第8章: HR Techのデータモデルと技術標準 — エンジニアの主戦場

HR施策が動かない理由の一部は、技術にある

前章まで、育成施策が形骸化する理由を主に組織と設計の問題として見てきました。 この章では、その下層——データモデルと技術標準——に降ります。

「スキルデータベースを作ったが誰も更新しない」「タレントマネジメントシステムが人事データの箱で終わった」 「学習履歴がLMSに閉じ込められていて移行できない」。 これらは根性の問題ではなく、データモデルの設計と標準の歴史から説明できる問題です。

この章は、シリーズの中で最もエンジニア向けです。 仕様の一次情報を辿りながら、この領域が何を解こうとしてきたのかを読み解きます。

第1世代 SCORM — データをLMSに閉じ込める

eラーニングの相互運用標準として最初に普及したのが SCORM（1.2 / 2004）です。 仕様を見ると、時代を感じさせる設計になっています。

第2世代 xAPI — 学習イベントをRDFトリプルにする

xAPI（Experience API、旧 Tin Can API）は、SCORMの制約を根本から外しました。 ステートメントの構造を見ると、設計思想がはっきりします。

{
  "id": "12345678-1234-5678-1234-567812345678",
  "actor": {
    "objectType": "Agent",
    "mbox": "mailto:learner@example.com"
  },
  "verb": {
    "id": "http://adlnet.gov/expapi/verbs/completed",
    "display": { "ja": "完了した", "en-US": "completed" }
  },
  "object": {
    "objectType": "Activity",
    "id": "http://example.com/courses/security-training"
  },
  "result": {
    "score": { "scaled": 0.85, "raw": 85, "min": 0, "max": 100 },
    "success": true,
    "completion": true,
    "duration": "PT45M30S"
  },
  "timestamp": "2026-08-10T09:00:00Z"
}

ステートメントの構造

Actor の型定義も特徴的です。Agent は個人を表し、IFI（inverse functional identifier）を1つだけ持ちます （mbox / mbox_sha1sum / openid / account のいずれか）。Group は anonymous（メンバーリスト必須）または identified（固有識別子あり）に分かれます。

Object の型には StatementRef（既存ステートメントをUUIDで参照）とSubStatement（保存せずにステートメント様の構造を埋め込む）もあります。

第3世代 cmi5 — xAPIに型を与える

xAPIには弱点がありました。コンテンツ起動の仕様を持たないことです。 「LMS内でどうコンテンツを起動するか」の取り決めがなく、 加えて表現力が高すぎるため、実装ごとに verb も activity ID もバラバラになり相互運用が壊れました。

そこで生まれたのが cmi5——xAPI のプロファイルです。 xAPIをデータ形式として使い、そこに厳密なデプロイメントプロトコル （セッションの初期化方法、必須イベント、終了方法）を追加します。

証明の技術 — Open Badges 2.0 → 3.0

学習の成果を外部に証明する仕組みも、世代交代しています。

graph TD
  subgraph V2["Open Badges 2.0 — サーバー依存検証"]
    A1[PNGのメタデータチャンクに<br/>JSONを埋め込む baking] --> A2[検証時に<br/>発行者サーバーへHTTPリクエスト]
    A2 --> A3["発行者サーバーが落ちると<br/><b>バッジが検証不能</b>"]
  end

  subgraph V3["Open Badges 3.0 — 署名依存検証（2023年）"]
    B1[W3C Verifiable Credentials<br/>Data Model 2.0 準拠] --> B2[発行組織による<br/>デジタル署名 Proof]
    B2 --> B3["検証が<b>オフラインで完結</b><br/>発行者のホスティングに依存しない"]
  end

  A3 -.PKI的転換.-> B1

  style A3 fill:#ef4444,stroke:#dc2626,color:#fff
  style B3 fill:#10b981,stroke:#059669,color:#fff

バージョンの変遷を整理します。

• 2.0：基礎版。baking——バッジ情報をポータブルな画像ファイルに焼き込む
• 2.1：Badge Connect API（OAuth 2.0によるクレデンシャル転送）
• 3.0（2023年公開）：W3C Verifiable Credentials Data Model 2.0 準拠。 各クレデンシャルが発行組織によってデジタル署名される

データ構造は OpenBadgeCredential（個別のアチーブメント主張）、Achievement（基準を伴う達成の定義）、Issuer、Proof（暗号署名）、Evidence（補足資料）、Endorsement credential（第三者推薦）、Framework alignment（コンピテンシフレームワークへの紐付け）から成ります。

関連する CLR（Comprehensive Learner Record） は、 複数の関連アチーブメントクレデンシャルを ClrCredential として成績証明書的に束ねる仕組みです。

スキルタクソノミー — 分類学か、検索インデックスか

学習履歴の次は、スキルそのものの表現です。 公開されている代表的なタクソノミーを比較すると、設計思想が正反対であることが分かります。

日本のスキル標準

日本では経済産業省とIPAが共同策定するデジタルスキル標準（DSS）があります。

• DSS-L（DXリテラシー標準）：2022年3月公表。全てのビジネスパーソンが身につけるべき能力・スキル
• DSS-P（DX推進スキル標準）：2022年12月新設。DX推進人材のロール定義とスキル
• ver.2.0：2026年4月16日公表。 「データマネジメント」カテゴリを新設し、AI実装・運用・AIガバナンス関連のスキルを追加

従来からある ITSS / ITSS+ / UISS / iコンピテンシ・ディクショナリとの棲み分けは、 ITSSがIT技術専門職向けであるのに対し、 DSSは非IT部門を含む全ビジネスパーソンをDX推進の観点で対象にする点にあります。

スキルデータの陳腐化という構造問題

ここに、企業のスキル管理が破綻する構造的な理由があります。

graph LR
  A["外部タクソノミー<br/>O*NET: 四半期更新<br/>Lightcast: 継続更新"] --> C{"ズレが<br/>四半期単位で<br/>蓄積"}
  B["自社スキルマスタ<br/>年1回の棚卸しが関の山"] --> C
  C --> D["労働市場の語彙と<br/>自社マスタが乖離"]
  D --> E["主要ベンダーが一斉に<br/><b>AIスキル推論</b>へ舵を切る"]
  E --> F["ただし aspiration と motivation は<br/><b>推論できない</b>"]

  style C fill:#f97316,stroke:#ea580c,color:#fff
  style E fill:#8b5cf6,stroke:#7c3aed,color:#fff
  style F fill:#10b981,stroke:#059669,color:#fff

O*NETは四半期更新、Lightcastは継続的に追加・削除・用語整理を行い変更履歴まで公開します。 対して企業の自社スキルマスタは年1回の棚卸しが関の山です。 したがって自社の固定スキル体系は、外部の労働市場語彙とのズレが四半期単位で蓄積していきます。

これが、主要ベンダー（Workday、SAP、Eightfold、Gloat）がそろってAIによるスキル推論（skills inference）に舵を切った直接の理由です。 人手入力に依存しない設計こそが、現在のプロダクト思想の中心にあります。

プロダクトのデータモデル

SAP SuccessFactors Talent Intelligence Hub

最も情報が公開されている実装です。3つのコンポーネントから成ります。

Gloat — HR TechがRAGアーキテクチャに収斂する

タレントマーケットプレイスの Gloat は、AIエージェント時代のアーキテクチャに明確に寄せています。

• Knowledge Graph："People, jobs, skills connected"
• Governance Engine："Business rules for AI agents"
• Retrieval & Embedding："Semantic workforce search"
• Intelligent Tools：14の目的別HR機能

ナレッジグラフ + 埋め込み + リトリーバル + ガバナンスエンジン—— そのままRAGアプリケーションのアーキテクチャです。 HR Techがベクトル検索基盤に収斂しつつあることを、製品構成が示しています。

海外製の「強い型」 vs 日本製の「スキーマレスな器」

日本製のタレントマネジメントシステムを並べると、設計思想の差がはっきりします。

なぜ統合が難しいのか — 4つの理由

ここまでの内容を、統合の困難さという観点で整理します。 まず、主要エンティティがそれぞれ別の権威システム（system of record）に分散しています。

Worker（人材マスタ）        → HRIS / 基幹人事
Position / Job Profile     → HRIS（組織改編で頻繁に変わる）
Skill                      → タレント基盤 or 外部タクソノミー
Learning Activity / Record → LMS（レガシー含め複数併存しがち）
Rating / Evaluation        → パフォーマンス管理
Candidate                  → ATS

補足すると、HR Open Standards は1999年設立の、 HR関連データ交換の標準仕様を開発する唯一の独立系・非営利・ボランティア主導の組織です。 HR-JSON / HR-XML の標準ライブラリを提供し、 Trusted Career Profile（リリース済み）、JEDx Open API Specification（確定）といった成果を出しています。 そのなかでスキル習熟度のAPIスキーマがまだプレリリース段階だという事実が、 この領域の相互運用性の現在地を端的に示しています。

運用のアンチパターン

「人事データの箱」で終わる

最も象徴的な数字が、LinkedIn Workplace Learning Report 2025 のこれです。

過去6か月にキャリアプラン構築を支援したマネジャーは、わずか15%。 しかも前年から5ポイント低下している。

システム導入とマネジャーの行動変容は独立事象である、ということをこの数字が示しています。 構造的な原因は2つです。

• 入力コストが入力者に返ってこない：スキル情報を入力するのは従業員とマネジャーで、 便益を受けるのは人事と経営です。コストと便益の非対称が構造化されています
• 更新のトリガーがない：外部タクソノミーは四半期・継続で更新されるのに、 自社マスタは年1回の棚卸しでしか動きません

LMSの移行コストが極端に高い理由

Cornerstone OnDemand の製品構成に、レガシー製品として Saba と SumTotal が併存しています。 買収でLMSを集めた企業が統合しきれない典型例です。

理由は明快で、既存SCORMコンテンツ・学習履歴・コンプライアンス証跡の3つが移行の壁になります。 特にコンプライアンス研修の受講証跡は法定の保存義務が絡むこともあり、捨てられません。 そして冒頭で見たとおり、SCORMは学習履歴をLMS内部に閉じ込める設計でした。

xAPI + LRS の構成が意味を持つのはここです。学習記録を最初からLMSの外に置いておけば、LMSは交換可能なコンポーネントになります。 ログをアプリケーションから分離しておくのと同じ発想です。

AI × 人材育成の現在地（2025-2026）

最後に、AI活用の実装状況を確認します。実在が確認できたものに限ります。

次章はシリーズの最終章です。ここまで見てきた仕組み—— スキルデータ、ポテンシャル評価、学習ログ、AI推論——が、 法規制と倫理の観点でどう扱われるのかを確認します。 EU AI Act は昇進とタスク配分を高リスクに指定し、職場での感情推認をすでに禁止しています。