【デバッグ神社、爆誕】Terraform × GitHub Actions で環境を「作って消す」まで

はじめに

こんにちは！デブオプスリードカンパニーの中嶋です。
今回は、チームメンバー（蒔苗、野間田）と一緒に取り組んだ、クラウド環境の自動化についてお届けします！

GitHub Actions から Terraform を実行して、クラウド環境（Azure）の作成と削除をボタンひとつで回せるようにしました。……と書くと一行で済むのですが、そこに至るまではエラーとの格闘の連続でした。

この記事でわかること

• Terraform × GitHub Actions で検証環境を「作って消す」仕組みの全体像

• インフラ自動化でつまずきやすい3つの壁（ゾーン指定・State不整合・クォータ制限）と、その乗り越え方

• 行き詰まったチームの空気を救った「デバッグ神社」の話

インフラ担当の方はもちろん、「チームで難所をどう乗り切るか」に関心のある方にも読んでいただけたらうれしいです。

1. やったこと：環境を「サッと作って、サッと消す」

今回のゴールは、開発や検証に使う環境を「必要なときに立ち上げ、いらなくなったらサッと消せる」状態にすることでした。

具体的なフローはこんな感じです。

• 作成フロー: workflow_dispatch（GitHub Actions を手動で実行する仕組み）や特定ブランチへのPRをトリガーに terraform apply を実行し、数分で検証環境を構築。

• 削除フロー: 検証が終わったら terraform destroy を実行して、不要なリソースを綺麗さっぱり削除。

インフラの構成をコードで管理する IaC（Infrastructure as Code）の考え方をそのまま活かした取り組みです。GitHub Actions に組み込むことで、手作業によるインフラ操作ミスを防ぎつつ、誰でも同じ手順で安全に環境を作ったり消したりできるようになりました。

「消し忘れて課金され続ける」という検証環境あるあるを、仕組みで潰せるのも大きなメリットです。

2. 立ちはだかった壁：リアルなエラーとの闘い

一見スマートに見える自動化ですが、構築初期は当然ながらすんなりとはいきません。実際のデバッグ現場では、次のようなインフラならではの壁にぶち当たりました。

つまずき①：ゾーンが使えない

terraform apply を実行すると、指定したアベイラビリティゾーン（同一リージョン内で障害の影響範囲を分けるための区画）でデータベースやVMを作れず、Azure API から「別のゾーンかサイズを選んでください」と弾かれるエラーが発生しました。

エラーコードはリソースによって異なり、データベース側では ZoneNotAvailableForRegion、VM側では OverconstrainedZonalAllocationRequest が返ってきます。いずれも、指定したリージョンとリソースのサイズ区分（SKU）の組み合わせでは、そのゾーンがそもそも提供対象外だったり、空き容量が足りなかったりするケースです。

対策: コード上でゾーンを固定するのをやめ、zone の指定を外して非ゾーン配置（配置先を Azure 側に委ねる形）に変更しました。可用性の要件が厳しくない検証環境だったため、ここは柔軟性を優先しています。

つまずき②：Terraform State と実環境のズレ

Terraform は「いまどのリソースが存在するか」を State（状態ファイル）で管理しています。途中でエラーが起きると、この State と実際の環境がズレてしまうことがあります。

今回起きたのは、「Azure ポータル上には VM が存在するのに、State には記録されていない」という不整合。この状態で再実行すると「リソースが既に存在する」と怒られ、削除しようとすると「NIC（ネットワークインターフェース）が使用中（NicInUse）」と拒否される、抜け出せないループに陥りました。

対策: Azure ポータルから不要な VM や NIC を手動で削除し、State と実環境を一度まっさらにリセットしてからクリーンビルドを成功させました。

なお、State のズレは本来 terraform state rm や terraform import で個別に整合を取るのが正攻法です。今回は使い捨て前提の検証環境だったため、手戻りの少なさを優先して最短ルートを選びました。本番環境で同じ手は使えないので、State はリモートバックエンドで管理し、ロックをかけて多重実行を防ぐ設計が前提になります。

CI/CD のデバッグは1回の実行に数分〜十数分かかることも多く、エラーログとにらめっこしながら何度も再実行する作業は、地味に精神力を削られます。

3. チームに降臨した「デバッグ神社」

そんなデバッグ作業で少し疲弊していた頃、メンバーの一人がチャット上にチーム専用の「デバッグ神社」（アスキーアート）を設営してくれました。

「デバッグ神社」は、原因不明のバグに悩んだエンジニアが机の上に神社を工作したところバグが収まった、というエピソードから広まったエンジニア界隈の文化です。Web 上に創建された「でばっぐ神社」のようなサービスも存在します。

それがこちらです。

生成AIに「デバッグ神社のアスキーアートを作成してください」と依頼して生まれたものですが、完成度が想像以上でした。

このデバッグ神社のここが凄い

• 左右に「バグ退散」「コード平穏」ののぼりが立ち、中央には「PATCH」と書かれた社（やしろ）

• 社の下には御神体のごとく <ERR> や if (bug) { fix(it); } という祈祷コードが鎮座

• 添えられた「貴方のコードに幸あらんことを。」の一言に、連日のデバッグで疲れたチーム全員がどれほど救われたか分かりません（笑）

これ以降、誰かが「またCI落ちた〜！」と嘆くと、すぐに他のメンバーが「デバッグ神社でお参り（ログ確認）してきな」と声をかけ合うようになり、殺伐としがちなデバッグの空気が一気に温かいものになりました。

4. 最後の壁：本番環境の「クォータ制限」

「デバッグ神社」のご利益（と地道なコード修正）のおかげで、検証環境（STG）でのパイプライン構築が完了。次はいよいよ本番環境（PRD）へのデプロイ検証です。

しかし、ここで最後の大物が立ちふさがりました。

クォータ制限（OperationNotAllowed）発生

本番用の VM を立ち上げようとしたところ、Azure から以下のエラーが返ってきました。

OperationNotAllowed: Approved Total Regional Cores quota exceeded...
（リージョンのコア数上限に達したためデプロイできません）

クォータとは、サブスクリプション単位であらかじめ決められた「使えるリソースの上限」のこと。今回予定していた構成が、この上限に引っかかってしまったのです。

臨機応変なチームプレイで乗り切る

ここで諦めず、デプロイ検証を前に進めるためにチームで迅速に対処しました。

1. 一時的な仕様変更で検証を継続
   本番デプロイのパイプライン自体が正常に動くかを確認することが目的だったため、一時的に VM のサイズを上限内に収まる構成に変更して再実行。無事にデプロイ完了まで通ることを確認し、その日の検証作業を終えました。
   

2. クォータ引き上げの申請
   翌日、権限保有者側でクォータの引き上げ申請を行っていただくよう連携。承認後、当初予定していた構成であらためて本番環境をデプロイし直すことができました。

「上限に当たったから今日はここまで」ではなく、検証の目的を切り分けて前に進める判断ができたのは、チームで動いていたからこそだったと思います。

5. やってみて良かったこと

• ハマりどころのナレッジが溜まった: ゾーン指定、State 不整合、クォータ制限など、インフラ自動化でつまずきがちなポイントをチーム全体で踏破できました。次回以降、同じ壁で止まることはありません。

• コスト削減と運用の効率化: 不要な検証環境の destroy 漏れによる無駄なクラウド利用料をカットでき、ボタンひとつで環境が生えてくる状態を作れました。

• 属人性の解消: 手順がコードとワークフローに落ちているので、「あの人がいないと環境が作れない」という状態から抜け出せました。

おわりに

IaC（Terraform）や CI/CD（GitHub Actions）といった技術そのものも素晴らしいですが、今回いちばんの財産だったのは、それを構築する過程で生まれた「チームの遊び心と助け合いの文化（＝デバッグ神社）」、そしてトラブルに臨機応変に対応するチームワークだったかもしれません。

みなさんのチームでも、デバッグで行き詰まったときはぜひ「デバッグ神社」を建立してみてはいかがでしょうか。（意外と成功率が上がるかもしれません……笑）

最後まで読んでいただきありがとうございました！