「プロンプトを書くな、ループを設計しろ」を読んで、自分のループを見直した

Addy Osmaniの「Loop Engineering」を読んだ。要は、もうプロンプトを上手に書くことを頑張るんじゃなくて、エージェントにプロンプトを書かせるループのほうを設計しろ、という話。

addyosmani.com

読みながら、これ自分が最近このブログのリポジトリでやってることそのものじゃん、と思った。意識して「ループを作るぞ」とやってたわけじゃなくて、気づいたらそうなってた、という感じ。なので一回ちゃんと棚卸ししておく。

5つの部品を自分の環境に当てはめてみる

記事だと、ループは5つの部品＋メモリでできてるという整理になってる。自動化・worktree・スキル・プラグイン/コネクタ・サブエージェント、それと状態を覚えておく場所。これを自分の手元に当てはめると、けっこう揃ってて自分でもびっくりした。

スキルはわかりやすい。このリポジトリには docs/agents/skills/ に記事を書くとき用の手順書が置いてあって、新しい記事を書くたびにテンプレートとフロントマターのルールを読み直させてる。記事を書くだけじゃなくて、仕事のほうでもWantedlyやクラウドワークスの応募者をスクリーニングするスキルとか、JDをSlackに下書きするスキルとか、1on1のレポートを作るスキルとかを自分用に書いてる。要は「毎回同じ説明を口頭でやるのがだるい作業」を全部スキルに落としてる感じ。

コネクタもそう。SlackとLinearとNotionとカレンダーあたりは繋いでるので、エージェントが「ここに調べた内容を書いて」「このチケットを更新して」までやれる。記事の話で言うと「修正案はこれです」で止まるのと、「PRを開いてチケットを紐付けてSlackに通知するところまで勝手にやる」のとでは全然違う、というのは本当にそう。

worktreeとサブエージェントは、最近はもうガンガン使ってる。

サブエージェントで効いてるのは、割り込みの使い方。ループとかgoal志向の作業を回してる最中に、「あとでこれもやろう」って後回しにするんじゃなくて、その場で枝を生やす。メインのagentとやり取りしてる流れの中で、「これはバックグラウンドで流して」とか「これは別のサブエージェントに投げて」と、今その瞬間に振っちゃう。メモだけ書いて別のやつに動かせることもある。どれをサブエージェントに出すかも、メインのagentに判断させたりする。会話を止めずに横で別の作業が進むので、待ち時間が減る。

worktreeのほうは、topicやgoalが違う作業を、同じリポジトリ上で並行して進めるのに使ってる。作業領域は分かれてるけど元は同じリポジトリなので、別のことを同時に走らせても混ざらない。実際この記事を書いてるのもworktreeの中だったりする。

その中でも「書くやつ」と「チェックするやつ」を分けるのは、相変わらず効果がデカい。自分で書いたコードを自分で採点すると、まあ甘くなる。別の指示を持った別のやつに見させると、自分が見落としてたのをちゃんと拾ってくる。

状態を覚えておく場所、これが地味に効いてる

記事で一番「わかる」と思ったのが、6つ目のメモリの話。会話の外側、ディスクの上に「何が終わってて何が次か」を置いておくやつ。

このブログで言うと AGENTS.md と CLAUDE.md がまさにそれ。スタックはNext.jsの何で、記事はどこに置いて、フロントマターの必須項目はこれで、検証は npx velite build を流せ、みたいなのが全部書いてある。エージェントは毎回まっさらな状態で来るから、これがないと毎回ゼロから僕のプロジェクトを推測し直すことになる。実際このリポジトリのNext.jsはバージョンが新しくて、学習データのNext.jsとは違うところがあるので、それを AGENTS.md の先頭で釘を刺してる。これがないとエージェントは平気で古いやり方で書いてくる。

忘れるのはエージェントで、忘れないのはリポジトリ、というのは本当にその通りだなと思う。

「次に何を書くか」はどこに置くか

AGENTS.md と CLAUDE.md は「どう書くか」の記憶なんだけど、ループにはもう一個、別の種類の記憶が要る。「次に何を書くか」「この前ふと思いついたTopic」「この記事は保留にした、理由はこれ」みたいな、タスクとか判断のほうの記憶。これは規約とは性質が違うので、置く場所も分けたほうがいいなと最近思ってる。

このブログでは、そこを GitHub の issues に寄せていくことにした。リポジトリのすぐ隣にあって、エージェントも読み書きできるので、「次に書くネタ」とか「この前の検討の続き」をissueに積んでおけば、ループの次の一手をそこから拾える。会話を閉じても消えない、ディスク上のメモリのタスク版、というイメージ。正直まだ始めたばっかりで、これからちゃんと運用に乗せていくところ。

会社とか、もっと大きいProjectになると器が変わる。僕の場合、大きめのTopicはLinearだったりNotionだったり、あるいはそれ以外の何かを使ってる。ただこれはあくまで「僕はこうしてる」という個人の運用の話で、組織として「ここに集約する」みたいな決めはまだ作れてない。正直そこは課題で、人によってLinearだったりNotionだったりSlackのDMの中だったりに散らかってる。

スケールで器は変わるけど、やってること自体は同じで、ループの状態を会話の外に置いておく、というだけ。ブログくらいの規模ならissuesで十分だし、むしろリポジトリと地続きなぶん都合がいい、というのが今の感触。

じゃあ全部ループに任せられるかというと、まだ無理

ここからが持論。記事自体もちゃんと「ループはお前を仕事から消してはくれない」と書いてて、そこに一番共感した。

僕がまだ全部は任せられてない理由は単純で、検証が結局こっちに残るから。ループを回しっぱなしにするということは、ミスも見てないところで量産されるということで、サブエージェントに検証させても「できました」はあくまで主張であって証明じゃない。記事のスクリーニングにしても、最終的に面談するかどうかは人が判断したい。ループが出してきた判定をそのまま鵜呑みにするのは、まだちょっと怖い。

あと、これは自分でも気をつけないとなと思うんだけど、ループが勝手にコードを書いてくれるほど、自分が中身をわかってない部分が増えていく。便利なんだけど、便利すぎて「とりあえず出てきたやつでいいや」になると、たぶん良くない。記事の言葉を借りると、同じループでも、わかってる仕事を速くするために使う人と、わかるのをサボるために使う人とで結果が逆になる、と。これはツールのせいじゃなくて使う側の話なので、耳が痛い。

結局どうするか

なので今のところ僕のスタンスは、スキルとメモリと「作る/チェックの分離」みたいな、明らかに毎回得するところは積極的にループに寄せる。けど、最終的な判定とマージは自分の手元に残す、というあたりでバランスを取ってる。

記事を読んで一番良かったのは、自分が無意識にやってたことに「ループ設計」という名前がついて、どこがまだ穴かが見えたこと。worktreeやサブエージェントで並列に走らせるところは、もう日常になった。残ってる穴はむしろ、検証と最終判定を手放せないところと、ループの記憶を組織としてどこに集約するか決められてないところ。そのへんが次の宿題かな。