電電の女子枠が定員割れ起こして話題になってる。 https://www.kyoto-u.ac.jp/ja/admissions/tokusyoku/statistics

一昨日、昨日と熊が岩倉を徘徊してららしいんやけど https://kurashi.yahoo.co.jp/kyoto/26103/incidents/bohan/338757

日本在住シベ人については承志先生が2016年に書いた文章が残っている。どうもここに登場する人っぽい。シベ人の言語や歴史を研究している人ではないからノーマークだったんだけど。 https://storystudio.tw/article/gushi/%E5%9C%A8%E6%97%A5%E6%9C%AC%E5%B0%8B%E6%89%BE%E6%96%B0%E7%96%86%E7%9A%84%E9%8C%AB%E4%BC%AF%E4%BA%BA%EF%BC%88%E4%B8%8B%EF%BC%89

この日本にシベ語母語話者の夫婦が住んでいて、家庭内で日常的にシベ語を使っているという衝撃の報告。動画内で突然シベ語会話が始まってテンション爆上げ。動画を上げている子供には継承されていない。 https://www.youtube.com/watch?v=vvoBcaYwPHc しかし聞き取れない。sibe gisun (シベ語) は確実に言っている。gisurembi (離す) も使っているけど活用がよくわからない。e が落ちて gisur- のようになっている?

『日本言語地図』の近世藩領図は大藩だけしか扱っていなかったし、飛び地もよくわからなかったが、 https://mmsrv.ninjal.ac.jp/laj_map/data/laj_map/LAJ_S06.pdf 幕末期近世村領域データセットでは小藩も飛び地も見えて素晴らしい。 https://geoshape.ex.nii.ac.jp/av/han/ いろいろ眺めていて驚いたのが柏原藩。領域が継ぎ接ぎだらけで旧柏原町すらろくに覆っていない。 https://geoshape.ex.nii.ac.jp/av/han/H294/ 陣屋跡まで領域外になっていて、境界データの正確性には疑問がある。 「境界は現代（2015年）の農業集落境界データに基づく」とのことなので町の扱いは怪しい。 近世村としての柏原町が旗本領分だったこと自体は確からしい。 https://geoshape.ex.nii.ac.jp/av/resource/K43/K43G05S00001.html

https://arxiv.org/abs/2510.20075 表題に steganography が含まれていないので、危うく見逃すところだった。以下の (不適切な) 紹介ポストが流れてきたことで知った。 https://x.com/ai_database/status/1982790910409875839 稀に見るひどいプレプリント。LLM を使った生成型言語ステガノグラフィをまるで初めて見つけたかのような口調で紹介している。実際には特に新しいことはない。 第一著者はポスドクで、経歴を見ると言語処理ともセキュリティとも無縁に見える。しかし、仮にも博士を取った人間が、従来研究に気づかないまま、ここまでの長さの原稿を書くことが本当に可能なのか? ニューラル言語モデルによるテキスト生成の過程でメッセージを埋め込む手法は、すでに Fang et al. (2017) や Luo and Huang (2017) で提案されている。ニューラル以前の n-gram 言語モデルを用いた事例ならさらにさかのぼる。 Ziegler et al. (2019) は算術符号を用いることで高い埋め込み容量を実現した。彼らは隠したいテキストをバイナリ列に変換する段階でも算術符号を使い (むしろこちらが算術符号の本来の用途)、そのビット列を自然な偽装テキストとして生成・復号する手続きを実演済み。 現在の諸手法の埋め込み容量はかなり高く、隠したいテキストと偽装テキストの長さはだいたい同程度になる。提案手法は素朴なランク対応づけによって両者のトークン数を完全に一致させることを売りにしているが、そんなことをする必要はないし、その制約のせいで偽装テキストの品質が下がるリスクのほうが気になる。 提案手法は LLM の tokenizer に依存しているため、我々がここ数年取り組んできた問題が直撃する。すなわち、LLM が生成したトークン列をいったん detokenize して文字列に戻し、それをもう一度 tokenize したとき、元のトークン列が再現されないという現象が一定の頻度で起きる。この不一致が起きると、受信者はメッセージの復号に失敗する。著者らがこの問題を認識している形跡はない。 https://arxiv.org/abs/2508.20718 さらに不可解なのは、比較的最近の研究 (例えば2021年の Meteor) は引用していること。もし従来研究をすべて無視していたら、単なる調査不足で片付くのだが。本当に Meteor 論文を読んだのなら、Fang et al. (2017) や Ziegler et al. (2019) の系譜に気づかないはずがない。

mention のテスト。 のコードを LLM に解析させた。フォロー条件は profile にカナを含むことが必須になっている。一方、一度フォローしたアカウントのアンフォロー条件には profile カナ要件がなく、カナを含む short text note の投稿が直近であればフォローし続けるとのこと。 試しに profile に一時的にカナを加えたら実際にフォローされた。今度は profile からカナを消して様子見。 今回は zip で固めたコードを ChatGPT 5 Thinking に食わせてみたわけだが、コードに関する QA も問題なく行えるのは改めて考えるとすごい。

nowser の UI 上で remote app を消しても SQL のテーブルでは一部が残ったままになる謎挙動。こちらも issue report を書いてみた。 https://github.com/haorendashu/nowser/issues/4

issue report を書いてみた。 https://github.com/haorendashu/nowser/issues/3

Nowser は利用者の鍵こそ flutter_secure_storage.dat に保存するが、bunker 関係の情報は nowser.db に 平文で保存している。 私の理解が正しければ、もし第三者が nowser.db にアクセスできたとすると、bunker URL が復元できて、remote app を装って Nowser に接続を試みられる。 Nowser 利用者が何かの間違いで接続を承認したら、第三者 (偽 remote app) は本物の remote app と同じ権限を得てしまう。