> ## Documentation Index
> Fetch the complete documentation index at: https://docs.base44.com/llms.txt
> Use this file to discover all available pages before exploring further.
# データ権限の管理
Base44 は、アプリの構築中にデータ権限を自動的にセットアップします。AI チャットを使用していつでも調整したり、より細かい制御が必要な場合は手動で設定したりできます。権限が正しく設定されていない場合、間違った人々がアプリ内のデータを表示または変更する可能性があります。
誰がアプリを開けるか、サインインが必要かを設定するには、[アプリアクセスとロールの管理](/Setting-up-your-app/Managing-access#setting-your-app-visibility) を参照してください。
***
## AI チャットを使用して権限を設定する
権限を手動で設定する必要はありません。AI チャットにアプリがどう動作すべきかを平易な言葉で伝えると、適切なルールを設定します。これは、最初にアプリを構築するときと、ニーズが変わったときの後のいずれにも機能します。既存のルールを更新する必要がある場合は、最初に承認を求めます。
**使用できるプロンプトの例:**
```text theme={null}
注文を送信した人だけがそれを表示できるようにして。
```
```text theme={null}
管理者はすべてのクライアントの詳細にフルアクセスできる必要がある。通常のユーザーは自分のものだけを見ることができる。
```
```text theme={null}
誰でも製品カタログを閲覧できるが、マネージャーだけがリスティングを追加または更新できる。
```
***
## 権限を手動でカスタマイズする
特定のデータテーブルの権限をレビューまたは微調整したい場合は、ダッシュボードのテーブルの **Permissions** ページから行えます。ページは、現在のルールを示す読み取り専用ビューで開きます。**Edit** をクリックして変更を加えます。
どのルールを設定すべきか分からない? 必要なものを平易な言葉で AI チャットに説明すると、権限を設定します。手動設定は、より正確な制御が必要なときのためにあります。
**データテーブルの権限をカスタマイズするには:**
1. アプリエディタで **Dashboard** をクリックします。
2. **Data** の下で、管理したいテーブルをクリックします。
3. ページの右上にある **Permissions** をクリックします。権限の問題がある場合、ボタンに警告アイコンが表示されます。
4. **Edit** をクリックして **Configure permissions** パネルを開きます。
5. 各ルールがカバーするアクションのボックスをチェックします: **Create** (レコードを追加)、**Read** (レコードを表示)、**Update** (レコードを編集)、**Delete** (レコードを削除)。
6. **Entity-User Field Comparison** のボックスをチェックする場合は、**Entity field** にこのテーブルから比較するフィールドを入力し、次に **User field** ドロップダウンから一致するユーザープロパティを選択します。
7. **User Property Check** のボックスをチェックする場合は、**User property** ドロップダウンからユーザープロパティを選択し、必要な値を設定します。
8. **Save** をクリックします。
人が任意の 1 つのルールに一致すると、アクセスが許可されます。追加の Entity-User Field Comparison または User Property Check 行を追加するには、パネルの下部にある **Add rule** をクリックします。アクションをカバーする唯一のルールを削除することはできません。最初にそのアクションの別のルールを追加してから、削除したいものの選択を解除してください。
ページ下部の **Generated JSON (Preview)** セクションには、ルールが Base44 が舞台裏で使用する技術形式にどう変換されるかが表示されます。権限エディタを使用するためにそれを理解する必要はありませんが、開発者が権限設定の共有を依頼した場合や、どのルールが正確に有効かを確認したい場合に役立ちます。
### 権限ルールタイプ
通常、ルールを手動で追加する必要はありません。AI はデータテーブルを作成するときに設定し、**Permission recommendations** パネルは何かがおかしいときに修正を提案します。このセクションは、推奨を適用する前に各ルールが何をするかを理解したい場合や、特定の何かを微調整する必要がある場合のためにあります。
| ルール | 機能 | 適している用途 |
| -------------------------------- | ------------------------------------------ | -------------------------- |
| **All Users** | 誰でも、サインインしていなくてもこのアクションを実行できます | 製品カタログやブログなどの公開データ |
| **Creator Only** | 人は自分が作成したレコードにのみアクセスできます | 注文、メッセージ、フォーム送信などの個人データ |
| **Entity-User Field Comparison** | レコードのフィールドがアカウント詳細に一致する場合にのみ、レコードにアクセスできます | タスクやチケットなど、特定の人にレコードを割り当てる |
| **User Property Check** | 特定のアカウントプロパティを持つ人のみがこのアクションを実行できます | 管理者のみなど、ロールベースのアクセス |
すでに特定のルールがあるアクションに **All Users** を有効にすると、それらのルールがクリアされる前に確認ダイアログが表示されます。アクションに **All Users** がアクティブな状態で特定のルールを有効にすると、**All Users** は自動的に削除されます。
### Entity-User Field Comparison の仕組み
このルールは、レコードのフィールドがサインインしている人のアカウントのプロパティに一致するかどうかをチェックします。一致する場合、アクセスが許可されます。
2 つのことを設定します:
* **Entity field**: このデータテーブルにすでに存在するフィールドの名前。フィールド名を見つけるには、**Dashboard** に移動し、**Data** の下のテーブルをクリックして、そこにリストされている列を見てください。表示されているとおりにフィールド名を入力します。例: `assigned_to` や `owner_email`。
* **User field**: 比較する、サインインしている人のアカウントからのプロパティで、ドロップダウンから選択します。例: メールアドレス。
**例:** タスクが属する人のメールを保存する `assigned_to` フィールドを持つ Tasks テーブルがあります。**Entity field** を `assigned_to` に、**User field** を `email` に設定します。これで、各人は自分に割り当てられたタスクのみを見ます。
複数のフィールドペアで一致させる必要がある場合は、複数の Entity-User Field Comparison 行を追加できます。
### User Property Check の仕組み
このルールは、サインインしている人のアカウントのプロパティをチェックして、設定した値に一致する場合にのみアクセスを許可します。
2 つのことを設定します:
* **User property**: チェックするアカウントフィールド。例: **User Role**、**User Email**、または **Full Name**。
* **Required value**: 一致する必要がある値。**User Role** の場合、ドロップダウンから **Admin** または **User** を選択できます。他のフィールドの場合は、値を直接入力します。
**例:** 管理者のみがレコードを削除できるようにしたい。**User property** を **User Role** に、**Required value** を **Admin** に設定します。
異なるプロパティや値のための複数の User Property Check 行を追加できます。
***
## 権限推奨事項を適用する
AI が現在の設定で潜在的なリスクを検出すると、データテーブルページに直接 **Permission risks detected** バナーが表示されます。リスクのサマリーと推奨される修正を表示します。次の 2 つの方法で操作できます:
* **Fix** をクリックして推奨事項に直接移動し、1 ステップで適用します。
* **More details** をクリックして完全な **Permission recommendations** パネルを開き、適用する前に変更をレビューします。
**Permission recommendations** パネルには 2 つのセクションが表示されます。**Risk** セクションには、現在のルールと、それらが意図しない人々にデータを露出する可能性がある理由が説明されます。**Recommended rules** セクションには、推奨される置き換えと、それらが施行するものの平易な言葉での説明が表示されます。
**Apply recommendations** をクリックして現在のルールを推奨されるルールに置き換えるか、**Cancel** をクリックしてパネルを閉じて既存のルールを維持します。推奨事項を適用した後にルールを手動で編集することもできます。
***
## アプリタイプ別の権限の例
アプリの権限をセットアップする方法が分からない? これらの一般的なシナリオを出発点として使用してください。AI チャットに設定をレビューして適切なルールを提案するように依頼することもできます。
家族の買い物リストや共有家庭管理ツールなど、信頼できる少数の人々のグループが同じアプリを使用します。
* **アプリの可視性:** Private。アクセスが必要な人々を招待します。
* **ログインを要求:** はい。
* **権限:** 全員が平等に共有するデータには、制限は必要ありません。個人的なメモやリマインダーなど、各人に個別に属するデータには、Read、Update、Delete に **Creator Only** を使用して、各人が自分が作成したレコードのみにアクセスできるようにします。
誰でもサイトを訪問できますが、送信した応募はあなたまたはチームのみに表示される必要があります。
* **アプリの可視性:** Public。
* **ログインを要求:** いいえ。
* **権限:** フォーム送信テーブルでは、Create に **All Users** を使用して誰でも送信できるようにします。Read、Update、Delete には、管理者ロールに制限された **User Property Check** を使用して、チームのみが受信したメッセージを表示および管理できるようにします。
チームや会社が内部でアプリを使用し、一部のデータはマネージャーや特定のロールのみに表示される必要があります。
* **アプリの可視性:** Workspace。
* **ログインを要求:** はい。
* **権限:** 給与データやパフォーマンスレビューなどの機密テーブルをマネージャーロールに制限するには、**User Property Check** を使用します。お知らせや共有リソースなどの一般的なコンテンツには、Read に **All Users** を使用してチーム全体が表示できるようにします。
各人はログインして自分のデータを管理します。彼らは自分のレコードのみを見るべきで、他の誰かのレコードは決して見ないべきです。
* **アプリの可視性:** オープンサインアップが必要か、招待のみが必要かに応じて、Public または Workspace。
* **ログインを要求:** はい。
* **権限:** すべての個人データテーブルで、Read、Update、Delete に **Creator Only** を使用します。これにより、各人は自分が作成したレコードのみにアクセスできることが保証されます。
誰でもコンテンツを参照できますが、編集者または管理者のみが何かを追加または変更できます。
* **アプリの可視性:** Public。
* **ログインを要求:** いいえ、特定のコンテンツをゲートしたい場合を除きます。
* **権限:** Read に **All Users** を使用して、誰でもコンテンツを表示できるようにします。Create、Update、Delete には、編集者または管理者ロールに制限された **User Property Check** を使用して、チームのみがコンテンツを管理できるようにします。
異なる会社、学校、または部門がそれぞれアプリを使用しますが、データは完全に互いに分離されている必要があります。
* **アプリの可視性:** セットアップに応じて Public または Workspace。
* **ログインを要求:** はい。
* **権限:** 各レコードのフィールドをサインインしている人のアカウントのプロパティに一致させるには、**Entity-User Field Comparison** を使用します。例えば、各レコードに `company_id` フィールドがあり、各ユーザーアカウントに一致する `company_id` プロパティがある場合、Entity field を `company_id` に、User field を `company_id` に設定します。各人は自分の会社に属するレコードのみを見ます。グループ内の管理者アクセスには、管理者ロールに対する **User Property Check** と組み合わせます。
***
## FAQ
いいえ。Base44 は、データテーブルを作成するときに自動的に権限をセットアップします。平易な言葉でいつでも AI チャットにそれらを更新するように依頼でき、または各テーブルの **Permissions** ページから手動で調整できます。公開する前に、セキュリティスキャンを実行してすべてが正しく見えることを確認する価値があります。
影響を受けるテーブルをダッシュボードで開き、その **Permissions** ページを確認します。**Permission risks detected** バナーがある場合は、**Fix** をクリックして推奨されるルールを適用するか、最初にレビューするには **More details** をクリックします。**Security** タブからセキュリティスキャンを実行して、アプリ全体の問題の完全な概要を確認することもでき、または問題を AI チャットに説明して修正を依頼できます。変更を加えたら、**Preview** モードでアプリをテストして、さまざまなロールでサインインして、アクセスが期待どおりに動作することを確認します。
はい、変更はすぐに反映されます。変更を加える前に、新しいルールでアプリがどう動作するかをテストするには **Preview** モードを使用してください。さまざまなロールでサインインして、アクセスが期待どおりに動作することを確認します。
はい。User テーブルにカスタムフィールド (`department` や `access_level` など) を追加して、マネージャーやビューアなどの値を定義します。次に、そのフィールドに **User Property Check** ルールを使用して、各ロールに適切なレベルのアクセスを与えます。AI チャットに設定するように依頼できます。
いいえ。権限は、個々のフィールドではなくデータテーブル全体に適用されます。テーブルから返されるデータを制限する必要がある場合、これはバックエンド関数を介して行えます。これにより、アプリに到達する前にデータをフィルタリングまたは変換できます。AI チャットにこのセットアップを支援するように依頼できます。
権限が、高度な演算子を使用する条件など、ビジュアルエディタが表現するには複雑すぎるルールでセットアップされている場合、エディタは JSON のみのビューにフォールバックします。JSON を直接編集することも、マトリックスのボックスをチェックして新しく開始することもできます。これにより、既存の設定を置き換える前に確認を求められます。
このページは AI を使用して翻訳されました。最も正確で最新の情報については、[英語版](/) を参照してください。