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）が再起動後に作動しないバグを修正
起動するだけで前回の設定通りに同期が開始されるようになり、移動運用や常設シャックでの信頼性が高まりました。ぜひ最新版をご活用ください。
▼ 詳細・ダウンロード
AI三兄弟の猛獣使い ― 2026年02月22日 21時43分08秒
# AI三兄弟の猛獣使い
―― ChronoGPS v2.4.4 と、2026年らしい泥臭いエンジニアリング
ChronoGPS v2.4.4 を作る過程で、思いがけず「2026年らしい開発体験」をすることになった。
それはコードを書く話であり、同時に **AIとどう付き合うか** という話でもある。
登場人物は三人……いや三体。
- ChatGPT
- Gemini
- Claude
そして、それらを相手に右往左往する、ただの人間である私だ。
---
## 発端：Geminiからの一通の“冷静な報告”
すべては、Geminiからのこのメッセージを起点に動き出した。
> 「先ほど、津久浦氏のローカル環境（実機）において、
> アップロードされたものと同一の gui.py に対し、
> `python -m py_compile gui.py` を実行しました。
> 結果は無出力、構文エラーは検出されませんでした。」
ここまでは穏やかだった。
だがこの時点で、**ChatGPTはすでに“別の世界線”に入っていた**。
---
## 第一の猛獣：ChatGPT、存在しない構文エラーを断言する
ChatGPTは断言した。
> 「gui.py には構文エラーがある」
> 「f-string が途中で切れている」
> 「try/except の構造がおかしい」
……しかし、**実機では動いている**。
`py_compile` も通る。
`main.py` からも普通に起動する。
それでもChatGPTは言い続けた。
> 「いや、理論的におかしい」
> 「動いているのは偶然だ」
ここで気づいた。
**AIは時に、“理論に固執して実機を無視する”**。
まるで昔の大学にいた、
「理論上あり得ないから君の実験結果が間違っている」
と言い張る偏屈な教授のようだ。
私はこの瞬間、**ChatGPTという猛獣の檻に足を踏み入れていた**。
---
## 第二の猛獣：Gemini、認知心理学的プロンプトを投下
ここでGeminiが割って入る。
GeminiはChatGPTを否定しない。
しかし、やり方が違った。
> 「実機で成功しているという事実を前提に、
> 自身の解析ロジックが“断片情報の誤認”ではないか再検証せよ」
これは**技術的反論ではなく、認知への介入**だった。
- 先入観に引きずられていないか
- バッファで切れたコード断片を誤認していないか
- 「動かないはずだ」という思い込みがないか
結果、ChatGPTは沈黙した。
正確には、**論点を失った**。
この瞬間、私は確信した。
> AI同士をぶつけるとき、
> 一番強いのは「感情的否定」ではなく
> **事実と前提条件の再定義**だ。
---
## 第三の猛獣：Claude、アーキテクチャへの冷徹な審判
そして最後に現れたのがClaudeだった。
Claudeは構文の話をほとんどしない。
代わりに、静かにこう言った。
- DRYではない
- ヘルパー関数が定義されているのに使われていない
- ローカライズ分岐が散らばっている
- 保守性が低い
つまり、
> 「動くかどうか」ではなく
> **「長く持つ設計かどうか」**
という観点で、容赦なく斬ってきた。
結果、採用されたのはClaude版の `time_sync.py` だった。
構文エラーを直しただけのコードではなく、
**設計として一段上に行っているコード**だったからだ。
---
## 結論：AIは猛獣、人間は猛獣使い
この一連の体験で、はっきりしたことがある。
AIは強力だ。
だが、**万能ではない**。
- ChatGPTは論理に強いが、時に現実を無視する
- Geminiは全体状況と前提整理が得意
- Claudeは設計美と保守性に厳しい
そして最後に必要なのは、
> **実機での挙動という、絶対的な真実**
を持って、
三体のAIを競わせ、
良いところだけを拾い集める人間の判断だ。
---
## 2026年らしい泥臭いエンジニアリング
ChronoGPS v2.4.4 は、
そんな**AI三兄弟との格闘の末**に出来上がった。
これはAI礼賛でも、AI批判でもない。
**AI時代のエンジニアは、コードを書く人ではなく
「AIの猛獣使い」になる**。
そんなことを実感した、
2026年らしい、少し泥臭い開発記録である。
追記：この格闘の副作用
AIたちに「無駄だ」「美しくない」と罵られながら削って分けて整えて……気づけば exe が **32MB → 19MB** に。
本当はビルド条件でもサイズは変わる。わかってる。
でも、理論（AI）と現実（人間）がぶつかって散った火花が、コードの不純物を焼き払ったように見えるんだから仕方ない。
「ChronoGPS」v2.4.4 リリース ― 2026年02月22日 21時25分32秒
時刻同期ツール「ChronoGPS」v2.4.4 をリリース！
今回は「中身の品質改善」中心です✨
✅ 同期ロジックの整理とテスト強化で、より安心して使えるように
✅ トレイ終了時の後始末（COMポート解放）を安定化
✅ ビルド手順を見直し、配布版の再現性を改善
DL👇から /詳細はリリースノートに
https://github.com/jp1lrt/ChronoGPS
今回は「中身の品質改善」中心です✨
✅ 同期ロジックの整理とテスト強化で、より安心して使えるように
✅ トレイ終了時の後始末（COMポート解放）を安定化
✅ ビルド手順を見直し、配布版の再現性を改善
DL👇から /詳細はリリースノートに
https://github.com/jp1lrt/ChronoGPS
ChronoGPS v2.4.3 リリース ― 2026年02月20日 17時23分37秒
ChronoGPS v2.4.3 リリース
定期同期モードの内部改善が中心です。
・「定期（監視用）」ラベル追加（16言語）
・毎秒サンプル蓄積で統計精度向上
・サンプル窓 5→30 に拡大
最近のコメント