より良いリグが欲しい、でも動けない — 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 ケーブル、あの慣れ切ったメニュー画面。これらすべてを「越境コスト」として勘定に入れたとき、買い替えという行為の重みが初めて見えてくる。リグ選びは、単体の数字を比べる作業ではなく、アンテナ、受信環境、周辺機器、操作感まで含めたシャック全体の総合力をどう設計するか、という問題でもある

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

救えるログ、取り戻す"思い出" — 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



第41回1エリアAMコンテスト 結果発表2026年02月03日 09時08分22秒


第41回1エリアAMコンテスト 結果発表


2025年12月21日(日)に開催しました「第41回 1エリアAMコンテスト」の結果を発表いたします。

ログ提出局数は138局でした。多数のご参加ならびにログのご提出、誠にありがとうございました。心より御礼申し上げます。
昨年より18局増となりました。ありがとうございます。
なお、提出ログの得点については、主催者側で再点検(再計算)を行っております。
計算誤り等が確認された場合は、規約に基づき加点・減点の修正を行っておりますので、あらかじめご了承ください。

結果は上記URLからご確認ください。入賞の皆様、およびログをご提出いただいた皆様には、PDFの賞状・参加証をご用意いたしました。

第41回1エリアAMコンテスト 現在までのログ受付状況2026年01月25日 16時18分05秒

第41回1エリアAMコンテスト 現在までのログ受付状況

2026年1月25日14時30分現在  https://6mnet.jp/mannaka/blog/archives/362

締切まで一週間を切りました。 1局でもQSOされた方は是非ご提出をよろしくお願いいたします。


📡 hamlog-supercheck-builder v0.2.0 をリリースしました(コンテスト運用者向け)2026年01月09日 20時41分17秒

📡 hamlog-supercheck-builder v0.2.0 をリリースしました(コンテスト運用者向け)
HAMLOG スーパー チェックリスト生成をより正確に、柔軟に、運用実務に寄せてアップデートしました。

🔧 主なアップデート
• マージ方式を GUI で選択可能に
• 上書き(CSV優先)
• 追加(既存優先・空欄のみ補完)
• 併記(既存+CSV)=同一コールでも複数 QTH を複数行で出力
• 不完全行の整理(ON/OFF 可)
CALLのみ/都道府県2桁のみ → CSVに完全情報があれば補完、なければ削除
• 詳細優先クリーンアップ(ON/OFF 可)
例: 09003 と 09003J → より詳細な 09003J を採用
完全な JCC/JCG があれば、都道府県2桁行局を削除
• 上書き時の詳細度チェック(ON/OFF 可)
既存の方が詳細なら既存を保持(例:29012A を保護)
• マージ結果レポート TXT を出力可能(任意)

コンテストのスーパー チェック生成で「既存データを壊したくない」「詳細度の整合性を保ちたい」という運用者のニーズに応える更新です。


最新版の supercheck_builder.exe は GitHub Releases からダウンロードしてください:
https://github.com/jp1lrt/hamlog-supercheck-builder/releases/latest

📣【コンテスト勢のみなさんへ】2025年12月29日 22時45分56秒

CTESTWIN / zLog を使ってる方、**スーパーチェック(パーシャルチェック)**使ってますか?
これ、地味だけど めちゃ効く仕込み です

既に使ってる方には耳タコですからごめんなさい
■ スーパーチェックって何?
 事前に用意した「局リスト(常連局・最近QSOした局など)」を
CTESTWIN / zLog に読み込ませておく機能です。
 コールを打ってる途中から
「候補局がズラッと出てくる」あれです!
■ 実戦メリット(これが効く)
 誤記・呼び間違いが減る
似たコールが多い時間帯ほど効果大!
「それじゃない!」に早めに気づけます
 S&P が速くなる=拾いが増える
数文字で候補が出るので、判断が早い
結果的に取りこぼしが減ってスコアが伸びやすい
 テンポが崩れにくい(レート維持)
確認・迷い・打ち直しが減る=運用がスムーズ
長時間運用ほど差が出ます
 “出てきそうな局”が見える
常連局・復活局・最近交信した局が候補に出ると
「今いるかも?」が見えて探しやすい
 後処理もラク
誤記が減る=ログ修正が減る
提出前の整理も楽になります
■ 国内コンテストだとどうする?
国内向けは、基本的に
 自分で作る or  友人からもらう
って感じになりがち(JCC/JCG と相性◎)ですよね。
 ちなみに海外コンテストなら…
 supercheckpartial.com から
Super Check Partial Database Files が入手できます!
 https://www.supercheckpartial.com/
 そこで配布されている master.scp などの “.scp系” は、配布側の説明では Win-Test / N1MM+ 向け とされていることが多いです。CTESTWINでは読み込めて使用できました。きっとzLogでも?
■ 今回:国内向けを作るのが面倒だったのでツール作りました(笑)
Turbo HAMLOGから出力させる CSV から
 国内局(JCC/JCG が入ってる行)だけ拾って
 既存リストとマージ → ソート → 重複削除
して、チェックリストを作れる簡易ツールです
補足:
 .spc で出力したものは拡張子を .pck に変えるだけで CTESTWIN で使えます(逆も同様に運用可)
■ まとめ
スーパーチェックは派手じゃないけど
 ミス減
 拾い増
 テンポ維持
に直結するので、コンテストではかなり効きます
まだ使ってない方は、一度入れてみると体感できると思います


1エリアAMコンテスト(1AM)】開催日アンケート(2026年)2025年12月29日 09時36分05秒


【1エリアAMコンテスト(1AM)】開催日アンケート(2026年) — 2026年の開催日、どちらが参加しやすいですか? — ※アンケート締切:2026/1/3(土)23:59(JST) 1エリアAMコンテスト(1AM)は、皆さんのおかげで 41回連続で開催できています。本当にありがとうございます。 そして 2023年から私が主催を引き継いで以降、ありがたいことに「結果発表が劇的に早くなった!」という評価も多くいただいています。 ※なお 2025年分は、まだ結果発表前ですが、並行して「来年以降さらに良くする」ための改善も進めたいと思っています。 主催者として次に目指したいのは、 さらに参加しやすく、皆が楽しめるコンテストにすること。 そして「年内最後にこれに出て締めくくる」――そんな印象を持ってもらえる恒例行事に育てたいと思っています。 その第一歩として、2026年の開催日について皆さんの実感を教えてください。 第4日曜(12/27)に寄せると「年末で忙しくて出られない」方が増えるかもしれません。 一方で「年末休みに入っていて、逆に参加しやすい」という方もいるはずで、主催者の想像だけでは決めきれません。 さらに運営面では、来年以降 ログ提出期限を少し早めることも検討しています(集計〜結果発表をよりスムーズにするため)。この点についてもご意見があればぜひお寄せください。 投票だけでも大歓迎ですし、理由や事情は この投稿へのコメントでも、または コンテストログ提出先メール(1am_test(あっとまーく)6mnet.jp)宛に送っていただいてもOKです(短文でも大丈夫です) ※メールの場合、件名に「開催日アンケート」と入れていただけると助かります。 【投票】2026年、参加しやすい開催日は? A:12/20(第3日曜・年末前) B:12/27(第4日曜・年末寄り) C:どちらでもOK D:年によって調整が良い(例:年末に近い年は前倒し 等) 最後にひとこと: ぜひ“年末の挨拶代わり”に、1局でも交信したら参加してみてください!

第41回1エリアAMコンテスト2025年12月22日 16時17分02秒

第41回 1エリアAMコンテストにご参加いただき、誠にありがとうございました。
現在、ログの集計作業を進めております。

規約には

【提出書類】 JARL推奨旧フォーマット R1.0
【提出先】 1am_test(あっとまーく)6mnet.jp
※2023年度より電子メールのみの受付となっております。
添付ファイルではなく、メール本文に貼り付けてお送りください。

と明記しておりますが、今年も R1.0 以外の形式 で提出された方、添付ファイルで送付された方 が数名いらっしゃいました。
また、
「1. 移動局は移動場所・使用電源を明記してください」
という規定についても、記載漏れが見受けられました。
今年については、主催者側で確認のうえ、必要事項を補足・訂正させていただきました。
ただし、スムーズな集計のためにも、来年度以降は規約に沿った形式でのご提出にご協力いただけますと幸いです。
引き続き、結果発表まで今しばらくお待ちください。

また随時ログの受付状況についても公開しています。

第41回1エリアAMコンテスト 現在までのログ受付状況



サバイバルマラソンコンテスト2025年11月13日 08時24分50秒

2m SSB の祭典、サバイバルマラソンコンテストが開催中です。


おいおい!!   ちょっと待てよ?????

昨年の規約では EME への混信を考慮して 144.150MHz 以上を推奨と書いてあったのに、今年は書いていない

単に書き忘れか、それとも他モードへは配慮する必要なしとの判断か???

コンテスト実行委員の JK3HYS 戸田氏に問い合わせたところ、《書き忘れ》 だそうです。


サバイバルマラソンにご参加の皆さん、 144.150MHz 以上での運用を心がけましょう。







第41回1エリアAMコンテスト2025年10月31日 16時00分07秒

第41回1エリアAMコンテスト

規約を発表しました。  皆さんぜひご参加ください。