IBM Bob で Ansible MCP サーバー (VSCode 拡張) を試してみました

Last updated at 2026-09-14Posted at 2026-09-13

はじめに

Ansible の VS Code Extension（redhat.ansible）には、MCP サーバーが同梱されています。

MCP（Model Context Protocol）は、AI エージェントが外部ツールと連携するための標準プロトコルです。この MCP サーバーは VSCode 向けに作られたものですが、IBM Bob からも、VSCode を起動せずに同じツール群を呼び出せます。

このサーバーが提供するのは、lint の実行・環境確認・ベストプラクティスの参照・プロジェクト生成といった、Ansible 開発に直結する 10 のツールです。Bob に接続することで、「コマンドを調べて叩く」作業を Bob に委ねられるようになります。

この記事では、Ansible VS Code Extension の MCP サーバーを Bob に接続した手順と、接続できなかった際のトラブルシューティング、そして各ツールを実際に試した結果をまとめます。

この記事でわかること：

Ansible MCP サーバーの概要と、VSCode なしで Bob から使える仕組み
「URL を渡して設定して」と頼むだけで Bob が MCP の設定を自動生成する流れ
接続できないときの原因と修正方法
接続後に使える 10 のツール概要

対象読者： Ansible をある程度使っており、IBM Bob を活用して作業を効率化したい方

動画

当記事を動画にした内容です。理解の一助にご参照ください。

環境情報

IBM Bob (AI Client)

項目	バージョン
Node.js	v25.2.1 (`/opt/homebrew/bin/node`)
Ansible Core	2.17.3
Ansible Lint	26.1.0
Python	3.14.2
Ansible VS Code Extension	`redhat.ansible-26.8.2`

Bob への依頼：設定ドキュメントの URL を渡して依頼

使ったプロンプト

MCPサーバー設定文書も人の方で読まず、Bob に依頼しました。

https://docs.ansible.com/projects/vscode-ansible/mcp/  を読んで設定して

Bob が自動で行った処理

Bob は以下のステップを自動で実行しました。

ドキュメントを読み込む
渡した URL の内容を解析し、設定に必要な情報を抽出。
必要な設定項目を特定する
MCP サーバーの command・args などをドキュメントから読み取る。
設定ファイルに書き込む
プロジェクトルートの .bob/mcp.json に Ansible MCP サーバーの設定を自動生成。
設定完了を報告する
「設定しました。MCP タブから Ansible サーバーが接続されているか確認してください」と返答。

全体アーキテクチャ

IBM Bob（MCP クライアント）→ .bob/mcp.json → Node.js MCP サーバー → Ansible（ローカル）→ Collections の流れ

構成のポイントは以下の通りです。

IBM Bob（AI Agent）が .bob/mcp.json を読み込み、MCP Protocol（stdio）でサーバーと通信する
MCP サーバーは VSCode 拡張機能（redhat.ansible-26.8.2）のファイルを間借りした Node.js プロセスとして動作する
VSCode 自体は不要。ファイルだけ利用し、すべてローカル Mac 上で完結する
Ansible Core 2.17.3 と ansible-lint 26.1.0、合計 24 個の Collections（amazon.aws・cisco.* など）を参照する

VSCode Extension の MCP サーバーが Bob でも動く理由

Ansible VS Code Extension に含まれる MCP サーバー（cli.js）は、VSCode との通信に依存していません。MCP（Model Context Protocol）という標準プロトコルの stdio トランスポートで実装されているため、MCP に対応したクライアントであれば何でも接続できます。

┌─────────────────────────────────────────────────┐
│ 本来の用途（VSCode）                              │
│   VSCode  ──MCP──▶  redhat.ansible extension    │
│                      （内蔵 MCP サーバー）        │
└─────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────┐
│ この記事の構成（Bob）                              │
│   IBM Bob ──MCP──▶  cli.js（同じサーバー）         │
│              stdio     ↓                        │
│                   Ansible / ansible-lint        │
└─────────────────────────────────────────────────┘

つまり、VSCode Extension をインストールした際に ~/.vscode/extensions/redhat.ansible-*/ に展開された cli.js を、Bob が直接 Node.js で起動しているだけです。VSCode が起動していなくても、拡張機能ファイルが存在さえすれば MCP サーバーとして機能します。

	VSCode での利用	Bob での利用
必要なもの	VSCode + 拡張機能インストール	拡張機能インストール（VSCode 起動不要）
MCP クライアント	VSCode 本体	IBM Bob
設定ファイル	VSCode の設定	`.bob/mcp.json`
使えるツール	同じ 10 ツール	同じ 10 ツール

設定手順

1. Extension のパスを確認する

ターミナルで以下を実行して、インストール済みバージョンを確認します。

ls ~/.vscode/extensions/ | grep redhat.ansible
# 例: redhat.ansible-26.8.2

2. MCP 設定ファイルの場所を決める

今回はプロジェクト内にのみ適用するため、プロジェクトルートに .bob/mcp.json を作成します。

スコープ	ファイルパス
グローバル（全ワークスペース）	`~/.bob/settings/mcp.json`
プロジェクト（このワークスペースのみ）	`.bob/mcp.json`

注意： 同名サーバーが両方に存在する場合はプロジェクトレベルが優先されます。

3. 設定を記述する

Bob が自動生成した内容をベースに、.bob/mcp.json に以下を記述します。

{
  "mcpServers": {
    "ansible": {
      "command": "/opt/homebrew/bin/node",
      "args": [
        "/Users/yourname/.vscode/extensions/redhat.ansible-26.8.2/packages/ansible-mcp-server/dist/cli.js",
        "--stdio"
      ],
      "disabled": false
    }
  }
}

/Users/yourname/ の部分はご自身のホームディレクトリに置き換えてください。Bob が .bob/mcp.json を読み込み、Node.js で MCP サーバーをローカルプロセスとして起動します。VSCode 自体は起動していなくても動作します。

接続できない場合のトラブルシューティング

設定後に Bob を再起動しても ansible が Disconnected になる場合、以下の 2 つが原因であることが多いです。

原因 1：`node` のフルパスを指定していない

Bob が起動するシェルは PATH が制限されており、node という短縮名でコマンドが見つからないことがあります。

# node のフルパスを確認する
which node
# → /opt/homebrew/bin/node

修正： "command": "node" → "command": "/opt/homebrew/bin/node" に変更します。

原因 2：`server.js` を指定している

dist/server.js はライブラリとして関数をエクスポートするだけのモジュールで、サーバープロセスとして起動できません。

# server.js の中身を確認すると export 文だけ
head -1 ~/.vscode/extensions/redhat.ansible-26.8.2/packages/ansible-mcp-server/dist/server.js
# → export { t as createAnsibleMcpServer, e as runStdio };

実際の起動スクリプトは cli.js で、STDIO モードで動かすには --stdio 引数が必要です。

node dist/cli.js --help
# → Usage:
#     ansible-mcp-server --stdio

修正： server.js → cli.js に変更し、引数に --stdio を追加します。

修正内容まとめ

問題	原因	修正
サーバーが起動しない	Bob の環境で`node` の PATH が通っていない	`command` をフルパス `/opt/homebrew/bin/node` に変更
起動してもすぐ終了する	`server.js` はモジュール。`--stdio` 引数も必要	`cli.js --stdio` に変更

動作確認

設定が正しければ、以下のコマンドで MCP の initialize リクエストに応答することを確認できます。

echo '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{},"clientInfo":{"name":"test","version":"0"}}}' \
  | /opt/homebrew/bin/node ~/.vscode/extensions/redhat.ansible-26.8.2/packages/ansible-mcp-server/dist/cli.js --stdio

以下のようなレスポンスが返れば成功です。

{
  "result": {
    "protocolVersion": "2024-11-05",
    "capabilities": { "resources": {}, "tools": {} },
    "serverInfo": { "name": "ansible-mcp-server", "version": "0.1.0" }
  },
  "jsonrpc": "2.0",
  "id": 1
}

Bob の MCP パネルに ansible が接続済みで表示されれば完了です。

実際に接続に成功すると、Bob の MCP 設定画面で以下のように ansible サーバーが Connected として一覧に表示されます。

サーバー名をクリックすると詳細が確認でき、Status が Connected、バージョンが 0.1.0 であることが分かります。

接続後に使えるツール

接続後、Bob に「Ansible MCP サーバーで使えるツールを教えて」と尋ねると、以下の 10 個が確認できます。

zen_of_ansible
ansible_content_best_practices
list_available_tools
ansible_lint
ansible_navigator
ade_environment_info
ade_setup_environment
adt_check_env
create_ansible_projects
define_and_build_execution_env

以下、それぞれの使い方と活用場面を紹介します。

Ansible の設計思想：`zen_of_ansible`

Ansible の設計哲学を示す 20 の指針を返します。Python の import this（The Zen of Python）と同じ発想で、Ansible らしい設計とは何かを手軽に参照できます。

「なぜ Ansible ではこう書くのか」という問いへのヒントになりますし、コードレビューの基準やチームでの設計判断の軸にもなります。

Bob への頼み方：

「Ansible の設計思想を教えて」

全 20 の格言と日本語訳：

#	原文	日本語訳
1	Ansible is not Python.	Ansible は Python ではない。
2	YAML sucks for coding.	コーディングに YAML はイケていない。
3	Playbooks are not for programming.	Playbook はプログラミングのためのものではない。
4	Ansible users are (most likely) not programmers.	Ansible ユーザーは（ほぼ確実に）プログラマーではない。
5	Clear is better than cluttered.	明確さは混乱よりも優れている。
6	Concise is better than verbose.	簡潔さは冗長さよりも優れている。
7	Simple is better than complex.	シンプルは複雑よりも優れている。
8	Readability counts.	読みやすさは重要だ。
9	Helping users get things done matters most.	ユーザーがタスクを達成できるよう助けることが最も重要。
10	User experience beats ideological purity.	ユーザー体験はイデオロギー的純粋さに勝る。
11	"Magic" conquers the manual.	「魔法」は手作業を征服する。
12	When giving users options, use convention over configuration.	ユーザーにオプションを与えるとき、設定より規約を優先せよ。
13	Declarative is better than imperative -- most of the time.	宣言的は命令的よりも優れている——ほとんどの場合。
14	Focus avoids complexity.	集中は複雑さを避ける。
15	Complexity kills productivity.	複雑さは生産性を殺す。
16	If the implementation is hard to explain, it's a bad idea.	実装の説明が難しければ、それは悪いアイデアだ。
17	Every shell command and UI interaction is an opportunity to automate.	すべてのシェルコマンドと UI 操作は自動化の機会だ。
18	Just because something works, doesn't mean it can't be improved.	動いているからといって、改善できないわけではない。
19	Friction should be eliminated whenever possible.	摩擦は可能な限り排除されるべきだ。
20	Automation is a journey that never ends.	自動化は決して終わらない旅だ。

シンプルさ・読みやすさ・ユーザー体験・自動化の継続的追求 が中心テーマです。特に格言 13・15・20 は Ansible の設計全体に反映されている重要な哲学です。

実際に試してみた：`zen_of_ansible` の実行結果

「Ansible の設計思想を教えて」と頼むと、MCP ツールが zen_of_ansible を呼び出し、上記 20 件の格言がリスト形式で返ってきます。Bob はそれをそのまま表示した上で、各格言の日本語訳と解説をあわせて提示してくれました。

ベストプラクティスの参照：`ansible_content_best_practices`

Ansible コンテンツを書くときのベストプラクティスをトピック別に教えてくれます。

「この変数名の付け方は正しい？」「ロールの中でどこに何を置けばいい？」など、Ansible 特有の慣習や推奨事項がわからないときに活用できます。

Bob への頼み方：

「変数の命名規則を教えて」
「ロールのディレクトリ構成のベストプラクティスは？」
「Playbook を書くときの注意点は？」

聞けるトピックの例：

トピック	内容
Naming Conventions	変数・タスク・ロールの命名規則
Formatting	YAML の書き方・インデント
Roles	ロールの構成と役割分担
Variables	変数の優先順位と管理方法
Playbooks	プレイブックの設計指針
Inventories	インベントリの管理方法

実際に試してみた：`ansible_content_best_practices` の実行結果

「どんなトピックがあるか教えて」と頼むと、MCP ツールが ansible_content_best_practices を呼び出し、利用可能なトピック名がリスト形式で返ってきます。続けて「変数の命名規則を教えて」のように具体的なトピックを指定すると、そのトピックの詳細なガイドラインが返ってきます。

実際に試してみた：Playbook 作成 + ベストプラクティスレビュー

「postfix を再起動する Playbook を作成して」と依頼すると、まず ansible_content_best_practices を playbooks / naming conventions の2トピックで呼び出しながら以下の Playbook を生成しました。

---
- name: Restart Postfix mail service
  hosts: all
  become: true

  tasks:
    - name: Restart Postfix service
      ansible.builtin.service:
        name: postfix
        state: restarted

    - name: Verify Postfix service is running
      ansible.builtin.service:
        name: postfix
        state: started
        enabled: true

注目ポイント： ベストプラクティスを参照しながら生成しただけあって、FQCN・命名規則・拡張子など主要な項目はおおむね準拠できていました。残った指摘は hosts: all（具体的なグループ名への変更）、サービス名の変数化、gather_facts: false の明示という軽微な改善点の3点のみでした。

続けて「ansible のベストプラクティスで確認して」と依頼すると、今度は playbooks / naming conventions / variables / Guiding Principles の4トピックを参照し、作成済みの Playbook とガイドラインを照合して改善点を一覧で提示してくれました。さらに ansible-lint も自動で実行され、0 failure / 0 warning（production プロファイル合格）であることを確認するところまで一連の流れで行われました。

指摘された改善点：

チェック項目	結果	詳細
ファイル拡張子 `.yml`	✅	`.yaml` ではなく `.yml` を使用
Play に `name` が付いている	✅	`Restart Postfix mail service`
全タスクに `name` が付いている	✅	命令形・大文字始まりで命名済み
FQCN モジュール名	✅	`ansible.builtin.service` を使用
`hosts: all` の使用	⚠️	全ホストが対象になるため `mail_servers` など具体的なグループ名に変更すべき
`gather_facts` の明示	⚠️	facts を使わないため `gather_facts: false` を明示すると高速化できる
サービス名のハードコード	⚠️	`vars` で変数化すると再利用しやすくなる

ツール一覧の確認：`list_available_tools`

MCP サーバーに接続後、まず list_available_tools を実行してどんなツールが使えるかを確認するのがおすすめです。

Bob への頼み方：

「MCP サーバーで list_available_tools を実行して」

実行すると、以下のようにツール名と概要が一覧で返ってきます。

ツール名	概要
`zen_of_ansible`	Ansible の設計哲学を表す 20 のアフォリズムを返す
`ansible_content_best_practices`	Ansible コンテンツのベストプラクティス・ガイドラインを取得する
`list_available_tools`	利用可能なツール一覧を表示する（このツール自体）
`ansible_lint`	Ansible Playbook を lint で検証する
`ansible_navigator`	`ansible-navigator` を使って Playbook を実行する
`ade_environment_info`	Python / Ansible / ADE / ADT のバージョンや状態を確認する
`ade_setup_environment`	Ansible 開発環境をセットアップする（仮想環境・コレクション等）
`adt_check_env`	ADT (ansible-dev-tools) のインストール確認・セットアップを行う
`create_ansible_projects`	`ansible-creator` を使ってコレクションや Playbook プロジェクトを生成する
`define_and_build_execution_env`	`ansible-builder` 用の Execution Environment 定義ファイルを作成・ビルドする

上記テーブルの内容は実際の実行結果をそのまま掲載したものです。MCP ツールが list_available_tools を呼び出すと、ツール名と概要のペアがリスト形式で返ってきます。

コードの品質チェック：`ansible_lint`

プレイブックに書いたコードの問題点を自動で見つけてくれます。

Ansible には「こう書くべき」というベストプラクティスが多くあります。ansible-lint はそのルールに照らして問題箇所を指摘してくれるツールです。「動くけど書き方が良くない」という部分も検出できます。

Bob への頼み方：

「playbooks/deploy.yml を lint してエラーを確認して」
「lint を実行して、自動修正できるものは直して」

ターミナルで直接実行したい場合は次のコマンドです。

# チェックだけ実行する
ansible-lint playbooks/deploy.yml

# 自動修正も合わせて行う
ansible-lint site.yml --fix

メモ： Bob はチャットで開いているファイルをコンテキストとして把握しているので、「この Playbook を lint して」と言うだけでファイルパスを自動判別します。

実際に試してみた：既存 Playbook に対して lint を実行

「ansible-lint を実行」と頼むと、Bob はまずワークスペース内の Ansible ファイルを自動検索し、~/Desktop/xxx/Code/VM/ 配下の 13 ファイルを対象に lint を実行しました。

source venv/bin/activate
ansible-lint ~/Desktop/xxx/Code/VM/*.yml ~/Desktop/xxx/Code/VM/tools/*.yml

結果：13 ファイル中に 280 failures・2 warnings を検出

違反件数の内訳：

ルール	件数	説明
`fqcn[action-core]`	148	FQCN 未使用（例:`uri` → `ansible.builtin.uri`）
`yaml[truthy]`	36	`yes`/`no` の代わりに `true`/`false` を使うべき
`yaml[trailing-spaces]`	19	行末の余分なスペース
`name[casing]`	13	タスク名を大文字始まりにすべき
`risky-shell-pipe`	11	pipe 使用時に`pipefail` オプションが未設定
`ignore-errors`	10	`ignore_errors` の代わりに `failed_when` を使うべき
`yaml[line-length]`	10	1 行が 160 文字を超過
`no-changed-when`	8	`command`/`shell` タスクに `changed_when` が未設定
`command-instead-of-module`	5	`systemctl` の代わりに `systemd` モジュールを使うべき
`risky-file-permissions`	3	ファイルパーミッションが未指定
`command-instead-of-shell`	2	shell 機能不要なのに`shell` を使用
その他`yaml[*]`	7	`new-line-at-end-of-file`・`brackets`・`empty-lines` など

特記事項（要対処）：

ファイル	問題
`cert-replace.yml`	`community.hashi_vault.vault_kv2_get` モジュールが未インストール
`tools/setup_cert_env.yml`	ロール`cert_prerequisites` が見つからない
`tools/setup_webserver_env.yml`	`firewalld` モジュールが未解決

最も多い fqcn[action-core]（148 件）は ansible-lint --fix で自動修正できます。community.hashi_vault のコレクション不足は ansible-galaxy collection install community.hashi_vault で解消します。

プレイブックの実行：`ansible_navigator`

ansible-navigator を通じてプレイブックを実行します。

ansible-playbook コマンドに比べて、実行環境（コンテナ）を使った再現性の高い実行や実行履歴の確認など多くの機能を持つツールです。Podman や Docker が使えない環境でも、自動でフォールバックしてローカル実行に切り替えてくれます。

Bob への頼み方：

「site.yml を実行して」
「playbooks/deploy.yml をコンテナなし（Podman なし）で実行して」

環境の確認：`ade_environment_info`

現在の Ansible 開発環境を一覧表示します。「自分の環境に何が入っているか」をすぐ確認できます。

チームで作業するとき、「自分の環境と相手の環境で Ansible のバージョンが違う」「あのコレクション入ってたっけ？」という確認にも使えます。

Bob への頼み方：

「今の Ansible 環境を確認して」

実際に試してみた：`ade_environment_info` の実行結果

「ade_environment_info を試して」と頼むと、以下の情報が返ってきました。

Environment Information
==================================================

Workspace: /
Python: Python 3.14.2
Virtual Environment: Not set

Ansible Tools:
  - Ansible: ansible [core 2.17.3]
  - Ansible Lint: ansible-lint 26.1.0 using ansible-core:2.20.1

Development Tools:
  - ADE: Not installed
  - ADT: Not installed

Installed Collections:
  ansible.controller      4.7.6
  awx.awx                 24.6.1
  infra.aap_configuration 3.3.0
  amazon.aws              8.1.0
  ansible.netcommon       6.1.3
  cisco.aci               2.10.1
  cisco.asa               5.0.1
  cisco.dnac              6.17.1
  cisco.intersight        2.0.10
  cisco.ios               8.0.0
  cisco.iosxr             9.0.0
  cisco.ise               2.9.3
  cisco.meraki            2.18.1
  cisco.mso               2.9.0
  cisco.nxos              8.1.0
  cisco.ucs               1.10.0
  community.aws           8.0.0
  community.ciscosmb      1.0.9
  community.hashi_vault   6.2.0
  f5networks.f5_modules   1.30.1
  ibm.spectrum_virtualize 2.0.0
  ibm.storage_virtualize  2.4.1
  openstack.cloud         2.2.0
  vyos.vyos               4.1.0

読み取れる情報のポイント：

項目	内容	補足
Python	3.14.2	システムインストール済み
Ansible Core	2.17.3	システムの ansible を参照
Ansible Lint	26.1.0	システムの ansible-lint を参照
Virtual Environment	Not set	venv は有効化されていない状態で実行
ADE / ADT	Not installed	`venv/` 内のツールは認識されていない
コレクション数	22 個	AWS・Cisco・IBM・F5 など幅広いベンダー

気づいた点： ade_setup_environment で構築した venv/ 内の ansible-dev-tools 26.8.0 は、MCP ツールが参照しているシステム Python の環境ではないため「ADE / ADT: Not installed」と表示されます。venv を有効化した状態で Bob に頼む場合と、システム環境で MCP サーバーが動いている場合で見える情報が異なります。

開発環境のセットアップ：`ade_setup_environment` と `adt_check_env`

Ansible 開発に必要なツール一式をまとめてインストールします。

新しいマシンで開発を始めるとき、「何をインストールすればいいか」を調べる手間がなくなります。OS を伝えるだけで、パッケージマネージャーの違いを吸収して適切にセットアップしてくれます。

Bob への頼み方：

「macOS に Ansible 開発環境をセットアップして」
「Ubuntu で amazon.aws と ansible.posix コレクションも含めてセットアップして」
「ansible-dev-tools（ADT）がインストールされているか確認して」

対応している OS とパッケージマネージャー：

OS	使われるパッケージマネージャー
macOS	Homebrew（`brew`）
Fedora / RHEL / CentOS	`dnf`
Ubuntu / Debian	`apt`
Arch Linux	`pacman`

注意点： amazon.aws のようなコレクション名は requirements.txt（Python パッケージ用）ではなく、コレクション専用のパラメーターで指定する必要があります。Bob に頼む場合は「コレクションも含めて」と伝えるだけで適切に処理してくれます。

実際に試してみた：`ade_setup_environment` で venv を構築

「ade_setup_environment で環境設定をお願い」と頼んだところ、MCP ツールが内部でワークスペースのルートを /（システムルート）と誤認識し、仮想環境の作成に失敗しました。

Failed to create virtual environment
Error: [Errno 30] Read-only file system: '/venv'

このケースでは Bob が自動でフォールバックし、ターミナルコマンドで同等のセットアップを実施しました。

# Python と pip のバージョン確認
python3 --version  # → Python 3.14.2
pip3 --version     # → pip 25.3

# venv を作成して ansible-dev-tools を一括インストール
python3 -m venv venv
source venv/bin/activate
pip install --upgrade pip ansible-dev-tools

インストール完了後、ansible --version で確認した結果：

ansible [core 2.21.3]
  python version = 3.14.2
  jinja version = 3.1.6
  pyyaml version = 6.0.3

インストールされたツール一覧（ansible-dev-tools 26.8.0 に含まれるもの）：

ツール	バージョン	用途
`ansible-core`	2.21.3	Ansible 本体
`ansible-lint`	26.8.0	Playbook の静的解析
`ansible-navigator`	26.8.0	Playbook の実行・ナビゲーション
`ansible-builder`	3.1.1	実行環境（EE）イメージのビルド
`ansible-creator`	26.8.0	Collection / Playbook 雛形生成
`molecule`	26.8.0	ロールのテスト
`pytest-ansible`	26.8.0	pytest との統合テスト
`tox-ansible`	26.8.0	tox による CI 自動化

次回からは source venv/bin/activate で有効化するだけで使えます。

`adt_check_env` の役割

adt_check_env は ADT がインストールされているかを確認し、なければ自動でインストールするツールです。ade_setup_environment が「ゼロから開発環境全体を構築する」ツールであるのに対し、adt_check_env は「ADT の有無だけを素早く確認・修復する」ことに特化しています。

比較項目	`ade_setup_environment`	`adt_check_env`
目的	開発環境の新規構築	ADT の存在確認と自動インストール
引数	OS・コレクション・Python バージョンなど多数	なし（引数不要）
実行コスト	重い（パッケージ・venv 一式を構築）	軽い（チェックのみ）
主な使いどころ	新規マシン・新規プロジェクト起動時	他ツールを使う前の前提確認

実際に試した結果：

新規プロジェクトの作成：`create_ansible_projects`

Ansible Collection や Playbook プロジェクトの雛形（ひな形）ファイル一式を自動生成します。

Ansible を本格的に使い始めると「Collection」という再利用可能なコンテンツのパッケージや、「Playbook プロジェクト」という標準的なディレクトリ構造が登場します。手作りすると漏れが出がちなファイル構成を、一度の指示で揃えられます。

Bob への頼み方：

「my_org.network_tools という名前で新しい Collection を作って」
「deploy_webapp という Playbook プロジェクトを作って」

生成される Collection の構造例：

ansible_collections/
└── my_org/
    └── network_tools/
        ├── README.md           ← ドキュメント
        ├── galaxy.yml          ← コレクションのメタ情報
        ├── plugins/            ← カスタムモジュールやプラグイン
        ├── roles/              ← ロール
        └── tests/              ← テスト

Execution Environment の定義：`define_and_build_execution_env`

Execution Environment（EE）とは、Ansible の実行に必要なツール・コレクション・Python ライブラリを一つのコンテナイメージにまとめたものです。「どのマシンで実行しても同じ結果になる」ことを保証するために使います。

この EE を定義するファイル execution-environment.yml を生成してくれます。

Bob への頼み方：

「amazon.aws と ansible.utils を含む EE を CentOS ベースで作って。タグは my-ee:latest で」
「boto3 と requests を pip に含めた EE の定義ファイルを作って」

指定できる主な内容：

項目	説明	指定例
ベースイメージ	EE の土台になるコンテナイメージ	`quay.io/centos/centos:stream10`
タグ	作成する EE イメージの名前	`my-ee:latest`
コレクション	含める Ansible コレクション	`amazon.aws`, `cisco.ios`
Python パッケージ	pip でインストールするライブラリ	`boto3`, `requests`
システムパッケージ	OS レベルで必要なパッケージ	`git`, `curl`

MCP サーバーありの場合、なしの場合の比較

Ansible MCP サーバーを Bob に接続すると、何が変わるのか。一言でいえば、「Ansible の文脈を Bob が最初から持った状態で会話が始まる」 という点です。

MCP サーバーなしでも Bob に Ansible の質問はできます。ただし、Bob が参照できるのは学習済みの一般的な知識のみです。プロジェクト固有の環境情報や、バージョンを指定したコレクション一覧、ローカルの Playbook ファイルの実態は把握していません。

MCP サーバーを接続すると、この状況が変わります。

カテゴリ	やりたいこと	❌ MCP なし	✅ MCP あり
哲学・設計思想	Ansible の設計思想を知りたい	一般的な説明しか得られない	`zen_of_ansible` が公式の 20 の格言を即返す
	「なぜこう書くのか」の根拠を示したい	Bob の解釈に依存し、ブレる	Ansible プロジェクト公式の言葉として引用できる
	設計思想をチームに共有したい	ドキュメントを別途検索して貼る必要がある	Bob に聞いてそのまま引用できる
推奨記載	変数・タスクの命名規則を確認したい	一般的な回答でバージョンや文脈によってブレる	`ansible_content_best_practices` が公式ガイドラインを返す
	YAML フォーマット規約を守りたい	「こうするといい」程度の提案にとどまる	Ansible 固有のフォーマット要件を具体的なルールで返す
	ロール構成のベストプラクティスを知りたい	記憶に頼った回答になる	トピック指定で該当箇所のガイドラインを即参照できる
ツール実行	Playbook を lint したい	「このコマンドを実行してください」と案内するだけ	`ansible_lint` で Bob が直接実行し、結果を解説する
	環境情報を確認したい	「`ansible --version` を実行してください」と案内するだけ	`ade_environment_info` でコレクション一覧まで含めて即取得
	環境を構築したい	手順を文章で説明するだけ。手を動かすのは自分	`ade_setup_environment` で OS を伝えるだけで実際にセットアップが走る
	プロジェクトの雛形を作りたい	ディレクトリ構成を説明するだけ。手動作業が必要	`create_ansible_projects` で雛形ファイル一式を自動生成

MCP サーバーなしの Bob は「Ansible を知っているアシスタント」です。質問には答えてくれますが、手を動かすのは自分です。

MCP サーバーありの Bob は「Ansible の公式情報に直接アクセスでき、ツールも実行できるアシスタント」になります。哲学を尋ねれば公式の言葉で返し、書き方を尋ねれば公式ガイドラインを示し、lint や環境構築も Bob が代わりに実行します。

「調べて → コマンドを叩いて → 結果を解釈する」という繰り返しが、「Bob に伝えて → 結果を受け取る」に変わります。

場面別：Bob への頼み方まとめ

こんなとき	Bob への一言
Playbook のコードを確認したい	「この Playbook を lint して問題点を教えて」
プレイブックを実行したい	「`site.yml` を実行して」
自分の環境を確認したい	「今の Ansible 環境を確認して」
新しくプロジェクトを始めたい	「`my_org.my_collection` という Collection を作って」
環境を一から整えたい	「macOS に Ansible 開発環境をセットアップして」
EE を作りたい	「amazon.aws を含む EE を CentOS ベースで定義して」
書き方に迷ったとき	「変数の命名規則のベストプラクティスを教えて」
Ansible らしい設計を知りたい	「Ansible の設計思想を教えて」

まとめ

Ansible MCP サーバーを Bob に登録する際に詰まりやすい 2 点（node のフルパス・cli.js --stdio）さえ押さえれば、VSCode を起動せずに Bob から直接 Ansible のツール群を呼び出せます。

接続後に使えるツールを通じて、Bob は Ansible の開発作業を直接サポートします。

コードチェック・実行 はツールを呼び出すだけでなく、結果の解説もしてくれます
環境構築・プロジェクト作成 は OS の違いや構成の細かい知識がなくても進められます
ベストプラクティス参照 はドキュメントを検索する手間を省いてくれます

「ターミナルで何のコマンドを叩くか」を考える時間を減らし、Ansible でやりたいこと本来の作業に集中できるようになります。

参考リンク

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up

IBM Bob で Ansible MCP サーバー (VSCode 拡張) を試してみました

はじめに

動画

環境情報

Bob への依頼： 設定ドキュメントの URL を渡して依頼

使ったプロンプト

Bob が自動で行った処理

全体アーキテクチャ

VSCode Extension の MCP サーバーが Bob でも動く理由

設定手順

1. Extension のパスを確認する

2. MCP 設定ファイルの場所を決める

3. 設定を記述する

接続できない場合のトラブルシューティング

原因 1：node のフルパスを指定していない

原因 2：server.js を指定している

修正内容まとめ

動作確認

接続後に使えるツール

Ansible の設計思想：zen_of_ansible

実際に試してみた：zen_of_ansible の実行結果

ベストプラクティスの参照：ansible_content_best_practices

実際に試してみた：ansible_content_best_practices の実行結果

実際に試してみた：Playbook 作成 + ベストプラクティスレビュー

ツール一覧の確認：list_available_tools

コードの品質チェック：ansible_lint

実際に試してみた：既存 Playbook に対して lint を実行

プレイブックの実行：ansible_navigator

環境の確認：ade_environment_info

実際に試してみた：ade_environment_info の実行結果

開発環境のセットアップ：ade_setup_environment と adt_check_env

実際に試してみた：ade_setup_environment で venv を構築

adt_check_env の役割

新規プロジェクトの作成：create_ansible_projects

Execution Environment の定義：define_and_build_execution_env

MCP サーバーありの場合、なしの場合の比較

場面別：Bob への頼み方まとめ

まとめ

参考リンク

Bob への依頼：設定ドキュメントの URL を渡して依頼

原因 1：`node` のフルパスを指定していない

原因 2：`server.js` を指定している

Ansible の設計思想：`zen_of_ansible`

実際に試してみた：`zen_of_ansible` の実行結果

ベストプラクティスの参照：`ansible_content_best_practices`

実際に試してみた：`ansible_content_best_practices` の実行結果

ツール一覧の確認：`list_available_tools`

コードの品質チェック：`ansible_lint`

プレイブックの実行：`ansible_navigator`

環境の確認：`ade_environment_info`

実際に試してみた：`ade_environment_info` の実行結果

開発環境のセットアップ：`ade_setup_environment` と `adt_check_env`

実際に試してみた：`ade_setup_environment` で venv を構築

`adt_check_env` の役割

新規プロジェクトの作成：`create_ansible_projects`

Execution Environment の定義：`define_and_build_execution_env`