関係マップ：ノートブックの実態調査・データセット

この地図は「論文同士がどう繋がるか」を散文で語るもの。各論文の事実は、対応するノートの # AI解説（論文本文／アブスト等を情報源に書いたもの）に基づく。まだノートを作っていない論文は、リンクにせず cite key を添えた素のテキストで書く（リンクは作成後に張る）。索引（何があるか）は トップページ を参照。

この地図は deep-research（複数ソースの横断検索＋主張の敵対的検証） をきっかけに作った。狙いは1つ：「公開ノートブックデータセットには何があり、計算資源・システム視点（セルの実行時間・メモリ・CPU/GPU）のデータはあるのか」 を見取り図にすること。結論から言うと、静的（コード・テキスト）データセットは非常に豊富だが、ランタイムの資源プロファイルを公開したデータセットは事実上存在しない。

問いと結論（一言で）

ノートブックを「マイニング」する研究は2018年以降たくさんある。だが何を記録しているかで並べ替えると、関心はくっきり左に偏っている——つまり保存済みファイルの中身（コード・Markdown・出力）を静的に見る研究がほとんどで、実際に実行して資源を測る研究はごく少数、しかもその資源データは公開データセットになっていない。

補足図（AI生成）：公開データセットを「記録している情報」で左→右に並べたもの。灰＝静的コンテンツ（大多数）、淡い金＝実行の成否・来歴・イベント（少数）、オレンジ枠＝セル別の資源プロファイル＝公開データが空白。色は「記録の種類」に対応させ、オレンジだけを強調＝狙い目として立てている。

1. 静的コンテンツ ― データセットの大多数はここ（スペクトラム左）

公開されている大規模コーパスは、ほぼ全部が .ipynb の中身（コードセル・Markdown・保存された出力・構造メタデータ）を静的に集めたもの。実行はしないし、資源も測らない。

• Rule 2018（rule2018exploration, CHI ‘18）— UCSD が公開した ~1.25M ノートブックのコーパス。2017年7月時点の公開 GitHub ノートのほぼ全量＋約6,000ノートの精選サンプル。中身はコード・テキスト・出力。「約4分の1のノートに説明文が無い」という静的な内容分析。これがこの分野の出発点的データセット。
• Källén 2021（kallen2021clones, Programming journal）— 2.7M ノートブック／3,700万スニペット。関心はコードクローンで、「70%超のスニペットが完全重複」という静的解析。規模は最大級。
• pimentel2019largescale（MSR ‘19, ~1.15M）と quaranta2021kgtorrent（KGTorrent）（MSR ‘21, Kaggle 由来＋メタデータ）はこのリポジトリに既にノートがある定番コーパス。
• mostafavi2024distilkaggle（DistilKaggle）・drozdova2023code4ml（Code4ML）・biswas2019boa（Boa for Python） も、Kaggle/ML コードを注釈付きで静的に配るデータセット。
• コード生成（LLM）向けのデータセットも構造は同じ：JuICe（agashe2019juice, EMNLP ‘19, 1.5M 例）と DSP / JuPyT5（chandel2022jupyt5, Microsoft ‘22）は、コード＋自然言語（＋assert テスト）を集めたもので、ランタイムの資源信号は一切持たない。

→ この群を貫くのは「ノートブックは保存ファイルである」という前提。だから記録されるのは書かれたもの（コード・文章・最後に保存された出力）であって、走らせたときに起きたことではない。

2. それを使った分析 ― 関心は「コードの質と中身」（やはり静的）

上のコーパスを使った研究の主要カテゴリも、ほぼ静的解析に収まる。SLR がこの全体像を裏づける。

• siddik2025review（SLR）（arXiv ‘25, 一次研究199本）は、公開データセット22件を表に列挙しているが、それらはすべて GitHub/Kaggle 由来の静的コーパス（メタデータ・コード品質・クローン・コミット履歴等の注釈付き）で、資源プロファイル/性能トレースのデータセットは1件も無い。これは「静的偏重」の最も強い裏づけ（※ これは SLR の表の中身から読み取れる事実であって、SLR 自身が『静的に偏っている』と主張しているわけではない）。
• 分析の中身も静的が中心：コード品質/スタイル（siddik2023codequality, SCAM ‘23 — ML ノートは非ML より PEP-8 品質が低い）、バグ分類（desantana2022bug, arXiv ‘22）、ライブラリ/API 利用や比較（psallidas2022datascience、grotov2022comparison）。
• これは、あなたが「よく使われるライブラリなどの分析はいくつもある」と認識しているのと一致する。コード分析系は厚い。

3. 実行を「する」研究 ― でも記録するのは成否・出力・来歴であって、資源ではない（スペクトラム中央）

ここからが境界線。実際にノートを走らせる研究はある。ただし測って残すのは「資源」ではなく「結果」——成否、出力、依存関係、操作ログだ。

• 再現性：pimentel2019largescale と Samuel 2024（samuel2024reproducibility, GigaScience ‘24, 生物医学論文由来の27,271ノート）は、ノートを再実行して「エラー無く走るか」「出力が一致するか」を測る。記録されるのはpass/fail・例外・出力一致であって、実行時間でもメモリでもない。Samuel の結論は「インストール可能だった10,388件中、エラー無く走ったのは1,203件、結果まで再現したのは879件」——再現性は低い、という成否ベースの話。
• 実行可能性：Nguyen 2025（nguyen2025nonexecutable, MSR ‘25, 42,546ノート）も実行はするが、目的は「pathological に実行不能か」の分類。やはり資源メトリクスは取らない。
• 来歴/安全性：nbsafety（macke2021nbsafety, VLDB ‘21）はランタイムのトレースでセル間の依存・staleness を追う。これは実行時情報だが、データ来歴であって資源使用量ではない。
• 操作ログ（最も資源に近い）：JuNE（titov2025june, JetBrains ‘25）は 20名・100時間超の実行イベントログ。各行に time（壁時計タイムスタンプ）・event（execute / finished_execute / error …）・cell_source / cell_output を持つ。execute→finished の時刻差から「セルの粗い壁時計時間」は導けるが、実行時間・メモリ・CPU/GPU の専用カラムは無い。これが現状「ランタイムに最も近い公開データ」。なお JuNE は Themisto が4ノートを再実行して開発トラジェクトリを作るための土台でもある（同じ JetBrains 系）。

→ この中央帯が重要：「実行データ」と呼べそうなものはここにしかないが、それでも資源プロファイル（時間・メモリ・CPU/GPU を体系的に揃えたもの）ではない。

4. ランタイム資源を「測る」研究はある ― だが公開データセットにはなっていない（スペクトラム右＝空白）

「資源を測る」研究はツールとしては存在する。このリポジトリの 性能分析マップ がその群だ。ところが、測った資源データを公開データセットとして配ったものが無い。

• werner2021bridging と werner2024jumper（JUmPER） は、セルごとに実行時間・メモリ・CPU/GPU/IO を計測する Jupyter 統合プロファイラ。つまり資源は測れる。だが配るのはツールであって、計測したデータセットではない。
• li2023elasticnotebook（ElasticNotebook） は、複製プラン最適化のためにセルの実行時間と変数サイズを内部計測する。だがそれは最適化に使うだけで、トレースを公開していない。
• prathanrat2018performance は CPU/RAM プロファイルや同時ユーザ数から応答時間を予測するが、これも運用予測であってデータ公開ではない。
• 「ランタイム文脈が未開拓」という主張は grotov2025themisto も（LLM 入力の文脈として）述べており、Themisto のベンチも実行時間・メモリ・出力を含むトラジェクトリを扱う——が、これもベンチマークであって、汎用の資源プロファイルデータセットではない。

→ つまり右端（セル別の資源プロファイルを集めた公開データセット）は、計測技術は揃っているのに、誰もデータとして出していない空白。

まとめ ― あなたの仮説は正しい。ただし一段シャープにできる

あなたの認識「ライブラリ等のデータ分析は多いが、メモリ使用量・セル実行時間といったシステム視点の研究は無い」は、データセットの軸で見ると正しい。ただし正確には次の3点に分かれる：

1. 静的コード分析のデータセットは過剰なほど豊富（§1–2、SLR の22データセットは全部これ）。
2. 実行系のデータは少数あるが、記録は成否・出力・来歴・操作イベントであって、資源プロファイルではない（§3。最も近いのは JuNE の壁時計時刻）。
3. 資源を測るツールは存在するが（JUmPER 等）、測った資源データを公開データセットとして配った例は無い（§4）。

だから「研究が無い」のではなく、正確には 「公開データセットが無い」。計測技術（JUmPER・ElasticNotebook の内部計測）と分析需要（性能予測・LLM へのランタイム文脈）は既にあるのに、その間をつなぐ『セル別の実行時間・メモリ・CPU/GPU を揃えた公開コーパス』だけが欠けている——これが、あなたが作ろうとしているデータセットの位置づけになる。ElasticHub の「資源を測ってスケーリング判断に使う」動機とも、この空白は地続きである。

検証メモ：この地図のもとになった deep-research は20本の一次ソースから90主張を抽出し、うち25主張を3票の敵対的検証にかけ（25/25 確認・棄却0）て作った。各データセットの「静的か／資源を記録するか」の判定は、各ソースのアブスト・データセットページを実際に読んで確認している。新規追加分（rule2018exploration・kallen2021clones・agashe2019juice・chandel2022jupyt5・titov2025june・samuel2024reproducibility・siddik2023codequality・desantana2022bug・nguyen2025nonexecutable・macke2021nbsafety）はその後、各論文の本文（または HuggingFace データセットカード）を一次情報として精読してノート化済みで、本文中のリンクはそのノートを指す。

この分野の論文一覧（索引）

静的コーパス：rule2018exploration（UCSD ~1.25M）・kallen2021clones（2.7M, clones）・pimentel2019largescale・quaranta2021kgtorrent・mostafavi2024distilkaggle・drozdova2023code4ml・biswas2019boa

コード生成データセット：agashe2019juice（JuICe）・chandel2022jupyt5（DSP / JuPyT5）

コード分析・品質・バグ・サーベイ：siddik2025review（SLR）・siddik2023codequality（SCAM ‘23）・desantana2022bug・psallidas2022datascience・grotov2022comparison

実行の成否・来歴・操作イベント：samuel2024reproducibility（再現性）・nguyen2025nonexecutable（実行可能性）・macke2021nbsafety（来歴/staleness）・titov2025june（JuNE 実行イベントログ）

資源を測るツール（データ非公開）：werner2021bridging・werner2024jumper・prathanrat2018performance・grotov2025themisto・li2023elasticnotebook（→ 詳細は 性能分析マップ）