自分のドメイン名には昔からあった個人・家庭向け Google Workspaces を使ってたんだけど、いい加減どうにかしようと重い腰を上げて、結局 Proton Mail でカスタムドメイン設定をして使うことにした。 Google workspaces は昔は個人向けの設定があって、しかも社員用割引で激安だったのもあって使っていたのだが、そういう利用形態向けの価格帯系がなくなって値上げがあり（自分も Google を辞めたので割引も効かなくなり）、ということがあった。あの値上げの時に個人用途でやめた人は多かったんじゃないか、と記憶している。自分もそのうち見直そうと思いつつ、設定等が面倒だったのもあってずっとそのまま使っていた。 で、やめるとしてどうするかというとドメイン名はそのままにただ Workspaces の利用をやめて個人の gmail.com のアドレスに転送するような設定を行う、というものが一般的かと思う。けど色々考え（すぎ？）た結果、 gmail 以外の環境のものもあった方がいいし、独自ドメインのメールは別個どこかのサービスを使った方がいいような気もしてきた。というわけで比較的知名度の高い Proton Mail を使ってみることにした次第。個人用としては gmail.com のメールアドレスを Gmail で、自分ドメインのメールアドレスを Proton で利用するという体制になりました。携帯電話にはアプリも入れた。 Proton Mail は無料でも利用できるが、カスタムドメインを使うには有料アカウント登録が必要で、 Mail Plus というものを年額契約で利用している（年額だと大体毎月$4くらい）。 Proton はメール以外にも色々なオフィススイートが用意されているみたいだけど、これまで自分のドメインの Workspaces では gmail 以外は使っていなかったので、メールしか使わないことにしてそういうプランで契約した。まあ他のも無料枠として使えるものもあるみたいなので使ってみてもいいかもな、せっかくだしな、という気もするけど。 というわけでこれまで通り私の独自ドメインのメールアドレスは利用可能ですが以降はメールサーバが変わりますという話でした。多分はたから見ると影響はないはず。そもそも普段の連絡はほぼ完全に gmail.com のばかりだし。 あと proton.me ドメインのメールアドレスもあわせて獲得したわけですが、こちらはまああんまり人にはお知らせしたりはしないかもなと思っております。その辺は今後どうなるか次第ではあるな。 そういえば proton mail にリファーラルがあるっぽい。興味ある人は https://pr.tn/ref/F089JE2C から登録してもらえると2週間は無料期間になるようです。そのままサブスクリプション成立してもらえると私に$20のクレジットが来るという仕組みらしいので、有料版に興味ある人は使ってみてください。

ブログをHugoを移行してから、まあいいんだけどブログにでも書いておこうかなというネタを携帯から書くというのが面倒になってしまった。 どうしようかなと思ってなんかAIに作ってみようかなとGeminiに相談してみたところ、decapCMSてのがあるよというのを見て、試してみている。 すごくいい、という感じではない。とくにエディタUIがいけてない気がする。モバイルフレンドリーでもないし。でもとりあえず走り書き的なことはしやすくなっているんじゃないか。知らんけど。 ログイン設定は色々はまった。Netlifyは使ってないのでできれば回避したいんだよなーということでカスタムのOAuthを利用している。 しかし使うかな？　まあどっちでもいいですが…。

LLMのAPIではストリーミング的にサーバからデータを断続的に受け取って、ちょっとずつ画面に出すということがよくあり、そのために Server Sent Events (SSE) というものがよく使われているようだ。 自作のAIコーディングエージェントでは、 Anthropic のLLMを呼び出すときに公式のSDKが見当たらなかったので自分で net/http を使って書いたときに、 SSE の仕様についても調べた。適当なクライアントライブラリを使ってもいいかなと思ったのだが、けっきょく仕様を調べて自分で簡単なパーサを書いたのだった。 SSE の仕様というか中身についてはそのとき MDN の記述 https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events/Using_server-sent_events#event_stream_format を参考にしたのだけど、この仕様のなんともいえない古臭さに驚いたのであった。テキストベースで行指向なフォーマット。こんなのが最新のLLMの根幹技術なの？って感じ。その分実装は割と簡単なのだけど。 それで改めて調べてみて知ったんだけど、 SSE ってめちゃくちゃ古い技術なのであった。初登場は 2004 年、仕様著者は hixie こと Ian Hickson。多分 Google 以前の作ですね。その割に全然存在を知らなかったし、全く使ったこともなかった。ブラウザAPIとかもあり、ブラウザ内で使うなら割と便利なのかもしれない。 HTTP で非同期にサーバからデータを送るというと例えば websocket があるのだけども、 websocket というのは http/2 ではいまだに使えないとか制限が多くて難しい。一方で特殊な content-type で断続的にテキストデータが返ってくるだけでそれをクライアント側でいい感じに解釈してもらうという SSE の方が取り回しが良く、現代でもよく使われる、といったあたりなのではないかと思う。また LLM の API セマンティクス的にも双方向非同期通信は必要なくてサーバから断続的にデータが送られればそれでいいから SSE が適している、といった話もある。 しかし、そういう事情は考えればわかるとしても、ウェブ仕様の発展を横目に見て 2004 年からある SSE が採用されているってのはなんだか味わい深い話だと思っちゃうんだよな。

そういえばここ最近、趣味プログラミングの一環としてコーディングAIエージェントを作っていた。もちろんLLMの部分は既存のものをAPIで呼び出すだけだけど。 https://github.com/jmuk/sylvan とりあえずGo言語で書いている。というのは他にGoで書いてるものが（いっぱいあるんだろうけど自分は）知らなかったので。でもこういうツールってシングルバイナリで配布できたほうがいいんじゃない？とか思っている。いや配布してないですけど。 さて、コーディングAIエージェントを作ってみて、まだまだ未完成だが「割と動く」ところまではかなりすぐできた。作り始めてから1週間ぐらいで初歩的なツールは大体作り終えて Hello, world プログラムを書いてもらってファイルに保存して実行して動作確認するみたいなところまではできている。これは自分がすごいということではなくて、最近のLLMってめちゃくちゃ賢いので、雑に作っても割と動いてくれるからである。初歩的なファイル操作ツールを実装して接続すれば結構動いてくれる。 もちろん「割と動く」レベルから使えるツールレベルに至るには膨大な労力が必要だということもわかっていて、個人で趣味でやっていても既存の他のツールと「戦える」ようなクオリティに到達するのはなかなか難しいだろうなということもわかってきた。例えば今は入力で使っているライブラリの関係で複数行入力ができない（enterを押した瞬間に入力が完了してしまい処理が始まってしまう）のだけど、複数行入力とか長文のプロンプトをコピペみたいなことができなくて不便。まあ趣味なので細々とやって行けたらいいかなぁとは思うけど。飽きるまでは。 ちなみに先日書いたように Advent of Code 2025 を自力で解き終わったので、AIにも解かせてみてどれぐらいできるのか確認してみようかな、と思い立ち、ちょっと解かせてみたところ割と解けた。でも初日でも結構色々苦戦していた。まあ今年の初日はちょっとコーナーケースとかハマりがちではあるのだけど、流石に苦戦しすぎではという気がした。でも9日目も11日目も割と苦戦の末に解けていたので偉い。自分で解くよりだいぶ速い。コードははちゃめちゃだけど。 MCPも実装しているので、Chrome MCPとかと繋いで、適当なログインアカウントも設定できれば、自力でページを見て問題をダウンロードして解答をサブミットするみたいなことまでできるだろうなとは思う。でも第三者のサービスでそういうことをするのは気が引けるので全てローカルで解いてみて自分の回答と一致しているかどうかで判定しています。

今年の Advent of Code を全部解いた。 Advent of Code は毎年この時期にやっているコーディングパズルサイトで、アドベントカレンダーみたいに毎日問題が解放されて解けるようになっている。サンタがプレゼントを配るのを手伝ったり、妖精がプレゼントを作るのにトラブルがあってそれを解決するには……みたいなちょっとしたストーリーがあって、それに基づいた問題になっている。毎日、簡単な準備編というようなパート1と、ちょっと難しくなるパート2に分かれる。 といっても、いわゆる競技プログラミングとかコーディングパズルみたいなのを想像すると、それよりはだいぶ退屈な課題が多い。特に序盤は「やるだけ問題」とでもいえばいいのか、言われた通りに書けば解けるようなごく単純な問題が多い。でも後半になると徐々に（時として急に）難しくなったり複雑化したりする。 で、例年やってるんだけどクリスマスに近づくと時間も取れなくなってきたりするし、なんだかんだで最後までやり切ることはあんまりなかったのだけど、今年は多分作者の都合か何かで全部で12日分しかないということでもう全問出てしまっていた。全部解けた。規模が小さくなってコアなファンとしては残念だろうけど自分としてはまあちょっとありがたかったかな。 問題としては9、10、11日目の問題はまあまあ面倒だった。特に9（パート2）はめちゃくちゃ面倒だったけど、なんか簡単な解き方があるのかなぁ。 で、12日目。これは問題作と思った。というかこれ難しすぎるのでは？と思ってよく見てみると……という。一体これなんなんだろ、というのをちょっと考えてみて、もしかするとコーディングAI対策なのかな、と思った。いや対策になっているのかどうかはわからないが、コーディングAIに解かせたらひたすら大変で時間（とトークン）を浪費することになりそうだ。が人間がよく見れば……という。知らんけど。 まあ特におすすめをするようなものではないけど、自分としては解けたので満足です。

半年ぐらい前のことだがロボット掃除機を買った。 Roborocks のやや前の型のやつ。 以前は Roomba を使ってたことがあるのだけど、引っ越しをしてからあんまり使わなくなって（床拭きの Braava ばっかり使うようになった）、それからまた引っ越したので改めてロボット掃除機を買った次第。以前の Roomba も型落ちのをタダでもらったものなので、相当なアップグレードである。 というわけで久しぶりにアップグレードされたモダンなロボット掃除機を使っていると、全然違ってかなりいい。壁とかにぶつかったりせずにスムーズに無駄なく掃除するし、部屋も認識して覚えている。自分がどの部屋にいるかもすぐ認識して動作する。携帯電話とかからも操作できる。便利だし隙がなく、よくできている。 よくできていて便利で快適なんだけど、ここに一抹の寂しさを感じてしまう。というのも、自分は subsumption architecture に思い入れがあるから。 subsumption architecture というのは90年代に流行った知能ロボティクスのアーキテクチャで、MITのRodney Brooksという研究者が作ったものだ。自律動作するロボットなんだけど、極々単純なルールとその優先度やオーバーライドの仕組みだけを用意しておき、これを組み合わせるだけでいい、というのがその思想である。例えば、単純な「ゴミ集め」というタスクがある。部屋の中にあるゴミを集めるというタスクで、ホッケーパックみたいなものをゴミに見立てて、これを拾ってゴミ捨て場まで運んでいくというタスク。部屋の中にはいろんな障害物があって、これを避けながらどのような経路で進んでゴミを拾ってゴミ捨て場まで行くか、というのがタスクになる。 subsumptionではこの場合、単純な「まっすぐ進む」「障害物にぶつかったら曲がる」「ゴミを見つけたらその方を向く」「ゴミを持っている時はゴミ捨て場の方を向く」みたいなルールだけを持っている。それだけなのに複雑な地形でもちゃんとゴミを見つけてゴミ捨て場まで運んでいけることが示されていた。 ダンゴムシってすごい単純な規則で動いていて、障害物にぶつかったらどちらにどれぐらい曲がるのが決まっていたりするでしょう。そんな単純なルールにも関わらずダンゴムシも複雑な動きを見せる。何故かというと環境が複雑だから。subsumption はそれと同じで、環境の複雑さによって知能が発現する、知能が環境に埋め込まれているとか言われていた。 この Brooks が共同創業者兼CTOとして立ち上げた会社が iRobot で、その民生用製品として作られたのが世界初のロボット掃除機 Roomba だった。だからそうなのかは全然知らんけど、自分としては Roomba の振る舞いにsubsumptionの影響を見ていた。単純な何パターンかの動きと、壁にぶつかるとこうするといったルールの組み合わせだけなのに、どんな形状の部屋でもきちんと掃除できる。複雑な部屋の形状や家具配置について対応するのではなく、単純かつ柔軟な構成の振る舞いが複雑な部屋にあることによって知的な行動が発現する。かっこいい！　みたいな。 なので iRobot が最近苦境だというのを知って寂しかったものだし、ロボット掃除機を買うにあたって検討はした。見当はしたが、やっぱり便利なのはこっちだよなと思って別の会社のものを買った。そしてそれに満足している。人に勧めるのも多分こういうやつだろう。そのことが少し寂しい。勝手な言い草だけど、そんなふうにも思ってしまうのである。 ちなみに余談だが、当の Brooks はとうの昔に iRobot の職を辞して別なロボットスタートアップを立ち上げ、それも畳んでまた別のロボットスタートアップをやっているらしい。当人すら move on してるのにわけのわからない外野に何か言う権利があるものだろうか。 （ところで私が大学院生だった頃から SLAM （simultaneous-localization-and-mapping）といって、未知環境に置かれたロボットが動き回りながらセンサ情報から自己位置同定と地図作成を同時に行うという研究が盛んに行われていた。ああいうのを真面目に研究していた人だと、現代のロボット掃除機などまさにその実用化として感慨深いものがあるのではないだろうか。当時は「技術的な面白さはともかく、未知環境でわざわざロボットが自力で地図作成しなきゃいけないような応用場面なんかあるんかいな。地図ぐらい設置時に与えればいいじゃん」などと思っていたものである）

私が個人的に「ソフトウェア開発におけるマーフィーの法則」と呼んでいるものがある。 マーフィーの法則というのは「失敗する可能性のあるものは失敗する」というもので、一般的にはある種のジョークというか皮肉として解釈されていると思う。まあ「フラグ」というか、これは絶対大丈夫でしょと思ってたものがいきなり壊れるというような。 でもソフトウェア開発をしていると、そういう不運とかフラグとかとは全然別な意味で、マーフィーの法則ってよく成り立つなと思うことがしばしばあるのだ。 ソフトウェア開発において書かれたコードというのは実際にリリースされると極めて高頻度に、何度も何度も実行される。実行条件は毎回少しずつ違う。また、ユーザ環境にインストールされるアプリやOS、フレームワークといったものの場合は、インストール環境が多種多様で微妙な違いというものが多数存在しうる。そんなとき、どんな僅かな確率であっても失敗する可能性があるのであれば、その失敗が発生するということはかなり確実に起こるのである。 例えばアンドロイド携帯の総出荷数は30億台だそうである。仮に100万回に1回しか起きないようなごくごく稀な事象であっても、単純な計算で全部のデバイスで1回ずつ実行するだけで3000台のデバイスに問題が生じる可能性があるということになる。何度も行うような操作の場合には問題の発生件数はもっと大きくなるだろう。 ソフトウェア開発をしていて、特に分散処理とかのややこしいレースコンディションや論理的な整合性に関する部分が微妙におかしかったりする。正しく直すのはかなり難しい、またはめんどくさい、しかしどのみち、現実的には到底起こりえないようなごくごく微妙な話でしかない、みたいなことはある。でもそのまま放置すると実際にはその問題が起こって問題を引き起こす、みたいなことが起こる。あるいは、バグレポートから調査をしていた結果、まさかそんなところで、みたいなところで問題が起きていたりする。こういうのは不運でもジョークでもなく、単に何度も何度も実行されるから。どんなに現実的に到底起こりえないような現象であっても、失敗する可能性のあるところで失敗するという事象は絶対に発生すると思っている。 なのでソフトウェア技術者としてマーフィーの法則ってよくあるよな、と思ってる。でもこれ自分だけが思ってることで人にあんまり話したことないんだけど、どうなんだろ。案外常識だろと思わない人もいそうである。 ところで関連する話として、スタニスワフ・レムに「枯草熱」というかっこいいタイトルの中編小説がある（タイトルの字面はかっこいいが、このタイトルは英語で言うと hey fever つまり花粉症のことだと知って大層がっかりしたものである）。中身はなんだかしょうもない結末でうーん面白くないな、と思ったものだが、この作品内に（記憶で書いているので細部は違っているかもしれないが）次のような話があって印象に残っている。 「テーブルがあって、そのテーブルを組み立てるのに使った釘がテーブルの面に見えているとする。水を一滴垂らしてこの釘を狙うのは到底できないことのように思える。でも雨が降ればその釘の上に雨粒が落ちないと言うことはありえない」 同様に、そんなこと狙ってもできないでしょ、と思うような、針の目を縫うような微細な条件でだけ発生する問題であったとしても、何度も何度も実行すればいつかはそういうことが起こる。多数の人に使ってもらうと言うのは雨が降るようなものだ。この例えはなんだかかっこいいなと思っていていつか使えたらいいなと思ってるのだけど、いまだに使えた局面というものがない。みんなレムの「枯草熱」なんて読んだことないだろうしな。ていうか読んでも総合的にはそんなに面白くもないしな。 （ところで余談だが、冷静になって考え直してみると、これは自分がソフトウェア開発者だからソフトウェアについてこう思うのであって、一般的に大量生産品の設計や製造というのはこういうものであるのかもしれない）

最近 Zhangliang Malatang という麻辣湯の店が流行ってる。勤務先のすぐ近くにも店舗があるので、会社のお昼にそこそこの頻度で行っている。バイキング形式で好きな具材をボウルに入れていき、それを指定のスープと麺で食べる。うまい。 そうやって選べる具材の中に Chiba Tofu ってのがある。あるな、とは思っていたが今まで入れてみることはなく、何なんだろうな、と不思議な気持ちでいたのだけど、今日行ったついでに入れてみた。カマボコみたいなモキュっという感じの食感が独特。味はふつうに豆腐、というか単体ではあまり味がしないが、スープの味を吸っているのでまあ別に不味くなりようがある感じではない。まあ食感を楽しむ食材って感じなのかな。自分はそこまでこういう食感を求めていないので他の豆腐の方が好きかなぁという気がするが全く普通に食べられる。 しかしこれはいったいなんなのだろうか。なんで豆腐なのにこんな食感なんだろう。ネットを検索してみたりしたところによると台湾生まれの食材で、豆乳に加えて大豆タンパク質とスターチを組み合わせてこの食感を作っているらしい。このカマボコとか、火鍋によく入っている魚肉団子とかみたいなモキュっとした食感、これがQというやつで台湾人の好みの食感だということみたいである。 それより気になるのはなぜチバなのかということではないか。台湾発の割に日本の地名となんか関係あるのか？　漢字では千叶豆腐と書くようだが、叶は簡体字では葉のことなので、まさしく千葉豆腐のことだ。でも葉の発音はイェみたいなかんじ、千はチエンみたいな発音のようなので、普通に考えたらこの表記でチバトーフにはなり得ないはずだけど。 他の検索結果を色々読んでいたら、こうした疑問に対する答えはwikipediaに書いてあった。 Thousand-layer tofu (simplified Chinese: 千叶豆腐; traditional Chinese: 千葉豆腐; pinyin: qiānyè dòufu; lit. ’thousand-layer tofu’) is not a true tofu made by coagulation of soymilk, but a modern invention made from soy protein isolate and a source of starch. It has a smooth, bouncy texture somewhat comparable to kamaboko. Originally a Taiwanese invention called hundred-layer tofu (百葉豆腐), it was renamed in China to avoid confusion with the existing type of extra-firm tofu called baiye. ...

本ブログは Hugo で書かれていて、更新すると github action の一環で自動的に Bluesky と Mastodon に「更新したよ」という投稿をするようになっているんだけど、Blueskyの方は link card が出てこなくて、なんか出てこないなーと思ってた。 このactionを使わせてもらっているのだけど、よくみると link-preview-url というのを指定するだけでいいのかな？　やってみたのでテストしてみたい。というわけで本件はそういうテスト投稿です。 というだけだと寂しいし、なんか画像も欲しいなと思ったので、少し前に Costco で見かけた怪しい日本ウィスキーの写真をあげておくことにする。この手の「日本風ウィスキー」はなぜかよく見かけるのだけど、微妙にへんなネーミングで笑ってしまう。 Kira Kira Koi。そしてRyujin。なんかすごそう感と高級感はある。しかし高級感のあるウィスキーにしてはキラキラは軽すぎだよなぁ。Ryujinはすごそうだけどウィスキーに龍神あるかな。 「渋い」そして「林」。「林」は、そういうのあるんですよと言われたらそうかもしれないという気はする。これがfakeとはこれだけで断言するのはちょっと難しい。でも聞いたことねえな。「渋い」はセンスがある（笑）。あと「い」の字形がなんというかすごいね。まぁこういうデザインにするということが日本語をきちんと理解している人から出てこないという断言もこれまた難しいわけですけれど、筆っぽいフォントでここまで丸い字形はちょっとどうかねえ。 こういうのが日本産のウィスキーなのかどうか、誰がどこでどう作ってアメリカで流通しているのか、みたいな解説は以前どこかで見かけた気もするけれど忘れてしまった。教えてくれる人がいたらありがたい。それにしてもCostcoならもうちょっとまともなのを売ってくださいよ。 というわけで小ネタでした。