ACORD 25：スプレッドシートでは見えない
追加被保険者の盲点

チェックボックスは補償にあらず

北米の建設業界で事実上すべての下請け業者が使用する賠償責任保険証明書フォーム「ACORD 25」には、ADDL INSDという列があります。この列は補償範囲グリッド内で、保険証券の種類と代位求償権放棄の列の間に静かに位置しています。下請け業者の保険代理店が証明書を記入する際、証明書保有者が追加被保険者として追加された補償ラインごとに、この列にチェックマークまたは「X」を記入します。

リスク管理チームはPDFを受け取ります。補償範囲グリッドまでスクロールし、一般賠償責任の行を見つけます。ADDL INSDに「X」が入っているのを確認し、コンプライアンススプレッドシートに「AI: あり」と入力します。証明書は承認済みの山に移されます。

このワークフローは論理的で標準化されており、何千もの建設会社で採用されています。しかし同時に、これこそが、請負業者のポートフォリオ内のすべてのアクティブなプロジェクトにわたって、証明書ごとに無保険のエクスポージャーが蓄積されるメカニズムでもあります。

ACORD 25フォーム自体に、なぜこれが危険なのかの説明が記載されています。証明書に直接、太字で印刷されていますが、ほとんどのレビュー担当者は壁紙のように見慣れてスキップしてしまいます。

平たく言えば、証明書は代理店からのメモであり、保険会社からの契約ではありません。代理店はADDL INSDボックスにチェックを入れることができます。業務内容の説明ブロックに裏書フォーム番号を入力できます。CG 20 10フォームのコピーを添付することもできます。しかし、保険会社が裏書を処理していなければ——引受担当者が承認しておらず、追加被保険者が実際に保険証券に追加されていなければ——証明書の記載は補償を提供しません。証明書は情報提供に過ぎません。防御と損害賠償の権利を生み出すのは、保険証券上の裏書だけです。

判例はこの点で明確です。ジョージア州法O.C.G.A. § 33-24-19.1(j)は、複数の州の裁判所が支持してきたことを成文化しました。すなわち、保険証明書は保険証券ではなく、補償範囲を修正するものではないということです。請求が発生し、保険会社が証明書の記載にかかわらず裏書が実際には発行されていないことを発見した場合、保険会社が追加被保険者を防御し損害を賠償する義務は単に存在しません。スプレッドシートの「AI: あり」という入力は、誰かがそうであってほしいと願った記録に過ぎなくなります。

これは理論上の限界的なケースではありません。COI検証プラットフォームであるBrambleは、コンドミニアム請負業者の証明書データセットを調査し、追加被保険者ステータスを主張するCOIの約31%が、保険証券レベルで対応する裏書を持っていなかったことを発見しました。プロパティマネージャーやゼネコンが補償を頼りにしていた証明書の3つに1つ近くが、幽霊のような追加被保険者保護を抱えていたのです——COI上では見えるが、保険証券上には存在しない。

ACORD 25に追加被保険者が表示される3つの場所と、それぞれの失敗パターン

追加被保険者記入欄は単一のバイナリフィールドではありません。ACORD 25フォームでは、3つの異なる場所に表示される可能性があり、それぞれに異なるルールと失敗パターンがあります。この3つのパターンを理解することは、スプレッドシートベースのレビューが構造的にギャップを捉えられない理由を理解する上で不可欠です。

ADDL INSDチェックボックス（最も一般的、最も信頼性が低い）

これは補償範囲グリッド内の列で、保険ラインごとに1つあります。ここにチェックマークがあることは、保険証券取得者のために、被保険者の保険に追加被保険者記入欄が追加されたという保険代理店の認識を示します。

失敗パターン：代理店の認識には法的根拠がない。代理店は保険会社ではありません。代理店は記入欄を処理しません。保険会社の引受部門が処理します。代理店は、被保険者から聞いた内容や、包括的記入条項が理論上許可する内容に基づいて、保険会社が実際に記入欄を発行したり追加保険料を徴収したりしていなくても、善意でチェックボックスをオンにすることができます。ニューヨーク州金融サービス局の規制意見は、代理店は実際の保険契約の条件を変更、拡大、または修正する条項を証明書に追加してはならないと明示しています。チェックボックスはまさにこのカテゴリに該当します。存在するかどうかわからない変更を説明しようとするものです。

全米独立保険代理店・ブローカー協会が発行する標準的な保険代理店ガイダンスは、これを補強しています。「追加被保険者ステータスと代位権放棄をデフォルトで含めないでください。保険契約に「書面による契約で要求された場合」の自動記入条項が含まれている場合でも、代理店はデフォルトで追加被保険者を表示すべきではありません。」ガイダンスは明確です。チェックボックスは実際の処理に依存するものであり、保証ではありません。

業務内容説明ブロック（自由記述、未検証）

ACORD 25の補償範囲グリッドの下には、業務内容／所在地／車両／特約による追加除外条項／特別規定の説明ブロックがあります。これは構造化スキーマのない自由記述フィールドであり、代理店は事実上何でも入力できます。

実際には、このブロックには追加被保険者に関する最も具体的な情報が含まれることがよくあります。例えば「ABC Construction, Inc.はCG 20 10（07/04）およびCG 20 37（07/04）に基づき追加被保険者として指名」や「書面契約で要求される追加被保険者」などと記載されます。さらに問題を複雑にするのは、契約で要求される特定の裏書フォーム番号を、実際に保険証券に添付されたか確認せずに入力するケースです。

障害モード：自由記述は大規模な機械検証が不可能。 リスクマネージャーが今週80枚の証明書を確認する場合、業務内容説明ブロックは一行ずつ読まなければならない密集した段落になります。「CG 20 10による追加被保険者」（進行中の業務に対する補償あり）と「CG 20 10およびCG 20 37による追加被保険者」（完了した業務まで補償拡大）の違いは、文中の数文字だけです。「書面契約で要求される追加被保険者」（条件付き—契約で要求される場合のみ補償）と「ABC Constructionは裏書CG 20 10により追加被保険者として指名」（具体的—契約に関係なく補償）の違いは、疲労時のスキャンではほぼ同一に見える文言に埋もれた法的ニュアンスです。

添付裏書ページ（最も価値があるが、最も確認されない）

追加被保険者ステータスの法的に強制力のある唯一の証拠は、実際の裏書ページ—保険会社によって処理され、被保険者の保険証券に添付されたISOフォームまたは保険会社同等フォームです。適切に作成された証明書では、これらの裏書ページはACORD 25フォームの後ろに添付資料として表示されます。保険証券番号、裏書フォーム番号（CG 20 10、CG 20 37、CG 20 33など）、追加被保険者の名前、および発効日が記載されています。

障害モード：レビュー担当者がそれらを要求または確認することはほとんどありません。 業界の標準はACORD 25を収集して次に進むことです。裏書ページが含まれていたとしても、PDFの後ろにあり、めったにスクロールされません。プロジェクト開始時に200人の下請け業者を管理するコンプライアンスコーディネーターは、証明書1枚あたり約3〜5分しかありません。その時間は、保険証券の日付、補償限度額の確認、および証明書保有者名の検証に費やされます。契約要件に一致する裏書フォーム番号を添付裏書ページでスキャンすることは、5分のレビュー枠には収まりません。

これにより構造的なコンプライアンスギャップが生じます。証明書パッケージの中で最も法的に重要な部分が、最も無視されやすい部分でもあるのです。200行と「AI確認済み」列のあるCOI追跡スプレッドシートは、保険証券レベルで実際に確認された裏書がゼロでも、100％のコンプライアンスを示すことができます。

誰も確認しない追記被保険者：AIが誤った保険種目に存在するケース

たとえ保険証券の追記ページまでスクロールして確認するような注意深いレビュアーでも見落とす可能性がある、より微妙な失敗モードがあります。それは、追記被保険者（AI）の追記条項自体は存在するものの、証券取得者が想定している保険種目とは異なる種目に付帯されている場合に発生します。

一般的な下請け業者の保険構成を考えてみましょう。

一見すると、COIは準拠しているように見えます。ACORD 25の「追記被保険者」欄にはチェックが入っています。「業務内容の説明」欄には「ABC建設を追記被保険者として指定」と記載されています。追記条項のページも添付されており、PDFの3ページ目には、ABC建設がスケジュールに記載されたCG 20 10追記条項が表示されています。

このギャップが明らかになるのは、どの保険種目に追記条項が付帯されているかを追跡したときです。アンブレラ保険にCG 20 10が付帯されています。請求に最初に対応する一次層である一般賠償責任保険には付帯されていません。これにより、追記被保険者は一次限度額が使い果たされた後にのみ保護されるという補償構造が生まれます。工事現場での負傷による75,000ドルの一般賠償責任請求の場合、アンブレラ保険は発動しません。GC（元請け）はGL保険の追記被保険者ではありません。その請求はGC自身の保険に影響を及ぼします。

これは作為的なシナリオではありません。COI追跡プラットフォームJonesは、コンプライアンス徹底のワークフローにおいて、まさにこの問題を記録しています。そこでは、クライアントによってAI追記条項の表示場所に関するルールが異なり、業務内容の説明欄と追記条項ページの両方への記載を求めるクライアントもいれば、複数の保険種目に同時に記載することを求めるクライアントもいました。クライアント要件のばらつき自体が、この問題がカスタム検証ルールを生成するほど広く浸透していることの証拠です。

より深い構造上の問題：ACORD 25には1つの「追記被保険者」欄がありますが、その欄は5行（GL、自動車、アンブレラ、労災、その他）のグリッド上にあります。チェックボックスはそれが配置されている行に適用されます。しかし、フォームの視覚的な単純さが、レビュアーにそれを単一の「はい/いいえ」条件として扱うよう促します。アンブレラ行のチェックボックスは、GL行に追記条項があることを意味しません。しかし、レビュアーが一度に50枚の証明書をスキャンし、「追記被保険者」欄に複数の行にわたって一貫して「X」が表示されている場合、視覚的なパターン認識が行ごとの検証を上書きします。目には準拠のパターンが見えます。GL行がその一部であるかどうかは別問題です。

500件の証明書、1人の確認者——手動確認ではなぜこのギャップを埋められないのか

中堅ゼネコンが20のプロジェクトを同時進行し、各プロジェクトに平均25社の下請け業者がいる場合、常時約500件の保険証明書が追跡システムに登録されています。各証明書は、契約時の確認、更新時の再確認、さらにプロジェクト途中で下請け業者が保険会社を変更するたびに再確認が必要です。これは、保険契約の満期と切り替えが頻繁に発生するため、珍しいことではありません。

確認作業の負荷は一定ではありません。証明書は一度に大量に届きます——着工前の1週間に40件、下請け業者の車両保険が一斉更新されるタイミングで15件、監査期限が迫りコンプライアンスチームが未通知の失効COIを発見した際に8件。リスクマネージャーやコンプライアンス担当者は、落ち着いて集中できる環境で証明書を処理しているわけではありません。彼らはトリアージ（優先順位付け）を強いられているのです。

トリアージ状態では、人間による確認プロセスは、以下のように予測可能な形で劣化していきます。

ステップ4まで進むと、脳は分析的検証からパターンマッチングへと切り替わります。ADDL INSDチェックボックスは視覚的な信号——「このセクションは処理済み」を示す青信号——になります。GLライン上のCG 20 10とアンブレラライン上のCG 20 10の違いは、パターン認識モードでは目で捉えられません。分析モードに戻り、グリッド上のポリシーラインをたどり、承認ページと照合し、フォーム番号が契約仕様と一致することを確認する必要があります。

これは注意力の欠如ではありません。プロセス設計の失敗です。人間の視覚システムは、何百回もの繰り返しにわたって、高精度でフィールドレベルの検証を緻密な表形式の文書に対して持続するようには設計されていません。保険コンプライアンス業界全体で、手動による保険データ入力のエラー率は15～20%と報告されています。これは無能さからではなく、タスクの認知的負荷と持続的な分析的注意力に対する人間の能力との構造的なミスマッチによるものです。

Redditのスレッドは現場の現実を捉えています：「下請け業者は、誤った補償限度額、追加被保険者承認の欠落、または誤ったプロジェクト名の証明書を送ってきます。プロセスがあるだけでは不十分です。」 プロセス——スプレッドシート、チェックリスト、5分間のレビュー——こそが、最も重大なギャップを未検証のままにしながら、管理の錯覚を生み出すものなのです。

抽出が検証の方程式をどう変えるか

手動によるCOIレビューの構造的な失敗は、レビュー担当者が不注意であることではありません。レビュー担当者が、データ入力（保険証券番号、限度額、日付をスプレッドシートに入力すること）とコンプライアンス検証（ページ上の内容が契約要件を満たしているか評価すること）という2つのタスクを同時に実行するよう求められていることです。しかも、各フィールドが個別の分析的注意を必要とする文書形式に対してです。これらは2つの異なる認知操作であり、両方を同時に行うと、両方の質が低下します。

これらを分離することが、ギャップを埋め始める閾値です。データ入力のステップ——ページ上の内容を抽出すること——はAI抽出が処理します。コンプライアンス検証のステップ——そこにあるものが契約を満たしているか判断すること——はリスクマネージャーに残され、各証明書が実際に何を言っているかの完全かつ正確な抽出結果に支えられます。

AIがACORD 25を読み取るとき、ADDL INSDチェックボックスだけを見るわけではありません。チェックボックスの状態、Description of Operationsブロックのすべての行（「CG 20 10」や「CG 20 37」などの特定のフォーム番号を含む）、添付ページからの承認フォーム番号という、承認情報の3つのソースすべてを同時に抽出できます。これら3つのデータポイントは、スプレッドシートの3つの列——AI確認済み？、説明ブロックテキスト、見つかった承認フォーム番号——に配置され、リスクマネージャーはそれらを並べて確認します。

不一致がスプレッドシートから飛び出します：AI列には「X」と表示されているが、承認フォーム番号列は空欄。説明ブロックには「CG 20 10」とあるが、添付された承認ページはCG 20 33。GL行にチェックボックスがあるが、承認はアンブレラ行にある。これらは、手動レビューではその認知的設計上、規模を問わず表面化できないコンプライアンスシグナルです。

このアプローチは、あらゆる文書を構造化されたスプレッドシートに変換する、同じカスタム列抽出ワークフローに基づいています。抽出したい列（証券番号、被保険者名、GL 1事故限度額、GL 総合限度額、ADDL INSDチェックボックス、作業内容、承認書様式番号、証券満期日）を定義すると、AIは各ACORD 25 PDFを読み取り、それらのフィールドが何を意味するかを意味論的に理解します。固定座標で探すわけではありません。保険会社によるフォーマットの違い（異なるフォントサイズ、フィールド位置のずれ、フォームに重なった代理店スタンプ）があっても、AIは位置ではなく意味で読み取るため、抽出が失敗することはありません。

出力はコンプライアンストラッカーであり、すべての証明書のデータが同じ12列のテンプレートに抽出されます。リスクマネージャーの業務は、「PDFを開き、フィールドを読み、スプレッドシートに入力する」から、「スプレッドシートをスキャンして不一致を見つけ、フラグを立てる」へと変わります。これは根本的に異なる認知負荷です。列内の赤旗パターンをスキャンする方が、PDFから個々のフィールドを抽出するよりも桁違いに速く、エラー率も低下します。なぜなら、パターン認識のステップがスキャンされたフォームではなく構造化データに対して行われるからです。

規模の問題（500件の証明書、1人のレビュー担当者）に関しては、これは重要です。1件あたりの時間が、手動による抽出とレビューの5分から、AI抽出の約10秒と構造化データレビューの30秒に短縮されます。これまでフィールド転記という機械的な作業に費やされていたレビュー担当者の注意力は、実際に会社を守る分析業務、つまり架空のAI補償が記載された証明書を特定することに振り向けられます。列ごとのワークフローの詳細はACORD 25抽出ガイドに、数百件の証明書を一度に処理するバッチ規模の戦略はバッチACORD 25検証ウォークスルーで説明しています。

よくある質問

ACORD 25の「ADDL INSD」チェックボックスに法的保護効果はありますか？

いいえ。ACORD 25フォーム自体に「証明書保持者に対していかなる権利も付与しない」「保険契約による補償を積極的にも消極的にも修正、延長、変更するものではない」と明記されています。チェックボックスは保険代理店による記載に過ぎません。追加被保険者とするには、保険会社による承認手続きと保険証券への追加が必要です。チェックボックスだけでは法的効力は一切ありません。

CG 20 10とCG 20 37の違いは？なぜ両方必要なのですか？

CG 20 10は、被保険者である元請けの継続中の作業（下請けが現場で作業中の期間）に起因する賠償責任を追加被保険者として補償します。CG 20 37は、完了した作業（下請けの作業完了後）に起因する賠償責任を補償します。CG 20 37がないと、下請けが現場を離れた後は追加被保険者としての保護がなくなり、完工から数ヶ月後に発覚した欠陥クレームは元請け自身の保険が対応することになります。完工から数年にわたって製造物責任の除斥期間が続くプロジェクトでは、両方の担保が必要です。

AI抽出で、Description欄の約款番号と添付ページの約款番号は区別できますか？

はい。抽出列を、作業内容の説明テキストブロック用と添付ページの約款番号用に分けて設計すれば、抽出されたスプレッドシートで情報の出所が正確にわかります。Description欄にCG 20 10の番号があっても、添付された約款ページにその番号がなければ、証明書の記載が実際に処理された約款に裏付けられていない可能性を示します。

下請けが包括的な追加被保険者約款を持っている場合、チェックボックスの確認は必要ですか？

包括的な追加被保険者約款は、通常「書面による契約で要求される場合」という文言で発動し、被保険者と書面契約を結び、追加被保険者を要求する相手に自動的に追加被保険者資格を付与します。ただし、包括的補償にも条件があります。書面契約の存在、契約での追加被保険者要件、契約範囲が約款の補償発動条件に該当することの3つです。COIのチェックボックスだけではこれらの条件充足を確認できません。補償の適用有無を決めるのは、証明書の記載ではなく、根拠となる契約と実際の約款文言です。

ISOが発行する追加被保険者承認はいくつあり、建設業で重要なのはどれか

ISOは数十の追加被保険者承認を発行している — CG 20 09からCG 20 38まで、さらにそれ以上 — これらは異なる関係（所有者、賃借人、請負業者、管理者、販売業者、贈与者）と異なる補償トリガー（継続作業、完了作業、契約で要求された場合の自動付与）をカバーしている。建設業で最も一般的に要求されるのは次の3つである：CG 20 10（追加被保険者 — 継続作業、指定型）、CG 20 37（追加被保険者 — 完了作業）、CG 20 33（建設契約で要求された場合の自動追加被保険者ステータス）。それぞれに版日付が異なり、補償文言が実質的に異なる — CG 20 10の04/13版と12/19版は10/01版よりも狭く、「起因する」という文言を「全体的または部分的に起因する」に置き換えたため、裁判所は記名被保険者の過失の証明を要求すると解釈している。承認に印刷された版日付が重要である。

COI承認が保険証券と一致しない頻度に関する業界標準はあるか

複数の独立した情報源が大きなギャップを指摘している。Brambleのコンドミニアム請負業者証明書データでは、追加被保険者ステータスを主張するCOIの約31%に、対応する証券レベルの承認が欠けていた。COI検証プラットフォームが引用する業界調査では、手動レビューされた建設証明書の23%にエラーまたは補償ギャップが含まれていると報告されている。IRMIの監査結果では、10件中9件の証明書が契約上の保険仕様を満たしていなかった — これはさらに広い範囲ではあるが — 問題の規模と一致している。データは、COIが追加被保険者保護を主張する下請け業者3社ごとに、約1社が実際にはそれを保有していないことを示唆している。

ImageToTable.aiは専用のCOI追跡プラットフォームとどう違うのか

専用のCOI追跡プラットフォーム — Jones、myCOI、bcs、Billy、CertFocus — は継続的なコンプライアンス管理のために設計されている：証明書を収集し、更新リマインダーを送信し、プロジェクト管理ソフトウェアと統合し、一部は人間によるレビューサービスを提供する。これらは追跡とワークフローの問題を解決する。ImageToTable.aiは別の問題を解決する：抽出ステップである。ACORD 25 PDFの束を、承認フォーム番号とそのソースコンテキストを含む、定義した列にすべてのフィールドを抽出した構造化スプレッドシートに変換する。スプレッドシートでCOIコンプライアンスを管理するチーム、またはCOIプラットフォームを使用しても証明書データを手動で入力しているチームにとって、抽出ステップこそが承認ギャップが隠れる場所である。COIコンプライアンスのコストエクスポージャーの広範な比較はCOI非準拠コスト分析にあり、COIデータ抽出の完全な概要はCOI抽出ガイドにある。