肥大化するRailsへの処方箋 AI駆動開発のポテンシャルを引出す「モジュラ・モノリス」の実践アプローチ

Railsアプリの肥大化で境界が曖昧になり技術負債に悩んでいませんか？
AI時代に並列開発で生産性を高めるためには、モジュラ・モノリスが有効です。
なぜ今注目されるのか・AIとの相性の良さ・気軽に始められる実践アプローチ・実際のチーム導入事例を紹介。

Transcript

1. 肥大化するRailsへの処方箋 AI駆動開発のポテンシャルを引出す 「モジュラ・モノリス」の 実装アプローチ 2026/03/26 サポーターズCoLabランチイベント 株式会社TOKIUM Webエンジニア 阪下 駿
2. プロダクト本部 オペレーション開発部 阪下 駿 Suguru Sakashita 経歴 大手通信会社にて経理として新卒のキャリアをスタート。 その後、Webエンジニアにジョブチェンジし、Ruby on Rails のバックエンド開発を経験。 2024年にTOKIUMに入社し、書類データ化システムのチーム リーダーを務める。 自己紹介 2
3. 会社名 株式会社TOKIUM 設立日 2012年6月 所在地 東京都中央区銀座6-18-2 野村不動産銀座ビル 12F 従業員数 約240名 （2025年11月、正社員のみ） 代表取締役 黒﨑 賢一 TOKIUMの志 未来へつながる時を生む 会社概要 3
4. 経理AIエージェント「TOKIUM」は、AIとプロスタッフが連携し、経理作業を丸ごと代行。単に効率化するのでは なく、作業自体を手放すことで「時を生み」 、全社員が本来の業務に集中できる環境を実現。 日常的な言葉で指示 経理作業を丸ごと代行 作業完了 「経理AIエージェント TOKIUM」とは 4
5. 解決している課題 経費申請の不備・誤りのチェックを含めた一次承認作業 を、AIとプロスタッフが代行。 社内規程やルールに基づいた申請内容の目視チェックや、 頻発する内容不備による差し戻し対応の手間をなくしま す。 移動経路の検索・宿泊先の手配、出張申請…。 出張手配の「探して、予約して、申請して」をAIエージェ ントが代わりに実行します。 5
6. 累計導入社数3,000社を突破 直近3年で3倍増加 導入実績 ＊2025年11月末時点、シリーズ累計 6
7. 1. モジュラーモノリス導入のきっかけ 2. モジュラーモノリスとは 3. 実践編 ― プロジェクトでの導入 4. 応用編 ― アーキテクチャーの選択とAI アジェンダ 7
8. モジュラーモノリス導入の きっかけ 8
9. チームメンバーは全3人 10年モノのモノリスRails MVCを逸脱し、肥大化したアーキテクチャー MVCではどうしても苦しい、複雑な状態遷移があるドメイン engineer engineer engineer ↓ app/ ├── commands/ ├── controllers/ ├── domains/ ├── helpers/ ├── jobs/ ├── mailers/ ├── models/ ├── parameters/ ├── policies/ ├── queries/ ├── serializers/ ├── services/ ├── specifications/ ├── validators/ └── views/ チーム参画当時 9
10. 負債と向き合わずに新規実装をしたい... 新規開発を止めてリプレースしたいが、そんな猶予やリソースはもらえない... コーディングエージェントをフル活用したい... 負債に苦しめられる日々 10
11. Controller Controller A Controller B Controller C Model Model X Model Y Model Z DB table_x table_y table_z JOIN JOIN Controller → Models → DB の依存に境界がないため、 どのControllerからも任意のModelを参照でき、Model間も自由に結合する なぜつらいのか ― 密結合が伝播しやすい構造 11
12. app/model 継承 / 利⽤ 継承 / 利⽤ 継承 / 利⽤ 永続化先は 1 つ Order::Use Payment::Use Shipping::Use ::User (ActiveRecor users テーブル email order_notification_enable default_payment_metho shipping_priority support_locale 名前空間で分けても、実テーブルが1つだと 本質的に関心は分離されない 結果として各コンテキストの「最大公約数」 を背負って肥大化する 変更時に「どの業務へ波及するか」を読み づらくなる なぜつらいのか ― 共有テーブルの問題 12
13. Service A Controller Model DB Service B Controller Model DB Service C Controller Model DB Service D Controller Model DB API で密結合 = 分散モノリス Engineer Engineer 少人数で複数サービスを管理 → 認知負荷・運用コスト増大 ではマイクロサービスにすればよいか？ 13
14. そ う だ そ う だ モ ジ ュ ラ ー モ ノ リ ス 、 モ ジ ュ ラ ー モ ノ リ ス 、 移 行 移 行 14
15. モジュラーモノリスとは 15
16. モノリス Controllers Models DB Schema A Schema B JOIN 共有 DB（JOIN で密結合） Controller → Models → DB が直接依存 モジュラーモノリス Module A Controller Model Module B Controller Model Module C Controller Model DB Schema A Schema B Schema C 単一 DB（スキーマで論理分離） ドメイン境界で分割・単一デプロイ マイクロサービス Service A Controller Model DB Service B Controller Model DB Service C Controller Model DB サービスごとに独立 DB 完全分離・個別デプロイ モジュラーモノリスとは モノリスの開発体験を保ちながら、内部をモジュールに分割するアーキテクチャ “ 16
17. モノリス 1つの家 モジュラーモノリス 1つの家の中に 複数の機能がある マイクロサービス 複数の家に分かれている 例えるなら... 17
18. 単⼀ DB （論理分離） packs/ Customer packa Order packag 永続化 永続化 公開 API 経由で連携 Order::Custome Customer::Custom order_customers email order_notification_enable shipping_priority customers email company_nam billing_plan 例: Order::Customer と Customer::Customer のように業務ごとに 独立したモデル・テーブル定義が可能 連携は公開API経由に絞ることで、変更影響 を局所化できる デプロイはモノリスのままなので、運用は シンプル モジュラーモノリスのメリット 18
19. モノリス モジュラーモノリス マイクロサービス デプロイ 単一 単一 サービスごと コードベース 1つ 1つ（モジュール分割） サービスごと データ 共有DB 論理分離 物理分離 モジュール間通信 直接参照 明示的インターフェース ネットワーク（API） 開発の独立性 × △ ◦ 運用の複雑さ × △ ◦ 3つのアーキテクチャ比較 19
20. 新規実装はモジュラーモノリスのパッケージとして作ることで、既存影響を受けずにまっさ らな状態で開発を進める 既存実装については、変更が必要なタイミングでパッケージ化を検討する 新しい部分はピカピカに、古い部分は少しずつ 20
21. 実践編 ― プロジェクトで の導入 21
22. rails-app/ ├── app/ # 既存の Rails コード │ ├── controllers/ │ ├── models/ │ └── ... ├── packs/ # モジュラーモノリスのパッケージ群 │ ├── product/ # ドメインパッケージ │ ├── order/ # ドメインパッケージ │ ├── notification/ # 基盤パッケージ │ └── ... └── ... ディレクトリ構成 22
23. Package A Package Controlle Public API Service Mode Mode DB Public API A Service Mode Mode DB Controller は既存の権限管理ロジックが根深く、 段階的な移行のためパッケージ外に残すことにした プロジェクトでの構成 23
24. ドメインパッケージ ― ビジネスの境界で分割 機能・基盤パッケージ ― 複数ドメインから広く依存される技術基盤 基盤パッケージ ドメインパッケージ 受注管理 在庫管理 請求処理 イベントバス 通知配信 パッケージの種類 24
25. Shopify はモジュラーモノリスの実践で、パッケージの分類について次のように述べている: ― A Packwerk Retrospective (Shopify Engineering, 2024) ドメインとして分割されるパッケージと、システム上の役割で分割されるパッケージが共存 する 後者は Shopify では Platform コンポーネントと呼ばれ、基盤的な位置づけ → つまり、機能的なパッケージが存在してもよい 機能的なパッケージは存在してもよいの？ "We are faced with a dichotomy: some components are domains, while others are designed around the functional role they play in the application." “ 25
26. packs/customer/ ├── app/ │ ├── models/ # ドメインモデル │ │ └── customer/ │ ├── public/ # 外部公開インターフェース │ │ └── customer/ │ │ └── public.rb │ └── use_cases/ # ユースケース実装 │ └── dto/ # データ転送オブジェクト ├── docs/ # パッケージ固有のドキュメント └── spec/ # テストコード ├── factories/ ├── models/ ├── public/ └── use_cases/ パッケージ内部の構成 26
27. class OrdersController < ApplicationController def index # Order パッケージから注文一覧を取得 orders = Order::Public.list_by_customer( customer_id: current_customer.id ) # Customer パッケージから顧客の表示名を取得 customers = Customer::Public.names_by_ids( customer_ids: orders.map(&:ordered_by).uniq ) # Shipping パッケージから配送ステータスを取得 statuses = Shipping::Public.statuses_by_order_ids( order_ids: orders.map(&:id) ) @orders = orders.map do |o| { order: o, customer: customers[o.ordered_by], status: statuses[o.id] } end end end Controller はパッケージの公開APIのみを通じてアクセスし、内部実装には依存しない 実装例 ― Controller から公開APIを呼び出す 27
28. 公開API（パッケージの入口 → 公開オブジェクトに変換） # packs/customer/public/customer/public.rb module Customer::Public def self.register(email:) result = ::Customer::Register.call(email: email) Dto::Customer.new(**result) end end ユースケース（内部モデルをオーケストレーション） # packs/customer/app/usecases/customer/register.rb class Customer::Register def self.call(email:) customer = ::Customer::Customer.create!(email: email) settings = ::Customer::NotificationSetting.create_defaults!(customer_id: customer.id) { id: customer.id, email: customer.email, notification_channels: settings.pluck(:channel) } end end 公開オブジェクト（ActiveRecordモデルを外部に露出させない） # packs/customer/public/dto/customer.rb class Customer::Public::Dto::Customer attr_reader :id, :email, :notification_channels def initialize(id:, email:, notification_channels:) @id = id @email = email @notification_channels = notification_channels end end 実装例 ― 公開APIの内部構造 28
29. パッケージ名がそのままテーブル名のprefixになる パッケージ間で外部キー参照を持たないように規約で注意 PKとは別の公開識別子を共有する(マイクロサービスのような考え方) Payment packag Order packag Customer packa 同⼀ package 内の F customer_custome ──────── id public_id(uuid) email status order_orders ──────── id public_id(uuid) customer_public_id(uui ordered_at order_items ──────── id order_id sku quantity payment_charges ──────── id order_public_id(uuid amount status package 間は内部 id を参 照せず public_id / uuid を値とし て保持する 実装例 ― DB定義 29
30. 負債を気にせず新しいコードを書ける Rails の高速な開発を取り戻せる 開発の独立性 最悪間違えても捨てれば済む 契約(公開API)のみ決めておけば、パッケージごとに自由かつ同時平行で開発を進められる 感じたこと ― Good 30
31. システム構造が抽象化され、理解が容易に 顧客参照 在庫引当 決済依頼 配送依頼 注⽂確認 配送通知 注⽂ 顧客 在庫 決済 配送 通知 感じたこと ― Good 31
32. 境界設計の難しさ パッケージの切り方を間違えると、かえって複雑になる 規約ベースゆえの脆さ 境界を跨いだテーブルの関連を作れてしまう ボイラープレートの増加 公開APIやDTOなど、直接参照に比べて書くコードが増える 感じたこと ― Bad 32
33. packs/customer/ ├── app/ │ ├── models/ │ │ └── customer/ │ │ └── user.rb │ ├── public/ │ │ └── customer/ │ │ └── public.rb │ └── use_cases/ └── spec/ → app/ ├── models/ │ └── user.rb ├── use_cases/ └── ... パッケージが Rails Way に従っていれば、ファイル移動と名前空間の調整で済む モノリスに戻すのは比較的かんたん 33
34. Step 1 ― 規約ベースで小さく始める packs/ にパッケージを切り、公開API経由のアクセスを規約にする 境界の探索段階では身軽に試行錯誤できる 既存への依存が少ない新規機能などがベスト Step 2 ― 境界が固まったら Packwerk で強制 package.yml を追加し、依存ルールを定義 既存の違反を許容しつつ、新規の違反のみ検出 おすすめのはじめ方 34
35. 応用編 (アーキテクチャーの選 択、AI) 35
36. 公開APIさえ守れば、パッケージ内部の設計は自由に選択できる packs/payment/ ├── app/ │ ├── aggregates/ # 集約 │ ├── commands/ # コマンド │ ├── events/ # ドメインイベント │ ├── public/ # 外部公開インターフェース │ └── projections/ # リードモデル └── spec/ 状態遷移が複雑なドメインでは、Rails Way に縛られず イベントソーシングなどのアーキテクチャを採用している ただし、既存実装に戻せなくなる点がトレードオフ パッケージごとにアーキテクチャーが異なっても良い 36
37. モノリス Model A Model B Model C Model D Model E Model F AI ? ? ? 影響範囲が不明 暗黙の依存が絡み合い AIが影響範囲を特定できない モジュラーモノリス Order Public API Notification Public API Customer Model UseCase Public API AI ✓ 責務と影響範囲が明確 公開APIが境界となり AIが責務と影響範囲を把握できる AI駆動開発との親和性が高い 37
38. Step 1: 公開 API の契約を決める Order::Public Customer::Public Shipping::Public Step 2: パッケージごとに並列で実装 Order AI Agent 1 Model UseCase Public API DTO spec/ テスト作成 Customer AI Agent 2 Model UseCase Public API DTO spec/ テスト作成 Shipping AI Agent 3 Model UseCase Public API DTO spec/ テスト作成 契約（公開API）さえ決めれば、内部実装は同時並行で進められる パッケージ単位でAIに並列開発を任せやすい 38
39. 「感じたこと Bad」で挙げたボイラープレートの増加のコストが0に 公開API・DTO・テストの雛形 → AIが数秒で生成 面倒な定型コードこそ、AIが最も得意 開発者はビジネスロジックと境界設計に集中できる AIがボイラープレートを解消 39
40. Order Model Public UseCase ✓ Customer Model Public UseCase ✗ AI がミス Shipping Model Public UseCase ✓ Notification Model Public UseCase ✓ Product Model Public UseCase ✓ Payment Model Public UseCase AIに実装を任せた結果の失敗の影響が限定的 パッケージ丸ごとAIに書き直させるコストも限定的 AIの失敗コストを最小化できる 40
41. モジュラーモノリスは、モノリスの開発体験を保ちつつ、ドメイン境界で内部を分割するア ーキテクチャ 規約ベースで小さく始めて、境界が固まったら Packwerk で強制できる モジュールの明確な境界が、AI駆動開発との相性を飛躍的に高める まとめ 41
42. 本日のスライドは公式Xで公開！ 開発チームの技術やイベントに関する情報を発信しています！ フォローお願いします！ @TOKIUM_Dev 資料公開＆技術発信は公式Xから 42
43. カジュアル面談実施中！ 現場のメンバーと気軽にお話しませんか？ 詳細はこちら 技術的チャレンジ AIエージェントの群れを量産し、多数のサービスとの連 携を素早く実現する AIエージェント実行制御を行う共通基盤の開発を進める 継続的に品質を上げる仕組みや、セキュリティ・ガバナ ンス向上の仕組みを構築する 一緒に挑戦してくれる仲間を募集してます！！ エンジニアを募集しています！ 43
44. 未来へつながる時を生む 株式会社TOKIUM 東 京 本 社 〒104-0061　東京都中央区銀座6丁目18-2 野村不動産銀座ビル12階 西 日 本 営 業 所 〒550-0015　大阪府大阪市西区南堀江1丁目1番14号 四ツ橋中埜ビル7階 URL: https://www.keihi.com/company 44