契約書が人事部に届いたら、
タイピングが始まる

HRISが保存するのは入力されたデータだけ——書類の中身は見ていない

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

これは機能不足ではなく、カテゴリの違いです。HRISはデータベースであり、構造化されたレコードを保存・整理します。自然言語を解析せず、複数ページに散らばった値を探し出せず、同じ書類内の「開始日」と「発効日」の違いも、人間が正しいフィールドに入力しない限り認識できません。HRISは「保存先」であり、署名済みの雇用契約書は「情報源」です。その間には、2つの画面を開き、ファイルキャビネットがデジタル化されて以来変わらない仕事をこなす人がいます。

このギャップは入社手続きで顕在化します。新入社員の雇用契約書はPDFで届き、多くの場合、署名済みの紙原本をスキャンしたものです。そこには合意内容の確定記録——給与、役職名、試用期間、退職通知期間、労働時間、賞与対象、競業避止範囲、福利厚生加入期間——が含まれています。これらの値はすべて、初回給与支払い前にHRISに登録される必要があります。しかしHRISはどれも抽出できません。誰か（通常は人事コーディネーターかジェネラリスト）がPDFを開き、各フィールドを探し出し、システムに入力して初めて受け付けられます。

月に15人の新入社員を迎える企業——成長期の中堅企業では標準的なペース——では、単純な再入力に約7時間かかります。BLS（米国労働統計局）のHRスペシャリストの年収中央値72,910ドルを基に計算すると、この単一ワークフローの年間コストは、誰も気づかないうちに5桁に達します。

雇用契約書の10～14項目、なぜ同じ場所にないのか

HRジェネラリストに、雇用契約書からどの項目を抽出するか尋ねると、即座にリストが返ってきます。そのリストはほとんど変わりません。

問題はフィールドの数ではない。雇用契約書は、どれも同じように整理されていないからだ。あなたの会社は独自のテンプレートを使い、候補者の前職の会社は別のものを使う。多国籍企業の契約書を処理するなら、英国法人のテンプレートでは給与は別表1にあるのに、シンガポールオフィスでは3ページの「報酬」の項にある。米国の随意雇用の文言は、ある契約書では冒頭の段落にあり、別の契約書では署名欄の前の太字の免責事項にある。

この構造のばらつきこそが、テンプレートベースの抽出ツール（ページに領域を設定し、「給与は常にここ」とソフトウェアに教えるタイプ）が、標準化された請求書では成功する一方で、雇用契約書では失敗する理由である。どのベンダーの請求書も、ヘッダー、明細行、合計というほぼ同じレイアウトに従う。しかし、異なる2社の雇用契約書は、まったく共通のレイアウト規則を持たない。重要なフィールドは、作成者が置いた場所にある。

これが、HRIS自体がこの問題を解決できない理由でもある。たとえHRISがフィールド抽出機能付きの文書アップロードを提供していたとしても（ほとんどのシステムは提供していない）、内部ではテンプレートマッチングを使用する。受け取る契約書のフォーマットごとに個別のテンプレートが必要になる。各フィールドの場所をシステムに教えるのに、現在手入力している時間よりも多くの時間を費やすことになるだろう。

ステップバイステップ：署名済みPDFから人事システム対応スプレッドシートへ一発変換

テンプレートベースの抽出に代わる方法が、意味ベースの抽出です。AIが契約書を読み、位置ではなく意味を探します。ページ上の領域を定義する代わりに、出力スプレッドシートに必要な列（「従業員名」「開始日」「給与」「試用期間」など）を定義すれば、AIが各フィールドの意味と契約書での表現方法を理解し、該当する値をページや文言の違いに関わらず見つけ出します。この手法をカスタム列抽出と呼びます。必要な列を指定するだけで、AIがピクセル座標ではなく意味理解に基づいてデータを埋めます。

以下のワークフローで、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へのインポート手順は全プラットフォームで、一人あたり数時間ではなく数分で完了するという点です。

ここがこの手法のスケールする点でもあります。10件の契約を抽出した場合、10行のスプレッドシートが1つできます。チームを拡大し、今期50人を採用した場合、50行のスプレッドシートが1つできます。HRISへのインポートプロセスは、量に関係なく同じです。つまり、一人あたりの節約時間は頭打ちにならず、積み重なっていくのです。

一つ注意点を述べておきます。抽出後、HRISにインポートする前に、開始日と給与の列を元のオファーレターと照合してください。この2つのフィールドは、不一致が最も直接的な影響を及ぼします。開始日が間違っていると給与の有効化が遅れ、給与額が間違っていると、福利厚生サマリーフィールドの誤字よりもはるかに修正が難しい、法的かつ信頼上の問題を引き起こします。50行の2列を30秒で確認するのは、それでも14フィールドすべてを再入力するより50倍速いのです。

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

よくある質問

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

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

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

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

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

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

米国の州ごとに異なる随意雇用の表現はどのように処理されますか？

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

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

CLM（Ironclad、LinkSquares、Sirionなどのプラットフォーム）は、契約書の作成、交渉、承認、電子署名、保管、義務の追跡、更新アラートといった、契約ワークフロー全体を管理します。これは8～10の機能に及びます。ほとんどの人事チームが必要とするのは、実行済みの雇用契約書から構造化データを抽出するという、たった一つの機能です。このアプローチは、導入サイクルやシート単位のライセンス、機能の10％しか使わないプラットフォームのトレーニングを必要とせずに、その一点を実現します。これは、完全なライフサイクル管理を必要とする企業においてCLMを置き換えるものではありません。「データをHRISに取り込む」という契約上の課題が始まりであり終わりである人事チームにとって、適切なツールなのです。

データはすでに文書の中にある。それを取り出すのが難しいはずがない。

雇用契約書は密度の高い法的文書ですが、人事がそこから必要とするデータは限定的で予測可能です。すなわち、誰が、どの役割で、いくらで、いつから、どのような条件で、どのような制約のもとで働くか、です。このリストは何十年も変わっていません。変わったのは、文書を読み取るツールがデータを保存するツールに追いつき、かつて人事コーディネーターがPDFを一つずつ開いて埋めていた両者のギャップを、もはや手作業で埋める必要がなくなったことです。

米国の労働力における944,300人の人事プロフェッショナルは、情報をある形式から別の形式に打ち直すためにお金をもらっているのではありません。彼らは人材を採用し、育成し、定着させるためにお金をもらっています。署名済み契約書とHRIS対応スプレッドシートの間のギャップを埋めることは、元に戻すのにコストがかからず、ボリュームが増えるほど即座に効果が加速し、人事チームが本来の職務に時間を費やせるようにする、数少ない運用上の変更の一つです。

サンプルの雇用契約書を抽出ワークフローにかけてみましょう。上のプレビューでは契約書のプリセットを使用しています。実際にチームが必要とする列名を入力すれば、30分かかっていたクロスリファレンスが、スプレッドシートを待つ10秒になるかどうかを確認できます。