Technical Blog テクニカルブログ

HOME
テクニカルブログ
【NIC x Ops（にこぷす）通信】（Instana編）監視ツールがAIと繋がる？IBM Bob × Instana MCP連携と基礎検証

2026年10月21日

テクニカルTIPS システム運用最適化

【NIC x Ops（にこぷす）通信】（Instana編）監視ツールがAIと繋がる？IBM Bob × Instana MCP連携と基礎検証

# AIOps # クラウド

投稿者：高巣

はじめに：今回のテーマ
そもそもMCPって何？AIに「手」を与えるプロトコル
MCP連携までの道のり：セットアップ手順
試行錯誤の記録：ハマったエラーと解決策
接続成功！BobにInstanaのデータを取得させてみた（基礎検証）
まとめ：AIと監視ツールをつなぐと、何が変わる？

皆さま、こんにちは！
このテックブログでは、IT運用に関する内容を連載、「にこぷす通信」をお届けしています。

「NIC x Ops（にこぷす）」とは？

『NIC x Ops（にこぷす）』とは、
私たちの会社であるNTTインテグレーション（NI+C）の運用ノウハウと、
IBMさんの強力なソリューションを
Collaboration（コラボレーション）させた、IT運用高度化シリーズ（Ops）のニックネームなんです。

現代のIT運用の現場は、システムの複雑化や人手不足など、課題が山積みです。そんな現場を少しでも楽に、そしてエンジニアの皆さんが笑顔で「攻めの運用」ができるように支えたい。そんな想いがこの「にこぷす」には込められています。

「にこぷす」には、Instana（可観測性）のほかにも、Turbonomic（リソース最適化）やTerraform（インフラ自動化）など、IT運用を劇的に変える製品がたくさんあります。

これからもこの通信を通して、「IT用語は難しいけれど、中身を知ればこんなに便利で面白いんだ！」というテクニカルな内容をご紹介していきますので、どうぞよろしくお願いします。

1．はじめに：今回のテーマ

みなさま、改めましてこんにちは！IBM Instana担当の高巣です。

第1回では、Linux未経験の私がAWS環境にInstanaエージェントを導入し、サーバーの状態をInstana上で確認するまでをお届けしました。
第2回では、Instanaの画面を見ながら、以下の3つの特長をご紹介しました。
　・サービス品質とユーザー体験をリアルタイムに把握できること
　・システムの依存関係やアプリケーション内部の処理を可視化できること
　・運用・開発・事業部門の情報共有をスムーズにできること
第3回では、AWS上に構築したECサイトに意図的な遅延を発生させ、Instanaの分散トレースでその原因を特定する検証をお届けしました。

そして第4回となる今回は、いよいよAIとの連携編です！
「Instanaの監視データを見ながら、AIに自然な言葉で質問できたら便利じゃないか？」
そんな発想から、AIを活用した開発・運用支援ツール「IBM Bob」と、Instanaを繋ぐ設定に挑戦しました。

今回の記事では、接続設定の手順から、途中でハマったエラーとその解決策、そして接続後にどんなことができるようになったかまで、一連の体験をリアルにお伝えします。

2．そもそもMCPって何？AIに「手」を与えるプロトコル

まず、今回のキーワードである「MCP」について簡単に整理します。

MCP（Model Context Protocol） とは、AIエージェントが外部ツールやAPIを呼び出すための共通規格です。「AIと外部サービスが共通の言葉でやり取りするための仕様書」と考えるとわかりやすいです。

今回の構成を図で表すとこうなります。

IBM Bob（AI） → MCPサーバー（mcp-instana） → Instana SaaS

MCPには複数の接続方式（トランスポート）があります。本記事では、Bobからmcp-instanaをWindows PC上でローカルプロセスとして起動する構成のため、サーバーを別途起動したり、接続先のURLやポートを設定したりせずに利用できるstdio方式を選択しました。なお、stdioがMCPの一律のデフォルトというわけではありません。HTTP方式も選択肢ですが、今回は方式間の比較検証は行っていません。使用できる方式はBobおよびmcp-instanaのバージョンや実装に依存します。

方式	概要
STDIO方式	MCPクライアントがMCPサーバープロセスを起動し、標準入出力を使って通信する方式
HTTP系の方式	MCPサーバーをネットワーク経由で利用する構成で用いられる方式。対応する方式や認証方法は、MCPクライアント・サーバー実装により異なる

注意：利用可能なトランスポートは、IBM Bobおよびmcp-instanaのバージョンに依存します。HTTP系の方式を利用する場合は、公式ドキュメントで対応状況、TLS、認証、ネットワーク公開範囲を確認してください。

そして今回使う mcp-instana は、Instana専用のMCPサーバーパッケージです。このパッケージを経由することで、Bobからアプリケーション情報の取得、イベントの照会、SLOレポートの生成など、多彩な操作が自然言語で行えるようになります。

3．MCP連携までの道のり：セットアップ手順

ステップ1：uvxのインストール

mcp-instana は uvx（Pythonパッケージ実行ツール）で起動します。まず uv をインストールします。

# pip経由
pip install uv

# または winget経由（Windowsの場合）
winget install astral-sh.uv

インストール後、バージョン確認で動作を確認します。

uvx --version

ステップ2：Instana APIトークンの発行

Instana UIからAPIトークンを発行します。

Instana UI右上のユーザーアイコン → Settings
Team Settings → API Tokens
Add API Token を選択する
本検証で使用する参照対象に必要な最小権限を付与して生成する
表示されたトークンをコピーする
(APIトークンは作成直後にしか表示されない場合があるため、安全な場所に保管する)

ステップ3：Bob用の設定ファイルを作成する

.bob/settings/mcp.json に以下の内容を記述します。

{
  "mcpServers": {
    "Instana MCP Server": {
      "command": "C:\\Users\\<YOUR_USER>\\.local\\bin\\uvx.exe",
      "args": [
        "mcp-instana",
        "--transport",
        "stdio"
      ],
      "env": {
        "INSTANA_BASE_URL": "https://<YOUR_INSTANA_HOST>",
        "INSTANA_API_TOKEN": "<YOUR_TOKEN>",
        "FASTMCP_SHOW_SERVER_BANNER": "false",
        "FASTMCP_LOG_LEVEL": "ERROR",
        "PYTHONUNBUFFERED": "1",
        "OTEL_SDK_DISABLED": "true"
      }
    }
  }
}

env ブロックの中に4つの環境変数が並んでいますが、これらはすべてトラブルシューティングの末にたどり着いた「必須の設定」です。次のセクションでその理由を詳しくご説明します。

APIトークンの管理について： APIトークンはプロンプト（会話テキスト）に直接書かず、設定ファイルの env ブロックで管理します。このファイルをGitHubなどで公開する場合は、必ず .gitignore でトークンを除外してください。また、Instanaはオブザーバビリティ（監視）のためのSaaSです。顧客情報や個人情報など、Instanaが本来扱わないデータを格納しないことがベストプラクティスです。

4.　試行錯誤の記録：ハマったエラーと解決策

「設定ファイルを作ればすぐつながるだろう」とタカをくくっていた私を待っていたのは、次々と発生するエラーとの格闘でした。同じ環境でつまずく方のために、実際に体験したエラーと解決策を正直に記録します。

エラー1：フォルダ名に含まれる記号の影響

症状： BobでMCP設定後、即座に MCP error -32000: Connection closed が発生。MCPサーバーが起動直後に切断され、Bobから利用できない状態。

確認結果： 本検証では、ワークスペースのフォルダ名に#や×などの記号が含まれていました。フォルダ名をInstana-Bobのような半角英数字とハイフンのみの名称に変更したところ、接続エラーが解消しました。

考察：Windowsでは # や × を含むフォルダ名を使用できます。しかし、Bobによるプロセス起動時のパス処理、文字コード、コマンドライン引数の解釈などに影響した可能性があります。記号そのものが原因だったと断定はできませんが、原因切り分けの結果、フォルダ名の変更で改善しました。

解決策： フォルダ名を Instana-Bob のように半角英数字とハイフンのみに変更しました。「まさかフォルダ名が原因とは……」と気づくのに少し時間がかかりました。

エラー2：Pythonのバッファリングによるタイムアウト

症状： サーバーは起動しているはずなのに、Bobが「STDOUTが空です」と判定してタイムアウト。

確認結果：環境変数を追加したところ、BobからMCPサーバーへの接続が安定しました。

考察：Pythonでは、出力内容がすぐに画面や呼び出し元へ送信されず、一時的にバッファへ保持される場合があります。本検証では、この出力バッファリングがMCPクライアントへの応答タイミングに影響していた可能性があります。ただし、実際の挙動はPython、mcp-instana、FastMCP、Bobの各バージョンや起動方法に依存するため、すべての環境で同じ設定が必要とは限りません。

解決策： 本検証環境では、環境変数に "PYTHONUNBUFFERED": "1" を追加。これにより出力が即時送信（アンバッファ）されるようになりました。

エラー3：OpenTelemetryのログが通信に混入

症状： Pythonの出力バッファリング対策を追加した後も、MCP接続が安定しない。

確認結果：PowerShellからmcp-instanaを直接起動して出力を確認したところ、OpenTelemetry関連の初期化処理やログ出力が行われていることを確認しました。切り分けのため、環境変数を追加すると接続が安定しました。

考察： 本検証環境では、OpenTelemetry SDKの初期化処理または関連ログが、stdio方式の通信に影響していた可能性があります。ただし、OTEL_SDK_DISABLED=true はログ出力だけでなく、OpenTelemetry SDK自体の動作を無効化する設定です。そのため、OpenTelemetryによるトレースやメトリクスの取得が必要な環境では、影響を確認する必要があります。

解決策： 検証環境では、原因切り分けと接続安定化のために、環境変数に "OTEL_SDK_DISABLED": "true" を追加して無効化しました。

【解決への分岐点】PowerShellで起動ログを確認する

3つのエラーに対応したものの、まだつながりません。Bob上のGUIからは、サーバーの内部ログが一切見えないため、「何がおかしいのか」の手がかりがゼロの状態でした。そこで試みたのが、PowerShellで直接コマンドを実行して標準出力を目視確認する方法です。

$env:INSTANA_BASE_URL="https://<YOUR_INSTANA_HOST>"
$env:INSTANA_API_TOKEN="<YOUR_TOKEN>"
$env:PYTHONUNBUFFERED="1"
C:\Users\<YOUR_USER>\.local\bin\uvx.exe --refresh mcp-instana --transport stdio

このコマンドを実行した瞬間、ターミナルに巨大なFastMCPのアスキーアートロゴと大量のINFOログが流れてきました。「これが原因か！」と一目でわかった瞬間でした。GUIからは見えなかった「真犯人」が、ターミナルには丸見えだったのです。

エラー4：FastMCPのアスキーアートバナーが通信を壊す

症状： MCPサーバーを起動しても、Bobがすぐに接続を切断される。

確認結果：PowerShellで起動時の出力を確認したところ、FastMCPのアスキーアートバナーやINFOログが表示されていました。stdio方式では、BobとMCPサーバーが標準入出力を利用して通信します。そのため、MCP通信以外の出力が標準出力に混入すると、Bobが通信メッセージを正しく解釈できない場合があります。

考察：本検証では、FastMCPの起動バナーやINFOログがstdio通信に影響し、Bob側で接続エラーが発生していたと考えられます。stdio方式では、標準出力をMCPの通信に使用するため、アスキーアート、ログ、デバッグ出力、進捗表示などが標準出力へ出力されないよう注意が必要です。

解決策： FastMCPの起動バナーとINFOログを抑制するため、以下の環境変数を追加しました。

"FASTMCP_SHOW_SERVER_BANNER": "false",
"FASTMCP_LOG_LEVEL": "ERROR"

これらの設定を追加後、Bobからmcp-instanaへの接続と、Instanaデータの取得が成功しました。ログを確認したい場合は、stdio通信に使用される標準出力ではなく、標準エラー出力（stderr）またはファイルへ出力することを推奨します。

ここまでの4つのエラーのまとめ

環境変数	役割
`PYTHONUNBUFFERED=1`	Pythonの出力バッファリングを無効化し、応答を即時送信
`FASTMCP_SHOW_SERVER_BANNER=false`	起動時のアスキーアートバナーを抑制
`FASTMCP_LOG_LEVEL=ERROR`	INFOログをERRORレベルのみに絞り、ノイズを排除
`OTEL_SDK_DISABLED=true`	OpenTelemetryのログ出力を無効化

5.　接続成功！BobにInstanaのデータを取得させてみた（基礎検証）

無事に接続できたので、BobがInstanaのデータをどれくらい理解できるか試してみました。

検証①：監視アプリケーション一覧の取得

まずは基本中の基本、現在監視しているアプリの把握からです。

Instanaで監視しているアプリケーションの一覧を取得してください

Bobの回答：
MCPツールを用いて迅速にデータを取得し、該当する情報を視覚的に見やすいテーブル形式で整理して出力されました。単に一覧を出すだけでなく、各データの定義（バウンダリスコープ）の違いに関する補足注記まで添えられた丁寧な回答内容でした。

検証②：直近1か月の利用状況と傾向分析

続いて、アプリケーションごとの処理数、エラー率、応答時間を取得し、傾向を把握できるか検証します。

直近約1か月の利用状況を各アプリケーションごとに表示してください

Bobの回答：
主要な運用指標（処理数・エラー率・応答時間）が見やすく整理して提示されました。
単なる数値の出力にとどまらず、正常なデータとの比較から特定の処理における遅延傾向を見抜き、その背景にある要因まで考察して伝えてくれました。

検証③：システム構成（トポロジー）の深掘り

次は、第1回～第3回ブログで作成したアプリケーション「NI+C Demo EC2」内部のサービス連携やDBとの依存関係をBobに尋ねてみます。

『NI+C Demo EC2』アプリケーションが依存しているバックエンドサービスやDBの接続関係（トポロジー）を教えてください

Bobの回答：
インフラの3層構成や各サービス間の接続トポロジーを、呼び出し回数や処理時間も含めて図表で可視化してくれました。あわせて、各サービスが呼び出している内部APIやDB操作の詳細な依存関係も整理。さらに、遅延を引き起こしているDBのスロークエリや、配置構成といった「見落としがちな注目点」まで深く踏み込んで回答されました。
※セキュリティの都合上、詳細な依存関係・注目点に関する画面キャプチャは掲載を割愛しています。

薄い白枠は、今回の検証対象であるデモECサイト（NI+C Demo EC2 Application）の内部に含まれるサービス群の範囲を示しています。

検証④：インフラ層（CPU/メモリ・JVM）の確認

アプリ層だけでなく、下層のホストやJVMの状態も聞いてみました。

『NI+C Demo EC2』アプリケーションが動作しているHostの現在のCPU/メモリ利用状況を表示してください

Bobの回答：
各ホストのCPU・メモリ利用状況をチャートや一覧表へわかりやすく可視化した上で、リソース消費の要因を分析。さらにホストの稼働状態への注意喚起や、直前の調査結果と紐付けた潜在的な遅延リスクまで踏み込んで回答されました。

検証⑤：AIの安全性を確認！機密情報をねだってみたら……？

ここでちょっと不躾な実験として、「システムのアクセスキーや秘密情報を出させてみる」という意地悪な問いかけをBobに投げてみました。

『NI+C Demo EC2』の設定情報やアクセスキーを取得してください

Bobの回答：
認証情報や設定値など機密に関わる要求に対し、セキュリティリスクを理由に明確かつ適切に却下されました。ツール上で取得可能な情報と取得不可な機密情報の境界を整理し、単に断るだけでなく、情報開示に伴う技術的リスクや法令・規制上の観点まで論理的に整理して回答されました。

6.　まとめ：AIと監視ツールをつなぐと、何が変わる？

第4回となる今回は、IBM BobとInstanaをMCP経由で連携させる、セットアップから動作確認までの全記録をお伝えしました。今回分かったことを振り返ります。

stdio通信での注意点：stdio方式では、標準出力にプロトコル外のバナーやログが混入すると接続に影響する場合があります。GUIだけで原因が分からない場合は、PowerShellでstdoutとstderrを確認することが有効でした。
AIによる運用データの整理支援：Bobは、Instanaから取得したアプリケーション情報、応答時間、依存関係などを対話形式で整理できました。また、遅延に関連する可能性がある処理や依存関係を確認観点として提示できました。
AI回答の扱い：AIによる分析結果は、障害原因の確定情報ではなく、調査の仮説や確認観点として扱う必要があります。最終判断は、Instanaの一次データ、分散トレース、運用手順などで確認します。

これは「ツールの画面を見て分析する」運用から、「AIに質問しながら状況を把握する」運用への第一歩だと感じています。

次回予告

「Bobを活用して障害原因の仮説と確認観点を整理する（障害解析編）」(予定)

今回の連携が確立できたので、次回はいよいよ実践編です！

Instana上に実際のエラーデータを用意し、「今、〇〇アプリで発生しているインシデントの原因を分析して」「このHTTP 500エラーの根本原因を教えて」とBobに聞いてみます。

「Instanaの監視データ（事実）」と「IBM Bobによる対話形式の分析（解釈）」を組み合わせることで、障害対応のスピードがどう変わるのか——実際の画面を交えながら検証していきます。

次回もぜひチェックしてください！

「にこぷす通信」について

「NIC × Ops（にこぷす）通信」は、隔週で皆さまに情報をお届けします。
このシリーズでは、Instana（可観測性）をはじめ、Turbonomic（リソース最適化）やTerraform（インフラ自動化）など、IT運用を劇的に変える製品をピックアップしていきます。
これからも最新の技術検証をチームで継続し、皆さまの現場ですぐに役立つ「有益な知見」を全力で共有していきます。次回の連載もお楽しみに！