AIエージェントを「行列」で作るのをやめる — チェーンではなくグラフとして設計する理由
何の話か：「一列に並べる」という習慣を疑う
AIエージェントの設計を始めると、誰でも最初は同じ形を書く。
ファイルを読む → 要約する → ルールと照合する → レポートを書く
各工程が1プロンプト。前の工程が終わるまで次は待つ。タイプする順番そのままだから自然に見える。短い仕事ならそれで十分だ。
問題は、仕事が長くなったとき、横に広がったとき、そしてエージェントに自分の仕事を採点させたときに起きる。
2026年7月27日にMIKE（@mikenevermiss）氏が公開した記事「Graph Engineering: How to Stop Building AI Agents That Wait in Line」は約22万回表示された。主張の一行要約は元記事自身がこう書いている。
エージェントに工程を足すのをやめて、形を変える。速度・コスト・信頼性を一番大きく左右するのは、モデルではなくトポロジー（グラフの形）である。
これが刺さる人には刺さる一文だ。「モデルを変えれば解決する」と思いながら、実際には設計の形を見直せていないケースが多い。
なぜ今それが重要か：失敗はモデルではなくトポロジーから来る
Anthropicは、1つのコンテキストウィンドウの中でエージェントを長く働かせると起きることを3つに分類している。
| 失敗モード | 何が起きるか | 具体例 |
|---|---|---|
| Agentic laziness（エージェント的な怠惰） | 複雑な多段タスクを途中でやめて「終わりました」と宣言する | セキュリティレビューの50項目のうち35項目だけ見て完了報告 |
| Self-preferential bias（自己優遇バイアス） | 自分の出力を検証・採点させると、自分の結果を好む | 自分で書いたコードのレビューが甘くなる |
| Goal drift（目標のドリフト） | ターンを重ねるうちに元の依頼への忠実さが落ちる | 「Xはやらないで」という制約が最初に失われる |
重要なのは、この3つはどれも工程を足しても解決しないという点だ。一列に並べたまま工程を増やせば、同じコンテキストがさらに重くなるだけ。公式記事の表現を借りれば、ワークフローは「それぞれ独自のコンテキストウィンドウと、焦点の絞られた孤立したゴールを持つ別々のサブエージェント」を編成することで、これらに対抗する。
解決策は形を変えることだ。
事実整理：ノード・エッジ・6つの型
「and then テスト」で偽エッジを炙り出す
グラフの構成要素はノード（境界のある1つの仕事）とエッジ（依存関係）の2つだけだ。設計の混乱の多くは、この2つを混同することから来る。
エッジを本物にするのは「データが実際にそこを渡ること」だけであり、「順序」や「プロンプト内での近さ」はエッジにならない。
自分の書いたチェーンを診断するシンプルな方法がある。工程の間の「そして次に」ひとつひとつについて、「次の工程は前の工程の出力を実際に読んでいるか？」を問う。
元記事の例が分かりやすい。「ファイルを要約して、それから明日の天気を調べて」——この2つの間には何の関係もない。天気は要約を消費しない。独立した2つの仕事を、一直線のスクリプトが勝手に鎖でつないでいるだけで、その待ち時間は何も買っていない。
6つの型
ノードとエッジが明確になると、実際のエージェントシステムはごく少数の形でほぼカバーできる。
-
Fan-out（扇状に広げる）：独立した仕事がN個あるなら、順番待ちさせずに同時に走らせる。失敗した単位はクラッシュではなく空で返すよう設計し、次の段階で空を除去する。
-
Fan-in（barrier で集める）：広げたものを集める地点。ただしこれは例外であって既定値ではない。全ソース横断の重複除去、リスト全体のランキング、「1件も返ってこなかったから早期終了する」判断など、本当に全部が揃わなければ進めない場合だけ使う。
-
Diamond（ダイヤモンド）：fan-outとfan-inを組み合わせた形。まともなエージェントシステムのほぼすべての背後にある。「広げて、働かせて、まとめる」の3段を分けて名前を付けると管理しやすい。重要なのは中央の「reduce」（リスト平坦化・重複除去）は決定論的なコード数行で済む点だ。エージェントは要らない。
-
Routing（振り分け）：ルーターノードが結果を見て次のエッジを発火させる。設計判断として「分類はエージェントの判断でよいが、ルーティング自体は普通のコードで書く」——こうすれば同じ入力は毎回同じ経路を通り、予測できない分岐が起きない。
-
Verification（検証）：検証者がエッジの上に座り、結果が下流に行くのを許す前に立ちはだかる。その唯一の仕事は発見を反証しようとすること。自己優遇バイアスへの構造的な対策がここにある。別のコンテキストの別エージェントに反証させれば、「自分の仕事を自分で採点させる」問題を回避できる。
-
収束するサイクル：仕事の量が事前に分からない場合（バグ探しのように、1つ見つかると3つ見えてくる仕事）に使う。出口条件は「数ラウンド連続で新しいものが出なくなるまで続けて止める」（loop-until-dry）。致命的な細部として、新しい発見を照合する相手は「確認済み」ではなく「これまで見た全部」にすること。却下された結果を記録しないと、それは毎ラウンド浮かび上がってくる。
これら6つはAnthropicが dynamic workflows のために命名・文書化した公式6パターンとほぼ対応している（Routing = classify-and-act、Diamond = fan-out-and-synthesize、Verification = adversarial verification、収束するサイクル = loop until done）。
AIおじさんの見方：「形を変える」という発想転換が難しい理由
ここからは見方の話になる。
この記事が「22万回表示」を集めた理由は、おそらく内容が「知らなかった知識を教えてくれる」タイプではなく、「薄々感じていた問題に言葉を与えてくれる」タイプだからだと思う。
エージェント設計の議論は長らく「どのモデルを使うか」「どのフレームワークを使うか」に集中していた。しかし実際に複雑なエージェントを動かしてみると、ボトルネックはモデルの能力でも選定したフレームワークでもなく、「工程をどう並べるか」という設計の形であることに気づく。これは、ソフトウェアアーキテクチャが「どの言語を使うか」より「どう分割するか」の問題だというのと同じ構造だ。
議論の重心が「モデル選択」から「トポロジー設計」へ移り始めている。この記事はその移行期の実践的な整理として読める。
一方で、期待値の調整も必要だ。グラフ型設計は万能ではない。元記事自身も「ほとんどのタスクに5人のレビュアーのパネルは必要ない」と書いており、Anthropicも「ワークフローはトークンを著しく多く使う可能性がある」「複雑で価値の高いタスクに最も適している」と明言している。素早い一発のプロンプトは、素早い一発の仕事には今でも正しい道具だ。
実務的な示唆：4つの実装判断
では、これを読んだ開発者は具体的に何を考えるべきか。
（1）失敗の隔離と書き込みの隔離を分けて考える
並列実行での壊れ方は「ノードが単に失敗する」と「同じファイルに書くノードが衝突する」の2種類あり、対策も別だ。前者は例外が全体を落とさないよう fan-out を設計する。後者は各エージェントに隔離された作業場を与えて後でマージする（Claude Code では worktree の隔離として提供されている）。ただしこれはそれが必要なトポロジーのためのシートベルトであって、すべてのグラフに課す税ではない。
（2）モデルをグラフ全体で階層化する
すべてのノードが同じ重さではない。1フィールドを抽出する・1チケットを分類するといった境界が明確で反復的な仕事には安いモデル。最終レポートの合成・争点の裁定といった判断が宿る場所には最良のモデル。これは意図的にやらなければ起きない。既定では生成したすべてのノードは開始セッションのモデルを継承するため、ノードごとに明示する必要がある。
（3）barrier はコストだと認識する
barrierは他の9個が一瞬で終わっていても、下流の全工程を一番遅い1つが終わるまで待たせる。既定は「独立に流す」。barrierに手を伸ばすのは、完全なセットが本当に必要な場合——全体横断の重複除去、総数による早期終了、他の全発見との比較——だけにする。元記事のこの一文が刺さる。「このほうがコードがきれいだ」は、その理由に含まれない。余分な待ちは実測できる時間であり、その場所を得るには理由が必要だ。
（4）グラフが「静かに壊れる」パターンを覚えておく
元記事が挙げる落とし穴のうち、特に現場で見かけるのは次の3つだ。
- 偽のエッジ：その順でタイプしたから繋いだだけで、2つ目は1つ目の出力を読んでいない。待ちは何も買っていない。
- 既定でbarrier：整って見えるから同期待ちにしたが、次の段階は完全なセットを必要としていない。レイテンシは実在し、無駄だ。
- 乾かないループ：新しい発見を「確認済み」だけと照合している。却下された結果が毎ラウンド再登場し、同じ行き止まりを永遠に再発見する。
今後の論点：グラフを「描く」から「育てる」へ
手で描いたグラフは一直線のチェーンより大きな前進だが、それが天井ではない。
元記事が指す次のフロンティアは、グラフを手で描かないことだ。目的を記述し、システム自身がタスクを分解し、fan-outの幅を選び、その実行に合わせた編成スクリプトを書く。固定の形を当てはめるのではなく、仕事の性質に応じてトポロジー自体が生成される方向だ。
もう一つ、個人の習慣から共有資産への転換という論点がある。うまくいった実行のスクリプトを保存してリポジトリに入れ、チームメイトが名前で起動できるようにする。「誰かが設計したグラフ」が組織の中で再利用可能な資産になっていく。この方向は、エージェント設計が個人の職人技から組織的な標準化へと移行する流れと重なる。
次に問題になるのは、おそらく「グラフの管理コスト」だ。ノードが増え、エッジが複雑になるにつれ、デバッグや変更管理のコストも上がる。「どのノードがどの依存関係を持っているか」を可視化・管理するツールや慣習が、次の実務的な課題として浮上してくるはずだ。
トポロジーがコストと信頼性の一番大きなレバーだという主張は、実感として正しい。モデルのアップグレードよりも、エッジを1本消す判断の方が、実行コストと速度に効くことはある。「設計の形を見直す」という発想を持っているエンジニアと持っていないエンジニアの差は、これから広がっていく気がしている。
