銀行の店頭・コールセンター・アプリに寄せられる「お客さまの声」を苦情・要望・称賛と商品・手続きの区分に分け、経営への月次報告の下書きにまとめる

処理の起点を決める

動きは2つで、頻度を分けます。

分類を毎朝にするのは、2つの理由からです。 1つは、月初の1週間に集中していた確認の負荷をならすためです。もう1つは、金融庁の監督指針が、苦情等とその対処結果を類型化のうえで内部管理部門や営業部門に報告し、重要案件は速やかに監査部門や経営陣に報告する態勢を求めているためです。月に1回まとめて読む作りでは、重要案件が上に届くのが最長で1か月遅れます。

月次報告は、前月の最終日の分まで確定してから動かします。 第1営業日の朝の時点で前月末の数日分が未確定なら、確定を待ってから集計します。未確定のまま集計すると、AIの候補の区分がそのまま件数に入ります。

入力データを集める

質を決めるのは、事象の一覧です。 AIは声を読んで「同じ事象らしい」とは言えますが、その日にアプリの障害があったことは知りません。 システム部や商品部から届く出来事の連絡を一覧にして渡すと、「10月3日のアプリの障害」という名前で束ねられます。 一覧に無い事象は、AIに名前を付けさせず「未登録の事象の候補」として返させます。

過去の確定例は、第3章の（c）への手当てです。 苦情と要望の境目の声について、人がどちらに倒したかを10〜20件、指示に添えます。境目の判断を毎月同じ側にそろえるための材料です。

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

3つの経路の記録を、同じ形にそろえてから渡します。 共通の欄は、受付日、経路、営業店（店頭のみ）、本文、対応の経過です。アプリの声には営業店がなく、店頭の声にはアプリのバージョンがありません。 無い欄は空のまま渡し、AIに埋めさせません。

対応の経過は、苦情の候補を確かめるときに効きます。 「ご説明により納得された」と書かれている店頭の声と、「後日改めて連絡」と書かれている声では、同じ苦情でも報告での重みが違います。 経過は分類には使わず、長期未済の判定と要旨の材料にします。

AIへ渡す前に整形する

1. 形式をそろえる … 3つの経路の記録を、共通の欄に並べ替えます
2. 個人を特定する情報を伏せる … 氏名、口座番号、電話番号、住所、生年月日、カード番号を、Python の規則で [氏名] [口座番号] のような記号に置き換えます
3. 短すぎる声を分ける … アプリの声で「最悪」「使いにくい」だけのものは、分類には回しますが、要旨の材料からは外す印を付けます
4. 重複を落とす … 同じお客さまが同じ日にアプリとコールセンターの両方で同じことを申し出た場合、受付番号を並べて1件にまとめる候補を付けます
5. 事象の一覧の日付で絞る … その声の受付日の前後7日に起きた事象だけを、指示に添えます
6. 長い対応メモを切る … コールセンターの対応メモが長いものは、最初の受付の内容と最後の経過だけを残します

2番目は、AIに渡す前に必ず済ませます。 声の本文には、お客さまが自分で口座番号や電話番号を書いていることがあります。伏せ忘れを見つける仕組みとして、伏字の後の本文に数字が8桁以上続く箇所があれば、その声を分類に回さず担当者に戻します。

4番目は、AIではなく規則で行います。 お客さまを特定できる番号は伏せた後なので、伏せる前の段階で同じお客さまかどうかの印だけを付けておき、その印で束ねます。 AIに同じお客さまかを推測させることはしません。

AIに処理させる

分類の段でさせるのは、5つの欄を埋めることです。

1行目の「苦情の候補に倒す」が、第3章の（c）への答えです。 監督指針は、苦情と紛争の区別は相対的で相互に連続性を持つとし、申出を形式的に切り分けて対処しないことを求めています。 苦情と要望の境目も同じ扱いにし、AIは苦情から外す方向の判断をしません。 外すのは、確認する人です。

5行目の反社会的勢力の印は、AIには「付ける」ことしかさせません。 監督指針は、反社会的勢力による苦情等を装った圧力を通常の苦情等と区別し、関係部署に速やかに連絡する態勢を求めています。区別する判断そのものは人が行い、AIの印はその入口にすぎません。

月次報告の段でさせるのは、2つの文を書くことです。 苦情の上位の区分ごとの要旨と、再発防止の論点の候補です。件数・前月比・順位は、すべて Python の集計から差し込みます。

指示内容を固定する

分類の段の指示（システムメッセージ）：

あなたは地方銀行のお客さま相談室で、お客さまの声を分類する担当です。
渡された声を1件だけ読み、決められた欄を埋めてください。

【声の種類 voice_type】
- complaint ... 不満・不便・不信の表明が含まれる
- request ..... 改善や新しいサービスの希望だけで、不満の表明が無い
- praise ...... 職員の応対やサービスへの感謝・評価
- other ....... 問い合わせ・手続きの依頼など、上のどれにも当たらない
不満の表明が少しでも含まれていれば complaint を選んでください。
要望の形をとっていても、不満が書かれていれば complaint です。
complaint を request や other に倒す判断はしないでください。

【商品・手続きの区分 category】
{category_list}
main_category に1つ選び、必要なら sub_category に1つ選んでください。
どれにも当たらなければ other とし、category_note に理由を書いてください。

【事象のまとまり event】
次の一覧のどれかに当たれば、その event_id を入れてください。
{event_list}
当たらないが、同じ出来事への声が他にもありそうなら
event_id を unregistered とし、event_note に出来事を短く書いてください。
一覧に無い出来事に、名前や日付を作らないでください。

【重要案件の印 escalation_flags】
次に当たると読める記載があれば、該当するものをすべて入れてください。
- legal_concern ...... 法令違反・不正・説明義務違反の疑いの申出
- antisocial ......... 威圧的な要求・金品の要求・組織名を示した圧力
- media_mention ...... 報道機関・SNS・監督官庁・弁護士への言及
- repeated ........... 同じ営業店・同じ職員について繰り返し申し出ている旨
迷ったら入れてください。

【厳守事項】
- evidence には、判定の根拠にした本文の一部をそのまま写してください。
- 本文に書かれていない原因や事情を補わないでください。
- [氏名] [口座番号] などの伏字を推測で戻さないでください。
- confidence は high / medium / low で、迷った欄があれば low にしてください。

【過去の確定例】{precedents}
【声】{voice_record}

「要望の形をとっていても、不満が書かれていれば complaint」を書かないと、AIは文の末尾で判断します。 「〜してほしい」で終わる声は、前半に不満があっても要望になります。文の形ではなく中身で選ばせる一文です。

事象の段で「名前や日付を作らない」を明記するのは、AIが親切に事象名を付けるからです。 「10月上旬のアプリ障害」と書かれると、確認する人はそれが実際にあった障害だと読みます。一覧に無いものは、無いと返させます。

月次報告の段の指示（要点）： 「次の集計表の数字は変えずに使い、数字を新しく書かないでください。苦情の上位5区分について、確定した要旨の一覧から共通する内容を2〜3文でまとめてください。事象ごとに束ねた件数と、事象に属さない苦情の件数を分けて書いてください。再発防止の論点は、要旨に書かれた事実から言えることだけを、候補として3つまで挙げてください。対策を決めた書き方をしないでください」

出力形式を固定する

分類の段は、次の形のJSONで受け取ります。

{
  "voice_id": "",
  "channel": "branch | call_center | app",
  "voice_type": "complaint | request | praise | other",
  "main_category": "",
  "sub_category": "",
  "category_note": "",
  "event_id": "",
  "event_note": "",
  "escalation_flags": [""],
  "evidence": "",
  "confidence": "high | medium | low",
  "use_for_summary": true
}

構造化出力で、このスキーマに沿わせます。 Chat Completions では response_format に json_schema と strict: true を指定します。すべての欄を必須にし、オブジェクトには additionalProperties: false を付ける決まりがあり、欄の数は全体で100まで、入れ子は5段までとされています。minItems や文字列の長さの指定は使えないので、evidence が空でないかなどの検査は Python の側で行います。

JSONで受ける理由は3つです。 1つ目は、voice_type と main_category を区分の一覧の値に限れることです。表記の揺れた区分名が集計に入りません。2つ目は、evidence を本文と照らせることです。evidence が本文にそのまま含まれていなければ、AIが言い換えたか作ったかなので、確認の一覧で上に出します。 3つ目は、escalation_flags を規則で読めることです。

称賛は、営業店へ返します。 確定した称賛の声は、営業店ごとに束ねて月に1回送ります。苦情の分類の仕組みが、職員への励ましの経路にもなります。

システムへ連携する

苦情等管理システムへは自動で書き込みません。 確定した区分を登録するのは担当者です。AIの候補が、確認を経ずに正式な記録に入る経路を作りません。 監督指針は、苦情等の内容と対処結果を適切かつ正確に記録・保存することを求めており、正式な記録の区分は人が確定したものにします。

営業店への称賛の送付も、下書きまでです。 店長宛ての送付は、お客さま相談室が内容を確かめてから行います。

人が確認する

毎日の確認は、お客さま相談室の3名で行います。

1. 重要案件の印の付いた声を最初に見る … 室長が、関係部署への連絡と、経営陣への報告が要るかを決めます
2. 苦情の候補を全件見る … 種類と区分を確定します。要望やその他に変えるときは、理由を一言残します
3. 確信の低いもの、根拠の文が本文に無いものを見る … 区分を確定し、必要なら事象の一覧に新しい事象を足します
4. 要望・称賛・その他の抜き取りを見る … 1割を見て、AIの候補との食い違いを記録します

月次報告の確認は、経営企画部の担当とお客さま相談室長が行います。 下書きの数字に印が付いていないか、要旨が確定した区分の声から書かれているか、論点が事実から言える範囲かを見ます。論点を経営会議に出すかどうかは、ここで決めます。

2番目で「外すときは理由を残す」が効いてきます。 苦情から外した理由が残っていれば、翌月、同じ境目の声を過去の確定例として指示に添えられます。 確定例が積み上がるほど、AIの候補と人の確定が近づきます。

目標は、1,200件をならして1件2分です。 苦情の候補は全件を読むので数分かかり、確信の高い要望・称賛は数秒で流れます。

例外に対処する

4行目は、この構成でいちばん早く役に立つ例外です。 システム部からの連絡より先に、お客さまの声のほうが障害を知らせることがあります。 未登録の事象の件数が跳ねたら、それ自体が知らせになります。

記録を残す

• 書き出した元の記録（3つの経路）と、伏字の後の本文
• Azure OpenAI に渡した指示と、返ってきたJSONの全文、呼び出した日時とデプロイの名前
• 人が確定した区分と、AIの候補との違い、変えた理由
• 重要案件の印に対して、室長が決めた扱い（関係部署への連絡、経営陣への報告）
• 月次報告の集計表と、下書きの文と、確定した報告の差分
• 事象の一覧の版（いつ、どの事象を足したか）

3つ目の「変えた理由」が、次の月の確定例になります。 理由が残っていないと、同じ境目で毎月同じ迷いが起きます。

5つ目の差分は、下書きがどれだけ使われたかを見るためです。 論点の候補がほとんど書き直されている月が続くなら、指示に添える材料（要旨の一覧、事象の一覧）のどちらかが足りていません。