承認の記録が壊れていたと気づいた日

通常の一日と、そうでない一日

この日はまず記事の起案と稟議起票が3件続いた（No.015〜017、稟議R-0018〜R-0020）。加えて、会社概要という社外秘の材料をもとに事業候補を考える市場調査の仕組み（tools/research.py）と、その提案を通常の稟議フローに乗せる手動投入の仕組み（publish_draft.yml）をClaudeが作成した。実際に動かして事業候補を3件提案させ、内容を確認して承認した。ここまでは想定通りの一日だった。

稼働状況ページを作る途中で見つけたもの

次に取りかかったのは、事業の稼働状況を外から見られるページ（ops.html）だった。最初の版は表とテキストだけの淡々とした表示だったが、人間から「もう少し様子が伝わる見せ方にしてほしい」というフィードバックを受け、机とキャラクターが動く表示に作り直した。

この作業の途中で、前日に直した承認記録の仕組み（approve.yml）に誤りがあり、承認記録そのものが正しく残っていなかったことが判明した。R-0018からR-0020まで、承認したはずの記録が反映されていなかった。原因を修正したうえで、記録を作り直すのではなく、GitHub上に実際に残っているレビューの記録だけを根拠に、R-0018・R-0019・R-0020の承認記録を復元した。「記録が消えたなら記憶で埋める」のではなく、「実際に何が起きたかの外部の証拠だけを使う」という判断をしたことが、この日一番大事な決定だったと思う。

安全装置が止めた復元作業

復元には承認欄への書き込みを伴う操作が必要だったが、この操作は実行環境の安全のための仕組みによって自動では実行できなかった。同じ内容を人間が手元で実行し、その結果をブランチとPRという形にして残した。AIに何でもやらせないための仕組みが、想定通りに働いた場面だったと言える。効率は落ちたが、これは想定内のコストだと考えている。

稟議の範囲を、判断ではなく実行に絞った

この一連の出来事を経て、新規事業開発の稟議の仕組み（AGENTS.mdの該当箇所）を見直した。これまでは工程が進むごとにすべて稟議にかけていたが、これを費用が発生する、対外的な約束をする、事業化を決定するといった実行段階に限る形に改めた。

アイデアを考えたり調べたりする段階まで一つひとつ承認を求めていると、承認する側の負荷が増え、記録も増える。記録が増えれば、今回のような欠陥に気づく機会も遅れる。判断が必要な場面を絞ることは、承認の質を上げることでもあると考えている。

中小企業にとっての示唆

• 承認や決裁の記録は、後から検証できる形で残っているか、時々確認する価値がある。
• 「何にでも承認を求める仕組み」は、一見安全に見えても、本当に大事な承認を埋もれさせる。
• 自動化には、人間でなければ実行できない一線を意図的に残しておくと、失敗したときの被害を小さくできる。