20年超レガシー『バイトル』をAI駆動で再設計!事業成長を実現するリアーキ戦略
はじめに
こんにちは!ディップ株式会社 執行役員 CTOの長島です。
今回はアーキテクチャカンファレンス2025での登壇でお話しした内容を残しておこうと思います。
20年以上続く求人サービス『バイトル』。この巨大モノリスと日々向き合い、私たちは事業成長を続けながら大規模リアーキテクチャに挑んでいます。既存システムと共存しつつ、複雑な技術負債の解消、ドメイン再設計、マイクロサービス移行の意思決定。持続可能性とスケーラビリティを両立させるこの戦略と、変革を推進した組織のリアルを共有します。
「技術的迷宮」からの脱出
私たちのシステムは、20年という長い歴史の中で増築を重ねた巨大な城塞であり、現在地もわからない状態。もはや「技術的負債」という表現では軽く、「技術的迷宮」と呼ぶべきものでした。事業成長を支える裏側で、システムは限界に達し、開発スピードの低下や、改修の影響範囲が看通せない「脆さ」が深刻な課題となっていました。
このままでは事業成長を支えられない。小手先の改善では限界であり、我々に残された道は抜本的な再設計、リアーキテクチャしかありませんでした。
我々が目指した3つの変革
我々はこの巨大な変革を成功させるため、以下の3つの大きな意思決定と変革を掲げました。
戦略(アーキテクチャ): 事業のズレを直すためのドメイン再設計と技術選定。
戦術(AIプロセス): AIを前提とした新しい開発プロセス、AIDLC(AI駆動開発ライフサイクル)の導入。
組織(チーム): 変革を推進するAIネイティブな体制と役割の再定義。
戦略:アーキテクチャの意思決定
全体設計思想:事業成長とAIネイティブの両立
我々の全体設計思想は、単なる負債解消ではなく、事業成長とAIネイティブの両立です。AIによる開発プロセスを前提とすることで、5年後も10年後も戦える持続可能なシステムづくりを目指しました。
アーキテクチャの根幹として、ドメイン駆動設計(DDD)を採用しました。これは技術的な役割で分割する技術駆動から、求人や応募といったビジネス領域(ドメイン)ごとに整理するドメイン駆動へと、思考の軸と全体の構造を転換するものです。
GoによるDDDとTDDを用いたリアーキテクチャの実践
技術選定の激論と結論
技術選定においては、標準化と陳腐化を重視し、OpenAPIとRESTを採用し、スキーマファーストに徹する方針を立てました。特に、BFF(Backend For Frontend)については激しい議論がありました。
論点:RESTへの統一とBFFの原則廃止
レガシーシステムからの脱却にあたり、私たちはまず、アーキテクチャをシンプルに保つため、RESTへの統一とBFFの原則廃止を初期決定としました。
BFFを原則廃止したことで、データ集約(アグリゲーション)の責務は必然的にクライアントサイドに移されました。私たちは、クライアントがSDK(Software Development Kit)を使って複数のAPIを型安全に叩けるメリットを優先し、モバイル共通ロジックにKMP(Kotlin Multiplatform)を採用することでこれを支援しました。

しかし、この方針に対し、現場エンジニアから「待った」がかかります 。
特定のビジネス要求、例えば画面表示のために複数のドメインデータを組み合わせる必要がある際、クライアントサイドでのアグリゲーションだけでは、汎用APIが「画面の都合を知りすぎて神API化してしまう」 、あるいは「パフォーマンス的に厳しい」 という反発の声が上がったのです。これはアーキテクチャの「独立性」と「保守性」を守りたいという現場の切実な声でした 。
激論の着地:「薄いBFF (BFF 2.0)」の復活
この激論の結果、現場の「保守性、独立性」を重視する視点こそが長期的なアーキテクチャとして正しいと判断し、薄いBFFとして限定的に復活させることに着地しました 。
- アグリゲーション: 複数サービスからの応答を束ねる 。
- 認証ゲートウェイ: 認証を一手に引き受け、裏側のAPIをセキュアに保つ 。
- UIへの最小限の変換 。
これにより、「Decoupling(疎結合)」を最優先しつつ、現場の開発生産性と保守性の両立を目指しました
論点:GraphQL vs REST
BFF不採用の方針を固めた上で、私たちはAPI設計をどうするか議論しました。

柔軟性の高いGraphQLを採用すべきという声もありましたが、最終的にはOpenAPIとRESTを採用しました。その背景には、GraphQLの「更新系処理の複雑化」や、組織全体の「学習コスト」に対する懸念がありました 。私たちは、全員が知っているRESTを採用することで「堅実かつ最速の選択」を優先し、スキーマ駆動開発によるサーバー/クライアント双方のコード自動生成と堅牢性の確保を目指しました。
論点:認証基盤
レガシーシステムの内製認証基盤は、セキュリティリスクと保守コストが極めて高い状態でした。この課題を解消するため、AWS Cognitoを採用し、認証・認可の責務をAWSにオフロードしました。これにより、車輪の再発明を避け、開発リソースをコアビジネスに集中させることが可能になりました。

モノレポによる「秩序ある」リアーキとAI戦略
-
モノレポによる「秩序ある」リアーキ
既存の巨大モノリスと共存し、安全に移行を進めるため、新規開発領域にモノレポを導入しました。さらにCI/CDを分離することで、既存システムと共存しながらも、秩序だった安全なリアーキテクチャを推進しました。 -
「AIが前提」のアーキテクチャ
開発ガイドラインのゴールにAIネイティブを明記したのが最大の特徴です。AIがテストを書きやすいようにテストカバレッジ80%以上を義務化するなど、AI活用を組み込んだフローをルール化しました。
戦術:AI駆動開発プロセスのリアル(AIDLC)
私たちはAIDLC(AI駆動開発ライフサイクル)を導入しました。これは単なるコーディング支援ではなく、要件定義からAIを組み込むアプローチです。抽象的な要求をAIに入力すると、AIが詳細なユーザーストーリー、受け入れ基準、タスク分割までを支援します。
AIDLCワークショップの様子
- AI-DLCの威力: 従来数日から数週間かかっていた要件定義作業が、AIDLCでは数時間で完了しました。
- 実際のプロンプトの一部: AIには役割とルールを厳格に定義し、PMとしての振る舞いを指示。また、インタラクティブな壁打ちを強制し、AIが勝手に捏造しないよう不足情報は人間に質問するフローを組み込みました。
AI活用の前に立ちはだかる「3つの壁」(影の部分)
この成功体験をスケールさせようとした時、私たちは以下の3つの大きな壁に直面しました。

- ドメイン知識の壁: AIは20年モノのドメイン知識を知りません。AI活用の前提として、ドメイン知識の整理が不可欠でした。
- DDDの学習コスト: AIに正しい指示を出すためには、私たち自身がドメインを深く理解する必要があり、DDDの学習コストが重くのしかかりました。
- レビューのボトルネック化: AIが生成する大量のプルリクエストに人間が追いつかず、スループットが上がらない状況が発生。
この経験から、AIは銀の弾丸ではないこと、ドメイン知識の整理といった泥臭いプロセスの重要性を浮き彫りにしたことを学びました。

組織:変革を推進した体制
アーキテクチャ変革は「組織変革」である
最高の戦略と戦術も、それを使う組織が変わらなければ失敗します。私たちは、組織構造そのものにAIを組み込む決断をしました。
- 役割の再定義: 開発者の役割は、コーディングというHowはAIに任せ、「What、何をすべきなのか」「なぜすべきなのか」というドメインの定義や、AIの生成物をレビューし指導するという、より上流の意思決定へとシフトしました。
- 議論を知識に換える仕組み:AI活用の前提であるドメイン知識の壁を乗り越えるため、全ての議論をAIの知識に換える仕組みを構築しました。
- フロー情報のストック化: Slackの議論、会議の議事録など、あらゆるフロー情報をNotion AIなどに集約し、ストック情報へと変えました。
劇的なビフォーアフター
以前は数日かかっていた仕様確認が、AIへの質問で仕様回答は30秒で終わるようになりました。

AIによる「知識型ADR(Architecture Decision Record)」の実現: これにより、「いつ、誰が、どんな懸念を持って、なぜその決定をしたか」をAIが即座に回答できるようになり、ドキュメントは人が探すものから、AIが使えるものへと役割が変わったのです。
この一連のプロセスは、開発ガイドライン策定までの道のりとなり、組織全体の目線を合わせるための羅針盤となりました。

レガシー資産は「AIの教師データ」へ
20年超のレガシーは「AI駆動」で再設計できる。
レガシー資産は「負債」ではなく、そこには20年分のビジネスの成功法則、ドメイン知識が詰まった「AIの教師データ」であり、「資産」です。
レガシーとAIの掛け算ほど、エンジニアとして面白く、社会に大きなインパクトを与えられる挑戦のフィールドはありません。私たちもまだ旅の途中です。
テックブログでも、今回お話ししたAIDLCの挑戦や、具体的な技術tipsを失敗も含めて赤裸々に公開していますのでぜひご覧ください!
speakerdeck



今回はゴールドスポンサーとしてスポンサーブースも出展させていただきました!
Discussion