SCORM進捗トラッキング

進捗の報告方法

SecureCodingHubはSCORM 1.2およびSCORM 2004 (3rdおよび4th edition) のレポートモデルの両方を実装するため、同じコンテンツパッケージは標準に準拠する任意のLMS内で実行されます。アクティブセッション中、プレーヤーはLMSが起動時に挿入するSCORM APIアダプターを介してLMSとランタイムデータを交換し、その交換が管理者が成績簿または完了レポートで見る4つのデータポイントを生成します。以下のフィールドは、すべてのコミットで書き込む正規セットです。特定のLMSベンダーは異なる列ラベルで表示しますが、基礎となる値は同じです。

学習者がトレーニングを完了すると、SCORMブリッジは次のデータをLMSに送信します:

• 完了ステータス (incomplete → completed)
• スコア (0-100)
• セッション時間
• 再開のためのブックマーク

これらはそれぞれ特定のSCORMデータモデル要素にマッピングされます。完了ステータスはSCORM 2004ではcmi.completion_statusに、SCORM 1.2ではcmi.core.lesson_statusに書き込まれます。スコアは両バージョンでcmi.score.rawに書き込まれ、スケールされた同等のものは2004のcmi.score.scaledのみです (1.2にはスケールフィールドはありません)。セッション時間はISO 8601期間形式でcmi.session_timeに蓄積され、再開ブックマークはcmi.suspend_dataにシリアル化されます。ブリッジはアクティブセッション中、ハートビートティックごとにこれらの要素を再コミットするため、中断されたセッションでも、LMSが表示できる部分的に報告された状態が生成されます。

完了基準

SCORMセッションは、学習者が組織内のすべての必須課題を完了したとき、または — 必須課題が保留されていない場合 — 記録された進捗があるときにcompleteとマークされます。しきい値は現在、課題ごとまたはパッケージごとに構成可能ではありません。同じロジックがプラットフォームによって生成されるすべてのSCORMパッケージに含まれています。

SCORM 2004はcompletion (学習者はアクティビティを終了したか) とsuccess (合格したか) を区別します。ブリッジは両方を報告します: cmi.completion_statusはアクティビティが終了したかどうかを反映し、cmi.success_statusは平均合格スコアしきい値が満たされたかどうかを反映します。SCORM 1.2には別々の完了 / 成功の分割はありません — ブリッジは完了がtrueになるとcmi.core.lesson_statusにpassedまたはfailedを書き込み、それ以外の場合はincompleteを書き込みます。

スコア計算

LMSが受信するスコアは、学習者の練習進捗からサーバー側で計算されます。内部スコアスケールは、チャレンジあたり0から160まで実行されます (フェーズ1 + フェーズ2、両フェーズはヒントなしの初回試行完了で最大100の価値があります)。SCORMフレンドリーな0-100の数を生成するために、ブリッジは学習者の完了したチャレンジ全体の練習スコアを平均し、1.6で割り、結果を100で上限します。変換は固定されています。このリリースでは、パッケージごとまたは課題ごとの重み付けはありません。

再開 / サスペンド

学習者が完了前にセッションを閉じた場合:

• 現在の位置がブックマークとして保存される
• 次の起動時にブックマークから再開
• セッションハートビートはアクティブな使用中にセッションを維持

完全なブックマーク — 学習者がどのトピックにいたか、どのチャレンジ、どのフェーズ、どのヒントを明らかにしたか — はSCORMパッケージ内ではなく、SecureCodingHubセッションレコードのサーバー側に存在します。ブリッジが実際にcmi.suspend_dataに入れるのは、SecureCodingHubセッションIDのみを含む小さなJSONエンベロープです (例えば{"sid":"..."})。再開時、ブリッジはそのIDを読み取り、SecureCodingHubセッションエンドポイントを呼び出し、サーバー側の状態を使用してプレーヤーを再水和します。したがって、LMSはチャレンジコンテンツ、回答履歴、ヒント状態を保持しません。

SCORMはSCORM 1.2仕様でcmi.suspend_dataに64KBの上限を強制し、多くの2004実装でも事実上同じ制限を強制します。ブリッジはセッションIDのみをLMSに書き戻すため、サスペンドペイロードは、課題の長さや学習者がサスペンドと再開する回数に関係なく、1キロバイト未満に留まります。

ハートビート

学習者がSCORMプレーヤーを開いている間、ランチャーは60秒ごとにPOST /api/sch/scorm/heartbeatでSecureCodingHubバックエンドにハートビートを発射し、セッションID、現在のブックマーク、蓄積されたセッション時間を運びます。同じティックがLMS側でSCORMデータモデルを再コミットするため、明示的な保存イベントを待つことなく、完了、スコア、セッション時間、サスペンドデータが同期されたままになります。

進捗の表示

管理者は以下からSCORMセッションを表示できます:

SecureCodingHub管理ビューは、きめ細かい分析の信頼できる情報源です: チャレンジごとの試行、ヒントの使用、タスクにかかった時間、学習者が選択した特定の修復。LMS成績簿はSCORMサマリー — 完了、スコア、セッション時間 — を見ており、コンプライアンスレポートと証明書発行に適した画面ですが、基礎となるステップバイステップデータの可視性はありません。ほとんどの管理者は両方のビューを併用します: 「学習者は終了して合格したか」のレポートにはLMS、「コホートが苦戦している場所はどこで、何を調整すべきか」の決定にはSecureCodingHubダッシュボード。より深い分析ワークフローと、ダッシュボードでの管理者ロール権限の設定方法については、管理者ダッシュボードのドキュメントと関連のロールと権限のガイドを参照してください。

xAPI発行はロードマップにあり、現在は利用できません。 出荷されると、SecureCodingHubはSCORMコミットと一緒に、同じチャレンジごとのイベント (ヒント表示、間違った試行、チャレンジ遷移) をLearning Record Storeにプッシュできるようになります。それまでは、SCORMコミットセットが唯一のすぐに使えるLMS画面であり、SecureCodingHub管理者ダッシュボードがイベントごとの粒度を確認できる唯一の場所です。