人にやさしく、AIにやさしく、書き手を選ばないIaCのガードレール再考 / Rethinking IaC Guardrails for Humans and AI Alike

Platform Engineering Kaigi 2026
https://www.cnia.io/pek2026/sessions/f5c5abcb-19e9-4983-8521-c863d26f802c/

Transcript

1. ⼈にやさしく、AIにやさしく、書き⼿を選ばない IaCのガードレール再考 2026/09/26 Platform Engineering Kaigi 2026 @kohbis ©MIXI 1
2. ABOUT ME Kohei SUGIMOTO 株式会社MIXI • 2022/04 ~ 『家族アルバム みてね』SRE X/ ©MIXI @kohbis 2
3. 『家族アルバム みてね』について ©MIXI 3
4. 『家族アルバム みてね』について（1/2） 家族アルバム みてねはスマホで撮った⼦どもの写真や動画を家族と共有し、 コミュニケーションして楽しむ家族アルバムサービスです。 ©MIXI 4
5. 『家族アルバム みてね』について（2/2） 2015年にリリースから、7⾔語‧175の国と地域で3,000万⼈以上の⽅にご利⽤いただいています。 人数 国内 海外 30,000,000 25,000,000 20,000,000 15,000,000 10,000,000 5,000,000 0 20 15 20 1 6 20 1 7 20 18 20 19 20 20 20 21 20 22 20 23 20 24 20 25 20 26 年月 .5 ※ iOS‧Android™ アプリ登録者数、ブラウザ版登録者数の合計 ©MIXI 5
6. 『家族アルバム みてね』の開発組織とIaC SREグループがインフラやプラットフォームを管理 • 開発は複数のドメインチーム • 横断組織としてプラットフォーム部があり、 そのなかにSREグループがある ドメインA ドメインB ドメインC チームα チームβ チームγ Security SRE プラットフォーム部 本セッションで 「IaC（Infrastructure as Code）」 と⾔うときは • Terraform ◦ AWS / Google Cloud / GitHub / New Relic etc. • Helm Chart ◦ Kubernetes（Amazon EKS） CRE （どちらもCI/CD、GitOpsの仕組みが構築されているが、今回はスコープ外） ©MIXI 6
7. なにを「再考」するのか なぜ「再考」するのか ©MIXI 7
8. なにを「再考」するのか、なぜ「再考」するのか 1年前の『いま、あらためて考えてみるアカウント管理 with IaC』※1 の続き （2025/08/20 Platform Engineering Meetup Online #4） • 開発者もIaCを書きやすいように整備した（IaCの⺠主化） • 開発者にフレンドリーなコードは、AIにとってもフレンドリーになる（はず！） • ⼀部の権限や、⼀部のSaaSなどから⼩さく始めるのがおすすめ この1年間でAIがコードを書くことが「増えてきた」から「当たり前」になりました そんなAI時代に、IaCにおいてどのようなガードレールを⽬指すのかについて「いま、あらためて考 えてみる」=「再考する」というお話をします つくったものや⼿法の紹介ではなく「こう考えてみました」という内容です 「うちではこう考えるかも」「うちとはここが違う」など、みなさまの組織やプロジェクトではど うか？を思い浮かべながらお聴きいただければ幸いです ※1 https://speakerdeck.com/kohbis/account-management-with-iac ©MIXI 8
9. AIの登場によって 変わったものと変わっていないもの ©MIXI 9
10. 「コードを書く」作業者（書き⼿）が変わった（1/5） AI登場以前から、みてねではIaCをSREではなく可能な限りドメインチームが書く⽅針 • そのためにドメインチームが「書く」負担を減らすための⼯夫をしてきた • いまはTerraformもHelmも、ほぼすべてを「⼈間が指⽰し、AIが書く」 ➡ コードの書き⼿は、ほぼ完全にAIに変わった しかし、IaCがあるべき状態や品質とそれを守るためにやることは変わっていない コードの書き⼿は、AI登場以前からロールやスキルなど多様なメンバーだった ➡ AIは多くの役割をこなせるが、IaCの⽂脈ではそのメンバーがひとり増えただけ ただし、これまでよりはるかに⾼速に、⼤量の変更やPRを作れるメンバー 人間が書く PR レビュー CI/CD 作成される リソース （人間が指示して） AIが書く ここは変わっていない（もちろん、ここにもAIがいることが多い） しかし、ここにいたるまでの速さと数量が圧倒的に増加した ©MIXI 10
11. ルール、ガイドラインの「想定読者」が変わった（2/5） コードを書くときの、ルールやガイドラインを伝えたい相⼿は⼈間だけだった • 規約レベルから「意識してほしい」レベルのガイドラインも⼈間向け • ⼈間にとってわかりやすいようにドキュメントを構造化 • 記載不⾜や省略があっても（よくいえば柔軟に）⽂脈を補う • （おそらく）⻑い⽂章は苦⼿ ⬇ 「AIが読む」ことも前提に書くようになった • AIも構造化されたものほど理解しやすい（⼈間同様） • 記載の不⾜や省略に強い（ただし意図どおりになるとは限らない） • ⻑い⽂章も愚直に読む（ただし参照できるものだけ） ドキュメントの書き⽅の⽅針は変わらないが、⻑さ（量）は⼈間、置き場所はAIに制限がある （記載内容の詳細度はややAIよりだがあまり変わらない） ひとつのドキュメントで⬆を満たせれば、⼈間とAI両⽅に伝わるドキュメントになる ©MIXI 11
12. 書く「難しさ」が変わった（3/5） AI登場以前にあった「IaCは難しい」は書くことへの難しさ ⬇ 基本的に「AIが書く」ようになった • ⼈間が指⽰し、AIが書いたコードを、第三者（⼈間やAI）がレビューする • ⼈間が書いたコードも、AIが修正したり、第三者がレビューする AIが書くようになり、表⾯的な難しさはなくなった しかし残念ながら、抜けや漏れなどは発⽣する ➡ 「⼈間とAIのどちらが書いたのか」は、リポジトリに⼊るコードにとって意味がない ➡ 「誰が書いたのか」ではなく「なにが書かれているのか」「なにがリポジトリに⼊ろうとしてい るのか」を⾒るべきなのは変わらない ©MIXI 12
13. ⽬指すべき「品質」は変わっていない（4/5） AI登場以前からIaCやCI/CDのメリットは明⽩ ⬇ コードの書き⼿にAIが加わり、⼈間もAIも書くようになった 「コードの品質」の定義と計測は難しいのでざっくり「上限」と「下限」を考えてみる • 上限 … インフラとしての設計の良し悪しなど ◦ ある程度はAIも寄与するが、いまも⼈間の⼒量によるところが多い ◦ 実際には明確なラインがなく、上振れも下振れも発⽣する可能性がある • 下限 … フォーマット、命名規則、必須項⽬、危険な設定の抑制など ◦ ⼈間もAIもラインを下回るコードを書く可能性がある ⽬指すべき品質は変わっていないはずだが「誰がやっても同じ品質」は難しい ➡ 上限は（当然）さらに上を⽬指すべきだが、そろえるべきラインはない ➡ 下限はそれより下振れることを許さない、そろえるべき（かつ押し上げるべき）ライン （あらためてIaCやCI/CDを⾒ると「下限をそろえる」点において効果を発揮しやすい） ©MIXI 13
14. プラットフォーム側のやるべきことは変わっていない（5/5） Platform Engineering Kaigi 2026 公式サイト ※1 より " 従来ながらのポータルやゴールデンパス作りだけでなく、AIエージェントが組織内でガバナンス を効かせながら最⼤限の効果を発揮できるような、あらたな仕組み作りが求められています。" しかし「下限をそろえて、下振れを防ぐ」というプラットフォーム側（みてねではSRE）の仕事は AI登場以前から存在していた • AIもメンバーのひとりが増えただけであり、同じ⼊⼒でも出⼒が⼀定でなく、コンテキストに 依存し、前提知識に⽳がある ➡ どれも（いまのところは）⼈間と同じ • ⼈間を想定して「下限をそろえる」理由は、AIにもそのまま当てはまる AI時代にあらたにつくらなければならないものは、実はそこまで多くない むしろ、AI登場以前から必要だったものの重要度と価値が上がっている ※1 https://www.cnia.io/pek2026/ ©MIXI 14
15. プラットフォームエンジニアリングの 考え⽅を当てはめる ©MIXI 15
16. 品質の「下振れを防ぐ」ことはPFEのどこにあたるか 「下限をそろえて、下振れを防ぐ」という仕事を、プラットフォームエンジニアリングの概念に当 てはめることで、より考えやすくなる 概念 今回のケースでは ゴールデンパス 書き手が迷わずに作業できる標準のかたちを、先に提供しておく ガードレール 書き手がルールを外れることを抑制する セルフサービス 書き手自身が変更も改善も可能にする 認知負荷の削減 書き手がルールを覚える必要をなくす シフトダウン ルールを守る責任と知識を、書き手ではなくプラットフォーム側に寄せる （みてねにおける取り組みは後述） ©MIXI 16
17. 「下振れを防ぐ」ための考え⽅と みてねの取り組み ©MIXI 17
18. 「下振れを防ぐ」ための考え⽅と、みてねの取り組み ©MIXI • 「レビュー」を分解する • 同じものが同じように適⽤されるようにする • 守るための「レイヤー」と「検知と抑制」を考える • ルールを継続的に改善する仕組みをつくる • 例外を許容するためにTODOリストをつくる 18
19. 「下振れを防ぐ」ための考え⽅と、みてねの取り組み ©MIXI • 「レビュー」を分解する • 同じものが同じように適⽤されるようにする • 守るための「レイヤー」と「検知と抑制」を考える • ルールを継続的に改善する仕組みをつくる • 例外を許容するためにTODOリストをつくる 19
20. 「レビュー」を分解する（1/2） これまでは、フォーマットやplanのような機械的なチェックはCI、それ以外は⼈間のレビュー レビューでの指摘やアドバイスは • コードに反映するかの強制⼒が、レビュアー（担当またはチーム）に依存する • レビュアーの知識や記憶に依存する • コード量が増えることで、レビュアーの負担およびマージまでの時間が増加する ⬇ AIの登場により拍⾞がかかった また「レビュアーに依存する」部分は、AIがレビュアーになっても発⽣する ⬇ 「レビュー」でなにをしていたのかを分解することで、レビュー以外の最適な⼿段を探す ©MIXI 20
21. 「レビュー」を分解する（2/2） レビューでやっていたこと やりたかったことの特徴 移行先（手段） ①下限を守っているかの判定 必須項目の抜け漏れや、セキュリティ観点で 危険な設定を、リポジトリに入れない ポリシーテスト ②ルールやガイドラインの 徹底 過去の指摘やアドバイスを、以降のPRにも反 映する ロジックを書けるものはポリシーテス ト、書けないものはAGENTS.md ③より高い品質（上振れ）を 目 指す 設計の良し悪しを踏まえて、より良いものにす る 人間によるレビューに残す ものによってはAGENTS.md ①と②はAI登場以前から必要だったが、レビュー（⼀部CI）で間に合ってはいた レビュー（コメント）はその特徴によって分類することができる ⬇ AI登場によってレビューからほかの⼿段に移⾏する価値が上がった 移⾏する作業そのものがAIによって容易になった ©MIXI 21
22. 「下振れを防ぐ」ための考え⽅と、みてねの取り組み ©MIXI • 「レビュー」を分解する • 同じものが同じように適⽤されるようにする • 守るための「レイヤー」と「検知と抑制」を考える • ルールを継続的に改善する仕組みをつくる • 例外を許容するためにTODOリストをつくる 22
23. 同じものが同じように適⽤されるようにする 書き⼿が⼈間であってもAIであっても、同じものが同じように適⽤されるようにしたい • • • 書き⼿にかかわらず、同じチェックを実⾏する ◦ PRごとに同じ処理が実⾏される / 認証や権限に依存しない 読むことができるドキュメントをそろえる ◦ ⻑さは⼈間、置き場所はAIに制限がある 両⽅を満たしたドキュメントがひとつあればよい プラットフォーム側から提供する情報には、エラー情報の設計も含める ◦ 書き⼿が読める場所、読める粒度で出⼒する（⾏、ルール、理由など） ◦ 次になにをすべきかがわかる ➡ 書き⼿が⾃律的に修正できる 書き⼿のAI⽐率が上がっても、仕組み⾃体をつくりかえる必要はない なぜなら、やりたいこと（下限を守ること）は「書き⼿が誰か？」に依存しないから ©MIXI 23
24. （みてねでは）ガイドラインからポリシーテストへの移⾏ Before • ガイドラインに記載されているが⾒逃されている • レビューで毎回指摘していたが、レビュアーの⾒落としによって徹底されない After • conftest（Rego）でポリシーにして、すべてのPRでチェックする ◦ Terraformの場合は、たとえば付与してほしいタグと命名規則など ▪ tfファイルを直接参照するため、AWSの認証も権限も不要 ◦ Helm Chartsの場合は、必ず付与してほしいラベルやセキュリティ関連の設定など ▪ helmコマンドでレンダリングされたマニフェストを参照する （実環境に適⽤するマニフェストと同じもの） • 書き⼿が⼈間でもAIでも同じポリシーが強制される（しかも⾼速に） ©MIXI 24
25. （みてねでは）CIのエラー情報を書き⼿が⾒える場所に出⼒ Before • GitHubでPRを作成した場合、terraform planが実⾏されChecksに通知されるが、失敗した場 合のエラー情報が「 exit code: 1 」だけ （ChecksにあるリンクからAWS上のパイプラインのログを⾒ればわかる状態ではあった） • ⼈間にとっては⾒に⾏く⼿間があり、AIにとってはそもそも権限がなく⾒れない状態 After • Checksに失敗時のエラー詳細情報が記載されるように、パイプラインの処理を修正 • ⼈間にとってもAIにとっても、必要な情報はすべてPR上に存在しており、失敗した場合にはエ ラー詳細を読んで⾃律的に修正が可能 ©MIXI 25
26. 「下振れを防ぐ」ための考え⽅と、みてねの取り組み ©MIXI • 「レビュー」を分解する • 同じものが同じように適⽤されるようにする • 守るための「レイヤー」と「検知と抑制」を考える • ルールを継続的に改善する仕組みをつくる • 例外を許容するためにTODOリストをつくる 26
27. 守るための「レイヤー」と「検知と抑制」を考える 書かれたものが「下限を守っているか（または下振れているか）」は • 「どこで」守るか（レイヤー） • 守っていないことにどう気づくか（検知）と、さらにどう⽌めるか（抑制） レイヤー 検知（気づく） 抑制（止める） 実装 Lintの警告 Lintのエラー、formatの自動修正 CI ポリシーテストをcheck-onlyで実行 ポリシーテストを実行、違反があればエラー 指摘、コメント（人間やAI） approve必須（ゲート）、ブランチルール 監査ログ、定期スキャン、ドリフト検知 作成や変更を拒否する（アドミッション制御） レビュー 実行 ほとんどの場合、より前段で検知または抑制できる（はず） いきなりすべてをやる必要はなく、どれかのレイヤーで検知からはじめることができる ©MIXI 27
28. （みてねでは）レイヤーごとになにをしているか レイヤー 検知（気づく） 抑制（止める） terraform fmt / validate helm lint ベストエフォートの検知 PR作成までは許容される CI ルール違反は抑制必須 terraform fmt / validate / plan helm lint ポリシーテスト（conftest） レビュー SREとAIによるレビュー approve必須（CODEOWNERS） ブランチルール AWSではConfig, Security Hub K8sではPSS（audit） AWSではSCP K8sでは徐々にPSSをenforceに移行中 実装 実行 実装やレビュー時のルールやガイドラインは、READMEやAGENTS.md（後述） ポリシーテストは適⽤範囲を拡⼤中（後述） ©MIXI 28
29. 「下振れを防ぐ」ための考え⽅と、みてねの取り組み ©MIXI • 「レビュー」を分解する • 同じものが同じように適⽤されるようにする • 守るための「レイヤー」と「検知と抑制」を考える • ルールを継続的に改善する仕組みをつくる • 例外を許容するためにTODOリストをつくる 29
30. ルールを継続的に改善する仕組みをつくる ルールは完全を保てないため、ルール違反があったとき、書き⼿のミスではない可能性はゼロにで きない • （特にAI時代においては）組織やシステムの変遷に対して、どんどん古くなっていく • ルール⾃体に誤った記述が混⼊する可能性もある • ルールを適⽤するときに、想定していない範囲に適⽤する可能性もある 最初につくったルールが正しいとは限らない • ルールには、ルールを改善しつづける仕組みもセットで必要 • ものによっては、コード化できる可能性もある ルールを追加 ©MIXI ルール違反 修正対象の 判断 修正 30
31. （みてねでは）レビューからAGENTS.mdを⾃動的に改善する Before • TerraformのPRでレビュー指摘した観点が、PRコメントかレビュワーの記憶にしか残らず、 全体に徹底されない • ドキュメントに追加しても更新されず、古いルールとして存在し続ける After • レビューコメントからルールを抽出し、AGENTS.mdへ⾃動的に蓄積および統廃合するワーク フローを構築 • ⼈間の作業は「AGENTS.mdへの蓄積と統廃合がされたPRをマージする」だけ • 統廃合はロジックで件数や⽂字数で可否を判断し、残すべき（消すべき）記載は基準を明⽂化 してAIによって判断 マージ済み PRの レビューコメント ©MIXI ルール抽出 AGENTS.md改善を蓄積した PRに追記（なければ起票） しきい値超えで統廃合 31
32. 「下振れを防ぐ」ための考え⽅と、みてねの取り組み ©MIXI • 「レビュー」を分解する • 同じものが同じように適⽤されるようにする • 守るための「レイヤー」と「検知と抑制」を考える • ルールを継続的に改善する仕組みをつくる • 例外を許容するためにTODOリストをつくる 32
33. 例外を許容するための「TODOリスト」をつくる ルールを追加したとき、既存リソースが違反している可能性は存在する いきなりすべてをルールに対応させるのはリスクを伴う ⬇ 追加した⽇から新規リソースには適⽤され、既存リソースはあとから徐々に追従したい ⬇ 「TODOリスト」をつくり、ルールの適⽤範囲から（⼀時的に）例外として除外する ©MIXI やること なぜやるか 違反しているリソースを、ルール追加時点でリストにして「例 外」として登録する 既存リソースには影響を出さない（いま動いているものを止 めない） 例外として登録されていないものは、ルールをそのまま適 用する 新規リソースにだけルールが適用される 例外のリストは基本的に追加せず、徐々に登録されている ものを減らす（運用方針） 「いま対応できていないもの」「将来やるべきもの」が人間に もAIにも一目で理解できる 33
34. （みてねでは）TODOリストを活⽤し、段階的に導⼊（1/2） Before • Helm Chartについて、命名規則や⼀部の設定に関するRubyによるテストが存在 • 新たなルールを追加する場合、「テスト対象とするものだけ」をホワイトリスト⽅式で指定 After • Rubyのテストおよびガイドラインにあるコード化可能なルールを、conftest（Rego）に移⾏ し、機械的かつ⾼速に検知可能 ◦ ⼀部Rubyが残っているが、今後完全に移⾏予定 • conftestをうすくラップして、新しいルールの段階的な導⼊が可能 ◦ conftestに備わっているもの ▪ warn, denyの区別 / exception（条件に⼀致する場合は評価をスキップ）/ 外部のYAML, JSONを --data で参照 ◦ ⾃作したもの（もちろんAIで） ▪ TODOリストを⾃動的に⽣成 / denyメッセージのリッチ化 ©MIXI 34
35. （みてねでは）TODOリストを活⽤し、段階的に導⼊（2/2） ① ポリシーテスト（ Rego）で例外を Denyする # 全コンテナで allowPrivilegeEscalation=false を必須化 deny contains msg if { obj := input # Deployment / Job / CronJob workload_kinds[obj.kind] # kind の差分は helper で吸収 spec := workload_spec(obj) some c in array.concat( spec.containers, object.get(spec, "initContainers", [])) object.get(c.securityContext, "allowPrivilegeEscalation", null) != false # どのリソースの、どのコンテナが、何をすべきか msg := sprintf( "%s/%s: container %s の allowPrivilegeEscalation は false が必要です ", [obj.kind, obj.metadata.name, c.name]) } ② TODOリスト（ --data で参照YAML） # ルール名 > chart > Kind/name exceptions: APP_LABEL_TODO: charts/sample-app: - Deployment/sample-app-web SECURITY_CONTEXT_TODO: charts/sample-app: - Deployment/sample-app-web - Deployment/sample-app-worker charts/batch-app: - Job/batch-app-migrate RUN_AS_ROOT_TODO: charts/sample-app: - Deployment/sample-app-web # 既存の違反のみを列挙 # 追加は禁止、削除（＝解消）方向にのみ更新する $ conftest test --policy policy/conftest --data policy/conftest/data/exceptions.yaml rendered/ ©MIXI 35
36. まとめ ©MIXI 36
37. みてねがいま抱えている課題 どうやって横展開していくか • AGENTS.mdの⾃動改善の仕組みは、現在Terraformだけに導⼊している ◦ 開発者からの体感ではプラスのフィードバックをもらっている • 現在は、ルールの抽出や統廃合観点をプロンプトに頼っているところが多いため、ポータビリ ティのあるかたちに改善中 新たな運⽤の定着 • 仕組みは⼊ったが「CIで必ず落ちる」とは違って「PRをマージする」ような運⽤を回せるよ うにしたい 実⾏時の抑制 • 検知も抑制も昔から実践できるプラクティス • シフトレフトを前提にしつつも、より強化していきたい ©MIXI 37
38. まとめ コードの「書き⼿」は、ほぼ完全にAIへと変わった しかし⽬指すべき品質と、プラットフォーム側がやることは変わっていない • レビューを分解して、ロジックにできるものはポリシーテストへ、できないものはドキュメン トへ • ルールをつくるときは、継続的に改善できる仕組みとセットでつくる • 例外リストを、TODOリストとして導⼊するのがおすすめ AI時代のガードレールを「AIのためにつくる」ではなく 「⼈間とAIの区別なく運⽤する」と判断したひとつの事例としてご参考になれば幸いです ©MIXI 38
39. さいごに WE ARE HIRING!!! https://team.mitene.us ©MIXI 39
40. ありがとうございました ©MIXI 40