Ansibleとは？エージェントレスの仕組みとメリット・デメリット、Red Hat AAPの制約

Ansible（アンシブル）は、サーバーやネットワーク機器の設定をYAMLで書き、SSH経由でまとめて適用するオープンソースの構成管理ツールです。管理対象に専用の常駐エージェントを入れない設計で、既存サーバーにも接続設定・権限・モジュールの依存関係を確認したうえで導入できます。一方で「YAMLで書けば誰でも同じ結果になる」という説明は正確ではありません。冪等性が成り立たないタスクがあり、商用版のRed Hat Ansible Automation Platform（AAP）にはライフサイクルと既定バージョンの制約があります。この記事では、ansible-core 2.21.4を実際に動かした出力と、Red Hatが公開しているライフサイクル情報をもとに、採用判断に必要な事実を整理します。

まとめ：Ansibleの採用判断に効く5つの事実

• エージェントレスの代償はコントロールノードに集まる。管理対象に専用エージェントは不要ですが、通常のPOSIXモジュールには対応するPythonや依存ライブラリが必要です。ansible-core 2.21の実行側にはPython 3.12〜3.14が必要で、WindowsではWSLなどのLinux環境を使います。
• 冪等性はモジュールごとの性質であって、Ansible全体の保証ではない。shell・commandは、実行条件や変更判定を指定しなければ、正常実行時に原則changedになり、--checkではcreates・removesがなければタスクがスキップされます。これらを指定すると、コマンドを実行せず変更有無を予測できます。
• 「Ansible」は3つある。ansible-core 2.21.4（2026-09-08）、コレクション同梱のcommunity package 14.4.0（同日）、商用のAAP 2.7です。バージョン体系が別なので混同すると要件定義がずれます。
• AAPの既定ansible-coreは2.16に固定されている。2.5・2.6・2.7いずれもRed Hatの表記はansible-core 2.16で、OSS側の最新2.21とは5世代離れています。
• AAPのフルサポートはGAから約1年。2.6は2025-10-01 GAでフルサポート終了が2026-10-01、2.7は2026-06-02 GAで2027-06-02までです。フルサポートを維持する場合は、各版の終了日に合わせてアップグレードを計画します。

Ansibleの実体：SSHで接続してPythonを実行する仕組み

Ansibleの動作は単純です。Playbookを実行するマシン（コントロールノード）が、管理対象（マネージドノード）へOpenSSHで接続し、通常のPOSIX向けモジュールではPythonコードを転送して実行し、返されたJSONをタスクの成功・失敗や変更有無の判定に使います。公式ドキュメントはAnsible connects to POSIX managed nodes using OpenSSH by default.と明記しています。常駐プロセスが無いため、監視対象の増減やエージェントの版ずれといった管理が発生しません。接続ポートはSSHが22、Windows向けWinRMがHTTP 5985・HTTPS 5986です。

この設計では管理対象に専用エージェントを入れませんが、通常のPOSIXモジュールを動かすPythonなどの依存関係は管理対象側にも必要です。ansible-core 2.21が要求するPythonはコントロールノードで3.12〜3.14、マネージドノードで3.9〜3.14です。手元で2.21.4を入れた実測でも、Python 3.14.6上で動作しました。

Windowsノードを混ぜると増える前提条件

Windowsを管理対象に含める場合、接続方式はWinRM（winrm／psrpプラグイン）かSSHになります。ここで見落とされやすいのが依存関係で、公式ドキュメントはThese plugins have their own Python requirements that are not included in the Ansible package and must be installed separately.と書いています。pywinrm>=0.4.0やpypsrp<=1.0.0を、選んだWinRM系プラグインに応じてコントロールノードへ別途導入します。SSH接続では、これらのWinRM用ライブラリは不要です。コントロールノード自体については、公式ドキュメントがAnsible cannot run on Windows as the control node due to API limitations on the platform.と書いており、WSLかコンテナでの実行が案内されています。ただしWSLについては同じページにThe Windows Subsystem for Linux is not supported by Ansible and should not be used for production systems.という注記があるため、本番運用ではLinuxホストを用意します。

ansible-core・community package・AAPという3つのAnsible

導入検討で最初につまずくのがバージョン体系です。ansible-coreは「2.21」のように旧来の採番を続け、セマンティックバージョニングを採用しません。community packageは3.0.0以降でセマンティックバージョニングに移行し、85を超えるコレクションを同梱します。AAPはこの上に管理基盤を載せた商用製品で、2.7という別の採番です。

ansible-coreはおおむね5月と11月にメジャー版が出て、最新版とその前2世代が保守されます。community packageは年2回のメジャー版で、保守されるのは常に1系統だけです。この差が効くのは移行計画で、community package 13.xは2026年6月にEOL済み、14.xだけが現行です。

マネージドノードのPython 2.7対応はansible-core 2.16が最後で、2.17以降は打ち切られています。古いCentOS 7系を残したまま最新coreへ上げると、この行で止まります。

Playbookとアドホックコマンドの書き分け

Playbookは、設定や実行するタスクをYAMLで記述したファイルです。対象ホストはインベントリで定義します。以下をinventory.iniとsite.ymlとして同じディレクトリに保存し、ansible-playbook -i inventory.ini site.ymlで実行します。

# inventory.ini（手元で再現できるようローカル接続にしています）
[web]
localhost ansible_connection=local

# site.yml
- name: web config
  hosts: web
  gather_facts: false
  tasks:
    - name: set max_connections
      ansible.builtin.lineinfile:
        path: /tmp/ansible-demo/app.conf
        line: max_connections = 200
        create: true

    - name: append to log
      ansible.builtin.shell: echo hello >> /tmp/ansible-demo/deploy.log

    - name: run initializer once
      ansible.builtin.shell: echo init > /tmp/ansible-demo/init.done
      args:
        creates: /tmp/ansible-demo/init.done

一方、Playbookを書くまでもない一回限りの確認にはアドホックコマンドを使います。疎通確認のpingモジュールは、ICMPではなくPythonが起動できるかを見る点に注意してください。

$ ansible -i inventory.ini web -m ansible.builtin.ping
localhost | SUCCESS => {
    "changed": false,
    "ping": "pong"
}

対象を絞る--limit、タスクを絞る--tagsは、本番適用前に影響範囲を切るための最低限の装備です。GUIでジョブ管理まで行いたい場合は、OSSのWeb UIという選択肢もあります（Semaphore UIの基本機能と対応する自動化ツールの全体像）。

よく使うbuiltinモジュールと一覧の引き方

タスクの実体はモジュールです。ansible-core 2.21.4だけを入れた環境でansible-doc -l -t moduleを実行したところ、ansible.builtinのモジュールは71件でした。community package 14.4.0はこれに85を超えるコレクションを足すため、件数は桁が変わります。まず覚える範囲は用途別に区切ると絞れます。

個別の引数はansible-doc ansible.builtin.copyのようにコマンドで確認できます。専用モジュールがある処理をcommandやshellで書くと、次章のとおり冪等性とドライランの両方を失います。

冪等性が成り立つタスクと成り立たないタスク（2回実行の実測）

「何度実行しても同じ状態になる」かどうかは、使用するモジュールとタスクの記述に依存し、Playbook全体で確認する必要があります。公式ドキュメント自身がnot all playbooks and not all modules behave this wayと断っています。上のsite.ymlをansible-core 2.21.4で2回続けて実行した結果が以下です。

== RUN 1
TASK [set max_connections] *****************************************************
changed: [localhost]
TASK [append to log] ***********************************************************
changed: [localhost]
TASK [run initializer once] ****************************************************
changed: [localhost]
localhost : ok=3    changed=3    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

== RUN 2
TASK [set max_connections] *****************************************************
ok: [localhost]
TASK [append to log] ***********************************************************
changed: [localhost]
TASK [run initializer once] ****************************************************
ok: [localhost]
localhost : ok=3    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

2回目にokへ変わったのはlineinfileと、createsを付けたshellだけです。ガードの無いshellは2回目もchangedのままで、ログファイルの行数は2行に増えました。commandモジュールの公式ドキュメントはcreatesについてIf a matching file already exists, this step will not be run.と説明しており、任意コマンドを冪等にするのは書き手の責任です。実行結果で判定したい場合はchanged_whenで条件を書きます。

さらに危険なのはドライラン時の挙動です。同じPlaybookを--check付きで流すと、createsを指定していないログ追記タスクはskippingになります。creates付きの初期化タスクはファイルの有無を判定し、この例ではokになります。

== CHECK MODE
TASK [set max_connections] *****************************************************
ok: [localhost]
TASK [append to log] ***********************************************************
skipping: [localhost]
TASK [run initializer once] ****************************************************
ok: [localhost]
localhost : ok=2    changed=0    unreachable=0    failed=0    skipped=1    rescued=0    ignored=0

公式ドキュメントは理由をthe command itself is arbitrary and cannot be subject to the check mode semanticsと説明しています。つまりshellやcommandを多用したPlaybookほど--checkの結果は当てにならず、「ドライランが通ったから安全」という判断が成り立ちません。checkモードで検証されない処理が残ると、実行可否の判断を担当者の経験に依存しやすくなります。手順書のコマンドをそのままshellに貼り替えただけの移行はやめたほうがよい、というのがこの実測からの結論で、専用モジュールへ置き換えるか、再実行による副作用を防ぐ条件を設計し、必要に応じてcreatesなどで実行を制御します。changed_whenは変更の報告を調整する機能で、再実行や副作用を防ぐものではありません。

Ansibleの並列実行・接続・ファクト収集の既定値

台数が増えたときは、まず並列数、SSH接続の処理、ファクト収集の設定を確認します。実行時間には、通信遅延やタスク内容、コントロールノードの処理能力も影響します。ansible-core 2.21.4でansible-config dumpを取った実測値が以下です。

数百台規模ではansible.cfgの[defaults]でforksを引き上げ、[ssh_connection]でpipelining = trueにし、不要なplayではgather_facts: falseを指定するのが先です。pipeliningが既定で無効なのは、管理対象のsudo設定でrequirettyが有効だと失敗するためで、有効化前にその確認が要ります。

Red Hat Ansible Automation Platform（AAP）のデメリットと制約

OSSのAnsibleとAAPは、機能追加版という関係ではありません。AAPはWeb UI・RBAC・ジョブスケジューリング・認定コンテンツ・サポートを提供する商用プラットフォームで、課金単位はmanaged nodeです。Red HatのナレッジはRed Hat Ansible Automation Platform is sold and supported by counting the number of managed nodesと定義しています。評価目的であれば製品トライアルが用意されており、Red Hatのトライアル案内はMost product trials are 60 daysとしています。期間や条件は申込時に確認してください。

導入判断で効く制約は4つあります。

第一に、フルサポート期間がGAから約12か月しかない点です。2.6は2026-10-01でフルサポートを終え、Maintenance Support 1では、セキュリティ修正はCritical・Important、不具合修正はCriticalに限定されます。フルサポートの維持を要件とするなら、終了日前の移行に必要な人員と検証期間を確保すべきです。

第二に、既定のansible-coreが2.16に固定されている点です。Red Hatの注記はthe version of Ansible Core required to install and operate AAP for its supported lifecycle as well as the default version of Core in the platformで、2.5から2.7まで一貫して2.16です。より新しいcoreを使いたい場合はExecution Environmentイメージを切り替えますが、Red Hatが並行して供給しているのは2.16・2.18・2.20のEEで、2.21はここで挙げたRed Hat提供のサポート対象EEに含まれません。カスタムEEへの組み込み可否とRed Hatのサポート対象かどうかは別に判断する必要があります。

第三に、AAP 2.7でRPMインストールが提供されなくなり、RHEL 9／RHEL 10向けコンテナ型インストールやOpenShift上のOperator方式を選ぶ構成になった点です。加えて、ジョブの実行自体がコンテナ前提で、AAP 2.7のドキュメントはAll automation in Red Hat Ansible Automation Platform runs on container imagesと書いています。OSSでansible-playbookを直接叩いていたチームは、Execution Environmentのビルドと配布という新しい運用を抱えます。

第四に、サポート範囲が思ったより狭い点です。Red Hatが「Unsupported Activities」として挙げているのは、データベースのレプリケーションとフェイルオーバー、サードパーティのロガーやロードバランサー・認証との連携、カスタムAPI連携、そしてカスタムコンテンツとコレクションの開発・デバッグです。プラットフォーム自体の標準的な操作・運用は当然サポートされますが、自社で書いたロールやコレクションの中身は対象外になります。サブスクリプションで買えるのはプラットフォーム本体の面倒であって、自社Playbookの面倒ではありません。

ここまでを踏まえると、AAPが向くのは、承認フローや権限分離を監査要件として求められ、複数チームの実行を1か所で束ねたい組織です。数十台を少人数で管理し、必要な承認・権限分離・実行記録を既存のGitとCIで満たせるなら、OSSのansible-coreとCIを第一候補にできます。TerraformやChef・Puppetを含めた選定軸は構成管理ツールの比較と選び方｜Ansible・Terraform・Chef・Puppet・OpenTofuの選定条件で整理しています。

よくある質問

Ansibleの読み方は？

アンシブルです。Red Hatの日本語ページも見出しを「Ansible (アンシブル) とは？」と表記しており、日本語圏ではこの読みで定着しています。

AnsibleとTerraformはどちらを使うべきですか？

役割が重なる部分はありますが、出発点が違います。Terraformはクラウドリソースの作成と状態管理（プロビジョニング）、Ansibleは作られたサーバーの中身の設定（構成管理）に強みがあります。両方を使う構成も一般的で、Terraformでインスタンスを作りAnsibleで設定を流す分担がよく採られます。AWSであればCloudFormationも選択肢になります（AWS CloudFormationとは？テンプレートの書き方から使い方までわかりやすく解説）。

with_itemsはもう使ってはいけませんか？

使えます。公式ドキュメントはWe have not deprecated the use of with_<lookup>と明記しており、非推奨にはなっていません。Ansible 2.5で追加されたloopのほうが推奨されるのは事実ですが、既存Playbookのwith_itemsを急いで書き換える必要はありません。

Ansibleを入れれば属人化は解消しますか？

Playbookをリポジトリで管理し、レビューを通す運用とセットにして初めて効きます。shellにコマンドを並べただけのPlaybookは、手順書がYAMLになっただけで、前述のとおり--checkも効きません。専用モジュールで状態を宣言し、変数をgroup_vars・host_varsへ切り出して環境差を明示するところまでが属人化対策です。

Ansibleは無料で使えますか？

ansible-coreとcommunity packageはGPL-3.0のオープンソースで、PyPIからpip install ansible-coreで無償導入できます。有償なのはAAPで、managed node数に応じたサブスクリプション契約になります。Kubernetesクラスタ構築のように、OSSのAnsibleをそのまま使う周辺ツールも広く存在します（Kubesprayとは？Ansibleで作るKubernetesクラスター構築・運用・kubeadmとの違い）。

関連記事

• 構成管理ツールの比較と選び方｜Ansible・Terraform・Chef・Puppet・OpenTofuの選定条件
• Semaphore UIの基本機能と対応する自動化ツールの全体像
• Kubesprayとは？Ansibleで作るKubernetesクラスター構築・運用・kubeadmとの違い
• Paramikoとは？PythonでSSH接続・コマンド実行・SFTP転送を行う使い方【5.0対応】
• AWS CloudFormationとは？テンプレートの書き方から使い方までわかりやすく解説