Claude Code / CodexでKaggle金メダルを取った話

TL;DR

• 実装と分析をAIに任せることで、実験量が桁違いに増えた（5-Fold CV合計1,515回）
• 実装から解放された分、人間はアイディアとデータ観察に集中できた
• ただし、スコアを押し上げたアイディアのほとんどは人間発。AIの提案の打率は低かった
• AIに素早く実験を回させるための環境・構成づくりも重要だった
• この構図はKaggleに限らず、定量評価できるR&D全般で起きうると感じている

今回のコンペで使ったコード・設定・分析結果を公開しています。
https://github.com/Chihiro-n/csiro-biomass-agentic-solution

はじめに

2026/1/28に終了したKaggleの草コンペ（CSIRO - Image2Biomass Prediction）で5位 / 3,803チーム（Top 0.1%）、金メダルを獲得しました。

自分が書いたコードはほぼゼロです。実装のほぼすべてをClaude Code / Codexに任せました。EDAなどで自分が書いたほうが早いと判断したときだけ手を動かした程度です。ただし、人間の仕事が消えたわけではありません。消えたのは「実装そのものに使う時間」で、むしろ重要になったのは仮説を立てること、データを観察すること、何を優先するかを判断することでした。

ではCoding Agentがあれば誰でも勝てるのかというと、そうではありません。理由は2つあります。まず、他の参加者もAIコーディングツールを使っています。道具が同じなら差はつきません。そして、Coding Agentは自律的にスコアを改善し続けることに限界があります。序盤のベースライン構築は強いですが、終盤の精度の詰めになると頭打ちになります。

この記事では、その上で自分がどうやって勝ったのか——Claude Codeに何を任せて何を自分でやったのかを、実験の記録(一部)とともにお伝えします。ただし、草コンペという特定のタスクでの体験なので再現性のある話ではありません。「ぼくのかんがえた〜」であり、これがベストだとも思っていません。AIコーディングツールを使ってR&Dや実験を高速に回したい人にとって、一つの実例になればと思います。

この記事で話すのはコンペでの活用方法に限ります。Claude Code / Codexの便利な使い方や最新機能の紹介は扱いません。そもそも私が使いこなせているわけではなく、高度なコマンドやClaude Code Skillsのような機能は使っていません。ただお願いしているだけです。Claude Code / Codex自体の使い方・便利な活用方法を知りたい方は、oikonさんやnukoさんやみのるんさんの発信を追ったほうが確実だと思います🙇‍♂️

コンペ参加中はClaude Code（Opus 4.5）とCodex（GPT-5.2 xhigh）を併用していました（いずれも2026年1月時点の最新モデル）。当時の体感として両者に大きな差は感じませんでした。実装や分析は得意だがスコア改善のアイディア出しは苦手、という点は共通しています。以下ではこれらを区別せず、コーディングエージェントという表記で統一します。

草コンペとは

画像からBiomass量(g)を推定するコンペ。

詳細はこちら
https://www.kaggle.com/competitions/csiro-biomass

日本語のまとめ記事はこっち
https://zenn.dev/prgckwb/articles/kaggle-csiro-image2biomass

私の解法はこれ
https://speakerdeck.com/chihironakayama/cao-konhezhen-rifan-ri

Kaggleで勝つために必要なこと

Kaggleに馴染みのない方もいるかもしれないので、最低限の文脈を共有します。この記事で頻出する用語だけ先に書いておきます。

• CV (Cross Validation): ローカルでの検証スコア
• LB (Leaderboard): Kaggleに提出したときのスコア
• OOF (Out-of-Fold): CVで各foldの検証データに対して出した予測

Kaggleは競技です。他の参加者より1ポイントでも精度を上げないと勝てません。

今回のコンペには3,804チームが参加し、金メダル獲得には17位以内に入る必要がありました。上位0.5%です。Kaggleで勝つというのは本当に難しいです。

そしてKaggleには定石がありません。モデル選択、データ加工、Augmentation、学習・推論パイプラインの設計、アンサンブル、後処理、それを適切に実装する力——コンペごとに何が効くかは変わります。とにかく実験するしかない。KaggleにはDo Everythingという言葉があります。思いつく施策を片っ端から試せ、ということです。

もちろん、Kaggleの強い人は過去の経験から何が効いて何が意味がないかの勘所を持っているので、効率的に枝刈りできます。ただ、その勘所がなければとにかく試すしかない。

言うは易く行うは難し。ひとつの施策を試すだけでも、実装に数時間かかることがあります。「このアイディア試したら効きそうだけど、実装めんどくさいな……」と見送った経験がある人も多いのではないでしょうか。

Coding Agentの登場で、この壁がほぼなくなりました。実装力も今までは重要なスキルのひとつでしたが、その比重は大きく下がっています。代わりに、何を試すかを決めるアイディアの力と、Coding Agentが素早く実験を回せる環境を整える力がより問われるようになったと感じます。

コーディングAgentの現在地

※米自動車技術会（SAE）の自動運転レベルのパロディです。

得意なこと——実装と分析：

• 「siglipのimage encoderを使ってtrain pipelineを書いて」みたいにCV・前処理・学習ループなどを必要な単位を理解して書いてくれる
• DINOv3のpatch tokenを活用したカスタムヘッドのような、モデルアーキテクチャを深く理解した実装もこちらから指示を出せばこなす
• 実装の正確さは高く、コードの品質は見ずに精度（CV/LB）だけで判断する運用でも問題なく回せた
• 実験結果の可視化、誤差の傾向分析、大量のNotebookの要約も得意

苦手なこと——自律的な精度改善：

• 「精度を上げろ」のようなアバウトな指示には、アンサンブル、TTA、正規化の追加など教科書的な施策ばかり提案してくる。コンペのお題に沿った本質的な改善提案がほしいのに！
• 公開Notebookを渡して「ここから改善して」もいろんなパターンのアイディアを提案はしてくれるが、どれもスコア改善には至らない。すでにコンペに最適化されており、AIだけで伸ばせる余地がない
• 自律的な改善サイクルは数回で頭打ち。コンペ序盤のベースライン構築までは頼れるが、終盤のスコアの詰めは厳しい

Kaggleではただ動くだけのコードを作るだけでは足りません。ライバルに勝つために、スコアをずっと伸ばし続ける必要がある。ここが現時点でのAIの限界であると感じました。

実装と分析はAIに、アイディアと判断は人間に。AIに分析をさせて、その結果を見て人間が次のアイディアをひねり出す。この役割分担が、今回のコンペを通じて見えてきた形です。

この構図はKaggleに限った話ではありません。にとりさんがトレード領域でClaude Codeを活用した記事でも、「LLMが考えてくる戦略は基本に忠実だけど、なんかセンスを感じない」とほぼ同じ壁にぶつかっています。お題が違っても同じ限界にぶつかるということは、これが現時点でのAIの構造的な限界なのだと思います。おわりにで改めて触れます。

実験環境

まず実験環境について触れておきます。

ローカルのMacBook Airでコーディングエージェントを動かし、Google Driveをマウントしたディレクトリを作業ディレクトリにしています。コーディングエージェントはこのディレクトリ内でtrain.py、infer.py、config.yamlなどのファイルを作成・編集します。

学習の実行はGoogle Colabです。ColabからGoogle Driveをマウントすれば、コーディングエージェントが書いたコードがそのまま見えます。Colab Notebookにpythonスクリプトの実行コマンドを書いて実験を投入する、という流れです。

[ローカル Mac]                    [Google Colab]
コーディングエージェント              Notebook
  ↓ コード作成・編集                ↓ 学習実行
  ↓                               ↓
Google Drive (マウント済み) ←――――→ Google Drive (マウント済み)
  EXP/EXP001/train.py              同じファイルが見える
  EXP/EXP001/config/               結果もDriveに保存される
  EXP/EXP001/output/

この構成の利点は環境構築がほぼ不要なことです。DockerもクラウドのGPUインスタンスも要りません。コーディングエージェントがコードを書き、Colabで実行し、結果がDriveに溜まる。ColabのNotebookを複数開けば並列実行もできます。

高価なGPU環境を自前で持っていない人でも、この構成ならすぐに始められます。

Colabは月額5,767円で以下のGPUが使えます※2026年3月時点

実験を高速に回すための構成

今回のコンペでは、5-Fold CVで合計1,515回の学習を回しました（ユニーク実験数は約300）。

これだけの数を回せたのは、実験管理の構成を工夫したからです。ベストかどうかはわかりませんが、一例として紹介します。

EXP + child-exp の2段構成

EXP/
├── EXP001/
│   ├── train.py           # メインの学習パイプライン
│   ├── config/
│   │   ├── child-exp000.yaml   # ベース設定
│   │   ├── child-exp001.yaml   # loss変更
│   │   ├── child-exp002.yaml   # model変更
│   │   └── ...
│   └── output/
│       ├── child-exp000/
│       │   ├── oof.csv
│       │   └── result.json
│       ├── child-exp001/
│       └── ...
├── EXP002/                # パイプラインを大きく変えるとき
│   ├── train.py
│   ├── config/
│   └── output/
└── ...

EXPの使い分け：

• train.pyのパイプラインを大きく変えるとき → 新しいEXPを作る
• パラメータ、loss、モデルの変更程度 → 同じEXP内のchild-expで回す

こうすることで、コーディングエージェントへの指示が簡潔になります。「EXP001のchild-exp003として、lossをXXに変更して」で済む。後方互換性を保つのでtrain.pyは膨れますが、実験のサイクルを速く回すことを優先しました。

CLAUDE.md / AGENTS.md — AIへのプロジェクト指示書

最初から設計したわけではありません。コンペ中にがむしゃらに走る中で、AIが同じミスを繰り返すたびに「二度とやるな」と書き足していった結果、場当たり的に育ったものです。

• CLAUDE.md（430行）: コーディングエージェント用の指示書。評価関数の正しい実装と間違った実装の両方を明記したり、infer.pyの変数名バグが3回出たので「必ずチェックしろ」と書いたり、後方互換性のルールを良い例・悪い例つきで記載したり。痛い目にあうたびに育っていきました。
• AGENTS.md（270行）: Codexも併用し始めたタイミングで作成。CLAUDE.mdをベースに削ぎ落とし、「これをやるとLBが下がる」というガードレールリストを重点的に追加しました。

どちらも「AIに同じ失敗を繰り返させない」ためのドキュメントです。こうした指示書があるとないとでは、AIの出力の安定感がまるで違います。

EXP_SUMMARY.md — 実験履歴

実験が増えてくると、コーディングエージェントは過去に試して効かなかった施策を何度も提案してきます。これを防ぐために、EXP_SUMMARY.mdで実験の履歴を一元管理しました。

実験の流れはこうです：

1. コーディングエージェントに実験コードを書かせる
   → EXP/{EXPNO}/config/child-{childexpno}/ に train.py, infer.py, config を作成

2. Colabで実行する
   → EXP/{EXPNO}/outputs/child-{childexpno}/ に結果が出力される
      ├── oof.csv          # Out-of-Fold予測
      ├── train.log        # 学習ログ
      └── result.json      # CVスコア

3. KaggleにSubmitしてLBスコアを確認する

4. EXP_SUMMARY.md を更新する
   → 実験名、変更内容、CV、LB、成功/失敗、所感を追記

EXP_SUMMARY.mdの役割は「AIの記憶」です。 次に実験の方針を相談するとき、このファイルを読ませることで「それは前に試して効かなかった」と立ち返らせない。(LBスコアは手作業で記入していましたが、APIで取得できる)

ただし注意点があります。失敗した実験を大量に読ませると、AIが非常に消極的になります。「もう打ち手がないです」と諦めてくる。振り返ると、過去の失敗を踏まえた上で新しいアイディアを出すことをAIに期待すること自体が間違いでした。EXP_SUMMARY.mdは「同じ失敗を繰り返させない」ためのガードレールとして使い、次のアイディア自体は人間が出す。この割り切りが大事です。

小ネタ：AIにも性格がある

失敗実験を読ませすぎると消極的になると書きましたが、そのときのClaudeの「撤退の仕方」が面白かったので共有します。「正直に言います。0.73を超えるのは極めて困難」と切り出し、選択肢Aに「撤退（現実的）」を提案してくる。別の場面では「このコンペは学びとして区切りをつけますか？」と、ただ諦めるのではなく学びの場として着地させようとしてくる。さらには「exp058を信じてPrivateに賭ける」という根拠のない楽観案まで出してきます。いろんな言い回しでなんとか私に勝ちを諦めさせようとするのがおかしくて、ついついキャプチャを撮りためてしまいました。

一方、Gemini 3.0 Pro（Chatでアイディアの壁打ちに使用。Gemini CLIは未使用）は真逆の性格でした。相関分析の結果を見せると「まさに"宝の山"を見つけた状態です」と興奮し、別の場面では「大・勝利の予感ですね！プロボクサーが1ラウンド目でダウンを奪ったくらいの勢い」と全力で盛り上げてきます。実際はその特徴量は何の役にも立ちませんでした。

Claudeは慎重すぎて撤退、Geminiは楽観的すぎて空振り。どちらも人間が判断を握っていないと危ない、という点では同じです。

---

ここまで紹介した構成の実物はGitHubに公開しています。最終Submissionに使ったEXP060・EXP113を含むいくつかの重要な実験と、Colabでの実行用Notebook（execute_train.ipynb）を載せています。EXP + child-expの構成、CLAUDE.md、EXP_SUMMARY.mdなど、この記事で紹介した運用がどう動いていたかを確認できます。

アイディアから実験への流れ

構成の話ばかりしてきたので、実際にどうやってアイディアをコーディングエージェントに渡していたのかも紹介します。

アイディアを思いついたらまずメモします。雑でいい。「2000x1000の横長画像からCrop数を増やしてデータ数を稼ぐ」程度のメモで十分です。そのメモをそのままプロンプトに投げるか、もう少し練ってからmdファイルに書いておくか、2パターンの依頼方法がありました。

方法1: プロンプトに直接投げる

具体的なアイディアがあるときはそのまま投げます。

EXP060のchild-exp005をベース実験として、「2000x1000の横長の画像から現在は半分半分の1000x1000を2枚だけ学習に使っているが、1000x1000のx座標を変更して、ランダムに5枚切り出して学習に使えるようにしてください。」

ベース実験を指定することで、コーディングエージェントはEXP構成を理解した上でchild-expとしてconfigとコードの差分を作ってくれます。

方法2: mdファイルにまとめてから渡す

GeminiやChatGPTのDeep Researchで調べた結果や、精度が高そうだと気になったモデルの情報など、プロンプトに収まりきらない量の情報は docs/Idea_Research/ にmdファイルとして書き溜めておきます。雑なメモでもいい。溜めておくと、あとからコーディングエージェントに「このファイルを読んで、まだ試していないものを実装して」と渡すだけで勝手にやってくれます。

GeminiにDeep Researchで調べてもらった結果です。
docs/Idea_Research/20251221_gemini_deepresearch.md
まだ試していないアイテムがあれば教えてください。child-expで対応できそうならそちらで、train pipelineに大きな変更が必要ならEXPのリビジョンを上げて実装してください。

こうするとコーディングエージェントがEXP_SUMMARY.mdと照らし合わせて、まだ試していないものをピックアップし、実験の規模に応じてchild-expかEXPかを判断して実装してくれます。

どちらの方法でも、アイディアの粒度は人間が決めて、実装への落とし込みはコーディングエージェントに任せる。この分業が実験のスピードを上げてくれました。

スコアアップの記録

ここからが本題です。実験の時系列の成功失敗例を記載します。各施策について、アイディアが人間由来かAI由来かも記載します。

成功した施策

#	施策	アイディア	結果	備考
1	ConvNext baseline	AI（フル実装）	ベースライン完成	最初のパイプラインをまるごと書かせた
2	SigLIP (freeze head only)	人間	↑	モデル選択は自分で判断
3	SigLIP + Gradual Unfreeze	AI	↑	数少ないAI発のヒット
4	SigLIP half/half (freeze head only)	人間	↑
5	Augmentation設計（RandomResizedCrop等）	人間	↑	データ観察から気づいた。カメラ高さのばらつきへの対策
6	EVA02-CLIP	人間	↑
7	EVA02-CLIP + Consistency Loss	AI（参考資料経由）	↑	Kmatさん資料を読ませたら出てきた
8	DINOv3	人間	↑	High Score Notebookを参考に
9	CV設計の変更（月単位Group）	人間	↑	sampling_dateのGroupを月単位に変更。LB大幅改善
10	DINOv3 patch特徴	人間	↑	金メダルラインに押し上げたアイディア
11	入力解像度の段階的向上	人間	↑

精度が上がらなかった施策（抜粋）

#	施策	LB	備考
A	Focal Loss	0.64 (CV 0.78)	CV↑ LB↓の典型。過学習
B	補助タスク（Metadata予測）	0.66→変化なし	補助タスク系は効果なし
C	補助タスク（Species予測）	0.62	上と組み合わせて悪化
D	手工特徴（ExG/HSV）	0.62	画像特徴を手動抽出。逆効果
E	EMA（指数移動平均）	-0.04	壊滅的崩壊。CV -0.170
F	3-Crop学習	0.66	学習・推論の分布不一致で悪化
G	Cosine Annealing	0.65	変化なし〜微減
H	苦手speciesのloss penalty強化	CV↑ LB↓	Trainの分布を歪める系
I	苦手サンプルの水増し	CV↑ LB↓	同上

この記録から読み取れること

精度が上がった施策のほとんどは人間のアイディアです。 AIから出たヒットはGradual UnfreezeとConsistency Loss（資料を読ませた結果）の2つだけ。

一方で、精度が上がらなかった施策の大半はAIの提案です。
でも、これは普通のことです。Kaggleでは10回実験して1回当たれば良い方。外れること自体は問題ではありません。問題は試行回数を稼げるかどうか。

AIがいなければ、失敗した施策の多くはそもそも試す時間がなかった。実装コストがほぼゼロに近づいたことで「とりあえず試す」ができるようになった。これがコーディングエージェントの本当の価値であると感じました。

そして最も重要な勝因であるDINOv3のpatch tokenの活用は、「精度上げろ」のようなアバウトな質問からは絶対に出てきません。このアイディアは、コンペ参加中ずっと考えていた仮説から生まれました。「画像に写っている草の重さを推定するなら、緑の面積・高さ・密度の3つの情報が大事なはずだ」と。これをうまくモデルで表現できないかをずっと考えていて、DINOv3のpatch tokenの出力を目視で観察したときに「これだ」とつながりました。

K_matさん（Competition GrandMaster）が記事で書かれているように、コンペ特注のドメインやクセをNNにうまく学習させるため工夫を考えることが大事です。コーディングエージェントはこの「コンペ特注」の部分が苦手で、「いつもやること」は得意。だからこそ、「いつもやること」はコーディングエージェントに任せて、人間は「そのコンペだからやること」に集中する。

DINOv3のpatch tokenにたどり着けたのもコーディングエージェントが実装を引き受けてくれていたからです。実装に時間を取られなかった分、モデルの出力を注意深く観察する余裕が生まれました。人間がアイディアに集中できる環境を作ること自体が、コーディングエージェントの貢献だったと思います。

AIに任せて効いた使い方

実装以外にも、コーディングエージェントが力を発揮した場面があります。共通するのは「分析までは積極的に任せていい。その先のアイディア出しは人間がやる」という線引きです。

OOFの分析

OOFを分析させて、推論が苦手なサンプルの傾向を把握する。これは積極的に任せていいです。 どのアイテムの予測が外れているかをメタデータと照らし合わせて分析させると、非常に質の高いレポートが出てきます。どのカテゴリで誤差が大きいか、どういう画像で失敗しているかを可視化・言語化してくれます。

実際、分析結果の出力先として output/ 以下にカテゴリ別の分析をどんどん溜めていました。

output/
├── CV_LB/           # CV-LB相関の分析
├── STATE_SEASON/     # 状態×季節ごとの誤差分析
└── ...               # その他メタデータ別の分析

こういう切り口を変えた分析を何パターンも回せるのは、AIの得意領域です。自分でやったら面倒で2〜3パターンで止まるところを、気になる軸を片っ端から試せる。

ただし、分析結果をもとにしたNext Actionの提案は全外しでした。具体例を出します。

私「OOFエラー分析で、SpeciesがXXのサンプルが苦手であることがわかりました。ラベルよりも明らかに予測が低すぎる傾向にあります。改善するアイディアをください」
エージェント「Speciesごとにlossの重みを変えましょう」
→ 実験 → CV↑、LB悪化
エージェント「過学習でした。XXのサンプルの推論結果を1.2倍に補正しましょう」
→ 実験 → また悪化

このように、Trainの分布を歪めるか、推論時に無理やり補正する方向のアイディアばかり出してきます。「過学習でした」と自分で言ったのに、次の提案もまた同じ方向。このループが何度も繰り返されました。

ただ、これはAIだけの問題ではなく、私の指示の出し方にも原因があったかもしれません。「このSpeciesが苦手だから改善して」と課題を限定してしまうと、AIはその課題を直接的に解決しようとします。結果、Trainの分布を歪めるか推論時に補正するかの二択に収束してしまう。もっと広い視点で聞いていれば、違う提案が出ていた可能性もあります。

いずれにせよ、分析結果を読んで次に何をやるかは、人間が決めたほうがいいです。 出してくれるレポートを注意深く観察して、アイディアは人間がひねり出しましょう。

CV-LBの相関分析

これも積極的に任せていいタスクです。実験が増えてくるとCVとLBの相関を確認したくなりますが、自分でやるより任せたほうが早い。CVスコアの信頼性が揺らいでいないか、特定の実験群でCV-LBの乖離が起きていないかを定期的にチェックさせていました。

ただし、CVの切り方自体を工夫する必要があることには、AIが自律的にたどり着くことはできませんでした。今回のコンペではCV設計に工夫が必要でしたが、それはこちらからの指示でたどり着いた形です。ここでも「分析は得意、設計は人間」という同じ構図です。

High Score Notebookの分析

Discussion や上位のpublic notebookを全部読ませて、要約・比較させる。これは非常に有効でした。大量の情報を短時間で整理してくれるので、自分がどのアイディアを深掘りするか判断する材料になりました。

コーディングエージェントが得意なコンペの前提条件

念のため補足しておくと、今回の草コンペはAIコーディングとの相性が良い条件が揃っていました。

• データ数が少なく、1実験の学習時間が短い → 試行回数を多く回せた
• タスクがシンプル（画像回帰） → パイプラインの構造が単純
• 同時期開催の別コンペ（PhysioNet）はパイプラインが複雑で、Agentの手助けを得にくかったと思います

データ量が大きいコンペや、パイプラインが複雑なコンペでは、また違う結論になるかもしれません。

おわりに

コーディングエージェントは「Do Everything」のハードルを劇的に下げました。「言うは易く行うは難し」だったものが、「言う方を人がやれば、行う方はAIがやる」に変わりました。

ただし、何を試すかを決める力は今まで以上に問われます。実装の差がなくなった分、差がつくのはアイディアとデータ理解の深さです。

これはKaggleに限った話ではなく、定量評価ができるR&D全般に当てはまると思います。冒頭でも触れたにとりさんの記事では、トレード領域でClaude Codeを活用した体験が書かれていますが、ぶつかった壁が驚くほど似ています。

• AIの提案は「基本に忠実だけどセンスを感じない」→ Kaggleでも「教科書的な施策ばかり」
• 「コアの方針は自分で考えて、深掘りさせるのが良い」→ まさに「アイディアは人間、実装はAI」
• 「ただ『戦略を考えて』と投げる人と、何を分析すべきか知っている人では結果が全然違う」→ 「精度上げろ」vs 具体的な指示
• バックテストだけ強いけど本番ダメ → CV↑ LB↓
• 禁止リストを増やすとコンテキスト汚染される → EXP_SUMMARY.mdに失敗を書きすぎると消極的になる

評価が定量的にできて、フィードバックループが回せる。だからAIとの相性は良い。しかしドメイン知識がなければ使いこなせない。領域は違えど、構造は同じです。