EKSからGKEへ、AIが作った設定をどう信頼する？

AWSのKubernetesサービス「EKS」から、Google Cloudの「GKE」へ移るとき、AIに設定ファイルを書き換えさせるだけで十分だろうか。問題は、出力された設定が一見正しくても、アクセス権や通信経路が元の環境と変わり得ることだ。

Googleが公開した「GKE agentic migration」は、場当たり的なプロンプトで移行設定を作る代わりに、大規模言語モデル（LLM）の推論と、同じ入力に同じルールを適用する決定的なツールやガードレールを組み合わせるエージェント向けプラグインだ。2

移行で確認すべきは「書式」より「挙動」

インフラをコードで管理する設定やKubernetesのマニフェストを変換する際は、移行前に何ができていたかを確かめる必要がある。Googleの一般的な移行ガイダンスも、まずワークロードと依存関係を把握するよう勧めている。19

特に注意したいのは、次の3点だ。

• IDと権限： AWS側のID設定をGKEのWorkload Identityに対応付けたとき、必要なアクセスを維持しつつ、権限を広げすぎていないか。
• 通信経路： ロードバランサーの入口設定をGateway APIへ移す場合、想定したルールで適切なサービスにリクエストが届くか。
• ノード構成： ワークロードの配置条件や必要な処理能力を移行後も満たせるか。

これらは移行時に確認すべき論点であり、ツールがあらゆる変換を正しく処理すると実証された項目ではない。エージェントにツールを使わせるModel Context Protocol（MCP）も、それ自体が変換結果の正しさを保証する仕組みではない。Googleの発表で確認できるのはLLMと決定的なツールの組み合わせであり、提供された発表抜粋には個々の変換ルールの詳細までは示されていない。2

チェックとレビューで、本番反映までの距離を置く

オフラインでの決定的なチェックには、AI自身の説明とは別の基準で、提案されたファイルを繰り返し評価できる利点がある。ただし検出できるのは、定義されたルールに含まれる問題だけだ。Googleは「決定的なガードレール」を掲げる一方、提供された発表抜粋からは検証範囲の全容は分からない。2

また、生成した変更をプルリクエストとして提示し、エンジニアのレビューや既存のCI/CD（継続的インテグレーション・デリバリー）を通す運用なら、稼働中のクラスターを直接書き換える前に差分やテスト結果を確認できる。ソース管理からデプロイまでを管理する考え方はGoogleのGKE文書とも整合する。ただし、提供された発表抜粋だけでは、このツールのプルリクエスト処理の全工程を独立に確認できない。172

Googleの発表で、Persistentの幹部Rahul Shrivastava氏はこの手法を「証明可能な、コンパイラー級の移行ファクトリー」と評している。生成物を一定の手順で検査するという比喩としては分かりやすいが、移行全体の安全性が数学的に証明されたという意味ではない。切り替え後の動作や性能、権限は別途テストが必要だ。2

Intrinsic Coreとの共通点、異なる課題

GKEの発表に先立つ2026年9月22日、Google傘下のIntrinsicはトロントのROSCon 2026で「Intrinsic Core」を発表した。ロボット向けソフトウェア基盤「ROS」と互換性があり、制御、動作・把持計画、シミュレーション、姿勢推定などの機能を含むオープンソースの基盤だ。報道によると、ライセンスはApache 2.0。Intrinsic自身も、ハードウェアに依存しないリアルタイム制御やデジタルツインの機能を説明している。403337

両者のつながりは技術面より戦略面にある。GKEのツールはクラウド移行の手間を、Intrinsic Coreは産業用ロボットの開発の手間を減らす可能性がある。後者については、基盤を広く提供して開発者のエコシステムを育てる「ロボット版Android」という見方も報じられている。ただし、いずれの公開も、それだけでAWSからの移行増加やGoogleの有料AIサービスの売上を示すものではない。230

結論： この移行ツールの価値は、AIに本番環境の変更を任せ切ることではなく、AIの提案を検証・レビューできる変更として扱う点にある。移行失敗やコストの削減を示す測定結果は、提供された資料にはない。219