62 RailsからRustへ？ DHHがRails Worldで話したこと, Opus5.5 Grok4.7感想 - YouTube

https://www.youtube.com/watch?v=Z22uv_hdUEY

Transcript: (00:00) ムーザルのプログラミング絶望ラジオ。こんばんは。ムーザルのザルです。この番組は、プログラミング歴30年のザルと、お休みのムーが最近のプログラミング事情について話すラジオです。鮮度が高くて、かつ適当なお話をお届けしてまいりますので、最後までお付き合いください。本日は2026年9月24日木曜日、62回目です。ということで、ムーさんが体調不良で高熱が出てしまってお休みしているので、今日は僕、ザル1人でお送りするんですけど、若干心細いんですけど、皆さんと一緒に盛り上げていけたらなと思います。ムーさんはお休みしてるんですけど、僕も含めて、聞いてる皆さんも多分中年の方が多いと思うんで、中年ならではの体調管理っていうのがやっぱり必要になってくるなと思ってて。若い時ってやっぱり体が元気だから、何やってても基本的に元気だったりするんですけど、40を超えてくるとですね、ちゃんとやらないとすぐに体調が悪くなるというのが実感としてあります。僕知らなかったんですけど、年を取ると筋肉が勝手に落ちていくそうで、 (01:13) 筋トレしてないと、それがより加速するから、年を取った時には骨と皮、あるいはただの脂肪の塊だけになってしまうと。これだとちょっとまずいなというところで、最近、食後20分以内にスクワットをするっていう、なかやまきんに君のメソッドを使って、毎日朝昼晩とやってるんですけど、このスクワットもですね、いい感じに体力がついたりとか、階段の上り下りが全然楽になったりとか、長時間歩いても全然疲れないみたいな、そういう効果はありますし、体重も2kg、今3kgぐらいかな、落ちたりとかしていい感じなんですけど、ちょっと調子に乗って、 1回あたり30回とかでいいと思うんですけど、60回とか70回とか、2倍の負荷をかけてやってたら、最近ちょっと足腰が疲れ始めてきて、スクワットをするとその後非常に眠くなるという本末転倒な感じになってるので、筋トレはほどほどに、自分の体に合わせて負荷を調整するのがいいなという感想でした。で、今日は何を話そうかなと思ってたんですけど、ムーさんがいない (02:22) んで、直近のイベントの感想を色々話していこうかなと思うんですけど、ここ最近、いろんなLLMの新しいモデルが出たと。例えばGrokの4.7とか、Opusの5.5、GPT-6のSol とかLunaとか、あとMuse Sparkとか、いくつかのモデルがリリースされてるんですけど、最近僕はですね、 GrokとClaude系のモデルを使うことが多かったんですけど、 Grokがすごく気に入ってたんですよ。安くて、ほどほどに賢くて、レスポンスのパフォーマンスもいいと。で、1番気に入ってたのが、日本語が割と自然なアウトプットが出ることが多いなと思って、Grokが好きだったんですけど、4.6以降、4.7もかな。4. (03:19) 7はまだそこまで試してないですけど、日本語がちょっと怪しくなってきてるなと。いわゆるAI特有の、聞いたことのない日本語の言い回しが増えてきて、これはちょっとしんどいなというところで、Opus 5.5を昨日ぐらいからフルで使ってみてるんですけど、この5.5はいいですね。かつてOpus 4系が出た時の、 Opus賢いぞ、このまま使い続けたいっていう感覚にちょっと似てるフィードバックが来ます。で、Fableとの使い分けのところで言うと、ぶっちゃけもうFableは使わなくてもいいかなとは思ったりしてます。Opus 5.5とでベンチマークを取ったわけじゃないんですけど、Opus 5.5でもFable相当のアウトプットは出てきてるなっていう実感はあります。あと、GPT-6系はまだ触ってないですけど、これもなかなかいいっていう評判が出てるので、特にLunaとかをね、 Max推論で使い倒すみたいな、 (04:27) そういうのがいいんじゃないかなと思います。あと、僕は全然触ってないですけど、 MetaのMuse Spark。これもいつの間にか、ベンチマーク上だと上位に食い込んできて、しかもかなり安いということなので、Muse Sparkもかなりおすすめかもしれないですね。これ使ってる人いたら、ぜひコメントで感想を教えてください。で、Grokの話をさっきしたんですけど、 Cursorで使われるComposerが今2.5かな。で、3がもう少しで出るぞみたいな雰囲気を醸し出しつつも、ちょっと沈黙を保ってるっていう感じで、 Grokとの、何でしょうね、社内のリソースの使い方とかも含めて、どういう風になってるかわかんないですけど、Composer 3がこの先どうなっていくのかなってのは気になってるところですね。Cursorのモデル自体はともかく、Cursorのプロダクトとか、モデルより上のレイヤーの使い方の部分に関しては結構先進的なところがあったりするので、xAI全体で Grokも含めて、この先より良いモデル、良いサービスを作っていってもらえると個人的には嬉しいなと思ってます。で、もう1つちょっと大きな (05:38) 話というか、ちょうど今朝か昨日かな、Rails Worldっていうイベントがあって、そこのキーノートでDHHが話をしたんですけど、その中で話してる内容がかなり議論を呼ぶというか、賛否両論分かれるような話があったので、ちょっとそれについて話していきたいなと思ってます。何を言ったのかって言うと、DHHがですね、職業プログラマーを引退したと宣言したと。で、Rails Worldっていう、その名の通りRailsに関するカンファレンスなんですけど、 Railsについての言及はほとんどなかったですね。何を言ってたかって言うと、AIによって開発方針が大きく変化したよということについて話をしてました。しかも、DHHが開発してる HEYっていうメールサービスがあるんですけど、そのHEYのバックエンドを RailsからRustに書き換えて、さらにWebアプリとしてじゃなくてネイティブアプリとして提供していくみたいな、そういうプロジェクトを (06:47) 始めてるよみたいな話がありました。Railsの話の中なのに、言語で言うとRubyではなく、もうRustを使ってるよみたいな話もしてるという感じですね。これ自体はまだ完了してるわけじゃなくて、このプロジェクト自体は始まったばっかりで、実際の成果はまだないらしいんですけど、今のところ、RailsからRustに書き換えたことで、バックエンドのCPUは 99%ぐらいコストが下がったり、メモリに関しては95%ぐらい減ったりとか、目に見えるコスト削減はできてると。要は今まで、書きやすい、書き手に対していい体験を提供してたRails、Rubyから、これは人によって違うと思うんですけど、Rustという、人が書くには学習コストが高いと言われてたような言語を使うけど、実行パフォーマンスが非常にいいと。今はAIにコードを書かせるから、学習コストは基本的に無視して、実行パフォーマンスが優れてる手法を選択した方がいいよみたいな、そんな感じのことを言ってるっていう感じですね。で、DHHが (07:55) 所属するっていうか、37signalsっていう会社ですね。これがHEYっていうアプリを作ってますけど、ここではもう手書きコーディングはせず、手書きは例外扱いだと。やむを得ず手でコーディングして調整するけど、基本的にはコードを生み出す仕組みそのものを改善していくということで、いわゆるハーネスエンジニアリングみたいなことをやってるという感じですね。で、その会場で、今も毎週まとまった量を手で書いてる人は手を挙げて、みたいな感じで聞いたら、挙手したのは大体5人と。多分1000人以上いると思うんですけど、たったの5人しかいなかったっていう感じで。以前僕もXでアンケートを取ったんですけど、そこでも90%ぐらい、ほぼAIがコードを書いてるっていう結果だったので、世界的にも今そういう風になってるなという感じで、驚きはないですけど、なんて言うんだろうな、Rails Worldっていうカンファレンスで、ほとんどの人がコードを書いてないということには、 (09:04) 一抹の寂しさというかね、時代の変化っていうのを非常に感じるなと思いました。で、肝心のRailsがどこに行ったかっていう話は、今回のDHHの講演では全く触れられてないんですけど、他のセッションとかでは、Railsの新しい機能とか、AIとRailsみたいなテーマで色々発表があるらしいので、今日もやってるのかな？今後、動画とか出たらまた見たいなと思います。で、DHH曰く、 Railsを使う部分は、インストールしてもらえない、要はネイティブアプリをダウンロードしてインストールしてもらえない相手を客にする最初の入り口として、 Webの領域が残ると言ってますね。ただこれ、 DHHのポジショントークじゃないけど、一般論にはちょっとしにくいかなとは思います。いろんな領域があると思うんですけど、Webが適してる領域とアプリが適してる領域ってのは結構明確にあるなとは思っているので、インストールの手間を乗り越えるほど常用するアプリケーションの種類って限られてるんじゃないかなっていう気が個人的にはしてますね。 (10:15) なので、Webアプリケーション自体はまだしばらく残り続けるし、昔でいう、昔っていうか今もあるか、プログレッシブWebアプリケーションみたいな、Webアプリをインストールするような体験の方向性で進化するっていう可能性もあるのかなとは思います。あとRailsに対してDHHが言ってたのは、いわゆる設定より規約っていうのはAIにとってトークン効率がいいので、そこはポジティブなんじゃないかみたいなところだったりとか、あと元々の思想として、小さいチームで大きな仕事をするっていうことを体現するためのフレームワークとしてRailsってあったりするので、1人開発者がRailsを使ってエージェントと一緒にアプリケーションを作っていくっていうのには非常にいいんじゃないかなっていうことは言ってましたね。どっちかっていうと、結構フォローするようなニュアンスに感じたので、Railsそのものの独特の価値っていうよりは、今のRailsがAIの中で置かれてる立場を説明してるっていう印象でした。あとDHHが言ってたのは、設計自体が今後 (11:22) 変わっていくみたいな話で、ここはそんなに驚きのあるような話ではないんですけど、エージェント時代に抽象化の意味が変わると。要は繰り返しのコストがほぼ0になったことで、同じコードが重複していろんなところにあったとしても、それを読み書きして管理していくっていうのは、人の手で書いていた時代と比べたら全く問題にならなくなったと。ここら辺でDRYが出てくるんですけど、DRY自体は知識の重複をさせない方針なので。コードの重複と知識の重複ってちょっと混在しながら語られることが多いんですけど、少なくとも知識の重複は一元化して、コードの重複は気にしないっていうのが、今のAI時代におけるDRYの扱い方なのかなっていう風には思いますね。あと、そのイベントの中で言ってたのは、アプリケーションの中にチャットボットみたいなAIを組み込むんじゃなくて、アプリケーションを操作できるCLIツールを出した方がいいということを言ってましたね。要はAIがアプリケーション自体を操作するから、操作可能なインターフェースを備えることが、 (12:32) アプリケーションとしての1つの最低条件みたいな、そんな感じのことを言ってましたね。これは結構前から言われてますけど、MCPサーバーとかを用意して、AIで自動化できるようにしてほしいみたいな。マネーフォワードとかね、 freeeとか、そういうお金関係のツールっていうのは特にそういうのを言われてたし、今は用意されたりしてますけど、人のためのインターフェースからAIのためのインターフェースに移行するよみたいなのは結構前から言われてましたけど、ここはあんまり変わらないでしょうね、この先も。かと言って、人が全く操作しなくなるってこともないのかなとは思ってるので、人が操作しやすいインターフェース＝AIが操作しやすいっていうことを踏まえながら設計していくのがいいのかなとは思いますね。CLIとかMCPサーバーとかは、また別の軸の話かなとは思ってますけどね。で、最終的にDHHが何を言って締めくくったかというと、色々あるけど、AIがプログラミングそのものを奪うという (13:38) か、なくすというか、職業プログラマーという仕事がなくなるみたいな、そんな感じのことを言ってたんですけど、最終的には絶望するよりも楽観的であれと、そんなことを言ってました。言葉で言うと、ホワイトピルを飲めみたいな。で、このホワイトピルって何？って思って調べたんですけど、映画のマトリックスで出てきた赤い薬と青い薬由来のスラングらしいんですけどね。ネオがモーフィアスから、赤い薬と青い薬どっちを飲むかみたいな感じで迫られるシーンがあるんですけど、すごい昔のやつで思い出すのがあれだったんですけど、ホワイトピルっていうのは、いろんなことがあったとしても、その全てに対して前のめりになって、選択肢は1つしかないから楽観的に熱意を持って進め、みたいな、そんな感じのニュアンスらしいですね。で、その逆がブラックピルで、ブラックピルは負け犬のためのものだから、負け犬になるなみたいな感じで話を締めくくってました。これは何て言うんだろう？ AIによっていろんな価値観 (14:44) とか、自分自身のアイデンティティみたいなものが変わりうる、揺さぶられるみたいなことは、この1年ぐらい、いろんなところで言われてましたけど、そういうのも全てね、未来を受け入れて楽観的に希望を持って取り組むのがいいんじゃないかっていう、ある種優しいトークの締めくくりだったかなとは思います。今回のこのイベントで、内容はともかく気になったのは、DHHとRailsって今後どうなるんだろう、その関係性ってどうなるんだろうってのがちょっと気になっています。Railsイコール、もうDHHみたいな、そういうイメージがやはり強かったりはするので。DHHが今Railsに対して熱意を持ってるのかというと、多分そこまで持ってないんじゃないかなっていう気がちょっとしてます。まさに今、OmarchyっていうOSの開発に非常にぞっこんというかね、集中してるっていう感じがするので、今回Railsそのものへの言及もなかったですし、開発方針とか、今後Railsをどうしていくかっていう (15:55) ところにどこまで主体的に関わっていくのかってのは、ちょっと疑問かなとは思いつつも、Railsの開発体制自体には全然不安は感じてないというか、 DHH 1人で作ってるわけじゃ当然ないので、Railsは特に問題ないかなとは思ってます。ただ一方で、37signalsが Railsをメインで使わなくなる、主力武器でなくなってしまうとしたらなんですけど、そこの主導権は結構変わってくるかもしれないなっていう、組織的な影響はあるかもしれないなとは思ってはいます。あとは、今日やるのかな？ Rails Worldの別のセッションで、MatzとDHHが対談するセッションがあるらしいんですけど、そこでどんな話をするのかが非常に気になると。元々Railsのドクトリンに書かれてるものの1つが、プログラマーの幸福のために最適化するっていうもので、Railsを表すものの1つですと。元々DHHってRubyがめちゃくちゃ大好きで、Rubyと出会ったことで人生が変わったっていう風に言ってるぐらいで、知的な興奮と自己表現ができると、フロー状態に入ることができるからRuby大好きだみたいなことですね。 (17:05) で、MatzがRubyの言語設計の中心に置いてるプログラマの幸福っていうところを受け継ぎながらRailsを作ってると。 Railsを使うことによって、人間がコードを書いて読む時も幸福であるという設計をしてるっていうのが根幹にあるんですけど、AIによってコード自体を読むことがないような世界に突入した時に、プログラマの幸福ってどこにあるんだみたいなことについて、DHH曰く、職業プログラマーとしてプログラミングで幸せになるというよりは、物を作るという、より拡大した意味での幸福を感じるべきだみたいな、そんな感じのニュアンスのことは言ってましたね。なので、DHHの中では、ものづくりをする道具自体はRubyから他のものに移り変わっていくってことはあるのかなと思うんですけど、本人の中ではその喜びそのものは延長線上にあるっていう感覚なのかもしれないなと思いました。一方でDHHって、今回のRails WorldでAIの話をしてますけど、実際1年ぐらい前は、エディター (18:17) のAI補完は邪魔だ、コードは全部自分で打つみたいな方針の人で、たった1年の中でだいぶスタンスが変わったなという印象はあります。徐々にですね、Opus、去年かな、去年のOpus 4.5とかが出た時ぐらいから、世界的にもそうですけど、DHH自身もAIエージェントがこれから花開いていくぞみたいな実感を得て、半年ちょっとぐらい経つとほぼコードはAIでしか書いてないみたいな感じになって、今日の Rails Worldに至るというような感じですね。という感じで、 Rails WorldのDHHの講演は、いろんな反響を呼ぶ内容かなと思いつつも、言ってること自体はここ 1年ぐらいでいろんな人たちが言及してるような方向性の1つだとは思うので、突飛な話っていう感じではなくて、いよいよ DHHもそうだったかみたいな、そういう印象を受けたかなという感じですね。 Rails WorldのDHHのセッションの感想でした。 (19:23) ということで、ちょっとお便りにいこうかなと思います。ラジオネーム、TKG（卵かけGo言語）さん。Go言語が好きなのかな？いつも楽しくラジオを聞かせていただいています。昨今のAIエージェント利用のブームに流されるかのように、私自身もAIエージェントを使い始めたのですが、 AIによってPC内の意図しないデータを消されてしまう事象が発生してしまいました。 AIによる削除の拒否設定などはしていたのですが、私が気付かないうちにAIが拒否設定を回避するようになっていました。賢すぎるのも考えものだなと思わされました。世の中でもAIを安全に利用するための防御方法は提示されていると思いますが、お二人がAIによる事故が起きないために実施されている対策があれば教えていただきたいです、ということなんですけど、これ時々聞きますね。AIによってファイルを消されちゃったみたいな。僕自身はですね、正直何にもしてなくてノーガード戦法でやってるんですけど、これは怖いですね。でもガードするって言ったら、もう環境を分離するぐらいしかないんじゃないかってちょっと (20:30) 思っちゃったりするんですけど。AI自身も賢いから、多少の設定とかガードだと、すり抜けて任意のコマンドを実行するってことも起こり得ると思うんで、もはやAIを動かすのはクラウド環境のサンドボックス内だけ、みたいな。つまり自分のローカルPCで動かすというよりは、隔離された環境でAIを動かすっていう、そういう風なものに移行していく方が、もしかしたらいいのかなとは思います。ここら辺、僕は知見がないので、知ってる方がいたら、ぜひコメントで教えてください。じゃあ続いてのお便り。ラジオネーム、Zetsubou_Usageさん。初めまして。ムーさん、ザルさん、いつも動画拝見しております。私はフロントエンドを中心に業務を行っているアラフィフです。といってもお恥ずかしながらプログラミング歴は浅く、 5〜6年程です。30代終わりに本格的にJavaScript/ Reactを学び始め、40代でこの業界に入りました。これまで書籍や動画、実務で毎日勉強していたのが楽しかったのですが、AIの性能が上がるにつれハーネスや (21:38) オーケストレーションが面白くなってしまい、すっかり夢中です。先日のJEV のお話も面白かったです。ムーさん、ザルさんが今夢中になっているものはありますか？今後も応援しております。ということで、非常にいいですね。学んでることに絶望してるというよりは、興味の範疇が変わってきてるっていうことですね。AIのところに移ってきてると。まさに今の時代に適応したエンジニアの生き方って感じがして、非常にいいなと思います。今夢中になってるもの、夢中になってるものか。プログラミング領域だと正直夢中になってるものってないんですけど、今はですね、ベンチマーク、ベンチマークっていうのは、アプリケーションのパフォーマンスを計測するためのベンチマーカーを作ったりとかしてるんですけど、この開発に夢中っていうか、はまってるというか、頭を悩ませてるというかっていう感じですね。元々やりたかったのが、この間、映画のチケットを取ろうとしてTOHOのシステムにアクセスしたら、僕、TOHOの有料会員なの (22:45) で、他の人より先にチケットを購入できるんですけどね、某人気映画のチケット争奪戦が発生して、夜9時にめちゃくちゃトラフィックが集まると。一応TOHOもトラフィックが集中するのは分かってるので、いわゆる待合室みたいな、今1万人待機してます、あと10分でアクセスできるようになりますみたいな、そういうシステムがあるんで、そうそう落ちなかったりはするんですけど、それ自体の障害なのかわかんないですけど、全く繋がらなくなりまして。珍しいなと思いつつも、トラフィックが集中すると、システムが落ちるとか、障害とか、反応が遅くなるってのはよくある話なので、どういう設計にしたら、絶対に落ちない映画チケット販売システムが作れるだろうかっていう設計を考えてますと。で、その設計が正しいかどうかを証明するためにベンチマークが必要なんで、大量のトラフィックを送るためのベンチマーカーを今作っ (23:51) てるんですけど、これがまあ難しいですね。ちゃんと何をいい指標とするかっていう部分を考えないと、闇雲にトラフィックを送っても、出てきた数字が価値のある性能なのかどうかちょっと言えないみたいなところも含めて、そこら辺が非常に面白いなと思ってます。いわゆるISUCONっていう、いい感じにスピードアップするコンテストも、同じようにベンチマーカーがあって、大量のトラフィックを送ってスコアを計算するんですけど、あそこら辺を考えてる人たちは非常に頭がいいということが、改めて分かったなという感じでした。あとはあれですかね。豚肉を使った野菜炒めをよく作るんですけど、キャベツと豚肉のね、ただの肉野菜炒めなんですけど、そのクオリティを上げること。あと最近はハンバーグを作ることにはまってるんですけど、ふんわりハンバーグじゃなくて、割としっかりとした、肉々しい固めのハンバーグを作るのにはまってて、その味の探求を今やってます。じゃあ続いてのお便りにいきます。 (25:02) ラジオネーム、ドラム缶の上にあるリンゴさん。あれ？これドラムの上？ドラム缶の上にある……あれ、何だっけ？忘れちゃった。まあいいか。愚痴です。現在所属している企業の上層部が技術に疎く、ミーティングをする時に技術用語が伝わらずに、いつも翻訳をしています。部長はまだしも、マネージャーも技術に疎くて、メンバーとの衝突がよく発生しています。部長とマネージャーが早く体調を崩してくれないかなー、入れ替わって欲しいと祈りながら毎晩寝ています。いや、これはあるあるですけど、いいですね。部長とマネージャーが早く体調を崩してくれないかなって、陰湿だな。だけど、この気持ちは分かりますよ。もうすごい嫌なんでしょうね。マネージャーすら技術に疎くて、コミュニケーションコストが非常に高いし、伝わらないし、伝えようとしても、多分見当違いのレスポンスが返ってきたりとかね、するんでしょうね。で、入れ替わって欲しいと祈って寝てるということなん (26:08) ですけど、多分ね、入れ替わることはないんですよ、これ。会社あるあるですけどね。上の方はあんまり入れ替わらない。下の、現場の人たちは、辞めて入ったり、辞めて入ったりとかするんですけど、マネージャーまで行くとですね、なかなか変わらないということなので、そのままね、ちょっと絶望して働いていただければなと思います。愚痴ありがとうございます。非常に楽しいです。では、プログラマー人生相談室に、いくつか相談が来てるので、今回はムーさん、ムー相談員がいないので僕が代わりにお答えするんですけど、ラジオネーム、平成生まれの生き残りさん。初めまして。現在絶賛就活中のエンジニア志望学生です。私はこれまで成長環境、ミッションなどへの共感、事業内容などから、基本的に成長中のSaaS系、 AI系ミドルベンチャーのサマーインターンに参加してきました。本選考もサマーインターン参加企業を中心に受ける予定です。しかし、メガベンチャー・大手 SIerに行く気はないという前提はありつつ、ミドルベンチャーとの違いなどを知るためにサマーインターンぐらいは参加しておくべきだったかと、今更ながら感じています。 (27:17) そこでお二人に以下のような質問にお答えいただきたいです。メガベンチャー・大手 SIerとミドルベンチャーならどちらをファーストキャリアとして選ぶか。規模の大きい会社と小さい会社のメリット・デメリット。P.S. いつも絶望ラジオ楽しみにしております。ありがとうございます。これですね。僕も新卒採用を10年以上やってきてるので、非常によく受ける質問ですね。大手とベンチャーどっちに行くべきか、あと受託、SESとかと自社サービス系どっちに行くべきかみたいなこの質問は、多分トップ3に入るぐらい聞かれる質問ですね。ファーストキャリアで大手、ベンチャーとか、どこを選ぶべきかみたいな話で言うと、ぶっちゃけどこを選んでもいいかなとは思ってはいます。ただ個人的には、大手とベンチャーどっちが入りにくいかで言うと、大手の方が入りにくいと思います。特に中途で入ろうと思うと、それなりの実績、パフォーマンスを出してないと、選考を通るのは結構難しかったりは (28:29) するので。新卒っていう形態だと、そこまで難しくは、そこまで難しくないって言うとちょっと語弊があるか。難しいのは難しいんですけど、入りやすいとは思ってます。なので、そういう意味で言うと大手に行った方が今後の選択肢の幅は広がりやすいかなとは思ってますね。あとは実際会社に入って何をやっていきたいのかっていうのと、どういう人と働きたいのかっていう観点で選ぶ方がいいかなとは思ってるので、規模の大きい会社を選ぶのであれば、その会社でしか実現できないような仕事をやりたいっていうことだったら、もうそこを選ぶ方がいいですし、もっと裁量の大きさとか、あるいは、この人と働きたいなみたいな、この開発チームで一緒に働きたいなみたいな、そういうのが感じられる会社を選ぶのがいいかなとは思いますね。あと規模の大きい会社と小さい会社のメリット・デメリットで言うと、僕、一瞬だけめちゃくちゃ規模の大きい会社に所属してたこともあるんですけど、非常にですね、ゆっくりしてます。 (29:38) ゆっくりしてるっていうのは、これは会社の風土によって違うんですけど、今日明日にでもやりたいことが、いろんな書類手続き、定期的なミーティングを経て承認を得るみたいな感じで、1ヶ月単位でスパンを考えなきゃいけないみたいな。1ヶ月だったらまだ早い方かもしれないんですけど、っていう感じの、割とのんびりしたところもあったりするので、そういうのが好きな人もいれば、じれったいって感じる人もいると。小さい会社の場合は、そういう手続きって基本的に省略されてたり、上長が社長みたいなケースも、極端に言うとね、あったりするんで、その場のミーティングでOKをもらったら即着手で、予算も割り振られるみたいな、そういうメリットもあったりするんですけど、いわゆる、なんでこういう手続きが必要なのかみたいなことを経験せずに仕事をしていくので、我流になりやすいっていうところはあるかもしれないです。これはデメリットなのかメリットなのかはちょっとわかんないですけど、基本的には仕事の教え方もハンズオンですし、小さい会社から大きい会社に (30:47) 行くと、こんなに仕事のやり方って違うんだみたいな差に驚くかもしれないぐらい、ずさんというかね、悪く言うとそういうところはあると思います。なので、ここに関しては自分の性格に合わせて選んだ方がいいのかもしれないなとは思います。じゃあ、続いての相談です。ラジオネーム、30代目前、在宅勤務ひきこもらー@山形さん。ムーさん、ザルさん、初めまして。いつも楽しく拝聴しております。毎週、ムーさんの視点の多さとザルさんの視野の広さから、多くの学びをいただいています。私は5年目エンジニアとしてはありがたいことに、技術リードのポジションをいただいており、社内の開発プロセス思案に悪戦苦闘しながら働いております。さて、そんな私の作業の一環としてAI駆動開発を推進していますが、「理解負債」や「チーム内での成果のバラつき」を懸念しています。また、AI生成コードの修正に時間を取られ、少なからず絶望を感じています。そこで私は、コードリーディング時に気になった箇所へTODOのようなコメントを残す工程を加えています。理解を蓄積しつつ、場当たり的な修正に時間をかけすぎないようにすることが狙いです。 (31:58) この取り組みへのご意見と、お二人が理解負債を防ぐために工夫されていることがあれば、ぜひお聞きしたいです、ということです。で、この理解負債って、最近よく言われてる認知的負債みたいな、技術的負債とは別の、認知することの負債だと思うんですけど、AIがコードを書くけど、そのコードが何をしてるか、どういう設計なのか、どういう意図があるのかみたいな、そういうところを理解する、認知するコストが非常に高いから、それを放置するのか、取り組むのかみたいな、そういう話かなと思います。で、30代目前さんは TODOとかコメントを残すようにしてると。だからコードリーディングをちゃんとしてるっていうことなんですね。で、理解が追いついてないところとか、ここちょっと気になるなみたいなところは、ちゃんとコメントをして後から着手できるようにするというような感じで、これ素晴らしいですね。コードをそもそも読むっていうことが、今かなり減ってきてるような気がします、世の中的に。なので、ちゃんと理解をしようという取り組みをするタイプの人ですね。 (33:07) 一方で、そもそもコードを読まないと。DHHも今日のRails Worldで言ってましたけど、Rustでコードを書いてるけど、Rustのコードは一切読んでないと。ブラックボックステストをして、コードを読まない限りにおいてはRustは素晴らしい言語だみたいな、皮肉なのかジョークなのかよくわかんないことを言ってましたけど、そういう、AIが書いたコードを理解する必要がないっていう一派もいるということで、これはちょっとチームのスタンスが分かれるのかなとは思ってます。とはいえ、チームとして事業を進めていく中で、自分たちがAIを通じて作ってるものが何をしているのかを全く理解しないっていうのは、何て言うんだろうな、責任問題としてはかなり重いなと思っているので、僕としてはなるべく理解した方がいいと。細かいところは正直理解しなくてもいいと思うんですけど、全体のフローだったりとか、何がボトルネックになってるのかとか、どこが複雑な構造になってるのかみたいな、そういうところはきちんと把握しといた方がいいなとは思ってますね。 (34:15) で、理解負債を防ぐためにできることって言うと、取り組みとしては結構難しいなとは思ってます。いきなりコードを書かせるよりも先に、やりたいことの手法的なものを検証したりして、検証の結果から自分なりに設計をしたものを具体的にAIに書いてもらうみたいな工程を経ることによって、自分自身でコードは書かないけれど、プロセスそのものは頭の中で理解してるし、自分の頭で考えたものっていう風にすることによって、負債にしないということはあるかなと思います。ただこれもね、AIを使ってこのやり方をすると、まあまあ時間がかかるんですよね。普通にAIに任せたら1時間以内で終わるようなタスクが、数時間とか1日とかかかったりとか、下手したらAIを使ってない時代と同じぐらいの時間がかかってるみたいなこともあるので、どこまでやるかはバランスの問題だと思うんですけど。あとはモブプロとかペアプロとか、AI以前からありましたけど、そういうのを通じて、チーム (35:26) の中で大きめの機能を作る時には、一緒に取り組みながらAIに書かせるみたいな、そういうのもいいかなとは思いますね。人と会話をすることによって、一体どこが不明瞭なのかとか、自分の中でうまく分かってないみたいなところが浮き彫りになったりとかするので、そういうのを見つけ出すっていう取り組みをまずしてみるのもいいのかなとは思います。じゃあ最後の相談ですね。ラジオネーム、ザルは俺様のものさん。あなたのものではないですが。ようお前ら、俺様だ。ムーザルの大親友にして一匹狼のプログラマの俺様だぜ。ありがとうございます。一匹狼で寂しい俺様はついに転職を決意して、とりあえず2社から内定をもらったぜ。うち1社の条件が不明瞭なんで相談させてくれ。メールには「雇用形態：スタートは契約社員→スキルの習得度合い、現場での業務の習得状況や現場評価、勤怠率等含めて、正社員登用を行いたく存じます。」とかぬかしてる。ちなみに求人サイトには正社員での募集って書いてるんだがな。この業界ではよくあることなのか？人生経験が不足している俺様に教えてくれ。 (36:33) お礼として俺様のアツいキッスを送るぜ。いや、いらないです。P.S. どのみちもう1社のほうに入社するつもりだけどね。ということなんですけど、この会社はちょっと舐めてますね。雇用形態で、要は正社員として雇うと解雇することが非常に難しいから、その前に見極めをしたいということなんでしょうけど、それだったらもう最初からそういう形式で募集すべきですし、契約社員でなんだろうな、プロセス、パフォーマンスをチェックするみたいなのは、信頼関係を築くのが難しいと思いますね。ぶっちゃけ、この業界でよくあることかって言われたら、全然よくあることではないと思います。なので、その会社は少数派だとは思いますね。いや、でも今時あるんだな、こういう契約社員から始まるの。IT系だとね、あんまりこういうのは聞かないですけどね。という感じで、もう1社の方に決まって、全然良かったなと思います。あと、今回1人で収録するということで、Xで質問ある？って投稿したら、誰からもレスがなかったので、 (37:45) お便りはいただきましたけど、お便りだけで終わらせようかなと思ったんですけど、今見たらXに2つほどレスが来ててですね、それについて答えていきたいなと思います。ただ僕が期待してた質問は、ザルの好きな食べ物は何？とか、そういう非常に答えやすい質問を想定してたんですけど、めちゃくちゃゴリゴリな技術的な質問が2つ来てるので、ちょっと満足には答えられないんですけど、今この場で取り上げたいなと思います。まず1個目がですね、DCさん。個人的にコロケーションはアーキテクチャーではないと思っています。ディレクトリー構成やファイル配置の戦略であり、VSAもDDDレベルの戦略としてしか語られてないように思います。これらの戦略を基盤としたアーキテクチャーについて、ザルさんが運用の中で考えられたことはありますでしょうか？ということで、このコロケーション、VSA、これあれかな？バーティカルスライスアーキテクチャーの略かな？で、それはディレクトリー構成、ファイル配置であって、 (38:54) あんまりアーキテクチャーじゃないよねみたいな。それは僕もそう思います。VSAは僕はそんなに好きじゃないというか、好きじゃないわけじゃないんだけど、あんまり興味がないというか。いわゆるNextとかの文脈で語られるんですけど、Next.jsの設計どうしてる？っていう話の中で、大半はディレクトリー構成をこうしてますみたいなことが多くて、結構違和感があったんですよね。設計ってディレクトリー構成って、かなり、なんて言うの？限定的な話だなみたいな気がしてて。で、コロケーション自体は僕は大好きなので、関連してるファイルは物理的に近くにある方が読み書きしやすいなと思ってるんで、コロケーションは採用したいと。ただ、それが設計の1つなのかと言われるとそうじゃないなと思ってますし、そこのディレクトリー構成は、はっきり言ってそんなに興味があるわけじゃないんで、読みやすければいいかなみたいな感じですかね。これどっから発祥してるんだろう？バーティカルスライスアーキテクチャーとかって、クリーンアーキテクチャーからの派生なの (40:03) かな？ちょっとここら辺詳しくないんでわかんないですけど。もしコロケーションとか、バーティカルスライスアーキテクチャーとか、あとクリーンアーキテクチャー、DDDについて熱い思いを持ってる人がいたら、ぜひコメントで教えてください。じゃあ続いて2つ目。こさん。Octane.js とTSRXの組み合わせは、Reactとそのエコシステムを置き換えることができると思いますか？ドミニックが作っているReact互換のライブラリーと、TSRXはTSXの拡張です。有名なReactライブラリーは移植済みです。個人的には可能性あるかなと思います、ということなんですけど、これ最近話題になってますね。TSRX、TSXを拡張した新しい書き方ができるところと、Octane. (40:51) jsっていう、React Compilerをより進めた実装ですね。互換性のあるライブラリーですね。これ僕個人的にはまだ使ったことないんですけど、Reactとエコシステムを置き換えることができるかどうかに関して言うと、ちょっと難しいかなと思ってます。好きなチャレンジなんですけど、置き換えることができるかというと難しいかなと。それは過去の歴史も含めて、いろんなUIライブラリーがありますけれど、Reactのシェアを大きく塗り替えるっていうアプローチは、同じ延長線上、同じ方向性では結構難しいんじゃないかなって思ってますね。なので、一定のシェアを持ったりとか、ここから何か影響を受けて発展していくみたいなことは、結構あるかなとは思ってますけど、今のReactそのものを揺るがすものにまではいかないんじゃないかなっていう気はしてますけど、これはどうなんでしょうね。僕自身が直接使ってないんで、そこは分からないですけど、もしOctane. (41:57) js、TSRX が大好きな方がいたら、コメントで教えて欲しいです。個人的にね、 TSRXは最初見た時に、あ、いいじゃんと。TSX僕大好きなんで、そこを拡張させて、より良くしてるっていう意味で言うとすごい好きなんですけど、あんまりif文とか書きたくない派だったりするので、if文とかが独自構文、@ifとか、@elseとか、そういう書き方、@forとかもそうか。だからTSXだと書けないような、なんだろう、宣言的というよりは手続き的な書き方がサポートされてるっていうのは、ちょっと個人的にはネガティブポイントかなっていう気はしてます。ただ表現力がね、TSXに比べたら圧倒的に上とも言えるので、こういうのが好きな人は、かなりいいんじゃないかなと思いますね。という感じで、急遽ですけど、Xでも質問いただいてありがとうございます。非常に助かりました。いや、しかし今回ムーさんがいなくて、1人で1時間近く話し続けてますけど、非常に疲れます (43:05) ね。非常に疲れるし、自分でもだんだん何を言ってるのかよくわかんなくなるというか、次の言葉を自分で紡がないと続いていかないから、ずっと考えながら話し続けるみたいな。原稿もそんなに用意してなかったりするんで、その場の思いつきで話したりとかしてるんですけど、疲れたけど楽しかったですね。リスナーの皆さんも、ぜひ感想コメントいただけたら嬉しいです。ということでエンディングです。この番組では皆さんからのお便りをお待ちしております。YouTubeのコメント欄、Spotifyの説明欄にお便りフォームのURLを記載してあります。またお便り以外にもYouTubeや Spotifyでのコメントもお待ちしております。それではまた次回。ここまでのお相手はムーザルのザルとお休みのムーでした。さようなら。ムーさん、お大事に。

要約

今回はムーさんが体調不良で休み、ザル1人での配信。

体調管理

40代になり筋肉が自然に落ちるため、食後スクワット（なかやまきんに君メソッド）を毎日実践。体力向上・体重減少の効果はあったが、負荷を上げすぎて逆に疲労・眠気が出たため、無理のない負荷調整が大事という反省。

最近のLLMモデル動向

Grok（4.6〜4.7）は安価・高速で気に入っていたが、最近は日本語表現がAI特有の不自然な言い回しになってきた。
Opus 5.5はかなり良く、Fableを使わなくてもOpus 5.5だけで代替できそうという感触。
GPT-6系（Sol/Luna）やMeta「Muse Spark」も評判が良く気になっている。
CursorのComposer 3の動向にも注目（xAIとの関係含め）。

DHHのRails World基調講演について

DHHが「職業プログラマー引退」を宣言。Railsそのものにはほぼ言及なし。
自社サービスHEYのバックエンドをRailsからRustへ書き換え、ネイティブアプリ化するプロジェクトを開始。CPUコスト約99%減、メモリ約95%減という成果。
「AIがコードを書く時代は、書きやすさより実行性能を優先すべき」という主張。37signalsでは手書きコーディングは例外扱いに。会場で「今も毎週まとまった量を手で書いている人」の挙手はわずか5人程度。
Web版の存在意義は「ネイティブアプリをインストールしない客への入り口」に限定されるとの見解（ザルはこれに一部懐疑的）。
Rails思想（設定より規約）はAIのトークン効率的にも良く、小規模チーム開発とAIエージェントの相性が良いと評価。
AI時代の「DRY」は、コードの重複は気にしないが知識の重複は避けるべき、という解釈に変化。
アプリにはチャットボットではなく、AIが操作できるCLI/MCPインターフェースを備えるべきと主張。
結論は「絶望よりも楽観（ホワイトピルを飲め）」というメッセージ。
ザルの所感：DHHは今Omarchy（OS開発）に情熱を注いでおり、Railsへの関心は薄れているのでは。Rails自体の開発体制には不安はないが、37signalsの主力言語がRailsでなくなることで組織的な影響はあるかもしれない。Matzとの対談セッションの内容にも注目。DHHは1年前は「AI補完は邪魔」という立場だったが、この1年で大きくスタンスを変えた。

お便り・相談コーナー

AIによるファイル誤削除対策：ザル自身は特に対策なし（ノーガード）。今後はローカルではなくクラウドのサンドボックス環境でAIを動かす方向に移行するのが良いのではという私見。
興味の対象がAIハーネス/オーケストレーションに移った視聴者へ：ザル自身は今、映画チケット販売システムを想定した高負荷ベンチマーカー作りに熱中（TOHOのチケット争奪戦での障害体験がきっかけ）。良い指標設計の難しさに苦戦中。私生活では野菜炒めとハンバーグ作りにハマっている。
技術に疎い上層部への愚痴：共感しつつも、現実的には上層部の入れ替わりは期待しにくいという回答。
就活生からのファーストキャリア相談（大手 vs ミドルベンチャー）：どちらでもよいが、大手の方が新卒での入りやすさ・その後の選択肢の広さがある。会社選びは「そこでしか出来ない仕事」か「一緒に働きたい人・チーム」で選ぶのが良い。大手はプロセスが遅く手続き重視、小さい会社は即断即決だが我流になりやすい傾向。
AI駆動開発における「理解負債」対策の相談：コードリーディング時にTODOコメントを残す取り組みは高評価。ザルの考えでは、細部は理解しなくてもいいが全体フロー・ボトルネック・複雑箇所は把握すべき。対策として、AIに書かせる前に自分で手法を検証・設計してから任せる、モブプロ/ペアプロで理解の齟齬を可視化する、などを提案（ただし時間はかかる）。
転職先の雇用形態（契約社員→正社員登用）が求人と食い違う件の相談：業界的には少数派・怪しい対応であり、もう一方の内定先を選んで正解という回答。

X（旧Twitter）からの質問への回答

コロケーション/VSA（Vertical Slice Architecture）はアーキテクチャと呼べるか：ザルも同意見で、これらはディレクトリ構成・ファイル配置の戦略であり、厳密な意味でのアーキテクチャではないと考える。コロケーション自体は関連ファイルが近くにある方が読み書きしやすく好み。
Octane.js（React互換ライブラリ）とTSRX（TSX拡張）はReactとそのエコシステムを置き換えられるか：面白い取り組みだが、Reactのシェアを大きく塗り替えるのは歴史的にも難しいと予想。一定の影響力を持つ可能性はあるが、Reactを揺るがすまでには至らないだろうという見立て。TSRXの独自構文（@if等の手続き的記法）には好みが分かれそうとのコメント。