マルチエージェント設計パターンとは。15のパターンと6つの基本原則を整理

家事と子育てのスキマで経営する3方よしAI共創コンサルタントの田中啓之、ひろくん（@passion_tanaka）です。今回は、＠ITの記事「マルチエージェント設計「15のパターン」」を紹介します。AIエージェントを複数連携させるマルチエージェントシステムの設計について、GitHub・Google・Siemensの知見から、15のデザインパターンと6つの基本原則を整理した記事です。

なぜ取り上げたかというと、私が保存したブックマークだからです。私の過去記事には、「所有者は一人です」という判断の軸や、止まって聞くのは出す直前の最終確認と私にしかできない操作だけ、という決めごと、止まる条件が無い仕事は見ていない間も間違った前提のまま進む、という考えを書いています。元記事の15の型に、この考えを重ねて読んでみました。

読み方の筋は、受け渡し、順番と振り分け、並行と階層、作る役と確かめる役、人が止まる場所、コンテスト上位の4つ、象を切り分ける、6つの基本原則の順です。元記事の整理を、私の仕事の目線で読んだ記録になります。あなたのAIエージェントの使い方に重ねながら、読んでみてください。

＠IT『マルチエージェント設計「15のパターン」』の「GitHubの2つの基本設計」より（2026年11月8日公開・第1章で引く部分）

これは、マルチエージェントシステムがチャットのように動作するのではなく、分散システムのように動作するからです。

GitHubは、複数のAIエージェントはチャットのようにではなく、分散システム（役割の違う部品が連絡し合って動く仕組み）のように動く、と説明しています。だから受け渡しの形を先に決める、という話です。

元記事は＠IT、筆者は雨輝ITラボ（リーフレイン）、2026年11月8日の公開です。

GitHubは2026年2月24日（米国時間）に、マルチエージェントが失敗する要因と、信頼性を高める設計手法を解説しました。

エージェントを増やすと、共有する状態の不整合、実行順序の推測に基づくエラー、曖昧な引き継ぎ、予測しにくい挙動といった新しい障害のリスクが出てくるといいます。

1つ目が型付きスキーマ（データの形を決めた約束事）です。エージェント間で受け渡すデータの形や型を明確に定めて、受け渡しの際に検証し、不正な形式のメッセージを早い段階で排除する。

スキーマ違反は契約違反として扱い、不正な状態が広がる前にリトライ（もう一度やり直すこと）、修復、エスカレーション（上の担当や人に引き上げること）を行います。

GitHubは、そうした設計が不可欠だと説明しています。

2つ目がアクションスキーマ。例えば「このイシュー（作業の依頼や不具合を書き留めた票）を分析してチームが対応できるようにする」という指示だと、対応が割れます。

エージェントによって、クローズ（票を閉じる）、アサイン（担当者を割り当てる）、エスカレーション、何もしない、と変わるんです。どれも合理的でも、自動化は難しくなるんです。

許可する操作の正確なセットを先に決める。判断結果は、少数の明示的なアクションに絞る。これがアクションスキーマです。

こうしたスキーマや制約を一貫して強制する層として、MCP（AIが外のツールとつながるための共通の約束）も有効だとGitHubは説明しています。

私の読みです。あなたがAIエージェントに仕事を渡す時も、渡す物の形と、選べる操作の数を決めるところが出発点だと受け止めました。

＠IT『マルチエージェント設計「15のパターン」』の「Googleの基本パターン（順番と振り分け）」より（2026年11月8日公開・第2章で引く部分）

例えば顧客サービスでは、請求書に関する問題なら請求担当のエージェントに、トラブルシューティングならテクニカルサポート担当のエージェントに誘導します。

請求の問題なら請求担当へ、トラブル対応ならサポート担当へ。依頼を見て合う担当に回す形が、パターン4です。順番に渡すパターン3と並べて整理します。

Googleは2025年12月16日に公式ブログで、マルチエージェントの8つの基本的なデザインパターンを解説しました。

単一のAIエージェントに多くの役割を持たせると、十分な性能を出せない可能性がある、という指摘が前提です。

パーサ（解析器）や批評家、ディスパッチャー（依頼を見て担当に振り分ける役）といった役割を各エージェントに割り当てます。

そうすれば、マイクロサービス（小さな機能ごとに分けて組み合わせる作り方）のAI版のような、モジュール化された信頼性の高いシステムを作れるとしています。

パターン3はシーケンシャルパイプライン。処理を終えたら、結果を次に渡す。それがこの構成です。組み立てラインのような、ワークフローの基本形。

PDFの処理なら、テキストへの変換、構造化データ（表のように整理した形のデータ）の抽出、要約の生成を、専門のエージェントが順番に担当します。

流れが一本なので各段階の入出力をつかみやすく、問題が起きた時の原因調査に向くそうです。

パターン4はコーディネーター／ディスパッチャー。連鎖ではなく意思決定者が要る場合の構成で、中央のエージェントが利用者の意図を分析し、専門エージェントに振り分けます。

顧客サービスの請求とトラブル対応が、その例。異なる種類の要求を受け、それぞれに専門的な対応が必要なシステムに合うということです。

私の読みです。順番に渡す型は、流れが見えやすい。振り分ける型は、入口が一つになる。あなたの仕事はどちらに近いか。まず眺めてみるのが近道かな。

＠IT『マルチエージェント設計「15のパターン」』の「並行分岐と階層的分解」より（2026年11月8日公開・第3章で引く部分）

全てのレビューが終わると、集約役のエージェントがフィードバックをまとめ、1つのレビューコメントを作成します。

並行して走らせた結果を、最後に一つにまとめる。大きな目標を、子に任せて結果を待つ。パターン5と6は、仕事を分ける型です。

パターン5の並行分岐／集約（タコ足）は、互いに依存しないタスクを複数のエージェントで同時に処理し、最後に統合する構成です。遅延が短くなり、多様な視点も得られます。

自動コードレビューなら、セキュリティ監査、スタイル準拠、パフォーマンス分析の各エージェントを同時に起動して、プルリクエスト（コードの変更を取り込んでもらう依頼）をレビューさせる。

全てのレビューが終わると、集約役のエージェントがフィードバックをまとめ、1つのレビューコメントを作ります。

パターン6の階層的分解（マトリョーシカ）は、タスクが1つのエージェントのコンテキストウィンドウ（AIが一度に読める文章の量）に収まらないほど大きい時の型です。

上位のエージェントが目標をサブタスクに分けて委任する構成です。ディスパッチャーとの違いは、親が一部のタスクだけを委任し、結果を待ってから自分の推論を続ける場合があること。

レポート作成なら、作成担当は自分でリサーチせずリサーチ担当に任せ、リサーチ担当がWeb検索と要約のツールを管理します。

AI氣道『サブエージェントを畳む前に、分けてよい仕事を決める』より

「私の判断の軸は、一つのボールは誰か一人が全部持ち、やり切る、というもの。所有者は一人です！」

分けるほど持ち主が分からなくなる、という見方を、私は『サブエージェントを畳む前に、分けてよい仕事を決める』で書いています。

ここで思い出したのが、サブエージェントを分けてよい仕事を決める話を扱った、私の記事の一文です。分けるほど、途中で誰の手にあるのか分からない仕事が出やすい。だから、分ける前に決めます。

最後まで運ぶ持ち主を一人にするのが私の軸です。並べてみます。元記事の「親は結果を待って自分の推論を続ける」と、同じ向きとして読めました。

＠IT『マルチエージェント設計「15のパターン」』の「生成者と批評家・反復的改良」より（2026年11月8日公開・第4章で引く部分）

生成者と批評家パターンが正誤（合格／不合格）に焦点を当てるのに対し、このパターンは質的な改善に焦点を当てているのが違いです。

作る役と確かめる役を、別のエージェントにする。パターン7と8は、その分け方の違いです。合否を決める型と、質を上げる型。

パターン7の生成者と批評家（編集デスク）は、コンテンツの作成と検証を分ける構成です。

生成者がドラフトを作り、批評家がハードコード（プログラムの中にあらかじめ書き込むこと）された基準や論理チェックでレビューします。特徴は条件付きループ（同じ手順を繰り返す流れ）。

Googleの2025年12月16日の解説では、SQL（データベースに問い合わせる文）を作るエージェントと、そのSQLが正しいか確認するエージェントを組み合わせた場合を見てみます。

合格すればループを抜けて内容が確定します。合格しなければ、具体的なフィードバックが生成者に戻り、作り直される。

構文チェックが要るコード生成や、コンプライアンスレビュー（法令や社内ルールに合っているかの確認）が要るコンテンツ作成に有用だということです。

パターン8の反復的改良（彫刻家）は、優れた成果物がドラフト1回で完成するのはまれ、という前提に立ちます。出力が特定の品質基準に達するまで、生成、批評、改良のサイクルを繰り返す型です。

生成者が粗いドラフトを作り、批評家が指摘し、改良担当がその指摘に基づいて磨き上げる。違いは焦点です。パターン7は正誤、反復的改良は質的な改善に焦点を当てています。

AI氣道『サブエージェントを畳む前に、分けてよい仕事を決める』の別の節より

「検収も作業を作らず、別の家のモデルを1回呼ぶ形にしています。」

作る側と確かめる側を分ける、という形を、私は『サブエージェントを畳む前に、分けてよい仕事を決める』で書いています。

この一文は、サブエージェントの記事の中で、検収（出来上がりを別の目で確かめること）の形を書いたところです。別の家のモデル、つまり作ったAIとは別の会社のAIを1回呼ぶ形にしています。

作る側と確かめる側を分ける。その向きは、パターン7の生成者と批評家と同じだな、と読みました。

＠IT『マルチエージェント設計「15のパターン」』の「ヒューマンインザループと複合パターン」より（2026年11月8日公開・第5章で引く部分）

重大なチェックが必要になると、承認ツールを呼び出して実行を一時停止し、人間のレビュー担当者の判断を待ちます。

重大な判断の前では、AIエージェントが止まる。人の承認を待つ。パターン9のヒューマンインザループ（重要な場面に人間が入って判断する設計）です。

Googleの2025年12月16日の解説では、AIエージェントに通常の処理を任せつつ、重大な判断や操作が必要な場合に人間の承認を求める構成です。

対象は特に、不可逆（やってしまうと元に戻せないこと）な行動や重大な結果を伴う行動で、安全性と説明責任を確保する狙いがあります。

例は、金融取引、本番環境へのコードデプロイ（作ったものを本番に反映すること）、機密データに基づく行動。

重大なチェックが必要になると、承認ツールを呼び出して実行をいったん止め、人間のレビュー担当者の判断を待つ流れです。

パターン10は複合パターン。Googleは、本番で動かすなら、これらのパターンを組み合わせることになるだろうと指摘しています。顧客サポートなら、振り分けにコーディネーターを使う。

技術的な問題なら、文書検索とユーザー履歴の各エージェントが同時に起動して並行処理します。最終回答は、送信前にトーンの一貫性を確かめるため、生成者と批評家のループを通る可能性があるそうです。

AI氣道『AIエージェントに作業は任せても判断は任せない、まさおさんが語るマネジメントの習慣』より

「止まって聞くのは、公開・送信・削除・Kindle本の出版申請などの、出す直前の最終確認と、私にしかできない操作だけ、と決まりました。」

止まる場所を出す直前に絞る、という決めごとを、私は『AIエージェントに作業は任せても判断は任せない、まさおさんが語るマネジメントの習慣』で書いています。

元記事は不可逆な操作の前で人間の承認を待つと書き、私の記事は、止まって聞くのは出す直前の最終確認と私にしかできない操作だけ、と書いています。途中の一つずつに承認は挟まない。止まる場所を絞る。

向きが同じだと読みました。

＠IT『マルチエージェント設計「15のパターン」』の「コンテスト上位作品の4パターン」より（2026年11月8日公開・第6章で引く部分）

参考にすべきは、フォールバックがあること自体ではなく、検証の置き場所です。

4つの工夫のうち、フォールバック（主に使うモデルが止まった時の代わりへの切り替え）の話は、検証をどこに置くかが主題です。

Googleは2026年9月2日、スタートアップ向けのAIエージェント開発コンテスト「Google for Startups AI Agents Challenge」の上位作品を分析し、共通する4つの設計パターンを公開しました。

パターン11は、自分用に作ったツールを他のエージェントにも提供する形。

多くの作品はMCPを一方向でしか使っていませんでしたが、あるチームはテレメトリー（機器から送られる計測データ）のデータベースをMCPのツール層経由で使いました。

さらに、同じ推論機能を、他のエージェントから呼べるMCPサーバとして公開しました。ツール層を挟めば必要なデータだけに絞れます。

制御下にない呼び出し元に提供する以上、実効性のあるアクセス制御が要る、という注意点つきです。

パターン12は、同じイベントに複数のエージェントを並行して反応させる形。転倒リスクを検知して担当者に通知するシステムは、直線的なパイプラインの初期版では対応可能な時間内に通知できませんでした。

そこで、エージェントごとにキュー（順番待ちの列）を持つ非同期（待たずに並行して進む）のイベントバス（出来事を発行して関心のあるエージェントだけが受け取る仕組み）を導入しました。

互いに依存しない処理を、同時に動かせるようにしたんです。

パターン13は、フォールバック先のモデルにも同じ検証基準を適用する形。

臨床推論エージェント（医療の現場で診断や治療を考える手助けをするエージェント）は、主系統のモデルが503エラー（サービスが一時的に使えないことを示す合図）を返し始めた時の別モデルを用意し、どちらの応答も同じ検証関数で確認してから受け入れました。

主系統用と待機系統用に検証を複製すると、片方だけ更新して他方を忘れやすいので、単一の関数を両方の経路から必ず呼ぶ構造にしたそうです。

パターン14は、高性能なAIモデルを呼ぶ前に段階的に振り分ける形。

3層の分類器（受信メッセージが何を求めているかを仕分ける仕掛け）を前段に置き、最初の1層だけで受信メッセージの40％超をモデルの呼び出し前に処理できた、とこのチームの計測は示しています。

私の読みです。4つとも、AIの手前や横に置く仕掛けの話で、主役のモデルの外側を整えるのが共通点かな。

＠IT『マルチエージェント設計「15のパターン」』の「Siemensの象を切り分ける」より（2026年11月8日公開・第7章で引く部分）

重要なのは、最初からAIにコードを書かせるのではなく、必要な情報の調査や変更の影響分析を先に実施する点です。

大きくて曖昧な仕事は、先に調べる。小さく切ってから任せる。パターン15の「象を切り分ける」は、その考え方の型です。

Google Cloudは2026年6月17日、Siemensと共同開発したAIシステム「Knowledge Fabric」を紹介しました。

ソフトウェア開発の工程の自動化が目的で、ナレッジグラフ（物事の関係を線でつないで整理したデータ）が土台です。

Siemensは数億行規模のレガシーコード（長年使われてきた古い作りのプログラム）を抱えていました。

重要な知識は、コードのほか、Jiraのチケット（プロジェクト管理ツールの依頼票）、Confluenceのページ（ナレッジ共有ツールの文書）、PDFマニュアルなどに散らばっていました。

既存のコーディング支援ツールでは、産業用コードを読み解くための文脈が足りなかったといいます。

象を切り分けるは、「このモジュールをリファクタリング（動きを変えずに中身を整理し直すこと）する」といった大まかな要求を、小さく扱いやすいタスクに分ける設計です。

AIエージェントが大規模で曖昧なタスクを苦手とすることが、プロジェクトを通じて分かり、採用されました。専門エージェントは5種類。

検索は、コードグラフ（コード同士の関係を整理したデータ）を探して、関連するドキュメントと照合します。ユーザーストーリーは、要件を集めて、受け入れ基準つきの要求（使う人の目線で書いた要求）にします。

アーキテクチャ影響は、変更の影響を実装の前に分析します。タスク分解は、作業を小さく分けます。コーディングは、個々のタスクの変更を実装します。

重要なのは、最初からAIにコードを書かせず、調査と影響分析を先にする点。各ステップにヒューマンインザループも入れて、本番運用に耐える信頼性を確保したそうです。

制御パネルをWebベースのインタフェースに移す本番パイロットでは、システムの整合性と産業品質基準を保ちながら、全体のコーディング工数を減らしました。

私の読みです。書かせる前に調べる。その順番がこの型の中心だと受け止めました。あなたの仕事でも同じかな。大きな頼みは、切ってから渡す。

＠IT『マルチエージェント設計「15のパターン」』の「GitHubの6つの基本原則」より（2026年11月8日公開・第8章で引く部分）

GitHubは、型付きスキーマ、制約されたアクション、MCPによって強制される構造化されたインタフェースを加えることで、エージェントは信頼性の高いシステムコンポーネントのように動作し始めると総括しています。

15のパターンは、受け渡し、役割分担、実行効率、大規模な作業の分解まで幅広く対応します。ただし、複数のエージェントを組み合わせるだけで信頼性が高まるわけではありません。

最後に、記事冒頭のGitHubの解説から、6つの基本原則が挙がります。失敗を前提に設計する。全てのエージェント境界で検証する。エージェントを追加する前にアクションを制約する。中間状態をログに記録する。

リトライと部分的な失敗を想定する。エージェントをチャットフローではなく分散システムとして扱う。境界はあるエージェントから次へ渡す場所、ログは途中経過の記録のことです。

GitHubの総括は、受け渡しの形と許す操作を決めれば、エージェントは部品として頼れるようになる、という内容でした。

その上で、エージェントはチャットインタフェースではなくコードとして扱うべきだと結論づけています。

AI氣道『AIエージェントに作業は任せても判断は任せない、まさおさんが語るマネジメントの習慣』の別の節より

「止まる条件が無い仕事は、見ていない間も間違った前提のまま進み、最後は私が見つけて戻すことになる。」

止まる条件を先に置く、という考えを、私は『AIエージェントに作業は任せても判断は任せない、まさおさんが語るマネジメントの習慣』で書いています。

元記事の「失敗を前提に設計する」と、私の記事の「止まる条件が無い仕事は、見ていない間も間違った前提のまま進む」を並べて読みました。どちらも向きは同じ。うまくいく前提で組まないことです。

15の型を自分の仕事のAIエージェントに当てはめるなら、型を増やす前に、次の順で決めるのが先だと読みます。①受け渡す内容を決まった形で書き出す（型1・2）。

対象は一番よく回す仕事1つ、10〜15分、完了の目安は項目名と入れる内容が一覧になっていること。②仕事ごとに最後まで運ぶ持ち主を一人に決める（型6・15）。

対象は分けている仕事すべて、10〜15分、完了の目安は各仕事に持ち主の名前が1つ付いていること。③人が止まる場所を、出す・送る・消す・払う直前に先に決める（型9）。

対象は外に出る操作、10〜15分、完了の目安は止まる場所の一覧が手元にあること。

＠ITの記事は、GitHub、Google、Siemensの知見から、15のデザインパターンと6つの基本原則をまとめていました。15の型は、受け渡し、流れ、確かめ、人が止まる場所、工夫の5つの束で言い直せます。

GitHubの総括は、エージェントを増やす前に、型付きスキーマ、制約されたアクション、MCPで強制される構造化されたインタフェースを整えることでした。

自分の仕事に当てはめるなら、型を増やす前に、受け渡しを決まった形で書き出す、仕事ごとに最後まで運ぶ持ち主を一人に決める、人が止まる場所を先に決める、のどれかから選ぶのが近道だと読みます。

私の過去記事の考えを、15の型に重ねて読めました。あなたは、どれから決めてみますか？

この記事で学んだことを誰かに教えて恩送りして学びを深めよう！