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

マルチエージェントの現在地を調べてみた Yuki Sogawa Oracle Japan

自己紹介曽川宥輝日本オラクル CloudNative/AI,ML クラウドエンジニアバックグラウンド大阪大学でデータセンターの省電力化の研究をしていました趣味
ギター、バイク、ゲームなど 2 Copyright © 2026, Oracle and/or its affiliates

Agenda 3 Copyright © 2026, Oracle and/or its affiliates 1
2 3 4 エージェントの基礎マルチエージェントエージェントのオブザーバビリティまとめ

エージェントの基礎

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

AIエージェントの構成要素 • モデル • ツール • メモリ • ナレッジベース •
オーケストレーション 6 Copyright © 2026, Oracle and/or its affiliates オーケストレーションモデルツールメモリナレッジベースユーザー

AIエージェントの構成要素モデルエージェントの頭脳に相当するモデルを選択する際には、賢さとレイテンシーやコストとのトレードオフを考える • 高度な思考を要求する場合は、コストやレイテンシーは妥協が必要 • レイテンシーを下げたい場合は、賢さは妥協が必要 7 Copyright
© 2026, Oracle and/or its affiliates 大きいモデル小さいモデルレイテンシー: 低いコスト: 低いモデルの性能: 低いレイテンシー: 高いコスト: 高いモデルの性能: 高い

AIエージェントの構成要素ツールエージェントが外部に作用するために必要主に3つのカテゴリーがある • ローカルツール • エージェントのコードに実装されているツール • 内部で解決するもの（計算処理や、ローカルにあるファイル参照など）
• APIベースのツール • エージェントのコードの実装されているツール • 外部のAPIを呼び出す • MCP • エージェントの外に実装されているツールツールといえばMCPのようなイメージがあるが、MCPは選択肢の一つ 8 Copyright © 2026, Oracle and/or its affiliates

ローカルツールの例 9 Copyright © 2026, Oracle and/or its affiliates langchain_coreのtoolsデコレータを使ってツールを定義
処理は内部で完結する https://github.com/sogawa-yk/orajam-multi-agent/tree/main/tools/local_tools

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

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

エージェントの構成要素メモリ LLMは関数なので、状態（記憶）を保持することができない ChatGPTなどで、以前の会話内容を覚えているように見えるのは、毎回LLMの入力に以前の会話内容を入れているため 12 Copyright © 2026, Oracle and/or
its affiliates 記憶を保持する仕組みが必要

コンテキストエンジニアリング 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 Copyright © 2026, Oracle and/or its affiliates
https://github.com/sogawa-yk/orajam-multi-agent/tree/main/memory/no-memory

デモエージェントにメモリがあるとどうなるか 15 Copyright © 2026, Oracle and/or its affiliates
https://github.com/sogawa-yk/orajam-multi-agent/tree/main/memory/with-memory-responses-api

AIエージェントの構成要素メモリエージェントの記憶を保持するメモリには２種類ある • 短期メモリ • 現在のタスクを実行中に保持する記憶を格納する • 会話履歴などに用いる
• 長期メモリ • タスクを横断して保持する記憶を格納する • 過去の成功パターンや、ユーザーの行動に基づくパーソナライズに用いる 16 Copyright © 2026, Oracle and/or its affiliates

短期メモリを利用する場合のコード 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

短期メモリを利用する場合のコード 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

（参考）Response IDによる会話チェーン 20 Copyright © 2026, Oracle and/or its affiliates
Response IDで会話チェーンを表現する場合、リクエストの際に任意のレスポンスIDを指定する • ある程度を会話を進めた後に戻る（rewind） • レスポンスIDだけわかっていれば良いので管理が楽などのメリットがある Conversations APIを使う場合は、Conversation IDを指定する（チェーンにはならない）

短期メモリ実装場所エージェントのインスタンスメリット • 最速でアクセスできる • 外部サービスが増えないデメリット •
インスタンスが落ちると消える • スティッキーセッションが必須 Redis, Valkeyなどのデータストアメリット • 高速アクセス • スティッキーセッション不要デメリット • 運用の手間 • 耐久性は努力目標 Oracle, PostgreSQLなどのRDB メリット • 強い耐久性とトランザクション • 状態がSQLで検査できるデメリット • レイテンシが大きい • RDBは永続化する場所なので、短期化が表現しづらい Copyright © 2026, Oracle and/or its affiliates 21 メモリエージェントのロジックエージェントのインスタンスエージェントのロジックメモリエージェントのインスタンス Redisのインスタンスエージェントのロジックメモリエージェントのインスタンス RDBのインスタンス

短期メモリの基本的な管理 • ローリングコンテキストウィンドウ • LLMを使った要約などを利用する 22 Copyright © 2026,
Oracle and/or its affiliates ローリングコンテキストウィンドウ LLMを使った要約

AIエージェントの構成要素長期メモリ短期メモリは、1つの会話セッション内で使うメモリだった長期メモリは、会話を跨いで保持する情報に使用する例えば • ユーザー固有の恒久情報（名前や所属、好みなど） • タスク状態の永続化（長時間にわたるタスクの情報など） •
エピソード記憶（過去の類似ケース参照や、継続的プロジェクトの文脈など） 23 Copyright © 2026, Oracle and/or its affiliates

デモ長期メモリがないとどうなるか 24 Copyright © 2026, Oracle and/or its affiliates
新しい会話を作成すると会話を跨いだ記憶はない

デモ長期メモリがあると 25 Copyright © 2026, Oracle and/or its affiliates
新しい会話を作成すると会話を跨いで記憶を保持している https://github.com/sogawa-yk/orajam-multi-agent/tree/main/memory/long-term-memory

長期メモリの利用方法 26 Copyright © 2026, Oracle and/or its affiliates memory_subject_idをリクエスト時に送る
ユーザーごとにこのIDを管理しておけば、ユーザーごとに属性を記憶できる

長期メモリの管理いつ書き込むか • 即時書き込み • バッチ書き込み • ２段階書き込み記憶の抽出と圧縮 •
LLMを使った要約 • 時間経過に応じて削除どう読み出すか • すべて読み出す • ベクトル検索で関連するものを読み出す 27 Copyright © 2026, Oracle and/or its affiliates 他にも様々な方法があるこれと言った正解があるわけではないので、ユースケースに応じて最適化する必要がある

長期メモリ管理の例 28 Copyright © 2026, Oracle and/or its affiliates ユーザー
AI ①会話内容を埋め込みモデルに埋め込みモデル随時内容を要約 ②メモリに保存要約モデル ③メモリを参照長期メモリ

AIエージェントの構成要素ナレッジベース AIエージェントに与える、静的な情報を格納する（動的な情報はメモリに格納）ここに入る情報は、必ずしも1つのエージェント専用の情報である必要はなく、共用してもOK 29 Copyright © 2026, Oracle and/or
its affiliates ユーザー AI オブジェクトストアベクトルストア必要な時に参照埋め込みモデル定期的に同期社内規則などの静的なドキュメントを配置

AIエージェントの構成要素オーケストレーションエージェントが複雑なタスクを実行するための実行設計のこと AIエージェントの実装の多くがオーケストレーション部分だと思ってOK 実行の制御を行う上では、以下のことを考慮しておく必要がある • エージェントの種類 • 今回はここのみお話しします •
ツール選択方法 • ツールトポロジー 30 Copyright © 2026, Oracle and/or its affiliates

エージェントの種類エージェントにはいろいろな種類がある • ReAct • Planner-Executor • Reflection など 31
Copyright © 2026, Oracle and/or its affiliates

ReAct 各ステップ「考える → 行動する → 観察する」のループを回し、状況を見ながら次の手を動的に判断するパターン 32 Copyright © 2026,
Oracle and/or its affiliates メリット • 各ステップLLMが判断するので、状況の変化に柔軟に対応できる • ツールの実行結果を見て次の行動を決めるため、事前に手順を決められないタスクをこなせるデメリット • 各ステップLLM呼び出しが発生するため、コストと遅延が大きい • １ステップごとに計画するため、局所最適な判断を行なってしまう

デモ ReAct 33 Copyright © 2026, Oracle and/or its affiliates
https://github.com/sogawa-yk/orajam-multi-agent/tree/main/orchestration/react

Planner-Executor 最初に全体計画を立て、あとはその計画通りに実行するパターン 34 Copyright © 2026, Oracle and/or its affiliates
メリット • 高価な大きいモデルを呼ぶのはPlannerの１回で済む • 計画が先に確定するため、予測可能でデバッグしやすいデメリット • 実行中に状況が変わっても計画を変更できない

デモ Planner-Executor 35 Copyright © 2026, Oracle and/or its affiliates
https://github.com/sogawa-yk/orajam-multi-agent/tree/main/orchestration/planner_executor

Reflection ReActのループに「自己検証」のステップを挟み込むパターン 36 Copyright © 2026, Oracle and/or its affiliates
メリット • ReActの弱点である「局所最適な判断の積み重ね」を緩和できるデメリット • 検証のための追加LLM呼び出しが発生するため、コストと遅延がさらに増える

デモ Reflection 37 Copyright © 2026, Oracle and/or its affiliates
https://github.com/sogawa-yk/orajam-multi-agent/tree/main/orchestration/reflection

オーケストレーションのデザインパターンの変化モデルが賢くなるにつれて、オーケストレーションのデザインパターンも変化してきている 38 Copyright © 2026, Oracle and/or its affiliates
従来 • グラフで制御フローを組む • ステートマシンを設計する • ノード間の遷移を書く制御ロジックを設計することが焦点現在 • ReActループに任せる • コンテキストをステートとしてReActに渡して、ステートマシンは設計しないツール・スキル・コンテキストを設計することが焦点

シングルエージェントの限界エージェントのステートとしてコンテキストを扱うが、モデルが持つことのできるコンテキストには限界があるつまり、コンテキストに入りきらない情報が必要なタスクは物理的にシングルエージェントでは解くことができないコンテキストエンジニアリングを徹底して、コンテキストを小さくすればシングルエージェントで解ける幅が広がるが、それでも物理的な制約は避けられない 39 Copyright © 2026, Oracle
and/or its affiliates 余裕があるので素朴な実装で対応できるコンテキストエンジニアリングでギリギリ対応できる頑張ってもコンテキストサイズから溢れてしまうマルチエージェントにして、コンテキストを分離する必要がある

マルチエージェント

マルチエージェントとは複数の自律エージェントが協調するシステムマルチエージェントシステムは以下の３要素で構成される 41 Copyright © 2026, Oracle and/or its
affiliates エージェントアーキテクチャ通信方法各々が独自のコンテキストとツールを持つ単独でも価値を持つ役割分担と指揮系統を定める • スーパーバイザー • スウォーム情報をやり取りする仕組み • サブエージェント • A2A • MCP

マルチエージェントシステムの代表的なアーキテクチャ • スーパーバイザー型 • スウォーム型 42 Copyright © 2026, Oracle
and/or its affiliates スーパーバイザー型中央に調整役のエージェントがいて、ユーザーからの入力を受け取ってどのワーカーに振り分けるかを動的に判断するスウォーム型中央の調整役をおかず、エージェント同士が直接制御を受け渡す

エージェント間の通信方法 • サブエージェント • MCPツール化 • A2A 43 Copyright ©
2026, Oracle and/or its affiliates サブエージェントエージェントを内部的に呼び出す MCPツール化エージェントをツールとして呼び出す A2A エージェントをピアとして協調

エージェント間の通信方法サブエージェントこのパターンの場合は、必然的にスーパーバイザー型になる基本的には、親エージェントが子プロセスとしてサブエージェントをスポーンする形になる 44 Copyright © 2026, Oracle and/or
its affiliates

エージェント間の通信方法 MCPツール化エージェントをMCPサーバーのツールとして公開し、他のエージェントから呼び出せるようにする基本的にはスーパーバイザー型になるが、クライアントの実装次第ではスウォーム型にできなくもない 45 Copyright © 2026, Oracle and/or
its affiliates

エージェント間の通信方法 A2A (Agent to Agent) 各エージェントは自身の能力をAgent Cardとして公開し、他のエージェントはそれを見て協調相手を見つけるスーパーバイザー型でもスウォーム型でも使えるマルチエージェントシステムのために作られた専用のプロトコル 46
Copyright © 2026, Oracle and/or its affiliates

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

A2A Task A2Aにおける作業の基本単位で、ライフサイクルを持つ構成要素 • 会話の文脈（タスクを跨ぐ） • 現在の状態 • タスク内でのメッセージ（後述するMessage）
以下の状態がある • submitted • working • input-required • auth-required • completed • failed 50 Copyright © 2026, Oracle and/or its affiliates

A2Aを使ったエージェントの動的発見 A2Aでは、各エージェントのWell-Known URIにAgent Cardが公開されているつまり、各エージェントのドメイン名が分からなければ、そもそもそのエージェントを発見することができないエージェントのドメイン名が分からない状態でもエージェントを発見できるようには、レジストリが必要 53 Copyright © 2026,
Oracle and/or its affiliates エージェントA エージェントB Well-Known URIで公開してるよそもそも接続先がわからないレジストリエージェントA エージェントB 自分のAgent Cardを登録するレジストリの接続先さえわかっていればどんなエージェントがいるかわかるレジストリがない場合レジストリがある場合

エージェント数が増えた時の課題 A2Aは１体１の通信を基本として設計されているエージェント数が増えると、直接接続の数が指数関数的に増え、管理・スケーリング・デバッグが困難になるこのような課題は、マイクロサービスアーキテクチャが出てきた時と同じメッセージブローカーを導入する 54 Copyright © 2026, Oracle
and/or its affiliates N個のサービス（エージェント）があると、N*Mの依存関係メッセージブローカーとの１体１の関係のみで済む

A2A on Kafka https://www.confluent.io/blog/google-agent2agent-protocol-needs-kafka/ A2Aの通信経路として、Kafka（メッセージブローカーの代表的プロダクト）を使うことが提案されている 55 Copyright © 2026, Oracle
and/or its affiliates メリット • 複数のコンシューマーがメッセージに基づいて行動できる（ターゲットのエージェント以外も） • エージェントのやり取りを永続的に保存でき、監査やデバッグに利用できる • 接続経路が一つになるので、シンプルになる

エージェントの認可の課題通常のアプリケーションと違い、エージェントにはいくつか課題がある 58 Copyright © 2026, Oracle and/or its affiliates
挙動が実行時まで決まらないプロンプトインジェクション権限の組み合わせが新しい能力を生む粒度のミスマッチ • 従来のアプリはコードで挙動が固定されている • エージェントは入力次第で毎回挙動が異なる • LLMは入力テキストを指示として受け取るので、参照するデータなどに悪意のあるプロンプトが紛れていても区別がつかない • 従来のアプリは機能はコードで書いた範囲のみ • エージェントはツールを動的に組み合わせるので、個別の権限は安全でも組み合わせると危険になる恐れがある • OAuthのスコープはread:gmailのような粗い単位 • エージェントに必要なのは、「この1件の返信用に」といった動的で細かい権限

マルチエージェントではさらに課題が出てくる 59 Copyright © 2026, Oracle and/or its affiliates 権限委譲の連鎖
プロンプトインジェクション権限の組み合わせ問題はエージェント単位でも • エージェントの呼び出しチェーンの中で、権限は狭まるべきだが、OAuth Bearerトークンはそのまま転送されると全権限が伝わってしまう • 標準的な方法がまだ確立されていない • プロンプトインジェクションの問題はマルチエージェントの場合でも同様 • ツールの連鎖の危険性は、エージェント単位でも起こる • エージェント単位では安全でも、組み合わさると危険になる恐れがある

エージェントのオブザーバビリティ

エージェントシステムのObservability 以下のような要素を監視する必要がある 61 Copyright © 2026, Oracle and/or its affiliates
インフラ層コスト層ワークフロー層出力品質層協調層（マルチエージェントの場合）ユーザーフィードバック層 • CPU、メモリ、ネットワークなど • コンテナやノードの稼働率 • 依存サービスの可用性 • トークン消費量 • モデル別コスト • キャッシュヒット率 • タスク成功率 • レイテンシ • リトライ回数、ループ回数 • 推論プロセスの追跡 • ハルシネーション検出 • 埋め込みドリフト • コンテキスト利用状況 • ポリシー遵守 • エージェント間の依存関係 • 処理依頼の成功率 • 処理依頼の適切性 • 再質問率、放棄率 • 明示的評価 • ユーザー満足度の定量化

エージェントシステムの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

OpenLLMetry LLM SDK向け自動計装ライブラリモンキーパッチによって自動計装を実現生成されるSpanは通常のOTel SDKが作るSpanと互換自動で記録されるデータ • LLMのプロバイダ •
モデル名 • 入力トークン数 • 出力トークン数 • プロンプト本文 • レスポンス本文などデコレーターを使って手動計装もできる 63 Copyright © 2026, Oracle and/or its affiliates モンキーパッチによって、普通のSDKを呼び出すだけで計装される

まとめ

まとめ • エージェントは以下の要素で構成される • モデル • ツール • メモリ •
ナレッジストア • オーケストレーション • マルチエージェントは、シングルエージェントでは解ききれないタスクにのみ適用する • エージェントが他のエージェントを呼び出すための標準プロトコルとして、Agent-to-Agentがある • エージェントの認可はまだまだ発展途上、マルチエージェントなら尚更 • エージェントの開発・運用にはO11yが必須 67 Copyright © 2026, Oracle and/or its affiliates

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

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

More Decks by oracle4engineer

Featured

Transcript