1. はじめに
「Ansible と AI」といえば、Playbook を生成したり、ドキュメントを生成したりできる「Ansible Lightspeed with IBM watsonx Code Assistant」が先駆け的な存在で登場しました。
最近は、それだけでなくAAP(Ansible Automation Platform) を自然言語で操作できる AAP MCP サーバーが登場しました。現状は Technology preview 扱いです。
「自然言語で AAP を操作」というと、「Ansible Lightspeed intelligent assistant」を思い浮かべるかもしれませんが、本記事で紹介するものとは別物です（裏で AAP MCP サーバーが動いてるのかもしれませんが）。「Ansible Lightspeed intelligent assistant」は AAP の画面にチャットウィンドウとして統合されているのに対して、「AAP MCP サーバー」はあくまで MCP サーバー単体です。ややこしいですが、Ansible Development Tools MCP Server とも別物です。
今回、AAP 本体と合わせて AAP MCP サーバー も構築して、ちょっと試してみたので、まとめます。
- 環境
- AAP 2.6 コンテナ版 オンラインインストーラー
- 最終更新 2025-12-10、ファイル名
ansible-automation-platform-containerized-setup-2.6-4.tar.gz - 実際はバンドル版でもOK
- 最終更新 2025-12-10、ファイル名
- RHEL9
- AAP 2.6 コンテナ版 オンラインインストーラー
なお、YouTube の The Ansible Playbook チャンネルでは、5つのユースケースが動画で紹介されています。動画なのでイメージがつきやすくておすすめです。
（本記事を書いてる途中で上記動画に気が付きました）
※ 用語のついて補足:
ドキュメントでは「AAP MCP server」ではなく「Ansible MCP server」という表記になっています。実態としては AAP を操作できるものであり、前述の動画でも「Ansible Automation Platform MCP Server」と表現されています。そのため本記事では「AAP MCP サーバー」と表記にします。
ご注意
繰り返しになりますが、AAP MCP サーバーは 2026年1月現在 Technology preview 扱いのため、まだ本番運用には向いていません。今後、手順や仕様も変更される可能性があります。また、本記事は、できることを探ったりする検証のため、権限をゆるくしています。本記事はあくまで私の環境でこうやってこうなった、と記録した趣旨であることをご了承ください。（本ブログの大抵の記事はそんな感じです）
2. 概要: AAP MCP サーバーで何できる？
「AAP を自然言語で操作」といっても、さまざまなことを連想します。
AAP の公式ドキュメントに、ツールセットの一覧があり、使い道の例も掲載されています。
私なりにまとめるとツールセットは以下のとおりです。ちょっとまだ私の理解がふわっとしています。
| ツールセット名 | できることの例 |
|---|---|
| Job management | ジョブテンプレートの起動や、実行ログの収集 |
| Inventory management | インベントリ上の、ホスト、グループの管理 |
| System monitoring | ログの収集やシステム状態のチェック |
| User management | ユーザー、チームの管理 |
| Security/compliance | 認証情報 |
| Platform configuration | システム設定 |
3. 準備
AAP 本体をインストールするときに、一緒に AAP MCP サーバーもデプロイできます。今回は手っ取り早く、1つの VM にすべてのコンテナをデプロイします。
通常よりもコンポーネントが多くなり「今やってる作業がどこの何なのか？」が分かりにくくなるため、手順の前に全体構成の説明をします。
上図に記載しているポート番号はデフォルトの場合のものです。今回はこのポート番号の前提で作業を進めます。
443 で待ち受ける Platform Gateway がいつもどおりと言うか、ここが本記事で AAP 本体と呼んでいる箇所です。（コンテナ単位で図示するともっと多いですが、単純化しています）
AAP MCP サーバーは 8448 で待ち受けます。今回はすべてのコンテナを 1つの VM にデプロイするので、ポート番号が被らないようにする必要があります。こういう経緯もあってデフォルトの 8448 を利用します。
インストール
基本的に 公式ドキュメントの以下のドキュメントを混ぜたような手順で進めます。
- 基本的な準備: Chapter 4. Preparing the containerized Ansible Automation Platform installation
- AAP MCP サーバー固有: Chapter 7. Deploying AAP MCP server on Ansible Automation Platform
- インストール: Chapter 8. Installing containerized Ansible Automation Platform
AAP 2.5 以降のコンテ版をインストールした経験がある方に説明しますと、主な差分はインベントリファイルの [ansiblemcp] グループにホストを追加する程度です（Chapter 7. Deploying AAP MCP server on Ansible Automation Platformどおり）。試してはいませんが、おそらく既存の AAP にあとから追加する流れでもできるのではないかと思います。
必要パッケージのインストール
RHEL 9 系に AAP 2.6 コンテナ版をインストールするには ansible-core 2.14 が要件になっていますので、インストールします。
sudo dnf install ansible-core
関連公式ドキュメント:
インストーラーのダウンロード
インストーラーを Red Hat のサイトからダウンロードして、インストール先の AAP サーバーに配置します。
今回はインストーラーとして「Ansible Automation Platform 2.6 Containerized Setup」（最終更新 2025-12-10、ファイル名 ansible-automation-platform-containerized-setup-2.6-4.tar.gz）を利用します。
続いて、解凍してディレクトリを移動します。
tar xzf ansible-automation-platform-containerized-setup-2.6-4.tar.gz
cd ansible-automation-platform-containerized-setup-2.6-4
関連公式ドキュメント: - 4.5. Downloading Ansible Automation Platform
インストール用インベントリファイルの準備
今回は構成をなるべくシンプルにするため、Automation Controller と Platform Gateway と MCP サーバーのみの構成にします。EDA や Automation Hub は省略します。
以下のようなインベントリを準備しました。ファイル名は inventory_with_mcp.ini とします。
# This section is for your AAP Gateway host(s) # ----------------------------------------------------- [automationgateway] aap26.sakana.local # This section is for your AAP Controller host(s) # ----------------------------------------------------- [automationcontroller] aap26.sakana.local # This section is for your Ansible MCP Server host(s) # ----------------------------------------------------- [ansiblemcp] aap26.sakana.local # This section is for the AAP database # ----------------------------------------------------- [database] aap26.sakana.local [all:vars] # Ansible ansible_connection=local # MCP Settings mcp_allow_write_operations=true # Common variables # https://docs.redhat.com/en/documentation/red_hat_ansible_automation_platform/2.6/html/containerized_installation/appendix-inventory-files-vars#ref-general-inventory-variables # ----------------------------------------------------- postgresql_admin_username=postgres postgresql_admin_password=<パスワード> registry_username=<コンテナレジストリ用Red Hat アカウント> registry_password=<パスワード> redis_mode=standalone # AAP Gateway # https://docs.redhat.com/en/documentation/red_hat_ansible_automation_platform/2.6/html/containerized_installation/appendix-inventory-files-vars#ref-gateway-variables # ----------------------------------------------------- gateway_admin_password=<パスワード> gateway_pg_host=aap26.sakana.local gateway_pg_password=<パスワード> # AAP Controller # https://docs.redhat.com/en/documentation/red_hat_ansible_automation_platform/2.6/html/containerized_installation/appendix-inventory-files-vars#ref-controller-variables # ----------------------------------------------------- controller_admin_password=<パスワード> controller_pg_host=aap26.sakana.local controller_pg_password=<パスワード> controller_percent_memory_capacity=0.5
AAP MCP サーバー固有のポイントは以下のとおりです。
[ansiblemcp]にデプロイ先ホストを指定- 変数
mcp_allow_write_operationsをtrueに指定
なお、証明書検証を無視したい場合は、さらに [all:vars] セクションに mcp_ignore_certificate_errors=true を追加します。詳細はドキュメントを参照してください。
関連公式ドキュメント:
- 4.6. Configuring the inventory file
- 7.2. Deploying an AAP MCP server on a container-based installation
- B.12. AAP MCP server variables
インストール Playbook の実行 （図中のA）
インストール用の Playbook を実行して、しばらく待ちます。
ansible-playbook -i inventory_with_mcp.ini ansible.containerized_installer.install
AAP 本体はすぐあとで GUI を開くのでよいとして、AAP MCP サーバー側の簡単な状態確認をします。
Web ブラウザから https://<AAP>:8448/api/v1/health を開いて、以下のレスポンスが返ってくることを確認します。
{"status":"ok"}
大丈夫そうです。
この確認手順は AAP としてのドキュメントに載っていませんが、ansible/aap-mcp-server というリポジトリの Health Monitoring の方法を参考に試したらこうなった、というレベルです（あやふや）。これでどこまでの確認ができたことになるのかは不明ですが、少なくとも AAP 本体（厳密には Platform Gateway）とは異なるポート 8448 への疎通は OK です。
ちなみに podman ps の結果は以下のとおりでした。
$ podman ps ONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 036dc2d14606 registry.redhat.io/rhel9/postgresql-15:latest run-postgresql 6 hours ago Up 37 minutes 5432/tcp postgresql 7f9007643375 registry.redhat.io/rhel9/redis-6:latest run-redis 6 hours ago Up 37 minutes 6379/tcp redis-unix 9f15eb4630bb registry.redhat.io/rhel9/redis-6:latest run-redis 6 hours ago Up 37 minutes 6379/tcp redis-tcp 19352dc9ec3e registry.redhat.io/ansible-automation-platform-26/receptor-rhel9:latest /usr/bin/receptor... 6 hours ago Up 37 minutes receptor 53e011b2ef53 registry.redhat.io/ansible-automation-platform-26/controller-rhel9:latest /usr/bin/launch_a... 6 hours ago Up 37 minutes 8052/tcp automation-controller-rsyslog b6bc635159d8 registry.redhat.io/ansible-automation-platform-26/controller-rhel9:latest /usr/bin/launch_a... 6 hours ago Up 37 minutes 8052/tcp automation-controller-task 11123fd4be2a registry.redhat.io/ansible-automation-platform-26/controller-rhel9:latest /usr/bin/launch_a... 6 hours ago Up 37 minutes 8052/tcp automation-controller-web 812971cb08b8 registry.redhat.io/ansible-automation-platform-26/gateway-proxy-rhel9:latest /usr/bin/envoy --... 5 hours ago Up 37 minutes automation-gateway-proxy 77a50b23c25e registry.redhat.io/ansible-automation-platform-26/gateway-rhel9:latest /usr/bin/supervis... 5 hours ago Up 37 minutes automation-gateway 751b06a66f4a registry.redhat.io/ansible-automation-platform-tech-preview/mcp-server-rhel9:latest /entrypoint.sh 4 hours ago Up 37 minutes 8080/tcp, 8086/tcp ansiblemcp
registry.redhat.io/ansible-automation-platform-tech-preview/mcp-server-rhel9:latest というイメージ名がみえますね。今回タイミングの latest は 2.6.20251210-2 を指しているようでした。
インストール番外編
AAP のインストーラーではなく、検証で ansible/aap-mcp-server ローカルで動かすという方法もあります。既存の AAP の環境をなるべく触らずに気軽に試すには良いかもしれません。
（本記事はあくまでも AAP のインストーラーを前提にしています）
AAP の API Token を作成 （図中のB）
ここまでで、AAP MCP サーバーを含む AAP をデプロイできました。
引き続き AAP MCP サーバーを利用するための準備を進めます。具体的には、あとで VS Code 側の mcp.json に指定する必要あるための、AAP の API トークンを作成します。MCP サーバー経由で操作したい権限のユーザーのものです。
今回は検証環境での検証目的のため、極めて緩い admin の Write 権限にします。
AAP に admin でログインして、ライセンス適用を済ませます。
続いて、左メニューの [Access Management] 配下の [ユーザー] を開いて、対象のユーザー（今回は admin）を選択します。
続いて、[API Token] タブを開きます。
[Create API token] ボタンをクリックし、以下の情報を入力し [Create token] ボタンをクリックします。
- 説明:
MCP Server(任意、分かりやすい自分向けの説明) - OAuth application: （空ののまま）
- Scope:
Write(検証のために緩く)
このときに限りトークンが表示されるので、コピーしてどこかに控えておきます。
AAP 本体側の設定は以上です。
関連公式ドキュメント:
mcp.json の設定(図中のC)
今回は Visual Studio Code 上の GitHub Copilot を利用し、ワークスペース単位で設定します。
公式ドキュメントの mcp.json のサンプルを参考にして .vscode/mcp.json を作成します。
サンプルからのカスタマイズポイントは以下のとおりです。
- VS Code 側の仕様に合わせて、一番トップのキーは
mcpServersではなくserversにする - 各
urlは今回デプロイした AAP MCP サーバーのFQDN:ポートにする。AAP 本体ではないのでご注意 AuthorizationヘッダーのBearerの後に、作成済みの AAP の API トークンを指定する- べた書きは避けたいので今回は
inputs経由で値を渡す（対策はお好み方法で）
- べた書きは避けたいので今回は
{ "inputs": [ { "type": "promptString", "id": "aap-api-token", "description": "AAP API Token", "password": true } ], "servers": { "aap-mcp-inventory-management": { "type": "http", "url": "https://<AAP>:8448/mcp/inventory_management", "headers": { "Authorization": "Bearer ${input:aap-api-token}" } }, "aap-mcp-job-management": { "type": "http", "url": "https://<AAP>:8448/job_management/mcp", "headers": { "Authorization": "Bearer ${input:aap-api-token}" } }, "aap-mcp-system-monitoring": { "type": "http", "url": "https://<AAP>:8448/system_monitoring/mcp", "headers": { "Authorization": "Bearer ${input:aap-api-token}" } }, "aap-mcp-user-management": { "type": "http", "url": "https://<AAP>:8448/user_management/mcp", "headers": { "Authorization": "Bearer ${input:aap-api-token}" } }, "aap-mcp-security-compliance": { "type": "http", "url": "https://<AAP>:8448/security_compliance/mcp", "headers": { "Authorization": "Bearer ${input:aap-api-token}" } }, "aap-mcp-platform-configuration": { "type": "http", "url": "https://<AAP>:8448/platform_configuration/mcp", "headers": { "Authorization": "Bearer ${input:aap-api-token}" } } } }
なお、GitHub リポジトリ ansible/aap-mcp-server の README.md では、ツールセット指定の MCP Endpointは /mcp/{toolset} と記載されていました。AAP のドキュメントだと {toolset}/mcp なので逆です。少し試した限りではどちらでも良いように見えました。
mcp.json の設定ができたら起動します。あまり効率が良くないかもしれませんが、今回はおためしで6つすべて起動してしまいます。（起動するツールが多すぎるというメッセージが表示されるので、実際はオンオフを切り替えた方が良いかもです）
今回は inputs で "type": "promptString" を指定しているので、以下のように VS Code 画面上部に入力プロンプトが表示されるので、作成済みで控えておいた AAP API トークンを入力します。
以下のような表示になれば、起動が成功したことがわかります。
エラーの場合は「エラー」となります（後述の「補足: エラー集」参照）。
関連公式ドキュメント:
ここまでで、各種準備ができました。
4. おためし
いよいよ、いろいろ指示して試してみます。プロンプト自体はあまり参考にならないと思いますが・・。
モードは Agent、モデルは Auto で試します。
参照系
安全、かつ手軽に試せそうな参照系の操作をします。
インベントリーの参照
ツールセットに「Inventory management」とあったので、手っ取り早く試せそうなインベントリー情報を参照してみます。
AAP から既存のインベントリーからホスト一覧を表示してください
途中、操作の許可が求められたら内容を確認して許可します。
こんな結果になりました。
localhost はデフォルトであるもの。ios01 は手動で作成しておいたもので、意図的にエラーになるジョブを実行済みなので、最終ジョブが「失敗」となってるのも正解です。
ジョブ実行エラーの調査
あらかじめ、エラーのジョブ実行ログを残しておき、その調査をお願いしてみました。
AAPで直近でエラーになったジョブの、エラーの原因と解決策を教えてください
良い感じです。確かに ios01 は名前解決できず、ansible_host 変数の指定もないため、指摘の内容は妥当です。
エラーの傾向の調査
引き続きトラブルシューティング系です。
今度は直近のエラーではなく、ある程度遡ってもらうことを前提に傾向を調べてもらいました。
AAP上で、最近のジョブのエラーの傾向を教えてください
もっとジョブが多いと、興味深い回答になりそうです。
自動化対象になっていないホストの一覧
あらかじめ ios99 というホストを作成し、自動化履歴がない状態（成功、失敗問わず）で、以下のことを聞いてみました。
AAP上で、直近一ヶ月で自動化対象になってないホストを教えて
このくらいであれば API リクエストを含むちょっとしたスクリプトでも良さそうですが。
プロンプトの言い回しが微妙でしたね。ただ、「新規追加したがジョブ未実行のホスト（例：ios99など）」は挙げられているので、少し意図したことは聞けました。
設定系
今度は設定や実行など、副作用のある操作を試します。
ジョブテンプレートの実行
シンプルにジョブテンプレートの実行をお願いしてみます。
AAP 上のジョブテンプレート Demo Job Template を実行して、結果のサマリーを表示してください。
結果は以下のとおりです。
おおっと思ったのは「ジョブがまだ実行中です。完了するまで待機してから、ホスト別のサマリーを取得します。」のところです。API の仕様上、ジョブテンプレートの実行は非同期です。「結果のサマリーを表示してください」まで指定したので、非同期処理をちゃんと待ってくれています。
念のため AAP の画面上で実行結果を確認したら、ちゃんと成功していました。
意図通りにできなかったこと
頼み方の改善の余地が大いにあるということだと思うのですが、今回の頼み方では以下のことはできませんでした。
ワークフローの Mermaid 化（実現ならず）
ワークフロージョブテンプレートのワークフロービジュアライザーで見れるノードのつながりを、Mermaid の書式で再現できたらいいなと思いました。ドキュメントとして残しておくために。
しかし、今回の頼み方では、ワークフロージョブテンプレートを一度実行してから、その結果からノードの情報を取得していました。意図としては、実行せずにノードの定義情報を読み取ってほしかったところですが、うまく伝えられませんでした。
AAP 上の ワークフロージョブテンプレート `wf01` の関連づいているノードを取得し、ワークフロービジュアライザー上で確認できるようなノードのつながりを、Mermaid の書式でつくってください
途中、
テンプレートを実行してから、実行ジョブのノード情報を取得します。
とあり、実行しようとしていることがあります。AAP の画面で確認しても実行されていました。実際は、許可するかどうかの確認のワンクッションがありましたが、今回は様子を見るためにあえて許可しました。
（もしかしたら現在の MCP サーバーの仕様では、実行後ジョブからはノード情報を取得できても、ワークフロージョブテンプレート定義からは取得できない、ってことなのかもしれません）
結果的に、手元にwf01_visualization.md というファイル名で以下の内容でファイルが作成されました。
クリックして開く
# AAP ワークフロージョブテンプレート `wf01` の構成 ## ワークフロー構成図 ワークフロージョブテンプレート `wf01` のノード関係を Mermaid で表現した図：
graph TD
Node3["ノード 3
Demo Job Template
(Status: successful)"]
Node1["ノード 1
Demo Job Template
(Status: running)"]
Node2["ノード 2
Demo Job Template
(Status: pending)"]
Node3 -->|always| Node1
Node3 -->|always| Node2
style Node3 fill:#90EE90
style Node1 fill:#87CEEB
style Node2 fill:#FFD700
## ノード詳細情報 ### ノード 3 (開始ノード) - **テンプレート**: Demo Job Template (ID: 7) - **ジョブ ID**: 9 - **ステータス**: successful - **実行時間**: 7.222秒 - **遷移**: 常に（always）ノード 1 と ノード 2 へ進行 - **属性**: `all_parents_must_converge: false` ### ノード 1 - **テンプレート**: Demo Job Template (ID: 7) - **ジョブ ID**: 10 - **ステータス**: running - **実行時間**: 0秒 - **遷移**: なし（ワークフロー終了） - **属性**: `all_parents_must_converge: false` ### ノード 2 - **テンプレート**: Demo Job Template (ID: 7) - **ジョブ ID**: 11 - **ステータス**: pending - **実行時間**: 0秒 - **遷移**: なし（ワークフロー終了） - **属性**: `all_parents_must_converge: false` ## ワークフロー実行フロー
sequenceDiagram
participant Start as ノード 3
開始
participant N1 as ノード 1
participant N2 as ノード 2
Start->>N1: always（無条件）
Start->>N2: always（無条件）
Note over N1: 実行中
Note over N2: 保留中
## API 情報 - **ワークフロージョブテンプレート ID**: 8 - **ワークフロージョブテンプレート名**: wf01 - **ワークフロー実行 ID**: 8 - **ノード数**: 3 ## 備考 - ノード 3 の `always_nodes` フィールドに `[1, 2]` が指定されており、ノード 3 の実行完了後、常にノード 1 と 2 が並行実行されます - ノード 1 と 2 に親の収束条件は設定されていません（`all_parents_must_converge: false`） - 各ノードは同じジョブテンプレート（Demo Job Template）を参照しています
2箇所 Mermaid の書式が出てきます。それぞれのレンダリング結果は以下のとおりです。
上の方にある「ワークフロー構成図」
下の方にある「ワークフロー実行フロー」 うん・・？
なお、AAP のワークフロービジュアライザー上の表示は以下のとおりです。これを再現したかった、という話です。
補足: エラー集
試行錯誤中に遭遇したエラーと対応についてです。
TypeError: fetch failed
VS Code から MCP サーバーへの疎通性がない状態では、VS Code の [出力] パネルで以下のエラーが発生しました。 （あまりきれいに切り分けできていませんが、証明書検証が失敗する場合でもこのエラーになるかもです。）
2026-01-22 10:12:23.954 [info] 接続状態: エラー Error sending message to https://<AAP>:8448/mcp/inventory_management: TypeError: fetch failed
正しく疎通が取れるようにして対策します。
トークン誤りの場合
mcp.json に指定する AAP API トークンが誤っているときは以下のエラーが表示されました。
2026-01-22 10:55:05.667 [info] 400 status sending message to https://48.218.140.169:8448/mcp/inventory_management, will attempt to fall back to legacy SSE 2026-01-22 10:55:05.737 [info] 接続状態: エラー 404 status connecting to https://48.218.140.169:8448/mcp/inventory_management as SSE: Session not found
ほかにも、7.5. Troubleshooting Ansible MCP server errors というページにトラブルシューティングがまとまっているので参考になります。
※ 本記事とは関係ないですが、最近は IP アドレスベースで証明書が作成できるようになったみたいですね
5. 感想・おわりに
ということで、自然言語で AAP を操作することをいくつか試してみました。
設定や実行よりも、むしろ参照系の操作のほうが活用のシーンはあるかもしれない、と今のところは思っています。とってきた情報をいろいろと加工できるためです。
もちろん「API を叩く処理を作りこめば普通に実現できる話だ」という見方もあります。しかし、作りこまなくても自然言語で、かつ、実現したい人が今その場で操作できる、というのが一つのポイントかなと感じました。操作の性質によるのが大前提ですが。
たとえばトラブルシューティングの場面では、エスカレーションすることなくオペレーター側で原因を解消、または切り分けを進められるような。
また、今回は権限をゆるくしたことと頼み方のイマイチさによって、意図せずワークフロージョブテンプレートが実行されてしまいした。頼み方（プロンプト）は制御しにくいと思うので、改めて権限を適切に管理、設定することの重要さを感じました。
現状は Technology preview 扱いであるものの、活用の幅は広そうだと感じるモノでした。引き続き情報をウォッチしていきたいと思います。
