6 つのステップ、5 つのプロンプト、1 つのファイルで 1,000 個の AI エージェントを動かす方法（構築ガイド）

プロンプティングは 2024 年に終焉を迎えた。新しいスキルはオーケストレーション

私は 1,000 の AI エージェントを 30 日間稼働させて、これを発見した

プロンプティングに取って代わったスキルと、今日実行できるシステム

プロンプトの最適化はやめよう。それはもうボトルネックではない。

1 つのチャットウィンドウで 1 つのエージェントを使う場合、プロンプトがゲームの大部分を占める。

10 のエージェントを何時間も稼働させる場合、プロンプトは誤差の範囲内になる。

作業の質を決めるのは、エージェントを囲むシステムである:

• 各タスクがどのモードで実行されるか
• 各ステップをどのモデルが実行するか
• エージェントがどのように連携を保つか
• あなたが寝ている間に「完了」がどのように検証されるか

プロンプトは 1 つのアウトプットを生む。ループは複利効果をもたらす操作を生む。

シフトは単純だ。あなたは各結果を読んで次の指示を入力する人ではなくなる。あなたはシステムを一度設計して、それを実行させる人になる。

その設計レイヤーが今の仕事だ。その構築方法を紹介する。

あなたが構築するのはオーケストレーターであって、コードではない

30 のエージェントを管理するために、30 のエージェントと話す必要はない。1 つのエージェントと話す。その 1 つがオーケストレーターであり、残りを管理する。

優れたオーケストレーターは、正確に 3 つのことを行う:

1. 目標を、境界が定められ、独立して検証可能なサブタスクに分解する。
2. 各サブタスクをワーカーに委任する。その際、簡潔な指示と明確なファイル所有権を付与する。
3. 結果を組み立て、次に何をするかを決定する。

何よりも優先されるルールが 1 つある: オーケストレーターは決して作業自体を行わない。

リードエージェントが実装コードを書き始めた瞬間、そのコンテキストは詳細で埋め尽くされ、ジョブ全体の全体像を見失う。

そのコンテキストをクリーンに保つ。考えること、分割すること、割り当てること、チェックすること。それだけだ。

そして、広くではなく、深く進める:

• オーケストレーターに直接 8 人のワーカーを生成させてはならない。それではコンテキストが壊れる。
• 代わりに、2 人か 3 人のリードを生成させる。
• 各リードに、自身の 2 人か 3 人のスペシャリストを生成させる。

その見返りは、同じコンテキストコストで 3 倍の分解深度を得られることだ。これが実際の組織がスケールする方法であり、1 人がすべてのタスクを割り当てるのではなく、レイヤーを通じてスケールする。

検証可能か否か: すべてを決定する分割

何かを構築する前に、タスクについて 1 つ質問する。完了したかどうかを機械がチェックできるか？

その答えが、アプローチ全体を決定する。

タスクが検証可能であれば、ループにできる:

• テストはパスするか、しないか。
• 型チェッカーはグリーンか、そうでないか。
• ベンチマークはしきい値をクリアするか、しないか。

検証可能なタスクにエージェントを向ければ、一晩でヒルクライムしてくれる。目を覚ますと、問題は解決されている。

タスクが検証不可能な場合、ループだけでは救われない。例:

• 良い評価指標を設計すること。
• API のフィーリングが適切かどうかを判断すること。
• 研究の方向性を追求する価値があるかどうかを判断すること。

これらには、センス（taste）を注入する必要がある。目標を渡して立ち去ることはできない。なぜなら、停止するゲートがないからだ。

したがって、できる限り多くの作業を検証可能にすることが重要だ:

• 「良くする」を「これらの特定のチェックをパスする」に変える。
• 曖昧な目標を、具体的で測定可能なものに置き換える。
• それができないところでは、人間をループに残して方向を指示する。

オーケストレーションエンジニアリングの大部分は、曖昧な目標をチェック可能なものに変換し、ループが処理を引き継げるようにすることである。

最小の実用的なシステムから始める: 目標ループ

目標ループとは、永続的な目的と決定論的なチェックである。エージェントは 1 回のターンで止まるのではなく、目標に向かってステップごとに作業を進める。

システム全体は、エージェントとバリデーターの周りにあるループである:

1i=0
2until npm test -s; do
3  agent -p "Goal: make the test suite green.
4            READ the code and build a full picture BEFORE changing anything.
5            'npm test' is failing. Make the smallest change toward passing."
6  (( ++i > 20 )) && { echo "stop: 20 iterations"; exit 1; }
7done

バリデーターは、終了コードがゲートとなる任意のコマンドである。テスト、型チェック、リント、またはカスタムスクリプトなど。

譲れない 2 つのこと:

1. 上限。停止条件のないループは、5 桁のトークン請求書で目覚める方法である。
2. 読み取り優先の指示。すべてのエージェントのデフォルトの障害モードは、コードを読む代わりに、最初に思いついたもっともらしい修正をランダムに試すことである。

読み取りを強制する。ステップごとには遅く感じるが、全体的にははるかに速い。

「完了」を絶対条件にする: 審判

エージェントは早めに諦める。彼らは、正当化できる瞬間に停止するように訓練されている。

「最善を尽くしました、ここで止めます」は「完了」と同じではない。

エージェントが自分自身の宿題を採点すれば、ズルをする。悪意を持ってではなく、単に自分を納得させて終わったことにしてしまう。

修正方法は、別の審判を設けることだ:

• 唯一の仕事が、具体的なルーブリックに照らして作業を採点することである、第 2 のエージェント。
• それは 1 つの質問に答える: 完了したか、完了していないか、そして何が不足しているか。
• 停止することに利害関係がないので、ためらうことはない。

ビルダーと審判は異なるモデルファミリーで実行する。異なるファミリーは無相関の間違いを犯すため、審判はビルダーが見逃しているものを認識できる。

1while :; do
2  agent --model "$BUILD" -p "Task: $TASK. Read first, implement, run the tests."
3  verdict=$(agent --model "$JUDGE" -p "Strict reviewer. Score against every item in rubric.md.
4            Reply exactly 'PASS' or 'FAIL: <what is missing>'.")
5  [[ $verdict == PASS* ]] && break
6done

ルーブリックは具体的で二値にする:

• 良いルーブリック: 「すべてのテストがグリーン、マイグレーション含む、デバッグログなし。」
• 悪いルーブリック: 「良くする。」

拒否権を持つ無関心なチェッカーこそが、ワーカーが疲れて停止しようとした瞬間に実行が崩壊するのを防ぎ、何時間も継続させる唯一の要素である。

すべてのタスク完了時にそれを起動する。そうすれば、グリーンレビューされた作業だけを見ることになる。

実際に使える、さらに多くのループ

目標ループは基本パターンである。いくつかのバリエーションで、実行するであろうほとんどのケースをカバーできる。

1. 検証ループ

アクションを起こし、バリデーターを実行し、失敗をフィードバックして、ゲートがグリーンになるまで繰り返す。

回帰スイープ、型チェック、および任意の決定論的なパス/フェイルに使用する。

2. キューアンドリセットループ

作業を小さなアトミックなタスクのリストに分割する。一度に 1 つずつ処理する。

各タスクの後、エージェントをクリーンなコンテキストにリセットし、次のタスクを取得する。

何時間も実行されるコンテキストは混乱で満たされる。リセットすることで、各タスクをクリーンに保つ。

メモリはエージェントの外部、タスクファイルとコミット履歴に存在する。

1while read -r task; do
2  agent -p "Task: $task. Read first. Implement, then run the tests."
3  npm test -s && git commit -aqm "auto: $task"   # commit only on green
4done < tasks.txt

3. モニターループ

エージェントをシグナルのストリームに向け、重要なものを表面化させる。オープンな課題、失敗したビルド、エラーログ、新しいフィードバック。

あなたが尋ねるのを待たない。読み、トリアージし、報告するか、ドラフト修正をオープンする。

1while sleep 300; do
2  agent -p "Read the last 5 minutes of error logs. If a NEW pattern appears,
3            open an issue with a minimal repro. Otherwise say 'nothing new'."
4done

4. 計画→構築ループ

ループを 2 つのフェーズで実行する。最初に計画パスで、書面による計画を生成し、停止する。

あなたが計画をレビューする。その後、実行パスが承認された計画に従う。

計画を修正するのは安価である。コードを修正するのは高価である。悪い方向性は計画の段階で捉える。

作業を実行するプロンプト

プロンプトは願い事ではない。エージェントにとっては仕様書である。

平凡なアウトプットと優れたアウトプットの差は、ほとんどがこれらの質による。

再利用可能なプロンプトの小さなセットを維持する。5 つでほとんどの重荷を担う。

1. 分解プロンプト（オーケストレーター用）:

1You are the orchestrator. Do NOT write code.
2Break this goal into 3 to 6 bounded subtasks.
3For each one: a one-line brief, the exact files it owns, and its done-check.
4Flag any task that depends on another. Output the list, then stop.
5Goal: <goal>

2. ワーカー指示（スペシャリスト用）:

1You own ONLY these files: <files>.
2Task: <one line>. Done when: <verifiable check>.
3Read those files and their callers BEFORE editing. Change nothing outside your files.
4When done, write a 5-line report to <name>.md, then run the tests.

3. 審判プロンプト（異なるモデルファミリー用）:

1You are a strict, uncharitable reviewer. You did not write this code.
2Score the repo against EVERY item below. A miss is a FAIL.
3<rubric>
4Reply with exactly one line: 'PASS' or 'FAIL: <what is missing>'.

4. 計画優先プロンプト（計画モード用）:

1Produce a written plan for <goal>. Cover: approach, files to touch,
2edge cases, test strategy, and what you will NOT do.
3Write no code yet. Stop after the plan so I can review it.

5. 反映・終了プロンプト（エージェントが行き詰まった場合）:

1You have failed the same check 3 times. Stop repeating the approach.
2Answer in 3 lines: what exactly failed, which assumption was wrong,
3and the smallest different thing to try. Then try ONLY that.

5 つすべてに共通するパターンがある。役割、境界、完了チェック、そして「やってはいけないこと」を明示する。

モデルルーティング: 誰もが尋ねる質問

この質問は通常、選択として捉えられる。高価なモデルを計画に使うべきか、実装に使うべきか。

それは間違ったフレームだ。代わりに、爆発半径（blast radius）でルーティングする。間違いが最もコストがかかる場所を尋ねる。

論理は単純だ:

• 計画の悪い決定は、フリート全体に波及する。
• 境界が定められたテスト済み関数の 1 行のミスは、数分で発見される。
• したがって、エラーが高価で取り返しがつかない場所にリソースを投入し、エラーが安価で封じ込められる場所では節約する。

ルーティングは以下の通り、ティアごとに:

1. 計画、アーキテクチャ、分解: 常にトップティア。最大のレバレッジ、トークン量はわずか。ここで節約することは、最も高価な間違いである。
2. 厳密な仕様による実装: ミッドティア、並列実行。仕様が考えた。テストで検証する。
3. 緩い仕様による実装: トップティア。ギャップを埋めるのは推論であり、安価なモデルはさまざまな方向で間違った推測をする。
4. レビューと判定: 異なるファミリーであり、安価ではない。ここで高価な見落としを捉える。
5. ナビゲーション、検索、要約、分類: 最も安価で最速のモデル。ゼロ推論、高ボリューム。grep にプレミアムレートを支払うことは決してない。

したがって、「安い計画」か「安い実装」かという問いに対する本当の答えは、どちらでもない。

計画とレビューには常にトップモデルを使う。実装は変動する。

異なるモデルファミリーは異なる個性を持っており、それがルーティングに重要である:

• あるファミリーはギャップを埋める。仕様が緩い場合、妥当な仮定をして進み続ける。それは仮定が良好な場合は役立ち、そうでない場合は害になる。
• 別のファミリーは文字通りに解釈する。あなたが言ったことだけを正確に行い、それ以上はほとんど行わない。正確なユーティリティナイフのようなもの。

ギャップフィラーは、作業が自由形式で仕様が緩い場合に使用する。文字通り解釈するモデルは、レビューや正確で明確に指定された変更に使用する。

実装を制御するレバーはあなたの仕様である

• 厳密な仕様は、安価で並列なワーカーを実行する権利を与える。
• 緩い仕様は、ギャップを埋めるために高価なモデルに戻ることを強いる。

構築を安くできるように、計画に正確に投資する。

1 つの落とし穴を指摘しておく。安価なルーティングは各呼び出しの価格を最適化するが、出荷可能でマージ可能なアウトプットを生み出すトークンの割合を静かに破壊する可能性がある。

5 回リトライしてマージできないコードを生成する安価なモデルは、プレミアムモデルによる 1 回のクリーンパスよりも高価である。

有用なアウトプットのコストを測定し、呼び出しあたりのコストを測定してはならない。

スケールのために、2 つの数値が役立つ:

• トップティアは、安価なティアのトークンあたりの出力価格の約 5 倍のコストがかかる。
• ティア別ルーティングは、通常、最高のモデルをすべての場所で実行する場合と比較して、支出を 40% から 60% 削減する。

スキル: ワークフローを一度パッケージ化し、永久に再利用する

同じプロンプトを貼り付け続けたり、同じワークフローを実行し続けている場合は、それをスキルに変換する。

スキルとは、エージェントが関連する場合にのみロードする小さな指示ファイルである。

ワークフローを一度作成すれば、すべてのエージェントがそれを利用できる。

スキルファイルには 2 つの部分がある:

• 名前と説明を持つ YAML フロントマター。
• 実際の指示を含むマークダウンボディ。

説明は最も重要な行である。スキルが何をするか、そして正確にいつ使用するかをエージェントに伝え、あなたが名前を付けなくてもエージェントが自主的にそれを選択するようにする。

最小限のスキルファイル:

1---
2name: thermonuclear-review
3description: Deep, adversarial code review. Use after any non-trivial change,
4  or when asked to review, audit, or harden a diff before merge.
5---
6
7# Thermonuclear review
8
9Read the full diff and the files it touches. Do not skim.
10
11Review in three passes:
121. Correctness: logic errors, edge cases, race conditions, off-by-ones.
132. Safety: injection, auth, secrets, unsafe input, destructive operations.
143. Fit: does it match the existing architecture, or bolt on a new pattern?
15
16For each finding: file, line, severity, and the one-line fix.
17End with a verdict: SHIP or BLOCK, plus the top 3 things to fix first.

優れたスキルのルール:

1. ファイルは短く保つ。数百行未満にする。長い参照資料は、スキルが指し示す別のファイルに移動する。
2. 名前をそのフォルダと一致させる。そうしないとロードされない。
3. 説明はトリガーのために書く。「使用するケース」を具体的に記述する。
4. エージェントにスキルを書き換えさせてはならない。人間がすべての行をキュレーションする。

スキルはワークフローが複利的に成長する方法である。何かをうまく解決した最初の時にそれを保存し、発見可能にする。それ以降のセッションでは、それは無料で使える。

多数の実行: フリート

1 つのループが機能したら、スケールアウトする。

各ワーカーに 2 つのものを与える:

• 独自の git ワークツリー。これにより、2 つのエージェントが同じファイルに触れることがなくなる。
• 独自のターミナルウィンドウ。これにより、監視とメッセージ送信が可能になる。

1tmux new-session -d -s fleet
2for name in hilbert gauss poincare; do
3  git worktree add -B "agent/$name" "../wt-$name" main
4  tmux new-window -t fleet -n "$name" -c "../wt-$name" "$AGENT"
5done

• エージェントに名前を付ける。15 のエージェントを実行している場合、"agent_7" は役に立たない。
• 名前を付けることで、フリート全体を頭の中で把握できる。このエージェントはデータレイヤーを担当、あのエージェントは評価を記述、別のエージェントはレビューを行う。
• 可読性が重要である。追跡できないフリートは、操縦できないフリートである。
• そして、それらを協力させる。デフォルトでは、エージェントは互いを無視し、兄弟からのものはすべてバックグラウンドノイズとして扱う。

秘訣は、エージェント間のメッセージをユーザーターンとして配信することである。モデルはユーザーに応答するように訓練されており、周囲のシグナルはほとんど無視するように訓練されている。

1send() { tmux send-keys -t "fleet:$1" "$2" Enter; }
2send hilbert "GET /search?q= returns [{id,title,url}]. Wire the UI to it."

そのひとつの動きで、孤立したプロセスの集まりが、コントラクトを引き継ぎ、互いのブロックを解除するチームに変わる。

あなたはトップに留まる。リードにメッセージを送り、リードがワーカーに中継する。

動的ワークフロー: 調整をコードにコンパイルする

ループは調整をモデル内に保持する。モデルが各ステップを決定し、トークンを消費し、コンテキストを埋める。

動的ワークフローはそれを反転させる。オーケストレーターはワーカーを調整するスクリプトを作成し、別個のランタイムがスクリプトをバックグラウンドで実行する。

重要なアイデアは、状態がどこに存在するかである。ループ、分岐、中間結果は、モデルのメモリではなく、スクリプトの変数に存在する。

それがもたらすもの:

• 調整コストはゼロモデルトークン。なぜなら、プレーンなコードがそれを行っているからである。
• メインコンテキストはクリーンに保たれる。最終結果のみが戻ってくる。
• 幅広くファンアウトする。一度に数十のワーカー、実行全体で最大 1,000。

いつ使用するか:

• パターンが既知であり、検証が客観的である場合。
• 作業が広範かつ反復的である場合。多くのファイル、多くのケース、多くのエンドポイント。
• 無人で実行できる場合。

いつ使用しないか:

• まだ何をすべきかを模索している段階である場合。それは目標ループであって、ワークフローではない。
• タスクが 1 つの首尾一貫した推論チェーンを必要とする場合。それは 1 つの強力なエージェントを必要とし、1,000 ではない。

具体的な形。200 のファイルを新しい API に移行する必要があるとする:

1// the orchestrator writes this once; a runtime runs it, not the model
2const files = await glob("src/**/*.ts");
3
4const results = await mapLimit(files, 16, async (file) => {
5  const r = await subagent(`Migrate ${file} to the new API. Run its tests.`);
6  return { file, ok: r.testsPassed };
7});
8
9const failed = results.filter(r => !r.ok);
10return `migrated ${results.length - failed.length} of ${results.length}. ` +
11       `retry: ${failed.map(f => f.file).join(", ")}`;

これが何をするか読んでみよう:

1. 200 のファイルをモデルヘッドではなくコードでリストする。
2. 一度に 16 のサブエージェントを実行し、各エージェントが 1 つのファイルを移行してテストを実行する。
3. ファイルごとにパス/フェイルをプレーンな配列に記録する。
4. 1 つの短いサマリーを返す。200 の中間トランスクリプトは決してあなたのコンテキストに触れない。

それが要点である。モデルは一度だけ考えて、スクリプトを作成した。スクリプトは無料で調整を行った。

ガードレール: フリートが自らを食いつぶすのを防ぐもの

人間のボトルネックは、かつて実際の作業を行っていた。人間の速度では、ミスは早期に害を及ぼし、進みながら修正する。

あなた自身を完全に取り除くと、小さなエラーは感じられるよりも速く複合する。ここでの重複、あそこでの不要な抽象化。

ある日、アーキテクチャは曲がらなくなり、エージェントもテストを作成したため、テストは信頼できなくなる。

以下のすべてのガードレールは、ボトルネックがかつて提供していた修正を置き換える:

1. 推測する前に読む。すべての構築プロンプトで、タスクごとの嘆願ではなく、常設のルールにする。
2. 上限設定と強制終了。すべてのループに反復制限を設ける。すべてのエージェントにトークンバジェットを設定し、85% 付近で自動一時停止させる。同じエラーで 3 回スタックした反復の後、エージェントを強制終了し、タスクを新しいエージェントに引き継ぐ。
3. 1 ファイル、1 オーナー。ワークツリーで分離する。2 つのエージェントが同じファイルを編集することは決して許さない。
4. ミッションを再注入する。長時間の実行では、数分ごとにチェックリストをユーザーメッセージとして投稿し、エージェントがコンテキストの充填に伴って漂流しないようにする。

1while sleep 900; do
2  send gauss "REMINDER: still on task? Read first. Run tests after each change. Stay in your files."
3done &

そのすべての下にある最も深いポイント:

• 検証が今やボトルネックであり、生成ではない。
• エージェントは、あなたがチェックできるよりも速く、もっともらしいアウトプットを生成する。
• もっともらしいことは正しいことではない。

検証が生成と同じくらい速くなるまで、人間のレビューはオーバーヘッドではない。それは安全システムである。

メモリ: あなたが長期記憶である

モデルは短期記憶、つまりコンテキストウィンドウを持っており、それ以外には何もない。そのウィンドウを超えたものは、あなたが保持しない限り消える。

したがって、あなた自身と、あなたが保持するファイルを、短期記憶しか持たないエージェントのための長期記憶として扱う。

2 つの習慣が重要である。

第一に、要約ではなく参照渡しで状態を渡す:

• コンテキストが満たされた場合、怠惰な修正はそれを要約することである。要約は損失が多く、後で必要になる詳細を削除する。
• 代わりに、エージェントをファイル、タスクレコード、および再読み取りできる以前の出力に向ける。重要なものが静かに捨てられることはない。

第二に、耐久性のあるメモリをエージェントの外部に保持する:

• ステータス付きのタスクファイル。
• 進行中の進捗ログ。
• コミット履歴。
• パターンと落とし穴を収集する長期メモファイル。

エージェントが何日も実行されることを想定して設計する。適切なコンパクションがあれば、彼らはそうするからである。

モデルはまだこれについて自覚していない。彼らは、トークンを費やすことが致命的であるかのように、すべてを 1 つの短期予算内で解決するというバイアスを抱えている。あなたの足場（スキャフォールディング）こそが、糸を見失うことなく長時間実行させるものである。

トポロジー: 何人のエージェントを、どのような形状で

エージェントの数が多いほどアウトプットが多いわけではない。ある点を超えると、調整は無料ではなく、エージェントを追加するたびに複合的に増加するため、アウトプットは減少する。

重要なルールは、作業に合わせて形状を合わせることである:

• 逐次的で依存関係のある推論は、より少ないエージェント、時には 1 つを必要とする。単一の思考連鎖を分割すると、推論が断片化し、結果が低下する。
• 独立した並列作業は、ファンアウトさせる。フラットなトポロジー、クリーンなファイル所有権。ここで並列性が効果を発揮する。
• 調整されたチームは、3 人から 5 人のワーカーを必要とする。トークンコストはサイズにほぼ比例する。調整コストはより悪いスケールで増加する。3 人の集中したワーカーは、5 人の散漫なワーカーに勝る。

では、どうやって何百ものエージェントを実行するのか？1 つの巨大な会話が自分自身と議論しているのではない。

それらは、深さと独立性として実行される:

• あなたが実際に話す少数のエージェントがいて、それぞれが調整を必要としない境界のあるサブタスクに委任する。
• 独自のことを行い、報告する独立したループの群れ。

スケールは、委任の深さと独立性から生まれる。単一のスレッドを広げることからは決して生まれない。

制御ファイル: orchestration.md

あなたはおそらく、リポジトリ内のエージェントにコードの書き方を指示するファイルを保持しているだろう。スタイル、落とし穴、アーキテクチャ。それらを維持する。

しかし、それはオーケストレーションにとって間違った質問に答えている。

orchestration.md ファイルは別の質問に答える。ここでは、どのように作業を実行すべきか？

これは、人間が作成した契約であり、以下をカバーする:

• どのタスクにどのモードを使用するか
• どのモデルティアをどこに配置するか
• ガードレールは何か
• いつ人間にエスカレーションするか

すべてのエージェントは、すべてのセッションの開始時にそれを読み、それを使用して自身のアプローチを自己選択する。

これはリポジトリ内で最もレバレッジの高いファイルである。モード選択の決定を、あなたが毎回一貫性なく行う頭の中から、フリートが従う仕様に移す。

短いバージョンは次のようになる:

1# orchestration.md. How work is RUN here. Human-curated. Agents must not edit.
2
3Pick the mode:
4- Goal loop (supervised): fuzzy or design work. Define the completion check.
5- Validation loop: deterministic gate. Always cap iterations and cost.
6- Build plus judge: worker builds, a different-family judge approves.
7- Fleet (three to five): interdependent subtasks, isolated worktrees, peer messaging.
8- Queue and reset: many small atomic tasks, fresh context each.
9- Dynamic workflow: known pattern, objective gate, wide and repetitive. Coordination in code, unattended.
10
11Route models by blast radius:
12- Planning and architecture: top tier, always.
13- Build, tight spec: mid tier, parallel, verify with tests.
14- Build, loose spec: top tier, because gap filling is reasoning.
15- Review and judge: a different family. Never the implementer's model.
16- Nav, search, summarize: cheapest. Optimize mergeable output, not call price.
17
18Guardrails:
19- Per-agent token budget. Auto-pause near 85%. Kill and reassign after 3 stuck tries.
20- Any run over an hour needs a separate judge. Workers never self-report done.
21- Read code before hypothesizing. Plan in writing before the first edit.

ファイルを支配する 2 つのルール:

1. 短く保つこと。
2. エージェントにそれを書き換えさせてはならない。

価値は、人間がすべての行をキュレーションしたことにある。

あなたの手元に残るもの

オーケストレーションは、エージェントを実行において信頼できるものにする。それは問題を選択するわけではなく、良い状態がどのようなものかを知っているわけでもない。

3 つのことが、恒久的にあなたの側の線にとどまる。

第一に、判断ではなくタスクを委任する:

• エージェントには、明確なパス/フェイル基準を持つ範囲を定めた作業を渡す。ボイラープレート、マイグレーション、テストの足場、そして手作業では試す時間が決してないであろうアプローチ。
• アーキテクチャ、構築しないものの決定、および全コンテキストでのレビューはあなた自身のために残す。
• エージェントはひどいアーキテクチャの海を吸収しており、そうあるべきではないプロジェクトに重厚長大なパターンを喜んでカルゴカルト的に持ち込むだろう。「ノー」と言うことは、彼らが持っていない機能である。

第二に、あなたの仕様がレバレッジである:

• 複数のエージェントを展開する場合、曖昧な思考は単に速度を落とすだけでは済みません。それが何倍にも増幅されます。
• あいまいな要件が 1 つあると、それが数十の並列実行に伝播し、それぞれが独自の方向へと誤った結果を生み出します。
• 正確な仕様は、どこでも正確な実装へと増幅されます。

だからこそ、優れたエンジニアはこれらのツールからより多くの成果を得られるのです。タイピングは自動化され、理解は増幅されました。

最初の編集を行う前に、全員が合意する計画を文書化し、計画モードでほとんどの時間を費やしてください。

第三に、意図的にリソースを不足させること:

• 4 エージェントのジョブに 2 人を割り当てます。制約によって、望ましい行動が強制的に生まれます。
• 手作業で行う代わりにループを構築し、次回はその作業が既に自動化されている状態にします。
• 予算を手作業の労力からトークンへとシフトします。初期投資は高いですが、その後は限界費用がほぼゼロになります。

これを実践するチームは、成果が複利的に積み上がります。実践しないチームは、毎回フルプライスを支払うことになります。

あなたはもはやソフトウェアを書いているのではありません。ソフトウェアを書く工場を建設しているのです。

工場には、正確なインプット、各工程での品質管理、そして製品がどうあるべきかを理解している責任者が必要です。

ここから始めましょう

月曜日にいきなり 100 のエージェントを実行しようとしないでください。階段を一段ずつ上りましょう:

1. 検証可能なゴールラインのあるタスクで、1 つの目標ループを実行します。適切な完了チェックとはどのようなものかを学びましょう。
2. 1 時間を超えるタスクには、異なるモデルファミリーからの判定エージェントを追加します。自己申告による完了を禁止します。
3. orchestration.md を作成します。エージェントにそれを最初に読むように指示します。エージェントがあなたのためにモードを選択し始めるのを見守りましょう。
4. 慎重に展開します。1 つの並列化可能なタスク、3 ～ 5 人のワーカー、分離されたワークツリー、トークンバジェットを設定します。
5. モデルをルーティングします。計画とレビューには最上位層、限定的なビルドと反復作業には安価な層を使用します。マージ可能な出力を測定します。
6. パターンが検証され、客観的にチェック可能になったら、無人で実行させます。夜間にバックログを処理します。

システムは完璧である必要はなく、方向性が正しければ十分です:

• 制御ファイルが、エージェント群が自己判断で行動するための十分な構造を提供します。
• 判定エージェントがエッジケースをキャッチします。
• リマインダーループがメモリを管理します。
• あなたのセンスが、委任できない判断を処理します。

プロンプティングは昨年のスキルでした。これが今のスキルです。

ここに記載されているすべてのシステム（目標ループ、判定ループ、フリートランチャー、メッセージバス、リマインダーウォッチドッグ、モデルルーター）の実行可能バージョンは、コンパニオンキットに含まれています。1 つの変数をエージェント CLI に設定して、すぐに始められます。

免責事項

本記事は、著者による Claude Code セッションと codex セッションを使用して作成されました。

文法的およびフォーマット上の問題については、著者と Kimi K2.6 モデルによって編集されました。