追記: 2026年6月17日の最新情報
2026年6月17日時点でGoogle Cloudの公式リリースノートと価格ページを再確認すると、導入判断では名称変更だけでなく、Agent Runtimeの運用条件と課金面の棚卸しが重要です。リリースノートでは、Agent EngineはAgent Runtime、Agent Builder SessionsはAgent Platform Sessions、Memory BankはAgent Platform Memory Bankとして整理され、Agent Runtimeは最大7日までのlong-running operations、sub-second cold starts、1分未満のprovisioning、custom-built containersをサポートすると説明されています。
価格面では、Agent Platformの価格ページが、ツール、ストレージ、コンピュート、利用するGoogle Cloudリソースを分けて確認する構成になっています。モデル単価だけで移行判断をせず、既存のVertex AI/Agent Builder利用箇所を、Runtime、Sessions、Memory Bank、Vector Search、Pipelines、評価、監査ログのどこに読み替えるかを先に一覧化してから、Cloud Platform SKUsと予算アラートで確認すると安全です。
このテーマをもう少し広げて見るなら、Google×KaggleのAI Agents Intensive Course：6月15日開始、参加前に確認すること と Workspace Policy APIのDLP mutate endpoints：管理者が自動化前に確認すること も合わせて確認してください。Agent Platformの導入前に、エージェント設計、評価、function callingの学習導線を確認できるため。
3行まとめ
Gemini Enterprise Agent Platformは、Vertex AIの進化版として説明され、今後のVertex AIサービスとロードマップの確認先になっている。
既存Vertex AIが今日すぐ使えなくなる話ではなく、機能名、呼び出し経路、権限、ログ、課金の棚卸しとして読む。
Agent Runtimeが必要なワークロードか、状態管理や統制が必要か、モデル料金以外の費用をどこまで見積もるかを確認する。
結論は一律の移行ではなく、旧Vertex AI利用箇所をAgent PlatformのBuild、Scale、Govern、Optimizeに読み替えること。
Google CloudのGemini Enterprise Agent Platformは、Vertex AIを使ってきた開発者と企業が、AIエージェントの構築、実行、統制、評価を同じ基盤で見直すための新しい確認先になっている。
公式発表と製品ページでは、Agent PlatformがVertex AIの進化版として扱われ、今後のVertex AIサービスとロードマップはAgent Platform経由で提供されると説明されている。ただし、これは「既存Vertex AIが今日すぐ使えなくなる」という意味ではない。
いま確認すべきなのは、旧Vertex AIのどの機能を使っているか、Agent Runtimeが必要なワークロードか、ログや権限をどう統制するか、モデル料金以外の費用をどこまで見積もるかだ。
Gemini Enterprise Agent Platformで何を判断する記事か
Model Garden、Generative AI、Agent Builder、RAG、Vector Search、Agent Engine系の確認先がどこに移ったのかを見る。
単発のモデル呼び出しなのか、状態を持つエージェントや複数ステップの業務フローなのかを分ける。
従業員が使うGemini Enterprise appの話か、Google Cloud上でエージェントを動かすAgent Platformの話かを分ける。
従業員向けAIアプリの導入判断と、エージェント開発基盤の導入判断を混ぜると、価格確認もセキュリティレビューもぼやける。
Gemini Enterprise Agent Platformを読むときに最初に分けたいのは、ニュースの大きさと、自社が今すぐ動くべき範囲だ。Google Cloudは2026年4月の発表で、Agent PlatformをVertex AIの進化版として説明した。さらに2026年6月のGoogle Cloud AI月次まとめでも、今後のVertex AIサービスとロードマップはAgent Platform経由になるという位置づけを改めて示している。
この一文だけを見ると、既存のVertex AI利用者は「すぐ移行しなければならないのか」と感じやすい。けれど、記事で扱うべき焦点はそこではない。まず見るべきなのは、名称と導線が変わったことで、Model Garden、Generative AI、Agent Builder、RAG、Vector Search、Agent Engine系の確認先がどこに移ったのか。次に、自社のワークロードが単発のモデル呼び出しなのか、状態を持つエージェントなのかを分けることだ。
Vertex AIの後継窓口として読む
根拠
Google Cloudの公式製品ページでは、Gemini Enterprise Agent Platformに「formerly Vertex AI」という位置づけが添えられている。発表ブログでは、モデル選択、モデル構築、エージェント構築の機能に、統合、DevOps、オーケストレーション、セキュリティなどの要素を加えた基盤として説明されている。
ここで重要なのは、Vertex AIという名前を追うだけでは足りなくなっている点だ。以前からVertex AIの下にあったModel Garden、Geminiモデル、RAG Engine、Vector Search、Agent Engine、評価、監視は、Agent PlatformのBuild、Scale、Govern、Optimizeという文脈で読み直す必要がある。
注意点
一方で、公式資料から確認できる範囲では、すべての既存APIや既存ワークロードに対して一律の即時移行期限が示されているわけではない。移行記事として煽るより、現在使っている機能名、呼び出し経路、権限、課金、ログを棚卸しする段階と見るのが安全だ。
Gemini Enterprise appとの混同を避ける
役割の分け方
もう一つ紛らわしいのが、Gemini Enterprise appとの違いだ。Agent Platformは、開発者や技術チームがエージェントを作り、実行し、ガバナンスをかけ、評価するためのGoogle Cloud側の基盤として読む。一方、Gemini Enterprise appは、従業員がエージェントを見つけ、使い、共有するための業務アプリ側の入口として説明されている。
たとえば、社内の営業担当やサポート担当が使うエージェントを配る話なら、Gemini Enterprise app側の導入条件が中心になる。Google Cloud上でエージェントの実行基盤、権限、ログ、評価、ツール呼び出しを設計する話なら、Gemini Enterprise Agent Platform側を読む。
判断の境界
両者はつながるが、導入判断は同じではない。従業員向けAIアプリを買う話なのか、エージェントを動かす開発基盤を整える話なのか。ここを分けないと、価格確認もセキュリティレビューもぼやける。
Vertex AI利用者が最初に確認する名称変更とロードマップ
古い名前で検索できる場面があっても、社内の設計書、Runbook、権限申請、請求タグ、監査説明は自動では直らない。
既存Vertex AI利用者が最初にやるべきことは、移行作業ではなく、名称変更表を見ながら自社の利用箇所を洗い出すことだ。Google Cloudのリリースノートでは、2026年4月22日の変更として、Vertex AIがGemini Enterprise Agent Platformの一部になったこと、Agent Builder系の機能名がAgent Runtime、Agent Platform Sessions、Agent Platform Memory Bankなどに変わったことが示されている。
この情報は、ドキュメントを探すときにも、社内の設計書を更新するときにも効いてくる。古い名前で検索しても自動リダイレクトされる場面はあるが、社内の運用手順、権限申請、障害対応Runbook、請求タグ、監査証跡の説明は自動では直らない。
公式が示した変化
根拠
公式資料で確認できる大きな変化は、Vertex AIを単独のAI開発基盤として見るより、Agent Platformの中でモデル、データ、実行、統制、評価をまとめて扱う流れに寄ったことだ。Google Cloudの製品ページは、Agent Platformを「build, scale, govern and optimize」という4つの柱で説明している。
Buildには、Agent Studio、Agent Development Kit、Model Garden、RAG Engine、Vector Searchなどが並ぶ。Scaleには、Agent Runtime、Sessions、Memory Bank、Sandboxesなどが入る。Governには、Agent Gateway、semantic governance、content security、IdentityとIAM、共有管理が置かれている。Optimizeには、Agent evaluation、Observability、Traces、Topology、Offline evaluation、Simulated evaluation、Online monitoring、Prompt optimizationが並ぶ。
見落としやすい点
つまり、旧Vertex AIの「モデルを選んで呼ぶ」感覚だけで追うと、Agent Platformで増えた運用面の論点を見落とす。AIエージェントを本番化するなら、モデル選択と同じくらい、状態管理、権限、ログ、評価を設計対象に入れる必要がある。
既存構成の棚卸し
確認項目
棚卸しは、サービス名だけで終わらせないほうがよい。次のように、ワークロード単位で見る。
| 確認するもの | 見るポイント | 担当 |
|---|---|---|
| モデル呼び出し | Gemini、Claude、Gemmaなど、どのモデルをどのAPI経由で使っているか | 開発者、AI基盤担当 |
| データ接続 | RAG Engine、Vector Search、BigQuery、Cloud Storageなどをどう接続しているか | データ基盤担当 |
| エージェント実行 | Agent Engine系、Agent Runtime、Sessions、Memory Bankを使うか | アプリ開発、SRE |
| 権限 | 人間のIAMとエージェントの権限を分けられるか | セキュリティ、クラウド管理者 |
| 監査とログ | Cloud Logging、トレース、プロンプト入出力、ツール呼び出しをどこまで残すか | セキュリティ、法務、運用 |
| 課金 | モデル、Runtime、評価、ログ、ストレージ、第三者モデルを分けて見積もったか | FinOps、事業責任者 |
既存のVertex AI Gen AI SDKやAPI移行を追う読者は、当サイトの<a href="https://googl-watch.blog.mo-gmo.com/googl-15-vertex-ai-genai-sdk-migration/">Vertex AI Gen AI SDK移行チェック</a>も合わせて確認しておきたい。SDKの更新とAgent Platformの名称変更は同じ話ではないが、社内のコード、ドキュメント、権限申請を直すタイミングは重なりやすい。
Agent Runtimeを採用する条件
- 1単発のモデル呼び出し
要約、分類、翻訳、フォーム入力補助、バッチ処理の一部なら、Gemini APIや既存のCloud Run、GKE構成で足りる場合がある。
- 2状態を持つ業務フロー
ユーザーや業務ごとの状態、セッション、記憶、ツール呼び出し、再試行が必要ならAgent Runtimeを検討しやすい。
- 3長時間実行
数分から数日単位で続くワークフローや、複数データソースをまたぐ処理では実行基盤の設計が重要になる。
- 4本番運用
実行ログ、トレース、評価、障害時の切り戻しを見たい場合は、Observabilityや評価機能も一緒に確認する。
Runtimeが効くのは、すべての生成AIアプリではなく、状態、委譲、監査、評価が必要なエージェント型ワークロード。
Agent Platformの中でも、導入判断が分かれやすいのがAgent Runtimeだ。リリースノートでは、Agent Runtimeが長時間実行、サブ秒のコールドスタート、1分未満のプロビジョニング、カスタムコンテナによるデプロイに対応することが示されている。Agent Builder SessionsはAgent Platform Sessionsへ、Memory BankはAgent Platform Memory Bankへと名前も変わっている。
この説明だけ見ると、すべての生成AIアプリをAgent Runtimeへ寄せたくなるかもしれない。だが、Runtimeが効くのは、単発のモデル呼び出しよりも、状態を持つエージェントや複数ステップの業務フローだ。
Runtimeが効く用途
条件
Agent Runtimeを検討しやすいのは、次のような条件が重なるときだ。
- 数分から数日単位で続くワークフローを扱う
- ユーザーや業務ごとの状態を持つ
- セッション、記憶、ツール呼び出し、再試行が必要になる
- エージェントが別のエージェントや外部ツールへ処理を委譲する
- 実行ログ、トレース、評価、障害時の切り戻しを本番運用で見たい
たとえば、営業リードの調査、顧客対応の一次整理、社内ナレッジ検索から回答作成までの流れ、複数データソースをまたぐレポート作成は、単なるチャット応答よりも状態と監査が重要になる。こうした用途では、Agent Runtime、Sessions、Memory Bank、Agent Sandbox、Observabilityを一緒に見る価値がある。
Runtimeが過剰になりやすい用途
評価基準
反対に、単発の要約、分類、翻訳、フォーム入力補助、バッチ処理の一部にモデルを呼ぶだけなら、Agent Platform全体を最初から使い切ろうとしないほうがよい。Gemini APIや既存のモデル呼び出し、Cloud RunやGKE上のアプリ構成で十分な場合がある。
判断するときは、「エージェントらしさ」という言葉ではなく、実行時間、状態保持、権限分離、ログ量、失敗時の再開、運用担当を見たほうがよい。とくに推論基盤やコスト最適化を自前寄りに見るチームは、<a href="https://googl-watch.blog.mo-gmo.com/googl-40-gke-inference-gateway-prefix-caching/">GKE Inference Gatewayのprefix caching</a>のような選択肢も並べて比較したい。
GovernとSecurityで確認すること
- 1人間ユーザー
誰がエージェントを作り、登録し、共有し、停止できるのかを決める。
- 2Agent Identity
人間ユーザーの権限とエージェントの権限を分け、エージェントを実行主体として扱えるかを見る。
- 3Registry
承認済みのエージェントやスキルを整理し、本番、検証、開発のエージェントを分ける。
- 4Agent Gateway
ツール呼び出しやエージェント間の通信を統制し、監視する制御点として確認する。
- 5ログと停止条件
どのログに残し、失敗時に誰が停止し、どこまで巻き戻せるのかを先に決める。
セキュリティの判断は勝敗ではなく、エージェントの行動範囲、承認済みツール、監査証跡を説明できるかで見る。
AIエージェントの本番化では、便利さより先に「誰の権限で何を実行したのか」を説明できるかが問われる。Agent Platformの公式ドキュメントでは、Govern領域にAgent Gateway、semantic governance、content security、IdentityとIAM、エージェント共有などが並ぶ。これは、モデルの品質だけでなく、エージェントの行動範囲を管理するための論点だ。
既存の生成AIアプリでは、人間ユーザーの権限とアプリのサービスアカウントだけで整理していたチームも多い。エージェントがツールを呼び、複数ステップで判断し、別サービスへ書き込みを行うなら、その設計では粗くなる。
Agent Identity、Registry、Gatewayの役割
確認項目
確認したいのは、エージェントを1つの実行主体として扱えるかだ。誰がエージェントを作り、どこに登録し、どのツールを使わせ、どのポリシーを通して、どのログに残すのか。ここを人間ユーザーの権限だけで説明しようとすると、セキュリティレビューで詰まりやすい。
Agent Identityは、エージェントの権限やアクセス管理を考える入口になる。Registryは、承認済みのエージェントやスキルを整理する場所として読む。Gatewayは、ツール呼び出しやエージェント間の通信を統制し、監視する制御点として見る。
社内導入では、次の問いを先に決めておきたい。
- エージェントはどのGoogle Cloudプロジェクトに属するのか
- 人間ユーザーの権限とエージェントの権限を分けるのか
- エージェントが呼べるツールは誰が承認するのか
- 本番、検証、開発のエージェントをどう分けるのか
- 失敗時に誰が停止し、どこまで巻き戻せるのか
ログ、データ保持、Model Armor
注意点
リリースノートでは、2026年6月2日にabuse monitoring、zero data retention、responsible AI関連のドキュメント更新が示されている。特にClaude MythosやOpusのような第三者モデルに関するrequest-response loggingにも触れられているため、モデルごとの条件を同じものとして扱わないほうがよい。
ここで見るべきなのは、ログを残すか残さないかだけではない。入力、出力、ユーザーID、ツール呼び出し、トレース、評価用データ、障害調査用ログが、どこに、どの期間、誰の権限で残るのか。zero data retentionやAdvanced AI Safety Addendumに関わる条件は、企業契約、モデル、リージョン、利用形態によって確認先が変わる可能性がある。
Model Armorやcontent securityは、出力の安全性だけでなく、入力側のリスクにも関係する。社内文書、顧客情報、コード、契約書、医療や金融に近い情報を扱うなら、Prompt injection、機密情報の混入、ログへの保存、第三者モデルへの送信条件を分けて見る必要がある。
価格で確認すること
価格は変わりやすいため、公式価格ページ、Google Cloud Pricing Calculator、請求アカウントの予算アラートで再確認する。
Agent Platformの価格確認で避けたいのは、モデルの入出力単価だけを見て「安い、高い」と判断することだ。公式価格ページでは、Agent Platform pricingと、旧AI PlatformやAutoML系製品との価格比較が説明されている。価格は米ドルで示され、他通貨で支払う場合はCloud Platform SKUs側の価格が適用される。
同ページでは、Agent Platformの費用は、Agent Platformが置き換える旧AI PlatformやAutoML製品と同じ扱いになる部分がある一方、例外も示されている。たとえば、旧InferenceやAutoML Tablesの一部低コスト機械タイプ、旧Inferenceのscale-to-zeroなど、差分として読まなければならない項目がある。
見積もりはモデル料金だけで終わらせない
費目の分け方
エージェント本番化の費用は、モデル単価だけでは閉じない。少なくとも、次の費目を分けて見る。
| 費目 | 発生しやすい条件 | 見落としやすい点 |
|---|---|---|
| モデル入力と出力 | 長いプロンプト、会話履歴、RAGの文脈投入 | テスト時より本番ログでトークンが増える |
| Agent Runtime | 状態を持つエージェントを実行する | 長時間実行、再試行、同時実行で増える |
| SessionsとMemory Bank | 会話や業務状態を保持する | 保持期間と削除方針がコストとリスクに効く |
| RAGとVector Search | 社内データを検索して回答に使う | インデックス更新、検索回数、ストレージを忘れやすい |
| 評価と監視 | Offline、Simulated、Onlineの評価を回す | 品質改善のための評価ループが継続費用になる |
| ログとトレース | 実行経路を監査する | 詳細ログほど保存量とレビュー工数が増える |
| 第三者モデル | ClaudeなどをModel Garden経由で使う | モデルごとの規約、ログ、価格、提供地域が異なる |
PoC段階では、毎回の推論単価よりも、成功条件を満たすまでの試行回数が費用に効く。システムプロンプトを何度も直す、評価データを増やす、失敗ログを長く保存する、複数モデルを比較する。こうした作業は、導入判断としては健全だが、見積もりには必ず入れるべきだ。
価格ページの読み方
公開前に見る順番
価格ページを読むときは、リージョン、モデル、プレビューか一般提供か、課金メトリクス、無料クレジット、組織契約、割引、Compute EngineやCloud Storageの関連費用を分ける。検索結果や二次記事の金額は、需要シグナルや参考にはなるが、記事本文や社内稟議の根拠にはしない。
また、Google Cloudの公式価格ページは項目が多い。Agent Platform pricing、Generative AI on Agent Platformの価格、Cloud Platform SKUs、Pricing Calculator、Billingの予算アラートをつないで読む必要がある。社内で本番化を進めるなら、開発者だけで金額を決めず、FinOpsや請求管理者と一緒に見るほうが事故が少ない。
導入判断チェックリスト
Google Cloud上にデータ、認証、ログ、監査の基盤があり、長時間実行、状態管理、ツール呼び出し、評価が最初から必要な場合。
既存Vertex AI利用者は、名称変更表とリリースノートを見ながら、現在の構成をAgent Platform側の呼称へ写すところから始める。
社内チャットボットや単純な文章生成だけの段階なら、ユースケース、権限、ログ、予算上限を先に整える。
同じ入力で再現でき、失敗時に追跡でき、予算内に収まり、運用担当が説明できることを成功条件にする。
Go、Trial、Waitは優劣ではなく、現在の基盤、ユースケース、統制、予算の整い方で変わる。
Gemini Enterprise Agent Platformは、Google CloudのAIエージェント基盤として重要な更新だ。ただし、すべての読者が同じ結論になるわけではない。ここでは、Go、Trial、Waitの3つに分けて考える。
Goに近いケース
該当条件
Google Cloud上にデータ、認証、ログ、監査の基盤があり、AIエージェントを複数業務で本番化したい企業は、Agent Platformを本格的に評価する価値がある。とくに、長時間実行、状態管理、ツール呼び出し、エージェント間の委譲、評価、Observabilityが最初から必要なら、Agent RuntimeやGovern領域を含めて設計したほうがよい。
Goに近い場合でも、最初のアクションは全社展開ではない。1つの業務フローを選び、データソース、権限、ログ、評価指標、停止条件、予算上限を決めてからPoCに入る。PoCの成功条件は、デモが動くことではなく、同じ入力で再現でき、失敗時に追跡でき、予算内に収まり、運用担当が説明できることだ。
Trialに向くケース
最初の進め方
既存Vertex AI利用者の多くは、Trialから入るのが現実的だ。Model Garden、Geminiモデル、RAG Engine、Vector Search、Agent Builder系を使っているなら、名称変更表とリリースノートを見ながら、現在の構成をAgent Platform側の呼称へ写してみる。そのうえで、新機能を使うかどうかを分ける。
Trialでは、いきなり全機能を試さない。単発モデル呼び出し、RAG、状態を持つエージェント、評価、ログの順に分ける。導入ROIを測るなら、当サイトの<a href="https://googl-watch.blog.mo-gmo.com/googl-41-dora-ai-roi-code-assist/">Google Cloud DORAのAI支援開発ROI</a>のように、開発生産性、レビュー工数、運用負荷、費用を同じ表で見ると判断しやすい。
Waitでよいケース
待つ間に追うもの
社内チャットボットや単純な文章生成だけを試している段階なら、Agent Platform全体を急いで採用しない選択もある。自社データへの接続が弱い、権限設計が未整理、ログ保持の方針がない、利用回数や予算上限が決まっていない場合も、まず設計を整えるべきだ。
Waitは、何もしないという意味ではない。公式リリースノートの更新、モデルの提供状態、廃止予定、価格ページ、zero data retentionやResponsible AI関連の条件は追っておく。とくに2026年5月28日のリリースノートでは、画像系モデルの一般提供とプレビューエンドポイントの廃止予定が示されている。利用モデルにプレビュー名が残っていないかは、定期的に確認したい。
いま試す人、待つ人、次に読むもの
現在のワークロードを棚卸しし、機能名、呼び出し経路、権限、ログ、課金をAgent Platformの文脈で読み直す。
Agent Runtimeより前に、ユースケース、データ、権限、ログ、評価、予算を決める。
AIエージェントが検索やWorkspaceだけでなく、Cloudの開発基盤にも広がっている点を見る。
株価や決算の前に、読者が触れる製品、サービス、導入条件の変化を確認する。
この記事はAlphabetおよびGoogle Cloudとは非提携の独立メディアによる整理であり、投資助言ではない。
この記事の結論は、Agent Platformをすぐ全社展開することではない。Google CloudのAI基盤を追うなら、Vertex AIという名前だけでなく、Agent PlatformのBuild、Scale、Govern、Optimizeへ読み替える必要が出てきた、ということだ。
既存Vertex AI利用者は、まず現在のワークロードを棚卸しする。新規エージェント導入企業は、Agent Runtimeより前に、ユースケース、データ、権限、ログ、評価、予算を決める。Google Cloudの事業動向を追う読者は、AIエージェントが検索やWorkspaceだけでなく、Cloudの開発基盤にも広がっている点を見ると流れを掴みやすい。
なお、この記事はAlphabetおよびGoogle Cloudとは非提携の独立メディアによる整理であり、投資助言ではない。GOOGLの株価や決算を見る場合も、まずは読者が触れる製品、サービス、導入条件の変化を確認してから、市場反応を補助線として読むのがよい。
月内のGoogle関連トピックを追う場合は、<a href="https://googl-watch.blog.mo-gmo.com/monthly-topics-2026-06/">2026年6月の重要トピックまとめ</a>に戻ると、公式発表、製品更新、噂の確認状況を同じ流れで追える。
次に読むなら
参照した主な情報源
| 確認日 | 情報源 | 本文で確認したこと |
|---|---|---|
| 2026-06-14 | https://cloud.google.com/blog/products/ai-machine-learning/introducing-gemini-enterprise-agent-platform | Gemini Enterprise Agent Platformの発表、Vertex AIの進化版という位置づけ、Build、Scale、Govern、Optimizeの説明 |
| 2026-06-14 | https://cloud.google.com/products/gemini-enterprise-agent-platform | 製品ページ上の「formerly Vertex AI」表記、200以上のGoogleおよび第三者モデル、Agent Platformの主な機能 |
| 2026-06-14 | https://docs.cloud.google.com/gemini-enterprise-agent-platform | Agent Studio、ADK、Model Garden、RAG Engine、Agent Runtime、Govern、Optimize関連の公式ドキュメント構成 |
| 2026-06-14 | https://docs.cloud.google.com/gemini-enterprise-agent-platform/release-notes | 2026年4月22日の名称変更、Agent Runtime、Sessions、Memory Bank、2026年6月2日のabuse monitoringとzero data retention関連更新 |
| 2026-06-14 | https://cloud.google.com/products/gemini-enterprise-agent-platform/pricing | Agent Platform pricing、旧AI PlatformやAutoMLとの価格比較、関連費用を公式ページで確認する必要性 |
| 2026-06-14 | https://cloud.google.com/blog/products/ai-machine-learning/what-google-cloud-announced-in-ai-this-month | 2026年6月時点でGoogle Cloud AIの月次まとめにAgent Platformが継続的に取り上げられている需要シグナル |
更新履歴
- 2026-06-14
Google Cloud公式ブログ、製品ページ、公式ドキュメント、リリースノート、価格ページを確認した。
- 初稿公開
Vertex AI利用者向けに、名称変更、Agent Runtime、Govern、Security、価格、導入判断の棚卸し観点を整理した。
提供条件、価格、モデル名、プレビューエンドポイントの廃止予定は、公開後も公式情報で確認する。
- 2026-06-14 初稿公開。Google Cloud公式ブログ、製品ページ、公式ドキュメント、リリースノート、価格ページを確認し、Vertex AI利用者向けの棚卸し観点を整理した。