保険証券をExcelに変換：あらゆる保険会社のACORD 25データに対応
ACORD 25フォームからCOIの項目を手入力で転記すると、1枚あたり3〜5分かかります。1枚の保険証券に4つの独立した補償区分（GL、Auto、Umbrella、WC）が含まれ、それぞれに保険証券番号、限度額、日付がある場合、列が1つずれるだけでコンプライアンス管理表に誤った満期日が記録されてしまいます。本ツールはすべての補償区分を名前付きのExcel列に抽出し、1ページあたり5〜10秒で処理します。
暗号化処理・変換後のデータは自動削除
保険証書から抽出できる項目
受け取る保険証書のレイアウトごとに新しいテンプレートを作成する手間を省けます。必要な列名を一度入力するだけで、AIがすべてのCOIから該当する値を自動で見つけ出します。標準的なACORD 25レイアウトでも、保険会社独自の証明書形式でも対応可能です。1セットの列名で、取引先のすべての保険会社の証明書にそのまま使えます。
このツールはカスタム列抽出を使用します。出力スプレッドシートの列名を「Named Insured」「GL Each Occurrence Limit」「Expiration Date」など自由に指定でき、AIがフィールドラベルの意味と文書内の視覚的な配置を理解して、各COIから該当する値を特定します。つまり、1セットの列名が、異なる保険会社のACORD 25フォーム、非標準の独自形式のCOI、レイアウトがずれた古いスキャン済み証明書にも対応できます。保険会社ごとにテンプレートや座標マッピングを設定する必要はありません。
テンプレート型抽出がCOIで機能しない理由と、本ツールの違い
ACORD 25フォームは保険業界の共通言語とも言える存在で、保険に関わるすべての関係者が補償内容の伝達に使用する標準フォーマットです。しかし「標準フォーマット」と「標準的な書類」は同じものではありません。各代理店管理システムはフォームを微妙に異なる形で描画し、1枚の保険証券には実際には3〜4件の独立した補償契約が密集したグリッドとして含まれており、フラットなOCRではその構造を理解できません。
1枚の証明書には3〜4件の独立した保険契約が密集したグリッド状に並んでいますが、フラットOCRは列ごとに縦方向ではなく、行ごとに左から右へ読み取ります。 ACORD 25の補償セクションには、一般賠償責任（General Liability）、自動車賠償責任（Auto Liability）、アンブレラ/超過（Umbrella/Excess）、労災（Workers' Comp）の行と、保険会社、証券番号、開始日、満了日、限度額の列があります。座標ベースで読み取るテンプレート型OCRでは、自動車行の満了日が一般賠償責任行の限度額とずれて一致し、誤ったデータを静かに生成する可能性があります。Redditでは、プロジェクトマネージャーが 1日を費やしてCOIデータを手動で検証していると述べており、「このスプレッドシートで日付を1つ見落とせば、会社に数百万ドルの損害が出る可能性がある」としています。
追加被保険者（Additional Insured）フィールドはチェックボックスであり、チェックボックスは座標ベースのOCRでは認識できません。 ACORD 25では、追加被保険者のステータスは「業務内容（Description of Operations）」セクションの横にあるチェック済みまたは未チェックのボックスとして表示されます。テキストフィールドや金額を読み取るように訓練されたOCRツールは、チェックボックスの状態を完全にスキップすることが多く、最も重要なコンプライアンス上の疑問（「この下請け業者の保険は当社を被保険者として裏書されているか？」）が未回答のままになります。コンプライアンス専門家が指摘するように、COIのチェックボックスだけでは有効とはみなされません。実際の裏書の存在を確認する必要がありますが、チェックボックスの抽出がなければ、その確認を始めることすらできません。
保険会社のレターコード（A、B、C、D）はリレーショナルなマッピングを形成しており、フラット抽出では失われます。 ACORD 25では、補償テーブルの「Insr Ltr」列の文字指定を使用して、各補償行をヘッダーに記載された特定の保険会社に結び付けています。代理店名と保険会社名は別々のブロックに表示されます。各セルを独立して読み取るフラット抽出では、A → 保険会社の関係が保持されないため、手作業で修正しなければ、どの保険会社がどの補償行を引き受けているかを把握することは不可能です。
列を一度定義するだけで、AIが各補償行を個別に読み取り、最終スプレッドシートには保険ごとに1行ずつ出力されます。 「補償種別」「保険証券番号」「各事故限度額」「満期日」という列を定義すると、AIは表内の各補償行を個別のデータレコードとして識別します。GL行とAuto行はそれぞれ出力の別々の行になり、被保険者名と証明書保持者名の値は複数の行に繰り返し表示されるため、出力は完全なリレーショナルコンテキストを保持します。補償種別でフィルタリングしたり、満期日で並べ替えたりすることができます。
AIはピクセル座標ではなく文書の視覚的構造を読み取ることで、チェックボックスの状態、保険会社の略号、密集したグリッドレイアウトを認識します。 「追加被保険者」ボックスにチェックが入っていれば「はい」を意味すること、「Insr Ltr」列の「A」が「Insurer A」ヘッダーブロックの保険会社に対応すること、そして「General Liability」とラベル付けされた補償行には、その下の「Auto Liability」行とは異なる独自の保険証券番号、日付、限度額があることを理解します。この意味論的な読み取りは、保険会社のレンダリングシステムが各要素をページ上のどこに配置するかに関係なく機能します。
1つの列定義が、ACORD標準形式か独自形式かを問わず、あらゆる保険会社のCOIで機能します。 証明書がTravelersが発行するシステム生成のACORD 25であっても、地域の保険会社による独自形式であっても、小規模な下請け業者がメールで送ってきたスキャン済みPDFであっても、同じ列名で同じデータ型を抽出できます。保険会社ごとのテンプレート設定は不要です。手動の座標マッピングも不要です。列を一度入力するだけで、AIはどこでも値を検出します。
下請け業者のCOIバッチ処理の流れ
アップロード：下請けから届くものをそのまま受け取る
20社の下請けからCOIを受け取ります。Applied Epicからシステム生成されたACORD 25のPDF、保険会社独自の証明書形式、さまざまな解像度のスキャンコピーなど、形式はさまざまです。ある下請けは追加被保険者の承認ページが添付されたCOIを送ってきます。これらすべてをまとめて1つのバッチとしてアップロードしてください。形式、保険会社、文書タイプによる事前の仕分けは不要です。
列の定義：コンプライアンス管理表に必要な項目を指定
出力するスプレッドシートの列名を入力します：Named Insured、Certificate Holder、Carrier、Coverage Type、Policy Number、Each Occurrence Limit、Effective Date、Expiration Date、Additional Insured。また、計算列を定義することもできます。たとえば、Days Until Expirationという列を設け、AIに満了日から今日の日付を引くよう説明を加えれば、Excelで別途数式を組むことなく、出力に即時のコンプライアンス状況を示す指標を含めることができます。
出力：全下請けのすべての補償行を1つのスプレッドシートに
Excelファイルをダウンロードすると、各行が1つのCOIの1つの補償タイプに対応します。GL＋自動車＋労災の補償がある下請けは3行分のデータになり、各行でNamed InsuredとCertificate Holderの値は同じですが、各補償セクションの保険証券番号、限度額、日付は異なります。出力はピボットテーブルにそのまま使えます。補償タイプでフィルタリングすれば全下請けのGL限度額をひと目で確認でき、満了日で並べ替えれば更新が必要な保険を把握でき、保険会社別にグループ化すればベンダーポートフォリオ全体の補償集中度を監査できます。追加被保険者のステータスはYes/No列で表示され、確認済みは緑、未確認は空白になります。XLSX、CSV、JSONのいずれかでエクスポートできます。
最適な用途と結果の確認が必要なケース
標準的なACORD 25および保険会社フォーマットのCOIでは、抽出精度は高い水準です。大量バッチを処理する前に、いくつかの書類条件とCOI特有の複雑さを理解しておくことをお勧めします。
確実に処理
システム生成のACORD 25証明書。Applied Epic、Vertafore、AMS360、その他の代理店管理システムで作成されたCOIは高い精度で抽出されます。AIが標準化されたセクションヘッダー（一般賠償責任、自動車賠償責任、アンブレラ/超過、労災）を読み取り、各行の保険証券番号、日付、限度額を正しい出力列にマッピングします。
保険会社独自の証明書形式。大手保険会社の多く（Travelers、Liberty Mutual、Chubb）は、ACORD 25ではなく独自形式で証明書を発行します。AIはACORDのレイアウトテンプレートに一致させるのではなく、フィールドラベルを意味的に理解することで、同じフィールドタイプ（被保険者名、保険会社、補償限度額、日付）を抽出します。
下請け業者COIの一括処理。複数の下請け業者からCOIをアップロードし、それぞれが異なる保険会社・異なる形式であっても、1つの列定義で全て処理できます。各証明書は個別に処理され、出力されるExcelには全下請け業者が1つのシートにまとめられます。
200dpi以上のスキャン紙COI。印刷された証明書の鮮明なスキャン（旧版のACORD 2010/05および2016/03を含む）も確実に抽出できます。追加被保険者のチェックボックス状態は、スキャン画像がチェックの有無を判別できるほど鮮明な場合に取得されます。
以下のケースを確認してください
追加被保険者の承認ページは、メインのCOIとは別の文書です。 AIはACORD 25フォーム自体から追加被保険者のチェックボックスを抽出しますが、実際の承認文言（どの事業体が指定され、どの補償が拡張されるかを明記するもの）は、別の添付ページに記載されています。承認ページをCOIと一緒にアップロードすると、追加被保険者名の列を定義でき、AIが承認ページから抽出します。現在のバージョンでは、承認ページを証明書番号によって親のCOIに自動的に関連付けることはできません。出力の各承認行が正しい証明書に対応していることを確認してください。
小さな文字や筆記体で手書きされたCOI。 エージェントがACORD 25のフィールドに保険証券番号、日付、または限度額を手書きで記入する場合、特に補償テーブルの狭いグリッドセル内では、AIの手書き文字認識精度が印刷テキストの基準値を下回ります。Confidence列を追加して、手動レビューが必要な低信頼度の行をフラグ付けしてください。特に保険証券番号や金額など、1桁の誤読が重要となるフィールドに有効です。
継続フォームにまたがる業務内容の説明。 ACORD 25の業務内容の説明セクションが「別紙参照」やACORD 101継続フォームへの参照で省略されている場合、AIはACORD 25自体に存在するテキストのみを抽出します。継続フォームのテキストは、メインの証明書と一緒にアップロードに含まれている場合にのみ取得されます。
グラフィックや画像ベースの形式を多用する保険会社からのCOI。 一部の地域保険会社は、テキストレイヤー付きの文書ではなく、PDF内のフラットな画像レンダリングとして証明書を発行します。AIはこれらの文書も視覚認識を通じて処理しますが、精度は画像の解像度とコントラストに依存します。出力にNamed Insured列やCarrier列で予期しない空白や文字化けした値が表示される場合は、ソースPDFに選択可能なテキストレイヤーが含まれているか、純粋にグラフィックのみかを確認してください。純粋にグラフィックのみの文書は、より高い解像度でアップロードすると効果的です。
よくある質問
あらゆる保険会社のACORD 25フォームに対応できますか、それとも正確な標準レイアウトを使用しているものだけですか？
どの保険会社または代理店管理システムが作成したものであっても、ACORD 25フォームを処理できます。AIはピクセル座標に依存するのではなく、フィールドラベルとセクションヘッダーを意味的に読み取るため、保険会社間の位置の違い（ある保険会社が「Certificate Number」を別の保険会社より10ピクセル高い位置に表示する場合など）は抽出に影響しません。ACORDレイアウトにまったく従っていない保険会社独自のフォーマットにも対応しています。「Named Insured」「Policy Number」「GL Each Occurrence Limit」などの列を定義すると、AIは周囲のラベルテキストと視覚的なコンテキストを理解して、ページ上のどこからでも対応する値を特定します。
General Liability、Auto、Umbrella、Workers' Compの各行が分かれた複数行の補償テーブルにはどのように対応しますか？
ACORD 25の補償テーブル内の各補償行は、出力されるExcelの各行になります。「Coverage Type」「Policy Number」「Each Occurrence Limit」「Expiration Date」などの列を定義すると、AIが各補償セクションの行を個別に識別し、GL行の保険証券番号・限度額・日付を1つの出力行に、Auto行を次の行に、Umbrella行をその次の行に、Workers' Comp行をその次の行に抽出します。出力では、証明書ヘッダー（Named Insured、Certificate Holder、Producer）と補償レベルの詳細との間の1対Nの関係が保持されます。Named InsuredとCertificate Holderの値は関連するすべての行で繰り返されるため、下請け業者と補償タイプの任意の組み合わせでフィルタリング、並べ替え、ピボットが可能です。これは、テーブルのグリッドを左から右に読み取り、Auto行の日付とGL行の保険証券番号がずれてしまう可能性があるフラットなOCRとは根本的に異なります。
追加被保険者のチェックボックス検出は、スキャンしたCOIでもどの程度正確ですか？
代理店管理システムで生成されるCOIの大半を占めるクリーンなデジタルPDFの場合、チェックボックス検出は信頼性が高く、マークされたボックス（Xまたはチェック）は「はい」、マークされていないボックスは「いいえ」として一貫して識別されます。スキャンした紙のCOIの場合、精度はスキャン品質に依存します。200 dpi以上の鮮明なスキャンでは、チェックボックス検出は信頼性の高い結果が得られます。解像度の低いスキャンや、チェックボックスのグリッド線がぼやけるFAXコピーでは精度が低下します。この違いが重要なのは、追加被保険者のチェックボックスが重要なコンプライアンス指標だからです。これは、下請け業者の保険があなたを追加被保険者として指名するよう裏書されているかどうかを示し、請求が発生した場合の法的立場に影響します。バッチ内の最初の数枚のスキャンCOIで追加被保険者列をスポットチェックし、出力パターンがソース文書と一致することを確認してから、自信を持って処理を進めることをお勧めします。
コレクションリンクと連携して、下請け業者が自分のCOIを直接アップロードできるようにすることはできますか？
はい。ImageToTable.aiにはコレクションリンク機能が含まれています。これは、各下請け業者に送信できる共有可能なURLです。下請け業者はリンクを開き、短い確認コードを入力して、COIを直接処理キューにアップロードします。相手側での登録やログインは不要です。ファイルは、あらかじめ定義した列名で抽出できる状態でアカウントに届きます。これにより、COIの依頼、催促、転送といったメールの往復がなくなり、すべての証明書がメールのスレッドに散らばるのではなく、フォーマットが一貫した処理パイプラインに届くようになります。処理後、抽出されたデータは、直接アップロードしたCOIとともにExcel出力に反映されます。
「被保険者」欄についてはどうですか？名前が似ている場合、被保険者と証明書保持者を区別できますか？
はい、可能です。ACORD 25では、被保険者（Named Insured）は明確なブロック（通常は左上の被保険者セクション）に表示され、証明書保持者（Certificate Holder）はページのさらに下にある別のブロックに表示されます。AIは視覚的な階層を読み取ります。「INSURED」または「PRODUCER」（標準的なACORD 25の左側）に記載されている主体が保険契約者であり、「CERTIFICATE HOLDER」に記載されている主体が証明書の提示を求める当事者であることを理解します。この意味的な読み取りにより、両方の名前が構造的に似ている会社名であっても（例：被保険者が「ABC Construction LLC」、証明書保持者が「ABC Development Corp」）、各当事者が正しい出力列に正しく割り当てられます。これは座標ベースのOCRが失敗するもう一つのケースです。異なる保険会社のACORDレンダリング間で2つの名前ブロックの位置がずれる場合、固定座標で名前を期待するテンプレートは警告なしに2つの当事者を入れ替えてしまいます。