AIでアプリを作るぞ、作ってるぞというみなさん
「アプリ」「ソフト」「システム」——なんとなく使ってるけど、違いを説明できますか？

この記事では、そもそもアプリって何？ から、Webアプリがどう動いているかまでを、一番やさしくまとめます。

そもそも「アプリ」って何？

パソコンやスマホを動かしているのは、ソフトウェア（＝コンピュータへの命令のかたまり）です。よく聞く言葉を、ざっくり整理すると：

ソフト、ソフトウェア：プログラム全般をまとめた、一番大きい言い方
OS（基本ソフト）：機器全体を動かす土台（Windows / iOS / Android）、最近のシステムではあまり意識することないと思います。
コンテナ（Docker等）：アプリを「箱」にまとめて、どのOS上でも同じように動かす技術（普段あまり意識しないかも。念のため）
PaaS / SaaS：自分でOSやサーバを用意せず、借りて使う形。SaaS＝完成したサービスをそのまま使う（Gmail等）／PaaS＝アプリを動かす土台だけ借りる（後で出てくるVercel等）
アプリ、アプリケーション（応用ソフト）：OSの上で、目的ごとに使う道具（LINE、Excel、ゲーム）今回説明するものです。イメージとしては、作業をまとめたものです。本を作るや説明用資料を作成するときに印刷、ホッチキスで止める、KINGS NOTEのようなものに入れて閉じる。このような流れをお願いすれば全部やってくれるのがアプリです。
ツール：作業を助けるための道具です（ざっくりアプリの一種）イメージとしてはハサミなどの特定の作業に効率化されたものです。上記のアプリの例でいくとホッチキスがツールですね。
システム：アプリ・サーバ・DB…が連携した「仕組み全体」、会社ともいえますね。こんなものができますというのを統合したものですね。受諾から商品の送付までを担当しているようなイメージです。

かなり絞ったのですが多いですね・・・

以下に、上記の関係をイメージにしました。OSという土台の上に、アプリやサーバ・DBが乗り、それらが連携した全体が「システム」、というイメージです。

最近受けた質問で、**OSってなんで必要なの？**という質問がありました。
このイメージを見るとわかると思います。
基本的に全ての土台部分で、みなさんが意識することないので、確かにわかりにくい部分もあると思います。
そもそもOSはキーボードやマウス、液晶を使ってCPUやGPUを使い作業できるようにしてくれたものなので、これがないと私たちは機械に「０と１」で表現したコードを渡さないといけなくなります。
HPやアプリも基本的にOS上で動いているので、OSは必ず必要ということになります。
みなさんが使用しているサービス（アプリやHP）は全てPCに繋がってるんだなと思っておいていただければOSが必要な意味もわかるのではないかと思います。

話はそれましたが、つまりアプリ＝「ソフトウェアの中で、私たちが目的のために直接使うもの」。この記事の主役です。

アプリは2種類ある

アプリには実は使い方で2種類に分かれます。

ネイティブアプリ：アプリストアからインストールして使う（例：LINE、Instagram）。端末の中で動くので動作が速く、カメラ・GPS・通知・オフラインに強い。基本的になんらかのOSの上で動くので処理は早いです。がOS毎に作ったりすると細かいバージョンアップのたびに色々な検証が必要なので、すごく大変です。OSバージョンアップのたびに色々なアプリが使えないなどのYAHOO NEWSが出るのはこのためです。色々テスト頑張ってるのですが、皆様にはご迷惑をかけてすみません・・・
Webアプリ：ブラウザでURLを開くだけで使う（例：Gmail）。インストール不要、更新がすぐ全員に反映、リンクで共有しやすい。ただし基本は通信が前提。ブラウザさえあればいいので、互換性が強いです。お客様としてはアプリの方が専用のインターフェース（画面）になっているので使いやすいと感じる方も多く、ブラウザのみだと人が離れていく可能性があります。ただブラウザもスマホ系とPC系のやつでもあるのでどんどん増えてきてます。もう増えないでーーー！

ざっくりの使い分け：速さ・端末機能ならネイティブ／手軽さ・更新のしやすさならWeb。（※両者の"いいとこ取り"を狙う PWA という形もあります）

この記事で扱うのは「Webアプリ（ブラウザで開く方）」。これがどう動いているか、を見ていきます。

全体像

Webアプリは、レストランのイメージが近いです。

用語	役割（レストランでいうと）
フロントエンド	お客さんから見える「ホール・メニュー・接客」（画面の見た目）
バックエンド	裏の「厨房」（注文を受けて調理＝処理する）
Webサーバ	入口の「受付・ウェイター」（注文を受け取り、厨房に渡し、料理を運ぶ）
データベース（DB）	「倉庫・冷蔵庫」（食材＝データを保管しておく場所）
API	「注文票」（ホールと厨房がやり取りする決まった書式）

レストランで注文が流れる順に並べると、以下です：
お客さん（フロントエンド）→ 入口の受付（Webサーバ）→ 厨房（バックエンド）→ 倉庫・冷蔵庫から食材（DB）。そして厨房とホールは 注文票（API） でやり取りし、できあがった料理がお客さん（画面）に返ります。

この地図を頭に置くと、これからの説明がわかりやすくイメージできると思います。

少しそれますが、上記の全てをまとめられるコンテナ技術というものもあります。細かいことは次回にでも記載しますが、
ざっくりいうと厨房の人（バックエンド）、ホールの人（フロントエンド）、冷蔵庫や全体の設計を定義しておき、特定のOSの上にそれを展開すればどこにでも展開できるというものです。フランチャイズ化が簡単にできるようなイメージですね。

フロントエンド＝お客さんから見える「ホール」

ブラウザに表示される、目に見える部分です。ボタン・文字・画像・入力フォームなどユーザーが直接触るところ全部です。お客様に直接触れたり、見える部分なのでここのデザイン性が一番重要と言っても過言ではありません。店前の商品イメージなどもお客様の注文意欲を掻き立て、たくさん来てもらうためにとても重要な部分です。

使う言語：HTML（骨組み）／CSS（見た目）／JavaScript（動き）
役割：見た目を作る＋ユーザーの操作を受け取って、裏（バックエンド）にお願いする

バックエンド＝裏の「厨房」

ユーザーには見えない、裏で処理する部分です。「ログインできるか確認」「データを保存」「検索結果を作る」など、頭脳の仕事。ここは調理なので見えない部分ですが、スピード感や品質が求められます。イメージ写真と違うや、注文してから1時間以上かかるようなものは今後お客様がきてもらえない可能性もあるので、明確な基準を作る部分です。ここはお金さえかければ大抵良くなるのですが、なるべくお金をかけずに処理を早くしていきたいという課題を常に持っています。

使う言語：Python／JavaScript（Node.js）／Java／Ruby／PHP／Go など
役割：フロントからの注文を受けて、データベースを読み書きし、結果を返す

ポイント：フロントが「お客さんに見せる係」、バックが「裏で考えて動く係」。この2つを繋ぐ部分を**API（注文票）**でやり取りします。

Webサーバ＝注文を捌く「受付・ウェイター」

ブラウザからの「このページちょうだい」を最初に受け取るのがWebサーバです。
ここは決まった形で注文が来ているかを確認するためのものです。ハンバーグ屋さんなのに、フルーツ盛り合わせなどのメニューが来たら困りますよね。それをチェックして、厨房（バックエンド）に流すのが仕事です。
WEBサーバには代表的なものが2つあり：

Apache（アパッチ）：オールマイティ。なんでも平均的にこなす。動的な処理（PHP等、PHPは日本ではまだかなり使われている技術です。衰退傾向なので、細かくは記載しないですが、画面内でオンラインに近い処理を実現したりするものです。）を直接さばくのが得意。1リクエストに1プロセスで対応。
Nginx（エンジンエックス）：静的ファイル配信・リバースプロキシ・ロードバランサに特化。少ないメモリで大量のリクエストを並列にさばくのが得意。今はこちらが主流。

リバースプロキシとは：受付が注文を受けて、奥の厨房（アプリケーションサーバ）に取り次ぐ仕組み。Nginxが入口に立ち、実際の処理は裏のアプリに回す——という構成がよく使われます。
ここはレストランの例だとよくわからないかもしれないですが、厨房が二つあるや二人のシェフがいて同じ人だけに依頼するのではなく一回目の注文は一人目、二回目の注文は二人目と負荷が分散するようにするものです。

そもそもみなさんがAIでアプリ作ると上記の二つすら出てこないと思います。
それはSaasなどの技術でNginxなどの土台の上にファイルを直接置かせてもらうことで外部に公開できるようにしているからです。その代わりNginxを動かしている分のお金を払っているようなイメージです。

データベース（DB）＝倉庫・冷蔵庫

データ（食材）を保管しておく場所です。ユーザー情報・投稿・購入履歴など、アプリが扱うデータは全部ここに貯めます。バックエンド（厨房）が必要に応じて出し入れします。
タブレットなどで管理している場合は、商品情報などもここに入れてます。一日何回までの注文はOKなど、制御するためにも必要だったりします。

種類：MySQL・PostgreSQL（表形式＝RDB）／MongoDB（柔軟なドキュメント型）／Redis（高速なキャッシュ）
役割：データを安全に保管し、必要なときに渡す

API ＝注文票

フロントとバックが「決まった書式」でやり取りするための窓口です。ホールが厨房に渡す"注文票"のイメージ。これがあるから、画面側（フロント）と処理側（バック）が混乱せずに連携できます。
厨房に不必要な情報を制限するために使用したりします。ハンバーグランチひとつ欲しいだけなのに、厨房に値段やお客様の情報、服装などいらないですよね。

形式：REST（定番）／GraphQL（必要な分だけ取る）
役割：フロントの「これちょうだい」を、バックに正しく伝える

私がAIに作らせると、だいたいこの構成

Cursor、ClaudeCode、Codex などでAIにWebアプリを作らせると、ほとんどが以下の組み合わせになります（私のプロンプトのせいかもしれないので、参考までに）：

Next.js（React）＋ Tailwind CSS ＋ Supabase（DB・認証）＋ Vercel（公開）

フロント＝Next.js＋Tailwind、バック＆DB＝Supabase、公開＝Vercel
Next.js＋TailwindとはJavaScriptというプログラミング言語の派生でできたTypeScript（JavaScriptの型付き）という言語の拡張機能です。最近のモダンなサイトはReactと言ってもいいくらい流行ってます。
SupabaseとはBaaS（Backend as a Service）の一つです。（PaaSでもSaaSでもないです・・・）Webアプリやネイティブアプリの裏側（サーバー、データベース、認証など）の機能をパッケージ化して使いやすくしてくれているものです。
VercelとはWebアプリケーションをインターネット上に公開・運用するために特化したPaaSです。
違う構成の場合は、作成したAIに聞いてみるのがいいですね。どんな構成でアプリ作成したのかと聞けば教えてくれます。

（※それぞれの言語・フレームワークの中身＝Django／FastAPI／React／Vue…の使い分けは、情報量が多いので**次回の「フレームワーク・言語編」**でまとめます）

「npm run dev」叩いたことありますか？

で、この構成でAIに作ってもらうと、だいたい「npm install ~~~」とか「npm run dev を実行して」と言われます。叩くと「http://localhost:3000」にブラウザでアクセスすると作成したアプリが見れます。
細かいことは言語やフレームワーク毎に書きますが、これは内部用にしか見えないので、外部からのアクセスはできません。

どうやって外部からのアクセス、公開されているのか

そもそもみなさんがブラウザから開いたlocalhostというのは自分自身ということです。
これを他の人が見たときにXXXアプリとわかる場所に置かないといけません。
そのためにSaaSなどがIPアドレスと名前解決（DNSの設定）を設定することにより公開が可能となります。

必ず実施して欲しいこと

ここはかなり重要だと思います。
環境は必ず本番環境と内部用の開発環境を作っておいてください。
具体的には、最低でも環境を2つに分けます：

本番環境：お客さんが実際に使う、世界に公開された環境
開発（検証）環境：自分たちだけが触る、テスト用の環境

いきなり本番をいじると、お客さんの目の前で壊れます。検証環境で試す → 問題なければ本番へが鉄則。AIで作ってそのまま本番に直結、は事故のもとなので気をつけたいところです。

Githubというファイル置き場（リポジトリ）

アプリのコードを保存し、変更履歴を残して、いつでも前に戻せる場所です（"リポジトリ"＝コード置き場）。レストランでいえば、レシピ帳をみんなで共有して、変更点を記録しておくノートのイメージ。

チームで同じコードを共有でき、「誰がいつ何を変えたか」が全部残る
GitHubに push（アップロード）すると、Vercel等が自動で拾って公開、という連携もできます（だから"コードを置く場所"が、そのまま公開の起点になります）
コミット／PR／レビューなどの具体的な使い方は、別記事で詳しく扱います

それを支える技術（その他）

DB・APIは上で説明したので、残りをざっと：

インフラ：動かす土台。Linux（OSの一種）サーバ、Docker（コンテナ）、クラウド（AWS/GCP/Azure）
認証：ログインの仕組み（トークン＝入館証。これは別記事で）

サーバあり構成 vs サーバレス

動かし方には、大きく2つあります。

① サーバあり（従来型）
自分でサーバ（EC2・VPS等）を立てて、Nginx＋アプリ＋DBを常時稼働させる。

自由度は高いが、サーバのお守り（OS更新・セキュリティパッチ・障害対応）が必要。
使っていなくても、立てている間は固定費がかかる。

② サーバレス
サーバを自分で持たず、クラウドにコードだけ置く（AWS Lambda・Vercel・Cloudflare Workers等）。リクエストが来た時だけ実行される。

サーバ管理はクラウドが肩代わり。アプリ開発に専念できる。
使った分だけの変動費。

上記の「Next.js（React）＋ Tailwind CSS ＋ Supabase（DB・認証）＋ Vercel（公開）」はサーバレス構成です。こちらでサーバを作成せずに中身だけ使わせてもらっている使い方です。特別なことがない限り今後はこちらが主流になると思います。

たとえ：自家用車（自前サーバ＝駐車場代・整備が常にかかる）／レンタカー（IaaS＝借りるが運転は自分）／タクシー（サーバレス＝乗って行き先を言うだけ。運転も管理もお任せ、料金は乗った分だけ）。

全体の流れ（リクエストの旅）

「ボタンを押してから画面が出るまで」を1本に繋ぐと：

ユーザーがボタンを押す（フロント）
Webサーバが受け取り、バックエンドに取り次ぐ
バックエンドが処理し、必要ならDBを読み書き
結果をフロントに返す → 画面が更新される

まとめ

フロント＝見える係（HTML/CSS/JS）、バック＝裏で考える係、Webサーバ＝受付
両者はAPIでやり取り、データはDBに保管
公開はSaaS（IP/DNS）が肩代わり、環境は本番／開発を分ける
いまAIに作らせると Next.js＋Tailwind＋Supabase＋Vercel が定番
作る時の npm run dev（簡易サーバ） ≠ 本番のWebサーバ

今後書く予定

このシリーズの続きで、こんなテーマを書いていきます：

フレームワーク・言語編（Django／FastAPI／Express／Rails／Laravel、React／Vue／Angular／Next.js の使い分け、npm install・アプリサーバ＝Gunicorn/WSGI など）
言語ごとの簡単なAPI・チートシート
DB操作（SQL・ORMの基本、CRUD）
入力の枠（フォーム）の追加と、バリデーション（入力チェック）のやり方
認証トークンの仕組みと扱い方（ログイン状態をどう保つか）
安全な通信とは（HTTPS/TLS、なぜ暗号化が要るか）
そもそもセキュリティとは何か？（何から、何を守るのか）
GitHubの使い方（コミット・PR・コードレビューのポイント）
そもそもサーバーって、なんで必要なの？（非エンジニア向けに、サーバーが要る理由）

ここまで読んでくれてありがとうございます。
分からなかった所・もっと知りたい所があれば、気軽にコメントください。 次回以降の参考にします。