何が起きたのか
terraform apply（または plan、init）を実行したら、次のエラーが表示された：
Error: No configuration files
Apply requires configuration to be present. Applying without a configuration would mark everything for destruction, which is normally not what is wanted. If you still want to proceed, -destroy flag can be used to destroy resources without a configuration.
Terraformがカレントディレクトリをスキャンしたところ、.tfファイルが1つも見つからなかった。ファイルなし、設定なし、何もなし。
このエラーは最悪のタイミングで発生しがちだ——デプロイの真っ最中、何か急いでいるとき、ずっと間違ったディレクトリでコマンドを実行していたとき。あるいはリポジトリをクローンしたら、構造が想定と違っていたとき。いずれにせよ、修正はたいてい cd 1回で済む。
デバッグの手順
ステップ1：現在地を確認する
pwd
ls -la
出力に .tf ファイルがあるか確認する。なければそれが原因だ。Terraformは有効な設定ルートとして認識するために、カレントディレクトリに最低1つの .tf ファイル——空の main.tf でも可——が必要だ。
ステップ2：.tfファイルの実際の場所を探す
find . -name "*.tf" -type f 2>/dev/null
現在地からディレクトリツリー全体を検索する。よくあるパターンはいくつかある：
- リポジトリのルートにいるが、設定ファイルは
terraform/、infra/、またはenvironments/prod/配下にある - サブフォルダにクローンしたまま、その中に
cdしていない - ディレクトリに
.tf.jsonファイルしかない——TerraformはJSON形式の設定もサポートしているので、これらも有効 - 誰かが断りなく
.tfファイルをリネームまたは削除した
ステップ3：モジュールのサブディレクトリに誤って入っていないか確認する
たとえば、リポジトリが以下のような構造だとする：
infra/
├── main.tf
├── variables.tf
├── outputs.tf
└── modules/
└── networking/
├── main.tf
└── variables.tf
infra/modules/networking/ の中から terraform apply を実行しても意図通りには動かない。モジュールはスタンドアロンではない——ルートモジュールから呼び出されることを想定しており、直接 apply するものではない。
修正方法
修正1：正しいディレクトリに移動する
10回中9回はこれだけで解決する：
cd /path/to/your/terraform/root
terraform init
terraform plan
terraform apply
何かを実行する前に、正しい場所にいることを確認する：
ls *.tf
次のように表示されるはずだ：
main.tf outputs.tf providers.tf variables.tf
修正2：-chdir フラグを使う（Terraform 0.14以降）
常にリポジトリルートから開始するCIスクリプトなど、固定された場所からTerraformを実行する必要がある場合は -chdir を使う：
terraform -chdir=./terraform/environments/prod apply
Terraformは何かを実行する前にそのディレクトリに移動する。cd + コマンド と同じだが、1回の呼び出しで済む。作業ディレクトリが保証されないスクリプトやパイプラインでははるかに安全だ。
修正3：ブートストラップ時に最小限の main.tf を作成する
まだ設定が何もない状態で始める場合は、最小限のエントリーポイントを作成する：
touch main.tf
または必要なバージョンを固定する terraform ブロックを追加する：
cat > main.tf <<'EOF'
terraform {
required_version = ">= 1.0"
}
EOF
その後 terraform init を実行する。空または最小限の main.tf でチェックは通過する。Terraformは何か操作対象があればよい。
修正4：リソースを意図的に削除したい場合
エラーメッセージはこのケースも示唆している。設定ファイルなしでステートのすべてを削除するには、次を実行する：
terraform apply -destroy
または従来のコマンドで：
terraform destroy
Enterを押す前によく考えること。ステートファイルが本番リソースを参照している場合、すべてが削除対象としてマークされる——削除範囲を制限する設定ファイルなしで。
修正の確認
正しいディレクトリに移動した（または -chdir を使用した）後、Terraformに設定を検証させる：
terraform validate
期待される出力：
Success! The configuration is valid.
このディレクトリでまだ init を実行していない場合は先にそちらを行う：
terraform init
terraform validate
terraform plan
変更がゼロを示すものであっても、plan が成功すればTerraformが設定を見つけて読み取れることが確認できる。
このエラーを引き起こしやすいリポジトリ構造
チームによってTerraformリポジトリの構成はまったく異なる。特に多くの人がつまずく3つのパターンがある：
# パターン1：環境ベース
infra/
└── environments/
├── dev/
│ └── main.tf ← ここから実行
├── staging/
│ └── main.tf
└── prod/
└── main.tf
# パターン2：コンポーネントベース
terraform/
├── networking/
│ └── main.tf ← ここから実行
├── compute/
│ └── main.tf
└── databases/
└── main.tf
# パターン3：フラット（小規模プロジェクト）
./
├── main.tf ← リポジトリルートから実行
├── variables.tf
└── outputs.tf
慣れないリポジトリでTerraformコマンドを触る前に、意図された作業ディレクトリを README や Makefile で確認する。その30秒の確認で多くの頭痛を防げる。
予防策
再発を防ぐためのいくつかの習慣：
- 正しいディレクトリをハードコードした Makefile またはシェルスクリプトでコマンドをラップする。 CI/CDではパスが固定されているため、ヒューマンエラーが完全になくなる。
- 各ルートモジュールディレクトリに
.terraform-versionファイルを追加する。tfenvなどのツールがバージョン固定に使用し、「これはTerraformルートだ、ここから apply する」という視覚的なマーカーにもなる。 - 実行前に
.tfvarsのYAMLブロックを検証する——変数ファイルが破損したり構文エラーがあったりすると、予期しない動作を引き起こすことがある。toolcraft.app/en/tools/developer/yaml-json-converter のYAML ↔ JSONコンバーターはブラウザ内で動作しアップロード不要なので、内部設定スニペットにも安全に使える。 - CIパイプラインでは素の
cdより-chdirを優先する。 サイレントに失敗するcdは、パイプラインを間違った場所で動かし続ける。-chdirは大きな音を立てて失敗する。
得られた教訓
このエラーは恥ずかしく感じるかもしれない——「ただの間違ったディレクトリ」だから。しかし、経験豊富なエンジニアでも引っかかる。特に、dev・staging・prod環境にまたがって20以上のTerraformモジュールが散在するリポジトリでは。最悪のパターンは深夜2時のインシデントだ——踏み台ホストにSSHし、何か燃えているものを直すために手動でTerraformを実行していたら、1ディレクトリ分ずれていた、というケース。
-chdir フラグが0.14で追加されたのは、まさにこれが繰り返し発生する痛点だったからだ。スクリプトが予測不能な作業ディレクトリから実行される可能性がある場合は、このフラグを使うこと。
最後に1つ注意点：terraform plan は正常に実行されるが予期しないリソースが表示される場合、正しい種類のディレクトリにいるが間違った環境にいる可能性がある。apply する前に staging/ ではなく prod/ を対象にしているかダブルチェックすること。