はじめに

これはCADDi Tech/Product Advent Calendar 2025 5日目の記事です。

こんにちは、Data&Analysis部の宇佐見です。最近30%キーボードを買って新体験のタイピングを楽しんでいます。

さて、今回はキャディにおけるRAGを利用したプロダクト開発の技術選定と開発プロセスについて紹介いたします。

キャディにおけるRAGの位置づけ

キャディでは、製造業AIデータプラットフォームを開発しており、その中の1機能としてドキュメント機能というものがあります。
これは、不具合情報や設計変更情報などの製造業に特化したドキュメントを管理・検索する機能です。自動的にドキュメント内容を読み取ることで、ユーザーはキーワードを用いてドキュメント検索することができます。
その中で我々はRAG技術を活用して、ユーザーがドキュメントから適切に情報を得られる機能の検証を行っています。

キャディにおけるRAG技術選定の変遷

初期の技術選定（何を重視したか）

初期の技術選定では、以下のポイントを重視しました。

顧客に届けられるまでの速度
- 我々はスタートアップであり、迅速な市場投入が重要です。また、キャディとしても初めてのRAGを活用したプロダクトであったため、早期にユーザーフィードバックを得ることが求められました。
実験のしやすさ
- 技術選定の段階では、様々なコンポーネントを試す必要がありました。実験のしやすさは、開発スピードに直結するため重要な要素でした。

技術選定で直面した課題

フェーズ変更に伴う課題の変化最初のPoCフェーズでは、実験のしやすさが重要であり、構成としては以下のようなものでした。

UI: Streamlit
LLM Framework: LangChain, litellm
検索エンジン: Elasticsearch

基本的にLangChainでingestionされたchunking, embeddingの取得を行い、Elasticsearchを利用して検索してからLLMを呼び出すという構成をとっていて、それをStreamlit上で見せる形でした。これにより、顧客にプロトタイプを早期に届けてフィードバックを得ることができました。しかし、本番開発フェーズに移行する際、以下のような課題が浮上しました。

LangChainの制約
- LangChainは非常に便利なフレームワークですが、簡単に利用できるようにされている反面、ロジックは隠されていて、動作を思うとおりコントロールするにはコードを深くまで読む必要があります。それにより開発効率が低下していると感じていました。また、当時はv1.0リリース前で破壊的変更が多かったこともあります。
プロダクトとの連携
- PoCで使用していたコンポーネントは、プロダクトに組み込むには適していない部分がありました。我々はPythonを使ってPoCを開発していましたが、プロダクトはTypeScriptで構築されており、言語の違いによる統合の難しさがありました。

検討した代替案

LangChainの代替

LangChainの代替として、我々は独自実装を行うことを決定しました。以下の理由からです。

自由度の向上
- 独自実装により、各コンポーネントの動作を細かく制御できるようになり、プロダクトの要件に柔軟に対応できるようになりました。
開発効率の向上
- LangChainのコードを深く理解する必要がなくなり、開発効率が向上しました。
チームのスキルセットの活用
- チームメンバーはPythonに精通しており、独自実装により、既存のスキルセットを最大限に活用できました。

もちろんLangChainを利用するメリットも多く存在します。Memory機能やRDB連携など、便利な機能が多くあります。しかし我々が顧客に提供すべき価値を満たすレベルにおいては、独自実装で十分であると判断しました。また、顧客から得られたフィードバックを素直に反映し、プロダクトの改善に注力できるという点でも独自実装は有効でした。

プロダクトとの連携方法の検討

プロダクトとの連携方法としては、以下のような案が挙げられるでしょう。

マイクロサービス化
- RAGコンポーネントを独立したマイクロサービスとして構築し、プロダクトからAPI経由で呼び出す方法。
プロダクトへの直接組み込み
- RAGコンポーネントをTypeScriptで再実装し、プロダクトに直接組み込む方法。

最終的に我々はプロダクトへの直接組み込みを選択しました。理由としては、マイクロサービス化は運用コストが増加することが挙げられます。RAGを用いた機能は未だβ版で、開発メンバーも3人しかおらず、全員がMLEであるためプラットフォーム運用には長けていません。プラットフォームチームも余剰リソースがないため、新しいサービスを運用するのは現実的ではないと判断しました。

現状のRAGプロダクトの開発プロセス

この経緯を踏まえた現在の開発プロセスを紹介します。

要件定義フェーズ

顧客からのフィードバックを受け、課題を分解し、要件を明確化

PoCフェーズ

Pythonでのプロトタイプ開発
- 必要があれば顧客への早期デモとフィードバック収集を行います。これはカスタマーサクセスだけでなく、PdMやエンジニアも同席して行います。

※課題が明確であれば、PoCフェーズをスキップして要件定義フェーズから本番開発フェーズに直接移行することもあります。

本番開発フェーズ

TypeScriptでのプロダクト組み込み
- applicationチームと密に連携し、RAGコンポーネントをプロダクトに組み込みます。

実際どうなのか？

RAG開発チームのメンバーは皆MLEであり、TypeScriptでの開発経験はほぼなかったことから、本番開発フェーズは苦労もあります。また、DDDの考え方を取り入れたプロダクトコードの構成に戸惑うこともありました。
しかし、RAG開発チームがプロダクトに組み込む部分はうまく分離されていて、触るべきところが明確なのでそこまで迷わない状態になっているので思っていたよりはスムーズに進んでいます。（applicationチームに感謝です）
また、現在はAIによるコーディング支援が実用レベルに達しているという点も大きいです。TypeScript文法やライブラリの使い方をAIに教えてもらったり、ベースコードを生成してもらったりすることで、開発効率が大幅に向上しています。現状では、課題設定から本番開発完了まで1~2週間程度でproduction環境にまで我々が実装した機能を届けられていて、速度という面ではこの選択が正解だったと感じています。

今後の展望

技術選定の振り返りと改善点

今後も技術選定のプロセスを継続的に改善し、より迅速かつ効果的な開発を目指していきたいと思っています。
今のところβ版であり、ユーザー数がそこまで多くないためにスケールをそこまで意識していない点は特に改善の余地がありそうです。将来的にはスケーラビリティも考慮した構成を検討していく必要があるでしょう。

まとめ

キャディにおけるRAG技術の選定と開発プロセスについて紹介しました。
実はRAG機能の開発が始まったのは今年の5月であり、まだ日が浅いものです。しかし、迅速な技術選定と開発プロセスの確立により、顧客に価値を提供できるプロダクトを短期間で構築できる体制を整えることができました。
ただ、まだまだ改善の余地があり、開発を加速させる必要があります。そのためにももっと多くのエンジニアの力が必要です。もし興味があれば、ぜひ一度カジュアル面談にお越しいただき、我々の取り組みについて直接お話させてください。もちろん、他にキャディが何やってるのか気になるという人もウェルカムです。

MLE/MLOps エンジニア募集
 カジュアル面談はこちらから