WSJT-X Improved 260908版が英語で起動する理由 ― 日本語で使用するには --language=ja を指定2026年09月11日 10時18分27秒

WSJT-X Improved 3.2 の 260908版を日本語Windows環境で起動すると、 これまでと違ってデフォルトでは英語GUIで起動することが分かりました。

最初は日本語translationの問題も疑いましたが、調査した結果、 これは翻訳ファイルの不具合ではなく、260908版で意図的に導入された 起動言語の仕様変更であることが分かりました。

DG2YCB Uweにも確認し、変更の経緯について回答をいただきましたので、 これから260908版を使用する日本のユーザー向けにまとめておきます。

■ 実際の動作

同じ日本語Windows PCで260818版と260908版を比較したところ、 次のようになりました。

Version 起動オプション 起動言語
260818 指定なし 日本語
260908 指定なし 英語
260908 --language=ja 日本語

つまり、260818まではWindowsのシステムロケールに従って 日本語環境では自動的に日本語GUIが選択されていましたが、 260908では言語を明示しない場合に英語が選択されるようになっています。

■ ソースコードを比較すると原因は明確

260818と260908の完全なソースツリーを比較したところ、 原因は wsjtx/main.cpp の変更でした。

260818では次のようになっています。

L10nLoader l10n {&a, locale, parser.value (lang_option)};

この場合、--language が指定されていなければ、 通常のsystem localeを使った言語選択処理へ進みます。 そのため日本語Windowsでは日本語translationが自動的に読み込まれます。

一方、260908では次のコードに変更されています。

QString language_override = parser.value(lang_option);

// Default to English unless a language was explicitly requested.
if (language_override.isEmpty()) {
    language_override = "en";
}

L10nLoader l10n {&a, locale, language_override};

コメントにも、

Default to English unless a language was explicitly requested.

と明記されています。

つまり260908では、言語オプションが空の場合、 system localeを参照する前に明示的に "en" が設定されます。

その結果、動作は次のようになります。

260818
言語指定なし
  ↓
system locale
  ↓
Japanese Windows
  ↓
Japanese GUI


260908
言語指定なし
  ↓
"en" を明示的に指定
  ↓
English GUI


260908 --language=ja
  ↓
"ja" を明示的に指定
  ↓
Japanese GUI

■ なぜこの変更が入ったのか

この点についてUweに問い合わせたところ、変更の経緯も分かりました。

Uweによると、複数の言語環境をインストールしたmacOSを使用している あるOMからの提案を受けて、

English should be the default everywhere.

という考え方に基づき、 言語を明示指定しなかった場合は英語をデフォルトにする 変更を行ったとのことです。

したがって260908版が日本語Windows上でも英語で起動するのは、 偶発的なregressionではなく、現在のWSJT-X Improvedで意図された動作です。

■ 日本語で使用するには

260908版を日本語GUIで使用したい場合は、起動時に

--language=ja

を指定してください。

Windowsのショートカットから起動している場合は、 ショートカットのプロパティを開き、 「リンク先」の wsjtx.exe の後ろに半角スペースを入れて、 次のようにします。

"C:\...\wsjtx.exe" --language=ja

実際のパスはインストール先によって異なりますので、 現在ショートカットに設定されているパスは変更せず、 その末尾に

 --language=ja

を追加すればOKです。

例えば英語を明示的に使用する場合は、

--language=en

となります。

■ 日本語translationが削除されたわけではありません

ここは誤解しやすいところですが、 260908版から日本語translationが無くなったわけではありません。

実際に

--language=ja

を指定すれば、正常に日本語GUIで起動します。

つまり問題はtranslation resourceではなく、 起動時にどの言語を選択するかというselection logicです。

■ Best S&Pの言語依存問題修正とは別件

今回の件については、私が以前Uweへ送った Best S&Pのlanguage-dependent flaw修正との関係も念のため確認しました。

結論として、両者は無関係です。

Best S&Pの修正は、 翻訳された文字列そのものを比較してCQ priorityを判定していた部分を、 typed CQ priority valueによる比較へ変更したものです。

変更対象は主として displaytext.cppmainwindow.cpp であり、

  • QLocale
  • QTranslator
  • L10nLoader
  • language command-line option
  • translation loading

には触れていません。

Uweからも、

It was not due to your patch, Yoshi.

と明確に回答をいただいています。

■ 将来的にはGUIから言語切替も?

Uweはさらに、各言語のtranslation fileが継続的にきちんとメンテナンスされるのであれば、 将来的には「User Dark Style」のように、 メインプログラムのメニューから言語を切り替えられるようにしたい、 という考えも示しています。

これは実現すればかなり便利だと思います。

■ まとめ

WSJT-X Improved 260908版について、 日本語Windowsで英語GUIが表示されても異常ではありません。

260908版では仕様変更により、 起動時に言語を指定しなかった場合は英語がデフォルト になりました。

日本語で使用する場合は、

--language=ja

を起動オプションとして指定してください。

日本語translation自体は正常に収録されており、 このオプションを指定すれば従来通り日本語で使用できます。

WSJT-X Improved 3.2 / 260908で日本語メニューが英語で起動する場合の対処と原因2026年09月10日 07時48分31秒

WSJT-X Improved 3.2 / 260908で日本語メニューが英語で起動する場合の対処と原因

WSJT-X Improved 3.2.0 260908 AL PLUSを使用した日本人ユーザーから、 「これまで日本語だったメニューが英語表示になった」という問い合わせがありました。

同様の事象は別の日本人ユーザーでも確認されており、 日本語表示そのものが失われたわけではなく、起動時の言語選択の挙動が変わっていることが分かりました。

先に結論:日本語で起動する方法

260908で日本語GUIを使用したい場合は、起動時に次のオプションを付けます。

--language=ja

たとえばWindowsのショートカットを使用している場合は、「リンク先」の実行ファイル名の後ろに半角スペースを入れて、

"C:\WSJT\wsjtx\bin\wsjtx.exe" --language=ja

のようにします。 実際のインストール先は各自の環境に合わせてください。

この方法で260908でも正常に日本語表示になることを、複数の日本人ユーザーで確認しています。

260818と260908を同じPCで比較

原因を切り分けるため、私自身の日本語Windows環境で260818と260908を同じPC上でA/Bテストしました。

  • 260818:言語オプションなし → 日本語で起動
  • 260908:言語オプションなし → 英語で起動
  • 260908:--language=ja → 日本語で起動

少なくとも私の環境では、260818と260908の間で、 「言語を明示指定しなかった場合のデフォルト動作」 が変わっていることが確認できました。

ソースを比較すると原因が見つかりました

そこで260818と260908の完全ソースを比較しました。 直接の違いは wsjtx/main.cpp にありました。

260818では次のようになっています。

L10nLoader l10n {&a, locale, parser.value (lang_option)};

この場合、--language が指定されていなければ空の値がそのまま L10nLoader に渡されます。 そのため通常のsystem localeによる言語選択が働き、日本語Windowsでは日本語GUIが自動的に読み込まれます。

一方、260908では次の処理が追加されています。

QString language_override = parser.value(lang_option);
// Default to English unless a language was explicitly requested.
if (language_override.isEmpty()) {
  language_override = "en";
}
L10nLoader l10n {&a, locale, language_override};

つまり260908では、言語指定がない場合に "en" を明示的に設定するよう変更されています。

L10nLoader 側では "en" を明示的な英語指定として扱い、 system localeに基づくtranslationの読み込みをスキップします。 その結果、オプションなしでは英語GUIになります。

逆に --language=ja を付ければ "ja" が明示指定されるため、 日本語translationが正常に読み込まれます。

実際の挙動とソースの処理が一致

整理すると次の通りです。

  • 260818:言語指定なし → system localeを使用 → 日本語Windowsでは日本語
  • 260908:言語指定なし → "en" を設定 → 英語
  • 260908:--language=ja → 日本語

実機で確認した挙動と、ソース上の処理が完全に一致しました。

また、L10nLoader.cppL10nLoader.hpp 自体は260818と260908で変更されておらず、 言語・locale・translation周辺を確認した範囲では、今回のデフォルト動作を変える直接の差分はこの main.cpp の変更でした。

Best S&Pの日本語対応patchとは無関係です

260908には、私(JP1LRT)が提供したBest S&Pの言語依存修正patchも取り込まれています。 そのため当初、この変更との関係も念のため確認しました。

しかしこのpatchは、Best S&P内部で翻訳済み文字列を比較していた処理を、 言語に依存しない内部のtyped valueによる比較へ変更したものです。

QLocaleQTranslatorL10nLoader、 translation loading、--language の処理には触れていません。 ソースdiffでも今回の日本語GUI起動問題との直接的な関係がないことを確認しました。

これは「バグ」なのか?

260908のコードには、

// Default to English unless a language was explicitly requested.

というコメントがあるため、コード変更そのものは意図的に書かれたものと考えられます。

ただし、 「すべての非英語環境で、言語指定がなければ英語をデフォルトにする」 ことまで意図したユーザー向け仕様変更だったのか、 またその理由が何だったのかまでは、今回比較したソースだけからは判断できません。

したがって現時点では、これを「バグ」や「regression」と断定するのではなく、 260818と260908の間でデフォルトの言語選択処理が変更された という事実として整理しておくのが適切だと思います。

従来の自動言語選択へ戻す場合

もし260818までのように、言語指定がない場合はsystem localeに従う動作へ戻すのであれば、 main.cpp の処理を260818の形に戻すのが最小の修正です。

L10nLoader l10n {&a, locale, parser.value (lang_option)};

この形に戻しても、英語を明示したい場合の

--language=en

は従来通り機能します。

今回の解析結果についてはDG2YCB / Uweにも共有しています。

とりあえず困っている方へ

260908をインストールして「メニューが英語になってしまった」と困っている方は、 まずはショートカット等に

--language=ja

を追加して起動してみてください。 日本語translationそのものは正常に利用できます。

最初は単純な「日本語メニューが出ない」という問い合わせでしたが、 同一PCでのA/Bテスト、260818と260908のソース比較、 そしてtranslation loaderの処理を追うことで、今回の挙動の直接原因まで確認することができました。

73,
Yoshi / JP1LRT

WSJT-X Improved JP1LRT Edition ユーザーガイドを Edition 1.10 に更新しました2026年09月09日 14時29分12秒

WSJT-X Improved JP1LRT Edition ユーザーガイドを Edition 1.10 に更新しました

一昨日、「ユーザーガイドを Edition 1.9 に更新しました」と書いたばかりなのですが……早くも Edition 1.10 です(笑)。

ソフトウェア本体の最新版は引き続き 20260901A-REB522-P6 / P6-AL で、今回の更新は ユーザーガイドの内容をさらに整理・明確化したドキュメント更新 です。

実際の運用で迷いやすい部分や、これまで説明が十分ではなかった挙動について見直しを行い、英語版を基準として各言語版にも反映しました。

Edition 1.10 の主な更新内容

  • Band Activity の LoTW ユーザー表示を明確化
    LoTW ユーザーには「●」が表示されること、また設定画面から LoTW User Validation 情報を取得できることを説明しました。
  • 候補局の優先順位を整理
    Wanted callsign / prefix / grid、New DXCC、CQ Zone、ITU Zone、Grid、Continent、New Call、LoTW user、Worked Before など、実際に使用される優先カテゴリを整理しました。
  • 同順位時の選択ルールを追記
    同じ優先カテゴリでは LoTW ユーザーを優先し、その後は設定に応じて距離または SNR、さらに同条件なら先にデコードされた局を優先する流れを説明しています。
  • Auto Tx Off の意味を明確化
    「AutoSeq の種類を変更する」という意味ではなく、Enable Tx / Auto Tx を OFF にする、または Halt Tx を使用することを明記しました。
  • CQ AutoSeq 2 における手動ダブルクリックの安全動作を追記
    FT8 の Tx1 / Tx2 送信中、送信開始後およそ2秒以内なら相手局を即時切り替えできますが、それ以降は送信中の FT8 メッセージを書き換えず、次の安全な送信タイミングまで手動切り替えを保留します。
    これは、1つの FT8 フレームの途中で送信内容が別局向けに変わってしまうことを防ぐための安全処理です。
  • 診断ログ機能の説明を追加・整理
    不具合や「反応しなかった」場面の解析に使用する JP1LRT 診断メッセージを ALL.TXT に記録する設定について、実際の画面表記に合わせて説明しました。
  • Wanted / Hunting / Pounce 周辺の説明を改善
    応答が得られない場合の復帰動作や、Hunting 待機へ戻る際の挙動など、実運用で分かりにくかった部分をより具体的にしました。

16言語版を用意しています

Edition 1.10 は、以下の 16言語 で用意しています。

English / 日本語 / Français / Español / Deutsch / 简体中文 / 繁體中文 / 한국어 / Português / Italiano / Nederlands / Русский / Polski / Türkçe / Svenska / Bahasa Indonesia

英語版を内容上の基準(semantic master)として確認したうえで、各言語版へ反映しています。

「機能を増やす」だけでなく、「挙動を正しく伝える」ことも重要

JP1LRT Edition は CQ RUN、Wanted / Hunting、Pounce、安全な QSO 遷移など、オリジナルの WSJT-X / WSJT-X Improved とは異なる運用支援を多く追加しています。

そのため、機能そのものが正しく動くだけでなく、「なぜその動作をするのか」「どのタイミングで何が起きるのか」をユーザーに正確に伝えること も重要だと考えています。

今回の Edition 1.10 は、そうした「実際の運用で迷わないための説明」をかなり強化した版です。

ソフトウェア本体は P6 / P6-AL のままですが、ユーザーガイドを利用されている方は Edition 1.10 へ更新していただければと思います。

73,
Yoshi / JP1LRT

WSJT-X Improved JP1LRT Edition User GuideをEdition 1.9へ更新しました2026年09月07日 13時31分04秒

WSJT-X Improved JP1LRT Edition
User GuideをEdition 1.9へ更新しました

WSJT-X Improved JP1LRT Edition のUser Guideを、 Edition 1.9へアップデートしました。

今回、P6 / P6-ALのソフトウェア本体には変更ありません。
Edition 1.9はドキュメントのみのアップデートです。

現在公開中の 20260901A-REB522-P6 / P6-AL の動作ロジックやバイナリはそのままで、 「実際に使い始めるときに、どこをどう設定すればよいのか」を これまで以上に分かりやすくすることを目的にUser Guideを拡充しました。

Edition 1.9で追加・強化した主な内容

  • 推奨デコーダー初期設定を追加
  • Decode depth、AP、multithreaded FT8 decoder、Reduce False Decodesなどの実用的な設定例を掲載
  • Parameters → Decoder startは、まず3-Stageから試すことを推奨
  • 「CQ: AutoSeq 2」がどこにあるのかをスクリーンショット付きで明示
  • JP1LRT EditionのCQ RUNを最初に試す場合は、まずCQ: AutoSeq 2から始めることを推奨
  • LoTW / CTY.dat / US Callsign States / CALL3.TXTなどのデータ更新について説明を追加
  • 自分で育てたCALL3.TXTを上書きしないためのバックアップ・マージ時の注意を追加
  • wsjtx_log.adiのRescanALLCALL7.TXTについての説明を整理
  • 「インストールしたがJP1LRT Editionらしい動作に見えない」場合のクイックチェックリストを追加
  • P6のWanted-Pounce無応答処理に関する診断マーカーを付録Aへ追加
  • 不具合報告だけでなく、「普通に動いています」という正常動作レポートも歓迎する旨を追記

推奨する最初のデコーダー設定

項目 推奨開始値 補足
Decode depth Deep 感度優先の実用的な開始値。CPU負荷を抑えたい場合はNormal。
Use multithreaded FT8 decoder ON 通常は有効化を推奨。
Enable AP ON AP(a priori)decodeを使用。
Reduce False Decodes ON 通常運用では有効化を推奨。
Decoder start 3-Stage まずここから試し、CPU性能や運用条件に応じて調整。

なお、Hide AP informationは表示上の好みを決める項目であり、 AP decodingそのものを無効にする設定ではありません。

CQ RUNを試すなら、まず「CQ: AutoSeq 2」

「AutoSeq 2はどこで選ぶのか分からない」という声を想定し、 Edition 1.9では場所を明確にしました。

AutoSeq 2はSettingsの中ではありません。
メイン画面にあるCQ応答方式の選択欄、 つまり CQ: FirstCQ: Max Dist などを選ぶプルダウンの中に CQ: AutoSeq 2 があります。

JP1LRT EditionらしいCQ RUNを初めて試す場合は、 CQ: AutoSeq 2から始めることをおすすめします。 AutoSeq 3も利用できますが、まずAutoSeq 2で候補選択や終端処理の動きを理解してから試す方が分かりやすいと思います。

P6のWanted-Pounce無応答処理も診断しやすく

P6では、Wanted Pounce / Huntingから開始したQSOで相手から応答が続かず、 こちらがレポートを正確に3回送信した場合、 4回目のレポートを送らず、自動CQへ移行せず、Huntingへ安全に戻る ようになっています。

Edition 1.9では、ALL.TXTからこの動作を追いやすくするため、 付録Aの診断マーカー表に以下も追加しました。

WANTED_POUNCE_NO_REPLY_PRE_PTT_GATE
WANTED_POUNCE_RETURN_HUNTING reason=no_reply_abandon

16言語版を更新

User Guide Edition 1.9は、これまでと同じく16言語で用意しています。

日本語、英語、フランス語、スペイン語、ドイツ語、中国語(簡体字・繁体字)、 韓国語、ポルトガル語、イタリア語、オランダ語、ロシア語、ポーランド語、 トルコ語、スウェーデン語、インドネシア語です。

英語版を意味上のmasterとして作成し、そこから各言語版へ展開しています。

ダウンロード

日本語README
https://github.com/jp1lrt/wsjtx-avelag/blob/main/README_ja.md

P6 / P6-AL Release
https://github.com/jp1lrt/wsjtx-avelag/releases/tag/20260901A-REB522-P6

これからJP1LRT Editionを試す方は、 まずUser Guide Edition 1.9を一度ご覧いただければと思います。

不具合報告はもちろん歓迎ですが、 「しばらく使っているけれど普通に動いています」 というレポートも大変参考になります(笑)。

73,

WSJT-X Improved JP1LRT Edition P6 / P6-AL Public RC公開 — Wanted Pounce無応答時のHunting復帰を改善2026年09月01日 14時33分37秒

WSJT-X IMPROVED JP1LRT EDITION / PUBLIC RELEASE CANDIDATE

WSJT-X Improved JP1LRT Edition P6 / P6-AL Public RC公開

Wanted Pounceで相手から応答が続かなかったときの復帰処理を見直し、CQへ誤って移行せずHunting待機へ戻るよう改善しました。

20260901A-REB522-P6 / P6-AL

WSJT-X Improved JP1LRT Editionの新しいPublic Release Candidate、20260901A-REB522-P6 / P6-ALを公開しました。

今回のP6は、これまで公開していた20260824A-REB522-P5 / P5-ALの後継版です。ベースは引き続き2026年5月22日版 WSJT-X Improved 3.1.0で、WSJT-X Improved 3.2.0ベースへ移行した版ではありません。

今回のポイント
P6の中心は、Wanted Pounce / Huntingから開始したQSOで、相手局からその後の応答が得られなかった場合の処理改善です。

P5で起きていたこと

Hunting待機中にWanted局を受信すると、JP1LRT Editionはその局を取得し、QSOを開始してレポートを送信します。

P5では、その後相手から応答がないままレポートを3回送信すると、通常のCQ RUN用の無応答処理へ入り、場合によってはそのままCQ送信へ移行してしまうことがありました。

通常のCQ RUNとしては自然な動作ですが、Wanted Pounce / Huntingの思想から見ると、ここは少し違います。Huntingでは「Wanted局を待っている」のであって、相手が応答しなかったからといって勝手に通常CQへ移るべきではありません。

P6でどう変わったか

Wanted Pounce / Huntingから開始したQSOで、レポートを3回送信しても相手から続きの応答が得られなかった場合、P6では次のように動作します。

  • 4回目のレポートを送信しない
  • CQを自動送信しない
  • Auto Txを停止する
  • DX Callをクリアする
  • Tx6 / CALLING状態へ戻る
  • Wanted Pounceを有効なまま維持する
  • Hunting待機状態へ戻る
  • 蓄積済みのAutoSeq候補を保持する
  • 同じWanted局を再び受信した場合も、新しいQSOとして再取得できる
つまり、P6では「Wanted局を3回呼んで応答がなければ、CQへ流れず、元のHunting待機へ戻る」ようになりました。

3回目の直後にRR73が来たら?

ここは重要な境界条件です。

3回目のレポート送信直後に、相手からRR73などの有効な応答を受信した場合は、無応答とは判定しません。

その場合は従来どおり、QSO完了処理、最終73、Terminal Holdを経て、正常にHuntingへ復帰します。

つまり、単純に「3回送ったら即中断」ではありません。3回目送信後に届いた有効な終端応答は、きちんとQSO完了側が優先されます。

通常のCQ RUNには影響しません

今回の新しい復帰処理は、Wanted Pounce / Huntingから開始したQSOだけに適用されます。

通常のCQから開始したQSOの動作は従来どおりです。

  • CQ: Firstは、通常の無応答上限後にCQへ戻る
  • AutoSeq 2の通常CQ RUNは、既存のactive-QSO no-progress処理を使用する
  • 「Set Rx frequency to Tx frequency after QSO」が有効なら、CQ復帰時にRX DFをTX DFへ戻す
  • 通常CQではAuto Txを継続してCQを再開する

Hunting由来QSOと通常CQ由来QSOを、明確に別のライフサイクルとして扱うようになった、と考えると分かりやすいと思います。

P5までの機能もそのまま維持

P6はWanted Pounceの無応答時復帰を追加したもので、P5までに実装・検証してきた既存機能を削除したものではありません。

  • P5 Return to Hunting
  • Stop after 73の優先
  • Best S&Pの言語依存不具合修正
  • AutoSeq 2 / AutoSeq 3
  • Terminal Hold
  • CQ DX / 地域指定CQの自動取得安全制御
  • Manual takeover safety
  • LoTW userのtie-break
  • 進行中QSOの保護
  • Quick Call OFF時の正常動作
  • Orange WantedとBlue display-onlyの役割分離
Quick Call OFFについて
Best S&Pが対象局、DX Call、DX Grid、送信メッセージを準備しても、自動的には呼び始めません。これは異常ではなく、意図した正常動作です。

検証内容

Standard版

Standard版では、以下を実行確認しています。

  • HuntingからWanted局を取得
  • レポートを正確に3回送信
  • 4回目のレポートを送信しない
  • CQを誤送信しない
  • Hunting待機状態へ復帰
  • 同一局への再発火とカウンター初期化
  • 新しい受信レポート値による送信メッセージ再生成
  • 通常AutoSeq 2 CQとの非干渉
  • 通常CQ: Firstの無応答復帰
  • RX DFのTX DFへの実際の復帰
  • 3回目送信直後のRR73受信
  • 最終73、Terminal Hold、Hunting復帰

AL版

AL版では、P5-ALとP6-ALの完全source bundleを独立比較し、Standard版で承認された修正内容との一致、AL固有コードとの非競合、クリーンビルド、正式パッケージ検証、隔離起動および正常終了を確認しています。

独立レビュー最終判定
Standard P6: READY FOR PUBLIC RC PROMOTION
P6-AL: READY FOR PUBLIC RC PROMOTION
Blocking issues: none

ただし、これはすべてのモード、設定、境界条件を網羅したことを意味するものではありません。P6 / P6-ALはあくまでPublic Release Candidateです。

ダウンロード

GitHub Releaseを開く

Release: https://github.com/jp1lrt/wsjtx-avelag/releases/tag/20260901A-REB522-P6

成果物 ファイル名 SHA-256
Standard GUI WSJT-X_20260901A-REB522-P6_win64.zip d69ef54fb7d10feb3a7bc9620497eda8ec40c700f08f4d5302e8e016a02e992b
AL GUI WSJT-X_20260901A-REB522-P6-AL_win64.zip 658db59666b89ae4884365e5ba55087b234b29aaa0cf7950fee80fcb2ab800e7
Standard source WSJT-X_20260901A-REB522-P6_source_bundle.zip 86e53df77bacaa93fc16bed15aec8e8ae1529231df16873486dacdb619803e2c
AL source WSJT-X_20260901A-REB522-P6-AL_source_bundle.zip 8ecb9f4d6ec4763a2eb03f7d33a1971466263b7435a7efc491e56b8365a1c1f4

各ZIPには対応する.sha256 sidecarも用意しています。

ユーザーガイドもEdition 1.8へ更新

P6 / P6-ALに合わせて、ユーザーガイドもEdition 1.8へ更新しました。

英語、日本語、ドイツ語、スペイン語の4言語版で、P6のWanted-Pounce無応答時復帰、最新のファイル名とSHA-256、Public RCとしての注意事項、既知の制限を反映しています。

現在も残っている既知の制限

P6で以下を修正したわけではありません。引き続き検討・調査中です。

  • F/DB6LLのようなプレフィックス形式を含むスラッシュ付きコールサインのRR73処理
  • jt9.exeの間欠的SIGSEGV
  • 「Highlight also messages with 73 or RR73」設定に関する報告
  • --language=es使用時、一部の新しい未翻訳UI文字列が英語ではなく日本語で表示される場合がある問題

最後の項目は表示上の問題で、QSOロジックや送信メッセージには影響しません。

Public RCとしてのお願い

  • 新しい別フォルダへ展開してください
  • 現在正常に動いている版を上書きしないでください
  • Standard版とAL版を同じフォルダへ展開しないでください
  • 別の--rig-nameプロファイルを使用してください
  • 設定とログをバックアップしてください
  • コールサイン、グリッド、無線機、PTT、オーディオ、レポート、ログ設定を確認してください
  • 生成された送信メッセージ、DX Call、Auto Tx状態を監視してください
  • 無人・無監視運用は行わないでください
  • 異常を感じた場合は直ちに送信を停止してください

最後に

JP1LRT Editionは、単に機能を増やすことではなく、実際のFT8/FT4運用で「次に何が起きるか」をできるだけ予測しやすくし、進行中QSOや終端メッセージを壊さず、運用者の意図を尊重することを重視して作っています。

今回のP6も小さな修正に見えるかもしれませんが、Wanted Pounce / Huntingという運用思想を崩さないためには重要な変更でした。

実運用で何か不自然な点や再現可能な挙動を見つけた場合は、Standard / AL、完全なタイトルバー識別子、UTC時刻、Wanted-Pounce / Hunting状態、Quick Call ON/OFF、ALL.TXT該当部分、期待した動作と実際の動作を添えてご連絡いただけると助かります。

73, Yoshi / JP1LRT

ハムフェア2026、今年も2日間楽しんできました!2026年08月31日 09時22分49秒

HAM FAIR 2026 / JP1LRT
ハムフェア2026、今年も2日間楽しんできました!

財布を忘れて《詰んだ》ところから始まり、0次会、6m DXer懇親会、ARDC講演、関東UHFコンテスト表彰式まで。たくさんの皆さんにお会いできた、楽しい2日間でした 📡

初日――国際展示場駅でいきなり《詰んだ》🤣

昨日・一昨日は ハムフェア2026 に参加してきました。

今年も出展者証を持っていなかったので、10時の開場を待つ一般入場組。とはいえ、朝から長蛇の列に並ぶのは苦痛なので(笑)、初日は 10時30分ごろ到着 をターゲットに自宅を出発しました。

会場までいろいろな行き方がありますが、この日は外も比較的涼しかったので、りんかい線の国際展示場駅から歩いて向かうことにしました。

ところが――
国際展示場駅に着いたところで《詰んだ》🤣

なんと……
財布を家に忘れてきました。

普段からあまり現金を持ち歩かない私ですが、さすがにハムフェアでは多少必要だろうと思っていたのに、その財布そのものがない(笑)

スマホケースの中には、非常用に入れてある エマージェンシー・キャッシュ5,000円

そして夜には6m DXerの皆さんとの懇親会。その予算もだいたい5,000円。

……はい、使えません🤣

そんなことを考えているうちに、11時に予定されていた仲間との記念撮影の時間が迫ってきます。

もう歩いている場合ではないのでタクシーへ。運転手さんに「Suica使えますか?」と確認するとOK。普段から モバイルSuica を使っているので、ここは無事突破(笑)

なんとか記念撮影にも間に合いました 📸

そのまま有明ガーデンで“0次会” 🍺

記念撮影のあとは、そのままの流れで有明ガーデンへ。

ハムフェア2026 懇親会 “0次会” スタート 🍺🤣

しゃぶしゃぶの飲み食べ放題で、ビールをジョッキ 7杯 流し込み、牛肉と野菜もしっかりいただいて満腹。

さて問題の支払いですが……仲間に PayPayで送金

財布がなくても、意外とどうにかなるものです(笑)

その後はハムフェア会場内をゆっくり散策。

普段SNSや無線でつながっている方、久しぶりにお会いする方、初めて直接ご挨拶できた方など、本当にたくさんの皆さんとお会いすることができました。

無線で声やコールサインを知っていても、実際に顔を合わせて話せるのは、やっぱりハムフェアならではですね 😊📡

秋葉原で6m DXer懇親会――PY2XB Fredさんも参加 🇧🇷

18時からは秋葉原へ移動し、6m DXerの皆さんとの懇親会

今年はブラジルから PY2XB Fredさん も参加されました 🇧🇷📡

宴会開始前にはFredさんとヨドバシカメラへ行き、Fredさんのスマートフォンケースと、奥様用のモバイルバッテリー選びにもお付き合い。

その後の懇親会では、6m DXの話はもちろん、いろいろと興味深い話を伺うことができ、とても有意義な時間になりました。

もちろん二次会にも参加 🍺🤣

2日目――ARDCの講演と関東UHFコンテスト表彰式

そしてハムフェア2日目。

この日は昼ごろから会場入りしました。

メインステージで行われた

「アマチュア無線で拓く次世代への架け橋
― イノベーション等を支える ARDC のビジョン ―」

のお話は、とても興味深く聞かせていただきました。

アマチュア無線を単に「今ある趣味」として見るのではなく、次の世代や技術、教育、イノベーションへどうつなげていくのか。

こういう話をハムフェアの場で聞けるのは、とても良いですね。

そして14時からは、第43回関東UHFコンテスト表彰式 を《見学》😅

なぜ《見学》かというと……

コンテスト当日の休みを申請するのを忘れてしまい、今年は参加できなかったから🤣

表彰される側には回れませんでしたが(笑)、多くのお知り合いの皆さんが表彰される姿を、拍手でお祝いしてきました 👏

2日目はそのまま帰宅。17時にはもう自宅でのんびりしていました。

やっぱりハムフェアは「人に会える」のが一番楽しい

今年のハムフェアも、2日間を通して、日頃から無線やSNSでつながっている本当に多くの皆さんとお会いすることができました。

直接お話しできた皆さん、ありがとうございました 😊

一方で、

「会場にはいたはずなのに、結局すれ違いで会えなかった!」

という方も本当にたくさんいらっしゃいました。

あれだけ多くの人が集まるイベントなので、こればかりは仕方ありませんね。

今回お会いできなかった皆さんとは、ぜひ来年こそ!

やっぱりハムフェアは、機器を見るだけのイベントではなく、
人と人が直接会えることこそが一番の楽しみなのかもしれません。

今年も楽しい2日間でした。
皆さん、ありがとうございました! 😊📡🍺

FT8の「最後の1 decode」を拾うために――Wide GraphとJTDX Filterを理解して使う2026年08月30日 10時09分56秒

ハムフェア2026のあと、6m DXer仲間で飲んでいた時のことです。話題がFT8の極弱信号のデコードになりました。 そこで僕が話したのが、「目的の局だけを何とかデコードしたい時は、リグのフィルターだけでなく、 WSJT-X / JTDXのWide Graphの表示範囲も狭めてみる」という方法です。

面白かったのは、そこにいた皆さんが「リグの受信フィルターを狭める」という方法は当然のように知っていたのに、 「Wide Graphを狭める」という発想はほとんどなかったことでした。

これは魔法ではありません。しかし、6mのマルチホップEsなどで、見えたり消えたり、-20数dB付近を行き来しながら、 「あと1回だけデコードできればQSOが進む」という場面では、覚えておいて損のないテクニックだと思っています。

Wide Graphは、単なる「表示窓」ではない

まず大前提です。WSJT-XのWide Graphは単なるウォーターフォール表示ではありません。 公式User Guideには、次のように明記されています。

“Decoding occurs only in the displayed frequency range.”

つまり、デコードはWide Graphに表示されている周波数範囲内でのみ行われます。 たとえばWide Graphを100~3300Hzまで表示していれば、その範囲がデコーダの探索対象になります。

JTDX 2.2.159のソースでも、この関係はかなり直接的に確認できます。 デコード時のパラメータ nfa にはWide Graphの開始周波数、 nfb にはWide Graphの上限周波数が設定され、デコーダ側へ渡されています。

ここがポイント Wide Graphの幅を変えることは、見た目を拡大・縮小しているだけではありません。 デコーダが探索する周波数範囲そのものを変えている、ということです。

「CPUを目的局に集中させる」は、感覚的には正しい

たとえば普段100~3300Hz、約3200Hz幅を探索しているところで、 目的局が1500Hz付近にいることが分かっているなら、 その周辺700~1000Hz程度までWide Graphを狭め、不要な範囲を探索対象から外すことができます。

これを「CPUパワーを目的局に集中させる」と表現すると、とても分かりやすいと思います。 ただし技術的により正確に言えば、 「不要な周波数範囲を探索対象から外し、デコーダの探索空間を限定する」ということになります。

もちろん、3200Hzから1000Hzへ狭めたからCPU負荷が単純に約1/3になる、という話ではありません。 FFTや音声前処理など、探索幅とは独立して必要な処理もあります。 それでも、デコーダが調べる候補の存在する範囲を限定できること自体には意味があります。

ただし、S/Nそのものが良くなるわけではない

ここは誤解してはいけません。Wide Graphを狭めても、受信した信号の物理的なS/Nが改善するわけではありません。 -23dBの信号が、それだけで-20dBになるわけではないのです。

FT8の限界領域のデコードでは、候補検出、同期探索、LDPC Decode、AP Decode、複数回のPass、 さらにデコード済み信号をSubtractして残った信号を再探索する処理など、いくつもの段階があります。

したがって、「探索範囲を狭めれば必ず感度が上がる」とは言えません。 一方で、限界付近の信号に対して不要な範囲を探索対象から外した結果、 広い範囲ではデコードしなかった信号が、狭めた時にはデコードするということは実戦上あり得ます。

重要 これは「デコード感度を何dB改善する」という種類のテクニックではありません。 デコーダに与える探索条件を変えることで、限界信号のデコード成功条件が変わることがある、 という理解が適切です。

リグのフィルターを狭めることとは、作用点が違う

「弱い信号ならリグのフィルターを狭める」という方法は、多くの方が使っていると思います。 しかし、リグのフィルターとWide Graphは同じ「帯域を狭める」操作でも、働く場所が違います。

📡 RF / IF / DSPリグの受信フィルター
不要な信号を前段で抑える
🔊 Audio受信音声をPCへ
ソフトへの入力
💻 DecoderWide Graphの範囲
探索する周波数範囲を限定

リグ側の帯域を狭めることで、強い近接信号によるAGC動作や受信系への影響を抑えられる場合があります。 一方、Wide Graphを狭めるのは、ソフトウェア側で「どこを探すか」を限定する操作です。

つまり、極弱局に集中したい時は、次の二段構えになります。

  1. リグ側で不要な受信帯域をできるだけ減らす。
  2. ソフト側でもWide Graphを目的局周辺へ絞り、デコーダの探索範囲を限定する。

実際には、Wide Graphをどこまで狭められるのか

ここで、実際の画面上ではどこまでWide Graphを狭められるのかも確認してみました。 Bins/Pixelを1にした状態で、私が現在使用しているWindows環境では、 WSJT-Xは約682Hz、JTDXは約572Hzまで狭めることができました。

これは固定された「最小デコード帯域」ではありません 682Hz / 572Hzという数字がデコーダの仕様として固定されているわけではありません。 Bins/Pixel=1のときの周波数スケールと、Wide Graphウィンドウを実際にどこまで細くできるかによって決まる表示幅です。 Windowsの表示スケーリング、フォント、使用言語、UIレイアウトなどによって多少変わる可能性があります。

つまり、「目的局の50Hzだけを残す」といった極端な狭帯域化は、 少なくとも通常のWide GraphのUI操作ではできません。 一方で、通常の数kHz幅から700~1000Hz前後へ狭めるだけでも、 探索対象をかなり限定することはできます。

狭ければ狭いほど良い、ではない

では、目的局が1500Hzにいるなら、可能な限りギリギリまでWide Graphを狭めれば最高なのか。 僕はそうは考えません。

FT8デコーダは、強い信号を先にデコードしてSubtractし、その後に近接した弱い信号を拾えることがあります。 目的局のすぐ近くに強い信号があるのに、それを探索範囲外へ追い出してしまうと、 状況によってはその恩恵を失う可能性があります。

そのため僕なら、目的局だけを極端に囲うのではなく、 まずは目的局を中心に±500Hz程度、つまり合計1000Hzくらいを目安に残して試します。

※ ±500Hz(合計約1000Hz)はWSJT-X/JTDX公式の推奨値ではなく、 極弱局へ集中する際の実戦上の目安として僕が考えている値です。 上記の最小幅まで最初から絞り切るのではなく、まずは1000Hz程度を残し、状況を見ながら調整します。

僕ならこう試す

  1. 通常運用では、例えば100~3300Hz程度を表示。
  2. どうしてもデコードしたい極弱DXが現れたら、まずリグの受信フィルターを狭める。
  3. Wide Graphも目的局周辺1000Hz程度へ縮める。
  4. 状況を見ながら、必要ならもう少し狭める。
  5. 近接強信号や呼んでくる他局も考慮し、「狭めすぎ」になっていないか確認する。

では、JTDXの「Filter」ボタンとは何が違うのか

ここまで読んだJTDXユーザーなら、 「それならJTDXのFilter機能と同じでは?」と思うかもしれません。 発想には共通する部分がありますが、完全に同じものではありません。

操作何を狭めるか考え方
リグの受信フィルター 無線機側の受信帯域 ソフトへ入る前の不要信号を減らす
Wide Graph wideband decoderの探索範囲 広帯域探索の「窓」そのものを狭くする
JTDX Filter 現在のRx周波数付近 選択したRx信号周辺だけを狙うnarrow decoding

現在のJTDX 2.2.159のFilterボタンのツールチップでは、帯域幅は次のように説明されています。

  • FT8:170Hz
  • FT8 Hound:580Hz
  • FT4:274Hz
  • JT9:115Hz
  • T10:225Hz

FilterはRx信号のスペクトラムを中心に置かれます。つまりFT8なら、 現在選択しているRx周波数周辺の170Hzという非常に狭い範囲へ対象を限定する機能です。

JTDX Filterの「昔の説明」と「現在の説明」が面白い

ここからが少し興味深いところです。

2018年版のJTDX User ManualではFilterについて、 デコード候補数を減らすことでdecoding attemptsがより少ない候補へ再配分され、 信号をデコードできる確率がわずかに上がるという趣旨の説明がありました。

ところが現在のJTDX 2.2.159のFilterツールチップには、はっきりこう書かれています。

“Filter functionality can not improve signal decoding”

つまり現在の説明では、Filter機能そのものはsignal decodingを改善するものではないとされています。 主目的は、遅いCPUでも送信開始までにデコード処理を終えられるようにし、 送信直前まで処理が続いてメッセージが変わることを避けることです。

さらに現在のツールチップには、Filter帯域外から自分を呼んでいる局は失われるため、 CPU上本当に必要な場合だけ使うようにという注意もあります。

ここは「矛盾」ではなく、世代差として読むのが良さそう JTDXのデコーダは長年にわたり改良されています。古いマニュアルの説明を、現在の2.2.159へそのまま当てはめるべきではないでしょう。 なお現在のAdvanced設定にも、decoding attemptsはlow-SNR信号のdecoding efficiencyに影響し、 wideband側とRx-frequency側の双方に関係する、という説明は残っています。 つまり「decoding attemptsが重要」であることと、 「Filterボタン自体を感度改善機能と説明しない」ことは両立します。

JTDXのAuto RX frequency Filterにも注意

JTDXには AutoSeq → Auto RX frequency Filter があり、 QSO進行中にRx-frequency Filterを自動で使うこともできます。

これは便利な機能ですが、Filterが有効な間は帯域外からの呼び出しを拾えなくなることがあります。 特にCQを出して複数の周波数から呼ばれるRUN運用では、 「今FilterがONなのか」を意識しておく必要があります。

結局、何を覚えておけばいいのか

今回の話を一言でまとめるなら、

欲しい信号がどこにいるか分かっているなら、不要な範囲まで常に全部探させる必要があるとは限らない。

ただし、「狭くすれば必ずデコード感度が上がる」と単純化してはいけません。 リグの受信フィルター、Wide Graph、JTDX Filterは、それぞれ違う場所に作用する別の道具です。

どの道具も、伝搬がなければ信号を作り出すことはできません。 十分強い信号なら、こんな工夫をする必要もありません。

でも6m DXで、目的局がウォーターフォールには確かにいる。 ときどき一度だけデコードする。 あと一つReportが欲しい。あと一つRR73を拾いたい。

そんな「あとほんの少し」の場面なら、 リグのフィルターだけでなく、Wide Graphの幅も思い出してみてください。

最後の1dBならぬ、最後の「1 decode」を拾えるかもしれません。📡

情報は共有した方が、この趣味は面白い

飲み会でこの話をした時、何人かから「それは知らなかった」という反応がありました。

DXの世界では、もしかすると「そんなことを皆に教えなくてもいいのに」と思う方もいるかもしれません。 でも僕は逆です。

アマチュア無線は、誰かが見つけた知識や工夫を共有し、他の人が試し、 そこからまた新しい発見へつながっていく趣味だと思っています。

アンテナも、伝搬も、受信技術も、ソフトウェアも同じです。 自分だけの「秘密の技」にするより、 「こうすると少し良くなるかもしれない。みんなも試してみて」と共有する。

そして誰かが実験して、「こういう条件では効いた」「ここでは逆効果だった」とさらに情報を積み重ねる。 そうやって知識が育っていくことこそ、アマチュア無線らしさの一つではないでしょうか。

参考資料

  1. WSJT-X User Guide, “Wide Graph” — “Decoding occurs only in the displayed frequency range.”
    https://wsjt.sourceforge.io/wsjtx-main_en.html
  2. JTDX 2.2.159 source, mainwindow.cpp — Wide Graphの開始周波数・上限周波数を decoder parameters nfa/nfbへ設定。
    Debian Sources: JTDX mainwindow.cpp
  3. JTDX 2.2.159 source, mainwindow.ui — Filter帯域幅および現在のFilter機能説明。
    Debian Sources: JTDX mainwindow.ui
  4. JTDX 2.2.159 source, Configuration.ui — decoding passes / attemptsとlow-SNR decoding efficiencyの説明。
    Debian Sources: JTDX Configuration.ui
  5. JTDX User Guide, Version 2018-01-08 — 旧Filter説明。
    JTDX User Manual 2018 PDF

※ 本文中の実戦的な運用目安は筆者の考えを含みます。ソフトウェアの動作・仕様については、 上記公式文書またはソースコードの記述と区別して記載しています。

【公開RC】WSJT-X Improved JP1LRT Edition P5を公開しました📡2026年08月28日 23時51分54秒

PUBLIC RELEASE CANDIDATE

【公開RC】WSJT-X Improved JP1LRT Edition P5を公開しました 📡

新しい番号を追うだけではなく、実際のFT8/FT4運用で「こう動いてほしい」を積み上げたJP1LRT Editionの一般公開RCです。

20260824A-REB522-P5 P5-AL Release Candidate
WSJT-X Improvedはすでに3.2.0が公開されています。
では、なぜ今になって3.1.0ベースのJP1LRT Editionを公開するのか?
答えは単純です。
3.2.0にはない、JP1LRT Edition独自の運用支援機能が数多く入っているからです。

新しいバージョン番号だけを追うのではなく、実際のFT8/FT4運用、とりわけCQ RUN、DXハンティング、短時間の6mオープンなどで「こう動いてほしい」と感じてきた機能を積み上げてきました。

今回公開したのは、WSJT-X Improved JP1LRT Edition 20260824A-REB522-P5 / P5-ALです。

主な特徴

🎯AutoSeq 2/AutoSeq 3

複数局から同時に呼ばれたとき、単純なデコード順や距離だけではなく、ユーザーが設定した優先順位で相手局を選びます。

New DXCC、バンドニュー、Wanted局、LoTWユーザーなどを考慮する、JTDX由来の考え方をWSJT-X側へ持ち込んだCQ RUN機能です。

🟧Hunting/Wanted Pounce

Wantedに登録したコールサイン、プリフィックス、グリッドの局を待ち受け、条件が成立すると自動的に対象局を選択します。

P5では、Huntingから開始したQSOが正常に完了すると、CQを自動送信せず、オレンジ色のHunting待機状態へ戻るReturn to Huntingを再検証しました。

「73送信後に停止」がONなら、最終送信を安全に完了してAuto Txを停止し、Huntingにも戻りません。

🛡️Terminal Hold

RR73/73付近で、QSO相手や送信状態が早く解除されすぎることを防ぎます。

最終送信、PTT終了、相手局からのRR73/73、手動で選んだ次の局などを整理し、安全なタイミングで次の動作へ引き継ぎます。

🔄安全な手動引継ぎ

送信中に別の局を選んでも、現在の送信や交信相手を不用意に壊さないよう、即時切替と予約切替を使い分けます。

現在進行中のQSO、最終73、手動で選択した相手局は、自動選局より優先して保護されます。

Best S&Pの言語依存不具合を修正

従来は、翻訳されたハイライトカテゴリ名を内部へ保存し、固定された英語文字列と比較していたため、日本語など英語以外のUIでは「バンドの新コールサイン」や「新DXCC」が正しく判定されない場合がありました。

現在は翻訳表示ではなく、内部の型付きカテゴリ値で判定します。

上流側へもフィードバック済み

この修正は上流側にも報告し、独立した差分として提供しています。表示言語に依存せず、同じ意味のカテゴリを同じ内部値として扱う方向へ改めました。

Standard版とAL版

特徴 QSOロジック
Standard 従来のWSJT-X Improved PLUS系レイアウト 主要なQSOロジック・安全機能はAL版と同等
AL JTDXに近い操作感を持つレイアウト 主要なQSOロジック・安全機能はStandard版と同等

表示・診断機能も充実

  • LoTWユーザー表示
  • Worked/B4情報
  • Wanted表示
  • 拡張されたActivity Window
  • ウォーターフォール表示改善
  • Avg/Lag/Sync
  • 詳細なALL.TXT診断マーカー
  • 8桁/10桁グリッドロケーター入力
  • PSK Reporterへの高精度位置情報送信

なお、8桁/10桁のグリッドロケーターを設定しても、通常のFT8/FT4でオンエア送信されるロケーターは従来どおり4桁に制限されます。

3.2.0が出たのに、なぜ3.1.0ベースなのか

今回のP5は、WSJT-X Improved 3.1.0の2026年5月22日版をベースにしています。3.2.0ベースではありません。

WSJT-X Improved 3.2.0 JP1LRT Edition P5
3.2.0で追加された新機能・改善 CQ RUN、Hunting、相手局管理、安全な終端処理、独自の表示・診断機能

つまり、「3.2.0が出たから、この3.1.0ベース版には意味がない」という関係ではありません。

むしろFT8/FT4の実運用では、3.2.0とは違う方向の機能を楽しんでいただけると思います。

今回はGAではなく、一般公開RCです

⚠️ 最初は既存の正常動作版を残したままお試しください。
  • 別フォルダへ展開
  • 別の --rig-name プロファイルを使用
  • 自動選局を使う場合も、生成される送信メッセージとDX Callを必ず監視
  • 無人・無監視運用は想定していません

公開内容

  • Standard版
  • AL版
  • 各SHA-256確認ファイル
  • Standard/ALの対応ソースバンドル
  • 英語/日本語/ドイツ語/スペイン語のUser Guide 1.7
  • 統合SHA256SUMS
📥 Download — Public Release Candidate

興味のある方は、まずUser Guideを読んだうえでお試しください。

GitHub Release Page を開く

https://github.com/jp1lrt/wsjtx-avelag/releases/tag/20260824A-REB522-P5

不具合報告をいただける場合

次の情報を添えていただけると、原因を追いやすくなります。

  • 使用したバージョン
  • UTC時刻
  • モード
  • 関連する設定
  • 行った操作
  • 期待していた動作
  • 実際に起きた動作
  • 可能であればALL.TXTの該当部分
限定テストに協力してくださった皆さん、ソースレビューと実運用確認に協力してくださった皆さんに、改めて感謝いたします。📡

WSJT-X Improved 3.2リリース、そして「JP1LRT Edition」が目指すもの2026年08月18日 16時35分52秒

📡 WSJT-X Improved 3.2リリースと、開発中のJP1LRT Editionについて

本日、WSJT-X Improved 3.2がリリースされました。

今回の3.2シリーズでは、EME関連の大幅な機能強化をはじめ、さまざまな改善や修正が盛り込まれています。

WSJT-X Improved 3.2 ダウンロードページ
https://sourceforge.net/projects/wsjt-x-improved/files/WSJT-X_v3.2.0/

開発中の「JP1LRT Edition」

一方、私が開発を進めている非公式の独立改造版「WSJT-X Improved JP1LRT Edition」は、現時点では3.1.0(260522版)を土台にしています。

まだ3.2をベースにした版ではありませんが、Improved 3.1/3.2にはない独自機能を多数追加しています。

「JTDXのような実戦的な運用感覚を、WSJT-Xでも楽しめること」

これがJP1LRT Editionの目指している方向です。単に機能を追加するだけでなく、実際のFT8/FT4運用でバンドの状況を把握しやすくし、CQ RUNを安全かつ効率的に継続できることを重視しています。

JTDXスタイルのBand Activity表示

Band Activityの情報量を大幅に増やしました。

CQを出している局や73を送ってきた局だけでなく、他局同士がQSOしている途中のデコードからも、次の情報を一目で確認できます。

  • 交信済み(B4)かNewか
  • LoTWユーザーか
  • 国・DXCCエンティティ情報
  • Wanted局などの局属性

JTDXを使い慣れた方なら、現在のバンド状況や呼ぶべき局を格段に把握しやすくなったと感じてもらえると思います。

JTDX由来のWide Graph描写

Wide GraphにはJTDX由来の中央値ノイズ正規化を取り入れ、コントラストの効いた見やすいウォーターフォールへ変更しています。信号とノイズの差が見やすく、混雑したバンドでも状況を直感的に把握できます。🌈

GainとZeroには現在値を示す数値ツールチップも追加しました。スライダーを動かした際の値が分かるため、好みの設定を正確に再現できます。

AutoSeq 2/3による継続CQ RUN

JP1LRT Edition最大の特徴が、AutoSeq 2/AutoSeq 3によるJTDXライクなCQ RUNです。

通常のWSJT-X/Improvedでは、QSOが終わるたびに送信許可を出し直す必要があります。JP1LRT Editionでは、一度CQ RUNを開始すれば、そのまま次のQSOへ継続できます。

複数局から同時に呼ばれた場合も、単に最初にデコードした局や最も遠い局を選ぶだけではありません。例えば次のような運用上の価値を考慮し、優先順位に基づいて応答相手を選択します。🎯

  • Wanted局
  • 新DXCC
  • 新グリッド
  • 新局・バンド/モードでの新局
  • LoTW利用状況
  • 交信済みかどうか

Wanted/Hunting機能

呼びたいコールサイン、プリフィックス、グリッドをWantedとして登録し、CQ RUNで優先させることができます。

さらに、Wanted局がバンドに現れるまで待機し、その局自身が送信したときに自動的に呼びに行くHunting機能も搭載しています。

通常の優先選局と、特定局を待ち受けて呼びに行く動作を使い分けられるようにしています。

自動化だけでなく、安全性も重視

自動選局を増やすだけでは、実運用で安心して使用できません。そこでJP1LRT Editionでは、運用者の意思や進行中のQSOを守るための安全制御も作り込んでいます。🛡️

  • 手動で選んだ相手を自動選局が奪わない所有権保護
  • QSO中に別局を選んだ場合の安全な保留と引き継ぎ
  • 自動選局したQSOが進まない場合の安全な打ち切りとCQ復帰
  • CQ DXや地域指定CQで、条件に合わない局を誤って自動選局しない保護
  • 第三者のRR73/RRR/73を新しいQSOの状態へ誤流用しない保護

QSO終端を守るTerminal Hold

最初のRR73が相手に届かなかった可能性がある場合、相手はRレポートを再送してくることがあります。

Terminal Holdは、最初のRR73を送った後も現在の相手局と終端状態を保持し、同じ相手からRレポートが再送された場合には再びRR73で応答します。

RR73、RRR、73の処理中は、別の局や自動選局にQSOを横取りさせません。交信の終端を安全に処理してから、CQ、次の候補局、またはHunting待機へ復帰します。

そのほかの主な追加機能

  • Avg/Lagによる受信タイミング情報の表示
  • 対象局へのRx DF追従とCQ復帰時の同期
  • Max Dist/Max dB/Min dB選局と進行中QSO保護の統合
  • CQ DXおよび大陸指定CQの自動選局安全ゲート
  • 8桁・10桁を含む拡張Maidenheadグリッドロケーター入力
  • 約25万件規模のALLCALL7データ対応
  • ADIFログのQSO取り違えや古いDX Call/Grid残留を防ぐ保護
  • 必要なときだけ有効にできる詳細診断ログ
  • 日本語UIとツールチップの説明改善

現在は限定テストの最終段階

Standard版とAL版は、現在、一般公開の一歩手前まで進んでいます。まずは限定テスターの皆さんに実際の無線環境で運用していただき、これまでの管理された試験だけでは確認できない多様な環境での状況を確認します。

公開日はまだ確定していませんが、フィールドでの確認を重ねたうえで、近日中のリリースを目指しています。

「JTDXのような情報量とCQ RUNを、WSJT-Xでも使いたい」📻✨

そんな方には、きっと楽しんでいただけると思います。

ご注意
JP1LRT Editionは、WSJT-XおよびWSJT-X Improvedを基礎にした非公式の独立改造版です。現在の候補版はWSJT-X Improved 3.1.0(260522版)をベースとしており、今回リリースされた3.2.0をベースにしたものではありません。

【WSJT-X Improved 3.2.0 / 260818版 ― 何が変わった?】2026年08月18日 16時20分43秒

先ほどWSJT-X Improved 3.2.0がリリースされたことをお伝えしましたが、今回は3.1.0 260522版から何が変わったのかを、リリースノートをもとに日本語で簡単に解説してみます。

今回の3.2は、一言でいえば、

「6mを含むEME/Q65運用の大幅強化」+「普段FT8/FT4を使っている人にも役立つ細かな改善と修正」

というアップデートです。

EMEをやっていない方には馴染みのない機能も多いと思いますので、そのあたりも含めて少し噛み砕いて紹介します。

なお、これはJoe Taylor K1JTらによるWSJT-X本家そのものではなく、DG2YCB Uwe氏が開発している WSJT-X Improved の新バージョンです。


■ ウォーターフォール上のコールサイン表示がさらに実用的に

3.1で追加された「ウォーターフォール上へのコールサイン表示」が改良されています。

CQを出している局は緑背景で表示。

「73/RR73も表示」のオプションを有効にしている場合は、それらも同様に扱われます。

現在DX Call欄に入っている局、つまり自分が狙っている相手は、Band Activityと同じように赤背景+白文字で表示されます。

さらに大きな変更として、ウォーターフォール上に表示されているコールサインを直接クリックできるようになりました。

ダブルクリックすれば、その局とのQSOを開始できます。

WSJT-Xでは、この機能を使う場合「Hold Tx Freq」がONである必要があります。

つまりウォーターフォール上のコールサイン表示が、単なる「見える表示」から、実際のQSO操作にも使えるインターフェースへ進化しています。

この機能はWSJT-Xだけでなく、QMAP、MAP65にも展開されています。


■ 6m EME向け「liveCQ」プロトコルを拡張

今回の3.2で特に大きなテーマの一つです。

W7GJ Lance氏による6m EME DXpedition H44GJ を念頭に開発された機能で、主にQ65 Pileup運用を強力に支援します。

普通のスポットというと、

「○○局がこの周波数に出ている」

という情報を送るものを想像しますが、今回のliveCQは少し違います。

受信したすべてのQ65メッセージをN6NU氏が用意した専用サーバーへ送り、サーバー側で情報を解析します。

これによってDXpedition局側は、

「今、どの局が自分の信号を実際に受信できているのか」

をActive Stationsウィンドウで、ほぼリアルタイムに確認できます。

EME、特に6m EMEでは伝搬条件が非常に厳しく、

「誰が呼んでいるか」

だけではなく、

「誰のところまでこちらの信号が届いているか」

が分かることには大きな意味があります。

QMAPとMAP65からも新しい

https://livecq.n6nu.org

へスポットできるようになり、さらに複数URLへの同時スポットにも対応しました。


■ QMAP v1.0 ― Click-to-Workを搭載

QMAPも正式にv1.0となりました。

最も分かりやすい新機能が Click-to-Work です。

コールサインのオーバーレイ、デコードされた個々のメッセージ、あるいはBand Map上のコールサインをクリックすると、

・コールサイン
・周波数
・Odd / Evenのタイムスロット
・Q65サブモード

などの情報がWSJT-Xへ渡されます。

そしてダブルクリックすればQSO開始。

つまり、

見つける → 運用条件をセットする → 呼ぶ

という操作がかなり直接的になりました。

WSJT-X側はQ65モードで、VHF featuresを有効にしておく必要があります。

さらに、

・QMAPを複数同時起動可能
・WSJT-Xと同じく--rig-name=NAMEで個別管理可能
・複数のWSJT-XとQMAPを個別にペアリング可能
・Band Mapウィンドウを追加
・Astro DataやBand Mapを開いていた状態を次回起動時に復元
・N6NU SDR bridgeと連携し、最新版では複数sliceにも対応

など、本格的なEME/SDR運用をかなり意識した進化になっています。

QMAPのユーザー設定やデータの保存場所もWindowsでは

AppData/Local/QMAP

へ変更されました。

初回起動時には、旧WSJT/wsjtx/binディレクトリにある既存データが自動的にインポートされます。


■ MAP65 v4.0 ― WSJT-Xとの連携が大きく進化

MAP65もv4.0になりました。

こちらもEMEをやっている方にはかなり大きな変更です。

新しい方式では、

MAP65 = 広帯域受信担当
WSJT-X = 実際のQSO担当

という使い分けが可能になりました。

MAP65はxPol Rxを含む広帯域受信を担当しながら、実際のQSOはWSJT-Xで行えます。

そのため、

・CAT制御
・AutoSeq
・ログブック
・その他WSJT-X側の機能

をそのまま利用できます。

MAP65上でコールサインのオーバーレイやメッセージをクリックして局を選択すると、その情報をWSJT-Xへ渡してQSOできます。

さらに、MAP65とWSJT-Xによる同時受信も可能になりました。

MAP65で広帯域を監視しつつ、WSJT-Xにも適切なナローバンド音声を入力しておけば、両方が同じ信号のデコードを試みることができます。

WSJT-Xのナローバンドデコーダーは非常に高感度なので、EMEでは新しい可能性が広がりそうです。

MAP65にもQMAPと同じClick-to-Workが実装され、

・コールサイン
・グリッド
・Odd / Even
・Txモード

などをクリック操作で設定、またはWSJT-Xへ転送できます。

条件を満たしていればダブルクリックでQSO開始も可能です。

その他にも、

・IQストリーム192kHz帯域幅へ対応
・従来の96kHz / 95.238kHzとの互換性を維持
・Q65のDecode Depthを設定可能
・過去のTR周期の信号を再デコードする実験的機能
・Astro Data / Band Map / Messagesウィンドウの状態を記憶

などが追加されています。

MAP65の設定・データ保存場所も

AppData/Local/MAP65

へ変更されます。


■ ここからは普通のFT8/FT4ユーザーにも関係する変更

EMEをやらない方は、むしろここからが重要かもしれません。


1. wsjtx_log.adiの保存場所とファイル名を指定可能に

WSJT-Xのログファイル

wsjtx_log.adi

の保存場所とファイル名を選択できるようになりました。

例えば、

・NASやネットワークドライブへログを置く
・ユーザーごとに別々のログを使う
・運用環境ごとにログを分ける

といった使い方が可能になります。

Settings → Reporting → Loggingに新しい設定があります。


2. Highlight orange / Highlight blueを拡張

Highlight orange / Highlight blueのプレフィックス指定で、

* = ワイルドカード
! = 除外

が使えるようになりました。

例えば、

;K*;!KH6!KL!KP!

のような指定が可能です。

つまり、Kで始まるプレフィックスを広く対象にしながら、KH6、KL、KPなどを除外するといった設定ができます。

DXを追いかける方にはかなり便利そうです。

ただし書式にはルールがあります。

コールサインやグリッドはカンマ区切りで、各コールサインの後にもカンマが必要。

プレフィックスは前後をセミコロンで囲みます。

ワイルドカード*を使えるのは1文字のプレフィックスの後だけ。

2~3文字のプレフィックスを除外する場合は!で囲みます。


3. PWR / SWRに加えてALCも表示

対応している無線機では、

PWR / SWR / ALC

をWSJT-X上に表示できるようになりました。

Settings → Radio → Rig Dataで

「Display PWR, SWR and ALC」

を選択します。

さらにALCが高い場合、黄色または赤背景で警告表示することもできます。

デジタルモードではALC管理も重要なので、対応リグを使っている方には実用的な改善でしょう。


4. DX Call欄の局とのメッセージだけを表示可能

CQまたはCQ/73チェックボックスを右クリックすると、

現在DX Call欄に入っている局との送受信メッセージだけを表示できます。

混雑しているバンドやDX pileupなどで、

「今、この局とのやり取りだけ見たい」

という時には便利そうです。


5. 送信中のバンドボタン誤操作を防止

送信中に誤ってバンドボタンをクリックしてしまい、周波数を変更してしまう事故を防ぐようになりました。

「Allow Tx frequency changes while transmitting」が有効になっている場合だけ、送信中の変更が許可されます。

派手な機能ではありませんが、実運用ではありがたい安全対策です。


6. コンテストモードのログ処理を改善

コンテストモード中は<state>タグを書き込まないよう変更されました。

このタグがログ処理上の問題を起こしていたためです。

また、

「ARRL Field Dayモードに切り替えますか?」

といった警告も、同一セッション中に何度も表示されず、1回だけ表示されるようになりました。

コンテスト運用者には嬉しい改善だと思います。


7. RRRにも国情報とハイライト表示

RRRを含むメッセージについても、国・エンティティ情報とハイライト色が表示されるようになりました。

交信終盤のメッセージでも相手局の情報を確認しやすくなります。


8. Cloudlog関連の修正

ホテルなどからQSOをアップロードする際に発生していたCloudlog関連の問題が修正されています。


9. WSPR / MSK144 / Q65関連

・WSPRモードでのTCI audioの問題を修正
・「MSK144/Q65: Tx until 73 is received」機能を修復
・MSK144の安定性を改善

といった修正も行われています。


■ 新機能「TX-Inhibit」

これも興味深い新機能です。

同じバンドで、

WSJT-Xによるデジタル運用

SSB/CW運用

を併用するような環境で、PTTが競合する事故を防ぐための機能です。

特に複数の無線機や複数のオペレーターが同時に運用するクラブ局、コンテスト局などで有用でしょう。


■ その他

・Linux用Debianパッケージの互換性改善
・Hamlibを4.7.2へ更新

なども行われています。


■ まとめ

今回のWSJT-X Improved 3.2は、FT8/FT4そのものを全面的に作り替えたというより、

EME/Q65運用環境を大きく進化させたバージョン

と見ると分かりやすいと思います。

特に、

QMAP / MAP65 / WSJT-X / liveCQを連携させ、「誰がこちらを受信できているか」を把握し、見つけた局をクリックして、そのままWSJT-Xで交信する

という方向へかなり進みました。

一方、EMEをやらないFT8/FT4ユーザーにとっても、

・Highlight orange / blueのワイルドカードと除外指定
・ログファイル保存場所の自由化
・ALC表示
・DX Call局だけを表示する機能
・送信中のバンド誤操作防止
・コンテストログ関連の改善
・RRRへの国情報・ハイライト表示
・TX-Inhibit

など、普段の運用に直接関係する改善が多数含まれています。

ですので、

「3.2はEME向けのアップデートだから、自分には関係ない」

というわけではありません。

EME/Q65ユーザーにはかなり大きなアップデート。

FT8/FT4中心のユーザーにとっても、日常運用の使い勝手や安全性を改善する変更が多数入ったバージョン、と考えるのがよさそうです。