前に「bobshell を CI/CD に組み込んでネットワーク機器の Config レビューを自動化してみた」という記事を書いたんですが、その相棒の IBM Bob Shell がメジャーアップして 2.0.0 になりました。
正直「1.x で困ってなかったし、まあマイナーに毛が生えた感じでしょ」くらいに思ってたんですが、changelog を眺めてたら MCP をコマンド一発で足せるようになってるじゃないですか。これはインフラ屋としては見逃せない…ということで、手元の NetBox（DCIM/IPAM の台帳）を MCP でつないで、ターミナルで「あのラックの機器の一覧ちょうだい」って会話で聞くところまでやってみたときのメモです。
技量不足であちこち回り道してるので、「そこはこう書くんだよ」って方はコメントでソッと教えてください。
そもそも Bob Shell ってなに
ざっくり言うと IBM Bob（AI 開発パートナー）の CLI 版です。ターミナルに住んでて、コードを読み書きしたり、コマンドを叩いたり、質問に答えたりしてくれる、いわゆる「AI エージェント系 CLI」の IBM 版、と思ってもらえれば近いです。
前回の記事では、この Bob Shell を 非対話モード（bob run）で叩いて Config レビュー器にする、という尖った使い方をしました。今回は逆に、対話しながら外部データをつなぐ方向で遊びます。
ストーリー0：1.x から 2.0 で何が変わったのか
まずは changelog の答え合わせから。個人的に「おっ」と思ったところだけ抜くとこんな感じです。
| 変わったところ | 中身 |
|---|---|
| MCP 管理コマンド |
bob mcp add / add-json / remove / list が生えた。global / workspace スコープ、stdio・SSE・HTTP の3トランスポート対応 |
| Skills | 再利用できる「instruction set（作業手順のかたまり）」を定義して、チームで共有できる。1.0.x には無かった機能 |
| モード統合 | 従来の Code mode と Advanced mode が Agent mode に一本化。自律的にタスクを進める（※ここは破壊的変更） |
| 設定スキーマ再設計 | 設定が ~/.bob/settings/settings.json に集約。telemetry セクションや edit ツールグループが追加 |
| 非対話出力の拡張 |
bob run の JSON 出力に stats（トークン数・キャッシュ率・コスト・所要時間・ツール呼び出し数）が付いた |
Code / Advanced mode に指が慣れてる人は、そこだけ注意です。旧モードは廃止されて Agent mode に寄りました。「今まで Code mode で…」って方は読み替えが要ります。
で、今回の主役は1行目の MCP 管理コマンド。ここを掘ります。
ストーリー1：材料をそろえる
例によって環境（材料）から。
- OS: Ubuntu 24.04 LTS x86_64（作業用の踏み台 VM）
- IBM Bob Shell: 2.0.0
- Node.js: 22.15.0 以上（Bob Shell の要件。※古いと入りません）
- つなぎたい先: 自分の閉域 NetBox（v4.0.11 相当）
- NetBox MCP サーバ: netbox-mcp-server（自分は fork して使ってますが、まずは素の read-only で十分）
-
uv（Python のパッケージ/実行マネージャ。MCP サーバの起動に使う）
※ NetBox の API トークンは read-only のものを用意しておくのが吉です。会話 AI に write 権限の token を握らせるのは、慣れるまでは怖いので（笑）。この記事も全部 read-only で通します。
ストーリー2：とりあえず 2.0 に上げて、MCP コマンドの存在を確認する
まずバージョン確認。
$ bob --version
2.0.0
そして、今回のお目当て。bob mcp というサブコマンド群が生えているのを確認します。
$ bob mcp list
No MCP servers configured
まだ何も刺さってないので空っぽですが、このコマンドが返ってきた時点で「2.0 に来たな」という実感があります。1.x のときは MCP は設定ファイルを手で書くのが基本だったので、list で一覧が出るだけでもだいぶ楽になりました。
MCP の設定は、ドキュメントによると
- グローバル（
--scope global）:~/.bob/settings/mcp.json - ワークスペース（既定スコープ）: プロジェクト直下の
.bob/mcp.json（こっちが優先）
に入ります。トランスポートは stdio / SSE / Streamable HTTP の3種類。今回の NetBox MCP は手元でプロセスを起動する stdio 方式でいきます。
ストーリー3：NetBox MCP サーバを用意する
MCP サーバ側を先に動くようにしておきます。uv で持ってきて、環境変数で NetBox の URL と token を渡すだけです。
$ git clone https://github.com/netboxlabs/netbox-mcp-server.git
$ cd netbox-mcp-server
$ uv sync
単体で起動確認（Ctrl+C で抜けます）。
$ NETBOX_URL=https://netbox.example.internal/ \
NETBOX_TOKEN=****(read-only token)**** \
uv run netbox-mcp-server
NETBOX_URL は自分の閉域 NetBox に読み替えてください（記事では netbox.example.internal で伏せてます）。ここでエラーが出なければ、MCP サーバとしては OK です。
※ token を read-only にしておくのを忘れずに。この MCP サーバ、素の状態は「read-only by default／簡単だけど誤爆しにくい」という設計思想なので、まずはそのまま使うのが安全です。
ストーリー4（核心）：Bob Shell に NetBox を「会話でつなぐ」
いよいよ本題。この stdio サーバを Bob Shell に登録します。2.0 なら CLI から一発です。まず bob mcp add の書式を見ておきましょう（bob mcp add --help より）。
bob mcp add [options] <name> <commandOrUrl> [args...]
-s, --scope <scope> workspace | global（既定: workspace）
-t, --transport <transport> stdio | sse | http（既定: stdio）
-e, --env <KEY=VALUE> 環境変数（繰り返し可）
-H, --header <K: V> HTTP ヘッダ（繰り返し可）
--timeout <ms> 接続タイムアウト
--include-tools <tools> 常に許可するツール（カンマ区切り）
--exclude-tools <tools> 無効化するツール（カンマ区切り）
今回は stdio（既定）で、NetBox の URL と token を -e で渡します。サーバの起動コマンド（uv …）は -- の後ろにまとめて置くのがコツです。
$ bob mcp add netbox \
--scope global \
-e NETBOX_URL=https://netbox.example.internal/ \
-e NETBOX_TOKEN=****(read-only token)**** \
-- uv --directory /home/ubuntu/netbox-mcp-server run netbox-mcp-server
-
netboxが登録名、--の後ろが「実際に起動するコマンド＋引数」です。 -
--directoryは clone 先の絶対パスで（相対だと後で泣きます。※忘れずに）。 - スコープは既定が
workspace。今回はマシン全体で使いたいので--scope globalにしました。 - ※ 登録すると token は
~/.bob/settings/mcp.jsonに平文で書かれます。このファイルは既定だと他者も読める権限（664）だったので、chmod 600 ~/.bob/settings/mcp.jsonで自分だけに絞っておくと安心です。
JSON をまるっと渡したい派は bob mcp add-json <name> '<json>' でも同じことができます（command / args / env を JSON で書くやつ）。
成功すると Added MCP server "netbox" to ~/.bob/settings/mcp.json と出ます。登録状況は一覧で確認。
$ bob mcp list
netbox: uv --directory /home/ubuntu/netbox-mcp-server run netbox-mcp-server | enabled | stdio | global
name: <コマンド> | enabled | stdio | <スコープ> の形で載れば登録OK。ふえてる！（※これは“登録”の一覧なので、実際に繋がるかは次の会話で bob がツールを呼べるかで分かります）
お試しで会話してみる
あとはもう、Bob Shell を起動して日本語で聞くだけです。
$ bob chat
> NetBox に登録されてるサイト(site)の一覧を出して。名前と slug だけでいい。
裏で Bob が NetBox MCP のツール（netbox_get_objects みたいなやつ）を呼んでくれて、こんな感じで返ってきます（※サイト名は説明用の架空 DC です）。
NetBox に登録されているサイトは以下の3件です:
| Name | Slug |
|--------------|--------------|
| Tokyo DC 01 | tokyo-dc-01 |
| Osaka DC 01 | osaka-dc-01 |
| Nagoya DC 01 | nagoya-dc-01 |
自分は DCIM/IPAM を NetBox に寄せてるので、「◯◯ラックに載ってるデバイス一覧」「このプレフィックスで空いてる IP」みたいな“台帳への問い合わせ”を、SQL も REST も叩かずに日本語で聞けるのが地味に効きます。しかも read-only 縛りなので、うっかり台帳を壊す事故も起きない。安心して雑に聞けます。
（※ これ、前回の CI/CD 記事の世界とつなげると、「Config レビュー」だけじゃなく「そのデバイス、NetBox 上ではどういう役割？」まで AI が自分で引きに行ける、ということでもあります。夢が広がる）
ストーリー5：ついでに Skills も
MCP が主役でしたが、2.0 のもう一個の目玉 Skills も軽く。これは「よくやる手順のかたまり」を instruction set として定義して、bob に覚えさせる仕組みです。
たとえば「NetBox から拠点のデバイス一覧を引いて Markdown 表にする」みたいな定型を Skill にしておくと、毎回プロンプトを書かなくても呼び出せます。チームで共有もできるので、「あの人の聞き方じゃないと NetBox からうまく引けない」問題を減らせそう。ここはまだ触り始めなので、別途ちゃんと使い込んだら追記します。
ハマりどころ
正直につまずいた点を置いておきます。
-
登録したのに
bobがツールを呼べない/エラー …bob mcp listは“登録”を出すだけで疎通保証ではありません。だいたい MCP サーバ側の単体起動が通っていないので、先にuv run netbox-mcp-serverが動くか確認するのが近道でした。 -
--directoryを相対パスで書いて動かない … Bob の起動ディレクトリ基準になってズレます。絶対パス安定。 - token を write 可のやつにしてヒヤッ … 最初うっかり write token を刺してました。会話 AI に台帳の書き込み権限、慣れるまでは持たせないのが精神衛生上よいです。read-only 推奨。
- 旧 Code mode の癖が抜けない … 2.0 で Agent mode に一本化されたので、「Code mode でやってた操作」を探して一瞬迷子になりました。もう Agent mode しかないです。
さいごに
というわけで、Bob Shell 2.0 の目玉は（自分の観測範囲では）MCP が“手書き設定”から“公式コマンド”に格上げされて、しっかり標準機能になったことでした。bob mcp add で NetBox を刺して、ターミナルから会話で台帳を引く、までを read-only で通しています。今のところ、「NetBox の前に AI の受付が一枚できた」感覚で、割と便利に使えています。
次は Skills をちゃんと組んで、「拠点まるごとレポート」みたいな定型を作れたらフィードします。あと write 系（自分の fork には preview/apply を足してあるので）を、どこまで安全に AI に握らせられるか、も追々。
個人的な検証メモなので誤りがあるかもしれません。おかしいところあれば優しく教えてください。