Amazon OpenSearch Service、エージェント型観測性を強化する MCP アプリ公開

観測エージェントは高速です。アラートを照会し、ログとトレースを相関付け、数分で根本原因の仮説を導き出します。しかし、まだ時間がかかる部分があります。

エージェントのテキスト要約を読み、ブラウザで観測ツールを開き、トレースウォーターフォールへ移動し、サービスマップで影響範囲を確認し、最後にエージェントが伝えた内容と画面に表示された内容を照合する作業です。エージェントはクエリにかかる時間を節約しましたが、タブを切り替える手間や文脈を引き継ぐ時間、手動での検証時間は節約してくれません。それは依然としてあなたの仕事です。

Amazon OpenSearch Service MCP Apps はこのギャップを埋めます。MCP Apps はモデルコンテキストプロトコル（Model Context Protocol）を拡張し、各ツールの呼び出しに対してインタラクティブな可視化——トレースウォーターフォール、サービストポロジー、ログパターンビューなど——を返すようにします。これらは AI アシスタントのチャットウィンドウ内で、テキスト応答と並んで直接レンダリングされます。

エージェントに調査を依頼すると、エージェントは Amazon OpenSearch Service を照会します。その結果として、テキストによる説明だけでなく、関連するダッシュボードウィジェットも同時に届きます。質問したスレッド内でそのまま検証できるため、別ブラウザのタブを開いたり、クエリを再実行したりする必要はありません。

本稿では、MCP Apps が観測ワークフローをどのように変えるかについて解説し、セットアップ手順を順を追って説明します。

課題：検証には依然としてエージェントループからの離脱が必要

一般的な調査プロセスは以下の通りです。まずエンジニアがエージェントに質問し、テキストベースの根本原因仮説を受け取ります。次に、IDE を離れてブラウザを開き、別の観測用 UI にログインします。その後、別のツールで手動クエリを再実行して、エージェントが見つけた現象を再現します。エージェントからの出力と実際のダッシュボードを見比べて視覚的に検証した後、再びエージェントに戻って会話を再開しますが、その際に調査の行方を見失っています。

エージェントは数秒で回答を生成しますが、検証にはエージェントの環境から離れる必要があります。つまり、別の観測用体験にログインし、手動でダッシュボードを操作する必要があるのです。この外部での検証ループがボトルネックとなっています。これによりツール切り替えの役割を強要され、アジェンティック自動化が持つ速度優位性が損なわれてしまいます。

ローカル環境でアジェンティック観測を実行している組織は、ベンダー提供の AI ではなく制御性とコスト効率を選択しました。しかし歴史的にこの選択にはトレードオフが伴います。ローカルのアジェンティック設定では、AI と自社のサービスを密結合させたベンダーホスト型ソリューションと比較して、使いやすさや場合によってはエージェントのパフォーマンスが犠牲になります。これらのチームにとって、検証のギャップが最大の運用負荷となっています。自律性を最適化しましたが、依然として検証は人間の速度で行われ、別の観測ツール上で行われています。

解決策：MCP Apps が IDE に観測 UI を持ち込む

Amazon OpenSearch Service は、MCP（Model Context Protocol）の機能を拡張する「MCP Apps」をサポートしました。この機能は、*デュアルレスポンス*パターンを採用しています。

AI エージェントが MCP App のツールを呼び出すと、応答には 2 つの部分が含まれます。1 つ目は、簡潔で構造化されたデータを含む*テキストサマリー*です。2 つ目は、会話スレッド内で直接レンダリングされる*インタラクティブな可視化*で、ユーザーが確認できるようになっています。

OpenSearch MCP App は、ダッシュボードの基盤となっている同じデータソースに対してコードを実行することで可視化を生成します。そのため、結果は常に*決定論的*（再現可能）です。AI の解釈を盲目的に信頼するのではなく、実際のクエリ結果がインタラクティブなチャートやトレースウォーターフォール、サービスマップとして描画されるのを直接確認できます。

図 1: エージェント IDE 内でレンダリングされた MCP App の観測レポート。サービス別のエラー数と、AI が生成した根本原因分析を併せて表示しています。

仕組みについて

MCP Apps 機能は、ローカルの MCP サーバー、IDE（統合開発環境）、そして OpenSearch UI アプリケーションが連携して動作します。ここでは、アーキテクチャ、プロトコル拡張の仕組み、および単一のツール呼び出しにおけるエンドツーエンドの流れを解説します。

アーキテクチャ

ローカル MCP サーバーは、お客様のマシン上で動作します。これは、エージェント型 IDE と OpenSearch UI アプリケーションの間を安全に繋ぐブリッジとして機能し、AI エージェントが呼び出せる観測ツールを公開します。各ツールの呼び出しは MCP サーバーを経由して OpenSearch UI エンドポイントへ送られ、クエリを実行した上で、双方向のレスポンス（テキストとビジュアル）を IDE へ返却します。

OpenSearch UI は、OpenSearch ドメイン、サーバーレスコレクション、CloudWatch、Amazon Managed Service for Prometheus と連携する、統一された観測のためのサーバーレスインターフェースです（詳細は OpenSearch UI のページをご覧ください）。

以下の図はリクエストフローを示しています：

Your IDE or AI desktop client (Claude, VS Code, Cursor, etc.)
  ↓ tool call
Local MCP server (runs on your machine)
  ↓ authenticated query
OpenSearch UI application (connected with your data sources)
  ↓ dual response
Your IDE ← text summary + interactive MCP App visualization

完全な制御権を保持できます。MCP サーバーはローカルで動作するため、データはお客様の AWS アカウント内に留まり、認証情報やポリシー、ドメインもすべてお客様が管理します。

MCP Apps による MCP プロトコルの拡張

標準的な MCP ツール呼び出しでは、レスポンスはテキストのみとなります。エージェントはツール名とパラメータを指定した JSON-RPC リクエストを送信し、サーバーからテキスト結果を受け取って推論に組み込みます。MCP Apps はこのパターンを拡張し、2 つ目の応答チャネルを追加します。これはビジュアルペイロードであり、IDE 上でテキストの隣にインタラクティブなウィジェットとして描画されます。

ローカル MCP サーバーがツール呼び出しを受け取ると、設定済みの AWS 認証情報を用いて認証を行い、そのリクエストを OpenSearch UI アプリケーションのエンドポイントへ HTTP API 呼び出しとして転送します。OpenSearch UI は接続されたデータソースに対してクエリを実行し、構造化されたテキストサマリーとレンダリングされた可視化アートを返します。サポートされているデータソースには、OpenSearch ドメイン、サーバーレスコレクション、Amazon Managed Service for Prometheus が含まれます。

MCP サーバーはこれらをパッケージ化し、エージェント用のテキストコンテンツと IDE ホストがレンダリングするための可視化コンテンツを含む単一の MCP 応答としてまとめます。

IDE ホストはこの可視化ペイロードを検知すると、会話スレッド内で対話型ウィジェットとして表示します。OpenSearch MCP App は、実際のデータに対してコードを実行することでサーバーサイドで可視化を生成するため、レンダリングされた出力は決定論的であり、OpenSearch ダッシュボードで確認できるものと一致します。

ツール呼び出しの全体像

この双応答パターンが実際にどう機能するかを示すため、トレース調査の例を考えてみましょう。以下の手順では、エージェントが trace investigation MCP App ツールを呼び出した際に何が起こるかを解説します。

エージェントからの送信内容。 エージェントは trace investigation MCP App に対してツール呼び出しを行い、trace ID やサービス名、時間範囲などのフィルタパラメータを渡します。この呼び出しは、標準的な MCP プロトコルを経由して IDE からローカル MCP サーバーへ送られます。

サーバーの実行プロセス

ローカル MCP サーバーがツール呼び出しを受け付け、AWS 認証を実行した上でリクエストを OpenSearch UI アプリケーションのエンドポイントへ転送します。OpenSearch UI は接続されたデータソースに対してトレースクエリを実行し、一致するスパンを取得してレスポンスを組み立てます。

デュアルレスポンスの内容

MCP サーバーは単一のレスポンス内で 2 つの出力を返します。テキスト部分は構造化されたサマリーを含み、トレース ID、総所要時間、スパン数、クリティカルパス、および障害発生源の分析が含まれます。ビジュアライゼーション部分は、IDE 内の MCP アプリとしてレンダリングされるインタラクティブなトレースウォーターフォールを含み、スパン階層、タイミング、エラー注釈を表示します。

エージェントと人間の利用方法

テキストサマリーから、エージェントは次の推論ステップのためのコンテキストを抽出します。例えば、失敗したスパンに関連するログエントリとの相関関係を確認するなどです。一方、人間は同じ会話スレッド内でインタラクティブなトレースウォーターフォールを目にできます。個別のスパンを展開したり属性を検索したりして、別ブラウザタブを開かずに視覚的に根本原因を確認できます。

利用可能な MCP アプリ

MCP アプリは調査ライフサイクル全体にわたる観測性調査をサポートし、各調査段階で連携するツールを提供します。

コア調査ツール

典型的な調査は、トリアージとレスポンスツールから始まります。これらのツールはアクティブなアラートを可視化し、データソース間で関連するアラートを相関付け、深刻度の内訳を表示して、エージェントが優先順位を決定できるように支援します。

エージェントが影響を受けたサービス特定すると、ログ調査ツールがエラーパターンを検索し、類似したログエントリをクラスタリングして障害のシグネチャを特定します。その後、トレース調査ツールが特定の分散トレースを見つけ、スパン階層とレイテンシーの内訳を表示し、障害が発生した場所をピンポイントで突き止めます。

コンテキストと可視化ツール

影響度を定量化するため、メトリクス調査ツールは PromQL クエリを実行して閾値分析を行い、サービスパフォーマンスツールはサービスレベルの RED メトリクス（レート、エラー数、継続時間）を提供します。トポロジーツールは、依存関係グラフとしてサービスマップを描画します。このグラフでは各エッジ間の呼び出し量とエラー率が示されるため、影響範囲を特定できます。

調査全体を通じて、動的可視化ツールが指定したクエリから折れ線グラフ、棒グラフ、面積図、メトリクスチャートを生成し、データセットと相関関係ツールはクロスシグナル結合やデータの要約をサポートします。

専門ツール

専門的なツールが、新たなニーズに応えています。AI やエージェントの可観測性ツールは、大規模言語モデル（LLM）の呼び出しを追跡し、独自に AI ワークフローを構築するチームのためにエージェントのトレースマップを描画します。スタックヘルスツールはクラスタの状態やシャード割り当てを報告します。インストルメンテーションスコアリングツールはテレメトリ品質のギャップを検出するため、チームは可観測性カバレッジを改善できます。

図 2: IDE 内でスパン階層、タイムライン、および障害発生源分析を表示する Trace Investigation MCP App

オンコールシナリオの再考

MCP Apps を用いると、同じオンコール調査は以下のような形になります。

エンジニアがエージェントに「チェックアウトエラーの急増の原因は何ですか？」と尋ねます。エージェントはログを照会し、トレースと相関付け、サービスマップを確認して調査を開始します。その結果、テキスト要約と対話型ビジュアライゼーション（アラートビュー、トレースウォーターフォール、サービスマップ）を含む二重のレスポンスが同じスレッド内で返されます。エンジニアは IDE を離れることなく、MCP App のビジュアライゼーションをスクロールしてインラインで確認し、スパンの詳細を選択して影響範囲を確認します。最後に、エージェントに問題サマリーのドラフト作成や修復処理のトリガーを指示します。

エンジニアは IDE を離れる必要はありません。調査、検証、解決のすべてを、単一の会話スレッド内で完結できます。オンコール担当者の場合、これにより解決までの時間が短縮され、AI エージェントとの協働がよりスムーズになります。

図 3: サービスマップ MCP アプリ。エラー率に応じた色分けと、呼び出し量に応じたエッジの太さで依存関係グラフを表示。

はじめに：MCP サーバーの設定

アジェンティック IDE を OpenSearch UI アプリケーションに接続するには、以下の手順に従ってください。

事前準備

作業を開始する前に、以下の環境が整っていることを確認してください。

• 少なくとも 1 つのデータソース（Amazon OpenSearch Service ドメイン、サーバーレスコレクション、または Amazon Managed Service for Prometheus）が接続された、Observability ワークスペースを備えた OpenSearch UI アプリケーション。
• 対応するアジェンティック IDE（Claude Desktop、VS Code GitHub Copilot、Goose、ChatGPT、または Cursor）。
• ローカル環境に Node.js 22 以降がインストールされていること。
• es:ESHttpGet および es:ESHttpPost の権限が付与された AWS クレデンシャルが設定されていること。

ステップバイステップの設定

以下の手順では、サーバーのダウンロード、IDE の設定、接続確認までを順を追って説明します。

ステップ 1：MCP サーバーのダウンロードと展開

MCP サーバーパッケージをダウンロードして準備してください。

OpenSearch 観測用 MCP サーバーのダウンロードページにアクセスしてください。

MCP サーバーの .zip ファイルをダウンロードします。

アーカイブを展開します。展開されたディレクトリには server/server.js というファイルが含まれています。このファイルへのフルパスを確認しておいてください。

手順 2: MCP サーバーを IDE に追加する

各対応 IDE には、MCP の設定ファイルが存在します。以下のリストにその場所を示します：

• Claude Desktop: [設定] → [開発者] → [構成の編集]
• VS Code GitHub Copilot: ワークスペース内の .vscode/mcp.json、または [ユーザー設定] → [MCP サーバー]
• Cursor: [設定] → [MCP] → [サーバーを追加]
• Goose: 拡張機能経由で ~/.config/goose/mcp.json

• ChatGPT: [設定] → [MCP プラグイン] → [追加]

IDE の設定を開き、以下を追加してください。

{
  "mcpServers": {
    "opensearch-observability-stack-mcp": {
      "command": "node",
      "args": ["/path/to/opensearch-observability-stack-mcp/server/server.js"],
      "env": {
        "OS_UI_ENDPOINT": "application-foo-bar.us-west-2.opensearch.amazonaws.com",
        "AWS_REGION": "us-west-2",
        "AWS_PROFILE": "my-profile"
      }
    }
  }
}

プレースホルダーの値を、OpenSearch UI エンドポイント、AWS リージョン、およびプロファイルに置き換えてください。

OpenSearch UI エンドポイントの確認方法:

• Amazon OpenSearch Service コンソールを開きます。
• ナビゲーションペインで [アプリケーション] を選択します。
• 対象の OpenSearch UI アプリケーションを選択します。
• アプリケーション URL (例: application-abc123.us-west-2.opensearch.amazonaws.com) をコピーします。

手順 3: 接続の確認

設定を保存後、IDE を再起動するか、MCP サーバーリストをリロードしてください。その後、IDE で以下のプロンプトを入力します:

*「利用可能な観測データソースの一覧を表示」*

エージェントが接続されたデータソース（Amazon OpenSearch Service ドメイン、サーバーレスコレクション、または Amazon Managed Service for Prometheus ワークスペース）を返す場合、MCP サーバーは正しく設定されています。

エラーが発生した場合は、AWS 認証情報が有効であることを確認し、AWS Identity and Access Management (IAM) ポリシーに、OpenSearch UI アプリケーションの ARN に対する es:ESHttpGet および es:ESHttpPost アクションが含まれているか確認してください。

ヒント: 本番データを使わずにテストするには、OpenTelemetry Demo アプリケーションをデプロイして、Amazon OpenSearch Service ドメイン内にサンプルのトレース、ログ、メトリクスを生成します。

クリーンアップ

MCP サーバー設定を削除するには、IDE の MCP 設定を開き、opensearch-observability-stack-mcp エントリを削除してください。その後、ローカルマシンから抽出された MCP サーバーディレクトリも削除します。このセットアップはクラウドリソースをプロビジョニングしないため、AWS 側でのクリーンアップ作業は不要です。

なぜこれが重要なのか

以下の表では、MCP Apps がオンコールワークフローにどう影響するかをまとめます：

結論

MCP Apps を活用することで、Amazon OpenSearch Service はアジェンティック・オプサービリティにおける「検証のギャップ」を埋めます。AI エージェントが調査を行い、対話形式で証明結果が同じスレッド内で即座に返ってくるため、コンテキストの切り替えや別ログイン、クエリの再実行は不要です。オンコール担当エンジニアにとっては解決までの時間が短縮され、ローカル環境でアジェンティック・オプサービリティを運用する組織にとっては、精度を損なうことなく、望んでいたような運用上の簡素化が実現します。

今日から始めましょう: 設定手順については、Amazon OpenSearch Service の開発者ガイドにある MCP Apps を活用したアジェンティック・オプサービリティ をご覧ください。

執筆者について

Arthur Hang Zuo

Amazon OpenSearch Service のシニアプロダクトマネージャー。OpenSearch UI プラットフォームとアジェンティック AI 機能のリーダーを務め、オプサービリティおよび検索ユースケースの実現を推進しています。アジェンティック AI やデータプロダクトに関するトピックにも興味を持っています。

Joshua Li

Amazon OpenSearch Service のシニアソフトウェアエンジニア。OpenSearch Dashboards や OpenSearch UI におけるオプサービリティ機能、UI 体験、およびアジェンティック AI との統合に注力しています。