タグ: GCP

【Google認定MLエンジニア】セキュリティ対策のベストプラクティス：Vertex AI Workbench編

Google CloudのVertex AI Workbenchは、機械学習プロジェクトにおいて強力なツールですが、特に医療・金融・政府データなどの機密性の高いデータを扱う際には、堅牢なセキュリティ対策が求められます。本記事では、GCP認定Professional Machine Learning Engineer試験で出題されたシナリオ問題を元に、Vertex AI Workbenchにおけるセキュリティ対策を以下の6つのカテゴリに整理して紹介します。

1. アクセス制御（認証・認可）

✅ ベストプラクティス

IAM（Identity and Access Management）ロールの設定
→ 誰がVertex AI Workbenchにアクセスできるか、何ができるかを厳格に制御。
監査ログ（Audit Logging）の有効化
→ 誰がいつ、どのリソースにアクセス・変更したかを記録。

❌ よくある誤解

Cloud ArmorやVPC Flow Logsではアクセス管理や監視はできない。

2. データ暗号化（転送中・保存時）

✅ ベストプラクティス

TLSによる転送中のデータ暗号化
→ Vertex AI WorkbenchとGCPサービス間の通信を安全に。
CMEK（Customer Managed Encryption Keys）による保存データの暗号化
→ 鍵を顧客自身が管理することで、より厳密な制御が可能。
KMS（Key Management Service）の利用
→ 暗号鍵のライフサイクルを安全に管理。

❌ よくある誤解

Cloud Storageのデフォルト暗号化だけではセキュリティ強化とは言えない（カスタム鍵の活用が重要）。

3. ネットワーク境界の制御

✅ ベストプラクティス

VPC Service Controlsの導入
→ 他のプロジェクトやネットワークからのデータ漏洩を防ぐ仮想境界を構築。

❌ 注意点

VPCはアクセス制御や監査の代替にはならない。
地域制限（region-based VPC Service Controls）だけでは完全なセキュリティ対策にならない。

4. 監視とインシデント対応

✅ ベストプラクティス

Security Command Centerの導入
→ 脅威検知、リスク評価、対応までを一貫して支援。

❌ 陥りやすい罠

自動化（Cloud Functionsなど）でのセキュリティ監視は便利だが、直接的なセキュリティベストプラクティスではない。

5. データ損失防止・匿名化

✅ 選択的に有効

DLP API（Data Loss Prevention API）の活用
→ 機密データをVertex AI Workbenchに送信する前にマスキングや削除を行う。

❌ 誤用例

DLP APIは便利だが、アクセス制御やネットワーク監視の代替にはならない。

6. その他の補足的対策

❌ あまり推奨されない（試験で不正解の選択肢になったもの）

2FA（二要素認証）のみを設定すること
→ 認証は強化されるが、暗号化・監査・監視の代替にはならない。
Cloud ArmorによるDDoS対策
→ ネットワークレベルでは有効だが、Vertex AIのデータセキュリティや監査には無関係。

総括：試験で問われやすい組み合わせ

セキュリティ目的	ベストプラクティスの例（正解選択肢）
認証・認可	IAM、Audit Logging、IAP（補足）
暗号化	TLS、CMEK、KMS
ネットワーク境界	VPC Service Controls
脅威監視	Security Command Center
データ損失防止	DLP API（補助的に）

試験対策TIPS

IAMだけでは不十分。Audit Loggingとセットで使うことが必須。
“便利”なもの（e.g., DLP, Cloud Armor, VPC Logs）はセキュリティの本質対策としての得点にならないことがある。
各対策がどの「目的」（認証、暗号化、監査、監視）に対応しているかを意識して選択する。

このように、Vertex AI Workbenchのセキュリティでは「認証・認可」「暗号化」「監査」「監視」の4本柱が基本です。GCP MLエンジニア試験でもこの構造を意識すれば、高得点が狙えます。

2025年5月6日

GCPにおけるJupyter Backendの選定と構成ポイント

～Vertex AI Workbench、Dataproc、TFX連携を中心に～

はじめに

GCP上でのJupyterノートブック環境の構築は、データサイエンティストやMLエンジニアがモデル開発・データ分析を行う上で不可欠です。本記事では、GCP Professional Machine Learning Engineer試験で問われる「Jupyter backend selection」に関する代表的なユースケースと、環境ごとの構成ポイントをまとめます。

1. Vertex AI Workbench を使った BigQuery 分析

ユースケース

データサイエンティストが BigQuery上の大規模データ を Jupyter環境で分析 。

必要な構成変更

✅ Vertex AI Workbenchのインストール
✅ **
✅ 正しい pandas_gbq のimport文の使用** （誤ってpandasから読み込んでいるケースに注意）

不要な変更

❌ 認証設定はNotebook実行環境で自動付与される
❌ クエリ構文自体はBigQuery仕様に準拠していれば問題なし

試験対策ポイント

pandas_gbq は from pandas_gbq import read_gbq のように正確にインポート
vaiw.display(df) のようなVertex AI Workbench固有関数の使用に慣れる

2. Dataproc を用いた Jupyter with Spark

ユースケース

分散処理が必要な大規模データ分析や、Spark MLlibを活用したモデル開発

必須構成

✅ --optional-components=ANACONDA,SPARK,JUPYTER のように

Jupyter および Spark をオプションコンポーネントとして追加する

✅ 単一ノード構成（--single-node）でもテスト環境としては有効

試験対策ポイント

--image-version によって使えるコンポーネントが制限される場合があるため、バージョン互換 も確認する

3. TensorFlow Extended (TFX) + Jupyter の統合

ユースケース

MLパイプラインの定義・テスト をJupyter上で行い、TFXによるデプロイまで進める

構成の必須ポイント

✅ tfxモジュールの正確なimport（import tfx.orchestration.pipeline など）
✅ components=[] にてパイプライン構成要素（ExampleGen, Trainer等）を明示的に追加

注意点

❌ LocalDagRunner() はローカル実行用で問題なし
❌ Cloud SQLとの接続（metadata_path）は不要な場合が多い

4. DataprocでのBigQuery連携の最適化

ユースケース

SQLでBigQueryからデータ抽出・整形を行い、DataprocのSpark処理と連携

構成変更ポイント

✅ SQLクエリの最適化 （不要なカラムの除外、絞り込みの明確化など）
✅ テーブル作成時のパーティショニング の追加でパフォーマンス改善

試験対策ポイント

CREATE TABLEの記述時に PARTITION BY を使うとクエリ高速化に有効

まとめ：Backend選定時の意思決定表

使用目的	推奨Backend	主な特徴	試験で問われる設定ポイント
BigQuery分析	Vertex AI Workbench	GUI付きJupyter、pandas_gbq連携	vaiw.display(), pandas_gbq import
Spark分析	Dataproc	分散処理、スケーラブル	–optional-components へのSPARK/JUPYTER追加
MLパイプライン	Vertex AI or local Jupyter + TFX	パイプライン開発・実験向け	正しいTFX importとcomponents定義
大規模SQL前処理	Dataproc + BigQuery	SQL最適化、Spark処理前段	SQL最適化＋パーティショニング

試験対策アドバイス

構文エラーではなく構成ミスに注目！

各問題で問われるのは、多くの場合構文そのものより ライブラリのimport や 必要コンポーネントの指定漏れ 。

単一ノード vs 複数ノードの判断は問題文の文脈に依存 。

試験では「チームで使う」か「個人でローカルテスト」かを見極めるのがポイント。

Vertex AIとDataprocの使い分け ：

分析・探索的作業ならVertex AI、スケーラブル処理や本番デプロイを意識するならDataprocが主流。

2025年5月6日

【Google認定MLエンジニア】機械学習パイプラインにおける機密データの取り扱い

概要

機械学習パイプラインで機密データ（PII：Personally Identifiable Information）を扱う際には、プライバシー保護とコンプライアンス遵守のために、適切な 匿名化（Anonymization） や マスキング（Masking） の処理が必須です。本記事では、GCP認定MLエンジニア試験で問われる「Handling Sensitive Data」に関するベストプラクティスを、代表的な出題形式をもとに体系的に整理します。

1. 基本原則と必要な対応

対応項目	概要
機密列の削除	クレジットカード番号や氏名などは、不要であれば完全に削除するのが最も安全な対応。
ハッシュ化（Hashing）	データを一方向に変換し、復元不能にする手法。クレジットカード番号やメールアドレスなどで使用。
マスキング（Masking）	部分的に見せて、一部を伏せる。名前や電話番号などの一部可視が許容されるケースで使用。
フォーマット変更（日付など）	生年月日は `DATE_TRUNC()` などで日単位→月単位に変換し、特定性を下げる。
暗号化（Encryption）	一部のデータでは保存時の暗号化が要求されるが、マスキングやハッシュと併用することもある。

2. 出題パターンと対応例

📌 パターン1：SQLベースのデータ匿名化（BigQuery）

代表問題

SELECT
  name,
  address,
  credit_card_number,
  birthdate,
  hash(email) AS anonymized_email
FROM customer_data;

対応

✅ credit_card_number の削除
✅ credit_card_number のハッシュ化（両方OK。出題意図次第）
⚠️ name, address はマスキング不要な場合もあり
❌ DATE_TRUNC() だけでは不十分な場合あり

📌 パターン2：Apache Beam によるJavaコードのマスキング

代表コード抜粋

fields[2] = "*****"; // クレジットカード番号のマスキング

対応

✅ より安全なマスキング手法に変更（例えば SHA256 + サルト）
✅ 他の機密列（氏名など）もマスキング
❌ この場面では暗号化は不要とされることが多い

📌 パターン3：Python（pandas）でのHIPAA対応

代表コード抜粋

df['name'] = 'REDACTED'
df['ssn'] = 'XXX-XX-XXXX'
df['birthdate'] = df['birthdate'].apply(lambda x: x.strftime('%Y-%m'))

対応

✅ name カラムの削除
✅ 全ての機密列が正しく匿名化されているか確認
⚠️ birthdateの処理は緩やかな対応でも許容されることが多い

📌 パターン4：BigQueryでのPII処理とマスキング

代表コード抜粋

SELECT
  full_name,
  email,
  REGEXP_REPLACE(phone, r'\d', '*') AS masked_phone
FROM raw_data;

対応

✅ full_name のマスキング
✅ email のハッシュ化または部分マスキング
❌ 暗号化はこの文脈では不要

3. 試験対策ポイント

✅ EXAM FOCUS

機密情報（クレジットカード番号、氏名、住所、メール、電話番号）は削除 or ハッシュ化 or マスキング
SQL/Java/Python問わず データ処理ロジックを読める力 が必要
暗号化やスキーマ検証は、問題文の文脈次第で「不要」とされるケースあり

⚠️ CAUTION ALERT

hash() や REGEXP_REPLACE() のような関数処理が適切かを吟味
HIPAA, GDPR などの規制準拠かどうかに注意
一部の出題では「暗号化は不要」「検証は仮定済み」とされることもある

まとめ

GCP MLエンジニア試験では、「実装の文脈」と「規制の目的」を両立して考える力が求められます。単なる暗号化・マスキングだけでなく、不要な列の削除や、処理の十分性判断も含めて対策しましょう。

2025年5月3日

【Google認定MLエンジニア】Vertex AI Feature Storeにおける特徴量エンジニアリング完全ガイド

✅ はじめに

Vertex AI Feature Store は、GCP上で機械学習パイプラインにおける特徴量の生成・バージョン管理・共有・再利用を一元管理できる重要なコンポーネントです。本記事では、試験にも頻出の「特徴量エンジニアリングに関する設問」をベースに、実務・試験の両面で活用できる知識を体系的にまとめます。

📌 基本概念：Vertex AI Feature Store の役割

機械学習における特徴量を一元的に保存・管理
トレーニングとオンライン推論において一貫性ある特徴量を提供
他プロジェクトやチームと再利用・共有が可能
特徴量のバージョン管理と系譜管理（lineage） を内蔵

🔧 特徴量エンジニアリングにおける4つの中核タスク

1. 特徴量の作成（Feature Creation）

正解：Vertex AI Feature Store を直接使用して作成（例: create_feature メソッド）
非推奨：
- 外部の BigQuery や Dataflow を介しての前処理（無駄なレイヤー追加）
- TFX を使った変換（実現可能だが非効率）

✅ 試験のポイント：

「Vertex AI の組み込みツールを使うのが最も効率的」と覚えておく。

2. 特徴量のバージョン管理（Feature Versioning）

正解：feature versioning を Vertex AI Feature Store の機能で直接実装
利点：
- モデルの再学習やアップデートにおいて変更履歴を追跡できる
- チーム内で一貫したデータ基盤が保てる

✅ 試験のポイント：

「全問共通で登場、最重要項目」：すべての正答選択肢に含まれていた。

3. 特徴量の共有と再利用（Feature Sharing & Reuse）

正解：export_feature 関数を使って他チーム・プロジェクトと共有
試験での立ち位置：
- 主役ではないが、再利用性とコラボレーションを促進する副次的ベストプラクティス

4. 特徴量の系譜管理（Lineage Tracking）

正解：Vertex AI の組み込みツールで lineage をトラッキング
意義：
- どのデータからどの特徴が生まれたか追跡でき、データ品質とコンプライアンス向上に寄与

🚫 非推奨パターンと注意事項（CAUTION ALERT）

方法	理由
Dataflow や BigQuery による外部前処理	機能的には可能だが、非効率で複雑化を招く
Vertex AI Workbench での特徴量管理	できるが、Feature Storeの専用機能の方が効率的
TFX での変換処理	Vertex AI内で完結すべき処理を外部に出すのは非効率

📝 試験に向けた要点まとめ（EXAM FOCUS）

🔹 **「バージョン管理」**は最優先で覚えるべき。
🔹 **「Vertex AI Feature Store を直接使う」**が前提。
🔹 「前処理や統合を外部ツールで行う」ことは誤答になりやすい。
🔹 「Lineage管理とFeature共有」も適切な文脈で選ぶと得点につながる。

📚 おわりに

Vertex AI Feature Store は、単なる特徴量保存の場所ではなく、データ品質・共有性・変更追跡性すべてを担保する基盤です。効率的な設計と運用は、モデルの精度だけでなく、チーム全体の生産性にも直結します。試験では上記のベストプラクティスを意識しながら、選択肢のニュアンスに注意しましょう。

2025年5月1日

【Google認定MLエンジニア】効率的なトレーニングのためのデータ整理

効率的なデータ整理と前処理は、スケーラブルかつ高精度な機械学習（ML）モデルの構築において重要です。Google Cloudは、データの種類やMLワークフローに応じたさまざまなツールとサービスを提供しています。本ガイドでは、効率的なトレーニングのためのデータ整理について、GCP Professional ML Engineer認定に沿った体系的なベストプラクティスを紹介します。

1. 基本原則

自動化: 手動エラーを減らし、一貫性を向上。
スケーラビリティ: 大規模データセットへの対応が必要。
MLライフサイクル全体の一貫性: データの取り込みからデプロイまで統一的に管理。
リアルタイムとバッチ処理の両立: ストリーミングとバッチの両ワークフローをサポート。
特徴量の一貫性: トレーニングと推論で特徴量を一致させる。

2. ツールとサービス

a. Vertex AI Pipelines

用途: 前処理、トレーニング、デプロイメントまでのMLワークフロー自動化。
強み: 一貫性、スケーラビリティ、完全自動化。
対象データタイプ: 全データタイプ（表形式、画像、音声、時系列）。

b. Dataflow

用途: 大規模データのバッチ/ストリーミング処理、データ拡張。
強み: 高いスケーラビリティと効率性。
対象データタイプ: 全データタイプ、特にリアルタイムストリーミングや大規模データ。

c. Vertex AI Feature Store

用途: 表形式特徴量の一貫した管理と提供。
強み: 特徴量の一貫性確保、重複排除。
対象データタイプ: 表形式（音声、画像、時系列データには不向き）。

d. Cloud Storage

用途: 生データ（画像、音声、テキスト）の格納。
強み: 大容量データに対応可能なコスト効率の良いストレージ。
対象データタイプ: 全データタイプ。

e. BigQuery

用途: 大規模データセット（主に表形式）のクエリ処理、音声テキストの検索。
強み: 高速な分析クエリ処理。
対象データタイプ: 表形式・文字起こしテキスト。

f. Cloud Speech-to-Text API

用途: 音声データをテキストに変換。
強み: 音声の自動文字起こし、後続処理が容易。
対象データタイプ: 音声。

3. データタイプ別ベストプラクティス

A) 表形式データ（例：購買履歴）

特徴量管理: Vertex AI Feature Store を使用。
前処理: Dataflow でバッチ/ストリーミング処理。
自動化: Vertex AI Pipelines でワークフローを自動化。

推奨戦略:

Vertex AI Feature Store（特徴量の一貫性管理）。
Dataflow（リアルタイム/バッチ前処理）。

B) 音声データ（例：音声認識）

格納: Cloud Storage に音声ファイルを保存。
文字起こし: Cloud Speech-to-Text API を利用。
前処理: Dataflow で音声またはテキストデータを前処理。

推奨戦略:

Cloud Storage + Dataflow（格納と前処理）。
Cloud Speech-to-Text API + BigQuery（文字起こしとクエリ処理）。

C) 画像データ（例：ラベル付き画像）

格納: Cloud Storage に画像を保存。
前処理・拡張: Dataflow で画像前処理やデータ拡張を行う。
自動化: Vertex AI Pipelines で前処理とトレーニングを自動化。

推奨戦略:

Cloud Storage + Vertex AI Pipelines（格納と自動化）。
Dataflow（前処理と拡張）。

D) 時系列データ（例：金融予測）

前処理・拡張: Dataflow で欠損データ処理やデータ拡張。
自動化: Vertex AI Pipelines でワークフローを自動化。

推奨戦略:

Vertex AI Pipelines（エンドツーエンドの自動化）。
Dataflow（前処理と拡張）。

4. よくある落とし穴

手動前処理（Cloud FunctionsやSQL）: エラーが発生しやすく、スケーラビリティが低い。
Feature Storeの誤用: 表形式特徴量専用であり、生の音声・画像・時系列データには不向き。

5. まとめ表

データタイプ	格納	前処理	特徴量管理	自動化
表形式	Cloud Storage	Dataflow	Vertex AI Feature Store	Vertex AI Pipelines
音声	Cloud Storage	Dataflow、Speech-to-Text	なし	Vertex AI Pipelines
画像	Cloud Storage	Dataflow（拡張含む）	なし	Vertex AI Pipelines
時系列	Cloud Storage	Dataflow（拡張含む）	なしまたはPipelines内で管理	Vertex AI Pipelines

6. 試験対策ポイント

自動化・スケーラブルなソリューションを優先: Dataflow と Vertex AI Pipelines が中心。
Vertex AI Feature Storeは表形式特徴量専用。
手動処理（Cloud FunctionsやSQL）は避ける: スケーラビリティや信頼性が低下。

2025年4月27日

【Google認定MLエンジニア】Google Cloud API活用ガイド〜Vision・Natural Language・Speech・Translation APIの活用戦略〜

✅ 概要

Google Cloud の ML API群（Cloud Vision API、Natural Language API、Speech-to-Text API、Translation API）は、エンタープライズレベルのMLソリューションを短期間で構築・運用するための強力なツールです。
この単元では、試験で問われやすい APIの活用場面・連携サービス・設計上の注意点 について、代表的なユースケースに基づいて解説します。

📷 1. Cloud Vision APIの活用（画像認識・商品検索）

🔍 主な使用例

アパレル小売業における、アップロード画像からの服のカテゴリ推定と類似商品の推薦。

🎯 有効な戦略

label detectionで衣類カテゴリを抽出し、BigQueryで分析
product search機能を使い、類似商品を自動検索

💡 関連サービス

BigQuery ML（分析基盤として）
Cloud Functions / Vertex AI（補助的役割）

⚠ 試験注意点

正確な推薦には product search の活用が不可欠
自動化ばかりに頼らず、ユーザー体験の質を考慮

💬 2. Natural Language APIの活用（カスタマーサポート・チャットボット）

🔍 主な使用例

通信事業者のチャットボットにおいて、大量テキストデータからキーワード抽出・即時応答を行う。

🎯 有効な戦略

entity analysis により文脈に応じたトピック抽出
Cloud Functions によるリアルタイム応答処理

💡 関連サービス

Vertex AI Workbench（継続学習用に適応）
Pub/Sub や TFX はこの用途では適さない

⚠ 試験注意点

リアルタイム処理には Cloud Functions が最適
学習環境とリアルタイム応答の機能は役割が異なる

🔁 1. Pub/Sub（Cloud Pub/Sub）とは？

🧭 概要

Cloud Pub/Sub は、Google Cloud の メッセージキューサービス です。

「Publisher（送信者）」が送ったメッセージを、
「Subscriber（受信者）」が 非同期・リアルタイムで受け取る

というアーキテクチャで、イベント駆動型アプリケーション構築に活用されます。

🧩 代表的な用途

IoTセンサーからのリアルタイムデータ送信
マイクロサービス間の非同期通信
ログ収集とリアルタイム分析（例：BigQueryとの連携）

❌ 試験上の注意点

「Pub/Subはテキスト処理や意味理解をするわけではない」
Pub/Sub はあくまで データを運ぶインフラ に過ぎないため、チャットボットのような 自然言語理解が必要な処理には不向き。

⚙️ 2. TFX（TensorFlow Extended）とは？

🧭 概要

TensorFlow Extended（TFX） は、Googleが開発した MLパイプラインのためのフレームワーク。

データ処理
モデル学習
モデル評価
モデルのデプロイ

までを一気通貫で自動化し、再現性の高い機械学習運用を可能にします。

🧩 代表的な用途

モデル開発の自動化・標準化
トレーニングから推論サービングまでの一貫運用
データのバリデーションやバイアスチェック

❌ 試験上の注意点

「TFXはバッチ処理向け。リアルタイム処理には不向き」
TFXは 音声認識やチャット応答のような即時性が求められる処理には適しておらず、学習・運用の自動化に特化しています。

✅ 試験対策用まとめ表

項目	Pub/Sub	TFX（TensorFlow Extended）
主な役割	非同期メッセージ配送	MLパイプライン構築・運用自動化
主な用途	イベント通知、IoTデータ送信	学習〜評価〜サービングの自動化
適する場面	ストリーム処理、ログ処理	モデル学習・再学習・評価・監視
不向きな場面	テキスト意味理解、音声即時応答	リアルタイム制御、即時応答型アプリ

🎯 ポイントまとめ

Pub/Sub = データを届ける役割（配送係）
TFX = モデルを作って届けるための工場（パイプライン管理）
どちらも「補助的な存在」であり、主要APIの処理を担うものではない

試験では「本質的なAPI処理（画像分類・テキスト理解など）を誰が担っているか？」という視点を忘れずに！

🎙 3. Speech-to-Text APIの活用（音声アシスタント）

🔍 主な使用例

スマートホームにおける、音声コマンドの認識・リアルタイム制御。

🎯 有効な戦略

streaming recognitionで継続的音声入力に対応
Cloud Functionsでコマンドに基づくデバイス制御を即時実行

💡 関連サービス

Cloud Run（デプロイ用だがリアルタイム制御には不向き）
Vertex AI ExperimentsやTFXは精度向上には良いが、本用途では補助的

⚠ 試験注意点

連続音声・リアルタイム性を重視した構成が求められる

🌐 4. Translation APIの活用（グローバル展開・多言語化）

🔍 主な使用例

大量の製品情報やレビューを多言語に翻訳し、ピークトラフィックにも耐えるWebアプリを構築。

🎯 有効な戦略

batch translation で高効率翻訳処理
Cloud Run でピーク時にスケーラブルな翻訳サービスを維持

💡 関連サービス

Cloud Storage（翻訳後の保存用途）
Vertex AI Model Monitoring（翻訳の品質保証には補助的）

⚠ 試験注意点

高ボリューム翻訳では リアルタイム翻訳に依存しすぎない
Cloud Run はスケーラビリティ確保のキーテクノロジー

🧠 まとめ：試験対策としてのポイント

API	適用用途	連携すべきサービス	試験での差別化ポイント
Cloud Vision API	類似商品検索、画像分類	BigQuery, Product Search	ラベル検出＋商品検索機能の組合せを理解
Natural Language API	顧客対応チャットボット	Cloud Functions	リアルタイム応答＋エンティティ抽出
Speech-to-Text API	音声コマンド処理	Cloud Functions	ストリーミング＋即時処理連携が鍵
Translation API	多言語翻訳・スケール処理	Cloud Run	バッチ処理＋スケーラビリティ確保が重要

🛡 試験でのよくある誤答パターン

Vertex AI系のサービスは「学習管理・改善」に特化、初期のリアルタイム処理には向かない
TFXはバッチ処理やMLパイプライン用であり、リアルタイム処理には不適
Cloud RunやCloud Storageは補助的な存在で、API処理の中核ではない

💡この単元では「どのAPIをどの目的で使うか」に加えて、「補完するGCPサービスとの組合せ」が理解できているかがカギです。

2025年4月20日