自治体の福祉の相談窓口で、面談のメモと聞き取りの記録を要約し、支援経過記録の下書きと関係機関への連絡票の案を作る

処理の起点を決める

支援員が相談記録システムの入力画面で「下書きを作る」を押したときに動きます。 面談の終わりに自動で動かすことはしません。メモを入れ終えたかどうかは、支援員にしか分からないからです。 途中のメモで下書きを作ると、決めたことの欄が抜けた下書きが出て、それを直す手間が増えます。

連絡票の案は、支援員が宛先と伝える項目を選んで「連絡票の案を作る」を押したときに動きます。 支援経過記録の下書きと同時には作りません。第5章の6番目のとおり、伝える項目を人が選ぶ工程を、必ず先に通します。

1件の面談に対して、下書きは何度でも作り直せるようにします。 メモを書き足して作り直したときは、前の下書きを残したうえで新しい下書きを出し、どちらを確定に使ったかを記録します。

入力データを集める

質を決めるのは、いちばん上の面談のメモです。 本人の言葉を「」で書く、確かめたことには「確認」と付ける、という書き方の取り決めがあると、下書きでの分け方の精度が大きく変わります。 取り決めは係で決め、研修で揃えます。

前回までの記録は、要点だけを渡します。 全文を渡すと、前回の内容が今回の下書きに混ざります。「前回決めたことのうち、今回どうなったか」を書かせるのに要るのは、前回の「決めたこと」と「次の予定」だけです。

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

相談記録システムから、中継の処理（Azure Functions）がメモ・シート・前回までの記録の要点を受け取ります。相談記録システムに外部から呼べる口が無い場合は、入力画面から中継の処理を呼ぶ形を、システムの事業者と個別に作る必要があります。 ここは利用している相談記録システムによって変わる部分です。

氏名・住所・電話番号・生年月日は、Azure OpenAI に渡す前に記号に置き換えます。 「本人」「長男」「母」「A事業所」のように、続柄と役割で書きます。要約に要るのは誰が誰に何を言ったかの関係で、氏名そのものは要りません。 置き換えの表は中継の処理の中にだけ持ち、生成AIには渡しません。

世帯の構成は、続柄だけを渡します。 同じ世帯に「母」と「祖母」がいるとき、どちらの話かをメモの文脈で取り違えないようにするためです。

AIへ渡す前に整形する

1. 固有の情報の置き換え … 氏名、住所、電話番号、生年月日、口座番号、事業所名を、続柄や役割の記号に置き換えます
2. シートの文章化 … チェックの付いた項目を「収入：就労収入なし（チェック）」のような短い行に直します。チェックの無い項目は渡しません
3. 前回の要点の抜き出し … 直近3回の記録から「決めたこと」と「次の予定」の欄だけを取り出します
4. メモの表記の統一 … 全角と半角、日付の書き方（「来週火」「10/14」）をそろえます。日付は面談日を基準に年月日へ直し、直したことを印で残します
5. 長さの確認 … 1件の面談のメモが極端に長いときは、面談の途中で区切って2回に分けて要約し、つなぎます

1番目を軽く見ないでください。 相談のメモには、本人だけでなく家族や近所の人、勤め先の名前が出てきます。置き換えの漏れは、そのまま外部のサービスに渡る情報になります。 置き換えのあとに、記号以外の固有名詞らしい語が残っていないかを機械で確かめ、残っていたら送らずに支援員の画面に戻します。

AIに処理させる

3行目がいちばん起きやすい失敗です。 メモに「家賃のこと心配」とだけあると、AIは「家賃を滞納している」と書きたくなります。滞納しているのか、来月払えるか心配なのかは、メモからは分かりません。 書かれていないことは「メモに記載なし」とし、支援員が直すときに埋めます。

気になる言葉の抜き出しは、判断ではなく見落としの防止です。 面談の終わりに本人がつぶやいた一言が、メモの最後に1行だけ書かれていることがあります。下書きの先頭にその言葉をそのまま出し、支援員が読み飛ばさないようにします。 それが緊急かどうかは書かせません。

指示内容を固定する

支援経過記録の下書き：

あなたは市の福祉の相談窓口で、相談支援員の記録づくりを手伝う担当です。
渡された面談のメモ、聞き取りのシート、前回の要点だけを根拠にしてください。
推測で埋めないでください。

【書くこと】
1. statements：本人や家族が言ったこと。メモで「」の付いた言葉はそのまま写す
2. facts：支援員が書類や現地で確かめたこと。メモで「確認」とあるもの
3. decisions：この面談で決めたこと（誰が、何を、いつまでに）
4. next_steps：次の予定（日付が分かるものは日付を書く）
5. previous_followup：前回決めたことが今回どうなったか。メモに無ければ「メモに記載なし」
6. flagged_words：死・暴力・食事・お金の困窮・子どもの安全に関わる言葉を、メモの文言のまま

【厳守事項】
- 支援員の所見・評価・見立てを書かないでください。observations は必ず空にしてください。
- メモに書かれていないことを補わないでください。
  書かれていない項目は「メモに記載なし」としてください。
- 本人の言葉を言い換えないでください。「」の中はそのまま写してください。
- 本人がそう言ったことを、確かめた事実として書かないでください。
- flagged_words について、緊急かどうか、どう対応すべきかを書かないでください。
- 記号（本人、長男、A事業所など）は記号のまま使ってください。
  実名を推測して書かないでください。
- 支援の方針を提案しないでください。

【面談のメモ】{memo}
【聞き取りのシート】{sheet}
【前回の要点】{previous}
【世帯の構成（続柄のみ）】{household}

連絡票の案：

あなたは市の福祉の相談窓口で、関係機関への連絡票の文案を作る担当です。

【宛先の機関】{agency}
【連絡の目的】{purpose}
【伝える項目（支援員が選んだもの）】{selected_items}

【厳守事項】
- 伝える項目に書かれていることだけを使ってください。
  支援経過記録や面談のメモにある他の情報を足さないでください。
- 本人や家族の評価、支援員の見立てを書かないでください。
- 依頼したいことは、宛先の機関に1つずつ箇条で書いてください。
- 伝える項目が空のときは、文案を作らず empty_selection を true にしてください。

「observations は必ず空に」を書かないと、最後に「本人は前向きな様子であった」と添えてきます。 善意の一文ですが、支援員がそのまま確定すると、本人の様子を見ていない仕組みの評価が記録に残ります。 指示で禁じたうえで、所見の欄に何か入っていたら中継の処理で消し、支援員の画面に「所見は支援員が記入」と表示します。

連絡票の指示に「他の情報を足さない」を入れるのは、2つの呼び出しを分けていても混ざる経路があるからです。 支援員が伝える項目の欄に面談のメモを丸ごと貼ることがあります。その場合も、貼られた内容のうち宛先と目的に関係するものだけを使わせ、残りは支援員の画面で確かめてもらいます。

出力形式を固定する

支援経過記録の下書きは、構造化出力で次の形にします。

{
  "interview_date": "2026-10-06",
  "statements": [ { "speaker": "本人", "text": "" } ],
  "facts": [ { "item": "", "how_confirmed": "" } ],
  "decisions": [ { "who": "", "what": "", "by_when": null } ],
  "next_steps": [ { "date": null, "what": "" } ],
  "previous_followup": [ { "previous_decision": "", "status": "" } ],
  "flagged_words": [ { "text": "", "speaker": "" } ],
  "observations": "",
  "not_in_memo": [""]
}

1つ目の理由は、statements と facts を別の配列に置けることです。 支援員が直すときに、本人の言葉と確かめた事実を取り違えていないかを、配列ごとに見比べれば済みます。 相談記録システムの支援経過記録の欄にも、この区別のまま流し込みます。

2つ目は、observations を空の文字列として必ず返させられることです。 Microsoft Learn では、構造化出力ではすべてのフィールドを必須にする必要があり、省略可能な項目は null との共用体型で表すとされています。所見の欄を必須の項目として持たせ、中身が空であることを中継の処理で検査します。 欄が無いのか、空なのかを区別できます。

3つ目は、スキーマの制限を先に知っておけることです。 オブジェクトには常に additionalProperties: false を設定し、オブジェクトのプロパティは最大100個、入れ子は最大5レベルです。文字列の minLength・maxLength・pattern・format などはサポートされていません。日付の形式はスキーマで縛れないので、中継の処理で検査します。

連絡票の案は、次の形で受け取り、庁内の様式に流し込みます。

{
  "agency": "地域包括支援センター",
  "purpose": "",
  "items_to_share": [ { "item": "", "text": "" } ],
  "requests": [""],
  "contact": "福祉総合相談課 相談支援係",
  "consent_recorded": true,
  "empty_selection": false
}

items_to_share の item は、支援員が選んだ項目の名前と1対1で対応させます。 中継の処理で、選ばれていない項目の名前が出ていないか、選んだ項目が抜けていないかを突き合わせます。consent_recorded は生成AIに埋めさせず、相談記録システムの同意の記録から中継の処理が入れます。

システムへ連携する

Azure OpenAI のデプロイの種類は、処理の場所で選びます。 Microsoft Learn では、標準のデプロイではプロンプトと応答はお客様が指定した geography の中で処理される一方、「グローバル」のデプロイでは関連するモデルがデプロイされている任意の地域で、「DataZone」ではデータ ゾーン内の任意の地域で処理されうるとされています。住民の相談の内容を扱うので、処理の場所が geography の中に収まる種類を選びます。

相談記録システムへの確定は、支援員の操作でだけ行います。 中継の処理は下書きを画面に返すだけで、支援経過記録の欄に直接書き込みません。

人が確認する

1. 気になる言葉を先に見る … 下書きの先頭に出る flagged_words を読み、必要なら所属長に相談します。ここは下書きを直すより先です
2. 本人の言葉と事実の分け方を確かめる … statements に入るべきものが facts に入っていないかを、メモと照らして見ます
3. 「メモに記載なし」を埋める … 覚えていることがあれば書き足します。覚えていなければ空のまま残します
4. 所見を自分で書く … 所見の欄は支援員が書きます。空のままでは確定できません
5. 連絡票の項目を選び、同意を確かめる … 宛先と伝える項目を選び、本人の同意の記録があるかを確かめてから案を作ります
6. 連絡票は係長と所属長が確かめる … これまでどおりの決裁を経て送ります

1件9分を目安にします。 下書きをメモと照らして直し、所見を書き、連絡票が必要なものは項目を選んで案を直す時間です。下書きを読まずに確定する運用にはしません。

例外に対処する

上の2行が、運用の初めにいちばん多く出ます。 どちらも仕組みの側で止める設計で、止めた件数を月ごとに数えると、置き換えの表と指示のどちらを直すべきかが分かります。

記録を残す

• 面談ごとの、下書きを作った日時と回数、確定に使った下書き
• 生成AIに渡した文章（置き換えたあとのもの）と、返ってきたJSON
• 支援員が直した項目と、直す前と後の文
• 検査で止めた件数と理由（置き換えの漏れ、所見の混入、言葉の不一致）
• 連絡票の宛先、選んだ項目、同意の記録の有無、決裁の記録

3つ目は、下書きの質を測る材料になります。 statements から facts へ移した件数が多ければ、メモの書き方の取り決めか指示を直します。置き換えの表そのものは、ログに残しません。 置き換えたあとの文と、相談記録システムの記録を突き合わせれば、元に戻せるからです。