ステップ4では、あなたはもう個々の指示を出さない。
第18回まで、この講座はずっと「人がまだ画面のどこかに残っている場所」を扱ってきた。伴走し、レビューし、疑い、信頼を積む。ステップ1から3まで、あなたは常にループのどこかに立っていた。
ステップ4は、その前提が崩れる場所だ。Boris Chernyが公開した五段階表の最上段では、同時に走るエージェントは数百から数千に達する。あなたが個々の作業に指示を出す場面は、もうほとんど残っていない。ループが動き、ループがClaudeにプロンプトを送り、Claudeが必要に応じて次のClaudeを起動する。あなたの手に残るのは、個々の指示ではなく、全体が向かう方向だけになる。
これを、この回では「意図で舵を取る」と呼ぶ。ハンドルを握っているのではなく、地図を握っている状態だ。
ただし、正直に断っておく。この段に実際に立っている組織は、まだ数えるほどしかない。Boris自身が「Anthropicはステップ3から4へ押し進んでいる最中」だと公開している。だからこの回は、「今日から実践する手順」ではなく「向かう先の風景を先に知っておく」回として読んでほしい。地図を持たずに山頂を目指す人はいない。
ステップ4で何が変わるか
ステップ4で変わるのは、承認と起動の主体だ。ステップ3までのあなたは、いわば「マネージャーのマネージャー」だった。仕事はループになり、疑う役も組織した。それでも、承認するのは人間で、ループを起動するきっかけを作るのも人間だった。
呼び方を借りるなら、指揮官からVPへ、とでも言うべき変化だ。大きな会社の部門長は、担当者一人ひとりの業務判断を自分で決めているわけではない。方針と閾値を示し、そこから外れた案件だけが報告として上がってくる仕組みを作る。意図で舵を取るというのは、これと同じ構造だ。現場の一つひとつを見なくても、全体が向かう方向には誰よりも責任を持っている。
誰が指示を出しているのか
この段を一言で表すなら、ループがClaudeにプロンプトを送るようになる、ということだ。作者本人が、驚くほど率直な言葉でこの変化を語っている。
“I don't prompt Claude anymore. I have loops prompting Claude and figuring out what to do.”
筆者訳もうClaudeに直接プロンプトを送ってはいない。ループがClaudeにプロンプトを送り、何をすべきかを判断している。
これまでの回で書いてきた「依頼の型」「CLAUDE.mdを育てる」「検証ループを作る」は、すべてあなたが1つのプロンプトを書くことを前提にしていた。ステップ4では、その前提そのものが外れる。プロンプトを書くのではなく、プロンプトを書く判断をするループを書く。たとえば、こんな形を想像してほしい。
$./monitor-loop.js --watch billing-anomalies[loop] 異常パターンを検知: 3件[loop] Claudeを起動 → 原因調査タスクを自動生成
[loop] Claudeを起動 → 修正案の作成タスクを自動生成
[loop] 人間への通知: 重大度「警告」1件のみ
3件のうち、人間の画面に届くのは1件だけだ。残り2件は、ループの中で発見され、ループの中でClaudeに投げられ、ループの中で処理が完結している。あなたはこの流れを設計した人であって、この流れを毎回動かす人ではない。
これは仮定の話ではない。Boris Cherny自身が、これまで四半期単位でエンジニアを拘束するために先送りされがちだった大規模なコード移行やリファクタリングが、同じ構図でもっと短い期間に収まるようになったと明かしている。
“Big migrations and refactors are some of a team's most important work, and the easiest to push off to a “better time” since they'd tie up engineers for a quarter. With dynamic workflows, Claude can now land that kind of work in days or weeks.”
筆者訳大規模なマイグレーションやリファクタリングは、チームにとって最も重要な仕事の一つでありながら、エンジニアを1四半期拘束してしまうために「もっと良いタイミングで」と先送りされがちな仕事でもある。Dynamic workflowsを使えば、その種の仕事をClaudeが今や数日から数週間で仕上げられる。
Claude Agent SDKの位置づけ
この規模を人手で組むのは現実的ではない。ここで登場するのが、Claude Agent SDKだ。
Claude Codeという対話ツールの裏側にある「ハーネス」（エージェントループ、組み込みツール、hooks、サブエージェント、権限管理、MCP接続）を、Python/TypeScriptのライブラリとしてそのまま使えるようにしたものだと考えてほしい。CLIを操作するのではなく、ハーネスそのものを自分のシステムに組み込む。
公式には、3つの使い分けが示されている。
先ほどの監視ループの例は、まさにSDKが支えている層だ。ステップ4の「数百〜数千体」という数字は、対話セッションの数ではない。SDKで組まれたシステムが、必要に応じてClaudeを呼び出した回数に近い。
作者本人が、この変化をどれだけ徹底して生きているかを示す発言がある。
“I haven't written a line of code by hand in, I think, eight months now.”
筆者訳もうかれこれ8ヶ月、自分の手でコードを書いていないと思う。
8ヶ月という数字そのものより、その裏側にある事実の方が重要だ。手を動かす仕事から離れるほど、代わりに問われる仕事が増える。それが次の話になる。
この段のボトルネックは技術ではない
この段の本当の難所は、技術ではなく対象選びだ。ここまで読むと、ステップ4は技術的な達成に見えるかもしれない。実際はそうではない。
視点
この段の本当の難所
SDKも、ループを書く技術も、もはや珍しいものではない。難しいのは、その規模で自動化する価値がある仕事を、そもそも見つけることだ。動かす対象を間違えれば、数百体は数百件の見えない失敗を同時に生む装置になる。
Cat Wuの発言は、この講座がずっと扱ってきた「検証ループ」の議論と、同じ根から生えている。
“As code becomes much cheaper to write, the thing that becomes more valuable is deciding what to write.”
筆者訳コードを書くコストが劇的に下がるほど、価値が上がるのは『何を書くか』を決めることだ。
同じことが、自動化にもそのまま当てはまる。エージェントを起動するコストが下がるほど、価値が上がるのは「何を自動化するか」を決めることだ。では、何が良い候補で、何がそうでないのか。
- 繰り返し発生し、パターンが安定している
- 結果を機械的に確認できる（テスト、数値、差分）
- 失敗したときの合図がはっきりしている
- 一回性が高く、毎回判断基準が変わる
- 「良い」の基準が人の感覚にしかない
- 失敗しても、誰も気づかないまま進む（サイレント障害）
この基準を満たす実例が、すでに公開されている。Anthropicは、大規模なコード移行を、挙動の正しさを機械的に判定する基準（judge）を確立するところから始め、ルールブック作成、少数ファイルでのストレステスト、全体翻訳、コンパイル、スモークテスト、挙動一致という6段階のループに乗せて終わらせたと報告している。
この進め方の核心は、次の一文に集約される。
“The core insight is that you don't fix the code. You fix the process (loop) that produced the code.”
筆者訳核心にあるのは、コードを直すのではなく、コードを生んだプロセス、つまりループを直すという発想だ。
同じ発想は、対象選びにもそのまま当てはまる。手直しすべきは個々の失敗ではなく、失敗を生み続けているループの方だ。
見分ける基準は、第7回で作った検証ループとまったく同じだ。確かめようがない仕事を数百倍に増やしても、確かめようのない失敗が数百倍に増えるだけ。
注意
よくある誤解と罠
- 「自動化できる」と「自動化すべき」の混同。技術的に可能なことと、その規模でやる価値があることは別の話
- 検証ループが育っていないのに数だけ増やす。第18回で見たとおり、信頼はループの実績でしか積み上がらない。ここを飛ばすと、ステップ4は「見えない失敗が同時多発する場所」になる
- 「意図で舵を取る」を「丸投げして放置する」と取り違える。舵を取るとは方向を確認し続けることであって、手を離すことではない
今日のまとめ
- ステップ4では、あなたが個々の指示を出すのではなく、ループがClaudeにプロンプトを送る
- Claude Agent SDKは、この規模を自分のシステムに組み込むための土台
- 本当のボトルネックは技術ではなく、規模で自動化する価値がある仕事を見つけること
明日のアクション
自分の仕事の中で、「繰り返し発生し、結果を機械的に確認でき、失敗の基準がはっきりしている」タスクを3つ書き出してください。
そのうえで、それぞれについて1文で答えてください。「これを今100体規模で自動化したら、最初に壊れるのは何か」。
答えられないタスクは、まだ自動化の候補ではありません。それがこの回の診断です。
次は、この規模で走らせたときにあなたに残る唯一の仕事、監視の設計に入ります。