Railsの作者が発注側に立ちました
読めないコードで手元に残す3つ

開発会社から「コードはAIが書きます」と言われた方へ

開発を外に出している、あるいはこれから出す立場で、提案書に「実装はAIエージェントが行います」と書かれている方に向けて書いています。

問いは1つです。開発会社の側でも誰もコードを読まない開発が現実になったとき、発注側の手元に何が残っていれば安全か。

残すものは3つです。正しさを判定するテスト、外から呼べる口、一致していなければならない業務知識です。この記事で判定者（oracle）と呼ぶのは、実装が正しいかどうかを実装とは別に決める基準のことで、発注側にとっては受入テストがそれに当たります。

「手書きは例外」と宣言した講演

Ruby on Railsの作者で37signalsのCTOを務めるDHHは、2026年9月23日、オースティンで開かれたRails World 2026の基調講演で社内の方針を明かしました。37signalsは講演の数週間前に、手でコードを書くことを通常の業務から外すと決めた。手書きのコードはいまや例外の状態で、エラー監視ツールにバグが出たのを見るようなものだ、という言い方です。

さらに、手でコードを書くことは大多数の会社で働く大多数のプログラマにとって、もう経済的に割に合う仕事ではない、年末にはほぼすべての領域でそうなる、とまで言い切りました。講演でRails本体の新機能は発表されていません。

会場で「今も週に相当量のコードを手で書いている人は」と挙手を求める場面もありました。

読めないRustで作り直させている

話の中心はメールサービスのHEYです。HEYはもうWebアプリではなくなると述べ、講演の約1週間前に6つのネイティブアプリの開発に着手したと紹介しました。Webアプリでなくなったコードを、本来の姿であるメールサーバーとしてRustで作り直す、という進め方です。DHHはあわせて、Webは何もインストールさせない素晴らしい基盤であり、Railsはそこで引き続き強い位置にあるとも述べています。

DHHはRustを心底嫌っていると公言したうえで、こう続けます。Rustは自分で一度も見なくてよいなら素晴らしい。エージェントはRustを好む。だからRustで書かせる、自分は見ない。

そして次の発言が、この記事の出発点です。

私はRustをまったく知らない。それは長所だと思っている。……私はRustの箱を、外側からブラックボックスとして評価する。歴史上、プログラマの一団に何かを発注してきたすべての事業主と同じように。これは新しい現象ではない。責任を持つ人が変わっただけで、現象は変わっていない。（講演の発言を要約して訳出）

Railsを作った本人が、自分を発注者の位置に置いたのです。

講演で挙がった数字を、条件と一緒に並べます。

• CPU 99%減・メモリ95%減：Rustで作り直すバックエンドについて講演で挙げた数字。10台のホストを置くのは冗長化のためだけになる、という言い方です。実測か見込みかは判別できません
• Raspberry Pi 1台：ピーク時のトラフィックをさばけるだろうという話で、本人が概算だと断っています
• 15万行：DHHが2026年8月の1か月に書いたコードの行数。長期の平均の約60倍です
• 約3%：DHHの今年の仕事のうちRubyのコードが占める割合。過去21年は半分以上でした
• 約5人：会場で「今も週に相当量のコードを手で書いている」と挙手した人数。壇上からの本人の目測で、会場の定員は1,200人、実際の入場者数は公表されていません

職業プログラマとしては3月ごろに引退した、ともDHHは述べました。行数が成果を表さないことは生産性の数字を読む回に書いたとおりです。ここで見るべきは量ではなく、立場が動いた速さです。

1月の本人は慎重でした

2026年1月7日のブログで、DHHはまだこう書いていました。品質とまとまりを守る限り、エージェントにコードの9割以上を書かせるという主張には程遠い。純粋なバイブコーディング（コードを読まずにAIへ任せる書き方）は、仕事の場ではまだ自分にとって願望だ、と。約8か月半で、同じ人が反対側に立っています。

GitHubの移行記録

GitHubは2026年9月16日、Copilotの実行基盤（ランタイム）をTypeScriptからRustへ移した記録を公式ブログに出しました。筆者はStephen Toubです。コードの大半はAIエージェントが書いています。

• 8月21日時点の本番Rust：832,378行
• Rustの単体テスト：468,689行
• E2Eテスト（システム全体を端から端まで動かす試験・TypeScript）：174,675行
• 本体に入ったプルリクエスト：128件
• 約14.5週の移行期間中のリリース：135回（プレリリース100回・安定版35回、1日平均約1.3回）

進め方は、各プルリクエストで既存のTypeScript実装をRustを呼ぶ薄い中継層に置き換え、古いコードを同じ変更で削除する形です。CLI（コマンドラインから操作する口）とSDK（他のプログラムから使うための部品）にまたがる既存のE2Eテストを毎回新しいRustコードに対して走らせ、必須テストを落とすプルリクエストは本体に入れませんでした。

テストごと消えた移植が1件ありました

それでも退行は起きています。退行は移行の途中で早く見つかり、直されたと書かれていますが、中身は見ておく価値があります。ある移植でSDKのコールバックが抜け落ち、そのE2Eテストも一緒に削除されていました。

エージェントは、明示的な同意なしにE2Eテストを変えてはならない。このルールは、この退行のあとで加わったものです。もう1つ、機能の欠落を伴う退行は1件を除いてすべてE2Eテストの不足が原因だった、とも書かれています。テストを誰が持つかの前に、テストが振る舞いをどこまで覆っているかが問われています。

教訓の節で、筆者は次のように書いています。

移植の正しさを確かめるテストが要る。そしてそのテスト自体を移植の途中で書き換えてはならない。書き換えれば判定者（oracle）を失う。……実装を変えるエージェントに、テストを弱める、スナップショット（比較の基準として保存した結果）を更新する、互換性の基準を引き上げる、例外扱いのラベルを付ける、といった形で正しさを黙って定義し直させてはならない。少なくとも監督なしには。（要約して訳出）

GitHubの移行では、既存のE2Eテストがこの判定者に当たりました。コードを書く側がこの基準まで書き換えられるなら、テストが全部通っていても正しさの保証にはなりません。

保証したのは1人のエンジニアでした

人の役割もはっきり書かれています。筆者自身が、移行先の設計を選び、どの振る舞いが大事かを決め、作業を分け、曖昧なトレードオフを裁き、証拠を判定し、危険度の高い箇所は手で読み、指摘へのエージェントの応答を確かめ、最後に変更を本体へ取り込む判断（マージ）をした。

エージェントが変えたのは、1人のエンジニアが監督できるコードの量だ。システムを理解し、方向とガードレールとリリースを保証できるエンジニアの必要は、なくしていない。（要約して訳出）

エージェント以前ならチーム全体で1〜2年かかった仕事を、主に1人の開発者が数か月で終えた、とも書いています。

2人は正反対のことを言っています

DHHは中身を読まずに外から評価すると言い、Toubは中身を理解して保証する人が要ると言います。どちらが正しいかは、ここでは決めません。

ただし2人とも、保証する人は自社の中にいます。発注側にとって問題になるのは、保証する役が社外の開発会社の側にあるときです。

3つの事例の比較

当サイトで前に取り上げたShopifyのShopアプリの作り直しを、DHHも講演でネイティブアプリへの作り直しの先例として挙げていました。Shopifyは、既存コードを指して一度で作り直させると保守できないコードの山になると明記し、画面ごとの小さな工程に分けました。試作からストア公開まで12週間です。

3つを「誰が保証するか」「判定の基準をどこに置くか」「人がどこで関わるか」で並べます。各行の太字が事例、その後ろが保証する人です。

DHHの講演だけが、判定の基準をどこに置いたかに触れていません。講演で触れなかっただけで、37signalsに基準が無いという意味ではありません。37signalsではDHHが事業主で、評価する人が社内にいます。

外注では事情が違います。保証する人は開発会社の側にいて、そのエンジニアもコードを読まなくなれば、発注側に見えるのは外側だけです。外側から評価するなら、判定の基準と呼び出し口は発注側が自分で持つしかありません。

発注側の手元に残す3つ

内側のコードは開発会社とエージェントの領分に置いたまま、外側の3つを発注側が持ちます。呼び出し口とは、CLIやAPI（プログラム同士の接続口）のように、画面を開かずにプログラムからシステムを操作できる口のことです。

1. 判定者になる受入テスト

コードを書く主体が同じ権限でテストも書き換えられる状態では、テストが全部通っても、それは書いた本人の採点です。GitHubほど仕組みを整えた現場でも、テストごと消えた移植が1件出て、ルールは後から足されました。

発注側がやることは、受入テストを実装より先に決め、開発会社の手元ではなく自分の管理下に置くことです。移行ならテストの分母を現行側に置く、改修なら変えない範囲を先にテストにするという形で、すでに書いてきた話と同じ場所に行き着きます。

GitHubの教訓にはもう1つ、目標は明確に、漏れなく書く必要がある、初期の指示は曖昧すぎた、という記述があります。判定者の手前には、何を正しいとするかを書いた文章が要ります。

受入テストは発注側が持ち、変えるときは発注側の同意を要する形にします。

2. 外から呼べる口

DHHは講演で、アプリ側が用意する案内役は使いたくない、自分にはCLIを使ってBasecampとHEYと無数のアプリをつなぐ執事がいる、と言いました。そして、CLIが無いなら次の金曜日までに見せてほしい、と聴衆に迫っています。

DHHは2026年3月25日のブログで、BasecampのAPIを作り直し、新しいCLIを作り、エージェントに使い方を教える手順書（スキル）で包んだと書いています。Basecampでできることはエージェントにもできる、次はFizzy、HEYもいずれ、という順番です。

DHHの話は、利用者側のエージェントにアプリを使わせるための口です。同じ口は、発注側が検証に使えます。内側のコードが読めなくても、外側の呼び出し口とその振る舞いは発注側が握れます。受入テストも、この口を通して書けます。画面や承認を業務アプリの側に置く話はエージェント組み込みの回に書いたので、ここでは繰り返しません。

3. 一致していなければならない業務知識

DHHは設計の話もしています。抽象化はエージェントの時代にはそのままの意味では通用しない。何百、何千という処理がアプリを書き換えるなら、抽象化という関所は望ましくない。抽象化をしてきた理由の一部は繰り返しを避けるためだったが、繰り返しの費用はほぼゼロになり、同期を保つ費用も同じように下がった。そして、エージェント時代の設計の定石はまだ誰も持っていない、と明言しました。

重複が許されるなら、同じ業務ルールがコードのあちこちに書かれてよいことになります。そのとき、どことどこが一致していなければならないか、たとえば画面に出る金額と請求書の金額、社内の締め日と外部への連携日が揃っているべきかどうかは、誰も読まないコードからは分かりません。

どこが一致していなければならないかを知っているのは、主に業務を持つ発注側になります。

37signals自身、Basecamp 5の仕上げの時期にデザイナーたちにバイブコーディングで最終機能を作らせ、1件ずつは妥当に見えるプルリクエストが20〜30件集まると、設計が少し穴の開いたチーズのようになったと振り返っています。DHH自身は、そこで人が全部見直す形に戻したのは間違った結論だったと言い、モデルの進歩を待てばよかったとしています。それでもほぼ正しい出力がいちばん危ないという話を、プルリクエストの単位で見たような例であることは変わりません。この逸話だけでは、設計のどこに問題が出たのかの内訳は分かりません。ただ、発注側の確認項目としては、個別の機能に加えて、機能の間で一致させる業務ルールを先に整理しておく必要がある、と私たちは考えます。

契約の前に確かめること

承認の仕組みがあると言われたときは、承認が素通りしていないかを実装で確かめる話もあわせて読んでください。

数字の出どころと限界

DHHの発言と数字は、Ruby on Rails公式チャンネルが公開した「Rails World 2026 Opening Keynote - DHH」（講演は2026年9月23日、オースティン）に基づきます。1月の立場はDHHのブログ「Promoting AI agents」（2026年1月7日）、BasecampのAPIとCLIは同「Basecamp becomes agent accessible」（2026年3月25日）の記載です。GitHubの数字と教訓は、Stephen Toubによる公式ブログ「Migrating the GitHub Copilot runtime to Rust, using Copilot」（2026年9月16日公開、9月23日更新）の記載です。Shopifyの事例は同社の「Native is now the future of mobile at Shopify」（2026年9月10日）に基づき、当サイトの前の回「6年前の正しい選定をAIを理由に捨てました」の記載範囲で使っています。

会場の定員1,200人はRails Foundationの2026年4月23日の告知によるもので、実際の入場者数は公表されていません。挙手の約5人は壇上からの本人の見立てです。HEYのバックエンド移行にかかった工数・人数・期間は講演では示されておらず、CPU 99%減・メモリ95%減は講演での発言で、実測か見込みかは判別できません。Raspberry Pi 1台の話は本人が概算と断っています。GitHubの移行は「主に1人の開発者」と書かれていますが、レビューなどに関わった人数の総数は、この記事で参照した範囲では示されていません。

この記事の3つの持ち物と5つの確認項目は、公開された発言と記録から発注側の論点として整理したもので、DHHやGitHubが示した手順ではありません。受入基準を成果物として残す進め方は、AIネイティブ開発の体制案に書いています。コードを読まない前提の開発で、受入テストと確認項目をどこから固めるかのご相談は、お問い合わせからお送りください。