11-5 · 章 11 · 2 分で読めます

承認と証跡の記録が「はい」の一言より重要な理由

口頭での承認は後で揉める原因に。CI/CDパイプラインにおける承認記録に必要な3要素（承認者、時刻、判断根拠）と監査証跡の構築方法を解説。

承認と証跡の記録が「はい」の一言より重要な理由

深夜にデータベース変更のデプロイについてマネージャーから口頭で承認を得たとしよう。マネージャーは「やっていいよ」と言い、あなたはデプロイを実行し、すべて順調に見えた。ところが1週間後、何かが壊れる。ポストモーテムで「マネージャーが承認した」とあなたが言う。マネージャーはそんな承認をした覚えがないと言う。あなたは今、2つの問題に直面している。障害を引き起こした技術的な問題と、誰が変更を承認したかという争いだ。

このシナリオは、ほとんどのチームが認めるよりも頻繁に発生している。承認は行われたが、その記録が残っていない。誰が「はい」と言ったのか、いつ言ったのか、承認する前に何を見たのかの証拠がない。記録がなければ、承認は存在しなかったも同然だ。

適切な承認記録が捉えるべきもの

適切な承認記録は3つの質問に答える。どれか1つでも欠けると、監査証跡に穴が空き、後で深刻な問題を引き起こす可能性がある。

完全な承認記録がパイプラインの監査ログでどのように見えるかを示す：

{
  "change_id": "DEPLOY-2024-11-05-142",
  "approver": {
    "name": "alice.chen",
    "role": "engineering_manager"
  },
  "timestamp": "2024-11-05T14:30:00Z",
  "evidence": [
    {
      "type": "test_results",
      "url": "https://ci.internal/pipeline/1234/test-report"
    },
    {
      "type": "security_scan",
      "summary": "0 critical, 2 high, 5 medium findings - all waived per policy"
    },
    {
      "type": "change_request",
      "url": "https://tickets.internal/CR-7890"
    }
  ]
}

誰が承認したか

パイプラインは承認を行った人物のIDを記録する必要がある。単なる名前だけでなく、チーム内での役割もだ。テックリードなのか、エンジニアリングマネージャーなのか、DBAなのか。役割が重要である理由は、その人物がその種類の変更を承認する権限を持っていたかどうかがわかるからだ。

さらに重要なのは、システムが承認が実際にその人物から来たものであり、他の誰かがそのアカウントを使って承認したものではないことを検証する必要があることだ。これが、承認ワークフローがチームの認証と統合されたシステムを通じて実行されるべきであり、簡単に偽造や転送が可能なチャットメッセージやメールを通じて実行されるべきではない理由である。Slackのスレッドから「承認済み」メッセージをコピペできるなら、それは承認システムではない。スクリーンショットゲームだ。

いつ承認されたか

タイムスタンプには分とタイムゾーンを含める必要がある。これは過剰に思えるかもしれないが、インシデント調査中に一連のイベントを再構築する必要がある場合にはそうではない。

次のタイムラインを考えてみよう：

変更が14:00に提出
承認が14:30に付与
本番環境へのデプロイが14:45
インシデントが15:10に検出

きれいなタイムスタンプがあれば、物事がどのように展開したかを正確に把握できる。タイムスタンプがなければ、承認がデプロイの前か後か推測することになる。デプロイ後に行われた承認は、承認ではない。ガバナンスを装った単なる通知だ。

何の証拠に基づいて承認したか

これがほとんどのチームが忘れている部分だ。誰かが変更を承認したが、実際に「承認」ボタンをクリックする前に何を見たのか？テスト結果を確認したのか？チェンジログを読んだのか？変更が他のシステムに影響を与えるかどうかを確認したのか？それともすべて大丈夫だと信じていただけなのか？

パイプラインは、判断の根拠となった証拠をキャプチャする必要がある。これには以下が含まれる：

すべてのゲートを通過したパイプライン実行へのリンク
セキュリティスキャン結果のスクリーンショット
レビュー済みの変更要求ドキュメント
チェックおよび確認された内容のサマリー

これらの証拠をキャプチャすると、承認は単なるハンコではなくなり、検証可能な決定となる。誰でも後で振り返って、承認時に何がわかっていたかを正確に確認できる。単に誰かが「はい」と言ったという事実だけではない。

監査証跡の構築

これら3つの情報が一緒になって監査証跡を形成する。監査証跡とは、変更に最初から最後まで何が起こったかの完全な記録である。誰が変更を行い、誰がレビューし、どのゲートを通過し、誰が承認し、いつデプロイされ、デプロイが成功したか失敗したか。

完全な監査証跡には2つの目的がある。第一に、コンプライアンス要件を満たす。社内ポリシーであれ外部規制であれ、すべての変更とそれを承認した人物の明確な記録を持つことは、しばしば必須である。

第二に、より実用的には、インシデント調査をより迅速かつストレスの少ないものにする。何か問題が発生したとき、「誰がやったのか？」「なぜこれが許可されたのか？」と人を追いかける必要がない。答えはすでに記録されている。何が起こったかを再構築する代わりに、問題の修正に集中できる。

実際に機能させるには

最近のCI/CDツールのほとんどは、この情報の一部をすでにキャプチャしている。GitLab CI/CD、GitHub Actions、適切なプラグインを使用したJenkinsは、誰がいつ変更を承認したかを記録できる。しかし、証拠の部分は通常、承認を行う人の手動の努力を必要とする。

修正方法はシンプルだが、規律が必要だ。承認する前に、承認者がレビューした内容のリンクやサマリーをコメントとして追加する習慣をつけること。この習慣がなければ、承認記録は文脈のない「承認済み」とだけ表示される。記録がないのとほとんど変わらない。

さらに進んでいるチームもいる。証拠収集をパイプライン自体に組み込むのだ。承認ステップでは、テスト結果、セキュリティスキャンの結果、変更の詳細のサマリーを承認インターフェースに直接表示できる。承認者はパイプラインから離れることなく必要なすべてを確認でき、システムは表示された内容を記録する。これにより手動コメントの必要性がなくなり、証拠のキャプチャが自動化される。

承認記録のためのクイックチェックリスト

承認プロセスを設定またはレビューする場合は、次のチェック項目を確認しよう：

パイプラインは承認者のIDと役割を記録しているか？
タイムスタンプはイベントシーケンスを再構築するのに十分な精度か？
承認の判断根拠となった証拠は自動または手動でキャプチャされているか？
6か月後に監査証跡をレビューする人が、この変更が承認された理由を理解できるか？
承認システムはチームの認証と統合されており、単なるチャットメッセージではないか？

結論

記録のない承認は承認ではない。それは関係者全員が異なる記憶を持つ可能性のある会話にすぎない。誰が承認したか、いつ承認したか、どのような証拠を見たかをキャプチャすれば、カジュアルな「いいよ、やって」を、レビュー、監査、防御可能な決定に変えることができる。これが、コントロールがあるように見えるプロセスと、実際にコントロールがあるプロセスの違いだ。