--- title: "Ansible Towerとは：automation controllerへの改称とSurvey・Webhook・RBACの設定手順【AAP 2.7】" url: "https://www.issoh.co.jp/tech/details/18459/" published: 2026-10-17 updated: 2026-10-17 categories: ["自動化"] publisher: "株式会社一創" --- # Ansible Towerとは：automation controllerへの改称とSurvey・Webhook・RBACの設定手順【AAP 2.7】 Ansible Towerは、Ansibleの実行をWeb画面とREST APIから管理するRed Hatの製品でした。2021年のAnsible Automation Platform（AAP）2で名称が「automation controller」に変わり、現在はAAPの一部として提供されています。この記事では改称の経緯とAnsible Engineとの違いを押さえたうえで、ジョブテンプレート、Survey、GitHub Webhook、REST APIからの起動、RBACによる権限委譲をコード付きで解説します。旧Towerの資料と現行のAAP 2.7系で異なる画面名とAPIパスも、本記事での解説対象です。 ## まとめ｜Ansible Towerの機能はautomation controllerが継承 Ansible Towerという名前の製品は、もう新しくは提供されていません。後継はAAPに含まれるautomation controllerで、ジョブテンプレート、Survey、Webhook、RBAC、スケジュールといった機能はそのまま引き継がれました。上流のAWXは無償ですが、2024年7月を最後にリリースが止まっています。 AAP 2.7系ではTower時代の`/api/v2/`を直接叩くスクリプトが401で止まるため、移行時はAPIパスを最初に確認してください。導入の判断軸は「Playbookを書かない人に実行を任せるか」と「誰が何を実行したか監査する必要があるか」の2点です。どちらも当てはまらない数名のチームなら、CLI運用のままで足ります。 ## Ansible Towerの改称経緯とAnsible Engine・AWXとの違い 検索で見つかるTowerの記事は、2016年前後のTower 3.x系を前提にしたものが多く残っています。名称の対応を先に整理しておくと、旧資料を現行版へ読み替えやすくなります。 ### 2021年のAAP 2でTowerがcontroller 4.0に改称された理由と変更点 Red Hatは2021年10月5日の公式ブログ[「What’s new in Ansible Automation Platform 2: automation controller」](https://www.redhat.com/en/blog/whats-new-in-ansible-automation-platform-2-automation-controller)で、automation controller 4.0を「改良され、名称が変わったRed Hat Ansible Tower」と説明しています。改称の理由は、Towerが担っていた機能の一部を切り離したことでした。 切り離されたのは主に実行部分です。Tower 3.x系ではPlaybookの実行に使うPythonの依存ライブラリやコレクションがTowerのサーバーと密結合していましたが、AAP 2では「automation execution environment」というコンテナイメージに分離されました。Red Hatの日本語製品ページも、[Automation Controllerを「Ansible Towerに代わる」コマンド＆コントロールセンター](https://www.redhat.com/ja/technologies/management/ansible/automation-controller)と位置づけています。現行ドキュメントでTowerの機能を調べるときは「automation controller」で探すのが近道です。 ### Ansible EngineとTowerの役割の違いとansible-coreの扱い Ansible Engineは、コマンドラインのAnsible本体にRed Hatのサポートを付けた製品でした。Towerはその上で動く管理基盤で、Web画面、REST API、権限管理、実行履歴を担っていました。 | 旧名称 | 担っていた役割 | AAP 2以降 | | -------------- | ---------------- | --------------------- | | Ansible Engine | Playbookを実行するCLI | 実行環境内のansible-core | | Ansible Tower | 画面・API・権限・履歴 | automation controller | | Towerの仮想環境 | 実行時の依存ライブラリ | execution environment | 前述のブログは、実行環境を「Ansible Core、Ansibleコンテンツ、追加の依存関係を含む自己完結型のイメージ」と説明しています。Engineを別に入れる代わりに、ansible-coreがイメージに同梱される形へ変わったわけです。Playbookの書き方そのものは変わらないので、基本は[Ansible Playbookの書き方と実行手順](https://www.issoh.co.jp/tech/details/18457/)で確認できます。 ### 上流のAWXとcontroller・AAPの関係と2024年からのリリース停止 Towerには、ソースコードが公開された上流プロジェクトのAWXがあります。画面構成やAPIの多くが共通なので、AWXの文書はcontrollerの機能を確かめる一次情報としても使えます。 ただし[AWXのGitHubリポジトリ](https://github.com/ansible/awx)には「最終リリースは2024年7月2日。大規模なリファクタリングの間、リリースを停止する」と明記されており、最新は24.6.1のままです。本番で使い続けると、脆弱性の修正版が出ない期間を自分で抱えることになります。AAPの費用とAWXを選ぶ場合の負担は[Ansible Automation Platformの費用と導入判断](https://www.issoh.co.jp/column/details/18090/)で整理しました。 ## ジョブテンプレートの作成項目とVMwareなどインベントリソースの同期設定 controllerでPlaybookを実行する単位がジョブテンプレートです。「どのPlaybookを、どのホストに、どの認証情報で実行するか」の組み合わせを保存したもので、インベントリや認証情報が未登録だと作成画面で選択肢が出てきません。 ### Automation Execution＞Templatesの入力項目と起動時の上書き AAP 2.7系の手順は[Red Hatのジョブテンプレート作成手順](https://docs.redhat.com/en/documentation/red%5Fhat%5Fansible%5Fautomation%5Fplatform/2.7/develop-proc%5Fcontroller%5Fcreate%5Fjob%5Ftemplate)にあります。ナビゲーションの「Automation Execution」から「Templates」を開き、「Create template」の一覧で「Create job template」を選びます。 | 項目 | 入れる値 | 起動時の上書き | | --------------------- | --------------- | ------- | | Job type | Run または Check | 可 | | Inventory | 対象ホストの一覧 | 可 | | Project | Playbookを置いたGit | 不可 | | Playbook | プロジェクト内のYAML | 不可 | | Execution Environment | 実行用イメージ | 可 | | Credentials | SSH鍵やクラウドの鍵 | 可 | | Forks | 並列数（0で既定の5） | 可 | Checkは`ansible-playbook --check`と同じドライランです。本番用テンプレートでJob typeとLimitの「Prompt on launch」にチェックを入れておけば、実行者が起動のたびにCheckかRunかと対象ホストを選べます。まず1台だけRunし、問題が無ければ全台へ広げる段階実行が画面操作だけで組めるわけです。なお公式手順は、`control-plane-ee`を実行環境に選ばないよう警告しています。内部用のイメージで、Playbookの依存関係が足りずに失敗する可能性があるためです。 ### VMware vCenterやAWS EC2をインベントリソースで同期する手順 「ansible tower vmware」で探す人の多くは、vCenter上の仮想マシンを自動で対象ホストにしたい人です。[AWXのインベントリ文書](https://docs.ansible.com/projects/awx/en/24.6.1/userguide/inventories.html)では、外部から取り込むインベントリソースとしてAmazon EC2、Microsoft Azure Resource Manager、VMware vCenter、Red Hat Satellite 6、Terraform Stateなどが選べます。 vCenterを使う場合は、先にvCenterの認証情報を作り、インベントリソースの画面で指定します。同期のたびに仮想マシンの一覧が更新されるため、台数が増減する環境ほど手書きより保守の負担を軽くできる仕組みです。対象にするフォルダやタグを先に決めておかないと、検証機まで本番用ジョブの対象に入ってしまいます。 ## SurveyでPlaybookの変数を画面入力させる設定とsurvey\_specのJSON Surveyは、ジョブの起動時に質問フォームを出し、回答をPlaybookの変数として渡す機能です。運用担当者に「版と対象環境だけ選んで実行してもらう」用途で使います。 ### Surveyの質問タイプ7種と変数名・必須・最小最大の指定方法 [AWXのジョブテンプレート文書](https://docs.ansible.com/projects/awx/en/24.6.1/userguide/job%5Ftemplates.html)によると、回答の型は次の7種類です。 - Text：1行のテキスト。最小・最大の文字数を指定できる - Textarea：複数行のテキスト - Password：実際のパスワードと同じく機密情報として扱われる - Multiple Choice（single select）：選択肢から1つ - Multiple Choice（multiple select）：選択肢から複数 - Integer：整数。最小と最大を指定できる - Float：小数 各質問には、Playbookで参照する変数名を指定します。空白を含む名前は使えません。対象環境のように取り得る値が決まっている項目は、Textで自由入力させずMultiple Choiceにしてください。typoした環境名がそのまま渡ると、意図しないホストグループに当たる原因になります。 ### survey\_specをawx.awx.job\_templateでコード管理する手順 画面だけでSurveyを作ると、誰がいつ質問を変えたかがGitに残りません。JSONの構造はAWXのソースにある[survey\_specの仕様書](https://github.com/ansible/awx/blob/devel/awx/api/templates/api/job%5Ftemplate%5Fsurvey%5Fspec.md)に定義されており、`type`には`text`、`password`、`integer`、`float`、`multiplechoice`、`multiselect`を指定します。 ``` { "name": "deploy", "description": "アプリのデプロイ先と版を選ぶ", "spec": [ { "type": "multiplechoice", "question_name": "対象環境", "question_description": "stgで確認してからprdを選ぶ", "variable": "target_env", "choices": ["stg", "prd"], "required": true, "default": "stg" }, { "type": "text", "question_name": "アプリの版", "question_description": "例 1.4.2", "variable": "app_version", "min": 5, "max": 20, "required": true, "default": "" } ] } ``` これを`survey/deploy.json`として保存し、[awx.awx.job\_templateモジュール](https://docs.ansible.com/projects/ansible/11/collections/awx/awx/job%5Ftemplate%5Fmodule.html)（コレクション24.6.1）でテンプレートごと作成します。 ``` # controller_setup.yml（AWXに対して実行する例） - name: ジョブテンプレートをコードで作る hosts: localhost gather_facts: false tasks: - name: deployテンプレートを作成または更新 awx.awx.job_template: controller_host: "https://awx.example.com" controller_oauthtoken: "{{ lookup('ansible.builtin.env', 'CONTROLLER_OAUTH_TOKEN') }}" name: "deploy-app" organization: "Default" project: "app-playbooks" playbook: "deploy.yml" inventory: "web-servers" credentials: - "deploy-ssh" job_type: "run" ask_job_type_on_launch: true ask_limit_on_launch: true survey_enabled: true survey_spec: "{{ lookup('ansible.builtin.file', 'survey/deploy.json') }}" state: present ``` 引数には`tower_host`などのエイリアスが残っており、Tower時代のPlaybookもそのまま読めます。このコレクションはAWX向けです。AAPに対しては、automation hubで配布される認定コレクションを使っているAAPの版に合わせて選んでください。 ## GitHub・GitLabのWebhookでジョブテンプレートを起動する設定手順 Webhookを使うと、リポジトリへのpushやプルリクエストを合図にジョブテンプレートを起動できます。CIツールを挟まずに、Playbookの更新を検証環境へ反映する流れが組めます。 ### Webhook URLとWebhook keyをGitHubのリポジトリ設定へ登録 ジョブテンプレートで「Enable webhook」をオンにすると追加の項目が表示されます。対応サービスはGitHubとGitLabの2つです。 1. 「Webhook service」でGitHubかGitLabを選んで保存する 2. 自動入力された「Webhook URL」と、自動生成された「Webhook key」を控える 3. GitHubのWebhook追加画面で、Payload URLにWebhook URLを貼る 4. Content typeを`application/json`にし、SecretにWebhook keyを貼る 5. 起動の合図にするイベントを選び、Add Webhookで保存する [AWXのWebhook文書](https://docs.ansible.com/projects/awx/en/24.6.1/userguide/webhooks.html)によると、ジョブの状態（pending・error・success）を書き戻せるのはGitHubではプルリクエスト、GitLabではマージリクエストのイベントだけです。書き戻しには「Webhook credential」として個人アクセストークンを登録します。ジョブが起動しないときは、GitHub側のWebhook画面に残る送信履歴で応答コードを確かめてください。 ### awx\_webhook\_payloadからブランチ名を取り出すPlaybookの書き方 Webhookで起動したジョブには、送られてきたJSONが`awx_webhook_payload`という変数で渡されます。GitHubのpushイベントでは`ref`に`refs/heads/main`の形でブランチ名が入るので、次のように取り出します。 ``` - name: Webhookのブランチに応じて処理を止める hosts: localhost gather_facts: false tasks: - name: refからブランチ名だけを取り出す ansible.builtin.set_fact: pushed_branch: "{{ awx_webhook_payload.ref | regex_replace('^refs/heads/', '') }}" when: awx_webhook_payload is defined - name: main以外のpushでは何もしない ansible.builtin.meta: end_play when: pushed_branch | default('') != 'main' ``` Webhookは選んだイベントのすべてでジョブを起動し、テンプレート側にブランチを絞る項目はありません。この判定をPlaybookの先頭に置かないと、作業ブランチへのpushでも本番向けのジョブが走ります。手動起動（manual）やスケジュール起動（scheduled）と処理を分けたいときは、自動で付く`awx_job_launch_type`変数で判定できます。 ## REST APIからジョブを起動する手順とAAP 2.7で変わったAPIパス 画面でできる操作は、ほぼすべてREST APIでも行えます。監視ツールのアラートや社内ポータルからジョブを起動する連携はこのAPIを使います。 ### gateway経由のlaunchエンドポイントへ回答を送るcurl実行例 AAP 2.5系以降、controllerのAPIはplatform gatewayの配下に移り、パスが`/api/controller/v2/`で始まる形になりました。トークンはgatewayで発行し、`Authorization: Bearer`ヘッダーに付けます。 ``` # IDが42のジョブテンプレートを、Surveyの回答を付けて起動する curl -s -X POST \ -H "Authorization: Bearer ${AAP_TOKEN}" \ -H "Content-Type: application/json" \ -d '{"extra_vars": {"target_env": "stg", "app_version": "1.4.2"}}' \ https://gateway.example.com/api/controller/v2/job_templates/42/launch/ ``` Surveyの回答は`extra_vars`として渡します。Surveyも「Extra variables」のPrompt on launchも有効でないテンプレートでは、送った変数が反映されません。2.7の手順書によれば、再実行（Relaunch）は`extra_vars`を新たに受け取らず、元のジョブで計算された値を使います。 ### Tower時代のapi/v2を叩く既存スクリプトが401になる移行の注意 移行で最も見落としやすい点です。[AAP 2.7のAPI変更点](https://docs.redhat.com/en/documentation/red%5Fhat%5Fansible%5Fautomation%5Fplatform/2.7/upgrade-con%5Fupgrade%5Fapi%5Fchanges%5F27)には「個々のコンポーネントへの直接のAPIアクセスは削除された」とあり、controllerのホストへ直接送ったリクエストはHTTP 401 Unauthorizedになります。認証情報やトークンもgatewayで作り直す必要があります。 Tower時代から使っているシェルスクリプトや監視ツールの連携は、ホスト名、パス、トークンの3点を書き換えます。アップグレード前に`/api/v2/`を含む設定を社内でgrepして洗い出しておけば、切り替え当日に連携が一斉に止まる事態を防げます。AAP 2.7はRed Hatが[2026年6月10日に一般提供を発表](https://www.redhat.com/en/blog/whats-new-ansible-automation-platform-2-7)した版で、2.4系から上げる組織ではこの作業が必須です。 ## RBACで実行だけを委ねるチーム設計と認証情報を見せない権限 Towerが選ばれてきた最大の理由は、実行権限を細かく委譲できる点にあります。CLIで同じことをすると、実行者全員にSSH鍵やクラウドの鍵を配ることになります。 ### Execute・Use・Adminロールの違いと全員を管理者にする失敗 [AWXのRBAC文書](https://docs.ansible.com/projects/awx/en/24.6.1/userguide/rbac.html)で定義されているロールのうち、実務でまず押さえるのは上の2つです。 | ロール | 付ける対象 | できること | | ------- | ------------ | ---------------- | | Execute | ジョブテンプレート | 割り当てられたテンプレートの実行 | | Use | 認証情報・インベントリ等 | テンプレートの中で使う | | Admin | 組織・チーム・各リソース | 設定の変更と削除 | | Read | 組織・チーム・各リソース | 閲覧のみ | 運用担当者のチームにはジョブテンプレートのExecuteだけを付けます。同じ文書には、利用者に秘密情報を見せないまま必要な認証情報を使わせられると書かれています。SSH鍵の中身を知らない担当者でも、許可されたテンプレート経由なら本番への適用を実行できるわけです。AAP 2.7系では、ロールの一覧と独自ロールの作成が「Access Management」の「Roles」に集約されました。 導入初期に多い失敗は、権限設定を後回しにして全員を組織の管理者にする運用です。誰でもPlaybookの参照先やインベントリを書き換えられる状態では、実行履歴が残っても監査証跡になりません。テンプレートを作るチーム（Admin）と実行するチーム（Execute）は最初から分けてください。 ## automation controllerを導入する条件とCLI運用で見送る場面の判断 判断は、Playbookを書く人と実行する人が分かれているかどうかで決まります。 ### 導入する条件：実行者が開発者以外で操作の監査が求められる場合 次の2つが両方当てはまるなら、controller（またはAAP）の導入を勧めます。1つ目は、夜間の運用担当者やヘルプデスクなど、Playbookを書かない人に定型作業を任せたい場合です。2つ目は、ISMSや内部統制の監査で「誰が、いつ、どの手順で本番を変更したか」を示す必要がある場合です。この2つが揃えば、Surveyで入力を絞り、Executeロールで実行を委ね、ジョブ履歴を証跡にする構成がそのまま効きます。 ### 見送る場面：数名のインフラ担当がGitのPlaybookを直接実行できる体制 Playbookを書く人と実行する人が同じ3〜4名で、監査の要件も無いなら、controllerは過剰です。サーバー、データベース、実行環境イメージの保守が増える割に、得られるのは画面での実行と履歴だけになります。GitHub ActionsなどのCIから`ansible-playbook`を実行すれば、履歴はCIのログに残ります。 リリース停止中のAWXを無償の代替として本番に入れる判断も勧めません。軽いWeb画面が欲しいだけなら[Semaphore UIの導入手順とAWXとの違い](https://www.issoh.co.jp/tech/details/12399/)も比較対象です。Playbookの整備から実行基盤の設計、CI/CDへの組み込みまで外部に任せる場合は、[DevOps・CI/CD導入支援](https://www.issoh.co.jp/service/system/devops/)でご相談を受け付けています。 ## よくある質問 Ansible Towerについて、検索されることの多い質問に答えます。 ### Ansible Towerは今でも使えますか？ Ansible Towerという名前の製品は、2021年のAAP 2でautomation controllerへ改称されました。新規に導入するならAAPを契約し、その中のcontrollerを使う形になります。Tower 3.x系を動かしている環境は、サポート期間とOSの対応を確かめたうえでAAPへの移行を計画してください。影響が大きいのはAPIパスと実行環境の変更です。 ### Ansible Towerは無料で使えますか？ controllerを含むAAPは有償のサブスクリプションで、料金は管理対象ノード数とサポート水準による見積もり制です。無償で同系統の機能を試すなら上流のAWXがあります。ただし2024年7月2日の24.6.1を最後にリリースが止まっており、本番利用は脆弱性対応を自前で抱える前提になります。 ### Ansible TowerとAWXの違いは何ですか？ AWXは、Tower（現automation controller）の上流にあたるオープンソースのプロジェクトです。ジョブテンプレートやSurveyなどの機能の多くは共通しています。違うのは、Red Hatのサポート、セキュリティ修正の提供、認定コンテンツの有無です。KubernetesへのAWXの導入手順は[Ansible AWXとは：AWX OperatorでKubernetesへ導入する手順とAAPとの違い](https://www.issoh.co.jp/tech/details/18461/)で扱っています。 ### Ansible TowerのGUIでPlaybookを書けますか？ 書けません。controllerの画面でできるのは、Gitリポジトリなどに置いたPlaybookを選んで実行し、結果を見ることです。Playbook本体はエディタで書き、プロジェクトに登録したリポジトリへコミットします。画面から編集できないぶん、変更履歴がGitに集まるという利点もあります。 ### Ansible TowerのWebhookはGitHub以外にも使えますか？ 「Enable webhook」が標準で対応しているのはGitHubとGitLabの2つです。それ以外のサービスから起動したい場合は、REST APIの`launch`エンドポイントへPOSTします。AAP 2.5系以降はgateway経由の`/api/controller/v2/`を使い、トークンもgatewayで発行してください。 ## 関連記事 - [Ansibleとは？エージェントレスの仕組みとメリット・デメリット、Red Hat AAPの制約](https://www.issoh.co.jp/tech/details/6533/)：controllerが実行するAnsible本体の仕組み。 - [Ansible Playbookの書き方と実行手順：–checkでのdry-runとhandlers【2.21系】](https://www.issoh.co.jp/tech/details/18457/)：ジョブテンプレートに登録するPlaybookの書き方。 - [Ansible Automation Platformの費用と導入判断：AWX・ansible-coreとの違いと契約すべき条件](https://www.issoh.co.jp/column/details/18090/)：controllerを含むAAPの費用と契約判断。 - [Ansibleによる運用自動化の進め方：対象作業の選び方と費用対効果・失敗パターン](https://www.issoh.co.jp/column/details/18092/)：どの運用作業をジョブテンプレート化するかの選び方。 - [Ansible Moleculeとは？v26系のansible-native設定とmolecule testの実行手順](https://www.issoh.co.jp/tech/details/17630/)：controllerへ載せる前にロールを自動テストする方法。 --- 出典: [Ansible Towerとは：automation controllerへの改称とSurvey・Webhook・RBACの設定手順【AAP 2.7】]()（株式会社一創）