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

【WSJT-X Improved 3.2.0 / 260818版 リリース】2026年08月18日 16時17分58秒

【WSJT-X Improved 3.2.0 / 260818版 リリース】

本日、WSJT-X Improvedの新しい3.2シリーズがリリースされました。

https://sourceforge.net/projects/wsjt-x-improved/files/WSJT-X_v3.2.0/

今回のアップデートは、一言で言えば、

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

です。

リリースノートは英語でかなり専門的なので、「結局何が変わったの?」という方向けに、日本語で少し噛み砕いてまとめてみます。

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


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

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

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

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

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

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

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

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


■ 6m EME向けの「liveCQ」が大幅強化

今回の3.2で最も大きなテーマの一つです。

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

通常のスポットというと「○○局がここに出ている」という情報を送るイメージですが、今回のliveCQは少し違います。

各局が受信したすべてのQ65メッセージをN6NU氏が用意した専用サーバーへ送り、そこで情報を集約します。

これによってDXpedition局側は、

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

をActive Stations画面で、ほぼリアルタイムに確認できます。

EME、特に6m EMEでは伝搬状況が非常に厳しく、「呼んでいる局」だけでなく「そもそもこちらを受信できている局」が分かることには大きな意味があります。

QMAP、MAP65からも新しいliveCQサーバーへスポットでき、さらに複数の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を複数同時起動可能
--rig-name=NAMEで個別管理
・複数のWSJT-XとQMAPをそれぞれペアリング可能
・Band Mapウィンドウ追加
・Astro DataやBand Mapを開いていた状態を次回起動時に復元
・N6NU SDR bridgeの最新機能、複数sliceにも対応

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

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

AppData/Local/QMAP

へ変更。

旧ディレクトリのデータは初回起動時に自動インポートされます。


■ MAP65 v4.0 ― WSJT-Xとの連携が大きく変わった

MAP65もv4.0になり、こちらもEMEをやっている人にはかなり大きな変更です。

新しい方式では、

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

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

MAP65はxPolを含む広帯域受信を担当し、実際の送受信シーケンス、CAT制御、AutoSeq、ログなどはWSJT-X側で処理できます。

これはかなり合理的な構成です。

MAP65で見つけた局をクリックすると、その情報がWSJT-Xへ渡され、WSJT-X側でそのままQSOできます。

さらにMAP65とWSJT-Xを同時に受信させることも可能。

MAP65の広帯域受信と、WSJT-Xの高感度なナローバンドデコーダーを同時に使って、同じ信号のデコードを試みることができます。

MAP65にもQMAPと同様のClick-to-Workが実装されました。

その他、

・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の保存場所とファイル名を自由に指定可能

これまでは基本的に決められた場所にあったwsjtx_log.adiですが、保存先とファイル名を指定できるようになりました。

例えば、

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

といった使い方が容易になります。

Settings → Reporting → Loggingから設定できます。


2. Highlight orange / Highlight blueがさらに強力に

プレフィックス指定で、

* ワイルドカード
! 除外指定

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

例えば、

;K*;!KH6!KL!KP!

のように指定すれば、Kで始まる対象を広く指定しつつ、KH6、KL、KPなどを除外する、といった設定ができます。

DXingをしている人にはかなり便利な機能です。

なお書式にはルールがあり、

コールサイン・グリッド → カンマ区切り
プレフィックス → セミコロンで囲む
ワイルドカード → 1文字プレフィックスの後のみ使用可能
2~3文字プレフィックスの除外 → !で囲む

という仕様です。


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

対応している無線機では、送信中の

PWR / SWR / ALC

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

さらに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メッセージにも国名・ハイライト表示

これまでのCQ等だけでなく、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デコーダーそのものを大きく刷新したバージョンというより、

EME/Q65運用環境を一段進化させたバージョン

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

特に、

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

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

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

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

など、日常運用で便利な改良が多数入っています。

ですので、

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

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

なお開発者自身も、大きな変更を含む新バージョンへの更新前には、WSJT-X.iniwsjtx_log.adiをバックアップしておくことを推奨しています。


【高いAIを使えば、難しい問題も一発で解決して、かえって安く済む……はずだった話🤣😭】2026年08月13日 14時00分00秒


開発中のWSJT-X Improved JP1LRT Editionに、限定テスターのJK1BPAさんから、再現性のある不具合報告が届きました。

状況はこうです。

相手局からRレポートを受信
 ↓
こちらがRR73を送信
 ↓
相手に届かなかったため、相手が同じRレポートを再送
 ↓
ところがこちらは、RR73送信直後に交信相手の情報をクリアしてしまい、再送されたRレポートに反応できない

今回は再現確認のため、JK1BPAさんが送信出力を意図的に絞り、最初のRR73を相手へ届かせないという試験まで行い、ALL.TXTも提供してくれました。📡

ログを解析すると、これはAutoSeq2やAutoSeq3ではなく、CQを手動でダブルクリックして呼び出した普通のS&P運用で起きていました。

まずChatGPT側でソースコードを追跡し、原因と修正方針を整理。
次にClaude Sonnet 5へ、先入観を与えすぎない形で独立レビューを依頼しました。

Sonnetの一次解析は概ね妥当でしたが、一部に、

「この大きな処理ブロックも手動運用へ開放した方が安全かもしれない」

という提案がありました。

しかし、そのブロックは約638行。

中には単なるRR73再送処理だけでなく、

・AutoSeq2/3の候補局収集
・Wanted Hunting
・候補局の順位付け
・AS2 late-pick
・Auto Txの自動ON
・別局への自動呼出開始

まで含まれています。

もしここを安易に手動運用へ開放すると、RR73の再送を直した代わりに、操作者が意図していない別局を勝手に呼び始める可能性があります。これは危ない。😱

そこでRound 2。

ClaudeをSonnet 5から最上位のOpus 5へ変更し、エフォートもデフォルトの「高」ではなく「超高」に設定。

さらに、

「前回の自分の結論も、こちらの懸念も、どちらも信用せず、生のソースから実行順序と状態遷移を再導出せよ」

という、かなり厳しいプロンプトを渡しました。

要求したのは、

・最初のRレポート受信
・RR73送信開始
・Terminal Holdのarm
・ログ処理と画面クリア
・物理送信終了
・次の復号処理
・Rレポート再受信
・2回目、3回目のRR73
・相手から73/RR73/RRRを受信した場合
・送信上限とタイムアウト
・AutoSeq2/3やWanted Huntingへの副作用
・最小修正diff
・回帰試験表

まで全部です。

すると、さすがOpus 5・超高。

考える。
ひたすら考える。
そして猛烈に利用枠を食う🤣

現在セッションの消費量が、

52%
 ↓ 5分後
64%
 ↓
ついに100% 🔴

途中で、

「Claudeの応答を最後まで生成できませんでした」

げーーーーー🤣😭

再試行すると、

Claudeの回答が中断されました

またかよ🤣😭

さらにもう一度走らせると、また失敗表示。

これはもう、超高+大規模解析で処理限界に当たっている。分割するしかないか……

と思ったその直後、なぜか突然、完成した長大なレビュー報告書と提案パッチを吐き出しました(笑)。

そして現在セッションは、きれいに100%使用済み。




まさに、燃料を全部使い切って滑走路へ着陸した大型機状態です✈️🤣

追加クレジットの表示も、最後の解析中に$6.42から$7.08へ増加。

「高いAIを使えば、一発で地雷まで見つけて結局安く済む」

という話を書くつもりだったのに、実際には途中で何度も生成に失敗し、セッション枠を完全に食い尽くすという、予想以上に面白い展開になりました。

しかし、出てきた結果はかなり重要でした。

Opus 5は、一次解析で自分が提案した「大きなAutoSeqブロックの開放」を明確に撤回。

ソースを再追跡した結果、

・RR73再送に巨大なAutoSeqブロックを開放する必要はない
・そこを開放するとWanted Huntingや自動選局が手動運用へ流入する
・RR73再送にはprocessMessage()の再実行すら不要
・交信相手、Tx4、Auto Txを保持すれば、既存の周期送信機構がRR73を再送する
・送信は3回のソフトリミットで止まる
・さらに10回上限、300秒上限、無応答タイムアウトも残る
・相手から73/RR73/RRRを受信した場合も既存の安全処理で終了できる

と結論しました。

つまり必要なのは、大きな自動選局機構を触ることではなく、

「Terminal HoldをAutoSeq2/3など特定モードだけの機能にせず、通常の手動S&Pでも利用できるようにする」

という、ずっと小さな修正でした。

さらに、設定値の異常によってCQ応答モードが空欄になり、その状態が設定ファイルへ再保存され続ける別の問題も発見。

こちらも、無効な値を安全な「CQ: None」へ戻す小さな修正案が出ました。

最終的な提案パッチは、

・変更1ファイル
・4関数
・5ハンク
・危険な638行のAutoSeqブロックは変更ゼロ

という、かなり絞り込まれた内容です。

もちろん、AIがそう言ったから採用するわけではありません。

Opusの報告とパッチをChatGPT側でも、正式なP2ソース、生のALL.TXT、実際の関数呼出順序と突き合わせて再確認しました。

結果、技術的な中核は整合。
パッチも正式ソースへcleanに適用可能。
現時点でブロッキング欠陥は見つかっていません。

ただし、作業はまだこれからです。

現在配布中のP2正式パッケージは変更せず、そのまま観察を継続。

今回の修正は別の隔離テスト版として実装し、

・手動S&P
・FT8/FT4
・RR73再送
・相手の73/RR73/RRR
・AutoSeq2/3
・Max Distance
・Wanted Hunting
・意図しない別局への自動送信が起きないこと
・異常設定値の自動修復

などを改めて実機試験します。

今回改めて感じたのは、AI開発で重要なのは「AIにコードを書かせること」ではなく、

・最初の答えを疑う
・別のAIに独立レビューさせる
・同じAIにも自説を撤回できる条件で再検証させる
・大きな修正より、証明できる最小修正を選ぶ
・最後は人間がログ、ソース、実機で確認する

という使い方なのだと思います。

高性能AIは確かに高い。
超高エフォートは燃料も猛烈に食う。
しかも、ときどき離陸中止や生成中断まで起こす🤣😭

それでも、一見もっともらしい危険な修正を事前に排除し、638行の変更候補を5ハンクまで縮められたなら、再ビルド、再配布、テスター全員の再試験、そして新しい不具合を生むコストを考えれば、結果として安かった可能性はあります。

ただし、まだ「可能性」です。

本当に一発で核心へ到達したのか。
本当に副作用なく直るのか。

答えは、これから作る隔離テスト版と実運用ログが教えてくれます。🔧📡

AIは優秀。
でも燃料計と最終進入は、人間が最後まで監視しないといけませんね
🤣👍