ども！最近バグ調査のたびに Azure CLI を叩いている龍ちゃんです。 バグ調査でコードを読むところ、AI にやらせると爆速なんですよね。処理の順序を追って、どこで何が呼ばれているかを整理するくらいなら、もう完全に任せてます。ここはめちゃくちゃ助かってます。 で、あるとき思ったんです。次はバグの原因まで見つけられるように、アプリのログも自由に見れる形にしたら、調査もっとはかどるんじゃね？と。 ただ、正直に言うと僕、 KQL そんなに書けないんですよ。Application Insights のログを引くやつですね。書けないから今までポータルのグラフを眺めて終わっていました。 で、そこを整備してみたら、 書けるようにならないまま読めるようになった んです。整備といっても大したことはしていなくて、Azure CLI を Claude Code に叩かせる形にしただけです。これがめちゃくちゃ良かったので共有します。 今回の内容です。 仮説を渡すと、それを確かめる集計がそのまま返ってくるという話 実際にどう頼んで、どう叩かせているか AI に Azure を触らせる前に、こっちで決めておいたこと それでも仮説は人間が立てたほうがいい、という話 なお、Application Insights そのものの説明はしません。社内の先輩の武井さんが書いた 世界一わかりみの深いAPM 〜Application Insights〜 という決定版があるので、そちらに譲ります。計装の入れ方も扱いません。すでに入っていて、必要な情報が出ている状態からのスタートです。KQL の書き方も解説しません。書けないので、動いたものをそのまま貼っていきます。 あともう1つ。Azure 側にも 自然言語で聞ける仕組み が乗っています（Observability Agent）。ただ Azure Copilot へのアクセスが要って、今のところ英語のみなんですよね（2026年8月時点）。 この記事はそっちの話ではないです。 手元の Claude Code から Azure CLI を叩く形の話をします。 うれしいのは、仮説をそのまま確かめられることでした 先に一番おいしいところを言います。 思いついた仮説を、そのまま確かめられる ようになったんですよね。 バグを追っていると「たぶんこうなってるんじゃないか」が浮かぶじゃないですか。最初の1回だけ遅いんじゃないか、とか。特定のエンドポイントだけ詰まってるんじゃないか、とか。 前はそこで止まってました。確かめるには KQL を書かないといけなくて、書けないから調べながら組み立てて、たいてい1本目で力尽きる。だからポータルのグラフを眺めて「なんとなくそれっぽい」で終わっていたんです。 今は、その仮説を言葉のまま渡せば、確かめる集計が返ってきます。表を見て当たりか外れかが分かって、外れていたら次の仮説を投げる。 この回転が速いこと が、僕にとっての「ログが調査に使える」でした。 グラフを眺めるのと決定的に違うのはここだと思っていて、ポータルって「用意された切り口」を見る場所なんですよね。自分の仮説に合わせた切り口は自分で作るしかない。そこを肩代わりしてもらえると、仮説を出すコストだけ払えばよくなります。 生ログを丸ごと渡してるわけではないです 「AI にログを読ませる」と言うと、生ログをどさっと投げるイメージがあると思います。僕も最初はそう思っていました。 でも実際は逆で、KQL 側で集計してから返させています。AI が受け取るのは集計済みの表だけです。生ログが要る場面なら読ませますけど、基本は表です。 これ、トークンをケチるためだと思われがちなんですが、そこはあんまり関係なかったですね。効いたのは、 集計の条件がクエリに残る ことのほうでした。 生ログを渡して集計させると、その集計をどうやったのかが会話の中に消えます。後から「この数字どうやって出した？」と聞き直すことになる。クエリで集計してあれば、そのクエリ自体が手順書なんですよね。数字を疑いたくなったら、同じものをもう一度叩けばいい。 あと単純に、数を数えるところを AI にやらせるのが怖いんですよね。なので集計が要る作業は全部 KQL 側に寄せています。 ログで見えたことを、そのまま設定と突き合わせられます これは後から効いてきたやつです。 ログを引くのが az monitor app-insights query で、リソースの設定は az functionapp show 。同じ CLI なんですよね。 az functionapp show -g <リソースグループ> -n <関数アプリ名> \ --query "properties.functionAppConfig.scaleAndConcurrency" -o json { "alwaysReady": [ { "instanceCount": 1, "name": "http" } ], "instanceMemoryMB": 2048, "maximumInstanceCount": 40, "triggers": {} } この出力は Flex Consumption プラン のものなので、別のプランだと形が変わります。 「ログ上はこう見えるけど、設定はこうなってる」の突き合わせがそのままつながります。ポータルだと画面を行き来してスクショを渡すことになって、渡した時点でどれがどこの値なのか分からなくなるんですよね。 実際は、知りたいことと仮説を渡してるだけです じゃあ何を渡しているのか、という話です。 先に1つだけ言っておくと、 az は権限が付いていればリソースを消せます 。この後の「決めておいたこと」に注意書きを書いたので、手を動かす前にそこだけ読んでもらえると安心です。 渡しているのは2つだけです。 知りたいこと と、 仮説 。 こんな感じで言ってます。 この時間帯で遅かったやつをエンドポイント別に見たい。たぶん最初の1回だけ遅いんだと思う これで返ってくるのがこういうクエリです。 requests | where timestamp between (datetime(2026-07-20T00:00:00Z) .. datetime(2026-08-04T08:00:00Z)) | where cloud_RoleName == "<関数アプリ名>" | extend path = tostring(parse_url(url).Path) | where path endswith "/auth/csrf" or path endswith "/auth/login" | summarize reqs=count(), slowPct=round(100.0*countif(duration>5000)/count(),1), p50=round(percentile(duration,50),0), p90=round(percentile(duration,90),0) by name, resultCode ここで一回止まって、僕がクエリに目を通します。読み取りだけになっているか、対象がちゃんと絞れているか。この確認だけは毎回やっていて、問題なければ叩かせます。KQL が分からなくても、なんとなくは読めますよね（英語力さえあれば…）。引っかかったところは AI に聞けば済みます。 叩くのはこれです。 az monitor app-insights query --app <appId> \ --analytics-query "$(cat q.kql)" \ --start-time 2026-07-20T00:00:00Z --end-time 2026-08-04T08:00:00Z \ --query "tables[0].rows" -o tsv エンドポイントごとに件数と p50 / p90 が並んだ表が返ってくるので、それを見て仮説が当たっていたかを判断します。外れてたら「じゃあインスタンス別でも見たい」と言えばすぐ次が出てきます。 細かいところを補足しておきますね。 クエリは ヒアドキュメントでファイルに落として から食わせています。シェルに直書きするとパイプと引用符だらけで事故るんですよね。ファイルにしておくと、クエリだけ差し替えて何回も回せます。何を叩いたのか？という痕跡をファイルで残すということですね。 <appId> は Application Insights のアプリケーション ID です。ポータルの Application Insights リソースから「API アクセス」を開くと載っています。 -o tsv にしているのは、そのまま次の集計に食わせたいからです。JSON のままだと、AI が読むにも人が見るにも一手増えます。 --start-time と --end-time は KQL 側の between と同じ範囲にしておくのがおすすめです。ずらすと、どっちの条件で絞られた結果を見ているのか分からなくなります。 ちなみに az monitor app-insights query は application-insights 拡張のコマンドなんですが、入っていなければ初回に勝手に入ります。ここは気にしなくて大丈夫でした。 あと、複雑なクエリだと CLI 側が弾いてくることがあります。そのときは「直して」と言えばそのまま通る形にしてくれるので、楽々です。ただ、内容は読んでおいて勉強につなげています。 AI に Azure を触らせる前に、決めておいたこと ここからは運用の話です。 先に言っておくと、 Azure 側の権限をどう設計するかは書きません 。RBAC をどう振るかは組織ごとの運用の話で、僕が「こうしろ」と言えるものじゃないので。 ここで書くのは、AI に触らせる前に こっち側で決めておいたこと です。3つあります。 認証方式は1つに決めておく 僕は az login で自分がログインして、 その資格で AI に叩かせています 。 理由は、とりあえず一番手軽だからです。常設のトークンをどこにも置かなくて済むのもいいところですね。 ただこれ、 権限の縛りやすさと安全マージンを上げたくなったら、選択肢は増えていきます 。サービスプリンシパルとか、マネージド ID とかですね。 このへんも武井さんが書いてくれているので、そちらに譲ります。 もう多分怖くないサービスプリンシパル と 世界一わかりみの深いマネージドID 〜ソースコードから資格情報を追い出そう！！〜 です。僕は今回どちらも使っていないので、名前を挙げるだけにしておきます。 どれを選ぶかは次の注意書きにつながる話なので、そこでもう一度触れます。 どれを選ぶにしても、 先に1つに決めておくこと が大事だと思っていて。その場の思いつきで方式が混ざると、何の権限で何を叩いたのかが後から追えなくなります。 見せる対象を固定する --app で読みにいく Application Insights を1つに固定して、 where cloud_RoleName == "..." で対象のアプリまで絞っています。上に貼ったコマンドにもう入っているやつですね。 これ、 安全の話であると同時に、精度の話でもあります 。 安全のほうは単純で、対象を固定しておけば、AI が見にいける範囲がそのアプリのログの外に出ません。関係ない別チームのアプリのログまで読める状態にしておかない、という話ですね。 で、精度のほうがちょっと厄介でした。1つの Application Insights に複数のアプリが相乗りしていることがありますよね。僕の環境がまさにそれで、調べたい対象の API よりも、まったく関係のない別のアプリのほうがリクエスト件数が多かったです。あと、別のアプリの数字を自分のだと思って読むのが一番まずいですからね。 知らずに数を数えると全部混ざった値が出ますし、見た目は普通の数字なので間違いに気づけません。なので最初の1本は、これを流しておくのがおすすめです。 requests | where timestamp between (datetime(...) .. datetime(...)) | summarize reqs=count(), instances=dcount(cloud_RoleInstance) by cloud_RoleName | order by reqs desc cloud_RoleName ごとの内訳を出すだけのクエリです。1回叩いておけば、以降のクエリにフィルタを入れ忘れなくなります。僕は後から気づいたクチなので、ここだけは先にやっておいてほしいです。 読み取りだけにする 叩かせるのは読み取り系のコマンドだけにしています。 調査でやりたいのは現状を知ることなんで、書き込みが要る場面ってそもそも無いんですよね。無いなら最初から候補に入れない。 で、どうやって守らせているかというと、正直に言うと仕組みでは塞いでいません。 クエリを先に作らせて、実行前に自分で目を通す 。さっき書いたやつですね。あとは Claude Code に読ませる指示ファイル（ CLAUDE.md ）に方針を書いているくらいです。 なのでこれ、「AI が絶対に書き込めない」状態ではないです。 人が見ているから成立している 、くらいのものだと思ってください。ツール側の許可設定で塞ぐ手もあって、そっちのほうが確実だとは思っています。ここはまだ模索中で、運用フローに載せて正式に導入するところまでは行けていないですね。 注意：権限次第では、リソースを吹き飛ばせます ここは強めに書いておきます。 az は調べるためだけのコマンドじゃないです。 権限が付いていれば、リソースを消すこともできます。 つまり、AI に渡した資格に何が付いているかで、事故ったときの被害範囲が決まります。 上に書いた「読み取りだけにする」は、あくまで こっち側の運用 でそうしているだけで、権限そのものを塞いでいるわけではありません。ここが効くのは権限側です。 なので、 始める前に社内の Azure 運用の担当に確認してください。 どこまでの権限で触っていいのか、そもそも AI に叩かせていいのか。ここは環境ごとに答えが違うので、僕が書けるのは「確認しよう」までです。 さっきの認証方式の話に戻ると、 縛りやすさと安全マージンを上げたければ選択肢は増えます 。僕が az login にしているのは手軽さを取った結果であって、ここが正解というわけではないです。 じゃあ人間は要らないのか、というと逆でした 最後に、一番言いたかったことを書きます。 そもそも最初の KQL は、レビュアーの方が Issue のコメントで投げてくれたものでした。確認項目を並べたうえで、クエリの例まで付けてくれていたんです。 ただ、後から考えると、効いたのはクエリそのものじゃなかったんですよね。クエリは仮説さえ渡せば AI が書いてくれるので、あれが無くても回ったと思います。ありがたかったのは、その前に並んでいた 「何を確認すべきか」 のほうでした。 しかもその方は、コメントの最後にノイズの注意まで書いてくれていました。サンプリングで最初の要求が欠落することがある、といったやつです。App Insights は量が多いと ログを間引くことがある ので、そうなると数え上げた件数がそのまま実数ではなくなるんですね。 この件、僕は最後まで確認していません。全数ある前提で率を出しました。ここは反省点です。 思ったんですけど。 良い仮説を出せるかどうかって、そのシステムをどれだけ知っているかで決まる んですよね。 どんなログを吐いているのか。どういう構成で動いているのか。どこが詰まりやすいのか。それを知っている人間のほうが、確かめる価値のある問いを立てられます。AI はその問いを 確かめる のがめちゃくちゃ速いだけで、問いそのものを出してくるわけじゃない。 だから「AI に読ませる形にしたら人間が要らなくなる」ではないです。むしろ逆で、 仮説を出すところに人間が集中できるようになった 、が正しい。KQL を書く時間が消えた分、何を疑うかを考える時間が増えた感じですね。 書いていないことが3つあります。実際どんなシナリオで何が見つかるのか、どんなログを吐いて customEvents に何を積むべきかは、APM をどう設計するかの世界なのでまた別で。読ませた数字をどう疑うかも、それだけで一本になるので入れていません。GitHub 側でも同じことをやっていますが、認証まわりの事情が違うので今回は Azure だけで区切りました。 まとめ KQL を書けるようにならないまま、Application Insights の仮説検証を AI に任せた話でした。 渡すのは知りたいことと仮説の2つ。KQL に落とすのは AI の仕事です うれしいのは 仮説をそのまま確かめられる こと。当たり外れが表で返ってきて、次の仮説に進めます 生ログではなく集計した表を返させます。クエリが手順書として残るのが効きます AI に触らせる前に、認証方式・見せる対象・読み取り限定の3つを決めておきます 権限次第ではリソースを消せます。始める前に社内の Azure 運用に確認してください 仮説を出すのは人間の仕事のままです。むしろそこに集中できるようになります 最初の一歩は、 cloud_RoleName ごとの内訳を出すクエリ1本です。相乗りに気づかないまま数えると、以降の数字が全部ずれるので。 KQL が書けないから諦めていたログ、けっこうあると思うんですよね。書けるようになるより、叩かせる形を作るほうが早い気がします。 もし間違いを見つけたら、SNS でもメールでも問い合わせください。 ほなまた〜 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post KQL は書けないまま、Application Insights の仮説検証を AI に任せた first appeared on SIOS Tech Lab .

G-gen の杉村です。当記事では、BigQuery cross-cloud connections と BigQuery Omni の違いについて解説します。いずれも Google Cloud のデータ分析用データベースである BigQuery と、Amazon S3 や Azure Blob Storage を接続するための仕組みです。 概要 BigQuery cross-cloud connections と BigQuery Omni 相違点のサマリ どちらを使うべきか 対応リージョン BigQuery cross-cloud connections BigQuery Omni 使用可能な機能 BigQuery cross-cloud connections BigQuery Omni コンピュートリソースの所在 BigQuery cross-cloud connections BigQuery Omni データセットの所在 BigQuery cross-cloud connections BigQuery Omni 料金 BigQuery cross-cloud connections BigQuery Omni 構築手順 概要 BigQuery cross-cloud connections と BigQuery Omni 当記事では、 BigQuery cross-cloud connections と BigQuery Omni の違いについて解説します。これら2つの機能は、いずれも Google Cloud のデータ分析用データベースである BigQuery と、Amazon Web Services（AWS）の Amazon S3 や、Microsoft Azure の Azure Blob Storage を接続するための仕組みですが、内部的な仕組み、パフォーマンス、料金体系などが異なります。 これらの仕組みを使うことで、BigQuery からクエリを実行してオンデマンドな分析を行ったり、INSERT 〜 SELECT によって AWS / Azure から BigQuery テーブルへデータを転送できます。 参考 : Create cross-cloud connections 参考 : Introduction to BigQuery Omni なお、BigQuery cross-cloud connections は2026年8月現在、Preview 公開であり、本番環境での使用は推奨されません。以下の記事も参考にしてください。 参考 : Preview版のサービスを使うとはどういうことなのか - G-gen Tech Blog 相違点のサマリ BigQuery cross-cloud connections と BigQuery Omni の違いをサマリすると、以下のようになります。詳細は、当記事の残りの部分で解説します。 項目 BigQuery cross-cloud connections BigQuery Omni コンピュートリソースの所在 BigQuery の標準リソース AWS/Azure リージョン内にデプロイされた専用ワーカー データ転送 AWS/Azure から Google Cloud へ生データが転送 AWS/Azure 側で処理が行われ、結果のみが Google Cloud へ返送 パフォーマンス・コスト 生データ転送により処理速度と外向き通信費用に課題が出る可能性 クラウドをまたぐ大規模転送を抑えられ、高速かつ外向き通信費用が小さい傾向 対応リージョン すべての BigQuery リージョンに対応 限定された AWS/Azure リージョンのみ対応 制限事項 通常の BigLake テーブルと同等。比較的制限が少ない BigQuery ML や一部の UDF、Azure Blob Storage のマテリアライズドビュー等が不可 料金体系 通常の BigQuery クエリ料金 + 外向き通信費用 BigQuery Omni 専用のコンピュート料金 (割高な単価) + 外向き通信費用 構築手順の違い BigQuery リージョンに接続 (Connection) を作成 BigQuery Omni 専用リージョン (aws-us-east-1 等) に接続を作成 どちらを使うべきか 前述のような相違点から、以下のいずれかに当てはまるケースでは BigQuery cross-cloud connections が適しており、それ以外のケースでは BigQuery Omni が適しているといえます。 小規模なクエリが中心で、AWS / Azure からの外向きトラフィック料金（data egress charges）を大きく気にする必要がない S3 バケット / Blob Storage コンテナが、BigQuery Omni に対応していないリージョンに配置されている 2026年8月現在、以下の日本国内リージョンは BigQuery Omni に対応していないため、BigQuery cross-cloud connections は有力な選択肢になります。 AWS 東京リージョン（ap-northeast-1） AWS 大阪リージョン（ap-northeast-3） Azure 東京リージョン（japaneast） Azure 大阪リージョン（japanwest） なお、大規模なデータ処理が必要だがデータソースが BigQuery Omni 非対応リージョンにあるといった場合は「AWS / Azure 側でデータを Omni 対応リージョンへ事前転送する」「AWS / Azure 側でデータを事前処理して小さくする」などのアーキテクチャを検討します。 対応リージョン BigQuery cross-cloud connections BigQuery cross-cloud connections は、すべての BigQuery リージョンで使用可能です。 参考 : Create cross-cloud connections - Region recommendations BigQuery Omni BigQuery Omni は以下のリージョンでしか使用できません（表は2026年8月現在のもの）。 AWS 名称 リージョン ID 米国東部（バージニア北部） us-east-1 米国西部（オレゴン州） us-west-2 アジア太平洋地域（ソウル） ap-northeast-2 アジア太平洋地域（シドニー） ap-southeast-2 ヨーロッパ（アイルランド） eu-west-1 ヨーロッパ（フランクフルト） eu-central-1 Azure 名称 リージョン ID East US 2 eastus2 参考 : Introduction to BigQuery Omni - Locations BigQuery Omni では、これらの対応リージョンに配置された S3 バケットや Blob Storage コンテナに対してのみ、クエリできます。非対応リージョンのバケット / コンテナに対しては、クエリできません。なおこれは、後述するコンピュートリソースの場所に関係しています。 前述のとおり、2026年8月現在、BigQuery Omni は東京および大阪の AWS / Azure リージョンに未対応であり、東京および大阪リージョンに配置された S3 バケットや Blob Storage コンテナにはクエリできません。 使用可能な機能 BigQuery cross-cloud connections BigQuery cross-cloud connections を使用して作成した外部テーブル（BigLake テーブル）には、通常の BigLake テーブルの制限が適用されます。 参考 : Introduction to BigLake tables - Limitations これに加えて BigQuery cross-cloud connections では、 EXPORT DATA ステートメントを使ったデータのエクスポート（ファイルへの書き出し）は使用できません。 EXPORT DATA を実行しようとすると、以下のようなエラーメッセージが表示されます。 EXPORT to AWS S3 is only supported for tables present in BigQuery Omni AWS regions. BigQuery Omni BigQuery Omni では、通常の BigLake テーブルの制限に加えて、使用可能な機能にいくつかの制限があります。以下は一部の抜粋です。 BigQuery ML は使用不可 Blob Storage の場合、マテリアライズドビューに対応していない JavaScript UDF（ユーザー定義関数）は使用不可 詳細は以下のドキュメントを参照してください。 参考 : Introduction to BigQuery Omni - Limitations なお BigQuery Omni では先述の EXPORT DATA ステートメントが使用可能であり、ファイルを S3 バケット等へ書き出すことができます。 EXPORT DATA WITH CONNECTION `aws-us-east -1 .connection- for -bigquery-omni` OPTIONS( uri= " s3://my-sample-bucket-n-virginia/* " , format= " CSV " ) AS SELECT 10002 , " mytestname2 " , " mytestvalue2 " , 9999 コンピュートリソースの所在 BigQuery cross-cloud connections BigQuery cross-cloud connections では、一度 BigQuery 上に Amazon S3 や Azure Blob Storage の生データを読み込んでから処理をします。そのため、BigQuery cross-cloud connections は、標準的な BigQuery のコンピュートリソースを使用してクエリを実行できます。 このことから、普段 BigQuery で使っているスロット予約（reservation）やコミットメントを、そのまま使用できます。 BigQuery cross-cloud connections の構成 BigQuery cross-cloud connections では、まず AWS / Azure から Google Cloud への生データの転送が発生することから、処理速度と外向きトラフィック料金が大きく発生する可能性があります。よって、処理速度とコストを最適化するには、対象の AWS / Azure リージョンから最も近い Google Cloud リージョンに、データセットを作成することが望ましいといえます。地理的に近いリージョン同士の対照表は、以下のドキュメントに記載されています。 参考 : Create cross-cloud connections - Region recommendations BigQuery Omni BigQuery Omni は、対象の AWS リージョンや Azure リージョンに、 専用のコンピュートワーカーをデプロイ して処理を行わせる仕組みです（図中の「BigQuery データプレーン」）。 クエリの処理は、AWS リージョンや Azure リージョンの中で完結します。BigQuery Omni が、サポートされているリージョンの S3 バケットまたは Blob Storage コンテナに対してしかクエリできない理由は、ここに起因しています。 参考 : Introduction to BigQuery Omni - Architecture BigQuery Omni の構成 例として BigQuery Omni における SELECT クエリは、AWS / Azure リージョン上のワーカーで処理され、結果だけが Google Cloud に返ります。これにより、大量のデータを処理する場合でも、クラウドをまたいだ大規模なデータ転送が発生しないため、処理速度が速いことに加え、結果のみが転送されるため AWS / Azure からの外向きトラフィック料金（data egress charges）が比較的小さくなります。この点が、BigQuery Omni の利点といえます。 データセットの所在 BigQuery cross-cloud connections BigQuery cross-cloud connections では、標準的な BigQuery リージョン（ us-east1 、 asia-northeast1 等）に BigQuery データセットを作成します。このデータセットに、S3 バケットや Blob Storage コンテナへの外部テーブル等を作成します。 BigQuery Omni BigQuery Omni は、BigQuery データセットを特殊なリージョンに作成します。これらのリージョンは、BigQuery 側では aws-us-east-1 や azure-eastus2 といった名称になり、ここに外部テーブルを設置します。 この特殊なリージョン名は、AWS / Azure のリージョン名の冒頭に aws- または azure- を付与したものです（後述の接続を作成するリージョンの ID と同じもの）。 料金 BigQuery cross-cloud connections BigQuery cross-cloud connections では、通常の BigQuery のクエリ料金（コンピュート料金）が発生します。これに加えて、AWS / Azure からデータが外部に出る際の外向きトラフィック料金が発生します。 BigQuery Omni BigQuery Omni では、AWS / Azure の外向きトラフィック料金に加えて、通常の BigQuery クエリ料金ではなく、BigQuery Omni 専用のコンピュート料金が発生します。この課金は、デフォルトではデータ処理量（TiB）あたりに発生します（Editions を選択することも可能）。この専用料金は、通常の BigQuery オンデマンド料金よりも、割高に設定されています。 通常の BigQuery 料金と異なる設定がされている理由は、AWS / Azure に専用のワーカーをデプロイしているためだと考えられます。 参考 : BigQuery pricing - BigQuery Omni pricing 構築手順 BigQuery cross-cloud connections を使う場合でも、BigQuery Omni を使う場合でも、セットアップ手順はほとんど同一です。 参考 : Create cross-cloud connections - Create AWS cross-cloud connections 参考 : Connect to Amazon S3 AWS との接続を例に取ると、構築手順は両手法とも、おおまかに以下のとおりです。 No 概要 説明 1 AWS 側で IAM をセットアップ IAM ポリシー、IAM ロールを作成する 2 Google Cloud 側で接続（Connection）を作成 認証情報を保存するための接続（Connection）を作成 3 Google Cloud 側で接続（Connection）から BigQuery Google Identity を取得 AWS 側の信頼関係ポリシー等に登録するための数字 4 AWS 側で IAM ロールの信頼関係ポリシーに BigQuery Google Identity を追加 5. とあわせて BigQuery はロールの引き受け（AssumeRole）が可能になる 5 AWS 側でカスタム ID プロバイダ accounts.google.com の Audience として BigQuery Google Identity を追加 4. とあわせて BigQuery はロールの引き受け（AssumeRole）が可能になる これらのうち、BigQuery cross-cloud connections と BigQuery Omni の違いは、手順 2. にあります。接続（Connection）を作成する際、BigQuery cross-cloud connections では、 --location パラメータとして以下のように通常の BigQuery リージョンを指定します。 bq mk --connection \ --connection_type =' AWS ' \ --location = asia-northeast1 \ --project_id = ${PROJECT_ID} \ --properties =' {"accessRole":{"iamRoleId":"arn:aws:iam::123456789012:role/RoleForBigQuery"}} ' \ connection-for-bigquery-cross-cloud 一方で BigQuery Omni の場合、 --location パラメータには以下のように AWS / Azure リージョンを示す独自の ID を指定します。この ID は、AWS / Azure のリージョン名の冒頭に aws- または azure- を付与したものです。 bq mk --connection \ --connection_type =' AWS ' \ --location = aws-us-east-1 \ --project_id = ${PROJECT_ID} \ --properties =' {"accessRole":{"iamRoleId":"arn:aws:iam::123456789012:role/RoleForBigQuery"}} ' \ connection-for-bigquery-omni 外部テーブル（BigLake テーブル）を作成する際に、Google Cloud リージョンに作成された接続を使うと BigQuery cross-cloud connections が使用され、AWS / Azure リージョンに配置された接続を使うと BigQuery Omni が使用されることになります。 外部テーブル（BigLake テーブル）作成時の DDL は以下のようなものです。WITH CONNECTION の後のリージョン ID に着目してください。 BigQuery cross-cloud connections 用の接続を使用する場合 CREATE EXTERNAL TABLE `my-project.my_dataset_tokyo.table_for_s3` WITH CONNECTION `asia-northeast1.connection- for -bigquery- cross -cloud` OPTIONS ( format = ' CSV ' , uris = [ ' s3://my-sample-bucket-tokyo/* ' ] ); BigQuery Omni 用の接続を使用する場合 CREATE EXTERNAL TABLE `my-project.my_dataset_n_virginia.table_for_s3` WITH CONNECTION `aws-us-east -1 .connection- for -bigquery-omni` OPTIONS ( format = ' CSV ' , uris = [ ' s3://my-sample-bucket-n-virginia/* ' ] ); 杉村 勇馬 (記事一覧) 執行役員 CTO 元警察官という経歴を持つ IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の松尾です。当記事では、Google Cloud と Amazon Web Services（AWS）をプライベートに接続する Partner Cross-Cloud Interconnect for AWS について解説します。 概要 Partner Cross-Cloud Interconnect for AWS とは 対応リージョン transport リソース Cross-Cloud Interconnect との比較 料金 接続方式 接続方式の違い VPC ネットワークピアリング Network Connectivity Center 2 つの方式の比較 接続の表示・更新・削除 注意点 概要 Partner Cross-Cloud Interconnect for AWS とは Partner Cross-Cloud Interconnect for AWS は、Google Cloud と Amazon Web Services（以下、AWS）の間にプライベートな専用線接続を提供するマネージドサービスです。対応するペアリングロケーションであれば、両クラウドのリソースをインターネットを経由することなくセキュアに相互接続できます。 本サービスの最大の特徴は、ネットワークサービスプロバイダーとの回線契約や、クラウド間のポート申請等の物理回線の手配が不要である点です。Google Cloud と AWS の両社が共同設計したインフラを利用するため、数ステップの操作を行うだけで、わずか数分で専用線の接続ができます。Google Cloud 側では、VPC ネットワークピアリングや Network Connectivity Center スポークといったクラウドリソースとして接続を管理できます。 参考 : AWS 向け Partner Cross-Cloud Interconnect の概要 参考 : 画期的な AWS とのコラボレーションで Google Cloud のクロスクラウド ネットワークを拡大 なお2026年8月現在、Google Cloud および AWS の東京リージョンや大阪リージョンには対応していない点に注意が必要です。 対応リージョン Partner Cross-Cloud Interconnect for AWS では、Google Cloud のリージョンと AWS のリージョンが、あらかじめ決められたペアとして定義されています。2026年8月現在、対応するリージョンペアは以下のとおりです。最新の一覧は以下の公式ドキュメントを参照してください。 Google Cloud リージョン AWS リージョン asia-southeast1（シンガポール） ap-southeast-1（シンガポール） europe-west2（ロンドン） eu-west-2（ロンドン） europe-west3（フランクフルト） eu-central-1（フランクフルト） us-east4（バージニア） us-east-1（バージニア北部） us-west1（オレゴン） us-west-2（オレゴン） us-west2（ロサンゼルス） us-west-1（北カリフォルニア） 参考 : ペアリング ロケーションを選択する transport リソース このサービスの中心となるのが transport リソースです。物理的な相互接続や VLAN アタッチメント、Cloud Router インスタンスをひとまとめに抽象化したマネージドサービスのリソースです。 従来の Cross-Cloud Interconnect では、こうした構成要素を 1 つずつ自分で用意して管理する必要がありました。一方の Partner Cross-Cloud Interconnect for AWS では、Google Cloud 側の transport リソースと AWS 側の Direct Connect ゲートウェイを結びつけるだけで、セキュアなマルチクラウド専用接続の確立が完了します。 Google Cloud と AWS のリソース同士を結びつけるために アクティベーションキー を使用します。起点となるクラウド側でキーを発行し、もう一方がそのキーを登録して自クラウドのリソースを作成する仕組みです。この相互連携により、プロビジョニングをどちらのクラウドからでも開始できます。 参考 : AWS 向け Partner Cross-Cloud Interconnect のプロビジョニングの概要 Cross-Cloud Interconnect との比較 Cross-Cloud Interconnect は、Google Cloud と AWS をはじめとする他社クラウドのネットワークを、専用の物理接続でプライベートに接続するサービスです。Partner Cross-Cloud Interconnect for AWS は Cross-Cloud Interconnect の発展形と位置づけられています。 従来の Cross-Cloud Interconnect では、物理回線を手配し、VLAN アタッチメントなどのネットワークリソースを自分で設定する必要がありました。Partner Cross-Cloud Interconnect for AWS ではこの工程がなくなり、接続が使えるようになるまでの時間は大きく縮まります。冗長性も基盤側にあらかじめ組み込まれているため、利用者が冗長構成を設計したり管理したりする必要はありません。 Cross-Cloud Interconnect についての詳細は、以下の記事を参照してください。 blog.g-gen.co.jp Cross-Cloud Interconnect と Partner Cross-Cloud Interconnect for AWS の主な違いは、以下のとおりです。 項目 Cross-Cloud Interconnect Partner Cross-Cloud Interconnect for AWS 接続先 OCI、AWS、Azure、Alibaba Cloud など AWS 物理的な配線工事 発生する 発生しない 物理ポート申請（LOA の取得・提出） 必要 不要 接続の発注元 Google Cloud から発注 Google Cloud または AWS の双方向 料金 Cloud Interconnect 接続・VLAN アタッチメント・下り（Egress）トラフィックに課金 transport リソースのみに課金 参考 : AWS 向け Partner Cross-Cloud Interconnect の概要 - Cross-Cloud Interconnect との比較 料金 Partner Cross-Cloud Interconnect for AWS の料金は、 transport リソースの時間単位の課金 で構成されます。transport がアクティブな時間に対して、選択した帯域とリージョンに応じた料金が発生します。 特徴は、 データ転送量に対する従量課金がない点 です。従来の Cross-Cloud Interconnect では、接続の時間課金に加えて、Virtual Private Cloud（以下、VPC）ネットワークからの下り（Egress）データ転送にも料金がかかりました。しかし、Partner Cross-Cloud Interconnect for AWS では、上り（Ingress）・下り（Egress）ともにデータ転送料金は発生しません。 なお、後述する 2 つの接続方式である VPC ネットワークピアリングと Network Connectivity Center（NCC）のどちらを選んでも、Partner Cross-Cloud Interconnect for AWS 自体の料金は変わりません。料金はあくまで transport リソースの帯域に対する時間課金で決まるためです。 ただし、料金には注意点が 2 つあります。1 つは、NCC を使用する場合、Partner Cross-Cloud Interconnect for AWS の料金とは別に NCC の利用料金が発生する点です。もう 1 つは、接続先となる AWS 側でも、AWS Interconnect（multicloud オプション）など対象サービスの料金が別途発生する点です。 詳細は以下の公式ドキュメントを参照してください。 参考 : Cloud Interconnect pricing - Partner Cross-Cloud Interconnect 参考 : Network Connectivity pricing 接続方式 接続方式の違い Partner Cross-Cloud Interconnect for AWS では、Google Cloud 側のネットワーク構成として、 VPC ネットワークピアリング を使用する方式と、 Network Connectivity Center （NCC）を使用する方式の 2 つがあります。 前者は単一の VPC ネットワークと AWS を 1 対 1 で接続するシンプルな構成、後者は複数の VPC やハイブリッド接続を集約管理する規模の大きいネットワーク向けの構成です。 参考 : AWS 向け Partner Cross-Cloud Interconnect のプロビジョニングの概要 VPC ネットワークピアリング VPC ネットワークピアリングを使用する方式は、transport リソースを単一の VPC ネットワークに接続する構成です。特定の VPC ネットワークと AWS を 1 対 1 でプライベートに接続したい場合に適しています。 transport リソースを作成すると、中継用のピアリング VPC ネットワークが自動的に生成されます。利用者は、この自動生成されたピアリング VPC ネットワークと、自身のワークロード VPC ネットワークを VPC ネットワークピアリングで接続します。これにより、ワークロード VPC（図最左部）と AWS のリソース（図右部）が、自動的に交換されるルートを通じて通信できます。構成のイメージは以下のとおりです。 VPC ネットワークピアリングを使用する場合 参考 : Google Cloud から開始する接続を作成する - VPC ネットワーク ピアリングを使用する 参考 : AWS から開始する接続を作成する - VPC ネットワーク ピアリングを使用する VPC ネットワークピアリングについての詳細は、以下の公式ドキュメントを参照してください。 参考 : VPC ネットワーク ピアリングの概要 Network Connectivity Center Network Connectivity Center（NCC）を使用する方式は、transport リソースを NCC のハブにスポークとして接続する構成です。NCC は、複数の VPC ネットワークやハイブリッド接続をハブアンドスポークのモデルで集約的に管理するためのサービスです。NCC を使用すると、複数の VPC ネットワークや他の外部接続をまたいでルートを一元的に管理できます。複数の VPC や複数のクラウド接続を統合的に扱いたい、規模の大きいネットワークに適した方式です。 なお NCC を使用する方式は 2026年8月現在、Preview ステージです。Preview ステージの機能には技術サポートや SLA が提供されないこと、また一般公開せずに終了したり、一般提供の際に仕様が変更される可能性がある点に留意してください。Preview 版のサービスや機能を使用する際の注意点は、以下の記事も参照してください。 blog.g-gen.co.jp transport リソースを NCC のハブにスポークとして接続すると、ハブが各スポーク間でルートを伝播します。これにより、ハブに接続した複数の VPC ネットワークやハイブリッド接続（オンプレミスとの接続等）と AWS との間で、ルートを一元的に交換できます。VPC ネットワークピアリング方式が単一の VPC との 1 対 1 接続であるのに対し、NCC 方式は複数のネットワークを 1 つのハブに集約できる点が大きな違いです。構成のイメージは以下のとおりです。 Network Connectivity Center を使用する場合 参考 : Google Cloud から開始する接続を作成する - Network Connectivity Center を使用する 参考 : AWS から開始する接続を作成する - Network Connectivity Center を使用する NCC についての詳細は、以下の記事を参照してください。 blog.g-gen.co.jp 2 つの方式の比較 2 つの方式の違いを以下に整理します。 観点 VPC ネットワークピアリング NCC 提供ステージ 一般公開（GA） Preview Google Cloud 側の接続先 単一の VPC ネットワーク NCC のハブ（スポークとして接続） 適した規模 単一 VPC と AWS の 1 対 1 接続 複数 VPC・複数接続の集約管理 接続の表示・更新・削除 接続の表示、更新、削除は、transport リソースを通じて行います。gcloud CLI、Google Cloud コンソールまたは API を使用します。 当記事では、gcloud CLI を使用した場合の操作を紹介します。 接続を一覧表示するには、 gcloud network-connectivity transports list コマンドを使用します。リージョンを指定すると、transport の名前、プロファイル、帯域、状態（State）が一覧で確認できます。 gcloud network-connectivity transports list \ --region = LOCATION 特定の transport の詳細を確認するには、 gcloud network-connectivity transports describe コマンドを使用します。説明（description）の更新や、広告されるルート（advertisedRoutes）の確認ができます。 transport を削除するには、 gcloud network-connectivity transports delete コマンドを使用します。 gcloud network-connectivity transports delete TRANSPORT_NAME \ --region = LOCATION transport を削除しても AWS 側のリソースは削除されません。接続を完全に解除する際は、Google Cloud 側と AWS 側の両方をクリーンアップする必要がある点に注意してください。 参考 : 接続を管理する 注意点 transport リソースにはプロジェクトごと・リージョンごとのクォータがあり、デフォルトでは各プロジェクトがリージョンあたり 1 つに制限されます。複数必要な場合は、クォータの引き上げを検討してください。 Google Cloud のワークロード VPC と AWS VPC の MTU は揃える必要があります。MTU が一致していないと、パケットのドロップやフラグメンテーションが発生します。その結果、データ損失・スループットの低下・インターコネクト全体での接続切断につながります。 VPC ネットワークピアリング方式を利用して transport リソースを作成する際、 Network MTU 1460B does not match the peer's MTU 8896B といった警告が表示されることがあります。これは、ワークロード VPC と、前述のピアリング VPC ネットワーク（8896 バイト固定）との MTU 差分を検知した警告です。ピアリング VPC ネットワークは最大値で固定されているため、この区間自体がボトルネックになることはありません。一方で、ワークロード VPC と AWS VPC の MTU は前述のとおり一致させる必要があります。この警告が表示されても、両端の MTU が揃っていれば通信に問題はありません。 SLA は、Google と AWS がそれぞれ自社の管理する接続区間に対して提供します。 各項目の詳細は、以下のドキュメントを参照してください。 参考 : Create a connection initiated from AWS with VPC Network Peering 参考 : AWS Interconnect が一般提供され、ラストマイル接続を簡素化する新しいオプションが追加されました 松尾 和哉 (記事一覧) クラウドソリューション部 これまで主にAWSを活用する企業でインフラエンジニアとして従事していました。Google Cloudに魅力を感じてG-genにジョイン。アウトプットを経てコミュニティへの還元や自己研鑽をしたいと思っています。