マルチエージェントの現在地を整理してみた

Transcript

1. マルチエージェントの 現在地を調べてみた Yuki Sogawa Oracle Japan
2. 自己紹介 曽川 宥輝 日本オラクル CloudNative/AI,ML ク ラウドエンジニア バックグラウンド 大阪大学でデータセンターの省電力化の研究をしていました 趣味 ギター、バイク、ゲームなど 2 Copyright © 2026, Oracle and/or its affiliates
3. Agenda 3 Copyright © 2026, Oracle and/or its affiliates 1 2 3 4 エージェントの基礎 マルチエージェント エージェントのオブザーバビリティ まとめ
4. エージェントの基礎
5. AIエージェントとは Gartner*では以下のように定義されている AIエージェントは、アプリやクラウドといったデジタル環境、そしてロボットやセンサー機器といった物理的な環境 で、AIの手法を使って状況を把握し、判断し、行動し、目標を達成できる自律（または半自律）のソフトウェアです 従来のAIツールとの違いを考えると・・・ 1. チャットボットは事前定義されたルールに基づく一問一答型 • 推論・学習機能を持たない 2. LLMを利用したもの（ChatGPTなど）はユーザーの質問に「答える」ことに最適化 • 柔軟に質問に答えることはできるが、LLM単体では自ら計画を立てて実行することはできない 3. AIエージェント • 目標を与えるだけで、自ら計画を立て、ツールを使い分け、実行結果を評価し、自己修正をしながらタスクを 完遂する 5 Copyright © 2026, Oracle and/or its affiliates ※ https://www.gartner.co.jp/ja/articles/ai-agents
6. AIエージェントの構成要素 • モデル • ツール • メモリ • ナレッジベース • オーケストレーション 6 Copyright © 2026, Oracle and/or its affiliates オーケストレー ション モデル ツール メモリ ナレッジベース ユーザー
7. AIエージェントの構成要素 モデル エージェントの頭脳に相当する モデルを選択する際には、賢さとレイテンシーやコストとのトレードオフを考える • 高度な思考を要求する場合は、コストやレイテンシーは妥協が必要 • レイテンシーを下げたい場合は、賢さは妥協が必要 7 Copyright © 2026, Oracle and/or its affiliates 大きいモデル 小さいモデル レイテンシー: 低い コスト: 低い モデルの性能: 低い レイテンシー: 高い コスト: 高い モデルの性能: 高い
8. AIエージェントの構成要素 ツール エージェントが外部に作用するために必要 主に3つのカテゴリーがある • ローカルツール • エージェントのコードに実装されているツール • 内部で解決するもの（計算処理や、ローカルにあるファイル参照など） • APIベースのツール • エージェントのコードの実装されているツール • 外部のAPIを呼び出す • MCP • エージェントの外に実装されているツール ツールといえばMCPのようなイメージがあるが、MCPは選択肢の一つ 8 Copyright © 2026, Oracle and/or its affiliates
9. ローカルツールの例 9 Copyright © 2026, Oracle and/or its affiliates langchain_coreのtoolsデコレータを使ってツールを定義 処理は内部で完結する https://github.com/sogawa-yk/orajam-multi-agent/tree/main/tools/local_tools
10. APIベースのツールの例 10 Copyright © 2026, Oracle and/or its affiliates langchain_coreのtoolsデコレータを使ってツールを定義 外部のAPIを呼び出す https://github.com/sogawa-yk/orajam-multi-agent/tree/main/tools/api_tools
11. MCPの例 11 Copyright © 2026, Oracle and/or its affiliates MCPサーバーとの接続設定 MCPサーバーのツールをLangChain ツールとして読み込む https://github.com/sogawa-yk/orajam-multi-agent/tree/main/tools/mcp_tools
12. エージェントの構成要素 メモリ LLMは関数なので、状態（記憶）を保持することができない ChatGPTなどで、以前の会話内容を覚えているように見えるのは、毎回LLMの入力に以前の会話内容を入れているため 12 Copyright © 2026, Oracle and/or its affiliates 記憶を保持する仕組みが必要
13. コンテキストエンジニアリング LLMに対する入力を組み立てる LLMに対する入力を、コンテキストという 何をLLMに入力するかが、LLMの推論品質を高めるために非常に重要 メモリの内容などを使って、コンテキストを組み立てる 13 Copyright © 2026, Oracle and/or its affiliates 短期メモリ 長期メモリ ナレッジストア 今のユーザー入力 ツール定義 必要な情報を抽出 [System Prompt] [Tool Definitions] [Retrieved Context(RAG)] [Long-term Memory] [Short-term Memory / Conversation History] [Current User/Agent Input] [Scratchpad / Intermediate State] コンテキスト LLM
14. デモ エージェントにメモリがないとどうなるか 14 Copyright © 2026, Oracle and/or its affiliates https://github.com/sogawa-yk/orajam-multi-agent/tree/main/memory/no-memory
15. デモ エージェントにメモリがあるとどうなるか 15 Copyright © 2026, Oracle and/or its affiliates https://github.com/sogawa-yk/orajam-multi-agent/tree/main/memory/with-memory-responses-api
16. AIエージェントの構成要素 メモリ エージェントの記憶を保持する メモリには２種類ある • 短期メモリ • 現在のタスクを実行中に保持する記憶を格納する • 会話履歴などに用いる • 長期メモリ • タスクを横断して保持する記憶を格納する • 過去の成功パターンや、ユーザーの行動に基づくパーソナライズに用いる 16 Copyright © 2026, Oracle and/or its affiliates
17. 短期メモリを利用しない場合のコード 17 Copyright © 2026, Oracle and/or its affiliates 今回のユーザー入力だけを入れることになる
18. 短期メモリを利用する場合のコード Responses APIの場合 18 Copyright © 2026, Oracle and/or its affiliates 前回のレスポンスのIDも含めて リクエストを投げる https://github.com/sogawa-yk/orajam-multi-agent/tree/main/memory/with-memory-responses-api
19. 短期メモリを利用する場合のコード Conversations APIの場合 19 Copyright © 2026, Oracle and/or its affiliates 会話のIDを指定する https://github.com/sogawa-yk/orajam-multi-agent/tree/main/memory/with-memory-conversations-api
20. （参考）Response IDによる会話チェーン 20 Copyright © 2026, Oracle and/or its affiliates Response IDで会話チェーンを表現する場合、リクエス トの際に任意のレスポンスIDを指定する • ある程度を会話を進めた後に戻る（rewind） • レスポンスIDだけわかっていれば良いので管理が楽 などのメリットがある Conversations APIを使う場合は、Conversation IDを指定す る（チェーンにはならない）
21. 短期メモリ 実装場所 エージェントのインスタンス メリット • 最速でアクセスできる • 外部サービスが増えない デメリット • インスタンスが落ちると消える • スティッキーセッションが必須 Redis, Valkeyなどのデータストア メリット • 高速アクセス • スティッキーセッション不要 デメリット • 運用の手間 • 耐久性は努力目標 Oracle, PostgreSQLなどのRDB メリット • 強い耐久性とトランザクション • 状態がSQLで検査できる デメリット • レイテンシが大きい • RDBは永続化する場所なので、短 期化が表現しづらい Copyright © 2026, Oracle and/or its affiliates 21 メモリ エージェント のロジック エージェントのインスタンス エージェント のロジック メモリ エージェントの インスタンス Redisの インスタンス エージェント のロジック メモリ エージェントの インスタンス RDBの インスタンス
22. 短期メモリの基本的な管理 • ローリングコンテキストウィンドウ • LLMを使った要約 などを利用する 22 Copyright © 2026, Oracle and/or its affiliates ローリングコンテキストウィンドウ LLMを使った要約
23. AIエージェントの構成要素 長期メモリ 短期メモリは、1つの会話セッション内で使うメモリだった 長期メモリは、会話を跨いで保持する情報に使用する 例えば • ユーザー固有の恒久情報（名前や所属、好みなど） • タスク状態の永続化（長時間にわたるタスクの情報など） • エピソード記憶（過去の類似ケース参照や、継続的プロジェクトの文脈など） 23 Copyright © 2026, Oracle and/or its affiliates
24. デモ 長期メモリがないとどうなるか 24 Copyright © 2026, Oracle and/or its affiliates 新しい会話を作成すると 会話を跨いだ記憶はない
25. デモ 長期メモリがあると 25 Copyright © 2026, Oracle and/or its affiliates 新しい会話を作成すると 会話を跨いで記憶を保持している https://github.com/sogawa-yk/orajam-multi-agent/tree/main/memory/long-term-memory
26. 長期メモリの利用方法 26 Copyright © 2026, Oracle and/or its affiliates memory_subject_idをリクエスト時に送る ユーザーごとにこのIDを管理しておけば、 ユーザーごとに属性を記憶できる
27. 長期メモリの管理 いつ書き込むか • 即時書き込み • バッチ書き込み • ２段階書き込み 記憶の抽出と圧縮 • LLMを使った要約 • 時間経過に応じて削除 どう読み出すか • すべて読み出す • ベクトル検索で関連するものを読み出す 27 Copyright © 2026, Oracle and/or its affiliates 他にも様々な方法がある これと言った正解があるわけではないので、 ユースケースに応じて最適化する必要がある
28. 長期メモリ管理の例 28 Copyright © 2026, Oracle and/or its affiliates ユーザー AI ①会話内容を埋め込みモデルに 埋め込みモデル 随時内容を要約 ②メモリに保存 要約モデル ③メモリを参照 長期メモリ
29. AIエージェントの構成要素 ナレッジベース AIエージェントに与える、静的な情報を格納する（動的な情報はメモリに格納） ここに入る情報は、必ずしも1つのエージェント専用の情報である必要はなく、共用してもOK 29 Copyright © 2026, Oracle and/or its affiliates ユーザー AI オブジェクトストア ベクトルストア 必要な時に参照 埋め込みモデル 定期的に同期 社内規則などの静的な ドキュメントを配置
30. AIエージェントの構成要素 オーケストレーション エージェントが複雑なタスクを実行するための実行設計のこと AIエージェントの実装の多くがオーケストレーション部分だと思ってOK 実行の制御を行う上では、以下のことを考慮しておく必要がある • エージェントの種類 • 今回はここのみお話しします • ツール選択方法 • ツールトポロジー 30 Copyright © 2026, Oracle and/or its affiliates
31. エージェントの種類 エージェントにはいろいろな種類がある • ReAct • Planner-Executor • Reflection など 31 Copyright © 2026, Oracle and/or its affiliates
32. ReAct 各ステップ「考える → 行動する → 観察する」のループを回し、状況を見ながら次の手を動的に判断するパターン 32 Copyright © 2026, Oracle and/or its affiliates メリット • 各ステップLLMが判断するので、状況の変化に柔軟に対応で きる • ツールの実行結果を見て次の行動を決めるため、事前に手 順を決められないタスクをこなせる デメリット • 各ステップLLM呼び出しが発生するため、コストと遅延が大 きい • １ステップごとに計画するため、局所最適な判断を行なっ てしまう
33. デモ ReAct 33 Copyright © 2026, Oracle and/or its affiliates https://github.com/sogawa-yk/orajam-multi-agent/tree/main/orchestration/react
34. Planner-Executor 最初に全体計画を立て、あとはその計画通りに実行するパターン 34 Copyright © 2026, Oracle and/or its affiliates メリット • 高価な大きいモデルを呼ぶのはPlannerの１回で済む • 計画が先に確定するため、予測可能でデバッグしやすい デメリット • 実行中に状況が変わっても計画を変更できない
35. デモ Planner-Executor 35 Copyright © 2026, Oracle and/or its affiliates https://github.com/sogawa-yk/orajam-multi-agent/tree/main/orchestration/planner_executor
36. Reflection ReActのループに「自己検証」のステップを挟み込むパターン 36 Copyright © 2026, Oracle and/or its affiliates メリット • ReActの弱点である「局所最適な判断の積み重ね」を緩和で きる デメリット • 検証のための追加LLM呼び出しが発生するため、コストと遅 延がさらに増える
37. デモ Reflection 37 Copyright © 2026, Oracle and/or its affiliates https://github.com/sogawa-yk/orajam-multi-agent/tree/main/orchestration/reflection
38. オーケストレーションのデザインパターンの変化 モデルが賢くなるにつれて、オーケストレーションのデザインパターンも変化してきている 38 Copyright © 2026, Oracle and/or its affiliates 従来 • グラフで制御フローを組む • ステートマシンを設計する • ノード間の遷移を書く 制御ロジックを設計することが焦点 現在 • ReActループに任せる • コンテキストをステートとしてReActに渡して、 ス テートマシンは設計しない ツール・スキル・コンテキストを設計することが焦点
39. シングルエージェントの限界 エージェントのステートとしてコンテキストを扱うが、モデルが持つことのできるコンテキストには限界がある つまり、コンテキストに入りきらない情報が必要なタスクは物理的にシングルエージェントでは解くことができない コンテキストエンジニアリングを徹底して、コンテキストを小さくすればシングルエージェントで解ける幅が広がる が、それでも物理的な制約は避けられない 39 Copyright © 2026, Oracle and/or its affiliates 余裕があるので素朴な実装 で対応できる コンテキストエンジニアリ ングでギリギリ対応できる 頑張ってもコンテキストサ イズから溢れてしまう マルチエージェントにして、 コンテキストを分離する必要 がある
40. マルチエージェント
41. マルチエージェントとは 複数の自律エージェントが協調するシステム マルチエージェントシステムは以下の３要素で構成される 41 Copyright © 2026, Oracle and/or its affiliates エージェント アーキテクチャ 通信方法 各々が独自のコンテキス トとツールを持つ 単独でも価値を持つ 役割分担と指揮系統を定 める • スーパーバイザー • スウォーム 情報をやり取りする仕組 み • サブエージェント • A2A • MCP
42. マルチエージェントシステムの代表的なアーキテクチャ • スーパーバイザー型 • スウォーム型 42 Copyright © 2026, Oracle and/or its affiliates スーパーバイザー型 中央に調整役のエージェントがいて、ユーザーから の入力を受け取ってどのワーカーに振り分けるかを 動的に判断する スウォーム型 中央の調整役をおかず、エージェント同士が直接制 御を受け渡す
43. エージェント間の通信方法 • サブエージェント • MCPツール化 • A2A 43 Copyright © 2026, Oracle and/or its affiliates サブエージェント エージェントを内部的に呼び出す MCPツール化 エージェントをツールとして呼び出す A2A エージェントをピアとして協調
44. エージェント間の通信方法 サブエージェント このパターンの場合は、必然的にスーパーバイザー型になる 基本的には、親エージェントが子プロセスとしてサブエージェントをスポーンする形になる 44 Copyright © 2026, Oracle and/or its affiliates
45. エージェント間の通信方法 MCPツール化 エージェントをMCPサーバーのツールとして公開し、他のエージェントから呼び出せるようにする 基本的にはスーパーバイザー型になるが、クライアントの実装次第ではスウォーム型にできなくもない 45 Copyright © 2026, Oracle and/or its affiliates
46. エージェント間の通信方法 A2A (Agent to Agent) 各エージェントは自身の能力をAgent Cardとして公開し、他のエージェントはそれを見て協調相手を見つける スーパーバイザー型でもスウォーム型でも使える マルチエージェントシステムのために作られた専用のプロトコル 46 Copyright © 2026, Oracle and/or its affiliates
47. A2Aとは 独立したAIエージェント同士が協調するための標準プロトコル Googleが2025年に提唱した IBMのACP (Agent Communication Protocol)がA2Aに統合され、エージェント協調プロトコルとしては事実上標準 4つのコア概念がある • Agent Card • Task • Message • PartとArtifact 47 Copyright © 2026, Oracle and/or its affiliates
48. A2A 全体の流れ 48 Copyright © 2026, Oracle and/or its affiliates
49. A2A Agent Card エージェントの名刺として機能するメタデータ文書 構成要素 • エージェントの名前 • バージョン • エンドポイント • スキル • 認証方式 など /.well-known/agent-card.jsonで公開する 49 Copyright © 2026, Oracle and/or its affiliates
50. A2A Task A2Aにおける作業の基本単位で、ライフサイクルを持つ 構成要素 • 会話の文脈（タスクを跨ぐ） • 現在の状態 • タスク内でのメッセージ（後述するMessage） 以下の状態がある • submitted • working • input-required • auth-required • completed • failed 50 Copyright © 2026, Oracle and/or its affiliates
51. A2A Message エージェント間の対話の１ターンを表すオブジェクト 構成要素 • ロール • user • agent • Part（後述） • TextPart • DataPart • FilePart 51 Copyright © 2026, Oracle and/or its affiliates
52. A2A PartとArtifact Part Messageや成果物を構成する最小単位 • TextPart: プレーンテキストやマークダウン • DataPart: 構造化データ（JSON） • FilePart: バイナリデータ Artifact タスクの最終成果物 Partで構成される 52 Copyright © 2026, Oracle and/or its affiliates
53. A2Aを使ったエージェントの動的発見 A2Aでは、各エージェントのWell-Known URIにAgent Cardが公開されている つまり、各エージェントのドメイン名が分からなければ、そもそもそのエージェントを発見することができない エージェントのドメイン名が分からない状態でもエージェントを発見できるようには、レジストリが必要 53 Copyright © 2026, Oracle and/or its affiliates エージェントA エージェントB Well-Known URIで 公開してるよ そもそも接続先がわからない レジストリ エージェントA エージェントB 自分のAgent Cardを登録 する レジストリの接続先さえわ かっていればどんなエー ジェントがいるかわかる レジストリがない場合 レジストリがある場合
54. エージェント数が増えた時の課題 A2Aは１体１の通信を基本として設計されている エージェント数が増えると、直接接続の数が指数関数的に増え、管理・スケーリング・デバッグが困難になる このような課題は、マイクロサービスアーキテクチャが出てきた時と同じ メッセージブローカーを導入する 54 Copyright © 2026, Oracle and/or its affiliates N個のサービス（エージェント）があると、N*Mの依存関係 メッセージブローカーとの１体１の関係のみで済む
55. A2A on Kafka https://www.confluent.io/blog/google-agent2agent-protocol-needs-kafka/ A2Aの通信経路として、Kafka（メッセージブローカーの代表的プロダクト）を使うことが提案されている 55 Copyright © 2026, Oracle and/or its affiliates メリット • 複数のコンシューマーがメッセージに基づいて行 動できる（ターゲットのエージェント以外も） • エージェントのやり取りを永続的に保存でき、監 査やデバッグに利用できる • 接続経路が一つになるので、シンプルになる
56. A2Aのデモ スーパーバイザー型 56 Copyright © 2026, Oracle and/or its affiliates https://github.com/sogawa-yk/orajam-multi-agent/tree/main/multi_agent/supervisor
57. A2Aのデモ スウォーム型 57 Copyright © 2026, Oracle and/or its affiliates https://github.com/sogawa-yk/orajam-multi-agent/tree/main/multi_agent/swarm
58. エージェントの認可の課題 通常のアプリケーションと違い、エージェントにはいくつか課題がある 58 Copyright © 2026, Oracle and/or its affiliates 挙動が実行時まで決まらない プロンプトインジェクション 権限の組み合わせが新しい能力を生む 粒度のミスマッチ • 従来のアプリはコードで挙動が固定されている • エージェントは入力次第で毎回挙動が異なる • LLMは入力テキストを指示として受け取るので、 参照するデータなどに悪意のあるプロンプトが紛 れていても区別がつかない • 従来のアプリは機能はコードで書いた範囲のみ • エージェントはツールを動的に組み合わせるので、 個別の権限は安全でも組み合わせると危険になる 恐れがある • OAuthのスコープはread:gmailのような粗い単位 • エージェントに必要なのは、「この1件の返信用 に」といった動的で細かい権限
59. マルチエージェントではさらに課題が出てくる 59 Copyright © 2026, Oracle and/or its affiliates 権限委譲の連鎖 プロンプトインジェクション 権限の組み合わせ問題はエージェント単位でも • エージェントの呼び出しチェーンの中で、権限は 狭まるべきだが、OAuth Bearerトークンはそのまま 転送されると全権限が伝わってしまう • 標準的な方法がまだ確立されていない • プロンプトインジェクションの問題はマルチエー ジェントの場合でも同様 • ツールの連鎖の危険性は、エージェント単位でも 起こる • エージェント単位では安全でも、組み合わさると 危険になる恐れがある
60. エージェントの オブザーバビリティ
61. エージェントシステムのObservability 以下のような要素を監視する必要がある 61 Copyright © 2026, Oracle and/or its affiliates インフラ層 コスト層 ワークフロー層 出力品質層 協調層 （マルチエージェントの場合） ユーザーフィードバック層 • CPU、メモリ、ネットワークなど • コンテナやノードの稼働率 • 依存サービスの可用性 • トークン消費量 • モデル別コスト • キャッシュヒット率 • タスク成功率 • レイテンシ • リトライ回数、ループ回数 • 推論プロセスの追跡 • ハルシネーション検出 • 埋め込みドリフト • コンテキスト利用状況 • ポリシー遵守 • エージェント間の依存関係 • 処理依頼 の成功率 • 処理依頼の適切性 • 再質問率、放棄率 • 明示的評価 • ユーザー満足度の定量化
62. エージェントシステムのObservability Stack 例えば… 62 Copyright © 2026, Oracle and/or its affiliates アプリ側の計装ロジック • OpenTelemetry SDK + OpenLLMetry • Langfuse SDK 収集 • OpenTelemetry Collector バックエンド • Prometheus • Grafana Loki • Grafana Tempo • Langfuse UI • Grafana • Langfuse
63. OpenLLMetry LLM SDK向け自動計装ライブラリ モンキーパッチによって自動計装を実現 生成されるSpanは通常のOTel SDKが作るSpanと互換 自動で記録されるデータ • LLMのプロバイダ • モデル名 • 入力トークン数 • 出力トークン数 • プロンプト本文 • レスポンス本文 など デコレーターを使って手動計装もできる 63 Copyright © 2026, Oracle and/or its affiliates モンキーパッチによって、普通のSDKを呼び出すだけで計装される
64. Langfuse LLMの判断基準などをトレースできる 機能 • トレーシング（LLM呼び出し単位の入出力記録） • 評価（Evaluation、スコア付与と時系列推移） • プロンプト管理（バージョン管理と品質比較） など 64 Copyright © 2026, Oracle and/or its affiliates
65. Langfuse トレーシング • LLM呼び出しの入出力 • 使用モデル • トークンコスト • 所要時間 などを１リクエスト単位で記録できる 65 Copyright © 2026, Oracle and/or its affiliates デコレータをつけるだけ
66. まとめ
67. まとめ • エージェントは以下の要素で構成される • モデル • ツール • メモリ • ナレッジストア • オーケストレーション • マルチエージェントは、シングルエージェントでは解ききれないタスクにのみ適用する • エージェントが他のエージェントを呼び出すための標準プロトコルとして、Agent-to-Agentがある • エージェントの認可はまだまだ発展途上、マルチエージェントなら尚更 • エージェントの開発・運用にはO11yが必須 67 Copyright © 2026, Oracle and/or its affiliates
68. 68 Copyright © 2026, Oracle and/or its affiliates