Google Cloud、AI プロトタイプから本番環境移行前の 10 の質問を提示

It’s never been easier to start an AI-powered startup on Google Cloud.

You grab an API key from Google AI Studio at breakfast, paste it into Antigravity, and by lunch you’ll have a nascent prototype of your product.

But it’s not all one straight line to progress. It's common to bump into these three challenges as you build out your stack:

• A leaked API key racks up a large bill in 48 hours.

• A "quick" migration from AI Studio to Gemini Enterprise Agent Platform stalls the roadmap for weeks because nobody on the team owns Identity and Access Management (IAM).

• The launch works, until the app starts returning HTTP 429 Too Many Requests because of default per-project quotas, and there's no clean path to more capacity without paying a premium.

None of these are unique edge cases. . They're  default failure modes of moving fast without a plan, and we've all done it at least once.

Below are the 10 questions every startup should be ready to answer before they scale,  grouped into the three phases where decisions can shape your future:

• Onboard (setting up your own projects and identities right)

• Scale (getting more throughput without breaking the bank)

• Govern (keeping costs, keys, and agents from running away). Each question ends with a short, runnable snippet you can copy into your own project today.

These ten are scoped to the prototype-to-production transition itself. Adjacent decisions that matter just as much but aren't specific to that move, your data layer and RAG architecture, CI/CD, network design, are deliberately out of frame here.

Onboard: get the foundation right (in the first hour).

#1 Where should I start: Google AI Studio or Gemini Enterprise Agent Platform?

Both surfaces expose the same Gemini family of models, but they solve different problems.

• Google AI Studio (with the Gemini Developer API) is the fastest path from an idea to working code. A browser IDE, an API key, a generous free tier, and no cloud project to configure. It's where most ideas should start, and Google's own guidance says as much.

• Gemini Enterprise Agent Platform (formerly Vertex AI) has the same Gemini models (plus 3rd party and OSS ones)  with enterprise controls around them: IAM and service-account auth instead of raw keys, VPC Service Controls, Cloud Logging and Monitoring, reserved capacity, regional endpoints, and the compliance surface your first enterprise customer's security review will ask about.

The right answer for most startups is both, sequenced deliberately: first prototype in AI Studio, then migrate before you have real users. The danger for startups is treating them as interchangeable solutions, AI Studio's simple key model does not translate to enterprise controls, and Agent Platform's IAM model might look like overkill until the day it saves you from a stolen-credential incident.

It's less work than it sounds like.

The unified google-genai SDK targets both:

code_block

• )])]>

The rule of thumb: the day you have users who are not you or your startup colleagues, you should already be on Gemini Enterprise Agent Platform.

#2  How do I set up a Google Cloud project without becoming an IAM expert?

The biggest reason startups stall on the migration to Agent Platform isn't the code, it's the operational leap from "here's an API key" to a cloud project with folders, service accounts, org policies, logging, and IAM bindings. If your team doesn't have a dedicated cloud admin, that first project setup can eat a week of engineering time.

Three moves cut that dramatically:

Use an opinionated project template instead of clicking through the console. The Cloud Setup checklist and the Google Cloud Architecture Framework give you a production-grade folder hierarchy (prod / non-prod / dev), a central logging + monitoring project, Security Command Center turned on, and baseline org policies, without you having to design them from scratch.

• Enable the APIs you'll actually use, once. Batch it so you're not doing it project-by-project when you need it. The billing-link step is not optional. Every paid API you're about to enable will refuse to activate on a project with no billing account attached, so we handle that first.

• Let Gemini pick the roles, but ask it for the narrow ones. You don't have to memorize the roles reference. In the Grant access dialog, Help me choose roles lets you describe the task in plain language, "this service account needs to call Gemini models and read one Cloud Storage bucket", and get predefined roles back with the reasoning shown. One catch worth knowing on day one: by default it suggests roles that cover common journeys, which usually means a service's Admin, Editor, or Viewer. Those are broader than you want. Say "least privileged" or "narrowest access" in the prompt and it returns granular roles instead. Same amount of typing, considerably smaller blast radius when a credential leaks.Sources: Get predefined role suggestions with Gemini assistance

code_block

• )])]>

Sources: gcloud services enable reference, · gcloud billing projects link (GA),  GE Agent Platform environment setup.

If you're a solo founder, resist the urge to build in your personal GCP account. Create a proper organization or self-owned org first, then create the project inside it. That single decision can make everything else, fromIAM to billing and audit, dramatically easier.

#3 I'm on Google Cloud, how should my code actually authenticate: API keys, service accounts, or user credentials?

There's a hierarchy of safety here, and the easiest option is rarely the right one in production.

Raw API keys are fine for local prototyping. They are dangerous in production because they are long-lived, easy to leak into a client bundle or a public repo, and grant unbounded access until you notice.

• User credentials via OAuth (application default credentials) are best for interactive tools, CLIs, and any code that runs on a developer's laptop.

• Service accounts with least-privilege IAM roles are the right answer for anything running on a server, in a container, or in a scheduled job.

The pattern you're aiming for is one where your code never sees a key at all. It just calls the Google Auth library, which quietly reads Application Default Credentials (ADC) from the environment,  a short-lived token minted for whichever service account is attached to your Cloud Run service, GKE workload, or Compute Engine VM. You get enterprise-grade auth without writing any auth code.

code_block

• )])]>

code_block

)])]>

Do one last favor to your future self: give that service account the minimum IAM role your workload actually needs,  usually roles/aiplatform.user for calling models, not the broader admin roles. It takes an extra 30 seconds and prevents the credential from becoming a master key if it leaks.

#4 When should I actually stop procrastinating and migrate from AI Studio's API key to Agent Platform's IAM model?

Sooner than you'd like,  and the correct trigger is not when it breaks. It's when any of these is true:

Your key has left your laptop (checked into a repo, pasted into a Slack, shipped in a mobile app).

• You have more than one person on the team who needs to call the API.

• You're spending more than a few hundred dollars a month.

• You're about to onboard paying customers.

A potential pitfall that can catch growing startups off guard is simple: a leaked Gemini API key on an account that normally spends $180 a month gets scraped from a public repo and used to run distillation attacks,  accumulating tens of thousands of dollars in charges before the owner even sees the first billing alert. The Google Cloud Shared Responsibility Model is unambiguous: the customer is liable for charges incurred with their own valid credentials.

The migration itself is genuinely smaller than the anxiety around it. In