10X SREの栗原です。
この記事は10X 新春ブログリレー 2026の1月28日分の記事です。
株式会社10Xでは、SREチームとセキュリティチームが合同で「技術改善キャンプ」を定期的に開催しています。 事業の優先度や日々の対応に押されがちな…でも大事なタスクへ、まとまった時間で取り組むためのイベントです。
本記事では、その取り組みの一例として、私が第6回（2026/1/26）で検討した「Terraformを管理するリポジトリのレビュー負荷をAIで減らせないか？」というテーマを紹介します。
なお、今回キャンプ内で実装（PoC作成）まで到達したわけではありません。検討と設計（Design Docの作成）までがスコープです。
技術改善キャンプとは
技術改善キャンプは、平たくいうと「普段は優先度の壁に阻まれがちな改善へ、全員で集中して取り組む日」です。
目的は大きく3つあります。
- 「やるべきだが、Qのフォーカスや事業優先度の都合で後回しになりがちな重要タスク」を消化する
- やりたかったけどやれなかったことをやる
- 同じタイミングで同じ趣旨の改善に取り組み、交流を深める
普段はリモートで仕事をしていますが、キャンプ当日は可能な限りオフィスへ集まり、最初と最後は同期的に話す場を設けています。
開催時間は10時〜17時で、13時〜14時はみんなでランチ、16時〜17時は発表の時間です。
冒頭では各自が取り組むテーマを発表し、最後に成果発表をします。
成果発表は「完成物の存在」だけが価値ではありません。うまくいかなかったとしても、何を試し、何が分かったのかを共有すること自体も、十分な成果になります。
今回の私のテーマ：TerraformレビューをAIで“減らせないか？”
SREとして日々運用する中で、Terraformのレビューに「けっこう時間を取られている」感覚がありました。
そこで、ざっくり集計してみると、SREは3人にもかかわらずTerraformのレビューを 年間で約2300件 していたことが分かりました（リリース用PRなども含まれるため、純粋なTerraform変更だけではもう少し少ないはずですが、それでも負荷は小さくありません）。
この負荷を減らすために、次の仮説を立てました。
AIがレビューし、条件を満たすものはAIがApproveまでできれば、レビュー負荷を下げられるのでは？
もちろん、ApproveまでAIにやらせるなら、権限設計・誤Approveの防止など、考慮すべきことが一気に増えます。そこでキャンプでは、まず 「どこまでなら安全に任せられるか」 を明確にし、設計として成立するか（Design Doc）を詰めることに集中しました。
Terraformの品質をどう担保するか
「AIにレビューを任せる」と言っても、そもそもレビュー対象の品質がバラついていると、AIだけでなく人にも厳しいです。
10XではTerraformの書き方や運用の勘所が整理されており、品質担保の下地があります。特に、社内のベストプラクティスがまとまった次の記事に助けられている部分が大きいです。
https://product.10x.co.jp/entry/2026/01/09/154331
（この「土台」があるからこそ、AIに“機械的にチェックさせる範囲”を切り出しやすい、という話でもあります）
AIがレビューする範囲を限定する
今回の方針は、「AIが変な挙動をしても被害が小さい範囲」に限定して、レビューの一部を委譲することです。
具体的には、PRを受け取ったときに次のようなルールで分岐させる案を考えました。
- PRの変更が develop環境以外 を含む場合は、AIレビュー対象外（人間がレビュー）
tfplan.jsonを取得する（plan結果をJSON化したもの）resourceの削除がある場合は、AIレビュー対象外（人間がレビュー）resourceにiamが含まれる場合は、AIレビュー対象外（人間がレビュー）- 上記をすべてクリアした場合に限り、AIレビューを走らせる
ここでいう tfplan.json は、Terraformのplan結果です。
具体的には、terraform plan -out=tfplan.out のようにplanをバイナリ形式で出力し、そのファイルを terraform show -json tfplan.out でJSONに変換したものを想定しています。
今回の案では、このJSONを「静的解析結果」としてAIに渡します。
図にすると、次のようなイメージです。
この時点で「そこまで限定するなら、AIじゃなくて自動Approveでもよいのでは？」というツッコミが入りそうです。 それは半分そのとおりです。だからこそ今回は「AIである必然性」も含めて検討対象にしました。たとえば、将来的にチェック項目を増やしたり、例外を柔軟に扱ったりするなら、ルールベースの自動化よりLLMのほうが適していそうです。 一方で、現時点のスコープでは“AIでなくてもよい”ラインに近いのも事実で、その見極めも含めてのDesign Docです。
AIに渡す情報は、可能な限り静的解析済みの結果（tfplan.json）に寄せます。
イメージとしては、次のフローです。
要点は次のとおりです。
tfplan.jsonとプロンプトをAI（例：Vertex AI）に渡す- 出力はJSONで返すように指示する
- 返ってきたJSONのフラグ（例：review要件を満たすか）に応じて
- 満たす：PRにApproveを付ける
- 満たさない：Approveしない（= 人間レビューに回す）
最近はCopilot SDKのような選択肢も出てきており、GitHub上の体験に自然に組み込める可能性があります。
ただし、キャンプ当日は時間切れで、PoC作成までは到達できませんでした。実装に着手する前段として「そもそもApproveを付ける主体をどうするか」という設計が詰め切れていなかったのも大きいです。
Approveの認証と権限設計
Design Docを書いている段階では、「GitHub Appで認証してApproveを付ければ良さそう」と考えていました。
ところが発表の場で、GitHub AppはCODEOWNERSに含められないことを知りました。これにより、「CODEOWNERSで最終的に守りたいルール」と「Approveを付ける主体」の整合が一気に難しくなります。
代替としてPAT（Personal Access Token）を使う案もありますが、PATは運用を間違えるとセキュリティリスクになり得ます。 このあたりのリスク評価を詰め切れず、現時点では設計が宙に浮いた状態です。
キャンプは“止まっていた改善”を動かすよいきっかけ
普段は目の前のタスクに忙殺されて、こうした改善にまとまった時間を取りづらいのが正直なところです。その点、技術改善キャンプのような機会は非常にありがたく、「止まっていた問い」を前に進める力があります。
次回は、認証方式の現実的な落とし所（GitHub App / PAT以外の選択肢も含む）を設計してPoCを作るところまで進めたいと思います。
一方で、SREは少人数体制ということもあり、日々の運用やレビューに追われて「やりたい改善があっても手が回らない……」となりがちです。正直なところ、こういう改善を一緒に進められる仲間がもっとほしいなと思っています。
株式会社10Xでは、SRE / セキュリティを含め、プロダクトを一緒によくしていく仲間を募集しています。こうした改善活動に興味のある方がいれば、ぜひお話ししましょう。
