AIコーディングを監査可能にする——PRゲートと監査ログ

🚪前提: mainへの直接pushは許さない

無人ループの安全性は、最後のドアが1つに絞られているかどうかで決まります。

AIエージェントが直接メインブランチにコードを書き込めてしまうと、監査は事実上不可能になります。私たちの構成では、コードの変更は必ずブランチを切ってプルリクエスト（PR）にし、mainへの直接pushはガードスクリプトで機械的にブロックしています。ドキュメント系の定型更新だけは例外的に許可していますが、それ以外のコード変更は全て「PRを通してからマージ」の一本道です。GitHub自体もブランチ保護ルールとして、レビュー必須化やステータスチェック通過を前提にした保護機能を提供しており（GitHub Docs: About protected branches）、私たちの運用もこの標準的な仕組みの上に成り立っています。

実際にあった例です。複数の自動化タスクが同じファイルを触っていないかを調停する、内製の小さなスクリプトがあります。その自己診断テストが、ある時だけ失敗するようになりました。原因を追うと、テスト内の並べ替え処理が実行環境の文字コード設定（ロケール）によって順序を変えてしまうバグで、手元では通っていたのに別の環境では落ちる、という典型的なパターンでした。

直し方自体は並べ替えの基準を固定する1行でしたが、直したと自称するだけでは終わらせません。複数の文字コード設定で同じテストを再実行して全て緑になったことを確認し、修正をプルリクエストにしてCIでも同じ結果になるのを見てから、ようやくマージしました。AIが「直しました」と言うだけでは終わらせず、修正後に同じチェックを再実行して緑になったことを確認する——ここが監査可能性の core です。

🟢「機械が緑と言うまでマージしない」

AIの「できました」という報告は、そのままでは検証になりません。

私たちが最も重視しているのは、AI自身の自己申告を最終的な合否として扱わないことです。「テストが通りました」「デプロイしました」という報告は、必ず機械的な再チェック（テストの再実行・実際のURLへのアクセス確認・APIの状態照会）で裏を取る運用にしています。

背景には、AIが古い記録から「もう対応済みのはず」と推論して、実際には未対応のまま報告してしまう、という失敗を実際に経験したことがあります。悪意ではなく、AIの推論のクセです。だからこそ、「報告」と「実際の状態」を分けて考え、後者だけを判断材料にするルールにしました。

📒監査ログ: 「誰が・いつ・何を確認したか」を残す

PRの差分だけでは、判断の理由までは残りません。

コードのdiffは残っても、「なぜその判断をしたか」「何を確認してOKにしたか」は、放っておくと消えてしまいます。私たちはコミットメッセージに、変更内容だけでなく「なぜ」を必ず書くルールを敷いています。空虚なメッセージ（「〜を更新」で終わるようなもの）は禁止で、後から見た人がその判断の妥当性を検証できることを基準にしています。

加えて、繰り返し発生する種類の異常（同じチェックの失敗、同じパターンのミスなど）は、簡潔なルールとして常設の記録に1行だけ足す運用にしています。経緯の詳細は別のアーカイブに残し、日常的に参照する記録は増やしすぎない——これも「後から検証できるが、埋もれない」ための工夫です。

この「なぜを書かせるコミット規約」を人力の運用ルールで終わらせず、機械的なゲートとして強制したい場合は、私たちが公開しているエージェント基盤willink-claude-kitの commit-convention-gate が参考になります。prefixの有無・空虚なメッセージ・「なぜ」の欠落を決定論的に検査するゲートとして実装しています。

⏳kill-date: 「無期限の自走」を作らない

一度動かした仕組みを、動かしっぱなしにしないための予防線です。

定期的に自走する仕組みを新しく作るときは、必ず見直し期日か有効期限をセットで決めるようにしています。無期限で回り続ける自走ジョブは、作った本人でさえ「なぜこれが動いているか」を忘れます。期日が来たら棚卸しし、まだ必要か・仕様を変えるべきかを判断する。この一手間だけで、放置された自動化が静かに事故を起こすリスクはかなり減ると感じています。

🧭まとめ: 監査可能性は「後から」設計する

整理します。①mainへの直接書き込みを塞ぎ、変更は必ずPRを通す②AIの自己申告でなく機械的な再チェックで合否を判定する③コミットに「なぜ」を残し、判断を後から検証できるようにする④自走の仕組みには必ず見直し期日をつける。

「AIに開発を任せる」というと、任せた瞬間に手放しになる印象があるかもしれません。実際に回してみて分かったのは、任せるからこそ、後から確認できる仕組みを先に作り込む必要がある、ということでした。