書架
前の巻次の巻
SAKUOLIA WORKS

第4巻　要件定義書(下) ― 法制度整合性・監督当局・FX/レガシー・非機能要件

決済協調層 設計資料集
2026-09-28 ／ SAKUOLIA Works

目次

  1. 第4章 法制度・契約構造との整合性
  2. 4.1 契約構造の骨格（規範）
  3. 4.2 a/bの法的意味と最終性（Finality）
  4. 4.3 取消・組戻し・救済（規範）
  5. 4.4 誤記録訂正（唯一の超例外：規範）
  6. 4.5 個情法・業法・AML/CFT
  7. 4.6 Web3（HTLC等）に関する法務境界
  8. 第5章 監督当局への説明整理
  9. 5.1 監督当局（検査・監督）向け説明要点
  10. 5.2 中央銀行（決済システム）向け説明要点
  11. 5.3 監督モニタリング（API/レポート：枠）
  12. 5.4 想定論点と回答方針（抜粋）
  13. 第6章 クロスカレンシーFX 要件
  14. 6.1 問題定義と原理
  15. 6.2 リスク・コンプラ
  16. 第7章 レガシー勘定系アダプタ 要件
  17. 7.1 なぜ敵対的コアモデルを分離するのか
  18. 7.2 勘定系（レガシーコア）への要求仕様（API別要求仕様・対応レベル） <a id="core-requirements"></a>
  19. 7.3 要点
  20. 第8章 非機能要件
  21. 8.1 本章の位置づけ（規範）
  22. 8.2 可用性・事業継続（Availability & Continuity）【規範】
  23. 8.3 性能・応答性（Performance）【規範】
  24. 8.4 データ耐久性・完全性（Durability & Integrity）【規範】
  25. 8.5 セキュリティ非機能要件【規範】
  26. 8.6 運用性・可観測性（Operability & Observability）【規範】
  27. 8.7 保守性・可搬性（Maintainability & Portability）【規範】
  28. 8.8 非機能要件の検証（受入）【規範】

第4巻　要件定義書(下) ― 法制度整合性・監督当局・FX/レガシー・非機能要件

本巻は docs/specs/10_requirements.md の第4章〜第8章(法制度・契約構造との整合性/監督当局への説明整理/クロスカレンシーFX要件/レガシー勘定系アダプタ要件/非機能要件)を収める。前巻→第3巻の続き。

第4章 法制度・契約構造との整合性

要旨

本章では、b後取消禁止・救済はReversalという基本方針を、約款・制度・契約構造と整合させる。取消・組戻し・救済・訂正の扱いと、証跡・責任分界・利用者説明が破綻しない条件を整理する。

4.1 契約構造の骨格（規範）

  • 参加行とZC間で「結果の契約（Decision/Execution、a/b、証憑）」を固定する。
  • 参加行間の関係は、原則として ZCを介した相対関係へ整理し、責任分界を明確化する。

4.2 a/bの法的意味と最終性（Finality）

  • b（受取銀行の管理下への着金）が弁済完了（Finality）の中心概念となる。
  • a（支払完了）は利用者体験・事務上重要だが、法的弁済完了と混同しない。
  • UI・約款・FAQで用語の統一を必須とする（用語は序章「Zenith 独自用語ミニディクショナリー」を参照）。

4.3 取消・組戻し・救済（規範）

  • b成立後の取消は禁止。救済は原則として Forward Recovery（復旧後の再適用・強制Custody化） を優先する。
  • 口座都合（凍結・解約・口座不存在・残高不足等）を理由としたReversal/組戻しは禁止 とし、受取不能は受取銀行の Custody（別段預り金） として保全する。
  • 紛争・差押え等は「決済の取消」ではなく、受取銀行側のCustody資金の払出制約（法的手続き）として制度・約款で整理する。

4.3.0 Reversal の三層ゲート（規範：読み方の固定）

Reversal については、本書の 3 箇所（§3.2.2・本節・§4.3.1）がそれぞれ異なる軸を規定している。3 つは選択肢ではなく AND 条件であり、Reversal を起票するには三層すべてを通過しなければならない。この読み分けを明示しないまま各節を独立に読むと「災害時に限定」と「顧客異議で起票可」が矛盾して見えるため、ここで固定する。

層 問い 規定箇所 内容
第1層：原因事由 なぜ元取引を巻き戻さねばならないのか 本節（§4.3） 資金移動が物理的に不能であることの証明を要する（proof_type='CREDIT_FAILED_PROOF'、値域は 30_internal_design.md §12.3.3）。受理は POST /api/transfers/:txid/credit-failed-proof（受取銀行の署名付き）で、ZC はこの証明が記録された取引だけ Reversal を起票できる。口座都合は原因事由になり得ない（Custody で吸収する。API 側も口座都合の reason_code を ACCOUNT_CONDITION_NOT_A_CAUSE で拒否する）。b 未成立の場合はそもそも Reversal ではなく取消・CASE で収束させる（20_method_design.md §6.3.2）
第2層：正当化要件 誰の権限でそれを行うのか §3.2.2 (a) 受取人同意、(b) 法令・裁判所命令、(c) 当局要請 のいずれかを要する。第1層を満たしても、この 3 つのいずれも無ければ起票できない
第3層：業務区分 どの類型として記録・統計するのか §4.3.1 ReversalRecords.reason（値域の正は §4.3.1。ここでは列挙しない）。これは分類ラベルであって許可条件ではない

規範

  1. 第3層の reason 値は、第1層・第2層を代替しない。 例：CUSTOMER_DISPUTE で起票する場合も、第1層（物理的不能の証明）と第2層（受取人同意・命令・当局要請のいずれか）を別途満たす必要がある。満たさない顧客異議は Reversal ではなく CASE として受理し、当事者間の解決へ接続する——POST /api/reversals は 422 CREDIT_FAILED_PROOF_REQUIRED を返しつつ CASE を起票し、応答に case_id を含めなければならない（「拒否して終わり」にしない。契約は 32_api_contracts.md § POST /api/reversals）。
  2. 第2層の証跡は必須。 (a) の場合は受取人同意の証跡参照、(b)(c) の場合は命令書・要請文書の evidence_ref を ReversalRecords に付す。
  3. 事前承認 reason（APPROVAL_REQUIRED_REASONS）は第2層の内部統制版であり、第2層の代替ではない（§4.3.1）。
  4. b 成立前の失敗は Reversal の対象外である。20_method_design.md §6.3.2 の分岐（口座起因＝禁止／システム災害＝CASE→Forward Recovery）に従う。

4.3.1 Reversal API と承認フロー（規範）

Reversal は 新規取引（lane=STANDARD, purpose=REFUND）として起案 し、ZC は元 TX と補償 TX の関連を ReversalRecords として保全する。

前提：本節は §4.3.0 三層ゲートの 第3層（業務区分） を定める。以下の reason は分類ラベルであり、起票の許可条件ではない。第1層（原因事由＝物理的不能の証明）と第2層（正当化要件＝受取人同意／法令・裁判所命令／当局要請）を別途満たすこと。

  • エンドポイント:

    • POST /api/reversals — 補償取引起票
    • GET /api/reversals/:reversal_id — 状態照会
    • GET /api/transactions/:txid/reversals — 元 TX に紐づく Reversal 一覧

  • reason 区分 (ReversalRecords.reason)。値域の正は
    実装の正: src/zc/cases/reversal.ts#ReversalReason: CUSTOMER_DISPUTE | DUPLICATE_PAYMENT | INCORRECT_AMOUNT | INCORRECT_PAYEE | FRAUD | OPERATIONAL_ERROR

    • CUSTOMER_DISPUTE — 顧客からの異議
    • DUPLICATE_PAYMENT — 二重送金（システム的に冪等で吸収できなかった残存）
    • INCORRECT_AMOUNT — 金額誤り
    • INCORRECT_PAYEE — 受取人誤り
    • FRAUD — 不正取引
    • OPERATIONAL_ERROR — 事務起因の誤処理

  • 事前承認必須の reason（規範）: FRAUD など一部の reason は内部統制系の事前承認チケット参照（approval_ref）の付与が必須（§4.3.0 第2層の内部統制版であり、第2層の代替ではない）。実装上は APPROVAL_REQUIRED_REASONS セットに列挙し、欠落時は 422 APPROVAL_REF_REQUIRED を返す（ReversalRecords.approval_ref、src/zc/cases/reversal.ts）。

  • 状態モデル: REQUESTED → APPROVED → TX_CREATED → COMPLETED または途中で REJECTED。TX_CREATED に到達した時点で補償 STANDARD TX が出来上がり、通常の決済フローを辿る。補償 TX が SETTLED に達した時点で onPayeeExecConfirmed から completeReversal がコールバックされ COMPLETED に遷移する。

  • prefix discriminator 禁止（規範）: 補償 TX の判定は ReversalRecords.reversal_txid のルックアップで行う。txid.startsWith('TX-REV-') のような prefix 推定は使わない（再フォーマット時に silent break するため）。

  • 責任分界（規範）:

    • 起票責任: 受取銀行（顧客から異議を受けた側）または OPS。
    • 承認責任: 事前承認 reason に該当する場合は別系統（コンプライアンス部門等）。承認なしで起票された場合は ZC が 422 APPROVAL_REQUIRED で拒否する。
    • 補償実行責任: ZC（STANDARD レーンとして通常通り処理）と支払銀行（元の受取銀行が補償の支払行になる点に注意）。

4.4 誤記録訂正（唯一の超例外：規範）

  • 許容するのは「ZC障害により a到達が誤って記録された」場合の記録訂正のみ。
  • 取消ではなく 記録訂正 として扱い、時間窓・4眼承認・証拠（evidence）を必須とする。
  • すべてFinality Logに追記し、後から争点化しても立証できること。

4.5 個情法・業法・AML/CFT

  • 目的限定・最小化・保管期間・第三者提供の整理を制度文書と一体で行う。
  • Authority Check（AML/制裁）は「照会した事実」と「署名付き応答参照」をログ化し、判断基準を中央に寄せない（責任分界）。

4.6 Web3（HTLC等）に関する法務境界

  • hashlock+timelockは「条件付き拘束」として整理し、外部オラクル参照は本基盤の責任範囲外。
  • 秘密値（preimage）の取扱いは、情報管理（漏えい）・否認防止（署名）・時効（timelock）を規範化する（30_internal_design.md §15.4）。

第5章 監督当局への説明整理

要旨

本章では、監督当局への説明を「状態・証跡・統制」で整理し、問われやすい論点に対する回答方針を示す。モニタリングAPI/レポートの枠や、危機時の対外説明の統制を、方式設計の範囲で明確化する。

5.1 監督当局（検査・監督）向け説明要点

  • 統制：規範（Must）の固定（I/F、署名、証憑、運用操作）
  • リスク：決済リスク（信用・流動性・オペ）への対応（Hモデル、レーン分離、CASE）
  • 監査：Finality Logとbank_proof_refにより後日再現可能
  • 外部委託：ZCの委託範囲と責任分界、再委託、監査権限、データ管理

5.2 中央銀行（決済システム）向け説明要点

  • DNS/高額即時レーンの役割分担を尊重し、高額即時レーン域で多者協調の完了認定を要求しない。
  • DNS HOLDを状態化し、制度運用と整合した照会・再開・監査導線を提供する。
  • ExternalSettlement Adapterの冪等・相関・再照合（txid↔ext_instruction_id）を規範化する。

5.3 監督モニタリング（API/レポート：枠）

  • レーン別の遅延・失敗・H凍結・CASE件数を定期報告可能。
  • 重大障害時は「Decision/Executionどちらの軸の問題か」を即時提示可能。
  • 監督上必要なログ閲覧は、個人情報最小化の上で証跡参照（digest/参照番号）を提供する。

5.4 想定論点と回答方針（抜粋）

  • Q：なぜ非同期か？ → 低単価・疎結合・可用性のため。代償は冪等・監査で吸収。
  • Q：誤送金救済は？ → b後取消はせず、Reversalで救済。争点化しやすい取消を禁止。
  • Q：H凍結で詰まらないか？ → 安全弁として設計。解除は証憑と手続でのみ行い、対外説明可能。

第6章 クロスカレンシーFX 要件

本機能の全体像 — 要件:本章 ／ 処理方式:20_method_design.md（FX処理方式／アダプタ処理方式の章）／ 内部設計:30_internal_design.md（FX内部設計／アダプタ内部設計の章）。

6.1 問題定義と原理

6.1.1 既存ギャップ

これまでの GTID は、各通貨が脚（複数の取引を束ねたグループの中の1つ1つの取引）をまたいで
均衡すること（通貨別に payer 合計 == payee 合計であること）を要求していた。これを満たさない
GTID は advanceGtid が AMOUNT_BALANCE_MISMATCH として安全にキャンセルする
（src/zc/lanes/gtid.ts バレル、実体は src/zc/lanes/gtid/advance.ts）。この仕組みは
「両当事者がそれぞれ両方の通貨を持ち寄る PvP（Payment-versus-Payment、通貨交換の両建て決済）」
しか表現できない。そのため、payer は通貨Aしか持たず、payee は通貨Bしか受け取らないという、
本来のクロスカレンシーFXの姿を素朴にはそのまま表現できなかった。

6.1.2 解決原理（導管としてのFXP）

そこで、クロスカレンシー送金をFXプロバイダ(FXP) を導管（仲介役）とする複数の単一通貨脚
（edge）に分解する。各脚はそれぞれ単一通貨の振替であり、銀行元帳上は通常どおりの通貨別
ゼロサム（amount_currency）として扱われる。FXP が受け取り側・払い側の両方に立つことで、
通貨ごとに見ると payer 合計と payee 合計が自動的に一致するようになり、§6.1.1 で述べた
既存の検査を変更することなくそのまま通過する（20_method_design.md §17.5 均衡検査の置換 ／ 30_internal_design.md §17.4 既存コードへの接地）。

デフォルト（HTLCなし、決済は即時に進行）:

  直接 (2脚):
     payer --(A)--> FXP --(B)--> payee

  ブリッジ (3脚, 中間通貨 C):
     payer --(A)--> FXP_a --(C)--> FXP_b --(B)--> payee

このデフォルト経路には secret やハッシュロックは登場しない。決済は通常のGTID（H予約→脚ごとの
中銀レール確定）でそのまま進む。

クロスレール原子性をさらに強めたい場合は、bind_htlc=true を指定して同じ脚分解の上に
HTLC（共有ハッシュロック＋段階タイムロック）を任意で被せられる。この場合は決済そのものが
secret 公開（claim）まで遅延する:

任意（bind_htlc=true、決済は claim まで遅延）:

  直接 (PvP, 2脚):
     payer --(A, T1)--> FXP --(B, T2)--> payee        (T1 > T2)
     payee が secret 公開 → 全脚が一括 CLAIMED → 導管GTIDを登録・前進 → 決済

  ブリッジ (PvPvP, 3脚, 中間通貨 C):
     payer --(A, T1)--> FXP_a --(C, T2)--> FXP_b --(B, T3)--> payee   (T1 > T2 > T3)
     同様に secret 公開で全脚が同時に CLAIMED

ブリッジの中間通貨は、対応する from→C と C→to の ACTIVE 見積が存在する通貨であれば
よい。経路は ZC が最良実効レートで選ぶ（直接 vs ブリッジ、20_method_design.md §17.3.3 最良経路エンジン）。

6.2 リスク・コンプラ

  • 決済前検証（未実装・将来課題）: 流動性コミット前に AML/トラベルルール・着金フィルタ
    （既存の PaymentFilters/src/shared/fatf_validator.ts）を実行する設計は構想として
    あり得るが、現状 FX 導管の脚生成パス（src/zc/fx/transfer.ts/htlc.ts）には接続
    されていない。これらのモジュールは src/zc/ingress/・src/bank/ 側の入口でのみ
    使われており、FX の GTID 生成自体はその入口を経由しない。AML 等の網をかけたい場合は
    別途フックを追加する必要がある。
  • 見積透明性: payer 承認前に FXP/コスト/経路を提示する（POST /api/fx/quote、20_method_design.md §17.2 役割の規範）。
    ただし確定時には必ず再プライシングするため（20_method_design.md §17.5 均衡検査の置換 ／ 30_internal_design.md §17.2 API）、提示された経路がレート変動
    なしにそのまま実行される保証はない（min_effective_rate で防御可能）。
  • タイムアウト/再送: 見積有効期限（valid_to）・idempotency_key による冪等化
    （既存機構）。HTLC 経路ではタイムロックが追加の安全弁になる。
  • アトミシティの検証: test/integration/chaos_fx.test.ts が8通りの敵対的シナリオ
    （FXP流動性不足／quote失効／HTLCロック後のquote失効／claim対sweepの競合／脚の途中失敗／
    claimの再送／ブリッジ中間FXPの資金不足／誤secretの繰り返し）で「部分決済も二重決済も
    起きない」ことを検証している。
  • 紛争処理: Cases 連携等のスキームルール上の救済は本実装の範囲外（30_internal_design.md §17.4「将来課題」）。

第7章 レガシー勘定系アダプタ 要件

本機能の全体像 — 要件:本章 ／ 処理方式:20_method_design.md（FX処理方式／アダプタ処理方式の章）／ 内部設計:30_internal_design.md（FX内部設計／アダプタ内部設計の章）。

レガシー勘定系（既存の銀行基幹システム）に対して、ZC はどこまで「フレンドリー」

な前提を置けるか——本書はその問いへの実装上の答えである。

ZC の 13 コマンド ingress（勘定系との窓口となる 13 種類の操作）は、

「勘定系に何を要求するか」という線引きとしてはよくできている。しかし

これまでは、相手が理想的な銀行（グリーンフィールド＝制約の無い新規実装。

ここでは常にゼロサムの複式簿記を維持できる bank/ledger.ts を指す）で

ある場合しか検証されていなかった。本サブシステムは、現実の勘定系が持つ

制約を意図的に再現した敵対的コアモデルを用意し、それを相手にしても

崩れないことを前提に、6 つの「フレンドリー化」施策を実装・検証する。

［本章の規範の範囲］ 本章のうち 規範（要件）は §7.2.1 マスター表・§7.2.2 対応レベル（Tier）・
§7.2.4 の判断基準と要求しない範囲 ——すなわち「ZC が勘定系に何を要求し、何を要求しないか」——である。

§7.1（分離理由）と §7.3（要点）は、その規範がなぜこの形かを説明する背景であり、参加行・ベンダーが

充足を問われる対象ではない。

7.1 なぜ敵対的コアモデルを分離するのか

グリーンフィールド（制約の無い新規実装）である bank/ledger.ts は素直な
相手である——24 時間 365 日オンラインで、冪等（同じ呼び出しを何度実行しても
結果が変わらない）で、資金の予約もでき、残高照会もいつでもできる。しかし
現実の勘定系は、このどの性質も満たさないことが多い。この差——通信手順
（プロトコル）の違いではなく、制約そのものの違い——こそが、統合
プロジェクトが行き詰まって溶けていく沼である。legacy_core.ts は、
実運用で観測される代表的な制約を意図的に再現したモデルである:

# 制約 実際の勘定系での背景
1 バッチ窓 — 夜間バッチ中はオフライン、全 call 失敗 24/365 が困難な最大要因。オンライン停止窓を持つ
2 非冪等 — posting API に重複排除が無く、再送で二重適用 多くのコアは冪等キーを持たない
3 予約プリミティブ無し — DEBIT / CREDIT / 残高照会のみ 「hold」状態を持てない
4 ミッドバッチ照会不可 — バッチ中は残高を読めない 照合はバッチ後にしか回せない
5 タイムアウト — コアが処理する前に call が失敗し得る ack ロストの温床
6 push 口が無い — 通知を受け取れない（プルのみ） 着信サーバ新設は重い負担

アダプタ（adapter.ts）はこの 6 つの制約をすべて吸収した上で、ZC 側
からはクリーンでリアルタイム・冪等・24 時間 365 日稼働しているかのように
見せる。

重要な限界: 本サブシステムは、ZC の状態機械や src/bank/ingress.ts の
13コマンド dispatcher（コマンドを実際の処理へ振り分ける仕組み）には
一切結線していない。あくまで独立したリファレンス設計・テストダブル
（本物の代わりに使う検証用の模擬実装）であり、実際の ZC のトラフィックは
まだこのアダプタを経由しない。「勘定系に対してどこまでフレンドリーな
前提を置けるか」という設計上の問いに、単体で検証可能な答えを与えたもの
である。

7.2 勘定系（レガシーコア）への要求仕様（API別要求仕様・対応レベル）

本節について: 勘定系（レガシーコア）に対する、API 別の要求仕様と対応レベル（Tier）を定める。ZC は既存の勘定系をそのまま活かせるよう、勘定系に要求する能力を最小限に絞る。実装・テストからは、本節内のアンカー（#req-master マスター表 / #req-tier 対応レベル / #req-history 確定範囲 / #req-rationale 要求しない・縮退させる範囲 / #req-rfi ベンダー自己申告シート / #req-summary まとめ）を参照する。

「結局、勘定系システム側にどんな機能を求めているのか」への回答を、ZC ingress の 13 コマンド
それぞれについて、勘定系に何を要求し、何を要求しないかという1枚の表として固定する。

判断基準は §4-a（銀行／コアの境界を実際に何が越えるか）を正とする。

7.2.1 マスター表：13コマンド × 勘定系要求機能

列の意味:

  • 勘定系に必須の最小能力: これが無いと当該コマンドに一切応答できない
    （＝ RFI で最初に聞くべき Yes/No 質問）。
  • あると望ましい能力（任意）: 無くても ZC 側で吸収できるが、あれば
    精度・速度が上がる能力。
  • 未対応時の縮退動作: 最小能力すら無い場合に ZC/アダプタ側がどう
    代替するか。「縮退できない」は即ち Tier 0（接続不可）を意味する。
  • 関連プロファイル項目: LegacyProfile（§2）のどのフィールドがこの
    コマンドの挙動を切り替えるか。
# コマンド ZC が必要とする操作 勘定系に必須の最小能力 あると望ましい能力（任意） 未対応時の縮退動作 関連プロファイル項目
1 reserve-funds 送金前に払出側の資金を一時確保する 借方 post ＋残高照会（"予約"という専用状態は不要 — 別段預金3操作に分解可能） 予約(hold)プリミティブそのもの reservation_mode=NONE で純粋な残高チェックのみに縮退。下流失敗時は補償 Reversal(#4) で戻す reservation_mode, sync_reserve
2 execute-debit 払出側の確定的な出金（a-proof） 借方 post（オンライン時に限り可、非同期でも可） 冪等キー受理、または受付番号発行 settlement_mode=PREFUNDED_SHADOW でシャドウ承認→非同期 drain。バッチ窓中でも ZC には即答 settlement_mode, window_open_hour/close_hour
3 execute-credit 受取側の確定的な入金（b-proof） 貸方 post 大口・フラグ時の保留（手動承認）対応 同上（shadow + drain）。手動承認相当（PENDING_APPROVAL）は Tier 3 の将来項目（§4-c） settlement_mode
4 release-reserve 予約の解放（取消・タイムアウト時） reservation_mode=SUSPENSE なら借方 post の取消能力（実質、別段預金からの戻し） — reservation_mode=NONE なら no-op（そもそも hold していない） reservation_mode
5 leg-ready-check GTID（多者協調）取引の脚（leg）単位の事前準備確認（PAYER脚は残高確認＋仮引当、PAYEE脚は口座存在確認のみ） PAYER脚: reserve-funds と全く同一（借方 post＋残高照会）／PAYEE脚: account-verify と全く同一（口座存在確認のみ） reserve-funds/account-verify と同一 reserve-funds/account-verify と同一（GTID の all-or-nothing 判定は ZC オーケストレータ側で完結し、コアには一切現れない） reservation_mode, sync_reserve（PAYER）／realtime_name_check（PAYEE）
6 authority-check AML/制裁リストとの照合 なし（コアの責務外という前提） 実際の AML エンジンとの連携 常時 OK を返す（判定の責務は参加行に残る。§3.3.5-2） —
7 name-check 受取人の名義確認（PSPR/口座hashで解決、MATCH時に customer_name を返す） 口座に紐づく名義を返せること 表記ゆれ・曖昧一致の吸収（多くのレガシーコアは非対応で、ZC/アダプタ側で持つべき） realtime_name_check=false なら DEFERRED に降格（送金は止めない） realtime_name_check
8 account-verify 口座存在確認＋名義スコアリング（Levenshtein 等のファジーマッチ） 口座存在確認＋名義返却 ファジーマッチ自体（本来は ZC 側が持つべき機能で、勘定系には要求しない。§4-b） 同上 DEFERRED 降格 realtime_name_check
9 credit-notify 入金結果通知の配送 なし（push 口は不要。プルでよい） push 口があれば即時配送も選べる notify_mode=PULL を既定に、格納のみ行い銀行が取りに来る notify_mode
10 rtp-notify 支払リクエスト（RTP）の通知を仕向銀行（払出側）へ配送する なし（credit-notify と全く同一 — 純粋な通知。承諾後の実際の資金移動は、この通知とは別の通常の reserve-funds/execute-debit で行われる） push 口があれば即時配送も選べる notify_mode=PULL と同じ仕組みで格納・プル notify_mode
11 debit-settled 決済完了（SETTLED到達）を仕向銀行へ確認 なし（受動的に ack を記録できればよい。コア側からの応答は不要） — 常に ack（コア不介入） —
12 initialize-bank 参加行の口座・仕訳を初期化する 口座開設能力（通常運用の一部） — — —
13 cleanup-bank 参加行の内部データを削除する（脱退時） 口座・仕訳の削除能力 — — —

本表に「実装状況」欄を置かない理由：本表が固定するのは ZC が勘定系に要求する能力 であり、

参加行・ベンダーが充足を問われるのはこの列だけである。参照実装のアダプタが各コマンドを

どの関数で受けているかは要件ではないので、対応は file_structure.md（src/bank/legacy/）と

30_internal_design.md 第18章に置く（30_internal_design.md §10.0 の規約）。

7.2.2 対応レベル（Tier）— プロファイル設定と、その組み合わせで何ができるか

「勘定系にどこまで機能を求めるか」を個別コマンドの寄せ集めではなく、
接続レベルとして一括提示する。RFI では、各ベンダーに「御社はどの
Tier に該当しますか」を一問で聞ける形にしている。

Tier 0（接続不可）

残高照会・借方 post・貸方 post のいずれかが一切できない。
この場合、本アダプタのどのモードでも救済できない——RFI 対象外。

Tier 1（最小・被仕向のみ／バッチ専業）
role: PAYEE_ONLY
reservation_mode: NONE       (予約プリミティブなし)
settlement_mode: PREFUNDED_SHADOW  (バッチ窓あり)
notify_mode: PULL
sync_reserve: false
realtime_name_check: false
batch_ingest: true
window_open_hour / window_close_hour: 設定あり

対応できるコマンド: execute-credit（非同期 drain 経由）、account-verify /
leg-ready-check(PAYEE脚)（DEFERRED 降格）、credit-notify・rtp-notify
（プル）。
対応できない: reserve-funds・execute-debit・leg-ready-check(PAYER脚)（送信
不可なので意味を持たない — role=PAYEE_ONLY の直接的帰結であり、コマンド
自体の限界ではない）。

報告書（資金決済システムの将来像 SG）でいう「被仕向のみ参加」を選ぶ行に
相当し、参加のハードルを最も下げた形。

Tier 2（標準・双方向オンライン）
role: FULL
reservation_mode: SUSPENSE
settlement_mode: DIRECT
sync_reserve: true
realtime_name_check: true
notify_mode: PUSH または PULL
window: なし（常時オンライン）

13コマンド全てをリアルタイムに処理可能（leg-ready-check・rtp-notify
を含む — §4-a の判断基準により、この2つも他のコマンドと同じ扱いになる）。

Tier 3（フル・高度）— 未実装の将来項目

Tier 2 に加えて、以下がベンダー側にあれば、20_method_design.md の
§ ベンダー接続可否
で挙げた残存リスク（クラッシュ窓・手動承認）を閉じ
られる。Tier 3 の能力は要求しない——「無い」前提で Tier 1/2 が成立することを
先に固定し、有る場合の上積みだけを本 Tier に置く:

  • ベンダー側の冪等キー受理、または受付番号による状態照会
  • 大口・フラグ時の手動承認（保留）ワークフロー（execute-credit の
    PENDING_APPROVAL 相当。§4-c）

7.2.3 要求仕様の確定範囲

13 コマンドすべてについて、勘定系への要求（最小能力・任意能力・縮退動作）を本章で確定している。
「ZC の内部処理が複雑だから、このコマンドは要求仕様を書けない」という留保は残っていない
（そう留保していた 2 コマンドについては §4-a）。ベンダーが RFI で問われるのは
§1 マスター表 と §2 Tier の 2 つだけである。

7.2.4 要求しない／縮退させる範囲と、その判断基準

7.2.4.1 判断基準：境界を越えるものだけを数える

規範：あるコマンドについて勘定系に何を要求するかは、銀行／コアの境界を実際に何が越えるか
だけで決める。ZC 内部のオーケストレーション（GTID の多者協調、RTP の請求→承諾フロー）が
どれほど複雑でも、それは勘定系への要求には現れない。

この基準が要る理由は、実際に取り違えたからである。leg-ready-check と rtp-notify は当初
「GTID／RTP というレーン固有の多段フローに紐づく」として要求仕様の範囲外に置かれていたが、
境界を越えるものだけを数えると、両者は既存コマンドと同一だった：

  • leg-ready-check: PAYER 脚は「残高照会＋別段預金への引当」——reserve-funds と同一の操作。
    PAYEE 脚は口座存在確認のみ——account-verify と同一。GTID の all-or-nothing 判定は
    ZC オーケストレータの状態機械（GtidLegs / checkAndFinalizeGtid）に閉じており、
    銀行／コアの境界には一切現れない。コアから見れば、GTID の脚は普通の reserve-funds／
    account-verify と区別がつかない。
  • rtp-notify: 借方／貸方の post は一切発生しない純粋な通知であり、credit-notify と同一。
    支払人が承諾した後の資金移動は、この通知とは別の通常の reserve-funds／execute-debit 経路で行う。

帰結（規範）：この 2 コマンドについて、勘定系に追加の能力を要求しない。
「ZC 側が複雑だから」を理由に要求仕様を空欄にすることを禁じる——空欄は、ベンダーには
「未定義の要求が後から降ってくる」と読まれる。

7.2.4.2 名義のファジーマッチは勘定系に要求しない

規範：勘定系に要求するのは「口座に紐づく名義を返せること」だけであり、表記ゆれ・
曖昧一致の吸収（Levenshtein 距離等）は要求しない。多くの実在コアは完全一致以外の
照合手段を持たず、ファジーマッチは本来 ZC 側（またはアダプタ側）が持つべきロジックだからである。
この境界を曖昧にすると、RFI で「名義照合機能」そのものを勘定系ベンダーに要求してしまう。

7.2.4.3 手動承認（PENDING_APPROVAL）ワークフローは Tier 3 に置く

大口・フラグ時の保留（テラー承認）は、コアのシステム能力ではなく銀行の業務プロセスである。
したがって Tier 1／Tier 2 の要求には含めず、Tier 3 の任意項目として扱う。
ただし §4-a の判断基準に照らせば、この線引きも「境界を何が越えるか」で再検証すべき
候補である——実在の勘定系が承認待ちをコア側の状態として返してくる場合、それは境界を
越えるため、要求仕様に昇格する。RFI の回答を見て確定する（§5 の「手動承認」欄）。

7.2.5 ベンダー自己申告シート（RFI用テンプレート）

各ベンダーにこの表を埋めさせれば、接続前に地雷を可視化できる。

項目 質問 回答（Yes/No/一部） 備考欄
残高照会 オンライン時、残高照会に同期応答できるか
借方 post 借方の post に同期応答できるか（非同期のみなら「一部」）
貸方 post 貸方の post に同期応答できるか
予約(hold) 残高の一時確保（予約）状態を持てるか 無ければ reservation_mode=NONE
冪等性 同一リクエストの再送を検知できるか（キー受理／受付番号照会） 無ければ Tier 2 止まり
バッチ窓 オフラインになる時間帯があるか、あれば何時〜何時（JST） window_open_hour/window_close_hour
名義照合 口座に紐づく名義を返せるか 表記ゆれ吸収は不要（ZC側で行う）
通知受信 ZC からの通知を push で受け取れる口があるか 無ければ notify_mode=PULL（credit-notify・rtp-notify 共通）
バッチ取込 複数件をファイル/一括で受け取れるか batch_ingest
GTID対応 多者協調取引の脚として reserve-funds/account-verify と同じ操作に応じられるか 追加の能力は不要（§4-a）
手動承認 大口・フラグ時の保留（テラー承認）ワークフローを持つか Tier 3 相当（§4-c）
プロトコル 接続手段（MQ／専用線／バッチファイル／API 等）と電文仕様 § ベンダー接続可否 参照

7.2.6 まとめ

「勘定系にどんな機能を求めるか」は、コマンド単位（§1）と
接続レベル単位（§2）の両方で読めるようにしてある。個別コマンドを見れば
「このAPIには何が必須か」がわかり、Tierを見れば「うちの製品は結局どこまで
接続できるか」が一問で判定できる。要求仕様が空欄のコマンドは無い（§3）。

sync_reserve=false（コアが予約を同期に取って返せない）を宣言した参加行では、

reservation_mode='SUSPENSE' は NONE に縮退する（src/bank/legacy/adapter.ts

の effectiveReservationMode）。宣言どおりに hold を取ると、コアが履行も解放もできない

reserved がシャドウに残り、まさに突合（#3）が検出すべきドリフトになるためである。

縮退先はこの設計が既に持っている経路——#4 の「予約なし＋補償 Reversal」——であり、

新しい状態を増やさない。縮退したことは reserve の応答に

degraded='SYNC_RESERVE_UNSUPPORTED' として現れるので、能力の誤申告が黙って通らない。

予約・借方・解放の三つは同じ判定を通す（片方だけが hold を前提にすると、

取られていない予約を借方が探すことになる）。

7.2.7 将来課題（専門家レビューからの反映）

以下2点は、本サブシステムのコードに現存するバグではなく、金融システム専門家に
よるレビューを受けて将来 lands 予定の制度的・受入的な拡張である。両者は
同じタイミング（接続認定試験の整備）で一緒に入る——フェンシングトークンの
受入条件は、認定試験がそれを検証して初めて実効性を持つため。

7.2.7.1 将来の受入条件: フェンシングトークンの単調性検査（専門家レビュー S1 への回答）

二元帳アトミシティ（two-ledger atomicity。2PC を張れない信頼境界を越えて
複数台帳の整合をどう保証するかという論点）は、「原子性」ではなく 単一
所有者則（single-owner rule。定義は [30_internal_design.md §5 単一所有者則]
(30_internal_design.md#single-owner) を参照） で閉じる、というのが結論である。
所有権の移転は
OFFER（フェンシングトークン発行を FinalityLog に記録）→ 受領者の署名付き
ACK → TRANSFERRED の三拍子で行い、非同期境界では「動かせる者は決して
二人いない」を保証する。

このうち信頼境界を越える半分が本アダプタの受入条件になる：

  • 受入条件（将来）: 銀行側アダプタ（および venue ゲートウェイ）は、
    受け取ったフェンシングトークンの単調性を検査し、stale（旧エポック）な
    トークンを拒否しなければならない（MUST）    。単調性を検査するのは受け手で
    あり、発行側（ZC）が FinalityLog にエポックを刻むだけでは、古い所有者が
    遅れて発行した指図を受け手が握り潰せない——ここを閉じて初めて
    単一所有者則が信頼境界の外側でも成立する。これは単一所有者則の
    トラストバウンダリ側の半分である。
  • 新しい基盤を要しない: 所有権は既に owner 列として一級化・強制されている
    （docs/specs/30_internal_design.md §5 単一所有者則）。
    フェンシングトークンの受入は、その上へ積むだけで足りる。
  • 位置づけ: 当初から「スコープ外（次点）」として扱われてきた将来課題で、
    単独では意味を持たず、下記の接続認定試験（certification suite）と
    同じタイミングで lands する    （認定試験が「stale トークンを正しく
    拒否するか」を参加行アダプタに課して初めて実効化）。
7.2.7.2 将来の制度化: 参加行接続認定試験（certification suite）（専門家レビュー D1 への回答）

本番で実際に壊れるのは決済コアではなく、参加行側アダプタと照合運用
である、というのが実務上の指摘である（重複送信・遅延 ACK・時刻ずれ・
誤った証明・電文解釈違いといった「参加者の行儀」こそが実在レールの
事故の主戦場）。

  • 提言: 30_internal_design.md の § 適合性検証テストが固定していること
    が固定している敵対的コアモデルの適合性テスト群
    （test/bank/legacy/adversarial.test.ts）を、
    内部テストから「参加行の接続認定試験（certification suite）」へ制度化する。
    実在の決済網で品質を実質的に守っているのは、中核の設計美ではなく
    接続認定である——ZC の敵対的テスト群は、そのまま認定試験の種になる
    （このリポジトリの隠れた資産）。
  • 具体像: §5 ベンダー自己申告シート の RFI テンプレートが
    「宣言」だとすれば、認定試験はその宣言を実際に叩いて検証する工程になる。
    バッチ窓・非冪等・タイムアウト・オーバードラフト・並行 drain・失効 CLAIMED
    回収・stale フェンシングトークン拒否（§ 上記 S1）を、
    参加行アダプタが本当に正しく吸収/拒否できるかを、接続前に合否判定する。
  • 位置づけ: 将来／制度的作業（コード修正ではなく運用制度の新設）。
    上記フェンシングトークン受入条件（S1）は、この認定試験に組み込まれて
    初めて実効性を持つため、両者は同じタイミングで lands する。

7.3 要点

本章が固定したのは「繋がりやすい契約」ではなく、「現実の制約が揃った条件下でも
契約が壊れないか」である。RFI では、敵対的コアモデルに各ベンダー製品を当て、
「あなたの製品はこの 13 コマンドのうち、同期で返せるのはどれか」「バッチ窓・非冪等・
タイムアウトをどう吸収するか」を書かせる叩き台として使う。

設計上の教訓（経緯）：「実装の正しさ（監査に耐えるか）」と「接続可能性（ベンダーが

実装できるか）」は別の検証軸であり、片方を直してももう片方は自動的には満たされない。

実際、競合安全性を閉じるための是正が、一度は「コア内部テーブルへの直接アクセスを前提とする」

という接続不能な契約を生んでいる（経緯は 30_internal_design.md の

§ 監査で見つかった問題と是正 #8、現行の規範は

20_method_design.md §18.2）。要求仕様を書き換えるときは、両方の軸で見直すこと。

第8章 非機能要件

要旨

本章では、ZC が満たすべき非機能要件——可用性・性能・容量・耐久性・セキュリティ・運用性・保守性——を、要件（何を満たすべきか）として固定する。実現方式は 20_method_design.md、実装規約は 30_internal_design.md に委ね、本章はそれらが満たすべき受入水準のみを述べる。

参照実装の射程（規範）

本リポジトリは 機能要件（協調層のふるまい）の参照リファレンスであり、本章の非機能水準を

本番グレードで満たすことは目標にしていない。本章は「本番なら何が要るか」を規範として

固定するために在り、実装はその多くを簡易な形（単一ノード D1、全参加者共通の共有 HMAC、
開発環境の性能値など）で例示するに留める。したがって本章の各水準について実装の到達度を

30_internal_design.md §10.0 の非対称ルールで個別に追跡するのではなく、章全体として
「規範であって受入済みではない」と読むこと。機能面で個別に塞いだ穴（例：外周認証・

claim 直前の AML 再照会）はあるが、保管の耐久性・可用性・スループット・鍵管理の堅牢化
といった非機能の本丸は、規範として書いてあっても実装は達していない。この線引きの根拠は、

参照リファレンスはコピーされる——非機能を「満たしたふり」で書くと、複製した配備がその穴ごと

本番に出る——ためである。

8.1 本章の位置づけ（規範）

8.1.1 要件・方式・実装の分業

非機能は「方式設計に書いてあるから要件も満たされている」とは言えない領域である。方式は どう作るか を述べるが、どこまでできていれば合格か を述べない。本章はその欠けている半分を埋める。

層 何を固定するか 所在
要件（本章） 満たすべき水準と、その測り方・合否判定 本章
方式 その水準を実現するアーキテクチャ・縮退・運用 20_method_design.md 第1章・第9章・第10章
内部設計 実装規約・不変条件・移植契約 30_internal_design.md 第6章・第7章

8.1.2 SLO / SLA との関係（混同の禁止）

  • 本章の要件＝設計・調達の受入水準。RFP・接続認定・監査で「充足しているか」を問われる対象。
  • SLO（20_method_design.md §10.9.1）＝運用中の目標。逸脱したら自動エスカレーションが起きる運用上のトリガ。
  • SLA＝参加者との契約上の保証。
  • 三者は別物であり、同じ数値である必要はない（通常、要件 ≥ SLO ≥ SLA の順に緩む）。本章はレイテンシについては PR-SLO-* をそのまま要件として採用し、二重管理を避ける。

8.1.3 値の扱い（伏せ字基準に従う）

本章の数値は 30_internal_design.md §12.9.1 の基準に従って扱う。制度が確定する水準は PR-NFR-* として名前で参照し、値は 30_internal_design.md §12.9 の台帳で管理する（公開版では非公開）。技術的既定値は具体値を本文に書く。

規範：本章に新しい非機能水準を追加する場合は、必ず対応する PR-NFR-* を 30_internal_design.md §12.9 台帳へ同じ変更で登録する。名前の無い伏せ字（「所定水準」等）を本章に残してはならない。

8.2 可用性・事業継続（Availability & Continuity）【規範】

8.2.1 可用性目標

# 要件 水準 測定方法（SoT）
A-1 受付・Decision 系（POST /api/transfers ほか確定を伴う API）の可用性 PR-NFR-AVAILABILITY-DECISION 成功応答率。母集団は ZC Ingress の受理記録、確定の事実は Finality Log と突合可能であること
A-2 照会系（GET /api/transactions/* ほか）の可用性 PR-NFR-AVAILABILITY-QUERY 同上。A-2 は A-1 より高い水準とする（縮退中も照会は生き続ける設計であるため。20_method_design.md §9.2）
A-3 任意の 1 地域（リージョン）喪失時の継続 新規 Decision を継続できること 過半数が地理的に分散した配置（20_method_design.md §1.3.0）
A-4 過半数（quorum）喪失時の挙動 Read-only へ自動縮退し、誤決定を書かないこと SystemQuorumLossActivated が GLOBAL チェーンに記録されること

規範（可用性の定義）：A-1 の「利用可能」とは 応答が返ること ではなく、確定要求に対して確定または明示的拒否のいずれかを、契約どおりの語義で返せることをいう。REJECT_UNAVAILABLE を返している時間は不可用として計上する。「拒否は返しているから可用」という計上は禁止する——それを許すと、Read-only 縮退中も可用率 100% になり、指標が意味を失う。

8.2.2 RTO / RPO

# 要件 水準
A-5 RPO（許容データ損失） 0。合意ログにコミット済みの Finality Log エントリは、いかなる障害でも失われてはならない（20_method_design.md §9.6）
A-6 RTO（復旧目標時間） PR-NFR-RTO
A-7 Read Model の全再構築時間 PR-NFR-READMODEL-REBUILD。Read Model は捨てて再構築できることをもって復旧要件を満たす（原則1）

規範（RPO=0 の意味の限定）：RPO=0 が保証するのは 協調事実（Decision・所有権移転・受領した署名付き証明）についてである。金銭事実の正は各参加行の元帳にあり、ZC はこれを保有しない（20_method_design.md §6.1 の精密化）。したがって ZC の耐久性要件は「乖離しない」ではなく「すべての乖離が有界時間内に検出・帰責される」ことに対して定義される（B-3）。

8.2.3 計画停止

# 要件
A-8 計画停止を前提としない。スキーマ変更・デプロイ・鍵ローテーションは無停止で実施できること（32_api_contracts.md § メッセージ・スキーマ進化と互換性政策 の n / n-1 併存受理がその手段）
A-9 やむを得ず停止する場合、事前告知期間・代替手段・参加行への影響を制度の変更管理（30_internal_design.md §12.7）に従って周知すること

8.3 性能・応答性（Performance）【規範】

8.3.1 レイテンシ

レイテンシ要件は 20_method_design.md §10.9.1 の SLI/SLO 定義をそのまま要件として採用する（PR-SLO-STANDARD-P99 / PR-SLO-RTP-P99 / PR-SLO-BULK-COMPLETION / PR-SLO-DNS-CYCLE-CLOSE）。算定式は 20_method_design.md §10.9.1.1、母集団の SoT は Finality Log とする。

これに加えて、本章は次を要件として固定する。

# 要件 水準
P-1 同期応答（受付 API の受理/拒否）は、非同期の後続処理の完了を待たないこと 契約上の語義（20_method_design.md §2.1）に反する待ち合わせを禁止する
P-2 Express の同期 Decision は店舗導線で成立する応答時間であること PR-SLO-STANDARD-P99 とは別枠。値は PR-NFR-EXPRESS-P99
P-3 照会応答の鮮度 freshness_level が GREEN（Read Model の遅れが既定 10 秒未満）である割合を運用指標として持つ。閾値・測定基準の定義は 30_internal_design.md §13.6 を正とする。測るのは Read Model の遅れであって取引の古さではない——後者で測ると正常完了した取引がすべて RED になり、指標が意味を失う

規範（測定の SoT）：性能指標は必ず Finality Log と突合可能な形で算定する。Read Model 由来のメトリクスは補助であり、SoT の代替にしてはならない（20_method_design.md §10.9.1.1）。

8.3.2 容量・スケーラビリティ

# 要件 水準
P-4 設計ピーク受付レート PR-NFR-PEAK-TPS（レーン別）
P-5 ピーク係数（平常時比の設計余裕） PR-NFR-PEAK-FACTOR。給与・年金・自治体支払・EC セール等の予見可能なピークを吸収できること
P-6 スケール方式 水平（シャード追加）でスケールできること。txid/gtid 単位でシャードを切る前提（20_method_design.md §1.3・30_internal_design.md §16.1）であり、単一シャードの垂直増強に依存する設計は不可
P-7 縮退時の処理能力 1 地域喪失時も PR-NFR-DEGRADED-CAPACITY を維持すること

規範（ピークは「捌く」か「均す」かを明示する）：非同期 I/F を採る理由の一つはピーク平準化である（20_method_design.md §4.1）。したがって P-4 は「同期受付のピーク」に対する要件であり、後続の非同期処理は平準化してよい。ただし平準化の結果が SLO を破ってはならない（P-1〜P-3 との同時充足）。

8.4 データ耐久性・完全性（Durability & Integrity）【規範】

# 要件 水準・判定
B-1 Finality Log の追記専用性 UPDATE / DELETE が構造的に不可能であること。改ざんはハッシュチェーンで検知できること（20_method_design.md §8.2.1）
B-2 改ざん検知の外部性 内部 WORM だけに依存しないこと。チェーン先頭ハッシュを複数の独立主体へ日次配布し外部アンカーとすること（§3.3.3）
B-3 乖離の検出可能性 ZC と参加行元帳の乖離が、有界時間内に検出され帰責されること。検出手段（照合）を持たない構成は不可
B-4 監査再現性 任意の取引について「なぜその金額か／誰がいつ決めたか／証憑は何か」を Finality Log から再現できること（20_method_design.md §16.2）
B-5 保存年限 記録クラス別に §3.3.5.1（法定下限）と §3.3.2.1（データ最小化観点）の長い方を WORM 期間の下限として強制すること
B-6 オンライン即時照会可能期間 PR-NFR-RETENTION-ONLINE。これを超える期間は WORM 退避を許容するが、取り出し手段と所要時間を規程で定めること

8.5 セキュリティ非機能要件【規範】

技術的な統制方式は 20_method_design.md 第7章、鍵の制度統制は本書 §3.3.4 に規定する。本章は充足水準のみを固定する。

# 要件
S-1 ZC は秘密鍵で他者になりすませないこと。ZC が保持するのは検証用公開鍵であり（§3.3.4）、参加行の秘密鍵を保持しない
S-2 ZC は秘密値を永続保持しないこと。HTLC の preimage は保持せず、secret_hash と検証証跡のみを持つ（§3.2.3-4）
S-3 鍵はローテーション可能であること。無停止で新旧併存でき、失効は非遡及であること（§3.3.4-3・§3.3.4-4）
S-4 単一の鍵侵害が単独で資金移動を成立させないこと。外部レール観測は相異なる運用主体の定足数を要する（20_method_design.md §7.7.2）
S-5 アクセスは目的コードなしに成立しないこと。目的コード・承認者の無いアクセスは自動遮断されること（§3.3.2.2.1.1-2）
S-6 PII を保持しないこと。ZC は氏名・住所・口座番号を保持せず、顧客識別子はソルト付ハッシュのみとする（§3.3.2）
S-7 参加行間の越境参照が構造的に不可能であること。ある参加行が当事者でない取引・フロー統計へ到達できないこと（§3.3.2.3-1）

未充足（§8.8 の開示規範による。充足している要件は 30_internal_design.md §10.0 の規約に従い注記しない）

  • S-4 は申告された確定種別に依存する——機構（相異なる運用主体の定足数）は規範化され、既定値もレール別に効き（PUBLIC＝2）、種別を欠くクロスチェーン脚は拒否される。残るのは (a) その種別を誰も検証しないこと（PUBLIC の鎖を PRIVATE と申告すれば定足数は 1 に落ちる）、(b) Watcher の独立性が制度側で未検証であること（20_method_design.md §7.7.2・§7.7.3）。
  • S-5 / S-7 は鍵の登録が全参加行に行き渡っていない——目的コードのゲート・当事者判定・アクセス監査台帳・主体認証（KeyRegistry の参加者鍵によるリクエスト署名）はすべて全照会経路に掛かっている。強制は鍵の登録状態で決まるため、鍵を登録していない参加行は申告のみで読める（移行のための意図的な経路。32_api_contracts.md § 照会の認可）。系として「参加行が他行を騙れない」と言えるのは全行の登録が完了した時点であり、残っているのは運用（登録の督促と期限）であって機構ではない。

いずれも本番化の必須条件として 30_internal_design.md 第10章 Roadmap で追跡する。

8.6 運用性・可観測性（Operability & Observability）【規範】

# 要件
O-1 例外が状態として表現されること。未決・不整合は必ず SUSPENDED → CASE に収束し、ログの目視に依存しないこと（原則4）
O-2 属人的運用を前提としないこと（原則7 No Heroics）。恒常的な時間外対応や個人の記憶に依存する手順を要件充足の前提に置かない
O-3 照会だけで日々の事務が回ること。20_method_design.md §10.4.1 の照会メニューを提供し、as_of / next_action_hint / next_retry_at を常時付与すること
O-4 CASE が人手に比例して増えないこと。同一原因の CASE は集約され（20_method_design.md §10.7.2）、Auto-Resolvable / Auto-Progress が既定であること
O-5 全応答が追跡可能であること。X-Request-Id が全応答に付与され、構造化ログと突合できること（32_api_contracts.md § リクエストトレーシング）
O-6 重大な運用操作が 4 眼であること。cap 変更・強制停止/再開・誤記録訂正・Circuit Breaker リセットは 4 眼承認と evidence_ref を要すること（20_method_design.md §10.5）

8.7 保守性・可搬性（Maintainability & Portability）【規範】

# 要件
M-1 破壊的変更を無停止で移行できること。n / n-1 の 2 世代併存受理と公表された非推奨期限を持つこと（32_api_contracts.md § メッセージ・スキーマ進化と互換性政策）
M-2 単一ベンダー・単一クラウドに固定されないこと。保管バックエンドは移植契約（30_internal_design.md 第7章）を満たす複数候補から選択可能であること
M-3 移植の完了を機械的に判定できること。30_internal_design.md §7.3 の受入条件（方言コンフォーマンス緑・chaos 全通過・縮退の観測・線形化可能性・split-brain 安全・対話型トランザクション不使用）を合否基準とすること
M-4 仕様と実装の乖離が検出されること。値域・索引・語彙・参照の整合を CI で機械検査すること（30_internal_design.md §9 静的解析インバリアント）

未充足（§8.8 の開示規範による）

  • M-2 は未充足——実行環境は Cloudflare 固有バインディング（Workers/D1/Queues/R2）に密結合しており、抽象化層は未着手。
  • M-3 は部分充足——移植契約は文書化とコンフォーマンステスト化まで済んでいるが、実バックエンド上での合否判定（線形化可能性・split-brain 安全）は未実施であり、これらは実バックエンドが無ければ判定できない（30_internal_design.md §7.3 条件0 の但し書き）。

いずれも 30_internal_design.md 第10章 Roadmap で追跡する。

8.8 非機能要件の検証（受入）【規範】

本章の要件は「宣言」ではなく「検証されるもの」として扱う。検証手段を持たない非機能要件は要件として採用しない。

要件群 検証手段 頻度
可用性（A-1〜A-4） 障害注入（地域喪失・quorum 喪失）を含む DR 試験。20_method_design.md §11.4・§16.1 の Crisis 段 年次
RTO/RPO（A-5〜A-7） Finality Log からの Read Model 全再構築を実測 年次
性能・容量（P-1〜P-7） ピーク相当負荷での Soak 試験。母集団は Finality Log リリース毎＋年次
耐久性・完全性（B-1〜B-6） ハッシュチェーン監査バッチ、外部アンカーの包含検証、WORM 整合性レビュー（§3.3.3） 日次（自動）＋年次（監査）
セキュリティ（S-1〜S-7） 接続認定試験（§7.2.7.2）＋年次第三者監査 接続時＋年次
運用性（O-1〜O-6） 危機演習（DNS_HOLD の通知・証跡・公表統制。20_method_design.md §16.2） 年次
保守性・可搬性（M-1〜M-4） 契約テスト・移植コンフォーマンス（30_internal_design.md §7.3） CI 常時

規範（未充足の明示）：本章の要件のうち現時点で未充足のものは、充足しているかのように書かない。S-4（確定種別未指定の脚と Watcher 独立性）・S-5／S-7（参加者鍵の登録が全行に行き渡っていない）・M-2（実行環境の可搬性）・M-3（実バックエンド上での判定）は未充足であり、30_internal_design.md 第10章 Roadmap で追跡する。要件を下方修正して「充足」に見せる操作を禁止する。

「部分充足」を「充足」と書かない（規範）：機構が 1 経路にでも入っていれば充足と書きたくなるが、要件文が系全体を対象にしている場合（S-5・S-7 が典型）、1 経路の充足は充足ではない。要件の主語の範囲と実装の適用範囲が一致して初めて充足と書ける。

逆に、残っている欠落を実際より広く書かない（規範）：S-5／S-7 は経路を全照会へ広げた段階で「機構が無い」から「主体の認証が無い」へ変わった。残件の記述は、残件が縮んだらその通りに縮める——広いままにしておくのは安全側に見えて、Roadmap の優先順位を誤らせる（何が本当に足りないかが埋もれる）。

裏返しの規範（充足を書かない）：上記の対として、充足している要件にはその旨を書かない。設計書は規範を現在形で述べる文書であり、進捗表ではない——沈黙が「規範どおり」を意味する。書き方の詳細は 30_internal_design.md §10.0（実装状況の書き方）を正とする。

PDFを作成

フォントは初回だけ読み込むため、1回目は時間がかかります。

用紙
組み方向
表紙
本文