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

HRISは入力された情報を保存するだけ — 文書の中身は読み取らない

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

これは機能が欠けているという話ではありません。カテゴリーの違いです。HRISはデータベースであり、構造化された記録を保存・整理するものです。自然言語を解析することも、複数ページに散らばった値を探し出すことも、同じ文書内の「入社日」と「発効日」の違いを認識することもできません。人間が正しいフィールドに値を入力して初めて機能します。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倍速いのです。オファーレターがフル契約書よりもボリュームの大部分を占める場合は、署名済みオファーレターのExcel変換が、同じワークフローを最も重要な報酬と入社日フィールドに絞り込みます。

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

柔軟な勤務形態に関する書類もそのテーブルに含めるべきです。リモートワーク契約書のExcel変換は、標準的なオフィス契約書では明記されないハイブリッド勤務スケジュール、在宅勤務手当、機器に関する条件を捉えます。

よくある質問

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チームが必要とするのは、実行済みの雇用契約から構造化データを取り出すという、たった一つの機能だけです。このアプローチは、実装サイクルやシート単位のライセンス、機能の10%しか使わないプラットフォームのトレーニングを必要とせずに、その一つのことを実現します。完全なライフサイクル管理が必要な企業では、CLMの代替にはなりません。契約に関する課題が「データをHRISに入れる」ことから始まり、そこで終わるHRチームにとって、これが正しいツールです。

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

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

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

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