保険会社が代理店の業務点検の記録と点検票から、指摘事項・改善の期限・前回からの変化を要約して、点検報告書の下書きにする

処理の起点を決める

点検の記録の状態が「記録済み」に変わったことを起点にします。 担当者は点検の当日か翌日に、点検票の入力と面談のメモの保存を済ませ、状態を変えます。状態を変えたのが、記録がそろったという担当者の宣言です。

ファイルの保存そのものを起点にはしません。点検票は当日の夜に一度保存され、翌日に所見を書き足されることがよくあります。保存のたびに動かすと、書きかけの点検票から下書きができ、担当者はどれが最新か分からなくなります。

状態の変更は、点検の予定表（点検ごとに1行、代理店コード・点検日・担当者・状態の列）で持ちます。Python のスクリプトを1時間ごとに動かし、「記録済み」で下書きがまだ無い行を拾います。 1件ずつ処理し、下書きができたら状態を「下書き済み」に変えます。状態を変えるのは成功したときだけにし、失敗した点検は「記録済み」のまま次の回に拾い直します。

月末に、「記録済み」のまま残っている点検を数えます。 それが処理の止まっているものです。

入力データを集める

質を決めるのは、前回の指摘です。 報告書の文章ではなく、指摘ごとに番号を振った台帳で持ちます。文章のままだと、AIは前回の報告書の言い回しから指摘を切り出すところから始めることになり、同じ指摘を2つに分けたり、2つを1つにまとめたりします。

指摘の台帳を作るのが、最初の手作業です。 過去1年分の報告書から指摘を拾って番号を振ります。点検は代理店ごとに周期が違うので、次の点検が来る代理店の分から順に作れば足ります。

自己点検の結果は、点検の観点と同じ項目番号で出してもらいます。 番号がそろっていれば、「代理店の自己点検では適、当社の点検では不備」という食い違いを項目ごとに拾えます。監督指針も、代理店の自己点検のみに依拠しないことを求めています。

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

点検票は表として読み、文章として読みません。 Python で項目番号・判定・所見の列を取り出し、項目番号をキーにした一覧にしてから渡します。表計算のファイルを丸ごとテキストにすると、結合したセルや空の行で列がずれ、所見がとなりの項目に付きます。

面談のメモは、そのまま渡します。 どの項目に関わる話かを分けるのは、AIの仕事にします。ただしメモの行に番号を振ってから渡し、要約の根拠として行番号を返させます。

前回の指摘は、改善の計画まで引きます。 代理店が「次回までに意向の確認の記録の様式を変える」と書いていれば、今回の点検で様式が変わったかが確かめどころになります。計画が無い指摘は、計画が出ていないこと自体を下書きに書きます。

AIへ渡す前に整形する

1. 項目番号の確認 … 点検票の全項目に判定が入っているかを確かめます。判定が空の項目は、要約の対象から外さず「判定なし」として渡します
2. 面談のメモの行番号 … メモを行に分け、M-01 のような番号を振ります
3. 不備の一覧の番号 … 抜き取りで見た書類ごとに D-01 のような番号を振ります
4. 個人情報の伏せ字 … 契約者・被保険者の氏名、証券番号、住所、電話番号を、［契約者A］ ［証券1］ のような記号に置き換えます。対応表は手元にだけ残します
5. 募集人の名前の扱い … 募集人の氏名は登録番号の下4桁と役割（管理者／募集人）に置き換えます
6. 前回の指摘の整形 … 指摘番号、内容、区分、期限、改善の計画を1件ずつの形にします
7. 分量の確認 … 面談のメモが長い点検は、項目の群（募集の手続き／顧客情報の管理／保険料の管理／教育と体制）ごとに分けて渡します

4番目と5番目は外せません。 点検の記録には、抜き取りで見た申込書類の契約者名がそのまま書かれています。報告書に必要なのは「どの書類に何の不備があったか」であって、契約者の名前ではありません。 伏せた記号のまま要約させ、報告書でも記号のまま残します。代理店は記号と自分の手元の一覧で書類を特定できます。

7番目は、要約の粒度をそろえるためでもあります。 群に分けて渡すと、群ごとの事実の数が見えます。1つの群だけ要約が極端に短い点検は、記録が足りていない点検です。

AIに処理させる

させるのは、記録に書かれた事実を点検の項目ごとに要約し、指摘の候補を挙げ、前回の指摘と突き合わせることです。

右端の列がいちばん大事です。 特に前回の指摘の not_checked は、「改善済み」と書かないための逃げ道です。 今回の点検でその点を見ていなければ、記録に何も書かれません。何も書かれていないことを「問題が見つからなかった」と読むと、見ていない指摘が改善済みとして閉じられます。

3行目が、いちばん起きやすい失敗です。 面談のメモに「様式は来月変える予定」とだけあると、AIは「担当者の異動で様式の変更が遅れている」のように、もっともらしい理由を足して書くことがあります。理由はメモに無く、代理店はそう言っていません。

指示内容を固定する

あなたは保険会社の業務品質部で、代理店の業務点検の報告書を下書きする担当です。
渡された点検の記録だけを根拠に書いてください。記録に無いことは書かないでください。

【入力】
- 点検票：項目番号ごとの判定（適／一部不備／不備／判定なし）と所見
- 面談のメモ：行番号（M-01 など）付き
- 不備の一覧：番号（D-01 など）付き
- 代理店の自己点検の結果：項目番号ごとの自己判定
- 前回の指摘：指摘番号、内容、区分、期限、代理店の改善の計画

【してほしいこと】
1. 点検票の項目ごとに、何を見て何があったかを1〜3文で要約する。
   要約の各文には、根拠にした項目番号・行番号・不備の番号を evidence に入れる。
2. 面談のメモの行を、関わる項目に振り分ける。どの項目にも当たらない行は
   unassigned に入れる。
3. 判定が「不備」「一部不備」の項目から、指摘の候補を挙げる。
   区分の候補は「重要」「通常」「軽微」から選び、決められなければ undetermined。
4. 自己点検の自己判定と、当社の判定が食い違う項目を挙げる。
5. 前回の指摘ごとに、今回の記録から改善状況を選ぶ。
   - improved ....... 改善されたことが記録から読み取れる
   - continuing ..... 同じ不備が今回も記録されている
   - worsened ....... 同じ不備の件数や範囲が前回より広がっている
   - not_checked .... 今回の記録に、その点を確かめた手がかりが無い
   手がかりが無いときに improved を選ばないでください。

【厳守事項】
- 代理店の説明は、面談のメモに書かれた範囲で書く。理由や事情を補わない。
- 契約者・被保険者は［契約者A］などの記号のまま書く。元の名前を推測しない。
- 募集人は記号のまま書き、個人の能力や態度の評価を書かない。
- 改善の期限の日付を書かない（期限は別の処理で付ける）。
- 指摘とするかどうかの結論を書かない。あくまで候補として挙げる。
- 委託契約の見直しなど、代理店への措置を提案しない。
- 判定が「判定なし」の項目は、要約に「判定なし」と書き、候補に挙げない。

【点検の記録】{inspection_records}
【前回の指摘】{previous_findings}

「手がかりが無いときに improved を選ばない」を明記しないと、前回の指摘の多くが改善済みになります。 点検の記録は、不備があったことは書きますが、問題が無かったことはあまり書きません。書かれていないことを良い知らせとして読む癖を、指示で止めます。

「期限の日付を書かない」と書くのは、書かせないと必ず書くからです。 報告書の形を見せると、AIは期限の欄を埋めようとして「1か月以内」「次回点検まで」のような期限を自分で作ります。期限は基準表の側で付けるので、AIの出力に日付の欄を作りません。

出力形式を固定する

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

{
  "agency_code": "",
  "inspection_date": "",
  "items": [
    { "item_no": "", "rating": "適 | 一部不備 | 不備 | 判定なし",
      "summary": "", "evidence": ["" ] }
  ],
  "unassigned_notes": [""],
  "finding_candidates": [
    { "item_no": "", "summary": "", "severity_candidate": "重要 | 通常 | 軽微 | undetermined",
      "evidence": [""] }
  ],
  "self_check_gaps": [
    { "item_no": "", "self_rating": "", "our_rating": "", "evidence": [""] }
  ],
  "previous_findings": [
    { "finding_no": "", "status": "improved | continuing | worsened | not_checked",
      "summary": "", "evidence": [""] }
  ]
}

スキーマでは rating、severity_candidate、status を enum にし、すべてのオブジェクトの additionalProperties を false にします。

1つ目の理由は、事実と候補を別の場所に置けることです。 items は記録の要約で、finding_candidates は指摘の候補です。報告書の「点検の結果」の段は items から、「指摘事項」の段は担当者が採った候補から作ります。 候補を採らなかったときも、事実の要約は残ります。

2つ目は、期限を後から付けられることです。 Python は担当者が確定させた区分で基準表を引き、点検日に日数を足して期限を出します。

日数は社内で決めるもので、ここに書いたのは例です。 基準表を変えれば、AIの出力には触れずに期限だけが変わります。

3つ目は、evidence で確認が速くなることです。 担当者は要約の文ごとに、点検票の項目番号やメモの行番号を見て元の記録を開けます。根拠の無い文は、Python の検査で「根拠なし」として下書きに印を付けます。

システムへ連携する

下書きは、報告書の様式のまま作ります。 「点検の概要」「点検の結果（項目ごと）」「指摘事項と改善を求める期限」「前回の指摘の改善状況」の4つの段で、担当者は見慣れた様式の上で直します。 指摘事項の段には、候補を区分の候補と根拠付きで並べ、採るものに印を付ける欄を設けます。

指摘の台帳へは、上長の承認の後にだけ書き込みます。 承認された報告書の指摘を番号付きで台帳に登録し、次回の点検の「前回の指摘」になります。

人が確認する

下書きは全件を担当者が読みます。 代理店に渡る文書で、指摘の判断を含むためです。

1. 前回の指摘の段を先に読む … not_checked が付いたものは、点検で確かめ忘れたか、記録に書き忘れたかです。記録に書き忘れたなら書き足し、確かめ忘れたなら代理店に問い合わせます
2. 指摘の候補を採るか決める … 候補ごとに根拠を開き、指摘とするか、区分は合っているかを決めます。区分を決めた時点で、期限が基準表から入ります
3. 代理店の説明の書きぶりを確かめる … 面談で聞いたことと違う書き方になっていないかを見ます
4. 自己点検との食い違いを見る … 食い違いが多い代理店は、自己点検のやり方そのものを指摘の候補にします
5. 上長が承認する … 担当者が直した下書きを上長が読み、承認して代理店へ送ります

1番目を先にするのは、ここが一番漏れていたからです。 第3章の（b）のとおり、前回の改善の確かめは急ぐと抜けます。下書きの段で not_checked が目立つように出ていれば、抜けたことが送る前に分かります。

判定を覆した記録を残します。 候補を採らなかった、区分を変えた、not_checked を improved に直した、の3つを、理由と一緒に残します。区分を変えた記録がたまると、区分の候補の付け方の癖が見えます。

例外に対処する

6行目と7行目を分けているのが要です。 前回の指摘が見つからないとき、初回なのか台帳が欠けているのかで対応が違います。台帳が欠けているのに「初回の点検」として下書きを作ると、前回の指摘の確かめが丸ごと抜けます。 代理店管理システムで前回の点検日を引き、日付があるのに台帳に指摘が無ければ、台帳の未整備として止めます。

根拠の無い文を消さないのにも理由があります。 消すと、担当者はその文があったことに気づきません。印を付けて残し、担当者が記録を見て採るか消すかを決めます。

記録を残す

• 点検ごとの入力（伏せ字にした後の記録と、前回の指摘の一覧）
• Claude API が返したJSONの全文と、呼び出した日時
• 下書きと、担当者が直した後の報告書、上長が承認した版
• 担当者が判定を覆した記録 … 候補を採らなかった、区分を変えた、改善状況を直した、の理由
• 指摘の台帳に登録した指摘の番号と、登録した日時
• 伏せ字の対応表（手元のみ。外部に出さない）

3つの版を残すのは、AIの下書きと送った報告書の差を後から見るためです。 差が大きい項目が、指示の直しどころです。