保険代理店の事故受付書類をClaude Codeで守る: 証券番号と診断書を渡さない入力境界

事故受付メールの添付を開くと、事故状況メモ、保険証券のPDF、修理見積、診断書の写真が同じフォルダに入っている。担当者は早く不足書類を返したいので、まとめてClaude Codeへ読ませたくなります。けれど証券番号、住所、車台番号、病名、相手方の氏名まで混ざったまま下書きを作ると、社内確認で止まります。今日まず直す場所は、プロンプトではなく、事故受付CSVと添付書類をAI作業用に切り分ける表です。

保険代理店の事故受付では、問い合わせ対応、保険会社への連携、契約者への不足書類案内が重なります。Claude Codeは、架空IDに置き換えた受付CSV、分類済みチェックリスト、メール下書き、権限設定の確認に向いています。一方で、保険金支払いの判断、補償範囲、診断書、本人同意、保険会社別の送付先は人が確認します。

この記事では、保険代理店が事故受付書類を扱う時に、原本、作業コピー、AI出力、承認済みメールを分ける流れを作ります。参考にした一次情報は、Claude Codeの権限設定、サンドボックス、金融庁の金融分野における個人情報保護、個人情報保護委員会のクラウドサービス注意喚起、同委員会の損害保険会社及び保険代理店に関する資料です。この記事は個別の法務判断ではありません。主CTAは、社内の役割と承認線を一緒に決める研修・相談です。

この記事の要点

• 原本は claim-raw/、AIへ渡す作業コピーは claim-ai-work/ に分けます。
• Claude Codeへ渡すのは、受付ID、事故種別、日付帯、不足書類カテゴリ、伏せた状況要約までに絞ります。
• 証券番号、住所、電話、メール、車台番号、診断書、病名、相手方情報、保険会社別の内部メモは原本側に残します。
• Use caseは、受付CSVの分類、不足書類メール、保険会社別チェックリストの3つです。
• ROIは、下書き時間だけでなく、入力前検査で止めた件数、差し戻し、誤送信寸前の検知数も見ます。

業務フロー: 事故受付CSVと添付を分ける

最初に、事故受付フォルダを4つに分けます。claim-raw/ は原本です。契約者メール、証券PDF、診断書画像、修理見積、相手方メモを置きます。claim-transform/ は変換ルールです。claim-ai-work/ はAIへ渡す作業コピーです。claim-approved/ は人が承認したメールとチェックリストです。

フォルダ	入れるもの	Claude Codeの扱い
claim-raw/	メール原文、証券、診断書、写真、見積	読み書きとも拒否
claim-transform/	項目表、置換ルール、検査コマンド	人が確認して実行
claim-ai-work/	仮名化CSV、分類表、メール下書き材料	読み書きを許可
claim-approved/	承認済みメール、送付チェック表	人の操作で保存

作業コピーの1行は、次の粒度にします。claim_id、case_type、received_date、missing_document_type、redacted_summary、next_owner、carrier_channel です。carrier_channel は「A社Webポータル」「B社担当窓口」のような分類だけにし、実際の担当者名やメールアドレスは入れません。

事故状況の自由記述は、もっとも漏れが出やすい場所です。「山田様の自宅前で」「同乗の母が」「首の痛みで通院」のように、氏名や健康情報が残ります。作業コピーでは「契約者A」「同乗者B」「身体症状あり、詳細は原本確認」のように置き換えます。病名、診断名、医療機関名はAI作業用には入れません。

金融庁は金融分野の個人情報保護に関するガイドラインや実務指針を公開しています。個人情報保護委員会の保険代理店関連資料でも、保険契約者データを保険会社ごとに分けず一斉送信した事案、出向者による不適切な共有、組織的・人的安全管理措置の不足が扱われています。だからAIに渡す前の線引きは、便利な下書き作りの話ではなく、送付先と委託範囲を間違えないための業務設計です。

flowchart TD
  A[claim-raw 原本] --> B[claim-transform 項目表]
  B --> C[匿名化と範囲化]
  C --> D[入力前検査]
  D --> E[claim-ai-work 作業コピー]
  E --> F[Claude Code 下書き]
  F --> G[担当者レビュー]
  G --> H[claim-approved 承認済み]

Claude Codeに任せる範囲と人が判断する範囲

Claude Codeに任せる範囲は、匿名化後のCSVを分類し、不足書類を表にし、契約者へ返す質問案を作るところまでです。たとえば「物損、修理見積なし、事故日だけある」「人身の可能性、診断書詳細は原本確認」といった作業メモから、不足書類と次の担当を並べます。

人が判断する範囲は、補償対象、保険金支払い、免責、過失割合、診断書、相手方への連絡、保険会社への正式送付、本人同意、保存期間です。Claude Codeが作ったメールは、そのまま送信しません。人が原本を見て、保険会社ごとの手順と顧客への表現を確認します。

権限は二層で考えます。Claude Codeの権限設定では、どのtoolがどのファイルやドメインへ触れるかを制御します。公式説明では、権限とサンドボックスは補完関係にあり、サンドボックスはBashコマンドと子プロセスにOSレベルの境界をかけます。保険代理店では、Read(/claim-raw/**) と Edit(/claim-raw/**) を拒否し、claim-ai-work/ だけを許可します。Bashで原本を読めないこともサンドボックスで重ねます。

内部記事では、Claude Codeの権限設定ガイドとセキュリティ実践も合わせて読むと、denyを先に置く考え方を整理できます。

3つのUse case

Use case 1: 受付CSVを事故種別と不足書類に分ける

• 入力: claim_id、事故種別、受付日、伏せた状況要約、添付カテゴリ、担当チーム。
• 出力: 物損、人身、火災、水漏れなどの分類、不足書類、次に見る原本欄、担当者への質問。
• 人の確認: 補償範囲、契約内容、証券番号、相手方情報、診断書、保険会社別の送付先を確認する。

Claude Codeには「分類の候補」と「人が見る欄」を出させます。事故原因や支払い可否は断定させません。受付CSVの行が増えた日でも、まず不足書類の棚卸しだけならAI作業コピーで足ります。契約内容へ踏み込む時は、担当者が原本と保険会社の手順を見ます。

Use case 2: 不足書類メールの下書きを作る

• 入力: 受付ID、契約者の仮名、足りない書類カテゴリ、返信期限、提出方法の選択肢、問い合わせ窓口の分類。
• 出力: 件名、本文、必要書類の箇条書き、返信時の注意、送信前チェック欄。
• 人の確認: 宛先、契約者名、実際の必要書類、保険会社名、送信方法、添付漏れを確認する。

不足書類メールでは、やわらかい文面よりも宛先と書類名が大事です。作業コピーでは「修理見積」「事故状況メモ」「通院関連書類」のようなカテゴリだけを出します。診断書の中身や病名は入れません。文面の型は、問い合わせ導線の整え方とも近いです。

Use case 3: 保険会社別の送付チェックリストを作る

• 入力: 保険会社分類、事故種別、提出チャネル、必要書類カテゴリ、担当者ロール、送付禁止情報。
• 出力: 送付前チェックリスト、保険会社別の確認欄、送らない情報、承認者、保留理由。
• 人の確認: 委託範囲、本人同意、保険会社別ルール、正式な宛先、保留時の顧客連絡を確認する。

乗合代理店では、保険会社をまたぐ情報の扱いに注意が要ります。Claude Codeには「どの保険会社へ送るか」ではなく、「送付前に人が確認する欄」を作らせます。保険会社名、担当者名、具体的な契約番号は原本側に残し、作業コピーには分類だけを置きます。

コピペで使えるプロンプト

次のプロンプトは、claim-ai-work/ に置いた架空ID化済みCSVだけを読む前提です。原本、証券、診断書、メール原文は読ませません。

あなたは保険代理店の事故受付補助です。
./claim-ai-work/intake-redacted.csv だけを読み、次の順で出力してください。

1. 受付IDごとの事故種別候補
2. 不足書類カテゴリ
3. 担当者が原本で確認する欄
4. 契約者へ返す不足書類メールの下書き
5. 送信前チェックリスト

制約:
- 保険金支払い、免責、過失割合、補償対象を断定しない
- 証券番号、住所、電話、メール、車台番号、病名、相手方名を補わない
- 原本フォルダ、メール送信、外部通信、削除を行わない
- 個人情報らしい値を見つけたら処理を止め、項目名だけ報告する
- 出力の最後に「担当者確認前・送信不可」と書く

動く確認コード

記事内で新しい補助ファイルを紹介するなら、保存先は tools/check-insurance-claim-input.mjs です。この記事ではファイルを作りません。使う場合は、次の完全な内容をそのまま保存します。検査対象はJSON、CSV、Markdown、テキストだけです。PDFや画像は対象外として止めます。

const files = [
  {
    path: "claim-ai-work/intake-redacted.csv",
    text: "claim_id,case_type,redacted_summary\nC-001,auto_property,front bumper damage"
  },
  {
    path: "claim-ai-work/bad.csv",
    text: "claim_id,email,policy_number\nC-002,[email protected],AB1234567890"
  }
];

const blockedFieldNames = [
  "name",
  "email",
  "phone",
  "address",
  "policy_number",
  "vin",
  "diagnosis",
  "hospital",
  "counterparty"
];

const valuePatterns = [
  /[A-Z]{2}\d{10}/,
  /[\w.+-]+@[\w.-]+\.[A-Za-z]{2,}/,
  /\b\d{2,4}-\d{2,4}-\d{3,4}\b/
];

const findings = [];

for (const file of files) {
  const lower = file.text.toLowerCase();
  for (const field of blockedFieldNames) {
    if (lower.includes(field)) findings.push({ path: file.path, type: "blocked field", field });
  }
  for (const pattern of valuePatterns) {
    if (pattern.test(file.text)) findings.push({ path: file.path, type: "blocked value", pattern: String(pattern) });
  }
}

console.table(findings);
if (findings.length > 0) process.exitCode = 1;

実運用では、上の配列をローカルの架空検証ファイルに置き換えます。実契約者データをテストに使わないでください。検査で0件でも安全とは決めず、人が作業コピーを開いて確認します。

Claude Code側の設定例は次の形です。公式の設定仕様は変わるため、導入前に公式ページを見直します。

{
  "permissions": {
    "deny": [
      "Read(/claim-raw/**)",
      "Edit(/claim-raw/**)",
      "Read(/secrets/**)",
      "Edit(/secrets/**)",
      "Bash(git push *)"
    ],
    "allow": [
      "Read(/claim-ai-work/**)",
      "Edit(/claim-ai-work/**)",
      "Bash(node tools/check-insurance-claim-input.mjs *)"
    ]
  },
  "sandbox": {
    "enabled": true,
    "failIfUnavailable": true,
    "allowUnsandboxedCommands": false,
    "filesystem": {
      "denyRead": ["./claim-raw", "./secrets"],
      "denyWrite": ["./claim-raw", "./secrets"]
    }
  }
}

Pitfall: 保険代理店のAI入力境界が破れる落とし穴と直し方

原因の1つ目は、証券番号だけ消せばよいと考える点です。事故状況メモには、住所、車台番号、相手方名、勤務先、通院先、病名が残ります。直し方は、目的ごとに許可項目を決め、自由記述を短い伏せ字要約へ変えてから claim-ai-work/ へ置くことです。

原因の2つ目は、保険会社ごとの情報を同じ作業コピーへ混ぜる点です。乗合代理店では、契約先ではない保険会社へ送ってはいけない情報が出ます。対策は、保険会社名を分類にとどめ、正式な送付先と委託範囲は人が原本で見る欄へ戻すことです。

原因の3つ目は、Read拒否だけでBashや外部toolも止まると思う点です。公式ドキュメントでは、権限とサンドボックスは別の層です。修正は、deny とサンドボックスの denyRead、denyWrite を重ね、サンドボックスが使えない端末では事故受付データを扱わない運用にします。

原因の4つ目は、検査コードを実データで試す点です。ログ、スクリーンショット、ターミナル履歴に値が残ります。架空の受付IDと架空のメールだけで拒否と許可を試し、本番フォルダでは検査と目視確認のあとにClaude Codeへ渡します。

ROIを小さく測る

最初の2週間は、事故受付のうち「不足書類メール」だけを対象にします。導入前に、1件あたりの下書き分、担当者レビュー分、差し戻し件数、宛先や書類名の修正件数を5件分記録します。導入後も同じ項目を取り、入力前検査で止まった件数を追加します。

計算は単純で構いません。件数 × (下書き分 + レビュー分 + 差し戻し分) と、入力前検査で止まった件数 を並べます。たとえば10件の下書きが速くなっても、承認で戻る件数が増えたなら、運用はまだ粗いです。速さだけでなく、他社名混入、証券番号残り、診断書情報の混入を止めた件数を見ます。

広告や問い合わせの成果を見る前に、社内の停止件数を見ます。保険代理店の事故受付では、早く返すことと、送ってはいけない情報を送らないことを同じ表で扱う必要があります。

よくある質問

Q. 証券番号を消せばClaude Codeへ渡せますか。

いいえ。氏名、住所、電話、メール、車台番号、相手方、診断書、病名、勤務先、珍しい事故状況も見ます。複数の値から契約者を推測できないか、人が確認します。

Q. Claude Codeの権限設定だけで十分ですか。

十分とは決めません。権限設定はtoolの境界を作りますが、Bashの子プロセスや端末全体の境界はサンドボックス、OS、フォルダ運用で重ねます。設定が効いているかは架空データで拒否テストをします。

Q. 診断書の内容を要約させたい時はどうしますか。

この記事の流れでは、診断書本文をAI作業コピーへ入れません。必要なら責任者が、契約、本人同意、利用目的、委託先、社内規程を確認し、承認済み手順を別に作ります。

Q. 保険会社別のルールまでAIに決めさせますか。

決めさせません。Claude Codeには、確認欄や不足書類カテゴリを整えさせます。正式な送付先、委託範囲、保険会社ごとの指示は人が原本で確認します。

研修・相談で決めること

保険代理店で事故受付にClaude Codeを入れるなら、設定ファイルだけでは足りません。原本を置く人、作業コピーを作る人、メールを承認する人、保険会社へ送る人、削除期限を見る人を分けます。小さな代理店でも、同じ担当者が兼務するなら、チェック欄だけは分けて残します。

研修・相談では、事故受付CSV、メール、添付書類、保険会社別送付先、権限設定、入力前検査、承認表を、実データを持ち込まない形で整理します。最初の面談では、既存フォルダ名と作りたい成果物だけを確認し、証券や診断書そのものは共有しません。

実際に試した結果

この記事では、/images/hero/hero-056.webp が site/public/images/hero/hero-056.webp に存在すること、Claude Codeの権限設定URL、サンドボックスURL、金融庁URL、個人情報保護委員会URL、PPCの保険代理店資料URLを確認しました。本文のJavaScriptは架空配列だけを使う構文例です。保険会社API、顧客DB、メール送信、実契約者データでのruntime testは行っていません。

公開前の確認対象は、slug insurance-agency-claim-intake-data-boundary-claude-code、frontmatter、内部リンク、外部リンク、CTA、コードフェンス、10言語ファイル、Qiitaリンクです。今日まずやる1手は、実データではなく架空の claim-raw/ と claim-ai-work/ を用意し、原本側を読ませない拒否テストから始めることです。