WH-347が15枚、スプレッドシートは1つ：
週次認定給与の処理方法

1件の報告書なら管理可能。15件となれば、まったく別の問題です。

下請け業者1社のWH-347を手作業で転記するには、従業員名、社会保障番号下4桁、職種分類、7日分の時間外・通常時間別労働時間、基本時給、付加給与率、総賃金、控除額、手取り額など、約15～20分かかります。認定給与報告書1件をExcelに抽出する方法をすでにお読みなら、個別の作業は単純です。必要なフィールドを定義し、PDFをアップロードすれば、AIがグリッド上の位置ではなく意味に基づいて各値を特定します。処理時間は15分から約10秒に短縮されます。1件の報告書であれば、この仕組みは問題なく機能します。

これを3つのプロジェクトにわたる15件の報告書に拡大すると、問題は一変します。ボトルネックは「ツールが1件の報告書を読み取れるか」から「ツールが、6種類の異なるソフトウェア出力形式、3種類の州別様式、複数のプロジェクトで異なる賃金率で働く重複従業員を含む15件の報告書を、金曜日までに3つの異なる契約機関に提出できるか」へと移ります。単一報告書のチュートリアルではこの問いに答えられません。なぜなら、形式の不統一、賃金決定の帰属、期限の逼迫といった課題は、バッチ規模で初めて顕在化するからです。

効率のギャップは直線的ではない。1回目の報告書は15分で完了する。Foundation Softwareのエクスポートのレイアウトを覚えるからだ。5回目は15分かかる。手書き修正のあるスキャン済み紙の報告書だからだ。10回目は15分かかる。ADP Workforce Now形式で、WH-347の慣例とは異なるフィールドラベルが使われているからだ。15回目までには疲労が蓄積し、3つの異なる賃金決定書と照らし合わせてすべてのフィールドを再確認することになる。15件の報告書、15通りのレイアウト、反復による効率化はなく、蓄積されるのはエラーリスクだけだ。しかも、違反1件につき最大13,508ドルの罰金（DOL賃金・時間課）と、最長3年間の連邦契約からの排除措置が科される可能性のある法的証明書の下での話である。

バッチ規模で初めて発生する3つの問題

単一報告書の抽出は単純なロジックに従う。列を定義し、ファイルをアップロードし、スプレッドシートを受け取る。バッチ処理では、抽出精度とは無関係で、複数の公共事業プロジェクトを管理する組織の現実に起因する、3つの複合的な課題が発生する。

課題1：6種類のソフトウェア形式、3種類の州様式、そして月曜朝の受信箱

単一プロジェクトの場合、すべての下請け業者は同一の賃金決定と通常同じフォーム形式で提出します。複数プロジェクトのポートフォリオでは、フォーマットの組み合わせが急速に拡大します。プロジェクトAは連邦資金による高速道路工事で、標準のWH-347が必要です。プロジェクトBはイリノイ州の市営下水道契約で、連邦の付加給与とは異なるマッピングの賃金補足列を持つフォームIL-452CM02が必要です。プロジェクトCはカリフォルニア州の学校建設でCA A-131に基づき、カリフォルニア州産業関係局がDIR固有の列規則による電子提出を義務付けています。

さらに下請け業者のソフトウェアの違いが重なります。Foundation Softwareの給与報告モジュールはWH-347をある方法で構成します。Sage 300 CREの「認定給与」モジュールは別の方法で構成します。ADP Workforce Nowは3番目のレイアウトを生成します。Viewpoint Vistaは4番目を生成します。ある下請け業者は今でもコピーしたテンプレートに手書きでWH-347を記入しています。3つのプロジェクトのポートフォリオでは、元請け業者は月曜朝のバッチで6種類もの異なる報告書形式を受け取る可能性があります。そして各形式で「付加給与率」フィールドの位置が異なり、ラベルも微妙に異なります。

テンプレートベースの抽出方法、つまり「フリンジレートはFoundation社のWH-347エクスポートのセルG22にある」という方法に依存する場合、下請け業者が給与ソフトをアップグレードするたびに6つのテンプレートを維持、テスト、更新する必要があります。この維持管理の負担により、抽出で節約できるはずの時間がしばしば消費されてしまいます。この問題を解決する仕組みがセマンティック列名抽出です。抽出ソフトに値がページ上のどこにあるかを指示する代わりに、出力に必要な列（「従業員名」「区分」「月間労働時間」「賃金率」「フリンジレート」「総支給額」「控除額」「純支給額」）を定義すると、AIが各書類を読み取り、 prevailing wage コンプライアンスの文脈で値が意味するものに基づいてすべての値を見つけ出します。イリノイ州IL-452CM02の「Supplemental Rate」という列と、連邦WH-347の「Fringe Rate」という列は、どちらも同じ概念を指しているとAIが理解するため、出力列の「フリンジレート」にマッピングされます。1つの列テンプレートで、Foundation、Sage、ADP、Viewpoint、スキャンされた紙、および3種類の州様式に対応できます。

課題2：3つのプロジェクト、3つの賃金決定、重複する作業員

プロジェクトAで「大工」として働く作業員は、賃金決定番号WD OR20240001に基づき、基本給38.15ドルに加えフリンジ12.40ドルを受け取る。同じ作業員がプロジェクトBで働く場合、WD IL20240003に基づき、基本給42.80ドルに加えフリンジ15.10ドルを受け取る。この作業員が週を2つのプロジェクトに分割し、月曜から水曜までを一方、木曜と金曜をもう一方で働く場合、2つの異なる賃金率で2つの別々の公認給与報告書に記載しなければならない。DOLの2023年デービス・ベーコン最終規則（88 FR 57730）は、元請負業者が下請負業者の賃金違反に対して厳格責任を負うことを再確認した。すなわち、元請負業者の給与管理担当者は、ポートフォリオ内のすべてのプロジェクトにわたって、下請負業者が報告したすべての時間、職種、賃金率の正確性を証明しているのである。

バッチ規模では、これは検証マトリックスとなる。各下請負業者の報告書から抽出されたすべての作業員の行は、その作業員の職種をその特定のプロジェクトで規定する賃金決定と照合しなければならない。単一の誤った賃金率の適用（オレゴン州の大工賃金率をイリノイ州のプロジェクトに適用すること）は、元請負業者が責任を負う賃金違反を生み出す。PilieroMazza法律事務所は、ワシントンD.C.の2つのプロジェクトにおいて、下請負業者が熟練板金工を意図的に低技能労働者として誤分類した結果、596,443ドルの未払賃金と3年間の連邦契約からの排除処分が下された最近のDOL執行事例を文書化している（PilieroMazza、2024年6月）。

バッチ抽出では、出力にプロジェクト列を含めることでこの問題に対処します。抽出フィールドの1つとして「プロジェクト」を定義すると、AIが抽出されたすべての行にそれを適用します。OR-Highway-Foundation_CPR-8.pdfのような命名規則に従ったファイルの場合、プロジェクト識別子は統合出力のすべての行に残ります。プロジェクトでフィルタリングし、正しい賃金決定に対して賃金率を検証し、各契約機関向けにプロジェクト固有のスプレッドシートをエクスポートできます。15個の個別PDFを切り替える必要はありません。

課題3：毎週の締切に余裕は一切ない

認定給与計算は毎週のサイクルで行われます。DOL規則29 CFR § 5.5(a)(3)(ii)に基づき、請負業者は各給与期間終了後7日以内に認定給与計算書を提出しなければなりません。提出が遅れると、契約機関はコンプライアンスが回復するまで契約支払いを差し控えることができます。作業が行われなかった週でも、無作業報告書を提出する必要があります。報告の時計は決して止まりません。

下請け業者が月曜の朝に報告書を提出することはほとんどありません。実際には、報告書は少しずつ届きます。月曜に4件、火曜に5件、水曜に3件、残りの3件は木曜日、つまり提出期限の前日に届きます。15件すべての報告書をまとめて処理しようと待っていた給与計算担当者は、残り半日で3件の下請け業者報告書を処理し、抽出されたすべてのデータを3つの賃金決定と照合し、各プロジェクトの元請け業者自身のWH-347を完成させ、契約機関に提出しなければなりません。これは仮定の話ではなく、複数の公共事業賃金プロジェクトを管理するすべての元請け業者が毎週経験している現実です。

バッチ抽出ワークフローにより、各レポートの処理時間が15分から数秒に短縮されます。月曜朝の一括処理で統合スプレッドシートが作成され、午後にはレビュー可能に。週半ばに届いたレポートは個別に数秒で処理され、既存の出力に追加されます。金曜の提出期限は、データ入力の慌ただしさではなく、確認作業へと変わります。

バッチ処理ワークフロー：15件のPDFを1つのスプレッドシートに

以下の手順は、元請け業者が3つの異なる公共事業プロジェクトで5つの下請け業者から公認賃金報告書を受け取り（週に約15件）、コンプライアンス審査と提出のために統合・プロジェクト別に整理されたスプレッドシートにまとめる必要がある場合を想定しています。列定義は一度設定すれば、再利用可能なプリセットとして保存されます。

複数プロジェクト＝複数州対応：賃金決定マトリクスの拡大

バッチ処理による認定給与計算の複雑さの上限は、下請け業者の数ではなく、適用される賃金決定の数によって決まります。各プロジェクトには独自の賃金決定が伴い、作業が複数の郡や分類グループにまたがる場合は、プロジェクトごとに複数の賃金決定が発生することもあります。3つの州で3つのプロジェクトを抱える元請け業者は、最低でも3つの連邦賃金決定を管理することになり、それぞれに基本賃金表、福利厚生構造、見習い比率要件、さらに州固有のフォーム項目が重なります。

カリフォルニア州労働局は、DIR固有のフォーマットでオンラインシステムを通じた電子提出を義務付けています。ニューヨーク州は、すべての州および地方公共事業について、NY認定給与ポータルを通じた電子提出を義務付けています（NY DOL認定給与）。イリノイ州は、郡レベルの公共団体を通じて提出する認定給与明細書フォームを使用します。ワシントン州はL&I固有の報告を要求します。オレゴン州は、連邦WH-347にはない見習い追跡フィールドを含むWH-38を要求します。各州のポータルは独自のアップロードテンプレートを期待しており、カリフォルニア州DIRのフィールドはイリノイ州IDOLのフィールドと一対一で対応せず、それらはニューヨーク州DOLのフィールドとも一対一で対応しません。

このため、統合された出力スプレッドシートのすべての行にプロジェクト属性を付与する必要があります。給与管理担当者はプロジェクトAにフィルタリングし、抽出したデータをカリフォルニア州DIRのアップロードテンプレート用に再フォーマットして提出します。次にプロジェクトBにフィルタリングし、イリノイ州用に再フォーマットします。さらにプロジェクトCにフィルタリングし、ニューヨーク州用に再フォーマットします。抽出処理は、3つのプロジェクトすべてに対して一度だけ文書からスプレッドシートへの変換を行います。提出フォーマットはプロジェクトごとですが、受信箱に散らばった15個の個別PDFではなく、単一の検証済みデータソースから始まります。

両方の認証・非認証給与を同時に処理する請負業者（公共工事と民間プロジェクトの両方を扱う企業に多いパターン）では、同じ抽出ワークフローで両方に対応できます。給与台帳からExcelへの変換ツールは、同じ列定義アプローチを使用して標準的な給与処理を実行するため、ソース文書がWH-347でも通常の給与明細でも、週次報告を統一的に整理できます。

プロジェクト横断的な作業者追跡：同一技能労働者が2つの賃金決定に該当する場合

同じ週に複数のプロジェクトを移動する作業者は、手動処理の仕組みでは構造的に見落とされがちなコンプライアンス上のエッジケースを生み出します。ジェームズ・カーターが月曜から水曜までオレゴンの高速道路プロジェクト（WD OR20240001、大工、時給38.15ドル）で働き、木曜から金曜までイリノイの下水道プロジェクト（WD IL20240003、時給42.80ドル）で働いた場合、同一暦週に同一作業者に異なる賃金率を適用した2つの別々の認証済み給与報告書（プロジェクトごとに1つ）を提出する必要があります。DOLのWH-347指示では、列9（「全作業に対する作業者への正味支払額」）に全プロジェクト（非デービス・ベーコン作業を含む）の合計を反映させる一方、個別プロジェクトの総収入はその特定のプロジェクトで行われた作業のみを反映するよう求めています。

手動処理では、同一人物が複数のプロジェクトにまたがって作業している場合、そのデータが異なる下請け業者からの報告書に分散し、異なるフォルダに保管され、異なる担当者が確認し、異なるポータルに提出されるため、見落としが発生しやすくなります。バッチ抽出で作成された統合スプレッドシートは、プロジェクトごとに孤立した処理では得られない可視性を提供します。「従業員名」列でフィルタリングすれば、James Carter が3つのプロジェクトすべてに登場するすべてのデータが一覧表示され、「プロジェクト」列で各行がどのプロジェクトに属するかが、「賃金率」列でプロジェクトごとに正しい賃金率が適用されているかが一目でわかります。

混合形式の公認給与計算用に設定されたバッチ文書からExcelへのワークフローでは、プロジェクトごとに抽出処理を繰り返す必要はありません。同じ列テンプレートで全プロジェクトの報告書を同時に処理し、出力の「プロジェクト」列を使用して後工程でプロジェクトごとにフィルタリングできます。

バッチ処理で実際に節約できるもの：週間の計算

給与管理者が15件の認定給与報告書をPDFからExcelに転記する場合、1件あたり約20分（クロスチェックと賃金決定の確認を含む）かかり、データ入力だけで週に約5時間を要します。作業のない週の無業務報告書の提出を加えると、週の管理負荷は約5～7時間になります。26週間のプロジェクトサイクルでは、累計で約150時間（ほぼ1か月分のフルタイム労働）を、PDFからスプレッドシートへの数字の転記に費やすことになります。

給与管理者の時給が25ドルの場合、3つのプロジェクトにわたる手動の認定給与処理の週間人件費は125～175ドルです。50週間の稼働で、データ入力作業だけで年間6,250～8,750ドルになります。より大きな項目は罰則リスクです。3回連続の週次提出で1件の未検出の誤った賃金率が発生すると、違反が発生し、その金銭的コスト（未払賃金と罰則）は年間のデータ入力作業費を上回ります。

同じ15件の報告書をバッチAI抽出で処理する場合、処理時間は3分未満、レビューとプロジェクト固有のエクスポート書式設定に約30分かかります。週間の時間的負担は5～7時間から1時間未満に減少し、エラー発生範囲は2,520件の手動入力フィールドから、最大99%の精度で印刷テキストを抽出するAIデータの検証に縮小されます。手書きの修正やかすれたスキャンだけが人間の確認対象としてフラグ付けされます。

よくある質問

一度にバッチ処理する必要がある場合、報告書を遅れて提出する下請け業者にはどう対応すればよいですか？

バッチ抽出では、15件の報告書がすべて同時に届く必要はありません。最初の波（例：15件中10件）を処理し、統合スプレッドシートをダウンロードします。残りの5件が水曜日または木曜日に届いたら、個別にアップロードします。列テンプレートとプリセットは既に設定されているため、既存の出力に追加されます。遅れて届いた報告書も数分ではなく数秒で処理されます。バッチワークフローは増分的であり、全か無かではありません。

下請け業者が、列見出しのない完全に非標準的な報告書形式を使用した場合はどうなりますか？

認識可能な列ラベルがない報告書は、AIの意味的な手がかりが少なくなるため、抽出精度が低下します。下請け業者が一貫して非標準形式を提出する場合の対応方法は次のとおりです。(1) 下請け業者に、DOLが無料で提供する標準のWH-347テンプレートの使用を依頼する。このテンプレートは、非標準形式と同じ時間で記入できます。(2) その下請け業者のレイアウトに合わせた個別の列プリセットを作成する。完全に非構造化された報告書（ラベルのない数字だけの表）の場合は、手動での確認が必要です。AIは解釈できるものを抽出しますが、ラベルのない数字の列を、人間の判断なしに特定の給与フィールドに確実にマッピングすることはできません。

バッチ出力をLCPtracker、eMars、または州のコンプライアンスポータルに直接入力できますか？

出力は標準のXLSXファイルです。LCPtracker、eMars、Elation Systems、各州のポータル（カリフォルニア州DIR、ニューヨーク州公認給与ポータル、ニュージャージー州Wage Hub）は、それぞれ独自のインポート形式（通常はCSV、XML、または必須の列ヘッダーを持つExcelテンプレート）でデータを受け付けます。抽出されたスプレッドシートは構造化されたソースデータを提供します。プロジェクトでフィルタリングし、列をポータルのアップロードテンプレートにマッピングして送信します。抽出処理が文書からデータへの変換を行います。ポータル固有のフォーマットは別のステップですが、フォーマットされるデータは、15のPDFに分散するのではなく、単一のソースから検証・構造化・プロジェクト属性付けが済んでいます。

下請け業者のWH-347に、印刷された数字の上に手書きで修正がある場合は？

AIは筆記体、修正、チェックマークを含む手書きの値を読み取ります。下請け業者が総労働時間として印刷された「38.5」を消して横に「40.0」と書いた場合、AIは手書きの「40.0」を有効な値として読み取ります。抽出は文書が視覚的に提示する内容に基づくため、人間のレビュー担当者が修正後の値として読むものは、AIも同様に読み取ります。読みにくい文字や薄い鉛筆書きは精度を低下させるため、手動検証の対象としてフラグを立てる必要があります。出力にはソースファイル名が保持されるため、不確かな行は元のPDFと迅速に照合できます。

計算列を使用して、下請け業者が報告した総額が賃率×時間と一致するか検証できますか？

はい。直接抽出に加えて、計算列が処理中に抽出データの計算を実行します。総額検証（標準時間 × 時給 + 残業時間 × 時給 × 1.5）のような列を定義すると、AIが期待総額を計算し、報告された総額と並べて出力し、差異がしきい値を超える行にフラグを立てます。この検証ステップはバッチの一部としてすべての報告書で自動的に同時に実行されるため、すべての下請け業者の計算が、スプレッドシートがレビュー段階に達する前にチェックされます。差異がある行は、誰かに見つかって違反になる前に、提出前にフラグが立てられます。

バッチ抽出と、認定給与モジュールを備えた統合給与ソフトウェアの比較は？

統合給与プラットフォーム（Foundation、ADP Workforce Now、Viewpoint Vista、Payroll4Construction、Miter）は、自社の給与計算上の労働者の認定給与を処理します。内部のタイムトラッキングと賃金テーブルからデータを取得し、WH-347フォームを自動生成します。元請け業者の自社従業員については、自社の給与プラットフォームを使用してください。これらのプラットフォームが解決しない問題は、下請け業者側です。下請け業者は異なる給与ソフトウェアを使用しているか、まったく使用しておらず、互換性のない形式で報告書を作成し、PDFとして受信箱に届きます。統合プラットフォームは自社の給与データから認定給与を生成します。抽出ツールは、プラットフォームが取り込めない下請け業者のPDFを処理します。これらは補完的です。給与システムは自社のチームを処理し、バッチ抽出は他のすべての業者の報告書を処理します。

AIはコンプライアンス声明と認証署名を処理しますか？

いいえ。コンプライアンス表明書（WH-347の2ページ目）は、会社の権限ある代表者が偽証の罰則のもとで署名する法的な証明書です。AIは給与データ（数字、職種、時間数、賃率）のみを抽出します。証明書への署名は、会社の役員が行う別個の法的行為として残ります。バッチ抽出はデータ転送を自動化します。証明を自動化することはできず、法的にもできません。

複数の公共事業プロジェクトで公認給与を処理する請負業者にとっての根本的な問いは、毎週のデータ入力作業（2,520項目の手入力、3つの賃金決定との照合、偽証の罰則下での証明）がコンプライアンスプロセスに価値を付加するかどうかです。答えは、リスクを付加するのであって価値ではありません。コンプライアンスの価値は検証とレビューにあります。PDFとスプレッドシートの間のキーボード操作は、純粋な責任です。コンプライアンス要件の基礎となる枠組みについては、建設業における公認給与の初心者向けガイドをご覧ください。バッチワークフローの基盤となる単一レポート抽出プロセスについては、公認給与データをExcelに抽出する方法をご覧ください。また、連邦コンプライアンス対象外の標準的な給与計算については、給与明細からExcelへの変換ツールが、同じ列定義アプローチで任意の形式の給与明細を処理します。