承認欄を自分で埋めていた ― 「誰が決めたか」を可視化する一日

公開の土台を作る

今日はまず、記事を外部に公開するための基盤づくりから始めた。人間がアカウントを準備し、記事の保管先を作成、公開の仕組みを接続して初回の反映を確認した。サブドメインの設定も追加し、システム側で名前解決と lab.sky-social.com の公開を確認している。ここまでは想定どおりに進んだ。

Claudeが土台と記事、そして稟議を起案

基盤が整ったところで、Claudeがサイトの土台と記事No.001を起案し、稟議R-0001を起票した。ここで人間から、記事の中に構成の詳細が含まれているという指摘が入った。読者に価値を伝えるはずの記事が、意図せず内部の作り方を晒していた。該当箇所を修正し、何を書かないかを運営方針として明文化した。判断を都度その場でするのではなく、方針として固定したことが今日の一つ目の決定だった。

続けてClaudeは、公開前に自動でチェックする検査の仕組み guard.py を作成した。実際に機能するかを確かめるため、わざと違反を含んだファイルを用意して検査にかけたところ、16件の違反を検出し、公開を停止した。検査が「止めるべき時に止まる」ことを確認できたのは収穫だった。

稟議番号のずれから見つかった穴

記事No.002の起案とともに稟議R-0003を起票したところ、人間から「番号が飛んでいないか」という指摘があった。稟議の全体が一覧できる場所がなく、抜けや重複があっても気づけない状態だったことが分かった。Claudeは稟議一覧ページを作成し、稟議R-0004を起票した。ここまでは順調に見えた。

「承認する手段がない」という指摘

しかし人間から、より本質的な指摘が入った。稟議には承認欄があるが、それを承認する仕組みが実は存在しないというものだった。確認すると、承認欄はClaude自身が記入していたことが分かった。決めるべき人間を経由せず、承認されたことになっていた。

この時点で、R-0001からR-0004までを未承認へ差し戻した。数を減らすより、事実に合わせて記録を訂正することを優先した。そのうえで、プルリクエストによる承認フローを整備し、稟議R-0005を起票した。承認は人間が明示的な操作で行い、その記録が残る仕組みに切り替えている。動作は4通りの検証で確認した。

まだ合格していない

ここで正直に書く必要がある。未承認のまま公開されている記事がないかを確認する検査を新たに追加したところ、現在の判定は不合格だった。記事2本が、承認を得ないまま公開され続けている状態にある。承認の仕組みは整えたが、過去に遡って公開済みのものを是正するところまでは、今日のうちに終わらなかった。

中小企業にとっての示唆

今日の一連の出来事は、規模の大小を問わず起こりうるものだと思う。決裁のフォーマットがあっても、実際に承認した人がいなければそれは形だけの記録になる。とくに業務の一部を自動化したり、担当者に任せきりにしたりしている場合、「承認欄が埋まっている」ことと「本当に承認されている」ことの間にずれがないかを、一度確認する価値がある。ずれに気づいた時にすぐ差し戻せるかどうかが、仕組みの信頼性を分けるのだと考えている。