はじめに
今回はKaggle BirdClef2026コンペあるいは鳥コンペこと、「BirdCLEF+ 2026」の参戦振り返り記事となります。 鳥や虫の鳴き声から、5秒セグメントごとに234種の生物の存在確率を予測する多ラベル分類コンペで、例年類似のコンペが開催されております。2021年から開催されているため過去コンペでの知見が公開されていることやコーディングAIの台頭もあり、参加チームは4,084と非常に多かった印象です。一方で今年のコンペは過去と明確な違いもありました。またコーディングAIはもはや多くの参加者がデフォルトで活用しているため参加するための前提レベルであり、そこでの差はもはやつかず（もちろん人よりもさらにdeepに活用していく工夫はありつつ）、最終的にはいかに課題を的確にとらえるか、という洞察力が求められていたと思います。publicは最終16位で金圏だったものの、privateはshake downして72位という非常に悔しい結果となりました。本稿ではコンペの概要および上位解法などを振り返っていきたいと思います。

| (1) BirdCLEF+2026の概要

BirdCLEF+2026は、ブラジル・パンタナール湿地帯で録音された長時間サウンドスケープから、 5秒セグメントごとに234種の生物の存在確率を予測する多ラベル分類コンペで評価指標はmacro-averaged ROC-AUC（種ごとに AUC → 平均）でした。分類対象は: 162 Aves（鳥）/ 35 Amphibia（両生類） / 28 Insecta（昆虫） / 8 Mammalia（哺乳類） / 1 Reptilia（爬虫類）となります。与えられたデータは、train_audio:35,549ファイル（個別録音・206 種）、train_soundscapes: 10,658 ファイルでした。去年はラベル付きsoundscapesファイルが与えられませんでしたが、今年は、66ファイル、1,478セグメントがラベル付きという点が新要素でした。

このコンペの特徴・難しさは主に下記4点となります。（と、主観的に感じました）

・正解データを自分で作る必要がある
trainデータのtrain_audioはクリーンな単一個体の録音（focal）な一方、testは 多種が重なり背景ノイズだらけのサウンドスケープ。この分布のズレがあるため、テスト領域に近いtrain_soundscapesデータを活用することになるがごく一部しかラベル付けされていないため、labeled soundscapesだけではなくunlabeled soundscapesをいかに活用するかが求められる。

・ロングテールと音声が存在しない種
クラス不均衡は 1 件〜499 件と極端であり、さらに28種はtrain_audioに一切音声がない。 特にInsectaのsonotype（47158sonNN）25種は録音が（世の中の）どこにも存在せず、labeled soundscapeのラベルとしてのみ現れる。macro-AUCではsonotype 25種が評価対象75種のうち約1/3を占めるが、sonotype同士の取り違え（AUC が 0.5 を大きく下回る系統的逆転）を起こし、Perch・SEDいずれの特徴空間でも区別困難。

・CPU 90 分の推論制約
Code Competition のため、隠しテストに対しCPU 4コア・90 分で全推論を完結させる必要がある。これがアンサンブル設計を物理的に縛る。様々な高速化の工夫が必要であり、アンサンブル多様化には時間削減が前提となる。

・CV-LB、Public LB/Private LBの相関
labeled soundscape はわずか66ファイル・1,478セグメント。ここで作ったOOF/CVを信頼できるものにすることが困難。実際、2位の解法でも「LB と相関を保った唯一の指標は labeled SCのAUC、それでも相関は~0.2」と書かれている。これにより、多くのチームがpublic LBに無意識に過学習を蓄積することになる。

また解法の取り組み傾向含め、過去開催のBirdCLEFとの違いは下記となります。

観点	(主に)BirdCLEF2025	BirdCLEF2026
検証データ	実質なし	labeled soundscapes が初登場＝「Validation の導入」（優勝者いわく “something new to BirdCLEF lore”）
最適な窓長	20 秒モデルが有効（1 位など）	5 秒が最適。20 秒は今年は一貫して劣化（focal の文脈を削るとモデルが集中できる）
基盤モデル	SED CNN 中心	Perch v2（Google の鳥音声基盤モデル）が中核。公開 Perch NB が初日から強かった
対象種	鳥中心で2025では一部Insecta/Amphibia	Aves に加え Amphibia / Insecta / Mammalia / Reptilia、さらに音声のない sonotype
地域	多地域・別指標で地理マスクが有効だった年も	単一地域（パンタナール）＋ macro-AUC で地理マスクは無効
勝ち筋の中身	自己学習（Noisy Student）と XC 事前学習	同じ自己学習がdistillation を併用すると逆に効きにくくなるなど、レシピの再設計が必要
AI エージェント	限定的	Claude Code等のコーディングエージェントが標準装備に（序盤から多くの参加者が活用を明記）

優勝者のソリューションで述べられていた言葉が象徴的でした。

“初日から残酷だった。去年のアイデアが何ひとつ通用せず、他の参加者はコーディングエージェントで開発を自動化してLBを駆け上がっていくのに、自分はまだ旧来のやり方でコードを書いていた。(よってClaude Code活用を始めた)”

2026は「2025の延長」では勝てない年だったということですが、それでも彼は2025に続き、public/privateで1位という偉業を成し遂げました。その詳細は後述します。

| (2) 本コンペの取り組み

本コンペの私のアプローチは下記のようなものでした。

基本構造は 2つの異なる特徴空間（PerchとSED）をrank空間でブレンドするcross-modalityアンサンブルとなります。これ自体は参加者の多くと同じだと思いますが、特にSEDが単体public:0.942(private:0.940)とそれなりに強いモデルにできたことが少なくともpublicで金圏まで行けた要因でした。しかしこれはある種の罠で単体の精度を落としてでも推論時間を確保して軽い多様性のあるモデルをアンサンブルして汎用性を高めるべきだったことが終了後にわかりました。

効いた軸
– Perch v2 蒸留 SED：Perch の embedding を cosine/MSE で蒸留して SED backbone を初期化。これが SED 単体の土台。
– cross-modality rank blend：Perch（embedding）と SED（mel CNN）は特徴空間が直交し、error 相関 ~0.7。SED 単体 +0.001 が blend で +0.002 に増幅。
– OOF teacher pseudo（exp240, SED 単体 0.939）：BirdCLEF 2025 2位レシピ準拠。fold k のSCをfold k未学習の teacherで予測で indirect leakを排除。
– tail-end SWA（exp303, SED 単体 0.942）：aug 軸 4 戦・loss 軸 3 戦が全敗する中、唯一 training-sideでSED単体SOTAを更新。
– class 別非対称化：Aves は frame_max 寄せ、Insecta は clip 寄せ、と taxonomy ごとに pooling を変える。

効かなかった軸
– 反復擬似ラベル（Noisy Student）：上位が大きく伸ばした王道だが、distillationと冗長で機能せず。
– teacher のアンサンブル/多様化：teacherモデルの弱メンバーを混ぜるほど保守化して悪化。
– cross-family backbone メンバー（B0/V2-S）：脱相関は大きいが「弱モデルの別エラー＝worse-model noise」で ensemble に乗らず(かつ推論時間も足りない)。
– sonotype 改善：学習段階の様々な工夫でOOF +0.044 でも LB 非転移。
– metadata / 後処理の二重適用：site/hour prior、tax smoothing 等は既存救済機構と二重になり過剰補正。


スコア推移は下記となります。

マイルストーン	LB	効いた施策
exp005	0.902	Perch v2 + LogReg probe ベースライン
exp021	0.923	Perch probe + ProtoSSM のアンサンブル
exp050	0.930	全 234 クラス CNN ブレンド
exp128	0.937	rank blend（Perch × SED）
exp140 → 151	0.939 → 0.942	Perch + 4-way SED
exp229	0.951	SED を単 stack + overlap + sharp kernel に質的変更
exp234 → 254	0.952 → 0.954	class 別非対称化（Aves frame_max 寄せ）
exp289 → 301 → 308	0.955 → 0.956 → 0.957	SED 10-fold / 脱相関メンバー / cross-stack weight
exp334	0.958	AUC lossアンサンブル
exp337	0.958	cross-stack weight 0.70:0.30 再最適化

コンペは中盤以降から上位に着実にランクすることができ、1週間前ほどで金圏に入り維持することができました。ただしそれによってそのpublicLBでの金圏を維持することに注力してしまったといえるかもしれません。 結果、16位から72位へのshake downとなりました。

| (3) 上位ソリューション

上位の共通項は下記となります。
– Perch v2 蒸留 SED
– 反復擬似ラベル
– 多様なバックボーンの等重みアンサンブル
特に自分がうまくいかなかったのは「反復疑似ラベル」で、PseudoLabelを足すと特にiteration2回目以降はうまくいかずそこで差がでました。

1st Solution — public/private ともに 1 位（2025 も両 1 位）
① 2 段学習と「再蒸留による多様化」
Perch v2（1 モデルだけ AudioProtoPNet-5）から cosine embedding 蒸留（cosine は MSE より速く良い収束）→ 低 LR 2e-4 で end-to-end fine-tune。蒸留 11ep / FT 8-15ep、mixup p=0.5、AdamW。 同じ backbone でも head/label を変えるたびに毎回 backbone を再蒸留。蒸留 loss が非ゼロのまま残るので、seed 違いで再蒸留した同一構成 2 モデルを ensemble するだけで明確な boost。蒸留を「固定の土台」ではなく多様性の源に転用した。

② 自己学習：同じ壁を「信号を弱める」で越えた
1 位も「蒸留済み base に PL(PseudoLabel)を足すとPLなしより大幅悪化」を観測（＝自分と同じ症状）。原因を「強い base ＋ ノイジー PL は致命的、PL が全信号を自分側に引っ張る」と診断。 解決＝注入ラベルの和を focal 以下に cap（LSS injector は和 0.5、PL injector は和 0.75）。LSS(Labeld SoundScapes) は実GroundTruthを持つので noisy PL はそこを壊すだけ、非 LSS のレア種は focal から学ぶしかないので PL 信号を抑える。 LSS injector と PL injector を同一バッチで併用（別サンプルに）。LSS の正解で PL ノイズを相殺。さらに Site-22 の非 LSS 種をマスク（+0.002）。 結果 supervised 0.935 → iter1 0.946 → iter2 0.950（iter3 は 0.949 で頭打ち、”magic は 2 iter まで”）。

③ 10 メンバーの設計多様性 SED-head CNN（regnety_032 / eca_nfnet_l0 / v2s）×6 ＋ MLP-head CNN ＋ Amphibia/Insecta スペシャリスト（XC 拡張 41,127 サンプル/1,903 種）＋ genus スペシャリスト ＋ Perch v2 native。 genus（属）スペシャリスト：過密 SC で区別不能なレア両生類に「属の信号」を撒く（同属の最大ラベルで学習し、予測を同属全種へ broadcast）。0.96+ で詰まったとき +0.001〜0.002。私の sonotype mirror と同じ発想を、学習段階で実装した上位互換。 追加 XC/iNat データは（スペシャリスト以外）一貫して悪化したのでコンペデータのみ使用。窓は 5 秒が最適（20s は今年は劣化）。

④ 検証と後処理 Site-22 split（未知サイト汎化）＋ greedy split（種カバレッジ最大化）の 2 split を平均して調律。「validation で決めた学習パラメータは、LB 用に再調整したものよりむしろ良かった」＝LB プロービングを断った。 後処理は fine-tuned 系と Perch native 系で別々に調律（calibration が違うため）。最終は各クラス列を rank 変換してから fine-tuned 0.8 ＋ Perch native 0.2 で blend。 Perch は単体 ~0.9（凡庸）だが native 予測が ensemble に必須で、boost の大半は非 LSS 種から来た（GroundTruth がない種を Perch が担った）。

2nd Solution
① あえて Perch 蒸留を「捨てた」
序盤に Perch 蒸留で各 backbone +0.02 を得たが、モデル間相関が著しく上がるのを見て蒸留を一切やめた。アンサンブル余地を守るための判断。 ＝1 位（蒸留を再蒸留 seed で多様化）と正反対のアプローチで、同じ「脱相関を守る」目的に到達。両者とも diversity を最優先した。

② 5 ラウンドの反復擬似ラベル（mixup→置換が転機）
単体 LB/PB の推移：comp のみ 0.881/0.869 → focal PL 0.917/0.910 → SC PL r1 0.919/0.926 → r2 0.922/0.929 → r3 0.934/0.933（2025 2 位の XC 事前学習 backbone 投入で 0.930 突破）→ r4 0.938/0.935（AUC+0.25BCE loss）。 転機 = round2 で「SC を labeled へ mix する」のをやめ「置換（50→60%）」に切替。さらに毎ラウンド backbone を変える（NFNet→Effnet→v2s…）ことで self-iter の lock-in を回避＝私が踏んだ罠を構造的に避けた。 pseudo-power はラウンド別（BCE: 1.55/1.0/1.2/1.2/1.2、AUC+BCE: 1.0）。

③ loss と pooling の発見
序盤は BCE 一択。終盤に soft AUC loss + 0.25 BCE が最良メンバーを生んだ（4 位の AUC loss、私の exp332 AUC aux と符合）。 GeM pooling は A/B で毎回悪化し average pooling に。我々は GeMFreq+AttBlock を採用しており、ここは判断が分かれた点。ViT は 0.9 を超えず、Convnext/PaSST は推論時間で 90 分に載らず不採用。

④ アンサンブル戦略（最重要）
最終 7 メンバーほぼ等重み（相関の高い r3-r4-r5 だけ僅かに下げる）。相関表は Perch が全メンバーと ~0.4-0.5 と低く、脱相関の核だった。 検証は私と同じく LB を主信号にした（labeled SC AUC の相関は ~0.2 のみ）。にもかかわらず崩れなかったのは、等重み＋多様性という「構造」で robust 性を担保したから。本人いわく「重み付けを攻めたサブだけが PB で劣化した。等重みと LB 過学習施策の少なさ（＋少しの運）に救われた」。

3rd Solution
2 系統（Perch KD + 2025 2 位 FT）を 特徴・backbone・レシピすべてで最大限に違えることで大きな gain。
seresnext26t（mel256）と efficientnetv2_s（mel128）のペアが最も効いた。
sampling 戦略を最重視（レア種 upsample・focal/SC 比・site weight）。prior fusion + per-file refinement。


4th Solution
Perch + 2 つの自前 SED + 2 つの Perch 蒸留 SED の 5 モデル。
rank-gating：Perch を種ランキングのプロトタイプとして使い、弱い SED の false positive を抑制。


5th Solution
HGNetV2-B0 / EffNetV2-S / EffNet-B3 の Perch 蒸留 SED ＋ ProtoSSM ＋ Distilled SED。Diversity Is All You Need を掲げ、mel パラメータを最小化して推論を速くし、より多くのモデルを積んで分散を下げた。
周波数フィルタ aug を、通常の dB 加算ではなく dB × linear_gain（dB 領域での乗算）で実装。物理的には無茶苦茶（-80dB が ×2 で -160dB になる）だが、この「狂ったスケーリング」が +0.01 の汎化をもたらし、private に驚くほどフィットした。



私のアプローチと上位（特に1,2位）ソリューションとの比較は下記となります。

アプローチ	上位（特に 1〜2 位）	私のアプローチ
反復擬似ラベル	中核の勝ち筋。0.935→0.950 を実現（自己学習の調律で蒸留 base でも機能させた）	実験8連敗で完全に断念。teacher 強化＝保守化で LB 単調悪化、1回の疑似ラベルが大域最適だった
モデル多様性	backbone・head・ラベル空間・入力を変えた 9〜10 メンバー。genus / insecta スペシャリスト	Perch 2 系統 + SED 2 系統が中心。精度の低いモデルのアンサンブルはLB悪化になり断念
蒸留の扱い	1 位は積極活用＋多様性で相関を打ち消す。2 位はあえて不使用	Perch 蒸留が土台。だが蒸留と擬似ラベルが冗長になり自己学習を殺した（1 位が解決した課題を解決できず）
OOF/PublicLBでの検証	1 位は Site-22 / greedy の 2 split で後処理を調律、LB に頼らない	labeled SC 66 ファイルの OOF が LB 非転移。判断を直接 LB 提出に依存（過学習リスク）
アンサンブル戦略	等倍重みで robust。重み付けを攻めると private 劣化（2 位の自己分析）	cross-stack weight / rank-blend を grid で攻めた。public への適合度は高いが robust 性は劣る

ではなぜ各アプローチにおいて上位のような戦略をとれなかったのか。個別の深堀は下記となります。

深掘り A：蒸留をめぐるアプローチ
蒸留は「単体を強くするが、モデル間相関を上げてアンサンブルを殺す」両刃の剣となります。 1位・2位・私はこのアプローチの使い方が明確に分かれました。

チーム	蒸留の扱い	相関対策	結果
1 位	使う。だが head/label ごとに seed 違いで再蒸留	蒸留 loss 非ゼロ＋設計多様性で相関を能動的に下げる	強い単体 ×10 メンバーで脱相関も確保
2 位	捨てる（相関が上がるのを嫌って）	蒸留しないので自然に脱相関	等重き 7 メンバーで PB 無崩壊
私	使う（Perch v2 蒸留が土台）	相関対策なし（多様な member を積めず）	高相関な少数 member ＝ 薄く脆いアンサンブル

私は蒸留の「良いとこ取り」ではなく「悪いとこ取り」をしていました。 蒸留で相関を上げておきながら（1 位と違い）それを多様性で打ち消さず、かつ蒸留を捨てて自然な脱相関を得る（2 位の道）でもなかったということです。 結果、高相関なモデルを少数だけ束ねるという、アンサンブルにとって最も不利な状態に陥りました。 私の実験で「member は他 member 強化後に冗長化する／cross-family は worse-model noise」という負の知見は正しかったが、 それは「蒸留 base で多様性を作る方法を見つけられなかった」ことの裏返しでもありました。 1位は再蒸留seedという安価な答えを持っていました。

深掘り B：反復擬似ラベルの失敗と多様性の失敗
私の pseudo iteration は exp251 の self-iter（HGNet→HGNet）で representation lock-in し、その後teacher を強くする 8 軸すべてで敗れました。 一方 2位は毎ラウンド backbone を替えて（NFNet→Effnet→v2s）lock-in を回避し、5 ラウンド回し切りました。 つまり 「多様な backbone を持てなかったこと」が、そのまま「pseudo を反復できなかったこと」に直結していました。 多様な teacher があれば multi-teacher iteration で lock-in を避けられはずです（2 位の道）。 私は単体強度に予算を全振りした結果、アンサンブルの幅も、自己学習の反復も、同時に失ったということになります。 なぜそうなったのかというと、私もコンペ中盤までは多様なbackboneモデルをアンサンブルするアプローチをとっていたものの、それらを凌駕するsingleモデルを作れてしまったときに見誤りました。

| (4) コーディングAI活用

このコンペでの取り組みは、最初から最後まで Claude Code との協働で運用しました。これまでも部分的にKaggleにコーディングAIは用いていましたが今回初めてほぼコード自体を書くことはしませんでした。 私はDS/MLの判断（仮説・次に攻める軸・採否）を担い、Claude Code が 実装・分析・記録・Kaggle 運用を一気通貫で自動化しました。アイデアが枯渇したり実験が止まることはなく、コンペ中340回の実験を行うことができました。

やり取りのスタイル — 仮説駆動の高速ループ
– 会話は一貫して「仮説 → 1 差分の実装 → 提出 → LB で判定 → 知見を言語化」のループとなりました。1 回の提出で 1 つの軸だけを動かす規律を徹底し、 交絡を排して「効いた/効かなかった」を構造的理由まで圧縮して残しました。
提出結果から「期待 % のどこに着地したか」を毎回事後評価し、次の一手の確率を更新
– 負の知見も同格に記録：reject も「なぜ効かないか」を 1 文に圧縮（例：teacher 強化 8連敗 → pool species 被覆が leading indicator）。同じ失敗を二度踏まないための資産化。
wall-clock を常時監視
– CPU 90 分制約下で「wave 数 = ceil(ONNX/4core)」というコスト構造をもとにtimeout を外挿で予測してから提出。
Skills — 競技フローを 7 つの再利用可能な手順に
– 今回あらためてKaggle参加用に 7 つの Skill を定義し、定型作業を呼び出し 1 つで実行できるようにしました。(以下詳細)

これはスタンダードな運用のため、他の参加者と大きな差はついた要因ではないと思います。今回の参加を通してアップデートしたい点もあります。

Skill	役割
setup	データ DL、competition_overview.md / data_specification.md の自動生成
eda	探索的分析を analysis/anaXXX/ に保存（分布・相関・種構成など）
baseline	src/ 共通モジュール初期化と最初のベースライン実験作成
experiment	仮説に基づく新実験の設計→コード→実行→結果記録を一貫実施
analyze-notebook	公開 NB を解析し、移植可否を insights.md に記録
review	これまでの実験を総括し次の方針を提案（行き詰まり時のリセット）
submit	提出前検証（行数・カラム・NaN/Inf）→ Kaggle submit → スコア記録

各 expXXX/ の中身は以下となります。 – README.md — 仮説・結果・考察
– config.yaml — パラメータと seed
– inference.py — Kaggle 単体実行可能な推論
– models/, logs/, OOF 予測
– dataset-metadata.json — Kaggle Dataset 化用

また各実験後に実験単位のREADMEのほか以下2 つの俯瞰ドキュメントを更新していきました。
– experiment_log.md（347 行）— 全実験の 1 行サマリ台帳（やったこと＋LB＋結論）
– insights.md（511 行）— 核となる知見・構造的パターン・致命的に避けるべき設計判断

その他、重要な分析結果、つまり人間の目でも確認すべきものは.mdではなく、.htmlでレポート作成しました。結局コーディングAIにとって.htmlは非常に理解しやすく、.mdだと可読性が.htmlより劣るので、分析レポート作成のhtmlアウトプットは重宝しました。

[.mdファイル]あまり人間の目ではチェックしないもの


[.htmlファイル]人間の目でチェックしてアイデアを練るためのもの

※「1年ぶりのSOTA更新」などおかしな記述があるのはご愛嬌として、。


Kaggle 運用が自動化できた点も非常に良かった点です。学習→Dataset 化→Notebook push→submit→スコア記録の提出パイプラインを Skill 化することで高速に実験を行うことができますしミスを減らすこともできます。

総じて役割分担が肝でした。1 位の総括「Kaggle の仕事はソフトウェア（機械的なコード書き）と DS/ML（新規アイデア）に分かれ、エージェントは前者を見事に自動化するが、後者では人間に分がある」は、私含め多くの参加者が感じたことだと思います。 Claude Codeのおかげで0.958（public 金圏）まで積み上げる推進力になった一方で、上位を分けた独自の DS/ML 洞察に最後まで届かなかったことも、この分業の限界、つまりは私自身のDS力不足といえると思います。

| (5) 総括・今後に向けて

反省点は上位ソリューションとの比較の前章で述べたため、ここではよかった点含めた総括を記載します。本コンペはShakedownしたものの得たものもありました。

・Public金圏、過去最高順位でfinish
Publicで駆け上がることに執着したことは敗因でもあるのですが、それでもこれまで参加したコンペで一番粘ることができました。コンペ終盤では金圏ボーダーは数時間以内に順位が大きく変動する展開でしたが、最後の2,3日はずっと金圏にいることができました。正直に言えばかなりの期待感を持って最終日を迎えましたし、朝9時前の出勤中の電車での高揚感は他で味わうことができないものでした。それだけにPrivate結果が発表されたときは大きく落胆しました。ただそれでも実はShakeが起きることを見越して、最後の2,3日はShakeが起きるとしたらどのようなパターンがありえるかをClaudeCodeとディスカッションして、保険のSubmitを作成、結果的にはPublicベストではなく、その保険のsubmitのおかげで、まだshakeを耐えることができた、という点は良かった点でした。

・ClaudeCodeを用いたKaggle参加の自分なりの一連のワークフローを構築できた
人によってさまざまなやり方があると思いますし、自分のワークフローも次回に向けて手直ししたい点はあるものの、いったんのbaselineといえる環境構築ができた点はよかったところです。今回は些細なコード変更もClaudeCodeに指示してその変更ログを記載させ、自分はアイデアだしと方針を決めることに徹しました。よく言われる点ですが、まだまだ現時点ではコーディングAIのアイデア出しや判断は誤っている、不十分な点も多かったです。現にこのコンペ中ClaudeCodeに言われたセリフTop3は「すでにこのアプローチは限界に達しています」「もはやこれ以上の改善の見込みは望めません」「これまでの失敗パターンと完全に一致しました」でした。そして重要なことはこのようなセリフは無視して自分の方針を立てることでした。これはある意味サービス設計としては適切かもしれず、ユーザ体験を満足いくものにしてほしいためにはそれなりのところで撤退して現実的なラインで完成させてあげたいのかもしれません。しかしそれはKaggleには適しません。このようなClaudeCodeの諦めの早さやアイデアだしの不足は、はもしかしたらCLAUDE.md含めた設定や、現在のLBでの状況などをインプットすることで改善できる部分かもしれません。

本記事執筆時点でsilver11枚、bronze9枚。メダルは20枚になりましたがSilverコレクターの道は続きます。以上、BirdCLEF+2026コンペの振り返りとなります。

• 深層強化学習を駆使してカタン最強プレイヤー達に挑んでいく。 2019.3月.16 に投稿された | カテゴリ: data
• Chromeの閲覧履歴を取得する。 2015.1月.10 に投稿された | カテゴリ: data
• Kaggleのtitanic問題で上位10%に入るまでの環境構築とデータ分析 2016.10月.22 に投稿された | カテゴリ: kaggle
• 検証：”データサイエンティスト”から”分析”をとると何者になるのか。 2017.7月.8 に投稿された | カテゴリ: data
• Kaggle Haliteコンペ参戦振り返り（Bronze） 2020.10月.14 に投稿された | カテゴリ: kaggle