Claude Code の動的ワークフローで組むグラフエンジニアリング 14 ステップ

TL;DR

多段エージェントを組むと、ほとんどの人が一列の行列を作る。ステップ 1 → 2 → 3 と、前が終わるのを律儀に待つ。だがその半分は最初から何も待つ必要がなかった。
仕事の形は本質的にグラフである。ノードが考え、エッジが結果を運ぶ。エッジは「その後で」ではなく「データが実際に渡る」ときだけ存在する。データが渡らないエッジ＝偽エッジを消すだけで、待ち時間の多くが消える。コストはゼロ。
Claude Code の**動的ワークフロー（Dynamic Workflows / Workflow ツール）**はこのグラフを直接書くための仕組み。Claude が素の JavaScript でオーケストレーション用スクリプトを書き、サブエージェントのフリート（数十〜数百規模のエージェント群）がそれを実行する。調整レイヤ自体はモデルのトークンを消費しない（コードだから）。
14 ステップは 4 ブロック構成：01–04 今あるグラフを見る / 05–08 フリートを動かす / 09–11 出力を信頼する / 12–14 破産しない。
最重要の反対ルール：グラフが買えるのは幅（＝同時に走らせられる仕事の量）だけで、「判断の質」は買えない。仕事が分割できないなら、エージェント 1 体のままでいい。→ 反対ルールだけは先に読んでほしい。
元記事の主張は Claude Code 公式ドキュメントとほぼ一致していた。ただし「0 トークン」は調整レイヤに限った話で、実行全体のトークンは会話でやるより増える——ここは元記事が触れていないので後述する。

元記事について

このロードマップは @angeldot_ が 2026 年 7 月 25 日に X の記事（長文フォーマット）として公開した「GRAPH ENGINEERING CON OPUS 5」がベース。スペイン語で書かれた 14 ステップのロードマップで、44 万ビュー・612 ブックマークを集めている。

このブログでは以前、グラフエンジニアリング入門 — AIエージェントで多因子アルファモデルを組む「4段階」の到達点で「プロンプト → ループ → スワーム → グラフ」という進化の整理を扱った。今回はそのグラフ段階を実際に手で組むための実装レベルの話になる。また出発点である「ループ」についてはプロンプトからループへ、その土台となる「ハーネス」についてはハーネスエンジニアリングを参照。

なお動的ワークフローという機能そのものの仕様確認と、「全自動で自走する」というバイラル投稿の誇張の切り分けは、別記事 Claude Code の「Dynamic Workflows」を冷静に検証で扱っている。あちらが機能の検証なら、この記事はその機能を使って何をどう設計するかという設計論だ。

以下、元記事の構成に沿って再構成しつつ、記述の裏取り（公式ドキュメントとの照合）を各所に挟んでいく。以降、スペイン語の原文を単に「元記事」と呼ぶ。

発想の転換：プロンプト・ループ・ハーネス・そしてグラフ

プロンプトは一文である。
ループは周回である。
ハーネスはエージェントが立つ床である。

だが「何が何の前に走るのか、何が同時に走れるのか、何が全部を待たねばならないのか」——仕事そのものの形はグラフだ。

ノードが考える。エッジが結果を運ぶ。

そして Claude Code はこのグラフを直接構築する仕組みを既に持っている。動的ワークフローである。

以降のコード例で使う API は 3 つだけなので、先に押さえておくと読みやすい。

API	役割
`agent()`	ノード 1 個。1 依頼・1 出力。`schema` を渡すと構造化データを強制できる
`parallel()`	バリア付きの fan out。全部を待って結果の配列で返す
`pipeline()`	バリアなし。要素ごとに全段を独立に流す

以降のコード例では、schema の中身は FINDINGS や VERDICT のような定数に切り出してある（実体は後述のステップ 03 を参照）。

ロードマップは 4 ブロックに分かれる。

ブロック	ステップ	テーマ
1	01–04	今あるグラフを見る
2	05–08	フリートを動かす
3	09–11	出力を信頼する
4	12–14	破産しない

ブロック 1 · 今あるグラフを見る

01. ノードは「依頼」、エッジは「流れるもの」

グラフの構成要素はちょうど 2 つで、これを明確にするだけで混乱のほとんどが解ける。

ノード：仕事の単位。1 エージェント、限定された依頼、1 入力、1 出力。
エッジ：依存関係。このノードの出力が、あのノードの入力になる、という宣言。それだけ。

よくある間違いは、「その後で」をエッジとして扱ってしまうことだ。

「このファイルを要約して、それから天気を教えて」——この 2 つの間にエッジは 1 本もない。天気予報は要約を消費しない。直列スクリプトが必要もなく繋いだ、独立した 2 ノードである。

エッジはデータが実際に渡るときにだけ存在する。

箱と矢印で描いてみるとよい。箱は agent() 呼び出し 1 個。矢印はある呼び出しの戻り値から出て、別の呼び出しのプロンプトに入る変数のこと。矢印が描けない——変数が何も渡らない——なら、その 2 つの箱は独立している。

ルール：エージェントの「その後で」ごとに、次のステップは前の出力を読んでいるかを問う。読んでいないなら、その待ちは捨てた時間である。

02. あなたの直列スクリプトは、既にグラフである（退化した形の）

「A して、次に B、次に C、次に D」と書いた時点で、あなたは既にグラフを描いている。分岐のない鎖だ。各ノードの入次数 1、出次数 1。

動きはする。だが遅く、そして脆い。鎖には冗長性がないので、C が詰まれば D は永遠に起きず、A の成果は行き先を失って上流で滞留する。

グラフエンジニアリングの最初の実技は、鎖を描き直すことだ。手元の直列エージェントを取り出し、矢印ごとにステップ 01 の問いを当てる。

たいていの鎖には、データを運んでいない矢印が 2〜3 本ある。それらが存在する理由は「あなたがタイプした順序」でしかない。

その矢印を切ると、鎖はほどけて横に広い形になる。同時に走れる独立ノードがいくつかと、それら全部を本当に必要とする単一ノード、という形だ。

左のチェーンは所要時間が B + C + D の合計になるが、右のダイヤモンドでは max(B, C, D) と統合の和に縮む。

これはお金がかからず、新しいツールも要らず、そして普通は買えるどんなものより多くの待ち時間を消す。

ルール：何かを足す前に、データを運んでいないエッジを消せ。

03. 各ノードに契約を与える

推論できないノードは、並列化できないノードである。

直し方は契約だ。限定された入力、限定された出力、単一の仕事。

入力は、そのノードが読むもの。明示的に渡される——共有のコンテキストウィンドウ経由で暗黙に前提しない。
出力は定義された形。理想的には検証済み。次のノードが推測せずに消費できるように。

ワークフローではこの契約を schema で強制する。agent() 呼び出しに JSON Schema を渡すと、サブエージェントは妥当な構造化データを返すことを義務づけられる。

const found = await agent('src/routes/ 配下の .ts ファイルを全て列挙せよ。', {
  schema: {
    type: 'object',
    required: ['files'],
    properties: {
      files: { type: 'array', items: { type: 'string' } },
    },
  },
})
// found.files は検証済みの配列。パースもお祈りも不要

検証はツール呼び出しのレイヤで起きるので、形が合わなければリトライされる。自由テキストが返ってきて、自分でパースして「うまくいってくれ」と祈る——ということにはならない。

これが「Claude がグラフに配線できるノード」と「人間が読んだときだけ機能するノード」の差である。

ルール：ノードの出力に形がないなら、それはノードではない。会話である。

04. エッジも契約であり、しかもタダである

エッジは「B が A の後に来る」ではない。渡るものについての約束だ——A はこの形を生成し、B はこの形を消費するために作られている。

エッジを「順序」ではなく「データ」で名付けると、2 つのことが簡単になる。

そのエッジが本物かどうかが即座に分かる。「何かがここを移動するか？」と問えるから。
形が保たれる限り、両端どちらのノードも差し替えられる。グラフを壊さずに。

実務上、エッジは素の JavaScript として存在する。fan out（扇状に開いて並列に配る）と統合の間にある reduce ステップ——平坦化、重複排除、フィルタ——は、ノードが返した形の上で動くただのコードだ。

そこにエージェントは要らない。

ここがグラフ思考の静かな勝利のひとつである。人がトークンを払っているものの相当量は実際にはエッジであり、エッジはタダだ。

「結果を統合する」ためにエージェントを起動したくなる。抵抗せよ。統合が平坦化と重複排除を意味するなら、それは flatMap と Set である。決定的、即時、0 トークン。

// ❌ 統合のためにエージェントを 1 体焚く（トークンを払って配管をする）
const merged = await agent(`次の結果をマージして重複を除け: ${JSON.stringify(all)}`)

// ✅ エッジはコード。決定的・即時・0 トークン
const merged = [...new Set(all.filter(Boolean).flatMap(r => r.findings))]

ルール：エージェントは判断のためにあり、配管のためにはない。すべてのエッジがエージェントであるグラフは、自分の配線に家賃を払っている。

ブロック 2 · フリートを動かす — `parallel()` と `pipeline()` で並列化する

05. `parallel()` で fan out する

この一手だけで、残りすべての投資が回収できる。

独立ノードが N 個あるとき——照会すべき N 個のソース、レビューすべき N 個のファイル、監査すべき N 本のルート——それらを鎖にしない。扇状に開いて同時に走らせる。

ワークフローではこれが parallel() だ。thunk（引数なしで呼ぶと実行が始まる関数。() => agent(...) の形）の配列を取り、thunk ごとに 1 サブエージェントを起動し、全部を並行実行して結果の配列を返す。

const results = await parallel(
  SOURCES.map(src => () => agent(`${src} を調査せよ。`, { schema: FINDINGS })),
)
const alive = results.filter(Boolean)   // ← これが封じ込め（後述）

堅牢にしているディテールが 2 つある。

parallel() はバリアである。 全 thunk を待って返すので、次の段は完全な集合を見る。
例外を投げた thunk は null に解決される。バッチ全体を倒すのではない。不安定なエージェント 1 体が実行を沈められない。

だから出力には常に .filter(Boolean) を当てる。

並行数の上限はおおよそ CPU コア数で決まる。公式ドキュメントでは最大 16 並行で、コアが少ないマシンではより少ない。超過分はキューに入る。だから thunk を 100 個渡しても全部終わる——ひと掴みずつ、というだけだ。なお1 実行あたりのエージェント総数は 1,000 体が上限で、これは暴走ループに対する歯止めとして置かれている。

そしてここが肝心なところ。fan out は Claude が書いたコードの中に存在し、モデルとの会話の中には存在しない。

Claude 自身のコンテキストは N 個のソースを同時に抱えない。各サブエージェントが自分の分をロードし、最終的な答えだけが戻る。これが数十〜数百のサブエージェントへスケールしてもセッションが溺れない理由である。

ルール：N 個が互いを読まないなら、キューに並べるな。開け。

06. fan in でバリアを閉じる

fan out は、それを受け止める何かがあって初めて意味を持つ。

fan in（開いた扇を 1 点に合流させる）はエッジが収束するノードだ。1 エージェント、あるいはコード片が、上流の全結果を一度に見て、集合全体を必要とする何かをする——ソース間の重複排除、インパクト順のソート、何も来なかった場合の早期終了。

そこがバリアが待ち時間のコストを正当化できる唯一の場所である。

全ソース間で重複排除する？ → バリア、正しい。
リストを平坦化するだけ？ → それはエッジ。インラインでやれ。

テストは単純だ。parallel() → 変換 → parallel() と書いて、その中間の変換に要素間の依存が一切ないなら、pipeline() を使ってバリアごとスキップすべきだった。

ルール：バリアは、ある段が本当に前段の全結果を一緒に必要とするときだけ。

07. ダイヤモンド：fan out → reduce → 統合

fan out と fan in を合わせると、まともなエージェントグラフすべての作業トポロジーが得られる。ダイヤモンドである。

1 ノードが依頼を分割する。多数のノードが並列に働く。1 ノードが融合する。

覚える価値のある名前が付いた正典形がこれだ。

fan out → reduce → 統合

fan out で幅を稼ぐ
reduce を素のコードで行って圧縮する
統合を最終エージェントに書かせる

これが市場スキャン、依存関係監査、コードレビュー、リサーチレポートの背後にある骨格である。ソースとプロンプトを差し替えれば、同じ骨格が適応する。

ダイヤモンドが見えると、「どうやってエージェントにもっとステップを踏ませるか」と考えるのをやめて、**「切れ目はどこで、融合はどこか」**と問い始める。そちらが本当にスケールする問いだ。

ルール：ステップを設計するな。どこで分かれ、どこで合流するかを設計せよ。

08. 実行時にエッジをルーティングする

すべてのグラフが固定ではない。どのエッジを通るかが、あるノードの発見内容に依存することがある。

ルーターノードは結果を検査してどの経路が発火するかを決める。チケットを分類して正しいハンドラへ分岐する。diff のサイズを見て、素早いレビューか完全監査の立ち上げかを選ぶ。

const triage = await agent('この diff を分類せよ。', { schema: TRIAGE })

// ルーティングは JavaScript。モデルの気分ではない
const review = triage.size === 'large'
  ? await parallel(LENSES.map(l => () => agent(`${l} の観点で監査せよ。`, { schema: FINDINGS })))
  : [await agent('素早くレビューせよ。', { schema: FINDINGS })]

ワークフローではこれは検証済み出力に対する**ただの if か switch**だ。制御フローがコードに存在するからである。

ここでは決定性が制約ではなく機能だ。ルーターの判断は Claude から来てよいが、ルーティングはコードである。同じ分類に対して常に同じように走る。

モデルの判断をノードに、スクリプトの信頼性をエッジに。「エージェントが監査をスキップすることに決めた」という創発的な驚きは起きない。そのスキップはグラフに書かれていなければならず、書かれていないからだ。

ルール：これが何であるかはモデルに決めさせ、それをどうするかはコードに決めさせよ。

反対ルール — グラフが買えるのは「幅」だけ

元記事でここに置かれている警告は、14 ステップの中で最も重要な一節だと思う。引用しておく。

グラフが買えるのは幅である。より良い判断は買えない。
仕事の各ステップが前ステップの全体像を必要とするなら、エージェント間に分配してもより良い答えは得られない。同じ答えが、より高くより遅く得られるだけだ。
グラフが元を取り始めるのは、仕事が「互いの結果を決して読まない依頼」に分割される、まさにその瞬間である。
エージェントを 1 体足す前に、請求額を決める唯一の問い：私の仕事はどこで分かれるのか？
分かれないなら、エージェント 1 体のままで、残る 6 ステップを節約せよ。

ブロック 3 · 出力を信頼する — 敵対的検証とノード隔離

09. エッジに検証ノードを置く

グラフの本当のレバレッジは、エージェントの数が増えることではない。信頼を生み出すために周囲に組める構造のことだ。

検証ノードは、結果が下流へ降りる許可を得る前にエッジに座る。その唯一の仕事は発見を殺そうとすること。生き延びれば通る。そうでなければ答えに到達しない。

その下には硬いルールがある。

同じエージェントに自分の答案を採点させるな。

自分の出力をレビューするモデルは、自分の誤りの大半を見逃す。間違えたのと同じ場所から評価しているからだ。

手元に持っておくべきパターンが 3 つ。

敵対的検証：発見ごとに、それを反証する命令を与えた独立の懐疑者を N 体起動する。過半数を生き延びたものだけが残る。
多様レンズ検証：各検証者に異なる角度を与える。正しいか、安全か、再現するか。多様性は、同一のチェック N 回では決して見つからない失敗モードを狩る。
審査員パネル：異なる角度から N 個の試行を生成し、並列の審査員で採点し、勝者から統合しつつ次点の良い部分を接ぎ木する。

const votes = await parallel(
  ['correctness', 'security', 'repro'].map(lens => () =>
    agent(`「${claim}」を ${lens} の観点で反証せよ。不確かなら refuted=true を既定とせよ。`,
      { schema: VERDICT })),
)
const survives = votes.filter(Boolean).filter(v => !v.refuted).length >= 2
// 3 レンズのうち 2 票以上が「反証できなかった」なら通す（過半数）

ルール：検証されていない発見は移動しない。そして 2 人の検証者が同じ問いをすることは決してない。

10. ノードを隔離して、1 つの失敗がグラフを汚染しないようにする

鎖では失敗がカスケードする。C が死ねば D は永遠に走らず、全部が止まる。

グラフでは、失敗はそのノードに封じ込められるべきだ。

これは既に部分的に成立している。parallel() の中で破裂した thunk は null に解決されるので、1 体こけても残りのエージェントは普通に結果を返す。.filter(Boolean) が封じ込めである。

そして各 fan in は、完全な集合を前提するのではなく、入力の欠損を許容するよう設計する。

より微妙な失敗はノード同士が互いを踏むことだ。複数エージェントが並列にファイルを書くと衝突する。

直し方は隔離である。各エージェントが自分の git worktree で走り、サンドボックスで仕事をして、それからクリーンにマージする。

await pipeline(files, f => agent(`${f} を移行せよ。`, { isolation: 'worktree' }))

ただしこれはノードが本当に並列に書き込むときだけ使う。worktree の生成にはセットアップ時間とディスク消費のコストがかかる。これはそれを必要とする唯一のトポロジーのためのシートベルトであって、全実行に課すデフォルトの税金ではない。

なお worktree による並列作業の実務は、dmux で AI エージェントを並列に走らせるでも扱っている。

ルール：1 ファイルにつき書き手は 1 人。そしてすべての fan in は穴を許容する。

11. サイクルを足す。ただし収束させる

中に入るまで仕事の大きさが分からないことがある。サイズ未知の探索だ。1 個見つけると 3 個現れるバグ掃討のような。

それはサイクルを要求する。前のノードへ戻る制御されたエッジである。

危険は明白だ。収束しないサイクルは、予算が溶けるまでエージェントを起動し続ける無限ループになる。

収束するパターンは loop until dry（新しい発見が枯れるまで回す）である。K 回連続で新しいものが出なくなるまで探索者を起動し続け、そこで止まる。

そして成否を分けるディテール——ほぼ全員が初回にやる間違い——は何に対して重複排除するかだ。

確認済み（confirmed）ではなく、見た全部（seen）に対して重複排除せよ。

そうしないと、却下された発見が毎ラウンド再登場する。ループは永遠に枯れず、同じ袋小路を再発見するために金を払い続ける機械ができあがる。

const seen = new Set(), confirmed = []
let dry = 0
while (dry < 2) {                                   // ラウンド上限は必ず持たせる
  const found = (await parallel(FINDERS.map(f => () => agent(f.prompt, { schema: BUGS }))))
    .filter(Boolean).flatMap(r => r.bugs)
  const fresh = found.filter(b => !seen.has(key(b)))  // ← seen に対して dedup（confirmed ではない）
  if (!fresh.length) { dry++; continue }
  dry = 0
  fresh.forEach(b => seen.add(key(b)))
  confirmed.push(...await verifyAll(fresh))
}

key() は発見の同一性判定（何をもって「同じバグ」とみなすか）、verifyAll() はステップ 09 の検証ノードにあたる。どちらも自前で書く部分だ。

ルール：すべてのループはラウンド上限を持ち、見た全部に対して重複排除する。

ブロック 4 · 破産しない — トークンコストとモデルの段階化

12. ノード間でモデルを段階化する

すべてのノードがあなたの最良のモデルを必要とするわけではない。

グラフはこれを、単一エージェントでは決して達成できない形で自明にする。限定的で反復的なノードがある——このフィールドを抽出せよ、このチケットを分類せよ。そして本当に判断が宿るノードがある——レポートを統合せよ、発見を裁定せよ。

退屈なものは安いモデルで走らせ、高いトークンは判断が効く場所に使う。

ワークフローでは、各サブエージェントはスクリプトが上書きしない限りセッションのモデルを継承する。デフォルトでは、大きな実行はまるごとセッションの階層で課金される。agent() 呼び出しの model オプションが、そのノードだけを別の場所へルーティングする。

// 反復的な fan out は安く、判断が要る統合は高いまま
const extracted = await pipeline(tickets,
  t => agent(`${t} を分類せよ。`, { schema: CLASS, model: 'haiku' }))
const report = await agent('分類結果を統合してレポートを書け。', { schema: REPORT })

大きな実行の前に /model を確認し、それから fan out の反復ノードは安いモデルに下げ、融合ノードは高いモデルのままにする。

補足：公式ドキュメントによると、環境変数 CLAUDE_CODE_SUBAGENT_MODEL が設定されている場合はセッションのモデルとスクリプトの指定の両方を上書きする。意図せず全ノードが同じモデルに固定されていないか、大規模実行の前に確認しておくとよい。

ルール：高いモデルは判断が賭かっている場所にだけ。

13. `parallel()` と `pipeline()` はどちらを使うべきか — トポロジーがコストとレイテンシである

グラフの形は装飾ではない。待ち時間（レイテンシ、wall-clock time）に対して存在する最大のレバーだ。

全員がつまずく判断がこれである。parallel() 対 pipeline()。

parallel() のバリアは、次の段が始まる前に全部を最も遅いノードに待たせる。
pipeline() は各要素を全段に独立に流す。バリアがない。要素 A が段 3 にいる間、B はまだ段 1 にいてよい。

上段は各段の最も遅いノードの合計が全体の待ち時間になる。下段では、最も遅い 1 項目が全段を通り抜ける時間に収まる。

速い要素は、遅いものの後ろで立ち止まらずに早く終わる。

デフォルトは pipeline()。バリアに頼るのは、ある段が本当に前段の全結果を同時に必要とするときだけ——集合に対する dedupe、合計に応じた早期終了、「他の発見」と比較するプロンプト。

「こちらのほうが綺麗」「段が別物に感じる」は理由にならない。バリアによる待ち時間は実在し、計測でき、そして無駄である。

分離していることは、同期していることと同じではない。

ルール：pipeline() をデフォルトに、バリアは正当化された例外として。

14. Claude にグラフを描かせる

最後の一手は、事前に計画できない仕事について、グラフを手で描くのをやめることだ。

動的ワークフローでは目標を記述し、Claude がオーケストレーションスクリプト自体を書く。タスクを分解し、fan out を選び、協調したサブエージェントのフリートを起動し、結果を統合する。合うことを期待した固定グラフではなく、その実行に合わせて作られたグラフが得られる。

入口は 3 つ。

プロンプトに workflow という語を入れる → Claude がそのタスク用に 1 本書く。
保存済み、あるいは同梱のワークフローを実行する。 /deep-research は本番で走っている実在のグラフである——絞り込み → 並列検索 → フェッチ → 敵対的検証 → 統合。まさにこのロードマップの骨格だ。
セッション中の実質的なタスクごとにワークフローを計画するモードを有効にする。 /effort ultracode、起動時なら claude --effort ultracode、単発ならプロンプトに ultracode: を前置する。

うまくいったワークフローは .claude/workflows/ に保存して再利用する。 バージョン管理され、名前で再実行でき、リポジトリをクローンした誰でも起動できる。保存したワークフローは / の補完に同梱のものと並んで現れる（ユーザー単位なら ~/.claude/workflows/）。

› src/routes/ の全ルートを監査して auth 漏れを探す workflow を起動して。
  ルートファイル 1 個につきエージェント 1 体、報告前に各発見を検証すること。

● Claude がオーケストレーションスクリプトを書きました · バックグラウンドで起動中…

  /workflows — auth-audit · running
  ✓ 絞り込み    1/1     2.1k tok · 4s
  ✓ Fan-out    18/18    ルートファイル 1 個につき 1 エージェント
  ◯ 検証       11/18    発見ごとに 3 票の懐疑者…
  ○ 統合        0/1     検証待ち

  セッションは応答を続ける。フリートが走る間も作業を続けられる

ルール：実行ごとに仕事の形が変わるなら、グラフを描くな。記述せよ。

補足：「0 トークン」の正確な意味

原文は「調整レイヤ自体はモデルのトークンを 0 消費する（コードであって会話ではないから）」と繰り返す。これは正しい。公式ドキュメントも、ワークフローランタイムは会話とは分離された環境でスクリプトを実行し、中間結果は Claude のコンテキストに入らずスクリプト変数に留まると明記している。

ただし原文が触れていない点がある。実行全体のトークンは、同じ作業を会話で進めるより「意味のある差で増える」。公式ドキュメントの記述はこうだ。

ワークフローは多数のエージェントを起動するため、1 回の実行が会話より大幅に多いトークンを使い得る。実行はプランの使用量・レート制限にカウントされる。
ワークフローが25 エージェントを超えてスケジュールする、あるいは予測トークン総数（projected tokens）が 150 万を超えると、進捗行に警告が出る（ultracode が有効な場合は、既に大規模実行に同意しているとみなされ警告は出ない）。

つまり 「配管が無料」と「実行が安い」は別の話である。ステップ 12（モデルの段階化）とステップ 13（トポロジー）が「破産しない」ブロックに置かれているのは、まさにこの理由だ。0 トークンなのはエッジであって、ノードではない。

その他、原文の技術的記述は公式ドキュメントおよび Workflow ツールの仕様と照合して一致を確認した。

主張	判定
`agent()` / `parallel()` / `pipeline()` という API 面	✅ 確認
`schema` 指定でツール呼び出し層で検証・不一致ならリトライ	✅ 確認
`parallel()` はバリア、例外を投げた thunk は `null` に解決	✅ 確認
並行数の上限（最大 16、コア数に依存）	✅ 確認
1 実行あたりのエージェント総数上限 1,000	✅ 確認
`isolation: 'worktree'` によるノード隔離	✅ 確認
`agent()` の `model` オプション、既定はセッションのモデルを継承	✅ 確認
`/deep-research` が同梱の組み込みワークフロー	✅ 確認（WebSearch ツールが利用可能である必要あり）
`ultracode` によるセッション全体のワークフロー計画モード	✅ 確認（`/effort ultracode`）
保存済みワークフローは `.claude/workflows/` に置きスラッシュコマンドになる	✅ 確認

今週作る 6 つのグラフ

全ルートに対するセキュリティ掃討。 ルートファイル 1 個につき 1 サブエージェント、各自が auth チェック漏れを狩り、その後に検証パスが各発見をレポート到達前に確認する。単一コンテキストでは支えられない幅。
出典付きレポート（/deep-research）。 Claude Code に既に入っているグラフ。質問を異なる角度に分解し、並列に検索を走らせ、ソースを重複排除し、書く前に 3 票の懐疑者で各主張を敵対的に検証する。
モジュールをファイル単位で移植。 翻訳をファイルに fan out し、テストスイートを各ファイルのゲートにして、失敗はループへ戻す。敵対的レビューが、1 パスなら壊れたまま納品していたものを狩る。
diff の敵対的レビュー。 サイズでルーティング：小さい変更は素早い 1 パス、大きい変更は異なるレンズ（正しい・安全・速い）のレビュアーによる完全並列監査を発火させ、その後で審査員パネルが統合する。
スケジュールされたエコシステムスキャン。 一度保存して永遠に再実行。多数のソース（リリース、ブログ、フォーラム）を並列に照会し、バリアでインパクト順にソートしてサマリを書く。.claude/workflows/ にバージョン管理され、名前で起動できる。
サイズ未知の探索。 バグが何個あるか分からない。並列の探索者、新しい発見ごとに見た全部に対する dedupe、生存者の検証、そして 2 ラウンド何も出なくなるまでループ。そこで止まる。

最初のグラフを起動する前のチェックリスト

3 つ以上外したなら、あなたが持っているのはグラフではない。ステップの多い鎖である。

おわりに

プロンプトを打つ者は質問をする。設計する者はグラフを描く。

直列エージェントは天井ではなかった。最初の形にすぎない。誰もがそれを取るのは、それが我々が文章を書く仕方と一致しているからだ。一列、一つの頭、一度に一つ。

ノードとエッジが見え始めると、「エージェントにもっとステップを踏ませる」ことを頼むのをやめて、「グラフをもっと広くする」ことを頼み始める。

仕事が独立なところでは扇状に開く。
信頼が問題になるエッジにはゲートを置く。
判断が賭かっていないところでは安いモデルを使う。

そして原文が最後に置いている宿題は、コストゼロで今夜できるものだ。

今の自分のシステムを描いてみること。依頼と、その間の矢印だけ。偽のエッジを数えて、消すこと。

これがこの職人技全体の最初の一手であり、コストはゼロで、そして普通は買えるどんなツールより多くの待ち時間を消す。