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

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の該当部分
限定テストに協力してくださった皆さん、ソースレビューと実運用確認に協力してくださった皆さんに、改めて感謝いたします。📡

「50.303MHzが選べない人へ ― 周波数登録、たった4ステップです2026年07月27日 17時39分44秒

以前このブログで周波数の使い分けについて書きました。

周波数の使い分けについて

でも実際、多くの人が標準周波数(50.313MHz)から動こうとしません。

これ、単に周波数を事前にソフトウェアへ登録していないだけなんじゃないでしょうか。

50.303MHz(国内通信用サブ周波数、標準が混雑した時用)の登録方法を、簡単に説明します。

① メニューから「周波数」タブを選択

(JTDXでは「使用周波数」という表記です)

② その枠内を右クリック

③ ポップアップの中から「挿入」をクリック

→「周波数を追加」のコラムが表示されます。

④ そこに 50.303 と入力してOK

→ 周波数リストに追加完了です。

以降はWSJT-XでもJTDXでも、メインUIの周波数横にある「バンドの選択肢」から選べるようになります。

実は登録しなくてもQSYできる

バンド表示(例:6m)を消去して、50.303 と直接入力しEnterを押すだけで、その周波数にQSYできます。

ぜひ一度試してみてください。

杉並から18,669km ― PY5CC受信で実感したPSKRの価値2026年07月27日 14時00分13秒

昨日、仕事から帰ってきてPSKRを何気なく確認したら、驚くべき記録が残っていました。

ブラジルのPY5CC(GG54RE)を受信していたのです。

260726_224730    50.313 Rx FT8    -18 -0.1 2039 K8SIX PY5CC GG54

PY5CCとは過去にF2伝搬でQSOしたことがあります。ALL.TXTには、彼が北米局を呼んでいた電波が日本まで届いていた記録として残っていました。

自分のグリッド(PM95TQ)とPY5CCのグリッド(GG54RE)の位置関係を計算してみると、方位角37.6度・距離18,669km。当日のアンテナ固定方向は35度――ほぼ正面から入ってきていたことになります。単なるバックローブでの拾いものではなく、ダイレクトパスでした。伝搬がEsとF2の複合だったのか、TEPが絡んだのか、あるいはEsのコーダルホップ連鎖だけだったのかは分かりませんが、地球一周の半分近い距離を受信できたというだけでもワクワクします。

なぜこの受信に気づけたのか

答えはシンプルです。PSKRに情報を送信していたからです。

PSKRによれば、この瞬間PY5CCの信号を受信報告していたのは、僕を含めて3局。青葉区の局(PM95SO)と、白子町の局(QM05EK)でした。もちろんPSKRへの送信をオフにしている局もいるはずなので、実際にはもっと多くの局が受信していた可能性があります。

もし僕がPSKRへの送信をオフにしていたら、この受信記録は自分のALL.TXTの中に埋もれたまま、誰の目にも触れることなく終わっていたでしょう。逆に言えば、送信をオンにしている局が3局いたからこそ、この奇跡的な瞬間がお互いに可視化されました。

Give and Takeの精神

PSKRの設定方法については、以前この記事で詳しく書きました。今回改めて、設定画面を最新のものに差し替えて掲載します。

JTDXの設定画像

WSJT-X

MSHV

JTAlert

JTAlertについては、PSKRとは直接の関係はありませんが、HamSpots(https://hamspots.net/)で情報共有ができます。

設定はどれも数クリックで完了します。それでもなお、自局の情報を一切出さずに、他局が受信報告してくれた「旗が立った」という結果だけを享受している局を見かけることがあります。ネット接続が従量制、あるいはPCがオフライン運用という事情であれば仕方ありませんが、そうでないなら、ぜひオンにしていただきたいと思います。

情報の共有はとても大切なことです。しかしリグがCAT非対応であれば仕方ないですね。CAT非対応だと違うbandの情報を上げてしまうことがあり注意が必要です。

さらにその情報に正確性を出すため、ご自身のGrid Locatorは正確に入れましょう。各ソフトウェアには自局のGrid Locatorを入力する場所があります。少なくとも6桁のデータを入れましょう。4桁だと大雑把な位置表示になり、PSKR地図上で海上になってしまったりします。

JTDXはデフォルトで10桁まで対応しています。一方でWSJT-Xは6桁までですが、iniファイルをいじって10桁まで表示させることも可能となり、多くの方が8桁ないしは10桁のGrid Locatorを表示させています。

10桁のGrid Locatorを調べるには

http://www.k7fry.com/grid/

このサイトでご自身のご自宅を見つけてください。10桁まで入れるのに抵抗のある方は8桁で十分です。

iniファイルの編集は、WSJT-X/JTDXを閉じた状態で行ってください。

"C:\Users\各人の設定\AppData\Local\WSJT-X\WSJT-X.ini"
"C:\Users\各人の設定\AppData\Local\JTDX\JTDX.ini"

をテキストエディタで開き、いずれのiniファイルも

[Configuration]
MyCall=JP1LRT
MyGrid=PM95tq47gc

(私の場合はこのようになっています)

MyGrid= を編集して保存した後に各ソフトウェアを立ち上げれば反映されます。結果はPSKRでも確認できます。

情報はGive and Takeが基本です。今回のPY5CC受信も、複数局が情報を出し合っていたからこそ、お互いに「あの瞬間、あの局も同じ信号を捉えていた」と分かる形になりました。

目覚ましで起きたら、50MHzは北米大オープンだった――杉並区で観測した今季最大の6m Es2026年07月21日 13時46分53秒

2026年7月21日の朝、目覚ましをセットしていた06:30に起きて無線機を見たら、50MHzはすでに北米の大オープン状態だった。

後から聞いたところでは、05:30頃にはもう開いていたらしい。

実は朝5時半にトイレへ行った時、一度起きていた。 あの時スマートフォンを見ておけばよかった……と少し後悔している(笑)

「自分が不在の時に限って6mが開く」というのは、もはや6mあるあるだと思う。

だからこそ、昨日のヨーロッパに続いて、今朝は自宅にいる時にこれほどの北米オープンに巡り会えたことが、素直に嬉しかった。

50MHz FT8北米オープン時のWSJT-Xデコード画面

上の画像はピーク時そのものではないが、北米局が画面を埋めていた当時の雰囲気は伝わると思う。

WSJT-Xの受信ログを解析してみた

今回、僕のWSJT-XのALL.TXTから、06:33~11:53 JSTの北米局を抽出して解析した。

画面には米国、カナダ、メキシコの局が次々と現れていた。集計条件を米国・カナダ・メキシコに絞った結果は次の通りだった。

  • ユニークでデコードした米国・カナダ・メキシコ局:430局
  • 延べデコード数:8,817回
  • 1分間のピーク時刻:06:35 JST
  • 1ピリオド、15秒間の最大ユニーク局数:38局
  • 1ピリオドのピーク時刻:06:35:45 JST

06:35~06:41頃には、1ピリオド30局を超える状態が何度も続いていた。

僕が起きて無線機の前に座った時には、すでに今シーズンで最も濃い数分間に突入していたことになる。

グラフを見ると、起床直後の06:35頃に最大の山があり、その後いったん落ち込みながらも、08:40頃から10時前後にかけて再び厚い入感が続いていたことが分かる。

一瞬だけのオープンではなく、濃淡を繰り返しながら午前中いっぱい続いた、規模の大きなオープンだった。

西海岸だけではなかった

コールサインとグリッドロケーターのデータベースを照合したところ、430局中380局のグリッドを確認できた。

延べデコード数が多かったグリッドフィールドは、次の通りだった。

  • EM:2,527回
  • DM:2,365回
  • EN:1,835回
  • DN:571回
  • FN:453回
  • FM:352回

DMの米国南西部、EMの中南部、ENの中西部北部が特に強かったが、DNのロッキー山脈北部、FMの南東部、そしてFNの米国北東部・ニューイングランド方面まで届いていた。メキシコからはXE2JS、XE2CQ、XE2Xの3局を確認しており、メキシコ中部・北東部方面までパスが伸びていたことになる。

西海岸や南西部だけが開いていたのではない。

太平洋岸から中部、東海岸方面、そしてメキシコ方面まで、北米大陸の非常に広い範囲が同時に日本へ入感していた。

北米大オープン時のPSK Reporter画面

PSK Reporterの画面を見ても、北米大陸の西側だけではなく、中部から東海岸に至る広い範囲へ伝搬していた様子が分かる。

なお、コールサイン・データベースのグリッド情報は、移動運用や引っ越しなどにより、当日の実際の送信地点と異なる場合がある。

また、PSK Reporterの表示は、受信ログそのものとは性質が異なる。

それでも、今回の伝搬が北米大陸の非常に広い範囲に及んでいたことを示す資料としては、十分に印象的だと思う。

同じ関東でも、見えている北米がまったく違う

今回、特に面白かったのがJR1LZK局との比較だった。

JR1LZK局は水戸市、QM06FI。

僕は東京都杉並区、PM95TQ。

同じ06:48:45 JSTのピリオドを比較しても、画面に現れている局数も、見えている局の顔ぶれも大きく異なっていた。

JR1LZK局の設備は、9.1mブームの7エレ八木を3枚使用した三角形スタック。

水平間隔7.5m、垂直間隔7.0m、最上段は32mという本格的な6m設備で、1ピリオドに北米局を60局以上デコードした場面もあったという。

一方、僕の設備は杉並区の住宅地に設置した、9.8mブームの7エレ一枚。

設備差は当然大きい。

しかし、それだけではない。

50MHzのマルチホップEsでは、最終ホップの着地点や散乱域の位置によって、同じ関東地方でも受信状況が大きく変わる。

さらに、次のような要素がすべて重なる。

  • アンテナの利得と高さ
  • アンテナのビームパターン
  • 周辺のノイズフロア
  • 強力なJA局によるマスク
  • 受信機やAGCの状態
  • WSJT-XとJTDXのデコード特性

したがって、当然ですが今回の430局という数字は全国共通の値ではなく、

「2026年7月21日、東京都杉並区PM95TQのJP1LRT局で観測した北米オープン」

という、一地点での観測記録として見るべきです。

逆に言えば、杉並区の7エレ一枚でも1ピリオド38局、WSJT-X単独のログで430局が確認できたのだから、この日のオープンがどれほど大きかったかが分かる。

WSJT-XとJTDXの二面起動が実戦で役に立った

僕はWSJT-XとJTDXを同時に起動して運用している。

同じ受信音を入力していても、両者のデコード結果は完全には一致しない。

WSJT-Xではデコードできなかった局をJTDXだけが拾うこともあれば、その逆もある。

今回の実際のQSOログにも、WSJT-XのALL.TXTには記録されていない局が含まれている。

それらはJTDX側だけでデコードできた局を見つけ、周波数やメッセージを確認した上で、WSJT-X側から手動で対応してQSOしたものだ。

だから、

「WSJT-Xでデコードした430局の中から交信した」

という単純な包含関係にはならない。

実際の運用では、二つのデコーダーがそれぞれ拾った情報を、人間がリアルタイムで統合している。

こうした運用をしているDXerは少なからずいる。

彼らもやり手だと思う。

二面起動は単に画面を二つ並べているのではない。

片方で取りこぼした弱い局をもう片方で救い、それを実際のQSOへつなげる、実戦的なデコード・ダイバーシティとして機能している。

今回は送信タイミングも特殊だった

50MHz FT8では、通常はJA局が奇数側、

2nd / ODD
15秒・45秒

で送信し、DX局が偶数側、

1st / EVEN
00秒・30秒

を使うという慣習がある。

JAの強力なローカル信号が、JA局が受信したい弱いDX信号を覆い隠さないための考え方だ。

しかし今回は、北米局の多くが奇数側で送信していた。

米国内では東海岸と西海岸の間でも送信タイミングが分かれることがあり、すでに成立していた米国内や他地域との運用の流れを維持したまま、突然JAとのパスが開くことがある。

また、米国とヨーロッパが同時に開いている場合、ヨーロッパ局は通常偶数側で送信するため、米国局は奇数側を使う。

その状態で米国からアジアへのパスまで開けば、アジア側が偶数を使わざるを得ない状況も生じる。

だから重要なのは、

「原則を知った上で、その時の状況を読むこと」

だと思う。

原則を知らずに偶数側でCQを出し続けることと、実際に入感しているDX局のタイミングを確認し、状況判断の結果として偶数を選ぶことは、同じではない。

原則を守ることと、状況を読まないことは違う

今回、北米局の多くが奇数側に並んでいる中で、奇数側からCQを出し続けるJA8エリアの局がいた。

Esに乗った強力なJA信号が、同じタイミングで届いている複数の弱い北米局をマスクしていた。

さらに、偶数側でCQを出していたJA局を、別のJA局が呼ぶ場面も見られた。

北米がこれほど大きく開いている時の50.313MHzでのCQは、実質的には「CQ DX」と同じ意味を持つ。

国内同士でQSOしたいのであれば、50.303MHzのFT8を試すか、FT4へ移るという選択肢がある。

少なくとも、周囲に何が入感しているかを見ずにCQを出すべきではないと思う。

50MHz FT8の基本的な運用目安としては、次のようになる。

  • CQは原則として2nd / ODD、15秒・45秒
  • ただしDX局が実際にどちら側で送信しているかを必ず確認する
  • 50.323MHzは大陸間DX用として扱い、国内QSOには使用しない
  • 50.313MHzが混雑している時の国内QSOは50.303MHzを検討する
  • 国内QSOではFT4も活用する

このあたりを共有しておくことが、DX局を守り、同時にJA全体の受信機会を守ることにつながると思う。

詳しい考え方は、以前こちらの記事にまとめている。

50MHz FT8で国内局とDX局が共存するために

だから6mは面白い

今回は新しいグリッドロケーターとも数多くQSOできた。

05:30頃から開いていたと聞くと、朝5時半にトイレへ行った時にスマートフォンを確認していれば……とは思う。

しかし、目覚ましで起きた時にはすでに大オープンしていて、そのピーク付近を自分の設備で実際に体験できた。

設備が違えば見える局数が違う。

地域が違えば、同じピリオドでも見えている局そのものが違う。

ソフトが違えば、拾える弱い局も違う。

そして最後は、その情報を見たオペレーターがどう判断し、どう動くかで結果が変わる。

だから6mは面白い。

2026年夏の、忘れられないオープンの一つになった。