CRUDとは？ータベースとAPI設計の基本原則を初心者にもやさしく解説！

CRUDをちゃんと決め切れずAPI設計がぶれる、一覧が遅い、削除方針やPUT/PATCHで迷う…そんな悩みを一気に解消します。

本記事はCRUDの基本から、データモデル、REST/HTTP対応、インデックスとキャッシュ、権限制御、SQL対策、データエンコーディングまで実務視点で整理します。

つまり、読めば今日から迷わない設計と実装ができます。チェックリストとサンプルも豊富に用意しました。

外資系エンジニア

この記事は以下のような人におすすめ！

CRUDとは何か知りたい人

CRUDの仕組みが良くわからない人

CRUD と REST/HTTP の対応があいまいな人

1 CRUD の基本と背景
2 CRUD の各操作を理解する
3 CRUD を使ったアプリケーション設計と実装
4 ベストプラクティスと設計上の注意点
5 応用・拡張テーマ
6 データエンコーディングと CRUD の関わり

CRUD の基本と背景

ソフトウェア開発で最も頻繁に触れるキーワードの一つが「CRUD」です。

つまり、アプリがデータに対して行う基本操作を四つに整理した概念で、要件定義からAPI設計、UI、セキュリティ対策まで、あらゆる場面の共通言語になります。

したがって、CRUDを正しく理解すると、設計の迷いが減り、実装やレビューの品質も大きく向上します。

1-1. CRUD とは何か？：定義と語源

まず、CRUDは次の頭文字をつないだ言葉です。

Create：新しいデータを作成する
Read：既存データを参照する
Update：既存データを更新する
Delete：既存データを削除する

言い換えると、CRUDはデータのライフサイクルを最小の操作単位でとらえたフレームワークです。だからこそ、CRUDを出発点にすると、要件の抜け漏れを防ぎやすくなります。

1-1-1. CRUD の語源と歴史

CRUDという言葉自体は古く、業務システムの設計やデータベース設計の現場で広く使われてきました。なぜなら、ほぼすべての情報システムは「データを作り、読み、変え、消す」という同じ動きを繰り返すからです。プロジェクトの規模や技術スタックが違っても、CRUDという共通の物差しで議論できます。

1-1-2. CRUD とデータモデルの関係

CRUDはデータモデル（テーブルやコレクション、エンティティ）と密接です。

Create は**新しい行（ドキュメント）**の追加
Read は検索・一覧・詳細表示
Update は属性の変更や関係の更新
Delete は行（ドキュメント）の除去または無効化
つまり、CRUDはモデルに対する操作の境界をはっきりさせ、APIやUIの設計を安定させます。

1-1-3. CRUD とよく混同される用語

Insert / Select / Update / Delete：SQLの文法。CRUDと対応はしますが、CRUDは概念、SQLは実装手段です。
BREAD（Browse, Read, Edit, Add, Delete）：UI文脈で使われることがある拡張表現。目的は近いですが、CRUDの方が技術横断的で汎用です。

1-2. CRUD が重要な理由：データ操作の基本原則

結論から言えば、CRUDは要求と実装をつなぐ橋です。なぜなら、CRUDを基軸にすると、仕様・設計・実装・運用の各レイヤーで一貫性と説明可能性が高まるからです。

1-2-1. CRUD が生むメリット（要点）

抜け漏れ防止：各エンティティに対し、Create/Read/Update/Deleteの要否をチェックできる
見通しの良いAPI設計：エンドポイントの役割が明確になり、命名や責務がぶれにくい
UI/UXの指針：一覧・詳細・編集・新規・削除の画面構成が自然に定まる
セキュリティ設計の起点：権限（誰が何をできるか）をCRUD単位で整理しやすい
テスト容易性：CRUDごとに正常系・異常系の観点が切り出しやすい

その結果、チーム内のコミュニケーションコストが下がり、進行中の仕様変更にも強くなります。

1-2-2. ステークホルダー別のメリット（早見表）

役割	CRUD がもたらす価値
プロダクトオーナー	要件の粒度がそろい、優先順位付けがしやすい
設計者	境界づけと責務分割が明確になり、依存関係を整理しやすい
開発者	実装方針が揃い、コードの再利用とレビューが容易
テスター	テストケースをCRUD単位で網羅的に設計しやすい
セキュリティ担当	権限、入力検証、監査ログをCRUD基準で設計可能

1-2-3. よくある落とし穴と回避策

過剰な汎用API：何でも受け付ける1本のエンドポイントは、結局CRUDの境界が曖昧になります。
→ 操作ごとに目的と入力を限定しましょう。
権限の粗さ：Readは全員可、Updateは管理者のみ、などCRUD単位で最小権限を徹底します。
論理削除の運用漏れ：Deleteをソフトデリートにしたら、検索や集計からの除外条件、定期パージ、監査ログも合わせて設計します。
更新衝突：Update時の上書き事故を防ぐため、バージョン番号やETagで同時更新を検知しましょう。

1-3. CRUD と REST / HTTP メソッドの関係

次に、CRUDはRESTfulなAPI設計と相性が良い、という点を押さえます。なぜなら、HTTPメソッドがCRUDの意図を表現しやすいからです。

1-3-1. CRUD と HTTP メソッドの典型対応

CRUD	典型のHTTPメソッド	例（リソース）	想定ステータス	冪等性	主な注意点
Create	POST	POST /users	201 Created, 400, 409	否	同一リクエストの重送対策（重複作成防止）
Read	GET	GET /users, GET /users/{id}	200, 404	可	安全性（状態を変えない）、キャッシュ戦略
Update（全体）	PUT	PUT /users/{id}	200/204, 400, 404, 409	可	置換の意味。未指定フィールドの扱いを明確に
Update（部分）	PATCH	PATCH /users/{id}	200/204, 400, 404, 409	条件次第	差分適用の仕様を文書化（JSON Patch等）
Delete	DELETE	DELETE /users/{id}	204, 404	可	論理削除か物理削除か、監査ログ・復元方針

ポイントは、GETは安全かつ冪等、PUT/DELETEは冪等、POSTは冪等ではないということです。つまり、同じリクエストを繰り返したとき、サーバーの状態が変わらないのが冪等です。

1-3-2. 実務で迷いがちな設計判断

PUT と PATCH の使い分け
全体置換ならPUT、部分更新ならPATCH。したがって、API仕様では「未指定フィールドをどう扱うか」を先に合意しましょう。
Create の重複防止
同一内容のPOSTが重送されても二重作成されないよう、リクエストIDや一意制約を活用します。
Delete の設計
法令や監査要件があるなら論理削除＋アーカイブを基本にし、復元手順と保持期間を明記します。
検索（Read）の拡張
ページング、ソート、フィルタ、範囲検索などのクエリパラメータ設計は早期に決め、上限（limit）やタイムアウトでパフォーマンスと可用性を守ります。
セキュリティの前提
CRUDの各操作に対して、認証（誰か）と認可（何ができるか）を明確化。さらに、入力検証・エンコーディング・エスケープでインジェクションを防ぎます。

1-3-3. 最低限そろえたいCRUDドキュメント

リソース一覧（ユーザー、注文、在庫など）
各リソースのCRUD可否（どの役割がどの操作を許可されるか）
エンドポイント仕様（URL、メソッド、リクエスト/レスポンス例）
エラーハンドリング方針（ステータスコード・エラー形式）
監査ログ方針（誰がいつ何をCreate/Update/Deleteしたか）

CRUD の各操作を理解する

CRUD は、アプリがデータに対して行う四つの基本操作（Create／Read／Update／Delete）の総称です。つまり、CRUD を正しく押さえることは、要件定義・API 設計・UI・セキュリティ・運用までのすべてに直結します。ここでは、実務にそのまま活かせる観点で各操作を整理します。

2-1. Create（作成）：用途と実装パターン

新しいリソースを作るのが Create です。したがって、入力検証と重複防止、そして失敗時の巻き戻しが設計の肝になります。

2-1-1. Create の基本フロー

入力検証（必須項目、型、範囲、正規表現）
権限チェック（誰が作成できるか）
一意制約チェック（メール、ユーザー名、注文番号など）
作成（トランザクションで一括確定）
監査ログ（誰がいつ何を作成したか）

2-1-2. ID 付与と重複防止

ID 生成
- サーバー側（連番、UUID、ULID など）：衝突しづらく監査と相性が良い
- クライアント側（暫定 ID）：一時保存やオフライン同期に便利
重複防止
- 一意制約（DB 側）
- リクエスト ID／冪等性キー（同じ Create を複数回送っても二重作成しない）

2-1-3. バリデーションとデータエンコーディング

サーバー側での最終バリデーションは必須（クライアントは参考）
文字列のサニタイズ・エスケープにより、インジェクションを回避
入力を受け取るときは文字コードとデータエンコーディングを明示（例：UTF-8、JSON）
画像や添付はコンテンツタイプ検証とサイズ上限を定義

2-1-4. トランザクションと分散

単一 DB：ACID トランザクションで整合性を担保
分散環境：結合書き込みを避け、アウトボックスパターンやイベント駆動で整合性を取る
失敗時は部分的に作られた関連データを確実にロールバック

2-2. Read（参照／取得）：問合せ・フィルタ・一覧／詳細表示

Read は最も頻度が高い CRUD 操作です。つまり、応答速度・ページング・絞り込み・キャッシュ戦略がユーザー体験を左右します。

2-2-1. 一覧と詳細の基本

一覧：ページング、ソート、フィルタ、検索語をサポート
詳細：関連情報の取得粒度を設計（過剰取得を避ける）

2-2-2. ページング戦略（比較表）

戦略	例	長所	短所	向き
オフセット	`?page=2&limit=20`	実装が簡単	大量データで遅くなりがち	管理画面
カーソル	`?after=token`	安定・高速	実装が複雑	無限スクロール
時系列境界	`?since=timestamp`	追記型に強い	並び替えが限定	フィード

2-2-3. フィルタリングとセキュリティ

ホワイトリスト方式で許可するクエリパラメータを限定
ソート項目や並び順も事前定義
出力フィールドのプロジェクション（必要な項目だけ返す）
個人情報はマスキングまたは除外、権限に応じてフィールドレベルで制御

2-2-4. パフォーマンス最適化

適切なインデックス設計（結合・範囲・複合）
キャッシュ（HTTP キャッシュ、ETag、サーバーサイドキャッシュ）
N+1 問題を避けるため、必要に応じて事前集約やJOIN 最適化
大きな一覧には要約ビューや非正規化テーブルを用意

2-3. Update（更新）：パッチ／全体更新、データ整合性の注意点

Update は既存データを変更します。したがって、競合制御とスキーマ整合性、そして監査が要になります。

2-3-1. 全体更新（PUT）と部分更新（PATCH）

PUT（全体置換）：送られた内容でリソースを置き換える。未指定フィールドの扱いを仕様で明確化
PATCH（部分更新）：差分のみ適用。JSON Merge Patch や JSON Patch の採用可否を文書化
どちらも検証順序（認証→認可→入力検証→存在確認→整合性チェック）を統一

2-3-2. 同時更新の衝突を防ぐ

楽観的ロック：バージョン番号や更新時刻、ETag＋If-Match ヘッダー
悲観的ロック：短時間のレコードロック（長時間ロックは回避）
衝突検出時は409 Conflict相当の扱いで再取得・再編集を促す

2-3-3. 整合性とビジネスルール

参照整合性（子を更新するときの親の存在検証）
逆参照の更新（在庫数、カウント値などは一括更新かイベントで反映）
不可逆な更新（状態遷移）には状態機械を導入し、許可遷移を限定

2-3-4. 監査と追跡可能性

更新前後の差分を監査ログに記録
重要フィールドは履歴テーブルやイベントストアで追跡
フィールド単位の更新者・更新時刻を保持

2-4. Delete（削除）：論理削除 vs 物理削除、安全性確保

Delete はデータの消去です。ただし、いきなり消すのではなく、復元性・法的要件・参照整合性を踏まえて設計します。

2-4-1. 論理削除（ソフトデリート）と物理削除（ハードデリート）

方式	概要	長所	短所	主な用途
論理削除	`deleted_at` などのフラグで非表示化	復元が容易、監査に強い	検索除外や集計が複雑に、肥大化	会員・注文・課金履歴
物理削除	行（ドキュメント）を完全削除	ストレージ節約、検索が簡単	復元不可、誤削除が致命的	テンポラリ・キャッシュ

ポイントは、どちらを採るかではなく一貫した運用です。つまり、論理削除なら「一覧から除外」「集計で除外」「定期パージ」「復元手順」をセットで設計します。

2-4-2. 参照整合性とカスケード

親削除時の子の扱いを明確化（禁止、カスケード削除、孤児化の防止）
外部キー制約や ON DELETE ルールを仕様に反映
論理削除なら「子も論理削除」か「参照禁止」に統一

2-4-3. 安全性確保の実務テクニック

二段階削除（まず論理削除→一定期間後に物理削除）
重要データは削除保護フラグや多要素確認（例：プロジェクト名の再入力）
監査ログに削除リクエストの発行者・理由を記録
誤削除時の復元プレイブック（バックアップからのリストア手順）

2-4-4. 法令・ポリシーとの整合

保存期間、忘れられる権利、監査要件を CRUD の Delete 設計に落とし込む
データ分類（高機密、個人情報など）ごとに削除手順を分ける
ログ・バックアップに残るデータの扱いも方針化

CRUD を使ったアプリケーション設計と実装

CRUD を軸に設計すると、要件の抜け漏れが減り、API と UI、さらに運用やセキュリティまで一貫した品質にできます。ここでは、データモデルからフロントエンドまでを、実務で使える観点で整理します。つまり、これから紹介する手順に沿えば、CRUD を使ったアプリケーションの骨格を短時間で固められます。

3-1. データモデル設計：エンティティとリレーション

堅牢な CRUD を実現するには、まずデータモデルが要です。なぜなら、エンティティとリレーションの設計が、そのまま API の形と UI の動線を決めるからです。

3-1-1. ユースケースからエンティティを抽出する

主要なユーザーストーリーを列挙し、名詞を候補エンティティに、動詞をCRUD 操作に対応付けます。
例えば「ユーザーが商品を注文する」なら、User・Product・Order がエンティティ、Create Order が主要な CRUD です。
その結果、実装前に「何を作り、何を読み、何を更新し、何を削除するのか」が明確になります。

3-1-2. 正規化と非正規化の使い分け

正規化で冗長性を抑え、Update 時の一貫性を高める。
非正規化で Read の速度や集計性能を上げる。
ポイントは、CRUD の頻度に合わせて調整することです。Read 多めなら非正規化の検討、Update 多めなら正規化を優先します。

3-1-3. リレーション設計の基礎

一対一：詳細情報の分割やプライバシーデータの隔離に有効
一対多：最も一般的。子の CRUD ポリシー（親削除時の扱い）を明文化
多対多：中間テーブルで表現。Create/Read/Update/Delete のどこで中間を触るかを決めておく

3-1-4. 制約と CRUD の整合

主キー、一意制約、外部キー、チェック制約をCRUD ごとに点検します。
例えば Create では一意制約と必須項目、Update ではチェック制約と参照整合性、Delete では外部キーの挙動が要点です。

3-1-5. 監査と削除ポリシー

全エンティティに created_at、updated_at、updated_by を用意し、CRUD の痕跡を追跡可能にします。
削除は論理削除フラグや deleted_at を検討し、検索・集計の除外条件を合わせて仕様化します。

3-2. API 設計（エンドポイント設計・URL 命名規則）

API は CRUD を外部に公開する契約です。したがって、URL 命名、HTTP メソッド、ステータスコード、エラーモデルを統一すれば、利用側と開発側のコストが大幅に下がります。

3-2-1. リソース指向の URL 設計

原則は名詞の複数形でリソースを表現し、階層で関係性を示します。
例：/users, /users/{id}, /users/{id}/orders
動詞は原則使わず、特殊操作はサブリソースやアクション名で表現します。

3-2-2. CRUD と HTTP メソッドの対応

Create：POST /resources
Read：GET /resources（一覧）、GET /resources/{id}（詳細）
Update：PUT（全体置換）または PATCH（部分更新）/resources/{id}
Delete：DELETE /resources/{id}
冪等性と安全性を明記し、ドキュメントに反映します。

3-2-3. クエリとネストの使い分け

一覧は ?page, ?limit, ?sort, ?filter[...] などで制御。
深いネストは過剰な結合の兆候になりがちです。必要に応じて検索エンドポイントを別に設けます。

3-2-4. エラーモデルとステータスコード

400（入力不正）、401（未認証）、403（権限不足）、404（未検出）、409（競合）、422（検証失敗）、500（サーバーエラー）を使い分けます。
レスポンス本文は code, message, details, trace_id などを統一。

3-2-5. バージョニングと互換性

パスでのバージョン付け（例：/v1）が分かりやすいです。
互換性維持の方針を先に決め、CRUD のスキーマ変更時は非推奨期間を設けます。

3-2-6. セキュリティとレート制御

認証（トークン、セッション）と認可（ロール、属性）を CRUD 単位で定義。
レートリミット、入力検証、出力エンコーディング、監査ログを標準装備にします。

3-3. バックエンド実装例（SQL／NoSQL／ORM 使用例）

ここでは、CRUD を SQL、NoSQL、ORM でどう形にするかを概観します。つまり、ストレージが違っても CRUD の考え方は同じで、違うのは操作手段だけです。

3-3-1. SQL での CRUD（例）

Create：INSERT INTO users (name,email) VALUES (?, ?);
Read：SELECT * FROM users WHERE id = ?;
Update：UPDATE users SET name = ? WHERE id = ?;
Delete：DELETE FROM users WHERE id = ?;
ポイント：トランザクションで一連の CRUD を包み、外部キーとインデックスを適切に設定します。

3-3-2. NoSQL での CRUD（ドキュメント指向の例）

Create：db.users.insertOne({...})
Read：db.users.find({_id: ...})
Update：db.users.updateOne({_id: ...}, {$set: {...}})
Delete：db.users.deleteOne({_id: ...})
ポイント：スキーマはアプリ側で管理。Read が多いなら読みやすい形に整形して保存します。

3-3-3. ORM での CRUD（典型パターン）

Create：repo.save(entity)
Read：repo.findById(id), repo.find({ where, order, take, skip })
Update：repo.update(id, patch) または entity.field = ...; repo.save(entity)
Delete：repo.delete(id) または softRemove(entity)
リポジトリやサービス層を挟み、ビジネスルールを散在させないのがコツです。

3-3-4. トランザクションと整合性

同時更新には楽観的ロック（バージョン番号）を採用し、409 相当の競合を返します。
複数ストアをまたぐ場合はアウトボックスやイベント駆動で最終的整合性を担保します。

3-3-5. パフォーマンス最適化

Read はインデックスとキャッシュ、Update はバッチ処理やキューで平準化。
Create の重複は一意制約＋冪等性キーで抑止。
Delete は二段階削除やアーカイブで安全に運用します。

3-3-6. 自動テストとデータ準備

CRUD ごとに正常系・境界値・権限違反・競合のテストを用意。
固定のテストデータと、毎回再生成するシードを使い分けます。

3-4. フロントエンド連携と UI/UX 観点

最後に、CRUD をユーザーに触ってもらう入口である UI/UX を整えます。なぜなら、良い API も UI が使いにくいと価値が半減するからです。

3-4-1. CRUD UI の基本構成

一覧（Read）・詳細（Read）・新規（Create）・編集（Update）・削除（Delete）の五画面を軸に設計。
画面遷移を単純化し、状態が分かるフィードバックを即時に返します。

3-4-2. フォーム UX（Create/Update）

入力中にバリデーションを行い、エラーは項目ごとに明確化。
必須・任意・形式（メール、URL、数値など）を視覚的に区別。
その結果、Create と Update の完了率が大きく改善します。

3-4-3. 一覧 UX（Read）

ページング、ソート、フィルタ、検索を統一 UI で提供。
列表示のカスタマイズや、選択項目の一括操作（複数削除や一括更新）を用意します。

3-4-4. 楽観的 UI 更新とエラーハンドリング

Create/Update/Delete の成功を予測して先に UI を更新し、失敗時はロールバックします。
ネットワーク失敗時はリトライ、競合時は最新データの再取得を促すメッセージを表示します。

3-4-5. アクセシビリティと国際化

入力支援、フォーカス移動、スクリーンリーダー配慮を標準化。
文字コードとデータエンコーディングは UTF-8 を前提に、サーバー・クライアントで統一。
日付・通貨・並び順のローカライズを CRUD の Read/Update に反映します。

ベストプラクティスと設計上の注意点

CRUD を正しく設計すると、変更に強く、保守しやすいアプリになります。ここでは、実務でつまずきやすい論点を「DRY・エラーハンドリング・パフォーマンス・権限とセキュリティ」の四点に整理して解説します。つまり、この章を押さえれば、CRUD 実装の品質が一段引き上がります。

4-1. コードの DRY 原則と共通処理抽象化

同じ処理を繰り返すと、CRUD の変更コストが雪だるま式に増えます。したがって、DRY（Don’t Repeat Yourself）を軸に、共通化ポイントを見極めましょう。

4-1-1. CRUD で重複しがちな箇所

入力検証（必須・型・範囲・正規表現）
認証・認可チェック
ページング・ソート・フィルタの解釈
例外からエラーレスポンスへの変換
監査ログ（誰が何を Create/Update/Delete したか）

4-1-2. 抽象化のレイヤー設計（推奨）

ミドルウェア／フィルター層：認証、レート制御、監査の横断処理
サービス層：ビジネスルール（在庫引当、状態遷移など）
リポジトリ層：CRUD のデータアクセス（SQL/NoSQL の詳細を隠蔽）
DTO/スキーマ層：入出力のバリデーションを一元化

4-1-3. 反復を減らす共通部品

ページングユーティリティ（limit/offset/cursor の正規化）
権限判定ヘルパ（ロールや属性に基づく CRUD 許可）
一意制約違反→409 などのエラーマッパー
ソフトデリートを自動的に除外するクエリビルダー

4-1-4. アンチパターンと対処（早見表）

症状	何が問題か	対処
各コントローラで同じバリデーション	規則変更の波及が大きい	スキーマ定義を共通化、ミドルウェア化
SQL を各所で直書き	最適化やセキュリティが分散	リポジトリ/ORM に集約
例外処理の書き散らし	返却形式が不統一	グローバルハンドラで統一

4-2. エラーハンドリング・バリデーション戦略

CRUD は失敗する前提で設計します。なぜなら、入力ミス、競合、整合性違反は必ず起こるからです。したがって、エラーの型と扱いを明確にしましょう。

4-2-1. バリデーションの層別

リクエスト層：型・範囲・必須チェック（早期に 400/422）
ドメイン層：ビジネスルール（状態遷移、在庫上限など）
永続化層：一意制約・外部キー・チェック制約（DB が最終ガード）

4-2-2. エラーモデルの統一

共通フォーマット例：{ code, message, details, traceId }
CRUD でよく使うマッピング
- Create：重複 → 409、検証失敗 → 422
- Read：未認可 → 403、未検出 → 404
- Update：競合（ETag/Version 不一致）→ 409
- Delete：関連存在で禁止 → 409 または 400

4-2-3. ユーザーに優しいメッセージ

何が原因で、次に何をすればよいかを明示
フィールド単位のエラーは配列で返す（例：details.fields[]）

4-2-4. 冪等性とリトライ

Create は冪等性キーで二重作成を防止
Update/Delete は If-Match（ETag）やバージョン番号で競合検知
一時的障害は指数バックオフで自動再試行

4-3. パフォーマンス対策：インデックス・キャッシュ・ページング

CRUD の Read が遅いと、体感品質が急落します。だからこそ、データアクセスを数字で管理します。

4-3-1. インデックス設計の基本

選択性の高い列、JOIN に使う列、ソート列に付与
複合インデックスはプレフィックス順を意識（例：(status, created_at)）
過剰なインデックスは Update/Delete を遅らせるため、利用状況を計測して整理

4-3-2. キャッシュの使い分け

層	用途	例	注意点
ブラウザ/HTTP	GET の省力化	ETag/Last-Modified	私的情報は短寿命・条件付き
アプリ内	計算/集計結果	メモリキャッシュ	失効戦略、スレッド安全性
分散キャッシュ	人気一覧・詳細	Redis 等	書き込み時の無効化設計

4-3-3. ページング最適化

小規模データ：オフセットで十分
大規模データ・無限スクロール：カーソル方式（安定・高速）
一覧には軽量ビュー（必要フィールドのみ）を返し、詳細は個別 Read に委ねる

4-3-4. N+1 と過剰取得の抑制

必要に応じてJOIN/集約、または事前集約テーブル
フィールド・カラムのプロジェクションで転送量を削減
バックエンドでタイムアウトと上限を定義（limit, maxDepth）

4-3-5. 計測と継続的改善

P95/P99 レイテンシ、DB の実行計画、キャッシュヒット率をモニタ
スロークエリログからボトルネック CRUD を優先的に最適化

4-4. 認可とセキュリティ：権限制御、SQL インジェクション対応

CRUD の安全性は、認証より認可の設計で決まります。さらに、SQL インジェクションは初歩的ながら致命的です。

したがって、最小権限と安全なデータ取り扱いを徹底しましょう。

4-4-1. 権限制御の設計（RBAC/ABAC）

RBAC（ロール基盤）：Admin/Manager/Viewer などの役割ごとに CRUD 許可を定義
ABAC（属性基盤）：リソース所有者や部門、地域などの属性で許可を細分化
フィールド/レコードレベルの権限：同じ Read でも見える項目を変える
権限はコード直書きではなくポリシーとして集中管理

4-4-2. 監査とアラート

Create/Update/Delete は誰が・何を・いつ行ったかを必ず記録
失敗した認証・認可や大量削除の試行にはアラートを設定

4-4-3. SQL インジェクション対策（必須）

プレースホルダ／パラメータ化クエリを徹底（文字列連結で SQL を組み立てない）
ORM でも生 SQL を使う場合は必ずバインド変数を使用
入力はスキーマ検証し、データエンコーディング（文字コード、JSON など）を明示
エラーメッセージに SQL を含めない（情報漏えい防止）

4-4-4. その他の実務ポイント

最小権限：DB ユーザーは必要な CRUD のみ許可
CSRF/同一サイト設定：特に Delete/Update は保護を必須化
レート制限：Create/Update/Delete の連打を抑止
バックアップと復元手順：誤削除時のプレイブックを用意

応用・拡張テーマ

CRUD を土台に、運用やセキュリティ、スケールを見据えて一歩先の設計に踏み込む章です。

つまり、ここで扱う考え方を押さえると、要件変更に強く、監査可能で、性能劣化もしにくい CRUD ベースのアプリケーションを育てられます。

5-1. CRUD 行列（CRUD マトリクス）とアクセス制御

CRUD 行列は、エンティティ×操作（Create/Read/Update/Delete）×役割を表で可視化する道具です。

したがって、誰がどのデータに何をしてよいかを曖昧にせず、仕様の抜け漏れを防げます。

5-1-1. CRUD 行列とは

目的：操作の可否を一目で判断できるようにする
対象：主要エンティティ（例：User、Product、Order）
切り口：役割（例：Admin、Manager、Member）や属性（部署、所有者、地域）

5-1-2. 作り方（最小手順）

エンティティを縦軸、CRUD を横軸に置く
役割ごとに「許可」「条件付き許可」「禁止」を記入
条件がある場合は注記に具体化（例：所属部門のみ、本人のデータのみ）

例（簡易版）：

エンティティ \ 操作	Create	Read	Update	Delete
User	Admin: 許可 / Manager: 一部許可 / Member: 禁止	Admin: 許可 / Manager: 条件付き（所属のみ） / Member: 自分のみ	Admin: 許可 / Manager: 一部許可 / Member: 自分のみ	Admin: 許可 / Manager: 禁止 / Member: 禁止
Product	Admin: 許可 / Manager: 許可 / Member: 禁止	全員: 許可	Admin: 許可 / Manager: 許可 / Member: 禁止	Admin: 許可 / Manager: 禁止 / Member: 禁止
Order	Admin: 許可 / Manager: 許可 / Member: 自分のみ	Admin: 許可 / Manager: 所属のみ / Member: 自分のみ	Admin: 許可 / Manager: 所属のみ / Member: 自分のみ	Admin: 許可 / Manager: 条件付き / Member: 自分のみ取消

5-1-3. アクセス制御に落とし込むコツ

RBAC（ロール基盤）で大枠を決め、必要に応じてABAC（属性基盤）で細分化
Read でもフィールドレベル権限を検討（個人情報を隠す等）
監査ログは CRUD 行列の粒度（誰が・どの操作・どの範囲）に合わせて記録

5-1-4. ありがちな失敗

行列が最新化されず、実装と乖離
Delete の扱いが曖昧（論理削除か物理削除か）
条件付き許可の条件が定義不十分（「所属」とは何を指すかが明確でない）

5-2. 拡張 CRUD：BREAD・CRUDL などの概念

CRUD だけでは UI 文脈や探索体験を表現しにくい場合があります。

そこで、BREAD や CRUDL などの拡張 CRUDを知っておくと設計が楽になります。

5-2-1. BREAD（Browse, Read, Edit, Add, Delete）

Browse：一覧＋探索の体験に焦点（フィルタ、ソート、ページング）
Read：詳細表示
Edit / Add：更新・新規作成の分離で UI を明確化
Delete：削除
つまり、CRUD を UI 行動の言葉に置き換えたもので、画面遷移やコンポーネント設計が整理しやすくなります。

5-2-2. CRUDL（Create, Read, Update, Delete, List）

List を独立扱いにして、一覧 API の要件（クエリ、ページング、権限）を強調
検索性能やキャッシュ戦略、軽量レスポンス設計を分離して議論できるのが利点

5-2-3. そのほかの拡張（例）

CRUDE：Export を明示（帳票出力・CSV/Excel）
CRUDA：Archive を定義（保管、保留、復元手順まで設計）
CRUDP：Publish（公開/非公開の切り替えを状態遷移として扱う）

5-2-4. どれを採用すべきか

データ探索主体なら BREAD
大規模一覧・検索重視なら CRUDL
法令対応や監査重視なら CRUDE/CRUDA
したがって、プロダクトの主要行動に合う拡張 CRUD を採用し、用語をチームで統一することが重要です。

5-3. 非同期操作・バッチ処理との組み合わせ

現実の CRUD は、必ずしも即時に完結しません。

なぜなら、外部連携や大量データ、課金処理などは非同期やバッチが適するからです。

5-3-1. 非同期化が有効な場面

画像/動画の処理、レポート生成、全文検索の再構築
外部 API 決済、メール送信、在庫引当の最適化
大量の Create/Update を伴う取り込み

5-3-2. 設計パターン（要点）

キューイング：Create/Update の結果としてジョブを投入
アウトボックスパターン：トランザクション整合性を保ちつつイベント配信
結果の受け渡し：ジョブ ID を返し、Read で進捗・結果を参照できるようにする
冪等性：再実行に備え、同じジョブが複数回走っても結果が破綻しない設計にする

5-3-3. バッチ処理の CRUD 影響範囲

Create：大量登録は分割投入とバックプレッシャ
Read：バッチ中は整合性の揺らぎに注意。スナップショット読み取りや整合性レベルを調整
Update：行ロックやインデックス更新の負荷を考慮し、夜間実行や小刻みコミット
Delete：二段階削除やアーカイブを併用し、監査と復元を確保

5-3-4. 障害時の再試行と監視

再試行ポリシー（回数、間隔、上限時間）を定義
デッドレター行きのジョブを可視化し、運用手順に組み込む
成功率、遅延、キュー長をメトリクス化して容量計画に反映

5-4. データ履歴管理／バージョニング

CRUD の信頼性を高めるには、過去の状態を追跡できることが不可欠です。

つまり、いつ・誰が・何を変更したかをたどれる仕組みが必要です。

5-4-1. 履歴の種類（まず要件整理）

監査履歴：誰が、いつ、どの CRUD を行ったか
業務履歴：業務状態の推移（例：注文の状態遷移）
完全履歴：フィールド単位の前後差分、復元可能性まで要求

5-4-2. 実装パターン（比較）

パターン	概要	長所	注意点
監査テーブル	本体とは別に操作ログや差分を保存	実装容易、監査に強い	復元は手作業になりがち
履歴テーブル（SCD Type 2）	有効期間カラムで過去版を保持	ある時点の状態を再現可能	ストレージ増、クエリが複雑
イベントソーシング	変更イベント列を保存し再生	完全再現性、拡張に強い	設計難度が高い、読み取りは要投影

5-4-3. API とスキーマのバージョニング

API バージョン：互換性を壊す変更は新バージョン（例：/v1 と /v2）
スキーマ移行：前方/後方互換を意識して段階更新（フィールド追加→消費側対応→古いフィールド廃止）
ドキュメント：各 CRUD に対して変更点と移行手順を明示

5-4-4. 復元・証跡・削除ポリシー

復元は「履歴からの復元」と「アーカイブからの復元」を区別
個人情報を含む履歴は保存期間とマスキングを定め、Read 権限を限定
Delete と履歴の関係を明文化（論理削除時は履歴を残すが、法令上の要請で匿名化する等）

データエンコーディングと CRUD の関わり

CRUD はデータの作成・参照・更新・削除の設計指針ですが、実務ではデータエンコーディングを正しく扱わないと、安全性や可用性が一気に崩れます。

つまり、どの操作で何をどの形式に変換し、どのコンテキストでエスケープするかを決めておくことが、堅牢な CRUD 実装の土台です。

ここでは、用語整理から具体的な適用、そしてセキュアな実装までを一気に整理します。

6-1. データエンコーディングとは？基本概念と目的

6-1-1. 用語の整理（違いをひと目で）

概念	目的	例	重要ポイント
エンコーディング	表現形式を変換して可搬性を高める	UTF-8、Base64、URL エンコード	可読性より互換性。復号不要で元に戻せる
暗号化	内容を秘匿する	AES、TLS	鍵が必要。可搬性より機密性
ハッシュ	同一性検査・改ざん検知	SHA-256	片方向。パスワードは塩付けして保存
シリアライズ	構造化データを送受信用に変換	JSON、Protobuf	バージョニングを設計
エスケープ	文脈に応じて記号を無害化	HTML、SQL、JS	文脈依存。二重エスケープに注意

したがって、CRUD の各所で「何のために」変換するのかを明確にし、混同しないことが重要です。

6-1-2. CRUD とエンコーディングの接点

Create/Update：入力の文字コード統一、危険文字の適切な処理、バイナリの Base64 化など
Read：出力先の文脈（HTML、JSON、CSV）に合わせたコンテキスト別エスケープ
Delete：ログ・アーカイブへの安全な記録（改ざん検知、マスキング）

つまり、CRUD は単なる操作分類ではなく、変換と保護の設計ポイントでもあります。

6-1-3. UTF-8 で統一する理由

多言語・絵文字を含む入力を統一的に扱える
API やブラウザ、DB との互換性が高い
文字化け・不正バイトの検出が明確
プロジェクト全体で「入出力は UTF-8」をルール化し、境界（ブラウザ、API、DB、ログ）ごとに明示します。

6-2. CRUD 操作におけるデータエンコーディングの使いどころ

6-2-1. Create/Update：入力受理のベストプラクティス

受信直後に正規化：文字コードを UTF-8 に強制、改行コードも統一
スキーマ検証：型・必須・範囲チェックと同時に、文字種や長さを制限
危険文字の扱い：保存時点では原則そのまま保持し、出力時に文脈エスケープ（保存前エスケープは二重化の原因）
バイナリ：JSON 経由なら Base64、サイズ制限と MIME 検査をセットにする

6-2-2. Read：レスポンスの文脈エスケープ

HTML：< > & " ' を HTML エスケープ
属性値：引用符やイベント属性内は専用の属性エスケープ
JavaScript 埋め込み：JSON.stringify で埋め込み、コードとして実行しない
URL/クエリ：パラメータごとに URL エンコード
CSV：先頭の = + - @ を無害化（表計算の式注入防止）

6-2-3. Delete/Archive：監査と復元を見据える

削除ログ：誰が・何を・いつ削除したかを UTF-8 で一貫記録
アーカイブ：圧縮＋ハッシュで整合性を担保、機密なら暗号化
匿名化：法令・ポリシーに応じて識別子をマスキングまたはトークナイズ

6-2-4. 形式別の使い分け（早見表）

文脈	推奨形式	主なエンコーディング	注意点
API（構造化）	JSON	UTF-8、Unicode エスケープ不要	スキーマで型と長さを固定
高速・省サイズ	Protobuf/MessagePack	バイナリ	バージョン管理を厳格に
ダウンロード	CSV	UTF-8（BOM 有無を明示）	区切り・引用・式注入対策
静的表示	HTML	HTML/属性/URL エスケープ	文脈別に処理を分離

6-3. 文字コード変換・エスケープ処理と安全性

6-3-1. コンテキスト別エスケープ早見表

出力先	どこに挿入するか	何をエスケープするか	代表的な失敗
HTML 本文	テキストノード	`< > & " '`	画面にタグが混入し XSS
HTML 属性	`href` など	引用符、制御文字	属性値からスクリプト実行
JavaScript	文字列リテラル	`\n \r " ' \` など	文字列が壊れコード化
CSS	値	`()`、特殊記号	見た目改ざんや情報露出
URL/Query	パラメータ	`%` エンコード	パラメータ解釈の破綻