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

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 のことを思い出して使っている。 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 状態になったセッションがンビ化することがある気がするのだけど、これも再現条件とかがよくわからないし対処法もよくわからない時がある。ツールとしてはもう少し成熟する余地がありそうなのだけど、この辺は自分で貢献するところまではなかなか行かなそうなので頑張って欲しいなぁなどと他人事で思っている。

最近、子供が図書館で借りてきた本に、 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を発音しないエルキュール的な発音で行きたいな、と思いました。それで通じるのか知らんけど。

去年のことだが、会社のオフサイトイベントに行ったら余興の一環としてランダムに組まされたチームでいろんなタスクをやるというよくある遊びがあった。で、タスクの一つがドッジボール。 日本で育ったオタク・インドア・運動苦手勢は全員同じ気持ちがあると思うがドッジボールには何一つとしていい思い出がない。できれば一生関わることなく生きていたいし、まあ大人になれば関わるようなことはまずない。そういえば、かつてGoogle東京で働いていた時にも会社イベントでドッジボールやろうかみたいな話が出たことがあったが、一部のソフトウェアエンジニアたちからの強い意向により取りやめになったということがあったことも思い出す。 そんなわけでドッジボールか……とちょっと嫌な気持ちになったが、まあみんな大人だし俺も大人なので適当にこなそう、と素知らぬ顔で参加した。そしたらルールが結構違っており、そしてやってみたら結構楽しかった。まあ自分は全く活躍しなかったけど、それはそれ、これはこれ。大まかなルールは一緒なのに、細かな違いでこんなに変わるものかと感心したのであった。 あとで軽く調べてみたところによると、日本のドッジボールは日本で独自に発展・進化して成立していった独自ルールであるようだ。 ここを読むような人は知らないことはないと思うけど、日本のドッジボールのルールというのは次のようなものだろう。 ２チームに分かれてボールを投げ合う。一方のチームの誰かが手で投げたボールに当てられたらその人は退場。どちらか一方のチームが全員退場したらそのチームの負け。 長方形のコートを2つに分け、各チームがそれぞれ自分のエリア（内野）内にとどまる。退場した人は「外野」と呼ばれ、敵チームエリアの外側に行く。 ボールは1個、バレーボールやサッカーボールのようなものを使う 誰にも当たらずエリアの外に出たボールは外野が拾い、敵チームへの攻撃に使う ボールを当てられても地面に落ちる前に拾えればセーフ 自分が体験したドッジボールは、その後にウィキペディアなどで見るとアメリカなどで一般的なルールのようだった。大きな違いは、 ボールが複数、大体チームの人数分ぐらいある（9vs9だとボール9個ということ） ボールは中が空気の軽くて小さなボールを使う。大体ソフトボールくらいの大きさのやつ（utility ballという） スタート時点で、ボールは自陣と敵陣を分ける線上に配置されている。スタート時点ではチームは全員外で待機し、スタートと同時に走ってボールを拾いに行く 外野は自陣の奥に待機し、敵を攻撃したりできない 投げられたボールをキャッチできると敗者復活で、外野から一人戻れる といったところであった。大きな違いは「ボールの数」「ボールの大きさ・硬さ」「外野が攻撃できない」だ。 日本のドッジボールはボールが一つしかないので、強い人がいるとその人がボールを占有して攻撃し続けるサイクルになりやすい。それ以外の自分みたいな人は基本的には標的であり、いかにうまく避けるかしかやることがない。でも避けてもボールはそのまま外野に流れてまた攻撃されるだけだし何も面白くない。ボールは結構硬くてあたれば割と痛い。総じて体格が良くて運動の得意な子がそれ以外をひたすら攻撃し続けるだけの競技だと思う。 ボールが複数あると展開はスピーディになるし、どちらかの攻撃というだけではない複雑な展開が行われる。誰を狙おうかなとのんびりしている余裕はないというかボールを持って振りかぶってるやつなんて狙われてしまう。ボールはやや小ぶりで柔らかく、当たっても痛くない。そもそもスピードが乗せづらい。後ろの外野は味方なので、うまく避けれれば自分にボールが供給され攻撃側になるチャンスも多い。ボールが増えるだけでこんなに変わるものかと感心するくらい全然違うスポーツであった。 もちろん、自陣最後の一人になったら狙われまくったりしてあまりいい気はしないだろうし、どんなボールでも（特に子供なら）当たったら痛くていやな気持ちにはなろう。それにこのルールだと敗者復活は結構稀な現象な気がして、ゲーム序盤で当てられてしまって退場したら後は玉拾いぐらいしかやることがないという話はある。あと何にしても体を使うので運動そのものがいやならいやだとは思う。 けど総じてこちらのドッジボールの方が余興むきだし子供同士の遊びにも向いているように感じた（もちろんcompetitiveな世界ではまた違った話ではあるのだろうとは思うのだけど）。というか日本ではなんであんな硬いボールでドッジボールやってるんだろうか。っていうのはそれが一番学校で常備されているからだろうけど、さすがにやめた方がいいのでは、と思うのだけど。 ともあれ、同じ単語でもこんなにも違いがあるものかと結構驚いたのだったし、そもそもこんなにルールが違うものが同じ名前で何の説明もなく併存しているのに結構ビビったのであった。ドッジボールやろうぜ、と言われてイメージする風景が違いすぎる。今から思えば、Google東京であっても日本育ちの人ばかりではなく、当時提案されていたドッジボールはこういうアメリカっぽいやつだったのかもしれない。だとしたら悪いことをしたかな……とまでは思わないけど、不幸な行き違いというか誤解というか、そういう何かではあったのかもしれない。まさかこんなものの中身が違うとか、思わないよね。

最近よく YouTube で lawn mowing の動画をみている。多分いろいろ類似のチャンネルがあると思うけど自分がよくみているのは SB Mowing というやつ。自分の近隣ではちゃめちゃに伸び切った芝生（とか）のあるうちに行って、「Youtubeで動画をやってるから、タダで刈ってあげるよ」といって交渉して、刈って、掃除して、何もかもきれいにしてしまう。 どうも人類というのは「メチャクチャで乱雑なものがきれいに整頓されるのを眺める」というのが好きなんではないか。こういう芝刈りとかの他にも、排水溝の詰まりを取り除くやつとか、そういうのも微妙な人気を博していたりする。そういえば自分は以前には、伸びすぎた家畜のひづめをきっちりと削って、問題があったらそれを治すという削蹄系の動画をよく見ていたけど、あれも似たようなものだと思う。他にも絨毯の清掃、家のリモデル、そう言った動画が無数にあってそれなりに人気を博しているようだ。 ……「人類」は主語でかすぎた。でもまあそういうのを見たいという気持ちのある人はそれなりにいる、とは言っていいと思う。例えば自分の見てるこのチャンネルも何百万人というフォロアーがいて、芝刈りしてるだけの30分ほどの動画も何百万人という人が見ていたりする。などと他人事風にいうまでもなく自分もたまにだが見ている。よく考えるとなんとも不思議な世界である。 まあそれだけの話なんだけど、そういう無償の芝刈り奉仕活動を眺めていくうちに、なんというか不思議な気持ちが芽生えてきた。 この SB Mowing という会社（なのかどうなのか）が今でも普通に芝刈り・ガーデニング業をやってるのかはよくわからないが、少なくとも動画で取り上げるネタはいつも完全にタダというか、家主側は何も払わなくてもいいようになっている。動画によっては、お金がほとんどなくて体の自由も聞きづらい老人の家だったり、もう空き家になって何年も経つような家も多い。というか、動画のネタになるようなとんでもないぐらい伸び放題になっている家というのはそういう訳ありのところが多いからではあるだろうが、そういうところの芝を整えてあげるというのは結構な地域貢献になっているんではないだろうか。景観の話だけじゃなく、虫とかの発生源になってたりすることもあるだろうし。 で、そんなことを無償でやっていて偉い、という気持ちはもちろんあるけれど、でも考えてみれば実際には彼にはYouTubeから動画の広告収入という形で労働代が賄われているという話でもある。いや現実には動画スポンサーがいたりグッズ販売とかも手掛けていたりするので広告収入だけってことではないのだけれど、あれだけ嫌われている広告が巡り巡って地域貢献につながっているっていうところに不思議な感覚を覚えるのだ。 まぁ実際のところ私はPremium入ってるんで広告を見ているわけではないし、自分がこういうのを見てることというのを広告収入とか言っていいのかどうかもよくわかんないんですけど。

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 が盛り込んでくれてこの流れを乗っ取ってくれるんじゃないか、というのを期待している。

新規記事を公開したら 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 動いた！　よかったよかった。

前回の記事はgithub workflowが狂ってて動作していなかったみたいなので、もう一度記事を投稿してみるテスト。こういう言い回し懐かしいな。 （追記）Blueskyは成功したっぽい https://bsky.app/profile/jmuk.org/post/3ltgqbig3ob2h 一方、Fediverseはうまくいってない。が理由がよくわからない。 “Internal Server Error” とだけ表示が出てアクション自体はなぜか成功している。