何が起きたか

Anthropic（Claudeを作るAI会社）は、Claude Codeチームのコード確認の方法を公式記事で説明した。記事は2026年10月15日付で、ClaudeがClaude Codeのコードの約90％を書くと紹介している。6月から9月にかけて、統合された変更案は2倍以上になった。一方、リバートになった割合は40％以上下がったという。Anthropicの大きな共有コードベースでは、1日の変更数が5月の約2500件から、9月には3万件超へ増えた。これらは同社が示した社内の数字で、外部監査の結果ではない。詳しくは公式記事で説明されている。

背景：人が読む量だけでは追いつかない

AIエージェントがコードを書くと、変更の数は急に増える。人が1行ずつ最後に読むだけでは、確認が終わらない。コードレビューには、出荷前に問題を見つける役割と、チームがコードの構造を理解する役割がある。Anthropicは、すべてを人が読んだかではなく、起こりそうな問題をどの確認で見つけるかを考えるようになった。レビューは最後の関門ではなく、書いている途中から続く確認へ変わった。

機械が先に調べる

プルリクエスト（PR、コードの変更案を確認してもらうための提出）を作る前に、Claudeへテスト、ビルド、画面の比較などを実行させる。別の作業役のAIが、新しい視点で差分を読む。PRができると、Claudeはリポジトリ全体と変更の目的を見て、バグや周囲への影響を探す。安全性の確認も別に走り、問題が開いたままなら統合できない。複数のAIが指摘を確かめ、十分に本物らしいものだけを人へ渡す。文体の好みや小さな整理は、主な指摘から外す。

人の判断を残す

変更はリスク階層で分けられる。文書の修正など低い変更は、自動確認が通れば人の承認なしで進められる場合がある。普通の変更は1人、危険な場所や影響の大きい変更は2人が見る。AIの承認は、人の承認の代わりにならない。人は、そもそも作るべきか、設計の方向はよいか、請求・更新機能・CIなど危険な場所に問題がないかを判断する。AIに変更を頼んだ人は、入力したのがAIでも結果に責任を持つ。

失敗を小さくする仕組み

統合前には、変更をまとめた状態でもう一度確認する。新しい機能は社内で先に試し、問題があれば機能を止めたり、前の版へ戻したりする。事故やリバートは、次の確認AIを試す材料になる。ただし、AI同士の確認は続きすぎることもある。あるPRは一晩で50回以上、修正と再確認を繰り返した。繰り返し指摘された部分の約59％は、最初の確認時から存在したコードだった。チームは3回を目安に区切り、その後は新しい差分を中心に見るようにした。

確認できたこと、まだ分からないこと

記事から確認できるのは、Anthropicが自動確認、人の承認、段階的な公開、すぐ戻せる仕組みを組み合わせていることだ。同社は、人の承認数や待ち時間、コメント数、リバートと事故の割合を見ている。まだ分からないのは、数字の細かな分母、事故の重さ、別の会社や小さなチームでも同じ結果が出るかだ。AIが読む量を増やしても、人がコードの意味を理解する方法が十分に保てるかも、これからの課題になる。

HNで話題になったことと、次に見る点

この記事はHacker Newsで472点、468コメントを集めた。掲載ページの数字は、コミュニティの注目度を示すものだ。元記事の正しさを証明する数字ではない。次に見るべきなのは、変更数が増えてもリバートや事故が増えないか、人の待ち時間が本当に減るか、低リスク変更の自動統合をどこまで広げられるかである。