はじめに
- Kaggle 本家はブラウザ＋クラウド前提で、手元でやるには環境を自分で足す必要がある
- LB 提出は 失敗するとスロットを無駄にしやすい
この記事で分かること:
- Cursor にコードを書いてもらう ためにローカルに寄せる理由
- 手元なら venv + Jupyter + エディタプロファイル分離 のセット
- 提出 zip を ローカル verify してから LB に出すメリット
- Notebook 紐づけ提出 でハマりがちな点（403 時に zip-only しない、など一般論）
シリーズの読み順: 0008 プロファイル分離 → 0010 コンペ開始の儀式 → 0011 Skill 分離 → 本記事（ローカル verify）。コスト周りは 0009 失敗談 → 0012 コスト設計 を参照 (｡･ω･｡)
結論
ローカルで「壊れていない提出物」を作ってから、LB は確認用に使う。
環境は プロファイル分離 で軽くし、検証は 提出前の習慣 に固定するのがよさそうです ((_๑òωó)_ﾊﾞﾝ
想定読者
- Kaggle の
.ipynbをローカルで触り始めた方 - Cursor のエージェントに実装を書いてもらいながら コンペを回したい方
- 提出エラーで LB スロットを無駄にしたくない方
- Cursor / VS Code で Kaggle と Web 開発を行き来している方（Skill 分離は 0011）
私の属性
- エディターは Cursor がメイン（VS Code 系プロファイルの考え方は同じ）
-
拡張機能52個でPCが重すぎた話 で Kaggle 用プロファイル（
Kaggle-Light） を分けた - コンペ ROOT だけを開き（0011）、ローカル verify → Notebook 紐づけ提出、の順を意識している
理由と手順
なぜローカルか
私がローカルに寄せた いちばんの理由 は、Kaggle 本家の Notebook より Cursor のエージェントに実装を書いてもらう方が速い からです。
自分でコードを書くより、エージェントに patch を出してもらい、短い verify で確認するループの方が合っています。
Kaggle Notebooks 公式 の世界はクラウド中心です。
ブラウザ上だけだと、エージェントとの共同編集や手元での短い検証がしづらいので、手元に Python + Jupyter を置いています。
0010 の my-notebook/（Cursor が編集）→ ローカル verify → Kaggle Notebook、という流れの 土台 です。
| 場所 | 向いていること |
|---|---|
| ローカル | エージェントとの .ipynb 編集、短い verify、スクリプト整形 |
| Kaggle Notebook | コンペ公式データに近い実行、提出用 Notebook |
| LB | 最終確認（ローカルで通ったものだけ） |
全部をローカルで完結させる必要はありません。壊れた zip を LB に投げない ことが目的です。
手元環境 — venv + Jupyter + プロファイル分離
最低限、次の3つをセットにしています。
- コンペごとの venv（依存を他プロジェクトと混ぜない）
- Jupyter + Python 拡張
-
Kaggle-Lightプロファイル（0010 でコンペ ROOT 用に使う名前。Web 系拡張を入れない）
プロファイル分離の詳細は 拡張機能52個でPCが重すぎた話 に任せます。
コンペ ROOT の開き方と Skill の閉じ方は Kaggle用Cursor Skillをコンペフォルダだけに閉じた話 を参照してください。
# 例: コンペ ROOT で venv 作成
python -m venv .venv
.\.venv\Scripts\Activate.ps1
pip install -r requirements.txt # あれば
ローカル verify を先に回すメリット
提出前にローカルで確認すると、次のような LB 前の脱落 を減らせます。
- zip サイズ・形式の不一致
- 静的チェック（shape・禁止 op など、コンペが定める条件）
- 明らかな壊れファイル（空 zip、パス違い）
| 順番 | やること |
|---|---|
| 1 |
my-local-eval-notebook/ または dataset/ 配下で verify を PASS |
| 2 | 問題なければ my-notebook/ を更新し、Kaggle Notebook に反映 |
| 3 | Notebook 紐づけ で LB 提出 |
my-local-eval-notebook/ は 0010 で 検証専用・提出しない 置き場として定義しています。
「完走した Notebook」≠「提出できる zip」とも言えます。
verify は 提出物そのもの を見る段階だと安心です（´・ω・`）
Notebook 紐づけ提出でハマりがちな点（一般論）
コンペによって提出方式は違いますが、Notebook 紐づけが絡むときに私が踏んだ・見たパターンです。
特定コンペの解法は書きません。
| 症状 | 一般論としての対処 |
|---|---|
| 403 が出る | zip だけ差し替えようとしない。紐づく Notebook / kernel の状態 を先に直す |
| Notebook と zip の不整合 | 提出前に「どの Notebook 版が zip を生んだか」を my-ran-notebook/run-log.md に1行残す |
| 他人の Notebook を参照した | ライセンス・ルールを確認。fork は材料、CHK には仮説だけ 載せる |
| ローカルで通ったのに LB で落ちる | 入力データ版・実行環境差。docs-ja/kernels-runbook.md に環境メモを残す |
Kaggle API / CLI で kernel を操作する場合も、token は Git に載せない のは当然として、ログに出さないよう注意します。
具体例 — 私のループ（抽象化）
-
exp/experiment-checklist.mdから 今日1仮説 を選ぶ - Cursor に patch を書いてもらい、
my-local-eval-notebook/で verify PASS - 通ったら
my-notebook/を更新し、Kaggle Notebook で再現（必要なら GPU） -
my-ran-notebook/run-log.mdに結果を書く - 問題なければ Notebook 紐づけ提出
解法の中身はコンペごとに違うので、ここでは 順番だけ が再現ポイントです。
フォルダ儀式の詳細は Kaggleコンペ開始の「儀式」を固定した話 を参照してください。
注意点
- ローカルと Kaggle の データ版がズレる と verify が嘘をつくことがある
- エージェントに「提出まで」丸投げすると、GPU時間と提出枠の浪費可能性が痛い（Kaggle×Cursor×Google Colabのコスト設計 を参照）
- verify を通しても Public LB は別問題 — ローカルは「壊れていないか」のゲート
まとめ
- ローカルに寄せる主因は Cursor に実装を書いてもらう こと。venv + Jupyter +
Kaggle-Lightプロファイル をセットにする（0008・0010・0011 と併読） - 提出 zip は
my-local-eval-notebook/で verify → Notebook 更新 → 紐づけ提出 の順が安全 - API・GPU のコスト設計は 0012 を参照
- 403 などは zip-only で逃げず、紐づく Notebook 側を直す（一般論）
LB は最後の確認役にして、無駄撃ちを減らしたい人の参考になれば幸いです (ﾉ´∀｀*)
m(_ _)m 読んでくれてありがとうございました (´▽｀)