こんにちは。Data Ingestion チームでData Engineerをしている @orfeon です。この記事は「 Merpay & Mercoin Tech Openness Month 2026 」の14日目の記事です。 はじめに Data Ingestion(旧Data Platform)チームでは、多数のマイクロサービスが管理する データベース・テーブル から、大量のデータを継続的にDWH（データウェアハウス）へ同期する必要があります。同期対象には数億〜 数百億件 に達する大規模なテーブルも含まれ、これらをいかに速く・安全に・一貫性を保ったまま抽出するかが、DWHの鮮度や安定性にとって大事になります。 これまで  Cloud Spanner  からのデータ取得では、Spannerの分散DB特有の機能（後述）を活用することで、大規模テーブルでも高いスループットでの取得を実現できていました。 一方、社内にはTiDBやAlloyDBといったSpanner以外のデータベースも多く利用されており、その中には数百億件以上に達するテーブルもあります。 これらのテーブルは従来、主キーなどで シーク方式 で取得していましたが、単一コネクションでの シーケンシャルなデータ取得 になるため、大規模テーブルでは取得に非常に時間がかかっていました。 そこで今回、Spannerと同じように、 それぞれのDBに特有の機能を活用して並列取得などでスループットを上げる よう工夫しました。 具体的には、 TiDB  と  AlloyDB  の大規模テーブルをDWHへ同期する仕組みを  Cloud Dataflow（Apache Beam）  上に構築しました。 本記事では、その中核となる2つのSourceモジュール   TiDBSource  と  PostgresSource   について、高いスループットを実現するための工夫を解説します。 なぜ汎用JDBCではなく専用モジュールなのか Beam/Dataflowには汎用的な  JdbcIO  が既に存在します。 しかし汎用JDBCは「 SELECT を実行して結果を1行ずつ読む」という標準的な経路をたどるため、大規模テーブルでは以下のボトルネックが発生します。 1行ごとのSQL処理オーバーヘッド : 通常のクエリ実行では、サーバ側でのタプルのテキスト/プロトコル変換などが行ごとに発生する。 並列化の難しさ : テーブルを並列に読むには「どこで分割するか」を決める必要があるが、 OFFSET ベースの分割はオフセットが大きくなるほど遅くなり、フルスキャンを誘発する。 一貫性の確保 : 並列に複数コネクションから読む場合、各コネクションが別々の時点を読むと整合性が崩れる。 そこで今回のモジュールでは、 それぞれのデータベースが持つネイティブなバルク転送機構と物理的なデータ配置情報を活用 し、汎用JDBCのボトルネックを回避する設計にしました。 加えて運用上の大きなメリットとして  分割キー（フィルタ条件）の自動抽出  があります。 マイクロサービスごとに膨大なテーブルを扱う環境では、テーブル1つひとつに対して「どのカラムで分割するか」を人手で指定するのは現実的ではありません。 両モジュールはテーブルのメタデータから 主キー（PK）や暗黙の行ID、物理ブロック位置を自動で見つけ出し 、分割範囲の絞り込み条件を組み立てます。 利用者は接続先とテーブル名を指定するだけで、同じ設定が多数のテーブルに横展開することができます。 なぜCloud Spannerでは高いスループットでデータ取得が可能なのか 今回の設計の発想は、既にうまくいっていたSpannerからの取得方法を、TiDBやAlloyDBにも持ち込むことにありました。 そこでまずSpannerが大規模テーブルでも高いスループットを出せている理由を説明します。 Spannerは分散データベースとして、以下の機能を組み合わせています。 PartitionQuery / PartitionRead（Splitベースの自動分割） : Spannerはデータを内部的に  Split （キー範囲＋負荷ベース）へ分割して保持しています。 PartitionQuery  はこのSplit境界に基づいてクエリを複数のパーティションに自動分割します。クライアントはキー範囲などSplitの内部構造を意識する必要がありません。 BatchReadOnlyTransaction（スナップショット一貫性） : 全パーティションの読み取りが、 TimestampBound  で指定した同一スナップショットを参照することを保証します。ロックを取らずに一貫した読み取りができます。 Partition Tokenの分散・並列実行 : 分割結果は シリアライズ可能なPartition Token として返されるため、複数プロセス・複数マシン、そして Beam Worker に配布してそのまま並列実行できます。Apache Beamの  SpannerIO  も内部でこの仕組みを使っています。 Partition Tokenによる自動バージョン保持 : Tokenが有効な間は対象バージョンがGCされないことが保証されるため、クライアント側で明示的なバージョン保護（SafePoint管理）が不要です。 Data Boost（Spanner固有） : Google管理の独立した計算リソースで読み取るオプションで、 本番ワークロードへの影響をほぼゼロ にしつつ弾力的にスケールできます。 これらは「 物理的なデータ配置に沿った自動分割 」「 スナップショット一貫性 」「 分割単位の分散ワーカーへの配布と並列実行 」という構図で成り立っています。Spannerではこれらが高度に抽象化されたAPIとして提供されていますが、 TiDBやAlloyDB(PostgreSQL)にもそれに近いDB固有の機能が存在します 。 このSpannerの機能とTiDBやPostgreSQLの機能は以下のように対応します。 Spanner TiDB（dumpling相当） AlloyDB（PostgreSQL） PartitionQuery（Split境界で自動分割） TABLESAMPLE REGIONS() （TiKV Region境界） ctid 物理ブロック範囲（ pg_relation_size ） BatchReadOnlyTransaction（スナップショット） tidb_snapshot MVCC(Multi-Version Concurrency Control) + TSO(Timestamp Oracle） バッチ読み取り（ ctid スナップショットのズレは許容） Partition Tokenの分散実行 Range条件の分散実行（本記事の設計） Range条件の分散実行（本記事の設計） Partition Tokenによる自動GC保護 tidb_gc_life_time  の引き上げで代替 （該当なし） SpannerのSpannerIOで提供されている「分割 → 配布 → 並列スナップショット読み取り」を、TiDB/AlloyDBではDB固有の機能を組み合わせて自前で構築する、というのが本記事のモジュールの狙いです。 以降その共通の仕組みと各DB向けの実装を見ていきます。 共通アーキテクチャ 両モジュールに共通する基本戦略は次の3ステップです。  TiDBSource / PostgresSource はCloud Dataflow バッチジョブとして実行され、以下3つのステップで役割が分かれます。 テーブルの範囲分割 : 1本のコネクションでメタデータだけを取得し、テーブルを物理的な分割単位（Range）のリストに列挙する 再分配 : 分割単位をPCollectionの「種」として撒き、 Reshuffle でワーカーに再分配する 並列読み込み : 各ワーカーが担当Rangeをネイティブのバルク転送機構で並列に読み取る 以降、TiDBとPostgreSQLそれぞれについて、この3ステップの中身を掘り下げます。まずTiDBから、この3つのステップがどのように実装されるかを見ていきます。 TiDBテーブルからのデータ抽出 TiDB公式ツール dumpling に学ぶ TiDBには  dumpling  という高速なエクスポートツールが公式に提供されています。 TiDBSource の設計は、このdumplingが高スループットを実現している仕組みを参考にしています。 まずはdumpling側の要点を整理します。 テーブルのチャンク分割と並列読み取り dumplingは、1テーブルを丸ごと1クエリで読むのではなく、テーブルをチャンク（範囲）に分割し、各チャンクを独立したSELECTクエリとして並列実行します。 チャンク分割は3段階のフォールバック構造になっています。 戦略 方式 概要 A（最優先） TiKV Regionベース分割 TABLESAMPLE REGIONS()  でRegion境界をチャンク境界にする B（フォールバック） 数値インデックスベース分割 数値型PK/インデックスのMIN/MAXから均等分割 C（最終） テーブル全体ダンプ 分割可能なフィールドがない場合は1クエリ 特に重要なのが戦略Aです。 TiDBではデータがTiKV上で Region（デフォルト96MB単位） に分散配置されます。 dumplingはこのRegion境界をそのままチャンク境界として利用するため、各チャンクが異なるTiKVノードへの読み取りリクエストに分散され、クラスタ全体のI/O帯域を引き出せます。 dumplingの並列実行の仕組み: Producer-Consumer 分割したチャンクを並列に読み出すために、dumplingは内部で Producer-Consumer という構造をとります。登場人物は次の3つです（いずれもdumplingの実装に出てくる用語です）。 Producer（プロデューサ） : テーブルをチャンクに分割し、「このチャンクを読め」というタスクを作り続ける係。dumplingではメインのgoroutineが担当します。先ほどのRegion境界などをもとにタスクを生成します。 Writer（ライター） : 生成されたタスクを受け取り、実際にSELECTを発行してデータを読み出す係。 --threads で指定した数だけ並列に動き、それぞれが独立したDB接続を持ちます。タスクを消費するConsumer側にあたります。 infiniteChan（無制限チャネル） : ProducerとWriterの間をつなぐ、容量に上限のないキュー（待ち行列）。Writerの処理が詰まってもProducerがブロックされず、生成済みのタスクをいくらでも貯めておけます。 このように、タスクを作成する人（Producer）とタスクを実行する人（Writer）を分離し、その間を待ち行列（infiniteChan）でつなぐことで、分割と読み取りを互いに待たせずに並列で回す基本構造です。後述のTiDBSourceは、この役割分担をそのままDataflowの分散モデルに置き換えています。 Snapshot読み取り dumplingはTiDBのMVCC (Multi-Version Concurrency Control)機構を利用し、特定のTSO（Timestamp Oracle）時点の  スナップショット  から一貫したデータを読み取ります。 ロック不要 :  FLUSH TABLES WITH READ LOCK  のような排他ロックが不要で、書き込みをブロックしない。 一貫性保証 : 全Writerが同一時点のデータを読むため整合性が保たれる。 高スループット : ロック競合がないため並列度を上げられる。 加えてdumplingは、長時間のダンプ中にTiDBのGC（Garbage Collection）がスナップショット時点の古いバージョンを回収しないよう、PD（Placement Driver）に対してGC SafePointを登録します。 TiDBの機能を活用したDataflowでの実装 TiDBSource は、dumplingのこれらのアイデアを Apache Beam / Dataflowのモデルに移植 したものです。dumplingがgoroutineで実現していた並列性を、Dataflowの分散ワーカーによる並列性に置き換えています。対応関係は次の通りです。 dumpling TiDBSource (Dataflow) Producerがチャンクタスクを生成 パイプライン構築時に Range のリストを生成 infiniteChan  + 複数Writer goroutine Reshuffle  +  ParDo による分散ワーカー並列処理 各Writerが独立DB接続でSELECT 各ワーカーが @Setup で独自コネクションを確立 TSOスナップショット読み取り TSOを一度取得し全ワーカーに配布 ステップ1: 分割キーの決定とRangeの列挙 パイプラインの初期起動時に1本のコネクションを張り、出力スキーマの確定・スナップショットTSOの取得・テーブルの分割を行います。 ここではメタデータと境界値だけを読み、実データのスキャンは行いません。 分割キーの自動解決  は次の優先順位で行われます。利用者がカラムを指定しなくても、テーブルのメタデータから自動的に決定されます。 利用者が  splitField  を明示指定していればそれを使う なければ 単一カラムの主キー（PK） それもなければ 暗黙の行ID  _tidb_rowid （クラスタードキーを持たないテーブル向け） _tidb_rowid  は、明示的な主キーを持たないテーブルでTiDBが内部的に振る暗黙の行IDです。 これを分割キーに使えるため、主キー設計に依存せず、どんなテーブルでも分割の足がかりを得られます。 Rangeの列挙  は、先述のdumplingの戦略A→B→Cと同じ3段階フォールバックで行います。 戦略Aは、次のSQLでTiKVのRegion境界を取り出します。 SELECT `pk` FROM table TABLESAMPLE REGIONS() ORDER BY `pk` TABLESAMPLE REGIONS() は各Regionの先頭行を返すため、結果の各値が「次のチャンクの下限」になります。 境界値の列 b[1], b[2], …, b[n] から、隣り合う境界で挟まれた半開区間を生成します。 取りこぼしを防ぐため、最初の区間は下側を、最後の区間は上側を開いておきます。 chunk[ -∞, b[1] ), chunk[ b[1], b[2] ), …, chunk[ b[n], +∞ ) TABLESAMPLE REGIONS() はTiDB v5.0以降の構文です。 非TiDBのMySQLや古いTiDBではこのクエリが失敗するため、自動的に戦略B（数値MIN/MAX均等分割）へフォールバックします。 戦略Bは、SELECT MIN(pk), MAX(pk) で取得した範囲を、推定行数とチャンクあたりの目標行数 splitSize から決めた個数で等分します。 chunks = ⌈ 推定行数 / splitSize ⌉ step = (max − min) / chunks + 1 区間 = [min, min+step), [min+step, min+2·step), … , [ …, max] (stepの計算では厳密な切り上げ ⌈(max−min)/chunks⌉ ではなく+1 としています。半開区間 [cutoff, cutoff+step) で走査するため、割り切れるケースでもmax が最終チャンクに確実に含まれるようstep を 1 大きく取っており、実際のチャンク数は chunks 以下になります) ステップ2: Rangeの再分配（Reshuffle） 範囲が決まったら次にワーカーに範囲ごとの処理を並列にさせる必要があります。列挙した Range のリストを並列実行するよう明示的に指定するためにPCollection化した Range の後に、 Reshuffle.viaRandomKey()  を挟みます。  Reshuffle  には2つの重要な役割があります。 fusionの分断 : Dataflowは連続する処理を一つの処理Stageとして結合してしまうことがあります。これがないとDataflowは Create と後続の読み取り ParDo を融合し、Rangeが1ワーカーに偏って並列性が出ません。 ランダムキーによる再分配 : 全Rangeが利用可能なワーカーへ均等にばらまかれ、クラスタ全体に読み取り負荷が分散されます。 これがdumplingの「 infiniteChan から複数Writerがタスクを取り出す」構造に相当します。 ステップ3: 各ワーカーでのスナップショット並列読み取り 各ワーカーは処理開始時（ @Setup ）に自前のコネクションを確立し、パイプライン構築時に取得・配布されたTSOで  tidb_snapshot  をセットします。  全ワーカーが同一TSOを使うことで、分散読み取りでも単一時点の一貫したスナップショットになります 。 TSOの取得は、一貫スナップショットを開始してその時点の論理時刻を読むだけで完了します（トランザクション自体はすぐロールバックします）。 START TRANSACTION WITH CONSISTENT SNAPSHOT;SELECT @@tidb_current_ts; -- ← この値（TSO）を全ワーカーに配布 各ワーカー側では、読み取り前にセッション変数を設定します。 SET @@tidb_snapshot = '<配布されたTSO>'; -- ロックなしで同一MVCC版を読む SET @@session.tidb_enable_paging = ON; -- 大量スキャン時のメモリ使用量を抑制 tidb_enable_paging  はCoprocessorリクエストのメモリ使用量を抑える設定です（TiDB v6.2.0以降はデフォルト有効。変数を知らないDBではスキップ）。 実際の読み取りでは、担当Rangeを分割キーへの 値の範囲条件 に変換してSELECTに組み込みます。 SELECT * FROM table WHERE `pk` >= 1000 AND `pk` < 2000 ここで重要なのは、この条件が 主キー（インデックス）に対する値の比較 である点です。 データベースはこの行値比較を使ってインデックスを シーク し、該当範囲の先頭へ直接ジャンプして必要な行だけを読みます。  OFFSET のように先頭から数え直す必要がないため、どのチャンクも一定コストで読み出せます。 また、読み取りはMySQL Connector/Jの 行単位ストリーミングモード （ fetchSize = Integer.MIN_VALUE ）で行います。 これは結果セット全体をワーカー側メモリにバッファせず1行ずつ取り出す特別な設定で、巨大チャンクでもワーカーのメモリ消費が一定に保たれます。 dumplingがgo-sql-driver/mysqlのストリーミング動作で実現しているのと同じ効果を、JDBC側で引き出している形です。 制約: GC SafePoint dumplingはPDクライアント経由でGC SafePointを登録しますが、これは JDBCコネクションからは到達できません。 そのためTiDBSourceではSafePoint登録を行わず、長時間の読み取りに対しては運用側でクラスタの tidb_gc_life_time を引き上げ、読み取り中にGCがスナップショットのバージョンを回収しないようにする運用方針としています。 AlloyDB（PostgreSQL）テーブルからのデータ抽出 AlloyDBとPostgreSQL互換性 AlloyDBは、Google CloudがPostgreSQL互換で提供するフルマネージドのデータベースサービスです。  ワイヤプロトコルもSQLの方言もPostgreSQLと互換 であるため、クライアントから見ればPostgreSQLそのものとして扱え、標準のPostgreSQL JDBCドライバがそのまま使えます。 さらに  ctid （物理行位置）や  COPY 、 pg_relation_size  といったPostgreSQLの内部機能・システムカタログも利用できます。 したがって、AlloyDBからのデータ抽出は  PostgreSQLの機能を前提に設計できます 。 以下では PostgresSource がPostgreSQLのどの機能を使っているかを説明しますが、その内容は基本的にAlloyDBにも当てはまります。 通常のJDBCクエリ取得との違い PostgresSource も「物理的な分割 → 並列読み取り」という骨格はTiDBと同じですが、データ転送経路とテーブル分割の方式 がPostgreSQL固有の機能に最適化されています。 まず、通常のJDBC経由のクエリ取得との違いを整理します。 観点 通常のJDBC ( SELECT ) PostgresSource ( COPY ... TO STDOUT BINARY ) 転送経路 拡張クエリプロトコル COPYプロトコル（バルク転送専用） 行ごとの処理 パース/プラン/結果整形が走りうる クエリは1回プラン。あとはタプルを連続送出 データ形式 テキスト or バイナリのフィールド単位 バイナリのタプルストリームを直接デコード 並列分割 OFFSET / LIMIT 等（大きいほど低速） ctid 物理ブロック範囲（フルスキャン不要） PostgreSQLの COPY は、もともと大量データのインポート/エクスポートのために用意された専用経路で、通常のクエリ実行に伴う1行ごとのオーバーヘッドを回避できます。 PostgresSource はJDBCドライバの CopyManager API（PGCopyInputStream）を使い、COPY (SELECT …) TO STDOUT (FORMAT BINARY) のバイナリ出力ストリームを受け取って、Avroのレコードへ直接デコードします。 中間のテキスト変換を挟まないぶん、CPU負荷とアロケーションを抑えられます。 PostgreSQLの機能を活用したDataflowでの実装 ステップ1: ctidブロック範囲の列挙 PostgreSQLの全タプルには ctid（物理的な行ロケーション = (ブロック番号, ブロック内オフセット)）が付与されています。 PostgresSource はテーブルを 物理ブロック範囲 で分割し、各範囲を TID range scan で読みます。 分割の計画には実データのスキャンが一切不要です。 ブロック数は、テーブルの実ディスクサイズをブロックサイズで割って求めます。 SELECT pg_relation_size('table'::regclass) / current_setting('block_size')::bigint pg_relation_size  は実ディスクサイズを返すため、統計情報の  pg_class.relpages  推定値よりも正確で、しかもstat呼び出し1回で済みます。 1ブロックあたりの行密度は推定行数（ pg_class.reltuples ）から求め、目標行数  splitSize  に対応するブロック幅を機械的に算出します。  [0, blockCount)  をこの幅で割っていくだけなので、 フルスキャンも OFFSET も不要 です。 行密度 = 推定行数 / ブロック数1範囲のブロック幅 = max(1, round( splitSize / 行密度 )) 範囲 = [0, w), [w, 2w), … , [kw, blockCount) ※最後の範囲は上限を開く 最後の範囲を上限なし（オープンエンド）にしておくことで、分割を計画した後に追記された行も読み取れます。各範囲は ctid の半開区間条件に変換されます。 WHERE ctid >= '(0,0)'::tid AND ctid < '(3,0)'::tid この条件も、TiDBの主キー範囲と同様に物理位置の値による範囲比較です。 PostgreSQL 14以降ではこれが TID range scan として処理され、該当ブロックへ直接シークして必要な範囲だけを読みます。 注意点 :  ctid  は物理的な行位置なので、読み取り中にINSERT/UPDATE（別ページへの移動）/VACUUMが起きると、同じ行を二重に読んだり取りこぼしたりする可能性があります。同期中に更新されないテーブルに対して使うか、バッチ読み取りで一般的なスナップショットのズレを許容する前提で利用します。また、TID range scanはPostgreSQL 14以降のサポートで、それ以前のバージョンでは各範囲がシーケンシャルスキャンにフォールバックします。 ステップ2: Rangeの再分配 TiDBと同様、RangeのリストをCreateで撒き、Reshuffle.viaRandomKey()でワーカーへ再分配します。fusion分断と負荷分散の狙いは同じです。 ステップ3: 各ワーカーでのバイナリCOPY並列読み取り 各ワーカーは、担当Rangeのctid条件を組み込んだSELECTを COPY (…) TO STDOUT (FORMAT BINARY) でラップし、バイナリストリームを受け取ります。 COPY (SELECT * FROM table WHERE ctid >= '(0,0)'::tid AND ctid < '(3,0)'::tid)TO STDOUT (FORMAT BINARY) 返ってくるのはPostgreSQLのCOPYバイナリフォーマットです。 PostgresSource はこれを直接パースします。 先頭の固定シグネチャ（ PGCOPY\n\377\r\n\0 ）とヘッダを読み飛ばし、以降はタプルを1件ずつ読みます。 各タプルは「フィールド数」に続いて、フィールドごとに「長さ（ -1 はNULL）＋値のバイト列」が並ぶ構造で、終端は番兵値（フィールド数 =  -1 ）で示されます。 値のデコードは、PostgreSQLのバイナリ表現をAvroの値へ型ごとに変換します。たとえば次のような処理です。 整数・浮動小数: ビッグエンディアンでそのまま読む numeric : base-10000 のdigit配列から十進数を復元 date  /  timestamp : PostgreSQLエポック（2000-01-01）基準の値をUnixエポック基準へ補正 uuid  /  json  /  jsonb  /  bytea : それぞれの専用処理 これらをドライバのテキスト変換を介さず自前でデコードすることで、転送経路を最短化しています。 なお、IAM認証（Cloud SQL / AlloyDB）にも対応しており、 user 未指定時はワーカーのサービスアカウントをDBユーザとして使い、接続URLに  enableIamAuth=true  を自動付与します。 検証用の12つのカラムを持つ6億件のダミーテーブルデータをAvroファイルとしてGCSに出力するタスクで、6コア並列で8分で処理完了するようになりました。 制約: なぜTiDBSourceのようにワーカー間の一貫性を担保できないのか TiDBSource では tidb_snapshot によって全ワーカーが同一時点を読み、ワーカー間の一貫性を担保していました。一方の PostgresSource では、各 ctid レンジが それぞれ独立したトランザクションで読まれる ため、レンジ間（別接続・別時刻）での一貫性は保証されません。読み取り中にINSERT/UPDATE（ ctid が別ページへ移動）/VACUUMが起きると、レンジをまたいで行の重複や欠落が起こりえます。 PostgreSQLにも一見すると同等の仕組みがあります。 pg_dump の並列モードは、 pg_export_snapshot() でスナップショットをエクスポートし、各ワーカーが SET TRANSACTION SNAPSHOT でそれを取り込むことで、ワーカー間の一貫性を担保しています。 PostgresSource で同じことを今回実現できなかった理由は スナップショットの「寿命」の違い にあります。 TiDB（ tidb_snapshot ） PostgreSQL( pg_export_snapshot() ) 実体 TSO（論理タイムスタンプ＝ただの数値） エクスポート元トランザクションに紐づくスナップショットID 寿命 永続的 （GCされるまで。トランザクション非依存） 一時的 （エクスポート元トランザクションが開いている間だけ有効） 共有方法 数値を渡し、各セッションが独立に SET 元トランザクションが生存中に各セッションが SET TRANSACTION SNAPSHOT で取り込む PostgreSQLのエクスポートされたスナップショットは、 それをエクスポートしたトランザクションが終了するまでしかインポートできません 。 pg_dump の並列モードが成立するのは、単一プロセスのリーダーがダンプ全体の間ずっとエクスポート元トランザクションを開いたまま保持し、自身でワーカーを起動するからです。 PostgresSource が動くCloud Dataflowの実行モデルでは、元トランザクションを 並列読み取りの全期間にわたって保持する場所を確保するのが難しかったのです 。TiDBSourceではランチャーでTSO（数値）がトランザクションと無関係に有効だったためワーカーに配るだけで済みました。 そのため PostgresSource では各レンジ独立読み取りを前提とし、「同期中に更新されないテーブルに対して使う／バッチ読み取りで一般的なスナップショットのズレを許容する」という運用方針にしています。 まとめ: 高スループットを支える設計要素 両モジュールでは、 「テーブルの物理的なデータ配置に沿って分割し、その分割単位を分散ワーカーで並列に読み取る」  という共通する設計思想で実装しました。 以下  SpannerSource （SpannerのPartitionQuery等を活用したモジュール）も加えた各設計要素の比較表です。すでにいずれかのDBに親しんでいる人は別のDBの機能と比較することで関心・理解が深まるかもしれません。 要素 SpannerSource TiDBSource PostgresSource 物理分割の基準 Split境界（ PartitionQuery ） TiKV Region境界（ TABLESAMPLE REGIONS() ） ctid 物理ブロック範囲（ pg_relation_size ） 分割キーの自動抽出 Spannerが自動分割（指定不要） PK /  _tidb_rowid  を自動解決 ctid （全テーブル共通） 分割計画のコスト API呼び出しのみ（フルスキャン不要） 境界キーの列挙のみ（フルスキャン不要） stat呼び出しのみ（フルスキャン・ OFFSET 不要） 範囲の読み取り Partition Tokenを実行 PK値の範囲比較でインデックスをシーク ctid の範囲比較でTID range scan 転送機構 gRPCストリーミング（ executeStreamingSql ） ストリーミングResultSet（ fetchSize=MIN_VALUE ） バイナリCOPY（ COPY ... TO STDOUT BINARY ） 一貫性 BatchReadOnlyTransaction （ TimestampBound ） tidb_snapshot によるMVCCスナップショット バッチ読み取り（ ctid スナップショットのズレは許容） 並列化 Partition Tokenを Reshuffle  +  ParDo で分散 Reshuffle  +  ParDo （dumplingのWriter並列に相当） Reshuffle  +  ParDo バージョン保護 Partition Tokenで自動保持 tidb_gc_life_time  の引き上げで代替 （該当なし） フォールバック Partition Query → 通常Query Region → 数値MIN/MAX → 全体 TID range scan → シーケンシャルスキャン（PG14未満） 汎用JDBCに対する優位性は、(1) 分割キーを自動抽出でき、分割計画も安価なので並列度を素直に上げられること、(2) 各ワーカーの転送がネイティブ機構でCPU/メモリ効率が高いこと、(3) DB固有のスナップショット機構で一貫性を担保できること(TiDB) の3点に整理できます。これらはもともとSpannerSourceがSpannerの機能で実現していた特性を、今回 TiDB / PostgreSQL 固有の機能を組み合わせて再現したものになります。 おわりに 多数のマイクロサービスが抱える大量のテーブルをDWHへ同期するという要件に対し、汎用的なJDBC経路ではなく、TiDBとPostgreSQL（AlloyDB）それぞれの  分散ストレージアーキテクチャや物理データ配置を活かした専用Sourceモジュール  をCloud Dataflow上に実装しました。これは、すでにSpannerからの取得で高スループットを実現できていた「分割 → 配布 → 並列スナップショット読み取り」というパターンを、他のDBにも横展開した取り組みと言えます。 今回は各DBが公式ツール（ dumpling  / pg_dump ）で利用されている高速化のノウハウを参考にさせてもらい、Dataflowの分散実行モデルに取り込みました。「分割キーの自動抽出」「物理配置に沿った安価な分割」「ネイティブなバルク転送」「DB固有のスナップショット」という要素の組み合わせが、大規模テーブルでも高いスループットと一貫性を両立させる助けになりました。 次の記事は cyan さんの「Scaling Myself: How I Run 22 Claude Code Sessions for DS4 Migration」です。引き続きお楽しみください。

G-gen の武井です。当記事では、Google Cloud のセキュリティ対策を観点ごとに整理し、網羅的にまとめます。 はじめに 全体像 証跡管理 概要 関連サービス・機能 Cloud Audit Logs Cloud Logging Cloud Asset Inventory 予防的統制（統制の基盤を整備する） 概要 関連サービス・機能 組織（Organization） 階層構造 組織を使わないリスク 予防的統制（ID・認証基盤を整備する） 概要 関連サービス・機能 Google Workspace / Cloud Identity MFA / パスキー Workforce Identity Federation（外部 IdP 連携） Workload Identity Federation（ワークロード間の認証） 予防的統制（コンソール・API へのアクセスを制御する） 概要 関連サービス・機能 Chrome Enterprise Premium Identity-Aware Proxy Access Context Manager Context-Aware Access VPC Service Controls 予防的統制（最小権限の原則を徹底する） 概要 関連サービス・機能 Identity and Access Management（IAM） Privileged Access Manager（PAM） 拒否ポリシー（Deny policies） 予防的統制（組織横断で一貫した統制を適用する） 概要 関連サービス・機能 組織のポリシー（Organization Policy） カスタム制約（Custom Constraints） タグ（Tags） 予防的統制（ネットワークレベルで防御する） 概要 関連サービス・機能 Cloud NGFW（Next Generation Firewall） Cloud Armor Cloud NAT Secure Web Proxy Cloud IDS 予防的統制（データを暗号化・保護する） 概要 関連サービス・機能 Cloud KMS Cloud HSM / Cloud EKM Sensitive Data Protection VPC Service Controls（再掲） Certificate Authority Service Certificate Manager 予防的統制（コンテナやコードの安全性を担保する） 概要 関連サービス・機能 Artifact Registry / Artifact Analysis Binary Authorization GKE セキュリティ機能 Software supply chain security 発見的統制 概要 関連サービス・機能 Security Command Center IAM Recommender（Active Assist） Cloud Monitoring Google SecOps（SIEM / SOAR） Mandiant 是正的統制 概要 関連サービス・機能 Config Controller Eventarc + Cloud Run functions / Workflows Google SecOps（SOAR） 経済的統制 概要 関連サービス・機能 Cloud Billing 予算アラート Spend Caps コスト異常検知（Anomaly Detection） Quotas（割り当て） 生成 AI 特有のセキュリティ 概要 生成 AI 基盤の選択 関連サービス・機能 Model Armor Agent Identity Agent Gateway / Agent Registry AI Protection（Security Command Center） Google Workspace はじめに Google Cloud にはセキュリティに関連するサービスが数多く存在します。しかし、いざ Google Cloud 環境をセキュアにしたいと考えたとき、どのサービスをどう組み合わせればよいかを俯瞰的に把握するのは容易ではありません。 当記事では、 セキュリティ上の観点 （何を守りたいか、何を実現したいか）を軸にサービスを分類し、それぞれの課題に応じて必要なサービスを素早く特定できることを目指します。 全体像 当記事では、Google Cloud のセキュリティサービスを以下の5つに分類して解説します。 # 分類 概要 1 証跡管理 「いつ・だれが・何を・どのように」操作したかを記録し、追跡を可能にする 2 予防的統制 不適切な操作や攻撃を未然に防ぐ。 アクセス制御・認証・暗号化・ネットワーク防御等 3 発見的統制 セキュリティ事象や設定ミスを速やかに検知し、可視化する 4 是正的統制 不適切な状態が発生した際に自動的に修復し、あるべき状態を維持する 5 経済的統制 クラウド利用料金の異常な増加から組織を保護する（EDoS 対策を含む） また、各分類に該当する Google Cloud のサービスについては以下のとおりです。 # 目的（分類） 該当サービス 1 操作ログ・資産情報を記録する （証跡管理） ・Cloud Audit Logs ・Cloud Logging ・Cloud Asset Inventory 2 統制の基盤を整備する （予防的統制） ・組織（Organization） ・階層構造 3 ID・認証基盤を整備する （予防的統制） ・Google Workspace / Cloud Identity ・MFA・パスキー ・Workforce Identity Federation ・Workload Identity Federation ・Secret Manager 4 コンソール・API へのアクセスを制御する （予防的統制） ・Chrome Enterprise Premium ・Identity-Aware Proxy ・Access Context Manager ・Context-Aware Access ・VPC Service Controls 5 最小権限の原則を徹底する （予防的統制） ・Identity and Access Management ・Privileged Access Manager ・拒否ポリシー 6 組織横断で一貫した統制を適用する （予防的統制） ・組織のポリシー ・カスタム制約 ・タグ 7 ネットワークレベルでの防御を行う （予防的統制） ・Cloud NGFW ・Cloud Armor ・Cloud NAT ・Secure Web Proxy ・Cloud IDS 8 データを暗号化・保護する （予防的統制） ・Cloud KMS ・Cloud EKM ・Cloud HSM ・Sensitive Data Protection ・VPC Service Controls ・Certificate Authority Service ・Certificate Manager 9 コンテナやコードの安全性を担保する （予防的統制） ・Artifact Registry / Artifact Analysis ・Binary Authorization ・GKE セキュリティ機能 ・Software supply chain security 10 脅威・設定ミスを把握する （発見的統制） ・Security Command Center ・IAM Recommender（Active Assist） ・Cloud Monitoring ・Google SecOps（SIEM / SOAR） ・Mandiant 11 不適切な状態を修復する （是正的統制） ・Config Controller ・Eventarc + Cloud Run functions / Workflows ・Google SecOps（SOAR） 12 クラウドの利用料金を保護する （経済的統制） ・Cloud Billing 予算アラート ・Spend Caps ・コスト異常検知 ・Quotas なお、近年トピックとして重要性が増している 生成 AI 特有のセキュリティ については、独立した章で解説します。 証跡管理 概要 証跡管理 とは、「いつ・だれが・何を・どのように」操作したかを記録し、いつでも追跡可能な状態にしておくための取り組みで、インシデント発生時の原因究明、内部監査・外部監査への対応、内部統制（J-SOX 等）において重要な要素となります。 Google Cloud では、 Cloud Audit Logs が API 操作の監査証跡を自動的に記録し、それらを集約・保管する基盤として Cloud Logging があります。 さらに Cloud Asset Inventory によって、リソース構成の変更履歴を時系列で追跡できます。 関連サービス・機能 Cloud Audit Logs Cloud Audit Logs とは、Google Cloud 上で発生した管理操作・データアクセス・システムイベント等を記録する監査ログサービスです。 Cloud Audit Logs には、以下の4種類のログがあります。 # 名称 説明 料金 デフォルト 1 管理アクティビティ監査ログ リソースに対する管理的な更新系の API リクエストが記録される 無料 有効（無効化できない） 2 データアクセス監査ログ リソースやデータに対する更新系・読み取り系の API リクエストが記録される。有効化するとログ容量が大きくなる可能性があるため注意 有料 無効（BigQuery のみデフォルト有効） 3 システム イベント監査ログ ユーザではなくGoogle Cloudサービスによって行われたリソース構成変更が記録される 無料 有効（無効化できない） 4 ポリシー拒否監査ログ セキュリティポリシー違反（VPC Service Controls や組織のポリシー等）によって拒否された API リクエストが記録される 有料 有効（除外フィルタ設定可能） 特に注意したいのが データアクセス監査ログ です。有効化するとログ量が膨大になり Cloud Logging の料金に影響するため、機密データを扱う API・サービスに絞ってデータアクセス監査ログを有効化するのも一案です。 参考 : Cloud Audit Logsを解説。Google Cloudの証跡管理 - G-gen Tech Blog Cloud Logging Cloud Logging とは、Google Cloud 上のあらゆるログを収集・保管・分析するための基盤サービスで、以下の機能によって構成されます。前述の Cloud Audit Logs もここに集約されます。 特にログシンクは、長期保管目的での Cloud Storage 連携、BigQuery を使った分析、後述の Google SecOps 等 SIEM への連携の起点となる重要な機能です。 # 機能 説明 1 ログエクスプローラ ログクエリ言語による高速なログ検索 2 ログバケット ログエクスプローラでログを可視化するための専用ストレージ 3 ログシンク ログを Cloud Storage、BigQuery、Pub/Sub 等へ転送する機能 4 ログベースのアラート 特定のログパターン検知時のアラート発報 5 ログベースのメトリクス ログから定義可能なカスタムメトリクス 参考 : Cloud Loggingの概念と仕組みをしっかり解説 - G-gen Tech Blog Cloud Asset Inventory Cloud Asset Inventory とは、Google Cloud 上のリソース構成、IAM ポリシー、組織のポリシー等のメタデータを、時系列のスナップショットとして保存・検索できるサービスです。 本サービスは無料で利用できる他、主に以下の用途で利用する機会が多いです。 # 用途 説明 1 資産棚卸 現在のリソース構成を CSV / JSON 等で一括エクスポート （監査・コンプライアンス対応で利用） 2 構成変更履歴の追跡 リソースの状態を時系列で保持し、過去のある時点の構成を確認可能 3 リソース横断検索 組織内のフォルダ、プロジェクトを横断したリソース検索 4 IAM ポリシーの検索 「誰が、どのリソースに、どの権限を持っているか」の俯瞰 5 変更通知 リソース変更時に Pub/Sub へ通知を送信し、後続処理のトリガーとして利用 これらのうち、リソース構成のスナップショット保存・変更履歴の追跡は証跡管理に該当しますが、変更通知を起点とした 設定ドリフトの検知 は発見的統制、それを受けての 自動修復 は是正的統制の観点から後述します。 参考 : Cloud Asset Inventoryを徹底解説！ - G-gen Tech Blog 予防的統制（統制の基盤を整備する） 概要 Google Cloud を組織的に利用するにあたり、最初に行うべきは 組織（Organization）の作成 です。 組織は Google Cloud 環境を統制ならびに管理するためのリソースで、後述する IAM、組織のポリシー、VPC Service Controls、Security Command Center など、ほぼすべてのセキュリティ施策の前提となります。 組織がなくても Google Cloud を利用できますが、その場合、組織的な統制やガバナンスに必要な機能の多くが利用できません。企業や官公庁で Google Cloud を利用する場合、組織の構成は必須といえます。 関連サービス・機能 組織（Organization） 組織（Organization）とは、Google Cloud リソースの階層構造における最上位のリソースです。組織は Google Workspace または Cloud Identity のドメインと 必ず 1:1 で紐づきます。 例えば my-domain.com という Google Workspace ドメインがある場合、自動的に my-domain.com という組織リソースが作成されます。このように、Google Workspace を利用している組織では、Google Workspace のドメインに紐づく形で Google Cloud 組織が自動的に作成されます。 Google Workspace を利用していない場合でも、Cloud Identity（Free エディションは 50 アカウントまで無料）を登録することで組織が作成できます。 参考 : Google Cloudの組織(Organization)を徹底解説 - G-gen Tech Blog 参考 : Cloud Identityの登録・組織作成手順 - G-gen Tech Blog 階層構造 組織作成後は、 フォルダとプロジェクト で構成されるリソースの階層構造（ツリー構造）を設計します。 リソース 役割 プロジェクト Google Cloud リソースの最も基本的な管理単位（AWS でいうアカウントに相当） フォルダ プロジェクトを部署、環境区分（本番・開発）、サービスなどの単位でグルーピングするためのリソース 階層構造はセキュリティの観点で非常に重要です。組織機能を使って複数プロジェクトを 組織下に束ねる ことにより、組織のポリシーや IAM、VPC Service Controls などの統制を、リソースツリーの親から子へ 継承 （inheritance）の性質を活かして適用できるため、現実的な工数で効果的かつ効率的な統制が実現できます。 組織を使わないリスク 組織を使用しない場合、前述の通り組織的な統制やガバナンスに必要な機能の多くが利用できません。また、個人の Gmail アカウントなどによる「野良プロジェクト」の存在を許すことになり、意図しないセキュリティ事故のリスクが高まります。 そのため、Google Cloud を利用する場合は、たとえ最初は Google Cloud プロジェクトを1つしか使わない場合でも、 将来の拡張性も見込んで最初から組織を作成しておき 、組織下でプロジェクトを管理することが望ましいと言えます。 予防的統制（ID・認証基盤を整備する） 概要 組織の次は Google アカウント（ユーザー ID）と認証 を整備します。「誰が Google Cloud を利用できるのか」「どのように本人確認を行うのか」を明確にすることは、すべてのアクセス制御の基本となります。 関連サービス・機能 Google Workspace / Cloud Identity 前述の通り、組織で Google Cloud を利用する場合、Google アカウントやグループは Google Workspace もしくは Cloud Identity で作成・管理 します。 アカウントは 1 人に 1 つ発行することを原則とし、共用アカウントの利用はパスワード漏洩や監査ログからの実行者特定の困難さにつながるため避けるべきです。 また、メンバーの異動・退職時の管理等、運用効率とセキュリティを加味し、Google グループで役割ごとにアカウントをグルーピングし、グループ単位で IAM ロールを付与することが推奨されます。 参考 : Google Cloudの利用に必要なGoogleアカウントを徹底解説！ - G-gen Tech Blog MFA / パスキー Google アカウントの認証強度を高めるため、 2 段階認証の有効化 が推奨されます。特に管理者アカウントには、フィッシング耐性の高いセキュリティキー（FIDO2）やパスキーの利用が強く推奨されます。Google Workspace や Cloud Identity の管理コンソールから、組織単位で 2 段階認証を必須化できます。 参考 : 2 段階認証プロセスを導入する Workforce Identity Federation（外部 IdP 連携） Workforce Identity Federation とは、OIDC や SAML 2.0 に対応した IdP（ID プロバイダ。Microsoft Entra ID や Okta 等）を利用するユーザーに、Google Cloud コンソールや Google Cloud リソースへのアクセスを提供する機能です。 外部 IdP 経由でシングル サインオン（SSO）を行い、Google Cloud コンソールにアクセスできるため、Google アカウントの作成は不要です。 参考 : SAMLでGoogle Cloudにシングルサインオンする方法（Workforce IdentityによるOktaからのSSO） - G-gen Tech Blog Workload Identity Federation（ワークロード間の認証） Workload Identity Federation とは、AWS や Azure 、あるいは GitHub Actions 等、外部のワークロードから Google Cloud の API を呼び出す際に、サービスアカウントキーを使わずに認証を行う仕組みです。サービスアカウントキーの発行と管理に伴うセキュリティリスクを排除できます。 参考 : キーを使用せずに AWS から Google Cloud にアクセスする方法 - G-gen Tech Blog 参考 : GitHub Actions を使って Google Cloud 環境に Terraform を実行する方法 - G-gen Tech Blog 予防的統制（コンソール・API へのアクセスを制御する） 概要 Google Cloud コンソール（Web UI）や gcloud コマンド、API へのアクセスを、接続元の IP アドレスやデバイスの状態などの条件に基づいて制限したいケースがあります。たとえば「社内ネットワークからのみ操作を許可したい」「会社承認のデバイスからのみアクセスさせたい」といった要件です。 関連サービス・機能 Chrome Enterprise Premium Chrome Enterprise Premium （以下、CEP）とは、Chrome ブラウザを前提とした Google のゼロトラスト（社内ネットワークの内側であっても無条件に信頼せず、アクセスのたびに検証する考え方）ソリューションです。 VPN を使わずに、ユーザー ID、接続元 IP アドレス、デバイス情報といった コンテキスト （背景情報）に基づき、Google Cloud をはじめ、社内システムや SaaS などへのアクセス制御を行います。 なお、CEP の主要な構成要素は以下のとおりです。 コンポーネント 概要 役割 Identity-Aware Proxy リバースプロキシ 社内システムなど接続を中継する Google Cloud 上の仕組み（フルマネージド） Identity and Access Management（IAM） 権限管理機構 Google アカウントなどのプリンシパルと権限を紐づける仕組み Access Context Manager ルールエンジン デバイス情報、アカウント情報、接続状況など各種背景情報からアクセス可否を判断する仕組み Endpoint Verification エンドポイントエージェント ユーザーのデバイス情報を収集する Google Chrome 拡張機能 参考 : Chrome Enterprise Premium（旧BeyondCorp Enterprise）を徹底解説 - G-gen Tech Blog Identity-Aware Proxy CEP の構成要素である Identity-Aware Proxy （以下、IAP）はフルマネージドのリバースプロキシサービスです。 主な利用用途としては、Google Cloud 上で稼働する Web アプリケーションへのアクセス制御や、踏み台サーバ無しでの VM マシンに対する Google アカウントを用いたログイン制御があげられます。これら IAP の基本機能については、Google Cloud ユーザーであれば無料で利用できます。 IAP が中継を許可するかどうかは、後述の IAM や Access Context Manager で定義したルールに基づきアクセス可否が判断されるため、サービスを安全に利用することができます。 参考 : 踏み台サーバはもういらない。IAP(Identity-Aware Proxy)の便利な使い方 - G-gen Tech Blog Access Context Manager 同じく CEP の構成要素である Access Context Manager （以下、ACM）は、ユーザー情報、接続元 IP アドレス、デバイス情報（OS バージョン、暗号化の有無など）、地理的な場所などのコンテキスト情報を アクセスレベル （条件）として管理するためのルールエンジンです。定義したアクセスレベルは、Chrome Enterprise Premium や VPC Service Controls と組み合わせて使用します。 参考 : Access Context ManagerでGoogle CloudコンソールとAPIへのアクセスを制限する Context-Aware Access Google Workspace にも前述同様の機能として Context-Aware Access （以下、CAA）がありますが、機能面に差はなく、呼称の違いと捉えていただいて構いません。 両者ともに共通の API（Access Context Manager API）を使用しており、ACM（Google Cloud）で作成したアクセスレベルは、CAA（Google Workspace）側にも自動的に共有されます。 Google Workspace では、Gmail、Google Drive、Gemini といった各種アプリケーションに対するアクセス条件として使用できます。 参考 : コンテキストアウェアアクセスでGoogle Workspaceのセキュリティを強化してみた - G-gen Tech Blog VPC Service Controls VPC Service Controls とは、Google Cloud 上の機密データやサービスを保護し、意図しないデータ流出やデータアクセスを防ぐための機能です。主に機密データを取り扱うプロジェクトにおいて多く実装され、情報漏洩リスクの軽減に寄与します。 具体的には、 サービス境界 という論理的な囲いを設け、信頼できるネットワークや認証情報以外からの API リクエストを制限します。 アクセス条件の部分については前述の ACM との組み合わせも可能で、ACM で定義した背景情報にもとづく API アクセス制御の実現も可能です。 参考 : VPC Service Controlsを分かりやすく解説 - G-gen Tech Blog 参考 : VPC Service Controlsのリソース構成を図解 - G-gen Tech Blog 予防的統制（最小権限の原則を徹底する） 概要 Google Cloud のリソースに対して「誰が」「何をできるか」を適切に管理することは、セキュリティの根幹です。最小権限の原則（必要最小限の権限付与）を徹底することで、内部不正や設定ミスによるリスクを低減できます。 関連サービス・機能 Identity and Access Management（IAM） Identity and Access Management （以下、IAM）とは Google Cloud リソースに対するアクセス制御を司る仕組みです。「誰（プリンシパル＝ユーザーやグループ、サービスアカウントなどの操作主体）が」「どのリソースに対して」「何をできるか（ロール・権限）」を管理します。事前定義ロール、カスタムロール、基本ロールの使い分けや、後述する拒否ポリシー（Deny policies）で強制的な権限制限も可能です。 参考 : Google CloudのIAMを徹底解説！ - G-gen Tech Blog 参考 : Google CloudのIAMで最小権限の原則を実現する方法 - G-gen Tech Blog Privileged Access Manager（PAM） Privileged Access Manager （PAM）は IAM ロールを一時的に付与するための仕組みです。IAM は恒久的な権限付与ですが、PAM は承認フローを含むジャスト・イン・タイム（JIT）アクセスを実現し、常時特権を保持することによるリスクを低減できます。 参考 : Privileged Access Manager（PAM）を解説！ - G-gen Tech Blog 拒否ポリシー（Deny policies） 拒否ポリシー とは、特定のプリンシパルが特定の権限を使用することを強制的に禁止できる IAM の機能です。拒否ポリシーは 許可ポリシーよりも優先して評価 されるため、たとえ IAM ロールを通じて権限を持っていても、拒否ポリシーで禁止されている操作は実行できません。 例えば、何らかのロールによって resourcemanager.projects.delete 権限を持ったユーザーがいたとしても、拒否ポリシーによって当該操作を実行できるのはプロジェクト管理自動化ジョブに紐づくサービスアカウントのみとし、それ以外のプリンシパルによる操作を禁止するといった制御が可能です。 参考 : Google CloudのIAMにおけるDenyポリシーを解説 - G-gen Tech Blog 予防的統制（組織横断で一貫した統制を適用する） 概要 組織に複数のプロジェクトが存在する環境では、各プロジェクトに対し、組織として一貫したルールやガードレール（逸脱を防ぐための共通の制約・歯止め）の適用が必要不可欠です。 例えば、「特定のリージョン以外でリソースを作成させない」、「Cloud Storage バケットを公開設定にさせない」、「サービスアカウントキーを作成させない」といった統制を、IAM とは別のレイヤから強制的に適用するための仕組みが 組織のポリシー です。 組織のポリシーは、組織・フォルダ・プロジェクトといったリソース階層の上位から下位へ 継承 することができるので、リソース階層の設計（前述）と組み合わせることで、現実的な工数で組織横断のガバナンスを実現できます。 関連サービス・機能 組織のポリシー（Organization Policy） 組織のポリシー （Organization Policy）とは、組織・フォルダ・プロジェクトに対してガードレールを設定し、Google Cloud リソースの利用方法に制約を課す仕組みです。 IAM が「誰が何をできるか」を制御するのに対し、組織のポリシーは 「組織として何を許容し、何を許容しないか」 を制御します。 例えば、以下のような統制が可能です。 制約名 役割 gcp.resourceLocations リソースを作成できるリージョンを限定する storage.publicAccessPrevention Cloud Storage の公開アクセスを禁止する compute.vmExternalIpAccess 外部 IP アドレスを持つ VM の作成を禁止する iam.disableServiceAccountKeyCreation サービスアカウントキーの作成を禁止する 組織のポリシーは Google Cloud があらかじめ用意した 制約 （Constraint）から選択して適用します。 組織・フォルダで設定したポリシーは下位リソースに継承されるため、組織レベルで共通的なガードレールを定義し、必要に応じてフォルダ・プロジェクトレベルで上書きするという運用が可能です。 参考 : 組織のポリシーを解説 - G-gen Tech Blog カスタム制約（Custom Constraints） カスタム制約 （Custom Constraints）とは、Google Cloud があらかじめ用意した組織ポリシーの制約だけでは要件を満たせない場合に、独自のポリシー条件を CEL （Common Expression Language）で定義し、組織のポリシーとして適用できる機能です。 例えば「VM のマシンタイプは n2-standard シリーズのみ許可する」、「Cloud Storage バケット名に特定のプレフィックスを必須にする」といった、組織固有の要件に応じた統制が実現できますが、サポートサービスが限定されている点には注意が必要です。 参考 : カスタム制約の作成と管理 タグ（Tags） タグ （Tags）は、組織またはプロジェクトレベルで定義したキーバリューペアをリソースに紐づけ、 ガバナンス・統制の条件として利用するための機能 です。 具体的には、IAM ポリシーの条件（Condition）や組織のポリシーの条件付き制約として利用でき、タグを軸とした条件付きの統制を実現できます。 似た機能として ラベル （Labels）があり、いずれもキーバリューの文字列ペアという性質は共通しますが、別の機能です。 最も重要な違いは、タグはそれ自体がリソースとして扱われるため、組織横断のリソースとして事前定義する必要があるのに対し、ラベルはリソースに付与する単なるメタデータである点です。 # 比較項目 タグ（Tags） ラベル（Labels） 1 性質 キー・バリュー・バインディングがそれぞれリソース リソースに付与するメタデータ 2 事前定義 組織またはプロジェクトでキー・バリューの事前定義が必要 事前定義不要 3 階層継承 子リソースに継承される 継承されない 4 主な用途 権限管理・統制（IAM 条件、組織のポリシー条件） リソース整理、課金分析 5 IAM 条件として利用 可能 不可 6 組織のポリシー条件として利用 可能 不可 組織ポリシーにタグを組み合わせることで、例えば、 environment=prod タグが付いたプロジェクトには、外部 IP の利用を禁止する組織のポリシーを適用するといったタグを軸とした条件付き統制を実現できます。 参考 : 組織のポリシーをタグで制御してみた - G-gen Tech Blog 参考 : タグとラベルの違い（Tags / Labels） - G-gen Tech Blog 予防的統制（ネットワークレベルで防御する） 概要 Google Cloud 上のワークロードを、外部からの不正アクセス、DDoS 攻撃、Web 攻撃、内部ネットワークからの脅威などから保護したい。あるいは、外部から VM への直接的な接続を許さず、必要な通信は制御された経路のみに限定したいといったケースが考えられます。 これらの課題に対応するため、Google Cloud では複数のネットワークセキュリティサービスが提供されています。しかし、それぞれが守る対象やレイヤが異なるため、要件に応じて組み合わせて利用することが推奨されます。 関連サービス・機能 Cloud NGFW（Next Generation Firewall） Cloud NGFW （Next Generation Firewall）とは、Google Cloud の VPC ネットワークに対するファイアウォール機能の総称です。従来の VPC ファイアウォールから発展した次世代ファイアウォール製品で、以下の3つの形態でルールを定義できます。 # 種類 適用範囲 ユースケース 1 VPC ファイアウォールルール VPC ネットワーク 従来からの VPC 単位のファイアウォール 2 ネットワークファイアウォールポリシー 特定リージョンまたは複数リージョンの VPC ネットワーク プロジェクト内の複数の VPC ネットワークに対して同じルール群を適用 3 階層型ファイアウォールポリシー 組織・フォルダ 組織横断のガードレールとして適用 例えば 階層型ファイアウォールポリシー を利用することで、組織レベルで「インターネットからの SSH 接続を一律拒否する」といった共通のガードレールを設定し、配下のすべての VPC に強制的に適用できます。 また、Cloud NGFW の機能は Essentials（無償） / Standard（有償） / Enterprise（有償） ティアのいずれかに分類され、Standard ティアでは FQDN オブジェクトや Threat Intelligence 連携が、最上位の Enterprise ティアではこれらに加えて侵入防止（IPS）や TLS インスペクションといった L7 セキュリティ機能が利用できます。 参考 : Cloud Next Generation Firewall(Cloud NGFW)を徹底解説！ - G-gen Tech Blog Cloud Armor Cloud Armor とは、Google Cloud のロードバランサーに対して DDoS 攻撃対策 と WAF （Web Application Firewall）機能を提供するサービスです。Google が提供する大規模なエッジネットワーク（Google Front End）と統合されており、アプリケーションに到達する前の段階で攻撃トラフィックをフィルタリングします。 主な機能は以下のとおりです。 # 機能 説明 1 DDoS 攻撃対策 L3/L4 の大量トラフィック攻撃（ボリューム型攻撃）に対する自動的な防御 2 WAF ルール OWASP Top 10 等の Web 攻撃（SQL インジェクション、XSS 等）に対するプリセットおよびカスタムルール 3 エッジセキュリティポリシー 地理的条件、IP アドレス、リクエストヘッダ等に基づくアクセス制御 4 Adaptive Protection 機械学習を用いた異常トラフィック検知（Enterprise エディションのみ） 5 bot 対策 reCAPTCHA Enterprise との連携によるボット判定 Cloud Armor には Standard と Enterprise の2つのエディションがあり、Enterprise では Adaptive Protection や脅威インテリジェンス連携といった高度な機能が利用できます。 参考 : Cloud Armorを徹底解説。GoogleのフルマネージドWAF - G-gen Tech Blog Cloud NAT Cloud NAT （Network Address Translation）とは、外部 IP アドレスを持たない VM や GKE Pod 等から インターネットへのアウトバウンド通信 を可能にするためのフルマネージドの NAT サービスです。 セキュリティ観点での主な意義は、 ワークロードを外部 IP なしで運用しつつ、必要な外部通信のみ実現できる 点にあります。外部 IP を持たないことで、インターネット側からの直接的な攻撃対象とならず、攻撃面（アタックサーフェス）を縮小できます。 外部 IP は、本来はインターネット側にサービスを提供するためのものですが、外部 API 呼び出しやパッケージのダウンロード等、アウトバウンド通信のためだけに外部 IP を付与しているケースは少なくありません。このような場合、Cloud NAT を利用することで外部 IP を排除し、より安全な構成にできます。 参考 : Cloud NAT の概要 Secure Web Proxy Secure Web Proxy （以下、SWP）とは、Google Cloud 上のワークロードからの アウトバウンド通信 （HTTP/HTTPS）を制御するためのフォワードプロキシサービスです。 主な機能は以下のとおりです。 接続先 URL（FQDN・パス）に基づくフィルタリング TLS インスペクション（HTTPS 通信の中身の検査） ユーザー・サービスアカウントに基づくポリシー適用 Cloud NAT がアウトバウンド通信の経路そのものを提供するのに対し、SWP はその上で「どのワークロードが、どの URL に通信できるか」を制御します。データ持ち出し対策や、信頼できる外部サービスへのみ通信を許可するゼロトラスト的な構成において有用です。 参考 : Secure Web ProxyでVMからのWebアクセスを制御してみた - G-gen Tech Blog Cloud IDS Cloud IDS （Intrusion Detection System、侵入検知システム）とは、VPC ネットワーク内のトラフィックを検査し、 ネットワーク侵入や脅威の兆候を検知 するためのマネージド型 IDS サービスです。バックエンドには Palo Alto Networks の脅威検知エンジンが採用されています。 VPC 内のトラフィックを パケットミラーリング によって IDS エンドポイントに複製し、不審な通信や既知の攻撃パターンを検知してアラートを発報します。検知のみを行い、通信の遮断は行わない点が IPS（Intrusion Prevention System、侵入防止）との違いです。 なお、前述の Cloud NGFW Enterprise エディションで IPS 機能が利用できるため、要件（検知のみ / 検知 + 遮断）に応じて使い分けることができます。 参考 : Google CloudのCloud IDSを徹底解説 - G-gen Tech Blog 参考 : Cloud NGFWのIPS機能を試してみた - G-gen Tech Blog 予防的統制（データを暗号化・保護する） 概要 Google Cloud に保存されるデータは、ユーザーが特別な設定を行わなくても、デフォルトで暗号化されています。このとき暗号鍵は Google 側で自動的に生成・管理・ローテーションされるため、ユーザーが意識する必要はありません。これを デフォルトの保存データの暗号化 と呼びます。 しかし、情報セキュリティ監査上の要件や、より強固なセキュリティが求められる場合には、ユーザー側で暗号鍵を独自に管理したい、機密データの所在を把握して保護したい、通信を暗号化する証明書を統制したい、といった要件が生じます。 本章では、こうした 暗号化・データ保護 に関連するサービスとして、暗号鍵を管理する Cloud KMS （およびその保護レベルである Cloud HSM ・ Cloud EKM ）、機密データを検出・保護する Sensitive Data Protection 、データ流出を防ぐ VPC Service Controls 、そして証明書を管理する Certificate Authority Service ・ Certificate Manager を解説します。 関連サービス・機能 Cloud KMS Cloud KMS （Cloud Key Management Service）とは、Google Cloud の暗号鍵を作成・保管・管理するための鍵管理サービスです。前述のとおり Google Cloud のデータはデフォルトで暗号化されますが、その鍵をユーザー自身で管理したい場合に Cloud KMS を利用します。 ユーザーが Cloud KMS で管理する鍵を、各種 Google Cloud サービスのストレージ暗号化に利用することを 顧客管理の暗号鍵 （Customer-Managed Encryption Keys、以下 CMEK）と呼びます。CMEK は Cloud Storage バケット、Compute Engine の永続ディスク、BigQuery のデータセットなど、多くのサービスでサポートされており、鍵の無効化・破棄をユーザーの管理下に置けるため、監査・コンプライアンス上の要件に応えやすくなります。 Cloud KMS の鍵は、鍵マテリアルの保護方法に応じて以下の 保護レベル から選択します。 # 保護レベル 説明 1 SOFTWARE ソフトウェアモジュールで鍵を保護する標準的な保護レベル 2 HSM Cloud HSM（後述）の専用ハードウェアで鍵を保護する 3 EXTERNAL / EXTERNAL_VPC Google Cloud 外部の鍵管理システム（Cloud EKM 経由、後述）で管理される鍵を利用する なお、Cloud KMS にはユーザー側で生成した既存の鍵をインポートする機能（BYOK : Bring Your Own Key）や、CMEK の鍵を自動でプロビジョニング・割り当てする Autokey といった機能もあり、鍵運用の負荷を軽減できます。 参考 : Cloud KMSを徹底解説 - G-gen Tech Blog Cloud HSM / Cloud EKM Cloud HSM と Cloud EKM は、いずれも独立した別サービスというよりも、前述の Cloud KMS の 保護レベル として選択できる鍵管理の選択肢です。どちらも Cloud KMS の API を通じて利用するため、操作方法やアクセス制御（IAM）は通常の Cloud KMS 鍵と共通です。 Cloud HSM は、FIPS 140-2 レベル3認定のハードウェアセキュリティモジュール（HSM）によって鍵を保護するフルマネージドの仕組みです。一方の Cloud EKM （Cloud External Key Manager）は、Google Cloud の外部に存在する鍵管理システムに格納された鍵を、Cloud KMS 経由で利用するための仕組みで、鍵をクラウド外部で保持・管理したい（HYOK : Hold Your Own Key）という要件に対応します。 # 機能 概要 主なユースケース 1 Cloud HSM FIPS 140-2 レベル3認定の HSM で鍵を生成・保護する ハードウェアで保護された鍵が求められる規制・監査要件 2 Cloud EKM Google Cloud 外部の鍵管理システムの鍵を Cloud KMS 経由で利用する 鍵をクラウド事業者の管理外に置きたい要件 要件に応じて、標準的な SOFTWARE 保護レベルで十分なのか、ハードウェア保護（Cloud HSM）が必要なのか、あるいは鍵そのものを外部に置く必要があるのか（Cloud EKM）を見極めて選択します。 参考 : Cloud HSM | Cloud Key Management Service Sensitive Data Protection Sensitive Data Protection （旧称 Cloud Data Loss Prevention、Cloud DLP）とは、個人識別情報（PII）等の機密データを 検出・分類・保護 するためのフルマネージドサービスです。 主な機能は以下のとおりです。Cloud Storage や BigQuery 等に保存されたデータをスキャンする使い方のほか、API 経由でテキストを送信して検査する使い方もあります。 # 機能 説明 1 検出（Discovery） 組織・フォルダ・プロジェクトを横断してデータをプロファイリングし、機密データの所在とリスクを可視化する 2 検査（Inspection） Cloud Storage、BigQuery、Datastore 等のデータや、API 経由のテキストに含まれる機密データを検出する 3 匿名化（De-identification） マスキングや仮名化（pseudonymization）等により、機密データを別の文字列に置き換えて保護する 4 リスク分析 k-匿名性などの指標を用いて、データの再識別リスクを測定する 代表的なユースケースとして、データ処理パイプラインの中で Sensitive Data Protection を用いて PII を検知・除去してからデータを保存する、といった構成が挙げられます。なお、生成 AI の入出力テキストに含まれる機密データの検査については、現在では Model Armor に統合されています。 参考 : Sensitive Data Protection の概要 VPC Service Controls（再掲） VPC Service Controls は、 サービス境界 という論理的な囲いを設け、信頼できるネットワークや認証情報以外からの API リクエストを制限することで、機密データの意図しない流出（データ持ち出し）を防ぐ機能です。当記事では「予防的統制（コンソール・API へのアクセスを制御する）」の章で詳しく解説しています。 データ保護の観点では、暗号化（Cloud KMS）や機密データの検出（Sensitive Data Protection）が「データそのものを守る」のに対し、VPC Service Controls は「データを取り扱う API アクセスの境界を守る」役割を担うものとして、組み合わせて活用することが推奨されます。 Certificate Authority Service Certificate Authority Service （以下、CA Service）とは、プライベート認証局（CA）の構築・運用・管理を簡素化・自動化するためのフルマネージドサービスです。組織内のシステムやワークロードに対して証明書を発行する仕組みを、CA サーバーやハードウェアを自前で運用することなく利用できます。 CA Service では、自己署名証明書を持つ ルート CA と、別の CA によって署名される 下位 CA （subordinate CA）の両方を作成でき、複数の CA を CA プール にまとめることでスケーラビリティを高められます。主なユースケースとしては、サービス間通信（mTLS）で利用するワークロード証明書の発行、内部向けロードバランサで使うプライベート証明書の発行、IoT デバイスの認証などが挙げられます。 手動での証明書の作成・更新作業を排除し、厳格なアクセス制御のもとで証明書のライフサイクルを管理できる点が、セキュリティ上の主な意義です。 参考 : Certificate Authority Service の概要 Certificate Manager Certificate Manager とは、Cloud Load Balancing（ロードバランサ）で利用する SSL/TLS 証明書の作成・管理・デプロイを行うサービスです。多数の証明書を扱う構成でも、証明書マップを通じて効率的に管理できます。 Certificate Manager で扱える証明書には、以下の2種類があります。Certificate Manager で管理する証明書は、合計100枚までは無料で、それを超えると枚数に応じた月額課金が発生します。また、前述の CA Service と連携することで、プライベートな Google マネージド証明書を発行することも可能です。 # 証明書の種類 説明 1 Google マネージド証明書 Google により発行・自動更新されるドメイン認証（DV）証明書 2 セルフマネージド証明書 ユーザーが外部で取得した証明書をアップロードして利用する CA Service が「証明書を発行する認証局そのもの」を提供するのに対し、Certificate Manager は「発行された証明書をロードバランサに紐づけて運用する」役割を担う、と整理すると分かりやすいでしょう。 参考 : GoogleマネージドSSL/TLS証明書をDNS認証で作成する方法 - G-gen Tech Blog 予防的統制（コンテナやコードの安全性を担保する） 概要 アプリケーションをコンテナとしてビルドし、GKE や Cloud Run にデプロイする運用が一般的になるなかで、 ソフトウェアサプライチェーン のセキュリティが重要な課題となっています。 具体的には、「コンテナイメージに既知の脆弱性が含まれていないか」「許可されていない、あるいは検証されていないイメージが本番環境にデプロイされていないか」「ビルドからデプロイ、実行に至る一連の経路が信頼できるものか」といった点を担保したい、という要件です。Google Cloud では、これらの課題に対応するためのサービスが提供されています。 関連サービス・機能 Artifact Registry / Artifact Analysis Artifact Registry とは、コンテナイメージや各種言語パッケージを保存・管理するためのフルマネージドのリポジトリサービスです。Cloud Run や GKE などのコンテナランタイムへイメージを提供する基盤となり、アクセス制御は IAM によってきめ細かく管理できます。 その Artifact Registry に保存されたアーティファクトの安全性を担保するのが Artifact Analysis （旧称 Container Analysis）です。Artifact Analysis は、ソフトウェア構成分析（脆弱性スキャン）とメタデータの保存・取得を提供するサービスで、イメージを既知の脆弱性情報と照合します。 スキャンには以下の2種類があり、特に自動スキャンは新たな脆弱性が発見されるたびに情報が継続的に更新されるため、過去に push されたイメージについても最新の脆弱性状況を把握できます。 # スキャン種別 説明 1 自動スキャン イメージを Artifact Registry に push した時点で自動的にスキャンが実行される。脆弱性情報は継続的に更新される 2 オンデマンドスキャン gcloud コマンドにより手動でスキャンを実行する。ローカルやレジストリ上のイメージを対象にできる Artifact Analysis による脆弱性検出結果は、後述の Security Command Center に集約され、プロジェクト横断で他のセキュリティリスクと併せて確認できます。また、次に述べる Binary Authorization と連携し、脆弱性のあるイメージのデプロイを抑止する用途にも利用されます。 参考 : Artifact Analysis の概要 Binary Authorization Binary Authorization とは、GKE、Cloud Run、Google Distributed Cloud（GDC）などへのコンテナイメージのデプロイ時に、信頼できるイメージのみがデプロイされることを保証する デプロイ時のセキュリティ統制 の仕組みです。 Binary Authorization では、組織のデプロイ要件を ポリシー として定義します。イメージが CI/CD パイプラインの各段階を通過する際に、その通過を示す署名（ 証明 / attestation ）が生成され、デプロイ時にはアドミッションコントローラ（リソース作成要求を受け付ける前に検査・制御する Kubernetes の仕組み）がポリシーを評価して、要件を満たさないイメージのデプロイをブロックします。証明を発行する主体は アテスター（attestor） と呼ばれます。 前述の Artifact Analysis と組み合わせることで、「一定以上の深刻度の脆弱性が検出されたイメージはデプロイを許可しない」といった、脆弱性スキャン結果に基づく統制も実現できます。なお、障害対応など緊急時には、ポリシーを一時的に迂回する breakglass（ブレークグラス）の仕組みも用意されています。 参考 : Binary Authorization の概要 GKE セキュリティ機能 GKE（Google Kubernetes Engine）には、コンテナワークロードを安全に運用するためのセキュリティ機能が数多く実装されています。とりわけ Autopilot モード では、Google のベストプラクティスに基づいたハードニング済みの構成がデフォルトで適用され、ノードの管理（スケーリング・修復・セキュリティパッチ適用）も Google に委任できます。 代表的なセキュリティ機能は以下のとおりです。 # 機能 説明 1 Autopilot モード ハードニング済みの構成をデフォルト適用し、危険な構成や設定ミスが起きやすい機能をブロックする 2 Workload Identity Pod に対し、サービスアカウントキーを使わずに Google Cloud リソースへの認証を提供する 3 Shielded GKE Nodes ノード VM のセキュアブートや整合性監視により、ノードの改ざんを検知する 4 限定公開クラスタ ノードに外部 IP を付与せず、攻撃面（アタックサーフェス）を縮小する 5 Pod セキュリティの制御 特権 Pod など危険な構成を、アドミッションコントローラによって制限する Standard モードでもこれらの機能は個別に有効化できますが、Autopilot モードを選択することで、セキュリティのベースラインを最初から確保できる点が大きなメリットです。 参考 : Google Kubernetes Engine（GKE）を徹底解説 - G-gen Tech Blog Software supply chain security Software supply chain security とは、特定の単一サービスを指す名称ではなく、ソフトウェアサプライチェーン全体をエンドツーエンドで保護するための製品群の総称です。 開発環境からビルド、アーティファクトの保管、デプロイ、実行に至る各段階を保護するために、Cloud Workstations（セキュアな開発環境）、Cloud Build（ビルド）、本章で解説した Artifact Registry / Artifact Analysis、Binary Authorization、Assured Open Source Software（検証済み OSS パッケージ）といったサービスが組み合わされています。すなわち、ここまでに解説してきた各サービスを、サプライチェーンセキュリティという観点で束ねた包括的なフレームワークと捉えるとよいでしょう。 参考 : ソフトウェア サプライ チェーンのセキュリティ 発見的統制 概要 予防的統制をどれだけ整備しても、すべての設定ミスや新たな攻撃手法を完全に防ぐことは困難です。 発見的統制 は、発生した（あるいは発生しつつある）セキュリティ事象や設定ミスを速やかに検知し、可視化するための仕組みであり、予防的統制を補完する重要な役割を担います。 Google Cloud では、構成ミス・脆弱性・脅威の検出を統合的に行う Security Command Center を中核に、過剰権限の検出を支援する IAM Recommender （Active Assist）、運用監視を担う Cloud Monitoring 、より広範なログ分析と脅威検知を行う Google SecOps 、そして脅威インテリジェンス・インシデント対応サービスを提供する Mandiant が用意されています。 関連サービス・機能 Security Command Center Security Command Center （以下、SCC）とは、Google Cloud 環境の 構成ミス・脆弱性・脅威・コンプライアンス違反 を一元的に検出・可視化する統合セキュリティプラットフォームです。各検出機構が出力した結果は 検出結果（Findings） として集約され、SCC のダッシュボード上で横断的に確認できます。 SCC が提供する主な検出カテゴリは以下のとおりです。 # 検出カテゴリ 説明 1 構成ミスの検出 IAM・ネットワーク・ストレージ等の設定ミスを継続的に検出する（Security Health Analytics） 2 脆弱性の検出 Web アプリケーションの脆弱性（Web Security Scanner）、Artifact Registry のコンテナイメージ脆弱性等を検出する 3 脅威の検出 Cloud Audit Logs 等のログから攻撃の兆候を検出する（Event Threat Detection、Container Threat Detection 等） 4 コンプライアンス CIS Benchmarks、PCI DSS 等の業界標準に対する準拠状況を可視化する SCC は2026年6月現在 Standard ・ Premium ・ Enterprise の3つのサービスティアで提供されていますが、Enterprise ティアは2027年5月21日に EOL の予定です。 # ティア 概要 1 Standard 基本的な構成ミスの検出と、コンプライアンス順守状況の管理。Google Cloud を対象とする 2 Premium Standard に加え、攻撃パス分析、脅威検出、コンプライアンスモニタリング、DSPM（Data Security Posture Management。機密データの所在やリスクを可視化・管理する仕組み）等の高度機能を提供 3 Enterprise マルチクラウド対応の CNAPP（Cloud-Native Application Protection Platform、クラウドネイティブなアプリを開発から実行まで包括的に保護する統合プラットフォーム）として AWS と Azure に対応。Mandiant の脅威インテリジェンスや Google SecOps との統合を含む包括的なソリューション SCC の検出結果は Pub/Sub 経由で外部システムへ通知したり、後述の Google SecOps と統合して SIEM 側でより高度な分析・自動対応につなげたりすることも可能で、運用ワークフローの起点として利用できます。 参考 : Security Command Centerを徹底解説。Google Cloud(GCP)の脆弱性を自動検知 - G-gen Tech Blog IAM Recommender（Active Assist） IAM Recommender とは、IAM ポリシーの利用状況を機械学習で分析し、 実際には使われていない過剰な権限を特定して推奨事項を提示する 機能です。最小権限の原則を「すでに付与済みの権限を整理する」観点で支援するもので、Google Cloud の推奨機能群である Active Assist の一部として提供されます。 IAM Recommender は、過去の権限利用履歴を分析し、付与されているロールに対して実際に必要だった権限を割り出した上で、より粒度の細かいロールへの差し替えや、未使用権限の削除といった推奨を生成します。推奨事項はコンソール上で確認し、レビューの上で適用する運用が基本となります。 IAM Recommender 自体は無料で利用できますが、生成される推奨事項の範囲は SCC のティアに依存する点に注意が必要です。 # 対象ロール・スコープ 必要な SCC ティア 1 基本ロール（オーナー、編集者、閲覧者） Standard 2 ・基本ロール以外 ・組織、フォルダ、プロジェクト以外のリソースに付与されたロール Premium 以上 Active Assist には IAM Recommender 以外にも、放置プロジェクトの検出、未使用リソースの検出など、コスト・パフォーマンス・セキュリティに関する各種の Recommender が含まれており、組み合わせることで運用全体の最適化にも貢献します。 参考 : Google CloudのIAMで最小権限の原則を実現する方法 - G-gen Tech Blog Cloud Monitoring Cloud Monitoring は、Google Cloud リソースの指標（メトリクス）を収集・可視化し、しきい値超過時に通知を発報する統合監視サービスです。本来はパフォーマンス監視や可用性監視を主目的としますが、セキュリティ運用においても重要な役割を果たします。 特に、前述の Cloud Logging に集約された Cloud Audit Logs 等のログに対するログベースのアラート と組み合わせることで、「特定の高権限操作が実行された」「想定外のリージョンでリソースが作成された」といった事象を即時に検知し、運用チームへ通知できます。 # 機能 セキュリティ運用での主な用途 1 アラートポリシー 監査ログのパターンや異常なメトリクスに基づくインシデント通知 2 通知チャネル メール、Slack、PagerDuty、Pub/Sub 等への通知発報 3 稼働時間チェック 外形監視によるサービスの可用性監視 4 ダッシュボード セキュリティ関連メトリクスの可視化 SCC が「Google Cloud 全体のセキュリティ状態（ポスチャ）」を扱うのに対し、Cloud Monitoring は「自社で構築したワークロード固有のメトリクスやログ」をきめ細かく監視する役割を担い、両者は補完関係にあると整理できます。 参考 : Cloud Monitoringを徹底解説！ - G-gen Tech Blog Google SecOps（SIEM / SOAR） Google SecOps （Google Security Operations、旧称 Chronicle）は、 SIEM （Security Information and Event Management）、 SOAR （Security Orchestration, Automation and Response）、脅威インテリジェンス、Gemini を統合した、Google Cloud のセキュリティ運用プラットフォームです。 従来、ログの収集・検索、検知ルール管理、インシデントの調査と対応はそれぞれ別々の製品で行う必要があり、運用面での課題となっていました。Google SecOps はこれらを単一のクラウドネイティブな基盤上で統合し、ログ分析から脅威検知、調査、自動対応までを一気通貫で実現します。Google Cloud のログだけでなく、AWS や Azure、各種オンプレミス機器や SaaS のログも取り込むこともできます。 発見的統制の文脈では、特に SIEM の側面が重要です。Google SecOps は取り込んだログを UDM （Unified Data Model）という共通スキーマに正規化した上で、検知ルールと突き合わせて脅威を検出します。後述する Mandiant および VirusTotal の脅威インテリジェンスが標準で組み込まれており、IoC（Indicator of Compromise、侵害の痕跡）との照合による検知が可能です。なお、検知された事象に対する自動対応（SOAR）の側面については、是正的統制の章で改めて解説します。 参考 : Google SecOps(Google Security Operations)を徹底解説！ - G-gen Tech Blog Mandiant Mandiant は、2022年に Google が買収したサイバーセキュリティ企業で、脅威インテリジェンス、インシデント対応、攻撃面管理といった分野で世界的に知られています。買収後も Mandiant ブランドは維持され、現在は Google Cloud のセキュリティポートフォリオの一部として位置づけられています。 Mandiant が提供する主なサービスは以下のとおりです。 # サービス 概要 1 Mandiant Threat Intelligence 攻撃者の戦術・技術・手順（TTP）に関する脅威インテリジェンスを提供する 2 Mandiant Attack Surface Management（ASM） 組織のインターネット側からの露出範囲（攻撃面）を発見・継続監視する 3 Mandiant Managed Defense 24時間365日のマネージド検知・対応（MDR）サービス 4 Mandiant Incident Response インシデント発生時の調査・対応支援サービス Google Cloud との統合という観点では、前述の SCC Enterprise および Google SecOps に Mandiant の脅威インテリジェンスが標準で組み込まれており、最前線の知見に基づく検知・分析機能が利用できます。 参考 : Security Command Center Enterprise 発表: AI を活用した SecOps とクラウド セキュリティを融合した初のマルチクラウド リスク管理ソリューション 是正的統制 概要 発見的統制によってセキュリティ事象や設定ミスを検知できても、その是正を人手のみに頼っていては対応が追いつかず、ミスや遅延も生じます。 是正的統制 は、検知された不適切な状態を、人手を介さず（あるいは最小限の人手で）自動的に修復し、あるべき状態を維持するための仕組みです。 代表的な適用例としては、本来あるべき構成から逸脱した状態（ 設定ドリフト ）を自動的に元へ戻す、検知した脅威に対して定型の対応手順を自動実行する、といったものが挙げられます。Google Cloud では、宣言的なリソース管理で構成を維持する Config Controller 、イベントを起点に修復処理を実行する Eventarc + Cloud Run functions / Workflows 、そして脅威対応を自動化する Google SecOps の SOAR 機能 が用意されています。 関連サービス・機能 Config Controller Config Controller とは、 Config Connector （Kubernetes を用いて Google Cloud リソースを宣言的に管理できる Kubernetes アドオン）のマネージドサービスです。リソースの「あるべき状態」を Kubernetes のマニフェストファイルとして定義し、その状態を維持します。 是正的統制の観点で重要なのが、Kubernetes の Reconciliation Loop（調整ループ） の仕組みです。マニフェストで定義した「理想の状態」と「実際の環境」との間に差分（ドリフト）が生じた場合、Config Connector が自動的に理想の状態へ戻します。たとえば、誰かが手動で設定を変更してしまっても、定義した状態へ自動修復されるため、構成の一貫性を保てます。 Config Controller の実体は GKE クラスタであり、以下のコンポーネントがプリインストールされています。これらを組み合わせることで、GitOps による構成管理とガードレールの適用を実現できます。 # コンポーネント 役割 1 Config Connector Kubernetes マニフェストで Google Cloud リソースを宣言的に管理する 2 Config Sync Git リポジトリと連携し、格納されたマニフェストを継続的に同期する（GitOps） 3 Policy Controller ポリシーに違反するリソースの作成を検出・拒否する（ガードレール） 参考 : Config Controller(Config Sync)でGoogle Cloudブループリントを利用してGitOpsなリソース管理を実現する - G-gen Tech Blog Eventarc + Cloud Run functions / Workflows Eventarc とは、サーバーレスかつ標準化されたイベント配信により、Google Cloud 上でイベントドリブンアーキテクチャを容易に構築できるフルマネージドサービスです。これを Cloud Run functions や Workflows と組み合わせることで、「特定の事象が発生したら自動的に修復処理を実行する」という是正フローを構築できます。 是正的統制の典型的な構成は、 Cloud Audit Logs や Cloud Asset Inventory のイベント （リソースの作成・更新・削除など）を Eventarc トリガーで捕捉し、後続の処理を起動するというものです。 例えば、「公開設定にされた Cloud Storage バケットを検知して自動的に非公開へ戻す」「許可されていない構成のリソースが作成されたら自動で削除・通知する」といった処理を、サーバーレスで実装できます。Eventarc で利用できる主なイベントソースとコンシューマは以下のとおりです。 # 区分 主な選択肢 1 イベントソース Cloud Audit Logs イベント（リソースの作成・更新・削除等）、Cloud Storage、Pub/Sub、サードパーティ（Datadog 等） 2 イベントコンシューマ Cloud Run、Cloud Run functions、Workflows 後続処理には、単一の修復処理であれば Cloud Run functions を、複数ステップを順序立てて実行する必要があれば Workflows を利用する、といった使い分けが可能です。なお、証跡管理の章で触れた Cloud Asset Inventory の変更通知（Pub/Sub 連携）を起点とすれば、設定ドリフトの検知から自動修復までを一連のフローとして構築できます。 参考 : Eventarc + Cloud Run で Google Cloud リソースの作成を Slack 通知する - G-gen Tech Blog Google SecOps（SOAR） 発見的統制の章で解説した Google SecOps は、SIEM による脅威検知だけでなく、検知後の対応を自動化・オーケストレーションする SOAR （Security Orchestration, Automation and Response）の機能も備えています。是正的統制の文脈では、この SOAR の側面が中心となります。 SOAR では、検知された脅威の種類に応じた対応手順を プレイブック として定義しておき、インシデント発生時に自動実行します。たとえば「不審なアクティビティを検知したら、該当アカウントの権限を制限し、関係者へ通知し、チケットを起票する」といった一連の対応を、人手を介さずに（あるいは承認を挟みつつ）実行できます。これにより、対応の標準化と初動の高速化が図れます。 経済的統制 概要 クラウドは従量課金制であるため、設定ミスや想定外のトラフィック、あるいは意図的な攻撃によって、利用料金が異常に増加するリスクを常に抱えています。特に、リソースを大量消費させて経済的な損害を与える攻撃は EDoS（Economic Denial of Sustainability） と呼ばれます。 経済的統制 は、こうした想定外のコスト増から組織を保護するための仕組みです。Google Cloud では、予算超過を通知する Cloud Billing 予算アラート 、プロジェクト単位で費用上限を自動適用する Spend Caps 、機械学習による コスト異常検知 、そしてリソース使用量そのものに上限を設ける Quotas（割り当て） を組み合わせて、多層的にコストを保護できます。 関連サービス・機能 Cloud Billing 予算アラート 予算アラート とは、Cloud Billing で予算（budget）としきい値を設定し、指定期間の請求額がしきい値を超えた際に通知を発報する機能です。予期しない請求の発生に早期に気づくための、コスト保護の基本となる仕組みです。 ここで極めて重要な注意点として、 予算アラートはあくまで「通知」であり、支出を自動的に停止するものではない という点が挙げられます。しきい値を超えても、リソースの利用や課金がその時点で止まるわけではありません。支出を実際に抑制したい場合は、Pub/Sub トピックへ連携した自動アクションや、後述の Spend Caps による上限の適用が必要になります。 通知先としては、メール（請求先アカウントのロールベースの宛先、または Cloud Monitoring の通知チャネルで指定したメールアドレス）が利用できます。さらに、プログラムによる後続処理につなげるための通知先として Pub/Sub トピックを指定できます。 参考 : 予算アラートの設定方法 - G-gen Tech Blog Spend Caps Spend Caps とは、2026年4月の Google Cloud Next '26 で発表された、プロジェクト単位で費用の上限を自動的に適用する機能です。Google Cloud の予算（budget）と連携して動作し、管理者が設定した上限に基づいてコストを制御します。2026年6月現在では非公開プレビュー（Private Preview）で、一般提供（GA）はされていない点にご留意ください。 この機能が登場した背景には、AI ワークロード特有のコスト急増リスクがあります。AI は TPU / GPU といった高価な専用ハードウェアを使用するため、制御不能になった単一のトレーニングジョブや最適化されていないモデルが、ごく短時間で予算を使い果たしてしまう可能性があります。従来の費用管理ツールは管理者へアラートを送るのみで上限を強制適用しないため、各社は課金の無効化のような影響の大きい操作を含む独自のガードレールを構築せざるを得ませんでしたが、それを Google Cloud ネイティブな仕組みで解決するのが Spend Caps となります。 対象サービスは、Google AI Studio、Gemini Enterprise Agent Platform（旧称 Vertex AI）、Cloud Run、Cloud Run functions、Google Maps Platform となっており、挙動としては、設定した上限に到達するとアラートを送信し、予算に達すると API トラフィックが一時停止 されますが、課金無効化のようにリソースそのものが削除・停止されるわけではなく、リソースは保持されたまま残ります。トラフィックを再開したい場合は、Spend Caps を停止するだけで済みます。 参考 : AI 時代に向けた次世代の FinOps コスト異常検知（Anomaly Detection） 異常検知（Anomaly Detection） とは、Google Cloud の請求先アカウントに標準で付属する、突発的な課金を検知する機能です。請求先アカウント単位で過去の使用傾向が機械学習により学習され、普段と異なるパターンの課金が発生すると「異常（anomaly）」として検知されます。 予算アラートが「あらかじめ設定したしきい値」を基準とするのに対し、異常検知は「過去の利用傾向からの逸脱」を基準とする点が特徴で、想定外の急激なコスト増を捉えるのに適しています。検知結果はコンソールで確認できるほか、メールや Pub/Sub への通知が可能で、Pub/Sub 連携により後続の自動処理につなげることもできます。なお、異常が検知される対象は6ヶ月間以上の利用実績があるプロジェクトに限られる点には留意が必要です。 参考 : Google Cloud請求先アカウントの異常検知（Anomaly Detection）を解説 - G-gen Tech Blog Quotas（割り当て） 割り当て（Quota） とは、Google Cloud の各種サービスに設定された、リソース使用量や API 呼び出し回数の上限です。本来はサービスの過負荷を防ぎ、意図しない大量のリソース作成を防止するための仕組みで、組織・プロジェクト・ユーザーなど様々な粒度で設定されています。 経済的統制の観点では、割り当てを「利用拡大に応じて緩和するもの」としてだけでなく、 あえて任意の上限値を設定することで突発的な課金を防ぐガードレール として利用できます。 代表的な例として、BigQuery の「1 日あたりのクエリ使用量（Query usage per day）」の割り当てが挙げられます。かつてこの割り当ては課金有効プロジェクトでデフォルト無制限でしたが、2025年9月1日以降、デフォルトで 1 日 200 TiB に設定されるよう変更されました。それでも上限としては大きいため、ワークロードに合わせてより低い値を明示的に設定しておくことで、想定外の高額課金をより確実に防げます。 予算アラートやコスト異常検知が「課金の発生を検知して通知・対応する」事後的なアプローチであるのに対し、割り当ては「リソース消費そのものに上限を設ける」事前的なアプローチであり、両者を組み合わせることでより堅牢なコスト保護が実現できます。 参考 : Google Cloudで割り当て（Quota）を上限緩和する方法 - G-gen Tech Blog 参考 : BigQueryのオンデマンドクエリの利用量にフタをする (上限を設ける) - G-gen Tech Blog 生成 AI 特有のセキュリティ 概要 これまで解説してきたセキュリティ統制の多くは、「人間のユーザー」と「あらかじめ定められた動作をするアプリケーション」を前提としていましたが、生成 AI の利用はこの前提に新たな脅威をもたらします。 具体的には以下の3点です。 自然言語の入力そのものが攻撃の経路になり得ること モデルが確率的に予期しない出力を返し得ること AI エージェントが自律的に判断して他システムを操作し得ること そのため、生成 AI のセキュリティでは、以下のような生成 AI 特有の脅威領域を意識する必要があります。 # 脅威領域 代表的なリスク 1 入出力（プロンプト、レスポンス） ・プロンプトインジェクション、ジェイルブレイク ・機密データの入/出力 ・有害コンテンツの生成 ・悪意のある URL の出力 2 データ ・RAG（グラウンディング。外部データを検索して回答の根拠とする手法）における過剰権限 ・入力データの学習利用 ・データの保存場所（レジデンシー） 3 AI エージェント ・自律的に動作するエージェントの過剰権限 ・エージェントのなりすまし ・外部ツール連携時の認証情報管理 本章では、前提となる基盤の選択、またこれらに対応する生成 AI 特化のサービスとして Model Armor （入出力のスクリーニング）、 Agent Identity （エージェントの認証）、 Agent Gateway 、 Agent Registry 、 AI Protection を中心としたエージェントのガバナンスを解説します。 生成 AI 基盤の選択 Google で生成 AI を利用する主な経路には、Google Cloud に統合された Gemini Enterprise Agent Platform （旧称 Vertex AI）と、Google アカウントだけで手軽に始められる Google AI Studio があり、どちらを選ぶかはそれ自体がセキュリティ・統制上の判断になります。 前者は Google Cloud に統合されているため、IAM によるアクセス制御、VPC Service Controls や Cloud Armor による保護、Cloud Audit Logs による監査、そして本章で解説する Model Armor・Agent Identity・Agent Gateway といった ガバナンス機能を組み合わせて 利用できます。管理者が利用状況を可視化し、問題のある振る舞いを検知した際にサービスアカウントの停止やアクセス権の剥奪を行う、といった統制も可能です。 一方の後者は API キーを発行してすぐにモデルを呼び出せる手軽さが魅力ですが、 組織レベルの統制やアクセス制御機能は備わっていません。 そのため、個人開発やプロトタイピングには適しているものの、企業・官公庁・研究機関などが組織として生成 AI アプリケーションを開発・運用する場合は、 統制機能の整った Gemini Enterprise Agent Platform が推奨されます。本章で扱うセキュリティ機能の多くも、この基盤を前提としています。 参考 : Google AI Studio vs Vertex AI。違いや選び方を解説 - G-gen Tech Blog 関連サービス・機能 Model Armor Model Armor とは、生成 AI・エージェントのプロンプト（入力）とレスポンス（出力）をスクリーニングし、LLM が悪意のあるコンテンツや機密性の高いコンテンツにさらされたり、それらを生成したりするのを防ぐランタイムセキュリティサービスです。 Model Armor が提供する主な検知・フィルタ機能は以下のとおりです。 # フィルタ 説明 1 プロンプトインジェクション・ジェイルブレイク検出 LLM に指示や安全フィルタを無視させようとする入力を特定・ブロックする 2 機密データの保護 Sensitive Data Protection と連携し、PII・財務情報・認証情報等の機密データを入出力の両方で検出する 3 悪意のある URL の検出 入出力に含まれる悪意のあるリンクやフィッシングリンクを検出する 4 有害コンテンツのフィルタリング 露骨な性的表現・危険・ハラスメント・ヘイトスピーチ等を検出し、責任ある AI の原則に沿わせる Model Armor の挙動は テンプレート で定義します。テンプレートには各フィルタと、検知の確信度を表す しきい値 を設定でき、アプリケーションのリスク許容度に応じて適用の強さを調整できます。利用方法としては、API へ直接スクリーニングリクエストを送る方法と、Gemini Enterprise Agent Platform（旧称 Vertex AI）に統合して使う方法があります。Model Armor の検出結果は SCC に送られ、他のセキュリティリスクと併せて確認できます。 参考 : Model Armorを徹底解説！ - G-gen Tech Blog Agent Identity Agent Identity とは、Google Cloud 上で動作する AI エージェントに、 SPIFFE （ワークロードに標準化された ID を付与するためのオープン標準）に基づく固有のアイデンティティを付与する仕組みです。これにより、エージェントは MCP サーバー、Google Cloud リソース、外部 API、他のエージェントに対して、自身の権限で安全に認証できます。 従来、エージェントの実行環境にはサービスアカウントを利用するのが一般的でしたが、共有（使いまわし）や権限借用（なりすまし）が可能であること、サービスアカウントキーの漏洩リスクなどの課題がありました。 Agent Identity はこの問題を解決するもので、サービスアカウントとは以下の点で異なります。 項目 サービスアカウント Agent Identity 複数ワークロードでの共有 可能 複数のエージェントで同じサービスアカウントを使い回すこともできてしまう 不可 エージェント単位で ID が発行される 権限借用（impersonation） 可能 別のプリンシパルにサービスアカウントの借用（なりすまし）を許可することもできてしまう 不可 エージェント自身以外は ID を使用できない 長期キーの手動生成 可能 サービスアカウントキーはデフォルトで有効期限がなく、漏洩した場合は無効化しない限り悪用され続けてしまう 不可 トークンのバインド なし アクセストークンを入手した第三者がそのまま使用できてしまう あり トークンが X.509 証明書と紐付き、意図された実行環境以外では使用できない 参考 : Google CloudのAgent Identityを解説 - G-gen Tech Blog Agent Gateway / Agent Registry 前述の Agent Identity が「エージェントが何者か（認証）」を担うのに対し、エージェントが「何にアクセスでき、どのような通信・内容が許されるか」を統制するのが Agent Gateway です。 Agent Gateway は、ユーザーとエージェント、エージェントとツール、エージェント同士といった、 エージェントが関わるすべての通信を保護・管理するネットワーク基盤 です。クライアントからの内向き通信（Client-to-Agent）と、外部サービスへの外向き通信（Agent-to-Anywhere）の双方を仲介し、通過するプロンプトとレスポンスを前述の Model Armor で検査し、危険な内容を除去（サニタイズ）できます。 また、すべての通信のログ・メトリクス（テレメトリ）を Cloud Logging や Cloud Trace へ送信できるため、セキュリティ調査や監査にも活用できます。 Agent Gateway は、通信に対して ポリシー を適用することでアクセス制御を実現します。ポリシーには以下の2種類があります。 # ポリシー 内容 1 IAM 許可ポリシー Identity-Aware Proxy を用いた静的な権限制御。「読み取り専用」「破壊的変更の許可」といった条件で、エージェントが行える操作を制限する 2 セマンティック ガバナンス ポリシー プロンプトや MCP ツール呼び出しの「内容」を実行時に分析し、エージェントの振る舞いがユーザーの意図と組織の制約の両方に適合するよう制御する 特に セマンティック ガバナンス ポリシー は、入力や呼び出しの「内容」そのものを評価して制御する点で、生成 AI 特有の統制といえます。 これらの前提として、エージェント・MCP サーバー・エンドポイントを一元的に登録・管理する統合カタログである Agent Registry があります。 Agent Gateway を利用するにはエージェントを Agent Registry に登録しておく必要があり、Agent Registry によって エージェントやツールが組織内に散在し、どこに何があるか・誰が呼び出せるかを把握できなくなる 、といった管理課題を解消します。 なお、2026年6月現在 Agent Registry がプレビュー、Agent Gateway は非公開プレビューです。 参考 : Gemini Enterprise Agent Platformを徹底解説！ - G-gen Tech Blog 参考 : Agent Gateway の概要 AI Protection（Security Command Center） ここまで解説した Model Armor やエージェントのガバナンス機能による検出結果は、発見的統制の章で解説した SCC の AI Protection という機能群に集約され、他のクラウドリスクと同じダッシュボード上で一元的に確認できます。 AI Protection は、組織内の AI 資産（モデル・データセット・アプリケーション、Agent Registry に登録された MCP サーバー等）を自動的に検出・棚卸しし、それらに対するリスクや脅威を管理するための機能です。前述の Model Armor を中核コンポーネントとして取り込みつつ、AI 特有のリスクを可視化します。SCC の Premium または Enterprise ティアで、組織レベルの有効化により利用できます。 個々のサービス（Model Armor 等）が「入口で守る」役割を担うのに対し、AI Protection は「組織全体の AI セキュリティ状態（ポスチャ）を俯瞰する」役割を担うものと整理できます。 参考 : AI Protection overview Google Workspace Google Workspace の生成 AI 機能（Gemini アプリ・NotebookLM 等）のセキュリティについては、以下の記事を参照してください。 blog.g-gen.co.jp 武井 祐介 (記事一覧) クラウドソリューション部クラウドエンジニアリング課。 Google Cloud Partner Top Engineer 2026 選出。 Follow @ggenyutakei

はじめに こんにちは、クラウドエースの梶尾です。 Google Cloud のコンピューティングサービスを検討するとき、必ずと言っていいほど選択肢として並ぶのが Compute Engine と Cloud Run です。 よく「クラウドは柔軟だから、まずは手軽な方で始めて、あとで変えればいい」という言葉を耳にします。 しかし、実務で言えば、開発途中のプラットフォーム変更は設計・運用・CI/CD パイプラインのすべてにおいて、手戻りを発生させます。 最初の一歩を間違えると、その後の開発効率やコストに大きな差が出てしまうのが現実です。 とりあえずで選んで後悔しないために。 この記事では