保険会社のコールセンターと代理店から上がる苦情の記録を、苦情の区分と原因で分類し、毎月の苦情報告と改善の検討資料の下書きを作る

処理の起点を決める

起点は2つあります。日々の分類と、月次の報告です。

日々の分類は、SharePoint のライブラリに前日分の書き出しが置かれたことを起点にします。毎朝7時に書き出せば、出社時には候補が並んでいます。重大な申出は、課長に回るまでの時間がそのまま顧客を待たせる時間になります。

月次の報告は、Power Automate の「繰り返し」のトリガーで毎月1日の朝に動かします。タイムゾーンを日本の時刻に合わせて開始時刻を指定します。前月分の区分の確定が終わっていないと集計が狂うので、1日の時点で未確定の記録が残っていれば、集計を止めて担当者に知らせます。

原因区分の付け直しは、対応の記録が完了になったことを起点にします。毎朝の書き出しに「前日に対応が完了した記録」も含めてもらい、同じフローで原因区分だけを付け直します。

入力データを集める

質を決めるのは、苦情分類コード表の書き方です。 中分類の名前だけを渡すと、AIは名前から想像して付けます。「含めないもの」と「紛らわしい中分類との違い」を1行ずつ持たせると、担当者が迷っていた境目でAIも同じ基準で選びます。 第3章の（a）を直す作業そのものなので、AIを入れるかどうかにかかわらず効きます。

判定例には、典型的な記録ではなく、課内で揉めた境目の記録と決めた理由を入れます。

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

コード表には版を持たせます。 中分類を足したり分けたりすると、前年同月との比較の意味が変わります。各行に「有効開始月」と「有効終了月」を持たせ、分類したときの版を記録に残します。

「アイテムを取得」は上位カウントの既定値がすべてなので、600件程度なら一度に読めます。接続ごとに60秒あたり600回の呼び出しの上限があるため、書き込みはまとめて回す件数を絞ります。

AIへ渡す前に整形する

1. 1件ずつに分ける … 書き出しのファイルを記録の番号で分け、受付と対応の記録を同じ単位にまとめます
2. 個人を特定する情報を伏せる … 氏名、電話番号、住所、証券番号、事故の受付番号を、[氏名] [証券番号] のような記号に置き換えます。記録の番号との対応表はフローの側で持ちます
3. 経路の印を付ける … コールセンターか代理店かを入力に含めます。代理店の場合は代理店の区分（専属・乗合）も付けます
4. 短すぎる記録を分ける … 申出の内容が20字未満の記録は、AIに渡さず「情報不足」として確認リストに直接入れます
5. 長すぎる記録を切る … 対応の記録が長いものは、直近の経過と結果の部分を残し、途中の電話のやり取りを要約せずに省きます
6. 重複の確認 … 同じ顧客の同じ件が、コールセンターと代理店の両方から上がっていないかを、伏せる前の証券番号で照らします
7. コード表の版を選ぶ … 受付日に有効な版の苦情分類コード表を選びます

2番目を省かないでください。 区分を付けるのに顧客の氏名は要りません。伏せてから渡しても分類の結果は変わらず、外へ出す情報だけが減ります。

6番目の重複の候補は、1件にまとめず印を付けて人に見せます。 同じ顧客の別の申出であることもあるからです。

AIに処理させる

させるのは、記録1件ごとに次の5つを答え、それぞれの根拠にした文を記録からそのまま引くことです。

いちばん大事なのは、1行目の右端です。 監督指針は、苦情と紛争の区別は相対的で相互に連続性を有するもので、顧客からの申出を形式的に切り分けるのではなく、相対性・連続性を勘案して対処することが重要としています。AIに求めるのは切り分けではなく、「外さない」ことです。 inquiry_only を付けてよいのは、不満の表明が記録のどこにも無いときだけです。

3行目の undetermined も同じくらい大事です。 受付の記録だけで原因を書かせると、「説明不足」がいちばん多くなります。どの申出も、説明が足りなかったと言えば言えてしまうからです。 原因区分は、対応の記録に調べた事実が書かれているときだけ埋めます。

4行目の印は、規則の側で使います。 監督指針は、保険金等の不払いに関する苦情等について、不払いを決定した支払担当部門のみで対処するのではなく、最終的にはコンプライアンス担当部門などの他の部門で適切に対処されたかを検証する態勢を求めています。代理店を含む外部委託先の苦情等は、漏れなく報告される態勢が求められています。印が付いたものは、確認先へも回します。

最後の行は、監督指針が苦情等を装った圧力を通常の苦情等と区別して関係部署に速やかに連絡することを求めている点に対応します。 判定を誤れば顧客を不当に扱うので、印を付けて人に回すところまでにします。

指示内容を固定する

あなたは損害保険会社のお客さま相談室で、苦情等の記録を分類する担当者です。
記録に書かれていることだけを根拠にしてください。推測で埋めないでください。

【答えること】
1. 苦情等に当たる可能性（complaint / inquiry_only / unclear）
2. 苦情分類コード：大分類と中分類を1つずつ。次点の中分類も1つ
3. 原因区分：原因区分の一覧から1つ
4. 確認先の印：claim_payment / agency / serious のうち当てはまるもの（複数可）
5. 確信の度合い（high / medium / low）

【厳守事項】
- 顧客の不満・不服・怒り・困惑の表明が記録に少しでもあれば、
  complaint にしてください。「要望」「問い合わせ」と書かれていても、
  不満の表明があれば complaint です。
- inquiry_only は、不満の表明が記録のどこにも無いときだけ選んでください。
  迷ったときは unclear にしてください。
- 中分類は、コード表の「含めないもの」に当たらないかを確かめてから選んでください。
  当てはまるものが無ければ unmatched としてください。新しい区分を作らないでください。
- 原因区分は、対応の記録に調べた事実が書かれているときだけ選んでください。
  書かれていなければ undetermined にしてください。
  受付の記録だけから原因を推測しないでください。
- 「説明不足」は、何の説明が足りなかったかが記録に書かれているときだけ選んでください。
- 保険金の支払・支払の遅れ・支払額に関わる申出には claim_payment を付けてください。
- 代理店の対応・説明・手続に関わる申出には agency を付けてください。
- 申出の中に、通常の苦情と違う圧力の文言（金銭の要求、脅しなど）があれば
  serious を付け、その文を evidence に写してください。判定はしないでください。
- evidence には、判断の根拠にした文を記録からそのまま写してください。言い換えないでください。
- 伏せ字（[氏名] など）を元に戻そうとしないでください。

【記録】{record}
【経路】{channel}
【苦情分類コード表（有効な版）】{code_table}
【原因区分の一覧】{cause_list}
【判定例】{examples}

「要望と書かれていても、不満の表明があれば complaint」を明記しないと、記録の書き手の言葉に引きずられます。 代理店の報告には「ご要望」と書かれたものが多く、そのまま読めば inquiry_only が増えます。書き手がどう呼んだかではなく、顧客が何を言ったかで見るよう指示します。

「説明不足」の行を別に書いているのは、第7章「AIに何をさせるのか」の3行目の理由からです。 禁じないと、原因区分の半分近くが「説明不足」になります。

出力形式を固定する

次の形のJSONで受け取ります。 Azure OpenAI の構造化出力を使い、JSON Schema に沿った形で返させます。

{
  "record_id": "",
  "code_table_version": "",
  "complaint_status": "complaint | inquiry_only | unclear",
  "category": {
    "major": "",
    "minor": "",
    "minor_runner_up": "",
    "evidence": ""
  },
  "cause": {
    "code": "",
    "evidence": ""
  },
  "flags": ["claim_payment", "agency", "serious"],
  "flag_evidence": [""],
  "confidence": "high | medium | low",
  "note_for_reviewer": ""
}

1つ目の理由は、選べる値を enum で縛れることです。 構造化出力は enum に対応しているので、中分類42のコードを enum に並べれば、コード表に無い区分は返ってきません。 「その他」に逃げることも、新しい区分を作ることもできなくなります。unmatched と undetermined も enum に入れておきます。

2つ目は、すべての項目が必ず返ることです。 構造化出力ではすべての項目を必須にし、任意の項目は null との組み合わせの型で表します。原因区分が空のまま返ってくることが無くなり、undetermined という明示の値が返ります。 空欄と「未確定」を区別できるのは、月末の集計で効きます。

3つ目は、additionalProperties を false にするので、確認リストの列と1対1に対応させられることです。

月次の報告の下書きは、別の呼び出しで次の形を返させます。

{
  "month": "",
  "summary": "",
  "increased_categories": [
    { "minor": "", "count": 0, "prev_month": 0, "prev_year": 0,
      "explanation": "", "example_record_ids": [""] }
  ],
  "undetermined_cause_ratio_comment": "",
  "improvement_candidates": [
    { "cause": "", "related_department": "", "point": "", "record_ids": [""] }
  ],
  "numbers_used": [ { "label": "", "value": 0 } ]
}

numbers_used に、本文で使った数値をすべて書き出させます。 フローがこの値を集計と照らし、1つでも違えば下書きを差し戻します。構造化出力は文字列の長さや数値の範囲の指定には対応していないため、値が正しいかの確認はフローの側で行います。

システムへ連携する

苦情管理のシステムには書き込みません。 確定した区分を登録するのは担当者です。分類の誤りが顧客対応の記録に直接入る経路を作らないためです。

通知は印が付いたものだけにし、serious は即時、ほかは午前中にまとめて知らせます。

人が確認する

人が確定するのは全件ですが、読む深さを3段階に分けます。

1. unclear と inquiry_only を先に見る … 苦情等から外す候補です。ここだけは記録の全文を読み、外してよいかを決めます
2. 確信の度合いが low のものを見る … 中分類の候補と次点を見比べ、どちらかを選びます。判定例に足すべき記録なら印を付けます
3. high で complaint のものは一覧で流し見る … 中分類と根拠の文が合っていれば、まとめて確定します
4. 区分を覆したら理由を残す … どの区分からどの区分へ、なぜ変えたかを一言書きます

1番目を先にするのは、外した記録が分析と再発防止の対象から消えるからです。

月次の下書きは、担当者と課長の2人が見ます。 担当者は事例の選び方と説明が記録と合っているかを、課長は経営会議に出す言葉として適切かを見ます。数字の確認はフローが済ませているので、人は数字を検算しません。

目標は、600件をならして1件2分です。 1番目と2番目に回るのが全体の2割前後という想定で、それより多い月は、コード表の定義が足りていないか、判定例が古くなっています。

例外に対処する

上から2行目と3行目は、仕組みではなく記録とコード表の問題です。 直すほうが、指示を工夫するより効きます。

記録を残す

• 書き出しの元のファイルと、伏せる前と後の記録の対応（対応表はアクセスを絞った場所に置く）
• AIに渡した入力の全文（伏せた後のもの）と、返ってきたJSONの全文
• 分類したときのコード表の版と、渡した判定例の一覧
• 人が確定した区分と、AIの候補との違い。覆した場合の理由
• 月次の集計の値と、下書きの numbers_used、照合の結果
• 経営会議に出した最終版の報告と、下書きとの差分

3つ目を残すのは、区分の比較を後から説明するためです。 前年同月より件数が増えたとき、申出が増えたのか、コード表の版が変わったのか、判定例が変わったのかを切り分けられるようにします。

4つ目は毎月数えます。 覆す件数の多い中分類は、定義か判定例を直します。