SQL LRS 導入で失敗しないために LearningLocker から移行する前に確認すべき「データ領域」の違い
xAPI を活用した学習履歴の収集や分析を進めるうえで、LRS（Learning Record Store）の選定は重要なテーマです。既に LearningLocker を利用している企業の中には、運用コストやシステム構成の見直しをきっかけに、 SQL LRS への移行を検討するケースもあります。
しかし、SQL LRS への移行は、単に LRS 製品を置き換えるだけでは完了しません。
特に注意すべきなのが、 LearningLocker に存在する「Organization」という考え方と、 SQL LRS におけるデータ領域の扱いの違いです。
この違いを理解しないまま導入や移行を進めると、クライアント別、プロジェクト別、サービス別に分離していた xAPI データが想定通りに管理できなくなる可能性があります。
【 目次 】
- ・SQL LRSとは
- ・LearningLockerとSQL LRSの大きな違い
- ・LearningLockerからSQL LRSへの移行時に起こりやすい問題
- ・SQL LRS導入前に確認すべきポイント
- ・SQL LRSは設計次第で有効な選択肢になる
- ・SQL LRS に独自検索システムを追加したスパイスワークスの事例
- ・教育ICT分野でのスパイスワークスの支援領域
SQL LRSとは
SQL LRS は、 xAPI に対応した学習履歴データを蓄積し、必要に応じて取り出すための LRS です。
xAPI では、学習者の行動を「誰が」「何を」「どうした」という Statement として記録します。
LMS上の受講履歴だけでなく、動画視聴、外部ツールでの演習、実地研修、シミュレーション、アプリ内の行動など、さまざまな学習体験を記録できる点が xAPI の特徴です。
LRS は、これらの Statement を受け取り、保存し、検索や分析に利用できる状態にするための基盤です。そのため、導入時には「 xAPI に対応しているか」だけではなく、「自社の運用単位に合ったデータ管理ができるか」を確認する必要があります。
LearningLockerと SQL LRS の大きな違い
LearningLocker を利用している企業では、 Organization を前提にした運用が組まれていることがあります。
LearningLocker では、1つのインスタンス内に複数の Organization を作成できます。それぞれの Organization は、別々のデータ領域のように扱うことができ、 Organization ごとにアクセスキーを発行することも可能です。
たとえば、以下のような使い方ができます。
・クライアントA向けの Organization
・クライアントB向けの Organization
・社内研修向けの Organization
・実証実験向けの Organization
この構成では、1つの LearningLocker インスタンスで複数クライアント、複数プロジェクト、複数サービスの xAPI データを分離して管理できます。受け入れ側の LRS は1つでも、運用上は複数のデータ領域を持っているように扱える点が特徴です。
一方、SQL LRS には、 LearningLocker の Organization に相当する概念がありません。基本的には、1つの SQL LRS インスタンスが1つの xAPI データ領域として扱われます。
そのため、 LearningLocker で Organization ごとに分けていた構成を SQL LRS で再現する場合は、複数の SQL LRS インスタンスを用意する設計が必要になります。
LearningLocker から SQL LRS への移行時に起こりやすい問題
LearningLocker から SQL LRS へ移行する際に起こりやすい問題は、「 LRS を置き換えれば同じ運用が継続できる」と考えてしまうことです。
たとえば、 LearningLocker で4つの Organization を使っていた場合、その4つはデータ分離、アクセスキー、接続先、分析対象の単位として使われている可能性があります。
この構成をそのまま SQL LRS の1インスタンスにまとめてしまうと、以下のような課題が発生します。
・クライアント別のデータ分離が曖昧になる
・既存システムの送信先エンドポイントを再設計する必要がある
・アクセスキーや認証情報の管理方法が変わる
・既存レポートや分析処理の前提が崩れる
・移行後にデータ取得や検証が複雑になる
SQL LRS 自体が問題なのではありません。重要なのは、 LearningLocker と SQL LRS では、データを分ける単位が異なるという点です。
SQL LRS 導入前に確認すべきポイント
SQL LRS を導入する際には、まず現在の LRS 運用を整理することが重要です。特に LearningLocker から移行する場合は、以下の観点を事前に確認しておく必要があります。
1. Organization の利用状況
現在いくつの Organization を利用しているか、それぞれがどのクライアント、プロジェクト、サービスに紐づいているかを確認します。使われていない Organization がある場合は、移行前に整理することで構成をシンプルにできる場合があります。
2. データ分離の要件
クライアントごと、事業部ごと、研修ごとにデータを完全に分ける必要があるかを確認します。契約上またはセキュリティ上、データ混在を避ける必要がある場合は、 SQL LRS インスタンスを分ける設計が有力です。
3. アクセスキーと接続元の整理
LearningLocker では Organization ごとにアクセスキーを発行しているケースがあります。 SQL LRS への移行時には、どのシステムが、どのエンドポイントに、どの認証情報で Statement を送信するのかを再設計する必要があります。
4. 既存データの移行方針
LearningLockerに蓄積された xAPI Statement を SQL LRS へ移行する場合、対象期間、対象 Organization 、 Statement 数、添付データの扱い、重複登録の防止、移行後の検証方法を整理します。移行は単なるデータコピーではなく、移行先のインスタンス構成に合わせたデータの振り分けが重要です。
5. データ取得と分析処理の見直し
既存のダッシュボード、レポート、外部システムが LearningLocker の Organization 構成を前提にしている場合、 SQL LRS 移行後には取得方法や検索条件の修正が必要になります。データを入れる処理だけでなく、取り出す処理も合わせて確認することが大切です。
SQL LRS は設計次第で有効な選択肢になる
SQL LRS は、 xAPI データを扱う基盤として有効な選択肢です。一方で、 LearningLocker と同じ感覚で導入、移行できるわけではありません。
特に、 Organization の有無によるデータ領域の違いは、導入前に必ず確認すべきポイントです。
SQL LRSを安定して運用するには、以下のような設計が欠かせません。
・どの単位で SQL LRS インスタンスを分けるか
・既存の LearningLocker Organization をどう対応付けるか
・xAPI Statement をどのように移行するか
・各システムの送信先エンドポイントと認証情報をどう切り替えるか
・移行後のデータ取得、分析、運用監視をどう行うか
これらを事前に整理することで、 SQL LRS への移行はより現実的で安定したプロジェクトになります。
SQL LRS に独自検索システムを追加したスパイスワークスの事例
SQL LRS は xAPI に対応しているため、 Statement の書き込みや取得の機能を標準で備えています。 Statement API を利用すれば、 xAPI 仕様で定義された検索パラメータを使って、蓄積された Statement を取得できます。
代表的な検索パラメータには、以下のようなものがあります。
・statementId：指定した Statement ID の単一 Statement を取得する
・voidedStatementId：指定した Voided Statement ID の無効化済み Statement を取得する
・agent：指定した Actor または Object が一致する Statement を取得する
・verb：指定した Verb ID と一致する Statement を取得する
・activity：Object が指定 Activity ID のStatement を取得する
・registration：指定した registration ID と一致する Statement を取得する
・related_activities：activity フィルタを広義に適用し、Context Activities なども対象に含める
・related_agents：agent フィルタを広義に適用し、 Authority や Team なども対象に含める
・since：指定時刻より後に stored された Statement を取得する
・until：指定時刻以前に stored された Statement を取得する
・limit：返却する最大件数を指定する
・format：ids, exact, canonical のいずれかで返却形式を指定する
・attachments：添付ファイルを同梱するかどうかを指定する
・ascending：stored 時刻の昇順または降順を指定する
これらは xAPI 標準の検索条件として有効ですが、実際の業務システムでは、必ずしも標準パラメータだけで検索要件を満たせるとは限りません。
あるお客様の事例では、既存システムから xAPI Statement を SQL LRS へ取り込む構成になっていました。しかし、既存システム側が持っている独自の管理IDや業務上の検索条件では SQL LRS を直接検索できず、必要なデータを取り出す際に手間がかかっていました。
そこで、 SQL LRS 本体のプログラムを直接改修するのではなく、独自検索用の API を別途開発しました。この API では、独自システムのデータベースと SQL LRSのStatement データを両方参照し、既存システムが持つパラメータを使って検索できるようにしています。
また、独自パラメータだけでなく、 statementId, agent, verb, activity, since, until などの xAPI 標準パラメータでも検索できるように設計しました。これにより、既存業務システムの検索性を維持しながら、 xAPI 標準に沿ったデータ取得にも対応できる構成を実現しています。
SQL LRS を導入する際には、 Statement を保存できるかだけでなく、「運用現場が必要とする条件でデータを取り出せるか」も重要です。既存システムの検索条件、レポート要件、管理画面の使い方に合わせてAPIを設計することで、 SQL LRS をより実務に適した形で活用できます。
教育ICT分野でのスパイスワークスの支援領域
株式会社スパイスワークスでは、これまで20年におよび携わってきた教育工学研究分野でのシステム開発の知見を活かし、LTI 1.3対応コンサルティング、SQL LRSの構築・運用、LearningLockerからSQL LRSへのデータ移行を支援しています。
また、xAPIを使ったデータ入力処理、LRSからのデータ取得処理、既存システムとの連携実装にも対応可能です。
「LearningLockerから SQL LRS へ移行したいが、Organizationの扱いで悩んでいる」
「複数クライアントの xAPI データをSQL LRSでどう分離すべきか相談したい」
「LRS の導入だけでなく、データ活用まで含めて設計したい」
このような課題をお持ちの場合は、ぜひ株式会社スパイスワークスへご相談ください。現在のLRS構成や運用要件を確認したうえで、SQL LRS導入・移行に適した構成をご提案します。
