市役所の生活保護のケースワーカーが家庭訪問・面談のメモから、Azure OpenAI でケース記録の下書きと次回の訪問で確かめる事項を作る

処理の起点を決める

ケースワーカーが下書き画面からメモを送ったときに動かします。 訪問から戻った順に1件ずつ送り、まとめて夕方に送る運用にはしません。 時間がたつほどメモの断片の意味を思い出せなくなり、下書きの直しが増えるからです。

下書き画面は、庁内の業務用パソコンからだけ開けるようにします。 職員の認証を通った人だけが使え、送った人の職員番号が入力と一緒に残る作りにします。どの職員がどの世帯の下書きを作ったかを、後から追えるようにするためです。

どのネットワークの区分から Azure へつなぐかは、自治体の情報セキュリティポリシーに沿って情報政策の部署と決めます。 この部分は自治体ごとに違い、本記事では前提を置きません。つなげる区分が決まらないうちは、第8章の最小構成で試すにとどめてください。

入力データを集める

質を決めるのは、援助方針と前回の確認事項です。 これが無いと、AIは「何を確かめるはずだったか」を知りません。援助方針に「通院の継続」とあり、メモが通院に触れていなければ、 それが次回の確認事項の先頭に来ます。

氏名・住所・生年月日・保護の決定額は渡しません。 下書きに要るのは、続柄と年代、援助方針、メモの中身だけです。世帯は世帯番号で扱い、メモの中でも人は続柄で書く決まりにします（「長女」「元夫」「主治医」）。

子どもの世帯員の情報は、特に絞ります。 学校名、学級、部活動の名前、友人の名前は、続柄と年代だけでも世帯を特定する手がかりになります。メモには「長女・中学生、通学継続」のように書き、固有の名前を書かない決まりにします。医療機関や勤め先も同じで、「主治医」「勤め先」と書けば記録の役目は果たせます。固有の名前が要る場面は、確定のときにケースワーカーが業務システムの画面で書き足します。

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

業務システムの書き出しは、提供元に確かめて決めます。 多くの業務システムには帳票や一覧の書き出しの機能がありますが、項目や形式は製品ごとに違います。書き出しの列に氏名を含めないよう、最初の段階で指定してください。 含まれてしまうと、プログラムの側で消す手間と、消し忘れの危険が生まれます。

書き出しは前の晩の時点のものです。 当日の午前に援助方針を見直した世帯は、下書きに古い方針が使われます。下書き画面に、書き出しの日時を必ず表示します。

AIへ渡す前に整形する

1. 世帯番号で引く … 送られた世帯番号が、送った職員の担当の世帯かを確かめます。担当外なら送信を止めます
2. 援助方針を項目に分ける … 援助方針の「確かめ続ける項目」を、1行1項目の一覧にします
3. メモの「所見：」を切り出す … 「所見：」で始まる行を、所見の候補として印を付けます
4. 氏名らしい文字列を検知する … 「〇〇さん」「〇〇様」のような形や、書き出しにある世帯員の氏名の文字列（照合のためだけに使い、AIには渡さない）が含まれていないかを見ます。見つかれば送信を止め、続柄に直すよう画面に出します
5. 略語をそろえる … 「通院月2→1」「就労✕」のような略記の意味を、決まりの略語の一覧で添えます
6. 1回に1世帯だけ … 複数の世帯のメモを混ぜて送れない作りにします

4番目は、AIの前に置く安全装置です。 メモに氏名を書かない決まりを作っても、急いでいると書いてしまいます。送る前に止めることで、 氏名が Azure に送られること自体を防ぎます。

1番目で担当外の世帯を止めるのは、必要な人だけが情報を扱うためです。 下書きの仕組みが、担当以外の世帯の援助方針を引ける抜け道にならないようにします。

AIに処理させる

させるのは、メモを項目ごとの事実と所見に振り分けて文章にし、援助方針の進み具合と次回の確認事項を挙げることだけです。

事実の項目は、研修教材が訪問調査で確認すべきこととして挙げる健康状態、社会生活、将来に向けた希望、世帯の家計や住環境をもとに立てています。 研修教材は、居宅訪問では年間を通じて世帯員全員と面接し、援助方針の進み具合を確かめることも大切だとしています。世帯員の状況の欄を独立させているのはこのためです。

2行目が、いちばん起きやすい失敗です。 メモに「冷蔵庫空き目立つ」とあれば、AIは「食費に困っている様子」と書きたくなります。事実の欄に書けるのは「冷蔵庫の中の食品が少なかった」までです。 困っているかどうかは、ケースワーカーが所見として書くことです。

指示内容を固定する

あなたは福祉事務所の生活保護のケースワーカーが、ケース記録を書くのを
手伝う立場です。入力の【メモ】【訪問の種類と目的】【援助方針】
【前回の確認事項】【世帯の構成】だけを根拠に、下書きを作ってください。

【書き方】
- 事実の欄には、本人・世帯員が話したことと、ケースワーカーが見たことだけを
  書いてください。話したことは「〜と話す」、見たことは「〜であった」の形にします。
- 事実の欄に、推し量りや評価を書かないでください。
  「〜と思われる」「〜の様子」「〜が心配される」は事実ではありません。
- 所見の欄には、【メモ】の「所見：」で始まる行の内容だけを、文章に整えてください。
  「所見：」の行が無ければ、所見の欄は「【ケースワーカーが記入】」とだけ書いてください。
- 人は続柄で書いてください（本人、長女、主治医など）。
  入力に氏名らしいものがあっても写さず、warnings に書いてください。
- 本人が話した希望は、話した言葉に近い形で残してください。

【厳守事項】
- メモに書かれていないことを書かないでください。推測で補わないでください。
- メモが触れていない事実の項目は「記載なし」としてください。
  「特に変わりなし」「問題なし」で埋めないでください。
- 保護の要否、保護の程度、指導・指示が必要かどうかに触れないでください。
- 援助方針を変えるべきかどうかを書かないでください。
- 【援助方針】の項目ごとに、メモに関係する事実があれば progress に要点を、
  無ければ「今回確かめていない」と書いてください。
- 【前回の確認事項】のうち、メモが触れていないものは、
  next_checks の先頭に carried_over を true にして挙げてください。

【訪問の種類と目的】{visit}
【世帯の構成】{household}
【援助方針】{policy}
【前回の確認事項】{prev_checks}
【メモ】{memo}

「〜と思われる」を名指しで禁じているのは、事実と所見を分けるためです。 「推測しない」とだけ書くと、AIは「〜の様子」を推測とは考えません。禁じる言い回しを具体的に書くことで、 推し量りが事実の欄に混ざるのを止めます。

「特に変わりなし」で埋めないことも同じ理由です。 メモが健康状態に触れていないとき、「特に変わりなし」と書かれた記録は、確かめて変わりが無かったという意味に読まれます。 確かめていないなら「記載なし」です。

出力形式を固定する

{
  "case_ref": "",
  "visit_purpose": "",
  "facts": {
    "health": "",
    "social_life": "",
    "household_budget_and_housing": "",
    "household_members": "",
    "wishes": ""
  },
  "cw_findings": "",
  "cw_findings_needed": true,
  "policy_progress": [ { "policy_item": "", "progress": "" } ],
  "next_checks": [ { "item": "", "carried_over": true } ],
  "warnings": [ "" ]
}

構造化出力では、すべてのフィールドを必須にし、オブジェクトには additionalProperties: false を設定するとされています。スキーマのプロパティは最大100個、入れ子は最大5段です。この形は2段の入れ子で収まります。

JSON にする1つ目の理由は、事実と所見を別の欄で受けられることです。 下書き画面では、事実の欄と所見の欄を色を分けて表示し、所見の欄が「【ケースワーカーが記入】」なら確定のボタンを押せない作りにします。所見を書かないまま記録が確定することを防ぎます。

2つ目は、policy_progress をプログラムが照合できることです。 AIが援助方針の項目を1つ落としても、前処理で作った項目の一覧と突き合わせ、返ってこなかった項目を「今回確かめていない」として足します。 確かめていない項目の挙げ漏れを、AIの出来に頼らずに防ぎます。

3つ目は、next_checks を次回の訪問の前に表示できることです。 確定したときの確認事項を保存しておき、次にその世帯番号を入れたとき、下書き画面の最初に出します。 担当が交代しても同じものが出ます。

システムへ連携する

業務システムへの書き込みの経路は作りません。 ケース記録は、保護の決定の根拠や不服申立ての際の根拠資料にもなる記録です。ケースワーカーが読んで確かめていない文が、そのまま記録に入る経路を作らないでください。

下書き画面に残るのは、確定までの下書きだけです。 記録の正本は業務システムにあり、下書きは確定から一定の期間で消す決まりにします（第7章の保存・ログ）。

人が確認する

下書きは全件、ケースワーカーが読んでから記録します。

1. 事実の欄をメモと照らす … 話していないことが「〜と話す」になっていないか、見ていないことが「〜であった」になっていないかを見ます
2. 所見を書く … 「【ケースワーカーが記入】」なら自分で書きます。整えられた文なら、自分の考えと同じかを確かめます
3. 援助方針の進み具合を見る … 「今回確かめていない」の項目は、次回の確認事項に残っているかを確かめます
4. 次回の確認事項を直す … 不要なものを消し、足りないものを足します
5. 業務システムに貼り付けて確定し、決裁に回す

1番目の「話していないことが話したことになっていないか」を、最も丁寧に見てください。 ケース記録は不服申立ての際の根拠資料にもなります。本人が言っていないことが「〜と話す」と残ると、 後から記録の信頼そのものが問われます。

査察指導員の決裁は、いまと同じです。 この構成は決裁の手順を変えません。査察指導員は、月に1回、各ケースワーカーの下書きと確定した記録を数件見比べ、 下書きのまま確定している記録が続いていないかを見ます。

例外に対処する

6行目は、この構成の外に置いてください。 研修教材では、長期間不在が続き連絡が取れないような場合、ケースワーカーは1人で対応せず、まず査察指導員に報告し、組織的な対応を検討することが求められるとされています。下書きを作る手順が、急ぎの報告を遅らせてはいけません。

記録を残す

• 確定した記録 … いまと同じく業務システムのケース記録に残します
• 入力と下書き … メモ、援助方針の書き出しの日時、AIの下書きを、確定から一定の期間（例：3か月）だけ残して消します
• 操作の記録 … 誰が、いつ、どの世帯番号の下書きを作ったか。送信を止めた記録（氏名の検知、担当外）
• 次回の確認事項 … 確定したときの next_checks を世帯番号ごとに残し、次の訪問の前に表示します
• 決まりの版 … 指示の文、略語の一覧、事実の項目の立て方を、変更のたびに日付付きで残します

下書きを長く残さないのは、正本と重ならないようにするためです。 下書きと確定した記録が両方残ると、どちらが記録なのかが分からなくなります。 下書きは確定までの作業の材料として扱います。

操作の記録は、長く残します。 担当外の世帯の情報を引こうとした記録や、氏名を送りかけた記録は、安全管理の見直しの材料になります。