Note
本記事で扱う IBM Bob は、現在 Early Access（早期アクセス） 提供中の
開発者向け AI アシスタントです。IBM Bob は、ユーザーの意図・ソースコード・セキュリティを理解した上で
開発を支援する IDE / AI パートナーとして設計されています。日本からも Early Access に申し込むことができます。
IBM Bob 早期アクセス方法
- https://lnkd.in/gYtFbwcw にアクセス
- [Sign up now] にコンタクト情報を入力
- 案内メールを待つ（※順次案内）
はじめに
Instana Observability Advent Calendar 2025、2枚目に参加します。
いきなり2枚目を開けてしまいましたが、
正直な話をすると――
25日分すべて書ける自信はありません。
それでも今年は、ひとつ決めました。
「全部 IBM Bob で行く」
設計も、検証も、試験計画も、障害分析も。
Instana のデータを IBM Bob に渡して、まずは 考えさせてみる。
途中で止まったら、それはそれ。
Early Access 製品を触る、というのは、そういうものだと思っています。
なぜ IBM Bob を使うのか
IBM Bob は、IBM が提供している開発者向け AI アシスタントです（※現在 Early Access）。
ただ、この記事で IBM Bob を使っている理由は「新しい AI だから」ではありません。
一般的な生成AIチャットは、基本的に 会話 で完結します。
一方で IBM Bob は、
- 外部ツールを呼び出せる
- API と連携できる
- 構造化された結果を扱える
という前提で設計されています。
この仕組みを支えているのが
MCP（Model Context Protocol） です。
正直に言うと、最初は「また新しい仕組みか」と思いました。
でも実際に触ってみて、
「あ、これは AI に“考えさせる”ための設計だな」
と感じました。
だから今回は、
Instana のデータを IBM Bob に渡し、設計や分析を 考えさせてみることにしました。
なぜ Instana なのか
Observability ツールは数多くあります。
ただ、今回の検証で重視しているのは「どの製品が優れているか」ではありません。
AI に渡したときに、観測データがそのまま “判断に使える事実”として扱えるか
という点です。
その観点で見ると、
- メトリクスやイベントを API 経由で一貫した形式で取得できる
- アプリケーションとインフラの情報を同じ文脈で扱える
- 人ではなく「AI」に渡す前提で扱いやすい
という条件を満たしていたため、今回は Instana を使っています。
あくまで、
今回の実験条件に合っていた、という理由です。
「見る」 から 「考える」へ
この Advent Calendar でやりたいのは、
Instana の使い方解説ではありません。
Instana を
**「監視ツール」ではなく「事実の供給源」**として使い、
その事実を IBM Bob に渡して、設計や分析を 考えさせる。
- 試験計画
- 障害分析
- 仮説立て
- 判断材料の整理
人は「それが正しいか」を見る役に回る。
これは自動化でも ChatOps でもなく、
思考の下書きを AI に書かせる、
そんな使い方です。
なぜ「全部 IBM Bob」なのか
理由は、とてもシンプルです。
- 人が途中で考え始めると、IBM Bob の限界が見えなくなる
- どこまで任せられるかを知りたい
- 制約をかけたほうが、本質が見えやすい
なので今回は、
- 単体試験
- 結合試験
- システム試験
- Chaos 試験
すべて IBM Bob に最初の案を出させる前提で進めます。
人はレビュー担当です。
たぶん
「それは無理だろ」
と思う場面も、たくさん出てきます。
それも含めて、試します。
技術的な前提（大事な話）
先に言っておきます。
- IBM Bob は Early Access
- MCP も発展途上
- Python や Node、Transport 周りで普通に詰まります
実際、すでに何度も詰まりました。
このシリーズでは、
きれいに動いた話
だけは書きません。
- Python 3.14 で詰まった話
- Transport を間違えた話
- 構成を途中で捨てた判断
そういった部分も、ちゃんと書きます。
この Advent Calendar の進め方
- 書けた記事から登録します
- 順番は気にしません
- 書けるところまで書きます
予定している内容は、例えばこんな感じです。
- IBM Bob × MCP × Instana の構成整理
- STDIO と HTTP(SSE) の使い分け
- IBM Bob に試験計画を書かせてみた結果
- Chaos 試験を設計させた話
次回予告
次回はまず、足元から。
IBM Bob × MCP × Instana の全体アーキテクチャ
なぜ Marketplace を使わなかったのか。
なぜ STDIO と HTTP の両方を試したのか。
その判断理由を書きます。
おわりに
これは成功事例集ではありません。
Early Access の AI と Observability を、
現場目線で触ってみた記録です。
途中で止まっても、それは失敗ではありません。
次回も IBM Bob と一緒に、手探りで進めます。
これまでの投稿
2日目: IBM Bob × MCP × Instana ― なぜこの構成にしたのか、なぜ Transport で迷ったのか
3日目: IBM Bob に環境構築の実行計画を書かせようとして、私は止めた
4日目: IBM Bob を使う前に、人間がやるべきこと（実録）