保険会社の代理店監査の記録とチェックリストから、代理店ごとの監査報告書と改善の指示の案を作り、監査担当が確かめてから返す

処理の起点を決める

監査担当が、記録の仕組みで「指摘の判定」を確定したことを起点にします。 監査の当日に回答を入れた時点ではなく、帰社して指摘とするかどうかと重さを入れ終わった時点です。指摘が決まる前に下書きを作ると、AIが不備のあった項目をすべて指摘として書いてしまいます。

記録の仕組みから確定の通知を受けられない場合は、1日に数回、確定済み・報告書未作成の監査を抽出する作り方にします。どちらの場合も、同じ監査で下書きを二度作らないよう、作成済みの印を記録の仕組みとは別の一覧に持たせます。

判定を確定し直したときは、下書きを作り直します。 上長の確認で指摘の重さが変わることがあるからです。作り直したときは、前の下書きとの差分を担当に示します。

入力データを集める

質を決めるのは、いちばん下の指示の文例です。 何も渡さなければ、AIは一般的な「改善してください」を書きます。項目ごとに、上長の確認を通った指示を2〜3例ずつ選んで渡すと、自社の求め方の水準がそろいます。 文例は業務品質部が選び、年に一度見直します。

面談の記録には、項目番号を付けて入れてもらいます。 番号の無いメモは、どの指摘の根拠なのかが分かりません。記録の入力画面で、メモを項目に結び付けて入れる形にしておくのが、最初の準備です。

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

期限はプログラムで決めます。 基準表に「重い指摘は1か月、中程度は2か月、軽い指摘は次回の監査まで」のような決まりがあれば、監査の日と重さから日付を計算し、AIには計算した日付を渡します。 AIに期限を書かせると、文中に基準表と違う日付が混ざります。

再発の判定もプログラムで行います。 前回の指摘と今回の指摘でチェックリストの項目番号が同じなら「再発」の印を付けて渡します。AIに前回と今回を比べさせると、文言が違うだけで別の不備と判断することがあります。

AIへ渡す前に整形する

1. 指摘の範囲の確定 … 「指摘とする」とされた項目だけを取り出します。不備があっても指摘としなかった項目は渡しません
2. 根拠の結び付け … 指摘ごとに、同じ項目番号の面談のメモと証跡の確認結果を集めます
3. 顧客情報の置き換え … 証跡の確認結果に入っている顧客名と証券番号を、「抽出契約A」のような記号に置き換えます。対応表は手元に残します
4. 期限の計算 … 基準表から、指摘の重さごとの期限の日付を計算します
5. 再発の印 … 前回と同じ項目番号の指摘に印を付け、前回の指示と改善報告を添えます
6. 文例の選択 … 指摘の項目番号ごとに、指示の文例を2〜3例選びます

3番目は、報告書の性質から欠かせません。 報告書は代理店の中で回覧されます。顧客名が入った報告書が回覧されると、その代理店の中でも見るべきでない人の目に触れます。 報告書には記号で書き、どの契約かは対応表で監査担当と代理店の管理者だけが確かめます。

5番目の「前回の改善報告」は、体制の是正を書くための材料です。 前回「研修を行いました」と報告されたのに同じ不備が出たなら、今回の体制の是正は研修以外の手当て（手順の見直し、点検の仕組み）にすべきだと分かります。

AIに処理させる

させるのは、決まった指摘ごとに改善の指示の案を作り、代理店向けの報告書の文面にすることです。

3行目の「代理店の規模に合わせる」が、この構成でいちばん効くところです。 募集人が3人の代理店に「点検の専任者を置く」と書いても動けません。募集人の数と乗合の有無を渡し、規模に見合った手当てを書かせます。

3行目がいちばん起きやすい失敗です。 体制の是正を書かせると、AIは「管理者による確認が行われていなかったため」のような原因を補って書きがちです。原因が記録に無ければ、原因の確認を代理店に求める指示にします。

指示内容を固定する

あなたは保険会社の代理店監査の担当として、監査を終えた代理店に渡す
監査報告書の、指摘ごとの改善の指示を書く立場です。
指摘とするかどうか、指摘の重さ、期限はすでに決まっています。
あなたの仕事は、決まった指摘を、代理店が読んで動ける指示にすることです。

【指摘ごとに書くもの】
1. fact ............ 指摘の事実。面談の記録と証跡の確認結果にあることだけ
2. individual_fix .. 見つかった不備そのものを直す行動
3. system_fix ...... 同じ不備が起きないための手当て（手順・研修・点検の仕組み）
4. evidence_to_submit 改善報告に付けてもらう提出物
5. recurrence_note . 再発の印がある場合、前回の改善報告を踏まえた書き方

【厳守事項】
- fact には、渡した記録にある事実だけを書いてください。
  記録に無い原因や事情を補わないでください。
  一文ごとに、根拠にした記録の source_ref（項目番号・記録の番号）を付けてください。
- 原因が記録から読み取れないときは、system_fix を
  「原因を確認し、改善報告に記載してください」とする指示にしてください。
- system_fix は【代理店の基本情報】の規模に見合ったものにしてください。
  募集人が少ない代理店に、専任者の配置のような手当てを求めないでください。
- evidence_to_submit は、提出物の名前と範囲を具体的に書いてください。
  「研修を行ったことが分かる資料」ではなく
  「研修の資料と出席者の記録」のように書いてください。
- 再発の印がある指摘では、前回の改善報告と同じ手当てを求めないでください。
- 期限は【期限】に書かれた日付をそのまま使い、変えないでください。
- 委託契約の見直しなど、代理店への措置に触れないでください。
- 法令に違反するかどうかを断定しないでください。
- 顧客は記号（抽出契約A など）のまま書き、名前に戻さないでください。
- 文例は書き方の参考です。文例の事実を今回の指摘に持ち込まないでください。

【代理店の基本情報】{agency_profile}
【指摘（項目番号・重さ・再発の印）】{findings}
【根拠の記録】{records}
【前回の指示と改善報告】{previous}
【期限】{deadlines}
【指示の文例】{examples}

「文例の事実を持ち込まない」を最後に置いているのは、文例を渡したときに起きる失敗だからです。 文例に「3か月分の控えを抽出」とあると、その代理店の取扱件数にかかわらず同じ範囲を求める指示が出ます。文例から借りるのは書き方で、中身は今回の記録から作らせます。

出力形式を固定する

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

{
  "audit_id": "",
  "agency_code": "",
  "findings": [
    {
      "item_no": "",
      "severity": "high | medium | low",
      "recurrence": true,
      "fact": [
        { "text": "", "source_ref": "" }
      ],
      "individual_fix": "",
      "system_fix": "",
      "evidence_to_submit": [""],
      "due_date": "",
      "recurrence_note": "",
      "status": "ready | needs_input"
    }
  ],
  "good_practices": [
    { "text": "", "source_ref": "" }
  ],
  "cover_message": ""
}

1つ目の理由は、照合ができることです。 fact の一文ごとの source_ref は、プログラムが記録の項目番号と照らします。実在しない番号を根拠にした文は、一覧で赤く示します。 due_date は基準表から計算した日付と照らし、違えば計算した日付で置き換えます。

2つ目は、改善報告の管理にそのまま入れられることです。 evidence_to_submit は配列で、提出物が1つずつ一覧の行になります。代理店から改善報告が届いたら、行ごとに「提出あり／なし」を付けるだけで、足りない提出物が分かります。

3つ目は、報告書の様式に流し込めることです。 様式の「指摘と改善の指示」の欄に、fact、individual_fix、system_fix、evidence_to_submit、due_date を決まった順で並べます。担当者ごとに報告書の見た目が違う、ということがなくなります。

構造化出力のスキーマでは、公式のページにあるとおり、すべての項目を必須にし、additionalProperties: false を設定します。 再発でない指摘でも recurrence_note は空の文字列で返させます。

報告書の「指摘と改善の指示」の欄は、たとえば次のように組み上がります。

【指摘 3】意向の把握と確認（重さ：中／前回からの再発）
 事実：抽出した契約10件のうち2件（抽出契約C・F）で、最終的な意向と当初の意向を
       比べた記録が残っていませんでした。
 個別の是正：2件について、顧客に意向を確認し直し、その記録を残してください。
 体制の是正：前回は研修で対応されましたが、同じ不備が見られました。申込みの前に
       比べた記録の有無を管理者が確かめる手順を、手順書に加えてください。
 提出物：改めた手順書／手順を加えた後に申込みを受けた契約から5件分の記録の写し
 期限：2026年12月8日

システムへ連携する

監査の記録の仕組みには書き込みません。 指摘の判定は担当者の記録で、AIの下書きが判定を上書きする経路を作りません。

報告書を代理店へ送るのは人です。 代理店の代表者に渡す文書で、送り方（手渡し、代理店向けの連絡の仕組み、メール）は代理店ごとの取り決めに従います。

改善報告の管理の一覧への追加は、上長の確認が済んでからにします。 確認で指示が変わったときに、古い提出物が一覧に残るのを避けるためです。

人が確認する

監査担当が下書きを読み、直してから上長に回します。 見るのは次の順です。

1. needs_input を先に埋める … 根拠の記録や提出物の例が足りなかった指摘です。記録に足すか、指示を自分で書きます
2. fact を記録と照らす … 一覧で赤く示された文から見ます。代理店が言っていないことが書かれていないかを確かめます
3. system_fix の現実味を見る … 代理店の規模と体制で、本当に実行できるかを考えます
4. evidence_to_submit の範囲を見る … 求める提出物が、代理店の取扱件数に対して重すぎないかを確かめます
5. 報告書の全体を通して読む … 良かった点と指摘の釣り合い、言い回しの強さを整えます

上長の確認は、指摘の重さと指示の強さが釣り合っているかを見ます。 重い指摘に「今後注意してください」程度の指示が付いていないか、軽い指摘に重い提出物を求めていないかです。

目標は、100件をならして1件45分です。 指摘の少ない代理店は20分ほど、再発の指摘が並ぶ代理店は1時間を超えることもあります。

例外に対処する

上から3行目までが大半を占めます。 どれもAIの問題ではなく、監査の記録の付け方の問題です。 記録の入力画面で、項目番号と結び付けないとメモを保存できないようにするだけで、多くが消えます。

7行目は、止めることが正解です。 顧客名の入った報告書が代理店の中で回覧されれば、監査で顧客情報の管理を指摘している側が、同じ不備を起こすことになります。

記録を残す

• 監査の記録の版（指摘の判定が確定した時点のもの）と、使った基準表・文例の版
• 顧客名と記号の対応表（監査担当だけが読める場所）
• AIへの入力と出力のJSONの全文
• 監査担当と上長が直した差分 … どの指摘の、どの欄を、どう直したか
• 代理店へ渡した報告書の確定版と、渡した日
• 指摘ごとの提出物と、改善報告で届いた提出物の対応

4つ目の差分は、文例を見直す材料になります。 上長がいつも同じ欄を直しているなら、その項目の文例が自社の求め方に合っていません。直された指示を次の文例に入れ替えていけば、下書きが上長の水準に近づきます。

最後の行は、次の監査の準備になります。 提出物が出ていない指示が残っている代理店は、次の監査でその項目から確かめます。