保険会社で約款・特約を改定したときに、パンフレット・重要事項説明書・ご契約のしおりの記載が改定後の約款と食い違っていないかを校正する

処理の起点を決める

商品部が、審査の受付フォルダに1件の改定の資料一式を登録したときに動きます。 一式は、改定後の約款、新旧対照表、影響する文書の原稿です。一式がそろったことを示すため、受付票のファイルを最後に置いた時点で動かします。 原稿が1本ずつ届くたびに動かすと、文書の間の食い違いを見る前に指摘が出てしまいます。

直した原稿が届いたときも、同じ受付で動かします。 2回目は、前の回の指摘のうち採ったものが直っているかと、直したことで別の場所に新しい食い違いが出ていないかを見ます。前の回の指摘の一覧を一緒に渡します。

改定と関係なく、年に一度、全商品の文書を約款と照らす棚卸しにも使えます。 ただしこれは月々の審査とは別の扱いにし、工数の試算にも入れていません。

入力データを集める

質を決めるのは、新旧対照表と諸元表です。 新旧対照表に変わった条文が漏れていれば、その変更点からは文書を見に行きません。諸元表の数字が約款と合っていなければ、数字の見比べが間違った正解で行われます。 どちらも商品部が作るものなので、審査を依頼する前に商品部の中で確かめる手順を決めます。

審査の観点の一覧は、いまの審査担当の経験を文字にしたものです。 例えば「給付の金額を表に書くときは、減額の条件と不担保の期間を同じ表の中に書く」のような取り決めです。監督指針が例に挙げる制限条件（契約後一定の不担保期間、年齢・入院日数・対象疾病等による減額や消滅、先進医療の対象外となる場合）を、まず一覧の最初に入れます。

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

受付フォルダから中継の処理（Azure Functions）がファイルを受け取り、約款は Word から条文の単位で、原稿は PDF から文字と位置を取り出します。

原稿の文字は、制作会社から受け取った PDF から取り出します。 文字が画像になっていて取り出せないページは、制作会社に文字を含む PDF を出し直してもらいます。 画像から読み取る仕組みを足すより、元データを受け取るほうが確実で、読み取りの誤りが指摘の誤りになることもありません。

記載の単位には、ページと位置を付けます。 「パンフレット p.6 表2 3行目の注記」のように、審査担当が原稿の該当の場所をすぐ開けるようにするためです。 表は行と列の位置まで持たせます。

AIへ渡す前に整形する

1. 変更点の一覧化 … 新旧対照表の1行を1つの変更点にし、変わった語句、条文番号、変更の種類（給付の条件、支払わない場合、保険期間、告知、手続き、用語の整備）を付けます
2. 約款の分割 … 条・項・号の単位に分け、条文番号を付けます。別表は表のまま持ちます
3. 原稿の分割 … 見出し・本文・注記・表のセルに分け、ページと位置を付けます
4. 候補の拾い出し … 変更点ごとに、変わった語句・その言い換え（「入院給付金」と「入院一時金」など、用語の対応表から）・条文番号を含む記載を、全文書から拾います
5. 数字の抽出 … 原稿の中の金額・日数・年齢・回数・期間を、単位と一緒に取り出します
6. 用語の対応表の適用 … 約款の用語と募集文書のやさしい言い換えの対応（「責任開始期」と「保障の始まる日」など）を、商品部の用語の表から引きます

4番目を軽く見ないでください。 変わった語句そのものだけで拾うと、パンフレットで言い換えた記載が候補から漏れます。 約款では「疾病入院給付金」、パンフレットでは「病気で入院したとき」と書かれているのが普通で、言い換えの対応表が、拾い出しの網の目の細かさを決めます。

表は、セルを単独で渡しません。 表のセルの「10日」だけでは何の日数か分からないので、行の見出しと列の見出しを添えて「入院給付金／支払限度の日数：10日」のような形にして渡します。 パンフレットの給付の説明の多くは表で書かれているため、この添え方で拾い出しと判定の精度が変わります。

候補は広めに拾い、絞るのはAIに任せます。 関係の無い記載が候補に入っても、AIが「関係なし」と返せば済みますが、候補から漏れた記載は誰にも見られません。 拾った候補と、AIが関係ありとした記載は、どちらも一覧に残します。

AIに処理させる

3行目がいちばん起きやすい失敗です。 「疾病の定義」のような条文で、パンフレットの記載が約款より広く読めるか狭く読めるかを、AIは自信を持って判定してしまいます。解釈が分かれうる条文は、unclear とさせて審査担当に回します。 解釈は、商品部・支払管理部門・コンプライアンス担当部門で決めることです。監督指針も、商品の開発・改定にあたって約款解釈を関連部門で十分に検討し、その結果がパンフレット等に適切に反映されているかに触れています。

missing_condition の「近く」は、プログラムが決めて渡します。 給付の金額を書いた記載と同じ表、同じページ、同じ見出しの下にある記載を「周辺の記載」としてまとめて渡し、その中に制限の条件が書かれているかを見させます。 AIに「近いかどうか」を判断させると、10ページ先の注記を見つけて「書かれている」と返すことがあるからです。監督指針も、条件が保障内容を強調した表示から離れたところに表示されている場合などに見落とされるおそれがあるとしています。

not_related を返させるのは、見た記載の一覧を残すためです。 関係なしと判定した記載も、変更点ごとに「見た」ことが分かります。審査担当は、関係なしとされた記載を流し見て、見落としが無いかを確かめられます。

指示内容を固定する

あなたは保険会社のコンプライアンス担当部門で、募集文書の記載が
改定後の約款と合っているかを確かめる担当です。
渡された変更点・改定後の条文・記載の候補だけを根拠にしてください。

【確かめること】
変更点ごとに、記載の候補を1つずつ見て、次のどれかに分けてください。
- conflict：記載の内容が改定後の条文と違う
- outdated：記載が改定前の文言のとおりになっている
- missing_condition：条文にある制限の条件（不担保の期間、減額、対象外となる場合など）が、
  その給付を書いた記載に併記されていない
- term_mismatch：用語の対応表と違う言い換えになっている
- unclear：条文の解釈が要る、または記載が抽象的で照らせない
- not_related：この変更点とは関係が無い

【厳守事項】
- doc_quote には記載の候補の文を、clause_quote には改定後の条文の文を、
  一字一句そのまま写してください。要約・言い換えをしないでください。
- 条文の解釈が分かれうるときは、判定せず unclear にしてください。
- 直した文言を書かないでください。表示が適正かどうかの結論を書かないでください。
- 金額・日数・年齢などの数字を見比べないでください。数字は別の仕組みで確かめます。
- reason には、何がどう違うかを1〜2文で書いてください。

【変更点】{change}
【改定後の条文】{clauses}
【改定前の文言（新旧対照表）】{old_text}
【用語の対応表】{terms}
【審査の観点の一覧】{checklist}
【記載の候補（文書・ページ・位置付き）】{candidates}

「一字一句そのまま写してください」を書かないと、引用を要約してきます。 要約された引用は照合で原文に当たらず、正しい指摘まで落ちることになります。 逆に、指示どおりに写していれば、照合で当たらない引用は作られた引用だと分かります。

「数字を見比べないでください」を書くのは、二重の判定を避けるためです。 AIにも数字を見させると、諸元表との見比べと違う結果を返すことがあり、どちらを信じるかで審査担当が迷います。 数字は1つの仕組みにだけ任せます。

出力形式を固定する

変更点ごとに、次の形のJSONで受け取ります。

{
  "change_id": "C-03",
  "findings": [
    { "doc": "pamphlet | overview | caution | guidebook",
      "location": "p.6 表2 3行目 注記",
      "doc_quote": "",
      "clause_ref": "第12条第2項",
      "clause_quote": "",
      "type": "conflict | outdated | missing_condition | term_mismatch | unclear | not_related",
      "reason": "" }
  ]
}

1つ目の理由は、type を列挙型で縛れることです。 指摘の種類が決まっていれば、conflict と outdated を先に、unclear を次に、not_related を最後に、という並べ方を機械でできます。審査担当は上から読めば済みます。

2つ目は、doc_quote と clause_quote を必須にできることです。 Microsoft Learn では、構造化出力ではすべてのフィールドを必須にする必要があり、オブジェクトには常に additionalProperties: false を設定するとされています。引用の無い指摘は形として返ってこないので、照合の対象から漏れません。

3つ目は、スキーマで縛れない検査を先に決めておけることです。 文字列の pattern などはサポートされていないため、条文番号の書き方や引用の中身は、中継の処理で確かめます。

最後の行が大事です。 返ってこなかった候補は、AIが見落としたか、出力の途中で切れたものです。その候補だけを、もう一度渡して判定させます。

数字の見比べの結果は、同じ一覧に別の種類として足します。 原稿の数字が諸元表と合わなければ number_mismatch として、ページと位置、原稿の数字、諸元表の数字を並べます。 これはAIの出力ではなく、プログラムの出力です。

システムへ連携する

審査の台帳には、指摘の下書きとして書き出します。 採否の欄は空のまま渡し、審査担当が採ったものだけが商品部への指摘になります。 商品部や制作会社に、AIの指摘が直接届く経路は作りません。

人が確認する

1. conflict と outdated を先に見る … 引用と根拠の条文を並べて読み、採るかどうかを決めます
2. missing_condition を見る … 制限の条件がその記載の近く（同じ表、同じページ）に本当に無いかを、原稿の該当の場所を開いて確かめます
3. unclear を商品部と相談する … 解釈が要るものは、商品部・支払管理部門と確かめます
4. not_related を流し見る … 関係なしとされた記載の中に、関係のあるものが無いかを見ます
5. 見た記載の一覧を確かめる … 変更点ごとに、どの文書のどの記載を見たかを確かめ、一覧に1つも記載が無い文書があれば、その文書を自分で開きます
6. 表現の指摘を足す … 分かりやすさ、強調の仕方、文字の大きさのような表現の問題は、審査担当が足します

再審査のときは、前の回に採った指摘から見ます。 直っているかを引用で確かめたあと、直した段落の周りに新しい指摘が出ていないかを見ます。文言を直すと、同じページの別の記載との言い回しがずれることがあるからです。

1件35分を目安にします。 指摘を引用と並べて確かめ、制限の条件の場所を原稿で開き、見た記載の一覧を確かめる時間です。5番目を省かないでください。 AIの指摘が無い文書は、問題が無いのではなく、候補が拾えていないだけかもしれません。

例外に対処する

2行目は、AIではなく仕組みで拾う例外です。 制作会社が改定に合わせて、頼まれていない箇所まで直すことがあります。新旧対照表を起点にする設計だと、その変更は見に行きません。 前の版の原稿との差分を別に取っておくと、起点の漏れを補えます。

記録を残す

• 改定ごとの資料一式（約款、新旧対照表、原稿）の版と受付日時
• 変更点ごとの、拾った候補、AIに渡した内容、返ってきたJSON
• 照合で落とした指摘と理由（引用が当たらない、条文番号が実在しない）
• 審査担当が採った指摘、採らなかった指摘、自分で足した指摘
• 直した原稿の再審査で、前の回の指摘が直っていたかどうか
• 変更点ごとの、候補の数と関係ありとされた記載の数

4つ目は、仕組みの精度を測る材料です。 審査担当が自分で足した指摘のうち、表現の問題でないものが多ければ、候補の拾い出しの網の目が粗いか、審査の観点の一覧が足りていません。 用語の対応表と観点の一覧を直す手がかりになります。