AIのための人事データ基盤：HRISのデータ品質と連携

著者: Kevin Kim · 更新日: 2026年10月11日

人事データ基盤とは、AIシステムが学習したり回答時に参照したりする従業員データの正確性、一貫性、接続性、そして法的根拠のことで、主にHRIS、採用管理システム（ATS）、給与の記録を指します。 モデルは、ある従業員が2つの部署に所属していると記録されたレコードや、9通りの表記が存在する役職名を修正できません。間違いを、表計算ソフトよりも速く、しかも自信満々に繰り返すだけです。

本記事は、人事向けAIツールの購入、パイロット導入、承認を控えているCHRO、人事部長、人事マネージャーに向けて、事前にデータで何が整っている必要があるかを解説します。人事におけるAIで扱うユースケースの土台にあたり、ACE Frameworkのデータ層（レベル0）で、予測や生成の前に行う取り込み（Ingest）と分析（Analyze）を扱います。

重要なポイント

• GDPRは、個人データが「正確であり、必要な場合には最新の状態に保たれる」ことを求めており、不正確なデータは遅滞なく消去または訂正するためにあらゆる合理的な措置を講じなければならないとしています（Regulation (EU) 2016/679、第5条(1)(d)）。
• 同じ規則の下で、処理の基本原則に違反した場合、2,000万ユーロまたは全世界年間売上高の4%のいずれか高い方までの制裁金が科される可能性があります（GDPR、第83条(5)）。
• EU AI Actは、人の採用や選考、昇進や解雇の判断、個人の行動に基づく業務の割り当て、パフォーマンスの監視や評価に使われるAIを、附属書IIIで高リスクに分類しています（Regulation (EU) 2024/1689、附属書III、第4項）。
• 高リスクシステムについて、同法は学習、検証、テストに使うデータが想定される目的に照らして「関連性があり、十分に代表的で、可能な限り誤りがなく完全」であることを求めています（AI Act、第10条）。
• GDPRは、法的効果または同様に重大な影響を及ぼす判断について、もっぱら自動化された処理だけに基づく判断の対象とされない権利も認めています（GDPR、第22条）。

人事AIはデータ次第で成否が決まる

人事AIのユースケースはどれも、同じ3か所から読み取ります。スクリーニングツールはATSを読みます。離職予測モデルはHRISを読み、給与から報酬履歴を取り込みます。従業員向けアシスタントは就業規則などの文書に加えてHRISの一部の項目を読み、ドイツのマネージャーとブラジルのマネージャーに異なる回答ができるようにします。

つまり問うべきは「AIは優れているか」ではなく、「AIは何を見ているか」です。答えが「乱雑なデータ」であれば、次の3つが起こります。

• 予測が、データに偏って多く含まれるものへ寄っていきます。 10年分の昇進記録が1つの拠点と1つの職種グループのものであれば、「昇進の準備ができている」ことを予測するモデルは、その拠点の慣習を学習します。これがAIにおけるバイアスの仕組みであり、原因はアルゴリズムではなくデータにあります。
• アシスタントが古い情報源から自信満々に回答します。 育児休業規程が3つのバージョンで読み込まれていると、アシスタントはそのうち1つを選びます。どれを選んだのか、誰にも分かりません。
• 分析結果が互いに食い違います。 経理の従業員数と人事の従業員数が違うと、AIが作成する最初の人材レポートは意思決定ではなく数字をめぐる議論になります。

これを後始末ではなく基盤づくりとして扱う利点は、同じ作業がAIの有無にかかわらず成果を生むことです。レポートの整備、監査の迅速化、給与の修正件数の減少は、いずれも同じ改善から生まれます。

人事AIを機能不全にする5つのデータ問題

すべてが全社に見つかるわけではありませんが、たいていの企業で少なくとも3つは見つかります。パイロット中にチームが驚く頻度のおおよその順に並べています。

重複とアイデンティティ

アイデンティティは、あらゆる結合がこれに依存するため、最初に直すべきものです。応募者が従業員になったのにATSのレコードがHRISのレコードに紐づいていなければ、ソーシングチャネルが定着を予測するかどうかを問うことはできません。典型的な原因は、再雇用と、契約社員から従業員への切り替えです。2つのHRISが統合され、同じ人物が両方に現れる買収も同様です。

ジョブアーキテクチャ

役職名は人が書くもので、人は創造的です。ジョブアーキテクチャ（等級、職種グループ、標準的な職務のカタログ）は、役職名をモデルが使えるデータに変えます。これがなければ、「プロダクトマネージャーに異動できる人を全員表示して」という依頼は、キーワードの重なりに基づく推測にすぎません。スキルベースのAI機能、社内人材マーケットプレイス、賃金の公平性分析は、いずれもこの構造が存在することを前提としています。

発効日

現在の状態しか保存しないHRISは、今誰がどこにいるかは分かっても、どう経てきたかは分かりません。発効日管理とは、各変更に適用開始日を持たせ、過去のどの時点も再現できるようにすることです。これは公平性の分析にも重要です。昇進率がグループ間で異なるかを検証するには、入力日ではなく、実際の昇進の実際の日付が必要です。

サイロ化したシステムと自由記述

多くの人事システムは、最適なツールを個別に追加して成長してきたため、データがあちこちに存在します。解決策は必ずしも1つのプラットフォームではありません。どのシステムがどの項目を管理するかを合意し、2つのシステムが同じ値を編集しないようにすることです。自由記述にも同じ規律が当てはまります。退職面談のコメントや採用担当者のメモはテキスト分析モデルの入力にできますが、健康状態、家庭の事情、特定の同僚についての意見も含みます。証明されるまでは、社内で最もリスクの高い項目として扱ってください。

人事で有効なデータ連携の方法

データのある場所からAIが使える場所へ移すには、現実的に4つの方法があります。システムの数と、データをどれだけ速く動かす必要があるかで選びます。

どの方法を選ぶ場合も、2つのルールが当てはまります。

すべての項目に記録システムを定めてください。 法律上の氏名と国民IDはHRISに置きます。採用要件のステータスはATSに置きます。報酬は給与に置き、HRISがそれを読み取ります。2つのシステムが同じ値を変更できると衝突が起き、衝突はひとりでに解消されることはありません。

移すデータは最小限にしてください。 休暇の質問に答えるアシスタントに、給与履歴は不要です。ユースケースに必要な項目だけを取り込めば、AIは単純になり、情報漏えいのリスクが下がり、プライバシー評価も短くなります。GDPRはこれを原則としており、個人データは目的に照らして「適切で、関連性があり、必要なものに限られる」ことを求めています（GDPR、第5条(1)(c)）。

文書や記録を読むRAG型のアシスタントを計画している場合、連携の問題はコンテンツの問題にもなります。どの文書が最新で、誰が古い文書を廃止するのかです。その仕組みは検索拡張生成で解説しています。

従業員データのプライバシーの基本

従業員データは企業が保有するデータの中でも特に機微なものであり、AIはそれを悪用する新たな経路を生みます。以下はマネージャー向けの概要であり、法的助言ではありません。従業員を雇用している国ごとに何が適用されるかは、顧問弁護士に確認してください。

原則を押さえてください。 GDPRの中核となる原則は、適用対象となるすべての人事データセットに当てはまります。適法性、目的の限定、データの最小化、正確性、保存の制限、安全性です。AIにとって特に厳しいのは、正確性（誤ったデータを速やかに訂正する第5条(1)(d)の義務）と、データは必要以上に長く識別可能な形で保管してはならないとする保存の制限です（第5条(1)(e)）。削除すべきだった記録で学習したモデルは、自ら作り出した問題です。

特別カテゴリのデータは慎重に扱ってください。 GDPRは、人種または民族的出身、政治的意見、宗教的信条、労働組合への加入を明らかにするデータ、さらに遺伝データ、個人を識別するための生体データ、健康や性生活に関するデータの処理を制限しています（第9条(1)）。人事システムは、病気休暇や多様性レポートなど、正当な理由でこうしたデータの一部を収集します。意図的に含めると決め、その理由を文書化した場合を除き、AIへの入力からは外してください。

各国の雇用規則がGDPRに上乗せされる場合があることを忘れないでください。 第88条は、採用、雇用契約の履行、業務の計画と組織を含む雇用の文脈における従業員データの処理について、加盟国が法律または労働協約によってより具体的な規則を定めることを認めています（第88条）。実際には、ある国では問題のない展開でも、別の国では労使協議会の関与や追加の通知が必要になることがあります。

パイロットの前に影響評価を行ってください。 特に新しい技術を用いた処理が、人の権利と自由に高いリスクをもたらす可能性が高い場合、GDPRは処理の開始前に評価を行うことを求めています（第35条）。新しいツールで従業員をスコアリングしたりランク付けしたりすることは、その典型例です。

重大な判断には人を関与させてください。 第22条は、法的効果または同様に重大な影響を及ぼす判断について、もっぱら自動化された処理に基づく判断の対象とされない権利を認めています（第22条）。実務上の答えは、結果を変えられる本物のレビュー担当者を置くことで、これがヒューマン・イン・ザ・ループの考え方です。

EUで事業を行う場合は、AI Actのデータに関する義務に留意してください。 雇用に関するAIは附属書IIIで高リスクに分類され、第10条はそうしたシステムの学習、検証、テストに使うデータのガバナンスに関する期待を定めています。データの出所と収集目的、クレンジングとラベル付けの方法を文書化し、人の権利に害を及ぼしかねないバイアスがないかを検討することなどが含まれます（AI Act、第10条）。義務の内容は、システムを自社で構築するのか、ベンダーのものを導入するのかで変わりますので、ベンダーにどんな文書を提供してもらえるか確認してください。

EU域外でも、枠組みは似ています。 英国では、情報コミッショナー事務局が、雇用記録の保管と従業員の監視に関する雇用主向けガイダンスを公開しています（ICO employment information）。米国の規則は州ごと、ユースケースごとにまちまちなので、従業員や候補者のいる場所を確認してください。

これらの統制が組織全体でどう組み合わさるかについては、AIガバナンスをご覧ください。NISTの任意のAI Risk Management Frameworkは、2023年1月にバージョン1.0として公開され、Govern、Map、Measure、Manageの4つの機能で構成されており、リスクの議論を進める構造として役立ちます。

人事AIのデータ準備状況チェックリスト

パイロットを承認する前にお使いください。各行について、準備完了、一部、未整備のいずれかを付けます。最初の6行で「未整備」が2つ以上ある場合は、パイロットより先にデータを直してください。

スコアリング、ランク付け、従業員のモニタリングを行うものでは、アイデンティティ、発効日管理、代表性の行が特に重要です。就業規則に関する質問応答アシスタントのような小規模でリスクの低いパイロットは、他の行が一部しか満たされていなくても始められます。

うまくいく進め方

始める前に2年がかりのデータプログラムは必要ありません。勢いを保てる進め方は次のとおりです。

1. まず1つのユースケースを選びます。 AIユースケースの優先順位付けの基準で選び、そのユースケースに必要な項目だけを洗い出します。休暇規程のアシスタントに必要なのは、文書といくつかのプロフィール項目です。離職リスクモデルには、数年分のきれいな履歴が必要です。
2. そのユースケースのデータをプロファイリングします。 対象の項目だけで、重複、空欄、役職名のばらつきを数えます。1ページにまとめた数字は、データに関する漠然とした不満よりも経営層を動かします。
3. 下流ではなく、発生源で直します。 HRISが不良レコードを生み続けるのに、ウェアハウス上のコピーだけをクレンジングしても、来四半期にまた同じ作業になります。フォームに入力チェックを加え、項目を必須にし、選択リストで足りるところでは自由記述をやめてください。
4. 不備を生むプロセスを直します。 重複レコードは、内定承諾からオンボーディングへの移行など、引き継ぎで生じることが大半です。役職名の混乱は、マネージャーが職務を自由に作れることから生じます。そうした地点に関門を設けてください。
5. スチュワードシップを割り当てます。 人事オペレーションの担当者が主要なデータセットごとに1人ずつ責任を持ち、毎月の品質レポートを人事のリーダーシップチームに提出します。
6. パイロット、測定、拡大の順に進めます。 きれいな範囲でパイロットを実施します。最初のユースケースのデータが安定したら、次のユースケースへ広げます。

質問に答えるだけでなく行動を起こすAIエージェントにも、同じ規律が重要です。レコードを更新したり候補者を振り分けたりするエージェントの安全性は、読み取るデータと与えられた権限で決まります。この点は人事向けAIエージェントで解説しています。

よくある間違い

• 先にツールを買い、パイロットでデータの問題に気づく。 ベンダーは整ったサンプルデータでデモを行います。本番の最初の1週間は、デモのようにはなりません。
• 一度きりのクレンジングで終わらせる。 スチュワードと月次チェックがなければ、新規採用、組織再編、システム変更が積み重なり、品質は1年以内に劣化します。
• 同意を万能薬と考える。 雇用主から求められた従業員が自由に拒否できないことは多く、職場での処理において同意は不安定な根拠になりえます。それぞれの用途にどの適法性の根拠が合うかは、顧問弁護士に確認してください。
• すべてをAIに送る。 連携を構築するチームには、項目が多いほうが安全に感じられます。しかし、データの持ち主である従業員にとってはリスクが高まります。
• 説明可能性を無視する。 どのデータがスコアを左右したのかをベンダーが説明できなければ、スコアが誤っていてもデータを修正できません。説明可能なAIは、モデルの要件であると同時にデータの要件でもあります。