やりたかったこと
AzureとNew Relicを使ってシステム監視をしていると、こんな課題があります。
- 監視データの確認のために毎回New Relicのダッシュボードを開いてNRQLを手書きするのが面倒
- アラートが飛んできたとき、原因調査に複数のツールを行き来する必要がある
- 「あのサーバーのCPU使ってどれくらい？」程度の質問に、わざわざコンソールにログインしたくない
- チームメンバーがTeamsやSlackで「〇〇サーバー大丈夫？」と聞いてきたとき、すぐ答えたい
→ そこで、チャットで聞いたら監視データを調べて答えてくれるBot、作れないかな？と思いました
本記事ではオブザーバビリティ（o11y）ツールとして New Relic を例に紹介していますが、Datadog・Grafana・Splunk・Dynatraceなど、MCP サーバーを提供している（または自作できる）o11y ツールであれば同様のアプローチが可能です。ご自身の環境に合わせて読み替えてください。
やれたこと
- Teams / Slack から自然言語で質問すると、AI が監視データを自動で取得・分析して回答してくれるBotを作りました
- MCP（Model Context Protocol）を使って、New RelicとAzureの監視データにAIからアクセスできるようにしました
- 3段階にわたって改良を重ね、最終的にはアラートの根本原因分析（RCA）まで自動でやってくれるようになりました
NewRelic含む多くのo11yツールにもAIでの根本原因分析機能がありますが、大抵はとてもライセンス費用が高価です。その割にo11y内の情報をもとに解析するだけなので、AzureやAWSなどの構成情報をとれません。これをうまく中継させて、o11yツールのAI機能を使用せずに原因分析ができたらなと思いました。
そもそもMCPって何？
MCP（Model Context Protocol） は、AIモデルが外部のツールやデータソースに接続するための標準プロトコルです。Anthropicが提唱し、今やOpenAIやMicrosoftも対応しています。
ざっくり言うと：
- AI（LLM）は「考える」のは得意ですが、「外の世界のデータを取りに行く」のは苦手です
- MCPは、AIが外部ツールを呼び出すための 共通の接続規格 です
- New RelicやAzureなど、各サービスがMCPサーバーを提供していれば、AIから統一的にアクセスできます
USBケーブルやBlueToothのような規格の一種で、MCPに対応していれば何でも繋がると想像するとわかりやすいです。USBケーブルやBlueToothを使って、お気に入りのキーボードからモニタ、スマホやスマートスピーカーに接続できますよね。それと同じでMCPを通してAIはNewRelicやAzure内の情報を取得できます。
MCPの通信の仕組み
MCPは JSON-RPC 2.0 ベースのプロトコルです。JSON-RPC 2.0はJSON形式でRPC通信をすることができます。通信の流れは以下のようになっています。
実際のコードでの、MCPセッションの初期化はこんな感じです。プロトコルのバージョンやクライアントの情報を与えてるぐらいです。
async initialize() {
// JSON-RPC 2.0 で初期化リクエストを送信
await this._post({
jsonrpc: '2.0',
id: ++this._reqId,
method: 'initialize',
params: {
protocolVersion: '2025-03-26',
capabilities: {},
clientInfo: { name: 'monitoring-bot', version: '2.0.0' }
}
});
// サーバーに準備完了を通知
this._post({ jsonrpc: '2.0', method: 'notifications/initialized' }).catch(() => {});
this._initialized = true;
}
ツールの呼び出しもかなりシンプルです。このarguments要素の中に引数が入ります。
async callTool(name, args = {}) {
await this._ensureInitialized();
return this._post({
jsonrpc: '2.0',
id: ++this._reqId,
method: 'tools/call',
params: { name, arguments: args }
});
}
MCPサーバーとの通信には 2つのトランスポート があります。
| トランスポート | 接続方式 | 用途 | たとえ |
|---|---|---|---|
| Streamable HTTP | HTTPS経由でJSON-RPCをやりとり | New Relic MCPなどのSaaSホスト型 | 電話をかける（相手はクラウド上にいる） |
| stdio | 子プロセスのstdin/stdoutで通信 | Azure MCPなどのローカル実行型 | 隣の席の人に直接話しかける（同じマシン内） |
使い分けの基準は「MCPサーバーがどこで動くか」 です。
-
Streamable HTTP は、サービス提供者がクラウド上でMCPサーバーをホスティングしている場合に使います。New Relicのように、SaaS側が
https://mcp.newrelic.comというエンドポイントを公開しており、利用者はAPIキーを渡してHTTPSでアクセスするだけです。サーバーの起動や管理は不要で、手軽に使えます。 -
stdio は、MCPサーバーをアプリケーション自身が子プロセスとして起動する場合に使います。Azure MCPサーバー（
@azure/mcp）はnpmパッケージとして配布されており、BotがNode.jsの子プロセスとして起動し、stdin/stdoutで通信します。認証にサービスプリンシパルやManaged Identityを使うため、自分のマシン上で動かす必要があります。
このBotでは両方を併用しており、MCPのプロトコル自体は同じJSON-RPC 2.0なので、トランスポートが違っても呼び出し方のコードはほぼ共通です。
stdioは今回検証を簡略化するために使用しました。実際の運用環境で使用するにはプロセスを常時実行する独立した環境として、MCPサーバーを別に立てておくことをお勧めします。
なぜMCPを活用するのか
「New RelicのAPIを直接叩けばいいのでは？」と思われるかもしれません。ここで、MCPを使う理由を私の観点で述べておきます。
1. AIとの統合が圧倒的に楽
New Relic APIを直接使う場合、NRQL構文を自分で組み立て、APIのエンドポイントや認証方式を管理し、レスポンスのJSON構造をパースするコードを書く必要があります。
MCPなら、AIが tools/list で「何ができるか」を取得し、tools/call で実行するだけです。勝手にAIがやり取りをしてくれるので、APIの詳細を意識する必要がありません。
2. 複数サービスを統一的に扱える
このBotはNew RelicとAzureの2つのMCPサーバーに接続しています。MCPが統一規格だからこそ、同じ仕組みで両方にアクセスでき、サービスを横断した調査（New Relicでアラートを検知 → Azureでリソース構成を確認）が可能になっています。
3. サービス側がツールを最適化してくれる
New Relic MCPサーバーは、New Relic自身が提供しています。つまり、APIの最適な使い方やツールの粒度は サービス提供者が設計 してくれています。自分でAPIラッパーを書くより品質が高いですし、メンテナンスもNew Relic側がやってくれます。
Botを利用することのメリット・デメリット
ここからは少し趣向を変えてBotの話をしていきましょう。そもそも、システム監視にBotを利用することでどんなメリットがあるのかについて説明していきます。
メリット
| メリット | 詳細 |
|---|---|
| 問い合わせのハードルが下がる | NRQLを書けなくても「あのサーバーのCPU見て」で済みます |
| 既存のチャットツールに統合 | TeamsやSlackなど、普段使いのツールから離れずに監視データにアクセスできます |
| 属人化の解消 | 監視ツールに詳しくないメンバーでも同じレベルの情報を得られます |
| 調査の高速化 | AIが複数のツールを自動で順番に呼び出して分析するため、手作業よりはるかに速いです |
| ナレッジの集約 | NRQLテンプレートや調査手順をシステムプロンプトに組み込むことで、ベストプラクティスが標準化されます |
デメリット
| デメリット | 詳細 |
|---|---|
| LLMのコスト | Azure OpenAI Serviceの利用料が発生します。ReActループで複数回呼び出すため、1回の質問でそれなりにトークンを消費します |
| レスポンス遅延 | LLMの推論 → MCP呼び出し → 結果の要約 のサイクルを複数回繰り返すため、即座には回答が返りません（数十秒～1分程度） |
| 精度の限界 | LLMが生成するNRQLが不正確だったり、ツール選択を誤ることがあります。完全な自動化ではなく、結果の妥当性は人間の確認が必要です |
| セキュリティ上の考慮 | APIキーやシークレットの管理が必要です。MCPサーバーへのアクセス権限の設計が重要になります |
| 依存サービスの増加 | Azure OpenAI、New Relic MCP、Azure MCPと依存先が増え、どれか一つが落ちると影響を受けます |
全体構成
作ったBotの全体像は以下の通りです。
| 通信 | 内容 |
|---|---|
| ① App Service → Azure OpenAI | ツール自動選択・引数生成・結果要約（Function Calling） |
| ② App Service → Azure MCP | Azureリソース情報取得（stdioトランスポート、サービスプリンシパル認証） |
| ③ App Service → New Relic MCP | 監視データ取得（HTTPトランスポート、API Key認証） |
AzureOpenAIの選定理由は、「チャットの内容を学習データに使用されない」、「Azureでの操作に慣れていると設定が楽」、「Azureのアカウントがあれば新規でアカウント発行は不要」という３点です。
今回の構成のポイントは、Azure OpenAIとMCPサーバーは直接つながっていないということです。Azure OpenAIは「execute_nrql_query をこの引数で呼べ」という判断だけを返す司令塔で、実際にMCPサーバーへ通信してツールを実行するのはApp Service上のBot（MCPクライアント）です。Azure OpenAIがNew RelicやAzureのAPIに直接アクセスすることはありません。
つまり、App Serviceが全通信の中継点であり、Azure OpenAIへの問い合わせもMCPサーバーとのセッション管理もすべてBotが担っています。Botの責任重大ですね。
使用技術
以下が上記構成での仕様技術になります。こうやって並べると多く見えますが、Node.jsとApp Service以外は私も正直初めて触るものばかりでした。それでもAIとペアプロしたり、調べたりしながら進めることができたのであまり身構えないでください。
| 技術 | 用途 |
|---|---|
| Node.js | Bot アプリケーションランタイム |
| Bot Framework SDK v4 | Teams/Slack メッセージ処理 |
| Azure OpenAI Service | 自然言語理解・ツール自動選択 (Function Calling) |
| MCP (Model Context Protocol) | AI ↔ 外部ツール接続の標準プロトコル |
| New Relic MCP Server | 監視データ取得（SaaSホスト型） |
| Azure MCP Server (@azure/mcp) | Azureリソース情報取得（stdioローカル実行型） |
| Azure App Service (Linux) | Botアプリケーションのホスティング |
| Azure Bot Service | Teams/Slackチャネルルーティング |
後編へ続く
後編では、実際の実装と3段階にわたる改良の詳細を紹介します。
- 第1世代（ツール直接呼び出し型）: NRQLを手で書いてBotに投げる方式
- 第2世代（AI Agent化）: LLMが自動でツール選択する方式
- 第3世代（RCA対応）: アラート原因を自動で根本原因分析（RCA）してくれるように進化
いつも、すぐに飽きて後編を書く気力が尽きてしまいます。皆さんの熱いコメントといいねで私にやる気をください<(_ _)>