Google Cloud

Vertex AI RAG Engineの使い方:コーパス作成・チャンク設定・料金

AWSを利用したインフラ構築

Vertex AI RAG Engineは、社内文書を取り込んでチャンク分割と埋め込みを行い、Geminiの回答に検索結果を差し込むまでを1つのAPIで扱えるGoogle Cloudのマネージドサービスです。2026年4月にRAG Engineへ改称され、Python SDKもエージェント向けの新パッケージへ移りました。本記事では、新SDKのclient.ragでコーパスを作ってCloud StorageのPDFを取り込み、Geminiから検索させるまでのコードを示します。あわせてチャンクとベクトルデータベースの決め方、明示しないと選ばれるSpannerモードの課金、東京リージョンの制約を2026年10月時点の公式ドキュメントで整理します。

まとめ:Vertex AI RAG EngineでRAGを組むときの要点と既定値

コードは「コーパス作成→ファイル取り込み→検索→Geminiで生成」の4段です。つまずきやすいのはコードより既定値のほうです。

  • 新SDKではagentplatform.Clientのclient.ragから呼びます。旧来のfrom vertexai import ragの記事とは書き方が違います。
  • チャンクの既定値は1,024トークン・重なり256トークンです。公式クイックスタートのサンプルは512・100を指定しています。
  • 埋め込みモデルはコーパス作成後に変えられません。日本語の文書なら作成時に多言語モデルを指定します。
  • デプロイモードを明示しないと、Spannerモードのベーシック階層(100処理ユニット)になります。既定のRagManagedDbを使うコーパスがある間は、us-central1の単価で月90ドル前後の固定費がかかります。
  • 東京リージョンは2026年10月時点でプレビューです。追加料金のかからないサーバーレスモードはus-central1でしか使えません。

Vertex AI RAG Engineの構成とAgent Searchとの位置づけ

RAG Engineは、検索の部品を自分で選べる中間層の製品です。

2026年4月の改称と新SDKのclient.ragで変わった呼び出し方

Gemini Enterprise Agent Platformのリリースノートにある2026年4月22日の名称対応表で、Vertex AI RAG EngineはRAG Engineになりました。プラットフォーム全体の改称と構成はVertex AIの機能・料金とSageMaker・Azure MLとの違いで解説しています。

コードの書き方も変わりました。RAG Engineのクイックスタートは、agentplatform.Clientを作り、client.rag.create_corpusやclient.rag.import_filesを呼ぶ形に書き換わっています。ところがデプロイモードや再ランキングのページは、2026年10月17日時点でも旧来のvertexai.init()とrag.create_corpusのままです。1つのプロジェクトで両方を混ぜると、初期化の仕方が違うため設定が片方にしか効きません。新規に書くなら新SDKにそろえてください。

取り込みから生成までの6工程と取り込めるファイル形式ごとの容量上限

RAG Engineの概要ページは、処理を「データの取り込み・変換(チャンク分割)・埋め込み・インデックス登録・取得・生成」の6工程で説明しています。インデックスはコーパスと呼ばれる単位で作ります。データ取り込みのページが挙げる取り込み元は、ローカルファイル、Cloud Storage、Googleドライブのほか、Slack・Jira・SharePointです。

既定のパーサーが扱えるファイルの上限は、対応ドキュメントの一覧によるとPDFとWord(DOCX)が50MB、HTML・Markdown・PowerPoint(PPTX)・テキスト・JSONが10MBです。スキャンした画像だけのPDFや複雑な表は、有料のLLMパーサーかDocument AIのレイアウトパーサーに回します。マネージドの検索アプリ側で済ませる方法はVertex AI Search(現Agent Search)の使い方で扱っており、本記事はチャンクや埋め込みを自分で決める側の手順です。

RAG Engineでコーパスを作りGeminiから検索するPython実装

クイックスタートのコードを、日本語の文書を東京で扱う前提に置き換えて示します。

IAMロール1つとSDK2本・同じプロジェクトのバケットの事前準備

必要なIAMロールは、Agent Platformユーザー(roles/aiplatform.user)の1つです。SDKは、コーパス操作用のgoogle-cloud-agentplatformと、Geminiの呼び出し用のgoogle-genaiの2本を入れます。

# 認証とSDKの準備(ステージング用ではなく、取り込む文書を置くバケット)
gcloud config set project your-project-id
gcloud auth application-default login
gcloud storage buckets create gs://your-rag-docs --location=asia-northeast1
gcloud storage cp ./manuals/*.pdf gs://your-rag-docs/manuals/

pip install --upgrade google-cloud-agentplatform google-genai

バケットの作成先は、RAG Engineを呼ぶのと同じプロジェクトです。google-cloud-agentplatformの2.5.0(2026年10月14日公開)のソースを読むと、import_filesはバケットの所有プロジェクトを確かめ、クライアントのプロジェクトと違えばValueErrorで止まります。部署ごとにプロジェクトを分けている会社では、文書の置き場所から決め直すことになります。

create_corpusとimport_filesで多言語埋め込みのコーパスを作成

import agentplatform
from agentplatform import types
from google.genai import types as genai_types

PROJECT_ID = "your-project-id"
LOCATION = "asia-northeast1"  # 東京は2026年10月時点でプレビュー
client = agentplatform.Client(project=PROJECT_ID, location=LOCATION)

# 埋め込みモデルは作成後に変えられないので、日本語向けに多言語モデルを指定する
embedding = types.RagEmbeddingModelConfig(
    vertex_prediction_endpoint=types.RagEmbeddingModelConfigVertexPredictionEndpoint(
        endpoint="publishers/google/models/text-multilingual-embedding-002"
    ),
)
corpus = client.rag.create_corpus(
    rag_corpus=types.RagCorpus(
        display_name="社内規程",
        rag_vector_db_config=types.RagVectorDbConfig(rag_embedding_model_config=embedding),
    )
)

# Cloud StorageのPDFを取り込む(完了まで待ってから戻る)
client.rag.import_files(
    name=corpus.name,
    import_config=types.ImportRagFilesConfig(
        gcs_source=genai_types.GcsSource(uris=["gs://your-rag-docs/manuals/"]),
        rag_file_transformation_config=types.RagFileTransformationConfig(
            rag_file_chunking_config=types.RagFileChunkingConfig(chunk_size=512, chunk_overlap=100)
        ),
        max_embedding_requests_per_min=1000,
    ),
)
print(corpus.name)  # projects/.../locations/asia-northeast1/ragCorpora/数字のID

create_corpusとimport_filesは、どちらも長時間オペレーションの完了を待ってから戻ります。埋め込みモデルの選択ページによると、既定はtext-embedding-005で、多言語向けにはtext-multilingual-embedding-002やmultilingual-e5が並んでいます。埋め込みモデルとコーパスの関連付けはコーパスの存続期間中固定です。公開モデルが廃止されると、コーパスを作り直して再インポートする必要があると書かれています。

retrieve_contextsで検索結果を確かめてからGeminiに渡す呼び出し

いきなりGeminiに投げず、先に検索だけを実行して、どのチャンクが返るかを確かめます。回答がおかしいとき、検索と生成のどちらが原因かを切り分けられるからです。

from google import genai

store = genai_types.VertexRagStore(
    rag_resources=[genai_types.VertexRagStoreRagResource(rag_corpus=corpus.name)],
    rag_retrieval_config=genai_types.RagRetrievalConfig(
        top_k=5,
        filter=genai_types.RagRetrievalConfigFilter(vector_distance_threshold=0.5),
    ),
)

# 1. 検索だけを実行して、返るチャンクと出典を確認する
found = client.rag.retrieve_contexts(
    vertex_rag_store=store,
    query=types.RagQuery(text="出張の日当はいくらですか"),
)
print(found)

# 2. 同じコーパスを検索ツールとしてGeminiに渡す
genai_client = genai.Client(enterprise=True, project=PROJECT_ID, location=LOCATION)
answer = genai_client.models.generate_content(
    model="gemini-3.5-flash",
    contents="出張の日当はいくらですか。根拠の規程名も示してください。",
    config=genai_types.GenerateContentConfig(
        tools=[genai_types.Tool(retrieval=genai_types.Retrieval(vertex_rag_store=store))]
    ),
)
print(answer.text)

genai.Clientのenterprise=Trueは、Gemini Developer APIではなくAgent Platformのエンドポイントを使う指定です。google-genai2.31.0のdocstringでは、旧来のvertexai=Trueはこの引数の旧名と説明されています。モデルの窓口と料金の差はVertex AIとGemini APIの違いで比べています。

文書に合わせたチャンクサイズ・ベクトルDB・再ランキングの設定項目

検索の品質を左右する設定は、チャンク・ベクトルデータベース・再ランキングの3つにまとまります。

既定1,024トークンと重なり256トークンのチャンク設定の見直し方

RAG変換の調整ページによれば、chunk_sizeを省くと1,024トークン、chunk_overlapを省くと256トークンになります。ページは、チャンクが小さいほど埋め込みの精度は上がり、大きいほど内容が一般的になって細部が落ちると説明しています。

規程集やFAQのように1項目が短い文書は、クイックスタートと同じ512・100程度が開始時の設定候補です。手順書や仕様書のように前後の文脈がないと意味を取れない文書は、既定の1,024のままのほうが答えが崩れにくい設定です。どちらが合うかは、評価用の質問を20〜30問用意し、retrieve_contextsで正解の箇所が上位に返るかで比べて決めます。日本語でのトークン数と文字数の関係はチャンクとトークンの違いとサイズ設計で実測しています。

RagManagedDbなど5種類のベクトルDBを既存構成と文書量で選ぶ

ベクトルDB 検索の型 リリース段階 向く場面
RagManagedDb(既定) KNN(既定)とANN 一般提供 新規構築・試作
Vector Search ANN 一般提供 大量文書・Google Cloudで統一
Vertex AI Feature Store ANN プレビュー BigQueryに正本がある
Weaviate ANN+ハイブリッド プレビュー Weaviateを既に運用している
Pinecone ANN 一般提供 Pineconeを既に運用している

表はベクトルデータベースの選択肢から要約しました。既存のDBが無い場合の開始時の選択肢はRagManagedDbです。RagManagedDbの解説ページは、KNNを1万ファイル未満のコーパス向けとし、それを超える場合の推奨はANNです。ANNではtree_depth(既定2)とleaf_count(既定500・推奨は10×√ファイル数)を決め、クエリの前にrebuild_ann_indexでインデックスを一度作り直します。製品ごとの料金体系はベクトルデータベースの価格とRAG用途の選び方にまとめています。

Ranking APIとLLM再ランキングの遅延100ミリ秒と1〜2秒の差

上位に関係の薄いチャンクが混ざるときは、取得後の再ランキングを足します。再ランキングのページでは、Agent Platformのランキング APIは遅延100ミリ秒未満でリクエストごとの課金、LLM再ランキングは1〜2秒でGeminiのトークン料金です。ランキングAPIを使うにはDiscovery Engine APIの有効化が要ります。チャット画面で待たせたくない用途ならランキングAPIを選び、バッチで回答を作る用途に限ってLLM再ランキングを検討します。

デプロイモードの既定値とSpanner課金で月額が決まる仕組み

RAG Engineの費用で読み落とされやすいのが、プロジェクト単位のデプロイモードです。

明示しないとSpannerモードのベーシック階層になる既定値の注意

デプロイモードのページによると、RAG EngineにはサーバーレスモードとSpannerモードの2つがあり、選ばなければSpannerモードが割り当てられます。Spannerモードの管理ページでは、既定のベーシック階層は100処理ユニット(0.1ノード)の固定構成、スケーリング階層は1〜10ノードの自動スケーリングです。SDKの型定義でも、Spannerモードのベーシック階層が既定と書かれています。

課金の内訳はRAG Engineの課金ページにあります。既定パーサーと固定長のチャンク分割は無料で、RagManagedDbのためにSpanner Enterpriseエディションのインスタンスが用意され、その代金の請求先は利用するプロジェクトです。埋め込みモデル、LLMパーサー、再ランキングは各サービスの料金で別に請求されます。

ベーシック100処理ユニットの月額試算と未プロビジョニングでの停止

Spannerの料金ページでは、us-central1のリージョン構成でEnterpriseエディションが1ノード時間1.23ドルです。1ノード未満は処理ユニット単位で課金されるので、ベーシック階層の0.1ノードを1か月(730時間)動かすと、1.23×0.1×730で約90ドルです。ストレージ料は別で、東京の単価は料金ページで地域を切り替えて確かめてください。問い合わせが1件も来ない月でも、この固定費は止まりません。

試作を終えたら、現在のモードを読み、使わないなら未プロビジョニングにします。

# 現在のデプロイモードと階層を確認する
print(client.rag.get_config())

# Spannerモードを未プロビジョニングにして課金を止める(中のデータは復元できない)
client.rag.update_config(
    updated_config=types.RagEngineConfig(
        name=f"projects/{PROJECT_ID}/locations/{LOCATION}/ragEngineConfig",
        rag_managed_db_config=types.RagManagedDbConfig(
            spanner=types.RagManagedDbConfigSpanner(
                unprovisioned=types.RagManagedDbConfigUnprovisioned()
            )
        ),
    )
)

未プロビジョニングにすると、Spannerモードのコーパスとファイルはすべて消えます。消す前に、取り込み元のバケットとチャンク設定さえ残っていれば同じコーパスを作り直せる状態にしておきます。

東京リージョンはプレビューでサーバーレスはus-central1のみの制約

概要ページのリージョン表で、asia-northeast1(東京)はv1とv1beta1のどちらもプレビューです。us-central1とus-east4は一般提供ですが、新規プロジェクトは許可リストへの登録が必要とされ、別のリージョンを試すよう案内されています。クイックスタートのサンプルはus-east4のままなので、新しいプロジェクトで写すと最初の呼び出しで止まることがあります。

追加料金のかからないサーバーレスモードはプレビューで、us-central1でしか使えません。CMEKにも対応していません。どのページにも、データ所在地のセキュリティ管理には非対応と書かれています。文書を国内に置く契約上の義務がある案件では、プレビューの東京で本番を組むか、別の製品を選ぶかを最初に決める必要があります。

RAG Engineを採用する条件とAgent SearchやBedrockを選ぶ場面

ここまでの仕様と課金を前提に、使う場面と使わない場面を分けます。

チャンクと埋め込みを自分で評価できる体制がある場合の採用条件

採用してよいのは、次の3条件がそろうときです。業務データとGeminiの利用がGoogle Cloudにまとまっている。チャンクサイズや埋め込みモデルを、評価用の質問で比べて決められる開発者がいる。月90ドル前後の固定費を、試作から本番まで払い続ける前提で予算を組める。この場合、ベクトルDBと検索APIを自前で組むより、取り込みからGeminiへの差し込みまでをclient.ragに任せたほうが本番までが短くなります。Weaviateなど既存のベクトルDBをそのまま後ろに置ける点も、作り直しを避けたい案件では効きます。

社内文書の整理とチャンク設計から、評価の仕組み、既存システムとの権限連携までを一緒に詰めたい場合は、一創のRAG構築支援で、RAG EngineとAgent Searchのどちらに載せるかから検討できます。

評価の人手が無い・データがAWSにある場合に採用を見送る判断基準

見送るのは、検索の中身を調整する人手が無い案件です。チャンクや埋め込みを選べることは、選んで比べる作業が発生することでもあります。Webサイトや社内文書をそのまま検索させたいだけなら、クエリ単位の課金で精度の調整をGoogleに任せられるAgent Searchのほうが筋がよい選択です。Agent Searchを検索バックエンドにする構成もあるため、まずAgent Searchで始め、後からRAG Engine経由でGeminiに渡す移行も取れます。

業務データとIAMがAWSに集まっているなら、RAG Engineのために文書をGoogle Cloudへ複製する理由は薄くなります。その場合は、検索と生成をAWSの中で完結させられるAmazon BedrockのKnowledge BasesでRAGを実装する手順を先に検討してください。

Vertex AI RAG Engineの導入前によくある質問

RAG Engineを使い始めるときに出やすい疑問に、公式ドキュメントの記載をもとに答えます。

Vertex AI RAG EngineとRAG Engineは別の製品ですか?

同じ製品です。2026年4月22日のリリースノートで、Vertex AI RAG EngineはRAG Engineへ改称されました。REST APIのリソース名はragCorporaのままで、作成済みのコーパスはそのまま使えます。変わったのはPython SDKの入口で、新しいコードはgoogle-cloud-agentplatformのclient.ragから呼びます。検索記事で見つかるfrom vertexai import ragの書き方は改称前のものです。

RAG Engineは無料で使えますか?

RAG Engine自体の利用料はありませんが、無料にはなりません。既定のSpannerモードでは、ベーシック階層のSpannerインスタンス代がus-central1の単価で月90ドル前後かかります。そのほか、取り込み時の埋め込み、Geminiのトークン、LLMパーサーや再ランキングを使えばそれぞれの料金が加わります。追加料金のかからないサーバーレスモードはus-central1限定のプレビューです。

日本語の社内文書でも検索できますか?

できます。ただし既定の埋め込みモデルtext-embedding-005のまま作らず、作成時にtext-multilingual-embedding-002などの多言語モデルを指定して、評価用の質問で比べてください。埋め込みモデルはコーパスを作った後に変えられません。比べた結果で変えたくなったときは、コーパスを作り直して文書を取り込み直すことになります。

Googleドライブのファイルを取り込めますか?

取り込めます。取り込み設定のgoogle_drive_sourceにファイルやフォルダを指定します。GoogleドキュメントやスライドはWorkspaceからのエクスポートで10MBまでです。Cloud Storageから取り込む場合と違い、事前にドライブのフォルダかファイルを、Agent PlatformのRAGデータサービスエージェントのアカウントへ閲覧者として共有しておく必要があります。更新頻度の高い文書は、取り込み直す手順を決めてから載せてください。

社員ごとに検索できる文書を分けられますか?

コーパスを部署や権限ごとに分け、アプリ側で利用者に応じて渡すコーパスを切り替えるのが基本です。検索時には、コーパス内の特定ファイルだけを対象にするrag_file_idsも指定できます。誰にどのコーパスを見せるかは、社内の認証基盤から利用者の所属を取り、アプリ側で判定して渡す設計にします。

関連記事

お気に入りに入れた記事の一覧

この記事は以下の記事からリンクされています

資料請求

今日のトレンド記事 直近 24 時間で、いつもより多く読まれている記事

  1. 2026.10.16 テックブログ バーガーキング不正アクセスで約1,118万件の情報漏洩|対象確認・案内メールの真偽と運営側のログ点検
  2. 2026.10.15 テックブログ 銀のさら不正アクセス:最大650万件の対象確認と窓口、パスワード変更の手順
  3. 2026.10.15 テックブログ リゾートトラスト不正アクセス:会員2.6万件・カハラ横浜3.6万件の対象確認と窓口
  4. 2025.12.02 テックブログ クーパン問題とは?3,755万人流出と過去最大6,246億ウォンの課徴金
  5. 2026.10.16 テックブログ ソースネクスト不正アクセスで最大2,252万件流出|ログインできない理由・パスワード再設定と会員APIの点検

RELATED POSTS 関連記事

目次