AWS DevOps Agent を TrueWatch MCP Server に接続する（APM、ログ、トレース & RUM）

2026年9月21日

運用エージェントは、調査対象のシステムを実際に見ることができて初めて役に立つ。

AWS DevOps Agentは、クラウド運用タスクのための自然言語エントリポイントをチームに提供する。TrueWatch MCP Serverは、そのエージェントに対して、ログ、メトリクス、トレース、RUMデータ、ダッシュボード、モニター、関連する調査コンテキストといったオブザーバビリティデータをガバナンスの効いた方法でクエリする手段を与える。両者を組み合わせることで、エンジニアは「このエラー急増の前後で何が変わったか」といった本番環境の質問から始め、エージェントがプロンプトのコンテキストから推測するのではなく、スコープ化されたツールを通じて証拠を収集できるようになる。

このガイドでは、実践的な接続フローを解説する。これはパーミッションモデルではなく、統合パターンとして捉えてほしい。MCPが答えるのはインターフェースの問題、つまりエージェントが適切なオブザーバビリティツールを呼び出せるかどうかである。本番デプロイでは、依然としてワークスペーススコープ、最小権限のキー、読み取り専用のデフォルト、副作用を伴うアクションの承認、そしてツール呼び出しの監査記録が必要になる。

AWS DevOps Agentが加えるもの

AWS DevOps AgentはAWSが提供するAI運用アシスタントであり、ユーザーがクラウドリソースを扱い、問題をトラブルシューティングし、自然言語での対話を通じてインフラ関連の出力を生成できるよう設計されたAI DevOpsエージェントである。

オブザーバビリティ業務において重要なのは、チャットインターフェース自体ではない。価値が生まれるのは、エージェントを最新の本番シグナルに接続し、そのアクセスを境界づけて保つことによってである。この接続がなければ、エージェントは起こりうる障害パターンを説明することしかできない。スコープ化されたMCP接続があれば、現在のテレメトリを調査し、使用した証拠を提示できる。

TrueWatch MCP Serverが加えるもの

TrueWatchは、モダンな本番システムを運用するエンジニアのためのオブザーバビリティプラットフォームである。インフラ監視、アプリケーションパフォーマンス監視（APM）、ログ管理、分散トレース、RUM、ダッシュボード、アラート、クラウドリソースデータを、一つの共有された調査コンテキストにまとめる。

TrueWatch MCP Serverは、選定されたTrueWatchの機能をMCP対応クライアントに公開する。本記事では、AWS DevOps AgentがTrueWatch MCP Serverに接続し、以下のような読み取り指向のツール群を受け取る。

  • list_checkers
  • list_logging_query_rules
  • list_dashboards
  • query_log_data
  • query_metric_data
  • query_trace_data
  • query_rum_data

まずは読み取り専用ツールから始めること。本番システムを変更するワークフローへアクセスを拡張する前に、エージェントに証拠を取得させ、要約させ、次のステップを提案させる。

統合の流れ

統合フローは次の通りである。

AWS DevOps Agent -> MCP Server registration -> TrueWatch MCP Server -> TrueWatch observability data

AWSのUIは今後変わる可能性がある。しかし運用上の形はおおむね変わらないはずだ。MCPサーバーを登録し、エンドポイントと認証情報を追加し、そのサーバーをAgent Spaceに紐付け、許可するツールを選択し、読み取り専用の調査を実行して経路を検証する。

1. MCP Serverの登録エントリを開く

AWS DevOps Agentのコンソールを開く。機能メニューでSettingに進み、Registerを選択する。 登録ページには、GitLab、ServiceNow、Slack、MCP Serverなど、サードパーティ統合のエントリが並んでいる。TrueWatch MCP Serverの登録フローを開始するには、MCP Serverを選択する。

アソシエーションフローが正常に開始されると、ページには次のようなメッセージが表示されるはずだ。

AWS DevOps Agent MCP Server associated successfully

2. TrueWatch MCP Serverのエンドポイントを設定する

MCPサーバーの詳細ページで、基本設定を完了させる。

トランスポートプロトコルを確認する

MCPサーバーはStreamable HTTPトランスポートに対応している必要がある。エンドポイントを追加する前にこれを確認すること。

認可フローを選択する

Authorization configurationを開き、使用しているTrueWatch MCP Serverの構成に合った認可方式を選択する。

サーバーに名前を付ける

Nameには、次のような分かりやすい名前を付ける。

TrueWatch MCP Server

複数のワークスペースを運用している場合は、環境を示す名前を使うこと。例えば「TrueWatch MCP Server - Production Read Only」のように。

エンドポイントURLを追加する

Endpoint URLには、自分のワークスペース用のTrueWatch MCP Serverエンドポイントを追加する。

ターゲット形式の例:

https://toby-ai.truewatch.com/toby_ai_mcp/mcp

このガイドを公開・共有する前に、最新のTrueWatchドキュメントで最終的なエンドポイントを確認すること。このURLはAWS CloudTrailのログに記録される可能性もあるため、エンドポイント自体にシークレットを埋め込まないこと。

Descriptionの項目があれば、次のような簡潔な運用メモを追加する。

Read-only observability tools for production investigation.

Dynamic Client Registrationは、自社のセキュリティポリシーに合致する場合のみ有効にする。これを有効にすると、セットアップフロー中にDevOps AgentがMCP認可サーバーに登録できるようになる。

エンドポイントの設定が完了したらNextをクリックする。

3. APIキー認可を使用する

AWS DevOps Agentは、OAuth Client Credentials、OAuth 3LO、API Keyといった認可フローに対応している。元のセットアップでは、TrueWatch MCP ServerにAPI Key認可を使用している。

この方式はブラウザのリダイレクト手順を回避し、呼び出し元アプリケーションに直接的な認証経路を提供する。本番環境では、このエージェント接続専用のキーを使用し、必要最小限のデータとツールにスコープを絞ること。

ヘッダーを設定する

固定のヘッダー名を次のように設定する。

Authorization

APIキーの値を設定する

TrueWatch MCP Serverのドキュメントで定義されているAPIキーとサイトキーの形式を使用する。元のセットアップでは、次のように結合した値を使用している。

<TRUEWATCH_API_KEY>-<SITE_KEY>

ここで:

  • <TRUEWATCH_API_KEY>は、TrueWatchワークスペースで作成したAPIキーである。
  • <SITE_KEY>は、TrueWatchのデプロイ先リージョンまたはサイトを識別する。

APIキーを作成・確認する

TrueWatchコンソールでSystem Settingsを開き、API Keysに進む。この統合用のキーを新規作成するか、既存のキーを確認する。

運用エージェントにとって、より安全な出発点は次の通りである。

  • 読み取り専用アクセス
  • ワークスペースにスコープされた権限
  • 広範な管理者ロールを付与しない
  • 開発・ステージング・本番で別々のキーを使用する
  • ローテーションポリシーと所有者情報を明確にする

サイトキーをマッピングする

TrueWatchのデプロイ先リージョンは、異なるOpenAPIエンドポイントに対応している。本番利用前に、有効なマッピングを確認すること。英語版のブログでは、内部のデプロイ詳細を公開せずにパターンだけを示すことができる。

const SITE_KEY_MAP = {  us1: 'https://us1-openapi.truewatch.com',  eu1: 'https://eu1-openapi.truewatch.com',  ap1: 'https://ap1-openapi.truewatch.com',};

設定を確認した後、以前の設定を見直したい場合はPreviousをクリックする。その後Nextをクリックして送信する。設定が成功すると、MCPサーバーのアソシエーションメッセージが表示されるはずだ。

4. MCPサーバーをAgent Spaceに紐付ける

AWS DevOps Agentのメインページに戻り、Agent Spacesを開く。

Agent Spacesは、DevOps Agentのアクセス範囲、機能の境界、運用スコープを制御する。チーム、環境、リスクレベルを分離すべき場合は、別々のスペースを使用すること。

対象のAgent Spaceを開き、View detailsをクリックしてからMCP Serverを探す。

5. MCPツールを追加し、設定を保存する

MCPサーバーのツールページで、AWS DevOps Agentが呼び出せるツールを選択する。

元のセットアップでは、TrueWatchのMCPツールを7つ追加している。

  • list_checkers
  • list_logging_query_rules
  • list_dashboards
  • query_log_data
  • query_metric_data
  • query_trace_data
  • query_rum_data

デフォルトですべてのツールをエージェントに与えないこと。本番システムに対しては、データを読み取るだけのツールから始める。別途承認経路が用意されている場合を除き、本番環境の挙動を変更、削除、書き込み、ロールバック、スケーリング、サイレンス化するツールは避けること。

許可するツールを選択したらSaveをクリックする。

6. 読み取り専用の調査を開始する

MCP Serverとツールの権限設定が完了したら、Agent Spaceの詳細ページを開き、Operator accessを選択する。

このエリアには、トポロジー、機能、Webアプリケーションアクセスといった運用ビューが含まれる。最初のテストでは、タスクの範囲を狭く、読み取り専用に保つこと。

Start investigationをクリックする。Investigation starting pointに、具体的な調査リクエストを入力する。最初のテストとして良い例は次の通りだ。

Analyze error logs from the last 15 minutes and group them by service and error type.

あるいは:

Find services with recent trace errors and summarize the evidence behind each finding.

プロンプトでは、エージェントにどの証拠を取得させ、どのように要約させるかを伝える必要がある。

ページにFetching dataやInvestigatingといったステータスが表示され、出力にMCPツールからの結果が含まれていれば、接続経路は正しく機能している。

デモ: 過去15分間のエラーログを分析する

元のデモでは、次のようなシンプルなリクエストを使用している。

Analyze error logs from the last 15 minutes.

AWS DevOps Agentはこのリクエストを解釈し、調査計画を作成し、TrueWatch MCPツールを呼び出し、返されたデータを要約する。

元のフローでは、エージェントは次のことを行った。

  • 直近のエラーデータをクエリした
  • エラーを種類別にグループ化した
  • 影響を受けたサービスを特定した
  • 生のログサンプルを含めた
  • 主要な調査結果を要約した

3つのサービス、3つの異なる障害モード — これが実際のマイクロサービス監視の姿である。エラーは特定のサービスと時間帯に紐づいており、一つの汎用的なインシデントにまとめられることはない。

結果の形の例

デモの時間帯において、調査では3つのカテゴリのエラーが特定された。

設定が見つからない

  • エラータイプ: forethought.utils.exceptions.APIException
  • エラーコード: ftLogackupCfgNoExists
  • サービス: inner-api
  • 説明: データ転送設定が見つからなかった

クエリタイムアウト

  • エラータイプ: errors.errorString
  • サービス: kodo-inner
  • 説明: クエリタイムアウトによる内部サーバーエラー

不明なAPIエラー

  • エラータイプ: forethought.utils.exceptions.APIException
  • エラーコード: ft.CloudCareApiError
  • サービス: front-api
  • 説明: 不明なAPIエラー

重要なのは、エージェントが段落を生成したことではない。重要なのは、その回答をツール呼び出し、時間帯、サービス、ログサンプル、クエリ結果にまで遡って追跡できることである。

よくある質問

Q: AWS DevOps AgentにTrueWatchデータへの書き込みアクセスを与えるべきか？ A: いいえ、少なくとも最初は与えるべきではない。まずは読み取り専用ツールのみから始める。本番環境の挙動を変更、削除、ロールバックするツールへの拡張は、人間による承認経路を別途用意した後にのみ行うこと。

Q: この統合のためにAPIキーを設定する最も安全な方法は？ A: このエージェント接続専用のキーを使用し、共有キーや管理者権限のキーは使わないこと。ベストプラクティスは、ワークスペースにスコープされた権限、広範な管理者ロールを与えないこと、環境ごと（開発・ステージング・本番）に別々のキーを使うこと、そして担当者を明示したローテーションポリシーを設けることである。

Q: この統合が本番環境で実際に安全に稼働するかどうか、どう判断すればよいか？ A: 最初の調査の後、次の3点を確認すること。データスコープ（エージェントは意図したワークスペース・環境・時間範囲のみをクエリしたか）、ツールスコープ（有効化したすべてのツールが実際に使用されたか — 使われなかったものは削除する）、そして証拠の質（エンジニアは回答を特定のサービス、時間帯、エラータイプ、クエリ経路まで遡って追跡できるか）。

Q: TrueWatch MCP ServerとToby AI Agentsの違いは何か？ A: MCP Serverはインターフェース層であり、AIクライアントがTrueWatchのオブザーバビリティツールを呼び出せるようにするものである。Toby AI Agentsは、その上に構築された完全な運用モデルであり、トラブルシューティングの方法論、権限境界、証拠の追跡、承認フロー、ロールベースの振る舞い、事後検証を含む。MCPが答えるのは「エージェントはデータを見ることができるか」であり、Toby AI Agentsが答えるのは「エージェントは行動すべきか、それをどう統治するか」である。それこそが、本番運用に耐えるAIエージェントのオブザーバビリティに実際に求められるものだ。

Q: この構成で避けるべきことは何か？ A: デフォルトで利用可能なすべてのツールをエージェントに与えないこと。エンドポイントURLにシークレットを埋め込まないこと（AWS CloudTrailのログに表示される可能性がある）。本番環境の状態を変更するアクションについて、人間による承認を省略しないこと。最初のテストを本番のAgent Spaceで実行しないこと — まずは非本番のワークスペースを使うこと。

Get in touch background

Toby AI Agents

TrueWatchで、オブザーバビリティのその先へ。今すぐ始めましょう。