第7巻　処理方式設計書(3) ― 運用設計・移行・相互運用・試験戦略

本巻は docs/specs/20_method_design.md の第10章〜第16章(運用設計/ベンダ実装観点/移行・切替・共存/ZC Communicator・ZC Adopter導入モデル/参加要件・適合性評価/相互運用と段階導入ロードマップ/試験戦略)を収める。前巻→第6巻の続き、続きは→第8巻。

---

第10章 運用設計（監視・エスカレーション・事務対応／SLA・障害対応Runbook／CASE運用テンプレ）

要旨

本章では、監視・エスカレーション・事務対応をCASE中心に組み立て、電話とExcelに依存しない運用を設計する。照会メタ情報（as_of/watermark/next_action_hint）、Runbookの分岐固定、CASE自動収束やCircuit Breakerなど、現場を回すための仕組みをまとめる。

10.1 運用の基本方針（規範）

• 例外・遅延・未応答・不整合を「人が読むログ」ではなく 状態＋ワークフロー で収束させる（事務レス）。
• そのために、CASEが中心概念となる（第3章）。

10.2 監視（SLO/SLAの扱い）

• 絶対表現（所定水準）は採用しない。SLO（目標）とSLA（保証）を分離。
• SLA逸脱は自動エスカレーションと理由コードを付し、事務処理を定型化。

10.3 エスカレーション（規範）

• 重大障害は「取引影響（件数/金額/レーン）」「安全弁（H）への影響」「当局連携要否」で分類。
• 連絡系統：ZC運用→参加行運用→当局連絡→広報対応をテンプレ化。

10.4 事務対応（窓口・コールセンター）

• 照会画面は Decision/Execution/a/b を分離し、理由コードと次アクションを提示。
• 取消（CANCELLED）・失敗（FAILED）・救済（REVERSAL）は表示文言を固定し、誤認を防ぐ。
• RTPのAttempt履歴（PR-RTP-ATTEMPT-MAX 回まで）を照会可能にし、現行運用との整合を取る。

10.4.1 参加主体の事務が回るための照会メニュー（最低限）

参加主体（銀行）がZCと接続する以上、 日々発生する事務は「照会で回る」ことが必須 である。最低限、以下はZC照会（Query API / Dashboard）で提供する。

• 取引照会（txid/gtid/rtp） ：Decision／a／b、理由コード、次アクション、鮮度（as_of/watermark）、次リトライ（next_retry_at）
• H状況照会 ：H_reserved/H_locked の推移、超過回避のための見通し
• DNS照会（当日） ：ネット勝ち負け（純受取/純支払）、サイクル状態（OPEN/KICKED/SETTLED/HOLD_ACTIVE）、HOLD理由
• 未収束一覧 ：SUSPENDED、AUTHORITY_WAIT、PROOF_MISMATCH、DLQ等
• 加盟店/PSPR照会（Express） ：pspr_refの有効期限、受入可否、失効理由

規範 ：運用担当者が「電話とExcel」で追跡し始めた時点で事故は拡大する。照会とCASEで閉じる。

10.4.1.1 照会メタ情報（as_of / watermark / next_action_hint / next_retry_at）【規範】

照会（Query API / Dashboard）は、 「取引の状態」そのもの （Decision/a/b/証憑）を返すだけでなく、
運用・窓口が不安にならないように、 “見えている情報の鮮度と、次に何をすべきか” を明示する。

重要：これらは「曖昧にするための項目」ではない。

最終的整合（Read Modelの遅れ）を許容しつつ、説明責任をむしろ強化するための項目 である。

項目	意味（事務向けに一言）	規範（どう使うか）	代表例
as_of	この表示が“いつ時点”のものか （画面の鮮度）	画面・帳票の脚注として必ず出す。照会回答の「今の状況」を固定する。	2026-01-17T12:34:56+09:00
watermark	どこまでログ反映できているか （反映位置）	監査・再現性のために返す。複数チェーン（シャード）にまたがる場合は watermark_detail.shards に“複数”を返す（キー書式は 30_internal_design.md §13.6）。	{"TX:TX-2026-0001": 12345, "GT:GTID-7": 67890}
next_action_hint	次に取るべき行動 （定型応対の根拠）	窓口・コールセンターはこれを“テンプレ回答”に変換して返す（文言固定）。閉じた 4 値であり、事象ごとに新値を作らない（値域の正は 30_internal_design.md §13.6、実装は src/types/api/transfers.ts#QueryResponse）。事象固有の含意は reason_code が担う。	WAIT / RETRY_LATER / CONTACT_PAYER_BANK / OPEN_CASE
next_retry_at	次に照会すべき時刻 （過剰照会を防ぐ）	連続照会を抑止し、CASE爆発・電話増加を防ぐ。再試行の最短時刻として扱う。	2026-01-17T12:36:00+09:00

10.4.1.1.1 事務の安心ポイント（誤解を防ぐための規範）

• as_of が古い＝取引が危ない、ではない。
  • Decision（Raftコミット）と証憑（bank_proof_ref）は不変 であり、Read Modelの遅延は“表示の遅れ”に過ぎない。
• watermark は“内部の難しい数値”ではなく、監査用の 説明材料 である。
  • 窓口が顧客に説明する必要はない（監査・運用の再現性のために保持する）。
• next_action_hint は「担当者の経験」に頼らず、 設計で固定した分岐（Runbook） に沿って案内するための鍵である。
• next_retry_at は“いつまでに終わる”の確約ではない。
  • ただし、 この時刻より前に再照会しても状態が進まない ことを意味する（無駄な照会・電話を止める）。

10.4.1.1.2 窓口回答のテンプレ（例）

• next_action_hint=WAIT の場合：
  • 「処理は進行中です。次の更新見込みは {next_retry_at} です。更新後に再度ご確認ください。」
• next_action_hint=CONTACT_PAYER_BANK の場合：
  • 「支払側の確認が必要です。支払側金融機関へお問い合わせください。」
• next_action_hint=OPEN_CASE の場合：
  • 「例外処理に入りました。受付番号 {case_id} で対応状況を確認できます。」

規範 ：運用担当者が “次にどうすればよいか” を迷う余地を残さない。

10.4.2 帳票・データエクスポート（監査・分析のための規範）

参加主体は、事務・監査・経営のために一定のデータ抽出が必要となる。ZCは個人情報の最小化を前提に、以下の提供を規範化する。

• CSV/Parquetダウンロード（期間指定） ：自社起因の取引、相手先内訳、理由コード分布
• 集計ビュー ：銀行別の件数/金額（受取/支払）、RTP成功率、Bulk成立率、H逼迫回数
• 監査用パッケージ ：決定証跡（decision_proof_ref）と証憑参照（bank_proof_ref）の突合せ一覧

注意 ：他行の個別顧客情報は開示しない。必要な範囲は「自社起因＋統計化」で提供する。

10.4.3 H（仕向超過限度）のモニタリングは必須か

必須である。Hは本システムの 安全弁（絶対超過禁止） であり、超過の兆候が見えない設計は運用破綻する。

• モニタリング対象：H_reserved / H_locked / 解放待ち（FAILED_EXECUTION等）
• アラート：閾値超過ではなく「逼迫率」と「滞留時間」で出す
• 事務導線：逼迫→優先度調整（Bulk）→CASE起票→関係先連携

10.5 運用操作の統制（4眼・証跡）

• cap変更、circuit breaker、強制停止/再開、誤記録訂正は4眼承認＋evidence_ref必須。
• 実施者単独で不可とし、内部監査・当局への説明に耐える。

10.6 インシデント時の対外説明（説明骨子）

• 何が起きたか：Decision/Executionのどちらの軸で遅延・未確定が生じたか
• 利用者影響：a/bのどこまで到達しているか
• 安全性：H超過は起きていない（または安全側に凍結）
• 復旧見込み：SLO/SLAと再構築方針（ログから復旧）
• 再発防止：運用操作・監査証跡に基づく改善計画

10.7 CASE自動収束（大量頻発を前提とした規範）

CASEは「人手のチケット」ではなく、 例外を自動で収束させるワークフロー として扱う。
大量に起票される前提で、必ず以下を備える。

10.7.1 CASE分類（Auto-Resolvable / Auto-Progress / Manual-Only）

区分	趣旨	代表例	原則
Auto-Resolvable	自動で解決して閉じる	一時通信障害、重複受信、Read Model遅延	自動Closeがデフォルト
Auto-Progress	自動で進展するが時間待ち	夜間停止、相手証憑待ち、DNS HOLD	next_retry_atで“待ち”を管理
Manual-Only	判断が必要なものだけ人手	不一致（Misrecord）、法令凍結、争訟	ごく少数派に隔離

10.7.2 CASE集約（チケット爆発を防ぐ規範）

• 同一原因（例：Adapter停止）で多数txidが発生しても、
  CASEは1件（障害CASE）に集約し、txidは関連付け で管理する。
• 集約キー：CAUSE:{cause_party_id | detection_path}:{reason_code}

集約の入口は src/zc/cases/case.ts#openOrAggregateCase である。同一の集約キーを持つ
未解決（§10.7.2.1）の CASE が既に在れば、新規起票せずに当該 CASE へ関連付ける。
関連付けの内訳は CaseRelatedTransactions、件数は Cases.occurrence_count、最終発生
時刻は Cases.last_occurred_at が保持する（31_schema.md § Cases）。

• 原因主体が未特定のときは検出経路を鍵に用いる：原因主体（cause_party_id）が
  検出時点で判らない場合、集約キーの当該要素には検出経路（detection_path）を用いる。
  「判らないから集約しない」とすると、最も件数を生む障害（Adapter 不通、監査チェーン
  破断）がちょうど集約から外れる。原因主体が事後に特定された場合は、当該識別子へ
  置き換えたうえで CASE を分割してよい。
• 原因主体も検出経路も無い起票は集約しない：CAUSE::{reason_code} を鍵にすると、
  原因の判らない CASE が理由コードだけで束ねられ、「1 原因 1 件」ではなく
  「1 単語 1 件」になる。当該 CASE は単独で立てる。
• 件数は取引の数であって検出の数である：occurrence_count の増分は
  CaseRelatedTransactions への行挿入が成功した場合に限る。同一 txid の再検出（再送・
  スイープの再走）で件数を動かしてはならない——動かすと、下記 §10.7.2.2 の件数閾値が
  被害の広がりではなく再送量を測ることになり、閾値の意味が失われる。

10.7.2.1 「既に起票済みか」の判定（規範）

集約は「同じ原因の CASE が既に在るか」を問う判定に依存する。この判定の基準は
未解決であり、その値域は OPEN / IN_PROGRESS / ESCALATED の 3 値である
（RESOLVED だけが「対処済み」を意味する）。

規範：重複判定に OPEN のみ、または OPEN/IN_PROGRESS のみを用いてはならない。

これは保守的な近似ではなく、必ず破れる判定である——§10.7.4 の昇格スイープは
PR-CASE-SLA の経過とともに CASE を OPEN/IN_PROGRESS から必ず外す。したがって
ESCALATED を含まない判定は、ちょうど 1 SLA 期間で一致しなくなり、以降スイープの
たびに同じ原因の CASE を起票し続ける。しかも SLA 期間を生き延びる原因は重大なもの
（監査チェーン破断・所有権の乖離など）に偏るため、最も人が見ている案件が最も重複する。
「人手が増えないことを、誰も見ないことで達成してはならない」（§10.7.4）の裏返しで、
人が見ている案件を、機械が水増ししてはならない。

判定の値域は実装上も一箇所に閉じる（src/zc/cases/case.ts#UNRESOLVED_CASE_STATES。
各所での手書きを test/invariants/case_dedup.test.ts が機械検査する）。
昇格スイープ自身（OPEN/IN_PROGRESS のみを昇格対象とする）と GTID 収束時の自動 Close
（ESCALATED を自動で閉じない＝人の判断を機械が取り消さない）は、意図的に狭い
別の述語であり、その理由を同ファイルに併記する。

10.7.2.2 二次エスカレーション（人が持っている CASE の膨張を可視化する規範）

§10.7.2.1（ESCALATED も未解決として集約先にする）と §10.7.4（ESCALATED を自動 Close
しない）は、いずれも単独では正しい。両者の交点に死角がある——人が CASE を持っている間、
同一原因の新規発生は既存 CASE へ関連付けられるだけで、CASE 件数にも状態にも現れない。
被害が 10 件から 10,000 件へ広がっても、系の側では何も変わらない。

規範：ESCALATED の CASE について、次のいずれかが成立したら、状態を変えずに

あらかじめ定めた通知先へ再度通知する（二次エスカレーション）。

• occurrence_count が PR-CASE-SECONDARY-COUNT（既定 100 件）を超えた——原因の広がり
• last_occurred_at > escalated_at——人を呼んだ後もなお発生し続けている

• 状態を変えない：ESCALATED は既に終端の処理状態であり、さらに昇格させても意味が
  無い。OPEN へ戻すのは §10.7.4 が呼んだ人の判断を機械が取り消すことになる。emit する
  のは事実（EntityStateLog の CaseSecondaryEscalated、state_from = state_to）のみで
  あり、通知の実行はこのログを購読する側が行う。
• escalated_at は昇格時に打刻し、以後動かさない：判定は「人を呼んだ後も発生して
  いるか」を問うものであるから、基準は行の最終更新時刻ではなく呼んだ瞬間でなければ
  ならない（§10.9 の保留開始時刻列と同じ理由による）。
• 再通知は新規発生があったときだけ：last_notified_at 以降に last_occurred_at が
  進んだ場合に限る。広いが静かになった CASE を毎スイープ通知すると、二次エスカレーション
  自体が §10.7.2 の防ごうとしているノイズになる。

実装は src/zc/cases/case.ts#sweepSecondaryEscalations、駆動は timeout sweep の第19段。
検査は test/zc/case_aggregation.test.ts。

10.7.3 Circuit Breaker（再送嵐を止める規範）

• Adapter疎通不能を検知したら、該当参加行向けの実行要求を停止し、
  SUSPENDED + reason_code=SUSPEND_ADAPTER_DOWN で束ねる（32_api_contracts.md § 状態 reason_code）。「相手が拒否した」失敗（EXEC_DEBIT_FAILED / EXEC_CREDIT_FAILED）と同じ値に落としてはならない——両者を区別できないと、1 行の不通が実行失敗 CASE を大量に生み、§10.7.2 の集約が効かなくなる。
• 復旧検知後は、段階的に再開（レート制限）し、DLQを増やさない。

10.7.3.1 ブレーカー状態モデル（規範）

状態	意味	遷移トリガー
CLOSED	通常運転	連続失敗 N 回（既定 5 回） → OPEN
OPEN	全リクエスト即拒否	クールダウン経過（既定 30 秒） → HALF_OPEN
HALF_OPEN	限定数のリクエストのみ通過させ、成否で判定	成功 → CLOSED ／ 失敗 → OPEN

10.7.3.2 観測指標（規範）

参加行ごとに以下のカウンタを保持する（31_schema.md § CircuitBreakerState）：

• total_requests / total_successes / total_failures — 累計
• total_denied — OPEN 状態で拒否した数（ホストの呼出抑止効果の計測）
• half_open_inflight — HALF_OPEN 中の進行中呼び出し数
• last_success_at — 直近成功時刻（復旧監視）

10.7.3.3 運用 API（規範）

• GET /api/circuit-breaker — 全行の状態 + メトリクス一覧（OPS ダッシュボード用）
• GET /api/circuit-breaker/:bank_id — 個別行の詳細（未登録なら初期値 CLOSED を返す）
• POST /api/circuit-breaker/:bank_id/reset — 強制 CLOSED リセット。4 眼制御の対象とし、操作者 ID と理由を BankAuditLog に残す。

10.7.4 自動Close条件（規範）

• 同一idempotency_keyの再処理により状態が進展した場合、CASEは自動Closeしてよい。
• 期限（sla_deadline）を超えても OPEN / IN_PROGRESS のままの CASE は、ESCALATED へ昇格させる（Auto-Progress → Manual-Only）。判定は定期スイープが行い、期限は起票時に必ず設定する（§10.10.2）。
  • 昇格は「解決」ではない：ESCALATED は「人が見る必要がある」を意味し、CASE を閉じない。
  • 昇格は取引の状態に触れない：CASE のライフサイクルと決済のライフサイクルは別軸である（§3.6）。

規範 ：CASEが増えるのは正常。人手が増えるのは異常。

ただし「人手が増えない」を「誰も見ない」で達成してはならない——期限を持たない CASE は

昇格判定から落ちるため、統計上は人手ゼロに見えて実際には放置されている。期限の設定は

この規範の前提条件である。

10.8 参加行制約と例外収束（バッチ遅延／二重送信／夜間停止／Adapter不通）【規範】

参加行の勘定系・運用制約は現実として存在する。ZCはそれを前提にしつつ、
状態・証跡・次アクションで曖昧さなく収束 させる。

10.8.1 「a証憑をバッチ後にしか出せない」場合

• 許容レーン ：Standard / Bulk（許容）
• 非許容レーン ：Express / 高額即時レーン（不可）

規範：a証憑が遅延する場合、取引は DECIDED_TO_SETTLE のまま a未確定 として扱い、
reason_code=SUSPEND_EXEC_TIMEOUT（T2 タイマの満了。§3.3.1）、next_action_hint=WAIT、next_retry_at を返す。

Express/高額即時は「aを同期確定できる参加行のみ提供可」とし、Capability Registryで制御する。

10.8.2 「勘定系が二重送信してくる」場合

規範：配送はat-least-once前提であり、 二重送信は正常系の一部 として吸収する。

• COMMAND重複：同一 idempotency_key は同一要求として扱い、副作用は1回のみ。
• EVENT重複：同一 bank_proof_ref（または同一digest）は重複として無害化する。
• 内容不一致：同一txidで内容が異なる場合は PROOF_MISMATCH としてCASEへ接続する。

10.8.3 「夜間バッチ停止中のStandard処理」

規範：入口（受領）は可能だが、Executionは停止する。状態は明確に保留する。

• 遷移：PRECHECKED → PRECHECKED_SUSPENDED
• reason_code=COUNTERPARTY_WINDOW_CLOSED（相手行の稼働ウィンドウ外。復帰スイープがこの値を鍵に再開する）
• next_action_hint=RETRY_LATER
• next_retry_at=バッチ明け時刻

10.8.4 「Adapterが落ちたまま復旧しない」場合

規範：曖昧なまま放置しない。Decision前はCancel収束、Decision後はCASE＋補償で収束する。

• Decision前（RECEIVED/PRECHECKED/H_RESERVED）：DECIDED_CANCEL → CANCELLED（自動解放）
• Decision後（DECIDED_TO_SETTLE以降）：
  • SUSPENDED + reason_code=SUSPEND_ADAPTER_DOWN へ
  • 期限超過で FAILED_EXECUTION へ昇格
  • 収束は 補償（Reversal/返し決済） または 未実行証明（NoDebitRecordedProof） で行う

規範 ：Decision後の失敗を“取消”にすり替えない（監査・顧客説明が破綻する）。

10.9 SLA・障害対応Runbook（Operations & Resilience Runbooks）

10.9.1 SLI/SLO（レーン別）

レーン	SLI	目標SLO（例）	算定母集団（SoT）	証跡
Standard	end-to-end latency	p99 ≤ X秒	Finality Log（b到達）	指標ログ + 日次集計
RTP	acceptance-to-b latency	p99 ≤ Y秒	Finality Log（b到達）	状態遷移ログ
Bulk	completion time	期限内完了率 ≥ Z%	Bulk Window Close	バッチ証跡
DNS	cycle close time	サイクル閉鎖 ≤ T	DNS Cycle Close	DNS証跡

※数値（X,Y,Z,T）は PR-SLO-STANDARD-P99 / PR-SLO-RTP-P99 / PR-SLO-BULK-COMPLETION / PR-SLO-DNS-CYCLE-CLOSE として 30_internal_design.md §12.9（PR-* パラメータ台帳）で固定し、変更時は evidence_ref と周知を必須とする。

10.9.1.1 算定式（規範）

• latency：b_timestamp - received_timestamp（received_timestamp は ZC Ingress の受理時刻）
• availability：1 - (error_budget_breach_minutes / total_minutes)（算定はレーン別）
• Read Model 健全性：inconsistency_rate = inconsistent_reads / sampled_reads
• DNS cycle：cycle_close_timestamp - cycle_open_timestamp

規範

SLIは必ず Finality Log（SoT） と突合可能な形で算定する。Read Modelのメトリクスは補助であり、SoTの代替にしてはならない。

10.9.2 監視・アラート（最低限）

• backlog（未確定滞留）、DLQ増、再送率、署名失敗率、Read Model不一致率、quorum状態、外部接続（Adapter）遅延
• 閾値超過時はIncidentを自動起票し、 Commander / Comms / Tech / Legal を同時召集する。

10.9.2.1 重大度（Severity）分類（運用規範）

• Sev-1：Finality Log 書込不能、quorum割れ継続、DNS Cycle Close不能、広域影響の署名異常
• Sev-2：特定レーンのSLO継続逸脱、Read Model広域劣化、外部Adapterの結果不確定が増大
• Sev-3：一部参加者の不適合、局所障害（隔離で封じ込め可能）

10.9.3 Runbook

10.9.3.0 共通フォーマット（必須）

各Runbookは、公開版では『運用手順書』ではなく『設計上の収束戦略』として記述する。最低限、以下を含む。

• 発火条件（Trigger）／検知（Detection）／初動（初期対応）
• 役割： Commander / Comms / Tech / Legal / Participant Liaison
• 収束戦略：状態遷移の方針、判断分岐（Go/No-Go）、段階的な復帰方針
• 成功判定（Success Criteria）
• 証跡（Evidence）： incident_id 、タイムライン、発行イベント、関連 proof_ref 、顧客表示ログ

10.9.3.1 DNS_HOLD（System Runbook：証跡採取・通知・表示）

対象 ：本書 2.4 類型B（DNS HOLD）および 制度の DNS_HOLD 規程・運用プロトコル（10_requirements.md 第3章）。

運用骨格

• 検知→ incident_id 採番→状態遷移（DNS_HOLD_REQUESTED → DNS_HOLD_ACTIVE）→解消（DNS_RESUMED）を、 単一路線の証跡 として固定する。

• HOLD中はDNS関連の新規 Decision を停止し、受付中の取引は SUSPENDED 系状態に収束させる（取消は原則禁止、救済はReversal/CASEとして扱う）。

• 制度上の初動連絡・公表統制・顧客表示の規範は 10_requirements.md 第3章（制度・ガバナンス要件）を正とする。本書ではフェーズ移行に伴う 開始/終了イベント の記録（方式・証跡）のみを扱う。

• 顧客表示は、public_message_id に対応する定型文に限定し、原因断定・参加者名・定量情報の露出を抑制する。

• 再開時は「サイクル順→取引時刻順→同一取引の因果順（correlation/causation）」の順序制約を守り、Read Model を再構築する。

• カットオフ後の少額DNS取引は当該サイクルに追加計上せず、scheduled_cycle_id=next_cycle として繰延計上する（受付継続）。対外説明は「受付済み（次サイクル計上）」に固定する。

• IGS（高額即時）は igs_mode により制御する（優先クラス分類は設けない）。段階遷移（NORMAL/STOP/RINGFENCED/RINGFENCED_PLUS）と Accept 条件の規範は §2.4 を正とし、本節はその Runbook 適用に限る。

  • NORMAL（平時）→ HOLD 宣言で STOP（初動）→原因行集合確定で RINGFENCED → リザーブ算定が説明可能な形で成立したら RINGFENCED_PLUS → 解消で NORMAL
  • Accept条件（例）は本書 2.4 に従う。拒否ではなく Defer を原則とし、scheduled_execution_window を付与する。

• dns_recovery_reserve はZCが算式に基づきリアルタイム自動算定し、reserve_explain_hash と reserve_confidence を必須で証跡化する。

Success Criteria

• DNS Cycle Close が収束し、DNS_RESUMED 後の未確定残高が0に収束
• 顧客表示が規範通り（誤原因表示なし）
• 監査用証跡が一貫（ incident_id により全イベントが連結）

Evidence

• igs_mode の変更履歴（NORMAL/STOP/RINGFENCED/RINGFENCED_PLUS）
• dns_recovery_reserve / reserve_explain_hash / reserve_confidence
• IGSのDefer件数・実行件数・スロットリング適用状況（集計参照ID）
• カットオフ後の繰延計上（scheduled_cycle_id）件数（集計参照ID）
• incident_id
• 状態遷移イベント：DNS_HOLD_REQUESTED / DNS_HOLD_ACTIVE / DNS_RESUMED
• 不足額・件数等の算定根拠ダイジェスト（参照ID）
• 対外表示ログ（参照ID）
• 閉域連絡ログ（参照ID）

10.9.3.2 署名異常（Signature Anomaly：攻撃/運用逸脱の切り分け）

目的 ：署名検証の異常を『参加者単独の運用逸脱』『複数参加者に跨る系統障害』『特定メッセージ型に偏る改ざん/再送異常』として切り分け、 安全側へ収束 させる。

収束戦略

• 異常のスコープ（参加者×レーン×メッセージ型）を確定し、影響範囲を限定する。
• 影響範囲の新規Decisionを停止し、受付は SUSPENDED へ収束させる（Read-only/隔離の選択肢を持つ）。
• 原因が確定しない段階での対外説明は public_message_id による定型に限定し、原因断定を禁止する。

Success Criteria

• 署名検証異常が収束し、再開しても再発しない
• 改ざん疑義が解消、または捜査/当局連携へ適切に移管

Evidence

• incident_id
• 失敗率/対象/時刻/型のダイジェスト（参照ID）
• 隔離/遮断の操作ログ（参照ID）
• 鍵イベント（参照ID）

10.9.3.3 quorum割れ・split-brain（Read-only 遷移の運用）

Trigger

• quorum未達（過半数合意が成立しない）
• shard間でリーダが二重化（split-brain兆候）

収束戦略

• 自動で書込停止（READ_ONLY_ENTERED）へ遷移し、確定点を固定する。
• 影響範囲（どの txid/gtid 範囲が未確定か）を確定し、再同期の単位を明確化する。
• 最終確定点（Finality Log の確定済み範囲）を基準に単一リーダへ収束し、欠落分をSoTから再適用して整合を回復する。
• 整合性サンプルが合格した段階で READ_ONLY_EXITED を発行し、段階的に書込を再開する。

Success Criteria

• 単一リーダが確立し、書込が再開
• Read Model の再構築が完了し、整合性サンプルが合格

Evidence

• incident_id
• quorum状態の時系列（参照ID）
• リーダ収束の根拠（参照ID）
• Read Model再構築の結果（参照ID）

10.9.3.4 Read Model障害（照会系劣化運転）

Trigger

• SoT（Finality Log）とRead Modelの差分が増大
• 照会遅延が継続的に悪化

収束戦略

• 参照APIを劣化モードへ：結果を『最終確定のみ』または『受付状態まで』に限定し、誤表示の拡大を防ぐ。
• SoTとRead Modelの差分を測定し、インクリメンタル再投影またはフル再構築で整合を回復する。
• 再構築中はキャッシュを短期化し、誤表示の固定化を避ける。

Success Criteria

• 差分が収束し、通常モードへ復帰

Evidence

• incident_id
• 差分レポート（参照ID）
• 再構築実施ログ（参照ID）
• 顧客表示切替ログ（参照ID）

10.9.3.5 外部署名鍵の侵害（KeyRegistry：Watcher／アテスター／参加行）

対象 ：KeyRegistry に登録された鍵（owner_type ＝ EXTERNAL_RAIL / ATTESTER / PARTICIPANT / ZC）の漏えい・不正使用が疑われる、または確認された場合。§7.7.5 の受け皿。

Trigger

• 鍵所有者からの侵害申告、または ZC 運営による職権判断（異常な観測パターン・equivocation の多発）
• WatcherEquivocationDetected / ATTESTATION_EQUIVOCATION の急増

収束戦略

• 失効は非遡及であることを前提に組む ：revoked_at の設定は「以後を止める」操作であって「既往を無効化する」操作ではない（10_requirements.md §3.3.4-3）。したがって初動は失効と侵害ウィンドウの確定を必ず対で行う。
• 侵害ウィンドウの確定 ：[侵害開始の推定時刻, revoked_at) を確定し、当該区間に当該 key_id で成立した観測・表明を洗い出す（idx_watcher_observation_key による鍵別追跡、Attestation の attester_key_id 別追跡）。
• 影響取引の分類 ：洗い出した観測が終端化に寄与した取引を、(a) 定足数 >= 2 で他の独立主体の一致もあった＝影響なし、(b) 定足数 1 で当該鍵のみが根拠＝要再検証、に分ける。この分類ができること自体が §7.7.2 の k-of-n を持つ運用上の利益である。
• (b) の取引は個別に CASE を起票し、外部レール側の原本再照会で事実を再確認する。事実が異なっていた場合の救済は Reversal（別取引、10_requirements.md §4.3）とし、元取引の履歴は書き換えない。
• 同一 owner_ref の他の鍵・他の運用主体へ波及の疑いがある場合は、当該 owner_ref を定足数の計数から一時的に除外する（k-of-n の分母を落とすため、閾値の一時引き下げは行わず保留側に倒す）。

Success Criteria

• 侵害ウィンドウが確定し、区間内の全観測が (a)/(b) に分類済み
• (b) 全件が再検証を完了し、CASE が Close または救済取引へ接続済み
• 失効・再登録が 10_requirements.md §3.3.4 の 4 眼で記録されている

Evidence

• incident_id
• 失効・再登録の承認記録（承認者 ID・evidence_ref、10_requirements.md §3.3.4-5）
• 侵害ウィンドウの定義とその根拠（参照ID）
• 影響取引一覧と (a)/(b) 分類（参照ID）
• 再検証結果と救済取引の txid 一覧

10.9.3.6 参加行 Adapter の長期不通（Circuit Breaker 常時 OPEN）

対象 ：特定参加行の Adapter が復旧せず、Adapter 不通を理由とする SUSPENDED の滞留が積み上がる状態（§10.8.4 の運用面）。

Trigger

• Circuit Breaker が OPEN のままクールダウン→HALF_OPEN→OPEN を反復（total_denied の単調増加）
• 当該参加行宛の SUSPENDED 滞留件数・金額が Sev 分類（§10.9.2.1）の閾値を超過

収束戦略

• Decision 前後で分岐を固定する（§10.8.4）：Decision 前は DECIDED_CANCEL → CANCELLED で自動解放。Decision 後は SUSPENDED に束ね、期限超過で FAILED_EXECUTION へ昇格させる。Decision 後の失敗を取消にすり替えない。
• CASE は集約する ：CAUSE:{participant_id}:{reason_code} を集約キーとして障害 CASE 1 件に束ね、txid は関連付けで管理する（§10.7.2）。集約キーに埋め込む reason_code は実在する状態 reason_code でなければならない——実在しない値を鍵にすると、集約そのものが成立しない。参加行 1 行の障害で CASE が数万件生まれることを構造的に防ぐ。
• H_locked の滞留を放置しない ：Decision 後に a が成立しないまま長期化した枠は、§6.4.1 の解放経路（NoDebitRecordedProofSubmitted による自動解放、または CASE 4 眼の HUnlockAuthorized）で解放する。H の詰まりは当該参加行だけでなく相手方参加行の送金余力にも波及するため、滞留時間を SLI として監視する（§10.4.3）。
• 段階的再開 ：復旧検知後は HALF_OPEN の限定通過からレート制限付きで再開し、滞留分を一気に流して二次障害を起こさない（§10.7.3）。
• 参加要件への接続 ：不通が規程の許容を超えて継続する場合は、第14章 §14.3 の段階制裁（警告 → レーン制限 → 取引上限制限 → 参加停止）へ接続する。

Success Criteria

• 当該参加行宛の SUSPENDED 滞留が 0 に収束し、Circuit Breaker が CLOSED に復帰
• 滞留していた H_locked が全件、証跡付きで解放済み
• 昇格した FAILED_EXECUTION 全件が救済（Reversal／返し決済）または未実行証明で終端

Evidence

• incident_id
• Circuit Breaker 状態遷移履歴とメトリクス（total_denied / last_success_at、§10.7.3.2）
• 集約 CASE の case_id と関連 txid 一覧
• H_locked 解放の根拠（NoDebitRecordedProof / HUnlockAuthorized の承認記録）
• §14.3 の措置を発動した場合はその決裁記録

10.9.4 DR/BCP（整合条件）

• RPO：Finality Logは0、Read Modelは再構築許容。
• 訓練：年次、Step-in/復元試験（制度編の規定と整合）。

10.10 CASE（例外収束）運用テンプレ【規範】

10.10.1 CASE起票条件（自動）

• DECIDED_TO_SETTLE 到達後に b がSLA逸脱
• 証憑（bank_proof_ref）不整合（署名検証失敗／参照不能）
• Authority Check（AML/制裁）がタイムアウトし、保留が長期化
• Misrecord（誤記録）疑義

10.10.2 CASEの最低限フィールド

field	必須	説明	実体
case_id	必須	共通キー	Cases.case_id
related_txid/gtid	必須	因果リンク	Cases.related_txid / related_gtid
分類	必須	何の例外か。CASE reason_code が担う（32_api_contracts.md § 状態 reason_code）	Cases.reason_code
owner	必須	一次対応組織	Cases.opened_by（ZC/BANK/OPS）
sla_deadline	必須	期限。超過で ESCALATED へ昇格する（§10.7.4）	Cases.sla_deadline
evidence_refs	必須	根拠	Cases.evidence_refs（JSON 配列）

規範（期限の無い CASE を作らない）：sla_deadline は起票時に必ず埋める。呼び出し側が

指定しない場合は既定値（PR-CASE-SLA。30_internal_design.md §12.9）から計算する（31_schema.md § Cases）。期限が無い CASE は
Auto-Progress → Manual-Only の昇格判定（§10.7.4）の対象から落ち、「待ち続けたまま誰にも
気づかれない」状態になる——それは §10.7.4 が防ごうとしている事態そのものである。

なお、分類は当初 category（EXEC_DELAY / PROOF_MISMATCH / AUTHORITY_WAIT / MISRECORD）

という専用列を想定していたが、実装は reason_code 1 列に統合した。分類軸を 2 本持たない

という判断であり、本表はそれに合わせてある。

規範 ：CASEの更新は CaseUpdated としてFinality Logに残し、後日監査で追跡可能とする。

第11章 ベンダ実装観点での妥当性整理

要旨

本章では、RFPや実装計画に落とすために、外部設計として固定すべき要素（状態機械・I/F・証跡・運用手続）を再整理する。参加者側の実装プロファイル、テスト戦略、コストとリスクの現実的な要点をまとめる。

11.1 RFP化の粒度（規範）

• 外部設計として固定すべきは：状態機械、I/F契約、署名、証憑、運用手続、監査ログ、例外（CASE）、レーン仕様。
• 内部実装はプロファイル化し、参加行多様性を吸収する（固定しない）。

11.2 主要サブシステム（WBSの骨子）

• ZC：Ingress/API、Lane Orchestrators、Finality Log（Raft）、Read Model、Bus、Vault、Ops Workflow、Trust Registry、Capability Registry、ExternalSettlement Adapter（協議事項含む）
• 参加行：Bank Adapter（cmd/event）、Execution証憑生成（bank_proof_ref）、照会UI（a/b/Decision/Execution）、CASE連携、鍵管理（HSM）
• 共通：Schema Registry、監査基盤（WORM/保全）、監視・SRE

11.3 参照実装プロファイル（参加主体側：例）

本書の規範は「参加主体の内部がどう作られているか」ではなく、 外部に対して立証できる証憑（bank_proof_ref）と状態遷移 である。
したがって参加主体は、内部方式に応じて以下のプロファイルで参加できる。

• Profile-M（Modern） ：

  • ドメインイベントを内部でも保持し、a/b を内部確定境界として自然に生成できる構造（推奨）
  • API/Adapterは薄くし、証憑生成・監査再現が容易

• Profile-L（Legacy） ：

  • 別段・内部中継・バッチ確定等を用い、外部I/Fだけ規範に合わせる参加形態
  • 内部が即時に見えない場合でも、 証憑の発行と照会の整合 で参加可能にする

• Profile-H（Hybrid） ：

  • 一部はモダン、重要区間は既存勘定系に委譲する構成（現実解）

規範（不変） ：ZCに対しては「結果の契約（Decision/Execution/a/b）」を守ること。
内部の勘定方式差はプロファイルで吸収し、全体として相互運用性を確保する。

11.4 テスト戦略（RFPに必須）

• 契約テスト（Contract Test）：30_internal_design.md 第12章（I/F契約）を自動検証。
• 冪等・順序乱れ試験：重複/遅延/欠番を注入し、正しく収束すること。
• DR試験：地域喪失、Read-only遷移、再構築（ログ→Read Model）。
• 監査再現試験：「なぜこの金額か」「誰がいつ決めたか」「証憑は何か」を再現できること。

11.5 コストとリスクの現実的整理（設計メモ）

• 本設計は「作れる」設計だが、成功条件は I/F固定と運用設計（CASE） を最初に固めること。
• 逆に、I/Fが骨子のまま進むと、後工程で共通化作業が爆発し、最終的に事故リスクもコストも跳ね上がる。

第12章 移行・切替・共存

12.1 移行原則

• 段階導入：参加者群・レーン・取引種別のいずれかを軸にフェーズを刻む。
• 後戻り可能：各フェーズでロールバック条件と手順を明文化し、実地リハーサルを義務化する。
• 二重運用の事故抑止：冪等性とID空間統一を最優先し、二重送金・照会不整合を設計で封じる。

12.2 フェーズ計画（標準）

Phase	対象	目的	成果物	Go/No-Go
0	影響分析	業務/照会/帳票の差分確定	差分台帳、用語統一	参加者合意
1	影響小レーン	Standardの低リスク取引	互換ゲートウェイ	不一致率閾値
2	参加者拡大	業態別ロールアウト	移行Runbook	リハーサル合格
3	DNS連携	DNS計上/証跡一体化	DNS証跡ダイジェスト	監査合格
4	RTP等	追加レーン導入	SLO/監視設定	SLO達成
5	旧系縮退	共存解消	切替報告書	ロールバック不要

12.3 共存アーキテクチャ（必須）

• Coexistence Gateway：旧系/新系の相互変換、署名検証、冪等キー変換、監査ログ統合を担う。
• ID空間：旧txidと新txidのマッピングは 決定的（deterministic） であること。ランダム割当は禁止。
• 二重送金防止：
  • 旧→新、 新→旧のいずれでも「副作用は1回」の冪等規約を契約（30_internal_design.md §12.4 idempotency_key のスコープ）で強制。

12.4 Cutover Runbook（要約）

• 事前条件：鍵ローテーション完了、監視正常、リハーサル合格、当局連絡経路確認。
• 実施：Freeze（書込停止）→ Finality Log整合確認 → Switch → Soak（観測）→ 通常運転。
• ロールバック：不一致率/遅延が閾値超過、署名不正、quorum不安定時に発動。

第13章 ZC Communicator / ZC Adopter 導入モデル

13.1 目的と適用範囲【規範】

本章は、参加銀行が ZC に接続するための実装を ZC Communicator と ZC Adopter の二層に分離し、共通化（ZC保守）と個別化（各銀行保守）の境界を固定する。

• ZC Communicator：ZCが提供する共通コンポーネント（保守責任：ZC）
• ZC Adopter：各銀行が実装する個別コンポーネント（保守責任：各銀行）

規範 ：参加銀行は、ZC接続にあたり ZC Communicator と ZC Adopter を必ず併設しなければならない。

規範 ：ZC Communicator は勘定系更新（資金移動・残高更新）を実施してはならない。実施は ZC Adopter の責務とする。

13.2 用語と平仄（既存の「Adapter」との整合）【規範】

本書で既に用いる「Adapter（アダプター）」は、参加銀行境界に配置される接続要素の総称である。本章では、責任分界を明確化するため、これを以下に分解して呼称する。

• Adapter（総称）＝ ZC Communicator（共通）＋ ZC Adopter（個別）

規範 ：以後、「共通部分」は ZC Communicator 、「銀行固有部分」は ZC Adopter と表記し、両者を混用してはならない。

推奨 ：文脈上、総称としてのAdapterが必要な場合は「Adapter（総称）」と明記する。

13.3 責任分界（保守・障害・監査）【規範】

区分	機能	保守責任	障害一次切分	監査責任（一次）
ZC Communicator	ZC接続終端、Inbox/Outbox、投影、DLQ/CASE接続、共通暗号要件	ZC	ZC	ZC（共通部）
ZC Adopter	勘定系実行、資金隔離、行内AML/名義、証跡材料生成、行内運用統合	各銀行	各銀行	各銀行（行内）

規範 ：ZC Communicator の更新は ZC が版管理し、後方互換と移行期間を規定する。

規範 ：ZC Adopter の更新は各銀行が版管理し、Conformance（適合性評価）を満たすことを保証する。

13.4 配置（データ境界）【規範】（図説）

flowchart LR
  subgraph Bank["参加銀行（Bank Boundary）"]
    CORE["勘定系/周辺系"]
    OPS["行内運用（監視/ITSM/SOC）"]
    VAULT["行内KMS/HSM/WORM"]
    AD["ZC Adopter（銀行実装・銀行保守）"]
    COM["ZC Communicator（ZC提供・ZC保守）"]

    CORE <--> AD
    OPS  <--> AD
    VAULT <--> AD
    AD <--> COM
  end

  ZC["Zenith Coordinator（ZC）"]
  COM <--> ZC

規範 ：ZCとの通信は必ず ZC Communicator が終端する。ZC Adopter が直接 ZC と通信してはならない。

推奨 ：ZC Adopter は行内ネットワーク境界（行内統制の適用範囲）に配置し、ZC Communicator は「共通ランタイム」として標準運用する。

13.5 Communicator ⇄ Adopter I/F 契約（最小）【規範】

ZC Communicator と ZC Adopter のI/Fは、「冪等」「順序非依存」「説明可能」を満たす最小要件として固定する。詳細スキーマは 30_internal_design.md 第12章（I/F契約）§12.1〜§12.6 に従う。

13.5.1 冪等キーと再送（共通規範）【規範】

• すべての要求は request_id（冪等キー）を持つ。
• 同一 request_id の要求に対し、ZC Adopter は 同一結果 を返し、二重に勘定系副作用を発生させてはならない。
• ZC Communicator は Outbox により EVT の確実送達（再送）を担保する。

13.5.2 最小API（要約）【規範】

ZC Adopter は最低限以下を提供する（詳細は 30_internal_design.md 第12章（I/F契約） ）。

• ReserveFunds / ReleaseReserve（資金隔離）
• ExecuteDebit（a：支払実行）
• ExecuteCredit（b：入金実行）
• LegReadyCheck（GTIDの事前レディネス）
• AuthorityCheck（AML/制裁等：必要時）
• NameCheck（名義応答：必要時）
• BuildProofArtifact（証跡材料生成）

規範 ：ZC Communicator は上記以外の銀行固有I/Fへ依存してはならない。

13.6 資金隔離（顧客預金と別段預金）【規範＋推奨】

13.6.1 原則【規範】

資金隔離（Reservation/Isolation）は ZC Adopter の責務である。方式は固定しないが、隔離の成立・解除・再拘束は冪等に収束し、照会で説明可能でなければならない。

• パターンA：メモ拘束（available減、振替なし）
• パターンB：別段預金への振替（予約口）
• パターンC：サブ台帳隔離（隔離残高）

規範 ：取消・期限超過・CASEにより、隔離は必ず解除できなければならない。

13.6.2 別段振替を推奨する局面【推奨】

• HTLC の timelock が長い（数時間〜日跨ぎ）
• GTID の leg数が多い、または成立日跨ぎがあり得る
• チャネル競合が多い（アプリ＋窓口＋API）
• 監査・補償説明で「拘束の実体」が必要

13.6.3 図説（別段振替：Reserve→Execute→Release）

sequenceDiagram
  autonumber
  participant COM as ZC Communicator
  participant AD as ZC Adopter
  participant CORE as 勘定系
  participant SD as 別段預金（予約口）

  COM->>AD: ReserveFunds(request_id, isolation_mode=SEGREGATED_TRANSFER)
  AD->>CORE: 顧客預金→別段へ内部振替（予約）
  CORE->>SD: 振替
  AD-->>COM: Reserved(reservation_ref, as_of)

  COM->>AD: ExecuteDebit(request_id, txid, execution_mode=FROM_RESERVATION)
  AD->>CORE: 別段から支払実行（a）
  AD-->>COM: DebitConfirmed(proof_material_ref)

  alt 取消/期限超過/CASE
    COM->>AD: ReleaseReserve(reservation_ref, reason=CANCEL|EXPIRE|CASE)
    AD->>CORE: 別段→顧客預金へ戻入
    AD-->>COM: Released(as_of)
  end

13.7 レーン別プロファイル（必須＋Express例外）【規範】

13.7.1 Standard / GTID / High-Value（Hard Reservation必須）

不整合リスクを排除するため、以下の実装を必須とする。

1. Hard Reservation（支払） ：Accept時点で顧客口座から引き落とし、銀行内部の「未決済為替別段（支払口）」へ移動させること（§13.6 パターンB）。
2. Hard Landing（受取） ：入金指図を受け取った時点で、銀行内部の「未決済為替別段（受取口）」へ計上し、即座に b 証憑を発行すること。顧客口座への入金はその後に行う。

13.7.2 Express（条件付きSoft Reservation許容）

即時性が極めて重要となるExpress（店舗決済）に限り、以下の条件を全て満たす場合のみ、論理拘束（Soft Reservation / §13.6 パターンA）を許容する。

1. 上限額 ：1取引あたり PR-SOFT-LIMIT（例：5万円）以下であること。
2. 補償合意 ：万が一の残高不足（Decision後の引落失敗）発生時は、参加銀行が立替払いを行い、決済を成立させること。
3. 事後求償 ：立替分は銀行・顧客間で事後解決し、ZC上の取引を失敗させてはならない。

注 ：§13.6は「資金隔離の方式（パターン定義）」として残し、推奨・必須の文言は本節（§13.7）へ集約する。

13.8 証跡（bank_proof_ref）と秘匿【規範】

• PAYER_EXEC_CONFIRMED / PAYEE_EXEC_CONFIRMED は必ず bank_proof_ref を付与する。
• bank_proof_ref は参照であり、個人情報・秘密（HTLC preimage）・AML詳細を本文に含めてはならない（参照化のみ許容）。

規範 ：秘匿情報は Vault/WORM 等の行内統制下に保全し、外部には参照番号として提示する。

13.9 Conformance（適合性評価）【規範】

Conformance は、ZC Communicator（共通）と ZC Adopter（個別）の結合として実施し、以下を機械的に検証する。

• 冪等性（同一 request_id の収束）
• 順序非依存（逆順・遅延・重複の収束）
• 説明可能性（ as_of と next_action_hint の常時提示）
• 証跡（a/b の bank_proof_ref 付与）
• 例外収束（DLQ→CASE）

推奨 ：Conformance はCIで常時実行し、ZC Communicator の更新時に破壊的変更がないことを検出する。

規範 ：SLO・TTL・閾値等のパラメータは 30_internal_design.md §12.7（パラメータ統制）と §12.9（PR-* 台帳） により固定し、変更時は版管理と周知を必須とする。

第14章 参加要件・適合性評価

14.1 接続要件（技術）

• 回線/冗長：二経路、遅延/パケット損失のSLO
• 時刻：NTP/PTP、監査ログの時刻整合
• 鍵：HSM推奨、ローテーション、失効・再発行手順

14.2 適合性評価（Conformance）

• 契約テスト：30_internal_design.md 第12章（I/F契約）に対する自動検証
• 障害訓練：DNS_HOLD/隔離/復元を含む統合演習
• 合格証跡：test_report_ref、監査ログ、是正計画

14.3 不適合時の措置

• 段階制裁：警告 → レーン制限 → 取引上限制限 → 参加停止
• 全て証跡化し、監督当局に提出可能とする。

第15章 相互運用と段階導入ロードマップ

15.1 外部相互運用（Adapter / Gateway）

• BoJ連携：IGS結果の取り込み、DNS清算のKick/結果証跡
• 他スキーム：口座確認、Addressing、将来の新基盤（仮にCBDC等）とのI/Fを「周辺ゲートウェイ」で吸収

15.1.1 周辺ゲートウェイの責務（必須）

周辺ゲートウェイ（ExternalSettlement Adapter / Interop Gateway）は、次を必ず満たす。

• 変換：外部I/FとZC I/Fの差分吸収（型、桁、コード体系）
• 冪等：ext_instruction_id による外部指図の冪等送信
• 再照合：外部結果の再取得（pull）とZC状態の照合
• 証跡：外部由来の証跡を 検証可能な形 でZCへ取り込み、Finality Logにダイジェストを残す

規範

相互運用の失敗で最も揉めるのは「外部では処理されたが、ZCでは未了（または逆）」の類型である。周辺ゲートウェイは、結果の再照合と証跡の連鎖を 必ず 提供する。

15.1.2 相互運用の証跡モデル（Evidence Chain：規範）

ZC内部のSoTは Finality Log である。外部相互運用では、外部証跡を以下のモデルで連鎖させる。

(1) 外部証跡レコード（External Evidence Record）

• ext_system：外部系識別子（BoJ/他スキーム等）
• ext_instruction_id：外部指図ID（冪等の鍵）
• ext_status：外部状態（SENT/ACCEPTED/SETTLED/FAILED/UNKNOWN）
• observed_at：観測時刻（pull/notifyの別も含む）
• payload_digest：外部メッセージのハッシュ
• verification：署名検証結果または検証不能理由
• evidence_blob_ref：原本保管先（WORM等）

(2) 因果リンク（correlation / causation の継承規則）

• ZC→外部：送出時に correlation_id = txid 、 causation_id = last_event_id を付与（可能な範囲）
• 外部→ZC：受信/観測した外部結果は、必ず correlation_id = txid に正規化し、外部の ext_instruction_id を副キーとして保持

(3) Finality Logへの反映（ダイジェスト）
外部結果は、次の2段で扱う。

1. EXT_RESULT_OBSERVED：外部状態を観測した事実（ 外部の真偽はまだ断定しない ）
2. EXT_RESULT_RECONCILED：ZC側の状態と照合し、整合（または不整合）を確定した結果

(4) 不整合の扱い（規範）

• 不整合は「例外」ではなく 状態 として扱い、 SUSPENDED + CASE に収束させる
• 不整合解消には、外部証跡（原本）とZC証跡（Finality Log）の双方が必要

15.1.3 典型フロー（外部清算/高額即時）

1. ZCが外部へ指図送出：EXT_INSTRUCTION_SENT（ext_instruction_id を含む）
2. 外部結果を観測：EXT_RESULT_OBSERVED（External Evidence Record を添付）
3. 照合（pull再照会を含む）：EXT_RESULT_RECONCILED
4. 整合：ZC状態を進める（必要に応じて DECIDED_TO_SETTLE 等へ合流）
5. 不整合：SUSPENDED とし CASE を起票（制度の救済/補償へ接続）

15.2 参加行における導入順序（推奨）

1. Standard、DNS（証跡・監査の確立のため、一律導入が必須）
2. RTP（商流連携）
3. 条件付き（HTLC等）はプロファイルとして段階導入

15.3 互換性ポリシー

• 破壊的変更は禁止。
• 例外的に必要な場合は、制度の変更管理に従い、周知・共存期間・変換ゲートウェイを必須。

第16章 試験戦略

16.1 試験ピラミッド

• Unit → Contract（30_internal_design.md 第12章（I/F契約））→ Integration（相互）→ Soak（長期）→ Crisis（危機演習）

16.2 受入基準（例）

• SLO達成（PR-SLO-*、30_internal_design.md §12.9）
• 監査再現性：任意の取引をFinality Logから再現可能
• 危機演習：DNS_HOLDの通知・証跡・公表統制が規程通りに動く

16.3 試験環境

• 参加者向けSandbox
• 監督向け監査環境（証跡閲覧）
• データ：匿名化、再現用シナリオデータセット