AIで作ったアプリの中身：非開発者のためのツアー
AIアプリビルダーで何かを出して、自分が見ているものを理解したいなら、ここに各パーツの親しみやすいガイドツアーがあります — 専門用語なしで。
説明を打ち込み、実行を押すと、20分後には動くアプリが手元にありました。すばらしい。でも今、「ファイルを表示」をクリックして、別の言語で書かれたように見えるフォルダのツリーをじっと見ています。package.json って何？なぜ node_modules の中に40個もあるの？「スキーマ」って何で、なぜ自分はそれを持っているの？
この記事は、ガイドツアーです。チュートリアルではなく — ツアーです。読み終えても、これらのファイルを自分で書く方法は分からないでしょう。でも、次に何かが変に見えたとき、アプリのどの片隅を指せばいいかが分かるようになります。
抽象的なパーツに、何か具体的なものをくっつけられるように、この記事を通して3つの実例を使います。
- Maya、マーケティングのリーダーで、チームのために紹介ランキングを作った。
- Jordan、ヨガの先生で、クラスの予約サイトを作った。
- Sam、パン屋を営んでいて、「明日のクロワッサンを予約注文」ページを作った。
3人ともAIアプリビルダーを使いました。3つのアプリは、顧客にはまったく違って見えます。でも内側では、驚くほど似た形をしています。
フロントエンド：顧客が実際に目にするもの
フロントエンドは、誰かのブラウザに読み込まれるすべてです。ボタン、レイアウト、フォント、アニメーション、送信したあとにフォームがひとりでにクリアされる様子。目に見えるなら、それはフロントエンドです。
Maya にとって、フロントエンドは順位・名前・紹介の数を載せたランキングです。Jordan にとっては、「予約」ボタンつきのクラスのカレンダーです。Sam にとっては、それぞれの横にプラスとマイナスの小さなボタンがついた、お菓子のリストです。
プロジェクトの中で、フロントエンドはたいてい app/、pages/、src/ といった名前のフォルダに住んでいます。.tsx や .jsx で終わるファイルが見えるでしょう。それぞれが、おおざっぱに「1つの画面」か「画面の1つの部品」です。ランキングの行は1つのファイル。ヘッダーは別のファイル。それらをすべて結びつけるページは3つめのファイルです。
AIビルダーに「ボタンをもっと丸くして」とか「ランキングを右に動かして」と頼むとき、変わるのはこの部分です。
バックエンド：考える部分
バックエンドは、誰も見ないけれど、誰もが頼っている部分です。それはどこか別の場所で — 顧客のブラウザではなく、サーバー上で — 動くコードで、顧客のブラウザだけに任せて信頼すべきでない何かが起きる必要があるときに動きます。
なぜブラウザにすべてをやらせられないのか？ブラウザは顧客のマシンであり、信頼できないからです。Maya のランキングが、紹介の数を純粋にブラウザの中だけで更新していたら、誰でも右クリックして自分に9,000件の紹介を足せてしまいます。だからバックエンドが、ルールの住む場所です。「この人はこれはできるが、あれはできない」「これを実際にデータベースに保存する」「このメールを送る」。
バックエンドはたいてい api/、server/、app/api/ という名前のフォルダに住んでいます。そこのファイルはたいてい短いものです。それぞれが特定のリクエストを処理します。「予約を作る」「今日のクロワッサンを一覧する」「紹介を足す」。
アプリの中で何かが動くのに、その結果が残らないとき — 送信をクリックして、確認を見たのに、翌日にはデータが消えている — バグはほぼ必ずバックエンドにあります。
データベース：アプリの記憶
アプリの記憶を、ずらりと並んだ書類キャビネットだと思ってください。各キャビネットには、前面にラベルがついています。1つは「users」。1つは「bookings」。1つは「croissant_orders」。各キャビネットの中で、すべての引き出しが1つの行です。すべての引き出しは、同じ枠のセットを持っています。名前、メール、created_at、ステータス。
その構造 — 「どんなキャビネットがあるか、各行がどんな枠を持つか」 — はスキーマと呼ばれます。プロジェクトの中でいちばん重要なファイルです。たとえ、おそらくいちばん退屈な見た目のものでも。schema.ts、schema.prisma といった名前のファイルか、db/ や migrations/ という名前のフォルダの中の何かを探してください。開いてみましょう。アプリがこの世界について実際に覚えていることを映した、リストが見えるはずです。
Jordan のスキーマには classes テーブル、bookings テーブル、users テーブルがあります。Sam のには products、orders、order_items。Maya のには members と referrals。スキーマの形は、プロダクトの形です。だからこそ、あとでそれを変えるのは、ボタンの見た目を変えるより難しいのです。
役に立つ技：アプリが何を覚えているかを平易な言葉で説明できれば、たいていスキーマを説明できます。「各顧客の名前とメールを覚えている。各顧客について、彼らが出した注文を覚えている。各注文について、どのお菓子を、それぞれ何個かを覚えている。」その文は、ほぼ一語一語、スキーマです。
認証：ドアの用心棒
「認証（Auth）」は、2つの言葉を1つにしたものです。*authentication（あなたは誰か？）とauthorization（あなたは何を許されているか？）*です。両方ともたいてい、auth/ という名前のフォルダの中の小さなファイルのセット、あるいは、聞き覚えがあるかもしれない名前のサービスによって処理されます。Clerk、Auth0、Supabase Auth、NextAuth。
2つの問いは別物です。Authentication はこう答えます。「これは本当に Maya か？」 — たいていパスワード、Google ログイン、彼女にメールされたマジックリンクで。Authorization はこう答えます。「Maya は他人の紹介を削除することを許されているか？」 — そして、最初の1週間のほとんどのAIで作ったアプリにとっての正直な答えは、「チェックするのを忘れていた」です。
これは、いちばんよく静かに壊れている部分です。ログイン画面は動くので、安全に感じられます。でもバックエンドは、ログインしている人が、読もうとしているデータの持ち主と同じ人であることを、いつも確かめているとは限りません。アプリに「自分のデータ対あなたのデータ」という概念が少しでもあるなら、AIビルダーにはっきり頼みましょう。「ユーザーが自分のデータだけを見て編集できるようにして。」 そのたった1つの文が、欠けているチェックをどれほど頻繁に明らかにするか、驚くはずです。
連携：自分で作っていないのに使っているもの
ここが、ほとんどの非開発者が、実際に起きていることを過小評価する場所です。Sam の「クロワッサンの準備ができました」メールを送るものは、コードではありません — SendGrid や Resend のアカウントです。Jordan のクラスの決済を処理するものは、コードではありません — Stripe です。Maya のランキングの写真をホストするものは、コードではありません — S3 や Cloudinary のようなストレージサービスです。
各連携は、2か所に現れます。バックエンドに、「ねえ Stripe、このカードに請求して」と言う小さなコードの塊があります。そして、Stripe に対して、リクエストが見知らぬ人ではなく Sam のパン屋から来たことを証明する、鍵 — 長い秘密の文字列 — があり、どこか安全な場所（たいてい、誰も決してコミットすべきでない .env という名前のファイル）に保存されています。
アプリが突然メールを送らなくなったり、決済を受け付けなくなったりする理由を不思議に思ったら、原因はほぼ必ず次のどれかです。鍵の期限切れ、使用上限に達した、連携のポリシーの変更。コードは壊れていません。握手が壊れたのです。
デプロイ：それがインターネットに届く方法
最後のパーツは、ディスク上のフォルダを、顧客がURLで訪れられるものに変える部分です。これはたいてい、3つの小さなものが協力して動くことを意味します。
- ホスト：Vercel、Netlify、Fly、Render のようなサービスで、バックエンドを動かし、フロントエンドを配信します。
- ドメイン：
mayas-leaderboard.comのような名前で、ホストを指します。 - ビルド：散らかったソースファイルを、実際に動く、より無駄のない、より速い版に変えるレシピです。
何かがローカルでは動くのに本番では壊れるとき、たいていここに問題があります。あなたのノートパソコンには設定されているがホストにはない鍵。開発ではインストールされているが本番ではないライブラリ。ブラウザには存在するがライブのサイトにはないデータベース。
元が取れる、5分の習慣
プロジェクトの中のすべてのファイルを読む必要はありません。そのほとんどが何をするかを知る必要もありません。でも、週に一度、上のフォルダをそれぞれ開いて、AIビルダーに平易な言葉で何が変わったかを尋ねる、5分の見回りはすべきです。
Maya はこれを毎週金曜の午後にやっています。彼女はこう打ち込みます。「今週、スキーマで何が変わって、なぜ？」 そして「このアプリに、私が頼んでいない新しい連携はある？」 答えはほとんどいつも安心できるものです。そうでない数少ないときに、彼女はまだ小さいうちに問題を捕まえます。
それが、各パーツを理解することの目的すべてです。開発者になるためではありません。ただ、より良い質問ができるようになるためです。
次に行く場所
このツアーが役立ったなら、2つのフォローアップに時間を割く価値があります。「見た目は問題ない」バグ は、これらのパーツの1つが静かに壊れているときどうするかをカバーし、デモ対応 対 本番対応 は、アプリが最初の段階から2番目の段階へ移ったかをどう見極めるかをカバーします。同じ地図、違う使い道です。