BedrockかVertex AIか、モデル料金より既存クラウドが効く

企業の生成AI基盤を選ぶなら、主要データと権限・運用基盤がAWSにある企業はAmazon Bedrock、Google Cloudにある企業はVertex AIを第一候補にするのが実務的だ。モデルのトークン単価だけで別クラウドを選ぶと、データの接続、権限の再設計、運用体制の追加にかかる費用を見落としやすい。

東京リージョンを前提にすると、この判断には条件が付く。必要なモデルと機能が東京から使えるかに加え、推論の処理先、社内データへの接続方法、独自モデルの学習範囲まで確かめたい。既存クラウドを起点にしつつ、業務上欠かせない機能がある場合に移行負担と比較するのが妥当だ。

データの所在がRAGの移行範囲を決める

回答の根拠となる社内文書がAmazon S3にあり、業務アプリもAWSで動くなら、BedrockのKnowledge Basesを使う構成が候補になる。分析に使うデータがBigQueryに集まっているなら、Vertex AIをGoogle Cloud上のデータ基盤と接続する構成が出発点になる。いずれもモデルへの入力を作る前に、元データをどこで管理しているかが効く。

別クラウドへデータを複製する場合、原本の転送だけで作業は終わらない。文書の取り込み、検索用索引の作成、更新と削除の反映、閲覧権限の引き継ぎが必要になる。原本を移さずクラウド間で参照する場合も、認証方法、通信経路、転送量、応答時間、障害時の切り分けが運用項目に加わる。

RAGでは、検索した文書をモデルへの入力に添えて回答を作る。そのため生成モデルだけを切り替えても、検索先や文書の更新処理は自動的には移らない。特に部門ごとに閲覧範囲が違う文書では、検索結果を返す前に権限を判定するのか、回答を作る段階で制限するのかによって設計が変わる。既存の検索基盤を残して生成部分だけを変更できれば、全面移行より対象を狭められる。

ID管理と閉域接続には別々の設計が要る

AWS上のアプリからBedrockを呼ぶ構成では、既存のAWS IAMロールや監査の運用を起点にできる。Google Cloud上のアプリからVertex AIを呼ぶ構成でも、既存のIAMとプロジェクト管理を起点にできる。ただし、片方のクラウドで定義した権限をもう片方へそのまま移せるわけではない。

権限は利用者のモデル呼び出しだけに限らない。RAGの取り込み処理には文書を読む権限が要り、検索処理には索引へのアクセス権が要る。開発環境と本番環境を分ける企業なら、各環境の実行主体、資格情報、監査ログの保存先も設計対象となる。既存クラウドを使う利点は、こうした境界を現在の統制手順につなげやすいことにある。

閉域接続も、アプリから推論APIへの経路と、生成AIの処理から社内データへの経路を分けて考える必要がある。前者を閉じても、検索先や外部の業務システムへ別の経路を開けば、全体の通信設計は変わる。クラウドをまたぐ構成では、ネットワーク費用だけでなく、接続設定と障害対応を両側で維持する負担も見積もりに入る。

東京から呼べても、処理先が東京とは限らない

東京にAPIの呼び出し元を置くことと、推論処理が東京内で完結することは別の条件だ。Bedrockの推論プロファイルの説明では、呼び出し元リージョンからプロファイルが定める宛先リージョンへリクエストを送る仕組みと、宛先の確認方法が示されている。東京から利用できるモデルでも、選んだ推論方式の宛先を確認する必要がある。

Google Cloudのモデル別の提供地域とエンドポイントの案内も、地域エンドポイントの存在だけではデータ所在地や域内での機械学習処理を保証しないと明記している。候補モデルごとに東京で使えるエンドポイントと機能を確かめ、保存場所と推論処理の場所を分けて判断したい。

「データを日本に置く」という要件も、文書の原本だけを指すのか、検索索引、評価用データ、推論時の入力まで含むのかで選べる構成が変わる。地域条件が厳しい場合は、モデル名だけでなく、RAG、調整、評価に使う機能それぞれの提供地域を見る必要がある。東京で使えない機能を前提にした料金比較は、採用判断につながらない。

モデル選択とRAGは、周辺機能まで比べる

BedrockはAmazonと複数の第三者提供者の基盤モデルを扱い、AWS上でモデルを使い分けたい企業の選択肢になる。Vertex AIはGeminiに加え、Model Gardenを通じて第三者やオープンモデルを扱う。どちらのカタログが大きいかという総数だけでは、東京で必要なモデルを希望する方式で使えるかは分からない。

同じ業務で候補を比べるなら、入力形式、回答の品質、応答時間、処理量に応じた料金をそろえる必要がある。モデル名が両基盤に載っていても、検索、権限、監視、モデル変更時の評価手順まで共通になるわけではない。モデルを後から替えられる設計にするには、プロンプトだけでなく、検索結果の渡し方と評価に使う業務データも管理することになる。

RAGの機能比較では、検索した文書の出典を回答からたどれるか、文書の更新が検索結果へいつ反映されるかも重要だ。たとえば更新頻度の高い社内規程を使う場合、モデルの回答能力が高くても、古い索引を参照していれば期待する答えは得られない。閲覧権限を守りながら原文へ戻れる構成かどうかが、実運用での差になる。

独自モデルの学習は比較する製品の範囲をそろえる

Bedrockには対応モデルの調整や評価の機能がある。独自モデルの学習から実験管理、配備までAWSで担う場合は、Amazon SageMaker AIを含めた構成が比較対象になる。一方、Vertex AIは生成AIの利用に加えて、モデルの学習、配備、評価を扱う機械学習基盤でもある。Bedrock単体とVertex AI全体を同じ範囲の製品として比べると、必要な作業を見誤る。

すでに学習パイプラインを運用している企業では、推論APIの変更だけで移行は完了しない。学習データの保管場所、実験結果の管理、配備の承認、監視項目をどう引き継ぐかまで費用に含める必要がある。反対に、既存モデルを使った文書検索と回答生成が目的なら、独自モデルの学習機能を選定理由の中心に置く必要は薄い。

評価では同じ業務データと判定基準を使うことが重要だ。回答の正確さに加え、検索漏れ、権限外の文書の扱い、応答時間、失敗時の再試行も品質に関わる。モデルを変更した際に同じ条件で評価できれば、単価の差が業務上の利益につながるかを判断しやすい。

モデル数と料金の別表

2026年8月2日公開の独立比較は、トークン単価だけでなく、既存のデータ、ID管理、運用基盤との適合が選択を左右すると整理している。モデルの掲載数や料金は変わるため、ここでは固定した総数や異なるモデル同士の単価を優劣の指標にしない。

• Amazon Bedrock：東京で採用できるモデル数は、直接推論とリージョン間推論を分けて数える。Bedrockの公式料金表はモデルや提供者、処理方式ごとに料金を分け、Knowledge Basesなどの周辺機能の料金も示している。
• Vertex AI：Gemini、第三者モデル、オープンモデルを同じ利用方式として数えず、東京で使う配備方式に合う候補を数える。Google Cloudの生成AI料金表はモデル、入力と出力、処理方式に応じた料金を示している。

料金表の単価だけでは、東京で動かす業務の支払額は決まらない。候補モデルを絞って同じ入力・出力量と運用条件で推論費を計算し、データ移動、検索基盤、監査、学習・評価の維持費を加える。その合計と必要な機能を見れば、既存クラウドから移る価値があるかを判断できる。

関連記事：

• クラウドサインかGMOサインか、月額差より署名方式で選ぶ
• FUNDINNOかイークラウドか、手数料より株主の出口が違う
• SlackかTeamsか、30人の年額差より既存基盤が効く