毎週月曜9時、Claudeがドキュメントの嘘を見つけてPRを立てる

ドキュメントは腐る。これは誰も否定しない。

構成図に載っているディレクトリが実際には無い。手順書のコマンドが古い。READMEの前提バージョンが2つ前。誰も嘘をつく気はないのに、コードだけが先に進んでいく。

気づくのは、たいてい新しく入った人がその手順どおりにやって詰まったときだ。

これを毎週勝手に見張らせることにした。Claude Code の Routinesという機能を使う。定期実行の枠にプロンプトを1つ登録すると、その時刻に Claude が起動してリポジトリを調べ、勝手に PR を立てて帰っていく。

設定したもの

最初に登録したのはこれだけである。

リポジトリ内のドキュメント（README.md、docs/配下）を確認し、
実際のディレクトリ構成やファイル内容と矛盾している記述を探す。
矛盾があれば修正案のPRを作成する。
矛盾がなければ、確認した旨だけを報告して終了する。

/schedule から登録する。インフラは要らない。cron を書くサーバも、GitHub Actions の YAML も無い。

トリガーは最初は毎日9時にした。動くか見たかったからである。確認できてから毎週月曜9時に落とした。

動いたか

以下の数字は、筆者がこのサイトを作っている個人リポジトリでの実測である。

試すために、手順書にわざと嘘を2ヶ所仕込んだ。存在しないディレクトリと、存在しないビルドスクリプトである。

初回実行は9時3分に発火し、76秒・22ターンで完了した。

• 仕込んだ2ヶ所を両方とも検出
• 誤検出はゼロ
• 立った PR の内容が、嘘を仕込んだコミットの打ち消しと完全に一致

そのまま merge した。人間の作業は、差分を見て緑のボタンを押すだけだった。

（正直に書いておくと、この試し方は甘い。Claude は最初に git log を見ており、そこに「検証用の嘘を仕込む」というコミットメッセージが残っていた。**答えが見える状態のテストだった。**それでも独立に find で不在を確認しており、動くことは確かめられた。）

効いた一行

プロンプトの最後の一行が効いた。

矛盾がなければ、確認した旨だけを報告して終了する。

これを書かないと、Claude は「何か成果を出そう」として微妙な PR を立てがちになる。毎週動くものは、空振りしていいと明示しておかないとノイズ源になる。

対象範囲も同じ話になる。最初は README と docs/ 配下だけにしていた。あとから作業メモや計画ファイルも足したが、そのまま広げると毎週書き換わる部分に反応して PR が立つ。足すときは「実在するか」「実態と合っているか」といった検証できる事実の記述だけを見るよう指示を絞った。広げるなら、同時に見るものを絞る。

で、SEの実務ではどう使うか

刺さる先は README ではない。設計書と API 仕様書である。

プロジェクトが動き出すと、実装が先に進んで設計書が置いていかれる。パラメータが1つ増えた、エンドポイントの名前が変わった、必須項目が任意になった。**そのどれも、更新を忘れても誰も怒られない。**怒られるのは、それを信じて結合試験に来た別チームだ。

ここに毎週の見張りを1つ置くだけで、ずれが「発見」から「差分」に変わる。レビューする側は、月曜の朝に PR を1本見るだけでよくなる。

現実的な始め方は、対象を1つのディレクトリに絞ることだ。 API 仕様書とスキーマ定義の突き合わせだけ、といった具合に。範囲が狭いほど誤検出が減り、誤検出が減るほど PR を信用できる。逆に全ドキュメントを対象にすると、毎週の PR が読まれなくなって終わる。

もう一点。この Routine には外部連携を一切つけていない。 無人で動くので許可を求めるプロンプトが出ず、しかも読む対象であるリポジトリは誰でも書き換えられる。ドキュメントに指示文を仕込まれたときに、メールを送れる権限などが繋がっていたら実行されうる。最小権限がそのまま防御になる。

---

腐ったドキュメントは、直す価値が分かっていても手が回らないから腐る。**その手を機械にやらせて、判断だけ人間が持つ。**月曜の朝に PR が1本立っているのは、思っていたより気分がいい。