Claude Codeでアプリにデータ保存機能を足す前に知っておくこと:データベース、Supabase、そして「壊さない意識」

YouTubeで開く ↗
概要

安野貴博氏による「バイブコーディング超入門講座」の第7回は、データベースがテーマだ。これまでの回で、受講者はアプリをひと通り作り、少しずつ改善できるようになった。ただし、画面を作れてもデータを保存する場所がなければ、アプリでできることは限られる。今回はデータベースの基本、初心者向けとして選んだSupabaseの位置づけ、そしてAIにデータベースを触らせるときの注意点の3点を扱う。安野氏が特に時間を割いたのは3点目で、AIが本番データを消したり書き換えたりする事故をどう防ぐかという実践的な話である。

13分で読めます

なぜデータベースが必要なのか

安野氏はまず、データを保存する「箱」がないアプリで何が困るのかを説明する。例として挙げたのは、講座の第4回で作ったシューティングゲームだ。保存先がなければ、自分がどれくらいのハイスコアを取ったか、どのステージまで進んだかといった情報は、アプリを閉じるたびに失われる。ユーザー側から見れば、毎回同じデータを入れ直さなければならないことになる。

データベースは、見た目を担当するフロントエンドと連携して動く保存の仕組みだ。アプリを閉じると消えてしまうデータをデータベースに保存し、次に起動したときに読み込む。安野氏は、画面作りに加えてデータの保存までできるようになると、作れるアプリの幅が大きく広がると述べる。

データベースは「すごいExcel」

データベースと聞くと難しそうに感じるが、安野氏によれば、ざっくり言えばExcelやスプレッドシートのようなものだ。表形式のデータを保存でき、縦の列と横の行にデータを書いていく点は同じである。

違いは、縦の列の扱いがExcelより厳密なことだ。データベースでは「この列には数値しか入れてはいけない」「この列には名前の文字列しか入れてはいけない」「この列には日付しか入れてはいけない」といったルールを列ごとに決められる。スライドでは「名前」「メールアドレス」「登録日」を列に持つ表が示され、「田中太郎」「佐藤花子」が行として追加されていた。構造自体はスプレッドシートとほぼ同じで、そこにデータがどんどん追加されていく。

列ごとに決めるデータの種類を「データ型」と呼ぶ。代表例として、文字列型(VARCHAR)、数値型(INTEGER)、日付型(DATE)、真偽値型(BOOLEAN)が紹介された。真偽値型はtrueかfalse、0か1しか取らない型である。安野氏は、細かい名前を覚えるよりも、まずは「列ごとに型がある」と理解しておけばよいとしている。

覚えておきたい4つのキーワード

データベースの用語は数多くあるが、安野氏は初心者向けに4つだけを挙げた。

1つ目は「テーブル」で、1枚の表を指す。データベースの中には、通常いくつものテーブルを作る。たとえば名前・メールアドレス・登録日を持つユーザー登録のテーブルがあり、ゲームであれば「この人が何月何日にプレイして何点取ったか」を記録するスコアのテーブルがある。さらに、ハードモードかイージーモードか、画面を軽めにしているか暗めにしているかといった個人の設定を記録するテーブルも作れる。これらのテーブルをつなぎながら使うのがデータベースの使い方だ。

2つ目は「レコード」で、表の横の行にあたる。3つ目は「カラム」で、縦の列にあたる。4つ目が先ほどの「データ型」で、その列にどんな種類のデータが入るかを表す。この4つを組み合わせてデータを保存していくのがデータベースだ、と安野氏はまとめている。

Supabaseとは何か

2つ目の論点はSupabaseである。安野氏の説明では、Supabaseはデータベースを簡単に使えるようにするサービスで、裏側の設定をゼロから用意しなくて済む。データベースを本当にゼロから用意しようとすると、サーバーを作り、さまざまな設定をするといった専門知識が求められる。すぐに気軽にデータベースを使いたいなら、データベースまわりの機能をまとめて提供するサービスを使うと手軽だという。

こうしたサービスは「Backend as a Service(BaaS)」と呼ばれる。Supabaseを導入すると、データベースが使えるようになるだけでなく、ログインしている人が本当にその本人かを確かめる認証の仕組みや、APIでつなぐ仕組みなども一緒に使える。安野氏は、面倒な準備を肩代わりしてくれるものと捉えればよいと説明する。

PostgreSQLがベースで、バイブコーディングとの相性がよい

Supabaseのベースになっているのは PostgreSQL だ。データベースにはMySQLなどさまざまな種類があるが、PostgreSQLは世界中で使われている標準的なものの一つだと安野氏は紹介する。PostgreSQLを自分でゼロから用意することもできるが、Supabase経由で使えば、バイブコーディングを始めたばかりの人でも、多少のハードルはあるもののそれなりに使える。

安野氏がSupabaseを選んだ理由の一つは、バイブコーディングとの相性だ。AIに「Supabaseでよしなにやっておいて」と頼むと、それなりにやってくれるという。ただしSupabaseはあくまで初心者向けの入門として使いやすいものとして選んだのであり、他にもさまざまな製品があるので、興味のある人は調べてみてほしいとも付け加えている。

いちばん大事なのは「データベースを壊さない意識」

3つ目の論点は注意点である。ここでの話は、Supabaseに限らず、PostgreSQLやMySQLを自分で立てた場合にも当てはまるという前提で語られた。なお、セキュリティ面の話は別の回で扱う予定だという。

安野氏が最も大事だとするのは、データベースを壊さないように気をつけることだ。データベースを使っていていちばん怖いのは、データが意図せず消えてしまうことや、入っていたデータの整合性が取れなくなることである。AIは最近かなり賢くなっているが、それでも「AIが勝手に操作してデータベースの中身を全部消した」「壊した」「書き換えた」という話をたびたび耳にするという。だからこそ、本番のデータを守りながらAIを使うことは「絶対にやる必要がある」と安野氏は強調し、この「壊さない意識」を繰り返し口にした。

DELETE、UPDATE、WHERE句が出てきたら注意度を上げる

壊さない意識を持つうえで、安野氏は「危険な言葉」として DELETE、UPDATE、WHERE句 の3つを挙げた。これらが出てきたら注意度を上げよう、というのが趣旨である。

前提として、データベースを操作するときは、データベースに対して命令を送る。「このデータを追加して」「このデータを削除して」「3行目のデータをこう変えて」「山田さんを山田花子さんに変えて」といった命令だ。安野氏は、これはAIにプロンプトを送るようなものだと例える。その命令にあたるのがSQL文で、SQLは Structured Query Language(構造化問い合わせ言語)の略だ。SQL文を送ると、それに沿ってデータベース側が処理を行う。

入門講座の受講者はまだSQL文の詳細を知らないだろうと安野氏は認めたうえで、慣れていくにつれて興味があれば調べてほしい、細かいものを作ろうとすると知識が必要になる、と述べる。そのうえで、まずはこの3つが出てきたら気をつけることを勧めた。

DELETEは名前の通りデータを削除する命令で、本番のデータベースに飛べば実際に消えてしまう。UPDATEはデータを書き換える命令で、たとえば「山田太郎」を「山田花子」に変えると、もとの「山田太郎」という情報は失われる。そのためUPDATEにも細心の注意が必要だ。WHERE句は、どのデータを対象にするかを指定する部分である。

安野氏は、スライドの例を「呪文のようなものだと思って見てほしい」と前置きして解説した。安全な例として示されたのは DELETE FROM users WHERE id = 5 だ。DELETEなので削除、FROM usersは複数あるテーブルのうちユーザーのテーブルを対象にする、WHEREでIDが5という条件を指定している。つまり「IDが5番のユーザーの情報を消して」という意味になる。

ところがWHERE句を付け忘れて DELETE FROM users とすると、ユーザーの表が一撃で全部消える。さらに、WHERE句があっても条件が「id = 5」なのか「id != 5(5ではない)」なのかで結果はまったく変わる。後者なら、ID5番以外の全員の情報が消えてしまう。SQL文は少し間違えるだけで本番データが危険にさらされる、と安野氏は指摘する。

バイブコーディングをする人がこれを直接書くことはまだあまりないだろう。しかし、AIが「このSQL文を実行してよいですか」と尋ねてくることがある。DELETEやUPDATEが含まれている場合はデータが消えるかもしれないので、いったん立ち止まって確認しよう、というのが安野氏の助言だ。

事故を防ぐコツ1:件数とサンプルを先に確認する

では具体的にどう気をつければよいのか。安野氏は、データベースを触る人なら基本としてやっていることだと断ったうえで、3つのコツを挙げた。

1つ目は、データを操作する前に件数やサンプルを見て確認することだ。先ほどの DELETE を SELECT に置き換えて SELECT ... FROM users WHERE id = 5 とすると、削除の対象になるはずのデータがまず返ってくる。その中身や件数を見れば、自分が変なことをしていないかが分かる。

たとえば、条件を誤って「id != 5」と書いていた場合、1人分のデータだけを消すつもりだったのに、ユーザーが1万人いれば1万件が対象として表示される。それを見れば「これは完全に違う」と気づける。本番のデータを触るときは、必ずSELECT文などで対象となるデータの中身を確認してから実行しよう、と安野氏は述べる。

事故を防ぐコツ2:本番と開発を分ける

2つ目は、本番と開発を分けることで、安野氏は「非常に大事」だと強調した。実際に開発していると、データはつい壊してしまいがちだ。すでにユーザーがいて触っているアプリで、開発しながらデータを壊すと大変なことになる。だから開発用と本番用を切り分ける。

AIと会話しやすくなるキーワードとして、安野氏は環境の呼び名を紹介した。本番環境は「プロダクション環境」、本番に出る直前の検証環境は「ステージング環境」、もっと初期の段階で試行錯誤している環境は「デベロップメント環境」(開発環境)と呼ぶ。開発環境で試していたものがステージングに昇格し、さらにプロダクション環境になるという流れで、データベースもその環境の数だけ用意しておくとよい、という説明だ。ただし、この辺りにはいろいろな流派があるとも付け加えている。

事故を防ぐコツ3:バックアップを取る

3つ目はバックアップだ。現在のデータベース製品では、毎日決まった時刻にバックアップを取るといった設定ができる。取ったデータは「ダンプデータ」と呼ばれることがあり、この言葉も覚えておくとAIと話しやすいかもしれない、と安野氏は言う。

バックアップがあれば、仮に本番データを壊しても、ある時点までは復旧できる。安野氏の例では、毎朝7時にバックアップを取っていて、誤って12時にデータを消した場合、その間の5時間分の情報は失われるかもしれないが、それ以前の情報は守られる。製品によっては、もっと直前の状態まで復旧できるものもあるという。

Supabaseについては、毎日バックアップを取ってくれる仕組みがあり、フリープランでも手動でバックアップを取れると安野氏は説明する。難しい作業をする直前にバックアップを取っておく、あるいはClaude Codeに「今バックアップを取っておいて」と頼めば取ってくれる、という使い方も紹介された。

AIをどこまで信頼するか

これらを踏まえ、安野氏はAIへの信頼の置き方にも触れた。基本的には、最終的な確認は人間がきちんと行ってほしいという。何を消すのか、何を書き換えるのか、どこで実行しているのか(開発環境なのか、ステージング環境なのか)、バックアップはあるのか。これらを人間が確認しながら、作業を一歩ずつ進めていくことが大切だとする。

今回の3つのポイントの振り返り

安野氏は、データベースは本来ものすごく時間がかかる分野で深い知識があるが、今回は表層的なところだけを解説したと述べる。そのうえで、やりたいことがあればAIに「これはできるか」と聞き、分からない概念が出てきたらそれもAIに聞いて理解を深めていってほしいと勧めた。

振り返りとして挙げられたのは次の3点だ。データベースは、ざっくり言えば「すごいExcel」「すごいスプレッドシート」であり、普通の表計算と違って列ごとにデータ型があり、かっちりした構造を持つこと。生のデータベースソフトをそのまま使うのではなく、SupabaseのようなBaaSを使うと、AIエージェントからも非常に扱いやすいこと。そして、バックアップを取る、削除や更新の前に範囲を確認する、環境を複数用意して本番環境は絶対に死守する、という注意点である。

次のステップに進むためのキーワード

最後に安野氏は、今回入れようか迷って入れなかった概念を、次のステップに進むためのキーワードとして紹介した。

データベースの基本としては、テーブル同士をどう紐付けるかに関わる「主キー(プライマリーキー)」と「外部キー」。SQLの基本操作としては、SELECT、INSERT、JOIN、インデックス、UNIQUE、NOT NULL、トランザクション、ロールバック、そして制約(コンストレイント)。安野氏は、このあたりが分かってくると中級者だと言う。インデックスについては、データが大きくなると読み取りに時間がかかるところを、事前に目次をつけておくことで大幅に速くする機能だと補足した。

セキュリティ面では、SQLインジェクションが挙げられた。不正なSQL文を打ち込まれることで、データを意図しない形で壊されたり書き換えられたりする攻撃があり、これも大事な知識だという。

テーブル設計は最初にAIと壁打ちして詰める

もう一つ重要なキーワードとして挙げられたのが「正規化」だ。正規化やテーブル設計の巧拙によって、アプリケーションの作り方やメンテナンスの効率が大きく変わると安野氏は言う。

かつてはデータベースをどう設計すべきかについて膨大な知見が積み重ねられてきたが、安野氏は、最近ならAIと壁打ちすればAIがかなり良いテーブル設計を考えてくれるだろう、と見ている。そのため基本的には、自分がやりたいことをよく考え、AIと対話しながらテーブルを設計していくことが大事だという。

特に、データベースの最初の設計は、アプリケーションが動き始めた後から直すのがかなり大変になる。だから最初の段階でClaudeやGPTとしっかり壁打ちして、テーブルの正規化や仕様を詰めておくことを安野氏は勧める。本来は時間のかかる概念を高速に話したので、分かりにくかった点や分かりやすかった点があればコメントしてほしいと述べ、講座はあと1〜2回で終わりに向かう見込みだとして回を締めくくった。