Upgrade to Pro — share decks privately, control downloads, hide ads and more …

バイブコーディング時代のWebアプリ開発入門~Cloud Runで学ぶセキュアなビル...

Sponsored · SiteGround - Reliable hosting with speed, security, and support you can count on.

バイブコーディング時代のWebアプリ開発入門~Cloud Runで学ぶセキュアなビルドとデプロイ

本スライドは9月12日に開催された「がんサバイバーシップのためのAI ハッカソン」にて講演させていただいた内容になります
https://saqraaihackathon.my.canva.site/

Avatar for 尾﨑勇太/Yuta Ozaki

尾﨑勇太/Yuta Ozaki

September 16, 2026

More Decks by 尾﨑勇太/Yuta Ozaki

Other Decks in Technology

Transcript

  1. 講師紹介 オザキ ユウタ 尾﨑 勇太 株式会社 MBK デジタル Engineering Manager

    Lead Data Engineer 金融システム開発、Web・アプリ開発、ソフトウェア品質管理において、プレイ ヤー(開発実務)およびマネジメントの両面で豊富なバックグラウンドを保有。 マーケティング事業会社における事業基幹システム更改を契機に、バックエンド エンジニアからデータエンジニアへキャリアをシフト。SEOや広告領域における データ基盤構築・データ利活用を主導した実績を持つ。 現職のMBKデジタルでは、フルスタックなデータエンジニアとして要件定義から インフラ・バックエンド・フロントエンドの実装、データパイプライン構築まで幅広く 主導している。 DATA Saber(since 2025/06) Master of DATA Saber(since 2026/02) データパイプライン講座の運営 © MBK Digital co., Ltd. All Rights Reserved. 2
  2. 独自のビジネスフィールド 三井物産の子会社ならではの幅広い事業領域でのチャレンジ MBK デジタルが取り組むデータ活用・ AI 活用テーマ 消費財 • • •

    自社 EC 事業の拡大 科学的な根拠に基づく IP コラボレーション 生成 AI を用いた社内 FAQ の精緻化 インフルエンサー(ファーストピン)分析 マルチモーダル分析に基づく広告出稿高度化 大規模分析用データ基盤構築 モビリティ ・運輸 • • • 自社アプリの利用促進分析 配送ルートの最適化 トレーディングロジックの規定 小売り契約プランの収益性検証 レポーティング業務の自動化 教育機関・ 自治体 • • 施設訪問者数予測モデル構築 エンロールメントマネジメント 流通・小売 • • プライベートブランド商品の開発支援 在庫最適化、販売数需要予測 エンタメ • • • インフラ・ エネルギー • • © MBK Digital co., Ltd. All Rights Reserved. 3
  3. 進行 30分・解説形式 公開ボタンの向こう側には、押した人からは見えない部分があります。今日はその、見えない側の話です。 概要にはセキュアなビルドとデプロイと書きましたが、今日お話しするのはAIに何を預けているかです。 ※ 本日は実習ではなく解説です。手を動かす必要はありません。画面と考え方を見てください。 Chapter 扱うこと 1.導入 事故のリアル/本日の背骨

    2.第1段階 AI Studio から Cloud Run へのワンクリック公開の中身 3.第2段階 AI に権限を渡すということ(Claude Code + Cloud Run MCP) 4.幕間 お財布の危険(冒頭の問いの答え合わせ) 5.第3段階 ガードレールの3層/どこまでやるべきか 6.まとめ 判断の型・持ち帰る問い © MBK Digital co., Ltd. All Rights Reserved. 4
  4. 前提確認 バイブコーディングとは何か コードを1行ずつ書くのではなく、AI と会話しながらアプリを生成・改良・デバッグしていく進め方 2025年初頭に Andrej Karpathy 氏が提唱。実装は AI が担い、人間は「何を作りたいか」に時間を使う。

    この定義に入っていないもの 「レビューする人間」と「公開してよいかの判断」 生成が速くなったぶん、レビューすべき量も増えている。人間が1日で書く量は1日でレビューできるが、 AI が1時間で書く量は1時間ではレビューできない。今日の30分は、この抜けている部分の話です。 © MBK Digital co., Ltd. All Rights Reserved. 7
  5. 本日のキーメッセージ ツール機能の進化ではなく、「権限の渡し方」の3段階 持ち帰って欲しいこと 今日出てくるツール名は、1年後には半分変わっています。 覚えて帰ってほしいのは、ツールではなく「いま自分は誰に何を預けているか」という問いです。 第1段階 第2段階 第3段階 Google に全部預ける

    自分が AI に預ける 枠を作ってから預ける 事故の範囲がGoogleの決 めた枠に収まる 自由を得た反面、 事故の責任も自分に来る。 自由を保ったまま、 被害の上限を先に決める。 © MBK Digital co., Ltd. All Rights Reserved. 12
  6. Chapter 2 第1段階 Googleに全部預ける Google AI Studio / Cloud Run

    ©MBK © MBKDigital Digital co.,co., LTD.Ltd. All Rights All Rights Reserved. Reserved. 14
  7. Google AI Studioでのアプリケーション開発事例 無料で公開できる仕組み:Google Cloud Starter Tier 項目 内容 使えるもの

    Cloud Run / Firebase Authentication / Firestore / Cloud SQL for PostgreSQL 上限 アプリは2つまで。リージョンは1つに固定 使えないもの BigQuery、Pub/Sub など。IAM ロールもリージョンも変更できない 課金 クレジットカード・課金アカウントは不要 規約 通常の Google Cloud 利用規約ではなく、Starter Tier 独自の追加規約が適用される 卒業 課金アカウントを付けて標準プロジェクトへ昇格可能。作り直し不要で URL も維持される © MBK Digital co., Ltd. All Rights Reserved. 16
  8. Google AI Studioでのアプリケーション開発事例 ブラウザだけで、プロンプトから公開URLまで インストール作業はゼロ。クレジットカードも不要。 何ができて、何が問題なのかを実際のdemo画像を元に解説します STEP 1 STEP 2

    STEP 3 プロンプトを書く プレビューで直す Publish を押す 「投稿できる掲示板を作って」 程度の一文でアプリが生成される 会話で追加指示。 コードを開く必要はない 数分でHTTPS URL が発行される © MBK Digital co., Ltd. All Rights Reserved. 17
  9. Google AI Studioでのアプリケーション開発事例 公式ドキュメント上の制約 Starter Tier は「個人の Google アカウント」向け ・Workspace組織アカウントは組織のポリシーに従う

    あとで自分で試すときは ここで学ぶべきこと 個人の Gmail アカウントに切り替えてから。 ブラウザのプロファイルを分けると事故が減ります。 「無料」には必ず条件がある。 利用規約を読む習慣は、技術力より先に効いてきます。 © MBK Digital co., Ltd. All Rights Reserved. 18
  10. Google AI Studioで作ったアプリの裏側の分解 Publish ボタンの裏で、実際に起きていたこと 「全世界に公開された」 ここだけは、押した本人が意識していないことが多い。 画面から見えたこと 実際に起きたこと ボタンを押した

    ソースがコンテナイメージにビルドされた 数分待った Cloud Run にデプロイされ、新しいリビジョンが作られた URL が出た HTTPS エンドポイントが払い出され、全世界に公開された ログイン画面が付いていた Firebase Authentication が構成された データが保存された Cloud SQL が自動でプロビジョニングされた © MBK Digital co., Ltd. All Rights Reserved. 26
  11. Google AI Studioで作ったアプリの土台の理解 Cloud Runは「アクセスに応じて0から自動スケールする」仕組み よくある誤解:「最小インスタンス数を0にすれば安全」 最小インスタンス数0は Cloud Run のデフォルトです。事故の原因になるのは最小側ではなく、

    上限(最大インスタンス数)を決めていないこと。最大インスタンス数のデフォルトは100です。 100インスタンスが立ち上がればそれなりの請求額になります。この話は幕間でもう一度出てきます。 誰も来なければ 来た分だけ動く だから リクエストがない時間は インスタンスが0になり、実質かからない アクセスに応じて 自動的にスケールする。 「無料」なのではなく 「呼ばれた回数だけ払う」。 ※Cloud SQLがたった場合は0にならない 設定しなくても、勝手に 上限を決めるのは自分 © MBK Digital co., Ltd. All Rights Reserved. 27
  12. 起きやすい事故 自分の財布より先に、他人のサーバーが焼ける ここまでの話と、作るものの違い ここまでは「自分が払う」話でした。 でも実際にみなさんが作るのは、外のサイトから情報を集めてくるようなアプリです。 取りに行く先にも規約がある 研究費の公募サイトは、多くが公的機関のサイトです。 規約と robots.txt を先に確認しましょう

    動かしっぱなしが効く方向に効く Cloud Run で定期実行にした瞬間、深夜も休日も叩き 続けます。止め方を決めてから動かしましょう。 AI は「何回叩いていいか」を知りません。相手のサーバーが落ちても、 AI には見えません。 © MBK Digital co., Ltd. All Rights Reserved. 28
  13. Chapter 3 第2段階 自分がAIに預ける Claude Code / Cloud Run MCP

    サーバー ©MBK © MBKDigital Digital co.,co., LTD.Ltd. All Rights All Rights Reserved. Reserved. 29
  14. アプリの土台はできたが・・・ 第1段階(Starter Tierを使う場合)のままでは、3つの壁に当たる 一定の壁を越えると自身で制約と向き合う必要が出てきます 自由になるということは、設定を間違える自由も、権限を渡しすぎる自由も同時に手に入るということ。 アプリの公開数の制限 Google AI Studioで同時に公開できるア プリ数は無料枠では2つまで3つ目を作りた

    チーム開発の流れに載らない 生成できる形しか作れない チームのレビュープロセスに載らない /PRベースの共同開発ができない。 既存のリポジトリ、研究室のコード、 特定のライブラリ構成には持ち込めない。 くなった時点で拡張が必要になります。 © MBK Digital co., Ltd. All Rights Reserved. 30
  15. 第2段階とは ブラウザのAIから、自分のパソコンで動くAIへ 1段階は、ブラウザの中で Gemini と会話し、Google が⽤意した枠の中で Publish を押しました。 第2段階は、⾃分のパソコンで動く AI

    に、⾃分の Google Cloud の権限を渡して、直接デプロイさせます。 権限を渡す ⾃分 MCP Claude Code Cloud Run ツール名は変わります。「⾃分の権限を AI に渡す」という構造を⾒てください。 © MBK Digital co., Ltd. All Rights Reserved. 31
  16. やっていること ターミナルの AI に、Cloud Run を触らせる # 1. 自分の身分を Google

    Cloud に通す $ gcloud auth login # 2. Claude Code(MCP 経由)が使う認証情報を用意する $ gcloud auth application-default login # 3. Claude Code に Cloud Run MCP サーバーを登録する $ claude mcp add --scope user cloud-run -- npx -y @google-cloud/cloud-run-mcp あとは「このフォルダのアプリを Cloud Run にデプロイして」と日本語で頼むだけ 重要な変化 gcloud auth application-default login = ローカルのCloud Run MCPサーバーが、自分のADCを使っ てGoogle Cloud APIを呼べる状態にした © MBK Digital co., Ltd. All Rights Reserved. 32
  17. MCPとは AI と外部のツールをつなぐ、共通の差込口 便利さと危険さは、同じ一つの性質から来ている 「自分で実行できる」これが第2段階の価値であり、第2段階のリスクそのもの。 分けて考えることはできません。だから、次に必要になるのが枠(ガードレール)です。 これまで MCP をつなぐと レシピを書く人

    厨房に入って火を使う人 コードや手順を出力してくれる。 実行するのは人間。間違いは人間が気づける。 自分でコマンドを組み立てて実行する。 速いが、気づいたときには終わっている。 © MBK Digital co., Ltd. All Rights Reserved. 33
  18. MCPのリスク 頻出事故の3類型 守り方がまったく違うので、混ぜて考えると必ず穴が空きます。 操作の問題 使いすぎの問題 1.暴走:データが消える 2.意図しない情報漏洩 3.コストが跳ね上がる AI が破壊的な操作を実行してしまう

    秘密がコードに混ざって外に出る 設定ミスやバグで請求が跳ねる 例:rm -rf、terraform destroy を 例:.env や API キーの誤コミット、 例:常時起動設定、上限未設定、 誤って実行し、本番のDBやインフラを削除 プロンプトインジェクション、野良スキル導入 無限ループ、漏れた鍵の悪用 © MBK Digital co., Ltd. All Rights Reserved. 34
  19. 答え合わせ 予算アラートは、長いあいだ「メールを送るだけ」でした 予算を超えても、誰も止めなかった。寝ているあいだに、請求だけが伸びていく。 2026年4月 2026年5月 $7 の予算設定に $18,000 の請求 リソース削除後も請求が伸び続けた

    公開プロジェクトに残った API キーを悪用され、6万件超のリク API キー漏洩後、対象を消したあとも課金が止まらなかったとい エストが発生 う報告 参考リンク:2026年5月・ユーザー報告 https://www.reddit.com/r/googlecloud/comments/1tr4vp8/google_cloud_billed_me_19000_usd_r105000_brl/ © MBK Digital co., Ltd. All Rights Reserved. 36
  20. 2026年に変わったこと スペンドキャップ予算(2026年7月27日・Preview) 比較項目 予算アラート(従来) スペンドキャップ(新) 超えたとき メールが飛ぶだけ 対象サービスへの新規リクエストを実際に止める 復旧 —

    手動で解除するまで、止まったまま 対象範囲 プロジェクト単位で通知は出せるが、止めることはできない 1プロジェクト × 1サービス単位(Preview時点) Gemini API、Agent Platform、Cloud Run、Cloud Run functions 判定 確定コスト 推定・グロスコストで判定するため、確定より発動が速い 「止まらない」が、ようやく「止まる」に変わった。ただし、これで安心してよいわけではありません。 参考リンク:Manage spend cap budgets https://docs.cloud.google.com/billing/docs/how-to/budgets-spend-caps © MBK Digital co., Ltd. All Rights Reserved. 37
  21. 止まって困る本番がない間に心がけたいところ 自分でアプリを公開するとき、まずやる3つ PRACTICE 1 PRACTICE 2 最大インスタンス数を必ず指定する スペンドキャップ予算を設定する 鍵をリポジトリに置かない 個人のプロジェクトにこそ効く。

    止まって困る本番がないうちは、迷わず入 れる 漏れた鍵は、あなたが寝ているあいだも 課金され続ける。Secret Manager へ --max-instances を決めていないと、 デフォルトの100までスケールする。 バグでも攻撃でも、そこまでは自動で払うことに なる --max-instances=3 Billing → 予算 → Spend Cap PRACTICE 3 .env は commit しない この3つは、第2段階に足を踏み入れた日から必要になります。第3段階を待つ必要はありません。 © MBK Digital co., Ltd. All Rights Reserved. 39
  22. Chapter 5 第3段階 枠を作ってから預ける ガードレールという考え方 / VibeBox / Cloud Run

    sandboxes ©MBK © MBKDigital Digital co.,co., LTD.Ltd. All Rights All Rights Reserved. Reserved. 40
  23. MCPのリスク 頻出事故の3類型(再掲) 守り方がまったく違うので、混ぜて考えると必ず穴が空きます。 操作の問題 使いすぎの問題 1.暴走:データが消える 2.意図しない情報漏洩 3.コストが跳ね上がる AI が破壊的な操作を実行してしまう

    秘密がコードに混ざって外に出る 設定ミスやバグで請求が跳ねる 例:rm -rf、terraform destroy を 例:.env や API キーの誤コミット、 例:常時起動設定、上限未設定、 誤って実行し、本番のDBやインフラを削除 プロンプトインジェクション、野良スキル導入 無限ループ、漏れた鍵の悪用 © MBK Digital co., Ltd. All Rights Reserved. 42
  24. 本日の核心 ガードレールは3層ある。製品名ではなく、この3つで考える 層 守るもの 具体的な手段 対応する事故 ① 開発時 AI の暴走/秘密の持ち出し

    (消える・漏れる) サンドボックス実行、deny ルール、通信制限、 コミット前の機密検査(gitleaks 等) 事故1:暴走データが消える 事故2:意図しない情報漏洩 ② 公開時 不正アクセス (入られる) IAP による認証、Cloud Armor による WAF・レート制限、 Secret Manager、最小権限のサービスアカウント 事故2:意図しない情報漏洩 事故3:コストが跳ね上がる ③ 課金 請求スパイク (増える) スペンドキャップ、Quota 上限、最大インスタンス数、 異常検知アラート 事故3:コストが跳ね上がる 危険な操作をできなくすることと、使いすぎを止めることは、別のガードレールです。 どんなツールを選んでも、問いは同じです。大事なのは「この3つを、誰が担っているか?」 © MBK Digital co., Ltd. All Rights Reserved. 43
  25. 勘所は初見で抑えるのは難しいのでサービスを紹介します Cloud Run sandboxes:Google 純正で「①開発時」を担う AI が書いたコード=信頼できないコードを、隔離した環境で実行する機能(2026年7月時点 Preview) 非 root・プロセス分離

    環境変数を継承しない 親プロセスやメタデータサーバーにアクセスできない ホスト側の API キーがサンドボックスに渡らない 外部通信をデフォルト遮断 ホスト側のファイルシステムは読み取り専用 勝手に外へデータを送ることができない ホストのファイルを書き換えられない(サンドボックス内の作業領域は別) 「AI が書いたコードが鍵を持ち出す」を、アプリの実行基盤の側で止める 参考リンク:Cloud Run sandboxes https://cloud.google.com/blog/topics/developers-practitioners/google-cloud-run-sandboxes-are-in-public-preview?hl=en © MBK Digital co., Ltd. All Rights Reserved. 44
  26. その他サービス VibeBox:非エンジニアでも安全に公開するための仕組み 誤解しやすい点:VibeBox が守っているのは、主に「お財布」ではなく「操作」 危険な操作をできなくすることと、使いすぎを止めることは、別のガードレールです。 管理者(エンジニア推奨) バイブコーダー(非エンジニア可) 先に、枠を作る 枠の中で、会話で作る Terraform

    で Cloud Load Balancing、Cloud Armor(WAF)、 IAP、VPC、Secret Manager、Cloud SQL を セキュリティ設定済みの状態で構築し、鍵を払い出す 用意された環境に入り、AI と会話しながら開発・デプロイ・運用。 クラウドや DB への操作は MCP 経由に限定され、 危険なインフラ変更は自動でブロックされる 参考リンク:VibeBox(株式会社Clickan が提供) https://clickan.click/lp/vibe-box © MBK Digital co., Ltd. All Rights Reserved. 45
  27. やり過ぎには注意。用途に応じて適切な設定を考える 第3段階が正解ではない。用途で決める 個人アプリに Cloud Armor を積むのは、庭の防犯のために民間軍事会社を雇うようなものです。 用途 Must(必須) Better(できれば) Overkill(過剰)

    授業課題・ ポートフォリオ 最大インスタンス数の指定、 鍵をコミットしない スペンドキャップ、 Firebase Auth Cloud Armor + IAP + Terraform 研究室内ツール + IAP で学内限定公開 + Secret Manager、 監査ログ + WAF ルールの 個別調整 一般公開サービス + WAF、レート制限、 最小権限のサービスアカウント + IaC 化、 CI での機密検査 — © MBK Digital co., Ltd. All Rights Reserved. 46
  28. まとめ 公開ボタンを押す前に、この順で自問する 古典的な課題ではあるものの、AI活用が進むにつれて形を変えて顕在化 1 入口 誰でもアクセスできる状態でいいか? 2 秘密 鍵やトークンは、コードの外にあるか? 3

    権限 アプリのサービスアカウントは、必要最小限か? 4 入力 外から来た文字列を、そのまま AI や DB に渡していないか? 5 課金 想定の100倍(いきなり1万リクエスト)のアクセスが来たとき、止まるか、払い続けるか? 6 データ 要配慮個人情報にあたるか? 誰が見られる状態か? 後から消せるか? © MBK Digital co., Ltd. All Rights Reserved. 48
  29. まとめ 最後に:今日出てきたツールは、たぶん変わります 実例 Firebase Studio は 2026年3月にサンセットが発表され、2027年3月に終了予定 https://firebase.google.com/docs/studio/migrating-project?hl=ja つい先日まで「バイブコーディングの本命」と紹介されていたツールです。移行先は Google

    AI Studio / Antigravity。 賞味期限が短いもの 長く効くもの ツール名・画面の操作手順 権限の預け方・ガードレールの3層 1年で半分は変わる。 覚え直せばよい。 製品が変わっても、 問いの形は変わらない。 © MBK Digital co., Ltd. All Rights Reserved. 49