Rails作者DHH「Pencils Down、もう手でコードは書かない」　それでもソフトウェア開発の未来は明るい理由：Deep Insider Brief ― 技術の“今”にひと言コメント

Ruby on Railsの作者DHHがRails World 2026の基調講演で、37signalsでは手書きコードをやめたと宣言した。一方で「ソフトウェア開発の未来は明るい」とも言う。手書きが例外になった現場で開発者は何をするのか、講演の要点と筆者の考えを紹介する。

» 2026年10月01日 05時00分公開

[一色政彦，デジタルアドバンテージ]

この記事は会員限定です。会員登録（無料）すると全てご覧いただけます。

連載目次

　「ほとんどの会社のほとんどのプログラマーにとって、手でコードを書くことは、もはや経済的に生産的な行為ではない。それが今日の状況だ。年末までには、ほぼ全ての領域、ほぼ全てのプログラマー、ほぼ全ての会社がそうなる。」

　こう言い切ったのは、Webアプリケーションフレームワーク「Ruby on Rails」の作者、DHH（David Heinemeier Hansson：デイビッド・ハイネマイヤー・ハンソン）氏だ。2026年9月23日、米オースティンで開かれたRails World 2026のオープニング基調講演でのことである。自身が率いる37signals（Basecampやメールサービス「HEY」の開発元）では、手でコードを書くことを通常業務としてやめた。本人の言葉では「Pencils Down（鉛筆を置く）」だ。

「鉛筆を置け、でも悲観するな」。手書きコードの終わりと明るい未来を同時に語ったDHH氏のメッセージをイメージしたイラスト（本記事オリジナル）

　ところが、講演後のXポストでDHH氏はこう続けている。「でも、ソフトウェアを作る未来はこれまで以上に明るい。この美しい瞬間をブラックピル（悲観）で台無しにするな」。鉛筆を置け、しかし悲観するな。この一見矛盾したメッセージが、海外でも日本でも大きな反響を呼んだ。手書きが終わった現場で、開発者は何をする人になるのか。講演の内容を順に見ていく。

　まず補足しておくと、DHH氏の「Pencils Down」は手書きコードの全面禁止ではない。手で書くことが「例外的な状態」になった、という意味だ。その中身は後述するとして、DHH氏はこの変化を、ある歴史のたとえから語り始めた。

カメラの登場で、画家の仕事はどう変わったか

　DHH氏は講演の冒頭で、自分の今の状態を「AIデリリウム（せん妄）」「AIユーフォリア（多幸感）」と呼んだ。AIに浮かれていると診断されそうな高揚ぶりだと、自ら笑い話にしている。

　その上で持ち出したのが、写真の歴史のたとえだ。DHH氏の高祖父はデンマークの画家で、1枚の王室肖像画に3年をかけたという。1900年に安価なカメラ「Kodak Brownie」が登場すると、写真は大衆のものになり、肖像画家は「現実そっくりに描く職人技」で食べていけなくなった。画家たちは印象派やキュビスムへと、絵画にしかできない方向へ進んだ、とDHH氏は語る。

　そしてプログラミングにとってのKodak Brownieは、2025年11月24日に登場したClaude Opus 4.5である、とDHH氏は言う。このモデル以降、細かい実装手順を指示する段階から、問題や望む成果そのものをエージェント（人間の指示を受けて自律的に作業を進めるAI）に渡す段階へ進んだ、と語っている。

――ここで、この講演をどう受け止めるか。『Deep Insider Brief』恒例の“ひと言コメント”として、筆者の考えを先に述べておきたい。

　Deep Insider編集長の一色です。こんにちは。

　私の会社でも、もう何カ月も前から「手でコードを書くのではなく、AIコーディングに切り替えてほしい」というメッセージが経営陣やCTOから強く出ていました。それでも、人はなかなか変われません。基本的には手で書くやり方が続いていました。

　ところがここに来て、社内のメンバーが一人また一人と、AIコーディングを中心にした開発に移り始めています。経営陣はそれを「覚醒した」と表現していました。自分のやり方をがらりと変えるのは大変ですし、抵抗感もあると思います。特に「本当にそんなことができるのか」と信じ切れていない人ほど、手を出しにくいはずです。それでも、勇気を持ってどっぷり浸かってやってみる。結局はそれしかないのだろうと感じています。

　だからDHH氏の「ホワイトピルを飲め」というメッセージが、私には面白く思えました。コードを書くことから、コードを書く仕組みを作り、監視し、評価する役割へ人間が変わる。これ自体は多くの人が言っていることです。ただ、それを開発者が今この場でやるのは大変で、勇気が要ります。その勇気を持って実行し、しかもそれを自分の強みや楽しみとして引き受けていく。

　今強く求められているのは、そういう行動そのものではないでしょうか。その意味で、この講演で語られた内容は、単なる挑発ではなく、非常に価値のあるものだと思いました。

　それでは、講演の要点を順に整理していく。

「手書きは例外状態」という運用ルール

　37signalsの新しい方針を、DHH氏は次のように説明した。

通常業務としては、手でコードを書くのをやめた（pencils down）
手でコードを書くのは「例外的な状態」であり、監視ツールSentryでバグを見つけたときと同じ扱い
手書きが必要になったら「なぜエージェントは望むものを作れなかったのか」を問う。当面は手で書いて補うこともあるが、本来やるべきことは「機械（machine）を直し、製造ライン（factory：工場）を直し、再実行する」こと

　ここで言う「機械」とは、筆者の解釈ではコードを生産する装置としてのエージェントそのもの、つまりモデルや指示ファイル、スキル（作業手順をまとめた指示ファイル）の側であり、「製造ライン（工場）」はその周りにあるハーネス（エージェントを動かす実行レイヤー）、テストやLintなどのガードレール、コードベースの整理といった周辺の仕組みを指す。

　例えば実際の工場であれば、製品に不良が出たとき、職人が手で作り直すのではなく、機械の設定と製造ラインの両方を見直して流し直すだろう。ソフトウェア開発でも同様に、人間の仕事はコードそのものを書くことから、コードを生み出す装置と仕組みを整えて、それを通し直すことへ移る、という考え方だ。

　このとき、DHH氏は会場に「今も毎週、かなりの量のコードを手で書いている人は」と挙手を求め、「5人くらいか」と驚いてみせた。Rails Worldに集まった開発者の多くが、すでにエージェント中心の開発に移っていることを示す場面だった。

Basecamp 5で起きた失敗と、DHH氏の結論

　講演には、37signals自身の失敗談も含まれている。2026年春、Basecamp 5の仕上げで、デザイナーたちに最終機能をVibe Coding（バイブコーディング：AIの出力を細かく読まず、雰囲気と結果で進める開発）で作ってもらった。個々のPR（プルリクエスト：コード変更の提案）はもっともらしかったが、20～30本を合わせるとアーキテクチャ（全体の設計構造）が「スイスチーズのように穴だらけ」になった。

　このとき37signalsは「まだ技術が追いついていない。全て手動レビューに戻し、プログラマーだけに任せよう」と判断した。しかしDHH氏は今、それを「明らかに間違った結論だった」と振り返る。理由は2つある。すぐ後により強いモデル（Fable）が登場し、当初の意図通りに機能したはずだったこと。そして、今のソフトウェア開発で本当に重要な問いは1つしかなく、それは「この知能の爆発から、どうやって最大限を引き出すか」だということだ。

　人間の作業に戻るのではなく、エージェントが失敗しない仕組みを作る側に回れ、という主張である。先ほどの「機械を直す」ルールは、この失敗から生まれたものと読める。

1人の開発者はどこまで行けるか

　DHH氏は、1968年のSackmanらの研究（プログラマー間に約10倍の生産性差があるとした古典的研究）を引き合いに、「ツールを使わない最悪のプログラマーと、ツールを使いこなす最高のプログラマーの差は100倍だと言っても、今ではそれほど物議を醸さないだろう」と述べた。さらに「100倍か、1000倍か」と会場に問いかけている。これは測定に基づく数字ではなく、規模感を示すための問いかけだ。

　自身の変化としては、次の数字を挙げた。

2026年8月の1カ月で、15万行のコードを本番投入した。それまでの年平均は約3万行
過去21年の仕事の半分以上はRubyのコードだったが、今年はRubyが約3％
自分の一番好きなプログラミング言語は英語である
自分は「職業プログラマーを引退した」。時期ははっきりしないが、おそらく3月ごろ

　ただしDHH氏自身、コード行数について「奇妙で曖昧で、どうとでもなる指標だ」と断っている。厳密な生産性の証明ではなく、桁が変わったことを伝える数字として受け取るべきだろう。

RailsはAI時代に向くのか、そしてHEYはRustへ

　Railsの作者としての主張も忘れていない。Railsの「設定より規約（Convention over Configuration）」という原則は、ディレクトリ構造や命名が統一されているため、エージェントに余計な前提を説明せずに済み、トークン効率（AIが消費する処理量の効率）に直結すると述べた。1人の開発者が遠くまで行けるように作ってきたRailsの思想は、エージェント時代の要求と一致する、というわけだ。

　一方で、意外な発表もあった。メールサービス「HEY」の次期版「HEY Next」を、各プラットフォームのネイティブアプリとRust製バックエンドで作り直しているという。講演の時点で着手から約1週間のデモ段階だが、Rust化によってCPU使用量は99％、メモリ使用量は95％減り、概算ではHEYのピーク時のトラフィックがRaspberry Pi 1台に収まる、と語った。DHH氏はRustを「人間が読み書きするには不快だが、エージェントが書き、アプリが速くなるなら素晴らしい」と評している。

　人間が書くならRailsが楽しい。しかしエージェントが書くなら、人間にとっての書きやすさは選定基準から外れる。この発言は、Railsコミュニティにとっては重い意味を持つ。

締めの言葉は「徹底した楽観」

　講演の最後でDHH氏は、不確実さや不安があっても選択肢は1つしかないとして、「徹底した楽観（total optimism）」を呼びかけた。「ホワイトピル（楽観）を飲め。ブラックピル（悲観）は負け犬のものだ」というネットミームを交えた言い回しで、会場を鼓舞して講演を終えている。冒頭で紹介したXポストの「未来は明るい」は、この締めの言葉をそのまま持ち出したものだ。

反響と、読むときの注意点

　講演後、海外では賛否が分かれた。肯定的な受け止めとしては、写真や印刷の歴史と同じく、道具の進化が作り手を高次の仕事へ押し上げるという見方がある。批判としては、Basecamp 5の逸話について「より強いモデルが各PRを書いても、誰も全体を所有していないという本当の問題は解決しない」という指摘や、手でコードを書いた経験のないジュニア開発者がどうやってレビューの目を養うのか、という懸念が出ている。ジュニアの育成については、講演内に直接の言及はない。

　日本では「Rails is dead宣言」と受け取る反応がXで広がったが、講演の主題はRailsの終わりではなく、開発者の仕事の変化である。また、講演で挙げられた数値はいずれもDHH氏の自己申告で、測定方法は示されていない。HEY Nextも着手1週間の実験段階だ。「37signalsの実績」というより、「37signalsの現在の賭け」として読むのが正確だろう。

まとめ：開発者の仕事はどこへ移るのか

　DHH氏の講演を、開発者の仕事という観点で整理すると次のようになる。

書く仕事は、エージェントに渡す： 実装手順ではなく、問題や望む成果を渡す
人間は、成果を外側から評価する： 事業主がプログラマーの成果物を見るように、ブラックボックスとして結果を判断する
うまくいかないときは、コードではなく仕組みを直す： 手で書き直すのは応急処置で、本来の仕事はエージェント（機械）とその周辺（製造ライン・工場）を整えること

　「Pencils Down」は、開発者が不要になるという宣言ではない。鉛筆を置いた手で何をするのかを問う宣言だ。DHH氏の答えは「コードを生む機械を直す人になれ」であり、そこに未来の明るさがあると言う。この答えに納得するかどうかは別として、手で書くことが例外になった現場が実在し、そこで人間の仕事が具体的にどう変わったかを、Railsの作者自身が語った意味は大きい。