ACORD 25 COIデータをExcelに抽出する方法
協力会社コンプライアンス管理のために

ACORD 25（Certificate of Liability Insurance）は、100カ国以上、36,000以上の組織が採用する、北米建設業界における標準的な保険証明書です。中規模プロジェクトでも、40以上の下請け業者がそれぞれこの1枚の書類を提出します。多くのチームが行う管理業務（各PDFを開き、保険証券番号を目視確認し、スプレッドシートに入力し、補償限度額、有効期限、特約条項の確認を同様に行う）には、1枚あたり15～45分かかり、業界データによると、手動での保険データ入力エラー率は15～20％に上ります。

このエラー率は単なる非効率性の問題ではありません。追跡用スプレッドシートに記録された保険証書の約6枚に1枚は、証券番号が間違っていたり、有効期限が欠落していたり、フォーム上では確認済みでも実際には保険証券に添付されていない特約条項が含まれていることを意味します。そして、保険金請求が発生した場合（建設業における一般賠償責任保険の請求額は平均3万～7万5,000ドル、深刻なケースでは10万ドルを超えることもあります）、スプレッドシートが支払うわけではありません。本来あるべき保険が支払うかどうかは、誰かがExcelに入力した内容ではなく、実際の保険証券の内容に基づいて決まります。

ACORD 25データの抽出には、1枚ごとの料金と6か月の導入期間を要するエンタープライズ向けCOI管理プラットフォームは必要ありません。この記事では、ACORD 25のPDFの束を構造化されたExcelコンプライアンストラッカーに変換する、実用的な項目別抽出ワークフローを紹介します。このワークフローでは、AIが各フィールドの印刷位置ではなく、その意味を理解することでフォームを読み取ります。

ACORD 25の構成（コンプライアンス上、実際に重要な項目）

ACORD 25は一見シンプルな書類です。1ページ、標準化されたレイアウトで、建設業界なら誰もが知っているセクションで構成されています。しかし、どの項目がコンプライアンス上重要で、どの項目が単なる参考情報かを理解することは、会社を守るトラッカーと、誤った安心感を与えるだけのトラッカーの違いを生みます。

フォームはブロックごとに構成されています。上部にはPRODUCER（保険証券を発行した保険代理店またはブローカー）とINSURED（保険の対象となる下請け業者またはベンダー）があります。これらは、誰が保険を手配し、誰が保有しているかを示すもので、連絡先としては有用ですが、コンプライアンス上は重要ではありません。

その下のINSURER A～Fには、保険を提供する保険会社とそのNAIC番号が記載されています。NAIC番号は、すべての保険会社に割り当てられた固有の識別子であり、保険会社が合法的なものであり、ペーパーカンパニーではないことを確認する最も迅速な方法です。NAIC番号の欠落や誤りは危険信号です。

フォームの中核は、5つの保険種目を網羅するCOVERAGESセクションの表です。

各補償ラインについて、フォームには保険会社名、証券番号、開始日、満了日、および限度額（各事故および総合）が表示されます。また、重要なチェックボックスが2つあります — 追加被保険者 と 求償権放棄 — それぞれYまたはNで示されます。追加被保険者欄の「Y」は、このフォームで最も誤解されやすいシグナルです。これは、代理店が追加被保険者約款が存在すると主張していることを意味します。約款が実際に証券に追加されたことを意味するわけではありません。フォーム自体の下部に太字で警告があります：「証明書の受取人が追加被保険者である場合、証券には追加被保険者条項が含まれているか、裏書されている必要があります。この証明書の記載は、そのような裏書に代わる権利を証明書の受取人に付与するものではありません。」

補償グリッドの下にある 業務内容／場所／車両の説明 セクションは自由記述欄です。ここで代理店はプロジェクト固有の文言を追加し、追加被保険者を指名し、契約番号を参照し、そして重大なことに、証券が実際にはサポートしていない約束をすることがあります。保険業界のガイダンスは、証券に矛盾または拡張する文言をここに追加すると虚偽表示になると明示的に警告しています。コンプライアンス審査担当者はこのセクションを注意深く読む必要があります。

最後に、証明書受取人 ボックスには、証明書を要求し受領した者 — 通常は貴社 — が記載されます。解約 条項は、通知が「証券の規定に従って」行われると述べていますが、実際には通知が全くないことを意味することがよくあります。ACORD 25は、下請け業者の証券が解約された場合に保険会社が貴社に通知する義務を負わせるものではありません。唯一の信頼できる保護策は、積極的な満了日追跡です。

標準化されたフォームが、抽出の標準化を意味しない理由

ACORD 25は設計上標準化されています。それがACORDシステムの本質です。すべてのフォームは同じセクション構成、同じフィールドラベル、同じチェックボックス位置を使用します。では、なぜ従来のOCRでは単純に読み取れないのでしょうか？

それは、フォームは標準化されていても、記入内容は標準化されていないからです。

保険会社ごとに異なる代理店管理システムを使用してACORD 25を生成します。Applied Epicは日付をある形式で表示し、Vertaforeは別の形式で表示します。証券番号を正確なフィールド枠内に印刷する会社もあれば、枠をはみ出して印刷する会社もあります。ブローカーが直前の調整で記入する手書きの項目は、予測不能な位置に、判読性も様々な状態で現れます。業務内容の説明欄は、「別紙参照」の2語から、プロジェクト固有の詳細な3段落まで様々です。

テンプレートベースのOCR（多くの文書処理ツールに組み込まれている種類）は、ページ上の固定ゾーンを定義することで機能します。「証券番号は座標（x=400, y=280）にある」という具合です。別の保険会社のソフトウェアがそのフィールドを15ピクセルずらしたり、手書きのメモが補償範囲の表を0.5インチ押し下げたりすると、テンプレートは機能しなくなります。出力が文字化けしたり、セルが空白になったりして、節約したはずの時間は抽出エラーの修正に費やされます。

ここで、カスタム列抽出を使用するAI抽出は根本的に異なります。ツールにデータがページ上のどこにあるか（位置ベース）を指示する代わりに、何が欲しいか（意味ベース）を指示します。「一般賠償責任証券番号」「GL 1事故限度額」「追加被保険者約款フォーム」などの列名を入力するだけで、AIは各値がページ上のどこにあるか、どの保険会社が記入したかに関係なく、その意味を理解して特定します。フォームの位置がずれても、AIは気にしません。

この違いは、ACORD 25が通常、スキャンされたPDFやメール添付ファイルとして届き、元のデジタル原稿ではない場合に特に重要です。デスクトップスキャナによる傾き、メールによる圧縮アーティファクト、ブローカーのスタンプによるフィールドの部分的隠蔽は日常的に発生します。テンプレートベースのOCRはこれらのいずれでも失敗します。一方、座標マッピングではなく視覚的理解に基づいて訓練された意味ベースの抽出は、これらを通常の入力として処理します。

COIコンプライアンストラッカーに必要な12のフィールド

ACORD 25のすべてのフィールドをコンプライアンススプレッドシートに含める必要はありません。適切に設計されたトラッカーは、「もし明日この下請け業者に関連する保険金請求が発生した場合、補償は適用されるか？」という問いに答えるフィールドのみを抽出します。以下は抽出すべき12の列と、それぞれが取得する情報、そしてその重要性です。

契約書で必要になる場合に追加すべき2つの項目：プライマリー＆ノンコントリビュートリー条項 — 下請けの保険が自社のGL補償よりも先に支払われることを保証 — および証券受取人 — 自社が正しく記載されていることを確認。

この列リストを定義すれば、抽出ツールにトレーニング、テンプレート、ゾーン指定は不要です。列名を一度入力してテンプレートとして保存し、保険会社に関係なく、すべてのACORD 25に適用できます。

COI抽出からExcelへのワークフロー構築

以下が、ACORD 25 PDFのバッチを構造化されたExcelコンプライアンストラッカーに変換する、最初から最後までのワークフローです。

このワークフローは、PDFを開く→目でスキャン→Excelに入力→次のフィールドを確認、という手動サイクルを置き換えます。抽出がデータ取得を担当し、あなたはコンプライアンス判断に集中できます。そこにこそ、あなたの専門知識が真価を発揮します。

抽出データからコンプライアンスダッシュボードへ

抽出で得られるExcelファイルは構造化データです。各下請け業者が行に、各コンプライアンス項目が列に整理されています。この構造により、手動管理では不可能なスプレッドシート操作が可能になります。手動管理ではデータが異なるタブや形式、さらには誰かの受信箱に散在しているものです。

抽出したCOIデータをリアルタイムのコンプライアンスダッシュボードに変える、3つのExcelパターンを紹介します。

条件付き書式による有効期限アラート。有効期限列を選択します。条件付き書式ルールを適用します。30日以内の日付はセルを赤色に、31～60日以内は黄色に設定します。この列で降順に並べ替えると、保険が最も早く期限切れになる下請け業者が上位に表示されます。カレンダーリマインダーや、保険が失効してから始めるメール追跡は不要です。

ピボットテーブルによる補償範囲のギャップ検出。ピボットテーブルを作成し、行に下請け業者名、列に補償タイプ、値に保険証券番号を設定します。空白のセルは、その下請け業者がその補償を完全に欠いていることを意味します。週6日現場で作業しているのに労災補償がない下請け業者は、監査の時限爆弾です。ピボットテーブルがあれば数秒で発見できます。

フィルター列による裏書確認。「AIステータス」というヘルパー列を追加し、次の数式を入力します: =IF(AND([AI裏書フォーム番号]="", [追加被保険者]="Y"), "未確認—裏書依頼", IF([AI裏書フォーム番号]="", "AI未請求", "確認済み"))。これにより、追加被保険者欄にチェックがあるのに裏書フォーム番号が抽出されていない証明書をすべてフラグ付けします。まさに、COIのチェックボックスに裏付けとなる保険証券文言がないために保険金請求が却下されるシナリオです。

30以上の下請け業者を管理するチームにとって、これら3つのExcelパターンでコンプライアンス監視の90%をカバーできます。抽出ワークフローがクリーンなデータを供給し、ダッシュボードパターンがリスクを表面化します。自動化できない人間によるレビュー工程は、フラグが立った項目に集中でき、保険証券番号の再入力に時間を取られることはありません。

Google Sheetsで作業する場合も、Excelと同じパターンが適用され、条件付き書式やピボットテーブルの機能も同一です。30社から200社への下請け業者増加において、スプレッドシート本来のアプローチが特に効果を発揮します。新しいプラットフォームを学ぶ必要はなく、既存のワークフローにデータを追加するだけで済みます。

ACORD 25データ抽出 vs. 本格COI管理プラットフォーム：使い分けの基準

ここで当然の疑問が浮かびます。専用のCOI管理プラットフォームが存在し、実際に優れた機能を備えているのに、なぜ抽出→Excel方式を使うのでしょうか？

答えは、コンプライアンス成熟度の段階によって異なります。

ACORD 25からExcelへの抽出が適しているケース： 管理する下請け業者が10～80社で、活動中のプロジェクトが数件程度。コンプライアンス審査を社内のプロジェクト管理者やリスク担当者が担当し、契約要件を理解した上でグレーゾーンを判断できる場合。必要なのは、フォームからデータを取得して構造化する抽出機能であり、自動更新の追跡、多段階承認ワークフロー、ERP連携は不要な場合。現在の課題は、追跡基盤ではなく、データ入力作業そのものです。

本格COI管理プラットフォーム（myCOI、Jones、bcs、TrustLayer、SmartCompliance）が適しているケース： 管理する下請け業者が200社以上で、プロジェクトも数十件に及び、コンプライアンス要件がプロジェクト、職種、発注者契約ごとに異なる場合。自動更新ワークフロー、下請け業者セルフサービスポータル、Procore、Sage、CMiCとの直接連携が必要な場合。この規模になると、たとえ抽出データがあっても、手作業による審査の管理負荷がボトルネックになります。プラットフォームはワークフローを、抽出はデータ取得を担当します。

重要なポイント：抽出とコンプライアンス管理は別機能であり、同一ベンダーから提供される必要はありません。現在は軽量ツールでACORD 25データを抽出し、Excelでコンプライアンスダッシュボードを構築できます。後日スプレッドシートでは対応できなくなった場合でも、蓄積された構造化データはどのプラットフォームにも問題なくインポートできます。抽出はプラットフォーム選定を縛るものではなく、将来の基盤に先送りすることなく、今日の問題を解決します。

このアプローチが埋めるギャップは、多くの記事が見落としているものです。つまり、手動データ入力の非効率性を認識しつつも、予算、規模、組織的な準備の面で、エンタープライズCOIプラットフォームを導入する段階にない建設チーム向けです。COIデータ抽出を自動化することは、コンプライアンスワークフロー全体を自動化することなく実現でき、同じ列ベースの抽出アプローチはACORD 25以外のCOI形式でも機能します。

コンプライアンス追跡の失敗がもたらす影響について詳しくは、建設業におけるCOI非遵守の実際のコスト（保険料の再計算から請求拒否まで）を具体的な数字でご確認ください。

よくある質問

AI抽出はACORD 25書式の手書き入力を処理できますか？

はい。ビジョンモデルに基づく最新のAI抽出は、同じ書式上の印刷テキストと手書き（筆記体を含む）の両方を読み取ります。これはACORD 25にとって重要です。なぜなら、ブローカーが頻繁に修正を手書きで記入したり、ペンで保険証券番号を追加したり、余白に補償内容の注釈を記入したりするからです。機械印刷テキストのみを読み取る従来のOCRでは、これらの記入を完全に見逃します。ビジョンベースのAIは手書きを文書画像の一部として扱い、印刷テキストと同じ方法で読み取ります。明確な手書きの精度は印刷テキストと同等です。装飾的な筆記体や圧縮率の高いスキャンでは信頼性が低下する可能性があり、手動での確認が必要になる場合があります。

抽出ツールはCG 20 10やCG 20 37の約款フォーム番号を識別できますか？

はい。約款フォーム番号が証明書に記載されているか、業務内容の説明欄に含まれている場合に可能です。多くのブローカーは業務内容の説明欄に「CG 20 10 (04/13)、CG 20 37 (10/01)」と入力します。抽出ツールはこれをテキストとして読み取り、指定された列に抽出します。ただし、証明書に約款フォーム番号が表示されていても、その約款が実際に保険証券に添付されていたことを保証するものではありません。ACORD 25自体が、証明書の記載は権利を付与するものではないと警告しています。高リスクの下請け業者や厳格な所有者要件があるプロジェクトの場合は、証明書に加えて実際の約款ページの写しを請求してください。

これはACORD 25抽出におけるABBYY Vantageや他のエンタープライズIDPツールと比べてどうですか？

ABBYY VantageのようなエンタープライズIDP（インテリジェント文書処理）プラットフォームは、ACORD 25用のトレーニング済み抽出スキルを提供していますが、根本的に異なるモデルで動作します。ABBYYのACORD 25スキルは「プレビュースキル」と説明されており、「本番環境で使用する前に、特定の文書に対するさらなるトレーニングが必要になる場合があります」とされています。これは本質的にテンプレートベースの抽出です。つまり、サンプル文書でトレーニングされたモデルであり、形式が異なる場合は再トレーニングが必要です。テンプレート不要のAI抽出はトレーニングステップを完全にスキップします。列名を定義すれば、AIが各文書を新たに読み取り、サンプルセットは不要です。記入スタイルが異なる数十の保険会社からのACORD 25を処理するチームにとって、テンプレート不要のアプローチは、テンプレートベースのツールが時間の経過とともに蓄積するトレーニング保守の負担を回避します。

下請け業者が非ACORD 25のCOI（保険者固有様式や旧版ACORD）を送ってきた場合は？

テンプレート不要の抽出は、フィールドを位置ではなく意味で特定するため、あらゆるCOI形式に対応します。レイアウトの異なる保険者固有の証明書、フィールド配置が異なる2016年以前のACORD 25改訂版、さらにはACORD 27（財産保険の証拠書類）でも、AIが文書内容を読み取り、指定された情報を見つけ出します。標準的なACORD 25用に定義した列名は、非標準形式でも修正不要で機能します。これがテンプレートマッチングに対する意味ベース抽出の実用的な利点です。保険者ごとに異なる様式のテンプレートを個別に管理する必要はありません。

抽出データはコンプライアンス判断に直接使用できる精度ですか？

ACORD 25様式の印字テキスト（証券番号、日付、保険者名、限度額）は、AI抽出で最大99%の精度を達成します。人間による確認が推奨される領域は次の通りです。(1) 業務内容の自由記述欄（複雑な約款追補文言は文脈解釈が必要な場合あり）、(2) 手書き入力（判読性により信頼度が低下する可能性あり）、(3) 追加被保険者チェックボックス（常に約款追補番号列と相互参照すべき）。抽出ツールは抽出データと元のPDF画像を併せて保持するため、特定フィールドの確認はワンクリックで比較可能です。元のファイルを開き直す必要はありません。

ACORD 25のデータをExcelではなくGoogleスプレッドシートに直接抽出できますか？

はい。Googleスプレッドシートアドオンを使用すると、スプレッドシート内からACORD 25のPDFをアップロードし、抽出列を定義して、結果をアクティブシートに直接追加できます。ファイルのエクスポートやインポートの手順は不要です。これは、コンプライアンス追跡をすでにGoogleスプレッドシートで行っており、抽出結果を既存のワークブック構造に直接取り込みたい場合に便利です。同じ列名テンプレートシステムが、Webインターフェースとスプレッドシートアドオンの両方で機能します。