学習システムの設計 — 動力学とパイプラインの分離

想起練習の理論を、実際に回るシステムへ落とすときの設計。核心は記憶動力学(L1)とパイプライン(L2)を分離し、L1 を自作しないこと。学習ツールの自作が失敗するのは、たいてい面白いほうの L1 に手を出して、価値のある L2 に到達しないため。

ただし本ノートは設計段階の記録であり、運用実績に裏打ちされていない。理論側が実証研究に支えられているのに対し、こちらは理論から演繹した構成にすぎない。閾値や規則の妥当性は、回してみるまで分からない。

2層に分ける

層中身自作すべきか
L1: 記憶動力学項目ごとの記憶状態、減衰、増分、次回間隔の決定しない
L2: パイプライン素材 → ノート → カード → 失敗の還流、フェーズ制御ここが本体

L1 は既存実装が圧倒的に強く、L2 は既存ツールが持っていない。分離の判断はこの非対称性だけで決まる。

なぜ L1 を作ってはいけないか

理論が関数形を与えていないから。 Bjork の2軸モデルは「貯蔵強度の増分は引き出し強度の減少関数」としか言わず、その関数の形を定めない。自作すると、理論が空けている穴を勘の定数で埋めることになる。

一方 FSRS(Anki 23.10 以降の標準スケジューラ)は、大量のレビューログでパラメータを実測して合わせている。しかもモデルの構造が2軸とほぼ対応する。

FSRS の DSR定義2軸モデルとの対応
R (Retrievability)今この瞬間に想起できる確率引き出し強度そのもの
S (Stability)R が 90% まで落ちるのに要する日数貯蔵強度の操作的定義
D (Difficulty)項目固有の覚えにくさ (1–10)理論に対応物なし。経験的に足された第3項

S の定義の仕方に注目したい。貯蔵強度は直接測れない構成概念だが、[retrieval-practice|規則3]を逆に使えば、減衰の遅さそのものを貯蔵強度の定義にできる。測れない量を、測れる帰結で置き換える ── 構成概念を工学量に変換する典型的な手口で、L1 が既に解かれている理由でもある。

したがって L1 に手を出すなら、それは FSRS の再実装という別プロジェクトになる。学習の道具作りとは切り離して扱う。混ぜると、学習が進まないまま実装だけが残る。

L2 の状態機械

stateDiagram-v2
    [*] --> 未処理
    未処理 --> カード化待ち: Pile A (略語・式・対概念)
    未処理 --> 理解中: Pile B (性質語)
    理解中 --> 理解中: 押さえどころが書けない
    理解中 --> カード化待ち: 押さえどころが書けた
    カード化待ち --> 運用中: 対比/シナリオに変換
    運用中 --> 運用中: 合格して間隔が伸びる
    運用中 --> 要還流: 連続失敗
    要還流 --> 理解中: ノートを厚くする
    運用中 --> 安定: 間隔が閾値超え
    安定 --> [*]

運用中 → 要還流 → 理解中 の戻り辺があるため、直線ではなくループになる。この辺のおかげで、カードの失敗が薄いノートを名指しで教えてくれる。戻り辺を欠くと、落ち続けるカードを永久に回すだけの装置になる。

遷移条件は観測可能な事実で書く

量観測可能か取得元
カードの成否・間隔・経過時間✅SRS のレビューログ
ノートの有無✅vault のファイル
押さえどころの有無・項目数✅ノートの走査
Pile A / B の別✅frontmatter に持たせる
理解したか❌測れない

観測不能なのは「理解したか」だけ。ここにプロキシとして「押さえどころが書けたか」を置き、人間のゲートを1つだけ通す。逆に言えば、それ以外の遷移は全部自動化できる。

システム設計としては、観測不能な量をゲート1つに押し込め、残りを機械に渡す形になっている。ゲートが増えるほど回らなくなるので、増やさないことが設計目標。

ルーティングとゲートの4規則

  1. Pile A は vault を通さない — 略語・式にノートを書く価値はない。直接カードへ
  2. Pile B は押さえどころが書けるまでカード化しない — 理解フェーズ未通過の項目をカードにすると、落ち続けて還流ループを無駄に回す
  3. 定義カードを作らない — 必ず対比かシナリオの形にする
  4. 連続失敗はカードではなくノートを疑う — 4 が無いと戻り辺が機能しない

フェーズ制御は状態機械の外に出す

「習得モード」と「本番前モード」はシステム全体にかかるので、個々の項目の状態とは別に持ち、状態機械と直交させる。

モード新規投入間隔目的
習得ありスケジューラ任せ貯蔵強度を積む
本番前停止強制的に短縮当日のアクセス確保

本番前モードは、わざとミスさせる設計をヒットさせ続ける設計に反転させる操作で、スケジューラの目的関数を意図的に裏切る。だから状態として持つと破綻し、モードとして外から被せる必要がある。学習効率は落ちるが、それを承知でやる期間だと自覚できていれば正しい判断になる。

cue の多重化

同じ事実でも、符号化したときの手がかりでしか引けない。コードや図で理解した項目は、その形式の入口しか持たない状態になりやすい。

対策は SRS の note/card 構造をそのまま使うこと ── 1 note = 事実、複数 card = 入口。理解の実体はどんな表現で持ってもよいが、本番で与えられる形式の入口を必ず1本張る。

転移の度合いは測れないので、ここは最適化せず両方張る保守運用で回避する。

モデル化できない残り

  1. cue の転移度 — ある形式で符号化した理解が、別の形式の手がかりでどれだけ引けるか。測定手段がない
  2. 言い換えの質 — 押さえどころが「書けている」かの判定。行数や語数では代理できない

どちらも人間のゲートに残る。自動化できない2点を先に特定しておくことが、この種のシステム設計では実装より先に来る。

押さえどころ

制限

関連

Graph