保険代理店で募集人が自作する比較資料・チラシ・SNS投稿の原稿を、使う前に募集文書の社内ルールに照らして点検する

処理の起点を決める

SharePoint の「募集文書点検」ライブラリにファイルが作成されたことを起点にします。 Power Automate の SharePoint コネクタには「When a file is created (properties only)」というトリガーがあり、ライブラリの列の値だけを返します。中身は「Get file content」のアクションで、返ってきたファイル識別子を使って取り出します。

定時のまとめ処理にはしません。 募集人は使いたい日が決まっており、置いてから数分で指摘が返れば、担当者の確認を待つ前に自分で直せます。

フォルダ単位のトリガーは非推奨と表示されているため使いません。ライブラリの列に「点検状態」を持たせ、終わったら 点検済み、失敗したら 要再実行 に書き換えます。

入力データを集める

質を決めるのは、社内ルールの書き方です。 「誤解を招く比較をしない」とだけ書いた条文では、AIも担当者と同じく経験で読むしかありません。監督指針が比較表示で挙げている型を、条文の側で具体的に分けて書きます。

監督指針（II-4-2-2(9)）は、比較表示で不適切な例として、客観的事実に基づかない事項や数値を表示すること、正確な判断に必要な事項を包括的に示さず一部のみを表示すること、長所のみをことさらに強調し不離一体の関係にあるものを併せて示さないこと、同等と認識されない保険種類間の比較を同等であるかのように表示すること、現に提供されていない保険契約と比較すること、他社の商品を誹謗・中傷する目的で短所を不当に強調することを挙げています。社内ルールでは、これを1つずつ別の条文にします。

比較表には、比較の対象とした商品の契約概要を顧客が速やかに入手できるようにすることと、比較表に商品の内容のすべてが記載されていない旨の注意喚起が求められています。 保険料を比べる場合は、保険料のみに注目させない工夫と、保障内容など他の要素も考慮すべき旨の注意喚起です。これらは「必ず書く事項」として条文にします。

差し戻し事例は、直し方の案をその代理店の言い回しに寄せるために渡します。

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

社内ルールは全部を渡しません。 SNS投稿の原稿に比較表の条文を当てると、比較していない投稿に「比較の注意喚起が無い」という指摘が出ます。原稿の種類で条文を絞ってから渡します。

台帳はAIに渡しません。 番号の照合は Python が行い、AIには原稿から拾った番号の文字列だけを返させます。台帳には全店舗の資料の一覧と使用期限がまとまっており、照合に必要のないものを外へ出さないためです。根拠資料も、該当するページだけを切り出して置いてもらいます。

AIへ渡す前に整形する

1. PDFであることの確認 … WordやPowerPointのまま置かれたものは、PDFにして置き直してもらいます
2. 文字の取り出し … PythonのPDFライブラリでページごとに文字を取り出します。文字が取れないページ（画像だけのチラシ）は印を付けます
3. ページの画像化 … チラシとSNS投稿は、ページを画像にしてAIに渡します。文字の大きさ、注記の位置、写真に重ねた文字は、取り出した文字だけでは分かりません
4. 画像の枚数の確認 … 1回の要求で送れる画像は10枚までです。それを超える比較表の冊子は、10ページずつに分けて送ります
5. 条文の選択 … 原稿の種類と保険会社から、当てる条文を選びます
6. 根拠資料の文字の取り出し … 数値の照合に使うので、全角・半角、桁区切り、「円」「％」の表記をそろえます
7. 改訂の確認 … 改訂の原稿なら、台帳から旧版の登録番号と使用期限を引いておきます

3番目を省かないでください。 注意喚起が写真の上に小さく白抜きで重ねられていると、取り出した文字では「書かれている」ことになりますが、顧客の目には届きません。 監督指針は、契約概要や注意喚起情報の書面について文字の大きさを8ポイント以上とすることなどを「適切な表示の確保」として挙げています。この代理店では、チラシの注記にもこの考え方を当てています。

画像の解像度は、detail を high にします。low では512×512の低い解像度で処理されるため、小さな注記が読めません。 high では低解像度の画像を見たうえで、512×512の区画ごとに詳しく読むとされています。

AIに処理させる

させるのは、条文ごとに「外れている箇所があるか」「必須事項が書かれているか」を答え、根拠にした原文をそのまま引くことです。

右端の列が、この構成でいちばん大事な区別です。 unclear は担当者に回すもの、external は別紙を確かめるもの、not_applicable は条文が当たらないものです。「判断できない」を「問題なし」に混ぜると、点検したことになって通ってしまいます。

最後の行が、いちばん起きやすい失敗です。 注記の不足を指摘させると、AIはそれらしい注記を自分で作ります。保険会社の資料と違う言い回しの注記は、それ自体が審査で差し戻されます。

指示内容を固定する

あなたは保険代理店の本部で、募集人が作った募集用の原稿を、使う前に点検する担当者の補助です。
渡された原稿と社内ルールの条文だけを見て答えてください。条文に無い基準を持ち込まないでください。

【原稿の種類】{doc_type}（comparison / flyer / sns）
【扱う保険会社】{insurers}
【当てる条文】{rules}
  各条文は rule_id、本文、type（prohibited＝書いてはいけない／required＝必ず書く）を持ちます。

【答え方】
- type が prohibited の条文：原稿の中に外れている箇所があれば、1箇所ずつ挙げてください。
  quote には原稿の文字をそのまま写し、page と位置（見出し、表の行、注記など）を書いてください。
- type が required の条文：その事項が原稿に書かれているかを、必ず1つずつ答えてください。
  書かれていれば status を present とし、根拠の文字を quote に写してください。
  書かれていなければ status を absent とし、quote は空にしてください。
  「別紙参照」などで原稿の外にあると書かれていれば external です。
- 判断できないときは unclear を選び、理由を書いてください。迷ったときに present や問題なしを選ばないでください。
- 条文がこの原稿に当たらないときは not_applicable です。

【厳守事項】
- 使ってよいか、保険業法に違反するかを書かないでください。
- 指摘の重さ（must_fix など）を書かないでください。
- 登録番号は読み取った文字列をそのまま extracted に入れてください。桁を補ったり、
  それらしい番号に直したりしないでください。台帳との照合はしないでください。
- 保険料・返戻率・配当などの数値は、原稿に書かれたとおりに単位ごと拾ってください。
  計算や換算をしないでください。正しいかどうかも判断しないでください。
- 直し方の案（suggestion）では、不利益事項や注意喚起の文言を自分で作文しないでください。
  「根拠資料の◯ページの記載を、この位置に入れる」のように、どこに何を足すかを書いてください。
  根拠資料に該当する文言が見つからなければ「保険会社の資料で文言を確認」と書いてください。
- 表現の言い換えを提案するときは、差し戻し事例の言い回しを参考にしてください。
- 画像では、文字の大きさ、写真に重なった文字、注記の位置も見てください。
  文字として読めても、背景に埋もれて読みにくい場合は、その旨を書いてください。

【差し戻し事例】{past_cases}
【根拠資料の文字】{reference_text}
【原稿の文字】{draft_text}
（原稿のページ画像を添付します）

「必ず1つずつ答えてください」を required の条文に書いているのが要です。 書かないと、AIは問題のある箇所だけを答え、書かれていない事項について何も言いません。 何も言わないことは「書かれている」と同じに見えます。

「自分で作文しない」も同じ理由です。 補った文章を募集人がそのまま貼ると、保険会社の資料と食い違う注記が出回ります。

出力形式を固定する

structured outputs の strict: true で、次の形のJSONに固定します。 公式のドキュメントでは、structured outputs は与えたJSONスキーマに従わせる機能で、有効なJSONを保証するだけで厳密にスキーマに沿うとは限らない旧来の JSON モードとは異なるとされています。

{
  "doc_id": "",
  "doc_type": "comparison | flyer | sns",
  "findings": [
    {
      "rule_id": "",
      "rule_type": "prohibited | required",
      "status": "violation | present | absent | external | unclear | not_applicable",
      "page": 0,
      "location": "",
      "quote": "",
      "reason": "",
      "suggestion": ""
    }
  ],
  "extracted": {
    "registration_numbers": [""],
    "insurers": [""],
    "products": [""],
    "figures": [ { "label": "", "value": "", "unit": "", "page": 0 } ]
  }
}

1つ目の理由は、区分を後から付けられることです。 AIが返すのは status までで、must_fix ／ should_fix ／ ask は Python が条文の区分から付けます。ルールを改めたときは、条文の区分を書き換えるだけで済みます。

2つ目は、答えの抜けを数えられることです。 Python が渡した条文の rule_id がすべて返っているかを確かめ、足りなければ再実行します。

スキーマには制約があります。 すべての項目を required に入れ、オブジェクトには additionalProperties: false を付ける必要があります。項目は合計100個まで、入れ子は5段までです。文字列の maxLength や pattern、配列の minItems は使えないとされているため、条文が全部返っているかは、スキーマではなく Python の側で数えます。

Python は一覧に、区分と、登録番号の照合（matched ／ expired ／ old_version ／ not_found）、数値の照合（found ／ not_found）の列を足します。

システムへ連携する

募集人へは自動で差し戻しません。 一覧をそのまま見せると、担当者が捨てるはずの指摘まで直そうとします。 保険会社の審査の窓口にもつなぎません。

人が確認する

担当者は、指摘一覧と原稿を並べて読みます。 一覧は must_fix → ask → should_fix の順に並べます。

1. must_fix を確かめる … 引用された箇所を原稿で見て、本当に条文に外れているかを確かめます
2. ask と unclear を判断する … AIが判断できなかったものです。ここが担当者の仕事の中心です
3. absent を原稿全体で探す … 書かれていないと出た事項が、別のページや裏面に無いかを確かめます
4. 指摘の無い箇所に目を通す … 原稿を一通り読みます。AIが拾わなかった表現が無いかを見ます
5. 採否を記録する … 指摘ごとに「採る／捨てる」を付け、捨てた理由を一言残します
6. 差し戻す … 採った指摘と直し方の案を手直しして、募集人へ返します

4番目を省かないでください。 条文に無い言い回しは、AIも拾いません。拾った型は条文か事例に足します。

例外に対処する

登録番号の not_found を一律に差し戻さないでください。 改訂か新規かの列で扱いを分けます。

記録を残す

• 原稿と根拠資料のPDF、置いた日時と募集人、種類と保険会社
• そのとき当てた条文の版と、差し戻し事例の件数
• Azure OpenAI が返したJSONの全文と、使ったモデルのデプロイ名
• 照合の結果（登録番号、数値）
• 担当者の採否と、捨てた理由
• 差し戻した日時、直った原稿、保険会社の審査に出した日と結果

2つ目で条文の版を残すのは、ルールが後から変わるためです。 条文を改めた後に過去の点検を見直すとき、当時どの条文で見たかが分からないと、通した理由が説明できません。

5つ目は、条文を見直す材料になります。 同じ条文の指摘を何度も捨てているなら、条文の書き方が実態に合っていません。