グローバル保険会社：月8万件、処理時間−70%。

月80,000件のクレーム、14日のサイクル、ポリシー番号をまだ手で再入力するオペレータ。ドキュメントAIはもはやPoCではなく、やらなければ負債です。

コンテキスト

グローバル保険会社、28,000人従業員、パリと東京ハブ。マルチカントリーP&C事業、月80,000件のクレーム（調書、請求書、写真、医療証明書）。老朽化Tesseract OCR、高エラー率、過負荷の処理チーム。

問題

• 月80,000件のクレーム、主に手動処理
• 平均サイクル：14日、うち6日はドキュメント待機
• OCR精度：71%、体系的な人間検証
• 推定超過コスト：手動業務で1400万ユーロ/年
• クレームNPS：28（社内目標52に対して）

アプローチ

3段階のドキュメントAIパイプライン：標準ドキュメントの76%にレイアウト認識抽出（LayoutLMv3）、複雑または劣化ケースにマルチモーダルLLM（Claude Sonnet）、低信頼度例外に人間検証。適切なケースを適切な処理者にプッシュするために再構築されたケース管理ワークフロー。

技術的選択

• 18,000件の注釈ドキュメント（調書、請求書、証明書）でファインチューンされたLayoutLMv3
• 劣化ケース（写真、手書き、多言語）のフォールバックとしてClaude Sonnet
• 信頼度スコアリング + ドキュメントタイプによるルーティング
• ケースの8%（例外）にターゲットされた人間検証
• 現場処理者と再設計されたCamundaワークフロー

スタック

• LayoutLMv3ファインチューン、SageMakerホスティング
• AWS Bedrock経由Claude Sonnet（マルチモーダル）
• 前処理のAWS Textract
• ワークフローオーケストレーションのCamunda 8
• 社内APIのFastAPI、PostgreSQL + S3

結果

1. 平均クレームサイクル：14日から4.2日（-70%）
2. 抽出精度：71%から96.4%
3. 運用節約：12か月で検証された1100万ユーロ/年
4. クレームNPS：28から47
5. 処理ボリューム：人員一定で+30%

学んだこと

18kドキュメントでファインチューンされたLayoutLMv3は、標準ドキュメント（ボリュームの76%）でコスト/パフォーマンスでClaude Sonnetを打ち負かします。しかしClaude Sonnetは日本の手書きとぼやけた写真で無敵です。間違い：最終抽出スキーマを定義する前にドキュメントを注釈しました、2,000ドキュメントを再注釈。やり直すなら：1か月目から処理者とのスキーマコデザイン、ロールアウト前に5,000件の実クレームでパイロット。