CI/CD ゲート構成リファレンス

参照モデルの原則「合意済みルールはすべて機械化して CI に載せ、人の目を通さない」を実装します。人間の検証帯域を判断業務に温存するための、最重要の実装ポイントです。

G-5(自動検証)のパイプライン構成

graph LR
  PR["PR 作成(AI実装+テスト)"] --> T["テスト実行"]
  T --> S["静的解析・脆弱性"]
  S --> C["カバレッジ判定"]
  C --> W["仕様の曖昧語検査"]
  W --> V["データ・様式検証"]
  V --> I["知財潔白性の検査"]
  I --> K["秘匿情報の混入検査"]
  K --> D["依存の追加・更新の出力"]
  D --> G["gate-g5: 判定集約"]
  G -->|全通過| M["マージ可能(G-6 独立レビューへ)"]
  G -->|1つでも失敗| X["マージ不可(差し戻し)"]

GitHub Actions での骨格例:

name: gate-g5
on: [pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci && npm test -- --coverage
      - name: カバレッジ判定(新規コード80%目安・組織で調整)
        run: npx coverage-check --threshold 80
  static-analysis:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: 静的解析・脆弱性(Critical/High は 0 件で失敗させる)
        run: |
          npx eslint . --max-warnings 0
          npm audit --audit-level=high
  spec-lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: 機能仕様の曖昧語検査(禁止語リスト)
        run: npx textlint "specs/**/*.md"
  ip-clearance:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: 依存関係のライセンス検査(合否条件・G-5 基準5)
        run: |
          npx license-checker --production --summary
          npx license-checker --production --onlyAllow "$ALLOWED_LICENSES" --excludePrivatePackages
        env:
          ALLOWED_LICENSES: 'MIT;Apache-2.0;BSD-2-Clause;BSD-3-Clause;ISC'
      - name: 類似の検知(記録のみ・合否条件にしない)
        continue-on-error: true
        run: node scripts/similarity-scan.mjs --out evidence/ip/similarity.json
      - uses: actions/upload-artifact@v4
        with:
          name: ip-clearance-${{ github.event.pull_request.number }}
          path: evidence/ip/
  secret-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - name: 秘匿情報の混入検査(G-5 基準7・検出で失敗させる)
        run: npx secretlint "**/*"
  dependency-diff:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: 依存の追加・更新を PR へ機械出力(G-5 基準8)
        run: node scripts/dependency-diff.mjs --base origin/main --comment
  gate-g5:
    needs: [test, static-analysis, spec-lint, ip-clearance, secret-scan, dependency-diff]
    runs-on: ubuntu-latest
    steps:
      - run: echo "G-5 all green"

• 最後の gate-g5 ジョブが、ルールセットの必須ステータスチェック名になる(Git 戦略と対応)
• 曖昧語検査は、語の部分一致で実装する。検出語の正本は第4章 G-2「曖昧語(基準2)」の表である。準拠テンプレートは、表を複製した知識ベースを spec-lint が読む。検査の範囲は、機能仕様の受入基準の節に限る。理由を書いた除外の印の行は検出から外し、件数と所在を結果に出す
• 曖昧語検査の範囲は、受入基準を持つ機能仕様の置き場に限る。判定記録・体制図・様式のように受入基準を持たない文書は含めない。含めると、初期化の直後から G-5 が落ち、受入基準の曖昧さを検出する目的(第4章 G-5 基準4「仕様変更を含むPRの場合」)から外れる(#286 の通しの検証で、様式の語が初回の G-5 を止めた)。CI と手元で同じ範囲を見るよう、手元の既定の範囲を CI と同じにする

知財潔白性の2つのジョブを分ける

ip-clearance の中で、合否条件にするステップと記録だけを残すステップを分けています。設計の根拠は第4章 G-5によります。

ステップ	扱い	理由
依存関係のライセンス検査	失敗させる(合否条件)	実務として確立しており、判定材料が観測可能な事実に限られる
類似の検知	continue-on-error: true で失敗させない。成果物として保存する	検知に完全さを期待できない。失敗しなかったことを潔白の根拠にしないため

• ALLOWED_LICENSES は案件ごとに定める。許可リスト方式にする。禁止リスト方式では、リストにない新しいライセンスが素通りする
• ライセンスを判定できない依存が残る場合、技術負債台帳(テンプレ3)へ記録して通過させる。判定できないことを隠して通過させない
• 類似の検知の実装は、利用する AI サービスが提供する機能、または独立のツールによる。本標準は特定の手段を指定しない。指定すると、手段の提供条件が変わったときに規定が破綻する
• 生成した記録は成果物として保存し、出荷判定(G-7)のエビデンス集約へ渡す(G-7 判定基準8)

秘匿情報の検査は履歴の全体を対象にする

fetch-depth: 0 を指定しているのは、差分だけを検査すると過去のコミットで混入した値を見落とすためです。混入した資格情報は、削除するコミットを積んでも履歴から取り出せます。

• 検出時の一次対応は当該資格情報の無効化である。実装の修正を先に行わない(第4章 G-5 基準7)
• 検査の除外設定を、リポジトリの利用者が個別に追加できる状態にしない。除外の追加は統制側の承認を要する
• 全履歴の走査は実行時間を要する。PR 契機では差分、週次では全履歴、という二段構成でよい

依存の追加を PR の記述へ出力する

dependency-diff は合否を判定しません。追加・更新された依存の一覧を PR へ出力し、独立レビュー(G-6)の確認対象にすることが目的です。

出力する項目	用途
追加・更新されたパッケージ名と版	追加の必要性の確認
直接依存か推移的依存かの区別	意図しない取り込みの検出
各パッケージのライセンス	基準5の判定結果との突合

ライセンスの適合は ip-clearance が機械判定します。この出力を読んでライセンスを人間が判定させる運用にしないでください。判定の場が二重になり、機械判定の結果が参考値へ格下げされます。

PR 単位の検査(pr-rules)

準拠テンプレートの gate-g5 は、PR ごとに pr-rules のジョブを走らせます(#286)。指示文だけに依っていた規則のうち、PR の差分と本文から機械で判定できるものを、ここで止めます。実装は scripts/gate/check-pr.mjs、試験は scripts/gate/test-check-pr.mjs(一時のリポジトリで場面を作るフィクスチャ。contract のジョブが毎回実行する)です。

検査	扱い	通す場面	落とす場面
トレーラ Spec:	失敗させる	製品のコードを変えない PR(文書・記録・強制層・構成だけ)。依存の更新の bot の PR。変更が開発の基盤(設定・ツール・雛形のファイル)だけに収まり、トレーラが Spec: setup の PR	本文に Spec: F-NNN / Task-N が無い。末尾の段落に無い。形式が違う。指す仕様・実装計画のタスクが無い。Spec: setup なのに製品のコードを含む
変更規模の基準値(ADR-0058)	超過そのものは失敗にしない。size:over を付け、区分の下限を R2 へ引き上げる	算定の対象が基準値の内。超えていても、PR の本文の「規模の確認」(実施者・読み切れたか・分割しなかった理由・保証の所在)が成立している。担保水準 L1 以上の宣言に根拠が実在すれば、保証の所在だけでよい。基底の台帳に有効な例外承認の行がある。基底の構成が未設定の初回	超過し、「規模の確認」が無い。実施者が AI の名義。「読み切れたか」が「いいえ」。区分が R2 の下限より低い
閾値・除外設定と製品のコードの同時変更(禁止事項6)	失敗させる	閾値・除外設定だけの PR。基底に無い設定のファイルを足す初回の設定。基底の構成が未設定	基底にある閾値・除外設定のファイル、または構成の ci・task・guard と、製品のコードが、同じ PR でともに変わった
リスク区分	失敗させる	本文の「リスク区分」の節に R1 / R2 / R3 のいずれか1つだけが残っている	節が無い。区分の記載が無い。選択肢を2つ以上残している。変更の種類に依らない(文書・記録だけの PR、Spec: setup の PR、依存の更新の bot の PR を含む)
既存のテストの変更	失敗させない。PR のコメントとジョブの要約へ一覧を出す	—	—
区分の下限と確定者(第3章 3.8.1「区分の下限と確定者」。#288 第2巡)	失敗させる	記載した区分が、基底ブランチの構成の riskFloor.rules(パスと変更の種類)から導いた下限以上。R1・R2 で、「リスク区分」の節の 確定した者: <氏名> が作成を指示した者以外の名簿の人(AI の名義でない)。作成を指示した者以外の人が名簿にいない体制(1名体制)では、確定者が無くても失敗させず、確定していない区分として出す	記載した区分が下限より低い。riskFloor と製品のコードが同じ PR で変わった(riskFloor を変える PR の下限は R2)。R1・R2 で確定した者が無い・AI の名義・名簿の人でない・作成を指示した者である
停止の申し立て(第7章 7.11)	失敗させる(保留)	ラベル state:stop-requested も、付けた履歴も無い。基底ブランチに、成立した解除の記録がある	ラベルが付いている。またはラベルを付けた履歴があり、その日以後の成立した解除の記録が基底ブランチに無い。PR の中で足した解除の記録は数えない

設計の要点は次のとおりです。

• 基準値と、台帳の例外承認の行は、基底ブランチから読む。PR の中で基準値を上げる、task.nonProductPaths を足す、台帳へ自分の例外を足す、という形で検査を通せないようにするためである。基準値と置き場の変更は、閾値として扱い、製品のコードと同じ PR にできない。判定の材料を、判定される側が同じ変更で用意できない形にする
• 変更規模は製品のコードのファイルごとの max(追加, 削除)の合計で数える。テスト・fixture・snapshot は別に数え、基準値の判定に入れない。文書・記録・強制層・構成、ロックファイル、生成物(基底ブランチの .gitattributes の linguist-generated、または基底で生成の印を持つファイル)、空白だけの変更、内容の変わらない名前の変更を、算定から除く。第4章「タスクの分割基準」の除外規定のうち、機械が識別できるものを実装した
• 基準値を超えた変更は、遮断せず、規模の確認と区分の下限 R2(独立した人の確認)で通す。確認が取れない超過だけを止める。超過した変更も較正の母集団へ届き、出荷の集約が規模の分布・size:over の件数・「読み切れたか」の内訳・判定完了時間を出す。基準値へは自動で反映しない(ADR-0047の趣旨を、ADR-0058が実行層へ揃えた)
• トレーラは、スカッシュのコミットのメッセージになる PR の本文の末尾の段落で見る。コミットごとには見ない。PR の様式は、Spec: を末尾の「トレーラ」の節に置く。リポジトリのスカッシュの設定を「PR の題名と本文」にすると、出荷判定の証跡の集約と next.mjs が、その行をトレーラとして読む
• Spec: setup は、初期化の直後に足すテストの実行・カバレッジ・秘匿情報の検査の設定のように、仕様とタスクをまだ持たない基盤の変更を通すための経路である(#286)。基盤のファイルの一覧は check-pr.mjs の SETUP_FILES が持つ(package.json・pyproject.toml・go.mod・tsconfig*.json・.gitkeep など)。製品のコードを1つでも含めば通さない。基盤の変更を通すために仕様とタスクを作らせる運用は、仕様の置き場を形骸化させるため採らなかった
• 既存のテストの変更を合否に使わない理由は、テストを先に書く作業と、受入基準の変更に伴う正当な書き換えを区別できないためである。理由の欄を必須にする案も採らなかった。AI の担い手が欄を埋められ、担保にならないためである。一覧は独立レビュー(G-6)の材料として渡し、レビュアが受入基準の変更との対応を確かめる
• リスク区分の未記入は、変更の種類に依らず失敗させる(#286)。区分は変更ごとに確定する記録であり(第3章 3.8.1)、出荷判定の証跡の集約は同じ読み方で未記入を欠落にする。文書だけの PR を対象から外すと、未記入がマージの後の集約で初めて見つかる。判定を前へ移しただけで、基準は変えていない
• PR の題名と本文は、環境変数でスクリプトへ渡す。シェルへ展開しない。本文を直したときに再実行するため、gate-g5 は pull_request の edited でも走る
• 停止の申し立ては、受信箱のラベル state:stop-requested で表す(#288)。誰でも付けられ、どのロールの引き渡しのラベルにも含め、事業決裁者の受信箱に置く。gate-g5 は labeled・unlabeled でも走る。ラベルの付け外しの履歴(issue の events)をワークフローが取得して渡し、ラベルを外しただけでは保留が解けないようにする
• 解除の記録は、ゲート判定記録の様式(テンプレ4)の節「停止の申し立ての解除」で書く。ゲート欄を「停止の申し立ての解除」、対象を PR #<番号> とする。新しい台帳を作らない。例外承認の行と同じく、基底ブランチの記録だけを読む。保留された側が、同じ変更で解除の材料を用意できない形にする
• 解除する者は、基底ブランチの層1(docs/quality-assurance-policy.md)の項目4「停止の申し立ての解除」の受容者の席の責任者と照合する。層1 が無い、または行の受容者が空欄の組織では、事業決裁者の席の責任者と照合し、その旨を出す。AI の名義を受け付けない。申し立てた者の見解を退けた解除は、上申先と日付を要する。解除の日がラベルを付けた日より前の記録は数えない

機械で閉じていないものも開示します。

• 印の無い生成物と、機械的な変換(一括のリネーム・移行)は、算定に入る。例外承認か、印を先に基底へ入れる経路を使う
• 依存と設定を兼ねるファイル(package.json・pyproject.toml など)の中の閾値は、同時変更の検査の対象にしない。閾値・除外設定のファイルの一覧は、check-pr.mjs の既定とアダプタの thresholdFiles で持つ
• PR の時点で確かめる例外承認の行の欄は、状態・承認した者(名簿の人、AI の名義でない、PR の作成者でない)・理由・期限である。作成を指示した者の全員との照合と、承認の権限は、出荷判定の証跡の集約と内部監査が確かめる
• リスク区分の検査が見るのは、記載が1つに定まっているか、記載が区分の下限(基底ブランチの構成の riskFloor.rules)より低くないか、R1・R2 に作成を指示した者以外の名簿の人の「確定した者」の記名があるかまでである(#288 第2巡)。区分が変更の内容に照らして正しいかは見ない。下限の規則の網羅は主張しない。規則に当たらない R1 相当の変更は、指示した者の記載どおり R3 として通りうる(保証の開示の項目3 の自己記載の件数に出る)
• 区分の下限の規則は /process-change(種別 settings の riskFloor)で置く。下限を下げる・規則を削る・対象のパスを外す変更は緩める向きで、D-0 表1「体制と運用形態」の決定者の記名と理由を要する。規則の起案者(技術判断者)と承認者(AI維持管理者)の記名は、機械では見ない
• 依存の更新の bot の PR は、本文に様式を持たないため、人がリスク区分を本文へ書くまで失敗する
• pull_request の edited による再実行は、実際の GitHub 上では確かめていない
• Spec: setup の基盤のファイルの判定はファイル名による。package.json の中にスクリプトとして製品の処理を書く変更は、基盤の変更として通る。中身は G-6 で確かめる
• ブランチ保護(必須チェック)が適用されていなければ、失敗した PR もマージできる。私有リポジトリでルールセットを使えるかは、GitHub のプランに依る。使えない場合は、出荷判定の証跡の集約が、gate-g5 の成功を持たない PR(結果の記録が無い PR を含む)を事後に欠落として検出するだけになる
• 停止の申し立ての検査は、pr-rules のジョブの中にあるため、プロセス構成が未設定のあいだは働かない。PR でない対象(リリース、自律実行)の保留は機械で強制しない。ラベルの履歴を取得できなかった場合は、現在のラベルだけで判定する(外したラベルの申し立ては検出しない)
• 解除の記録が事実と合うか、申し立てた異常の内容の妥当性、解除の理由の妥当性は判定しない。比べる日付は日の単位であり、同じ日に付け直した申し立ては、同じ日の解除の記録で解ける
• ラベルの付け外しを契機とする再実行と、ラベルの履歴の取得は、実際の GitHub 上で確かめていない

独立レビュー(G-6)への引き継ぎ

G-5 のパイプラインでは、独立レビュアが読むレビューパッケージも生成します。生成は機械的な導出に限り、要約と評価を含めません。提示の順序に制約があるため、構成と生成方法は当該ページに規定します。

ゲートの前提条件を機械検査する(D-0 の統制)

第4章が区別する「前提条件」は、判定基準と違って人の判断を介在させません。整っていなければ審議を開始しない、という二値の検査です。

企画承認(G-1)の前提条件である意思決定・エスカレーション体制図(D-0)を例に、構成を示します。

<!-- docs/governance/P-042-d0.md の frontmatter -->
---
project_id: P-042
version: v1.2
approver: <氏名>
approved_at: 2026-08-05T10:30:00+09:00
approval_scope: 権限配分と通知経路への合意
next_review: 2026-11-05
---

# .github/workflows/gate-entry.yml(構成例)
name: gate-entry
on:
  pull_request:
  schedule:
    - cron: '0 0 * * 1' # 週次で期限切れを検出する
jobs:
  d0-check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: D-0 の存在・承認・有効期限を検査
        run: node scripts/governance/check-d0.mjs

検査する内容は次のとおりです。

#	検査	失敗時の扱い
1	案件IDに対応する D-0 ファイルが存在する	G-1 の審議を開始できない
2	approver と approved_at が空でない	同上
3	next_review が未来日である	ステージ移行ゲート(SG)の判定を開始できない
4	表5(役割と現任者の対応)の空欄がない	同上

期限切れの検出を週次で回すことが要点です。前提条件を PR 契機だけで検査すると、変更のない案件の D-0 は永久に検査されません。

承認記録を監査証跡として成立させる

第6章 テンプレ0が求める記録要件を、Git の機能へ対応づけます。

記録要件	実装
承認者を後から同定できる	所有者定義ファイルで決定者を指定し、所有者のレビューを必須にする
承認の日時が記録されている	承認 PR のマージ日時
承認が何に対するものかが明記されている	PR 様式に承認の対象と意味を記載させる
変更の履歴が保持される	版管理。過去の版を書き換えない
改ざん耐性	署名済みコミットのみを許可する設定(規制対象の場合)

アカウントと実在する人物の対応表は、リポジトリの外側で保守します。この対応表がない場合、承認者の同定は成立しません。

「人が毎回指摘すること」を CI へ移す運用

CI ゲートは一度作って終わりではなく、独立レビューの指摘を吸い上げて成長させます。

graph LR
  R["独立レビューで同種の指摘が3回"] --> L["ルール化を検討"]
  L --> CI["リンタールール / カスタム検査として CI へ追加"]
  CI --> F["以後、人はその観点を見なくてよい"]

• 目安は「同種の指摘が3回出たらルール化を検討」。レビューコメントのラベル付け(rule-candidate)で候補を収集する
• 逆に、機械化できない指摘(設計の妥当性・仕様との一致)こそが人間のレビューの本務として残る

様式・データの検証もゲートに載せる

成果物テンプレートの様式は、CI で検査できます。

検査対象	方法	落とす条件
機能仕様書	frontmatter・必須節の存在チェック+曖昧語検査	必須欄の欠落、禁止語の使用
負債台帳	スキーマ検証(列の欠落・状態の不正値)	様式違反
コミット	トレーラ検査(Spec: / Co-Authored-By:)	参照の欠落(規制業テーラリング時)
プロセスデータ	スキーマ検証(Zod 等の型定義)	型違反でビルド失敗

ノート

本サイト自体がこの構成の実例です。日本語文書は textlint、内部リンクはビルド時検証、プロセスデータは Zod スキーマで検査され、どれか1つでも失敗すると npm run check が落ちます。「合意したルールの機械化」はドキュメントプロジェクトでも同じ形で機能します。

出荷判定(G-7)エビデンスの自動集約

出荷判定を「記録の突合」に限定するには、突合対象が自動で揃っている必要があります。ブランチ保護(ルールセット)が実環境で効いていること、PR のレビューを G-5 が読めること、集約が gate-g5 の成果物を取り込めることは、採用の前に採用者が実環境で確かめます(附属書I I.11 要件⑦。準拠テンプレートの adoption-trial env-check)。確かめていない間は、保証の開示の項目4 に「実環境の統制 未確認」と出続けます。

name: ship-evidence
on:
  push:
    tags: ['v*']
jobs:
  aggregate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: エビデンス集約(前タグからの差分に対して)
        run: node scripts/aggregate-evidence.mjs --from "$(git describe --tags --abbrev=0 HEAD^)" --to "$GITHUB_REF_NAME"
      - uses: actions/upload-artifact@v4
        with:
          name: ship-evidence-${{ github.ref_name }}
          path: evidence/

集約スクリプトの入出力仕様

対象範囲: 前リリースタグ(--from)から今回タグ(--to)までにマージされた全 PR と、PR を経ていないコミット。

• コミットを PR の変更として扱うのは、そのコミットが当該 PR のマージコミットと一致する場合に限る。件名に (#N) を持つコミットでも、PR #N のマージコミットと一致しなければ、PR を経ていないコミットとして扱う。件名へ番号を書くだけでは、承認済みの PR の変更に数えない
• マージコミットを取得できない PR の番号を件名に持つコミットも、PR を経ていないコミットとして扱い、その旨を表示する
• 取り消しのコミット(件名が Revert "… (#N)" の形になる)も、同じ規則で扱う。取り消しが別の PR を経ていれば、その PR の変更として数える
• 構成の初期化の記録(changeLog[] の1件目)より前の履歴(pre-init)は、変更の件数に数えず、欠落にもしない。製品のコード(記録の置き場の外)を変えたコミットは、件数を保証の開示の項目1・5 に出し、品質レポートに一覧を出す。テンプレート由来の初期コミット(親を持たず、テンプレートのファイルだけを持つもの)は、一覧から除いて件数だけ出す

PR の記録は gh で引きます。リポジトリは、--repo <owner/name>、環境変数 GITHUB_REPOSITORY(CI)、git remote の GitHub の URL の順に決めます。手元で決まらない場合は、その旨と、件名に PR の番号を持つコミットをすべて PR を経ていないコミットとして数えたことを、欠落として出します。PR の記録を取得できなかった変更には、gh が返した理由を添えます(#286 の通しの検証で、手元の集約が全 PR を欠落にし、原因を読めなかった)。

入力(4系統):

系統	取得内容	取得手段
GitHub API	対象 PR のマージコミット、PR 本文(作成を指示した者・リスク区分・検証方法と結果)、G-6 承認記録(レビューしたアカウント・レビューの状態・本文・日時)、必須チェック(gate-g5)の結果	gh(トークンはワークフローの GITHUB_TOKEN)
CI 成果物	カバレッジの測定結果、依存の追加・更新の出力、依存関係のライセンス検査の記録、欠陥注入による検出率の記録	各ワークフローが保存した artifact / JSON。準拠テンプレートでは、ライセンス検査の記録(license-scan)を、出荷の対象のコミットに対する gate-g5 の成功した実行から gh run download で取り込む(actions/download-artifact は同じ実行の成果物しか取れない)
リポジトリ内の記録	技術負債台帳(区分・状態・例外承認の行)、ゲート判定記録、運用引き継ぎ文書の有無、構成(process.config.json)と変化点の記録	固定様式(テンプレ3・4・5)の Markdown をパース
コミット	トレーラ(Spec・Delegated・Co-Authored-By・Risk・Verification)、変更したファイル	git log

準拠テンプレートの集約が取り込んでいないものがあります。テストの計画数と消化数、未解決の欠陥の件数、静的解析と脆弱性の指摘件数、統合検証(非機能)の判定結果、類似の検知の記録です。これらに対応する G-7 の基準は、機械では確かめていません。出荷判定者が記録と突合します(後掲「判定基準との対応」)。

出力(3ファイル、evidence/ 配下):

• evidence.json — 機械可読の集約結果。ダッシュボード・監査ツールの入力になる

{
  "range": { "from": "v1.3.0", "to": "v1.4.0" },
  "prs": [{ "number": 123, "mergeCommit": "9f8e7d6c", "mergeMethod": "squash", "g5": "success",
            "riskClass": "R2", "delegated": false, "g6PostHoc": false,
            "authorVerificationPresent": true,
            "instructedBy": ["..."], "instructedBySource": "declared",
            "exceptionRecords": [],
            "g6": { "approvers": ["..."], "approvals": 1,
                    "independentHuman": true, "notCountedReason": null,
                    "reviewerSummaryPresent": true,
                    "reviewerSummarySource": "review" } }],
  "directChanges": [{ "commit": "1a2b3c4d", "riskClass": "R3",
                      "riskClassSource": "trailer",
                      "authorVerificationPresent": true,
                      "authorVerificationSource": "trailer", "exempt": null }],
  "gatesInRange": [{ "gate": "G-4", "records": 2 }],
  "specsWithoutG4": [],
  "preInit": { "commits": 2, "productChanges": [{ "commit": "5e6f7a8b", "files": 3 }],
               "templateOrigin": 1, "recordOnly": 0 },
  "criteria": [{ "id": 1, "machine": "partial",
                 "result": "受入基準 3 件、計画したテスト 1 件。実行して通過 1 / 失敗 0 / 実行の記録に無い 0。対応するテストの無い受入基準 1 件(F-001/AC-2)",
                 "humanReconcile": "計画したテストの十分性と、未消化のテストの理由(G-7 の判定記録の「未消化のテスト」)" }],
  "g8Objection": { "matters": [], "notJudged": [], "records": [] },
  "tests": { "coverage": { "measured": true, "pct": 87, "threshold": 80 } },
  "debt": { "ledgerPresent": true },
  "handover": { "updated": true },
  "ipClearance": { "scanRun": true, "result": "passed" },
  "gaps": []
}

• assurance-disclosure.external.md — 組織の外へ渡す形の保証の開示(後掲「組織の外へ渡す出力」)
• quality-report.md — 品質レポート(テンプレ様式)。第4章 G-7の判定基準(2026-10-01 時点で基準1〜9)と突合できる節構成で、出荷判定者が読んで署名する。基準と出力の対応は下表による

判定基準との対応(機械が確かめる範囲と、人が突合する範囲)

集約は、G-7 の基準1〜9 のすべてを機械で確かめるものではありません。準拠テンプレートの実装(2026-10-01 時点)が機械で確かめる範囲と、出荷判定者が記録と突合する範囲は、基準ごとに次のとおりです。品質レポートは、基準ごとに、機械が確かめた結果を出します。機械で確かめていない基準には、「機械では確かめていない。出荷判定者が次の記録と突合する」と、突合する記録を出します(criteria[]。machine は checked・partial・not-checked のいずれか。品質レポートでは「G-7 の基準ごとの確認範囲」の表)。

G-7 判定基準	テンプレートの実装	機械が確かめること	出荷判定者が突合する記録
1 計画したテストの消化率	一部	受入基準(specs/F-NNN/spec.md の受入基準の表の行 F-NNN/AC-N)を参照するテストのファイルの数(計画数)、G-5 の test ジョブが書くテストの実行の記録(evidence/test-results.json。scripts/gate/test-results.mjs)で通過した数、対応するテストの無い受入基準の数(criteria[0]。#288)。実行の記録を取り込めない出荷は、消化数を数えない。参照したテストが受入基準を確かめているかは判定しない	計画したテストの十分性。対応するテストの無い受入基準・未消化のテストの理由と残存リスク(G-7 の判定記録の「未消化のテスト」)
2 未解決の欠陥	一部	欠陥の台帳(docs/defect-ledger.md。重大度・優先度・状態・コア機能)を取り込み、事業ステージ別の欠陥トリアージ基準の区分ごとの未解決の件数を出す(criteria[1]、項目5。#288)。台帳が無い出荷と、読めない台帳は記載の欠落。出荷の可否は判定しない	区分ごとの件数が第4章の欠陥トリアージ基準を満たすか。台帳に載っていない欠陥
3 受容した負債の台帳記録	一部	技術負債台帳の有無(debt.ledgerPresent)。記録漏れは検出しない。コミットに残る未了の記述と台帳を突合していない	変更の記録(PR 本文、判定記録)と、技術負債台帳
4 運用引き継ぎ文書	一部	文書の有無(handover.updated)。監視項目・障害時連絡先・復旧手順の記載は確かめない	運用引き継ぎ文書(テンプレ5)の3項目
5 全ゲートの通過記録	一部	機械で導ける範囲に限る(下表)	機械で導けないゲートの判定記録
6 AI 品質指標の確認	なし	確かめない	第4章「AI 品質指標の扱い」による記録
7 (安全関連ソフトウェアのみ)安全適合性の検証記録	なし	確かめない	附属書F F.7 の項目
8 知財潔白性の検査記録	一部	依存関係のライセンス検査の実施記録の有無(ipClearance.scanRun)。類似の検知の実施記録、判定できなかった項目の台帳記録、期限を超過した指摘は確かめない	類似の検知の記録、台帳の記録、指摘ごとの措置と期限
9 保証の開示の完備	あり	7項目と保証の主張の成立判定の出力、導出元の記録の欠落(後掲「記載の欠落と、値として受け入れるもの」)、層1 の受容しない条件のうち印を付けたものに当たる事実	印の無い受容しない条件に当たる事実が開示に無いこと(G-7「保証の主張の成立判定」(b))。機械が確かめていない事項(後掲「実装の制約」)
(前提)作成側の検証の記載	あり	PR 本文の「検証方法と結果」の有無(prs[].authorVerificationPresent)。PR を経ていないコミットは、トレーラ Verification。G-6 の状態に依らない	記載の内容
(欠陥注入を運用する場合)注入の残存	なし	確かめない。集約が読むのは、検出率の記録だけである	欠陥注入の隔離設計による回収の記録

基準5 のうち、機械で導ける範囲は次のとおりです。出荷に対応する判定記録の数を機械で決められないゲートは、件数を表示し、人が突合する範囲として出します。

対象	機械が確かめること	欠落時
機能仕様承認(G-4)	変更がトレーラ Spec: F-NNN で仕様を指す場合に、その仕様を対象とする G-4 の判定記録の有無。対応は、判定記録の「対象」欄が仕様の ID を指していることで確かめる。ファイル名だけでは対応づけない。判定記録は出荷の範囲に限らず、リポジトリ全体から探す	判定記録が無い仕様を gaps に記録し fail
自動検証(G-5)	PR ごとの必須チェック gate-g5 の結果(prs[].g5)	成功でない PR を gaps に記録し fail。結果の記録が無い PR も欠落とする(必須チェックを経ずにマージされた PR の事後の検出。#286)
独立レビュー(G-6)	PR ごとの承認記録と、独立した人の確認の条件(後掲「独立した人の確認の数え方」)	G-6 を適用する体制では、独立した人の確認を経ていない変更を gaps に記録し fail。G-6 の判定を事後へ移した変更と、例外承認の記録が対応づく変更(リスク区分を問わない)を除く
G-6 未達のまま出荷する R1 の変更の例外承認	独立した人の確認を経ていない R1 の変更ごとの、第7章 7.3の例外承認の記録(prs[].exceptionRecords[]・directChanges[].exceptionRecords[])	記録が対応づかない変更を gaps に記録し fail
構成で適用するゲートごとの判定記録	当該出荷の範囲で追加された判定記録の、ゲートごとの件数(gatesInRange[])	範囲に1件も無ければ gaps に記録し fail。過去の出荷の判定記録では満たさない。期間を指定した実行(--period-from・--period-to)では、この検査を行わない
上のほかのゲート(企画承認、要件合意、技術設計判断、出荷判定、リリース決裁)	確かめない。件数の表示に留まる	fail させない。出荷判定者が、判定記録と突合する

• 機械が確かめる範囲に欠落があれば、ジョブを fail させ、不完全なレポートで G-7 を始めない(「あとで揃えます」を構造的に禁止する)
• 機械で確かめていない基準を、欠落として fail させない。実装に無い検査を、通過したものとして表示しない。品質レポートには「機械では確かめていない」と出す
• ipClearance で fail させる条件は、ライセンス検査を実施していないこと、または記録が欠けていることである。指摘があることでは fail させない。指摘が出た項目は、除去・代替実装・表示の追加・受容の決裁のいずれかを記録して通過させる
• 期限を超過した未処理の指摘が残る場合に出荷を止める規定(第4章 G-5)は、集約へ実装していない。出荷判定者が、台帳の期限で確かめる
• 欠陥注入の残存を出荷の前に確かめる規定(欠陥注入の隔離設計)も、集約へ実装していない。回収の記録で確かめる
• gaps には「何が・どの PR / 記録で欠けているか」を人が直せる粒度で書き出す
• 「作成側の検証の記載」は、作成側が書く記録である。レビュアの挙動要約(G-6 基準2)とは別の記録であり、人確定・協働の変更では、開発者の席の人が書く。開発者の席の委任の範囲の変更では、担い手が実行結果の証拠として書く(PR 運用リファレンス)
• 作成側の検証の記載の欠落は、G-6 が未達・省略の構成でも gaps へ記録する。独立レビューを置けない体制では、人が変更ごとに残す検証の記録が、この記載だけになるためである。独立した人の確認が無いことを gaps へ記録するのは、G-6 を適用する構成に限る

保証の開示の出力

集約スクリプトは、第4章 G-7の基準9 が突合する保証の開示の7項目を、evidence.json と quality-report.md へ出力します。evidence.json では assurance キー、quality-report.md では「保証の開示」の節です。構成と既存の記録からの投影であり、人に新しい記述を書かせません。

#	項目	assurance のキー	導出元
1	体制と独立性の成立状況	independence	構成の unmet[]・deviations[]・seats[]・people[](人の名簿と、人ごとのアカウント)、PR の承認記録、PR 本文の「作成を指示した者」
2	テーラリングの宣言	tailoring	構成の gates(適用以外の状態と理由)
3	リスク区分ごとの件数と、確定の形態の内訳	changes	PR 本文のリスク区分、コミットのトレーラ Risk と Delegated、判定記録の「確定の形態」と「リスク区分を確定した者」
4	機械検査の結果	machineChecks	必須チェックの結果、アダプタのコマンドの有無、CI 成果物
5	残存リスク、既知の不具合、未回収の例外	residual	構成の未達と逸脱、技術負債台帳の区分
6	検出能力の測定値と測定時点	detection	欠陥注入の記録。構成の適合性確認の記録は、検出能力の値とは別の行(detection.conformity[])に出す
7	生成の条件と、期間中の体制の変化点	generation	構成の担い手の識別と changeLog[](即時通知の通知先と通知日、AI が使えなかった期間の記録を含む)、コミットの共著者、指示資産の最終変更

• 導けない項目は「未測定」「記録なし」を値として出力する。空欄にしない
• 値の良否でジョブを fail させない。fail させるのは記録の欠落だけである
• AI が作った要約と評価を、項目の値にしない
• 独立した人の確認を経ていない変更が1件でもある場合は、附属書H H.6の定型の文を件数とともに出力する
• 出荷判定者の席と事業決裁者の席の責任者が同一人物である体制(1〜2名の体制の逸脱)では、項目1 へ「異議を書く者と、残存リスクを受容する者が同一である」と出力する(第3章 3.5)
• 項目1・3・6 には、前回の出荷の値を併記する。項目6 が「未測定」のときは、未測定が続いている期間を併記する(附属書H H.6)
• 項目3 のリスク区分が、作成を指示した者の自己記載だけに依る場合は、その旨を出力する。区分を確定した者の記名は、判定記録(「変更のリスク区分」の確定者)と PR 本文(「リスク区分」の節の「確定した者」。作成を指示した者以外の名簿の人)の両方から数え、件数を出所に出す(第3章 3.8.1)
• 項目6 の測定値は、検出率と件数(検出 / 注入)と測定時点で出す。記録は docs/adoption-trial/seeded-errors.json(導入前の検証の tally が書き、コミットされる記録の置き場)を読む。記録の置き場に記録があるときは、evidence/seeded-errors.json(CI の実行へ別の経路で置いた場合)を読まない。測定時点が新しくても採らない(誰でも書ける未コミットの記録が、コミット済みの目隠しの測定に勝つ経路を閉じる)。記録の置き場に記録が無いときに限り evidence/ を読む。採った出所と読まなかった記録を項目6 に出す。記録の生の値は印字しない。測定値に数えない層は4つある。目隠しを確かめられない層(記録に blind: false がある層。tally が、見つける者が注入した者と同じ場合などに書く)。出所の印(method と blind: true)の無い層。記録の置き場の記録がコミットされていない、またはコミットの後に変更がある場合。測定時点が判定の日より後の層。いずれも未測定として扱い、理由を出す
• 項目6 の AI の層の失効は、記録に書かれた測定した担い手の識別(席・モデル・指示資産の版)と現在の構成の識別の一致で判定する。一致しなければ、同じ日の世代交代でも失効とする。識別の無い旧い記録は、測定時点の日付と最後の担い手の変化点の日付の比較で補う
• 項目6 の人の層には、測定した見つける者(記録の finders[])と、現在の独立レビュアの席の責任者・名簿の対応を出す。測定した見つける者の全員が名簿(体制の内)にも独立レビュアの席にも居ない層は失効とする。層1 の「人の層の再測定の契機」に「席の責任者の交代」とあれば現在の責任者が測定に含まれない時点で、「見つける者の離脱」とあれば1人でも名簿から離れた時点で失効とする。契機が空欄で一部が離れた層は、残る者の指摘(記録の perFinder[].hits)の和集合で値を読み直し、その旨を出す(記録に各人の指摘が無ければ失効)。席の責任者が測定に含まれないときは注記を出す(附属書H H.6 項目6)
• 項目4 には、実環境の統制の確認(附属書I I.11 要件⑦)の記録(docs/adoption-trial/env-check.json。採用者が実環境の gh で adoption-trial env-check を実行して書く)を写す。項目は、ルールセットの適用、PR のレビューの取得、gate-g5 の成果物(license-scan・test-results)の3つである。ルールセットは、要求する承認の数が review.reviewerCount 以上であることと、必須チェック gate-g5 を持つことを読む。regulated では、最後の push の後の承認・コードオーナー・push で古い承認を無効にする設定も読む。いずれかが確認済みでない記録は「未確認」と出す。記録が無い場合、コミットされていない場合、記録の時点の承認者の数やルールセットが現在の構成と違う場合も同じである。確認済みの項目は、API の応答の識別(ルールセットの id、PR のレビューの id、gate-g5 の実行の id と URL、応答の取得時刻)を伴う。識別の無い確認済みは「実環境の証拠を欠く」として未確認と読む。欠落にはしない(未達のゲートと同じ扱い。消えない)
• 項目7 には、席の責任者本人の AI を使わない力量の確認(第3章 3.4.3 要求事項1。構成の seats[].competence)を判断を担う席ごとに出す。記録の無い任命は「未確認(確認を経ない任命)」、確認日が層1 の周期を過ぎた確認は「失効」、周期が空欄なら「有効性を判定できない」。欠落にはしない
• 項目1 には、10名以上の規則(第8章 軸A)の判定を出す。構成 review.mode: internal-plus-core-external では、コア機能(構成 delegation.protectedPaths)を変えた変更のうち独立した人の確認を経たものごとに、数えた承認者が作成を指示した者と別の所属(名簿の team)の人を含むかを件数で出す。パスが未宣言、所属の欄が無い名簿は「判定できない」。構成 approverMode: dedicated-qa では、出荷判定者の席の責任者の所属が開発者の席の責任者の所属と別かを出す。機能責任者への仕様承認の委譲は機械で確かめない旨を出す。いずれも欠落にはしない(第8章の表は手引き)。次の一手(/pit)は、直近の集約の出力が手元にあれば、同じ件数を同じ文で添える
• 項目1 には、G-6 に要する独立した人の承認者の数(構成 review.reviewerCount。規制業・CL3 は 2 名)と、承認者の数が要求に満たない変更の件数を出す。満たない変更は独立した人の確認を経ていない変更に数え、「G-6 の承認者 N 名 / 要求 M 名」と出す。監査対応書式(review.recordFormat: audit)の体制では、変更ごとの G-6 の判定記録の有無と「監査対応書式」の表の記入(2人目の承認者・2人目の挙動要約。旧称「2人目の判定者」の行も読む)を記録の欠落として確かめる。同一の変更で、先に数えた承認者と同一の文の挙動要約は、2件目に数えない(空白・記号・見出し語を除いて比べる。言い換えた写しは検出しない)。independentSafetyAssessment が真の体制では、同じ表の「安全性の評価者」の記名と独立(名簿の人で、開発者の席の責任者・作成を指示した者・判定者と別人)、または「該当なし(理由)」を確かめる
• 項目6 の AI の層には、欠陥注入による検出率だけを出す。適合性確認(第3章 3.4.2)の結果は、「適合性確認の結果」として別の行に出す。検出能力の測定値として出さない
• 出荷判定者の異議で理由の記載を要する事項(第4章 G-8「出荷判定者の異議」)に当たるかを、値から判定して出力する(assurance.objectionMatters)。判定できなかった事項は、その旨を出力する
• 構成の初期化より前に製品のコードを変えたコミットがある場合は、件数を項目1 と項目5 に出す。一覧は品質レポートの「変更単位」に出す。欠落にはしない
• 項目7 の即時通知の通知先は、名簿の人へ正規化した氏名で出す。名簿の人でない名義(品質保証部門の通知先など)は、その旨を添えて出す
• 項目7 の変化点に人の名簿の表記の変更(rosterEdits)があれば、旧い値と新しい値を概要へ出す。席の責任者の行なら、その席も出す。組織の外へ渡す形では、氏名とアカウントを出さず件数で出す

assurance の主なキーは次のとおりです。

キー	内容
independence.changes	total(変更の件数)、withoutIndependentHuman、approvalRecordNotFound、approverNotInRoster、withoutReviewerSummary、r1WithoutException、instructorsByDefault、unconfirmed(数えなかった理由ごとの件数)
independence.r1WithoutIndependentHuman	独立した人の確認を経ていない R1 の変更の件数と、例外承認の記録の有無
independence.unclassifiedWithoutIndependentHuman	リスク区分が未記入で、独立した人の確認を経ていない変更の件数。R1 かどうかを判定していない
independence.reviewerSummary	レビュアの挙動要約を伴う承認の件数と、挙動要約が無いために数えなかった承認の件数
changes.byReviewerSeat・changes.notByReviewerSeat	独立した人の確認に数えた変更のうち、承認した者が独立レビュアの席の責任者である件数と、そうでない件数。gaps にしない
changes.withdrawnApprovals	承認の後に同じ人が変更要求を出し、数えなかった承認の件数(PR ごとには prs[].g6.withdrawnApprovals)
independence.objectionSelfAccepted	出荷判定者の席と事業決裁者の席の責任者が同一人物であるか。同一の場合、項目1 へ「異議を書く者と、残存リスクを受容する者が同一である」と出す
residual.exceptedChanges	例外承認の記録が対応づき、gaps にしなかった変更。未回収の例外として項目5 に出す
residual.gateExceptions	ゲートの判定を対象とする例外承認(台帳の「対象」が G-2 F-001 の形)のうち、記録として成立した行。変更の例外承認と分けて項目5 に出す
independence.preInit・residual.preInitProductChanges	構成の初期化より前に、製品のコードを変えたコミットの件数と、テンプレート由来の初期コミットの件数。一覧は evidence.json の preInit.productChanges
independence.accountsRegistered	人の名簿にアカウントが1件でも登録されているか。登録が無ければ、すべての承認を未確認に数える
changes.delegated	inScope(トレーラ Delegated で識別した、規則の範囲の変更)、withIndependentHuman(うち、独立した人が事前に承認した変更)、withoutPriorHuman(うち、独立した人の事前の承認が無い委任の変更)、withoutPriorHumanBreakdown(その内訳。g6PostHoc は G-6 を事後へ移した変更で、本標準のいう「人の事前確認を経ていない変更」。other はそれ以外の未確認の変更)、outOfScope(範囲の逸脱)
changes.directCommits	PR を経ていないコミットの件数。リスク区分ごとの件数と、対象外にした件数(exempt.recordOnly・exempt.empty。初期化の記録より前の履歴は preInit)
detection.conformity[]	席ごとの適合性確認の結果と確認日。検出能力の測定値ではない
detectionExternal	項目6 の、組織の外へ渡す形。値を含まない
objectionMatters	matters[](当たった事項)、notJudged[](判定できなかった事項と理由)
claim	保証の主張の成立判定(後掲)
continuity	組織継続の側の状態(後掲)
stopReleases[]	当該の範囲で追加された、停止の申し立ての解除の記録と、その成立の可否
stopHolds[]・stopHistoryUnread[]	出荷の範囲の未解除の停止の申し立て(保留。集約を失敗させる)と、ラベルの履歴を読めなかった PR(#288 第2巡)
verification	壊してはならない品質条件(QC-NN)ごとの受入基準・テストからの参照の状態(qc[])、識別子を持たない条件、G-7 基準1 の件数(criterion1: 受入基準の数、計画したテストの数と一覧、対応するテストの無い受入基準、実行の記録)、欠陥の台帳の区分ごとの未解決(defects)。項目4・5 と criteria[] の基準1・2 の材料(#288 第2巡)
changes.riskConfirmation	R1・R2 の PR のうち、「リスク区分」の節の「確定した者」が作成を指示した者以外の名簿の人(AI の名義でない)である件数と、確定していない PR(#288 第2巡)
continuity.cycle・continuity.cycleNotices	層1 の「確認の周期と後継」の値と、空欄の注記(#288 第2巡)

保証の主張の成立判定の出力

集約は、附属書H H.1の6つの成立条件を機械で判定し、assurance.claim と、品質レポート・組織の外へ渡す開示の「保証の主張の成立判定」の節へ出します(#288)。7項目を増やさず、7項目の前に置きます。実装は scripts/gate/org-assurance.mjs と集約です。

条件	判定の単位	機械が見るもの
1 層1 が記名で有効	出荷	docs/quality-assurance-policy.md の版・記名(自然人の名義)・記名日と、5項目の記入(項目2 の条件が1件以上など)。<例: …> の行は記入に数えない
2 層2 を G-1 で宣言	出荷	企画書の「品質の約束と保証範囲」の4欄が記入済みで、保証範囲の欄が「組織として保証しない」「層1 なし」でないこと。G-1 の通過の判定記録があること。G-1 を省略・未達の構成では満たさない
3 指示者と別の自然人の確認	変更ごと	項目1・3 の独立した人の確認に数えた変更。G-6 を事後へ移した変更は、作成を指示した本人でない独立レビュアの席の責任者の抜き取りの記録がある場合
4 G-7 と G-8 を別の自然人が記名。G-7 を記名した人は、範囲内の変更の指示者でも G-6 の承認者でもない	出荷	当該出荷の G-7・G-8 の判定記録の判定者(名簿の自然人で、同じ人でない)。G-7 の判定者を、範囲内の変更の作成を指示した者(PR の欄。未記入なら PR の作成者と開発者の席の責任者)、G-6 の承認者、開発者の席・独立レビュアの席の責任者に照らし、当たれば不成立にして理由を出す。記録の無い間は、出荷判定者と事業決裁者の席の責任者の構成で判定し(出荷判定者の席の責任者を同じ条件に照らす)、その旨を出す
5 検出能力の測定	出荷	項目6 の未測定の継続(起点と回数)が、層1 の項目1 の許容する期間(日数、または出荷の回数)に収まるか。未記入・読めない期間は許容しないとして扱う
6 欠落と受容しない条件	出荷	記録の欠落(この判定から導く G-8 の対象外の受容の欠落を除く)と、層1 の項目2 で印を付けた条件に当たる事実

層1 の項目2 の条件のうち、機械で照合するのは、行頭に印を付けたものだけです。

印	当たる事実
[R1未確認]	独立した人の確認を経ていない R1 の変更
[未達ゲート]・[逸脱]	構成上の未達のゲート・逸脱
[未回収の例外]	技術負債台帳の未返却の例外承認の行
[未測定]	人の層・AI の層の検出能力の未測定
[台帳:<語>]	技術負債台帳の未返却の行のうち、内容に <語> を含むもの

• 印の無い条件と、知らない印の条件は、「機械で照合していない条件」として件数と本文を出す。G-7 の基準9 の突合の欄に、出荷判定者が開示と突合する事項として出る
• 出力は、成立と不成立の件数、条件ごとの不成立の件数、照らした層1 の版、受容しない条件に当たる事実と出所、条件ごとの判定と理由である。不成立が1件でもあれば、附属書H H.6 の定型の文(「品質保証の対象外として出荷した」)を出す。組織の外へ渡す開示にも同じ節を出し、層1 の記名者の氏名は伏せる
• 変更が保証範囲に入るかどうかは、企画書の記述からは機械で決められない。層2 を宣言した案件では、範囲の全変更を保証範囲に入るものとして数え、その旨を出す
• 不成立がある出荷では、G-8 の記録の「品質保証の対象外として出荷することの受容」に、層1 の項目4 の権限者(層1 が無い組織と、行が空欄の組織では事業決裁者)の席の責任者の記名を要する。記名が無い記録と、席の責任者と一致しない記録は欠落にする

組織継続の側の状態

集約は、第3章 3.12.11の依存先の一覧と単一障害点の一覧を、構成と記録から生成し、保証の開示の項目5・7 へ出します(assurance.continuity)。人に一覧を書かせません。成立条件には入れません。

出すもの	導出元
依存先の一覧	構成の seats[].performer(モデル・指示資産)、退出の予行の記録 docs/exit-rehearsal.json(提供者・試した提供者・実施日・基準集合の所在・AI運用担当者の承認・基準集合の範囲の承認 baselineScope)、席の責任者、運用引き継ぎ文書の節2(コア機能の理解保持者)。通知の期間とデータは、構成の dependencies[](/process-change の種別 settings。AI運用担当者が書く)から転記する(#288 第2巡)
代替の無い依存先・退出を試していない依存先	別の提供者での予行の記録の有無と、AI運用担当者の席の責任者の承認。同じ提供者の世代交代の記録は数えない。最後の予行の日が層1 の「退出の予行の間隔」を過ぎた依存先と、間隔の欄が空欄の層1 の依存先は「退出を試していない」へ戻す。基準集合の範囲の承認(AI運用担当者の起案・技術判断者の記名)が無ければ、その旨を出す。起案した者と承認した者が同一人物の承認は数えない(第3章 3.12.3 の要求事項10。両方の席を同じ人が担う体制では、別の自然人の記名を要する)
通知の期間またはデータが空欄の依存先	構成の dependencies[] に通知の期間またはデータの無いモデル。単一障害点の候補として出す
止める席・縮退を確かめていない業務	AI の担い手を置いた席の fallback と、D-0 節12 の縮退の3列(処理できる量が実測か「未確認」か)。実測の日が層1 の「縮退の実測の頻度」を過ぎた量、実測の日の無い量、頻度の欄が空欄の層1 の量は「未確認」へ戻す
後継不在の席	D-0 節9 の代理者(後継候補。席ごとに複数行)の確認の状態と確認日。確認済みで、確認日が層1 の「AI を使わない力量の確認の周期」の内の候補の数が、層1 の「判断の席ごとの後継候補の最低数」に満たない席。周期か最低数が空欄の層1 では全席
後継不在の席	D-0 節9 の代理者の行。人の名簿(people[])の人へ対応づく氏名で、確認済みかつ確認日が層1 の力量の確認の周期の内の候補だけを数える。役割名(「品質保証部 課長」)や名簿に無い名義は数えず、理由を出す
コア理解の保持者が1名以下	運用引き継ぎ文書の節2。本人以外の確認した者と確認日(周期の内)がある行の保持者だけを数え、数えなかった名前と理由を出す。文書が無い、またはコア機能の記載が無い場合もここへ出す
自組織に無い資産	指示資産・基準集合の所在が URL など、リポジトリで確かめられないもの
受容の状態	D-0 節15 の受容の記録(状態・対象・受容した者・期限・照らした層1 の版)。層1 の項目4 の受容者が席の名前なら、その席の責任者と照合する

• 期限を過ぎた受容は、状態が解消していなければ記載の欠落にする。受容の無い状態と、無効な受容(期限・層1 の版の未記入、AI の名義、権限者でない記名)は、欠落にせず「受容なし」「受容の記録が無効」と出す
• 項目7 には、次を出す。D-0 冒頭の層1 の版(現行の版と違えばその旨)。依存先の一覧(通知の期間・データ・退出の予行の失効)。退出の予行と縮退。層1 の「確認の周期と後継」の値(空欄はその旨)。後継(確認済みで周期内の候補の数 / 最低数)。コア機能の理解保持者の人数。有事の決定者の表の空欄の数。停止の申し立ての保留と解除の記録。自律実行の保留が指示文と AI運用担当者の操作に依る旨
• 層1 の「育成の担当」が空欄のあいだは、後継不在の席の受容を無効として扱う(テンプレ11「確認の周期と後継」の空欄の扱い)。演習の頻度が空欄なら、項目7 に「演習の頻度を定めていない」と出す

記載の欠落と、値として受け入れるもの

G-7 の基準9 が差し戻すのは、記載の欠落です。集約は、欠落を次のとおり判定します。

区分	該当するもの	扱い
欠落	7項目のいずれかが出力に無い	gaps に記録し fail
欠落	導出元の記録が無い(下表の事象)	同上
欠落でない	「未測定」「記録なし」と出力された項目	値として出力する。開示された事実であり、G-8 の受容と、出荷判定者の異議の対象になる

gaps へ記録し、ジョブを fail させる事象は次のとおりです。

検出する事象	対応づけの方法	規定
G-6 を適用する構成で、独立した人の確認を経ていない変更がある。G-6 を事後へ移した変更と、例外承認の記録が対応づく変更を除く	PR の承認記録と、後掲「独立した人の確認の数え方」の条件。承認の記録があっても、条件を満たさなければ欠落である。PR を経ていないコミットも当たる	第4章 G-6、G-7 基準5
作成側の検証の記載が無い。G-6 の状態に依らない	PR 本文の「検証方法と結果」。PR を経ていないコミットは、トレーラ Verification。書き忘れたコミットは、判定記録で確定できる(後述)	第5章 5.5.6
独立した人の確認を経ていない R1 の変更に、例外承認の記録が対応づかない	後掲「例外承認の記録が対応づく条件」による	第4章 G-6・G-7 基準5、第7章 7.3
PR のリスク区分が未記入である。選択肢を残したままの欄も未記入として扱う	PR 本文の「リスク区分」	第3章 3.8.1
PR を経ていないコミットに、リスク区分の記録が無い	コミットのトレーラ Risk: R1 / R2 / R3。書き忘れたコミットは、判定記録で確定できる(後述)	第3章 3.8.1
委任の範囲の逸脱(トレーラが指す規則の対象外のファイルを含む、規則が無い、規則が有効に成立していない、確約範囲とコア指定のパスが未登録である、リスク区分が R3 でない)	コミットのトレーラ Delegated と、当該コミットの直前の構成の規則、変更のリスク区分	第5章 5.5.4の条件2・5・7
判定記録が参照する D-0 の版と、判定の時点で構成が追随していた版の不一致	判定記録の「参照した D-0 の版」と判定日時、changeLog[] の版と時刻(後述)。判定日時が、記録した版を改訂前の版として持つ変化点より前か後か、記録を取り込んだコミットの時刻より後かを、文に添える	第3章 3.13.5
ゲートの判定を対象とする例外承認(台帳の「対象」が G-2 F-001 の形)のうち、有効を示す状態の行が、記録として成立しない	承認した者・理由・期限の記入、承認した者が名簿の人であること、AI の名義でないこと。変更の例外承認とは別に照合し、変更へは対応づけない	第7章 7.3
当該出荷の範囲で追加された判定記録が1件も無い	gatesInRange[]	第4章 G-7 基準5
変更が指す仕様に、機能仕様承認(G-4)の判定記録が無い	コミットのトレーラ Spec: と、G-4 の判定記録の「対象」	第4章 G-4、G-7 基準5
必須チェック gate-g5 が成功でない PR、結果の記録が無い PR がある	PR の必須チェックの結果	第4章 G-5、G-7 基準5
変化点の記録の連鎖が切れている。または、現在の構成が最後の記録と一致しない	changeLog[] の要約値(stateHash・prevHash)。契約検査の該当部分を、集約でも実行する	第3章 3.13.5
回答と名簿が矛盾している	確認者を置けないという回答と、外部の確認者を席へ記入した名簿の併存など。逆の向き(確認者がいるという回答で、名簿と席から確認者を確かめられない)は欠落にせず、G-6 を未達として表示し、未達の理由と契約検査の注記へ出す	第3章 3.5、3.13.5、第4章 G-6
即時通知の対象となる体制の変化点に、通知先と通知日の記録が無い	changeLog[] の通知の記録。通知する者と通知先が同一人物である場合は、入力を要求せず、「通知する者と通知先が同一」と自動で記録して表示する	第3章 3.13.6
リリース決裁(G-8)の決断の記録で、出荷判定者の異議の欄が空である。または欄が無い	当該出荷の範囲で追加された G-8 の記録と、「対象」が今回のタグを指す G-8 の記録	第4章 G-8「出荷判定者の異議」
理由の記載を要する事項に当たるのに、異議の欄に理由の記載が無い	同上。欄から、異議の有無を表す語と区切りを除いた残りが無い	同上
G-8 の決断の記録に、照らした層1 の版、または上申の欄が無い・未記入である。「異議あり」と書いた異議を退けて受容したのに、上申の欄に日付が無い	同上。上申の欄は「該当なし」を記入として受け付ける	第4章 G-8「受容の基準との照合と上申」
保証の主張の成立判定に不成立がある出荷で、G-8 の記録の「品質保証の対象外として出荷することの受容」に記名が無い。記名が層1 の項目4 の権限者の席の責任者でない	同上と、層1 の項目4 の行	第4章 G-8 要求事項6
組織継続の状態の受容(D-0 節15)が期限を過ぎ、状態が解消していない	単一障害点の一覧と、D-0 節15 の行	附属書H H.6、第3章 3.12.11
当該の範囲で追加された停止の申し立ての解除の記録が成立しない(記名・理由の欠落、権限者でない、AI の名義、見解を退けた解除に上申先と日付が無い)	ゲート欄が「停止の申し立ての解除」の判定記録	第7章 7.11
出荷の範囲の PR に未解除の停止の申し立てがある(ラベル state:stop-requested が付いている、または付けた履歴があり、その日以後の成立した解除の記録が出荷の終点に無い)。リリースを対象とする未解除の申し立て(ラベルの付いた開いている Issue で、題名か本文が出荷の終点を指すもの)がある(保留。#288 第2巡)	PR のラベルと issue の events、ゲート欄が「停止の申し立ての解除」の判定記録。保留は assurance.stopHolds[] と項目7 へ出す	第4章 G-7「停止の申し立ての保留」、第7章 7.11
D-0 節7 の有事の決定者(4つの事象 × 3つの決定)に空欄がある。「層1 の項目4 による」と書いた欄で、層1 の該当する行の受容者が空欄である(#288 第2巡)	D-0 節7 の有事の事象の表と、層1 の項目4	第6章 テンプレ0「有事の決定者を決めておく」、G-7 基準9
企画書の壊してはならない品質条件に、識別子(QC-NN)を持たない条件がある(#288 第2巡)	企画書の「壊してはならない品質条件(識別子)」の表と欄	第4章 G-7「壊してはならない品質条件の突合」
欠陥の台帳(docs/defect-ledger.md)が無い。または重大度・優先度・状態の列が無い(G-7 が有効な構成。#288 第2巡)	欠陥の台帳	第4章 G-7「基準1・2 の記録」
ステージ移行ゲート・案件に関与していない者による棚卸しの判定記録(ゲート欄に「ステージ移行」「SG」「棚卸し」を含む)に「AI の利用の評価」の節が無い。または6欄に空欄がある(「縮小・停止の基準に当たる状態での継続」の「該当なし」は記入。#288 第2巡)	当該の範囲で追加された判定記録	第7章 7.7.8、第6章 テンプレ4
委任の期間ごとの保証の開示に、受容と異議の記録が対応づかない。または異議の欄が空である。判定者の記名が名簿の人でない、結果が差し戻し、結果が未記入である	判定記録の「対象」が当該の期間を指す G-8 の記録(後掲「委任の期間ごとの保証の開示」)	第4章 G-8、第5章 5.5.4
責任者が未記入の席がある	構成の seats[]	第5章 5.5.1
出荷できない状態である	構成の shipBlocked	第8章 軸E「人員が足りない場合」

G-6 が未達の体制(1〜2名で、作成を指示した者以外の確認者を置けない体制)では、独立した人の確認を経ていない変更を gaps に記録しません。未確認として件数を開示します。R1 の変更は、例外承認の記録を要します。

G-6 を適用する体制で、例外承認の記録が対応づく変更は、リスク区分を問わず gaps に記録しません。独立した人の確認を経ていない変更の件数には数えたまま、未回収の例外として保証の開示の項目5 へ出します(第4章 G-7の基準5)。

例外承認の記録が対応づく条件

例外承認の記録は、番号の文字列が一致するだけでは対応づけません。第7章 7.3が定める記録の5つの事項(対象・状態・承認した者・理由・期限)について、次の4つをすべて満たす記録に限ります。正本は第4章 G-7の基準5 の突合です。

#	条件
1	記録が、当該の変更を対象として明示している。技術負債台帳(第6章 テンプレ3)の区分「例外」の行の「対象」の欄が、PR の番号またはコミットの識別子(先頭7桁以上)を指す。PR を指すのは、PR #N、前に語の無い #N、PR の URL に限る。Issue #N のように前に PR 以外の語がある番号は、PR を指さない。例外承認の記録の置き場は台帳であるため(第7章 7.3)、判定記録(docs/gates/)だけでは対応づけない
2	記録の状態が、有効を示す値(台帳の「未返却」)と完全に一致する。返却済み・取り下げ・失効の記録と、「未返却(…)」のように書き足した記録は対応づけない
3	承認した者の記名、理由、期限が記入されている。期限は、日付として解釈できる値に限る。「未定」「—」、様式の文言(<…>)は記入なしとして扱う
4	承認した者が名簿の人へ対応づき、その人が当該の変更の作成を指示した者でない。氏名の空白・括弧書き・敬称と、アカウントの @ の有無を正規化して、氏名・名簿の id・アカウントのいずれかで名簿の人へ対応づける。名簿の人へ対応づかない記名の行は、理由を出して対応づけない。作成を指示した者も同じ正規化で名簿の人へ対応づけ、人として比べる(文字列の完全一致で比べない)。作成を指示した者のうち1人でも名簿の人へ対応づかない場合は、承認した者と別の人かを確かめられないため、対応づけない(理由「作成を指示した者を名簿と対応づけられない」)。欄が未記入の PR は、PR の作成者と開発者の席の責任者を指示した者とみなす。PR を経ていないコミットは、コミットの作者と開発者の席の責任者とする。名簿に無いコミットの作者は、対応づかない指示者として扱う。AI の名義の記名は対応づけない

• 対象でない欄(内容、備考)に番号が含まれるだけの行は、対応づけない
• 対応づけなかった行は、理由とともに出力する(prs[].exceptionRejected と gaps の文)
• 機械が確かめるのは、記入の有無と状態である。承認した者が D-0 表1「例外承認」の決定者であるか、理由が妥当かは判定しない。出荷判定者も、例外承認の当否を判定しない(第4章 G-7)
• 「対象」が G-<N> <判定記録の対象>(例: G-1 P-001・G-2 F-001)の行は、変更でなくゲートの判定を対象とする例外承認である(#286)。全ゲート共通の通過条件(前提の台帳)を欠いたまま判定を進める場合などに使う。変更へは対応づけず、上表の欠落として記入の成立だけを確かめる。PR の番号を先に取る必要が無い。1行が1つのゲートの1つの対象を指し、「出荷まで」のような範囲を対象にしない

判定記録が参照する D-0 の版は、判定の時点の版と突合します。成立済みの判定記録は書き換えないため、変化点より前の記録は、当時の版を正とします。

不一致の文には、前後関係を添えます(#286)。判定日時を目安で書くと、実際は変化点より前の判定が、変化点より後の判定に見えるためです。添えるのは次の3点です。

• 記録した版を改訂前の版として持つ変化点の時刻
• 判定日時が、その変化点の前にあるか後にあるか
• 判定日時が、記録を取り込んだコミットの時刻より後にあるか

判定日時の書き誤りか、改訂前の版で判定したのかは判定しません。

場合	比べ方
変化点の記録が時刻(at)を持ち、判定記録の判定日時も時刻を持つ	時刻の前後で、判定の時点の版を定める
判定記録の判定日時が日付だけである。または、同じ日の変化点の時刻が分からない	その日の開始時点の版と、その日に改訂された版の、どれを参照していても一致とする
変化点の記録が時刻を持たない(旧い記録)	日付で比べる

保証の開示の項目7 へ出す「期間中の体制の変化点」は、期間の起点の構成に無かった記録として数えます。日付では比べません。起点の構成を読めない場合に限り、日付で比べます。

PR を経ていないコミットの扱いは次のとおりです。

• リスク区分は、コミットのトレーラ Risk: R1・Risk: R2・Risk: R3 のいずれかから読む。PR 本文の欄を持たないためである
• 検証の記載は、コミットのトレーラ Verification から読む。実行した検証と結果の要点か、証跡の所在を書く。PR 本文の「検証方法と結果」に当たる記録である。トレーラが無いコミットと、値が空のコミットは、記録の欠落として扱う
• 複数行の記載をコミットの本文へ書く場合も、トレーラ Verification: に値が1行要る。機械が読むのは、トレーラの値である
• トレーラを書き忘れたコミットは、履歴を書き換えずに、判定記録で確定できる(下表)
• PR を経ていないコミットは、独立した人の確認を経ていない変更に数える。Risk: R1 のコミットは、例外承認の記録を要する
• 記録だけのコミットは対象外とする。変更の件数にも、独立した人の確認を経ていない変更の件数にも数えない。対象外にした件数は表示する

書き忘れを判定記録で確定する条件は、次のとおりです。成立済みのコミットは書き換えません。

確定するもの	判定記録に要ること	出力
共通	判定記録の「対象」が、コミットの識別子(先頭7桁以上)を指している	—
リスク区分	「変更のリスク区分」が、1つに定まっている。選択肢を残したままの欄は未記入として扱う	directChanges[].riskClass と riskClassSource(trailer、または判定記録のパス)
検証の記載	「検証方法と結果」の表の行、または節があり、記載がある	directChanges[].authorVerificationPresent と authorVerificationSource(trailer、または判定記録のパス)

判定記録の「検証方法と結果」は、第6章 テンプレ4の必須欄ではありません。トレーラの書き忘れを補う場合にだけ足します。

対象外にする条件は次のとおりです。変更したファイルのすべてが、いずれかに当たる場合に限ります。

ファイル	対象外にする条件
判定記録(docs/gates/)、証跡(evidence/)、導入前の検証の記録(docs/adoption-trial/。附属書I I.11)、演習の報告(docs/drills/)、退出の予行の記録(docs/exit-rehearsal.json)、技術負債台帳、D-0 体制図、層1(docs/quality-assurance-policy.md)、構成書(PROCESS-PROFILE.md)	無条件。評価用の基準集合は評価の入力であり記録ではないため、PR で入れる
CLAUDE.md	生成区間の外(手書き部分)が、前後で同じである
process.config.json	変化点の記録(changeLog[])が追記され、既存の記録が先頭部分として保たれている
ファイルの変更を持たないコミット	無条件

構成の初期化の記録より前のコミット(pre-init)は、ファイルによらず変更の件数に数えず、欠落にもしません。ただし、製品のコード(上表の記録の置き場の外)を変えたコミットは隠しません。件数を保証の開示の項目1・5 に出し、品質レポートの「変更単位」に一覧を出します。テンプレート由来の初期コミット(親を持たず、テンプレートのファイルだけを持つもの)は、一覧から除いて件数だけ出します。初期化のコミットそのものは対象です。準拠テンプレートは、初期化の生成物と開発の基盤を PR で入れるよう案内します(トレーラ Spec: setup)。初期化のコミットは強制層の初期値を含み、記録だけのコミットに当たりません。独立レビュー(G-6)を適用する体制では、PR を経ないこのコミットは欠落になります。初期化のコミットを集約の対象から外す方式は採りませんでした。作成を指示した本人以外が強制層の初期値を確かめる機会を失うためです(#286)。PR を作れない環境で PR を経ずに入れる場合は、トレーラ Risk と Verification(契約検査の結果)を書き、G-6 を適用する体制では G-6 の判定記録を残します。

独立した人の確認の数え方

承認の記録があることと、独立した人が確認したことは別です。承認したアカウントが人のものであっても、作成を指示した本人の承認は独立した確認ではありません。集約は、承認を次の条件で数えます。

承認を「独立した人の確認」に数えるのは、次の4つをすべて満たす場合に限ります。

#	条件
1	承認したアカウントが、人の名簿(people[].accounts[])の人へ対応づく
2	その人が、当該変更の作成を指示した者でない
3	構成上、G-6 が「未達」でも「成立しない(責任者が同一)」でもない。承認した人が名簿で外部の確認者である場合は、この条件によらず数える
4	承認に、レビュアの挙動要約が伴う(G-6 基準2)。要約を伴わない承認は差し戻しとして扱うためである(第4章 G-6)

• レビューは、レビュアごとの最後の状態で数える。承認の後に同じ人が変更要求を出した場合、取り下げられた承認は数えない
• 承認した者が独立レビュアの席の責任者であるかは、条件にしない。席の作業を複数の人が担う体制を妨げないためである。独立レビュアの席の責任者による承認の件数と、そうでない者による承認の件数を、別に出力する。gaps にはしない
• 作成を指示した者は、PR 本文の欄「作成を指示した者」から取る。氏名、または @アカウント で書く。複数可とし、改行・「、」「,」「/」で区切る。区切れない書き方(「A と B」など)と、姓だけなど名簿の複数の人に当たり得る記名は、名簿と対応づかない指示者として扱う
• 作成を指示した者のうち1人でも名簿と対応づかない変更は、独立した人の確認に数えない(instructor-not-in-roster)。PR を経ていないコミットの作者が名簿に無い場合も同じである
• 欄が未記入の変更は、PR の作成者(人のアカウントの場合)と、開発者の席の責任者を指示した者とみなす。prs[].instructedBySource が default になり、既定値で判定した件数を出力する
• 2名体制で、2人とも作成の指示に関与した変更は、相互の確認では成立しない(第3章 3.5)。独立した人の確認を経ていない変更に数える
• PR を経ていないコミットは、独立した人の確認を経ていない変更に数える

数えなかった変更には、理由を1つ出力します(prs[].g6.notCountedReason)。理由ごとの件数は、品質レポートの項目1 の内訳に出ます。

notCountedReason	数えない理由
record-not-found	承認記録を取得できない
no-approval-record	人のアカウントによる承認が無い
ai-or-bot	AI・bot のアカウントによる承認だけである
approver-not-in-roster	承認者を名簿と対応づけられない
approver-instructed	承認者が、作成を指示した者である
g6-not-established	構成上、G-6 が未達または成立しない。体制の内の人の承認を数えない
instructor-not-in-roster	作成を指示した者を名簿と対応づけられない
direct-commit	PR を経ていないコミットである。件名に PR の番号を持つが、その PR のマージコミットと一致しないコミットを含む(directChanges[].claimedPr)
no-reviewer-summary	条件1〜3 を満たす承認に、レビュアの挙動要約が無い

レビュアの挙動要約(G-6 基準2)の有無は、次のとおり確かめます。

• 挙動要約は、承認レビューの本文、または G-6 の判定記録の「挙動要約」の節から取る(prs[].g6.reviewerSummarySource が review または gate-record)。PR 本文の「検証方法と結果」は作成側の記入であり、挙動要約として数えない
• 挙動要約を伴わない承認は、独立した人の確認に数えない。件数と PR の番号を出力する。G-6 を適用する体制では、当該の変更を gaps に記録し fail させる
• 挙動要約の内容が挙動を記述しているかは、機械で判定しない。プロセス内部監査の観点1 が確かめる

委任で先へ進めた変更と、G-6 の判定を事後へ移した変更

コミットのトレーラ Delegated: <規則ID> は、変更ごとの検証を担い手へ委ねたことの識別です。語を次のとおり呼び分けます。

語	指すもの	出力
人の事前確認を経ていない変更	G-6 の判定を事後へ移した変更。本標準の定義である(第5章 5.5.4 の条件7、第4章 G-7)	withoutPriorHumanBreakdown.g6PostHoc(PR ごとには prs[].g6PostHoc)
独立した人の事前の承認が無い委任の変更	トレーラ Delegated を持つ変更のうち、独立した人の事前の承認が無いもの。上の変更と、それ以外(未確認。withoutPriorHumanBreakdown.other)の合計である	withoutPriorHuman

委任の変更を、事前の承認の記録を持たない変更として一律には扱いません。開発者の席だけが委任の変更は、独立レビュアが事前に承認します。変更ごとの数え方は次のとおりです。

変更	数え方
開発者の席の規則にだけ該当し、独立レビュアが事前に承認した	委任で先へ進めた変更に数える。独立した人の確認を経た変更に数える。人の事前確認を経ていない変更に数えない
開発者の席の規則にだけ該当し、独立した人の事前の承認が無い	独立した人の事前の承認が無い委任の変更のうち、未確認の変更に数える。人の事前確認を経ていない変更には数えない。G-6 を適用する体制では、例外承認の記録が対応づかない限り gaps へ記録する。G-6 が未達の体制では、未確認として開示する
独立レビュアの席の規則にも該当し、G-6 の判定を事後へ移した	人の事前確認を経ていない変更に数える。G-6 の承認記録の欠落として扱わない
トレーラが指す規則に該当しない	委任の範囲の逸脱として gaps へ記録する
トレーラ Delegated を持つのに、リスク区分が R3 でない	委任の範囲の逸脱として gaps へ記録する。委任の範囲は R3 の変更に限るためである

G-6 の判定を事後へ移すのは、次の3つをすべて満たす変更に限ります。

#	条件
1	独立レビュアの席が委任を宣言している
2	変更が、その席の機械の規則に該当する
3	PR のリスク区分が R3 と記録されている

• 開発者の席の規則にだけ該当する変更は、事後へ移さない。独立した人の確認が無ければ、G-6 を適用する体制では gaps へ記録する
• リスク区分が R1・R2 の変更と、区分が未記入の変更も、事後へ移さない
• 該当は、当該コミットの直前の構成の規則で判定する。コミット自身が足した規則で、自らを委任の範囲へ入れる経路を作らないためである
• 独立レビュアの席だけが委任で、開発者の席が協働である構成では、G-6 を事後へ移しても、開発者の席の検証は人が変更ごとに行う(第5章 5.5.6)。人の確認が一切ない経路にはならない(後掲「委任の該当の判定とマージの経路」)

出荷判定者の異議の検査

第4章 G-8「出荷判定者の異議」の4つの事項に当たるかを、集約が値から判定します。当たる場合に、G-8 の決断の記録の異議の欄に理由が無ければ、gaps へ記録します。

事項	判定
1 独立した人の確認を経ていない R1 の変更がある	当該の変更が1件以上ある。PR を経ていない Risk: R1 のコミットを含む
2 検出能力が、前回の出荷に続いて未測定である	人の層または AI の層の、未測定の連続した出荷の回数が2回以上である
3 独立した人の確認を経ていない変更の件数、または構成上の未達のゲートと逸脱の数が、前回の出荷より増えた	どちらか一方の増加で当たる。前回の出力の値と比べる。前回の出力が無い場合は判定せず、その旨を出力する
4 事後の抜き取りを、作成を指示した本人が行っている	G-6 を事後へ移した変更があり、構成上、G-6 が未達または独立レビュアと開発者の責任者が同一である

• 理由の有無は、異議の欄から、異議の有無を表す語(「異議」「なし」「あり」など)と区切りを除いた残りがあるかで判別する。理由の内容は判定しない
• リスク区分が未記入で、独立した人の確認を経ていない変更がある場合は、事項1 に当たるかを判定していない旨を出力する

組織の外へ渡す出力

集約スクリプトは、組織の外へ渡す形の保証の開示を、別のファイル(evidence/assurance-disclosure.external.md)として出力します。人が値を差し替える手順を置きません。

• 項目6 は、検出率の値を出さない。測定している事実・測定時点・推移の向きで出す(附属書H H.6「組織の外へ渡すとき」)
• 未測定は「未測定」と、続いている期間を出す
• 適合性確認は、実施済みか、未実施または失効かだけを出す
• 氏名と自由記述を出さない。責任者・承認した者・通知先は、席の名前と件数で出す。変化点の理由など、人が書いた文は出さず、変化点の種別と日付で出す。伏せるのは名簿と記名の欄から集めた氏名であり、役割名(末尾の語が役職・部門のもの、席や責任者を指す語を含むもの)は伏せない。数えなかった候補・名前は、件数と「氏名は出さない」の定型の文で出す
• 上のほかは、内側の出力と同じ項目と件数を出す

委任の期間ごとの保証の開示

委任で先へ進めた変更は、G-7・G-8 を変更ごとには行わず、期間ごとの保証の開示で扱います(第5章 5.5.4)。出荷の範囲(タグ間)だけを集約する構成では、出荷を伴わない期間の開示が出ません。集約は、出荷の範囲によらず、期間を指定して開示を出す入力を持ちます。

項目	内容
入力	期間の起点と終点(日付。--period-from・--period-to)。出荷のタグを要しない。出力は evidence/period-<起点>_<終点>/ に置く
期間の切り方	コミットの日付(committer date)を、手元の時刻帯(実行した環境の時刻帯)の日付に直し、起点から終点まで(両端を含む)で切る。変化点の記録は、記録した時刻(時刻帯つき)の日付で同じ期間に切る。切り方を開示に書く
出力	期間の保証の開示。期間中に委任で先へ進めた変更の件数と内訳、事後の抜き取りの結果(抜き取りの判定記録の件数と、実施者が作成を指示した本人であるか)を含む
実行の契機	定期の実行(ワークフロー assurance-period)。月次を既定とする(第8章「事後監査の手続」の周期に合わせる)。手動でも実行できる。構成に委任の席または承認済みの委任の規則がある場合だけ、期間の開示を行う。起点の時点・期間中・現在の構成のいずれにも無く、期間中にトレーラ Delegated を持つコミットも無い構成では、「委任を使っていないため、期間の開示は要らない」と出して成功で終える
受容と異議の記録	判定記録(テンプレ4)の「対象」へ期間を書いた G-8 の決断の記録に残す。新しい様式を足さない
検査	期間の開示に対応する記録の有無と、出荷判定者の異議の欄を確かめる。対応づけるのは、「対象」に書かれた日付が起点と終点の2つだけで、その間が期間の区切り(〜、~、-、から)である記録に限る。対応づいた記録の判定者の記名(名簿の人。AI の名義でない)と判定の結果(通過 / 差し戻し)を確かめる。結果が差し戻しの記録は、期間の開示を受容していないものとして扱う。いずれも欠ければ gaps に記録する

出荷判定者が突合するもの

出荷判定者は、この品質レポートだけでは G-7 を判定できません。機械が確かめた範囲は、レポートの結果を読みます。機械で確かめていない基準は、レポートが示す記録と、出荷判定者が突合します(前掲「判定基準との対応」)。

範囲	出荷判定者が行うこと
機械が確かめた範囲(基準5 の機械で導ける部分、基準8 のライセンス検査、基準9、前提)	gaps が空であることを確かめる
機械で確かめていない範囲(基準1・2・6・7、基準3・4・8 の残り、基準5 の残りのゲート)	品質レポートが示す記録と、G-7 の基準を突合する

集約を人手でやると G-7 が滞留するため、エビデンス集約の自動化は出荷判定の前提と位置づけます。ただし、自動化した範囲を超えて「機械が確かめた」と読ませてはなりません。署名の第1の意味(出荷基準の充足。第4章 G-7「出荷判定者の署名の意味」)は、機械で確かめていない基準の突合を含みます。

委任の該当の判定とマージの経路

委任(第5章 5.5.4)の範囲に当たる変更を、人の事前の承認なしにマージする経路には、次を要求します。

#	要求事項
1	該当の判定は、決定的な検査として実装する。AI に判定させない
2	判定のコードと構成は、基底ブランチから読む。変更の側(PR のブランチ)から読まない。行為する側が、判定を書き換えられない形にする
3	判定の結果は、必須でないステータスとして PR へ出す(該当する / 該当しない理由)
4	機械は、承認のレビューを付けない。「人の事前確認を経ていない変更として、規則により先へ進めた。承認ではない」と PR へ記録する
5	マージの実行は、組織が明示的に有効化した場合に限る
6	マージは、判定した時点のコミットに固定して実行する。判定の後に足されたコミットを、判定なしに取り込まない

準拠テンプレートの実装は次のとおりです(2026-09-30 時点)。

項目	実装
ワークフロー	.github/workflows/delegation.yml(ジョブ delegation-check)。PR の更新と、G-5 の完了で動く。PR の番号を入力して手動でも再判定できる(workflow_dispatch)
基底ブランチから読む方法	ワークフローの定義を基底ブランチから読む契機(pull_request_target・workflow_run)で起動し、既定ブランチを checkout する。PR の側のコードを実行しない。スクリプトへ渡すのは、PR の番号とコミットの識別子だけである
判定のスクリプト	scripts/gate/check-delegation.mjs。作業ツリーが PR の先頭のコミットである場合は、判定しない
ステータス	delegation-eligibility。必須にしない。判定できなかった場合も、協働として扱う旨を出す
マージの実行の有効化	リポジトリの変数 DELEGATED_MERGE_ENABLED を true にし、シークレット DELEGATED_MERGE_TOKEN へ、必須承認を回避できる権限を持つ専用のトークンを置く。既定は無効である
マージの方法	スカッシュ。判定した時点の先頭のコミットを指定して実行する。スカッシュしたコミットへ、トレーラ Delegated: <規則ID> を残す
記録	マージした後に、PR へ記録を残す。承認のレビューを付けない

判定の結果は、3つの扱いのいずれかになります。

扱い	当たる変更	G-6	マージ
事後の抜き取りへ移す	下表の条件をすべて満たし、独立レビュアの席の規則にも該当する	事後の抜き取りで判定する	有効化されている場合に限り、機械がマージする。無効のあいだは、協働として人の承認を待つ。開発者の席が委任でない変更、または開発者の席の規則に該当しない変更は、開発者の席の責任者(人)の承認があることを、機械がマージする条件に加える
担い手が検証し、独立レビュアが事前に承認する	開発者の席の規則にだけ該当する。ほかの条件は満たす	独立レビュアが、人として事前に承認する	機械はマージしない。有効化していても同じである。現在のブランチ保護のまま、人の承認でマージする
協働	上のいずれにも当たらない。判定できなかった場合を含む	事前に判定する	人の承認でマージする

判定が機械で確かめる条件と、確かめない条件は次のとおりです。

条件	機械の判定
前提	判定する。PR が open で Draft でない。基底が既定ブランチである。フォークからの PR でない。変更ファイルとコミットの一覧を取得しきれている。委任の範囲の変更を Ready にする者は、PR 運用リファレンス「誰が PR を作るか」による
5.5.4 条件1 案件が委任を許している	判定する。安全重要度が CL0 で、規制業でなく、出荷できない状態でない
5.5.4 条件2 登録した変更種別に当たる	判定する。変更したファイルがすべて、承認済みの1つの規則の範囲に入る。強制層・構成の正本・判定の記録に触れない。規則が有効に成立している(決定した者の記名、AI維持管理者の承認、変更種別の登録)。PR のリスク区分が R3 である
G-6 を事後へ移せるか	判定する。独立レビュアの席の規則にも該当する
開発者の席の検証を担い手へ委ねているか	判定する。トレーラが指す規則が、行為した席(開発者の席)の規則であるかを見る。開発者の席が協働である変更は、開発者の席の人による検証を変更ごとに要する(第5章 5.5.6)。この場合は「人の記入を要求しない」と案内しない
5.5.4 条件3 G-5 の全項目を通過している	判定する。必須チェック gate-g5 の通過を見る。変更箇所の挙動を既存のテストで検出できるかは、種別の登録時に人が確かめる
5.5.4 条件4 取り消しを実行した実績がある	判定しない。種別の登録時の、人の判断である。判定していない旨を出力する
5.5.4 条件5 確約範囲とコア指定に触れない	判定する。構成に、確約範囲とコア指定のパス(delegation.protectedPaths)が登録されていることを要する。未登録の構成は、該当しないものとして扱う。該当するパスが無い案件は、空の一覧を明示して宣言する
5.5.4 条件6 事後の抜き取り	判定しない。事後の、人の判断である。判定していない旨を出力する
5.5.4 条件7 変更単位で識別できる	判定する。すべてのコミットに、同じ規則を指すトレーラ Delegated: <規則ID> が1つある

• 無効のあいだは、委任の範囲の変更も協働として人の承認を待つ。該当の判定の結果だけが PR へ出る
• 委任の範囲の変更では、マージの経路の有効・無効にかかわらず、コミットへトレーラ Delegated: <規則ID> を書く
• 判定とマージの経路は、実際の GitHub 上で実行して確かめていない。確かめたのは、模擬の入力による判定と、模擬の手順に留まる。第5章 5.5.4 の実装マーク(IMPL-0026)は、実環境での確認が取れるまで、降りていない規定として表示し続ける
• 有効化する組織は、試験用のリポジトリで、該当する変更と該当しない変更を流して確かめてから使う

実装の制約

準拠テンプレートの実装には、2026-10-03 時点で次の制約があります。

機械で確かめていないこと:

• G-7 の基準のうち、集約へ実装していないもの。基準6(AI 品質指標)、基準7(安全適合性の検証記録)は、機械で確かめていない。基準1・2 は件数だけを数える(#288。参照したテストが受入基準を確かめているか、件数がトリアージ基準を満たすかは判定しない)。基準3・4・8 は、記録の有無の一部だけを確かめる。基準5 は、機械で導ける範囲に限る(前掲「判定基準との対応」)。降りていない規定として、実装マーク(IMPL-0042〜0047)で表示し続ける
• テストの実行の記録の粒度(#288)。evidence/test-results.json は、テストの実行の単位(すべて通過 / 失敗あり)で記録する。失敗した実行では、どのファイルが通過したかを記録せず、通過に数えない。ファイルごとの結果を出す道具の形はスタックごとに違うため、1つに定めていない。受入基準を参照するテストのファイルの数え方は、強制層の testPatterns と、ファイルの中の F-NNN/AC-N の文字列による
• 名簿の記載が正しいか。承認したアカウントと人の対応は、名簿の記載による。実在しない2人目を名簿へ書けば、相互の確認として数えられる。名簿の記載は、プロセス内部監査の観点6 で確かめる。確認者を置けないという回答と、外部の確認者を記入した名簿の矛盾は、機械で検出する。回答も名簿に合わせて書き換えた構成は、検出しない
• 承認した者が、独立レビュアの席の責任者であるか。条件にせず、件数を別に出力するに留まる。承認者が所有者定義上の権限者と一致するかは、プロセス内部監査の観点6 で確かめる
• 例外承認の記録の内容。対象の明示、状態、承認した者・理由・期限の記入の有無と、承認した者が名簿の人へ対応づき、作成を指示した者でないことだけを確かめる。作成を指示した者に名簿と対応づかない記名が1つでもあれば、対応づけない。記名の正規化で落とすのは、空白・括弧書き・末尾の敬称・アカウントの @ である。旧字体と新字体、読み、略称は同じ人として照合しない。承認した者が例外承認の決定の権限を持つか、理由が妥当かは判定しない
• ゲートの判定を対象とする例外承認の内容。記入の成立(承認した者・理由・期限、承認した者が名簿の人で AI の名義でないこと)だけを確かめる。そのゲートの判定がどの基準を欠いたか、例外承認を要する判定だったか、承認した者が成果物の作成者と別の人かは確かめない。出荷判定者が判定記録と突合する
• 前提の台帳(テンプレ10)の中身。next.mjs が台帳の有無を見て作成を案内するだけである。行の記入・充足状態・受容の記録は確かめず、集約も台帳の有無を欠落に数えない。全ゲート共通の通過条件として、各ゲートの判定者が確かめる
• 構成の初期化より前のコミットの内容。初期化より前のコミットは、独立した人の確認・リスク区分・検証の記載を確かめない。製品のコードを変えたコミットの件数と一覧を出すに留まる。テンプレート由来の初期コミットかどうかは、親を持たないことと、ファイルがテンプレートの置き場に収まることで見分ける。テンプレートのファイルの中身を書き換えた初期コミットも、テンプレート由来として件数だけに数える
• 作成を指示した者の記載に漏れが無いか。記載に漏れがあれば、指示に関与した人の承認を独立した確認として数える。未記入の場合は既定値で判定し、その件数を出力する。名簿の別の人の氏名と同じ記名を書けば、その人として対応づく
• PR を指す番号の書き方。「対象」の欄は、PR #N・前に語の無い #N・PR の URL を PR の番号として読む。前に語のある番号(Issue #N、課題#N、org/repo#N)は PR を指さないものとして扱うため、PR を指していても対応づかない。判定記録の「対象」の照合も同じである
• リスク区分の記載が正しいか。PR 本文の区分も、コミットのトレーラ Risk も、自己記載である。低い区分へ記載した変更は、低い区分の件数として集計される。区分を確定した者の記名は、記名のある判定記録の件数として出所へ表示する。PR と判定記録を1対1では突合していない
• レビュアの挙動要約の内容。有無だけを確かめる。作成側の記載の転記かどうかは判定しない。1語でも書かれていれば、要約を伴う承認として数える
• 作成側の検証の記載の内容。PR 本文の欄も、コミットのトレーラ Verification も、有無だけを確かめる。書かれた検証が実際に行われたか、誰が書いたかは判定しない。開発者の席が協働である変更で、記載を人が書いたかどうかも判定しない
• 出荷判定者の異議の理由の内容。異議の有無を表す語のほかに記載があるかだけを見る。1語を足せば通る。理由が開示された事実に触れているかは、プロセス内部監査の観点14 で確かめる
• 事後の抜き取りが済んだか。件数を出力するに留まる
• 欠陥の台帳の中身(#288)。重大度・優先度・状態の語と件数を読むだけである。台帳に載っていない欠陥、重大度の付け方の妥当性、回避策の実在は判定しない
• 壊してはならない品質条件の参照の妥当性(#288)。企画書の識別子(QC-NN)と、受入基準の行・テストのファイルの中の識別子の文字列の一致だけを見る。参照したテストが条件を確かめているかは判定しない(G-6 の独立レビュア)
• 確約範囲とコア指定のパスの宣言が正しいか。空の一覧の宣言も、そのまま受け付ける
• 人の名簿の記載と、名義の機械検査を人が上書きした旨を、誰が書いたか。上書きは、氏名とともにレポートへ表示する
• 層1 の記名者がトップマネジメントか(#288)。記名が自然人の名義であること(AI の名義・担い手の識別でないこと)と、記名日の形だけを確かめる。トップマネジメントは名簿の外にいることがあるため、名簿とは照合しない。受容しない条件・権限の段階・上申先の妥当性は判定しない
• 変更が保証範囲に入るか。企画書の保証範囲の記述と変更を突き合わせない。層2 を宣言した案件では、範囲の全変更を保証範囲に入るものとして数える
• 受容しない条件のうち、印の無いもの。照合せず、出荷判定者の突合へ回す。印の付いた条件も、当たる事実を語と件数で見るに留まる([台帳:<語>] は台帳の行の内容の語の一致)
• G-8 の受容が層1 の段階を超えたか。照らした層1 の版と上申の欄の記入、「異議あり」を退けた受容の上申の日付だけを確かめる。段階を超える受容の上申の要否は判定しない
• 組織継続の側の記録の中身。退出の予行の記録の差分、縮退の処理できる量の実測、代理者の確認の証拠、コア機能の理解の確認の記録は、記載の有無と語と日付だけを見る。層1 の「確認の周期と後継」の間隔・頻度・周期と記録の日付を比べ、過ぎた記録を失効させる(#288 第2巡)。依存先の通知の期間とデータは、構成の dependencies[] に書かれた値を転記するだけで、契約・規約と照合しない。役割名で書いた受容者が席に当たらない場合(事業部長など)、記名した者が権限者かは確かめない

判定の時点と入力に依ること:

• 作成を指示した者の承認は、マージの時点では止まらない場合がある。PR の作成者が AI・bot のアカウントである場合、ブランチ保護(require_last_push_approval)は、作成を指示した者の承認を止めない。止めるのは、出荷の証跡の集約である。集約は出荷の時点で働く
• 今回の出荷の G-8 の決断の記録は、集約の後に書かれる。記録を書いた後に集約し直さないと、異議の欄は検査されない。当該出荷の範囲で追加された G-8 の記録と、「対象」が今回のタグを指す記録だけが検査の対象になる。照らした層1 の版・上申・対象外の受容の欄も同じである
• 保証の主張の成立条件4 は、G-7・G-8 の判定記録が無い間(最初の集約)は、席の責任者の構成で判定する。記録を書いた後に集約し直すと、判定者の記名で判定し直す。出荷ごとの条件(G-7 を記名した人が、範囲内の変更の指示者でも G-6 の承認者でもない)が照らすのは、記録に現れた指示者と承認者までである。記録に現れない関与(口頭の指示など)は確かめない
• 組織継続の状態の受容の期限は、出荷の終点のコミットの日付と比べる。同じ出荷を後日に集約し直しても、期限切れの判定は変わらない
• 異議の事項3(独立した人の確認を経ていない変更の件数、または未達のゲートと逸脱の数の増加)は、前回の出力が無いと判定しない。判定していない旨を出力する
• PR の変更として扱うのは、PR のマージコミットと一致するコミットである。テンプレートの既定のマージ方式はスカッシュであり、1つの PR が1つのコミットに対応する。マージコミット方式とリベース方式では、PR のブランチのコミットを当該 PR の変更として数え、直接のコミットにも、二重にも数えない。確かめたのは模擬の入力までである。リベース方式で GitHub がマージコミットを返さない PR は、PR を経ていないコミットとして扱い、その旨を表示する
• 構成の初期化の記録より前の履歴は、変更の件数に数えない。初期化の記録を持たない構成では、この除外は働かない
• 委任の期間ごとの保証の開示は、期間の起点と終点の日付で区切る。日付は実行した環境の時刻帯で切る。ワークフローの実行環境は UTC である。日付の境界の前後のコミットは、手元(例えば日本時間)で実行した開示と別の期間に入る場合がある。期間の受容と異議の記録は、判定記録の「対象」に書かれた起点と終点の日付で対応づける。日付の書き方が入力と異なる記録(年を省いたものなど)は、対応づかない
• 期間の開示が要るかは、起点の時点・期間中・現在の構成と、期間中のトレーラ Delegated で判定する。期間中に委任の席を宣言して外した構成のうち、構成の書き換えのコミットが期間の外の日付を持つものは、見落とす場合がある
• D-0 の版の突合では、判定記録の判定日時を、変化点の記録と同じ時刻帯で書かれたものとして比べる。判定記録の様式に、時刻帯の欄が無いためである。時刻帯の異なる場所で書いた判定記録は、前後を取り違える場合がある
• 前回の出荷の値は、ワークフローが取り込んだ前回の成果物(evidence/previous/evidence.json)から取る。取得できない場合は「前回なし」を出力する
• 未測定が続いている期間は、未測定のまま出荷した最初の出荷を起点とし、連続した出荷の回数とあわせて出力する。起点と回数は前回の成果物から引き継ぐ。前回の成果物が無い場合は「前回の出力なし。起点は今回」を出力する
• 人の層の検出能力は、欠陥注入の記録(docs/adoption-trial/seeded-errors.json。記録の置き場が空のときだけ evidence/seeded-errors.json)がある場合にだけ値を出力する。無い場合は「未測定」を出力する。evidence/ は .gitignore の下にあるため、そこにだけ書いた記録は clone した CI の集約に届かない。出所の印(method と blind: true)は文字列の有無であり、記録の中身が実際の測定であることは機械では確かめない(目隠しの手順は導入前の検証の記録で確かめる)
• G-6 の承認者の数の検査は、承認者の数と4条件までである。2人目の承認者の欄を1人目が埋めた形は、機械では止まらない(内部監査の観点6)。同一の文の挙動要約は2件目に数えないが、言い換えた写しは止まらない。2人目が1人目の結果を見たかは確かめない(標準が課していない)。独立した安全性の評価者の検査は記名と独立までであり、評価の実施と内容は確かめない
• 宣言した担い手の識別と実際に動いたモデルの突合は、コミットの共著者の記載との文字列の照合に留まる。ずれは警告として出力し、fail させない。警告には直し方(AI の担い手なら /process-change の種別 performer で宣言する、人の共著者なら宣言は要らない)を添える。どちらであるかは判定しない
• D-0 の版の不一致に添える前後関係は、判定日時と、変化点の時刻、記録を取り込んだコミットの時刻を、同じ時刻帯の文字列として比べた結果である。判定日時の書き誤りか、改訂前の版で判定したのかは判定しない
• 宣言した人数と実態の突合は、期間中の承認者の数が宣言の上限を超えた場合の警告に留まる
• PR を経ていないコミットを対象外にする判定には、抜けがある。changeLog[] を追記しつつ、構成のほかのキーを手で書き換えたコミットは、対象外になる。この書き換えは、要約値の照合が検出する。照合は、契約検査に加えて、証跡の集約でも実行し、不整合を gaps へ記録する。PR を経ない体制でも、出荷までに検出が働く。D-0 体制図の手書き部分の変更も、対象外になる
• 要約値を計算し直して追記した偽造は、集約の照合も通る(準拠テンプレートリポジトリ「実装の制約」)
• コミットが 250 件以上、または変更ファイルが 3,000 件以上の PR は、委任の該当を判定しない。協働として扱う
• 手元の集約でリポジトリを決められない場合(git remote が GitHub の URL でない、--repo を渡していない)、PR の記録を引かず、その旨を欠落として出す。集約はそのまま続けるため、品質レポートには、PR を経ていないコミットとして数えた結果が載る
• next.mjs と出荷判定の証跡の集約は、判定記録の結果欄を「通過」「差し戻し」の語の完全一致で読む。注記を足した値は通過に数えない。next.mjs は、数えなかった記録の所在と理由を出す
• 曖昧語検査(spec-lint)は、機能仕様の置き場(specs/F-NNN/)だけを見る。機能仕様を別の場所へ置く運用では、検査が働かない。判定記録・企画書・体制図の曖昧語は、G-5 の対象にしない
• カバレッジの測定対象が0行のとき、追跡しているファイルに製品のコード(文書・記録・強制層・設定・テスト以外)が無ければ「対象なし」として通す。製品のコードの判定はファイルの置き場と名前による。テストの判定は強制層の testPatterns による
• 出荷できない状態(安全重要度 CL1 以上または規制業で、体制が3名を割った状態)の構成で fail するのは、証跡の集約だけである。G-5 のパイプラインと契約検査は、記録のある構成を通し、表示に留める

実際の環境で確かめていないこと:

• 委任の該当の判定とマージの経路は、実際の GitHub 上で実行していない。マージの実行は、既定で無効である
• 前回の成果物を取り込むワークフローの手順と、PR の承認記録・マージコミットの取得は、実際の CI で実行していない。手元の模擬の入力で確かめた範囲に留まる
• ライセンス検査の記録(license-scan)を gate-g5 の実行から取り込む手順は、2026-10-01 時点で、実際の GitHub 上で実行して確かめていない(#286)。確かめたのは、ワークフローの構文(actionlint)と、gh を模擬した呼び出しの形と、取り込んだ記録で集約の欠落が消えることである。模擬した呼び出しは gh run list --workflow gate-g5 --commit <対象> --status success と gh run download <実行> --name license-scan --dir evidence である。gh run download が成果物を evidence/ の直下へ展開するかは、前回の出荷の証跡の取り込みと同じ前提に立つ。初回の出荷で、Actions の実行の記録を確かめる
• 出荷の対象のコミットに gate-g5 の成功した実行が無い場合(タグを、既定ブランチへの push の検査が終わる前に打った場合など)、記録は取り込まれず、集約が「知財潔白性の検査記録がありません」を欠落として出す。別のコミットの実行から取り込む代替の経路は持たない
• 委任の期間ごとの保証の開示を出す定期の実行と、既定ブランチへの push を契機とする契約検査は、実際の GitHub 上で実行していない

デプロイゲート

• リリース決裁(G-8)は GitHub Environments の approval(環境保護ルール)で実装できる。production 環境に事業決裁者を required reviewer として設定すれば、決裁の記録も自動で残る
• ロールバック手順は運用引き継ぎ文書(テンプレ5)に記載し、デプロイ自動化とセットで整備する