SRG Hub / Registry Architecture
制度の入口は、制度側が持つ。
概要
SRG Hub / Registry Architecture（C3-SRG-HUB-ARCH-0.1）は、Safe Referral Gate の公共仕様・PoC母艦として、制度入口Profileの登録・版管理・配布と、AI向けResolver APIの構成を定義した仕様草案です。
生成AIが高リスク相談を受け取る場面が増える中、AIが参照する「制度窓口の入口条件」を誰がどのように管理するかは、未解決の課題です。個々のAIプラットフォームが独自に窓口情報を保持する現状では、版管理・更新・制度変更への追従が困難であり、誤案内のリスクが分散します。
SRG Hubは、制度主体が入口条件を公式APIとして公開し、任意のAIサービスが同一の最新情報を参照できる共通層を整えるための構想です。
Status: Concept / Draft v0.1 — 運用中のシステムは存在しません。
解決したい課題
- 制度窓口の入口条件（対象者・必須確認事項・手続き）がAIに正確・最新の形で届いていない
- 各AIプラットフォームが独自に窓口情報を持つことで、版管理が分散し更新漏れが生じる
- 高リスク相談の案内が制度側の定義から外れ、AIが自由判断する状態が放置されている
- 制度側が「AIにどう参照されるか」を制御する手段を持っていない
- 各機関が個別にチャットボットを構築するコストが高く、汎用AIとの連携が困難
アーキテクチャ
SRG Hubは以下の5層スタックで構成されます。制度主体がProfileを登録し、Resolver APIを通じてAIに判定情報を提供します。
設計原則
SRG Hubの設計は以下の7原則に基づきます。
Public-Interest First（公共利益の優先）
SRG Hubの設計・運営・更新における全ての決定は、相談者の安全と制度側の正確な案内を最優先とします。商業的利益・利便性・技術的効率は、公共利益に従属します。
Minimum Information Principle（最小情報原則）
AIからSRGへの問い合わせには、判定に必要な最小限の構造化フラグのみを送ります。相談内容の詳細・個人情報・会話ログはSRGに送りません。
Human-Final Decision（人間最終判断）
SRGの判定はAIへの参照情報であり、最終的な判断・通報・接続は人間（相談者本人・支援者・制度担当者）が行います。SRGは決定を代替しません。
Institution-Defined Entry（制度側による入口定義）
どの条件でどの窓口に繋ぐかは、制度側がProfileとして定義します。AIまたはSRG運営主体が独自に窓口条件を設定することはありません。
Version-Controlled Transparency（版管理による透明性）
全てのProfileはバージョン管理され、変更履歴が追跡可能です。どの版のProfileでどの判定がなされたかを後から確認できる状態を維持します。
No Commercial Contamination（商業混入の禁止）
広告・有料優先表示・スポンサード参照・人気順ランキング・星評価・口コミ・コンバージョン最適化・商業的推薦をSRG Hubに含めてはなりません。
Transferable Public Architecture（移転可能な公共アーキテクチャ）
SRG Hubの設計・仕様・データは、特定の組織に依存しない形で設計します。将来、公共主体または多主体ガバナンスへの移転が可能な状態を初期から意図します。
コンポーネント構成
Profile Registry
制度入口ProfileのJSON台帳。Git版管理。各Profileは入口条件・確認項目・窓口情報・ルート種別・版を保持する。
Resolver API
AIからの問い合わせを受け、decision・required_questions・official_referralsを構造化して返す共通API。
Adapter Templates
GPT Actions / Gemini / Dify 等の各AIプラットフォーム向け接続テンプレート。Adapterの実装責任はAI開発者・導入者が持つ。
Audit Lite
問い合わせ件数・判定コード別カウント・版ログ・エラー率の最小証跡記録。個人情報・相談内容・会話ログは含めない。
Pilot Console
Profile編集・ルート構成・トークスクリプト設計・テストコンソール（Phase 2以降）。本番相談には使用しない。
役割と責任
制度入口Profileの定義・提出・更新
制度運用者（行政機関・相談機関・支援団体）
Registry管理・版管理・整合性確認
SRG運営主体（C³または移転先の公共主体）
Resolver APIの設計・開発・運用
SRG運営主体
AI Adapterの実装・接続
AI開発者・導入者
Profileの正確性・最新性の維持
制度運用者
独立レビュー・外部監査
外部評価機関・研究者
対象範囲
対象とするもの（In Scope）
- 制度入口ProfileのJSON台帳・登録・版管理
- Resolver APIによる判定・確認項目・窓口情報の返却
- AI向けAdapter Templateの設計・提供
- 合成ケースによるShadow評価・テスト
- Audit Lite（最小証跡記録）
- Pilot Consoleによるフローテスト（Phase 2以降）
- Profileの独立レビュー・版管理の透明性確保
対象としないもの（Out of Scope）
- 本番相談の受付・処理
- 緊急通報の実行・自動発信
- 自動親通知・学校通知・雇用者通知
- 医療診断・法的判断・福祉の適否判定
- 捜査判断・警察への通報決定
- 窓口の人気順ランキング・口コミ・星評価
- 広告枠販売・有料優先表示・スポンサード参照
- 商業的コンバージョン最適化
判定状態と Resolver API
Resolver APIは問い合わせに対して、以下の4つの判定状態（decision）のいずれかを返します。判定コードは相談者向けの表示メッセージと対応しています。
GUIDE
案内できます
公式窓口や案内文を提示してよい状態。
NEEDS_CONTEXT
もう少し確認が必要です
先に確認すべき項目がある状態。
HUMAN_SUPPORT
人の窓口につなぎます
人間の支援窓口へ接続すべき状態。
URGENT_SAFETY
今すぐ安全確保が必要です
緊急窓口を最優先すべき状態。
Resolver API リクエスト・レスポンス例を表示
// リクエスト（AIからSRGへ）
POST /api/srg/resolve
{
"srg_version": "0.1",
"case_type": "child_protection",
"age_band": "unknown",
"immediate_danger": "unknown",
"missing_context": [
"current_safety",
"age",
"continuity",
"trusted_adult_available"
]
}
// レスポンス（SRGからAIへ）
{
"decision": "NEEDS_CONTEXT",
"required_questions": [
"今、安全な場所にいますか",
"年齢は何歳くらいですか",
"同じことは何度も起きていますか",
"相談できる安全な大人はいますか"
],
"official_referrals": [
{
"route_type": "official_entry",
"label": "子どもの安全に関する公的相談窓口"
}
],
"what_happens_next": "相談内容によっては、安全確認や関係機関への共有が行われる場合があります。",
"privacy_mode": "minimal_flags_only",
"policy_version": "srg-core-v0.1",
"profile_version": "child_protection-v0.1",
"issued_at": "2026-06-03T00:00:00+09:00"
}Profile Entry JSONスキーマを表示
{
"profile_id": "child_protection-v0.1",
"domain": "child_protection",
"version": "0.1",
"status": "draft",
"entry_conditions": {
"age_bands": ["child", "minor", "unknown"],
"urgency_levels": ["low", "medium", "high", "unknown"]
},
"decision_rules": [
{
"if": { "immediate_danger": "yes" },
"then": { "decision": "URGENT_SAFETY" }
},
{
"if": { "missing_context": ["current_safety", "age"] },
"then": { "decision": "NEEDS_CONTEXT" }
},
{
"if": { "age_band": "child", "immediate_danger": "no" },
"then": { "decision": "HUMAN_SUPPORT" }
}
],
"required_questions": {
"current_safety": "今、安全な場所にいますか",
"age": "年齢は何歳くらいですか",
"continuity": "同じことは何度も起きていますか",
"trusted_adult_available": "相談できる安全な大人はいますか"
},
"official_referrals": [
{
"route_type": "official_entry",
"label": "子どもの安全に関する公的相談窓口"
},
{
"route_type": "emergency_only",
"label": "緊急の安全確保が必要な場合の窓口"
}
],
"what_happens_next": "相談内容によっては、安全確認や関係機関への共有が行われる場合があります。",
"privacy_mode": "minimal_flags_only",
"last_updated": "2026-06-03",
"owner": "（制度運用者が定義）"
}ルートエンジン：Route ≠ Contact
SRG Hubが返すのは「どの種別の窓口に繋ぐか（route_type）」であり、「電話番号・住所・URLなどの連絡先（contact）」ではありません。これはSRG Hubが電話帳や窓口ディレクトリになることを防ぐための設計です。
具体的な連絡先は、案内を受けたAIが制度側の公開ページから取得するか、相談者自身が公式サイトで確認します。SRG Hubは「どこに繋ぐかの判断」を提供し、「繋ぐ行為」はAIと人間の側が担います。
official_entry
制度の公式入口。対象者条件・必須確認項目あり。
general_inquiry
一般的な問い合わせ窓口。緊急性なし。
emergency_only
緊急時のみ使用する窓口。URGENT_SAFETY時に優先参照。
peer_support
当事者・ピアによる支援窓口。制度外の補完的選択肢。
Resource-Aware Routing（リソース状況を考慮した接続制御）
SRG Hubは、高リスク相談の安全接続だけでなく、低緊急度・多頻度相談におけるリソース状況を考慮した接続制御にも応用できます。
この用途では、制度側Profileは「どの窓口に接続するか」だけでなく、「現在どのチャネルへ案内すべきか」を定義します。
たとえば、電話窓口が混雑している場合はオンライン申請へ、対面窓口が混雑している場合は予約フォームへ、FAQで解決可能な場合はセルフヘルプへ誘導します。
ただし、SRG Hubは相談者を機械的に拒否するものではありません。緊急性・安全性・人間対応の必要性がある場合は、常に人間窓口または緊急導線を優先します。
Load-Balancing Profile
低緊急度・多頻度相談向けProfileでは、resource_state と routing_strategy を利用します。
resource_state は、窓口混雑・人間対応余力・優先チャネル・有効期限を表します。
routing_strategy は、制度側がその時点で推奨する接続方針を表します。
このProfileは、問い合わせを拒否するためではなく、限られた人間リソースを必要度の高い相談に残すために使用します。
resource_state スキーマを表示
{
"resource_state": {
"service_load": "normal | busy | saturated | emergency_surge | unknown",
"preferred_channel": "phone | web_form | official_chat | online_application | in_person | appointment | self_help | unknown",
"human_capacity": "available | limited | saturated | unknown",
"updated_at": "2026-06-04T14:00:00+09:00",
"valid_until": "2026-06-04T18:00:00+09:00",
"source": "institution_profile"
}
}| フィールド | 説明 |
|---|---|
| service_load | 現在の窓口混雑状態 |
| preferred_channel | 制度側が今優先したい接続チャネル |
| human_capacity | 人間対応の余力 |
| updated_at | 状況更新時刻 |
| valid_until | この負荷状態の有効期限 |
| source | 情報の発行元 |
routing_strategy スキーマを表示
{
"routing_strategy": {
"strategy_type": "normal_referral | digital_first | self_help_first | appointment_first | delayed_response | channel_shift | distributed_route",
"reason": "phone_channel_busy",
"fallback_condition": "urgent_or_complex_case",
"fallback_route_type": "human_support"
}
}| strategy_type | 意味 |
|---|---|
| normal_referral | 通常案内 |
| digital_first | まずオンライン申請・Webフォームへ |
| self_help_first | まずFAQ・手順ページへ |
| appointment_first | まず予約へ |
| delayed_response | 後日受付・時間分散 |
| channel_shift | 電話・対面からチャット・フォームへ移す |
| distributed_route | 地域・窓口ごとの空きに応じて分散 |
判定状態は GUIDE のままで、負荷分散は route_options・routing_strategy・resource_state で表現します。
Resolver API レスポンス例（負荷分散）を表示
{
"decision": "GUIDE",
"display_message": "現在、電話窓口が混雑しています。まずオンライン申請をご利用ください。",
"route_options": [
{
"route_type": "online_application",
"label": "オンライン申請",
"priority": 1,
"safety_note": "この手続きはオンラインで完了できます。"
},
{
"route_type": "phone",
"label": "電話窓口",
"priority": 2,
"safety_note": "複雑な相談やオンラインで解決できない場合に利用してください。"
}
],
"resource_state": {
"service_load": "busy",
"preferred_channel": "online_application",
"human_capacity": "limited",
"updated_at": "2026-06-04T14:00:00+09:00",
"valid_until": "2026-06-04T18:00:00+09:00"
},
"routing_strategy": {
"strategy_type": "digital_first",
"reason": "phone_channel_busy",
"fallback_condition": "urgent_or_complex_case",
"fallback_route_type": "human_support"
},
"what_happens_next": "オンライン申請では、入力内容を確認後、必要に応じて担当窓口から連絡があります。",
"policy_version": "municipal-service-demo-v0.1",
"reason_codes": [
"RC_CHANNEL_BUSY",
"RC_DIGITAL_FIRST",
"RC_HUMAN_CAPACITY_LIMITED"
]
}負荷分散用 reason_code
| Reason Code | 意味 |
|---|---|
| RC_CHANNEL_BUSY | 対象チャネルが混雑している |
| RC_HUMAN_CAPACITY_LIMITED | 人間対応余力が限定的 |
| RC_DIGITAL_FIRST | オンライン申請・Webフォームを優先する |
| RC_SELF_HELP_FIRST | FAQ・手順ページを先に案内する |
| RC_APPOINTMENT_REQUIRED | 予約が必要 |
| RC_DELAYED_RESPONSE | 後日受付・時間分散が推奨される |
| RC_CHANNEL_SHIFT | 電話・対面から別チャネルへ誘導する |
| RC_RESOURCE_SURGE | 一時的な問い合わせ急増がある |
| RC_FALLBACK_HUMAN_SUPPORT | 条件に該当する場合は人間窓口へ戻す |
医療相談領域のClaim Boundary
医療相談領域では、SRGは診断や受診要否を判断するものではありません。
制度側または医療提供体制側が定義した相談導線、オンライン相談、救急相談、受診目安、混雑時の案内方針を、AIが参照できる形で返すことを想定します。
症状の緊急性が不明な場合や、重症化の可能性がある場合は、必ず人間窓口または緊急導線を優先します。
Audit Lite
Audit Liteは、SRG Hubの動作を最小限の証跡として記録する仕組みです。相談者の安全に関わるシステムである以上、「いつ・どの版のProfileで・どの判定が返されたか」を後から確認できる状態が必要です。
ただし、プライバシー保護のため、記録の範囲は最小限に留めます。
記録するもの
- 問い合わせ件数（集計）
- 判定コード別カウント
- Profile版ログ
- エラー率・応答時間
記録しないもの
- 相談内容・会話ログ
- 個人情報・相談者ID
- AIの応答テキスト
- 問い合わせ元IPアドレス
公共ガバナンス原則：商業混入の禁止
SRG Hubは、広告枠・有料優先表示・スポンサード参照・人気順ランキング・星評価・口コミ・コンバージョン最適化・商業的推薦を含めてはなりません。
ルート選択（どの窓口種別に繋ぐか）は、相談者の安全性と制度定義条件のみに基づきます。特定の機関を他より優先的に表示する商業的インセンティブが介在してはなりません。
SRG Hubを運営する主体は、制度入口の中立性を維持するため、商業的利益を持つ事業者からの独立性を確保する必要があります。これはPhase 4（公共移転）での独立ガバナンス確立の前提条件です。
展開フェーズ
SRG Hubの展開は、以下の5フェーズで段階的に進めることを想定しています。現在は仕様策定・Phase 0の設計検討段階です。
Phase 0
Static Registry
JSONプロファイルをGitで管理。Resolver APIなし、コンソールなし、本番相談なし。仕様とProfileスキーマの合意形成が目的。
Phase 1
Resolver API
`/api/srg/resolve` エンドポイントを実装。Profile lookup・decision rules・route options・Audit Liteを搭載した最小APIを閉じた環境で検証する。
Phase 2
Pilot Console
Profile編集・ルートビルダー・トークスクリプト設計・テストコンソール・合成ケーステストを整備。専門家レビューを実施。
Phase 3
Institutional PoC
1〜2領域の制度主体と連携した限定PoC。最初は実利用者なし、合成ケース中心。専門家レビューと独立評価を経て拡大を検討。
Phase 4
Public Transfer / Shared Governance
公共主体または多主体ガバナンスへの移転。独立レビュー・外部監査・Verified Web連携を実装。C³は仕様管理から運用移転の支援に役割を移す。
Verified Web との関係
SRG Hubは、C³の Verified Web 仕様に基づく版管理・証跡・検証導線を備えることを前提としています。各ProfileはVerify IDで識別され、現行版・置換済み版・失効版の区別がAIにも人間にも同じ形で参照できる状態を目指します。
ECHO-VERIFY標準との連携により、Profileの独立検証（BYOV）が可能な状態を整えることを、Phase 3以降の目標として位置づけています。
C³社会デザインセンターの役割
C³社会デザインセンターは、SRG Hubの仕様起草主体として、初期のRegistry設計・Resolver APIの仕様化・Adapterテンプレートの開発・Pilot Consoleの設計を担います。
ただし、SRG Hubの長期的な運営は、特定組織への依存を避けるため、Phase 4において公共主体または独立した多主体ガバナンスへの移転を前提としています。C³はこの移転を支援し、仕様の管理から運用の独立へと役割を移行することを意図しています。
C³は、SRG Hubの唯一の運営主体であることを主張しません。仕様の公開と移転可能性の確保が、C³の役割における核心です。
本ページはSRG Hub / Registry Architecture の概念仕様（Concept / Draft v0.1）を記述したものです。運用中のシステムは存在しません。品質保証、法的効力、医療的判断、制度的権限、自動通報、投資収益を意味するものではありません。