展開と合流の設計（Parallel Fan-Out and Join）

互いに独立した作業は同時に開き、全部の結果が揃わないと決められない一点だけで待ち合わせて束ねる。難しいのは開くほうではない — どこで待つか・いつ止めるか・落ちた枝をどう扱うかであり、この三つは道具が決めてくれない。

問題

「この3つのライブラリを調べて、どれを使うか決めてくれ」と頼むと、たいてい1つずつ順に調べられる。しかしその順序は、前の結果を次が使うから並んでいるのではない。そう頼んだから並んでいるだけである。 3つの調査は互いを参照しない。順序の依存とデータの依存が取り違えられている。

取り違えの代償は待ち時間だけではない。1つの文脈で3つを続けて読めば、3つ分の中間物が同じ場所に積み上がり、最後の比較をするころには最初に読んだものが薄れている。分けずに並べたことが、待ち時間と文脈の両方を損なう。

ところが分けた途端、分けなければ存在しなかった問いが3つ生まれる。いつ待ち合わせるのか。落ちた枝が1本あったとき、全体を捨てるのか。終わりの見えない探索を、何をもって打ち切るのか。 並列に開く機構は道具が用意しているが、この3つに答えるのは運用の側である。

コンテキスト

適用する条件:

• 枝が互いの結果を必要としない — 3つのライブラリの調査、4つの観点のレビュー、複数リポジトリへの同じ問い合わせ
• 各枝の結果が要約に圧縮できる — 束ねる側が全文を受け取らずに済む
• 合流してはじめて判断が下せる — 比較・順位づけ・統合が最後にある仕事

適用しないケース:

• すべての枝が同じ文脈を共有していなければならないとき、および枝どうしの依存が多いとき。 これは推測ではなく 公式 が名指しした限定であり、同じ資料はコーディングの仕事の多くは調査ほど真に並列化できる部分が少ないとまで書いている（出典は具体例節）
• 枝が1〜2本のとき。 展開と合流の設計それ自体に手間がかかる。開いて束ねるための往復が、順に読む費用を上回りうる
• 費用を払えないとき。 枝を増やすほどモデルとのやり取りが増える。値札は委譲の損益分岐が扱う

隣接パターンとの境界:

• 読み捨ての隔離 — 同パターンは1本の枝の内側（何を捨て、何を要約して持ち帰るか）を扱う。本パターンは枝が何本あり、どこで束ねるかという全体の形を扱う
• 委譲の損益分岐 — 同パターンは委譲するか否かの値札、本パターンは委譲すると決めた後の並べ方である
• セッション境界の設計 — どちらも「いつ止めるか」に触れるが、契機が違う。同パターンの契機は文脈の劣化、本パターンの契機は新しい結果が出なくなったことである
• 計算をコードに落とす — 合流点で結果を突き合わせる作業のうち、結合・重複排除・整形は決定的な手続きである。同パターンがその部分を引き受ける

解決

第一に、順序の依存とデータの依存を分ける。 「次にこれをやって」と書いた順序のうち、前の出力を実際に読む段はどれか。読まない段は、並んでいる理由が無い。この仕分けは仕事の中身を知っている人間にしかできず、道具は依頼された順に従うだけである。

第二に、待ち合わせ点は「全部揃わないと決められない段」だけに置く。 比較・順位づけ・統合はそこに当たる。逆に、1本の結果が届くたびに何かを進められるなら、そこは待ち合わせ点ではない。待ち合わせ点を増やすほど形は直列に戻り、分けた意味が消える。分けることと束ねることは対であり、束ね方を決めずに分けると、束ねる場所が最後まで決まらない。

第三に、落ちた枝の扱いを先に決める。 3本のうち1本が失敗したとき、残り2本の結果で判断を進めてよいのか、それとも3本揃わない判断には意味が無いのか。これは仕事の性質が決めることであって、道具の既定が決めてよいことではない。 「3つのライブラリのうち2つしか調べられませんでした」で決めてよい選定なら切り離せるし、悪ければ全体をやり直す。⚠ 確認した範囲では、この「切り離して残りを続ける」を推奨する一次資料は両ベンダーに無い（不在確認。検索語と範囲は具体例節）。近い記述はあるが、それは落ちたところから復帰する話であり、落ちた枝を切り離す話ではない。

第四に、終わりの見えない探索には、外から止め方を与える。 「関連しそうなものを全部集めて」の類には自然な終わりが無い。新しく出てきたものが既に持っているものと重複しているかを見て、重複しかない状態が続いたら打ち切る、という止め方がある。⚠ これも一次資料には無い（不在確認）。近い記述は「十分な情報が集まったかをモデルに判断させる」であり、機械的な停止条件を外から与えることとは別である。前者はモデルの判断に依存し、後者は依存しない。

四つのうち、道具が助けてくれるのは第一と第二の途中までである。第三と第四は、確認した範囲では誰も推奨を書いていない領域であり、書く人が自分で決めるしかない。 決めずに走らせると、既定の挙動がそのまま方針になる。

トレードオフ

利点

• 待ち時間が最も遅い1本に縮む。 直列なら全部の和である
• 各枝の中間物が互いに混ざらない。 合流点に届くのは要約だけであり、比較の段で最初の調査が薄れることが無い
• 枝ごとに道具や権限を変えられる。 束ねる側は、どの枝がどう調べたかを知らなくてよい

代償

• 消費が増える。 枝ごとにモデルとのやり取りが独立に発生する。これは 公式 が両ベンダーとも明記している（具体例節）。値札は委譲の損益分岐が扱う
• 枝は互いを知らない。 同じことを2本が重複して調べても、走っている最中には気づけない。合流するまで分からない
• 形を決める手間がかかる。 どこで待つか・落ちた枝をどうするか・いつ止めるかを、仕事ごとに決め直すことになる。枝が2本の仕事では、この手間のほうが高い

GitHub Copilot での具体例

並列に開く機構は複数の面にある。合流・障害・停止についての推奨は、確認した範囲では無い。 以下、面ごとに機構を示し、最後に無かったものの範囲を記す。

Copilot CLI — /fleet で並列化を指示する

人間の側から並列化を指示できる（出典: Running tasks in parallel with the /fleet command、取得日: 2026-07-16）公式:

Context window: Each subagent has its own context window, separate from the main agent and other subagents. This allows each subagent to focus on its specific task without being overwhelmed by the full context of the larger task.

〔訳〕コンテキストウィンドウ: 各 subagent は、主エージェントや他の subagent とは別に、自分自身のコンテキストウィンドウを持つ。これにより各 subagent は、より大きなタスク全体の文脈に圧倒されることなく、自らの個別のタスクに集中できる。

同じページが代償も書いている 公式:

Each subagent can interact with the LLM independently of the main agent, so splitting work up into smaller tasks that are run by subagents may result in more LLM interactions than if the work was handled by the main agent. Using /fleet in a prompt may therefore cause more GitHub AI Credits to be consumed.

〔訳〕各 subagent は主エージェントとは独立に LLM とやり取りできるため、作業を subagent が実行する小さなタスクに分割すると、主エージェントが処理する場合より LLM とのやり取りが増えることがある。したがってプロンプト内で /fleet を使うと、より多くの GitHub AI Credits が消費されることがある。

VS Code — 枝の契約は人間が与える

主エージェントが subagent を起こす面では、各枝に何をさせ何を返させるかを明示せよと公式が書いている（出典: Subagents in Visual Studio Code、取得日: 2026-07-16）公式:

To optimize subagent performance, clearly define the task and expected output.

〔訳〕subagent の性能を最適化するには、タスクと期待する出力を明確に定義すること。

これは合流点の設計そのものである。 束ねる側が受け取る形が決まっていなければ、待ち合わせても比較できない。ただし原文が言うのは「明確に定義せよ」までであり、どこで待つかについては何も言っていない。

Anthropic 側 — 待ち合わせは実装の記述として現れる

対向の一次資料（出典: How we built our multi-agent research system、取得日: 2026-07-27。curl で 180,431 バイトを全文取得）は、調査システムの現行実装が subagent 群を同期的に実行し、各組の完了を待ってから次へ進むと述べている 公式。統合は主エージェント側が行う。⚠ 射程は調査（research）用途のシステムであり、エージェント一般の設計指針として書かれてはいない。

同じ資料は適用しないケースを名指ししており、これは本パターンの「コンテキスト」節の根拠である 公式:

Further, some domains that require all agents to share the same context or involve many dependencies between agents are not a good fit for multi-agent systems today. For instance, most coding tasks involve fewer truly parallelizable tasks than research, and LLM agents are not yet great at coordinating and delegating to other agents in real time.

〔訳〕さらに、すべてのエージェントが同じコンテキストを共有する必要がある領域や、エージェント間の依存が多い領域は、現時点ではマルチエージェントシステムに向かない。例えば、ほとんどのコーディングのタスクは、調査に比べて真に並列化できる部分が少なく、また LLM エージェントは他のエージェントへのリアルタイムな調整や委譲がまだ得意ではない。

⚠ 同じ資料はトークン消費の倍率も示しているが、本ページはその数値を載せない。 数値は委譲の損益分岐が正本として扱う。本ページが書くのは「増える」という向きだけである。

無かったもの（範囲つき）

2026-07-27 に、取得を担当したのとは別のサブエージェント2体が一次資料17件を取得して確認した。内訳は GitHub 側8件（/fleet、Copilot CLI の custom agent 3件、VS Code の subagents・agents concepts・overview・custom agents。いずれも公式リポジトリの raw markdown を全文取得）と Anthropic 側9件（Claude Code のベストプラクティス・sub-agents・hooks、Agent SDK の subagents、Agent Skills のベストプラクティス、構造化出力、プロンプトの連鎖、ツール利用の概要、上記の調査システムの記事。いずれも全文取得）である。

探したもの	検索語	結果
落ちた枝を切り離して残りを続ける	partial / isolat / error propagation / graceful / rather than failing	調査システムの記事で partial 0件・isolat 0件。⚠ 見つかったのは「誤りの時点から復帰する」「再試行と定期チェックポイント」であり、切り離しではない
重複排除と連続空振りによる打ち切り	deduplic / new result / stop condition / stopping / converg / termination	同記事で deduplic 0件・new result 0件・stop condition 0件・converg 0件。⚠ 見つかったのは「十分な情報が集まったかを判断させる」「依頼の複雑さに応じて労力の予算を決める」であり、機械的な停止条件ではない
待ち合わせ点を指す確立した呼称	barrier / join	呼称としての用例を確認できなかった。合流は「待つ」「統合する」という記述と実装の順序として現れる

不在確認 である。これは「そうしてはいけない」という意味でも、「機能が無い」という意味でもない — 確認した17件の範囲に推奨の記述が無かった、というだけである。本カタログはここから挙動を推論しない。

別名

呼称	出典
展開と合流の設計 / Parallel Fan-Out and Join	記述 — 本カタログの記述的呼称であり、一次資料に出典は無い
Subagent / /fleet	一次 — ただしこれらは枝を開く機構の名であって、本パターンの名ではない（出典は具体例節）

⚠ 本カタログが名前に使った「合流（join）」を、公式の呼称として引かないこと。 上記17件の確認範囲で、待ち合わせ点を指す確立した呼称は見つかっていない。素材の側が用いる図式的な語彙（節点と辺、障壁）も同様であり、呼称としては本カタログの造語として扱う。

機構の名を実践の名として流用しない理由は読み捨ての隔離と同じである。並列に開く機構が無い環境でも、この実践は成立する — 別々のセッションで同時に調べ、結果を1か所に書き戻す運用は、道具を問わず同じ形を持つ。

関連

• 読み捨ての隔離 — 本パターンの1本の枝が、同パターンである。 同パターンは枝の内側（何を捨て、何を要約して持ち帰るか）を扱い、本パターンは枝の本数と束ね方を扱う。合流点に要約だけが届くのは、同パターンが効いているからである
• 委譲の損益分岐 — 値札は同パターンが持つ。 枝を増やすほどモデルとのやり取りが増えることは両ベンダーの 公式 が明記しており（具体例節）、その倍率と損益の見積もりは同パターンが正本として扱う。本ページは向きだけを書く
• セッション境界の設計 — 「いつ止めるか」の契機が違う。 同パターンの契機は文脈の劣化、本パターンの契機は新しい結果が出なくなったことである。同じ「打ち切り」でも、見ている針が違う
• 計算をコードに落とす — 合流点の内側を引き受ける。 束ねる作業のうち、結合・重複排除・整形は手続きの決まった処理であり、推論に出させる理由が無い。⚠ ただし同パターンが主張するのは決定的になることであって、安くなることではない
• 出力の契約を明示する — 各枝に何を返させるかを決めるのは、束ねる前提である。同パターンは人間が受け取る出力の形を扱い、本パターンでは束ねる側が受け取る形として同じ問題が現れる
• 検証対象の明示 — 枝を分けるとき、各枝が何を確かめるのかが曖昧なら、合流しても比較できない
• まず次に読むなら 委譲の損益分岐 — 形を決めたら、次はその形にいくらかかるかを見る番である