Loop Engineering の後継：ワークフローであなたのエージェントを 10 倍広く動かす方法
マルチステップエージェントを構築するほとんどの人が、たどり着くのは 直線 です。
ステップ 1、ステップ 2、ステップ 3。それぞれが前の処理の終了を待ってから始まります。
ほとんどの人が確認しないことがあります：
あのステップの半分は、待つ必要なんてなかった
彼らはただ、一度に一つのジョブをキューに入れ、コンテキストウィンドウがいっぱいになってエージェントが自分のやっていることを忘れるまで、それを続けます。
- 遅かったのはモデルが弱かったからではありません
- 遅かったのは、あなたが、作業が グラフ であるべきところに、直線を引いたからです**
このガイドでは、その直線から、複数のエージェントに展開し、自分自身の作業をチェックするグラフへと導きます。
5 つのステップ。ステップ 2 までに、あなたは一つを構築できます -
このガイドでは、動作するグラフを手に入れ、実際のグラフを壊す落とし穴の名前を挙げ、困難な部分がどこから始まるかを示します
アルファ版の前に - より新鮮なアルファ情報については、私の Substack を購読してください ↓
第 0 章 - グラフエンジニアリングとは実際には何か
1 ヶ月前、この分野は ループ について話題にしていました。
ピーター・スタインバーガーはそれを 9 つの言葉で捉えました：
https://x.com/steipete/status/2078277297791189132
ループとは、より良くなるための 1 サイクルです：
何かを試す → 結果を確認する → 調整する → もう一度行う
それが原子です：1 つのエージェントが 1 つのことを繰り返し改善する
(私の Loop Engineering の記事を読んだことがあれば、それがこれです)
https://x.com/0xCodila/status/2072329149520232639
しかし、単一のループには既知の欠陥があります - 。サポートチームがフィードバックループを 1 つの指標に結びつけます：チケット解決率
数値は何ヶ月も上昇する一方で、満足度は低下します。ボットは問題を解決する代わりに、チケットを早く閉じることを学習しました。
それが グッドハートの法則 です。ループは自分の指標しか見ることができません。目標が正しいかどうかを問いかけたり、自分の測定値がずれていることに気づいたりすることはできません。
答えは、より良いループではありません。それはループのグラフです - サイクルが互いに監視し、修正し合うネットワークです。
エージェントにとって、それは 1 つのことを意味します：
1 つのエージェントにすべてを直線で実行させるのをやめて、作業の「形状」を設計しましょう - 何が何の前に実行され、何が同時に実行され、何が待つのか。
ノードが思考を行います。エッジが結果を運びます。
そして、Claude Code はこれらを直接構築するためのツールを出荷しました：動的ワークフロー
ステップ 1 - 存在しないエッジを見る
グラフには 2 つの部分があります：
- ノード は 1 つの作業単位です：1 つのエージェント、1 つのジョブ、1 つの入力、1 つの出力
- エッジ は依存関係です：このノードの出力が、あのノードの入力に供給されます
誰もが犯す間違いは、「そして次に」をエッジとして扱うことです。
"このファイルを要約して
そして次に
天気を教えて"
天気は要約を読みません。
これらは 2 つの独立したジョブであり、リニアなスクリプトが理由もなく連鎖させています。それぞれが、何のためでもなく前の処理を待っています。
すべてを始める習慣：
すべての「そして次に」に対して、次のように自問してください - 次のステップは、実際に前のステップの出力を読み取るのか？
- はいの場合 → 本当のエッジ。順序を維持します。
- いいえの場合 → エッジなし。待機は無駄です。それらを並行して実行します。
2 つのボックスの間でデータが渡らない場合、それらは独立しています。
この独立性こそ、このガイドの残りの部分で活用するものです。
あなたの単純な「A を実行し、次に B、次に C」というエージェントは、すでにグラフです - ただ最も哀れなものです：C が停止すると、D が決して起こらない単一のチェーンです。
ステップ 2 - 最初のグラフを構築する（最初から最後まで）
理論は十分です。一つ構築して、それが動くのを見てみましょう。
始める前に：
- Claude Code v2.1.154+（claude --version で確認）
- 有料プラン。 Max、Team、または Enterprise プランでは、ワークフローはデフォルトで有効です。Pro プランでは、/config で 動的ワークフロー 行をオンにしてください。
1. 知っているリポジトリを開きます。
実際のリポジトリで、結果に意味を持たせます。
2. このプロンプトを貼り付けます（Anthropic 提供）：
1src/routes/ 配下のすべてのルートファイルに対して、認証チェックの欠落を監査するワークフローを作成します。ファイルごとに 1 つのエージェントを起動し、各発見事項に対して独立した検証エージェントを実行してから報告します。まずは最大 20 ファイルを分析します。
src/routes/ を、あなたのファイルが存在する場所に置き換えてください。「最大 20」という行は、最初の実行を低コストに抑えます。
3. 「ワークフロー」が起動するのを確認します。
Claude Code はそれを強調表示します：「動的ワークフローが要求されました。」 これは、通常のチャットではなく、グラフが構築されているという合図です。
4. 計画を承認します。
Claude は JavaScript オーケストレーションスクリプトを作成し、最初にフェーズを表示します。それらを読み、「はい、実行します」を選択してください。
5. エージェント群を実行させます。
ファイルごとに 1 つのエージェントが並行して実行され、その間セッションは空いたままになります。
/workflows と入力して、ライブで確認します：スコープ、ファンアウト、検証、統合。
6. 1 つの回答を読みます。
20 の個別のチャットではありません。1 つのレポートです - 中間結果があなたのコンテキストではなく、スクリプトの変数に存在していたからです。
それがグラフです。
1 つの文章から、12 のエージェントが生まれました。
「ゼロトークン」という主張について聞くかもしれません
調整スクリプトはコードです
そのため、エージェント間で結果を渡すことは、チャットの引き継ぎのようにコンテキストを再消費しません。
しかし、エージェントは依然として使用量を消費します。 ワークフローは、通常のセッションよりも 著しくコストがかかります。
節約は調整にあり、作業自体にはありません。スコープを絞って開始し、使用量を監視し、その後で範囲を広げてください。
- 自分好みにカスタマイズする
実行がうまくいったら、s キーを押します。
~/.claude/workflows に保存され、名前で再実行可能になります。
次に、タスクを変更して形状を維持します。「認証チェックの欠落」を「未処理の Promise」や「100 行を超える関数」に置き換えてみてください。
これがどこまでスケールするか（記事タイトル）
1 回のワークフロー実行で、最大 1,000 のエージェント にファンアウトでき、最大 16 が同時に動作します。
これが「1 つのウィンドウで 1000+ ループ」の由来です - 比喩ではなく、機能の実際の上限です。
- そして、このスケールこそが重要です 1,000 のエージェントは、単一のコンテキストでは決して保持できないジョブを意味します - コードベース全体を一度に監査する、すべてのファイルに触れる移行、1,000 の角度を並行して実行する検索
16 の同時実行制限は、エージェント群が波のように移動し、あなたが一つ一つ監視することなく、1,000 すべてを処理することを意味するだけです。
実行の動作とコストを確認するために 20 から始めてください - その後、範囲を広げてください - なぜなら、これが他の誰も挑戦していない天井だからです
ステップ 3 - 実際に問題を引き起こす部分
グラフを構築しました。ここで、実際のグラフがどこで失敗するかを示します。
最も重要な 2 つの失敗があります
- 失敗 1: グラフが自分自身と同意する
エージェントが自分の作業をチェックするとき、自分に甘くなります。 モデルは自分の出力を好みます。
そこで、エッジ上に検証エージェント を配置します - 発見事項が下流に流れる前に確認する、別のノードです。
誰も名指ししない落とし穴：検証エージェントはクリーンなコンテキストを必要とします
実行エージェントと同じ会話を検証エージェントに渡すと、それは検証していません。それは別のフォントで自分自身に同意しているだけです。
1 つのコンテキストを共有するエージェントのグラフは、コスチュームを着た単一のループです。それは同じように失敗します - 後で、より高くつき、下り坂でより多くの青信号をともしながら。
したがって、検証エージェントは 新しいノードです - 独自のコンテキスト - 実際のシグナル をチェックします - 「エージェントが完了したと言ったか」ではなく、「テストが実際にパスするか」です。
- 失敗 2: エージェントが互いに干渉する
これは仮定の話ではありません
Bun のチームが初めて大規模な移植を多くのエージェントにファンアウトしたとき、実行は 運用上失敗しました 。そして、エージェントが 1 つのワークスペースで共有の git コマンドを使用し、互いに上書きしてしまいました。
修正は構造的なものであり、巧妙なプロンプトではありませんでした。彼らは安全でないコマンドを禁止し、各グループに 独自の独立したワークツリー を与えました。
これが並列処理の本当の教訓です - 同じファイルに書き込む 2 つのエージェントは競合します。
ファンアウトする前に、3 つの質問に答えてください：
- 各エージェントはどこで作業しますか？
- 結果はどのようにマージされますか？
- 2 つが同意しない場合はどうなりますか？
その計画のないグラフはスケールしません - より速く失敗します。
ステップ 4 - 今週構築する 6 つのグラフ
方法：実際のエッジを見つける → ファンアウトする → 独立したコンテキストで検証する → ワーカーを分離する
///
これらのそれぞれは、新しいジョブを対象とした、同じ形状です。タスク行を変更して実行してください：
- セキュリティスイープ - 認証の欠落を探すファイルごとのエージェント、各ヒットを確認する検証エージェント（あなたが構築したもの）
- /deep-research を使用した引用レポート - すでに出荷済み：質問を角度に分割し、並行して検索し、エージェントが執筆前に互いに反論します
- モジュールの移植 - ファイルごと、テストをゲートとして、失敗はループバック
- 敵対的差分レビュー - サイズでルーティング：小さな変更 → 1 回のパス；大きな変更 → 完全な並行監査
- スケジュールされたエコシステムスキャン - 一度保存し、名前で再実行
- 未知のサイズの発見 - ファインダーが並行して実行され、各結果がこれまでに見られたすべてと照合され、2 ラウンドで新しいものが見つからなくなるまでループします
///
天井の様子https://simonwillison.net/2026/Jul/8/rewriting-bun-in-rust/
Bun の Zig から Rust への移植は、まさにこの仕組みで実行されました。
約 50 のワークフロー、最大 64 のエージェントが並行して動作。約 535,000 行の Zig が、11 日間で 100 万行以上の Rust に変換されました。
また、使用料として約 $165,000 かかりました。全体を設計し監視する人間が必要でした。
そして、これほど多くの AI が作成したコードを安全にレビューできるかどうかについて、公の批判を浴びました。
スケールは本物です。価格と監視も同様に本物です。
ステップ 5 - グラフの誠実さを保つアンカー
トポロジーだけでは真実を買えません
互いに確認し合い、実際の何にも触れないエージェントのネットワークは、単一のループとまったく同じように失敗します - 単により多くの可動部品があるだけです。
グラフには アンカー が必要です：議論できないノードです。
- 実際に実行されたテスト - 「パスするはず」ではなく、パスした もの
- 雰囲気ではなく、証拠に基づく検証エージェント
- エージェントが決して調整することを許可されない凍結されたルール - なぜなら、それらは最適化者が弱体化させるものだからです
グラフは、その中にある動かないものと同じくらい誠実です。
グラフが間違った選択である場合
ほとんどのタスクはグラフではありません。必要ないときにグラフに手を出すと、単にお金を消費し、失敗する方法を増やすだけです。
次の場合はグラフをスキップしてください：
- タスクが小さいか、孤立している場合。 関数の追加、1 つのバグ修正。ワークフローはここでは純粋なオーバーヘッドです - 単一のエージェントの方が高速で低コストです。
- 厳密な監視が必要な場合。 次のステップを実行する前に、すべてのステップを読んで承認したい場合、グラフの要点（あなたなしで幅広く実行すること）は逆効果になります。
- 何を探しているかまだわからない場合。 探索的な作業には、あなたが操縦できる 1 つのエージェントが必要であり、問題を理解する前に計画にコミットするエージェント群ではありません。
- ステップが真に互いに依存している場合。 すべてのステップが前のステップの出力を読み取る場合、それは本当のチェーンです。並列処理は掴むものが何もありません。真に逐次的なタスクにグラフを強制すると、スピードアップがゼロのまま、調整コストが追加されるだけです。
その兆候はステップ 1 です。間に矢印のない 2 つのボックスが見つからない場合、構築するグラフはありません。それはループであり、ループで十分です。
グラフは 幅 のためのツールです - 独立した作業を、一度に行います。
作業が幅広くない場合、直線は問題ではなかったのです...
転換
プロンプターは質問をします。アーキテクトはグラフを描きます。
リニアなエージェントは、決して天井ではありませんでした。
それは最初の形状でした - 私たちがどのようにタイプするかに一致するため、誰もが手を伸ばす形状です：1 行、一度に 1 つのこと。
ノードとエッジが見えるようになると、エージェントに「もっとやれ」と頼むのをやめ、グラフに「もっと幅広くやれ」と頼み始めます：
- 作業が独立しているところではファンアウトする
- 信頼性が重要なところではエッジをゲートする
- 真実を保持するノードを凍結する
ほとんどの人は、ステップを直線にキューイングし続けるでしょう。
グラフを描くこと、そしてそれを壊すものを尊重することを学ぶ少数の人々は、エージェント群を実行するでしょう。
グラフを描きましょう。アーキテクトであり続けましょう。
前提条件から始めてください：
- これが基づいている単一のループ
