Ansibleとは？最短で自動化を始める準備とPlaybook設計の決定版ガイド

手順書通りなのに環境が揃わない、毎回changedになる、機密情報やCI/CDが不安――Ansibleを始めたい人ほど直面する壁は多いもの。

この記事は、最短の準備からPlaybook設計、インベントリとスケール設計、AWX活用、トラブル解決までを実務の型で解説します。

外資系エンジニア

この記事は以下のような人におすすめ！

Ansibleとは何か知りたい人

Ansible と Ansible-core の違いが知りたい

機密情報やCI/CDが不安な人

1 Ansibleとは何か
2 最短で始める準備と基本用語
3 Playbookの書き方・設計指針
4 実務で効く運用ノウハウ
5 スケールさせる導入設計

Ansibleとは何か

Ansibleは、サーバやネットワーク機器、クラウド、コンテナなどを一括して自動化するためのオープンソースツールです。

構成管理、アプリケーションのデプロイ、そして環境全体のオーケストレーションを、人が読みやすいYAML（Ansible Playbook）で記述できます。

つまり、複雑な運用を「手順書」から「実行可能なコード」に変えることで、手作業のばらつきやヒューマンエラーを減らし、再現性の高い運用を実現します。

1-1. Ansibleでできること（構成管理・デプロイ・オーケストレーションの全体像）

1-1-1. 構成管理の自動化

Ansibleは「所望の状態」を宣言的に記述し、パッケージ・サービス・ファイルを意図した状態に揃えます。

したがって、同じPlaybookを複数回流しても結果は変わらない（冪等）点が強みです。
例として、以下のような日常作業を自動化できます。

パッケージのインストール／更新
設定ファイルの配布と権限設定
サービスの起動、再起動、ステータス統一
ユーザーやグループの作成

1-1-2. アプリケーションデプロイ

Ansibleはアプリのビルド、配布、設定、サービス起動までを一気通貫で流せます。

例えば、ローリングデプロイでダウンタイムを抑えたり、複数階層（Web／AP／DB）の更新順序を保証したりできます。

その結果、手順の抜け漏れを防ぎ、安定したリリースを継続できます。

1-1-3. オーケストレーション（環境横断の連携）

複数サーバや複数クラウドにまたがる作業を一連のワークフローとして記述し、順序や依存関係を制御できます。

なぜなら、インベントリ（対象一覧）とグループ変数、そして条件分岐・ハンドラを組み合わせることで、環境差分や例外ケースにも対応できるからです。

1-1-4. 対象領域の広さ（クラウド・ネットワーク・コンテナ）

Ansibleはモジュールとコレクションを通じ、AWSやAzureなどのクラウド、Ciscoなどのネットワーク機器、さらにはDockerやPodmanの操作まで幅広く扱えます。

つまり、運用の自動化を一つの言語（YAML）で統一しやすいのです。

1-2. 仕組みの基礎（エージェントレス、SSH/WinRM、モジュール実行の流れ）

1-2-1. エージェントレスとは

Ansibleはターゲット側に常駐エージェントを入れません。コントロールノードから都度モジュール（小さな実行単位）を配布し、処理して結果を回収します。

だから、導入が軽く、既存環境に影響を与えにくいのが特徴です。

1-2-2. 接続方式（SSHとWinRM）

LinuxやUnix系は主にSSH、WindowsはWinRMで接続します。必要に応じて特権昇格（become）を使い、root権限相当の操作も安全に実行可能です。

1-2-3. モジュール実行の流れ

一般的な流れは次の通りです。

インベントリで対象ホストを特定
事前情報（facts）を収集
タスクごとに該当モジュールを転送・実行
結果（JSON）を回収し、状態変化を記録
必要に応じてハンドラでサービス再起動や次工程へ連携
この仕組みにより、Ansibleは「現在の状態」を理解したうえで、安全に変更を適用します。

1-2-4. インベントリと変数管理

静的ファイルや動的インベントリ（クラウドAPI連携）で対象を管理できます。

グループ変数・ホスト変数を使えば、環境ごと（開発・検証・本番）や役割ごと（web、db）に設定を切り替えられます。

1-2-5. PlaybookとRole（再利用の基本）

Ansible PlaybookはYAMLでタスクの順序と条件を記述します。

さらにRoleへ分割すればディレクトリ構成が定まり、テンプレート、ファイル、ハンドラ、タスクが整理され、再利用性が高まります。

Ansible GalaxyやCollectionsを使えば、社内外の知見を簡単に取り込めます。

1-3. 他ツールとの比較（Terraform・Puppet・Chef・Saltの違い）

1-3-1. 目的と実行モデルの違い（早見表）

ツール	主目的（得意分野）	実行モデル	エージェント有無	記述スタイル	向く場面の例
Ansible	構成管理・デプロイ・オーケストレーション	プッシュ型	なし（エージェントレス）	YAML（Playbook）	手早い自動化、混在環境
Terraform	インフラのプロビジョニング（作成・変更）	プラン＋適用（宣言的）	なし	HCL（宣言的）	VPCやVM、マネージドサービスの作成
Puppet	継続的な状態維持（構成管理）	プル型（常駐）	あり	DSL（宣言的）	大規模で厳密なコンプライアンス
Chef	構成管理・デプロイ	プル型（常駐）	あり	Ruby DSL（手続き寄り）	ルビー文化圏、柔軟なレシピ
Salt（SaltStack）	構成管理・イベント駆動	プル／プッシュ両対応	あり／なし（salt-ssh）	YAML（Jinja併用）	高頻度イベントや即時反応

1-3-2. TerraformとAnsibleの関係

Terraformは「基盤を作る」のが得意で、Ansibleは「中身を整える」のが得意です。

したがって、Terraformでネットワークやサーバ資源を用意し、その後にAnsibleでOS設定やアプリ配布を行う併用が実践的です。

1-3-3. Puppet／ChefとAnsibleの違い

PuppetやChefはエージェント常駐のプル型で、継続的な状態維持やドリフト検知を得意とします。

一方、Ansibleはプッシュ型で導入が軽く、アドホックな変更や段階的展開に強みがあります。

つまり、長期的なコンプライアンス重視ならPuppet／Chef、素早い自動化や混在環境ならAnsibleが選びやすいと言えます。

1-3-4. SaltとAnsibleの違い

Saltはイベントドリブンな自動化や即時性に強みがあり、大量ノードへの一斉配布が高速です。

対してAnsibleは学習コストが比較的低く、コミュニティとモジュールの裾野が広いのが利点です。

用途やチームのスキルに合わせて選択しましょう。

1-4. 向いているケース／向かないケースの判断基準

1-4-1. Ansibleが向いているケース

エージェントを入れにくいセキュリティ要件の環境
複数OS・クラウド・ネットワーク機器が混在する環境
手順書ベースの運用をYAML化して標準化したい場合
CI/CDパイプラインに組み込み、デプロイを安定化したい場合
インシデント対応やアドホック作業を安全に繰り返したい場合
Ansible Vaultで秘匿情報（パスワード・鍵）を安全に扱いたい場合

1-4-2. Ansibleが向かない／注意が必要なケース

常時エージェントによる厳密なドリフト監視・強制が必要な場合（Puppet等が適合）
サーバ台数が非常に多く、秒単位の即応・イベント駆動が必須な場合（Salt等を検討）
ほぼすべてがコンテナ／Kubernetesで、宣言的に完結している場合（KubernetesやHelmで統一）
超大規模なインフラ作成・変更の計画性（依存関係管理）が主目的の場合（Terraformが適合）

1-4-3. 判断チェックリスト（簡易）

変更は「ときどきまとめて」か、「常時監視して即時修正」か
異種環境（OS・クラウド・機器）の横断が多いか
手順書の属人化を解消したいか
学習しやすさ・導入しやすさを優先したいか
既存のCI/CDや秘密情報管理と統合しやすいか

1-4-4. 導入時のベストプラクティス

まずは小さなPlaybookから開始し、Role化して再利用性を高める
変数・テンプレート・条件分岐を活用し、環境差分を一本化
Lintやテスト（Molecule等）で品質を継続的に検証
Ansible Collections／Galaxyを活用して標準モジュールを優先
インベントリはグルーピングと命名規約を徹底
秘密情報はAnsible Vaultで暗号化し、リポジトリは権限分離
実行ログと変更履歴を記録し、ロールバック方針を明確化

最短で始める準備と基本用語

Ansibleを最短で使い始めるために、まずは「入れる・つなぐ・動かす」の三拍子を押さえましょう。

つまり、動作要件を満たしインストールし、基本用語を理解し、最小のYAMLとディレクトリで形を作り、最後にad-hocコマンドで「できる」体験を積みます。

したがって、本章は実務でそのまま使える最短ルートに絞って解説します。

2-1. 動作要件とインストール（Linux/Mac/Windowsのポイント）

2-1-1. 事前要件（最短チェックリスト）

制御ノード：Ansibleを実行する端末（Linux/macOS/WSLを推奨）
管理対象（Linux系）：Python 3系がほぼ必須（raw等の例外を除く）
管理対象（Windows）：Pythonは不要。WinRM（PowerShell）で接続
通信要件：Linux系はSSH、WindowsはWinRMが到達可能であること
資格情報：SSH鍵（推奨）またはパスワード。Windowsは管理者権限の資格情報

2-1-2. OS別の入れ方（要点早見表）

環境	推奨インストール	コマンド例のイメージ	補足
Linux（Debian/Ubuntu）	パッケージ or pip	aptで`ansible`または`ansible-core`	なるべく最新が必要ならpip/仮想環境を検討
Linux（RHEL/Fedora系）	dnfで`ansible-core`	`sudo dnf install ansible-core`	追加のCollectionsは後から入れる
macOS	Homebrew	`brew install ansible`	すぐ使いたい人向け。Python仮想環境も可
Windows（制御）	WSLでLinux化	WSL上でLinux手順を実施	だからWindowsでもUnix系と同様の体験に
Windows（管理対象）	事前にWinRM有効化	Inventoryで`connection=winrm`	ドメイン/証明書方針に合わせて設定

ポイントは、まず制御ノードをLinux/macOS（またはWSL）に寄せること。

なぜなら、Ansibleのエコシステムと相性が良く、トラブルシュートが楽だからです。

2-1-3. すぐ使えるインストール例

Linux（例：Ubuntu）

sudo apt update sudo apt install -y ansible ansible --version

Fedora/RHEL系（例：Fedora）

sudo dnf install -y ansible-core ansible --version

macOS（Homebrew）

brew update brew install ansible ansible --version

Python仮想環境での導入（どのOSでも再現性が高い）

python3 -m venv .venv source .venv/bin/activate # Windowsは .venv\Scripts\activate
pip install --upgrade pip
pip install ansible-core # 追加機能が多いmetaパッケージは 'ansible'

2-1-4. Windows管理対象の準備（最短の考え方）

WinRMを有効化（組織ポリシーに合わせたスクリプトを適用）
インベントリで接続方式を指定

[windows]
win01 ansible_host=192.0.2.10

[windows:vars]
ansible_connection=winrm
ansible_user=Administrator
ansible_password=＜安全な方法で管理＞
ansible_port=5986
ansible_winrm_server_cert_validation=ignore # 検証用。商用は適切な証明書で

2-1-5. バージョン管理の考え方（ansible-core と collections）

ansible-core：エンジン＋基本モジュール。軽量で読み替えが少ない
ansible：多数のCollectionを同梱。手早く広範囲を触りたいときに便利
その結果、チームで統一する場合はrequirements.ymlでCollectionsを固定し、仮想環境で隔離するのが安全です。

2-2. 基本用語：制御ノード・管理対象・インベントリ・モジュール・タスク

2-2-1. 制御ノード（Control Node）

Ansibleコマンドを実行する端末のことです。ここにPlaybookやインベントリ、設定ファイルを置き、SSH/WinRM越しに管理対象へ指示を送ります。

2-2-2. 管理対象（Managed Node）

設定を適用されるサーバやネットワーク機器です。LinuxではPythonが、WindowsではPowerShell/WinRMが要となります。つまり、常駐エージェントは不要です。

2-2-3. インベントリ（Inventory）

対象ホストの一覧と属性を定義します。INI風/YAMLのどちらでも記述でき、グループ化や変数割り当てが可能です。したがって、環境（dev/stg/prod）や役割（web/db）ごとに整理できます。

2-2-4. モジュール（Module）

各タスクで呼び出される最小実行単位です。packageやservice、copy、user、Windowsならwin_*系など、目的別に用意されています。

2-2-5. タスク（Task）とハンドラ（Handler）

タスクは「やること」の列挙、ハンドラは状態が変わったときだけ呼ばれる「後処理」（例：サービス再起動）です。この仕組みにより、Ansibleは冪等で安全に変更します。

2-2-6. Play と Playbook

Playは「どのホストに何をするか」のひとまとまり。PlaybookはそれらをYAMLで記述したファイル群です。つまり、運用手順をコード化した“実行可能な手順書”です。

2-2-7. 変数・テンプレート・Facts

変数：group_vars/host_varsやvarsで値を切り替え
テンプレート：Jinja2で設定ファイルを動的生成
Facts：対象ホストから収集した情報（OS種別、IP、メモリ等）

2-3. YAML基礎とプロジェクト構成（ディレクトリの型）

2-3-1. YAMLの最小ルール（Ansibleで困らないために）

インデントは半角スペース（推奨2または4）。タブは使わない
配列は - 、辞書は key: value で表現
文字列にコロンや特殊文字が入る場合はクォートで明示
だから、まずは整形ルールをチームで統一すると事故が減ります

2-3-2. 最小のPlaybook例（Linuxへパッケージ導入）

# site.yml
– name: Install and start nginx
hosts: web
become: true
tasks:
– name: Ensure nginx is present
ansible.builtin.package:
name: nginx
state: present

– name: Ensure nginx is running
ansible.builtin.service:
name: nginx
state: started
enabled: true

2-3-3. インベントリ例（INI と YAML）

INI風

[web]
web01 ansible_host=192.0.2.21
web02 ansible_host=192.0.2.22

YAML

all:
children:
web:
hosts:
web01: { ansible_host: 192.0.2.21 }
web02: { ansible_host: 192.0.2.22 }

2-3-4. 推奨ディレクトリ（小規模〜中規模の型）

project/
├─ site.yml
├─ inventories/
│ ├─ dev/hosts
│ └─ prod/hosts
├─ group_vars/
│ ├─ all.yml
│ └─ web.yml
├─ host_vars/
│ └─ web01.yml
├─ roles/
│ └─ webserver/
│ ├─ tasks/main.yml
│ ├─ templates/
│ ├─ files/
│ ├─ handlers/main.yml
│ └─ defaults/main.yml
└─ ansible.cfg

roles/に機能単位で分割し再利用性アップ
ansible.cfgでプロジェクトローカル設定を固定

2-3-5. ansible.cfg（最初に効く最小設定）

[defaults]
inventory = ./inventories/dev/hosts
forks = 20
retry_files_enabled = False
stdout_callback = yaml

[privilege_escalation]
become = True
become_method = sudo

開発初期は簡潔に。なぜなら、設定が少ないほど原因切り分けが容易だからです。

2-4. 初めての実行：ad-hocコマンドで「できる」を体感

2-4-1. 疎通確認（LinuxとWindows）

Linux系

ansible all -i inventories/dev/hosts -m ansible.builtin.ping

Windows系

ansible windows -i inventories/dev/hosts -m ansible.windows.win_ping

2-4-2. よく使うad-hoc（パッケージ／サービス／ファイル）

パッケージ導入（OS差を吸収するpackage）

ansible web -i inventories/dev/hosts -b \
-m ansible.builtin.package -a "name=curl state=present"

サービス起動・自動起動

ansible web -i inventories/dev/hosts -b \
-m ansible.builtin.service -a "name=nginx state=started enabled=true"

設定ファイル配布

ansible web -i inventories/dev/hosts -b \
-m ansible.builtin.copy -a "src=./files/index.html dest=/var/www/html/index.html mode=0644"

2-4-3. 失敗しないための実行オプション

--check：変更せずに差分だけ確認（ドライラン）
--diff：設定ファイルの差分を表示
-K：sudoパスワードを都度入力（必要なときだけ）
--limit web01：特定ホストに限定して安全に試行
つまり、まずは小さく当ててから全体へ広げるのが定石です。

2-4-4. 次の一歩：ad-hocからPlaybookへ

ad-hocで効果を確認できたら、同じ操作をPlaybook化してロールへ分割します。

その結果、レビューしやすく再現性も高まり、Ansibleをチームの標準運用に組み込みやすくなります。必要に応じて、ansible-galaxy initでRoleの骨格を自動生成し、requirements.ymlでCollectionsを固定しましょう。

Playbookの書き方・設計指針

Ansible Playbookは「人間が読める運用手順」を「安全に繰り返せるコード」に変える設計が肝心です。

つまり、冪等（同じPlaybookを何度流しても同じ状態に収束）を第一原則に、変数とテンプレートで差分を吸収し、条件分岐とループで重複を排除、さらにハンドラーやタグで再実行を速くします。

したがって、本章では実務でそのまま使えるAnsibleの設計指針を、例と型で整理します。

3-1. タスクとモジュールの基本（idempotent思考）

3-1-1. 冪等（idempotent）とは何か

Ansibleは多くのモジュールが状態を宣言的に扱います（present、absent、startedなど）。

だから、同じPlaybookを再実行しても不要な変更が起きません。

加えて、--check（ドライラン）や--diffを組み合わせれば、変更前に安全に確認できます。

– name: nginxをインストールし起動状態にする
hosts: web
become: true
tasks:
– name: nginxを導入
ansible.builtin.package:
name: nginx
state: present
– name: nginxを起動し自動起動
ansible.builtin.service:
name: nginx
state: started
enabled: true

3-1-2. 典型パターンとアンチパターン（早見表）

ゴール	推奨モジュール/手法	例	アンチパターン
パッケージを入れる	`package`	`state: present`	`shell: apt install ...` の手書き
設定ファイル配布	`template`/`copy`	`validate`で構文検証	上書きだけして再起動を忘れる
一度きりの初期化	`command` + `creates`	目印ファイルで再実行防止	無条件で`command`を毎回実行
外部資材の展開	`unarchive`	`creates`で再展開防止	都度展開して毎回changed

– name: スキーマ初期化（済なら実行しない）
ansible.builtin.command: /usr/local/bin/initdb
args:
creates: /var/lib/myapp/.initialized

3-1-3. 変更検知と失敗判定の制御

registerで結果を受け取り、changed_whenやfailed_whenで厳密に制御します。

つまり、モジュールが提供する冪等だけで足りない場合の保険です。

name: ip_forward値を確認（読み取りのみ）
ansible.builtin.shell: “sysctl -n net.ipv4.ip_forward”
register: ipf
changed_when: false

– name: 値が0なら設定を更新
ansible.builtin.lineinfile:
path: /etc/sysctl.conf
regexp: ‘^net.ipv4.ip_forward=’
line: ‘net.ipv4.ip_forward=1’
when: ipf.stdout | int == 0
notify: sysctl-apply

3-2. 変数・テンプレート（Jinja2）・ファイル配布

3-2-1. 変数の設計（最小ルール）

Ansibleの変数優先順位は複雑ですが、実務では次の簡略ルールで十分です。

なぜなら、役割（Role）を中心に据えると衝突が起きにくいからです。

既定値はroles/<role>/defaults/main.ymlに置く
環境差分はgroup_vars/host_varsで上書き
一時的な切り替えは--extra-varsで明示
重要値はansible-vaultで暗号化

3-2-2. テンプレート（Jinja2）の基本

templateで設定ファイルを生成し、可能ならvalidateで構文検証、notifyで必要時のみ再起動します。

したがって、誤配布や無駄な再起動を防げます。

# tasks/main.yml
– name: nginx.confを配布（構文検証付き）
ansible.builtin.template:
src: templates/nginx.conf.j2
dest: /etc/nginx/nginx.conf
owner: root
group: root
mode: ‘0644’
validate: ‘nginx -t -c %s’
notify: restart nginx
tags: [conf]

# templates/nginx.conf.j2（抜粋）
user {{ nginx_user | default(‘nginx’) }};
worker_processes {{ (ansible_facts.processor_vcpus | default(1)) | int }};
http {
server_tokens {{ nginx_server_tokens | default(‘off’) }};
{% for s in nginx_sites %}
server {
listen {{ s.port }};
server_name {{ s.server_name }};
root {{ s.root }};
}
{% endfor %}
}

3-2-3. ファイル配布と機密情報の扱い

静的ファイルはcopy、ディレクトリ作成はfile
大きな断片はassembleで連結し、レビュー性を上げる
機密はVaultに格納し、テンプレート内で参照

# vars/vault.yml（Vaultで暗号化）
db_password: supersecret

# tasks/main.yml
– name: アプリ設定
ansible.builtin.template:
src: app.ini.j2
dest: /etc/myapp/app.ini
vars_files:
– vars/vault.yml

3-3. 条件分岐・ループ・when/withの実践

3-3-1. OS差分の吸収（when）

ディストリビューションごとの分岐はfactsで一元化します。

だから、Playbookを一つに保ったまま複数OSへ配布できます。

– name: 依存パッケージを導入
ansible.builtin.package:
name: “{{ item }}”
state: present
loop: “{{ (ansible_facts.os_family == ‘Debian’) | ternary([‘debhelper’], [‘libselinux-python’]) }}”

3-3-2. ループの型（loop/withの使い分け）

今はloopが標準です。

複雑な入れ子はsubelementsやdict2itemsフィルタでシンプルにします。

# 単純なリスト
– name: パッケージ一括導入
ansible.builtin.package:
name: “{{ item }}”
state: present
loop: “{{ common_packages }}”

# 辞書のループ
– name: ユーザー作成
ansible.builtin.user:
name: “{{ item.key }}”
groups: “{{ item.value.groups }}”
state: present
loop: “{{ users | dict2items }}”

# 親子データ（サイトとエイリアス）
– name: サーバブロック生成
ansible.builtin.template:
src: vhost.conf.j2
dest: “/etc/nginx/conf.d/{{ item.0.name }}.conf”
loop: “{{ sites | subelements(‘aliases’, skip_missing=True) }}”

3-3-3. registerで結果に応じた分岐

実行結果に応じて次の処理を変えます。

したがって、外部コマンドやAPI連携でも安全に組み立てられます。

– name: バージョンを取得
ansible.builtin.command: myapp –version
register: ver
changed_when: false

– name: 旧バージョンならアップグレード
ansible.builtin.import_tasks: tasks/upgrade.yml
when: ver.stdout is version(‘3.2.0’, ‘<‘)

3-4. ハンドラー・通知・タグ運用で再実行を速くする

3-4-1. ハンドラーとnotify/listenの基本

設定が変わったときだけ後処理を実行します。

つまり、無駄な再起動を避けられます。

# tasks
– name: 設定変更時のみ再起動を通知
ansible.builtin.template:
src: app.service.j2
dest: /etc/systemd/system/app.service
notify: restart app

# handlers
– name: restart app
listen: restart app
ansible.builtin.service:
name: app
state: restarted

必要に応じて特定タイミングで即時反映するなら、次のようにします。

– name: ハンドラーをここで処理
ansible.builtin.meta: flush_handlers

3-4-2. タグ設計で部分実行を高速化

タグは再実行時間を縮める強力なスイッチです。

したがって、役割ごと・機能ごとに粒度を決めます。

基本タグ案：pkg（パッケージ）conf（設定）svc（サービス）deploy（配布）db（データベース）
実行例：--tags conf,svc、あるいは--skip-tags db
明示実行専用タスクにはtags: [never, migrate]＋--tags migrate

– name: DBマイグレーション（明示時のみ）
ansible.builtin.command: myapp migrate
tags: [never, migrate]

3-4-3. 差分最小化のテクニック

事前にstatで変更要否を判定してからcopy
バックアップが必要ならbackup: yes
読み取りだけのタスクはchanged_when: false
展開系はcreatesで再実行を抑制
大規模配布はserialやthrottleで段階展開

– name: 既存ファイルのハッシュ確認
ansible.builtin.stat:
path: /etc/myapp/app.ini
register: st

– name: 必要なときだけ差し替え
ansible.builtin.copy:
src: files/app.ini
dest: /etc/myapp/app.ini
when: not st.stat.exists or st.stat.checksum != lookup(‘file’, ‘files/app.ini’, errors=’ignore’) | checksum

3-5. 役割分割（Roles）とAnsible Galaxyの使い方

3-5-1. Roleで分ける基準とディレクトリ型

Roleは「関心ごとの分離」です。

つまり、アプリ、DB、Web、監視など機能単位で分けます。

roles/
└─ webserver/
├─ tasks/main.yml
├─ handlers/main.yml
├─ templates/
├─ files/
├─ defaults/main.yml # 変更されうる既定値
├─ vars/main.yml # 固定値（やむを得ず）
└─ meta/main.yml # 依存Role

3-5-2. 依存関係と変数の流儀

依存Roleはmeta/main.ymlで宣言（例：geerlingguy.repo-epel など）
調整可能な値はdefaults、固定したい値はvarsへ
取り込みはimport_role（静的）かinclude_role（動的）を使い分け

– name: Webロールを静的に取り込み
ansible.builtin.import_role:
name: webserver
vars:
nginx_server_tokens: “off”

3-5-3. Ansible GalaxyとCollectionsの導入

既製のRoleやCollectionを活用すると、工数を大きく削減できます。

その結果、社内は「自作するより組み合わせる」文化に寄せられます。

# requirements.yml
roles:
– src: geerlingguy.nginx
version: 0.21.3
collections:
– name: community.general
version: “>=8.0.0,<9.0.0”

# 取得・更新（例）
# ansible-galaxy role install -r requirements.yml
# ansible-galaxy collection install -r requirements.yml

Playbook側でCollectionを宣言すれば、接頭辞省略や可読性向上に役立ちます。

– name: Web層セットアップ
hosts: web
collections:
– community.general
roles:
– role: geerlingguy.nginx

実務で効く運用ノウハウ

Ansibleを現場投入する際は、セキュリティと再現性、そしてスピードの三点を同時に満たす設計が要です。

つまり、機密情報は厳格に守り、テストを自動化し、インベントリと接続方式を正しく選び、OSや機器特性を踏まえた運用に落とし込むことが重要です。

したがって、本章では「すぐ真似できる型」に絞って解説します。

4-1. 機密情報の守り方（Ansible Vaultの使いどころ）

4-1-1. 何をVaultで暗号化すべきか

パスワード、APIトークン、SSH秘密鍵、証明書の秘密鍵
データベース接続情報、クラウドのアクセスキー
本番固有の設定値（内部ホスト名、監視用コミュニティ文字列など）

一方、暗号化しない方がよいものは次の通りです。なぜなら、レビュー性と差分追跡を落とすからです。

一般設定（ポート番号、タイムアウトなど機微でない値）
大容量ファイル（バイナリ）や頻繁に変わるログ設定

4-1-2. Vaultの基本運用（チームで破綻しない型）

ファイル単位で暗号化：group_vars/prod/vault.yml のように環境別に分離
一行だけ暗号化：ansible-vault encrypt_string を使い、Playbookへ直接埋め込む
パスワード配布：ANSIBLE_VAULT_PASSWORD_FILE を使い、CIではシークレット変数から投入
レビュー性確保：機密以外は平文の defaults / group_vars に残す

4-1-3. 失敗しない読み込み順序

# site.yml
– hosts: app
vars_files:
– group_vars/common.yml
– group_vars/{{ env }}/vault.yml # 最後に読み込む
roles:
– app

最後にVaultを読み込むと、環境ごとの差分が意図通りに上書きされます。

だから、変数の衝突が減ります。

4-2. テスト（Molecule）とCI/CD連携（GitHub Actions/GitLab）

4-2-1. Moleculeの最小シナリオ

ドライバ：Docker/Podmanを選択（速い・使い捨て・再現性）
シナリオ：create → converge → verify → destroy
検証：pytest + testinfra で「ポートが開いているか」「サービスが起動しているか」をチェック

# 例：Role直下で
molecule init scenario -r webserver -d docker
molecule test

4-2-2. GitHub Actionsでの定番パイプライン

依存取得：ansible-galaxy install -r requirements.yml
静的検査：ansible-lint、yamllint、ansible-playbook --syntax-check
ユニット相当：molecule test（シナリオごとに並列）
デプロイ前検証：対象外部へは --check --diff でプルリク時に乾式実行

# .github/workflows/ci.yml（抜粋）
name: ansible-ci
on: [push, pull_request]
jobs:
test:
runs-on: ubuntu-latest
steps:
– uses: actions/checkout@v4
– uses: actions/setup-python@v5
with: { python-version: ‘3.11’ }
– run: pip install ansible-core ansible-lint molecule[docker] pytest testinfra
– run: ansible-galaxy install -r requirements.yml
– run: ansible-lint
– run: ansible-playbook -i inventories/ci/hosts site.yml –syntax-check
– run: molecule test –all

4-2-3. GitLab CIでのシンプル構成

# .gitlab-ci.yml（抜粋）
image: python:3.11
services: [docker:dind]
stages: [lint, test]
before_script:
– pip install ansible-core ansible-lint molecule[docker] pytest testinfra
– ansible-galaxy install -r requirements.yml
lint:
stage: lint
script:
– ansible-lint
test:
stage: test
script:
– molecule test –all

CI上のVaultパスワードはランナーのシークレットに保存し、ジョブ中にファイルへ書き出して使用します。

したがって、履歴に残さず安全です。

4-3. インベントリ設計（グループ化・動的インベントリ・クラウド連携）

4-3-1. グルーピングの基本指針

層で分ける：web、app、db
環境で分ける：dev、stg、prod
組み合わせは子グループで表現：[prod:children] web_prod app_prod
変数は「広い→狭い」の順に上書き：group_vars/all → group_vars/web → host_vars/web01

4-3-2. 静的と動的のハイブリッド

変動しにくいオンプレは静的ファイル
クラウドは動的インベントリプラグイン（例：aws_ec2、azure_rm、gcp_compute）
タグ駆動でグループ化し、ローリング更新のserial対象を自動抽出

# aws_ec2動的インベントリ（抜粋）
plugin: amazon.aws.aws_ec2
regions: [“ap-northeast-1”]
filters:
tag:Role: “web”
keyed_groups:
– key: tags.Env
prefix: “”
compose:
ansible_host: public_ip_address

4-3-3. 接続と性能のベース設定

# ansible.cfg（抜粋）
[defaults]
forks = 50
timeout = 30
gathering = smart
fact_caching = jsonfile
fact_caching_connection = .facts
host_key_checking = False

[ssh_connection]
pipelining = True
ssh_args = -o ControlMaster=auto -o ControlPersist=15m

pipeliningやコネクション再利用を有効化すると、並列数を抑えつつ高速化できます。

だから、大規模配布でもトラフィック過多になりにくいのです.

4-4. Windowsとネットワーク機器の自動化の勘所

4-4-1. Windowsの要点（WinRM・権限・モジュール）

接続はansible_connection=winrm、既定は5986/TLS。証明書運用かドメイン連携を前提に
権限昇格はLinuxのbecomeと異なるため、実行ユーザーを適切に設計
ソフト配布はansible.windows.win_package、設定はwin_regedit、再起動はwin_reboot
パッケージ管理はcommunity.windows.chocolateyの活用が便利
改行コードやパス区切り（\）の違いをテンプレートで吸収

[windows]
win01 ansible_host=203.0.113.10

[windows:vars]
ansible_connection=winrm
ansible_user=Administrator
ansible_password={{ vault_win_password }}
ansible_winrm_transport=credssp
ansible_winrm_server_cert_validation=validate

4-4-2. ネットワーク機器の要点（ベンダープラグイン・差分管理）

接続はnetwork_cliやhttpapi、OSはansible_network_os=ios|nxos|junosなどを明示
*-config系モジュールで意図状態を投入し、backup: yes と diff を活用
gather_facts: no を忘れずに。代わりに ansible_net_* facts を参照
段階展開：serialで少数ずつ適用し、失敗時にロールバック

– hosts: switches
connection: network_cli
gather_facts: no
tasks:
– name: intended configを適用
cisco.ios.ios_config:
src: templates/ios_intended.cfg.j2
backup: yes

4-5. ベストプラクティスとやりがちな落とし穴

4-5-1. ベストプラクティス要点

冪等を最優先：state 指定、creates、changed_when で補強
テンプレートは validate と notify を併用して安全に再起動
タグ設計：pkg、conf、svc、deploy などで部分実行を高速化
品質ゲート：ansible-lint、--syntax-check、Molecule の三点セット
性能：pipelining、fact caching、strategy: free、不要時は gather_facts: false
ログと追跡：-vvvでの一時デバッグと、実行履歴の保存（CIログ・Artifactory等）

4-5-2. よくある落とし穴と回避策（早見表）

落とし穴	何が起きるか	回避策
`shell`/`command`を多用	冪等性が失われる	まず対応モジュールを探す。やむを得ず使うときは`creates`や`unless`相当を設計
`latest`指定の乱用	意図せず更新が走る	バージョン固定。更新はメンテナンスタグで明示的に
Vaultに全て入れる	レビュー不能になる	機密だけをVault化。構造化された平文を保つ
変数の多重上書き	デバッグ困難	`defaults`→`group_vars`→`host_vars`の階層を厳守。`ansible-playbook -e`は最小限
動的インベントリ無設定	予期せぬ対象に配布	タグ基準で抽出し、`--limit`や`serial`で段階適用
Windows/Linuxの思考混同	実行失敗や権限エラー	各OS専用モジュールを選択し、接続方式・権限モデルを分けて設計
大量同時変更	サービス断や輻輳	`serial`、`throttle`、`max_fail_percentage`で安全弁を設置

4-5-3. 運用チェックリスト（配布前に見る）

変更はドライラン済みか（--check --diff）
重要変更にタグが付いているか（部分実行できるか）
ロールのdefaultsが現実的な初期値になっているか
rebootやserviceの通知条件が正しいか
CIでMoleculeが緑になっているか
Vaultパスワードの取り扱いが組織ポリシーに沿っているか

スケールさせる導入設計

Ansibleをチームや全社規模で運用するときに重要なのは、スケールさせるための「型」を最初から用意しておくことです。

つまり、小さく始めて共通テンプレートを固め、段階的に並列度やコントローラを増やし、パフォーマンスとセキュリティを両立させます。

したがって本章では、Ansibleを中長期で拡張するための設計指針を、テンプレート、チューニング、運用統制の観点で整理します。

5-1. 小規模〜中規模の標準構成例（テンプレート一式）

5-1-1. リポジトリの標準ディレクトリ（そのまま使える型）

ansible-repo/
├─ site.yml # 入口Playbook（役割の束ね）
├─ inventories/
│ ├─ dev/hosts # 環境ごとのインベントリ
│ ├─ stg/hosts
│ └─ prod/hosts
├─ group_vars/
│ ├─ all.yml # 全体既定
│ ├─ web.yml # 役割別
│ └─ prod.yml # 環境別（機微はVaultへ）
├─ host_vars/
│ └─ web01.yml
├─ roles/
│ ├─ webserver/ # 機能単位のRole
│ └─ app/
├─ files/ # 小さめの静的配布物
├─ templates/ # Jinja2テンプレート
├─ vars/
│ └─ vault.yml # ansible-vaultで暗号化
├─ collections/
│ └─ requirements.yml # 利用するCollections固定
├─ molecule/
│ └─ default/ # 最低限の検証シナリオ
└─ ansible.cfg # プロジェクトローカル設定

この「型」をチームで共有すると、レビューが揃い、Ansibleの学習コストも下がります。

つまり、スケールの原点は“同じ型で書く”ことです。

5-1-2. ansible.cfg の最小チューニング

[defaults]
inventory = ./inventories/dev/hosts
forks = 25
timeout = 30
gathering = smart
fact_caching = jsonfile
fact_caching_connection = .facts
retry_files_enabled = False
stdout_callback = yaml
callback_whitelist = profile_tasks,timer

[ssh_connection]
pipelining = True
ssh_args = -o ControlMaster=auto -o ControlPersist=15m -o ServerAliveInterval=30

pipeliningとコネクション再利用で往復を減らし、profile_tasksで遅いタスクを可視化します。

したがって、早い段階から性能のボトルネックを特定できます。

5-1-3. 実行設計の基本ルール

変更系タスクにタグ付け（pkg, conf, svc, deploy）
読み取りタスクは changed_when: false
長時間処理は async と poll で非同期実行
段階展開は serial: 20% のように割合指定
重要タスクは --check --diff で事前確認
このルールは小規模でも効きますが、中規模化したときの事故を大幅に減らします。

5-2. 大規模化のポイント（並列度、コントローラ分割、AWX/Automation Platform活用）

5-2-1. 並列度の考え方（forksだけに頼らない）

forks は接続数上限。むやみに増やすとネットワークとターゲットに負荷
serial でロールアウト幅を制御し、max_fail_percentage で停止条件を設定
throttle（タスク単位の同時数制限）で重い処理を抑制
strategy: free でホスト間の待ち合わせを減らす（順序依存が無いとき）

5-2-2. コントローラ分割（論理と物理のレイヤ）

論理分割：環境（dev/stg/prod）、ドメイン（Web/DB/ネットワーク）、地域（APAC/EMEA）
物理解：複数の制御ノードを用意し、ジョブ種別でキューを分離
SCMリポジトリは単一でも、実行は「プロジェクト別・キュー別」に分ける
つまり、運用負荷の平準化と影響範囲の限定が同時に達成できます。

5-2-3. AWX / Ansible Automation Platform の活用

ジョブテンプレートで「誰でも同じ実行」を保証（変数はSurveyで入力）
RBACでインベントリ・資格情報・テンプレートを分離し最小権限で運用
実行環境（Execution Environment）で依存パッケージをコンテナ化し再現性を担保
スケジューラで定時作業やコンプライアンスチェックを自動化
プライベートハブ（Collections/ロールの社内配布）で依存のバージョンと品質を統制
この仕組みにより、Ansibleの“人依存”を排し、監査性を高められます。

5-3. パフォーマンス最適化（forks・strategy・キャッシュ）

5-3-1. 早見表：ボトルネック別の対策

症状	主因	対策
接続確立が遅い	SSHハンドシェイク、DNS	`ControlPersist`、`pipelining`、名前解決キャッシュ、踏み台の近接配置
タスクが足踏み	ホスト間の待ち合わせ	`strategy: free`、タスク分割、`run_once`＋`delegate_to`
冪等でも毎回changed	モジュールの使い方	`creates`, `unless`相当や`changed_when`の明示、適切なモジュール選択
facts収集が重い	gather_factsデフォルト	`gather_facts: false`、`gather_subset: min`、factキャッシュ
I/Oが遅い	テンプレート大量配布	圧縮転送、差分配布、`async`で分散

5-3-2. Playbook側の具体テクニック

– hosts: web
strategy: free
serial: 25%
gather_facts: false
vars:
ansible_ssh_common_args: “-o ControlMaster=auto -o ControlPersist=15m”
pre_tasks:
– name: 必要なfactsだけを軽量収集
ansible.builtin.setup:
gather_subset:
– network
– virtual
tasks:
– name: 重いコンパイル処理は非同期
ansible.builtin.command: make build
async: 1800
poll: 0
throttle: 5