2026年東京CWコンテスト参戦記 ― 寝坊と中抜け、そして家庭内SWR無限大の危機!? 🤣 ― 2026年10月25日 14時11分45秒

TOKYO CW CONTEST 2026
📡 寝坊! 中抜け!
それでも234 QSO!
最大の難関は……
家庭内SWR無限大の回避!? 🤣👻
2026年10月25日(日)06:00〜12:00 JST

2026年の東京CWコンテストに参加しました!📡

このコンテストは06:00から12:00までの6時間勝負。

今回は最初から優勝を狙っていたわけではなく、気楽に楽しむつもりでした。

とはいえ、まさかこんな参加の仕方になるとは……(笑)

😴 開幕早々、寝坊で遅刻!

まず、開始時刻の06:00には起床できませんでした🤣

最初のQSOは06:13。

いきなり13分遅れでのスタートです。

まあ、今日は勝負を狙う日ではないので、気を取り直して3.5MHzから430MHzまで、各バンドを回りながら交信を重ねていきます。

ところが、ここで次なる問題が発生!

👻 最大の難関は《かみさん事由》

09:17頃、運用を中断しました。

理由は……

《かみさん事由》🤣
対応を怠った場合の予想される事態
家庭内SWR = ∞
もはや整合不能!
生活そのものが成り立たなくなります(笑)

無線機には高性能なアンテナチューナーがありますが、家庭内のインピーダンス整合については、そう簡単にはいきません。

場合によっては、いかなる整合回路を投入しても解決できない可能性があります🤣

したがって、こちらの対応を最優先!

何しろコンテストは次回もありますが、家庭内の平和が失われると、今後の無線活動そのものが危うくなりますからね👻

運用中断
09:17 ~ 11:39
約2時間22分
6時間のコンテストで、これはなかなかの中抜け(笑)

運用再開は11:39頃。

コンテスト終了まで残り約20分!

それでも最後の11:59まで交信を楽しみました。📡

📊 さて、肝心の結果は?

参加部門は都内電信オールバンド(1CA)。

総得点
45,423 点
QSO
234
得点
309
マルチ
147

3.5MHzから430MHzまで、全8バンドで交信できました。

📋 CTESTWIN 得点集計
得点
バンド別QSO数・得点・マルチ

最もQSOが多かったのは7MHzの66局。

次いで3.5MHzが50局、14MHzが32局。

いつも主戦場にしている50MHzでは24局でした。

今回の得点は309点 × 147マルチ = 45,423点。

寝坊と中抜けがあったことを考えれば、十分楽しめた結果です👍

📈 グラフに刻まれた《かみさん事由》(笑)

時間帯別QSOグラフをご覧ください。

📈 時間帯別QSOグラフ
画像をクリックすると拡大表示できます

ご覧の通り、09:17頃から11:39頃までQSOがありません。

リグの故障でも、アンテナのトラブルでも、停電でもありません。

《家庭内SWR調整時間》です🤣👻

コンテストの時間帯別グラフに、家庭内の事情がこれほど鮮明に記録されることも、そうそうないでしょう(笑)

🏆 強豪のJK1JHU、JK1QAY両局とも交信

東京CWコンテストの都内電信オールバンド部門といえば、やはりこのお二人。

昨年2025年の結果は、

2025年 1CA部門
🥇 JK1JHU 142,038点
🥈 JK1QAY 138,836点

このお二人、昨年は3,202点差という大接戦でした。

今回の私のログを確認すると……

2026年 今回の交信数
📡 JK1JHU 8 QSO
📡 JK1QAY 7 QSO

お二人とも、たくさんの交信ありがとうございました!😊

もっとも、このお二人がいるので、私は最初から優勝を狙っていたわけではありません(笑)

今回は勝負にこだわらず、無線そのものを楽しむ参加でした。

😊 こういうコンテストも、また楽しい

開始早々の寝坊。

そして、約2時間22分の《かみさん事由》による中抜け。

それでも最後の20分に復帰して、最終的には234 QSO。

いつも勝ちを狙って全力で走るのもコンテストの楽しみですが、こうして自分のペースで参加するのも悪くありません。

何より、家庭内の平和を維持しながら無線を楽しめたことが、今回の最大の成果かもしれません🤣

📡 コンテストも楽しく!
家庭内の平和は、もっと大切に!
目指せ、家庭内SWR 1.0!🤣👻

交信いただいた皆さん、ありがとうございました!

またコンテストでお会いしましょう。📡

73 de JP1LRT
2026年10月25日

📡 JTDX Contest 3.0.0-rc11 公開!――自動呼び出し・単局同期・バンドホッピングなど新機能が続々 ― 2026年10月25日 13時04分47秒

JTDX Contest 3.0.0-rc11|ASABLO記事プレビュー
DIGITAL MODE SOFTWARE UPDATE
📡 JTDX Contest
3.0.0-rc11
自動呼び出し・単局同期・バンドホッピングなど、運用を助ける新機能が登場!
2026.10.24 RELEASE   |   RC11

チリの CE3TSK(Tihomir)さんが開発している JTDX Contest Edition の新しいリリース候補版、v3.0.0-rc11 が公開されました。🎉

今回の更新は、日々のFT8・FT4・FT2運用に便利な機能の追加と、オートシーケンスやデコード時の安定性改善が中心です。特に気になったところを、運用者目線で紹介します。

今回の注目ポイント
「相手局を待つ」「自動で呼ぶ」「時刻を合わせる」――運用の手間を減らす機能が充実!

🆕 注目の新機能

01|Wait and Call 自動呼び出し

DX Call欄に設定した相手局の信号を受信すると、自動で呼び出します。最大6回まで試行。DXpeditionメニュー、Ctrl+W、またはEnable Txの右クリックから利用できます。

02|Wait and Reply 応答待機

DX Call欄の相手局から自局宛ての送信を受信すると、Enable Txが自動的にオンになります。相手の応答を待つ場面で便利な機能です。

03|バンドホッピング Tab 3

Tab 3から、FT8・FT4・FT2を1~2分間隔で順番に切り替える機能が追加されました。複数モードの受信状況を見て回る際に役立ちそうです。

04|Single Station Sync 単局同期

DX Call欄に相手局を設定し、SyncをCtrl+クリックすると、その局のDTを基準にJTDXの時刻補正を行います。

💡 個人的にも注目していた機能です。これはWindowsのシステム時計を変更する操作ではありません。

05|距離と方位を表示

Band Activityに、国名に続いて相手局までの距離と方位を表示できるようになりました。伝搬状況を確認するときにも嬉しい改善です。

06|Alternative layout

JTDX ImprovedのALレイアウト風の表示を選べるようになりました。画面の好みや運用スタイルに合わせた選択肢が増えています。

07|無線機との連携を強化

SWRが2.5を超えると送信を停止する機能を追加。また、Tuneを右クリックすると、対応する無線機のアンテナチューナーを起動できます。

※動作は無線機やCAT接続などの構成に依存します。SWR保護機能は無線機・アンプ側の保護機能に代わるものではありません。

🔧 修正・改善されたところ

  • 自動シーケンサー:RR73付近の動作を改善。
  • クラッシュ修正:混雑したFT8バンド、100局を超えるFT4/FT2デコード、PTTポートを開けない場合の計3件を修正。
  • 送信メッセージ:送信できないメッセージは送らないよう改善。FT系モードではTx欄をピンク色で表示。
  • バンド変更:無線機側で周波数帯を切り替えた場合の扱いを改善。
  • その他:FT2、PSK ReporterへのQO-100周波数通知、WSPR、グリッド表記などを修正。
  • データ更新:2026年版のCALL3.TXTを同梱。
  • 日本語表示:翻訳を再レビューし、表示文言を見直し。🇯🇵
📁 ALLCALL7.TXTを利用している方へ

rc11ではALLCALL7.TXTが初期状態で無効になり、有効化には JTDX_ALLCALL7=1 の設定が必要と案内されています。Windowsでの具体的な設定方法と読み込み確認手順は開発者に確認中です。

⬇️ ダウンロード

Windows、Linux、macOS向けの配布ファイルは、開発者の公式ダウンロードページから入手できます。

OFFICIAL DOWNLOAD
JTDX Contest Edition
📥 公式ダウンロードページを見る
https://ce3tsk.com/download/index.html
⚠️ RC(リリース候補)版です

実運用のメイン環境へ上書き導入する前に、設定ファイルやログのバックアップを取り、可能なら別環境で動作を確認することをおすすめします。

✍️ ひとこと

今回のRC11は、派手な新モードを追加するというよりも、実際の運用で「ここがもう少し便利なら」と感じる部分に手が入った更新という印象です。

特にSingle Station Syncは、私からも要望していた機能の一つ。開発者のTihomirさんが反映してくださったことに感謝しています。日本語訳についても、引き続き気付いた点をフィードバックしていきたいと思います。

新しい機能を試すのは楽しいもの。でも、まずは安全な環境で確認してから。みなさんも良いデジタルモード運用を! 📡✨

73 de JP1LRT
公式サイト:https://ce3tsk.com/
#JTDX   #FT8   #FT4   #FT2   #アマチュア無線

第1回 JARL WW RTTYコンテストに「ちょっとだけ」参加(笑)― CTESTWIN・FSK・マクロ・RITの話 ― 2026年10月19日 10時58分36秒

JP1LRT / CONTEST LOGBOOK / OCT 2026
第1回 JARL WW RTTYコンテストに
「ちょっとだけ」参加しました(笑)📡
CTESTWIN × MMTTY × IC-7300
USBケーブル1本でFSK。マクロは少し長め、RITはいつもON。

10月17日(土)から19日(月)まで開催された第1回 JARL World Wide RTTYコンテスト。長年のJARTS WW RTTY ContestをJARLが引き継いで開催する、最初の大会です。

先週は全市全郡コンテストに出たばかり。今回は特に気合を入れるつもりもなく、空いた時間にCQを出して「ちょっとだけ」遊びました。😁

TOTAL QSO
182
MULTIPLIER
24
CLAIMED SCORE
8,856
BandQSOMult.
3.5MHz196
7MHz15814
14MHz54
TOTAL18224

シングルオペ/オールバンド/ローパワー。申告スコアは369 QSOポイント × 24マルチ=8,856点。7MHzが158 QSOで、ほぼ7MHzでのCQ RUNでした。

運用は日曜の昼頃から月曜の終了直前まで断続的に。海外との交信はWB6JJJ、CX2AQ、9A1A、LZ5R、I4JEDの5局。私がQRVした時間帯では海外局がとても少ないという印象でした。第1回ということで、これから海外にももっと広まってくれるといいですね。

🔌 01|CTESTWIN+MMTTY、そしてFSK!

私が使ったのはCTESTWIN 4.64 + MMTTY 1.68 + EXTFSK 1.06。リグはIC-7300のRTTYモードです。デコードやログ管理はPCで、送信はAFSKではなくFSK。

CTESTWIN (ログ・RUN・マクロ)
↓
MMTTY (受信復調・RTTY符号生成)
↓ EXTFSK:COM16/DTR=FSK・RTS=PTT
IC-7300(RTTYモード)
受信音声はIC-7300のUSB Audio CODECからMMTTYへ。CAT制御も含め、私の設備ではPCとIC-7300をつなぐ物理的なケーブルはUSBの1本だけです。COM16は私のPCでの設定例。
📷 私のEXTFSK設定(IC-7300)

FSK出力はDTR、PTT出力はRTS。COM16は私のPCの例です。
写真をクリックするとasabloの拡大画像を表示します。

普段FT8をやっているのでUSB接続環境はできています。FSKのキーイングとPTTを設定すれば、余計な外付けインターフェースを増やす必要もありません。CTESTWINの受信文字列をクリックしてコールサインやナンバーを取り込み、マクロでテンポよくRUNできるのも実に快適です。

私なら、FSK対応リグでは断然FSKをおすすめします。✅

送信時にPCからRTTYのマーク/スペース音を流してSSBを変調するのではなく、リグ側でFSKを生成する方式。送信音声レベルやAFSKの過大入力を気にして調整する必要がありません。 これが大きい。

FSKではPC側の「送信用サウンドカード」の指定は、FSK信号の生成には関係しません。一方、受信側の音声入力とデコーダーの調整は必要です。また、最初のCOMポート、FSK極性、PTTなどの設定は当然必要。そこが完了してしまえば、送信オーディオレベルをその都度追い込む作業から解放される、という意味です。

もちろん、適切に調整したAFSKでも良好なRTTY信号は出せますし、FSKなら自動的に綺麗な電波になるわけでもありません。ただ、FSKを使えるリグで、あえて送信音声系を経由する理由は私にはあまりないですね。RTTYモード専用の受信フィルターや、Mark周波数の明確な表示も便利です。

※USBケーブル1本で何を同時制御できるか、またCATとFSKのCOMポートをどう共用するかは、機種・ドライバー・ソフト構成によって異なります。「同じCOMポートを複数のソフトが無条件で同時に開ける」という意味ではありません。利用する機種の取扱説明書に従ってください。

⌨️ 02|マクロは短ければいい、とは限らない

JARLが公開している「RTTYコンテスト入門」(JS1OYN 高橋勝さん著)には、初心者にも分かりやすい交信例が掲載されています。基本がよくまとまった資料です。

その記事にも書かれているように、RTTYは文字化けがあるため、コンディション次第でコールサインやナンバーを3回送ることも有効です。私は、その考え方を普段のCQ RUN用マクロに少し強めに反映しています。記事の例を否定したいのではなく、運用方針の違いのお話です。😄

📷 CTESTWINのRTTYマクロ設定

実際に使ったF5〜F14のマクロ設定画面。以下では、そのうちF6(UR)・F7(TU)・F12(ANS)の考え方を紹介します。
写真をクリックするとasabloの拡大画像を表示します。

① CQ局を呼ぶときは、自局のコールを2回
JP1LRT JP1LRT
CQを出している局が知りたいのは「誰が呼んでいるか」。呼ばれている側は、自分のコールサインなんて知っていますからね(笑)。
「JA1RL DE JP1LRT JP1LRT」と相手のコールを付けるより、必要なら「JP1LRT」をもう1回繰り返すほうが、相手のコピーの助けになる、というのが私の考えです。
② コールバック:相手のコール2回、ナンバー3回
JARLの一般的な例
JA2RL 599 60 60
私のF6マクロ(展開例)
JA2RL 59960 60 60 JA2RL

相手のコールサインを最初と最後に。最初が文字化けしても、最後で自分が呼ばれたと確認できるかもしれません。年齢「60」は3回。少し送信時間が増えても、NR? や CALL? で往復するより、最初から一度でコピーしてもらいたいのです。

CTESTWIN設定:$c $u $m $m $c $$(送信ナンバーは今回の例)
③ 相手からの返答:短い形でも成立するけれど…

こちらがコールバックしたあと、QSL UR 599 74 74 とだけ返してくる局もいます。これでも通じるときは通じます。

JARLの記事・例2(呼出局からの返答)
JA1RL 599 74 74
私のF12「ANS」マクロ(自局ナンバーが60の例)
JA1RL 59960 60 60 JP1LRT TU

私は呼び回り側でも、相手のコールサイン、ナンバーの反復、最後に自局コールを入れています。相手が複数局を相手にしていたり、QRM・QRN・QSBがあったりする場面では、誰からの返答か、ナンバーは何かを少ない手戻りで伝えたいからです。何回も送り直すより、RTTYらしい文字化け対策を最初からしておいてもいいでしょう。

CTESTWIN設定:$c $u $m $m jp1lrt tu $r$n$$
④ QSO終了:誰との交信が終わったか明示
JARLの一般的な例
TU JA1RL TEST
私のF7マクロ(展開例)
JA2RL TU DE JP1LRT CQ

最後にも相手のコールサインを入れれば、誰とのQSOが完了したのかが明確です。末尾は次の局を募集する「CQ」。TEST でも意味は通るので、そこは好みですね。

CTESTWIN設定:$c TU DE jp1lrt CQ $$
狙っているのは「電文の最短時間」ではなく、「1 QSOの手戻りの少なさ」。

冗長に送れば常に速くなるわけではありません。コンディションが良ければ短い電文も有利。それでも私は、RTTY特有の文字化けで NR? / CALL? / AGN? を何往復もすることを、できるだけ減らしたいのです。

🎯 03|RITはいつもON。ウォーターフォールが頼り!

今回のCQ RUNでは、少し周波数がずれたまま呼んでくる局が結構いました。 送信の音質が悪いという話とは別で、相手のRTTY信号の周波数が、こちらの受信の中心と一致していないという話です。

私のIC-7300はRTTYモード。RITは常にON、基準は0.00にしています。CQを出す側の送信周波数は固定したまま、呼んできた相手に合わせて受信側だけをRITで動かすためです。

そして、IC-7300のウォーターフォールのSPANは0.5kHz、または1kHzに設定。広いバンド全体を見るのではなく、目の前のRTTY信号を大きく、細かく見るためです。

WATERFALL / RTTY 170 Hz SHIFT (概念図)
Space
Mark → 基準
左:Space ← 170Hz → 右:Mark(高い周波数側)
※位置関係の模式図。RTTY Normalで周波数が右へ高くなる表示を想定。実画面の縮尺ではありません。
実際の手順はこんな感じ
① CQを出すときはRIT ON/0.00、送信周波数は動かさない。
② 応答局のRTTY信号がずれていたら、ウォーターフォールの2本線を見る。
③ 右側のMarkを目印に、RITで受信側だけを合わせ、MMTTYのデコードを確認する。
④ 交信が終わればRITを0.00基準に戻し、次の応答局を待つ。

SPANを狭くするのは、2本線の位置を見やすくするため。受信フィルターの帯域幅を狭くするのとは別の操作です。QRMが強ければRTTY用の受信フィルターも適切に使います。

もちろん、周波数を合わせたからといって、深いQSBやQRNによる文字化けがなくなるわけではありません。だから、前述のコールサインやナンバーの反復が効いてくるわけです。

🤣 04|「QRZ?」には返事がないのに…

呼んでいる信号は分かる。でも、コールサインが一文字もデコードできないことがあります。そこでフリーメッセージで QRZ? QRZ? や AGN AGN と送るのですが……。

JP1LRT : CQ TEST JP1LRT JP1LRT CQ
相手局 : (信号は見えるがデコードできない)
JP1LRT : QRZ? QRZ? / AGN AGN
相手局 : …… (沈黙)
JP1LRT : CQ TEST JP1LRT JP1LRT CQ
相手局 : 再び呼んでくる!(笑)

いやいや、だからさっきからもう一回呼んでくださいって言っているんだけど!🤣

こういうことはCWコンテストでもあります。相手がこちらの再送要求をコピーできていない可能性もあるので一概には言えませんが、長く無線をやっていても不思議に感じる現象の一つです。

☕ 05|そんなわけで「ちょっとだけ」でした

参加してみると、RTTYはやっぱり面白い。FT8とは違って、チューニング、文字化けの見極め、マクロの使い方、テンポの良いRUNなど、オペレーターの腕が出るところがあります。

今回は海外局が少なかったのが少し残念。来年はもっと多くの局が参加してくれると嬉しいですね。

「ちょっとだけ」で182 QSO。(笑)
交信していただいた各局、ありがとうございました!
73 de JP1LRT 📡
参考・関連リンク
・JARL「RTTYコンテスト入門」(JS1OYN 高橋勝氏)
・第1回 JARL World Wide RTTYコンテスト規約
・CTESTWIN公式ヘルプ:MMTTY
・CTESTWIN公式ヘルプ:PTT設定
※本文の交信例は、比較のための例示です。RTTYマクロの動作・画面構成は、私が今回使用した設定に基づきます。

QSLカード、裏返さなくても分かりますか? ――「マイルール」ではなく、受け取る側への小さな配慮 ― 2026年10月14日 12時03分50秒

PAPER QSL CARD & A LITTLE COURTESY

📮 QSLカード、
裏返さなくても分かりますか?

「マイルール」なのか、それとも受け取る側への配慮なのか。

先日、Xで「届いたQSLカードのデータ面に、発行局自身のコールサインが書かれていない」という投稿が話題になっていました。

これに対して「そんなのマイルールだ」「他人に押し付けるな」といった批判もあるようです。

でも、この話。ちょっと面白いんですよね。😊
私は「他人に強制してはいけない」という点には賛成です。一方で、「義務ではないから、書く意味もない」わけでは決してないと思っています。

📻 そもそも、何が不便なの?

例えば、紙QSLカードの表面が写真やイラストを使ったデザイン面、裏面が交信データ面になっている場合を考えてみましょう。

📷 表面(デザイン面)
大きな発行局コールサイン、写真、イラストなど

↕ ひっくり返す ↕

📝 裏面(交信データ面)
交信相手のコールサイン、日時、周波数、モード、RSTなど
ところが、発行局自身のコールサインがない……。

これでも、表面に発行局のコールサインが明確に表示されていれば、それだけでQSLカードとして成立しなくなるわけではありません。 問題はそこではないんです。

受領者が交信データをログと照合するとき、「これ、誰からのカードだっけ?」と表面へひっくり返して確認する必要がある。1枚なら数秒。でも、何百枚、何千枚となったらどうでしょう。😅

発行する側が一度レイアウトを工夫すれば、受け取る側の繰り返しの手間を減らせる。 そういう話です。

✅ 私のQSLカードでは

私は、交信データ面にも、いつも次の情報を記載しています。

自局コールサインの JP1LRT

📍 自局の運用地 ― JCC/JCG番号、Grid Locator

👤 オペレーター名

📋 交信データ ― 相手局、日時、周波数、モード、RSTなど

これならデータ面だけで、誰が・どこから・いつ・どのように交信したかを確認できます。

もちろん、JCC/JCG番号やGrid Locatorは実際にその交信を行った運用場所の情報を記載することが大切。移動運用なら、固定局の所在地と混同しないようにしたいですね。

名前の表示も含め、ここで挙げた項目すべてが一律に義務という意味ではありません。私自身が、受領者にとって便利だと考えて採用しているデザインです。

🌏 これって本当に「マイルール」?

そこで、海外のアマチュア無線団体の資料も調べてみました。すると、交信データと発行局情報を同じ面で確認できるようにするという考え方が、きちんと紹介されていたんです。

🇺🇸 ARRL(米国)

ARRLの公式資料 Sending and Receiving Paper Gems の「Essential Information」には、こう書かれています。

Your call sign should be printed or written on the report side of the card.

「自局のコールサインは、交信レポート面に印刷または記入すべきです。」

今回の話題に、まさに直接答えている一文ですね。運用場所やPortable/Mobileの明示についても案内しています。

🔗 ARRL公式資料(PDF・21ページ)

🇪🇸 URE(スペイン)

スペインのURE公式サイト掲載のQSL解説「Tráfico de QSL」では、片面に写真やイラストを使用できるとしたうえで、もう一方の面に必要な情報をまとめるよう説明しています。

Nuestro indicativo: de forma visible y clara

「自局のコールサインは、明瞭で分かりやすく。」

しかも、受け取った相手が「誰からのカードなのか探し回らなくて済むように」という趣旨まで説明しています。今回の問題意識と、ほとんど同じです。😊

🔗 URE公式サイト掲載「Tráfico de QSL」

🇦🇹 ÖVSV(オーストリア)

オーストリアのÖVSV公式Wikiにある「QSL Karten Design」は、さらにストレートです。

Die QSL-Karte muss auf der Datenseite enthalten:
• Rufzeichen des Absenders

「QSLカードのデータ面には、発行者のコールサインを記載しなければならない。」

一方で、冒頭にはカードのデザインは基本的に各自の自由とも書かれています。これは同Wikiの記載指針であり、日本の局に適用される義務ではありません。

🔗 ÖVSV公式Wiki「QSL Karten Design」

🇯🇵 JARL(日本)

JARLの「QSLカードの書き方」では、自局のコールサインを目立つように表示することや、QTH欄へのJCC/JCG番号・グリッドロケーター、OP欄への名前の記載などが案内されています。

ただし、この記載例は発行局のコールサインと交信データを同一面に集めたスタイルです。写真のデザイン面と交信データ面を分けた両面式カードに対し、同じ情報を重複記載する義務を定めたものではありません。

🔗 JARL公式「QSLカードの書き方」

※上記は資料の内容を紹介したものです。ARRLの推奨文、URE掲載の解説、ÖVSVのWiki、JARLの記載例は、それぞれ文書の性格が異なります。海外で紹介されている方法が、そのままJA局への義務になるわけではありません。

💬 議論がすれ違っているのかも?

Xでの反応を読んでいると、「表でも裏でも、カード全体で確認できれば十分」という意見があります。もちろん、その通りです。私も、発行局のコールサインがデータ面にないだけで、QSLカードとして駄目だなどとは思いません。

一方で、「一度に大量のカードを受領して照合するので、データ面だけで確認できると助かる」という声もあります。こちらにも実務上の理由があります。

発行する人にとっては不便がなくても、受け取って整理する人には小さな手間が生じるかもしれない。「今まで問題にならなかった」ことと「もっと照合しやすくできる」ことは、矛盾しないんですよね。😊

⚠️ ここが一番大事。「強制」する話ではありません

受領者に対する配慮を提案することは、
書式の強制ではない。

私はデータ面に発行局のコールサインなどを記載することを、良い方法だと思っています。 でも、だからといって、他人のQSLカードの書式を強制的に変えさせるべきだとは思いません。

JARLの「交信証及び受信証の転送取扱規程」第2条は、交信証明欄に必要な交信データを記載するよう定めています。しかし、発行局のコールサインをデータ面にも重複して表示することまでは明記していません。

🔗 JARL「交信証及び受信証の転送取扱規程」(PDF)

もちろん、交信日時や運用場所などの事実関係に誤りがあれば訂正すべきです。けれども、必要な情報がカード全体に正しく載っているのに、自分と違うレイアウトだからといって「矯正」しようとするのは、別の話でしょう。相手のカードを「直させる」ためではなく、こんな工夫もありますよ、と紹介するための記事です。

「義務ではない」≠「意味がない」

そして、「推奨する」≠「強制する」です。

発行する側が一度だけレイアウトを工夫することで、受け取る側の確認作業が少し楽になる。これは私だけの独自の思いつきではなく、海外の資料にも通じる考え方です。ただし、採用するかどうかは、それぞれの発行者の判断でよいと思います。

海外の資料は「こうすると良い」という考え方を説明する根拠にはなります。でも、それによって他人に守らせる権利が生まれるわけではありません。

📮 受け取る人の顔を思い浮かべて

紙QSLカードは、デザインを楽しむものでもあり、交信の記念として残すものでもあります。そこは自由でいいし、私もそう思います。

でも、カードは自分の手元に飾るためだけのものではなく、交信してくださった相手に届けるものでもあるんですよね。

だから私はこれからも、デザイン面は好きなように楽しみながら、データ面には自局コールサインのJP1LRT、交信時の運用地情報、オペレーター名を記載します。

誰かに義務付けたいわけではありません。ただ、こういう小さな工夫も、相手への配慮のひとつではないでしょうか。😊

強制ではなく、配慮。

QSLカードを受け取る相手のことを、少しだけ考えてみませんか?

73 de JP1LRT

※リンク先の資料は2026年10月14日に確認。引用の日本語訳は本記事によるものです。

言ってみるものですね(笑)――JARLコンテスト電子ログの「意見」が「意見・感想」に ― 2026年10月08日 22時03分43秒

JARL CONTEST / ELECTRONIC LOG
「意見」から
「意見・感想」へ 📡
ちょっとした提案でしたが、実際にJARLの電子ログサマリー作成ページが変更されました。

ちょっと嬉しい話です 😊

先日、JARLコンテストの電子ログサマリー作成ページにある 「意見」という欄について、 ひとつ提案をしてみました。

💡 私が気になったこと
結果発表ページではすでに 「意見・感想」 と表示されています。

それなら、入力する側の電子ログサマリー作成ページも 「意見・感想」 にした方が、 「ここには感想を書いてもいいんだ」 と分かりやすいのではないか?

コンテスト終了後に書くことは、別に要望や苦情だけではありません。

😊 「楽しかった」
☀️ 「コンディションが良かった」
📻 「久しぶりに参加しました」
😴 「さすがに眠かった(笑)」
💪 「来年はもっと頑張ります」
😭 「あと少し届かなかった、悔しい!」

そんな短い一言でも、後から結果を見る人にとっては、 その年のコンテストの雰囲気を伝える記録 になると思っています。

ところが入力欄に単に「意見」とだけ書かれていると、

「何か要望を書くところなのかな?」
「問題点や苦情を書く欄?」

と受け取る人もいるのではないか、と感じました。

📩 そこで、実際に提案してみました

今回、同じ趣旨で、

● JARLコンテスト委員会
● CTESTWIN 作者
● zLog 作者

それぞれに提案を送ってみました。

✅ CTESTWIN

作者の堀内さんから、

「次のバージョンにてご提案通り修正いたします。」

との回答をいただきました。

✅ zLog

zLogでは、電子ログ形式がJARL推奨形式に準拠していることから、 欄名そのものを独自に変更することは見送る、という判断になりました。

ただし、提案の趣旨を受けて、

「感想や意見を入力してください」

というガイド文を追加していただけることになりました 👍

🎉 そしてJARL本体も変更

JARLコンテスト係から連絡をいただきました。

電子ログサマリー作成ページ

「意見」
↓
「意見・感想」

VERSION=R2.1 で変更したとのことでした。

👻 いやー、言ってみるものですね(笑)

もちろん、これはものすごく大きな制度変更という話ではありません。

でも、こういうちょっとした改善によって、

「あ、ここには感想を書いていいんだ」

と思う人が少しでも増えて、 結果発表ページに参加者の声がもっと残るようになれば、 それはそれで意味があると思います。

🏆 コンテストは、得点と順位だけではない

コンテストって、順位や得点だけではないんですよね。

その時のコンディション。
うまくいったこと。
悔しかったこと。
楽しかったこと。
そして、疲れたこと(笑)

そういうものも含めて、 その年のコンテストの記録 だと思っています。

今後、コンテスト結果を見るときには、 「意見・感想」欄を読む楽しみが少し増えそうです 📡😊

🙏 ご対応ありがとうございました
今回の提案を受け止めて対応してくださった、

JARLコンテスト係の皆様、
CTESTWIN作者の堀内さん、
zLogの皆様、

ありがとうございました。
JP1LRT

2026年 第56回 6m AND DOWN コンテストの結果が発表されました ― 2026年10月06日 19時53分18秒

JARL CONTEST / 6m AND DOWN / COMMENTS MATTER
2026 6m AND DOWN コンテスト結果発表
そして「意見・感想」欄について思うこと
第56回 6m AND DOWN コンテストの結果が発表されました。
スコアを見るのはもちろん楽しいのですが、個人的にはもうひとつ、 ぜひ多くの参加局に意識してほしい欄があります。

それが、サマリーシートの「意見・感想」欄です。

2026年 第56回 6m AND DOWN コンテストの結果が発表されました。

参加された各局、お疲れさまでした。

今年も、50MHzを中心に各部門で熱い戦いがありました。

50MHzは、やはり「場所」と「腕」と「執念」の勝負

50MHz関係で見ると、 X50、つまり電信電話部門シングルオペ50MHzバンド は JM1TDG/6 が全国1位。

宮古島からの参加で、見事に2連覇とのことです。

宮古島からの50MHz。
南西諸島から参加する50MHzは、やはり強いです。
もちろん、場所が良いだけで勝てるわけではありません。
その場所を生かし切る運用力があってこそ、全国1位になるわけです。

一方、 C50、つまり電信部門シングルオペ50MHzバンド は JI1ACI が全国1位。

こちらはもう、 「不動の位置」 という感じです。

毎年のように安定して強い局というのは、本当にすごいと思います。

結果ページを見ていて、少し気になったこと

さて、今回の結果ページを見ていて、ひとつ気になったことがあります。

それは、 「意見・感想」の提出が、書類提出局数に比べてかなり少ない ということです。

もちろん、ログを提出するだけでも十分です。
コンテストに参加して、ログを整理して、期限内に提出する。
これだけでも、立派な参加記録です。

でも、せっかく参加したなら、サマリーシートの 「意見・感想」欄 にも、ぜひ何か一言残してほしいなと思います。

たとえば、こんな一言で十分です
・楽しかったです。
・今年はコンディションが良かったです。
・短時間でしたが参加できました。
・移動運用で参加しました。
・交信いただいた各局ありがとうございました。
・次回も参加したいと思います。
・集計ありがとうございます。

本当に、この程度で良いと思います。

長文である必要はありません。
名文である必要もありません。
技術的考察である必要もありません。

その年、その時、そのコンテストに参加した人の一言が残るだけで、 あとから見返した時の面白さがかなり変わります。

ただし、ログソフトの表示が少し分かりにくい

ここで少しややこしいのが、ログソフト側の表示です。

たとえば、zLogではこの欄が 「意見」 と表示されています。

zLog

CTESTWINでも、やはり 「意見」 と表示されています。

CTESTWIN

この「意見」という表記、少し構えてしまう人もいるかもしれません。

「何か要望を書かなければいけないのかな?」
「規約への意見を書かないといけないのかな?」
「苦情や改善提案を書く欄なのかな?」

そう思って、空欄のまま提出している人もいるのではないでしょうか。

ここ、もっと気楽に考えて良いと思います。
JARLの結果ページでは、この欄は 「意見、感想」 として掲載されています。

つまり、ここには 「意見」ではなく「感想」を書いて良い のです。

「感想」で良い。むしろ感想が読みたい。

たとえば、

  • 今年はEスポに助けられました。
  • 移動地は雨でした。
  • 暑くて大変でした。
  • 短時間参加でしたが楽しめました。
  • 初めて6Dに参加しました。
  • 久しぶりに50MHzで楽しめました。
  • アンテナの調子が悪くて伸びませんでした。
  • 来年はもう少し準備して参加したいです。

こういう一言で良いのです。

結果表には、QSO数、マルチ、得点、順位が残ります。
でも、それだけでは分からないことがあります。

スコア表には出ない情報。

その年の空気。
コンディションの印象。
移動運用地の様子。
参加者の疲労感。
初参加のうれしさ。
伸びなかった悔しさ。
それでも参加した楽しさ。

そういうものは、各局の「感想」によって残ります。

数年後に結果ページを見返した時、 「ああ、この年は50MHzが長時間開けたのか」 とか、 「この年は移動運用が雨で大変だったのか」 とか、 「この頃はこういう局が頑張っていたのか」 ということが分かる。

これは、単なるスコア表とは別の価値だと思います。

ログ提出時に、ぜひ一言

というわけで、次回以降コンテストログを提出する時は、 ぜひ「意見・感想」欄にも一言書いてみてはいかがでしょうか。

SUMMARY SHEET COMMENT
今年も楽しめました。
交信いただいた各局ありがとうございました。
次回も参加したいと思います。

これだけで良いと思います。

コメント欄が増えれば、結果ページはもっと面白くなります。
コンテストの記録は、スコアだけでなく、参加者の声も含めて残っていくものだと思います。

参加した記録を、数字だけでなく、言葉でも少し残していきましょう。

まとめ
6m AND DOWN コンテストの結果が発表されました。

X50は JM1TDG/6 が宮古島からの参加で2連覇。
C50は JI1ACI が不動の強さ。

そして、ログ提出時の「意見」欄には、 意見だけでなく感想を書いて良いのです。

ぜひ、次回は一言。
スコアと一緒に、その年の思い出も残しましょう。

73

WSJT-X FreqCal: From Rig Frequency Adjustment to Final Calibration ― 2026年09月29日 19時43分58秒

WSJT-X / FreqCal / PRACTICAL FREQUENCY CALIBRATION
From Rig Frequency Adjustment
to Final Calibration
FreqCal is not only a tool for calculating Slope and Intercept. It can also be used as a very useful measurement tool when adjusting the reference frequency of the radio itself.

This article describes the complete workflow I currently use, including the practical use — and evaluation — of local AM broadcast carriers.

Accurate frequency calibration is particularly important for digital modes such as FT8, and even more so when operating on 50 MHz and above.

WSJT-X includes a very useful tool for this purpose: FreqCal.

A common way to think about FreqCal is:

Measure several known frequencies → calculate Slope and Intercept → Apply.

That works, but I think FreqCal is even more useful if we use it one step earlier.

My preferred sequence is:

1. Warm up the radio.

2. Use FreqCal to observe the current frequency error.

3. Adjust the radio's hardware reference frequency first, if the radio provides such an adjustment.

4. Once the hardware adjustment is finalized, start a fresh FreqCal measurement session.

5. Use several reliable calibration frequencies, including suitable local AM broadcast stations if available.

6. Inspect the collected data before calculating the final correction.

7. Solve for Slope and Intercept and apply the final software correction.

1. Let the radio stabilize first

Do not begin precision adjustment immediately after power-on.

The reference oscillator will normally drift as the radio warms up. In practical amateur use, 30 to 60 minutes may often be sufficient, but I do not consider a fixed number of minutes to be the real criterion.

A better approach is to use FreqCal itself: watch a stable reference signal and confirm that the measured offset has stopped moving consistently in one direction.

The important criterion is stability, not the clock.

2. Use FreqCal to adjust the radio itself first

If your transceiver has an internal reference-frequency adjustment, I recommend correcting the radio itself before relying on software compensation.

On the IC-7300, for example, this is the REF Adjust setting. Other transceivers may use a different name.

Switch WSJT-X to FreqCal mode and receive a reliable reference signal.

During FreqCal operation, WSJT-X tunes the radio so that the reference carrier should appear at approximately 1500 Hz in the audio passband.

For the initial coarse adjustment, I prefer to use the highest reference frequency that can be received reliably at that time.

Why the highest reliable frequency?

A reference-oscillator error expressed in ppm produces a larger absolute error in Hz as frequency increases.

Therefore, the higher-frequency reference usually gives greater sensitivity when making a coarse hardware adjustment.

Adjust the radio's reference until the measured carrier is as close as practical to the expected 1500 Hz position.

This is only the first step. Do not assume that a single frequency proves the radio is perfectly calibrated.

3. Check several frequencies

Once the rough REF adjustment is close, let FreqCal cycle through several reference frequencies.

With a modern synthesized transceiver, the remaining frequency error should approximately follow a straight-line relationship with frequency.

Dial error = Intercept + Slope × f
f = frequency in MHz

This multi-frequency check is important.

A radio may appear almost perfect at one frequency while still showing a residual frequency-dependent error across the band.

If necessary, make a final small adjustment to the radio's hardware reference, then leave it alone.

Important: delete the old fmt.all after changing REF Adjust
Measurements made with different hardware reference settings must not be mixed in the final calibration fit.

Changing REF Adjust changes the radio's actual frequency calibration state. Data measured before and after that adjustment therefore represent different radios, mathematically speaking.

Once the hardware adjustment is finalized:

Delete the previous fmt.all and begin a completely new FreqCal measurement session.

4. Start the final FreqCal measurement

Now the radio's hardware reference is fixed.

Enable Measure and let FreqCal run through the chosen calibration frequencies several times.

In current WSJT-X versions, existing Slope and Intercept correction values are automatically disabled while Measure is active.

Therefore, you do not need to manually set Slope and Intercept to zero before collecting new measurement data.

The measurement results are stored in:

fmt.all

5. Use suitable reference signals

Use only signals that are reliably receivable at your location.

It is not necessary to force every nominal calibration frequency into the measurement. Propagation conditions change, and some frequencies may be weak or unusable at a particular time.

The WSJT-X User Guide also notes that major-city AM broadcast stations can serve well as calibration signals at the low-frequency end of the spectrum.

I agree — they are very useful.

But there is an important practical point.

Use your own local AM stations
The AM frequencies discussed below are examples from my location in Tokyo, Japan.

Do not copy my frequency list simply because it appears here.

Use strong, stable AM broadcast carriers available in your own area.

If you have several suitable AM stations, I think it is perfectly reasonable to include all of them initially.

Then collect several FreqCal cycles and look at the results.

WSJT-X FreqCal measurement example

Example from my station in Tokyo. The AM frequencies shown here are local examples only.

6. Before solving, inspect DF

This is the additional step I now recommend.

Before simply accepting all collected measurements, look at the reported DF values in frequency order.

After the radio's hardware reference has already been reasonably adjusted, the remaining frequency error should normally follow an approximately linear trend with frequency.

For example, if the residual error is increasing with frequency, a higher-frequency reference would generally be expected to continue along that same trend.

If one station at a higher frequency suddenly shows a distinctly smaller deviation than the lower-frequency stations, or otherwise reverses the overall trend, that point deserves closer examination.

Do not immediately assume the station is wrong.

Instead, treat it as a candidate for a sensitivity test: remove that station temporarily, recalculate the calibration parameters, and compare the result.

7. Recalculate with suspicious AM points removed

A practical procedure is:

1. Start with all reliable local AM stations included.

2. Run several FreqCal cycles.

3. Remove obviously unreliable low-SNR measurements and other clear outliers.

4. Solve once using the complete data set.

5. Examine DF in frequency order.

6. If one AM station breaks the overall frequency-dependent trend, temporarily remove it from fmt.all.

7. Solve again.

8. Compare Slope, Intercept and StdDev.

9. If several stations appear questionable, test them individually and in combination.

8. What do Slope, Intercept and StdDev mean?

Slope

Slope is the frequency-dependent part of the error, expressed in ppm.

A smaller absolute Slope means that less residual error grows with frequency.

Intercept

Intercept is the fitted error at 0 MHz, expressed in Hz.

It is not an actual measurement at 0 MHz. It is the intercept obtained by extending the fitted straight line.

StdDev

WSJT-X defines StdDev here as the root mean square deviation of the averaged measurements from the fitted straight line.

In practical terms:

StdDev Meaning
Larger The measured points are more widely scattered around the fitted line
Smaller The measured points agree more closely with a single straight-line model
A small StdDev does not, by itself, prove absolute frequency accuracy.

It tells us how well the selected measurements agree with the fitted model. The reference signals themselves must still be credible.

9. What happened in my Tokyo measurement

At my location, two AM frequencies appeared inconsistent with the overall trend:

  • 594 kHz
  • 1422 kHz

I therefore compared four calibration data sets.

Data set Slope Intercept StdDev
All data +0.029 ppm -0.33 Hz 0.32 Hz
1422 kHz removed +0.019 ppm -0.18 Hz 0.25 Hz
594 kHz removed +0.021 ppm -0.22 Hz 0.30 Hz
594 + 1422 kHz removed +0.004 ppm +0.05 Hz 0.08 Hz
StdDev: 0.32 Hz → 0.08 Hz

Removing both AM frequencies produced a much tighter fit to the remaining calibration data.

The final solution I adopted was:

FINAL CALIBRATION
Slope      +0.004 ±0.001 ppm
Intercept  +0.05 ±0.01 Hz
N         123
StdDev     0.08 Hz
What this does NOT mean
This result does not prove that the transmitters on 594 kHz or 1422 kHz were improperly adjusted.

Possible causes include the actual carrier offset, propagation effects, short-term variation, S/N, fading, receiver effects, and measurement uncertainty.

The justified conclusion is simply:

under my measurement conditions, those two signals were less consistent with the overall calibration trend than the other reference signals.

10. Apply and verify

Once you are satisfied with the data selection and the calculated fit, use Apply to set the resulting Slope and Intercept in WSJT-X.

Then clear Measure and run FreqCal again.

With Measure off, the calibration correction is active, so this gives a useful visual check of the final result.

If you use JTDX with the same radio and the same CAT frequency reference, the same calibration parameters can also be used there.

Summary
Use FreqCal first as a measurement instrument, not merely as a software correction calculator.

Adjust the radio's hardware reference first if possible.

After the hardware adjustment is finalized, delete the old fmt.all and start fresh.

Use several reliable reference frequencies.

As recommended in the WSJT-X User Guide, local AM broadcast carriers can be useful at the low-frequency end.

If several local AM stations are available, it is reasonable to include them all initially.

Then inspect DF and look for stations that do not follow the overall frequency-dependent trend.

Temporarily remove suspicious points, solve again, and compare Slope, Intercept and StdDev.

Do not remove data simply to make the numbers look better — use the recalculation as a consistency test.

FreqCal is much more interesting when used this way.

It is not only a frequency-correction function. It is also a useful tool for understanding the complete frequency behavior of the radio and the reference signals being used to calibrate it.

References
WSJT-X User Guide — Frequency Calibration
https://wsjt.sourceforge.io/wsjtx-main_en.html

WSJT-X Frequency Measurement Tools
https://wsjt.sourceforge.io/FMT_User.pdf

Related Japanese article
https://jp1lrt.asablo.jp/blog/2026/09/29/9879123
JP1LRT
Tokyo, Japan
September 29, 2026

WSJT-X FreqCalの較正点を検証する ― 594 / 1422 kHzを除外するとStdDev 0.08 Hz ― 2026年09月29日 14時53分24秒

WSJT-X / FreqCal / ACTUAL MEASUREMENT
594 / 1422 kHzを除外すると
StdDev 0.08 Hzになった
WSJT-XのFreqCalで周波数較正を実施していたところ、 中波AM放送局の一部が他の較正点と整合しないことに気付きました。

そこで594 kHzと1422 kHzを 「残す/除外する」の4条件で実際に較正パラメータを比較してみました。

昨日から、 WSJT-XのFreqCalを使って、 IC-7300の基準周波数を改めて調整しています。

リグ本体のREF Adjust調整から、 FreqCalを使った最終的なSlope / Interceptの算出までの手順は、 こちらの記事にまとめました。

今回の測定では、 リグ本体のREF Adjustを確定した後、 それ以前に取得したfmt.allを一度削除。

その後はREF Adjustを固定したまま、 FreqCalを数巡させて測定データを蓄積しました。

また、 低S/Nのため行末に*が付いた測定値は除外しています。

ところが、中波帯を見ていて気になる点が
954 kHz、1242 kHzなどは、 全体の周波数依存の傾向に比較的きれいに乗っているのに対し、 594 kHzと1422 kHzは別方向へ外れているように見えました。

そこで、 この2局を較正データに含めるかどうかで 結果がどの程度変化するのか、 4条件で比較してみることにしました。

その前に ― Slope / Intercept / StdDevとは?

WSJT-Xで 「ツール」→「較正パラメータ計算」 を実行すると、 次のような値が表示されます。

  • Slope
  • Intercept
  • N
  • StdDev

何を意味しているのかを簡単に整理します。

Dial error = Intercept + Slope × f
Dial error = 周波数誤差 [Hz]
f = 周波数 [MHz]

Slope(スロープ)

周波数が高くなるにつれて増減する誤差成分を表します。 単位はppmです。

例えば、 Slopeが +0.004 ppm なら、 周波数依存成分だけを見ると、 50 MHzでは、

0.004 × 50 = 0.20 Hz

となります。

Slopeが0に近いほど、 受信周波数が高くなるにつれて誤差が増えていく傾向が小さい ことを意味します。

今回のように、 まずリグ本体のREF Adjustを調整する場合は、 このSlopeに相当する周波数依存の誤差を リグ側でできるだけ小さくしてから、 残差をWSJT-Xで補正することになります。

Intercept(インターセプト)

Interceptは、 直線近似した時の 0 MHzでの切片で、 単位はHzです。

分かりやすく言えば、 Slopeだけでは説明できない 固定的なオフセット成分です。

ただし、 実際に0 MHzを受信して測定しているわけではありません。

複数の周波数で得られた測定値から求めた直線を 0 MHzまで延長した時の値です。

N

Nは、 直線近似に使用された平均化済みの周波数測定値の数 です。

単純なfmt.allの行数ではありません。

同じ周波数で連続して得られた測定値はまとめて平均され、 その平均値が直線近似に使われます。

StdDev

今回、 比較のために特に注目したのが StdDevです。

名前だけを見ると、 一般的な意味での「標準偏差」と思ってしまいますが、 FreqCalで表示されるStdDevは、 もう少し具体的な意味を持っています。

WSJT-X User Guideでは、 StdDevを

“the root mean square deviation of averaged measurements from the fitted straight line”

と説明しています。

つまり、 平均化された各測定点が、 SlopeとInterceptから求められた近似直線から どの程度外れているかを示すRMS値です。

簡単に言えば、

StdDev 意味
大きい 測定点が近似直線から大きく散らばっている
小さい 測定点が近似直線によく揃っている
注意:

StdDevが小さいからといって、 それだけで 「絶対周波数が正しい」 ことを保証するわけではありません。

誤った基準信号だけがきれいに一直線に並んでいても、 数学的には小さなStdDevが出る可能性があります。

したがって、 基準信号そのものが信頼できるかという確認も重要です。

「±」の数字

SlopeとInterceptの後ろに表示される ±の値は、 それぞれの推定不確かさです。

例えば、

Slope: +0.004 ±0.001 ppm

なら、 今回の直線近似から求められたSlopeが +0.004 ppmで、 その推定不確かさが0.001 ppmという意味です。

① 全周波数を使用

全周波数
Slope: +0.029 ±0.003 ppm
Intercept: -0.33 ±0.03 Hz
N: 170
StdDev: 0.32 Hz

まず、 594 kHzと1422 kHzを含めた、 すべての有効測定点を使用しました。

WSJT-Xの判定そのものは 「較正良好」です。

しかし、 StdDevは 0.32 Hz となりました。

② 1422 kHzだけを除外

1422削除
Slope: +0.019 ±0.003 ppm
Intercept: -0.18 ±0.03 Hz
N: 146
StdDev: 0.25 Hz

1422 kHzだけを除外すると、 StdDevは、

0.32 Hz → 0.25 Hz

へ改善しました。

1422 kHzの測定点が 今回の近似直線との整合性をかなり悪化させていることが分かります。

③ 594 kHzだけを除外

594削除
Slope: +0.021 ±0.003 ppm
Intercept: -0.22 ±0.04 Hz
N: 147
StdDev: 0.30 Hz

今度は逆に、 594 kHzだけを除外しました。

StdDevは、

0.32 Hz → 0.30 Hz

です。

594 kHzも影響していますが、 今回のデータでは 1422 kHzの方がより強く近似結果を崩しているようです。

④ 594 / 1422 kHzを両方除外

594/1422削除
Slope: +0.004 ±0.001 ppm
Intercept: +0.05 ±0.01 Hz
N: 123
StdDev: 0.08 Hz

最後に、 594 kHzと1422 kHzを 両方とも除外しました。

すると、 StdDevが一気に、

0.32 Hz → 0.08 Hz

まで低下しました。

さらにSlopeも、

+0.029 ppm → +0.004 ppm

となり、 ほぼゼロに近づきました。

4条件を比較

条件 Slope Intercept StdDev
全周波数 +0.029 -0.33 0.32 Hz
1422除外 +0.019 -0.18 0.25 Hz
594除外 +0.021 -0.22 0.30 Hz
594 / 1422除外 +0.004 +0.05 0.08 Hz

この結果から何が分かるか

今回の測定条件では、 594 kHzと1422 kHzの測定値が、 他の較正点が作る直線から系統的に外れていました。

594 kHzだけを残すと StdDev 0.25 Hz。

1422 kHzだけを残すと StdDev 0.30 Hz。

両方とも除外すると 0.08 Hzまで改善しました。

ただし、ここは重要
この結果だけを見て、 「594 kHz局と1422 kHz局の送信周波数がずれている」 と断定することはできません。

送信側の周波数偏差、 伝搬経路による周波数変動、 受信条件、 その他の要因が含まれる可能性があります。

今回確認できた事実は、 この測定条件では、 594 kHzと1422 kHzを較正点として含めない方が、 他の測定点との整合性が大幅に向上した ということです。

AM放送局をFreqCalに使う時の注意

WSJT-XのUser Guideでも、 大都市圏のAM放送局は 低い周波数側のFreqCal用基準として利用できると紹介されています。

実際、 AM局は強力かつ常時受信できることが多く、 非常に便利です。

ただし今回の測定からも分かるように、

公称周波数だからといって、 サブHz精度の絶対基準として無条件に採用しない
複数のAM放送局と、 5 / 10 / 15 / 20 MHzなどの 他の基準信号を比較し、

全体の傾向から明らかに外れていないか を見ることが重要です。

特に今回のように、 0.1 Hz単位まで見始めると、 「無線機の誤差」だけではなく、 基準として使っている信号側の差まで 見えてくる可能性があります。

今回採用した最終値

以上の比較から、 今回は594 kHzと1422 kHzを 較正点から除外した結果を採用しました。

FINAL CALIBRATION
Slope      +0.004 ±0.001 ppm
Intercept  +0.05 ±0.01 Hz
N         123
StdDev     0.08 Hz

この較正式を50 MHzに当てはめると、

0.05 + 0.004 × 50
= 約0.25 Hz

となります。

もちろん、 これはGPSDOや高精度周波数カウンターを使用した 研究所レベルの絶対周波数校正ではありません。

電離層伝搬、 フェージング、 Doppler、 受信機内部温度などの影響も存在します。

それでも、 通常のアマチュア無線局で、 特別な測定器を使わず、 この程度まで追い込めれば、 FT8などの実運用上は十分だと思います。

今回の教訓
・FreqCalでは、 *付きの低S/Nデータだけを見ればよいわけではない。

・測定値が正常に見えても、 較正点そのものが他の周波数と整合しているか確認する。

・Slopeは周波数依存の誤差。

・Interceptは直線近似の固定オフセット成分。

・StdDevは、 各測定点が近似直線からどの程度散らばっているかを見る指標。

・今回の測定では、 594 / 1422 kHzを除外することで StdDevが0.32 Hzから0.08 Hzへ改善。

・最終的に Slope +0.004 ppm、 Intercept +0.05 Hz を採用した。

FreqCalは、 単に 「無線機の周波数を合わせる機能」 として使うだけでも便利ですが、

こうして測定値を比較していくと、 リグ、 伝搬、 基準信号、 直線近似の関係まで見えてくる ので、 なかなか面白いツールです。

JP1LRT
2026年9月29日

WSJT-X FreqCalでリグの周波数を本気で合わせる ― IC-7300 / FT-991Aの基準周波数調整からJTDXまで【2026年版】 ― 2026年09月28日 19時47分05秒

WSJT-X FreqCal / FREQUENCY CALIBRATION / 2026 UPDATE
FT8のDF、本当に同じ周波数を見ていますか?
WSJT-XのFreqCalを使えば、 周波数の正確な基準信号を利用して、 リグの周波数誤差をかなり細かく確認できます。

さらにIC-7300やFT-991 / FT-991Aのように 基準周波数を調整できるリグなら、 まずリグ本体をできるだけ正しく合わせ、 その後に残ったわずかな誤差だけを WSJT-X / JTDXで補正することができます。

FT8などを運用していると、 「○○局はDF 850付近に出ています」 といった情報交換をすることがあります。

ところが同じ局を受信しているはずなのに、 局によって表示されるDFが数Hz、 場合によってはそれ以上違っていることがあります。

原因の一つが、 無線機の基準周波数の誤差です。

特に50 MHzでは無視しにくい
基準発振器が1 ppmずれていれば、 10 MHzでは約10 Hz、 20 MHzでは約20 Hz、 50 MHzでは約50 Hzの誤差になります。

HFではあまり気にならなかったわずかなppm誤差も、 6mではかなり目立ってきます。

私はこれまで、

という記事を書いてきました。

今回は2026年9月にもう一度実際に測定し直しながら、 現在のWSJT-Xの仕様と実測で分かった点を含めて、 手順を最初から整理し直します。

今回の考え方 ― FreqCalを二段階で使う

STEP 1
リグ本体を調整
FreqCalとワイドグラフを、 リグの周波数誤差を見る測定器 として使います。
STEP 2
残った誤差をソフトで補正
本体調整後にFreqCalを改めて取り直し、 スロープ/インターセプト を求めます。
まずリグそのものをできるだけ正しくする。
その後で、残ったわずかな誤差だけを ソフトウェアで補正する。

最初に重要 ― 十分にウォームアップする

周波数調整は、 電源を入れてすぐに行ってはいけません。

リグ内部の基準発振器は温度の影響を受けます。 電源投入直後は内部温度が変化しているため、 その状態でぴったり合わせても、 温まった後には再びずれてしまう可能性があります。

「30分」「1時間」という数字そのものより、 ドリフトが落ち着いたことが重要
実用上は少なくとも30分程度、 できれば1時間程度動作させてから始めるのがよいと思います。

ただし、本当の判断基準は時間ではありません。 FreqCalで同じ基準信号をしばらく観測し、 ワイドグラフ上の位置が時間とともに 一方向へ動き続けなくなったことを確認します。

私は以前の記事では2時間程度ウォームアップしてから行った例も紹介していますが、 今回の再測定では約30分観測し、 基準信号の位置がほぼ安定したことを確認してから調整を開始しました。

どの周波数を使うか

FreqCalには、 周波数が分かっている安定したキャリア信号を使います。

日本であれば、 地元の中波AM放送局や、 5 MHz、10 MHz、15 MHz、20 MHzなどを利用できます。

全部受信できる必要はありません
15 MHzや20 MHzは時間帯や電離層の状態によって、 十分なS/Nで受信できないことがあります。

例えば20 MHzが良好なら20 MHz、 20 MHzが使えず15 MHzが良好なら15 MHz。

その時点で安定して測定できる周波数だけを使えばよい ということです。

今回の測定でも、 ある時間帯の15 MHzはS/Nが低く、 測定値が大きくばらついていました。 一方で20 MHzは非常に安定して受信できていました。

逆のことが起きる日も当然あります。

STEP 1 ― まずリグ本体を合わせる

1.FreqCalにする

WSJT-Xのメニューから、

「モード」→ FreqCal

を選びます。

2.使用する周波数を確認する

「ファイル」→「設定」→「周波数」

へ進み、 「運用周波数」の中からFreqCal用の周波数を確認します。

必要に応じて、 受信可能な地元AM放送局などを追加します。

3.「測定」をONにする

メイン画面の「測定」にチェックを入れます。

旧記事からの重要な変更点
現行WSJT-Xでは、 「測定」中は設定済みの周波数較正補正が無効になります。

したがって、 以前の記事で行っていたように、 測定前にスロープ/インターセプトを 手作業で0へ戻す必要はありません。

4.安定して測定可能な最高周波数でまず粗調整

ここは今回の再測定で、 以前よりも分かりやすい手順だと感じた部分です。

まず、 その時点で安定して受信できる基準信号のうち、 最も高い周波数を受信します。

基準発振器のppm誤差は、 周波数が高いほどHz換算で大きく現れます。

周波数 0.1 ppmの誤差
5 MHz 0.5 Hz
10 MHz 1 Hz
20 MHz 2 Hz
50 MHz 5 Hz

したがって、 高い周波数の方がREF Adjustを動かした時の変化を確認しやすくなります。

今回私は20 MHzが良好に受信できていたので、 まず20 MHzだけを見ながら IC-7300のREF Adjustを少しずつ動かしました。

1500 Hzに最も近くなった値は、 今回の私のIC-7300では 39.2%でした。

これは私の個体の値です。

2021年の記事を書いた時は34.5%でした。 今回39.2%だったからといって、 他のIC-7300を39.2%にすればよいという意味ではありません。

必ず自分のリグを実測して決めてください。

また、 20 MHzを1500.000 Hzへ完全一致させること自体が目的ではありません。

ここではあくまで、 FreqCalを始める前の粗調整です。

5.FreqCalを一巡させて全体を見る

粗調整ができたら、

「ツール」→「周波数較正実行」

を選びます。

WSJT-Xは、 設定したFreqCal用周波数を 30秒ずつ順番に受信していきます。

正しく較正されたリグなら、 基準信号はワイドグラフ上の 1500 Hz付近に現れます。

調整前 ― 周波数が高くなるほどズレる

FreqCal 調整前

2021年の測定例。 受信周波数が高くなるにつれ、 1500 Hzからのズレが大きくなっています。

この状態は非常に分かりやすい例です。

低い周波数では1500 Hz付近に見えていても、 周波数を上げるにつれて 中央からのズレが大きくなっています。

基準発振器そのものにppm単位の誤差があると、 このように誤差が周波数に比例して大きくなります。

一つの周波数だけを見て 「合った」と判断しないこと。

複数の周波数を見て、 周波数が高くなるにつれて 一方向へズレが増えていく傾向 を確認することが重要です。

6.リグ本体の基準周波数を微調整する

IC-7300なら、 REF Adjustを少しずつ動かします。

IC-7300 REF Adjust

IC-7300のREF Adjust。 画像は2021年当時のものです。

ここでの目標は、 一つの周波数だけを1500 Hzへ合わせることではありません。

調整の目標
5 MHz、10 MHz、15 MHz、20 MHzなどを見た時に、 周波数が高くなるほど 1500 Hzからのズレが増える傾向を できるだけ小さくすることです。

後でWSJT-Xが数値として求める 「スロープ」を、 この段階ではREF Adjustによって リグ本体側でできるだけ小さくしている、 と考えると分かりやすいでしょう。

7.周波数を変えても1500 Hz付近に集まることを確認

FreqCal 基準周波数調整後

基準周波数調整後。 各周波数で基準信号が概ね1500 Hz付近へ集まっています。

このように、 周波数を切り替えても 基準信号が概ね1500 Hz付近へ集まるようになれば、 リグ本体の調整はほぼ終了です。

完全に一本の線へ重なる必要はありません。

実際の受信信号には、 電離層伝搬による周波数変動、 フェージング、 マルチパス、 S/N、 リグ内部温度の微小変化なども影響します。

基準信号側も盲信しない

地元のAM放送局は、 低い周波数側の測定点として非常に便利です。

ただし、 公称周波数に対して すべての送信局がサブHzまで完全一致している、 と最初から決めつけるのもよくありません。

今回の実測では、 594 kHz、954 kHz、1242 kHzと比較して、 1422 kHzだけが異なる方向の安定した偏差を示しました。

これだけで 「1422 kHzの送信局がずれている」 と断定することはできません。

しかし、 一つの測定点だけが全体の傾向から外れている場合、 その一点に合わせてREF Adjustを動かさない ことが重要です。

複数のAM局、 5 / 10 / 15 / 20 MHzなどを見て、 全体として整合しているかを判断します。

FreqCalは 「一つの正しそうな信号へ無線機を無理に合わせる」 ためのものではありません。

ここが非常に重要 ― REF Adjust確定後にfmt.allを捨てる

REF Adjustを変更しながら取得した fmt.allは、最終較正には絶対に混ぜない
REF Adjustを動かすたびに、 リグの基準周波数そのものが変化します。

つまり、 REF Adjust変更前、 調整途中、 調整後の測定値は、 同じ条件で測定したデータではありません。

REF Adjustが確定した時点で、 それまでの測定データを一度捨て、 固定したREF Adjustの状態から 改めてFreqCalを取り直します。

今回の再測定で、 まさにこれを実際に経験しました。

低S/Nを示す「*」付きデータを削除したにもかかわらず、 「較正パラメータ計算」を実行すると、

Calibration Error
Check fmt.all for possible bad data.

というエラーになりました。

原因は、 REF Adjustを変更する前と変更した後のデータが 同じfmt.allに残っていたことでした。

異なる基準周波数状態の測定値を一緒に直線近似すれば、 当然ばらつきは大きくなります。

REF Adjustを確定した後のデータだけにしたところ、 正常に「較正良好」となりました。

REF Adjust決定
↓
それまでのfmt.allを削除
↓
REF Adjustを固定
↓
本番のFreqCalを最初から取り直す

STEP 2 ― 調整済みリグで本番のFreqCal

1.fmt.allを削除

「ファイル」→「ログディレクトリを開く」

からログディレクトリを開き、 それまでのfmt.allを削除します。

2.REF Adjustはもう触らない

ここから先は、 決定したREF Adjustを固定します。

今回の私のIC-7300では 39.2%で固定しました。

3.「周波数較正実行」を改めて開始

「ツール」→「周波数較正実行」

を実行し、 「測定」をONにします。

今度はREF Adjustを一切変更せず、 同一条件のまま数巡測定します。

4.fmt.allを確認する

測定後、 fmt.allをテキストエディタで確認します。

明らかに外れた測定値や、 受信状態が悪かった測定値は除外します。

「*」の意味
FreqCalでは、 S/Nが20 dB未満の測定値に 行末の*が付きます。

以前の記事では 「*付きデータを削除」 と簡単に書きましたが、 正確には 低S/Nのため信頼性を確認すべき測定値 という意味です。

*があるから数学的に必ず無効、 *が無いから必ず正しい、 という意味ではありません。

*の有無だけではなく、 周囲の値から大きく外れた測定値も確認します。

5.「較正パラメータ計算」

「ツール」→「較正パラメータ計算」

を実行します。

WSJT-Xは、 複数の周波数で得られた誤差から、 次の直線を求めます。

Dial error = A + B × f
A = インターセプト [Hz]
B = スロープ [ppm]
f = 周波数 [MHz]

大まかには、

  • インターセプト: 周波数に依存しない固定的な誤差成分
  • スロープ: 周波数が高くなるほど増える比例誤差成分
少し技術的な話
現行WSJT-Xのcalibrate.f90では、 fmt.allの測定値を周波数ごとに平均し、 その後スロープとインターセプトを直線近似します。

さらに現在のGUI側では、 そのfitのRMSが1 Hzを超えると 「Check fmt.all for possible bad data.」 というCalibration Errorになります。

今回、REF Adjust変更前後のデータを混在させた時に このエラーが出た理由もこれです。

今回の実測結果

REF Adjustを39.2%に固定し、 それ以前の測定データを除外した上で FreqCalを取り直した結果、 次の「較正良好」が得られました。

2026年9月28日 実測
Slope +0.046 ±0.008 ppm
Intercept -0.39 ±0.07 Hz
N 58
StdDev 0.39 Hz

この結果を20 MHzへ当てはめると、

-0.39 + 0.046 × 20 ≒ +0.53 Hz

となります。

実際に20 MHzで観測していた偏差も およそ+0.52~+0.54 Hz程度でしたので、 計算結果ともよく一致しています。

6.「較正良好」ならApply

計算結果が正常なら、 「較正良好」のダイアログが表示されます。

結果を確認して Applyを押します。

すると、

「ファイル」→「設定」→「周波数」→「周波数較正」

の スロープ/インターセプト へ値が反映されます。

7.最後に「測定」をOFFにして確認

FreqCalモードのまま、 「測定」のチェックを外します。

「測定」を外すと、 設定された周波数較正値が有効になります。

再度「周波数較正実行」を行い、 各基準信号が1500 Hz付近に現れることを確認します。

JTDXにも同じ値を設定

JTDXにも、 周波数較正用の スロープ/インターセプトを設定する項目があります。

同じリグを使用するのであれば、 WSJT-Xで求めた値をJTDXにも設定します。

これによって、 リグ側にわずかな残留誤差があっても、 WSJT-X / JTDXで正しいDF表示に近づけることができます。

IC-7300だけの方法ではありません

この方法はIC-7300だけに限定したものではありません。

ユーザーが基準周波数を調整できるリグなら、 基本的には同じ考え方が使えます。

リグ 基準周波数調整
ICOM IC-7300 REF Adjust
YAESU FT-991 / FT-991A REF FREQ ADJ

FT-991 / FT-991Aなら、 IC-7300のREF Adjustを動かした段階で REF FREQ ADJを調整すればよいわけです。

スマートフォンのAF発振器などを使う方法との違い

スマートフォンの音声発振器などを使って、 受信音との周波数差を見ながら 基準周波数を調整する方法もあります。

簡便な方法としては十分意味があります。

ただ、 PCとWSJT-Xを使える環境であれば、 私はFreqCalを利用する方法を勧めます。

FreqCalの大きな利点は、 一つの周波数だけを合わせるのではなく、 複数の既知RF周波数を比較できることです。

周波数が高くなるほど誤差が増える傾向を ワイドグラフで視覚的に確認でき、 さらに最終的には スロープ/インターセプトとして 定量的に評価できます。

これは「絶対周波数標準器による校正」ではありません

ここで紹介している方法は、 GPSDOや高精度周波数カウンターなどを使用した 研究所レベルの絶対周波数校正ではありません。

受信する信号には、 電離層伝搬によるDoppler、 フェージング、 マルチパス、 S/Nの変化なども含まれます。

したがって、 1 Hz以下の数字を見て 意味なく追い込み続けるものではありません。

この方法の目的は、 特別な測定器を使わず、 アマチュア無線の実運用に十分な範囲まで リグの周波数誤差を小さくすること です。

まとめ

  1. リグを十分にウォームアップする
  2. FreqCalでドリフトが落ち着いたことを確認する
  3. その時点で安定して測定できる最高周波数で REF Adjustを粗調整する
  4. 「周波数較正実行」で複数周波数を見て、 高い周波数ほどズレる傾向を確認する
  5. REF Adjust / REF FREQ ADJを微調整し、 その傾向を最小にする
  6. REF Adjustを確定する
  7. ここで、それまでのfmt.allを必ず削除する
  8. REF Adjustを固定したまま、 改めてFreqCalを数巡実行する
  9. 低S/Nや外れ値をfmt.allから確認・除外する
  10. 「較正パラメータ計算」を実行する
  11. 「較正良好」ならApplyする
  12. 必要なら同じスロープ/インターセプトを JTDXにも設定する
まずリグそのものをできるだけ正しくする。
そして最後に残ったわずかな誤差だけを ソフトウェアで補正する。

そのためにFreqCalを 「測定器」と「補正値計算」の 二つの用途で使います。

特に50 MHzのように、 わずかなppm誤差が数Hz~数十Hzの差として見えるバンドでは、 一度確認してみる価値はあると思います。

ご注意

リグ本体の基準周波数調整を変更する場合は、 必ず各リグの取扱説明書を確認してください。 設定変更はご自身の責任で行ってください。

この記事で示したREF Adjustの数値は 私の個体での測定例であり、 他の個体にそのまま適用するための値ではありません。
参考資料
WSJT-X User Guide
https://wsjt.sourceforge.io/wsjtx-main_en.html

WSJT-X Frequency Measurement Tools
https://wsjt.sourceforge.io/FMT_User.pdf

WSJT-X source ― calibrate.f90
calibrate.f90

WSJT-X source ― freqcal.f90
freqcal.f90

旧記事:JTDX WSJT-X の周波数較正
https://jp1lrt.asablo.jp/blog/2020/10/28/9310527

旧記事:IC-7300 基準周波数調整
https://jp1lrt.asablo.jp/blog/2021/03/02/9352207

旧記事:Rig frequency calibration
https://jp1lrt.asablo.jp/blog/2024/08/31/9713282
JP1LRT / 2026年9月

WS – Digital Mode Suite 日本語User Guideを本気でレビューしてみた ― 69箇所修正、その日のうちに正式公開 ― 2026年09月27日 22時48分47秒

2026年9月27日
WS – Digital Mode Suite 日本語User Guideを本気でレビューしてみた
― 69箇所修正、その日のうちに正式公開

今日、DG2YCB/Uweから、

「日本語版のWS User Guideも見てもらえる?」

という連絡をもらいました。

せっかくなので、単なる誤字脱字のチェックで終わらせるのではなく、 英語版と日本語版のHTMLを比較しながら、かなり本気でレビューしてみることにしました。

対象は WS – Digital Mode Suite の日本語User Guide。

単なる「日本語の校正」ではありません

今回は英語版と日本語版を比べるだけではなく、 実際の WS 3.2.1のGUI、source code、日本語translation(.ts) とも照合しました。

確認したのは、例えばこんなところです。

  • 英語原文との意味の一致
  • 実際のGUI表示との用語統一
  • 未翻訳の英語が残っていないか
  • 日本語表記の揺れ
  • 不自然な日本語や誤訳
  • 現在のsource codeとの食い違い
  • HTML構造を壊していないか

最終的に、69箇所を修正しました。

例えばこんなところを修正

修正前 修正後
Falseデコードを軽減 誤デコードを低減
WS-MAPを占有 WS-MAP操作権を取得
ダイアル周波数 ダイヤル周波数
フィルター(software機能) フィルタ

「全部日本語にすればいい」のか?

ここは今回、ちょっと考えさせられたところです。

個人的には、 「Falseデコード」 の方が、なんとなくデジタルモードっぽくて格好いいと思っています(笑)。

同じように、

Low / Medium / High
Early / Normal / Late

のような短い技術用語も、英語のままで十分意味が通りますし、 技術系softwareではむしろその方が分かりやすい場合もあります。

しかも、今回User Guide側を合わせた日本語UIは、 その少し前に自分もレビューを手伝ったものです。

日本語UIをレビュー
↓
User Guideを確認
↓
「GuideとUIの表記が違う」
↓
GuideをUIに合わせる

……ある意味、自分で自分の首を絞めました(笑)

UIをレビューした時点で、 「これは英語のまま残す方がいいのでは?」 と、もう少し細かく考えておけばよかったかな、とも思いました。

でも、日本語UIを必要としている人の立場で考えると……

そこで、もう一度考えてみました。

自分には英語のままで分かったとしても、 日本語UIを使う人すべてがそうとは限りません。

むしろ、

「英語だと分かりにくいから日本語UIを使っている」

という方も当然たくさんいるはずです。

英語UI 日本語UI
Low / Medium / High 低 / 中 / 高
Early / Normal / Late 早め / 標準 / 遅め
False decode 誤デコード

そう考えると、日本語化する意味は十分にあります。

ローカライズは、
「自分ならどちらが格好いいか」ではなく、
「その言語のUIを必要としている人にとって、どちらが分かりやすいか」。

もちろん、CQ、FT8、DXCC、LoTWのように、 無理に日本語へ置き換えない方がいい言葉もあります。

「訳せるものは全部訳す」でもなければ、 「技術用語だから全部英語のままでいい」でもない。

その境界を考えるのも、localizationの面白いところだと思います。

日本語を見ていたら、英語Guide側の問題まで見つかった

User Guideを詳しく調べていくと、 日本語訳とは別に、英語Guideやsource側の古い記述と思われる部分もいくつか見つかりました。

例えば、現在のmain windowには以前のような 「Call 1st」checkbox はありません。

現在は、

CQ: None
CQ: First
CQ: Max Dist
CQ: Max dB
CQ: Min dB

というCQ selectorを使う実装になっています。

ところが、一部の設定説明やkeyboard shortcut helpには、 まだ「Call 1st checkbox」という以前の表現が残っていました。

また、3.2.1で動作が変更された “Highlight all messages” についても、User Guide側には旧仕様と思われる説明が残っていることを確認。

こういうところは、日本語だけ勝手に書き換えるべきではありません。

そこで今回は、

1. 日本語User Guideそのものの問題
2. applicationの日本語translation側の問題
3. 英語Guide / source側の問題

と分けてUweへ報告しました。

AIにも独立チェックさせてみた

修正版については、自分の判断だけで完結させず、 AIにも独立してチェックを依頼しました。

「こちらの判断に合わせてくれ」ではなく、 誤訳、過剰修正、見落としがないかを疑って調べてもらう形です。

実際にこちら側の見落としも見つかり、再確認・修正したうえで最終版を作成。

HTMLについても、ID、anchor、link、table、 そして埋め込み画像40枚が壊れていないことを確認しました。

そして、その日のうちに公開

最終版をUweへ送ったところ……

“Thanks, Yoshi! It should now be online”

73 de DG2YCB,
Uwe

仕事が速い(笑)。

今日のうちに、そのまま公開されました。

念のため、公開後のHTMLを自分でもダウンロードして、 こちらから送った最終版と比較しました。

byte-for-byte identical
SHA-256も完全一致

つまり、こちらでレビューした日本語版が、 そのまま正式公開されたことを確認できました。

今日一日で

レビュー依頼
↓
英語版/日本語版比較
↓
GUI・source・translationとの照合
↓
修正
↓
独立チェック
↓
Uweへ送付
↓
正式公開

まで全部終了。

なかなかのスピード感でした(笑)。

翻訳というより「整合性を取る仕事」

こういう作業は、単純に英文を日本語へ置き換えるだけではありません。

英語原文
↓
日本語
↓
実際のGUI
↓
source code
↓
User Guide

を行ったり来たりしながら、 全体の整合性を取っていく作業なのだと思います。

そして今回、改めて感じたのは、

「自分には英語のままで分かる」ことと、
「日本語版を必要としている人に分かりやすい」ことは別。

ということでした。

地味ですが、こういう作業は結構好きです(笑)。

あとはどこかに、

Japanese review: JP1LRT

くらいクレジットが入ったら、もっと嬉しかったんだけどなあ(笑)。
まあ、それは次の機会に。