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

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

Redditのr/ConstructionManagersに、6か月前に新米プロジェクトコーディネーターが投稿しました。「私は基本的に一日中、下請け業者にメールで新しいCOIを催促して過ごしています。期限切れになる前に。これは完全に非常識で、極めてリスクが高いと感じます。このスプレッドシートで日付を1つ見落とすだけで、会社に数百万ドルの損害が出かねません。みんな本当にこんなやり方でやっているのでしょうか？」

返信は総じて肩をすくめるような内容でした。そう、みんなこうやっている。そして、それは悪夢だ。あるPMは自分の仕組みを「スプレッドシートと電話」と表現しました。別の人は「郡の検査官が来るまで、失効した許可証を追跡し続ける」ことへの不安を挙げました。3つ目のスレッドでは、ある中小ゼネコンが率直に尋ねました。「普通はこんなに面倒なものなのでしょうか？」

これらのスレッドが明らかにしているのは、建設業界のプロフェッショナルがコンプライアンスに疎いということではありません。COI追跡が業界のテクノロジースタックの盲点になっているということです。プロジェクト管理ソフトウェアと会計システムの間に位置し、どちらも担当せず、誰も解決していないタスクなのです。

標準的なツールはいつも同じです。マスタースプレッドシート。下請け業者名、保険種別、保険会社、証券番号、補償限度額、開始日、満了日、追加被保険者ステータス、代位求償権放棄、そして更新のたびに長くなるメモ欄。スプレッドシートが30行以内なら機能します。しかし、下請け業者50社×保険種別4ラインになると、200のデータポイントを管理することになり、1つのセルが古いだけで、保険未加入の下請け業者が稼働中の現場で作業することになりかねません。

保険証券と保険証書は別物 — スプレッドシートではその違いを見分けられない

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

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

そのような不備の実態を掘り下げると、なぜスプレッドシートでは検出できないのかがわかります。COIには一般賠償責任の総合限度額が200万ドルと記載されているのに、実際の保険契約には下請けが行っている特定の専門工事に対する免責条項が含まれているケース。保険証書にはゼネコンが追加被保険者として記載されているのに、完工後補償をカバーするCG 20 37ではなく、工事進行中の作業のみをカバーするCG 20 10担保のみが付帯されており、下請けの工事完了後に数ヶ月経ってから発覚する補償の空白が生じるケース。代位求償権放棄の欄にチェックが入っているのに、その担保が実際には保険会社に提出されていないケース。

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

したがって、建設業界のCOI追跡スプレッドシートはすべて、体系的に信頼性の低いデータの上に構築されています。データ入力のボトルネック — PDFのフィールドをExcelに入力するのに保険証書1枚あたり5分かかる作業 — は現実の問題ですが、2番目に悪い問題にすぎません。最も悪い問題は、入力されるデータが90%の確率で誤っており、スプレッドシートにはそれを検出する仕組みがないことです。

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

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

ゼネコンは下請け業者に契約書を送り、必要な保険を指定します。一般賠償責任は1事故あたり200万ドル／総額400万ドル、労働者災害補償は法定限度額、事業用自動車は100万ドル、アンブレラは500万ドル、さらに追加被保険者および代位求償権放棄の特約が含まれます。下請け業者はこれらの要件を保険代理店に転送します。代理店は保険会社のシステムから保険約款情報を取得し、ACORD 25フォームを作成します。このプロセスは、IRMIの監査が示したように、契約条件に対するエラー率が90%以上です。

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

4者の間で4回の引き継ぎが行われますが、保険約款の内容が検証されることは一切ありません。この連鎖の末端にいるコーディネーターは、転送されたメールを基に代理店が保険会社のシステムから作成した書類からデータを転記しているのです。つまり、情報源から4段階も離れています。各段階でデータは劣化します。保険証券番号の数字の誤り。入れ替わった補償限度額。電話で話し合われたものの、書類化されなかった追加被保険者の特約。

これは、より良い規律で修正できる壊れたプロセスではありません。これは、参加者全員が異なるインセンティブを持つ複数当事者ワークフローです。下請け業者は現場に入って報酬を得たいと考えており、保険書類は摩擦でしかありません。下請け業者の代理店は顧客を維持したいと考えており、たとえ保険約款が実際には対応していなくても、契約が求める内容を記載した証明書を発行することがその目標にかないます。ゼネコンのコーディネーターはチェックボックスにチェックを入れて次の下請け業者に進みたいと考えています。保険金請求で実際に重要となるのは保険会社の実際の約款文言だけであり、それは連鎖の中で代理店の引受担当者以外誰も読むことのない唯一のものです。

保険契約の更新はこれを指数関数的に悪化させます。下請け業者の一般賠償責任保険は毎年更新されますが、労働者災害補償保険と同じ日付ではありません。アンブレラ保険は3つ目の日付で更新されます。自動車保険は4つ目の日付です。更新サイクルごとに、すべての下請け業者のすべての保険種目について完全な4者リレーが発生し、毎回の更新で、何も変わっていないかのようにスプレッドシートに反映されるエラーが新たに生まれる機会となります。

業界はソフトウェアを導入した。それでもスプレッドシートは残った。

建設業界は技術導入に消極的な業界ではありません。全米建設業者協会（AGC）の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 25フォームから保険証券番号、補償限度額、満期日を読み取り、構造化されたレコードに入力する作業 — が、ワークフロー全体における自動化されていない中間区間なのです。この問題が解決されるまで、すべてのCOI追跡プラットフォームは手動転記ステップの下流に位置し、スプレッドシートを使い続けるユーザーは、手動で入力しなければならないデータを管理するためだけにプラットフォームに料金を支払うことが明確な改善ではないと、ある程度認識しているのです。

欠けていた層：PDFからスプレッドシートへ、タイピングなしでデータを取り込む

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

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

このアプローチが機能するのは、ACORD 25フォームがレイアウトを標準化しているにもかかわらず、実際にはスキャン画像、フラット化されたPDF、デジタル署名付きドキュメント、そして時には現場のトレーラーで撮影された印刷証明書の写真として届くことが多いためです。これらはすべて、ピクセル位置がずれるため、従来のOCRテンプレートマッチングが失敗する形式です。ImageToTable.aiの列名抽出は、座標を照合するのではなく、フォームの意味内容を理解することでこれを回避します。「Insurer A」を特定し、テキストの意味に基づいて隣接する保険証券番号を取得します（位置に基づくのではありません）。

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

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

これは、専用のCOI追跡プラットフォームの代替ではありません。これらのプラットフォームは、保険約款の文言を検証し、除外条項にフラグを立て、プロジェクト全体のコンプライアンスを追跡し、監査証跡を提供します。これらはスプレッドシートでは再現できず、抽出ツールが試みるものでもありません。抽出は、1つ上流の問題（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は商業物件保険の証明書です。建物、内容物、設備などの物件補償を、第一者損失に対して証明するものです。建設業界では、ゼネコンが受け取る書式の95%はACORD 25です。ACORD 28は、プロジェクトオーナーがゼネコンまたは下請け業者が工事保険や設備補償を保有していることの証明を必要とする場合に登場します。両方とも同じ法的免責事項が記載されています。どちらも保険証券ではなく、証明書保有者に権利を付与するものではありません。

AI抽出ツールは補償内容が十分かどうかを検証しますか？

いいえ。抽出ツールはCOI PDFから構造化データ（証券番号、補償限度額、満了日）を生成しますが、それらの数値が契約の保険要件を満たしているか、記載された特約が実際に証券に存在するか、証明書に記載された補償内容が保険会社の実際の証券文言と一致するかを検証するものではありません。その検証ステップには、保険証券を確認する熟練したコンプライアンス担当者、または証券レベルの検証機能を備えた専用のCOI追跡プラットフォームが必要です。抽出はデータ入力レイヤーを簡素化します。コンプライアンス検証は、その後の別途必要なステップです。