> ## Documentation Index > Fetch the complete documentation index at: https://docs.cloud.cdata.com/llms.txt > Use this file to discover all available pages before exploring further. # 権限とアクセス制御 > Connect AI のアクセス制御は、ロール、権限、認証パターン（共有認証またはユーザーごとの認証）によって実現されます。 Connect AI のデータガバナンスでは、ロールベースアクセス制御（RBAC）を使用して権限を一括管理できます。リソースへのアクセスは、個々のユーザーに直接付与するか、認証されたユーザーが所属する 1 つ以上のロールを通じて付与できます。ロールは権限（エンティティに対するデータおよび実行アクセス）と特権（請求、設定、ユーザー管理などの管理タスク）を決定します。 各データソースへの接続方法は、認証パターンを選択することでさらに制御できます。すべてのユーザーが単一のサービスアカウントを介してデータソースにアクセスする共有認証と、各ユーザーが自身の認証情報で認証するユーザーごとの認証のいずれかを選択できます。 ## ユーザー Administrator または User Administrator が、E メールで新規ユーザーを招待します。ユーザーは、ユーザー名とパスワード（または、アカウントで有効になっている場合は自社の SSO）で Connect AI にサインインします。Administrator は、新規ユーザーに適切なロールを割り当てることができます。 Just-in-Time（JIT）プロビジョニングが有効になっている場合、ユーザーが初めて SSO 経由でサインインしたときに、手動の招待なしでユーザーアカウントが自動的に作成されます。新規ユーザーにはデフォルトの Query システムロールと、デフォルトのコネクション・ワークスペース権限が付与されます。これらは後から Administrator または User Administrator が変更できます。詳しくは [Users and Roles](/ja/Users) および [User Provisioning and SSO](/ja/SCIM) を参照してください。 ## ロール ロールとは、管理権限とリソースへのアクセス権限の集合体です。ロールは以下のガイドラインに従います： * 任意のロールを任意のユーザーに割り当てることができます。 * 各ロールには固有の権限があります。 * ロールがユーザーに割り当てられると、そのユーザーはロールに関連付けられたすべての権限を取得します。複数のロールを持つユーザーは、それぞれのロールに関連付けられたすべての権限を持ちます。権限は **加算的** です。ユーザーのアクセス権は、割り当てられたすべてのロールから付与される権限の和集合となり、常に最も寛大な付与が適用されます。あるロールが別のロールから付与されたアクセスを削除または上書きすることはありません。 例えば、ユーザーが role\_1 と role\_2 を持ち、role\_1 にはデータコネクションに対する Select 権限があり、role\_2 にはそのデータコネクションへのアクセス権がない場合、role\_1 が優先され、ユーザーはデータコネクションにアクセスできます。 Connect AI には、Administrator、Connection Administrator、User Administrator、Query の 4 つの事前定義されたシステムロールが用意されています。 以下の表は、Connect AI の各システムロールのスコープを示しています。 | ロール | スコープ | ログアクセス | | ------------------------ | -------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------- | | Administrator | アカウントへのフルアクセス：コネクション、ユーザー、請求、設定 | すべてのクエリログとすべての監査イベント | | Connection Administrator | コネクションおよびワークスペースの作成/編集/削除、ジョブおよびデータウェアハウスの管理、コネクションおよびワークスペースの権限の割り当て、ユーザーの参照（読み取り専用）、すべてのコネクションへのクエリ実行 | すべてのクエリログ、コネクションドメインの監査イベントのみ | | User Administrator | ユーザーの作成/招待/編集/無効化、User Administrator ロールおよびQuery ロールの割り当て/取り消し、コネクションおよびワークスペースの参照（読み取り専用）、明示的に権限が付与されたコネクションへのクエリ実行 | ユーザードメインの監査イベントのみ（招待、ユーザー作成、ロール変更、PAT アクティビティ、なりすまし、ログインアクティビティ）、自身のクエリログのみ | | Query | 権限が付与されたコネクションへのクエリ実行、設定されている場合はUser Credentials による認証 | 自身のクエリログのみ、監査ログへのアクセスはなし | ## 権限 権限とは、ロールを構成するよりきめ細かいアクセスレベルです。以下のエンティティ権限を割り当てることができます： 権限の文脈では、*エンティティ* とはデータコネクション（例：Salesforce1）またはワークスペース（例：MyWorkspace）を指します。エンティティはコネクションのロゴで表示され、ワークスペースはフォルダアイコンで表示されます。 * **Select:** ユーザーがエンティティ内のテーブルから行を選択できるようにします。 * **Insert:** ユーザーがエンティティのテーブルに行を挿入できるようにします。 * **Update:** ユーザーがエンティティのテーブルの行を更新できるようにします。 * **Delete:** ユーザーがエンティティ内のテーブルから行を削除できるようにします。 * **Execute:** ユーザーがエンティティ内のストアドプロシージャを実行できるようにします。 Connect AI では、これらの権限を割り当てる方法として、ユーザー単位（1 人のユーザーに対して複数のエンティティ）またはエンティティ単位（1 つのエンティティに対して複数のユーザー）の 2 つを提供します。 ### ユーザー単位で権限を割り当てる エンティティ権限は、**Edit User** ページからユーザー単位で付与できます。または **Edit Role** ページでアクセスロールを定義することにより、複数のユーザーに対して一度に付与できます。権限は加算的に共存します。つまり、ユーザーをロールに割り当てても、そのユーザーに直接付与されている権限が削除されることはありません。 Assign permissions by user テーブル内の個別のボックスをクリックして、単一のエンティティに対する権限を切り替えるか、テーブルカラムの上部にあるボックスをクリックして、すべてのエンティティに対してその権限を切り替えます。 ### エンティティ単位で権限を割り当てる 権限は、**Edit/Add Connection** ページまたは **Workspace** ページからエンティティ単位で割り当てることもできます。例えば、**Edit Acumatica Connection** ページの **Permissions** タブでは、コネクションに対する権限を複数のユーザーに一度に付与できます。以下の例では、すべてのユーザーがデータを選択できますが、データを挿入できるのは 3 人のユーザーだけです： Assign permissions by entity テーブル内の個別のボックスをクリックして、単一のユーザーに対する権限を切り替えるか、テーブルカラムの上部にあるボックスをクリックして、すべてのユーザーに対してその権限を切り替えます。 ### ワークスペースアクセスとソース権限 ワークスペースがソースコネクション由来のアセットを含む場合、そのアセットへのアクセスはソースコネクションの権限ではなくワークスペースの権限によって制御されます。ワークスペースへのアクセス権を持つユーザーは、（ユーザーごとの権限またはロールを介した）基盤となるソースコネクションへのアクセス権の有無に関係なく、そのワークスペース内のアセットにアクセスできます。 このワークスペーススコープのアクセスは、ワークスペースがツールキットに追加され、カスタム MCP エンドポイント経由で AI に公開されている場合にも適用されます。つまり、ユーザーがワークスペースへのアクセス権を付与されている場合、そのアセットの取得元であるソースコネクションへのアクセス権を持っていなくても、カスタム MCP エンドポイント経由でそのワークスペース内のアセットにアクセスできます。 ## 認証パターン ### サービスアカウント（共有）認証 デフォルトでは、アカウントのすべてのユーザーが、サービスアカウント（共有認証）を使用してデータソースのデータにアクセスできます。サービスアカウント認証は、ユーザー固有の権限を含まない読み取り専用のデータソース、またはユーザーごとの認証がないシステムに使用します。 例えば、サービスアカウント（共有認証）を使用したSalesforce へのコネクションがある場合、すべてのユーザーアカウントは、そのSalesforce コネクション用に作成されたSalesforce アカウントのデータにアクセスできます。クエリ権限はユーザーごとにカスタマイズして利用可能な操作を制限できますが、これらの制限の下ですべてのユーザーは同じデータにアクセスします。 ### ユーザーごとの認証 特定のデータソースは、アカウントの各ユーザーに対して、自身のログイン認証情報でコネクションにログインすることを強制する機能をサポートしています。規制要件に準拠する場合や、ユーザーごとに異なるデータの場合は、ユーザーごとの認証を使用してください。ユーザーごとの認証により、ユーザーは自身がアクセスする必要があるアカウントのデータのみにアクセスできます。さらに、この方法でコネクションを構成すると、アカウントの最大数に対して単一のコネクションスロットとしてのみカウントされます。 データソースがユーザーごとの認証をサポートしている場合、コネクション設定の **Authentication** セクションの下に **Authentication Model** セクションが表示されます。**Shared Authentication** または **Per-User Authentication** のいずれかを選択します。 Authentication Model 特定のデータソースでこの機能が利用できず、ご希望の場合は、サポートチームまでお問い合わせください。 この機能には以下の制限が適用されます： * Administrator のみがデータソースを **Shared Authentication** と **Per-User Authentication** の間で切り替えることができますが、すべてのロールのユーザーが自身の認証情報でユーザーごとの認証コネクションにログインできます。 * ユーザーごとの認証は、[OData API](/ja/API/OData-Dashboard) の使用時はサポートされていません。データソースをOData API に接続するには、共有認証を使用する必要があります。 * キャッシュは共有認証でのみ許可されており、ユーザーごとの認証では許可されていません。詳しくは [キャッシュ](/ja/Caching) を参照してください。