Jun Mukai's blog

注音符号IMEを作った時のこと

Thu, 02 Apr 2026 22:35:20 -0700

たしか2011年のどこかで、ChromeOS用に注音符号によるIMEを作るという仕事があったことを思い出した。

注音符号は台湾で使われている漢字の発音（読み方）を表現するための記号だ。台湾で販売されているキーボードでは（JISキーボードに日本語のかなが刻印されているのと同じように）各キーに一つずつ注音符号が割り当てられていて、それで読み方を入力して漢字変換をするという入力方式がある。そういうIMEがChromeOSに必要だというので作ったのだったと思う。

と言っても変換エンジンの部分はオープンソースのライブラリがもうあって、それをそっくりそのまま使うだけ。当時のChromeOSはIMEフレームワークとしてIBusを使っていたので、そのAPIとライブラリを橋渡しするだけという単純なミニプロジェクトだ。

そもそもなんでこんなものが必要になったかというと、ChromeOSの特殊な制約による。変換ライブラリがあるぐらいなので、オープンソースのIBus向け注音符号IMEも存在していたけど、Pythonで書かれていたというのが問題だった。ChromeOSはセキュリティを頑張るというのがコンセプトの一つだったので、スクリプト言語の実行環境はバンドルしないというポリシーになっていて、そういうことのためにPythonを入れたりはできなかった。でもコアの変換エンジンはCのものがあるし、IBusも普通にいろんな言語のバインディングがあるからそこを繋ぐやつを書けばそれでオッケー、なのでそれをやってね、というかんじ。

だからまあやるだけという単純な仕事だと思ったし、実際にもそれほど時間をかけずに完遂したと思う。ただいざやってみたら色々面白い苦労があったことを覚えている。

ライブラリはある。インタフェースを眺めて使い方を調べてみるが……わかるようなわからないような。ドキュメンテーションを探してみる。が……中国語のドキュメントしかない！　そりゃまあ中国語を入力するものを使いたい人は中国語を読めるであろうというのは自然な考え方であろう。日本語IMEの変換エンジンのドキュメントも日本語ばっかりだったりするのは間違いない。が、困る。中国語、全然知らないので。

とりあえずGoogle翻訳で頑張って翻訳してもらう。ちなみにGoogle翻訳にディープラーニングが取り入られ、性能が著しく改善したのは2016年のこと。そのはるか以前の当時のGoogle翻訳はサポートする言語数は多いものの翻訳能力はまだまだ厳しいと言われていた（というのは随分やさしい表現で、もっと酷い言われようも普通だった）。が、ないよりはマシ。それで少しずつ全体像を理解していったような気がする。

しかも細かいところがちょっとよくわからない、みたいなこともあったような記憶がある。IMEの用語ってちょっと特殊で独特なところがある。例えば日本語を入力していて下線が引かれている入力途中の部分をなんというかというと、日本語では「未確定文字列」と言ったりする。この部分は英語だと preedit ということもあるし、 composition text ということもある（compositionだけになっていることもある）。ライブラリのパラメータ名とかフィールド名とかにはそういう単語が使われたりするわけだけど、そういう単語が微妙に違っているとかがあったんじゃなかったか。あと日本語入力のライブラリを作っていたりすると、多分無理に英語化したりせずに「読み」に対応するところを yomi にしちゃったりするでしょう。で、ドキュメンテーション上でも yomi の説明は「よみ」だったりする。昔のことすぎて何も覚えていないけど、そういうようなことがあったりして、どうしても細かいところがよくわからない、というふうになっていたんじゃなかったかな。

結局、カンと試行錯誤で色々試して動くものを作っていったと思う。でもそもそもどういう入力をしたらどういうふうに動作して、最終的に何が入力できたら嬉しいか、みたいなことも実際にはよくわからない。とにかく色々試して作っていった。なんであんなことしてたんだろうな。なかなか得難い経験であった。

（カンと試行錯誤ということからして、今だったらAIとかにやらせたらサクッと作ってくれたりするのかもしれない。が、IMEみたいなものはAIに実際に試してもらう環境を作る方が大変だったりすると思うので、いうほど簡単でもないだろう）。

ちなみにChromeOSのIMEフレームワークはその後も色々変わっていて、今ではgboardベースのIMEになっていたりするはずなので、この成果は今はもう使われていない。

個人ドメインのメールをProton Mailに移行した

Wed, 18 Mar 2026 23:54:24 -0700

自分のドメイン名には昔からあった個人・家庭向け 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のクレジットが来るという仕組みらしいので、有料版に興味ある人は使ってみてください。

携帯電話からブログネタを書くための試み

Thu, 15 Jan 2026 22:29:00 -0800

ブログをHugoを移行してから、まあいいんだけどブログにでも書いておこうかなというネタを携帯から書くというのが面倒になってしまった。

どうしようかなと思ってなんかAIに作ってみようかなとGeminiに相談してみたところ、decapCMSてのがあるよというのを見て、試してみている。

すごくいい、という感じではない。とくにエディタUIがいけてない気がする。モバイルフレンドリーでもないし。でもとりあえず走り書き的なことはしやすくなっているんじゃないか。知らんけど。

ログイン設定は色々はまった。Netlifyは使ってないのでできれば回避したいんだよなーということでカスタムのOAuthを利用している。

しかし使うかな？　まあどっちでもいいですが…。

Server Sent Events とかいう実は太古のテクノロジー

Thu, 25 Dec 2025 22:41:03 -0800

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 が採用されているってのはなんだか味わい深い話だと思っちゃうんだよな。

コーディングエージェントを自作してみている

Sun, 21 Dec 2025 21:58:26 -0800

そういえばここ最近、趣味プログラミングの一環としてコーディング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 2025 解いた

Thu, 18 Dec 2025 22:04:10 -0800

今年の Advent of Code を全部解いた。

Advent of Code は毎年この時期にやっているコーディングパズルサイトで、アドベントカレンダーみたいに毎日問題が解放されて解けるようになっている。サンタがプレゼントを配るのを手伝ったり、妖精がプレゼントを作るのにトラブルがあってそれを解決するには……みたいなちょっとしたストーリーがあって、それに基づいた問題になっている。毎日、簡単な準備編というようなパート1と、ちょっと難しくなるパート2に分かれる。

といっても、いわゆる競技プログラミングとかコーディングパズルみたいなのを想像すると、それよりはだいぶ退屈な課題が多い。特に序盤は「やるだけ問題」とでもいえばいいのか、言われた通りに書けば解けるようなごく単純な問題が多い。でも後半になると徐々に（時として急に）難しくなったり複雑化したりする。

で、例年やってるんだけどクリスマスに近づくと時間も取れなくなってきたりするし、なんだかんだで最後までやり切ることはあんまりなかったのだけど、今年は多分作者の都合か何かで全部で12日分しかないということでもう全問出てしまっていた。全部解けた。規模が小さくなってコアなファンとしては残念だろうけど自分としてはまあちょっとありがたかったかな。

問題としては9、10、11日目の問題はまあまあ面倒だった。特に9（パート2）はめちゃくちゃ面倒だったけど、なんか簡単な解き方があるのかなぁ。

で、12日目。これは問題作と思った。というかこれ難しすぎるのでは？と思ってよく見てみると……という。一体これなんなんだろ、というのをちょっと考えてみて、もしかするとコーディングAI対策なのかな、と思った。いや対策になっているのかどうかはわからないが、コーディングAIに解かせたらひたすら大変で時間（とトークン）を浪費することになりそうだ。が人間がよく見れば……という。知らんけど。

まあ特におすすめをするようなものではないけど、自分としては解けたので満足です。

ロボット掃除機を買った時の寂しさ

Thu, 04 Dec 2025 10:59:00 -0700

半年ぐらい前のことだがロボット掃除機を買った。 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）といって、未知環境に置かれたロボットが動き回りながらセンサ情報から自己位置同定と地図作成を同時に行うという研究が盛んに行われていた。ああいうのを真面目に研究していた人だと、現代のロボット掃除機などまさにその実用化として感慨深いものがあるのではないだろうか。当時は「技術的な面白さはともかく、未知環境でわざわざロボットが自力で地図作成しなきゃいけないような応用場面なんかあるんかいな。地図ぐらい設置時に与えればいいじゃん」などと思っていたものである）

ソフトウェア開発におけるマーフィーの法則

Mon, 24 Nov 2025 23:09:05 -0800

私が個人的に「ソフトウェア開発におけるマーフィーの法則」と呼んでいるものがある。

マーフィーの法則というのは「失敗する可能性のあるものは失敗する」というもので、一般的にはある種のジョークというか皮肉として解釈されていると思う。まあ「フラグ」というか、これは絶対大丈夫でしょと思ってたものがいきなり壊れるというような。

でもソフトウェア開発をしていると、そういう不運とかフラグとかとは全然別な意味で、マーフィーの法則ってよく成り立つなと思うことがしばしばあるのだ。

ソフトウェア開発において書かれたコードというのは実際にリリースされると極めて高頻度に、何度も何度も実行される。実行条件は毎回少しずつ違う。また、ユーザ環境にインストールされるアプリやOS、フレームワークといったものの場合は、インストール環境が多種多様で微妙な違いというものが多数存在しうる。そんなとき、どんな僅かな確率であっても失敗する可能性があるのであれば、その失敗が発生するということはかなり確実に起こるのである。

例えばアンドロイド携帯の総出荷数は30億台だそうである。仮に100万回に1回しか起きないようなごくごく稀な事象であっても、単純な計算で全部のデバイスで1回ずつ実行するだけで3000台のデバイスに問題が生じる可能性があるということになる。何度も行うような操作の場合には問題の発生件数はもっと大きくなるだろう。

ソフトウェア開発をしていて、特に分散処理とかのややこしいレースコンディションや論理的な整合性に関する部分が微妙におかしかったりする。正しく直すのはかなり難しい、またはめんどくさい、しかしどのみち、現実的には到底起こりえないようなごくごく微妙な話でしかない、みたいなことはある。でもそのまま放置すると実際にはその問題が起こって問題を引き起こす、みたいなことが起こる。あるいは、バグレポートから調査をしていた結果、まさかそんなところで、みたいなところで問題が起きていたりする。こういうのは不運でもジョークでもなく、単に何度も何度も実行されるから。どんなに現実的に到底起こりえないような現象であっても、失敗する可能性のあるところで失敗するという事象は絶対に発生すると思っている。

なのでソフトウェア技術者としてマーフィーの法則ってよくあるよな、と思ってる。でもこれ自分だけが思ってることで人にあんまり話したことないんだけど、どうなんだろ。案外常識だろと思わない人もいそうである。

ところで関連する話として、スタニスワフ・レムに「枯草熱」というかっこいいタイトルの中編小説がある（タイトルの字面はかっこいいが、このタイトルは英語で言うと hey fever つまり花粉症のことだと知って大層がっかりしたものである）。中身はなんだかしょうもない結末でうーん面白くないな、と思ったものだが、この作品内に（記憶で書いているので細部は違っているかもしれないが）次のような話があって印象に残っている。

「テーブルがあって、そのテーブルを組み立てるのに使った釘がテーブルの面に見えているとする。水を一滴垂らしてこの釘を狙うのは到底できないことのように思える。でも雨が降ればその釘の上に雨粒が落ちないと言うことはありえない」

同様に、そんなこと狙ってもできないでしょ、と思うような、針の目を縫うような微細な条件でだけ発生する問題であったとしても、何度も何度も実行すればいつかはそういうことが起こる。多数の人に使ってもらうと言うのは雨が降るようなものだ。この例えはなんだかかっこいいなと思っていていつか使えたらいいなと思ってるのだけど、いまだに使えた局面というものがない。みんなレムの「枯草熱」なんて読んだことないだろうしな。ていうか読んでも総合的にはそんなに面白くもないしな。

（ところで余談だが、冷静になって考え直してみると、これは自分がソフトウェア開発者だからソフトウェアについてこう思うのであって、一般的に大量生産品の設計や製造というのはこういうものであるのかもしれない）

チバトーフの謎

Mon, 08 Sep 2025 21:20:04 -0700

最近 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.

怪しいニセ日本ウィスキー@costco

Sat, 06 Sep 2025 21:45:51 -0700

本ブログは Hugo で書かれていて、更新すると github action の一環で自動的に Bluesky と Mastodon に「更新したよ」という投稿をするようになっているんだけど、Blueskyの方は link card が出てこなくて、なんか出てこないなーと思ってた。

このactionを使わせてもらっているのだけど、よくみると link-preview-url というのを指定するだけでいいのかな？　やってみたのでテストしてみたい。というわけで本件はそういうテスト投稿です。

というだけだと寂しいし、なんか画像も欲しいなと思ったので、少し前に Costco で見かけた怪しい日本ウィスキーの写真をあげておくことにする。この手の「日本風ウィスキー」はなぜかよく見かけるのだけど、微妙にへんなネーミングで笑ってしまう。

Kira Kira Koi。そしてRyujin。なんかすごそう感と高級感はある。しかし高級感のあるウィスキーにしてはキラキラは軽すぎだよなぁ。Ryujinはすごそうだけどウィスキーに龍神あるかな。

「渋い」そして「林」。「林」は、そういうのあるんですよと言われたらそうかもしれないという気はする。これがfakeとはこれだけで断言するのはちょっと難しい。でも聞いたことねえな。「渋い」はセンスがある（笑）。あと「い」の字形がなんというかすごいね。まぁこういうデザインにするということが日本語をきちんと理解している人から出てこないという断言もこれまた難しいわけですけれど、筆っぽいフォントでここまで丸い字形はちょっとどうかねえ。

こういうのが日本産のウィスキーなのかどうか、誰がどこでどう作ってアメリカで流通しているのか、みたいな解説は以前どこかで見かけた気もするけれど忘れてしまった。教えてくれる人がいたらありがたい。それにしてもCostcoならもうちょっとまともなのを売ってくださいよ。

というわけで小ネタでした。

Google日本語入力の思い出：クラウド変換のいま

Thu, 04 Sep 2025 20:36:26 -0700

Google日本語入力チームでは、割と初期に関わって細々としたことを色々やってきたのだけど、今回はそのうちの機能の一つの思い出を思い出したので書いておこうと思う。

2009年くらいのことだったかと思うが、今はなきGoogle Labsの一部だったか何かで「ブラウザの中でGoogle日本語入力を使って入力する」という機能を作って出したということがあった。変換エンジン自体はサーバサイドで動いていてひらがな列から変換候補を返すというようなAPIを作り、ブラウザ側ではキー入力に応じてローマ字かな変換をした上でこのAPIを叩いて日本語入力・変換UIを作るというようなものだった。このアーキテクチャはMozc / Google日本語入力の基本的なアーキテクチャとは根本的に異なるが（Google日本語入力では、変換エンジンはキーイベントを受け取ってローマ字変換も含めたロジックを全てプラットフォーム共通の変換エンジン側に持つ）、ブラウザ内での動作ということなどからして、少なくとも当時としてはこの方が当然というような構成だったと言えるだろう。変換API自体も外部から叩けるようにしていたと記憶している。

ちなみに、この機能自体は細々と存在しているし、実はGoogle製品、例えばGmailやGoogle Docsといった製品でもブラウザ内で日本語を含む様々な言語での変換・入力を行うという機能が組み込まれている。私が関わったのはだいぶ昔のことなので現代の構成にどれぐらいの痕跡が残されているかは定かではないというか多分もう全然違う何かではないかと思うけれど、少なくともその源流となる何かを作ったのは私である（もちろん私だけじゃないです、一応念のため）。海外旅行中とかみたいな、日本語入力環境のないパソコンで日本語入力をどうしてもやりたいみたいな時はこの機能を使うと最低限の入力ができるので今度機会があったら使ってみてください。

さて話は変わるけれど、Mozc / Google日本語入力には特定の入力パターンに対して動作する特殊なロジック・変換というものが存在している。内部的には rewriter と呼ばれている。例えば「ばーじょん」と入力して変換すると、その時のMozc / Google日本語入力の変換エンジンのソフトウェアバージョンが変換候補として出てくるようになっている。この機能はGoogle日本語入力が外部に公開されるより前からあった機能だったはず。というのも、社内で誤変換や微妙な変換候補をフィードバックとして募りたいわけだけど、どのバージョンで起きた問題かがわからないとフィードバックとしてもあまり意味がない。でもソフトウェアのバージョンを探してコピペするというのは面倒なものだし、どうやって探すかみたいなドキュメントを整備するのも大変だ。でもこの機能があれば、フィードバックの時に「バージョンと入力してその結果を書いてください」としておけばそれで済む。

他にも例えば、算用数字から漢数字への変換を行う数値変換rewriterとか、数値＋年から年号を変換する（「1467年」から「応仁元年」を変換できるなど）みたいな年号rewriterとか、「今日」「明日」「昨日」みたいなものから具体的な日付を変換候補に出したり、「今」などから現在時刻を変換候補に出せる日付・時刻rewriterとか、そういうものが色々用意されている。私も数値変換とかの最初のバージョンを作ったりした。

ここからが本題。「ブラウザ内日本語入力」を外部に公開してやれやれと肩の荷を下ろした気分でいたある日、ふとこのrewriterのことを思い出した。で「今」をブラウザ内で変換してみると……時刻が表示される（当たり前だが）。でもそれは変換エンジンが動作しているサーバでの現在時刻であって、日本時間の時刻じゃない。つまり全然間違った変な時刻が表示されている！

困った。ここには3つの問題があった。第一に、日本語入力というものを行う人はほとんど日本からのアクセスだと思うけれど、間違った時刻が表示されてしまうという問題である。これは普通に誤変換の一種でなんとかした方がいい。第二に、サーバ内のソフトウェアがどんなタイムゾーンで動作しているか、という本来は公開されていない情報がうっかり公開されてしまっているという問題である。これは別に大問題ということはないだろうけど、しなくていいものは公開されない方がいい。第三に、変換候補はキャッシュされたりしうるので、へんな時刻がどこかで覚えられるとその時刻のまま更新されなくなってしまうという問題である。

どうしたもんだろうか？（ちなみに当時のブラウザJSにはタイムゾーン関係のAPIとか全然なかったように思うので、タイムゾーン情報を送ってサーバ側で適切に処理する、みたいなことは不可能であったはず）例えば、変換結果には特殊な結果（例えば @now とかみたいな）を入れておき、それを現在時刻に変換するロジックをJSでかく、みたいなことが考えられなくもない。このアプローチは（サーバとクライアントに分かれているわけではないが）SKKという入力エンジンではそういうようなことが実現されている。でもこれすると副次的に「通常の変換結果として偶然にそのパターンが出てきたらどうするか」みたいな問題も考えないといけないし、既存のrewriterの実装もサーバ用に書き直さないといけないし、JSを書き直すのも一苦労である。

私はもっと単純な方法を取ることにした。単純に日付など時と場合によって変換結果が変わるようなrewriterは機能を省くことにしたのである。ifdefか何かを足して、APIサーバとして動作する時には使われないようにした。もちろん数値変換とかみたいに便利な機能はキープしたいけれど、時刻とかみたいな別になくてもいい機能については選択的に省くことにした。

今、オープンソースとして公開されている Mozc の rewriter.cc をみても、 MOZC_DATE_REWRITER が変な場所に定義されていてオフしやすそうになっている。これは多分当時の名残で、内部的には条件的にオフできるようになっていたりするからなんじゃないだろうか。すぐ近くに出てくる「FORTUNE_REWRITER」も「おみくじ」で今日の運勢（大吉とか）が出てくるという隠し機能で、同じような理由でAPIサーバからは省いたのだと思う。

そういうわけで「うっかりサーバが動作しているタイムゾーンが外部からわかるようになってしまっていた」という話でした。

最近shpoolを使っている

Tue, 02 Sep 2025 16:36:45 -0700

そういえば最近になって、 shpool のことを思い出して使っている。

Shpool は ssh のセッション維持だけをしてくれるだけのツールだ。リンク先でもあるように、tmuxとかGNU screenとかのうち、セッション維持だけしか使ってないんだよなという自分みたいな人間のニーズを満たしてくれるツールである。確か昔 Hacker News で紹介されて存在を知ったのだと思う。

昔は自分も GNU screen を使っていて、ある時期から tmux に移行していたわけだけど、やがてこういうツールを使うのをやめてしまった。

やめちゃった理由だけど、そもそもターミナルを使ってなんでもやる、というようなワークフローから変わってしまったというのが一つある。昔は Emacs もターミナルの中で動かして、Emacsのタブとシェルのタブがあったりしたのだけど、今は VS code やその派生物を使っている。結局使ってるタブは一つだけ、みたいな状況になってきた。

それでも tmux の大きな利点としてセッション維持というのはある。作業環境はリモートにあるLinuxで、手元のラップトップデバイスからそこにアクセスする、みたいな仕事環境だったりして、そうなるとやっぱり細かなこと（出勤中に微妙にオフラインになるとか）でセッションが途切れちゃうのは結構悲しい。が、正直なところセッション維持のためだけに使うには tmux は微妙だな、とも思っていた。一番大きな問題として、tmuxが画面全体を支配してしまうというのがあると思っている。スクロールヒストリなどもtmux任せになり、そちらのキーバインドを覚えないといけないし、せっかくのターミナルアプリ側のヒストリには何にも残らない。

で、単にシェルをそのまま使っていて、タブなどはターミナルエミュレータアプリのタブ機能を利用していた。正直これで自分的には全然問題ないと思っている（自分は画面分割とか凝ったレイアウトは全く使わない主義だったし）。でもまぁたまにセッションが切れるのが不便だなとは思っていた。

そこで shpool です。 shpool は上で述べたような不満が全て解消されている。機能がセッション維持に特化されていてタブとかそういう機能は一切ない。そういうのはターミナルエミュレータを使えばいい。そういう割り切りというか、自分的には欲しい部分だけがある、といったツールであった。

githubのREADMEでは、デーモンを立ち上げてsshの設定で……みたいな凝った設定が書かれているが、そういう凝った設定は一切やっていない（面倒なので）。ログインしたら手動で shpool attach main みたいな雑な名前のセッションにアタッチするだけということをやっている。面倒？　いや自分としては別に面倒でもないかな。

不満点。プロンプトに勝手に shpool セッションの情報を表示してくれるのだけど、なんか他の機能と conflict しているような気がする。あんまり調べていないがちょっと微妙。あとたまにおかしな挙動になって復旧などで困ることがあるのだけど、再現条件等が煮詰まっておらずよくわかってない。ターミナルを制御するアプリ起動時にセッションが切れるとターミナルの状態がおかしくなる、とかだろうか。あと disconnected 状態になったセッションがンビ化することがある気がするのだけど、これも再現条件とかがよくわからないし対処法もよくわからない時がある。ツールとしてはもう少し成熟する余地がありそうなのだけど、この辺は自分で貢献するところまではなかなか行かなそうなので頑張って欲しいなぁなどと他人事で思っている。

Hercule Poirot Pronunciation

Mon, 18 Aug 2025 00:45:14 -0700

最近、子供が図書館で借りてきた本に、 the Mysterious Affair at Styles （『スタイルズ荘の怪事件』）を子供むけに翻案した絵本というのがあった。それで久々にポアロのことが色々気になってきた。スタイルズ荘も未読だったので英語で改めて読むということをしている。

さて子供に読み聞かせたりしているうちに、この名探偵の名前をどう発音したらいいかということがよくわからなくなってきた。日本では一般的にはエルキュール・ポアロという表記で知られていると思う（ポワロかもしれない）。ポアロはフランス語話者のベルギー人なので、自身の発音に則するとすればhは当然発音せず、カタカナにすればエルキュールに近い発音になることだろうとは思う（ところでポアロの名前が Hercule だというのも、ごく最近になるまで知らなかったというか考えたことがなかったように思う。ヘラクレスに対応するローマ神話の神様の名前から来ているということで、それで名探偵の小男というのがギャップな名前だったわけですね）。でもクリスティはイギリスの人だし原書は元々英語で書かれている。英語圏の読者たちがポアロをどのように呼んでいたかというのは、そうした設定に対して忠実であるとは必ずしも言えるわけでもない。

ちなみに絵本には発音ガイドが載っていて、めちゃくちゃhを発音する普通の英語発音であった。でもそれじゃ雰囲気でないと思うんだよなぁ。

一方軽くググってみたところ Oxford Learner’s Dictionary ではhは無音ということが示された。Googleの発音ガイドはhを発音するが、下に出てくるAI Overviewではhを無音とする情報、というふうにもなっている。

というわけで調べれば調べるほど訳がわからないのであった。でもまぁアメリカ人的にはどっちでもいいのかもしれない。イギリス人的には知らんけど……。

他の音声的情報源といえば、ドラマ版がありそうではある。デヴィッド・スーシェが演じてたアレ。私も子供の頃は大好きでよくみてました。もちろん自分が観てたのは熊倉一雄の吹き替え版だけども今の自分なら英語で観ればドラマ内の発音はわかるはずだ。もっともエピソードたくさんあるしそんなにHerculeの方は呼ばれていた気がしないが……とYoutubeで検索してみたところ、ありがたいことに「ポアロが自分の名前を呼んでるシーン集」という動画があった。自分ではやっぱりエルキュールと発音しているな。

ただ自分でというならベルギー人という設定なのでそれはまあ当然という気もする（それにしても……改めて聞くとデヴィッド・スーシェの発音ではrの発音が全くフランス語ぽくない）。どちらかというと周囲の英語話者キャラクターたちがどう呼んでいたかもみたい気がするがそっちはよくわからない（Mr. PoirotとかMonsieurとか呼ばれていてなかなかファーストネームが呼ばれない）。もちろんドラマ内の描写は、当時や現代の英語話者の読者が彼をどう呼んでいるか、ということはあまり含意しない気もしないでもない。

でもまぁやっぱり自分はhを発音しないエルキュール的な発音で行きたいな、と思いました。それで通じるのか知らんけど。

About

Mon, 11 Aug 2025 22:19:18 -0700

向井淳。ソフトウェアエンジニア。カリフォルニア州在住。

ブログの内容は個人の見解であり、所属先等を代表するものではありません。

ドッジボールが日本国内と国外で全然違う

Wed, 06 Aug 2025 23:05:49 -0700

去年のことだが、会社のオフサイトイベントに行ったら余興の一環としてランダムに組まされたチームでいろんなタスクをやるというよくある遊びがあった。で、タスクの一つがドッジボール。

日本で育ったオタク・インドア・運動苦手勢は全員同じ気持ちがあると思うがドッジボールには何一つとしていい思い出がない。できれば一生関わることなく生きていたいし、まあ大人になれば関わるようなことはまずない。そういえば、かつてGoogle東京で働いていた時にも会社イベントでドッジボールやろうかみたいな話が出たことがあったが、一部のソフトウェアエンジニアたちからの強い意向により取りやめになったということがあったことも思い出す。

そんなわけでドッジボールか……とちょっと嫌な気持ちになったが、まあみんな大人だし俺も大人なので適当にこなそう、と素知らぬ顔で参加した。そしたらルールが結構違っており、そしてやってみたら結構楽しかった。まあ自分は全く活躍しなかったけど、それはそれ、これはこれ。大まかなルールは一緒なのに、細かな違いでこんなに変わるものかと感心したのであった。

あとで軽く調べてみたところによると、日本のドッジボールは日本で独自に発展・進化して成立していった独自ルールであるようだ。

ここを読むような人は知らないことはないと思うけど、日本のドッジボールのルールというのは次のようなものだろう。

２チームに分かれてボールを投げ合う。一方のチームの誰かが手で投げたボールに当てられたらその人は退場。どちらか一方のチームが全員退場したらそのチームの負け。
長方形のコートを2つに分け、各チームがそれぞれ自分のエリア（内野）内にとどまる。退場した人は「外野」と呼ばれ、敵チームエリアの外側に行く。
ボールは1個、バレーボールやサッカーボールのようなものを使う
誰にも当たらずエリアの外に出たボールは外野が拾い、敵チームへの攻撃に使う
ボールを当てられても地面に落ちる前に拾えればセーフ

自分が体験したドッジボールは、その後にウィキペディアなどで見るとアメリカなどで一般的なルールのようだった。大きな違いは、

ボールが複数、大体チームの人数分ぐらいある（9vs9だとボール9個ということ）
ボールは中が空気の軽くて小さなボールを使う。大体ソフトボールくらいの大きさのやつ（utility ballという）
スタート時点で、ボールは自陣と敵陣を分ける線上に配置されている。スタート時点ではチームは全員外で待機し、スタートと同時に走ってボールを拾いに行く
外野は自陣の奥に待機し、敵を攻撃したりできない
投げられたボールをキャッチできると敗者復活で、外野から一人戻れる

といったところであった。大きな違いは「ボールの数」「ボールの大きさ・硬さ」「外野が攻撃できない」だ。

日本のドッジボールはボールが一つしかないので、強い人がいるとその人がボールを占有して攻撃し続けるサイクルになりやすい。それ以外の自分みたいな人は基本的には標的であり、いかにうまく避けるかしかやることがない。でも避けてもボールはそのまま外野に流れてまた攻撃されるだけだし何も面白くない。ボールは結構硬くてあたれば割と痛い。総じて体格が良くて運動の得意な子がそれ以外をひたすら攻撃し続けるだけの競技だと思う。

ボールが複数あると展開はスピーディになるし、どちらかの攻撃というだけではない複雑な展開が行われる。誰を狙おうかなとのんびりしている余裕はないというかボールを持って振りかぶってるやつなんて狙われてしまう。ボールはやや小ぶりで柔らかく、当たっても痛くない。そもそもスピードが乗せづらい。後ろの外野は味方なので、うまく避けれれば自分にボールが供給され攻撃側になるチャンスも多い。ボールが増えるだけでこんなに変わるものかと感心するくらい全然違うスポーツであった。

もちろん、自陣最後の一人になったら狙われまくったりしてあまりいい気はしないだろうし、どんなボールでも（特に子供なら）当たったら痛くていやな気持ちにはなろう。それにこのルールだと敗者復活は結構稀な現象な気がして、ゲーム序盤で当てられてしまって退場したら後は玉拾いぐらいしかやることがないという話はある。あと何にしても体を使うので運動そのものがいやならいやだとは思う。

けど総じてこちらのドッジボールの方が余興むきだし子供同士の遊びにも向いているように感じた（もちろんcompetitiveな世界ではまた違った話ではあるのだろうとは思うのだけど）。というか日本ではなんであんな硬いボールでドッジボールやってるんだろうか。っていうのはそれが一番学校で常備されているからだろうけど、さすがにやめた方がいいのでは、と思うのだけど。

ともあれ、同じ単語でもこんなにも違いがあるものかと結構驚いたのだったし、そもそもこんなにルールが違うものが同じ名前で何の説明もなく併存しているのに結構ビビったのであった。ドッジボールやろうぜ、と言われてイメージする風景が違いすぎる。今から思えば、Google東京であっても日本育ちの人ばかりではなく、当時提案されていたドッジボールはこういうアメリカっぽいやつだったのかもしれない。だとしたら悪いことをしたかな……とまでは思わないけど、不幸な行き違いというか誤解というか、そういう何かではあったのかもしれない。まさかこんなものの中身が違うとか、思わないよね。

芝刈りする動画を見てる

Thu, 10 Jul 2025 23:11:00 -0700

最近よく YouTube で lawn mowing の動画をみている。多分いろいろ類似のチャンネルがあると思うけど自分がよくみているのは SB Mowing というやつ。自分の近隣ではちゃめちゃに伸び切った芝生（とか）のあるうちに行って、「Youtubeで動画をやってるから、タダで刈ってあげるよ」といって交渉して、刈って、掃除して、何もかもきれいにしてしまう。

どうも人類というのは「メチャクチャで乱雑なものがきれいに整頓されるのを眺める」というのが好きなんではないか。こういう芝刈りとかの他にも、排水溝の詰まりを取り除くやつとか、そういうのも微妙な人気を博していたりする。そういえば自分は以前には、伸びすぎた家畜のひづめをきっちりと削って、問題があったらそれを治すという削蹄系の動画をよく見ていたけど、あれも似たようなものだと思う。他にも絨毯の清掃、家のリモデル、そう言った動画が無数にあってそれなりに人気を博しているようだ。

……「人類」は主語でかすぎた。でもまあそういうのを見たいという気持ちのある人はそれなりにいる、とは言っていいと思う。例えば自分の見てるこのチャンネルも何百万人というフォロアーがいて、芝刈りしてるだけの30分ほどの動画も何百万人という人が見ていたりする。などと他人事風にいうまでもなく自分もたまにだが見ている。よく考えるとなんとも不思議な世界である。

まあそれだけの話なんだけど、そういう無償の芝刈り奉仕活動を眺めていくうちに、なんというか不思議な気持ちが芽生えてきた。

この SB Mowing という会社（なのかどうなのか）が今でも普通に芝刈り・ガーデニング業をやってるのかはよくわからないが、少なくとも動画で取り上げるネタはいつも完全にタダというか、家主側は何も払わなくてもいいようになっている。動画によっては、お金がほとんどなくて体の自由も聞きづらい老人の家だったり、もう空き家になって何年も経つような家も多い。というか、動画のネタになるようなとんでもないぐらい伸び放題になっている家というのはそういう訳ありのところが多いからではあるだろうが、そういうところの芝を整えてあげるというのは結構な地域貢献になっているんではないだろうか。景観の話だけじゃなく、虫とかの発生源になってたりすることもあるだろうし。

で、そんなことを無償でやっていて偉い、という気持ちはもちろんあるけれど、でも考えてみれば実際には彼にはYouTubeから動画の広告収入という形で労働代が賄われているという話でもある。いや現実には動画スポンサーがいたりグッズ販売とかも手掛けていたりするので広告収入だけってことではないのだけれど、あれだけ嫌われている広告が巡り巡って地域貢献につながっているっていうところに不思議な感覚を覚えるのだ。

まぁ実際のところ私はPremium入ってるんで広告を見ているわけではないし、自分がこういうのを見てることというのを広告収入とか言っていいのかどうかもよくわかんないんですけど。

AI Browser hype

Thu, 10 Jul 2025 22:28:51 -0700

OpenAI がブラウザを出すらしいという話が盛り上がっているが、実際のところどうなんだろう？　みんなブラウザにそんなAI機能欲しい？

ここ2週間くらい Dia というブラウザを使っているが、けっきょくAI機能はほとんど触ってない。

このブラウザでは、今見てるページについていろいろ質問できたり、テキストボックスに（そのコンテキストに合わせた）文章生成できたり、new tab page がチャットUIと統合されていて検索する代わりにいろいろ質問・チャットできる。最後のやつでは色んなWebページを閲覧して “deep research” っぽいこともできたりするし、今開いているタブを参照していろいろできたりする。

けど、普段のウェブブラウジングでそんなことあんまりやらないんだよな。私用のMacで用途が限定されているというのはあるが、見てるページを要約して欲しいことってそんなにあるのだろうか。全くないとは思わないけど、たまにだったら別タブで好みのLLMのページを開いてコピペしても大した手間でもないような気がしてしまう。テキスト生成も同様で、インストール初日に生成してもらったことがあるがその後一度も使っていない。

検索で色んなページを見られるのは使い出がありそうに思えるんだけど、でもまぁ各社のLLMで “deep research” 機能を使うのと比べて何が違うのかというと……違いはあるといえばあるだろうがそんな大きな差がある気がしないのだよね。

Arc Max

ところでそういえば Dia の前身である Arc ブラウザには Arc Max というブランディングのAI機能が搭載されていた。Arc MaxはLLMの機能を使ってブラウザのよくある機能をほどよくアシストする機能で自分はなかなかよかったと思っていた。具体的には、

ブックマーク時にページタイトルを内容に即して書き換える機能
ページ内検索と統合され、曖昧に検索したりページ内の内容に質問できる機能
リンクをマウスカーソルでホバーするとリンク先のページを閲覧して要約し、要約をポップアップで表示してくれる機能

最後のやつとか、 Hacker News みたいなリンクがいろいろある中でいちいちクリックしなくてもどんな内容か（人々の反応がどんなであるか）を教えてくれて結構便利に使っていた。

Diaにはこういう機能が全然ないんだよな（タブの中身に基づいて質問したりする機能はあるけど）。なんだか残念。チャットUIを前面に出してくるのはわかりやすいが、こういうふうにさりげなくアシストする機能としてAIを使う方が未来があるしブラウザにAIを統合するという意味では正しい進化だと思うのだけど。

Dia skills

そういえば上で言及してなかった機能として Dia には「スキル」という機能があった。なんらかの固定プロンプトを盛り込むことで特定のよくある作業を自動化するもので、かつLLMがいるので自動化といっても自然言語でやることを書けばいい、みたいなものだ。例えば「The VergeとEngadgetとTechCrunchを見て今日のトップニュースを教えてください」みたいな「スキル」を自分で設定して、それを呼び出せばいい。

これ全然使ってなかったのを思い出したので、まさにこのテックニュースのスキルを作ってみたのだけど……うーん、まあ悪くはない。がしかしブラウザに盛り込んであって嬉しいものなのかもよくわからなくなってしまった。そういうエージェントツールがあればいいんではないか？　それこそ paywall でブロックされたニュースメディアとかもブラウザなら読めるから、という話はないでもないだろうけれども、どうにもモニョモニョした気持ちになる。ブラウザを作っている会社がだしたのでブラウザになっていますという以上の何かなのかはまだよくわからない。

AIブラウザはハイプか？

というわけで「AIブラウザ」っていかにも the next big thing っぽさがあるテーマなのだけど、そこまで便利なのかというのには疑問を感じてしまっている。 Google Chrome も gemini を乗っけてくることになっているが、これも宣伝されている感じだと Dia と同程度かややしょぼいぐらいの統合度であり、そこまでよく使うものにはならなさそうという気がしてしまうのだ。

と、今のところは思っているのだけど、それを覆すような上手い機能を OpenAI が盛り込んでくれてこの流れを乗っ取ってくれるんじゃないか、というのを期待している。

Publish to Fediverse

Wed, 09 Jul 2025 23:37:45 -0700

新規記事を公開したら Bluesky と Fediverse （自分で立ててるpleromaサーバ）の両方に投稿をするように設定しようとしていて、 Bluesky の方は既存の github actions でうまくいったことが確認できたが、 Fediverse の方がどうも動いていない。

アクション自体は成功していて internal server error というレスポンスになっているのが謎。サーバ側にもログが来ていない。サーバが狂っていた可能性もあるけど面倒だし、このアクション自体は5年前に書かれて以降ほぼ何もされていないようだし……と思ったので自分で作ることにしたというか coding AI に作ってもらうことにした。

gemini-CLI に依頼したところ、サクッと curl 経由でポストするというアクションを実行を作ってくれた。 curl のフラグの挙動がよくわからなくて微調整をしたけど、多分動いていると思うのでひとまず完了: https://github.com/jmuk/fediverse-post

さて動くでしょうか。乞うご期待。

https://ap.jmuk.org/notice/AvyxwkmQ113UdKPfaC 動いた！　よかったよかった。

Publish Bluesky / fediverse 2

Mon, 07 Jul 2025 23:56:03 -0700

前回の記事はgithub workflowが狂ってて動作していなかったみたいなので、もう一度記事を投稿してみるテスト。こういう言い回し懐かしいな。

（追記）Blueskyは成功したっぽい https://bsky.app/profile/jmuk.org/post/3ltgqbig3ob2h 一方、Fediverseはうまくいってない。が理由がよくわからない。 “Internal Server Error” とだけ表示が出てアクション自体はなぜか成功している。

Publish Bluesky and fediverse

Mon, 07 Jul 2025 23:21:15 -0700

記事を公開するたびに、BlueskyとFediverseに記事を投稿する仕組みをgithub actionsとして入れてみた。その動作確認のための記事公開。

Wordpressのアーカイブ

Mon, 30 Jun 2025 21:52:39 -0700

移行するので Wordpress.com でホストしている旧ブログをアーカイブすることにした。 https://www.jmuk.org/wp.jmuk.org/ 以下に保存している。うまく保存されてるのかはよくわからないけど。

さて、アーカイブをどうやるかだけど、せっかくなので（当時Sonnet 3.5だった）Claude Codeにお願いしてみた。張り切って Python スクリプトをガンガン書いていく。方式としてはWordPressのAPIに沿ってコンテンツをJSONでダウンロードしてからHTMLを生成していくようだ。え、何だそれ？

いやいやそんなことしたらテーマとかわからなくなっちゃうじゃん、みたいなことを言うとなるほどそうですねといってHTMLの生成を工夫し始めてきた。月ごとインデックスとかどうするつもりなのかわからんけどこれはダメだなーという印象。

それでしばらく放置していたがこないだ重い腰を上げて再開するにあたり、まっさらなレポジトリでgemini-CLIに聞いてみた。するといきなり wget コマンドでやりましょう、実行していい？　みたいなことを聞いてきて考え方が違うなと感じた。wgetだと微妙な面もあるんじゃないかという気がするが、面倒だったので（フラグはdepthの設定などをちょっといじって）実行させた。取りこぼしがあるのかもしれないけど、もう面倒なのでこれでいいということにした。

アーカイブとして保存するにあたりちょっとトリッキーだったのは、画像などでクエリパラメータ付きのデータがそのままファイルとして保存されてしまうところ。ファイル名から適切な拡張子が選ばれず、Content-Typeを推定できない可能性がある部分が残ってしまう。ただそうなるパターンは数が少なそうだったので適当なヒューリスティクスで誤魔化した。それで旧サイトからリダイレクションを設定してアーカイブ完了、ということに。

それにしても、割と最近になって移行したと思ってたのだけど、なんと10年以上くらいこのサイトでブログやってたらしい。アーカイブされた記事をいろいろ眺めたりしていて昔の記事や画像を眺めるとこの10年という変遷が思い出されてなんとも趣深い。まぁ自分にとってだけの話なのですが。

My First Post

Sat, 21 Jun 2025 23:01:45 -0700

ブログを Hugo に移行してみることにした。 Static Site Generatorベースのブログシステムって実は使ったことがない。

Hugo、だいぶ歴史のあるプロジェクトという認識だけど、Static blog Generatorとしてはいまだに現役なのだな。というか Jekyll も全然現役なのだね。

せっかくなので新しくてカッコ良さそうな他の何かにしてもいいかなとちょっとだけ調べてみたのだけど、例えば Astro は自分向きではないなと思った。良い点はあると思うけど、ブログとしての作りがシンプルすぎる気がする。そんなに長く、たくさんの記事をホストするためのものという感じがない。チュートリアルを読んでみると、無のウェブサイトからページを色々作っていって、それから自分でJSでロジックを書いてページ一覧を作ったりしているのだけど、いやそういうの再発明したくないから。別に。できのいいやつを使わせてくれよ、って思ってしまった。それでチュートリアルではカバーされていないけどブログテンプレートというのもあったのでそれも試してみたところ、そういう諸々が全部テンプレートに入ってはいる。でも例えばトップページには全部のポストが並んでしまうようだった。ページネーションとかしないの？　そういうところがキモなのでは？？　と思うのだけどね……。タグとかはあまり使わない予定だし、どうも自分の用途には向いてなさそうだなと思った。

他のもちょっとだけ軽くチュートリアルを見てみたりしたが、やっぱり自分向きではない気がした。なのでとりあえず今はこれで行こうと思う。Markdownでエディタで書くのはどちらかというと自分はかったるいと思う派なのだが、やろうと思えば github をWebブラウザで開いて編集とかできるので、一旦仕組みを作ってしまえばあとはそれほど負担ではなさそうという気がする。

ところで、Static Site Generator を使うということは色々諦めるということではある。例えばコメント機能をつけるのは難しい。まぁ昨今のブログでコメントとか滅多にあるものではないから必須ではないといえばないのだけど、あるとちょっとだけ嬉しいとは思っている。どうしたものだろう。一つには Disqus みたいなサービスを利用するというのはあるが、 Disqus ってまだあったんですね……というぐらいの盛り下がりぶりではなかろうか。もう一つはソーシャルなサービス（例えばBluesky）のポストを監視してコメント扱いして出すようなプラグインを作るのはどうか、などと一瞬だけ思ったけど、結構スパムし放題になってしまいそうでそういうのの対策は面倒くさい。などと考えるに、自分で検索して閲覧するぐらいで十分なのではという気がしてきた。 Bluesky ならカスタムフィードを作っておけば閲覧は容易であるし。まぁそもそもそんなに反応とかあるかというと、別にないわけですけど。

もう一つ ActivityPub サポートがない。今はすごく必須という気はしないけど個人的にはあると嬉しい。だがそのためになんらかのブログエンジンを使いたいかというと……そんなことはないよな。

て考えてみると、結局のところ新しい投稿があったらそのことを自分の ActivityPubのフィードにAPI経由で投稿するというアクションを作ってやればそれでいいのではないか、という気がしている。そういうのを作るのは結構かったるいのではないかと思っていたが、既存のアクションもあるし、そういうのを組み合わせるのはcodingagentの得意とするところで、サクッと作れてしまった。さてどうなりますか。