はじめに
1日目 では、
- なぜ Instana × IBM Bob をやるのか
- 「見る」から「考える」への転換
という話を書きました。
2日目 は、もう少し 技術寄りの話です。
IBM Bob × MCP × Instana を どんな構成でつないだのか
なぜ Transport で迷ったのか
完成した構成図ではなく、迷った過程そのものを書きます。
全体アーキテクチャ（まず結論）
最終的に落ち着いた構成は、こうなりました。
役割は明確です。
- IBM Bob は 考える役
- Instana は 事実を返す役
- MCP Server は 翻訳と整理
判断と取得を分離する構成です。
MCP Server を挟む理由
「Bob から直接 Instana API を叩けばいいのでは？」と思うかもしれません。
でも今回は、それをやりませんでした。
理由① Bob に API 詳細を覚えさせたくない
Instana の API は、
- エンドポイントが多い
- クエリが複雑
- 認証・ヘッダ指定が必要
Bob 側にこれを持たせると、
Bob が API クライアントになる
状態になります。
今回はそれを避けました。
Bob には、
「何を知りたいか」だけを考えさせる
役割に集中させたかった。
理由② Tool として意味を持たせたかった
MCP Server を挟むことで、
- アプリ一覧を取得する
- 直近のイベントを調べる
- 特定サービスのメトリクスを見る
といった操作が Tool として定義されます。
Bob から見ると、
API ではなく
「使える道具」
になる。
この違いは、後で効いてきます。
理由③ Transport を後から変えられる
MCP Server を挟むことで、
- Bob ↔ MCP Server
- MCP Server ↔ Instana
が分離されます。
この分離があったからこそ、後で Transport を迷える余地が残りました。
Transport で迷った話（正直なところ）
MCP には主に2つの Transport があります。
- STDIO
- HTTP(SSE / Streamable HTTP)
最初は、こう思っていました。
「STDIO 一択でしょ」
STDIO が魅力的に見えた理由
- ローカル完結
- 設定が少ない
- ネットワーク不要
Bob と MCP Server が同じマシンにあるなら、まずは一番ラクです。
実際、最初は STDIO で動かしました。
でも、途中で詰まり始めた
正直に書くと、このあたりから 詰まり始めました。
- なぜ MCP Server を挟むのか
- なぜ Transport を意識する必要があるのか
- なぜ STDIO だけでは足りないのか
最初は、
「動かし方」が分からなかった
のだと思っていました。
でも振り返ると違います。
「考え方」が整理できていなかった。
HTTP(SSE) を試した理由
そこで試したのが HTTP(SSE / Streamable HTTP) です。
- MCP Server を HTTP で起動
- Bob 側は STDIO のまま
- mcp-remote で STDIO ↔ HTTP をブリッジ
この構成にして、ようやく見えました。
- MCP Server を常駐させられる
- デモや共有がしやすい
- 「配る構成」がイメージできる
そして、気づきました。
Transport は通信方式ではなく使い方の選択肢なんだ
どちらが正解か？
結論は、とてもシンプルです。
どちらも正解
検証・開発フェーズ
- STDIO
- ローカル完結
- 壊しやすい
共有・デモ・展開フェーズ
- HTTP(SSE)
- mcp-remote 併用
- 再現性が高い
視点を切り替えた瞬間
Observability データを、ずっと 「人が見る前提」 で使っていました。
- グラフを見る
- イベントを追う
- 人が判断する
それが当たり前だと思っていた。
でも今回、Instana のデータを IBM Bob に渡す構成を考える中で、ふと視点が切り替わりました。
これは、人が見るためのデータではなく AI に渡す「事実」なんじゃないか
そう考えた瞬間、
- なぜ MCP Server を挟むのか
- なぜ Transport を選ぶ必要があるのか
が、自然につながりました。
構成や Transport は、先に決めるものではなく、
AI に何を考えさせたいかを決めた結果として 後から見えてくるもの
だったのだと思います。
2日目 のまとめ
- MCP Server は、Instana からデータを取るためではなく 役割を分離するために必要だった
- Transport は「どれが正解か」ではなく どう使いたいかで選ぶものだった
- 迷った過程そのものが、後から見ると判断材料になる
- 構成は、 「AI に何を考えさせたいか」を決めた結果として見えてくる
これまでの投稿
1日目: なぜ Instana × IBM Bob なのか？ ― Observability を「見る」から「考える」へ
3日目: IBM Bob に環境構築の実行計画を書かせようとして、私は止めた
4日目: IBM Bob を使う前に、人間がやるべきこと（実録）