IaCコード管理の歴史
こんにちは！
インフラ・SREチームマネージャーのよしたくです。
こちらは株式会社ココナラ Advent Calendar 2025 3日目の記事です。
はじめに
「Terraformのディレクトリ構成、どうするのが正解？」
これは全SREが一度は通る道であり、そして未だに議論が絶えないテーマではないでしょうか。
ココナラでも、組織の拡大やフェーズの変化に合わせて、IaC（Infrastructure as Code）の管理方法を何度も変化させてきました。
本記事では、ココナラにおけるTerraformコード管理がどのような変遷を辿ってきたのか、その歴史をかんたんに紹介したいと思います。
Phase 1. 黎明期
特徴：とりあえず動けばヨシ！
Terraform導入当初のフェーズです。当時はまだTerraformに関する日本語情報も少なく、実装者自身も学習しながら構築を進めていました。
この時期は「構成管理」ということは二の次で、**「とりあえずコード化してGitで管理すること」**が最優先でした。
- 単一のリポジトリに全てのコードをコミット
- ディレクトリ分割のルールはなく、なんとなくサービス名や環境名でディレクトリを切る
service-1/
├── prod/
├── stg/
├── dev/
└── dev2/ # よくわからない名称のディレクトリやファイルの存在
今だからこそ変な構成にしか見えないですが、当時の運用メンバーはかなり少なく、そのメンバーが把握していれば問題なかったためこの時点で構成はそれほど問題になっていません。
Phase 2. メンバー増員期
特徴：モジュール化への挑戦と阿吽の呼吸
インフラ担当メンバーが増えてくると、さすがに無秩序な状態では管理しきれなくなります。
この時期には、以下のような変化が生まれました。
-
ディレクトリ分割のルール化（暗黙）
- マイクロサービスレベルのインフラ単位でディレクトリを分けるという「暗黙の了解」が形成されました
-
モジュール化の開始
- EC2やRDSなど、パラメータを変えれば使い回せるリソースについて、共通モジュール化に挑戦し始めました
- ただしあくまで挑戦レベルであり、後続Phaseにおいてこの時期に作成したモジュールが使えることはありませんでした
-
デプロイフローの確立
- だれが実行可能であるか、CLIツールを使ってどのようにPlan / Applyすることができるのかを整備し、フローを確立しました
ある程度秩序は保たれていましたが、「ドキュメント化されたルール」ではなく「なんとなくの共通認識」で運用されていたため、まだ属人性が残るフェーズでもありました。
Phase 3. サービス拡大期（リポジトリ分割の功罪）
特徴：マイクロサービス流行ってるしインフラも分けちゃえ！
サービスドメインが増え、開発組織も大きくなってきた時期です。
「アプリケーションコードがリポジトリ分割されているなら、インフラもそれに合わせるべきでは？」と考え、サービスドメインごとにTerraformリポジトリを分割しました。
狙い（Good）
-
見通しの良さ
- どのサービスのインフラコードがどこにあるかが明確
-
権限管理
- リポジトリ単位でWrite権限を制御しやすい（AチームはAリポジトリのみ触れる、等）
現実（Bad & 失敗談）
意気揚々と分割してみたものの、運用してみると「あれ、これ辛くないか…？」という事態が頻発しました。
ここが辛かったよリポジトリ分割
-
共通モジュールの管理地獄
- VPCやIAMなど共通で使いたいモジュールを別リポジトリ（moduleリポジトリ）に切り出したが、これを各サービスリポジトリから参照させるCI/CD設定がとにかく面倒
-
バージョン追従のコスト
- あるモジュールを更新した際、それを利用している全リポジトリでバージョン上げのPRを出す必要がある
- 結果、リポジトリによってバージョンがバラバラになり、統制が取れなくなる
-
結局管理者は同じ
- 「権限分離できる！」と意気込んだものの、実際にインフラを触るのはSREチーム（数名）だけだったので、権限を分けるメリットがほぼなかった
「マイクロサービス化」という言葉の響きに引っ張られすぎた結果、運用の複雑さを招いてしまった反省期です。
Phase 4. 成熟期（再集約と標準化）
特徴：モノレポへの回帰とガバナンス
前フェーズの反省を活かし、散らばったリポジトリを再びモノレポに集約しました。
ただし、Phase 1のような「なんでもあり」ではなく、強力なポリシーと自動化をセットにしています。
ポリシー・ガイドラインの策定
ディレクトリ構成、モジュールの設計指針、ステートの分割単位などを明確にドキュメント化しました。
この作業がもっとも大変だったことだと言っても過言ではないかもしれません。
以下に以前の記事を記載していますので、参照ください。
「なんとなく」ではなく「規約」として定義することで、レビューコストを下げ、品質を均一化しています。
適用証跡とChatOps
- 自動適用: 原則として手動applyを禁止し、GitHub Actionsワークフローで自動化
- 承認フロー: 本番環境への適用（apply）前には、Slackへの通知とメンバーの承認（Approve）を必須とするChatOpsフローを組み込みました
これにより、安全性を担保することや適用に対する属人性を排除することに成功しました。
100%モノレポになっていない
このような章立てではあるもののモノレポ化したのはAWS関連のTerraformコードのみであり、そうではないSaasのコードが別リポジトリに残っています。
というのも、当該箇所に関しては
- 現在のSREチームのリソースでは優先的なメンテナンスが及ばない
- 一方で開発部署では実装・リリースサイクルに対してかなりの速度感を求めている
というリソース量と優先度レベルに違いがあるためです。
そのため、その部分に関しては開発部署側でコード化も実装してもらい、権限含め別リポジトリで管理する運びとしています。
Phase 5. AI活用時代（これから）
特徴：AIに「書かせる」ためのコードベース
そして現在、私たちが向き合っているのは「AIといかに共存するか」です。
GitHub CopilotやClaude等の生成AIを活用することを前提としたコード管理へとシフトしつつあります。
本Phaseはまだまだ検証段階であり、またAI自体の進化速度にも目覚ましいものがあるため、この思想自体が都度変わっているかもしれません。
ドキュメントのAI最適化
CLAUDE.md や rules などをリポジトリに配置し、AIに対して「このリポジトリのルール」を明示します。
これまでは人間が読むためのドキュメントでしたが、これからはAIにコンテキストを理解させるためのドキュメントが重要になります。
構成図からのコード生成
Mermaidなどで描いた構成図と、「やりたいこと」の要件を指示することで、Terraformコードを70〜80%程度の確度でAIに実装させるようなフローを目指しています。
人間は「0から書く」のではなく、「AIが書いたコードがポリシーに合致しているかチェックする」「ラストワンマイルの調整をする」役割にシフトしていくと考えています。
まとめ
ココナラのIaC管理の歴史を振り返ってみました。
とくに重要だと感じることは
持論: 一定のプラクティスはあるが「正解」は存在しない
ということです。
その時々の「チームの人数」「メンバーのスキルセット」「プロダクトのフェーズ」「利用できる技術（AIなど）」によって、最適な管理方法は変わります。
Phase 3のリポジトリ分割も、当時は失敗に感じましたが、もしSREが大勢いる組織であれば正解だったかもしれません。
重要なのは、一度決めた構成に固執せず、チームや技術のステージに応じて管理方法を柔軟に最適化し直し続けることだと思います。
明日はま。さんによる記事です。
ココナラでは積極的にエンジニアを採用しています。
採用情報はこちら。
カジュアル面談希望の方はこちら。
Discussion