Rails World 2026 の DHH 基調講演を読む — AI 時代の Rails と開発者の仕事

DHH が語ったのは、コードを書く仕事の変化

Rails World 2026 の基調講演で、Ruby on Rails の作者 DHH は、37signals が通常業務でコードを手書きすることをやめる方針を明かしました。さらに、メールサービス HEY の新バージョンでは、ネイティブアプリと Rust のバックエンドを選ぶと説明しています。

こうした発言だけを切り取ると、これまでの仕事や技術を否定する宣言に聞こえます。しかし、講演全体を通じて語られたのは、実装を AI に委ねたとき、作れるものと技術を選ぶ理由がどう変わるかという話でした。Web と Rails が担う役割も、その中に位置づけられています。

本記事は、公式講演動画「Rails World 2026 Opening Keynote - DHH」をもとに、主張と具体例を日本語で解説します。後半の実務への提案は、講演の要約と分けて記します。チームでの具体的な分担を知りたい方は、AI コーディングエージェントを併用する運用も合わせて参照してください。

写真の比喩で説明した、作る負担と作る量の関係

DHH が冒頭で持ち出したのは、肖像画から写真への変化です。専門家に依頼して時間をかけて残す肖像と、日常の一場面を気軽に撮れる写真を対比します。撮影の負担が下がると、同じ枚数を安く作るだけでなく、以前なら残さなかった場面まで撮るようになる、という説明です。

ソフトウェアにも同じ変化が起きる、と DHH は考えています。これまでなら開発時間と費用に見合わず、諦めていた機能や小さな不満の解消に着手できるといいます。講演の後半で紹介する自作アプリや最適化は、冒頭の写真の話とつながっています。

本人が転機として挙げたのは Opus 4.5 を使い始めた経験でした。エージェントに頼むと、取り込みたいと思える実装が返ってくるようになったといいます。その後は、実装手順を細かく伝えなくても、問題やアイデアを渡せるようになったと振り返ります。

この比喩を踏まえて、「従来の開発を何割速くするか」から「今まで作れなかったもののうち、何を作るか」へ問いを広げると、以降の話が理解しやすくなります。

37signals の「手書きをやめる」方針と、Basecamp 5 の経験

手書きが必要になったら、開発の仕組みを見直す

DHH は、かつての Rails のデモで、設定やコードを書かずに済むことを喜んでいた自分の映像を流します。Rails で減らそうとしてきた手作業を、いまは AI によってさらに減らせると考えています。その延長として、37signals の方針を説明しました。

英語の表現は「pencils down」、鉛筆を置くという言い方です。日常の製品開発で人がコードを手書きする状態を例外とし、発生したら、なぜエージェントが求める成果を出せなかったのかを考える方針です。一時的に人が書いて対処しても、その後で開発の仕組みを直すと述べています。

手書きの量をゼロにすること自体よりも、問題が起きたときに何を改善対象とするかが変わっています。人が代わりに書いて終えるのではなく、エージェントが仕事を完了できる状態へ戻すことを目指しています。

個々の PR が妥当でも、全体の設計が崩れることがある

講演は成功談だけで構成されていません。Basecamp 5 の仕上げで試した開発では、デザイナーが AI を使って追加機能を実装しました。個々のプルリクエストは妥当に見えても、20〜30 件をまとめると、アーキテクチャに問題が生じたと報告しています。

その時点では、技術がまだ十分ではないと考え、人がすべてをレビューし、プログラマーだけが使う形に戻しました。しかし DHH は、後からその結論を誤りだったと評価します。数ヶ月後に出たモデルなら当初の狙いどおりに機能しただろうというのが、本人の説明です。そのうえで、利用できる知性から成果をどう引き出すかを中心に置きました。

利用を狭めた判断が誤りだったという評価は、その後の進歩を経験した DHH の立場です。講演では、Basecamp の設計問題を解消する具体的な手順までは示していません。

FIXIT

AI が作った変更を 1 件ずつ確認すれば、それで安心なの？

Tsukasa

いいえ、統合した後の全体も確認します。Basecamp 5 では、変更をまとめた後の設計に問題が出ました。

FIXIT

DHH は、それで AI を使う範囲を狭めたままにしたの？

Tsukasa

いいえ。後に判断を改め、エージェントから成果を引き出す方法を探しています。

HEY のネイティブ化は、Rails が不要になるという話ではない

小さなチームが選べる実装の範囲が広がる

HEY の新バージョンの説明では、Web アプリとして作ってきた理由を問い直しています。DHH によれば、HEY が Web アプリだった大きな理由は、小さなチームが生産的に開発できることでした。複数の環境に向けて、それぞれのネイティブフレームワークでアプリを保守する負担を避けていたのです。

その負担が AI によって下がれば、利用者に届けたい体験を理由にネイティブアプリを選べるようになると説明しています。講演では、約 1 週間前に開発を始めたという 6 つのネイティブアプリのデモを示しました。ここで紹介されたのは開発中の成果であり、移行や一般提供の完了報告ではありません。

Windows アプリの例も具体的です。最初の指示で返ってきたものは出荷できる品質ではなく、方向を指示し直すと、20 分後には改善したものが返ってきたと説明します。短い時間で試せることに加え、出てきた成果を見て、どこを変えるか判断する仕事が残っていることも分かります。

AI で実装費用が下がるという主張を、DHH は技術選択の話へ進めています。以前はチームの人数から候補外にしていた構成を、もう一度検討できるということです。HEY の事例の中心は、この選択肢の変化です。

Rust を書く好みから、Rust が生む成果へ

バックエンドの説明では、かつて Rust を嫌っていた自分の発言を紹介します。それでも、自分がコードを書かず、実行速度や小さな実行ファイルといった成果を得られるなら、Rust を好きになれると話しました。

人間が書くときの好みと、エージェントに書かせた結果の価値を分けています。言語を扱う人の負担が技術選択の大きな条件だったときと、実装を委ねられるときでは、同じ言語でも評価が変わるという説明です。

HEY では、ネイティブのフロントエンドに合わせ、バックエンドを中心機能であるメールサーバーとして Rust で作り替える構想を示しました。DHH は、HTML を描画する従来の Web アプリ構成と比べ、CPU 使用量が 99%、メモリ使用量が 95% 減ると報告しています。ネイティブ化に伴う構成変更を含む数字です。Ruby と Rust で同一処理を比べた純粋な言語ベンチマークとしては読めません。

インストール不要の Web と、Rails の規約に残る価値

では、Rails はどこで使うのでしょうか。DHH は Web の強みとして、インストールを求めずに使えることを挙げます。ファイルを受け取るためだけに訪れる人や、短い期間だけ共同作業する人に、使うためだけにアプリをインストールしてもらえるとは限りません。Basecamp は、そのような用途の例です。

講演での対比を整理すると、次のようになります。技術全体の優劣ではなく、製品の使われ方に沿った区別です。

検討する観点	HEY の新バージョンで目指す方向	Basecamp のような用途で重視すること
利用者との接点	ネイティブアプリの体験	一時的な参加者もすぐに使えること
開発上の選択	複数のネイティブアプリを作る	インストール不要の Web を使う
Rails との関係	別の構成を選ぶ事例	Web 開発の規約や構成を活用する領域

Rails の「設定より規約」についても、DHH はトークン効率に結びつけています。また、1 人の開発者が製品全体を作れるようにする考え方は、エージェントによって個人の作れる範囲が広がる時代にも合う、と評価しました。Rails 公式の AI 紹介ページも、規約、表現の簡潔さ、製品開発に必要な機能がそろうことを利点として説明しています。

つまり、HEY の技術選択だけで Rails の将来を結論づけることはできません。何をネイティブにし、何を Web のままにするかという境界は、これから考える必要があると DHH 自身も述べています。

実装を委ねても、何を作り、どう評価するかは残る

エージェントには非同期で仕事を渡す

エージェントとの働き方について、DHH はチャット画面で出力を待ち続ける形から離れようとしています。同僚に頼むように仕事を渡し、成果ができたら戻ってレビューする、非同期の進め方です。37signals でも、Basecamp の中でエージェントに指示する方法を試していると説明しました。

この変化は、短い操作を何度も依頼することと、目的を持つ仕事を委ねることの差に表れます。講演では、個々のタスクだけでなく、成果や解決したい問題を渡せるようになったことを重視しています。人がずっと生成に付き添う前提を外し、どの時点で成果を確認するかを考え始めているのです。

ただし、DHH は完成した開発方法論を提示しているわけではありません。使える能力の変化が速く、この種の相手と働いた経験も少ないため、働き方を模索していると繰り返します。

細かな実装手段より、達成したい目的を伝える

技術をよく知る人に向けて、DHH は実装手段を細かく指定しすぎないことを勧めます。自分の知っている実装を順に再現させるより、実装手段を指定せずに達成したい目的を伝えるほうが、エージェントの能力を引き出せるという見方です。

Rust の内部を自分では理解せず、外側から成果を評価するという本人の説明も、この文脈にあります。長年、プログラマーに仕事を依頼してきた経営者と同じように、作られたものを判断する側へ移ると説明しています。何を作るかを伝え、その結果を受け取る責任の位置が変わったという話です。

さらに Ruby より好きなプログラミング言語は英語になったと語り、手書きを楽しんできた時代を肯定しながら、自分を「ものを作るプロ」として捉え直します。コードを書く楽しさを失った話よりも、作りたかったものを形にする楽しさが増えた話として語っている点が印象的です。

抽象化や重複の費用も、考え直す対象になる

抽象化をめぐる話では、従来の設計原則にも問いを向けました。共通の処理をまとめることは、人が同じ変更を何度も行う負担を減らしてきました。一方、多数のエージェントが同時に変更するなら、共通部分へ作業が集中する負担も考える必要がある、という問題提起です。

繰り返しの実装や複数箇所を同期させる費用が下がれば、重複を避ける原則である DRY や、抽象化の判断も以前とは変わるという見方です。DHH は、そのトレードオフを見直す必要があると話します。

抽象化をやめればよい、という完成した答えは示していません。本人も設計図はまだないと述べています。講演が問いかけているのは、人間の実装時間を前提に最適化してきた設計を、誰がどう変更するのかという条件から見直せるか、ということです。

自分のエージェントを連れてくるための CLI

製品側に向けた具体的な提案が、CLI を提供することでした。CLI はコマンドを通じてアプリを操作する窓口です。DHH はアプリごとに用意された対話相手を「コンシェルジュ」、自分が日常的に使うエージェントを「執事」にたとえます。

DHH が望むのは、各社の対話画面へ個別に入るより、自分のエージェントを使って Basecamp や HEY などを横断して操作することです。そのために、アプリの側がエージェントから使える入り口を用意してほしい、という提案です。利用者が普段使う AI を中心に、複数のサービスをつなぐ考え方と言えます。

HEY の例では、送り主も会社名も年もはっきりしない古いメールを探した経験を紹介しました。スニーカーやポッドキャストに関する曖昧な記憶からエージェントに検索を頼み、数分後にメールが見つかったといいます。本人は、具体的にどう探したのかは十分に分からないとも話しています。

この例の主題は、検索欄へ正しい単語を入れる作業を利用者だけが担う必要はなくなる、という体験です。目的を受け取ったエージェントが CLI を介してアプリを使えるよう、その接点を製品側に求めています。

講演の提案から分かるのは、専用チャットを追加する以外にも、利用者のエージェントに機能を開く方法があるということです。誰が操作の窓口を持つかという、製品設計上の選択肢が示されています。

Omarchy が示す、小さな不満を直せる範囲の広がり

Omarchy は、DHH が開発する Linux 環境です。講演で Omarchy を紹介する後半では、DHH の関心が仕事用のサービスから、自分のコンピューター全体へ広がります。ここをこう変えたいというアイデアを持つ人が、そのまま実現に取りかかれるといいます。その楽しさを、強い熱量で語りました。

紹介したのは、見た目を好みに合わせた電卓、文章を書くアプリ、動画を切り出すアプリ、講演に使うプレゼンテーションソフトなどです。DHH は、1 つ作るたびに、次に欲しかった道具の開発にも取り組みました。仕事の生産性だけでなく、自分が使う道具を自分の望む形へ近づける喜びが中心にあります。

最適化の話も同じ流れです。DHH は、従来は配布サイズの削減や細かな高速化による効果が、開発者の作業時間に見合わなかったと説明します。エージェントへ仕事を任せられれば、後回しにしていた改善にも取り組めるという主張です。冒頭の写真の比喩が、ここで具体的な開発対象として戻ってきます。

講演の終盤まで、DHH の姿勢は強い楽観です。リスクを認めつつ、対処する技術も自分たちで作れると考えています。その将来像に全面的に同意するかとは別に、「今の能力を使えば、後回しにしていたどの不満を解消できるか」という問いは、開発者が手元の仕事へ持ち帰れるものです。

講演を自分のチームに引き寄せて考える

ここからは、講演を踏まえた FIXIT の実務上の提案です。まずは小さな仕事を 1 つ選び、目的の伝え方と成果の確認方法を変えてみることを勧めます。

任せる仕事と、成果を確かめる方法を対にする

エージェントに目的を渡すなら、返ってきたものを何で判断するかも必要です。画面の試作なら操作したときの分かりやすさ、検索なら見つけたい情報を取り出せること、既存機能の改修なら元の挙動を壊さないこと。仕事の種類によって確認する内容は異なります。

講演から持ち帰る問い	最初の仕事で決めておきたいこと
実装手順を細かく決めずに渡せるか	利用者が達成したいことと、満たすべき条件
非同期で任せられるか	作業範囲、成果を受け取る時点、判断する人
個々の変更だけで十分か	統合後に確認する利用の流れと、影響を受ける既存機能
技術を選び直す価値があるか	利用体験の改善と、保守・運用を含む負担
CLI をどこまで開くか	検索・更新・送信など、許す操作の範囲

既存の挙動を守る場合は、期待する入出力を先に明確にし、検査できる形にする方法があります。AI 駆動 TDDでは、その確認をテストとして残す考え方を解説しています。仕事の分解や役割の整理は、AI エージェントの設計パターンも参考になります。

Basecamp 5 の経験を受け止めるなら、個々の変更の合否に加え、変更が積み重なった後に誰が全体を判断するかも決めたいところです。AI の生成量に合わせて受け入れる量だけを増やすと、確認が済んでいない変更も増えてしまいます。

行数や倍率を、そのまま成果の目標にしない

DHH は以前の年間約 3 万行に対し、8 月だけで 15 万行のコードを作ったと述べ、月あたりで約 60 倍という変化を紹介しました。同時に、Rust の冗長さや、Ruby なら許容しなかった量のコードを受け入れていることも挙げています。

行数は、作業の変化を示す本人の説明にはなります。しかし、利用者に届けた価値、障害の少なさ、保守の負担まで同じ倍率で改善したとは言えません。自社で確かめるなら、機能を利用可能にするまでの時間や、受け入れ後に必要になった修正など、仕事の目的に近いものを見ます。測定方法はAI 駆動開発の生産性を測る指標で整理しています。

FIXIT

たくさんコードができたら、その分だけ仕事も進んだってこと？

Tsukasa

いいえ。行数は作業量です。利用者ができることが増えたかは、別に確かめます。

FIXIT

じゃあ、最初に何を決めればいいの？

Tsukasa

任せた仕事を完了と判断する条件を決めます。利用者の目的と確認方法を先にそろえます。

まとめ — 作れるものを増やし、成果を判断する

Rails World 2026 の DHH 基調講演を貫くのは、実装の負担が下がることで、作る対象と仕事のあり方を選び直せるという主張です。HEY のネイティブ化、Rust への評価の変化、CLI、自作アプリは、いずれもその具体例でした。Rails についても、インストール不要の Web と規約の価値を認めたうえで、使いどころを考えています。

一方で、Basecamp 5 での設計上の問題や、非同期の働き方を模索しているという発言も残ります。次の一歩は、後回しにしていた小さな仕事を 1 つ選び、エージェントへ委ねる目的と、自分が成果を確かめる方法を決めることです。

FIXIT は AI 駆動開発のクリエイティブスタジオとして、AI 開発ツール定着支援を提供しています。個人の試用から組織標準へ広げる際のプレイブック整備や CI への組み込みなど、チームで利用するための準備を支援するサービスです。自社ではどの仕事から試すか整理したい方は、お問い合わせからご相談ください。