分析基盤をBigQueryに寄せたい一方で、ログや実績データはAmazon S3に貯まっている。この状態で選択肢に挙がるのがBigQuery Omniです。データをGoogle Cloudへコピーせず、置かれたクラウドの側でクエリを走らせ、結果だけを受け取る構成が組めます。マルチクラウド前提で製品ごと選び直す場合の判断軸はBigQueryとSnowflakeを課金モデルから比較した記事にまとめました。ただし対応リージョンと非対応機能の縛りが強く、国内案件では前提が崩れる場面もある設計です。2026年8月17日時点の公式ドキュメントで、使える範囲と代替手段、AWS側で完結させる判断までを整理します。
まとめ：対応リージョンで採否がほぼ決まり、国内S3なら別の手段になる
先に結論を置きます。BigQuery Omniの採否は、対象データがどのリージョンにあるかでほぼ決まります。2026年8月17日時点で対応するのはAWSの6リージョンとAzureの1リージョンで、東京と大阪は含まれません。国内で運用しているS3バケットが対象なら、Omniという選択肢はその時点で消えます。
消えたあとに残るのは3つです。BigQueryのクロスクラウド接続でデータを取り込んでからクエリする構成、Data Transfer Serviceなどで定期コピーしてBigQueryに持つ構成、そしてAmazon AthenaやRedshiftでAWS側に分析を寄せる構成。どれを採るかは、データ量とエグレス費用、そしてBigQuery側の機能をどこまで使いたいかで分かれます。
もう1点。Omniが使えるリージョンであっても、BigQuery MLやDML・DDLは動きません。Omniは「BigQueryのすべてがそのまま他クラウドで動く仕組み」ではなく、参照系に絞った出先の実行環境だと捉えるほうが設計を誤りません。
BigQuery Omniの仕組みと対応クラウド・リージョンのペア
まず何が動いているのかを押さえます。ここを曖昧にしたまま費用を見積もると、転送量の見立てが大きくずれます。
BigQuery Omniのクエリエンジンを他クラウドで動かし結果だけを返す構成
BigQueryは元々、ストレージとコンピュートを分離したアーキテクチャを持ちます。公式ドキュメントは、Omniがこのアーキテクチャを拡張して「BigQueryのクエリエンジンを他のクラウドで実行する」ものだと説明しています。処理はデータが置かれているクラウド側で行われ、Google Cloudへ返るのはクエリ結果だけです。
元データがクラウド間を移動しない点が、この構成の中核です。テラバイト級のログをS3に置いたまま集計し、返ってくるのは数万行の集計結果という形になれば、転送量は桁で変わります。仕組みの前提として、サーバーレスDWHとしてのBigQuery本体の構造を先に押さえたい場合は、BigQueryのストレージとコンピュートの分離と採用判断を読んでおくと以降が読みやすくなります。
対応リージョン一覧とGoogle Cloud側のペアを設計前に確認する
2026年8月17日時点で公式ドキュメントが挙げているOmniリージョンは、AWSが6つ、Azureが1つでした。それぞれGoogle Cloud側のリージョンと組で扱われます。
| Omniリージョン | 所在 | ペアとなるGoogle Cloudリージョン |
|---|---|---|
| aws-us-east-1 | 北バージニア | us-east4 |
| aws-us-west-2 | オレゴン | us-west1 |
| aws-eu-west-1 | アイルランド | europe-west1 |
| aws-eu-central-1 | フランクフルト | europe-west3 |
| aws-ap-northeast-2 | ソウル | asia-northeast3 |
| aws-ap-southeast-2 | シドニー | australia-southeast1 |
| azure-eastus2 | 米国東部2 | （Azure側は1リージョンのみ） |
アジア太平洋で使えるのはソウルとシドニーだけで、東京（ap-northeast-1）と大阪（ap-northeast-3）は入っていません。国内のS3バケットを直接クエリする用途では、この一覧が最初の関門になります。リージョンは追加されうるため、設計時点で公式ドキュメントの最新一覧を引き直してください。
接続とBigLake外部テーブルという3ステップで安全に構成する
実装の骨格は短いものでした。AWSの場合、接続を作ってIAMロールで信頼関係を結び、S3のデータを指すBigLake外部テーブルを作り、そのテーブルへクエリを投げる。この3つです。
- BigQuery側でAmazon S3への接続を作成し、返された識別子をAWS IAMロールの信頼ポリシーへ登録する
- Omniリージョンにデータセットを作り、S3のURIを指すBigLake外部テーブルを定義する
- 作成したテーブルへ通常のGoogleSQLでクエリを投げ、結果をコンソールやAPIで受け取る
認証にアクセスキーを配布せず、IAMロールの信頼で結ぶ形になっている点は運用上ありがたい部分です。メタデータのキャッシュを更新するジョブが別途走るため、公式ドキュメントはBACKGROUNDの予約を併用する構成を案内しています。
BigQuery Omniでできないことの整理：非対応機能と結果サイズの上限条件
採否の判断で効くのは、できることよりできないことのほうでした。以下は公式ドキュメントの制限事項に記載されている内容です。
BigQuery MLやDML・DDL・Storage APIが使えない
Omniリージョンでは、BigQuery MLとDML、そしてCREATE TABLEなどのDDLステートメントがサポートされません。JavaScriptのユーザー定義関数も使えず、BigQuery Storage APIも利用できません。Blob Storage側ではマテリアライズドビューが非対応です。
- SQLだけで予測モデルを作る流れをOmniリージョンで完結させることはできない
- 集計結果をその場でテーブル化して残す運用も、通常のDDLでは組めない
- Storage Read APIを前提としたデータ処理基盤やBIの直結構成は組み替えが要る
結果を残したい場合は、後述するクロスクラウド転送でBigQuery側のリージョンへ書き出す形になります。機械学習まで含めたい場合は、そもそもデータをBigQueryへ持ってくる構成が前提です。SQLだけでモデルを学習させる仕組み自体はBigQuery MLで扱えるモデル種別とVertex AIとの分担にまとめてあります。
ORDER BYで256MB、CTASで60GiBという結果サイズの壁
見落としやすいのが結果サイズの上限です。公式ドキュメントは、ORDER BY句を含むクエリで結果が256MBを超えると失敗すると記載しています。クロスクラウド転送のCREATE TABLE AS SELECTでは、結果が60GiBを超えるとクエリが失敗します。
集計してから返す使い方なら当たることはまずありません。当たるのは、明細をそのまま並べ替えて全件返そうとする使い方です。設計段階で「Omni越しに返すのは集計結果まで」と線を引いておけば、この上限は制約として意識せずに済みます。
Enterprise editionという前提条件と料金モデルの制約
Editionの縛りもあります。公式ドキュメントによれば、StandardエディションとEnterprise Plusエディションの予約はOmniリージョンでの作業に対応せず、Omniリージョンが対応するのはEnterpriseエディションの予約とオンデマンド課金です。すでにStandardで回している組織では、この一点で構成の見直しが要ります。自社がどちらの課金で走っているかは、オンデマンドとEditionsの分岐点とストレージ課金の内訳で確認してから判断してください。
BigQuery Omniの費用の考え方：クエリ課金・エグレス・転送という三層構造
Omniの費用は1本ではありません。三層で積み上がると考えると見積もりがぶれにくくなります。
BigQuery Omniのクエリ課金とAWS側エグレスが別勘定になる料金構造
公式ドキュメントは、Omniについて「クエリの実行に対してのみ課金され、BigQueryの料金モデルが適用される」と述べたうえで、AWSのエグレス料金が別途発生すると明記しています。つまりGoogle Cloudの請求書とAWSの請求書の両方が動きます。
単価はリージョンごとに設定され、公式の料金ページで更新されます。金額をここに書き写しても時点で古くなるため、見積もりの前に必ず公式ページの現行値を引いてください。構造として押さえるのは、走査バイト数に対する課金と、クラウドをまたいで出ていくバイト数に対する課金が別に立つという点です。
クロスクラウド転送とマテリアライズドビューレプリカの使い分け
結果や元データをBigQuery側へ持ってくる手段は用意されています。LOAD DATAステートメントによる転送と、CREATE TABLE AS SELECTによる絞り込み転送、そしてマテリアライズドビューレプリカによる継続的な複製です。
転送には制約が付きます。転送元と転送先が同じリージョンペアに属する必要があり、たとえばUSのOmniリージョンからはUSマルチリージョンへ、EUからはEUマルチリージョンへという対応になります。クロスプロジェクトの転送はサポートされません。課金はLOAD DATAが転送バイト数に基づき、CREATE TABLE AS SELECTやINSERT SELECTでは転送バイト数に加えてコンピュート容量も対象になります。
使い分けの目安はこうです。毎回の分析対象が全量に及ぶなら、繰り返し転送するより複製を置いたほうが安定します。参照が月数回で対象期間も狭いなら、その場でクエリして集計結果だけ返すほうが低コストです。定期コピーを前提にした構成そのものはData Transfer Serviceの対応ソースと転送スケジュール設計で扱っています。
クエリ頻度と走査範囲からコピーして持ち込む構成との損益分岐を判断する
比較の軸は3つに整理できます。第一に、S3側のデータ量と増加ペース。第二に、分析クエリの頻度と1回あたりの走査範囲。第三に、BigQuery側の機能をどこまで使うか。
データが大きく参照頻度が低いほど、その場でクエリする構成が効きます。逆に、同じデータへ日に何十回もアクセスし、機械学習やマテリアライズドビューまで使うなら、コピーして持ち込んだほうが総額でも運用でも軽くなりました。中間の領域では、生ログはS3に残し、日次で集計した粒度の粗いテーブルだけBigQueryへ転送する構成が扱いやすい形になります。
採否の判断：Omniを採る条件・クロスクラウド接続に寄せる場面・AWS側で完結させる場面
ここからは判断です。国内案件では、Omni以外の選択肢を検討する場面のほうが多くなります。
東京・大阪のS3が対象ならクロスクラウド接続という代替を採る
Omniリージョンに東京と大阪が無い以上、国内で運用しているS3バケットを対象にする案件では、Omniは使えません。ここで代替になるのがBigQueryのクロスクラウド接続です。公式ドキュメントは、この接続を「他のクラウドからBigQueryへデータを取り込んでクエリするもの」と説明し、Omniを使う標準接続に代わる選択肢だと位置づけています。
両者の違いは処理の場所です。Omniが出先のクラウドで処理して結果を返すのに対し、クロスクラウド接続はBigQuery側の基盤で処理します。その代わり、通常のBigQueryリージョンで使え、BigQueryのAI機能やGeminiの機能、マテリアライズドビュー、ユーザー定義関数が使えます。専用のコンピュート容量ではなく標準のスロット予約とコミットメントを消費する点も、運用の一本化という意味では扱いやすい部分です。
判断としては、国内リージョンのデータを対象にするなら、まずクロスクラウド接続を検討してください。生データがGoogle Cloud側へ渡る前提になるため、転送量とデータの所在に関する社内規程の確認は別途必要になります。
BigQuery Omniを採用してよいリージョンと分析条件を見極める
Omniが噛み合うのは、次の条件がそろった場合だと考えています。対象データが対応リージョン、たとえば北バージニアやアイルランドのS3にあること。データ量が大きく、Google Cloud側へ動かすと転送費用と時間が現実的でないこと。分析の出力が集計結果で、明細の全件取得ではないこと。そしてEnterpriseエディションかオンデマンド課金で運用していること。
この4つがそろえば、元データを移さずに単一のSQLで横断できる利点が費用と制約を上回ります。海外拠点や海外SaaSのログがそのリージョンに落ちている構成では、条件を満たすことがあります。
AthenaやRedshiftでAWS側に寄せる判断が向くワークロード条件
逆に、Omniを見送ってAWS側で完結させたほうがよい場面もあります。分析対象がS3のデータだけで完結し、BigQuery側の資産と突き合わせる必要が無い場合です。S3上のファイルへSQLを投げる用途なら、Amazon Athenaの使い方とクエリ課金の仕組みのほうが構成も請求も1つのクラウドに収まります。
同時実行数が多く、BIから常時参照するようなワークロードならAmazon Redshiftのアーキテクチャと料金体系を検討対象に入れてください。BigQueryを併用する理由が「既存のダッシュボードがLooker Studioだから」程度であれば、AWS側で完結させて可視化ツールだけ接続するほうが構成は単純になります。
両クラウドにまたがる構成は、権限設計とネットワーク、そして請求の管理が二重になります。どちらへ寄せるかの判断や、既存環境を踏まえた移行の設計から相談したい場合は、AWS・Google Cloud・Azureのインフラ構築支援をご確認ください。
BigQuery Omniの対応範囲と費用・導入判断でよくある質問と回答
採否の判断で分かれやすい点を5つに絞って整理します。
BigQuery Omniは東京リージョンのS3を扱えますか？
2026年8月17日時点で扱えません。公式ドキュメントが挙げるOmniリージョンはAWSが北バージニア・オレゴン・アイルランド・フランクフルト・ソウル・シドニーの6つ、Azureは米国東部2の1つで、東京と大阪は含まれていません。国内バケットを対象にする場合は、BigQueryのクロスクラウド接続でBigQuery側へ取り込んでクエリするか、定期コピーする構成に切り替えてください。
Omni経由のクエリでBigQuery MLは使えますか？
Omniリージョンでは対応していません。DMLとDDLステートメント、JavaScriptのユーザー定義関数、BigQuery Storage APIも同様に対象外です。予測モデルの学習まで含めるなら、クロスクラウド転送やData Transfer Serviceで対象データをBigQuery側のリージョンへ移してから扱う構成になります。
料金はBigQueryの通常クエリと同じですか？
課金の考え方はBigQueryの料金モデルに沿いますが、単価はリージョンごとに設定され、加えてAWS側のエグレス料金が別に発生します。クロスクラウド転送を使う場合は転送バイト数への課金も乗ります。金額は改定されるため、見積もり時に公式の料金ページで現行値を確認してください。
OmniとBigQueryのクロスクラウド接続はどちらを選ぶべきですか？
データの所在で切り分けるのが分かりやすい形です。対応リージョンにあり、データ量が大きく、返すのが集計結果ならOmni。対応外のリージョン、たとえば東京のS3が対象なら、通常のBigQueryリージョンで使えるクロスクラウド接続を選びます。後者はBigQuery側の機能が一通り使え、標準のスロット予約を消費する点も運用を単純にします。
Omniを使うのにAWSアカウント側で必要な準備は何ですか？
アクセスキーの発行ではなく、IAMロールによる信頼関係の設定です。BigQuery側で接続を作成すると識別子が返るので、それをAWS IAMロールの信頼ポリシーに登録し、対象のS3バケットを読める権限をロールへ付けます。そのうえでOmniリージョンにデータセットを作り、S3のURIを指すBigLake外部テーブルを定義する流れになります。
関連記事
- Amazon Redshift Serverlessとは｜仕組みと料金・実装・移行判断：AWS側で完結させる場合のDWH候補を確認する
- データ分析基盤の構築｜5層アーキテクチャとBigQuery実装手順：どこにデータを集約するかを基盤全体から考える
- BigQuery APIの選び方と権限・リトライ設計：Storage APIが使えない前提でのAPI選択に
- BigQueryの使い方：コンソールとbqコマンドの初回操作：接続とデータセット作成の基本操作を確認する
- BigQueryの事例4類型｜成果が出た条件と自社導入の判断軸：マルチクラウド構成を導入判断の文脈に置く
