WebアプリにDatabaseを追加する

前のチュートリアルでは、AIと一緒にWebサービスを作り、GitHub・Vercelを使ってインターネットへ公開する流れを学びました。

次は、WebアプリへDatabaseを追加して、入力したデータを保存できるようにするところまで進めます。

入力
↓
Webアプリ
↓
Databaseへ保存
↓
あとから取得
↓
画面へ表示

Databaseが使えるようになると、Todo、予約、顧客管理、投稿、会員サービスなど、より本格的なWebアプリを作れるようになります。

今回作るもの

前回作ったシンプルなアイデア整理アプリを拡張します。

これまではページを更新すると入力したアイデアが消えていました。

今回はDatabaseへ保存して、再びページを開いてもデータが残る状態にします。

これまで

入力
↓
画面に表示
↓
ページ更新
↓
消える

今回

入力
↓
Databaseへ保存
↓
ページ更新
↓
Databaseから取得
↓
残っている

Databaseとは？

Databaseは、Webサービスで使うデータを保存・管理するための仕組みです。

たとえばアイデア整理アプリなら、次のような情報を保存できます。

• タイトル
• 本文
• 作成日時
• ID

Todoアプリならタスク、予約サービスなら予約情報、CRMなら顧客情報などを保存します。

今回使うNeonとは？

このチュートリアルでは、PostgreSQLを利用できるクラウドDatabaseサービスのNeonを例に進めます。

WebアプリからNeonへ接続することで、インターネット上のDatabaseへデータを保存できます。

Webアプリ
↓
Database接続
↓
Neon
↓
PostgreSQL
↓
データ保存

Neonの基本を先に確認したい場合はこちらから学べます。

Neonの基本を見る →

STEP 1：保存するデータを決める

Databaseを作る前に、何を保存するか決めます。

今回保存するのはシンプルに4項目です。

Idea

id
タイトル
本文
作成日時

最初から大量の項目を作る必要はありません。

必要になったら後から追加できます。

STEP 2：AIにデータ設計を整理してもらう

Database設計が分からない場合も、まずAIへ相談できます。

Web開発初心者です。

アイデア整理アプリへ
Databaseを追加したいです。

保存したい情報:
・タイトル
・本文
・作成日時

Neon PostgreSQLを使う予定です。

まずDatabase設計を考えてください。

まだコード変更はしないでください。

次を説明してください。

1. 必要なテーブル
2. 必要なカラム
3. 各カラムの役割
4. IDの考え方
5. 作成日時の扱い
6. 初心者が注意すること

いきなりAIへDatabase変更をさせず、最初に設計を確認します。

STEP 3：NeonでDatabaseを用意する

Neonでプロジェクトを作り、Webアプリから接続するDatabaseを用意します。

作成すると、Databaseへ接続するための情報が発行されます。

Neon

Project
↓
Database
↓
接続情報
↓
Webアプリから利用

管理画面の名称や操作方法は更新されることがあるため、実際の画面や公式ドキュメントも確認しながら進めましょう。

STEP 4：Connection Stringを確認する

WebアプリからDatabaseへ接続するには、接続先・ユーザー・パスワードなどを含む接続情報が必要です。

一般的に、次のような形式の文字列を使います。

postgresql://USER:PASSWORD@HOST/DATABASE

これをConnection Stringと呼ぶことがあります。

STEP 5：DATABASE_URLとして管理する

Database接続情報をコードへ直接書くのではなく、環境変数として管理します。

よく使われる名前の1つが、

DATABASE_URL

です。

ローカル開発では、プロジェクトによって .env や .env.local などに設定します。

DATABASE_URL="YOUR_DATABASE_CONNECTION_STRING"

記事やAIへの質問では、実際の値を公開せず伏せて扱いましょう。

STEP 6：.gitignoreを確認する

秘密情報を保存しているファイルをGitHubへPushしないようにします。

.gitignore を確認し、環境変数ファイルがGitの管理対象から外れているか確認します。

.env
.env.local

など、実際に使っているファイルを確認してください。

git status

でも、秘密情報を含むファイルが誤って追跡されていないか確認できます。

STEP 7：Databaseへ接続する方法を決める

WebアプリからPostgreSQLへ接続する方法はいくつかあります。

Database用のクライアントやORMと呼ばれる仕組みを使う場合もあります。

どれを使うかは、現在のプロジェクト構成に合わせて決めます。

現在のプロジェクトを調査してください。

Neon PostgreSQLへ接続したいです。

まず、
このプロジェクトに合うDatabase接続方法を提案してください。

条件:
・初心者でも管理しやすい
・不要な依存関係を増やさない
・現在の技術構成を優先する
・新しいライブラリが必要なら理由を説明する

まだインストールやコード変更はしないでください。

AIが提案したものをそのまま導入するのではなく、理由を確認してから進めます。

ORMとは？

ORMは、プログラムからDatabaseを扱いやすくするための仕組みです。

直接SQLを書く代わりに、プログラム側のコードからデータを保存・取得できるようにします。

アプリのコード
↓
ORM
↓
SQL
↓
PostgreSQL

代表的なものはいくつかありますが、プロジェクトにすでに使われているものがある場合は、まず既存構成を確認しましょう。

STEP 8：テーブルを作る

Databaseでは、関連するデータをテーブルという形で管理します。

今回ならIdeaテーブルを作るイメージです。

Idea

id
title
content
createdAt

表で考えると次のようなイメージです。

id | title | content | createdAt
--------------------------------
1  | AI記事 | ...    | ...
2  | 新機能 | ...    | ...

Schemaとは？

Databaseで「どんなテーブルがあり、どんなデータを保存するか」という構造をSchemaと呼ぶことがあります。

Idea

id
↓
1件ごとに識別する

title
↓
タイトル

content
↓
本文

createdAt
↓
作成日時

AI開発では、Schema変更もAIに任せられますが、Databaseへ影響する重要な変更なので内容を確認します。

Migrationとは？

Databaseの構造変更を履歴として適用・管理する仕組みをMigrationと呼ぶことがあります。

現在のDatabase

↓

新しいテーブルを追加

↓

Migration

↓

新しいDatabase構造

利用しているツールによって、Migrationの方法やコマンドは異なります。

STEP 9：まず開発用Databaseで試す

可能であれば、開発中に使うDatabaseと本番Databaseを分けます。

Development
↓
テスト用Database

Production
↓
実際の本番Database

これにより、開発中のテストで本番ユーザーのデータを変更するリスクを減らせます。

STEP 10：AIに実装前調査をさせる

Database接続を追加する前に、現在のプロジェクトを確認してもらいます。

このプロジェクトへNeon PostgreSQLを追加します。

目的:
アイデアをDatabaseへ保存する。

まず現在のコードを調査してください。

確認:
・現在のプロジェクト構成
・使用しているFramework
・Database関連ライブラリの有無
・環境変数の扱い
・保存処理を実装する適切な場所
・データ取得を実装する適切な場所

まだコード変更・インストール・Migrationはしないでください。

最後に、
変更予定ファイルと実装方針を報告してください。

STEP 11：データを保存する処理を作る

次に、入力されたタイトル・本文をDatabaseへ保存できるようにします。

ユーザー入力
↓
送信
↓
サーバー側で受け取る
↓
内容を確認
↓
DatabaseへINSERT
↓
保存完了

重要なのは、ブラウザからDatabaseへ直接秘密情報を渡すような構成にしないことです。

Database接続は基本的にサーバー側で扱います。

Database保存機能を実装してください。

保存するもの:
・title
・content
・createdAt

条件:
・Database接続情報をブラウザ側へ公開しない
・入力値を確認する
・失敗時は適切にエラー処理する
・既存UIを必要以上に変更しない
・関係ないコードを変更しない

まず変更予定を報告してから実装してください。

STEP 12：入力値を確認する

ユーザーから送られてくるデータをそのまま信用しないことも重要です。

たとえば今回なら、

• タイトルが空ではないか
• 本文が空ではないか
• 想定以上に長すぎないか

などを確認できます。

入力
↓
Validation
↓
問題なし
↓
Databaseへ保存

問題あり
↓
保存しない
↓
エラー表示

STEP 13：保存テストをする

実装が終わったら、実際にデータを入力します。

タイトル:
AIで記事を作る

本文:
記事作成を自動化する方法を試す

送信後にDatabase側でもデータが保存されているか確認します。

画面では成功
+
Databaseにもデータがある

↓

保存成功

画面表示だけを見て判断せず、実際のDatabaseも確認するのがポイントです。

STEP 14：保存したデータを取得する

次はDatabaseに保存したアイデアを読み込みます。

ページを開く
↓
Databaseへ問い合わせ
↓
Ideaを取得
↓
画面へ表示

AIへは次のように頼めます。

Databaseに保存されているIdeaを取得し、
画面に一覧表示してください。

条件:
・新しいものから表示
・title
・content
・createdAt
を表示する

既存のデザインを維持してください。

まず現在の表示処理を確認してから実装してください。

STEP 15：ページを更新して確認する

Databaseを使う大きなメリットは、ページを更新してもデータが残ることです。

アイデアを追加
↓
Database保存
↓
ページ更新
↓
Databaseから取得
↓
アイデアが残っている

ここまでできれば、Database接続の基本が完成です。

STEP 16：エラー時も確認する

正常系だけではなく、失敗した場合も確認します。

• タイトルを空欄にする
• 本文を空欄にする
• Database接続に問題がある場合
• 保存処理が失敗した場合

ユーザーに何も表示されない状態ではなく、適切にエラーを扱えるようにします。

STEP 17：git statusとgit diffを確認する

git status
git diff

Database追加では、通常のUI変更より変更範囲が広がることがあります。

特に確認したいのは、

• Database関連ファイル
• Schema
• Migration
• 環境変数関連
• API・サーバー処理
• package.jsonなど依存関係

です。

現在のgit diffをレビューしてください。

確認:
・要件外の変更
・不要な依存関係
・Database Schema変更
・Migration内容
・秘密情報
・既存機能への影響

問題点があれば修正前に報告してください。

STEP 18：秘密情報がCommitされていないか確認する

Databaseを追加したときは、特に秘密情報の確認が重要です。

DATABASE_URL
PASSWORD
API_KEY
SECRET

などがGitの差分やファイルに直接含まれていないか確認します。

STEP 19：公開前チェックをする

利用しているプロジェクトで実行できるチェックを確認します。

このプロジェクトで公開前に必要な確認を実行してください。

確認:
・lint
・型チェック
・build
・利用可能なテスト
・Database接続
・Schema
・Migration
・秘密情報

失敗した項目があれば、
成功とは報告しないでください。

STEP 20：GitHubへPushする

ローカルで問題がなければ変更をCommitし、GitHubへPushします。

ローカル
↓
Commit
↓
Push
↓
GitHub
↓
Vercel Preview

本番Branchへ直接反映する構成の場合は、公開フローを理解してから操作しましょう。

STEP 21：VercelにDATABASE_URLを設定する

ローカルの .env ファイルはGitHubへPushしないため、Vercel側にも環境変数を設定する必要があります。

ローカル

.env.local
↓
DATABASE_URL

Vercel

Environment Variables
↓
DATABASE_URL

ローカルで動いていても、Vercel側に環境変数がなければ公開環境ではDatabaseへ接続できません。

STEP 22：PreviewとProductionを分ける

Vercelなどでは、PreviewとProductionで別の環境変数を設定できる構成があります。

可能であればDatabaseも分離します。

Preview
↓
開発・テスト用Database

Production
↓
本番Database

Previewでテストしたデータが、本番のユーザーデータへ混ざるのを防ぎやすくなります。

STEP 23：Previewで実際に保存する

Vercel Preview URLを開き、実際にデータを保存します。

Preview URL
↓
Idea追加
↓
Database保存
↓
ページ更新
↓
データが残っている

ローカルだけでなくPreviewでも動くことを確認します。

STEP 24：本番へ反映する

Previewで問題がなければ、現在のGit運用に従って本番へ反映します。

Local
↓
Feature Branch
↓
GitHub
↓
Preview
↓
確認
↓
Main
↓
Production

本番公開後も、実際のURLから保存・表示が正常に動くか確認します。

本番Databaseでテストするときの注意

Productionでは本番Databaseを利用している場合があります。

大量のテストデータを入れたり、削除操作を繰り返したりしないようにします。

Databaseを使うと何が作れる？

Databaseの基本が分かると、作れるWebアプリの幅が大きく広がります。

• Todoアプリ
• メモアプリ
• 予約システム
• 顧客管理
• 投稿サービス
• 問い合わせ管理
• 会員サービス
• EC関連サービス

ほとんどの本格的なWebサービスでは、何らかの形でデータ保存が必要になります。

Database追加の基本フロー

保存するデータを決める
↓
Schemaを考える
↓
Neonを用意
↓
DATABASE_URL
↓
環境変数
↓
Database接続
↓
テーブル作成
↓
保存処理
↓
取得処理
↓
ローカル確認
↓
git diff
↓
Preview確認
↓
Production

この流れを理解できれば、別のWebアプリでも同じ考え方を応用できます。

AIへDatabase変更を依頼する基本テンプレート

目的:
［Databaseへ追加したい機能］

現在:
［現在のアプリ状態］

Database:
Neon PostgreSQL

やりたいこと:
・［保存するデータ］
・［取得するデータ］

条件:
・本番Databaseは変更しない
・秘密情報を表示しない
・既存Schemaを最初に確認
・不要なライブラリを追加しない
・関係ないファイルを変更しない

最初に現在の構成を調査してください。

まだMigrationやコード変更は実行しないでください。

次を報告してください。

1. 現在のDatabase構成
2. 変更が必要なSchema
3. 変更予定ファイル
4. Migration内容
5. 既存データへの影響
6. リスク
7. テスト方法

ここまででできるようになったこと

Webサービスを作る
↓
GitHubへ保存
↓
Vercelで公開
↓
Neonを接続
↓
Databaseへ保存
↓
保存データを取得
↓
Webアプリとして利用

ここまで進めば、単なる静的なWebページから「データを持つWebアプリ」へ一段進んだことになります。

次に学ぶ

Databaseへデータを保存できるようになったら、次はユーザー登録・ログインを追加して、自分のデータだけを扱えるWebアプリへ進みます。

Webサービス
↓
Database
↓
ログイン
↓
ユーザーごとのデータ
↓
本格的なWebアプリ

Webアプリにログイン機能を追加する →