全体地図（overview）

論文同士がどう繋がるかを散文で語る地図。各分野の詳細マップへの入口と、分野をまたぐ橋だけをここに置く。「何があるか」の索引は トップページ を参照。

役割分担：トップページ index.md ＝ 何があるか（分類された一覧）／この overview/* ＝ なぜ繋がるか（系譜・対立・補完を散文と図で）。各分野マップは完成したものから順に公開し、未着手分はあとから足す。

分野別マップ

• ✅ 状態管理・チェックポイント・移行 — 粒度（変数〜プロセス）と狙い（最小化／完全化／配置／GPU／UX）でアプローチを整理。中心系譜は ElasticNotebook → Kishu → Chipmink。
• ✅ ノートブックの実態調査・データセット — 公開データセットを「何を記録しているか」で静的→実行成否→ランタイム資源のスペクトラムに並べ、セル別の実行時間・メモリ・CPU/GPU を集めた公開データセットが空白であることを示す。
  • うち 性能分析（SLR §5.2.4） ✅ — 「性能」という共通語の関心を ①計測して見せる／②測って運用判断／③LLMに与える の3方向で整理。
• ⬜ インフラ・HPC・クラウド運用 —（作成予定）

分野をまたぐ橋

ここは分野別マップが揃うにつれて充実させる。現時点で、各ノートの本文から確認できる分野横断のつながりだけを記す。

• チェックポイント／移行 ⇄ HPC・クラウド運用：Elsa は「アイドルセッションを退避して運用コストを下げる」という、HPC・クラウド運用側の動機（コスト・稼働率）とチェックポイント技術（CRIU）が交わる地点。Absolute State も Airavata / Cybershuttle 系のゲートウェイ上でのノートブック実行という上位文脈を共有する。
• 性能分析 ⇄ HPC・クラウド運用：faenza2024containerized の「コンテナ化(K8s)が性能をどれだけ食うか」という実測は、ElasticHub など JupyterHub の Kubernetes 運用が暗黙に前提する「コンテナ化のコストは許容範囲」という仮定の裏づけにあたる。性能分析マップ を参照。
• 実態調査・データセット ⇄ 性能分析 ⇄ HPC・クラウド運用：データセットマップ が示す空白（セル別の実行時間・メモリ・CPU/GPU を集めた公開データセットが無い）は、性能分析 側の「資源を測るツールはある（JUmPER・ElasticNotebook の内部計測）」と、運用側の「ElasticHub は資源を測ってスケーリング判断に使いたい」という需要のちょうど中間にある。計測技術と需要は揃っているのにデータが欠けている、という橋。
• （ほかの橋は各分野マップ作成時に追記）