Railsモノリス上でAIエージェントを一年かけて育てた話

RailsアプリにLLM/AIエージェントを組み込む際の「泥臭い」実践知見を共有します。

【主なトピック】

技術選定： なぜ初期フェーズでマイクロサービスではなくRailsモノリスを選んだのか

通信の課題： ActionCable（WebSocket）によるストリーミング実装で起きた本番環境でのタイムアウト・切断問題と、その解決策（WebSocket/Pollingのハイブリッド化）

安定性向上： JSONのパースエラー対策（Converse API/Tool Callへの移行）とリトライ機構

今後の展望： Railsを卒業し、TypeScriptエコシステム（Vercel AI SDK等）への移行を進めている理由

Rails上でAI機能を実装しようとしている方や、AI機能の安定稼働に悩んでいる方の参考になれば幸いです 。

Transcript

1. Rails モノリス上でAI エージェントを 一年かけて育てた話 株式会社スタディスト AI エンジニアリング室（業務委託） 株式会社YTAL 代表 Yuta Okazaki 1
2. 自己紹介 Yuta Okazaki 株式会社スタディスト AI エンジニアリング室（業務委託） 経歴: 海外スタートアップや大手テック企業での経験がメイン Shopify: 2020-2022: 世界で一番大きな？Rails モノリスにて機能開発 現在: 株式会社YTAL （ワイタル） を創業 Yuta + Taro + AI Lab = YTAL AI 駆動開発を積極的に発信予定 2
3. 今日のテーマ 3
4. Rails モノリスとAI エージェント 株式会社スタディストの主力ウェブアプリ 「Teachme Biz 」 での開発事例 開発したもの: 「おまかせ編集アシスタント」 マニュアルを自動作成・編集する機能 「Teachme Biz で良いとされるマニュアルの型」に則った構造化データを作成 既存の（人力）編集画面とシームレスに動作させる必要 4
6. AI エージェント？ 自律的に判断・行動し、目標達成のために複数のツールやAPI を組み合わせて動作するAI システ ム (Google AI Overiew) 編集アシスタントはおそらく「Semi Agentic 」 ユーザーとの継続的な対話履歴を保持・解釈し、次の行動を判断 マニュアルに付随する画像・動画データを理解させている ただ、あくまでSequential な実行：If/Loop は未実装（設計上サポートはしている） 6
7. ここからが本題 7
8. 当時の状況 (2024 年7 月) プロトタイプ: Python / LangChain / Streamlit 製 提示された選択肢： 1. Rails 上で実現するか？ 2. マイクロサービスを立てるか？ 8
9. 判断基準 1. 複雑さの度合い 2. データのアクセスパターン 当時の状況判断： AWS Bedrock(Runtime Client) 呼び出し: Rails 上ですでに実装済み 複雑さ: ライブラリなしでも十分実装可能に見えた データアクセス: コンテキストへのデータ注入など、柔軟性を保ちたい（Rails との密結合が 有利） 結論: Rails の中で一からエージェント的な振る舞いを実装する 9
10. ## 設計図 │ │ graph.invoke(state=S in Redis) ▼ ┌────────────────────────────────────────────────────────────────────────────┐ │ Graph │ │ ( ノードとエッジで状態遷移を管理) │ │ │ │ ┌─────────┐ ┌───────────────┐ ┌──────────┐ ┌─────────┐ │ │ │ START │-(S)->│ AppendLatest │ -(S)─>│ Bedrock │─(s)-> │ Json │ │ │ │ │ │ ManualNode │ │ Node │ │ Extract │ │ │ └─────────┘ └───────────────┘ └──────────┘ └─────────┘ │ │ │ │ │ │ │ │ │ │ ▼ ▼ │ │ ┌──────────┐ ┌─────────┐ │ │ │ Streaming│ │ EXIT │ │ │ │ Response │ │ │ │ │ └──────────┘ └─────────┘ │ └────────────────────────────────────────────────────────────────────────────┘ 10
11. 実際やってどうだったか 良かった点 データアクセスやバックエンド部分は概ね予想通り 初期実装から大きく姿を変えずにメンテできている 辛かった点 フロントエンドとの通信部分 特にストリーム通信周り 11
12. ストリーム通信の課題 ActionCable で実装 プロトタイプ時は問題なかったが、本番相当環境で課題が頻出： 長大なデータ生成時の Nginx timeout アプリサーバーのキャパシティ占有 サーバーリスタート時の再接続切れ クライアント環境のネットワーク制約（WS 不可など） 12
13. 通信課題への解決策 1. Job 側への処理移動 2. フォールバック機構の実装 もしWebSocket 接続が確立できない、あるいは途切れた場合： HTTP Polling に切り替え 現在は WebSocket 50% : Polling 50% 程度の比率で稼働中。 これにより本番環境でも安定動作を実現。 13
14. 通信以外の取り組み：安定化への道 リリース後に実施した主な改善： 1. JSON 処理・エラー対策 2. リトライ・フォールバック機構 3. Bedrock クライアント最適化 4. 監視・ログ強化 14
15. JSON 処理・エラー対策 JSON Parse/Repair エラーの撲滅 invoke → converse API 移行によるJSON エラー対策(Tool Call) LLM からの不完全なJSON を修復してから後続処理へ Sonnet 4 使用によるエラー削減 現在は、プロバイダー側でJSON やSchema 完全を保証し始めている 15
16. リトライ・フォールバック機構 エラー時の復旧機能 5xx 系キャパシティエラー時の別モデルフォールバック モデルダウングレード → リージョンスイッチ も後に追加 16
17. Bedrock クライアント最適化 & 監視 最適化 パラメータ管理の効率化 ( BedrockParameterFactory ) count tokens API による正確なトークン管理 max_tokens 増加による truncation 回避 監視・ログ ユーザー視点の待機時間計測 Datadog によるActiveJob 監視 Sentry でのレスポンスタイム計測 17
18. Basic Observability からの LLM Ops 18
19. 今ふりかえってどうか 19
20. 現在の取り組み：分離へ Rails の中に閉じ込める時代からの決別 現在は、LLM 実行環境の分離を試みている。 理由1 ：インフラ準備済み スタディスト組織として、マイクロサービスを実行できる環境・ステージング・Telemetry が整備 されている 理由2 ：抽象化の業界標準ができてきた Tool Call や MCP のツールチェインが成熟してきた LLM 実行環境とデータ層のやり取りの手戻りのリスクが当時より少ない 20
21. TypeScript エコシステムへの移行検討 LLM アプリの期待値の変化 ステータスアップデート Chain of Thought の表示 Human in the Loop TypeScript の優位性 Vercel AI SDK / Mastra などの成熟 Telemetry のサポート (TS/Python は First class citizen) Ruby で同等のエコシステムを維持するROI が見込めない 21
22. まとめ 1. Rails 上でのAI エージェント実現は十分に可能 マイクロサービス化必須ではない 2. ただし、考慮すべき点は多い 通信（WS/Polling フォールバック） （本番運用での）先駆者となる勇気 3. 個人的なBet はTypeScript だが.. 流動的な分野では、まずは既存資産の上で作る その後、出来てきたエコシステムに乗っかる （AI 駆動開発でリプレースコストが下がってきている背景もある） 22
23. ありがとうございました！ Rails でAI エージェントを実現しようとしている方、 ぜひ情報交換しましょう！ Twitter: jp_okazaki 株式会社スタディストも絶賛採用中！ 23