1. 受講ログあり
1.1. 中断情報あり
1.1.1. 中断中
1.1.1.1. ※中断情報を取得して前回の状態を復帰後、中断データを削除
1.1.1.2. 最新の受講ログセッション未終了
1.1.1.2.1. セッションを引き継いで、中断データ復帰
1.1.1.3. 最新の受講ログセッション終了済み
1.1.1.3.1. 新規ログセッションデータを作成し、中断データ復帰
1.2. 中断情報なし
1.2.1. 最新の受講ログセッション未終了
1.2.1.1. 受講中
1.2.1.1.1. セッションを引き継いで開く（受講画面の二重起動は許容。ただし履歴は先勝ち）
1.2.2. 最新の受講ログセッション終了済
1.2.2.1. 受講済
1.2.2.1.1. 複数回受講可能な場合は、再度受講開始のルートへ
2. 受講ログなし
2.1. 未受講
2.1.1. 通常の受講開始ルートへ
3. イレギュラー制御
3.1. ×で閉じた場合
3.1.1. 中断情報なしで未終了の状態なので、受講中になる
3.1.2. ※CCPや動画再生の場合はできるだけscriptで中断状態に持っていきたい。但し中断不可のコンテンツもあるため注意が必要。
3.2. ネットワーク断
3.2.1. 中断情報なしで未終了の状態なので、受講中（未終了の受講ログあり、中断情報なし）になる
3.3. 途中で受講終了する（中断じゃない）
3.3.1. 中断可の場合
3.3.1.1. 出来るだけ中断状態にもって行く
3.3.2. 中断不可の場合
3.3.2.1. 中断情報なしで受講終了（≠完了・合格）した状態なので、次回受講開始時は初めからスタートになる
3.4. 受講終了を書き込もうとしたときに、対象のセッションが既に終了済だった場合
3.4.1. 既に履歴登録済みとしてエラー表示（先勝ち）
3.4.1.1. 受講履歴は確定後は不変だから
3.5. 中断情報を書き込もうとしたときに、すでに中断情報があった場合
3.5.1. 中断情報を上書き（後勝ち）
3.5.1.1. ※中断情報は変わりうるから
4. CCH（アプリAPI）との連携
4.1. CCHでの受講
4.1.1. 中断データの扱い
4.1.1.1. オンラインの場合は、DBから中断情報を取得して再開可
4.1.1.2. オフラインの場合は、頭から受講
4.1.1.2.1. CCH上に中断情報がある
4.1.1.2.2. CCH上に中断情報がない
4.1.2. 受講終了時の処理
4.1.2.1. アプリAPI側で制御
4.1.2.1.1. completeの場合、受講終了とする
4.1.2.1.2. imcompleteの場合、中断データを作成し、受講終了とはしない
4.2. CCHでオフライン受講中に中断→次回通信時にデータ送信し、既存の中断情報があった場合
4.2.1. 中断情報を上書き（後勝ち）※イレギュラー制御と同様
5. その他（議論の経緯）
5.1. 多重起動された場合に都度ログセッションを作っていくのは？
5.1.1. 完了していないログセッションデータが増え続ける恐れがある
5.1.2. 中断データがあった場合に、どのログセッションで再開すべきか分からない
5.2. 中断データの復元可否判定
5.2.1. コンテンツバージョンIDを中断データにも持っておき、ログセッション情報と一致するか確認
5.2.1.1. 一致
5.2.1.1.1. 復元して再開
5.2.1.2. 不一致
5.2.1.2.1. 復元せずに対象ログセッションを無効にして、アラート表示、新規ログセッションとして開始？
5.3. 「終了」と「完了」の違い
5.3.1. 終了
5.3.2. 完了
5.3.3. いや、結局分からん。。
6. ※「受講ステータス」の説明
6.1. 赤っぽい要素は、「受講ステータス」ではなく、処理分岐のために内部的にどうみなすかというもの
6.2. LP等から見た時の「受講ステータス」は、"未受講（履歴がない）"、"受講中"（中断中を含む）、"受講済"（合格済や、受講可能回数制限に達してしまっている状態）
7. 受講開始・再開
7.1. ※受講可否判定
7.1.1. 不可
7.1.1.1. 受講不可メッセージで終了
7.1.2. 可
7.1.2.1. チャプター受講サマリー有無
7.1.2.1.1. なし：新規受講
7.1.2.1.2. あり：既存受講