規制対象企業におけるリスクベース承認と監査証跡

想像してみてほしい。あなたは顧客取引を扱うフィンテック企業で働いている。あるいは患者記録を保管するヘルステック企業かもしれない。あるいは保険会社で、すべての請求処理がいつでも監査可能でなければならない。規制当局が明日にも訪ねてきてこう尋ねるかもしれない。「その変更を承認したのは誰か？ 正確に何が変わったのか？ 安全であることをどうやって確認したのか？ 問題が発生した場合、チームが正しい手順に従ったことを証明できるか？」

小さなスタートアップでは、チームメンバー間の信頼で十分かもしれない。しかし規制対象企業では、信頼だけでは不十分だ。証拠が必要だ。すべてのステップを文書化し、不変に保存し、いつでも即座に提示できるようにしておかなければならない。

最初に聞かれる質問は決まっている。「すべての変更に長い承認プロセスが必要なら、どうやって素早くリリースできるのか？」 答えは承認をなくすことではない。リスクが実際に存在するポイントでのみ承認を行うことだ。これがリスクベース承認である。

なぜすべての変更が同等ではないのか

考え方は単純だ。すべての変更が同じリスクを伴うわけではない。プロフィールページのボタンの色を変えることと、ローン金利を計算するロジックを変更することは明らかに異なる。トランザクションデータを取得するクエリを編集することと、FAQページのテキストを更新することも同様だ。

規制対象企業のパイプラインは、この違いを認識できなければならない。開発者がプルリクエストを開くと、変更は自動的にステージング環境に流れる。そこでは承認は不要だ。しかし、同じ変更が本番環境にデプロイされようとするとき、パイプラインは停止し、適切な担当者に許可を求めなければならない。その担当者は、コンプライアンス責任者、指名されたテックリード、あるいはセキュリティチームのメンバーかもしれない。

パイプラインは単にランダムな承認を求めてはいけない。誰が、いつ、どのような情報に基づいて承認したのかを把握する必要がある。承認者はテスト結果を確認したか？ 変更内容の説明を読んだか？ 関連するドキュメントが添付されていたか？ これらすべてを自動的に記録しなければならない。手動のスクリーンショットは不要だ。フォルダに保存されたメールも不要だ。これが自動監査証跡である。

次のフローチャートは、プルリクエストから本番環境までの判断経路を示し、リスクレベルがどのように承認ゲートを決定し、監査証跡が自動的に取得されるかを示している。

以下は、GitHub Actionsワークフローで手動承認ゲートを設定する実践例である。環境保護ルールにより、誰が承認できるか、どの証跡が取得されるかを強制する。

name: Deploy to Production

on:
  workflow_dispatch:

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: production
    steps:
      - uses: actions/checkout@v4
      - name: Run tests
        run: make test
      - name: Security scan
        run: make security-scan
      - name: Deploy
        run: make deploy

承認を強制するには、リポジトリ設定で production 環境を設定し、必要なレビュアー（例：compliance-officer, security-lead）を指定し、「承認を待つ」を有効にする。監査ログには、誰が、いつ、どのコミットをデプロイしたかが自動的に記録される。

優れた監査証跡とは

優れた監査証跡とは、「アリスが午後3時42分に承認をクリックした」というだけのログではない。優れた監査証跡は、最初のコミットから本番デプロイまでの変更の全行程を捉える。記録する内容は以下の通り：

• どのコミットが含まれていたか
• 各コミットを誰が書いたか
• どのテストが実行され、合格したか
• 誰がコードレビューをしたか
• 誰がデプロイを承認したか
• デプロイが行われた時刻
• デプロイが成功したか失敗したか

これらのデータは、通常の開発者が変更できない場所に保存されなければならない。この監査ログに書き込めるのはパイプライン自身だけであるべきだ。開発者がログを編集できるなら、監査証跡は無価値だ。

ここで監査証跡（Audit Evidence）の概念が登場する。監査証跡とは、規制当局に対してプロセスがルールに従っていたことを示すために提示できる証拠の集合体である。この証拠は、監査証跡から自動生成されたレポートでもよい。また、セキュリティスキャン結果、負荷テストレポート、デジタル署名された変更ドキュメントなどの成果物でもよい。適切に運営されている規制対象企業では、監査が発表されてから慌てて証拠を集めることはない。パイプラインが変更が行われるたびに自動的に証拠を組み立てているからだ。

スピードとコンプライアンスのバランス

最も難しいのはバランスを保つことだ。緩すぎれば規制当局から警告を受ける。厳しすぎればチームの速度が落ち、イノベーションが停滞し、開発者が不満を募らせる。

解決策は、誰が変更を行ったかではなく、何が変更されたかに基づいてパイプラインがリスクを区別できるようにすることだ。本番データベースへの変更は、フロントエンドコードへの変更よりも明らかにリスクが高い。決済モジュールに触れる変更は、FAQページの変更よりもリスクが高い。パイプラインはこれを自動的に検出し、必要な承認の数を調整するべきだ。

パイプラインはどのようにしてリスクを自動検出できるのか？ いくつかの実践的なアプローチがある：

• パスベースのルール: src/payment/ 配下の変更は2名の承認が必要。src/docs/ 配下の変更は不要。
• ファイルタイプのルール: SQLマイグレーションファイルの変更はコンプライアンス責任者の承認が必要。CSSファイルの変更は不要。
• 依存関係のルール: 暗号化を扱うライブラリを更新する変更は、セキュリティレビューのフラグが立つ。
• スコープ検出: 変更がフロントエンドとデータベースの両方に影響する場合、より広範な承認プロセスをトリガーする。

これらのルールは固定されたものではない。チームが実際に問題を引き起こすものを学習するにつれて進化する。重要なのは、誰かが承認を求めることを覚えているかに依存するのではなく、パイプラインが一貫してルールを強制することだ。

リスクベース承認の実践的チェックリスト

規制環境向けにパイプラインを設定する場合、以下のチェックリストを確認するとよい：

• リスクレベルの定義: システム内の変更の種類をリストアップし、それぞれにリスクレベル（低・中・高）を割り当てる。シンプルに始めること。
• 承認ルールのマッピング: リスクレベルごとに、誰が承認する必要があるか、何人の承認者が必要かを決定する。
• リスク検出の自動化: 変更されたファイル、影響を受けるモジュール、対象環境に基づいて、どのリスクレベルが該当するかをパイプラインが検出できるように設定する。
• 監査データの取得: すべてのパイプライン実行において、誰が何をいつ行い、結果がどうだったかを記録する。追記専用システムに保存する。
• 証拠の自動生成: 監査データを規制当局がレビューできる形式にまとめたレポートまたはダッシュボードを構築する。監査を待ってから作成しないこと。
• プロセスのテスト: 模擬監査を実施する。誰かに規制当局の役を依頼し、証拠が通用するか確認する。実際の監査の前にギャップを修正する。

本当の目標

結局のところ、CI/CDで成功する規制対象企業とは、最も速くリリースできる企業ではない。すべての変更が正しいプロセスを経たことを証明でき、かつ真にリスクの低い変更ではスピードを犠牲にしない企業である。それが、単にコンプライアンスを満たしているだけの組織と、コンプライアンスを満たしつつ競争力を維持している組織の違いだ。

次に規制環境向けのパイプラインを設計するときは、どのツールを使うかから始めてはいけない。まず自問してほしい。「この変更はどのようなリスクを伴うのか？ そして、それを正しく処理したことをどうやって証明するのか？」