Ansible CollectionsとFQCNの基礎知識|ansible.builtinと外部コレクション導入の実践手順

宮崎智広 この記事の監修:宮崎智広(Linux実務・教育歴20年以上・受講者3,100名超)
HOMELinux技術 リナックスマスター.JP(Linuxマスター.JP)Ansible > Ansible CollectionsとFQCNの基礎知識|ansible.builtinと外部コレクション導入の実践手順
「PlaybookのモジュールをFQCNで書くよう指摘された。ansible.builtinとは何か、どう書けばいいのか分からない」
Ansible 2.10以降を使い始めると、こういった疑問を抱く方が多くいます。

この変化は一時的な仕様変更ではありません。Ansible CollectionsFQCN(Fully Qualified Collection Name)は、Ansible全体のモジュール体系を整理した根本的なアーキテクチャ改革です。ansible-lintでの警告への対応だけでなく、外部Collectionの導入や自動化コードの保守性にも直結する重要な概念です。

この記事では、CollectionsとFQCNの基本的な概念から、ansible.builtin名前空間の使い方、community.generalなどの外部Collection導入手順、そしてPlaybookへの実装パターンまでを解説します。単なるコマンドリファレンスではなく、ansible-lintの警告を解消しながらモダンな記法に移行するための実践的な設計視点を重点的に扱います。実行環境はRHEL 10 / Rocky Linux 9です。

この記事のポイント

・FQCNは「名前空間.コレクション名.モジュール名」の3パート形式でAnsible 2.10から標準化された
・ansible.builtinは追加インストール不要の組み込みコレクションでcopy/file/serviceなどが含まれる
・外部CollectionはCollection単位でインストールしrequirements.ymlで宣言管理できる
・ansible-lintのfqcn警告はモジュール名をFQCN形式に書き直すことで解消できる


「このままじゃマズい」と感じていませんか?
参考書を開く気力もない、同年代に取り残される不安——
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
図解60P/登録10秒/解除も3秒 / 詳細はこちら

CollectionsとFQCNが生まれた背景|Ansible 2.10のモジュール体系再編

Ansible 2.9以前は、数千のモジュールがすべて ansible/modules/ というフラットな単一名前空間に詰め込まれていました。copyuserec2_instanceが同じ場所に並ぶ構造で、モジュール数の増加に伴ってメンテナンスが困難になっていました。特定クラウドサービスのモジュールをアップデートするためにAnsible全体のリリースを待つ必要があり、開発サイクルの柔軟性が欠けていたのです。

2020年にリリースされたAnsible 2.10でこの構造が根本から見直されました。モジュールが機能・用途別の「Collection」という単位にまとめられ、Ansibleコア(ansible-core)と分離してリリースされるようになりました。

ansible-core:Playbook実行エンジン+ansible.builtinコレクションのみを含む最小パッケージ
ansible(パッケージ):ansible-coreに多数のコミュニティCollectionを同梱した配布パッケージ

この再編によって、各CollectionがAnsibleコアとは独立したリリースサイクルを持てるようになりました。AWS・GCP・Azure向けのCollectionが新しいクラウドサービスへの対応を素早く反映できるようになったのは大きなメリットです。

FQCNが必要になった理由
モジュールがCollection単位に分散した結果、「どのCollectionのモジュールを呼び出すのか」を明示的に指定する記法が必要になりました。これがFQCN(Fully Qualified Collection Name)です。copyと書くだけでは「ansible.builtinのcopyなのか、それとも別CollectionにあるcopyなのかJが曖昧になるため、ansible.builtin.copyのように完全修飾名で書くことが推奨されています。

FQCNの読み方と構造|ansible.builtin.copyを解剖する

FQCNは3つのパートを「.(ドット)」でつなげた形式です。

1. FQCNの3パート構造

# FQCNの基本形式 名前空間.コレクション名.モジュール名(またはプラグイン名) # 具体例その1: 組み込みモジュール ansible.builtin.copy ^^^^^^^ ^^^^^^^ ^^^^ 名前空間 コレクション名 モジュール名 # 具体例その2: コミュニティコレクション community.general.java_cert ^^^^^^^^^ ^^^^^^^ ^^^^^^^^^ 名前空間 コレクション名 モジュール名

各パートの意味は次のとおりです。

名前空間(Namespace):組織・プロジェクトを表す識別子。ansibleはRed Hat公式、communityはコミュニティ管理を意味する
コレクション名(Collection name):機能カテゴリを表す名前。builtinは組み込みモジュール群、generalは汎用モジュール群
モジュール名(Module name):実際に呼び出すモジュール。copyはファイルコピー、userはユーザー管理など

2. ansible.builtinの代表モジュール

ansible.builtinはansible-coreに同梱された組み込みCollectionです。追加インストールなしでいつでも使えます。現場でよく使うモジュールを以下に示します。

モジュール(FQCN) 主な用途
ansible.builtin.copy ファイルをリモートホストにコピーする
ansible.builtin.file ファイル・ディレクトリの属性・パーミッション変更
ansible.builtin.template Jinja2テンプレートを展開してコピーする
ansible.builtin.user Linuxユーザーアカウントの作成・変更・削除
ansible.builtin.service systemdサービスの起動・停止・有効化
ansible.builtin.package OSを問わず汎用パッケージ管理(dnf/apt両対応)
ansible.builtin.dnf RHEL/Rocky Linux向けのdnfパッケージ管理
ansible.builtin.apt Debian/Ubuntu向けのaptパッケージ管理
ansible.builtin.command リモートホストで任意のコマンドを実行する
ansible.builtin.shell シェル(/bin/sh)経由でコマンドを実行する
ansible.builtin.lineinfile ファイルの特定行を追加・変更・削除する
ansible.builtin.debug 変数の値やメッセージをコンソールに出力する
ansible.builtin.commandansible.builtin.shellの違いはよく混同されます。commandはシェルを経由しないため|&&などのシェル記法は使えませんが、予期しないシェルインジェクションのリスクがありません。パイプや変数展開が必要な場合のみshellを使い、それ以外はcommandを選ぶのが現場での定石です。

外部Collectionを導入する実践手順|community.generalとansible.posixの例

ansible.builtinにないモジュールを使いたい場合は、外部Collectionを追加でインストールします。ここでは最も利用頻度が高いcommunity.generalansible.posixを例に手順を示します。

1. ansible-galaxy collection installで個別インストールする

# community.generalをインストール(最新版) ansible-galaxy collection install community.general # バージョンを指定してインストール ansible-galaxy collection install community.general:9.5.0 # ansible.posixをインストール ansible-galaxy collection install ansible.posix # 実行結果の例(RHEL 10 環境) Starting galaxy collection install process Process install dependency map Starting collection install process Downloading https://galaxy.ansible.com/download/community-general-9.5.0.tar.gz Installing 'community.general:9.5.0' to '/root/.ansible/collections/ansible_collections/community/general' community.general:9.5.0 was installed successfully

インストール先はデフォルトで ~/.ansible/collections/ 配下になります。チーム開発ではプロジェクトのルートディレクトリ内にインストールすることも多いです。

2. requirements.ymlで複数のCollectionを宣言管理する

チーム開発では、必要なCollectionをすべてrequirements.ymlに宣言しておく方法が標準的です。これにより、チームメンバー全員が同じCollectionバージョンの環境を1コマンドで再現できます。

# requirements.yml(Collectionセクション) --- collections: - name: ansible.posix version: ">=1.5.0" - name: community.general version: "9.5.0" - name: community.mysql version: ">=3.8.0"

requirements.ymlにはcollectionsセクションとrolesセクションを共存させることができます。ただしCollectionとRoleではインストールコマンドが異なる点に注意してください。

# Collectionのみインストール(--type collection は省略可) ansible-galaxy collection install -r requirements.yml # Roleのみインストール ansible-galaxy role install -r requirements.yml # CollectionとRoleを両方インストールする場合は2コマンドを順に実行する ansible-galaxy collection install -r requirements.yml ansible-galaxy role install -r requirements.yml

Ansible GalaxyでRoleを管理している場合(requirements.ymlでroleを宣言している場合)、そのrequirements.ymlにcollectionsセクションを追記することでCollectionも一元管理できます。Roleとの棲み分けとして、RoleはPlaybookの「タスクの塊」を再利用する単位CollectionはモジュールやプラグインをFQCNで呼び出すための「モジュール配布パッケージ」と覚えると整理しやすいです。

3. ansible.cfgでCollection検索パスを設定する

プロジェクトにローカルインストールしたCollectionを認識させるには、ansible.cfgcollections_pathを設定します。

# ansible.cfg の設定例(プロジェクトルートに配置) [defaults] collections_path = ./collections:/usr/share/ansible/collections # 設定後、パスが正しく読まれているか確認 ansible-config dump | grep COLLECTIONS_PATHS # 出力例(RHEL 10 / rocky9-admin ユーザーの場合) COLLECTIONS_PATHS(/home/rocky9-admin/project/ansible.cfg) = ['/home/rocky9-admin/project/collections', '/usr/share/ansible/collections']

インストール済みCollectionの一覧は次のコマンドで確認できます。

# インストール済みCollectionの一覧を確認 ansible-galaxy collection list # 出力例(RHEL 10 環境) # /root/.ansible/collections/ansible_collections Collection Version ----------------- ------- ansible.posix 1.5.4 community.general 9.5.0 # /usr/lib/python3.12/site-packages/ansible_collections Collection Version ----------------- ------- amazon.aws 8.2.1 ansible.netcommon 6.1.2

CollectionsやFQCNを含むAnsible実務設計を体系的に身につけたい方へ、20年以上の運用経験を持つ現役エンジニアが基礎から教えます。
Ansible実践ハンズオンの詳細を見る >>

PlaybookでFQCNを正しく書く|直接記述とcollections:ディレクティブの使い分け

Playbook内でFQCNを使う方法は2つあります。

1. FQCNをモジュール名に直接書く(推奨)

最もシンプルで推奨される方法は、タスクのモジュール名としてFQCNをそのまま書くことです。

# FQCN直接記述(推奨) --- - name: Webサーバーセットアップ hosts: webservers tasks: - name: Nginxをインストールする ansible.builtin.dnf: name: nginx state: present - name: Nginx設定ファイルをコピーする ansible.builtin.copy: src: nginx.conf dest: /etc/nginx/nginx.conf owner: root group: root mode: '0644' - name: Nginxサービスを起動して自動起動を有効にする ansible.builtin.service: name: nginx state: started enabled: yes - name: sudoersにdeployユーザーを追加する(community.generalのモジュール) community.general.sudoers: name: deploy-user user: deploy commands: ALL nopassword: yes

2. collections:ディレクティブで短縮記法を使う

同じCollectionのモジュールを多数使う場合、collections:ディレクティブでデフォルトの検索順を指定することで、モジュール名を短縮して書けます。ただしansible-lintでFQCN警告が出る原因にもなるため、採用する場合は注意が必要です。

# collections:ディレクティブによる短縮記法(参考) --- - name: コミュニティモジュールをまとめて使うPlay hosts: dbservers collections: - community.general - community.mysql tasks: - name: MySQLデータベースを作成する(FQCN省略形) mysql_db: # community.general.mysql_db を指す name: appdb state: present

どちらを選ぶべきか
ansible-lintを使う現場ではFQCN直接記述を選んでくださいcollections:ディレクティブを使った短縮記法は、どのCollectionのモジュールを実際に呼んでいるか一見して分かりにくくなります。また、同名モジュールが複数のCollectionに存在する場合に、意図しないモジュールが呼ばれる曖昧さが生じます。FQCNを直接書く習慣をチームに定着させることが、Playbookの保守性を長期的に高める近道です。

トラブルシュート|ansible-lintのFQCN警告とCollection not foundエラーへの対処法

ansible-lintはデフォルト設定でFQCN未使用を警告します。既存のPlaybookをlintにかけると大量の警告が出ることがあります。

1. 「fqcn[action-core]」警告への対応

# ansible-lint実行時の警告例 ansible-lint playbook.yml # 出力例(FQCN未使用の警告) WARNING Listing 3 violation(s) that are fatal playbook.yml:8: fqcn[action-core]: Use FQCN for builtin module actions: copy playbook.yml:15: fqcn[action-core]: Use FQCN for builtin module actions: service playbook.yml:22: fqcn[action-core]: Use FQCN for builtin module actions: dnf

対処は単純です。警告の出たモジュール名を、対応するFQCNに書き換えます。

# 変更前(短縮名) - name: 設定ファイルをコピーする copy: src: app.conf dest: /etc/app/app.conf # 変更後(FQCN) - name: 設定ファイルをコピーする ansible.builtin.copy: src: app.conf dest: /etc/app/app.conf

大量のPlaybookがある場合、sedなどで一括置換する誘惑に駆られますが、タスクのnameフィールドにモジュール名が含まれる場合に誤置換するリスクがあります。ansible-lintの--fixオプション(バージョン6.8以降)を使うか、慎重に一件ずつ確認するのが確実です。

2. Collection not foundエラーの診断

# よくあるエラー ERROR! couldn't resolve module/action 'community.general.sudoers'. This often indicates a misspelling, missing collection, or incorrect module path. # 診断手順 # 1. Collection名にタイポがないか確認 ansible-galaxy collection list | grep community.general # 2. インストールされていない場合はインストール ansible-galaxy collection install community.general # 3. ansible.cfgのcollections_pathが正しいか確認 ansible-config dump | grep COLLECTIONS_PATHS # 4. モジュール名の正式名称をドキュメントで確認 ansible-doc -t module community.general.sudoers

ansible-doc -t module コレクション名.モジュール名を実行すると、そのモジュールのドキュメントとFQCNが確認できます。モジュール名が正しいのにエラーが出る場合は、インストール先のパスがansible.cfgのcollections_pathに含まれていないことが多いです。

3. プロキシ環境でインストールが失敗する

企業のプロキシ環境下ではansible-galaxy collection installがSSL証明書の検証エラーで失敗することがあります。

# プロキシを環境変数で指定してインストール export HTTPS_PROXY=http://proxy.example.com:8080 ansible-galaxy collection install community.general # または ansible.cfg にGalaxyサーバーの設定を追記 # [galaxy] # server_list = release_galaxy # # [galaxy_server.release_galaxy] # url=https://galaxy.ansible.com/ # # proxy=http://proxy.example.com:8080

本記事のまとめ

やりたいこと コマンド/設定
インストール済みCollectionを確認する ansible-galaxy collection list
外部Collectionをインストールする ansible-galaxy collection install collection名
requirements.ymlからCollectionを一括インストールする ansible-galaxy collection install -r requirements.yml
モジュールのFQCNとドキュメントを確認する ansible-doc -t module ansible.builtin.copy
ansible.cfgのCollection検索パスを確認する ansible-config dump | grep COLLECTIONS_PATHS
Playbookのfqcn警告を一括修正する ansible-lint --fix playbook.yml
Ansible 2.10以降では、モジュール名をansible.builtin.copyのようなFQCN形式で書くことがベストプラクティスになっています。最初は冗長に感じるかもしれませんが、どのCollectionのモジュールを呼んでいるのかが一目瞭然になり、複数のCollectionが混在する大規模プロジェクトほどその恩恵を実感できます。

外部Collectionはrequirements.ymlで宣言して管理することで、チームメンバー全員がansible-galaxy collection install -r requirements.ymlの1コマンドで同じ環境を再現できます。CollectionとFQCNの関係を正しく理解することが、モダンなAnsible設計の第一歩です。
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、20年以上の運用経験を持つ現役エンジニアが基礎から教えます。
Ansible実践ハンズオンの詳細を見る >>

無料メルマガで学習を続ける

Linuxの実践スキルをメールで毎週お届け。
登録は1分、解除もいつでも可。

登録無料・いつでも解除できます

暗記不要・1時間後にはサーバーが動く

3,100名以上が実践した「型」を無料で公開中

プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。

登録10秒/合わなければ解除3秒 / 詳細はこちら

Linux無料マニュアル(図解60P) 名前とメールで30秒登録
宮崎 智広

この記事を書いた人

宮崎 智広(みやざき ともひろ)

株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。

趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。