何が起きたのか
ansible-playbook を実行すると、タスクが動く代わりにこんなエラーが出ます：
ERROR! no action detected in task. This often indicates a misspelled module name, or incorrect module path.
The error appears to be in '/home/user/playbooks/deploy.yml': line 14, column 5
Ansible がタスクを読んだとき、何をすべきかが判断できなかった — モジュール名が既知のものと一致しないのです。ほとんどの場合、タイポ・キー名の間違い・インデントのずれが原因で、値がキーに見えてしまっています。
エラーの再現
以下は最小限のプレイブックでエラーを再現する例です：
- name: Install nginx
hosts: webservers
tasks:
- name: Install nginx package
apt_pakage: # typo: should be apt or ansible.builtin.apt
name: nginx
state: present
Ansible が apt_pakage を解析し、一致するモジュールが見つからず処理を停止します。タスクブロック全体がエラーとしてフラグされ、何も実行されません。
エラーのデバッグ
ステップ 1 — エラーに含まれる行番号を確認する
Ansible はほぼ必ず正確なファイルと行番号を教えてくれます：
The error appears to be in '/home/user/playbooks/deploy.yml': line 14, column 5
その行に直接飛んでください。ファイル全体をスキャンする必要はありません。
ステップ 2 — モジュール名のタイポを確認する
よくある間違い：
apt_pakageのところaptが正しいsystemd_serviceのところsystemdが正しいcopy_fileのところcopyが正しいgit_cloneのところgitが正しいcomandのところcommandが正しい
正確な名前がわからない場合は検索してみましょう：
ansible-doc -l | grep <keyword>
# Example:
ansible-doc -l | grep apt
ansible.builtin.apt のような FQCN 形式も使えます。どのコレクションを対象にしているか明確になり、曖昧さを排除できます。
ステップ 3 — モジュール名を隠してしまうインデントのズレを確認する
これに引っかかる人は多いです。モジュールの引数が誤ってタスクレベルまでインデントが戻ってしまうと、Ansible はそれを 2 つ目のモジュール名として読み取ります：
# Broken — 'state' looks like a module to Ansible
- name: Install nginx
apt:
name: nginx
state: present # ← wrong indent, now at task level
Ansible は apt と state を 2 つの別々のタスクレベルキーとして認識します。どちらがアクションなのか判断できず、エラーが発生します。
インデントを正しく戻せば解決します：
- name: Install nginx
apt:
name: nginx
state: present # ← correctly indented under apt
ステップ 4 — YAML 構造を検証する
深追いする前に、基本的な YAML の問題を除外しましょう。プレイブックを ToolCraft の YAML ↔ JSON Converter に貼り付けてみてください — ブラウザ上で YAML を JSON に変換でき、ファイルのアップロードは不要です。変換に失敗したり構造が崩れていたりすれば、インデントや構文の問題を直接示しています。見た目は正しそうなのにエラーが続くときに私もよく使います。
Ansible 標準のリンターも有効です：
ansible-playbook --syntax-check deploy.yml
どのホストにも接触せずにモジュール名のエラーを検出できます。
修正方法
たいてい 1 単語を変えるだけです。修正前後の例：
# Before (broken)
- name: Restart nginx
systemd_service:
name: nginx
state: restarted
# After (fixed)
- name: Restart nginx
systemd:
name: nginx
state: restarted
完全に明示したい場合は FQCN で記述することもできます：
- name: Restart nginx
ansible.builtin.systemd:
name: nginx
state: restarted
コレクションのモジュールパスの問題を修正する
コミュニティやサードパーティのコレクションを使っている場合、インストール済みであることと FQCN が正しいことを確認してください：
# Install the collection
ansible-galaxy collection install community.general
# Use the correct FQCN in your task
- name: Install pip package
community.general.pip:
name: requests
state: present
コントロールノードで利用可能なコレクションを確認するには：
ansible-galaxy collection list
確認方法
まず構文チェックを実行します：
ansible-playbook --syntax-check deploy.yml
# Expected output:
playbook: deploy.yml
クリーンな出力が返れば、Ansible がモジュールを認識しています。次に実際のインベントリに対してドライランを実行しましょう：
ansible-playbook -i inventory.ini deploy.yml --check
--check が no action detected エラーなしで完了すれば、問題は解消されています。
得られた教訓
難解に見えますが、このエラーは常に同じことを意味しています：Ansible がタスクブロック内にどのモジュールにもマップできないキーを見つけたということです。遭遇頻度の高い順に 3 つの原因があります：
- モジュール名のタイポ — 圧倒的に最も多い原因。
ansible-doc -lでスペルをクロスチェックしてください。 - インデントのズレ — モジュールの引数がタスクレベルにずり落ちてしまうケース。YAML 拡張機能を入れた VS Code はこれを視覚的にハイライトしてくれます。30 秒でインストールできるので入れておく価値があります。
- コレクションパスの誤り — コレクションをインストールせずにコミュニティモジュールを使おうとしているか、FQCN が間違っているケース。
CI パイプラインのプリフライトステップとして --syntax-check を追加しておけば、この種のエラーがライブホストに到達する前にすべて検出できます。