保険会社の商品部が約款の改定案を Claude で現行の約款と比べ、保障の範囲が変わる条項と説明の要る箇所を新旧対照表にする

処理の起点を決める

案件ごとの受付フォルダに、改定案の Word ファイルが置かれたことを起点にします。 フォルダの名前に案件番号を付け、その中に改定案と改定の趣旨のメモを置きます。プログラムは定時（毎時）にフォルダを見て、まだ処理していない案件があれば動きます。

改定案は何度も版が変わります。 審査の指摘を受けて直した版が同じ案件のフォルダに置かれたら、前の版との差ではなく、必ず現行の約款との差を取り直します。 版と版の差だけを見ていると、最初の版で入った変更が対照表から消えます。

現行の約款は、文書管理のフォルダの「施行中」の版からプログラムが自分で取ります。 担当者の手元の古い版が混ざらないようにするためです。

入力データを集める

質を決めるのは、下の2つです。 判定の基準が「保障の範囲が変わるもの」とだけ書かれていると、AIは文字の変化の大きさで判定します。「支払の対象となる場合が増える」「支払の額が減る」「請求の手続が増える」のように、変化の種類ごとに社内の例を置きます。 約款担当が過去の対照表の備考から選んだ例が、そのまま判定の物差しになります。

改定の趣旨のメモは、判定には渡しません。 担当者が「表現の見直し」の先入観で読んでしまう問題（第3章の（c））を、AIに持ち込まないためです。メモは対照表の頭に載せ、判定と趣旨が食い違う行を担当者が見つけられるようにします。

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

Word の原稿からの取り出しは、プログラムが行います。段落の書式（見出しのスタイル）と、「第○条」「（○）」のような番号の書き方の両方で、条・項・号を見分けます。 約款の原稿は長年の改定で書式が崩れていることが多く、片方だけでは見分けられない段落が出ます。

Word の変更履歴は当てにしません。 改定案の作成の途中で履歴を承諾してから直した箇所は、履歴に残りません。差は必ず、現行の版と改定案の全文から取り直します。

新旧の対応づけは3段で行います。 まず見出しが同じ条を組にし、残った条を本文の似ている度合い（ratio()）で組にし、どちらにも組が見つからない条を「追加」「削除」とします。似ている度合いが0.6前後の組は、移動か書き換えかを決めきれないので、判定には「対応づけが不確か」の印を付けて渡します。

AIへ渡す前に整形する

1. 構造の表を作る … 条・項・号・別表ごとに1行。番号、見出し、本文、親の条を持たせます
2. 表記をそろえる … 全角と半角、漢数字と算用数字、括弧の種類をそろえた写しを作り、比べるのはその写しで行います。原文は別に持ち、根拠の照合と対照表には原文を使います
3. 新旧を対応づける … 上の3段の手順で組を作り、組ごとに get_opcodes() で変わった箇所を取ります
4. 定義語の差を取る … 定義の条と「（以下「〜」といいます。）」の定義文を新旧で比べ、定義文が変わった語の一覧を作ります
5. 定義が変わった語を使う条項を拾う … 本文の文字が変わっていなくても、その語を含む条項を「定義の波及」の組として加えます
6. 別表の差を取る … 行の追加・削除・セルの変更を取り、別表を引いている条項を同じく波及の組として加えます
7. 判定に回す組を絞る … 文字の差が無く、波及にも当たらない組は判定に回さず「変更なし」とします

5番目と6番目が、この構成のいちばん大事な前処理です。 「入院」の定義に「治療を目的として」の一句が足されると、本文の入院給付金の条は1字も変わりませんが、支払の対象になる入院は減ります。 文字の差だけで組を選ぶと、この条は7番目で「変更なし」に落ちます。

7番目で落とす組は、件数だけを対照表の末尾に載せます。 「変更なし 412組」と出ていれば、担当者は流し見で足りることが分かります。落とした組を消してしまうと、対応づけの誤りで落ちた条があっても気づけません。

AIに処理させる

させるのは、新旧の条項の組ごとに、変化の種類を1つ選び、根拠の文言を新旧の両方から写すことだけです。

選ばせる変化の種類は、wording_only（表現だけ）、scope_expanded（範囲の拡大）、scope_reduced（範囲の縮小）、condition_changed（条件・手続の変更）、undetermined（判断できない）の5つです。 1つの条で拡大と縮小が同時に起きる場合は、契約者に不利な向きの方を選び、両方を notes に書かせます。 審査で先に読むべきなのは不利な向きだからです。

説明の要否は、AIに決めさせず「候補」として付けさせます。 範囲の縮小、免責の増加、手続の増加のどれかに当たる組に explain_candidate: true を立てさせ、どの書面で説明するか、既契約に及ぶかは書かせません。

指示内容を固定する

あなたは保険会社の約款担当として、約款の現行の条項と改定案の条項を比べ、
保障の範囲がどう変わったかを分類する立場です。
渡された条文だけを見て判定してください。改定の意図を推測しないでください。

【入力】
- old_text：現行の条項（原文）
- new_text：改定案の条項（原文）
- diff：変わった箇所の一覧（プログラムが作ったもの）
- changed_terms：定義が変わった語と、新旧の定義文（ある場合）
- changed_tables：この条項が引いている別表の差（ある場合）
- mapping_uncertain：新旧の対応づけが不確かなら true

【change_type の選び方】
- wording_only ........ 文の形が変わっただけで、支払の対象・額・免責・手続・義務が変わらない
- scope_expanded ...... 支払の対象になる場合や額が増える、または免責が減る
- scope_reduced ....... 支払の対象になる場合や額が減る、または免責が増える
- condition_changed ... 請求の手続・期限・書類、契約者の義務が変わる
- undetermined ........ 渡された文言だけでは向きが決められない
迷ったときに wording_only を選ばないでください。
拡大と縮小が同時に起きる場合は scope_reduced を選び、両方を notes に書いてください。

【厳守事項】
- 本文の文字が同じでも、changed_terms や changed_tables があれば、
  その定義・別表の変化を本文に当てはめて読んでください。
  本文が同じであることを理由に wording_only を選ばないでください。
- 「ただし」「〜を除きます」「〜を含みます」「〜に限ります」の向きを必ず確かめてください。
- old_quote と new_quote には、判定の根拠にした文言を原文から一字一句そのまま写してください。
  言い換え・要約・省略をしないでください。追加・削除の条では、無い側は空にしてください。
- 渡されていない条項・別表・法令の内容を根拠にしないでください。
- 認可・届出の要否、既契約への適用、契約者への案内の方法は書かないでください。
- explain_candidate は、scope_reduced、免責の増加、手続や義務の増加のときに true にしてください。
- mapping_uncertain が true のときは、まず新旧が同じ内容の条項かを確かめ、
  別の条項どうしと考えられる場合は undetermined にして notes に理由を書いてください。

【判定の例】{judgement_examples}
【保障に関わる語の一覧】{coverage_terms}
【判定する組】{pair}

「本文が同じでも定義の変化を当てはめて読む」を明記しないと、波及の組はほぼ wording_only になります。 本文の新旧が同じ文字列で、AIはその一致を最も強い手がかりにするからです。禁じるのは、本文の一致を根拠にした判断そのものです。

「迷ったら wording_only を選ばない」も同じ考えです。 wording_only の行は担当者が流し見する行で、そこに紛れた縮小は審査まで誰にも読まれません。 迷った行は undetermined にして、人が読む側に寄せます。

出力形式を固定する

構造化出力で、次の形の JSON を受け取ります。

{
  "pair_id": "",
  "old_ref": "第12条第1項",
  "new_ref": "第13条第1項",
  "pair_kind": "text_changed | term_propagation | table_propagation | added | deleted",
  "change_type": "wording_only | scope_expanded | scope_reduced | condition_changed | undetermined",
  "aspects": ["payment_trigger", "benefit_amount", "exclusion", "claim_procedure", "policyholder_duty"],
  "old_quote": "",
  "new_quote": "",
  "explain_candidate": true,
  "notes": ""
}

1つ目の理由は、pair_kind と change_type を別の項目に置けることです。 pair_kind はプログラムが付ける「なぜこの組を見ているか」で、change_type は AI が付ける「何が変わったか」です。定義の波及で拾った組のうち何割が実際に範囲を動かしたかを、あとで数えられます。 波及の組がほとんど wording_only なら、拾い方が広すぎるか、指示が効いていないかのどちらかです。

2つ目は、old_quote と new_quote をプログラムで照らせることです。 写された文言を、表記をそろえる前の原文の中で探し、見つからなければ、その行の change_type をそのまま使わず「根拠不一致」として人の確認に回します。 照合は文字列の一致だけで行い、AIにもう一度確かめさせることはしません。

3つ目は、対照表の並べ替えが機械的にできることです。 対照表の下書きは次の順に並べます。

4行目で趣旨と照らすのは、意図しない拡大も、保険料の算出の前提と合わなくなるからです。

システムへ連携する

約款の原稿にも、文書管理の「施行中」の版にも書き込みません。 対照表の下書きは案件のフォルダに新しいファイルとして置き、ファイル名に現行の版と改定案の版を入れます。 どの版どうしを比べた表かが分からなくなると、審査の指摘がどの版に対するものかが追えなくなります。

Claude API に送るのは、判定する組の条文と、その組に関わる定義・別表だけです。 約款の全文や、改定の案件の一覧は送りません。1組ずつ送ると、1つの組の判定がうまくいかなくても、その組だけを送り直せます。

人が確認する

担当者は、対照表の上から読みます。 第7章の出力形式の表の1から4までを読み、5は流し見、末尾は件数だけを見ます。全行を同じ深さで読む運用にすると、第10章の40.0時間には収まりません。

1. 根拠不一致と undetermined を先に読む … 多くは対応づけの誤りか、条をまたぐ書き方です。原文を開いて新旧を自分で決めます
2. scope_reduced の根拠を確かめる … old_quote と new_quote を読み、本当に範囲が狭まっているかを確かめます
3. 説明の要否の候補を見直す … explain_candidate の行から、説明が要るものを法務と決めます
4. wording_only の下線を流し見する … 数文字の差で向きが変わる言い回しが紛れていないかを見ます
5. 判定を覆したら記録する … どの組を、どの種類からどの種類に変えたかと、理由を一言残します

2番目を省かないでください。 scope_reduced の行は、審査の資料でいちばん重く読まれる行です。 AIが縮小と判定した理由が誤っていれば、改定の趣旨と違う議論が審査で始まります。

5番目の記録は、同じ種類の覆しが続いたら、その組を判定の例に加える材料になります。

例外に対処する

最後の行は、止めることが正しい例外です。 古い版と比べた対照表は、正しい形をしたまま誤った資料になります。 気づかれずに審査に回るのがいちばん危ないので、代用せずに止めます。

公式のドキュメントでは、応答が max_tokens で切れるとスキーマに沿わないことがあるとされています。 長い組では max_tokens に余裕を持たせます。

記録を残す

• 比べた現行の版と改定案の版（ファイル名と更新日時）
• 構造の表と、新旧の対応づけの結果（組ごとの ratio() の値を含む）
• 定義語の差の一覧と、そこから拾った波及の組
• 組ごとに Claude に送った内容と、返ってきた JSON の全文
• 根拠の文言の照合の結果（一致・不一致）
• 担当者が判定を覆した記録 … 組、変える前と後の種類、理由
• 審査に出した対照表の版と、そのときの判定の一覧

4つ目で送った内容を残すのは、判定の基準の例が後から変わるためです。 例を足すと同じ組の判定が変わることがあり、当時どの例で判定したかが残っていないと、審査で出た判定の理由をたどれません。