雇用契約書の項目をExcelに抽出、
HR向けステップバイステップガイド

HRISは入力された情報を保存するだけ — 文書に書かれた内容は読み取らない

Workday、BambooHR、ADP、SAP SuccessFactors、UKGは、合わせて数千万人分の従業員記録を管理しています。給与計算、福利厚生管理、勤怠管理、業績評価、コンプライアンス報告を担っています。しかし、どれもPDFを読み取ることはできません。

これは機能が足りないのではありません。カテゴリーの違いです。HRISはデータベースであり、構造化された記録を保存・整理するものです。自然言語を解析することも、複数ページに散らばった値を探し出すことも、「Start Date」と同一文書内の「Effective Date」の違いを認識することもできません。人間が正しいフィールドに値を入力して初めて機能します。HRISは宛先であり、署名済みの雇用契約書は情報源です。その間には、2つの画面を開いた担当者がいて、その仕事はファイリングキャビネットがデジタル化されてから変わっていません。

このギャップはオンボーディングの際に顕在化します。新入社員の雇用契約書はPDFで届きます。多くの場合、署名済みの紙原本のスキャンです。そこには合意内容の確定記録が含まれています。年俸、職位、試用期間、解雇予告期間、所定労働時間・勤務スケジュール、ボーナス受給資格、競業避止義務の範囲、福利厚生の加入期間などです。これらの値はすべて、初回の給与支払いまでにHRISに登録されている必要があります。しかし、HRISはどれも抽出できません。誰か（通常はHRコーディネーターまたはジェネラリスト）がPDFを開き、各フィールドを探し出し、システムに入力して初めて受け付けられます。

成長中の中小企業で標準的なペースとして、月に15人の新入社員を採用する企業の場合、純粋な再入力に約7時間かかります。BLSのHRスペシャリストの中央値年収72,910ドルで計算すると、この単一ワークフローの年間コストは、誰も気づかないうちに5桁に達します。

雇用契約書の10〜14項目と、なぜ同じ場所に記載されないのか

HR担当者に、署名済みの雇用契約書からどの項目を抽出するか尋ねれば、彼らはためらうことなくリストアップするでしょう。そのリストはほとんど変わりません：

複雑なのは項目のリスト自体ではありません — 雇用契約書はどれも同じように整理されていないということです。あなたの会社は独自のテンプレートを作成しました。候補者の前の雇用主は別のものを使用していました。多国籍企業の契約書を処理する場合、英国法人のテンプレートでは年俸がスケジュール1に記載される一方、シンガポールオフィスでは3ページ目の「報酬」の下に記載されます。米国の随意雇用条項は、ある契約書では冒頭の段落に、別の契約書では署名欄の前の太字の免責事項として表示されます。

この構造のばらつきこそが、テンプレートベースの抽出ツール — ページ上にゾーンを描き、「年俸は常にここにある」とソフトウェアに指示するタイプ — が、標準化された請求書では失敗しないのに、雇用契約書では失敗する理由です。どのベンダーの請求書もほぼ同じレイアウトに従います：ヘッダー、明細項目、合計。一方、2つの異なる会社の雇用契約書は、共有されたレイアウトの慣例をまったく踏襲していません。重要な項目は、作成者が置いた場所にあるのです。

これが、HRIS自体がこの問題を解決できない理由でもあります。たとえHRISがフィールド抽出付きの文書アップロードを提供していたとしても — 実際にはほとんどありませんが — 内部ではテンプレートマッチングを使用するでしょう。受け取る契約書の形式ごとに個別のテンプレートが必要になります。現在タイピングに費やしている時間よりも、システムに各項目の場所を教える時間の方が長くなるでしょう。

ステップバイステップ：署名済みPDFからHRIS対応スプレッドシートへ、一括で変換

テンプレートベースの抽出に代わる方法が、意味ベースの抽出です。AIは契約書を読み取り、位置ではなく意味を探します。ページ上の領域を定義する代わりに、出力するスプレッドシートの列を定義します。「従業員名」「入社日」「年俸」「試用期間」などです。AIは、フィールドが何を表し、契約書でどのように表現される可能性が高いかを理解することで、各値を特定します。値がどのページにあるか、起草者がどのように表現したかは関係ありません。このアプローチをカスタム列抽出と呼びます。必要な列を指定すると、AIがピクセル座標ではなく意味理解に基づいて値を埋めます。このツールが自チームに適しているかまだ判断中の場合は、HR契約管理抽出ガイドで、この機能の内容とHRチームがいつ利用するかを解説しています。

以下が、1件あたり20〜30分の手動入力作業を10秒の処理に置き換えるワークフローです。

実際のワークフローは次のとおりです。雇用契約書をアップロードし、列を指定するだけで、AIがあなたが行おうとしていた読み取り作業を代行します。

AIがフィールドを見つけられない場合の動作について補足します。役職が免除されたために上級役員の契約書に試用期間が存在しない場合、セルは空白のままになります。AIは値を捏造しません。推測もしません。フィールドを見つけて抽出するか、何も返さないかのどちらかです。この動作はHRデータにとって不可欠です。空白セルはスプレッドシート上で簡単に識別できますが、誤った入力は給与計算エラーやコンプライアンス期限の見逃しを引き起こすまで気づかれない可能性があります。

抽出結果をWorkday、BambooHR、ADPに取り込む

抽出したスプレッドシートが最終目的地ではありません。それは、署名済み契約書とHRISをつなぐ橋渡しです。主要なHRプラットフォームはすべてExcelまたはCSVからの一括インポートに対応しており、抽出時に使用した列名はHRISが期待するフィールドに直接マッピングされます。

例えばWorkdayは、Enterprise Interface Builder（EIB）インポートを通じて従業員データを受け付けます。BambooHRはテンプレートスプレッドシートを使用した一括従業員データインポートを提供しており、抽出した列をBambooHRのフィールド名に合わせてアップロードします。ADP Workforce Nowにも、新入社員データ用の同様の一括インポートワークフローがあります。重要な点は、契約データが構造化されたテーブルに入れば、HRISへのインポートステップは全プラットフォームで1人あたり数時間ではなく、数分で完了するということです。

ここがこのアプローチがスケールするポイントでもあります。10件の契約書を抽出した場合、10行のスプレッドシートが1つできます。チームを拡大して今四半期に50人を採用した場合、50行のスプレッドシートが1つできます。HRISへのインポートプロセスは、量に関係なく同一です — つまり、1人あたりの節約時間は頭打ちになりません。それは蓄積されていきます。バッチ自体が課題になるとき — 異なる形式の50通のオファーレターが同じ週に届くとき — バッチオファーレター・契約書抽出ワークフローが、その規模でしか発生しない命名、バリエーション、統合の問題をカバーします。

1つだけ注意点を述べておきます：抽出後、HRISインポートの前に、入社日と年俸の列を元のオファーレターと照合してください。この2つのフィールドは、不一致が最も即座に影響を及ぼすものです — 誤った入社日は給与支払いの開始を遅らせ、誤った年俸額は福利厚生概要フィールドのタイプミスよりもはるかに解消が難しい法的・信頼上の問題を生み出します。50行にわたる2つの列を30秒スキャンするのは、14個すべてのフィールドを打ち直すより50倍速いのです。

また、オファーレターや契約書と並行してW-2税務フォームなどの標準的な雇用書類を処理している場合、契約データのExcelへの抽出は文書タイプを問わず機能します — 定義した列名は、ソース文書が雇用契約書、業務委託契約書、新入社員とのNDAのいずれであっても一律に適用されます。1セットの列、1つのエクスポート、1つのインポートです。

FAQ

DocuSignのデータフィールドやHRISのオンボーディングモジュールではダメなのでしょうか？

DocuSignは、自分が署名用に契約書を送信する側であれば、署名プロセス中にフィールドをタグ付けできます。これは、自分が作成する送信契約書には有効です。しかし、雇用契約書は受信で届くことがよくあります。前職からの署名済みPDF（身元確認用）、候補者から返送された副署済みコピー、またはスキャンされた紙の原本などです。そうした場合、抽出できる事前タグ付きフィールドはありません。HRISのオンボーディングモジュールについても、通常は従業員が記入するデジタルフォームを提示するもので、データを将来に向けて収集しますが、すでに実行済みのPDFを読み取って、他の誰かが他の誰かのテンプレートで作成した条件を遡って抽出することはできません。

デジタルPDFではなく、スキャンした紙の契約書でも機能しますか？

はい。AIは、デジタル作成されたPDFに埋め込まれたテキストレイヤーに依存するのではなく、ページの視覚的な内容（印刷テキスト、スキャンテキスト、手書きの注釈も一部）を読み取ります。スマートフォンで撮影した紙の契約書も、Wordから生成されたデジタルPDFと同じように機能します。画像品質は読み取れる程度である必要がありますが、完璧である必要はありません。

米国以外の形式の契約書（英国の雇用契約書、欧州の労働協約など）はどうですか？

このアプローチは言語適応型で、フォーマット非依存です。「Remuneration」と呼ぶ英国の契約書と「Salary」と呼ぶ米国の契約書は、どちらも「年俸」という同じ列にマッピングされます。AIが管轄地域を問わず報酬に関する表現を理解するためです。同じロジックが「試用期間」（英国）と「Introductory Period」（米国）、ドイツ語の契約書の「Probezeit」にも適用されます。AIはキーワードの一致ではなく、意味を読み取ります。

米国の各州における随意雇用の文言にはどのように対応しますか？

公正労働基準法（FLSA）は連邦の賃金・労働時間基準を規定していますが、随意雇用（どちらの当事者も合法的な理由であればいつでも雇用関係を終了できるという原則）は州法で規定されています。モンタナ州を除く全50州が随意雇用を採用しており、モンタナ州では試用期間後の解雇には正当な理由が必要です。「随意雇用条項」を列として抽出すると、AIは契約書に明示的な随意雇用の文言が含まれているかどうかを特定します。これは、署名欄から何段落離れていても関係ありません。ほとんどの米国の雇用契約書には、解雇紛争における雇用主の法的立場を強化するためにこの文言が含まれています。モンタナ州の職務に関する契約書の場合、標準的な随意雇用の文言がないこと自体が、注目に値するデータポイントとなります。

これは契約ライフサイクル管理（CLM）システムと何が違うのですか？

CLM（Ironclad、LinkSquares、Sirionなどのプラットフォーム）は、契約ワークフロー全体を管理します。すなわち、ドラフト作成、交渉、承認、電子署名、保管、義務の追跡、更新アラートです。これは8〜10の機能に相当します。ほとんどのHRチームが必要とするのは、実行済みの雇用契約から構造化データを取り出すという、たった1つの機能だけです。このアプローチは、導入サイクルやシート単位のライセンス、機能の10%しか使わないプラットフォームのトレーニングを必要とせずに、その1つのことを実行します。完全なライフサイクル管理を必要とする企業にとって、これはCLMの代替品ではありません。契約に関する課題が「データをHRISに入れる」ことだけに始まり終わるHRチームにとって、これが適切なツールなのです。

データはすでに文書の中にあります。それを取り出すことが難しい部分であるべきではありません。

雇用契約は複雑な法的文書ですが、HRが必要とするデータは限定的で予測可能です。誰が、どの職位で、いくらで、いつから、どのような条件で、どのような制限付きで、ということです。このリストは何十年も変わっていません。変わったのは、文書を読み取るツールがデータを保存するツールに追いついたことです。そして、その2つの間のギャップは、長年にわたりHRコーディネーターがPDFを1つずつ開いて埋めてきましたが、もはや手作業で埋める必要はありません。

米国の労働力にいる944,300人のHRプロフェッショナルは、ある形式から別の形式へ情報を打ち直すためにお金を払われているわけではありません。彼らは人材を採用し、育成し、維持するためにお金を払われています。署名済み契約とHRIS対応スプレッドシートの間のギャップを埋めることは、元に戻すのにコストがかからず、量が増えるとすぐに加速し、HRチームがその役職が実際に示す仕事に時間を費やせるようにする、数少ない運用上の変更の1つです。

サンプルの雇用契約を抽出ワークフローに通してみてください。上記のプレビューは契約プリセットを使用しています。チームが実際に必要とする列名を入力して、30分かかっていた照合作業が、スプレッドシートを待つ10秒になるかどうかを確認してください。