承認したはずの記録が、なぜ消えていたのか

台帳を読んで気づいたこと

Claudeが新しい記事（No.027）の稟議を起票する際、台帳を確認したところ、R-0028からR-0030までの3件が「承認待ち」のまま、対応する記事はすでに公開されている状態になっていた。承認を経ないまま記事が世に出ていたとすれば、それ自体が見過ごせない問題である。

最初の診断は間違っていた

Claudeはまず「人間が承認操作を飛ばした」と診断した。もっともらしい説明であり、実際にそう報告しても不自然ではなかった。しかし、そこで終わらせずGitHub上のレビュー記録を確認したところ、3件とも承認は実際に行われていたことがわかった。抜けていたのは承認という行為ではなく、その行為が台帳に記録として届くまでの過程だった。

Claudeはこの誤診を自ら訂正した。原因は、承認の記録が台帳へ反映される仕組みと、記事が実際に公開される仕組みとの間にわずかな時間差があり、その差の中で記録が間に合わないことがある、というものだった。常に起きるわけではなく、たまたま今回は間に合ったケース（R-0030）もあったため、これまで気づかれずに来ていた。

直そうとして、また失敗した

欠けていた2件（R-0028、R-0029）の承認記録を、GitHub側の実際のレビュー記録をもとに台帳へ補記する作業に入った。ここでも記録しておくべき失敗がある。

• 台帳を差し替えるはずが、貼り付けが末尾への追加になってしまい、データ形式を壊した状態のままコミットしてしまった。同じ作業の中で直したが、失敗した記録そのものは履歴に残っている。
• 修正のためのPRを、本来botが名乗るべきところを人間個人の名義で作成してしまい、自分自身の作業を自分で承認できないという状態を作った。作り直して人間に承認してもらった。

いずれも「直そうとして新しい判断ミスを重ねる」という、AIによる運用にありがちな失敗だった。誤りを認めて即座に作り直す判断自体は機能したが、失敗しなかったわけではない。

本当の問題は「気づける仕組みがなかったこと」

今回、記録の欠落は人間が台帳を直接読んで気づいたものではなく、Claudeが次の稟議を起票する過程でたまたま発見したものだった。日常的な検査の仕組みは、この間ずっと「合格」を出し続けていた。つまり、記録が欠けていることを自動で検知する仕組みが、そもそも存在しなかった。これが今回の一連の出来事のなかで、最も重く受け止めるべき事実である。

承認の記録を本番へ直接書き込む方法へ改める案はできているが、適用には運用ルールの見直しが必要で、判断は人間に委ねられている。仕組みを直すことと、仕組みを直す権限をどこに置くかは別の問題だ。

中小企業にとっての示唆

承認フローを整備している会社は多いが、「承認された記録が、承認された事実どおりに残っているか」を定期的に確認している会社は少ないのではないか。承認そのものより、承認の証跡が正しく残る仕組みのほうが、実は壊れやすい。検査や監査が「異常なし」を出し続けているとき、それは本当に異常がないのか、それとも異常を見つける仕組みがそもそも見ていないのか。この違いを問い直す価値は、AIを使うかどうかに関わらずある。