Fable を使用して 40 個のサブエージェントで大規模プロジェクトを編成する方法

先週、@HelloUntangle で、私たちは社史上最大かつ最もリスクの高いエンジニアリングプログラムを完了しました。

• 834 ファイル
• 本番データの変更
• DB スキーマの更新
• 31 件の PR
• 金曜日開始 → 月曜日完了
• 本番インシデントゼロ

すべて、たった一つの Fable 親オーケストレーターセッションで実現しました。

一つの親 @DevinAI セッションが作業を計画し、40 の子セッションを生成して実行させ、各フェーズ間でリグレッションゲートとバックアップチェックを実施し、真にオーナーの判断が必要な決定、すなわちスコープの判断と不可逆的なステップのゴー/ノーゴーのみを私に提示しました。

これを成功させたのは、大規模な移行を改善する一連の プログラム管理パターン です。

その方法をご紹介します。

アーキテクチャ: 1 つのオーケストレーター、多数のワーカー

• 1 つの親セッション がプログラム全体をエンドツーエンドで管理しました。その唯一の役割は、計画、子セッションの生成、出力のレビュー、フェーズの順序付け、そして人間の判断が必要な決定を私にエスカレーションすることでした。コードは一切書きませんでした。
• 約 40 の子セッション が実際の作業のすべてを実行しました。フェーズ 0 での 11 の並行監査セッション、各ウェーブの実行セッション、そしてリグレッションスイートの実行のみを担当する専用のゲートランナーセッションです。

この分割が重要なのは、長期プロジェクト（AI であれ人間であれ）の失敗モードが コンテキストの崩壊、つまり作業を実行する主体がプログラム全体の全体像を見失うことだからです。

親を純粋なオーケストレーターに保つことで、そのコンテキストはクリアに保たれます。計画、スコープの決定、各ウェーブの状態を保持します。各子セッションは、正確に一つのジョブを持つ、新しく焦点を絞ったコンテキストを得ます。

成功を支えた 7 つのパターン

1. まず監査し、その結果を単一のマニフェストに固定する

フェーズ 0 は 11 の並行監査セッションで、それぞれがコードベースの一部（アプリルート、API ルートと cron、データベーススキーマ、共有ライブラリとワークフロー、スクリプトとドキュメント）を担当しました。それらの結果は一つのファイルに統合され、リポジトリにコミットされました。

マニフェストは、コードの各ユニットに判定とウェーブ番号を割り当てます。2 つのルールがこれを強力にしました。

• どのワーカーもスコープを再検討しない。 すべての実行プロンプトは、事実上、マニフェストが唯一の情報源であると指示しました。これがなければ、40 のセッションのそれぞれがスコープについて独自の意見を持ち、それらは一致しません。
• UNKNOWN は停止して問い合わせることを意味する。** 監査で触れられていないものはすべて明示的に unknown とマークされ、「推測するな、判断を仰げ」という指示が付されました。オーナーの判断は直接マニフェストに記録され、後のセッションがそれを継承できるようにしました。

2. 作業を都合ではなくリスクで順序付ける

ウェーブは、最も安全なものから最も不可逆的なものへと順序付けられました。

ウェーブ

内容

リスク

0

監査 + マニフェスト + 復元ポイントの git タグ

なし

1

ライブな依存関係がないことが確認された変更

ほぼゼロ

2

共有インフラストラクチャの絡み合い解消作業

中

3–4

コード変更の大部分

中

5

本番データの変更（ドライランインベントリ + スナップショット付き）

高

6

スキーママイグレーション

高

7

依存関係の整理、agents.md の書き換え、エージェント知識ベースの監査

低

本番データの変更（ウェーブ 5）はスキーマ変更（ウェーブ 6）の 前 に行われ、両方とも、影響を受けるテーブルに触れるすべてのコードパスが検証可能な形で更新された後にのみ実行されました。マイグレーションが実行される頃には、古い状態に依存しているものは何もなくなっていました。

3. ファイルの重複しない境界が並列処理を安全にする

ウェーブ内では、子セッションは並行して実行されました。あるウェーブでは、4 つのセッションが同時にツリーの異なる部分を処理しました。その規律は、すべてのプロンプトに明示的なファイル境界が含まれ、それらの境界が重複しないことでした。マージコンフリクトも、同じファイルを編集する 2 つのエージェントも、子セッション間の調整も一切不要でした。

これは古典的なタスク分解であり、エンジニア間で作業を分割するのと同じことですが、エージェントの場合は、毎回プロンプトに 明示的に 記載する必要があります。

4. ウェーブ間の安全ゲート

前のウェーブがゲートを通過するまで、次のウェーブは開始されませんでした。ゲート自体も子セッションでした。

• ブラウザ駆動のエンドツーエンドリグレッションスイート がプラットフォームのコアカスタマーワークフローをカバーし、ウェーブ 2 の後、およびウェーブ 3–4 の後に、新しい独立したデータベースブランチ上で実行されました。
• 本番データ変更の前: 専用セッションがデータベースバックアップインベントリ（数、日付範囲、保持期間）を監査し、新しいポイントインタイムスナップショットを取得しました。
• 本番ステップ自体は 最初にドライラン を実行し、オーナーの承認のために行数を提示し、実行後に行数を再確認しました。
• git タグは、変更されたすべての行の復元ポイントを示します。

ゲートが失敗すると、スコープを絞った修正セッションが生成されました。例えば、リグレッションスイートは、過剰に積極的な変更によって壊れたカスタマー向けフローを検出しました。1 つの修正セッションが数時間以内にそれを復元しました。これはシステムが機能している証拠です。ゲートは、顧客から報告されるバグを、当日中に修正される問題に変えたのです。

5. 人間が承認し、エージェントが提案する

このプロジェクトで、私はコードを書いたり、マイグレーションを実行したり、本番スクリプトを実行したりすることは一切ありませんでした。しかし、すべての不可逆的なステップには私の明示的なゴーサインが必要でした。main への各マージ、本番データの変更、スキーママイグレーション、そして UNKNOWN スコープ項目に対する各判断です。

破壊的な作業のパターンは次の通りです。エージェントがインベントリを提案し、人間がそのインベントリを承認し、その後エージェントがそのインベントリを正確に実行する。 本番セッションは、何かに触れる前に、触れる行の正確なリストを作成しました。私は漠然とした意図ではなく、具体的な リストを承認しました。

6. 予期せぬ事態に対するエスカレーションプロトコル

子セッションには、現実がマニフェストと一致しない場合の対処法が指示されていました。停止し、親に報告し、場当たり的な対応をしないことです。実際の例:

• 監査で安全とされたモジュールに、別の場所にライブな依存関係があることが判明 → 子セッションがそれをフラグし、そのユニットは絡み合いを注記した上で後のウェーブに降格されました。
• 2 回目の監査ラウンドで、5 つの領域全体に対する 1 回目の判定が覆されました → 覆された内容は、それに遭遇したセッションがその場しのぎで解決するのではなく、明示的なオーバーライドとしてマニフェストに書き込まれました。

親はこれらの予期せぬ事態を計画に吸収しました。個々のワーカーがスコープの決定を下すことはありませんでした。

7. キャンプサイトをきれいに保つ: 何が変わったかをシステムに教える

ウェーブ 7 は最も過小評価されているフェーズかもしれません。変更がリリースされた後、セッションは AGENTS.md、リポジトリスキル、エージェント知識ベースを書き換え、新しいアーキテクチャを説明しました。これにより、将来の すべての エージェントセッションが、古い指示ではなく、真実からスタートできるようになります。エンジニアリングがエージェント駆動型であれば、ドキュメントは重要なインフラです。

かかったコスト

プログラム内のすべてのセッションはタグ付けされていたため、台帳は完全です。1 つの親と 39 の子、すべて Devin の Ultra Agent 上で、金曜日の午後から月曜日の朝まで。これらは、使用状況ダッシュボードからの実際の計測コストです。

フェーズ

セッション数

コスト

親オーケストレーター（複数日）

1

$115.26

フェーズ 0 監査（2 ラウンド）+ マニフェスト統合

12

$85.56

ウェーブ 1

4

$37.55

ウェーブ 2（絡み合い解消）

4

$299.34

ウェーブ 2–4 リグレッションゲート + 修正

4

$244.69

ウェーブ 3–4

5

$130.84

ウェーブ 5（本番）+ バックアップ監査

2

$15.20

ウェーブ 6（スキーママイグレーション）

3

$118.83

ウェーブ 7（依存関係、ドキュメント、知識）+ 最終ゲート

4

$96.64

インフラストラクチャ修正

1

$11.47

合計

40

$1,155.38

内訳で際立つ 3 つのポイント。

1. マニフェストを作成した 12 セッションの監査フェーズ全体のコストは 90 ドル未満で、これまでに購入した中で最も安価な保険でした。
2. 最も高額な項目は、まさに難しい判断が求められた場所、つまり絡み合い解消（$299）と、すべての整合性を保ったリグレッションゲート（$245）に集中しています。
3. 最もリスクの高いステップである本番データ変更のコストは 15 ドルでした。なぜなら、それが実行されるまでに、すべてのリスクはすでにエンジニアリングによって排除されていたからです。

注: Devin がサブエージェントに別のモデルを選択することを許可していれば、このプロジェクト全体のコストはさらに低く抑えられた可能性があります。コーディング作業の大部分は、gpt 5.5 や opus 4.8 でも問題なく完了できたでしょう。Fable にサブエージェントのタスクに適したモデルを選択するよう指示するのは簡単です。

しかし、それができなかったとしても、1,000 ドルは完了した作業に対して信じられないほど安く、そしてその作業が完了し検証された 速度 は、まさに「すごい」の一言です。

https://x.com/ryancarson/status/2072694425365426344

まとめ

重要なのは、AI が大量のコードを書いたということではありません。適切に指定された変更を実行するエージェントは、今や当然のことです。

重要なのは、プログラム管理自体が委任された ということです。分解、順序付け、並列化、ゲート、エスカレーションのすべてがオーケストレーター内で実行され、人間の役割は、まさにオーナーが必要な決定のみに圧縮されました。

これを試すなら、ツールではなくパターンを盗んでください。

1. まず監査し、結果をマニフェストに固定し、どのワーカーも再検討できないようにする。
2. ウェーブをリスクで順序付け、不可逆的なステップは最後にする。
3. 並行ワーカーには明示的に重複しないファイル境界を与える。
4. すべてのウェーブを実際のリグレッションスイートと実際のバックアップでゲートする。
5. 破壊的な変更の前に提案されたインベントリを要求し、アイデアではなくリストを承認する。
6. 予期せぬ事態が発生する前にエスカレーションパスを定義する。
7. プロジェクトの一部として、後回しにせずにドキュメントとエージェント知識を更新する。

それでは、楽しいオーケストレーションを！ :)