AIの理解状態を4軸×3段階で引き継ぐ学習ツールを設計した
今回やったこと / この記事について
AIとの学習内容を次のセッションへ引き継ぐため、理解状態を保存するConcept Continuityの設計v2をまとめた。対象は、会話の履歴を読み直すだけでは学習の続きが作れない個人開発者や、復習の状態を記録したい人である。焦点はチャットUIを増やすことではなく、理解のどこが残っていて、どこが弱いかを次回に渡すことだ。
学習セッションは既存の開発環境で行い、/learn-saveで理解内容を抽出する。ツール内に新しいチャット画面は作らない。保存と再開の境界を薄くすることを優先した。
理解を1つの点数にしなかった理由
理解度を一つのスコアにすると、用語を思い出せることと、別の場面で使えることが同じ数字に混ざる。そこで、Recall、Meaning、Transfer、Reasoningの4軸に分け、それぞれをunknown、shaky、solidの3段階で表す。4軸×3段階の組み合わせなら、単に「分かった」と記録するより、次に何を復習するかを決めやすい。
| 軸 | 見るもの | 状態の例 |
|---|---|---|
| Recall | 用語や手順を思い出せるか | unknown / shaky / solid |
| Meaning | 説明の意味を理解しているか | unknown / shaky / solid |
| Transfer | 別の例へ適用できるか | unknown / shaky / solid |
| Reasoning | 根拠を組み立てられるか | unknown / shaky / solid |
正解してもすぐsolidへ上げず、shaky止まりにする方針も採用した。一度うまく答えただけでは、再現性があるとは限らないからだ。逆に誤答した場合は間隔をリセットし、再学習を提案する。スコアを上げるゲームではなく、理解の不確実さを残す記録として扱う。
Phase 1の構成を小さくした
Phase 1は依存ゼロのhttp.serverとsqlite3で動く単一Pythonサーバーにした。外部サービスを先に増やすと、学習状態の設計より環境構築の問題が前面に出るためだ。停止中はdata/inbox/へ記録を書き、起動時に取り込む。常時起動を前提にしないことで、記録したい瞬間にサーバーが動いていない問題を吸収する。
学習セッション
↓ /learn-save
理解状態を4軸へ分解
↓
data/inbox/へ一時保存
↓ サーバー起動時
sqlite3へ取り込み
↓
次回の復習候補を生成
この構成で重要なのは、データベースを使ったこと自体ではない。入力経路を「サーバーが動いている時だけ」に限定しなかったことだ。記録を先に失わず、あとで取り込めるようにすると、復習の流れが環境状態に引きずられにくい。
初期データはベクトル検索、RAG、学習者モデルの3概念、計9問から始めた。少ない題材で4軸の記録が実際に使えるかを確認してから、概念数を増やす順序にしている。
Phase 2で増やすものと、まだ増やさないもの
Phase 2では自由記述のAI採点、/learn-resume、問題補充、誤解の解消記録を追加する予定だ。12概念を2週間セルフテストする検証計画も置いた。ただし、音声入力は最初から中心にせず、テキスト採点の後にアダプタとして足す位置づけにした。
先に入力方法を増やすと、理解状態の更新ロジックと入力UIの問題が混ざる。まずテキストで、正解・誤答・間隔リセット・shaky据え置きが期待どおり動くかを確認する。そのうえで音声を同じ更新処理へ渡せるなら、入力アダプタとして追加できる。
やってみてわかったこと
学習の引き継ぎで必要なのは、前回の会話を長く保存することだけではない。次に何を確認すべきかが、状態として読み取れる必要がある。4軸に分けることで「思い出せるが応用できない」「説明はできるが根拠を組み立てられない」といった差を残せる。
また、低摩擦を優先する設計では、入力しないことを失敗扱いにしないほうが続きやすい。停止中はinboxに書き、復習はタイピング不要の自己判定を中心にする。完全な学習管理システムを作る前に、状態の定義と再開経路を固定することが最初の実装になる。
更新履歴
- 2026-09-24: 初稿。Concept Continuity設計v2とPhase 1の構成を整理。
訂正履歴
- なし。