SOC 2コントロールを維持しながら低リスクPRのAIレビューを導入

昨年、Mirage Securityはコード変更のスループットを146%向上させました（人員調整後）。この飛躍的な成長には、アーキテクチャ、開発プロセス、リリースツールの全面的な見直しが伴いました。しかし、依然として残るボトルネックが1つありました。それは人間によるレビューです。

SOC 2 CC8.1のコンプライアンス要件として、監査可能な変更管理プロセスが必要です。変更は承認、テスト、承認され、管理された方法でデプロイされる必要があります。従来、これはすべての変更に人間のレビューを必要とし、単一の担当者がリスクの高い変更を一方的に本番環境に送り込めないようにしていました。

スループットが倍近くに増加するにつれ、承認キューがボトルネックになりました。エンジニアはコンテキストスイッチを余儀なくされ、レビューして承認ボタンをクリックするまでPRが待機状態になりました。そこでチームは、コンプライアンスを維持し、かつ速度を落とさず、自信を持って導入できる方法はないか模索しました。

監査法人Richey Mayと協力した結果、次のポリシーと技術計画に落ち着きました。

• コードベースのどの部分が高リスクで、どの部分が低リスクかを定義する。
• 低リスク変更はAIコードレビュアーがレビューし、ブロッカーがなければマージできる。
• 高リスク変更には、PR作成者以外の人間によるレビューが必要。
• AI承認されたマージは毎週、人間が全数（サンプリングではなく）レトロスペクティブレビューする。これが自動化のギャップを補うキャッチオールとなり、フィードバックをツール改善に活用する。
• すべてのプロセスをCI/CDスクリプトにコード化し、監査可能で人為的エラーを減らす。

リスク分類の仕組み

核となる考え方：すべてのコード変更が同じリスクを伴うわけではない。ダッシュボードのラベルのコピー変更と、認証ミドルウェアやネットワークインフラの変更はリスクが異なります。

チームはdorny/paths-filterアクションを使用して、PRのオープン時および進化中に分類を行います。変更ファイルが高リスクリストのいずれかに該当する場合、PR全体が高リスクと分類され、人間の承認が必要です。それ以外は低リスクです。

高リスクパスの例：インフラコード（*.tf）、CI/CDパイプライン、アクセス制御、コンテナ定義、環境設定、認証トークン、API契約、データベースマイグレーション、リクエストミドルウェア、テナント境界、暗号化、IDサービス、依存関係など。

分類基準スクリプトとワークフロー自体も高リスクと分類され、変更には人間の承認が必要です。

SDLCゲート

分類後、sdlc-gateというCIワークフローがマージ前に承認ポリシーを強制します。ロジックはシンプルです：

• 高リスクPR：PR作成者以外の人間による承認レビューが必要（ブランチ保護で強制）。human-reviewラベルを付け、以前のai-approvedラベルを削除。
• 低リスクPR：少なくとも1つの承認レビュー（人間またはAI）が必要。AIが承認した場合、ai-approvedラベルを付ける。ラベルは監査証跡として機能し、毎週のレトロスペクティブに利用されます。

AIコードレビュー

チームはClaude Code Action（Claude Opus実行）をAIレビュアーとして使用しています。AIは差分を読み、フラグを立てた箇所にインラインコメントを残し、推奨（✅承認または🚫変更要求）を含むサマリーコメントを投稿します。その後、別のステップがそのサマリーを読み、専用のレビューボットが正式なGitHubレビューを送信します。これはSOC 2にとって重要です。承認は単なるコメントではなく、適切なGitHubレビューイベントである必要があります。AIの推奨があいまいな場合（「条件付き承認」など）、システムはデフォルトで変更要求となります。問題のあるPRを通すより、クリーンなPRに人間のレビューを求める方が安全です。

毎週のレトロスペクティブ

これは他のすべてを検証するコントロールです。毎週金曜日、スケジュールされたGitHub Actionが先週マージされai-approvedラベルが付いたすべてのPRをクエリし、それらをリストアップしたGitHub Issueを生成します。人間のレビュアーがリストを確認し、高リスクと分類されるべきだった変更がないか、例外を記録し、Issueを閉じてサインオフします。レビューウィンドウは前回のレトロスペクティブIssueの作成タイムスタンプにアンカーされ、期間のギャップを防ぎます。各Issueには、それを生成したスクリプトの正確なコミットへのリンクが含まれ、追跡可能性を確保します。

レトロスペクティブIssueの例：期間、AI承認マージの総数、クエリ方法、全PRの一覧（リンク、タイトル、作成者、マージ日時）、およびレビューステップ。

GitHub Actionsワークフロー

3つのワークフローが連携します：

• claude-pr-review.yml：すべてのPRでClaude Code Actionを実行し、レビューボットが正式レビューを送信。
• sdlc-gate.yml：すべてのPRイベント（オープン、同期、レビュー送信）で実行、ファイルを分類し承認ポリシーを強制。
• sdlc-weekly-review.yml：毎週金曜10:30 AM PTにcronで実行、レトロスペクティブIssueを生成。

これら3つのワークフロー、分類基準、強制スクリプト、およびそれらを変更できる人を制限するCODEOWNERSファイルは、CTO承認を必要とするコード所有権ルールで保護されています。

変更管理ポリシー

更新されたポリシーの関連セクションでは、変更リスク分類を定義：高リスク変更はセキュリティコントロール、処理の完全性、可用性、機密性に合理的に影響を与えるもので、非作成者の人間によるレビューと承認が必要。低リスク変更はこれらに影響を与えないもので、AIコードレビューシステムによるレビューと承認が許可されるが、条件として：分類基準は文書化されバージョン管理され、その変更自体が高リスクと分類されること；分類基準と強制スクリプトへの変更アクセスはコード所有権ルールで制限されること；すべてのAI承認マージの全数レトロスペクティブレビューが毎週実施されること。

プロセスを信頼できるか？

AIがコードをレビューするのは恐ろしく聞こえるかもしれませんが、人間も完璧ではないことを認める必要があります。コピー変更、ウィジェット移動、テスト、小規模リファクタリングなど、多くの低リスク変更を人間がレビューすると、レビュー疲れが生じ、重要なものを見逃す可能性が高まります。現在、これらのレビューを処理する優れたツールがあります。また、AIモデルがセキュリティ脆弱性の発見においてほとんどのエンジニアと同等かそれ以上であるという証拠も増えています。

低リスク変更にはAIレビューが適切なゲートです。セキュリティ体制やサプライチェーンに影響を与えるもの（インフラ、認証、テナント境界、暗号化、CI/CD、依存関係、重要なワークフロー）には、引き続き人間の関与が必要です。

このプロセスの目的はAIを盲信することではなく、最も理にかなった場所でAIを活用し、人間が最も重要な場所に集中できるようにすることです。いつの日か、人間がAIレビューなしでコードを書くことさえ許されなくなるかもしれません。