create_agentでエージェントを作り、公式の5つのパターン（Subagents・Handoffs・Skills・Router・Custom workflow）から構成を選ぶのが基本です。まずは1つのエージェントで足りないかを確かめ、足りない部分だけを専門のエージェントに分けると、複雑になりすぎずに済みます。
お疲れ様です！IT業界で働くアライグマです！
「AIエージェントを複数連携させたいけど、どう設計すればいいか分からない…」
「LangChainでマルチエージェントを実装したが、エージェント間の通信が複雑で管理しきれない…」
「タスク分散の仕組みを作りたいが、エラーハンドリングや状態管理の方法が見えてこない…」
こうした悩みを抱えているエンジニアの方は多いのではないでしょうか。
1つのエージェントに道具や指示を詰め込みすぎると、どの道具を使うべきか迷って精度が落ちることがあり、役割を分けたくなる場面が出てきます。
本記事では、LangChainを用いたマルチエージェントシステムの構築手法について、LangChainの公式ドキュメント（2026年11月時点）で確かめた構成パターンと、実装・運用の設計の考え方を解説します。
マルチエージェントシステムの基礎概念と実務での位置づけ
マルチエージェントシステムは、複数のAIエージェントが役割を分けて協調し、問題を解決する仕組みです。
LangChain 1.0では、エージェントはcreate_agentで作るのが標準で、公式のリリースノートでは、このcreate_agentがLangGraphの上に作られていると説明されています。
実務におけるマルチエージェントシステムの価値は、役割ごとに指示と道具を絞れることにあります。
たとえばカスタマーサポートなら、問い合わせを分類するエージェント、回答を作るエージェント、回答を確かめるエージェントに分けると、それぞれのプロンプトを短く具体的にでき、どこで間違えたのかも追いやすくなります。
マルチエージェントシステムの3つの核心要素
マルチエージェントシステムには、実務で特に重要な3つの要素があります。
第一に、エージェントの自律性があります。
各エージェントは独立した意思決定能力を持ち、与えられた目標に向けて自律的に行動します。
これにより、システム全体の柔軟性が向上し、予期しない状況にも対応できるようになります。
第二に、エージェント間の受け渡しがあります。
LangChainの公式パターンでは、ほかのエージェントを「ツール」として呼び出したり、ツール呼び出しで状態を書き換えて担当を切り替えたりする形で、エージェント同士がつながります。
第三に、タスクの分け方があります。
複雑なタスクを適切に分割し、各エージェントに割り当てる仕組みです。
お互いに依存しないタスクを見つけて並行して進められるようにすると、全体の時間も短くできます。
単一エージェントとマルチエージェントの使い分け
単一エージェントは、シンプルなタスクに適しています。
一方、マルチエージェントは複雑で多段階のタスクに威力を発揮します。
ただし、エージェントを分けるほど、受け渡しの手間とLLMを呼ぶ回数が増えます。
まずは1つのエージェントで作ってみて、「道具が多すぎて選び間違える」「指示が長くなりすぎて守られない」といった問題が出たところで、その部分だけを別のエージェントに切り出すのが安全です。
LangChainにおけるエージェント実装の基本構造
LangChain 1.0では、langchain.agentsのcreate_agentに、モデル・ツール・システムプロンプトを渡してエージェントを作ります。
以前のlanggraph.prebuilt.create_react_agentを使っていたコードは、公式の移行ガイドでもcreate_agentへの置き換えが勧められています。
from langchain.agents import create_agent
def search_docs(query: str) -> str:
"""社内ドキュメントを検索する"""
...
research_agent = create_agent(
model="openai:gpt-5", # 使うモデルに合わせて変える
tools=[search_docs],
system_prompt="あなたは社内ドキュメントの調査担当です。",
)create_agentはLangGraphの上で動くので、状態の保存（persistence）やストリーミング、人の承認をはさむ仕組み（human-in-the-loop）も使えます。
AIエージェントのテストの考え方は、AIエージェント開発ガイドも参考になります。
IT女子 アラ美
ITアライグマLangChainによるエージェント実装の基本パターン
LangChainでエージェントを実装する際は、エージェントの役割定義が最も重要です。
各エージェントが担当する責務を明確にし、適切なツールとプロンプトを設定することで、システム全体の効率が決まります。
たとえばデータ分析を自動化するなら、データ収集・前処理・分析・レポート作成のように、扱う道具と求める出力がはっきり違う単位で分けると、それぞれの指示を具体的に書けます。
マルチエージェントの公式の構成パターン
LangChainの公式ドキュメントでは、マルチエージェントの構成として次の5つのパターンが紹介されています。
- Subagents：メインのエージェントが、ほかのエージェントを「ツール」として呼び出す。どのエージェントにいつ頼むかはメインのエージェントが決める
- Handoffs：ツール呼び出しで状態を書き換え、担当のエージェントや設定を切り替える。エージェント同士がツール呼び出しで制御を渡し合う
- Skills：1つのエージェントが主導権を持ったまま、必要なときだけ専門のプロンプトや知識を読み込む
- Router：最初に入力を分類して、1つ以上の専門のエージェントに振り分け、結果をまとめて返す
- Custom workflow：LangGraphで、決まった処理の流れとエージェントの判断を組み合わせた独自の流れを作る
これらは組み合わせて使うこともできます。
迷ったら、全体の流れを1つのエージェントが握るSubagentsから始めると、どこで何が起きたかを追いやすくなります。
個々のエージェントの考え方
それぞれのエージェントの中の動き方としては、推論（Reasoning）と行動（Acting）を交互に繰り返すReActの考え方が基本です。
create_agentで作るエージェントも、モデルがツールを呼び、その結果を見て次の行動を決める、というループで動きます。
最初に全体の計画を立ててから順に実行させたいときは、計画を立てる役と実行する役を分け、上のパターンで組み合わせます。
ツールとメモリの統合手法
エージェントの能力は、利用可能なツールによって決まります。
LangChainでは、API呼び出し、データベースアクセス、ファイル操作など、多様なツールを定義できます。
実務では、ツールの選定と組み合わせが重要です。
1つのエージェントに渡すツールが多すぎると、どれを使うかの判断を誤りやすくなるので、役割に必要なものだけに絞ります。
例えば、データ収集のエージェントにはWeb APIを呼ぶツールを、分析のエージェントにはデータを集計するツールを、というように分けます。
記憶（メモリ）の扱いは、LangChain 1.0で大きく変わりました。
公式ドキュメントでは、エージェントに短期記憶（スレッド単位の会話の保存）を持たせるには、create_agentにcheckpointerを渡すと説明されています。
会話の履歴はエージェントの状態（state）のmessagesとして管理され、同じthread_idを渡せば前の会話の続きとして扱われます。
from langgraph.checkpoint.memory import InMemorySaver
agent = create_agent(model="openai:gpt-5", tools=[search_docs], checkpointer=InMemorySaver())
agent.invoke(
{"messages": [{"role": "user", "content": "先週の障害の資料を探して"}]},
{"configurable": {"thread_id": "user-123"}},
)本番では、メモリの中ではなくPostgresSaverなどでデータベースに保存します。
以前よく使われたConversationChainなどの古いチェーンは、LangChain 1.0ではlangchain-classicパッケージに移されています。
プロンプトエンジニアリングの実践
エージェントの動作は、プロンプト設計に大きく依存します。
役割、目標、制約条件を明確に記述することで、エージェントの意図しない動作を防げます。
プロンプトのテンプレートには、エージェントの役割、入力データの形式、期待される出力の形式、うまくいかないときの対応、の4つを必ず入れるようにすると、新しいエージェントを足すときも迷いません。
IT女子 アラ美ITアライグマエージェント間通信プロトコルの設計手法
マルチエージェントシステムでは、エージェント間の受け渡しの設計がシステム全体の信頼性を左右します。
LangChainの公式パターンでは、受け渡しは主に「ツール呼び出し」と「状態（state）」を通して行います。
受け渡す内容の形をそろえる
Subagentsのように、ほかのエージェントをツールとして呼ぶ場合は、そのツールの引数と戻り値が、エージェント間で受け渡す情報の形になります。
自由な文章のまま受け渡すと、受け取る側の解釈がぶれやすいので、Pydanticのモデルなどで「どの項目を、どの型で返すか」を決めておくと、エラーの原因を追いやすくなります。
状態を共有するか、結果だけを渡すか
Handoffsのように担当を切り替える構成では、会話の履歴などの状態を次のエージェントに引き継ぎます。
一方、Subagentsでは、呼び出されたエージェントの途中のやり取りは返さず、最終的な結果だけをメインのエージェントに返す形にできます。
全部の途中経過を共有すると、文脈が長くなって費用も判断の迷いも増えます。
次のエージェントが本当に必要とする情報だけを渡すのが基本です。
受け渡しのエラーのハンドリング戦略
エージェント間の受け渡しでは、エラーハンドリングが重要です。
LLMのAPIのタイムアウトや、期待した形式で答えが返ってこないなど、様々なエラーが起こりえます。
一時的なエラーには、待ち時間を伸ばしながらの再試行（リトライ）を、連続して失敗する相手には、しばらく呼び出しを止めるサーキットブレーカーを使うと、1か所の失敗が全体に広がるのを防げます。
IT女子 アラ美ITアライグマタスク分散と協調動作の実装戦略
マルチエージェントシステムの最大の利点は、タスクの並列処理です。
お互いに依存しないタスクを別のエージェントに並行して任せれば、待ち時間を短くできます。
ただし、どれだけ速くなるかは、タスクの分け方とLLMの応答時間しだいなので、自分のタスクで測って確かめます。
タスク分割の基本原則
タスク分割には、3つの基本原則があります。
第一に、独立性の原則です。
各タスクは可能な限り独立して実行できるよう設計します。
依存関係が少ないほど、並列処理の効率が向上します。
第二に、粒度の原則です。
タスクの粒度は、エージェントの処理能力とオーバーヘッドのバランスを考慮して決定します。
細かく分けすぎると、LLMを呼ぶ回数と受け渡しの手間ばかりが増えてしまいます。
第三に、負荷分散の原則です。
各エージェントの負荷が均等になるよう、タスクを動的に割り当てます。
これにより、特定のエージェントがボトルネックになることを防げます。
協調動作のパターン
エージェント間の協調動作には、複数のパターンがあります。
パイプラインパターンでは、エージェントが直列に接続され、前のエージェントの出力が次のエージェントの入力になります。
データ処理フローが明確な場合に適しています。
マスター・ワーカーパターンでは、マスターエージェントがタスクを分配し、ワーカーエージェントが並列で処理します。
大量のデータを処理する場合に有効です。
ピアツーピアパターンでは、エージェント同士が対等な関係で協調します。
柔軟な協調が必要な場合に適しています。
LangChainの公式パターンに当てはめると、パイプラインはCustom workflow、マスター・ワーカーはSubagentsやRouterに近い形で作れます。
タスクの特性に応じて、これらのパターンを使い分けます。
動的なタスクの割り当て
同じ種類のエージェントを複数動かす場合、決まった順に割り当てるだけだと、時間のかかるタスクを抱えたエージェントで待ちが発生します。
タスクをキューに入れ、空いたエージェントから順に取り出す形にすると、処理時間のばらつきがあっても全体が詰まりにくくなります。
エージェントの数を増やせば必ず速くなるわけではなく、受け渡しの手間やLLMのAPIのレート制限で、どこかで効果が頭打ちになります。
何体まで増やすと効果があるかは、自分のタスクで数を変えて測りながら決めます。
IT女子 アラ美ITアライグマエラーハンドリングと状態管理のベストプラクティス
マルチエージェントシステムでは、エラーハンドリングが複雑になります。
単一エージェントのエラーがシステム全体に波及しないよう、適切な分離と回復メカニズムが必要です。
ここでは、実務で押さえたい考え方をまとめます。
エラー分離と回復戦略
エラー分離の基本は、フェイルセーフ設計です。
1つのエージェントが失敗しても、他のエージェントは動作を継続できるよう設計します。
エージェントごとにエラーの扱いを決め、まずそのエージェントの中で回復を試み、それでもだめなときだけ呼び出し元に「失敗した」と伝える形にすると、1か所の失敗で全体が止まるのを防げます。
回復の方法には、リトライ、フォールバック、補償トランザクションの3つがあります。
リトライは一時的なエラーに対応し、フォールバックは代わりのモデルや手段に切り替え、補償トランザクションは途中まで進んだ処理を取り消します。
状態管理とトランザクション制御
マルチエージェントシステムでは、状態の一貫性を保つことが難しくなります。
複数のエージェントが同時に状態を更新すると、競合が発生する可能性があります。
エージェントが外部のデータベースを書き換える場合は、競合が少なければ楽観的ロック、多ければ悲観的ロックのように、一般的なアプリと同じ考え方で一貫性を守ります。
複数のエージェントにまたがる長い処理は、Sagaパターンのように小さな処理の連鎖として作り、途中で失敗したら、それまでの処理を取り消す補償の処理を順に実行します。
エージェントの会話の状態そのものは、前の章のcheckpointerで保存しておくと、途中から再開することもできます。
ログとモニタリングの実装
マルチエージェントシステムでは、可観測性が重要です。
各エージェントの動作を追跡し、問題を早期に発見できる仕組みが必要です。
各エージェントの処理の開始・終了、呼び出したツール、エラー、かかった時間をJSON形式のログに残し、1つの依頼を最後まで追えるように同じIDを付けておきます。
LangChainの公式ドキュメントでは、エージェントの動きを追跡・評価するサービスとしてLangSmithも案内されています。
応答時間、エラー率、LLMの呼び出し回数と費用などの指標は、Prometheusなどで集めてダッシュボードで見られるようにしておきます。
IT女子 アラ美ITアライグマ実運用での性能最適化とスケーリング手法
マルチエージェントシステムを本番環境で運用する際は、性能最適化が不可欠です。
開発環境では問題なく動作していても、本番の負荷では性能が低下することがあります。
ボトルネック分析と最適化
性能最適化の第一歩は、ボトルネックの特定です。
マルチエージェントでは、処理時間の大半がLLMの応答待ちであることが多いので、まずはどのエージェントのどの呼び出しに時間がかかっているかをログやトレースで確かめます。
LLMの呼び出し回数を減らす（受け渡しを減らす、要らないエージェントを外す）ことや、お互いに依存しない呼び出しを並行させることが、最も効く改善になりやすいところです。
エージェントが使うツールの中でデータベースを読んでいるなら、N+1問題やまとめて取れる処理がないかも見直します。
水平スケーリングと負荷分散
システムの負荷が増加した場合、水平スケーリングが有効です。
エージェントを動かすワーカーの数を増やすことで、同時にさばける依頼の数を増やせます。
Kubernetesなら、CPU使用率やキューにたまったタスクの数に応じて、ワーカーの数を自動で増減させられます。
依頼はメッセージキューで受け付けてワーカーに配ると、急に依頼が増えても受け付けを止めずに済みます。
ただし、LLMのAPIのレート制限は増やしたワーカーで共有されるので、上限に当たらないかも確かめます。
コスト最適化とリソース管理
本番運用では、コスト最適化も重要な課題です。
マルチエージェントでは、サーバーの費用より、LLMのAPIの費用のほうが大きくなりがちです。
分類や振り分けのような簡単な役割のエージェントには軽量で安いモデルを使い、難しい判断をするエージェントにだけ上位モデルを使う、という使い分けが効きます。
同じ前置きを毎回渡す使い方なら、モデルの提供元のプロンプトキャッシュも活用します。
IT女子 アラ美ITアライグマよくある質問
LangChain 1.0でエージェントを作るには何を使えばよいですか？
langchain.agentsのcreate_agentを使います。
公式の移行ガイドでは、以前のlanggraph.prebuilt.create_react_agentからcreate_agentへの置き換えが勧められています。
ConversationBufferMemoryは今も使えますか？
LangChain 1.0では、エージェントの短期記憶はcreate_agentにcheckpointerを渡して持たせる形が公式の方法です。
古いチェーンなどはlangchain-classicパッケージに移されているので、新しく作るならcheckpointerとthread_idを使います。
マルチエージェントはどのパターンから始めればよいですか？
迷ったら、メインのエージェントがほかのエージェントをツールとして呼び出すSubagentsから始めると、流れを追いやすくなります。
入力の種類で振り分けるだけならRouter、担当を切り替えながら会話を続けたいならHandoffsを検討します。
IT女子 アラ美ITアライグマまとめ
本記事では、LangChainを用いたマルチエージェントシステムの構築手法について解説しました。
マルチエージェントシステムは、役割ごとに指示と道具を絞り、複雑なタスクを分担して進めるための仕組みです。
LangChain 1.0では、create_agentで作ったエージェントを、Subagents・Handoffs・Skills・Router・Custom workflowの公式パターンで組み合わせ、記憶はcheckpointerで持たせます。
一方で、エージェントを分けるほど受け渡しとLLMの呼び出しが増え、システムも複雑になります。
まずは1つのエージェントで作り、困った部分だけを切り出す形で、段階的に広げていくことをお勧めします。
IT女子 アラ美ITアライグマ
