Model Gardenとは？使い方や料金、対応モデルを解説

Model Gardenは、Google CloudのVertex AI上で利用できるAIモデルのカタログ兼実行入口です。Google独自モデルだけでなく、オープンモデルやパートナーモデルまでを1か所で探し、試し、必要に応じてチューニングやデプロイへ進められます。

本記事では、Model Gardenの基本概念から、対応モデルの種類、Google AI StudioやVertex AI全体との違い、使い方、料金の考え方、導入判断で詰まりやすい論点までを2026年4月時点の公式情報で整理して解説します。

Model Gardenとは？

Model Gardenは、Google Cloud公式ドキュメントで「モデルを発見し、試し、カスタマイズし、デプロイするためのAI/MLモデルライブラリ」と位置づけられている機能です。要するに、Vertex AIの中でモデル選定と初期評価の起点になる場所だと考えると分かりやすくなります。

Vertex AIの中での位置づけ

Vertex AIとは何かを先に押さえると、Model GardenはVertex AI全体の中にあるモデルカタログ兼導線です。Vertex AIそのものが学習、推論、評価、エージェント、データ連携まで含む広い基盤であるのに対し、Model Gardenはその中で「どのモデルを使うか」を決める入口に近い役割を持ちます。

同じModel Gardenの公式ページでは、Model Gardenを通じて200以上のモデルにアクセスできると案内されています。単に一覧表示するだけでなく、そのままモデルカードの確認、テスト、チューニング、デプロイまで進められる点が重要です。

選べるモデルの種類

Model Gardenの強みは、モデルの種類が1つの系統に閉じないことです。Google Cloud公式ページとModel Garden overviewをもとに整理すると、主な区分は次のとおりです。

• Google独自モデル
  Gemini、Imagen、Veo、Chirpなど、Googleが提供する基盤モデルやタスク特化モデルです。
  
  
• 事前学習済みAPI
  Text-to-Speech、Vision、Translation、Natural Language Processingのような、用途が比較的明確なAPI群です。
  
  
• オープンモデル
  Gemma、Llama、Mistral、AI21、Falcon、BERT、T5 FLAN、ViT、EfficientNetなどが含まれます。
  
  
• パートナーモデル
  AnthropicのClaudeなど、Googleパートナーのモデルが利用できます。managed APIとして使えるものに加え、self-deployして使うパートナーモデルもあります。

この構成を見ると、Model Gardenは「Geminiを使う場所」ではなく、「Google系、オープン系、パートナー系を同じ土俵で比較しやすくする場所」だと理解するのが正確です。

Model Gardenが必要な理由

Model Gardenが必要になるのは、モデルの数が増えたこと自体よりも、選定と運用の難しさが増したからです。この節では、なぜ単に1つのモデルを使うだけでは済まなくなっているのかを整理します。

モデル選定が難しくなっている

2026年時点では、Gemini 2.5 Proのような高性能モデル、Gemini 2.5 Flashのような価格性能重視モデル、Gemma 4のようなオープン寄りモデル、Claude 4のようなパートナーモデルが同時に選択肢になります。

この状況で難しいのは、「どれが一番賢いか」ではなく、「自社の要件にどれが一番合うか」です。精度、速度、コスト、ガバナンス、リージョン、デプロイ方式まで同時に見ないと、PoCでは良くても本番で詰まりやすくなります。

選定後の運用まで見据える必要がある

Model Garden overviewでは、Model Gardenの利点として、単一の場所でモデルを扱えることに加え、Vertex AIのチューニング、評価、サービングとの統合が明示されています。つまり、Model Gardenは単なるカタログではなく、その後の運用導線まで含めた入口です。

実務で詰まりやすいのは、試したモデルをそのまま本番で使えると思い込むことです。実際には、managed APIで呼ぶのか、自前でデプロイするのか、組織ポリシーで制御できるのかまで整理してはじめて、本番候補として比較できます。

---

Model Gardenでできること

Model Gardenでできることは、モデルの閲覧だけではありません。モデルの種類に応じて、試す、呼び出す、チューニングする、デプロイするといった実務的な作業に進めます。

モデルカードから性能と制約を確認する

Use models in Model Gardenでは、Model Gardenからモデルカードを開き、対応タスク、提供方式、サンプルコード、デプロイ可否などを確認できる流れが案内されています。初期検証では、まずモデルカードで入出力、利用条件、対応リージョン、API提供方式を見ておくのが基本です。

特に、同じ「使えるモデル」でも次のように性質が異なります。

• managed API型
  GoogleやパートナーがAPIとして提供するモデルです。推論基盤を自前で持たずに呼び出せます。
  
  
• MaaS型オープンモデル
  一部のオープンモデルはModel as a Serviceとして利用できます。
  
  
• self-deploy型オープンモデル
  エンドポイントへ自分でデプロイして利用するモデルです。

この違いを見落とすと、後で「思っていたより運用負荷が高い」「逆に制御が足りない」といったズレが起きます。

テスト、チューニング、デプロイまで進める

Overview of Model Gardenでは、Model GardenがVertex AIのチューニング、評価、サービングと統合されていると説明されています。また、Use models in Model Gardenでは、コンソールからモデルをテストし、必要に応じてデプロイやカスタマイズへ進める手順が示されています。

このため、Model Gardenを使うと、典型的には次の流れで進められます。

• モデルを絞る
  用途、コンテキスト長、マルチモーダル対応、価格帯から候補を数個に絞ります。
  
  
• コンソール上で試す
  モデルカードやテスト機能で、応答品質や入出力形式をざっと比較します。
  
  
• 必要ならチューニングする
  GeminiやGemma、Llamaなど対象モデルでは、チューニングやノートブック経由のカスタマイズに進めます。
  
  
• 本番導線へ載せる
  managed APIとして呼ぶか、自前エンドポイントへデプロイするかを決めます。

この一連の流れを同じ基盤で回せる点が、Model Gardenの実務上の価値です。

組織ポリシーで利用モデルを絞り込める

Control access to Model Garden modelsでは、Model Gardenに対して組織、フォルダ、プロジェクト単位で利用可能モデルとアクションを制御できると明記されています。許可・拒否できる代表的なアクションは、predict、deploy、tuneです。

これは企業導入ではかなり重要です。たとえば「Geminiのpredictだけ許可」「特定のLlamaはdeploy禁止」「fine-tuningは検証用プロジェクトに限定」といった統制ができるため、モデル選定を自由にしつつ、運用上の事故を減らしやすくなります。

Model Gardenの使い方

Model Gardenの使い方は、いきなり全機能を触るより、選定、試験、実装の3段階で考えるほうが整理しやすいです。ここでは、初めて触る人が迷いにくい流れに絞って説明します。

まずはコンソールで候補モデルを絞る

Overview of Model Gardenによると、Model Gardenではタスク、モデルコレクション、プロバイダ、機能などで絞り込みができます。最初にやるべきことは、「何でも見られる状態」を捨てて、用途別に候補を数個まで減らすことです。

具体的には、次のような条件で絞ると判断しやすくなります。

• 生成したいもの
  テキスト、画像、音声、動画、埋め込みなど、まず出力タイプを固定します。
  
  
• 提供方式
  APIでそのまま呼びたいのか、自前デプロイ前提かを先に決めます。
  
  
• プロバイダ
  Google独自モデル、Anthropic、オープンモデルのどこを主戦場にするかを決めます。

この時点で候補を3つ程度まで減らしてから比較するほうが、PoCが無駄に広がりません。

次にモデルカードで実行方式を確認する

同じModel Garden内でも、モデルごとに使い方が異なります。Use models in Model GardenとModel Garden pricingを合わせて見ると、少なくとも以下は先に見ておくべきです。

• managed APIか
  トークン課金中心で扱えるかを確認します。
  
  
• self-deploy前提か
  エンドポイント、GPU、TPU、スケーリング設計が必要かを確認します。
  
  
• チューニング対象か
  チューニングできるモデルなのか、できる場合はどの方式かを確認します。

この見分けを早めにやっておくと、後から料金と運用体制の見積もりが大きくずれるのを防げます。

実装段階ではSDKとCLIの扱いも確認する

Vertex AI release notesでは、2025年4月30日にModel GardenのモデルをPython SDK、gcloud CLI、APIからデプロイする追加資料が利用可能になったと案内されています。コンソールだけでなくコード化の導線も用意されているため、本番を意識するなら早い段階でIaCや自動化との相性を見ておくべきです。

実装系で詰まりやすいのは、「コンソール上で試せた」ことと「本番手順を再現できる」ことを同じだと思う点です。検証後に継続利用するなら、SDKやCLI経由で再現可能かまで見てから採用判断をするほうが安全です。

Model Gardenの活用事例

Model Gardenそのものを前面に出した顧客事例はまだ多くありませんが、Model Gardenで提供されるモデルを含むVertex AI活用例はすでに複数公開されています。ここでは、モデル選定の幅が業務価値につながっている事例を見ておきます。

Replit

Replitの顧客事例では、ReplitがClaude on Vertex AIを使い、Cloud Runと連携しながらアプリ生成体験を支えていると紹介されています。Model Garden経由で利用できるパートナーモデルを既存GCP基盤とつなぎやすい点が、実装上の利点として表れています。

この事例が示すのは、Model Gardenの価値が「モデルを選べること」だけではなく、その先のCloud Runやデータ基盤と同じクラウド内でつなげやすいことにある、という点です。

Shopify

同じClaude on Vertex AIの紹介ページでは、ShopifyのSidekickに関するコメントも掲載されています。ClaudeとVertex AIの組み合わせが、AI支援型のコマース体験を支える実運用基盤として使われていることが分かります。

ここで参考になるのは、Shopifyのような大規模事業者でも、単一モデル固定より「用途に応じてモデルを選べる基盤」を重視している点です。Model Gardenは、その前提を作りやすい入口だといえます。

GitLabとGA Telesis

Generative AI support on Vertex AI generally availableでは、GitLabがCodeyを使った脆弱性説明機能を、GA Telesisがメール注文と在庫情報の照合を自動化するデータ抽出ソリューションをVertex AI上で構築していると紹介されています。

厳密にはModel Garden単体の事例ではありませんが、同じVertex AI基盤の上で「用途に応じてモデルを選び、カスタマイズし、アプリへ載せる」流れが実務で使われている点は、Model Gardenの役割を理解するうえで参考になります。

---

Model Gardenと他サービスの違い

Model Gardenは名前が広すぎるため、Google AI StudioやVertex AI全体と混同されがちです。ここを整理すると、何をどこでやるべきかがかなり明確になります。

Google AI Studioとの違い

Google AI Studioとは何かは、主にGoogle独自モデルを素早く試すための環境です。一方、Model GardenはGoogle独自モデルに加えて、オープンモデルやパートナーモデルまで含めた比較・選定の入口です。

その違いを表にすると次のようになります。

観点	Google AI Studio	Model Garden
主な役割	Googleモデルの試作とプロンプト検証	複数ベンダーのモデル発見、比較、導線管理
モデル範囲	主にGoogle独自モデル	Google独自モデル、オープンモデル、パートナーモデル
本番導線	Vertex AI移行を前提に考えやすい	そのままVertex AIのチューニングやデプロイへ接続しやすい
向いている場面	まずGeminiを試したい	どのモデルを採用するか比較したい

この表が示すように、Google AI Studioは試作ツール寄り、Model Gardenはモデル選定ハブ寄りです。Gemini一本で行くと決まっていないなら、最初からModel Garden視点で整理したほうが後戻りが少なくなります。

Vertex AI全体との違い

Model GardenはVertex AIの一部であり、Vertex AI全体そのものではありません。Vertex AIの公式ドキュメントでも、Model Gardenはチューニング、評価、サービングと統合された入口として説明されています。

ざっくり言えば、役割分担は次のとおりです。

• Model Garden
  どのモデルを使うかを探し、試し、次のアクションへ進む入口
  
  
• Vertex AI全体
  モデル選定後の評価、チューニング、RAG、エージェント、監視、運用まで含む実装基盤

この違いを理解していないと、「Model Gardenを触ったから導入設計も終わった」と誤解しやすくなります。実際には、Model Gardenは入口であり、運用設計はVertex AI全体で詰める必要があります。

導入判断で詰まる論点

概念解説として最後に残るのは、「結局どこで判断すべきか」です。Model Garden導入で詰まりやすい論点は、次の3つに絞れます。

• モデルの賢さで選ぶか、運用方式で選ぶか
  PoCでは前者が目立ちますが、本番では後者の影響が大きくなります。
  
  
• API利用で足りるか、自前デプロイが必要か
  レイテンシ、データ制御、コスト最適化の考え方が変わります。
  
  
• 組織として何を許可するか
  個人の好みでモデルを増やすのか、許可済みモデルに絞るのかで運用難易度が変わります。

AI総合研究所としては、PoC段階ではモデル性能比較をしてよい一方、採用判断では「本番方式まで含めて比較できているか」を先に確認することを推奨します。ここを飛ばすと、精度では勝っても運用で負けるケースが出ます。

---

Model Garden利用時の注意点

Model Gardenは便利ですが、使い始める前に知っておかないと判断を誤るポイントがあります。特に、セキュリティ、ポリシー、デプロイ方式の3点は先回りで見ておくべきです。

安全性表示があっても最終判断は自社側で必要

Model Garden overviewでは、Googleが提供するサービング用コンテナに対する脆弱性スキャンに加え、featured partnersのモデルに対するチェックポイントスキャンが説明されています。Hugging Faceモデルについても、Hugging Face側やサードパーティスキャナによる検査結果が表示されます。一方で、疑わしいモデルやリモートコード実行の可能性があるモデルは、警告付きでデプロイ可能な場合もあると明記されています。

つまり、Model Gardenに載っているから無条件に安全とは言えません。特にオープンモデルをself-deployする場合は、表示された警告やライセンス条件まで読んだうえで採用判断する必要があります。

組織ポリシーは万能ではない

Control access to Model Garden modelsによると、Model Gardenの組織ポリシーはModel Garden内のモデルにだけ適用され、Vertex AI Model Registryに登録されたモデルには適用されません。また、許可・拒否リストは500値までで、モデル群をまとめて一括許可・拒否することもできません。

このため、統制を強めたい企業ほど、ポリシーがあるから安心と考えるのではなく、「何をModel Gardenで管理し、何を別管理にするか」を整理しておく必要があります。

self-deploy型は運用負荷も引き受ける

Model Garden overviewと2025年10月のGoogle Cloud Blogを見ると、Model Gardenではself-deploy型のモデル選択肢も広がっています。これは制御性の高さにつながる一方で、機械タイプ選定、レプリカ数、オートスケール、リージョン、VPC設計といった判断も自社側に戻ることを意味します。

そのため、最初からすべてをself-deployで考えるより、managed APIで十分な業務と、自前デプロイが必要な業務を分けて検討したほうが現実的です。

Model Gardenの料金

Model Gardenの料金は、単一の月額プランではありません。何を選ぶか、どう動かすかで課金体系が変わるため、まずは「料金の構成要素」を分けて理解する必要があります。

料金の構成要素

Model Garden overviewでは、オープンモデルに対してはチューニング時の計算資源、デプロイ時の計算資源、Colab Enterpriseなどが課金対象だと説明されています。一方、Vertex AI pricingでは、パートナーモデルはmanaged APIとしてトークン課金で整理されています。

整理すると、主な考え方は次の3つです。

• パートナーモデルや一部managed API
  入力トークン、出力トークン、キャッシュ、バッチなどの従量課金
  
  
• self-deploy型オープンモデル
  エンドポイントに使うGPUやTPUなどの計算資源課金
  
  
• チューニング
  学習トークン数または学習用計算資源に応じた課金

つまり、Model Garden自体に一律料金があるわけではなく、選んだモデルと実行方式がそのまま見積もり条件になります。

代表的な価格例

2026年4月時点のVertex AI pricingをもとに、代表例を挙げると次のようになります。

区分	価格例	補足
Claude Sonnet 4.5 Global	入力 100万トークンあたり 3.00ドル、出力 100万トークンあたり 15.00ドル	パートナーモデルのmanaged API課金
Claude Haiku 4.5 Global	入力 100万トークンあたり 1.00ドル、出力 100万トークンあたり 5.00ドル	低コスト寄りのパートナーモデル例
Gemma 3 27B ITのfine-tuning	学習 100万トークンあたり 6.83ドル	チューニング課金の例
Gemini 2.5 Flashのfine-tuning	学習 100万トークンあたり 5.00ドル	Google独自モデルのfine-tuning例

この表だけで料金を判断すると危険です。パートナーモデルは推論中心の比較に向きますが、オープンモデルのself-deployではGPU構成と稼働時間が支配的になるため、単純なトークン単価比較では実態を見誤ります。

価格注記と読み解き

料金を読むときに大事なのは、「どの価格表を見ているか」を混ぜないことです。Model Garden overviewはオープンモデルの課金対象を示し、Vertex AI pricingはパートナーモデルやチューニング価格を具体的に示しています。両者は補完関係にあり、同じ意味の表ではありません。

企業側の見積もりでは、まずAPI従量型かself-deploy型かを分け、その後でPoC期間の利用量を入れて計算するのが現実的です。モデル単価だけで比較すると、運用開始後に想定外の差が出やすくなります。

Model Gardenで選んだモデルを業務実装へつなぐなら

Model Gardenは、どのモデルを使うべきかを比較しやすい優れた入口です。ただし、業務で成果を出すには、モデル選定だけでなく、その後にどの業務フローへ接続するか、誰が何を使えるか、実行ログをどう残すかまで設計しなければ定着しません。

特に、Google独自モデル、パートナーモデル、オープンモデルを比較し始めると、PoCは進んでも本番方式がばらつきやすくなります。ここを整理しないまま進めると、精度比較はできても運用設計で止まりやすくなります。

AI総合研究所のAI Agent Hub資料では、Vertex AIやModel Gardenで選んだモデルを前提に、業務システム連携、管理ダッシュボード、権限設計、実行導線の整備をどう進めるかを整理しています。Model選定をPoCで終わらせず、業務実装へつなぐ判断材料としてご確認ください。

---

Model Gardenのまとめ

Model Gardenは、Vertex AI上でGoogle独自モデル、オープンモデル、パートナーモデルを横断的に探し、試し、必要に応じてチューニングやデプロイへ進められるモデル選定ハブです。単なる一覧画面ではなく、その後の評価と運用導線まで含めた入口として見るべきサービスです。

重要なのは、モデル性能だけでなく、managed APIかself-deployか、組織ポリシーで制御できるか、料金がどの単位で発生するかまで含めて判断することです。まずは用途別に候補を3つほどに絞り、実行方式まで見たうえで採用判断する進め方をおすすめします。