🔍

[翻訳] OpenSearch で実現する Agentic AI エクスペリエンス

tkykenmt

2025/06/10に公開

Model Context Protocol

OpenSearch

Agent

tech

検索が従来のテキストベースの入力から会話型の双方向エクスペリエンスへと進化する中、Agentic AI の力によって、システム、アプリケーション、大規模言語モデル (LLM) との新しい接続方法が実現されています。最近、私たちはオープンソースソリューションとして OpenSearch 用の Model Context Protocol (MCP) サーバーをリリースしました。このブログ記事では、MCP を使用して Amazon Q Developer CLI と OpenSearch の Agentic AI ツールを統合する方法を紹介します。自然言語を使用してアプリケーションに関する有用な分析とインサイトを抽出する方法を、ステップバイステップで説明します。

開発者、データエンジニア、ソリューションアーキテクトの方々に向けて、このガイドでは OpenSearch における AI 機能の変革的な可能性を紹介し、より知的で効率的な検索エクスペリエンスの実現をサポートします。

前提条件

Amazon Q Developer CLI
Python 3.10+
OpenSearch クラスター (セルフマネージドまたは Amazon OpenSearch Service)

セットアップ

OpenSearch で Agentic AI を使用するには、以下の手順に従います。

1. 必要なツールのインストール

まず、OpenSearch MCP サーバーの実行に必要なツールである uv パッケージマネージャーをインストールします:

pip install uv

2. Amazon Q Developer CLI の設定

Amazon Q Developer CLI 用の MCP 設定ファイルを ~/.aws/amazonq/mcp.json に作成または編集します。Amazon Q Developer CLI を Amazon OpenSearch Service に接続するには、クラスターのエンドポイントとクラスターへのアクセス権限を持つ AWS 認証情報を提供します:

{
  "mcpServers": {
    "opensearch-mcp-server": {
      "command": "uvx",
      "args": ["opensearch-mcp-server-py"],
      "env": {
        "OPENSEARCH_URL": "<your_opensearch_domain_url>",

        // IAM 認証
        "AWS_REGION": "<your_aws_region>",
        "AWS_ACCESS_KEY_ID": "<your_aws_access_key>",
        "AWS_SECRET_ACCESS_KEY": "<your_aws_secret_access_key>",
        "AWS_SESSION_TOKEN": "<your_aws_session_token>"
      }
    }
  }
}

または、mcp.json 設定ファイルを使用する代わりに、OpenSearch URL と AWS Identity and Access Management (IAM) 認証情報を直接ターミナルセッションの環境変数として設定することもできます。

3. Amazon Q Developer CLI の使用

q chat を使用して Amazon Q Developer CLI のチャットセッションを開始します。opensearch_mcp_server が正常に読み込まれたことが確認できます:

> q
✓ opensearch_mcp_server loaded in 0.36 s
✓ 1 of 1 mcp servers initialized.

Amazon Q 内で /tools コマンドを使用すると、4 つの OpenSearch ツール (GetShardsTool、IndexMappingTool、ListIndexTool、SearchIndexTool) が読み込まれていることを確認できます。今後のバージョンでは、システムの機能を拡張するために追加の OpenSearch ツールが追加される予定です。

デフォルトでは、新しく追加されたツールは信頼されていない状態であり、Amazon Q がツールを使用しようとするたびに確認が求められます。オプションで、/tools trust <full_tool_name> または /tools trustall を使用してツールを信頼するように指定し、確認をスキップすることができます:

> /tools

𝗧𝗼𝗼𝗹 𝗣𝗲𝗿𝗺𝗶𝘀𝘀𝗶𝗼𝗻
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
𝗕𝘂𝗶𝗹𝘁-𝗶𝗻:
- execute_bash * trust read-only commands
- fs_read  * 𝘁𝗿𝘂𝘀𝘁𝗲𝗱
- fs_write * not trusted
- report_issue * 𝘁𝗿𝘂𝘀𝘁𝗲𝗱
- use_aws  * trust read-only commands

𝗼𝗽𝗲𝗻𝘀𝗲𝗮𝗿𝗰𝗵_𝗺𝗰𝗽_𝘀𝗲𝗿𝘃𝗲𝗿 (𝗠𝗖𝗣):
- opensearch_mcp_server___GetShardsTool  * not trusted
- opensearch_mcp_server___IndexMappingTool * not trusted
- opensearch_mcp_server___ListIndexTool  * not trusted
- opensearch_mcp_server___SearchIndexTool  * not trusted

Amazon Q Developer CLI での OpenSearch の使用

Amazon Q Developer CLI と OpenSearch MCP サーバーの設定が完了したら、OpenSearch データのクエリを開始できます:

> list indices
OpenSearch のインデックスを一覧表示します。情報を取得しています。

🛠️ Using tool: ListIndexTool from mcp server opensearch_mcp_server
 ⋮
 ● Running ListIndexTool with the param:
 ⋮ {
 ⋮ "arguments": {},
 ⋮ "name": "ListIndexTool"
 ⋮ }
Allow this action? Use 't' to trust (always allow) this tool for the session. [y/n/t]:

> y
 ⋮
 ● Completed in 1.8s
OpenSearch クラスター内のインデックス一覧:
1. .plugins-ml-model-group
2. tmdb
3. .plugins-ml-memory-meta
4. .ql-datasources
5. .plugins-ml-task
...

インデックスの一覧表示と検索が可能になったので、Amazon Q Developer CLI を使用してより高度なユースケース (データの要約など) を実行できます:

> give me a quick summary of my eCommerce data
eCommerce データの要約を提供します。OpenSearch の eCommerce サンプルデータインデックスを
クエリして情報を取得します。

🛠️ Using tool: SearchIndexTool from mcp server opensearch_mcp_server
...

# eCommerce データの要約
eCommerce サンプルデータの概要は以下の通りです:

## 注文統計
• 総注文数: 4,675
• 平均注文金額: $75.06
• 最小注文金額: $6.99
• 最大注文金額: $2,250.00

## 人気カテゴリ
1. メンズ衣類 (2,024 件)
2. レディース衣類 (1,903 件)
3. レディースシューズ (1,136 件)
4. メンズシューズ (944 件)
5. レディースアクセサリー (830 件)

## 主要メーカー
1. Low Tide Media (1,553 件)
2. Elitelligence (1,370 件)
3. Oceanavigations (1,218 件)
4. Tigress Enterprises (1,055 件)
5. Pyramidustries (947 件)

## 顧客層の分布
• 女性顧客: 2,433 件 (52%)
• 男性顧客: 2,242 件 (48%)

このデータは衣類とアクセサリーに焦点を当てたサンプルデータセットで、顧客の性別分布は
ほぼ均等です。

OpenSearch の可観測性を使用している場合、Amazon Q Developer CLI を使用してシステムのパフォーマンスを詳細に調査できます。以下は例です:

> check my otel traces, show me latency by service name

OpenTelemetry (OTel) トレースを分析して、サービス名ごとのレイテンシーを表示します。
関連するインデックスをクエリします。

🛠️ Using tool: SearchIndexTool from mcp server opensearch_mcp_server
 ⋮
 ● Running SearchIndexTool with the param:
...

OpenTelemetry トレースに基づく、サービス名ごとのレイテンシー分析:

## サービスレイテンシーの要約 (ナノ秒単位)
| サービス | リクエスト数 | 最小レイテンシー | 平均レイテンシー | 最大レイテンシー | 平均 (ms) |
|---------|------------|--------------|---------------|---------------|------------|
| frontend | 4,486 | 5,376 | 4,212,749 | 297,229,056 | 4.21 ms |
| cartservice | 1,151 | 573,500 | 908,025 | 5,473,600 | 0.91 ms |
| productcatalogservice | 976 | 5,025 | 1,179,214 | 9,671,364 | 1.18 ms |
| loadgenerator | 792 | 4,075,763 | 12,225,651 | 298,967,030 | 12.23 ms |
| checkoutservice | 662 | 258,431 | 6,623,067 | 288,126,051 | 6.62 ms |
| paymentservice | 403 | 8,448 | 108,115 | 4,312,064 | 0.11 ms |
| featureflagservice | 385 | 468,824 | 786,792 | 4,978,760 | 0.79 ms |
| recommendationservice | 271 | 880,730 | 8,177,191 | 13,767,667 | 8.18 ms |
| emailservice | 196 | 63,342 | 3,739,964 | 189,894,340 | 3.74 ms |
| adservice | 170 | 36,500 | 3,126,550 | 141,348,925 | 3.13 ms |

## 主な観察事項:
1. トラフィックが最も多いサービス:
 • frontend (4,486 リクエスト)
 • cartservice (1,151 リクエスト)
 • productcatalogservice (976 リクエスト)

2. 平均レイテンシーが最も高いサービス:
 • loadgenerator (12.23 ms)
 • recommendationservice (8.18 ms)
 • checkoutservice (6.62 ms)

3. 最大レイテンシーが最も高いサービス (潜在的な外れ値):
 • loadgenerator (298.97 ms)
 • frontend (297.23 ms)
 • checkoutservice (288.13 ms)

4. 最も効率的なサービス:
 • paymentservice (平均 0.11 ms)
 • featureflagservice (平均 0.79 ms)
 • cartservice (平均 0.91 ms)

このデータから、frontend が最も多くのリクエストを処理している一方で、loadgenerator、
recommendationservice、checkoutservice が最も高い平均レイテンシーを示していることが
わかります。paymentservice は最も低い平均レイテンシーで最も効率的なサービスと
なっています。

OpenTelemetry トレースとレイテンシーデータの初期分析を受け取った後、フォローアップの質問でより深い調査を行うことができます。以下は、loadgenerator の平均レイテンシーが高い理由を調査する例です:

> why does loadgenerator have high average latencies?

loadgenerator の平均レイテンシーが高い理由を理解するために、そのトレースについてより
詳細な情報を調べます。loadgenerator サービスに関するより具体的な情報をクエリします。

🛠️ Using tool: SearchIndexTool from mcp server opensearch_mcp_server
 ⋮
 ● Running SearchIndexTool with the param:
...
...

OpenTelemetry トレースデータを詳細に分析した結果、マイクロサービスアーキテクチャの他の
サービスと比較して loadgenerator サービスのレイテンシーが著しく高い理由を説明できます。

## Loadgenerator の高レイテンシーの根本原因

loadgenerator サービスの高レイテンシーは設計上の仕様であり、すべてのダウンストリーム
サービスの処理を含む完全なエンドツーエンドのリクエスト時間を表しています。以下が
その詳細です:

1. クライアント側の測定: loadgenerator は OpenTelemetry インストルメンテーションを
備えた Python の requests ライブラリを使用して HTTP 呼び出しを行います。loadgenerator
からのスパンは、リクエストのライフサイクル全体を測定する CLIENT スパンです。

2. エンドツーエンドのタイミング: トレース 753ef52011e443ed190dbf6f31c30cad を見ると:
 • loadgenerator スパンは 2023-11-23T00:16:14.063978483Z に開始
 • 2023-11-23T00:16:14.362945513Z に終了
 • 合計時間: 298.97ms

3. ネストされたサービス呼び出し: frontend サービスはこのリクエストを受け取り、
loadgenerator のスパンのほぼ全期間である 297.23ms のスパンを作成します。

4. カスケード型サービス呼び出し: システムを通じてトレースを追跡すると:
 • Frontend が CheckoutService に gRPC 呼び出しを行う (291.63ms)
 • CheckoutService が注文を処理する (288.13ms)
 • CheckoutService が EmailService に HTTP POST を行う (193.04ms)
 • 複数のサービスを通じて処理が続く

## トレース分析による確認

完全なトレース 6f0611913ca16432c5952b2c76bd3f1f を調べると:
• frontend が合成リクエストを開始 (loadgenerator の元のリクエストにリンク)
• これが複数のサービス (checkout、email など) を通じてカスケードする
• 各サービスが独自の処理時間を追加
• loadgenerator のスパンがこれらすべての処理時間を包含

## これが正常である理由

1. 負荷テストツール: loadgenerator はユーザートラフィックをシミュレートし、完全な
レスポンス時間を測定するように設計されています。高レイテンシーはバグではなく機能です。

2. インストルメンテーションの違い: 他のサービスが内部処理時間を報告するのに対し、
loadgenerator は完全なクライアントエクスペリエンス時間を報告します。

3. ネットワークオーバーヘッド: loadgenerator のスパンには、すべてのサービス間の
ネットワークレイテンシーが含まれ、これが大きく積み重なります。

## 推奨事項

1. これは期待される動作: loadgenerator の高レイテンシーは正常であり、システムにおける
その役割を反映しています。

2. パフォーマンステストへの活用: これらの測定値はエンドツーエンドのパフォーマンス
テストに有用です。

3. メトリクスの分離: サービスパフォーマンスを評価する際は以下を考慮:
 • 内部サービスレイテンシー (各サービスの SERVER スパンから)
 • エンドツーエンドレイテンシー (loadgenerator の CLIENT スパンから)

4. 最適化の焦点: システム全体のパフォーマンスを改善したい場合は、loadgenerator 自体
ではなく、内部処理時間が最も長いサービス (checkout、recommendation、email サービス) に
焦点を当てます。

loadgenerator は、すべてのダウンストリームサービスの処理とネットワークオーバーヘッドを
含む完全なユーザーエクスペリエンス時間を正しく測定しています。

まとめ

OpenSearch の Agentic AI 機能は、高度な分析、調査、要約、レポート作成を可能にすることで、
実世界での価値を提供します。この記事で紹介した統合は、従来の検索機能を強化するだけでなく、
システムパフォーマンスとデータ分析に関するより深いインサイトを提供し、開発者とデータ
エンジニアにとって価値あるツールとなります。

OpenSearch での Agentic AI の使用について詳しく学ぶには、最近のブログ記事 OpenSearch における MCP の紹介をご覧ください。OpenSearch MCP リポジトリでのフィードバックと貢献をお待ちしています。

OpenSearch ProjectPublication

OpenSearch Project(OSS) の Publicationです。 OpenSearch Tokyo User Group : meetup.com/opensearch-project-tokyo/