NaCl東京支社の関戸です。
2026年10月16日(金)〜17日(土)に渋谷で開催された Kaigi on Rails 2026 に参加しました。
NaClからは、まつもとさんが基調講演を、社長の前田と東京支社の早川がそれぞれセッションで登壇しました。
この記事では、Kaigi on Rails 2026で特に印象に残った3件の発表についてご紹介します。
AIエージェントのデバッグ能力を向上させよう — AI時代にRailsが輝く理由
弊社の早川による、AIを用いたデバッグに関する発表です。AIエージェントが自律的にバグを調査・修正するためのアプローチと、Railsフレームワークが持つ観測可能性の高さについて紹介されました。
AIエージェントのデバッグにおける課題
AIにデバッグを依頼すると、AIが推測で修正を行い、人間に確認を依頼しては失敗するという「不毛なループ」に陥ってしまう問題が指摘されました。
原因は、AIが「実行時の状態(事実)」を直接確認できず、ソースコードなどから得られる「仮説」のみに頼って修正を試みることにあると説明されました。特に実行時の状態に依存するバグでは、AIが事実を確定できないため、修正も検証も推測ベースになってしまうそうです。
解決策としての debug-mcp
AIに実行時の事実を確認させる手段として、Rubyの debug gem をMCP経由でAIに公開する debug-mcp サーバーが紹介されました。これにより、AI自身が外部ツールとしてデバッガを操作し、次のようなことができるようになるとのことです。
- ブレークポイントの設定
- 実行の停止と変数の確認
- 式の評価やスタックの取得
デモでは、ユーザーのメールアドレスが更新されないバグに対して、AIが自律的にブレークポイントを設定し、リクエストのパラメータやSQLの実行結果を確認しながら原因を特定し、確信を持って修正する様子が示されました。
Railsの観測可能性の高さ
デバッガをAIに渡すアプローチでは、Railsの特性が非常に有利に働くと解説されました。
- プロセスが一つにまとまっているため、デバッガを1本つなぐだけでリクエストの全容を把握できる
- システム自身が構造や関連性を自己記述できるため、AIがソースコードを読まなくてもモデルの情報を得られる
- フレームワーク内部のイベントを外部から観測しやすい
これらの特徴により、Railsで作られたアプリケーションは実行時の観測可能性が高く、AI時代にも相性のよいフレームワークであると結論づけられました。
感想
推測に頼りがちなAIエージェントに、debug-mcp を通じて実行時の事実を直接確認させるアプローチは非常に合理的で、デバッグの精度と効率を大きく高める可能性があると感じました。また、モノリスやリフレクションといったRailsの従来の特徴が、AIエージェントにとっての観測可能性の高さという新たな強みになるという視点も大変興味深く、実践的なAI活用のヒントになりました。
小さく作ってわかるRailsの仕組み 〜mini-rails〜
Railsの仕組みについての発表です。自分でRailsを小さく作りなおすことで、Railsの裏側で何がどう動いているのか、その仕組みを解き明かしていくというお話でした。
問題があったときに小さく作って確認するのは、私も普段からよく使う学習方法なので、興味深く聞くことができました。
開発のきっかけ
Railsの起動処理など、裏側で何が行われているのかを深く理解できていないという課題を感じていたそうです。大規模で複雑なRailsのソースコードをいきなり読むのはハードルが高いため、小さく自作すれば全体の流れがつかめるのではないかと考え、開発を始めたとのことです。
新しいことを学ぶときは、まず小さく作ってみるほうが飲み込みが早いという、ご自身の学習スタイルに基づいて進められたそうです。
mini-railsの内部構造と処理の流れ
Railsの構造を参考に学習用として実装した「mini-rails」を題材に、コードの動きが詳しく解説されました。
土台にはRackを利用しており、リクエストを受け取ると、ルーティング機能がパスを評価し、対象となるコントローラーのアクションへディスパッチします。ルーティングから呼び出されたアクションでは、モデルを通じてデータベースから対象のデータをインスタンスとして取得します。アクションの実行後、ERBテンプレートを呼び出し、取得したデータを埋め込んでHTML文字列に変換し、最終的なレスポンスとして返す、という一連の流れが説明されました。
感想
普段はブラックボックスとして扱いがちなRailsの内部挙動を、Rack層からルーティング、コントローラー、ERBによるレンダリングに至るまで自分で小さく再実装して紐解くというアプローチが、とても素晴らしいと感じました。巨大なソースコードを前に圧倒されるのではなく、最小限のものを作って概念の骨格をつかむという手法は、他の技術や複雑なフレームワークを学ぶ際にも参考になります。
私自身も同じように学習することがありますが、「どこまで模倣するか」の線引きにはいつも迷います。「やりたいことができる分だけ実装する」というアプローチは効率がよさそうなので、真似してみたいと思いました。自作を通じてRailsの全体像を俯瞰できるようになるという、実りのある学習プロセスを共有していただけたことが、とてもよかったです。
RailsはAIという責務をどう受け入れるのか — AIという新しい責務をRailsらしく設計する
LLMを利用したAI機能をRailsアプリケーションに組み込む際の課題と、その解決策についての発表でした。特にモデルに詰め込みすぎてFat Modelになってしまうというところはよくある話だと思いながら聞き入り、Railsらしいとは何なのかをもう一度考えるきっかけになりました。
AI機能の実装と設計の壁
社内で人が行っていた記事のレビュー業務を効率化するため、LLMを用いたAIレビュー機能を実装したそうです。当初は、リクエストの組み立て、プロンプトの定義、APIクライアントの処理などをすべて単一のモデル層に実装していたとのことです。
しかし、GeminiからOpenAIなど他のモデルを試したり、要約などの別機能を追加したりするうちに、コードが肥大化していったそうです。その結果、「プロンプトやレスポンスの形式をどこに定義すべきか」「AI固有の関心事をどこに置くべきか」という明確な答えが出せず、モデル層に処理を置き続けることに違和感を覚えるという設計上の壁にぶつかったと説明されました。
ActiveAgentの導入と「Railsらしさ」の発見
これらの課題を解決するためにActiveAgentを採用し、AIに関する責務を、RailsのMVCに近い形で分離・構造化したそうです。
Agent層は、コントローラーやメイラーのような役割を持ち、AIに何をさせるかを定義して、パラメータを受け取り処理を実行する位置づけだと説明されました。View層ではERBテンプレートを用いて、AIに渡すプロンプトの文章や、期待するレスポンスのフォーマット(JSON形式など)を定義する形になっているとのことです。
責務を分割したことでコードが整理され、「どこに何を書くべきか」をフレームワークが規定してくれる点に、「設定より規約(Convention over Configuration)」や「Omakase」といったRailsの根底にある思想のありがたさを改めて実感した、と語られました。
感想
AIのプロンプトやAPI呼び出しの責務を既存のモデル層に詰め込んでFat Model化してしまう問題は、実際の開発現場でも直面しやすい課題だと思います。プロンプトをViewとして扱い、AgentをControllerやMailerのように振る舞わせるアプローチは、議論を呼びそうではありますが、とても面白いと感じました。
新しい技術要素を導入する際に、既存のアーキテクチャや思想を応用することで、方向性を保った設計ができるという知見は、大変参考になりました。
最後に
時代の移り変わりなのか、今回はAIに関する発表がとても多かった印象です。一方で、すべてをAIに丸投げして安心できる時代にはまだなっていないとも感じました。この過渡期の中で、自分に何ができるのかをよく考えていきたいと思います。
おまけ
Rails生みの親とRuby生みの親による基調講演は、とても話題になりました。
弊社の早川による登壇の様子です。
弊社社長の前田による登壇の様子です。
