[レポート]Vibe Codingによって生成されたアプリケーションの注意点とその先にある本番環境向けの堅牢なアーキテクチャ構築を考える #AWSreInforce #COM322

はじめに

こんにちは、コンサルティング部の神野です。

re:Inforce 2025のLightning Talkで「COM322: Why vibe coding isn't enough: Building secure AI apps that scale」というセッションに参加してきました。
タイトルを見た時は「Vibe Coding（生成AIを使った勢い重視のコーディング）をもっと効率的に行う方法」を学べるセッションだと思っていました。
Vibe Codingというタイトルがキャッチーで気になっていました。

実際は逆で、「Vibe Codingによって生成されたアプリケーションの注意点とその先にある本番環境向けの堅牢なアーキテクチャ構築」について語るセッションでした。
Vibe Codingを使ったその先について言及しているセッションなので気になりますね。

セッション概要

セッションタイトル: COM322: Why vibe coding isn't enough: Building secure AI apps that scale
スピーカー: Brian Huff氏（AWS Dev Tools Hero、Tech Stack Playbook CEO）
セッションタイプ: Lightning Talk
レベル: 300 - Advanced

公式概要

Vibe coding with GenAI is almost too easy... until your app goes live. Then come unauthenticated access alerts, surprise bills, DDoS attacks, Denial of Wallet events—or worse, a system take down. I've built AI-powered systems for millions of users, and I've seen how fast becomes fragile without security by design. In this talk, I'll share what GenAI skips - and how to harden your stack by shifting security left with protective app layers, authentication patterns, Infrastructure as Code, and automated CI/CD deployments to go from vibes to resilient architecture.

スピーカーのBrian Huff氏は、パンデミック中に独学でエンジニアになったという経歴を持つAWS Dev Tools Heroです。
自己学習でここまで来た方だからこそ、多くの開発者が陥りがちな罠を理解し、実践的なソリューションを提供できているのかなと思いました。

セッション内容

Vibe Codingの魅力的なデモ - AIで瞬時にアプリが完成

セッションは衝撃的なデモから始まりました。Brian氏がAIに次々とプロンプトを投げかけていきます。

「PDFをアップロードして対話できるアプリを作りたい」
「最近アップロードしたドキュメントのリストを表示して」
「チャット履歴も保存できるようにして」
「認証機能を追加して」
「アナリティクスダッシュボードも作って、ビジュアルにして」
「かっこいいランディングページも追加して」

わずか数分で、見た目も機能も充実したアプリケーションが完成しました。グラフィックも美しく、まさに「これなら明日にでもリリースできそう！」と思わせる出来栄えです。

転換点 - 「これで本番環境に出せますか？」

ここでBrian氏が投げかけた質問が、会場の空気を一変させました。

「Not quite. There's going to be a lot of problems with this app that you never know about.」

そして、画面に表示されたのは恐ろしいチェックリストでした。

• ゼロトラストアーキテクチャ？
• セキュアでない依存関係？
• DDoS攻撃やボット対策？
• レート制限？
• スケーラビリティ設計？
• 認証・認可？
• マルウェアアップロード対策？

この瞬間、私も含めて多くの参加者が「確かに...」と頷いていました。
Vibe Codingで作ったアプリケーションには、表面上は見えない問題が山積みでした。

Shift Development Leftの概念 - プロンプトから始まっても、そこで終わらせない

Brian氏は「Shift Security Left」から発展させた「Shift Development Left」という概念を提唱しました。

従来のVibe Codingのフローは単純です。

Prompt → Deploy

ただ、本来あるべきフローは下記であるとおっしゃていました。

Prompt → Scan → Build → Automate → Review → Test → Deploy

「We're in the vibe coding era, so we have to acknowledge that. Things might start off as a prompt, but it doesn't have to end at the prompt.」

生成AIの時代を否定するのではなく、それを出発点として、その先にある堅牢なプロセスにつなげていくという考え方です。

本番環境向けアーキテクチャ構築 - AWS CDKとEKSを使った堅牢な実装

ここからは具体的な実装の話に入りました。Brian氏が提示したアーキテクチャは以下のようなAWSサービスを組み合わせたものでした。

• 認証: Amazon Cognito
• API: API Gateway + Lambda
• ストリーミング: API Gateway WebSocket
• ファイルストレージ: Amazon S3
• LLM: Amazon Bedrock
• コンテナ化: Amazon EKS
• CDN: CloudFront
• データベース: DynamoDB
• ベクトルDB: Amazon OpenSearch Service

AWS CDKを使った Infrastructure as Code のアプローチです。

このようにコードで定義することで、「Max Availability Zones を2に設定するだけで、マルチAZ構成が自動的に構築される」という説明をおっしゃっていました。

私はEKSをあまり触ったことがないのでそんなに簡単なら・・・？と試してみたくなりました。

具体的なセキュリティ対策 - Amazon Q、GuardDuty、WAFなどの活用

セキュリティ対策として、以下のような具体的な実装例が紹介されました。
いくつか特徴的だった案を紹介します。

フロントエンドの脆弱性対策

Vibe Codingで生成されたアプリには、多くの場合、古い依存関係や脆弱性が含まれています。Brian氏のデモでは、npm auditを実行すると6つの脆弱性が発見されました。

解決策として、Amazon Q Developer を使用しています。

「これらの6つの脆弱性を修正してください」

Amazon Qが自動的に依存関係を更新し、脆弱性をゼロにしてくれました。

煩雑な依存関係をAIを使って解消できるのは魅力的だなと感じました。
ただ、AIだけでうまくいかないケースも往々にしてあるんだろうなと想像してしまい、
AIによって何が行われたかはしっかりと把握しておく必要もあるかと思います。

マルウェア対策

ユーザーがアップロードするファイルの安全性を確保するため、以下のフローを実装していました。

1. ファイルは一時的なアップロードバケットに保存
2. Amazon GuardDuty Malware Protection for S3 でスキャン
3. 安全と判断されたファイルのみ本番バケットにコピー
4. 危険なファイルは隔離・削除し、アラートを発行

Amazon GuardDuty Malware Protection for S3 を組み込んでいるのは実践的で参考になりますね。

Denial of Wallet 攻撃対策

「Denial of Wallet」という新しい攻撃手法についても言及されました。これは、攻撃者があなたのAIアプリを無制限に使用し、莫大なコストを発生させる攻撃です。

対策として下記を意識することが大事です。

• トークン数の追跡と制限
• APIレート制限の実装
• ユーザーごとの利用量モニタリング

むやみやたらに使われてとんでもない額の課金が・・・みたいなケースは生成AIを活用したアプリケーションではありそうですね。トラッキングと制限の意識は実装する際は必ず意識したいですね。

Amazon QによるPRプロセスの自動化

セキュリティを自動化する仕組みとして、Amazon Q DeveloperをPull Requestプロセスに組み込む方法も紹介されました。

実装の流れは以下の通りです。

1. GitHubにコードをプッシュ
2. WebhookでAmazon Qが自動的に起動
3. AI生成のコードレビューが実行される
4. セキュリティの問題や改善点を自動検出

実際のPRでは、このようなAI生成のコードレビューコメントが自動的に追加されます。特定のチェックで問題が見つかった場合、Amazon Qが自動的に修正案を提示したり、アラートを発行したりすることも可能です。

これにより、Vibe Codingで生成されたコードでも、PRの段階でセキュリティの問題を自動的にキャッチできるようになります。人間のレビューと組み合わせることで、より堅牢なコードベースを維持できるスキームですね。

人間だけのチェックだと限界もあるので、事前チェッカーとしてAIを機能させるのはいいですね。

プロダクション化プレイブック - 10のチェックリスト

最後に、Brian氏は「Productionizing Playbook」として10のステップを提示しました。

1. Secure Dependencies - 依存関係のセキュリティ確保
2. Infrastructure as Code - CDKによるインフラ定義
3. Container Orchestration - EKSによるコンテナ管理
4. Load Balancing - 負荷分散の実装
5. CDN Integration - CloudFrontの活用
6. Authentication & Authorization - 認証・認可の実装
7. Monitoring & Logging - CloudWatch、CloudTrailの活用
8. Malware Protection - ファイルスキャンの実装
9. Rate Limiting - API利用制限
10. Automated Security Reviews - Amazon Qによる自動レビュー

このチェックリストは実際にアプリケーションを本番環境にデプロイする際に参考になりそうですね。
スピーカーはこう対応したとおっしゃっていましたが、必ずしもこれが正解と言ったわけでもないと思い、ワークロードに応じて参考にしたいですね。

まとめ

このセッションを通じて、「Vibe Codingは出発点であって終着点ではない」ということを強く認識しました。
生成AIの力を借りて素早くプロトタイプを作ることは素晴らしいことですが、
それを本番環境で安全に運用するためには、従来通りのエンジニアリングのベストプラクティスが不可欠です。

特に印象的だったのは、Brian氏が最後に言った「Are you prepared for a million users?」という問いかけです。

私たちは常に、作ったものが大きなインパクトを生む可能性を考えて設計すべきだという姿勢に、エンジニアとしての責任感を感じました。
サクッと開発やPoCで使うならいいもののやはり実際の本番環境で耐えうるものなのか？？は胸に留めておきたいです。

実務では、生成AIを使った迅速な開発と、セキュアで堅牢なアーキテクチャの構築をうまくバランスさせることが重要になってくるでしょう。
このセッションで学んだ「Shift Development Left」の考え方を、今後のプロジェクトで実践していきたいと思います。

セッションレポートは以上となります。
最後までご覧いただきありがとうございましたー！！