生成AI時代に信頼性をどう保ち続けるか - Policy as Code の実践

2026-05-15 クラウドネイティブ会議 SRE Track
https://kaigi.cloudnativedays.jp/

Transcript

1. © CADDi Inc. ⽣成 AI 時代に信頼性をどう保ち続けるか Policy as Codeの実践 2026-05-15 クラウドネイティブ会議 キャディ株式会社 小林 明斗
2. © CADDi Inc. About me • Akito Kobayashi ◦ 通信系 SIer やファッション EC サイトで開発 ・SRE・マネジメントを経験 ◦ 2024年 キャディ入社 ▪ 2024-01 ~ Platform Team ▪ 2024-07 ~ Drawer SRE ▪ 2025-10 ~ Central SRE リード 2
3. © CADDi Inc. © CADDi Inc. ⽬次 3 1. サービス成⻑と⽣成 AI 活⽤と SRE の歩み 2. 解決策としてのPolicy as Code 3. CI チェックの実装 4. 実環境への適⽤ 5. 今後の展望
4. © CADDi Inc. © CADDi Inc. 4 1. サービス成⻑と⽣成 AI 活⽤と SRE の歩み 4
5. © CADDi Inc. 製造業AIデータ プラットフォーム® ※「製造業AIデータプラットフォーム」はキャディ株式会社の登録商標です CADDi 5
6. © CADDi Inc. プロダクトの変遷: 開発組織の拡⼤と事業‧プロダクトの変遷 6 シリーズB 80.3億円調達 シリーズC 118億円調達 シリーズC 91億円追加調達 ⼈ 数 CADDi Drawerに 注⼒ 新規事業開始 (CADDi Drawer) CADDi Quote ローンチ CADDi Drawer ローンチ 製造業AIデータ プラットフォーム 社内向け図⾯管理 システム開発 開発チームごとの⼈数 1 2 3 4 CADDi Drawer 初期 2021〜2022 Manufacturing 事業 2019〜2022 Data Platform 化 2025〜 CADDi Drawer 成⻑期 2023〜2024 1 2 3 4 Manufacturing 事業統合
7. © CADDi Inc. SRE の歩み 7 シリーズB 80.3億円調達 シリーズC 118億円調達 シリーズC 91億円追加調達 ⼈ 数 CADDi Drawerに 注⼒ 新規事業開始 (CADDi Drawer) CADDi Drawer ローンチ 製造業AIデータ プラットフォーム 社内向け図⾯管理 システム開発 開発チームごとの⼈数 Drawer SRE 誕⽣ Platform Team / Drawer SRE が合流 し、横断組織に 開発標準の策定 Central SRE と Embedded SRE に分離 Policy as code の実装 Platform Team 誕⽣ Production Readiness Check Embedded SREs Role の運⽤開始 Policy as code の プロトタイプ、設計 CADDi Quote ローンチ Manufacturing 事業統合 チーム変遷 今回のトピックに 関連する取り組み
8. © CADDi Inc. 8 Make Production Readiness 信頼性 可⽤性 セキュリティ 完全性 運⽤性 オブザーバビリティ 開発プロセスとして、GA (General Availability) 昇格の必須条件とした 背景 サービス拡⼤と組織スケールに備え、 「品質の再現性」を組織で確保。 導⼊の流れ 障害ポイントの明⽂化から始まり、監視標準など 領域を拡張。“Production-Ready Microservices” や他社事例を参考に、さらに拡充。 以下の項⽬遵守を⽬的として、Production Readiness Checklist (PRC) を定義した。
9. © CADDi Inc. 組織‧ビジネス成⻑と⼈⼿による PRC レビューの限界 • SRE が PRC を⽬視レビュー • プロダクトが少ない間は、 負荷は許容範囲内で耐えられる • 運⽤知⾒が溜まっておらず、 チェック項⽬も限定的 • マルチプロダクト化により徐々に 負荷が増⼤ • ⽣成 AI 活⽤により⽣産量も増加 • 複雑化に伴い、PRC の項⽬も増加 レビューがビジネス‧サービス成⻑を阻害する危機 9
10. © CADDi Inc. © CADDi Inc. 10 2. 解決策としての Policy as Code
11. © CADDi Inc. 組織内の「守るべきポリシー」をプログラム可能なコードとして記述し、 その検証‧適⽤プロセスをソフトウェア開発のライフサイクルへ統合する⼿法。 記述 (Declarative) ルールの意図を宣⾔的に記述。 「何が許可‧禁⽌されるか」を コードで定義します。 評価 (Automated) ⼈間の⽬ではなく、エンジンが⾃動で 評価。CI/CD や Admission Controller によって、常に⼀貫して検証します。 管理 (Versioned) Git 等でバージョン管理。いつ‧誰が‧ なぜルールを変更したのかを追跡し、 信頼性の⾼い統制を実現します。 Policy as Code (PaC) とは？ Reviewed by Humans Policy as Code • 判断の属⼈化: レビュアーにより基準がバラつく • ⾼負荷: 膨⼤なチェックリストを⽬視確認 • 遅いFB: レビューまで違反に気づけない • ⼀貫した評価: システムが機械的に厳密判定 • 低負荷: ⼈⼿ゼロで常に⾃動チェック • 即時FB: コードを書き換えた瞬間に検知 11
12. © CADDi Inc. PRC を隠蔽して、認知負荷を減らす ガードレールを自動化することで、エンジニアが価値創出に 100%集中できることを目指す BEFORE: Manual Checklist ⼿動で属⼈的な確認 AFTER: Policy as Code ⾃動で安定したガードレール シフトレフト チェックリストを「実⾏される コード」へ。CI で⾃動検知する ことで、形骸化を防ぎ、品質を 常に実効的なものにする。 イネーブリングの推進 複雑な要件を覚える必要はあり ません。開発者が普通に進める だけで、より正しい道へ導く。 組織的なスケール SRE による個別レビューの依存 を脱却。チーム数が増えても、 ガバナンスの質を維持したまま 開発速度の最⼤化を⽬指す。 12
13. © CADDi Inc. Pull Request Code / Manifest CI Policy Check GitHub Actions Deploy Terraform / ArgoCD Environments terraform plan の結果(JSON)を⾃動検証 Conftest + Rego を⽤いて開発者への即時 FB Google Cloud の⾼可⽤性‧セキュリティ 設定などを検証 k8s YAMLマニフェストを⾃動検証 Kyverno CLI を⽤いて開発者への即時 FB リソース設定や Autoscaling などの ベストプラクティスを検証 CI でチェックする Shift Left 13 Conftest
14. © CADDi Inc. 14 Google Cloud Organization Policy も活⽤し強制する リソース操作の要求 Organization Policy Engine ポリシー違反を検知 設定が組織の制約に抵触した 場合、API が要求を拒否 Terraform, gcloud CLI, Google Cloud Console など あらゆる経路からの要求 API リクエストを リアルタイム検証 最後の砦としての物理的な拒否 CI パイプラインを介さない「⼿動操作」に対し ても有効。ポリシー違反を検知した瞬間に、 Google Cloud の API レベルでリソース作成を 物理的に遮断する。 組織階層による⼀元的な統制 組織‧フォルダ単位で適⽤。新規作成される全プロ ジェクトに対し、デフォルトでセキュアな状態 （例：外部IP禁⽌、Public GCS Bucket 禁⽌など）を 強制継承させる。 14
15. © CADDi Inc. リスクの性質に応じた多層防御：CI による検証と、基盤によるバイパス不能な統制 PLATFORM ENFORCEMENT Google Cloud Organization Policy CI/CD プロセスを経由しない ⼿動操作もブロックする 基盤レベルでの強制ロック。 即インシデントに直結する設 定を遮断する。 SHIFT-LEFT (INFRASTRUCTURE) Conftest (Terraform CI) インフラ構成の妥当性を CI 上でチェック。デプロイ前に 不備を検知し、組織のルール に合致したコードのみを承認 ‧実⾏させる。 SHIFT-LEFT (K8S WORKLOAD) Kyverno CLI (Kubernetes CI) k8s ワークロードの整合性を CI 上でチェック。リソース 間の依存関係を含めて、運 ⽤上安全な設定であること を事前に保証する。 役割 「バイパス不能」な遮断 役割 Terraform IaC に対する検証 役割 k8s manifests に対する検証 Policy as Code Strategy
16. © CADDi Inc. © CADDi Inc. 16 3. CI チェックの実装 16
17. © CADDi Inc. Central Repositories を更新するだけで すべてのプロダクトラインに最新のガバナンスが即座に適⽤される。 PaC のシステム構成：リポジトリ間の関係 Central Pipeline Repo Terraform Repo k8s Repo 全てのポリシー (Rego / Kyverno YAML) を⼀元管理。 共通アクション (Composite Action) として定義され、 各リポジトリから呼び出される。 Terraform / k8s CI が呼び出されたら、ポリシーを pull して検証を⾏う。 CI 実⾏時に Central Pipeline Repo にある Terraform / k8s CI を呼び出す。 Central Policy Repo 17
18. © CADDi Inc. Terraform：Conftest によるインフラ検証 検証の仕組み terraform plan の結果を JSON 形式に変換。 Rego で書かれたポリシーに基づいて、 Conftest がスキャンします。 主なチェック内容 ‧必須ラベルの付与: owner, service 等の強制 ‧Backup 設定: Auto Backup、PITR 設定 ‧ネットワーク: 外部IPの禁⽌ ‧保守性: メンテナンスウィンドウの設定 18 # owner label を強制 deny[msg] { resource == input.planned_values==. not resource.values.labels.owner msg == "Owner label is required" }
19. © CADDi Inc. Kubernetes：Kyverno によるマニフェスト検証 YAML 形式でポリシーを定義し、Kyverno CLI が k8s マニフェストをデプロイ前に検証 します。 ‧Pod の起動停⽌: Probe 設定 ‧リソース管理: CPU/Memory limits の設定 ‧イメージ管理: Image digest 強制や latest 禁⽌ ‧拡張性: オートスケーリング ‧オブザーバビリティ: Metrics / Trace 連携 検証の仕組み 主なチェック内容 19 # 全コンテナの ReadinessProbe を強制 validate: foreach: - list: request.object.spec.containers[] deny: conditions: all: - key: readinessProbe operator: AllNotIn value: "{{ element.keys(@)[] }}"
20. © CADDi Inc. Conftest Rego テスト rego test コマンドにより、Rego の定義とテ ストデータを照合。Terraform ファイルが期 待通りに拒否‧許可されるか検証する。 Kyverno テスト kyverno test コマンドにより、YAML 定義と テストデータを照合。manifest が期待通り 拒否‧許可されるかを検証する。 ポリシーの品質管理： Unit Test の構成 20 Policy Repo ⾃体に test CI を組み込むことで、 ポリシーの変更が誤検知、過剰検知を起こさないようにする test_deny_missing_owner { input == { "planned_values": ==. } results == deny with input as input count(results) == 1 } name: cks-pod-test policies: - cks-pod-001 resources: - bad-pod.yaml results: fail
21. © CADDi Inc. ポリシーの動作を検証するために、本物のインフラ環境を使わず、 「期待される⼊⼒（Mock）」を定義してテストを回す。 Positive Test 「正しい設定」のモックデータを ⼊⼒。ポリシーに適合していると 成功判断されるか確認。 Negative Test 「違反設定」のモックデータを 複数パターン⼊⼒。それぞれの パターンで意図した通りのエラー メッセージが出るか確認。 リソース単体では検証できない 「周囲の環境」を CI 上で再現。 Namespace 属性や外部変数を 擬似注⼊してテストを実⾏。 Context Mocking テストパターンとモック構成：あらゆるシナリオの再現 21 網羅的なテストと多様なモックにより、ポリシーの品質を保つ
22. © CADDi Inc. Q. ⼿法が複数あると、維持管理が⼤変にならないか？ ポリシー記述は ⽣成 AI に任せる 記法の違いは ⽣成 AI が吸収 します。⼈間が Rego や Kyverno の構⽂を覚える必要はなく、 学習コストは限りなく少ない。 ポリシーの品質はテストで⽀える 前述の安定したテスト構成により、属⼈的 なレビューを廃し、⾃動化された品質保証 プロセスを確⽴している。 ポリシーのメンテナンス負荷は？ 22
23. © CADDi Inc. © CADDi Inc. 23 4. 実環境への適⽤ 23
24. © CADDi Inc. Total Violations 1,684 件 「あるべき姿」を定義した瞬間に 突きつけられた現実の負債量 開発の進⾏阻害 このまま導⼊すれば、ほぼ全ての PR がブロック される。 レビュー負荷の爆発 SRE が⼀件ずつ⽬視で確認し、修正を依頼するの は物理的に不可能。 ノイズによる形骸化 ⼤量のアラートは無視され、本当に重要な警告が 埋もれてしまう。 ポリシー種類 リソース総数 現実との衝突：既存負債への対峙 24
25. © CADDi Inc. 段階的に負債を修正する ① 警告通知モード ② 全件トリアージ ③ 段階的強制と オーナーシップ ④ エラー通知モー ド 25
26. © CADDi Inc. 警告通知モード • Conftest / Kyverno のエラーで CI をブロックしない • 「何が正しい設定か」のフィードバックを 返しつつ、開発を⽌めない • 「まずは知ってもらう」 ための習熟期間 MERGE ALLOWED 警告は表⽰されるが マージは拒否しない PR PaC Check Deploy 26
27. © CADDi Inc. 優先度マトリクスによるアクションの決定 ユーザー向けではない内部リソース など過剰検知で あれば、ポリシーの除外設定を⾏う 追加コストの有無 即時実施 (Enforce) ダウンタイム/追加コストなし 検知後速やかに修正を進め、ガバ ナンスを効かせる メンテナンス調整 ダウンタイムあり SRE 主導でビジネス側と調整し、 計画的なメンテナンスを実施 予算‧承認フロー 追加コストあり SRE 主導で関係者へ説明。予算承 認を得た後に実施 ダウンタイムの有無 1. 過剰検知ではないか？ 2. 修正インパクトの評価 全件トリアージ 27
28. © CADDi Inc. 段階的移⾏とオーナーシップ 開発者に丸投げ SRE ⾃ら主導 既存負債に関する Policy Error は無視される慣習 になり形骸化する。 ポリシーの形骸化をさせない。1つ1つ泥臭い実⾏に より、SRE が単なる⾨番ではなく、強く Enable し てくれる組織だという認知と信頼を獲得していく。 開発者の負荷を減らし 正確な影響範囲‧リスクを把握しながら 本番環境の修正も実⾏していく 新規開発アイテムが多くある中で 直ちにユーザー影響はないが リスクがあるものについて優先度を上げにくい 28
29. © CADDi Inc. エラー通知モード • Conftest / Kyverno のエラーで CI をブロックする • 段階的移⾏が完了したことで、CI での通知が信⽤ できるようになる • 今通知されているものは今修正すべきもの MERGE BLOCKED 不備があるコードは マージが拒否される PR PaC Check Deploy 29
30. © CADDi Inc. レビュー負荷の削減 PRC の静的チェック項⽬を⾃動化 開発者はより本質的な議論に集中 フィードバックの⾼速化 ポリシー違反を早期発⾒ ⼿戻りコストを最⼩化し、開発リード タイムを短縮 SRE への信頼構築 「単にブロックする番⼈」ではなく、 「併⾛して安全を守るパートナー」へ 成果：形骸化しない Policy as Code で信頼を構築 30
31. © CADDi Inc. さらに形骸化させないための⼯夫 (1/3) • ポリシー違反通知に Wiki(GitHub) をリンク し、修正を容易に • NG / OK 例を書くことで、⼈間はもちろん ⽣成 AI に修正もさせやすい 31
32. © CADDi Inc. さらに形骸化させないための⼯夫 (2/3) • 除外⽅法はポリシー違反通知にリンクし、 導線を良くする • Central SRE が除外ポリシーの CODEOWNER が となることで、過剰な除外を防⽌ 32
33. © CADDi Inc. さらに形骸化させないための⼯夫 (3/3) • Pull Request (PR) の変更範囲に合わせて、なるべく最⼩単位でチェックする ◦ paths-filter を⽤いて変更されたパスに合わせて最⼩単位でポリシーチェックする ◦ Terraform State / Kubernetes Manifests は環境単位、チーム単位での分割を進め、更に最⼩化する ◦ → PR 作成者に、⾃⾝の修正範囲外の環境や、チームの所掌外のポリシー違反について考えさせない 33
34. © CADDi Inc. © CADDi Inc. 34 5. 今後の展望 34
35. © CADDi Inc. AUTOMATION PHASE 1 CIチェックでの ポリシー違反の⾃動修正 検知された違反に対し、推奨 設定を⾃動適⽤。修正⼯数の 削減と修正ミスの防⽌を同時 に実現。 AUTOMATION PHASE 2 動的チェック項⽬の ⾃動化範囲の拡⼤ PRC のうち、現在は静的検証 できない項⽬も⾃動化。 STRONG GOVERNANCE Kyverno による ⼿動操作の強制統制 Admission Controller を導⼊。 CI を通過しない⼿動リソース 作成に対しても、k8s 基盤上で ポリシーを強制。 今後の展望 PRC の運⽤をさらに⾼度化し、「⼈の⼿によるミス」と「⼿動操作によるバイパス」を テクノロジーによって徹底的に排除していく
36. © CADDi Inc. おわりに • Policy as Code で組織ごとのポリシーを⾃動的に強制しよう ◦ 組織‧サービス成⻑や、⽣成 AI 導⼊などにより⽣産量が増えているならば、⼈ ⼿のレビューがビジネスボトルネックになり得る • ポリシーに熟知した⼈がまずはオーナーシップを持とう ◦ 単なるガードレールになるのではなく、強く Enable しよう • ⾃分たちが整えた仕組みを、誰から⾒ても信頼できる状態に保ち、 組織としての信頼関係を確⽴しよう ◦ 仕組みが正しければ回るわけではない。 愚直に現実に向き合って、信頼できる仕組みを作り上げよう。 36