AIエージェントのデバッグ能力を向上させよう — AI時代にRailsが輝く理由

[日本語版]Kaigi on Rails 2026 発表資料

Transcript

1. AIエージェントのデバッグ能力を向上させよう AI時代にRailsが輝く理由 rira100000000 Kaigi on Rails 2026 · 2026年10月16日 · Magenta Hall 1
2. 自己紹介 rira100000000 • 株式会社ネットワーク応用通信研究所（NaCl）Railsエンジニア • フィヨルドブートキャンプ卒業後、2024年から現職 • AI×Rubyの領域でOSSを公開: debug-mcp、girb、ruby-gemini-api… • github.com/rira100000000 NaClのRailsエンジニア。AI×Rubyの領域でOSSを作っています。AI大好きです！ 2
3. NaClの登壇 — Kaigi on Rails 2026 10/16（金） 14:10–14:25 Magenta Hall 10/17（土） 10:15–10:55 Magenta Hall 10/17（土） 15:50–16:05 Magenta Hall AIエージェントのデバッグ能力を向上させよう rira100000000 ← この発表 Keynote まつもとゆきひろ（Matz） Refining Active Record 前田修吾（NaCl 社長） 3本ともMagenta Hall。明日はまつもとさんのキーノートと前田さんの発表で、NaClコンプリートを！ 3
4. 終わらないデバッグのループ AI 原因はおそらくこれです。修正しました。 動作確認をお願いします 人間 動作確認する 人間 「まだダメです」と伝える 結果 …まだ壊れている 確信のない修正と、人間の動作確認のループ。身に覚えはありませんか？ AIは確信がないまま直し、検証だけが毎回人間に返ってくる。この不毛なループを断ち切りたい 4
5. なぜループが起きるのか AIのデバッグには、得意と苦手がはっきりある 得意 コードとテスト出力から原因がわかるバグ テストが通れば、直ったことをAI自身が確認できる。 ループは発生しない。 苦手 実行時の状態に依存するバグ AIには確かめる手段がない。検証装置が、人間だけになる AIが自分で確かめられないから、人間がループに巻き込まれる。 ループの原因は、バグの原因をAIが自分で確かめられないこと 5
6. 実行時の状態に依存するバグ DBに残った不整合データ メモ化されたまま無効化され なかった古い値 そのsaveで実際に変わった属 性 キャッシュ こういう情報は、コードのどこにも書かれていない。コードから立てられるのは仮説まで。 確定できないから、修正も検証も推測になる。 AIに実行時の事実を確かめる手段を渡したらどうなる？ そのための道具は、RubyとRailsにすでに揃っている。 コードから出るのは仮説まで。AIに実行時の事実を確かめる手段を渡したら何が変わる？ 6
7. 解決の部品は、debug gem 「rdbgを使って」と指示すれば済む話ではない。rdbgのコンソールは人間用の対話UI。 debug gemのリモート接続を、MCP経由でAIに開放する。 エージェントが確実に扱える形に開放するのがdebug-mcp。 実行中のRailsプロセス debug-mcp AIエージェント rdbg（debug gem、リモート接続） MCPサーバー Claude Code、Codex … MCP: AIエージェントに外部ツールを接続する共通規格。Claude CodeでもCodexでも、同じ形で繋げる。 debug gemのリモート接続をMCPで開放する。人間用のrdbgコンソールを、debug-mcpでエージェント向けに包む 7
8. debug-mcpでできること 人間がデバッガでやることをそのままツールとしてAIに渡す 止める set_breakpoint 行・メソッド・例外 trigger_request リクエストを打つ 見る 進める get_context 変数とコールスタック evaluate_code 式を評価する continue_execution 再開する rails_model モデルの構造を聞く 止める・見る・進める。人間のデバッグ操作をツールとしてそのまま渡す。組み合わせはAIが決める 8
9. デモ: 直したはずの /users/6 が、まだ500 • 開発中のアプリ。/users/6 だけが500。原因は分かっている: このレ コードだけ email が nil の、レガシーなデータ。 GET /users/6 500 • 正しいアドレスは alice@example.com。PATCH /users/6 で直したら 200 が返った。でも GET /users/6 は、まだ500。 PATCH /users/6 200 OK • 普通なら、ここからループが始まる。別のレコードを更新した？ キャッ シュ？ 表示側？ コードから出るのは仮説まで。 GET /users/6 500 AIへの依頼文（原文）: GET /users/6 が500になります。原因は Alice（id=6）の email が nil であることまで分かっています。正しいメール アドレスは alice@example.com なので PATCH /users/6 で更新したところ、200 が返りましたが、GET /users/6 はまだ500のままです。 debug-mcpを使って、なぜ修正が反映されないのか原因を特定してください。 環境の制約: 道具は debug-mcp を指定。ログ・DBファイル・rails console は使わせない（デモの統制。他の経路で解ける問題もあるが、今日はデ バッガから見える事実だけで解く）。DBへの直接書き込みは、人間の判断を得てから。 直したはずの /users/6 がまだ500。普通ならここからループ。コードから出るのは仮説まで 9
11. デモ（映像の続き）: 人間が判断し、AIが直して検証する 映像のあと 人間の判断: 「レガシーデータの修復なので、 DBを直接更新して構いません。update_all で直して、GET /users/6 が200を返すことを 確認してください」 AI: User.where(id: 6).update_all(email: "alice@example.com") を実行。戻り値は 1 reload で email を確認し、ブレークポイント を外す 素の GET /users/6 → 200 OK、 email_domain: "example.com" 直ったことまで、AI が自分で検証。人間の 動作確認は、一度も挟まっていない 人間が返したのは判断だけ。AIは update_all で直し、素の GET /users/6 が200になるまで自分で検証した 11
12. いま起きたこと 推測は入らなかった ループは1周で閉じた 仮説はコードで立てた（attr_readonly）。 「直したのに、まだ500」の原因を、人間の動作確認を挟 まずに確定。 確定は全部、実行時の事実。readonly_attributes、発行 された SQL、reload した値。 修復後の 200 まで、AI が自分で検証した。 人間に返ってきたのは、判断 道具は、ほぼ既製品 「DB を直接更新してよいか」。 Ruby: debug gem のリモート接続。 返ってきたのは検証ではなく、この判断ひとつ。 Rails: リフレクション（readonly_attributes）と、 ActiveSupport::Notifications（発行された SQL）。 debug-mcp は、それを AI に繋いだだけ。→ 次は、この Rails 側の話。 推測なしで1周。人間に返ったのは判断だけ。効いていたのは、Railsが元から持っている観測可能性 12
13. ベースはdebug gem。でも、裏で効いているのはRails debug gemはRubyの道具。ではなぜ、この話をKaigi on Railsでするのか? rubyonrails.org/ai 「Rails is built for AI」（2026年8月公開） 規約（Convention over Configuration） トークン効率 学習データの質 One Person Framework 実行時の観測可能性 今日の話 4本とも、コード生成側の話。 デバッガでプロセスの中に入ったあと、Railsだと観測可能性が大きくひろがる。 Rails公式のAIページはコード生成側の話。今日はそこにまだ書かれていない、実行時の観測可能性の話を。 13
14. 1. モノリス — 1プロセス、接続1本 Railsプロセス1つ コントローラ マイクロサービス モデル ビュー サービスA サービスB サービスC 接続1本 debug-mcp 接続3本 ＋ 分散トレーシング モデルからコントローラ、ビューまでが1つのプロセスに同居している。デバッガを1本繋げば、リクエスト処理の全域が 見える。 モデルからビューまで1プロセス。デバッガ1本で全域が見える。マイクロサービスなら分散トレーシングの話になる。 14
15. 2. リフレクション — モデルは自分の構造を答える User.columns AIエージェント 「カラムは？ 関連は？ バリデーショ ンは？」 Userモデル 自分のことを答える reflect_on_all_associations validators_on readonly_attributes ↑ デモで AI が実行中の User に聞いたのがこれ AIはソースコードを読まなくても、モデル本人に聞ける。 「このデータはバリデーション上ありえるのか？」「この属性は更新できるのか？」という照合が、一手でできる。 デモで AI が readonly_attributes を実行中の User に聞いたのが、これ。ソースで立てた仮説を、モデル本人の答えで 確定した。 AIはソースを読まなくても、モデル本人に聞ける。デモで readonly_attributes に聞いたのが、まさにこれ 15
16. 3. Notifications — アプリは最初から計装されている ActiveSupport::Notifications のイベント sql.active_record APM New Relic、Datadog、Skylight… あなたのRailsアプリ コードは変更しない enqueue.active_job debug-mcp cache_read.active_support 購読しているだけ アプリのコードに一切手を入れずに、発行されたSQL、ジョブの投入、キャッシュの読み書きまで観測できる。 デバッガの機能ではない。Railsがフレームワーク全域に最初から計装を張っているから。APMと同じ仕組みを、debugmcpが購読している。 Railsは最初から全域を計装している。debug-mcpはそれを購読しているだけ 16
17. RailsがAI時代に輝く理由 AI — 事実ベースのデバッグ Rails — 人間のために積み上げてきた観測可能性 モノリス · リフレクション · Notifications Ruby — 開かれたランタイム debug gem、リモート接続 そのまま転用 人間のために作られたものが、AI時代に思わぬ配当として返ってくる。 Rubyの開かれたランタイムの上にRailsが積み上げた観測可能性が、AIの土台にそのまま転用できる。 17
18. 【応用】テストが失敗した、その瞬間に 時間 現状 assertionが失敗（例外 がraiseされる） RSpecがレポートに変 換（期待値と実際の値 だけ） 実行時の状態は消え ている。もう調べられ ない 例外ブレーク ポイントあり assertionが失敗（例外 がraiseされる） その場でプロセスを停 止。状態を保全 AIエージェントを後か ら送り込み、現場で調 査 continue → 通常のレ ポート 再現しないflakyテスト。同じseed・同じ順序でも出たり出なかったりする。失敗したその実行が唯一の証拠なので、現 場保全だけが手段になる。 実験実装で動作を確認済み（gem本体の機能とは区別）。公開は今後の予定。 テスト失敗の瞬間にプロセスを止めて保全し、AIを後から送り込む。ループの最悪形であるflakyテストの出口 18
19. 安全の線引き 開発環境 本番環境 デバッグソケットが開いている → エージェントが接続できる ソケットがない → 接続する先がない RUBY_DEBUG_OPEN=true 普段の運用が、そのまま防壁 • デバッガをAIに開放するとは、AIに任意コード実行を許すこと。能力の源泉であり、同時にリスク。 • 人間に残すのは、検証ではなく判断。不可逆な操作をするかどうか、どの環境で許すか。 • 開発環境限定で使う。これが線引き。そもそも、デバッグソケットを開いたプロセスにしか接続できない。 開発環境限定。人間に残すのは検証ではなく判断。本番でソケットを開かない運用が、そのまま防壁になる 19
20. まとめ これまで 確信のない修正と人間の動作確認のループ。AIは仮説を事実に確定できず、推測で直すしかなかった これから debug gemをMCPで開放すると、AIは事実を確かめてから直し、直ったことまで自分で検証する。人間に返るのは判断 だけ 支えていたもの モノリス・リフレクション・Notifications。Railsが私たちのために積み上げてきた観測可能性 事実を確かめてから直し、直ったことまで自分で検証する。支えるのはRailsの観測可能性 20
21. debug-mcp まず自分の手でbinding.breakを書いて止めて、変数を見る。AIにさせるのは、そ れと同じこと。 あとは、お使いのエージェントに繋ぐだけ。 AIのデバッグ能力は、実行時の事実を渡す設計で今日から上げられる。 そしてその設計に最も向いたフレームワークを、私たちはすでに使っている。 ありがとうございました。 github.com/rira100000000/debug-mcp debug gemはもうGemfileに入っている。あとはお使いのエージェントに繋ぐだけ。ありがとうございました 21
22. 予備 1/6 — 依頼文 映像 0:00 の場面 email が nil で /users/6 は500。PATCH で 直して、200が返った。でも GET /users/6 は まだ500。なぜ反映されないのか、AIに調べ させます。 映像が再生できないときだけ使う。 1/6（映像 0:00） 22
23. 予備 2/6 — connect 映像 0:16–0:32 の場面 AIはまず仮説を並べます。別のレコードを 更新した？ 表示側？ キャッシュ？ ここか ら推測で直すと、ループが始まります。そこ で debug-mcp で、動いている Rails プロセ スに接続しています。実行時の事実を見る ための準備です。 映像が再生できないときだけ使う。2/6（映像 0:16–0:32） 23
24. 予備 3/6 — ソースを読む 映像 0:41–1:06 の場面 コントローラとモデルを読みます。show が email_domain を呼び、email が nil なら落 ちる。500の仕組みはこれです。concern や モジュールも調べ、PATCH と GET が別の データを見ている可能性を疑っています。 映像が再生できないときだけ使う。3/6（映像 0:41–1:06） 24
25. 予備 4/6 — readonly_attributes → ["email"] 映像 1:22–1:50 の場面 attr_readonly :email に気づきました。有力 な仮説。でもAIは言います。「ソースだけの 仮説。断定せず、rails_model で確認する」。 User.readonly_attributes は ["email"]。ソー スの仮説が実行時の事実になりました。リ フレクションを有効に活用できています。 映像が再生できないときだけ使う。4/6（映像 1:22–1:50） 25
26. 予備 5/6 — 発行されたSQL: UPDATE に email がない 映像 2:04–2:29 の場面 update 直後の行にブレークポイントを置き、 AI自身が PATCH を送りました。発行された SQLが全部見えます。4番の UPDATE に email がない。updated_at だけ。コードに は触っていません。これが Notifications で す。 映像が再生できないときだけ使う。5/6（映像 2:04–2:29） 26
27. 予備 6/6 — メモリ上は新しい値、reload は nil 映像 2:42–3:00 の場面 @user.email と reload した値を評価し、DB の事実と突き合わせます。メモリ上の email は新しい値、DBを読み直すと nil。だ から200が返り、実データは変わらない。推 測は、どこにも入っていません。この後、AI は修正方法を人間の判断に委ねて止まり ます。 映像が再生できないときだけ使う。6/6（映像 2:42–3:00） 27