TL;DR
Q: バイブコーディングで本当にアプリをリリースできるのか？
A: できました。ただし「商用・セキュア」という条件では、非エンジニアにはまだ厳しいと感じました。
- AI英語学習アプリをゼロから個人開発し、Web・iOS App Store の両方でリリースできました
- AIは「コードを書くこと」を代替できますが、「何を確認すべきか」の判断は代替できません
- 一番大変だったのはコードではなく、セキュリティ・ドメイン知識・データ設計・デバッグ力でした
AIとバイブコーディングの時代
ChatGPTが登場してから数年、CursorやClaude Codeのようなコーディング特化のAIツールが普及し、「コードが書けなくてもアプリが作れる」という言説が広まってきました。XのタイムラインにはAIだけでSaaSを作ってMRR ○万円達成、というポストが毎週のように流れてきます。
バイブコーディング（vibe coding）という言葉も定着しつつあります。「雰囲気でコードを書く」、つまりAIに指示を出しながらコードの中身をあまり理解せずにアプリを構築するスタイルです。
これはバイブコーディングを否定するものでは決してありません。AIによって開発のハードルが下がり、より多くの人がアイデアを形にできるようになったことは、素晴らしいことだと思っています。
また、決してポジショントークではありません。
今回、個人開発でClaude Codeを使って実際にアプリをリリースしましたが、その際に本当に非エンジニアでもアプリをリリースできるのかと感じました。今の私が思う正直な感想を書きたいと思います。
私について、作ったものについて
私はもともとAWSインフラの構築経験があり、JSでの簡単なコードは書けるレベルのエンジニアでした。TypeScriptやNext.jsといった技術は今回初めて本格的に触りました。
今回はClaude Codeを使い、EngyというAI英語学習Webアプリを0から構築してWebおよびApple App Storeで公開しました。
Engyとは
AIを活用した英語4技能学習プラットフォームで、主な機能は以下のとおりです：
- AI Speaking: Bedrock AgentCore（音声AI）とリアルタイムで英会話練習。会話内容・表現へのフィードバックも自動生成
- AI Writing: 英作文をAmazon Bedrockが添削
- Grammar / Vocabulary: 文法クイズと語彙デッキ
- Listening / Reading: 長文読解・リスニング問題
インフラはAWS完全サーバーレス（Lambda + DynamoDB + Cognito + CloudFront + Bedrock AgentCore）、課金はWeb経由がStripe・iOS経由がApple IAP（RevenueCat）、モバイルはCapacitorを使ってiOSアプリとしてApp Storeに公開しています。
よろしければ、ぜひ一度お試しください。
- Web: engy.academy
- iOS: App Store
正直なところ、非エンジニアには厳しいと思った
はじめに触れておくと、VercelやFirebase、Supabase、Replit Agentのような「アイデアを入力するだけでデプロイまでやってくれる」系のサービスは今回使っていません。それらを使えば話は変わるかもしれません。
ただ、実務レベルのセキュリティを維持しながら、商用サービスとしてリリースするという条件では、今の時点で非エンジニアには難しいと感じました。その理由を具体的に書きます。
1. セキュリティと課金：「わからなくて怖い」
セキュリティ：網羅できているかどうかわからない、という恐怖
私はエンジニアとしての経験があるので、「IAMの最小権限は設定した、JWT検証している、Webhookは署名検証している、WAFを入れた」という状態を見て「最低限は押さえている」という判断ができます。この感覚は経験から来るもので、体系的に説明するのが難しい類のものです。（それでも、攻撃などで落ちたらどうしよう・・・と思っています。）
非エンジニアのバイブコーダーには、この 「ここまでやれば大丈夫」という基準線がありません。
最近は攻撃による個人情報漏洩や、GitHubに誤ってAPIキーをコミットして不正利用されるというニュースが増えています。これらは「知識がなかったから起きた」というよりも「何が問題かを知らなかったから気づけなかった」という構造の事故が多いです。AIがコードを書いてくれても、意図せずセキュリティ上の問題を含んだコードが生成されることがあります。AIは「動くコードを書く」ことは得意ですが、「コードに潜むリスクを網羅的に指摘する」ことは別の話です。
漠然とした不安の中でリリースボタンを押すのは、エンジニアでも怖いです。逆に、構築を進めて知識がついてくると、知れば知るほどリスクが見えてきて、エンジニアと同様に怖くなっていくとも思います。
クラウド課金：使うまでの「漠然とした怖さ」
Engyで使っているAWSのサービスはほぼサーバーレスの従量課金です。Lambda・DynamoDB・API Gatewayは実際にリクエストが来たときだけ課金されます。誰も使わなければほぼゼロ円、スパイクが来ても上限設定で制御できます。この知識があるから安心して使えます。
AWSに馴染みのない人から見ると、クラウドは「つけっぱなしにしたら高い請求が来そう」「どこかに設定ミスがあったら青天井になりそう」という怖さがあります。実際に設定ミスで数百万円の請求が来た事例はネットに転がっています。
何に・どのくらいかかるかの感覚がないまま進むのは難しいです。これもエンジニアとしての知識が前提になっている部分です。
2. 自分の知らないことは、AIエージェントから引き出せない
「いや、セキュリティもコストも、AIが教えてくれるし、そこすら気にしなくていいのでは？」 ということを言われるかもしれません。お金があればそうかもしれません。しかし、バイブコーディングの難しさとして、もう一つ話しておきたいことがあります。
AIに「セキュリティ大丈夫？全部確認して」と投げたとします。AIは何かしら答えを返してくれます。しかしシステムの規模が上がるほど、その回答が本当に網羅的かどうかを判断できるのは、結局指示を出す人間の知識量に依存します。
AIはインプットの質に比例する。これはコーディングエージェントの時代でも変わっていません。
具体例を挙げます。AWSのセキュリティ設定が適切かどうかを体系的にチェックする方法として、AWS Security Hubという仕組みがあります。CISベンチマークやAWSのベストプラクティスに照らして、設定の問題点を自動で洗い出してくれるサービスです。これを知っていれば「Security Hubで確認して」とAIに指示できます。知らなければ、AIからSecurity Hubを引き出すのは難しいです。
コスト面でも同じことが言えます。Bedrockには Prompt Cachingという機能があり、同じプロンプトの先頭部分を繰り返し送る場合にキャッシュを利用してAPIコストを削減できます。これを知っていれば「プロンプトキャッシュを使うように実装して」と指示できますが、存在を知らなければそもそも使おうという発想が生まれません。
同様に：
- ペネトレーションテスト
- SAST
- DAST
これらは「知っていれば使える」ツールや手法ですが、そもそもこれらの言葉を知らなければ、AIに聞くきっかけ自体が生まれません。コーディングエージェントは「作ること」を優先する傾向があります。プロンプトに書かれていないレビューや検証は、後回しになりやすいです。
知識がないと「正しい質問」ができない
これはAIに限った話ではありません。エンジニアに依頼するときも同じで、「セキュリティよろしく」だけでは、何を確認してほしいかが伝わりにくいです。ただ、エンジニアは経験から「認証周りのことを言っているのかな、それとも通信暗号化のことかな」と解釈して確認してくれます。AIはそのコンテキスト補完を、現状まだ人間ほど信頼性高くやってくれません。
バイブコーディングで作れるアプリの品質の上限は、指示を出す人の知識量に比例すると思います。 コードを書く能力は代替してもらえますが、何を作るか・何を確認すべきかの判断は代替してもらえません。
また、すべてをAIに逐一質問しながら進めていれば、コストも無視できません。Claude CodeのMAXプランは月額$200で、売り上げがない状態でその費用だけを投資し続けるのはなかなか大変です。
3. 実際に躓いたポイント・意識すべきポイント
ここからは、アプリをリリースするにあたって私が実際に躓いたことや、バイブコーダーが意識しておくといいと感じたポイントを挙げていきます。
AWSのセキュリティ基本設定
AWSを使い始める前に、まずAWSにおけるセキュリティの基本概念のような記事で押さえておくべき設定を把握しておくことをおすすめします。
全部を最初からやる必要はありませんが、商用サービスとして運用していくなら、できることはやっておいたほうがいいです。ただし、セキュリティ強化とコストはトレードオフになる部分もあるので、優先度を判断しながら進めることになります。
今回私が実施したのは以下のとおりです：
- 最小権限の原則：各LambdaのIAMロールには、その関数が必要とする権限だけを付与。IAM Identity Centerのユーザーにも同様に、操作内容に応じた最低限の権限セットのみを割り当てます
- Rootユーザーの保護：日常操作でのRoot使用を禁止、MFA（多要素認証）を設定
- AWS OrganizationsとIAM Identity Center：検証環境と本番環境をマルチアカウントで分離管理
- SCP（Service Control Policy）：特定リージョン以外へのリソース作成を禁止するなど、組織レベルで操作を制限
- WAFなど各セキュリティサービスの利用：CloudFrontにWAFを適用してアクセス制御
AWSのコスト基本設定
セキュリティと同様に、コスト管理の基本設定も最初に済ませておくべき項目があります。AWSは従量課金なので、設定ミスや予期せぬスパイクが起きたとき、気づくのが遅れると請求額が大きくなります。
今回私が実施したのは以下のとおりです：
- 従量課金サービスの選択：Bedrock・API Gateway・DynamoDB（オンデマンドモード）・Lambdaはリクエストがなければコストほぼゼロ。S3・CloudFrontもストレージ量やデータ転送量に応じた従量課金で、小規模な初期段階ではコストを最小限に抑えられます
- AWS Budgets：月額の予算を設定し、閾値を超えたらメールで通知
- Cost Anomaly Detection：過去の利用パターンと比較して異常なコスト増加を自動検出
- API Gateway スロットリング：レートリミットを設定し、スパイクや不正なリクエストによる過剰な課金を防止
- Lambda の同時実行数制限：予期せぬスパイクによる青天井を防ぐため、関数ごとに上限を設定
- Bedrockプロンプトキャッシュ：同じプロンプトの先頭部分を繰り返し送る場合にキャッシュを利用し、APIコストを削減
BedrockのリージョンとQuota
今回はSpeakingにAmazon Nova Sonic、WritingにNova Proを使っていますが、どちらも東京リージョンではデフォルトのQuotaが非常に小さいです。新規アカウントだと同時接続数がNova Sonicで1、Nova Proで10程度しか割り当てられていないケースがあります。引き上げ申請を出しても、利用実績がないアカウントでは承認されず、実績を積み上げるしかない状況になります。これを知らずにアーキテクチャを組んで後から詰まるのは典型的な落とし穴です。モデル選定とリージョン・Quotaの確認は同時にやるというのは今回の学びでした。
DynamoDBのデータ設計
DynamoDBはRDBと根本的に設計思想が違います。RDBは「とりあえずテーブルを作ってあとでクエリを考える」が通用しますが、DynamoDBはパーティションキーとソートキーを最初に決める必要があり、後から変えるにはテーブルごと作り直しになります。
今回は機能を追加するたびにテーブルが増えていきました。課金のライフサイクル管理（サブスクのステータス・更新日・プラン変更履歴）、AI機能の月次利用回数リセット、Speaking/Writingそれぞれの利用履歴など、後から「このデータが必要」と気づいて追加した箇所が複数あります。アクセスパターンを先に洗い出しておけば、テーブル設計がもっとすっきりしていた部分もあります。
バイブコーディングで「とりあえず動かす」を優先すると、データ設計は後回しになりやすいです。しかしDynamoDBに限らず、データモデルは後から変えるコストが高いです。最初にどんなクエリが必要かを一通り考えてからテーブルを作る、という手順は省略しないほうがいいです。
Cognito × Apple Sign Inの落とし穴
CognitoでApple Sign Inを実装した際に、一度本番も含めてUser Poolを作り直す羽目になりました。
Cognitoのemail属性をmutable: falseで作成したのですが、Apple Sign Inは2回目以降のログイン時にIdPから属性を再送してきます。そのときCognitoが「このemail属性は更新できない」と弾いてしまい、2回目以降のAppleログインが失敗するバグが発生しました。
CognitoのUser PoolはSchemaの設定が作成後に変更できません。 mutable: falseをtrueに変えようとしても、AWS CLIでもCDKでもエラーになります。さらに、Apple Sign Inはユーザー情報を初回認証時にしか送信しないという仕様があり、これも事前に知らないとハマります。2回目以降はIDトークンのクレームしか送ってきません。そのIDトークンにemailクレームを含めるにはApple IdPのスコープにemailを追加する必要があるのですが、CDKのデフォルトはnameのみです。スコープが足りないとIDトークンにemailが含まれず、email: required: trueのUser Poolでは2回目ログインが弾かれます。これも再作成しないと直せない設定でした。
User Poolを作り直すと、AgentCore RuntimeのJWT認証設定、API Gatewayのオーソライザー、iOSアプリのPool ID/Client IDをすべてやり直す必要があり、被害が連鎖しました。DynamoDBと同様、最初の設計判断を間違えると後から直すコストが跳ね上がります。
フレームワークの制約
Next.jsには大きく2つの動かし方があります。静的書き出し（Static Export）はビルド時にHTML/CSS/JSファイルを生成してS3に置くだけで動きます。サーバー不要でコストが低く、CloudFrontで配信できます。一方、サーバーモード（SSR）はリクエストのたびにサーバーでHTMLを生成するため、ユーザーごとにページ内容を変えたり、SEO向けに動的なメタタグを出したりできます。ECサイトやニュースメディアはこちらが向いています。
今回はS3+CloudFrontへの静的配置を選びました。ユーザーごとのデータはログイン後にAPIから取得する構成なので、静的書き出しで十分でした。ただしこれにより、Next.js組み込みのAPI機能（Route Handlers）が使えません。バックエンドはすべてLambdaで別途実装しています。
ただし、この選択を後から変えるにはホスティング構成ごと変える必要があります。将来「ページごとにOGPを動的に生成してSNSでシェアしたい」「検索エンジン向けに動的なコンテンツを返したい」となると、Static ExportからSSRへの移行はそれなりの工数になります。最初にどこまでSEOやサーバー機能を使うかを考えておくと、後で選択肢が広がります。
モバイル対応方針
iOSアプリとして公開するには、Capacitor・React Native・Swift（ネイティブ）のどれかを選ぶことになります。これは後から変えるとほぼ全書き直しになる選択です。
今回は実は、最初からApp Storeへの公開を予定していたわけではありませんでした。Next.jsでWebアプリを作っていた流れで、たまたまCapacitorを使えばそのままiOSアプリとして出せると知り、後から対応した形です。結果的にはうまくいきましたが、もし最初からモバイルファーストで設計していたら別の選択をしていた可能性もあります。
選択基準は「どの程度Webとコードを共有したいか」に尽きます。
| 方式 | Webとのコード共有 | UX品質 | 向いているケース |
|---|---|---|---|
| Capacitor | ◎ Webそのまま流用 | △ | WebアプリをそのままiOS化したい |
| React Native | ○ ロジックは共有可 | ○ | モバイルUXを重視したい |
| Swift（ネイティブ） | × | ◎ | 完全ネイティブ品質が必要 |
最初にモバイル展開を視野に入れているなら、この方針はWebの技術選定と同時に決めておいたほうがいいです。Capacitorでも基本的には差を感じませんでした。
4. コーディングの外の世界：ドメイン知識
コードを書く以外の作業が予想以上に多かったです。特にApp Store・法的要件・ドメイン・課金まわりは早めに動いておくべきでした。
Apple App Store申請
iOSアプリとして公開するには、コードとは別の作業が大量にあります。しかもその多くはAppleエコシステム固有の知識が必要で、かなりハードルが高いです。
XcodeはMacでしか動かないため、ビルド環境としてMacが必要になります。今回はGitHub ActionsのmacOSランナーを使ってビルドを自動化したので、手元にMacがなくても対応できました。ただしその設定自体もそれなりの工数がかかります。実機テストにはiPhoneも必要になります。
他にも：
- 証明書・プロビジョニングプロファイルの管理 — Appleの署名周りは独特で、期限切れや設定ミスでビルドが通らないことがあります
-
App Store Connectへのバイナリ提出 — Xcodeまたは
altool/xcrun経由で提出。手順が複雑です - Apple IAP（アプリ内課金） — iOSで有料機能を提供するには、WebのStripe課金とは別にApple IAP（In-App Purchase）の実装が必要です。RevenueCat等のSDKを活用しても、購入フロー・購入復元・Webhookによる購入状態のDB同期など実装すべき箇所が多く、相応の工数がかかります。また、App Store ConnectへのIAP商品登録・審査申請が別途必要で、プライバシーラベルでのデータ利用目的の申告も求められます
- Appleのレビュー — 独自の審査基準があり、リジェクトされることも珍しくありません。今回も「プライバシーラベルの申告内容が不正確」「アプリ説明文に利用規約へのリンクが不足している」という理由で差し戻されました。差し戻しのたびに再提出・再審査が必要です
- Apple Developer Programへの加入 — 年額$99。申請〜審査〜公開まで数日〜1週間以上かかります
法的ドキュメント
課金機能を持つサービスをリリースするには、コードとは別に以下の文書が必要になります：
- プライバシーポリシー — 個人情報の取り扱い方針。App Store申請の必須要件でもあります
- 利用規約 — サービス利用に関するルール。トラブル時の免責にも関わります
- 特定商取引法に基づく表記 — 日本で有料サービスを提供する場合の法的義務。運営者情報・料金・解約方法などの記載が必要です
これらはAIに叩き台を生成させることはできますが、内容が自分のサービスに合っているか、法的に問題がないかは自分で確認する必要があります。後から「表記が不十分だった」となると信頼に関わります。
ドメイン取得
サービス名が決まったら、ドメインは早めに取っておいたほうがいいです。開発が進んでから「そのドメインはすでに取得済み」となると、サービス名から見直す羽目になります。
使いたいTLDは、すでに埋まっていることも多いです。最近は.aiがAI系サービスで人気ですが、年額数万円になることもあり、初期コストとして見込んでおく必要があります。Engyは.academyを選びましたが、TLDによってブランドの印象も変わります。
また、ドメインを取得してからCognito・CloudFront・メール送信（SES）等にカスタムドメインを設定する作業が発生します。後からドメインを変えるとこれらの設定をすべてやり直すことになるので、早めに決めておくほど楽になります。
課金のライフサイクル
サブスクリプション課金を実装するには、まずSaaSの課金モデルそのものを理解している必要があります。「月次プランに加入して、翌月に自動更新される」というシンプルな流れの裏には、多くの状態遷移が隠れています。
- プランのアップグレード・ダウングレード（即時反映か、次回更新時か）
- 支払い失敗時のリトライと、それでも失敗した場合のアカウント停止
- 解約（即時解約か、期間終了まで継続するかの判断）
- 返金・プロレーション（日割り計算）
これらはWebhookイベントとして通知してくれますが、どのイベントに対してDBのどのフィールドをどう更新するかの設計は自分でやる必要があります。AIに「Stripe webhook対応して」と投げるだけでは、こうした状態遷移を正しく網羅した実装は期待しにくいです。
課金の設計はSaaSビジネスの根幹で、ここを誤ると「解約したのにまだ課金されている」「プラン変更が反映されない」というユーザートラブルに直結します。コードを書く前に、自分のサービスの課金ルールを言語化しておくことが先決です。
5. デバッグ：「なぜ動かないか」を切り分ける能力
AIはコードを生成することは得意ですが、「なぜ動かないか」を特定するのは別の話です。例えば、サーバーレス構成ではリクエストがCloudFront → API Gateway → Lambda → DynamoDBと複数の層を通過するため、同じ「APIが返ってこない」という症状でも原因の場所はさまざまです：
- CORSのOriginヘッダが合っていない（API Gatewayの設定）
- CognitoトークンのExpiryが切れている（認証層）
- Lambda関数のIAM権限が足りない（実行権限）
- DynamoDBのテーブル名が環境（dev/prod）によって違う（設定ミス）
- CloudFrontのキャッシュが古い（CDN層）
「どこまで届いているか」を確認するには、ブラウザのDevToolsでネットワークタブを見たり、AWSコンソールでAPI GatewayやLambdaのメトリクス・ログを確認したりするのが有効です。CORSエラーはLambdaのログには出ないのでブラウザ側でしか見えないものもあれば、Lambdaまで届いていないエラーはAWSコンソール側にしか出ないものもあります。切り分けの手段を複数持っておくことが重要です。
また、必要なログがそもそも有効化されていないというケースも多いです。API GatewayのアクセスログはデフォルトOFFで、有効化しないとリクエスト自体が記録されません。バイブコーディングで機能を積み上げる中でログ設定を後回しにすると、本番で問題が起きたときに手がかりのない状態になります。
6. AIが作ったものを「理解する」責任
バイブコーディングで陥りやすいのが、動いているが自分では説明できないシステムができあがるという状態です。コードの一行一行を理解する必要はありませんが、「何がどう動いているか」のレベルでは把握しておく必要があります。
例えば：
- 認証はどの仕組みで実現しているか、トークンはどこで検証されるか
- ユーザーのリクエストはどの順序でどのサービスを通過するか
- 課金のステータスはどこに持っていて、何をトリガーに更新されるか
- 障害が起きたとき、どこを見れば原因がわかるか
これらを答えられない状態でリリースしてしまうと、問題が起きたときに「AIに聞けばなんとかなる」という頼り方しかできなくなります。しかしAIにも限界はあり、特にセッションが切れてコンテキストが失われた状態では、状況を正確に把握して正しい指示を出すのは人間側の役割になります。
AIが作ったものを理解するとは、コードを読むことではありません。システムの構造・データの流れ・判断の根拠を自分の言葉で説明できる状態を保つことです。それができていないと、機能追加のたびに「前の実装と何が違うのか」がわからなくなり、負債が積み上がっていきます。
実践的な方法として、設計の意図や「なぜこうしたか」をファイルに書き出しておくのは有効です。AIのセッションが切れてコンテキストが失われたときも、ファイルに残しておけば再開がスムーズになります。.mdにプロジェクトの方針・制約・決定事項を書いておくと、新しいセッションでも一貫した動作が得られやすいです。「理解する」ことと「残す」ことはセットで考えるといいでしょう。
結論：「コードを書く能力」より「何を作り・確認すべきかを決める能力」が問われる
AIはコードを書くことができます。それは本当にすごいことですし、エンジニアの開発速度が大幅に上がったのは事実です。私自身、TypeScriptやReactを本格的に使ったのは今回が初めてだったにもかかわらず、AWS全サーバーレス構成のシステムを構築してWebとApp Storeへのリリースまで持っていけました。
ただ、バイブコーディングで乗り越えられないのは判断と責任です。
- このサービスを選んでいいか
- このセキュリティ設計で本当に大丈夫か
- ここで妥協すると後でどうなるか
AIはこれらの問いに対して「答え」を提示してくれますが、それが自分のシステムに対して正しい判断かどうかを評価できるのは、最終的には人間しかいません。
完全な非エンジニアがVercelやFirebase等の簡易ツールでプロトタイプを作ることは現実的に一つの案だと思います。しかし商用サービスとして、セキュアに、スケーラブルに、課金を組み込んでリリースするとなると、インフラ・セキュリティ・ドメイン知識への一定の理解はまだ必要だと感じました。
ここで言う「理解」は、特定のサービスの使い方を深く知ることではなく、どんな攻撃手法が存在するか、システムはどういう構造で成り立っているか、脆弱性はどこに生まれやすいか——そういった体系的な概念の理解です。個別サービスの知識はAIに聞けば補完できますが、「何を気にすべきか」という視点そのものはAIが自動で持ってきてくれるものではありません。
コードを書く能力はAIが代替してくれます。だからこそ、AIが生成したコードを理解する能力、そして何を作るか・何を確認すべきかを判断する能力が、求められるスキルだと感じました。
最後まで読んでいただきありがとうございます。
今回ご紹介した Engy は、AIを使った英語4技能学習アプリです。AIとのリアルタイム英会話練習（AI Speaking）、英作文の自動添削（AI Writing）、文法クイズや語彙学習など、日常的な英語学習をひとつのアプリでカバーしています。WebブラウザでもiOSアプリでも利用できます。
無料プランからお試しいただけますので、英語学習に興味がある方やAIと実際に話してみたい方は、ぜひ一度使ってみてください。使ってみた感想や、改善してほしい点なども気軽にお伝えいただけると嬉しいです。
- Web: engy.academy
- iOS: App Store