RubyKaigi 2026 - Autoresearching Ruby Performance with LLMs

ogp

はじめに

こんにちは、株式会社 Techouse のクラウドハウス事業部で SRE チームのエンジニアをしているショーンです。

先日開催された RubyKaigi 2026 に参加してきました。本記事では、3 日目に行われた Nate Berkopec（GitHub / X）さんのセッションについてご紹介します。タイトルは「Autoresearching Ruby Performance with LLMs」です（スライド）。

Nate さんは Ruby on Rails のパフォーマンスコンサルティング企業 Speedshop のオーナーです。『The Complete Guide to Rails Performance』の著者であり、Web サーバー Puma のメンテナーの一人でもあります。Ruby のパフォーマンス改善の第一人者として知られる方です。

本セッションは、2026 年 3 月に Andrej Karpathy 氏が公開した「autoresearch」という概念を Ruby のパフォーマンス改善に応用する話でした。しかし単なる技術デモにとどまらず、「AI が生成したコードをどうやって検証・マージするのか」「ソフトウェア開発のゲート設計とは何か」という、より本質的な問いへと展開していく内容でした。

Autoresearch とは

セッションは、2026 年 3 月 8 日の Andrej Karpathy 氏のツイートから始まります。

Karpathy 氏は autoresearch というツールを公開しました。AI コーディングエージェントが ML の学習スクリプトに対して自律的に修正を提案・適用します。5 分間学習を走らせ、ベースラインと比較して性能が改善していれば変更を残す。そうでなければ元に戻す。このループを無限に繰り返すツールです。PyTorch のみに依存するシンプルな構成で、1 時間あたり約 12 回の実験を自動で回せます。Karpathy 氏自身が 2 日間自律的に走らせたところ、約 700 回のコード変更を経て 11% の効率改善を達成しました。リポジトリは公開から数日で 21,000 以上のスターを獲得しています。

autoresearch の本質は、LLM に単一の変数軸に沿ってブルートフォース最適化させることにあります。Nate さんのセッションは、この概念を Ruby のパフォーマンス改善にどう適用できるかを探るものでした。

期待と現実：Tobi Lutke 氏の実験

autoresearch のような AI 駆動の最適化はうまくいくのでしょうか。セッションでは、Shopify の CEO である Tobi Lutke 氏の実験が紹介されました。

Tobi 氏は AI を使って Bundler に対する PR を出し、37 件の変更を提案、8 件がマージされました。しかし注目すべきは、マージされた変更はすべて人間の手によるレビューと修正を経ている点です。また、Liquid を 50% 高速化するという PR も出されましたが、こちらは 6 週間が経過してもテストが通らず、マージされないまま放置されていました。

さらに印象的だったのは、AI が生成した PR のコメントに「GC が全 CPU 時間の 74% を消費しているため、すべてのアロケーション削減が大きな効果を持つ」という記述があった点です。しかし Nate さんが示したデータによれば、GC の頻度はプロセスの起動からの経過時間によって大きく異なります。つまりこの主張は、AI が事実と異なる分析を生成してしまった――いわゆるハルシネーションの一例でした。

Lesson 1: Automatic Research, Not Automatic Modification

ここで Nate さんは最初の教訓を提示します。

自動化すべきは「リサーチ」であって、「コード修正」ではない。

この教訓の好例として、Shopify の Stan Lo さんの成果が紹介されました。Stan さんは AI を活用して、ruby-lsp の CI 実行時間を 33% 削減し、rubydex のインデキシングを約 10% 高速化、さらに別の部分を 50% 高速化しています。Tobi 氏の実験との違いは、Stan さんが対象のコードベースを深く理解した上で、AI をリサーチの道具として活用している点にあります。

「マージできないコードをなぜ書くのか」

セッションでは、Nate さん自身による Sidekiq の autoresearch 実験も紹介されました。使用したのは Pi という最小限のコーディングエージェントです。ツールは 4 つだけで、Claude Code よりトークン消費の少ない点が特徴です。

AI は Processor::Counter というアトミックカウンターを導入する変更を提案しました。ストライプドロック（各スレッドが独自の状態を持ち、書き込みは安価だが読み取りは高コストなロック方式）を使う 3 行から 26 行への変更です。別の提案では、Time.now.to_i の代わりに Process.clock_gettime を使い、Time オブジェクトのアロケーションを避けて約 20ns を節約しています。

ベンチマーク上は改善が見られます。しかし Nate さんは繰り返しこう述べました。

「Mike（Sidekiq の作者 Mike Perham 氏）は絶対にこれをマージしない」

なぜでしょうか。ここからセッションは、PR レビューとは何のためにあるのか、という根本的な問いへと展開していきます。

PR レビューは何のためにあるのか

マージする際、私たちは何を考えているのか。なぜ Request Changes をするのか。Nate さんは以下の観点を挙げました。

「バグがある」 — AI エージェント（Cursor など）はバグ検出がそれなりに得意である。単一軸の検証だからである
「トレードオフがある」 — 速ければ良いというものではない。CPU 50μs、IO 1000μs の処理で 5% の改善が複雑さに見合うかは疑問である
「複雑すぎる」 — Flog/Flay スコアや ABC メトリクス、行数で測れる部分もある
「リスクが高すぎる」 — autoresearch はキャッシュを好む。しかしキャッシュ無効化はコンピュータサイエンスで最も難しい問題の 1 つである
「テストは通るが...」 — autoresearch はテストが十分に書かれていることを前提としている
「GPL に違反する」 — GitHub のチェック以外にも法的観点やコンプライアンスの確認が必要である

ここで Nate さんは「Pirates and Architects（海賊と建築家）」というメタファーを使いました。AI エージェントは海賊のようにコードを量産できますが、それを評価し、取捨選択するアーキテクトの仕事はむしろ増えているということです。

Lesson 2: レビューできないものをリサーチさせるな

自分が深く理解し、正確にレビューできる領域にのみ autoresearch を適用すべき。

これが 2 つ目の教訓です。Stan Lo さんの成功も、自身がよく知るコードベースに対して適用したからこそ成り立っていました。

では、AI が人間を介さずに自律的にコードを生成する世界はどうなるのでしょうか。Nate さんは現状の AI 開発ワークフローを「ベビーシッティング」と表現しました。1〜4 個のウィンドウを開き、AI の出力をスクロールしながら眺め、適宜指示を出す。「このスキルを使って」と言うだけで、評価やバックプレッシャーはない。ただの「バイブス」です。

Lesson 3: ループは Bitter Lesson を適用する

Nate さんは Richard Sutton の「The Bitter Lesson」を引用しました。

AI 研究者は知識をエージェントに埋め込もうとしてきたが、長期的にはそれは停滞し、さらなる進歩を妨げる。突破的な進歩は、探索と学習による計算のスケーリングから生まれる。

ループはまさにこの Bitter Lesson を実践する仕組みです。計算をスケールさせ、ブルートフォースによる探索を可能にします。そして「ベビーシッティング」も、実は人間をゲートとしたループの一形態だと Nate さんは指摘しました。

しかし、無制限のコード生成＋人間のゲート＝スロップ（低品質な量産物）になりがちです。AI エージェントが数分で実装を完成させられるのに、人間のレビューに数時間〜数日かかるのは、インピーダンスミスマッチです。PR が山積みになり、レビューが追いつかなくなります。

Lesson 4: 人間のゲートをソフトウェアゲートに置き換える

判断をソフトウェアに落とし込むことで、意思決定が明示的になり、ばらつきが減る。

Nate さんは自身の Puma リリースプロセスを例に挙げました。ブランチの確認からリリースノートの生成、gem のビルドとプッシュまで、16 ステップすべてを自動化可能なゲートとして定義しています。

そして Nate さんは、自身のコンサルティング業務の多くが「『遅い』とは何を意味するのかをチームに定義させること」だと述べました。バイブス（感覚）を Red/Green の状態、つまりバグチケットに変換する作業です。

4 つのループパターン

セッションの後半では、AI を活用した開発ワークフローを 4 つのループパターンに分類する枠組みが提示されました。

1. Agents（エージェント）

最もシンプルなパターンです。LLM がツールを使いながらタスクを完了するまでループし、自ら停止します。ゲートは離散的（LLM の自己判断）で、成果物は最終的な返答です。

2. Ralph

Ralph は、プロンプトを繰り返し AI に渡し、ビルドとテストが通ったらコミット・プッシュするループです。

while :; do
  cat PROMPT.md | claude-code
  ./build_and_test || continue
  git add -A
  git commit -m "ralph: passing build"
  git push
done

ゲートはビルド＋テストという離散的な判定で、頑固なバグの修正に向いています。

3. Autoresearch

ベンチマークのスコアという連続的な値をゲートとして使うパターンです。

best = benchmark

loop do
  change = agent.propose_optimization
  apply(change)
  score = benchmark

  if score > best
    git_commit(change.summary)
    best = score
  else
    git_revert
  end
end

改善があれば残し、なければ元に戻す。パフォーマンスチューニングに特化したループです。

4. Factory

最も野心的なパターンです。仕様のバックログに対してエージェントが実装し、複数のゲート（シナリオ）をすべて通過するまでループします。ゲートは多変量（multivariate）です。単一のスコアではなく、独立した複数のチェックすべてを通過しなければなりません。

	Agents	Ralph	Autoresearch	Factory
ゲート	LLM 自己停止	ビルド + テスト	ベンチマーク差分	複数チェック
シグナル	離散	離散	連続	多変量
成果物	最終返答	green なコミット	改善した diff	通過した PR
設計対象	ツール・プロンプト	ツール・プロンプト	メトリクス・ベンチマーク	ゲート + 仕様
適用先	単発タスク	頑固なバグ	パフォーマンス改善	フィーチャーバックログ

Software Factory の世界

Factory パターンの先にあるのが「Software Factory」の概念です。Nate さんは StrongDM 社の事例を紹介しました。

「コードは人間が書いてはならない。コードは人間がレビューしてはならない。」 — StrongDM「Software Factory」

StrongDM では、Attractor というノンインタラクティブなコーディングエージェントが仕様からコードを生成します。依存関係の Digital Twin に対してシナリオを実行し、すべてのゲートを通過したものだけが出荷されます。誰もいない工場（Dark Factory）で、テストだけが存在するプロジェクトです。

Intercom の事例も紹介されました。自動で Approve されマージされる PR や、PR あたりのコスト削減が示されています。しかし同時に「リスク：誰も何が起きているか分かっていない」という率直な指摘もありました。

未解決の問い

セッションの終盤では、多くの未解決問題が提起されました。

マージ時だけで十分なのか — フィーチャーフラグやランタイムでの検証も含めるべきではないでしょうか。

形式検証と Property-Based Testing — Lean 4 による形式検証の例と、Ruby での Property-Based Testing の例が並べて示されました。いずれもプログラムの正しさを網羅的に証明するアプローチですが、プロダクション環境への適用はまだ黎明期です。

逆転した Mutation Testing — 通常、mutation testing はテストスイートの網羅性を検証するために使われます。しかし Nate さんは逆の使い方を提案しました。テストが正しいと仮定した上で、mutant がテストを通過するなら、そのコードは仕様が要求していない余分なコードだ――つまり削除できる、という考え方です。LLM が生成しがちな過剰なガード文やコードの膨張を抑制する手段として注目されます。

LOC の暴走 — LLM は「オーバーシュート」する傾向があります。コードが際限なく膨らんでいく問題への対策が求められます。

計算資源 — これだけの実験ループをどこで実行するのか。Nate さんは「全員が VM を使って隔離・試行・共有・反復・並列化している」と紹介しました。

byroot はトレーニングデータに含まれているのか — Ruby のパフォーマンス改善で著名な byroot（Jean Boussier）氏の知見がトレーニングデータに含まれているとします。その場合、AI の提案はその知見の再現に過ぎないのではないか。根本的な問いです。

まとめ

Nate さんは最後に、autoresearch の実践的なテイクアウェイを以下のようにまとめました。

自分が深く理解しているコードに対して使うべき（Be Like Stan）
小さく成熟したモジュールに適用する。大規模なレスキューではなく
ゲートが少なくて済むところから始める
ゲート・評価の設計の方が、コード生成やスキル設計よりも重要
ループを試してみる: Ralph（離散）、Autoresearch（連続）、Factory（多変量）
pi-autoresearch を試してみる

本セッションを通じて最も印象に残ったのは、「AI がコードを生成できるようになった今、本当に価値があるのは生成ではなく検証の仕組みを設計することだ」というメッセージでした。誰でもそれらしいソフトウェアを生成できる時代に、問うべきは「それが良いものかどうかを、どうやって検証するか」です。

「ゲート設計 > コード生成」という優先順位は、autoresearch に限らず広く通じる考え方ではないかと感じました。

Techouseでは、社会課題の解決に一緒に取り組むエンジニアを募集しております。ご応募お待ちしております。

jp.techouse.com

Techouse Developers Blog

テックハウス開発者ブログ｜マルチプロダクト型スタートアップ｜エンジニアによる技術情報を発信｜SaaS、求人プラットフォーム、DX推進