銀行の営業店から上がる苦情の記録を本部の苦情報告の書式にそろえて要約し、原因の区分と再発防止の案を付けて、苦情対応の担当が月次で確かめられるようにする

処理の起点を決める

起点は、毎晩の苦情管理の仕組みからの書き出しです。 その日に新しく書かれた記録と、対応の経緯が書き足された記録の両方を取ります。苦情等は数日から数週間かけて対応が進むので、書き足しのたびに要約を作り直します。

月末にまとめて動かさないのは、重要案件を待たせないためです。 監督指針は、重要案件を速やかに経営陣などへ報告する態勢を求めています。毎晩動かせば、営業店が記録した翌朝には印の付いた記録が担当の画面に出ます。

要約を作り直すたびに、前の版を残します。 担当が確定した後に記録が書き足されたら、確定を外して「書き足しあり」の印を付け、担当に見直しを求めます。

入力データを集める

質を決めるのは、原因の区分の定義です。 区分の名前だけを渡すと、モデルも担当と同じように揺れます。区分ごとに、当てはまる例と当てはまらない例を2〜3件ずつ書いて渡します。例えば「説明不足」には「手数料の説明を受けていないという申出」、当てはまらない例には「説明を受けたが金額に納得しないという申出（商品・サービスの内容）」を置きます。

記録の文は、置き換えた後のものだけを渡します。 顧客の氏名、口座番号、電話番号、住所、生年月日は、要約にも区分にも要りません。

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

苦情管理の仕組みの書き出しを、中継プログラムが毎晩受け取ります。 CSV か API かは製品によって違い、どちらで取れるかを最初に確かめます。 取れない製品では、担当が毎朝書き出したファイルを決まった場所に置く運用にします。

営業店の名前と担当者の名前は、分けて扱います。 営業店の名前は集計の切り口として残し、担当者の名前は「担当者A」のように置き換えます。 本部の担当が元の記録を開けば分かるので、要約に名前は要りません。

AIへ渡す前に整形する

1. 個人を特定する情報を置き換える … 氏名・口座番号・電話番号・住所・生年月日を、「顧客」「口座X」のような記号に置き換えます
2. 職員の名前を置き換える … 営業店の担当者の名前を「担当者A」「役席B」にします
3. 経緯を日付順に並べる … 書き足しの順がばらばらな記録は、日付で並べ直します
4. 重要案件の語で事前に印を付ける … 「金融ADR」「弁護士」「金融庁」「訴える」「脅し」「高齢」などの語の一覧に当たる記録に、プログラムで印を付けます
5. 前の版と比べる … 書き足しがあった記録は、前の版の要約と確定の状態を添えます
6. 短すぎる記録に印を付ける … 本文が数十字しか無い記録は、要約より先に「営業店へ確かめること」が要る記録として扱います

4番目をモデルとは別に置くのは、取りこぼしを二重に防ぐためです。 モデルが重要案件の疑いを付けなくても、語の一覧に当たった記録は必ず担当の目に入ります。 語の一覧は、お客さま相談室とコンプライアンスの担当が月ごとに見直します。

AIに処理させる

させるのは、記録の文を本部の書式の項目に読み分けて要約し、原因の区分の候補・再発防止の案・営業店へ確かめることを付け、重要案件の疑いに印を付けることです。 苦情かどうか、重要案件かどうかの決定はさせません。

いちばん大事なのは、3行目と4行目を分けることです。 「手数料について事前に説明しており、当店に落ち度はない」は営業店の説明で、確認できた事実ではありません。記録に「申込書の控えで説明の記録を確認した」とあれば、そこで初めて確認できた事実になります。確かめた方法が書かれていない記述は、事実の欄に入れません。

3行目がいちばん起きやすい失敗です。 記録を書いたのは営業店なので、文の多くは営業店の見方で書かれています。何も言わなければ、モデルはその見方のまま「事前に説明していた」を事実として要約します。 書いた人と言った人を分けるよう、指示で明記します。

指示内容を固定する

あなたは銀行の本部のお客さま相談室で、営業店が書いた苦情等の記録を
本部の苦情報告の書式に要約する担当を手伝う立場です。
記録は営業店の職員が書いたものです。顧客が書いたものではありません。

【要約の項目】
申出の要旨／顧客の申出／営業店の説明／確認できた事実／対応の結果

【読み分けの規則】
- 「顧客の申出」には、記録の中で顧客が言った・求めたと書かれている内容だけを入れてください。
- 「営業店の説明」には、担当者が説明したこと、営業店の見方や評価を入れてください。
  「落ち度はない」「納得いただいた」は営業店の見方です。
- 「確認できた事実」には、帳票・記録・映像などで確かめたと、確かめた方法が
  書かれているものだけを入れてください。方法が書かれていなければ入れないでください。
- 記録に無いことは書かないでください。足りない事実は「営業店へ確かめること」に
  質問の形で書いてください。

【原因の区分】
- 区分の定義から1つを選び、選んだ根拠の文を記録から写してください。
- 定義の例に照らして決められないときは「判断できない」を選んでください。

【重要案件の疑い】
- 目安の一覧に当たる記述があれば、当たった目安と根拠の文を写してください。
- 重要案件かどうかを決めないでください。印を付けるだけです。

【書かないこと】
- 苦情・相談・紛争のどれに当たるかの結論
- 顧客や営業店の落ち度についての評価
- 再発防止策を決めたかのような書き方（必ず「案」として書く）
- 置き換えた記号を、元の名前や番号に戻そうとすること

【原因の区分の定義と例】{cause_definitions}
【重要案件の目安】{escalation_criteria}
【記録】{record}

「納得いただいた、は営業店の見方」と例を挙げて書くのは、言い方だけでは分からないからです。 「納得いただいた」は事実の報告のように読めますが、顧客がそう言ったのか、担当者がそう受け取ったのかは記録からは分かりません。例を示すと、モデルは同じ型の文を営業店の説明の側に置きます。

出力形式を固定する

次の形の JSON で受け取ります。

{
  "record_id": "",
  "version": 1,
  "branch": "",
  "channel": "counter | phone | letter | email | other",
  "product": "",
  "gist": "",
  "customer_statements": [""],
  "branch_explanations": [""],
  "verified_facts": [ { "fact": "", "how_verified": "" } ],
  "outcome": "resolved | ongoing | referred_external | unknown",
  "cause_candidate": { "category": "", "basis_quote": "" },
  "prevention_ideas": [""],
  "questions_to_branch": [""],
  "escalation_flags": [ { "criterion": "", "basis_quote": "" } ]
}

1つ目の理由は、customer_statements と branch_explanations を別の配列に持てることです。 本部の書式の別の欄にそのまま流し込め、担当は2つの配列を元の記録と見比べるだけで読み分けの誤りを見つけられます。

2つ目は、verified_facts に how_verified を必須で持たせられることです。 構造化出力はすべての項目を必須にする決まりなので、事実を1つ書けば確かめた方法も必ず書かれます。方法が空の事実は、中継プログラムが営業店の説明の側へ移します。

3つ目は、category と outcome を決まった値で受け取れることです。 原因の区分は Enum にして、定義の区分と「判断できない」だけを許します。定義に無い区分の名前が増えないので、月ごとの集計が比べられます。項目は合計100まで、入れ子は5段までという上限があるので、書式の項目はこの程度の深さに収めます。

4つ目は、escalation_flags を事前の印と突き合わせられることです。 語の一覧で印が付いたのに escalation_flags が空なら、その食い違いも担当に見せます。 片方だけに頼りません。

システムへ連携する

苦情管理の仕組みには書き込みません。 確定した区分を苦情管理の仕組みに入れるのは担当です。要約の下書きが正式な記録に混ざらないようにします。

呼び出しには、Chat Completions を使います。 Responses API はやり取りの履歴を保存する機能を持ちます。1件ずつ要約するだけなので、履歴を残さない呼び出し方にします。

人が確認する

担当は、元の記録と要約を並べて、毎日20件前後を確かめます。 確かめるまで、要約は苦情報告に使いません。

1. 重要案件の疑いを先に見る … escalation_flags と事前の印のある記録を最初に読み、責任者への報告を決めます
2. 読み分けを確かめる … 顧客の申出・営業店の説明・確認できた事実の振り分けを、元の記録の文と見比べます
3. 区分を確定する … 候補と根拠の文を見て、定義に合う区分を選びます。候補と変えたら理由を残します
4. 営業店へ確かめることを送る … 質問を選んで送り、返事が記録に足されたら要約を作り直します
5. 再発防止の案を会議の材料にする … 案のうち会議にかけるものを選びます

2番目を省かないでください。 本部が営業店の説明を事実として報告すれば、顧客に直接確かめる必要がある案件を見逃します。 要約の読み分けが合っているかは、毎回人が見ます。

目標は、400件をならして1件6分です。 短く明快な記録は数分で確定でき、経緯の長い記録や重要案件の疑いのある記録は15分を超えます。

例外に対処する

5行目は、要約の流れに乗せません。 監督指針は、反社会的勢力による苦情等を装った圧力を通常の苦情等と区別し、関係部署に速やかに連絡する態勢を求めています。語の一覧で印が付いたら、要約より先に責任者へ知らせます。

記録を残す

• 書き出した記録（置き換えの前は苦情管理の仕組みにあり、ここでは置き換えた後の文を残す）
• 置き換えの対応表（記号と元の値。行内の限られた担当だけが見られる場所に分けて置く）
• 要約の版ごとの全文、使った指示とスキーマの版、原因の区分の定義の版
• 担当が確定した区分と、候補から変えた理由
• 営業店への確認の依頼と、返事の日付
• 重要案件の疑いの通知と、責任者への報告の記録

4つ目は、区分の定義を見直す材料になります。 候補から変えた理由が同じ区分に集まるなら、その区分の定義の例が足りません。 月ごとに数え、定義に例を足します。

2つ目を分けて置くのは、要約の側から元の個人の情報に戻れないようにするためです。 要約の保管の場所を見られる人と、対応表を見られる人を分けます。