sqlite-utilsの作者Simon Willisonは、メジャーバージョン(4.0rc2)のリリース前レビューをClaude Fableに依頼した。かかった実額は$149.25。自分では気づいていなかった破壊的変更が5件見つかったという。「自分のコードを、自分以外の目でもう一度読む」を、AIにやらせる話。
メジャーリリース前のセルフレビューをAIに任せるという具体的なユースケースと、なぜこの使い方が「自分のコードだからこそ」効くのかの理由。そして今日から真似できるチェックリスト。
sqlite-utilsは、SQLiteデータベースをコマンドラインやPythonから操作するためのSimon Willison作のOSSツールだ。長く使われてきたプロダクトのメジャーバージョンアップ——つまり後方互換を崩す可能性が最も高いタイミングで、彼はリリース前レビューをClaude Fableに依頼した。
結果として、実額$149.25のコストで、本人が把握していなかった破壊的変更が5件見つかったという。書いたのは自分自身だ。何が変わったかは頭では分かっているつもりでも、「利用者から見てどこが壊れるか」という視点は、書いた本人ほど見えにくくなる。
「このAPIをこう変えた」という意図は書いた本人が一番よく分かっている。だが「この変更で、どの呼び出し方をしている既存ユーザーが壊れるか」という影響範囲は、意図とは別のスキルが要る。ここで見落としが起きやすい。
本人は無意識に「ここは前から動いているから大丈夫」というバイアスを持って読んでしまう。AIレビューには開発の経緯にまつわる思い入れがなく、今のコードが今のインターフェースとして何を約束しているかだけをフラットに見る。
ここが核心。AIコードレビューは「自分より賢い指摘」を期待するものではなく、自分が持っているバイアスを持っていない第三の目として使うと最も効く。特にメジャーリリースのような「後方互換」が焦点になる作業は、この性質と相性がいい。
大掛かりな体制を組まなくても、この使い方自体は今日から真似できる。
普段のコードレビューをすべてAIに置き換える必要はない。むしろ「年に数回のメジャーリリース前」のような、見落としのコストが特に高い局面にピンポイントで使う方が、コストに対する効果が大きい。
出典: Simon Willison's Weblog — sqlite-utils 4.0rc2, mostly written by Claude Fable
ここまではSimon Willisonの事例だった。そこで2026年7月17日、ローカルの実運用コード top/feed_util.py を対象に、同じファイルと同じ評価軸（正しさ、境界条件、冪等性、パス/文字コード、失敗時挙動、テスト不足）で独立したレビュー記録A/Bを作った。
article.html がないときのHTML選択順が明示されていない、という運用上の曖昧さが出た。rebuild() とCLI通常経路で、sitemap/robots更新の範囲が異なる点が出た。再現できた指摘は1件。 2026-9-30 と 2026-10-01 を区切り文字だけ統一して文字列降順にすると、9月30日が10月1日より新しい扱いになる。最小テストでこの順序逆転を確認した。
再現できなかった、または仕様上の指摘に留めたもの。 HTMLエスケープと noindex 除外は期待どおり動作した。HTMLファイルの選択順とCLI経路の更新範囲はソース上の注意点だが、今回の実データで表示事故までは確認していない。
この実験の結論。レビューの指摘数をそのまま信じるのではなく、境界値を作って再現できたものだけを採用する。今回は一致した指摘1件が検証済みで、残りは仕様確認またはテスト不足として記録した。本番コードの修正は行っていない。
実験記録: 計画 / レビューA / レビューB / 検証結果。A/Bは同一入力から観点を分けた記録であり、別々の実行主体による独立レビューとは保証しない。