📖 読了目安：約9分
普段はAPIとDBを触っているバックエンドエンジニアが、人生2回目の本格的なKaggleコンペに挑んだ。しかも今度は、これまで触ったことのない「音声」が相手だ。結論から言うと、半分は惨敗で、半分は望外の大逆転だった。賢いAIには裏切られ続け、最後に勝ったのは「現地の泥臭いAI」だった。その6週間の記録を書き残しておく。
第1幕：導入 ── 畑違いの戦場へ
1-1. 自己紹介とジレンマ
本業はバックエンドエンジニア。API設計、DBチューニング、CI/CDパイプラインの整備は日常的にやっている。一方で、機械学習（ML）はまだ初心者の域を出ない。
とはいえKaggleは初めてではない。前回、Playground Series（Kaggleの練習向けシリーズ）の「顧客解約予測」コンペに挑んだ。表形式データで、顧客が解約するかを当てる課題だ。だから、しっかり参加するのはこれで2回目になる。
だが今回は勝手がまるで違った。前回が見慣れた表データだったのに対し、今回の相手は 音声 だ。選んだのは BirdCLEF+ 2026。南米パンタナール地域の自然録音から、どの鳥が鳴いているかを当てるコンペで、賞金は$50,000、主催はコーネル大学の鳥類研究所、世界中の研究者が集まる。
表データなら業務の延長線上で想像がつく。だが音声は完全に未知の領域だ。「2回目」という小さな自信と「初めての音声」という大きな不安を抱えて、この戦場に足を踏み入れた。
1-2. 今回の戦場
やることはシンプルに聞こえる。「録音を聞いて、鳴いている鳥の種類を当てる」。だが初心者の前には、すぐに3つの壁が立ちはだかった。
- データが音声で、とにかく重い。画像や表データと違い、扱いに手間と計算時間がかかる。
- 正解ラベル付きの“現地データ”が極端に少ない。パンタナールで録られた、答え合わせができる音声はごくわずかしかない。
- 本番の採点環境が厳しい。提出時の予測計算は 90分以内・インターネット遮断 でやり切らねばならない。
この3つが、後に何度も奈落に突き落とすことになる──とは、この時点では知る由もなかった。
1-3. バックエンドの武器は通用するのか（4月12日）
ML力では世界の猛者に勝てない。それは最初から分かっていた。だから、本業の武器で殴ることにした。自動化・構造化・CI/CD。要するに「ソフトウェアエンジニアの基礎体力」だ。
予測を作る一連の流れ（パイプライン）を組み、GitHub Actionsからボタンひとつで本番採点まで走る仕組みを先に整えた。MLの知識は薄くても、ここは自分のフィールドだ。
最初のスコアは 0.532。0.5は「まったくのデタラメ」を意味するので、ほんの少しマシな程度。ここから長い旅が始まった。
第2幕：展開 ── 賢いAIたちの、裏切りの記録
2-1. 最初の上り坂 ──「教科書通り」は素直に効いた（0.532 → 0.776）
最初のうちは順調だった。
まず、鳥の鳴き声を「声紋のような縞模様の画像」に変換し、画像認識AIに見分けさせた。次に、複数のAIの予測を平均する「多数決」方式にした。さらに、Googleなどが公開している**鳥の声の専門AI（Perch）**を“すでに耳が肥えた先輩”として借りてきて、自分は最後の判定だけを担当する形にした。
ここまでで 0.776。教科書通りにやれば、初心者でもここまでは上がるのか──と、このときは安心していた。
2-2. 小さな大勝利 ──「鳴き声が途切れる」問題（+0.010）
次の改善は、MLというより観察から生まれた。録音は5秒ごとに区切って処理していたが、パンタナールの鳥は鳴き声が短く、ちょうど区切りの境界で声が分断されてしまう。そこで区切る位置を少しずらして何度も聞き直し、結果を重ねた。
たったこれだけで +0.010、過去最大級の改善になった（0.786）。「対象を素直に観察すると効く」──この小さな成功体験は、後半の大逆転の伏線になる。
2-3. 繰り返される悲劇 ──「練習では天才、本番では役立たず」
ここからが本当の戦い、そして長い苦難の始まりだった。
Kaggleには2種類の点数がある。手元で自己採点する CV（練習点） と、本番で採点される LB（本番点） だ。教科書には「強いモデルを足してCVを上げ、多様なモデルを混ぜろ」とある。初心者ゆえ、それを素直に信じた。
そして、3体の高性能AIに順番に裏切られた。
- 画像AI(ConvNeXt)：練習点は全モデル中トップ。意気揚々と投入したら、本番点はむしろ悪化。
- 時系列を読み解くAI(SSM)：音声を時間の流れとして追うタイプ。練習点が高く期待したが、本番では −0.009 の害。混ぜるほど点が下がった。
- 大型のTransformer(AST)：何時間もかけて学習させた自信作。だが本番にかけると 90分の制限時間に間に合わずタイムアウト。一度も採点されず丸ごとボツになった。
| 投入したAI | 練習点(CV) | 本番(LB) | 結末 |
|---|---|---|---|
| 画像AI ConvNeXt | 最高クラス | 悪化 | 凍結 |
| 時系列を読み解くAI SSM | 高い | −0.009 | 凍結 |
| 大型Transformer AST | 最高クラス | 測定不能 | 90分超過でボツ |
特にASTの件は痛かった。だがこれは、MLの失敗というより見積もりの失敗だ。「本番の制限時間に収まるか?」を作る前に測っていれば防げた。本業なら真っ先にやる確認なのに、畑が違うと当たり前のことほど抜け落ちる。
2-4. 見えてきた“真犯人” ──「似た者同士は混ぜても無駄」
裏切りはこれだけではなかった。数値の微調整、順位の補正、確率の補正……良かれと思って足す施策が、ことごとく**「点が1ミリも動かない」**結果に終わった。同じ壁に何度もぶつかるうち、一つの仮説にたどり着いた。
多数決は、“違う視点”の意見を入れたときだけ強くなる。似た意見は、何票積み上げても結果が変わらない。
すでに似た判断をするAIをいくら足しても、結論は動かない。当たり前のようでいて、教科書はこれを正面から教えてくれなかった。この仮説が、第3幕の大逆転への伏線になる。
2-5. エンジニアリング力で殴る
ML力で勝てないなら、実験の物量と管理で勝負するしかない。ここはバックエンドエンジニアの独壇場だった。GitHub ActionsのUIから設定を変えて提出を自動で回し、スマホからでも実験を起動できるようにした。そして何より、すべての実験に通し番号（RUN番号）を振り、結果と考察を記録し続けた。「何を試して、何が効かなかったか」を一切忘れない仕組みだ。
最終的に試した施策は 33本。大半はボツになったが、その記録こそが次の一手の精度を上げた。ML力の不足を、実験管理と自動化の物量で補う──これが初心者なりの戦い方だった。
第3幕：結末 ── 非常識な賭けと、二度の大逆転
3-1. 賭け ──「世界中のデータより、“この沼地”の音だけで学ばせる」
ある時、ふと考えた。借りてきた高性能AIたちは、みな“世界中の鳥の声”で学んでいる。だから一般的には優秀だ。でも、もしかするとパンタナール特有の音に対しては、世界の常識がかえって邪魔をしているのではないか?
そこで非常識な賭けに出た。現地で録られた正解付きデータ──たったの59ファイル──だけを使って学ぶAIを、一から作ってみたのだ。普通の感覚では「データが少なすぎて学習にならない」と一蹴される発想だ。だが初心者ゆえ、その常識を知らなかったぶん、迷わず張れた。
3-2. 第一の大逆転 ── 比率を上げるほど伸びる恐怖
この“現地特化AI”を、他のAIたちの多数決に少しだけ混ぜてみた。比率10%。点が上がった。20%、また上がった。そこから先は恐怖に近い体験だった。混ぜる比率を上げるたびに、過去最高を更新し続けるのだ。
| 現地AIの比率 | 本番LB |
|---|---|
| 60% | 0.801（初の0.8突破） |
| 80% | 0.805 |
| 90% | 0.808 |
| 100%（このAI単独） | 0.851 |
そして比率を100%──つまり他の賢いAIを全部捨てて、現地AI単独にした瞬間、点数は 0.808 から 0.851 へ歴史的なジャンプ を見せた。
種明かしはこうだ。賢いAIたちは、現地AIが確信を持って出した正しい判断を、多数決で薄めて殺していた。第2幕の仮説──「似た意見をいくら足しても無駄」──には、さらに先があった。足を引っ張る意見は、引き算したほうが勝つ。教科書は「足せ」と言う。だが、このコンペの正解は「引け」だった。
3-3. 第二の大逆転 ──「いつ・どこで録ったか」という宝の山
勢いに乗って仕上げの後処理を片っ端から試した。多くは空振りだったが、「その場所にいない鳥を候補から外す」(+0.004)、「順位の情報を少し混ぜる」(+0.007) が当たった。
そして、最大の鉱脈を掘り当てた。録音データには「いつ・どこで録ったか」という情報が付いている。これを使い、その場所・その時間帯に鳴きやすい鳥を推定して予測を補正してみたのだ。結果は いきなり +0.030。これまでの改善が0.001刻みだったことを思えば、桁違いの当たりだった。
パンタナールは湿地・森林・草原で生息する鳥がまるで違う。だから「場所」だけで候補を大きく絞れる。当たり前すぎて誰も真剣に集計していなかった情報だ。データを素直に集計して活かすという、バックエンドエンジニアの地味な習性が、ここで効いた。
3-4. 仕上げと、最後の壁（0.904で着地）
最後に、発想の違う別タイプの専門AIを混ぜて、点数は 0.903 → 0.904 に届いた。
だが、ここが限界だった。これ以降は何をしても点はぴくりとも動かない。公開されている上位の参加者は0.950に達していて、その差は最後まで埋まらなかった。正直に書けば、これは初心者の力不足だ。
3-5. 数字で振り返る6週間
| 指標 | 数値 |
|---|---|
| 期間 | 約6週間（4/12〜6/2） |
| 投入したAIの種類 | 7系統以上 |
| 試した施策(RUN) | 33 |
| 凍結（ボツ）にした軸 | 多数 |
| 最高LB | 0.904（出発点 0.532 から +0.372） |
3-6. 得られた知見
ML面（初心者の学び）
- 練習点(CV)と本番点(LB)は別物。手元の自己採点が高くても本番で悪化することが何度もあり、この食い違いに最後まで悩まされた。
- 効いたのは派手なモデルではなく、“現地データ”と“場所・時間の文脈”という地味な情報だった。
- 多様性のない追加は無意味。似た判断をするものは、何個足しても結果が変わらない。
エンジニアリング面（この記事の核）
- MLの専門知識が浅くても、Kaggleは戦える。武器は、自動化・実験管理・そして「効かないものを見切る判断」。すべてソフトウェアエンジニアの基礎体力そのものだ。
- 勝負を分けたのは、賢いAIを全部捨てる「賭け」と、効かない施策を切る「撤退」。皮肉にも、初心者だったからこそ常識に縛られず賭けられた。
3-7. 次の一歩、そして反省
正直な反省を書く。一番効いた手──現地データと場所・時間の文脈──に気づくのが遅すぎた。 どちらも終盤の2週間で見つけた施策で、もっと早く着手していれば、裏切りAIたちに溶かした時間を別のことに使えた。
そしてもう一つ。序盤に「信頼できる物差し（手元で本番点を正しく予想できる検証の仕組み）」を作っておくべきだった。これがあれば、本番前に多くの空振りを見抜けた。本業で言う「テストと監視を先に整える」話と同じで、畑が違っても効く原則は同じだった。
ML初心者のバックエンドエンジニアでも、エンジニアの戦い方で本気のコンペに食らいつけた。0.532から0.904まで、6週間で這い上がれた。次に挑むときは、最初の2週間で物差しを作るところから始めたい。
鳥の声は、最後までいろいろなことを教えてくれた。