2026年 02月 18日

uutransfer-tmux-v2

https://github.com/cho45/uutransfer/blob/master/uutransfer-tmux-v2

ちょっとだけ賢い v2 を作ってみた。

uutransfer とは何か

ごく稀に scp が直接通らないが ssh ができるホストからデータをひっぱってきたいときがある。(例: 多段プロキシなどややこしいホスト)

こういう場合に、既にある tmux セッションを利用して、ファイルを手元に持ってこようというのが uutransfer。scp よりかなり効率は悪いものの手軽にリモートファイルを手元に持ってこれる。要はコピペでがんばって転送するのを自動化している。

uutransfer-tmux-v2

従来は

  • uutransfer 1 で uutransfer の待受実行
  • openssql ... など適当なコマンドをリモートで手動実行

という2ステップ必要だったのを、単に

uutransfer-tmux 1 foobar.log

でいけるようにした。

やってること

  • tmux send-keys をより活用するようにした。ワンライナーをインジェクトするような感じに
  • 圧縮→base64 するようにした
    • メインの想定はログファイルとかなので効率良くなったはず

Google の Family Safety の発信先制限 (ペアレンタルコントロール) がゴミすぎる

Google の Family Safety (ペアレンタルコントロール) には発信先を制限する機能があるんだけど、これがバグっててひどい。

端的にいえば「許可した電話番号へ発信できない」問題が発生する。

まずFamily Safety 側からは常に正規化された +81 プリフィックスの国際電話番号形式しか入れられない。まぁこれは別に仕様としてはいい。

しかしコントロールされる側の Family Safety の設定画面にある同期された「保護者が管理する連絡先」などから発信しようとすると「保護者による使用制限(システム)から通話を発信することができません。別の通話転送アプリを使用するか、デベロッパーに問い合わせてみてください。」とでてブロックされる。

明示的に許可した一覧が表示されているのに、ここから発信するとブロックされる。は?

あるいはペアレンタルコントロールされる側は、ここで登録した連絡先が自動的に「編集不可」の「連絡先」として登録されるんだけど、この連絡先を使って通話することもできない (同様にブロックされる)

なおかつ、コールされた履歴からのかけなおし(コールバック)も制限される。

発信制限を解除するとかけられるので間違いなく発信先制限のせいなんだけど、本当にひどい。

どうすればかけられるか

ペアレンタルコントロールされる側のアカウントでも自力で「連絡先」を作って、「+81 90-XXXX-XXXX」形式で保存する。この状態で該当する連絡先を開くと、Family Safety で登録した「連絡先」とマージされて表示される。そしてなぜか

  • +81 90-XXXX-XXXX
  • 090-XXXX-XXXX

と二段で表示されるので、+81がついていないほうを選んでコールすると発信できる。上を選ぶとダメ。なんで? バカなのか?

逆だろと思うかもしれませんが↑の挙動で間違いないです。

どうすればかけられるか 2

ダイアルパッドからかける場合は +81 からはじまる形式の入力でかけられる。

直前の挙動と矛盾してるじゃんと思うけど間違いないです。

結論: 使えない

この意味不明な挙動を子どもに説明するのは不可能なので、実質的には「発信は完全に封じる」機能として使うのが妥当でしょう。着信専用として使うしかない。

ペアレンタルコントロールを設定するみなさまにおかれましては、設定するだけで満足せずに動作確認を必ずしましょう。普通に動く機能だろうと思ったらゴミだった例です。

subtechグループのcho45日記をインポート

subtech.g.hatena.ne.jp/cho45 以下のデータをインポートした。

はてブのホッテントリの復元

(iframeです)

https://lowreal.net/2026/restore-subtech-hotentry.html

サブテクURLからインポート済みへ転送

やったこと

グループのサービス終了にともなってエクスポートだけはしたけど、放置してあった。ときたま「あぁサブテクグループに書いた気がする」と思っても検索不可能だったのが地味に自分にとって不便だった。

ということで2020年にグループが終わってるから6年越しに、ずっっっっとやってなかったのを Codex と共にやってみた。

/cho45/20100107/1262839487/2010/01/07/1262839487 となるようにインポートしたので基本的に機械的に遷移できるはず。

そして http://subtech.g.hatena.ne.jp/cho45/20100107/1262839487 みたいに貼り付けられているリンクも後処理時に書き換えるようにしたので、この日記内ではリンク切れが復活するつもり。

あと一律で subtechタグをつけるようにした。ほとんど gerry++ で埋まっとるが……

ホッテントリの復元

グループ関係のはてブは全部タイトルが一緒になってしまっていて終わっているので、このホッテントリのトップだけ雑に再現したリンク集をつくった。供養。

2026年 02月 17日

LLMエージェント自体はめちゃくちゃいいのだけど「レビュー不要!」みたいな楽観的なやつ見ると意味わからんなと思う。出力されたコードが伝えた要求を満たしているか確認する能力がないだけでは? と思う。

いちいちすべてサボろうとするし実装をTODOみたいにコメントだけ書いて終わらそうとするし、設計能力は本当にないし、言わないとテストもろくに書かないし、些細な(まさに人間がやるような)変更漏れも多いのに? 本当にエージェント使ってんの? 何やらせてんの?

iijmio の契約をまとめようとしている

as-is:

  • 自分: 音声SIM (メイン)
  • 自分: SMS SIM (子ども用)
  • 妻: 音声 SIM (メイン)

で一切家族割の恩恵を受けられていない

to-be:

  • 自分: 音声SIM (メイン)
  • 自分: 音声SIM (子ども用) ← 音声SIM契約 & SMS SIM 解約
  • 自分: 音声 SIM (妻のメイン) ← 名義変更

で、子ども用の音声SIMの追加契約をしている。追加契約中だと名義変更の受け付けを拒否するようで順番にやる必要があるぽい。

住所にローマ数字が入っていると iijmio の本人確認アプリで住所不一致で失敗する

端的に: eKYC (ウェブ認証というやつ) でやれば良い

あとのメモ

本人確認の前提:

  • iijmio の本人確認アプリはマイナンバーカードを読みとるタイプ。
  • 登録住所とマイナンバーカードの住所を突き合せて完全一致(?)を見ている

特殊な前提:

  • 正式な住所 (マイナンバーカードに入っている) にローマ数字が入っている

問題点:

  • iijmio の登録住所にはローマ数字を入れることができない (バリデーション違反) なので Ⅴ vs V とか Ⅳ vs IV と「似てるけど違う表記」書く必要がある
  • 本人確認アプリを使うと住所不一致でハネられる。何度やってもだめ


eKYCのほうがそもそもアプリ入れる必要もないし、処理が遅いとかもないので、本人確認アプリ使うメリットがそもそもなさそう

2026年 02月 16日

ONNX Runtime Web の `ort.env.wasm.proxy` と `numThreads` は軽い推論では効果が薄そう

軽量なモデルの推論だと ONNX Runtime Web のマルチスレッド化の恩恵は受けれないという理解してるけど、どうするのが正解か考えている。

ort.env.wasm.proxy で Worker 化しても Session が1つだと1コアしか使えないよな、と思ってなんかいろいろ複雑なこと考えていたけど、ふと思うと単に Session 複数にすれば一番重いところはオフロードしてできるのか? → これはできなそう。プロキシ用のワーカーはグローバルに1つしか作られないっぽい。numThreads に応じてそこからさらに分岐するっぽいが

ということで、基本的に ort.env.wasm.proxynumThreads は重い推論の分散化だから軽量なモデルの大量推論にはあまり有効ではなく、そういうことをするなら自力で複数 Worker + Session 分離の仕組みを作らなければならない。

リアルタイム推論での複数同時推論の設計の方向性

リアルタイム前提のモデルの場合、推論時間はリアルタイム性に対して十分余裕があるぐらい軽量に作ってあるはず (100ms分の推論が10msで終わるというような)。これを複数同時にCPUコアを活用して行いたい。

この場合 90ms 分が余裕時間なので、以下のようなのが理想の状態

  • ワーカー数 m: できるだけ少なく〜最大でコア数 (2〜4)
    • onnx の session の数になる = モデルのコピーが m 個分必要 = メモリ必要量の増加
  • 処理数 n: 1つのワーカーに複数のストリーム(推論リクエスト)をコンカレントに(多重に) 流し込む。
    • ジッターを考えるとどのぐらいが適切かわからないが 100ms 分が 10ms で終わるなら5つ(50ms = 50%) ぐらい詰めこんでもいいか?

ort の session の初期化は結構重いので、ワーカー数はあまり増やすと初期化のコストが全然無視できない。なので1つのワーカーでできるだけ多くのことをしたい。そして session 自体はステートレスなので別々の推論ストリームを流しても大丈夫 (モデルの入力としてステートを渡すのが普通なので)

ワーカー数でパラレルにしつつ、リアルタイム余裕分をコンカレントに実行させる。

memo

let proxyWorker: Worker はモジュールレベルで定義されて使いまわされている

numThreads SetGlobalIntraOpNumThreads(numThreads) numThreads は Intra-Op (演算内のオペレーション) の並列化

Python だと inter_op_num_threads があるようだ Web にはないっぽい。

interOpNumThreads 自体はあった。This setting is available only in ONNXRuntime (Node.js binding and react-native). なので Web では使えない。

月次の家計簿診断もLLMにやらせてみたら、Claude とか Adobe Photo Plan とかを事業経費に分類してたのが気にくわなかったみたいで「それで稼いでるわけじゃないんだろ? だったら趣味か教養だろ」と怒られた…… そんなひどいこと言わなくても……

モールスデコーダの並列推論

ONNX Runtime Web の `ort.env.wasm.proxy` と `numThreads` は軽い推論では効果が薄そう ということで独自にワーカー化して分散推論させるようなものにしてみた。動画だとメイン周波数 (シグナル履歴がでているやつ) で占有ワーカー1つ、ほかサブ周波数 (デコード結果だけでているやつ) が16本まで推論する。

↑ のエントリに書いた通りリアルタイム性としては余裕があるので、1つのSessionで複数の周波数のデコードを順次行う(コンカレント)のを、複数の Worker で同時に行う(パラレル)

  • ワーカーごとに ONNX Runtime の Session を持つ (モデルのコピーをもつ)
    • session 自体はステートレス
  • ワーカー内で「スロット」という概念で特定の周波数のデコード状態を持つ
    • attention とかもろもろ。外に出す必要がないのでワーカー内で閉じる

普通に実装するだけなら難しくないんだけど、クリックしたとき遡って再デコードという機能を入れた結果割と面倒くさい。結局再デコードを伴うという特殊性からメインの推論はこのワーカー分散の仕組みには入れず、単体で ort.env.wasm.proxy = true によるワーカー分離をしている。