同じ依頼を、毎回言葉で説明し直すのをやめる。気づいたら、仕組みに変える。
第3部をここまで歩いてきた。2体目を立て（第8回）、自己検証を組み込み（第9回）、許可を設計し（第10回）、差分だけを見る型を作った（第11回）。複数のエージェントを、キーストロークを追わずに動かせる状態は、もう整っている。
だが振り返ってみると、ここまでの依頼はすべて一回きりだった。「このバグを直して」「このAPIを実装して」。毎回、言葉で一から説明している。ステップ2の最後の一手は、この一回きりの依頼の中に、実は繰り返されているものがあると気づくことだ。
同じ依頼を何度も打っていないか
繰り返しているのに、毎回言葉で説明し直している依頼が、きっとある。
まず自分の依頼の履歴を眺めてみてほしい。似た文面のプロンプトを、週や月の単位で繰り返し打っていないか。毎週のニュースレター生成、リリース前の確認作業、定期的なコンテンツの棚卸し。
- そのつど言葉で説明し直す
- 手順は毎回頭の中にあるだけ
- やる人によって微妙に手順がぶれる
- 手順が固定され、毎回同じ確認が走る
- 完了条件があらかじめ決まっている
- 誰が動かしても同じ結果に近づく
同じ内容を毎回打ち直しているなら、それはまだ言葉にしただけで、仕組みになっていない依頼だ。
何がループ化できるか：見分け方の3条件
すべての繰り返し作業がループ化に向いているわけではない。見分けるための条件は3つある。
他の現場にも、これとよく似た発想の道具がある。標準作業手順書（SOP）だ。特定の業務に対する標準的な進め方・確認項目・完了基準を、あらかじめ手順として固めておく。同じ案件が来るたびに、一から進め方を考え直さなくて済む。
仕事をループ化するというのは、その仕事のSOPを作る作業だと考えると分かりやすい。
ループにする前に、まず1回動かして確かめる
ループ化も、まず1回試してから広げる。第7回の検証ループと同じ原則だ。手順を固めたつもりでも、実際に1回通してみると、想定していなかった入力の形や、完了条件の甘さが見えてくる。
いきなり自動で毎日回す設定にはしない。1回、目の前で動かして、結果を自分の目で確認してから、繰り返す仕組みに格上げする。
Anthropicの公式ドキュメントは、この原則がいちばん小さい形で効く例として、大量のファイルを同じ手順で処理する作業を挙げている。手順は3つしかない。
ファイル横断の一括処理、3ステップ
対象の一覧を作らせる
たとえば「移行が必要な2,000個のPythonファイルを全部リストアップして」のように、まず対象を洗い出す
一覧を回すスクリプトを書く
第8回で扱った-pフラグを、シェルのforループに組み込む
数件で試してから、全件を流す
最初の数件の失敗を見て手順を直し、うまくいってから規模を広げる
2番目のステップの中身は、公式ドキュメントではこういう1行として示されている。
$for file in $(cat files.txt); do claude -p "Migrate $file..." --allowedTools "Edit,Bash(git commit *)"; done
files.txtに並んだファイルを1件ずつ渡し、編集とgit commitだけを許可した状態で、同じ移行作業を繰り返す。
--allowedToolsで触ってよい範囲を絞る点は、第10回の許可設計とそのまま重なる。ループで同じ処理を繰り返すときほど、権限を先に絞っておく効果が大きい。
3番目のステップが、この見出しの主張そのものだ。2,000件をまとめて流す前に、まず数件で試し、失敗のパターンを見てから規模を広げる。
ループの姿を先取りする
この先、第4部では実際に仕事がループとして自律的に回るようになる。その先にある景色を、少しだけ覗いておく。
“I don't prompt Claude anymore. I have loops prompting Claude and figuring what to do.”
筆者訳私はもう、Claudeに直接プロンプトを書かない。Claudeに何をすべきか考えさせ、動かすループがある。
ここまでの4回でやってきたのは、この状態にたどり着くための足場作りだった。2体を分離し、自己検証を強制し、許可を設計し、差分で見る。この4つが揃って初めて、次に「ループにプロンプトさせる」段階に進める。
何を最初にループ化すべきか選ぶ
見分け方の3条件を満たす候補が複数見つかったとしても、全部を一度にループ化しようとしない。
“the product manager's role is now to identify the handful of true non-negotiables and let the rest go.”
筆者訳プロダクトマネージャーの役割は今や、譲れない本当に重要な少数を見極め、それ以外は手放すことだ。
これは製品開発の話として語られた発言だが、ループ化の優先順位づけにもそのまま使える。候補全部に手を出さず、本当に繰り返す価値がある少数を選び、残りは当面手作業のままでいい。
ステップ2卒業条件
以下のすべてに手を動かして答えられるなら、ステップ2を卒業していい。
視点
ステップ2卒業条件
- 2体以上を同時に動かし、worktreeなどで作業領域を分けられる
- 各エージェントの検証（テスト・lint・型チェック）が自動で回り、結果だけが報告される状態になっている
- 許可の境界を先に決めていて、承認疲れで思考停止せずに判断できる
- 差分だけを見て、途中経過を全部追わなくても質を判断できる
- 繰り返している依頼を最低1つ、ループ化候補として言葉にできる
よくある誤解と罠
- ループ化を焦って、候補を全部いっぺんに自動化しようとする。優先順位をつけず手を広げると、どれも中途半端な完成度で止まる
- 完了条件が曖昧なままループ化してしまう。何をもって終わりとするかが決まっていないと、無駄に回り続けるか、途中で止まらなくなる
- ループの結果を誰も見ない状態を放置する。何を自動化すべきかを俯瞰し、例外だけを監視する仕組みは第5部で扱う。今の段階でそこまで手を広げなくていい
今日のまとめ
- 一回きりの依頼の中に、実は繰り返されているものがないか目を向ける
- ループ化に向くのは、完了条件が機械的に判定でき、入力の形が安定していて、頻度が繰り返しに値するもの
- ステップ2の卒業条件は、並列・自己検証・許可設計・差分レビューの4つが揃い、ループ化候補が1つ言語化できていること
明日のアクション
自分の仕事の中から、繰り返しているタスクを1つ選んでください。
「完了条件を機械的に判定できるか」「入力の形は安定しているか」「頻度は繰り返しに値するか」の3条件に照らして、ループ化候補になるかどうかを判定してください。候補になるなら、その完了条件を1文で書き出してください。
次は、そのループを実際に動かす番だ。第4部、第13回「ループとルーティン」で、/loopと/goalの実体を扱う。