📚 連載：Ansibleが理解できない理由はLinuxにあった【OS編】第2回：【Ansibleでハマる】command not foundの原因はPATHだった（環境変数の正体）
Linuxの仕組みからAnsibleを理解するシリーズです。
0️⃣ Ansibleの仕組み
1️⃣ Linuxの構造（Kernel / Shell / Filesystem）
2️⃣ command not foundの原因：PATH
3️⃣ SSH接続できない理由：鍵認証とポート
4️⃣ Permission deniedの原因：ユーザーと権限
5️⃣ サービスが起動しない理由：systemd
6️⃣ cronが動かない理由：PATH問題
7️⃣ ディスク満杯になる理由
8️⃣ サーバーが遅くなる理由
🗺️ 初めての方・シリーズの全体像を知りたい方はこちら
本記事は、OSの仕組みからAnsible設計までを繋ぐ連載シリーズの一部です。
「どこから読み始めればいいか」あるいは、「OS/Shell/Ansible編の関係性」 について把握されたい場合は、以下の統合ガイドで整理しています。
📑 【OS編】全体のまとめはこちら
→ Ansibleが理解できない理由はLinuxにあった【OS編】まとめ
📑 連載の移動
前の記事：【OS編】第1回 ｜ 次の記事：【OS編】第3回
シリーズ全体構造（学習 × 問題解決）
本シリーズは
「理解（各記事）」と「問題解決（逆引き辞典）」を組み合わせて
スキルを身につける構成になっています。
この図は、どこから学び、どこに進めばよいかを示した“ロードマップ”です。
📍 現在の位置
現在はこの図の「OS編 第2回」になります
📍 はじめに：この記事のスタンス
SSHでのログイン操作を終え、いよいよAnsibleでコマンドを実行する段階で直面する以下の事象を整理します。
-
「FAILED! => command not found と出力され、タスクが失敗する」
-
「手動でコマンドを叩けば動くが、Ansible（またはcron等）経由だと失敗する」
-
「対象ホストにコマンドは存在するが、Ansibleがそれを発見できない技術的根拠を説明できない」
⚠️ 注意事項
本稿は、Linuxの環境変数やシェルスクリプトの全機能を網羅することを目的とした資料ではありません。
主眼に置くのは、Ansibleにおいて command / shell モジュール等が失敗した際、
「OS側のどの環境変数（PATH）に起因し、どの事実を確認して解決すべきか」を特定する手順の確立です。
「コマンドはインストール済みであるにもかかわらず、発見不能と判定される」
この実務上の課題を解消するため、Linuxの「$PATH」によるコマンド探索の仕組みと、「実行主体」によって変化するAnsibleの実行環境（コンテキスト） の相関関係を、実機検証を交えて解説します。
📋 目次
- 前回の振り返り（第1回）
- 逆引き辞典との連動
- PATHとは何か：コマンド実行時の「検索対象リスト」
- なぜAnsibleでcommand not foundが起きるのか：OSによる3つの要因
- env / echo $PATHの読み方：プロセスが持つ「事実」を確認する
- 実機検証：Ansible実行環境における環境変数の差異
- 実務で遭遇する「コマンドが発見・実行できない」2つの要因
- まとめ：事象の特定を迅速化する「調査のプロセス」
- 次回予告
- 連載一覧：Ansibleが理解できない理由はLinuxにあった
1. 前回の振り返り（第1回）
前回の記事では、Linuxを構成する主要な要素である 「Kernel / Shell / Filesystem / Process」 の役割を整理しました。OSが資源を管理し、ファイルやプロセスを通じて操作を受け付ける全体像を把握しました。
今回は、その構造の上で Ansibleがコマンドを実行する際 に直面する具体的な問題を深掘りします。
対象ホストにパッケージは導入されているはずなのに、Ansibleが command not found と判定してしまう事象を、シェル（Shell）が持つ $PATH（検索対象リスト） の仕組みと、実行時の プロセス が保持する情報の観点から紐解いていきます。
2. 逆引き辞典との連動
具体的なエラー名から原因を特定したい場合は、以下の逆引き辞典を活用してください。
Ansibleが理解できない理由はLinuxにあった ：【保存版】Ansibleトラブル逆引き辞典｜エラー別の原因と解決フローまとめ
- まず「逆引き辞典」で該当ステップを特定する
- 次に「本編（各連載記事）」で仕組みを理解する
3. PATHとは何か：コマンド実行時の「検索対象リスト」
Linuxにおいて「コマンドを実行する」という操作は、OSがファイルシステム上の特定のディレクトリ群から、対象の実行ファイルを捜索するプロセスを指します。この捜索対象を定義した「検索対象リスト」が環境変数 PATH です。
3-1. コマンドの実体と所在
Linuxのコマンドは、独立した「ファイル」として特定のディレクトリに格納されています。
| コマンド名 | ファイルの実体（フルパス） |
|---|---|
| ls | /bin/ls |
| systemctl | /usr/bin/systemctl |
| nginx | /usr/sbin/nginx |
3-2. 走査ロジック：リストに基づく順次検索
ユーザーやAnsibleが nginx と入力した際、シェル（bash等）は $PATH に格納されたディレクトリリストを左から順番に確認し、最初に一致したファイルを「正解」として実行します。
現在の設定値は、以下のコマンドで確認可能です。
echo $PATH
# 表示例：/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin
この「検索対象リスト」に実行ファイルの所在が含まれていない場合、OS側でパッケージの導入が完了していても、「対象を発見できなかった」 という事実に基づいて command not found を返します。
3-3. Ansibleにおける「リスト」の参照
Ansibleの多くのモジュール（command, shell等）は、リモートホスト上でシェルを介して動作するため、この $PATH リストの状態が実行結果に直接影響します。
ここで注意が必要なのは、「$PATH の中身は常に一定ではない」 という点です。
-
手動（SSHログイン時）: 設定ファイルが読み込まれ、フルセットのリストが構成される。
-
Ansible実行時: 接続方式や権限設定により、リストの一部が欠落したり、最小構成に制限されたりする。
このように、実行主体や接続方式によって「検索対象リスト」の中身が動的に変化することが、「手動では動くが、Ansibleでは失敗する」 というトラブルの根本的な要因となります。
4. なぜAnsibleでcommand not foundが起きるのか：OSによる3つの要因
Ansibleからコマンドを実行した際に発生する command not found は、単なるスペルミスを除けば、そのほとんどがOS側による「検索対象リスト（$PATH）」の制約に起因します。これらは技術的に以下の3つの要因に集約されます。
4-1. 検索パスの未定義（OS側の基本仕様）
最も基本的な要因は、実行ファイルの格納先が環境変数 $PATH にそもそも登録されていないケースです。
OS標準のパッケージ管理（yumやdnf）以外で導入したソフトウェアや、独自に作成したスクリプトは /usr/local/bin や /opt 配下に置かれることが多いですが、これらが検索リストに含まれていなければ、OSはコマンドを特定できません。
-
主な事象: 対象ホスト上でフルパス（例：
/opt/myapp/bin/start.sh）を指定すれば動くが、コマンド名のみでは失敗する。
4-2. 環境設定読み込みのスキップ（非対話モードの影響）
Ansibleがリモートホストでコマンドを実行する際、基本的には「非対話モード（Non-interactive shell）」で動作します。
Linuxのシェル（bash等）は、実行形態によって読み込む設定ファイル（プロファイル）が異なります。手動ログイン時には読み込まれる .bashrc や /etc/profile 等に記述されたパス設定が、Ansible実行時にはスキップされることがあります。
-
主な事象: 手動でSSHログインして実行すると成功するが、Ansible経由だと
$PATHが初期状態にリセットされ、特定のコマンドが発見不能になる。
4-3. 特権昇格によるリセット（secure_path の制約）
Ansibleで become: yes（sudo等）を使用して特権昇格を行う場合、セキュリティ上の理由から $PATH がOSによって厳格に制限されます。
多くのLinuxディストリビューションでは、/etc/sudoers 内の secure_path という設定により、昇格後のプロセスが参照できるディレクトリが固定されています。ユーザー環境で独自に通していたパス設定は、昇格した瞬間にこの固定リストによって上書き（リセット）されます。
-
主な事象: 一般ユーザーでのAnsible実行は成功するが、
become: yesを付与した途端にcommand not foundとなる。
これら3つの要因は、すべて 「その瞬間のプロセスが、どの検索リスト（$PATH）を持っているか」 という一点に帰結します。
次章では、この「プロセスが持っている事実」をどのように確認すべきか、その具体的な手法を整理します。
5. env / echo $PATHの読み方：プロセスが持つ「事実」を確認する
トラブルシューティングにおいて重要なのは、「パスが通っているはず」という推測ではなく、OSがその瞬間に保持している「現在の値」を確認することです。コマンド実行が失敗した際、OS側でプロセスがどのような情報を保持しているか、客観的な事実を特定します。
5-1. echo $PATH で検索リストの現状を知る
コマンドが発見できないとき、まず確認すべきは「そのプロセスから見える検索リスト（PATH）」です。
/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin
このリストに目的のコマンドの所在が含まれていなければ、OSは探索を打ち切ります。「パッケージを入れたのに動かない」という事象の多くは、このリストの中に該当のパスが存在しないという事実に集約されます。
5-2. env コマンドで全環境変数を俯瞰する
env コマンドは、そのプロセスに割り当てられたすべての環境変数を表示します。
-
LANG: 文字コードや言語設定。
-
PWD: プロセスが動作している現在のディレクトリ。
-
HOME / USER: 実行ユーザーの識別情報。
これらは、OSが「どのような設定で」プログラムを動かそうとしているかを示す、プロセスのプロファイルとしての役割を持ちます。これらを俯瞰することで、意図したユーザー環境で動いているかを客観的に判断できます。
5-3. 「プロセスが持つ事実」の確定
重要なのは、「今、命令を実行しているそのプロセスの環境変数は何か」 という点です。
Linuxでは、実行主体（手動ログイン、Ansible経由、sudo後）によって、OSがプロセスに割り当てる環境変数が変化します。たとえ同じリモートノード上の操作であっても、Ansibleという実行主体を経由した瞬間に、特定の変数がリセットされたり、設定ファイルの読み込みがスキップされたりすることがあります。
「設定ファイルに書いたから反映されているはず」という先入観を捨て、「リモートノード側で動いているプロセスの真実」 を直接確認することが、解決への一歩となります。
次章では、「手動ログイン」「Ansible経由（一般ユーザー）」「Ansible経由（特権昇格）」 の3つのパターンにおいて、プロセスの $PATH にどのような具体的な差異が生じるかを実機で検証します。
6. 実機検証：Ansible実行環境における環境変数の差異
「手動では動くのに、Ansibleでは失敗する」 という事象の正体を突き止めるため、実行主体や接続方式によって、OSがプロセスに割り当てる「検索対象リスト（PATH）」がどのように変化するかを検証します。
6-1. 【検証1】手動ログイン（SSH）時の状態：比較の基準を確認する
まずは比較の基準（ベースライン）として、一般ユーザーがリモートノードへ直接SSHでログインした際の状態を確認します。
実務を想定し、コントロールノードの作業用ユーザー（guestuser）から、リモートノードの運用ユーザー（ansibleuser）へ接続して検証を行います。
実行準備：
あらかじめリモートノード側に /usr/local/bin/my_command を作成し、実行権限を付与した状態で検証を開始します。
検証コマンドの内容：
#!/bin/bash
echo "Success: Process started by $(whoami)"
検証コマンドの権限：
-rwxr-xr-x. 1 root root 57 4月 27 08:43 my_command
実行手順：
- コントロールノードからリモートノードへSSHで
ansibleuserアカウントにログインする。 - ログイン後、
echo $PATHで環境変数を確認する。 - 続けて自作コマンド
my_commandを実行する。
実行ログ:
①. コントロールノードからリモートノードへSSHでログイン
[guestuser@localhost ~]$ ssh ansibleuser@192.168.1.21
ansibleuser@192.168.1.21's password:
Last login: Mon Apr 27 08:39:03 2026
②. パスの確認
[ansibleuser@localhost ~]$ echo $PATH
/home/ansibleuser/.local/bin:/home/ansibleuser/bin:/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin
↑ 検索対象に /usr/local/bin が含まれている
③. コマンドの実行確認
[ansibleuser@localhost ~]$ my_command
Success: Process started by ansibleuser
↑ コマンド実行成功
この結果から読み取れること
この結果は、OSが正規の「ログインプロセス」を通過し、リモートノード側の .bash_profile や .bashrc などの設定ファイルを正しく読み込んだ状態を示しています。
注目すべきは、/usr/local/bin が検索リスト（PATH）に含まれている点です。OSがコマンドの場所を把握できているため、ファイル名を指定するだけで正常に実行できています。
この状態（ログインシェル）であれば、フルパスを意識せずともコマンドが実行できることが確認できました。では、Ansibleを介した非対話モードではどうなるでしょうか？？
6-2. 【検証2】Ansible経由（非対話モード）での挙動：成功事例
次に、Ansible経由 （非対話モード） でコマンドを実行し、環境変数の読み込み状況を確認します。
- 検証内容:
-
Ansibleのアドホックコマンドを用い、リモートノードの
$PATHを出力。 -
自作コマンド
my_commandを実行。
実行ログ:
※プロンプトの表記は環境により異なります
①. パスの確認
（リモート側で評価させるために \$PATH とエスケープして実行）
(ansible) [guestuser@localhost workspace]$ ansible test_servers -i inventory.ini -m command -a "sh -c 'echo \$PATH'"
192.168.1.21 | CHANGED | rc=0 >>
/home/ansibleuser/.local/bin:/home/ansibleuser/bin:/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin
↑ 検索対象に /usr/local/bin が含まれている
②. コマンドの実行確認
(ansible) [guestuser@localhost workspace]$ ansible test_servers -i inventory.ini -m command -a "my_command"
192.168.1.21 | CHANGED | rc=0 >>
Success: Process started by ansibleuser
↑ コマンド実行成功
結果の分析：
検証の結果、Ansible経由の非対話モードにおいても /usr/local/bin にパスが通っており、コマンドの実行に成功しました。この挙動の根拠は以下の通りです。
1. Bashの公式仕様（SSH経由の実行）
Bashの公式リファレンス （6.2 Bash Startup Files） には以下の規定があります。
"Bash attempts to determine when it is being run with its standard input connected to a network connection, as when executed by the remote shell daemon, usually sshd... If bash determines it is being run in this fashion, it reads and executes commands from ~/.bashrc, if that file exists and is readable."
Bashは、たとえ非対話モードであっても、sshd 等のネットワーク越しに実行されたことを検知すると、~/.bashrc を読み込みます。
2. RHEL系OSにおける読み込みの連鎖
Rocky Linux 9（RHEL系）のデフォルト構成では、~/.bashrc が読み込まれると、以下の連鎖（Chain）が発生します。
-
~/.bashrcが/etc/bashrcを読み込む。 -
/etc/bashrcが/etc/profile.d/*.shを読み込む。
この一連の動作により、システム標準のパスである /usr/local/bin が $PATH に追加された状態でコマンドが実行されます。
6-3. 【検証3】Ansible経由（特権昇格あり）での挙動：失敗事例
続いて、--become オプションを使用して特権昇格（sudo実行）を行った場合の挙動を確認します。
- 検証内容:
-
--becomeを付与し、リモートノードの$PATHを出力。 -
自作コマンド
my_commandを実行。
実行ログ:
※プロンプトの表記は環境により異なります
①. パスの確認
(ansible) [guestuser@localhost workspace]$ ansible test_servers -i inventory.ini -m command -a "sh -c 'echo \$PATH'" --become
192.168.1.21 | CHANGED | rc=0 >>
/sbin:/bin:/usr/sbin:/usr/bin
②. コマンドの実行確認
(ansible) [guestuser@localhost workspace]$ ansible test_servers -i inventory.ini -m command -a "my_command" --become
192.168.1.21 | FAILED | rc=2 >>
[Errno 2] そのようなファイルやディレクトリはありません: b'my_command'
結果の分析：
特権昇格を行った場合、一般ユーザー実行時とは異なり、/usr/local/bin がパスから消失し、コマンド実行に失敗しました。
根拠：sudoの secure_path 仕様
この挙動の根拠は、sudoの公式マニュアル（sudoers(5)）に記載されている secure_path の仕様です。
secure_path: Path used for every command run from sudo. (...)
Rocky Linux 9を含む多くのOSでは、セキュリティ保護のため、sudo実行時に環境変数 $PATH をリセットし、特定の安全なパスのみを使用するように制限されています。/etc/sudoers にて定義されているデフォルト値に /usr/local/bin が含まれていないため、今回の失敗が発生しました。
6-4. 【検証4】フルパス指定による実行：環境に依存しない解決策
検証2と検証3の結果から、Ansibleの実行環境（一般ユーザーか、特権昇格ありか）によって $PATH が動的に書き換わることが確認できました。
これら環境変数の差異に影響されず、確実にコマンドを実行する手段が 「フルパスでの指定」 です。
- 検証内容:
-
シェル（
sh）をフルパスで指定し、become実行時の$PATHを再確認する。 -
自作コマンドをフルパス（
/usr/local/bin/my_command）で指定して実行する。
実行ログ:
※プロンプトの表記は環境により異なります
①. フルパスによる環境変数の再確認
(ansible) [guestuser@localhost workspace]$ ansible test_servers -i inventory.ini -m command -a "/usr/bin/sh -c 'echo \$PATH'" --become
192.168.1.21 | CHANGED | rc=0 >>
/sbin:/bin:/usr/sbin:/usr/bin
②. 自作コマンドのフルパス実行確認
(ansible) [guestuser@localhost workspace]$ ansible test_servers -i inventory.ini -m command -a "/usr/local/bin/my_command" --become
192.168.1.21 | CHANGED | rc=0 >>
Success: Process started by root
結果の分析：
検証3で失敗した become 環境下においても、フルパス指定を用いることで正常にコマンドが実行できることが証明されました。
-
環境変数に依存しない実行
フルパス指定（絶対パス）での実行は、OSがコマンドを探すための仕組み（$PATH）を介さず、指定されたファイルを直接参照します。そのため、secure_pathによって環境変数がリセットされている状態であっても、その影響を受けません。 -
Ansibleにおける実用性
AnsibleのPlaybookを運用する際、ターゲットとなるノードのOSや、実行ユーザー、特権昇格の有無によって環境変数の構成は様々に変化します。
これらの不確定要素を排除し、どのような環境でも意図したコマンドを確実に動作させるためには、標準パス外にあるバイナリはフルパスで記述することが最も確実な手法となります。
7. 実務で遭遇する「コマンドが発見・実行できない」2つの要因
第6セクションの検証結果から、Ansibleでコマンド実行に失敗する背景には、OSのシェル仕様とAnsibleの挙動が複雑に絡み合っていることが分かりました。ここでは実機で証明された確実な要因を整理し、その対策を提示します。
① 非ログインシェルによる「環境設定の未反映」
【要因】
Ansibleはデフォルトで「非ログインシェル（Non-interactive shell）」として動作します。そのため、通常はリモート側の /etc/profile や ~/.bash_profile が自動的に読み込まれません。
-
技術的な影響:
多くのバージョン管理ツール（nvm,rbenv,pyenv等）は、シェルの起動スクリプト（.bashrc等）を通じて実行パスを設定する仕組みを採用しています。Ansibleのような非対話的な実行環境では、これらのパス設定がスキップされるため、導入済みのツールがcommand not foundとなる事象が発生しやすくなります。 -
対策:
特定のシェルの起動プロセスに依存せず、コマンドをフルパスで指定する。
② 特権昇格（become）による「パスの最小化」
【要因】
検証3で確認した通り、become: yes（sudo等）を利用すると、セキュリティ上の制約から環境変数がリセットされます。これはsudoの secure_path という仕様に基づいた挙動であり、パスはOSが定義するシステム最小限（/sbin, /bin 等）に制限されます。
-
技術的な影響:
一般ユーザーの実行環境（検証2）ではパスが通っていた/usr/local/bin配下の自作コマンドやツールであっても、root昇格した瞬間にパスの検索対象から外れ、実行に失敗します。 -
対策: システム標準ディレクトリ（
/bin等）以外にあるコマンドは、必ずフルパスで記述する。
結論：運用負荷を下げるための「フルパス指定」
実務において、実行モード（一般ユーザーか特権昇格か）によって異なる環境変数の状態を都度調査し、リモート側の設定ファイルを微調整して対応を続けるのは、保守コストの観点から現実的ではありません。
どのような実行モードやOS側のセキュリティ設定にも左右されない、最も確実で堅牢な対策は 「コマンドをフルパスで記述すること」 です。
これを「手間」と捉えるのではなく、環境の差異によるトラブルを未然に防ぎ、Playbookのポータビリティ（移植性）を高めるための標準的な作法と考えるのが、安定した運用の鍵となります。
8. まとめ：事象の特定を迅速化する「調査のプロセス」
Ansibleで「手動では動くはずのコマンド」が command not found 等で失敗した際は、以下の3ステップに従って「OS側の実行環境」を確認してください。
【コマンド実行失敗時の調査手順】
1. 実行モードによるパス構成の差異を確認
→ --become（特権昇格）の有無により、OSが検索対象とする $PATH の範囲が切り替わっていないか。
2. リモート側での「現在のパス」を直接出力
→ ansible -m command -a 'sh -c "echo \$PATH"' （必要に応じて --become 付）を実行し、Ansibleのプロセスが実際に参照しているパスのリストを把握。
3. コマンドの所在（配置先）との整合性確認
→ 対象コマンドが配置されているディレクトリが、手順2で出力されたパスのリスト内に含まれているかを確認。
-
本質的な視点
コマンドの実行失敗は、Ansibleの構文エラーではなく、その大半が 「非ログインシェル実行に伴う環境変数の欠落や変質」 です。
「手動なら動く」という主観を捨て、「その実行パターンにおいて、OSは実際にどこを探しているのか」 という実機ログから得られた事実のみで判断することが、トラブルシューティングにおける最短の経路となります。
9. 次回予告
環境変数の仕組みを整理し、コマンドが実行されるまでのルールを確認した後に直面するのが、以下の事象です。
「手動のSSHならログインできるのに、Ansibleだと UNREACHABLE で失敗する」
鍵も設定も合っているはずなのに、なぜ接続が拒絶されるのか。その要因は、ネットワークの到達性、待ち受ける sshd の状態、そしてLinuxの厳格な認証ルールにあります。
次回、第3回：AnsibleのSSH接続が失敗すると UNREACHABLE エラーになる。 をお送りします。
📑 連載の移動
前の記事：【OS編】第1回 ｜ 次の記事：【OS編】第3回
📑 【OS編】全体のまとめはこちら
→ Ansibleが理解できない理由はLinuxにあった【OS編】まとめ
🗺️ 初めての方・シリーズの全体像を知りたい方はこちら
本記事は、OSの仕組みからAnsible設計までを繋ぐ連載シリーズの一部です。
「どこから読み始めればいいか」あるいは、「OS/Shell/Ansible編の関係性」 について把握されたい場合は、以下の統合ガイドで整理しています。
10. 連載一覧：Ansibleが理解できない理由はLinuxにあった
| 回数とタイトル | 内容（概要） |
|---|---|
| Ansibleが理解できない理由はLinuxにあった【OS編】：【保存版】Ansibleトラブル逆引き辞典（Linux / SSH / Shellエラー対応 | Ansibleで発生するエラー（UNREACHABLE / Permission denied / command not found など）を「エラーから逆引き」で調べられる実務向け記事。各回の内容と対応しており、トラブル時の入口として使える。 |
| 第0回：【なぜAnsibleは理解できないのか】仕組みを分解してみる | Ansibleは「Linux操作の自動化」ツール。Ansible → SSH → Shell → Linux の構造を理解し、シリーズ全体の土台を作る。 |
| 第1回：【なぜLinuxが分からないと詰むのか】Kernel / Shell / Filesystemの全体像 | Linuxの基本構造を理解することで、Ansibleが内部で何をしているのか（Shell実行・プロセス・ファイル操作）を把握できるようになる。 |
| 第2回：【Ansibleでハマる】command not foundの原因はPATHだった（環境変数の正体） | Ansible実行時に発生する「command not found」の原因はPATHにある。環境変数の仕組みを理解しないとエラーを解決できない。 |
| 第3回：AnsibleのSSH接続が失敗すると UNREACHABLE エラーになる。（Connection refused / Permission denied / Timeout など） | AnsibleのSSH接続が失敗すると UNREACHABLE エラーになる。SSH（鍵認証・ポート・Firewall）を理解することで原因を特定できる。 |
| 第4回：【Permission deniedの正体】Linuxユーザーと権限の仕組み | Ansibleのbecome（sudo）で発生する Permission denied の原因はLinux権限にある。ユーザー・グループ・権限の仕組みを理解する。 |
| 第5回：【サービスが起動しない理由】systemdの仕組みを理解する | Ansibleのservice / systemdタスクが失敗する原因はLinux側にある。systemdの仕組みを理解することで原因を特定できる。 |
| 第6回：【cronが動かない理由】手動では動くのに失敗する原因 | Ansibleで設定したcronが動かない原因は環境差分（PATHなど）にある。cron特有の実行環境を理解することで解決できる。 |
| 第7回：【No space left on device】ディスク容量不足の原因と調査方法（df / du / log） | Ansible実行時のディスク不足エラーはLinuxのログ肥大化や容量管理が原因。df / duを使った調査方法を解説する。 |
| 第8回：【サーバーが遅い】原因の見つけ方（CPU / メモリ / プロセス） | Ansible実行が遅い・失敗する原因はサーバー負荷の可能性がある。CPU・メモリ・プロセスの見方を理解して原因を特定する。 |