Safe Referral Gate（SRG）
制度の入口は、制度側が持つ。
生成AIが、社会的な相談窓口になりつつあります。
子どもの安全、家庭内暴力、DV、性被害、自傷、生活困窮、内部通報など、人生や安全に関わる高リスク相談を、AIが最初に受け取る場面は今後さらに増えていきます。
このとき重要なのは、AIに「どこへ相談すべきか」を自由判断させることではありません。
必要なのは、制度側が公式な入口条件を定義し、AIがそれを正確に参照して案内できる仕組みです。
Safe Referral Gate（SRG）は、生成AIが高リスク相談を検知した際に、制度側の公式入口APIから、必要確認項目、公式窓口、相談後に起き得る手続き、案内可能な範囲を返すための制度入口ゲートです。
なぜSRGが必要なのか
生成AIは、相談の入口として機能することをすでに始めています。しかしAIが高リスク相談を受けたとき、「どの制度窓口に繋ぐか」の判断をAIが自律的に行うことは、誤誘導・過小対応・過剰介入のリスクを内包します。
制度側（行政機関・相談機関・支援団体）は、それぞれ入口条件を持っています。対象年齢、緊急性の判定基準、相談者本人の意思確認の要否、案内できる内容の範囲、相談後に起き得る手続き——これらは制度側だけが正しく定義できます。
AIがこの情報を「モデルの知識」として保持することには、版管理・更新・制度変更への追従という点で限界があります。制度側がAPIとして入口条件を公開し、AIがその時点の正確な情報を参照する構造が必要です。
SRGはその仕組みの構想です。AIに判断を委ねるのではなく、制度側が判断の入口を持つ。それがSRGの基本的な考え方です。
SRGの基本構造
SRGは2層から構成されます。
第1層は、制度側が管理するAPIです。各制度（DV相談、子どもの安全、自傷・自殺念慮等）の入口条件を、機械可読な形式で公開します。入口条件には、対象者条件、必須確認項目、公式窓口情報、案内可能な範囲、相談後に起き得る手続きが含まれます。
第2層は、生成AIとSRG APIの接続です。AIは高リスク相談を検知した際、相談内容の詳細ではなく、最小限の構造化フラグ（年齢帯・緊急性・種別）をSRGに送ります。SRGは判定結果と制度入口情報を返却します。AIはこの情報をもとに、相談者に案内を提供します。
この構造によって、AIは制度情報を「知っている」のではなく、制度側の公式情報を「参照する」立場に置かれます。情報の正確性と更新の責任は、制度側に留まります。
SRGが返す4つの状態
SRGは問い合わせに対して、以下の4つの判定コードのいずれかを返します。
GUIDE
案内できます
公式窓口や案内文を提示してよい状態。
NEEDS_CONTEXT
もう少し確認が必要です
安全に案内するため、先に確認すべき項目がある状態。AIは指定された確認項目を相談者に問いかける。
HUMAN_SUPPORT
人の窓口につなぎます
AI内で完結させず、人間の支援窓口へ接続すべき状態。
URGENT_SAFETY
今すぐ安全確保が必要です
緊急性が高く、緊急窓口を最優先すべき状態。AIは最短の緊急連絡先を提示し、自律的な判断を停止する。
APIイメージ
以下はSRG APIの概念的なリクエスト・レスポンス例です。実装仕様ではありません。
// リクエスト（AIからSRGへ）
POST /srg/query
{
"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": [
{
"type": "child_protection",
"label": "子どもの安全に関する公的相談窓口"
}
],
"what_happens_next": "相談内容によっては、安全確認や関係機関への共有が行われる場合があります。",
"privacy_mode": "minimal_flags_only",
"policy_version": "srg-core-v0.1",
"issued_at": "2026-06-03T00:00:00+09:00"
}SRGが扱う領域
SRGが対象とするのは、制度側（行政機関・相談機関・支援団体）が入口条件を持つ領域に限られます。以下は想定領域の例示です。
- 子どもの安全・虐待相談（児童相談所・通告）
- DV・家庭内暴力（配偶者暴力相談支援センター・保護命令）
- 性被害・性暴力（ワンストップ支援センター）
- 自傷・自殺念慮（よりそいホットライン・いのちの電話）
- 生活困窮・緊急支援（福祉事務所・生活保護相談）
- 内部通報・公益通報（公益通報者保護制度）
- 人身取引・強制労働（相談機関・警察）
SRGが扱わない領域：制度的な入口条件が定義されていない一般相談、法的判断を要する事案、医療診断を要する事案。
もう一つの用途：社会的ロードバランサー
SRGは、高リスク相談を安全に制度へ接続するための仕組みとして設計されています。
一方で、同じ構造は「低緊急度・多頻度相談」における社会リソースの負荷分散にも応用できます。
たとえば、行政手続き、自治体窓口、社内ヘルプデスク、大学の教務窓口、公共交通や観光案内などでは、問い合わせが一時期に集中し、人間の窓口がパンクすることがあります。
生成AIが親切に「窓口へ相談してください」と一律に案内すると、かえって現場の負荷を増やし、本当に人間対応が必要な人に支援が届きにくくなる可能性があります。
SRGは、この問題に対して、制度側が現在の窓口状況・対応可能チャネル・優先ルートを定義し、AIがその時点の制度側方針を参照して案内する仕組みとして応用できます。
この場合、SRGが返すものは単なる「相談先」ではありません。次のような、制度側が定義した接続ルートです。
- いま電話につなぐべきか
- まずオンライン申請へ案内すべきか
- FAQで完結できるか
- 人間窓口へ回す条件は何か
- 何日以降の予約へ誘導すべきか
- 緊急性がある場合だけ別ルートにすべきか
つまりSRGは、AIと有限な社会リソースの間に置かれる、公共的な交通整理レイヤとしても機能します。
高リスク相談 vs 低緊急度・多頻度相談
主目的
- 高リスク相談
- 安全な制度接続
- 低緊急度・多頻度相談
- 社会リソースの負荷分散
例
- 高リスク相談
- 児童相談、DV、自傷、性被害、内部通報
- 低緊急度・多頻度相談
- 行政手続き、社内FAQ、大学教務、自治体FAQ
SRGの役割
- 高リスク相談
- 必要確認・人間支援・緊急導線
- 低緊急度・多頻度相談
- チャネル分散・セルフヘルプ・予約・時間分散
失敗時リスク
- 高リスク相談
- 重大な安全リスク・権利侵害
- 低緊急度・多頻度相談
- 窓口混雑、待ち時間増、現場疲弊、不満増
返す情報
- 高リスク相談
- 必須確認項目、公式窓口、事後説明
- 低緊急度・多頻度相談
- 推奨チャネル、混雑状況、代替ルート、受付条件
使う判定状態
- 高リスク相談
- NEEDS_CONTEXT / HUMAN_SUPPORT / URGENT_SAFETY
- 低緊急度・多頻度相談
- GUIDE / NEEDS_CONTEXT / HUMAN_SUPPORT
※ 判定状態は両用途で共通です。増やすのではなく、使われ方が変わります。
低緊急度・多頻度相談の例
SRGの考え方は、以下のような領域にも応用できます。
- 行政手続き：繁忙期にオンライン申請や予約へ誘導する
- 企業ヘルプデスク：同一問い合わせをFAQ・チケットへ分散する
- 大学教務：履修登録期の問い合わせを一括案内・予約へ分散する
- 公共交通・観光案内：混雑時にWebフォームや別窓口へ誘導する
- 医療相談：制度側が定義した受診相談・オンライン相談・緊急相談ルートへ案内する
この用途は、相談者を機械的に排除するためのものではありません。
SRGのロードバランシングは、窓口を閉じる仕組みではなく、必要な人に人間対応を残すための接続制御です。
医療・福祉・安全領域では、軽症・低緊急度の判断をAIが確定してはなりません。必要な場合は必ず人間窓口・専門機関・緊急窓口への接続条件を残します。
責任境界
SRGは、相談者と制度側を直接つなぐシステムではありません。SRGは生成AIに判定情報を渡すAPIゲートであり、相談者との直接の関係を持ちません。
SRGが返却する情報は、AIが相談者への案内を構成するための参照情報です。案内の内容・方法・タイミングは、生成AIの設計と実装に委ねられます。SRGはAIの応答を制御しません。
通報・連絡・緊急対応の実行は、人間の判断と制度側の手続きに委ねられます。SRGは自動通報を行いません。
SRGが参照する制度情報の正確性・最新性の責任は、各制度側APIの管理主体に帰属します。SRGはその情報を仲介するだけです。
法的判断、医療診断、福祉の適否判定はSRGの範囲外です。SRGはこれらを代替しません。
既存の取り組みとの違い
生成AIの安全策やリスク低減の取り組みは世界各地で進められています。SRGはそれらを置き換えるものではなく、これまで埋まっていなかった層を補うものです。位置づけを明確にするため、代表的な既存手法との違いを整理します。
一般的なAIガードレール
AI開発企業が実装している、自傷・暴力・差別などのリスクを検知して定型文を表示し、回答を遮断する仕組みです。
ガードレールは「あらかじめ決められた定型文」を返します。SRGは、制度側の最新の状況や個別のケースに応じて「今聞くべき質問」「接続すべき公式窓口」「相談後に起き得る手続き」をAPIで動的に返します。
ガードレールの主目的は遮断です。SRGの主目的は、安全に接続するために必要な情報を揃えることです。
RAG（検索拡張生成）による公式情報参照
自治体のマニュアルやFAQをAIに読み込ませ、その内容から回答を組み立てる手法です。
RAGは「正しい情報を教える」ためのものです。SRGは「どの順番で、何を確認して、どこに繋ぐか」という手続きを制御するものです。
RAGでもAIは情報を要約して回答するため、誤案内のリスクが残ります。SRGは、判定状態ごとに動作を直接的に指示するため、自由作文の余地を狭めます。
行政・専門機関による専用チャットボット
児童相談所や自治体が、自前で専用のチャットボットを構築し運用する取り組みです。
専用ボットは特定の窓口だけを対象にした個別の解決です。しかし、相談者は最初に汎用AIに話しかけることが増えています。SRGは、汎用AIと制度窓口を繋ぐ共通の層を整えるための仕様です。
全ての制度が個別にボットを作るのは現実的ではありません。SRGのように入口APIだけを整備すれば、既存のAIサービスから参照可能になります。
比較表
目的
- 一般的なガードレール
- リスクの回避
- RAG（公式参照）
- 正確な情報の提示
- 専用チャットボット
- 特定窓口の効率化
- Safe Referral Gate（SRG）
- 安全な制度接続の担保
制御主体
- 一般的なガードレール
- AI開発企業
- RAG（公式参照）
- AI開発企業 / 導入者
- 専用チャットボット
- 制度運用者
- Safe Referral Gate（SRG）
- 制度運用者（API経由）
動作
- 一般的なガードレール
- 定型文の表示
- RAG（公式参照）
- 情報の要約・回答
- 専用チャットボット
- 閉じた導線での案内
- Safe Referral Gate（SRG）
- 状態判定 → 必須確認 → 接続
柔軟性
- 一般的なガードレール
- 低（固定文）
- RAG（公式参照）
- 中（データ依存）
- 専用チャットボット
- 中（設計依存）
- Safe Referral Gate（SRG）
- 高（APIで動的更新可能）
思想
- 一般的なガードレール
- 危ないので止める
- RAG（公式参照）
- 正しく教える
- 専用チャットボット
- うちの窓口に来てもらう
- Safe Referral Gate（SRG）
- 制度の入口は制度側が持つ
SRGは、AIに判断を任せるのではなく、制度側がプログラム可能な入口を持つことを前提にした層です。既存のガードレールやRAGと競合するものではなく、それらの上流または下流で機能します。
C³での位置づけ
SRGはC³の制度OS構想における「制度入口の機械可読化」に位置します。C³がVerified Web・ECHO-VERIFY・ITS APIで扱う「版管理・検証・ゲート制御」の考え方を、高リスク相談の制度入口に適用したものです。
C³ ITS API（C3-ITS-API-0.5）が生成AIの出力に対してHOLD/ALLOW/DENYゲートを提供するのと対照的に、SRGは制度側の公式入口条件を機械可読な形で公開することに焦点を当てています。AIのゲート制御と制度入口の参照という2つの層は、相互補完的に機能することを想定しています。
LLM SafeControl Profile（C3-SPEC-LLM-SAFECONTROL-PROFILE-0.1）が記述する外付け安全制御層の観点では、SRGの URGENT_SAFETY 判定が ITS API の ESCALATE と連動する制度参照レイヤとして位置づけられます。
論文・仕様書
SRGの概念設計・問題設定・アーキテクチャをまとめた論文および仕様書を公開しています。いずれもConcept / Draft v0.1段階の文書です。
C3-SRG-WP-0.1 ポジションペーパー
SRGの問題設定（なぜ制度入口の機械可読化が必要か）、設計原則、非目標、制度整合性の要件をまとめたポジションペーパーです。高リスク相談領域におけるAIの役割と制度側の責任境界を論じています。
SRG Hub / Registry Architecture（C3-SRG-HUB-ARCH-0.1）
SRGのハブ・レジストリ構造、コンポーネント設計、設計原則（7原則）、役割と責任、展開フェーズ（Phase 0–4）をまとめた技術仕様書です。制度・Profile Owner から生成AI・相談者への案内に至る6層スタック構造を定義しています。
PoCについて
SRGは現在、概念段階（Concept / Draft v0.1）にあります。運用中のシステムは存在しません。
PoC実施に向けた検討として、以下の段階を想定しています。
- Phase 0：領域選定と制度側ヒアリング。1〜2領域を選定し、制度側の入口条件定義を確認する。
- Phase 1：閉じた環境でのAPIスキーマ検証。制度側と共同で入口条件のJSON-Schema設計。
- Phase 2：生成AIとの接続テスト。最小限の構造化フラグでの往復を確認。本番データは使用しない。
PoCは、制度側（行政機関・相談機関）との共同設計が前提です。C³単独でのPoC実施は行いません。
参画・お問い合わせ
SRGの構想に関心のある行政機関・相談機関・研究機関・AI開発者の方からのご連絡をお待ちしています。
特に以下のような関与を想定しています。
- 制度側：入口条件の定義・APIスキーマ設計への参加
- 研究者：高リスク相談のAIルーティングに関する共同研究
- AI開発者：SRGとの接続仕様の共同検討
- 評価者：SRGの安全性・中立性・制度整合性のレビュー
お問い合わせ: info@c3-anchor.jp
本ページはSRG構想の概念仕様（Concept / Draft v0.1）を記述したものです。運用中のシステムは存在しません。品質保証、法的効力、医療的判断、制度的権限、自動通報、投資収益を意味するものではありません。
検証面・版履歴
このページの版状態・更新履歴・証跡は以下から追跡できます。