AIでアプリは作れた 公開と運用の言葉をレストランで地図にする

AIは作ってくれるのに 公開のあたりで言葉が変わる

AI駆動開発では、画面はするすると出来上がります。ところが「作れた」あとの公開や運用の話になると、急に知らない言葉が並び始めます。こんな場面に覚えはないでしょうか。

• AIに「ではデプロイしましょう」と返されたが、デプロイが何を指すのか分からない
• 画面に「環境変数を設定してください」と出たが、どこに何を入れるのか分からない
• 手元のプレビューでは動くのに、本番にすると止まってしまう
• フォームに入力したデータが、次に開いたら消えている

どれも、コードの書き方の問題ではありません。作ったものが、どこで、どうやって動き続けるのかという、Webの土台の話です。この土台を、一軒のレストランに置き換えて最後まで通してみます。

Webアプリは2つの軸で整理できる

細かい用語に入る前に、地図を一枚だけ描きます。Webアプリは分解していくと、最後は2つの軸に収まります。

ひとつは、リクエストとレスポンスの往復です。お客さんが注文を出し、料理が返ってくる。ブラウザ（アプリを使う人の画面）が「このページをください」と頼み、その答えが返る。Webアプリの動きは、突き詰めればこの往復の繰り返しです。

もうひとつは、状態（データ）がどこに残るかです。やりとりの中で生まれた情報が、その場限りで消えるのか、どこかにしまわれて次回も残るのか。

これから出てくる言葉は、すべて「往復のどこにいるか」「データを持つ側か」で位置づけられます。先に置いておくと、迷子になりません。では、一軒のレストランを歩いてみます。

注文から料理が返るまで

• 来店するお客さんが、ブラウザ。注文を出す側にあたります
• お客さんが接するホール、内装やメニュー表や接客が、フロントエンド。見た目と操作を担う部分です
• 注文を受けて調理し、味を決める厨房が、バックエンド。画面の裏で計算や判断をするプログラムです
• ホールと厨房を行き来する注文伝票が、API。何を渡すと何が返るかを決めた受け渡し口で、外部の仕入れ先とのやりとりにも同じ伝票を使います

ここまでが、注文して料理が返る往復の登場人物です。では、データはどこに残るのでしょうか。食材や作り置きをしまう倉庫が、データベース（DB）です。登録情報も保存したメモも、ここに入れておけば次回また取り出せます。逆に、倉庫に入れず調理台に出しっぱなしの食材は、店を閉めれば片付けられて消えます。

「入力したデータが次に開いたら消えている」の正体は、たいていこれです。DBに保存する処理を通っておらず、その場に置いただけなので、次の営業では残っていません。

サーバという言葉が2つの意味で使われている

いちばん混乱しやすいのが「サーバ」です。この一語は、文脈によって別のものを指します。

ひとつは、いま出てきた厨房、動いているプログラムそのものです。「サーバ側で処理する」と言うときの意味にあたります。もうひとつは、そのプログラムが動く場所、厨房を構える物件、つまり機械やクラウドのことです。「サーバを借りる」「サーバに載せる」と言うときの意味です。

AI駆動開発で「サーバを立てる」と出てきたら、どちらの話かは前後で決まります。処理の話なら厨房、置き場所の話なら物件。同じ言葉が両方に使われていると知っているだけで、読み違いが減ります。

この物件を借りて店を構えることが、ホスティングです。自分で建てることもできますが、多くはクラウドという貸し物件を借ります。必要なときだけ席を用意してくれる形もあり、管理の多くは貸主側が引き受けます。

物件が決まっても、お客さんは住所を知らなければたどり着けません。nihonbashi.ai のような住所がドメイン、その住所を実際の物件へ案内する仕組みがDNSです。ドメインを買っただけでは店は開かず、住所を物件に結びつけて、はじめて人がたどり着けます。

作れたと動き続けるは別のこと

手元やプレビューで動くことと、本番で公開されて使われ続けることは、同じではありません。ここで、仕込みと開店の違いが効いてきます。

書いたコードを、本番で実際に動く形にまとめ上げる下ごしらえが、ビルドです。その仕上がりを本番の店頭に並べ、お客さんに出せる状態にすることが、デプロイです。仕込みが終わっただけでは、まだ誰も食べられません。開店して初めて届きます。「ビルドは通ったのに本番に反映されない」という戸惑いは、仕込みと開店を一続きだと思っていると起きます。

営業中のフロアとは別に、試作用の厨房もあります。新しいメニューをお客さんに出す前に試す場所が開発環境やプレビュー、実際に使ってもらうのが本番環境です。試作の場で確かめてから本番に出す、という順序が事故を防ぎます。

そして店には、外へ出してはいけない金庫の鍵があります。外部サービスと取引するための合言葉（APIキー）のような値は、環境変数として渡します。環境変数は、実行時に店へ渡す設定の入れ物という広い意味で、その中でも外に出してはいけない秘密の部分がシークレットです。金庫の鍵にあたるのは、この秘密の部分です。本番の金庫に鍵を入れ忘れると、外部サービスの扉が開かず、プレビューでは動いたのに本番だけ止まります。「環境変数を設定してください」は、この金庫に鍵を入れてください、という意味です。

余裕があればもう2つ

店が回り始めると、さらに2つの仕組みが助けてくれます。お客さんの近くに置いた受け取り拠点から、画像などを速く届けるのがCDNです。更新すると仕込みから開店までが自動で流れるようにするのが、CI/CDです。どちらもなくても店は開けます。まずは往復とデータの2軸を押さえ、必要になったら足せば十分です。

用語ごとの代表的なサービス

言葉と実物が結びつくと、地図はぐっと使いやすくなります。よく使われるサービスを、地図の箱ごとに挙げておきます（いずれも一例です）。

• フロントエンド … React、Vue、Next.js
• バックエンド（サーバ） … Node.js、Python、Supabase Edge Functions
• データベース … PostgreSQL、MySQL、Supabase、Firebase
• ホスティング … Vercel、Netlify、Cloudflare、Lovable Cloud
• ドメイン / DNS … お名前.com、Value Domain、Cloudflare
• ビルド … Vite、webpack
• デプロイ … Vercel、Netlify、GitHub Actions
• 環境変数 / シークレット … .env ファイル、Vercel の環境変数、Supabase Secrets

ひとつ知っておくと楽なのは、最近のサービスは複数の役割を兼ねることです。たとえば Vercel はホスティングとデプロイとビルドを、Supabase はデータベースとバックエンドをまとめて引き受けます。データベースからホスティング・デプロイまで一通りをまとめて用意する Lovable のようなサービスもあります。ひとつのサービス名が地図の複数の箱にまたがって見えるのは、このためです。

AIが画面を作れても 地図は人が持つ

ここまでの言葉は、最初の地図に戻すと収まります。往復の側にいるのが、ブラウザ、フロントエンド、API、バックエンド。データを持つ側が、データベース。動かす場所が、ホスティングとドメイン。公開の工程が、ビルドとデプロイ。そして秘密の設定が、環境変数です。この地図さえあれば、AIへの指示も、詰まったときの切り分けも、自分の言葉でできます。

一方で、正直に書いておきます。AIは画面を驚くほど速く作りますが、店をどう設計するかまでは肩代わりしてくれません。どのデータをどこに残すか、誰に何を見せてよいか、どこをAIに任せどこを人が確かめるか、公開したあとどう運び続けるか。そこは人が決める領域として残ります。

私たち Nihonbashi AI Lab が価値を置いているのも、画面を作ることそのものではなく、その手前と奥にある4つの設計です。

• 業務設計 その画面が、どの業務のどこを担うのか
• データ構造・権限設計 何を倉庫に残し、誰が取り出してよいのか
• AI活用設計 どこをAIに任せ、どこを人が確かめるのか
• 運用導線 開店したあと、誰がどう店を回し続けるのか

AIで作り始めたけれど、この地図の引き方に自信が持てない。そんなときは、Nihonbashi AI Lab に相談する。作れたその先の、動き続けるを一緒に設計します。