200件のCOIを1枚のスプレッドシートに
保険限度額と有効期限を一括検証
中堅ゼネコンが80社の下請け業者を抱え、賠償責任、自動車、労災、包括保険で約350件の保険証明書を管理。それぞれ有効期限も、プロジェクト・職種・発注者ごとに求められる契約限度額も異なります。従来の方法——各PDFを開き、補償範囲を確認し、限度額をスプレッドシートに入力し、契約と照合する——には1件あたり10~15分かかります。四半期ごとの更新ラッシュで200件のCOIが届けば、手作業のコンプライアンス審査に33~50時間。疲労が積み重なるほどエラー率も跳ね上がります。
重要ポイント
- すべてのCOIを保管していても、下請け業者のコンプライアンスが万全とは限りません。
- IRMIのデータによると、証明書の10件中9件が契約上の保険仕様を満たしていません。それは誰かの過失ではなく、同じ補償範囲を40回も読めば人間の注意力が途切れるからです。
- COIの検証を目視で行うのはやめましょう。200件すべてを1枚のスプレッドシートに抽出し、条件ルールを10個一度だけ設定すれば、不適合行が数秒で自動フラグされます。
33~50時間という数字の背景には、控えめな見積もりがあります。IRMIによる請負業者保険プログラムの監査では、提出された保険証券の10件中9件以上が、元の契約書に定められた保険仕様を満たしていないことが判明しました。しかし、ファイル上のすべての証券は完全に準拠しているように見えました。業界のデータ自体が、手作業のプロセスではギャップを捉えきれていないことを示しています。では、フルタイムのコンプライアンス担当者を雇ったり、200以上のベンダーに対して証券ごとのSaaS料金を支払ったりせずに、実際にそれらを大規模に捕捉するにはどうすればよいのでしょうか。
この記事では、実用的な一括検証ワークフローを説明します。すべてのACORD 25を1つのスプレッドシートに抽出し、不適合な証券を自動でフラグ付けする条件付きルールを適用し、プロジェクト監査で見つかる前に、どの下請け業者が対応を必要としているかを示すコンプライアンスダッシュボードを生成します。単一の証券抽出の基本(どのフィールドを取得するか、ACORD 25フォームの構造、セマンティックAIが保険会社間のフォーマットの違いをどのように処理するか)については、ACORD 25 COIデータをExcelに抽出するガイドをご覧ください。この記事では、その抽出機能があることを前提とし、それを200の証券に同時に適用した場合に何が変わるかに焦点を当てます。
一括検証のギャップ:COI1件あたり10分ではスケールしない理由
1つのプロジェクトで10の下請け業者を管理する場合、手動でのCOI検証は機能します。各業者を名前で把握し、どれが200万ドルの包括保険を持ち、どれの労災保険が3月に期限切れになるかを覚えています。Open-PDF-Scan-Typeのサイクルは1件あたり10分かかりますが、10件なら2時間未満で、業務時間内に収まります。
50の下請け業者になると、ほころびが見え始めます。複数の保険契約を持つ業者もいれば、プロジェクトの途中で更新し、以前のバージョンと比較する必要がある新しい証券を送ってくる業者もいます。手書きの調整が加えられたACORD 25を発行する保険会社もあり、読むのに時間がかかります。COI1件あたりの時間は15分に近づきます。そして、200以上になると(ほとんどの地域のゼネコン、大規模な不動産管理者、エンタープライズ建設会社が運営する規模)、計算は破綻します。200件 × 12分 = 2,400分、つまり40時間です。まるまる1週間の労働です。そして、これはたった1回の四半期サイクルにすぎません。
より厄介な問題は時間ではなく、一貫性の欠如です。47件目のCOIをチェックするとき、あなたの目は同じ補償範囲グリッドを47回目で読んでいます。50万ドルの1事故あたりのGL限度額が100万ドルに見えるのは、どちらも数字で始まりゼロが続くからです。2026年8月15日満期の保険が、2025年8月15日と入力されています。追加被保険者のチェックボックスに「Y」とマークされていても、CG 20 10 承認が実際に添付されているかどうかは確認されません。IRMIが見つけた10件中9件の失敗率は、過失によるものではなく、大量処理における人間の注意力の限界によるものです。
これが一括検証のギャップです。「1つのCOIを注意深くチェックできる」と「200のCOIを一貫してチェックできる」の間の距離です。これを埋めるには、ワークフロー自体を変更する必要があります。つまり、各文書の人間によるレビューから、自動抽出とそれに続くルールベースのコンプライアンスチェックへと移行することです。
一括検証で実際にチェックされる6つの観点:カバレッジ表だけでは不十分
自動化の前に、「検証済み」の正確な定義が必要です。一括コンプライアンスチェックに合格したCOIは、単に「カバレッジが記載されている」だけでなく、6つの観点にわたる具体的で測定可能な基準を満たしています。これらは条件エンジンが評価するルールです。
| 観点 | ルールの内容 | 閾値の例 | 非準拠フラグ |
|---|---|---|---|
| 1. カバレッジ種別の有無 | 必要な補償種目(GL、自動車、労災、アンブレラ)がすべて記載されているか | 最低限:GL+労災+自動車(請負業者が現場で運転する場合) | 「労災なし」 |
| 2. 包括賠償責任(GL)の限度額 | 1事故限度額と総合限度額が契約の最低要件を満たしているか | 1事故100万ドル/総合200万ドル | 「GL限度額が100万ドル/200万ドル未満」 |
| 3. アンブレラ/超過限度額 | アンブレラが記載され、GLおよび自動車にフォロー・フォームで適用されるか | 最低200万ドル(Certificialベンチマークによるプログラムの60%) | 「アンブレラなし、または200万ドル未満」 |
| 4. 保険期間 | 保険が現在有効か、失効しているか、30日以内に失効するか | 保険満了日>本日;30日以内の場合はフラグ | 「失効」、「あと15日で失効」 |
| 5. 追加被保険者(AI)の特約 | CG 20 10(継続作業)とCG 20 37(完了作業)が記載されているか | 両方のフォーム番号がCOIまたは添付の特約ページに存在すること | 「CG 20 37なし」 |
| 6. 証券保管者と解約通知 | 自社が証券保管者として記載されているか、解約通知が30日以上前であるか | 正しい法人名;30日以上の通知期間が明記されていること | 「証券保管者誤り」、「解約通知なし」 |
これら6つの観点は、すべてのコンプライアンス審査担当者が頭の中で、1枚のCOIずつ確認するチェックリストです。一括アプローチでは、各観点をスプレッドシートの数式に変換し、すべての行を同時に評価します。1人の担当者が1度ルールを作成すれば、200枚のCOIを数秒で評価できます。
いくつかの注意点があります。追加被保険者のステータスは特に注意が必要です。これはACORD 25で最も誤解されやすい項目だからです。フォーム自体に太字で、「AI欄のチェックマークは、特約に代わる権利を証券保管者に付与するものではない」と警告されています。実際の特約(通常、継続作業にはCG 20 10、完了作業にはCG 20 37)は、保険に添付された別個の文書でなければなりません。準拠した一括検証プロセスは、追加被保険者欄の「Y」をチェックするだけではありません。特約フォーム番号が業務内容欄または添付のACORD 101明細書に記載されているかを確認します。IRMIのCOIガイダンスは明確です。証券はカバレッジの証拠であり、カバレッジを付与する契約ではありません。それを実現するのは特約だけです。
解約通知は、契約書に求められる以上に書式の文言が重要な領域です。2010年以降、標準的なACORD 25の解約条項には「通知は保険契約の規定に従って行われる」と記載されており、保険会社は保険契約に既に定められている以上の義務を負わず、保険契約自体も証明書保有者への通知について何も規定していないことが多いです。30日解約通知特約(「解約通知特約」や「NOC特約」とも呼ばれます)は、保険契約への別途の追加条項であり、ACORD 25自体が提供するものではありません。契約で30日間の通知が求められる場合、その文言が業務内容の説明欄に記載されていることを最低限確認し、実際の特約が存在することを確認することがゴールドスタンダードです。
ステップ1:すべてのCOIを1つのスプレッドシートに抽出する
バッチ処理のワークフローは抽出から始まります。200のPDFを1つの構造化されたスプレッドシートに変換します。このステップで多くのチームが停滞します。200のACORD 25からの手動データ入力は遅いだけでなく、正確性が最も重要となる瞬間に転記ミスを引き起こします。
代替手段は、カスタム列抽出を使用したAI駆動の抽出です。出力したい列を定義すると、AIが各ACORD 25のPDFを読み取り、対応する値を見つけます。テンプレートに一致させたり、ページ上の固定位置を確認したりするのではなく、各フィールドの意味を理解することで実現します。「GL 1事故あたりの限度額」や「アンブレラ保険証券の満期日」などの列名を入力すると、AIは保険会社の代理店管理システムに関係なく、フォーム上のどこからでもそれらの値を見つけ出します。
この意味論的アプローチ(フィールドの位置ではなく意味を理解する)により、バッチACORD 25抽出は信頼性が高まります。Applied Epic、Vertafore、その他の代理店管理システムでは日付の形式が異なります。一部の保険会社は証券番号をフィールド境界を越えて印刷します。手書きのブローカー調整は予測不能な位置に現れます。位置ベースのテンプレートは、これらのバリエーションのいずれかで失敗します。意味論的抽出は値がどこにあるかを気にしません。ドキュメントを読み取り、要求されたものを取得します。
以下は、コンプライアンス重視のバッチ抽出用に定義する列セットです。これらの14列は、条件付きルールが評価するすべての側面を捉えます。
| 列名 | 抽出内容 | コンプライアンスチェックでの役割 |
|---|---|---|
| 下請業者名 | ACORD 25ヘッダーの被保険者名 | このCOIがどの下請業者に属するかを特定 |
| GL保険会社 | 事業一般賠償責任の保険会社名 | 保険会社がA格以上かを確認(AM Best参照) |
| GL証券番号 | GL補償明細の証券番号 | クレーム参照用の一意の識別子 |
| GL 1事故限度額 | GL行の1事故あたりの限度額 | 契約最低額(通常100万ドル)と比較 |
| GL総合一般限度額 | GL行の総合限度額 | 契約最低額(通常200万ドル)と比較 |
| GL証券満期日 | GL補償明細の満期日 | 有効か?間近か?既に失効か? |
| 自動車賠償責任限度額 | 自動車行の総合単一限度額 | 通常100万ドル。現場で車両を使用するか確認 |
| アンブレラ限度額 | アンブレラ/超過行の1事故限度額 | 契約要件(通常200万ドル以上)と比較 |
| 労災保険ステータス | 労災補償の有無と法定限度額 | 適用除外州の個人事業主以外は必須 |
| 追加被保険者特約 | CG 20 10、CG 20 37、CG 20 33、または包括的AI文言 | 継続作業(CG 20 10)と完了作業(CG 20 37)の両方を確認 |
| 求償権放棄 | 求償権放棄チェックボックス列の有無 | 契約で要求されているのに「無」または空白の場合にフラグ |
| 証券受取人 | 証券受取人欄の法人名 | 自社の正式な法人名と完全一致する必要あり |
| 解約通知 | 業務内容または解約セクションの通知日数 | 30日未満または未記載の場合にフラグ |
| 業務内容 | 業務内容フリーテキスト欄の全文 | プロジェクト固有の文言、契約番号、特別条件を目視確認 |
COI抽出の概要(契約抽出、特約確認、複数文書タイプにわたるコンプライアンス追跡との連携を含む)については、COI抽出の完全ガイドをご覧ください。
これらの列を定義したら、200件のACORD 25 PDFを一度にアップロードしてください。AIが並行処理し、結果を1つのスプレッドシートに出力します。各下請業者が1行、指定した各フィールドが1列になります。この抽出ステップにより、Open-PDF-Scan-Typeのサイクルは不要になります。以降、コンプライアンスレビューはPDFではなくスプレッドシート上で行います。
ファイルは安全に処理され、保存されません。
この抽出ステップで得られる出力は、生のコンプライアンスデータセット(200行×14列の構造化データ)です。次のステップでは、その生データを実用的なコンプライアンスインテリジェンスに変換します。
ステップ2:条件ルールを構築して非準拠を検出する
抽出はデータを提供します。条件ルールは判断を提供します。目標はシンプルです。スプレッドシートの各行を3つのカテゴリのいずれかに分類することです。準拠、非準拠(即時対応が必要)、またはレビューが必要(人間の判断が必要な境界ケース)です。
ExcelやGoogleスプレッドシートでこれらのルールを設定するのにプログラミングは不要です。各ルールは、特定のセルをしきい値と照合してフラグを返す条件式です。行にフラグが蓄積されると、エスカレーションされます。以下が、次元ごとに構築されたルールセットです。
| ルール# | 次元 | 条件ロジック | フラグ出力 |
|---|---|---|---|
| 1 | GL 1回あたり | IF GL_Each_Occurrence < 1000000 | "GLが100万ドル未満" |
| 2 | GL総合一般 | IF GL_General_Aggregate < 2000000 | "GL総合が200万ドル未満" |
| 3 | アンブレラ限度額 | IF Umbrella_Limit < 2000000 | "アンブレラが200万ドル未満" |
| 4 | 保険満期 | IF GL_Expiration < TODAY() | "満期済" |
| 5 | 保険満期(間近) | IF GL_Expiration <= TODAY()+30 | "あと[N]日で満期" |
| 6 | 労災保険 | IF WC_Status = "" OR WC_Status = "N/A" | "労災保険なし" |
| 7 | 追加被保険者 | IF AI_Endorsement NOT CONTAINS "CG 20 10" | "CG 20 10なし" |
| 8 | 追加被保険者(完了業務) | IF AI_Endorsement NOT CONTAINS "CG 20 37" | "CG 20 37なし" |
| 9 | 証券保管者 | IF Cert_Holder <> "Your Company Legal Name" | "証券保管者が誤り" |
| 10 | 解約通知 | IF Cancellation_Days < 30 | "解約通知期間不足" |
実際には、これらをスプレッドシートの追加列として実装します。各行のトリガーされたルール出力をすべて連結する「フラグ」列を作成します。次に、簡単な数式で「ステータス」列を作成します。
=IF(Flags="","COMPLIANT",IF(OR(ISNUMBER(SEARCH("EXPIRED",Flags)),ISNUMBER(SEARCH("Missing",Flags))),"NON-COMPLIANT","REVIEW"))この数式を使えば、PDFを1つも開かずに全データを3つのカテゴリに分類できます。フラグがなくクリーンなCOIは「準拠」。保険期限切れ、必要な補償の欠落、契約基準未満の限度額があるものは「非準拠」に振り分けられます。グレーゾーン(例:境界線上のアンブレラ限度額や、CG 20 33に言及しているがCG 20 10ではないAI条項など)は「要確認」として人間の判断に回されます。
重要な注意点:これらのルールは、あくまで証明書に記載されている内容を評価するものであり、必ずしも保険証券の実態を評価するものではありません。この違いは重要です。CG 20 10とCG 20 37が「業務内容の説明」欄に記載された200万ドルのアンブレラを示すACORD 25は、すべての自動チェックを通過します。しかし、元の保険証券が実際にそれらの裏書を保有していなければ、証明書は誤解を招くものとなります。これこそがIRMIの「10件中9件」という統計が存在する理由です。日常業務を行う低リスクの下請け業者には、自動化されたCOIレベルの検証で十分です。構造、掘削、屋根工事を行う高リスク職種については、裏書レベルの検証(CG 20 10およびCG 20 37の裏書ページの実際のコピーを請求)で補完してください。
ステップ3:コンプライアンスダッシュボードの作成
200行にフラグとカテゴリが付けられても、生のスプレッドシートは依然として情報過多です。コンプライアンスダッシュボードは、プロジェクトマネージャーやリスク委員会が実際に必要とする3つの数値(完全準拠している下請け業者の数、対応が必要な問題を抱える業者の数、最も一般的なギャップは何か)に情報を凝縮します。
最もシンプルなダッシュボードはピボットテーブルです。「ステータス」列(COMPLIANT / NON-COMPLIANT / REVIEW)を行に設定し、下請け業者名のカウントを値に設定します。以下のような結果が得られます:
| ステータス | 件数 | 全体比 |
|---|---|---|
| 準拠 | 142 | 71% |
| 非準拠 | 38 | 19% |
| 要確認 | 20 | 10% |
これが全体像です。現在、下請け業者の71%が準拠、19%が現場に入る前に解決すべき問題を抱え、10%がより詳細な確認を必要としています。ダッシュボードの次の層では、非準拠グループをさらに掘り下げ、38件のフラグ付き証明書の原因となっている具体的なギャップを明らかにします:
| 非準拠の理由 | 件数 |
|---|---|
| 保険期限切れ | 14 |
| GL限度額が100万ドル/200万ドル未満 | 9 |
| CG 20 37(完了業務)の欠落 | 11 |
| 労災保険の欠落 | 6 |
| 証明書受取人の誤り | 5 |
| 解約通知期間の不足 | 3 |
この第2層は、どこに労力を集中すべきかを示します。最も一般的な問題が保険期限切れであれば、限度額の再交渉ではなく、更新リクエストの送信に注力します。CG 20 37の欠落がパターンであれば、その内容と必要性を説明するテンプレートメールを送信します。ダッシュボードは、「確認すべきCOIが200件ある」という状況を、「追跡すべき期限切れ保険が14件、より高い限度額が必要な下請けが9社、完了業務裏書を追加する必要がある業者が11社」という管理可能なアクションリストに変えます。もはやPDFの山ではありません。
チームでプロジェクトマネージャーとコンプライアンス状況を共有する必要がある場合、シンプルな条件付き書式設定レイヤーを追加するだけで、ダッシュボードがひと目で読み取れるようになります。準拠している協力会社は緑、非準拠は赤、30日以内に期限切れとなるものは黄色で表示。プロジェクト、職種、コンプライアンスのギャップでフィルタリング可能。200社の協力会社に拡大しても、コンプライアンスに比例して時間を費やす必要はありません。ルールを設定した後は、証明書1件あたりの時間がほぼゼロに近づくシステムを構築することを意味します。
四半期リズム:COI一括検証が一度きりのプロジェクトではなく反復プロセスである理由
保険証券は毎年更新されますが、協力会社の更新日はすべて同じではありません。80社の協力会社がいるゼネコンでは、毎週新しい証明書や更新された証明書が届き、契約更新やプロジェクトフェーズの移行がある四半期ごとに急増します。この反復的なリズムこそが、COIコンプライアンスにおいて一括処理を自然なワークフローにする理由です。
3つの反復サイクルを設定します。
毎週の取り込み。協力会社から新しいCOIが届いたり、更新後に更新された証明書が届いたりしたら、実行中のバッチに追加します。新しいファイルを同じ14列のテンプレートに対して抽出すれば、既存のスプレッドシートに直接組み込めます。条件付きルールは自動的に発動します。最初からやり直すのではなく、追加していくのです。
四半期ごとの完全監査。四半期に一度、全協力会社リストに対して完全な一括検証を実行します。すべての稼働中の協力会社を抽出し、過去90日以内に保険が期限切れになった会社には更新されたCOIを要求し、すべてを再抽出します。このサイクルで、9割のギャップ(各COIを個別に提出した数ヶ月前には見えなかったが、200行すべてを並べて比較すると見えてくるギャップ)を発見します。
プロジェクト着手前の確認。協力会社が現場に着手する3週間前に、コンプライアンスダッシュボードから該当行を抽出します。ステータスが「準拠」以外の場合は、プロジェクトマネージャーにフラグを立てます。COI非準拠のコスト(1日平均3,500ドルのプロジェクト遅延、カバーされない賠償責任請求、監査による回収)は、着手予定日の当日ではなく、着手の3週間前にギャップを発見すれば完全に回避可能です。
ステップ2とステップ3で構築したスプレッドシートは、一度きりの成果物ではありません。それは、協力会社ベースとともに成長し、問題を修正可能なタイミングで発見する、生きたコンプライアンス記録なのです。
バッチ自動化の限界と、人間の判断が不可欠な領域
自動バッチ検証は強力ですが、ACORD 25フォーム上で確認できる情報に基づいて動作します。自動化だけでは埋められないギャップが存在し、それを事前に理解しておくことで、誤った安心感を防げます。
手書きや非標準の証明書。一部の保険会社、特に小規模な下請け業者を扱うブローカーが手動調整を行う場合、ACORD 25が部分的に手書きで発行されることがあります。AI抽出はテンプレートOCRよりも手書きの処理に優れていますが、機械印字のフォームと比較すると精度は低下します。このような場合は、まずバッチ抽出を行い、フラグが立った行を手動でレビューしてください。AIはほとんどの項目を正しく抽出しますが、手書きの証券番号やブローカーの余白メモを見逃す可能性があります。
裏書文言の解釈。抽出ツールは「CG 20 10」が証明書に記載されているかどうかを確認できます。しかし、実際の裏書ページを読み取り、その文言が特定のプロジェクト範囲をカバーしているかどうか、あるいはパラグラフ4に埋め込まれた免責条項が補償を無効にしていないかどうかを判断することはできません。構造用鉄骨、掘削、屋根工事、解体工事などの高リスク業種では、条件ルールによって「要確認」フラグを発動し、保険知識を持つ担当者に証明書を回付する必要があります。ルールは200件の山を、専門家の読解が必要な20件程度に絞り込みます。専門家を代替するものではありません。
ポリシーレベル vs プロジェクトレベルの総額。ACORD 25の「一般総額限度額の適用単位」欄には、「ポリシー」「プロジェクト」「ロケーション」の3つの選択肢があります。ポリシー単位で適用される200万ドルの総額は、下請け業者が請け負う全プロジェクトをカバーします。その業者があなたの3つのプロジェクトで作業している場合、プロジェクトAでの1件のクレームがプロジェクトBの補償額を減少させます。プロジェクト単位の総額であれば、各プロジェクトに独自の200万ドルの限度額が設定されます。条件ルールで「ポリシー単位の総額」を確認項目としてフラグ付けできますが、それを受け入れるかどうかの判断は、あなたのリスク許容度と下請け業者のプロジェクト負荷に依存します。
バッチ検証は「ルールを設定して放置」ではありません。「ルールで日常的な80%を処理し、人間が判断を要する20%に集中できるようにする」ことです。IRMIの統計(COIの10件中9件が契約仕様を満たさない)は、人間が日常的な80%を手動で処理しようとして、判断を要する20%にまで手が回らない状況を反映しています。この配分を逆転させることが目的です。
スプレッドシートルール vs. COI管理ソフト:それぞれの適切な使い分け
前のセクションでは、スプレッドシートベースの条件ルール手法について説明しました。チームによっては、専用のCOI管理ソフトウェア(Billy、Jones、myCOI、CertFocus)が適切な選択肢です。違いは品質ではなく、取扱量と複雑さにあります。
AI抽出を活用したスプレッドシートベースのワークフローは、20~200社の下請け業者を管理し、証明書ごとの課金(ベンダー1社あたり年間3~30ドルがすぐに膨らみます)や6か月の導入期間を避けたい場合に適しています。抽出はバッチごとに1回行われ、ルールは自動実行され、ダッシュボードはリアルタイムで更新されます。総コストは抽出のためのAI処理クレジットのみであり、ベンダーごとのサブスクリプションは不要です。
専用のCOIソフトウェアは、複数のプロジェクトにわたって500社以上の下請け業者を管理する場合、ProcoreやCMiCとの統合が必要な場合、または更新時の自動ベンダーフォローアップを希望する場合に適しています。これらのプラットフォームは、組み込みワークフロー(有効期限の60日前に下請け業者に自動メール送信、セルフサービスでのCOIアップロードが可能なベンダーポータル維持、エンタープライズコンプライアンス要件のための監査証跡レポート提供)を通じて付加価値を提供します。ただし、コストと複雑さも増加し、ほとんどの場合、営業電話、年間契約、専任のオンボーディングが必要です。
多くの中堅ゼネコンにとって現実的な道筋は、ここで説明したスプレッドシートベースのバッチワークフローを実行し、自動ベンダーフォローアップによる節約時間がプラットフォームコストを上回る取扱量に達した場合にのみ、専用ソフトウェアに移行することです。条件ルールとコンプライアンスの次元はどちらも同じであり、変わるのは提供メカニズムだけです。
よくある質問
バッチ抽出は、異なる保険会社の異なるレイアウトのCOIに対応できますか?
はい、抽出は位置ベースではなく意味ベースで行われるため可能です。AIは「一般賠償 各事故」を読み取り、ある保険会社では(x=400, y=280)、別の保険会社では(x=415, y=295)に印刷されていても、対応する金額を見つけます。一部の保険会社が生成するACORD 25では、補償範囲のグリッドが半インチずれたり、保険証券番号が2行にまたがったりすることがあります。これらのバリエーションは正常であり、再設定なしで処理されます。唯一の例外は、まったく異なるフィールドラベルを使用する非ACORDの保険会社発行の証明書です。その場合は、まず少量のテストバッチを実行し、AIが正しい値を認識していることを確認してから、全件を処理してください。
このワークフローで200件のCOIを抽出・確認するにはどのくらい時間がかかりますか?
抽出自体はCOI1件あたり5~10秒で、バッチアップロードと処理の合計は約15~30分です。14の列と10の条件ルールの設定には初回約45分かかります。その後は、四半期ごとのサイクルは1時間未満で完了します。抽出に30分、ルール評価(数式が設定されていれば自動実行)に15分、人間の判断が必要とフラグが立てられた約20件のCOIの確認に15分です。手動でのアプローチ(Open-PDF-Scan-Type方式)では、サイクルごとに33~50時間かかっていたのと比較してください。
下請け業者のCOIが2010年以前のACORD 25フォームバージョンを使用している場合はどうなりますか?
データフィールド(被保険者名、補償範囲グリッド、限度額、日付、証明書取得者)は同じですが、レイアウトが若干異なる場合があります。特に解約通知文言で違いが見られます(古いフォームでは「__日間の書面通知を送付するよう努める」と記載されていましたが、現在は「保険契約条項に従う」となっています)。意味ベースの抽出はフォームのバージョンではなくフィールドの意味を読み取るため、どちらも処理できます。解約通知の抽出列には表示されている文言がそのまま取得されるため、条件ルールで評価できます。
このワークフローで包括型追加被保険者追認は検証できますか?
部分的に可能です。包括型追加被保険者追認は通常、書面契約で追加被保険者として追加することに同意した事業体を自動的にカバーすると規定しています。ACORD 25の業務内容欄にこの文言が記載されている場合があります(例:「書面契約に基づく包括型追加被保険者」)。抽出ツールでそのテキストを取得できます。ただし、包括文言が適切に機能するかどうかの検証には、次の2つの存在確認が必要です。(1) 保険証券内の包括追認、(2) 貴社と下請け業者間の、追加被保険者ステータスを要求する書面契約。条件ルールで包括文言を含むCOIにフラグを立てて人間によるレビューを促すことはできますが、書面契約の存在を独立して検証することはできません。それが判断を要する20%の部分です。
ACORD 25フォームのAI抽出精度はどの程度ですか?
標準的な機械印字のACORD 25フォームでは、証券番号、日付、金額など明確に印字された項目で99%以上の精度を達成します。中小の地域ブローカーが発行する証明書では手書き記入が依然として一般的であり、手書き部分の精度は約90~95%に低下します。自由記述で複数段落に及ぶこともある業務内容欄では、出力に軽微な書式の違い(改行、句読点)が生じる可能性がありますが、内容は確実に抽出されます。コンプライアンス上重要な項目については、バッチワークフローの効率性は、200のPDFを読んで手入力する代わりに、抽出データをスプレッドシートで確認し、200行をスキャンしてフラグをチェックできる点にあります。
200のPDFから、ひとつの実用的なコンプライアンスレポートへ
「COIをファイルに保管している」と「どれがコンプライアンスに準拠しているか把握している」の間には、多くの建設チームが認識する以上に大きなギャップがあります。IRMIの調査結果——10件中9件の証明書が一見準拠しているように見えて契約条件を満たしていない——は、請求対応を経験したリスクマネージャーなら誰でも知っている事実を数値化しています。ACORD 25フォームは証拠であって、保護ではありません。検証のない証拠は単なる書類です。規模を拡大した検証には、200回の繰り返しに人間の注意力が耐えられるかに依存しないプロセスが必要です。
3ステップのワークフロー——全COIを1つのスプレッドシートに抽出し、全行に同時に条件ルールを適用し、準拠しているものと対応が必要なものを分けるダッシュボードを生成する——は、40時間の手動サイクルを1時間未満の定期プロセスに変えます。一度作成したルールは、来週も来四半期も届く新しい証明書すべてを評価します。変わるのはリスク顕在化のタイミングです。請求が既に提出された後に補償のギャップを発見するのではなく、ダッシュボードのフラグが立った行でそれを確認し、修正する時間があります。
お手持ちのACORD 25 PDFの束で抽出をお試しください。ルールが初めて実行されたときのコンプライアンスダッシュボードをご確認ください。10件中9件という統計は、結果が厳しいものになることを示唆しています。インシデント後ではなく、今確認することをお勧めします。