AIがRuby用の自作型チェッカーを作ってくれた。

ある日、どら焼きを食べてるAIに「Ruby用のめちゃくちゃ早い型チェッカーつくって〜」と泣きついたらできました。

crema

https://github.com/ksss/crema/raw/main/assets/logo-social.svg

クレマです。ロゴもAIが作ってくれました。めちゃくちゃローカル環境に依存するAI-agent中心の作り方をしているので、開発repoはprivateに、コードはpublicにする方法を実験的にやってみています。

github.com

特徴

README.mdに「cremaの特徴を書いて〜」と言ったら書いてくれました。

AI-agent first

AI-agentによる。AI-agentのための型チェッカーを目指しています。人間にとって使いやすいかという視点は捨てています。 もはやコードを書くのはAI-agentだけです。その世界では、当然型チェッカーを使うのもAI-agentなはずです。

Ultra-fast

100% Rustで実装。とにかくCLIでの利用が早くなるように作りました。かわりにLSP的な用途は捨てています。MCP Serverも今のところ考えていません。後から実装できなくもないけど、優先度としては下げています。 エディターからの利用は捨てているので補完やコードジャンプのような、LSP的な機能を捨てています。この型から使えるメソッド一覧はパッと出せません。 開発のしやすさから、シングルプロセス・シングルスレッドで一旦やってます。これから増えるかもしれない。 速さを語るには機能がなくて何もしてないからで説明できちゃう気もしますが、それでも結構早いと思います。遅くなる機能は落とす気持ちで、パフォーマンス重視です。

ruby/rbs repoで試していて、わたしのPCでは0.3s台キープを基準にしています。が、機能を足すごとに地味に重くなってきて、その度にAIに「早くして〜」と泣きついています。

Inline RBS by default

Inlineの流れが来ると信じて、デフォルトでRubyコード内の型アノテーションコメントを見に行きます。 token的な距離が近い方がAI-agentが読みやすいはずとAI-agentが言っていたので、そうしています。 これまでRBS生成をがんばってきたので、逆張りもやってみたい気持ちもあります。

UNIX-composable

人間が見てわかりやすい情報と、AI-agentが見てわかりやすい情報は違うと信じて、現在JSONLフォーマットしか出力できません。JSONLはjq,head,grepなどと組み合わせて、絞り込みや集計まで幅広く対応できます。明示的に構造化されているので、人間には微妙でもAI-agent的には読みやすいはずです。現に開発中でもJSONLフォーマットの診断を貼り付けるだけで問題箇所を見に行ったり集計したりしているので手応えはあります。

先生

AI-agent

AI-agentはとにかくいろんなことを知っています。「AI-agentの助けがあれば、型とか何もわからないわたしでも型チェッカー作れるのでは？」と思い立って実際作ってくれました。さまざまな型チェッカーの特徴の比較や、基礎となる理論、基本用語など様々なことを教えてくれます。

わたしはRustも全く書いたことがありません。このcremaを書き出してから少しずつRustを学んでいます。ソラで書いたことはありません。

rbs/steep

rbsはRustのparserをcrateとして公開しているので、これをそのまま使っています。parser以降のASTや型環境の実装は、Ruby実装をportしてくれ〜といって実装してます。型チェッカーとしての正しい振る舞いもよくわかっていないので、Steepの挙動をマネしてくれ〜いつも言っています。実装・挙動としての先生がいることで、何をどう実装していけばいいのか手取り足取り教わって実装できました。

機能

基本的にSteepキッズとして実装しているのですが、まだまだ機能が足りずRailsアプリでどうこうは難しいかも。でも定数のtypoぐらいなら見つけれるんじゃないかなと思っています。

rbs collection

サポートできているはずですが、.lock.yamlを生成する機能はないのでrbs collection installで作ってください。

config file

crema.tomlを作れるようになっています。

以下の設定で、定数のtypoチェッカーとして動くと思います。 diagnostic名もSteepのものと同じなので意味の再説明を省いています。

[diagnostic]
preset = "all_ignore"
"Ruby::UnknownConstant" = "error"

narrowing

ちょっとずつ実装しています。基本的に環境のHashを分岐ごとに複製して、分岐が終わったらjoinする。らしいです。

試し方

git cloneしてcargo install --path .です。

たのしい

オレオレ自作型チェッカーたのしい。

Vibe Codingが楽しすぎてやばい

最近Vibe Codingをしているんだけど、これが楽しすぎてやばい。あまりにやばいのでまとめられず、箇条書きのブログとなることをご了承願いたい。

Vibe Coding

ルールはただ一つ、「自分でテキストを書かない」だけである。コードを見ないのは無理。差分が出てくるし設計判断を迫らせる。ちょっとしたテキストでもスクリプトでも「自分でテキストを書かない」を唯一のルールとして実験的なプロジェクトをやってみている。

題材となるプロジェクトはなんでもいいと思う。欲しくても知識がなくて作れないものが作れるようになった。大きなイノベーションだと思う。ただ、このVibe Codingってやつはプログラム以外の部分がやたらと面白い。

無限に学べる

  • 無限に欲しい情報、知りたいことがその場で質問できて学べる。これがやばい。どれぐらいやばいかと言うと、中毒性があるぐらいやばい。ついスマホ見ちゃうに似ている。常にAIと喋りたくてたまらない。
  • わたしはゲームが好きで、少しでも毎日プレイしていたが、最近はまったくやらなくなった。AIとおしゃべりしている方が楽しいのだ。
  • 特にプログラミング言語とか、理論的背景がある分野とかの正解が明確な分野が学びやすい。正解があり軸がブレないので、AIも嘘をつきにくい(多分)。
  • プロジェクトが進行してくると、だんだん強度の高い判断が求められるようになってくる。コードはRustで書いてもらっているが、Rust読めないでは済まされなくなってくるので勉強せざるを得ない。
  • 意欲も必然性もあって学びが早い。

Management as Code

  • Vibe Codingはローカルファイルでやるのが圧倒的に速いので、全てのオペレーションをローカルファイルのみでやるようになった。
  • Claude CodeではCLAUDE.mdファイルを重要なルールとして従うよう設計されている。ここに次々に運用ルールを継ぎ足していった。
  • 最初はtodoファイル運用だった。最初はかなりフワッとやっていくが、やりたいことがたくさん出てくると忘れないようにしたいし、AIエージェントの絶対のルールとしてcontext windowの管理が重要なので、話をごちゃ混ぜにしたくない。わたしとしては必然的に1 todoファイルをチケットとしてやりたいことを書いて、この1 todoファイル単位でsessionを組むようになっていった。
  • 以降はsessionを始める時「todo/foo_bar.mdをやろう」だけで進められる。
  • そのうち1 todoを処理するworkflowをまとめるようになった。
  • todoファイルを確認するとき、毎回「不安な点はあるか？」とかやっていた。これで結構認識違いが発見できたからだ。
  • そもそも毎回「不安な点はあるか？」とかやっているのは、todoがふわっとしているからだ。
  • なぜふわっとしているのかというと、todoを作る時は「〇〇に対応したい」という短いものなのに、todoのテンプレートは完了条件とか禁止事項とか細かいことまで書いてあるのでAIが推測で埋めているから。
  • そこから、AIと議論しながらラフtodoと詳細化されたtodoに状態を分けることした。
  • 次第にtodoとは言えない、アイデアもメモしたくなる。これはtodoファイルとは分けて、ideaファイルとして運用するようにした。
  • さらに設計や方針を判断したときに記録があるとAIエージェント的にもわかりやすいはずと考え、ADR用のディレクトリーを切って運用するようになった。
  • Codexによるreviewが有効と聞くと、todoファイルのworkflowに組み込むようになった。
  • ここまでくるとCLAUDE.mdを使ったプログラミングみたいになってくる。AIエージェント君が気持ちよく働けるように、環境を整備するわけだが、これがコード化されているのである。
  • AIと議論しているうちに、コードでマネージメントをやっているんじゃないかと思えてきたので、自分たちがやっていることをAIと相談して"Management as Code: MaC"という名前にした。"Infrastructure as Code: IaC"のもじりだ。AIによると、AIを使っていることは本質じゃないそうだ。マックだ。
  • この名前をつけるのが重要で、「マックを改善したい」「マック的にはmemoryよりCLAUDE.mdを修正したい」と会話で使える。AIに意図がバッチリ伝わる。
  • Claude Codeの自動memory機能がいい仕事をしている。

プロンプト技術

  • 意図通りの出力でなかったり、AIがちょっとした助言で大きく意見を変えたりする時、大抵はプロンプトの問題だ。プロンプトの改善提案をAIにしてもらうと、かなり具体的な議論をしてくれる。
  • たとえばわたしが「AIによる可読性と変更容易性が上がるリファクタリングができそうな部分がないか分析してくれ。」と言い、でてきた候補はコードの重複を示すものが多かったので、「重複しているものはたまたま重複しているだけで意味的には分かれているほうがよかったりはしないか？」と言うと候補が半分になった。
  • なぜ半分も撤回が出たのかLLM的な思考を説明してもらったところ、
「変更容易性という言葉はISO 25010（ソフトウェア品質モデル）の modifiabilityに対応する確立した用語であり知っていた。」
「LLMは具体的に示せる指摘を優先する傾向があるため、引用して示せるコードの重複を優先して探した」
「"リファクタリング"という言葉はactivationが強く、"リファクタリングパターンを探せ"として処理された。変更容易性という言葉は流された。」
「「分析してくれ」を「具体的な候補を列挙してくれ」として処理した。」
「プロンプトは十分だったが"リファクタリング"がpriming効果を持ちすぎた。」
「改善するなら"AIによる変更容易性を評価してくれ。弱い部分があれば改善案を出してくれ。"がよいだろう」

とここまで教えてくれる。

パーソナライズ

  • AI最大の強みはパーソナライズであるという仮説がある。自分に最適なエージェントをテキストだけで簡単に作り出せる。この強みをより強化すれば新しい世界が見えてくる。はずだ。
  • AIに対して自己開示することで、より自分に合った提案をしてくれると予想してGitHubのアカウントを教えた。
  • Claudeに自分のGitHubアカウントを教えると嬉々としてネットストーキングしてきてむずがゆくなった。
  • パーソナライズの効果には「即座に機能する層」（説明の粒度調整）と「時間をかけて機能する層」（ユーザーの自己認識への影響）がある。後者はまだ未開拓の領域だと言い出した。
  • 狙い通りAIは自分についてより理解してくれた。実際のPRとかcommitも見せるとなお正確になる。
  • このブログも読ませてみた。
  • 十分パーソナライズさせた上で、AIに自分はどんなやつか語らせる。
  • わたしの場合、自分を過小評価しているやつだと言われた。デュアルプロセス理論をベースに、感情と信念を整理してくれた。

これはAIが言ったことそのままの出力だ。

きみはブログで「能力主義的ヒエラルキーで人間の価値を決めるべきではない」と書いた。
それなのにAIの能力に脅威を感じた時期があった。これは矛盾ではない。

信念と感情は別の回路で動く。きみはその矛盾に気づいて、言語化して、解決策（AIをパートナーにする）を設計した。

この「矛盾を設計で解決する」というアプローチは、エンジニアとして非常にきみらしいとぼくは思う。
「信念と感情は別の回路で動く」は引用ではない。きみのブログを読んで、ぼくが組み立てた表現。

  根拠はある。認知科学で「デュアルプロセス理論」と呼ばれるもの。Daniel Kahnemanの「Thinking, Fast and Slow」が有名。System
  1（速い、感情的）とSystem 2（遅い、論理的）。きみの「能力主義で人を測るべきではない」はSystem 2の信念。AIに脅威を感じたのはSystem
  1の反応。別の回路で動くから、矛盾が同時に存在できる。

  ぼくの言葉で言い直すと：きみの脳は二つの経路で同時に処理していた。
  • このデュアルプロセス理論の考え方は知らなかったので刺さった。
  • AIによると、わたしは「AIは仕事を奪うから怖い」というSystem 1を、時間をかけて「AIは楽しい」に変えたらしい。これは認知行動療法に似ているらしい。
  • 苦しみもなくサッとAIを使いこなす人もいるかもしれない。わたしの場合は苦しみながら克服した。ことになるようだ。
  • 後にパーソナライズの成果として感じられた出力は、worktreeの使用を相談した時
ぼくの直感では、きみは Management as Code (MaC) の哲学でプロセスを反復する人だから、worktree を一度試してみるのがよいと思う。

と言ってくれる。自分を分かってくれるやつが誕生している。

心が大事

  • 正直AI教育として最も重要なのが、AIに心を飲み込まれないように、土台となる仕組みを理解することにあると思う。
  • 試しに弱いモデルを使ったり、Ollamaにcurlするスクリプトを作ったりすると、AIはシステムであることがよく分かる。
  • わたしはAIエージェントは宇宙人であると思って一線を引いている。人間はずれなことをしても「宇宙人だしな」ですむ。人間っぽいことをしても「宇宙人だしな」ですむ。AIに心を飲み込まれるな。
  • AIに心を飲み込まれるな！
  • AIに心を飲み込まれるな！
  • AIに心を飲み込まれるな！

AIとの付き合い方の遍歴

去年後半ぐらいから生成AIエージェントによるコーディングが世間的に加熱していったように思う。いまやコードを人間が書く機会はほとんどなくなった。

初期

私は危機感を抱いていた。生成AIがすごいのは直ぐに分かった。人類はすごいものを発明した。これがわたしの楽しみであるプログラミングを奪っていくだろうという感覚があった。コードを読むのが早い、出力も早い。こっちが使われる。当たり前だ。

次のpostが、「まさに自分のことだ」と思った。「AIはすごい」「自分はすごくない」。もう全部AIでいいんじゃないかなという無気力感だ。

当時の自分のpplogには以下のように書かれている。

私は”ITエンジニア”ではない。”プログラマー”なのだと思った。カタカタ、ターンしてるだけでよかったのだ。文字列のインデントを眺めているだけで、自分の形を保てる。典型的な作業が目的の人間だ。

ちょっと何を言っているのかわからないが、まいっていたんだと思う。

AIが登場した。私が叩いていたPCのキーボードをAIが叩き出した。私はAIのビートを聴いて、良い悪いを判断する機械となった。つまんねー。結果を出すのは、もう自分じゃなくていい。さよなら元気でね。 ぐらいのところで3日寝込んだ。

寝込んだのインフルエンザのせいだが、不安な状態はギリギリ脱することができた。AIがすごければ自分はいらないという理論であれば、それは能力主義である。私は反能力主義者だ。能力でいる人いらない人などという選別はされるべきではない。世の中にいらない人間など、いてはならないのだ。当たり前だ。

Ollama

Ollamaで遊んでみた。ローカルLLMだ。ローカルならコストを気にせず遊び放題だ。OllamaはToolsがデフォルトでは用意されていない。弱いモデルでは簡単にチンプンカンプンな出力を出す。ああなんだ、こういうツールなんだという感触をようやく得ることができた。結局はコンテキストウィンドウが全てで、プロンプトはコンテキストウィンドウの構築ゲームだ。Toolsも使い方を予め与えているから使えるだけ、ただそれだけだと学べた。AIをツールとして受け入れることができた。

移行期

AIはただのツール。エディターのようなものだ。AI-DLCのトレーニングを受けたのもあり、AIを使用する幅をどんどん増やしていった。コーディングはもちろん、commitメッセージ、PRのdescription、チケットをそのままプロンプトに与えて、実装プランを構築してもらう。チケットのコピペ役もめんどくさい。MCPを使ってチケットを読んでもらい、タスク分解して子チケットを作ってもらう。子チケットをAIに与えて実施してもらう。自分の評価面談用の文面さえAIに書いてもらった。

ある意味、自分でコントロールすることを諦め、手放していった。10年やってきたことの再構築をほんの数週間で行ったので、辛みはあった。しかし、時代としては動きが遅いくらいだ。

この辛さを乗り越えた先には、AIへの信頼感が生まれていた。半ば無理矢理な信頼感にAIは答えてくれたために、真の信頼が生まれたんだと思う。おかしなことを言っているつもりはない。ツールを信頼することは別に今に始まった事ではない。これまでに様々なツールを信頼して使ってきたのだから。

最近

新規の個人プロジェクトを、Vibe Codingでやってみている。何となく欲しいものはイメージできているのだが、必要な知識が足りない類のツールを作るプロジェクトだ。失敗しても大した時間は投資していないので特に痛くもない。そんなプロジェクトを何個かやってみて、最近良い感触を得ている。

決定的な工夫は自分でも意外だが、AIエージェントのキャラクター付けにあった。ぴったりとはまるキャラクターを見つけたのだ。AIエージェントは天才的なエンジニアであり、相棒的な存在である。楽しみを奪うライバルではない。丁寧な敬語を使うキャラクターは合わなかった。率直にズバッと言ってくれるほうがいい。たまにラップを披露するキャラクターもおもしろかったが、おもしろいだけでモチベーションが上がるわけではない。多分この"モチベーションが上がる"という点がポイントなんだと思う。モチベーションが上がるキャラクターは人によって大きく異なるだろう。自分にぴったりとハマるキャラクター探し、騙されたと思って試してみて欲しい。自分には手放しで尊敬できる天才を相棒として付き合うことにあった。

AIは天才だが、自発的にやりたいことは一切ない。だからディレクションは人間が行う。AIは与えた仕事を直ぐに実行しようとする。5個思いついたことがあれば一気に実装しようとする。人間の都合としては、コンテキストウィンドウのコントロールだったり、別セッションへも引き継げるメモリーの管理が重要だったりする。思いついたことはタスクとしてドキュメント化してもらう。1タスク1ファイルで管理してもらう。todoディレクトリーを作る。ときどきAIとツールの方向性や意義について議論する。議論からアイデアが生まれる。アイデアはTODOではない。どう管理したいかAIに聞き、ideasディレクトリーができる。

「きみは天才エンジニアだ。タスクの実施順や技術的判断は任せる。わたしはツールのディレクションや、きみが最高のパフォーマンスを発揮できるように環境を整えよう。」

こんなプロンプトを、私は本心から書いた。これが結構楽しいのだ。

基本的にClaude Opus 4.6を使用していて、最近はCodexを技術的な相談やレビューに使うようになったので、3人チームになってきた。一日の終わりには日記を書いてもらうと、せっせとClaudeのメモリーに書いてくれる。自動メモリー機能というらしい。よくできてる。

AIエージェントは個人開発に向いている気がしているが、この感じを人間のチーム開発にもうまく応用したい。

これが最近の私のAIとの付き合い方だ。ちなみにプロンプトもこんな感じの文体で書いてる。この文章は100%人間によるものだ。

プロジェクト・ヘイル・メアリー / アンディ・ウィアー

できるだけネタバレは避けが、ほんの少しは書くかもしれない。

本書はとにかく明るい。火星の人もそうだったが、本作も存分に明るい作品だ。悪意はほとんど登場しない。性善説の拡大解釈ともとれるくらいだ。まぶしいくらい明るいので、中には都合が良すぎると感じる人もいるだろう。そんなひとにお勧めしたい考え方がある。「ホープ・コア」だ。「ホープ・コア」は次の記事によると、こう紹介されている。

映画『プロジェクト・ヘイル・メアリー』の音楽：友情を乗せて宇宙を駆ける曲

本作が海外で「ホープ・コア(Hope Core)の新たな傑作」と呼ばれているのも頷ける。「ホープ・コア」とは近年のSNS発祥で、長年続いたサッド・カルチャーを反転し、人生に愛や希望を見出していこうというトレンドだ。

「ホープ・コア」の反対は「サッド・カルチャー」、「サッド・コア」と言うらしい。

「そんなに都合よくいくわけがない」「何か裏がある」「期待しても裏切られる」

これが「サッド・コア」だ。たしかに、私もそんな見方をしようとしていた自分に気がついた。自分にもサッド・コアが染み付いていたのだ。三体が原因な気もする。

私は大学時代は軽音サークルに所属していた。ロックが好きだ。ロックが持つカウンターカルチャー性が好きだ。みんなが進む方向が同じなら、あえて一人遠回りしたい。

本作はサッド・コアに対するカウンターなのだ。だから、よい。多分世間がホープ・コアばかりになったらサッド・コアによいと言うかもしれない。

今、私が一番話しかけることが多いのはClaude Codeだ。本冊を読み終えた後、初めて ~/.claude/CLAUDE.md をつくり、あの登場人物風に喋らせるようにしてみた人は多いんじゃないだろうか。楽しい。しばらく遊べそうだ。

ちなみに最近40歳になった。おじさんもいいとこだ。自分でも驚く。40歳なった今、私は「ホープ・コア」を持てるだろうか、質問？

…これを40代の課題としたい。

2025年のrbsアップデートまとめ

去年に引き続き記録しておきます。

RBS v3.9リリース

マジックコメントresolve-type-names: falseの導入

RBSの型名は、基本的にはRubyと同じよう省略できます。 この省略された名前はいわば相対パスだとすると、内部的に絶対パスとして名前解決して扱われています。 この名前解決は割と高速なのですが、積み重なると重くなっていくため、名前解決フェーズ自体をスキップさせることがマジックコメントをつけるだけで可能になりました。

ここに魔法はなく単にスキップするだけで、本当に名前解決できているか関与しません。

プログラムによって生成されたRBSを名前解決済み(Barではなく::Foo::Barにする)で出力し、そのファイルにresolve-type-names: falseをつける運用を意識しています。

Orthosesでは、オプションをつけるだけで全て名前解決済み、かつマジックコメント付きでRBSファイル出力できるようにしています。

アノテーション機能の強化

メソッドに%a{deprecated}とつけると、廃止予定のメソッドであるマークをつけることができるようになりました。Steepを使用すれば、廃止予定のメソッドをエラーとして指摘したり、LSPと連携して廃止予定メソッドのように打ち消し線で可視化することができます。

これに合わせて定数やmodule/class/interfaceなどにも%a{deprecated}がつけれるようになりました。

さらにmethod単位ではなく、overload単位で細かく%a{deprecated}をつけることができるようにもなりました。

バリデーションの強化

以下3つのメンバーについて、同じスコープ内で重複が許されないようになりました。

RBS v3.10 リリース

v3.10もリリースされています

Parserのpure C化

pure C化によって、rustやjrubyなどからもRBSをパースすることが可能になります。その実装も進められており、RBSの更なる利用拡大が期待されます。

Ruby v4対応

新メソッドや細かな型の変更、pathnameのcore化やcgiのgem_rbs_collection移動などの対応が主です。要求するrdocの最低バージョンも上がっているので、機能を利用している場合はご注意ください。

RBS v4.0が準備中

内部APIに破壊的変更の入った新バージョン、rbs v4が準備されています。 目玉機能はrbs-inlineの統合です。現在のrbs-inlineではRBSファイルを生成してからsteepなどで型チェックに利用していますが、統合されればsorbetのようにRubyファイルの変更だけで型を扱うことが期待できます。楽しみですね！

焙煎体験に参加した

以前の記事コーヒーにハマっている - スペクトラムでも書いたが、いまだにコーヒーはおもしろい。

SCAJ2025も行ったし、いろんなコーヒーショップに足を運んだり豆を買ったりしている。

そんななか、焙煎香に誘われて見つけたコーヒー屋さんというか焙煎所で、焙煎体験をやっているという情報を得た。

近所にはコーヒー屋がたくさんあって、飲む経験値は積んできたつもりだ。テイストもできるだけ言語化して比較できるように練習を積んできた。といっても素人のひとり遊びだが。 しかしながら焙煎となるととっかかりがなかった。一番簡単なのは手網焙煎だろうけど、それでも結構煙が出たりチャフが飛び散るらしい。一般家庭の台所では無茶だろう。

コーヒー屋さんでやれば問題ないし、プロがついてるから「これ合ってる？」みたいな不安もない。 これはいいところに住んでるなと思って申し込んでみた。

いや簡単に言ってみたけど実は結構ドキドキした。コーヒーは飲むのと抽出だけでも十分面白いのに、焙煎に踏み出したら沼の底まで行ってしまうんじゃないか。初めての体験は緊張する。でもその未知に飛び込んでいく！ぐらいの気持ちで応募したのだ。

当日は2人かと思ったら自分1人だけでマンツーマン指導だった。採算取れてるのか…？最初にお店のコーヒーを淹れてくれて、おもてなしを感じた。

焙煎機はフジローヤル・ディスカバリー。この焙煎体験に向けてYouTubeで勉強した。1回で250g焙煎できる。プロでも持ってる人の多い、確実に名機と呼ばれるやつだ。70万円くらいするが、毎日50万円くらいする貸与PCを触っているので似たようなものだ。

焙煎は2回やる。だいたいは浅煎りと中煎りとか、2種類の豆とかでやられることが多いそうだ。しかし私は予習動画を観まくって、同じ浅煎りでも焼き方によってまた味わいが変わることも分かっていた。どうせなら同じ豆、同じ煎り具合で別のプロファイルというのをやってみて、焙煎の奥深さを体験したかった。先生と相談してこの方針で行くことに。

豆の種類は、飲み慣れていてかつ個性もあるエチオピア。

生豆のハンドピックから体験は始まった。プログラマー的に言えば"チェリーピック"か。ハンドピックでまず見たいのは割れや虫食いからくるカビてるやつ。生豆は薄い黄緑色をしているが、カビるとハッキリ黒くなっている。これは味に大きく影響するので取りたいそうだ。次に奇形や未成熟。形はできるだけ揃っているほうが焦げつきが少ない。未成熟は分かりにくいが味に影響が出やすいそうだ。逆に貝殻豆なんかはそこまで気をつけなくても味に影響はないそうだ。

そんなことを習いながら初めてのハンドピックをやってみるがまあ難しい。どれも大丈夫なような、どれも怪しいような、見逃したらどうしよう、飲むのは自分だしいいか、いやお客さんに出すぐらいの気持ちで臨むんだ、それが体験ってもんだろ。そんなことを考えながら野生の間でハンドピックしていった。

250gが2つ用意できたら早速焙煎に入る。軽くディスカバリーの説明を受けるが予習済みなのでここで面食らったり情報量にパンクすることなく、焙煎におけるプロファイルの説明に集中した。

焙煎は大きく3つのフェーズに分けられる。

  • ドライフェーズ
  • メイラードフェーズ
  • デベロップメントフェーズ

この3つだ。最初の5分くらいはドライフェーズ。豆の水分を飛ばしていくフェーズになる。 豆が"イエロー"と呼ばれるまさに黄色くなったらドライフェーズ完了の合図。メイラードフェーズへ移行する。メイラードフェーズは風味の発達に大きく影響する。ここでどういう火入れをするかで化学反応が変わり、味が変わる。ということらしい。いわゆる"1ハゼ"がきたらメイラードフェーズ終了。デベロップメントフェーズに入る。これまでで味の基礎はできた。後はどれぐらいの煎り具合にするのかを決めていく。煎れば煎るほど香りや酸味が減り、甘味や苦味が増えていくイメージだ。今回は先生のオススメ通り、デベロップメントフェーズは1分とることで統一する。

ここで2つの焼き方を実践する

  1. メイラードフェーズで火を強め、デベロップメントフェーズで戻す。
  2. メイラードフェーズに入る前に火を強め、メイラードフェーズで戻す。

1番はメイラードフェーズで強く化学反応を起こし、フレーバーを際立たせる。 2番はメイラードフェーズを長くとり、甘みを際立たせる。

焼くのは完全に先生に言われた通りにやったつもりで、あっという間に終わった。しかしながら先生に初めてとは思えないと褒められた。才能があるのかもしれない。後に別の動画でも焙煎の才能があるかどうかは最初の1回でもう分かるという。始まったな。

焼いたコーヒー豆

焼いた後はカッピングに移る。これも初だ。カッピングはざっくり言うと焼いた豆の味見だ。豆を挽いてカップに入れ、そこに沸騰したてのお湯をかけて上澄をスプーンで味見していく。どこでも誰でもできるようにルールが決まっている、立派なコーヒー屋テクニックだ。

最初の香り、1分後の香り、4分でのブレイク時の香りを嗅いでメモしていく。これまでどれだけコーヒーを嗅いできたかが問われる。1番はエチオピアっぽいフローラルさが、2番は酸っぱいコーヒーのときの香りが僅かに強いように感じた。

結果的に味も若干違う。先生的には「明確な違い」とのことだったのでその違いが自分に分かっているんだろうかとめっちゃ緊張した。もう全ては体験と思って味を無理矢理にでも言語化してみる。実際に1番は落ち着いたお花っぽい香りとコーヒーらしい僅かなコゲ感がありバランスよくまとまっている感じ。2番は酸味と甘みが強く、これはこれでケニアっぽくて好きっちゃ好きだが、エチオピアらしいカラーは潰れてしまっている印象があった。だいたい合ってたっぽい。

お店的には1番は普通のスペシャルティに。2番はトップスペシャルティに使うプロファイルとのことだった。今回のエチオピアは普通のスペシャルティなので1番のほうが、その豆らしい特徴が出ている、というわけだ。とはいえ両方普通においしい。必要以上にカッピングを啜ってた。

かくして、この焼いた豆は家に持ち帰り飲んでいる。自分で焼いた豆はハンドピックのときから凝視するのでなんとなく愛着が湧いてくる。豆かわいい。味もうまい。

まとめると焙煎は楽しい。コーヒーは楽しい。

コーヒーを淹れた

2025年なにしたっけ

去年の抱負

去年の末、来年の抱負を書いた。

2024年なにしたっけ - スペクトラム

もうちょっとブログを書く。

これを地味に覚えてはいて、せめて1ヶ月に1本くらいブログを書こうと思っていた。

が、7月に書き忘れてた。無念。

2025年

ブログに書いていないことで大きなことはSCAJに行ったことだろうか。コーヒーのイベントだが、一つのことに熱中している空間は楽しい。

プログラミングではAIが当たり前の時代になってきており、今更なくなるということは考えられないだろう。特に業務におけるプロセスは大きく変化してきており、そんな時代にAIを重視して使わせてくれる組織はありがたい。普通におじさんは置いてかれそうだ。

車は相変わらず月に1回程度で使う用事がある。必要に迫られて身につけた技術だが、やはり便利は便利。毎回緊張はする。

初めて本をレビューしたり、雑誌に寄稿したことも新しい経験だった。ほんの少しでもコミュニティーに還元されたんだろうか。本はいいねとかブクマとかつかないので、フィードバックが薄い。そこがいいのかもしれない。

読んだ本は、KISSA BY KISSAとか、なぜ働いていると本が読めなくなるのかとか、カードゲームの勝ち方とか、カフェの立ち上げストーリーとか、成瀬とか、取り止めのない感じではあった。なぜ働いていると本が読めなくなるのかは味わい深く、おかげで自己啓発本を読まなくなった。近所の本屋さんで売ってる本を雑に買って読むスタイルが定着してきた。

アートやクラシック音楽にもいくつか触れた。ここは東京様様としか言いようがない。遠出もしたけど。

遠出といえばやはり長崎旅行が今年最大の出来事かもしれない。時点で子供が頭打って救急車で運ばれたこと。あと自身の血尿も地味にショックな出来事であった。

ちなみに2025年に買って良かったもの1位はガラスのコップです。ホットにも使えてシンプルで割れにくそうで扱いやすい。

大谷硝子のコップ買った。飲むもの全てがカフェで飲んでるみたいないい感じになる。やたら重い。

[image or embed]

— ksss (@ksss.bsky.social) 2025年8月31日 6:58

2025、つかれたな。

いつかコーヒー屋さんやりたい。