Deskflowの最新版がOpenBSDで動かなくなっていたので、直しているところです。排他制御を行う必要が生じたらしく、std::scoped_lock lock{m_mutex}がいくつか追加されているのですが、どうもロックのかかった状態でさらにロックしようとしてabort trapで落ちます。OpenBSD(server)からWindows(client)にキーボード/マウス操作が移った瞬間に。

二重ロックの検出は #define CheckLock(x) {if (m_mutex.try_lock()) m_mutex.unlock(); else __asm__ volatile("int3");} した上で、std::scoped_lock lock{m_mutex};の前にCheckLock(0)を呼ぶとして、gdbの操作が厄介です。というのも、キーボード/マウス操作の対象がWindows側に切り替わるタイミングでgdbに落ちるため、Ctrl-Alt-BackspaceでX.orgを落とす以外何もできなくなります。これについては、tmux→gdb→deskflowの順に動かし、breakpoint trapでgdbに落ちたら一旦X.orgを落とす→X.orgを再起動→tmux aでgdbセッションに復帰、という手順でbacktraceは取れます。Xを一旦落としているので、その後の動作は継続できませんけど。

実はこの方法を見つける前に、何か例外を吐いているのではなかろうかということで try { std::scoped_lock{m_mutex}; } catch(...) { /*適当な処理*/ } を試していたものの、全然問題を見つけ出せずかなり悩んでいました。これ、分かる人はすぐ分かると思いますがstd::scoped_lock{m_mutex}の範囲がtry{}の中だけに限定されてしまうのでコメントアウトしているのと変わりません。いくら頑張っても、流石に「無」をデバッグするのは…（←一回言ってみたかった）。57.2kg(24:00)

45字/分の速度、2分間の欧文普通文の受信でした（送信の試験は無かった時代です）。具体的にどんな感じなんだっけ？ということで、メルカリで「CQモールスカセット(3) 2級国試編」を購入して調べてみました。テープ付属のテキストには「国家試験の合格点は公表されていませんが、第2級アマチュア無線技士の試験では85点のようです。満点を100点として減点法で採点されます。」とあり、減点は

字をまちがえたり、余計な字を書いた場合

1字につき3点

字を抜かしたり、書いた字がはっきりしない場合

1字につき1点

書き間違えて訂正した場合

3回まで1点

となっていることに加え、語間を開けなかった場合は品位による減点を受けるという記述もあります。なので、採点基準については現在の総合無線通信士と同様であったと思われます。脱字だけであれば90文字のうち15文字を落とす…75文字(83.33%)取れればよし、ですかね。

テープの中身をPCMエディタ等で雑に調べると、こうでしょうか。

• A面：耳慣らしのA〜Zは、短点100ms(12WPM)、文字間3点、単語間不明
• A面：45字/分の国家試験模擬テストは、短点125ms(9.6WPM)、文字間3点、単語間7点
• A面：55字/分の国家試験模擬テストは、短点100ms(12WPM)、文字間2.9点、単語間6.8点
• B面：45字/分の暗文受信練習は、短点122.5ms(9.8WPM)、文字間2.9点、単語間6.9点
• B面：55字/分の暗文受信練習は、短点83ms(14.4WPM)、文字間2.9点、単語間6.9点

トーンは正弦波、A面が878.9Hz/B面が890.6Hzなのは誤差と言えるのかどうかはともかく、長短点比は全て3:1でした。安ラジカセ（小泉成器 SAD-1222）で再生した結果で見ているので、高級機を使って調べた場合はもう少し違う結果になる可能性もあります。とりあえず、2アマであればPARIS 10WPM程度の欧文普通文を取れる能力が問われていたということになるでしょうし、1アマは60文字/分→13.3WPMくらいの（以下略）。

50文字/分の和文がどれくらいのPARIS WPMに対応するかを今後調べてみたいのですが、CQモールスカセット(4)和文入門編、持っている筈なのに何処へやってしまったのか…

ここ一年以内に発売されたCQ Ham radioの電信に関する記事では、「最低限、自分のコールサインは25WPM（毎分125文字）くらいの速さでも聞き取れるようにする」だそうで…この速度で交信できることは求められてはいないんですよね。とはいえ、X上ではかなりこの記事は問題視されていたようです（例）。確かに、その速度は一総通（100文字/分）ではなく一通（125字/分）の領域なんですけど。

国家試験から電気通信術がなくなったので電信の人口や学習機会が減ったという話は以前から散々出ていましたが、こういう言説によって、新規参入者の減少にも成功してしまったようです…試験による、無線従事者が対応可能な通信速度の目安が無くなってしまいましたから。

（おまけ）

1999年2月1日に廃止された、電信による気象通報(JMC)と思われる録音をinternet archiveで見つけました。CQモールスカセット(3)のテキストには、「122.65/4298/6397/12840kHzなどの周波数帯で送信されています」と記載がありました。この音源だと、796.7Hz、短点長51.1ms(23.5WPM)、長短点比3:1、文字間3点、単語間7点です。自動送信されているのか正確無比な符号（人間味の無い無機質な符号とマニアは批判しそうですね）、ということになるのでしょうか。

この録音がいつの物なのか、自力で解読する根性は無かったのでMorse Code Adaptive Audio Decoderの力を借りて録音の中身を見てみました。特に日付等を示す情報は見当たりません。56.8kg(23:25)

前回の続き。ウナの元たるUR、これは一体いつ、どこから湧いて出たのでしょうかね？については、国立公文書館デジタルアーカイブにある、公文類聚・第九編・明治十八年・第十八巻・運輸・電信・船舶車輌の電信取扱規則ヲ定ムの中に定義されています。これよりも古い資料もありそうな気がしますが、探し出すことはできていません。

国際法規ではどうなってるのかなーということで、History of ITU Portalで"telegraph regulations"をキーワードにして調べてみます。最古と思われるInternational Service Regulations (Telegraph), edition of 1872には見当たらなかったものの、Règlement de service international (télégraphique), édition de 1875には以下のような定義がありました。

Signes conventionnels:

Télégramme privé urgent D, réponse payée RP, télégramme collationné TC, accusé de réception CR, télégramme recommandé TR, télégramme à faire suivre FS, poste payée PP, exprès payé XP.

1872年が明治5年、1875年が明治8年になります。日本では明治6年に電信取扱規則被定（大日本政府電信取扱規則）が制定されていたりするので、海外の動きとは異なる何かによってURが生まれたのかもしれません。

とりあえず、額表に出てくる種類、特別取扱、局内心得は濁点・半濁点無しのカタカナ二文字であろうと勝手に決めて、額表っぽいランダムな文字列を生成するものをPythonで書いてみました。verbose=0で無効化はできますが、[#comment]によるコメントを使っているので、a1a_genは最新版を使うことをお勧めします。

これらについて、A1A Breakerではどうなっているかも調べています。以下の文字列のどれかを使用するようです。

種類

ムセン ホアン ケン クニ カキトメ ソクタツ

特別取扱

ヒシテイ トキシテイ インジシテイ ソクタツ デンワハイタツ カキトメ

局内心得

ホゾン デンタツ ヒカエ

なお、情報通信振興会のモールス通信練習用CD(2023)の文章は、種類・特別取扱・局内心得を一切使用していません。昔の練習用テープでは使用したものがあったのでしょうか…？56.9kg(24:40)

第一級総合無線通信士等の電気通信術に出てくる、額表。これが《電報》に由来していることは何となく分かっていても、そもそも《電報》とは何か、が分かりません。電報頼信紙に必要事項を記して依頼し、メッセージの記載された電報送達紙が宛先に届く、そういうシステムであったようなのですが。

○平成二年郵政省告示第七百二十一号(無線従事者規則第三条の規定による電気通信術の試験の方法)を見るに、和文電報形式とは

1. ・・・・　・－・　・・・・　・－・
2. ・－・－・－
3. 種類(あるときに限る。)
4. 字数
5. 発信局(発信局を番号で表すときは、「ハツ」を前置するものとする。)
6. 発信番号(発信局を番号で表すときは、「タナ」を前置するものとする。)
7. 受付時刻(時と分を・－・－・－によって区分するとともに数字を略体により送信するものとする。)
8. －・・－・・(特別取扱のあるときに限る。)
9. 特別取扱(あるときに限る。)
10. ・・－・・－(局内心得のあるときに限る。)
11. 局内心得(あるときに限る。)
12. ・－・－・－
13. 名あて
14. －・・－　－　－
15. 本文(六十字を超えるときは、六十字目ごとの字の次に送信する・・－　－・・の次に約五秒の間隔を置くものとする。)
16. ・・・－・

ということですが、種類とは、特別取扱とは、局内心得とは一体何なのか。これらの三つは多分無いかな？と言われていても、あったとしたらどんな文字列なのか、気になっています。AIの力も借りて調べてみると、こうなっているみたいです。

【種類】

学校用無線電信法規（昭和17年）、電報取扱規程の第二章第二十九條に記載があります。それほど数が多くないので、引用します。()は和文における略号、[]は欧文における略号です。

• 官報 (リム) [G]
• 至急官報 (イリ) [S]
• 局報 (ムラ) [A]
• 至急局報 (イラ) [AD]
• 課金局報 (ニラ) [ST]
• 爲替局報 (ワラ)
• 至急爲替局報 (イワ)
• 振替局報 (フリ)
• 至急振替局報 (イフ)
• 氣象局報 (ヨラ)
• 障碍局報 (チナ)
• 至急私報 (ウナ) [D]
• 新聞電報 (ツム)
• 豫約新聞電報 (ラム)
• 後納新聞電報 (ナム)
• 照校電報 (ムエ)

【特別取扱】

こちらも学校用無線電信法規から引きます。第二章第第十二條。

• 至急 (ウナ) [D]
• 返信料前納 (ナツ) [RP]
• 照校 (ムニ) [TC]
• 電報受信報知 (ツニ) [PC]
• 郵便受信報知 (ツツ) [PCP]
• 追尾 (チラ) [FS]
• 再送 (ナチ) [RP]
• 同文 (ムヨ) [TM]
• 夜間配達 (タラ) [NS]
• 翌朝配達 (ヨナ) [MR]
• 留置 (ムナ) [TR]
• 別使配達 (マツ) [XP]
• 別使配達料受信人拂 (マナ) [XR]
• 艀船配達 (ハホ) [BD]
• 艀船配達料受信人拂 (ハナ) [BR]
• 電話送達 (ムチ) [TF]
• 局待 (ヤム) [WT]
• 親展 (ニカ) [CL]

【局内心得】

デジタルアーカイブとして見ることができるものは、現行通信法規第7巻（電報便覧）（明治37年）の局報略號使用心得 八 局内心得ノ類があります。非常に数が多いので、引用はしません。この他に、局報局内心得略号表（日本電信電話公社・昭和27年）が国会図書館にあります。

局報局内心得略号表は古書店で売られているのを見つけたので、入手して見ています。種類や特別取扱と同様に、局内心得も基本的には二文字の符丁、場合によってはこれに何らかの情報が付加されるようです。なお、電報便覧のものと電信電話公社のものはなんとなく似ているとはいえ「ヒゼウ」（非常電報）のように追加されているものや、以下のように意味が違うものがあります。

ムチ（電報便覧）

（何何）ノ文字本字

ムチ（電信電話公社）

貴局発第（何）号に対する返信である。

まとめてみて、至急の指定に疑問を持ちました。ウナ電と言われるだけあって欧文略号ではUR(urgent)かと思っていましたが、昭和17年における学校用無線電信法規ではDになっています。その一方で、電信法規 第一篇（昭和10年）ではウナ/UR表記となっています。

昭和26年11月1日の官報PDFの2ページ目には、電気通信省令第二十号、第十二條中「D」を「Urgent」に改めるとの記載があるので、Dが正式なものとして使われていたことになるのでしょうが…ウナの元たるUR、これは一体いつ、どこから湧いて出たのでしょうかね？57.2kg(23:20)

24-May-2026の続き。

OpenBSDでのDeskflow、LibreSSLではなくOpenSSLでも試しています（実は最初OpenSSLでやっていたのですが、LibreSSLで動いたのでそっちに一本化したものの、OpenSSLでの動作も確認する必要があったので結局両方用意する羽目になったということです）。自分が使うときに楽できるようports化も目論んでおり、LibreSSL版にするかOpenSSL版にするか悩んでいます。CMake関連のファイルを直すだけで済む、OpenSSL版の方が有力か？

解説のための文章を書こうとして途中で挫折した05-Feb-2026のモールス符号を鳴らすプログラムの話、少しだけまとめてみようと思います。

面倒な文字間の処理…次の文字が分かっていればまだ楽に書けるのでしょうけど、分からない以上はフラグ等を使って対処する必要があって面倒という話です。処理対象となるファイルを全部読み出してメモリ上に置くならともかく、fgetws()で一行単位の読み出し→一文字単位の処理を行うとなると、読み出した行の次の行にどんな文字がくるかは分かったものではありませんから。

a1a_genのコード(player.c)には以下のフラグがあり、こんな感じに動いています。文字間の処理と関係ないものも含めて説明します。

use_alt_code

和文電信の額表で使われる略体数字のような、同じ文字だが別の符号を使用する場合のフラグ。{}内の文字列を処理中の場合にtrueとなる。

space_sent

直前に空白を送信していた場合はtrue、そうでなければfalse。複数の空白は一つにまとめられてしまうが、これは仕様としている。

disable_char_space

ARやBTのような、文字間を空けずに送信することを示すフラグ。<>内の文字列を処理中の場合にtrueとなる。

char_space_is_disabled

文字間が実際にon/offとなっているかを示すフラグ。disable_char_spaceだけで文字間のon/offを判断するとx<ar>に対応できないため（xと<ar>の文字間が確保できない）、このフラグを使用して、x→<(disable_char_space=true, char_space_is_disabled=false)→文字間(disable_char_space=true, char_space_is_disabled=true)→a（これ以降は>が来るまで文字間off）→r、という動作をさせている。

久々にコードを見て頭を抱えておりましたが、文章にするとより頭を抱えたくなりますね…57.8kg(23:05)