Claude Opus 5.5 コード監査チェックリスト：マージ前に全指摘を検証する

Claude Opus 5.5に数時間かけてリポジトリを監査させると、「重大」とされた指摘が何十件も並び、大きな修正パッチまで用意されることがあります。難しいのはその後です。実在する不具合はどれか、既存の設計意図を壊す変更はないか、どの修正なら安全にマージできるかを判断しなければなりません。

ここではモデルの出力を結論ではなく、証拠が必要な監査仮説として扱います。最初に再現可能なベースラインを固定し、各指摘を再現、リスク、アーキテクチャ、修正、回帰テストのゲートに通します。

Opus 5.5は監査範囲を広げる道具であり、マージ承認者ではない

大規模で長時間の監査には有力な候補ですが、独立したレビューを代替するものではありません。 Anthropicは2026年9月22日の発表で、リポジトリ全体の移行や監査をOpus 5.5の得意な長時間タスクとして挙げ、社内試験や早期利用者の結果を紹介しています。ただし、それらは提供元や個別テスターの結果であり、あなたのリポジトリでも同じ成果が出る保証ではありません。AnthropicのOpus 5.5発表。

Kent C. Doddsは、セキュリティ、性能、アクセシビリティ、保守性、拡張性、アーキテクチャ、ドキュメント、テスト、自動化を対象にした監査プロンプトを公開し、Opus 5.5が他モデルの見逃した重大なセキュリティ問題を見つけたと述べています。一方、その投稿には問題の詳細、再現手順、対照実験はありません。試す価値は示しますが、検証を省いてよい根拠にはなりません。公開投稿を確認する。

したがって目標は、警告数を最大化することではなく、再現可能で、優先度が付けられ、独立して確認できる指摘を増やすことです。

監査前に「成功」を実行コマンドで定義する

正常なベースラインがなければ、後の失敗が既存不具合なのか、モデルの変更による回帰なのかを区別できません。 現在のコミット、実行環境、主要依存関係、各コマンドと終了コードを保存します。

次のプレースホルダーを実プロジェクトのコマンドに置き換えてください。該当しないゲートは、無理に作らず「対象外」と記録します。

git status --short
<install-command>
<lint-command>
<type-check-command>
<unit-test-command>
<integration-test-command>
<build-command>

最低限、次を残します。

• コミットSHA、ランタイム、パッケージマネージャー、重要な依存バージョン
• 正確なコマンド、作業ディレクトリ、終了コード、失敗の要点
• 既知の失敗、フレークするテスト、一時的な例外
• 監査対象ディレクトリと、生成コード、過去のマイグレーション、ロックファイル、ベンダーコードなど変更禁止の範囲
• 認証、認可、課金、データ移行、外部API契約などの重要経路

ベースラインがすでに失敗している場合は、先に修正、隔離、既知問題としての登録のいずれかを行います。古い失敗を新しい発見として扱わせないためです。

最初は「監査のみ、コード変更なし」と指示する

調査フェーズと修正フェーズは分離します。 調査しながらファイルを変更すると、次の失敗が元のコード、最初の修正、それとも複数パッチの相互作用によるものか分からなくなります。

以下を初回プロンプトとして使い、リポジトリ固有の制約を追加します。

このリポジトリを長時間監査してください。現在のフェーズでは調査と報告だけを行い、ファイルを変更しないでください。

対象: <ディレクトリ、サービス、言語、重要な業務フロー>
除外: <生成ファイル、外部コード、過去のマイグレーション、アクセスできないシステム>
ベースライン: <実行済みコマンド、終了コード、既知の失敗>

確認項目:
1. セキュリティと認可境界
2. 正しさ、並行処理、トランザクション、エラー処理
3. 性能とリソース使用量
4. 該当する場合のアクセシビリティ
5. 保守性と拡張性
6. アーキテクチャとモジュール境界
7. ドキュメント、テスト、自動化の不足

各指摘に必ず含めるもの:
- 一意のIDと短い題名
- 重大度と影響の根拠
- 対象ファイル、シンボル、正確な行
- 発生条件、期待動作、実際の動作
- 再現コマンドまたは最小テスト
- 出力の要約と終了コード
- 誤検知である可能性の説明
- 最小の修正方針
- 修正後に必要な検証コマンド
- 確信度: 高・中・低

ルール:
- 実行していないコマンドは「未実行」と明記する。
- 再現できない指摘は「未検証」とし、確認済みと書かない。
- テストを通すために削除、スキップ、弱体化しない。
- 認証情報、サービス、依存関係が不足したら停止し、不足項目を列挙する。
- 各フェーズ終了時に状態表を更新し、レビューを待つ。

このプロンプトだけで遵守が保証されるわけではありません。ターミナル記録、差分、実際のテスト出力を確認してください。目的は、曖昧な「問題かもしれない」をそのまま修正キューへ送らないことです。

長時間タスクを4つの管理フェーズに分ける

長時間実行だからといって、範囲や権限を無制限にしてはいけません。 各フェーズの終了時に止め、証拠を確認してから次へ進みます。

フェーズ1：システム地図を作る

コード、設定、テスト、設計文書を読み、入口、信頼境界、データフロー、外部依存、影響の大きい経路を整理します。この段階では不具合件数の目標を置かず、ファイルも変更しません。

フェーズ2：候補指摘を出す

各候補は、具体的なコード位置と発生条件に結び付けます。場所やトリガーのない一般論は「改善案」であり、不具合件数には含めません。

フェーズ3：一件ずつ再現する

影響が大きく、確認コストが低い候補から始めます。一つの実験で一つの仮説だけを検証し、加工前の出力と環境条件を保存します。

フェーズ4：修正計画を作る

再現できた不具合だけを計画に入れます。最小変更、互換性への影響、移行リスク、ロールバック、必須テストを記載し、設計判断が必要な項目はコードオーナーに回します。

状態はaudit-plan.mdやチケットで管理します。

ID	状態	リスク	再現証拠	設計判断	修正ブランチ	承認者
AUD-001	再現待ち	高	まだなし	未確認	—	—

進行は候補 → 再現待ち → 再現済み → 設計確認済み → 修正済み → 受け入れ済みに限定します。モデルの文章が自信に満ちていても、証拠なしに状態を進めません。

リスクゲート：重大度と確信度を分ける

重大度は想定被害、確信度は証拠の質を表します。 認可回避の可能性は高重大度でも低確信度かもしれません。確実に再現するログの誤字は高確信度でも低重大度です。

重大度	適用条件	修正前に必要な最低証拠
致命的	広範な権限昇格、機密データ露出、不可逆な破損、基幹サービス停止	制御環境での再現、影響範囲、責任者の即時確認
高	重要業務フローに影響、または現実的な入力で安定して発生	最小再現、失敗テストかコマンド出力、コードオーナー確認
中	影響が限定的、回避策がある、または特殊条件が必要	反復可能な証拠と優先度判断
低	局所的な品質、文書、保守性、非重要性能	具体的なコード根拠と、回帰リスクを上回る利益

モデルはコード経路を追えても、データの機密度、顧客との約束、許容停止時間、互換性方針を自動では知りません。事業上の影響は責任者が補います。

再現ゲート：指摘を「修正前に失敗する検査」に変える

怪しいコードを示すだけでは不十分です。 修正前に失敗し、修正後に通る検査が必要です。各指摘について次を確認します。

1. どのコミットと環境で起きるか
2. 最小の発生入力は何か
3. 期待動作はテスト、仕様、契約、業務規則のどれで定義されるか
4. 実際の結果と生出力はどこにあるか
5. 既存テストが見逃した理由は何か
6. 正当な設計判断や環境差で説明できないか

理想は最小の回帰テストです。自動化できない場合も、決定的な手順、観察結果、後片付けを記録します。セキュリティ問題は、所有または許可されたローカル、隔離、検証環境でのみ再現してください。

モデルがコマンドを実行したと述べたら、完全なコマンド、作業ディレクトリ、終了コード、関連出力を確認します。文章の要約だけでは実行証拠になりません。

アーキテクチャゲート：既存コードがそうなっている理由を確認する

見た目がきれいな変更でも、互換性、デプロイ順序、意図的な境界を壊すことがあります。 大きな変更の前に、ADR、設計文書、API契約、データ移行制約、履歴を確認します。

Git履歴が使える場合は次を補助にできます。

git log -- <path>
git blame -L <start>,<end> <file>
git show <commit> -- <path>

そのうえで、次への回答を求めます。

• 現在の設計は何の制約を守っているか
• どの呼び出し元、データ形式、デプロイ手順が依存しているか
• 提案は不具合修正か、製品動作の変更か
• より小さな局所変更で解決できないか
• ロールバック時にコード、設定、データのどれを戻す必要があるか

履歴は手掛かりであり、意図そのものではありません。根拠が見つからない場合は「設計意図不明」とし、保守担当者に確認します。

修正ゲート：再現済みの一件につき小さなパッチ一つ

複数の無関係な指摘をまとめた巨大パッチは受け入れません。 まず旧コードで安定して失敗するテストを追加し、その後に最小修正を行います。

ゲート	要件	失敗した場合
範囲	差分は承認済み指摘だけを扱う	無関係な変更を分離する
回帰テスト	修正前に失敗し、修正後に成功	テストを直すか指摘を再評価する
静的検査	フォーマット、Lint、型検査が通る	広い例外で新エラーを隠さない
プロジェクト検査	関連Unit、Integration、Buildが通る	次のパッチ前に最初の新規失敗を調べる
アーキテクチャ	オーナーが境界と互換性を承認	範囲縮小または設計レビューを行う
人手差分レビュー	エラー処理、権限、データ変更、削除を確認	怪しい差分を一つずつ説明する

アサーション削除、テストスキップ、例外の握りつぶし、検証の弱体化、競合を隠すためのリトライ増加、元の不具合を追えなくする大規模リファクタリングは「偽の成功」として拒否します。

回帰ゲート：モデルが選んだ検査だけでなく、プロジェクト標準を実行する

最終判定は既存スクリプトやCIで行います。 監査前の完全なベースラインと修正後を比較し、新しい回帰テストが未修正版で本当に失敗することを確認します。

ロックファイル、データベースマイグレーション、公開API、設定既定値の意図しない変更も確認します。性能改善は同一環境・同一入力で比較します。フレークするテストは、緑になるまで回すのではなく、失敗パターンを記録し、修正が不安定性を悪化させていないか調べます。

次の兆候が一つでもあれば指摘を却下する

• 正確なコード位置、発生条件、確認可能な証拠がない
• 未実行のコマンドを「成功」と報告している
• 重大度に具体的な影響経路がない
• パッチが承認範囲を超え、無断で設計を変更している
• テストを削除、スキップ、弱体化し、またはエラーを隠している
• ADR、契約、移行方針と矛盾するのに責任者承認がない
• 最終要約しかなく、コマンドやレビュー可能な差分がない
• セキュリティ主張の根拠が「別モデルも同意した」だけ

別モデルは反例探しには使えますが、モデル同士の合意は独立証拠ではありません。独立検証はテスト、実行出力、履歴、仕様、責任ある人の判断から得ます。

マージ前の最終チェックリスト

• 対象、除外、ベースラインコミットを固定した
• ベースラインコマンドと終了コードを保存した
• 受け入れる全指摘にIDと正確なコード位置がある
• 重大度と確信度を別々に記録した
• テストまたは決定的手順で不具合を再現した
• 設計意図、互換性、ロールバックを確認した
• 一件の指摘が小さくレビュー可能な一つのパッチに対応する
• 回帰テストが修正前に失敗し、修正後に成功する
• 既存スクリプトまたはCIで全ゲートを実行した
• コードオーナーが最終差分を確認し、明示的に承認した

公開情報から、Opus 5.5は広範で長時間のコード監査を試す価値があり、他の確認で見落とされた問題を示す可能性もあります。ただし、検証は不要になりません。最小の次の一歩は、すぐに編集を許可することではなく、正常なベースラインを保存して「監査のみ、変更なし」の初回タスクを実行することです。