Ansible(アンシブル)は、サーバーやネットワーク機器に対する設定作業をYAMLで書き、SSHなどで接続してまとめて適用するオープンソースの自動化ツールです。管理対象に常駐エージェントを入れず、手元のマシンから「この状態にしておく」という宣言を流します。この記事では、2026年11月2日に公開されたansible-core 2.22.0を実際に動かした出力と、公式ドキュメント・Red Hatのライフサイクル情報をもとに、仕組み・できること・メリットとデメリットを整理します。
まとめ:Ansibleを理解するための5つの要点
- Ansibleは「手元から接続して設定を流す」道具。Playbookを実行するコントロールノードが、管理対象へSSH(WindowsはWinRMかSSH)で接続し、モジュールを転送して実行します。管理対象側に専用エージェントもデータベースも要りません。
- できることは「既にあるマシンの中身を整える」作業が中心。パッケージ導入・設定ファイル配布・サービス起動・ユーザー作成・アプリのデプロイ・ネットワーク機器の設定変更が得意分野で、クラウド上のリソースを作って状態を管理する仕事はTerraformのほうが向きます。
- 冪等性はモジュールと書き方で決まる。
lineinfileで書いた行の追加は2回目に何もしませんが、ガードの無いshellは毎回実行され、--checkではスキップされて結果を予測できません。 - 最新は ansible-core 2.22.0。コントロールノードにPython 3.13〜3.15が必要で、2.21までの3.12は対象外になりました。コレクション同梱の community package は14.5.0(2.21系)が現行です。
- 商用版のRed Hat AAPは別物として考える。AAP 2.7の既定ansible-coreは2.16で、OSSの最新版とは版が大きく離れています。
Ansibleでできること:サーバー設定・デプロイ・ネットワーク機器・Windows
公式のインストールガイドは、Ansibleがコントロールノードからremotely with SSH, Powershell remoting, and numerous other transports, all from a simple command-line interface with no databases or daemons requiredで多数の機器を管理すると説明しています(Installing Ansible)。実務で自動化の対象になるのは次の作業です。
| 自動化する作業 | 使うモジュール・コレクションの例 | 手順を詳しく扱う記事 |
|---|---|---|
| OSの初期設定・パッケージ導入 | ansible.builtin.dnf・apt・user | 使い方入門 |
| 設定ファイルの配布・サービス再起動 | template・service・handlers | Playbookの書き方 |
| ルーター・スイッチの設定変更 | ansible.netcommon・cisco.ios | ネットワーク自動化 |
| Windowsサーバーの設定 | ansible.windows | Windows管理 |
| Kubernetesクラスタの構築 | Kubespray(Ansibleのロール集) | Kubespray |
| クラウドで作ったサーバーの設定 | Terraformの出力をインベントリに渡す | Terraform連携 |
反対に、Ansibleが苦手なのは「作ったリソースを記録しておき、コードから消したら実物も消す」管理です。Ansibleは実行のたびに管理対象の現状を調べて差分を当てる方式で、Terraformのような状態ファイルを持ちません。クラウドのVPCやインスタンスを作る仕事はTerraform、できたサーバーの中身を整える仕事はAnsibleという分担が基本になります。ツールごとの選定条件は構成管理ツールの比較と選び方|Ansible・Terraform・Chef・Puppet・OpenTofuの選定条件で比較しています。
Ansibleの仕組み:コントロールノードからの接続とモジュール実行
Playbookを実行するマシン(コントロールノード)が、管理対象(マネージドノード)へ接続し、LinuxなどのPOSIX系ではモジュールのPythonコードを転送して実行します。結果はJSONで返り、Ansibleはそれをもとに「ok(変更なし)」「changed(変更あり)」「failed」を判定します。公式ドキュメントはAnsible connects to POSIX managed nodes using OpenSSH by default.と書いており(Managing Windows hosts with Ansible)、接続ポートはSSHが22、WindowsのWinRMがHTTP 5985・HTTPS 5986です。
「エージェントレス」でも、管理対象に何も要らないわけではありません。POSIX系の管理対象にはモジュールを動かすPythonが必要で、ansible-core 2.22が対象にするのは管理対象側でPython 3.9〜3.15、コントロールノード側で3.13〜3.15です(Releases and maintenance)。ルーターやスイッチは例外で、モジュールをコントロールノード側で動かし、機器に応じてnetwork_cli(CLI)・netconf・httpapiのいずれかの接続で操作します(Working with network connection options)。
Ansibleを構成する要素:インベントリ・Playbook・モジュール・ロール・コレクション
Ansibleの用語は、公式のAnsible conceptsで定義されています。最初に押さえるのは次の8つです。
| 用語 | 役割 | 実体の例 |
|---|---|---|
| コントロールノード | ansibleコマンドを実行するマシン | Linux・macOSの端末やCIランナー |
| マネージドノード | 設定される側のサーバー・機器 | web01、ルーター |
| インベントリ | 管理対象とグループの一覧 | inventory.ini・inventory.yml |
| Playbook | プレイを並べたYAMLファイル | site.yml |
| プレイ・タスク | 対象ホストと、順に実行する処理 | hosts: web/tasks: |
| モジュール | タスクの中身になる処理単位 | ansible.builtin.copy |
| ロール | タスク・変数・テンプレートの再利用単位 | roles/nginx/ |
| コレクション | モジュール・プラグイン・ロールの配布単位 | cisco.ios・amazon.aws |
よく聞かれる「Ansibleサーバー」は、多くの場合このコントロールノードを指します。常駐サーバーを立てる必要はなく、ansible-coreを入れた作業用のLinuxマシンがそのまま「Ansibleサーバー」になります。Web画面からジョブを実行したい場合に初めて、AWXやRed Hat AAP、Semaphore UIのような実行基盤を別に立てます。
Windowsを混ぜるときの前提条件
Windowsは管理対象にはできますが、コントロールノードにはできません。公式ドキュメントはAnsible cannot run on Windows as the control node due to API limitations on the platform.と書き、WSLかコンテナでの実行を案内しつつ、WSLについてshould not be used for production systemsと注記しています。本番の実行元はLinuxホストを用意します。WinRMで接続する場合は、コントロールノードにpywinrmまたはpypsrpを別途入れます。接続設定の手順はAnsibleでWindowsを管理する手順:WinRM・SSHの接続設定とansible.windowsのPlaybook例【2.21系】にまとめています。
ansible-core・community package・AAPの違いと最新版
「Ansible」と呼ばれるものは3つあり、版の数え方がそれぞれ違います。Ansibleは2015年10月16日にRed Hatが開発元のAnsible, Inc.の買収を発表し(Red Hatの発表)、現在はOSSの2つをコミュニティが、商用のAAPをRed Hatが提供しています。
| 名称 | 最新版(2026年11月5日確認) | 中身 | 入手 |
|---|---|---|---|
| ansible-core | 2.22.0(2026-11-02) | 実行エンジンとansible.builtin | PyPI(無償) |
| Ansible community package | 14.5.0(2026-10-06) | core 2.21+85超のコレクション | PyPI(無償) |
| Red Hat AAP | 2.7(2026年6月 GA) | Web UI・RBAC・実行環境・サポート | サブスクリプション |
ansible-coreは毎年5月と11月に新しい系列が出て、最新とその前の2系列が保守されます。PyPIのansible-coreでは2.22.0と同じ日に2.21.6・2.20.11も公開されています。community packageの次の15.0.0は公式の表で「In development (unreleased)」で、2.22を取り込む予定です。pip install ansibleで入るのは現時点では2.21系だという点に注意してください。
| ansible-core | GA | EOL | コントロールノード | マネージドノード |
|---|---|---|---|---|
| 2.22 | 2026年11月 | 2028年5月 | Python 3.13〜3.15 | Python 3.9〜3.15 |
| 2.21 | 2026年5月 | 2027年11月 | Python 3.12〜3.14 | Python 3.9〜3.14 |
| 2.20 | 2025-11-03 | 2027年5月 | Python 3.12〜3.14 | Python 3.9〜3.14 |
| 2.19 | 2025-07-21 | 2026年11月 | Python 3.11〜3.13 | Python 3.8〜3.13 |
2.22へ上げるときに止まりやすいのはコントロールノードのPythonです。RHEL 9やUbuntu 24.04の標準Python(3.9・3.12)のままではpip install ansible-core==2.22.0が入りません。CIのランナーイメージも含めて、先にPython 3.13以上を用意します。2.22では、登録した秘密値を出力時に$REDACTED$へ置き換えるsecret maskingが入りました(Porting guide for 2.22)。ログに値がそのまま出ることを前提にした確認手順は、上げる前に見直します。
Playbookの例と冪等性:ansible-core 2.22.0で2回実行した結果
Ansibleの説明でよく出る「何度実行しても同じ状態になる(冪等性)」は、Ansible全体の保証ではありません。公式ドキュメント自身がnot all playbooks and not all modules behave this wayと断っています(Ansible playbooks)。次の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
ansible-core 2.22.0(コントロールノードはPython 3.14.6、管理対象側は自動検出されたpython3.15)で2回続けて実行し、続けて--check付きで流した結果のPLAY RECAPです。
== RUN 1
localhost : ok=3 changed=3 unreachable=0 failed=0 skipped=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
== 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
2回目にokへ変わったのはlineinfileと、createsを付けたshellだけでした。ガードの無いshellは2回目もchangedで、deploy.logは2行に増えています。--checkではこのタスクがskippingになり、公式ドキュメントは理由をthe command itself is arbitrary and cannot be subject to the check mode semanticsと説明しています(ansible.builtin.shell)。shellやcommandを多く使ったPlaybookほど、ドライランが通っても安全とは言えません。手順書のコマンドをshellに貼り替えただけの移行はやめ、専用モジュールに置き換えるか、creates・removesで実行条件を付けます。handlersや--check --diffを使った段階的な流し方はAnsible Playbookの書き方と実行手順:–checkでのdry-runとhandlers【2.21系】で解説しています。
Ansibleのメリットとデメリット
メリット:エージェント不要の導入・YAMLの可読性・状態の宣言
- 既存サーバーにそのまま使える。SSHで入れてPythonがあれば動くので、エージェントの配布・版合わせ・常駐プロセスの監視が要りません。
- 手順がレビューできる形で残る。YAMLのPlaybookをGitで管理すれば、誰がいつ何を変えたかが差分で追えます。
- 専用モジュールは状態を宣言できる。
state: presentのように「あるべき状態」を書くモジュールは、既に満たしていれば変更しません。ansible-core 2.22.0だけを入れた環境でansible-doc -l -t moduleを実行すると、ansible.builtinのモジュールは71件ありました。community packageはこれに85を超えるコレクションを足します。
デメリット:既定の並列数の少なさ・shell多用による冪等性の欠落・Pythonの版への追随
1つ目は実行速度です。ansible-core 2.22.0でansible-config dumpを取ると、既定値は次のとおりでした。
| 設定 | 既定値 | 影響 |
|---|---|---|
| DEFAULT_FORKS | 5 | 100台でも同時に処理するのは5台 |
| ANSIBLE_PIPELINING | False | タスクごとのSSH往復が増える |
| DEFAULT_GATHERING | implicit | プレイごとにファクト収集が走る |
| DEFAULT_TIMEOUT | 10 | 接続タイムアウト(秒) |
数百台を扱うなら、ansible.cfgでforksを引き上げ、pipeliningを有効にし、ファクトが要らないプレイではgather_facts: falseにします。pipeliningが既定で無効なのは、管理対象のsudo設定でrequirettyが有効だと失敗するためです。
2つ目は、前章のとおりshellやcommandを多用すると冪等性と--checkが効かなくなる点です。3つ目は、Pythonの版に追随する手間です。同じMacで管理対象のPythonを自動検出させたところ、ansible-core 2.21.6はpython3.14を、2.22.0はpython3.15を選び、どちらも「別のPythonを入れると検出結果が変わりうる」という警告を出しました。インベントリでansible_python_interpreterを指定すると警告は消え、coreを上げても実行するPythonが変わりません。本番では明示しておくのが安全です。
OSSのAnsibleとRed Hat AAPの違い:既定のansible-coreは2.16
Red Hat Ansible Automation Platform(AAP)は、OSSのAnsibleにWeb UI・権限管理(RBAC)・ジョブのスケジュール実行・認定コンテンツ・ベンダーサポートを載せた商用製品です。Red Hatのライフサイクルページでは、AAP 2.5・2.6・2.7のいずれも既定のansible-coreが2.16です。より新しいcoreは実行環境(Execution Environment)のイメージで選び、2.18はAAP 2.5〜2.7で、2.20はAAP 2.7だけで提供されます。OSSの最新2.22とは版が離れているため、コミュニティの記事やドキュメントで覚えた新しい書き方がAAPの既定環境では動かないことがあります。
AAP 2.7はRPMでのインストールが提供されず、RHEL 9・RHEL 10へのコンテナ型インストールかOpenShift上のOperatorが前提です。フルサポート期間も約1年で、AAP 2.6はGAの2025-10-01から1年後の2026-10-01にフルサポートを終えています。費用の決まり方と契約すべき条件はAnsible Automation Platformの費用と導入判断:AWX・ansible-coreとの違いと契約すべき条件、旧Ansible Towerとの関係はAnsible Towerとは:automation controllerへの改称とSurvey・Webhook・RBACの設定手順【AAP 2.7】、無償の上流版はAnsible AWXとは:AWX OperatorでKubernetesへ導入する手順とAAPとの違い【2.19.1】で扱っています。
数十台を数名で管理していて、承認や実行記録をGitとCIで満たせるなら、ansible-coreとCIで足ります。AWSなどクラウド側の構築と合わせてAnsibleの導入を外部に任せる場合は、インフラ構築(AWS・Google Cloud・Azure)の支援でも相談を受けています。
Ansibleを学ぶ順番:使い方入門からVault・Galaxy・テストまで
Ansibleの仕組みをつかんだら、次の順で手を動かすと、つまずく箇所を1つずつ片づけられます。
- Ansibleの使い方入門:インストールからアドホックコマンド・最初のPlaybookまで【2.21系】:pipでの導入、ansible.cfgとインベントリ、アドホックコマンド
- Ansible Playbookの書き方と実行手順:handlers、変数の置き場所、ロールへの分割
- Ansible Vaultの使い方:encrypt_stringとvault-idで機密変数を暗号化しCIで復号する手順【2.21系】:パスワードや鍵をGitに平文で置かない
- Ansible Galaxyの使い方:ansible-galaxyコマンドとrequirements.ymlでロール・コレクションを管理する手順【2.21系】:コレクションの版を固定する
- Ansible Moleculeとは?v26系のansible-native設定とmolecule testの実行手順:ロールをテストしてから本番へ流す
ネットワーク機器が対象なら、2の次にCisco機器をAnsibleで設定変更する手順:cisco.ios・cisco.nxos・cisco.aciのPlaybook例【2026年10月】へ進みます。
よくある質問
Ansibleの読み方と名前の意味は?
読み方は「アンシブル」です。名前はSF小説に由来し、opensource.comの記事は、アーシュラ・K・ル=グウィンの『ロカノンの世界』に登場する超光速通信装置「ansible」から、開発者のMichael DeHaan氏が借りたと説明しています(What’s in an open source name?)。離れた機械を一斉に操るソフトウェアに合う名前として選ばれました。
Ansibleは無料で使えますか?
ansible-coreとcommunity packageはGPL-3.0のオープンソースで、pip install ansible-coreで無償で導入できます。有償なのはRed Hat AAPで、管理するノード数に応じたサブスクリプション契約です。
AnsibleとTerraformはどちらを使うべきですか?
役割が違うので、クラウドのリソース作成とサーバー内の設定を両方コードで管理したい場合は併用します。Terraformはクラウドのリソースを作って状態ファイルで管理し、Ansibleは作られたサーバーの中身を設定します。Terraformで作ったホストをAnsibleのインベントリに渡す方法はTerraformとAnsibleの連携手順:インベントリの受け渡しとactionsでの自動実行【2026年10月】で解説しています。
Ansibleの冪等性とは何ですか?
同じPlaybookを何度実行しても、2回目以降は変更が起きず同じ状態に収まる性質です。成り立つかどうかはモジュールと指定内容で決まり、lineinfileのように状態を宣言するタスクは2回目に変更なしになる一方、ガードの無いshellやcommandは毎回実行されます。冪等性の考え方そのものは冪等性とは?読み方・意味からAPI・IaCでの担保方法まで実装者向けに解説で扱っています。
Ansibleを入れれば作業の属人化は解消しますか?
Playbookをリポジトリで管理し、レビューを通す運用とセットにして初めて効きます。shellにコマンドを並べただけのPlaybookは手順書がYAMLになっただけで、--checkも効きません。専用モジュールで状態を宣言し、環境ごとの差をgroup_vars・host_varsへ切り出すところまで進めて、担当者が替わっても同じ結果を出せるようになります。