AIでモノづくりしたいエンジニア未経験者が押さえておきたいWebアプリの基本知識
BASE株式会社執行役員の柳川です。金融事業の事業責任者をしています。エンジニア→PdM→事業責任者というキャリアを歩んできました。
最近、AIで何かを作る人が爆発的に増えてます。Claude CodeやCodexに「こういうアプリ作って」と頼めば、即座に動くものが出てくる。本当にすごい時代です。
Codexのアプリとか本当にすごいので触ってみて欲しいです。
しかし、AIが裏で勝手にやってくれている部分、ブラックボックスのまま使ってる人、結構いるんじゃないでしょうか。あと、AIに指示するにしても、何がなんやらわからんから、どう指示していいかわからなくなる時もあると思います。
使い捨ての自分にだけわかるシステムなら問題なくても、人に見せようとした瞬間とか、データを保存したくなった瞬間とかに、「あれ、これってどうやるんだっけ？」と詰まります。
今回は、AIで何か作るときに知っておきたいWebアプリケーションの基礎知識、という話を書いてみます。
AIがあればもはやコードは書けなくていいです。ただ書けなくていいけど、知識がいらないわけじゃないです。なんとなくの地図を押さえておくとAIに対する指示が一段精度上がるし、何より「自分が何をやっているか」が分かる、というラインを目指します。
先に正直に言っておくと、この記事より詳しく正確に分かりやすく説明している記事も本も、世の中に無限にあります。だってただのWebアプリケーション基礎知識なので。歴史があるのよ。なので、途中でピンと来なかったら遠慮なく他の入門書や記事に飛んでください。ここはあくまで「ぼんやりとした最初の全体像」を作るための、入り口の一つです。僕の書く粒度が肌に合う人は読んでみてください。それこそAIに聞いてみてもいいと思います。
AIの時代になって、Webアプリの学び方って順序がひっくり返ったんですよね。昔は「仕組みを学んでから、作ってみる」しかなかった。今は逆に、「とりあえずAIで作ってから、仕組みを知る」という順番が、可能になりました。これはこの時代ならではの面白さだと思ってます。リバースエンジニアリングとも言えるしお手本の生成とも言えると思います。この記事はそのお手本の読み解き方だと思ってください。
なので、すでに何か作ってみた人ほど、この記事は刺さるはず。作ってない人は、軽く読んだあとに何か小さく一個作ってみると、戻ってきたとき景色が変わってると思います。
というか昔は、大体環境構築で詰むこと多かったですよね。それをAIがやってくれるだけでも神だよね。環境構築が死語になる世界が来るとはね。
この記事の歩き方
長くなったので、先に道案内を置いておきます。
大きく分けると、3つのパートで構成されています。
前半: そもそもWebアプリは何でできているのか
── ソースコード、ファイル、拡張子、ターミナル、言語、フロント/サーバー、通信、ブラウザの描画、Webアプリの定義中盤: Webアプリの「3つの段階」を旅する
── ローカルで動く / サーバーに上げて世界公開 / データを持つ。登場人物(Vercel、Supabase)も後半: 地図を持っていると、何が変わるか
── AIへの頼み方、学び方、まとめ
順に読めば、なるべく前提知識なしで追えるように書いてます。すでに用語に馴染みがある人は、中盤から読んでもらっても大丈夫。気になるセクションだけ拾い読みするのも、ありです。よくわかんないところは飛ばして、また後日読んでください！！
まず、「ソースコード」って何なのか
AIがバーっと書いてくれている「コード」って、結局なんなのか。
正体は、ただのテキストファイルです。メモ帳に書いた文章と、本質的には同じものです。
じゃあ、そのテキストファイルがどうやって「動く」のか。これは、テキストファイルを解釈して実行してくれる環境があるから動いています。あなたのPCの中だったり、サーバーの中だったり、ブラウザの中だったり。実行環境がコードを読んで、「ああ、これは画面にこういうボタンを出せ、と書いてあるな」と解釈して、初めて画面が出る。
ただこの指示文章、人間が書くのには慣れが必要だったり、ルールを間違えるとうまく動かなかったりするのです。多分慣れてないとイライラします。これを自然言語の形で指示してAIが書いてくれるのです。すごいね！
ところで、あの「黒い画面」は何
AIで何か作ろうとして、Claude CodeやCodexを使い始めると、たぶん最初に出会うのが「黒い画面に文字を打つやつ」だと思います。ターミナル(Terminal)とか、コマンドラインとか呼ばれてるやつ。
あれ、要するに「文字でコンピュータに命令を出す場所」です。マウスでクリックして操作する代わりに、「これをやって」「あれを起動して」を、文字でPCに直接お願いする場所。
macOSだと「ターミナル.app」、Windowsだと「PowerShell」「コマンドプロンプト」あたり。中身はどれも似たような役割。
Claude CodeもCodexも、このターミナルの中で動きます。だから「AIでコード書かせる」と言っても、まずはこのターミナルを開いて、そこにAIを呼び出すところから始まる。
「黒い画面=エンジニアの世界=怖い」のイメージを持ってる人、結構いると思います。でも実態は、ただの「文字で命令を出す画面」です。AIに命令する場所、と思えば、最初の心理的ハードルがだいぶ下がるはず。
幸いなことに、この黒い画面を直接触らなければならない場面はかなり少ないです。Claude Code使う場合でも、立ち上げた後にコマンド打つことはほぼないです。AIがかなりこの部分やってくれますので。まれにAIに黒い画面での直接操作をお願いされることがありますが、その時は少し注意して、そのコマンドがなんの操作なのか調べてから使ってみてください。
ちなみに、Codexのアプリを使えばターミナルを触る必要はないので使ってみてください。ターミナルを開きたくない人は、そっち系から始めるのも一手。
ファイルとフォルダ、それから「拡張子」
ソースコードはファイルだ、と書きました。じゃあアプリって、何個のファイルでできているのか? 答えは「結構たくさん」です。
多分この辺り、結構躓きポイントだと思うですよね。エンジニアリング文脈以外で、複数のファイルという概念をなかなか扱わないんですよね。ここに慣れる必要がある。
小さなアプリでも数十、大きなアプリだと数百、数千のファイルになります。これを管理するために、ファイルはフォルダ(ディレクトリと言うこともあります)で階層構造に整理されています。これを「ファイルツリー」と呼びます。
たとえば、ClaudeCodeやCodexで作るWebアプリ(何も指示しないと大体JavaScript系のフレームワークを使われます。JavaScriptについては後述します)だと、だいたいこんな構造のフォルダができます。
my-app/ ── プロジェクトの大元のフォルダ
src/ ── 自分が書く(AIに書かせる)ソースコードたち
public/ ── 画像など、そのまま配信するファイル
package.json ── このアプリがどんな部品を使うかのリスト
node_modules/ ── 取り寄せた部品の中身が入る場所(自動生成)
.env ── APIキーなど、秘密の設定情報
それぞれの役割をざっくり覚えておくと、AIに頼むときも「src/のここを直して」「.envにこれを足して」と指示が出せて、会話の解像度が上がります。
静的なWebページだとhtmlのファイル一つの場合もありますが、少し複雑なことをしようとするとこのファイルシステムへの意識が必要になります。でも安心してください。実際のところAIがうまいことしてくれるので、そんなに意識する場面はありません。でもWebアプリは複数のファイルの集合体だということは押さえておいてください。
拡張子で「ファイルの種類」が分かる
もう一つ、ファイル名の最後についている「.html」「.js」「.css」みたいな部分。これを拡張子と呼びます。
拡張子は、そのファイルがどんなルールでで書かれているかを表すラベルです。中身がHTMLなら `.html`、JavaScriptなら `.js`、CSSなら `.css`、というふうに、拡張子を見るだけで何のファイルかが分かるようになっている。
よく登場する拡張子はだいたいこのへん。
`.html` ── HTML(画面の骨格)
`.css` ── CSS(見た目・装飾)
`.js` ── JavaScript(動き)
`.json` ── JSON(設定や構造化されたデータ)
`.md` ── Markdown(文章、ちなみにこの記事もmd形式)
`.env` ── 環境変数(秘密の設定情報)
拡張子さえ見れば「あ、これは画面の話のファイルだな」「これは設定ファイルだな」と判断できる。ブラウザやサーバーも、拡張子を見て「これはHTMLとして扱おう」と判定している。
コードを書けるようにならなくても、拡張子の意味だけ知っておけば、「AIが今いじっているのは見た目のファイルだな」みたいに状況が掴めるようになります。これがあると、AIとの会話の精度がさらに一段上がる。
ちなみに、コードにはいくつかの「種類」がある
さっき「ソースコードはただのテキストファイル」と言いましたが、そのテキストの中身はいくつかの「プログラミング言語」で書かれています。聞いたことありますよね、プログラミング言語。プログラミング言語自体はたくさんあるんですが、Webアプリの文脈でよく登場するのはこのあたりです。覚えなくてもいいけど、目を慣らしておいてください。
HTMLとCSS: Webブラウザの画面の骨格を作る言葉。「ここにタイトル」「ここにボタン」「こんなデザインで」みたいな画面の構造を書く。Webブラウザはそれをのまま表示しています。
JavaScript(JS): 画面に動きを付ける言葉。HTMLを動的に生成してくれます。「ボタンを押したらこう動く」みたいな動作を書く
サーバーサイドのJavaScript(Node.jsなど): 同じJSなんですが、書く場所が違う。サーバー(後で出てきます)の中で動くJS。「データを受け取って、保存する」みたいな処理を書く(JS以外の言語もあります)
SQL: データベース(これも後で出てきます)と会話するための言葉。「このユーザーのデータを取って」「これを保存して」と頼むときに使う
コードを「読める」ようになる必要はありません。AIが書いてくれますし。
ただ、「どの言語が、何を担当しているか」、役割だけは頭に入れておくと何かあった時に役に立ちます。中身を読まなくてもいいけれど、AIが生成してくれたファイルの種類だけでも見てみましょう。
AIが「ここはJSで書きました」と言ってきたら「ああ、画面の動きの話ね」、「SQLでこう書きました」と言ってきたら「データを取り出す話ね」と、何の話をしているかが掴める。これだけでAIとの会話の精度がぐっと上がります。
他にもPythonとかRubyとかGoとか、いろんな言語があります。でもまずはこの4種類の役割を押さえておけば、AIで作るWebアプリの大半は、何の話をしているか追えるようになります。
プログラミング言語のことを調べ始めると、実行環境とか、「コンパイラ言語」と「スクリプト言語」とか色々出てくるけど、一旦無視していいです。Webブラウザは偉大だなーと思っておいて。
フロントエンドと、サーバーサイド
もう一個、Webアプリの話でしょっちゅう出てくる言葉。「フロントエンド」と「サーバーサイド(バックエンド、とも言います)」。
ざっくり、こういう分け方です。
フロントエンド ── ユーザーの目の前で動く部分。あなたがブラウザで見ている画面、押すボタン、表示される文字。HTMLとCSSとJSで作る側
サーバーサイド(バックエンド) ── ユーザーには見えない、裏方の部分。データを受け取る、保存する、計算する、認証する、みたいな処理を担当する側
ここで先に押さえておきたいのは、フロントエンドだけでも、Webアプリはちゃんと動く、ということ。
画面が出て、ボタンが押せて、入力に応じて何か計算して結果を返す、というレベルなら、フロントエンドだけで成立します。サーバーサイドは要りません。データをどこかに保存する必要がない限り、本当にフロントだけで完結する。
だから、「Webアプリを作る」=「フロントもサーバーも両方ガッツリ作る」じゃないんですよ。やりたいことに合わせて、必要な範囲だけ作ればいい。
サーバーサイドを本格的に作り込まないといけなくなるのは、データを保存したい、ユーザーごとに違う処理をしたい、ユーザーに見せたくない処理を入れたい、というあたりから。そこまで来てから、サーバーを考え始めればよいです。
AIに頼むときも「これはフロントエンドの話」「これはサーバーサイドの話」と分けて指示できると、精度が一段上がります。「ログイン機能を追加して」と漠然と言うより、「フロント側にログイン画面を作って、サーバー側で認証して、結果をフロントに返す」と分けて指示すると、AIも整理して動きやすい。
ところで、フロントとサーバーは、どう「会話」しているのか
そもそもの話。
ユーザーがブラウザで見ているフロントエンドの中身(HTML、CSS、JS)って、どこから来てるんでしょう。実は、ブラウザがインターネット上のサーバーから、ファイルを「ダウンロード」してきて、その場で表示しているんですよ。これがWeb通信の出発点。
仕組みは、こんな感じです。
ユーザーがURLを開く
ブラウザが、そのURLのサーバーに「これください」とお願いを送る、これを「リクエスト」と言います
サーバーが、フロントエンドのファイル(HTML、CSS、JSなど)を返す、これを「レスポンス」と言います
ブラウザがそれを受け取って、解釈して、画面に絵を描く
ここまでが、ページを開いた瞬間に起きていることです。
その後、ユーザーがボタンを押したり、データを送信したりすると、また別の「お願い」がサーバーに飛びます。「このデータください」「これ保存しておいて」みたいな。サーバーは「はい、これです」「保存しました」と返事を返す。これを、ユーザーがアプリを使っている間、ずっと繰り返している。
このやり取りの作法を決めているのが、HTTPというルールです。「ハイパーテキスト・トランスファー・プロトコル」の略ですが、覚えなくて大丈夫。「フロントとサーバーが会話するための共通のルールがある」と思っておけば十分。
ちなみに、サーバーから返ってくるものは、状況によって変わります。HTML、画像、CSS、JS、JSON(構造化されたデータ)、いろんなもの。
TCP/IPとか、もっと細かいネットワークの仕組みもあるんですが、そこは今日は触れません。「ブラウザが、サーバーから必要なファイルやデータをダウンロードして、画面に表示している」というイメージさえ持っておけば、当面は十分です。
ブラウザはどう「絵」を描いているのか
もう一段、ソースコードがどうWebの画面になるか、ざっくり知っておくと楽な話を。
あなたがWebの画面を開く、というのは、ブラウザ(ChromeやSafari)がHTMLを読んで、絵を描いてくれている、ということなんです。
ざっくり、こんな流れです。
ブラウザがHTMLを受け取って、画面の構造を組み立てる
CSS(見た目を担当する言語)を読んで、色や配置を決める
JavaScriptを読み込んで、動きを足す
ぜんぶ合わせて、ピクセル単位で画面に描く
ユーザーがクリックしたり入力したりしたら、JSが反応して画面の一部を書き換える
ブラウザって、普段なんとなく使っていますけど、実はこれだけ複雑なことを毎秒やってくれているソフトウェアです。
これを知っておくと、「なんでこのページ重いんだろう」「なんでこの動きカクつくんだろう」みたいな話の根っこが見えやすくなります。AIに「ここの動きをこのように変えて」と頼むときも、勘所を持って指示が出せるようになる。
JavaScriptって、画面に直接絵を描いているわけじゃないんですよ。やっているのは、HTMLを書き換えること。「ボタンが押されたら、この場所の文字を『送信中…』に変える」みたいなJSの動きは、内部的には「HTMLの該当箇所を書き換える」をやっている。そして書き換わったHTMLを見て、ブラウザがまた絵を描き直す、というループになっています。
つまり、ブラウザはあくまで「HTMLを元に描画している」装置で、JSはそのHTMLを動的に書き換える役割を担っている。ここを掴むと、ブラウザの仕組み全体が一気に見通しよくなります。
ところで、「Webアプリケーション」って何のこと
ここまで話してきて、もしかしたら違和感があったかもしれません。「HTMLだけで表示されるページは、Webアプリケーションなの?」 ふつうは、Webアプリケーションとは呼びません。
HTMLだけのページは「Webサイト」「Webページ」と呼ばれます。文字や画像を表示するだけのもの。
「Webアプリケーション」と呼ばれるのは、そこにJSが入って動きが付いて、ユーザーの操作に何かを応える、もしくはサーバー側で処理が走る、というレベルから。動的に何かが起きる、ということ。これが「アプリケーション」の語感です。
具体例で言うと、僕が個人事業で作っている「複眼道場」も「ゆびきりげんまん」も、どっちもWebアプリケーションです。
複眼道場は、エニアグラムをベースにした診断ツール群。質問に答えると結果が動的に返ってきて、ペア診断で相性を出したり、対話型で深掘りしたりできる。HTMLだけの静的なページじゃなく、JSが回答を解釈して、その場で結果を計算したり、表示する文章を組み立てたりしています。
ゆびきりげんまんはもう一段進んで、データを保存します。ユーザーが「約束」を書いて、それを覚えておいて、後から見返したり管理したりできる。これはまさに段階3、データを持つアプリです(段階の話は次のセクションで)。
みなさんがAIで作ろうとしているのも、たぶんこの「動きや処理が入っている」レベル、もしくはそれを超えて「データを保存する」レベルのものですよね。だからこの記事では、ただのHTMLじゃなくて、Webアプリケーションを作る、という前提で話を進めます。
ただ、もう一個大事なポイント。HTMLとJSだけでも、かなりリッチなものが作れます。サーバー側の処理や、データの保存がなくても、JSが頑張れば見た目も動きもかなり凝ったものが組める。
たとえば、計算機、占い、ちょっとした診断ツール、お絵描きツール、簡単なゲーム、見せ方が凝った情報ページ、このあたりはHTMLとJSだけで完結します。サーバーやデータベースなしで、結構リッチな体験を提供できる。
だから「Webアプリ作る」と聞いて、急にデータベースとか認証とか身構える必要はないんですよ。やりたいことが「データを覚えておく必要がない」レベルなら、段階2まででだいたい収まる。「データを覚えておきたい」となった瞬間に、初めて段階3が必要になる、というだけ。
作りたいものに合わせて、必要な段階まで進めばいい。これが大事です。
Webアプリには「3つの段階」がある
その上で、Webアプリには「コードをどこで動かすか」の段階が、ざっくり3つあります。
ローカルで動く段階 ── 自分のPCの中だけで動いている
サーバーに上げて、世界中から見える段階 ── URLを知っていれば誰でもアクセスできる
データを持つ段階 ── ユーザーの入力や情報を保存できる
この3つは、やってることが全部違うんですよ。なのにAIで作ってると一気にやろうとして混乱します。一個ずつ見ていきます。
段階1: ローカルで動く 「自分のPCの中だけの話」
Claude Codeで作って、「動いた！」となるのが、まずこの段階です。
画面が出る。ボタンを押すと反応する。動いてる。これは「あなたのPCの中だけで動いている状態」です。
他の人からは、見えません。あなたのPCを閉じたら、アプリも止まります。
ここで満足してると、「人に見せられない」で止まります。「動くプロトタイプ」止まり。
よくある勘違いとしては、「自分のPCで動いたから、他の人も見れるよね？できません。あなたのPCを24時間つけっぱなしにして、自宅のWi-Fiを世界に開放する気がない限り。
でも、ローカルで動かせること自体が、めちゃくちゃ面白い時代
「自分のPCの中で動く」って、本当はものすごく自由な状態なんですよ。
昔は、ブラウザ上で気持ちのいい動きや見た目を作るって、HTMLやJavaScriptを一行ずつ書き換えて、リロードして、また書き換えて...のループで、作らないといけなくて、正直だるかった。だから「とりあえず動くもの」を作るところで力尽きる、というのが、わりと普通でした。
それが今、AIに自然言語で「ここに動くグラフを足して」「ここをドラッグで並び替えられるようにして」と頼めば、ガッと出てくる。ブラウザ上で表現できるリッチさを、ようやく誰でも現実的に使い捨てしても痛くない工数で享受できるようになったんです。これがめちゃくちゃ大きい変化。
スライドの代わりにローカルで動くWebページを作ってみせるとかもできます。HTMLのファイルをブラウザで開くだけです。サーバーを建てたりする必要もありません。
だから、ローカルで動かすフェーズ自体は、本当は遊び場として最高なんです。「世界に出せないからショボい」じゃなくて、「自分の頭の中の絵を、最速で形にできる場所」として使えばいい。試行錯誤の回転数が上がるから、上達も早い。
段階1で満足してはいけない、というよりは、段階1を思いっきり楽しんでから、段階2に進んでください、と言うのが正しいかもしれない。ローカルで動かす意味は、ここにあります。
段階2: サーバーに上げる 「世界から見える状態にする」
じゃあ人に見せるにはどうするか。少し専門用語チックに言うと「サーバーに上げる」と言います。「デプロイする」とも言います。
そもそも「サーバー」って何
サーバーって言葉、聞いたことはあっても具体的なイメージが湧かない人、わりといるんじゃないでしょうか。先にざっくり押さえておきます。
サーバーは、「世界のどこかにある、ずっと電源が入ったままのコンピュータ」です。あなたのPCと本質的には同じコンピュータなんですが、決定的に違うのは「24時間365日、誰かがアクセスしてきたらすぐ応答できる状態で動き続けている」こと。
データセンターと呼ばれる大きい建物に、こういうコンピュータが何千台も並んでいて、世界中のWebサービスは、どれもそういうサーバーの上で動いています。あなたが普段使っているNetflixも、Amazonも、Instagramも、全部、誰かが用意したサーバーの上で動いている。
で、あなたのPCで「動いた!」となっているアプリを世界に出すというのは、要するに「この何千台もあるサーバーのどれかに、自分のアプリを乗せる」ということなんです。
では、どうやって乗せるのか
具体的には、あなたのPCの中で動いていたアプリを、その常時起動しているサーバーの上にコピーして、URLを発行する、ということをします。
これをやると、URLを知っている人なら世界のどこからでもアクセスできるようになります。
ここで登場するのがVercelみたいなサービスです。
Vercelは、ものすごくざっくり言うと、「あなたのアプリを、世界から見える状態にしてくれる箱」です。GitHub(=コードを保管しておくためのクラウドサービス)に置いたコードを自動で取ってきて、サーバーに展開して、URLも発行してくれる。
昔は、サーバーを借りて、土台の設定をして、コードを置いて、公開設定をして...と、何日もかかる仕事でした。今はVercelに繋げば、文字通り5分で世界公開できます。すごいね。
この段階からは「技術の話」じゃなくて、「心構えの話」も入ってきます
ここがわりと大事なところ。
「ローカルで動いている」と「世界から見える状態にある」は、技術的にも違うんだけど、それ以上に作り手の心構えが変わる転換点なんです。
ローカルで動かしているうちは、触るのはあなただけです。だから「自分が分かる動かし方をすればOK」「変な入力はしないからエラー処理は雑でいい」「データ壊れても自分が泣くだけ」で済む。
でも、世界に出した瞬間、触る人はあなただけじゃなくなる。「自分だけ分かればいい」が一切通用しなくなるんです。
想定していない使い方をされる
想定していない入力が飛んでくる
悪意を持って壊しにくる人もいる
スマホからもタブレットからも触られる
何人かが同時にアクセスする
知らない人がログインしようとする
これ全部、ローカルでは考えなくてよかった話です。世界に出した瞬間、全部考えないといけなくなる。
「動いてる」のレベルが、「自分の手元で、決まった操作をしたら動く」から、「誰がどう触っても、なんとか動き続ける」に上がる。ここの段差が、わりと急なんですよ。
AIに「世界公開して」と頼んだら、Vercelに置くところまではやってくれます。でも、「不特定多数に触られても耐える設計」までは、勝手にはやってくれない。ここはあなたの心構えとして、持っておかないといけない。
大変そうだなーと思いましたか？でも実際に自分の作ったものみた人からコメントとかもらえるとめちゃくちゃ嬉しいし、自分ごとのようにもっと良くしたい！ってなりますよ！
サーバーには「何を」上げているのか
もう一つ、段階2に絡んで知っておくと安心な話。
「サーバーに上げる」って、具体的には「あなたのプロジェクトのファイル一式を、丸ごとアップロードする」ことなんですよ。「アプリの動く部分だけ」が魔法のように選ばれて上がるんじゃなくて、プロジェクトフォルダの中身が、まるっとサーバーに乗っかる。
だから、開発中のメモ、テストデータ、APIキー(=外部サービスに接続するための鍵)が書かれた設定ファイル、こういうものも何も考えずに上げると、一緒に上がってしまうことがあります。
「リンクを張ってないから誰も見ないでしょ」も通用しません。URLは推測されます。たとえば `/admin` `/test.html` `/.env` みたいなパスを試しに叩く人は、普通にいます。何の保護もしてないと、見られて当然です。
だから、世界に出すときは「公開していいファイル」「公開してはいけないファイル」を意識して、後者を除外する。これも、ローカルでは考えなくてよかったけど、世界に出した瞬間に向き合うことになる、典型的な話です。
この指示の方法はAIに聞けば教えてくれます。そう言うことがあるんだ！と言うことだけ知っていてくれればオッケーです。
段階3: データを持つ 「保存」を実装する
次の段階。
段階1〜2のアプリは、「画面を表示するだけ」「ボタンを押すと計算結果を返すだけ」みたいな、データを永続化(また少し難しい言葉)しないものです。たとえば、計算機アプリとか、占いアプリ(その場でランダムに結果を返すだけ)とか、何かの情報をただ表示するだけのページとか。
でも、世の中の多くのアプリ、ToDoリスト、SNS、ブログ、家計簿、ECサイト、診断アプリ、は、データを保存したい。ユーザーが書き込んだ内容を覚えていてほしい。次に開いたときも残っていてほしい。ログインしてユーザーごとに違う画面を出したいという要件が出てきます。
これを実現するには、データベースというものが必要です。ここで登場するのがSupabaseみたいなサービスです。
Supabaseは、ものすごくざっくり言うと、「データの倉庫＋認証の仕組みを、まとめて貸してくれる人」です。データを保存する場所と、ユーザーがログインする仕組みと、それらを操作する命令の窓口を、ぜんぶセットで持っている。
これも昔は、自分でデータベースを立てて、認証を作り込んで、APIを書いて...と何週間もかかる仕事でした。Supabaseを使うと、それを数分でセットアップできます。すごいね。
「Vercelに上がっているけど、データを持たないアプリ」と「Supabaseに繋いでデータを持つアプリ」は、難易度が一段上がります。データの設計、認証の設計、誰がどのデータにアクセスできるかの設計。考えることが急に増えます。
データの構造は、後から変更を入れるのが大変です
ここでひとつ大事な話をしておきます。
データの構造は、後から変更を入れるのが、めちゃくちゃ大変です。
画面のデザインなら、変えたければHTMLを書き換えるだけで済む。色を変える、ボタンの位置を動かす、これは気軽にできる。
でも、データの形を変えるとなると、話が違います。「すでに保存されているデータをどうするか」「アプリ全体のどこを書き換える必要があるか」「データを壊さずに移行できるか」「このデータをどこで参照しているか洗い出す」などを、全部考えないといけない。動いているサービスのデータ構造を変えるのは、走っているバスのタイヤを履き替えるようなものです。
なので、データ設計だけは、できれば最初に時間をかけてみてください。「あとでこういう使い方されるかな」「ユーザーごとに何を覚えておいてほしいかな」「将来こういう機能を足したくなるかな」拡張の可能性を考えるフェーズを、ここは厚めに取る。これもAIに助けてもらってください。
…とはいえ、正直こういうのって、失敗しないと分からないんですよね。だから、失敗したらいいんですよ。最初から完璧な設計なんて、どんな凄腕エンジニアでも無理です。ただ「データの構造をあとから変えるのは、だるい」、これだけ覚えておけば、ハマったときに「あ、これがあの話か」と思い出せる。それで十分です。
登場人物の整理
ここまで出てきた登場人物を、改めて並べます。
Claude Code / Codex みたいな開発支援AI
あなたの手元で、コードを書くのを手伝ってくれる相棒。設計のたたきも、コードそのものも、文言も、AIが一緒に作ってくれる。これがなかった時代に比べて、最初の「動くもの」までの時間が、10分の1とか、それ以下になった。
Vercel(のような、デプロイサービス)
あなたのコードを、世界から見える状態にしてくれる箱屋さん。サーバーの面倒を全部見てくれる。あなたはコードだけ書けばいい。
Supabase(のような、データベース＋認証サービス)
データの倉庫と、ユーザー認証の仕組みを、まとめて貸してくれる業者さん。「ログインする」「データを保存する」「データを取り出す」みたいなことを、お任せできる。
これらが組み合わさって、初めて「世界に公開された、データを持つアプリ」ができあがります。
Claude Code/Codexが「作る」を、Vercelが「公開する」を、Supabaseが「覚える」を、それぞれ担当している、と覚えるとシンプルです。
[図7: 役割分担の整理。AI=「作る」、Vercel=「公開する」、Supabase=「覚える」を、三つの箱で並べる]
地図を持っていると、AIに頼める精度が上がる
なんでこの地図を知っておくべきか。
ここを知らないと、AIに対して的確な指示が出せないんですよ。
たとえば「ログイン機能を追加して」と頼んだとします。AIは「どこに保存するのか」「どの認証方式を使うのか」「Supabaseと繋ぐのか別の方法か」みたいなことを、勝手に決めて作り始める。それが妥当な選択かどうか、判断できないと、後で困るかもしれません。
逆に、「Supabaseに繋いでメールアドレスでログインできるようにして、ユーザー情報のテーブル(=データの表)はこういう構造で」と指示できれば、AIは精度高く動いてくれる。
全体の地図を持っていることが、AIを的確に動かす条件なんですよ。「AIに任せれば全部やってくれる」じゃなくて、「地図を持っている人が、AIに正しく頼める」が現実です。
どこから学べばいいか
ここまで読んで、「もう少しちゃんと知りたい」と思った人へ。
おすすめは2つです。
ひとつは、Webエンジニアの入門書を一冊読むこと。プログラミングの本ではなく、「Webアプリケーション全体の仕組み」を扱う本。「Webを支える技術」とか「プロになるためのWeb技術入門」みたいな、ロングセラーの古典が何冊かあります。コードを書けるようになる必要はないけど、こういう本を一冊通せば、「あ、こういう仕組みで動いてるのね」という地図がだいたい頭に入ります。正直いきなり読んでも結構きついと思うので、このnote参考にしてもらったり、実際にAIに作らせるでいいので、何か作らせてから読んだ方がいいと思います。
もうひとつは、実際に小さく一個作ってデプロイすること。Claude Codeを開いて、Vercelに繋いで、Supabaseに繋いで、「ToDoリスト」みたいな小さいアプリを一個作って、世界に公開してみる。「ToDoリスト」で全然いいよ。全世界に公開しな。
やってみると、「あ、これが『デプロイ』ってやつね」「これが『データベースに保存する』ってやつね」と、頭の地図に色が付きます。
本だけだと抽象的、手だけ動かしても断片的。両方やると、立体になる。
とりあえずホムペでもいいです。
最後に
繰り返しになりますが、AIで何かを作ろうとしたとき、「動いた！」までは爆速で来れます。でも、「世界に見せる」「データを持つ」までは、地図がない人にはわりとハードルがあります。
逆に、地図さえあれば、その先も進めるようになる。コードは書けなくていい。でも、「自分のアプリは、今どの段階にいるのか」「次の段階に進むには、どのサービスを使うのか」がわかると、AIに頼める精度が一段上がります。
冒頭にも書いたとおり、「先に動かせて、後から仕組みを知れる」って、良い時代だなと思ってるんですよ。仕組みから入るのは退屈になりがちで、続かない。でも、自分が手で動かしたあのアプリが、裏でどう動いていたのかを知る、なら興味が持続する。読んでて「あ、これは自分が作ったあのアプリのあれか」と一個でも繋がる瞬間があったなら、その流れで一冊本を読んでみてください。一気に地図に色が付くはずです。
あと、今日は触れなかったけど大事な話もたくさんあります。セキュリティの話、キャッシュの話、データがすごく増えてきたときの話。どれも、ある段階を超えると一気に重みが増してきます。Webアプリの世界がもう一段深くなってからの話なので、今日は省きました。気になった方は、これも別の入門書を一冊読むなり、ハマったときに調べるなりして、自分のペースで進めてみてください。
それから、外に公開したり、データベースのようなミドルウェア(裏方のソフトウェアたち)を使い始めると、「開発環境」と「本番環境」、その間に「ステージング環境」を用意する、みたいな話も出てきます。本番のデータを触らずに、安全に試せる場所を別で持っておく、ということですね。これも、ある程度の規模感になってから本気で考える話なので、今日は触れていません。
「AIで誰でもアプリ作れる」みたいな雑な言い方ではなく、ちゃんとAIを使いこなしたい人にとっての、最初の地図として読んでもらえると嬉しいです。
