生成AIによる天気図解析のアプローチと限界【第2部】 ― なぜAIは天気図を読み誤るのか

おさらい：自信満々のハルシネーション

第1部では、生成AIに天気図を解析させた結果、存在しない低気圧を捏造し、高気圧圏内なのに「広範囲で荒天」と予報するという致命的な誤りを観測しました。さらに恐ろしいことに、AIは自己検証フェーズでもその誤りを検出できず、「完全に整合している」と二重に嘘を重ねました。

では、なぜこのような失敗が起きるのか。プロンプトを工夫すれば直るのか、それとも現在のAIアーキテクチャに由来する構造的な限界なのか。本記事では、4つの観点から原因を掘り下げます。

本稿で言う「AI」「限界」の範囲について（重要なスコープ注記）

本稿が「限界」として論じるのは、ChatGPTやClaudeのような汎用のマルチモーダルLLMに、人間用に描画された天気図（PDF・画像）を読ませるというアプローチの話です。これは、近年「実用段階に入った」と報じられる専用のAI数値予報モデル（GraphCast／Pangu／AIFSなど）とはまったくの別物です。

後者は天気図の「絵」を一切読みません。人間向けにレンダリングされる手前の数値（ERA5などの再解析テンソル）を直接学習し、数値場から次時刻の数値場を生成します。台風進路を従来手法より約20%改善するなど、領域によっては人間（現業数値予報）を上回る精度を示しています。

つまり「LLMに天気図の絵を読ませると失敗する」ことと「AI数値予報が実用化した」ことは矛盾しません。両者は気象AIスタックの別レイヤーの話です。本稿の以下の議論は、断りのない限り前者（描画天気図を読む汎用LLM）に限定したものとして読んでください。この区別は、限界3（後述）で決定的に効いてきます。

4つの限界の「射程」をあらかじめ区別する

本記事で挙げる4つの限界は、すべてが同じ重さ・同じ普遍性を持つわけではありません。どのカテゴリのAIにまで効く限界なのかを、先に整理しておきます。

限界	性質	射程（どこまで効くか）
限界1：投影法の非互換	ビジョンモデル固有。画像を読むこと自体に起因	LLMで画像を読む場合に限る。数値を直接渡せば回避できる「入口設計」の問題
限界2：等値線のトレース困難	ビジョンモデル固有。同上	LLMで画像を読む場合に限る。そもそも数値を持っていれば線を追う必要がない
限界3：物理モデル・気候学的常識の欠如	カテゴリ依存	汎用LLMで画像を読む場合のみ成立。専用AI数値予報には当てはまらない（後述）
限界4：過剰な自信	モデル種別を問わず普遍的	あらゆる生成AIに効く。最も本質的で、回避が難しい

要点を先取りすると――限界1・2は「描画チャートをLLMに読ませる」という構成を選んだことに起因する、設計を変えれば避けられる問題です。限界3はAIのカテゴリ次第で、専用AI数値予報には当てはまりません。そして限界4だけが、モデルの種類を問わず普遍的に効く最も厄介な限界です。

この温度差を意識しながら、以下の各論を読んでください。

限界1：投影法の非互換性 ― 「地図」を地図として認識できない

気象庁の高層天気図は、ポーラーステレオ図法（60°N, 140°E基準） で描かれています。北極を中心とした平射投影で、緯度経度の格子は曲線として表現されます。

人間の予報士は、この投影法の歪みを頭の中で動的に補正できます。「この緯線のカーブから推して、ここは大陸奥地ではなく日本海だ」と。

ところが、AIの画像認識モデルは画像を2Dのピクセル配列として処理するだけで、座標変換を動的に行うエンジンを内部に持っていません。プロンプトで「ポーラーステレオ図法で解析せよ」と指示しても、内部にGIS（地理情報システム）が生成されるわけではないのです。

その結果、AIは画面上の「相対的な位置」をそのまま平面的に解釈し、

大陸上にある低気圧を九州付近に「ワープ」させて解釈する
緯度40度と50度を取り違える
等値線が日本にかかっているかどうかを誤判定する

といった空間認識エラーを起こします。実例で観測された「大陸の低気圧を九州付近にワープさせて荒天予報を生成した」現象は、まさにこの限界の典型です。

なお、これはビジョンモデルが画像を読むことそのものに起因する限界です。裏を返せば、座標や緯度経度を含む数値データを最初からテキストで渡してしまえば、この問題は原理的に発生しません。限界1は「読ませ方（入口設計）」の問題でもある、という点を覚えておいてください。

限界2：高密度な視覚情報の分解能力の低さ ― 「線をたどる」のが苦手

専門天気図には、等高度線・等温線・等相当温位線・風羽・前線記号などがラベルなしの曲線として無数に重なり合っています。

人間の予報士は、視線を一本の線に固定して端から端まで追う（トレースする）ことができます。AIは、これが極端に苦手です。

現在のビジョンモデルは、

独立した物体や文字の認識（例：「H」「L」「1018」というラベル）には強い
ラベルのない曲線を密集環境のなかで他の線と区別しながら追跡することは非常に苦手

そのため、線が密集する前線帯やトラフの解析において、AIはしばしば「この辺りに線が多いから前線帯だろう」というおおざっぱなテクスチャ認識で済ませてしまいます。これが、相当温位の傾度や渦度極大の位置を読み誤る根本原因です。

限界1と同様、これも「絵を読ませる」構成を選んだことに起因する問題です。そもそも等値線の元になった格子点数値を直接扱えるなら、線を目でトレースする作業自体が不要になります。

限界3：物理モデルと「気候学的常識」の欠如 ―― ただし“汎用LLMで画像を読む場合に限る”

人間の気象予報士は、流体力学や熱力学を理解したうえで天気図を読みます。だからこそ、

「地上が高気圧圏内（1018hPa）なのに、700hPaで強い上昇流？おかしい」
「4月の九州に真冬並みの寒気と996hPaの低気圧？クリマトロジー的にあり得ない」

といった物理的・気候学的な違和感（メタ認知） を自然に働かせられます。

描画天気図を読む汎用LLMには、これがありません。汎用LLMは大気の3次元グリッドを内部に持たず、流体力学の計算エンジンも備えていません。テキストの確率的な並びとして気象現象を「語る」だけです。

そのため、

上下の図面間で物理的に矛盾する解釈を平然と並列する
季節的に極端な値を「異常」と認識せず、そのまま出力する
自分の出力が自然法則と整合しているかを事後検証できない

という挙動になります。実例で観測された「高気圧の中心付近で寒冷前線が通過する」という記述は、人間なら一瞬で気づく論理破綻ですが、汎用LLMは矛盾に気づかず最後まで書き切ってしまいます。

重要な限定：これは「AI一般」の限界ではない

ここで強調しておきたいのは、この限界3が成立するのは「人間用に描画された天気図を、気象専用に訓練されていない汎用LLMに読ませる」という限定された場合に限るということです。「AIには物理が分からない」という一般命題に拡張すると、事実に反します。

実際、専用のAI数値予報モデル（GraphCast／Pangu／AIFS）は、上の3点をことごとく覆します（気象研究所・関山剛先生の講演に基づきます）。

3次元グリッドを「持たない」どころか、むしろそれが本体である。 これらのモデルは地球を3次元グリッドに分割して大気の状態を保持します。日本周辺を5kmメッシュで解像するストレッチドモデルのような実装もあります。「3次元グリッドを内部に持たない」のは汎用LLMの話であって、専用モデルはまさに3次元の状態場を持って時間発展させています。
物理パラメータの推定は、むしろ人間より上手とされる。 専用AI数値予報は、再解析データから物理的な振る舞いを学習しており、ある種のパラメータ推定では人間（従来の数値予報）を上回るとされます。
損失関数に物理を注入できる（Physics-informed）。 学習の目的関数そのものに物理的整合性を組み込むことで、出力が物理法則から外れないよう制約をかけられます。「物理を後付けで期待する」のではなく、設計段階で物理を織り込めるのです。
ブラックボックスでもない。 内部の状態を調べる技術が存在し、何を根拠に予報しているかをある程度追跡できます。「中身の分からない不透明な箱」というイメージは、必ずしも当たりません。

限界3のまとめ： 「物理モデルがない／3次元グリッドを持たない／矛盾に気づけない／ブラックボックス」という指摘は、汎用LLMで描画天気図を読む場合にのみ成立します。専用AI数値予報モデルには当てはまりません。本稿が扱っているのは前者なので限界3は本物の壁ですが、これを「AI全般の物理的限界」と読み替えてはいけません。カテゴリを混同すると、「AIは天気に使えない」という誤った一般化を招きます。

限界4：過剰な自信（オーバーコンフィデンス）

技術的には限界1〜3が本丸に見えますが、実害として最も危険で、しかもモデルの種類を問わず普遍的に効くのはこれです。限界1・2は入口設計で避けられ、限界3はカテゴリ依存でしたが、限界4はそうした逃げ道がありません。

大規模言語モデルは、「もっともらしく、流暢で、権威あるトーンで回答を生成する」ように学習・調整されています。内部で確信度が10%しかなくても、出力時には

「〜となります」
「〜が予想されます」
「〜と検証できました」

といった100%の自信を持った文章に変換されてしまいます。

これにより、ユーザーは「AIがどこまで本当に読めていて、どこからが推測か」を判別できません。第1部で観測した「完全に整合していると検証できました」という出力は、内部のあやふやな処理が自信満々のトーンで上書きされた結果でした。

ハルシネーションを最も危険なものにしているのは、事実誤認それ自体ではなく、それが自信のあるトーンで提示されることなのです。

「カラー化された地上天気図ならどうか」という現実的な問い

ここで一つの問いが立ちます。

ASASやFSASは文字情報があり、色分けされている。ポーラーステレオ図法での解析を明示的に指示すれば、地上天気図に限れば実用レベルになるのではないか？

これは半分正しく、半分は依然として限界があります。

期待できる改善点：

「赤い線（温暖前線）」「青い線（寒冷前線）」「中心気圧の数値」など、コントラストが強く、文字情報を伴う要素の抽出精度は確実に上がる
「低気圧が北海道の北にある」といった大まかな地理的配置の認識エラーは大幅に減る

依然として残る限界：

AI内部に動的なGISエンジンが生成されるわけではないため、緯度経度の厳密な座標変換は不可能
等圧線の本数や間隔から気圧傾度を定量的に読むタスクは引き続き苦手

つまり、「カラー＋文字情報が豊富な地上天気図」に絞れば、致命的な空間ワープを防ぐ確率は高まる。これは有効なリスクヘッジになります。

逆に、白黒で線が密集した高層天気図（FXJP854、FXFE502など）の視覚解析は、現時点では困難と割り切ったほうがよさそうです。

役割分担という発想 ― AIに何をやらせ、何を人間に残すか

これらの限界を踏まえると、自然と次の設計思想が浮かびます。

AIに「完璧な解析者」を期待するのをやめ、「データ抽出と理論的なチェックリストを提示するアシスタント」として位置づける

具体的には：

タスク	担当	理由
文字情報（中心気圧、台風諸元）の抽出	AI	OCR的処理は得意
カラー地上天気図の大まかな配置認識	AI	コントラストが強い
「次に確認すべき着眼点」の言語化	AI	テキスト生成は本領
高層天気図の等値線トレース	人間	ビジョンモデルの限界（限界2）
上下の物理整合性の最終判断	人間	描画図を読むLLMには困難（限界3）
気候学的な違和感の検知	人間	メタ認知が必要

この発想は次の第3部で、具体的なプロンプト設計とサービス実装に落とし込んでいきます。

補足：構造化プロンプトでハルシネーションは消えるか？

「AIに正確に読み解かせるための構造化プロンプト」をいくつか試した経験から言えるのは、プロンプト工夫だけで限界1〜4を克服することは、現時点では不可能ということです。

ただし、ハルシネーションが起きにくくなる方向に誘導することは可能です。鍵は次の3点。

「推測の禁止」と「読解不能の宣言」を強制する ― 「判読不能（Unreadable）」という出力を許す
AIにメタ認知させる ― 「この図のこの領域は線が密集していて確信度が低い」と最初に宣言させる
物理的・気候学的な矛盾検知を中核タスクにする ― 予報シナリオの創作ではなく、「データの破綻チェック」を主役にする

これらを盛り込んだプロンプト設計と、それでも残るリスクへの対処（ユーザーへの注意書き）は、第3部で具体的に扱います。

まとめ

現時点の生成AIが、描画天気図を読むという使い方で抱える限界は、プロンプト工夫の範囲を超えた構造的なものです。ただし、それぞれの限界がどこまで効くかは異なります。

限界1：投影法の歪みを動的に補正できず、地理位置を誤認する（ビジョンモデル固有。数値を直接渡せば回避可能）
限界2：密集した等値線をトレースできず、テクスチャ認識で済ませる（ビジョンモデル固有。同上）
限界3：物理モデルと気候学的常識がなく、自分の出力の矛盾に気づけない（汎用LLMで画像を読む場合に限る。専用AI数値予報は物理を学習しており当てはまらない）
限界4：内部の確信度に関わらず、常に自信満々のトーンで出力する（モデル種別を問わず普遍的。最も本質的）

これらを「次世代モデルで自動的に解決する」と楽観するのは禁物です――が、逆に「原理的に不可能で、数年単位で構造は不変」と断じるのも行きすぎでしょう。実際、専用AI数値予報の分野では、ECMWFのAIFSが多くの専門家の予測より速く現業化されるなど、AI気象技術は予想を上回る速度で進歩してきた前例があります。マルチモーダルLLMの図表読解力も、この例外とは限りません。

したがって本稿の立場は、「現時点では困難。ただし進歩速度を過小評価しないよう、定期的に再検証する」というものです。そのうえで、実務上の結論は揺るぎません――少なくとも今は「AIに完結させない設計」が必須であり、最後に嘘を見抜く責任は人間が手放してはならない、ということです。

次回は、これらの限界を前提としたうえで、AIを実サービスにどう組み込むか――Tenkiz Portのような気象アプリでの「副操縦士」としての活用設計を扱います。

続き → 第3部：実用化への道筋 ― 「副操縦士」としてのAI活用設計