Google: Agents Companion Architecture / マルチエージェントアーキテクチャ

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/214013/74d23a7f-cc94-4ffc-9207-597b75eef343.png)
Agents Companion
https://www.kaggle.com/whitepaper-agent-companion

## 目次
- [1. AIエージェントの基礎と進化](#1-aiエージェントの基礎と進化)
  - [1.1 エージェントとは何か？](#11-エージェントとは何か)
  - [1.2 AgentOpsの概念と重要性](#12-agentopsの概念と重要性)
  - [1.3 エージェントの評価方法](#13-エージェントの評価方法)
- [2. マルチエージェントシステム](#2-マルチエージェントシステム)
  - [2.1 マルチエージェントアーキテクチャの理解](#21-マルチエージェントアーキテクチャの理解)
  - [2.2 マルチエージェントデザインパターン](#22-マルチエージェントデザインパターン)
  - [2.3 マルチエージェントの課題と評価](#23-マルチエージェントの課題と評価)
- [3. アジェンティックRAGと企業応用](#3-アジェンティックragと企業応用)
  - [3.1 アジェンティックRAGの進化と重要性](#31-アジェンティックragの進化と重要性)
  - [3.2 企業でのエージェント活用](#32-企業でのエージェント活用)
  - [3.3 エージェントから契約者へ：新しい概念](#33-エージェントから契約者へ新しい概念)
- [4. 実際の応用例と実装](#4-実際の応用例と実装)
  - [4.1 自動車AIにおけるマルチエージェントアーキテクチャ](#41-自動車aiにおけるマルチエージェントアーキテクチャ)
  - [4.2 専門化エージェントと実装パターン](#42-専門化エージェントと実装パターン)
  - [4.3 Googleのツールとエコシステム](#43-googleのツールとエコシステム)
- [5. まとめと将来の展望](#5-まとめと将来の展望)
  - [5.1 主要なポイント](#51-主要なポイント)
  - [5.2 今後の研究と開発の方向性](#52-今後の研究と開発の方向性)
  - [5.3 開発者へのアクション指針](#53-開発者へのアクション指針)

## 1. AIエージェントの基礎と進化

### 1.1 エージェントとは何か

生成AI（Generative AI）エージェントは、従来の単独言語モデルからの飛躍的な進化を遂げています。エージェントは、特定の目標を達成するために環境を認識し、利用可能なツールを戦略的に活用するアプリケーションです。その基本原則は、推論、論理、外部情報へのアクセスを統合し、基盤となるモデル自体の能力を超えたタスクの実行や意思決定を可能にすることにあります。

エージェントのアーキテクチャは以下の3つの本質的な要素で構成されています：

1. **モデル**: 中心的な意思決定ユニットとして機能する言語モデル（LM）で、指示ベースの推論と論理的フレームワークを使用します。エージェントの特定の要件に応じて、汎用からマルチモーダルまたは微調整されたモデルまで様々です。

2. **ツール**: エージェントの内部能力と外部世界の間のギャップを埋め、外部データやサービスとの相互作用を容易にします。これらのツールにより、エージェントは現実世界の情報にアクセスして処理することが可能になります。ツールには拡張機能、関数、データストアが含まれます。

3. **オーケストレーション層**: エージェントが情報を取り込み、内部推論を行い、その推論を次のアクションや決定に活かす循環プロセスです。このレイヤーはメモリ、状態、推論、計画の維持を担当しています。環境との効果的な相互作用とタスク完了を促進するために、推論やプランニングを導くプロンプトエンジニアリングフレームワークを採用しています。

```plantuml
@startuml
!theme plain
skinparam roundcorner 20
skinparam BackgroundColor #EEEBDC

package "AIエージェントのアーキテクチャ" {
  component "モデル\n(LLM)" as Model
  component "ツール" as Tools {
    component "拡張機能" as Extensions
    component "関数" as Functions
    component "データストア" as DataStores
  }
  component "オーケストレーションレイヤー" as Orchestration {
    component "メモリ" as Memory
    component "推論エンジン" as Reasoning
    component "プランニング" as Planning
    component "状態管理" as State
  }
}

actor "ユーザー" as User
database "外部データ\n&サービス" as ExternalServices

User --> Orchestration : クエリ/指示
Orchestration --> Model : プロンプト/コンテキスト
Model --> Reasoning : 生成結果
Reasoning --> Planning : 次のステップ決定
Planning --> Tools : ツール選択
Tools --> ExternalServices : API呼び出し/データ取得
ExternalServices --> Tools : 結果
Tools --> Model : ツール結果
Memory <--> State : コンテキスト維持
Model --> User : 最終応答

note right of Model
  様々なタイプ:
  - 汎用LLM
  - マルチモーダルLLM
  - 特定タスク向け微調整LLM
end note

note right of Tools
  外部世界との橋渡し:
  - APIへのアクセス
  - データの処理と変換
  - 最新情報の取得
end note

note right of Orchestration
  制御フロー:
  - ReAct
  - Chain-of-Thought (CoT)
  - Tree-of-Thoughts (ToT)
  による推論のガイド
end note
@enduml
```

これらの基礎概念を踏まえ、このブログ記事では開発者向けにより高度なトピックを深く掘り下げていきます。特にエージェント評価手法とGoogleエージェント製品の実際の応用例に注目し、複雑な実世界の問題を解決するためのエージェント能力の向上方法を探ります。

### 1.2 AgentOpsの概念と重要性

過去2年間で、生成AIの分野は大きく変化し、企業は関連ソリューションの運用化に注目するようになりました。これにより、MLOps for GenAI、LLMOps、FMOps、GenAIOpsなど、GenAIの運用化を表すさまざまな用語が登場しています。

Agent and Operations（AgentOps）は、エージェントの効率的な運用に焦点を当てたGenAIOpsのサブカテゴリです。その主要な追加コンポーネントには、内部および外部のツール管理、エージェントブレインプロンプト（目標、プロファイル、指示）とオーケストレーション、メモリ、タスク分解などがあります。

```plantuml
@startuml
!theme plain
skinparam roundcorner 20
skinparam BackgroundColor #EEEBDC

archimate #Technology "DevOps" as DevOps
archimate #Technology "MLOps" as MLOps
archimate #Technology "FMOps" as FMOps
archimate #Technology "PromptOps" as PromptOps
archimate #Technology "RAGOps" as RAGOps
archimate #Technology "AgentOps" as AgentOps

DevOps <-- MLOps : 基盤として使用
MLOps <-- FMOps : 拡張
MLOps <-- PromptOps : サブカテゴリ
MLOps <-- RAGOps : サブカテゴリ
MLOps <-- AgentOps : サブカテゴリ

note right of DevOps
  決定論的ソフトウェアアプリケーションを
  効率的に本番環境に投入する実践
end note

note right of MLOps
  MLモデルを効率的に本番環境に
  投入することに焦点
end note

note right of AgentOps
  エージェントの効率的な運用化
  • 内部/外部ツール管理
  • エージェントブレインプロンプト
  • オーケストレーション
  • メモリ
  • タスク分解
end note
@enduml
```

これらの「Ops」はそれぞれ、バージョン管理、CI/CDを通じた自動デプロイ、テスト、ログ記録、セキュリティ、そして特に重要なメトリクスなどの機能を必要とします。各システムは通常、メトリクスに基づいた最適化の形式を実装しています。これはシステムが何をしているか（あるいはしていないか）を測定し、結果やビジネスメトリクスを測定し、より全体的なメトリクスを得るためのプロセスを自動化し、段階的に改善していくというアプローチです。

AgentOpsの文脈では、新しい実践が古いものを置き換えるわけではないことを覚えておくことが重要です。DevOpsとMLOpsのベストプラクティスは依然としてAgentOpsに必要であり、それらは依存関係にあります。例えば、APIを呼び出すエージェントツールの使用では、非エージェント型ソフトウェアでも呼び出すのと同じAPIを使用することが多いです。認証とシークレット管理、セキュリティ、プライバシー、例外処理、スロットリング、クォータ、スケーラビリティなどは依然として重要であり、APIデザインに加えてエージェントデザインにも細心の注意が必要です。

本格的なエージェントの構築に進む前に、いくつかの思考実験を行ってみましょう。本番環境でA/B実験を設定し、新しいエージェントを評価するとします。処理グループは新しいエージェントを取得し、対照グループは取得しません。このシナリオでは、処理グループがより優れているかどうかを判断するためにどのようなメトリクスを測定していますか？プロジェクトのROIを判断するためにはどのようなメトリクスを測定していますか？それは目標の達成、売上の合計、あるいはユーザージャーニーにおける一連の重要なステップでしょうか？これらのメトリクスを理解し、計測し、簡単に分析できるようにすることは、より詳細なエージェント評価メトリクスに加えて不可欠です。

### 1.3 エージェントの評価方法

プルーフオブコンセプトから本番対応AIエージェントへの移行には、堅牢で自動化された評価フレームワークが不可欠です。生成モデルの評価（主に最終出力に焦点を当てる）とは異なり、エージェント評価は意思決定プロセスのより深い理解が必要です。エージェント評価は3つのコンポーネントに分けることができます：

1. **エージェント能力の評価**: 指示を理解し論理的に推論する能力など、エージェントのコア能力を評価します。

2. **軌跡（トラジェクトリ）とツール使用の評価**: ツールの選択、戦略、アプローチの効率性など、エージェントがソリューションに到達するための手順を分析します。

3. **最終応答の評価**: エージェントの最終出力の品質、関連性、正確性を評価します。

```plantuml
@startuml
!theme plain
skinparam roundcorner 20
skinparam BackgroundColor #EEEBDC

state "エージェント評価" as AgentEval {
  state "能力評価" as CapabilityAssessment
  state "軌跡評価" as TrajectoryEval {
    state "完全一致" as ExactMatch
    state "順序一致" as InOrderMatch
    state "任意順序一致" as AnyOrderMatch
    state "精度" as Precision
    state "再現率" as Recall
    state "単一ツール使用" as SingleToolUse
  }
  state "最終応答評価" as FinalResponseEval
  state "人間介在評価" as HumanInTheLoop {
    state "直接評価" as DirectAssessment
    state "比較評価" as ComparativeEval
    state "ユーザー調査" as UserStudies
  }
}

CapabilityAssessment --> TrajectoryEval
TrajectoryEval --> FinalResponseEval
FinalResponseEval --> HumanInTheLoop

note bottom of CapabilityAssessment
  公開ベンチマークや技術レポートを活用
  基本的な能力と制限を理解
end note

note bottom of TrajectoryEval
  エージェントが取った一連のアクションを評価
  参照軌跡との比較による自動評価
end note

note bottom of FinalResponseEval
  エージェントが目標を達成したかを評価
  オートレーター（判断するLLM）を使用可能
end note

note bottom of HumanInTheLoop
  主観的判断や創造的問題解決を要するタスクに有効
  自動評価アプローチの調整や二重確認にも役立つ
end note
@enduml
```

#### エージェント能力の評価

特定のエージェントユースケースを評価する前に、公開されているベンチマークや技術レポートは、エージェント構築時に考慮すべきコア能力と制限に関する洞察を提供できます。ツール呼び出し、計画、推論などのほとんどの基本的なエージェント能力には公開ベンチマークが存在します。

例えば、適切なツールを選択して使用する能力であるツール呼び出しは、Berkeley Function-Calling Leaderboard（BFCL）やτ-benchなどのベンチマークによって実証されています。これらは一般的なミスも概説しています。また、PlanBenchは複数のドメインと特定の能力にわたる計画と推論を評価することを目的としています。

公開ベンチマークは、何が可能かを感じ取り、注意すべき落とし穴を特定するための価値ある出発点です。ほとんどのベンチマーク評価には、独自のユースケース固有の評価フレームワークの設定に役立つような一般的な失敗モードの議論が含まれています。

#### 軌跡とツール使用の評価

エージェントは通常、ユーザーに応答する前にいくつかのアクションを実行します。ユーザー入力をセッション履歴と比較して用語を明確にしたり、ポリシードキュメントを検索したり、ナレッジベースを検索したり、チケットを保存するためにAPIを呼び出したりするかもしれません。これらのアクションの各々は、「軌跡」とも呼ばれる行動の経路上のステップです。

エージェントに期待する軌跡と実際にエージェントが取った軌跡を比較することは、アプリケーションをデバッグし、エラーや非効率性を特定し、最終的にパフォーマンスを向上させたい開発者にとって特に有用です。

以下の6つの真値ベースの自動軌跡評価は、エージェントのパフォーマンスを評価するための異なる視点を提供します：

1. **完全一致（Exact match）**: AIエージェントが理想的なソリューションを完全に模倣するアクション列（「軌跡」）を生成する必要があります。期待されたパスからの逸脱を許さない最も厳格なメトリックです。

2. **順序一致（In-order match）**: このメトリックは、追加のペナルティのないアクションを許容しつつ、エージェントが期待される軌跡を完了する能力を評価します。成功は、追加のアクションの柔軟性を持ちながらコアステップを順序正しく完了することと定義されます。

3. **任意順序一致（Any-order match）**: 順序一致と比較して、このメトリックは順序を無視します。エージェントが必要なすべてのアクションを含んでいるかどうかを問いますが、アクションの順序を見ず、追加のステップも許容します。

4. **精度（Precision）**: 予測された軌跡内のツール呼び出しのうち、参照軌跡によれば実際に関連または正確なものはいくつありますか？

5. **再現率（Recall）**: 参照軌跡からの必須ツール呼び出しのうち、実際に予測された軌跡で捕捉されているものはいくつありますか？

6. **単一ツール使用（Single-tool use）**: 特定のアクションがエージェントの軌跡内にあるかを理解します。このメトリックは、エージェントが特定のツールの使用をまだ学習しているかどうかを理解するのに役立ちます。

これらのメトリクスを、エージェントの軌跡を分析しデバッグするための異なるレンズと考えてください。各メトリクスは独自の視点を提供しますが、すべてのシチュエーションに関連するわけではありません。例えば、一部のユースケースでは理想的な軌跡への厳格な遵守が求められますが、他のケースではより創造的な逸脱が許容されます。

#### 最終応答の評価

最終応答の評価は、シンプルな質問に帰着します：あなたのエージェントは目標を達成していますか？これを測定するために、特定のニーズに合わせてカスタマイズされた成功基準を定義できます。例えば、小売チャットボットが製品の質問に正確に答えているかどうか、あるいは研究エージェントが適切なトーンとスタイルで効果的に発見を要約しているかどうかを評価できます。

このプロセスを自動化するために、オートレーターを使用できます。オートレーターは判断者として機能するLLMです。入力プロンプトと生成された応答が与えられると、ユーザー提供の基準に対して応答を評価することで人間の評価を模倣します。この評価が機能するためには、真値が存在しない場合、評価基準を非常に正確に定義することが重要であることを考慮する必要があります。これがあなたの評価が見ているものの核心だからです。

#### 人間介在評価

エージェント開発とエージェント評価の分野は急速に進化しています。AIエージェントの評価には、明確な目標の定義、現実的な環境の設計、確率的な動作の管理、特に社会的影響の大きいアプリケーションでの公平性とバイアスの軽減など、重要な課題があります。

したがって、以前に議論した自動評価（事前定義されたメトリクスとオートレーターを含む）と並行して、人間介在アプローチを組み込むことが重要です。人間介在は、主観的な判断や創造的な問題解決を必要とするタスクに価値があり、自動評価アプローチが実際に機能し、あなたの好みと一致しているかどうかを調整し、二重確認するのにも役立ちます。

主要な利点は以下の通りです：

- **主観性**: 人間は創造性、常識、ニュアンスなど、定量化が難しい質を評価できます。
- **文脈的理解**: 人間の評価者はエージェントの行動の広範な文脈とその意味を考慮できます。
- **反復的改善**: 人間のフィードバックはエージェントの動作や学習プロセスを改良するための貴重な洞察を提供します。
- **評価者の評価**: 人間のフィードバックはオートレーターを調整し洗練するための信号を提供できます。

人間介在評価を実装するには、以下の方法を検討してください：

- **直接評価**: 人間の専門家が特定のタスクに関するエージェントのパフォーマンスを直接評価または採点します。
- **比較評価**: 専門家がエージェントのパフォーマンスを他のエージェントや以前のバージョンのパフォーマンスと比較します。
- **ユーザー調査**: 参加者がエージェントと相互作用し、その動作、使いやすさ、全体的な効果についてフィードバックを提供します。

## 2. マルチエージェントシステム

### 2.1 マルチエージェントアーキテクチャの理解

エージェント評価は、自律型AIエージェントの有効性、信頼性、適応性を評価するもので、前のセクションで見てきたように、重要な焦点領域として浮上しています。AIシステムが著しく進化するにつれて、複数の専門エージェントが複雑な目標を達成するために協力するマルチエージェントアーキテクチャへの移行が見られます。

マルチエージェントシステムは、協力して複雑な問題を解決する専門家チームのようなものです。各エージェントは独立したエンティティであり、潜在的に異なるLLMを使用し、独自の役割とコンテキストを持っています。エージェントは共通の目標を達成するために通信し協力します。このアプローチは、1つのLLMがタスクのすべての側面を処理する従来の単一エージェントシステムとは異なります。

```plantuml
@startuml
!theme plain
skinparam roundcorner 20
skinparam BackgroundColor #EEEBDC

actor "ユーザー" as User

rectangle "単一エージェントシステム" as SingleAgentSystem {
  component "言語モデル\n(LLM)" as LLM
  component "ツール群" as Tools
  
  User --> LLM : クエリ
  LLM <--> Tools : ツール呼び出し
  LLM --> User : 応答
}

rectangle "マルチエージェントシステム" as MultiAgentSystem {
  component "オーケストレーター\nエージェント" as Orchestrator
  component "専門エージェントA\n(LLM1+ツール)" as AgentA
  component "専門エージェントB\n(LLM2+ツール)" as AgentB
  component "専門エージェントC\n(LLM3+ツール)" as AgentC
  
  User --> Orchestrator : クエリ
  Orchestrator --> AgentA : タスク割り当て
  Orchestrator --> AgentB : タスク割り当て
  Orchestrator --> AgentC : タスク割り当て
  
  AgentA <--> AgentB : 協力
  AgentB <--> AgentC : 協力
  AgentC <--> AgentA : 協力
  
  Orchestrator --> User : 統合された応答
}

note bottom of MultiAgentSystem
  マルチエージェントの利点：
  • 精度向上（相互チェック）
  • 効率性向上（並列処理）
  • 複雑なタスクの扱いが向上
  • スケーラビリティの向上
  • 耐障害性の向上
  • 幻覚とバイアスの軽減
end note
@enduml
```

従来の一枚岩的なAIシステムとは異なり、マルチエージェントアーキテクチャは問題を専門エージェントが処理する個別のタスクに分解します。各エージェントは定義された役割で動作し、意思決定、知識検索、実行を最適化するために他のエージェントと動的に相互作用します。これらのアーキテクチャは、より構造化された推論、分散型の問題解決、スケーラブルなタスク自動化を可能にし、単一エージェントのワークフローからのパラダイムシフトを提供します。

マルチエージェントシステムの中核では、モジュール性、協力、階層の原則を活用して堅牢なAIエコシステムを作成します。これらのシステム内のエージェントは、その機能に基づいて分類できます。例えば：

- **プランナーエージェント**: 高レベルの目標を構造化されたサブタスクに分解する責任があります。
- **検索エージェント**: 外部ソースから関連データを動的に取得することで、知識獲得を最適化します。
- **実行エージェント**: 計算の実行、応答の生成、APIとの対話を行います。
- **評価エージェント**: 応答を監視・検証し、目標との一貫性と整合性を確保します。

これらのコンポーネントを通じて、マルチエージェントアーキテクチャは単純なプロンプトベースのインタラクションを超え、適応的で説明可能で効率的なAI駆動ワークフローを可能にします。

### 2.2 マルチエージェントデザインパターン

効果的なマルチエージェントアーキテクチャを設計するために、特定のデザインパターンが確立されています。これらのパターンはインタラクションプロトコル、委任メカニズム、役割分布を定義し、企業が構造化された方法でAI駆動の自動化を実装できるようにします。

```plantuml
@startuml
!theme plain
skinparam roundcorner 20
skinparam BackgroundColor #EEEBDC

agent "ユーザー" as User

rectangle "階層型パターン" as Hierarchical {
  agent "オーケストレーター\nエージェント" as HOrchestrator
  agent "専門エージェントA" as HA
  agent "専門エージェントB" as HB
  agent "専門エージェントC" as HC
  
  User --> HOrchestrator
  HOrchestrator --> HA
  HOrchestrator --> HB
  HOrchestrator --> HC
  HOrchestrator --> User
}

rectangle "ダイアモンドパターン" as Diamond {
  agent "オーケストレーター\nエージェント" as DOrchestrator
  agent "専門エージェントA" as DA
  agent "専門エージェントB" as DB
  agent "専門エージェントC" as DC
  agent "リファイナー\nエージェント" as DRefiner
  
  User --> DOrchestrator
  DOrchestrator --> DA
  DOrchestrator --> DB
  DOrchestrator --> DC
  DA --> DRefiner
  DB --> DRefiner
  DC --> DRefiner
  DRefiner --> User
}

rectangle "ピアツーピアパターン" as P2P {
  agent "専門エージェントA" as PA
  agent "専門エージェントB" as PB
  agent "専門エージェントC" as PC
  
  User --> PA
  PA <--> PB : 相互連携
  PB <--> PC : 相互連携
  PC <--> PA : 相互連携
  PA --> User
  PB --> User
  PC --> User
}

rectangle "協調パターン" as Collaborative {
  agent "オーケストレーター" as COrchestrator
  agent "専門エージェントA" as CA
  agent "専門エージェントB" as CB
  agent "専門エージェントC" as CC
  agent "レスポンスミキサー" as CMixer
  
  User --> COrchestrator
  COrchestrator --> CA
  COrchestrator --> CB
  COrchestrator --> CC
  CA --> CMixer
  CB --> CMixer
  CC --> CMixer
  CMixer --> User
}

note bottom of Hierarchical
  中央のオーケストレーターがクエリを
  分類し、専門エージェントに振り分ける
end note

note bottom of Diamond
  専門エージェントからの応答が
  ユーザーに届く前に中央のモデレーション
  エージェントを通過する
end note

note bottom of P2P
  エージェントは誤った振り分けを検出すると
  互いにクエリを引き渡す能力がある
end note

note bottom of Collaborative
  複数のエージェントが同じタスクの
  補完的な側面に取り組み、結果を結合する
end note
@enduml
```

一般的なマルチエージェントデザインパターンには次のようなものがあります：

1. **階層型パターン**: 中央のオーケストレーターエージェントがクエリを分類し、専門エージェントにルーティングします。例えば、ユーザーが「近くの寿司レストランを探して」と尋ねると、オーケストレーターはこれをナビゲーションリクエストとして検出し、場所の検索やマップAPIとの対話を処理するナビゲーションエージェントにルーティングします。

2. **ダイアモンドパターン**: 階層型パターンの変形で、専門エージェントからの応答はユーザーに届く前に中央のモデレーションエージェントを通過します。例えば、ナビゲーションエージェントが近くのレストランに関する事実に基づく応答を生成し、次にテキスト音声合成の前にユーザーの好みに基づいてトーンとスタイルを調整するリファイナーエージェントを通過します。

3. **ピアツーピア**: エージェントは、オーケストレーションでルーティングミスを検出した場合、互いにクエリを引き渡すことができます。これにより、初期の誤分類から回復できるより弾力性のあるシステムが作成されます。

4. **協調パターン**: 複数のエージェントが同じタスクの補完的な側面に取り組み、レスポンスミキサーエージェントが異なるエージェントの応答から要素を組み合わせて包括的な回答を作成します。このアプローチは、異なるエージェントが専門知識に基づいて価値ある部分を完全なソリューションに提供することを認識しています。

デザインパターンの選択は、特定のアプリケーションとエージェント間の望ましい相互作用のレベルによって決まります。これらのパターンをビジネスに採用することで、運用のボトルネックを削減し、知識検索を改善し、自動化の信頼性を高めることができます。マルチエージェントシステムにより、企業は意思決定とワークフローの実行における俊敏性を確保しながら、AIデプロイメントをスケールすることができます。

### 2.3 マルチエージェントの課題と評価

マルチエージェントシステムは多くの利点を提供しますが、いくつかの課題も抱えています：

- **タスク通信**: 今日ほとんどのエージェントフレームワークは構造化された非同期タスクではなく、メッセージで通信します。
- **タスク割り当て**: 複雑なタスクを異なるエージェント間で効率的に分割するのは難しく、フィードバックループの実装はしばしば開発者に委ねられています。
- **推論の調整**: エージェントに効果的に議論させ、一緒に推論させるには洗練された調整メカニズムが必要です。
- **コンテキスト管理**: エージェント間のすべての情報、タスク、会話を追跡するのは圧倒的になりえます。
- **時間とコスト**: マルチエージェントの相互作用は計算的に高価で時間がかかる場合があります。これによりランタイム価格が高くなり、ユーザーのレイテンシが増加します。
- **複雑さ**: マイクロサービスアーキテクチャが各マイクロサービスにより柔軟性と単純さを提供するのと同じように、システム全体は通常より複雑になります。

幸いなことに、マルチエージェントシステムの評価は単一エージェントシステムの評価の明確な進化です。ビジネスメトリクスを北極星として、目標と重要タスクの成功メトリクス、レイテンシやエラーなどのアプリケーションテレメトリメトリクスなど、エージェント成功メトリクスは変わりません。トレースでマルチエージェントシステムを計測することで、複雑な相互作用中に何が起こっているかをデバッグし理解するのに役立ちます。

エージェント評価セクションで議論した軌跡と最終応答の評価は、エージェントの自動評価に最適なアプローチであり続けており、これはマルチエージェントシステムにも当てはまります。マルチエージェントシステムでは、アクションの軌跡にいくつかの、あるいはすべてのエージェントが含まれる場合があります。複数のエージェントがタスクで協力する場合でも、最終的には単一の回答がユーザーに返されるので、それを単独で評価できます。

マルチエージェントシステムには多くのステップがある可能性が高いため、各ステップでドリルダウンして評価できます。各エージェントを単独で評価し、システム全体も評価できます。軌跡評価はまさにこれを行うためのスケーラブルなアプローチです。

マルチエージェントシステムに固有のいくつかの質問があります：

- **協力と調整**: エージェントはどれだけうまく協力し、共通の目標を達成するために行動を調整していますか？
- **計画とタスク割り当て**: 正しい計画を立て、それを守りましたか？子エージェントはメインプランから逸脱したり、行き止まりに迷い込んだりしなかったですか？
- **エージェント活用**: エージェントはどれだけ効果的に正しいエージェントを選択し、ツールとしてエージェントを使用するか、バックグラウンドタスクを委任するか、ユーザーを転送するかを選んでいますか？
- **スケーラビリティ**: より多くのエージェントを追加するとシステムの品質は向上しますか？レイテンシは下がりますか？より効率的になっていますか？

これらの質問は、マルチエージェントシステムの改善領域を特定するための指針となります。単一エージェントシステムと同じツールを使用してこれらの質問に答えますが、分析の複雑さは増加します。

## 3. アジェンティックRAGと企業応用

### 3.1 アジェンティックRAGの進化と重要性

マルチエージェントアーキテクチャの重要な進化はアジェンティック検索拡張生成（Agentic RAG）です。従来のRAGパイプラインは、ベクトルデータベースから知識を取得し、それをLLMに合成のために供給するという静的なアプローチに依存しています。しかし、このアプローチは曖昧な、複数のステップ、または複数の視点を持つクエリを扱う場合に失敗することがよくあります。

アジェンティックRAGは、イテレーティブな推論に基づいて検索を能動的に洗練する自律的な検索エージェントを導入します。

```plantuml
@startuml
!theme plain
skinparam roundcorner 20
skinparam BackgroundColor #EEEBDC

actor "ユーザー" as User

rectangle "従来のRAG" as TraditionalRAG {
  component "クエリ" as Query1
  database "ベクトルDB" as VectorDB1
  component "LLM" as LLM1
  
  User --> Query1 : 質問
  Query1 --> VectorDB1 : 1回の検索
  VectorDB1 --> LLM1 : コンテキスト提供
  LLM1 --> User : 応答
}

rectangle "アジェンティックRAG" as AgenticRAG {
  component "クエリ拡張エージェント" as QueryAgent
  component "検索エージェント" as RetrievalAgent
  database "ベクトルDB" as VectorDB2
  database "ウェブ" as Web
  database "データベース" as DB
  component "検証エージェント" as ValidationAgent
  component "LLM" as LLM2
  
  User --> QueryAgent : 質問
  QueryAgent --> RetrievalAgent : 複数の洗練されたクエリ
  
  RetrievalAgent --> VectorDB2 : 検索
  RetrievalAgent --> Web : 検索
  RetrievalAgent --> DB : 検索
  
  VectorDB2 --> ValidationAgent : 結果
  Web --> ValidationAgent : 結果
  DB --> ValidationAgent : 結果
  
  ValidationAgent --> LLM2 : 検証済み情報
  LLM2 --> User : 応答
}

note bottom of TraditionalRAG
  • 単一のクエリで情報取得
  • 1つの知識ソースに依存
  • 単一ステップの検索プロセス
end note

note bottom of AgenticRAG
  • コンテキスト対応クエリ拡張
  • 複数ステップの推論
  • 適応的ソース選択
  • 検証と修正
  • 高精度と説明可能性
end note
@enduml
```

これらのエージェントは以下の方法で検索を強化します：

1. **コンテキスト対応クエリ拡張**: 単一の検索パスに依存する代わりに、エージェントは複数のクエリ洗練を生成し、より関連性が高く包括的な結果を取得します。

2. **複数ステップの推論**: エージェントは複雑なクエリをより小さな論理的ステップに分解し、構造化された応答を構築するために順番に情報を取得します。

3. **適応的ソース選択**: 単一のベクトルデータベースからデータを取得する代わりに、検索エージェントはコンテキストに基づいて最適な知識ソースを動的に選択します。

4. **検証と修正**: 評価エージェントは、取得された知識を最終応答に統合する前に、幻覚や矛盾がないかクロスチェックします。

このアプローチにより、応答の正確性、説明可能性、適応性が大幅に向上し、法的調査、科学的発見、ビジネスインテリジェンスなどの分野で複雑な知識検索タスクを扱う企業にとって重要なイノベーションとなっています。

アジェンティックRAG（検索拡張生成）は、RAGの強みと人工知能エージェントの自律性を組み合わせた高度なアプローチです。従来のRAGシステムは外部知識ソースから関連情報を取得してLLM応答を強化します。アジェンティックRAGはこれをさらに一歩進め、インテリジェントエージェントを採用して検索プロセスをオーケストレーションし、取得した情報を評価し、それをどのように最もよく活用するかを決定します。

アジェンティックRAGは従来のRAGに比べていくつかの利点を提供します：

- **精度の向上**: エージェントは取得した情報の品質を評価し、どのソースを信頼するかについて決定を下すことができ、より正確で信頼性の高い応答につながります。
- **コンテキスト理解の強化**: エージェントはユーザーのクエリのコンテキストと取得した情報を考慮して、より関連性が高く意味のある応答を生成できます。
- **適応性の向上**: エージェントは変化する情報ニーズに適応し、最新かつ関連性の高い情報を提供するために検索戦略を動的に調整できます。

ほぼすべてのRAGアプローチは、関連データのインデックス作成と取得のための検索エンジンを必要とします。エージェントの導入により、クエリの洗練、フィルタリング、ランキング、最終回答の精度向上が可能になります。

既存のRAG実装を最適化しようとしている開発者にとって、エージェントを導入する前に検索結果（再現率で測定）を改善することが通常最も価値があります。検索パフォーマンスを向上させるための主な技術には次のようなものがあります：

- **ソースドキュメントの解析とチャンク化**: Vertex AI Layout Parserは複雑なドキュメントレイアウト、埋め込みテーブル、チャートなどの埋め込み画像を処理し、意味的チャンカーを使用して見出しの階層でチャンクをトピックに保持します。
- **チャンクへのメタデータ追加**: 同義語、キーワード、著者、日付、タグ、カテゴリにより、検索のブースト、埋め込み、フィルタリングが可能になります。これによりユーザーやエージェントの検索結果をより細かく制御できます。
- **埋め込みモデルの微調整または検索アダプタの追加**: これにより、検索可能なベクトルインデックスが汎用埋め込みモデルよりもドメインをより適切に表現できるようになります。
- **より高速なベクトルデータベースの使用**: 埋め込みを検索するには、速度と精度の間でトレードオフを行う必要があります。Vertex AI Vector Searchのような超高速なベクトル検索にアップグレードすると、レイテンシと品質の両方が向上します。
- **ランカーの使用**: ベクトル検索は高速ですが近似的であり、数十または数百の結果を返すべきであり、それらは上位の結果が最も関連性が高いまたは最良の回答であることを確実にするためにより高度なシステムで再ランク付けする必要があります。
- **根拠チェックの実装**: 根拠に基づく生成のセーフガードとして、各フレーズが実際に取得されたチャンクによって引用可能であることを確認できます。

Vertex AI Searchは強力な検索エンジンであり、データに対してGoogle品質の検索を提供し、任意のRAGまたはアジェンティックRAG実装で使用できます。上記のコンポーネントはそれぞれ、開発時間をまったく必要とせずに、Vertex AI Search内で自動的に利用可能です。独自の検索エンジンを構築したい開発者向けに、上記の各コンポーネントはスタンドアロンAPIとして公開されており、RAG Engineは全体のパイプラインを簡単にオーケストレーションでき、LlamaIndexに似たPythonベースのインターフェースを提供します。

### 3.2 企業でのエージェント活用

2025年はエージェントの年であり、特に企業がエージェントを開発・使用して特定のタスクの実行を従業員に支援したり、自律的にバックグラウンドで自動化を実行したりするコンテキストでこれが特に当てはまります。ビジネスアナリストはAI生成のインサイトに支えられた業界トレンドを簡単に発見し、説得力のあるデータ駆動型プレゼンテーションを作成できます。HRチームは401k選択のような複雑なタスクでも、効率化されたオンボーディングでユーザーエクスペリエンスを革新できます。ソフトウェアエンジニアはバグを事前に特定して解決し、より効率的に構築・反復し、デプロイサイクルを加速させることができます。マーケターはより深いパフォーマンス分析のロックを解除し、コンテンツレコメンデーションを最適化し、キャンペーンを容易に微調整して優れた結果を達成できます。

2種類のエージェントが登場しています：

1. **「アシスタント」**: ユーザーと対話し、タスクを引き受け、実行し、ユーザーに戻ってくるエージェント。GemsやGPTなどのフレームワークで普及した会話型エージェントは通常このカテゴリに属します。アシスタントは汎用的なものもあれば、特定のドメインやタスクに特化したものもあります。例としては、会議のスケジュールを支援するエージェント、データを分析するエージェント、コードを書くエージェント、マーケティングプレスリリースを書くエージェント、販売者が販売機会を支援するエージェント、あるいはユーザーの要求に応じて特定のトピックについて深い調査を行うエージェントなどがあります。これらのエージェントは同期的であり、要求された情報を返すか、要求されたタスクを素早く実行するか、または長期間実行してから返す（深い調査エージェントのような）ことができます。

2. **「自動化エージェント」**: バックグラウンドで実行され、イベントを監視し、システムやデータの変更を監視し、賢明な決断を下して行動するエージェント。行動には、バックエンドシステムでの操作、観察を検証するためのテストの実行、問題の修正、適切な従業員への通知などが含まれる場合があります。これは将来の自動化のバックボーンと見なすことができます。過去では自動化のロジックを指定するための特別なコードを書く必要がありましたが、今ではAIエージェントのスマートで一般的な意思決定能力に頼ることができます。

```plantuml
@startuml
!theme plain
skinparam roundcorner 20
skinparam BackgroundColor #EEEBDC

actor "知識労働者" as Worker
actor "管理者" as Admin

cloud "Google Agentspace" {
  package "アシスタントエージェント" {
    component "データ分析エージェント" as DataAgent
    component "コード作成エージェント" as CodeAgent
    component "リサーチエージェント" as ResearchAgent
    component "マーケティングエージェント" as MarketingAgent
  }
  
  package "自動化エージェント" {
    component "監視エージェント" as MonitorAgent
    component "ワークフローエージェント" as WorkflowAgent
    component "通知エージェント" as NotificationAgent
  }
  
  package "管理システム" {
    component "アクセス管理" as AccessControl
    component "オーケストレーション" as Orchestration
    component "モニタリングUI" as MonitoringUI
  }
  
  database "企業データ" as EnterpriseData
}

Worker --> DataAgent : タスク割り当て
Worker --> CodeAgent : タスク割り当て
Worker --> ResearchAgent : タスク割り当て
Worker --> MarketingAgent : タスク割り当て

Worker <-- MonitoringUI : エージェント管理

Admin --> AccessControl : 設定管理
Admin --> Orchestration : フロー設定

DataAgent <--> EnterpriseData : データアクセス
CodeAgent <--> EnterpriseData : コードリポジトリアクセス
ResearchAgent <--> EnterpriseData : ドキュメントアクセス
MarketingAgent <--> EnterpriseData : キャンペーンデータアクセス

MonitorAgent <--> EnterpriseData : システム監視
WorkflowAgent <--> EnterpriseData : プロセス自動化
NotificationAgent <--> EnterpriseData : アラート管理

note bottom of Worker
  従来：単一のタスクを割り当て、結果を待つ
  未来：複数のエージェントを管理し、監督する
end note

note bottom of EnterpriseData
  セキュアな設計
  • ロールベースのアクセス制御(RBAC)
  • VPC Service Controls
  • IAM統合
end note
@enduml
```

単純にタスクを実行して出力を待つためにエージェントを呼び出すのではなく、ナレッジワーカーはますますエージェントのマネージャーになっていきます。彼らは複数のエージェントにタスクを割り当て、管理し、どのエージェントが助けを必要としているか、または進行するための承認が必要かをチェックし、特定のエージェントの出力を使用して新しいタスクを開始し、長時間実行タスクの実行をモニタリングして確認し、正しい方向に導くことができるようになります。このタイプの仮想チーム管理を可能にする新しいユーザーインターフェースが登場し、タスクを実行し、他のエージェントを呼び出す（または作成する）マルチエージェントシステムのオーケストレーション、モニタリング、管理を可能にします。

Google Agentspaceはこのタイプの体験を提供し、以下を可能にすることを目指しています：
- コード不要/低コードのインターフェースまたは完全なコードフレームワークを使用して、専門化されたアシスタントと自動化エージェントの両方を実装する新しいエージェントを作成
- 企業管理者のためのエージェントへのアクセスを設定および管理
- 適切なタイミングで適切なエージェントを呼び出す
- チーム管理に適したUIで複数のエージェントをモニタリング、管理、およびオーケストレーション

Google Agentspaceは、従業員に統合された会社ブランドのマルチモーダル検索エージェントを提供し、企業情報の決定的なソースとして機能します。Googleの広範な検索能力に基づき、Agentspaceは比類のない会話型アシスタンスを提供します。従業員は複雑なクエリへの回答、積極的なレコメンデーション、情報源を問わない情報への統一されたアクセスを得られます。この機能はドキュメントやメールなどの非構造化データだけでなく、テーブルなどの構造化データにも及びます。統合された翻訳機能により、情報の元の言語に関係なく、包括的な理解が保証されます。

NotebookLM Enterpriseは、複雑な情報を理解し統合するプロセスを効率化するように設計された研究・学習ツールです。ユーザーはドキュメント、ノート、その他の関連ファイルなど、様々なソース資料をアップロードし、人工知能の力を活用してより深い理解を促進することができます。多面的なトピックを研究している場合を想像してください。NotebookLMを使用すると、散らばったすべてのリソースを単一の整理されたワークスペースに統合できます。本質的に、NotebookLMは専用の研究アシスタントとして機能し、研究プロセスを加速し、ユーザーが単なる情報収集を超えて真の理解に移行できるようにします。

### 3.3 エージェントから契約者へ：新しい概念

様々なツールやプラットフォーム全体でAIエージェントを定義する現在の一般的なインターフェースは非常にシンプルで、通常、目標、いくつかのテキスト指示、エージェントが使用できるツール、および一連の例を指定するだけです。これはデモをプロトタイプ化するには十分かもしれませんが、潜在的に不完全な定義につながり、AIエージェントがプロトタイプから本番環境への移行に苦労する主要な理由の一つかもしれません。

エージェントインターフェースを「契約遵守エージェント」に進化させることを提案します。これは特に高いリスクのあるコンテキストで、AIエージェントを使用して複雑なタスクを解決することを目的としています。

契約者の鍵となるアイデアは、リクエスタとエージェント間の契約を指定し標準化することであり、以下を可能にします：

1. 実際の世界のシナリオで会社と契約する際と同様に、望ましい結果をできるだけ正確に定義します。これにより、エージェント（契約者）は望ましい結果に対して検証し、目的の目標が達成されるまで反復することができます。

2. タスクについて交渉し、明確化・洗練する可能性を提供し、目標の定義にあいまいさがないようにします。

3. より大きな契約を解決するために必要な新しいサブ契約を標準的な方法で生成するためのルールを契約者に定義します。

```plantuml
@startuml
!theme plain
skinparam roundcorner 20
skinparam BackgroundColor #EEEBDC

actor "ユーザー" as User
participant "エージェント\n(契約者)" as Agent

== 契約定義フェーズ ==
User -> Agent: 契約提案\n(タスク説明、成果物、範囲、期待コスト、期間)
note right
  契約の主要要素:
  - タスク/プロジェクト説明
  - 成果物と仕様
  - 範囲
  - 期待コスト
  - 期待期間
  - 入力ソース
  - 報告とフィードバック
end note

== 交渉フェーズ ==
Agent -> User: フィードバック\n(不明確な点、コスト交渉、リスク、追加入力要求)
User -> Agent: 契約更新\n(明確化、調整)

== 実行フェーズ ==
Agent -> Agent: タスク分析
Agent -> Agent: サブ契約生成(必要に応じて)
Agent -> Agent: 解決策生成
Agent -> Agent: 自己検証

== フィードバックフェーズ ==
Agent -> User: 進捗報告
User -> Agent: フィードバック提供

== 完了フェーズ ==
Agent -> User: 最終成果物提出
User -> Agent: 承認または修正要求

@enduml
```

契約実行には、契約者ランタイムが契約を履行し、定義された仕様に従って契約の背後にあるタスクを解決できることが必要です。品質と完全性をレイテンシよりも優先することで、異なるソリューションを生成し、それらをレビュー、スコアリング、進化させるなど、LLMの能力を最大限に活用できます。エンジンは提供された期待に基づいて結果と成果物を反復し、自己検証し、バリデータが満たされるまで改善し自己修正することができます。

企業世界の多くのタスクは、より制約の少ない方法（レイテンシとコスト面で）でLLMの力を活用することで大きな恩恵を受けられるというのが、自動化エージェントの文脈における契約の背後にある核心的な仮説です。

より複雑なタスクに取り組み、顧客が契約者の結果を信頼できるようにすることで、企業にとって真の価値を確保します。とはいえ、タスクが適切に優先順位付けされ、リソースが公平に割り当てられるように、相対的な優先度の概念を持つ必要があります。したがって、契約イニシエーターと契約者との間で議論し交渉できるコスト（通常、顧客または契約イニシエーターごとの相対的なもの）の概念を導入します。これにより、契約が契約イニシエーターによって開始された他の契約に対して適切なリソースを受け取ることを確保します。

## 4. 実際の応用例と実装

### 4.1 自動車AIにおけるマルチエージェントアーキテクチャ

マルチエージェントの概念が実際にどのように現れるかを示すために、自動車会話型AIのための包括的なマルチエージェントシステムを検討しましょう。このシステムでは、複数の専門エージェントが協力して直感的でシームレスな車内体験を提供します。

自動車ドメインは、生産環境におけるマルチエージェントアーキテクチャの課題と機会を例示しています。現代の車両は、接続性の有無にかかわらず機能する会話型インターフェース、安全性とユーザーエクスペリエンスの両方に対してオンデバイスとクラウド処理のバランスをとり、ナビゲーション、メディア制御、メッセージング、車両システム全体で専門能力をシームレスに調整する必要があります。

```plantuml
@startuml
!theme plain
skinparam roundcorner 20
skinparam BackgroundColor #EEEBDC

actor "運転者" as Driver
participant "車載システム" as CarSystem
participant "オーケストレーター\nエージェント" as Orchestrator
participant "ナビゲーション\nエージェント" as NavAgent
participant "メディア検索\nエージェント" as MediaAgent
participant "メッセージ作成\nエージェント" as MsgAgent
participant "車両マニュアル\nエージェント" as ManualAgent
participant "一般知識\nエージェント" as KnowledgeAgent

== ナビゲーションシナリオ ==
Driver -> CarSystem: "ミュンヘンへの道中で\nランチ休憩に良いレストランは？"
CarSystem -> Orchestrator: クエリ転送
Orchestrator -> NavAgent: ナビゲーション意図検出
NavAgent -> NavAgent: Google Places APIクエリ
NavAgent -> NavAgent: ユーザー好みに基づき\n結果を再ランク付け
NavAgent -> Orchestrator: レストラン情報提供
Orchestrator -> CarSystem: 応答フォーマット
CarSystem -> Driver: "A9沿いに3つの評価の高い\nレストランが見つかりました..."

== マルチドメインシナリオ ==
Driver -> CarSystem: "アクアプレーニングの対処法は？"
CarSystem -> Orchestrator: クエリ転送
Orchestrator -> ManualAgent: 車両固有の安全システム情報要求
Orchestrator -> KnowledgeAgent: 物理現象の説明要求
ManualAgent -> Orchestrator: "ESCおよびABSシステムが\n牽引制御を維持するのに役立ちます"
KnowledgeAgent -> Orchestrator: "アクアプレーニングは、\n水の蓄積によりタイヤが路面との\n接触を失う現象です"
Orchestrator -> Orchestrator: 応答統合
Orchestrator -> CarSystem: 統合応答
CarSystem -> Driver: "アクアプレーニングを経験した場合、\nアクセルを緩め、急ブレーキや\n急ハンドルを避け..."

@enduml
```

このユースケースを通じて、階層型、協調型、ピアツーピアなどの異なる調整パターンがどのように組み合わさって、制約の多い環境での堅牢で応答性の高いユーザーエクスペリエンスを作り出すかを見ることができます。このケーススタディは、企業が特定のドメインに適応できるマルチエージェントシステムの実用的な応用を示しています。

### 4.2 専門化エージェントと実装パターン

まず、いくつかの専門化エージェントの例を見てみましょう。

**会話型ナビゲーションエージェント**は、Google PlacesやMapsなどのAPIを使用して、ユーザーが場所を見つけ、場所を提案し、ナビゲートするのを支援することに特化しています。このエージェントは「近くの寿司レストランを見つけて」などのナビゲーション意図を理解し、Places APIで関連する結果をクエリし、ユーザーの好みと履歴データに基づいてこれらの結果を再ランク付けし、車の組み込みシステムにナビゲーションコマンドを送信します。

対話例：
ユーザー: 「ランチ休憩が必要です。ミュンヘンへの道中で良いレストランはありますか？」
ナビゲーションエージェント: 「A9沿いに3つの評価の高いレストランを見つけました。25キロ先のインゴルシュタット出口に「ガストハウス・アルテ・ミューレ」があります（4.5星）- レビューでは伝統的なバイエルン料理とビアガーデンが賞賛されています。45キロ先のサービスエリアには「ラ・ストラーダ」（4.1星）があり、クイックイタリアン料理の良いレビューがあります。または70キロ待てるなら、アラースハウゼン近くの「ツァイトロス」（4.7星）はやや高級でファームトゥテーブル料理です。どれが最も興味がありますか？」

**会話型メディア検索エージェント**は、ユーザーが音楽、オーディオブック、ポッドキャストを見つけて再生するのを支援することに特化しています。このエージェントはローカルデータベースやストリーミングサービスからメディアを取得し、必要に応じて追加コンテンツのためにウェブ検索を使用し、気分、天候、時間帯などの文脈的要素に基づいてメディアを提案し、「ドライブ中にリラックスできるプレイリストを再生して」などの音声コマンドを処理します。

**メッセージ作成エージェント**は、運転中にユーザーがメッセージやメールの下書き、要約、送信を行うのを支援することに特化しています。このエージェントは「アレックスに遅れていると伝えて」などの音声コマンドを解析し、自然言語モデルを使用して文脈的に適切なメッセージを作成し、ユーザーによる修正オプション付きの下書きプレビューを提供し、SMS、WhatsApp、メールなど様々なメッセージングアプリと統合します。

これらの専門エージェントを組み合わせるための一般的な方法を見てみましょう。

```plantuml
@startuml
!theme plain
skinparam roundcorner 20
skinparam BackgroundColor #EEEBDC

package "マルチエージェントシステム" {
  [オーケストレーター\nエージェント] as Orchestrator
  [ナビゲーション\nエージェント] as Navigation
  [メディア検索\nエージェント] as Media
  [メッセージ作成\nエージェント] as Messaging
  [車両マニュアル\nエージェント] as Manual
  [一般知識\nエージェント] as Knowledge
  [レスポンスミキサー\nエージェント] as Mixer
  [リファイナー\nエージェント] as Refiner
}

actor "ユーザー" as User

database "Google Places API" as PlacesAPI
database "地図サービス" as MapsService
database "メディアストリーミング\nサービス" as MediaService
database "メッセージングアプリ" as MessagingApps
database "車両マニュアル\nデータベース" as ManualDB
cloud "インターネット" as Internet

User --> Orchestrator : クエリ/コマンド

Orchestrator --> Navigation
Orchestrator --> Media
Orchestrator --> Messaging
Orchestrator --> Manual
Orchestrator --> Knowledge

Navigation --> PlacesAPI
Navigation --> MapsService
Media --> MediaService
Messaging --> MessagingApps
Manual --> ManualDB
Knowledge --> Internet

Navigation --> Mixer
Media --> Mixer
Messaging --> Mixer
Manual --> Mixer
Knowledge --> Mixer

Mixer --> Refiner
Refiner --> User : 最終応答

note right of Orchestrator
  ユーザークエリを分析し、
  最適な専門エージェントに
  ルーティングする
end note

note right of Mixer
  複数のエージェントからの
  応答を評価し、最も有用な
  部分を結合する
end note

note right of Refiner
  技術情報を会話的な言葉に変換し、
  ユーザー好みと運転状況に
  応じて応答を調整する
end note
@enduml
```

自動車AIにおけるマルチエージェントシステムの主要なパターンは以下の通りです：

**階層型パターン**: 中央のオーケストレーターエージェントがクエリを分類し、専門エージェントにルーティングします。例えば、ユーザーが「近くの寿司レストランを見つけて」と尋ねると、オーケストレーターはこれをナビゲーションリクエストとして検出し、ナビゲーションエージェントにルーティングします。

**ダイアモンドパターン**: 階層型パターンの変種で、専門エージェントからの応答はユーザーに届く前に中央のモデレーションエージェントを通過します。例えば、ナビゲーションエージェントが近くのレストランに関する事実に基づく応答を生成し、次にユーザー好みに基づいてトーンとスタイルを調整するリファイナーエージェントを通過してからテキスト音声合成されます。

**ピアツーピア**: エージェントは、オーケストレーションでルーティングミスを検出した場合、互いにクエリを引き渡すことができます。これにより、初期の誤分類から回復できるより弾力性のあるシステムが作成されます。

**協調パターン**: 複数のエージェントが同じタスクの補完的な側面に取り組み、レスポンスミキサーエージェントが異なるエージェントの応答から要素を組み合わせて包括的な回答を作成します。例えば、アクアプレーニングの対処法について質問された場合、車両マニュアルエージェントは車両固有の安全システム情報を提供し、運転のヒントエージェントは実用的な運転テクニックを提供し、一般知識エージェントは現象の背後にある物理学を説明します。

**適応ループパターン**: 初期クエリが満足のいく結果を生成しない場合、繰り返し改善を通じて結果が望ましい基準を満たすまでステップバイステップの改善を行います。

自動車AIにおけるマルチエージェントシステムは、複雑なタスクを専門的な役割に分解することで強力な利点をもたらします。一人の総合的な専門家ではなく、専門家チームを組み立てるように考えてください。このアプローチでは、各エージェントは最も得意なことに特化します。

この専門化により、システム全体の効率が向上します。エージェントがより狭いタスクセットを扱うと、そのパフォーマンスを最適化するのがより簡単になります。結果として、より高品質の応答がより迅速に、より低い計算コストで提供されます。

車両では速度が重要であり、マルチエージェントシステムはそれが重要な場所で提供します。空調の調整や窓の開閉などの重要な機能は、即時応答のために高速なオンデバイスエージェントで実行されます。一方、レストランのレコメンデーションなどの緊急性の低いタスクは、より広範な知識を持つクラウドベースのエージェントを使用できます。

### 4.3 Googleのツールとエコシステム

Google Agentspaceは、関連情報へのアクセスを促進し、複雑なエージェント型ワークフローを自動化することで企業の生産性を向上させるように設計されたAI駆動ツールのスイートを提供します。Geminiの高度な推論能力、Googleの検索インフラストラクチャの力、物理的な場所に関わらず企業データへの安全なアクセスを活用しています。

Agentspaceは、パーソナライゼーション、自動回答生成、コンテキスト理解、包括的な情報検索などの分野で従来の知識管理システムに固有の制限に直接対処します。分散したコンテンツソースを統合し、根拠に基づいたパーソナライズされた応答を生成し、運用ワークフローを合理化することで、従業員に効率的な情報アクセスを提供します。

NotebookLM Enterpriseは、NotebookLM Plusの基盤の上に構築され、これらの強力な機能を企業環境にもたらし、従業員がデータとどのように相互作用し、洞察を引き出すかを効率化します。この企業グレードのバージョンでは、ユーザーは情報をアップロードして合成するだけでなく、隠れたパターンを発見し、革新的な方法でデータとやり取りすることもできます。

```plantuml
@startuml
!theme plain
skinparam roundcorner 20
skinparam BackgroundColor #EEEBDC

package "Google AI Agent エコシステム" {
  frame "エンタープライズプラットフォーム" {
    [Google Agentspace] as Agentspace
    [NotebookLM Enterprise] as NotebookLM
  }
  
  frame "開発者ツール" {
    [Vertex AI Agent Builder] as AgentBuilder
    [Vertex AI Agent Engine] as AgentEngine
    [Vertex AI Eval Service] as EvalService
  }
  
  frame "エージェントツール" {
    [Vertex AI Search] as Search
    [RAG Engine] as RAGEngine
    [Gen AI Toolbox for Databases] as DBToolbox
    [Application Integrations] as AppIntegrations
    [Apigee Hub] as ApigeeHub
  }
  
  frame "基盤モデル" {
    [Gemini Models] as Gemini
    [Vertex AI Model Garden] as ModelGarden
  }
}

Agentspace --> AgentEngine : 実行基盤
NotebookLM --> AgentEngine : 実行基盤

AgentBuilder --> AgentEngine : デプロイ
AgentBuilder --> EvalService : 評価

AgentEngine --> Search : 検索ツール
AgentEngine --> RAGEngine : RAGツール
AgentEngine --> DBToolbox : DB接続
AgentEngine --> AppIntegrations : API接続
AgentEngine --> ApigeeHub : API管理

AgentEngine --> Gemini : 推論
AgentEngine --> ModelGarden : モデル選択

note bottom of Agentspace
  企業向け統合検索・エージェントプラットフォーム
  • 社内データへの安全なアクセス
  • カスタムエージェントの作成と管理
  • ワークフロー自動化
end note

note bottom of AgentEngine
  エージェント開発を合理化
  • オープンソースライブラリとの統合
  • 自動スケーリング実行環境
  • セッション、例、トレース、評価サービス
end note

note bottom of EvalService
  包括的な評価ツール
  • LLM評価
  • RAG評価
  • エージェント評価
  • モニタリングと実験との統合
end note

note bottom of Gemini
  エージェント向け最先端モデル
  • 高度な推論能力
  • マルチモーダル理解
  • コンテキスト保持能力
end note
@enduml
```

Vertex AI Agent Builderは開発者向けの製品とサービスのコレクションです。エージェントを構築し接続するための包括的なプラットフォームを提供しています。Google Cloudのエンジニアリングの卓越性とセキュリティ、Google Deepmindのリサーチ、そしてAgentOpsのベストプラクティスが組み合わされています。Googleはこのプラットフォーム上に独自のエージェントを構築しており、今では開発者もそれを活用できます。2025年には開発者向けにさらに多くの興味深い発表が予定されています。

Vertex AI Agent Engineは、人気のあるオープンソースエージェントライブラリとの統合を管理するGoogleエンジニアリングに依存して開発を合理化します。管理された自動スケーリングランタイムと、エージェントが必要とする多くのサービス（セッション、例、トレース、評価など）を提供します。これは、任意のフレームワークで記述したエージェントを安全に展開するための非常に低い労力で高い価値を持つ方法です。

Vertex AI Eval Serviceは、このブログ記事で議論されたすべての評価ツールを提供しています。LLM、RAG、およびエージェント評価は、Vertex AI Eval Serviceを通じて安定してスケーラブルであり、モニタリングと実験のオファリングに便利に統合されています。

今後に期待されるエージェントツールの大規模なポートフォリオには以下が含まれます：
- Vertex AI SearchやRAG Engineを通じた検索
- Gen AI Toolbox for Databasesを通じた非検索ベースのDBからの取得
- 完全なACLをサポートする数百のAPIとのアプリケーション統合
- Apigee Hubを使用した任意のAPIの管理された企業対応ツールへの変換

そしてもちろん、エージェント向けの最高のLLMも提供されており、Vertex AI Model Gardenへのアクセスと、エージェンティックな時代を支えるGeminiファミリーのモデルも利用可能です。

## 5. まとめと将来の展望

### 5.1 主要なポイント

この記事では、生成AIエージェントの急速に進化する分野を、その基本的なアーキテクチャから高度な評価技術、そしてマルチエージェントシステムの変革的な可能性まで探求しました。

開発者のための主要なポイントは以下の通りです：

1. **AgentOpsは不可欠**: 成功するエージェントの構築は初期のプルーフオブコンセプトをはるかに超えています。DevOpsとMLOpsのベストプラクティスを統合するAgentOpsの原則を採用しながら、ツール管理、オーケストレーション、メモリ、タスク分解などのエージェント固有の要素にも焦点を当てましょう。

2. **メトリクスが改善を促進**: 「北極星」としてビジネスレベルのKPI（目標達成、ユーザーエンゲージメント、収益など）から始めましょう。次に、重要なタスク、ユーザーインタラクション、エージェントアクション（トレース）に関連する詳細なメトリクスを追跡するようにエージェントを計測します。人間のフィードバック（👍、ユーザー調査）は非常に価値があります。

3. **自動評価が重要**: 手動テストだけに頼らないでください。エージェントの能力、軌跡（取られたステップ）、最終応答を評価する自動評価フレームワークを実装しましょう。軌跡評価には完全一致、順序一致、精度/再現率などのテクニックを活用し、最終応答の品質にはオートレーター（判断するLLM）を活用しましょう。

4. **人間介在は重要**: 自動化されたメトリクスは強力ですが、人間の評価は特に創造性、常識、ニュアンスなどの主観的な側面に不可欠なコンテキストを提供します。人間のフィードバックを使用して、自動評価メソッドを調整・検証しましょう。ドメイン知識をアウトソースしないでください。

5. **マルチエージェントシステムは利点を提供**: 複雑なタスクにはマルチエージェントアーキテクチャを検討しましょう。正確性、効率性、スケーラビリティ、および障害耐性を向上させることができます。異なるデザインパターン（階層型、ダイアモンド型、ピアツーピア、協調型）を理解し、アプリケーションに適したものを選択しましょう。

6. **アジェンティックRAGは関連性を向上**: 検索クエリを積極的に洗練し、取得した情報を評価し、進化する知識に適応するエージェントを組み込むことで、従来のRAGを超えましょう。これにより、より正確で文脈的に関連のある応答につながります。

7. **検索最適化はRAGの基礎**: 複雑なアジェンティックRAGに進む前に、基盤となる検索エンジンを最適化しましょう。意味的チャンク化、メタデータ強化、埋め込みモデルの微調整、ランカーの使用などの技術により、検索品質を大幅に向上させることができます。

8. **エージェントとツールのレジストリが重要**: 使用しているエージェントやツールの数が増えるにつれて、能力、オントロジー、パフォーマンスを管理するレジストリが必須になります。

9. **セキュリティは最重要**: 特に企業内でエージェントをデプロイする場合、セキュリティを優先しましょう。RBAC、VPC Service Controls、IAM統合などの組み込みセキュリティ機能を提供するGoogle Agentspaceのようなプラットフォームを活用しましょう。

10. **開発者サイクルの効率的な使用**: 古典的な「構築 vs 購入」の設計選択は依然として重要であり、生成AIエージェントの業界は急速に進化しています。ゼロから構築する代わりに、プラットフォームと製品を検討しましょう。これにより、急速に変化する業界の変動を緩和し、データ、ドメイン、ユーザーに集中できるようになります。

### 5.2 今後の研究と開発の方向性

AIエージェントの分野は急速に進化しています。進行中の研究と開発の主要な分野は以下の通りです：

- **高度な評価方法**: 推論に焦点を当てたプロセスベースの評価、AIアシスト評価、標準化されたベンチマークなど、より堅牢でスケーラブルな評価技術の開発。

- **マルチエージェント調整**: より効果的なコラボレーション、タスク処理、推論を可能にするために、マルチエージェントシステム内の調整とコミュニケーションメカニズムの改善。

- **実世界適応**: 動的で予測不可能な実世界環境で適応し学習できるエージェントの作成。自動車AIのような本番システムは、重要な機能にはオンデバイスのパフォーマンス、複雑なタスクにはクラウドベースの能力のバランスをとる必要があり、しばしば変化する接続状況に適応する必要があります。

- **説明可能性と解釈可能性**: エージェントの行動をより透明で理解しやすくし、開発者とユーザーが意思決定プロセスについてより深い洞察を得られるようにする。

- **長期記憶と学習**: エージェントが拡張期間にわたって情報を保持し活用できるようにする、より洗練されたメモリメカニズムの開発。継続的な学習と適応を可能にします。

- **エージェント通信プロトコル**: 特に不透明なリモートシステム間で、エージェントがタスク、知識、メッセージをどのように共有するかをより適切に定義すること。

- **エージェントから契約者へ**: エージェントが次のレベルの信頼性と有用性に到達するためには、タスクの定義を向上させる必要があります。明確な成果物、検証メカニズム、および他の企業から作業を契約する方法と同様に、あいまいさを交渉する能力を持つ契約にタスクを変換します。

### 5.3 開発者へのアクション指針

AIの未来はエージェント型です。これらの概念を採用し、次世代の知的アプリケーションの構築を始めることをお勧めします。この記事で議論されたツールと技術を使って実験を始めましょう。Google Agentspace、NotebookLM Enterprise、Vertex Eval Service、Cloud Observability、Vertex AI Searchなどの利用可能なリソースを探索して、開発プロセスを加速しましょう。

提供されたコード例、チュートリアル、ドキュメントに取り組んで、実践的な経験を得ましょう。構築し、評価し、繰り返し、成長するエージェント開発者コミュニティに貢献しましょう。可能性は無限であり、構築する時は今です！