台風位置に関する複数の情報の図解をChatGPTに依頼した

下記の記事で、複数のAIに、みちびき（準天頂衛星システム）の災害・危機管理通報サービスで提供された災害等の情報に基づく内容を地図上に表示した事例を紹介したが、今回は、台風９号の位置情報が複数得られ、それらの連続した位置情報に基づく図解を行ったので紹介する。

上記記事では、AIに情報の図解を依頼したが、その回答には、そのサービスから得られた情報だけでなく、AIが推測した内容も含まれており、AIに適切な指示を与えなければ、災害情報を表示するシステムには利用できないことを紹介した。
今回は、ChatGPT 5.5 Thinkingに、「サービスから提供された情報」だけを使用するように指示を行い、台風９号に関する複数の位置情報を与え図解してもらった。

---

（注）本記事の内容は正確性を保証するものではない。

（2026年7月9日 追記）YouTube動画を追加しました。　https://youtu.be/bHiPHSKlZEw

台風９号の位置に関する複数情報の図解

複数時刻（117時間後、93時間後、45時間後、12時間後、0時間後）の台風位置情報を記録することができたので、それらの図解を依頼した。

---

推測に基づく表示は行わないようにと指示したので、台風の位置は「点」で表示されており、その点の周囲には「円」も描かれていないので、添付画像の情報だけを使って忠実に描画されていることが分かる。連続した位置情報の描画という当初の目的は達成できた。
さらに、描画内容について追加質問を行った。

---

（補足）　何時間後までの予測を行うと決まっているのかを回答してもらいたかったが、位置情報の「予測範囲」についての回答が行われた。

はい。気象庁の台風情報としては「予報円」や「暴風警戒域」といった“予測範囲”に関する情報があります。
ただし、今回の添付画像に表示されている117時間後の情報には、その範囲情報は出ていません。

添付画像の「117時間後」から読み取れるのは、次の情報だけです。

項目	内容
基点時刻	13日15時00分、117時間後
位置	北緯31度50分0秒、東経115度0分0秒
中心気圧	994hPa
大きさ	なし
強さ	なし
最大風速	不明
最大瞬間風速	不明

気象庁の台風予報では、本来は各予報時刻について「台風の中心位置」、「予報円の中心と半径」、「中心気圧」、「最大風速」、「最大瞬間風速」、「暴風警戒域」などが扱われます。
予報円は「その時刻に台風の中心が入る確率が70％と予想される範囲」で、台風の大きさではなく、進路予報の不確実性を表すものです。(気象庁)

一方、今回のWebページ表示では、予報円半径・暴風警戒域・暴風域に入る確率などは表示されていません。
そのため、添付画像だけを根拠にして「117時間後の予測範囲」を円で描くことはできません。
描いてしまうと、画像にない情報を補ってしまうことになります。

図解に入れるなら、次のような注記が安全です。

117時間後：位置と中心気圧のみ表示。最大風速・最大瞬間風速は不明。予報円・暴風警戒域は添付画像からは読み取れないため図示しない。

なお、みちびきの災危通報は、気象庁が提供する防災気象情報を独自フォーマットに変換して送信する仕組みです。
したがって、元の気象庁XMLや台風詳細情報側には追加項目が存在する可能性がありますが、今回の抽出表示に出ていない項目は、図解では「未取得／未表示」と扱うのがよいです。(みちびき（準天頂衛星システム）)

---

はい、2つの意味で整理できます。

添付画像だけを見る場合
「何時間後まで予測する」という総括的な項目はありません。
ただし、各情報に 「基点時刻：○時間後」 が表示されているので、今回の画像では最後の地点が 117時間後 です。
したがって、この画像から言えるのは、

この表示データでは、台風9号の位置予測は 117時間後まで表示されている

ということです。

今回の5地点は次の流れです。

区分	基点時刻から	日時	内容
1	0時間後	7月8日18時	実況
2	12時間後	7月9日6時	予報
3	45時間後	7月10日15時	予報
4	93時間後	7月12日15時	予報
5	117時間後	7月13日15時	予報

みちびき災危通報のデータ仕様として見る場合
台風情報には 「基点時刻からの経過時間」 という項目があり、仕様上は 0〜127時間 の値を持てるようになっています。
つまり、災危通報の台風メッセージ自体には「何時間後の情報か」を表す項目があります。

気象庁の台風予報として見る場合
気象庁の台風予報は、現在は進路・強度ともに 5日先、つまり120時間先まで が基本です。
気象庁は2019年3月から、台風の強度予報も3日先から5日先までに延長しています。(気象庁)
また、気象庁の精度検証でも、中心位置の 24・48・72・96・120時間予報 が対象になっています。(気象庁データ)

今回の画像で最後が 120時間後ではなく117時間後 になっているのは、基点時刻が 7月8日18時、最後の予報時刻が 7月13日15時 だからです。
これは5日先に近い予報ですが、添付画像上では 117時間後が最終表示 なので、図解や記事では、

気象庁の台風予報は5日先、概ね120時間先まで。
ただし、今回取得した災危通報の表示では、最長は117時間後まで。

と書くのが安全です。

---

はい。今回のデータで、大陸上に進んだあと 中心気圧が 990hPa → 994hPa と高くなるのは、一般的には「台風が弱まっていく」ことを示します。

今回の5地点では、中心気圧は次のように変化しています。

時点	位置の概要	中心気圧
0時間後	フィリピン東方の海上	925hPa
12時間後	海上	925hPa
45時間後	台湾東方〜沖縄南西側の海上	935hPa
93時間後	中国大陸側	990hPa
117時間後	中国大陸内陸側	994hPa

原理

台風は、暖かい海面から供給される水蒸気をエネルギー源にしています。
水蒸気が雲になるときに熱を放出し、その熱で台風の中心付近の上昇気流や循環が維持・強化されます。
気象庁も、台風は暖かい海面から供給された水蒸気が凝結するときの熱をエネルギーとして発達すると説明しています。(気象庁)

ところが大陸上に進むと、海からの水蒸気供給がほぼ断たれます。
さらに、陸地は海面より摩擦が大きいため、低い高度の風の流れが乱され、台風のきれいな渦構造が崩れやすくなります。
気象庁は、上陸した台風が急速に衰える理由として「水蒸気の供給が絶たれること」と「陸地の摩擦でエネルギーが失われること」を挙げています。(気象庁)

その結果、台風中心部の強い上昇気流や低圧部を維持しにくくなり、中心気圧が上がる方向に変化します。
つまり、今回の図でいうと、

海上：925hPa〜935hPaで強い状態
大陸側：990hPa〜994hPaへ上昇し、弱化傾向

という読み方になります。

図解に入れるなら

地図の93時間後・117時間後あたりに、次の注記を入れると分かりやすいです。

大陸上では、海からの水蒸気供給が減り、地表摩擦も大きくなるため、台風は弱まりやすい。
そのため中心気圧は 990hPa → 994hPa と高くなっている。

注意点として、中心気圧が高くなる＝完全に安全になる、ではありません。台風が北上・衰弱する過程では、中心付近の風は弱まっても、強い風の範囲が広がる場合があります。気象庁も、台風が北上すると中心付近の風速は弱まる傾向に入る一方、強い風の範囲は広がることがあると説明しています。(気象庁)

---

いいえ、中心気圧が994hPaまで高くなったからといって、自動的に「熱帯低気圧になった」とは判定できません。

ポイントは、台風か熱帯低気圧かの判定基準は中心気圧ではなく、最大風速だという点です。

気象庁では、北西太平洋または南シナ海にある熱帯低気圧のうち、低気圧域内の最大風速、10分間平均でおよそ 17m/s以上 のものを「台風」と呼びます。
17m/s未満になると、台風ではなく「熱帯低気圧」と扱われます。(気象庁)

今回の画像で見ると、93時間後は中心気圧が 990hPa まで高くなっていますが、最大風速は 20m/s と表示されています。20m/sは台風の基準を上回るため、この時点ではまだ「台風」と考えられます。

一方、117時間後は、

項目	表示
中心気圧	994hPa
最大風速	不明
最大瞬間風速	不明
強さ	なし

となっています。

このため、添付画像だけから言えるのは、

117時間後は中心気圧が994hPaまで上がって弱まっている予想だが、最大風速が不明なので、熱帯低気圧になったかどうかは判定できない。

ということです。

また、画像の「強さ：なし」は、台風ではないという意味ではありません。
気象庁の「強さ」は、最大風速が 33m/s以上 の場合に「強い」「非常に強い」「猛烈な」と表現する区分です。
最大風速が33m/s未満なら、台風であっても「強さ」は表現されません。(気象庁)

つまり、図解や記事では次のように書くのが安全です。

中心気圧は925hPaから994hPaへ上昇しており、台風は弱まる傾向にある。
ただし、台風か熱帯低気圧かは中心気圧ではなく最大風速で判定される。
117時間後は最大風速が「不明」のため、添付画像だけでは熱帯低気圧化したとは判断できない。

---

ここでいう「摩擦の大きい陸地」は、地表面に凹凸や障害物が多く、空気の流れを乱しやすい陸地と考えると分かりやすいです。

専門的には、地表の「粗さ」を 地表面粗度 と呼びます。

摩擦が大きい陸地の例

陸地の種類	摩擦・乱れの大きさ	理由
山地・丘陵地	大きい	地形の起伏で風向・風速が乱れやすい
森林	大きい	樹木が風を受け、下層の流れを乱す
都市部	大きい	建物群が障害物になり、乱流が発生しやすい
農地・集落が混在する平野	中程度	畑、家屋、樹木、地形の小さな凹凸がある
砂漠・草原・広い平野	比較的小さい	障害物は少ないが、海面ほど一様ではない
湖面・海面	小さい〜中程度	表面は比較的一様。 ただし強風時は波で粗くなる

つまり、単に「土の地面だから摩擦が大きい」というより、山、森林、建物、樹木、地形の凹凸が空気の流れを邪魔するという意味です。

台風にとって特に影響が大きい陸地

台風が大陸に入ったときに弱まりやすいのは、主に次のような場所です。

山地や丘陵地では、台風の下層の渦が地形で乱されます。中心付近に向かって流れ込む風がきれいに回り込めなくなり、渦の形が崩れやすくなります。

森林や都市部では、地表近くの風が強く減速します。風が減速すると、台風中心へ流れ込む空気のバランスが変わり、中心付近の構造が乱れます。

内陸の平野部でも、海上に比べると地表は一様ではありません。農地、住宅地、河川、丘陵などが混在するため、海上のように滑らかなエネルギー供給と風の流れを維持しにくくなります。

今回の台風9号の図で言うと

93時間後、117時間後の位置は中国大陸側に入っています。ここでは、海上にいたときと違って、

暖かい海からの水蒸気供給が減る
＋
陸地の凹凸や地形で下層の風が乱れる

という2つの効果で、台風の構造が弱まりやすくなります。

その結果として、中心気圧が
925hPa → 935hPa → 990hPa → 994hPa
のように高くなる、つまり弱まる予想になっていると考えられます。

まとめると、ここでいう「摩擦の大きい陸地」は、特に 山地・丘陵地・森林・都市・農地や集落が混在する内陸部 のような、空気の流れを一様に保ちにくい地表です。

---

はい、できます。
ただし条件があります。現在のWebページを変更せずに実現するには、Webページに表示される前、または表示されている最中のデータを“横取りではなく別系統で保存する”仕組みを作るのが基本です。

一番よい構成は次の形です。

みちびき災危通報の受信データ
        ↓
現在のWebページ表示用データ
        ↓
現在のWebページ
  └ 最新10件だけ表示

同じ受信データ
        ↓
別の保存プログラム
        ↓
SQLite / CSV / JSONなどに蓄積
        ↓
別Webページで
同じ台風ごとに集約表示・地図更新

つまり、今のWebページはそのままにして、別の小さなプログラムで「流れてきた災害情報」を保存し続ける方式です。

できること

たとえば台風9号なら、流れてくる情報の中から次のような項目を抽出して保存します。

保存する項目	例
台風番号	台風9号
基点時刻	2026年7月8日18時
何時間後	0時間後、12時間後、45時間後、93時間後、117時間後
予報対象時刻	7月9日6時など
緯度・経度	北緯17度55分、東経130度30分
中心気圧	925hPaなど
最大風速	あれば保存
最大瞬間風速	あれば保存
受信時刻	そのデータを受け取った時刻
元データ	元のテキストやJSONをそのまま保存

これを保存しておけば、現在のWebページが最新10件で流れて消えてしまっても、別ページ側では、

台風9号の同じ基点時刻の予報情報をまとめて表示
位置を時系列で線で結ぶ
中心気圧の変化も表示
新しい情報を受信したら地図を更新

ということができます。

実現方法は3パターンあります

1. 受信データの元を別プログラムでも読む方法

これが一番おすすめです。

現在のWebページが、たとえば次のようなデータを読んでいるなら、その同じデータを別プログラムでも読ませます。

JSONファイル
CSVファイル
WebSocket
MQTT
HTTP API
ローカルのログファイル
シリアル受信データ

この場合、現在のWebページのコードは変更不要です。

別プログラムが同じデータを監視して、台風情報だけを保存します。

2. 現在のWebページが読んでいる通信を、別ページ側も読む方法

現在のWebページが内部で data.json のようなファイルを定期的に読んでいる場合は、別ページも同じ data.json を読めます。

現在のWebページ
  → data.json を読んで最新10件表示

別の集約ページ
  → 同じ data.json を定期確認
  → 新しい情報だけ保存
  → 台風別に集約

この場合も、現在のWebページは変更しません。

ただし、data.json 自体も最新10件しか保持していないなら、別ページ側の保存プログラムを常時動かしておく必要があります。
一度流れて消えた過去データは、あとから復元できません。

3. どうしても元データに触れない場合は、表示中のWebページを読み取る方法

最後の手段として、PlaywrightやPuppeteerのようなブラウザ自動操作ツールで、現在のWebページを定期的に開き、表示されている10件を読み取って保存する方法もあります。

ブラウザ自動巡回
        ↓
現在のWebページを定期的に読む
        ↓
表示中の10件から新規情報を抽出
        ↓
DBに保存

これは現在のWebページを変更しないで済みますが、表示レイアウトが変わると壊れやすいです。
可能なら、表示されたHTMLではなく、元データを保存する方法のほうが安定します。

台風情報の集約ルール

台風の場合は、単に「台風9号」だけでまとめるより、次のようにまとめるのが安全です。

台風番号
＋
基点時刻
＋
何時間後

たとえば今回なら、

台風9号
基点時刻：7月8日18時
0時間後
12時間後
45時間後
93時間後
117時間後

という1つの予報セットとして保存します。

次に新しい発表が来て、基点時刻が変わった場合は、

台風9号
基点時刻：7月9日00時
0時間後
12時間後
24時間後
...

のように、別の予報セットとして保存します。

すると、別ページでは次のように切り替え表示できます。

表示モード	内容
最新予報だけ表示	最新の基点時刻の進路図を表示
過去予報も表示	基点時刻ごとの予報進路を比較
台風9号の履歴	台風9号に関する全受信情報を時系列表示

別Webページの画面イメージ

別ページは、次のような構成にできます。

台風9号 進路情報

基点時刻：2026年7月8日18時

[地図]
1 0時間後   925hPa
2 12時間後  925hPa
3 45時間後  935hPa
4 93時間後  990hPa
5 117時間後 994hPa

[表]
時刻 / 何時間後 / 緯度 / 経度 / 中心気圧 / 最大風速 / 瞬間最大風速

地図は、LeafletというJavaScript地図ライブラリで作れます。
また、外部地図を使いたくない場合は、簡易的なSVG地図やCanvas図でも作れます。

注意点

一番重要なのは、保存を始める前に流れてしまった情報は復元できないという点です。

今回のように偶然スクショできた情報は、あとから手入力や画像読み取りで再構成できます。
しかし、通常運用ではスクショ頼みではなく、

受信した瞬間に、元データをそのまま保存する

という仕組みにしておくのがよいです。

結論

できます。
おすすめは、現在のWebページはそのまま残し、別の常駐プログラムで受信データを保存し、台風番号・基点時刻・予報時間で集約して、別Webページで地図と表を更新する構成です。

現在のWebページがどの形式のデータを読んでいるか、たとえば JSON、CSV、WebSocket、MQTT、ログファイル、シリアル受信 のどれかが分かれば、具体的な構成案まで落とし込めます。

別のWebページに、集約した情報を表示する方法が提案されたので、今後、検討する。
機器が大きくなり消費電力も増えるが、小規模のローカルLLMを内蔵し、情報集約の要領を容易に変更できるようにして、融通が利くようにシステムを構成するのも面白いかもしれない。