AIと連携した個人の学習層 (Learn)

前回の記事 Multi-Repo Agent Orchestrator で, 複数リポの Claude/Codex セッションを束ねる上位レイヤを紹介した. あの構成にはタグ付きの知識層 (自前 RAG) があり, あるリポの Agent が踏んだ gotcha を別リポの Agent が二度踏まない, という横断再利用が回っている.

Agentの自律運用がある程度回ってくる中で, Agentの成果に対する私の理解と承認が障壁として顕在化してきた. 特に Opus 4.8 までは,提案の内容を理解して,課題等の指摘が可能であったが, 昨日公開された Fable 5 を使っていると, 思考の展開が早い,抽象度が高い,コードと数理の間の横断が自動的に展開していき追いつけない場面が出てきた.

対話の中で確認することは可能だが,人間の理解がボトルネックとなり,また理解してもそれらは会話ログの中に死蔵されることになる. そこで,人間のための学習キューをセッションから分離することにした(Orchestrator の知識層は Agent のための corpus であって, 人間のための 学習キューではない).

本記事はその欠けた層 — 人間 (私) 自身の学習を, Agent 群と同じ枠組み (queue + 毎時巡回) で回す層 — の作成と運用を扱う.

まだ運用を始めたばかりなのであまり事例が積まれていないが,

• 全論文の参考文献(候補)とbibを管理する,papaer repo が次に読むべき論文をmd化→分割キュー化,スマホでちまちま読む,メモをする,質問をする,などを統合.

• 作業中に出てきた実装,数学,その他の知識に関して,教科書的に説明するmdを作成→分割キュー化

などを行っている. 特に1つ目に関しては,論文をスキマ時間に読む環境として,かなり良さそうに感じている.

要件

作る前に, 自分の学習がどこで破綻しているかを整理すると, 要件は次の 5 つになった.

1. queue できる: Agent が「これは学ぶ価値がある」と判断した知識 (承認制), または私が「これを学びたい」と指示した知識が, 1 箇所に積まれる.

2. スマホで少しずつ消化できる: 通勤や隙間時間に, 数分で読める単位 (Part) に割られていてほしい. 進捗が視覚化・管理可能なこと.

3. 集積される: 学習済みの知識が markdown として個人の知識管理 (PKM) 網に残り, リンク・検索・関連付けに乗り,資産として運用できること.

4. 質問できる: 読んでいて分からないところをその場で書いておけば, 短時間で Agent が答えてくれる.

手法比較 — なぜ Obsidian 正本か

当初考えていた候補は 以下の4 手法.

決め手は要件 3 (集積) である. 学習の成果物は「読了の記録」ではなく「自分の vault に増えた知識ノート」であってほしい. もともと個人の知識管理を Obsidian でやっているので, 学習 note の正本を Obsidian (iCloud 同期) に置けば, スマホ閲覧も集積も追加実装なしで手に入る.

Todoist は, 後ほど連携して通知と Done 入口だけの薄い一方向ミラーとして足す予定. 間隔反復 (Anki 的な復習サイクル) も 後の検討項目で, 正本が plain markdown なのでどの方向にも発展できる可能. この「アプリ化や高機能化を後回しにしても障害にならない」点が, 正本を plain markdown に置く最大の利点である.

全体像

仕組みは小さい. Python スクリプト数本 (stdlib のみ) + headless Claude + launchd の毎時巡回で構成される.

学習 note は次のような形をしている. 入力 markdown を ## 見出し単位で Part に割り, 長すぎる節 (1500 字超) は段落単位で再分割, 小さい節は併合する. 各 Part の末尾に読了 checkbox が付く.

---
title: <タイトル>
status: queued
source_repo: <どの repo 由来か>
recommended_by: agent | user
parts: 23
---
# <タイトル>

## Part 1/23 — <小見出し>
<本文>

- [ ] Part 1/23 読了

## Part 2/23 — ...

ユーザ (私) のやることは, スマホの Obsidian で Part を読んで checkbox を ✓ するだけ. 進捗は毎時の巡回が checkbox から数えて dashboard (一覧 note) に反映する.

設計の肝

機能としては「分割して積んで, 質問に答える」だけだが, 設計判断はいくつか紹介する価値があると思っている.

1 ファイル 1 書き手 — iCloud は無言で上書きする

最大の敵は iCloud 同期である. iCloud はオフライン編集が重なると, マージもエラーもせず片方を無言で上書きする (運が良ければ conflict copy が残る. 別リポでは conflict copy 58 件を踏んだ実績がある). スマホで checkbox を ✓ した直後に Agent が同じファイルを書くと, どちらかの編集が消える.

対策は同期アルゴリズムの工夫ではなく, ファイルごとに書き手を固定するという構造的なものにした.

当初は「queue note にはユーザしか書かない. Agent の回答は別ファイルに append して embed で読む」という完全分離だった. しかし使ってみると, 質問の回答は質問を書いたその場所の直下に出てほしい (スマホで embed の先まで飛ぶのは体験が悪い). そこで不変条件を一段緩和して, Agent の書込みを次の 4 条件つきで許した.

1. 挿入位置はユーザが書いたマーカーブロックの直下のみ. 既存行の変更・削除は絶対にしない (append-only な挿入).
2. 冪等: ブロック内容の hash に対するマーカーをコメントで残し, 二重挿入を防ぐ. ユーザが質問文を書き換えると hash が変わり, 新しい質問として再回答される.
3. 挿入前に note 全文を repo 側へ snapshot する (iCloud に上書きされた場合の復元用の安全網).
4. 書込みは巡回時の数秒のみ (ユーザのオフライン編集と時間が重なる確率を最小化する).

「同期の衝突はアルゴリズムでなく所有権で避ける」「緩和するときは無条件でなく, 復元手段と確率の低減をセットにする」というのが, この層に限らず iCloud + Agent 構成全般で使っている指針である.

ユーザの操作は行頭マーカー 3 種だけ

note への能動的な操作は, 任意の場所に行頭マーカーで書く 3 種類に統一した. スマホのキーボードで打てる記法であることが重要である.

• ##Q <質問> — 質問. 次の巡回 (≤1h) で直下に回答 callout が入る.
• ##A <自分の解答> — 確認問題への解答. 直下に添削 callout (正誤 + 指導) が入る.
• ##M <メモ> — 学習メモ. Agent は回答せず, dashboard のメモ欄に集約だけされる (note を汚さず, 後から知識化する時の材料になる).

実際の画面はこうなる. 読んでいる論文 note の途中に ##Q で質問を書いておくと, 次の巡回で直下に回答が挿入される.

回答の生成は headless の claude -p で行う. 巡回スクリプトが未回答の ##Q / 未添削の ##A を検出して JSON に吐き, 回答 Agent が note 全文 + 質問 (解答添削の場合は直前の確認問題も) を文脈にして回答を生成し, 専用 CLI がブロック直下へ挿入する. リアルタイムの対話なしで「Agent に質問できる」を成立させるのがポイントで, スマホで読んでいる最中に PC の前にいる必要はない.

地味な gotcha として, マーカーブロックの終端は「空行まで」にしてある. note の任意箇所に書かれるため, 空行を越えて続きを読むと元の本文と機械的に区別できなくなるからである. この種の「どこまでがユーザの書いた質問か」問題は, 自由編集される markdown に機械処理を混ぜる時に必ず出てくる.

進捗は導出状態 — note に書き戻さない

M/N の進捗や queued / learning / done の状態を note の frontmatter に書き戻す設計も考えられるが, やめた. 巡回は checkbox を数えるだけで, 導出した状態を dashboard にのみ表示する. 状態の二重管理 (checkbox と frontmatter が食い違う) を避けるためと, ユーザ正本への書込み経路を増やさないためである. 状態を 1 箇所 (checkbox) に置いて他は導出にする, というのは Orchestrator のタスク層でフィールド単位に真の側を分けたのと同じ思想である.

launchd と iCloud TCC — /bin/bash では書けない

毎時巡回は launchd で回している. ここに macOS 固有の罠があって, launchd から /bin/bash 直起動したスクリプトは, TCC (プライバシー保護) により iCloud 配下 (Mobile Documents) への書込みが拒否される. 対策は, 独立にコンパイルした小さな helper binary を responsible process として立てる方式で, これは以前 backup 機構を作った時に確立した手法の再利用である. ついでに深夜 (0-7 時) は巡回を skip する quiet hours も入れてある (深夜に回答が届いても読まないし, 万一の暴走時の被害も減る).

他リポの Agent からの登録経路 — 承認制

この層の入口は「Agent が学習を薦める」である. 十数リポで走っている各 Agent が, セッション中に「これはユーザが学ぶ価値がある」と判断した知識を送ってくる — のだが, ここを自由化すると queue がすぐ Agent の善意で溢れる. そこで承認制にした.

1. 各リポの Agent は, 学習推奨を Orchestrator 経由のユーザ依頼 (📖 prefix 付き) として送る. queue への直接書込みはさせない.
2. 推奨は briefing (毎時の横断レポート) に surface され, 対話セッションが選択肢として提示する.
3. 承認されたものだけが enqueue CLI で queue に入る. 却下は却下として記録される.
4. 例外は 1 つ: ユーザがセッション中に「これを learn に入れて」と明示指示した場合のみ, その場で直接 enqueue してよい.

面白いのは, このために新しい仕組みをほぼ作っていないことである. Orchestrator には元々「Agent からユーザへの判断依頼」を briefing に集約する承認フローがあり, 学習推奨はそれに 📖 prefix を付けて相乗りしただけ. 横断的なタスクは Orchestrator だけが扱い, 各リポの Agent は自リポのことだけを surface するという既存の役割分担とも整合する. レイヤを増やす時は, 専用機構より既存フローへの相乗りを先に検討する方がよい.

実例: 圏論入門 note — 研究知識の段階配信

この機構が一番活きたユースケースを紹介する. ライブラリの開発で, 並列実行の正しさを圏論で整理して定理証明→実装を進めていた際にその実装内容を, 私が確認する作業を一旦スキップして,証明自体は型推論とコンパイラに任せて取り敢えずgoを出した.そこで研究リポの Agent に, できるだけ分解して理解への負担を最小限にした解説 note を書かせ, learn に投入した.

結果は 23 Parts, 確認問題 6 問の note になった. 書かせる時の規約が効いていて:

• 証明は省略しない. 等式変形は 1 行 1 根拠で, どの定義・どの補題を使ったか明記する.
• 各節末に確認問題を置き, 解答は折りたたみ (callout) で同じ場所に入れる.

↑この初歩的なところから,自分の研究まで分割して接続しているので,そのまま他人への説明になりうる(まだ全部読めていないけれど).

これをスマホで Part ごとに消化していく. モノイドの定義から始まって 1 Part 数分, 確認問題には ##A で自分の解答を書くと巡回が添削を返してくる. 「研究に必要な長い数学知識を, 確認問題つきで自分に段階配信する」という体験は, 講義を受けるのとも教科書を読むのとも違っていて, 自分の研究の文脈だけに最適化された教材が, 自分の隙間時間の粒度かつ初学者レベルまで分解して届くために,認知不可が極限まで低下している感覚がある.

副産物として, 読了後の note はそのまま vault に残る. 論文の改稿で同じ数学に触れる時, Agent も私もこの note を参照できる. 学習の成果物が「読了の記録」でなく「知識ノート」になる, という要件 3 はここで効いている.

段階導入と今後

現在 Phase 1 (queue + M/N + 非同期 Q&A, Obsidian plugin ゼロ) が稼働中で, 以後は運用データを見ながら段階導入する.

1. Phase 1 — Obsidian コア (稼働中): 本記事の内容.
2. Phase 2 — Todoist 一方向ミラー: enqueue 時に「📖 タイトル (0/N)」をタスク起票し, 巡回が進捗を reconcile する. 通知と Done 入口だけの薄い層で, 正本は常に vault.
3. Phase 3 — TTS / 間隔反復: 読み上げと復習サイクル (FSRS 系) の検討.
4. Phase 4 — アプリ化判断: 消化率や Q&A 頻度のデータを見て決める.

最初から専用アプリを作らなかったのは意図的で, 「そもそも自分は queue された知識を消化するのか」という一番の不確実性を, 一番安い構成 (plain markdown + 既存の Obsidian) で検証したかったからである. そして正本が plain markdown である限り, どの Phase に進んでもデータの移行が問題にならない — これは Orchestrator の vault を全 markdown にしたのと同じ賭けであり, 今のところ良い賭けだったと思っている.

AI に何かを教わること自体は, もう誰でもやっているが 流れて消えるその知識を, 自分の知識基盤に向けて queue し直す層を一枚挟む — Agent 群の orchestration の隣に, 人間の learning を置いてみた, という話でした. 学生にAIの使い方,AIに教わる的な使い方を指導している資料などが多いが,個人的にも一番しっくり来ている. そのうち,学生向けの資料としてまとめるためのたたき台にしようかと思っている.