検索拡張生成(RAG: Retrieval-Augmented Generation)のプロトタイプを組むこと自体は非常に容易です。LangChainやLlamaIndexを用い、オープンソースの埋め込みモデルとpgvectorやPineconeなどのベクトルデータベースを組み合わせれば、週末の数時間でMarkdownフォルダから関連テキストを検索して回答を生成するシステムが完成します。しかし、エンジニアリング組織全体や事業部門が日常的に利用する本番環境レベルの社内ナレッジ検索システムを長期運用するとなると、直面する課題の性質は一変します。
エンジニアリングチームがDustを採用すべきなのは、主たる目的が社内チームの生産性向上と分散した業務知識の横断検索にある場合です。Notion、Slack、Google Drive、Confluence、GitHubに散らばる社内ナレッジを、プラットフォーム専任エンジニアを常時拘束することなく、セキュアかつ安定的に検索・活用したい組織にとって、Dustは最適な選択肢となります。
一方で、RAGパイプラインが自社の外部向け商用コアプロダクトの差別化要素である場合や、100ミリ秒未満(p99)の超低レイテンシSLAが必須な場合、独自のハイブリッド検索やマルチモーダル埋め込みモデルのチューニングが必要な場合、あるいはクラウドLLMへの接続が法規制等で一切禁止された完全閉域網(エアギャップ)環境である場合は、自社開発による内製RAGパイプラインを維持・構築すべきです。
氷山の水面下:自社製RAGにおける「Day 2」の運用課題
多くのエンジニアリングリーダーは、自社製RAGの総所有コスト(TCO: Total Cost of Ownership)を過小評価しがちです。初期構築に要する工数はライフサイクル全体の20%未満に過ぎず、残りの80%は継続的な運用・保守工数に費やされます。
1. SaaSコネクタの仕様変更とデータ取り込みの脆弱性
エンタープライズSaaSとの連携は、単発のAPI呼び出しでは完結しません。サービスごとに固有の障害パターンが存在します。
- レートリミットと指数バックオフ:SlackやNotionの大規模ワークスペースをフルクロールする際、厳しいAPIレート制限が発生します。これに対処するには、耐障害性の高い分散キューとバックオフ機構の自作が必要です。
- Webhookのライフサイクル:外部Webhookはネットワーク瞬断時にイベントを取りこぼしやすく、深い階層のフォルダ権限変更の検知漏れやOAuthトークンの失効が頻発します。
- ファイル解析と構造抽出:Googleスライド、Notionの複雑なデータベース、複数シートのExcel、スキャンされたPDFなど、多様な形式を精度高くテキスト化しチャンク分割し続けるには、パーサーライブラリの絶え間ない保守が欠かせません。
2. 権限継承とアクセス制御リスト(ACL)漏洩リスク
社内ナレッジ検索におけるセキュリティは厳格です。一般エンジニアが役員報酬の議事録を検索できてはならず、カスタマーサポートが制限付きの顧客個人情報(PII)に勝手にアクセスしてはなりません。 自社パイプラインでIdP(OktaやMicrosoft Entra ID)のグループと各SaaSのファイル単位ACLを同期させるには、専用の同期エンジンを構築する必要があります。Google DriveやNotionで権限が変更されるたびにベクトルデータベースのメタデータを即座に更新しなければならず、検索時のメタデータフィルタリングに不備があれば、重大な情報漏洩に直結します。
3. 再インデックス遅延と孤立チャンクの残骸
社内ドキュメントは日々更新されます。ナイーブなベクトルデータベース構成では、50ページの仕様書が更新された際、古いチャンクを削除し、新しいチャンクを登録し、孤立したチャンクをクリーンアップする整合性管理が必要です。同期がずれると、モデルは古い規約に基づいて回答を捏造(ハルシネーション)してしまいます。さらに、埋め込みモデルを(例: text-embedding-ada-002からtext-embedding-3-largeへ)更新する場合、サービスを停止することなく数万件以上のコーパス全体を再埋め込み・再インデックス化しなければなりません。
4. フロンティアモデルの急速な進化とルーティング
最先端のLLMは毎月のように進化します。自社製パイプラインでは、OpenAI、Anthropic Claude、Google Gemini、Mistral、DeepSeekといった各社モデルのコンテキスト長、JSON構造化出力、推論エフォート(Reasoning effort)の仕様変更に合わせて、オーケストレーションコードを常時リファクタリングし続ける必要があります。
5. マルチサーフェスなUI/UXの構築負担
エンジニアはSlack、ターミナル、GitHubで作業し、非エンジニアはブラウザやZendeskで作業します。自社製RAGを全社展開するには、Slackボット、ストリーミング対応のWebチャットUI(Server-Sent Events: SSE)、出典引用ポップアップ、ユーザー認証機構を各ツール向けに開発・保守し続けなければなりません。
アーキテクチャの比較:Dustマネージドプラットフォームの実力
Dustは、全社規模のナレッジ検索と自律型エージェントの協調動作を前提に設計された「マルチプレイヤーAIオペレーティングシステム」です。
フルマネージドなデータソースとコネクタ
Dustは、Slack、Notion、Google Drive、Confluence、GitHub、Zendesk、Intercom、Snowflake、BigQuery等へのネイティブ連携を標準提供しています。
- 自動化されたドキュメントライフサイクル:取り込まれたドキュメントには一意の
document_idが付与されます。ドキュメント登録はすべてUpsert操作として処理され、更新時には古いベクトルチャンクが自動置換されるため、孤立データが残りません。 - 前処理と最適チャンク分割:余分な空白を除去し、
max_chunk_sizeに基づきトークン単位で自動的にチャンク分割します。 - 埋め込みインフラ:デフォルトでOpenAIの
text-embedding-3-largeを使用(Enterpriseプランでは独自モデルの指定も可能)。クエリ実行時は自動でベクトル検索を行い、ドキュメント単位でチャンクを集約して関連度スコア順にソートして返します。
Spaces(空間)による二層の権限統制
各SaaSの複雑で壊れやすいファイル単位ACLを力技で同期する代わりに、Dustは**Spaces(空間)**を用いた明快なガバナンス構造を採用しています。
- Open Spaces(オープン空間):全ワークスペースメンバーがアクセス可能。技術標準ガイドラインや社内FAQに最適です。変更不可のデフォルト空間
Company Dataも含まれます。 - Restricted Spaces(制限空間):指定メンバーまたはIdP(Okta、Entra ID)からSCIM経由で同期された特定グループのみがアクセス可能。
- 二層のアクセス制御機構:
- エージェントとデータ間:エージェントは設定されたSpaces内のデータソースのみを検索可能。
- ユーザーとエージェント間:ユーザーは自分がメンバー権限を持つSpacesに基づくエージェントのみを閲覧・実行可能。権限外の機密データがエージェントの会話を通じて漏洩するリスクを防ぎます。
- 専用サービスアカウントの運用:Google DriveやNotionの接続において、Dustは
dust-admin@company.comのような専用サービスアカウントの利用を推奨しています。情シスやセキュリティ責任者が同期対象の共有ドライブやチームスペースを一元的に監査・管理できます。
マルチモデルの柔軟なルーティングと利用量ガバナンス
Dustはモデルプロバイダーを抽象化し、コードを書くことなく20種類以上の最先端モデル(OpenAI GPT-4o、Anthropic Claude 3.5 / 3.7 Sonnet、Google Gemini 1.5 / 2.0、Mistral Large、DeepSeek等)をエージェントごとに切り替えられます。管理者はグループごとにモデルアクセス階層や推論リソース上限を設定し、トークン費用の高騰を防ぐことができます。
開発者向け拡張機能:REST APIとMCP(Model Context Protocol)
Dustはブラックボックス型のノーコードツールに留まりません。
- 開発者向けAPI & OpenAPI 3.0:データソースの作成、テキスト/PDFのUpsert、エージェントの実行、SSEストリーミングをプログラムから完全制御可能です。
- MCP(Model Context Protocol)対応:リモートMCPサーバーおよびクライアントサイドMCP(プレビュー)をサポート。社内のマイクロサービスや業務データベースとエージェントをセキュアに接続できます。
- トリガーと定期実行:Cronスケジュールによる定期自動実行や、外部システムのWebhook連携によるイベント駆動型ワークフローを構築できます。
- オープンコアの透明性:DustのコアリポジトリはGitHub(
dust-tt/dust)で公開されており、内部のチャンク処理や検索ロジックをアーキテクトが直接検証できます。
徹底比較:自社製RAGパイプライン vs Dust
| 比較項目 | 自社製RAGパイプライン(LangChain / LlamaIndex / ベクトルDB) | Dustマネージドプラットフォーム |
|---|---|---|
| 主な用途 | 自社プロダクトの中核となる商用機能の開発 | 社内エンジニアリング組織および全社的なナレッジ検索 |
| 本番展開までの期間 | 複数ソースの安定稼働まで3〜6ヶ月 | 主要SaaSの連携完了まで48時間以内 |
| コネクタ保守負担 | 大;Webhook再送、API制限キュー、スキーマ変更の保守が必要 | ゼロ;50種類以上の標準統合をベンダーが完全管理 |
| アクセス権限管理(ACL) | 脆弱;クエリ時のメタデータフィルタリングに依存し漏洩リスク高 | Spacesによる二層権限分離;SCIMによるIdPグループ自動同期 |
| モデル切り替え | オーケストレーションコードの改修、Prompt再設計、SDK更新が必要 | UI上で20以上の最先端モデルを選択可能;アクセス制限設定に対応 |
| ユーザーインターフェース | Webチャット画面、Slackボット、拡張機能等をすべて自社開発 | Slack連携、Pods協調ワークスペース、Frames、ブラウザ拡張機能を標準装備 |
| 開発者拡張性 | Python / TypeScriptによる完全自由なカスタム実装 | REST API、OpenAPI、JS SDK、Webhook、MCPサーバー対応 |
| 年間の保守エンジニア工数 | 専任プラットフォームエンジニア0.5〜1.5名分 | ワークスペース管理者による設定のみ;IT部門の負担極小 |
総所有コスト(TCO)の試算
自社構築(Build)か導入(Buy)かを評価する際、エンジニアリング責任者はソフトウェア利用料と、エンジニアの人件費および機会損失を天秤にかける必要があります。
試算モデル:従業員150名(エンジニア50名)のテクノロジー企業
自社開発・内製パイプラインの費用
- 初期開発フェーズ(4ヶ月):シニアエンジニア2名がデータパイプライン、ベクトルDB、評価指標、Slack連携を構築。人件費(1人あたり年額1,500万円換算)で約1,000万円。
- 継続的な運用保守(年間):SaaS API仕様変更対応、モデル移行、データクリーンアップに専任0.75人月を消費:年間約1,125万円。
- インフラ及びLLM API費用:マネージドベクトルDB(Pinecone/Qdrant Cloud)、コンピュート、API利用料:年間約200万〜350万円。
- 初年度の総支出:約2,325万〜2,475万円(2年目以降も年間1,300万円以上の保守固定費が発生)。
Dust導入時の費用
- Businessプラン:標準ユーザー向けProシート(年払い時24ユーロ/月)、パワーユーザー向けMaxシート(年払い時120ユーロ/月)に月間クレジットが付与。
- Enterpriseプラン:ワークスペース全体でのクレジットプール、無制限のコネクタおよびMCPサーバー、SCIMプロビジョニング、SLA、データレジデンシー(EU/US)。
- 年間の総支出:シニアエンジニア1名の給与の数分の一程度に収まります。
- 機会損失の解消:シニアエンジニア2名が社内用ツールのバグ修正から解放され、直接収益を生み出すコアプロダクトの開発に集中できます。
意思決定フレームワーク:どちらを選ぶべきか
Dustを採用すべき状況:
- 社内ナレッジが主要SaaSに分散している:仕様書、議事録、設計ドキュメントがSlack、Notion、Google Drive、Confluence、GitHubに散在している。
- 非エンジニア部門にエージェントを自作させたい:PM、カスタマーサポート、事業開発メンバーがエンジニアに依頼することなく、自部門専用のRAGエージェントを自然言語やMCPで構築・運用したい。
- エンジニアのリソースが極めて逼迫している:プロダクトのリリース期限が迫っており、外部APIの仕様追従や再インデックス作業に工数を割けない。
- エンタープライズセキュリティ要件を即座に満たす必要がある:SOC 2、GDPR、SAML SSO、監査ログへの適合がすぐに求められている。
自社製RAGパイプラインを維持・開発すべき状況:
- RAG自体が自社の商用プロダクトの中核である:法務向け文書解析SaaS、医療画像検索システム、独自コードベース解析サービスなど、検索アルゴリズムそのものが企業の知的財産である場合。
- 極端な低レイテンシ(<100ms)要件がある:インメモリのカスタムベクトル検索や、トランザクションDBに深く統合された検索キャッシュが必要な場合。
- 完全閉域網(エアギャップ)環境である:防衛や厳格な金融規制により、外部公衆回線や商用クラウドLLMへの接続が一切許されず、vLLMやOllamaを用いたオンプレミス環境が必須な場合。
- 数千万件規模の公開データで権限モデルが極めて単純である:5,000万件のEC商品カタログ検索など、シート課金のSaaSモデルが適さず、ドキュメントごとのアクセス制限が不要な場合。
現実的なベストプラクティス:ハイブリッド構成
先進的なテック企業では、以下のようなハイブリッド構成が定着しつつあります。
- 全社ナレッジ検索はDustに委譲:社内の開発ドキュメント、オンボーディング、サポートナレッジ、仕様書の検索はDustで即座に一元化。
- 社内基幹システムはMCP経由でDustと連携:エンジニアはRAG基盤を一から構築する代わりに、社内マイクロサービスや専有データベースを操作するための軽量なMCPサーバーを開発し、Dustエージェントのツールとして登録。
差別化に繋がらないSaaSコネクタの運用保守をマネージドプラットフォームに任せることで、エンジニアリングチームは最も事業価値の高いプロダクト開発に全精力を注ぐことができます。