はじめに
生成AIを使っていると、ふと不思議な感覚になることがあります。
文章が、最初から決まっていたように出てくる。
でも実際には、一文字ずつ、あるいは単語のような単位で、次に来そうな内容を選びながら進んでいる。
この動きは、台風進路予測に少し似ているのではないでしょうか。
台風の進路も、未来の一点を断定しているわけではありません。現在の観測データをもとに、複数の可能性を計算し、その中からもっともありそうな進路を示します。さらに、時間が経つごとに観測データが更新され、予測も修正されていきます。
本稿の仮説は、次のとおりです。
生成AIの文章生成と台風進路予測は、対象はまったく違うものの、「現在の状態から未来の候補を確率的に推定し、可能性の高い方向へ収斂させる」という抽象構造が似ている。
ただし、同じ仕組みだと言いたいわけではありません。
台風予報は物理法則に基づく数値シミュレーションであり、LLMは言語データのパターンを学習した確率モデルです。この違いを雑に扱うと、かえってAI理解を誤ります。
そこで本稿では、似ているところ、違うところ、そしてこの比喩から得られる実務上の示唆を整理します。
1. 生成AIは「次に来そうな内容」を逐次的に選んでいる
まず、生成AI側の前提を確認します。
ChatGPTのような大規模言語モデルは、入力された文章をそのまま「文字」として扱うのではなく、トークンと呼ばれる単位に分割して処理します。トークンは、単語、単語の一部、記号、空白などを含む単位です。OpenAIの説明では、モデルは入力をトークンに分割し、処理し、生成されたトークン列を再び文章として返します1。
また、OpenAIはChatGPTの仕組みについて、学習中に大量のデータ内の関係性を分析し、応答生成時には次に来る可能性の高い語を一語ずつ予測すると説明しています2。
ざっくり言うと、生成AIは次のような処理を繰り返しています。
入力文脈
↓
これまでのトークン列を読む
↓
次に来そうなトークン候補を確率で並べる
↓
候補から1つを選ぶ
↓
選んだトークンを文脈に追加する
↓
次のトークンをまた予測する
ここで重要なのは、AIが最初から完成原稿を一括で取り出しているわけではない、という点です。
もちろん、最近の推論モデルでは内部的な推論過程や追加の処理が入る場合もあります。しかし、文章として出力される段階では、基本的にはトークン列を順に生成していきます。
このため、生成AIの文章には次の特徴が出ます。
| 観点 | 内容 |
|---|---|
| 文脈依存 | 直前までの内容によって次の候補が変わる |
| 確率性 | 同じ入力でも異なる出力になりうる |
| 逐次性 | 一度出した内容が、その後の文脈を拘束する |
| 誤差伝播 | 途中の誤った前提が、その後の文章をもっともらしく歪める |
この「逐次的に候補を選びながら未来を作る」感じが、台風進路予測との比較ポイントになります。
2. 台風進路予測も「一点の断定」ではなく「幅を持った予測」である
次に、台風進路予測を見ます。
気象庁は、数値予報について、観測データをもとに地球大気や海洋・陸地の状態を格子に分け、物理学や化学の法則に基づいて将来の状態を計算するものだと説明しています3。
台風予報でよく見る「予報円」も、中心線を台風が必ず通るという意味ではありません。気象庁の用語説明では、予報円は台風や暴風域を伴う低気圧の中心が予報時刻に到達すると予想される範囲を円で示したもので、中心が予報円に入る確率はおよそ70%とされています4。
つまり、台風予報は次のような情報を同時に示しています。
| 表示 | 意味 |
|---|---|
| 予想進路 | もっとも確からしい中心の移動方向 |
| 予報円 | 中心が入る可能性の高い範囲 |
| 暴風警戒域 | 台風が予報円内を進んだ場合に暴風域へ入るおそれのある範囲 |
| 確率情報 | 予測には不確実性があること |
さらに気象庁は、アンサンブル予報という手法も説明しています。これは、少しずつ異なる初期値を多数用意して複数の予報を行い、その平均やばらつきから気象現象を確率的に捉える方法です5。
台風アンサンブルの情報カタログでは、アンサンブル予報の手法を用いて5日半先まで計算した予測値が、台風の予報進路や予報円の大きさを決める際に使われると説明されています6。
ここで見えてくるのは、台風予報もまた、未来を一点で断定していないということです。
現在の観測データ
↓
物理モデルに投入
↓
複数の未来シナリオを計算
↓
ばらつきと平均を見る
↓
もっともありそうな進路と不確実性を示す
この構造は、LLMの文章生成とかなり似ています。
3. 似ているのは「候補空間を狭めていく」考え方である
生成AIと台風進路予測の共通点を、抽象化して並べるとこうなります。
| 比較軸 | 生成AI | 台風進路予測 |
|---|---|---|
| 現在状態 | プロンプト、会話履歴、生成済みトークン | 観測データ、気圧配置、海面水温など |
| モデル | LLMの重み、Transformerなどの構造 | 数値予報モデル |
| 候補 | 次に来るトークン候補 | 将来の進路候補 |
| 不確実性 | 各候補の確率分布 | 進路のばらつき、予報円 |
| 更新 | 新しいトークンが出るたびに文脈が更新される | 新しい観測データで予測が更新される |
| 失敗の形 | ハルシネーション、文脈の誤読 | 進路の外れ、強度予測の誤差 |
共通しているのは、「未来を直接知っている」のではなく、「現在までに得られている情報から、次に起こりそうなことを推定している」という点です。
AIが文章を作るとき、次に来る候補は1つではありません。
例えば、次の文があるとします。
明日の会議では、まず
この後には、いろいろな候補があります。
| 候補 | ありそうな続き |
|---|---|
| 議題 | 明日の会議では、まず議題を確認します |
| 進捗 | 明日の会議では、まず進捗を共有します |
| 目的 | 明日の会議では、まず目的を整理します |
| 課題 | 明日の会議では、まず課題を洗い出します |
どれも不自然ではありません。
文脈によって、どれがもっとも自然かが変わります。
台風進路も同じように、将来の進路候補は1本ではありません。偏西風の位置、太平洋高気圧の張り出し、周辺の気圧配置、海面水温などの条件によって、北寄り、西寄り、速度変化などのシナリオが変わります。
この意味で、両者はどちらも「候補空間」を持っています。
AIの候補空間
次の単語・表現・文脈展開の可能性
台風の候補空間
将来の位置・速度・強度・進路の可能性
そして、情報が増えるほど、候補は絞られていきます。
AIの場合は、生成済みの文章が増えるほど、次に来る表現の候補が狭まります。
台風の場合は、観測時刻が進むほど、新しい実測値によって進路予測が更新されます。
ここが、今回の比喩のいちばん面白いところです。
4. ただし、決定的に違うのは「物理世界を予測しているか、言語空間を生成しているか」である
一方で、この比喩には限界があります。
生成AIと台風予報を、同じものとして扱ってはいけません。
違いは大きく分けて3つあります。
違い1. 台風予報は物理法則に強く縛られる
台風は現実の大気現象です。
気象庁の数値予報は、物理学や化学の法則に基づいて将来の状態を計算します3。
つまり、台風予報には外部の現実があります。
予報が外れたかどうかは、後から観測によって検証できます。
一方、LLMの文章生成は、主に言語データ内の関係性を学習したモデルによる出力です。Transformerの代表的な論文である「Attention Is All You Need」では、再帰や畳み込みではなく注意機構に基づくアーキテクチャが提案され、機械翻訳などで高い性能を示しました7。
LLMは言語のパターンを扱えますが、出力が現実に対応しているかは、モデル単体では保証されません。
ここが、ハルシネーションにつながります。
違い2. 台風予報は不確実性を見せるが、AIはしばしば一本の文章として出す
台風予報では、予報円という形で不確実性が可視化されます。
「この線を必ず通る」のではなく、「この円の中に中心が入る確率がおよそ70%」という表現です4。
一方、生成AIの回答は、通常は一本の完成文として出てきます。
台風予報
→ 予報円で不確実性を見せる
生成AI
→ 自信ありげな文章で不確実性が隠れやすい
ここが実務上のリスクです。
AIの回答にも、本当は「予報円」に相当する不確実性があります。
しかし、ユーザーの画面には、その不確実性が見えにくい。
そのため、AIの出力は「断定文として読まれる確率予測」になりがちです。
違い3. 台風は未来へ進むが、AIは出力した文脈に自分で縛られる
台風は物理現象として進みます。
予測がどうであれ、台風そのものは現実世界の力学に従って移動します。
一方、AIは自分が出したトークンを次の入力文脈に含めます。
つまり、一度出した言葉が、次の言葉の前提になります。
このため、AIには次のような挙動が起きます。
最初の小さな誤解
↓
それに合う説明を続ける
↓
文脈として整合して見える
↓
しかし、現実とはズレている
これは、文章生成における誤差伝播です。
台風予報にも初期値の小さな差が将来大きく広がるカオス性があります。気象庁も、初期値の小さな差が時間とともに拡大することをアンサンブル予報の説明で述べています5。
AIの文章生成でも、序盤の小さな前提ミスが後続の文章全体を歪めることがあります。
ただし、台風の場合は現実が後から訂正してくれます。
AIの場合は、人間が検証しない限り、もっともらしいまま進んでしまうことがあります。
5. AIにも「予報円」を持たせて読むと、使い方が変わる
この比喩から得られる実務上の示唆は、かなり明確です。
AIの回答を読むときは、完成文だけを見るのではなく、その背後にある「候補の幅」を想像した方がよい、ということです。
例えば、AIが次のように回答したとします。
このエラーの原因は、認証情報の不一致です。
このとき、台風予報的に読むなら、こう捉えます。
最有力候補
認証情報の不一致
予報円の中にある候補
トークン期限切れ
API権限不足
ネットワーク制限
サーバー側障害
クライアント側キャッシュ不整合
AIの出力は、中心線です。
しかし、実務で見るべきなのは、中心線だけではありません。
むしろ重要なのは、予報円です。
| AI回答の読み方 | 台風予報での対応 |
|---|---|
| 断定文 | 予想進路の中心線 |
| 代替仮説 | 予報円内の別ルート |
| 信頼度 | 予報円の大きさ |
| 追加確認 | 新しい観測データ |
| 再プロンプト | 予報更新 |
この考え方を使うと、AIへの指示も変わります。
悪い聞き方は、いきなり結論だけを求めることです。
この障害の原因は何ですか？
よい聞き方は、候補と不確実性を出させることです。
この障害の原因候補を、可能性が高い順に5つ挙げてください。
それぞれについて、根拠、確認方法、外れていた場合の次の仮説も整理してください。
これは、AIに「予報円」を描かせる使い方です。
さらに、次のように聞くと精度が上がります。
前提が不足している場合は、断定せずに不足情報を列挙してください。
現時点の情報だけで判断できることと、追加確認が必要なことを分けてください。
AIの回答を、一本の進路図として読むのではなく、確率分布として読む。
この姿勢が、AI活用ではかなり重要になります。
おわりに
生成AIの文字推測と台風進路予測は、対象もモデルも違います。
台風予報は、物理法則に基づいて大気の未来を予測するものです。
生成AIは、学習した言語パターンをもとに、次に来るトークンを生成していくものです。
それでも、抽象化すると似ている部分があります。
どちらも、現在の情報から未来の候補を計算します。
どちらも、候補には幅があります。
どちらも、初期条件や文脈の小さな違いが、後の結果に影響します。
どちらも、もっともらしい一本の線だけを見てしまうと、不確実性を見落とします。
だから、AIの回答にも「予報円」があると考える。
これが本稿の結論です。
AIの出力は、完成された答えではなく、確率的に選ばれた有力ルートです。
その周辺には、別の候補、外れた場合の仮説、確認すべき観測データがあります。
次にAIを使うときは、こう聞いてみるとよいです。
この回答の予報円を広げてください。
最有力の答えだけでなく、代替仮説、確認方法、外れた場合のリスクも整理してください。
AIを使うとは、答えを受け取ることではありません。
予測の中心線と予報円を見ながら、人間が次の観測を設計することです。
参考
-
OpenAI Help Center「What are tokens and how to count them?」。OpenAIモデルが処理するテキスト単位としてのトークン、および入力から出力までのトークン処理の説明。 (OpenAI Help Center) ↩
-
OpenAI Help Center「How ChatGPT and our foundation models are developed」。ChatGPTがデータ内の関係性を学習し、応答生成時に次に来る可能性の高い語を予測するという説明。 (OpenAI Help Center) ↩
-
気象庁「数値予報とは」。観測データと物理・化学法則に基づき、将来の大気や海洋などの状態を計算する数値予報の説明。 (気象庁) ↩ ↩2
-
気象庁「気圧配置 台風に関する用語」。予報円の定義、および台風や低気圧の中心が予報円に入る確率がおよそ70%であることの説明。 (気象庁) ↩ ↩2
-
気象庁「アンサンブル予報」。初期値の誤差、数値予報モデルの不完全性、複数予報によって確率的に現象を捉える考え方の説明。 (気象庁) ↩ ↩2
-
気象庁情報カタログ「台風アンサンブル」。台風アンサンブルが、台風の予報進路や予報円の大きさを決める際に用いられることの説明。 (氣象庁データ) ↩
-
Ashish Vaswani et al.「Attention Is All You Need」。Transformerアーキテクチャを提案した代表的論文。 (arxiv.org) ↩