データベース

データベースの仕組み

AIにアプリケーションの構築を依頼すると、ブログ投稿、ユーザープロフィール、製品カタログ、またはアプリが必要とするその他の情報など、データを保存するための専用データベースが作成されます。このデータベースは他のプロジェクトから完全に隔離され、セキュリティと追跡機能が自動的に構成されます。

データベースはグローバルに複製され、自動バックアップを備えた高速で信頼性の高いデータストレージを提供します。AIはすべての技術的詳細を管理します：テーブルの作成、データ間のリレーションシップの設定、セキュリティルールの構成、およびすべてがシームレスに連携することの保証。

自動的に得られるもの：

完全な分離 - データは他のすべてのプロジェクトから分離されています
自動バックアップ - データは継続的にバックアップされ保護されています
セキュリティ強制 - すべてのクエリにアクセス制御が自動的に適用されます
監査証跡 - すべての変更がタイムスタンプとユーザー情報で追跡されます
高速パフォーマンス - データベースは低レイテンシのためにデータをグローバルに配信します
視覚的管理ツール - UIを通じてデータを閲覧、検索、編集、エクスポートできます

自動データ追跡

AIが作成するすべてのテーブルには、考える必要なくセキュリティ、監査証跡、データ整合性を提供する5つの特別な列が自動的に含まれます：

`_row_id` - 一意識別子

各レコードは変更されない一意のIDを取得します。AIはこれを使用して関連データをリンクし（ブログ投稿と著者の接続など）、特定のレコードを更新します。独自のID列を作成する必要はありません — システムがこれを自動的に処理します。

`_created_by` - ユーザー追跡

ユーザーがレコードを作成するたびに、システムは自動的にユーザーIDでスタンプします。これにより、「自分の投稿のみを表示する」や「著者のみが編集できる」などの機能が可能になります。AIはこれをセキュリティルールに使用して、適切な場合にユーザーが自分のデータのみにアクセスまたは変更できることを保証します。

`_created_at` - 作成日

データが作成された時刻を記録し、タイムスタンプとして保存されます。これにより、最新順にソートしたり、「2日前に投稿」ラベルを表示したり、最近のアクティビティにフィルタリングしたりできます。タイムスタンプは自動的に設定され、変更されません。

`_updated_at` - 最終更新日時

レコードが変更されるたびに自動的に更新されます。これは「最終編集」情報の表示、キャッシング戦略の実装、または最近のアクティビティの追跡に役立ちます。システムはこれを完全に自動的に処理します — 手動で更新する必要はありません。

`_deleted` - ソフト削除

ユーザーがデータを削除すると、レコードは実際にはデータベースから削除されません — 削除済みとしてマークされるだけです。これは、誤って削除されたデータを回復し、監査証跡を維持し、履歴情報を失わないことを意味します。削除されたレコードはすべてのクエリから自動的に非表示になりますが、回復またはコンプライアンスのために必要な場合はアクセス可能です。

AIがデータベースを作成および更新する方法

アプリが必要とするデータの種類をAIに伝えると、バックグラウンドで適切なデータベーステーブルが作成されます。このプロセスは、データベース構造へのすべての変更を追跡する移行システムを使用し、時間の経過とともに更新、ロールバック、または変更内容を理解することを可能にします。

自動的に起こること：

「ユーザーが投稿を書けるブログを作成する」のようなものを要求すると、AIは：

テーブル構造を設計 - 必要なフィールド（タイトル、コンテンツ、公開日など）を決定します
追跡列を追加 - _row_id、_created_by、_created_at、_updated_at、_deletedを含めます
パフォーマンスインデックスを作成 - クエリが高速に実行されるようにデータベースインデックスを追加します
リレーションシップを設定 - テーブルをリンクします（投稿を著者に接続するなど）
変更を適用 - データベースにテーブルを作成します
セキュリティを構成 - アクセス制御ルールを設定します（以下で説明）
変更を記録 - 監査とロールバックの目的で作成されたものの記録を保存します

データリレーションシップ：

AIはデータ間のリレーションシップを自動的に管理します。例えば：

1対多：各ユーザーは多くのブログ投稿を持つことができます
多対多：各投稿は多くのタグを持つことができ、各タグは多くの投稿に適用できます
必須フィールド：存在しなければならないメールアドレス
一意の値：重複できないユーザー名
検証ルール：負の値にできない価格

アプリケーションが行う必要があることを説明すると、これらすべてが自動的に設定されます。

自動セキュリティとアクセス制御

データは行レベルセキュリティ（RLS）によって自動的に保護されます — 各データを誰が見て変更できるかを正確に制御するシステムです。AIにアプリケーションを説明すると、構築しているものに基づいて適切なセキュリティルールを設定します。

たとえば、「ユーザーは自分のメモのみを見るべき」と言うと、AIは各ユーザーが作成したレコードのみにアクセスできることを保証するルールを構成します。「ブログ投稿を公開するが、著者のみが編集可能にする」と言うと、それを自動的に設定します。セキュリティはデータベースレベルで強制されるため、誰かがAPIに直接アクセスしようとしても、それをバイパスする方法はありません。

セキュリティルールタイプ

AIは、洗練されたアクセス制御を作成するために組み合わせることができる9つの異なるタイプのセキュリティルールを構成できます：

1. パブリックアクセス

ログインしなくても誰でもこのデータを表示できます。マーケティングコンテンツ、製品カタログ、公開ブログ投稿、FAQセクションに最適です。

2. 認証済みユーザー

ログインしたユーザーのみがデータにアクセスできます。ユーザー生成コンテンツ、コミュニティ機能、内部ダッシュボード、またはメンバー専用のコンテンツに最適です。

3. オーナーのみ

レコードを作成した人のみが表示または変更できます。個人メモ、プライベートドキュメント、ユーザー設定、ショッピングカート、または各ユーザーに完全にプライベートであるべきデータに最適です。

4. 同じ組織

ユーザーは自分の組織のデータにアクセスできますが、他の組織のデータにはアクセスできません。チームドキュメント、全社アナウンス、共有プロジェクトデータ、部門リソースに最適です。各組織は自分のデータのみを表示します。

5. プライマリ組織

アプリの顧客ではなく、内部チーム（プライマリ組織）のユーザーに制限されたアクセス。これは、システム構成、管理ダッシュボード、請求管理、機能フラグ、内部分析、またはあなただけが見るべき監査ログに役立ちます。

プラットフォームコンテキスト：顧客があなたのアプリにサインアップすると、独自の組織を取得します。このルールは、彼らがあなたの内部管理データにアクセスできないことを保証します。

6. ユーザーが属性を持つ

「admin」グループにいるなど、特定のユーザー属性に基づくアクセス。管理者専用テーブル、役割ベースのコンテンツ、機能フラグ、またはベータアクセスに使用されます。

7. レコードが値を持つ

レコード自体の特定のフィールド値に基づくアクセス。たとえば、status = "published"のレコードのみを表示します。公開済みコンテンツ対下書きコンテンツ、アクティブデータ対アーカイブデータ、または承認ワークフローに最適です。

8. フィールドマッチング

ユーザー属性をレコードフィールドに一致させます。たとえば、ユーザーはレコードのdepartmentが自分のdepartmentと一致するレコードのみを表示できます。部門ベースのアクセス、場所ベースのフィルタリング、テリトリー管理、またはカスタムセグメンテーションに最適です。

9. すべてのアクセスをブロック

操作を完全に防ぎます。監査テーブルでの削除を防ぐ、読み取り専用の参照データを作成する、追加専用ログを実装する、または特定のレコードを決して変更できないようにするために役立ちます。

ルールの適用方法

セキュリティルールは、各タイプのデータベース操作に対して個別に設定できます：

データの読み取り（SELECT） - 誰がレコードを表示できるか
データの作成（INSERT） - 誰が新しいレコードを追加できるか
データの更新（UPDATE） - 誰が既存のレコードを変更できるか
データの削除（DELETE） - 誰がレコードを削除できるか

AIは複数のルールをOR論理で組み合わせることができます。たとえば、「レコードはオーナーまたは同じ組織の誰でも表示できる」は、セキュリティを維持しながら柔軟なアクセスを提供します。

実例

個人用Todoアプリ： AIは「オーナーのみ」ルールを設定するため、各ユーザーは自分のタスクのみを表示します。タスクを作成すると、あなただけがそれを表示、編集、または削除できます。

会社ブログ：公開された投稿は読み取りに「パブリック」ですが、「認証済み」ユーザー（チーム）のみが新しい投稿を作成でき、「オーナー」（投稿著者）のみが編集または削除できます。

マルチテナントSaaS： AIは「同じ組織」ルールを使用するため、会社Aのユーザーは会社Bのデータを見ることができません。内部チームは「プライマリ組織」ルールを使用して、顧客が見るべきでない管理機能にアクセスします。

部門リソース：「フィールドマッチング」ルールにより、営業担当者は営業資料のみを表示し、エンジニアリングはエンジニアリングドキュメントを表示するなど、部門属性に基づいて自動的に行われます。

データへのアクセス

データベースには3つの方法でアクセスできます：

1. 管理インターフェース

視覚的な管理インターフェースを使用すると、スプレッドシートのようなインターフェースを通じてデータを閲覧、検索、編集、エクスポートできます。データをフィルタリングし、列をソートし、レコードをインライン編集し、CSVまたはJSONにエクスポートできます。インターフェースは、テーブル構造に基づいてフォームを自動的に生成し、ルールに従ってデータを検証し、テーブル間のリレーションシップを処理します。

2. アプリケーションから

フロントエンドアプリケーションは、AIが自動的に構成するREST APIを通じてデータベースを直接クエリできます。APIはPostgREST互換の構文を使用します。これはデータベースAPIの広く採用されている標準です。設定したすべてのセキュリティルールが自動的に適用されます — ユーザーは見るべきデータのみにアクセスできます。

3. エッジ関数を通じて

エッジ関数（サーバーサイドコード）は、セキュリティルールを尊重しながら、フルパワーでデータベースにアクセスできます。AIは、複雑なビジネスロジックを実装したり、外部サービスと統合したり、ブラウザで実行すべきでない操作を実行したりする必要がある場合に、これらの関数を作成します。

ベストプラクティス

✅ AIに構造を処理させる - 必要なものを説明し、AIにテーブルを作成させます。技術的なデータベースの詳細について心配する必要はありません。

✅ 説明的な名前を使用する - AIと話すときは、データに明確な名前を使用します（「アイテム」や「もの」ではなく「ブログ投稿」など）。

✅ 自動機能を活用する - AIはリレーションシップ、検証、セキュリティを自動的に設定します。独自のものを構築しようとするのではなく、これらのシステムを信頼してください。

❌ デフォルトを上書きしない - 自動ID列、タイムスタンプ、ソフト削除には正当な理由があります。それらを機能させてください。

❌ セキュリティをスキップしない - 新機能を作成するときは、常に誰がデータを見て変更できるべきかを説明してください。

関連ドキュメント：

データベース ​