Instiq

Google Cloud Professional Machine Learning Engineer のナレッジマップ

Google Cloud Professional Machine Learning Engineer の主要概念 152 件と、そのつながり。上のマップでノードをクリックすると関連用語や前提をたどれます。下は全概念の索引で、定義と「前提・関連する概念」への内部リンクを掲載しています。

概念一覧(152)

  • Vertex AI

    機械学習モデルの構築・学習・デプロイ・運用を一気通貫で行える統合 AI プラットフォーム。基盤モデルの利用も可能。

    前提: 基盤モデル

  • BigQuery

    ペタバイト級のデータを SQL で高速に分析できる、Google Cloud のサーバーレスなデータウェアハウス。

  • Cloud Storage

    画像・動画・バックアップなど非構造化データを保存するオブジェクトストレージ。

  • マネージドサービス(管理の境界)

    AWS が運用の一部を肩代わりするサービス区分。フルマネージド(パッチ/スケール/可用性まで AWS)ほど運用負荷が下がる一方、制御は減る。アンマネージド(EC2 等)は柔軟だが自己管理。責任共有モデルの「どこまでが自分の責任か」を決める軸。

  • Cloud Run

    コンテナをサーバーレスで実行するサービス。トラフィックがなければゼロまで縮小し、使った分だけ課金される。

    前提: ML データ準備(エンコード/スケーリング/不均衡)

  • Vertex AI Workbench

    Google Cloud のマネージドな JupyterLab ベースの ML 開発環境。VPC Service Controls・限定公開 Google アクセス・最小権限のサービスアカウントなど、本格的なエンタープライズ ML 開発向けのセキュリティ制御を適用できる。BigQuery や Cloud Storage とのネイティブ連携が組み込まれている。

    前提: BigQueryCloud StorageVertex AIサービスアカウント(Service account)

  • Gemini

    Google Cloud の中核となる生成 AI モデル。文章生成・要約・コード支援・画像理解などを担い、各サービスや Workspace に組み込まれる。

  • Tabular Workflows

    表形式データ向けの AutoML パイプラインを、Vertex AI Pipelines 上のコンポーネントとして分解し、特徴量エンジニアリングやアーキテクチャ探索などの各段階を個別にカスタマイズ・再利用できるようにした機能。AutoML のブラックボックス的な自動化に対し、大規模データや特定段階への細かい制御が必要な上級ユースケース向け。

    前提: WorkflowsVertex AI特徴量エンジニアリングと埋め込み/RAGVertex AI Pipelines(Kubeflow/TFX)

    関連: Vertex AI AutoML

  • 基盤モデル

    幅広い用途に使える大規模な事前学習モデル(例:GPT)。マルチモーダルは複数種類を扱う。

  • ML データ準備(エンコード/スケーリング/不均衡)

    生データをモデルが学べる形に整える工程。エンコード=カテゴリを数値化(ワンホット/順序/ターゲット)、スケーリング=標準化(z-score)/正規化(Min-Max)、不均衡=SMOTE等のオーバーサンプリング/クラス重み付け(評価はF1/PR-AUC)。変換のfitは分割後のトレーニングデータのみ(データリーク防止)。

  • VPC Service Controls

    BigQuery や Cloud Storage などのマネージドサービスへのデータ持ち出しを、サービス境界(perimeter)で防ぐ仕組み。IAM の許可とは別レイヤーの統制。

    前提: BigQueryCloud Storageマネージドサービス(管理の境界)

  • Cloud Composer

    Apache Airflow ベースのマネージドなオーケストレーション。依存のある複数ステップのパイプラインをスケジュール・実行する。

  • Workflows

    サービス間の軽量なステップ連携(シンプルなワークフロー)を行うサーバーレスのオーケストレーション。重い依存は Cloud Composer。

    前提: Cloud Composer

  • BigQuery ML

    BigQuery 上のデータに対し、データを移さず SQL だけで機械学習モデルを作成・予測できる機能。

    前提: BigQuery

  • Compute Engine

    Google Cloud の IaaS。CPU/メモリを選べる仮想マシン(VM)を提供し、OS まで自分で管理できる。既存システムのリフト&シフト先に適する。

    前提: 移行戦略(リフト&シフト/改善移行/リファクタ)

  • Cloud Build

    ソースコードの取得・ビルド・テスト・コンテナイメージ化を自動実行するサーバーレス CI サービス。cloudbuild.yaml でビルドステップを定義し、GitHub/Cloud Source Repositories への push をトリガーに実行できる。生成物は Artifact Registry へ保存するのが一般的。

    前提: YAML

    関連: Cloud DeployArtifact Registry

  • サービスアカウント(Service account)

    人ではなくワークロード(VM/アプリ)が使う特別な ID。鍵の代わりにメタデータ経由の短命トークンや Workload Identity Federation で認証するのが安全。

  • デプロイ戦略(カナリア/ブルー・グリーン/ロールバック)

    カナリア=一部の利用者に先行公開、ブルー/グリーン=新旧環境を瞬時に切替、ロールバック=問題時に即座に戻す。リスクを抑えてリリースする手法。

  • Vertex AI AutoML

    コードをほぼ書かずに、表形式・テキスト・画像・動画データから高品質なカスタム ML モデルを自動構築する Vertex AI の機能。ニューラルアーキテクチャ探索とハイパーパラメータ調整を裏側で行い、精度と学習コストのバランスを取ったモデルを出力する。素早い SQL 分析だけなら BigQuery ML の方が手軽な場合もある。

    前提: BigQueryBigQuery MLVertex AI分散訓練(Reduction Server/Horovod)とハイパーパラメータ調整

    関連: Tabular Workflows

  • Eventarc

    Pub/Sub や Cloud Storage の変更など多様なイベント源からのイベントを Cloud Run / Cloud Functions へ統一的に配送する仕組み。

    前提: Cloud FunctionsCloud RunCloud StoragePub/Sub

  • Ops Agent

    Compute Engine や オンプレミス VM にインストールし、詳細なシステムメトリクス(CPU/メモリ/ディスク等)とログを Cloud Monitoring / Cloud Logging へ収集するエージェント。旧来の Monitoring エージェントと Logging エージェントを統合したもので、新規はこちらを使う。

    前提: Cloud LoggingCloud MonitoringCompute Engineエージェント(agentic AI)

  • Dataproc

    既存の Spark / Hadoop ワークロードをマネージドで実行するサービス。Dataflow(Beam)とは用途が異なる。

    前提: Dataflowマネージドサービス(管理の境界)

  • 暗号鍵(GMEK / CMEK / CSEK)

    GMEK=Google が管理する既定の鍵、CMEK=顧客が Cloud KMS で管理する鍵(ローテーション/無効化を制御)、CSEK=顧客が鍵そのものを供給。保存時・転送時とも既定で暗号化される。

    関連: Cloud KMS

  • Cloud SQL

    MySQL / PostgreSQL / SQL Server 互換のマネージド リレーショナルデータベース。一般的な業務アプリ向け。

  • ファインチューニング

    自社のラベル付きデータで基盤モデルを追加学習し、振る舞い・文体・専門知識を重みに内在化させる方法。RAGより手間大。

    前提: 基盤モデル

  • エージェント(agentic AI)

    単に文章を返すだけでなく、目的に向けて自律的に計画し、ツールを使い、複数ステップで行動する AI。

  • Model Garden

    Google 製・オープン・サードパーティの多様な基盤モデルを一覧から選んで使える Vertex AI のカタログ。

    前提: Vertex AI基盤モデル

  • Cloud Deploy

    GKE・Cloud Run・Anthos 向けのマネージドな継続的デリバリー(CD)サービス。開発→ステージング→本番のようなデリバリーパイプラインをテンプレート化し、カナリアやブルー・グリーンなどのデプロイ戦略、承認ゲート、ロールバックを標準機能として提供する。

    前提: Cloud RunGKE Enterprise(Anthos)デプロイ戦略(カナリア/ブルー・グリーン/ロールバック)

    関連: Cloud Build

  • 特徴量エンジニアリングと埋め込み/RAG

    特徴量エンジニアリングは学習・サービング向けにデータを整える作業。生成 AI では非構造化データを埋め込み(embeddings)にし、検索拡張生成(RAG)で関連情報を取り出して回答に使う。

    前提: RAG(検索拡張生成)

  • BigQuery ML のモデル種別

    データが BigQuery にあるとき SQL で学習/予測できるモデル群。分類/回帰、時系列予測の ARIMA_PLUS、レコメンドの行列分解、高精度な表形式のブーストツリー(XGBoost)、異常検知のオートエンコーダなどを課題で選ぶ。

    前提: BigQueryBigQuery ML

  • 分散訓練(Reduction Server/Horovod)とハイパーパラメータ調整

    大規模な訓練を効率化する手段。GPU データ並列の勾配集約(all-reduce)を専用ノードに肩代わりさせる Reduction Server、フレームワーク非依存の Horovod、精度向上のためのハイパーパラメータ調整(Vertex AI Vizier)。アクセラレータはワークロードで選ぶ(大規模 TF/JAX=TPU、汎用=GPU、端末推論=エッジ)。

    前提: Vertex AI

  • Vertex AI Model Monitoring(スキュー/ドリフト)

    本番モデルを継続的に評価し、訓練/サービングスキュー(訓練 vs サービングの入力分布の差)と特徴量/予測ドリフト(時間による変化)を検知してアラートする。しきい値超過で再訓練をトリガーする。ラベル遅延時はアトリビューション変化を代理指標にできる。

    前提: Vertex AI

  • Vertex AI の公開/限定公開エンドポイント

    オンライン推論のデプロイ先。インターネット公開は公開エンドポイント、VPC 内に閉じて低遅延/非公開にするなら限定公開エンドポイント(Private Service Connect)。需要追従は Vertex AI Prediction の自動スケールやコンテナ化サービングで行う。

    前提: Vertex AIPrivate Service Connect

  • Vertex AI Feature Store

    計算した特徴量を集約し、チームやモデル間で再利用する仕組み。訓練と推論で同じ特徴量を使い、重複計算と訓練/サービングスキューを防ぐ。推論時の低遅延取得はオンラインサービング、一括の訓練用はオフライン。

    前提: Vertex AIVertex AI Model Monitoring(スキュー/ドリフト)

  • Vertex AI Pipelines(Kubeflow/TFX)

    Kubeflow Pipelines や TensorFlow Extended(TFX)で定義した ML パイプラインを、マネージドでサーバーレスに実行するサービス。汎用(ML 以外含む)ワークフローの依存/スケジュールは Airflow ベースの Cloud Composer を使う。

    前提: Cloud ComposerVertex AI

  • A/B テスト(Vertex AI)

    同一エンドポイントに複数のモデルバージョンをデプロイし、トラフィック分割比率を指定して実際のリクエストで性能を比較する手法。指標が悪化すればトラフィックを即座に旧バージョンへ戻すロールバックが容易で、本番影響を抑えながら新モデルを検証できる。

    前提: Vertex AIデプロイ戦略(カナリア/ブルー・グリーン/ロールバック)

  • Dataflow

    バッチとストリーミングの両方に対応するデータ処理パイプラインのサービス。

  • Google Kubernetes Engine(GKE)

    マネージド Kubernetes。多数のコンテナを自動配置・スケール・自己修復しながら大規模に運用できる。

    前提: ML データ準備(エンコード/スケーリング/不均衡)

  • Spanner

    世界規模で強い整合性と高可用性を両立する分散リレーショナルデータベース。グローバルな基幹系に適する。

  • Colab Enterprise

    使い慣れた Colab のノートブック体験を Google Cloud の IAM・VPC・データガバナンスと統合したエンタープライズ版。個人向け Colab と異なりリソースは顧客の Google Cloud プロジェクト内で実行され、チームでの共同編集や権限管理がしやすい。手軽さ重視の共同作業に向く。

    前提: データガバナンス

  • API Gateway(Google Cloud)

    サーバーレスのバックエンド(Cloud Run/Functions/App Engine)の前段に置くフルマネージドな API ゲートウェイ。OpenAPI で定義し認証・鍵・モニタリングを担う。

    前提: App EngineCloud Runマネージドサービス(管理の境界)

  • Cloud Interconnect

    オンプレミスと Google Cloud を専用回線で接続するサービス(Dedicated/Partner)。高帯域・低遅延・SLA を提供し、手軽な暗号化トンネルの Cloud VPN と使い分ける。

    前提: Cloud VPN

  • Private Google Access

    外部 IP を持たない VM から Google API(Cloud Storage など)へプライベートに到達できるようにする設定。外向き一般通信の Cloud NAT とは目的が異なる。

    前提: Cloud NATCloud Storage

  • Cloud CLI エミュレータ

    Google Cloud CLI が提供する Firestore・Pub/Sub・Spanner などのローカル模擬環境。クラウドに接続せず開発・ユニットテストを高速化する(本番の代替ではない)。

    前提: FirestorePub/SubSpanner

  • 可観測性の三本柱(メトリクス・ログ・トレース)

    メトリクス(Cloud Monitoring・数値の傾向)、ログ(Cloud Logging・出来事)、トレース(Cloud Trace・リクエストの経路)。トレース ID でログとトレースを相関させて原因を特定する。

    関連: Cloud TraceCloud LoggingCloud Monitoring

  • Database Migration Service(Google Cloud DMS)

    MySQL/PostgreSQL などを Cloud SQL や AlloyDB へ継続的レプリケーション付きで移行する Google のマネージドサービス。最小ダウンタイムのカットオーバーを支援する。

    前提: AlloyDBCloud SQLマネージドサービス(管理の境界)

  • Private Service Connect

    インターネットを経由せず、特定のマネージドサービスや公開サービスへプライベート IP で接続する仕組み。公開 IP の露出を避けたい接続に使う。

    前提: マネージドサービス(管理の境界)

  • Cloud Router

    オンプレ/他ネットワークと BGP で動的に経路交換するルーター。ASN・ルート優先度/MED・認証を構成し、カスタムアドバタイズ/ラーン ルートで広告・学習する範囲を制御する。

    前提: ルート優先度

  • Vertex AI Model Registry

    学習済みモデルのバージョン・系統(リネージ)・評価指標・デプロイ状況を一元管理するリポジトリ。同じモデル名の下に複数バージョンをまとめて追跡でき、どのバージョンがどのエンドポイントにデプロイ中かを一目で把握できる。モデルガバナンスと再現性確保の起点となる。

    前提: Vertex AI

  • Vertex AI Experiments と TensorBoard

    実験の再現性のための追跡。Vertex AI Experiments はパラメータ/メトリクス/成果物を記録・比較し、Vertex AI TensorBoard は学習曲線などを可視化する。役割が補完的で併用する。

    前提: Vertex AI

  • RAG(検索拡張生成)

    社内文書などを検索してプロンプトに添え、根拠ある回答を生成する手法。ハルシネーション低減に有効。

  • YAML

    インデントで階層を表す、人が読み書きしやすいテキスト形式。CloudFormation や各種 IaC ツール、CI/CD パイプラインの設定ファイルで好まれ、同じデータを JSON とも相互変換できる。

    前提: JSON

  • Cloud DNS

    内部/外部の名前解決(ドメイン名から IP へ)を管理する Google Cloud のサービス。

  • Cloud NAT

    外部 IP を持たない VM から、インターネットへの外向き通信を可能にするサービス。

  • Cloud VPN

    オンプレミスや他ネットワークと Google Cloud を暗号化トンネルで接続するサービス。

  • GKE Autopilot

    GKE のクラスタ運用モードの一つで、ノードのプロビジョニング・スケーリング・アップグレード・セキュリティ強化まで Google がフルマネージドで行う。Pod 単位の課金で、ノードプールの構成や SSH アクセスは持てない代わりに運用負荷が最小になる。

    前提: マネージドサービス(管理の境界)ML データ準備(エンコード/スケーリング/不均衡)

  • マネージドインスタンスグループ(MIG)とインスタンステンプレート

    インスタンステンプレート(VM の設計図)に基づき同一構成の VM を作成し、オートスケールや自己修復を行う Compute Engine のグループ。

    前提: Compute Engine

  • Storage Transfer Service

    大量・継続的なデータを Cloud Storage へ転送するマネージドサービス。少量は gcloud/bq CLI が手軽。

    前提: Cloud Storageマネージドサービス(管理の境界)

  • Cloud KMS

    暗号鍵を作成・管理し、ローテーションや無効化を制御するマネージドな鍵管理サービス。CMEK の基盤。

    関連: 暗号鍵(GMEK / CMEK / CSEK)

  • ライフサイクルルール

    Cloud Storage で「作成から N 日後に削除」「N 日後に安いクラスへ移行」を自動化し、コストを最適化するルール。BigQuery では有効期限が同様の役割。

    前提: BigQueryCloud Storage

  • スケジュールされたクエリ

    BigQuery で定期的に同じクエリ(集計など)を自動実行する手軽な機能。複雑な依存は Cloud Composer。

    前提: Cloud ComposerBigQuery

  • App Engine

    フルマネージドな Web アプリ基盤(PaaS)。サーバー管理なしにアプリを公開でき、開発に集中できる。

    前提: マネージドサービス(管理の境界)

  • Cloud Logging

    ログの収集・検索・保管を担う Google Cloud Observability の機能。原因調査や監査に使う。

    関連: 可観測性の三本柱(メトリクス・ログ・トレース)

  • Cloud Monitoring

    メトリクスの監視・ダッシュボード・アラートを担う Google Cloud Observability の機能。

    関連: 可観測性の三本柱(メトリクス・ログ・トレース)

  • Conversational Agents

    自然言語で対話する対話型エージェント/チャットボットを構築し、顧客サポートなどを自動化するソリューション。

    前提: エージェント(agentic AI)

  • Looker

    分析結果をダッシュボードで可視化し、ビジネスでの活用を支えるビジネスインテリジェンス(BI)。

  • Pub/Sub

    イベントをリアルタイムに取り込み、複数のサービスへ配信するメッセージングサービス。ストリーミング取り込みに使う。

  • Vertex AI Agent Builder

    目的に向け自律的に行動するエージェントや検索アプリを構築するための Vertex AI の仕組み。

    前提: Vertex AIエージェント(agentic AI)

  • Cloud Billing(課金)

    請求先アカウントをプロジェクトに紐づけ、費用の確認・予算アラート・課金データの BigQuery エクスポートを行う仕組み。

    前提: 課金アカウントと予算BigQuery

  • Deployment Manager

    Google Cloud のネイティブな Infrastructure as Code サービス(YAML/Jinja/Python テンプレート)。非推奨化され 2026-03-31 にサポート終了予定で、Terraform ベースの Infrastructure Manager などへの移行が推奨される。

    前提: Infrastructure ManagerYAML

  • Filestore

    フルマネージドな NFS ファイルストレージ。Compute Engine VM や GKE から共有ファイルシステムとしてマウントし、低レイテンシの共有ストレージを提供する。

    前提: Compute Engineマネージドサービス(管理の境界)

  • ファイアウォールルール(VPC firewall rules)

    VPC 内外のトラフィックを許可/拒否するステートフルな規則。方向・優先度・ターゲット(タグ/サービスアカウント)・送信元で評価する。組織レベルの階層型ファイアウォールポリシーもある。

    前提: サービスアカウント(Service account)Cloud NGFW と階層型ファイアウォール

  • Gemma

    Google の軽量なオープンモデル群。Gemini と同じ研究・技術から派生し、オンデバイスや自前ホスティングでの利用・ファインチューニングに向く。

    前提: Geminiファインチューニング

  • Gemini Cloud Assist

    Google Cloud コンソール内で、ログ・メトリクス・トレースやリソース構成を分析し、トラブルシューティングやアーキテクチャ設計の提案を自然言語で行う AI アシスタント。運用担当者がコンソールを横断して原因調査する時間を短縮する目的で使う。

    前提: Gemini

    関連: Gemini Code Assist

  • Gemini Code Assist

    IDE 上でコード補完・生成・説明・レビューを支援する AI ペアプログラミング機能。個人向け無償枠と、社内コードベースを踏まえた補完やエンタープライズ管理が可能な Enterprise 版がある。VS Code や JetBrains 系 IDE の拡張として使う。

    前提: Gemini

    関連: Gemini Cloud Assist

  • JSON

    波括弧とキー・値のペアで構造化データを表す軽量なテキスト形式。API のリクエスト/レスポンスや IAM ポリシー・バケットポリシーのような権限定義など、機械可読性を重視する場面で広く使われる。

  • 線形回帰

    連続値のターゲットを、特徴量の重み付き線形結合として予測する基本的な教師あり学習モデル。解釈しやすく、回帰問題のベースラインとしてまず試されることが多い。

  • ロジスティック回帰

    線形結合の出力をシグモイド関数に通して 0〜1 の確率を得ることで、二値分類を行うモデル。名前に「回帰」とあるが実際には分類器であり、線形回帰同様に解釈しやすく分類問題のベースラインとしてよく使われる。

    前提: 線形回帰

  • Cloud External Key Manager(Cloud EKM)

    外部(自社/サードパーティ)の鍵管理基盤に保持した鍵で Google Cloud のデータを暗号化する仕組み。CMEK(Cloud KMS で顧客管理)よりさらに鍵主権を高める。

    前提: Cloud KMS暗号鍵(GMEK / CMEK / CSEK)

  • Binary Authorization

    デプロイするコンテナイメージの署名を検証し、信頼できる(出所が保証された)成果物だけを GKE / Cloud Run に許可する仕組み。サプライチェーン保護に使う。

    前提: Cloud Run

  • Cloud Run のリビジョンとトラフィック分割

    デプロイごとに作られる不変の単位がリビジョン。トラフィック分割で各リビジョンへ送る割合を制御し、カナリア公開やロールバックを行う。

    前提: Cloud Runデプロイ戦略(カナリア/ブルー・グリーン/ロールバック)

  • Cloud CDN

    外部 Application LB のバックエンドで有効化し、Google のエッジでコンテンツをキャッシュする CDN。オリジンは MIG/Cloud Storage/Cloud Run/インターネット NEG。更新時はキャッシュ無効化で古い内容を破棄する。

    前提: Cloud RunCloud Storage

  • Cloud NGFW と階層型ファイアウォール

    VPC 内通信を制御する次世代ファイアウォール。組織/フォルダに継承する階層型ポリシー、優先度で評価される実効ポリシー、Enterprise ティアの L7 検査(IPS)を持つ。タグ/サービスアカウントでマイクロセグメンテーションを実装する。

    前提: サービスアカウント(Service account)

  • Cross-Cloud Interconnect

    他のパブリッククラウドと Google Cloud を、インターネットを経由せず専用の物理接続で低遅延に結ぶサービス。マルチクラウド接続で Cloud VPN より高帯域・低遅延が必要なときに使う。

    前提: Cloud VPNCloud Interconnect

  • ネットワークエンドポイントグループ(NEG)

    ロードバランサのバックエンド単位。コンテナネイティブ(GKE)・サーバーレス(Cloud Run など)・インターネットのエンドポイントをまとめて登録できる。マネージドインスタンスグループ(MIG)と使い分ける。

    前提: マネージドインスタンスグループ(MIG)とインスタンステンプレートCloud Run

  • VLAN アタッチメント

    Cloud Interconnect と VPC(Cloud Router)を結ぶ論理接続。物理接続(Interconnect)を作った後、VLAN アタッチメントで実際の VPC へトラフィックを通す。

    前提: Cloud InterconnectCloud Router

  • BigLake

    Cloud Storage などのデータを移動せずに BigQuery から統一的に扱えるようにするストレージエンジン。レイクとウェアハウスを橋渡しする。

    前提: BigQueryCloud Storage

  • BigQuery Data Transfer Service

    SaaS や他のデータウェアハウスから BigQuery へデータを定期的に取り込むマネージドサービス。DB の移行は Database Migration Service と用途が異なる。

    前提: BigQueryマネージドサービス(管理の境界)

  • AlloyDB

    高性能な PostgreSQL 互換のマネージドデータベース。

  • 課金アカウントと予算

    費用を支払う単位。プロジェクトをリンクして使う(1 アカウントに複数プロジェクト可)。予算とアラートはしきい値で通知するのみで自動停止はしない。

  • 組織ポリシー(Organization Policy)

    リソース階層に沿って制約を継承・強制し、組織全体に一貫したルール(例: 特定リージョン以外の作成禁止)を適用する仕組み。IAM の許可とは別。

    前提: リソース階層

  • Cloud Storage のストレージクラス

    アクセス頻度で選ぶクラス:Standard(頻繁)/Nearline(月1)/Coldline(四半期)/Archive(長期低頻度)。低頻度ほど保存は安いが取り出しは高い。

    前提: Cloud Storage

  • VPC ネットワークピアリング

    2 つの VPC ネットワークを直接接続して相互に通信できるようにする仕組み。

    前提: VPC(Virtual Private Cloud)

  • Analytics Hub

    BigQuery のデータセットを、コピーを作らずに社内外の他組織と安全に共有・受領できるサービス。

    前提: BigQuery

  • Cloud Data Fusion

    コードをあまり書かずにビジュアルで ETL/ELT パイプラインを構築できるマネージドサービス。

    前提: マネージドサービス(管理の境界)

  • Dataform

    BigQuery 内の SQL ベースの変換(ELT)を、依存関係やバージョン管理とともに開発・運用できるサービス。

    前提: BigQuery

  • Looker Studio

    手軽にレポートやダッシュボードを作成・共有できる可視化(BI)ツール。

    前提: Looker

  • LookML

    Looker でデータのメトリクスやディメンションを定義するモデリング言語。指標の一貫性を保つ。

    前提: Looker

  • Transfer Appliance

    大量データを物理デバイスに格納して輸送し、Cloud Storage へ取り込むオフライン転送サービス。ネットワーク転送が現実的でない規模に向く。

    前提: Cloud Storage

  • 均一バケットレベルアクセス

    Cloud Storage で、オブジェクトごとの ACL を使わずバケット単位で IAM により権限を一元管理する推奨設定。簡潔で安全。

    前提: Cloud Storage

  • Amazon Managed Service for Prometheus (AMP)

    Prometheus 互換のマネージドなメトリクス収集/保存サービス。EKS/ECS などコンテナ環境のメトリクスを PromQL でクエリでき、スケールや保持を AWS に任せられる。Managed Grafana と組み合わせて可視化する構成が定番。

    前提: マネージドサービス(管理の境界)

  • 誤差逆伝播

    ニューラルネットワークの学習で、出力の誤差を出力層から入力層へ逆向きに伝えながら各重みの勾配を計算する手法。勾配降下法と組み合わせて重みを更新するために使われ、深層学習の学習アルゴリズムの中核をなす。

    前提: 勾配降下法

  • Cloud Functions

    「ファイルがアップされたら実行」のようなイベント駆動の小さな処理を動かすサーバーレスの関数サービス。

  • Firestore

    モバイル/Web アプリのデータ向けのスケーラブルなドキュメント型 NoSQL データベース。

  • GKE Enterprise(Anthos)

    オンプレミスや複数のクラウドにまたがって一貫した方法でコンテナを運用・管理できるプラットフォーム。ハイブリッド/マルチクラウドを実現する。

  • リソース階層

    組織→フォルダ→プロジェクト→リソースという Google Cloud の階層。プロジェクトが課金/権限の基本単位で、ポリシーは階層に沿って継承される。

  • Spot VM

    中断され得る代わりに大幅な割引が受けられる Compute Engine の VM。中断に強いバッチ処理などのコスト最適化に用いる。

    前提: Compute Engine

  • 決定木

    特徴量に対するしきい値で分岐を繰り返し、葉ノードで予測値を出す解釈しやすいモデル。単体では訓練データに過剰適合しやすく、深さの制限や剪定で抑える必要がある。回帰・分類の両方に使える。

  • Chirp

    Google の音声向け生成モデル。元来は多言語の音声認識(文字起こし)用の基盤モデルで、後継の Chirp 3 では HD 音声合成(Text-to-Speech)にも対応する。

    前提: 基盤モデル

  • データガバナンス

    どのデータを AI に渡してよいか、機微情報をどう保護するかを定める統制。生成 AI を安全に使う前提。

  • Gemini for Google Cloud

    コード補完・説明やクラウド運用のトラブルシュート助言など、開発・運用を支援する Gemini。

    前提: Gemini

  • Gemini for Google Workspace

    Docs・Gmail・Sheets・Slides・Meet などに Gemini を組み込み、文書作成・メール・要約・会議メモを支援する生産性ソリューション。

    前提: Gemini

  • Vertex AI Studio

    本格運用の前にプロンプトを手軽に試作・比較・検証できる Vertex AI の機能。

    前提: Vertex AI

  • Contact Center as a Service(CCaaS)

    クラウドで提供されるコンタクトセンター基盤の総称(SaaS 型でマルチチャネル対応、オンプレ設備不要。例:Amazon Connect、Genesys Cloud、Five9 等)。Google Cloud 文脈では Customer Engagement Suite に含まれる Google の CCaaS 製品が該当し、Conversational Agents や Agent Assist と組み合わせて顧客対応を自動化・支援する。

    前提: Conversational Agents

  • Classic VPN

    単一トンネルのゲートウェイで SLA 保証のない旧世代の IPSec VPN。ルートベース(動的)とポリシーベース(静的トラフィックセレクタ指定)の 2 方式があり、後者は特定の相手先ネットワーク機器との互換性のためだけに残っている。Google は非推奨とし、新規構築では HA VPN を案内する。

    前提: HA VPN

  • Cloud Code

    VS Code や IntelliJ 等の IDE に組み込む拡張機能。Kubernetes マニフェストや Dockerfile の作成支援、ローカルからの GKE/Cloud Run へのデプロイ、リモートクラスター上でのライブデバッグをエディタ内から行える。

    前提: Cloud Run

  • Cloud Endpoints

    OpenAPI/gRPC の API を Extensible Service Proxy 経由で管理し、認証・モニタリング・割り当てを付与する API 管理サービス。

    前提: gRPC

  • HA VPN

    冗長化された 2 本のトンネル(それぞれ別の外部 IP)を使い 99.99% の可用性 SLA を提供する、Google 推奨の IPSec VPN。オンプレミスや他クラウド・他 VPC との接続に使い、BGP による動的ルーティングを前提とする。新規構築では基本的にこちらを選ぶ。

  • VPC(Virtual Private Cloud)

    Google Cloud のソフトウェア定義ネットワーク。グローバルなリソースで、リージョンをまたぐサブネットを 1 つのネットワークに収容する。ルート・ファイアウォール・ピアリングで通信を制御する。

  • Workload Identity Federation(GCP)

    AWS・Azure・オンプレミス・CI/CD(GitHub Actions 等)といった Google Cloud 外部の ID プロバイダを信頼し、その発行するトークンと引き換えに一時的な Google Cloud 認証情報を得られる仕組み。サービスアカウント鍵のダウンロード・配布を避けたい外部システム連携で使う。

    前提: サービスアカウント(Service account)

  • Dataplane V2

    eBPF ベースで実装された GKE のネットワーキングデータプレーン。Kubernetes NetworkPolicy(Pod 間の L3/L4 通信制御)をカーネルレベルで高効率に強制し、フローログによる可視化も提供する。GKE 1.20 以降の新規クラスタで既定化が進んでおり、従来の iptables ベース実装より少ないオーバーヘッドで動く。

  • IP マスカレード(GKE)

    GKE の Pod がクラスタ外へ送信する通信の送信元 IP を、ノードの IP に変換(SNAT)する仕組み。既定の非マスカレード対象(変換しない宛先)は RFC 1918 等のプライベートアドレス範囲とリンクローカルアドレスで、ip-masq-agent の設定で対象 CIDR を追加・変更できる。この agent が DaemonSet として自動デプロイされるか、その既定設定がどうなるかは GKE のバージョンやクラスタ構成(Autopilot か Standard か、Dataplane V2 の有無等)によって異なる。

    前提: Dataplane V2

  • GKE Standard

    GKE のクラスタ運用モードの一つで、ノードプールのマシンタイプ・スケーリング設定・ノードへの SSH アクセスまで自分で構成できる。Autopilot より柔軟だが、ノードの容量管理やセキュリティパッチ適用の一部は利用者側の責任になる。

    前提: ML データ準備(エンコード/スケーリング/不均衡)

  • 勾配ブースティング

    弱い決定木を1本ずつ逐次的に追加し、直前までの予測誤差を縮めるように学習していくアンサンブル手法(代表実装は XGBoost・LightGBM)。表形式データに対する強力な既定手法として、多くのマネージド ML サービスに組み込みアルゴリズムとして用意されている。

    前提: 決定木

  • 勾配降下法

    損失関数の勾配(傾き)の反対方向へ、学習率で決まる歩幅ずつパラメータを更新して損失を最小化する最適化アルゴリズム。全データを使うバッチ型のほか、1件ずつ更新する確率的勾配降下法(SGD)や少量ずつ処理するミニバッチ型などの変種がある。

  • k-means クラスタリング

    教師なしで、データを k 個のクラスタに分ける代表的手法。各点を最寄りの重心へ割り当て→重心更新を反復する。k はエルボー法/シルエットで選ぶ。スケールに敏感なので標準化が前提。顧客セグメンテーション等に使う。

    前提: ML データ準備(エンコード/スケーリング/不均衡)

  • ワンホットエンコーディング

    カテゴリ変数を、各カテゴリに対応する 0/1 のフラグ列へ変換する手法。順序のないカテゴリ(色・地域)に使い、ラベルエンコーディング(整数化=誤った順序を与える)の代わりに用いる。次元が増えるため高カーディナリティでは別手法(埋め込み等)を検討。

    前提: ML データ準備(エンコード/スケーリング/不均衡)

  • p値

    帰無仮説が正しいと仮定した場合に、観測されたデータと同等以上に極端な結果が出る確率。値が小さいほど帰無仮説を棄却する根拠が強く(統計的に有意)、A/B テストなどの仮説検定の判断基準として使われる。

    前提: A/B テスト(Vertex AI)

  • Cloud Trace

    分散システムのリクエストの経路(スパン)を追跡し、レイテンシのボトルネックを特定する分散トレースのサービス。メトリクス(Monitoring)やログ(Logging)とは別の観測軸。

    関連: 可観測性の三本柱(メトリクス・ログ・トレース)

  • Infrastructure Manager

    Terraform をマネージドで実行する Google Cloud のサービス。インフラをコード化(IaC)して再現可能にし、CI/CD と PR でレビュー・監査する。

  • 移行戦略(リフト&シフト/改善移行/リファクタ)

    リフト&シフト=そのまま移行(最速・変更最小)、改善して移行=少し最適化、リファクタリング=クラウドネイティブに作り替え(手間大・効果大)。要件で選ぶ。

  • アプリケーションデフォルト認証情報(ADC)

    アプリが Google Cloud へ認証する際の標準的な資格情報の解決方法。サービスアカウントや Workload Identity Federation と組み合わせ、鍵の直書きを避ける。

    前提: サービスアカウント(Service account)

  • Artifact Registry

    コンテナイメージや言語パッケージを保存・管理するレジストリ。Cloud Build でビルドした成果物の保存先。

    関連: Cloud Build

  • Cloud SQL Auth Proxy

    公開 IP を露出させずに、IAM 認証と暗号化で Cloud SQL へ安全に接続するためのプロキシ。アプリからの DB 接続の推奨手段。

    前提: Cloud SQL

  • gRPC

    HTTP/2 上で動く低遅延・型付き(Protocol Buffers)の RPC フレームワーク。内部のサービス間通信に向く。公開 Web には REST も選ぶ。

  • Memorystore

    Redis / Memcached 互換のフルマネージドなインメモリキャッシュ。頻繁な読み取りをキャッシュしてレイテンシを下げる。永続ストアではない。

    前提: マネージドサービス(管理の境界)

  • Secret Manager

    API キー・パスワード・証明書などのシークレットを安全に保管・取得・ローテーションするマネージドサービス。コードへの埋め込みを避ける。

    前提: マネージドサービス(管理の境界)

  • 署名付き URL

    Cloud Storage のオブジェクトへ、期限付き・限定的なアクセスを公開せずに付与する URL。バケット全体を公開するのとは異なる。

    前提: Cloud Storage

  • メンテナンスウィンドウ

    マネージドデータベースの計画的なメンテナンス(パッチ/マイナーバージョン更新等)を実施する時間帯。可用性要件に合わせ、業務影響の小さい時間帯に設定して計画停止を制御する。

    前提: ウィンドウと遅延データ(ストリーミング)

  • リバースレプリケーション

    移行のカットオーバー後に新環境から旧環境へ書き戻す仕組み。問題発生時に旧環境へ安全に切り戻すためのロールバック保険になる。

    前提: デプロイ戦略(カナリア/ブルー・グリーン/ロールバック)

  • Artifact Analysis

    コンテナイメージやパッケージの既知の脆弱性を検出するスキャン。Binary Authorization(署名済みのみデプロイ可)とは役割が別で、検出と強制を組み合わせて使う。

    前提: Binary Authorization

  • 合成モニタ

    エンドポイントやワークフローを能動的に定期チェックし、ユーザー視点で外形監視する仕組み。受動的な監視と併用して問題を先回りで検知する。

    前提: Workflows

  • Cloud DNS ルーティングポリシーと分割ホライズン

    Cloud DNS の高度な解決機能。ジオロケーション(送信元地域で応答変更)とフェイルオーバー(プライマリ障害でバックアップへ)のルーティングポリシー、公開/非公開ゾーンで同名を別解決する分割ホライズン DNS を含む。

    前提: Cloud DNS

  • 動的ルーティングモード(グローバル/リージョナル)

    Cloud Router が学習した BGP 経路を伝播する範囲を決める VPC の設定。リージョナルは同一リージョンのみ、グローバルは全リージョンへ伝播する。複数リージョンへ広げるにはグローバルが必要。

    前提: Cloud Router

  • ハイブリッド DNS(転送ゾーン/インバウンドポリシー/DNS ピアリング)

    オンプレと Cloud DNS の双方向の名前解決を組む構成。転送ゾーンは Cloud からオンプレへ問い合わせ、インバウンドサーバーポリシーはオンプレから Cloud を解決、DNS ピアリングは別 VPC のゾーンを参照する。

    前提: Cloud DNS

  • ルート優先度

    同一宛先に複数のルートがあるときに、どれを採用するかを決める値。値が小さいほど優先される。ネットワークタグと組み合わせて適用先を絞れる。

  • Secure Web Proxy

    外向き(egress)の通信を URL や SNI に基づいて許可リスト制御するプロキシ。一般インターネット外向きの Cloud NAT とは異なり、「どこへ出てよいか」をアプリケーション層で制御する。

    前提: Cloud NAT

  • BI Engine とマテリアライズドビュー

    BI Engine は BigQuery のインメモリ分析を高速化する。マテリアライズドビューはよく使う集計を事前計算しておく。ダッシュボードの応答を速くする別々の手段(併用可)。

    前提: BigQuery

  • BigQuery Editions と予約(reservations)

    安定利用のコンピュート容量を予測可能なコストで確保する仕組み。少量・不定期はオンデマンドが向く。

    前提: BigQuery

  • パーティションとクラスタリング(BigQuery)

    パーティションはテーブルを日付などで分割し、クラスタリングはよく絞る列で行を整列する。どちらもスキャン量を減らし BigQuery のコスト/性能を最適化する。

    前提: BigQuery

  • ウィンドウと遅延データ(ストリーミング)

    ストリーミングでは、時間で区切って集計するウィンドウと、遅れて到着するデータ(late data)をウォーターマークと許容遅延で扱う設計が要る。バッチは溜めてまとめて処理。

  • Vertex Explainable AI

    モデルの個々の予測に対し、どの特徴量がどれだけ寄与したか(特徴量アトリビューション)を数値化して示す Vertex AI の機能。表形式データにはサンプリング Shapley 等、画像データには統合勾配等の手法を使い分ける。規制対応の説明責任・デバッグ・バイアス検出に使う。

    前提: Vertex AI