Claude Code / IBM Bob を Terminal-MCP で繋いだら、構成情報の収集とドキュメント化が自律化した話

はじめに

最近、Claude CodeやIBM Bobをはじめとする「AIエージェント」の進化には目を見張るものがあります。しかし使っているうちに、こんな不満を感じることはありませんか?

• AIエージェントがフリーズする。

• AIエージェントが間違ったコマンドを実行してエラーが発生する。

その都度、人間が手動でAIを再起動したり、AIに正しいコマンドを調べて教える必要があります。

ときには、AIに正しいコマンドをうまく教えられず、結局、自分でコマンド実行し、その出力をAIにコピペするという作業を繰り返す羽目になることもありました。

楽になるためにAIを使っているのに、かえって無駄な作業が増えていては本末転倒です。
AIを手足にするはずが、自分がAIの手足になってはいけません。
そんな不満を解消するために、AIが自律的にターミナルと対話できるTerminal-MCPを自作することにしました。

1章 Terminal-MCPとは何か

Terminal-MCPは、AIエージェントがターミナルを直接操作できるようにするMCPサーバーです。
Node.jsとnode-ptyを使って実装しており、MacBook Pro M1（macOS）上で動作確認しています。

主にできることは以下の通りです。

• ターミナルセッションの作成・管理：複数のセッションを同時に立ち上げ、並行して操作できます。

• コマンドの送信と出力の取得：AIがコマンドを送信し、その結果をリアルタイムに受け取ります。

• 双方向の対話：SSHやtelnetで接続した先のサーバーや機器と、AIが自律的にやり取りできます。

• 特殊キーの送信：Ctrl+CなどもAIから送信可能です。

• iTerm2との連携（macOS限定）：ターミナル画面を人間も見ながら操作できるハイブリッドモードも利用できます。

Claude CodeおよびIBM BobのどちらのAIエージェントからも利用可能です。
通信はネットワークを経由せず、stdioトランスポートでローカルに接続します。

2章 コマンドを「実行する」だけでは足りない理由

通常、コマンドを実行するだけのMCPサーバーであれば、Node.jsの child_process を使って子プロセスを立ち上げ、標準入出力をパイプするだけで簡単に作れます。

しかしこのアプローチには、致命的な弱点が2つあります。

• 対話型コマンドでフリーズする：sshなど実行中に入力を求めるコマンドを叩いた瞬間、プロセスがユーザー入力を待ったままブロックされます。

• エラーが起きたら人間頼みになる：環境ごとのコマンドの差異でエラーが出た際、AIがターミナルの状態を察知できず、そこで思考が途切れてしまいます。

これらを解決するためには、AIにただコマンドを投げさせるのではなく、「ターミナルセッションを授け、出力をリアルタイムに認識させる」
必要がありました。

なお、macOS環境限定ですが、iTerm2とAppleScriptを組み合わせることで、パスワード入力など人間が介入すべき場面だけ手動でターミナル・ウインドーで対応し、それ以外をAIに任せるハイブリッドな操作も可能です。

3章 node-ptyの擬似端末で解決できました

今回の自作MCPでは、バックエンドのシェル制御に node-pty を採用しました。
node-ptyは、VS Codeの統合ターミナルなどでも使われている、実績のある擬似端末（Pseudoterminal）ライブラリです。
OS側からは「本物のターミナルウィンドウから人間が操作している」ように見え、sshのような双方向通信も保持できます。

設計のポイントはマルチセッション管理です。

"create_terminal" でセッションを必要なだけ作成し、それぞれを独立したPtyプロセスとして管理します。
AIは複数のセッションを同時に持ち、機器ごとに別々のターミナルで並行して作業できます。

コマンド送信は "send_command" で行い、指定した待機時間（wait_ms）の間に蓄積された出力をまとめてAIに返します。
AIはその出力を見て「パスワードを求められている」「エラーが出た」と判断し、次のアクションを自律的に決定します。

4章 AIに必要最低限の権限のみを与えるシンプルな安全策

AIに本物のターミナルを授けるとなると、どうしても頭をよぎるのがセキュリティのリスクです。
万が一、AIが意図せずファイルを削除したり、重要な設定ファイルを書き換えてしまったら目も当てられません。

そこで、MCPサーバーのコードで危険なコマンドを弾くのではなく、システムレベルでガードする方法を採用しました。

具体的には、ターミナルからSSHやtelnetで対象のサーバーや機器に接続する際、AIが使用するログインIDをRead-Only専用のものにします。
こうすることで、AIがどれだけ破壊的なコマンドを実行しようとしても、接続先のシステムがパーミッションエラー（Permission denied）でブロックします。

そしてここからが Terminal-MCP の本領発揮です。

エラーで弾かれたAIは、そこでフリーズすることなく、ターミナルに返ってきたエラーメッセージから「このコマンドには権限がないのだな」と自律的に理解し、安全な代替案に切り替えて処理を続行します。
コードによる制限と違い、AIがどんなアプローチを取ってもシステムレベルで突破できないのが最大の強みです。

5章 構成情報の収集とドキュメント化への応用

現状は、主にTerminal-MCPを使ってインフラの構成情報を収集し、ドキュメントとしてまとめる作業に利用しています。

従来は、人間が複数の機器にSSH接続してコマンドを叩き、その出力をコピペしながらドキュメントを作成する、という泥臭い作業が必要でした。Terminal-MCPを使えば、この一連の作業をAIに任せることができます。

AIへの指示はシンプルです。
以下の "9.9.9.9 <read-only-userid> xxxxxx" はダミーの値です)

指示を受けたAIは、マルチセッション機能を使って複数の機器に同時接続します。
接続後はOSの種類を自動判定し、機器ごとに適切なコマンドを選びながら自律的に構成情報を収集していきます。

途中でコマンドが間違っていてもフリーズしません。
ターミナルに返ってきたエラーメッセージを読んで、自分でコマンドを修正しながら収集を続けます。

すべての情報が集まったら、AIが自動的にドキュメントとしてまとめます。人間がやることは最初の一言だけです。

まとめ

Terminal-MCPは、AIと私たちが普段使っているインフラ環境をダイレクトに繋ぐ架け橋となりえます。

現在、ターミナルで大量に手打ちしている作業について、Terminal-MCPがあれば、AIに任せる道筋が見えてくるはずです。

AIにどのようなことをやらせたいのかを、プロンプト形式で依頼するだけで、ターミナルとのやり取りはTerminal-MCPが行うので、特別なプログラムを作成しなくとも、AIを手足のように使えるようになるでしょう。

実際「5章 構成情報の収集とドキュメント化への応用」のユースケースでは、簡単な指示(プロンプト)だけで、一度動き始めたら、AIが自律的にターミナルを操作し、複数の機器から同時に構成情報を収集して、ドキュメントまで仕上げてくれました。
しかも、コマンドが間違っていても自分で修正しながら進んでいきました。

この記事を参考に、ぜひ読者の皆様も自分だけの「手足」を作っていただければ幸いです。

最後までお読みいただき、ありがとうございました。
もし参考になりましたら、「スキ」やシェアをしていただけると励みになります！