AI解説

出版社版: https://doi.org/10.1109/MSR52588.2021.00072（arXiv 全文: https://arxiv.org/abs/2103.10558 / 実装: https://github.com/collab-uniba/KGTorrent） 情報源: arXiv 全文（PDF）を精読して検証済み。248,761 本の Python ノートブックを取得、Meta Kaggle のスキーマを逆解析して関係 DB を構築・連結、HTTP/Kaggle API での取得と更新手順、を確認。

一言で

Kaggle 上の Python Jupyter ノートブック 248,761 本を、Meta Kaggle 由来のメタデータ（MySQL データベース）と紐付けて配布する大規模データセット KGTorrent。ノートブックの中身（コード・出力）と、それに関する豊富な文脈（作者・コンペ・評価・投票など）を結合して分析できるのが眼目。2015 年 11 月〜2020 年 10 月、約 175 GB。

背景・問題

Kaggle はデータサイエンス学習・実践の巨大な場で、そこにある膨大なノートブックはDS の実コードの宝庫だ。だが研究で使うには困りごとがある。

• ノートブック本体だけでは文脈が足りない：誰が・どのコンペで・どんな評価のノートブックかが分からないと、品質や傾向の分析が浅くなる。
• 収集が面倒で再現しにくい：各自が Kaggle からスクレイプすると、取得方法・時点がバラバラで、研究間で比較可能な共有コーパスにならない。

問題は「Kaggle ノートブックの本体とメタデータを、整合的に結合した再利用可能なデータセットがない」こと。KGTorrent はこれを埋める。

提案手法（データセット構築＝やったこと）

1. ノートブック本体の収集：248,761 本の Python ノートブックを取得。取得経路は 2 通りで性質が違う——HTTP 経由だと出力付きの完全なノートブックが得られ、Kaggle API 経由だと出力なし。両者を使い分け／補完する。ファイルは UserName_CurrentUrlSlug の規則で命名。
2. メタデータの整備：Kaggle 公式の Meta Kaggle（29 個の CSV テーブル）を取り込み、MySQL データベースとして再構成。外部キー（FK）の不整合をクリーニングして、テーブル間を正しく結合できるようにする。
3. 本体とメタデータの連結：各ノートブック ファイルを、データベース上の対応レコード（作者・カーネル・コンペ・評価等）に紐付ける。

直感：価値の源は「コード × 文脈の結合」。ノートブック単体ではなく、「高評価のノートブックは何が違うか」「特定コンペで流行った手法は何か」といった問いに答えられるよう、関係データベースとして整合させるのが課題の核。

数式・アルゴリズム

データセット論文なので定式化はなく、規模・スキーマ・収集方法が要点。

• ノートブック数：248,761（Python）
• 期間：2015-11 〜 2020-10
• サイズ：約 175 GB
• メタデータ：Meta Kaggle 由来の 29 CSV → MySQL（FK 整合済み）
• 取得経路：HTTP（出力あり・完全）／ API（出力なし）

想定用途と評価

• 品質・傾向分析：評価や投票と結合して「良いノートブックの特徴」を調べる。
• コード解析の素材：大規模な Python DS コードのコーパスとして、スタイル・API 利用・再現性などの研究に使える。
• 再現性：取得スクリプトを公開し、他者が同じ手順でコーパスを再構築できるようにしている（研究間の比較可能性を担保）。

Kaggle を出所とする妥当性について

本論文は 4 ページのデータショーケース論文であり、Threats to Validity セクションが存在しない。 Kaggle を選んだ根拠として論文が挙げているのは次の 3 点にとどまる。

1. 規模と多様性：Kaggle は Novice から Grandmaster まで幅広いスキルレベルのユーザを抱えるプラットフォームであり、248,761 本の Python ノートブックが得られる。
2. メタデータの豊富さ：Meta Kaggle 由来の構造化メタデータ（作者、コンペ、スコア、投票、Performance Tier）が GitHub には無い強み。
3. 未開拓の出所：先行のノートブック研究（Rule+ 2018, Pimentel+ 2019）はいずれも GitHub 由来であり、Kaggle を分析した研究はまだ無い。

一方、Kaggle のノートブックがデータサイエンス全般を代表するかについては議論していない。 コンペ中心の文化が内容に及ぼすバイアス、公開ノートブックのみという選択バイアス、Kaggle の管理された実行環境が構造に与える影響、GitHub や企業内との差異は、いずれも扱われていない。

関連研究との関係（メモ）

• DistilKaggle（mostafavi2024distilkaggle）：同じく Kaggle ノートブックだが、DistilKaggle はセル単位に”蒸留”した軽量テーブル＋コード品質指標＋Performance Tierに振っており、KGTorrent の生ノートブック＋関係メタデータとは設計思想が違う（生データの網羅 vs 解析しやすい蒸留）。
• Code4ML（drozdova2023code4ml）：Kaggle 由来のコード スニペットに意味アノテーションを付けたデータセット。KGTorrent が”文脈つき生ノートブック”なのに対し、Code4ML は”注釈つきスニペット”。
• Boa dataset（biswas2019boa）：出所が GitHub OSS（AST 化）で、Kaggle ノートブックとは母集団が異なる。
• pimentel / psallidas：このようなコーパスを使う／作る大規模実証研究の系譜。

Q&A

Q1. 論文内で Kaggle をデータソースに使う妥当性はどう説明されている？

A. 4 ページのデータショーケース論文ということもあり、正面からの妥当性議論はほとんど無い。 Threats to Validity セクション自体が存在しない。 論文が暗黙に挙げている正当化は 3 つ：(1) 規模（248,761 本）と Novice〜Grandmaster の多様なスキル層、(2) Meta Kaggle 由来の豊富なメタデータが GitHub にはない利点、(3) 先行研究（Rule+ 2018, Pimentel+ 2019）はいずれも GitHub 由来で Kaggle は未開拓。 代表性（Kaggle ノートブックが DS 全体を代表するか）、コンペ中心文化のバイアス、管理された実行環境の影響には一切触れていない。

Q2. Kaggle をデータソースに使うことについて、他の論文はどう見ている？

A. リポジトリ内の論文を横断すると、次の見解が読み取れる。

Kaggle の強みとして挙がる点：

• コンペノートブックは同一タスクと同一データセットを共有するため、手法間の統制された比較が GitHub よりしやすい（sato2024multiverse が活用）。
• Kaggle のリビジョン履歴から、DS の反復と後戻りの自然な記録が取れる。GitHub のスナップショットにはない利点（同上）。
• スコアや投票、Performance Tier との紐付けで「質の高いノートブック」を定量的に選別できる（KGTorrent 固有の利点）。

限界や注意として指摘される点：

• siddik2023codequality（SCAM ‘23）は Threats to Validity で「Kaggle のノートのみであり、GitHub 等への一般化は未検証」と明記している。
• nguyen2025nonexecutable（MSR ‘25）は逆に「GitHub 偏り（Kaggle や HuggingFace は過少代表）」を外的妥当性の脅威として挙げており、裏返しの指摘になっている。
• psallidas2022datascience（SIGMOD Record ‘22）は GitHub OSS と企業内（ML.NET）を比較して「公開ノートブックと企業内パイプラインでは使われる技術や構造に差がある」と述べている。Kaggle はそのどちらとも異なる第三の文脈であり、結果の一般化にはさらに慎重になる必要がある。
• sato2024multiverse（OOPSLA ‘24）は top-20 コンペの top-20 ノートブックだけを抽出しており、人気上位の選択バイアスが掛かっている。

プラットフォーム横断の直接比較は存在しない。 リポジトリ内のどの論文も、Kaggle と GitHub のノートブックを同一指標で直接比較していない。 各研究は Kaggle を特定の限られた母集団として扱い、全 DS 実務の代表とは主張しない態度が主流。

自分のコメント

（ここは自分で都度書く欄。例：HTTP 経由だと出力付き・API だと出力なし、という差は、ノートブックの「実行結果＝状態の痕跡」を集めたい自分には重要。出力付きコーパスの使い道を考えたい。）