AWX入門｜AnsibleをGUIで運用する方法とジョブテンプレート・スケジュール実行の構築手順

宮崎智広 この記事の監修：宮崎智広（Linux実務・教育歴20年以上・受講者3,100名超）
ＨＯＭＥ ＞ Linux技術 リナックスマスター.JP（Linuxマスター.JP） ＞ Ansible ＞ AWX入門｜AnsibleをGUIで運用する方法とジョブテンプレート・スケジュール実行の構築手順
「Ansibleは使えている。でも、チームに展開しようとしたら途端に行き詰まった」
複数のエンジニアが手元のPCからansible-playbookを実行すると、誰がいつどのPlaybookをどのサーバーに対して走らせたか追跡できません。SSH鍵やVaultパスワードは全員が持つ必要があり、定期実行のたびにcrontabを設定するサーバーを探して回る羽目になります。

この記事では、Ansible CLIにGUI管理機能を追加するOSSプロジェクト「AWX」の概念と導入全体像を解説します。
インストールコマンドの羅列ではなく、「AWXがチーム運用のどこを解決するのか」「ジョブテンプレートとスケジュール実行をどう設計するか」に軸足を置きます。Ansible CLIは使えるが、チーム展開・GUI管理に移行したいエンジニアが最初に掴んでおくべき設計思想を整理します。

この記事のポイント

・AWX = Ansible Tower のOSS版。CLI実行にGUI・RBAC・監査ログを追加する
・ジョブテンプレートはPlaybook・インベントリ・認証情報の実行定義書
・スケジュール実行・通知をGUIで設定し、crontabの属人化を解消できる
・デプロイはKubernetes推奨。検証ならminikubeまたはk3sで即日構築可能


「このままじゃマズい」と感じていませんか？
参考書を開く気力もない、同年代に取り残される不安——
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
図解60P／登録10秒／解除も3秒 ／ 詳細はこちら

AWXとは何か — Ansible CLIとの違いを理解する

AWX（Ansible Web eXecutor）は、Red Hat社が提供するエンタープライズ向け「Ansible Automation Platform（旧Ansible Tower）」のオープンソース版であり、商用版のアップストリームプロジェクトです。コミュニティが無償で使えるUIおよびAPIサーバーとして機能し、Red Hat社がサポート付きの商用版へのフィードバックを収集する場でもあります。

Ansible CLIとAWXの根本的な違いは「実行の集中化」にあります。

Ansible CLIは手元のPCや踏み台サーバーからansible-playbookコマンドを直接実行する分散型の構成です。対してAWXは、Playbookの実行を一本のAPIサーバー（AWXサーバー）に集約します。エンジニアはブラウザからWeb UIにアクセスし、ジョブの起動・監視・履歴参照をすべて一か所で行えます。

項目 Ansible CLI AWX
実行場所 各自のPC・踏み台サーバー AWXサーバー（集中管理）
実行ログ ターミナルに流れるだけ DB保存・Web UIで一覧参照可能
認証情報の管理 各自のPCに分散 AWX内で暗号化して一元管理
アクセス制御（RBAC） なし（SSH鍵を持てば誰でも実行可能） ユーザー・チーム・ロール単位で制御
定期実行 crontabを手動設定 GUIからScheduleを設定
Playbookのバージョン 各自のローカルに依存 GitリポジトリをProjectとして登録・自動同期
API連携 なし（シェルスクリプト経由のみ） RESTful API・awxkit CLIが標準装備
AWXが提供する価値を一文で表すなら「Ansible CLIに集中管理・RBAC・監査ログを追加し、チームで安全に運用できるプラットフォームに昇格させるもの」です。Ansible CLIの知識はそのまま活かせます。学習コストの大半は「どのコンポーネントが何を担うか」の概念把握です。

AWXが解決する「チーム運用」の課題

Ansible CLIをチームで運用すると、多くの現場で次の4つの壁にぶつかります。AWXがそれぞれをどう解決するかを対比で整理します。

課題1：実行ログが手元に分散する
ansible-playbookの出力はターミナルに流れるだけで、チームが共有可能な形式で自動保存されません。「昨日夜中に誰かが走らせたPlaybookが原因でサービスが不安定になった」という状況でも、事後確認の手立てがありません。

AWXの解決策：すべてのジョブ実行はAWXのデータベースに記録されます。誰が・いつ・どのJob Templateを・どのインベントリに対して実行したかがWeb UIに一覧表示され、各ジョブの詳細ログをリアルタイムでストリーミング参照することも可能です。

課題2：認証情報が全員のPCに散在する
各自がPlaybookを手元で実行する場合、対象サーバーへのSSH鍵・sudoパスワード・Vault復号パスワードを全員が手元に持つ必要があります。退職者が出たときのSSH鍵ローテーション作業や、Vaultパスワードがチャットに流れる事故リスクが付きまといます。

AWXの解決策：「Credentials（認証情報）」機能でSSH鍵・Vaultパスワード・クラウドAPIキーを暗号化して中央管理します。エンジニアはジョブ実行権限だけを持ち、Credentialsの実体を知る必要はありません。退職者の鍵ローテーションも一か所の変更だけで完結します。

課題3：定期実行が属人化する
Playbookを定期実行するためのcrontabがどのサーバーのどのユーザーに設定されているか、全体像を把握している人が誰もいない状況は珍しくありません。担当者の離職や環境変更でcronが停止しても、長期間気づかれないケースもあります。

AWXの解決策：Job TemplateにScheduleをGUIから設定できます。全スケジュールはダッシュボードで一覧管理され、実行の成否に応じてSlack・メール・Webhookへの通知も設定できます。crontabの管理サーバー探しからも解放されます。

課題4：Playbookのバージョンがチームで不統一になる
各自がPlaybookをローカルにコピーして運用する場合、誰かが修正を加えたPlaybookが他のメンバーのPCには反映されないまま実行される事故が起きます。「どのバージョンが本番に当たっているか」の確認が困難です。

AWXの解決策：「Projects」機能でPlaybookのGitリポジトリを登録し、実行時に最新コードを自動で取得（git pull相当）します。GitのブランチやタグをProject単位で指定できるため、ステージング環境はdevelopブランチ、本番環境はmainブランチのPlaybookで実行するといった管理が可能です。

Ansibleのチーム運用を体系的に学びたい方へ

AWXが解決する4つの課題は、Ansible CLI自体の設計思想（Playbook・インベントリ・Credentials）を正しく理解していることが前提です。基礎からハンズオンで学びたい方は、現役エンジニアによる実践セミナーを活用してください。
＞＞ Ansible実践セミナーの詳細はこちら

AWXの主要コンポーネントと画面構成

AWXのWeb UIは左サイドバーにコンポーネント一覧が並び、トップダウンで設定を進める構造になっています。「まず何を設定すべきか」の順番を把握することが、AWXを使いこなす最初のポイントです。

Organizations（組織）
AWX内のリソースを束ねる最上位の論理グループです。大企業では部署ごと・プロジェクトごとに複数のOrganizationを作成してリソースを分離管理できます。1つのOrganizationに対して、Admin（管理者）・Member（実行者）・Auditor（閲覧のみ）の3ロールを割り当てます。

Users / Teams（ユーザー / チーム）
AWXにログインするユーザーアカウントとチームを管理します。RBACの権限設定はユーザーまたはチーム単位で行います。LDAP・SAML・OAuthと連携したSSOも設定可能で、既存の社内IdPを活用できます。

Credentials（認証情報）
SSH秘密鍵・Vaultパスワード・sudoパスワード・クラウドAPIキー（AWS/Azure/GCP）など、Playbook実行に必要な認証情報を暗号化して保存します。AWXではCredentialsの値は保存後に平文で取り出せない設計になっており、使用権限だけを付与できます。「Machine」「Vault」「Source Control」「AWS」など用途ごとにCredentialのTypeが分かれています。

Projects（プロジェクト）
PlaybookファイルのソースとなるGitリポジトリを登録します。GitHubやGitLabのプライベートリポジトリもSSH鍵またはPersonal Access Tokenで接続できます。「Update on Launch」オプションを有効にすると、ジョブ実行のたびにgit pullを自動実行して最新Playbookを取得します。

Inventories（インベントリ）
Ansibleの実行対象ホストを管理します。静的インベントリ（Web UIでホストを手動定義）と動的インベントリ（AWSのEC2インスタンスをAPI経由で自動収集）の両方に対応します。ホストの変数（host_vars相当）もWeb UIから設定できます。

Job Templates（ジョブテンプレート）
「Project（どのPlaybook）」「Inventory（どのホスト群）」「Credentials（どの認証情報）」を組み合わせた実行定義書です。AWX運用の中心となるコンポーネントで、次のセクションで詳しく解説します。

Workflow Templates（ワークフローテンプレート）
複数のJob Templateを「成功したら次を実行」「失敗したらロールバック用を実行」という形で連結するオーケストレーション機能です。複数フェーズのデプロイ自動化やCI/CDパイプラインの一部として使われます。

Jobs（ジョブ）
Job Templateを実行した各インスタンスの記録です。実行開始・終了時刻・実行者・実行結果（Successful / Failed / Running / Canceled）・ホストごとのタスク詳細ログが保存されます。過去のジョブを一覧から選んでログを遡ることも可能です。

AWX REST APIを使ったジョブ一覧の取得例です。Web UIに表示されている情報はすべてAPIからも取得できます。

# AWX の REST API でジョブ実行履歴を取得する
# ホスト名・パスワードは環境に合わせて変更すること
$ curl -s -u admin:（パスワード） \
  https://awx.example.com/api/v2/jobs/?page_size=5&order_by=-started \
  | python3 -m json.tool
{
    "count": 312,
    "results": [
        {
            "id": 312,
            "type": "job",
            "status": "successful",
            "name": "nginx_deploy",
            "started": "2026-07-18T09:14:32.441Z",
            "finished": "2026-07-18T09:15:47.882Z",
            "elapsed": 75.441,
            "launched_by": {
                "name": "tanaka"
            },
            "job_template": 15
        },
        {
            "id": 311,
            "type": "job",
            "status": "failed",
            "name": "patch_apply_staging",
            "started": "2026-07-18T02:00:00.023Z",
            "finished": "2026-07-18T02:03:51.702Z",
            "elapsed": 231.679,
            "launched_by": {
                "name": "schedule"
            },
            "job_template": 22
        }
    ]
}
上記のように、誰が実行したか（launched_by）、スケジュール実行かどうか（schedule表示）、実行時間（elapsed）がAPIレスポンスに含まれます。監査ログとしての活用やCIパイプラインとの連携に使える情報です。

ジョブテンプレートの設計思想と運用フロー

Job Templateは「どのPlaybookを・どのホスト群に・どの認証情報で実行するか」を定義した実行定義書です。AWX運用の中心となるコンセプトであり、ここの設計精度がチーム運用の品質を左右します。

1. Job Templateの構成要素

Job Templateには以下の要素を紐づけて定義します。

・Name（名前）：「nginx_deploy_production」のように目的と環境が一目でわかる命名にする
・Job Type：「Run」（通常実行）または「Check」（ドライラン）を選択できる
・Inventory：実行対象のホスト群を選択
・Project：PlaybookのGitリポジトリを選択
・Playbook：ProjectのリポジトリにあるYAMLファイルを選択
・Credentials：SSH鍵・Vault等のCredentialを複数紐づけ可能
・Extra Variables：実行時に渡す変数をYAML/JSON形式で定義（vars_filesの外部注入に相当）
・Limit：インベントリ内の特定のホストやグループに実行を絞り込む（--limit相当）
・Verbosity：ログの詳細度（0=Normal ～ 5=WinRM Debug）を選択

2. Job Templateの設計原則

Job Templateの設計で最も重要なのは「1テンプレート = 1目的」の原則です。

たとえばWebサーバーのデプロイを担当するPlaybookが1本あるとして、それを本番・ステージング・検証の3環境で実行したい場合、Job Templateを3つ作成します。Playbookは同一でも、Inventoryと紐づけるCredentialsを環境ごとに変えることで、誤って本番環境に検証用の変更を適用するミスを構造的に防げます。

Job Template名 Inventory Credentials
nginx_deploy_production prod_servers prod_ssh_key + prod_vault
nginx_deploy_staging staging_servers staging_ssh_key + staging_vault
nginx_deploy_dev dev_servers dev_ssh_key

3. 実行権限の設定（RBAC）

Job Templateに対してユーザーやチームに次の3種類の権限を設定できます。

・Admin：テンプレートの設定変更・実行・削除が可能
・Execute（Use）：テンプレートの実行のみ可能（設定変更は不可）
・Read：テンプレートの内容閲覧のみ（実行不可）

インフラエンジニアはAdminを持ち、アプリ開発チームにはExecuteのみを付与するという運用が一般的です。開発者がデプロイを自分で実行できる環境を与えながら、Playbook本体の改変はできないように制限できます。

4. Surveyによる実行時パラメータ入力

Job Templateの「Survey」機能を使うと、実行時にWeb UIでフォーム入力を受け付けられます。「デプロイするバージョンを入力してください」「対象のホストグループを選んでください」といった動的なパラメータを、コード修正なしに実行者が指定できる仕組みです。

スケジュール実行とインベントリ管理

1. Scheduleの設定と管理

Job TemplateにScheduleをGUIから追加することで、crontab相当の定期実行を設定できます。スケジュールの設定はRFC 5545のRRULE形式で管理されますが、Web UIでは「毎日AM2:00」「毎週月曜日8:00」のようなGUI選択で入力できます。


# awxkit CLI でスケジュール一覧を確認する例
# （awxkitは pip install awxkit でインストール）
$ export CONTROLLER_HOST=https://awx.example.com
$ export CONTROLLER_USERNAME=admin
$ export CONTROLLER_PASSWORD=（パスワード）
$ awx schedules list --all

id  name                   next_run                        enabled
--  ---------------------  ------------------------------  -------
 3  patch_apply_daily      2026-07-19T02:00:00.000000Z     true
 7  config_audit_weekly    2026-07-21T08:00:00.000000Z     true
12  cert_renewal_monthly   2026-08-01T03:00:00.000000Z     true
スケジュール一覧はnext_runフィールドで次回実行予定時刻を確認できます。有効・無効の切り替えもenabledフィールドで一目でわかります。crontabが複数サーバーに散在しているケースと比較すると、全スケジュールの把握が格段に容易です。

通知（Notifications）
スケジュール実行の成否をSlack・メール・Webhook・PagerDutyへ通知できます。Notificationは「成功時」「失敗時」「開始時」ごとに設定を分けられるため、成功は無通知・失敗のみアラートという運用が可能です。

2. インベントリ管理

インベントリはAnsibleが「どのホストに接続するか」を定義する情報源です。AWXでは2つの方式があります。

静的インベントリ（Inventory Sources: Manual）
Web UIでホスト名・IPアドレス・グループを手動定義します。サーバー台数が固定されているオンプレミス環境や、変動が少ない構成に向いています。ホストごとの変数（host_vars相当）もWeb UIのHost VariablesフィールドにYAML/JSON形式で設定します。

動的インベントリ（Inventory Sources: クラウドプロバイダー）
AWSのEC2・Azure VM・GCPのCompute Engine・VMware vCenterのVMを自動収集します。AWSの場合、「Amazon EC2」タイプのInventory SourceにAWS CredentialとリージョンフィルタのSourceVariablesを設定するだけで、実行時に最新のEC2インスタンス一覧を自動取得します。


# 動的インベントリ（EC2）のSource Variables設定例
# AWX Web UI の Inventory Sources > Source Variables に入力する
---
regions:
  - ap-northeast-1
filters:
  instance-state-name:
    - running
  "tag:Env":
    - production
keyed_groups:
  - key: tags.Role
    prefix: role
上記を設定すると、東京リージョンで稼働中かつタグEnv=productionのEC2インスタンスが自動収集され、tags.Roleの値でホストグループが生成されます（例：role_webserverグループ）。Playbook側でこのグループ名をhosts:に指定するだけで、Inventoryの管理をAWSと同期した状態に保てます。

なお、AWXのデフォルトアクセスポートは80（HTTP）または443（HTTPS）です。ネットワーク的にHTTPS通信が可能かどうかは、事前に確認しておきましょう。Linuxのポート確認方法についてはLinuxポート確認コマンド（ss・lsof）の使い方も参考にしてください。

AWX導入の全体像と次のステップ

1. AWXのデプロイ方式

AWXの公式推奨デプロイ方式はKubernetesです。以前はDocker Composeを使った単一サーバー構成も提供されていましたが、AWX 18以降はKubernetesネイティブの構成に移行しています。

・検証環境（1台のサーバーで試す場合）：minikube または k3s をインストールし、AWX Operator（Kubernetes用のデプロイツール）を使って構築します。2 vCPU・4GB RAM・20GB Disk程度のVMがあれば数時間で動作確認できます
・本番環境：マルチノードのKubernetesクラスター（EKS・AKS・GKE等のマネージドサービス、またはkubeadm構築のオンプレクラスター）にデプロイします。PostgreSQLのバックアップ設計と永続ボリュームの設計が重要です

2. 導入フェーズの全体像

AWXのPoC（概念実証）から本番移行までの標準的なフェーズを示します。

フェーズ 目的 主な作業
Phase 1: 検証構築 AWXの動作確認 minikube/k3s上にAWX Operatorでデプロイ
Phase 2: コンポーネント設計 チーム運用設計 Organizations・Teams・Credentials・Projects の設計と登録
Phase 3: テンプレート移行 既存Playbook移行 手動運用していたPlaybookをJob Templateとして登録・権限設定
Phase 4: スケジュール移行 crontab廃止 既存crontabをAWXのScheduleに移行・通知設定
Phase 5: 本番移行 本番クラスターへの展開 EKS等の本番Kubernetesクラスターへ移行・バックアップ設計

3. AWS Tower（Ansible Automation Platform）との使い分け

AWXはOSSですが、商用版のRed Hat Ansible Automation Platform（AAP）には、コンテンツコレクション・テクニカルサポート・Execution Environmentの管理UI（Private Automation Hub）が追加されています。PoC・小規模チームはAWXで十分ですが、大規模運用やRHELサポート契約を活用したい場合はAAPを検討してください。

本記事のまとめ

AWXはAnsible CLIに「集中管理・RBAC・監査ログ・スケジュール実行」を追加し、チームで安全に自動化を回す基盤を提供します。Playbookの知識はそのまま活かせるため、Ansible CLIに習熟したエンジニアが最初に挑戦するステップとして最適です。

コンポーネント 役割
Organizations リソースを束ねる最上位グループ・RBAC境界
Credentials SSH鍵・Vault・クラウドAPIキーを暗号化して一元管理
Projects GitリポジトリとPlaybookを紐づけ・自動同期
Inventories 実行対象ホストの静的・動的管理
Job Templates Playbook×Inventory×Credentialsの実行定義書・RBAC起点
Schedules Job Templateの定期実行をGUIで一元管理
Jobs 実行履歴・リアルタイムログ・監査情報
Notifications 実行成否をSlack・メール・Webhookへ通知
AWXの概念を掴んだ次のステップは、実際のPlaybook・インベントリ・Credentialsの設計です。Ansible自体の基礎（Playbook構造・モジュール選択・変数設計）がしっかりしていることが、AWX活用を成功させる前提条件になります。
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、AWXとAnsibleをゼロから体系的に教えます。20年以上の運用経験を持つ現役エンジニアによるハンズオン形式のセミナーです。
Ansible実践ハンズオンの詳細を見る ＞＞

関連記事

無料メルマガで学習を続ける

Linuxの実践スキルをメールで毎週お届け。
登録は1分、解除もいつでも可。

登録無料・いつでも解除できます

暗記不要・1時間後にはサーバーが動く

3,100名以上が実践した「型」を無料で公開中

プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。

登録10秒／合わなければ解除3秒 ／ 詳細はこちら

Linux無料マニュアル（図解60P） 名前とメールで30秒登録
宮崎 智広

この記事を書いた人

宮崎 智広（みやざき ともひろ）

株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。

趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。