このトピックでは、データプロバイダーのアカウント作成と共有の構成、他の（つまり、コンシューマー）アカウントとの共有の共有、および共有の継続的なメンテナンスの実行に関連するタスクについて説明します。
これらのタスクを実行するには、 ACCOUNTADMIN ロール（またはCREATE SHARES グローバル権限が付与されたロール）を使用する必要があります。CREATE SHARES 権限の詳細については、 ACCOUNTADMIN 以外のロールによる、データ共有タスクの実行の有効化 をご参照ください。
データ共有とBusiness Criticalアカウント
Business Criticalアカウントをお持ちの場合、他の（つまり、コンシューマー）アカウントとデータを共有するための次の条件に注意します。
他のすべてのSnowflakeエディションの場合:
詳細については、 一般的なデータ共有の考慮事項と使用法 （このトピック内）をご参照ください。
注意
Snowflakeでは、データ共有に携わっている HIPAA （および HITRUST）アカウントが相互に BAA に署名していることを保証する責任を負いません。これは、データを共有しているアカウントの裁量です。署名済みの BAA がないと、両方のアカウント、 特に プロバイダーアカウントの HIPAA （および HITRUST）コンプライアンスに影響する可能性があります。
また、Business Criticalアカウントをお持ちの場合、Business Criticalが提供するデータ保護の期待レベルを維持するため、SnowflakeにBusiness Critical以外のアカウントのSecure Data Sharingの有効化をリクエストする前に、次の点を考慮するよう 強く お勧めします。
機密データを非Business Criticalアカウントと共有しないでください。
2つ目の非Business Criticalアカウントを作成して、機密性の低いデータを保存し、このデータを非Business Criticalアカウントと共有することを検討します。
Business CriticalアカウントでTri-Secret Secureを使用しており、他のアカウントとデータを共有している場合、Snowflakeは、これらのアカウントからのデータアクセスを自分のアカウント内から発生したかのように扱います。具体的には、コンシューマーアカウントへのアクセスを許可するには、Snowflakeが AWS KMSにアクセスする必要がある場合があります。
これらは推奨事項にすぎず、Snowflakeによって強制されるものではありません。データを共有する決定は常にデータプロバイダーの裁量で行われ、Snowflakeは不適切に共有されたデータについて一切責任を負いません。
共有のウェブインターフェイス
ACCOUNTADMIN ロール（または CREATE SHARES 権限が付与されたロール）がある場合、Snowflakeのウェブインターフェイスの Shares 
ページを使用して、共有の作成と管理に関連するほとんどのタスクを実行できます。
実行できるタスクは、共有が Outbound か Inbound かによって異なります。
アウトバウンド共有（プロバイダー）
アウトバウンド共有は、コンシューマーアカウントとデータを共有する目的でアカウントによって作成されます。ウェブインターフェイスでは、アウトバウンド共有に対して次のタスクを実行できます。
作成した共有、またはアクセスする権限がある共有の表示。提供される情報には、共有のデータベースと、共有に追加されたコンシューマーアカウント（存在する場合）が含まれます。
共有の作成。
コンシューマーアカウントの共有への追加。アカウントを追加するときに、フルアカウントまたはリーダーアカウントの追加を選択できます。また、その場でリーダーアカウントを作成し、共有に追加することもできます。
以下を含む共有を編集します。
共有をドロップします。これにより、共有用にコンシューマーによって作成されたすべてのデータベースが直ちに無効になります。
インバウンド共有（コンシューマー）
インバウンド共有は、プロバイダーアカウントによってアカウントと共有されます。ウェブインターフェイスでは、インバウンド共有に対して次のタスクを実行できます。
共有用のデータベースが作成されると、データベースで実行する他のすべてのタスク（データベースのドロップなど）は Databases 
ページから実行されます。
共有を作成する準備
共有を作成する前に、共有する予定のSnowflakeオブジェクトを特定することをお勧めします。
データベース
テーブル
外部テーブル
セキュアビュー
安全なマテリアライズドビュー
安全な UDFs
これにより、特にテーブルのデータのサブセットのみを共有することにした場合、追加の計画および管理タスクが必要になる可能性があります。
データベースとテーブル
データベースを共有するための準備はほとんど必要ありません。同様に、データベース内のテーブル全体を共有することを選択した場合の準備は不要です。
ただし、特定の条件に基づいて、またはコンシューマーアカウントによって、テーブル（またはテーブルのセット）のデータをフィルター処理する場合、1つ以上のセキュリティでセキュアビューをテーブルに作成する必要があります。
セキュアオブジェクト（ビュー、マテリアライズドビュー、および UDFs）
共有データベース内のデータへのアクセスを厳密に制御するには、 セキュアビュー、 セキュアマテリアライズドビュー および/または セキュア UDFs を使用する 必要 があります。たとえば、日付やその他の条件でデータをフィルターすることを選択したり、単一の共有を使用して異なるコンシューマーアカウントの共有データを分割したりできます。セキュアオブジェクトを使用すると、ベーステーブルとビジネスロジックが公開されないようにしながら、データに適用する細分性のレベルを指定できます。
セキュアオブジェクトは、対応する CREATE <オブジェクト> または ALTER <オブジェクト> コマンドを使用して、標準オブジェクトと同様に定義されます。ただし、次の重要な使用情報に注意します。
完全修飾名（つまり、 <データベース名>.<スキーマ名>.<テーブル名> ）でテーブルを参照する安全なオブジェクトは、共有に含めることができます。ただし、参照されるデータベース名が共有のデータベースと 一致 することを確認する必要があります。
定義に CURRENT_USER または CURRENT_ROLE 関数を使用するセキュアオブジェクトを含め ない でください。これらの関数によって返されるコンテキスト値は、コンシューマーのアカウントに関連性がなく、クエリ/使用時にオブジェクトが失敗します。
安全なオブジェクトを定義してコンシューマーアカウントと共有する場合、実行する重要な追加のステップは、表示するデータのみを表示するようにオブジェクトが正しく構成されていることを検証することです。これは、データが共有されるアカウントに基づいてデータアクセスを制限する場合に特に重要です。
この検証の実行を容易にするために、Snowflakeは、 SIMULATED_DATA_SHARING_CONSUMER セッションパラメーターを提供します。
現時点では、 SIMULATED_DATA_SHARING_CONSUMER セッションパラメーターは、セキュアビューとセキュアマテリアライズドビューのみをサポートしており、セキュア UDFs はサポートしていません。セッションでこのパラメーターを設定すると、ビューを共有する予定のコンシューマーアカウント内にあるいずれかのユーザーとして、セキュアビューのクエリをシミュレートできます。
たとえば、 xy12345 という名前のコンシューマアカウントの場合は、
ALTER SESSION SET SIMULATED_DATA_SHARING_CONSUMER = xy12345;
詳細な例については、 セキュアオブジェクトを使用したデータアクセスの制御 をご参照ください。
共有オブジェクトのストリーム
データコンシューマーは、ソーステーブルまたはビューに加えられたデータ操作言語（DML）の変更を記録するストリームを独自のデータベースに作成できます。
データコンシューマーによる、共有テーブルへのテーブルストリームの作成を有効化
データコンシューマーが共有テーブルまたはセキュアビューにストリームを作成するには、共有テーブルまたは共有ビューの基になるテーブルで変更追跡を有効にする必要があります。
さらに、テーブルのデータ保持期間を延長する必要があります。
- 変更の追跡を有効にする
現在、ローカルテーブルの最初のストリームが作成されると、非表示の列のペアがテーブルに自動的に追加され、変更追跡メタデータの保存が開始されます。共有のコンシューマーはソースデータベースを変更できないため、この変更は共有テーブルでは不可能です。代わりに、共有を目的としたテーブルの変更の追跡を有効にするには、各テーブルで ALTER TABLE ... CHANGE_TRACKING = TRUE を実行します。
- テーブルのデータ保持期間を延長する
ローカルテーブルのストリームが定期的に消費されない場合、Snowflakeは古さを回避するために、ソーステーブルのデータ保持期間を一時的に延長します。
共有テーブルのストリームは、テーブルのデータ保持期間を延長しません。同様に、共有ビューのストリームは、基になるテーブルのデータ保持期間を延長しません。共有テーブルまたは共有ビューの基になるテーブルに長期のデータ保持期間を手動で指定するには、テーブルの DATA_RETENTION_TIME_IN_DAYS パラメーターを設定します。
CHANGE_TRACKING および DATA_RETENTION_TIME_IN_DAYS パラメータは、テーブルを作成するときに（ CREATE TABLE を使用して）または後で（ ALTER TABLE を使用して）設定できます。
SQLを使用した共有の作成
SQLを使用して共有を作成するには、
CREATE SHARE コマンドを使用して、空の共有を作成します。
GRANT <権限> ... TO SHARE コマンドを使用してデータベースを共有に追加し、特定のデータベースオブジェクト（スキーマ、テーブル、およびセキュアビュー）へのアクセスを共有に選択的に許可します。
ALTER SHARE コマンドを使用して、共有への1つ以上のアカウントアクセスを追加します。
注釈
次の手順では、 prvdr1 という名前のプロバイダーアカウントが、 xy12345 および yz23456 という名前の2つのコンシューマアカウントとデータを共有していることを前提としています。
ステップ1：空の共有を作成する
次の例では、 sales_s という名前の空の共有を作成します。
ステップ2：共有にデータベースおよびオブジェクトへの権限を付与する
オブジェクト（データベース、スキーマ、テーブル、セキュア ビューなど）を共有に追加します。これらのオブジェクトに対する権限をデータベースロール経由で共有に追加するか、オブジェクトに対する権限を共有に直接付与するかの いずれか を選択できます。これらのオプションの詳細については、 データベースオブジェクトの共有方法の選択 をご参照ください。
- オプション1
次の例は、データベースロールを作成し、次のオブジェクトに対する権限をデータベースロールに付与してから、前のステップで作成した sales_s 共有にデータベースロールを付与する方法を示しています。
sales_db （データベース）
aggregates_eula （スキーマ）
aggregate_1 （テーブル）
CREATE DATABASE ROLE sales_db.dr1;
GRANT USAGE ON DATABASE sales_db TO DATABASE ROLE sales_db.dr1;
GRANT USAGE ON SCHEMA sales_db.aggregates_eula TO DATABASE ROLE sales_db.dr1;
GRANT SELECT ON TABLE sales_db.aggregates_eula.aggregate_1 TO DATABASE ROLE sales_db.dr1;
GRANT USAGE ON DATABASE sales_db TO SHARE sales_s;
GRANT DATABASE ROLE sales_db.dr1 TO SHARE sales_s;
- オプション2
共有にオブジェクトを含めるには、各オブジェクトに権限を付与します。権限を付与する場合、コンテナーオブジェクトの使用を許可する前に、まずコンテナー内のオブジェクトの使用を許可します。たとえば、データベースに含まれるスキーマの使用を許可する前に、データベースの使用を許可します。
注釈
アカウントを共有に追加する前に、このタスクを実行します。データベースの使用を許可する前にアカウントを追加しようとすると、エラーが発生します。
次の例は、前の手順で作成した sales_s 共有に次のオブジェクトの権限を付与する方法を示しています。
sales_db （データベース）
aggregates_eula （スキーマ）
aggregate_1 （テーブル）
GRANT USAGE ON DATABASE sales_db TO SHARE sales_s;
GRANT USAGE ON SCHEMA sales_db.aggregates_eula TO SHARE sales_s;
GRANT SELECT ON TABLE sales_db.aggregates_eula.aggregate_1 TO SHARE sales_s;
共有の内容を確認するには、
SHOW GRANTS TO SHARE sales_s;
+-------------------------------+-----------+------------+--------------------------------------+------------+----------------+--------------+--------------+
| created_on | privilege | granted_on | name | granted_to | grantee_name | grant_option | granted_by |
|-------------------------------+-----------+------------+--------------------------------------+------------+----------------+--------------+--------------|
| 2017-06-15 16:45:07.307 -0700 | USAGE | DATABASE | SALES_DB | SHARE | PRVDR1.SALES_S | false | ACCOUNTADMIN |
| 2017-06-15 16:45:10.310 -0700 | USAGE | SCHEMA | SALES_DB.AGGREGATES_EULA | SHARE | PRVDR1.SALES_S | false | ACCOUNTADMIN |
| 2017-06-15 16:45:12.312 -0700 | SELECT | TABLE | SALES_DB.AGGREGATES_EULA.AGGREGATE_1 | SHARE | PRVDR1.SALES_S | false | ACCOUNTADMIN |
+-------------------------------+-----------+------------+--------------------------------------+------------+----------------+--------------+--------------+
これにより、共有が他のアカウントで使用できるようになる前に、共有が正しく構成されます。
ステップ3：アカウントを共有に追加する
注意
Business Criticalアカウントを所有しており、消費者アカウントとデータを共有している場合：
Snowflakeは、非Business Criticalアカウントとの機密データの共有をサポートしています（デフォルトでは無効）が、そうすることを推奨 しません 。
HIPAA と HITRUST 要件への準拠を確保するために、Snowflakeは、HIPAA アカウントが非 HIPAA アカウントとデータを共有することを許可 しません 。
Tri-Secret Secureデータ保護を使用している場合、Snowflakeは、ユーザーアカウントからのデータアクセスを自分のアカウント内から発生したかのように扱います。
これらの推奨事項と制限の詳細については、 データ共有とBusiness Criticalアカウント をご参照ください。
次の例では、2つのアカウントを sales_s 共有に追加します。
ALTER SHARE sales_s ADD ACCOUNTS=xy12345, yz23456;
アカウント xy12345 および yz23456 は共有を表示し、そこからデータベースを作成できるようになりました。
注釈
アカウントを共有に追加するときに、アカウントが存在しない場合、コマンドは正常に完了しますが、共有は更新されません。共有が適切に更新されるようにするには、アカウントが存在し、名前を正しく入力したことを確認します。
SHOW SHARES を使用して共有を確認します。コマンドの出力には、 sales_s 共有がリストされます。 kind 列は、共有が OUTBOUNDであることを示します。これは、この共有が他のSnowflakeアカウントとデータベースを共有していることを意味します。 to 列には、共有が使用可能になったすべてのアカウントがリストされます。
SHOW SHARES;
+-------------------------------+----------+-------------------------+-----------------------+------------------+--------------+----------------------------------------+
| created_on | kind | name | database_name | to | owner | comment |
|-------------------------------+----------+-------------------------+-----------------------+------------------+--------------+----------------------------------------|
| 2016-07-09 19:18:09.821 -0700 | INBOUND | SFC_SAMPLES.SAMPLE_DATA | SNOWFLAKE_SAMPLE_DATA | | | Sample data sets provided by Snowflake |
| 2017-06-15 17:02:29.625 -0700 | OUTBOUND | PRVDR1.SALES_S | SALES_DB | XY12345, YZ23456 | ACCOUNTADMIN | |
+-------------------------------+----------+-------------------------+-----------------------+------------------+--------------+----------------------------------------+
SQL を使用した共有の維持
共有からデータベースを作成したコンシューマーの表示
共有からデータベースを作成したアカウントを表示するには、 SHOW GRANTS OF SHARE コマンドを使用します。これは、 SHOW SHARESによって返されるアカウントのリストとは異なります。
たとえば、次の例に示します。
2つの共有、 prvdr1.sales_s および prvdr1.sales_s2 がアカウント xy12345 および yz23456 で利用可能になりました。
アカウント xy12345 は、 prvdr1.sales_s 共有からデータベースを作成しました。
prvdr1.sales_s2 共有からデータベースを作成したアカウントはありません。
SHOW SHARES;
+-------------------------------+----------+-------------------------+-----------------------+------------------+--------------+----------------------------------------+
| created_on | kind | name | database_name | to | owner | comment |
|-------------------------------+----------+-------------------------+-----------------------+------------------+--------------+----------------------------------------|
| 2016-07-09 19:18:09.821 -0700 | INBOUND | SFC_SAMPLES.SAMPLE_DATA | SNOWFLAKE_SAMPLE_DATA | | | Sample data sets provided by Snowflake |
| 2017-06-15 17:02:29.625 -0700 | OUTBOUND | PRVDR1.SALES_S | SALES_DB | XY12345, YZ23456 | ACCOUNTADMIN | |
| 2017-06-15 17:02:29.625 -0700 | OUTBOUND | PRVDR1.SALES_S2 | SALES_DB | XY12345, YZ23456 | ACCOUNTADMIN | |
+-------------------------------+----------+-------------------------+-----------------------+------------------+--------------+----------------------------------------+
SHOW GRANTS OF SHARE sales_s;
+-------------------------------+----------------+------------+----------+
| created_on | share | granted_to | account |
|-------------------------------+----------------+------------+----------|
| 2017-06-15 18:00:03.803 -0700 | PRVDR1.SALES_S | ACCOUNT | XY12345 |
+-------------------------------+----------------+------------+----------+
SHOW GRANTS OF SHARE sales_s2;
+------------+-------+------------+---------+
| created_on | share | granted_to | account |
|------------+-------+------------+---------|
+------------+-------+------------+---------+
共有へのオブジェクトの追加
GRANT <権限> ... TO SHARE コマンドを使用して、いつでも既存の共有にオブジェクトを追加できます。共有に追加したオブジェクトは、共有からデータベースを作成したコンシューマーアカウントですぐに利用できます。たとえば、共有にテーブルを追加すると、コンシューマーアカウントのユーザーは、テーブルが共有に追加されるとすぐにテーブル内のデータをクエリできます。
次の例では、 aggregates_eula スキーマの agg_secure という名前のセキュアビューを sales_s 共有に追加します。
SHOW GRANTS TO SHARE sales_s;
+-------------------------------+-----------+------------+--------------------------------------+------------+----------------+--------------+--------------+
| created_on | privilege | granted_on | name | granted_to | grantee_name | grant_option | granted_by |
|-------------------------------+-----------+------------+--------------------------------------+------------+----------------+--------------+--------------|
| 2017-06-15 16:45:07.307 -0700 | USAGE | DATABASE | SALES_DB | SHARE | PRVDR1.SALES_S | false | ACCOUNTADMIN |
| 2017-06-15 16:45:10.310 -0700 | USAGE | SCHEMA | SALES_DB.AGGREGATES_EULA | SHARE | PRVDR1.SALES_S | false | ACCOUNTADMIN |
| 2017-06-15 16:45:12.312 -0700 | SELECT | TABLE | SALES_DB.AGGREGATES_EULA.AGGREGATE_1 | SHARE | PRVDR1.SALES_S | false | ACCOUNTADMIN |
+-------------------------------+-----------+------------+--------------------------------------+------------+----------------+--------------+--------------+
GRANT SELECT ON VIEW sales_db.aggregates_eula.agg_secure TO SHARE sales_s;
SHOW GRANTS TO SHARE sales_s;
+-------------------------------+-----------+------------+--------------------------------------+------------+----------------+--------------+--------------+
| created_on | privilege | granted_on | name | granted_to | grantee_name | grant_option | granted_by |
|-------------------------------+-----------+------------+--------------------------------------+------------+----------------+--------------+--------------|
| 2017-06-15 16:45:07.307 -0700 | USAGE | DATABASE | SALES_DB | SHARE | PRVDR1.SALES_S | false | ACCOUNTADMIN |
| 2017-06-15 16:45:10.310 -0700 | USAGE | SCHEMA | SALES_DB.AGGREGATES_EULA | SHARE | PRVDR1.SALES_S | false | ACCOUNTADMIN |
| 2017-06-15 16:45:12.312 -0700 | SELECT | TABLE | SALES_DB.AGGREGATES_EULA.AGGREGATE_1 | SHARE | PRVDR1.SALES_S | false | ACCOUNTADMIN |
| 2017-06-17 12:33:15.310 -0700 | SELECT | TABLE | SALES_DB.AGGREGATES_EULA.AGG_SECURE | SHARE | PRVDR1.SALES_S | false | ACCOUNTADMIN |
+-------------------------------+-----------+------------+--------------------------------------+------------+----------------+--------------+--------------+
共有からのオブジェクトの削除
REVOKE <権限> ... FROM SHARE コマンドを使用して、既存の共有からいつでもオブジェクトを削除できます。共有から削除したオブジェクトは、共有からデータベースを作成したコンシューマーアカウントではすぐに使用できなくなります。たとえば、共有からテーブルを削除すると、コンシューマーアカウントのユーザーは、共有からテーブルが削除されるとすぐにテーブル内のデータをクエリできなくなります。
次の例では、 aggregates_eula スキーマの agg_secure という名前のセキュアビューを sales_s 共有から削除します。
SHOW GRANTS TO SHARE sales_s;
+-------------------------------+-----------+------------+--------------------------------------+------------+----------------+--------------+--------------+
| created_on | privilege | granted_on | name | granted_to | grantee_name | grant_option | granted_by |
|-------------------------------+-----------+------------+--------------------------------------+------------+----------------+--------------+--------------|
| 2017-06-15 16:45:07.307 -0700 | USAGE | DATABASE | SALES_DB | SHARE | PRVDR1.SALES_S | false | ACCOUNTADMIN |
| 2017-06-15 16:45:10.310 -0700 | USAGE | SCHEMA | SALES_DB.AGGREGATES_EULA | SHARE | PRVDR1.SALES_S | false | ACCOUNTADMIN |
| 2017-06-15 16:45:12.312 -0700 | SELECT | TABLE | SALES_DB.AGGREGATES_EULA.AGGREGATE_1 | SHARE | PRVDR1.SALES_S | false | ACCOUNTADMIN |
| 2017-06-17 12:33:15.310 -0700 | SELECT | TABLE | SALES_DB.AGGREGATES_EULA.AGG_SECURE | SHARE | PRVDR1.SALES_S | false | ACCOUNTADMIN |
+-------------------------------+-----------+------------+--------------------------------------+------------+----------------+--------------+--------------+
REVOKE SELECT ON VIEW sales_db.aggregates_eula.agg_secure FROM SHARE sales_s;
+-------------------------------+-----------+------------+--------------------------------------+------------+----------------+--------------+--------------+
| created_on | privilege | granted_on | name | granted_to | grantee_name | grant_option | granted_by |
|-------------------------------+-----------+------------+--------------------------------------+------------+----------------+--------------+--------------|
| 2017-06-15 16:45:07.307 -0700 | USAGE | DATABASE | SALES_DB | SHARE | PRVDR1.SALES_S | false | ACCOUNTADMIN |
| 2017-06-15 16:45:10.310 -0700 | USAGE | SCHEMA | SALES_DB.AGGREGATES_EULA | SHARE | PRVDR1.SALES_S | false | ACCOUNTADMIN |
| 2017-06-15 16:45:12.312 -0700 | SELECT | TABLE | SALES_DB.AGGREGATES_EULA.AGGREGATE_1 | SHARE | PRVDR1.SALES_S | false | ACCOUNTADMIN |
+-------------------------------+-----------+------------+--------------------------------------+------------+----------------+--------------+--------------+
共有へのアカウントの追加
ALTER SHARE コマンドを使用して、いつでも既存の共有にアカウントを追加できます。アカウントが共有に追加されると、共有はすぐにアカウントに「表示」され、アカウントは共有からデータベースを作成し、データベース内のSnowflakeオブジェクトのクエリを開始できます。
共有からのアカウントの削除
ALTER SHARE コマンドを使用して、既存の共有からいつでもアカウントを削除できます。共有からアカウントを削除すると、共有から作成したデータベースが即座に無効になります。アカウントのユーザーがデータベースに対して実行するすべてのクエリ、およびその他の操作は機能しなくなります。
共有のアカウントの新しいリストを設定し、目的のアカウントをリストから外して、共有からアカウントを削除します。
共有からアカウントを削除した後、共有に再度追加できます。ただし、以前に共有から作成したデータベースは復元されません。共有から新しいデータベースを作成する必要があります。
注釈
共有からアカウントを削除する前に、アカウントの削除がアカウントに与えるダウンストリームの影響を考慮します。データベースは即座に無効になるため、ユーザー（アカウント内）がデータベースに対して実行するすべてのクエリやその他の操作は機能しなくなり、アカウントのビジネスオペレーションに大きな影響を与える可能性があります。
共有のドロップ
DROP SHARE コマンドを使用して、いつでも共有をドロップできます。共有をドロップすると、共有からコンシューマーアカウントによって作成されたすべてのデータベースが即座に無効になります。これらのデータベースで実行されるすべてのクエリおよびその他の操作は機能しなくなります。
共有をドロップした後、同じ名前で共有を再作成できます。ただし、これにより、コンシューマーアカウントによる共有から作成されたデータベースは復元されません。再作成された共有は新しい共有として扱われ、すべてのコンシューマーアカウントは新しい共有から新しいデータベースを作成する必要があります。
注釈
共有をドロップする前に、共有を使用するすべてのコンシューマーアカウントに与えるダウンストリームの影響を考慮します。
代わりに、共有から個々のオブジェクトを削除することも検討できます。削除されたオブジェクトは、コンシューマーアカウントの側で追加のタスクを必要とせずに共有に追加できます。
すべてのアカウントでプロバイダー共有が有効になっていません