信用金庫の営業店から本部に届く事務ミスの報告を、ミスの種類・原因・影響の大きさで分類し、月次の事務指導の資料に使える一覧にする

処理の起点を決める

毎日18時の定時の実行を起点にします。 営業店の報告は、窓口を閉めた後の夕方にまとまって届きます。18時に1日分をまとめて分類しておけば、事務指導の担当は翌朝、一覧を開いた時点で前日の報告をすべて見られます。

取引時確認に関わるものと重大のおそれの印が付いたものは、18時の実行の直後に事務部長とコンプライアンスの担当へ通知の一覧を送ります。 翌朝まで待たせないのは、顧客への連絡や事実の確認を早く始める必要がある報告だからです。

月次の集計は、毎月の第1営業日の朝に動かします。 前月分の分類がすべて「確定」になっているかを確かめ、未確定が残っていれば、その件数を担当に知らせて集計を止めます。未確定のまま集計すると、AI の分類のままの件数が資料に載ります。

入力データを集める

質を決めるのは、区分表の「境目の例」です。 区分の名前と短い定義だけでは、振込の誤りを「振込・送金」に入れるか「端末の操作」に入れるかが決まりません。「振込先の口座番号を打ち間違えた → 種類は振込・送金、原因は端末の操作」のように、迷いやすい組み合わせを例で書いておくと、AI の分類も担当者の分類もそろいます。

最後の行のように、原因は種類と別に決まります。 種類は何の事務か、原因はなぜ起きたかで、同じ「手引を知らなかった」が、預金でも融資でも起きます。

過去の分類は AI に渡しません。 再発の照合は Python が店名と種類で数えます。AI に同じ店の過去の報告を見せると、過去の分類に引きずられて、今回の報告の経緯を読まずに同じ区分を返すことがあります。 今回の報告の分類と、過去との照合を分けておくと、どちらが誤ったかを後から切り分けられます。

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

Python が受付フォルダの報告のファイルを開き、様式の決まった欄を読みます。

AI に渡すのは、文章の欄だけです。 店名や日付は分類に要らないので渡しません。渡す情報が少ないほど、伏せ字の漏れが起きる場所も減ります。

営業店が選んだ取引の種類は、AI には渡さず、後で突き合わせます。 営業店の選択を見せると、AI はそれに合わせて分類しがちです。別々に出して食い違えば、どちらかを人が確かめるほうが、分類の揺れを見つけられます。

AIへ渡す前に整形する

1. 様式の確認 … 行内の様式の版と欄の並びを確かめます。古い版や欄の欠けた報告は処理から外し、担当に戻します
2. 欄の取り出し … 経緯・原因・顧客への対応・再発防止策の4つの欄の文を取り出します
3. 伏せ字 … 顧客の氏名、口座番号、電話番号、住所、生年月日を、決まった形の文字列（〔顧客〕〔口座番号〕など）に置き換えます
4. 伏せ字の検査 … 置き換えた後の文に、数字の連なりや「様」「殿」の前の語が残っていないかを規則で調べ、残っていれば処理を止めて担当に戻します
5. 職員名の置き換え … 報告に書かれた職員の氏名を〔担当者A〕〔担当者B〕に置き換えます
6. 重複の検知 … 同じ店・同じ発生日・同じ経緯の報告が二重に届いていないかを確かめます

3番目と4番目を軽く見ないでください。 経緯の欄には、顧客の氏名や口座番号がそのまま書かれていることがあります。伏せ字の規則を通った後にもう一度調べ、少しでも残っていれば送らない、という二重の仕組みにします。

5番目は、分類を人の評価に結びつけないためです。 職員の氏名が分類の結果に残ると、集計表が誰がミスをしたかの一覧として読まれます。事務指導の資料は、手順と仕組みを直すための材料です。

AIに処理させる

させるのは、報告ごとに種類・原因・影響を区分表から1つずつ選び、それぞれに報告の原文の一文を根拠として写し、決まった印を付けることだけです。

原因の行が、この構成でいちばん手間のかかる部分です。 原因の欄に「確認不足」とあっても、経緯の欄に「二人目の検印を待たずに処理した」と書かれていれば、原因は「確認の手順の省略」です。 原因の欄ではなく経緯の文から判断させ、その文を根拠として写させます。経緯からも分からないときは、営業店に聞くための印を付けます。

1行目がいちばん大事です。 escalation_check は「人が報告の全体を読むべき」という印で、不祥事件に当たるという判断ではありません。 出力の項目にも判断の言葉を置かず、印と根拠の一文だけを返させます。

指示内容を固定する

あなたは信用金庫の本部の事務部で、営業店から届いた事務ミスの報告を
行内の区分表に沿って分類する補助をします。
報告に書かれていることだけを根拠にしてください。推測で補わないでください。

【区分表】{category_table}（種類・原因・影響の区分、定義、境目の例）
【報告】
  経緯：{course}
  原因：{cause}
  顧客への対応：{customer_action}
  再発防止策：{prevention}

【返すこと】
- type：区分表の種類から1つ。type_quote に根拠にした報告の一文をそのまま
- cause：区分表の原因から1つ。cause_quote に根拠にした報告の一文をそのまま
  原因の欄だけでなく、経緯の文から判断してください
- impact：customer_impact（yes／no／unknown）、amount_stated（true／false）、
  explained_to_customer（yes／no／unknown）
- flags：当てはまるものだけ
  kyc_related（取引時確認・本人確認・確認記録に関わる）
  escalation_check（顧客の情報の外部への流出、現金の行方不明、意図的な操作をうかがわせる記載）
  shallow_cause（原因が「確認不足」「不注意」などだけで、何を確認しなかったかが経緯にも無い）
- flag_quotes：印ごとに根拠にした報告の一文
- case_summary：指導の事例に使うための、何の事務で何が起きたかの要約（60字以内）

【厳守事項】
- type と cause は、区分表にある区分だけから選んでください。
- quote には報告の原文をそのまま写してください。言い換えないでください。
- 不祥事件に当たるか、外部への報告が要るかを書かないでください。
- 職員の責任、処分、評価に触れないでください。
- 金額や顧客への影響が書かれていないときは、unknown や false にしてください。推測しないでください。
- 〔顧客〕〔口座番号〕〔担当者A〕などの伏せ字を、元に戻そうとしないでください。
- case_summary に伏せ字の中身や、店を特定できる記載を書かないでください。

「原因の欄だけでなく、経緯の文から判断する」を明記しないと、原因の欄の言葉どおりに分類します。 原因の欄が「確認不足」なら、AI はそのまま「確認の手順の省略」を選び、根拠に原因の欄の「確認不足」を写します。 それでは担当者の分類と同じ深さにしかなりません。

「不祥事件に当たるかを書かない」を独立した行にしているのは、AI が書き添えがちだからです。 現金の行方が分からない報告を渡すと、「不祥事件に該当する可能性があります」と書き添えることがあります。その一文が一覧に残ると、判断が済んだもののように読まれます。

出力形式を固定する

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

{
  "report_id": "",
  "type": "cash | deposit | transfer | bill_check | loan_doc | kyc | notification | passbook_seal | customer_info | public_fund | other",
  "type_quote": "",
  "cause": "skipped_check | misunderstanding | unclear_rule | operation | workload | handover | customer_error | unclear",
  "cause_quote": "",
  "impact": { "customer_impact": "yes | no | unknown", "amount_stated": false,
              "explained_to_customer": "yes | no | unknown" },
  "flags": ["kyc_related | escalation_check | shallow_cause"],
  "flag_quotes": [ { "flag": "", "quote": "" } ],
  "case_summary": ""
}

スキーマでは type・cause・customer_impact・explained_to_customer・flags の要素を enum にし、type・type_quote・cause・cause_quote を required にします。

1つ目の理由は、印と通知を規則で決められることです。 Python は次の規則で、報告ごとの扱いを決めます。AI の出力が揺れても、誰に知らせるかの決め方は表のとおりです。

1行目と2行目が要です。 取引時確認に関わるミスと重大のおそれのある報告を、件数の集計とは別の流れで、その日のうちに人の目に届けます。

2つ目は、根拠の一文で確認が速くなることです。 一覧には type_quote と cause_quote が並ぶので、担当は報告を開く前に、どの文で分類されたかを読めます。根拠の一文がずれていれば、分類も疑えます。

3つ目は、月次の集計にそのまま使えることです。 確定した type・cause・impact を数えれば、種類×原因の表と店ごとの件数が出ます。case_summary は、指導の資料の事例の候補として並べます。

システムへ連携する

集計表に書き写すのは、担当が確定の印を入れた行だけです。 AI の分類のまま集計表に入れると、確かめていない分類が月次の資料の件数になります。集計表は事務部の判断の記録なので、判断した人の後に書きます。

人が確認する

事務指導の担当が見るのは、一覧の全行の分類と根拠の一文と、印の付いた報告の原本です。

1. 通知の一覧に載った報告を先に見る … 原本を読み、事務部長・コンプライアンスの担当と、事実の確認の段取りを決めます
2. 「種類の確認」「原文の確認」の行を開く … 原本で経緯を読み、分類を直します
3. 「営業店に聞き取り」の行をまとめる … 店ごとにまとめて、何を確認しなかったのかを聞きます。聞き取った内容で原因を直します
4. 印の無い行を流し見て確定の印を入れる … 根拠の一文と分類が合っていれば確定します
5. 分類を直した記録を残す … どの区分を、どの区分に直したかを残します

5番目を省かないでください。 同じ境目で直しが続くなら、区分表の「境目の例」が足りていません。直しの記録が、区分表を育てる材料になります。

目標は、420件をならして1件2分です。 印の無い報告は数十秒で確定でき、通知の一覧に載った報告は原本を読むので10分以上かかります。印の付く報告が全体の2割を大きく超える月は、区分表の境目の例が足りないか、営業店の書き方が変わっています。

例外に対処する

最後の行で、API が止まっても取引時確認に関わる報告が埋もれないようにします。 分類の自動化が止まっても、知らせるべき報告を知らせる流れは止めません。

記録を残す

• 元の報告のファイルと、伏せ字にした後に送った文
• Gemini API から返ってきたJSONの全文
• 規則で付けた印と、通知の一覧に載せた日時・宛先
• 担当が確定した分類と、AI の分類から直した記録
• 営業店への聞き取りの内容と、それで直した原因
• 伏せ字の検査で止めた件数と理由

6つ目の記録は、伏せ字の規則を直す材料になります。 止めた件の多くが同じ書き方（口座番号の区切り方など）なら、規則の側に足します。