Opus 5.5のコードレビュー:指摘を再現して確かめる

合成Pythonコード、意図的に失敗するテスト、指摘記録表でOpus 5.5のレビュー手順を設計。根拠のある不具合と仮説、見逃しを分けて扱います。

青灰色の背景に、カード上のデスクライトの黒い線画、点の装飾、Opus 5.5 Code Reviewの英字。

Opus 5.5のレビュー指摘は、「不自然に見えるコード」ではなく、再現できる具体的な動作を示す必要があります。 小さなPythonモジュール、プロンプト、テストを使い、指摘と推測を分ける手順を練習します。

2026年9月24日にOpus 5.5のプロンプトガイドを確認しました。実行したのは合成教材のローカルテストです。Opusが欠陥を発見したとは述べておらず、誤検出率やモデル順位も測っていません。

コードと要件を固定する

教材ZIPreview_fixture.pyreview-prompt.txtreview_tests.py、空のfindings.csvを使います。故意に壊したコードなので本番に転用しないでください。

要件は、offsetから最大size件を返すこと、0–100の範囲外の割引を拒否すること、タグの独立した浅いコピーを返すことです。要件がないままでは、設計上の選択を不具合と誤認しかねません。

commitかアーカイブのハッシュ、モデルID、供給元、クライアント版、effort、ツール権限を記録します。Claude Codeでは利用ガイドに沿って選択モデルを確認します。画面の名前だけで全リクエストの経路が証明されるわけではありません。

編集の前に根拠を求める

レビュー用プロンプトは、ファイルと行、再現入力、期待値と実値、実行可能な手順を要求します。確定した不具合と仮説を分け、最初の段階では編集させません。

独立発見を評価するならテストと正解を隠し、指摘の提出後に採点します。テストを先に渡すなら「テストに基づく修正」と呼びます。どちらも有用ですが、同じ能力の評価ではありません。

コメントやログは信頼できる命令ではなく調査資料です。秘密を送信させる文や依頼を無視させる文に従わず、必要なリポジトリと操作へ権限を限定します。

意図的に入れた2つの不具合を再現する

レビュー結果を保存してから実行します。

python3 review_tests.py

終了コードは失敗になるのが正解です。ローカル実行では2テストが失敗し、1テストが成功しました。公開サイトのビルド失敗とは別の、教材の期待結果です。

動作入力期待実際
ページが1件少ないpage([1,2,3], 0, 2)[1,2][1]
不正な割引を受け入れるpayable(1000, 120)ValueError-200
独立した浅いコピーcopy_tags(['a'])の戻り値へ要素を追加元リスト不変元は['a']

スライス終点が1つ早く、割引では範囲検査をせず計算しています。コピー関数はこの要件を満たします。あらゆる要件で正しいという意味ではありませんが、深いコピーを要求していないのにその欠如を不具合とは呼べません。

自信ではなく指摘を採点する

固定版で再現し、確認済み、根拠なし、未解決の3状態で管理します。同じ原因の重複指摘をまとめてから数えます。報告されなかったあらかじめ入れた不具合も記録してください。

1つ正しく報告して別の欠陥を見逃したレビューは、書いた内容が正しくても完全ではありません。詳しい説明も、誤った再現条件や勝手に追加した要件を補えません。

適合率や再現率には合意した正解と分母が必要です。この小課題は計算方法の練習にはなりますが、モデル全体を採点できません。実業務に近い統合処理、移行、並行実行などの例を選び、失敗例も残します。

修正と回帰確認は別に行う

判定後、別ブランチで終点と範囲検査を直して再実行します。空リスト、sizeが0、割引0と100などを追加します。負のoffsetや非整数割引、無効な金額は、先に仕様を決めてからテストしてください。

AIアシスタントが書いた変更でも差分を確認し、関連テストを実行します。3ケース通過は完全な正しさではありません。元の欠陥コードとログも残し、記事の結果を再現可能にします。

モデルと連携の制約も記録する

Opus 5.5変更点で連携仕様の変更と拒否処理を確認します。以前のOpusの設定をそのまま置き換えられるとは考えず、実際の停止理由と未完了レビューを保存してください。未完了を完了済みとして扱わないことも重要です。実評価では使用量、全試行、確認済み欠陥、見逃し、誤指摘、人の確認時間を併記します。Solとの費用比較も、単価からレビュー品質は決められないことを説明しています。

よくある質問

Opus 5.5の検出率を測っていますか?
いいえ。不具合と期待動作は教材として作ったもので、テスト出力はOpusのレビュー結果ではありません。
再現なしで指摘を確定できますか?
入力、期待動作、実際の結果を独立して確認するまでは仮説として扱います。
成功するテストも必要ですか?
正常な動作を残し、根拠のない指摘を考えるために使えます。ただし1例で一般的な誤検出率は分かりません。