この日記システムを golang で書きなおした。元日から4日ぐらいかけた。なんかおかしかったら教えてください。

前々から日記システムをgolangにしたいなという気持ちを抱きつつxatena-goを書いたりしていた。しかし実際全体を移行するという気がなかなか起きなかった。というのも Hatena記法だけじゃなくてMarkdownだったり素のHTMLだったり、tDiary記法だったりをそのままDBに入れていたり、類似エントリ機能とか、類似画像機能とか、それらを実行するジョブキューとか、なんか細けえ最適化 (linkヘッダとか) が入ってたりとか……

最初のとっかかりが重要、ということで、既存のDBそのままで閲覧側だけまず作り (表示するだけだから特にフォーマッタとかは関係ない)、一旦安心しつつ書きこみ系を実装していった。大きな変更は主に Claude Code で計画させて割と自動で実装してもらい、Claude Code の Limit がきたら、細かいレビューしたり、小さい変更は Gemini CLI で補完した。

無駄に元のスキーマで DATE や DATETIME をつかっていたせいで (SQLite ではTEXTと一緒)、これらを go-sqlite3 が「いい感じ」に time.Time に変換するので、若干ややこしいクエリに書きかえたり、最小限のマイグレーション (created_at などを TZ 付きのフルのISO 8601に) をかけた。

smem -P "/srv/www/backend.psgi" -t -k
  PID User     Command                         Swap      USS      PSS      RSS 
2438110 cho45    /srv/www/backend.psgi (mast        0     6.0M    10.9M    50.0M 
2438111 cho45    /srv/www/backend.psgi (work        0     6.8M    10.9M    49.4M 
2438114 cho45    /srv/www/backend.psgi (work        0     7.5M    11.2M    49.1M 
2438205 cho45    /usr/bin/python3 /usr/bin/s        0    11.0M    11.3M    13.7M 
2438118 cho45    /srv/www/backend.psgi (work        0     7.8M    11.4M    49.4M 
2438119 cho45    /srv/www/backend.psgi (work        0     8.5M    12.2M    50.2M 
2438120 cho45    /srv/www/backend.psgi (work        0     8.7M    12.3M    49.6M 
2438117 cho45    /srv/www/backend.psgi (work        0     8.7M    12.3M    49.7M 
2438112 cho45    /srv/www/backend.psgi (work        0     8.9M    12.4M    49.7M 
2438113 cho45    /srv/www/backend.psgi (work        0     8.8M    12.6M    50.5M 
2438115 cho45    /srv/www/backend.psgi (work        0     9.3M    13.0M    51.1M 
2438116 cho45    /srv/www/backend.psgi (work        0    17.9M    21.6M    57.8M 
-------------------------------------------------------------------------------
   12 1                                           0   109.8M   152.0M   570.1M 

  PID User     Command                         Swap      USS      PSS      RSS 
2498750 cho45    /usr/bin/python3 /usr/bin/s        0     9.8M    10.1M    12.2M 
2498688 cho45    /srv/www/lowreal.net/Hanran        0    17.8M    17.9M    19.6M 
-------------------------------------------------------------------------------
    2 1                                           0    27.6M    28.0M    31.8M 

せっかくバックエンドシステムも変わったことだしと思ってCSSをアてなおした。何年ぶりかわからん (調べたら約10年一緒だった)

以下のように gemini-3-flash-preview に指示して、何度かやりなおしたら割といい感じだったので、さらに指示を加えたり手動で数字いじってなんとかした。

この日記を以下の条件で CSS を書きなおして新しいデザイン(見た目)を適用するとしたらどうしますか。やってみて
- 落ち着いたトーン 
- 「読みやすさ」最重視  
-「コード」は情報密度を高く
- 「写真」はできる限り大きく 
- ブロックの大きさに px 基本的に指定しないこと 
- フルにレスポンシブ (モバイルも同一ページです) 

中央揃えだとなんかモダンに感じる。

コードブロックと写真の幅を画面いっぱいにしたりするのは後からの指示。

HTML の変更はしないつもりだったけど、結局微調整した。

デフォルトだと fusion が有効にならなかったが明示的に指定したらいけた。

cmake -DWITH_BUNDLED_SSL=on  -DWITH_FUSION=ON -DCMAKE_C_FLAGS="-march=native" .

ゼロコピー系の設定をいれてみた。ただ効果測定できるほどの情報がない

proxy.zerocopy: ALWAYS  
ssl-offload: zerocopy   

統一OGP画像を作ったところで、そういえば最近のサービスはどこもOGP画像をダイナミック生成させていて、リッチでちょっと羨しいなと思っていたことに気付く。こんな日記には実装・運用コスト的に、見合う価値があるわけないのだけど、バックエンド置き換えの機会ということでやってみることにした。

使ってるのは golang 標準の image と golang.org/x/image/font/opentype

RGBAで処理しつつ、最終的に16色のパレットに割り当ててサイズを減らしている。一応ファイルキャッシュをしたいが、あまり容量の余裕のあるサーバではないのでできる限りのことをする。

以下のような感じで最適化した。パレット化の効果はすさまじい。

1. 初期実装 (RGBA / BestCompression なし): 66KB
2. BestCompression 適用後: 64KB
3. 256色パレット化 (RGBA → Paletted): 25KB
4. 128色パレット化: 23KB
5. 64色パレット化: 21KB
6. 32色パレット化: 19KB
7. 16色パレット化: 15KB

あと速度的にも手元で 1600req/sec ぐらい (静的ファイル 590000req/secに対し) 出るようにまで調整してある (pprof の結果を Gemini CLI に投げつけると割とよくやってくれた)

pprof でひたすら潰していった。html/template のリフレクションを丁寧に潰すのが地味に効く (funcMap 呼ぶのが本当に遅いみたい)

一通りやったので `hey -z 5s -c 20` (20並列 5秒) でそれぞれのエンドポイントのスループットを測った結果出してみた。マシン性能で数字が変わっちゃうので、静的ファイルに対しての係数も出してみた。

フィードは encoding/xml で、思ったよりすごく早くてびっくり。個別ページとトップページが html/template で、レンダリング後のキャッシュは入れてないので毎回出している。

   基準値: 静的ファイル配信 (/images/github.svg) = 0.3ms (コスト係数 1.0)
 
 
   ┌──────────────────────┬────────────────────────┬───────────────────┬───────────────────────┐
   │ ページ種別           │ スループット (req/sec) │ 平均処理時間 (ms) │ コスト係数 (静的=1.0) │
   ├──────────────────────┼────────────────────────┼───────────────────┼───────────────────────┤
   │ 静的ファイル         │ 59,240                 │ 0.3               │ 1.0                   │
   │ OGP (キャッシュあり) │ 48,695                 │ 0.4               │ 1.3                   │
   │ フィード             │ 7,143                  │ 2.8               │ 9.3                   │
   │ 個別ページ           │ 4,958                  │ 4.0               │ 13.3                  │
   │ トップページ         │ 2,305                  │ 8.7               │ 29.0                  │
   │ OGP (キャッシュなし) │ 1,644                  │ 12.1              │ 40.3                  │
   └──────────────────────┴────────────────────────┴───────────────────┴───────────────────────┘
 
 
   指標の解説
    * 平均処理時間 (ms): hey で計測された平均レイテンシです。
    * コスト係数: (各ページの平均処理時間) / (静的ファイルの平均処理時間) で算出。
        * 例: トップページ（8.7ms）は静的配信（0.3ms）の 29倍 の時間を要しており、そのマシンの性能によらず「静的ファイル29個分の重さがある」という実装の相対的な複雑さを示します。

実際はサーバのネットワークがボトルネックになる。

VPS 上の h2o サーバの h3 接続が不安定に。手元から curl しても、https://http3check.net/ を使っても繋がったり繋がらなかったり不定。

結局 mtu いじったりなんやかんやいじっているうちになおってしまった。設定は結局元のままだしわけわからん。

GSO が怪しいのでオフにしてみることに。Gemini と壁打ちしたところ、最終的に矛盾がないのは「virtio_net ドライバの TXリングバッファ（送信キュー）がスタックしていた」説らしいですが。

$ sudo ethtool -k ens3 | grep -i segmentation  
tcp-segmentation-offload: off
        tx-tcp-segmentation: off
        tx-tcp-ecn-segmentation: off
        tx-tcp-mangleid-segmentation: off
        tx-tcp6-segmentation: off
generic-segmentation-offload: on
tx-fcoe-segmentation: off [fixed]
tx-gre-segmentation: off [fixed]
tx-gre-csum-segmentation: off [fixed]
tx-ipxip4-segmentation: off [fixed]
tx-ipxip6-segmentation: off [fixed]
tx-udp_tnl-segmentation: off [fixed]
tx-udp_tnl-csum-segmentation: off [fixed]
tx-sctp-segmentation: off [fixed]
tx-esp-segmentation: off [fixed]
tx-udp-segmentation: off [fixed]

$ sudo ethtool -K ens3 gso off

$ sudo ethtool -k ens3 | grep -i segmentation  
tcp-segmentation-offload: off
        tx-tcp-segmentation: off
        tx-tcp-ecn-segmentation: off
        tx-tcp-mangleid-segmentation: off
        tx-tcp6-segmentation: off
generic-segmentation-offload: off
tx-fcoe-segmentation: off [fixed]
tx-gre-segmentation: off [fixed]
tx-gre-csum-segmentation: off [fixed]
tx-ipxip4-segmentation: off [fixed]
tx-ipxip6-segmentation: off [fixed]
tx-udp_tnl-segmentation: off [fixed]
tx-udp_tnl-csum-segmentation: off [fixed]
tx-sctp-segmentation: off [fixed]
tx-esp-segmentation: off [fixed]
tx-udp-segmentation: off [fixed]

24497: HTTP_STREAM_JOB_CONTROLLER
https://lowreal.net/
Start Time: 2026-01-09 08:50:46.370

t=83062 [st= 0] +HTTP_STREAM_JOB_CONTROLLER  [dt=50]
                 --> allowed_bad_certs = []
                 --> is_preconnect = true
                 --> privacy_mode = "disabled"
                 --> url = "https://lowreal.net/"
t=83062 [st= 0]   +PROXY_RESOLUTION_SERVICE  [dt=0]
t=83062 [st= 0]      PROXY_RESOLUTION_SERVICE_RESOLVED_PROXY_LIST
                     --> proxy_info = "DIRECT"
t=83062 [st= 0]   -PROXY_RESOLUTION_SERVICE
t=83062 [st= 0]    HTTP_STREAM_JOB_CONTROLLER_PROXY_SERVER_RESOLVED
                   --> proxy_chain = "[direct://]"
t=83062 [st= 0]    HTTP_STREAM_JOB_CONTROLLER_ALT_SVC_FOUND
                   --> alt_svc = "quic lowreal.net:443, expires 2026-01-09 09:00:11"
                   --> is_broken = true
t=83112 [st=50] -HTTP_STREAM_JOB_CONTROLLER

$  pwd
/Users/cho45/Library/Application Support/Google/Chrome/Default

$ cat "Network Persistent State" | jq '.net.http_server_properties.broken_alternative_services[] | select(.host == "lowreal.net")'
{
  "anonymization": [
    "...",
    false,
    0
  ],
  "broken_count": 3,
  "host": "lowreal.net",
  "port": 443,
  "protocol_str": "quic"
}
{
  "anonymization": [
    "...",
    false,
    0
  ],
  "broken_count": 8,
  "broken_until": "1767933207",
  "host": "lowreal.net",
  "port": 443,
  "protocol_str": "quic"
}

$ cp "Network Persistent State" "Network Persistent State.bak"
$ cat "Network Persistent State.bak" | jq '.net.http_server_properties.broken_alternative_services |= map(select(.host != "lowreal.net"))' > "Network Persistent State"

Web Share API というのがあるんだなあ、ということで付けてみた。ファイルもこれで共有できるみたい。知らなかった。

Firefox は未対応。あとmacOSの共有はあんまり意味ないので、SNSの共有ボタンをまるごと代替できるものではないようだ。

customElements.define('web-share-button', class extends HTMLElement {
	connectedCallback() {
		const title = this.getAttribute('title');
		const url = this.getAttribute('url');

		if (!navigator.share) {
			this.style.display = 'none';
			return;
		}

		// Web Share API 対応: ボタンを表示
		const button = document.createElement('button');
		button.className = 'share-button';
		button.textContent = '共有';
		button.addEventListener('click', async () => {
			try {
				await navigator.share({ title, url });
			} catch (err) {
				if (err.name !== 'AbortError') {
					console.error('共有エラー:', err);
				}
			}
		});
		this.appendChild(button);
	}
});

https://github.com/cho45/ticker-generator でも対応させてみた。

こんな感じ。Android の「共有」のペインの最上位、DMとかチャットとかが表示されて消せないのがひどい。このためだけにゲストモード設定が必要になる pic.twitter.com/cfmiz7I0Zj

— ショ糖 (@cho45) January 9, 2026

README.md に書いてある通りだけど、ext/ 以下で libaom をビルドしてそれを static link するのが良いようだ

git clone -b v1.3.0 --depth 1 https://github.com/AOMediaCodec/libavif.git
cd libavif
cd ext
sh aom.cmd
cd ..
cmake -DAVIF_BUILD_APPS=ON -DBUILD_SHARED_LIBS=OFF -DAVIF_CODEC_AOM=LOCAL -DAVIF_LIBYUV=LOCAL . 

v1.3.0 より新しいと要求する cmake があたらしすぎてダメだった

LLM にリリースノートと ps aux の結果とかを食わせながら注意点を適当にあらいだしてやった。こういうときペアでやってる感じがあってだいぶ気が楽だ。

そこそこすんなりいったのでよかった。

 wget https://www.openssl.org/source/openssl-3.0.12.tar.gz
 tar xzvf openssl-3.0.12.tar.gz 
 cd openssl*
./config --prefix=/opt/h2o-ssl no-shared
make
sudo make install

$ git clean -fdx
$ export PKG_CONFIG_PATH=/opt/h2o-ssl/lib64/pkgconfig  
$ cmake -DOPENSSL_ROOT_DIR=/opt/h2o-ssl -DOPENSSL_USE_STATIC_LIBS=TRUE  -DWITH_FUSION=ON -DCMAKE_C_FLAGS="-march=native" .
$ make
$ make install

$ ./h2o -v
h2o version 2.3.0-DEV@afe696c72
OpenSSL: OpenSSL 3.0.12 24 Oct 2023
mruby: YES
capabilities: YES
fusion: YES
ssl-zerocopy: YES
ktls: YES
key-exchanges: secp521r1, secp384r1, x25519, secp256r1

$ ldd ./h2o
        linux-vdso.so.1 (0x00007ffef3ffb000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f411d0e2000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f411d0dc000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f411cf8d000)
        libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f411cf71000)
        libcap.so.2 => /lib/x86_64-linux-gnu/libcap.so.2 (0x00007f411cf68000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f411cd76000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f411d951000)

sudo tar czvf /data/vps_config_backup_20260110_v2.tar.gz \
  /home \         
  /etc \
  /usr/local \
  /var/lib \
  /var/spool/cron \
  /root \
  /opt \
  /srv \
  /var/www \
  --exclude=/var/lib/docker \
  --exclude="/home/*/tmp" \
  --exclude="/home/*/swp"

 sudo apt install snapd
 sudo snap install core; sudo snap refresh core
 sudo snap install --classic certbot
 sudo ln -s /snap/bin/certbot /usr/bin/certbot

2021年にh2oをsystemd管理にしてから、UNIXドメインソケットでの接続 (unix:/tmp/backend とかにしてた) がうまくいかず、ずっと TCP を無駄に通してた。

これがいまさらながら解決した。つまり /tmp は systemd が PrivateTmp で隔離しているので共有できないというだけだった。

なので以下のように RuntimeDirectory の設定を入れる。

RuntimeDirectory=hanrangon
RuntimeDirectoryMode=0755

これで /run/hanrangon が systemd によって作られるので、ここの下に /run/hanrangon/socket として UNIXドメインソケットを作るといいらしい。

フロント(h2o)からは http://[unix:/run/hanrangon/socket] を指定する。

以下をコピーして pbpaste | python する

import matplotlib
import shutil
import os

# キャッシュディレクトリの場所を取得
cache_dir = matplotlib.get_cachedir()
print(f"キャッシュディレクトリ: {cache_dir}")

# キャッシュディレクトリ内の fontlist 関連ファイルを削除
for file in os.listdir(cache_dir):
    if file.startswith("fontlist") and file.endswith(".json"):
        path = os.path.join(cache_dir, file)
        print(f"削除中: {path}")
        os.remove(path)

print("削除完了。Jupyter Notebookやスクリプトを再起動してください。")

類似画像検索まわりをだいぶいじった。Perl の実装では Libpuzzle を適当に使ったやつだったが、独自実装に変えてみた。↑ の画像は管理画面

標準ないし準標準 (golang.org/x/image/webp みたいな) にはないので面倒っぽそうだなあとなんとなく思ってたけど意外にも簡単に対応できた。

CGo を許容するかで今のところ2択っぽい

1. _ "github.com/vegidio/avif-go" CGo
2. _ "github.com/gen2brain/avif" libavif を WASM にコンパイルし、wazero で実行

どっちもブランクインポートするだけでつかえる。ベンチ的には CGo のほうが10倍早い

こういう検証とベンチをむちゃくちゃサクっとやれるのすごいいいよなあ。Agentic Coding。脳の負荷が位置が変わっているのを感じる。

検証

vegidio/avif-go

# register_vegidio_test.go
package main

import (
	"bytes"
	"image"
	"os"
	"testing"

	_ "github.com/vegidio/avif-go"
)

func TestRegisterVegidio(t *testing.T) {
	data, err := os.ReadFile("../../static/fixtures/sample.avif")
	if err != nil {
		t.Fatal(err)
	}

	img, format, err := image.Decode(bytes.NewReader(data))
	if err != nil {
		t.Fatalf("Vegidio registration failed: %v", err)
	}

	t.Logf("Successfully decoded %dx%d %s image using vegidio", img.Bounds().Dx(), img.Bounds().Dy(), format)
	if format != "avif" {
		t.Errorf("Expected format avif, got %s", format)
	}
}

go test -v register_vegidio_test.go   
=== RUN   TestRegisterVegidio
    register_vegidio_test.go:23: Successfully decoded 2886x2164 avif image using vegidio
--- PASS: TestRegisterVegidio (0.08s)
PASS
ok      command-line-arguments  0.313s

github.com/gen2brain/avif

# register_gen2brain_test.go
package main

import (
	"bytes"
	"image"
	"os"
	"testing"

	_ "github.com/gen2brain/avif"
)

func TestRegisterGen2brain(t *testing.T) {
	data, err := os.ReadFile("../../static/fixtures/sample.avif")
	if err != nil {
		t.Fatal(err)
	}

	img, format, err := image.Decode(bytes.NewReader(data))
	if err != nil {
		t.Fatalf("Gen2brain registration failed: %v", err)
	}

	t.Logf("Successfully decoded %dx%d %s image using gen2brain", img.Bounds().Dx(), img.Bounds().Dy(), format)
	if format != "avif" {
		t.Errorf("Expected format avif, got %s", format)
	}
}

go test -v register_gen2brain_test.go 
=== RUN   TestRegisterGen2brain
    register_gen2brain_test.go:23: Successfully decoded 2886x2164 avif image using gen2brain
--- PASS: TestRegisterGen2brain (0.73s)
PASS
ok      command-line-arguments  1.119s

容量的には 10GB までは無料で、そのあと従量課金になってもそれほど高額ではなさそう。

ただクラスB操作(参照系)がコントロールしにくいのでちょっと怖い。CDN経由のキャッシュミスだけが問題なのでファイル数が十分に少なければ恐るることはなさそう。現状ではこのサイトの全GETリクエスト(ほとんどクローラーだけど)がR2に飛んだとしても無料枠に収まる。

まず新規アップロードを R2 にするようにしてある。様子を見つつ過去分もアップロードするつもりではあるけど、その前に JPEG ファイルを全ファイル AVIF にするということをしたいのでまだやれてない。

もともと Cloudflare Registrar 契約してるので使いはじめに抵抗がない感じ。

半年以上前に Cloudflare Workers上で Honoフレームワーク使いつつ懐しい構成のサイトを作ってみたやつ、日記に書いてなかった。

• https://github.com/cho45/cf-neocities

中身がシーディーエンヌのエッジのワーカーで動いてるけど見てくれがジオシティーズだったら面白いなと思って、当時は Github Copilot 使いながら作った記憶。

いわゆる6hotサイトみたいのは現状の Worker の無料枠で全然問題なかろうという気がするし、そういう意味では現代のジオシティーズなんじゃと思ったのだった。

Durable Objects まわり仕様が変化していくのでエーアイに書かせて困った思い出がある。作りっぱなし

過去のをちまちま変換してるけど、1/10 になってかつ見た目がまったく変わらないのも多い。JPEGはやめよう!

よく昔の日記を検索してはりつけるので、さっさと作ればよかった。

Ctrl-L で起動して、Ctrl-N Ctrl-P で選択し、よくわからんかったら一度 Shift-Enter で別窓で開き、確定なら Enter で挿入できる。すごい便利

$ ffmpeg -ss 1 -i "/Users/cho45/Movies/2026-01-14 23-01-13.mkv" \
	-t "5" \
	-vf "scale=1280:-2" \
	-an \
	-c:v libsvtav1 \
	-crf 45 \
	-preset 4 \
	-svtav1-params tune=0:enable-overlays=1 \
	-pix_fmt yuv420p \
	"./foo.webm"

プログラムろくに書いたことない人はプログラミング言語をシンプルに誤解してて、機械語と区別がついていないのだろうと思う。

プログラミング言語はたまたま最終的に機械語に変換できるだけで、前提は人間同士(自分自身も含む)のコミュニケーション言語であるという理解がない。形式言語という形で意図を正確に伝えられるのがプログラミング言語であって、そうすると、たまたま実行可能にしやすいだけ。

LLMとのやりとりで自然言語を通してプログラミング言語を生成するのは、この意図が正確に反映されたかを、人間がレビューする必要性があるからにほかならない。

「ちゃんとできたか」を確認するのは最終的にはその要求をしている主体だ。一方で、人間は要求・要件を自然言語で100%正確に漏れなく曖昧さなく書くことはできない。なぜなら自然言語だから。やってみたいことを書き出したら矛盾することすらある。

プログラミングは、単なる実装(機械への命令)というより、曖昧な人間の意思を形式言語でミラーして具現化する行為であって、これはLLMを通じても別に変わらない。

とにかく本質的には人間は自分が欲しいものを、そもそも自分自身でも正確に理解していないところにある。「AIが無限に強くなれば言わなくてもやってくれる」という期待は、自分は自分が欲しいものを正確に理解しているという根本的な錯覚に基いている。

たとえAIが神になっても祈る側の願いが不定な以上は結果は定まらず、祈りと矛盾しないが意図しない結果がうまれる。この手の話は神話の時代からあり、上記の通り人間の埋め込みバグなので解決することはない。

だからこそ一度コードという形で曖昧さをなくし、テスト可能にし、自分の要求がなんだったのかを矛盾なく記述する必要がある。

Windows でスクリーンレコード気軽にとるなら ScreenToGif がよさげ？

名前からしてデフォルトでは anigif 出力なんだけど、WebM 形式にするとエンコーダーを選べて、普通に AVIF 出力ができる。録音はそもそもされないみたい。

macOS だと何がいいんだろうな。Kap なのかな。今度使ってみる。

複数のテストを並列実行でマルチカラムで表示するやつをGeminiに書いてもらった。依存なし180行 で必要十分なのができて満足

人間が実行したときは途中経過を見せて、tty 経由じゃなければ最後まで無言でやってFAILしたものだけログをすべて出すというようにしてる。(Agentが実行するとき対策)

ずーーーと「なんでh3にならんのかな〜」ということをやってたけど、この開発者ツールのプロトコルの部分にホバーすると理由が出るということにようやく気付いた。ただ出ないこともある

JSON-LD 全然好きではないが、microdata でやっていた構造情報を JSON-LD にのせかえてみた。どっちにしろたいした情報はないが……

microdata だと display: none な要素を使ってメタデータを埋めこむ必要がしばしばあって、これがDOMの構成要素を増やす要因になっていて気になっていた。

最近のChromeだとDOM要素多いとパフォーマンス悪化するぞと脅してくる。

HTMLとしては非常にシンプルになって気持ちよいけど、やっぱ microdata のほうが好きだなあ。

このサイト開くと、便利情報として右上に IPv4 か IPv6 か表示するようにしてあるんだけど、ここに今繋いでる HTTP のバージョンも出すようにしてみた。

/.ip としてシンプルな情報を出すエンドポイントが前からあるのでここに足しただけ

      "/.ip":
        header.set: "Cache-Control: private"
        mruby.handler: |
          lambda do |env|
            ipv6 = env["REMOTE_ADDR"].include?(":")
            proto = {"HTTP/2" => "h2", "HTTP/3" => "h3"}.fetch(env["SERVER_PROTOCOL"], "")
            [200, {'content-type' => 'text/plain'}, [ "#{ipv6 ? 'IPv6' : 'IPv4'} #{proto}" ]]
          end

直接関係ないけど、h2o からproxy.reverse.url のバックエンドに直接こういう変数を入れたカスタムしたヘッダを送るのはあんまり簡単でなさそう？ http_request 使うぐらい？

主に Gemini を使って、LLM主体でモデルの設計と学習をなるべくさせてみるということに数日とりくんでた。

自分が知らないことをLLMにやらせてみようというのを時々やっている。

課題

モールス符号の音響受信をさせる。7年前にKerasを使って頑張って似たようなことをやった覚えがある。その情報は渡さずに「今こういうのやるならどういうモデルがいいかな」という相談からはじめた。

Gemini いわく「 CTC損失を用いたStreaming Conformer (CNN + Transformer)」がいいのではということだった。よくわからないが全く理解しないままこの方向ですすんでみることにする。(賢いあなたは、わからないことがあったらその時点で必ず解消しましょう)。

リアルタイム音声認識ということでこれを提案してきたのだろう……

できたもの

https://cho45.github.io/morse-decoder-2026/demo.html

一応計画の段階で「最終的にブラウザでリアルタイムにストリーム処理できること」は入れてたので、いろいろ問題はありつつも動くものはできた。

pytorch でモデルを作り、最終的に onnx に変換して onnx web で動いている (wasm)。WebGPU でも動きはするけど、なんかちゃんとやってないのでパフォーマンスがでない。

「SNRいくつまでデコードができる」みたいなことを言いたいが、SNRの定義がなんともいえない (信号のある瞬間の振幅基準) ので難しい。このSNRで-15dBぐらいまでギリデコードができる。もうちょっと頑張ってほしいけど……

モデル構造

こんな感じ。CNN + Transformer のことを Conformerというらしい。まんなかの4層がそれ。ただのモールス復号のモデルにしてはデカいはずだけど、もっと少ない状態だとまったくうまくいかなかった。

入力はスペクトログラムを特定ピーク中心で切り出したものになっている。つまりベースバンド波形ではなく画像として見てる。別途ピーク検出と切り出しを行ってからこのモデルに入れる想定。位相が不要だから画像として扱うほうがいいっぽい？

しかし疑問点

モデルの内容には、ほぼ口を出さずにやれるところまでやったけど、そもそもいくつか疑問があるので、今更訊いた。

なぜ入力にメルスペクトログラム？

(意図: 特定周波数付近を切り出して渡しているので、通常のスペクトログラムで十分だし実用上は楽なのでは？)

A:「メルスペクトログラムは、一般的な音声認識（ASR）モデルの標準的な入力形式であり、情報の圧縮とノイズ耐性に優れているため採用されています。狭帯域にクリップする場合、メル尺度による圧縮の恩恵は薄れるため、本アプリにおいては線形スペクトログラムの方が解像度を維持でき、より合理的である可能性が高いです。」

「リアルタイム音声認識」にひっぱられてあんまり考えずに決めてるな……

出力がCTCなのはなぜ？

Q: 「今回のモールス学習の場合、かなり厳密にラベルがつけられるはずですよね。そして実際そうしているし Signal Head として出力もしている。それでもなおCTCを使う理由は？」

A:「Signal Head による物理的な信号認識を補助としつつ、CTC を使うことで「文字」としての文脈や区切りを柔軟に扱い、デコード時の頑健性を高めるためです。」

Q:「今回の場合ラベルの柔軟性というよりは出力の簡略化の側面がつよい？」

A:「はい、その通りです。Signal Headのように「全フレームを分類」するのではなく、CTCを使うことで「重複除去とblank削除」という単純なルールだけで、複雑な後処理なしに最終的なテキストを直接得られるという、出力の簡略化と利便性の側面が非常に強いです。」

フーン……

他

出力に CTC 以外に Signal Logits と Boundary Logits がある。これらはCTC出力からだけの学習で一切上手くいかなかったため、苦肉の策として追加した出力になっている。(ここは自分の指示……)

• Signal Logits: モールスの「短点」「長点」「符号間空白」「文字間空白」「単語間空白」「ブランク」を予想させる -- モールスの形状を強制的に学習させる
• Boundary Logits: モールスにおいて、符号が確定する瞬間に1になる。つまり文字符号の後の空白1ユニットの直後に発火する -- CTCが発火すべきポイントを間接的に学習させる意図 --- これそのままCTCへの入力に使ったら楽や～んと思ったけど、それだとCTCがチートして、Boundary Logits が高かったら適当に文字出すようになってしまって一敗

これが正しいことかはわからないが、Gemini 的には学習を進めるうえで有効ですとはいっていた。まぁ結果としてうまくはいったけど、これのせいでモデルサイズが大きくなっている面がある気がする。

得られたもの

やはり自分で正解知らないことをボーっとやらせるのは非常に難しい。結局急がば回れになることが多い…… わかってるんだよ。わかってるけどわからないまま作りたいんだ！

機械学習の修正タスク投げると、いくら事前に指示をしていてもテストを書かないし実行してくれない。最終的には「平均的なエンジニアはテストを書かず本体のコードだけに集中している。そこから学んでいるので自分もそういう傾向にあるのだ」という開きなおりをされた。

むか〜し書いた WebAudio-Signal-Generatorをモダンにした。AngularJS 1.2 + Bootstrap 3 だったのを Vue3 + Vanilla CSS に。というかそもそも ScriptProcessorNode 使っててマジで古かった。

ブラウンノイズ こんな感じで設定をURLに反映するようにして、リンクを貼れるように。

まぁもうこんなの欲しいとおもったときにLLMに書かせりゃいいという気はするけど