「AI に書かせたコードを、人が全部は読めない。何で確かめればいいのだろう」。
Claude Code を作る Anthropic の開発チームが10月15日、コードレビュー（書いたプログラムを読んで誤りを探すこと）の進め方を公開しました。Claude Code 自身のコードの約9割を AI が書くなかで、読む作業の大半を AI に任せた内容です。
確かめる人が1〜2人の会社でも、AI が直したプログラムを使い始める前に AI のレビュー（/code-review）を深さ medium で1回かけ、人が必ず見る部分を決めるところから真似られます。i-Style の過去の不具合3件で試すと、medium は3件とも見つけ、浅い low では1件も見つかりませんでした。
先にまとめ
Claude Code の開発チームは、人が読んだかどうかを安全の目安にするのをやめ、この変更で何が壊れうるか、それをどの確認で止めるかを先に考えています。確認を6段重ね（うち1段は人の承認）にし、それでも見逃した変更はすぐ元に戻せるようにしたうえで、承認する人の数を危険度に応じて0〜2人に変えました。
Anthropic によると、6月から9月にかけて、Claude Code に反映した変更の数は2倍を超え、反映したあとに取り消すことになった変更の割合は4割以上小さくなりました。どちらも Anthropic が自社で測った数字です。
i-Style の過去の不具合3件（後で別の点検で見つかり、直したもの）を、直した記録を見せない状態で、Claude Code に付いているレビュー用のコマンド /code-review に読ませました。調べる深さを medium にした回は3件とも見つけ（1回46〜89秒）、浅い low にした回は3件とも見逃しました。ほかに22件の指摘も出ましたが、今も残っていてすぐ直す必要のあるものはありませんでした。
確かめる人が足りない会社なら、AI を使う社員が使い始める前に medium を1回かけることと、お金・ログイン・お客様の情報に触れる部分は、外注先などプログラムを読める人が必ず見ると決めることから始められます。経営者が担うのは、そもそも作るべきかの判断です。
Claude Code の開発チームは、人が全部を読むのをやめ、人の手間と取り消しの割合を測っている
AI がコードを書くようになると、プログラムへの直し（変更）の数が一気に増えます。Anthropic の社内で多くのプログラムをまとめて置いているリポジトリ（プログラムの保管場所）では、1日に反映される（本番用のプログラムに組み込まれる）変更が、5月の約2,500件から9月には3万件を超えました。
Claude Code のプログラムでも、同じように変更が増えています。この速さでは人が1行ずつ読むのはほぼ無理だ、と開発チームは公開した記事（以下、元の記事）に書いています。
そこで開発チームは、人がコードを読んだかどうかで安全かを測るのをやめました。代わりに考えるのは2つです。この変更で何が壊れうるか。それを止めるのは、自動の確認（AI や検査用のプログラムが毎回する点検。次の章の表）と人のどちらが向いているか、です。
確かめる時期も変えました。以前は、書き終えて PR（プルリクエスト。変更を反映する前に、確認を頼む申請）を出してから、同僚が見るのを待っていました。いまは、書いている途中から AI が確かめ続けます。元の記事では、これを書きながらかけるスペルチェックにたとえています。
目標は、Claude Code という製品を直す PR の大半を、人の確認は多くても1人で反映できるようにすることです。その1人は、変更を出した本人（AI に書かせた場合は、指示した人）でもかまいません。その前に、AI や自動の検査が何段も確かめる前提です。
条件は、取り消し（反映した変更を元に戻すこと）や障害（システムが止まったり、正しく動かなくなったりすること）を増やさないことです。測っているのは、PR 1件あたりの人の承認の数、人がレビューで書き込んだ指摘の数、PR が人を待っている時間です。あわせて、取り消しや障害の割合が増えていないかも見ています。
確認の手間を減らした結果、あとで直す手間が増えていたら、人の手間は減っていないと考えるためです。自社に関係があるかどうかは、AI にコードを書かせているかどうかで分かれます。書かせているなら、確かめる人が少ない会社ほど関係のある話です。
マメ
うちは社員12人の工務店で、見積りの社内システムを、外注のエンジニア1人と、Claude Code を使う社員1人で直しています。確かめる人はその2人だけです。この人数でも真似られますか。
ホク
真似られます。開発チームの目標も、人の確認は多くても1人です。人を増やせないぶん、人が見る前に、AI に動かして試させる、別の AI に読ませる、といった確認を重ねます。
マメ
人が見る前の確認は、Claude Code を使っている社員1人でも始められますか。
ホク
始められます。まず社員が、AI の「できました」で済ませず、実際に動かして試した結果や、直したあとの画面を AI に出させて見ます。そのあとで、新しい会話で開いた AI に、変えた部分を読ませます。
変更は6段の確認にかけ、すり抜けた不具合は取り消して戻す。人の承認の人数は危険度で決める
変更が使う人に届くまでに通す確認を、開発チームは6段に重ねています（5段目が人の承認）。どの段も不具合の一部を止め、一部は通してしまいます。全部の段をすり抜ける不具合は少なく、すり抜けたときは最後の備えとして、その変更をすぐ取り消す、という考え方です。
少人数の会社が真似しやすいのは、このうち1段目と2段目です。表は、元の記事の説明を i-Style が短くまとめたものです。
| 段 | していること |
|---|---|
| 1 反映前の確認 | AI に、テスト（決めたとおりに動くかを自動で試す仕組み）・ビルド（プログラムを動く形にまとめる作業）・完成見本（デザイン）と実際の画面の見比べをさせ、結果を見せてもらう。そのあと、書いたときの会話を引き継いでいない別の AI が、変えた部分を読む |
| 2 AI のレビュー | すべての PR に、人より先に AI（Claude）のレビューが付く。何体もの AI が不具合を探し、別の AI たちが1件ずつ投票して、本物と認める票が十分に集まった指摘だけを残す。動きには影響しない、書き方の好みだけの指摘は残さない |
| 3 セキュリティの確認 | セキュリティ上の問題を自動で探す。未解決の指摘が1つでもあると反映できない |
| 4 自動の検査 | 書き方の決まり・型（データの種類の取り違え）の検査、すべての環境でのテスト、ビルドを、検査用のプログラムが PR ごとに回す。通らなければ反映できない。PR を出す人には、決まった書式で、どう試したかと、問題が出たらどう戻すかを書いてもらう |
| 5 人の承認 | 変更の危険度で、承認する人数を0〜2人に変える |
| 6 直前の再検査と段階的な公開 | 反映の直前に全部の検査をもう一度回す。新しい機能はまず社内の社員に使わせ、一般の利用者にも、先に試したい人向けの版から順に広げる |
| 最後の備え すぐ戻す | 機能ごとのオン・オフの切り替えで、プログラムを入れ替え直さずに、その機能だけを止める。障害に対応する当番を週替わりで決め、振り返りでは、どの段で止めるべきだったかを問う |
2段目の AI のレビューは、その試験版を公開した前後で比べると、社内の PR のうち中身のある指摘が付く割合が16%から54%に上がったそうです。1,000行を超える大きな PR の多くには指摘が付き、小さな PR の多くは「問題なし」で返ってきます。
5段目の人の承認は、変更の危険度で人数を変えます。ドキュメントや文言の直し、社内だけの機能のような危険度の低い変更は、AI のレビューとセキュリティの確認が通れば、人の承認は要りません。ふつうの製品の変更や、アプリが自分で新しい版に入れ替わる仕組み（自動更新）のような注意の要る部分は1人です。いちばん危ないコードと、必ず2人が見ると決めた一部の場所は2人です。
危険度は、変更の中身で決めます。ただし、承認なしで通せるのは、危険度が低く、しかもそのリポジトリを受け持つチームなど、信頼された書き手が出した変更だけです。それ以外の人の変更は、危険度が低くても、もう1人の承認が要ります。自動の検査の決まりを書いたファイルのように、危険度によらず人が見る部分も決めてあります。
AI の承認は、人の承認に数えません。AI に書かせた変更では、その AI に指示した人が、確認する人の1人に数えられます（自社で真似るときの扱いは後の章で書きます）。AI に書かせて AI にレビューさせる形には、もう1つ決めごとが要りました。レビューを何回まで回すかです。
AI どうしのレビューは回すほど終わらなくなる。3回で立ち止まる決まりにした
AI が書き、AI がレビューする形には、終わらなくなる落とし穴があります。Claude Code の PR の1つでは、書く AI とレビューする AI のやり取りが一晩で50回を超え、PR を出した人が止めるまで続きました。
開発チームが、レビューがくり返し指摘していた箇所を調べると、約59%は、1回目のレビューの時点からあったコードでした。元の記事は、レビューは直しで新しく生まれた不具合をほとんど見つけておらず、もとからあった不具合を回すたびに少しずつ見つけていた、とまとめています。
やり取りが終わらなくなった一因は、どの PR でもレビューを何度も回すのが、チームの当たり前になっていたことです。危ない変更なら何度も回す意味がありますが、全部の PR に要るわけではありませんでした。
そこで、直したあとにかけ直すレビューのやり方を、4つの点で変えました。1つ目は、3回かけても指摘が出続けたら、レビューする AI が書いた側に、直し方の方針から見直すよう促すこと。2つ目は、最初の数回のあとは新しく変えた部分だけを見ることです。
3つ目は、1行ずつではなく不具合の種類で指摘し、同じ種類をまとめて直させること。4つ目は、一度出した指摘をくり返さないことです。
元の記事のグラフでは、変えたあと、1回のレビューと直しで指摘が無くなる PR が65%から78%に増え、5回以上かかる PR は8.9%から1.5%に減りました。指摘が無くなるまでの平均の回数は、2.08回から1.32回になっています。
元の記事は、指摘が多すぎることの害は、書くのが AI のときほど大きいとも書いています。人なら細かい指摘はすぐ流せますが、AI は直そうとして変更を足し、そのたびにレビューが1回増えるためです。
もとからあった不具合を1回目で見つけられれば、回す回数そのものが減ります。そこで、1回のレビューで AI にどこまで調べさせるか（深さ）を変えると、見つかるかどうかが変わるかを、i-Style の手元で確かめました。
i-Style の過去の不具合3件で /code-review を試すと、medium は3件とも見つけ、low は0件
開発チームは、過去に障害を起こした変更を集めておき、レビューする AI がそれを見つけられるかを毎日試して、AI のレビューの出来を採点しています。i-Style では、これを小さく真似ました。自社で作っている仕組みから、不具合が入り込んだ変更を3件選び、その変更を Claude Code の /code-review に読ませました。どれも後で別の点検で見つかり、直したものです。
/code-review は、Claude Code の中で打つレビュー用のコマンド（命令）で、Claude のどの料金プランでも使えます。レビューの深さは effort という設定で、浅い順に low・medium・high・xhigh・max から選び、/code-review medium のようにコマンドのすぐ後ろに付けて打ちます。公式ドキュメントによると、low は自信のある指摘だけに絞って誤った指摘を減らし、medium から max までは調べる範囲を広げます。
試したのは10月27日の朝です（Claude Code は 2.1.311 版、中で動く AI は初期設定のままの Claude Opus 5.5）。まず、リポジトリのコピーを用意し、不具合が入り込んだ直後の状態まで巻き戻しました。後で直した記録はコピーから消し、AI にはその1件の変更だけを見せています。答えを知らない状態で、後で見つかった不具合に気づけるかを見るためです。
A は、記事の下書きを自動で作る仕組みの不具合です。下書きを作ったあと、完了の連絡に失敗してやり直す間に、テーマの予定表が次のテーマへ進むと、やり直しの回が新しいテーマで依頼を作り直し、前の依頼と食い違って止まる作りでした。反映する前の点検で見つかり、同じ日に直しています。
B は、お客様のブログにも入れている管理画面の不具合です。カテゴリ（記事の分類）の名前を変えると、ふつうは公開中の記事にも新しい名前が付きます。ところが、公開後に開いて保存した記事は、管理画面の中で下書き扱いに戻っていたため、公開し直すまで名前の変更から漏れ、サイトに古い名前が残りました。4日後に直しています。
C は、同じ管理画面の、記事のアドレス（URL）の不具合です。「3つのコツ」のような日本語の題名から「3」だけの短いアドレスができるのを防ぐ仕組みを足しました。ところが、管理画面は保存のたびに自分でアドレスを決めて一緒に送っていたため、足した仕組みが使われず、画面から作った記事には効いていませんでした。20日後に直しています。
3件とも、変えた箇所だけを見ると正しく見え、ほかのファイルと合わせて読んで初めて分かる不具合です。結果は次の表のとおりで、「9件中3番目」は、AI が出した指摘9件のうち、答え合わせに使った不具合が上から3番目にあったという意味です。2回目は、同じ結果がくり返されるかを見るために A と C だけで回しました。
| 答え合わせの不具合 | medium 1回目 | medium 2回目 | low |
|---|---|---|---|
| A 下書きの自動作成 | 見つけた（9件中3番目・52秒） | 見つけた（9件中1番目・52秒） | 見逃した（指摘0件・17秒） |
| B カテゴリ名の変更 | 見つけた（10件中1番目・89秒） | 回していない | 見逃した（指摘0件・21秒） |
| C 記事のアドレス | 見つけた（6件中1番目・57秒） | 見つけた（6件中1番目・46秒） | 見逃した（指摘0件・17秒） |
AI は調べる途中で、ファイルを開くなどのコマンドを自分で打ちます。low が見逃した理由は、その記録を見ると分かります。low の AI は、差分（変えた部分）を1回表示しただけで判断していました。medium の AI は、差分を見たあとに関係するほかのファイルを開いて読み比べ、コマンドは合わせて3〜8回でした。
B の low の回は、差分の範囲で確かめられる不具合は無く、ほかのファイルを開く確認はこの深さではしていない、と自分で範囲を書いて返していました。low の「問題なし」は、変えた部分の中に限った「問題なし」です。
medium は、1回目の3件と2回目の2件、合わせて5回とも、答え合わせに使った不具合を指摘に含めていました。B では、変えた部分とは別のファイルまで読み、公開中の記事を編集すると状態が下書きに戻る作りを見つけて、古い名前が残る理由として示しています。
費用は、使った分だけ払う契約だった場合の値段（Claude Code の表示）で、medium が1回0.26〜0.64ドル、low が0.21〜0.27ドルでした。1ドル150円で計算すると、medium は1回約40〜100円です。i-Style は定額のプランで使っているので追加の請求はなく、プランで使える量の中から使いました。
試せなかったこともあります。セキュリティの確認（/security-review）と、medium より深い段階（high から max）は試していません。また、3件はどれも別の点検で見つかった不具合です（A は反映する前に Codex〈OpenAI のプログラム用の AI〉に読ませた確認と読み直し、B と C は9月2日に AI に分担させた総点検）。AI が見つけやすい種類に偏っている可能性があり、誰も気づかないまま残っている種類の不具合を見つけられるかは、今回の結果からは分かりません。
medium は、答え合わせに使った不具合のほかにも指摘を出していました。その中身を次に分けます。
答え合わせの3件のほかに出た指摘22件のうち、今も残っていてすぐ直すべき不具合は0件
medium の1回目は、答え合わせに使った3件のほかに22件を指摘しました（A が8件、B が9件、C が5件）。開発チームは、指摘を受けた担当者がどう扱ったか（直した・違うと言った・わざとだと説明した・気にしないことにした）で当たり外れを数えています。
i-Style では、別の AI に今のコードと、その後の直しの記録を読み比べさせ、根拠のファイルと行を付けて振り分けさせました。そのうち3件（当たらなかった1件と、後で直していた2件）は、記事を書く側でも根拠のファイルを開いて確かめました。残りの19件は、振り分けた AI の判定のままです。
| 分け方 | 件数 | 中身の例 |
|---|---|---|
| 後で直していた | 3件（うち1件は答え合わせの不具合の言い直し） | ドキュメントの記述の誤り、同じ不具合が再び起きないかを確かめるテストが無い |
| 今も残るが、起きる条件が限られるか害が小さい | 11件 | GitHub（プログラムの保管サービス）への書き込みが失敗し、しかも記事ごとの表示名がもともとカテゴリ名と違っていたときにだけ、その表示名がカテゴリ名で上書きされる |
| 当たらない | 1件 | お客様ごとの識別名に危ない記号が入りうるという指摘。実際は受け付けの段階で使える文字を絞っていて入らない |
| 動きの誤りではない提案 | 7件 | テストの重複、プログラムの中に書いた説明のメモと実際の動きのずれ、書き方の整理 |
| 今も残っていて、すぐ直すべき | 0件 | なし |
条件が限られる11件のうち2件には、起きる回数によっては直すべき不具合になりうる、と振り分けた AI が但し書きを付けました。この2件は、記事を書いた時点ではまだ直していません。
答え合わせの不具合1件に対して、別の指摘が5〜9件付いた計算です。全部を同じ重さで直していたら、担当が1人の会社はそれだけで手が止まります。開発チームも、すべての指摘に、直すか、直さない理由を書き残して片づけるかのどちらかで答えています。
指摘が多いときは、プログラムの動きがおかしくなるもののうち、起きたときの害が大きいものから直し、書き方の提案は直さない理由を1行書き残して片づける、という分け方が現実的です。どれを直すかは、プログラムを読める担当（外注先を含む）が決めます。
社員1〜数人で AI にプログラムを直させている会社が真似るなら、使う前の medium のレビュー、人が見る部分の線引き、すぐ戻せる準備の3つから
真似るなら、次の3つをこの順に進めるのがよいと i-Style は見ています。1つ目は、AI が直したプログラムを使い始める前の2つの確認です。まず AI に、「できました」ではなくテストの結果や画面を見せてもらい、次に /code-review medium を1回かけます。どちらも、AI を使っている社員が自分でできます。
試した結果の画面とレビューの結果を、使い始める前に見せてもらう決まりにしておくと、経営者も確かめられます。月額の定額のプランなら追加の費用はかからず、使った分だけ払う API（プログラムから AI を使う窓口）の契約なら、今回の例で1回約40〜100円の利用料です。PR という確認の申請を使っていなくても、そのまま使えます。
かけ直す回数も決めておきます。開発チームは、3回かけても指摘が出続けたら、直し方の方針から見直す決まりです。少人数の会社なら、3回で終わらなければ社員は AI に直させ続けるのをやめ、外注先などプログラムを読める人に相談する、と決めておけます。
2つ目は、人が必ず見る部分を決めることです。開発チームは、そもそも作るべきかの判断、課金や自動更新のような注意の要る部分のレビュー、あとから足す機能が真似する基本の部分の設計を人に残しています。確認の結果を読むことと、出したものへの責任も人の役目です。
社員が数人の会社なら、お金の計算（見積り・請求・支払い）・ログイン・お客様の情報に触れる部分は人が必ず見る、と決めるところからで足ります。AI に指示した社員がプログラムを読めないなら、その社員の確認は数に入れず、その部分の変更だけは外注先など読める人に見てもらいます。プログラムを読めない経営者が担えるのは、そもそも作るべきかの判断です。
3つ目は、問題が出たらすぐ前の状態に戻せるようにしておくことです。おかしくなったらどの操作で前の状態に戻すかを、開発を担当する社員や外注先に手順として書いてもらいます。起きた不具合は、担当の社員が、いつ・何が起きて・どう直したかを一覧に控えます。控えた不具合は、今回のように、レビューする AI がそれを見つけられるかを後で試す材料になります。
i-Style の場合、開発者が1人なので PR は作らず、直したものをそのまま本番用のプログラムに反映しています。人の確認は、指示した本人の1人です。そのうえで、複数のファイルにまたがる変更や、外部のサービスとの連携・ログイン・課金に関わる変更は、反映する前に Codex にも見せる決まりにしています。
これは表の1段目の、別の AI に読ませる確認にあたります。別の会社の AI でなくても、同じ Claude Code を新しい会話で開いて読ませれば同じ形になります。
手元で打つ /code-review とは別に、名前は似ていますが別物の Code Review という機能もあります。GitHub に出した PR に、AI が自動でレビューを付けるもので、Claude の会社向けの契約（Team・Enterprise）で使えます。費用は1回いくらの定額ではなく、変更の大きさなどに応じて、プランの利用枠とは別に払います。管理者が月の上限を決められますが、1回あたりの目安の金額は公式ドキュメントに無く（10月27日に確認）、i-Style は Team の契約ではないため試していません。
まとめ：人が全部を読む代わりに、変えた部分の外まで読む AI のレビューを1回かけ、人が見る部分を決める
Claude Code 開発チームのコードレビューは、人が全部を読むのをやめ、AI のレビューや自動の検査を含む確認を6段重ねて、人は危ない変更と結果への責任に時間を使います。確認を減らしすぎていないかは、取り消しと障害の割合で見張り、AI どうしのレビューは3回で立ち止まります。
冒頭の「AI に書かせたコードを、人が全部は読めない。何で確かめればいいのだろう」への答えは、AI を使う社員が、使い始める前にほかのファイルまで読む AI のレビュー（medium）を1回かけることです。そのうえで、お金・ログイン・お客様の情報に触れる部分は、外注先などプログラムを読める人が必ず見ると決めておきます。経営者は、そもそも作るべきかを決めます。
i-Style の過去の不具合3件では、medium は3件とも見つけ、low は1件も見つけられませんでした。すぐ前の状態に戻せる手順を書いておき、起きた不具合を記録しておけば、開発を担当する人や外注先に頼んで、自社でも medium で足りるかを試してもらえます。
確かめた資料
進め方と数字は、claude.dev ブログの元の記事「How the Claude Code team does code review」（2026年10月15日、Addy Osmani 氏ほか2名）で確かめ、図の中の数字も読みました。元の記事の書き手の1人である Osmani 氏は、同じ内容を書き直して X に載せています（2026年10月26日）。
Code Review の対象の契約と費用は公式ドキュメントの「Code Review」と「Code Review costs and usage」、/code-review の深さと打ち方は「Review locally with /code-review」で確かめました（いずれも10月27日）。
実際に試したのは、自社の過去の不具合3件に /code-review の low と medium をかけたことだけです（medium は A と C で2回目も実施）。
i-Styleに相談する
i-Style の AI 活用支援サービス「まるっとAI」では、AI にプログラムを書かせるときの確認の仕組みづくりもお手伝いできます。始める前に手をつけやすい準備は次の2つです。1つは、社内のシステムのうち、お金・ログイン・お客様の情報を扱う画面や機能を、担当の社員や外注先と一緒に書き出し、人が必ず見る部分として決めること。もう1つは、これまでに起きた不具合を、いつ・何が起きて・どう直したかの一覧にしておくことです。
お問い合わせページへ arrow_forward相談するほどでもなければ、右下のチャット窓口で「うちの体制だと何から始めるか」を聞くところからでも十分です。