ln-22-codebase-auditor

コードベース監査

目標： 本番コード全体の健全性を、読み取り専用で幅広く監査します。検出パターンや個人的なスタイルの好みを問題として扱わず、複数領域にまたがる具体的な障害、セキュリティ、リリース、および保守性のリスクを見つけます。ドキュメントの信頼性、テスト群、アーキテクチャ全体、または永続化に特化したレビューの代わりにはなりません。

実行条件： 順序付きのチェックボックスが完了の定義です。各項目を内部で PENDING、具体的な証拠がある PROVEN、該当する条件が存在しない証拠がある CLEARED、または未解決の不足がある UNPROVEN として追跡します。読んだこと、委任したこと、またはツールの失敗は証明になりません。各セクションの後に項目を再評価してください。回答を返す前に、すべての PENDING を解消し、PROVEN と CLEARED のみを数えます。すべての不足に対し、このスキルの判定ルールと承認ルールを適用してください。 ユーザーの意図、範囲、および既存の承認を尊重してください。承認された作業は続行し、重大な未解決の選択肢や必須の外部承認がある場合にのみ確認を求めてください。重大なリスクに応じて調査の深さを調整し、チェックを黙って省略しないでください。依存関係と安全性に関する順序を守り、それ以外は各義務に適した検証方法を選択してください。

ツールの使い分け

必要事項	推奨ツール	使用する場面	代替手段
リポジトリの構成把握とスタックの検出	ネイティブのファイル一覧、マニフェスト、ビルドファイル、リポジトリの指示	範囲、生成領域、エントリーポイント、サポート対象ランタイム、コマンドを確認するとき	対象を絞ったツリーの確認と既知のエントリーポイント
シンボル、呼び出し元、所有者、データフロー	言語サーバーまたはホストネイティブのコードインテリジェンス	シンボルの同一性、参照、オーバーライド、ルートの接続、またはファイル間の挙動が問題の判断に関わるとき	範囲を絞ったテキスト検索と、関連するすべての一致箇所の直接確認
現在の変更と履歴上の背景	Git のステータス、差分、ログ、blame	現在の作業、リグレッション、意図的な制約、不要になった互換性維持コードを区別するとき	現在の実装と明示的な意思決定記録
リリースの健全性	リポジトリで定義されたビルド、リンター、型チェック、テスト、スモークテストのコマンド	ドキュメントに記載された環境でプロジェクトをリリースできるか確認するとき	CI とスクリプトを確認し、実行できない場合はその旨を記録
依存関係とセキュリティの状態	ネイティブのパッケージマネージャー監査、マニフェスト、ロックファイル、公式アドバイザリ	既知の脆弱性、サポート対象外のバージョン、依存関係の健全性を確認するとき	公式レジストリとベンダーの情報源を使用し、深刻度を推測しない
ランタイムの証拠	既存のログ、メトリクス、トレース、プロファイル、診断情報	静的解析では頻度、到達可能性、運用上の影響を判断できないとき	呼び出し経路を分析し、静的解析のみであるという制約を明示
現在の外部挙動	公式仕様、ベンダーのドキュメント、リリースノート	問題の判断が現在の API、ランタイム、または標準の挙動に依存するとき	一次情報を用いてウェブ調査し、それができない場合は UNVERIFIED と記録

まず概要レベルで調査し、その後対象を絞って詳しく確認します。リポジトリで定義されたコマンド、または明らかに安全な診断コマンドのみを実行してください。監査中に公開、デプロイ、本番データの移行、秘密情報のローテーション、ファイルの書き換えを行ってはいけません。

証拠に関するルール

• パターンの一致は候補であり、問題そのものではありません。到達可能性、状況、影響を確認してください。
• ランタイムの障害や決定的なコマンド出力は静的な疑いより優先されます。実行できない場合は、制約を明示すれば静的な証拠も有効です。
• 生成コード、ベンダーコード、フィクスチャ、マイグレーション履歴、意図的な互換性維持コードには、それぞれの状況に応じて対応してください。
• 外部のベストプラクティスは、リポジトリにある具体的な欠陥やリスクに対処する場合にのみ、実行可能な指針となります。
• 根本原因が異なる問題のみを採点または集計してください。同じ修正で解消する症状は重複として除外してください。

チェックリスト

1. スコープとベースラインの確立

• 言語、フレームワーク、パッケージマネージャー、エントリーポイント、デプロイモデル、生成領域、リポジトリでサポートされている検証コマンドを特定します。
• プローブ、テレメトリ、シグナル処理、シャットダウン動作を求める前に、各ランタイムの実行面を、長時間稼働するサービス、CLI、ライブラリ、ジョブ、サーバーレス関数、プラットフォーム管理コンポーネントに分類します。
• 該当する指示を読み、セキュリティ境界、重要なビジネスパス、公開インターフェース、取り消せない操作を特定します。
• Git の状態を確認し、監査によってユーザーの無関係な変更を上書きしたり、誤って帰属させたり、無視したりしないようにします。
• 実行可能なビルド、リンター、型チェック、テスト、スモークテストのベースラインを確立し、実行した範囲、環境、終了ステータス、証拠を記録します。選択されたテストがない、またはゲートがスキップされたまま成功していないことを確認します。
• すべてのファイルを同じ労力でスキャンするのではなく、リスクに応じて対象外の範囲と深度を定めます。
• 監査は読み取り専用で行います。許可されたキャッシュとビルド成果物のみを作成し、作成した場合はその旨を明記します。

2. セキュリティとデリバリーの境界を監査する

• コミット済みのシークレット、安全でない認証情報のパターン、機密情報を含むデフォルト値、デバッグ用バイパス、ログやエラーを介した意図しない情報漏えいを検索します。
• 認証情報に関する問題では、生の値を決して公開しません。実際に使用可能な情報と、プレースホルダー、フィクスチャ、サンプル、許可リストに登録されたフィンガープリントを区別します。種類、場所、マスキングした証拠のみを報告し、監査中には対応せず、漏えいが確認された場合に限って無効化、ローテーション、履歴の修正を推奨します。
• 信頼できない入力が、SQL、シェル、テンプレート、HTML、ファイルパス、URL、デシリアライズ、リダイレクト、その他のインジェクションに対して脆弱なシンクに到達する経路を追跡します。
• 認証、認可、テナントまたは所有権の分離、権限の移行、安全でない直接オブジェクト参照、デフォルト拒否の動作を確認します。
• 信頼境界での検証、正規化、サイズ制限とレート制限、安全でないファイル操作、破壊的操作の確認または保護を確認します。
• 重大度を割り当てる前に、実際の呼び出し経路、フレームワークの動作、設定、最新の公式ガイダンスに照らしてセキュリティ上の問題を検証します。
• コンパイラー、リンター、型チェッカー、テスト、パッケージング、CI の設定を調べ、ゲートのスキップ、失敗の無視、環境のずれ、再現不可能なデリバリーを確認します。
• パッケージングの成功によって、意図したエントリーポイント、アセット、メタデータ、ターゲットプラットフォーム、デプロイ可能な成果物が生成されることを確認します。終了コードがゼロであるだけでは、リリース可能なビルドの証明にはなりません。
• 必須のシグナルを成功しているように見せる、古いスキップ、隔離、失敗許容、エラー時続行、警告抑制の経路を特定します。
• 設定の完全性、必須環境の検証、安全でないフォールバック、サンプルの不足、ローカル、CI、デプロイ設定間の相違を確認します。

3. 保守性と依存関係の監査

• 関数、ハンドラー、モジュール、設定、統合コード全体で、根拠のある重複を見つけます。共有されるドメイン概念と、偶然の類似を区別します。
• 過剰な抽象化、未使用の拡張ポイント、過剰なファクトリーやラッパー、並行する仕組み、宣言済みのプラットフォーム機能を重複して実装するカスタムユーティリティを特定します。
• 重複を統合したり、抽象化を削除したりする前に、ライフサイクルと所有権の境界、意図的な疎結合、依存性注入やテスト用の接点、フレームワーク要件、公開された拡張契約、独立して進化することが想定されているかを確認します。
• 複雑さが集中している箇所、長いメソッド、巨大なモジュール、深いネスト、過剰なパラメーター、真偽値でモードを切り替える API、誤解を招く名前、責務の混在を調べます。
• アルゴリズムについて、早期終了の誤り、重複キーによるデータ損失、境界の誤り、処理量の上限がないこと、スキャンの繰り返し、反復中の変更、隠れた共有状態を確認します。
• 明示的な設定や名前付きポリシーにすべき、ハードコードされた運用値、URL、タイムアウト、上限、識別子、環境固有の動作を確認します。
• 外部契約、DTO、サービス、永続化、ストレージにわたって、ある概念の扱いを追跡します。明示的なシリアライザー、コード生成、ORM の境界マッピングで説明できない場合に限り、同義語の使用や大文字・小文字の不一致を指摘します。
• 依存関係の脆弱性、サポート状況、ライセンスやランタイムの制約、重複パッケージ、未使用パッケージ、妥当な置き換えまたは削除の機会を監査します。
• アドバイザリを解決済みのバージョンとデプロイ環境に照らし合わせ、到達可能性と悪用条件に基づいて、影響を「確認済み」「不明」「該当なし」に分類します。呼び出し経路が利用できないことだけを理由に、影響を受けるコンポーネントを対象外としてはなりません。
• ネイティブ機能、既存の依存関係、外部の代替手段を推奨するのは、必要な機能の同等性、移行の範囲、保守状況、ライセンス、セキュリティ履歴、ドメイン固有の動作を確認した後に限ります。
• 到達不能なコード、未使用のインポートやエクスポート、コメントアウトされた実装、古くなったフラグ、不要になった互換性シム、後継コードの横に残された置き換え前のコードを見つけます。
• 削除が安全だと報告する前に、リフレクション、登録、フレームワークによる検出、設定、シリアライズ、テンプレート、外部エントリーポイントを確認し、不要なコードという指摘を裏付けます。

4. 診断可能性、並行処理、ライフサイクルの監査

• ログが構造化され、適切なレベルで記録され、対応につながる内容であり、リクエストまたはジョブ全体で相関付けられ、秘密情報や過剰なペイロードデータを含んでいないか確認します。
• 相関コンテキストが最初のリクエストログだけに存在するのではなく、外部への呼び出し、キュー、再試行、スケジュールされた処理、分離された非同期処理の境界を越えて引き継がれることを検証します。
• 重要な経路について、メトリクス、トレース、ヘルスシグナル、エラーコンテキストを確認します。運用担当者が障害を検出または診断する必要がある箇所に限って、可観測性を求めます。
• 到達可能な並行処理経路における共有可変状態、ロック順序、原子性、非同期タスクの所有権、キャンセル、再試行、競合が発生するタイミングを追跡します。
• await または yield を挟む読み取り・変更・書き込みを調べ、共有ファイル、サブプロセス、端末や OS のリソース、ユーザー操作の繰り返しについて、リソースとアクセス元のタイムラインを作成します。現在のプロセス外のアクセス元も含めます。
• 非同期経路でのブロッキング I/O または同期的な待機、上限のない並行処理、孤立タスク、デッドロック、TOCTOU の危険性、スレッドセーフでないリソースを確認します。
• 起動順序、依存関係の準備状況、設定の検証、フェイルファスト動作、シグナル処理、グレースフルシャットダウン、処理中の作業の完了を確認します。
• 起動時と実行時に取得するリソースを一覧化し、成功、失敗、タイムアウト、キャンセル、シャットダウンシグナルの繰り返し時に、安全な依存関係の逆順で冪等なクリーンアップが各リソースに対応していることを確認します。
• ホスト固有のプローブの意味を検証します。再起動を正当化するのは liveness の失敗であり、readiness はトラフィックを受け入れる条件を決め、startup チェックは初期化を保護します。依存関係の障害による再起動の連鎖や、大きな負荷や副作用を生じさせるプローブは避けます。

5. 指摘事項の検証と報告

• 外部 API、標準、脆弱性、実行時の挙動について調査するのは、指摘事項の判断が変わり得る場合に限り、該当バージョンに一致する公式情報源を使用します。
• 候補を確定する前に、フレームワークの慣例、生成コード、制約された管理用経路、テスト、例、文書化されたトレードオフを除外します。
• 重大度の高い問題は、可能な限り、安全なコマンド、テスト、最小限の呼び出しトレース、または静的に確認できる障害経路全体を使って再現します。
• 重要性の判定基準を適用します。証拠で裏付けられた規模において、具体的な障害、セキュリティ、デリバリー、運用性、または繰り返し発生する保守への影響があることを求めます。好み、理論上の純粋性、一般論、仮定上の規模、妥当な代替手段は指摘対象から除外します。望ましい実装ではなく、結果または制約を要件とします。
• 外部の修正提案は、バージョンが一致する公式仕様に基づかせ、未解決のトレードオフには一次エンジニアリング情報源を使用します。裏付けとなる仕組みを引用します。ローカルの不具合には、ローカルの証拠で十分です。
• 悪用可能性、データまたは可用性への影響、デリバリーの阻害、再発性、修正の緊急性に基づいて、指摘事項を P0〜P3 に分類します。
• 修正の順序は、ファイル順や検出カテゴリではなく、リスクの低減効果と依存関係に基づいて決めます。
• 信頼できる代替手段がなく、必要な安全な実行環境、高リスクの挙動、または権威ある仕様を検証できない場合は BLOCKED を使用します。証拠のある未解決の P0/P1、必須のデリバリーゲートの失敗、または安全でない挙動が実証されている場合は FAIL を使用します。検証済みでブロッキングではないリスクにのみ CONCERNS を使用し、必要なチェックが完了して重大な指摘事項がない場合にのみ PASS を使用します。

自己チェック

• 返答前に整合性を確認します。 項目ごとの証拠、要件の網羅性、矛盾、スコープ、判定、該当するクリーンアップを確認します。報告または許可された成果物を修正します。有効な証拠を再利用し、リポジトリを自動的に再スキャンしたり、成功済みのコマンドを再実行したりしません。関連する変更、失敗、または未解決の証拠がある場合にのみ、チェックを繰り返します。残る不足事項を明示します。

出力契約

ユーザーの言語で、次の順に報告してください。5つのフィールドをすべて残し、各事実は一度だけ記載してください。結果が少ない場合はフィールドごとに1行で記載してかまいません。空の表は省略し、リンク先の成果物をコピーしないでください。

1. 結果： スキル固有の判定と、裏付けられた結果。
2. 範囲： レビュー／変更した範囲、対象外、ベースライン、重要な前提。
3. エビデンス： 以下のスキル固有の項目。事実、推論、未検証の主張を区別してください。成果物にリンクし、必要に応じて表を使用してください。
4. 検証： チェック／結果、入手できないエビデンス、該当するクリーンアップ／外部状態。
5. 完了： Checklist: X/Y complete。Incomplete: None、または各 UNPROVEN 項目の理由、結果への影響、具体的な次のアクション。残存リスクと必要な判断事項。

スキル固有のエビデンス： セキュリティ、デリバリー、保守性／依存関係、診断可能性、並行処理、ライフサイクルに関するエビデンス。指摘には、優先度、場所、発生条件または失敗経路、確信度、重要な影響、許容できないトレードオフ、最小限の修正と想定工数を含めてください。同等に有効な解決策も認めてください。修正の順序は、検出件数ではなく、前提条件とリスク低減に基づいて決めてください。