AI 駆動 Terraform 開発/SRE_BizReach_MIXI_2

[SRE AI活用事例] 減らせ！TOIL削減大作戦！ AI 駆動 Terraform 開発 AI で Terraform
実装を高速化するにはどうしたら良いのか？

自己紹介大島拓人 / Takuto Oshima 株式会社ビズリーチ / SRE •
金融営業 → SIer → 株式会社ビズリーチ • SIer 時代に Azure, AWS インフラをメインに仕事に従事 • SREチーム所属、現在はアプリケーションチームの新規開発 PJにて、AI 駆動の Terraform 設計を主に担当 • 趣味はバスケ・スノーボード・お笑い・飲み会 • AI のレビューのせいでタバコの本数が一向に減らない。

QUESTION AI 駆動 Terraform 開発ってなんのこと？

今回の発表における AI 駆動 Terraform 開発とは名前の通り AI に Terraform を書かせるための開発手法
ここでは、Terraform の設定値まで正しく AI に判断させ、 Terraform を書いてもらうことを指す本発表の内容（本内容で扱う Skill や知見）は以下を前提とする・「新規開発にて利用する」・「Terraform やインフラに一定の精通をしている人が利用する」

QUESTION 「AI 駆動開発をやったことあるよー」って人？

QUESTION 「AI 駆動開発を Terraform（IaC）でやったことあるよー」って人？

なんとなく難しそうですよね

QUESTION 何が難しいのか？

ANSWER 何が難しいのか？ AI に正しく設定値を判断させることが難しい

QUESTION なぜか？

ANSWER なぜか？そもそも AI に正しく設定値を判断してもらうためのインフラの仕様定義が難しい

要求 → 仕様の変換が難しい APP INFRA 要求から仕様が直接的要求から仕様が間接的ユーザー要求「条件を指定して求人を検索したい」

要求 → 仕様の変換が難しい APP INFRA 要求から仕様が直接的要求から仕様が間接的ユーザー要求「条件を指定して求人を検索したい」仕様をそのまま整理できる
勤務地・職種を受け取り、条件に一致する求人一覧を返す

勤務地・職種を受け取り、条件に一致する求人一覧を返す非機能レベルで整理ピーク 100 RPS p95 500ms以下可用性 99.9% コストはなるべく安く導出が大変決めきれない／オーバーワーク

勤務地・職種を受け取り、条件に一致する求人一覧を返す非機能レベルで整理設定値レベルで整理ピーク 100 RPS p95 500ms以下可用性 99.9% コストはなるべく安く desired_count = xxx timeout = yyy retention_days = zzz 導出が大変決めきれない／オーバーワークほぼ実装

インフラの仕様の定義の難しさ非機能レベルで整理をした場合、オーバーワークになりがち • そもそも決められないものもある設定値レベルで整理をした場合、ほとんど Terraform ができてしまっている • 状態を宣言的に定義する関係上、設定値が決まって以降のコードの複雑性は低め

QUESTION AI にどういう仕様を渡したら Terraform を正しく書いてもらえるのか？

QUESTION AI にどういう仕様を渡したら Terraform を正しく書いてもらえるのか？ A. そもそも仕様（設定値）自体の決定を AI
と一緒に行う

仕様（設定値）自体の決定を AI と行うそもそも Terraform は設定値が決めるが作業の大部分であれば、その決定を高速化すれば、結果として AI による Terraform
開発が回る

QUESTION どう高速化するのか？

まずは、新規開発における Terraform 実装の流れを整備してみるインフラ開発をしたい！

まずは、新規開発における Terraform 実装の流れを整備してみるフェーズ要求把握インフラ開発をしたい！

まずは、新規開発における Terraform 実装の流れを整備してみるフェーズ要求把握全体の設計インフラ開発をしたい！

まずは、新規開発における Terraform 実装の流れを整備してみるフェーズ要求把握全体の設計インフラ開発をしたい！詳細の設計

まずは、新規開発における Terraform 実装の流れを整備してみるフェーズ要求把握全体の設計インフラ開発をしたい！詳細の設計 Terraform
実装

さらに分解してみるフェーズ要求把握全体の設計詳細の設計 Terraform 実装作業単位

さらに分解してみるフェーズ作業単位要求把握どんなアプリケーションが動くか理解する全体の設計詳細の設計 Terraform 実装

さらに分解してみるフェーズ作業単位要求把握どんなアプリケーションが動くか理解するざっくりと全体のインフラ構成を決める全体の設計詳細の設計 Terraform 実装

さらに分解してみるフェーズ作業単位要求把握どんなアプリケーションが動くか理解するざっくりと全体のインフラ構成を決める全体の設計ざっくりと state の分割方針を決める
state A 詳細の設計 Terraform 実装 state B state C

詳細の設計 Terraform 実装 state A state B state C リソース同士の構造を決めるリソース同士の構造を決めるリソース同士の構造を決める

詳細の設計 Terraform 実装 state A state B state C リソース同士の構造を決めるリソース同士の構造を決めるリソース同士の構造を決める個々の設定値を決める個々の設定値を決める個々の設定値を決める

詳細の設計 Terraform 実装 state A state B state C リソース同士の構造を決めるリソース同士の構造を決めるリソース同士の構造を決める個々の設定値を決める個々の設定値を決める個々の設定値を決める Terraform 実装 Terraform 実装 Terraform 実装

分解してみると、ほとんどの部分が仕様整理作業単位どんなアプリケーションが動くか理解するざっくりと全体のインフラ構成を決めるざっくりと state の分割方針を決める仕様整理リソース同士の構造を決める個々の設定値を決める
Terraform コードに落とすコーディング

人間が得意なこと・AIが得意なこと人間が得意なこと AI が得意なこと • コンテキストやドメイン知識が膨大な設計判断 • 調査と定型コード生成 • 全体を通した長期的な整合性の維持
• 小さくフォーカスされたタスク

整理した流れを振り分けてみる作業単位どんなアプリケーションが動くか理解する人間が得意そうざっくりと全体のインフラ構成を決めるざっくりと state の分割方針を決める仕様整理 state
リソース同士の構造を決めるリソース同士の構造を決める個々の設定値（パラメータ）を決める個々の設定値（パラメータ）を決める Terraform コードに落とす Terraform コードに落とすここから小さくなるので AI でもできそう？コーディング AI が得意そう

整理した流れを振り分けてみる作業単位どんなアプリケーションが動くか理解する人間が得意そうざっくりと全体のインフラ構成を決めるざっくりと state の分割方針を決める仕様整理 state
リソース同士の構造を決めるリソース同士の構造を決める個々の設定値（パラメータ）を決める個々の設定値（パラメータ）を決める Terraform コードに落とす Terraform コードに落とすここから小さくなるので AI でもできそう？高速化コーディング AI が得意そう

先を踏まえて、今 PJ で使ってみている Skill 1 どんなアプリケーションが動くか理解する 2 ざっくりと全体のインフラ構成を決める人間がざっくりとした要件を整理する一応人間の判断をチェックする
3 ざっくりと state の分割方針を決める 4 リソース同士の構造を決める 5 個々の設定値（パラメータ）を決める 6 Terraform コードに落とす AIが推奨を出し、人間がチェックする

先を踏まえて、今 PJ で使ってみている Skill 作業単位どんなアプリケーションが動くか理解する人間の判断が問題ないかチェックするざっくりと全体のインフラ構成を決める・人間は issue
に作りたいリソースを state 単位で分割しておくざっくりと state の分割方針を決めるリソース同士の構造を決める個々の設定値（パラメータ）を決める Terraform コードに落とす・issue ベースで入力を受け取り、作成リソース、 state 分割などに懸念がないかチェックを行う

先を踏まえて、今 PJ で使ってみている Skill 作業単位どんなアプリケーションが動くか理解するリソース同士の構造を決めるざっくりと全体のインフラ構成を決めるリソースの依存・接続関係を整理し、 state
内のリソースのトポロジーを決めるざっくりと state の分割方針を決めるリソース同士の構造を決める・インフラのアーキテクチャに関わるような設定値を決定する ex : ・ ecs cluster とアプリを n : m で作るか？・log bucket は集約するか？個別に作るか？ ...etc 個々の設定値（パラメータ）を決める・Terraform レベルの設定値、書き方などについては一切触れない Terraform コードに落とす・判断結果はそのタイミングの決定のスナップショットとして残す

先を踏まえて、今 PJ で使ってみている Skill 作業単位どんなアプリケーションが動くか理解する Terraform の設定値を判断するざっくりと全体のインフラ構成を決める前段の決定をもとに、
Terraform リソース単位で設定値を判断するざっくりと state の分割方針を決める・Terraform MCP Server を利用して、設定値を網羅的に取得リソース同士の構造を決める・設定値の重要度（高・中・低）を分類し、人間が判断しやすく個々の設定値（パラメータ）を決める・全ての設定値に推奨値、根拠、採用しなかった選択肢を提示する Terraform コードに落とす・同様にスナップショットに落とし込み、判断結果を見直せるようにする

先を踏まえて、今 PJ で使ってみている Skill 作業単位どんなアプリケーションが動くか理解する Terraform の記述方式を合意するざっくりと全体のインフラ構成を決める for_each・dynamic・local
変数など、 Terraform の書き方を人間と合意するざっくりと state の分割方針を決める・Terraform の文法的な記載方法を判断するリソース同士の構造を決める個々の設定値（パラメータ）を決める Terraform コードに落とす・合意が取れたら、実際にリソース単位でコードを出力し、人間と合意を得る・全てのフェーズが完了したら全体の整合性チェックを行い、必要に応じて修正が必要なフェーズに戻る

QUESTION この Skill だけで簡単に Terraform が書ける... !?

ANSWER この Skill で簡単に Terraform が書ける... !? 書けない

それっぽいものは生成されるが、質はまだまだとりあえず AI に terraform を書かせると起きがちな悩み • 命名が適当でバラバラ • validation
をとりあえず入れまくる • とりあえずコメントを入れまくる • 片っ端から local 変数に突っ込む ...etc

QUESTION 生成の結果を良くするには？

生成の結果を良くするには？ざっくり2つの方法がある決定論的な仕組みを導入する生成の確率を上げる AI とは別の場所で、機械的にルールを遵守できるような機構を入れる AI 自身が良い生成を行う確率を引き上げる

生成の結果を良くするには？決定論的な仕組みを導入する生成の確率を上げる AI とは別の場所で、機械的にルールを遵守できるような機構を入れる AI 自身が良い生成を行う確率を引き上げるツールによる機械的な判定主なアプローチ linter
formatter scanner

生成の結果を良くするには？決定論的な仕組みを導入する生成の確率を上げる AI とは別の場所で、機械的にルールを遵守できるような機構を入れる AI 自身が良い生成を行う確率を引き上げるツールによる機械的な判定主なアプローチ linter
formatter scanner ディレクション試行回数

生成の結果を良くするには？決定論的な仕組みを導入する生成の確率を上げる AI とは別の場所で、機械的にルールを遵守できるような機構を入れる AI 自身が良い生成を行う確率を引き上げるツールによる機械的な判定試行回数主なアプローチ
主なアプローチ linter ディレクション formatter scanner ハーネスエンジニアリング AI review

どんなハーネスを入れているか？命名規則・ディレクトリ構成・タグ構成・module 利用方針・ファイル分割基準などをガイドライン化 AI がやりがちな過剰・複雑な生成を抑えるようにする • validation は module 以外では原則利用しない
• 「IaC は宣言的に記述し、リソースと設定値が読み手に理解できる状態を重視すること」を記載する • 保守性に寄与しない DRY・抽象化・複雑な関数の組み合わせは避けるよう記載する ...etc コードの書き方が揺らがないよう、規約として固定する • main.tf 内部のリソース順序は依存関係の順 • variables.tf 内部の順序はアルファベット順 • 既定値と同じ設定値であっても、セキュリティ・コストなどのような影響の大きい場合には省略しない ...etc

AIレビュー 1 ハーネスで整備した規約をもとに、コードとドキュメント全体をレビューする 2 指摘は重要度に応じて、基準を分けており、一定基準以上の指摘がなくなるまで修正する 3 AIレビューを繰り返し、指摘が「枯れた」状態になったら、人間が最終レビューする 1回⽬ 2回⽬ n回⽬
AIレビュー AIレビュー AIレビュー ‧‧‧ 修正指摘多い修正指摘減る ✓ 指摘が枯れる PR レビュー

QUESTION これで人間は楽になる...？

ANSWER これで人間は楽になる...？ならない

ハーネスも AI レビューもとても疲れる大量のレビュー指摘が上がってくる • 特にドキュメント周りの指摘が大量に出るレビュー指摘の解決は、AI に自動でやらせきれない • 変な修正が紛れ込んでしまうため、現状人間がチェックをしないとハーネスがぶれていってしまう感じがある
レビュアー自体も AI なので重箱の隅的な指摘や、誤った指摘もあり、人間側はストレスが貯まる

Terraform 開発が楽になっても、AI向けのハーネス整備が増える AFTER BEFORE AI活用後従来 Terraform開発⼈間⼈間が担うアプリケーションを理解する
NEW AI向けハーネス開発人間が担うインフラ構成を決める state の分割方針を決めるリソース構造を決める設定値を決める Terraform コードに落とす Terraform開発 AI が担う

QUESTION じゃあAI駆動でやる意味はない...？

ANSWER じゃあAI駆動でやる意味はない...？ちゃんと意味はある

AI駆動開発を行うことのメリット仕様作成・コーディング部分のスピードは圧倒的に早い AI 向けに整備することで、ドキュメントが自然に残る品質も高くなる（体感）

AI駆動は初期投資に時間がかかるが、全体の開発速度は上がる！ハーネスの整備がある程度終われば、開発コストがグッと下がる（...はず）ハーネス整備のコストが高い開発コスト従来の開発 AI駆動開発ハーネスが整備されることで開発コストが一気に低下複雑性が蓄積し
修正コストが高くなる開発の進行 → 開発の進行 →

とはいえ、不安も残る... 人間によるレビュー・判断は増加しており、Human On The Loop はまだ遠い... AI のモデルに依存しており、適宜ハーネスの調整が必要になる（Opus など）複数人で同時に開発を行った場合、ドキュメント関連の衝突が多々発生しそう
が、やっていくしかない

まとめ仕様（設定値）自体の決定までを AI と一緒に高速化することが大切序盤のハーネス投資が重要で、初期の負荷は普通より大きい開発の高速化 ≠ 人間が楽できる • 人間はジャッジの集中、ハーネスの開発増、
AIレビュー指摘対応など別のつらみが生まれる Icons: Tabler Icons — Copyright © 2020‒2026 Paweł Kuna — MIT License — https://tabler.io/icons

AI 駆動 Terraform 開発/SRE_BizReach_MIXI_2

AI 駆動 Terraform 開発/SRE_BizReach_MIXI_2

More Decks by Visional Engineering ＆ Design

Other Decks in Technology

Featured

Transcript