【2026年最新版】BigQuery Omni（AWS/Azureデータ）で外部クエリが実行できない対処法【完全ガイド】

※本ページにはプロモーション(広告)が含まれています

Google BigQuery Omni は、Google Cloud にデータを移すことなく AWS S3 や Azure Blob Storage 上のデータを直接クエリできる、マルチクラウド分析の切り札です。ところが現場では「BigQuery Connection を作ったのにクエリが返ってこない」「権限エラーで実行できない」「テーブルは見えるのに SELECT すると失敗する」といった問題が頻発します。マルチクラウドゆえのリージョン制約と IAM 連携の複雑さが、BigQuery Omni を扱ううえで最大の壁になっているのが実情です。

本記事では、BigQuery Omni でクエリが実行できない問題の原因切り分けから、BigQuery Connection の正しい作成手順、AWS IAM ロール / Azure Service Principal 設定、データセットリージョンの注意点、料金体系の落とし穴、よくあるエラーへの対処までを体系的に解説します。コンソール操作だけで完結する手順と、bq コマンド・Terraform を使った再現性の高い構成も併記しているので、運用フェーズにある方も初学者の方も活用できます。

この記事でわかること

• BigQuery Omni の仕組みとアーキテクチャ概要
• クエリが実行できない時に最初に確認すべき 5 ポイント
• BigQuery Connection の作成手順(AWS / Azure)
• 必要な IAM ロール・Service Principal 権限
• サポートされるリージョンの組み合わせ
• 料金体系とコスト最適化のコツ
• 典型的なエラーメッセージと対処法
• よくある質問への回答

BigQuery Omni の仕組みを理解する

マルチクラウド分析の橋渡し役

従来、BigQuery で AWS や Azure のデータを分析するには、データを Google Cloud Storage に転送してからインポートする必要がありました。BigQuery Omni はこの転送ステップを省略し、データを「置いてある場所」のクラウドで直接クエリを走らせて結果だけを返す仕組みです。AWS では Amazon EKS 上に、Azure では Azure Kubernetes Service 上に Anthos クラスタを配置して BigQuery クエリエンジンを実行します。

クエリ結果は通常の BigQuery と同じインターフェース

クエリの実行は普段の BigQuery コンソール、bq コマンド、または BigQuery API を使います。SQL の書き方も標準 SQL のままで、AWS S3 のデータも Azure Blob のデータも Google Cloud のテーブルと同じ感覚で SELECT できます。違いは「リソース(データセット)が存在するリージョンが AWS / Azure の特定リージョンであること」です。

BigQuery Connection の役割

BigQuery Connection は「BigQuery と外部クラウドを橋渡しする認証チャネル」です。AWS の場合は AssumeRole によるフェデレーション、Azure の場合は Service Principal による委任認証で、BigQuery のサービスアカウントが外部クラウドのストレージへ読み取りに行くことを許可します。Connection が正しく作られていないと、クエリ実行時に「Permission denied」エラーが返ります。

クエリが動かない時にまず確認する 5 項目

(1)データセットのリージョンが Omni 対応か

BigQuery Omni のデータセットは、必ず「aws-us-east-1」「azure-eastus2」などの専用リージョンで作成する必要があります。Google Cloud のリージョン(US、asia-northeast1 など)で作成したデータセットでは、AWS / Azure 上の外部テーブルを SELECT できません。データセット作成時のリージョン選択ミスが、つまずきの最頻出原因です。

(2)BigQuery Connection が作成・関連付けされているか

外部テーブルの作成時には Connection ID を指定します。Connection が存在しても、テーブル定義と紐付いていなければクエリは失敗します。「BigQuery Studio」→「外部接続」から、対象 Connection の状態が「準備完了」になっていることを確認してください。

(3)IAM 設定が完了しているか

AWS の場合は、Connection 作成時に表示された「BigQuery アイデンティティ ARN」を AWS IAM ロールの信頼ポリシーに追加し、そのロールに S3 読み取り権限を付与する必要があります。Azure の場合は、Service Principal にストレージ Blob データ読み取り権限を割り当てます。これが抜けていると「access denied」が返ります。

(4)外部テーブルの DDL が正しいか

外部テーブルは CREATE EXTERNAL TABLE 文で定義します。S3 のパス・Connection ID・スキーマ・形式(Parquet / CSV / Avro 等)を正しく指定する必要があり、どれか 1 つでも抜けると「No suitable connection」「Schema not found」などのエラーになります。

(5)料金体系で必要な機能が有効か

BigQuery Omni はオンデマンド課金とエディション課金(Enterprise / Enterprise Plus)に対応しています。リージョンによっては Enterprise エディション以上が必要で、オンデマンドのみでは実行できないことがあります。「BigQuery エディション」設定を確認し、対象リージョンが利用可能なエディションになっているかチェックしてください。

BigQuery Connection を正しく作成する(AWS 編)

ステップ 1: BigQuery 側で接続を作成

BigQuery Studio の「外部接続」から「外部データソースの追加」を選択し、接続タイプ「BigLake on AWS」を選びます。接続 ID(任意の名前)、ロケーション(aws-us-east-1 など)、AWS の IAM ロール ARN(後で作成)を入力して「接続を作成」。作成完了後、画面上に「BigQuery アイデンティティ」(arn:aws:iam::…)が表示されるので必ずコピーしておきます。

ステップ 2: AWS で IAM ロールを作成

AWS マネジメントコンソール → IAM → 「ロール」→「ロールを作成」。信頼されたエンティティとして「Web ID」を選び、Identity Provider に「accounts.google.com」を指定。Audience(aud)に先ほどコピーした BigQuery アイデンティティの最後の部分を貼り付けます。S3 へのアクセスポリシーとして「AmazonS3ReadOnlyAccess」もしくは特定バケットだけを許可するカスタムポリシーをアタッチします。

ステップ 3: 信頼ポリシーを編集

作成したロールの信頼関係に、BigQuery が AssumeRole できる条件を追加します。具体的には Condition の StringEquals に "accounts.google.com:sub": "" を指定します。これでこの BigQuery 接続専用のロールとして固定でき、第三者が誤って使うリスクがなくなります。

ステップ 4: BigQuery 側にロール ARN を反映

BigQuery Studio に戻り、先ほど作成した接続を編集して AWS のロール ARN を貼り付けます。接続テストを実行し、「接続成功」が出れば準備完了です。失敗する場合は IAM ロールの信頼ポリシーまたは Audience の値が一致していない可能性が高いです。

BigQuery Connection を正しく作成する(Azure 編)

ステップ 1: Azure AD でアプリを登録

Azure ポータル → Microsoft Entra ID(旧 Azure AD)→「アプリの登録」→「新規登録」。名前を入力(例: bigquery-omni-connector)、サポートされるアカウントを「シングルテナント」に。登録後、表示される「アプリケーション(クライアント)ID」と「ディレクトリ(テナント)ID」を控えます。

ステップ 2: BigQuery 側で接続を作成

BigQuery Studio の「外部接続」から接続タイプ「BigLake on Azure」を選択。接続 ID、ロケーション(azure-eastus2 等)、Azure テナント ID、フェデレーションアプリケーションのアプリケーション ID を入力して保存します。

ステップ 3: BigQuery アイデンティティに権限委譲

接続作成後、BigQuery が表示する「フェデレーション ID」(URL 形式)を Azure AD のアプリ「フェデレーション資格情報」に追加します。これで Google 側の BigQuery サービスアカウントが Azure AD アプリとして振る舞えるようになります。

ステップ 4: ストレージ Blob データ読み取り権限を付与

対象の Storage Account → 「アクセス制御(IAM)」→「ロールの割り当ての追加」で、「ストレージ Blob データ閲覧者(Storage Blob Data Reader)」ロールを Azure AD アプリに割り当てます。コンテナ単位で絞ることも可能です。

外部テーブルを作成しクエリする

外部テーブルの作成例(AWS S3)

下記のような SQL でテーブル定義を作成します。Connection ID には先ほど作成した名前、URL には対象 S3 パスを指定します。

CREATE EXTERNAL TABLE my_dataset.sales_log
WITH CONNECTION `aws-us-east-1.my_aws_conn`
OPTIONS (
  format = 'PARQUET',
  uris = ['s3://my-bucket/sales/*.parquet']
);

外部テーブルの作成例(Azure Blob)

CREATE EXTERNAL TABLE my_dataset.events
WITH CONNECTION `azure-eastus2.my_azure_conn`
OPTIONS (
  format = 'CSV',
  uris = ['azure://account.blob.core.windows.net/container/events/*.csv']
);

クエリの実行

作成した外部テーブルは普通の SELECT で読み取れます。SELECT COUNT(*) FROM my_dataset.sales_log のように記述するだけで、裏側で AWS / Azure 上のクエリエンジンが起動し、結果が BigQuery に返されます。クエリ結果のサイズが大きいほど、データ転送料金がかかる点には注意してください。

サポートされるリージョン

AWS の対応リージョン

BigQuery Omni for AWS は以下のリージョンで利用可能です(2026 年時点)。

• aws-us-east-1(バージニア北部)
• aws-us-west-2(オレゴン)
• aws-ap-northeast-2(ソウル)
• aws-eu-west-1(アイルランド)

東京リージョン(ap-northeast-1)はまだ対応していないため、日本国内のデータでもソウルや米国経由でクエリする運用となります。

Azure の対応リージョン

• azure-eastus2(米国東部 2)
• azure-westus2(米国西部 2)
• azure-northeurope(北ヨーロッパ)
• azure-eastjapan(東日本) ※段階的展開中

クロスリージョンクエリの注意

BigQuery Omni のリージョンはストレージのリージョンと一致させる必要があります。aws-us-east-1 のデータセットから aws-us-west-2 の S3 バケットを SELECT すると失敗するか、追加の転送料金が発生します。設計段階でリージョンを揃えることが重要です。

料金体系と最適化

クエリ料金

BigQuery Omni のクエリ料金は通常の BigQuery オンデマンド料金より割高です(リージョンにより 1.5〜2 倍)。スキャンするデータ量に応じて課金されるため、Parquet 等のカラムナフォーマットを使うと劇的にコスト削減できます。CSV をそのまま読むのは避けてください。

クロスクラウド転送料金

クエリ結果を Google Cloud に持ってくる「BigQuery Omni のクロスクラウド転送」には別途料金がかかります(GB あたり数十円〜数百円)。集計後の小さな結果セットを返すように設計し、生データを大量に転送しないことが鉄則です。

エディションの選択

2026 年現在、BigQuery Omni は Enterprise エディション以上の利用が推奨されています。Enterprise Plus を選べば BI Engine、レプリケーションなど高度機能も使えます。チームでの本格運用なら Enterprise 以上を選ぶのが妥当です。

主要な対処法の比較表

エラー / 症状	原因	対処法	所要時間
Permission denied	IAM 権限不足	S3 / Blob の読み取り権限を付与	5 分
No suitable connection	Connection 未指定	外部テーブル DDL に Connection ID を追加	2 分
Region mismatch	データセットと S3 のリージョン不一致	同一リージョンで再作成	15 分
Edition not supported	オンデマンド契約のみ	Enterprise エディションへ切替	10 分
Schema not found	形式や URI 誤り	format / uris の見直し	5 分
Connection failed	信頼ポリシー不一致	Audience / フェデレーション ID を再確認	10 分
転送料金が高騰	大量データを GCP へ転送	集計後の結果のみ転送する設計に変更	30 分
クエリが極端に遅い	CSV を直接 SELECT	Parquet や Avro へ変換	1 時間

運用上の Tips

BigLake テーブルとの違い

BigQuery Omni と似た仕組みに BigLake があります。BigLake は Google Cloud Storage 上のデータを「あたかも BigQuery テーブルのように」扱うもので、リージョンも Google Cloud です。BigQuery Omni は AWS / Azure 上のデータを対象にする点で異なります。両者を混同しないよう注意してください。

パフォーマンスチューニング

BigQuery Omni は通常の BigQuery より物理的な遅延が大きいため、可能な限りデータをパーティション分割し、WHERE 句でパーティションを絞るクエリを書きましょう。Parquet ファイルを 1 GB 程度のサイズに分割しておくのも有効です。

Terraform での自動化

本番運用では BigQuery Connection や IAM ロールの作成を Terraform で記述するのが定石です。google_bigquery_connection リソースで接続を、aws_iam_role でロールを定義し、CI/CD で再現可能にしておくと、複数環境への展開や災害復旧が容易になります。

よくある質問(FAQ)

Q1. BigQuery Omni は無料枠で試せますか?

BigQuery 自体には毎月 1 TB のクエリ無料枠がありますが、Omni のクエリは無料枠の対象外です。少量から試す場合でも数十円〜数百円のコストが発生する可能性があります。

Q2. AWS の Glue Data Catalog と連携できますか?

2026 年時点では Glue Data Catalog から直接スキーマを読み込む機能は限定的です。BigQuery 側で外部テーブル定義を手動作成するのが一般的です。Iceberg テーブルへの対応は段階的に進んでいます。

Q3. Azure Blob のプライベートエンドポイントに対応していますか?

BigQuery Omni for Azure はインターネット経由でストレージにアクセスする仕様のため、プライベートエンドポイントのみのストレージは利用できません。パブリックアクセスを許可するか、専用ファイアウォール設定が必要です。

Q4. データの書き込み(INSERT)はできますか?

BigQuery Omni は基本的に「読み取り専用」です。書き込みが必要な場合は、データを GCS にエクスポートしてから書き戻す形になります。一部のリージョンでは MATERIALIZED VIEW の自動更新がサポートされています。

Q5. オンデマンドだけで Omni を使えませんか?

一部リージョンではオンデマンドでも利用可能ですが、新規リージョンや高度機能は Enterprise エディション必須です。長期利用を見越して早めに Enterprise へ移行することをお勧めします。

Q6. クエリ実行ログはどこで確認できますか?

通常の BigQuery と同じく Cloud Logging に記録されます。ジョブ ID で AWS / Azure 側の処理時間や転送量も追跡できるため、コスト分析にも便利です。

Q7. ベンダーロックインのリスクはありませんか?

SQL は標準 SQL なので、他社サービスへの移行も比較的スムーズです。Connection 設定や DDL は再構築が必要ですが、データそのものは AWS / Azure に残るため、データ移動コストは発生しません。

Q8. リアルタイムストリーミングデータも分析できますか?

S3 / Azure Blob のファイルとして書き出されたデータは即座にクエリできますが、ミリ秒単位のリアルタイムには向きません。Dataflow や Pub/Sub を経由した本格的なストリーミング基盤と併用するのが現実的です。

まとめ

BigQuery Omni でクエリが実行できない問題は、ほぼ「リージョン不一致」「Connection 未設定」「IAM 権限不足」のいずれかに集約されます。本記事のステップに従って Connection を設計し、IAM・Service Principal を漏れなく構成し、クエリ対象データを Parquet 化しておけば、マルチクラウドの強みを活かしながらコストを抑えた分析基盤が構築できます。

BigQuery Omni は、データの主権を維持したままクラウドを跨いだ分析を可能にする数少ない選択肢です。比較表とエラー対処法を活用し、安定した運用を目指してください。