市役所の相談窓口で、新しい相談に似た過去の相談・苦情の対応記録を探し、対応の経緯と関係課を初動の判断に使えるように引く

処理の起点を決める

取り込みと検索で、起点が2つあります。

取り込みは、相談記録の仕組みで相談が終結したことを起点にします。 対応中の相談を取り込まないのは、途中の見立てや、まだ決まっていない受け持ちを検索結果に出さないためです。 終結を通知できない仕組みなら、毎晩、終結日で絞った一覧を取りに行きます。

過去の約6万件は、別に一括で取り込みます。 このときは終結させた職員の確認が取れないので、経緯に「未確認」の印を付けます。過去の記録ほど、事務分掌が今と違うことが多いので、受付日も検索結果に必ず出します。

検索は、職員が検索画面で「探す」を押したときに動きます。 電話を受けながら使うので、入力から結果が出るまでを短くすることを優先します。 Claude のまとめは、検索の一覧を先に表示したあとで追って表示します。

入力データを集める

質を決めるのは、言い換えの辞書と事務分掌の一覧です。 辞書が無ければ、言葉の違いで記録を取りこぼします。事務分掌の一覧に課の名前の変更の履歴が無ければ、過去の記録の「生活環境課」が今のどの課なのかが分かりません。 組織の改編のあった年をまたいで探すには、この履歴が要ります。

氏名・住所・連絡先の項目は、最初から取り込みの対象にしません。 同じ人からの繰り返しの相談かどうかは、相談記録の仕組みの側で、権限のある職員が確かめます。 検索基盤には、個人を結びつける項目を持たせません。

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

相談の記録は、相談記録の仕組みから文字で取り出します。添付のファイルや写真は取り込みません。 要旨と経過の文、関係課、終結の区分だけを対象にします。

検索は、要旨の項目を重く、経過の項目を軽くして探します。 要旨は相談の中身、経過は役所の中の動きで、経過の言葉で当たった記録は、中身が違うことが多いためです。分類が入力されていれば、filter ではなく加点に使います。分類は職員によって付け方が違うので、絞り込みにすると取りこぼします。

AIへ渡す前に整形する

1. 個人を特定する言葉の除去（取り込み時） … 要旨と経過の文を Amazon Bedrock Guardrails の機微な情報のフィルターに通し、名前（NAME）、電話番号（PHONE）、住所（ADDRESS）、メールアドレス（EMAIL）を、{NAME} のような種類の記号に置き換えます
2. 市の独自の番号の除去 … 宛名番号や受付番号の形の文字列は、正規表現のフィルターで伏せます。正規表現は先読み・後読みに対応していないので、単純な形で書きます
3. 伏せた結果の確認 … 伏せた件数が多い記録は、取り込みを止めて一覧に載せます。伏せる運用が守られていない課を見つける材料にもなります
4. 課の名前の読み替え … 事務分掌の一覧の履歴から、当時の課の名前に今の課の名前を併記します
5. 辞書の反映 … 言い換えの辞書は検索時の解析器だけに使い、updateable を true にします。索引を作り直さずに辞書を差し替えられるようにするためです
6. 長い経過の分割 … 経過の文が長い記録は、取り次ぎごとの段落に分け、段落の番号を付けます

1番目は、伏せる運用の代わりではありません。 ドキュメントでは、このフィルターは文脈に依存する確率的な機械学習の仕組みとされており、日本語の名前や住所をどこまで見つけられるかは、公式には書かれていません。 第8章の試しで、伏せた結果を人が見て確かめます。漏れがあれば、正規表現と記録の書き方の両方で補います。

5番目を軽く見ないでください。 ドキュメントでは、updateable は検索時の解析器にだけ使え、索引時の解析器に辞書を使うと、更新のたびに索引を閉じて開き直すか、作り直す必要があるとされています。言い換えは毎月足していくものなので、最初から検索時の解析器に置きます。

言い換えの辞書は、1行に同じことを指す言い方を並べる形で作ります。

ごみ屋敷, 不良な生活環境, 物があふれた住宅
空き家, 空家等, 管理されていない家
音がうるさい, 騒音, 生活音
木がはみ出している, 越境した枝, 樹木の越境
道路の穴, 舗装の損傷, 道路の陥没

索引時の解析器は Sudachi だけ、検索時の解析器は Sudachi に synonym_graph を足したものにします。 索引の側に言い換えを入れないので、辞書を足しても登録済みの6万件を作り直す必要がありません。1行に並べる言い方は、市民相談課が「この言い方で来た相談は、この書き方で記録した」と確かめたものだけにします。 意味の広い言葉（「困っている」「迷惑」など）は入れません。入れると、関係の無い記録が大量に当たります。

AIに処理させる

AIの仕事は2か所です。取り込み時の経緯の取り出しと、検索結果のまとめです。

1行目がいちばん外せない線です。 10件のうち8件が同じ課で受け持たれていると、AIは「本件は〇〇課の担当です」と書きたくなります。この一文を相談者にそのまま伝えると、受け持ちの決まっていない課に相談者を案内することになります。

5行目も必ず指示に入れます。 経過の文には、職員が相談の様子を書いた言葉が残っています。それをまとめの文で要約すると、相談者についての評価のように読める文ができます。

指示内容を固定する

取り込み時（経緯の取り出し）：

あなたは市役所の市民相談課で、終結した相談の記録を整理する担当です。
対応の経過の文だけを根拠にしてください。推測で埋めないでください。

【やること】
次の項目を取り出してください。
- 取り次ぎの順番：課の名前を、経過に書かれた順に並べる
- 受け持った課：最後に対応した課
- 対象外として戻した課と、その理由（経過に書かれた文をそのまま写す）
- 根拠にした制度や条例の名前（経過に書かれたものだけ）
- 終結の区分：resolved / referred_outside / explained_only / withdrawn / unresolved

【厳守事項】
- 経過に書かれていない課や対応を足さないでください。
- 戻した理由が書かれていなければ「記載なし」としてください。
- 制度の名前が書かれていなければ null にしてください。補わないでください。
- {NAME} {ADDRESS} {PHONE} などの記号を、元の情報に戻そうとしないでください。
- 相談者の人柄や態度についての記述は、項目に含めないでください。

検索時（結果のまとめ）：

あなたは相談窓口の職員の調べものを助ける担当です。
渡された検索結果だけを根拠に、過去の相談の扱いを並べてください。

【新しい相談の要点】{request}
【過去の相談（上位10件）】検索結果として渡します

【書くこと】
1. 各記録の相談の要旨、取り次ぎの経緯、受け持った課、終結の区分
2. 対象外として戻した課があれば、その理由（記録の記載どおり）
3. 受け持った課が記録によって違うときは、記録に書かれた違い

【厳守事項】
- 今回の相談をどの課が受け持つかを書かないでください。
- 相談者への回答を書かないでください。
- 件数の多い課を、担当の課として書かないでください。
- 相談者の人柄や態度に触れないでください。
- 受付日の古い記録には、受付日を必ず添えてください。

検索結果は、Claude の検索結果ブロックで渡します。 1件の記録を1つの search_result にし、source に受付番号と受付日、title に分類と受け持った課、content に要旨と取り次ぎの段落を別々のテキストブロックで入れます。引用を有効にすると、まとめの文ごとにどの記録のどの段落を根拠にしたかが付きます。 職員は、一覧の1行から元の記録へそのままたどれます。

「件数の多い課を担当として書かない」は、取り次ぎ先を書かせない指示とは別に書きます。 取り次ぎ先だけを禁じると、「多くは〇〇課が対応しています」という形で同じことを書きます。

出力形式を固定する

取り込み時の経緯は、次の形のJSONで受け取ります。

{
  "case_id": "SD-2024-007215",
  "received": "2024-06-12",
  "route": ["市民相談課", "道路管理課", "みどり公園課"],
  "handled_by": "みどり公園課",
  "returned": [ { "section": "道路管理課", "reason": "", "paragraph": 2 } ],
  "basis": [""],
  "closure": "resolved | referred_outside | explained_only | withdrawn | unresolved",
  "redacted_count": 0,
  "unconfirmed": false
}

1つ目の理由は、route と returned で、たらい回しの経緯を項目にできることです。 「道路管理課に回したが対象外で、みどり公園課が受け持った」という経緯が、文の中ではなく項目として残ります。次の職員は、道路管理課に電話をかける前に、この経緯を読めます。

2つ目は、closure を決まった値に限れることです。 解決した相談と、説明だけで終わった相談と、市の外の機関に案内した相談では、初動の判断に使える情報が違います。 一覧で区別して見せます。

3つ目は、redacted_count で、伏せる運用の守られ方を数えられることです。 伏せた件数を課ごとに集計すると、記録の文に個人の情報を書いてしまう課が分かります。

検索の要求は、次の考え方で組みます。

システムへ連携する

言い換えの辞書の更新は、月に1回の手順にします。 ドキュメントでは、S3 のファイルを差し替えても、OpenSearch Service の側のパッケージは自動では更新されません。 パッケージを更新してドメインに適用し、検索時の解析器が updateable なら、検索時の解析器の再読み込みは自動で行われるとされています。

相談記録の仕組みには書き込みません。 取り次ぎ先と対応の記録は、職員が相談記録の仕組みに自分で書きます。

人が確認する

確認は2か所です。取り込み時の職員と、検索時の窓口の職員です。

1. 終結させた職員が経緯を確定する … 取り次ぎの順番と受け持った課、戻した理由を確かめます。伏せた件数が多い記録は、伏せ方が正しいかも見ます
2. 窓口の職員が取り次ぎ先を決める … 一覧と経緯を読み、取り次ぎ先を自分で決めます。迷うときは、受け持ちそうな課に確かめてから相談者に伝えます
3. 古い記録は今の事務分掌で読み直す … 受付日が組織の改編より前の記録は、今の課の名前で読み替えて判断します
4. 拾えなかった言葉を報告する … 探しても出てこなかった言い方は、検索画面から報告し、市民相談課が辞書に足します

1件の相談あたり5分を目安にします。 一覧と経緯を読み、必要なら元の記録を1〜2件開く時間です。まとめの文を相談者に読み上げる運用にはしません。

3番目は、異動の多い職場ほど効いてきます。 過去の記録の課の名前が今の組織と違うと、着任したばかりの職員はその課がどこになったかを知りません。読み替えの表示があれば、取り次ぐ先を組織図で探し直す手間がなくなります。

例外に対処する

6行目が、この構成でいちばん大事な例外です。 こうした相談の記録は、似た相談として窓口の一覧に出るだけで、関わる人の安全に関わります。 担当課の外には、検索の段階で出さない設計にします。

記録を残す

• 取り込んだ記録の受付番号、終結日、取り込んだ日時、伏せた件数
• Claude が返した経緯のJSONと、終結させた職員が確定した時に直した項目
• 検索のたびの入力（伏せたあと）、上位10件、当たった言い換え
• Claude に渡した検索結果と、返ってきたまとめと引用
• 職員が決めた取り次ぎ先と、参照した記録
• 「似た過去の相談は見つかりませんでした」と出た入力と、報告された言い方

ログにも個人の情報を残さないようにします。 ドキュメントでは、Guardrails の伏せる処理はモデルへの入力と出力にだけ効き、モデルの呼び出しのログには元の入力がそのまま残るとされています。伏せる処理の結果の中にも、見つけた元の値が入ります。 ログの側でも伏せる設定を入れ、伏せる処理の結果は保存しません。