WSJT-X improved 3.1、かなりお勧めです。📡2026年05月16日 09時28分12秒

WSJT-X improved 3.1、かなりお勧めです。 私の実感では、デコード性能はすでに JTDX 2.2.159 と同等、場合によってはそれ以上と感じています。 FT8は、デコードできてなんぼの世界です。 デコードできなければ、そもそもQSOはできません。 見えなかった信号が見える。 拾えなかった局が拾える。 これはFT8運用ではとても大きいです。 デコード性能については、こちらの記事にまとめています。 asahi-net.or.jp/~vj5y-tkur/ft8 WSJT-X improved 3.1 は、20260228版からさらに進化し、現在は20260418版が公開されています。 さらに 20260516版もテスト版として出ており、開発は継続中です。 こちらには 20260228版と20260418版がありますが、今から使うなら 20260418版をお勧めします。 sourceforge.net/projects/wsjt- 20260516テスト版を試したい方は、こちらからダウンロードできます。 QMAP v0.7 関連のテスト版です。 sourceforge.net/projects/wsjt- 公開されている WSJT-X improved 3.1 がここまで進化している今、ベータテスター以外には非公開の JTDX rc版を無理に追いかけたり、こっそり使ったりする必要性は、少なくとも私には感じられません。 JTDX のUIに馴染みがある方は、まず AL_PLUS版を選ぶと入りやすいと思います。 最初は「少し使いづらいかな?」と感じるかもしれません。 でも、それはたいてい慣れの問題です。 使っているうちに、違和感はすぐ過去のものになります。 古いバージョンを使い続けている方も、ぜひ WSJT-X improved 3.1 へのアップデートを検討してみてください。 なお、私は現在、JTDX の AutoSeq や Wanted 機能に近い使い勝手を WSJT-X 3.1 improved 上で実現する JP1LRT版を作成中です。 まだ限定テスト段階ですが、かなり良いところまで来ています。 そのうち皆さんにもお試しいただけると思います。 どうぞお楽しみに。


より良いリグが欲しい、でも動けない — ICOM⇔YAESU の壁について2026年05月08日 08時00分19秒

Sherwood の数字は誘惑する

Rob Sherwood の Receiver Test Data を眺めていると、ある数字の組み合わせに目が止まる。

私の現用機 IC-7300 の Narrow Spaced Dynamic Range は 97dB。それに対して YAESU FTdx10 と FT-710 は 107dB。10dB の差が、第三者測定の数字としてそこにある。

ここで技術的に正確に書いておきたい。Narrow Spaced DR は「強い近接信号が存在するときに、受信機が IMD で潰れずに済む耐性」、つまり受信機の "頭の高さ" を示す指標である。「信号強度で 10 倍の差が聞こえる」という素朴な解釈は誤りだ。実運用でこの余裕が使い切られる場面は限定的で、多くの状況では大気雑音や人工雑音の方が支配的になり、DR の差は体感されない。中波 DX のような大電力局がひしめく過酷な環境ですら、ICOM 機で十分戦えるという経験者の声もある。

さらに踏み込むと、Sherwood の測定そのものがダイレクトサンプリング SDR 機への適用において方法論的な課題を抱えているという指摘がある。SSG(信号発生器)から ADC へ直接入力する測定条件下では、入力レベル上昇に伴って波形立ち上がりが急峻化し、サンプリングビット刻みを 2〜3 段飛びで抜ける現象が起きる。これが量子化雑音にスパイクとして混入し、擬似ノイズとして観測される。サンプリングと信号の微妙なタイミング依存で結果が安定しないため、Sherwood 自身も計測値の不安定性を認めているとされる。実運用ではアンテナからの外来ノイズや他信号が自然なディザリング効果として働き、この現象は原理的にほぼ起きない。つまり Sherwood の数値はディザリング条件下のワースト値であり、ダイレクトサンプリング SDR 機の実運用性能を必ずしも反映しない。ヘテロダイン機では原理的に発生しない現象であり、アーキテクチャの異なる機種を Sherwood の同一指標で単純比較することには、原理的な注意が必要である。

それでも、この 10dB は誘惑する。FTdx10 100W が実勢価格 ¥158,400 から手に入る今、「Sherwood トップグループの数字を持つリグ」を IC-7300 と大差ない金額で買える時代である。コンテストで隣接強局に押し潰された経験のある人なら、「あと 10dB の余裕があれば」という思いを一度は抱いたことがあるはず。スペックは、実効値の差以上に人を惹きつける

数字だけ見れば、検討に値する買い物に見える。

でも、動けない。

なぜか。


見えないコスト — エコシステム移行費

リグ単体の比較表には絶対に載らないコストがある。「メーカー越境のコスト」だ。

私の例で具体的に書こう。

私のシャックでは IC-7300 の ACC 端子から 13.8V と SEND 信号を一本のケーブルで取り出し、6m 用プリアンプに供給している。これは ICOM 機の伝統的な設計で、IC-7600 でも同じ ACC 端子から同じ信号が取れる。長年積み上げてきた、安定した運用構成だ。

ところが YAESU FTdx10 は事情が違う。背面に TX GND(RCA)はあるが、ICOM ACC のような 13.8V 給電ピンは持たない。プリアンプ給電は別経路で安定化電源から分岐する必要がある。SEND 信号も RCA から取り直す。

つまり、リグを買い替えた瞬間、6m の中核装備であるプリアンプの給電・制御系統を全面再配線することになる。

「単なる配線でしょ?」と思うかもしれない。だが SEND タイミングはリグごとに微妙に違う。ミスれば送信時にプリアンプにフルパワーが突き刺さり、一瞬でファイナル昇天である。オシロで実測しながら慎重に組まないといけない。

これは私の例だが、似た話は他にも山ほどある。

越境で発生する隠れコスト一覧

  • ACC 端子:ピン配置・信号仕様が異なる
  • CAT 制御:ICOM は CI-V、YAESU は独自プロトコル
  • マイクコネクタ:8ピン同士でもピン配置が違う
  • 外部チューナー連動:バンドデータ電圧仕様が異なる
  • ロギングソフト設定:全リグエントリ書き換え
  • メモリ管理ツール:リグ専用、流用不可
  • キーパッド・FH-2 等:メーカー専用
  • マニュアル理解:用語・体系から学び直し

金銭的には、ケーブル・コネクタ・場合によっては T/R シーケンサで数千円〜数万円。たいした額ではない。

問題はそこじゃない。

三層のコスト構造

メーカー越境のコストは三層で発生する。

第1層:金銭コスト — 数千円〜数万円。リグ本体価格の 5〜10%。
第2層:時間コスト — 配線・設定・動作確認で週末数回分。実測・調整含めて 10〜20 時間。
第3層:リスクコスト — 配線ミス、信号タイミング差、誤動作によるハードウェア損傷の可能性。

そして見落とされがちな第4層がある

第4層:身体に染みついた操作感

四半世紀、ICOM を使っていると、私の手は IC のメニュー体系を覚えている。AGC ノブの位置、フィルタ切替の手順、メモリ呼出のキー操作。これらは脳ではなく指が記憶している。

YAESU に乗り換えると、この身体記憶が一瞬で無効になる。コンテスト中の一瞬の判断、パイルアップ中の混信処理、すべてが「考えながらの操作」に戻る。慣れるまでの数か月間、運用効率は確実に落ちる。

これは右ハンドル車に乗っていた人が左ハンドル車に乗り換えるのに似ている。技術的には運転できる。でも、無意識でできていたことを、しばらく意識的にやらないといけない。

この第4層こそが、メーカー越境の最大のハードルだと私は思う。スペック表の差が実運用で限定的なら、なおのこと、この身体記憶を捨てる合理性は薄い。

業界構造としての「囲い込み」

ここで一歩引いて見ると、これは個人の問題ではなく、産業構造の問題だと気づく。

ICOM は ACC 端子互換性を長年維持してきた。これは「ユーザー親切」の側面と同時に、「離脱コストを高く維持する戦略」でもある。一台買い替えるたびに、過去のアクセサリ投資がそのまま次のリグでも使える。だから ICOM ユーザーは ICOM を買い続ける。

YAESU 側も同じ構造で、FTdx101 → FTdx10 → FT-710 と購入してきたユーザーは、周辺機器をほぼ流用できる。だから YAESU ユーザーは YAESU を買い続ける。

これは Apple のエコシステムや、カメラの Canon vs Nikon と同じ構造だ。「囲い込みは、ユーザーの便宜と表裏一体で機能する」

ハム業界のユニークな点は、この囲い込みが数十年スパンで機能することだ。スマホは 2〜3 年で買い替えるが、リグは 20 年使う。アクセサリも、AC アダプタやプリアンプは 30 年使う人もいる。だから一度ある陣営に属すると、簡単には抜け出せない。

真のリグ価格 = 表示価格 × エコシステム係数

私が思う「越境購入の真のコスト」を式にするとこうなる。

真のコスト ≒ リグ表示価格 × 1.3〜1.5(メーカー越境時)

FTdx10 100W が ¥158,400 だとしても、ICOM ユーザーが買うときの「実質コスト」は ¥200,000〜¥240,000 と見るのが現実的だ。配線材料費、時間コスト、リスクコスト、運用効率低下のすべてを織り込めば、それくらいになる。

逆に、YAESU 内で FTdx101D → FTdx10 への買い替えなら、エコシステム係数は 1.0 に近い。表示価格そのままが実質コストだ。

この差が、性能比較表からは絶対に読み取れない。そして比較表の数字そのものが、必ずしも実運用の差を保証しないことを考え合わせると、越境判断はますます慎重にならざるを得ない。

ではどうするか

選択肢は三つある。

選択肢1:エコシステム内に留まる — スペック上の性能向上は限定的でも、移行コストはゼロに近い。複数メーカー機種を並行使用する経験者の観察によれば、IC-7851/K3S/FTDX10/FT-710/FTDX5000/TS-890S といった上位機間の実運用性能差はほぼないとされる。実運用での体感差が小さいなら、なおさら合理的な選択。ICOM ユーザーなら IC-7610 や IC-7851 へのアップグレードパス。慣れた操作系、確実な周辺機器流用。

選択肢2:越境を覚悟して移行する — Sherwood トップグループの数値を取りに行く。ただし三層〜四層のコストを直視する必要がある。週末を数回潰す覚悟と、しばらくの運用効率低下を許容する精神的余裕が要る。「数値が変わっても運用は変わらないかもしれない」という冷静な認識も持っておく。

選択肢3:併存運用 — 既存システムは温存し、新ブランドは限定用途で導入。例えば「6m 専用機として FTdx10 を導入し、HF はICOM継続」。ただしこれもプリアンプが越境バンドにあると成立しないなど、運用構成によっては実現困難。

正解はない。自分の運用形態と、移行コストの見積もり次第だ。

メーカーへの注文 — 宗教のハードルを超えてくれ

ここまではユーザー側の話だった。だが、視点を一段上げて言いたいことがある。

ICOM と YAESU は、もっとライバル意識をむき出しにして性能を追うべきだ。

私はメーカー越境のハードルを「合理的な敬意」と書いた。しかしその裏返しは、両メーカーが現状の囲い込みに安住しているということでもある。

考えてみてほしい。Sherwood Engineering の Receiver Test Data において、5 年以上前に発売された FTdx10 が今もトップグループに居座り続けている。これは YAESU の設計が優秀である証であると同時に、「5 年経っても本気で挑戦してくる対抗馬がいない」という業界の停滞でもある。

2026 年に登場した IC-7300Mk2 では、Sherwood の Narrow Spaced DR が 87〜89dB と、初代 IC-7300 の 94〜97dB を下回るという結果が公表されている。ただしこの数値については、前述のダイレクトサンプリング SDR 機固有の測定方法論上の問題に起因する現象である可能性が高く、実機性能の劣化を意味するとは限らない。実機経験豊富な OM 諸氏の観察を踏まえれば、IC-7300Mk2 が実際に初代より劣ると判断する根拠は乏しい。

ただ、新機能の追加(USB-C、HDMI、LAN、CW デコーダ、APF)が素晴らしい一方で、第三者測定で前モデル比の明確な向上を示しきれない開発思想には、メーカーがエコシステム内買い替えを織り込んでいる雰囲気を感じる。「うちのユーザーは結局うちで買う」という前提に立っていないか。

性能だけでなく、UI も激しい競争軸として欲しい。八重洲機は性能良好だが UI が弱いという評価が定着しており、つまみの数比例で FTDX101 > FTDX10 > FT-710 という声まで聞かれる。FT-710 は FT8 等で PC コントロール前提の設計と見れば筋は通るが、リグ単体で操作するときの使い勝手はやはり大事だ。ハードウェア性能の競争と、ユーザー体験を左右する UI の競争。両輪で各社が殴り合えば、業界全体が前進する。

私が両メーカーに望むのは、スペック表の数字ではなく、実機で誰もが体感できる性能の飛躍と、操作のしやすさで思わず手が伸びる UI の進化である。ユーザーの「宗教のハードル」を強引にぶち壊すには、それしかない。

ICOM ユーザーが実機を触って「これは…YAESU に乗り換えるべきか?」と本気で悩む製品。YAESU ユーザーが操作して「ICOM の新作は、エコシステム再構築のコストを払ってでも欲しい」と思う製品。そういう製品が出てきて初めて、業界全体が前進する。

スマートフォン業界では、iPhone と Android の覇権争いが互いを進化させた。GPU 業界では NVIDIA と AMD と Intel の三つ巴がユーザーに恩恵をもたらしてきた。ハム業界も、同じレベルの競争を見たい

互いの牙城を尊重する紳士協定のような現状は、ユーザーには不利益でしかない。ICOM は YAESU の縄張りを荒らしに行くべきだし、YAESU は ICOM の城を崩しに行くべきだ。Kenwood も、Elecraft も、Flex も含めて、もっと激しく性能を競ってほしい。

「宗教のハードルを超えてでも、こいつが欲しい」とユーザーに言わせる体感の差を、ぜひ作ってほしい。それがあれば、私たちは喜んで配線をやり直し、メニュー体系を学び直し、四半世紀の指癖を捨てる覚悟をする。

ハムは、本物の性能には敬意を払う種族である。

メーカーへの具体的な提案 — アダプターという解決策

性能で殴り合うのと並行して、もう一つメーカーに提案したいことがある。

「越境を容易にする純正アダプター」を商品化してほしい。

例えば、YAESU が ICOM ユーザーを取り込みたいなら、こういう純正アクセサリを売ればいい:

  • ACC 変換ハーネス:ICOM ACC(13ピン DIN)→ YAESU FTdx10 制御端子。13.8V と SEND を既存配線のまま流用可能
  • マイクアダプター:ICOM 8ピンマイク → YAESU マイクコネクタ変換
  • CAT ブリッジ:CI-V ↔ YAESU CAT プロトコル変換、既存ロギングソフトの設定維持
  • バンドデータ変換:ICOM バンド電圧 → YAESU バンドデータ、外部チューナー連動継続

ICOM 側も同じだ。YAESU ユーザーを取り込みたいなら、YAESU の周辺機器を ICOM 機に繋ぐアダプターを純正で出せばいい。

「そんなことをしたら囲い込みが崩れる」と思うかもしれない。だが視点を変えてほしい。囲い込みが崩れて困るのは、自社のユーザーが他社に流出する場合だけだ。逆に、相手陣営のユーザーを取り込みたいなら、彼らの囲い込みを緩める方向に動くのは戦略的に正しい。

想像してみてほしい。FTdx10 を検討している ICOM ユーザーが、店頭でこう説明されたら:

「純正 ACC アダプターハーネスがあります。既存のプリアンプ、チューナー連動、マイクがすべてそのまま使えます

この瞬間、移行コストの第1層・第2層・第3層が一気に消える。多くの ICOM ユーザーは、ここで YAESU 購入を決断するだろう。

これは既存 YAESU ユーザーに何の不利益もない。純粋に他社陣営から新規顧客を切り崩す施策である。価格は ¥10,000〜¥20,000 程度のアクセサリで構わない。本体価格 ¥158,400 に対する追加負担は微々たるもの。むしろ「これで安心して移行できる」という心理的ハードルの低下効果は計り知れない。

売上は確実に伸びる。越境の物理的・技術的ハードルが下がれば、あとは純粋な性能勝負になる。そしてここで初めて、Sherwood の数字も、実機の体感も、本当の意味で武器として機能し始める。

両メーカーには、製品開発リソースの一部を「越境促進アクセサリ」に振り向けてほしい。これは囲い込みを緩めるリスクではなく、相手陣営のユーザーを切り崩す攻撃手段である。守りの戦略ではなく、攻めの戦略として考えるべきだ。

ハードウェア互換性アダプターは、結局のところ業界全体のパイを広げる。固定客の奪い合いではなく、買い替え意欲そのものを刺激することになる。長期的に、両メーカーにとっても、ユーザーにとっても、利益になる構造だ。

「性能で殴る」と「アダプターで橋を架ける」。この両輪が揃ったとき、ハム業界は本当の意味で動き出す。

結論

「より良いリグが欲しい」という気持ちと、「動けない」という現実の間にあるのは、決して怠惰でも保守性でもない。それは、これまで積み上げてきたエコシステムへの合理的な敬意である。

新しいリグを買うとき、メーカーが同じなら表示価格を、メーカーが違うなら表示価格 × 1.3〜1.5 を見積もる。これが私の最近の考え方だ。

そして、Sherwood の数字を眺めながら、しばらく自分のシャックを見回す。あの 6m プリアンプ、あの ACC ケーブル、あの慣れ切ったメニュー画面。これらすべてを「越境コスト」として勘定に入れたとき、買い替えという行為の重みが初めて見えてくる。リグ選びは、単体の数字を比べる作業ではなく、アンテナ、受信環境、周辺機器、操作感まで含めたシャック全体の総合力をどう設計するか、という問題でもある

スペック表の数字は誘惑する。だがその数字が実運用でどこまで効くかは、数字だけからは読めない。実効性の不確かな優位は、四半世紀かけて築いたエコシステムの引力に勝てるか。これは、すべてのハムが買い替え時に直面する、見えない方程式である。

WSJT-X Improved 3.1.0 260418 was released2026年04月18日 21時35分02秒

WSJT-X Improved 3.1.0 260418 was released today — and this is not just "another new build." This is a substantial update. 📡

It helps to look at this in two layers. 👇

First, what the 3.1 series brings as a whole:
New FT2 mode
Non-standard / compound callsign QSOs for all 77-bit modes
U.S. state support for Worked All States 🇺🇸
a7 decoding / sub-sample DT refinement / 4th pass / baseline optimization
itone added to UDP status message
Hamlib 5 series support

These are major pillars.

On top of that, the 260418 update specifically adds:
🔹 Improved FT4/FT2 decoding
🔹 Better FT2 decoder timing
🔹 Enhanced U.S. state support
🔹 8 band hopping frequencies switchable between FT8 / FT2
🔹 Option to clear Band Activity window on mode change
🔹 WSPR spotting to PSK Reporter
🔹 Echo mode Dgrd display
🔹 Cloudlog/Wavelog Test API fix
🔹 Hamlib 4.7.1 update

Quite a lot packed in. 🛠️

Now here is where it gets interesting.

I had a look at the source as well, and my impression is:
It is NOT simply a case of "Qt6 being a completely different beast."

The bigger step is actually:
Old (Qt5 260228) → New Qt5 (clean 260418)

The representative files I checked all show differences here, and the scope of changes is quite broad.

Meanwhile, the delta from New Qt5 → New Qt6 is concentrated mainly around:
- Configuration
- mainwindow
- displaytext
- WorkedBefore

...and the core decoder files are not as different as I expected.

So my overall read is:
The 260418 generation itself is a big leap forward,
and Qt6 sits on top of that as a port plus surrounding differences. 📘

So all in all, WSJT-X Improved 3.1.0 260418 — covering:
FT2
Compound / non-standard callsign QSOs
U.S. state support
a7 / 4th pass / baseline optimization
WSPR / Echo / UDP / band hopping improvements

— is a much deeper update than it might appear on the surface. 🚀

This is not just "a new build came out."
This version makes the direction of the 3.1 series quite clear.



WSJT-X Improved 3.1.0 260418 リリース2026年04月18日 21時32分45秒

今日公開された WSJT-X Improved 3.1.0 260418、
これは「ちょっと新しいビルドが出た」という話ではなく、かなり大きい更新だと思います。📡
今回の話は、実は 2段階 で見ると分かりやすいです。👇

まず 3.1系全体 として入っているもの。
ここには

新しい FT2 モード
77-bit系での non-standard / compound callsign 同士のQSO対応
Worked All States を意識した US state 対応 🇺🇸
a7 decoding / sub-sample DT refinement / 4th pass / baseline最適化
itone を UDP status に追加
Hamlib 5 series 対応
など、かなり大きな柱があります。

そのうえで、今回の 260418 更新 ではさらに
🔹 FT4/FT2 の decoding 改良
🔹 FT2 decoder timing 改善
🔹 US state 対応の強化
🔹 8つの band hopping 周波数を FT8 / FT2 で切替可能
🔹 Band Activity を mode change 時に消す オプション
🔹 WSPR → PSK Reporter
🔹 Echo mode の Dgrd 表示
🔹 Cloudlog/Wavelog Test API 修正
🔹 Hamlib 4.7.1 更新
……と、かなり内容が濃いです。🛠️
で、ここからが面白いところ。
少しソースも追ってみたのですが、印象としては
「Qt6版だけが別物」ではない
です。👀
むしろ大きいのは
旧版(Qt5 260228) → 新Qt5(clean 260418) の段階。
こちらで見た代表ファイル群は全部差分ありで、更新範囲はかなり広い。

一方で
新Qt5 → 新Qt6 の差は、主に

Configuration
mainwindow
displaytext
WorkedBefore
周辺に集まっていて、
デコーダ主要部は思ったほど別物ではありませんでした。
つまり体感としては、
まず 260418 世代そのものが大きく進化していて、
Qt6 はその上に乗る移植+周辺差分
という見方が、いちばんしっくり来ます。📘

なので今回の 3.1.0 260418 は、

FT2
compound / non-standard callsign QSO
US state
a7 / 4th pass / baseline 最適化
WSPR / Echo / UDP / band hopping 周辺の改善
まで含めて、
思っていた以上に中身が濃い更新だと思います。🚀

単なる「新しいビルドが出た」ではなく、
3.1系の方向性がかなりはっきり見える版ですね。





WSJT-X 3.1 improved のFT8デコーダ設定を読み解く2026年03月24日 23時55分53秒

# WSJT-X 3.1 improved のFT8デコーダ設定を読み解く  

## ― 「デコードスタート」は何をしているのか。そして、いま本気で最適化を考える意味

-------------------------------
ここのブログはフォーマットがイマイチなので、独立ページを作りました
https://www.asahi-net.or.jp/~vj5y-tkur/ft8/wsjtx_31improved_article_ja.html

-------------------------------

是非上記独立ページをご覧ください。

FT8/FT4用ソフトウェアの選択2026年03月17日 16時10分07秒

FT8/FT4用ソフトウェアの選択について、少し書かせてください。 WSJT-X 3.0.0-rc1、そしてWSJT-X Improved 3.0/3.1が登場して以来、デコード率という点ではJTDXを選ぶ理由はなくなりました。JTDXのテクノロジーが取り入れられているため、デコード率は同等です。waiting機能に関してはむしろWSJT-X Improved 3.1の方が上で、対応モードも多く、コンテストモードも搭載しています。 私自身がJTDXを使い続けているのは、GUIの使いやすさとベータテスターとしての立場があるからです。 ここで一つお伝えしたいことがあります。 WSJT-XのRC版は広く一般公開されてフィードバックを集める仕組みですが、JTDXのRC版は開発チームとベータテスターの間だけでやり取りされる、完全非公開のバージョンです。もしJTDXのRC版をお使いの方で、この事実をご存知なかった方がいれば、ぜひ知っておいていただければと思います。 それを知った上でどうするかはご本人の判断ですが、WSJT-X Improved 3.1はデコード率も同等、機能的にも充実していて、公式サポートもあります。後ろめたさを感じることなく使える選択肢として、強くお勧めします。もはや隠れてJTDXのRC版を使う理由がありません。



PSKR の Statistics には誰がどのバージョンのソフトウェアを使用しているかが表示されます。 当然ですが私は誰がベータテスターズなのかそうでないかを把握していますし、開発チームも把握しています。



It Wasn't 3 Strikes and Out — Clearing Up the WSJT-X F/H Mode and MSHV Misconceptions —2026年03月08日 08時28分31秒

Introduction

In 2026, the amateur radio world was shaken.

3Y0K — Bouvet Island.

Located at the southern tip of Africa, surrounded by the perpetually stormy South Atlantic, this remote island has long been regarded as one of the most wanted DXCC entities in the world. Numerous expeditions have been attempted over the years, only to be thwarted by violent weather and failed landings. Time and again, the dream slipped away.

This time, the signals finally came through.

Amateur radio operators around the world flooded the pileup. FT8 waterfalls were wall-to-wall with signals, social media overflowed with reports, and ChronoGPS downloads spiked dramatically (personal note, sorry).

While participating in the pileup myself, I kept an eye on social media. Two opinions kept appearing over and over:

"I called below 1000Hz and got a callback. So it must be MSHV."

"It should have been 3 strikes and out, but I got a response anyway. So it must be MSHV."

Both conclusions landed on "therefore MSHV" — which I find interesting. MSHV is excellent software that enables multi-stream FT8/FT4 operation, but it's not the explanation for either of these observations.

And I'll be honest: regarding the second point — the "3 strikes" issue — I myself had the wrong understanding until very recently.

Let me go through this carefully.


F/H or MSHV? Let's establish the basics first

Before diving into the debate, let's confirm the premise.

The official 3Y0K website stated they were using F/H (Fox & Hound) mode. That's the simplest and most authoritative piece of evidence. The expedition team themselves said "we're using F/H" — that should be our starting point.

So where does the "it looked like MSHV" impression come from? To understand that, we need to know exactly how F/H mode works.


A quick refresher on F/H mode

WSJT-X's Fox & Hound mode was developed by K1JT (Joe Taylor) in 2018, designed to allow DXpedition stations (Fox) to complete QSOs at very high rates with multiple stations simultaneously.

The frequency arrangement works like this:

Fox transmits at audio frequencies between 300 and 900 Hz. When transmitting multiple simultaneous signals, they are spaced at 60 Hz intervals.

Hounds make their initial calls anywhere in the range 1000 – 4000 Hz.

This separation is the foundation of F/H mode.

Two critical points about Fox's behavior:

1. Fox decodes signals below 1000Hz but does not respond to them.
2. Fox only responds to Hounds calling with Tx1 (including grid square).

"Does not decode" and "ignores" are completely different things. This distinction becomes important shortly.


Misconception #1: "I called below 1000Hz and got a callback! → So it must be MSHV!"

This is the most common misconception I saw on social media.

Let's break it down.

In F/H mode, Fox does decode signals below 1000Hz. It just doesn't respond to them. If you look at Fox's waterfall display, Hound signals below 1000Hz are highlighted in red — Fox can see them, it's just choosing to ignore them. That's the design.

So how do we explain "I called below 1000Hz and still got a callback"?

The answer is the queue.

Fox maintains a queue of Hound callsigns decoded in recent sequences. If you called above 1000Hz with Tx1 (grid square included) even once in the past few sequences, your callsign remains in Fox's queue. Even if you subsequently drifted below 1000Hz, Fox can still select you from the queue and call you back.

"I called below 1000Hz and got a response" does NOT equal "therefore MSHV." It most likely means "I had previously called correctly above 1000Hz, and my callsign was still in the queue."

Think back carefully from the very beginning. Are you absolutely certain you never called above 1000Hz even once? 😅

In most cases, I suspect the memory of "I only called below 1000Hz" is inaccurate, and there was at least one transmission above 1000Hz somewhere along the way.

There's another possible source of confusion worth mentioning. In Hound mode, WSJT-X has automatic frequency control. After Fox calls you, Hound automatically moves to near Fox's DF to send R+report — which may place it below 1000Hz. This is a mid-QSO frequency change, not an initial call below 1000Hz. The memory of "I was below 1000Hz" may be conflating this automatic move with the initial call.


Misconception #2: "It should have been 3 strikes and out, but I got a response! → So it must be MSHV!"

This is the heart of today's post. And as I mentioned at the beginning, I had the same misconception myself.

The official F/H mode User Guide written by K1JT (2018) states the following about Fox's behavior:

"We use a '3 strikes and you're out' rule. Fox will call a specific Hound up to 3 times, waiting for an 'R+rpt' response. If a Hound repeatedly sends an 'R+rpt' message, Fox will send RR73 up to 3 times. Finally, the total timespan of an attempted QSO is limited to 3 minutes. When any of these timeouts is exceeded, the QSO is aborted."

Reading this, most people concluded: 3 failures means game over, start over from scratch. I did too.

"3 strikes and you're out" — it's baseball. Clear, intuitive, easy to remember.

But then—


Read the release notes and the world changes

While discussing this on Facebook, I received a tip from Michael Flensted Möller (Top Contributor): "Read the release notes."

In the WSJT-X 2.6.0-rc5 release notes (November 29, 2022), there is this entry:

"Fox now responds for another two cycles to stations whose report was not received, increasing the success rate for a difficult QSO."

Let me spell out what this means:

1. Fox calls a Hound up to 3 times, waiting for R+report
2. After 3 failures, Fox drops that Hound from the queue (3 strikes)
3. But for 2 more cycles after that, Fox still listens for that Hound's R+report
4. If R+report arrives during that window, Fox still sends RR73

In other words, there are effectively 5 chances.

It was NOT 3 strikes and out. 😄

I was genuinely surprised when I read this. It's not in the manual. It's only in the release notes. And of course it's not in the 2018 manual — this was a change made in 2022.

"Got a response after what should have been 3 strikes" is not because of MSHV. It's because of the behavior change introduced in WSJT-X 2.6.0-rc5.

The intent behind this change is clear: to increase the success rate for difficult QSOs. Propagation fluctuations and momentary interference can cause you to miss the 3-cycle window. Adding 2 more cycles as a buffer is a thoughtful design decision — very much in the spirit of K1JT's careful engineering.


The manual alone is not enough

What this whole experience reinforced for me is that thinking you understand something just because you read the manual can be dangerous.

WSJT-X has been continuously refined since the introduction of F/H mode in 2018. The manual is a snapshot of that point in time. To accurately understand current behavior, you need to follow the release notes as well.

Yes, the WSJT-X release notes are long. Keeping up with every version is genuinely tedious. But there are discoveries waiting in there — the accumulated history of careful improvements by K1JT and the development team. Things like the SuperFox mode introduction (2.7.0-rc5), improvements for handling MSHV multi-stream signals in Hound mode (2.7.0-rc1), and Fox queue management enhancements (2.6.0-rc5) — all of these directly affect real-world operation.

When something seems off, or the software behaves differently than you remember, the release notes often have the answer.

Think of the manual as the entrance, and the release notes as the map to where you are now.


A note on MSHV

I want to be clear: I'm not criticizing MSHV. It's excellent software developed by LZ2HV (Christo), enabling multi-stream FT8/FT4 QSOs with multiple stations simultaneously. Many DXpeditions use it effectively.

When calling a DX station running MSHV multi-stream, Hound operators need no special settings. It's the same as normal FT8 operation. No frequency restrictions. You can call with a grid square, or start with R+report — whatever works. MSHV's multi-stream capability is entirely on the host side; it's transparent to the calling station.

The confusion between F/H mode and MSHV matters precisely because of this difference: F/H mode places real constraints on the calling side (above 1000Hz, Tx1 with grid). MSHV does not. Understanding which mode is in use changes how you should operate.


Closing thoughts: the relationship between experience and understanding

Personal experience matters. "This worked" and "this didn't work" — the lessons from actual operating are at the heart of what makes amateur radio enjoyable.

But it's worth pausing before jumping from experience to conclusion. The question "why did that happen?" deserves an answer, and the answers are often in the manual and release notes.

"Called below 1000Hz and got a callback" → don't conclude "therefore MSHV." Ask "why did I get a callback?" Knowing about the queue explains it within F/H mode.

"Should have been 3 strikes but got a response" → don't conclude "therefore MSHV." Check whether the release notes have something relevant. The answer was in 2.6.0-rc5.

Understanding how your software actually works makes the hobby more interesting. When things go right, you know why. When things go wrong, you know why. And that understanding also helps reduce QRM — operators who know that parking below 1000Hz causes problems for everyone are less likely to do it.

Amateur radio is a hobby built around technology. If you enjoy the technology, understanding what's happening under the hood is part of the fun.

Please read the release notes. 📖


Feel free to share. 



三振アウトではなかった 〜WSJT-X F/HモードのリリースノートとMSHV誤解の話〜2026年03月07日 23時14分17秒

はじめに

2026年、アマチュア無線界に激震が走りました。

ブーベ島、3Y0K。

アフリカ最南端、南極に近い絶海の孤島。常時荒れ狂う南大西洋の波に囲まれ、上陸すること自体が命がけのこの島は、アマチュア無線界において長年「世界で最も欲しいエンティティ」のひとつとして君臨し続けてきました。過去に何度かペディションが試みられ、そのたびに悪天候や上陸失敗で夢と消えてきた場所です。

そのブーベ島からの電波が、ついに飛んできた。

世界中のハムがパイルアップに殺到しました。FT8のウォーターフォールは信号で埋め尽くされ、SNSはリポートで溢れ、ChronoGPSのダウンロード数が跳ね上がりました(これは私事ですが)。

私もパイルアップに参加しながら、SNSをモニターしていました。そこで目についたのが、繰り返し登場する2つの意見でした。

「1000Hz以下で呼んだのにコールバックがあった。だからMSHVだ。」

「三振アウトのはずなのに応答があった。だからMSHVだ。」

どちらも結論が「だからMSHV」に着地しているのが興味深い。MSHVはマルチストリーム運用ができる優れたソフトウェアですが、今回の3Y0Kの動作を説明する理由としては、どちらも的外れだと思っています。

そして正直に告白すると、2つ目の「三振アウト」については、私自身もつい最近まで間違った理解をしていました。

今回はその話を、できるだけ丁寧に書いていきます。


F/HモードかMSHVか、まず前提を整理する

議論を始める前に、まず前提を確認しておきます。

3Y0Kの公式ホームページには、F/H(Fox & Hound)モード使用と明記されていました。これが一番シンプルかつ強力な根拠です。ペディションチームが自ら「F/Hを使う」と言っているのだから、まずそれを信じるべきでしょう。

では「動作がMSHVっぽかった」という感想はどこから来るのか。それを理解するためには、F/Hモードの動作原理を正確に知っておく必要があります。


F/Hモードの基本をおさらい

WSJT-XのF/H(Fox & Hound)モードは、2018年にK1JT(Joe Taylor)によって開発されました。DXペディション局(Fox)が同時に複数のQSOを高レートでこなすための専用モードです。

基本的な周波数の使い方はこうです。

FoxはDF 300〜900Hzの範囲で送信します。複数スロット同時送信の場合は60Hz間隔で並びます。

HoundはDF 1000〜4000Hzの範囲で呼びます。

この棲み分けが、F/Hモードの根幹です。

そしてFoxの動作で重要なのが以下の2点です。

  1. Foxは1000Hz以下の信号もデコードするが、応答しない。
  2. HoundはTx1(グリッドスクエア付き)で呼ばなければFoxは応答しない。

「デコードしない」ではなく「応答しない」というのが正確な表現です。この違いは後で重要になってきます。


誤解その1:「1000Hz以下で呼んだのにコールバックがあった!→だからMSHVだ!」

これはSNSで最もよく見かけた誤解です。

まず整理しましょう。

F/HモードのFoxは、1000Hz以下の信号もデコードはしています。ただ応答しないだけです。Foxのウォーターフォールを見ると、1000Hz以下のHoundの信号も赤くハイライトされて表示されています。見えているけど、無視している。それがF/Hモードのデザインです。

では「1000Hz以下で呼んだのにコールバックがあった」という体験はどう説明するのか。

答えはキャッシュにあります。

Foxのシステムは、過去数シーケンスでデコードしたHoundのコールサインを記憶しています。つまり、あなたが1000Hz以上でTx1(グリッドスクエア付き)で呼んでいたシーケンスがあれば、その情報はFoxのキャッシュに残っています。その後うっかり1000Hz以下に移動して呼んでいたとしても、キャッシュから選ばれてコールバックが来ることがある。

「1000Hz以下で呼んだのに応答があった」は「MSHVだから」ではなく、「以前1000Hz以上で正規に呼んでいたから」である可能性の方がずっと高い。

ここで一度、自分の運用を最初から振り返ってみてください。本当に一度も1000Hz以上でTx1で呼んでいませんでしたか?😅

多くの場合、「1000Hz以下でしか呼んでいない」という記憶は不正確で、実際にはどこかで1000Hz以上で呼んでいるのではないかと思います。

さらに言うと、WSJT-XのHoundモードには自動周波数制御があります。Foxから応答が来た後、Houndは自動的にFoxのDF近辺に移動してR+rptを送ります。このとき1000Hz以下に移動することがあります。しかしこれはシーケンスの途中での移動であり、最初のコールは1000Hz以上だったはずです。「1000Hz以下で呼んだ」という記憶は、このシーケンス途中の移動と混同されている可能性があります。

* ここで《キャッシュ》と書いているものは【Queue】の事ですが、読む方が理解しやすいように敢えて《キャッシュ》と記しています。


誤解その2:「三振アウトのはずなのに応答があった!→だからMSHVだ!」

ここが今回のブログの本題です。そして冒頭でも書いた通り、私自身もつい最近まで間違った理解をしていました。

K1JTが書いたF/Hモードの公式マニュアル(2018年)には、Fox側の動作としてこう書いてあります。

"We use a '3 strikes and you're out' rule. Fox will call a specific Hound up to 3 times, waiting for an 'R+rpt' response. If a Hound repeatedly sends an 'R+rpt' message, Fox will send RR73 up to 3 times. Finally, the total timespan of an attempted QSO is limited to 3 minutes. When any of these timeouts is exceeded, the QSO is aborted."

これを読んだ多くの人が「3回失敗したら終わり、最初から呼び直し」と理解しました。私もそうでした。

「三振アウト」という表現は野球のルールそのものですから、わかりやすい。3回ダメなら次のバッターに交代、という理解は自然です。

ところが——。


リリースノートを読むと世界が変わる

Facebookでこの話をしていたところ、Michael Flensted Möller氏(トップコントリビューター)から指摘を受けました。

「リリースノートを読んでみて」と。

WSJT-X 2.6.0-rc5(2022年11月29日)のリリースノートにこう書いてあります。

"Fox now responds for another two cycles to stations whose report was not received, increasing the success rate for a difficult QSO."

「Foxは、レポートを受信できなかった局に対してさらに2サイクル応答するようになりました。これにより難しいQSOの成功率が向上します。」

つまりこういうことです。

  1. Foxが3回コールバックしてもHoundのR+rptが届かない
  2. FoxはそのHoundをキューからドロップする(三振)
  3. しかしその後2サイクル、FoxはまだそのHoundのR+rptを待っている
  4. そのウィンドウの中でR+rptが届けばRR73が返ってくる

つまり実質5回のチャンスがあるわけです。

三振アウトではなかった。😄

私はこれを読んで正直驚きました。マニュアルには書いていない。リリースノートにしか書いていない。しかも2022年の変更だから、2018年のマニュアルに書いてないのは当然です。

「三振のはずなのに応答があった」はMSHVだからではなく、WSJT-X 2.6.0-rc5以降の仕様変更によるものだったわけです。

ちなみにこの変更の意図は明確で、「難しいQSOの成功率を上げる」ためです。プロパゲーションの変動や一時的な混信で3回のウィンドウを逃してしまうことがある。そのためのバッファとして2サイクルを追加した。K1JTたちの細かい配慮が感じられる変更です。


マニュアルだけでは足りない、という話

今回の件で改めて強く思ったのは、マニュアルを読んだだけで理解した気になるのは危ないということです。

WSJT-Xは2018年のF/Hモード導入以来、細かい改善を重ね続けています。マニュアルはその時点のスナップショットに過ぎません。現在の動作を正確に理解するには、リリースノートまで追いかける必要がある。

リリースノートは確かに長い。WSJT-X 2.7.0-rc5のリリースノートを全部読もうとすると、かなりの時間がかかります。でも読むと発見があります。

例えば今回の「5回チャンス」の話だけでなく、リリースノートには他にも興味深い変更が記録されています。SuperFoxモードの導入(2.7.0-rc5)、MSHVのマルチストリーム信号をHoundモードで正しく処理するための改善(2.7.0-rc1)、Fox向けのキュー管理の改善(2.6.0-rc5)など、実際の運用に直結する変更が多い。

「なんかうまくいかない」「なんか動作が変わった気がする」という時、リリースノートを読むと「あ、そういうことか」という答えが見つかることがあります。

マニュアルは入口で、リリースノートが現在地への地図だと思っています。


MSHVについて補足

MSHVを否定したいわけではありません。MSHVはLZ2HV(Christo)が開発した優れたソフトウェアで、マルチストリーム運用によって複数局と同時にFT8/FT4のQSOができます。実際に多くのDXペディションで使われています。

MSHVを使っているDX局を呼ぶ時、Hound側は特別な設定は不要です。普通にFT8でQSOするのと同じです。DFの制限もありません。グリッドスクエア付きで呼んでもいいし、最初からR+rptで呼んでもいい。MSHVのマルチストリームはHost側の話であって、呼ぶ側には透過的です。

F/HモードとMSHVを混同するのは、この「呼ぶ側に制約があるかどうか」という点で大きな違いを生みます。F/Hモードには1000Hz以上でTx1で呼ぶという明確な制約がある。MSHVにはそれがない。この違いを理解した上で運用することが大切です。


最後に:体験談と原理理解の関係

体験談は大切です。「こうしたらうまくいった」「こうしたらうまくいかなかった」という実経験は、アマチュア無線の楽しさの核心だと思っています。

ただ、体験から結論を導く前に一歩立ち止まることも大切です。「なぜそうなったのか」を考える手がかりは、マニュアルとリリースノートの中にある。

「1000Hz以下で呼んだのにコールバックがあった」→「だからMSHVだ」ではなく、「なぜコールバックがあったのか」を考える。キャッシュの存在を知っていれば、F/Hモードでも説明がつく。

「三振アウトのはずなのに応答があった」→「だからMSHVだ」ではなく、「リリースノートに何か書いてないか」を調べる。2.6.0-rc5に答えがあった。

使っているソフトウェアの動作原理を正しく理解した上で運用する方が、うまくいった時もうまくいかなかった時も、ちゃんと理由がわかって面白い。そしてその理解が、周囲への迷惑を減らすことにもつながります。1000Hz以下に居座り続けるQRMも、正しい知識があれば防げる話ですから。

アマチュア無線は技術を楽しむ趣味です。技術を楽しむなら、その技術の中身を知るのも楽しみのうちだと思っています。

リリースノート、ぜひ読んでみてください。📖


ALL.TXT Is Not a Log. Until It's All You Have.2026年03月05日 09時02分37秒

# Recovering Logs, Reclaiming Memories — Releasing ALLTXT2ADIF

Someone reached out to me once with a message that stuck with me.

*"My PC crashed. Lost everything. wsjtx_log.adi, gone. wsjtx.log, gone. All I have left is ALL.TXT. Is there anything I can do?"*

If you operate FT8 or FT4, you know what ALL.TXT is. That quiet file WSJT-X and JTDX keep writing to in the background. A raw decode history. Not an official log.

**ALL.TXT is not a log. But when you lose your log, it becomes the last piece of evidence you have.**

ALLTXT2ADIF was built to reconstruct QSOs from that evidence — and export them as a standard ADIF file.

This situation is more common than most operators realize.

---

## Before Writing a Single Line of Code

The first decision I made wasn't about code. It was about what *not* to build.

A tool that blindly converts ALL.TXT to ADIF is technically straightforward. But it would be wrong.

ALL.TXT is a record of *received signals*, not *completed QSOs*. Third-party decodes are in there. Multiple QSOs overlap on the same frequency. RR73 gets sent multiple times — that's just normal FT8. In a pileup, you can't always tell which station a 73 was even intended for.

Anyone who's spent serious time operating FT8 knows: careless recovery means a log full of errors.

So from the very beginning, this tool had one guiding principle:

**Every recovered QSO must be explainable. Not just output — explained.**

---

## The Night We Argued About Philosophy Instead of Code

The most memorable part of this project wasn't solving a technical problem.

It was a night when I told the AIs:

**"Stop. Don't write any code. I want to talk about approach."**

Where exactly does *strict* end and *lenient* begin? Under what conditions does an RR73 count as a completed QSO? What does *high confidence* actually mean? How far should the sanitize option go?

These weren't engineering questions. They were questions about operating philosophy.

And here's where things got interesting.

I couldn't put ChatGPT and Copilot in the same room. So I became the messenger. ChatGPT would propose a boundary. I'd copy it over to Copilot. Copilot would push back — *"that threshold is dangerous, here's an edge case you're missing."* I'd carry that back to ChatGPT. A revised proposal would come. Back to Copilot. And so on.

Round after round. I was the only hallway connecting two rooms full of very opinionated engineers.

The AIs were impressive — sharp, thorough, creative. But there was something they couldn't provide: the *feel* of actually operating FT8. The quiet satisfaction of a late-night DX contact finally going through. The frustration of watching RR73 after RR73 disappear into the noise. The instinct that says *"this doesn't look right"* when a decoded message seems off.

That experience doesn't live in a dataset. It lives in hours of operating time. And in the end, *that* was what settled every disputed boundary.

Once the philosophy was locked down, we moved to implementation: ChatGPT building, Copilot verifying and proposing patches. The cycle ran deep into the night.

---

## "Stop. This Is Good Enough." — What Claude Said in the Morning

Then I went to sleep.

The AIs don't sleep. But they do have context limits. Claude had quietly dropped out of the session somewhere around midnight — context window exhausted, silently gone. This happened more than once. (There's something almost poetic about that.)

In the morning, I brought Claude back up to speed and asked for a review.

After going through everything, Claude said:

**"If you keep going, you'll end up in a loop. The current implementation is sufficient. Stop here."**

That might have been the single most important piece of advice in the entire project.

There's a trap in software development: the feeling that there's always something more to improve. And if you follow that feeling indefinitely, you end up with something too complex to trust. Knowing *when to stop* is part of good design.

ChatGPT and Copilot had been pushing forward with real momentum. Claude was the one who put a hand up and said: *this is the finish line.*

That balance — the drive to build, and the wisdom to stop — is what made this project work.

---

## A Small Development Team

Looking back, the roles broke down something like this:

- **ChatGPT** — Architecture, design discussions, primary implementation. Opinionated, tireless, always willing to go another round. The project's architect and de facto PM.

- **GitHub Copilot** — Implementation verification, patch proposals, edge case hunting. The engineer who finds the holes you didn't know were there.

- **Claude** — Code review, safety checks, and knowing when enough is enough. The QA lead with a philosophical streak. *Also known for vanishing silently when the context window runs out.* (laughs)

- **Gemini** — External perspective, expression review. The outside voice that keeps things honest.

And my role was to be the one in the hallway — carrying ideas between rooms, adding the operating experience the AIs couldn't have, and making the calls that only a human with skin in the game could make.

---

## What Grok Said

After the release, I asked Grok to review the repository independently.

One line from that review stayed with me:

> *The design directly confronts the risk that ALL.TXT is not an official log, and the confidence + review CSV architecture — which makes every recovery decision explainable — is outstanding.*

The philosophy we'd argued about through the night had come through clearly, even to an outside AI reading it cold.

5 out of 5. "Essential tool for amateur radio operators" was the verdict.

---

## What This Tool Can Recover

ALLTXT2ADIF will probably sit unused on most operators' machines.

But the day a drive fails, or a file gets overwritten, or a system just dies — and ALL.TXT is the only thing left —

What's in that file isn't just data.

- The morning you worked your first European DX
- The contact you called for an hour before someone finally came back to you
- The contest run that went better than you expected
- The exchange with a station you'll never hear again

A log is more than a record. It's a history of time spent at the radio.

---

## One Last Thing

ALLTXT2ADIF was built where an operator's judgment and AI assistance found each other.

AI isn't a replacement. It's a collaborator — one that argues, proposes, builds, and occasionally tells you to stop. Working with these tools as genuine partners, not just utilities, changed how I think about what's possible.

One request: **always check the review CSV**. The final call is yours.

If this tool recovers even one log that would otherwise have been lost — that's a win for the whole team.

Download and source code:
**https://github.com/jp1lrt/alltxt2adif**

Stars, issues, and feedback are always welcome.

And perhaps this is the most important thing of all:
The best version of this story is one where you never need ALLTXT2ADIF. Back up your wsjtx_log.adi. Do it regularly. Do it now.


73  
JP1LRT / Yoshiharu Tsukuura



救えるログ、取り戻す"思い出" — ALLTXT2ADIF をリリースしました2026年03月05日 08時47分34秒

# 救えるログ、取り戻す"思い出" — ALLTXT2ADIF をリリースしました

あるとき、こんな相談を受けたことがあります。

「PCがクラッシュして、ログが全部消えた。ALL.TXTだけ残ってる。何かできないか」

FT8をやっている人なら、ALL.TXTの存在はご存じだと思います。WSJT-XやJTDXが静かに書き続けるデコード履歴のファイル。

**ALL.TXTはログではない。しかし、ログを失ったとき最後に残る"証拠"になる。**

このツールは、その"証拠"から交信の形を推定し、ADIFとして復元するためのものです。

すべてを失った夜に、それだけが残っていた。そういうケースは、実は珍しくないんです。

---

## ツールを作ろうと思ったとき、最初にやったこと

コードを書き始める前に、まず「作らないこと」を決めました。

ALL.TXTをそのままADIFに変換するツールは、原理的には簡単に作れます。でもそれをやると、必ず問題が起きる。

ALL.TXTは「受信した信号の記録」であって、「交信の記録」ではないからです。第三者デコードが混ざる。同じ周波数に複数のQSOが重なる。RR73が再送されることなんて日常茶飯事。pileupのさなかでは、「誰に向けて送った73なのか」が判然としないことさえある。

FT8の現場を知っている人ほど、「雑に復元すると危ない」ことが分かります。

だからこのツールの根本にある設計思想は、最初からひとつだけでした。

**「なぜそれをQSOとみなしたのか、説明できること」**

---

## コードより先に、方針を議論した夜

今回の開発で、いちばん印象的だったのは技術的な難しさではありませんでした。

ある夜、私はAIたちにこう言いました。

**「今は何も作らなくていい。方針について話し合ってほしい」**

strict と lenient の境界をどこに引くか。RR73をどの条件で「完了」とみなすか。high / medium / lowの定義を何に置くか。sanitizeオプションはどこまで許容するか。

これらは「コードの問題」ではなく、「運用の哲学の問題」でした。

ここで私がやったのは、少し変わったことです。

ChatGPTに提案を出してもらい、それをコピペしてCopilotに見せる。Copilotが「その境界値は危ない、こういうエッジケースが抜ける」と返してくる。それをまたChatGPTに持ち帰る。ChatGPTが修正案を出す。またCopilotへ。

私はその**橋渡し役**でした。

AIどうしは直接話せない。だから私が間に立って、意見を運ぶ。まるで二人の優秀なエンジニアが別々の部屋にいて、私だけが行き来できる廊下にいるような感覚でした。

提案が来る。「それは運用現場ではこういうケースが起きる」と私が文脈を加えて返す。また提案が来る。「そのロジックだと、pileup時にこう誤爆する」と返す。完全なネゴシエーションが成立するまで、何往復も続けました。

AIたちは驚くほど提案力が高い。でもFT8の「現場感」——深夜に静かに積み上げてきたQSOの感触、あの周波数のにぎわい、RR73が返ってこない焦り——それはデータではなく経験です。最終的に「これを運用でどう扱うか」を決めるのは、やはり人間でした。

方針が固まったところで、ChatGPTに実装させる。Copilotが検証してパッチを提案する。そのサイクルを回しながら、深夜は更けていきました。

---

## 「もうここで止めていい」——朝、Claudeが言ったこと

そうして夜が明けて、私は眠りました。

AIたちは眠りません。でも文脈には上限があります。Claudeは深夜のセッションの途中でいつの間にか「離脱」していました。コンテキストウィンドウの上限に達して、静かにチームを抜けていく。これが何度かありました(笑)。

翌朝、改めてClaudeを呼び戻して、夜のやり取りをまとめて共有しました。

レビューを依頼すると、Claudeはしばらく考えてから言いました。

**「これ以上続けるとループに入ります。今の実装で十分です。ここで止めていい」**

これは、開発の中でいちばん重要なアドバイスだったかもしれません。

ソフトウェア開発には「やりすぎる」という罠があります。改善できそうなところは無限にある。でも、それを全部やると複雑になりすぎて、かえって壊れやすくなる。「何を入れないか」を決めることも、設計のうちです。

ChatGPTとCopilotが熱心に議論し続けている横で、Claudeが「もうここが完成点だ」とブレーキをかける。このバランスが、今回うまく機能したと思っています。

---

## AIたちとの"小さな開発チーム"

あらためて整理すると、今回の開発はこういう役割分担でした。

- **ChatGPT** — 設計整理、方針議論、実装の主担当。「こうすべき」という強い意見を持ち、何往復でも付き合ってくれるアーキテクト兼PM補佐。

- **GitHub Copilot** — 実装検証、パッチ提案、エッジケース指摘。黙々と手を動かしながら、穴を見つけてくる現場の開発担当。

- **Claude** — レビュー、安全性チェック、そして「やりすぎ警告」。職人気質のQA担当。*ただし文脈の上限に達すると静かにチームから離脱する*(笑)

- **Gemini** — 第三者視点での確認と表現整理。少し距離を置いた外部レビュー担当。

そして私の役割は、AIたちの橋渡しをしながら**方針を決めること**でした。

- 何を大切にするか(安全性と説明可能性)
- どこまでを「成立」とみなすか
- 不確実なものをどう扱うか
- いつ「止める」か

AIは提案できます。議論もできます。コードも書ける。でも「責任ある判断」を下すのは人間です。そこを最後まで握り続けることが、今回の自分の仕事でした。

---

## Grokが言った一言

完成後、Grokにもレビューを依頼しました。外部の目として。

返ってきた評価の中で、ひとつ刺さった言葉がありました。趣旨はこうです。

> 「ALL.TXTは公式ログではない」というリスクを正面から扱い、  
> "なぜ成立とみなしたか"を説明可能な設計(confidence + review CSV)が秀逸。

狙っていた思想が、第三者のAIにも伝わった。これは素直に嬉しかったです。

評価は5/5。「アマチュア無線家必携レベル」という言葉もいただきました。

---

## このツールが救えるもの

ALLTXT2ADIFは、普段は使わないかもしれません。

でも、たった一度のクラッシュでログが消えたとき。そして**ALL.TXTだけが残っていたとき**。

そこに記録されているのは、単なるデータではありません。

- 初めてヨーロッパ局と繋がった朝
- 深夜にずっと呼び続けてようやく取ってもらえたDX
- コンテストで積み上げた足跡
- 誰かとの、もう二度と繰り返せない交信

ログは運用の積み重ねであり、思い出の集合体です。

---

## 最後に

ALLTXT2ADIFは、**実運用者の判断**と**AIたちの支援**が噛み合って生まれたツールです。

AIは「代わりに作る存在」ではなく、一緒に考えて、議論して、ときにブレーキを踏んで、磨き上げる仲間になり得る。今回それを強く感じました。

使うときのお願いがひとつ。  
必ず **review CSV を確認してください**。最終判断は、あなた自身の目で。

もしこのツールが、誰かのログを救うことがあれば——  
それはこの"小さな開発チーム"全員の成果です。

ダウンロードとソースはこちら:  

スター、Issue、フィードバック、大歓迎です。


最後に、これがいちばん大事かもしれません。  
このツールが不要で済むように、`wsjtx_log.adi` は普段からバックアップを取っておきましょう。

73  
JP1LRT / Yoshiharu Tsukuura