AI DEVELOPMENT CORE GUIDE / 03
Independent QCとは。実装と検証を別runtimeへ分離する
同じruntime・contextで実装と検証を続けると、実装時の前提や見落としを検証側にも引き継ぎやすくなります。Netsujoでは実装者と独立検証者を分け、同じ対象版を別runtime・別contextから確認します。
Independent QCはNetsujoの運用上の呼称です。特定の業界規格や認証制度を示す名称ではありません。
実装runtime
コード変更、テスト追加、修正、PR更新などを担当します。自分の変更について説明できますが、その説明だけで独立受入は成立しません。
QC runtime
対象版とEvidenceを読み、要件・安全境界・回帰・過剰な主張を独立に確認します。原則としてread-onlyで確認できる範囲を優先します。
Independent QCの受入条件
対象IDが同じ
review対象のCommit SHA、artifact、Deployment IDなどが実装側の受入対象と一致している。
runtime / contextが独立
実装を行った実行環境の自己判定をIndependent QCとして扱わない。別runtime・別contextから読み取る。
Evidenceを直接読む
「テスト済み」という説明だけに依存せず、diff、CI、ログ、readbackなど確認可能なEvidenceを読む。
HEAD変更で再受入
レビュー後に対象HEADが変わった場合、以前のPASSを新しい版のPASSとして流用しない。
Exact HEADを固定する
PR番号だけでは検証対象を一意に決められません。レビュー開始時にHEAD SHAを固定し、そのSHAへCI・レビュー結果を結び付けます。修正commitが入れば新しい対象です。再検証が必要かを受入条件から判断します。
採用できるEvidence
exact HEADに対するHosted CI、独立レビュー、固定artifact hash、対象Deploymentのreadback。
そのまま流用しないEvidence
旧HEADのPASS、対象が不明なスクリーンショット、実装者の自己申告だけのQC結果。
CI・Independent QC・Production acceptanceは役割が違う
CI
定義された自動検証を実行する。再現性と回帰検知に強い。
境界: レビュー文脈や設計上の過不足までは自動で保証しない。
Independent QC
別runtime・別contextから対象版とEvidenceを確認する。
境界: Deploy権限や公開権限を自動的に得るものではない。
Production acceptance
公開先の実状態を確認する。HTTP、画面、機能、外部状態などを読む。
境界: CIやQCの代替にはしない。公開後に初めて確認できる事実を扱う。