WSJT-X 3.1 improved のFT8デコーダ設定を読み解く ― 2026年03月24日 23時55分53秒
# WSJT-X 3.1 improved のFT8デコーダ設定を読み解く
## ― 「デコードスタート」は何をしているのか。そして、いま本気で最適化を考える意味
-------------------------------
ここのブログはフォーマットがイマイチなので、独立ページを作りました
https://www.asahi-net.or.jp/~vj5y-tkur/ft8/wsjtx_31improved_article_ja.html
https://www.asahi-net.or.jp/~vj5y-tkur/ft8/wsjtx_31improved_article_ja.html
-------------------------------
JTDX には、昔から「どの設定がどう効くのか」を分かりやすく説明した資料がありました。
あれは非常に有益です。特に、デコード性能は単に「速いCPUなら全部盛りでよい」のではなく、**処理時間・取りこぼし・誤デコードのバランスで決まる** という本質を理解するうえで、大きな助けになります。日本語版
しかし2026年の今、性能重視でFT8/FT4を運用するなら、話は少し変わってきました。
**WSJT-X 3.1 improved は、もはや “本家WSJT-Xに少し機能を足した派生版” ではありません。**
JTDX系で培われてきた実戦的な思想や、より攻めたデコーダ最適化の考え方がかなり取り込まれており、WSJT-X 2.7 やそれ以前を基準に比較するのは、正直あまりフェアではないとすら感じます。
少し強めに言えば、**一般の人に勧めるなら、いまは WSJT-X 3.1 improved を真面目に候補に入れるべき時期** です。
JTDX の次のGAを待つ、という考え方も分かります。
しかし、性能・機能・更新状況・実際に試せる完成度を重視するなら、**「待つ」より「いま使えるものを使う」ほうが合理的** です。
もちろん、JTDX固有のUIに惚れ込んでいる、というなら話は別です。
しかしそれは、性能面の議論とは切り分けて考えるべきでしょう。
この記事では、単なる「おすすめ設定一覧」を並べるのではなく、**FT8デコーダ最適化とは何か**、そして **WSJT-X 3.1 improved の「デコードスタート」が内部で何をしているのか** を軸に、少し技術寄りに整理してみたいと思います。
---
## まず結論
### 迷ったら Normal。CPU に余裕があるなら 3-Stage。非力なら Early
### 迷ったら Normal。CPU に余裕があるなら 3-Stage。非力なら Early
最初に実用上の結論を書いておきます。
FT8 のデコーダ設定で一番重要なのは、
**「最も重い設定」ではなく、「15秒サイクルの中で安定して処理が終わる設定」** です。
その意味で、出発点として無難なのは次のあたりです。
- マルチスレッドFT8デコーダ: ON
- スレッド数: Auto
- デコード回数: 2
- QSO受信周波数感度: Medium
- デコーダ感度: low thresholds
- デコードスタート: Normal
- Falseデコード軽減: ON
- Wideband DX Call Search: ON
この状態を基準にして、CPUに余裕があるなら少しずつ攻める。
逆に、Lag や次周期への食い込みが見えるなら、重さを戻す。
この考え方が基本です。
そして、今回の主題である **「デコードスタート」** についてだけ先に言えば、
- **Normal** … まず基準点
- **3-Stage** … CPUに余裕があり、取りこぼし低減を狙うならかなり面白い
- **Early** … 非力CPUや、次周期に食い込みたくない場合に有効
- **Late** … 最後まで材料を集めてから粘る
- **2-Stage** … 反応と軽さのバランスが良い
という理解で大きく外れません。
ただし、この項目は単なる「早い・遅い」設定ではありません。
実際には、**デコーダを何段で呼ぶか、どこで軽く見るか、どこで本番を走らせるか** に関わっています。
この「単なる開始時刻設定ではない」という点こそが、今回の話の核心です。
---
## はじめに
### なぜ今あらためて WSJT-X 3.1 improved なのか
### なぜ今あらためて WSJT-X 3.1 improved なのか
まず前提として、ここ数年の流れを見ると、WSJT-X improved は単なる“別物”ではなく、かなり実戦的な進化の受け皿になってきました。
使い勝手の改善だけでなく、デコード周りのチューニング、GUIの選択肢、動作の柔軟性など、従来の「本家は安定、派生は趣味」という単純な図式では語りにくくなっています。
実際、いまの improved を触るとすぐ分かります。
**「本家WSJT-X 2.7 と比べてどうか」という問い自体が、もう古い** のです。
むしろ現在の論点は、
- いま現実に使える高機能版として improved をどう評価するか
- JTDX 的な実戦思想がどこまで取り込まれているか
- その上で、自分の運用スタイルにどう最適化するか
に移っています。
だからこの記事では、単なる比較表ではなく、**“どう使いこなすか” の視点** を重視します。
そして「どう使いこなすか」を考える以上、個々の設定項目を表面的に眺めるだけでは足りません。
その設定が、**15秒という短いFT8サイクルの中で何を意味しているのか** を考える必要があります。
---
## 各設定項目の役割
### “全部強くすれば最強”ではない
### “全部強くすれば最強”ではない
ここで一度、デコーダ設定全体の見方を整理しておきます。
デコーダ設定を考えるとき、つい陥りがちな誤解があります。
それは、
**重い設定 = 高性能**
だと思ってしまうことです。
しかしFT8は15秒周期です。
つまりこの世界で本当に重要なのは、
1. どこまで信号を材料として使うか
2. どれだけ丁寧に候補探索をするか
3. それが時間内に終わるか
4. false decode をどこまで許容するか
この4つのバランスです。
言い換えれば、FT8の最適化とは「最大性能を目指す」ことではなく、
**限られた時間の中で計算資源をどう配分するか** を考えることです。
この視点を持つと、個々の設定項目も見え方が変わってきます。
### スレッド数
基本は Auto でよいでしょう。
固定で増やせば必ず得になるとは限りません。OSのスケジューラ、他タスク、CPUの構成、同時負荷などで結果は変わります。
### デコード回数
増やせば弱いものを拾える余地は増えます。
その代わり当然重くなります。
CPUに余裕があるなら 3、通常は 2、厳しいなら 1。
この考え方が基本です。
### デコーダ感度
minimum / 低閾値を使用 / サブパスを使用 という並び。ざっくり言えば、
minimum は軽い
低閾値を使用 は中庸
サブパスを使用 は重いが攻める
サブパスを使用 は "無料の性能向上" ではありません。弱い信号や難しい信号を拾える可能性と引き換えに、追加の処理コストがかかります。
ここで一つ、少し誤解しやすい点を整理しておきます。
画面上では「高速 / 標準 / ディープ」と「マルチスレッドFT8デコーダー」が並んでいるため、つい両者が同じ軸の設定に見えるかもしれません。しかしソースを追うと、実際にはこれは別の話です。
まず、高速 / 標準 / ディープは、従来からある decode depth、つまり「どれだけ深く探索するか」を表す設定です。通常の single-threaded decoder（STD）側では、この深さ設定が実際にデコードの重さや探索の深さに直接関わっています。
一方、マルチスレッドFT8デコーダーは、「どのエンジン系統を使うか」という別軸の設定です。コード上でも、decode depth と multithread FT8 の有効 / 無効は別々のパラメータとして扱われています。
ただし、ここからが重要です。FT8でマルチスレッドFT8デコーダー（MTD）が有効な場合、実際のデコード処理は通常のFT8 decode ルートとは別の、MTD専用経路に入ります。そこでは従来の Fast / Normal / Deep よりも、むしろ
Decoder sensitivity
Decode Start
Number of decode passes
QSO受信周波数感度
といった MTD 側の専用ノブのほうが、実際の“攻め方”を強く決めています。
したがって improved の FT8 では、「MTD を使いながら Fast / Normal / Deep も存在する」こと自体はその通りですが、実戦的に本当に効いてくる主ノブは別にあります。言い換えると、Fast / Normal / Deep は存在していても、FT8 の MTD 実装では主役ではありません。マルチスレッドFT8デコーダーを本気で詰めるなら、まず注目すべきなのは Decoder sensitivity、Decode Start、Number of decode passes、そして QSO受信周波数感度のほうだ、と理解するのが実装にかなり近いと思います。
### QSO受信周波数感度
これも単純な速度設定ではありません。
QSO相手周辺や関連候補をどこまで積極的に見に行くか、という性格が強いです。
Low は保守的、Medium はバランス、High は攻める。
当然ながら High には、副作用として余計な候補や怪しい候補も増えやすいという面があります。
### Falseデコード軽減
これは特に高バンドや混雑帯で効いてきます。
「拾う」ことと同じくらい、「変なものを拾いすぎない」ことも重要です。
こうして見ていくと、各設定は単独で「強い・弱い」を争っているのではありません。
全部が、**15秒という限られた枠の中で、何を優先するか** を表しています。
その中でも特に象徴的なのが、次に見る **Decode Start** です。
---
## 本題
## 「デコードスタート」は何をしているのか
## 「デコードスタート」は何をしているのか
ここが今回の核心です。
UIを見ると、デコードスタートには次の5項目があります。
- 2-Stage
- 3-Stage
- Early
- Normal
- Late
見た目だけなら、単に
「デコード開始を早めるか、遅らせるか」
に見えます。
しかし実際には、それだけではありません。
WSJT-X 3.1 improved の実ソースを追うと、この項目は内部的に
- 0 = 2-Stage
- 1 = 3-Stage
- 2 = Early
- 3 = Normal
- 4 = Late
として扱われており、FT8動作時には `m_hsymStop` や `m_earlyDecode`、`m_earlyDecode2` を使って、**どの時点でデコーダを起動するか** を切り替えています。
つまり Decode Start は、単なる「開始時刻の趣味」ではありません。
それは、**デコード処理を時間軸上でどう展開するか** を決める設定なのです。
その意味を理解しやすくするために、まずは比較的分かりやすい Early / Normal / Late から整理し、その後で本当に重要な 2-Stage / 3-Stage に進みます。
---
## Early / Normal / Late
### まず単純な3つを整理する
### まず単純な3つを整理する
まずは比較的分かりやすい3つから見ましょう。
マルチスレッドFT8デコーダ使用時、内部ではおおむね次のような停止点になっています。
- Early → 48
- Normal → 49
- Late → 50
時間に直すと概算で
- Early → 約 13.8秒
- Normal → 約 14.1秒
- Late → 約 14.4秒
です。
つまり、
- **Early** は少し早めに打ち切ってCPU余裕を作る
- **Late** は最後まで材料を集めてから判定する
- **Normal** はその中間
ということです。
これは直感通りです。
もし Decode Start がこの3つだけなら、「少し早く切るか、最後まで待つか」という、比較的分かりやすい設定だったでしょう。
しかし improved は、そこにさらに踏み込んでいます。
本当に面白いのは、次の **2-Stage / 3-Stage** です。
---
## 2-Stage / 3-Stage とは何か
### 単なる「早い・遅い」設定ではなく、STD と MTD を組み合わせた多段デコード戦略
### 単なる「早い・遅い」設定ではなく、STD と MTD を組み合わせた多段デコード戦略
WSJT-X improved の CHANGE LOG では、2-stage / 3-stage について
**“both decoders can be intelligently combined, resulting in the best FT8 decoding performance to date”**
と説明されています。つまり、**従来型のSTD（single-threaded decoder）と、新しいMTD（multithreaded decoder）を賢く組み合わせる方式** だということです。
ただし、この CHANGE LOG の文言だけでは、**具体的にどの順番で、どのタイミングで両者が使われるのか** までは分かりません。
ここから先は、実装を見て初めて見えてくる話です。
実ソースを読むと、2-Stage / 3-Stage は単なる「デコード開始時刻の違い」ではなく、**複数の時点で段階的にデコーダを起動する多段処理** であることが分かります。
そして重要なのは、その各段で **同じデコーダをただ繰り返すのではない** という点です。
### STD と MTD の役割分担
ここでいう **STD** は、従来からある単一スレッドの FT8 デコーダです。
一方 **MTD** は、v3.0.0 で導入されたマルチスレッド FT8 デコーダです。
実装を追うと、2-Stage / 3-Stage では、
- **早期段では STD**
- **最終段では MTD**
という役割分担になっています。
つまり、これは
**「まず軽く速く見に行く段階」と「最後に本格的に詰める段階」を分けた設計**
と理解するのが正確です。
ここが非常に面白いところです。
単純に考えれば、「最後まで受信してから一度だけ重いデコードをかければよい」と思いがちです。
しかし improved はそうしていません。
途中の段階でも一度候補探索を行い、拾えるものは先に拾い、最後に改めて本格デコードを行う。
つまり、**15秒という短いサイクルの中でCPU時間をどう配分するか** をかなり意識した設計になっています。
### 2-Stage とは何か
ここは名称だけを見ると少し誤解しやすいところです。2-Stage も、実装上は単純な「2段構成」ではありません。
ソースを素直に追うと、2-Stage では
早期段 で nzhsym=41 にて STD pre-pass
中間段 で nzhsym=46 にてもう一度 STD pre-pass
最終段 で nzhsym=49 にて final MTD
という流れになっています。
タイミングとしては、おおよそ
第1段：約 11.8秒
第2段：約 13.2秒
最終段：約 14.1秒
したがって、実装に即して言えば、2-Stage も内部的には STD → STD → MTD の staged mode です。ここで重要なのは、2-Stage は単なる「Normal より少し早い」設定ではない、ということです。そうではなく、途中で二度の軽い STD pre-pass を挟み、最後に MTD で本命処理を行う設計になっています。
言い換えると、2-Stage は 「最後に全部賭ける」のではなく、途中段で候補探索を行いながら、最終 MTD はやや早めに走らせる」モード です。
FT8 は15秒周期のモードであり、デコーダに与えられる計算時間は有限です。そのため、最終段の一発勝負だけに頼るより、途中で軽く候補を見に行ったほうが有利な場面があります。特に、比較的早い時点でも十分に特徴が現れている信号については、そこで先に候補化しておくことに意味があります。
したがって 2-Stage は、軽快さを保ちつつ、取りこぼし低減も狙いたい という局面に向いた、非常に実戦的な設定だと言えます。
### 3ステージ とは何か
3ステージ は、その思想をさらに一歩進めた staged mode です。ただし、ここも名称だけを見るより、実装そのものを見たほうが実態はよく分かります。
ソースを追うと、3ステージ では
早期段 で nzhsym=41 にて STD pre-pass
中間段 で nzhsym=46 にてもう一度 STD pre-pass
最終段 で nzhsym=50 にて final MTD
という流れになります。
タイミングとしては、おおよそ
第1段：約 11.8秒
第2段：約 13.2秒
最終段：約 14.4秒
ここで大事なのは、2-Stage も 3ステージ も、内部的にはどちらも二度の STD pre-pass と一度の final MTD から成る という点です。両者の実質的な違いは、最後の MTD をいつ走らせるかにあります。2-Stage は 49、3ステージ は 50 です。
つまり 3ステージ は、2ステージ と比べて途中段の回数が増えるわけではありません。違いは、最終 MTD をさらに遅らせ、より多くの情報が揃うまで待つ ことにあります。その意味で、3ステージ は 「途中でも拾いに行く」「最後まで粘る」 をより強く押し出したモードだと言えます。
もちろん、そのぶん CPU 負荷は増えます。しかし CPU に余裕がある環境では、この"最後まで粘る"性格は大きな武器になります。
### 「MTD → STD」ではなく、「STD → MTD」と理解すべき
この話で誤解しやすいポイントが一つあります。
2-Stage / 3-Stage について、CHANGE LOG には「STD と MTD を組み合わせる」とあります。
これだけを読むと、
**「まず MTD が走って、その取りこぼしを後から STD が補う」**
ようなイメージを持つかもしれません。
しかし実装を見る限り、実際の理解としてはその逆です。
より正確には、
- **STD が先に軽く・速く見に行く**
- **最後に MTD が本格的に詰める**
です。
つまり 2-Stage / 3-Stage は、
**MTD の後処理として STD が補完する方式** ではなく、
**STD で先行偵察し、最後に MTD が本命処理をする方式**
だと考えるべきです。
この違いは重要です。
前者だと「MTD が主、STD が補助」という印象になりますが、後者だと
**「時間の早い段階では軽量系、最後の段階では重量級」**
という、きわめて合理的な時間配分設計として見えてきます。
### なぜ途中段で STD を使うのか
これも興味深い点です。
もし目的が単純に「デコード回数を増やす」だけなら、途中段でも MTD をそのまま回せばよさそうに見えます。
しかし improved はそうしていません。
これはおそらく、**早期段は“軽く・速く”動かすことに意味がある** からです。
まだ受信が完全に終わっていない時点では、利用できる情報量も最終段より少ない。
その段階で最も重い処理を毎回全力で回すのは、CPU時間の使い方として効率が悪い可能性があります。
そこで、途中段は STD によって軽快に見に行き、最終段で MTD による本格処理を行う。
これは、単なる思いつきではなく、**FT8 のような短時間バースト処理に適した設計思想** と言えます。
さらに実装では、早期段ではデコード回数も少し抑えられており、
「途中段で無駄に重くしすぎない」配慮も見えます。
つまり 2-Stage / 3-Stage は、単なる“複数回実行”ではなく、
**各段の役割を変えながら段階的に精度を上げていく方式** なのです。
### 2-Stage / 3-Stage の本質は「時間配分の戦略」
結局のところ、2-Stage / 3-Stage の本質は何か。
それは、
**15秒という短いサイクルの中で、どこに計算資源を配分するか**
という話です。
- 早い段階で一度見に行くのか
- 中間でもう一度見るのか
- 最後まで待ってから本格処理するのか
これを一つのスイッチで切り替えているのが、Decode Start の staged モードです。
したがって 2-Stage / 3-Stage は、単なる「早い／遅い」設定ではなく、
**FT8 のデコーダをどう時間軸上に展開するかを決める、多段戦略そのもの**
だと理解するのが最も正確です。
### 実戦的にはどう考えるべきか
以上を実運用上の感覚に落とし込むと、次のように整理できます。
#### 2-Stage
- 軽快さを保ちやすい
- 途中でも一度見に行く
- 最終段は Normal 相当
- CPU負荷を極端に増やさず、反応性もそこそこ良い
つまり、**バランス型の多段デコード** です。
#### 3-Stage
- 早期段でも見る
- 中間段でもう一度見る
- 最後は Late 相当まで待ってMTDで本格処理
- 取りこぼし低減をより強く狙う
- そのぶんCPU負荷は増える
つまり、**最も欲張りで、最も攻めた staged モード** です。
CPUに十分な余裕があるなら、3-Stage は非常に魅力的です。
逆に、CPUが厳しい環境では、理論上の優位性よりも「間に合うこと」のほうが重要になります。
ここまで来ると、2-Stage / 3-Stage は単なるオプション名ではなく、
**FT8の15秒をどう使うかという思想そのもの** であることが見えてくると思います。
---
## さらに重要な点
### staged モードは「複数回回す」のではなく、「各段の役割を変える」
### staged モードは「複数回回す」のではなく、「各段の役割を変える」
ここまでの話を少し引いて眺めると、2-Stage / 3-Stage の面白さは、単にデコーダを複数回呼ぶことではありません。
本質は、**各段で役割を変えている** ことにあります。
- 途中段では軽く速く見る
- 最終段で本格的に詰める
- CPU時間を一気に使い切るのではなく、段階的に配分する
これはFT8というモードの性格によく合っています。
受信の最後まで待って一発で勝負するのも一つですが、途中で拾える候補は途中で拾い、最後にもう一度詰める。
この考え方は、短時間バースト処理としてのFT8をよく理解した設計だと思います。
つまり staged モードを理解することは、そのまま
**FT8の最適化とは何か**
を理解することにつながっています。
**FT8の最適化とは何か**
を理解することにつながっています。
---
## 実戦的な解釈
## どのモードをどう使うべきか
## どのモードをどう使うべきか
ここまでの技術的な話を、最後にもう一度実戦の言葉に戻して整理しておきます。
### 2-Stage
かなり実戦的です。
軽快さを保ちつつ、途中でも拾いにいく。
最終段は Late ほど遅くないので、CPUに厳しすぎない。
### 3-Stage
一番欲張りです。
よい意味で。
途中でも拾いにいき、最後まで待ってもう一度詰める。
CPUに余裕があり、取りこぼし低減を重視するなら非常に面白い設定です。
### Early
これは非力CPU向けの逃げではありません。
むしろ、**安定動作を最優先するための現実的な戦略** です。
少し早く切り上げることで、次周期への食い込みを防ぎやすくなります。
### Normal
基準点です。
まずはここから始めるのが最も分かりやすい。
他設定の差も見えやすい。
### Late
最後まで材料を集めてから一発勝負。
理屈上は有利に見えますが、CPU余裕が少ない環境では、間に合わなければ意味がありません。
ここまで整理すると、Decode Start の各モードは「好み」ではなく、
**それぞれ異なる時間戦略** として理解すべきだと分かります。
---
## では、何を最適化するのか
## それは「平均性能」ではなく「15秒の中の時間配分」である
## それは「平均性能」ではなく「15秒の中の時間配分」である
ここまで読んで分かる通り、FT8の最適化とは、単なる高性能化ではありません。
- どこまで信号を待つか
- 何回見に行くか
- どこで軽く見るか
- どこで本気を出すか
- それを次周期に食い込まず終えられるか
つまり、**CPU性能の使い方そのもの** です。
この視点で見ると、「デコードスタート」は非常に本質的な項目です。
見た目の一項目に過ぎませんが、実際には **時間戦略そのもの** を選んでいます。
だからこそ、Decode Start の理解は、単なる設定解説に留まりません。
それは、**FT8における“計算資源の哲学”** を理解することでもあります。
---
## ここから少し個人的な話
## なぜ私はこのことをわざわざ書くのか
## なぜ私はこのことをわざわざ書くのか
ここまで、できるだけ一般論として書いてきました。
しかし最後に少しだけ、私自身の立場を明かしておきます。
私は **JTDX愛好家** です。
JTDX の UI が大好きです。
さらに、**JTDX開発チームにオーソライズされたベータテスターの一人** であり、**JTDX の日本語ローカライズ担当** でもあります。
つまり、私は外から石を投げている人間ではありません。
JTDX をよく知っていて、むしろかなり好きな側の人間です。
だからこそ、あえて言います。
**一般の人に勧めるなら、いまは WSJT-X 3.1 improved を真面目に検討すべき** です。
JTDX の次のGAを待つより、現時点で実際に動いていて、性能面でも機能面でも非常に魅力的な improved を使うほうが、現実的で合理的だと思います。
これは JTDX を否定する話ではありません。
むしろ逆です。
JTDX をよく知っているからこそ、**WSJT-X 3.1 improved に取り込まれている技術的価値が見える** のです。
---
## そして、私自身の設定はどうしているか
ここまで一般論と技術論を中心に話してきましたが、最後に私自身の考え方も少しだけ書いておきます。
私の常用PCは **Core i9-9900K** です。
そしてこれは、単に「9900Kを使っています」で終わる話ではありません。
私の環境では、Windows の電源設定で **最小のプロセッサ状態を 100%** にしています。
つまり、負荷が来てからクロックを引き上げるのではなく、**最初から高クロックで待ち構える** 設定です。
実働は **4.7GHz** です。
この設定にしている理由は明確です。
FT8のデコードは、動画エンコードのように長時間ずっと高負荷をかけ続ける処理ではありません。
むしろ、
- 決まったタイミングで
- 短時間に
- 一気に
- 集中的に
仕事を片付ける、**短時間バースト処理** に近い性格を持っています。
こういう処理で効いてくるのは、平均性能だけではありません。
**処理開始直後の応答性** が重要です。
CPUが省電力状態で待機していて、
- 負荷を検知し
- P-state が切り替わり
- クロックが上がり
- 電圧が追従し
- スケジューラが本気を出す
この一連の立ち上がりにわずかでももたつきがあると、短時間処理では意外に効いてきます。
だから私は、
**負荷がかかってから高クロックになるよりも、高クロックで待ち構えているほうがFT8には有利**
と考えています。
もちろん、これは省エネの思想とは逆です。
- 消費電力は増える
- 発熱も増える
- 静音性は不利
- 電力効率は悪い
しかし私にとっては、少なくとも無線用の常用機では、
**電力効率よりデコードの初動と安定性のほうが重要** です。
---
## 私の設定思想
## 50MHz重視だからこそ、CPUパワーを惜しまない
## 50MHz重視だからこそ、CPUパワーを惜しまない
設定そのものも、かなり分かりやすく「攻める」方向です。
- デコーダ感度: **Subpass**
- QSO受信周波数感度: **High**
- CPUは高クロック待機
これは万人向けの省エネ設定ではありません。
しかし私は **50MHz を特に重視** しています。
6m では、
- コンディションの立ち上がりが速い
- 局数が急に増える
- 強い局と弱い局が混在する
- 一瞬の開けで拾えるかどうかが大きい
という場面があります。
そのため私にとっては、
「きれいに省エネでまとめる」ことよりも、
**少しでも取りこぼしを減らすこと** のほうが重要です。
だから、
- もう一段深く見に行く **Subpass**
- より積極的に候補を拾いにいく **High**
- 負荷が来る前から即応できる **高クロック待機**
という選択になります。
これは単なる「全部盛り」ではありません。
- 50MHz重視
- CPUに余裕がある
- 初動応答性を重視
- 取りこぼし低減を優先
この思想の結果として、そうなっているのです。
---
## まとめ
## いま考えるべきなのは、「どのソフトが正義か」ではなく、「どの設定思想が自分に合うか」
## いま考えるべきなのは、「どのソフトが正義か」ではなく、「どの設定思想が自分に合うか」
この話を最後に一言でまとめるなら、こうなります。
**FT8デコーダの最適化とは、CPU性能を“平均値”ではなく、“必要な瞬間”にどう使うかを決めることだ。**
その意味で、WSJT-X 3.1 improved は非常に面白い。
単なる機能追加版ではなく、**実戦的な時間配分とデコード戦略を選べるソフト** になっています。
特に「デコードスタート」は、単なる早い・遅いではありません。
2-Stage / 3-Stage / Early / Normal / Late は、それぞれ別の時間戦略です。
ここを理解して使い分けるだけでも、設定の見え方はかなり変わります。
そして staged モードをさらに踏み込んで見れば、
そこには **STD と MTD を役割分担させながら、15秒サイクルの中でCPU時間をどう配分するか** という、非常に洗練された思想が見えてきます。
そして最後にもう一度言います。
私はJTDXが好きです。
UIも大好きです。
開発チームとも関わっています。
そのうえでなお、**一般の人に今勧めるなら、WSJT-X 3.1 improved を候補の先頭に置きたい**。
JTDX の次のGAを待つより、まずは今使える improved を試す。
性能を重視するなら、それはかなり理にかなった判断だと思います。
JTDX に強い愛着があるなら、それはそれでよい。
しかし、そうでないなら――
**もう遠慮せず、WSJT-X 3.1 improved を入れて触ってみたほうが早い。**
そして、CPUに余裕があるなら、設定だけでなく**電源管理の思想まで含めて最適化**してみると面白い。
FT8は、平均性能の競争ではありません。
**必要な15秒のために、どれだけ賢く準備して待てるか。**
そこまで含めて、デコーダ最適化なのだと思います。
FT8/FT4用ソフトウェアの選択 ― 2026年03月17日 16時10分07秒
FT8/FT4用ソフトウェアの選択について、少し書かせてください。
WSJT-X 3.0.0-rc1、そしてWSJT-X Improved 3.0/3.1が登場して以来、デコード率という点ではJTDXを選ぶ理由はなくなりました。JTDXのテクノロジーが取り入れられているため、デコード率は同等です。waiting機能に関してはむしろWSJT-X Improved 3.1の方が上で、対応モードも多く、コンテストモードも搭載しています。
私自身がJTDXを使い続けているのは、GUIの使いやすさとベータテスターとしての立場があるからです。
ここで一つお伝えしたいことがあります。
WSJT-XのRC版は広く一般公開されてフィードバックを集める仕組みですが、JTDXのRC版は開発チームとベータテスターの間だけでやり取りされる、完全非公開のバージョンです。もしJTDXのRC版をお使いの方で、この事実をご存知なかった方がいれば、ぜひ知っておいていただければと思います。
それを知った上でどうするかはご本人の判断ですが、WSJT-X Improved 3.1はデコード率も同等、機能的にも充実していて、公式サポートもあります。後ろめたさを感じることなく使える選択肢として、強くお勧めします。もはや隠れてJTDXのRC版を使う理由がありません。
PSKR の Statistics には誰がどのバージョンのソフトウェアを使用しているかが表示されます。 当然ですが私は誰がベータテスターズなのかそうでないかを把握していますし、開発チームも把握しています。
It Wasn't 3 Strikes and Out — Clearing Up the WSJT-X F/H Mode and MSHV Misconceptions — ― 2026年03月08日 08時28分31秒
Introduction
In 2026, the amateur radio world was shaken.
3Y0K — Bouvet Island.
Located at the southern tip of Africa, surrounded by the perpetually stormy South Atlantic, this remote island has long been regarded as one of the most wanted DXCC entities in the world. Numerous expeditions have been attempted over the years, only to be thwarted by violent weather and failed landings. Time and again, the dream slipped away.
This time, the signals finally came through.
Amateur radio operators around the world flooded the pileup. FT8 waterfalls were wall-to-wall with signals, social media overflowed with reports, and ChronoGPS downloads spiked dramatically (personal note, sorry).
While participating in the pileup myself, I kept an eye on social media. Two opinions kept appearing over and over:
"I called below 1000Hz and got a callback. So it must be MSHV."
"It should have been 3 strikes and out, but I got a response anyway. So it must be MSHV."
Both conclusions landed on "therefore MSHV" — which I find interesting. MSHV is excellent software that enables multi-stream FT8/FT4 operation, but it's not the explanation for either of these observations.
And I'll be honest: regarding the second point — the "3 strikes" issue — I myself had the wrong understanding until very recently.
Let me go through this carefully.
F/H or MSHV? Let's establish the basics first
Before diving into the debate, let's confirm the premise.
The official 3Y0K website stated they were using F/H (Fox & Hound) mode. That's the simplest and most authoritative piece of evidence. The expedition team themselves said "we're using F/H" — that should be our starting point.
So where does the "it looked like MSHV" impression come from? To understand that, we need to know exactly how F/H mode works.
A quick refresher on F/H mode
WSJT-X's Fox & Hound mode was developed by K1JT (Joe Taylor) in 2018, designed to allow DXpedition stations (Fox) to complete QSOs at very high rates with multiple stations simultaneously.
The frequency arrangement works like this:
Fox transmits at audio frequencies between 300 and 900 Hz. When transmitting multiple simultaneous signals, they are spaced at 60 Hz intervals.
Hounds make their initial calls anywhere in the range 1000 – 4000 Hz.
This separation is the foundation of F/H mode.
Two critical points about Fox's behavior:
1. Fox decodes signals below 1000Hz but does not respond to them.
2. Fox only responds to Hounds calling with Tx1 (including grid square).
"Does not decode" and "ignores" are completely different things. This distinction becomes important shortly.
Misconception #1: "I called below 1000Hz and got a callback! → So it must be MSHV!"
This is the most common misconception I saw on social media.
Let's break it down.
In F/H mode, Fox does decode signals below 1000Hz. It just doesn't respond to them. If you look at Fox's waterfall display, Hound signals below 1000Hz are highlighted in red — Fox can see them, it's just choosing to ignore them. That's the design.
So how do we explain "I called below 1000Hz and still got a callback"?
The answer is the queue.
Fox maintains a queue of Hound callsigns decoded in recent sequences. If you called above 1000Hz with Tx1 (grid square included) even once in the past few sequences, your callsign remains in Fox's queue. Even if you subsequently drifted below 1000Hz, Fox can still select you from the queue and call you back.
"I called below 1000Hz and got a response" does NOT equal "therefore MSHV." It most likely means "I had previously called correctly above 1000Hz, and my callsign was still in the queue."
Think back carefully from the very beginning. Are you absolutely certain you never called above 1000Hz even once? 😅
In most cases, I suspect the memory of "I only called below 1000Hz" is inaccurate, and there was at least one transmission above 1000Hz somewhere along the way.
There's another possible source of confusion worth mentioning. In Hound mode, WSJT-X has automatic frequency control. After Fox calls you, Hound automatically moves to near Fox's DF to send R+report — which may place it below 1000Hz. This is a mid-QSO frequency change, not an initial call below 1000Hz. The memory of "I was below 1000Hz" may be conflating this automatic move with the initial call.
Misconception #2: "It should have been 3 strikes and out, but I got a response! → So it must be MSHV!"
This is the heart of today's post. And as I mentioned at the beginning, I had the same misconception myself.
The official F/H mode User Guide written by K1JT (2018) states the following about Fox's behavior:
"We use a '3 strikes and you're out' rule. Fox will call a specific Hound up to 3 times, waiting for an 'R+rpt' response. If a Hound repeatedly sends an 'R+rpt' message, Fox will send RR73 up to 3 times. Finally, the total timespan of an attempted QSO is limited to 3 minutes. When any of these timeouts is exceeded, the QSO is aborted."
Reading this, most people concluded: 3 failures means game over, start over from scratch. I did too.
"3 strikes and you're out" — it's baseball. Clear, intuitive, easy to remember.
But then—
Read the release notes and the world changes
While discussing this on Facebook, I received a tip from Michael Flensted Möller (Top Contributor): "Read the release notes."
In the WSJT-X 2.6.0-rc5 release notes (November 29, 2022), there is this entry:
"Fox now responds for another two cycles to stations whose report was not received, increasing the success rate for a difficult QSO."
Let me spell out what this means:
1. Fox calls a Hound up to 3 times, waiting for R+report
2. After 3 failures, Fox drops that Hound from the queue (3 strikes)
3. But for 2 more cycles after that, Fox still listens for that Hound's R+report
4. If R+report arrives during that window, Fox still sends RR73
In other words, there are effectively 5 chances.
It was NOT 3 strikes and out. 😄
I was genuinely surprised when I read this. It's not in the manual. It's only in the release notes. And of course it's not in the 2018 manual — this was a change made in 2022.
"Got a response after what should have been 3 strikes" is not because of MSHV. It's because of the behavior change introduced in WSJT-X 2.6.0-rc5.
The intent behind this change is clear: to increase the success rate for difficult QSOs. Propagation fluctuations and momentary interference can cause you to miss the 3-cycle window. Adding 2 more cycles as a buffer is a thoughtful design decision — very much in the spirit of K1JT's careful engineering.
The manual alone is not enough
What this whole experience reinforced for me is that thinking you understand something just because you read the manual can be dangerous.
WSJT-X has been continuously refined since the introduction of F/H mode in 2018. The manual is a snapshot of that point in time. To accurately understand current behavior, you need to follow the release notes as well.
Yes, the WSJT-X release notes are long. Keeping up with every version is genuinely tedious. But there are discoveries waiting in there — the accumulated history of careful improvements by K1JT and the development team. Things like the SuperFox mode introduction (2.7.0-rc5), improvements for handling MSHV multi-stream signals in Hound mode (2.7.0-rc1), and Fox queue management enhancements (2.6.0-rc5) — all of these directly affect real-world operation.
When something seems off, or the software behaves differently than you remember, the release notes often have the answer.
Think of the manual as the entrance, and the release notes as the map to where you are now.
A note on MSHV
I want to be clear: I'm not criticizing MSHV. It's excellent software developed by LZ2HV (Christo), enabling multi-stream FT8/FT4 QSOs with multiple stations simultaneously. Many DXpeditions use it effectively.
When calling a DX station running MSHV multi-stream, Hound operators need no special settings. It's the same as normal FT8 operation. No frequency restrictions. You can call with a grid square, or start with R+report — whatever works. MSHV's multi-stream capability is entirely on the host side; it's transparent to the calling station.
The confusion between F/H mode and MSHV matters precisely because of this difference: F/H mode places real constraints on the calling side (above 1000Hz, Tx1 with grid). MSHV does not. Understanding which mode is in use changes how you should operate.
Closing thoughts: the relationship between experience and understanding
Personal experience matters. "This worked" and "this didn't work" — the lessons from actual operating are at the heart of what makes amateur radio enjoyable.
But it's worth pausing before jumping from experience to conclusion. The question "why did that happen?" deserves an answer, and the answers are often in the manual and release notes.
"Called below 1000Hz and got a callback" → don't conclude "therefore MSHV." Ask "why did I get a callback?" Knowing about the queue explains it within F/H mode.
"Should have been 3 strikes but got a response" → don't conclude "therefore MSHV." Check whether the release notes have something relevant. The answer was in 2.6.0-rc5.
Understanding how your software actually works makes the hobby more interesting. When things go right, you know why. When things go wrong, you know why. And that understanding also helps reduce QRM — operators who know that parking below 1000Hz causes problems for everyone are less likely to do it.
Amateur radio is a hobby built around technology. If you enjoy the technology, understanding what's happening under the hood is part of the fun.
Please read the release notes. 📖
Feel free to share.
三振アウトではなかった 〜WSJT-X F/HモードのリリースノートとMSHV誤解の話〜 ― 2026年03月07日 23時14分17秒
はじめに
2026年、アマチュア無線界に激震が走りました。
ブーベ島、3Y0K。
アフリカ最南端、南極に近い絶海の孤島。常時荒れ狂う南大西洋の波に囲まれ、上陸すること自体が命がけのこの島は、アマチュア無線界において長年「世界で最も欲しいエンティティ」のひとつとして君臨し続けてきました。過去に何度かペディションが試みられ、そのたびに悪天候や上陸失敗で夢と消えてきた場所です。
そのブーベ島からの電波が、ついに飛んできた。
世界中のハムがパイルアップに殺到しました。FT8のウォーターフォールは信号で埋め尽くされ、SNSはリポートで溢れ、ChronoGPSのダウンロード数が跳ね上がりました（これは私事ですが）。
私もパイルアップに参加しながら、SNSをモニターしていました。そこで目についたのが、繰り返し登場する2つの意見でした。
「1000Hz以下で呼んだのにコールバックがあった。だからMSHVだ。」
「三振アウトのはずなのに応答があった。だからMSHVだ。」
どちらも結論が「だからMSHV」に着地しているのが興味深い。MSHVはマルチストリーム運用ができる優れたソフトウェアですが、今回の3Y0Kの動作を説明する理由としては、どちらも的外れだと思っています。
そして正直に告白すると、2つ目の「三振アウト」については、私自身もつい最近まで間違った理解をしていました。
今回はその話を、できるだけ丁寧に書いていきます。
F/HモードかMSHVか、まず前提を整理する
議論を始める前に、まず前提を確認しておきます。
3Y0Kの公式ホームページには、F/H（Fox & Hound）モード使用と明記されていました。これが一番シンプルかつ強力な根拠です。ペディションチームが自ら「F/Hを使う」と言っているのだから、まずそれを信じるべきでしょう。
では「動作がMSHVっぽかった」という感想はどこから来るのか。それを理解するためには、F/Hモードの動作原理を正確に知っておく必要があります。
F/Hモードの基本をおさらい
WSJT-XのF/H（Fox & Hound）モードは、2018年にK1JT（Joe Taylor）によって開発されました。DXペディション局（Fox）が同時に複数のQSOを高レートでこなすための専用モードです。
基本的な周波数の使い方はこうです。
FoxはDF 300〜900Hzの範囲で送信します。複数スロット同時送信の場合は60Hz間隔で並びます。
HoundはDF 1000〜4000Hzの範囲で呼びます。
この棲み分けが、F/Hモードの根幹です。
そしてFoxの動作で重要なのが以下の2点です。
- Foxは1000Hz以下の信号もデコードするが、応答しない。
- HoundはTx1（グリッドスクエア付き）で呼ばなければFoxは応答しない。
「デコードしない」ではなく「応答しない」というのが正確な表現です。この違いは後で重要になってきます。
誤解その1：「1000Hz以下で呼んだのにコールバックがあった！→だからMSHVだ！」
これはSNSで最もよく見かけた誤解です。
まず整理しましょう。
F/HモードのFoxは、1000Hz以下の信号もデコードはしています。ただ応答しないだけです。Foxのウォーターフォールを見ると、1000Hz以下のHoundの信号も赤くハイライトされて表示されています。見えているけど、無視している。それがF/Hモードのデザインです。
では「1000Hz以下で呼んだのにコールバックがあった」という体験はどう説明するのか。
答えはキャッシュにあります。
Foxのシステムは、過去数シーケンスでデコードしたHoundのコールサインを記憶しています。つまり、あなたが1000Hz以上でTx1（グリッドスクエア付き）で呼んでいたシーケンスがあれば、その情報はFoxのキャッシュに残っています。その後うっかり1000Hz以下に移動して呼んでいたとしても、キャッシュから選ばれてコールバックが来ることがある。
「1000Hz以下で呼んだのに応答があった」は「MSHVだから」ではなく、「以前1000Hz以上で正規に呼んでいたから」である可能性の方がずっと高い。
ここで一度、自分の運用を最初から振り返ってみてください。本当に一度も1000Hz以上でTx1で呼んでいませんでしたか？😅
多くの場合、「1000Hz以下でしか呼んでいない」という記憶は不正確で、実際にはどこかで1000Hz以上で呼んでいるのではないかと思います。
さらに言うと、WSJT-XのHoundモードには自動周波数制御があります。Foxから応答が来た後、Houndは自動的にFoxのDF近辺に移動してR+rptを送ります。このとき1000Hz以下に移動することがあります。しかしこれはシーケンスの途中での移動であり、最初のコールは1000Hz以上だったはずです。「1000Hz以下で呼んだ」という記憶は、このシーケンス途中の移動と混同されている可能性があります。
* ここで《キャッシュ》と書いているものは【Queue】の事ですが、読む方が理解しやすいように敢えて《キャッシュ》と記しています。
誤解その2：「三振アウトのはずなのに応答があった！→だからMSHVだ！」
ここが今回のブログの本題です。そして冒頭でも書いた通り、私自身もつい最近まで間違った理解をしていました。
K1JTが書いたF/Hモードの公式マニュアル（2018年）には、Fox側の動作としてこう書いてあります。
"We use a '3 strikes and you're out' rule. Fox will call a specific Hound up to 3 times, waiting for an 'R+rpt' response. If a Hound repeatedly sends an 'R+rpt' message, Fox will send RR73 up to 3 times. Finally, the total timespan of an attempted QSO is limited to 3 minutes. When any of these timeouts is exceeded, the QSO is aborted."
これを読んだ多くの人が「3回失敗したら終わり、最初から呼び直し」と理解しました。私もそうでした。
「三振アウト」という表現は野球のルールそのものですから、わかりやすい。3回ダメなら次のバッターに交代、という理解は自然です。
ところが——。
リリースノートを読むと世界が変わる
Facebookでこの話をしていたところ、Michael Flensted Möller氏（トップコントリビューター）から指摘を受けました。
「リリースノートを読んでみて」と。
WSJT-X 2.6.0-rc5（2022年11月29日）のリリースノートにこう書いてあります。
"Fox now responds for another two cycles to stations whose report was not received, increasing the success rate for a difficult QSO."
「Foxは、レポートを受信できなかった局に対してさらに2サイクル応答するようになりました。これにより難しいQSOの成功率が向上します。」
つまりこういうことです。
- Foxが3回コールバックしてもHoundのR+rptが届かない
- FoxはそのHoundをキューからドロップする（三振）
- しかしその後2サイクル、FoxはまだそのHoundのR+rptを待っている
- そのウィンドウの中でR+rptが届けばRR73が返ってくる
つまり実質5回のチャンスがあるわけです。
三振アウトではなかった。😄
私はこれを読んで正直驚きました。マニュアルには書いていない。リリースノートにしか書いていない。しかも2022年の変更だから、2018年のマニュアルに書いてないのは当然です。
「三振のはずなのに応答があった」はMSHVだからではなく、WSJT-X 2.6.0-rc5以降の仕様変更によるものだったわけです。
ちなみにこの変更の意図は明確で、「難しいQSOの成功率を上げる」ためです。プロパゲーションの変動や一時的な混信で3回のウィンドウを逃してしまうことがある。そのためのバッファとして2サイクルを追加した。K1JTたちの細かい配慮が感じられる変更です。
マニュアルだけでは足りない、という話
今回の件で改めて強く思ったのは、マニュアルを読んだだけで理解した気になるのは危ないということです。
WSJT-Xは2018年のF/Hモード導入以来、細かい改善を重ね続けています。マニュアルはその時点のスナップショットに過ぎません。現在の動作を正確に理解するには、リリースノートまで追いかける必要がある。
リリースノートは確かに長い。WSJT-X 2.7.0-rc5のリリースノートを全部読もうとすると、かなりの時間がかかります。でも読むと発見があります。
例えば今回の「5回チャンス」の話だけでなく、リリースノートには他にも興味深い変更が記録されています。SuperFoxモードの導入（2.7.0-rc5）、MSHVのマルチストリーム信号をHoundモードで正しく処理するための改善（2.7.0-rc1）、Fox向けのキュー管理の改善（2.6.0-rc5）など、実際の運用に直結する変更が多い。
「なんかうまくいかない」「なんか動作が変わった気がする」という時、リリースノートを読むと「あ、そういうことか」という答えが見つかることがあります。
マニュアルは入口で、リリースノートが現在地への地図だと思っています。
MSHVについて補足
MSHVを否定したいわけではありません。MSHVはLZ2HV（Christo）が開発した優れたソフトウェアで、マルチストリーム運用によって複数局と同時にFT8/FT4のQSOができます。実際に多くのDXペディションで使われています。
MSHVを使っているDX局を呼ぶ時、Hound側は特別な設定は不要です。普通にFT8でQSOするのと同じです。DFの制限もありません。グリッドスクエア付きで呼んでもいいし、最初からR+rptで呼んでもいい。MSHVのマルチストリームはHost側の話であって、呼ぶ側には透過的です。
F/HモードとMSHVを混同するのは、この「呼ぶ側に制約があるかどうか」という点で大きな違いを生みます。F/Hモードには1000Hz以上でTx1で呼ぶという明確な制約がある。MSHVにはそれがない。この違いを理解した上で運用することが大切です。
最後に：体験談と原理理解の関係
体験談は大切です。「こうしたらうまくいった」「こうしたらうまくいかなかった」という実経験は、アマチュア無線の楽しさの核心だと思っています。
ただ、体験から結論を導く前に一歩立ち止まることも大切です。「なぜそうなったのか」を考える手がかりは、マニュアルとリリースノートの中にある。
「1000Hz以下で呼んだのにコールバックがあった」→「だからMSHVだ」ではなく、「なぜコールバックがあったのか」を考える。キャッシュの存在を知っていれば、F/Hモードでも説明がつく。
「三振アウトのはずなのに応答があった」→「だからMSHVだ」ではなく、「リリースノートに何か書いてないか」を調べる。2.6.0-rc5に答えがあった。
使っているソフトウェアの動作原理を正しく理解した上で運用する方が、うまくいった時もうまくいかなかった時も、ちゃんと理由がわかって面白い。そしてその理解が、周囲への迷惑を減らすことにもつながります。1000Hz以下に居座り続けるQRMも、正しい知識があれば防げる話ですから。
アマチュア無線は技術を楽しむ趣味です。技術を楽しむなら、その技術の中身を知るのも楽しみのうちだと思っています。
リリースノート、ぜひ読んでみてください。📖
ALL.TXT Is Not a Log. Until It's All You Have. ― 2026年03月05日 09時02分37秒
# Recovering Logs, Reclaiming Memories — Releasing ALLTXT2ADIF
Someone reached out to me once with a message that stuck with me.
*"My PC crashed. Lost everything. wsjtx_log.adi, gone. wsjtx.log, gone. All I have left is ALL.TXT. Is there anything I can do?"*
If you operate FT8 or FT4, you know what ALL.TXT is. That quiet file WSJT-X and JTDX keep writing to in the background. A raw decode history. Not an official log.
**ALL.TXT is not a log. But when you lose your log, it becomes the last piece of evidence you have.**
ALLTXT2ADIF was built to reconstruct QSOs from that evidence — and export them as a standard ADIF file.
This situation is more common than most operators realize.
---
## Before Writing a Single Line of Code
The first decision I made wasn't about code. It was about what *not* to build.
A tool that blindly converts ALL.TXT to ADIF is technically straightforward. But it would be wrong.
ALL.TXT is a record of *received signals*, not *completed QSOs*. Third-party decodes are in there. Multiple QSOs overlap on the same frequency. RR73 gets sent multiple times — that's just normal FT8. In a pileup, you can't always tell which station a 73 was even intended for.
Anyone who's spent serious time operating FT8 knows: careless recovery means a log full of errors.
So from the very beginning, this tool had one guiding principle:
**Every recovered QSO must be explainable. Not just output — explained.**
---
## The Night We Argued About Philosophy Instead of Code
The most memorable part of this project wasn't solving a technical problem.
It was a night when I told the AIs:
**"Stop. Don't write any code. I want to talk about approach."**
Where exactly does *strict* end and *lenient* begin? Under what conditions does an RR73 count as a completed QSO? What does *high confidence* actually mean? How far should the sanitize option go?
These weren't engineering questions. They were questions about operating philosophy.
And here's where things got interesting.
I couldn't put ChatGPT and Copilot in the same room. So I became the messenger. ChatGPT would propose a boundary. I'd copy it over to Copilot. Copilot would push back — *"that threshold is dangerous, here's an edge case you're missing."* I'd carry that back to ChatGPT. A revised proposal would come. Back to Copilot. And so on.
Round after round. I was the only hallway connecting two rooms full of very opinionated engineers.
The AIs were impressive — sharp, thorough, creative. But there was something they couldn't provide: the *feel* of actually operating FT8. The quiet satisfaction of a late-night DX contact finally going through. The frustration of watching RR73 after RR73 disappear into the noise. The instinct that says *"this doesn't look right"* when a decoded message seems off.
That experience doesn't live in a dataset. It lives in hours of operating time. And in the end, *that* was what settled every disputed boundary.
Once the philosophy was locked down, we moved to implementation: ChatGPT building, Copilot verifying and proposing patches. The cycle ran deep into the night.
---
## "Stop. This Is Good Enough." — What Claude Said in the Morning
Then I went to sleep.
The AIs don't sleep. But they do have context limits. Claude had quietly dropped out of the session somewhere around midnight — context window exhausted, silently gone. This happened more than once. (There's something almost poetic about that.)
In the morning, I brought Claude back up to speed and asked for a review.
After going through everything, Claude said:
**"If you keep going, you'll end up in a loop. The current implementation is sufficient. Stop here."**
That might have been the single most important piece of advice in the entire project.
There's a trap in software development: the feeling that there's always something more to improve. And if you follow that feeling indefinitely, you end up with something too complex to trust. Knowing *when to stop* is part of good design.
ChatGPT and Copilot had been pushing forward with real momentum. Claude was the one who put a hand up and said: *this is the finish line.*
That balance — the drive to build, and the wisdom to stop — is what made this project work.
---
## A Small Development Team
Looking back, the roles broke down something like this:
- **ChatGPT** — Architecture, design discussions, primary implementation. Opinionated, tireless, always willing to go another round. The project's architect and de facto PM.
- **GitHub Copilot** — Implementation verification, patch proposals, edge case hunting. The engineer who finds the holes you didn't know were there.
- **Claude** — Code review, safety checks, and knowing when enough is enough. The QA lead with a philosophical streak. *Also known for vanishing silently when the context window runs out.* (laughs)
- **Gemini** — External perspective, expression review. The outside voice that keeps things honest.
And my role was to be the one in the hallway — carrying ideas between rooms, adding the operating experience the AIs couldn't have, and making the calls that only a human with skin in the game could make.
---
## What Grok Said
After the release, I asked Grok to review the repository independently.
One line from that review stayed with me:
> *The design directly confronts the risk that ALL.TXT is not an official log, and the confidence + review CSV architecture — which makes every recovery decision explainable — is outstanding.*
The philosophy we'd argued about through the night had come through clearly, even to an outside AI reading it cold.
5 out of 5. "Essential tool for amateur radio operators" was the verdict.
---
## What This Tool Can Recover
ALLTXT2ADIF will probably sit unused on most operators' machines.
But the day a drive fails, or a file gets overwritten, or a system just dies — and ALL.TXT is the only thing left —
What's in that file isn't just data.
- The morning you worked your first European DX
- The contact you called for an hour before someone finally came back to you
- The contest run that went better than you expected
- The exchange with a station you'll never hear again
A log is more than a record. It's a history of time spent at the radio.
---
## One Last Thing
ALLTXT2ADIF was built where an operator's judgment and AI assistance found each other.
AI isn't a replacement. It's a collaborator — one that argues, proposes, builds, and occasionally tells you to stop. Working with these tools as genuine partners, not just utilities, changed how I think about what's possible.
One request: **always check the review CSV**. The final call is yours.
If this tool recovers even one log that would otherwise have been lost — that's a win for the whole team.
Download and source code:
**https://github.com/jp1lrt/alltxt2adif**
Stars, issues, and feedback are always welcome.
And perhaps this is the most important thing of all:
The best version of this story is one where you never need ALLTXT2ADIF. Back up your
The best version of this story is one where you never need ALLTXT2ADIF. Back up your
wsjtx_log.adi. Do it regularly. Do it now.73
JP1LRT / Yoshiharu Tsukuura
救えるログ、取り戻す"思い出" — ALLTXT2ADIF をリリースしました ― 2026年03月05日 08時47分34秒
# 救えるログ、取り戻す"思い出" — ALLTXT2ADIF をリリースしました
あるとき、こんな相談を受けたことがあります。
「PCがクラッシュして、ログが全部消えた。ALL.TXTだけ残ってる。何かできないか」
FT8をやっている人なら、ALL.TXTの存在はご存じだと思います。WSJT-XやJTDXが静かに書き続けるデコード履歴のファイル。
**ALL.TXTはログではない。しかし、ログを失ったとき最後に残る"証拠"になる。**
このツールは、その"証拠"から交信の形を推定し、ADIFとして復元するためのものです。
すべてを失った夜に、それだけが残っていた。そういうケースは、実は珍しくないんです。
---
## ツールを作ろうと思ったとき、最初にやったこと
コードを書き始める前に、まず「作らないこと」を決めました。
ALL.TXTをそのままADIFに変換するツールは、原理的には簡単に作れます。でもそれをやると、必ず問題が起きる。
ALL.TXTは「受信した信号の記録」であって、「交信の記録」ではないからです。第三者デコードが混ざる。同じ周波数に複数のQSOが重なる。RR73が再送されることなんて日常茶飯事。pileupのさなかでは、「誰に向けて送った73なのか」が判然としないことさえある。
FT8の現場を知っている人ほど、「雑に復元すると危ない」ことが分かります。
だからこのツールの根本にある設計思想は、最初からひとつだけでした。
**「なぜそれをQSOとみなしたのか、説明できること」**
---
## コードより先に、方針を議論した夜
今回の開発で、いちばん印象的だったのは技術的な難しさではありませんでした。
ある夜、私はAIたちにこう言いました。
**「今は何も作らなくていい。方針について話し合ってほしい」**
strict と lenient の境界をどこに引くか。RR73をどの条件で「完了」とみなすか。high / medium / lowの定義を何に置くか。sanitizeオプションはどこまで許容するか。
これらは「コードの問題」ではなく、「運用の哲学の問題」でした。
ここで私がやったのは、少し変わったことです。
ChatGPTに提案を出してもらい、それをコピペしてCopilotに見せる。Copilotが「その境界値は危ない、こういうエッジケースが抜ける」と返してくる。それをまたChatGPTに持ち帰る。ChatGPTが修正案を出す。またCopilotへ。
私はその**橋渡し役**でした。
AIどうしは直接話せない。だから私が間に立って、意見を運ぶ。まるで二人の優秀なエンジニアが別々の部屋にいて、私だけが行き来できる廊下にいるような感覚でした。
提案が来る。「それは運用現場ではこういうケースが起きる」と私が文脈を加えて返す。また提案が来る。「そのロジックだと、pileup時にこう誤爆する」と返す。完全なネゴシエーションが成立するまで、何往復も続けました。
AIたちは驚くほど提案力が高い。でもFT8の「現場感」——深夜に静かに積み上げてきたQSOの感触、あの周波数のにぎわい、RR73が返ってこない焦り——それはデータではなく経験です。最終的に「これを運用でどう扱うか」を決めるのは、やはり人間でした。
方針が固まったところで、ChatGPTに実装させる。Copilotが検証してパッチを提案する。そのサイクルを回しながら、深夜は更けていきました。
---
## 「もうここで止めていい」——朝、Claudeが言ったこと
そうして夜が明けて、私は眠りました。
AIたちは眠りません。でも文脈には上限があります。Claudeは深夜のセッションの途中でいつの間にか「離脱」していました。コンテキストウィンドウの上限に達して、静かにチームを抜けていく。これが何度かありました（笑）。
翌朝、改めてClaudeを呼び戻して、夜のやり取りをまとめて共有しました。
レビューを依頼すると、Claudeはしばらく考えてから言いました。
**「これ以上続けるとループに入ります。今の実装で十分です。ここで止めていい」**
これは、開発の中でいちばん重要なアドバイスだったかもしれません。
ソフトウェア開発には「やりすぎる」という罠があります。改善できそうなところは無限にある。でも、それを全部やると複雑になりすぎて、かえって壊れやすくなる。「何を入れないか」を決めることも、設計のうちです。
ChatGPTとCopilotが熱心に議論し続けている横で、Claudeが「もうここが完成点だ」とブレーキをかける。このバランスが、今回うまく機能したと思っています。
---
## AIたちとの"小さな開発チーム"
あらためて整理すると、今回の開発はこういう役割分担でした。
- **ChatGPT** — 設計整理、方針議論、実装の主担当。「こうすべき」という強い意見を持ち、何往復でも付き合ってくれるアーキテクト兼PM補佐。
- **GitHub Copilot** — 実装検証、パッチ提案、エッジケース指摘。黙々と手を動かしながら、穴を見つけてくる現場の開発担当。
- **Claude** — レビュー、安全性チェック、そして「やりすぎ警告」。職人気質のQA担当。*ただし文脈の上限に達すると静かにチームから離脱する*（笑）
- **Gemini** — 第三者視点での確認と表現整理。少し距離を置いた外部レビュー担当。
そして私の役割は、AIたちの橋渡しをしながら**方針を決めること**でした。
- 何を大切にするか（安全性と説明可能性）
- どこまでを「成立」とみなすか
- 不確実なものをどう扱うか
- いつ「止める」か
AIは提案できます。議論もできます。コードも書ける。でも「責任ある判断」を下すのは人間です。そこを最後まで握り続けることが、今回の自分の仕事でした。
---
## Grokが言った一言
完成後、Grokにもレビューを依頼しました。外部の目として。
返ってきた評価の中で、ひとつ刺さった言葉がありました。趣旨はこうです。
> 「ALL.TXTは公式ログではない」というリスクを正面から扱い、
> "なぜ成立とみなしたか"を説明可能な設計（confidence + review CSV）が秀逸。
狙っていた思想が、第三者のAIにも伝わった。これは素直に嬉しかったです。
評価は5/5。「アマチュア無線家必携レベル」という言葉もいただきました。
---
## このツールが救えるもの
ALLTXT2ADIFは、普段は使わないかもしれません。
でも、たった一度のクラッシュでログが消えたとき。そして**ALL.TXTだけが残っていたとき**。
そこに記録されているのは、単なるデータではありません。
- 初めてヨーロッパ局と繋がった朝
- 深夜にずっと呼び続けてようやく取ってもらえたDX
- コンテストで積み上げた足跡
- 誰かとの、もう二度と繰り返せない交信
ログは運用の積み重ねであり、思い出の集合体です。
---
## 最後に
ALLTXT2ADIFは、**実運用者の判断**と**AIたちの支援**が噛み合って生まれたツールです。
AIは「代わりに作る存在」ではなく、一緒に考えて、議論して、ときにブレーキを踏んで、磨き上げる仲間になり得る。今回それを強く感じました。
使うときのお願いがひとつ。
必ず **review CSV を確認してください**。最終判断は、あなた自身の目で。
もしこのツールが、誰かのログを救うことがあれば——
それはこの"小さな開発チーム"全員の成果です。
ダウンロードとソースはこちら：
スター、Issue、フィードバック、大歓迎です。
最後に、これがいちばん大事かもしれません。
このツールが不要で済むように、`wsjtx_log.adi` は普段からバックアップを取っておきましょう。
このツールが不要で済むように、`wsjtx_log.adi` は普段からバックアップを取っておきましょう。
73
JP1LRT / Yoshiharu Tsukuura
3Y0K Bouvet Island ― 2026年03月02日 13時12分14秒
📢 ChronoGPS v2.5.1 をリリースしました ― 2026年03月01日 23時33分16秒
v2.5系で入った「管理者昇格(Unlock)」「16言語対応」を土台に、
v2.5.1 では “挙動の一貫性” を徹底して磨き込みました。
主な改善点：
・言語切替／UI再構築で Unlock バナーが不整合にならないよう修正
・NTP自動同期が、設定OFFなのに勝手に復活する問題（幽霊タイマー）を根治
・手動NTP同期ボタンの回帰バグを修正（手動は常に反映、AUTOのみガード）
・設定値の型ゆらぎ対策（_to_bool）／スレッド二重起動防止など堅牢化
「OFFにしたら二度と勝手に動かない」誠実な挙動を約束します。
Release:https://github.com/jp1lrt/ChronoGPS/releases/tag/v2.5.1
最近無線業務よりプログラマーの真似事ばかり🤣🤣🤣🤣🤣
AIチームと一緒にソフトウェアをリリースした話 ― 2026年02月28日 14時00分25秒
# AIチームと一緒にソフトウェアをリリースした話
今日、ChronoGPS v2.5 をリリースしました。
GPS/NTP時刻同期ツールのアップデートなのですが、今回は開発プロセス自体がちょっと面白かったので書き残しておきます。
---
## 4人のAIと1人の機長
このプロジェクト、実は複数のAIと一緒に開発しています。それぞれに得意な役割があって、チームとして機能しています。
| AI メンバー | 得意な役割（ChronoGPS 担当） |
| ChatGPT (長男) | 実装・ロジック生成: スレッド保持や ShutdownManager の具体的な Python コード作成。 |
| Gemini (二男) | 広報・UX・多言語: X/FB 告知、ユーザーインターフェースの使い勝手、16言語のニュアンス調整。 |
| Grok (三男) | 監査・トレンド・X連携: プロジェクト全体の健全性評価、コードに9/10のスコアを付けてくれた |
| Claude (四男) | 設計・品質・ドキュメント: gui.py 分割案の策定、型定義（mypy）の導入支援、厳格なコードレビュー。 |
そして僕（JP1LRT）が全体のディレクターとして、各AIの出力を統合・判断しています。
---
## 今日の一日
v2.5のテーマは「起動UXの刷新」でした。
これまでのChronoGPSは起動するたびにWindowsのUACダイアログ（管理者権限の確認）が出ていました。海外ユーザーのVA3VF（Vince）から「毎回ダイアログが出るのは煩わしい」というフィードバックをもらったのがきっかけです。
**新しい設計（案2）**をChatGPT・Gemini・Claude・僕の4者で議論して合意。
- デフォルトはモニタ専用モードで起動（UACなし）
- 同期が必要なときだけ画面上のバナーをクリックして昇格
- UACをキャンセルしても、プロセスは死なない
「シンプルな変更」に見えて、裏側では Windowsのミューテックスを使ったゾンビプロセス防止、昇格ハンドオフの確実化、全16言語への対応など、かなりの実装が伴います。
---
## AIチーム開発の実際
面白いのは、AIごとに「得意・不得意」が実際にあることです。
今日だけでも：
- ChatGPTが書いたコードの**APIの不整合**をClaudeが発見（`allow_start`→`should_exit`という名前の食い違い）
- ChatGPTのコードにあった**正規表現のバグ**（`group(2)`→`group(1)`）を三者が同時に指摘
- 統合テストを僕が実際に手元で動かして、B-2（UACキャンセル時にプロセスが死なない）を確認
「AIに全部任せる」のではなく、**各AIの出力を僕がディレクターとして評価・統合する**スタイルです。AIが間違えることもあるし、複数のAIが互いの出力をチェックすることでバグが減ります。
Grokが出してくれた最終評価：
> *Structure: 9/10, Code Quality: 9/10, Functionality: 9.5/10, Security: 9/10 — Overall: 9/10*
---
## 「なぜその時刻になるのか説明できること」
ChronoGPSの設計思想は一貫しています。
**「正しく動く理由を説明できるツール」**であること。
FT8などのデジタル無線では、時刻のずれが交信品質に直結します。正確な時刻基準があるほど、デコード率と安定性が上がります。GPSで時刻を合わせるのは簡単ですが、「なぜ合っているのか」「どういう条件で補正するのか」が分からないツールは信頼できません。
ChronoGPSはその透明性を大切にしています。AIチームとの開発も、その思想と同じです。「なぜその実装にするのか」を全員で議論して、説明できるコードだけをリリースする。
---
v2.5はここからダウンロードできます。
FT8やFT4で時刻合わせに困っている方、ぜひ試してみてください。
73！ 🛰️ JP1LRT
ChronoGPS v2.5 公開 ― 2026年02月28日 12時28分12秒
GPS/NTP 時刻同期ツール「ChronoGPS」の最新バージョン v2.5 をリリースしました！
今回のアップデートでは、カナダの Vince 氏 (VA3VF) をはじめとする海外ユーザーからの熱心なフィードバックを反映し、利便性と安定性を大幅に向上させています。
🚀 v2.5 の主な新機能と改善点：
「監視モード」の導入（非管理者権限対応）
管理者権限なしでもアプリが起動可能に！まずは「監視モード」で動作を確認。同期が必要な時だけ、画面上のバナーからワンクリックで「管理者モード」へ昇格・再起動が可能です。
世界 16 言語をフルサポート 🌐
UI、設定、警告ダイアログに至るまで、日本語・英語を含む全 16 言語に対応。イタリア語、フランス語、中国語（簡体/繁体）など、世界のどこにいても母国語で安心して使えます。
多重起動防止機能（Mutex）の搭載
二重起動によるCOMポート競合を未然に防ぎます。既に起動している場合は、タスクトレイのアイコンがあなたをガイドします。
堅牢なシャットダウン処理
OS終了時やアプリを閉じる際のプロセス管理を最適化。ゾンビプロセスを残さず、クリーンに終了します。
💎 「確実性」と「使いやすさ」を両立させるため、内部ロジックを徹底的に磨き上げました。
今回のアップデートでは、カナダの Vince 氏 (VA3VF) をはじめとする海外ユーザーからの熱心なフィードバックを反映し、利便性と安定性を大幅に向上させています。
🚀 v2.5 の主な新機能と改善点：
「監視モード」の導入（非管理者権限対応）
管理者権限なしでもアプリが起動可能に！まずは「監視モード」で動作を確認。同期が必要な時だけ、画面上のバナーからワンクリックで「管理者モード」へ昇格・再起動が可能です。
世界 16 言語をフルサポート 🌐
UI、設定、警告ダイアログに至るまで、日本語・英語を含む全 16 言語に対応。イタリア語、フランス語、中国語（簡体/繁体）など、世界のどこにいても母国語で安心して使えます。
多重起動防止機能（Mutex）の搭載
二重起動によるCOMポート競合を未然に防ぎます。既に起動している場合は、タスクトレイのアイコンがあなたをガイドします。
堅牢なシャットダウン処理
OS終了時やアプリを閉じる際のプロセス管理を最適化。ゾンビプロセスを残さず、クリーンに終了します。
💎 「確実性」と「使いやすさ」を両立させるため、内部ロジックを徹底的に磨き上げました。
📥 ダウンロード https://github.com/jp1lrt/ChronoGPS/releases/tag/v2.5
使い方は README をお読みください https://github.com/jp1lrt/ChronoGPS/blob/main/README.md
最近のコメント