1. 初心者向け：最速スタート手順
📺 この動画でわかること（先に全体像だけ掴みたい人向け）
こんにちは。ジェネレーションB、運営者のTAKUです。
Google AI Studio（Build mode）は、公式ドキュメントを読んでも「結局どこを触ればいいの？」で止まりがちです。
この動画では、NotebookLMを使ってBuild modeの考え方→最短セットアップ→やりがちな事故ポイントまでを一気に整理しています。
コードを本格的に書く前に「全体の流れ」と「触るべき場所」を頭に入れておくことで、無駄な試行錯誤やAPIキー事故を避けられます。
まずは動画で俯瞰し、その後に本文の手順どおり進めるのが最短ルートです。
⏱ タイムスタンプ（見たいところだけ拾えます）
- 0:00｜Google AI StudioとBuild modeの全体像
- 1:35｜Build modeで「最初に触るべき場所」
- 3:10｜最短で動かす初期セットアップの流れ
- 5:05｜初心者がやりがちなミスと回避ポイント
- 7:20｜この記事の手順と、動画の使い分け方
👉 次の行動（ここから実際に手を動かす）
動画で流れが掴めたら、このまま下の手順に進んでOKです。
Build modeは「触りながら理解する」前提の設計なので、完璧に理解しようとせず、まずは動かしてみてください。
詰まりやすいポイントは本文中で全部フォローしています。
ここだけ先に読めば、Google AI Studio Buildの記事本文がグッと読みやすくなるはずです。
私も最初はこの順番で進めます。
1-1. 最速3ステップ（まずは成功体験）
- Buildmodeを開いて、Startwithapromptで「入力→ボタン→結果表示」の1画面アプリを作る
- プレビューで1回動かす（ボタンを押して結果が出たら成功）
- 次にやるのは1つだけ：出力を「結論→理由→箇条書き」に整える（UIより先に中身を安定させる）
成功判定はシンプルでOKです。
「入力して、ボタン押して、結果が出る」まで行けば、最初の山は越えてます。
最初に作るプロンプト例（コピペ用）
ブログ下書きを整える簡単なWebアプリを作ってください。
画面は1つ。要素は以下の3つだけにしてください。
- 入力欄（テキスト）
- 実行ボタン
- 結果表示欄
出力は次の順番で固定してください。
1) 結論（1〜2行）
2) 理由（3つ）
3) 次のアクション（3つ）
エラー時は、ユーザーに分かる日本語で表示してください。用語辞書（ここだけ押さえればOK）
専門用語は、全部を理解しなくて大丈夫です。
この記事で出てくる範囲は、まずは「こういう意味なんだな」くらいで十分です。
| 用語 | 超ざっくり意味 | 詰まった時の見方 |
|---|---|---|
| Google AI Studio | Gemini APIを試したり、アプリを作ったりする場所 | まずは「プロンプト→出力」が動けばOK |
| Buildmode | 会話でWebアプリを作って、その場でプレビューできるモード | 作る→触る→直すを最短で回す場所 |
| Vibecoding | 会話しながらノリよく試作して形にする作り方 | 一度に盛りすぎず、変更は1〜2点ずつ |
| GeminiAPI | Geminiをアプリから呼び出すための窓口 | 「アプリの外」と通信する部分だと思えばOK |
| APIkey | GeminiAPIを使うための鍵 | 漏れると勝手に使われる可能性があるので注意 |
| GEMINI_API_KEY | APIkeyを環境変数で渡すための名前（例） | コードに直書きしないための仕組み |
| geminiService.ts | GeminiAPIを呼ぶ処理がまとまりやすい中心ファイル | 出力がブレる時はここを疑うと早い |
| GenAITSSDK | GeminiAPIを呼ぶためのライブラリ（TypeScript想定） | 通信周りの土台。UIより先に把握すると強い |
| Runsettings | モデル選択や安全設定など、動き方を決める場所 | 動かない/空返答の時はここも見る |
| Annotationmode | 画面を指さしてUI変更を指示できる機能 | UIの微調整はこれが速い |
| AIChips | 画像生成やLiveAPIなど、やりたい機能を追加する導線 | 機能を足すほど運用の難易度も上がる |
| CloudRun | アプリを外部公開するための選択肢の1つ | 公開=キーと費用の設計が重要になる |
| GitHubexport | コードをGitHubに出して運用・改修しやすくする | 履歴が残るので、壊れても戻せる |
| ZIPdownload | コードをZIPで落としてローカルで開発する | AIStudioに“戻す”運用は期待しすぎない |
| FreeTier/PaidTier | 無料枠/有料枠のようなイメージ | 上限や扱いが違うので、公式確認が安心 |
| RPM/TPM/RPD | 叩きすぎ防止の制限（分/日あたり等） | 急に止まる時はレート制限の可能性 |
| 403AccessRestricted | 地域や条件などでアクセス制限がかかるケース | AvailableregionsやGoogleWorkspace制御も疑う |
| CORS | ブラウザから別ドメインに通信する時の制限 | 外部公開や別API連携で出やすい壁 |
全部覚える必要はないです。
最初はBuildmode/プレビュー/APIkey/CloudRunあたりだけ押さえれば十分です。
失敗回避（ここだけは先に知っておくと安心）
Buildはテンポ良く進むぶん、油断すると事故りやすいです。
私が「これだけは先に言っておきたい」ポイントをまとめます。
やらかしがちなTOP5
- APIkeyをフロントに直書きしてしまう（見えた時点で危険）
- 共有したらコードが見える前提を忘れる
- 外部公開（CloudRun等）で誰のAPIkeyで呼ぶかを決めていない
- 入力が長文化してトークン超過やコスト増に気づかない
- 連打や自動アクセスでRPM/TPM/RPDに引っかかる
私がやる最低限の安全策
- APIkeyは環境変数で管理して、コードに残さない
- 外部公開するなら、GeminiAPI呼び出しはサーバー側に寄せる
- 入力欄に文字数上限とカウンタを付ける
- ボタン連打を防ぐために実行中は無効化する
費用・セキュリティ・法務など、判断を誤ると影響が出る領域もあります。
この記事の内容は一般的な整理として読みつつ、正確な情報は公式サイトをご確認ください。
業務利用や機密を扱う場合は、最終的な判断は専門家にご相談ください。
1-2. 【30秒でわかる結論】
- プロトタイプ作成なら「Build mode」一択
- 継続開発・運用なら「GitHub Export」前提
- 迷ったら「App Gallery」のRemixから始める
1-3. 【今すぐやること3つ（3分で判断できます）】
- 目的・入力・出力をメモ帳に書き出す（迷いを減らす）
- Google AI Studioを開き、左メニューの「Build」に入る
- App Galleryから近い作例を選び「Remix」ボタンを押す
わかる。
情報多すぎて手が止まるやつ。
Google AI Studio Buildで検索しているあなたは、「Build modeって結局なに？」「Vibe codingってどうやるの？」「APIキーやデプロイはどうすれば安全？」といった疑問が一気に押し寄せていませんか？
さらに、Run settings、Annotation mode、Cloud Runへのデプロイ、GitHub Export、レート制限（RPM/TPM）など、専門用語が次々と出てきて、「結局、何から手をつければいいの？」と迷ってしまいますよね。
この記事では、Google AI Studio Buildの全体像を整理し、アプリを作って公開・運用するまでの手順を、迷わない順番で解説します。
この記事でわかること
- Google AI Studio Buildでできることの全体像
- Build modeの始め方とVibe codingのコツ
- APIキーの安全な扱いと外部公開の注意点
- Cloud Run・GitHub Export・料金や制限の考え方
2. Google AI Studio Buildの作り方
この章でわかること：最短で動くプロトタイプを作るための手順と判断軸
この章では、Google AI Studio Buildで「とりあえず動くWebアプリ」を作るまでの流れを、つまずきやすいポイント込みでまとめます。
プロンプトの投げ方、どこを編集するか、機能追加のやり方がクリアになります。
2-1. AI Studioの使い方 Quickstart
私のおすすめは、最初から完璧を狙わずに「動く雛形を作る → 小さく直す」を繰り返すことです。Google AI Studioは、プロンプト実験だけでなく、Gemini APIを呼ぶコードの雛形まで一気に用意してくれるので、最短なら数分で“それっぽいアプリ”が立ち上がります。
ここで大事なのは、Quickstartを「手順を暗記するもの」と思わないことですね。
むしろ、Quickstartは“迷ったときに戻る地図”です。
まずはアプリが動く状態まで持っていって、そこから構造を理解する方が結果的に早いです。
まずは最短ルートのチェックリスト
- AI StudioでAPIキーを用意（Gemini APIを呼ぶ前提ならここがスタート）
- Build modeに移動して、作りたいものを文章で伝える
- 生成されたアプリを右側のプレビューで触って確認
- 違和感があれば、チャットで修正依頼 or Codeタブで直す
最初のゴールは「公開できる完成品」ではなく「触れる試作品」にしておくと、途中で折れにくいです。
ここでつまずく人が多いのが、「AI Studioのどこを触ればいいか分からない」問題です。
Buildmodeに行く前に、まずはAI Studioで“1回成功する体験”を作っておくと、後がめちゃくちゃラクになります。
私がよくすすめるのは、文字起こしみたいにゴールが分かりやすい作業でAI Studioに慣れること。
手順をなぞるだけで「ファイルを入れる→指示する→結果が出る」まで体験できます。
Gemini文字起こしのやり方（AI Studio手順つき）
Quickstartで私が最初に決める「4つの前提」
Quickstartをスムーズにするために、私は最初に4つだけ前提を決めます。
これを決めずに走ると、プロンプトの指示がブレて、生成されたUIもコードも散らかりがちになります。
- 目的：このアプリは何をラクにするのか（例：文章整形）
- 入力：ユーザーが何を入れるのか（例：テキスト、画像）
- 出力：何が返ってくれば成功か（例：要約文と箇条書き）
- 画面：UIは1画面か、複数画面か（最初は1画面推奨）
| 決めること | 例 | 迷ったときの基準 |
|---|---|---|
| 目的 | ブログ下書きを整える | 成果物が一言で言えるか |
| 入力 | 下書き本文＋トーン指定 | 入力が増えたら脱線のサイン |
| 出力 | 見出し案＋本文草案 | 出力を先に固定すると速い |
| 画面 | 左入力・右出力の1画面 | 最初はUIを増やさない |
生成後に「何がどこにあるか」をメモしておくと、修正がスムーズになります。
例えば「入力フォームはcomponents側」「API呼び出しはgeminiService.ts」といった具合です。
※料金や仕様は更新されることがあります。最終確認は公式情報で行ってください。
2-2. Build mode使い方とVibe coding
Build modeは、ざっくり言うと「会話でアプリを作るモード」です。
いわゆるVibe coding（会話しながらノリよく作る）と相性がいいです。
Build modeの良さは、「作る → 触る →直す」の距離が極めて近いことです。
環境構築などの“儀式”なしでアイデアを検証できます。
ただし、勢いで進むほど仕様がブレやすいので、Vibecodingを行う際も「指示の型」を持っておくことで、実用的な生成物が得られます。
Build modeの始め方は3パターン
- Start with a prompt：作りたいものを文章で指示して開始
- I’m Feeling Lucky：アイデアを提案してもらって開始
- App GalleryのRemix：作例をコピーして改造（おすすめ）
初心者ほどApp GalleryのRemixをおすすめします。
ゼロから説明するより、動く完成形を「ここを変えて」と進めた方が迷いにくいです。
Vibe codingを失敗させない「指示のテンプレ」
指示テンプレ（例）
- 目的：〇〇をできるだけ簡単にしたい
- 画面：入力エリア、実行ボタン、結果表示の3要素
- 出力：結論→理由→箇条書き→次のアクションの順
- 例外：エラー時はユーザーに分かる言葉で案内
- 制約：既存の動作は壊さずに追加する
（出典：Google AI for Developers「Build mode in Google AI Studio」）
Build modeは便利ですが、共有や外部公開に進むと「APIキーの扱い」が一気に重要になります。
次の章に進む前に、後半のセキュリティ周りだけでも先に目を通しておくと事故りにくいです。
2-3. AI Chipsで画像生成やLive API
Build modeでは、AI Chipsを使って機能（画像生成、Google Search等）を追加できます。
しかし、機能を増やすとUIも複雑になります。
私は、AI Chipsを足すときは必ず「画面に何を増やすか」を先に決めます。
最初は「テキストだけで成立するUI」で作り、慣れてからリッチな機能を追加するのが失敗しないコツです。
画像生成を足すときに私が気にする「3つ」
- 生成結果の扱い：1枚だけ表示か、履歴として並べるか
- 再生成の設計：条件を微調整して再生成しやすくするか
- 重さの見せ方：生成が重いときのローディング表示
2-4. geminiService.tsとGenAI TS SDK
Build modeで生成されるコードの中で、最も重要なのがgeminiService.tsです。
ここに「プロンプトの組み立て」「Gemini API呼び出し」「レスポンスの整形」が集約されています。
UIをいじる前に、まずこのファイルを見て「どうやってAPIを呼んでいるか」を理解すると、その後の改造が圧倒的に楽になります。
入力をどう渡して、どんな指示でモデルを動かして、どういう形で返ってきたら正解なのか。
ここが決まると、UI側の設計も自然に決まります。
UIより先に、geminiService.tsを読めるようになると強いです。
“出力が安定しない”ときの考え方
出力形式を固定したい場合は、プロンプト内で「JSON形式の例」や「箇条書きのフォーマット」を具体的に提示するのが効果的です。
2-5. Run settingsとAnnotation mode
Run settingsでは、モデルの選択や安全設定（Safety Settings）を行います。
「No Content」エラーが出る場合は、安全設定が厳しすぎる可能性があります。
Annotation modeを使えば、プレビュー画面上のUIを直接クリックして修正指示を出せます。
「このボタンを大きく」「ここを赤く」といった直感的な修正に便利です。
修正は「一箇所ずつ」行うのがコツです。
※料金・仕様は更新されることがあります。最終確認は公式情報で行ってください。（出典：公式サイト）
2-6. App Gallery CopyとRemix活用
私が一番推奨するのは、App Galleryで近い完成形を探し、Remixして改造する方法です。
ゼロから作るよりも、必要な機能が実装済みの状態からスタートできるため、効率が良いです。
Remixを成功させるコツ
- 最初に「変えない部分」を宣言する
- 変更は一回で盛りすぎず、1〜2点ずつ
- 大きく崩れたら、直前の状態に戻せるようにしておく
Build modeは変更履歴が追いにくい場合があるため、ある程度形になったら早めにGitHub Exportを行うのが安心です。
3. Google AI Studio Buildの公開運用
この章でわかること：公開範囲とセキュリティリスクによるデプロイ先の判断軸
この章では、作ったアプリを「共有・公開・運用」する際の注意点、特にAPIキーの扱いとデプロイ方法について解説します。
3-1. API keyとGEMINI_API_KEY
APIキーは「鍵」です。
流出すると不正利用や高額課金のリスクがあります。
公開やチーム利用を考えるなら、キーの扱いを“仕組み”にしておく方が安心です。
キー管理の鉄則
- コードに直書きしない：フロントエンドのコードにキーを含めない
- 環境変数を使う：
GEMINI_API_KEYなどの環境変数で管理する - 公開前に確認：共有やデプロイ前に、キーがコードに残っていないかチェックする
フロントエンド（ブラウザ側）に実キーを直書きするのは厳禁です。
※セキュリティは状況によって最適解が変わります。最終確認は公式情報で行ってください。
Geminiと他のAIの比較記事はこちら：ChatGPTとGeminiの料金・安全性の違い比較
3-2. キー露出と共有アプリ外部公開
AI Studio内の「Share」機能と、Cloud Run等への「外部公開」は別物です。
AI Studio内での共有は比較的安全ですが、外部公開する場合、APIキーを安全に扱う仕組み（バックエンドでの管理など）が必須です。
外部公開で安全にやる基本方針は「キーを使う処理をサーバー側へ移す」です。
APIkeyの話って「鍵を隠す」だけに目が行きがちなんですが、実は同じくらい大事なのが入力するデータのほうです。
Buildで作ったアプリは便利なぶん、うっかり“素材”を丸ごと入れてしまう事故が起きやすいんですよね。
たとえば、音声の文字起こし、議事録、顧客対応メモ、社内チャットのコピペ。
これ、気づかないうちに個人情報や機密が混ざりやすいので、先に「入力していい範囲」を決めておくのが安全です。
AIの個人情報リスク対策完全ガイド（入力OK/NGの判断軸）
3-3. Cloud RunとGitHub ExportとZIP
公開方法は目的によって使い分けます。
| 方法 | 向いてる人 | 注意点 |
|---|---|---|
| Cloud Runデプロイ | 今すぐURLで公開したい | Billing設定が必要。キーは安全に管理される。 |
| GitHub Export | 継続的に開発・運用したい | 自分でCI/CDやキー管理を行う必要あり。 |
| ZIP Download | 手元のエディタで触りたい | AI Studioとの同期は切れる。 |
AI StudioからCloud Runへ直接デプロイする場合、APIキーはCloud Runの環境変数として設定され、クライアント側には露出しない構成が自動で作られるケースが多いです。
これが最も手軽で安全な公開方法の一つです。
継続的に機能追加をするなら、GitHub Exportを選び、履歴管理（Git）を行いながら開発するのが確実です。
※費用・運用体制は状況で最適解が変わります。正確な情報は公式サイトをご確認ください。
3-4. 無料枠Paid TierとRPM/TPM/RPD
Gemini APIには無料枠（Free Tier）がありますが、レート制限（RPM: 分間リクエスト数など）があります。
本格運用（Paid Tier）に移行する際は、課金体系を理解しておく必要があります。
私は料金の話をするとき、まず「トークン＝文章量のイメージ」として捉えます。
入力が長いほど、出力が長いほどコストが増えます。
アプリ側で「入力を短く誘導するUI」に寄せるだけで、コストが読みやすくなります。
レート制限の3軸
| 項目 | 意味 | 注意点 |
|---|---|---|
| RPM | 分あたりリクエスト数 | 連打するとエラーになる |
| TPM | 分あたりトークン数 | 長文や画像で上限に達しやすい |
| RPD | 日あたりリクエスト数 | Free Tierには日次上限がある |
※料金・仕様は更新されることがあります。最終確認は公式情報で行ってください。（出典：公式サイト）
※制限ルールは体感が変わるため、最新は公式も確認してください。（出典：公式サイト）
3-5. Google AI Studio Buildまとめと403
最後にまとめです。
Google AI Studio Buildは、アイデアを形にする最速のツールです。
ただし、外部公開する際はAPIキーの管理とコスト設計が重要になります。
403エラー（Access Restricted）が出た場合、焦らずに「地域制限」や「アカウント設定」を確認してください。
日本は対応していますが、VPN等で対象外地域になっていないか、Workspace管理者が許可しているかがポイントです。
※対応環境はアップデートで変わるため、公式の要件も併せて確認してください。（出典：公式サイト）
結論：まずはBuild modeで1本試す
Google AI Studio Buildは、アイデアを形にする最速のツールです。
迷っている時間はもったいないので、まずは手を動かしましょう。
3-6. 迷った時の最終チェック
- プロトタイプ作成ならBuild mode
- 公開するならCloud Runへのデプロイ（Billing設定要）
- 本格開発ならGitHub Export
次の行動：無料枠（または最小プラン）で「Build mode」を使って、簡単なアプリを1本だけ試してください。
3-7. AI開発（Vibe coding）を加速させる「入力環境」の3選
Google AI Studioの「Build mode」は、コードを書く時間よりも、AIに的確な指示（プロンプト）を打ち込む時間が長くなる開発スタイルです。
思考を止めずに指示を出し続ける「Vibe coding」において、ボトルネックになりがちなのがキーボードの入力環境です。
誤入力を減らし、長時間叩いても指が疲れない道具を選ぶことは、修正コストを減らす最も確実な投資になります。
①「とりあえず静かな環境で始めたい」高コスパ入門機
ポチップ
 | ロジクール ワイヤレスキーボード K295GP K295OW 静音 耐水 キーボード 無線 Unifying windows chrome K295 国内正規品 2年間無償保証 価格:3201円 |
②「打つ感覚を楽しみ、リズムを作る」メカニカルの最適解
ポチップ
 | 価格:12700円 |
③「プログラマーが辿り着く終着点」指を守る一生モノ
ポチップ
 | 価格:36850円 |
