はじめに
コドモンSREチームの佐々木です。
先日SREチームのメンバーが、こちらのイベントに登壇させて頂きました。
発表ではコドモンでのTerraformの使い方や運用についてお話しし、最後にAIによって運用がどう変わっていくか、という話にも触れました。
その流れを受けて、AI導入後のコドモンのTerraform運用がどう変わって、どこが変わらなかったか、ということを書いてみたいと思います。
なお、コドモンではTerraformを使っているので本記事もTerraform前提です。「AIに合うIaCツールはどれか」みたいな比較論には触れていません。
変わったもの
1. tfファイルの作成/変更
AIを使うようになってから、自分でtfファイルを修正することはなくなりました。自分で変更した方が早いレベルのちょっとした変更でも、AIと壁打ちしてPRをつくってもらうようになっています。
リポジトリの CLAUDE.md や AGENTS.md にコドモンのTerraform運用のルールやPRの書き方を仕込んであるので、
- 背景や経緯、関連するリンクなどをAIがPRのDescription等にまとめてくれる
- そのときは流し読みでマージしても、後から見返したときに「なんでこうなってるんだっけ？」が分かる
- 後日変更するときも、AIがその背景込みで把握してくれているので、変更の整合性が取りやすい
といったあたりがいい感じで回ってくれていて、自分で書くより手早く、かつ後から辿りやすいPRになってくれるなと感じています。
2. tfファイルの書き方
書き手がAI寄りになったことに連動して、tfの書き方ルール自体も変わってきました。
以前は人が見てわかりにくいので、ループや複雑な動的ブロックはなるべく避ける、という考えでした。
ところが最近は、AIが書く、AIが読む、AIがレビュー補助する前提なので、そのあたりはあまり気にしなくていいと思うようになりました。
3. レビュー
最終的に人がレビューして、Approveしてからapplyする、という大枠は変わっていません。
ただ、人にレビュー依頼を出す前に、
- ローカルのAIでPRを作成
- GitHub Appの Amazon Q Developer にレビューしてもらう
- その指摘事項と、
planの結果が意図しないものになっていないかを、再度ローカルのAIでチェック
というのを挟むようにしていて、その上で人にレビュー依頼を出す、というフローに変えています。
これで、人のレビューに回るときには細かい指摘はだいぶ消えている状態になっていて、人側のレビュー負担も減ったなと感じています。
4. ドキュメントの置き場所と書き方
以前は要件、構成、テスト仕様、運用手順などのドキュメントは、別のツールに保存していました。今は
- 積極的にGitHubに寄せる
- リポジトリ内の
docs/配下にmarkdownで置く - AIエージェントから、コードと一緒に読ませる
という方向に少しずつ振っています。
こうしておくと、
- PRを出したときに、AIにルール込みで読ませてレビューしてもらいやすい
- コード変更とドキュメント変更が同じPRで追える
- ドキュメントもGitの履歴に残る
といったあたりが効いてくる気がしています。
変わらないもの（と思うもの）
1. IaCの必要性
AIで変更できるので、IaC自体いらなくなるのでは？という見方もあるかもしれませんが、ここはあまり変わらないと思います。
IaCを使うことにより、
- 誰が・いつ・何を・なぜ変更したかがGitに残る
- PRレビューで第三者の目が入る
- 差分（plan）を事前に確認できる
このあたりは、AIが書くようになっても必要なんじゃないかなと思います。
むしろAIにより変更が容易になり、回数も増えるので、変更前に差分を見て止められる仕組み、変更はIaC経由に通すというガードレールが必要だと思います。
2. CI/CDの仕組み
これも同じく、あまり変わらないと思います。AIだからといってローカルで apply するのはリスクが高いので避けたいですし、レビューできる環境は必要だと思います。
あと、AIとは直接関係ない話ですが、最近のサプライチェーン攻撃を考慮すると、apply を実行するランナーはどうしてもAWSの強い権限を持つことになるため、Atlantisのように実行基盤は自分たちの環境に置くという構成にしたほうがよいと思っています。
今後、AIが自動で apply までやる世界になったとしても、実行基盤の境界線をはっきりさせておく意義はむしろ大きくなる気がします。
3. tfstateの分割
こちらにもありますが、tfstateを 環境 → サービス → リソース種別 の階層で分けたり、VPCやRDSのようにライフサイクルが独立しているものは別tfstateにしたりして、割と細かく分割しています。また、それぞれが依存しないように、ディレクトリ間で terraform_remote_state などによる依存関係は作らないようにしています。
このあたりの方針も、AIを使うようになった今でも正しいんじゃないかなと思っています。
理由としては、
- tfstateが大きいとapply時間が長くなる、というのはAIでは変わらない
- 大きなtfstateはDriftが起きやすく、起きたときの特定コストも大きい
- PRの差分が見にくくなるのは、AIレビューでも人間レビューでも同じ
このあたりは、ストレスなくスムーズに運用していくために必要な対応かなと思っています。
4. モジュールはやはり最小限
モジュールは運用しているうちにこっちとこっちで違う値が必要になるみたいなことが出てきて、結局複雑になりがちなので、あまり使わない方針にしています。
確かに、同じような変更を全箇所に入れる手間や更新漏れを防ぐ、という意味では効果があると思います。ただ、そのあたりはAIが文脈を把握したうえで一括変更してくれるようになったので、モジュールを使うそういう面でのメリットが減ってきた気もしていて、これからもあまり使わない方針でいいのかなと思っています。
まとめ
整理するとこんな感じです（あくまで現時点の所感です）。
変わったもの
| 観点 | 理由 |
|---|---|
| tfを書く主体 | ちょっとした変更も含めてAIに任せるのが普通に。背景込みで書いてくれるので後から辿りやすい |
| tfの書き方ルール | 人の認知負荷を下げるための制約は、AIが書く前提だと意義が薄れてきた |
| レビューの進め方 | 人に依頼する前に Amazon Q Developer + Claude Code で一巡させるフローに。人の負担が減った |
| ドキュメント | GitHubに寄せてAIに読ませる前提に |
変わらないもの
| 観点 | 理由 |
|---|---|
| IaCの必要性 | レビュー・履歴・差分確認の重要性は、むしろAIを使うようになって増していきそう |
| CI/CD基盤の必要性 | サプライチェーン観点でも、強権限はAtlantis等に閉じ込めたい |
| tfstateの分割方針 | apply時間・Drift・PR差分の見やすさはAIで解決しない |
| moduleの使い方 | 重複の手間はAIが吸収してくれるのであまり使わない |
まとめると、
- コードで管理する、小さく分ける、強い権限は閉じる、みたいな構造的な原則はあまり変わらない
- 誰がtfを書くか、どう書くか、どうレビューするか、ドキュメントをどこに置くか、みたいな運用面はAIに合わせてアップデートしていきたい
というのが、今のところの個人的な感覚です。
とはいえこのあたりはAIの進化が早いので、来月には考え方が変わっているかもしれません。「AIが書くから何でも自動でいい」でもなく、「これまで通りでよい」でもなく、その時々の変化に合わせて、変えるところと変えないところを見直しながら対応していく必要がありそうです。
