月曜日のデータ会議に、三つの画面が並ぶ。LMSには研修修了者の一覧、現場点検アプリには作業結果、CRMには顧客対応履歴がある。人材育成担当者が「研修後に仕事は変わったのか」と尋ねても、三つのシステムは同じ人、同じ課題、同じ時点を別々の形式で記録している。データ担当者が氏名と日付でファイルを結合すると、同姓同名や再受講が混ざる。一人が同じ教材を二度起動した場合、どちらを次の業務イベントにつなぐべきかも分からない。
不足しているのはデータ量ではない。コース―登録―起動―行動―結果をつなぐ識別子と規則である。修了イベントと現場イベントを同じ保管先に入れただけでは証拠にならない。どの登録から、どの学習活動を起動し、誰が記録を送り、どの業務課題に結び付いたのかを再構成できる必要がある。
cmi5は、xAPIを従来型LMSのコース起動に適用するためのプロファイルである。コース構造の取り込み、受講者の登録、LMSによるAU（Assignable Unit）の起動、認証、セッション、状態、修了条件を一貫して扱う規則を加える。cmi5そのものはLRSでも、分析ツールでも、コンピテンシー評価モデルでもない。散在するデータのうち、LMSから始まるセッション型学習を安定して束ねる契約である。
企業が決めるべきことは「SCORMをやめてcmi5を買う」ではない。まず、どの意思決定にどの証拠が必要かを定め、cmi5が担う範囲と、LMS外のxAPIや業務システムが担う範囲を分ける。その線引きがあって初めて、修了と業務経験を結びながら、クリックを能力に、相関を研修効果に読み替える誤りを避けられる。
修了と現場実践を切断しているのはイベントではなく識別子である
xAPIステートメントは一般に、誰が（actor）、何を行い（verb）、どの対象に対して（object）、どのような結果を残したか（result）を表現する。表現の自由度が高いため、同じ行動でもベンダーごとにverb、activity ID、拡張フィールドが異なり得る。ベンダーAのcompletedとベンダーBの修了表現が技術的に有効でも、同じ意味で比較できるとは限らない。
cmi5は、その自由度のうちLMSセッション学習に必要な共通規則を固定する。公式の概念文書が示すとおり、作成者はコースパッケージを作り、管理者はLMSへ取り込んで受講者を登録し、LMSがAUを起動する。LMSとAUはLRSへステートメントを送り、AUはLMSが用意した起動情報を取得する。
AICC/ADLのcmi5公式文書にある概念図は、コースパッケージ、LMS、LRS、AUと三つの役割の関係を示す。図そのものには「DRAFT Nov 20 – 2020」と記されている。現在のIEEE標準承認状況を示す図ではなく、本稿ではデータフロー上の役割分担を説明する目的に限って使用する。
一行の修了記録より重要なのは、次の識別子の層である。
| 層 | cmi5での役割 | 切れたときに起きる誤り |
|---|---|---|
| コース・AU | コース構造と個別に起動できる学習単位を識別 | どの版・活動を実施したか区別できない |
| actor | LMSが認証した受講者をaccountで表現 | メールアドレスや氏名の変更、同姓同名で人物を誤結合する |
| registration | 一人の受講者の一つのコース登録インスタンスを識別 | 再受講、反復研修、復習の記録が混ざる |
| session ID | 一回のAU起動セッションを識別 | 中断、再起動、複数タブのステートメントを区別できない |
| statement ID・authority | 一つのイベントと、その記録主体を識別 | 重複、衝突、出所不明の記録を判定できない |
| 業務証拠ID | チケット、作業指示、検査、成果物を識別 | 学習後の実践を追跡できない |
公式仕様では、registrationは一人の受講者に対する一つのコース登録インスタンスである。進捗中だけでなく、修了後のreviewまで維持される。反復研修や再受講で新たに登録するなら、新しいregistrationを作る。session IDはactorとregistrationに基づく一回のAU起動を識別し、LMSが生成する。両者を同一視すると、「同じコースに再登録した」のか、「同じ登録のまま教材を再び開いた」のかを判別できない。
cmi5はxAPIにコース・登録・起動の規則を加える
cmi5の適用範囲は明確である。現在公開されているQuartz仕様は、LMSによるAUの起動、起動時と実行時の環境、LMSとAUのデータ転送、AUが利用するコース定義、コース構造のインポートとエクスポート、LMSのレポート要件を扱う。それ以外のxAPI利用はcmi5仕様の範囲外だと明記されている。
したがってcmi5が決めるのは、「何を能力とみなすか」よりも「LMSセッションで、誰が、何を、どの条件で記録するか」である。
- 作成者が一つ以上のAUとコース構造XMLを作る。
- AUはZIP内に含めることも、外部URLから参照することもできる。
- 管理者がコース構造をLMSへ取り込み、受講者を登録する。
- LMSがendpoint、fetch、actor、registration、activityIdを起動URLに含める。
- AUがfetch URLからLRSアクセス用の認証トークンを一度取得する。
- LMSとAUが同じregistrationとsession IDをステートメントに含める。
- LMSが
moveOn規則に基づき、AU、ブロック、コースの充足を判定する。
この構造によって、「コンテンツがLMS外にある」ことと「活動がcmi5外にある」ことを区別できる。外部サーバーやモバイルアプリ上のコンテンツでも、LMSがcmi5の規則に従ってAUとして起動すればcmi5セッションに入る。一方、CRMで自然に発生した営業活動は、同じLRSへ保存しても自動的にcmi5ステートメントにはならない。
パッケージ―登録―セッション―ステートメントが一つの証拠連鎖をつくる
学習データ設計はイベントの一覧をつくる仕事ではない。証拠の連鎖を設計する仕事である。各段階で前後の識別子と判定規則を保たなければならない。
コースパッケージ・版
→ 受講者登録（registration）
→ AU起動（session ID）
→ cmi5 defined / allowed statements
→ 適用する業務課題
→ 業務成果物・品質結果
→ 研修の寄与に関する限定的な判断コースパッケージは、ルートにcmi5.xmlを置いたZIPでも、外部コンテンツを参照するXMLでもよい。cmi5は全教材を一つのZIPに収めることを強制しない。分散コンテンツやコンテンツサービスの運用には有利だが、URL、版、廃止、アクセス権限の責任まで消えるわけではない。
registrationが登録インスタンスを束ね、session IDが一回の起動を束ねる。xAPI statement IDは一件のイベント記録を、authorityは誰がその事実を主張したかを示す。次に、CRM、MES、点検システムなどのチケット、作業指示、検査IDを結び付けて、初めて実践へ進める。最後の段階で品質、速度、安全、顧客成果を見る。
この連鎖があっても、因果関係が自動的に成立するわけではない。同じ人が学習後に成果を上げたという接続は、時間的な順序と併存を示すにすぎない。課題の難易度、上司の支援、ツールの変更、チーム構成など別の説明を排除できない。cmi5は因果評価の標準ではなく、再現可能な学習接触と活動記録の基盤である。
一回のAU起動でも認証・状態・終了が先に動く
AUは単なる教材ファイルではない。LMSから個別に起動され、追跡・管理される単位である。公式のAU実装フローでは、起動前に受講者認証、権限、registrationが用意される。起動後、AUはトークン、状態文書、エージェントプロファイルを取得し、initializedステートメントを送ってから学習イベントを処理する。
AICC/ADL公式のAUフロー図は、初期化と終了の間で追加ステートメント、修了、合格・不合格がどう分岐するかを示す。実装順序を説明する図であり、すべてのOJTや業務イベントをAUにすべきだという意味ではない。
cmi5 definedステートメントでは、九つのverbを使う。送信主体と意味が異なるため、一つの「修了」ステータスへ押し込んではならない。
| 主体 | verb | 運用上の意味 |
|---|---|---|
| LMS | launched |
AUの起動を開始し、起動情報を用意した |
| AU | initialized |
AUが状態を読み、セッション処理を開始した |
| AU | completed |
受講者がAUの関連内容を経験した |
| AU | passed / failed |
所定の判定基準を通過した、または通過しなかった |
| LMS | abandoned |
異常終了した以前のアクティブセッションを閉じた |
| LMS | waived |
別の根拠によりAU要件を免除・充足扱いにした |
| AU | terminated |
AUがセッション処理を正常終了した |
| LMS | satisfied |
ブロックまたはコースのmoveOn条件を満たした |
仕様はcmi5 definedステートメントにおける同じverbの重複を制限する。同じ登録のAUでpassedとfailedを両方使うことはできず、passedの後にfailedを置くこともできない。状態を一貫して計算するための制約である。ただし、completedは業務習熟を意味しない。関連内容をすべて経験した事実と、実務の遂行品質は別の証拠である。
moveOnにはPassed、Completed、CompletedAndPassed、CompletedOrPassed、NotApplicableの五つがある。LMSはこの基準でAUの充足を判定し、ブロックまたはコース内のすべてのAUが条件を満たせばsatisfiedを記録できる。どの値を使うかは、学習目標と誤判定のリスクに応じて決める。単なる周知をPassedにしたり、高リスクな実習をCompletedだけで通したりすれば、技術上は動いても教育設計として誤っている。
九つのverbを集めても業務成果にはならない
cmi5は仕様で定めたverb以外のステートメントも許容する。AUが送るcmi5 allowedステートメントは、initializedとterminatedの間に置かれ、同じcmi5セッション識別子を含まなければならない。シミュレーション内の選択、ヘルプ要求、再試行といった細かな行動をxAPIで記録できる。
ただし、allowedステートメントはcmi5のセッション管理や充足規則へ自動的に使われない。記録を増やしてもmoveOn判定の妥当性は上がらない。クリック、動画位置、マウス移動をすべて集めれば分析対象は増えるが、従業員の判断力や業務遂行を示さない可能性がある。
行動イベントを証拠にするには、三つの問いが要る。
- 意味：そのイベントは、どの業務能力や判断を表すのか。
- 品質：発生の有無だけでなく、正確さ、難易度、誤りのコストをどう判定するのか。
- 用途：教材改善、コーチング、認定、人事評価のどこに使うのか。
同じデータでも用途が変われば、必要な品質と権利保護が変わる。学習経路の推薦には大まかな選好シグナルを使えるが、資格認定には検証された課題と評価者間の一致が要る。人事評価へ結び付けるなら、データ源、判定ロジック、訂正、異議申立ての経路を従業員へ明示する必要性がさらに高まる。
LMS外のOJT・業務経験はcmi5ではなく証拠契約でつなぐ
題名にある「LMS外」は、慎重に扱う必要がある。cmi5の中心的な利用場面は、受講者がLMSの画面からコンテンツを起動する状況である。CRM、MES、コールセンター、コードリポジトリ、現場点検などで自然に生じたイベントは、それ自体がcmi5の範囲ではない。別のxAPIプロファイルまたは業務データ契約で記録し、分析段階で学習証拠と結ぶ。
接続契約には、少なくとも次の項目を置く。
| 契約項目 | cmi5セッション学習 | LMS外の業務証拠 |
|---|---|---|
| 人物 | LMSが提供するactor account | HRIS・SSOと対応付けた安定的な仮名識別子 |
| 活動 | AU activityId・publisher ID | 業務課題、スキル、システムの永続IRIまたは基準ID |
| まとまり | registration・session ID | プロジェクト、チケット、作業指示、評価回ID |
| イベント | defined・allowed statement | 合意した業務verbとresultスキーマ |
| 出所 | LMS・AU authority | CRM、MES、評価者、センサーなどの記録主体と生成方法 |
| 品質 | moveOn、masteryScore、重複規則 | 難易度、ルーブリック、検証状態、欠損、誤り規則 |
| 用途 | コース進行・レポート | コーチング、業務改善、認定、人事判定ごとの許容範囲 |
actorを氏名やメールアドレスの文字列で直接結合しない。組織のID管理層で安定した内部IDをつくり、元の身元との対応表に触れられる人を絞る。activity IDも、コース名やチケット名のように変わる文言ではなく、持続する識別子を使う。スキルと業務課題を対応付ける際は、誰が、いつ、どの根拠でマッピングしたかを版として残す。
学習セッションと業務イベントを結ぶ時間窓も定義する。研修終了後に初めて担当した顧客応対、次の設備点検、次のコードレビューのように、実際の適用機会を基準にする。「30日以内の成果」を一律に研修へ帰属させてはならない。適用機会の有無、課題の難易度、上司の承認、システム変更も併せて記録する。
日本企業では、自己啓発、会社命令の研修、OJTで、就業時間の扱いもデータ利用の期待も異なる。人材育成担当者だけで一つの同意文へまとめず、労務、個人情報保護、情報セキュリティ、現場責任者と用途を分けて審査する。業務改善用に集めた詳細行動を、説明なしに人事評価へ転用しない運用境界が必要である。
イベント辞書は開発資料ではなく人材育成の測定契約である
cmi5プロジェクトをAPI連携から始めると、開発者はフィールドを実装できても、人材育成部門が何を主張するかは決まらない。最初に一枚のイベント辞書（event dictionary）をつくる。
| 問い | 合意の例 |
|---|---|
| どの意思決定に使うか | コース改善、コーチング配置、認定のいずれか一つに目的を絞る |
| どのイベントが必要か | 起動、初期化、修了、判定、終了と中核演習二～三件 |
| 何を同じ活動とみなすか | AU、コース、版、業務課題の永続ID規則 |
| 何を成功とみなすか | moveOnとは別に、実業務の品質判定線を定義する |
| 誰が事実を主張するか | LMS、AU、現場システム、上司・評価者のauthorityを分ける |
| いつ接続を止めるか | 目的終了、保存期間満了、同意・権限変更、品質不足 |
次に、架空の受講者一人の正常経路ではなく、失敗ケースで検証する。同一コースの再受講、AU中断後の再起動、ネットワーク断、重複ステートメント、誤ったmastery score、以前のセッションのabandoned処理、外部コンテンツURLの変更、アカウント移行、退職後の再入社、業務システムからの遅延送信を入れる。正常経路だけを通る連携は、運用証拠とは呼べない。
ダッシュボードも修了率より、証拠連鎖の健全性を先に見る。registration欠損率、session終了の完全性、重複・拒否ステートメント率、identityマッピング失敗率、業務課題接続率、記録遅延、出所不明率、削除・保存規則の履行率である。これらが安定してから、学習転移と業績を解釈する。
IEEE画面の「Active PAR」が調達文言を正確にする
2026年7月22日時点で、IEEE SAのP9274.3.1ページはステータスをActive PAR、PAR承認日を2023年2月15日と表示している。同じページのWorking Group Detailsには、承認済みのActive Standardsがないと示される。したがってP9274.3.1を、すでに承認・発行されたIEEE標準のように表現してはならない。
IEEE SA公式プロジェクトページは、P9274.3.1の名称、Active PAR、PAR承認日2023-02-15、オープンソースプロジェクト、Apache 2.0 CLAを表示する。PARは標準開発プロジェクトの承認状態であり、完成標準の発行を意味しない。完了時期をこの画面から推測しない。
現行運用で参照できる公開cmi5仕様はAICC/ADLリポジトリのQuartz 1st Editionで、改訂履歴は2016年6月1日を示す。ADLの35ページのBest Practices Guideは2021年6月14日付であり、現在もCATAPULT公式文書からリンクされている。古い資料であることと、公式実装資料としての役割を同時に明記する必要がある。
RFPや契約書には、「IEEE cmi5認証」のような広い表現ではなく、次を記載する。
- 実装対象とするcmi5仕様のstone、edition、commit、または固定URL
- 併用するxAPIの版とLRS適合性の範囲
- 対応するコースパッケージ形式とリモートAUの起動方法
- CATAPULT LMS Test Suite、Content Test Suiteの版と全結果
- registration、session、再起動、abandoned、waivedのテストケース
- definedとallowedステートメントの保存、検索、エクスポート方法
- ベンダー契約終了後に原本ステートメント、状態、コース構造を返却する形式
- セキュリティ、個人情報、保存・削除、アクセス権限を相互運用性とは別に審査する手順
適合性テストに通っても、自社の業務証拠設計が妥当だとは限らない。仕様適合、セキュリティ認証、データ品質、教育評価の妥当性は、それぞれ別の判定線である。
小さな一職種で証拠連鎖を端から端まで検証する
全社の学習履歴を一度に統合しない。適用機会が頻繁にあり、結果を比較できる一職種から始める。顧客問い合わせの分類、設備点検、コードレビューのように、業務イベントが明確な課題が向いている。
第一に、コース内で必要なdefinedステートメントと、主要なallowedステートメントだけを決める。第二に、registrationとsessionが再受講・再起動を正しく区別するかを見る。第三に、次の業務イベントのIDと品質判定をつなぐ。第四に、従業員と上司が記録を読み、実際の活動を再構成できるか確認する。第五に、接続できなかったイベントと誤接続したイベントを別標本として監査する。
成功基準は「LRSにデータが入った」ではない。同じ登録とセッションを再現でき、現場証拠の出所と品質を説明でき、従業員がどのデータをどの判断に使ったのか理解できることである。接続率が上がっても誤接続が増えれば失敗だ。
日本企業でも、LMS、人事システム、SSO、CRM・MES、データ基盤の所管部門は分かれていることが多い。人材育成部門は技術部門へフィールド一覧を渡すだけでなく、学習について何を主張するか、適用機会、判定線、データ用途、異議申立ての責任者を決める。セキュリティ、個人情報、労務の担当者は、actorのマッピング、業務行動の収集、人事評価への転用、保存・削除を別々に確認する。
cmi5の価値は、すべての経験を一つの形式へ変換することではない。LMSから始まる学習の境界を明確にし、その外側の業務証拠とつなぐ際に、何がcmi5で、何がcmi5ではないかを説明できるようにする点にある。良い学習データとは、多くつながったデータではなく、どこから始まり、どの規則で接続されたかを再び説明できるデータである。
あわせて読みたい記事
- 研修システム統合：LMS/LXPを増やす前に学習データを整える
- LMSセキュリティ認証、ISMAPとPマークは同じものを保証していない
- 学習分析の説明可能性：納得できないスコアはコーチングにならない
出典
- ADL Initiative, cmi5 Best Practices Guide: From Conception to Conformance, 2021-06-14
- AICC/ADL, cmi5 Specification Profile for xAPI — Quartz 1st Edition
- AICC/ADL, Conceptual Overview of cmi5
- AICC/ADL, cmi5 Implementation Flow for an AU
- ADL, CATAPULT Documentation
- IEEE SA, P9274.3.1 — Standard for Packaging, Launch, and Run-time of xAPI in Session-based Learning