関係マップ：状態管理・チェックポイント・移行
この地図は「論文同士がどう繋がるか」を散文で語るもの。各論文の事実は、対応するノートの
# AI解説（いずれも論文本文を情報源に書いたもの）に基づく。実装詳細が本文未取得のものはその旨を明記する。索引（何があるか）は トップページ を参照。
この分野の論文は「ノートブックやセッションの実行状態を、いかに保存・移行・復元するか」という共通の問題を、粒度（何を単位に保存するか）と狙い（最小化／完全化／配置最適化／GPU効率／UX）で異なる立ち位置から攻めている。全体像は下図の通り。
補足図（AI生成）：縦軸が「保存・移行する単位の粒度」（上ほど粗い）、色がアプローチの系統。青い縦矢印が後述の Park 研の系譜。
1. 中心にある系譜：ElasticNotebook → Kishu → Chipmink
この分野の背骨は、同一グループ（Park 研）による3本の系譜である。粒度を段階的に精密化しながら、「状態を全部保存するのではなく、必要な分だけ安く保存する」という思想を一貫して発展させている。
- ElasticNotebook（VLDB 2024）が起点。Application History Graph (AHG) でセル間の依存を追跡し、「保存するか・再計算するか」を最小 s-t カット（最大フロー）で最適化する。シリアライズ不能なオブジェクトは自動的に再計算側へ回す。問題は「セッション状態を別マシンへ安く移行する手段がない」こと。
- Kishu（VLDB 2025）は AHG をそのまま前提に、粒度を変数から Co-variable（参照を共有しあう変数の束）へ引き上げ、Git のような Checkpoint Graph で差分インクリメンタルなチェックポイント／チェックアウトを実現する。問題は「過去状態へ戻る（タイムトラベル）手段がない」こと。ノート上でも ElasticNotebook を先行・ベースラインとして位置づけている。
- Chipmink（VLDB 2026）は同じ「差分同定」を pod（構造を意識した部分グラフ） という粒度に一般化し、巨大で散在するオブジェクトグラフ一般へスコープを広げる。Kishu の Co-variable と Chipmink の pod は、「どこが変わった（dirty）かを安く検出する」同じ問いへの2通りの粒度設計と読める。
→ 一言でいえば 「粒度の精密化（変数 → Co-variable → pod）」 の系譜。なお ElasticNotebook にはデモ論文（SIGMOD 2024 Companion）もあり、マシン間移行・終了後再開の2シーンを実演している（手法の中身は本体論文と同じ）。
2. 粒度スペクトラム
中心系譜以外も含めて、「何を単位に保存・移行するか」で一直線に並べられる（上図の縦軸）。粗い側はOSに任せて頑健・汎用だが無駄が多く、細かい側はノートブック意味論を使って無駄を削れるが実装が複雑になる、というトレードオフがある。
| 粒度（粗→細） | 論文 | 単位 |
|---|---|---|
| プロセス全体 | VAS-CRIU / Elsa | OSプロセス・コンテナ |
| セッション全体＋参照ファイル | Absolute State | 名前空間＋外部ファイル依存 |
| セルブロック | CEMT | セルの塊＋その依存変数 |
| カーネル＋GPU大物分離 | NotebookOS | カーネルレプリカ（CPU状態）＋分散ストア上の大オブジェクト |
| 変数オブジェクト | ElasticNotebook | セル依存グラフ上の変数 |
| Co-variable | Kishu | 参照を共有する変数の束 |
| pod（部分グラフ） | Chipmink | オブジェクトグラフの部分 |
3. 対立軸：状態の「最小化」 vs 「完全化」
同じ「セルをローカル/リモートに分けて動かす（ハイブリッド実行）」という動機を共有しながら、状態の扱いが正反対の2本がある。
- CEMT は 最小化：AST 依存解析で移行に必要な変数だけに削り、性能（どこで実行すれば速いか）を最適化する。
- Absolute State は 完全化：コード・環境・参照データ・依存・変数状態をまるごと捕捉し、別環境での再現性を狙う。
straceでopenatを拾い、ファイル依存を言語非依存に集める点が独自。
→ 「いかに少なく済ませるか（移行・性能）」と「いかに全部とるか（再現性）」という、目的の違いがそのまま設計の違いになっている。中心系譜（ElasticNotebook/Kishu/Chipmink）はこの軸では最小化側に立つ。
4. OSレベル C/R（CRIU 系）— 層が一段違う
上の研究群がノートブック意味論（変数・セル）を使うのに対し、こちらはOSのプロセス／コンテナを丸ごと扱う層。中心系譜のノートでは「OSレベルのチェックポイント（CRIU）は環境差に弱く粒度が粗い」と批判対象・対照として言及される一方、独立した系統として成立している。
- VAS-CRIU（MEMSYS 2019）は CRIU そのものの内部高速化。遅さの主因であるメモリページのファイル I/O を、MVAS（複数の独立仮想アドレス空間）でメタデータだけ COW 複製することで回避する。永続化不要な「同一マシン内クローン・スケーリング・デバッグ」向け。
- Elsa（ADASS 2021）は CRIU を JupyterHub に組み込んだ実装。Spawner の start/stop API をハイジャックし、停止時に CRIU でチェックポイント、起動時に復元する。共有 NFS で
/homeの inode を揃え、移行先でも同一参照を保証する。アイドルセッションを退避してコストを下げるのが狙い。
→ VAS-CRIU（底層の高速化）と Elsa（上層の Jupyter 統合）は補完関係で、組み合わせ可能と読める。
5. GPU 効率という別軸：NotebookOS
NotebookOS（ASPLOS 2026）は「状態保存」そのものより、対話的深層学習訓練で 80% 以上アイドルになる GPU をいかに手放すかという資源管理が主眼。1論理カーネルを3レプリカに分散配置し、Raft で小さな CPU 状態を同期、セル実行ごとに空き GPU を持つレプリカを動的選挙で executor に選ぶ。GPU 上の大オブジェクトは分散ストアへ退避してポインタで扱う。状態保存系とは層が異なる別軸だが、「ノートブックの可搬性」という上位テーマで ElasticNotebook と接続する。
6. UI/UX 側からのタイムトラベル：Fork It・Multiverse
過去状態へ戻って別の道を試す、という動機を Kishu と共有するが、こちらは HCI / 言語処理系側からのアプローチ。
- Fork It（CHI 2021）は forking（新セッション生成）と backtracking（過去状態へのナビゲーション）の2操作で並行状態を露出させ、代替案探索を支援する。設計はデータサイエンティストへのヒアリング駆動。
- Multiverse Notebook（OOPSLA 2024）は状態隔離のもとで過去から分岐再開する。
→ いずれも実装機構の詳細は本文未取得（アブスト範囲）で、中心系譜との定量比較もないため、系譜上の位置づけは現状あいまい。「効率最適化（Kishu 系）」に対し「UX としてどう見せるか（こちら）」という対の関係として置いている。
この分野の論文一覧（索引）
ノートブックレベル：ElasticNotebook・Kishu・Chipmink・Multiverse・Fork It・NotebookOS
システムレベル：VAS-CRIU・Elsa・CEMT・Absolute State