■The手抜きな記事
Es予測プログラムをずっと作成してきました。それに続くようにDuct。
やっとまともに動くかなぁ？と思った頃には、すっかりEsシーズンも終わってしまいました（笑）
ということで、F2層予測プログラムに一度は着手するも２週間以上取り組んでも超えられない壁があり断念してました。
が、ここまでEsが元気なくなると、沖縄か台湾とのQSOに頼るしかありません。
ということで、諦めていたF2層予測エンジンに再度取り組むことにしました。
まっ、諦めが悪いんですね。
で、シルバーウィークも、少しでも隙間時間があればなんとかF層予測が出来ないか？といろいろとチャレンジしてまして、ようやく突破口が見えてきました。
なので、遂にやっちゃいました。F２予測機能実装。
ただ、プログラムばかりやっていたので、記事を書くのが逆にだるい・・・
そこで思ったのが、chatGPT6が出た（私は課金がいやなので使ってませんが（笑））記念で、chatGPTにプログラムを分析させてみました。
今回は（も？）「それを貼り付けただけ」の記事です。
■大事にしたいこと
個人的な思いとして、「ブラックボックスにはしない」ことです。
市民ラジオの新技適もそうですが、技術は公開してなんぼです。無論、普段仕事で開発しているものは「”隠して”造るもの」ではありますが・・・。
とはいえ、少しでも技術に興味を持ってもらえればと思っています。
残念ながらこのプログラムを最新AIで実用レベルまで組み上げることはまだ不可能とは思います。
ただ、AIの進化ペースを考えれば、この記事を始め、過去の記事をAIに食わせれば、同じエンジンが作れる日が来ることを信じてます。
■このプログラムってどうよ？（chatGPT出力そのままです）
これは単なる「Pythonで数値計算をするプログラム」ではなく、かなり大規模な実測データ収集 → 物理特徴量抽出 → 統計学習 → 予測 → 自己補正 → 可視化 → 継続学習までを一体化した、電波伝搬観測・予測システムです。
アップロードされた ESDUCTF2を全体構造まで確認して分析しました。ファイルは 23,953行、約1.05MB、AST上で 543個の関数、7クラスを含みます。PART 1～9という構成になっています。
1. まず、このプログラムの正体
名称は
> Es・F2・DUCT / Ver2.6
で、3つの異なる伝搬現象を一つのシステムに統合しています。
Es：スポラディックE層伝搬
F2：電離層F2層によるHF伝搬
DUCT：対流圏ダクト伝搬
重要なのは、単純に3つの予測値を足し合わせているわけではないことです。
特にEsとF2については、コード中でも明確に独立した評価系として扱われています。F2側も「Esとの統合確率を作らない」という設計になっています。
これはかなり重要な設計判断です。
---
2. 全体アーキテクチャ
概念的にはこうなっています。
┌───────────────┐
│ NICT │
│ 電離層観測 │
└───────┬───────┘
│
┌──────────▼──────────┐
│ Es解析 │
│ fxEs / foEs / 構造 │
│ シア / 重心 / MSTID │
└──────────┬──────────┘
│
┌─────────────────┼──────────────────┐
│ │ │
▼ ▼ ▼
物理特徴量 FT8実測 宇宙天気
F層状態 PSKReporter NOAA
│ │ │
└─────────────────┼──────────────────┘
▼
┌────────────────┐
│ エリア予測 │
│ Ridge / IDW │
│ ETA / Ensemble │
└───────┬────────┘
│
▼
Es伝搬予測結果
│
▼
Web Dashboard
NICT F2データ ──→ F2予測 ───────────────┐
│
▼
統合Dashboard
気象データ ──→ N/Mプロファイル ──→ ダクト検出
│
▼
WKB / 到達距離
│
PSK/WSPR実測
│
▼
DPP + 自動較正
│
▼
DUCT Dashboard
つまり、観測・物理モデル・経験モデル・実測伝搬・自己学習を混ぜたハイブリッド型です。
---
3. 特に特徴的なのがEs予測エンジン
Es側はこのプログラムの中心です。
PART 3～6にまたがっており、
NICTからfxEs取得
NICT HTML解析
履歴保存
Es構造解析
F層解析
MSTID
宇宙天気
FT8
PSKReporter
エリア別学習
Ridge回帰
時系列評価
空間補間
重心移動
ETA
自動補正
モデル成熟度
まで入っています。
単純な
if fxEs > 8:
Esあり
というタイプではありません。
---
4. Esの「状態」そのものを解析している
例えばfxEsだけでなく、
fxEs
fxEsの時間変化
層厚
層高度
ブランケット
垂直シア
F層との関係
MSTID
Es雲の重心
重心速度
伝播方向
方位異方性
などを特徴量化しています。
さらにEsのPhaseも、
Formation
Growth
Peak
Decay
Collapse
という時間的な状態として扱っています。
例えば、
fxEs > 5 MHz
fxEs > 8 MHz
fxEs > 12 MHz
などの閾値を使い、さらにEQIの変化率を使ってDecay等を判断する構造です。
これは「現在強いか」ではなく、
> 今Esがどの状態にあり、次にどう変化しそうか
を見ようとしている設計です。
---
5. かなり面白いのが「物理モデル＋機械学習」の構成
機械学習は単純なブラックボックスではありません。
中心となっているのは
Ridge
StandardScaler
です。
さらに学習対象には、
現在値
過去15分
過去30分
過去45分
過去60分
のラグ特徴量を入れる設計になっています。
そして、
Ridge
↓
予測
↓
persistenceとの比較
↓
holdout Skill Score
↓
信頼度判定
という構造を持っています。
これはかなり重要です。
---
6. 「R²が高いからAIを信用する」になっていない
コードではRidgeのインサンプルR²だけでなく、時系列80/20のホールドアウトで、
> persistenceモデルより改善しているか
を確認しています。
persistenceとは、
未来 = 現在値
という非常に強いベースラインです。
この比較を入れている点は、予測システムとしてかなりまともです。
さらに、
AREA_PRED_MIN_HOLDOUT_SKILL = 0.05
というゲートを設けています。つまり「R²は良いけれど、現在値をそのまま使う方法よりほとんど良くない」というモデルを簡単に信用しない設計です。
---
7. さらにShadow Ensembleまで入っている
ここはかなり高度です。
通常なら、
Ridge予測
だけで終わります。
このコードでは別に、
Ridge
persistence
幾何学的ETA
climatology
を比較しています。
そしてRidgeと幾何学モデルが矛盾した場合には、
Ridgeの重みを0.5倍
してpersistence側へ寄せる仕組みまであります。
つまり、
> 統計モデルが物理的におかしなことを言った場合に、そのまま採用しない
という思想です。
これは通常の個人製Pythonプログラムより一段進んだ設計です。
---
8. Es雲を「点」ではなく「動く空間構造」として扱っている
ここもこのプログラムの特徴です。
エリアごとの状態だけではなく、
Es centroid
↓
移動方向
↓
移動速度
↓
対象エリアまでの距離
↓
ETA
という処理があります。
コードでは例えば、
approach_cos
eta_min
eta_confidence
を計算しています。
approach_cos は、
+1に近い → 対象エリアへ向かう
0付近 → 横方向
-1に近い → 遠ざかる
という意味です。
これは単なる統計予測ではなく、
> 「今あるEsがこの先どこへ動くか」
を幾何学的に推定しています。
---
9. IDW空間補間も入っている
エリアを
北海道
東北
関東
東海
関西
中国
四国
九州
沖縄
台湾
などに分け、各エリアの実測値をそのまま独立に扱うのではなく、
逆距離加重（IDW）
で空間的に補間しています。
近いエリア → 大きな重み
遠いエリア → 小さな重み
という考え方です。
設定値として、
power = 2
minimum sources = 2
maximum neighbor distance = 1200 km
が設定されています。
---
10. FT8/PSKReporterを「センサー」として使っている
これもかなり特徴的です。
普通ならPSKReporterは、
> 「今日はどこまで飛んだ」
を見るだけです。
このコードでは、
PSKReporter
↓
実際の送受信地点
↓
距離
↓
方位
↓
到達率
↓
RPI
↓
伝搬モード
↓
Es予測の教師データ
という流れにしています。
さらに固定観測局DBまで組み込まれています。固定局は日本各エリアと台湾を含み、座標・エリアコードまで持っています。
つまりPSKReporterを単なる「通信ログ」ではなく、
> 広域の実測伝搬センサーネットワーク
として扱っています。
---
11. MSTID解析もかなり特殊
NICT GEONETのTEC画像を取得し、
画像
↓
クロップ
↓
エッジ
↓
PCA
↓
方向
↓
移動
という画像解析を行います。
さらに、
H15
H60
ROTI
LOL
TEC absolute
など複数の画像種別を扱える構造です。
特にH15をデフォルトにしている点は、
>15分以下のTEC変動 → MSTID検出
という明確な目的があります。
コードには画像領域を
0.08, 0.10, 0.82, 0.91
でクロップする設定まであり、タイトル・軸・カラーバーなどの「画像そのものの情報」を解析対象から除外しようとしています。
このあたりはかなり実験装置的な発想です。
---
12. F2予測はEsとは別系統
F2についてはNICTの
MUF
LUF
を使っています。
そして現在地から対象エリアまでの距離を大圏距離で求め、
NVIS
DEAD_ZONE
SKIP
に分類します。
さらにSKIPの場合、
> 大圏経路の中点に最も近いNICT局
の距離別MUF/LUFデータを使っています。
ここは非常に重要で、
「F2が強い」
ではなく、
「この距離の通信が成立する可能性」
へ変換しています。
---
13. F2は現時点では「機械学習予測」ではない
ここはコード自身がかなり正直に書いています。
F2の+15、+30、+45、+60、+90分予測は、
> セッション内のMUF履歴から単純線形トレンドを外挿
しています。
つまり、
MUF(t)
MUF(t-Δt)
↓
傾き
↓
MUF(t+30)
です。
コードにも+90分は単純外挿なので参考扱いと明記されています。
この点は、Es側のRidge/ensembleと比べると、かなり成熟度が違います。
---
14. ただしF2の可視化はかなり進化している
現在のコードではF2を、
離散エリア
↓
緯度経度グリッド
↓
F2開通期待度
↓
コンター
↓
塗りつぶし
へ拡張しています。
1°グリッドで、
21～47°N
118～149°E
を対象にする設計です。
さらに0/15/30/45/60/90分のホライズンに連動します。
これは「F2の数値表」から「F2伝搬場」へ進化させている部分です。
---
15. DUCTはほぼ別の研究システム
PART 8を見ると、DUCTは単なるおまけではありません。
元々独立していた
> Duct Propagation Forecast V6.2.1
を統合した構造です。
物理モデルとして、
気温
湿度
気圧
↓
屈折率 N
↓
修正屈折率 M
↓
dM/dz
↓
ダクト検出
↓
WKB
↓
周波数別到達距離
となっています。
特に、
\[
N = 77.6\frac{P}{T} + 3.73\times10^5\frac{e}{T^2}
\]
と、
\[
M=N+0.157h
\]
を使っています。
コード上でも実際にこの構造が実装されています。
---
16. DUCTのDPP計算も単純な一発判定ではない
DPPは、
構造
安定性
乱流
結合
を組み合わせています。
コードコメントに明示されている基本式は、
DPP_raw =
0.35 × 構造
+ 0.20 × 安定性
+ 0.20 × (100 - 乱流)
+ 0.25 × 結合
です。
その後、
DPP_raw
×
calibration correction
↓
DPP
となります。
つまりDUCT側も、
> 物理モデル → 実測による較正
という構造です。
---
17. DUCTでは「自己学習」がさらに別方式
Es側が主に
Ridge
時系列
Skill Score
なのに対して、DUCT側では、
実測
↓
較正セル
↓
信頼度
↓
補正係数
という方式です。
さらに、
時間帯別補正
空間補正
特徴量ベース補正
Reservoir Sampling
データ減衰
WSPRバックフィル
PSKReporter
などを持っています。
そして較正ファイルへの複数スレッド同時アクセスによる競合を経験し、_CAL_IO_LOCKで直列化しています。これは実運用からフィードバックを受けて改善された箇所です。
---
18. Web UIも「付属品」ではない
PART 7はかなり大きく、単なる結果表示ではありません。
サーバーとして、
/api/status
/api/log
/api/browse
/api/duct/status
/api/duct/point
/api/duct/map
/api/duct/settings
/api/duct/hepburn
/api/duct/geocode
/api/duct/pass
/api/duct/antenna
/api/duct/radar
/api/duct/celldata
/api/es/settings
などを提供しています。
さらにHTTP GETについてホワイトリストを設け、
> 学習CSVなどをHTTPサーバーから無制限に配信しない
という対策まで入っています。
これは「個人用スクリプト」の域をかなり超えています。
---
19. マルチプラットフォーム設計もかなり本気
想定環境は、
Windows
Raspberry Pi
Android / Pydroid3
Chromebook
Termux
です。
特にAndroidの、
スクリプトディレクトリ
↓
Android共有ストレージ
↓
ホームディレクトリ
↓
/tmp
という多段フォールバックがあります。
しかも単にmkdir()するだけではなく、
mkdir()
↓
.write_test
↓
書き込み
↓
削除
までして「実際に書けるか」を確認しています。
これは実運用経験がかなり反映されています。
---
20. ログ・学習データ管理も重要
このプログラムは、
prediction.csv
edfs_area_history.csv
edfs_ridge_training.csv
effective_contribution_history.csv
feature_ranking_history.csv
calibration_profile.json
などを蓄積していきます。
しかも起動時に過去ログを統合・整理し、学習データと分析用レポートを分離しています。
したがって、このプログラムは本質的には、
> 一回実行して答えを出すプログラムではなく、実行するほどデータベースが育つプログラム
です。
---
21. 「モデル成熟度」という概念まで持っている
非常に面白い部分です。
EDFSには、
Level 0 Learning
Level 1 Area Learning
Level 2 Area Predictor
Level 3 Motion Predictor
Level 4 Lifetime Predictor
Level 5 Dynamics Engine
という段階があります。
そして、
Area Teachers
Centroid history
Lifetime samples
Total samples
Es samples
などの蓄積量に応じて段階が上がります。
つまり作者は、
> 「機械学習モデルがある＝AIが完成」
とは考えていません。
データが足りなければ未成熟モデルとして扱う設計です。
これは非常に重要です。
---
22. 一方で、技術的にかなり気になる部分もある
ここからが重要です。
このプログラムは高度ですが、高度であることと、予測精度が科学的に確立していることは別問題です。
特に注意したいのは以下です。
① 特徴量が多く、自由度が非常に高い
現在の特徴量には、
fxEs
trend
cluster
shear
layer
descent
GW
foF2
dfoF2
hmF2
dhmF2
M3000F2
RPI
Es mode
EQI
Space Weather
Es phase
MSTID
interaction terms
lag terms
などが入ります。
これは強力な反面、
> データ量に対してモデル自由度が増えすぎる危険
があります。
---
② 一部の閾値は「物理定数」ではなく経験的仮値
例えば、
AREA_IDW_POWER = 2
GEO_ETA_MAX_MINUTES = 240
ES_HOP_DIST_MIN_KM = 600
ES_HOP_DIST_MAX_KM = 2400
などはコード自身が「暫定値」「実運用で要検証」と明記しています。
したがって、
> 「コードに数字が書いてある＝科学的に確定した数字」
ではありません。
ここは明確に区別すべきです。
---
23. 特に重要なのは「予測」と「推定」が混在していること
例えば、
Es雲の現在位置
↓
速度
↓
ETA
は、かなり物理的な推定です。
一方、
Ridge
↓
未来RPI
は統計的予測。
さらに、
climatology
↓
平年値
はベースライン。
そして、
PSKReporter
↓
実測到達率
は観測。
これらが一つの画面に出てきます。
これはシステムとしては強いのですが、利用者が
> 「この数字は何を意味しているのか」
を理解できるUI設計が非常に重要になります。
---
24. F2側にはEs側との差がかなりある
現在の設計を見る限り、
Es
実測
↓
物理特徴
↓
時系列
↓
Ridge
↓
OOS評価
↓
persistence比較
↓
geometry
↓
ensemble
↓
forecast
かなり複雑です。
F2
NICT MUF/LUF
↓
距離
↓
NVIS/SKIP/DEAD
↓
バンド別期待度
↓
MUFトレンド線形外挿
です。
したがって、「Es・F2・DUCT」という3本柱は機能上は統合されていますが、予測器の成熟度は同一ではありません。
これは今後の設計上かなり重要なポイントです。
---
25. もう一つ大きな問題は「単一巨大ファイル化」
現在、
> 約24,000行 / 約1MB
です。
しかもASTでは500以上の関数があります。
構造的には、
ES core
F2 core
DUCT core
HTTP server
HTML
JavaScript
CSS
logging
machine learning
data acquisition
platform abstraction
が全部一つのPythonファイルに入っています。
これはAll-in-Oneとしては非常に便利ですが、保守性はかなり悪化します。
特に現在は元々別系統だった
EDFS
DUCT
Hepburn
F2
を統合してきた痕跡がコード中にかなり残っています。
---
26. 実際に「統合の歴史」がコードに残っている
例えばコメントには、
> 元々 "Es & Duct"
Ver2.0でF2を復活
という履歴があります。
またDUCT側には、
> 元 Duct_Propagation_Forecast_V6_2.py
という説明があります。
つまり現在のコードは、最初から一枚岩として設計されたものではなく、
旧システムA
+
旧システムB
+
追加機能C
+
追加機能D
+
修正パッチ
が積み上がって現在の形になっています。
これは悪いことではありません。
むしろ実運用型ソフトウェアでは非常に普通です。
ただ、今後さらに発展させるなら、そろそろモジュール化のメリットが大きくなっています。
---
27. それでもコードから読み取れる作者の設計思想はかなり明確
このプログラムで特に一貫している思想があります。
「一つの指標だけを信用しない」
例えば、
NICT
FT8
PSKReporter
MSTID
宇宙天気
F2
気候値
幾何学
機械学習
を相互参照します。
そして、
モデルが言っている
だけでなく、
実測ではどうか？
を常に意識しています。
---
28. さらに「自己評価」まで実装している
例えば、
Ridge R²
Holdout Skill
MAE
persistence比較
feature contribution
effective contribution
model maturity
state coverage
novelty
などがあります。
これは単なる予測器ではなく、
> 予測器そのものを観測するシステム
になっています。
この思想はかなり研究的です。
---
29. コード品質について
私の評価を分類すると、
項目 状態
機能の豊富さ 非常に高い
実運用への対応 非常に高い
障害時フォールバック 高い
データ取得耐性 高い
可観測性・ログ 高い
物理モデル 高い
機械学習構造 高い
モデル評価 比較的高い
モジュール性 低い
テスト容易性 低い
保守性 中～低
科学的妥当性の検証 発展途上
UI統合 高い
特に、
「プログラムとして完成している」ことと「科学モデルとして検証済み」ことは分けて考える必要があります。
--
30. 私が一番注目したポイント
このコードで一番興味深いのは、機械学習そのものではありません。
むしろ、
> 「物理的にこうなるはず」
と
「実際にこう観測された」
を別々に持ち、それを比較していること
です。
例えば、
Ridge予測
│
├── persistence
│
├── geometry ETA
│
├── climatology
│
└── 実測PSKReporter
↓
整合性・Skill評価
という考え方です。
これは一般的な「AIにデータを食わせて予測」という発想とはかなり違います。
---
31. 結論
このプログラムを一言で表すなら、
> 「電波伝搬の実測データ・物理モデル・統計モデルを統合し、運用しながらモデル自身を評価・補正していく、実験観測型の予測システム」
です。
特に特徴的なのは、
1. Es/F2/DUCTを物理的に分離
2. NICTを一次観測源として利用
3. PSKReporter/FT8を広域実測センサー化
4. MSTIDを画像解析
5. Es雲を重心・速度・ETAとして追跡
6. Ridgeによるエリア別予測
7. persistenceとのOOS比較
8. 幾何学モデルとの整合性チェック
9. climatologyによるコールドスタート
10. 自己ログによる自動補正
11. モデル成熟度を段階管理
12. DUCTではN/M/WKB＋実測較正
13. Web API＋リアルタイムDashboard
14. Windows/Android/RPi/Chromebookを考慮
15. 実運用で発生した障害をコードへフィードバック
というところです。
そして、一番大きな弱点は「機能が高度すぎること」そのものではなく、24,000行近い単一ファイルの中に複数世代・複数エンジン・複数の予測思想が同居していることです。
逆に言えば、次に手を入れるなら新機能を追加するより、
ES Core
F2 Core
DUCT Core
Observation
ML
Calibration
Dashboard
Storage
Platform
へ分割して内部アーキテクチャを整理する段階に来ています。
なお、コード自身がF2について「以前は未実装だったF2コンター／機械学習を段階的に追加している」履歴を残しており、現在のVer2.6はかなり長い開発履歴の上に成立しています。