Vibe Coding で作ったプロダクトをどう安全に動かすか / How to Safely Run Products Built with Vibe Coding

ServerlessDays Tokyo 2026 での発表資料です

Transcript

1. ServerlessDays Tokyo 2026 / 2026年09月19日 Vibe Coding で作ったプロダクトを どう安全に動かすか 前田 章
2. 自己紹介 氏名 前田 章 所属 Cloud Native Inc. 経歴 国内、海外 Web 系企業でTech Lead, Engineering Manager, SRE Manager を 歴任。現職では セキュリティ周辺 を担当 SRE と認証が専門になります GitHub glidenote 個人活動 Vim のプラグイン memolist.vim、 M5Stack(マイコン) で動くツールの開発 共著 サーバ／インフラエンジニア 養成読本 DevOps編 2
3. この資料について 2026年9月時点の内容です この資料で対処するのは、セキュリティの問題です。実装やパフォーマンスの問題は 範囲に含みません 資料内の「ノンエンジニア」という表現は「専業エンジニア」と区別するためで、 優劣を付ける意図などはありません 特定のサービスを例にしますが、他のサービスにも置き換えられる 考え方にしています 3
4. はじめに 2026年8月の話 4
5. アイドルが Vibe Coding で配信システムを作った はじめに 2026年8月の話 元 Juice=Juice の宮本佳林さん 自身の10時間の生配信を支えるプロダクトを開発 プログラミング経験はゼロ。コードは一行も書かず、Claude Code で作った ブログ、技術イベントの動画を見るとAIの理解度が高く、エンジニアも感心する内容 アイドルがプロダクト開発をする時代に 5
6. 第1章 誰でも、プロダクト開発に 参加できるようになった 6
7. 第1章 誰でも、プロダクト開発に参加できるようになった Vibe Coding とは: 中身を理解しなくても、欲しいものが作れる 定義 コードの存在そのものを忘れる アンドレイ・カーパシー （OpenAI 共同創業者・Vibe Coding の命名者。2025年2月） 意図だけを伝え、コードはAIに書かせる開発スタイル 人間の役割は「書く人」から「指示する人」へ 7
8. 第1章 誰でも、プロダクト開発に参加できるようになった AIに言葉で伝えれば、動くものが出てくる 実態 品質に差はあれど、形にはなる 自分の業務で使うものを、自分で作れる 作るのも直すのも、とにかく速い 8
9. 第1章 誰でも、プロダクト開発に参加できるようになった US では、AIコーディングのブームは去った 実態 WordやExcelと同じように当然使うものになった 牛尾 剛（Microsoft Azure Functions チーム。@IT、2026年7月） 廃れたわけではなく、定着して当然になった コーディングエージェントは、魔法ではなく文房具と同じ扱い 9
10. 第1章 誰でも、プロダクト開発に参加できるようになった 一過性のブームではなく、 当たり前になっている 10
11. 第1章 誰でも、プロダクト開発に参加できるようになった だから、使わない、禁止は選択肢にならない 主張 禁止する 当たり前になるものは、止められない うまく使う 課題があるなら、解決する 利用できる状態を目指す 競合が使っている状況で、使わないことがビジネスリスクとなる 11
12. 第1章 誰でも、プロダクト開発に参加できるようになった 当たり前の道具になると、作る側に入る人が増える 実態 1年で3600万人超が GitHub に加わった。毎秒1人 Claude Code で、法務やマーケの人も道具を作る コードを書けない人が、確定申告やトマトの見守りに使う 開発への入口が、Vibe Coding になった 12
13. 第1章 誰でも、プロダクト開発に参加できるようになった その一方で使える状態にしても、作る人は希少 実態 私の会社の話 全社員に Claude を配り、勉強会も実施し、誰でも使える状態にした ただし、自分で作って業務に役立てるのは、ノンエンジニアの2割ほど 作りたい人、完成までやり切る人は、そもそも少ない 業務のために作ってくれる人は、ありがたい存在 13
14. 第1章 誰でも、プロダクト開発に参加できるようになった 新規参入者が増えるのは、業界として良いこと 主張 ノンエンジニアが開発すると、エンジニアから様々な理由で反発が起こりがち しかしドメイン知識がある人が作ると、有用なものになるのは事実 叩いて終わりではなく、良いものならば、活用する 最初は誰でも初心者。専業エンジニアはどう支えるか 14
15. 第2章 3つの実例から見えた、品質の差 15
16. 品質は、誰が使うかで変わるように見える 実態 ノンエンジニアが使う 動くが、問題を抱えていることが多い 第2章 3つの実例から見えた、品質の差 専業エンジニアが使う ちゃんとしたものが出来上がる Vibe Coding は道具。使う人自身の拡張でしかない 16
17. 第2章 3つの実例から見えた、品質の差 事例 1 シャッフルランチ: 動いて、中身も問題なし 専業エンジニアが作った 社内の交流のため、毎週社員をシャッフルしてマッチング 開発の進め方は普段と同じで、実装だけAIを利用 数日で完成し、そのまま運用に入って1年以上、安定稼働中 17
18. 事例 1 判断を人間が行い、実装はAIが行う 分析 第2章 3つの実例から見えた、品質の差 技術選定・設計・データ構造まで、エンジニアで決めて指示した 課題は分解し、大きいまま扱わず、細かく分解されたタスクにAIを活用 普段は PdM・FE・BE・QA・SRE で分担する工程を、1人で担った 18
19. 第2章 3つの実例から見えた、品質の差 事例 2 勤怠管理: 動くが、中身は問題だらけ ノンエンジニアが作った Slack 上で出勤・退勤・有給申請など各種申請ができる 作ったのは、業務を知るノンエンジニア 現在は全社で使われ、使い勝手も評判も上々 19
20. 事例 2 一見、うまく動いているように見えるが 第2章 3つの実例から見えた、品質の差 動作の不具合調査で実装をみたら驚くべき事実が判明 DB は Google スプレッドシート Git/GitHub で管理されず、手元からデプロイ。複数人で開発できない AWS Lambda で動いていて、lambda_function.py が3000行 幸い、セキュリティ面での問題はなかった 「意図した通り動く」と「問題がない」は別物 20
21. 第2章 3つの実例から見えた、品質の差 事例 2 要望だけAIに伝え、動けば受け入れていた 分析 全てをAIにおまかせ 課題を分解せず、大きいままで扱ってしまった 意図した通りに動けば、そのまま受け入れた 実装だけでなく、判断もAIに委譲していた 21
22. 第2章 3つの実例から見えた、品質の差 事例 3 なぜ、あのアイドルは作れたのか ノンエンジニアが作った 宮本佳林さんは同じノンエンジニアでも何が違ったのか 大切なことは「何を作りたいか」「どう動いてほしいか」を 具体的に言葉に できること 宮本佳林（元 Juice=Juice。オフィシャルブログ、2026年8月1日） 企画を考え、機能を洗い出し、順番を決めて実装 シャッフルランチを作ったエンジニアと同じAIの使い方をしていた 22
23. 第2章 3つの実例から見えた、品質の差 事例 3 AIに渡したのは実装で、判断は人間が行った 分析 何を作るか、どう動くか、課題を分解して取り組んでいた コードは読んでいなくても、判断は自分で行った 23
24. 第2章 3つの実例から見えた、品質の差 同じノンエンジニアでも、工程で結果が分かれた 分析 自作 勤怠管理 欲しい結果を伝える → 動いた → そのまま出す アイドル 何を作るか言葉にする → 機能と順番を 決める → 作らせる 成否の分かれ目は判断を自分で持ったか 24
25. 人間が判断する上で重要なポイント 主張 第2章 3つの実例から見えた、品質の差 イーロン・マスクの「開発5つのステップ」 1 2 3 4 5 まず前提を疑え 次に不要なステップを削除しろ 単純化して最適化せよ 上記 3ステップを繰り返し素早く回す 最後に自動化 この考え方は Vibe Coding を利用する際にも非常に重要 25
26. 判断を自分でして、AIを使いこなす 主張 第2章 3つの実例から見えた、品質の差 冒頭に出た、私の趣味開発である M5Stack(マイコン) の話 ハードもファームも本業ではない マイコン開発では、私もノンエンジニア側 何を作るか、どう動くかは自分で決め、実装はAIに任せている 判断を自分で持てば、専門外でも作れる 26
27. 第2章 3つの実例から見えた、品質の差 当たり前になると、問題を抱えたプロダクトが増える Vibe Coding を使った開発は、今後増える一方 自作 勤怠管理は一度きりの失敗談ではなく、次に来るものの見本 セキュリティの問題を抱えたプロダクトも、いずれ出てくる この資料で対処するのは、セキュリティの問題 27
28. 第2章 3つの実例から見えた、品質の差 問題はあっても、社内に投入すると便利で使われる 主張 業務を知る人にしか出せない価値がある みんなに便利に使われているものを問題があるからと捨てると、可能性が消える 28
29. 第2章 3つの実例から見えた、品質の差 技術力があっても、使われなければ意味がない 主張 技術力の高さと、みんなに使われるかは別の話 プロダクトの価値は、みんなに使われて初めて生まれる 自作 勤怠管理は問題を抱えても、社内で価値を生み出している 使われるものを作れる人に価値がある 29
30. 第2章 3つの実例から見えた、品質の差 問題を抱える有用な プロダクトをどう扱うか 30
31. 第3章 そのまま出すと、何が起きるか 31
32. 動いて見えても、中身は壊れている 認証 シークレット 外向き通信 操作の記録 第3章 そのまま出すと、何が起きるか ログインなしでも、データが読める API キーが、コードや .env に残っている どこへでも、データを送り出せる 誰が何を出したか、後から追えない それでも、画面の上では動く 32
33. 社内で起きた事例: .env が公開 実態 第3章 そのまま出すと、何が起きるか ローカルでの動作確認後に手元から AWS にデプロイ 成果物一式をそのまま公開し、 .env も URL がわかれば読める状態に .env は幸い空ファイルで、社内のクラウドセキュリティサービスが即検知 見つけたのは人ではなく、外側の仕組みだった 33
34. AIは、アクセス制御を憶測で作る 実態 第3章 そのまま出すと、何が起きるか 実装指示が「ログインした人だけ見える」だと「認証済みなら全部OK」 と実装される ユーザーAが、ユーザーBのデータを読み書き可能 曖昧な指示は、そのまま穴になる 34
35. 全部を人のコードレビューで守るのは不可能 主張 第3章 そのまま出すと、何が起きるか AIで生産量が何倍になれば、コードの量も何倍になる 数千行、数万行の Pull Request が送られてくる AIに指示した本人も、他人に説明できない すべてを人が読んで理解するのは難しい 35
36. 問題を抱えている前提で、動かす 主張 第3章 そのまま出すと、何が起きるか 動いていても、問題が無いとは言い切れない 全部を人のレビューで見つけるのは、現実的ではない 問題があっても、軽症で済むようにする 何かあっても、止まる形で出す 36
37. 第3章 そのまま出すと、何が起きるか ガードレールは、プロダクトの外側に置く 37
38. ガードレールとは: プロダクトの外側で、危険を止める仕組み 定義 サーバーレス AWS のセキュリティ CI/CD 第3章 そのまま出すと、何が起きるか 実行権限は基盤、認証は手前の入口が持つ 危ない操作を、アカウントの設定で止める デプロイを、CI の1本に絞る プロダクトの出来や実装に、依存しない 38
39. 第4章 ガードレールを、どう置くか 39
40. 「俺の考えた最強のセキュリティ」 絶対ダメ 打ち手 第4章 ガードレールを、どう置くか セキュリティには定石がある 自作の認証・自前の暗号化はやらない AIは、それらしい独自実装を平気で出してくる 使うのは、枯れた手順とマネージドサービス AIには定石通りに作らせ、人は定石通りかを判定する 40
41. 定石はどこから持ってくるか 打ち手 OWASP Top 10 徳丸本 AWS Well-Architected GitHub Actions 第4章 ガードレールを、どう置くか 何が起きるかの一覧 なぜ危なく、なぜ対策が効くのか セキュリティの柱。クラウド側の定石 公式のセキュリティ強化ガイド 従来の手法を、着実に実行する 41
42. 打ち手は、3つのレイヤーに分かれる 打ち手 第4章 ガードレールを、どう置くか プロダクト 1. 持たない 個人情報・機密情報を扱わない 2. 経路を絞る デプロイ経路を、1本にする 3. 外で強制する インフラの設定で守る 42
43. 打ち手 1 一番の対策は、集めないこと 持たない 第4章 ガードレールを、どう置くか 持っていない情報は、漏れない。住所や生年月日は、本当に要るか パスワードは自前の DB に置かず、Cognito など IDaaS に任せる 漏れたら困る情報は扱わない。対策そのものが要らなくなる 扱う情報を決めて、AIに作らせる 43
44. 第4章 ガードレールを、どう置くか 打ち手 2 デプロイは、GitHub Actions 経由だけにする 経路を絞る 手元からのデプロイを塞ぎ、いつ・誰が・何を出したかを残す 長期キーは置かず、OIDC で一時的な資格情報を受け取る 人の資格情報からは、デプロイ系 API を組織の SCP で Deny する 規約ではなく、権限で塞ぐ 44
45. 第4章 ガードレールを、どう置くか 打ち手 2 手元からのデプロイを塞ぐと、経路は1つになる 経路を絞る 手元からデプロイ 長期キーで、直接 手元の PC AWS 本番 検査の結果を待たずに出る。いつ・誰が・何を出したかも、残らない GitHub Actions 経由だけ 手元の PC push GitHub 検査 Actions がデプロイ OIDC で受け取る 一時的な資格情報 AWS 本番 手元から直接は、SCP で止まる（人の資格情報からのデプロイを Deny） 45
46. 第4章 ガードレールを、どう置くか 打ち手 2 手元からのデプロイは、検査の結果を待たずに出る 経路を絞る 手元からだと、CodeQL やシークレットスキャンの結果を待たずに出せる GitHub に無いコードは、Dependabot の検査も受けられない GitHub を経由し、Actions の検査を通らないと出せない形にする 検査を通ったものだけが、本番に出る 46
47. 打ち手 3 認証は、プロダクトの外で済ませる 外で強制する プロダクトの中で判定 プロダクトが要求を検証する 抜け道があったらすぐ陥落 第4章 ガードレールを、どう置くか プロダクトの外で判定 プロダクトの手前で要求を検証する 認証されない要求は、届かない 例: Auth0 や Cognito が認証し、API Gateway や ALB が要求を検証する プロダクトの責務は、認可（誰が、何をできるか）だけにする 47
48. 第4章 ガードレールを、どう置くか 打ち手 3 認証を外に出すと、届く要求が変わる 外で強制する プロダクトの中で判定 利用者 すべての要求 プロダクト 認証の判定 認可 処理 未認証の要求も届く。抜け道があれば、そのまま通る DB プロダクトの外で判定 利用者 すべての要求 認証 入口で検証 プロダクト 認証済みだけ 認可 処理 DB 未認証の要求は、ここで止まる 48
49. 第4章 ガードレールを、どう置くか 打ち手 3 認証が外になると、レビューの範囲が狭まる 外で強制する プロダクトの中に、認証を作らせない。届く要求は認証済みだけ 認証が掛かっているかは、コードではなく AWS Config が見る レビューするのは、認可だけになる 49
50. 第4章 ガードレールを、どう置くか 打ち手 3 AWS での構成例: 特別な部品は、1つも無い 外で強制する 認証 API Gateway の JWT オーソライザー シークレット Secrets Manager から実行時に取る 外向き通信 操作の記録 ルートごとに、同じ1つを掛ける コードにも .env にも置かない VPC 内の Lambda。出口は許可制 AWS へは VPC エンドポイント。SaaS へは決めた経路だけ CloudTrail と AWS Config プロダクトごとではなく、アカウントに一度 4つとも、プロダクトの外で止まる 50
51. 第4章 ガードレールを、どう置くか 打ち手 3 SCP は止め、AWS Config は見つける 外で強制する SCP で止める AWS Config で見つける 経路 人の資格情報からのデプロイ操作 放置された長期キー 認証 — 認証の無い API のルート シークレット — ローテーションが無い 外向き通信 NAT の作成 VPC の外の Lambda 操作の記録 CloudTrail・Config の停止 証跡の無いアカウント 51
52. 打ち手 3 重要な記録は Slack に通知し可視化 外で強制する 第4章 ガードレールを、どう置くか 本番デプロイのたびに、いつ・誰が・何を出したか AWS リソースが作られるたびに、誰が何を作ったか 見に行かなくても目に入るので、異変などを検知できる ただ記録するだけでは、誰も見ない 52
53. 第4章 ガードレールを、どう置くか ここまでの打ち手は、従来の開発と何も変わらない 主張 AIが作る問題は、これまでの開発と同じ対策が利用できる 定石も、構成例も、Vibe Coding 以前からある これまでと同じガードレールが利用できる 53
54. 第4章 ガードレールを、どう置くか ガードレール用の テンプレートリポジトリを用意する 54
55. 第4章 ガードレールを、どう置くか テンプレートリポジトリを利用し作っていく 外で強制する 構成例の IaC と Actions のワークフローが、最初から入っている AIは、その中でプロダクトのコードだけを書く ガードレールはAIに覚えさせず、作業する場所に入れておく 誰が作っても、同じ設定が入る 55
56. 外れたガードレールを検知する 外で強制する 第4章 ガードレールを、どう置くか コピーした先で修正され、ガードレールが外れる可能性 修正を止めるのではなく、外れたら気づけるようにする AWS Config のルールで、外れた設定を検出する 設定を監視する仕組みも作る 56
57. 外で止まらないものは、人が見る 主張 扱う情報 何を持ち、何を持たないか 認可 AがBのデータを読めないか AWS の外の設定 依存の選び方 第4章 ガードレールを、どう置くか 持つかどうかは、人が決める コードで人が見るのは、ここだけ SaaS の API キーの権限 SCP も AWS Config も届かない 脆弱性が無くても、保守されているか Dependabot が拾うのは、脆弱性だけ この4つを見るのは、人の役目 57
58. まとめ できることを、地道にやる 58
59. AIエージェントの進化が速く、 セキュリティは後回しになっている 実態 まとめ できることを、地道にやる AIエージェントはためらうことなく活用し、 現時点でできる対策もしっかり 実施すること 牛尾 剛（Microsoft Azure Functions チーム）『部下としてのAI』（文藝春秋、2026年） 新しい機能や効率化が優先され、対策は後回しになりがち 出てくるものの量に、対策の議論が追いついていない 対策が出るのを待たずに、いまある手で守る 59
60. 明日からできること 打ち手 まとめ できることを、地道にやる 1 誰が、何を作り、どこから出しているかを知る どの経路を塞ぐかは、知ってから決める 2 ガードレールを、プロダクトの外側に1つ置く コードを直させるのではなく、外側で止める 3 作ったガードレールを、次に作る人に渡す 覚えさせるのではなく、テンプレートリポジトリで いきなり全部ではなく、一つずつ地道に進める 60
61. 大きく作る前に、小さく早く失敗しておく 主張 まとめ できることを、地道にやる 最初は小さく作る。大きいものをいきなり作らない 課題を分解し、早く失敗する（Fail Fast） 小さいもので実績を積み、徐々に大きくしていく 小さく、早く、失敗して、大きな失敗を防ぐ 61
62. 最初は、誰でも初心者 主張 まとめ できることを、地道にやる AIの無い時代、私も Vim プラグイン memolist.vim を公開した 先人の mattn さん、heavenshell さんは、叩かずに助けてくれた その実績の一本槍で、今も頑張っている 専門領域が変わればノンエンジニア側 62
63. 新規参入者は増え続ける。支える側に回る 主張 まとめ できることを、地道にやる Vibe Coding は、当たり前の道具になりつつある 作る側に入ってくるのは、業務を知るノンエンジニア 作られたものに価値があるなら問題を解消する どう支えるかが、専業エンジニアの役目 63
64. 専業エンジニアの役目 主張 歓迎する 解決する 良くする まとめ できることを、地道にやる 作る人が増えていい 禁止は選択肢にならない 危険は外側で止める ガードレールは外側に 一緒に直して、次に渡す できることを地道に 禁止せずに、安全に動かし、可能性を広げていきましょう 64
65. まとめ できることを、地道にやる ご清聴ありがとうございました 65
66. まとめ できることを、地道にやる 参考URL 定石 事例 OWASP Top 10 2025 https://owasp.org/Top10/2025/ 徳丸 浩『体系的に学ぶ 安全なWebアプリケーションの作り方 第2版』 SBクリエイティブ、2018 AWS Well-Architected フレームワーク セキュリティの柱 https://docs.aws.amazon.com/ja _jp/wellarchitected/latest/security-pillar/welcome.html GitHub Docs Actions のセキュリティ強化ガイド https://docs.github.com/ja/actions/refere nce/security/secure-use ／ テンプレートリポジトリを作成する https://docs.github.com/ja/ repositories/creating-and-managing-repositories/creating-a-template-repository 宮本佳林オフィシャルブログ「かりんの頭の中」（2026年8月1日） https://ameblo.jp/miya motokarin-official/entry-12974432505.html 同（技術編） https://ameblo.jp/miyamotokarin-official/entry-12974440752.html AWS Config のマネージドルール・SCP api-gwv2-authorization-type-configured https://docs.aws.amazon.com/config/latest/d eveloperguide/api-gwv2-authorization-type-configured.html lambda-inside-vpc https://docs.aws.amazon.com/config/latest/developerguide/lambda -inside-vpc.html secretsmanager-rotation-enabled-check https://docs.aws.amazon.com/config/latest/d eveloperguide/secretsmanager-rotation-enabled-check.html cloudtrail-enabled https://docs.aws.amazon.com/config/latest/developerguide/cloudtr ail-enabled.html access-keys-rotated https://docs.aws.amazon.com/config/latest/developerguide/access -keys-rotated.html SCP（AWS Organizations） https://docs.aws.amazon.com/organizations/latest/userguid e/orgs_manage_policies_scps.html 引用 Andrej Karpathy（2025年2月2日） https://x.com/karpathy/status/18861921848081493 83 イーロン・マスクの5ステップ https://x.com/kenn/status/2076088272099635489 牛尾 剛『部下としてのAI 世界一流エンジニアの進化術』 文藝春秋、2026 https://books.bun shun.jp/ud/book/num/9784163921143 牛尾 剛「AIコーディングブーム」が去った US（@IT、2026年7月21日） https://atmarkit.it media.co.jp/ait/articles/2607/21/news012.html GitHub Octoverse 2025（2025年10月28日） https://github.blog/news-insights/octovers e/octoverse-a-new-developer-joins-github-every-second-as-ai-leads-typescript-to-1/ Anthropic「How Anthropic teams use Claude Code」（2025年7月24日） https://claude. com/blog/how-anthropic-teams-use-claude-code Fortune、Claude Code とコードを書かない利用者（2026年1月24日） https://www.fortu ne.com/2026/01/24/anthropic-boris-cherny-claude-code-non-coders-software-engineers Veracode「2025 GenAI Code Security Report」（2025年7月30日） https://www.veracod e.com/blog/genai-code-security-report/ NCSC「The 'vibe coding spectrum' approach」（2026年6月18日） https://www.ncsc.go v.uk/blogs/the-vibe-coding-spectrum-approach-to-ai-assisted-software-development 66