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

「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年夏の、忘れられないオープンの一つになった。

第56回 6m AND DOWN コンテスト X50 参加記2026年07月06日 16時59分56秒

第56回 6m AND DOWN コンテスト X50 参加記

西高北低の6m、そして届かなかったあと一歩

第56回 6m AND DOWN コンテストに、今年も X50部門 で参加しました。

まず最初に、交信してくださった皆さん、ありがとうございました。
呼んでいただいたのに取り切れなかった皆さん、ごめんなさい。
また次のチャンスで、ぜひよろしくお願いします。

今年の6mは、ひと言でいえば 西高北低 でした。
西・南西方面はかなり使えた一方で、東北から北海道方面は限定的。
スキャッターも派手には出ず、「どこでも開いている」という感じではありませんでした。

開始直後、50MHz FT8ではEU方面が開いていたようですが、そこは完全スルー。
今回はコンテストに専念しました(笑)

今年の全体像

今年の特徴は、大きく分けると次のようなものでした。

  • スタート直後のペースはかなり良好
  • 西・南西方面、特に九州・沖縄方面が強い
  • 北海道方面は一部のみで、全面的なオープンではない
  • スキャッターは限定的
  • CWの比率がかなり高い
  • 山口、滋賀、小笠原など、取りたかったマルチを落とした
  • 途中で仮眠と短い休憩を入れたが、大勢には大きく影響しなかった

コンテストとしては、かなり楽しめました。
ただ、あと一歩届かなかった悔しさも残りました。

交信局数の推移

今年の交信局数の推移を見ると、スタート直後はかなり良い入りでした。

特に21時台はSSBで一気に局数が伸び、最初の1時間でかなりの土台を作ることができました。
その後、22時台からCWへ比重を移し、23時台、0時台にかけてCW中心で細かく拾っていく形になりました。

一方で、深夜帯は例年通りほぼ止まります。
2時過ぎから5時頃までは仮眠を取りましたが、この時間帯は毎年大きく伸びる時間ではないため、スコアへの影響はほとんどなかったと思います。

朝5時以降に再開し、午前中に再び局数が伸びました。
特に9時台から11時台にかけては、今年の伸びを支えた重要な時間帯でした。

図1:2026年と2025年の交信局数推移

今年のグラフは、昨年と比べて明らかに上側を推移しています。
ただし、単に「ずっと開いていた」というよりは、開いている方向と時間帯をうまく拾っていった結果という印象です。

30分ごとの動き

30分単位で見ると、今年の動きはかなり分かりやすいです。

スタート直後の30分は非常に強く、その後も0時台前半までは良いペースを維持しました。
その後は深夜帯で一気に落ち込み、5時台から再始動。
午前中に再び伸び、終盤も粘る形でした。

ざっくり言うと、次のような流れでした。

  • 21時台:初動の主力。SSBで一気に積む
  • 22〜23時台:CWへ移行しつつ、西・南西方面を拾う
  • 0〜1時台:CW中心。弱いところを拾う時間
  • 2〜5時台:実質的に休止・仮眠
  • 5〜8時台:CWで各地を拾い直す
  • 9〜11時台:今年の重要時間帯。西・南西方面が効いた
  • 12時台:短時間休憩の影響あり
  • 13〜14時台:最後の追い込み

一分あたりの最大交信局数

一分あたりの最大交信局数は、今年もやはりスタート直後に出ています。

今年の最大は 1分間に4交信
これはすべてSSBで、21時台前半に集中していました。

具体的には、最大レートを記録したのは以下の時間帯です。

モード 最大レート 回数 時刻
SSB 4 QSO/分 4回 21:08、21:10、21:11、21:19
CW 3 QSO/分 3回 22:07、23:18、23:29

SSBの瞬間最大レートはやはり強いです。
ただし、今年の全体を支えたのはCWでした。

CWでは1分4局までは行っていませんが、弱い信号、微妙なパス、混み合った時間帯を安定して拾うには、やはりCWの力が大きいと感じました。

CWとSSBの比率

今年はCW比率が高い年でした。

ここ数年のモード比率を見ると、今年はかなりCW寄りです。

CW SSB CW比率
2022 364 287 55.9%
2023 330 237 58.2%
2024 362 271 57.2%
2025 309 269 53.5%
2026 397 256 60.8%

今年は5年の中で最もCW比率が高くなりました。

これは、単にCWに長くいたというだけではなく、コンディションの性格も反映していると思います。

九州・沖縄方面はSSBでもかなり取れました。
一方、東海、北陸、中国、北海道方面などは、CWで拾った局の比率が高くなりました。

つまり今年は、

強く開いた方向はSSBでも取れた。
微妙な方向はCWで拾った。

という年だったと思います。

地域別に見た今年のコンディション

ログの受信ナンバーをもとに地域別に見ると、今年の特徴はかなり明確です。

九州・沖縄方面

今年いちばん印象に残ったのは、やはり九州・沖縄方面です。

ここ数年の傾向を見ると、九州・沖縄方面は明らかに存在感を増しています。

地域 2022 2023 2024 2025 2026
九州・沖縄 33 31 32 44 63

2022〜2024年は30局前後でしたが、2025年に増え、今年はさらに大きく伸びました。

しかも今年は、九州・沖縄方面のCW/SSB比率がほぼ半々でした。
これは重要です。

弱いパスをCWで拾っただけなら、CW比率がもっと高くなるはずです。
しかし今年はSSBでもかなり交信できています。

つまり、九州・沖縄方面は単に「届いた」のではなく、かなり実用的に開いていたと見てよいと思います。

東海方面

東海方面も今年は伸びました。

ただし、九州・沖縄とは少し性格が違います。

東海は局数としては増えましたが、CW比率もかなり高くなっています。
これは「強く開いた」というより、広く届いたが、信号としてはややマージナルだったという印象です。

SSBで楽に積むというより、CWで丹念に拾った伸び方でした。

北海道方面

北海道は今年、かなり限定的でした。

2024年は別格でした。
開始直後から北海道が強く、101〜114の多くの地域が一気に入る、いわば「北が全面的に開いた年」でした。

それに対して今年は、北海道方面のオープンは狭く、深さもありませんでした。

今年取れた北海道方面は、主に101〜106の北部・中央部寄りでした。
一方で、107以降、つまり根室、後志、十勝、釧路、日高、胆振、檜山、渡島方面は届きませんでした。

北海道方面 2022 2023 2024 2025 2026
合計 34 8 54 22 11

2024年の北海道54に対して、今年はかなり少なめ。
これは今年の「北低」をよく表しています。

中国地方と山口

今年の面白い、というか気持ち悪いポイントが山口です。

中国地方全体がまったくダメだったわけではありません。

岡山、島根、鳥取、広島は交信できています。
さらに西側の福岡、佐賀、長崎、熊本もよく入っています。

それなのに山口だけが落ちました。

コード 地域 2026
31 岡山 2
32 島根 3
33 山口 0
34 鳥取 1
35 広島 3
40 福岡 11
41 佐賀 9
42 長崎 11
43 熊本 8

これは単純な「西が開かなかった」では説明できません。

山口局の活動が少なかったのか、出ていたがタイミングが合わなかったのか、あるいは関東から見たEsのスキップの谷に山口付近が入ってしまったのか。

原因は断定できませんが、少なくとも今年の山口は明確な空白でした。

マルチの伸び方

今年のマルチは、スタート直後にかなり進みました。

21時台だけで、関東周辺、東北の一部、東海、近畿、九州・沖縄、北海道の一部まで一気に入りました。
特に21時台に沖縄、福岡、熊本、長崎、宮崎、佐賀などが入ってきたことで、今年の西・南西方面の強さが早い段階で見えていました。

その後、22〜0時台で少しずつ追加。
深夜に細いパスをCWで拾い、朝以降もCWで未取得地域を拾っていきました。

今年の新マルチ追加の流れは、おおよそ次のような感じです。

時間帯 新規マルチの動き
21時台 初動で大きく伸びる。九州・沖縄、東海、近畿、北海道の一部も入る
22時台 鹿児島、長野、三重などを追加
23時台 京都、岐阜、岩手などを追加
0時台 新潟、秋田、徳島を追加
1時台 宗谷を追加
2時台 広島を追加して仮眠へ
5〜8時台 鳥取、香川、福井、岡山、島根、青森、富山、高知、兵庫などを追加
10〜11時台 大分、北海道の一部、石川を追加
14時台 最後に愛媛を追加

最後の愛媛はかなり大きかったです。
終盤に1つでもマルチが増えると、スコアへの効き方がまったく違います。

小笠原は残念

小笠原は、運用局がいたことは把握していました。

しかし今回は開きませんでした。
これは本当に残念。

小笠原は、そこに局がいても、開かなければどうにもなりません。
ある意味、6mらしいマルチです。

今年は西・南西方面がよく、北海道方面が限定的、そして小笠原は届かず。
このあたりが、今年のコンディションの偏りをよく表していたと思います。

仮眠と休憩

毎年のことですが、2時過ぎから5時頃までは仮眠を取りました。

この時間帯は、6m AND DOWNの50MHzでは大きく伸びる時間ではありません。
今年も2時台に少しだけ動きがありましたが、その後はほぼ止まりました。

経験的にも、この仮眠はスコアへの影響がかなり小さいと思っています。

一方、今年は12時から20分ほど休憩を入れました。
ここは多少影響があったかもしれません。

12時台は全体としても少し落ちています。
ただ、18時間のコンテストを最後まで集中して戦うためには、休憩も必要です。
ここは仕方ないところです。

昨年との比較

昨年と比べると、今年はかなり良い内容でした。

昨年はマルチが伸びず、全体としても少し苦しい印象でした。
今年は交信の流れもよく、特に西・南西方面の伸びが大きく効きました。

ただし、単純に「局数が増えたから良かった」というだけではありません。
スコア上は、局数の増加とマルチの増加がほぼ同じくらい効いています。

つまり今年は、

局数も増えた。
マルチも増えた。
その両方で昨年を上回った。

という内容でした。

ここ数年の傾向

自分の6m AND DOWNの参加履歴を見ると、単純な年比較は少し注意が必要です。

2014年から2019年頃は、主に /6 での移動運用でした。
2020年と2021年はC50、つまり電信部門でした。
そして2022年以降が、現在の比較対象となる関東固定X50です。

そのため、今年の結果を直接比較すべきなのは、主に2022年以降です。

2022年は総合的に強い年。
2023年はやや抑えめ。
2024年は北海道を含めた大きなオープンがあり、かなり強い年。
2025年はマルチ面で苦しい年。
そして今年2026年は、西・南西方面を中心に伸ばした年でした。

関東で勝つことと、全国で勝つこと

このコンテストは、関東で勝てても全国で勝てるとは限りません。

50MHzの場合、関東はローカル局数が非常に多く、開かない年でも一定の局数を積めます。
その意味では、関東固定局には大きな強みがあります。

一方で、全国的に大きく開くと、地方の強い局は関東の大量局を一気に得点源にできます。
九州や北海道、その他の移動局が関東を大量に取れるようなコンディションになると、全国順位では関東固定局が必ずしも有利とは言えなくなります。

つまり、

関東エリアで勝つゲーム
全国で勝つゲーム

この2つは、似ているようで少し違います。

全国を狙うなら、実は「開きすぎる年」よりも、「他地域が爆発しすぎず、自分だけがうまく拾える年」の方がチャンスがあります。

今年はその意味で、かなり面白いコンディションでした。
ただ、全国トップを狙うには、あと数マルチ欲しかったというのが正直なところです。

鬼門のマルチ

この数年のログを見ると、鬼門のマルチも見えてきます。

特に難しいのは、北海道の一部です。

ここ数年で見ると、日高、檜山は非常に厳しい。
根室、胆振、渡島も簡単ではありません。
小笠原は、局がいて、なおかつ開いてくれないとどうにもなりません。

今年落とした中で、特に悔しいのは山口と滋賀です。

山口は、周辺が取れているだけに悔しい。
滋賀も、決して地理的に無理な場所ではないだけに悔しい。

こういう「取れそうで取れないマルチ」が、結果的に最後まで効いてきます。

今年のまとめ

今年は、全面的に開いた年ではありませんでした。

西・南西方面は強く、特に九州・沖縄方面はかなり実用的に開きました。
一方で、北海道方面は限定的。
スキャッターも派手ではありませんでした。

その中で、SSBで積めるところは積み、CWで拾うべきところは拾う。
アンテナ方向を見ながら、開いている方向、散乱している方向を探る。
そういう意味では、6mらしい、かなり面白いコンテストだったと思います。

コンディションに翻弄されつつも、楽しみながら全力で参加できました。

以下、スコアのネタバレが含まれます。
見たくない方は、スルーしてください。
























































今回の自己集計

最後に、今回の自己集計です。

今年はCQ WW VHFとの日程重複があり、海外局からも呼ばれましたが、6m AND DOWN上は国内コンテストのため0点扱いです。

項目 数値
ログ上の交信数 653
得点対象ポイント 642
マルチ 49
スコア 31,458

0点交信の内訳は、海外局6局と国内重複5局でした。

50マルチには届きませんでした。
ここは少し悔しいところです。

参考:関東固定X50期の比較

部門 エリア ポイント マルチ スコア 備考
2022 X50 関東 647 51 32,997 公式
2023 X50 関東 565 47 26,555 公式
2024 X50 関東 618 56 34,608 公式
2025 X50 関東 577 44 25,388 公式
2026 X50 関東 642 49 31,458 自己集計・提出前

2026年は、関東固定X50期で見ると、2024年、2022年に次ぐ位置になりました。
公式審査後に多少変動する可能性はありますが、自分としては、今年のコンディションの中ではよく粘れたと思います。

交信してくださった皆さん、改めてありがとうございました。
また次回、お会いできるのを楽しみにしています。

FT8 と AGC2026年06月19日 22時05分29秒

FT8運用テク WSJT-X / JTDX の AGC 設定について、少し整理してみます。 WSJT-Xのユーザーガイドでは、受信レベルについて 「無信号時のノイズレベルをおおむね30dB程度にし、AGCはOFF、またはRF Gainを下げてAGCの動作を最小限にするのがよい」 という趣旨の説明があります。 これ、単に 「AGC OFFにすると感度が上がる」 という話ではありません。 本質は、 強い局に引っ張られて 受信機全体のゲインが下がり 同じパスバンド内の弱い局まで沈んでしまう これを防ぐためです。 FT8では、2.5〜3kHzくらいの受信帯域の中に、強い局も弱い局も同時に並びます。 たとえば同じ帯域内に、 ・+20dB級の強いローカル局 ・-20dB台のDX局 が同時にいたとします。 AGCがONだと、受信機は強い局に反応してゲインを下げます。 すると、その強い局だけでなく、同じ受信帯域内にいる弱いDX局まで一緒に下げられてしまうことがあります。 FT8でAGC OFFが推奨される理由はここです。 AGC OFFなら、強い局は強いまま、弱い局は弱いまま、できるだけ固定されたゲインでWSJT-X/JTDXへ渡せます。 つまり、 「強局に弱局を巻き添えにされにくい」 ということです。 ただし、ここが大事なのですが、AGC OFFはかなりシビアに受信レベルを調整する必要があります。 自分の場合、6mだけでなくHFでも、無信号時の入力レベルはだいたい25dBくらいにしています。 30dBぴったりを狙うというより、少し余裕を持たせる感じです。 6mでは突然Esで近距離局が強烈に入ったり、同じ地域のローカル局が非常に強く入ったりします。 HFでも、コンディションや時間帯によっては、強い局と弱いDXが同じ帯域内に混在します。 そのため、 ・PREAMP ・ATT ・RF Gain ・USB/AF出力 ・PC側入力レベル このあたりをかなり丁寧に追い込む必要があります。 AGC OFFは、設定すればそれで終わりというより、 「自分の受信環境に合わせて、過不足のないレベルに追い込む」 という運用だと思っています。 ただし、AGC OFFにも当然デメリットがあります。 強烈なローカル局、いわゆる凶信号・狂信号(笑)が出てくると、受信機やUSBオーディオ入力が過大入力になる可能性があります。 その場合は、 ・WSJT-X/JTDXのレベルメーターが赤に張り付く ・ウォーターフォール全体が濁る ・強信号の周囲に変なスプリアスっぽい線が出る ・そのスロットだけ弱信号のデコードが明らかに落ちる こういう現象が出ることがあります。 この場合は、AGC ON/OFF以前に、まず過入力対策です。 優先順位としては、 PREAMPをOFF ATTを入れる RF Gainを少し下げる USB/AF出力やPC入力レベルを見直す それでも駄目なら、状況限定でAGC FAST/MEDやJTDXのAGCcも検討 という感じでしょう。 JTDXには AGCc という機能があり、これを使って入力レベル変動をある程度カバーするという考え方もあります。 自分はJTDXのベータテスターでもあるので、以前は 「無線機側AGC ON + JTDX側AGCc 有効」 を基本にしていた時期もありました。 これはこれで実用的な設定です。 特に、強信号が多い環境や、入力レベルの変動をある程度ソフト側で吸収したい場合には、AGCcは有効な手段の一つだと思います。 ただし、AGCcはあくまでソフト側の補助機能です。 受信機の前段、ADC、USBオーディオ入力などが本当に過大入力で飽和している場合、それを根本的に救うものではありません。 そこは、 「AGCcがあるから何でも大丈夫」 ではなく、 「まず受信系を適正レベルに追い込む。そのうえで補助的に使う」 という理解が必要だと思います。 現在の自分は、 無線機側 AGC OFF 無信号時25dB前後 強信号時に飽和しないようシビアに調整 必要に応じてATT/RF Gainで追い込む という設定で使っています。 特に6m DXでは、弱いEUや中央アジア方面を拾いたい一方で、近距離の非常に強い局も同じパスバンド内に出てきます。 この状況では、AGC ONで強局にゲインを引っ張られるより、AGC OFFで固定ゲインにして、入力レベルを自分で追い込んだ方が結果が良いと感じています。 もちろん、これは環境次第です。 無線機、アンテナ、PC入力、ローカル局の強さ、バンドの混雑度、使っているソフトによって最適解は変わります。 ただ、FT8/FT4の基本的な考え方としては、 AGC OFFは「感度アップ」ではない 強局に弱局を巻き添えにされないための設定 無信号時25〜30dB程度が実用的 30dBは絶対値ではなく目安 AGC OFFは受信レベル調整がかなりシビア 強烈なローカル局、いわゆる凶信号・狂信号(笑)には過入力対策が必要 JTDXのAGCcは有効な補助手段だが、過入力そのものを救うものではない 最終的には自分の受信環境で追い込むしかない という理解でよいと思います。 FT8は弱信号モードですが、実際の運用では 「弱い信号をどう拾うか」 だけでなく、 「強すぎる信号をどう扱うか」 もかなり重要です。 特に6mでは、ここが意外と効きます


6m FT8 DXシーズン到来 — 皆で幸せになるための運用作法(2026年版)2026年05月22日 11時20分33秒

## 6m FT8 DXシーズン到来 — 皆で幸せになるための運用作法(2026年版)

毎年この時期になると書いている話ですが、今年も改めて。

2020年・2023年にも同様の記事を書きました。


繰り返し書くのには理由があります。毎年FT8を始める方が一定数いて、この慣習を知らないまま運用されるケースが続くからです。決して責める話ではありません。知らなければ当然そうなります。だからこそ書き続けています。

---

### 今年(2026年)の状況


Solar Cycle Sunspot Number Progression(出典:NOAA/NWS Space Weather Prediction Center、2026年5月2日更新)

上のグラフをご覧ください。太陽活動サイクル25は2024年末頃にSSN 200超でピークを打ち、2026年現在は明確な下降局面に入っています。それでも平滑化SSNはまだ100前後と高水準にあり、F2伝搬は引き続き活発です。

そしてこの時期、50MHzにはもう一つの伝搬が加わります。マルチホップEsのシーズン(5月〜8月上旬)です。F2とEsが重なるこの時期は、50MHzのFT8バンドに多くの局が集まります。だからこそ、バンドの使い方を改めて確認しておく価値があります。

---
### なぜ「JAは CQ の Tx が奇数秒(2nd / 15:45)」なのか

FT8は15秒を1ピリオドとして、偶数秒スタート(00秒・30秒)と奇数秒スタート(15秒・45秒)の2系統が交互に動いています。

マルチホップEsでヨーロッパ・中東・北米が入感するとき、相手のDX局は多くの場合偶数秒(00/30)でTXしています。DX局が送信している間、こちらは受信する。そして奇数秒(15/45)でこちらが送信し、DX局が受信する——これが理想の流れです。

ところがJAの局が偶数秒(00/30)でCQを出していると何が起きるか。DX局が送信しているタイミングと完全に被ります。自局の強いローカル信号が周囲のJA局の受信機でDXの微弱な信号を覆い隠してしまい、せっかくのDXを誰も受信できません。

逆に言えば、JAが一斉に奇数秒(15/45)でTXする習慣を守れば、偶数秒(00/30)の受信タイムを全員で共有できる。限られたチャンスを最大多数で活かせる、極めて合理的な取り決めです。

義務でも規則でもありません。しかし欧米の6mコミュニティでは広く認知されており、「JAは2nd」は国際的に通用するコンセンサスです。

考えてみてください。CQをどちらのピリオドで出しても、応答が来る確率は変わりません。ならば奇数秒(15/45)で出すことで、偶数秒のDXの弱い信号を守れるなら——自分には何の損もなく、バンド全体が得をする。こんなにコストパフォーマンスの良い協力はないと思いませんか?

---

### 6m bandのDXを守る意味

誤解のないように言っておくと、私はDX至上主義ではありません。国内QSOにも同じだけの価値があります。ただ、6m bandの特性を考えれば、マルチホップEsで入感する超遠距離のDXは保護してしかるべきだと思っています。

理由は単純で、そのチャンスは突然やってきて、あっという間に消えるからです。国内向けの1ホップEsは比較的機会が多く、コンディションさえ上がれば楽しめます。北海道〜沖縄のような長距離パスは2ホップEs的な伝搬が関与することもありますが、それでも国内での交信機会は海外DXに比べれば圧倒的に多い。一方、マルチホップEsによるEU・中東・北米との交信チャンスは年に数回あるかどうか。コンディションが特別に恵まれれば、アフリカや中米まで届くこともあります。その数分間を皆で守ることが、結果として全員の楽しみを最大化します。それをバンド全体で活かしたい。 思いはそれだけです。

---

### 具体的な設定

WSJT-X(標準版 / Improved版 共通)

「Tx even/1st」のチェックを外す。



JTDX

「15/45」を選択する。



---

### 周波数の使い分け

50.313 MHz FT8標準周波数(国内・DX共用)
50.323 MHz 大陸間DX専用 — 国内・近隣諸国との交信には使用しない
50.303 MHz 国内通信用サブ周波数(標準周波数が混雑した場合)

50.323MHzは「最初からあった」周波数ではありません。数年かけて国際的に合意形成し、WSJT-X開発者のK1JT Joe氏をはじめEU各国の6m関連団体・著名DXerと連携して定着させたものです。大陸間の微弱な信号を守るために確保された専用スロットです。

標準周波数がDXをコールするJAで混雑してきたら、国内向けQSOは50.303MHzへ移動することで、お互いのチャンスを守ることができます。 またFT8が混雑してきた時、ぜひ 50.318MHzのFT4を覗いてみてください。そこそこ局がいて結構スムースにQSOができます。

---

### 例外と現実——柔軟性も大切

「JAはCQは2nd/奇数秒」は原則であり、絶対ルールではありません実際の伝搬は複雑で、例外が発生することがあります。

米国内でも東海岸と西海岸で送信タイミングが分かれて運用されています。そこへ突然JAやAsiaとのパスがオープンした場合、それまでの流れのまま、Asia側が偶数になることがあります。

さらに複雑な状況もあります。米国とEUが同時にオープンしている場合、EUは常に偶数(1st)で送信しています。この場合、米国は奇数(2nd)を使う。そこへ同時に米国からAsiaへのパスがオープンすると、Asiaも偶数になる——EUと同じタイミングです。

こういう状況で原則を頑なに守ろうとすると、かえって混乱します。その時はもうどうしようもない。 流れに乗って臨機応変に対応するしかありません。

大切なのは「原則を知った上で、状況を読む」ことです。原則を知らずに偶数で出し続けることと、状況を判断した上で偶数を選ぶことは、まったく意味が違います。

---

### まとめ

- CQは原則 2nd / ODD(奇数秒)/ 15:45 で出す
- 50.323MHz は大陸間DX専用、国内QSOには使わない
- 50.313MHzが混雑したら国内QSOは 50.303MHz へ

一人ひとりの小さな協力が、超遠距離DXとのQSOを日本全体で最大化します。今シーズンも皆さんが素晴らしいDXと繋がれることを願っています。

追記 もちろん奇数でCQを出している局をコールする時に自分が偶数側になるのは言うまでもありません。CQを出す時にご注意くださいというお話でした