建設業のCOI追跡が、いまだに
メールとスプレッドシートに依存する理由

COIスプレッドシートは誰もが通る道——そして誰も自慢しない

Redditのr/ConstructionManagersに、6ヶ月前、新米プロジェクトコーディネーターが投稿した。「新米PMです。下請けの新しいCOIが期限切れになる前に、メールで追いかけ回すのに一日中費やしています。正気の沙汰とは思えず、リスクも極めて高い。このスプレッドシートでたった一つの日付を見逃せば、会社に数百万の損害が出かねない。みんな本当にこんなやり方なのか？」

返信は総じて肩をすくめるような内容だった。そう、みんなそうやってる。そしてそれは悪夢だ。あるPMは自社のシステムを「スプレッドシートと電話」と表現した。別のPMは「期限切れの許可証を追跡し忘れて、郡の検査官が現場に来るのが怖い」と述べた。さらに別のスレッドでは、ある中小ゼネコンが率直に「これって普通、面倒なものなの？」と尋ねていた。

これらのスレッドが明らかにしているのは、建設業者がコンプライアンスを軽視しているわけではない。COI追跡が業界のテクノロジースタックの盲点になっている——プロジェクト管理ソフトと会計システムの谷間に落ち、どちらも担当せず、誰も解決していないタスクなのだ。

デフォルトのツールはいつも同じだ。マスタースプレッドシート。列には、下請け業者名、保険の種類、保険会社、証券番号、補償限度額、開始日、満期日、追加被保険者 status、代位求償権放棄、そして更新のたびに長くなる備考欄。30行以内なら機能する。しかし、50の下請け業者にそれぞれ4つの保険ラインがある場合、200のデータポイントを管理することになる。たった一つのセルが古いままだと、無保険の下請けがアクティブな現場で作業していることになりかねない。

保険証券は保険契約書ではない——スプレッドシートではその違いは判断できない

ACORD 25 様式の賠償責任保険証券（米国建設業界で標準的に使用されるCOI様式）には、ほとんどの人が見落とす太字大文字の文言が記載されています。「この証明書は情報提供のみを目的として発行されており、証明書保有者に対していかなる権利も付与するものではありません。この証明書は、以下に記載された保険契約によって提供される補償範囲を積極的にも消極的にも修正、拡張、または変更するものではありません。」

これらは細かい免責条項ではありません。これらは文書の法的構造です。保険証券は、保険代理店が保険契約の内容を解釈して要約したものです。保険会社を拘束するものではなく、記載された補償が実際に存在することを保証するものでもなく、たとえ証明書保有者欄にその文言が記載されていても、ゼネコンが追加被保険者として追加されたことを証明するものではありません。

そうした不備の実態を掘り下げると、スプレッドシートではなぜそれらを捕捉できないかがわかります。COIには200万ドルの一般賠償責任包括限度額が記載されているが、実際の保険証券には下請けが行う特定の専門工事に対する免責条項が含まれている。証書には元請けが追加被保険者として記載されているが、それは工事中の作業をカバーするCG 20 10の裏書に限られ、工事完了後の作業をカバーするCG 20 37は対象外であり、下請けの作業完了後に発覚まで数ヶ月を要するギャップが生じる。代位求償権放棄のチェックボックスはオンになっているが、その裏書は実際には保険会社に提出されていなかった。

ACORD 25様式は、全米独立保険代理店・ブローカー協会によると、3つの大きな問題に脆弱です。すなわち、下請けが仕事を獲得できるよう存在しない補償内容を記載する代理店による証書詐欺、市場で入手可能な保険証券では満たせない過酷な契約上の保険要件、そして証書が約束しているにもかかわらず証書保有者が実際には解約通知を受け取れないという根強い問題です。スプレッドシートはこれらを一切認識しません。PDFに書かれていることを記録して次に進むだけです。

したがって、建設業界におけるすべてのCOI追跡スプレッドシートは、系統的に信頼性の低いデータの上に構築されています。データ入力のボトルネック（1枚の証書につき5分かけてPDFのフィールドをExcelに打ち込む作業）は確かに問題ですが、これは2番目に悪い問題です。最も悪い問題は、入力されるデータが90%の確率で間違っており、スプレッドシートにはそれを検出する仕組みがないことです。

誰も設計せず、誰も勝てない4者リレー

なぜメールとスプレッドシートがCOIワークフローの標準であり続けるのかを理解するには、1枚の証書がたどる経路を追跡してみてください。

元請けは下請けに対し、必要な保険内容を明記した契約書を送付する。一般賠償は1事故あたり200万ドル、総額400万ドル、労働災害補償は法定限度額、業務用自動車は100万ドル、アンブレラは500万ドル、さらに追加被保険者および求償権放棄の特約を付帯する。下請けはこれらの条件を保険代理店に転送する。代理店は保険会社のシステムから証券情報を取得し、ACORD 25書式に入力する。IRMIの監査によると、この工程では契約条件に対するエラー率が90%以上にのぼる。

代理店はCOIのPDFをメールで下請けに送り、下請けはそれを元請けのプロジェクトコーディネーターに転送する。コーディネーターはPDFを開き、証券番号、保険会社名、補償種別、限度額、開始日、満期日、追加被保険者の有無、求償権放棄の有無——各項目を読み取り、マスタースプレッドシートに手入力する。PDFは、最後に保存した人によって命名規則が異なる共有ネットワークフォルダに格納される。スプレッドシートは更新される。コーディネーターは満期30日前のカレンダーリマインダーを設定する。

当事者は4者、引き継ぎは4回、保険証券の内容確認は一切なし。この連鎖の末端にいるコーディネーターが転記しているデータは、転送メールをもとに代理店が保険会社システムから作成した書類に由来する——情報源から4段階も離れている。各段階でデータは劣化する。証券番号の桁違い。補償限度額の転記ミス。電話で話し合われたが書類化されていない追加被保険者の特約。

これは、規律を改善すれば解決できるような単純なプロセスの問題ではない。異なるインセンティブを持つ複数の当事者が関わるワークフローだ。下請けは現場に入って報酬を得たい——保険の書類手続きはその妨げになる。下請けの代理店は顧客を維持したい——たとえ保険証券がカバーしなくても、契約内容に合った証明書を発行すればその目的が達成される。ゼネコンの担当者はチェックを済ませて次の下請けに移りたい。保険金請求で実際に意味を持つのは保険会社の約款だけだが、その約款を読むのは、チェーンの中で代理店の引受担当者以外には誰もいない。

保険契約の更新はこれを指数関数的に悪化させる。下請けの賠償責任保険は年1回更新されるが、労災保険とは更新日が異なる。包括保険はさらに別の日、自動車保険はさらに別の日だ。更新のたびに、すべての下請けのすべての保険種目で4者間のやり取りが発生し、更新のたびに、何も変わっていないかのようにスプレッドシートに記録されるエラーが発生する新たな機会が生まれる。

ソフトウェアは導入された。スプレッドシートは残った。

建設業界は技術に消極的ではない。全米建設業者協会の2025年見通し調査によると、大手建設業者の66%がプロジェクト管理ソフトウェア、44%が積算ソフトウェア、40%がスケジューリングソフトウェアを導入している。平均的な企業は6.2種類のデジタルツールを導入している。これは技術導入を拒む業界ではない。導入された技術が、COI問題を解決するために設計されていなかっただけだ。

Procoreは、変更指示書、RFI、提出書類、パンチリストを管理しますが、下請け業者の一般賠償責任保険が実際の作業内容をカバーしているかどうかを確認する機能はありません。Procore内でCOIコンプライアンス追跡を行うには、ゼネコンは別途統合ツール（Billy、myCOI、Jones、SmartCompliance、TrustLayer）を購入する必要があります。これらのツールはAPIを介してProcoreに接続し、コンプライアンス状況を同期しますが、誰かがCOIのPDFを読み取り、そのフィールドを抽出するという基本的なデータ取得ステップは、ソフトウェアが有効に機能する前に手動で行わなければならないままです。

例えば、BillyプラットフォームのProcoreサイドパネルを使用すると、コンプライアンス管理者はProcoreから離れることなく下請け業者の保険状況を確認できます。ただし、まず誰かがCOIのPDFをアップロードし、管理レビューチームまたはゼネコンの内部スタッフが要件に照らして確認する必要があります。myCOIは、資格を持つ保険専門家チームを擁して同様の機能を提供します。Jonesは、実際の保険証券から除外文言を検出するAI検証機能を追加しています。これらは価値あるサービスですが、いずれもスプレッドシートと同様のデータ取得のボトルネックの上で動作しています。つまり、PDFがメールで届き、誰かがその内容を判断しなければならないという点は変わりません。

スプレッドシートが使われ続ける理由は、請負業者がソフトウェアを購入したがらないからではない。購入したソフトウェアは、データがシステムに入った後のコンプライアンス状況を管理するために設計されており、メールで届くPDFからデータをシステムに入力するためのものではないからだ。そのステップ——1ページのACORDフォームから保険証券番号、補償限度額、有効期限を読み取り、構造化されたレコードに入力する——こそが、ワークフロー全体の自動化されていない中間部分である。これが解決されない限り、すべてのCOI追跡プラットフォームは手動入力の下流に位置し、スプレッドシートを使い続けるユーザーは、自分で手入力しなければならないデータを管理するためだけにプラットフォームにお金を払うのは、明らかな改善ではないとどこかで認識している。

欠けている層：PDFからスプレッドシートへ、入力なしでデータを取り込む

構造的な問題が、COIデータがPDF内にあり、追跡ツールには構造化データが必要だということなら、最も直接的な介入は、スプレッドシートを置き換えたり別のプラットフォームを購入したりすることではない。手動入力のステップ——証明書1枚あたり5分、数字の転記ミス、コピー＆ペーストした有効期限——を、PDFが届いたときに自動的に行われるものに置き換えることだ。

ここで、ドキュメント抽出がCOI追跡の経済性を変える。ACORD 25フォームからフィールドを読み取ってExcelに入力する代わりに、必要な列——保険証券番号、保険会社、補償タイプ、発生限度額、総合限度額、開始日、満了日、追加被保険者（有/無）、代位求償権放棄（有/無）——を定義し、AIにCOI PDF上の各値を特定させる。出力は、すべてのフィールドが入力されたスプレッドシートの1行で、入力作業は一切不要。PDFはフォルダに入り、データはトラッカーに入る。証明書を受け取ってから記録されるまでのギャップは、数秒に短縮される。

この方法が有効なのは、ACORD 25書式がレイアウトを標準化しているにもかかわらず、実際にはスキャン画像、フラット化されたPDF、電子署名済み文書、さらには現場から送られてくる印刷された証明書の写真など、従来のOCRテンプレートマッチングではピクセル位置がずれて失敗する形式で届くからです。ImageToTable.aiの列名抽出は、座標を照合するのではなく、フォームの意味内容を理解することでこれを回避します。「Insurer A」を識別し、テキストの意味に基づいて隣接する保険証券番号を取得します。位置情報には依存しません。

このアプローチを持続可能にしているのは、既存のワークフローを放棄する必要がないことです。スプレッドシートはそのまま使えます。共有フォルダもそのまま使えます。BillyやmyCOIのようなCOI追跡プラットフォームを引き続き使用したり、新たに追加したりすることも可能です。抽出されたデータはExcelやCSVを受け入れるあらゆるシステムに流し込めるからです。メールリレーは引き続き機能します。下請け業者は代理店から保険証券を取得し、COIをゼネコンに転送します。しかし、コーディネーターはPDFをセルに転記する作業に一日を費やす必要がなくなります。スプレッドシートはデータ入力端末ではなく、抽出データによって更新されるダッシュボードになります。

同じ抽出レイヤーは、建設プロジェクトのコーディネーターが直面するより広範な文書コンプライアンスの課題にも対応します。下請け業者の請求書は15種類の異なる形式で届きますが、経理チームはすべての請求書から同じ項目を取得する必要があります。リーン権利放棄書、W-9、事業許可証にもそれぞれデータがあり、現在誰かが個別のトラッカーに手入力しています。列名抽出はこれらすべてを同じ操作として扱います。列を定義し、書類をアップロードし、構造化データを取得する。それがどのコンプライアンスカテゴリに属するかは関係ありません。

これは専用のCOI追跡プラットフォームの代替品ではありません。それらのプラットフォームは、保険証券の文言を検証し、除外条項をフラグ付けし、プロジェクト全体のコンプライアンスを追跡し、監査証跡を提供します。これらはスプレッドシートでは再現できず、抽出ツールが試みる機能でもありません。抽出が解決するのは、PDFからデータを取得し、次に使用するシステムに渡すという、一段上流の問題です。これは当初から欠けていたレイヤーであり、業界が他のすべてのソフトウェアカテゴリを採用した後も、スプレッドシートがデフォルトであり続けた理由です。

よくある質問

ProcoreやSageがCOI追跡を処理しないのはなぜですか？

ProcoreとSage 300 CREはプロジェクト管理および会計プラットフォームであり、システム内の財務データと運用データを整理します。どちらもCOIのPDFを読み取り、保険情報を抽出したり、証明書に記載された補償範囲が実際の保険証券と一致するかを検証するようには設計されていません。ProcoreのApp Marketplaceには、COIコンプライアンスステータスをProcoreダッシュボードに接続するサードパーティ製アドオン（Billy、myCOI、Jones、SmartCompliance）がリストされていますが、初期データ取得ステップ（ACORD 25フォームの読み取り）には、依然として人間または別の抽出ツールが必要です。ギャップはProcoreの機能セットにあるのではなく、COIデータが事前にデジタル化された状態で到着するというアーキテクチャ上の前提にあります。

すべての下請け業者にポータル経由でCOIを提出させるだけではダメなのですか？

ポータルは、データ入力の負担をあなたから下請け業者やその保険代理店に移すだけであり、なくすわけではありません。誰かがACORD 25フォームを読み、フィールドに入力する必要は依然としてあります。すべての下請け業者の保険代理店に、さらに別のプラットフォームへのログインを強いる煩わしさこそが、ポータルベースのCOI追跡ツールでベンダーの導入率が低い理由です。6つの異なるゼネコンで働く下請け業者が、6つの異なるコンプライアンスポータルにアカウントを維持することは期待できません。これが、電子メールが今もなお使われ続ける理由です。電子メールは、すべての下請け業者、すべての保険代理店、すべてのゼネコン担当者の間で100%普及している唯一のコミュニケーションチャネルだからです。より効果的な対策は、その普遍的なチャネルを通じて届くあらゆる形式を処理できる受信側を構築することです。

コントラクターズ・インシュアランス・サーティフィケート（工事保険証明書）に法的拘束力はありますか？

いいえ。ACORD 25のコントラクターズ・インシュアランス・サーティフィケート（工事保険証明書）は、その文言上「情報提供のみを目的として」発行され、「証明書保有者に対していかなる権利も付与するものではありません」。これは、記載されている保険契約を修正、延長、または変更するものではありません。法的拘束力を持つ唯一の文書は、保険契約自体とそれに添付された特約条項（エンドースメント）です。証明書にゼネコンが追加被保険者として記載されていても、特約条項（エンドースメント）が実際に保険会社に提出されていなければ、証明書の内容にかかわらず、ゼネコンは補償を受けられません。これは建設コンプライアンスにおいて最も危険な誤解であり、IRMIの監査結果（請負業者の保険の90%以上が契約要件を満たしていない）が書類上の問題ではなく、無保険のエクスポージャー（危険曝露）の問題である理由です。

ACORD 25とACORD 28の違いは何ですか？

ACORD 25は賠償責任保険の証明書です——第三者への賠償責任（一般賠償、自動車、労災、包括賠償）をカバーし、下請け業者が元請けに提出する書式です。ACORD 28は商業物件保険の証拠書類で、建物、内容物、設備などの物件補償を記録します。建設業では、ACORD 25が元請けが受け取る書式の95%を占め、ACORD 28はプロジェクトオーナーが元請けや下請けの建設業者保険や設備補償の証明を必要とする場合に使われます。両者とも同じ法的免責事項があります：保険証券ではなく、証明書保有者に権利を付与するものではありません。

AI抽出ツールは補償内容が適切か確認しますか？

いいえ。抽出ツールはCOIのPDFから証券番号、補償限度額、有効期限などの構造化データを取得しますが、それらの数値が契約の保険要件を満たしているか、記載された特約が実際に証券に存在するか、証明書に記載された補償内容が保険会社の実際の証券文言と一致するかは確認しません。その確認には、保険証券を読むコンプライアンス専門家か、証券レベルの確認機能を持つ専用のCOI追跡プラットフォームが必要です。抽出はデータ入力の部分を簡略化します。コンプライアンス確認は別途必要な後続のステップです。