自治体の総合相談の窓口で、相談者の世帯・収入・困りごとから使える可能性のある支援制度を各課の要綱と案内資料から横断で探し、要件と担当課を根拠付きで職員に返す

処理の起点を決める

起点は、相談員が制度検索の画面で状況の選択肢を送ったことです。 画面は庁内の ID でログインした総合相談の相談員だけが使え、住民は使いません。 送る前に、緊急の確認の3問に答えないと先に進めない作りにします。

状況は、選択肢で入れます。 世帯の構成（単身、夫婦、ひとり親と子、三世代など）、世帯員の年齢の区分（未就学、小中学生、18歳から64歳、65歳以上）、収入の区分（住民税の非課税か、収入が途絶えたか）、住まい（持ち家、賃貸、住まいが無い）、困りごと（生活費、家賃、介護、障害、子育て、就労、滞納）。自由に書く欄は、困りごとの補足として短く1つだけ置きます。

1件の相談は、1つのセッションで続けます。 確かめていない要件を聞いたあとに「同居の母は要介護2」と足すと、同じセッションで候補を絞り直します。別の世帯の相談は、新しいセッションで始めます。

入力データを集める

質を決めるのは、制度ごとのメタデータです。 制度ごとに、分野、対象の年齢の区分、対象の世帯の類型、所得の要件の有無、適用開始日と終了日、担当課を付けます。年齢と世帯の類型は、明らかに対象外の制度を検索の前に外すために使い、所得の要件の数字はメタデータにせず、要綱の本文のまま根拠として返します。 数字の読み方は制度ごとに違い、区分で機械的に比べると誤るからです。

氏名、住所、生年月日、相談の経緯の文章は、この構成に入れません。 制度を探すのに個人を特定する情報は要らず、年齢の区分と世帯の類型で足ります。

データの取得方法を決める

要綱・案内資料・内部の運用メモ・条文は、Cloud Storage に置いてデータストアに取り込みます。 取りまとめの担当（福祉総合相談課の1名）が、各課から年度の版を受け取り、メタデータを付けて置きます。

絞り込みの式は、年齢と世帯と日付で書きます。 項目を索引可能にしておけば、age_group: ANY("65plus", "18to64", "all") AND household: ANY("multi_gen", "all") AND valid_from <= "2026-10-08" AND valid_to >= "2026-10-08" のように、世帯にいる年齢の区分に当たる制度と、今日効いている版だけを引けます。対象を限らない制度には all を付けます。

各課の内部の運用メモには、閲覧の範囲を付けます。 要件の読み方の目安は、住民向けの案内と違う言い方をしていることがあり、そのまま相談者に伝える文書ではありません。 acl_info の readers に、その課と総合相談のグループを書きます。この設定はデータストアの作成時にしか選べず、データソースのアクセス制御はプレビューの機能です。 使わない場合は、内部の運用メモを別のデータストアに分けます。

AIへ渡す前に整形する

1. 制度ごとに文書をまとめる … 要綱、案内資料、内部の運用メモを、制度の番号で束ねます
2. 要綱を条ごとに分ける … 対象者、要件、申請の条を、見出しの付いた形で取り込みます。別表も表のまま残します
3. 年度の版に期間を付ける … 前年度の版には、今年度の版の適用開始日の前日を終了日として書きます
4. 年齢と世帯のメタデータを付ける … 要綱の対象者の条を見て、各課の担当が付けます
5. 案内資料の古いものを外す … ウェブページの写しは取得日を付け、要綱と食い違うものは各課に確かめます
6. 条文を取り込む … 社会福祉法と生活困窮者自立支援法の該当条を、法令APIから取ります
7. 見出しを断片に含める … データストアの作成時に分割を有効にし、includeAncestorHeadings を有効にします

4番目は、各課の担当に付けてもらいます。 取りまとめの担当が要綱を読んで付けると、対象者の条の読み違いがそのまま絞り込みに入ります。 制度を持つ課が付け、取りまとめの担当は抜けを見るだけにします。

7番目は、データストアを作る前に決めます。 分割はデータストアの作成のあとでは有効にも無効にもできず、見出しを含める設定は既定では無効です。 「所得の要件」の断片は、見出しが無いとどの制度の要件か分かりません。 分割の大きさは100〜500トークンで、既定は500です。

AIに処理させる

させるのは、状況に当たりうる制度の要綱と案内資料の記載を見つけ、制度ごとに要件を並べ、聞き取りの区分で満たしていそうなものと、まだ確かめていないものを根拠付きで返すことです。 緊急かどうか、明らかに対象外かは、相談員と中継プログラムが決めます。

answer メソッドの設定は次のようにします。

3行目がいちばん起きやすい失敗です。 要綱に所得の上限の表があると、モデルは収入の区分から「上限を下回るので対象」と書きます。 上限が世帯の人数や控除の後の額で決まる制度では、区分の比較では決まりません。所得の要件は「まだ確かめていない」側に置き、数字は要綱の表のまま示します。

指示内容を固定する

answer メソッドの preamble に、次の指示を入れます。

あなたは市の福祉総合相談課の相談員を手伝う立場で、
相談者の世帯に当たりうる市の支援制度を、各課の要綱と案内資料から探します。
読むのは相談員です。住民ではありません。

【前提】
検索の文の最初に、世帯の構成、年齢の区分、収入の区分、住まい、困りごとが並んでいます。
これは選択肢で入れた区分で、正確な金額や年齢ではありません。

【答え方】
1. 当たりうる制度ごとに、制度の名前と担当課を書いてください。
2. 制度ごとに、要綱の要件を並べ、
   「聞き取りの区分で満たしていそう」「まだ確かめていない」に分けてください。
3. 「まだ確かめていない」要件には、相談員が次に聞くことを1行で書いてください。
4. 根拠にした要綱の条と、案内資料のページを書いてください。

【厳守事項】
- 検索結果の文書に書かれていることだけで答えてください。
  他の自治体の制度や国の制度の一般的な説明で補わないでください。
- 「使えます」「対象です」「受けられます」と書かないでください。
  書くのは「当たりうる」までです。
- 所得の要件は、区分から満たすかどうかを判断しないでください。
  必ず「まだ確かめていない」に置き、要綱の金額の表をそのまま示してください。
- 区分で決まらない要件を、満たしていそうな側に置かないでください。
- 制度の優先順位や、どれを勧めるかを書かないでください。
- 当たりうる制度が見つからないときは、
  「要綱と案内資料に当たりうる制度が見つかりません。取りまとめの担当へ回します」
  とだけ書いてください。

「使えます、と書かない」が、この指示の要です。 候補を並べるだけの検索でも、モデルは要件が揃って見えると結論を書きます。相談員がそれを読み上げれば、相談者には市の約束に聞こえます。 書き方そのものを禁じ、「当たりうる」で止めます。

検索の文は、中継プログラムが組み立てます。 例えば「世帯：三世代（65歳以上1名、18〜64歳2名、小中学生1名）、収入：主な稼ぎ手の収入が途絶えた、住まい：賃貸、困りごと：家賃・介護・就労。当たりうる制度は何か」のように、区分だけを並べます。 補足の自由記入の欄は、固有名詞と数字を消してから足します。

出力形式を固定する

answer メソッドの応答を、中継プログラムが次の形に整えて、画面と記録に渡します。

{
  "search_id": "",
  "session_id": "",
  "counselor_id": "",
  "urgent_check": { "food": false, "safety": false, "abuse": false },
  "profile": { "household": "", "age_groups": [""], "income": "nontaxable | income_lost | other | unknown", "housing": "own | rent | none", "concerns": [""] },
  "candidates": [
    { "program_id": "", "name": "", "dept": "", "extension": "",
      "likely_met": [ { "requirement": "", "basis": "" } ],
      "to_confirm": [ { "requirement": "", "next_question": "", "basis": "" } ],
      "refs": [ { "doc_type": "rule | guide | memo", "title": "", "article": "", "valid_from": "", "uri": "" } ] }
  ],
  "status": "listed | none_found | urgent_route | skipped",
  "feedback": { "contacted_depts": [""], "missing_program": "" }
}

1つ目の理由は、to_confirm を候補ごとに持てることです。 相談員は画面の上から順に「次に聞くこと」を聞き、答えを足して同じセッションで絞り直します。 要綱を開き直さずに、相談の場で要件が揃っていきます。

2つ目は、refs の valid_from を検査に使えることです。 根拠の版の適用期間に今日が入っていなければ、その候補を画面に出さずに取りまとめの担当へ回します。 古い版での案内を、文の読み方に頼らずに止められます。

3つ目は、feedback の missing_program で漏れを集められることです。 相談員が「この制度が出なかった」と書いた制度は、メタデータの付け間違いか、文書の取り込み漏れです。 取りまとめの担当が毎月見て、各課に直してもらいます。

システムへ連携する

相談の記録の仕組みと、各課の業務の仕組みには、つなぎません。 候補を記録に書き写すのも、担当課へ連絡票を送るのも相談員が行います。住民の個人の記録を、検索の側へ流さないためです。

人が確認する

相談員は、候補の一覧を読んだあと、根拠の要綱の条を開いて確かめてから相談者に伝えます。 伝えるときは「当たるかもしれない制度」として伝え、決めるのは担当課であることを必ず添えます。

1. 確かめていない要件を聞く … 画面の「次に聞くこと」を順に聞き、答えを足して絞り直します
2. 根拠の版を見る … 候補の要綱の適用開始日が今年度かを確かめます
3. 担当課へつなぐ … 内線で担当課に状況を伝えるか、同行します

2番目を軽く見ないでください。 年度の途中で改正された制度は、要綱と案内資料の版がずれていることがあります。 食い違いに気づいたら、評価の欄に書いて取りまとめの担当へ回します。

目標は、200件をならして1件6分です。 画面の操作、確かめていない要件の聞き取り、根拠の確認、担当課への連絡の平均です。

例外に対処する

2行目のときに、相談員の目で探す道を残します。 検索に出ない制度があることは前提で、検索が漏れを減らす道具であって、漏れが無いことの保証ではないからです。

記録を残す

• 選択肢の値、日時、相談員（個人を特定する情報は残さない）
• 中継プログラムが組み立てた検索の文と、使った絞り込みの式
• answer メソッドの応答の全文（候補、出典、根拠のスコア、回答しなかった理由）
• 画面に出した候補と、版の検査で外した候補
• 相談員の評価（つないだ担当課、出なかった制度）
• そのとき効いていた要綱の版

最後の行は、案内の誤りを後から確かめるときに効きます。 「窓口で言われた制度が使えなかった」という申出に、当時の版と画面に出した候補を並べて見られるようにしておきます。