バイブコーディングのデプロイの壁。非エンジニアの公開手順

AIに話しかけるだけでWebツールは動くところまで作れた。でも、その画面を社内やお客さまに見せようとした瞬間、「どうやって公開するの？」で完全に止まってしまった。そんな経験はありませんか。

これは「デプロイの壁」と呼ばれる、バイブコーディングで誰もがぶつかる最初の関門です。この記事では、非エンジニアの方が自分のツールを安全にインターネット上へ公開するための判断軸と手順、そして公開前に必ず見るべきチェック項目までを、現場目線で具体的にお伝えします。

Contents / 目次

1. 結論。デプロイの壁は「公開先を1つ選ぶ」だけで越えられる
2. 具体的なやり方。種類別のデプロイ手順を順番に解説
3. デプロイできると何が変わるか。公開が生む成果イメージ
4. よくある失敗と回避法。公開でつまずく典型パターン
5. 使う側の落とし穴。公開できた後に見えてくる現場の本音
6. よくある質問

結論。デプロイの壁は「公開先を1つ選ぶ」だけで越えられる

先に結論をお伝えします。デプロイの壁が高く感じるのは、「作るAI」と「公開する場所」がまったく別の仕組みだからです。AIはコードを書いてくれますが、そのコードを世界中からアクセスできる場所に置く作業は、また別の手順なのです。

デプロイとは、かんたんに言うと「自分のパソコンの中だけで動いているツールを、インターネット上の住所（URL）を持った状態に引っ越しさせること」です。お店にたとえると、商品を作り終えた段階がコーディング、店舗を借りて看板を出して開店する段階がデプロイ、というイメージです。

そして、越えるためにやることは突き詰めると次の3つだけです。順番に見ていきましょう。

• 自分のツールの種類を見分ける：「画面だけのツール」か「裏で処理が動くツール」かを判定する
• 種類に合った公開先を1つ選ぶ：種類さえ分かれば、選ぶべきサービスは自然に絞れる
• 公開前チェックをしてから出す：特にAPIキーの扱いを確認してから世に出す

ここで一番大事なのが、最初の「種類の見分け」です。ツールが静的サイトなのか、それとも裏側の処理が必要なのかで、公開先も難易度もまったく変わります。ここを取り違えると、「無料で公開できるはずが急に複雑になった」と感じてしまいます。

静的サイト（せいてきサイト）とは、HTML・CSS・JavaScriptだけで完結し、誰が見ても同じ内容が表示されるページのことです。一方、ユーザーごとにデータを保存したり、AIのAPIを呼んだり、ログイン機能があるツールは「バックエンド（裏側の処理）」が必要になります。この違いを表にまとめます。

ツールの種類	具体例	向いている公開先の性質	難易度
静的サイト（画面だけ）	計算ツール、診断、LP、社内用の一覧表、ポートフォリオ	無料の静的ホスティング	やさしい
裏側の処理が必要	データ保存、ログイン、AI連携、フォーム送信を自前で処理	フルスタック対応のホスティング	やや高い
AI作成ツール内で完結	作成サービスの中で組み立てたアプリ	そのサービスの公開機能をそのまま使う	やさしい

つまり、あなたのツールがどこに当てはまるかが分かれば、もう半分は解決しています。次の章で、種類別の具体的な手順を見ていきます。

具体的なやり方。種類別のデプロイ手順を順番に解説

ここからは実際の手順です。まず自分のツールがどのタイプか判定し、それぞれの公開ルートに進んでください。AIが作ったコードでも、考え方は同じです。

まず最初にやること。ツールの種類を見分ける

種類の見分けは、次の質問にAIへ聞くのが一番早いです。コードを自分で読めなくても大丈夫です。ツールを作ったAIのチャットに、そのまま次のように投げてみてください。

このツールを公開したいです。次の3点を、専門用語を使わず教えてください。
1. これは静的サイト（HTML/CSS/JavaScriptだけ）ですか、それともサーバー側の処理が必要ですか
2. APIキーや秘密の情報をコードの中に直接書いていませんか。書いているなら場所を教えてください
3. 無料で公開する場合、どのホスティングサービスが向いていますか。理由も短く

この質問への答えで、進む道が決まります。「静的サイトです」と返ってくれば一番やさしいルート、「サーバー側の処理が必要です」と返ってくればもう一段ていねいに進めるルートです。

パターン1。静的サイトを無料で公開する手順

静的サイトなら、無料のホスティングサービスに置くのが基本です。代表的なものに、GitHub Pages、Netlify、Vercel、Cloudflare Pages などがあります。いずれも個人や小規模なら無料の範囲で公開できることが多いですが、無料枠の条件（帯域・ビルド回数・商用利用の可否など）はサービスごとに異なり、変更されることもあります。最新の条件は必ず各社の公式ページで確認してください。

• GitHub Pages：静的サイト向けのサービスです。カスタムドメインやSSLの利用可否、対応条件はリポジトリの公開設定などで変わるため、公式ページで確認する
• Netlify：静的サイト向けのサービス。対応条件や公開方法は公式ページで確認する
• Vercel：静的サイトからフルスタックまで対応。商用利用の可否は公式ページで確認する
• Cloudflare Pages：静的サイト向けのサービス。対応範囲や条件は公式ページで確認する

初心者の方がつまずきにくいのは、ファイルをまとめて置くだけで公開できるタイプのサービスです。プロセスとしては次の流れになります。具体的なボタン名は各サービスで違うため、ここでは順番だけ示します。

• 1. ファイルを1つのフォルダにまとめる：AIに「公開用のファイル一式を1つのフォルダに整理して」と頼み、index.html を含む状態にする
• 2. ホスティングサービスにアカウントを作る：メールアドレスで無料登録する
• 3. フォルダをアップロード（または連携）する：ドラッグ＆ドロップ対応のサービスならフォルダを画面に放り込むだけ
• 4. 発行されたURLを開いて確認する：自動でURLが割り当てられるので、スマホでも開いて表示を確かめる

ポイント。最初の公開は「自動で割り当てられる仮のURL」で十分です。独自ドメイン（自社の○○.comのような住所）はあとからでも設定できます。まず公開して動く状態を作ることを優先しましょう。

もし「GitHubと連携してください」と案内されて手が止まったら、ドラッグ＆ドロップでフォルダを直接アップロードできるサービスを選び直すのも有効です。連携の仕組みは便利ですが、初回はシンプルな方法から入る方が挫折しにくいです。

パターン2。裏側の処理があるツールを公開する手順

データ保存、ログイン、AI連携などがあるツールは、フルスタックに対応したホスティングが必要です。Vercel、Render、Google Cloud（App Engine など）といった選択肢があり、無料枠や条件はサービスごとに異なります。無料トライアルや無料枠の有無・条件は変わりやすいので、各サービスの公式ページで最新の情報を確認してください。

たとえばGoogle Cloudの場合、アプリのテストから公開までの流れが公式ドキュメントにまとまっています。Google Cloud公式のアプリをテストしてデプロイするドキュメントのように、提供元の手順を見ながら進めるのが結局は一番確実です。

このタイプで非エンジニアの方が必ず詰まるのが「環境変数（かんきょうへんすう）」です。環境変数とは、かんたんに言うと「コードの中に直接書かず、外側で安全に保管しておく秘密の設定値」のことです。AIのAPIキーやパスワードがこれにあたります。手順は次のようになります。

• 1. 秘密の値をコードから抜き出す：AIに「APIキーを環境変数に置き換えて」と頼み、コード内の直書きをなくす
• 2. ホスティング側に環境変数を登録する：サービスの設定画面で、キー名と値のペアを登録する
• 3. 公開（デプロイ）を実行する：連携やアップロードで公開処理を走らせる
• 4. エラーが出たらログをAIに見せる：赤い文字のエラーメッセージをコピーしてAIに貼り、原因と直し方を聞く

エラーが出ても落ち込む必要はありません。むしろ正常です。エラーメッセージをそのままAIに渡して「これはどういう意味で、どう直せばいいですか」と聞けば、たいていは数往復で解決します。これがバイブコーディングの強みです。

パターン3。AI作成サービス内で完結させる手順

Lovable、v0、Replit などのように、作成から公開までを1つのサービスの中で完結できるツールもあります。いずれも公開ボタンに相当する機能が最初から用意されていることが多く、別のホスティングを探す必要がありません。対応範囲や公開方法はツールごとに異なり、変わることもあるため、最新の仕様は各サービスの公式ページで確認してください。

• Lovable：AIで作ったアプリやページを、サービス内の機能でそのまま公開する使い方ができるとされています
• v0 by Vercel：AIでUIやアプリを生成し、そのまま公開につなげられるとされています
• Replit：ブラウザ上でコードの作成・実行・公開までを行えるとされています

具体的なツール上での操作については、Lovableで顧客管理ツールを自作する手順でも作成から公開までの流れを解説しています。「とにかく早く公開したい」「まず社内で試したい」という段階なら、この完結型から入るのが最短ルートです。

ただし、完結型サービスは手軽な反面、後から別の場所へ引っ越し（データやコードの移行）がしにくい場合があります。社外に長く公開する本番ツールにするなら、早い段階でコードを書き出せるか（エクスポートできるか）を確認しておきましょう。

デプロイできると何が変わるか。公開が生む成果イメージ

デプロイの壁を越えると、「作っただけ」から「使われるツール」へ一気に変わります。ここが一番のリターンです。

実際の現場でも、非エンジニアが自分でツールを作って公開し、日々の業務に使い始める動きが広がっています。ただし、どのくらいの時間や手間が削減できるかは、業種や業務内容、運用の仕方によって大きく変わります。

公開できると、具体的にこんな変化が生まれます。それぞれ見ていきましょう。

• 共有が一瞬になる：URLを送るだけで、相手はインストール不要でその場で使える
• 改善のサイクルが速くなる：公開後に直して再公開するまでが短く、使われながら磨ける
• 外注待ちがなくなる：小さな修正のたびに業者へ依頼していた時間とコストが減る
• 社内に「作れる人」が生まれる：1つ公開できた経験が、次のツール内製化への自信になる

成功している企業に共通するのは、いきなり大きなシステムを目指さず、小さな1業務から始めている点です。最初に紹介した完結型サービスでの公開や、社内限定の小さなツールから入り、成功体験を積みながら範囲を広げています。最初の一歩をどう選ぶかについては、AI導入は何から始めるか。中小企業が最初の1業務を決める手順も参考になります。

よくある失敗と回避法。公開でつまずく典型パターン

デプロイの段階で起きる失敗には、はっきりとした「あるあるパターン」があります。先に知っておけば、ほとんどは避けられます。代表的な4つを、起きる状況と防ぎ方のセットで紹介します。

失敗1。APIキーをコードに直書きしたまま公開してしまう

これが最も多く、そして最も危険な失敗です。AIに作らせたツールでAIのAPIを使う場合、キー（鍵）がコードの中にそのまま書かれていることがあります。静的サイトとして公開すると、そのコードは誰でも見られる状態になります。

つまり、キーが第三者に丸見えになり、勝手に使われて高額請求につながる恐れがあります。

防ぎ方は、公開前に必ずAIへ「このコードに秘密のキーが直書きされていないか確認して」と聞くことです。AIのAPIを呼ぶような処理は、キーを隠せるサーバー側（裏側の処理）を経由させるのが原則です。静的サイトにAPIキーを置いてはいけません。

失敗2。自分のパソコンでは動くのに、公開すると真っ白になる

「ローカル（自分のPC）では完璧だったのに、公開した途端に画面が真っ白」という状況です。これは、ファイルの読み込み先の指定や、必要なファイルが公開フォルダに含まれていないことが原因で起きがちです。

結果として、利用者には壊れたページしか見えません。防ぎ方は、公開後に必ず別の端末（できればスマホ）で開いて確認することと、真っ白になったらブラウザのエラー表示やホスティングのログをコピーしてAIに渡すことです。「公開すると真っ白になります。このログの原因を教えて」で、原因にたどり着けます。

失敗3。無料枠の制限を知らずに本番運用してしまう

無料で公開できた安心感から、そのまま本番で使い続けてしまうケースです。サービスによっては、一定時間アクセスがないと自動でスリープ（休止）し、次のアクセスで表示が遅くなる仕様のものもあります。

お客さま向けに使っていて「アクセスしたら表示が出るまで時間がかかる」となると、信頼を損ねます。防ぎ方は、本番で使う前に、選んだサービスの無料枠の制限（スリープ・転送量・同時アクセス数など）を公式ページで確認することです。料金や制限は変わりやすいため、必ず最新の情報を見てください。

失敗4。属人化してブラックボックスになる

作った本人しか公開方法も直し方も分からず、その人が不在になると誰も触れなくなる失敗です。これは技術というより運用の問題で、社内ツールほど起きやすいです。

結果、せっかく公開したツールが「怖くて誰もいじれない」状態になります。防ぎ方は、公開手順とログイン情報の保管場所を1枚のメモにまとめておくことです。どのサービスに、どのアカウントで、どう公開したか。この3点を書き残すだけで、属人化のリスクは大きく下がります。

使う側の落とし穴。公開できた後に見えてくる現場の本音

ここまで手順をお伝えしてきましたが、現場で支援していて率直に感じる「妥協点」もお伝えします。きれいごとだけでは、かえって判断を誤るからです。

まず本音として、「公開できた」と「安心して使い続けられる」は別物です。バイブコーディングは作って公開するまでは驚くほど速い。ですが、その後の運用は、AIが全部肩代わりしてくれるわけではありません。

具体的には、公開した後も次のような「地味な作業」が残ります。

• セキュリティの維持：脆弱性が見つかったときの対応
• エラー対応：動かなくなった箇所の調査と修正
• ライブラリの更新：使っている部品を新しい版に保つ
• データのバックアップ：万一に備えてデータを控えておく

ここを軽く見ると、半年後に「動かなくなったが直せる人がいない」という状態に陥ります。

内製と外注の切り分けで言えば、判断の目安は次のとおりです。まず、次に当てはまるツールは、自分たちで作って公開する内製が向いています。

• 社内だけで使う
• 止まっても困らない
• 扱うのが機密でないデータ

逆に、次に当てはまるツールは、公開して終わりにせず、設計やセキュリティの面で専門家の目を一度入れるべきです。

• お客さまの個人情報を扱う
• 止まると業務や売上に直結する
• 決済が絡む

コストの見落としもよくあります。「無料で公開できた」と思っても、独自ドメイン代、AIのAPI利用料、アクセスが増えたときの有料プランへの移行など、後から発生する費用があります。金額はサービスや利用量によって大きく変わりますが、把握せずに始めると「思ったより続かない」原因になります。

現場での率直なおすすめ。まずは社内限定・低リスクのツールで「作って公開する」を一度通しで経験してください。その手応えをつかんでから、お客さま向けや基幹業務に広げる。この順番が、結局は一番遠回りせずに済みます。

なお、公開したツールにフォーム機能などを足したい場合は、問い合わせフォームを外部ツール不要で自作する手順のように、機能ごとに小さく作り足していく考え方が現場では扱いやすいです。最初から完璧を目指さず、公開した後に少しずつ育てる方が、結果的に長く使えるツールになります。

よくある質問

ここまで読んで、「自分でやり切るのは少し不安」「お客さま向けの本番ツールとして公開したい」と感じた方もいるかもしれません。コレットラボのAI業務システム化支援では、AIで作ったツールを安全に公開・運用するところまで一緒に設計し、内製したい会社にはやり方を、任せたい会社には伴走を、状況に合わせてご提案しています。まずは現状を整理するだけでも大丈夫です。AI業務システム化の詳細はこちらから、お気軽にご相談ください。