DHHとは何者か？Rails作者の経歴と「Pencils Down」発言・2026年の現在地

DHHは、Ruby on Railsを書いたデンマーク出身の開発者David Heinemeier Hansson（デイヴィッド・ハイネマイヤー・ハンソン）の略称です。37signalsのCTOであり、2024年からはShopifyの取締役でもあります。2026年9月のRails World 2026では「手でコードを書く時代は終わった」と語り、HEYの次期版をRustで作り直していることも明かしました。この記事では経歴と発信先を押さえたうえで、彼のコードの作法をRails 8.1.4で実行して確かめ、AIへの転向とRailsフォーク「Mosscap」の進捗までを一次情報で整理します。

まとめ：DHHの人物像と2026年の現在地

• 人物：1979年10月15日コペンハーゲン生まれ。37signalsのパートナー兼CTOで、Railsコアチームには2003年から名を連ねています。2014年のル・マン24時間レースではGTE Amクラスで優勝しました。
• 代表作：Ruby on Rails（2004年公開）。Turbo、Kamal、Thruster、Omarchyと、自社で使う道具を公開し続けています。
• コードの作法：コントローラにはRESTの標準アクション以外を足さず、足したくなったらコントローラを新設します。Rails 8の認証ジェネレータもこの形で出力します。
• AIへの転向：2026年9月23日の基調講演で、37signalsでは手書きのコードを例外扱いにしたと表明しました。HEYの次期版はRust製バックエンドで試作中だと報じられています。
• フォーク：DHHの政治的な発言に反発した開発者がRailsのフォークを進めており、名称はAmikoからMosscapに変わりました。2026年11月1日時点でリリース版はありません。Rails本体の最新は2026年9月24日の8.1.4です。

DHHの経歴：37signals・Shopify取締役・レーサー

プログラマと経営者としての経歴

英語版Wikipediaによれば、1979年10月15日にコペンハーゲンで生まれ、2001年にジェイソン・フリードの37signals（現在のBasecampやHEYの開発元）と仕事を始めました。2003年にプロジェクト管理ツールBasecampをRubyで書き、その開発から切り出したフレームワークを2004年にRuby on Railsとして公開しています。Railsの公式サイトのCoreチーム一覧では、Davidが先頭に「Since 2003」と記されています。

Basecampはいまも彼の本業です。2026年5月26日のブログ「Basecamp Five」では、23歳で最初のコードを書いてから46歳で5番目のメジャー版を出したと振り返っています。この版で入ったエディタLexxyは、次のRailsのメジャー版でAction Textの既定になる予定だとも書いています。

Shopifyは2024年11月19日、DHHが取締役会に加わったと発表しました。ShopifyはRailsの大規模な利用企業で、Rails Foundationのコアメンバーでもあります。DHHとShopifyの関係は、Railsの利用に加えて取締役としての経営参加にも及びます。著作はフリードとの共著『Rework』（邦題『小さなチーム、大きな仕事』）、『Remote』（『強いチームはオフィスを捨てる』）、『It Doesn’t Have to Be Crazy at Work』（『NO HARD WORK!』）が知られています。

ル・マン24時間レースでのクラス優勝

日本語版Wikipediaの戦績では、2014年のル・マン24時間レースでLM-GTE Amクラスを制し、同年のFIA世界耐久選手権でも同クラスのドライバーズチャンピオンになっています。2013年にはLMP2クラスで2位に入りました。2024年以降もル・マンやIMSAに出走を続けています。

DHHの発信先：ブログ・X・GitHub

本人の主張を確かめる場所は4つです。金額や発言を引くときは、日本語の要約ではなく原文にあたってください。

GitHubの数字は2026年11月1日にGitHub APIで取得した値（公開リポジトリ15件、フォロワー30,592人）です。RailsやKamal、Omarchyの本体は個人アカウントではなく、rails・basecamp・omacomの各組織の下にあります。「dhh github」で個人ページを開いてもRailsのコードが無いのはこのためです。

DHHが公開してきた主なプロダクト

20年以上、37signalsの運用で困ったものを道具にして公開する、いわゆる抽出（extraction）を繰り返しています。Rails以外の初出日はGitHubのリポジトリ作成日です。

Railsと各ツールの版はRubyGemsの版一覧とGitHubのリリース一覧で確認しました。Omarchyのリポジトリはbasecamp組織からomacom組織へ移り、2026年11月1日時点のスター数は46,018、v4.5.0のリリース候補（rc2、10月27日）も出ています。2026年8月31日にはOmacom Foundationの発表で、1Passwordと37signalsがそれぞれ年10万ドルを3年間拠出し、財団の資金が1,260万ドルになったと公表されました。導入手順はOmarchyとは？DHHが作ったArch Linux環境の導入・Mac対応・日本語入力【Omarchy 4対応】、TurboとThrusterの仕組みはHotwireとは？Turbo・Stimulus・Hotwire Nativeの役割とRails 8.1での使い方とThrusterとは？Rails 8のHTTP/2プロキシ設定とKamal 2との役割分担で扱っています。

Rails Doctrineの9本柱と判断を変える2本

DHHの思想は公式サイトのThe Rails Doctrineに9本の柱として書かれています。Optimize for programmer happiness、Convention over Configuration、The menu is omakase、No one paradigm、Exalt beautiful code、Provide sharp knives、Value integrated systems、Progress over stability、Push up a big tentです。

設計レビューの結論を実際に変えるのは「Convention over Configuration（設定より規約）」と「The menu is omakase（メニューはおまかせ）」の2本です。前者はテーブル名やファイル配置を規約に合わせれば設定が要らないという原則で、規約を外れた瞬間にコードが増える圧力としても働きます。後者はフレームワークが標準構成を選んでおく考え方で、Rails 8がSolid Queueや認証ジェネレータを標準で持つ理由です。

注意したいのは「Progress over stability（安定より前進）」です。Railsは後方互換より前進を選ぶと明言しています。保守ポリシーではマイナー版ごとにバグ修正が1年、セキュリティ修正が2年で、長期運用するならメジャー更新に追随する工数を最初から見積もりに入れる必要があります。

DHH流のコントローラ設計：標準アクションへの分割

REST標準外のアクションとコントローラ新設の原則

出典はポッドキャストFull Stack Radioの第32回「DHH – Building Basecamp 3 like a Porsche 911」（2015年12月22日公開）です。DHHはこう述べています。

「Whenever I have the inclination that I want to add a method on a controller that’s not part of the default five or whatever REST actions that we have by default, make a new controller!」（標準のRESTアクション以外のメソッドを足したくなったら、そのたびに新しいコントローラを作れ）

同じ回で「Every single time I’ve regretted the state of my controllers, it’s been because I’ve had too few of them.」（コントローラの状態を後悔したときは決まって、数が少なすぎたときだ）とも語っています。コントローラが増えることを設計の失敗とみなす考え方とは逆の立場です。

memberアクション版とDHH流のroutes比較（Rails 8.1.4で実行）

actionpack 8.1.4（Ruby 4.0.6）でActionDispatch::Routing::RouteSetを評価した結果です。「記事を公開する／取り消す」機能を2通りで足しました。

# memberでカスタムアクションを足す
resources :messages do
  member { post :publish; post :unpublish }
end
# => 10ルート。MessagesController は9アクション

# DHH流：専用コントローラのcreate/destroyに割り当てる
resources :messages do
  resource :publication, only: [:create, :destroy], module: :messages
end
# => 10ルート。MessagesController は7アクションのまま

DHH流の定義で追加されるルートは次の2本です（実行結果）。

POST    /messages/:message_id/publication    messages/publications#create
DELETE  /messages/:message_id/publication    messages/publications#destroy

ルート総数はどちらも10本です。素のresources :messagesが7アクション・8ルート（updateだけがPATCHとPUTの2本を持つ）で、そこに2本足した数です。違いはコントローラあたりのアクション数で、前者はMessagesControllerが9アクションを抱え、後者は7アクションと2アクションの2つに分かれます。「公開取り消し」がunpublishという独自動詞ではなくdestroyになるので、フィルタやテストの置き場所が標準アクションの規約に乗ります。

Rails 8の認証ジェネレータが出力するresource :session

この作法はフレームワークの標準出力にもなっています。railties 8.1.4のauthentication_generator.rbがroutes.rbに書き込むのはresources :passwords, param: :tokenとresource :sessionの2行だけです。SessionsControllerが定義するのはnew・create・destroy、PasswordsControllerはnew・create・edit・updateで、loginやlogoutというアクションはありません。ログインはセッションの作成、ログアウトはセッションの削除として書かれています。

実行して分かった細部もあります。only:が付かないため、この2行だけで15ルートが生成され、passwords#indexやsessions#showのようにコントローラに存在しないアクションへのルートもbin/rails routesに並びます。これらへのリクエストはAbstractController::ActionNotFoundになり、既定では404として返ります。ルート一覧を監査に使うチームは、only:で実在するアクションに絞っておくと一覧と実装が一致します。

向かない場面もはっきりしています。外部連携の契約で既存のURLやアクション名を維持する必要がある場合は、RESTへの統一より互換性を優先してください。コントローラを分けた後に共通処理をどこへ置くかはRailsのConcernはアンチパターンか？使い方と判断基準【Rails 8.1で実測】で扱っています。

クラウド脱出の実額とKamal・Thruster

37signalsはクラウドから自社ハードウェアへ移る「cloud exit」を実行し、その金額を公開してきました。2023年9月15日の「Our cloud exit has already yielded $1m/year in savings」では、S3を除くクラウド支出が月18万ドルから8万ドル未満に下がったと報告しています。2024年10月17日には5年間の削減見込みが1,000万ドルを超えると書き、最後に残ったS3についても2025年3月26日に5年で約500万ドルの削減と見積もりました。S3からの移行は2026年1月8日の37signalsの技術ブログで、数十億ファイルを無停止で移したと報告されています。月額支出の減少は当時の実績報告で、5年間の削減額は将来見込みです。ここで参照した記事には、移行全体の累計削減実績は示されていません。

移行の道具は自分たちで書いて公開しました。コンテナを任意のサーバへ配るKamalと、HTTP/2終端とアセット配信を担うThrusterは、2024年11月7日のRails 8から新規アプリの既定構成に入りました。rails newのGemfileに最初から書かれ、外すには--skip-kamalや--skip-thrusterを指定します。

ただし、37signalsの数字を自社に当てはめるのは危険です。彼らはAurora/RDSやOpenSearchなど高額なマネージドサービスを使っていた側で、トラフィックが読める自社プロダクトと専任のインフラ担当を持っています。負荷変動が大きいサービスや、インフラ担当が兼務1名の組織では、設備の余剰容量と障害対応の工数を含めて比較しない限り、移行による費用削減は判断できません。アプリの大半をモノリスに残して一部だけ切り出す彼の設計論はシタデルアーキテクチャ（Citadel Architecture）とは？DHHの定義とアウトポストを切り出す判断基準にまとめています。

Rails World 2026の「Pencils Down」とAIへの転向

手書きのコードを例外にした37signalsの方針

Rails World 2026は2026年9月23〜24日に米テキサス州オースティンで開かれ、Rails Foundationの振り返りによれば58か国から1,000人以上が集まりました。DHHは初日の基調講演で、37signalsが手書きのコードについて「pencils down」になったこと、Railsの規約がこの時代に合っていること、取るべき道は「total optimism」しかないことを語っています（講演概要より）。

本人は2週間後のブログ「Over my dead pencil」で、「We’re not going to write the vast majority of code by hand any longer.」（コードの大半を手で書くことはもうない）と書いています。会場で毎週かなりの量を手で書いている人に挙手を求めたところ手を挙げたのはわずかだった、とも述べています。全面禁止ではなく、手書きが通常業務から例外へ移ったという意味です。

きっかけについて、本人はブログ「Promoting AI agents」で、Claude Opus 4.5などのモデルと、ターミナルやテストを操作できる実行環境がそろった2025年の終わりに、エージェントが自分にとって本当に使えるものになったと書いています。

HEY NextのRust化とRailsとの距離

講演では、メールサービスHEYの次期版についても説明がありました。@ITの講演レポート（2026年10月1日）によれば、HEY Nextは各プラットフォームのネイティブアプリとRust製バックエンドで作り直しており、CPU使用量は99％、メモリ使用量は95％減ったとDHHは説明しました。同記事は、HEY Nextが講演時点で着手から約1週間のデモ段階だったこと、数値はDHHの自己申告で測定方法が示されていないことも書いています。

エージェントが書くなら人間にとっての書きやすさは選定基準から外れる、という理屈です。日本では「DHHがRailsを捨てた」と受け取る反応も出ましたが、HEYの現行版はRailsで動いており、37signalsがRailsから撤退するという発表はありません。

Railsを使う側の受け止め方

判断材料はRails本体の動きです。講演の翌日に8.1.4と7.2.4が出て、7.2系はこれが最後のリリースになりました。開発ブランチでは8.2向けにHTMLテンプレートをHerbでコンパイルする既定値が入り、公式ブログは「Agents on Rails」としてエージェントがRailsのコードをどこまで書けるかを測る連載を始めています。フレームワークの開発はむしろAI前提へ寄せて続いていると読むのが妥当です。

現場が真似するなら、手書きをやめること自体より、エージェントが書いたコードを受け入れる基準を先に作ることです。@ITのレポートによれば、37signalsは2026年春のBasecamp 5の仕上げでデザイナーに最終機能をバイブコーディングで作らせ、個々のPRはもっともらしかったものの、20〜30本を合わせると設計が穴だらけになりました。いったんは手動レビューに戻しましたが、DHHはこれを誤った結論だったと振り返り、人が書き直すのではなくエージェントが失敗しない仕組みを直す側に回れと語っています。エージェントを組み込む開発を外部のAIエージェント開発に相談する場合も、生成コードの受け入れ基準、レビュー担当者、検証環境を先に決めておく必要があります。

政治的発言をめぐる論争とRailsフォーク「Mosscap」

公開書簡Plan Vertと1Passwordへの反発

2025年9月、DHHが個人ブログに書いた移民やジェンダーをめぐる記事を問題視した開発者たちが、公開書簡Plan VertをGitHubに出しました（リポジトリ作成は2025年9月22日）。書簡はRailsコアチームとRubyコミュニティに、DHHとの関係を断つこと、Railsを別名でハードフォークすること、行動規範とガバナンスを整えることの3点を求めています。2026年11月1日時点の署名表は153人です。

論争はその後も続いています。2026年8月に1PasswordがOmacom Foundationへの拠出を公表すると、DHHの政治的な発言を理由に利用者や社員から反発が出たとIt’s FOSSなどが報じました。

AmikoからMosscapへ：フォークの進捗

フォークはCodebergのmosscap組織で進んでいます。当初の名称はAmikoでしたが、2026年8月13日の告知でMosscapに改名しました。旧称Amikoで情報を探している場合は、現名称Mosscapでも確認してください。

• 対象範囲：rails new --minimalに含まれるrailties・actionpack・activemodel・activerecord・actionviewの5つ（ADR 0006）。gem名はmosscap-core、mosscap-http、mosscap-model、mosscap-record、mosscap-viewです（ADR 0005）。
• フォーク元：2026年9月25日のADR 0009でRails 8.1.4に決定。最初のリリースはMosscap 8.1.4になると10月の更新で示されています。
• 現状：RubyGemsに公開されているmosscapは名前確保用の0.0.0（2026年8月13日）だけで、10月の更新も初回リリースを予定として書いています。公式サイトのガバナンスページはSociocracy 3.0を参考にしたサークル制を採り、開発・ドキュメント・セキュリティなどのサークルごとに責任者とメンバーを公開しています。

Rails採用への影響とMosscapの評価条件

動いているRailsアプリを、この論争だけを理由に移す必要はないと考えます。Mosscapはリリース版が無く、移行先として評価できる段階にないためです。技術面で気にすべきなのはむしろ保守期限です。Railsの保守ポリシーでは、8.1系のバグ修正は2026年10月10日で終わり、セキュリティ修正は2027年10月10日まで、8.0系のセキュリティ修正は2026年11月7日までです。8.0以前で止まっているアプリは、論争より先に8.1への更新を計画してください。古い系列からの移行判断はRails 7.2の主な変更点とサポート終了日｜Rails 8.1への移行判断が参考になります。

特定の個人の発信を自社が支持しているとみなされたくない、という理由でRailsを避ける判断はあり得ます。ただしそれは組織のスタンスの問題で、可用性やロードマップの評価とは別の軸です。Mosscapを選択肢に入れるなら、最初の安定版が出た段階で、公開済みのSecurity担当組織に加え、脆弱性報告窓口、修正版の提供手順、保守期間を確認して評価するのが妥当です。

よくある質問

DHHとは何者ですか？

デンマーク出身の開発者David Heinemeier Hanssonの略称です。1979年生まれで、2004年にRuby on Railsを公開しました。現在はBasecampやHEYを提供する37signalsのパートナー兼CTOで、2024年11月からはShopifyの取締役も務めています。2014年のル・マン24時間レースでクラス優勝したレーシングドライバーでもあります。

Railsの開発者は誰ですか？

Ruby on Railsを最初に書いたのはDHHで、Basecampの開発から共通部分を切り出して生まれました。言語Rubyの作者まつもとゆきひろ氏とは別人です。

DHHはRailsを捨てたのですか？

捨ててはいません。Rails World 2026で語ったのは、手でコードを書く作業を例外にしたことと、HEYの次期版をRust製バックエンドで試作していることです。37signalsのRails撤退は発表されておらず、Rails本体も2026年9月24日に8.1.4を出し、8.2の準備が続いています。

DHHのブログやXはどこで読めますか？

長文のブログはHEY World（world.hey.com/dhh）、短い発言はX（x.com/dhh）、プロフィールは個人サイトdhh.dkです。GitHubの個人アカウントはgithub.com/dhhですが、Railsの本体はrails組織の下にあります。

「DHH」は他の意味で使われることもありますか？

3文字の略称なので、社名や団体名の略記にも使われます。人物を調べたいなら「DHH Rails」や「David Heinemeier Hansson」で検索すると絞り込めます。Rails関連の文書で単に「DHH」とあれば、本人か、彼が広めたコントローラ分割の作法を指していると読んで差し支えありません。

関連記事

• Omarchyとは？DHHが作ったArch Linux環境の導入・Mac対応・日本語入力【Omarchy 4対応】
• シタデルアーキテクチャ（Citadel Architecture）とは？DHHの定義とアウトポストを切り出す判断基準
• Hotwireとは？Turbo・Stimulus・Hotwire Nativeの役割とRails 8.1での使い方
• Thrusterとは？Rails 8のHTTP/2プロキシ設定とKamal 2との役割分担
• RailsのConcernはアンチパターンか？使い方と判断基準【Rails 8.1で実測】