はじめに
前回の記事では、IBM Bob に MCP（Model Context Protocol）サーバー を追加することで、AI IDE（AIエージェント型IDE。IDE：統合開発環境）が直接インフラ機器を操作できる可能性について解説しました。
その検証過程で 「MCPサーバー自体の開発も、IBM Bobに作成依頼が可能である」 ということ、「IBM Bob 自体がインフラ操作の実行者となりうる」 という発見がありました。
前回の記事：
今回はその実践編として、IBM SAN Volume Controller (略称 SVC) を操作対象としたMCP機能を開発・実装し、IBM Bobに対して日本語で指示を出すことで、ストレージ操作を完結させる動作検証を実施しました。
AI IDE（AIエージェント型IDE）が単なるコードの書き手からインフラ構築・運用の実行者の可能性をご覧いただけるかと思います。
本記事の後半では、MCPサーバーによるインフラ操作の自動化がもたらす将来の運用像と、自律型AIに特権操作を委ねる際に発生しうるリスクをどう抑制すべきかを考察しました。
IBM Bob（Project Bob）とは？
参考： IBM Project Bob 公式アナウンスメント
IBM Bobは、エンタープライズシステムの開発・運用を自律的に完結させる、AIエージェント型IDEです。
従来のAIツールは、人間が書くコードを横でサポートする「助手」のような存在でした。しかし、IBM Bobはさらに一歩踏み込み、AI自らが「思考」してタスクを完遂するエージェントとして設計されています。
「コード補完」から「ライフサイクル全体の自動化」へ
最大の特徴は、単なるコードの書き換えに留まらず、以下の開発ライフサイクル全体をAIが自律的に実行しようとする点にあります。
要件定義： 自然言語での指示を解釈し、必要なタスクを整理する。
実装： 既存コードの解析に基づき、最適なロジックを生成する。
テスト： 修正内容に対するテストコードの作成と実行を行う。
デプロイ： サーバーへの適用までを視野に入れる。
このように、エンジニアの「作業」を断片的に助けるのではなく、プロジェクトの工程そのものを強力に推進するパートナーとなります。
MCP サーバーとは？
MCP（Model Context Protocol）を一言でいうと、AIと外部ツール・データを安全につなぐための共通規格です。
Anthropic社によって公開されたこのオープンな規格は、今やIBM Bobを含む次世代AIツールのデファクトスタンダードになりつつあります。
IBM BobにMCPサーバーを導入することは、Bobに新しい専門知識や実行できる手足を後付けでインストールすることを意味します。
SVC IBM SAN Volume Control) とは
メーカーや種類の異なる複数のストレージを一つにまとめ、「仮想的な一つの巨大なストレージプール」として扱えるようにするソフトウェア（または専用機器）です
具体例：IBM SVC（SAN Volume Controller）と IBM Bob x MCPサーバー の連携
例えば、IBM SVCを操作するためのMCPサーバーを自作してBobに繋ぎます。
これまでストレージの状況を確認したり設定を変更したりするには、人間がGUIやCLIを操作する必要がありました。
しかし、MCPで接続されたBobは以下のよう進化します。
コーディング助手： 「SVCのボリューム作成コマンドを書いて」と頼むとスクリプトを生成
専属の運用エンジニア： 「最近発生したエラーを解析して」と頼むと、Bob自身が直接SVCから情報を取得し、原因を分析して、最適な対処まで提案・実行
検証環境 概念図
MCPサーバーを追加する最大のメリット
・「汎用AI」が「専門エンジニア」に変わり、インフラの固有情報を理解し、直接操作できるようになる。
・共通化されたプロトコルの MCPサーバーのツールを追加するだけで、Bobがそのツールを使いこなせるようになる。
・社内環境に閉じたMCPサーバーを用意することで、機密性の高いインフラ操作をAIに任せつつ、安全性も確保できる。
IBM Bob と SVC 機能のMCP サーバー機能検証
IBM Bob への SVC 操作用 MCP サーバー作成依頼
作成後、MCPサーバーを反映するためにIBM Bob のアプリケーション停止起動を行います。
起動後、MCPサーバー設定に svc ツールが追加されていることが確認できました。
作成依頼過程は省略しますが、check_system_status と execute_svc_command という２つのツールを作成しています。
後者はすべてのコマンドが Bob から実行できる汎用的なツールです。
SVC用MCPサーバーの自作開発コード
IBM Bob と協働して作成したMCPサーバーのコードは以下で公開していますのでご参考ください。
svc-mcp-server/
├── .bob/ # AIアシスタント「IBM Bob」向けの設定ディレクトリ
│ └── mcp.json.example # IBM Bob用のMCPサーバー設定テンプレート
├── src/ # ソースコードディレクトリ
│ └── index.ts # MCPサーバーのメイン実装（ツール定義やSSH接続処理）
├── .env.template # 環境変数のテンプレート（接続情報設定用）
├── .gitattributes # Gitの属性設定ファイル
├── .gitignore # Git管理から除外するファイルの設定
├── README.md # プロジェクトの説明、セットアップ手順、使用方法
├── package.json # Node.jsプロジェクト定義、依存関係、実行スクリプト
├── package-lock.json # 依存ライブラリのバージョン固定用ファイル
└── tsconfig.json # TypeScriptのコンパイル設定
※本コードは現状有姿（AS-IS）で公開しており、動作保証はありません。検証環境等で十分テストの上、自己責任でご利用ください
SVC MCPサーバー 稼働確認
ボリュームリスト表示依頼
プロンプト： SVCのボリュームをリストしてください。
表示結果です。標準出力ではなく、IBM Bob によって読みやすくしてくれた内容で出力されています。
SVCボリュームリスト取得完了
合計211個のボリュームが確認されました。主な情報：
- **IO Group**: すべてのボリュームが`io_grp0`に所属
- **ステータス**: すべて`online`
- **ストレージプール**: 主に`power`プールを使用
- **容量範囲**: 1GB～500GB
- **タイプ**: 主に`striped`構成
主なボリューム例：
- [`vios1_rootvg`](id:0) - 50GB rootvg
- [`vios2_rootvg`](id:1) - 50GB rootvg (FlashCopyマッピング有り)
- [`nim_rootvg`](id:2) - 30GB rootvg
- [`nim_datavg`](id:3) - 500GB nimvg
- 各種テスト環境用ボリューム
ボリューム作成依頼
プロンプト： SVCで1GBのボリューム「testvol20260108」を作成します。
一度コマンドが実行されましたが、ストレージプール指定のオプション不足で失敗しています。
エラーが発生しても自分で問題判別して必要な情報取得とコマンド・ラインを修正しています。
正しいコマンドでの実行で成功しました。
- Bob が実行した エラーが発生しても自分で判断して修正するプロセス
作成したボリュームの確認
プロンプト： 作成したボリュームの詳細情報を見せて。結果はコマンドの標準出力でください。
読みやすい内容ですが、コマンド実機結果を編集した結果が返ってくることが気になったので、コマンドの標準出力そのものの出力を依頼しました。
下記が出力結果です。問題なく出力結果を返してきていました。
Bob が出してくれた lsvdisk の標準出力 (折りたたみ)
id 106
name testvol20260108
IO_group_id 0
IO_group_name io_grp0
status online
mdisk_grp_id 0
mdisk_grp_name power
capacity 1.00GB
type striped
formatted no
formatting yes
mdisk_id
mdisk_name
FC_id
FC_name
RC_id
RC_name
vdisk_UID 60050763808106D7D8000000000005CD
preferred_node_id 2
fast_write_state not_empty
cache readwrite
udid
fc_map_count 0
sync_rate 50
copy_count 1
se_copy_count 0
filesystem
mirror_write_priority latency
RC_change no
compressed_copy_count 0
access_IO_group_count 1
last_access_time
parent_mdisk_grp_id 0
parent_mdisk_grp_name power
owner_type none
owner_id
owner_name
encrypt no
volume_id 106
volume_name testvol20260108
function
throttle_id
throttle_name
IOPs_limit
bandwidth_limit_MB
volume_group_id
volume_group_name
cloud_backup_enabled no
cloud_account_id
cloud_account_name
backup_status off
last_backup_time
restore_status none
backup_grain_size
deduplicated_copy_count 0
protocol
copy_id 0
status online
sync yes
auto_delete no
primary yes
mdisk_grp_id 0
mdisk_grp_name power
type striped
mdisk_id
mdisk_name
fast_write_state not_empty
used_capacity 1.00GB
real_capacity 1.00GB
free_capacity 0.00MB
overallocation 100
autoexpand
warning
grainsize
se_copy no
easy_tier on
easy_tier_status balanced
tier tier_scm
tier_capacity 0.00MB
tier tier0_flash
tier_capacity 0.00MB
tier tier1_flash
tier_capacity 0.00MB
tier tier_enterprise
tier_capacity 1.00GB
tier tier_nearline
tier_capacity 0.00MB
compressed_copy no
uncompressed_used_capacity 1.00GB
parent_mdisk_grp_id 0
parent_mdisk_grp_name power
encrypt no
deduplicated_copy no
used_capacity_before_reduction
SVC エラー確認
プロンプト： SVCの直近のエラーを教えて
エラーの表示と、内容についてコメントを付与してくれています。
ここまで Bob による SVC 操作を確認しましたが、命令の理解、実行、エラー・ハンドリング、出力結果の編集、内容の説明など、こちらの意図を汲み取って実行してくれていていることが確認できました。
考察：将来の運用像とリスクの抑制
今回の検証を経て、自律型AIによるインフラ操作がもたらす変化と課題が見えてきています。
1. 将来の運用像： 「手順」から「意図」へのシフト
これまでの運用は "手順書" を実行するという方式でしたが、今後はエンジニアが 意図 を伝えるだけでAIが実行することが可能となります。
- Before: エンジニアが手順を考え、手順書を時間をかけて作成する。
- After: エンジニアは「xx という名前のボリュームを 10 GiB分 拡張して」というポリシー（意図）を提示し、AIが実行する。(エンジニアは AI と会話するための会話集(プロンプト) を準備する)
運用エンジニアは、「作業者」から「AIが守るべきガイドラインの設計者」への役割のシフトが見えてきています。
2. 特権操作を委ねる際のリスクとその抑制策
AIに強力な特権操作（ボリューム削除や再起動など）を許可することには、リスクが伴います。これに対し、以下のガードレールが不可欠と考えます。
① MCPツールの機能を「限定的な機能」に絞り込む
MCPサーバー側で公開する機能を、必要最小限の「粒度の細かいツール」として定義します。
リスク: 「全てのCLIコマンドを実行できる」という万能な権限を与えてしまうこと。
抑制策: 「ボリューム一覧取得」「スナップショット作成」など、目的が明確で安全な機能のみをMCPツールとして公開します。AIが勝手に大規模な削除や構成変更を行えないよう、MCP サーバーのツール機能そのものを制限（ハードコーディング）します。
② 実行監査 と「思考プロセス」の記録
単なる実行コマンドの履歴（Who/When/What）だけでなく、AIエージェント特有のThought（思考）プロセスをセットで記録することが重要になります。
推論ログの保存: 「なぜそのコマンドを選択したのか」「エラーに対してどう解釈し、どうリトライを決めたのか」というAI内部の推論過程をログに含めることで、万が一の事故の際の「AIの過失」か「指示の不備」かの切り分けを可能にします。
非改ざん性の確保: インフラ操作の証跡として、MCPサーバーが出力するログを改ざん不可能な外部ストレージへリアルタイム転送する仕組みを構築します。
③ 人間による最終承認
AIが「破壊的、または不可逆的な操作」を行うと判断した場合、即座に実行するのではなく、人間に対して実行プランを提示し、承認を求めるフローを挟みます。
④ 権限の最小化（RBACの徹底）
AIが利用するサービスアカウントに対して、操作対象（SVC等）側でも最小限のロール（RBAC）を割り当てます。万が一AIが誤った指示を出しても、インフラ側の権限でブロックされる二重の防御線を張ります。
まとめ
IBM BobとMCPの連携は、インフラ運用の「手足」を強化することが可能となります。
しかし、その強力な力を制御するのは、依然としてエンジニアの役割であると考えます。
「AIをどう動かすか(設計)」、「AIが安全に動ける枠組み（ガードレール）をどう作るか」 これらがこれからのAI時代におけるエンジニアの新たな専門性になるのかもしれません。
多くの現場では「AIに業務システム操作をさせるのは時期尚早だ」という懸念があると思いますが、人間がガードレール（MCPサーバーの機能制限）を設計し、AIがその枠内で自律的に動くという形を実現することで、AIは脅威ではなく、頼れるパートナーになりうると思います。