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が付いた1件の申請書の場合、有能なプロジェクト会計担当者は約30～45分で完了します。隠れたコストは、そのタスクの周辺で発生します。毎月の請求締切により、すべての申請書が3日間のウィンドウに集中すること、保留金の誤りにより再提出サイクルが発生し、30日の支払い時計がリセットされること、フォーム間の不一致により下請け業者との調整電話が必要になること、そして新しいプロジェクトを開始するたびにAIAフォーム自体にコストがかかることです。個々には小さなコストですが、合計すると中規模ゼネコンにとってはフルタイムの給与に相当します。

毎月の請求サイクル。商業建設の支払申請書は、毎月決まったリズムに従います。下請け業者は締切日（通常は毎月20日か25日）までに支払申請書を提出します。ゼネコンはそれをレビュー、確認し、月末までにオーナーへの請求書にまとめます。承認されれば、オーナーからの支払いは30～45日後に到着します。締切に間に合わなければ、下請け業者の支払いは丸々1請求サイクル遅れ、30日待ちが60日待ちになります。プロジェクト会計担当者が4日間で40件の支払申請書を手作業で処理している場合、1～2件の締切を逃すリスクは理論上の話ではありません。建設財務管理協会の2025年財務ベンチマーカー（2024会計年度の1,558社のデータに基づく）によると、典型的な建設会社の税引前純利益率は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行目になります。1つの項目の転記ミスがすべての派生行に連鎖し、G702の計算が内部的に矛盾します。申請書を確認する建築士は数秒で矛盾を発見し、書類一式を却下します。

AIAフォームのコスト。 通常の注文書や納品書とは異なり、AIAフォームは著作権で保護された文書です。AIA契約書類を通じて1回限り使用するG702/G703の組み合わせは、約49.99ドルかかります。AIAソフトウェアサブスクリプション（年間約500ドルからで無制限アクセス）で一括購入すると、1セットあたり約15～25ドルになります。5つのプロジェクトで50の下請け業者を管理するゼネコンにとって、年間のフォームコストは750～2,500ドルです——大きな金額ではありませんが、ゼネコンが処理する必要のある請求データの形式を標準化する以外に価値を生まない、継続的な運営経費です。

G702/G702の親子構造：要約ページと継続シートの関係

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

G702は親であり、契約全体をカバーする9行の財務要約です。その行は次のとおりです。

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

G703は子であり、各行が価値表の明細項目であり、各列が請求期間全体にわたるその明細項目の財務的進捗を追跡する、可変長のテーブルです。標準的なG703継続シートは、データを次の列に整理します。

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

出来高請求書データ抽出の隠れた課題

たとえフォームが正しく記入されていても、G702/G703パッケージからのデータ抽出には、他の建設書類にはない課題が存在します。これらの課題は、出来高請求書を大規模に処理したことのない人にはすぐにはわかりません。

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

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

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

クロスフォーム検証の複雑さ。 G702とG703の間の算術的制約は、単純な列合計の一致を超えています。今回の出来高請求書におけるG703の列D（前回申請からの完了工事）は、前回の出来高請求書のG703の列G（現在までの完了・保管済み合計）から、前期の列F（保管材料）を差し引いた値と一致しなければなりません。下請け業者がプロジェクト途中で価格表を変更し、内訳項目を分割したり、工種間で価値を再配分したりすると、この繰越値は破綻し、ゼネコンは手動で差異を調整する必要があります。各出来高請求書を独立した書類として扱う抽出ツールでは、この不一致を検出できません。連続する出来高請求書を読み取り、その繰越値を比較するツールであれば、検出が可能です。

従来型 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が届き、表構造が不規則な場合には、完全に機能しなくなります。失敗するたびに、新しいテンプレートを作成するか、既存のテンプレートを調整する必要があります。そして、その調整によって、以前は機能していたフォームの対応が壊れてしまいます。

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

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

計算列：算術ループの完結

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

支払申請書の抽出に特に有用な3つの計算列を以下に示します。

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

これらの計算列は、抽出後にユーザーが数式を入力する必要はありません。抽出設定時に指定されます（例：「保留金チェック（完了合計×10%）」のような列名として、または多段階ロジック用のツールのルール形式におけるJSONルールとして）。AIは抽出処理中に計算を実行します。その結果、審査担当者がファイルを開く前に、支払申請書の正確性を検証する列が入力された出力スプレッドシートが生成されます。

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

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

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

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

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

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

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

Googleスプレッドシート連携。チームが支払スケジュールをGoogleスプレッドシートで管理している場合、抽出出力はGoogleスプレッドシートのアドオンを介してアクティブなスプレッドシートに直接取り込むことができます。これにより、エクスポートとインポートの手順が完全に不要になります。アップロードされた支払申請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抽出がゼネコンに最大の効果をもたらすシナリオです。あらゆる下請け業者、あらゆるプロジェクトからの支払申請PDF（デジタルまたは手書き）を1つのバッチにアップロードしてください。AIが各フォームを個別に読み取り、G702およびG703データを抽出し、ソースファイルを識別する列を含む1つの統合スプレッドシートを出力します。バッチワークフローは、デジタルAIAフォーム、スキャンした紙のフォーム、ExcelエクスポートをPDFにしたものなど、混在するフォーマットを自動的に処理します。このワークフローの詳細なチュートリアルについては、プロジェクトポートフォリオ全体でのAIA G702支払申請のバッチ処理をご覧ください。

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

はい。AIA契約書類は、公式のG702およびG703フォームの著作権を保有しています。AIAウェブサイトでのG702/G703セットの単回使用料は約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件の申請書を一括処理すれば、統合されたスプレッドシートが数秒で完成します。フォームは標準化されています。抽出も標準化されるべきです。