Claude Media
Ansible MCPサーバーでAutomation Platformの自動化をClaudeに任せる
Claude CodeMCPClaude連携チュートリアル

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

Red Hat Ansible Automation PlatformのMCPサーバーをデプロイし、Claudeから自然言語でジョブ実行やインベントリ照会を行う手順を解説します。

読了目安 約13分

Ansible Automation Platform MCPサーバーとは

Red Hat Ansible Automation Platform(AAP)のMCPサーバーは、Model Context Protocol経由でAAPとClaudeなどの外部AIツールをつなぐ標準インターフェースです。AAPの各コンポーネントと並んで動作し、AAP自身のAPIを介してデータをやり取りします。自動化ジョブの起動、インベントリの照会、監査ログの確認といった操作を、AAPの管理画面を開かずに自然言語のチャットから実行できます。

このMCPサーバーは2026年2月2日にAAP 2.6.4でテクノロジープレビューとして公開され、2026年6月3日のリリースでAAP 2.6以降を対象に正式サポート(GA)へ移行しました。公開当初は6種類だったツールセットも、GAの時点で7種類(後述)に増えています。技術検証中の記事や古いブログ記事には「テクノロジープレビュー」と書かれたものが残っているため、導入前にAAPのバージョンと利用中のドキュメントの版を確認します。

デプロイ先は2種類です。RHEL 9または10上のコンテナ化インストールでは、MCPサーバーはAAPの各コンポーネントと並ぶPodとして動作し、ポート8448でHTTPS公開されます。OpenShift Container Platform(4.12〜4.17以降)ではAnsible Automation Platform OperatorがAnsibleMCPServerカスタムリソースのライフサイクルを管理し、OpenShiftのRouteも自動生成します。

MCPサーバーが提供するツールセットは次の7つです。

ツールセット主な用途
job_management主な用途ジョブテンプレート・プロジェクトの作成、ジョブ起動、スケジュール設定
inventory_management主な用途インベントリ・ホストの作成と照会、グループ所属の確認
system_monitoring主な用途ジョブログの取得、プラットフォームのヘルスチェック
user_management主な用途ユーザー・チームの作成とアクセス権の管理
security_compliance主な用途認証情報の閲覧・管理、カスタム認証情報タイプの設定
platform_configuration主な用途システム設定・ライセンス管理、実行環境のチューニング
content_discovery主な用途Ansible Content Collectionsの検索、実行環境リポジトリの一覧、ナレッジベース検索

content_discoveryは7つの中でも新しく、GA時点で追加されたツールセットです。組織のインテリジェントアシスタントに「Bring your own knowledge」を有効にしている場合は、社内の運用手順やポリシーについてもAIエージェント経由で質問できます。

ステップ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(読み取り専用)です。インストール後は次のコマンドでPodの起動を確認します。

podman ps

MCPサーバーのURLはhttps://<ホスト名>:8448になります。

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

spec:
  mcp:
    disabled: false
    allow_write_operations: false

作成後に権限を変更したい場合は、AnsibleMCPServerカスタムリソースをいったん削除して再作成する必要があります。設定の書き換えだけでは反映されません。

ステップ2: APIトークンを発行して認証する

AAPのMCPサーバーは個人アクセストークン(PAT)とOAuthの2方式に対応しますが、Claude CodeはOAuthを使えません。AAP 2.6はOIDCの自動検出(automatic discovery)に対応しておらず、自動検出を前提にOAuth接続するClaude CodeやCursorのようなクライアントは、明示的な認可・トークンエンドポイントの手動設定が必要な現行のOAuthフローに乗れないためです。Claude Codeから接続する場合はPATを使います。

PATの発行手順は次のとおりです。

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

Writeスコープを選ぶかどうかは、次のステップで設定するMCPサーバー全体の権限(読み取り専用 / 読み書き)と組み合わさって最終的な操作範囲が決まります。どちらか一方だけを緩めても、もう一方が制限していれば操作は通りません。

ステップ3: AIエージェントを接続する

mcp.jsonにMCPサーバーの接続先を追加します。接続方法は2通りあります。

方法1: discoverエンドポイント(推奨) — 1つの接続で全ツールセットにアクセスでき、AIモデルはクエリごとに必要なツールセットだけを読み込みます。トークン消費を抑えたいときの既定の選択です。

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

方法2: 個別ツールセットのエンドポイント — AIエージェントに触らせるツールセットを絞りたいときは、/mcp/<toolset>ごとに個別の接続を設定します。7つのツールセットぶん、接続を並べる必要があります。

{
  "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文字までという制限があります。

接続後は、AIエージェントに「Ansible Automation PlatformのMCPツールは何が使えますか」のように聞くと、有効なツール一覧が返ってくることで疎通を確認できます。

MCPサーバーの権限は二層構造です。サーバー全体の権限(読み取り専用がデフォルト、または読み書き)を組織管理者が設定し、そのうえで各ユーザーのAPIトークンが持つAAPのRBAC権限が適用されます。読み取り専用のサーバー設定は、たとえユーザー個人が書き込み権限を持っていても、この設定を上書きしてジョブ実行やAAP側の変更を防ぐグローバルな安全装置として働きます。ユーザーのトークンに権限がない操作をAIエージェントが試みると、AAPのAPI自体がリクエストを拒否し、MCPサーバーはその拒否結果をそのままクライアントへ返します。サーバー側の許可とユーザー側の許可の両方が揃わないと操作は通らない、という考え方です。

この「まずサーバー全体を読み取り専用にして、必要な範囲だけ書き込みを許可する」設計は、他のMCPサーバーの本番導入でも共通する型です。Kubernetes MCPサーバーの権限設計ではKubernetesクラスタに対して同じ考え方を適用しており、比較すると業種を問わず「本番の書き込み権限は既定で閉じる」という運用が定着しつつあることが分かります。

書き込みを許可するかどうかの判断は、AIエージェントがプロンプトを誤解釈したり、存在しない手順を生成したりする可能性を踏まえて行います。AAPの公式ドキュメントも、読み書き権限を有効にするとAIエージェントの誤操作でAAP環境に意図しない変更が入るリスクがある、と明記しています。ジョブテンプレートの起動やインベントリの変更のような取り消しにくい操作を任せる前は、読み取り専用のまま動作を確認する段階を挟むと安全側に倒せます。

よくあるつまずき

自己署名証明書でSSL検証エラーになる。OpenShiftのIngress証明書がカスタムCAや自己署名の場合、SELF_SIGNED_CERT_IN_CHAINエラーで接続できません。CA証明書を含むSecretを作成し、AnsibleMCPServerカスタムリソースのbundle_cacert_secretで参照させると解消します。

ジョブの出力取得で406エラーになる。AAPはMCPサーバーからのリクエストがJSON形式でないと406を返します。AIツールに一度JSON形式で出力させてから、必要な形式に変換させると回避できます。ここで挙げたのはAAP固有のエラーですが、そもそもAIエージェントがMCPサーバーを認識しない、ツール一覧に出てこないといった接続そのものの問題は、MCPサーバーに接続できないときの切り分け手順にある設定・起動・認証・ツール表示の4層で切り分ける方法が使えます。

機微情報がLLM側に渡る。認証情報のパスワードやAPIトークンはAAPのAPI層で常にマスクされ、平文では返りません。ただし、IPアドレス・ホスト名・インベントリ変数・ジョブのextra varsといった運用データは既定でフィルタされず、接続先の外部LLMプロバイダーのコンテキストに含まれます。社内ポリシーで外部共有を制限している場合は、有効にするツールセットとRBACの範囲を事前に確認します。

テレメトリは無効化できない。2026年1月21日以降のパッチリリース以降、MCPサーバーの利用状況に関する匿名化テレメトリはRed Hatへ自動送信され、この収集自体は停止できません(個人情報は含まれない設計です)。

まとめ

AAPのMCPサーバーは2026年6月3日にGAとなり、AAP 2.6以降であれば本番環境での利用が正式にサポートされています。導入の勘所は、①コンテナ/Operatorどちらのデプロイ方式か ②読み取り専用か読み書きかのサーバー権限 ③discoverエンドポイントか個別ツールセットか、の3点です。Claude Codeから使う場合は、OAuthではなくPATで接続する点を忘れないようにします。

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

この記事を共有:XはてブLinkedIn

関連する記事

Claude Code をもっと見る →