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点です。
- Foxは1000Hz以下の信号もデコードするが、応答しない。
- 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の成功率が向上します。」
つまりこういうことです。
- Foxが3回コールバックしてもHoundのR+rptが届かない
- FoxはそのHoundをキューからドロップする（三振）
- しかしその後2サイクル、FoxはまだそのHoundのR+rptを待っている
- そのウィンドウの中で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
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` は普段からバックアップを取っておきましょう。
このツールが不要で済むように、`wsjtx_log.adi` は普段からバックアップを取っておきましょう。
73
JP1LRT / Yoshiharu Tsukuura
3Y0K Bouvet Island ― 2026年03月02日 13時12分14秒
📢 ChronoGPS v2.5.1 をリリースしました ― 2026年03月01日 23時33分16秒
v2.5系で入った「管理者昇格(Unlock)」「16言語対応」を土台に、
v2.5.1 では “挙動の一貫性” を徹底して磨き込みました。
主な改善点：
・言語切替／UI再構築で Unlock バナーが不整合にならないよう修正
・NTP自動同期が、設定OFFなのに勝手に復活する問題（幽霊タイマー）を根治
・手動NTP同期ボタンの回帰バグを修正（手動は常に反映、AUTOのみガード）
・設定値の型ゆらぎ対策（_to_bool）／スレッド二重起動防止など堅牢化
「OFFにしたら二度と勝手に動かない」誠実な挙動を約束します。
Release:https://github.com/jp1lrt/ChronoGPS/releases/tag/v2.5.1
最近無線業務よりプログラマーの真似事ばかり🤣🤣🤣🤣🤣
AIチームと一緒にソフトウェアをリリースした話 ― 2026年02月28日 14時00分25秒
# AIチームと一緒にソフトウェアをリリースした話
今日、ChronoGPS v2.5 をリリースしました。
GPS/NTP時刻同期ツールのアップデートなのですが、今回は開発プロセス自体がちょっと面白かったので書き残しておきます。
---
## 4人のAIと1人の機長
このプロジェクト、実は複数のAIと一緒に開発しています。それぞれに得意な役割があって、チームとして機能しています。
| AI メンバー | 得意な役割（ChronoGPS 担当） |
| ChatGPT (長男) | 実装・ロジック生成: スレッド保持や ShutdownManager の具体的な Python コード作成。 |
| Gemini (二男) | 広報・UX・多言語: X/FB 告知、ユーザーインターフェースの使い勝手、16言語のニュアンス調整。 |
| Grok (三男) | 監査・トレンド・X連携: プロジェクト全体の健全性評価、コードに9/10のスコアを付けてくれた |
| Claude (四男) | 設計・品質・ドキュメント: gui.py 分割案の策定、型定義（mypy）の導入支援、厳格なコードレビュー。 |
そして僕（JP1LRT）が全体のディレクターとして、各AIの出力を統合・判断しています。
---
## 今日の一日
v2.5のテーマは「起動UXの刷新」でした。
これまでのChronoGPSは起動するたびにWindowsのUACダイアログ（管理者権限の確認）が出ていました。海外ユーザーのVA3VF（Vince）から「毎回ダイアログが出るのは煩わしい」というフィードバックをもらったのがきっかけです。
**新しい設計（案2）**をChatGPT・Gemini・Claude・僕の4者で議論して合意。
- デフォルトはモニタ専用モードで起動（UACなし）
- 同期が必要なときだけ画面上のバナーをクリックして昇格
- UACをキャンセルしても、プロセスは死なない
「シンプルな変更」に見えて、裏側では Windowsのミューテックスを使ったゾンビプロセス防止、昇格ハンドオフの確実化、全16言語への対応など、かなりの実装が伴います。
---
## AIチーム開発の実際
面白いのは、AIごとに「得意・不得意」が実際にあることです。
今日だけでも：
- ChatGPTが書いたコードの**APIの不整合**をClaudeが発見（`allow_start`→`should_exit`という名前の食い違い）
- ChatGPTのコードにあった**正規表現のバグ**（`group(2)`→`group(1)`）を三者が同時に指摘
- 統合テストを僕が実際に手元で動かして、B-2（UACキャンセル時にプロセスが死なない）を確認
「AIに全部任せる」のではなく、**各AIの出力を僕がディレクターとして評価・統合する**スタイルです。AIが間違えることもあるし、複数のAIが互いの出力をチェックすることでバグが減ります。
Grokが出してくれた最終評価：
> *Structure: 9/10, Code Quality: 9/10, Functionality: 9.5/10, Security: 9/10 — Overall: 9/10*
---
## 「なぜその時刻になるのか説明できること」
ChronoGPSの設計思想は一貫しています。
**「正しく動く理由を説明できるツール」**であること。
FT8などのデジタル無線では、時刻のずれが交信品質に直結します。正確な時刻基準があるほど、デコード率と安定性が上がります。GPSで時刻を合わせるのは簡単ですが、「なぜ合っているのか」「どういう条件で補正するのか」が分からないツールは信頼できません。
ChronoGPSはその透明性を大切にしています。AIチームとの開発も、その思想と同じです。「なぜその実装にするのか」を全員で議論して、説明できるコードだけをリリースする。
---
v2.5はここからダウンロードできます。
FT8やFT4で時刻合わせに困っている方、ぜひ試してみてください。
73！ 🛰️ JP1LRT
ChronoGPS v2.5 公開 ― 2026年02月28日 12時28分12秒
GPS/NTP 時刻同期ツール「ChronoGPS」の最新バージョン v2.5 をリリースしました！
今回のアップデートでは、カナダの Vince 氏 (VA3VF) をはじめとする海外ユーザーからの熱心なフィードバックを反映し、利便性と安定性を大幅に向上させています。
🚀 v2.5 の主な新機能と改善点：
「監視モード」の導入（非管理者権限対応）
管理者権限なしでもアプリが起動可能に！まずは「監視モード」で動作を確認。同期が必要な時だけ、画面上のバナーからワンクリックで「管理者モード」へ昇格・再起動が可能です。
世界 16 言語をフルサポート 🌐
UI、設定、警告ダイアログに至るまで、日本語・英語を含む全 16 言語に対応。イタリア語、フランス語、中国語（簡体/繁体）など、世界のどこにいても母国語で安心して使えます。
多重起動防止機能（Mutex）の搭載
二重起動によるCOMポート競合を未然に防ぎます。既に起動している場合は、タスクトレイのアイコンがあなたをガイドします。
堅牢なシャットダウン処理
OS終了時やアプリを閉じる際のプロセス管理を最適化。ゾンビプロセスを残さず、クリーンに終了します。
💎 「確実性」と「使いやすさ」を両立させるため、内部ロジックを徹底的に磨き上げました。
今回のアップデートでは、カナダの Vince 氏 (VA3VF) をはじめとする海外ユーザーからの熱心なフィードバックを反映し、利便性と安定性を大幅に向上させています。
🚀 v2.5 の主な新機能と改善点：
「監視モード」の導入（非管理者権限対応）
管理者権限なしでもアプリが起動可能に！まずは「監視モード」で動作を確認。同期が必要な時だけ、画面上のバナーからワンクリックで「管理者モード」へ昇格・再起動が可能です。
世界 16 言語をフルサポート 🌐
UI、設定、警告ダイアログに至るまで、日本語・英語を含む全 16 言語に対応。イタリア語、フランス語、中国語（簡体/繁体）など、世界のどこにいても母国語で安心して使えます。
多重起動防止機能（Mutex）の搭載
二重起動によるCOMポート競合を未然に防ぎます。既に起動している場合は、タスクトレイのアイコンがあなたをガイドします。
堅牢なシャットダウン処理
OS終了時やアプリを閉じる際のプロセス管理を最適化。ゾンビプロセスを残さず、クリーンに終了します。
💎 「確実性」と「使いやすさ」を両立させるため、内部ロジックを徹底的に磨き上げました。
📥 ダウンロード https://github.com/jp1lrt/ChronoGPS/releases/tag/v2.5
使い方は README をお読みください https://github.com/jp1lrt/ChronoGPS/blob/main/README.md
【ChronoGPS v2.4.6 リリースのお知らせ】 ― 2026年02月25日 11時14分27秒
時刻同期ツール「ChronoGPS」の最新版 v2.4.6 を公開しました。
今回のアップデートでは、設定の復元に関する修正を中心に、利便性と安定性を向上させています。
🛰️ 主な更新内容 ・Windowsのシステム言語を自動判定して起動（16言語対応） ・再起動後にNTP自動同期が開始されないバグを修正 ・GPS定期同期（Interval）が再起動後に作動しないバグを修正
起動するだけで前回の設定通りに同期が開始されるようになり、移動運用や常設シャックでの信頼性が高まりました。ぜひ最新版をご活用ください。
▼ 詳細・ダウンロード
最近のコメント