Containers & Kubernetes

ガバナンスが組み込まれた、AI 支援による EKS から GKE への移行を実現する GKE エージェント型移行の概要

2026年10月2日

Sunny Hwang

Product Manager, GKE

Hamed Seifoddini

Engineering Manager, GKE

Gemini を今すぐお試しください

職場での AI 活用、その入り口に

今すぐ試す

※この投稿は米国時間 2026 年 9 月 25 日に、Google Cloud blog に投稿されたものの抄訳です。

最も重要な AI 駆動型ワークロードを実行するために、Google Kubernetes Engine（GKE）を標準として採用する企業が増えています。高スループットのデータアクセスを実現する Cloud Storage FUSE から、カスタムコンピューティングクラス（CCC）や高度な GPU スライス法まで、GKE は最新のアプリケーションに必要なスケールと効率性を備えています。

しかし、複雑な Kubernetes 環境を AWS EKS から GKE に移行することは、従来、エンジニアリング上の大きな課題であり、多大な手間を伴うものでした。プラットフォームチームは、複雑な Infrastructure as Code（IaC）を手動で分析し、クラウド固有のアーキテクチャの違いを把握して、カスタム変換スクリプトを構築する必要があります。

エンジニアリングチームは、汎用 LLM を使用してコード変換のドラフトを作成することをよく試みていますが、アドホックなプロンプトはすぐに運用上の落とし穴になる可能性があります。未加工のモデルは、存在しないリソースプロパティのハルシネーションを起こしたり、重要なネットワーク構成や ID 構成を欠落させたり、相互に依存するファイル間でコンテキストを失ったりします。プラットフォームエンジニアがモデルエラーを監査、解決、デバッグするために費やす時間は、当初得られるはずだったスピード向上効果を相殺し、手作業による労力と予測不可能性を生み出します。

このたび、Google は GKE エージェント型移行のオープンソースリリースを発表いたしました。これは、不安定なアドホックプロンプトに代わり、決定論的なガードレールで保護された AI 支援移行パイプラインを提供する専用のエージェントプラグインです。

「大企業のお客様にとって、クラウドのモダナイゼーションにおける最大の障壁は、実行リスクと予測不可能性です。コンテキストを失い、構成をハルシネーションする未加工のチャットプロンプトとは異なり、Google の GKE エージェント型移行は、生成 AI のスピードと、企業が必要とする決定論的なガードレール（構造化された状態の永続性、プラットフォームチームとアプリチーム間のマルチペルソナ境界、交渉の余地のない人間の承認ゲート）の両方を備えてます。これにより、当社のグローバルエンジニアリング部門は、コンパイラ並みの精度で検証可能な移行ファクトリーを手に入れることができ、デリバリーリスクを大幅に削減できました。- Persistent、EVP、Rahul Shrivastava 氏

インフラストラクチャの移行に伴う課題

インフラストラクチャの移行プロセスについてお客様と話すとき、ガバナンスに関するいくつかの課題をよく耳にします。

自動化の信頼ギャップ: Kubernetes 構成を手動でリファクタリングすると、非常に時間がかかることがあります。しかし、汎用的な AI コーディングアシスタントを使用すると、許容できないリスクが生じます。標準的な LLM は、インフラストラクチャコードをハルシネーションしたり、非推奨の API フィールドを使用したり、重要なセキュリティルールを省略したりすることがあります。「ほぼ正しい」コードを生成しても、ボトルネックがコードの作成からデバッグに移行するにすぎません。
ライブクラスタの可変性の危険性（ClickOps）: 従来の移行ツールは多くの場合、ライブクラスタに直接接続し、API 呼び出しを介してデプロイします。これにより、組織の Git リポジトリ（信頼できる情報源）がバイパスされて、CI / CD パイプラインが中断され、ロールバックが非常に困難になります。
サイロ化されたハンドオフのボトルネック: 移行は多くの場合、複数週にわたる長期的な作業となります。プラットフォームエンジニアがランディングゾーンを構築し、アプリケーションデベロッパーがワークロードを移行します。標準的な AI ツールを使うと、引き継ぎ時にコンテキストが失われます。
断片化されたツールチェーン: Velero などのバックアップツールは障害復旧には優れていますが、AWS 固有の構成（ALB など）をそのままキャプチャするため、Google Cloud 向けには変換されません。一方、リバースエンジニアリングツールは、デベロッパーの本来の論理的な意図を排除したフラットな構成を生成します。

GKE エージェント型移行の概要

GKE エージェント型移行は、LLM の推論機能と厳格で決定論的なツールを組み合わせることで、これらの課題に対処します。エージェントスキルとローカルの Model Context Protocol（MCP）サーバーを組み合わせた設計になっており、AI を使用して複雑な AWS EKS IaC と Kubernetes マニフェストを、自動化された pull リクエスト経由で GKE ランディングゾーンに直接変換します。

GKE エージェント型移行の特徴となっている主な機能は次のとおりです。

1. ハイブリッド検証 - LLM で生成し、決定論的に検証。危険な IaC ハルシネーションに対処するため、LLM ワーカーが Terraform と Kubernetes YAML の複雑な作成を処理し、サーバーが Workload Identity アノテーションやイメージレジストリなどの正確なマッピングのために決定論的な変換を実行します。重要なのは、AI が生成したこれらの変換は、ユーザーに提示される前に、厳格な決定論的検証（terraform validate、Kubernetes マニフェストコントラクトなど）にかけられることです。このアプローチは、ハルシネーションに対する安全性を維持しつつ、あらゆる操作を人間参加型（HITL）の承認によって制限するのに役立ちます。

2. GitOps ネイティブの PR ワークフロー: プラグインがライブクラスタに変更を直接適用することはありません。代わりに、信頼できる情報源を読み取り、ターゲット状態を生成して、pull リクエストを開きます。これにより、すべての変更が標準の人間参加型（HITL）CI / CD 審査プロセスをとおして処理されるようになります。「ClickOps」は不要です。

3. 変換と転送の分離を保護: プラグインは、アーキテクチャ変換の面倒なロジックを自動化しますが、ステートフルデータを意図的に転送しません。最も機密性の高いアセットを保護するため、プラグインは、専用の SLA に裏付けられたツール（Google Cloud の Database Migration Service や Storage Transfer Service など）の使用をチームに指示する、コンテキストに応じたランブックを生成します。

4. マルチペルソナの状態管理: 移行はチームが行う取り組みです。プラグインは、長時間実行される移行状態を保持します。これにより、保護された非同期のハンドオフが可能になります。プラットフォームエンジニアがベースラインのランディングゾーンを確立し、アプリデベロッパーは各自のマシンからワークスペースに個別にアクセスして、権限が分離されたフォルダ内で個々のワークロードを変換します。

仕組み: 移行のライフサイクル

内部的には、GKE エージェント型移行は実行可能関数の移行状態グラフを利用し、チェーンに沿ってコンテキストを体系的に渡します。オープンソースのエージェントプラグインとしてパッケージ化されているため、カスタム CLI バイナリをインストールする必要も、中央のコントロールプレーンを管理する必要もありません。チームは既存の開発ハーネスを通じてコラボレーションし、検証済みの pull リクエストと実用的なランブックをソースリポジトリに直接配信できます。これには、次のような利点があります。

EKS リポジトリの念入りな検出: プラグインは、ソース Git リポジトリのクローンを作成するか、EKS クラスタのライブスキャンを実行し、ソースマニフェストをプログラムによりインデックスに登録して、依存関係をマッピングし、インベントリを構築します。
評価とブロッカーガバナンス: アーキテクチャの非互換性を特定する準備状況レポートを生成します。設計を開始する前に、すべてのブロッカーにオーナーと解決目標日を割り当てる必要があります。プラットフォームエンジニアは、変換を開始する前に移行の境界を承認します。
ランディングゾーンの設計: プラグインは、プラットフォームの明示的な決定（GKE Autopilot か GKE Standard かなど）に基づいて、基本的な Google Cloud Terraform モジュール（VPC、サブネット、GKE クラスタ、組織のポリシー）をスキャフォールディングします。
AI を活用したクラウド変換: プラグインは、AWS IRSA から Workload Identity への変換、ALB Ingress から Gateway API へのマッピング、Karpenter ノードクレームから GKE ノード自動プロビジョニング（NAP）またはカスタムコンピューティングクラス（CCC）への変換など、独自の移行を処理します。
オフライン検証: 生成されたモジュールとマニフェストは、オフラインでコンパイルされ、検証されます（terraform validate、マニフェスト構造のチェック、出力コントラクト）。
デプロイ（pull リクエスト経由）: 最終的な構成がローカルで検証され、レビューのために PR が開かれます。