ADR-0207 週次観測ログ | BizLinkPartners 社内ドキュメント

ADR-0207 (認定 TSA を従量制 2 択 (セイコー/アマノ) から確定 · 2026-07-04 受理) の Confirmation 6 KPI の観測結果を時系列で記録する。SQL 骨格は本ファイル各節 · SSoT は ADR-0207 §9 Confirmation。実 SQL の実行は、事前確認 5 点の完了 (KPI 1 · 契約着手前 · 代表取締役アクション) → TSA 契約 + G1 (TSA Strategy interface · 見積 4 人日) 実装 → スタンプ付与の稼働開始後。table 名 (tsa_stamp_log 等) はすべて仮名で、G1 実装時に実名へ確定する。

Review After: 受理後 6 か月 (2027-01-04 目安 · 半年後負債化点検)。Phase 1 切替判断・撤退条件 1-4 のいずれかが先に発火した場合は前倒しで再レビュー。

Week 0 (2026-07-07 · 契約前 · 準備段階)

事前確認 5 点が未完了 (契約未着手) のため実測データなし。6 KPI の SQL 骨格 / 記録骨格 + SLO + 実施頻度 + 撤退条件連動を先出しで整理する。スタンプ付与の稼働開始時点で本節を Week 1 として実測数値に置き換える。

KPI 1: 事前確認 5 点の完了 (契約着手前に 1 回)

SLO: 5 点 + 追加 1 項の書面取得の完了 · 未完了のまま契約しない (判断式が適用できないため)
実施頻度: 契約着手前に 1 回
撤退条件連動: 両候補とも実効単価 > ¥15/スタンプ (見積結果 or 値上げ) で ADR-0207 §8-1 発動 (6 社再比較 + ウイングアーク繰上げ判定を 3 営業日以内に発動する即時繰上げフロー)

記録表骨格 (書面 = 監査痕跡として docs/_internal/06_ops/ に記録 · ADR-0207 §11 docs SSoT 同期):

#	確認項目	取得日	書面	数値/回答
1	セイコー見積 (実効単価)	-	-	-
2	ウイングアーク初期費 (撤退条件 1 の即時繰上げ用 · 5 点と同週内に完了)	-	-	-
3	TSA API のレート上限書面	-	-	-
4	セイコー接続方式 (Cloud NAT 固定 IP で完結するか)	-	-	-
5	最低契約期間・中途解約条項 + 初回法人契約の書類提出から開通までの最悪日数	-	-	-
追	追加 1 項 (§9-1 記載 · 書面取得時に内容を特定して記帳)	-	-	-

判定手順 (錨効果の排除 · ADR-0207 §9-1): (1) 見積数値を先に記録 → (2) 判断式「実効単価 ≤ ¥10/スタンプかつ初期費 ≤ ¥100,000 の最安」で数値のみの合否を確定 → (3) 合否判定は代表取締役以外の第三者 (顧問税理士または外部エンジニア) が独立に実施 → (4) 定性情報 (シェア・実績) の参照は判定完了後の文書署名以降に限定。

KPI 2: 月次スタンプ数と費用の観測 (月次 · 目標実効単価 ≤ ¥10)

SLO: 実効単価 > ¥10/スタンプで原因調査 · > ¥15 で撤退条件 1 を判定 · Phase 1 費用 ≤ ¥100,000/月 (1 万スタンプ)
実施頻度: 月次
撤退条件連動: §8-1 (両候補 > ¥15 → 再比較 + 繰上げ) · §8-4 (月間スタンプ数 14,000 を 3 ヶ月連続超過 → ウイングアーク年間パッケージ移行を判定し 90 日以内の移行完了を目標に契約手続き開始)

BigQuery SQL 骨格 (発行数 · 請求額は請求書から手動転記):

SELECT
  FORMAT_TIMESTAMP('%Y-%m', issued_at, 'Asia/Tokyo') AS billing_month,
  COUNT(*) AS stamps_issued
FROM `${project}.${dataset}.tsa_stamp_log`
WHERE issued_at >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 90 DAY)
GROUP BY billing_month
ORDER BY billing_month DESC;
-- 実効単価 = 月次請求額 (手動転記) ÷ stamps_issued
-- 期待値: 実効単価 ≤ ¥10 (> ¥10 で原因調査 · > ¥15 で撤退条件 1)
--        stamps_issued > 14,000 の 3 ヶ月連続で撤退条件 4 (年間パッケージ移行判定)

記録表骨格 (月次):

年月	発行数	請求額	実効単価	対 SLO (≤ ¥10)
-	-	-	-	-

KPI 3: キュー滞留の日付ベース監視 (日次自動 · 目標 fallback 余裕日数の負値 0 件)

SLO: 「付与期限残日数 − fallback 契約リードタイム最悪値 6 週間 (30 営業日)」がゼロを下回る文書 0 件 · 滞留 7 営業日超で警告
実施頻度: 日次 (自動 · BQ scheduled query) + dead-man's-switch (Cloud Monitoring uptime check または Cronitor 相当 · 24 時間ハートビート途絶で代表者 SMS + メール + 顧問税理士メールへアラート · 24 時間応答なしで外部委託先へ転送)
撤退条件連動: 負値の文書 1 件で §8-2 発動 (fallback の実契約 · 独立時刻源: primary がセイコーならアマノ · アマノならセイコーまたは GMO)

BigQuery SQL 骨格:

SELECT
  receipt_id,
  queued_at,
  stamp_deadline_at,
  DATE_DIFF(DATE(stamp_deadline_at, 'Asia/Tokyo'), CURRENT_DATE('Asia/Tokyo'), DAY) AS deadline_remaining_days,
  DATE_DIFF(DATE(stamp_deadline_at, 'Asia/Tokyo'), CURRENT_DATE('Asia/Tokyo'), DAY) - 42 AS fallback_margin_days
FROM `${project}.${dataset}.tsa_stamp_queue`
WHERE stamped_at IS NULL
ORDER BY fallback_margin_days ASC;
-- 期待値: fallback_margin_days < 0 の行 = 0 件 (1 件で撤退条件 2 発動) · 滞留 7 営業日超で警告
-- 6 週間 = 30 営業日は 42 暦日で近似。営業日の厳密計算 (祝日 calendar 参照) は監視 job 側で行い、本 SQL は近似監視の骨格

KPI 4: スタンプ検証の成功率とべき等性の観測 (月次 · 目標検証成功率 100% · 重複トークン 0 件)

SLO: 検証成功率 100% (検証失敗 1 件でも原因究明を最優先) · 重複トークン検出 0 件 (検出時は監査ログの退避記録を確認)
実施頻度: 月次 (一括検証 = 電帳法の検証要件 · 製品バンドルに依存せず IntegrityGuard の検証系に自社実装)
撤退条件連動: 直接連動なし (原因究明の運用ゲート) · 重複トークンの継続検出は冪等キー (文書 ID + 発行試行 UUID) 実装の review 対象

BigQuery SQL 骨格:

-- (a) 一括検証の成功率 (月次)
SELECT
  COUNTIF(verification_result = 'success') AS verified_ok,
  COUNTIF(verification_result != 'success') AS verified_fail,
  SAFE_DIVIDE(COUNTIF(verification_result = 'success'), COUNT(*)) AS success_ratio
FROM `${project}.${dataset}.tsa_verification_log`
WHERE verified_at >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY);
-- 期待値: success_ratio = 1.0 · verified_fail = 0

-- (b) 重複トークン検出 (べき等性 · 同一文書への複数 RFC 3161 トークン発行の検知)
SELECT receipt_id, COUNT(*) AS token_count
FROM `${project}.${dataset}.tsa_stamp_log`
GROUP BY receipt_id
HAVING COUNT(*) > 1;
-- 期待値: 0 行 (検出時は監査ログの退避記録を確認 · Cloud Tasks 複数回配信への冪等キー防御の検証)

KPI 5: ルート証明書チェーンの一次資料確認 (契約時 + 年 1 回)

SLO: 各事業者のルート証明書 fingerprint + 確認日時の記録 100%
実施頻度: 契約時 + 年 1 回
撤退条件連動: fingerprint の変更を検知したら ADR-0207 §3.2 守るべき設計制約の独立性前提 (primary/fallback の時刻源独立) を再評価

記録表骨格 (総務省公開資料または各社技術資料で確認):

事業者	ルート証明書	fingerprint	確認日	一次資料
-	-	-	-	-

KPI 6: バースト再送ロードテスト (G1 着手時 1 回 + Cloud Tasks 設定変更時)

SLO: 滞留 1,000 件の同時解放が max-dispatches-per-second (TSA API 秒間上限の 50% 以下) の設定内に収まる
実施頻度: 1 回 (G1 着手時 · G1 の完了条件) + Cloud Tasks 設定変更時
撤退条件連動: 上限突破が発生したら G1 の完了とせず設定値を再調整 (min-backoff 初回 30 秒 · 倍率 2.0 の指数増加と併せて再検証)

記録骨格: 実施日 / queue 設定値 (max-dispatches-per-second · min-backoff) / TSA API 上限 (事前確認 (3) の書面値) / 解放件数 / 実測ピーク配信レート / 合否。

KPI 総括 (ADR-0207 §9 記載)

Phase 1 の TSA 費用 ≤ ¥100,000/月 (1 万スタンプ) / 契約着手から開通 ≤ 6 週間 / 「付与期限残 − 6 週間」がゼロを下回る文書 0 件 / 検証成功率 100% / 重複トークン検出 0 件。

契約 + G1 着手時の確定タスク

事前確認 5 点の書面取得 (KPI 1 · 代表取締役アクション · ウイングアーク初期費は同週内に完了)
第三者独立判定者の指名 (顧問税理士または外部エンジニア · 数値のみ合否判定の実施者)
table 名の確定: tsa_stamp_log / tsa_stamp_queue / tsa_verification_log の実名を G1 実装 (リトライキュー + べき等キー + 監視を含む) で確定し本 SQL 骨格へ埋め込み
dead-man's-switch の設定 (KPI 3 · Cloud Monitoring uptime check または Cronitor 相当 + アラート 3 系統)
バースト再送ロードテストの実施 (KPI 6 · G1 完了条件)
本ページ Week 1 更新: スタンプ付与の稼働開始 1 週間後に本節を Week 1 として実測値へ置き換え