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 は軽い
• 低閾値を使用 は中庸
• サブパスを使用 は重いが攻める

サブパスを使用 は "無料の性能向上" ではありません。弱い信号や難しい信号を拾える可能性と引き換えに、追加の処理コストがかかります。

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時間をどう配分するか をかなり意識した設計になっています。

開発者から見た STD pre-pass の意味

Uwe Risse / DG2YCB によれば、この STD pre-pass の重要な意味は、単に「前処理を1回追加する」ことではありません。むしろ、従来の STD デコーダで知られていた early decoding の利点を、MTD を使っている場合にも活かせるようにすることにあります。

開発時には、STD と MTD のさまざまな組み合わせ、そして複数の nzhsym パラメータが試されました。その結果、STD を pre-pass として使い、その後に MTD を main pass として使う 現在の構成が、実用上もっとも良い結果を示したとのことです。

これは非常に重要な点です。つまり、2ステージ / 3ステージ は単に「デコードを複数回走らせる」機能ではありません。STD の軽快な early decoding と、MTD の本格的な最終デコードを組み合わせることで、15秒サイクル内のCPU時間をより有効に使うための設計だと理解できます。

さらに Uwe によれば、2ステージは 3ステージの約99.5%のデコード yield を得られる一方で、必要な計算能力は大幅に少なくて済む とのことです。このため、3ステージは最高性能を狙う高速PC向けのモードであり、実用上は 2ステージが多くのユーザーにとって非常に良い妥協点になります。

2-Stage とは何か

ライブ受信時における 2-Stage は、41シンボル時点での STD pre-pass と、49シンボル時点での final MTD decoding から成る2段構成です。

つまり、流れとしては次のようになります。

• STD pre-pass @ nzhsym=41（約11.8秒）
• final MTD @ nzhsym=49（約14.1秒）

ここで大事なのは、46シンボル時点での2回目の STD pre-pass は 2-Stage では行われない という点です。その追加 pre-pass は 3-Stage のみで行われます。

言い換えれば、2-Stage は「まず早い段階で一度軽く見ておき、そのあと49シンボル時点で本命の MTD decode を行う」という、非常にバランスの良いモードです。

CPU負荷との釣り合いが良く、実運用上も効率の高い選択肢です。Uwe Risse / DG2YCB によれば、2ステージは 3ステージの約99.5%のデコード yield を得られながら、必要な計算能力は大幅に少なくて済みます。その意味で、多くのユーザーにはまず 2-Stage を勧めやすい と考えています。

3ステージ とは何か

3ステージ は、2-Stage に対して 46シンボル時点の追加 STD pre-pass を加えた構成です。

ライブ受信時の流れは次の通りです。

• STD pre-pass @ nzhsym=41（約11.8秒）
• STD pre-pass @ nzhsym=46（約13.2秒）
• final MTD @ nzhsym=50（約14.4秒）

つまり 3ステージ は、41で一度軽く見て、46でもう一度追加の先行チェックを行い、最後に50シンボル時点で final MTD decoding を実行します。

このため 3ステージ は、WSJT-X 3.1 improved で得られる最高レベルの FT8 デコード性能を狙えるモードです。

ただし、ここには重要な注意点があります。3ステージによって得られる追加利得は、CPU負荷の増加に比例するわけではありません。Uwe Risse / DG2YCB によれば、2ステージでも 3ステージの約99.5%のデコード yield が得られるため、3ステージの追加分はかなり小さい一方で、要求される計算能力は大きく増えます。

さらに、非力なPCでは46シンボル時点の追加 STD pre-pass の処理が重くなりすぎて、50シンボル時点の最も重要な final MTD decoding に間に合わない、あるいは悪影響を与える可能性があります。そのため、3ステージは「最高性能を狙うための高級モード」と考えるのが自然です。高性能なCPUを持つ環境では非常に魅力的ですが、万人向けの標準推奨というよりは、余裕のある環境で真価を発揮する設定だと言えます。

STD と MTD はどのように組み合わされるのか

CHANGE LOG では、2-stage / 3-stage について「both decoders can be intelligently combined」と説明されています。この表現から、MTD が先に走り、後から STD が補完するような関係を想像する人もいるかもしれません。

しかし、ライブ受信時の実際の構造はその逆です。STD が早い時点で軽く先行チェックを行い、最後に MTD が本命のデコードを担当する、という関係です。

• 2-Stage：STD @41 → final MTD @49
• 3-Stage：STD @41 → STD @46 → final MTD @50

つまり、2-Stage と 3-Stage はどちらも STD と MTD を組み合わせた staged mode ですが、3-Stage だけが 46シンボル時点の追加 STD pre-pass を持つ という点が重要です。

この違いを理解すると、なぜ多くのユーザーに 2-Stage が推奨され、高性能PCでは 3-Stage が最高性能モードになるのかが分かりやすくなります。

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秒のために、どれだけ賢く準備して待てるか。そこまで含めて、デコーダ最適化なのだと思います。