<style> .gcm26-hero{padding:clamp(26px,5vw,46px);border-radius:24px;color:#fff;background:linear-gradient(125deg,#182943,#315a83 54%,#487f87)}.gcm26-hero h2{color:#fff;margin:.25em 0}.gcm26-kicker{color:#c5ebff;font-size:.8rem;font-weight:800;letter-spacing:.12em}.gcm26-grid{display:grid;grid-template-columns:repeat(3,minmax(0,1fr));gap:12px;margin:22px 0}.gcm26-card{padding:18px;border:1px solid #c9dce7;border-radius:15px;background:#f1f7fb}.gcm26-card strong{display:block;color:#276b8e;font-size:1.12rem;margin-bottom:7px}.gcm26-flow{display:grid;grid-template-columns:repeat(5,minmax(0,1fr));gap:8px;margin:21px 0}.gcm26-step{padding:14px;border:1px solid #c3d9e2;border-radius:13px;background:#edf6f9}.gcm26-step b{display:block;color:#236f8b}.gcm26-table{overflow-x:auto;margin:20px 0}.gcm26-table table{width:100%;min-width:670px;border-collapse:collapse}.gcm26-table th,.gcm26-table td{padding:11px;border:1px solid #c8dbe4;text-align:left;vertical-align:top}.gcm26-table th{background:#e7f2f7}.gcm26-note{padding:17px 20px;border-left:5px solid #d7994b;border-radius:10px;background:#fff7e9;margin:20px 0}@media(max-width:800px){.gcm26-flow{grid-template-columns:repeat(3,minmax(0,1fr))}.gcm26-grid{grid-template-columns:1fr 1fr}}@media(max-width:520px){.gcm26-grid,.gcm26-flow{grid-template-columns:1fr}} </style>

CLOUD MODERNIZATION / KUBERNETES

クラウド移行に必要なのは、生成だけでなく検証と承認

Google Cloud Modernizeは移行の評価・基盤設計・アプリ変換を一つの流れで捉える新ポートフォリオ。EKS→GKE移行支援を例に、AIができることと人に残る判断を見極めます。

3行で要約

• Googleは2026年10月5日、Migration CenterやModernization Hub、EKS→GKE移行支援などを束ねる「Google Cloud Modernize」を発表した。^[1]
• EKS→GKEの支援ツールは、AIがIaC・Kubernetesマニフェストを変換し、terraform validate等の機械的な検証と人の承認を経てPull Requestを作る設計だ。^[2][3]
• ただしデータの移送や本番環境への適用は自動完結しない。Googleの発表ではEKS→GKE Agentic MigrationはPublic Previewで、事前検証が欠かせない。^[1][2][3]

背景：移行は「YAMLの翻訳」だけでは終わらない

Amazon EKSとGoogle Kubernetes Engine（GKE）はどちらもKubernetesのマネージドサービスだが、認証、Ingress、ストレージ、ノード管理には各クラウド固有の設定がある。マニフェストを単純に置換しても、アクセス権やデータの整合性まで保証できない。Googleはこの作業を「発見→設計→変換→検証→レビュー」の工程として扱う。^[2][3]

何が新しいのか：10月5日の統合発表と、9月の先行公開

10月5日の新しい発表は、既存のMigration CenterやGoogle Cloud VMware Engineなどと、新しい移行・近代化機能をCloud Modernizeというポートフォリオに統合したことだ。コンソール内のModernization Hubも紹介されている。Quick TCO Estimatorのエージェント機能は一般提供（GA）、EKS→GKE Agentic MigrationはPublic Previewとされ、提供段階は同じではない。^[1]

一方、EKS→GKEのオープンソース・エージェントプラグインは9月24日に別途発表済みだ。10月5日に初めて公開された製品と誤解しないよう、日付を分けて読む必要がある。^[2]

技術的なポイント：AIの提案を「決定的なチェック」に通す

Googleが公開した仕組みは、エージェントスキルとローカルMCPサーバーを使い、チェックイン済みのIaCやKubernetes設定を調べる。AIがTerraformやマニフェストの変換案を作り、ツール側がWorkload Identityやレジストリの対応を機械的に処理し、terraform validateやマニフェスト契約のチェックを行う。最終成果物はライブクラスタへの直接適用ではなくPull Requestだ。^[2][3]

この表の自動化範囲は公開リポジトリのREADMEに基づく。個々のシステムが確実に変換できるという保証ではない。^[3]

開発者・企業への影響

プラットフォーム担当とアプリ担当の間で、何を承認し、どこまで完了したかを追跡しやすくなる可能性がある。公開リポジトリでは、移行管理者・プラットフォームエンジニア・アプリ開発者の役割を分け、状態をGCSの台帳に保持する構成を説明している。これは同社の設計説明であり、すべての企業で移行時間が短くなると実証された数値ではない。^[3]

特に大切なのは、AIが出した設定を既存のGitOpsレビューに載せられる点だ。Googleの説明ではツールはterraform applyを実行せず、元のEKS環境も変更しない。移行の責任と最終判断は運用チームに残る。^[2][3]

実践例：小さなワークロードで試す

1. まずEKS上の1サービスを選び、IaC、Helm/Kustomize、使用中のAWS固有リソース、データの場所を一覧にする。移行範囲と本番影響を明文化する。
2. 公開リポジトリのオンボーディングガイドで前提条件を確認する。READMEにはエージェント実行環境、gcloud、Python 3.11以上、Git、必要に応じてTerraform・Helm・kubectlが挙がる。^[3]
3. 実データや秘密情報を投入する前に、サンプルまたは匿名化した構成で発見・設計・変換を試し、生成したPRの差分と検証結果を確認する。
4. 特に認証、Ingress、永続データ、障害時の切戻しを人がレビューし、既存CIでテストする。ライブ環境への適用は別の承認作業として扱う。

リスクと限界

• Public Preview：EKS→GKE Agentic Migrationは一般提供ではない。機能、サポート範囲、導入条件は本番採用前に最新の公式情報で確認する。^[1]
• AI出力の誤り：検証は構文や既知の対応を補助するが、アプリの振る舞い、セキュリティ、性能、法令要件を完全に証明しない。レビューと実環境試験が必要だ。
• 認証情報と地域：公開READMEによると、状態台帳用GCSバケットは現時点でUSマルチリージョンに作られ、ブートストラップ時に地域指定できない。組織のデータ所在地ルールを先に確認する。^[3]
• 費用と成果の見積もり：Googleの発表にある顧客事例や短縮効果は個別環境の結果・提供元の主張であり、自社の移行期間やコスト削減率を保証しない。^[1]

今後注目すべき点

EKS→GKE支援の一般提供時期、対応するAWS固有リソースの拡大、実環境での移行時間・失敗率の比較データを追いたい。現段階では「自動移行」よりも、人の承認を挟んで変換案を再現可能にする仕組みとして評価するのが適切だ。これは公開設計からの編集上の解釈である。

最終確認日：2026年10月6日（日本時間）

参照元

1. Google Cloud公式ブログ：Google Cloud Modernize発表（2026年10月5日）
2. Google Cloud公式ブログ：GKE Agentic Migrationの先行発表（2026年9月24日）
3. Google公開リポジトリ：GKE Agentic Migrationの仕組み・対象範囲・前提条件