RAGは自作かマネージドか：OpenAI・Google Cloud・Azureの検索機能を選ぶ観点

まず「マネージド」の幅を揃える

ここでいうマネージドは、文書の取り込み・分割・ベクトル化・検索を提供側が持つ形です。ただし、任せる範囲はサービスごとに違います。公式の記述から読み取れる違いは次のとおりです。

• OpenAI：ファイルをベクトルストアに入れると自動で分割・埋め込み・索引化されます。チャンクサイズと重なりは chunking_strategy で変えられ、ファイル属性による絞り込み、スコアしきい値の調整もできます（Retrieval ガイド）。
• Google Cloud：旧称Vertex AI Searchは、現在のドキュメントではAgent Searchと説明されています。検索、生成による回答・要約、Webページに埋め込めるウィジェットなどを備えます（概要、2026年4月22日更新の表示）。
• Azure：Azure AI Searchは、LLMでクエリを分解する「agentic retrieval」と、従来のハイブリッド検索を使う「classic RAG」の二方式を示しています。agentic retrievalのクエリ計画はプレビュー扱い、GAのみで使いたい場合はclassicが向くと書かれています（RAG概要、2026年9月17日更新の表示）。

つまり、OpenAIは「ほぼ丸ごと任せる」寄り、Azureは「部品を組む」寄り、Google Cloudはその中間から社内データ連携寄りです。この位置づけは、上記の記述を踏まえた編集上の整理です。

判断表：要件別の向き不向き

下表は公式の記述をもとにした編集上の目安で、実際に構築して比べた結果ではありません。

• 少数の文書で、まず動かして反応を見たい、自作が向く：向かない（準備が重い）、マネージドが向く：向く。OpenAIのように、ファイルを入れれば索引化まで進む形が早い
• 文書ごとの権限を検索結果に反映したい、自作が向く：自社の認可基盤に合わせて作り込める、マネージドが向く：提供側のID連携に載るなら向く。載らなければ自作寄り
• 分割・順位づけを継続的に調整したい、自作が向く：向く。評価と改善を自分で回せる、マネージドが向く：Azureのように調整項目が多いものは可。完全ホスト型は項目が限られる
• データを置く地域・保持期間を厳密に管理したい、自作が向く：向く。保管先を自分で決められる、マネージドが向く：保存地域や保持の仕様が要件に合えば可。要確認
• 運用担当を置けない、自作が向く：向かない（再索引、障害、更新反映が自分の仕事）、マネージドが向く：向く
• 複数の社内システムを横断して検索したい、自作が向く：コネクタ実装が必要、マネージドが向く：Google CloudやAzureのコネクタ・インデクサが合えば向く

権限の項目だけは先に見る

権限は後から変えにくく、選定を左右しやすい項目です。公式の記述を挙げます。

• Google Cloudは、IDプロバイダで利用者を特定し、見てよい文書だけを検索結果に出す方式です。対象はCloud Storage、BigQuery、Google Drive、サードパーティのデータソースで、外部IDにはWorkforce Identity Federationが必要です。制約として、1文書あたりの閲覧者は3000まで、1ロケーションで選べるIDプロバイダは一つ、アクセス制御はデータストア作成時にしか設定できません（アクセス制御、2026年10月26日更新の表示）。後から権限を足せないため、最初の設計が重要です。
• Azure AI Searchは、文書単位のセキュリティトリミング、Azure Storage由来コンテンツへのMicrosoft Entra IDの権限メタデータの継承、プライベートエンドポイントによるネットワーク分離を挙げています。
• OpenAIの検索機能では、ファイル属性でのフィルタが公式に説明されています。属性にたとえば部署名を持たせ、利用者の所属に応じたフィルタをアプリ側で付ける設計は考えられます。ただし、利用者の特定や認可の判断は自分たちのアプリの責任になります。この点は、今回読んだページから読み取れる範囲での解釈です。

データの置き場所と保持を確認する

「学習に使われない」ことと「保持されない・指定地域に置かれる」ことは別の話です。混同しないでください。

OpenAIの公式ページでは、2023年3月1日以降にAPIへ送ったデータはモデルの学習・改善に使われないと説明されています。一方で、ベクトルストアは削除しない限り無期限に保持され、ファイルも削除するまで残ります。expires_after で自動削除を設定できます。また、Zero Data Retention（ZDR）が有効でも、/v1/vector_stores などは対象外と記載されています。保存地域は、米国、EU、豪州などから選べる旨があります（API のデータ管理）。

この内容は、社内規程が「社外サービスへの保管を禁じる」のか、「期間と地域を管理すればよい」のかで、評価がまったく変わります。個人情報や契約書を扱う場合の可否は、自社の法務・情報セキュリティ部門と契約条件で判断してください。この記事は適法性を保証するものではありません。

自作を選ぶべきサイン

自作は「性能が上がりそうだから」では選ばないほうが安全です。次のうち二つ以上当てはまるなら、検索層だけでも自前にする理由になります。

1. 既存の認可基盤（独自の権限モデル）をそのまま検索に効かせたい。
2. 保管先・保持期間・削除手順を、監査向けに自分で証明したい。
3. 検索の評価データがあり、チャンクや再ランクの改善を継続的に回せる人がいる。
4. 対象が頻繁に更新され、更新の反映タイミングを厳密に制御したい。

逆に、いずれも当てはまらず担当者が一人なら、マネージドで始めて、困った点が出てから置き換えるほうが、手戻りが小さいでしょう。

要件を言語化する入力例

選定会議の前に、次の項目をAIに渡して判断表の草稿を作らせる使い方ができます。以下は説明用の例で、実行結果ではありません。社名や文書名は架空のものに置き換えています。

次の要件で、RAGを自作とマネージド（OpenAI / Google Cloud / Azure）で
比べる表を作ってください。確実でない点は「公式で要確認」と書いてください。

- 対象：就業規則と社内手順書 約300本（PDFとWord、説明用の例）
- 更新頻度：月2回
- 閲覧権限：部署ごとに異なる。人事規程は人事部のみ
- 利用者：全社員約500人
- 運用担当：兼務1名
- 置き場所の制約：国内リージョン希望（社内規程は未確認）
- 最優先：権限の誤り防止、次に運用負担の小ささ

AIの出力は、公式の最新仕様ではなく推測を含みます。表の「要確認」の行を、次章の項目で人が埋めてください。

公式で確認する項目

契約・実装前に、各社の公式ドキュメントで次を確認します。

• 権限：自社のIDプロバイダに対応しているか。文書あたりの閲覧者数の上限、設定変更が後からできるか（Google Cloudには作成時のみとの記述あり）。
• データの置き場所：保存地域の選択肢と、自社の要件を満たすリージョンの有無。
• 保持と削除：ベクトルストアや索引の保持期間、削除手順、ZDRなど保持制御の対象外になる機能（OpenAIは対象外のエンドポイントを明記）。
• 提供状態：使いたい機能がGAかプレビューか（Azureのagentic retrievalのクエリ計画はプレビューと記載）。
• 対応形式と制限：自社の文書形式、サイズ、レート制限が収まるか。
• 料金：保存量、検索回数、LLM呼び出しの課金単位。見積りは自社の想定件数で試算してください。
• 引用と根拠表示：回答に出典箇所を示せるか。Azureのagentic retrievalは引用の追跡を機能に挙げています。
• 更新反映：文書を差し替えたとき、索引にいつ反映されるか。

最後に、少量の説明用データで同じ質問を各候補に投げ、「見てはいけない文書が出ないか」を最初に試してください。精度の比較より前に、権限の確認を済ませるのが安全です。