「.NET 開発基盤部会 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
概要 †
- 情報の収集・解析・意思決定・アクション実行を行うシステム
- あるサーベイ論文では、AIエージェントを「脳」「知覚」「アクション」という3つの要素で整理。
入力を「知覚」し「アクション」を計画的に実行する「脳」としてAIが機能することで、タスクを代行する。
- LLMエージェントについて「タスクを代行するもの」であるとして、最も原始的な実装であれば
- 入力に対応したワークフローを代行するようなものでも、エージェントと呼ぶことはできる。
- ただし、単一の呼び出しや、都度アドホック・プロンプト入力が必要なChatはエージェントとは呼べない。
エージェントの定義 †
エージェントらしさ †
最近の、LLMエージェント研究や実装では、次の要素が増えるほど「エージェントっぽい」とされる（≒ 自律性）。
デザインパターン †
Anthropic社が提示するデザインパターンが適用されている。
- ワークフロー型エージェント
ワークフローを持つエージェント・システムの5つのデザインパターン
- プロンプト・チェイニング：固定された一連のサブタスクに分解し、LLM呼び出しを連鎖させる方式
- ルーティング：LLMが入力を分類し、専門性の異なる複数のLLMの中から最適なものを選択
- パラレライゼーション：「コードが」タスクを複数に分割し、複数のLLMで同時処理、結果を束ねる。
- オーケストレーター・ワーカー：「LLMが」複雑なタスクを複数に分割し、複数のLLMで同時処理、結果を束ねる。
- エバリュエーター・オプティマイザー：生成LLM と 評価LLM の二段構えのフィードバックループ
- オープンエンド型エージェント
ワークフローの対極、オープンエンド型のエージェントデザインパターン
- 固定パスがない：一連のステップに従うのではなく、動的で流動的。
- 継続可能でフィードバックループがある：LLMは環境から情報を受け取りつつ繰り返し行動できる。
- 大きな柔軟性：より複雑で広範な問題を扱える。
- 予測不可能性：パス（時間、コスト）、出力（品質）が予測できない。
- 対策として、モニタリングやガードレールを実装
エージェントの †
開発スタイル †
AIエージェントをどう作るか？
| タイプ | 特徴 | 代表的なツール／例 |
| コーディング型 | LangGraph等のライブラリやPythonなどのプログラミング言語を用いてエージェントを実装する。柔軟性が高く、細かな制御やカスタマイズが可能。 | LangGraph、LangChain、OpenAI Agents SDK等 |
| ローコード・ワークフロー型 | GUIやノーコード環境で複数のアクションをつなぎ、チャットフローやツール呼び出しを組み立てる。業務担当者でも扱いやすいが、複雑なロジックは実装しにくい。 | Dify、LangFlow、n8nなど |
| プロンプト・エンジニアリング型 | MS Copilot Studioのようなツールでプロンプトやルールを記述し、LLMが内部的にエージェントを組み立てる。素早く試作できるが、動作のブラックボックス化に注意。 | MS Copilot Studio、LibreChat?、Watsonx Orchestrator |
※ 上から下に、プリミティブ → ハイ・レベル。
パーソナライズ †
AIエージェントの業務特化性能（現場適応レベル）
| レベル | 概要 | 対応ツール・技術 |
| Human-in-theLoop | １ | 人の詳細な指示と知識DBからの情報を生成AIに入力し、その結果出力して要求に対応 | RAG等 |
| ２ | 事前に人が定義した計画(フロー)に即して生成AIや知識DB、ツール等活用し要求に対応 | プロンプト・フロー |
| Human-on-theLoop | ３ | 要求理解・計画立案・行動/ツール活用にも生成AIを活用し、自律的に要求に対応 | ユーザがAgentにインストラクション |
| ４ | レベル3に加え、利用者に応じたパーソナライズした要求理解や要求対応を実施 | Text-to-LoRA等、コンテキストを踏まえた回答生成容易化 |
| Human-out-of-theLoop | ５ | レベル4に加え、継続的な自己改善の能力を持ち、成長し続けることが可能 | Agentの外部・内部の振舞いの可視化を通じた自己改善 |
※ Human-x-theLoop とは、業務特化型AI（現場適応型AI）において、人間（Human）がAIの自律的成長（theLoop）に、どの程度（x）介入（監督・判断）するかを表す。
※ フレームワークで実装したエージェントは、レベル2〜3を確実に実現し、レベル4の一部にも到達するが、プロダクションや企業の業務での導入はまだこれからとされている。
例と工夫 †
以下の5つの分野の有名なAIエージェントとその工夫
リサーチ †
GPT Researcher
シミュレーション †
Generative Agents
ゲーム †
- Voyager
- できるだけ多様な発見をすることを最終目標として行動するMinecraftを自動プレイするAIエージェント
- Minecraftのクライアントライブラリ (JavaScript)を使った「スキル」を生成して使用
- PokéLLMon
- 過去のターンのフィードバックやポケモンの技などの外部知識をプロンプトに含めることで、不利な選択をしないように制御
- 相手が強力なポケモンだとパニック状態になってポケモンの入れ替えを繰り返すのを防ぐよう、Self-Consistency (自己整合性) プロンプティングを使用
ソフトウェア開発 †
- ChatDev?
- プログラマー・テスター・デザイナーなど、様々な役割のAIエージェントに共同作業させて、自動でソフトウェアを開発させる
汎用のコンピュータ操作 †
詳細 †
構成要素 †
LLMエージェントは通常、以下のような構成要素を持つ
LLM本体 †
自然言語の理解・生成を担当する中核部分。タスクの実行や推論を行う。
メモリ †
- 会話履歴やタスクの進行状況などを保持。
- VDBやRDBを使用した長期的な記憶も可能。
ツール / プラグイン †
コントローラー †
- プランナーとLLMのやりとりを制御。ループを回す。
- 別のエージェントに切り出せるが、単一エージェントのツールとしても実装できる。
プランナー †
- ゴールに向けタスクを分割し、順序立てて実行計画を作る。
- 別のエージェントに切り出せるが、単一エージェントのツールとしても実装できる。
アクション実行器 †
- LLMの計画した出力に従って具体的なアクションを実行するモジュール。
- 別のエージェントに切り出せるが、単一エージェントのツールとしても実装できる。
思考ループ（Reasoning Loop） †
- 多くのLLMエージェントは以下のような思考ループ（Reasoning Loop）で動作している。
- 与えられたインストラクションから以下のステップで動作するように設計・実装されている。
- 実装によって名称や粒度は異なるが、概念的にはほぼ同じ構造で動いている。
タスクの理解（Goal Recognition） †
ユーザーから与えられた指示や問いを分析し、何を達成すべきかを明確にする。
- 自然言語で書かれた曖昧な指示から「最終的な目的」を推測する能力が求められる。
- LLMエージェントは、文脈や過去の対話履歴も考慮して目的を解釈する。
プランの生成（Plan） †
目的を達成するための一連の手順や方針（プラン）を考案する。
- Web検索が必要 → 検索 → 情報要約 → 回答生成、のようなステップ分割。
- 単純なプランではタスク分割、複雑なプランには外部ツール（計算機、検索エンジン等）との連携も含まれる。
次のアクションの選択（Reason） †
- プランに基づき、今の状況において最も適切な次のアクションを選ぶ。
- 「今なにをするべきか？」という意思決定プロセスであり、状況に応じた柔軟な判断が求められる。
- ここでは推論（Reasoning）能力が重要となる。
アクションの実行（Act） †
- 選択したアクションを実行する。
- 実行対象は、ツールの呼び出し、情報取得、外部APIへのアクセス、またはユーザーへの返答など。
- 実行結果は次のステップに活かされる。
観測と反省（Reflect） †
- アクションの結果を観察し、目的に近づいたか、想定とずれがないかを評価する。
- 不十分な結果が出た場合は原因を考え、改善点を洗い出す。
- エージェントが「何がうまくいかなかったか」を自己評価する重要な段階。
再計画（Replan） †
- 反省の結果に基づき、プランの修正・更新を行う。
- 新たな情報や環境の変化に応じて、アクションの優先順位や順序を再構築する。
- その後、再び次のアクションの選択へとループが戻る。
- 上記のステップを繰り返しながら、最終的な目標達成を目指す。
- このループは、ユーザーが満足する結果を得るまで、あるいは明示的な停止条件が満たされるまで続く。
- このような思考ループは、自律エージェントにおいて特に重要な「目的志向の行動」が可能となる基盤。
推論・行動戦略 †
推論・行動戦略（Reasoning & Acting Paradigms）に関する代表的アプローチ
- 思考ループ（Reasoning Loop）が、LLMエージェントがタスクを遂行する際の抽象的なプロセス・モデルであるとすると、
- 推論・行動戦略（Reasoning & Acting Paradigms）は、そのプロセスをどのように実装するかの具体的な戦略・アルゴリズムとなる。
- LLMベースのAIエージェントには、以下の5つの実装方法があり、「ReAct」が有名だが他にも多くの手法がある。
MRKL †
MRKL（Modular Reasoning, Knowledge and Language）
- 概要：AIエージェントが複数のツールを統合的に使うためのモジュラー・アーキテクチャ。
- 特徴：モデルが入力を解析し、適切なツールにタスクを振り分けて実行。LLMは「どのツールを使うべきか」を推論する役割。
- MRKLは、OpenAIの論文「ReAct?: Synergizing Reasoning and Acting in Language Models」などでも言及されている。
| Reasoning Loop | MRKL の対応 |
| Goal Recognition | LLM が入力から目的を抽出 |
| Plan | ほぼ行わない（短期的） |
| Reason | どの専門モジュール（ツール）を使うかを推論 |
| Act | 選択したツールを実行 |
| Reflect | ツール結果を受け取り再推論 |
| Replan | 必要に応じて別ツールを選択 |
ReAct?（Reasoning + Acting）
- 概要：思考（Reasoning）と行動（Acting）を交互に繰り返すことで、LLMがより柔軟かつ強力な問題解決を行うフレームワーク。
- 特徴：思考（Reason）と行動（Act）を交互に繰り返し、最も思考ループらしく「Reason → Act → Reflect」をそのまま実装した戦略
- 論文：Yao et al., 2022（例：「Let's think step by step」のようなプロンプト技法を拡張）
- エージェントはActだけでも実装できるが、Reason（思考過程を言語化）してからAct（実行内容を言語化）させる「ReAct?」の精度がよかったという論文
- Reasonなし・Actなし
- Reasonあり・Actなし (CoT)
- Reasonなし・Actあり (WebGPTのようなもの)
- Reasonあり・Actあり (ReAct?)
| Reasoning Loop | ReAct? の対応 |
| Goal Recognition | LLM がタスクを理解 |
| Plan | 明示的な長期計画は作らない |
| Reason | 「次に何をすべきか」を逐次推論 |
| Act | 推論に基づきツール実行 |
| Reflect | 観測結果を「Observation」として取り込み内省 |
| Replan | 次の Reason で自然に再計画 |
Plan-and-Solve †
- 概要：問題を解く前に、まず全体の計画（Plan）を立て、それに従ってステップごとに解決する「Plan」フェーズを強化した戦略で長期タスク・複雑タスクに強い。
- 特徴：「まず計画を立ててから解く」→ 思考の整理ができ、正確な回答率が上がる。CoTのような技法と組み合わせて使用される。
| Reasoning Loop | Plan-and-Solve の対応 |
| Goal Recognition | タスク理解 |
| Plan | 最初に詳細な計画を生成（中核） |
| Reason | 計画に沿ってステップを推論 |
| Act | 必要ならツール実行 |
| Reflect | 計画との差異を確認 |
| Replan | 計画が破綻した場合に再計画 |
LLMCompiler †
- 概要：タスクの自然言語仕様をプログラム的な実行計画やコードに「コンパイル」するLLMベースの手法。
- 特徴：
- LLMが自然言語からタスクグラフや関数構成などを生成。
- プログラムのような表現を通じて複雑なタスクを実行可能にする。
- 「計画＝プログラム」「再計画＝デバッグ」という形で Reasoning Loop を実装する。
- 応用：マルチステップの意思決定やエージェントプランニングなど。
| Reasoning Loop | LLMCompiler の対応 |
| Goal Recognition | タスクを形式的に理解 |
| Plan | タスクをプログラム構造に分解（強い） |
| Reason | プログラムの各ステップを推論 |
| Act | 実行環境でコードを実行 |
| Reflect | 実行結果を検証（テスト） |
| Replan | コード修正（self-debug）として再計画 |
デファクト標準 †
LLM/Agent の世界では、言語生成機であるLLMを「外部システムと連携する実行エンジン」に変える基盤技術として、
「Function Calling」と「Structured Outputs」が「事実上の標準（デファクト・スタンダード）」
Function calling †
- LLMに特定のAPIや関数を呼び出させ外部タスクを実行する仕組み。
- OpenAI Function calling
- Anthropic tool use
- Gemini tool calling
- LLMが自然言語から適切な関数名と引数を構造化出力（JSON）。
- 関数をLLMに使わせる事で、外部のツール・APIと接続可
- 高精度なツール選択と使い分けが可能
Structured Outputs †
- LLMの出力形式を厳密な構造（JSON等）に制約する仕組み。
- OpenAI Structured Outputs
- JSON Schema
- Pydantic model
- 事前定義したスキーマ（型・必須項目・制約）に適合させて出力させる。
- 出力の型安全性・検証可能性が高く、後段処理（パース・保存・検証）が安定。
- 関数実行を伴わず、データ抽出・要約・分類・設定生成などに適する。
2つの技術の類似点 †
Function Calling と Structured Outputs の 類似点
- 「LLM を自然言語の世界から構造化データの世界へ橋渡しする」という本質が同じ。
- 両者とも、以下の点で本質的に同じ方向性を持つため。
- LLM の出力を構造化し、外部システムと安全に連携させる制御技術
- JSON Schema を使い、揺らぎを抑え、機械可読なデータを返す
- どちらも「LLM の出力を構造化する」技術
自然文ではなく、機械が扱える構造化データを LLM に強制する。
- Function Calling：関数呼び出しの引数を 構造化データ で返す
- Structured Outputs：任意のスキーマに従った 構造化データ を返す
- 構造化データの前提スキーマがSON Schema
- Function Calling：関数の引数定義は JSON Schema
- Structured Outputs：出力スキーマは JSON Schema
- LLM の曖昧さ・揺らぎを抑制し信頼性・再現性を高める仕組み
- 余計な文章を生成しない
- フォーマットが揺れない
- パース可能なデータが返る
- 外部システムと連携するための“インターフェース”
- Function Calling：外部 API を呼ぶための入力インターフェース
- Structured Outputs：外部 API に渡すための出力インターフェース
- エージェント通信プロトコルの基盤
- A2A、MCP、Azure Agents などのプロトコル設計の前提となっている。
- 理由は人間は自然言語で要求してもエージェント通信は構造化データで行う必要があるため。
... †
標準化 †
対象 †
- Tool Registry / Metadata
ツールや機能の定義情報（引数、用途など）を共有するためのスキーマ
- Agent-to-Agent Protocols
複数エージェントがやり取りする際の通信仕様（メッセージ構造や状態管理）
- Observability
エージェントの動作トレース、ログ記録の標準フォーマット（OpenTelemetry?などと連携）
団体 †
- Anthropic, Google, Meta
独自API提供＋相互運用性の議論に参加（例: AI Alliance）
- W3C / ISOなど
将来的な正式標準化の議論も一部で始動
- Agent Protocol Community
自主的なコミュニティ駆動の標準仕様作成
プロトコル †
| プロトコル | 主目的 | 主導 | 主な対象 | 例えるなら |
| MCP | ツール呼び出しの標準化 | Anthropic | LLM → ツール | 手足の使い方のルール |
| ACP | エージェント間通信 | BeeAI/コミュニティ | エージェント⇔エージェント | 会話のルール |
| A2A | 異企業エージェント連携 | Google Cloud | 異なるプラットフォームのエージェント | 国際共通語 |
| 観点 | A2A | ACP |
| 主目的 | クロスベンダー相互運用性 | ローカル/エッジ自律性 |
| 想定環境 | クラウド・分散システム | エッジ・帯域制限環境 |
| 通信方式 | HTTP/HTTPS, JSON-RPC, SSE | 軽量メッセージング |
| セキュリティ | OAuth2, API Key, スコープ制御 | ローカル前提で軽量 |
| 状態管理 | セッション/タスク/メモリを包括的に管理 | 必要最小限 |
| エージェント発見 | Agent Card によるメタデータ | なし（軽量） |
| ガバナンス | Linux Foundation（Google → 移管） | Linux Foundation（IBM 系） |
| 得意領域 | 異種システム連携、大規模協業 | プライバシー重視、低遅延 |
AIモデルと外部システムのやりとりを標準化するオープン・プロトコル
- AIモデルと外部エージェントのやりとりを標準化するオープン・プロトコル
- ローカル/エッジでの軽量・低遅延・プライバシー重視
- 将来的に A2A に“統合される／継承される”方向。
- AIモデルと外部エージェントのやりとりを標準化するオープン・プロトコル
- クラウド横断の相互運用性・高度な協業・強力なセキュリティ
- ACPより上位の次世代標準だが実装複雑性/パフォーマンスでは劣る。
マルチエージェント †
LLMマルチエージェントは、LLMを用いた複数のエージェントが連携・協調・競合しながらタスクを遂行するシステムや枠組みのことを指す。
利用例 †
- ソフトウェア開発支援：プロジェクトの要件を受けて、複数のエージェントが設計、実装、レビュー、テストを分担。
- 複雑な意思決定支援：複数の視点から情報を収集・分析し、意見を統合して提案を生成。
- 教育やチュータリング：異なる学習スタイルや領域に対応した複数のエージェントが、個別に支援。
PE技法 †
PE技法のReActは「単体エージェントの内部推論フレーム」として機能しているが、
マルチエージェントでは、PE技法のSelf-Consistency, GKP, Self-Ask, ToT, AoTを、
連携方式（協調スタイル/制御・通信モデル/共有リソースモデル）によって、明示的または暗黙的にシミュレーションできる。
- Self-Consistency（自己整合性）
- 関係性：マルチエージェントが独立に推論を行い、それらの出力から最も整合的なものを選ぶという点で一致。
- シミュレーション性：高い。各エージェントを一つの「自己実行のバリエーション」と見なすことで、Self-Consistencyの仕組みと同様の効果が得られる。
- GKP（Generated Knowledge Prompting）
- 関係性：あるエージェントが生成した知識を別のエージェントが利用するという点で、GKP的。
- シミュレーション性：中〜高。知識共有や知識ベースのプロンプティングが実装されていれば、かなり近い。
- Self-Ask
- 関係性：タスク分解や質問の生成→他エージェントに解決させるプロセスが、Self-Askの「質問して自分で答える」構造に似る。
- シミュレーション性：高。特に質問応答・サブタスク分担型のマルチエージェントシステムでは、Self-Askに近い設計になる。
- ToT（Tree of Thoughts）
- 関係性：各エージェントが「思考の分岐」や「候補生成」に相当する役割を担うことで、ToTの木構造探索を模倣。
- シミュレーション性：中〜高。特に評価・選択メカニズムを持つマルチエージェント構成では、ToT的な探索が可能。
- AoT（Algorithm of Thoughts）
- 関係性：タスク解決を「アルゴリズム」として明示的に分解し、各部分をエージェントに割り当てることで、AoTに似た形になる。
- シミュレーション性：高。構造化された役割分担とステップ的な思考展開はAoTそのものに近い。
実装例 †
- Generative Agents
- 架空の町（例: Smallville）に複数のエージェントが暮らし、日常生活を送る。
- 各エージェントは「観察」「記憶」「計画」「行動」などのモジュールを持つ。
- GPT-4などのLLMで内面の思考・対話・行動を生成。
- ChatDev?：
- 開発プロセスを企業のようにモデル化（例: CEO、CTO、プログラマー、テスターなどの役割）。
- 各役職に対応するLLMエージェントが協調してコードを設計・実装・レビュー。
- 各フェーズでチャットを通じて議論・意思決定。
連携方式 †
マルチエージェントはエージェント同士が連携し機能する。この連携の方式には様々なものがある。
- 協調スタイル
エージェントが「どう協力するか」という抽象的なスタイル。
- 協調型
「共通の目的」を持つが役割が異なるエージェント同士が、互いに情報共有しながら協力してタスクを達成する方式。
- 競合型
協調型の反対で、複数のエージェントが「同じタスクに対して別々の解」を生成し、最終的に最も良い案を選ぶ方式。
- 混合型
協調型と競合型を組み合わせた方式で、「部分的に協力しつつ、重要な局面では競合させる」など柔軟な構造を取る。
- MoE型
複数の「専門家エージェント（Expert）」が存在（Mixture of Experts）し、ゲート（Router） が「割り当て」を選択する方式。
| スタイル | 関係性 | 強み | 弱み | 向いている用途 |
| 協調型 | 協力 | 安定性・網羅性 | 遅い・通信コスト | ワークフロー、分析 |
| 競合 | 競争 | 多様性・創造性 | コスト高 | アイデア生成、最適化 |
| 混合型 | 協力＋競争 | バランス良い | 設計が複雑 | 研究開発、大規模推論 |
| MoE型 | 専門家選択 | 専門性・効率 | ゲート依存 | 大規模モデル、専門タスク |
- 制御モデル
エージェント全体を「誰がどう制御するか」？また、中央集権か、分散自律か、役割分担かという観点。
- 役割分担
- どのように役割を分けて協調するかも重要な構造
- 各エージェントは専門性を持たせ、以下のような役割に分かれることが多い
- プランナー（Planner）実行者（Executor）評価者（Critic / Judge）専門家エージェント（Domain Expert）
- プランナー（Planner）、リサーチャー（Researcher）、エンジニア（Coder）、レビュワー（Reviewer）
- メタ・エージェント
全体を制御する「指揮官」的エージェント
- オーケストレーション
中央の調整者（オーケストレーター）が、複数エージェント（サブエージェント）の実行順序・依存関係・情報フローを管理
- マスターエージェント
オーケストレーションに似ているが、より「意思決定の中心」としてのマスターが存在するモデル。
- 自己組織化
LLMエージェント特有の現象として、明示的な制御なしに協調が生まれる。
- ブラックボード上で暗黙的にタスクを拾い合う
- エージェント同士が互いの出力を読み合い、自然に役割分担が形成される
- 通信モデル
エージェント同士が「どうやって情報をやり取りするか」。
- 同期メッセージ
エージェント同士がチャットする様な。送信側が応答を待つ通信方式。リクエスト/レスポンス型
- 非同期メッセージ
送信側が応答を待たずに処理を続行する方式。キューに蓄積され、受信側は後で処理するためスケーラブル。
- イベント駆動
- 非同期メッセージの一形態で、疎結合でスケールし易い方式
- エージェントが、Kafka や EventHub? のようなイベントストリームで連携し、必要なときだけ反応
- チェーン構造
- エージェントが順番で直線的に（明確なタスクフローで）タスクを引き継ぐ方式。
- Agent A → Agent B → Agent C（意図分類 → 情報検索 → 要約 → 検証）
- グラフ構造
- エージェント同士の関係をグラフとして定義、複数の経路・分岐・合流を持つ構造。
- 状況に応じて分岐（最適なエージェントにルーティング）する方式
- ノード：エージェント、エッジ：通信経路、ルーター：次エージェントの選択
- 通信プロトコル
エージェント間通信の「規格・インターフェース」であり、通信モデルにも関係する。
- API：同期/非同期メッセージ
- ACP：非同期メッセージ
- A2A：非同期メッセージ
- RPC/REST：同期メッセージ
- Pub/Sub プロトコル：イベント駆動
- 共有リソースモデル
複数エージェントが「何を共有して協調するか」。
- ブラックボード
複数のエージェントが中央の知識共有ボード（ブラックボード）に書き込み・読み取りを行いながら問題解決を進める協調方式
- メモリ共有
複数エージェントが同一のメモリ領域（変数・データ構造）を直接読み書きする方式。ブラックボードより軽量で、状態共有に向く。
- 共有ワークスペース
ブラックボードは「問題解決のための知識ベース」だが共有ワークスペースはタスク中心で、ボード、成果物、メッセージ、メタ情報を置く。
- 状態管理
「状態の一貫性を保つため各エージェントの状態（context, goal, progress, memory）を管理し、必要に応じて共有する方式。
- 制御を別のエージェントに移すことで、同期メッセージの場合に発生（非同期イベントでは発生しない）。
- ハンドオフに関連するケース（≒ 同期メッセージのケース）
・チェーン構造、グラフ構造では、次のエージェントが処理を開始するタイミングでハンドオフがされる。
・制御モデルのオーケストレーション・マスターエージェントではハンドオフしないケースが多い。
- 非同期メッセージのACP/A2Aでのハンドオフは、制御ハンドオフではなく責務ハンドオフに該当する。
- エージェント同士がチャットする方式
フレームワークの仕組みがあればブラックボックスで使うだけでも良いが、
実際に実装しようとすると、以下のような、様々なアーキテクチャから選択する必要がある。
- 通信モデルは非同期が基本だが同期でもできなくはない。
- 制御モデルはオーケストレーション/マスターエージェントが基本
- （つまりタスク分配や調停を行うファシリテーター的なメタ・エージェントを介在させる）
- ただし、「エージェント間でピアツーピア通信を行い、局所的なルールで全体の挙動を決定する」完全分散（スウォーム型）と言う方式もある。
フレームワーク †
全体比較（要点）
| 観点 | OpenAI Agents SDK | CrewAI | LangGraph | AutoGen |
| 思想 | 制御・安全 | 人的分業 | 状態遷移 | 会話駆動 |
| 抽象度 | 低〜中 | 高 | 中 | 中 |
| 再現性 | 高 | 中 | 非常に高 | 低〜中 |
| 本番向き | ◎ | △ | ◎ | △ |
| 研究向き | △ | △ | ○ | ◎ |
参考 †
https://speakerdeck.com/os1ma/imakosoxue-bullmbesunoaiezientoru-men-ji-ben-de-nasikumi-slash-kai-fa-turu-slash-you-ming-naossyalun-wen-noshao-jie
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
