前から Matz AI というのを作りたいと思っていて、これは何かというと "Matz は Proc#with_refinement というメソッドを承認するか" という質問に Matz ならどう答えるかというのを回答させるもの、でなんとか作れないものかと claude と話しながら作ってみた。
https://github.com/ruby/blade-mcp
誰でも使えるというものではなく、今のところ Ruby コミッタ限定で提供してる。これは何かというと
最後の返す、の部分も llm に渡して回答文を作らせても良かったけど、heroku で使えるのが Opus 4.8 が一番いい性能のモデルで、手元が Sonnet/Opus 5 ならクライアントに最初から渡して skill で加工した方が良かろうと思って手抜きした。
で、だいたいそれっぽい回答を得られるようにはなったのだけど、肝心の Matz が承認するかどうか、というところは何をやってもいい評価の結果は出なくて諦めてしまった。というか、出てきた結果を返す、の前の処理やプロンプトをいくら調整しても最後に Opus 5 に渡してしまえばどうやっても良い解答が出てくるという、システムの意味があるんか、ってなってしまった。
とはいえ、使ってるクライアントが Sonnet/Opus 4.8 だと有意な結果は出ているので結局モデルの強さによるのだなあとは思った。あと作ってから、claude に「これは典型的な RAG です」と言われてしまい「え、これが RAG なの」と今頃だけど「そうなんだ」と理解できてなんか気分がよかった。何事も作ってみないとわからないものだなあ。
とりあえず、予測についてはいい結果は出なかったけど「Matz は String にメソッドを追加するのをどう思ってるか」みたいな質問には便利だとおもう。
iPhone はカメラのシャッター音を消せるようになるまでフラグシップはもう買わない、としたので今年は 15 Pro Max の利用を継続するんだけど、iOS 27 を入れたら今までのはなんだったのか、というくらいキビキビ動いてよい。
Android は数年前からこんな感じで、何が変わったのかわからんが動き早くなったというアップデートを続けていて、iOS もやっとそうなったか、と安心した。ただしカメラの音だけは許さん。
4.1.0.beta1 をリリースはしたけど、4.0 系列も引き続きという感じなので積み上げた不具合修正を含めてリリースした。
https://blog.rubygems.org/2026/09/16/4.0.21-released.html
今までは手でリリースブランチを準備、としていたけど、ちょっと気合を入れてやってることを全て skill に書き出して claude に "/release-rubygems 4.0.21" と指示するだけで自動でコンフリクトを解消してリリースブランチを用意し、テストを乾燥させるということができるようになった。
ここまで来たらあとはマージ or push、タグ打ち、リリースまでを actions 側にやらせるというので自動化できそうなんだよなあ。もう少しって感じがある。
自分はよくコンピュータに文字を打ち込めるのは1つで、そこを最適化するのが最も効率的と考えてあるときはエディタとかある時は slack 、あるときはブラウザといろいろ変遷してきたんだけど、この半年を思い起こすと claude desktop に最も文字を打ち込んでいる気がする。
結局、この文字を打ち込む先は奪い合いでしかなくて、最近の slack が agent を直接操作できるようにしているのもそういうことだろうとおもう。勤務先ではまだまだブラウザとか slack に文字を打ち込んでいる人も多そうだけど自分は claude desktop ってなってしまった。
文字を読むのもブラウザで読むよりは英語の場合は url を放り込んでから壁打ち的に読むということも増えており、これはなかなかの行動変容だなと感じることも多い。ターミナルで何か、というのも最近はほとんど減っているので、このまま claude desktop だけあればいいというのもありうるんだけど、まだ「Ruby のビルドが通りました」と言われても、ほんとかよ、ってなるうちは統一はできなさそう。
Box 有効時に Marshal.load が動かないという問題があり、直していた pull request をマージしたのでめでたく Bundler のテストが動くようになった。
https://github.com/ruby/ruby/pull/18544
Bundler のテストは多くのところで Marshal.load でデータを読み込んで fixture を、というようなことをやっていてこれらをスキップするとなると1000件以上 skip して何をテストしてるのかよくわからない、という状態だったのでまずはこれをマージしたいっす、と moris さんに伝えていたのだった。
https://github.com/ruby/rubygems/pull/9826
で、Box を有効にしてテスト実行するようにしたのがこれ。微妙に動かなくて Ruby 側でなんとかしないとダメ、というのはかたっぱしからスキップして後回しにした。4.1 のリリースまでにとりあえず pend を全部外すというのができればいいんだけど難しいかなあ...。
MAtz や笹田さんは Euruko に行くためか不参加だったので、nobu, akr, mame といういつものメンバーでおしゃべり。
ちょうど「Ruby を Windows で使う上で解決できると効果が大きいもの」として Happy Eyeball V2 の対応とか long 問題とかを調べていたのでその辺の話題を振って色々教えてもらっていた。
long 問題、というのは Windows は 64bit のマシンでも long が 32bit になるので、String などを 2gb を超えて作れないというやつ。これ、Windows で Ruby を使って claude 経由であれこれしてる時に「2gb を超えるファイルは操作できないです」と突然言い出して、「は?」となって調べさせたらぶつかったというやつ。直せそうには直せそうなんだけど、結構大工事になりそうなんだよなー....。
いつの間にか claude desktop で pull-request の情報が出なくなったり、CI のステータスも見えなくなっていてなんだろうなあ、また gh かなあ、と調べてみたら gh を homebrew ではなく mise で管理するようにしたことで claude desktop から見えなくなっているのが原因なようだった。
この辺、本当にだるくて mise の path を注入するようなフックを作って claude に登録することで普段のセッションからは見えているんだけど、builtin の github status 監視みたいなところには届いてないということだった。
claude にこの手の質問をすると「desktop のコードを確認してきます」と言ってリバースエンジニアリングを始めるのが本当にウケるんだけど、/usr/bin, /usr/local/bin, ~/.local/bin みたいなパスからのみ gh を見つけて実行するということだったので、mise の gh を差し込んで exec するようなラッパーを ~/.local/bin に置いたら無事ステータスも見えるようになったので解決。
他にも claude desktop 由来のめんどいことがいくつかあって解決してるんだけど、この手のやつは本当に無駄なのでアプリ側でいい感じになってほしい。