🎯Single Source of Truth（SSoT）

4リポ共通の確定事項（正）。ターゲット OS / Asterisk 版 / ポート / verdict 経路など。各リポはここを参照する。

🕒 最終更新: 2026-09-16（JST）

このページは Aegis 全体（aegis-platform / aegis-sip-bridge / voice-edge / aegis-docs）の 唯一の正（Single Source of Truth） です。ターゲット OS や Asterisk 版などが各リポで食い違う （cross-repo drift）のを防ぐため、確定事項はここに一本化します。

確定事項（正）

本命（A22）と 凍結された設計

A22 と Route C の関係: voice-edge A22 は telephony（回線・Asterisk・AudioSocket）の土台、 Route C（OpenAI Realtime GA・既定モデル gpt-realtime-2.1）は AI 応答の本命。両者は別レイヤで、A22 の上で Route C が動く。

verdict の流れ（経路を取り違えない）

判定値（verdict）の戻し経路と、通話前のルート判定（route-decision）は 別レイヤ です。混同しないこと。

• 通話前 — route-decision: 着信時にどのルートで処理するかを決める。curl（HTTP）で問い合わせる。 応答の decision は 4値（block / human / ai / take_message）。 ★action（verdict の語彙）とは別物。混同しないこと——語彙も層も違う。 ⚑ 値のほかに 2 つの扱いがある（値ではない）: 空文字＝判定できなかった → dialplan は静的フォールバックへ倒し WARNING を出す （voice-edge 20-from-hikari.conf:161-162・ve=e94704495635）／ 4値以外の未知の値 → 人へ倒す（同 :167-168・ve=e94704495635）。 ⚑ 確定設計（2026-09-16）では、空・不正・401・時間切れは静的フォールバックではなく固定電話へ 1 回発呼する（第 1 段 E01・未実装）。 ★この 2 つを一緒に書かないと、現地が「4値しか来ない」と読み違える。 ⚑ 行番号は版が変わると動く（voice-edge 側の注記どおり）。上の ve= は この行を書いた時点の voice-edge の版（sha）——読むときは、まずこの sha で 実物を確認すること。
• Realtime の声（voice）: 電話の経路で実際に効く許可リストは bridge が持つ 10 値 （alloy / ash / ballad / coral / echo / sage / shimmer / verse / marin / cedar）。 既定は marin。出典は 2026-09-02 の実測——wss://…/v1/realtime へ session.update を送り、 不正値に対して相手（gpt-realtime 本体）が返したエラー本文の許可リストから採取した（推測ではない）。 ⚑ aegis-platform の openai_realtime_voice は別物——ブラウザ版 realtime-demo 専用の既定値で、 電話の経路とは未接続（backend/config.py:163-165 が自らそう書いている）。 同じ 10 語が並んでいても、効く先が違う。
• 通話中 — 遮断（verdict）は行わない（2026-09-16 訂正）: bridge には classify_call（should_terminate=true）→ 締めの発話後に AEGIS_UUID を AMI Status で逆引きして Hangup(cause=21) するコード（D-1）が残っているが、 conversation_may_terminate() が常に False のため どの通話でも発火しない（br=a557a5b1d41d・src/bridge.py）。 should_terminate は AI に「用件を預かる側へ」進ませる材料として記録に残るだけ。 確定設計（案A）はこの経路と terminate_pending・閾値照合・全チャネル探索を 撤去する。 旧A案（AMI DBPut → AstDB → dialplan DB()）も不採用（ADR-0001）。dialplan の h 拡張に DB_DELETE(aegis_verdict/…) が残るが書く側は無い。
• 切断安全弁（AEGIS_TERMINATE_MIN_SCORE・既定 0.8）: 上の道が発火しないので電話の経路では効いていない。 platform の verdict port が導出する should_terminate はブラウザ版デモと記録で使う値であり、電話を切る指示ではない。
• 開幕フロア・ガードレール（opener floor / L1 rules）: 「権威フレーム＋確認だけ」型の開幕なりすまし営業・詐欺は、 決定的発話が来る前の 1〜2 ターン目に spam_score が沈み（実測 0.1〜0.2）、正当寄りに誤判定されて人へ素通りする。 これを塞ぐため、verdict port を通る champion の spam_score に **開幕フロア 0.6 を OR 合成（max 合成）**する。
  • 検出（backend/engine/opener_floor.py）: NFKC 正規化のうえ、① 開幕テンプレ substring（還付金 / 保険年金課 / 無料点検 / モニター価格 / 内容のご確認だけ 等）と、② 「権威語（市の / 行政 / 役所 / 自治体 …）∩ 委託語（委託 / 委任 / 受託）」の複合一致（語順・助詞非依存。片方だけでは発火しない）。
  • フロア 0.6 は安全弁 0.8 未満なので 単独では切断しない（grey 帯＝人へ倒すだけ）。should_terminate は フロア後の spam_score から既存の導出規則で算出する（terminate の二重化はしない＝verdict port 契約）。
  • score_source は rules のまま（L1 rules 層のガードレール）。将来 LLM が champion になっても同一関数を LLM score に OR 合成する。
  • 根拠: adversarial A/B（攻撃56ターン・正当48ターン）で 突破（score<0.5）3→0、正当巻き込み 0 件 （＝誤爆ゼロコスト）を実測。詳細は aegis-platform decisions/ab_replay_2026-07-06.md。

通話後データ記録（学習データの本線）

通話中の「遮断」とは別に、通話が終わったら会話全文と判定を残すレイヤがある。これが moat（データ資産）と 分類器改善（eval）の土台になる本線。

• 経路: bridge（Route C）が通話終了時に POST /api/realtime/transcript-final へ 1 回だけ 送る。 中身は 会話全文（caller: / ai: の順序付き） ＋ 通話中 classify_call の直近 LLM 判定（spam_score / detected_category）。
• fail-safe: 送信失敗でも通話終了処理は止めない。文字起こしが 0 件でも判定があれば送る（判定欠落を防ぐ）。
• 保存先: call_logs に upsert（キー = 通話 UUID）。ここに溜まった行を 人手レビュー → 学習 → eval で回すのが本線。
• 通話中の判定とは独立。人へ倒れた通話・用件を預かった通話も含めて全通話ぶん記録するのが狙い。
• 会話全文判定（llm_conversation）: この call-end 経路で、会話全文を 会話 judge（全文を1回 LLM 判定）にかけた verdict を記録の正とする（下記 precedence）。per-turn の noisy な判定（開幕で沈む・機微語で跳ねる）を、会話全体を 見た判定で上書きするのが狙い。設計: aegis-platform decisions/aegis_scorer_v3_design_2026-07-07.md（配線は未実装・ 本節は掟に従い実装に先行して契約を確定するもの）。

usage メタデータ（AIが使った秒数・取りこぼしの記録）

通話後データ記録（上記）の POST body に、OpenAI の課金原価に対応する使用量を載せる。 通話全体の秒数ではなく、AI応答の生成に実際に使われた秒数を送る（理由: 課金の原価は AIが動いていない時間には発生しない）。

集計の単位（2026-09-10・岡田さん確定。bridgeにも効く）: usageは 月ごと・顧客ごとに集計する。 月は暦月（JST）——UTCの月境界でも「直近30日」でもない。occurred_at（UTC）をJSTへ変換してから 月境界で丸めるのは pf 側の集計ロジックの責務。★★ここが曖昧だと、月末（JST）付近に終わった通話が UTCでは前日・翌日の月に属して見え、集計が別の月へ落ちる。bridgeは変換・丸めを一切行わず、UTCの 絶対時刻をそのまま送るだけにする（変換規則を1か所（pf）に閉じる。第12条）。 集計の残り4本の物差し（件数 / トークン入力・出力を分けて / 円換算の為替 / ターン数）は いずれも pf 側で保持する設定・計算であり、bridgeが新たに送るフィールドは増えない （トークン入出力は上表で送信済み・ターン数は既存の caller_turns を使う）。上限は複数の物差しで 持てる形にし、空なら上限なしとする（pf 側の設計）。

None の契約（両リポで守ること。片方だけの約束にしない）:

• null（未送信を含む）は「測れなかった」を意味する。0 は「本当に使っていない」を意味する。 両者を混同しない（フィールド名不一致などで取得に失敗した場合は null を送る。0 を代用しない）。
• 受け側（pf）は null を「使っていない（$0）」として扱わない。cost_usd の計算・上限判定の対象外とし、 usage_events に 0 の行を作らない（人が見る対象として残す）。金額の上限判定に限っては 「分からなければ通す（fail-open）」は正しくない——分からないことが分かる形で残す。
• dropped_after_snapshot が 1 以上のとき、その通話の usage は不完全集計として扱う（詳細は pf 側の設計に従う）。

出典: aegis-sip-bridge docs/design/DESIGN_D0_F14_USAGE_METADATA_20260910.md（PR #160・ bridge 側で何を捕まえて送るかの設計。T2 割り2回目=打ち止め）。aegis-platform 側の受け口は PR #280（pf 側の設計・本ページ確定後に反映）。

score_source（どの脳の score か）

call_logs.spam_score には 3 種類の判定源が入り得るため、score_source 列で必ず区別する（verdict 二重化への対処）。

• どの score_source が分類器として正確か（＝eval の話）は未確定。実データが溜まってから eval（scripts/eval_scorer.py --source rules|llm|llm_conversation）で同一 gold で比較して決める。
• これとは別軸で、「どの判断にどの score_source を使うか（ルーティング vs 記録）」は下記 precedence で確定済み （分類器の優劣とは独立。混同しないこと）。
• 初期観測: ルール層は言い換え・STT 誤りに弱く見逃しが多い / LLM 層（per-turn）は捕捉するがコスト・レイテンシがかかり、 開幕1〜2ターンで沈む/機微語で跳ねる noise がある / 会話全文判定はその noise を弧で均せるが通話後にしか出ない。 名札があるので後から公平に測れる、が現時点の確定事項。

verdict port 契約（分類脳の唯一の入口）

判定を求める全経路（transcript-tick / transcript-final / bridge の classify / 将来の Rhodium webhook）は、 verdict port という単一の契約を通して分類脳を呼ぶ。champion が rules か llm か・shadow 並走の有無・ guardrail の適用は port 内部の関心事であり、呼ぶ側からは不可視（詳細設計: 00_Daimyo_Brain/decisions/aegis_L3_design_2026-07-04.md L3-D4）。

入力（VerdictRequest）:

出力（Verdict）:

契約上の不変条件（fail-open を契約に内包）:

1. should_terminate を port の外で独自計算しない（二重化の禁止）。正は常に action、should_terminate はその投影。
2. port は例外を呼び出し側に漏らさない。内部エラー・timeout は action="error"（grey 側＝人へ）の Verdict を返す。
3. L1 決定的ゲート（whitelist / hours / auth / blocklist）は L3（llm）判定より常に上位。

verdict の precedence（score_source 併存時の優先順位）

1 通話に複数の score_source（rules / llm / llm_conversation）が併存し得る。 どれを「正」とするかは、問う”判断”によって決まる（分類器としての優劣＝上記 score_source 節の eval とは別軸）。

1. ルーティング（AMI Hangup / 取次）は通話中に確定するため、原理的に signal-so-far しか使えない。 通話終了後の llm_conversation はルーティングを事後に覆さない（通話は既に終わっている）。
2. call_logs の「記録上の正」・eval の学習ラベルは llm_conversation を優先する。 per-turn の noisy な判定ではなく、会話全体を見た判定を moat（データ資産）の正とする。ライブの per-turn 判定も score_source の名札付きで破棄せず保持する（後から公平に測るため）。
3. 二重化禁止に違反しない理由: 上記「契約上の不変条件 1」が禁じるのは should_terminate を action の外で 独自計算する二重化であって、同一通話に複数 score_source が名札付きで併存することではない （score_source 節はもともと複数併存を前提に設計されている）。各 verdict の内部では should_terminate は 常に action からの一意な導出値。
4. fail-open の不変条件（会話後判定はライブを切らない）: llm_conversation は 記録・学習専用であり、 実チャンネルの切断（AMI Hangup）を発火しない。会話後判定がどれだけ高スコアでも、対象通話は既に終了しており 遡って切ることはない。ライブの切断安全弁（spam_score ≥ AEGIS_TERMINATE_MIN_SCORE）は従来どおり signal-so-far にのみ適用する。（会話全文判定を通話中に走らせ切断へ関与させる将来案＝準ライブは、per-tenant の誤爆ゲートを 満たしてからの別決定とする。本節時点では llm_conversation は切断に関与しない。）
5. llm_conversation は observed であって gold ではない（D6 準拠）: 会話全文判定の出力は モデルの予測記録 （llm_observed と同格の llm_conversation_observed）であり、正解（gold_is_spam / gold_category）ではない。 gold への昇格は 人手ラベルを必ず経る（call_log_id を保持して学習隔離＝D6）。会話全文判定の予測を無検証で gold 化してはならない（評価基盤の汚染禁止）。

src の共有方針

電話 1 本の受け渡し契約（2026-09-16 確定・未実装）

確定設計（案A）の受け渡しは aegis-docs docs/PHONE_CALL_CONTRACT.md に 1 枚で固定した。このページの上の節は現行コードの姿で、 契約の項目はまだ実装されていない。岡田さんの確定回答（再決定しない）:

更新履歴

• 2026-09-16: 現行コードと違っていた説明を訂正（第 1 段 D01）。通話中の自動切断（AMI Hangup・D-1）は conversation_may_terminate() が常に False で発火しない事実に合わせ「行わない・撤去予定」へ。切断安全弁は電話の経路で効いていない旨を明記。 route-decision の行番号を ve=e94704495635 に更新し、確定設計では判定不能を固定電話へ倒す（未実装）と注記。 「電話 1 本の受け渡し契約」節を新設し、docs/PHONE_CALL_CONTRACT.md（D00）と岡田さんの確定回答 5 件を登録。

• 2026-09-10: 「usage メタデータ（AIが使った秒数・取りこぼしの記録）」節を新設。 ai_active_seconds / tokens_in / tokens_out / dropped_after_snapshot / occurred_at を 確定値として登録し、null（測れなかった）と 0（本当に使っていない）を区別する契約を明文化した。 occurred_at は UTC・ISO 8601固定で送り、暦月（JST）への丸めは pf 側の集計責務と明記 （岡田さん確定: usageは月ごと・顧客ごと、月は暦月JST。bridgeで変換すると変換規則が2か所に散る）。 aegis-sip-bridge 側の設計（PR #160・T2割り2回目=打ち止め）を先行させ、値を実装する前に ここへ登録する（逆順禁止の原則どおり）。既存の call_seconds（usage_events）とは別物である旨も明記。 aegis-platform 側の受け口（PR #280）はこのページの確定後に別便で反映する。

• 2026-09-05: Realtime の既定モデルを確定値として追記（gpt-realtime-2.1）。2026-09-02 の岡田決定が bridge には入っていた（src/bridge.py:166,173 / deploy/bridge.env.example:141,174・br=5a8a221 で実測）が、SSoT には届いていなかった（この文書に gpt-realtime-2.1 の出現が 0 件だった）。確定値の表と本文の両方を、ja / en そろえて直した。⚑ aegis-platform 側は未追随（実際に効くのは backend/config.py:160 の openai_realtime_model: str = "gpt-realtime"。backend/adapters/realtime_adapter.py:131 がこれを先に読み、空なら同 :38 の _DEFAULT_OPENAI_REALTIME_MODEL = "gpt-realtime" へ倒れる＝ 2 か所とも無印・pf=8e3be70 で実測）。このリポでは直していない（別リポの実装は別 PR）。

• 2026-07-07: verdict の precedence 節を新設（v3 設計・aegis-platform decisions/aegis_scorer_v3_design_2026-07-07.md）。 score_source に llm_conversation（通話後の会話全文判定） を追加し、優先順位を確定：ルーティングは ライブ signal-so-far（rules/llm）が正・記録/学習は会話全文判定（llm_conversation）が正。二重化禁止は should_terminate の外部計算の禁止であって score_source 併存の禁止ではない、と明文化。会話後判定は記録専用で ライブを切らない（fail-open）／observed であって gold ではない（human 昇格必須・D6）。あわせて「verdict port 契約」節の Verdict 出力表 score_source に llm_conversation を追記（precedence 節と一致）。配線は未実装（掟に従い SSoT を先行確定）。

• 2026-07-07: verdict の流れに 開幕フロア・ガードレール（opener floor / L1 rules・フロア 0.6 を champion score に OR 合成） を追記。adversarial A/B（攻撃56/正当48）で突破 3→0・正当巻き込み 0 を実測（aegis-platform decisions/ab_replay_2026-07-06.md）。安全弁 0.8 未満のため単独切断はせず、should_terminate はフロア後 score から既存規則で導出（二重化しない）。

• 2026-07-04: 「verdict port 契約」節を新設（L3 設計 L3-D4 の承認を受けた先行更新）。分類脳の入口を単一契約に一本化し、should_terminate を action＋安全弁の導出値と定義（独立チャネルの禁止）。あわせて action に blocked を追加（8値） — L1 blocklist の Scorer 配線（L3-D2 の drift 解消）に伴う語彙追加。 ★※ その後7値に整理（2026-09-04）。

• 2026-07-04: verdict 経路を実装事実に更新（AMI Hangup（D-1）で能動切断・AstDB DBPut 経路は不採用/撤去）＋切断安全弁 AEGIS_TERMINATE_MIN_SCORE=0.8 を追記。ADR-0001（B案採用）に整合。

• 2026-07-04: 「通話後データ記録（transcript-final・学習データの本線）」節と score_source（rules/llm 区別） 節を新設。Route C（gpt-realtime）を本命の音声経路として位置づけ（A22＝telephony 土台）。

• 2026-06-18: 初版。本日の決定事項（OS / Asterisk 22 / ポート 9092 / verdict 経路 / A22 本命・standalone 凍結 / src 共有方針）を確定として記載。