Ansibleを使い始めてしばらくすると、ほぼ全員がこの問いにぶつかります。
roleは「ファイルを分割するための仕組み」ではありません。チームで同じ設定を繰り返し安全に使えるよう、自動化コードを「部品」として独立させる設計の考え方です。境界の引き方を誤ると、role化してもメンテナンスコストは下がらず、むしろ複雑さが増すことになります。
この記事では、ansible roleとは何かを概念から解説し、「どこで境界を引くか」という設計思考を具体例つきで説明します。roleのディレクトリ構造・実装手順は別記事に委ね、ここでは「なぜroleを使うのか・どう分けるか」という考え方の型に絞ります。
この記事のポイント
・ansible roleとはplaybookの処理を「名前のついた部品」として独立させるAnsibleの仕組み
・roleの境界は「1ソフトウェアスタック」「変更理由が同じ」「オーナーが同じ」の3基準で引く
・変数がroleの「インターフェース」。defaults/main.ymlを差し替え口として使うのが設計の要
・チームで共有するには「role内完結」「命名規則統一」「依存の明示」の3原則を守る
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
ansible roleとは——「名前のついた自動化の部品」
Ansibleのroleとは、関連するtask・変数・ファイル・ハンドラーをひとかたまりに束ねた、名前のついた自動化の単位です。「Nginxをインストールして設定ファイルを配置してサービスを起動する」という一連の処理を、
nginxという名前のroleにまとめる。playbook側はこう書けば済みます。# site.yml（roleを呼び出す側） - hosts: webservers roles: - nginx - postfix
PLAY [webservers] ************************************************************* TASK [Gathering Facts] ******************************************************** ok: [web01.example.com] ok: [web02.example.com] TASK [nginx : Install nginx] ************************************************** changed: [web01.example.com] changed: [web02.example.com] TASK [nginx : Deploy nginx.conf] ********************************************** changed: [web01.example.com] changed: [web02.example.com] TASK [postfix : Install postfix] ********************************************** changed: [web01.example.com] changed: [web02.example.com] PLAY RECAP ******************************************************************** web01.example.com : ok=4 changed=3 unreachable=0 failed=0 web02.example.com : ok=4 changed=3 unreachable=0 failed=0
nginx :やpostfix :というrole名がつくのがポイントです。実行ログを見ただけで「どのroleのどのtaskか」がすぐわかります。プログラミングで言えば「ライブラリのimport」に相当します。呼び出す側は「何を渡して何が返るか（= 変数とサーバーの最終状態）」さえ知っていれば、内部実装を知らなくても安全に使えます。これがroleの本質です。
roleが必要になる背景——playbookが抱える3つの問題
Ansibleを使い始めると、最初はplaybookが1ファイルに収まります。しかし管理対象サーバーが増え、設定項目が増えると、playbookは数百行から数千行の巨大ファイルになります。このとき起きる問題が3つあります。
・再利用できない：「同じNginx設定を新しいプロジェクトでも使いたい」と思っても、コードがplaybookに埋め込まれているのでコピー&ペーストしかない
・部分テストができない：一部だけ検証しようとしても、playbook全体を実行しないと確認できない
・責任境界があいまい：「このtaskは誰が管理するの？」という境界が不明で、変更時に影響範囲がわからない
roleはこの3つをまとめて解決します。設定の塊に名前をつけて独立させることで、再利用・テスト・責任境界のすべてが明確になります。
roleの「境界」をどこで引くか——3つの基準
roleを導入するときに最も迷うのが「どの単位でroleにするか」という問いです。粒度が細かすぎるとroleが乱立し、粗すぎると再利用できない。適切な境界を引く判断基準を3つ紹介します。1. 「1つのソフトウェアスタック」を1つのroleにする
最もシンプルで失敗が少ない基準が、「インストール→設定→起動」を1セットとする「1ソフトウェア＝1role」の原則です。・
nginx role：Nginxのインストール・設定・起動・ファイアウォール設定・
postfix role：Postfixのインストール・main.cf設定・サービス起動（Postfix の基本設定の解説）・
mysql role：MariaDB/MySQLのインストール・ユーザー作成・my.cnf設定このroleは「そのソフトウェアが動いている状態を作る」という明確な責任を持ちます。境界が直感的でチームメンバーも理解しやすく、新しいメンバーがroleの目的を理解するコストが最小になります。
2. 「変更の理由が同じ」ものをまとめる
より厳密な基準が、「変更の理由が同じtaskをひとつのroleに入れる」という考え方です。ソフトウェア設計の「単一責任原則」をAnsibleに適用したものです。例えばApacheとPHPを一緒にインストールする場合、「Apacheのバージョンアップ」と「PHPのバージョンアップ」は変更の理由が違います。この2つは
apache roleとphp roleに分けるべきです。変更理由が違うものを同じroleに入れると、一方の変更が他方に影響するリスクが生まれます（Apache タイムアウト設定の詳細）。3. 「誰がオーナーか」でroleを分ける
チーム運用では「このroleを誰が管理するか」という責任の単位でroleを分ける視点も重要です。・インフラチームが管理する：
common（OS基本設定）、security-baseline（セキュリティ強化）・アプリチームが管理する：
webapp（アプリデプロイ）、webapp-config（設定ファイル配置）オーナーが違うものをひとつのroleに混ぜると、変更のたびに両チームの調整が必要になります。境界をチームの担当境界と一致させると、レビューコストと摩擦が最小化されます。
roleのインターフェースを変数で定義する
roleの境界を引いたら、次に考えるのが「roleに何を渡すか」——変数によるインターフェース設計です。roleが持つ変数ファイルは2種類あります。
・
defaults/main.yml：呼び出し側が上書きできるデフォルト値（roleの「公開インターフェース」）・
vars/main.yml：roleの内部実装に使う固定値（外から変えてほしくない値）postfix roleのdefaults/main.ymlにこう書いておくと、
# roles/postfix/defaults/main.yml postfix_myhostname: "mail.example.com" postfix_mynetworks: "127.0.0.0/8" postfix_relay_host: ""
変数の命名はrole名をプレフィックスとするのが鉄則です（
postfix_、nginx_など）。複数のroleを同じplaybookで使うとき、プレフィックスなしの変数名は他のroleと衝突するリスクがあります。チームでroleを再利用するときの3原則
roleを「チームの共有資産」として機能させるには、以下の3原則を守ることが重要です。私がセミナーで3,100名以上を指導してきた中で、この3原則を守っていないroleが保守問題の原因になるケースを数多く見てきました。原則1：role内で完結させる
roleが外部のplaybookで定義された変数や他のroleの副作用に依存すると、再利用できなくなります。「このroleを使うにはあのroleを先に実行しないといけない」という暗黙の前提は極力避けてください。外部のroleが必要な場合は
meta/main.ymlのdependenciesで明示します。暗黙の依存を明示的な依存に変えることで、利用者がroleの前提条件を把握できます。原則2：defaults/main.ymlをオーバーライドの入り口にする
roleの利用者が環境ごとに設定を変えたいとき、roleのソースコードを直接編集させないことが重要です。defaults/main.ymlに全ての可変値を出しておき、利用者はgroup_vars/やhost_vars/で上書きする——この設計にすることでrole本体を安全に共有できます。原則3：role名は「何をするか」を端的に表す
role名は他のエンジニアがすぐ理解できる名前にします。・NG：
setup、config、common2（何をするか不明）・OK：
nginx-install、mysql-replication、os-hardening（目的が明確）role名は「ソフトウェア名」または「動詞＋名詞」の形式が読みやすく、Ansible Galaxyの命名規則とも一致します。
よくある失敗パターンと見直し方
roleを作り始めると陥りやすい失敗が3パターンあります。事前に知っておくと回避しやすくなります。失敗1：roleが大きくなりすぎる（commonに何でも入れる）
「共通処理を1つのroleにまとめる」のは効率的に見えますが、変更理由の異なるtaskが混在し、メンテナンスが困難になります。「この変更はこのroleに影響するか？」と問いかけて、不安なら分割を検討してください。
失敗2：roleが環境に依存している
roleの中に「本番サーバーのIPアドレス」や「ステージング専用の処理」が直書きされているケースです。環境依存の情報はすべて変数に切り出し、
group_vars/やhost_vars/から渡す設計にします。失敗3：roleの境界がplaybookの境界と一致していない
「Webサーバー構築playbook」と「DBサーバー構築playbook」に分けたのに、roleがそれをまたいでいるケースです。roleは特定のplaybookに縛られない汎用的な部品として設計するのが原則です。
まとめ
ansible roleとは、自動化コードを「名前のついた部品」として独立させるAnsibleの中核的な仕組みです。| 考え方 | ポイント |
|---|---|
| roleとは何か | task・変数・ファイル・ハンドラーを束ねた名前のついた自動化単位 |
| 境界の基準① | 1ソフトウェアスタック＝1role（インストール・設定・起動） |
| 境界の基準② | 変更の理由が同じものをまとめる（単一責任原則） |
| 境界の基準③ | オーナー（管理担当者）が同じものをまとめる |
| インターフェース | defaults/main.ymlを上書き可能な変数の置き場にする |
| チーム共有3原則 | role内完結・オーバーライド設計・命名規則統一 |
Ansibleのrole設計を体系的に学びたい方は、Ansibleを使ったLinuxサーバー自動構築の実践講座も参考にしてください。
＞＞ Ansibleサーバー自動構築 実践講座はこちら
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
姓・名・メールの3つだけ／30秒／解除は3秒 ／ 詳細はこちら
この記事を書いた人
宮崎 智広（みやざき ともひろ）
株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。
趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。
- 前のページへ：AnsibleのJinja2フィルター設計入門｜変数変換・デフォルト値・リスト操作でPlaybookの柔軟性を高めるパターン集
- この記事の属するカテゴリ：Ansibleへ戻る
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。
登録無料・いつでも解除できます