保険証券データをExcelに抽出 — ACORDフォームとCOI項目をあらゆる保険会社形式から対応
ACORD 25フォームのCOI項目を手入力すると、1枚あたり3～5分かかります。1枚の証券にGL、自動車、アンブレラ、労災の4つの補償区分があり、それぞれに証券番号、限度額、有効期限がある場合、列が1つずれるだけでコンプライアンス管理表の期限が誤ってしまいます。本ツールは各補償行を名前付きExcel列に抽出し、1ページあたり5～10秒で処理します。
暗号化処理 · 変換後自動データ削除
保険証券から抽出できる項目
必要な列名を入力するだけで、AIが各項目の意味を理解し、標準的なACORD 25形式や保険会社独自の証明書形式を問わず、すべてのCOIから該当する値を抽出します。一度設定した列名は、異なる保険会社の書類でもそのまま使えます。
本ツールはカスタム列抽出を採用しています。出力スプレッドシートの列名（「記名被保険者」「GL１事故あたりの限度額」「保険満了日」など）を指定するだけで、AIが各COI上の該当値を、フィールドラベルの意味と文書内の視覚的な配置から特定します。そのため、1組の列名で、異なる保険会社のACORD 25書式、非標準の独自フォーマットのCOI、レイアウトがずれた古いスキャン証書にも対応可能です。保険会社ごとのテンプレートや座標マッピングは不要です。
テンプレート抽出がCOIで機能しない理由 — 本ツールの違い
ACORD 25フォームは保険業界の共通言語であり、補償内容を伝える標準形式です。しかし「標準形式」と「標準文書」は同じではありません。各代理店管理システムで表示が微妙に異なり、1枚の証券には実際には3～4の独立した補償ポリシーが密集したグリッドとして含まれており、単純なOCRではその構造を理解できません。
1つの証明書には3～4の独立した保険証券が密集したグリッドに積み重なっていますが、フラットOCRは列ごとに縦読みせず、行ごとに左から右へ読み取ります。 ACORD 25の補償範囲セクションには、一般賠償責任、自動車賠償責任、包括・超過責任、労災の行と、保険会社、証券番号、発効日、満了日、限度額の列があります。座標ベースのテンプレートOCRは、自動車行の満了日を一般賠償行の限度額と誤って位置合わせし、静かに誤ったデータを生成する可能性があります。Redditでは、プロジェクトマネージャーが 一日中COIデータを手動で検証していると述べており、「このスプレッドシートの日付を1つ見逃すだけで、会社に数百万の損害が出る可能性がある」としています。
追加被保険者フィールドはチェックボックスです。チェックボックスは座標ベースのOCRでは見えません。 ACORD 25では、追加被保険者のステータスは、作業内容の説明セクションの横にあるチェック済みまたは未チェックのボックスとして表示されます。テキストフィールドと金額を読み取るように訓練されたOCRツールは、チェックボックスの状態を日常的にスキップします。つまり、最も重要なコンプライアンスの質問（「この下請け業者の保険は当社をカバーするように裏書されているか？」）が未回答のままになります。コンプライアンス専門家が指摘するように、COIのチェックボックスだけでは不十分で、実際の裏書を確認する必要がありますが、チェックボックス抽出がなければ、その確認を始めることさえできません。
保険会社の文字コード（A、B、C、D）は、フラット抽出では失われる関係マッピングを作成します。 ACORD 25では、補償範囲テーブルは「Insr Ltr」列の文字指定を使用して、各補償範囲行をヘッダーにリストされた特定の保険会社に結び付けます。プロデューサー名とキャリア名は別々のブロックに表示されます。各セルを個別に読み取るフラット抽出では、A→キャリアの関係が保持されないため、手作業でやり直さなければ、どのキャリアがどの補償範囲行を引き受けているかを知ることができません。
列を一度定義するだけで、AIが各補償行を個別のデータとして読み取り、最終スプレッドシートでは1行につき1保険証券を出力します。 「補償の種類」「証券番号」「1事故あたりの限度額」「満期日」という列を定義すれば、AIは表内の各補償行を個別のデータレコードとして識別します。GL行とAuto行はそれぞれ出力の1行となり、被保険者名や証明書保持者名の値は全行に繰り返されるため、出力は完全なリレーショナルコンテキストを保持します。補償の種類でフィルタリングしたり、満期日で並べ替えたりすることが可能です。
AIは、ピクセル座標ではなく文書の視覚的構造を読み取ることで、チェックボックスの状態、保険会社の略号、密集したグリッドレイアウトを認識します。 「追加被保険者」ボックスにチェックがあれば「はい」と理解し、「Insr Ltr」列の「A」は「保険会社A」ヘッダーブロックのキャリアに対応し、「一般賠償責任」とラベル付けされた補償行には、その下の「自動車賠償責任」行とは異なる独自の証券番号、日付、限度額があることを認識します。この意味的な読み取りは、キャリアのレンダリングシステムが各要素をページ上のどこに配置しても機能します。
1つの列定義が、ACORD標準形式でも独自形式でも、あらゆる保険会社のCOIで機能します。 証明書がTravelersのシステム生成ACORD 25であれ、地域保険会社の独自形式であれ、小規模下請け業者からメールで送られたスキャンPDFであれ、同じ列名で同じデータ型を抽出します。保険会社ごとのテンプレート設定は不要。手動の座標マッピングも不要。列を一度入力するだけで、AIはどこでも値を検出します。
下請け業者のCOIバッチ処理の流れ
アップロード — 下請けから届いた書類をそのまま
20社の下請けからCOIを受け取ります。Applied Epicが生成したACORD 25のPDF、保険会社独自の証明書フォーマット、解像度の異なるスキャンコピーなど、形式はさまざまです。ある下請けは追加被保険者条項が添付されたCOIを送ってきます。これらすべてをまとめて一度にアップロードしてください。形式、保険会社、書類の種類による事前仕分けは不要です。
列を定義 — コンプライアンストラッカーに必要な項目
出力するスプレッドシートの列名を入力します：被保険者、証明書保有者、保険会社、補償の種類、証券番号、1事故あたりの限度額、開始日、満期日、追加被保険者。計算列も定義できます。たとえば、満期までの日数という列名を付け、AIに「満期日から今日の日付を引く」と説明すれば、Excelで別途数式を設定しなくても、出力に即座にコンプライアンスステータスが表示されます。
出力 — 全下請けの全補償行を1つのスプレッドシートに
Excelファイルをダウンロードできます。各行は1つのCOIに記載された1つの補償の種類に対応します。GL + 自賠責 + 労災の補償がある下請けは3行生成され、被保険者と証明書保有者は同じですが、証券番号、限度額、日付は各補償セクションごとに異なります。出力はピボットテーブルに最適です。補償の種類でフィルタリングすれば全下請けのGL限度額を一目で確認でき、満期日で並べ替えれば更新が必要な証券を特定でき、保険会社でグループ化すればベンダーポートフォリオ全体の補償集中度を監査できます。追加被保険者のステータスは「あり/なし」列で表示され、確認済みは緑、未確認は空白になります。XLSX、CSV、JSON形式でエクスポート可能です。
最適な使用シーンと結果確認が必要なケース
標準的なACORD 25および保険会社フォーマットのCOIでは高い抽出精度を発揮します。大量のバッチを処理する前に、いくつかの書類の状態やCOI特有の複雑さを理解しておくことをお勧めします。
確実に処理
システム生成のACORD 25証明書。Applied Epic、Vertafore、AMS360などの代理店管理システムで作成されたCOIを高精度で抽出。AIが標準化されたセクションヘッダー（一般賠償責任、自動車賠償責任、包括・超過、労災）を読み取り、各行の保険証券番号、日付、限度額を正しい出力列にマッピングします。
保険会社独自の証明書形式。多くの大手保険会社（トラベラーズ、リバティ・ミューチュアル、チャブ）は、ACORD 25ではなく独自の形式で証明書を発行します。AIは、ACORDのレイアウトテンプレートに一致させるのではなく、フィールドラベルを意味的に理解することで、同じフィールドタイプ（被保険者、保険会社、補償限度額、日付）を抽出します。
下請け業者COIの一括処理。複数の下請け業者からのCOIをアップロード（各業者が異なる保険会社、異なる形式の場合もあり）し、1つの列定義で全てを処理。各証明書は個別に処理され、出力Excelは全ての下請け業者を1つのシートに統合します。
200dpi以上のスキャン紙COI。印刷された証明書の鮮明なスキャン（古いACORDバージョン2010/05および2016/03を含む）を確実に抽出。追加被保険者のチェックボックス状態は、スキャン画像がチェックの有無を判別できるほど鮮明な場合に取得されます。
以下のケースは要確認
追加被保険者の承認文言ページは、COI本体とは別の書類です。 AIはACORD 25フォーム自体から追加被保険者のチェックボックスを抽出しますが、実際の承認文言（どの法人が指定され、どの補償が拡大されるか）は、別添のページに記載されています。COIとともに承認ページをアップロードすれば、追加被保険者名の列を定義でき、AIは承認ページから抽出します。現バージョンでは、承認ページと親COIを証明書番号で自動的に関連付けません。出力の承認行が正しい証明書に対応しているか、必ず確認してください。
手書き（小さな文字や筆記体）のCOI。 代理店がACORD 25のフィールド（特に補償表の狭いグリッドセル）に証券番号、日付、限度額を手書きで記入する場合、AIの手書き認識精度は印刷文字のベースラインを下回ります。信頼度列を追加して、低信頼度の行を手動レビュー対象としてフラグ付けしてください。特に証券番号や金額など、1桁の誤認が重大な影響を及ぼすフィールドで有効です。
継続フォームにまたがる業務内容の説明。 ACORD 25の「業務内容の説明」欄が「別紙参照」やACORD 101継続フォームへの参照で途切れている場合、AIはACORD 25自体に記載されたテキストのみを抽出します。継続フォームのテキストは、メインの証明書と一緒にアップロードされた場合にのみ取得されます。
グラフィックや画像ベースの形式を多用する保険会社のCOI。 一部の地域保険会社は、テキストレイヤーを持つPDFではなく、PDF内のフラットな画像レンダリングとして証明書を発行します。AIはこれらを視覚認識で処理しますが、精度は画像の解像度とコントラストに依存します。出力に予期しない空白や「被保険者」「保険会社」列の文字化けが見られる場合は、ソースPDFに選択可能なテキストレイヤーがあるか、純粋なグラフィックかを確認してください。純粋なグラフィック文書の場合は、より高解像度でアップロードすると効果的です。
よくある質問
ACORD 25フォームは、正確な標準レイアウトを使用する保険会社だけでなく、どの保険会社のものも処理できますか？
保険会社や代理店管理システムの種類に関わらず、ACORD 25フォームを処理できます。AIはピクセル座標ではなく、フィールドラベルやセクションヘッダーを意味的に読み取るため、保険会社間で位置が異なっていても（例：「証明書番号」の位置が10ピクセルずれている場合でも）抽出に影響しません。ACORDレイアウトに従わない保険会社独自のフォーマットにも対応しています。「記名被保険者」「証券番号」「GL 1事故限度額」などの列を定義すれば、AIは周囲のラベルテキストと視覚的なコンテキストを理解して、ページ上の該当する値をどこからでも特定します。
一般賠償責任、自動車、アンブレラ、労災保険の個別の行がある複数行の補償テーブルはどのように処理しますか？
ACORD 25の補償テーブルにある各補償行は、出力Excelの個別の行になります。「補償種別」「証券番号」「1事故限度額」「満期日」などの列を定義すると、AIは各補償セクションの行を個別に識別します。GL行の証券番号、限度額、日付を1つの出力行に、自動車行を次の行に、アンブレラ行をその次の行に、労災行をさらに次の行に抽出します。出力では、証明書ヘッダー（記名被保険者、証明書取得者、保険代理店）と補償レベルの詳細との間の1対Nの関係が保持されます。記名被保険者と証明書取得者の値は関連するすべての行で繰り返されるため、下請け業者と補償種別の任意の組み合わせでフィルタリング、並べ替え、ピボットが可能です。これは、表グリッドを左から右に読み取り、自動車行の日付とGL行の証券番号が誤って一致するリスクがあるフラットなOCRとは根本的に異なります。
追加被保険者チェックボックスの検出精度は？スキャンしたCOIでも大丈夫？
代理店管理システムで生成された、鮮明なデジタルPDF（大半のCOIが該当）の場合、チェックボックス検出は信頼性が高く、マークあり（Xやチェック）は「はい」、マークなしは「いいえ」と一貫して識別されます。スキャンした紙のCOIの場合、精度はスキャン品質に依存します。200dpi以上の鮮明なスキャンでは信頼性の高い検出が可能ですが、低解像度のスキャンや、チェックボックスの枠線が不鮮明なFAXコピーでは精度が低下します。この違いが重要なのは、追加被保険者チェックボックスが重要なコンプライアンス指標だからです。これは、下請け業者の保険証券にあなたを追加被保険者として記載する裏書がされているかどうかを示し、請求発生時の法的立場に影響します。最初の数枚のスキャンCOIで追加被保険者欄をスポットチェックし、出力パターンが元の書類と一致することを確認してから、安心して処理を進めることをお勧めします。
コレクションリンクと連携して、下請け業者に直接COIをアップロードさせることはできますか？
はい。ImageToTable.aiにはコレクションリンク機能があります。これは各下請け業者に送信できる共有可能なURLで、業者はリンクを開き、短い確認コードを入力するだけで、登録やログインなしでCOIを直接あなたの処理キューにアップロードできます。ファイルは、あらかじめ定義した列名で抽出準備が整った状態でアカウントに届きます。これにより、COIの要求、催促、転送といったメールのやり取りが不要になり、すべての証明書がメールスレッドに散らばることなく、一貫したフォーマットの処理パイプラインに集約されます。処理後、抽出されたデータは、直接アップロードしたCOIとともにExcel出力に反映されます。
被保険者欄について — 名前が似ている場合、被保険者と証明書保持者を区別できますか？
はい。ACORD 25では、被保険者は通常左上の被保険者欄に、証明書保持者は別の欄に表示されます。AIは視覚的な階層を読み取り、「INSURED」または「PRODUCER」（標準的なACORD 25の左側）に記載された主体を保険契約者、「CERTIFICATE HOLDER」に記載された主体を補償証明の請求者として正しく認識します。この意味的な読み取りにより、両方の名前が構造的に類似した会社名（例：被保険者が「ABC Construction LLC」、証明書保持者が「ABC Development Corp」）であっても、各主体を正しい出力列に割り当てます。これは座標ベースのOCRが失敗するケースでもあります — 異なる保険会社のACORDレンダリング間で2つの名前ブロックの位置がずれると、固定座標を期待するテンプレートは警告なく両者を入れ替えてしまいます。