SCORM vs xAPI（Tin Can API）——次世代規格との違いと移行ガイド

1. SCORMとxAPI——何が違うのか

SCORMとxAPIの違いを一言で表すなら、SCORMは「教室内の出席簿」、xAPIは「行動すべてを記録する日記帳」 です。

SCORMは「LMSの中でWebブラウザを使って学習する」という前提で設計されています。教材をLMSに登録し、学習者がブラウザで教材を開き、進捗やスコアがLMSに記録される——これがSCORMの世界です。記録できる項目はあらかじめ決められており、「テストの点数」「完了/未完了」「学習時間」といった定型データが中心です。出席簿に「出席・欠席・遅刻」を記入するように、決まった枠の中に情報を記録する仕組みです。

一方のxAPIは、「誰が・何をした・何に対して」というシンプルなステートメント形式で、あらゆる学習体験を自由に記録できます。LMSの中での学習に限らず、モバイルアプリでの操作、VRシミュレーターでの訓練、対面研修への参加、書籍の閲覧まで——学習に関わるすべての行動を記録対象にできます。日記帳のように、何をいつどこでやったかを自由に書き込めるイメージです。

この根本的な違いが、対応環境、データの柔軟性、導入コストなど、あらゆる面での差異につながっています。

2. xAPIとは？

xAPIの正式名称は Experience API です。開発初期には Tin Can API という名称で呼ばれており、現在でもこの旧称が使われることがあります。

xAPIの歴史は2010年に遡ります。ADL（Advanced Distributed Learning）がSCORMの次世代規格の研究プロジェクトを立ち上げ、その開発を Rustici Software に委託しました。Rustici SoftwareはSCORMの技術に精通した企業であり、SCORMの限界を知り尽くした上で新規格の設計に取り組みました。

2013年にxAPI バージョン1.0がリリースされ、その後もバージョン1.0.1、1.0.2、1.0.3と改訂が重ねられています。2023年にはIEEE 9274.1.1として国際標準規格にもなりました。

xAPIの核となる設計思想は以下の3つです。

• ステートメント形式——学習データを「Actor（誰が）+ Verb（何をした）+ Object（何に対して）」のJSON形式で記録する
• LRS（Learning Record Store）——学習記録の保存先としてLRSを使用する。LMSとは独立して運用可能
• あらゆる学習環境に対応——Webブラウザに限らず、モバイル・デスクトップ・IoT・対面など、学習が発生する場所を問わない

3. 機能比較表

SCORMとxAPIの違いを項目ごとに整理します。ここではSCORM 1.2（最も普及しているバージョン）を比較対象とします。

※LMS対応率は編集部の調査・実務経験に基づく目安です

4. SCORMの強みと限界

SCORMの強み

圧倒的な普及率とLMS互換性 がSCORM最大の強みです。SCORM 1.2はほぼ100%のLMSが対応しており、「この教材はこのLMSで動くだろうか？」という心配がほとんどありません。iSpring、Articulate Storyline、Adobe Captivateなど主要なオーサリングツールもすべてSCORM出力に対応しています。

20年以上の実績 も大きな資産です。導入事例やトラブルシューティングの知見が豊富にあり、ベンダーへの問い合わせやコミュニティでの情報収集が容易です。担当者の異動や退職があっても、SCORMであれば後任者が対応できる可能性が高いでしょう。

導入コストの低さ も見逃せません。既存のLMSとオーサリングツールの組み合わせでそのまま使えるため、追加投資なしにeラーニングを始められます。

SCORMの限界

一方で、SCORMには明確な制約があります。

• Webブラウザ限定——教材はLMS内のブラウザウィンドウ（またはフレーム）で実行される必要があり、モバイルアプリやデスクトップアプリケーションからの学習記録には対応できない
• LMS必須——SCORMコンテンツは必ずLMS上で動作する必要があり、LMSがなければ学習記録を取得できない
• データモデルが固定——記録できるデータはSCORMの仕様で定義された項目（スコア、完了ステータス、学習時間など）に限られ、独自のデータを追加するにはcmi.suspend_dataなどを工夫して使うしかない
• オフライン不可——LMSとの通信が前提のため、ネットワークが利用できない環境では学習記録を取得できない
• クロスドメイン不可——教材とLMSは同一ドメイン上に存在する必要がある（SCORM 1.2の場合）

これらの制約は、2001年当時のWeb技術を前提とした設計に起因しています。当時はブラウザでの学習が主流であり、モバイルやVRでの学習は想定されていませんでした。

5. xAPIの強みと限界

xAPIの強み

あらゆる学習活動を記録できる柔軟性 がxAPI最大の強みです。「主語＋動詞＋目的語」のステートメント形式はシンプルかつ拡張性が高く、以下のような多様な学習体験を記録対象にできます。

• モバイルアプリでのクイズ回答
• VR/ARシミュレーターでの操作ログ
• OJT（現場研修）への参加・評価記録
• 動画コンテンツの視聴ログ（再生・一時停止・スキップ・完了）
• 対面ワークショップのチェックイン・フィードバック

モバイル・VR・IoT対応 もxAPIの大きなメリットです。REST APIベースの通信方式により、ブラウザ以外のあらゆるアプリケーションから学習データを送信できます。

オフライン対応 も可能です。ネットワークが利用できない環境でも学習記録をローカルに蓄積し、オンライン復帰時にLRSへ一括同期するという運用ができます。工場や建設現場など、常時インターネット接続が保証されない環境での研修に適しています。

ラーニングアナリティクスとの親和性 も見逃せません。xAPIで収集した詳細な行動データをBI（ビジネスインテリジェンス）ツールで分析し、「どの学習活動が業務成果に結びついているか」といった高度な分析が可能になります。

xAPIの限界

しかし、xAPIにも無視できない課題があります。

• LRS（Learning Record Store）が必要——学習記録の保存にはLRSが必須であり、LMSとは別にLRSを導入・運用するコストが発生する。LRS内蔵型のLMSも増えているが、まだ少数派
• 対応LMSが限定的——xAPIに対応したLMSは増加傾向にあるものの、SCORM対応率には遠く及ばない。特に国内LMSでの対応は限られている
• 導入コストが高い——LRS導入費用に加え、ステートメント設計（どのような動詞・アクティビティを使うか）、開発工数、運用体制の構築など、SCORMに比べて総コストが大幅に増加する
• ノウハウ・人材の不足——xAPIの設計・実装に精通したエンジニアや教材設計者はまだ少なく、社内で対応できる人材を確保しにくい
• 標準化の課題——ステートメントの設計が実装者に委ねられるため、組織間やシステム間でデータの互換性を確保するには、共通のプロファイル（語彙の取り決め）を策定する必要がある

6. いつxAPIに移行すべきか？——判断チェックリスト

xAPIへの移行を検討する際は、以下の5つの条件を確認してください。

• [ ] LMS外の学習も記録したい——モバイルアプリ、VR/ARシミュレーター、対面研修、OJTなど、Webブラウザ以外での学習を一元的に記録・管理する必要がある
• [ ] オフライン環境での学習記録が必要——ネットワーク接続が不安定または利用できない環境で学習が行われ、後からデータを同期したい
• [ ] 詳細な学習行動データを分析したい——SCORMの「スコア」「完了/未完了」だけでは足りず、学習者の細かな行動パターン（動画の視聴行動、シミュレーターの操作手順など）を分析したい
• [ ] 複数システム間の学習データを統合したい——複数のLMS、アプリ、外部サービスにまたがる学習記録を一箇所に集約し、横断的に分析・レポートしたい
• [ ] LRS導入の予算と技術リソースがある——LRSの導入・運用コスト、ステートメント設計の工数、開発・保守の体制を確保できる

5つすべてに「いいえ」と答えた場合は、SCORMのままで問題ありません。 無理にxAPIに移行する必要はなく、SCORMで十分に要件を満たせます。

逆に、1つでも「はい」がある場合は、xAPIの検討価値があります。ただし「はい」の数が1〜2個であれば、全面移行ではなく「SCORMをメインにしつつ、特定の用途でxAPIを併用する」ハイブリッドアプローチが現実的です。

7. SCORMからxAPIへの移行ステップ

xAPIへの移行は一気に行うのではなく、段階的に進めることを強く推奨します。以下の3段階で進めるのが安全です。

ステップ1: SCORMを維持しつつxAPIを試験導入

まずは既存のSCORM環境はそのまま維持し、小規模なパイロットプロジェクトでxAPIを試します。

• LRS（Learning Record Store）を選定・導入する（クラウド型LRSなら初期コストを抑えられる）
• 既存のSCORMコンテンツを引き続きLMSで配信する
• 新規に作成する1〜2個のコンテンツ、またはSCORMでは記録できない学習活動（モバイル学習、対面研修の記録など）でxAPIを試す
• xAPIステートメントの設計方針（使用する動詞・アクティビティの定義）を策定する

ステップ2: SCORM＋xAPI併用運用

パイロットで得た知見をもとに、xAPIの利用範囲を段階的に拡大します。

• LRS内蔵型のLMS、またはLMSとLRSの連携を構築する
• SCORM教材はこれまで通りLMSで配信しつつ、xAPIデータもLRSに蓄積する（多くのLMSはSCORM教材の学習記録をxAPIステートメントに変換してLRSに送信する機能を持つ）
• LMS外の学習活動をxAPIで記録し、LRSに集約する
• 学習データの分析・レポーティング体制を整備する

ステップ3: xAPI完全移行（必要な場合のみ）

すべての学習活動をxAPIで記録・管理する段階です。ただし、この段階に進む必要があるケースは限定的です。

• すべての新規コンテンツをxAPI対応で作成する
• 既存のSCORMコンテンツを順次xAPI対応に変換する（変換ツールやラッパーの利用も検討）
• SCORMベースの運用を完全に終了する

重要な注意点: ステップ3はすべての組織に必要なわけではありません。多くの場合、ステップ2の「SCORM＋xAPI併用」が最も合理的な着地点です。SCORMで問題なく運用できている教材をわざわざxAPIに作り替えるメリットは薄く、コストに見合わないケースがほとんどです。

8. 2026年の現実的な選択肢

2026年現在の率直な評価をお伝えします。

ほとんどのeラーニング案件では、SCORMで十分です。 企業研修のコンプライアンス教育、製品知識研修、新入社員研修、資格試験対策——こうした一般的なeラーニングであれば、SCORM 1.2（または必要に応じてSCORM 2004）で過不足なく対応できます。

xAPIは強力な技術ですが、「SCORMでは実現できない明確な要件」がある場合に初めて検討すべきものです。「xAPIが新しいから」「将来的にSCORMは廃れるかもしれないから」という理由だけで移行するのは、コストとリスクに見合いません。

SCORMが今後すぐに廃止される見込みはありません。ADLはSCORMの後継としてxAPIやcmi5を推進していますが、SCORM対応のLMS・ツール・コンテンツは膨大な数が存在しており、業界全体がxAPIに移行するには相当の年月がかかります。

現実的なアプローチは以下のとおりです。

• 基本はSCORMで配信する——実績・互換性・コストのバランスが最も優れている
• SCORMで対応できない要件にはxAPIを併用する——モバイル学習、VR/AR研修、オフライン研修、詳細なラーニングアナリティクスなど
• 将来のxAPI移行に備えて情報収集は続ける——LRSの動向、対応LMSの増加、cmi5の普及状況などを定期的にチェックする

9. まとめ

• SCORMは「LMS内のブラウザ学習」に特化した規格、xAPIは「あらゆる学習体験の記録」に対応する次世代規格
• 2026年現在、LMS対応率・導入コスト・実績の面でSCORMが依然として最も実用的な選択肢
• xAPIへの移行は「SCORMでは実現できない明確な要件」がある場合に検討し、段階的に進めるのが安全
• 多くの組織にとって最適解は「SCORMをメイン＋必要に応じてxAPIを併用」のハイブリッド運用
• 「とりあえずxAPIに移行」は非推奨——まずは自社の要件を5つのチェック項目で確認することから始めよう

SCORMやxAPIに関する個別のご相談は、お問い合わせフォームよりお気軽にご連絡ください。貴社の要件に合った規格選定や移行計画のアドバイスも承っております。