AIA G702 & G703データ抽出の完全ガイド
AIA G702 & G703データ抽出

AIA G702・G703様式とは

AIA G702（正式名称：支払申請兼証明書）は、米国のほぼすべての商業建設プロジェクトで使用される標準的な進捗請求書です。その補完書類であるG703継続シートは、要約数値を裏付ける明細項目の内訳を提供します。これら2つを合わせて、業界では支払申請パッケージと呼びます。米国建築家協会（AIA）が開発・著作権を有するこれらの様式は、進捗支払いを請求するための統一された仕組みを提供します。20万ドルのテナント内装工事でも、2億ドルの病院建設でも、同じフォーマットが使用されます。

G702は1ページの要約で、プロジェクト全体の財務状況を把握します。元の契約額、承認された変更命令による調整、現在までの完了工事および保管資材の総額、保留されている保留金、これまでに受領した支払い、そして現在支払われるべき正味額を記録します。建築家または発注者がこの様式を認証し、その後支払いが行われます。理論上は30日以内ですが、実際にはエラーが再提出サイクルを引き起こすと、さらに長引くことがよくあります。

G703継続シートは詳細が記載される場所です。各行はプロジェクトの価値表（SOV）の1つの明細項目を表し、各列はその明細項目の財務進捗の異なる側面（予定価額、前期完了工事、今期完了工事、保管資材、累計、完了率、残工事残高、保留金）を追跡します。30の明細項目があるG703には約270の個別データポイントが含まれ、そのすべての数値がG702の要約に反映されます。この2つの様式は独立した書類ではなく、親子関係のデータ構造であり、G702の合計はG703の総合計と一致しなければなりません。一致しない場合、申請は未払いで返却されます。

G702/G703のデータ抽出は、近年、相互に関連する3つの理由から注目を集めています。第一に、ゼネコンが処理する支払申請の量はプロジェクトごとに増加し、専門化が進むにつれて、一般的な商業プロジェクトにおける下請け業者の数も増加しています。第二に、Procore、Viewpoint、Sage 300 CRE、CMiCなどの建設会計・プロジェクト管理プラットフォームは構造化データを期待しており、記入済みのPDFフォームを取り込んで自動的に原価台帳に入力することはできません。第三に、テンプレートの位置を照合するのではなく、セマンティクスを理解することでこれらの様式を読み取ることができるAIツールが、信頼できる精度レベルに達したのは、ここ18～24か月のことです。様式自体は変わっていません。そこから抽出する能力が変わったのです。

G702/G703の処理が思った以上にコストがかかる理由

支払申請書の処理にかかる目に見えるコストは、PDFを開き、数字を読み取り、スプレッドシートに入力する時間です。30の明細項目を持つG703を備えた単一の申請書の場合、有能なプロジェクト会計担当者はその作業を約30〜45分で完了します。隠れたコストはその作業の周辺で発生します。毎月のドロー締切により、すべての申請書が3日間のウィンドウに圧縮され、保証金のエラーにより30日間の支払い時計をリセットする再提出サイクルが発生し、フォーム間の不一致によりサブコンラクターとの調整電話が必要になり、AIAフォーム自体も新しいプロジェクトが始まるたびにコストがかかります。個々にはこれらのコストは小さく見えます。しかし、それらが合わさると、多くの中規模ゼネラルコンラクター（GC）にとってフルタイムの給与に相当する額になります。

毎月のドロー・サイクル。商業建設の支払申請書は固定された毎月のリズムに従います。サブコンラクターは締切日（通常は月の20日または25日）までに支払申請書を提出します。GCはそれらをレビュー、検証し、月末までにオーナーへのドロー申請書に統合します。承認された場合、オーナーの支払いは30〜45日後に到着します。締切に間に合わない場合、サブコンラクターの支払いは請求サイクル全体、つまり30日ではなく60日遅延します。プロジェクト会計担当者が4日間で40件の支払申請書を手動処理している場合、1件か2件の締切を逃すリスクは理論上の話ではありません。再入力チェーンの別のウォークスルーで、遅いG702データ入力が支払いサイクルをどのように延長するかを詳しく解説しています。建設財務管理協会の2025 Financial Benchmarkerは、1,558社の2024会計年度データに基づき、一般的な建設会社の税引前利益率は6.7パーセントであると報告しています。遅延した申請書、修正サイクル、再提出のすべてがその利益率を直接侵食します。

保証金の計算エラー。保証金（プロジェクト完了まで差し引かれる各支払いの割合）は、支払申請書の紛争の最も一般的な原因です。ほとんどの契約は、完成した作業と保管資材の総額に適用される固定率（通常5または10パーセント）を指定します。しかし、計算は「G702の4行目の10パーセントを取る」ほど単純ではありません。多くの契約は変動保証金を使用します。作業が50パーセント完了すると率が10パーセントから5パーセントに引き下げられるか、保管資材の保証金が設置済み作業の保証金とは異なる率で計算されます。一部の州では法定の保証金上限を課しています。カリフォルニア州は民間プロジェクトで50パーセント完了後の保証金を5パーセントに制限しており、これは契約率を上書きします。契約が5パーセントを指定しているのに10パーセントで保証金を計算したサブコンラクターは、過大請求の支払申請書を提出したことになり、パッケージ全体が修正のために返却されます。エラーは通常小さく、数千ドル程度ですが、再提出の遅延によりプロジェクトの全員に2〜4週間のコストがかかります。

G702-G703フォーム間検証。 G702のサマリーはG703の明細項目合計から数値を引用します。G702の4行目の「現在までの完了・保管合計」は、G703のG列の総合計と一致する必要があります。G702の5行目の保証金は、G703のI列の総合計（またはG703合計に適用される固定率計算）と一致しなければなりません。プロジェクト会計士がこれらの数値を手作業で転記する際、最も一般的なエラーは、G703からの累計合計を誤ったG702の行に入力することです — 「完了合計」を保証金フィールドに入力したり、「前回確定額」を「今回支払い額」として入力したりします。フォーム自体には組み込みの計算式があります。6行目から7行目を引くと8行目になり、3行目から6行目を引くと9行目になります。単一フィールドの転記ミスは、派生するすべての行に連鎖し、内部計算が整合しないG702を生成します。申請書を審査する建築士は数秒で不整合を発見し、パッケージ全体を却下します — この失敗モードについては、支払申請書の紛争を引き起こす一般的なG702抽出エラーで詳しく検討します。

AIAフォームの費用。 標準的な発注書や納品書とは異なり、AIAフォームは著作権で保護された文書です。AIA契約文書を通じて一回限りの使用として購入される単一のG702/G703セットは、およそ49.99ドルかかります。または、年間約500ドルから始まるAIAソフトウェアサブスクリプションを通じて一括購入する場合、セットあたり約15〜25ドルです。5つのプロジェクトで50のアクティブなサブコンラクターを管理するゼネラルコンラクター（GC）の場合、年間フォーム費用は750〜2,500ドルです — 大きな金額ではありませんが、GCがすでに処理する必要がある請求データの形式を標準化する以外に価値を追加しない継続的な運用経費です。

G702/G703の親子構造：サマリーページと継続シート

これらのフォームからデータを抽出する際に、各ページを独立して読むだけでは不十分な理由を理解するには、まずそれらの構造的な関係を理解する必要があります。G702とG703は、一緒に提出される2つのフォームではありません。同じ財務データの2つのビューであり、信頼できる抽出ツールが読み取りと検証の両方を行う必要がある一連の算術的制約によってリンクされています。

G702は親フォームです。契約全体をカバーする9行の財務サマリーで構成されています。その行は以下のとおりです：

この9行のうち3行はG703から繰り越されます（行4、およびそれに伴い行5〜9）。4行は算術的な導出です（行3、6、8、9）。2行は契約からの固定入力です（行1と2）。G702の表紙のみを読み取る抽出ツールは、サマリー数値を取得できますが、そのソースに対して検証することはできません。また、データを分解できる唯一の場所であるG703も見逃してしまいます。

G703は子フォームです。各行が価値一覧表（SOV）の明細項目であり、各列が請求期間ごとのその明細項目の財務進行状況を追跡する、可変長のテーブルです。標準的なG703継続シートは、データを次の列に整理します：

G703の各行は、その特定の作業範囲に関するミニ財務諸表です。G列の総合計はG702の行4と一致する必要があります。I列の合計は行5と一致する必要があります。これらのフォーム間検証の制約こそが、支払申請書の抽出を請求書の抽出と異なるものにしています。単一の文書からフィールドを読み取るだけではなく、2つの部分からなるデータ構造を読み取り、2つの部分間の算術的な整合性を検証しているのです。この抽出が実際にどのように機能するかのステップバイステップのチュートリアルについては、AIA G702支払申請データをスプレッドシートに抽出する詳細ガイドをご覧ください。

支払申請書データ抽出に潜む課題

フォームが正しく記入されている場合でも、G702/G703パッケージからのデータ抽出には、他の建設文書タイプには存在しない課題があります。これらの課題は、支払申請書を大規模に処理した経験がない人にはすぐには明らかになりません。

手書きの変更命令と数量。デジタルAIAフォームが広く利用可能であるにもかかわらず、サブコンラクターの支払申請書のかなりの部分が手書きの記入で届きます。現場で注記されたG703は一般的です。サブコンラクターのプロジェクトマネージャーが価値一覧表（SOV）を印刷し、当期数量を手書きで記入し、余白に完了率を計算し、注記されたシートをPDFにスキャンします。複数のプロジェクトで活動するサブコンラクターは、手書きで注記された変更命令ログを1部作成し、AIA変更命令サマリーテーブルを使用せずに支払申請書に添付することがあります。ページ上のピクセル位置でデータフィールドを特定する従来のOCRやテンプレートベースの抽出ツールは、手書きの値がレイアウトを変えるため、これらの文書では機能しません。数量欄に手書きの「1,247」があると、隣の金額が1セル右にずれ、テンプレート抽出は何かが間違っているという信号なしに誤った値を返します。対照的に、ビジョンベースのAI抽出は各値を意味的な文脈で読み取ります。「今期完了作業」列の数字を、ページ上部からのピクセルオフセットを測定するのではなく、ヘッダーに「今期完了作業」と書かれた列にあることを理解して識別します。

CSI MasterFormatコード。ほとんどのG703継続シートは、建築仕様書協会（CSI）が維持する標準化された分類システムであるCSI MasterFormat区分番号を使用して明細項目を整理します。典型的なG703には、「03 30 00 — 現場打ちコンクリート」、「08 11 00 — 金属製ドアおよびフレーム」、「23 31 00 — HVACダクト工事」、「26 10 00 — 中圧電気設備」などの明細項目が記載される場合があります。これらのコードはジョブコスト計算にとって重要です。プロジェクト会計士は、コンクリート工事の47,000ドルが汎用カテゴリの「コンクリート」ではなく、コストコード03 30 00に属することを知る必要があります。明細項目の説明を構造化されていないテキストとして取得する抽出ツールは、構造化されたコストコードを失います。MasterFormat階層を認識するツールは、区分番号を別の列に出力し、明細項目の請求とジョブコスト配分の間のマッピングを維持できます。建築仕様書カナダ協会と連携してCSIが発行した現在のMasterFormat 2026年版は、建設仕様書を50区分（区分00（調達および契約要件）から区分49まで）に整理し、2026年更新で約2,185件の新規リストが追加されています。

変更命令にわたる契約額の追跡。建設プロジェクトが当初の契約額で完了することはほとんどありません。変更命令は、プロジェクトの進行に伴って作業を追加、削減、または価格を調整します。G702はこれをライン1、2、3で追跡します。当初額、正味変更額、調整後合計額です。しかし、G702の変更命令サマリーは単一の数字にすぎず、個々の変更命令やそのステータス（承認済み、保留中、紛争中）はリストされません。サブコンラクターは、変更命令ログやCO送付シートを支払申請書パッケージに添付することがよくあります。G702フィールドのみを取得する抽出ワークフローでは、プロジェクト会計士が正味変更額が正しいことを検証するために必要な補足詳細を見逃します。契約データ抽出に関するより広い教訓がここに当てはまります。構造化抽出は、サマリー文書だけでなく、それを支える補足文書も読み取るときに最も効果的に機能します。

フォーム間検証の複雑さ。G702とG703の間の算術的な制約は、列の合計の単純な一致を超えています。現在の支払申請書のG703の列D（前回申請時までの完了工事）は、前回の支払申請書のG703の列G（現在までの完了・保管合計）から、前回の期間の列F（保管材料）を差し引いたものと等しくなければなりません。サブコンラクターがプロジェクト途中で価値一覧表（SOV）を変更した場合（明細項目を2つに分割する、またはスコープ間で価値を再配分する）、この繰り越しが崩れ、ゼネラルコンラクター（GC）が手動で差異を調整する必要があります。各支払申請書を独立した文書として扱う抽出ツールでは、この不一致を検出できません。連続する支払申請書を読み取り、繰り越し値を比較するツールなら、検出できます。

従来型 vs. AI：支払申請書抽出の2つのアプローチ

従来型の支払申請書抽出とAIベースの抽出の違いは、速度の問題ではありません。どちらも1ページを数秒で処理できます。違いは、バリエーション、エラー、フォーム間の関係性への対応方法にあります。

スプレッドシート参照による手動コピーペースト。従来のアプローチ：サブコンラクターのG702 PDFを開き、4行目（完了・保管合計）を読み取り、プロジェクト追跡スプレッドシートのそのサブコンラクターの行に入力します。G703を開き、最初の明細項目から始めて、項目番号、説明、予定価格、前回完了、今期、保管、合計、パーセント、残高、保証金を入力します。30行に対して各行10フィールドです。このサイクルで支払申請書を提出する40のサブコンラクターそれぞれについて、このプロセスを繰り返します。このプロセスは単純明快で、ソフトウェアへの投資は不要です。また、請求サイクルごとに少なくとも数件の転記エラーが発生することが保証されています。Journal of Construction Engineering and Managementに掲載された建設業界のデータ入力精度に関する研究では、数値の建設データの手動転記では、フィールドあたり0.5〜2.5パーセントのエラー率が発生することが判明しています。1つの申請書あたり300の値、40の申請書で、請求サイクルごとに60〜300のエラーが発生します。ほとんどは小さなエラーです。しかし、一部はそうではありません。

テンプレートベースのOCR。Docparserなどのテンプレートベースの抽出ツールや従来のOCRプラットフォームは、転記の問題を解決しますが、メンテナンスの問題を引き起こします。G702のサマリーページ用のテンプレートを作成します：位置（x=200、y=150）に元の契約金額を取得するゾーンを定義し、位置（x=200、y=180）に正味の変更命令を取得するゾーンを定義し、9つの行すべてについて同様に定義します。G703のテーブル用に2つ目のテンプレートを作成します：テーブルの境界線を基準にしたピクセル座標でテーブルのセルを取得する列ゾーンを定義します。テンプレートは、最初のサブコンラクターがデジタル提出したフォームでは完璧に機能します。2番目のサブコンラクターが、印刷時にテーブルが3ミリメートル左にずれたスキャン済みのG703を提出すると、機能しません。3番目のサブコンラクターが、フォームフィールドの位置が少し異なる別のPDFエディターを使用すると、機能しません。手書きのG703が届き、テーブル構造が不規則な場合は、完全に機能しません。失敗のたびに、新しいテンプレートまたは既存のテンプレートの調整が必要になります。そして、その調整により、以前は機能していたフォームのカバレッジが壊れます。

Custom Column ExtractionによるセマンティックAI抽出。 最新のビジョン抽出技術は、G702/G703フォームを読み取る際、各フィールドがページ上のどこにあるかではなく、その意味を理解します。これがCustom Column Extractionです。出力スプレッドシートに必要な列（「元請契約額」「完了・保管済み合計」「保証金率」「項目番号」「説明」「予定価値」「今期完了工事」「現在までの完了合計」「残高」）を定義すると、AIが文書全体を読み取り、フォーム内での意味的役割に基づいて各列に対応する値を特定し、構造化された行として出力します。最初のサブコンラクターのデジタルG702も、2番目のサブコンラクターの手書きスキャンも、同じ出力列を生成します。AIが「保証金」が何であるかを知っており、通常どこに表示されるかを知っているからです。

異なる抽出ツールがAIA G702フォームを他の建設文書タイプとともにどのように処理するかを実践的に比較するには、2026年の建設業界向け最高の文書抽出ソフトウェアの記事で、8つのプラットフォームを共通のテストセット（35の建設文書）でテストし、支払申請書に特化したフィールドレベルの精度ベンチマークを提供しています。

計算列：算術ループを閉じる

G702/G703抽出で最も有用な機能の1つは、抽出パス中に派生値を計算する列を定義できることです。これにより、抽出後のスプレッドシート数式が不要になります。これが計算列の領域です。AIが他の抽出値に対して指定された計算を実行し、その結果をデータ行の一部として出力する列です。

支払申請書の抽出には、特に価値のある3つの計算列があります：

• 保証金の検証 — 抽出された「現在までの完了済み合計」に契約上の保証金率を乗算する計算列を定義します。G702に記載された保証金額がこの計算値とわずかな許容差（例：$1.00）を超えて異なる場合、抽出は不一致をフラグし、レビュー担当者は申請を承認する前に調査できます。
• フォーム間検証 — G703の列G（現在までの完了済み合計）をすべての明細項目で合計し、その結果をG702の行4と比較する計算列を定義します。これは支払申請書で最も重要な算術チェックであり、これを自動化することで再提出の最も一般的な原因を排除します。
• 完了までの残高のロールアップ — 累計獲得額と保有保証金を契約額から差し引いて、現在までの残りの契約価値を計算します。これにより、プロジェクトチームはサブコンラクターが次の支払申請書を提出するのを待たずに、各作業範囲に残っている予算をリアルタイムで把握できます。

これらの計算列は、抽出後にユーザーが数式を入力する必要はありません。抽出設定で指定されます。列名の一部（例：「保証金チェック（完了済み合計×10%）」）またはツールのルール形式でのJSONルールとして指定され、AIは抽出パス中に計算を実行します。結果として、レビューアーがファイルを開く前に、支払申請書の正確性を検証する列が入力された出力スプレッドシートが生成されます。

バッチ処理：30件の支払申請書から1つの統合スプレッドシートへ

単一のG702/G703パッケージの抽出は概念実証に過ぎません。一度に30〜50パッケージを抽出してこそ、運用上の価値が現れます。支払申請書のバッチ処理は、請求書や領収書のバッチ処理とは異なるロジックに従います。出力が明細項目のフラットなリストではなく、プロジェクト・サブコンラクター・工事範囲の階層を保持する構造化された統合データになるためです。

ゼネラルコンラクター（GC）の統合ドロー・スケジュール（全アクティブプロジェクトにわたる全サブコンラクターの支払状況を追跡するマスタースプレッドシート）は、通常、プロジェクト、サブコンラクター、明細項目の3つのレベルでデータを整理します。7つの異なるプロジェクトからの40件のG702/G703パッケージをバッチ抽出する場合、最初の列がプロジェクト、2番目の列がサブコンラクター、残りの列が各明細項目の支払申請データを表す単一のスプレッドシートを出力する必要があります。40件の申請書にデジタルフォームと手書きスキャンが混在している場合、バッチ抽出はファイルごとに個別の設定を必要とせず、同じワークフローで両方を処理できなければなりません。

バッチ方式はフォーム間検証もより強力にします。サブコンラクターAのG703合計がG702合計と一致するかを単独で検証する代わりに、統合スプレッドシートにより、同じプロジェクトで類似した工事範囲を担当するサブコンラクター間で支払額を比較できます。これにより、乾式壁サブコンラクターが80％完了で請求している一方で、乾式壁の完了まで作業を開始できない塗装サブコンラクターが90％完了で請求している状況を検出できます。このようなパターンレベルの異常は、各申請書を個別に処理する場合は見えません。バッチ処理の詳細なワークフローについては、プロジェクトポートフォリオ全体にわたるAIA G702支払申請書のバッチ処理に関する専用ガイドを参照してください。

エクスポートと統合：データを必要な場所へ届ける

支払申請書のデータを抽出しても、そのデータが支払処理が行われるシステムに届かなければ意味がありません。ほとんどのゼネラルコンラクター（GC）にとって、そのシステムは次の3つのいずれかです：プロジェクト管理プラットフォーム（Procore、Viewpoint、CMiC）、建設会計システム（Sage 300 CRE、Foundation）、またはそれらのいずれかにデータを供給する一連のスプレッドシートです。

Excelエクスポート。 最も一般的な出力経路であり、最も柔軟性があります。適切に構造化されたG702/G703抽出では、G702のサマリーフィールドとG703の明細項目用に、個別のシートまたは明確にラベル付けされた列を持つExcelファイルが生成されます。G702シートには、プロジェクトごと・サブコンラクターごとに1行が含まれ、元請契約額、正味変更命令、現在までの契約額、完了・保管済み合計、保証金、前回支払額、今回支払額、完了までの残高の列があります。G703シートには、明細項目ごとに1行が含まれ、プロジェクトとサブコンラクターの識別子に加えて、10すべての明細項目列があります。プロジェクト会計担当者は、ピボットテーブル、SUMIF関数、またはPower Queryを使用して、自社の報告・支払処理ワークフローに必要な形式にデータを集計できます。

Google Sheets統合。 ドロー・スケジュールをGoogle Sheetsで管理しているチームの場合、抽出出力はGoogle Sheetsアドオンを介してアクティブなスプレッドシートに直接取り込むことができます。これにより、エクスポート・インポートの手順が完全に不要になります。アップロードされた支払申請書PDFが処理され、結果の構造化データがリアルタイムで指定されたシートに追加され、列ヘッダーはユーザーの既存の追跡テンプレートに一致します。セマンティック抽出がテンプレートベースのアプローチと根本的にどのように異なるかをより深く理解するには、COI抽出の完全ガイドで、保険証明書データに適用された同じパラダイムシフトを説明しています。

ProcoreおよびViewpoint統合。ProcoreのAI機能（Datagrid買収による）は、提出物、RFI、契約レビューに焦点を当てており、外部ドキュメントデータを支払処理モジュールに取り込むことは対象外です。Viewpoint（Trimble）は、VistaおよびSpectrum ERPプラットフォーム内でAIA請求機能を提供していますが、支払申請書はサブコンラクターから記入済みPDFとして受け取るのではなく、システム内で生成する必要があります。実際には、外部から受け取ったG702/G703パッケージの最も信頼性の高い統合経路は、ExcelまたはCSVエクスポートに続いてプロジェクト管理または会計プラットフォームへのインポートであり、その統合の品質は、抽出ツールが出力をどれだけ明確に構造化するかに完全に依存します。

出来高請求書抽出ツールの評価基準

すべての文書抽出ツールがG702/G703データ特有の要求に適しているわけではありません。以下の基準は、出来高請求書を処理できるツールと、完璧にフォーマットされたデジタルPDF以外では使い物にならない出力しか生成しないツールを区別するものです。

フォーム間の検証機能。最も重要な基準：ツールがG702とG703が関連書類であることを理解しているか？各ページを独立して処理するツールは、G702の集計数値とG703の明細項目を別々の無関係なデータ行として抽出します。出来高請求書に対応したツールは、G702データをG703データにリンクして出力するか、さらに優れている点として、抽出処理中に2つのフォーム間の不一致をフラグ付けします。この機能がない場合、抽出結果は2つのデータセットとなり、ユーザーが手動で調整する必要があります。これはまさに、抽出によって排除されるはずだった作業です。

保留金計算の検証。ツールは、保留金の割合と金額を構造化フィールドとして抽出するか、ユーザーが抽出された合計から期待される保留金を計算する計算列を定義できるようにする必要があります。「5%」を備考欄のテキスト文字列として返すだけのツールは、実際にはデータを抽出したことにはなりません。解釈の責任をユーザーに転嫁しているにすぎません。

手書き文字への対応。ツールがG703継続シートの手書き記入を読み取れない場合、プロジェクトの種類や関与する下請け業者にもよりますが、実際の下請け業者提出書類の約30～50％で失敗します。これを確実にテストする唯一の方法は、少なくとも3件の手書きまたは手書き注釈が入った出来高請求書（ベンダー提供のデモフォームではない）を含むサンプルセットを提出し、テストセット内のデジタル文書と手書き文書のフィールドレベルの精度を比較することです。

可変長G703のテーブル抽出。G703テーブルの行数は、10行から100行以上の明細項目まで様々です。固定テーブルレイアウトを処理できても、明細項目が2行にわたる場合や、下請け業者が印刷された行の間に手書きで行を挿入した場合に破綻するツールは、不完全な出力を生成します。少なくとも40行以上を含み、複数行の説明がある明細項目を少なくとも1つ含むG703でテストしてください。

CSI MasterFormatコードの保持。プロジェクトで原価計算にCSI区分コードを使用している場合、抽出ツールはコードと説明を別々の列に出力するか、少なくとも隣接するフィールドを切り詰めたり連結したりせずに、明細項目の完全な説明を保持する必要があります。「03 30 00 — 場所打ちコンクリート」を「03 30 00」に切り詰めるツールは、原価コードシステムに必要な情報をすでに失っています。

テンプレート不要のセットアップ。ツールは、ユーザーが領域を描画したり、モデルをトレーニングしたり、テンプレートを作成したりする必要なく、G702/G703パッケージを抽出できる必要があります。セットアッププロセス中にベンダーがサンプル文書を要求する場合、そのツールはテンプレートベースまたはトレーニングベースのアーキテクチャを使用しており、フォームが変更されたり、新しい下請け業者が異なる形式で出来高請求書を提出したりした場合にメンテナンスが必要になります。

よくある質問

AIA G702とG703の違いは何ですか？

G702は支払申請書兼証明書で、契約額、変更指示、完了累計、保留金、前回支払額、今回請求額など、契約レベルの財務状況を1ページにまとめたものです。G703継続シートは、出来高価格表に基づく明細項目の内訳を示し、各明細の予定価格、期間内の完了工事、現場保管材料、保留金を追跡します。G703の合計はG702の集計行に直接反映されます。

AIA G702およびG703フォームでの保留金の計算方法は？

G702の保留金は通常、4行目（完了および現場保管累計）の固定割合（通常5％または10％）で計算されます。G703では、明細ごとに異なる保留金率が適用される場合、各明細（I列）で計算できます。固定のプロジェクト全体の率が使用される場合は空白のままにします。抽出ツールの計算列を使用すると、抽出された合計から期待される保留金を自動計算し、不一致をフラグ付けすることで検証を自動化できます。

AIはG703継続シートの手書き記入を抽出できますか？

はい、ただし精度は手書きの読みやすさと抽出ツールのアーキテクチャに依存します。「今期完了工事」列の値が金額であり、日付や項目番号ではないことを理解するなど、意味的文脈で文字を読み取るビジョンベースのAIは、テンプレートベースのOCRよりも手書きG703で大幅に高い精度を達成します。読みやすい手書き記入では、最新のビジョンAIはフィールドレベルで約85～92％の精度を達成しますが、読みにくい手書きや注釈が多いフォームでは70～80％の範囲に低下します。実用的な回避策は、抽出出力に信頼度スコア列を設け、しきい値を下回る値のみをレビューすることです。

複数のサブコンラクターからG702パッケージを一度にバッチ処理できますか？

はい。バッチ処理は、AI抽出がゼネラルコンラクター（GC）にとって最も高い効果を発揮するシナリオです。すべての支払申請書PDF（デジタルまたは手書き、任意のサブコンラクター、任意のプロジェクト）を1つのバッチにアップロードしてください。AIは各フォームを個別に読み取り、G702およびG703データを抽出し、ソースファイルを識別する列を含む1つの統合スプレッドシートを出力します。バッチワークフローは混合フォーマットを自動的に処理します。一部のファイルはデジタルAIAフォーム、他のファイルはスキャンされた紙、さらに他のファイルはPDFに保存されたExcelエクスポートの場合があります。このワークフローの完全なチュートリアルについては、プロジェクトポートフォリオ全体でのAIA G702支払申請書のバッチ処理をご覧ください。

AIA G702フォームの使用には費用がかかりますか？

はい。AIA文書は公式のG702およびG703フォームの著作権を保有しています。単回使用のG702/G703セットは、AIAウェブサイトで約49.99ドルです。すべてのAIA文書への無制限アクセスが可能な年間サブスクリプションは、年間約500ドルです。多くの請負業者は、著作権で保護されたフォームを使用せずにG702/G703レイアウトを再現するスプレッドシートベースのバージョンを作成していますが、これらは手動データ入力が必要であり、建築家や所有者からの同じ受け入れを得られません。データ抽出はフォーム自体の必要性を置き換えるものではありません。完了したフォームから追跡システムへのデータ転送を自動化するものです。

ProcoreはG702/G703データ抽出をサポートしていますか？

ProcoreのAI機能は、Datagrid買収を通じて導入され、契約文書、提出物、RFIの分析に焦点を当てています。受信した支払申請書PDFからの構造化データ抽出には対応していません。Procoreはプラットフォーム内でG702/G703フォームを生成するためのAIA請求機能を提供していますが、これは文書作成ツールであり、サブコンラクターから受け取ったフォームの抽出ツールではありません。最も一般的な統合パスは、専用の抽出ツールを使用してG702/G703データを抽出し、構造化された出力をExcelまたはCSVアップロードを介してProcoreにインポートすることです。

CSIマスターフォーマットコードはG702/G703抽出にどのように影響しますか？

ほとんどのG703継続シートは、項目をCSIマスターフォーマット区分コード（建設仕様協会が管理する標準化された番号体系）で識別します。この体系は6桁の数字（例：03 30 00＝現場打ちコンクリート、08 11 00＝金属製ドア・枠、23 31 00＝HVACダクト工事）で構成されています。これらのコードを使用するプロジェクト会計やジョブコスト業務では、抽出ツールは隣接フィールドを切り詰めたり結合したりせず、完全なコードと説明を保持する必要があります。現行版のMasterFormat 2026では、50区分の枠組みに約2,185の新規リストが追加されています。

変更命令の追跡はG702/G703抽出でどのように機能しますか？

G702は変更命令を2行目の単一の純額（元の契約金額に対する承認済み追加・控除の合計）として捕捉します。個別の変更命令、そのステータス、または裏付け文書は記載されません。包括的な抽出ワークフローでは、G702の純変更額だけでなく、下請け業者が支払申請パッケージに含める変更命令ログや変更命令送付状も捕捉する必要があります。これにより、プロジェクト会計担当者は純額がプロジェクトの変更命令台帳と照らし合わせて正確であることを確認するために必要な詳細を入手できます。

G702/G703抽出ではどの程度の精度が期待できますか？

印刷されたテキストのクリーンなデジタルフォームの場合、ビジョンベースのAI抽出によるフィールドレベルの精度は、G702およびG703の全フィールドで通常92～98パーセントです。手書き入力のあるフォームの場合、精度は手書きの読みやすさとフォームの状態に応じて80～92パーセントの範囲です。最も重要な運用指標は生の精度ではなく、エラー検出率です。計算列とクロスフォーム検証を備えた適切に設計された抽出ワークフローは、予想範囲外の値をフラグ付けするため、レビュー担当者はすべての数値を手動で再確認するのではなく、どのフィールドを検査すべきかを正確に把握できます。

G702/G703抽出データをViewpointやSage 300 CREに連携する最適な方法は？

Viewpoint（TrimbleのVistaおよびSpectrum）とSage 300 CREは、システム内で作成した支払申請用のAIA請求書生成モジュールを備えていますが、外部から受領したG702/G703 PDFの構造化データを直接取り込む機能はありません。標準的な連携方法は、抽出結果をExcelまたはCSVにエクスポートし、各プラットフォームの売掛金管理またはジョブ原価計算モジュールが備えるインポート機能を使って取り込むことです。一部のゼネコンはAcumaticaやRabbitMQなどのミドルウェアを使って転送を自動化していますが、ほとんどの企業にとっては、プラットフォームのインポートテンプレートに合わせて列をマッピングした、適切に構成されたExcelエクスポートが最も実用的な解決策です。

G702とG703は、建設書類として最も標準化されたフォームです。AIAが業界全体で進捗請求の統一フォーマットを実現するために設計しました。しかし、フォームの標準化は、その後のデータ入力プロセスを標準化するものではありません。各支払申請書は、ある時点におけるプロジェクトの財務状況を示すスナップショットであり、予算の追跡、進捗の確認、支払いの実行に必要な情報を含んでいます。このスナップショットを追跡システムに接続する抽出レイヤーは、月に数十件の申請書を処理するゼネコンにとって贅沢品ではなく、手作業による転記で避けられないエラー率を受け入れずにボリュームを処理する唯一の信頼できる方法です。

1件の支払申請書をアップロードして、セマンティック抽出が協力業者のフォームをどのように処理するかをご確認ください。または、30件の申請書を一括処理すれば、統合されたスプレッドシートが数秒で完成します。フォームは標準化されています。抽出も標準化されるべきです。