INTERCREATE JAPANClaude Codeチームのコードレビュー公開｜AIが先に見て、人は危ない所だけ見る
INTERCREATE JAPAN 編集部公開 2026.10.18
この記事でわかること
- Anthropicが公開したコードレビューの考え方
- AIの確認と人の確認をどう分けているか
- 変更の危険度で人の確認を変える表
- 小さな会社で「AIの成果物の確認」に置き換える方法
- 公式に書かれていないこと
目次
Anthropicは2026年10月15日、Claude Codeの開発チームが日々行っているコードレビューのやり方を、公式ブログで公開しました。
題名は「How the Claude Code team does code review」で、筆者はAddy Osmani氏ら3名です。
ブログによると、Claude Codeのコードの約9割はClaude自身が書いています。
そのため「これだけの量の変更を、人はどう確かめているのか」という疑問が出ますが、記事はその答えを具体的に書いています。
開発者向けの話ですが、「AIが作ったものを、人がどこまで確かめるか」という問題は、資料づくりやWebサイトの更新を任せている会社にもそのまま当てはまります。
この記事では、公式の内容を整理したうえで、当社の解釈として、小さな会社でのあてはめ方を書きます。内容は2026年10月18日時点の情報です。
何が公開されたのか
公開されたのは、新機能の発表ではなく、Anthropic自身の運用の記録です。
ブログに書かれている数字のうち、要点は次の3つです。
- Anthropicの社内の大きなコード置き場では、1日に取り込まれる変更が、5月の約2,500件から9月には3万件を超えた
- Claude Codeのコード置き場では、6月から9月にかけて、取り込まれた変更（プルリクエスト）が2倍を超えた
- 同じ期間に、あとから取り消された変更の割合は4割以上減った
つまり「確認を減らして速くした」のではなく、確認の中身をAIと仕組みに移し、人の時間を減らしても、取り消しや事故は増えていないというのが公式の主張です。
これらはAnthropic自身の観測値で、第三者が検証した数字ではありません。
考え方：「人が読んだか」ではなく「何が起きうるか」
ブログは、コードレビューには2つの仕事があると整理しています。
ひとつは出荷前に問題を見つけて直すこと、もうひとつはチームにコードの理解を広げることです。
そのうえで、「人がコードを読んだか」という確認は、本来知りたいことの代用品にすぎないと述べています。
本当に知りたいのは「この変更で何が起こりうるか。それを止めるのに適した確認は、自動のものか人のものか」という点です。
この見方に変えたことで、レビューの時期も変わりました。
以前は、書き終えて提出してから同僚を待つ「最後の関所」でした。
いまは、書いている途中から続けて確認が走る形で、人に見てもらう前に、たいていの変更はClaudeが一度は確認して直しています。
公式が置いている目標
Claude Codeのコード置き場では、多くの変更が「人は最大1人（書いた本人でもよい）」で取り込まれることを目標にしています。
人の時間は、確認にかかる時間と、悪い変更が壊したものを直す時間の合計で数え、取り消しや事故の件数を歯止めの指標にしています。
AIの確認と人の確認の分け方
公式は、確認を一枚の関所ではなく、何層にも重ねた形で説明しています。
ひとつの層が見逃しても次の層が拾い、最後は取り消しで戻せるようにしている、という考え方です。
| 層 | 内容（公式の説明を当社で要約） |
|---|---|
| 1. 提出前の自己確認 | テストやビルド、画面の見比べなど「実行できる確認」をClaudeに渡し、結果を見せさせる。別のAI（サブエージェント）が、前提を持たない状態で差分を見直す |
| 2. 全件のAIレビュー | すべての変更にClaudeのレビューが付く。複数のAIが同時にバグを探し、別のAIたちが投票して、本物と判断されたものだけを投稿する |
| 3. 止められるセキュリティ確認 | バグ確認とセキュリティ確認の指摘が1つでも未解決なら取り込めない。直すか、理由を書いて閉じる |
| 4. 自動チェック | 書式の検査、型の検査、各環境でのテスト、ビルド。提出時に「どう確かめたか」「どう元に戻すか」も書く |
| 5. 危険度に応じた人の承認 | 変更の内容で、承認不要・1人・2人を分ける（次の見出しの表） |
| 6. 順番待ちと段階的な公開 | 取り込む前にもう一度全部の検査を通す。新機能は先に社内で使い、公開も段階的に行う |
さらに、最後の層として、問題が出たときにすぐ気づいて戻す仕組みがあります。
機能のスイッチは、作り直しなしで切れるようになっています。
事故のあとには「どの層が止めるべきだったか」を振り返ります。
AIのレビューについては、公式の中で次の点が目を引きます。
- 指摘はすべて返事が必要で、「直す」か「理由を書いて閉じる」のどちらかにする
- 文体や掃除だけの指摘は、投稿前に捨てる。実際に自分たちのレビューで比べてから採用した
- 指摘は「重要」「細かい点」「以前からあった問題」に分けて表示し、変更した人の責任に見えないようにする
Claude Codeのセキュリティ対策｜権限・サンドボックス・学習設定を解説Claude Codeは手元のファイルを書き換え、コマンドを実行できるため、使い方を決めずに導入すると誤操作や情報漏えいが心配です。標準の安全機能、権限モードと権限ルール、サンドボックス、データの扱いと学習設定、脆弱性やMCPへの備え、会社で決めるルールを公式情報でまとめました。変更の危険度で、人の確認を変える
人の承認は、書いた人の肩書きではなく、変更の中身で決めます。
公式の表を、当社で要約すると次のようになります。
| 危険度 | 例 | 人の承認 |
|---|---|---|
| 低い | 文書、文言、社内向けの機能、スイッチの裏に隠れた追加 | AIの確認とセキュリティ確認が通れば不要 |
| 中くらい | 通常の製品の変更、キャッシュや自動更新、AIへの指示文などの重要な部分 | 1人 |
| 高い | 最も危険なコードと、必ず2人が必要と決めた場所 | 2人 |
決め方にも工夫があります。
- 危険度は、変更を読む分類用のAIが判断する。さらに別の分類が「この変更だけは人が必要か」を確かめる
- 請求や自動更新、検査の設定ファイルなど、持ち主が重要と決めた場所は、常に人が必要
- 軽い手続きを使えるのは、信頼できる作者の一覧に載った人だけ。それ以外は2人目の承認が要る
- AIの承認は、人の承認の代わりにならない
- AIに指示して作らせた場合は、指示した人が「書いた人」と同じ責任を負う
- 承認は特定の1回の変更にだけ有効。あとから追加の変更が入れば、承認し直す
AIレビューを良くし続ける仕組み
公式は、AIレビュー自体の質を測り続けていることも書いています。
過去の事故を「試験問題」にしている点が特徴です。
事故につながった過去の変更と、その修正・取り消しを集め、詳しい技術者が「どのバグがどこにあったか」を確定させ、レビューのAIに毎日解かせています。
事故が増えるたびに問題集も増え、レビューの仕組みを変えるたびに、その全部で採点し直します。
もうひとつは、うるさすぎるレビューを避ける取り組みです。
指摘への反応（直した、間違いと言われた、意図どおりと言われた、どうでもよいとされた）を分類して、見当はずれな指摘の割合を数えています。
書き手がAIの場合は、細かい指摘にも修正と再確認が走るので、うるささのコストが人より大きくなります。
実際に、あるコマンドライン版の変更では、夜のあいだにレビューと修正が50回以上繰り返された例が挙げられています。
調べると、レビューが指摘し続けていたものの約59%は、最初の確認の時点からあったコードでした。
新しいバグを見つけていたのではなく、古い問題を毎回少しずつ見つけていたことになります。
そこで次のような変更をしています。
- 3回までで、書き手に「やり方を考え直す」よう促す
- 数回のあとは、新しく加わった差分だけを再確認する
- 同じ種類のバグは1行ごとでなく種類として指摘し、同種のものを全部直させる
- すでに投稿した指摘は繰り返さない
日本の小さな会社では、どう置き換えられるか
ここからは、公式の内容をもとにした当社の解釈です。
公式に書かれているのは、あくまでAnthropicの開発チームの運用です。
プログラムを書かない会社でも、AIに資料やWebページ、メールの下書きを作らせる場面は増えています。
そのとき、公式の考え方は次のように置き換えられます。
| 公式の考え方 | 小さな会社での置き換え例 |
|---|---|
| 実行できる確認を先に渡す | AIに資料を作らせるとき、「数字の出どころを一覧にして」「元データと合計が合うか自分で確かめて」と頼む |
| 別のAIが前提なしで見直す | 作ったAIとは別の会話で、完成物だけを渡し、誤りや抜けを探させる |
| 危険度で人の確認を変える | 社内メモは本人確認だけ、お客様への見積書や公開するWebページは担当者と責任者の2人、と先に決める |
| AIの承認は人の承認の代わりにならない | AIの「問題ありません」を、責任者の確認として扱わない |
| 指示した人が責任を負う | AIに作らせた資料も、依頼した人が内容に責任を持つ |
| 戻せるようにしておく | 公開前のページで確認し、更新前の版を残しておく |
プログラム開発の現場では、公式ブログが勧める準備のうち、次のものはすでに誰でも始められます。
- 短い指示ファイル（CLAUDE.md）に、プロジェクトの前提と守ることを書く
- 提出前に、ローカルで
/code-reviewや/security-reviewを実行する - 確認が必要な場所（認証・請求・公開手順など）は、必ず人の承認が要るように設定する
Claude Codeのauto modeとは？仕組み・設定方法・注意点を解説Claude Codeのauto mode（オートモード）は、確認の画面を減らし、危険な操作だけを別のモデルが止める権限モードです。ほかのモードとの違い、使える条件、切り替え方、止められたときの対処、設定、注意点を2026年10月時点の公式ドキュメントで解説します。注意点・まだ分からないこと
- 数字は、Anthropicが自社の運用で観測した値です。自社と同じ結果になるとは限りません
- 公式の中で、問題に気づくための歯止め（数字が悪化したら承認を厳しくする仕組み）は「まだない」と書かれています
- 公式はレビューの量を減らすことが目的ではなく、「人の時間を減らしても、取り消しを増やさない」ことが目標だと述べています。確認を飛ばしてよい、という話ではありません
- AI用のレビュー製品「Code Review for Claude Code」は、TeamとEnterpriseプランで一般提供されていると書かれています。料金や日本での提供条件は、確認したブログには書かれていません（未確認）
公式に書かれていないこと（未確認）
非エンジニア向けの業務（資料や文章）にこの仕組みをそのまま使えるかは、公式には書かれていません。
前の見出しの置き換えは、当社の解釈です。まずは影響の小さい作業で試し、効果を自社で確かめてください。
まとめ
この記事のまとめ
- Anthropicは2026年10月15日、Claude Codeチームのコードレビューのやり方を公式ブログで公開した
- 多くの確認をAIと自動チェックに移し、人は危険な変更とAIが苦手な判断に集中している
- 人の承認は、書いた人ではなく変更の危険度で決め、AIの承認は人の承認の代わりにしない
- 公式の数字では、6月から9月に変更が2倍超になり、取り消しの割合は4割以上減った（Anthropic自身の観測値）
- 小さな会社では「別のAIで見直す」「危険度で確認者を変える」「依頼した人が責任を持つ」が参考になる
AIに任せる範囲が広がるほど、「誰が何を確かめるか」を先に決めておくことが大切になります。
まずは、影響の小さい作業から確認の手順を決めて試してみてください。
INTERCREATE JAPANでは、AIを仕事で使うときの確認ルールづくりや、業務へのあてはめ方の相談を受けています。
参考・出典
