ClaudeとCodexに同じアプリをレビューさせてみた——セカンドオピニオンを活かす比較方法

はじめに

コードレビューをAIに任せるとき、1つのモデルの回答だけを見て「問題なさそう」と判断してよいのか。私は以前から、この点に少し不安がありました。

1つのAIは、最初に見つけた問題を中心にレビューを組み立てます。プロンプトに含まれていない観点や、最初に読んだファイルから遠い処理は、実装されていても報告されないことがあります。そこで、プライベートな個人用アプリを対象に、ClaudeとCodexへ別々にレビューを依頼し、出力されたHTMLレポートを比較しました。

この記事では、アプリそのものの詳細や実データは扱いません。レビューの条件、共通して出た指摘、一方のレポートにしか登場しなかった指摘、そしてレビュー結果をどう人間が再確認するかをまとめます。

先に結論を書くと、セカンドオピニオンの価値は「どちらのAIが勝ったか」ではありません。2つのレポートの交差部分を高優先度の候補として扱い、片方だけの指摘を再現テストへ回すという、判断材料の増やし方にあります。

この記事で持ち帰れること

AIレビューを比較するときに揃えるべき条件
2つのレビューで共通した指摘と、報告が分かれた指摘の読み方
レビュー時間やテスト件数を、品質スコアと誤解しないための考え方
プライベートなアプリをAIに見せるときの情報最小化と再現手順

今回のレビュー条件

対象は、家庭内LANで利用する個人用アプリです。記事ではアプリ名、ローカルパス、画面固有の情報、実データを出さず、一般化できる範囲だけを扱います。

2つのレビューは、同じ対象を2026年8月17日に別々に実施したものです。レビューHTMLに残っていた範囲を整理すると、条件には次の差がありました。

項目	Claudeのレビュー	Codexのレビュー
実行時間	約26分	約15分
確認範囲	ソース、仕様書、テスト、一時DB、ブラウザで全画面を確認	ソース、仕様書、テスト、一時DBを確認
テスト結果	96件すべて成功	96件すべて成功
ブラウザ確認	スマートフォン相当のビューポートを含めて実施	操作用ブラウザへ接続できず、視認性評価は対象外
実データ	一時DBで検証	実データ・認証情報にはアクセスしていない
レポートの分類	Critical 0件、Major 2件、Minor 7件、Suggestion 8件	Major 2件、Minor 5件を中心に整理

この表で重要なのは、実行時間の差を性能の優劣に変換しないことです。Claudeの方が長く動いたのは、ブラウザで全画面を確認していたからです。Codexの15分という数字だけを見て「簡潔で優秀」と決めることも、26分という数字だけを見て「遅い」と決めることもできません。何を確認した時間なのかをセットで読む必要があります。

2つのレビューで共通して確認できたこと

まず、両方のレポートで一致していたベースラインを整理します。

96件のテストは両方で成功した

どちらのレポートにも、既存テストが96件すべて成功したことが記録されています。これは安心材料ですが、「96件成功だから問題なし」という意味ではありません。テストがカバーしていない入力や、ブラウザでしか発生しない状態遷移は、テスト成功と両立します。

今回も実際に、テストは通っているのにレビュー対象になった問題がありました。金額や精算に関わる業務ロジック、入力中の値が消える状態、家庭内LAN上の変更APIの保護などです。

テスト結果は「既存の期待動作が壊れていない」という情報であり、「期待動作の定義が十分」という情報ではありません。この区別を、レビュー結果の冒頭に明記しておくと誤解が減ります。

基本的な実装上の安全策は確認された

レビューでは、SQLがプレースホルダーで実行されていること、表示用のユーザー入力がエスケープされていること、CSV取り込みのプレビューが保存前に確認できることなど、維持すべき設計も確認されました。

AIレビューは問題探しに偏りがちですが、良い設計を残すことも重要です。修正のために全体を書き換えてしまうと、すでに正しく動いている安全策まで壊す可能性があります。「ここは問題なし」と言える箇所をレポートに残す意味は大きいと感じました。

UIのアクセシビリティと拡大表示に問題が出た

両方のレポートに、キーボード操作、補助テキストの見やすさ、モーダルの扱い、画面の拡大禁止といったアクセシビリティ上の指摘が登場しました。ここは、2つのレビューで重なったため、優先的に再確認する価値があります。

ただし、共通しているから即修正ではありません。キーボード、読み上げ、200%拡大など、人間が確認条件を決めて実際に操作し、対象ユーザーにとってどの程度の影響かを判断します。

図: 共通指摘を優先しつつ、片方だけの指摘も人間の再現確認へ回す

片方のレポートにしか登場しなかった指摘

ここが、セカンドオピニオンを使う一番の理由です。報告が分かれたからといって片方が間違いとは限りません。確認範囲やプロンプトが違えば、同じコードを見ても違う論点が出ます。

Claude側のレポートで深掘りされた論点

Claudeのレポートでは、画面を操作しながら見つけやすい状態遷移や、利用者の導線に関する指摘が目立ちました。

精算済みの月を後から編集したとき、画面によって精算額が異なる可能性
金額やメモを入力した後で項目や負担者を切り替えると、入力途中の値が消える問題
一覧画面から項目だけを変更できない編集導線
設定画面の読み込みに失敗したとき、読み込み中のままになる可能性
WALを使うデータベースのバックアップ手順と、アプリ内ヘルプの説明の不一致
Hostヘッダーの検証不足による、家庭内LANでのDNSリバインディング耐性

これらは、ソースだけを読むより、画面の状態を切り替えたり、利用者の操作手順を追ったりした方が見つけやすい論点です。ブラウザ確認が含まれていたことが、レポートの傾向に影響したと考えられます。

Codex側のレポートで強調された論点

Codex側では、入力時の既定値と、ネットワーク上の変更系APIの境界が強く指摘されました。

カテゴリに設定された既定の負担者が、通常入力では初期値に反映されない問題
家庭内LAN上の書き込みAPIに認証・認可がない問題
クリック用の div、ズーム禁止、モーダルのフォーカス管理などのアクセシビリティ不足
精算済みへの切り替えが即時実行される導線
CSV確認画面の「全件選択」が除外理由を上書きできる可能性

こちらは、コード上のデータの流れと、APIの境界を追うレビューの強みが出ています。家庭内LANだから安全と決めつけず、同じネットワークにいる端末から変更操作ができるかを問題として切り出した点は、セキュリティのセカンドオピニオンとして有用でした。

「片方だけ」は「片方が見落とした」と同じではない

ここは慎重に扱う必要があります。ClaudeのレポートにないからCodexが見落とした、CodexのレポートにないからClaudeが見落とした、とすぐに断定はできません。

レビュー結果に出なかった理由には、次のようなものがあります。

その観点を確認するツールが使えなかった
同じ問題を別の指摘の中に含めていた
重大度の基準が違い、Suggestion側にまとめていた
レポートの文字数や時間の制約で優先順位が下がった
実装上は確認したが、問題なしとして記録しなかった

したがって、比較表には「Claudeだけが発見」「Codexだけが発見」と断定的に書くより、一方のレポートにのみ登場した指摘と書く方が正確です。

レビュー結果を比較するときの4つの軸

1. 共通部分は高優先度の候補にする

2つのレビューが独立して同じ問題を指摘しているなら、再確認の優先度を上げます。今回なら、アクセシビリティやズーム制限が該当します。

ただし、共通していることは証拠ではありません。2つのAIが同じ誤解を共有することもあるため、ブラウザ操作、テスト、HTTPリクエスト、コード読解などで人間が再現します。

2. 片方だけの指摘は、根拠を読む

片方だけの指摘は、セカンドオピニオンで得られる追加情報です。特に次の条件に合うものは、見落とし候補として優先的に確認します。

金額・権限・データ消失など、失敗時の影響が大きい
指摘に具体的なファイルや関数、操作手順がある
既存テストの範囲外である
ローカル環境と本番に近い環境で挙動が変わる

今回の「既定負担者が通常入力に反映されない」「変更系APIに認証がない」は、実際の利用条件に照らして人間が再確認すべき候補です。AIの表現を信じるのではなく、該当コードと実際のリクエストを確認します。

3. 指摘の件数を品質スコアにしない

ClaudeはCritical、Major、Minor、Suggestionを分け、CodexはMajorとMinorを中心に整理していました。分類名や件数が違うため、単純に「Claudeは17件、Codexは7件だからClaudeの方が優秀」とは言えません。

件数を比較するなら、少なくとも次の条件を揃える必要があります。

重大度の定義
対象にしたファイルと画面
実行したテスト
ブラウザや一時DBの有無
レポートへ記録する最低ライン

件数は作業量の参考にはなりますが、品質の点数ではありません。

4. 「問題なし」の範囲を確認する

レビューで「問題なし」と書かれていても、すべての可能性を調べたという意味ではありません。「ブラウザへ接続できなかったため視認性評価は含めない」のように、できなかったことが明記されているレポートの方が信頼できます。

今回のCodexレポートは、ブラウザ確認ができなかったことを制約として明記していました。これは弱点の告白ではなく、結果の適用範囲を判断するための重要な情報です。

実際に使えるセカンドオピニオンの手順

Step 1: 対象を固定する

まず、レビューするコミットや作業ツリーを固定します。レビュー中にコードが変わると、2つのレポートが違う対象を見てしまいます。

git rev-parse HEAD
git status --short --branch

プライベートアプリの場合は、実データを使わず、一時DBやダミーの入力を用意します。レビュー対象に必要のない設定ファイル、環境変数、秘密鍵は渡しません。

Step 2: なるべく同じ依頼文を別々に渡す

ClaudeとCodexに別の目的を与えすぎると、出力の差がモデル差ではなくプロンプト差になります。まず同じ基本依頼を渡し、その後に追加の観点を分けます。

同じコミットのソース、仕様書、テストを対象にコードレビューしてください。
実データと認証情報にはアクセスしないでください。一時DBとダミー入力だけを使います。

次の形式で、根拠を付けて報告してください。
- 重要度
- 問題の要約
- 再現手順または該当コード
- 利用者への影響
- 修正案
- 確認できなかった範囲

レビュー後も、依頼がない限りソースは変更しないでください。

同じ依頼文にした上で、ClaudeにはUI/UXの確認、Codexにはデータフローとセキュリティの反証を追加する、という分け方もできます。その場合は、追加観点を比較表に残しておきます。

Step 3: レポートを混ぜずに保存する

片方のレビュー結果を先にもう片方へ渡すと、独立したセカンドオピニオンではなくなります。まず review-claude.html と review-codex.html のように別ファイルへ保存し、両方が完成してから比較します。

また、HTMLレポートを保存するときは、出力にローカルパスや個人情報が残っていないか確認します。記事の素材として使う前に、アプリ名を一般化し、コード断片や画面名も必要最小限にします。

Step 4: 共通・差分・制約に分類する

比較表は次の3列に分けると、結果を過大評価しにくくなります。

分類	意味	次のアクション
共通指摘	2つのレポートに同じ論点がある	最優先で再現確認
一方のみの指摘	片方のレポートにだけ登場する	根拠と影響を読んで確認
制約	ツールや環境の都合で確認できなかった	別の方法で補完する

「問題なし」は4つ目の分類ではありません。問題なしと書かれた観点についても、何を確認した結果なのかを記録します。

Step 5: 人間が再現して、対応を決める

最後は、重大度の高い順に再現します。金額計算なら入力パターンと期待値を固定し、認証なら許可されていない端末からの書き込みを確認し、UIならキーボードや拡大表示で操作します。

AIのレポートは、修正指示書ではなく再現テストの候補一覧です。人間が再現できたものだけを修正し、修正後に同じテストをもう一度実行します。

今回の比較から得た改善候補

今回の2レポートを、人間が次に確認する順番へ並べると次のようになります。

書き込みAPIの保護 — 家庭内LANでも、同じネットワーク上の端末から変更できる範囲を確認する
負担者の既定値と精算額の整合性 — 入力画面、一覧、精算画面で同じルールが適用されるかを確認する
精算済みデータの編集 — 編集後にすべての画面で同じ値が表示されるかを確認する
アクセシビリティ — キーボード操作、フォーカス、拡大表示、コントラストを確認する
CSVとバックアップ — 除外理由の扱い、WALを含むバックアップ手順を確認する

これはAIの指摘件数順ではありません。データの正しさとアクセス制御を先に、その次に利用者が誤操作しやすい導線を置いています。対応の順番も、最終的にはアプリの利用者と運用条件を知る人が決めるべきです。

プライベートなアプリをレビューさせるときの注意

個人用アプリでも、入力データやローカル環境には保護すべき情報が含まれます。レビューの精度を上げるために、何でも渡すのは危険です。

渡す情報を最小化する

実データではなく、構造を再現したダミーデータを使う
.env、秘密鍵、アクセストークン、Cookieを渡さない
ローカルパス、ホスト名、ユーザー名を一般化する
レビューに不要な履歴やログを除外する
外部サービスへ送信される範囲を確認する

レビューHTMLを記事の素材にするときも、個人アプリの名前をそのまま公開しません。今回も「家計簿アプリ」という機能領域だけを残し、特定につながる名称やパスは使わない方針にしました。

認証・認可の指摘は、人間レビューを必須にする

認証方式やLAN境界を変更する提案は、単なるリファクタリングではありません。便利そうな修正案でも、そのまま実装せず、ネットワーク構成、利用端末、脅威モデルを人間が確認します。

「家庭内だから大丈夫」「ローカルだけだから認証不要」という前提は、レビューで明示的に疑うべきです。一方で、AIに指摘されたから必ず大規模な認証基盤を入れるという意味でもありません。想定する攻撃者と、守るべき操作を決めてから対処します。

レビュー結果を公開しすぎない

コードレビューの実例は有用ですが、脆弱性の再現に必要な情報をそのまま公開すると、アプリや環境の特定につながります。記事では、脆弱性の本質と確認方法を一般化し、実際のエンドポイント名やローカルアドレスは掲載しない方が安全です。

まとめ

ClaudeとCodexに同じアプリをレビューさせると、同じ指摘が重なる部分と、片方のレポートにしか出ない論点が見えてきます。今回のポイントは次の通りです。

セカンドオピニオンは勝敗を決める仕組みではなく、確認すべき候補を増やす仕組み
共通指摘は優先的に再現し、片方だけの指摘も根拠と影響を読んで捨てない
レビュー時間や指摘件数は、対象範囲と制約を併記しないと比較できない
テストが全件成功していても、未定義の期待動作やUI、ネットワーク境界の問題は残り得る
プライベートなアプリでは、実データを使わず、秘密情報と特定情報を最小化する
AIの提案はそのまま修正せず、人間が再現してから対応を決める

1つのAIに「問題がないか」と聞き、問題がないと答えたから終わりにする。その流れを変えるだけでも、コードレビューの質は上げられます。ただし、AIを2つに増やせば自動的に安全になるわけではありません。対象を固定し、条件を記録し、制約を明示し、最後は人間が再現する。この手順まで含めて、セカンドオピニオンとして使うのが現実的です。

Claude Codeおすすめプラグイン集 2026年版——実際に使っている構成と選定基準 — Claude Codeのプラグイン選定と、Codexを別のAIモデルによるセカンドオピニオンとして使った経験

カテゴリ

AWS & AI ツール

タグ