コードレビュー/テスト実務の標準準拠マップ

AIエージェント・ワークフローにおけるレビュー・テスト体制を、Google eng-practices / OWASP / ISTQB の語彙で説明する

作成: 2026-07-19 対象: agent-flow-engine + retail-ai-ops-copilot 読者: プロのエンジニア組織

1. エグゼクティブサマリ

本プロジェクトは、AIエージェント(実装・レビュー・テスト設計を担う複数ロール)が人間の承認ゲート(HITL)の下でコード変更を配達するワークフローである。その品質保証層は次の3点で説明できる。

標準準拠

レビュー19観点をGoogle eng-practices・OWASP Top 10(2021)・OWASP LLM Top 10(2025)・CWE・Twelve-FactorへJSON正本上でマッピング。テスト23パターンをISTQB CTFL v4系の標準技法へタグ付け。重大度はblocker〜nitとP0〜P3の対応表1枚で橋渡し。

上回る点

① 証跡境界規律 — 「何を証明していないか」を出力契約(JSON Schema)で強制。② 観点ID運用 — 観点パックのversion+digestをrun開始イベントに束縛。③ 実run実証 — 2026-07-19の実runで13/19観点の識別的選択とISTQBタグ付きテスト5本を実測。

ボトルネック

grader(レビュー品質の自動採点)は採点実績ゼロ。finding受理率などレビュー有効性メトリクスは意図的に未計測。公開ページはJSON正本より古い版を配信中。実run実証はまだn=1。

2. システム概観 — レビュー/テストはどこに座るか

ワークフローは1チケット=1runで次のロール列を通る。

implementer → reviewer → test-designer → integrator ↓ HITL承認 (integration-approval) ↓ 統合 (main push) → 完了終端 → 署名検証

一般的な組織のPRレビュー+CIに対応させると、reviewerがヒューマンレビューの代替、テストパックとその実行がテスト計画+CI、HITL承認がマージ権限に相当する。相違点は、各段の入出力がスキーマ強制されたJSONとして残り、監査可能な証跡になることである。

3. 標準準拠マップ

3.1 コードレビュー19観点 × 業界標準

観点はJSON正本 config/flow-engine/review-perspective-pack-v1.json で管理される(HTML文書は参照側)。各観点は id(不変ID)・standard_mappingmachine_gate(先行する決定論ツール)・llm_focus(機械で確定できない文脈判断)・trigger_paths(発火する変更パス)を持つ。代表例(全19観点は附録A、既存公開ページはコードレビュー観点一覧を参照):

観点標準
P-01 秘密情報ハードコードCWE-798、secret scanning
P-03a 認可・アクセス境界OWASP A01:2021 Broken Access Control
P-04 LLM固有セキュリティOWASP LLM01:2025 Prompt Injection、LLM02:2025 Sensitive Information Disclosure
P-05 結合・責務境界Google code review: design / complexity
P-14 要求適合Google code review: functionality
P-15 可読性・保守性Google code review: naming / comments / style / documentation

設計上の要点は2つ。機械ゲート先行の原則(ツールで検出できるものはツールに任せ、LLMは文脈判断に集中する、というGoogle流の役割分担を観点ごとに明文化)と、Googleのレビュー観点の網羅(eng-practices "What to look for" の主要カテゴリをP-05/07/11/13/14/15でカバー。P-14とP-15は標準に照らした欠落レビューで後から追加された経緯があり、「標準で自分の穴を見つける」運用が機能した実例)。

3.2 テスト23パターン × ISTQB技法

テストパターンはJSON正本 config/flow-engine/test-pattern-pack-v1.json で管理され、各パターンが evidence_leveltechnique_mapping(ISTQB CTFL v4系の標準技法名)・変更クラス別の適用可否と最低テストセットを持つ。登場する技法: 同値分割、境界値分析、状態遷移、デシジョンテーブル、負例、契約テスト、mutation(PIT系)、golden master、フォールトインジェクション、テストダブル、トレーサビリティ確認。パック冒頭にISTQB CTFLシラバスv4.0.1等への参照URLが根拠として残る。既存公開ページのテストパターン一覧も参照できる。

証跡レベル語彙は7種で、テスト結果から主張してよい範囲の上限を表す:

compile-only / static-lint / fixture-unit / contract-test / data-bearing-local / live-integration / user-facing-e2e

ISTQBのテストレベルがテストの対象範囲の分類であるのに対し、この語彙はその結果から何を主張してよいかの分類である点が特徴。

選定の決定論化: 最少3・最多5、同点時は定義順、変更クラス別のmin_requiredにより、テスト選定がLLMの裁量ではなくパック定義で拘束される。ただし限界が1つ実測されている: 実装は選定数が上限5件に達すると後続の変更クラスを打ち切るため、複数クラスが同時に活性な場合にmin_requiredが無警告で脱落し得る(run 10監査で実測。§5-5参照)。

3.3 重大度ブリッジ — 一般語彙との相互運用

一般語彙エンジン重大度blocking規律
blockerP0 / P1する違反した不変条件と影響する主要経路の明示が必須
majorP1 / P2P1のみ主要経路/共有runtimeの欠陥を証拠で示せる場合だけP1
minorP2しない回復可能な局所不具合・改善
nitP3 / surfaceしない文書整合・命名等。自動整形領域はfindingにしない

blocking判定はreviewer本人の宣言ではなくrunner側のコードで導出される。重大度と根拠の構造(違反不変条件・影響経路)が揃った場合にのみ機械的に止まるため、severityインフレというレビュー運用の一般的な劣化モードへの構造的対策になっている。

4. 一般実務を上回る点(証跡付き)

4.1証跡境界規律 — 「何を証明していないか」を出力契約で強制する

reviewerの出力契約は unproven_scope(未証明範囲)、overclaim_findings(過大主張の指摘。証跡レベルの無断昇格 evidence_escalation を分類として持つ)、worker_claimed_evidence_level を必須項目とするJSON Schemaで検証される。test-designerも skipped_tests(理由必須)、carried_unproven_scopeoverclaim_risks を必須で持つ。

実測例(run 10): テスト設計出力は「local modeの成功をSnowflake実接続成功の証拠として扱わない」等のoverclaim回避4件、理由付きskip 4件を明示。integrator判断にも「Slack HTTP receiptは送信成立だけを示し、受信者の閲覧・理解は未証明」という境界記述が残る。一般実務でこれに相当するのはテスト計画書の「対象外項目」節や熟練レビュワーの慎重な言い回しだが、属人的文化でありスキーマで強制されない。ここでは過大主張が構造的に書けない

4.2観点ID運用 — レビュー構成そのものを監査可能にする

観点・テストパックはJSONが単一の正本(SSOT)。各runの開始イベントの config_identity.knowledge_packs に、パックのversionとsha256 digestが束縛される(run 10実測: review pack = sha256:10e972d0…、test pack = sha256:b7d9e16e…)。観点の選択は変更パス×trigger_pathsの決定論で行われ、findingは観点IDへ構造帰属する(reviewer契約v3でperspective_idフィールド化)。

レビューチェックリストを持つ組織は多いが、チェックリストのバージョンを個々のレビュー実行に紐付けて追跡する組織は稀。ここでは観点定義の改訂とレビュー結果が同じ証跡チェーンに乗る。

4.3実run実証 — 設計ではなく実測で語れる

2026-07-19、実チケット(RAIOPS-10: HITL画面警告文言の日本語first化)を対象に観点パック適用後の初runが完走(run ID: phase4b-pilot-raiops-10-20260719-01)。

項目実測値
観点選択19観点中13観点が変更パスから選択(P-01, P-02, P-03a/b, P-04, P-05, P-06, P-08b, P-09b, P-11, P-12a, P-14, P-15)。全部盛りではなく識別的選択が動いた。この選択はマッチャー意味論を独立に再実装した第三者検算で期待集合と完全一致を確認済み(除外6観点も全て正当)
レビュー結果outcome = no_blocking。P2 finding 1件 — 新設の非sensitive系safe-stop文言分岐に直接テストがない、という指摘。該当パス・行番号・根拠・影響経路・checker候補付き。指摘の実在性は統合後コードとの照合で確認済み(該当文言はapp.py:151にのみ存在し、参照するテストが無い)
未証明範囲4件明示(実ブラウザ表示、credential欠落時の実行時挙動、remote状態 等)
テスト設計TP-13 / 12 / 15 / 03 / 02 を知識源とする5本(選定上限どおり)。各テストに期待証跡レベル。負例4・境界5・失敗時artifact期待5・skip理由4
統合人間の一回性承認後、retail main へ統合(commit c6588d4。remoteのfresh cloneで実在確認済み)
終端検証terminal_result = success、HMAC署名付きprocess receipt生成

findingの中身も象徴的で、「実装は正しいがテストが分岐を1本カバーしていない」という、Google eng-practicesがtests観点で求める典型的な指摘である。

5. ボトルネック(自己申告)

  1. grader(自動採点)は撤去を裁定 採点値の実生成が稼働以来0件のまま実証runとエンジン修正を要求し続け、採点値の消費者も不在だったため、2026-07-20のオーナー裁定で撤去(過剰ハーネス回避の設計思想との整合判断)。品質評価は記録が継続する一次データ(観点別結果・findings・選定/脱落記録・producer identity readback — 2026-07-20 runで実証済み)の直読みと後日集計で行う。定量メトリクスが無いのではなく、採点レイヤーを持たない選択をした
  2. 受理率計測を開始 finding受理率・有用率(Googleの "usefulness" 系指標)の後日集計を2026-07-20に開始。初回ベースライン(n=2 run・findings総数1): 受理率1/1、有用率1/1、偽指摘0、記録済み脱落起因の事後不具合0。意味的品質のrubric評価(9軸・根拠引用必須・評価者独立)も2 run分を実施し、run 10のテスト設計に当時のエンジン契約起因の欠陥(脱落反映T3:0点)を遡って可視化した。母数極小のため統計ではなく集計パイプラインの確立の段階。
  3. 公開面の遅延 → 解消済み(2026-07-19)。旧版配信を実測後、同日中に観点別standard_mapping・技法タグ・evidence_level・出典リンクをHTMLへ投影し(retail a725ba6)、commit ad7ede0 を既存Cloudflare経路でデプロイ。7ページのsource equivalence PASS+canonical URLの独立フェッチで19観点・23パターン・標準名の表示を確認済み。
  4. 実証はn=2 実runはRAIOPS-10(07-19)とRAIOPS-34(07-20)の2回。後者はfail-closed起動拒否・pack digest束縛・pack由来観点選択(6/19)・正本順選定・dropped_min_requiredの実記録・人間approve後の成功終端+署名検証まで一巡を実証。統計的主張にはなお不足で、実run数を積む以外の近道はない。
  5. 選定cap截断 run 10監査で実測: テスト選定が上限5件に達すると、パス由来クラス(product/test/checker)のmin_required(TP-11 fixture/unit regression等)が無警告で脱落する。run 10ではcap截断で外れたTP-11が担うはずの検証(新分岐の直接テスト)をreviewerが同runで指摘しており、截断の不可視性リスクを示した(「記録済み脱落→事後不具合」の実測は初回集計時点0件で、脱落と実害の相関はデータ上未実証)。パックのtie_break宣言と実装の走査順の食い違いも併発。→ 2026-07-19に修正済み(engine 02acb529ed2d5e / retail b61ff4d): 走査順はpackキー順へ、脱落はdropped_min_requiredとして記録、パック適用自体もfail-closed化。remote独立検証済み。2026-07-20のRAIOPS-34 live runで脱落記録の非空実記録までE2E実証済み。

6. まとめ — この体制は何と言えば伝わるか

一言で言えば、「Google eng-practicesの観点分離とOWASP/ISTQBの標準語彙を、AIレビュワーの出力契約として機械可読化し、観点定義のバージョンごとrun証跡に焼き込んだレビュー・テスト体制」である。

附録A: コードレビュー19観点の全対応表

ID観点名標準マッピング機械ゲート(先行)
P-01secret-hardcode-reviewerCWE-798、secret scanningsecret scanning、credential literal scan
P-02config-hardcode-reviewerTwelve-Factor App: Configconfig schema validation、env-reference lint
P-03asecurity-logic/access-controlOWASP A01:2021、Google: functionalityauthorization contract tests、input schema validation
P-03bsecurity-logic/sast-scaOWASP A03:2021、SCASAST、SCA、dependency audit、parameterized-query lint
P-04llm-security-reviewerOWASP LLM01:2025、LLM02:2025prompt injection fixtures、tool allowlist、output validation
P-05coupling-boundary-reviewerGoogle: design / complexitydependency direction lint、cycle detection
P-06availability-resilience-reviewerresilience patterns、fault tolerancetimeout/retry/idempotency tests、failure-artifact contract
P-07concurrency-race-reviewerGoogle: functionality(並行性)race/idempotency tests、transaction tests
P-08ascale-nfr/requirementsperformance engineering、NFRNFR schema/checklist、benchmark threshold
P-08bscale-nfr/codeperformance engineering、Google: complexityperformance smoke、query profile、N+1 scan
P-09adata-kpi-correctness/contractsdata contract testingschema tests、dbt tests、semantic contract validation
P-09bdata-kpi-correctness/evaluationgolden dataset evaluationgolden evaluation、semantic validator
P-10compatibility-migration-reviewerbackward compatibility、API versioningcontract compatibility tests、migration/rollback tests
P-11test-gap-reviewerGoogle: teststest execution、coverage、negative/mutation fixtures
P-12apii-logging/privacyOWASP LLM02:2025、OWASP A09:2021redaction tests、PII/log scan、secret scan
P-12bpii-logging/diagnosticsOWASP A09:2021、observabilitytrace contract tests、failure artifact parity
P-13architecture-intent-boundaryGoogle: design、ADRcontract/schema validation、architecture lint
P-14requirement-conformance-reviewerGoogle: functionalityacceptance criteria readback、brief/config identity validation
P-15readability-maintainabilityGoogle: naming / comments / style / documentationformatter、lint、documentation link check

附録B: テスト23パターンの技法対応表

IDパターン名証跡レベル技法マッピング
TP-01dbt parse / compile --emptycompile-onlystatic testing、configuration validation
TP-02runtime failure artifact paritycontract-testnegative testing、状態遷移、contract testing
TP-03live trace runner boundarylive-integrationintegration testing、negative testing、fallback-path
TP-04RBAC / LLM-safe / cost guardrail contractcontract-testnegative testing、同値分割、contract testing
TP-05dbt schema / generic / singular / static gatedata-bearing-localdata contract testing、同値分割、invariant testing
TP-06rate KPI mutation / denominator-zero guardcontract-testmutation testing、境界値分析、negative testing
TP-07Backlog / Slack private simulationfixture-unittest doubles、negative testing、idempotency
TP-08diagram quality lintstatic-lintstatic testing、visual contract testing
TP-09feedback reflection lintstatic-lintstatic testing、traceability testing
TP-10workflow state vocabulary lintstatic-lint状態遷移テスト、contract testing
TP-11fixture/unit regressionfixture-unit同値分割、境界値分析、unit testing
TP-12Streamlit component smokefixture-unitcomponent testing、scenario testing
TP-13Streamlit browser E2Euser-facing-e2eend-to-end testing、scenario testing、状態遷移
TP-14Golden Eval / answer qualitydata-bearing-localgolden master testing、regression testing
TP-15integration evidence freshnessstatic-linttraceability testing、consistency checking
TP-16HTML parse / link / local previewstatic-lintstatic testing、navigation contract testing
TP-17SCA / dependency vulnerability scanstatic-lintsoftware composition analysis、static testing
TP-18reviewer defense fixture / Promptfoo redteamcontract-testnegative testing、adversarial testing、mutation
TP-19NFR placeholder / performance load smokedata-bearing-localperformance testing、境界値分析
TP-20idempotency key / external API fault injectioncontract-testfault injection、状態遷移、negative testing
TP-21Golden Eval two-layer / dbt unit testsdata-bearing-localgolden master、unit testing、regression
TP-22AI_OBSERVABILITY_EVENTS comparison ADRcontract-testデシジョンテーブル、traceability、contract testing
TP-23pre-commit formatting layer / review separationstatic-lintstatic testing、consistency checking

附録C: run 10で設計されたテスト5本

テストID知識源目的(要約)期待証跡レベル
T-01TP-13実ブラウザでHuman Review画面の日本語first警告を確認(skip 0)user-facing-e2e
T-02TP-12承認待ち/safe-stop fixtureのcomponent renderで警告文言を固定fixture-unit
T-03TP-02credential欠落時のsafe-stop契約と失敗artifactの項目整合contract-test
T-04TP-03明示的local mode実行とcredential欠落safe-stopの経路分離(暗黙fallback禁止)live-integration
T-05TP-15結果artifactを対象commit・設定・skip数へ対応付け、古い証跡を除外static-lint

付随して負例4件(NC-01〜04)、境界5件(BC-01〜05)、失敗時artifact期待5件、理由付きskip 4件(実Snowflake接続・実外部送信・公開デプロイ・push検証)が設計された。

附録D: 用語集(最小)