AIで作ったアプリの、動く場所を知る

この記事の目次

AIに予約アプリを作ってもらいました。日付を選ぶと予約できて、一覧にも出ます。画面が動くと、完成した感じがします。

でも、その予約はどこに保存されているのでしょう。自分のブラウザだけ？公開先のサーバー？別のデータベース？画面が同じでも、保存先や利用者を確かめる場所は違います。

この記事は、AIでアプリを作り、公開や実データの利用を考え始めた人に向けたものです。サービス名を丸暗記する前に、画面・処理・保存・外部サービスを分けて、情報の動きをたどります。

AIでアプリが動くところまで作れたら**画面はできた。保存したデータは、どこにある？**

まず、4つの役割を分ける

ブラウザは、利用者の端末で画面を表示し、操作を受け付ける場所です。ブラウザで動くコードや、そこへ届くデータは、利用者の側に渡ります。

サーバーは、要求を受けて処理する運営側の仕組みです。データベースは、予約やメモなどの記録を保存・検索します。外部APIは、決済やAIなど、別サービスの機能を呼び出す入口です。

4つの役割で、アプリの構成を読む

ブラウザ：画面
利用者の端末。操作を受け付け、届いたデータを表示。
サーバー：処理
要求の条件を確認し、結果を返す。
DB：保存
予約やメモなど、残す記録を管理。
外部API：別の機能
決済やAIなどのサービスへ処理を頼む。

同じ提供元が複数の役割を担う場合もあります。物理的な台数の図ではありません。

これは4台のコンピューターが必ず必要という意味ではありません。同じ事業者が複数の役割を提供したり、サーバーレス関数のように処理の実行をサービスへ任せたりします。「サーバーレス」でも、利用者の端末以外で処理する役割がなくなるわけではありません。

役割で分けると、どの会社のサービスを使っていても、「何をどこで確かめるか」を考えやすくなります。MDN：クライアントとサーバーの概要

予約ボタンを押したあと、何が起きる？

ブラウザが「この時間に予約したい」と要求を送ります。要求は、処理をお願いするデータです。サーバー側は、本人・予約可能な時間・重複などを確認し、保存できたかを応答します。応答は、その処理結果です。

予約ボタンの先を、要求と応答でたどる

要求を送る
利用者の画面から、予約したい時間を送信。
条件を確かめる
本人、空き時間、重複などを処理側で確認。
保存して結果を返す
保存先の結果を受け、画面へ成功や失敗を返す。

典型的な構成の一例です。画面上の成功表示と、保存結果を対応させます。

ブラウザ側の入力チェックは、使いやすくするためにも役立ちます。ただし、画面で選べない値が、別の送信経路でも必ず拒否されるとは限りません。保存する側でも条件を確かめます。

また、「保存しました」と表示するタイミングにも違いがあります。処理結果を受け取る前に表示する作りなら、通信に失敗しても画面だけ成功に見えることがあります。再読み込みや別端末でも結果が残るか、実際に保存先へ反映されたかを確認します。

返す項目を絞ると、ブラウザへ届くものが変わる

架空の予約に、運営側だけで使う内部メモが付いているとします。内部メモを表示しなくても、データ全体を返したら利用者の端末には届きます。

この例はメモリ上だけで動きます。通信も予約の保存も行いません。認可を済ませた後に、どの項目を返すかという一部分の例です。

const booking = {
  id: "demo-1",
  time: "10:00",
  internalMemo: "架空の運営メモ",
};
const response = { id: booking.id, time: booking.time };
console.log("返す内容:", JSON.stringify(response));
console.log("内部メモが含まれる:", "internalMemo" in response);

返す内容: {"id":"demo-1","time":"10:00"}
内部メモが含まれる: false

この例では、ブラウザへ返すデータに内部メモを選んでいません。ただし、予約を読む本人の権限を確認する仕組みは別に必要です。項目を絞ることだけで、他人の予約を返してよいことにはなりません。

「表示しない」と「渡さない」を分けよう。

画面から見えなくしても、配信したコードや通信データに残ることがあります。秘密や内部用の情報は、端末へ返す前の設計で考えます。

保存先が違うと、残り方も違う

練習用のアプリでは、画面のメモリだけに保存していることがあります。再読み込みで消えるなら、その可能性があります。ブラウザ内の保存領域を使えば残る場合もありますが、別の端末へ自動で引き継がれるとは限りません。

データベースへ保存するなら、複数端末から利用する仕組みを作れます。その分、利用者ごとの権限、バックアップ、保存期間も考えます。画像ファイルはDBと別のストレージに置く構成もあります。

「残った」の場所を分ける

画面のメモリ
再読み込みすると失われる場合がある。
ブラウザ内の保存領域
同じ端末で残っても、他端末へ引き継ぐとは限らない。
DB・ファイル保存サービス
権限、バックアップ、保存期間を管理する。

保存方式の比較です。上から順に全方式へ保存する処理ではありません。

ブラウザからデータサービスへ直接つなぐ構成もあります。この場合は、そのサービスの認可ルールが重要です。自前サーバーを1台挟めば自動で安全になるわけでも、直接接続ならすべて危険というわけでもありません。OWASP：認可を強制する場所

手元・プレビュー・本番は、名前より接続先を見る

開発環境は、作って試す場所。プレビューは、変更を確認するための公開先。本番は、実際の利用者が使う環境です。同じコードでも、接続するDBやAPIの設定が違うことがあります。

「プレビュー」という名前でも、公開URLを知る人が見られる設定や、本番のDBへ書き込む構成なら、その影響があります。逆に、本番用の画面を開いていても、古い版が動いている可能性があります。

画面が似ていても、接続先が違う

開発・プレビュー
テスト用DB、テスト用API、確認用URLかを調べる。
本番
実利用者のデータ、課金、メール送信への影響を確認。

名称だけで安全性を決めず、実際の接続先と公開範囲を見ます。

確かめるのは、公開URL、接続先のプロジェクト、使うキーの種類、公開範囲です。秘密の値そのものを一覧へ書き出す必要はありません。決済やメールも、テスト用の接続先かを別に見ます。

Node.jsやPHPは、この処理を動かすための実行環境として登場します。自分で版を指定するのか、ホスティング側が管理するのかを確認すると、更新の担当も決められます。Node.jsの教材やPHPの教材は、その先の確認に使えます。

非公開という表示だけでは分からなかった事例

分類：脆弱性の公表。 2025年7月29日公表のBase44の報告では、非公開アプリへの登録・認証の制限に問題がありました。報告を受けて修正され、提供元は悪用の証拠はなかったと説明しています。Wizの一次報告

この事例から、すべてのAI開発基盤に同じ問題があるとは言えません。構成を理解する理由は、利用者側が表示を見て安心するだけでなく、どの処理・提供元が制限を担うかを確かめるためです。

自分のアプリは、3つの視点で調べる

作る人：構成の見取り図を作る

画面・処理・保存・外部サービスを書き、対応するサービス名を置きます。AIへ説明を頼むなら、「どのファイルや管理画面を根拠にしたか」「何が未確認か」「秘密の値は表示しないで」を添えます。推測した構成と、実物で確認した構成を分けます。

公開する人：環境と接続先を照合する

公開する版、URL、DBのプロジェクト、テスト用/本番用のAPIを照合します。ログアウトした自分の別ブラウザから公開範囲も確認します。メール送信や課金の確認は、提供元のテスト機能を使う方法から検討します。

運用する人：更新と復旧の担当を決める

ホスティング、DB、認証、外部APIの契約と管理者を整理します。コードを戻す方法と、利用者のデータを戻す方法は別に確認します。サービスの停止・上限到達・認証期限切れを、どこで知るかも決めます。

全部を自分で作る必要はない。でも、担当は分かるように。

提供元に任せる機能でも、利用者側で設定する権限や公開範囲は残ります。「サービスがやる」と「自分が設定する」を分けると、相談する相手も見つかります。

構成が分かったと判断するための確認

役割： 画面・処理・保存・外部APIの担当サービスを、自分の構成に対応付けた。
情報： ブラウザへ返す項目と、運営側だけで扱う項目を分けた。
権限： データを返す・保存する側で、本人と操作の許可を確認する場所が分かる。
環境： 開発・プレビュー・本番のURLと接続先を照合した。
運用： 更新、料金・障害の確認、コードとデータの復旧の担当が分かる。

次は、秘密と利用者のデータを守る

設定値がどこへ届くかはAPIキーの教材へ。本人だけのデータを返す仕組みはログインと権限へ進みます。構成の見取り図を横に置くと、「どこを確認する話か」を見失いにくくなります。

一次資料

情報確認日：2026年10月24日。構成によって必要な設定は変わります。本文の予約アプリとコードは独自の架空例です。

MDN：クライアントとサーバーの概要 — 要求・応答と役割。
OWASP：認可 — 権限を判断する場所と原則。
Wiz：Base44の脆弱性報告 — 事例の確認範囲と修正。
Vite：環境変数とモード — ブラウザへ渡る設定と環境の具体例。

書いた人

月ねこ｜Tsukineko

マーケティングの現場から、AIをつくり、仕事で使う側へ。実際に試したことや、つまずいたことを、図解と具体例で伝えています。

プロフィール・発信先 →著作権・利用条件 →

この記事のURL：https://nekoai-lab.github.io/ai-security-playbook/learn/app-architecture/

続けて読む

シリーズ · 全14記事のうち3記事目

次に読むAIに「APIキーを設定して」と言われた。どこに入れるのが正解？はじめて外部サービスをつなぐ人へ。.envの設定がブラウザに届く仕組みを、要約アプリの図とダミーコードで確かめる。

読む順番・ルートを見る

AIで作って公開する基本

アプリの仕組みの教材へ戻る →

この教材のソース・修正提案 ↗