富山県ホタルイカ身投げAI予測モデルを作った (地域別推定)

GPT5.5-Thinking より:

読みました。結論から言うと、**趣味記事としてはかなり良いですが、「予測精度がこの程度ある」と強く主張するには危ない点が多い**です。特に突っ込まれそうなのは、モデルよりも **教師データの作り方と検証方法** です。

## 一番大きい突っ込みどころ

### 1. 掲示板投稿ベースなので、「ホタルイカの発生」ではなく「人間の投稿行動」を学習している可能性がある

掲示板の全投稿をスクレイピングし、LLMで「場所・量・日付」を抽出して教師データにしている構成ですが、これはかなり面白い一方で、データの性質としてはかなり歪みます。記事中でも、地名の伏字、投稿の曖昧さ、嘘投稿の存在を認めています。([たつろぐ | tatuiyoWebServer – 自宅鯖とかの技術系ブログ][1])

特に問題なのは、

* 採れた人ほど投稿しやすい
* 採れなかった日は投稿されないことがある
* 人気地点ほどデータが多い
* 「湧いた」ではなく「誰かが行って採れた」を見ている
* 嘘投稿や誇張投稿が混ざる

という点です。

そのため、厳密には「ホタルイカ身投げ発生モデル」ではなく、**掲示板上で報告される採集成功の予測モデル** に近いです。記事内でも Location 2 が721件、Location 5 が58件と地域差が大きいので、地域別比較もそのまま自然現象の差とは読めません。([たつろぐ | tatuiyoWebServer – 自宅鯖とかの技術系ブログ][1])

### 2. 嘘投稿対策に90パーセンタイルを使うのは、むしろ逆効果になり得る

「同じ日・同じ地域の投稿群から90パーセンタイルで最終的な身投げレベルを確定」とありますが、これはかなり突っ込みどころです。([たつろぐ | tatuiyoWebServer – 自宅鯖とかの技術系ブログ][1])

90パーセンタイルは、低めの外れ値を無視して「その日の良かった側」を拾うには向いています。しかし、記事中で問題にしているのが **嘘の大量報告・誇張投稿** なら、90パーセンタイルはむしろその影響を拾いやすいです。

たとえば同じ日に、

“`text
0, 0, 1, 1, 6
“`

みたいな投稿があったとき、嘘の「爆湧き」投稿が上側にあると、90パーセンタイルはそれに引っ張られます。

ここは、より安全にするなら、

* 投稿数が少ない日は信頼度を下げる
* median / trimmed mean / winsorize を比較する
* 「採れた」「採れない」の二値は別集計する
* 量レベルではなく「1件以上の肯定報告あり」に落とす
* 同一IDや文体、連投、極端値を疑う

あたりを書いておくと、かなり説得力が増します。

### 3. 悪天候日を「湧きレベル0」として追加するのは、便利だが少し循環している

記事では「雨量30mm超または平均風速8m/s以上の日を湧きレベル0として追加」としています。([たつろぐ | tatuiyoWebServer – 自宅鯖とかの技術系ブログ][1])
これは実務的にはかなり合理的ですが、機械学習の検証としては注意が必要です。

なぜなら、**ラベルを気象条件から人工的に作って、その同じ気象条件で学習している** からです。モデルが「雨量30mm超なら0」「風速8m/s以上なら0」というルールを覚えれば、検証精度が上がります。

実運用上は役に立つルールですが、精度評価では、

* 人工追加データを除いた評価
* 人工追加データだけの評価
* 実投稿由来データだけの評価
* 人工データに低い重みを付ける

を分けた方がよいです。

ここは記事中で自覚的に「これは実質ルールベース補完」と書いておくと、かなり突っ込まれにくくなります。

## 検証精度まわりの突っ込みどころ

### 4. 検証データを使いすぎていて、報告精度が楽観的になっている可能性が高い

記事では、時系列順に80%を学習、20%を検証に使い、さらにその検証データで閾値と精度を決めています。加えて、特徴量を入れたり抜いたり、地域ごとのモデル選択や使用アメダス地点の選択もしています。([たつろぐ | tatuiyoWebServer – 自宅鯖とかの技術系ブログ][1])

これは典型的に、**検証データに合わせ込んでいる** 状態です。

たとえば、

* Location 2 は専用モデルがよい
* Location 4 は朝日アメダスより富山アメダスがよい
* 閾値は検証データでスイープして決める
* 特徴量の採否も試行錯誤で決める

という判断を全部同じ検証データでやってから、その同じ検証データのAccuracyやPrecisionを出すと、数値は高めに出ます。

公開記事としては、表の前に一文、

> なお、以下の精度は特徴量・モデル・閾値選択にも使った検証データ上の値であり、完全な未知データに対する推定精度より楽観的である可能性があります。

と入れるだけで、かなり誠実になります。

本当に検証するなら、最後の1年または最後の1シーズンを完全に封印して、そこで一発評価するのがよいです。

### 5. 予報運用時の精度は、検証精度より確実に落ちる

学習・検証では過去の実測気象データ、実運用ではOpen-Meteoの予報データや気象庁の波浪予報などを使っています。記事でも「予報データを用いた場合の精度は当然下がるはず」と書いており、ここは正しい認識です。([たつろぐ | tatuiyoWebServer – 自宅鯖とかの技術系ブログ][1])

ただ、ここはもう少し強く書いてもよいです。

実測値で作った特徴量と、予報値で作った特徴量は別物です。Open-Meteoは複数の数値予報モデルを組み合わせた時系列を返す仕組みで、日本ではJMA MSM/GSMなども選択肢に含まれますが、観測所の実測値そのものではありません。([Open Meteo][2])

なので、過去検証で80%近いAccuracyが出ても、実運用では、

* 降水量予報のズレ
* 風向・風速予報のズレ
* 波浪予報の粗さ
* 雲量・晴れ時間のズレ
* 観測所と海岸現地の差

で普通に落ちます。

ここは「バックテストには過去予報を使うべき」と書くと強いです。Open-Meteoにも過去の予報ランを検証・ML学習に使うためのHistorical Forecast APIやSingle Runs APIが案内されています。([Open Meteo][2])

## 特徴量まわり

### 6. 「晴れ時間」が通説と逆に効いたのは、モデルが因果ではなく相関を拾っている可能性が高い

記事では、夜に晴れている方が湧きやすい方向に効いていて、通説と逆だと書かれています。([たつろぐ | tatuiyoWebServer – 自宅鯖とかの技術系ブログ][1])

これはかなり面白いですが、解釈には注意が必要です。単純な「晴れ時間」は、月明かりそのものではありません。

本来見たいのは、

* 月齢
* 月の高度
* 月の出・月の入り
* 夜間の雲量
* 月が出ている時間帯だけの雲量
* 人間が出撃しやすい天気

あたりです。

たとえば「新月付近で晴れている夜」は、月明かりが少なく、かつ人間も出撃しやすいので、掲示板上の成功報告は増える可能性があります。この場合、「晴れ」がホタルイカに効いているというより、**新月期の好天と観測・投稿のしやすさ** を拾っているかもしれません。

### 7. 向かい風スコアは発想は良いが、海岸線形状と風向の定義が粗い

向かい風なら岸に寄るはず、という仮説で `風速 × cos(風向 – 目標方向)` を入れているのは良い特徴量設計です。ただし、目標方向を地図を見て手で設定しているので、かなり恣意的です。([たつろぐ | tatuiyoWebServer – 自宅鯖とかの技術系ブログ][1])

また、気象庁などの風向は通常「風が吹いてくる方向」なので、式の符号を間違えると、向かい風と追い風が逆になります。記事の式だけでは、そこを読者が確認できません。

ここは、

> 風向は「風が吹いてくる方角」として扱い、各海岸の沖側方位との差を取った

のように明記した方がよいです。

## 確率表示まわり

### 8. isotonic regression は良い選択だが、データが少ないと過学習しやすい

LightGBMの生スコアをそのまま確率として読めないので、isotonic regressionで確率校正した、という流れ自体は妥当です。([たつろぐ | tatuiyoWebServer – 自宅鯖とかの技術系ブログ][1])

ただし、scikit-learnの説明でも、isotonic regression は小さいデータでは過学習しやすく、十分なデータがある場合に向くとされています。([scikit-learn][3])

今回、地域別に見ると Location 5 は58件しかなく、Location 1や4も数百件規模です。さらに時系列検証の後半20%だけで校正しているなら、校正用データはもっと少ないはずです。したがって、表示される「40%」「70%」は、かなり粗い目安として扱うべきです。

記事には、

> 表示確率は厳密な発生確率ではなく、過去データ上で校正した相対的な期待度です。

と書いておくと安全です。

## 細かい表現・誤字・読者向けの直し

* 「LightGBMは決定木」とありますが、より正確には **決定木ベースの勾配ブースティング** です。単体の決定木ではありません。LightGBM自体もtree based learning algorithmsの勾配ブースティング系フレームワークです。([LightGBM][4])
* 「当日夜の腫れ時間」は誤字で、「晴れ時間」だと思います。([たつろぐ | tatuiyoWebServer – 自宅鯖とかの技術系ブログ][1])
* 「深層学習は不可能」は少し強いです。「このデータ量では深層学習を使う利点が薄い」くらいが妥当です。
* 「理解しなくても組めました」は記事としては面白いですが、確率校正の信頼性を語る節ではやや弱く見えます。ネタとして残すなら、その直後に「ただし校正用データが少ないため過信は禁物」と補うとよいです。
* 「先行研究の実用精度は不明だが、同じ掲示板を学習データとしているようなので大きく精度は変わらないはず」は少し雑です。モデル、特徴量、ラベル化、検証方法でかなり変わるので、「同じデータ源なら似た課題を抱えているはず」くらいが安全です。([たつろぐ | tatuiyoWebServer – 自宅鯖とかの技術系ブログ][1])

## 追記するとかなり強くなる内容

記事末尾か課題に、以下を入れると技術記事としてかなり締まります。

“`text
本モデルの限界：
このモデルは自然現象としてのホタルイカ接岸そのものではなく、掲示板に投稿された採集報告を教師データとしている。そのため、投稿者数・地点人気・出撃しやすい天候・虚偽投稿・報告バイアスの影響を受ける。また、検証には実測気象値を用いているため、実際の予報値を用いた運用精度は表中の検証精度より低下する可能性がある。
“`

さらに強くするなら、

“`text
今後は、2026年シーズンの予測を事前に保存し、後から掲示板投稿と照合することで、完全な未来データに対する的中率を評価する。
“`

と書くとよいです。

総評としては、**発想・実装・記事の面白さはかなり良い**です。ただし、技術的に厳しく見ると、現状の弱点は「LightGBMの性能」ではなく、**掲示板由来ラベルのバイアス、人工負例、検証データの使い回し、予報運用時の分布ズレ** です。ここを自覚的に書けば、かなり突っ込まれにくい記事になります。

[1]: https://tatuiyo.xyz/?p=1722 “富山県ホタルイカ身投げAI予測モデルを作った (地域別推定) – たつろぐ | tatuiyoWebServer”
[2]: https://open-meteo.com/en/docs “️ Docs | Open-Meteo.com”
[3]: https://scikit-learn.org/stable/modules/calibration.html “1.16. Probability calibration — scikit-learn 1.8.0 documentation”
[4]: https://lightgbm.readthedocs.io/?utm_source=chatgpt.com “Welcome to LightGBM’s documentation! — LightGBM 4.6.0 …”