専門家一覧
LangGraphによる階層型マルチエージェント・ワークフローの設計

LangGraph階層型設計：エージェント組織図で作る制御可能なマルチエージェント・テンプレート集

この記事は急速に進化する技術について解説しています。最新情報は公式ドキュメントをご確認ください。

約11分で読めます
文字サイズ:
LangGraph階層型設計：エージェント組織図で作る制御可能なマルチエージェント・テンプレート集
目次

導入

「複数のAIエージェントを連携させれば、複雑なタスクも自動化できるはずだ」

そう意気込んでLangGraphでマルチエージェントシステムを構築し始めたものの、いざ動かしてみるとエージェント同士が延々と会話を続けたり、期待した通りにタスクが完了しなかったりといった経験はないでしょうか。

システム受託開発やECサイト構築支援、業務効率化ツール開発などのプロジェクトにおいて、AIを組み込んだシステムの需要が急速に高まっています。しかし、LangGraphは非常に強力なフレームワークである反面、エージェントの数が増えるにつれて、その制御は指数関数的に難しくなります。特に、全エージェントが対等な立場で会話する「フラット型」の構成では、誰が決定権を持つのか曖昧になりがちで、これが無限ループの温床となります。

そこでおすすめしているのが、人間の組織図になぞらえた「階層型（Hierarchical）」のアプローチです。プロジェクトリーダーが各担当者にタスクを振るように、AIにも明確な上下関係と役割を持たせることで、論理的かつ体系的な制御が可能になります。

この記事では、実務の現場で活用されているプロンプトの設計パターンを「テンプレート」として公開します。単なるコード例ではなく、「なぜその指示が必要なのか」という設計意図（Intent）も含めて体系的に整理していますので、ぜひ実際のプロジェクトに合わせてカスタマイズしてみてください。

1. このテンプレート集の目的と活用法

まず、なぜ「階層型」にする必要があるのか、その背景を論理的に整理します。

なぜ「階層型」設計が必要なのか

LangChainやLangGraphのチュートリアルにある単純なチャットボットであれば、単一のエージェントや、数体のエージェントが順列（Sequential）で動くだけで十分機能します。しかし、実際の業務アプリケーション開発では、以下のような課題に直面することは珍しくありません。

  • 要件の曖昧性: ユーザーの指示が具体的でなく、まずは要件定義やヒアリングが必要になる
  • ツールの多様性: Web検索、社内DB参照、計算処理、API連携など、使用するツールが多岐にわたる
  • 品質管理の必要性: 出力結果に対して、誤りがないかチェック（Review）する工程が必須である

これらをすべて1つのプロンプト、あるいは対等な関係のエージェント群（フラットな構造）で処理しようとすると、コンテキスト（文脈）が複雑になりすぎます。その結果、LLMは「今何をすべきか」を見失い、幻覚（ハルシネーション）を起こしたり、同じツールを何度も呼び出す無限ループに陥ったりするリスクが高まります。

LangGraphにおけるSupervisorモデルの利点

そこで有効なのが、Supervisor（監督者）を置く階層型構成です。LangGraphの最新版では、サブグラフの制御や状態管理機能が強化されており、このモデルをより堅牢に実装できるようになっています。

  • 責任の分離: Supervisorは「誰にタスクを割り振るか」という指揮命令に専念し、Worker（作業者エージェント）は「どう実行するか」という実務だけに集中します。
  • 状態管理の単純化: 各エージェントは自分に必要な情報だけを受け取り、結果だけを返せば良くなります。LangGraphのチェックポイント機能（Checkpointer）を活用することで、複雑なフローでも状態を確実に保持・復元できます。
  • 拡張性と保守性: 新しい機能が必要になった場合、新しいWorkerを追加し、Supervisorに「こういう時はこのWorkerを使って」とルーティングルールを教えるだけで済みます。既存のエージェントへの影響を最小限に抑えられます。

本テンプレートの適用範囲とカスタマイズ方針

今回紹介するテンプレートは、このSupervisorモデルを前提としています。LangGraphの最新仕様（機能強化された制御フローなど）に対応した設計となっていますが、そのままコピー＆ペーストして終わりではありません。

これらはあくまで、プロジェクトの「組織図」を作るためのひな形です。実際の業務フローに合わせて、以下の視点でカスタマイズして活用してください。

  1. Workerの専門性定義: 必要な役割（例：法務チェック担当、コードレビュー担当）に置き換える
  2. ルールの調整: Supervisorがどのような基準でタスクを振り分けるか、プロンプトを調整する
  3. ツールの選定: 各Workerが使用するツールを、実際の業務APIやデータベース接続に差し替える

次章からは、具体的なコードとともに、この「組織図」の実装方法を解説します。

2. プロンプト設計の基本：エージェントに「職務記述書」を与える

プロンプト設計の基本：エージェントに「職務記述書」を与える - Section Image

マルチエージェントシステムにおいて、システムプロンプト（System Message）は、プロジェクトメンバーに渡す「職務記述書（Job Description）」そのものです。

曖昧な職務記述書ではメンバーが動けないのと同様に、AIエージェントにも以下の3点を明確に定義する必要があります。

  1. Role（役割）: あなたは何者で、ミッションは何か。
  2. Constraints（制約）: やってはいけないこと、守るべきルールは何か。
  3. Tools & Output（道具と成果物）: どのツールを使い、どのような形式で報告すべきか。

状態（State）の共有と引き継ぎルール

LangGraphの肝は State（状態）の管理です。プロンプト内では、常に「現在のState」を意識させる記述が重要です。

例えば、「過去の会話履歴を見て、重複した作業をするな」という指示を入れるだけで、無駄なAPIコールを劇的に減らせます。また、次のエージェントにバトンを渡す際、「FINAL ANSWER」という特定のキーワードを含めるかどうかで終了判定を行うテクニックも実用的です。

では、具体的なテンプレートを見ていきましょう。

3. テンプレート①：Supervisor（監督者）エージェント

テンプレート①：Supervisor（監督者）エージェント - Section Image

システムの中核となる司令塔です。このエージェントは原則としてツールを使いません（ルーティング用の構造化出力ツールを除く）。ユーザーの意図を論理的に理解し、適切な専門家に仕事を振り、最終的にユーザーへ回答するのが仕事です。

プロンプトテンプレート：司令塔の振る舞い

# Role
あなたは高度なAIアシスタントチームの監督者（Supervisor）です。
あなたの役割は、ユーザーの複雑な要求を理解し、配下の専門エージェント（Workers）にタスクを割り振ることです。
あなた自身はタスクを実行しません。適切なWorkerを選択し、指示を出すことに専念してください。

# Workers
以下の専門エージェントが利用可能です：

1. Researcher: Web検索やデータベース検索を行い、情報を収集します。
   - [Intent] 情報不足の際や、最新データが必要な場合に呼び出す。

2. Coder: Pythonコードの生成と実行、データ分析を行います。
   - [Intent] 計算、グラフ作成、ファイル処理が必要な場合に呼び出す。

3. Reviewer: 生成された成果物の品質チェックを行います。
   - [Intent] 最終回答をユーザーに出す前に必ず通す品質ゲート。

# Constraints
- ユーザーの要求が一度のステップで解決できない場合は、ステップバイステップで計画を立ててください。
- 無限ループを防ぐため、同じWorkerに同じ指示を3回以上繰り返さないでください。
- すべてのタスクが完了し、Reviewerの承認が得られた場合のみ、"FINISH"として最終回答を出力してください。

# Decision Logic
現在の会話履歴（messages）を確認し、次に誰が動くべきかを判断してください。
- 情報が足りない -> Researcher
- 情報はあるが加工が必要 -> Coder
- 成果物ができた -> Reviewer
- ReviewerがNGを出した -> 修正担当のWorkerへ差し戻し
- ReviewerがOKを出した -> FINISH

解説：なぜこの記述が必要か

  • # Workers: ここで利用可能な手札を提示します。各Workerが「何が得意か」だけでなく、「どういう時に呼ぶべきか（Intent）」まで書くのが実践的なアプローチです。
  • # Decision Logic: LLMは文脈によっては迷うことがあります。if-thenのようなロジックを自然言語で明記しておくことで、ルーティングの精度が安定します。
  • FINISHシグナル: LangGraphの条件付きエッジ（Conditional Edge）でフローを終了させるためのトリガーワードを定義しています。

4. テンプレート②：Specialized Worker（専門作業者）エージェント

次は、実際に手を動かす作業者です。ここでは「検索担当（Researcher）」を例にします。ポイントは、余計な判断をさせないことです。

プロンプトテンプレート：職人の振る舞い

# Role
あなたはWeb検索と情報収集に特化した専門リサーチャーです。
Supervisorからの指示に従い、必要な情報だけを正確に収集してください。

# Tools
利用可能なツール: [TavilySearch, WikipediaRetriever]

# Instructions
1. 与えられた指示に対して、最適な検索クエリを作成してください。
2. ツールを使用して情報を取得してください。
3. 取得した情報は、事実に基づいて要約してください。個人の意見や推測は不要です。
4. 情報が見つからない場合は、正直に「見つかりません」と報告してください。捏造は厳禁です。

# Output Format
収集した情報は以下のフォーマットで報告してください：

-- Research Report --
[概要]
...
[詳細]
...
[出典ソース]
...
-- End Report --

# Constraints
- ユーザーへの最終回答は行わないでください。あなたの仕事はSupervisorへの報告までです。
- 1回の実行で複数の検索クエリを発行しても構いませんが、応答時間は意識してください。

解説：職人に徹させる

  • # Constraintsの「最終回答は行わない」: これが非常に重要です。Workerが勝手に「以上です、ありがとうございました」と会話を締めてしまうと、Supervisorが結果を取りまとめられなくなります。「あくまで中間報告である」という意識を持たせます。
  • # Output Format: 後続のエージェント（CoderやSupervisor）がパースしやすいように、特定のヘッダーやフッターで囲む形式を指定します。

5. テンプレート③：Reviewer（品質管理者）エージェント

AIエージェントの実用性を高めるための鍵となるのが、このReviewerです。人間が介在する前（Human-in-the-loop）の防波堤として機能します。

プロンプトテンプレート：検品係の振る舞い

# Role
あなたは品質管理担当のReviewerです。
他のWorkerが生成した成果物が、ユーザーの当初の要求を満たしているか、正確であるかを厳しくチェックします。

# Checklist
以下の基準で評価してください：
1. 網羅性: ユーザーの質問すべてに答えているか？
2. 正確性: 数値や事実に矛盾はないか？
3. 安全性: 有害なコンテンツや不適切な表現はないか？
4. 形式: 指定されたフォーマットに従っているか？

# Action
- 承認（Approve）: 全ての基準を満たしている場合。
  - 出力: "APPROVED"
- 却下（Reject）: 修正が必要な場合。
  - 出力: 具体的な修正指示（例：「数値の根拠ソースが不足しています。Researcherに再調査させてください」）

# Constraints
- あなた自身は修正作業を行いません。指摘を行うだけです。
- 些細な表現の違いで却下しないでください。本質的な欠陥のみを指摘してください。

解説：フィードバックループの構築

  • # Action: ここでの出力が、Supervisorの次のルーティング判断（条件分岐）に使われます。"APPROVED"なら終了、それ以外ならループ継続、というロジックをLangGraph側で組みます。
  • 自己修正の禁止: Reviewer自身に修正させると、能力オーバーで品質が下がることがあります。修正はあくまで専門のWorkerに戻す（フィードバックループ）のが体系的な設計の鉄則です。

6. テンプレート④：実装コード生成用メタプロンプト

ここまで設計できれば、あとはPythonコードに落とし込むだけです。しかし、LangGraphのノード定義やエッジ接続の記述（add_node, add_edge, add_conditional_edges）はボイラープレート（定型コード）になりがちです。

そこで、設計した役割定義からコードを自動生成するための「開発者支援用プロンプト」も紹介します。これをChatGPTやClaudeの最新モデルに投げれば、実装の大部分を効率化できます。

開発者支援用プロンプトテンプレート

あなたはLangGraphのエキスパートエンジニアです。
以下の「エージェント定義」に基づいて、LangGraphを用いた階層型マルチエージェントシステムのPythonコードを生成してください。

# 要件
- ライブラリ: langgraph, langchain, langchain_openai
- 構成: Supervisor-Workerパターン
- State: TypedDictを使用し、messagesキーを持つこと
- モデル: OpenAIの最新モデル（またはClaudeの最新モデル）

# エージェント定義
[ここに先ほどのSupervisor, Worker, Reviewerのプロンプト定義を貼り付ける]

# 出力すべきコード
1. 各Agentのノード関数定義（create_agentヘルパー関数を使用）
2. Supervisorのルーティングロジック（function_callまたはstructured_outputを使用）
3. StateGraphの定義
4. add_node, add_edgeによるグラフ構築
5. graph.compile()までの完全な実行可能コード

解説：開発工数の短縮と最新の開発フロー

このメタプロンプトを使うことで、手動でのコーディングミスを減らし、ロジックの検証に時間を割くことができます。特にグラフの接続部分は複雑になりやすいので、AIに生成させた土台を修正するアプローチが効率的です。

さらに、GitHub CopilotやCursorなどのAIコーディングエディタを使用している場合は、より高度な連携が可能です。例えば、GitHub Copilotの@workspaceコマンドやCursorのComposer機能（Agent Mode）を活用すれば、プロジェクト内の既存ファイル構成を考慮した上で、このテンプレートに基づいたコードを適切なディレクトリに生成させることもできます。

単発のコード生成だけでなく、IDE統合型のエージェント機能を活用して、定義書から実装までをシームレスにつなぐのが現代的かつ実践的な開発スタイルと言えるでしょう。

7. 実装時の失敗パターンと改善チェックリスト

最後に、テンプレート通りに実装してもうまくいかない場合のチェックリストを共有します。

よくある「無限会話ループ」の原因

SupervisorとWorkerがお互いに「お願いします」「了解しました」と挨拶し続けてループが終わらないケースがあります。
これは、プロンプトに「挨拶不要」「結果のみ返す」という制約が弱い場合に起こります。特に日本語のLLMは丁寧すぎる傾向があるため、System Messageで強く制約する必要があります。

トークン消費量の爆発を防ぐコツ

会話履歴（Messages）をすべて保持し続けると、コンテキストウィンドウが溢れ、コストも嵩みます。

  • 要約ノードの導入: ステップが一定数を超えたら、過去の会話を要約するノードを挟む。
  • メッセージのフィルタリング: Workerには全体の履歴ではなく、直前の指示と必要なコンテキストだけを渡す。

デバッグと最適化のステップ

LangSmithなどのトレースツールは必須です。「なぜSupervisorがそのWorkerを選んだのか」を確認するには、Supervisorの思考プロセス（Chain of Thought）を出力させるのも有効です。ただし、本番運用時はトークン節約のためにCoTをオフにするなど、開発フェーズに応じた調整を行いましょう。

まとめ

Role - Section Image 3

LangGraphを用いた階層型マルチエージェント・ワークフローは、複雑な業務プロセスを自動化するための強力な武器になります。

今回ご紹介したテンプレートは、あくまで「型」です。実際の現場では、業務特有のルールや例外処理が無数に存在します。

  • 「自社の業務フローをどうエージェント組織図に落とし込めばいいか分からない」
  • 「実装してみたが、意図通りに制御できない」
  • 「本番運用を見据えたコスト管理やセキュリティ設計に不安がある」

もしそのような課題をお持ちの場合は、専門家に相談して最適なエージェント設計とアーキテクチャ構築を進めることをおすすめします。論理的な設計図を描き、実践的なアプローチでプロジェクトを成功に導きましょう。

LangGraph階層型設計：エージェント組織図で作る制御可能なマルチエージェント・テンプレート集 - Conclusion Image

コメント

コメントは1週間で消えます
0 / 150
コメントを読み込み中...