CRUDとは？作成・読み取り・更新・削除をわかりやすく解説

CRUDは**作成（Create）、読み取り（Read）、更新（Update）、削除（Delete）**の頭文字をとった言葉で、アプリが保存されたデータに対して行う4つの基本操作を指します。新しい顧客を追加するのは作成、顧客の一覧を見るのは読み取り、顧客の電話番号を変えるのは更新、顧客を削除するのは削除です。CRM、予約システム、在庫管理ツール、管理パネルといったほとんどのビジネスアプリは、基本的にこのCRUDに、ルールと見やすい画面を加えたものです。

AIで作るときにCRUDが重要な理由

CRUDは、あいまいなアプリのアイデアを、正確な依頼に変えるための言葉です。「取引先を管理するアプリ」と言うだけでは、AIは推測するしかありません。「取引先の作成、一覧、編集、削除ができるように。項目はこれこれ」と伝えれば、どの画面、どのデータベース操作、どのサーバーのルートを作ればよいかが正確に伝わります。

CRUDは、テストのチェックリストとしても使えます。アプリにある記録の種類ごとに、次の4つを確認してください。追加できるか、見られるか、変更できるか、削除できるか。さらに、それぞれの操作を正しい人だけができるかどうかも確認します。意外に多くのAIで作られたアプリは、作成はできても編集ができなかったり、誰でも何でも削除できてしまったりします。

身近なたとえ：レシピカードの箱

キッチンの棚にあるレシピカードの箱を想像してください。

• 作成： 新しいカードを書いて、箱に入れる。
• 読み取り： 箱をめくって眺める。または、ラザニアのカードを取り出す。
• 更新： 「チーズ200g」を二重線で消して「250g」と書き直す。
• 削除： カードを箱から出して捨てる。

ここにルールを加えてみましょう。カードを捨てられるのは料理長だけ。すべてのカードにはタイトルが必要。同じ名前のカードは2枚作れない。これが入力チェックや権限管理を備えたCRUDアプリで、実際のほとんどのアプリはこの形をしています。

CRUDが各層でどう現れるか

各操作は、画面、サーバー、データベースのすべてに現れます。並べて見ると、アプリがどのように作られているかがよくわかります。

画面がフロントエンドで、APIのリクエストはフロントエンドがバックエンドと話す方法で、SQLはバックエンドがデータベースと話す方法です。これらの言葉に馴染みがなければ、APIとはとデータベースとはをご覧ください。

具体例：機材の貸出管理ツール

ある学校の映像制作部門は、学生に貸し出しているカメラとマイクの管理が追いつかず、困っています。そこで、シンプルなアプリを作ることにしました。

記録するもの。 2種類のものを扱います。機材（名前、種類、シリアル番号、状態）と貸出（どの機材を、どの学生に、貸し出した日、返却期限、返却日）です。

機材のCRUD：

• 作成： スタッフが、シリアル番号付きで新しいカメラを追加する。ルール：シリアル番号は重複できない。
• 読み取り： 機材の一覧（種類や「今使えるか」で絞り込み可能）。1台ごとの貸出履歴を見る詳細ページ。
• 更新： 状態を「修理が必要」に変更する。
• 削除： 通常は本当の削除はしません。過去に30回貸し出されたカメラを削除すると、その貸出記録とのつながりが失われてしまいます。代わりに「廃止」とマークして、利用可能な一覧からは消えるけれど、履歴は残るようにします。これを論理削除と呼びます。

貸出のCRUD：

• 作成： 機材を学生に貸し出す。ルール：すでに貸し出し中の機材は、貸し出せない。
• 読み取り： 「延滞中の貸出」の一覧。返却期限を過ぎていて、返却日が入っていないもの。
• 更新： 機材が戻ってきたときに、返却日を記録する。
• 削除： 間違えて入力した貸出だけ、スタッフが削除できる。

権限。 学生は利用可能な機材を読み取ることだけができ、作成、更新、削除はスタッフだけができます。これらのチェックは、ボタンを隠すだけでなく、サーバー側で行われます。

これがアプリの全体です。二重に貸し出さないこと、延滞一覧、機材ごとの履歴といった肝心な部分は、基本的なCRUDの上に重ねたルールや問い合わせです。

主な用語

• レコード（行）： 1件のデータ。たとえば、1社の取引先や、1件の貸出。
• エンティティ／リソース： レコードの種類。たとえば「取引先」。通常、それぞれが独自のテーブルと、一連のCRUD画面を持ちます。
• バリデーション（入力チェック）： 入力内容の確認。必須項目、正しいメールアドレス、正の数量など。利便性のためにフォームで行い、安全のためにサーバーでも行います。
• 論理削除： 履歴やつながりを残すために、レコードを削除せず、削除済みや保管済みとしてマークすること。
• ページネーション： 長い一覧を1ページずつ表示して、アプリを速く保つこと。
• 監査ログ： 誰が、いつ、何を作成、変更、削除したかの記録。
• 管理パネル： スタッフがアプリのデータを管理するためのCRUD画面の集まり。

よくあるミスと誤解

• 4つのうち1つを忘れる。 作成と読み取りだけで編集がないアプリは多く、タイプミスのたびに削除して入力し直すことになります。エンティティごとに4つすべてを確認してください。
• 削除がほかのものを壊す。 請求書がある顧客を削除すると、請求書が宙に浮いたり、履歴が消えたりすることがあります。エンティティごとに決めてください。削除を禁止するか、論理削除するか、関連するレコードも一緒に削除するか。
• 権限が画面にしかない。 削除ボタンを隠しても、誰かが DELETE リクエストを直接送ることを防げません。サーバーは、誰がリクエストしているかを必ず確認する必要があります。
• ID指定の更新で、所有者を確認しない。 ユーザーAがURLの数字を変えるだけで /api/notes/42 を編集できるなら、ユーザーBのメモを編集してしまうことがあります。すべての更新と削除で、そのレコードがリクエストした本人のものかを確認してください。
• 削除時に確認がない。 一度の押し間違いでデータが消えてはいけません。確認のステップか、元に戻す機能を用意してください。
• 「CRUDは基本的すぎて、作る価値がない」。 汎用ツールよりも業務の流れに合うCRUDアプリは、価値のある製品になることがたくさんあります。

AIビルダーに頼むときの依頼例

エンティティごとに、このパターンで1つずつ依頼します。

取引先機能を作成してください。一覧、作成、編集、削除ができるようにしてください。項目は次のとおりです。名前（必須）、連絡先メール（正しい形式のメール）、電話番号、カテゴリ（食品、包装、清掃用品のいずれか）、メモ。一覧は名前での検索とカテゴリでの絞り込みに対応し、1ページ20件とします。削除の前には確認を出してください。注文がある取引先は、削除ではなくアーカイブにしてください。作成、編集、アーカイブができるのはログイン済みのスタッフだけにし、この制限はサーバー側で強制してください。

そのうえで、4つの操作をすべて、権限のあるユーザーと、アクセスできないはずのユーザーの両方でテストしてください。1つのエンティティがうまく動いたら、次のエンティティを追加します。社内ツールの作り方では、CRUDの画面がどのように完全な管理アプリになるかを説明しています。また、これらのアプリの多くが使う土台のデータベースについては、Postgresとはをご覧ください。

MythexでのCRUDアプリ

CRUDアプリは、AIアプリビルダーが最も得意とする分野の一つで、Mythexも例外ではありません。エンティティとその項目をチャットで伝えると、MythexはプロジェクトにPostgresデータベースを接続し、テーブルを作成し、リスト、フォーム、詳細画面をライブプレビューに作ります。その後、/test を実行して操作の流れを確認できます。ドキュメントには、開始用のプロンプト付きのCRUDアプリのレシピがあります。また、社内ツールビルダーとダッシュボードのテンプレートも、始めるのに適した場所です。

よくある質問