はじめに
1日目 では、
- なぜ Instana × IBM Bob をやるのか
- Observability を「見る」から「考える」へ、という話
2日目 では、
- IBM Bob × MCP × Instana の構成
- STDIO と HTTP(SSE) で迷った理由
を書きました。
3日目 は、いよいよ 実践です。
IBM Bob に、環境構築の実行計画書を書かせる
……はずでした。
やろうとしたこと
やろうとしたのは、とてもシンプルです。
IBM Bob に対して、こう依頼しました。
- macOS（M1 / M2）
- Instana API を使う
- MCP Server は mcp-instana
- HTTP(SSE) で起動
- Bob 側は STDIO
- mcp-remote でブリッジ
- 再現性重視
- ローカル検証目的
この前提で、
「環境構築の実行計画書を書いてほしい」
と。
アウトプット要件も、かなり細かく指定しました。
しかし、すぐに止まった
実際にやり取りを始めると、すぐに詰まりました。
Bob から返ってくるのは、正論の質問です。
- Python のバージョンは？
- Node.js はどのバージョン？
- 仮想環境はどう作る？
- PATH は前提？
- pyenv / nvm は使う？
……全部、もっともです。
でも、その時の私の正直な状態は、こうでした。
それ、まだ俺も分かってない
ここで、あえてやめた
この時点で、私はやめました。
理由は単純です。
自分自身が、まだ分かっていなかったから。
- どの Python バージョンが本当に動くのか
- Node はどこまで新しくする必要があるのか
- 何をどこまで事前に入れておくべきか
正直、この時点では 頭の中に「正解の構成」はありませんでした。
だから Bob に質問されても、
「それは、まだ俺も知らない」
という状態だった。
Try & Error をしていないのに、計画は書けない
ここで気づいたのは、これです。
Try & Error を一度もしていない状態で、実行計画だけを書こうとしていた
人間でも無理なことを、AI にだけ求めていた。
それに気づいた瞬間、
これは一度、人間が手を動かすフェーズだ
と割り切りました。
無理に続けなかった理由
このまま Bob の質問に答え続けることもできました。
でも、それは
- その場で仮の前提を作る
- 後から壊れる計画を積み上げる
- 結果的に「それっぽい嘘」を書く
ことになります。
それはやりたくなかった。
だから今回は、
「分からないまま AI に考えさせる」ことをやめた
それだけです。
この判断は、逃げではない
後から振り返ると、この判断は正しかったと思っています。
- 先に手で試す
- 動く最小構成を見つける
- そこから AI に戻る
この順番でないと、** IBM Bob の価値も、Instana の価値も見えない**。
この時点で分かったこと
この 3日目 で得られた一番の学びは、これでした。
AI に考えさせる前に、人間が一度は「分からない」を経験する必要がある
Try & Error をやらずに、最初から正解を AI に求めるのは無理だった。
3日目 のまとめ
- IBM Bob の質問は正しかった
- 答えられなかったのは、AI のせいではない
- 自分自身が、まだ試していなかった
- だから一度、AI を止めた
- これは失敗ではなく、段階の切り分け
次回予告（4日目）
次回は、こうなります。
人間が、手で環境を作る
- Python のバージョンで詰まる
- Node.js を上げる
- Transport を間違える
- 何度も壊す
その全部を経て、
「これなら Bob に考えさせられる」
という最小構成を作ります。
AI を使う前に、人間が泥臭くやった話を書きます。
これまでの投稿
1日目: なぜ Instana × IBM Bob なのか？ ― Observability を「見る」から「考える」へ
2日目: IBM Bob × MCP × Instana ― なぜこの構成にしたのか、なぜ Transport で迷ったのか
4日目: IBM Bob を使う前に、人間がやるべきこと（実録）