宮崎翼 
自分で作った画面（アプリ）を、いざ「みんなに使ってもらおう」と思った瞬間に手が止まる——。Webサイトとして出すの？ スマホアプリとしてストアに出すの？ サーバーは要るの？ 公開のやり方が一気に押し寄せて、何から手をつければいいか分からなくなります。
香川県のノーコードブートキャンプで質問ありました。
その「アプリ公開の方法」についての記事です。
作ったものを世に出すルートはいくつかありますが、すべて「アプリの3層構造」で整理できます。
これさえ掴めば、自分のアプリがどのルートで公開できるかを、迷わず選べるようになります。
この記事は、AI（ChatGPT・Cursorなど）やノーコードで、初めてサービスを作ってみた／作り始めた人に向けています。「作れたのはいいけど、これってどうやって公開するの？」——その段階のモヤモヤを解消するのがゴールです。
先に結論だけ言うと——
・パソコンやスマホのブラウザで使えれば十分なら → Webのまま公開（ホスティングに乗せるだけ）
・スマホアプリとしてストアに並べたいなら → ①ネイティブで作る、または②今あるWebをそのまま箱に包む
まずこの2択を押さえれば大丈夫。あとは枝葉です。
まず大前提：アプリは「3つの層」でできている
公開方法を理解する前に、土台となる考え方を1つだけ。アプリは、ざっくり3つの層でできています。レストランに例えると分かりやすいです。
- ① ガワ（画面） … お客さんが見る「お皿の上の料理」。ユーザーが触る部分で、「Web」か「ネイティブアプリ」か
- ② 届け方 … 料理をどう出すか（店内提供かテイクアウトか）。①をどうやって手元に届けるか（＝この記事の主役）
- ③ 裏側 … お客さんから見えない「厨房」。データ・保存・ログイン（Supabase / Firebase など）
公開でつまずく人のほとんどは、この3つをごちゃ混ぜにして「全部まとめて難しそう」と感じています。逆に言えば、「①が何か」で「②の公開ルート」が決まり、「③裏側（厨房）」はどのルートでも共通——この関係さえ分かれば、一気に見通しが良くなります。
1つ補足します。③の裏側（厨房）は、ゼロから自分で作る必要はありません。データ保存やログインが最初から揃った“裏側まるごとお任せ”サービス——代表がSupabaseやFirebase——を組み合わせるのが、いまの定番です。料理人を一人ずつ雇うのではなく、設備の整ったセントラルキッチンを借りるイメージですね。
そしてここで、初心者が必ずぶつかる疑問があります。「Vercelを使え、ってよく勧められるけど、あれは裏側のこと？」——いいえ。先に答えだけ言うと、Vercelは③裏側ではなく、②の“届け方（ホスティング）”の道具です。この取り違えが混乱の元。なぜ混同しやすいのかは、このあとの「ホスティングとストアは別物」の章でハッキリさせます。
使ったツール別：あなたの作り方はどれ？
「で、私が使ったツールはどれに当てはまるの？」を先にはっきりさせておきましょう。何で作ったかによって、進む公開ルートが少し変わります。
| 使ったツール | 手に入るもの | 進むルート |
|---|---|---|
| AIでコードを書いた（v0 / Lovable / Bolt / Cursor / Claude Code など） | コード（HTML / CSS / JS） | この記事のルートがそのまま使える |
| ノーコードで作った（Bubble / Glide / Adalo / STUDIO など） | ツール上で動くWebアプリとURL | 公開URLはツールに付属。スマホアプリにするなら後半の「ラップ（Capacitor / TWA）」へ |
| ノーコードでネイティブ書き出し（FlutterFlow など） | ネイティブアプリ | そのままストアに申請（後述のルートD） |
どのツールで作っても、③の裏側（Supabaseなど）は共通で使えるのは同じ。まずは「自分はこの行だ」と当たりをつけて、次の早見表に進んでください。
公開ルート早見表 — 作ったものを、どう世に出すか
では本題。作ったものを公開するルートを、1枚の表にまとめました。
左の「作ったもの」から、自分のルートをたどってください。
| 作ったもの | 公開ルート | 出る場所 |
|---|---|---|
| Webアプリ | ホスティングに乗せる | URL（Vercel / GitHub Pages / Netlify） |
| Webアプリ | PWA化する | ブラウザから「インストール」 |
| Webアプリ | TWAでラップ | Google Play |
| ネイティブ（Flutter / React Native） | ビルドして申請 | App Store / Google Play |
| ハイブリッド（Capacitorで同梱） | ビルドして申請 | Google Play（Vercel不要） |
そして③の裏側（Supabaseなど）は、どのルートを選んでも共通で使えます。「Google Playに出すから裏側を変えなきゃ」ということはありません。この表のどこに自分がいるかを把握するのが、公開の第一歩です。
最大の落とし穴：「ホスティング」と「ストア」は別物
公開でいちばん混乱するのがここです。よくこう整理されます。
- Webなら → Vercel / GitHub Pages
- アプリなら → App Store / Google Play
一見正しそうですが、VercelとGoogle Playは役割がまったく違います。
- Vercel / GitHub Pages … Webを「動かし続ける場所」（ホスティング）
- App Store / Google Play … アプリを「配る場所」（ストア）
ECサイトで例えるなら、Vercelは商品を置いておく倉庫、Google Playは商品を並べる店頭です。倉庫と店頭を同じ「公開する場所」とひとくくりにすると、混乱します。「動かす場所」と「配る場所」は分けて考えるのが、公開を理解する鍵です。
ルート別の中身 — どれを選べばいい？
A. Webアプリをそのまま公開する（ホスティング）
作ったWeb画面を Vercel / GitHub Pages / Netlify などに乗せると、URLで誰でもアクセスできるようになります。インストール不要で、リンクを送るだけで見てもらえるのが強み。例：社内の勤怠入力ツール、イベントの申込フォーム、ポートフォリオサイト。「URLを共有すれば使ってもらえる」もので十分なら、これが一番ラクです。
B. WebアプリをPWAにする
Webアプリに少し設定を足すと、ブラウザから「ホーム画面に追加」でアプリのように使える形（PWA＝Progressive Web App）になります。スマホのホーム画面にアイコンが並び、全画面で開けます。例：食べログやX（旧Twitter）を「ホーム画面に追加」したときの、あのアプリっぽい状態。ストア申請なしでアプリ風にできるのが利点。ただし見た目は「Webアプリ感」が残ります。
C. WebアプリをTWAでGoogle Playに出す
既にWebアプリがあるなら、TWA（Trusted Web Activity）で箱に包んで Google Play に並べられます。専用ツールのBubblewrapなどを使います。コマンド操作が苦手なら、Web画面でポチポチ操作するだけでパッケージを作れるPWABuilder（Microsoft製）が手軽でおすすめです。仕組みは「アプリを開くと、中で公開URLをこっそり表示する」イメージ（＝Webサイトをアプリの皮で包んだ状態）。そのためホスティング（Vercel等）が必須です。Webの公開とストア公開をセットで行うルートです。
D. 最初からネイティブアプリで作る（Flutter / React Native）
本格的なスマホアプリにするなら、Flutter や React Native でネイティブアプリそのものを作るのが王道。特にReact Nativeは、Expoを使うと環境構築やビルドが自動化され、初心者でも始めやすい定番です。ビルド（アプリの形に組み立てること）して App Store / Google Play に申請（ストアの審査に出すこと）します。カメラやプッシュ通知などスマホの機能をフルに使え、動作も見た目もアプリらしく仕上がります。例：InstagramやUberのような“ちゃんとしたスマホアプリ”を目指すならこれ。ただしWebとは別の作り方を覚える必要があります。
E. ハイブリッド（Capacitorでローカル同梱）
「Webで作った画面を、そのままアプリにしたい」なら Capacitor。Cと似ていますが決定的に違うのは、画面ファイルをアプリの箱の中に直接詰め込む（同梱する）点。Cの「お店に毎回URLを見に行く」のに対し、Eは「お弁当を最初から箱に詰めて持っていく」イメージです。だからWebをネットに公開する必要がありません（＝Vercel不要）。Webの資産を活かしつつ Google Play に出せる、いいとこ取りのルートです。詳しくは後半の「最小構成」で扱います。
③裏側は、どの公開ルートでも共通で使える
※ここから少し専門的な話になります。難しければ読み飛ばしてOK。結論（「裏側はSupabaseで足りる」）は変わりません。
ここで③の裏側（データ・ログイン）の話。結論から言うと、Supabaseなどの裏側は、上のA〜Eどのルートを選んでもそのまま共通で使えます。Webでもネイティブでもハイブリッドでも、裏でデータを保存しログインを処理してくれます。
だから「Google Playに出すからSupabaseはダメ」という発想は不要です。たいていのアプリは、裏側はSupabaseだけで足ります。「サーバーをもう1つ用意して」とAIに言われるのは、次のような“ちょっと特別なこと”をしたいときだけ。自分に当てはまらなければ、ここは読み飛ばして大丈夫です。
- 開くたびに中身を作り直して見せたい … 例：ニュースサイトのように、毎回その時点の最新一覧を表示する（専門用語で「SSR」）
- 画面の裏で“自動の処理”を動かしたい … 例：「問い合わせが届いたら、自動で確認メールを送る」（専門用語で「API」）
- 人に見せたくない“鍵”を使いたい … 例：クレジット決済や他社AIの秘密のパスワード。スマホやブラウザに置くと盗まれるので、裏側に隠す必要がある（この鍵を「APIキー」と呼びます）
- 時間のかかる重い作業をやりたい … 例：毎晩0時に売上をまとめて集計する、画像をいっぺんに縮小する
そして安心材料がもう一つ。こうした特別な処理も、たいていはSupabase自身の機能（Edge Functions）でまかなえます。だから最初から別のサーバーを足す必要は、ほとんどありません。
要するに：「公開ルートを選ぶ話」と「裏側を強くする話」は別物。まずは「裏側はSupabaseでOK」とだけ覚えておけば十分です。
最小構成の実例：ローカルの画面をそのままアプリにする
「すでにローカルで画面が動いている」人にいちばん手軽なのが、ルートE（ハイブリッド）です。流れはこうなります。
ローカルの画面（HTML/CSS/JS）
↓ 静的ファイルに書き出し
↓ Capacitor が箱に同梱
Androidアプリ（AABファイル＝Google Play用の配布パッケージ）
↓
Google Play へアップロード
↑
データ・ログインは Supabase に直接通信※「静的ファイル」とは、サーバーで毎回処理せずそのまま表示できる完成済みのHTML/CSS/JSのこと。印刷済みのチラシのようなもので、配るだけで誰のパソコンでも同じように表示されます。
画面をアプリ内に同梱するので、Webをネットに公開する必要がありません＝ホスティング（Vercel等）もなしで完結します。必要なものはこれだけ。
- ✅ ローカルの画面（もうある）
- ✅ Supabase（裏側）
- ✅ Capacitor（ラップ役・無料）
- ✅ Google Play Console（$25 の一回払い）
- ❌ Vercel … 不要
まとめ：3層で切り分けられれば、公開で迷わない
| 疑問 | 答え |
|---|---|
| どうやって公開する？ | ①が「Web」か「ネイティブ」かで、②の公開ルートが決まる |
| ホスティングとストアの違いは？ | 倉庫（動かす）vs 店頭（配る）。役割が別 |
| Webをアプリにするには？ | TWA（要ホスティング）か、Capacitor（ローカル同梱・Vercel不要） |
| 裏側（Supabase）は変える必要ある？ | 不要。どの公開ルートでも共通で使える |
最後にもう一度。①ガワ ②届け方 ③裏側——この感覚さえ持っておけば、今後AIに色々言われても「これは①の話」「これは③だから関係ない」と自分で切り分けられます。
難しいのはアプリそのものではなく、層が混ざって見えているだけ。
自分のアプリがこの地図のどこにいるかを掴めば、公開はもう怖くありません。
