WSJT-X 3.1 improved の
FT8デコーダ設定を読み解く

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 の「デコードスタート」が内部で何をしているのか を軸に、少し技術寄りに整理してみたいと思います。

まず結論

迷ったら 標準。CPU に余裕があるなら 3ステージ。非力なら Early

最初に実用上の結論を書いておきます。

FT8 のデコーダ設定で一番重要なのは、「最も重い設定を使う」ことではありません。

それは：「15秒サイクルの中で安定して処理が終わる、最も攻めた設定を使う」 こと。これはまったく異なる考え方です。

出発点として無難なのは次のあたりです：

この状態を基準にして、CPUに余裕があるなら少しずつ攻める。逆に、Lag や次周期への食い込みが見えるなら、重さを戻す。この考え方が基本です。

デコードスタート についての実用まとめ：

ただし、この項目は単なる「早い・遅い」設定ではありません。実際には、デコーダを何段で呼ぶか、どこで軽く見るか、どこで本番を走らせるか に関わっています。この「単なる開始時刻設定ではない」という点こそが、今回の話の核心です。

はじめに

なぜ今あらためて WSJT-X 3.1 improved なのか

まず前提として、ここ数年の流れを見ると、WSJT-X improved は単なる"別物"ではなく、かなり実戦的な進化の受け皿になってきました。

使い勝手の改善だけでなく、デコード周りのチューニング、GUIの選択肢、動作の柔軟性など、従来の「本家は安定、派生は趣味」という単純な図式では語りにくくなっています。

実際、いまの improved を触るとすぐ分かります。

むしろ現在の論点は、いま現実に使える高機能版として 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ステージ
• 3ステージ
• Early
• 標準
• Late

見た目だけなら、単に 「デコード開始を早めるか、遅らせるか」 に見えます。しかし実際には、それだけではありません。

WSJT-X 3.1 improved の実ソース（jt9.f90）を追うと、この項目は内部的に以下として扱われています：

• 0 = 2-Stage
• 1 = 3-Stage
• 2 = Early
• 3 = Normal
• 4 = Late

そして、m_hsymStop や m_earlyDecode、m_earlyDecode2 を使って、どの時点でデコーダを起動するか を切り替えています。

その意味を理解しやすくするために、まずは比較的分かりやすい Early / Normal / Late から整理し、その後で本当に重要な 2ステージ / 3ステージ に進みます。

Early / Normal / Late

まず単純な3つを整理する

まずは比較的分かりやすい3つから見ましょう。マルチスレッドFT8デコーダ使用時、内部ではおおむね次のような停止点（nzhsym値）になっています：

• Early → 48
• Normal → 49
• Late → 50

時間に直すと概算で：

• Early → 約 13.8秒
• 標準 → 約 14.1秒
• Late → 約 14.4秒

つまり：

• Early は少し早めに打ち切ってCPU余裕を作る
• Late は最後まで材料を集めてから判定する
• 標準 はその中間

これは直感通りです。もし Decode Start がこの3つだけなら、「少し早く切るか、最後まで待つか」という、比較的分かりやすい設定だったでしょう。しかし improved は、そこにさらに踏み込んでいます。本当に面白いのは、次の 2ステージ / 3ステージ です。

追記解説

2ステージ / 3ステージ とは何か

単なる「早い・遅い」設定ではなく、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ステージ / 3ステージ は単なる「デコード開始時刻の違い」ではなく、複数の時点で段階的にデコーダを起動する多段処理 であることが分かります。そして重要なのは、その各段で 同じデコーダをただ繰り返すのではない という点です。

STD と MTD の役割分担

ここでいう STD は、従来からある単一スレッドの FT8 デコーダです。一方 MTD は、v3.0.0 で導入されたマルチスレッド FT8 デコーダです。

実装を追うと、2ステージ / 3ステージ では、

• 早期段では STD
• 最終段では MTD

という役割分担になっています。つまり、これは 「まず軽く速く見に行く段階」と「最後に本格的に詰める段階」を分けた設計 と理解するのが正確です。

単純に考えれば、「最後まで受信してから一度だけ重いデコードをかければよい」と思いがちです。しかし improved はそうしていません。途中の段階でも一度候補探索を行い、拾えるものは先に拾い、最後に改めて本格デコードを行う。つまり、15秒という短いサイクルの中でCPU時間をどう配分するか をかなり意識した設計になっています。

2-Stage とは何か

ここは名称だけを見ると少し誤解しやすいところです。2-Stage も、実装上は単純な「2段構成」ではありません。

ソースを素直に追うと、2-Stage では

1. 早期段 で nzhsym=41 にて STD pre-pass
2. 中間段 で nzhsym=46 にてもう一度 STD pre-pass
3. 最終段 で 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ステージ では

1. 早期段 で nzhsym=41 にて STD pre-pass
2. 中間段 で nzhsym=46 にてもう一度 STD pre-pass
3. 最終段 で 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」と理解すべき

この話で誤解しやすいポイントが一つあります。CHANGE LOG には「STD と MTD を組み合わせる」とあります。これだけを読むと、「まず MTD が走って、その取りこぼしを後から STD が補う」 ようなイメージを持つかもしれません。

しかし実装を見る限り、実際の理解としてはその逆です。より正確には、

• STD が先に軽く・速く見に行く
• 最後に MTD が本格的に詰める

つまり 2ステージ / 3ステージ は、MTD の後処理として STD が補完する方式ではなく、STD で先行偵察し、最後に MTD が本命処理をする方式 だと考えるべきです。

この違いは重要です。後者だと 「時間の早い段階では軽量系、最後の段階では重量級」 という、きわめて合理的な時間配分設計として見えてきます。

なぜ途中段で STD を使うのか

もし目的が単純に「デコード回数を増やす」だけなら、途中段でも MTD をそのまま回せばよさそうに見えます。しかし improved はそうしていません。これはおそらく、早期段は"軽く・速く"動かすことに意味がある からです。

まだ受信が完全に終わっていない時点では、利用できる情報量も最終段より少ない。その段階で最も重い処理を毎回全力で回すのは、CPU時間の使い方として効率が悪い可能性があります。そこで、途中段は STD によって軽快に見に行き、最終段で MTD による本格処理を行う。これは、FT8 のような短時間バースト処理に適した設計思想 と言えます。

さらに実装では、早期段ではデコード回数も少し抑えられており、「途中段で無駄に重くしすぎない」配慮も見えます。つまり 2ステージ / 3ステージ は、単なる"複数回実行"ではなく、各段の役割を変えながら段階的に精度を上げていく方式 なのです。

2ステージ / 3ステージ の本質は「時間配分の戦略」

結局のところ、2ステージ / 3ステージ の本質は何か。それは、

• 早い段階で一度見に行くのか
• 中間でもう一度見るのか
• 最後まで待ってから本格処理するのか

これを一つのスイッチで切り替えているのが、Decode Start の staged モードです。したがって 2ステージ / 3ステージ は、単なる「早い／遅い」設定ではなく、FT8 のデコーダをどう時間軸上に展開するかを決める、多段戦略そのもの だと理解するのが最も正確です。

さらに重要な点

staged モードは「複数回回す」のではなく、「各段の役割を変える」

ここまでの話を少し引いて眺めると、2ステージ / 3ステージ の面白さは、単にデコーダを複数回呼ぶことではありません。本質は、各段で役割を変えている ことにあります。

• 途中段では軽く速く見る
• 最終段で本格的に詰める
• CPU時間を一気に使い切るのではなく、段階的に配分する

これはFT8というモードの性格によく合っています。受信の最後まで待って一発で勝負するのも一つですが、途中で拾える候補は途中で拾い、最後にもう一度詰める。この考え方は、短時間バースト処理としてのFT8をよく理解した設計だと思います。

つまり staged モードを理解することは、そのまま FT8の最適化とは何か を理解することにつながっています。

実戦的な解釈

どのモードをどう使うべきか

ここまでの技術的な話を、最後にもう一度実戦の言葉に戻して整理しておきます。

2ステージ

かなり実戦的です。軽快さを保ちつつ、途中でも拾いにいく。最終段は Late ほど遅くないので、CPUに厳しすぎない。

3ステージ

一番欲張りです。よい意味で。途中でも拾いにいき、最後まで待ってもう一度詰める。CPUに余裕があり、取りこぼし低減を重視するなら非常に面白い設定です。

Early

これは非力CPU向けの逃げではありません。むしろ、安定動作を最優先するための現実的な戦略 です。少し早く切り上げることで、次周期への食い込みを防ぎやすくなります。

標準

基準点です。まずはここから始めるのが最も分かりやすい。他設定の差も見えやすい。

Late

最後まで材料を集めてから一発勝負。理屈上は有利に見えますが、CPU余裕が少ない環境では、間に合わなければ意味がありません。

ここまで整理すると、Decode Start の各モードは「好み」ではなく、

では、何を最適化するのか

それは「平均性能」ではなく「15秒の中の時間配分」である

ここまで読んで分かる通り、FT8の最適化とは、単なる高性能化ではありません。

• どこまで信号を待つか
• 何回見に行くか
• どこで軽く見るか
• どこで本気を出すか
• それを次周期に食い込まず終えられるか

つまり、CPU性能の使い方そのもの です。この視点で見ると、「デコードスタート」は非常に本質的な項目です。見た目の一項目に過ぎませんが、実際には 時間戦略そのもの を選んでいます。

だからこそ、Decode Start の理解は、単なる設定解説に留まりません。それは、FT8における"計算資源の哲学" を理解することでもあります。

ここから少し個人的な話

なぜ私はこのことをわざわざ書くのか

ここまで、できるだけ一般論として書いてきました。しかし最後に少しだけ、私自身の立場を明かしておきます。

JTDX の次のGAを待つより、現時点で実際に動いていて、性能面でも機能面でも非常に魅力的な improved を使うほうが、現実的で合理的だと思います。これは JTDX を否定する話ではありません。むしろ逆です。JTDX をよく知っているからこそ、WSJT-X 3.1 improved に取り込まれている技術的価値が見える のです。

そして、私自身の設定はどうしているか

ここまで一般論と技術論を中心に話してきましたが、最後に私自身の考え方も少しだけ書いておきます。

私の常用PCは Core i9-9900K です。そしてこれは、単に「9900Kを使っています」で終わる話ではありません。

私の環境では、Windows の電源設定で 最小のプロセッサ状態を 100% にしています。つまり、負荷が来てからクロックを引き上げるのではなく、最初から高クロックで待ち構える 設定です。実働は 4.7GHz です。

この設定にしている理由は明確です。FT8のデコードは、動画エンコードのように長時間ずっと高負荷をかけ続ける処理ではありません。むしろ、決まったタイミングで、短時間に、一気に、集中的に仕事を片付ける、短時間バースト処理 に近い性格を持っています。

こういう処理で効いてくるのは、平均性能だけではありません。処理開始直後の応答性 が重要です。CPUが省電力状態で待機していて、

• 負荷を検知し
• P-state が切り替わり
• クロックが上がり
• 電圧が追従し
• スケジューラが本気を出す

この一連の立ち上がりにわずかでももたつきがあると、短時間処理では意外に効いてきます。だから私は、

もちろん、これは省エネの思想とは逆です。消費電力は増える、発熱も増える、静音性は不利、電力効率は悪い。しかし私にとっては、少なくとも無線用の常用機では、電力効率よりデコードの初動と安定性のほうが重要 です。

私の設定思想

50MHz重視だからこそ、CPUパワーを惜しまない

設定そのものも、かなり分かりやすく「攻める」方向です。

• デコーダ感度: サブパスを使用
• QSO受信周波数感度: High
• CPUは高クロック待機（最小プロセッサ状態 = 100%、実働 4.7GHz）

これは万人向けの省エネ設定ではありません。しかし私は 50MHz を特に重視 しています。6m では、

• コンディションの立ち上がりが速い
• 局数が急に増える
• 強い局と弱い局が混在する
• 一瞬の開けで拾えるかどうかが大きい

という場面があります。そのため私にとっては、「きれいに省エネでまとめる」ことよりも、少しでも取りこぼしを減らすこと のほうが重要です。だから、もう一段深く見に行く サブパスを使用、より積極的に候補を拾いにいく High、負荷が来る前から即応できる 高クロック待機 という選択になります。

これは単なる「全部盛り」ではありません。50MHz重視、CPUに余裕がある、初動応答性を重視、取りこぼし低減を優先、この思想の結果として、そうなっているのです。

まとめ

いま考えるべきなのは、「どのソフトが正義か」ではなく、「どの設定思想が自分に合うか」

この話を最後に一言でまとめるなら、こうなります。

その意味で、WSJT-X 3.1 improved は非常に面白い。単なる機能追加版ではなく、実戦的な時間配分とデコード戦略を選べるソフト になっています。

特に「デコードスタート」は、単なる早い・遅いではありません。2ステージ / 3ステージ / Early / Normal / Late は、それぞれ別の時間戦略です。ここを理解して使い分けるだけでも、設定の見え方はかなり変わります。

そして staged モードをさらに踏み込んで見れば、そこには STD と MTD を役割分担させながら、15秒サイクルの中でCPU時間をどう配分するか という、非常に洗練された思想が見えてきます。

そして最後にもう一度言います。私はJTDXが好きです。UIも大好きです。開発チームとも関わっています。そのうえでなお、一般の人に今勧めるなら、WSJT-X 3.1 improved を候補の先頭に置きたい。

JTDX の次のGAを待つより、まずは今使える improved を試す。性能を重視するなら、それはかなり理にかなった判断だと思います。JTDX に強い愛着があるなら、それはそれでよい。しかし、そうでないなら――

そして、CPUに余裕があるなら、設定だけでなく電源管理の思想まで含めて最適化してみると面白い。FT8は、平均性能の競争ではありません。必要な15秒のために、どれだけ賢く準備して待てるか。そこまで含めて、デコーダ最適化なのだと思います。