LASSIC Media らしくメディア

監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）

Ansibleで作った自動化の手順が、担当者のパソコンの中にしか無い。誰がいつどのサーバーに実行したのか、あとから確かめようがない——。Ansibleをコマンドで使い始めた運用の現場では、こうした悩みが起こりがちです。Ansible AWX（エーダブリューエックス）は、Ansibleの実行をWebの画面から行い、権限と実行履歴をまとめて管理するためのオープンソースのソフトウェアです。

運用担当者に作業を任せやすくなる一方で、2024年7月から新しい版の公開が止まっているため、使い続けるかどうかの判断が要ります。本記事では、サーバー運用を担当する情報システムの担当者に向けて、Ansible単体との違い、Ansible Automation Platformとの関係、導入の進め方、そして外部に頼むときに確認したい点を整理します。

Ansible AWXとは

AWXの公式リポジトリは、AWXをAnsibleの上に作られたWebの画面、REST API、タスクエンジンだと説明しています。^*1 Ansible自体はコマンドで動かす道具で、AWXはその実行を管理する画面と仕組みをかぶせたもの、と考えると分かりやすいでしょう。

• Ansibleの実行を、Webの画面とREST APIから行えます
• Red Hatが支援するコミュニティのプロジェクトで、ソースコードはApache License 2.0で公開されています^*2
• Red Hat Ansible Automation Platformの元になるプロジェクト（アップストリーム）の一つです^*1
• 最後の版は2024年7月2日の公開で、大規模な作り直しのあいだ新しい版の公開は止まっています^*1

サポートは利用者どうしのコミュニティで行われ、Red Hatは有料のサポートを提供していません。^*2 無料で使える一方で、障害や更新への対応は自社で受け持つことになります。

Ansible単体との違い

Ansible単体（Ansible Core）は、コマンドで動かす道具です。^*2 手順を書いたファイル（Playbook）を担当者が自分の端末から実行するので、人が増えると誰が何を実行したかを追いにくくなります。AWXとの違いは、主に画面・権限・実行履歴の3つに表れます。

中でも大きいのは権限と認証情報の違いです。AWXでは、手順を実行する権限だけを運用担当者に渡し、編集の権限は作った人に残す、といった分け方ができます。サーバーのパスワードや鍵を見せずに使わせられるため、担当者が異動や退職をしても、すべてのサーバーの鍵を作り直す必要がありません。だれが何を変え、どの手順を実行したかの操作の記録も残ります。^*3

Red Hatの製品版との関係

AWXとあわせてよく出てくるのが、Red Hat Ansible Automation Platform（以下、AAP）です。AAPはRed Hatがサブスクリプションで提供し、サポートする製品です。^*2 その中で画面とAPIを受け持つ部品が、automation controller（以前の名前はAnsible Tower）です。^*4 公式のFAQは、automation controllerはAWXの版の中から選んだものを、長く使えるように固めて作っていると説明しています。^*2

どちらを選ぶかは、機能の多さより、障害のときに誰が対応するかで考えると整理しやすくなります。自社で更新と障害対応を受け持てるならAWX、メーカーのサポートを前提にしたいならAAP、という分け方です。AWXは新しい版の公開が止まっているため、これから入れる場合はその状態を踏まえて選ぶ必要があります。

導入の進め方

AWXの導入は、ソフトを入れる作業より、誰にどの手順を任せるかを決める作業のほうが大切です。次の4つの段階で進めると、権限の設計をやり直さずに済みます。

• ステップ1：画面から実行したい定型作業を選ぶ（サービスの再起動、利用者の追加など）
• ステップ2：組織とチームを決め、見る・実行する・編集するの権限を割り当てる
• ステップ3：手順（ジョブテンプレート）と、サーバーに入るための認証情報を登録する
• ステップ4：スケジュールと、成功・失敗の通知先（メールやSlackなど）を決めて運用を始める

入れ方にも注意が要ります。公式の手順では、版18.0以降はKubernetes（コンテナを動かす基盤）の上でAWX Operatorという仕組みを使って入れる方法が推奨で、Dockerで動かす形は開発やテスト向けとされています。^*5 版の更新もAWX Operatorで入れた場合に限られ、古い版から直接上書きする更新には対応していません。^*2

外部に頼むときに確認しておきたい点

AWXはライセンス費用がかからない一方、Kubernetesの運用と版の管理は自社で持つことになります。構築や運用を外部に頼むときは、次の点を見積もりの前に確かめておきます。

• AWXかAAPか：新しい版の公開が止まっていることを踏まえ、どちらで組むかの提案と理由を出してもらえるか
• 権限の設計：チームと権限の分け方を、いまの運用の担当分けから一緒に決めるか
• 認証情報の扱い：サーバーの鍵やパスワードを誰が登録し、入れ替えをどう行うか
• 基盤の保守：Kubernetesとデータのバックアップを、誰がどの頻度で確かめるか
• 手順の移し替え：担当者の端末にあるPlaybookを、どの順でAWXへ移すか

手順書をジョブとして実行する仕組みには、AWXのほかにRundeckもあり、考え方はRundeckで運用自動化基盤を外注構築で扱っています。Ansibleそのものの基本はAnsible入門にまとめています。

まとめ：Ansible AWXで確かめておきたい3つの点

Ansible AWXを導入するうえで、確かめておきたい点は3つに整理できます。第一に、Ansible単体との違いは画面・権限・実行履歴にあるので、誰にどの手順を任せたいかをはっきりさせること。第二に、新しい版の公開が止まっていることを踏まえて、AWXとAAPのどちらで組むかを決めること。第三に、Kubernetesの基盤と認証情報の管理を誰が受け持つかを、導入の前に決めることです。この3点を踏まえておけば、「画面は入れたが、結局コマンドでの実行に戻ってしまった」という事態を避けやすくなります。構築や移行の進め方に迷いがあれば、外部の手を借りるのも一つの選択肢です。

よくある質問

出典

1. *1　参考：ansible/awx（GitHub）README（https://github.com/ansible/awx）。出典：AWXの説明（Webの画面・REST API・タスクエンジン）、Red Hat Ansible Automation Platformのアップストリームであること、最後の版（2024年7月2日）と版の公開の停止についての記述を参照（2026年10月確認）
2. *2　参考：Ansible「Frequently asked questions」（AWX Project FAQ）（https://www.ansible.com/awx-project-faq）。出典：Ansible CoreとAWXの違い、automation controller（旧Ansible Tower）との関係、サポート、ライセンス（Apache License 2.0）、版の更新、安定版の扱いの記述を参照（2026年10月確認）
3. *3　参考：AWX Documentation「User Guide」（版24.6.1、GitHub上のドキュメントの原稿）（https://github.com/ansible/awx/tree/24.6.1/docs/docsite/rst/userguide）。出典：Overview（権限・監査・REST API・認証連携・通知）、Role-Based Access Controls、Jobs、Credentials、Schedulesの記述を参照（2026年10月確認）
4. *4　参考：Red Hat「Red Hat Ansible vs. Ansible projects and AWX: What’s the difference?」（https://www.redhat.com/en/technologies/management/ansible/compare-awx-vs-ansible-automation-platform）。出典：automation controller（画面とAPI）、版ごとのサポート期間についての記述を参照（2026年10月確認）
5. *5　参考：ansible/awx（GitHub）INSTALL.md（https://github.com/ansible/awx/blob/devel/INSTALL.md）。出典：版18.0以降のAWX Operatorによる導入の推奨、Dockerでの導入は開発・テスト向けであることの記述を参照（2026年10月確認）

Tweet