スキーマ

概要（サマリー）

スキーマ（データベーススキーマ）とは、データベースにデータを保存するときの「整理棚のレイアウト」や「入力フォームの共通ルール」のことである。

Excelで顧客管理をするとき、適当にセルに入力していくと、ある行では名前がA列にあり、別の行ではB列にある、といったバラバラな状態になってしまう。
データベースではこれを防ぐため、あらかじめ「テーブル（棚）」を作り、「顧客IDは数字のみ」「名前は文字列」「登録日は日付形式」といった厳格なルールを決める。
この「どんな名前のテーブルがあり、それぞれの列（カラム）にはどんな種類のデータが入るか、テーブル同士はどう繋がっているか」を定義したデータベースの全体的な設計図のことを「スキーマ」と呼ぶ。

詳細解説

スキーマで定義するもの

関係データベース（RDB）におけるスキーマ定義には、データ型、制約、リレーションシップなどが含まれる。

データ型（Data Type） は、それぞれの列（カラム）に何が入るかを指定するルールである。数値（INTEGER）、テキスト（VARCHAR）、日付（DATE）などが代表例である。

制約（Constraints） は、データに異常が発生しないように強制するルールである。たとえば、NOT NULL は空の入力を許さず、UNIQUE は同じ値の重複を防ぎ、PRIMARY KEY は行を一意に特定するために使われる。

リレーションシップ（結合関係） は、テーブル同士の繋がりを定義する。たとえば、「注文テーブル」の user_id 列が「ユーザーテーブル」の id 列を指し示す場合、外部キー制約（Foreign Key）として関係を表す。

スキーマ設計でよく考えること

スキーマ設計では、どのテーブルにどのデータを置くか、どの列を必須にするか、どの列にデータ型や制約を設定するかを考える。
たとえば、メールアドレスを重複させたくないなら UNIQUE 制約を使い、検索を高速化したい列にはインデックスを検討する。
この設計が曖昧だと、同じ意味のデータが複数箇所に散らばったり、不正な値が保存されたりして、後から修正が難しくなる。

スキーマの変更（マイグレーション）

Webアプリの機能追加によって「ユーザー情報に新しく電話番号を追加したい」となった場合、データベースのスキーマを変更する必要がある。
このスキーマを変更する作業、および変更履歴をプログラムで管理する仕組みのことをマイグレーションと呼ぶ。

JSONスキーマやOpenAPIスキーマとの違い

スキーマという言葉は、データベース以外でも使われる。
JSONスキーマはJSONデータの形を定義するもので、OpenAPIスキーマはREST APIのリクエストやレスポンスの形を定義するために使われる。
どれも「データの構造を決める設計図」という点では共通しているが、対象がデータベースなのか、JSONなのか、APIなのかが異なる。

AIコーディングとの関係

AIにデータベースのクエリ（SQL）やバックエンドの処理を作らせる際、最初にデータベースのスキーマ情報をインプットすることが極めて重要である。
スキーマの情報（テーブル構成やカラム名）をAIに伝えることで、AIはカラム名の書き間違えなどを減らし、実際の構造に合ったSQLやORMのコードを生成しやすくなる。

AIへ指示する際のポイント

• 「以下のスキーマ情報（テーブル設計）を元に、ユーザーが過去1ヶ月間に購入した合計金額を計算するSQLを書いて」
• 「Prisma（ORM）のスキーマファイル（schema.prisma）を作成したい。ユーザーモデルと、それに紐づく投稿（Post）モデルの1対多の関係を定義したコードを書いて」

よくある勘違い

スキーマと「スキーマレス」の違いは？

従来のデータベース（MySQLやPostgreSQLなど）は、データを保存する前に必ずスキーマ（設計図）を決定し、そのルールに反するデータは保存できないようにする。
一方で、MongoDBなどの「NoSQLデータベース」の中には、あらかじめルールを決めずに柔軟なデータを保存できるものがあり、これを スキーマレス（スキーマがない）と呼ぶ。
スキーマレスは自由度が高く開発スピードが速いが、データが乱雑になりやすいため、アプリケーション側でデータの形式をコントロールする必要がある。

スキーマは一度決めたら変更できない？

スキーマは変更できないというイメージを持つ人もいるが、実際にはマイグレーションによって後から変更できる。カラムの追加・削除・型の変更などはマイグレーションの仕組みを通じて管理される。
ただし、既存データが大量に入っているテーブルへのカラム追加や型変更は、ダウンタイム（サービス停止）が発生するリスクがあるため、本番環境では慎重に設計・実施する必要がある。

NoSQLデータベースはスキーマが不要だから設計しなくていい？

「スキーマレス ＝ 設計不要」は大きな誤解である。MongoDBなどのNoSQLデータベースはデータの構造を事前に決めなくても保存できるが、アプリケーション側で「どんなフィールドがどんな型で入るか」という設計（非公式のスキーマ）が存在しないと、データが乱雑になり、後から整合性を保つのが非常に難しくなる。
「スキーマレス」は「構造を決めなくてよい」ではなく、「データベースエンジンがスキーマを強制しない（その代わりアプリが責任を持つ）」という意味である。

まとめ

• スキーマは、データベースの構造、データの種類（型）、ルール（制約）を定めた設計図。
• テーブルのカラム名やデータ型、外部キーによる関係性などを定義する。
• AIにデータベース操作のコードを書かせるときは、スキーマ情報を事前に渡すことで、生成されるコードの精度が劇的に向上する。

情報ソース

• PostgreSQL Documentation — Data Definition（テーブル定義・スキーマの公式解説、英語）
• MySQL Reference Manual — CREATE TABLE（英語）

より詳しくAIに聞いてみよう

• スキーマ設計において、「主キー（Primary Key）」と「外部キー（Foreign Key）」の役割の違いを初心者向けに説明してください。
• データベースのテーブルを分割して整理する「正規化（第1正規化〜第3正規化）」について、具体的な例を使って説明してください。
• JSONスキーマ（JSON Schema）とは何ですか？データベースのスキーマと何が違うのですか？
• データベースのインデックス（INDEX）はどのような仕組みで検索を高速化しますか？どの列にインデックスを貼ると効果的かの判断基準を教えてください。
• OpenAPIスキーマ（Swagger）を使ってREST APIのドキュメントを自動生成する仕組みと、Node.jsやPythonでの実装方法を教えてください。