【クラウドネイティブ会議】生成AIにより膨れ上がるレビューに対し、Poicy as Codeの段階的投入で応戦した試みを解説

生成AIの活用によりコードやIaCの生成が加速し、変更量が増え続ける中、人手によるレビューだけでコードの信頼性を維持することは難しくなっている。「生成AI時代に信頼性をどう保ち続けるか - Policy as Codeの実践」では、キャディ株式会社の小林明斗氏が、Production Readiness Checklist（PRC）を起点に、組織ポリシーをCIや実環境へ組み込むPolicy as Codeの実践を紹介した。

人手レビューが成長のボトルネックになる理由

キャディ株式会社の小林明斗氏は最初に、キャディの事業と開発組織の変遷を紹介した。キャディは「製造業AIデータプラットフォーム」を掲げ、製造業に関わるデータを利活用可能な資産へ変換する事業を展開している。事業はManufacturing事業からCADDi Drawer、CADDi Quote、そしてData Platform化へと広がり、開発組織も拡大してきた。

小林氏は「サービス拡大と組織スケールに備え、品質の再現性を組織で確保する必要がありました」と説明した。当初は、SREがPRC（Production Readiness Checklist）を目視レビューしていたが、プロダクトが少ない間は負荷も許容範囲内だった。しかし、マルチプロダクト化が進むとレビュー対象は増え、生成AI活用によって生産量も増加する。サービスやアーキテクチャが複雑化すれば、PRCの項目も増える。

組織・ビジネス成長と人手によるPRCレビューの限界

この状態について、小林氏は「レビューがビジネス・サービス成長を阻害する危機」と表現した。信頼性を守るためのレビューが、逆にサービス成長のボトルネックになりかねない。ここに、Policy as Codeを導入する背景があった。

Policy as Codeでレビュー依存から脱却する

続いて小林氏は、解決策としてPolicy as Codeを紹介した。Policy as Codeとは、組織内の「守るべきポリシー」をプログラム可能なコードとして記述し、その検証・適用プロセスをソフトウェア開発のライフサイクルへ統合する手法である。

Policy as Codeには、大きく3つの要素がある。第一は「記述（Declarative）」である。何が許可され、何が禁止されるかを、宣言的にコードで定義する。第二は「評価（Automated）」である。人間の目ではなく、エンジンが自動で評価し、CI/CDやAdmission Controllerによって一貫して検証する。そして第三は「管理（Versioned）」である。Gitなどでバージョン管理し、いつ、誰が、なぜルールを変更したのかを追跡できるようにする。

Policy as Code (PaC) とは？

人手レビューでは、レビュアーによって判断基準がばらつきやすく、膨大なチェックリストを目視確認する負荷も大きい。これに対し、Policy as Codeでは、システムが機械的に判定し、コード変更時点で違反を検知できる。

小林氏は、PRCを開発者の前面に出すのではなく、むしろ「隠蔽して、認知負荷を減らす」ことを狙った。「ガードレールを自動化することで、エンジニアが価値創出に100％集中できる状態を目指しました」と小林氏は語った。

実装コンセプトとして示されたのは、3つである。1つ目はシフトレフトである。チェックリストを「実行されるコード」に変換し、CIで自動検知する。2つ目はイネーブリングの推進である。開発者が複雑な要件を覚えなくても、通常の開発フローを進めるだけで、より正しい道へ導かれる状態を作る。そして3つ目が組織的なスケールである。SREによる個別レビューへの依存を脱却し、チーム数が増えてもガバナンスの質を維持する。

具体的なCIチェックでは、Terraformで管理するGoogle Cloudリソースと、Kubernetes YAMLを対象にしている。Google Cloud側では、Terraform planをJSON形式で出力し、ConftestとRegoで自動検証する。Kubernetes側では、Kyverno CLIでマニフェストを検証する。

一方で、CIだけではすり抜けが起こり得る。そこでGoogle Cloud Organization Policyも活用し、CIパイプラインを経由しない直接操作も制御する。CIによるシフトレフトと、実環境側での強制を組み合わせることで、多層防御としてのPolicy as Code Strategyを構成している。

ConftestとKyvernoでCIチェックを実装する

次に、CIチェックの実装が説明された。小林氏が示した構成は、ポリシーを中央で管理しながら、各プロダクトのリポジトリへ継続的に適用する設計である。

中心にあるのは、Central Policy Repoである。ここにConftest向けのRegoポリシーや、Kyverno向けのYAMLポリシーを配置する。次にCentral Pipeline Repoがあり、各プロダクトのCIパイプラインから共通的に参照される。実際の環境を管理するTerraformリポジトリやKubernetesリポジトリは、この中央パイプラインを通じてポリシーチェックを受ける。

PaCのシステム構成：リポジトリ間の関係

この構成により、中央のポリシーリポジトリを更新するだけで、各プロダクトのパイプラインに最新のガバナンスを適用できる。プロダクトごとの個別実装による反映漏れや差分を避け、組織全体に同じ基準を継続的に適用するための設計である。

ただし、ポリシー自体が壊れれば、開発フロー全体に影響する。そのため小林氏は、ポリシーの品質管理も重視した。Conftestでは、Regoの定義とテストデータを用意し、rego testでポリシーが期待通りに動作するかを検証する。Kyvernoでも、ポリシーYAMLとテストデータを用意し、kyverno testで許可・拒否の結果を確認する。

RegoやKyvernoの構文を覚える負荷については、生成AIを活用することで下げられるという。「重要なのは、どのようなポリシーがあるべきかに集中することです。構文面は生成AIに支援させる余地があります」と小林氏は説明した。ただし、生成AIが出力したポリシーが正しく動くとは限らないため、テストによる品質担保が必要になる。

信頼できる仕組みとしてPolicy as Codeを育てる

最後に、キャディ社内で実環境へPolicy as Codeを適用した際の取り組みが紹介された。導入時に既存環境をチェックしたところ、1684件のポリシー違反が検出されたという。このまま強制適用すれば開発が止まってしまうため、キャディでは段階的に移行した。

現実との衝突：既存負債への対峙

移行は、警告通知モード、全件トリアージ、段階的強制、エラー通知モードの順で進めた。まずマージは止めず、開発者に違反を認知してもらう。並行してCentral SREが全件トリアージを行い、過剰検知か、除外すべきか、修正すべきかを判断した。

ここで重要だったのが、Central SREによるオーナーシップである。すぐにユーザー影響が出ない将来リスクは、優先度が下がりやすい。放置すれば、Policy as Codeは通知を出すだけの仕組みになり、やがて形骸化する。そこでCentral SREが主導し、開発者負荷を下げながら本番環境の修正まで進めた。

最終的に、1684件の違反はすべて修正され、エラーでマージをブロックするモードへ移行した。これにより「今通知されているものは、今すぐ直すべきもの」という状態を作った。小林氏は「CIでの通知が信用できるようになり、今通知されているものは今修正すべきものになりました」と語った。

成果としては、レビュー負荷削減、フィードバック高速化、SREへの信頼構築の3点が挙げられた。特に重要なのは、SREが単にブロックする門番ではなく、併走して安全を守るパートナーとして認識されるようになった点である。

また形骸化を防ぐ工夫も紹介された。ポリシー違反レポートにはガイダンスリンクやNG例を含め、人間だけでなく生成AIにも読みやすい状態を作る。また、除外方法を示しつつ、Central SREがコードオーナーを持ち続けることで、過剰な除外を防ぐ。さらに、変更範囲に合わせた最小単位でチェックし、開発者に自分の修正範囲外の違反まで背負わせないようにしている。

小林氏は今後の展望として、CIチェックで検出したポリシー違反の自動修正、負荷テスト結果やSLIの判断基準など動的チェック項目の自動化範囲拡大、Kyvernoによる手動操作の強制統制を挙げた。

最後に小林氏は、Policy as Codeによって組織ごとのポリシーを自動的に強制する重要性を強調した。組織やサービスが成長し、生成AIの導入などによって生産量が増えれば、人手レビューはビジネス上のボトルネックになり得る。そのため、ポリシーに熟知した人がまずオーナーシップを持ち、単なるガードレールにとどまらず、開発を強くEnable（支援）する仕組みとして育てる必要がある。もちろん仕組みが正しいからと言って、それだけで上手く回るわけではない。自分たちが整えた仕組みを、誰から見ても信頼できる状態に保ち、組織としての信頼関係を確立することが求められる。小林氏は「愚直に現実に向き合って、信頼できる仕組みを作り上げることが重要です」と語り、セッションを締めくくった。