Ansible MCPサーバーでAutomation Platformの自動化をClaudeに任せる

Ansible MCPとは何か

Ansible MCPは、Red Hat Ansible Automation Platform(AAP)2.6以降に含まれる公式のMCPサーバーです。AAPのMCPサーバーは、Model Context Protocol経由でAAPとClaudeなどの外部AIツールをつなぐ標準インターフェースです。使い始めるには、管理者がサーバーを立てて読み取り専用か読み書きかを決め、利用者がAPIトークンで接続します。自動化ジョブの起動、インベントリの照会、監査ログの確認といった操作を、AAPの管理画面を開かずに自然言語のチャットから実行できます。

2026年2月2日のRed Hatのブログで、AAP 2.6.4のテクノロジープレビューとして紹介されました。2026年6月3日のリリースからは、AAP 2.6以降で正式サポート(GA)になっています。検証記事や古いブログには「テクノロジープレビュー」と書かれたものが残っているので、読む前に版を見分けておくと混乱しません。

デプロイ先は、コンテナ化インストールとOperatorベースのOpenShiftインストールの2種類です。コンテナ化インストールはRHEL 9(9.6以降)またはRHEL 10のホストが対象です。OperatorベースのインストールはOpenShift Container Platform 4.14〜4.22が対象です(AAP 2.6のライフサイクル表)。

要求の流れは、公式ドキュメントでは次のように説明されています。ユーザーがAIクライアントに依頼し、AIモデルが意図を読んで適切なツールセットを呼びます。MCPサーバーが検証したうえでユーザーのAPIトークンでコントローラーに指示を渡し、結果をAIクライアント向けの形式に直して返します。

使えるツールセット

ツールセットは次の7つです。2026年2月のブログでは6つと紹介されていましたが、現行のドキュメントではcontent_discoveryを加えた7つです。

content_discoveryでは、組織のインテリジェントアシスタントに「Bring your own knowledge」を有効にしている場合に限り、社内の運用手順やポリシーについてもAIエージェント経由で質問できます。

導入は3人の役割に分かれる

導入の手順は、作業する人ごとに分かれています。自分がどの段階を担当するのかを先に見分けると、読む節が絞れます。

ステップ1: 管理者がMCPサーバーをデプロイする

コンテナ化インストールでは、インベントリファイルに[ansiblemcp]グループを追加してMCPサーバーのホストを指定し、[all:vars]に権限設定を書きます。

[ansiblemcp]
aap.example.com
 
[all:vars]
mcp_allow_write_operations=false
mcp_ignore_certificate_errors=false
mcp_tls_cert=<TLS証明書のパス>
mcp_tls_key=<TLS秘密鍵のパス>
mcp_extra_settings='[{"setting": "DEFAULT_PAGE_SIZE", "value": "25"}]'

mcp_allow_write_operationsをtrueにすると読み書き両方を許可します。デフォルトはfalse(読み取り専用)です。mcp_extra_settingsのDEFAULT_PAGE_SIZEは、一覧系APIの1ページあたりの件数を上書きする設定です。インストール後は次のコマンドでPodの起動を確認します。

podman ps

ansiblemcpのPodが動いていれば成功で、MCPサーバーのURLはホストの8448番ポートにHTTPSで公開されたhttps://<ホスト名>:8448になります。

OpenShift上のOperatorベースインストールでは、Ansible Automation Platformのカスタムリソースにmcpコンポーネントを追加します。

spec:
  mcp:
    disabled: false
    allow_write_operations: false

作成後は、OpenShiftコンソールの「Workloads」→「Deployments」にデプロイが出ていること、Podのログにエラーが無いことを確認します。接続先のURLは「Networking」→「Routes」で、MCPサーバー用のデプロイ(例: aap-mcp)のLocationをコピーして得ます。

コンテナ化のmcp_extra_settingsに相当する設定は、Operatorではspec.mcp.extra_settingsのリストで渡します。保存するとMCPサーバーのPodが再起動して反映されます。

spec:
  mcp:
    disabled: false
    allow_write_operations: false
    extra_settings:
      - setting: DEFAULT_PAGE_SIZE
        value: "25"

権限を作成後に変えたいときは、AnsibleMCPServerカスタムリソースをいったん削除して再作成します。名前の末尾が-mcpのものが稼働中のインスタンスで、削除後に調整処理が完了すると新しいインスタンスが作られます。設定の書き換えだけでは権限は変わりません。

ステップ2: 認証方式を選んでトークンを用意する

AAPのMCPサーバーは個人アクセストークン(PAT)とOAuthの2方式に対応しますが、どちらを選ぶかはAIクライアント側の条件で決まります。

AAP 2.6にはOIDCの自動検出がありません。自動検出を前提にするClaude CodeやCursorはOAuthを使えず、PATを使うよう公式に書かれています。手動のエンドポイント設定に対応するクライアントとしては、Gemini CLIが公式の例に挙がっています。

OAuthを使うクライアント向けの設定値は、次のとおりです。ゲートウェイ側でAuthorization grant typeを「Authorization code」にしたOAuthアプリケーションを作り、そのクライアントIDを使います。

Redirect URIsにはMCPクライアントのコールバックURLを登録し、Confidentialを選んだ場合はクライアントシークレットも控えます。AAP 2.6ではPKCEは強制されません。クライアントがシークレットを安全に保管できるなら「Confidential」、できないなら「Public」を選びます。

Claude Codeで使うPATの発行手順は次のとおりです。

1. AAPの管理画面で「Access Management」→「Users」から自分のユーザーを開く
2. 「Tokens」タブで「Create token」をクリック
3. Scopeを選ぶ(Write: 追加・編集・削除まで許可 / Read: 参照のみ。Writeを選んでもRead相当の操作は含まれる)
4. Applicationは空欄のままにするとアプリケーションに紐付かないPATになる
5. トークンは発行画面で一度しか表示されないため、その場でコピーして保存する

Scopeの選択は、ステップ1のサーバー全体の権限と組み合わさって最終的な操作範囲が決まります。どちらか一方を緩めても、もう一方が制限していれば操作は通りません。

ステップ3: Claudeに接続する

接続先はmcp.jsonに書きます。エンドポイントは3通りあり、ツールの読み込み量と制御のしやすさが変わります。

トークン消費を抑えたい場合の既定は/mcp/discoverです。設定例は次のとおりです。

{
  "mcpServers": {
    "aap-mcp": {
      "type": "http",
      "url": "https://aap.example.com:8448/mcp/discover",
      "headers": {
        "Authorization": "Bearer ${env:AAP_MCP_TOKEN}"
      }
    }
  }
}

ツールセットを絞る場合は、/mcp/<toolset>ごとに別のサーバー名で定義します。

{
  "mcpServers": {
    "aap-mcp-job-mgmt": {
      "type": "http",
      "url": "https://aap.example.com:8448/mcp/job_management",
      "headers": { "Authorization": "Bearer ${env:AAP_MCP_TOKEN}" }
    },
    "aap-mcp-inventory-mgmt": {
      "type": "http",
      "url": "https://aap.example.com:8448/mcp/inventory_management",
      "headers": { "Authorization": "Bearer ${env:AAP_MCP_TOKEN}" }
    }
  }
}

サーバー名は20文字程度に収めます。AIエージェントはMCPサーバー名とツール名を結合して識別子を作るため、多くのエージェントでは結合後64文字までという制限があります。

接続後は、「What MCP tools are available for my Ansible Automation Platform?」のように尋ねます。有効なツールの一覧が返れば疎通できています。

権限は二層で決まる

MCPサーバーの権限は、サーバー全体の設定とユーザーのトークンの二層です。サーバー全体を組織管理者が決め、そのうえで各ユーザーのAPIトークンが持つAAPのRBAC権限が適用されます。

読み取り専用のサーバー設定は、ユーザー個人に書き込み権限があっても上書きされます。ジョブ実行やAAP側の変更を防ぐ、全体の安全装置です。

ユーザーのトークンに権限がない操作をAIエージェントが試みると、AAPのAPIがリクエストを拒否します。MCPサーバーはその拒否結果をそのままクライアントへ返します。公式の例では、トークンが「network」インベントリしか見られないなら、依頼されても「database」インベントリには届きません。

この「まずサーバー全体を読み取り専用にして、必要な範囲だけ書き込みを許可する」設計は、Kubernetes MCPサーバーの権限設計で扱ったクラスタ向けの考え方と同じ型です。

書き込みを許可するかどうかは、慎重に決めます。公式ドキュメントも、読み書き権限ではAIエージェントの誤解釈や存在しないコマンドの生成によって、意図しない変更が入るリスクがあると警告しています。ジョブテンプレートの起動のように取り消しにくい操作を任せる前に、読み取り専用のまま動作を確認する段階を挟むという選択肢があります。

よくあるつまずき

症状から原因を探せるように、トラブルシューティングの内容を症状別に並べます。

証明書まわりの2件は、対処の手順が公式に載っています。

OpenShiftでSELF_SIGNED_CERT_IN_CHAINが出る場合は、まずCA証明書を含むSecretを作ります。

oc create secret generic <secret_name> \
  --from-file=bundle-ca.crt=<ca_cert_file> \
  -n <namespace>

そのうえでAnsibleMCPServerカスタムリソースにbundle_cacert_secretでSecret名を指定します。Operatorが証明書をマウントしてCAバンドルに加え、Podを再デプロイします。解消の確認には、PodのログにSSLのエラーが無いことと、初期化コンテナのログに「Added customer CA bundle」があることを使います。

400エラーの対処は、デプロイ方式で書き方が変わります。コンテナ化ではmcp_ignore_certificate_errorsをtrueにします。Operatorではspec.mcp.extra_settingsにIGNORE_CERTIFICATE_ERRORSをtrueで追加します。ただしこれは検証を飛ばす設定なので、検証用途にとどめたほうが無難です。

406エラーは、AAP固有のものです。AAPはMCPサーバーからの要求がJSON形式でないと406を返すので、一度JSONで出力させ、必要な形式への変換はAIツール側に任せます。

外部LLMに渡る情報を見積もる

もうひとつのつまずきは、エラーとして現れません。Claudeなどの外部LLMプロバイダーを使うと、ツールの結果はすべてそのプロバイダーに送られ、会話のコンテキストに入ります。MCPサーバーは独自のフィルタをかけず、AAPのAPIが返す内容をそのまま渡します。

まず、守られる範囲です。パスワード、秘密鍵、Vault資格情報、SSH秘密鍵、資格情報システムに保存されたAPIトークンは、AAPのAPIがマスクして返すので平文では届きません。一方で、資格情報の名前・タイプ・ユーザー名はマスクされず、LLMプロバイダーに見えます。

次に、既定でフィルタされない運用データです。IPアドレス、DNS名、ホスト名、ネットワーク設定、ジョブの実行詳細、インベントリの構造と変数、プロジェクトやテンプレートの設定が該当します。

見落としやすいのは、資格情報システムの外に置いた秘密です。公式が「自動では保護されない」と挙げているのは次の項目です。

• インベントリ変数(ホスト変数・グループ変数)
• ジョブテンプレートのextra vars
• ジョブの出力とログ
• ワークフローの変数プロンプト
• サーベイの回答
• カスタムインベントリスクリプト

たとえばextra varsにパスワードを直書きしていると、ジョブログの取得でそのまま外部LLMへ渡ります。秘密はAAPの資格情報システムに寄せ、やむを得ず外に置く場合はRBACで見られる範囲を絞る、というのが公式の推奨です。

社内ポリシーで外部サービスへのインフラ情報の共有が制限されている場合は、有効にするツールセットとトークンのRBAC範囲を、導入前に洗い出します。

テレメトリは止められない

2026年1月21日のパッチリリース以降のAAPでは、MCPサーバーの性能や利用傾向に関する匿名化されたテレメトリがRed Hatへ自動で収集されます。この収集は無効化できません。ユーザー名やパスワードなどの個人情報は収集対象ではなく、誤って受信した場合は削除されると公式に書かれています。

まとめ

導入前に決めることは、デプロイ方式、サーバー権限(読み取り専用か読み書きか)、接続先エンドポイントの3点です。Claude CodeではOAuthが使えないためPATで接続し、外部LLMに渡る運用データの範囲は導入前に洗い出します。

IT自動化以外の業務システムをClaudeにつなぐ選択肢を広く知りたい場合は、おすすめMCPサーバー10選で用途別の候補を一覧できます。Ansible自体をClaude Codeに書かせたい場合は、Claude CodeでAnsibleのPlaybookを書く手順も参考になります。