Claude Code を作った Boris Cherny 氏が、開発者からのメールに答える形で X に投稿していました (Simon Willison 氏の紹介が分かりやすいです)。AI の書いたコードを blackbox として使うか、人が確認してから使うか、という問いへの答えは “I think there is room for both.” でした。Cherny 氏によれば、使い捨てで壊れても影響の小さいものは blackbox でよく、本番コードには人が書く場合より高い基準を課すべきで、それを保つのが使い手の仕事だそうです。”Your job is to hold the bar on code quality.” と書いています。
rail も AI 製
続きには、本番コードを守る guard rail として Anthropic 社内で置いているものが並んでいます。lint とテストを大量に置くこと、Claude による end-to-end テスト、Claude 製の fuzzer を毎日走らせること、自動コードレビューと security review、自動リファクタリングです。基準に届かない時の対処も列挙されていて、最新のモデルを使う、effort を上げる、CLAUDE.md と skills を整備する、Claude に技術的負債を直させる、と続き、最後は “Or, wait for the next model.” で終わります。
読んで思ったのは、どちらにしても AI の出力をそのまま使っていて、rail の方も AI 製だ、ということです。AI が書き、AI が守る。人が持っているのは、どの rail を置くかと、基準の高さだけです。
私も読んでいない
手元を見ると同じでした。うちで動いている rail は、実装文脈を渡さない reviewer の agent 定義、「却下には、原文またはコードの引用を必須とする」という規則、tool 実行前に警告する hook、各 skill、運用規則の memory です。全部 AI の筆です。読んで感心した規則はありますが、効いているかを確かめたものはありません。
それでいいのか、は別として、少なくとも困ってはいないので是認しています。確かめる cost が結構高い、要は面倒くさいのです。
動くのは、明らかに困った時と、ふと表に出た物が目について「思ってたんと違う」となった時です。その時は「どうなってるんだこれ?」と問います。それ以上ではありません。外に出て行く物には目を通しますが、rail に対して私がしているのは、そこに現れた物への反応だけです。bar を持つというのは、rail を読むことではありませんでした。
基準を上げるのが安い
Cherny 氏は本番コードには人が書く場合より高い基準を課す、と言っています。理由は、rail が無いと後で保守しにくい混乱になる、と短く触れているだけです。誤りが見つけにくくなるから、と言えばそれらしいですが、私の理由はもっと単純で、基準を高くする cost が低いからです。テストも fuzzer もレビューも AI が書くので、ただではないにせよ、人がやるより遥かに安く上げられます。そう真剣に検証せずとも、これは言えると思います。
見つからない誤りは、誤りとして扱えない
誤りは見つけにくくなるかもしれません。ただ、見つからない誤りは、あるかどうか分かりません。見つからないうちは誤りとして扱えないし、扱いません。不可知論です。何か哲学的な話になってしまいました。
ここから先は、うちの AI が継いだ一段です。私の言葉ではありませんが、なるほどとは思うので、そのまま載せます。
「困っていない」は、rail が効いている時と、誤りが黙っている時とで同じに見える。だから不可知論は開き直りではなく、拾い漏れは測れないという話の裏面で、それを許せる範囲を影響の大きさで区切る、という態度になる。元に戻せる所、たいていは間違っても影響の小さい所では許し、本番と外に出る物では、rail ではなく出て行く物の方を見る。Cherny 氏の線引き (使い捨ては blackbox、本番は高い基準) も、同じく影響の大きさで引いている。
(本文は私の言葉をもとに AI が下書きし、最後の引用は AI のものです。文責は私にあります)