VibeCodingのコードレビューを誰が担うのか——AIを「審査者」に使うコード品質管理の実践

VibeCodingのコードレビューが問われる時代——「確認の問い」が残っている

2026年現在、AI駆動開発（VibeCoding）は企業の開発現場に急速に浸透しています。Claude CodeやGitHub Copilotを日常的に使うエンジニアは珍しくなくなりました。「AIに書かせてからレビューする」が標準ワークフローになりつつある組織も出てきています（VibeCodingとは何かも参照）。

この変化は歓迎すべきことです。私たちAI-Pathも、お客様との現場でVibeCodingを使って1日でプロトタイプを作り、それを叩き台にして議論する進め方を取ってきました。従来の「要件定義→設計→実装→テスト」という直線的なプロセスとは異なります。動くものを見ながら要件を固めていくこの方法論は、特に業務システム開発で大きな威力を発揮します。

ところが、速度が上がるほど新しい問いが明確になってきます。

「AIが書いたこのコードは、本当に意図通りに動くのか」「セキュリティ的に問題はないか」「半年後にメンテナンスする人間が理解できるコードになっているか」——これらの問いに答える仕組みを持たないまま、速さだけが先行している組織が多いのが実態です。

私たちが製造業や中堅企業の開発チームと一緒に作業するとき、この問いに対して「AIが書いたコードなんだから、しっかり読めばいい」という答えが返ってくることがあります。正論ですが、現実的ではありません。AIがVibeCodingで生成するコードの量は、人間が書く場合の数倍から数十倍に上ります。全部を丁寧に読んでいたら、速さで得たものを確認で失います。

AIが書いたコードには、人間が書いたコードと異なる「死角」がある

人間のエンジニアがコードを書く場合と、AIがコードを書く場合とでは、エラーのパターンが異なります。この違いを理解していないと、確認の仕組みを設計できません。

人間が書くコードのエラーは、疲労・知識不足・思い込みから生まれることが多く、比較的局所的です。「あの関数の引数を間違えた」「境界値の条件を間違えた」のような形で現れます。

AIが書くコードのエラーは、別の構造を持っています。局所的なミスは少ないですが、「全体として正しく見えるが、業務ルールを微妙に外れている」「一般的には正しい実装だが、このシステムの前提条件を満たしていない」というパターンが多い。つまり、コードを読んで構文的に正しいかどうかではなく、業務文脈に照らして正しいかどうかという確認が重要になります。

もうひとつ厄介なのは、AIが書くコードは「それっぽい」という点です。読みやすく、コメントも整い、変数名も適切です。人間が書いた汚いコードよりも、一見して品質が高く見えることがある。だから、表面上の読みやすさに引っ張られて、業務ロジックの問題を見落とすリスクがあります。

私たちが携わった化粧品メーカーの生産計画システムのケースでは、AIが生成した在庫計算のロジックが、一般的な在庫管理の考え方としては正しいにもかかわらず、そのメーカー固有の「臨機応変な修正が必要」という現場ルールを組み込めていませんでした。コードを読むだけでは分からない——現場に入らないと見つけられない問題でした。

「高性能モデルを実装者に使う」のは、実は最もコストのかかる使い方かもしれない

ここからが本論の核心です。

VibeCodingが普及するにつれ、コストに関する議論が始まっています。Claude Fable 5のようなトップ性能モデルは、Opus 4.8と比べてトークン単価が約2倍とされています。「賢いモデルほど高い」という構造はこれからも続くでしょう。

この状況で、多くのチームが直感的に取る行動は「普段は安いモデルを使い、重要なときだけ高性能モデルを使う」です。しかしここに盲点があります。「重要なとき」の定義が曖昧なまま、高性能モデルを実装の全工程に使い続けてしまうケースが少なくありません。

実際の現場での観察からいうと、高性能モデルが最も力を発揮するのは「実装」ではなく「審査」の局面です。

実装（コードを書く工程）では、中程度のモデルでも十分な品質のコードが生成できます。問題は、そのコードが業務要件を満たしているか、セキュリティ的な問題がないか、テストが十分かどうかです。この「審査」の工程こそ、高い判断能力が求められます。

Fable 5の実機評価を行ったエンジニアが報告しているのもこの点です。個人で自動売買システムを開発する中でFable 5を試したところ、実装そのものへの貢献は中程度のモデルと大差なかった一方、実装側のモデルが見逃したバグを、審査局面ではFable 5が検出したという結果が得られています。実装コストではなく、審査コストに高性能モデルを投入する方が費用対効果が高いという判断に至ったとされています。

「実装者」と「審査者」を分けると、開発フローはどう変わるのか

この考え方を組織の開発フローに組み込むと、具体的にどう変わるでしょうか。

従来のVibeCodingフローはシンプルです。「AIに指示を出す → コードが生成される → 人間がざっくり確認する → マージ」。問題は「ざっくり確認」の部分で、担当者のスキルと疲労状態に品質が左右されます。

審査者としてAIを組み込んだフローはこうなります。

1. 実装フェーズ: 中コストのモデル（例: Claude Sonnet 4.6）で実装を生成する
2. 審査フェーズ: 高性能モデル（例: Claude Fable 5）が実装の問題点を洗い出す
3. 人間の判断フェーズ: AIの審査結果を見て、人間が「修正する/許容する/要件を変える」を判断する
4. 修正フェーズ: 実装モデルが審査結果を受けて修正する

このフローのポイントは、人間が毎行コードを読む必要がなくなることです。代わりに、AIが整理した問題点のリストを見て判断するという、人間が得意な仕事に集中できます。

「そんな仕組みを作るのは大変では？」という声もよく聞きます。実際には、Claude Codeのレビュー指示は難しくありません。Claude Codeのような開発環境であれば、プロジェクトの設定（CLAUDE.md）に「このフェーズではレビュアーとして振る舞え」という指示を書くだけで、基本的な動作は実現できます。完全に自動化された仕組みを最初から作る必要はありません。

クロスレビューは本当に有効なのか——実験から見えた答え

「同じAIに書かせて同じAIにレビューさせても意味があるのか」という疑問は当然です。自分の文章を自分で校正しても、ミスは見つかりにくい——それと同じことが起きるのではないか、という直感です。

この問いに対して、実験データがあります。

ReactコードのベンチマークをClaudeとOpenAI Codexで実施した比較実験では、同一モデルの継続セッション（同じ会話の中でレビューさせる）は確かに検出率が低いという結果が出ています。これは予想通りとも言えます。同じ会話の文脈をAIが引き継いでいる以上、「自分が書いた前提」から自由になれないからです。

一方で、別モデルによるクロスレビュー（Claudeが書いたコードをCodexがレビューする）は、問題検出率が有意に高まるという結果になりました。

直感的にも納得できます。モデルが異なれば、訓練データも、得意な構造も異なります。あるモデルが「あたりまえ」と判断して書き飛ばすパターンを、別のモデルは「これは問題では？」と検出する可能性があります。

「同じモデルの別セッション」（同一モデルで新しい会話からレビューする）は中間的な結果でした。継続セッションよりは改善しますが、クロスレビューほどではない。コンテキストを引き継がないことで多少の独立性は生まれますが、判断基準の違いは生まれないからです。

この結果の実践的な含意は明確です。コードレビューに別モデルを組み合わせることで、実装の追加コストに見合う問題検出が得られる場合が多い。費用対効果を考えると、全部を高性能モデルに流すより「実装は中程度のモデル、レビューは別モデル」という組み合わせが現実的です。

QAエンジニアが「自分でテストやりきる」をやめた日

開発のコードレビューだけでなく、テスト設計でも同じ構造変化が起きています。

あるSaaS企業のQAエンジニアチームが報告しているのは、Claude Codeの導入によって「テスト設計して実行する」という従来のQAの仕事のやり方がガラッと変わったという話です。従来は、QAエンジニアが自分でテストケースを設計し、自分で実行し、自分で結果を確認するという一人完結の仕事でした。

この仕事をAIに移譲すると、何が起きるか。まずテストケースの生成はAIが担います。次に実行もAIが担う。QAエンジニアの仕事は「AIが設計したテストケースが十分かどうかを判断すること」と「AIが実行できない環境・UXの問題を探すこと」に変わります。

この変化は、効率化というより役割の再設計です。QAエンジニアが単純作業から解放されるのではなく、より判断力の必要な仕事（テスト設計の評価）に移行します。人間が「実行者」から「評価者」になる——AIコーディングの品質管理において、この役割変化が核心です。

私たちAI-Pathの現場でも、これに近い変化を経験しています。VibeCodingで実装を進める中で、テストコードもAIに書かせることが増えました。ただし、私たちが特に重視しているのはUAT（ユーザー受け入れテスト）は人間が担うという点です。

なぜかというと、UATはコードの正しさを確認するだけでなく、「使いやすいか」「現場の人が迷わずに使えるか」というUXの観点を含むからです。AIは正しさは判断できますが、人間が感じる「使いやすさ」は判断できません。VibeCodingで起きがちな「謎の項目が勝手に増える」「ボタンの位置が直感と逆」のような問題は、実際にユーザーが触ってみるまで分からないことが多いです。

「守れる設計」はコードの中から始まる

AI-Pathが2026年に掲げている「Sovereign AI OS」「守れる設計」というコンセプト（詳しくは製造業向けソブリンAIの記事も参照）は、多くの場合、インフラや権限設計の話として語られます。クラウドか自社サーバーか、誰がデータにアクセスできるか——確かに外せない論点です。

しかし私たちの現場経験から言えば、「守れる設計」の土台はコードの品質から始まると考えています。

どれほど優れたセキュリティ設計をしても、コードの中に脆弱性があれば意味をなしません。SQLインジェクション、権限チェックの漏れ、入力値の不十分な検証——これらの問題はインフラ設計では防げず、コードレビューの工程で防ぐものです。

VibeCodingで開発速度が上がると、この「コードの脆弱性リスク」も速度に比例して増えます。AIが書くコードは確かに人間より一般的なバグは少ないですが、前述の通り「業務文脈のずれ」という問題が残ります。そしてセキュリティ的な問題は、多くの場合この「業務文脈のずれ」から生まれます。

たとえば、あるエンジニアリング企業の社内システムを開発した際、ユーザー権限の制御ロジックをAIが生成しました。一般的な権限制御としては正しい実装でしたが、そのシステム固有の「取引先ごとに見えるデータが違う」という要件を反映できていなかった。コードレビューの段階で発見できましたが、もし見逃してテストなしで本番に入っていたら、別の取引先のデータが見えてしまう状態になっていました。

AI-PathがISMS（情報セキュリティマネジメントシステム）の整備を自社で先に実施しているのも、この経験があるからです。「自社で先に厳格化して知見を貯める」——これは単なる認証取得ではなく、AIが書くコードの品質担保を実務レベルで検証するための取り組みでもあります。

私たちが現場で積み重ねてきた「AIレビュー」の設計

具体的にどう設計するかを、私たちの現場経験を元にお伝えします。

**設計の基本原則は「モデルの役割を明示的に分けること」**です。実装を頼むときと、レビューを頼むときでは、AIへの指示の仕方も、使うモデルも、確認の観点も変わります。

実装フェーズでは、コストを抑えながら速度を優先します。Claude Sonnet 4.6のような中程度のモデルに「この業務フローを実装してほしい」と依頼します。このとき重要なのは業務文脈を十分に与えることです。単に「在庫管理の関数を書いて」ではなく、「このシステムでは毎月末に担当者が手動で上書き修正できる必要があり、その履歴も残す要件がある」という背景まで伝えます。

レビューフェーズでは、モデルを変えます。Fable 5のような高性能モデルか、別会社のモデルを「審査者」として使います。指示の仕方も変えます。「このコードを実行してください」ではなく、「以下の観点でこのコードを批判してください。（1）業務要件の取りこぼし、（2）セキュリティ上の問題、（3）半年後のメンテナンス担当者が困りそうな箇所」という形で依頼します。

人間の判断フェーズでは、AIが挙げた問題点のリストを見て、「これは修正が必要」「これは許容する（理由を記録）」を決めます。このとき、理由を記録することを習慣にしてください。「なぜこの問題は許容したか」を残しておくことで、後でメンテナンスする人が判断の背景を理解できます。

「そこまで丁寧にやる余裕はない」という声もあります。正直に言えば、私たちも全案件で完璧にやれているわけではありません。ただし、最低限やるべきこととして「レビューフェーズだけは別モデルを使う」という習慣は、比較的少ない手間で効果を出せます。CLAUDE.mdに「コードレビュー依頼時はFable 5（またはCodex）を使う」と書いておくだけで、自然と使い分けが実現します。

CLAUDE.mdに「審査者の設定」を書いておく

CLAUDE.mdは、Claude Codeのプロジェクトに固有のルールや文脈を書いておくファイルです。これをうまく使うと、開発フロー全体にAIのレビュー文化を組み込めます。

アクセンチュアのエンジニアチームが公開しているCLAUDE.mdの設計では、「プロジェクトの本質（何を作っているか、誰が使うか、何を守るべきか）」を毎セッション冒頭で読み込ませることが重要だと指摘されています。セッションをまたいで文脈が失われることが品質劣化の大きな原因の一つであり、CLAUDE.mdがその補完機能を果たします。

この設計をレビューの観点に応用すると、CLAUDE.mdに以下のような内容を追加します。

• このシステムが守るべきセキュリティ要件（どの権限でどのデータが見えるか）
• 業務ルールの例外事項（一般的な実装パターンからずれるもの）
• コードレビュー時に確認する観点（3〜5項目に絞る）

この情報があると、AIレビュアーは「このシステムに固有の文脈」を踏まえた審査ができます。汎用的な「コードの問題点」ではなく、「このプロジェクトで問題になる可能性のある点」を洗い出してくれます。

よくある質問

Q: 高性能モデルをレビューに使うと費用が増えませんか？

実装にかかるトークン数とレビューにかかるトークン数では、レビューの方が少ない傾向があります。実装は長いコードを生成するため大量のトークンを使いますが、レビューは既存のコードを読んで問題点を指摘するだけなので比較的少量です。実装は中コストのモデル、レビューは高コストのモデルを使うことで、全体のコストは思ったほど増えないケースが多いです。

Q: AIのレビューだけで十分で、人間のレビューはいらなくなりますか？

なりません。AIは「コードとして正しいか」は判断できますが、「この変更が今の組織の優先事項と合っているか」「この機能を今リリースして現場が混乱しないか」といったコンテキスト依存の判断はできません。人間の判断が必要なのは、業務上の意思決定が絡む箇所です。AIを入れることで、人間が確認すべき箇所が絞り込まれます。

Q: VibeCodingで内製化を進めようとしている非エンジニアにも使えますか？

使えますが、難易度が上がります。コードの問題点をAIが指摘してくれても、それが本当に問題かどうかを判断するには最低限の技術知識が必要です。非エンジニアがVibeCodingで開発する場合、私たちは「品質の確認フェーズだけはエンジニアのサポートを受ける体制」を強く推奨しています。

Q: どこから始めればいいですか？

まず「レビューフェーズだけ別モデルを使う」という一点から始めることをお勧めします。CLAUDE.mdに「コードレビューを依頼するときはFable 5を使う」と書いて、1週間試してみてください。どんな問題が指摘されるかを見ると、自社のVibeCodingワークフローのどこに穴があるかが見えてきます。

まず試すなら

1. レビューモデルを1つ選んで、来週から試す

現在使っているAI開発ツールに加えて、「レビュー専用のモデル」を決めます。Claude Codeを使っているなら、Fable 5を指名してレビューを依頼してみてください。「このコードの（1）セキュリティ上の問題、（2）業務ロジックの抜け、（3）メンテナンス性の問題を挙げてください」という指示で始めると、すぐに使えます。

2. CLAUDE.mdに「守るべき業務ルール」を書き加える

現在のプロジェクトのCLAUDE.mdに、「このシステムで守るべきこと」を3〜5項目書き加えます。権限設計、データの保持ルール、例外処理の方針——チームが口頭では共有しているが、どこにも書いていない「暗黙のルール」を書き出すのが最初のステップです。

3. 自社のVibeCodingワークフローの品質ガバナンスを設計したい方へ

AI-Pathでは、無償の業務プロセス診断（BPR）を通じて、VibeCodingを使った内製化の進め方と品質担保の仕組みを一緒に設計しています。「速く作れるようになってきたが、品質の確認体制が整っていない」「ISMSや社内のセキュリティ基準に対応した開発フローを作りたい」という場合は、まず無償の業務診断でご相談ください。

参考リンク

本記事の執筆にあたり以下を参照しました。

高性能モデルの使いどころは『実装者』でなく『レビュアー』 — Fable 5 実機評価（Fable 5の実機評価・審査者としての活用）

別モデルによるクロスレビューは有効なのか？同一モデルの継続セッション・別セッションと比較する（クロスレビューの効果検証・React習熟度ベンチマーク）

QAエンジニアが「自分でテストやりきる」のをやめようとしている話（AIによるQAの役割変化）

Claude Codeのアドバイザーが「プロジェクトの本質」を毎回思い出させてくれる（CLAUDE.mdの設計思想・公式ドキュメント準拠）