# 権限と継承
GitBook には柔軟な権限モデルがあり、必要に応じて権限を大きくも小さくも管理できます。GitBook の権限モデルは [**ロールベースの**](https://gitbook.com/docs/documentation/ja-gitbook-documentation/akaunto/roles#roles-in-gitbook)**、カスケード型の** モデルです。つまり、既定値を設定し、その後はコンテンツの任意の階層で、その既定値を継承するかどうかを決めます。
権限は 4 つのレベルで設定できます。 **組織**, **サイト**, **コレクション**、および **スペース**.
### 組織のデフォルトロール
組織にメンバーを追加するときに、 [そのメンバーのデフォルトロール](https://gitbook.com/docs/documentation/ja-gitbook-documentation/akaunto/member-management/roles)を設定します。このロールは、組織のデフォルト設定から権限を継承するあらゆるコンテンツに適用されます。
### 権限の継承の仕組み
GitBook の権限は、上から下へ 4 つのレベルを通って流れます。
* **組織** — 各メンバーに設定されるデフォルトロール
* **サイト** — ドキュメントサイトに設定される権限で、継承モードのすべてのリンク済みスペースに適用されます
* **コレクション** — コレクションに設定される権限で、その中のすべてのスペースに適用されます
* **スペース** — 権限を直接設定できる基本レベル
スペースが継承モードにある場合、各メンバーには、適用可能なすべてのレベルの中で持っている **最も高いロール** が割り当てられます。たとえば、あるメンバーが組織レベルでは Creator、サイトレベルでは Commenter の場合、そのスペースでは Creator の権限が維持されます。
実際の動作を示す例を 2 つ紹介します。
例 1
あるメンバーは組織レベルで Creator のロールを持っています。あるスペースは継承モードで、誰かがサイト権限を Commenter に設定します。Creator は Commenter より上位なので、その Creator はそのスペースで Creator の権限を維持します。組織内の他の人もそれぞれの既存ロールを維持します。ただし Reader は、Commenter のほうが Reader より上位のため、Commenter に引き上げられます。
例 2
あるコレクションには Reader 権限があり、5 人のメンバーが明示的に Creator に設定されています。そのコレクション内のあるスペースは継承モードで、誰かがサイト権限を Commenter に設定します。Commenter はコレクションの Reader 権限より上位なので、組織内の全員がそのスペースでは Commenter に昇格します。名前付きの 5 人の Creator は、Creator のほうが Commenter より上位なので、Creator の権限を維持します。
{% hint style="info" %}
**注:** サイト権限は継承モードのスペースにのみ適用されます。スペースに独自の権限設定がある場合、つまり継承モードではない場合は、そちらが優先され、サイトレベルの権限は影響しません。
{% endhint %}
### 継承の管理
コレクションやスペースを作成するときはいつでも、希望する継承タイプを設定できます。コンテンツの継承を設定するときの主な選択肢は 3 つあります。
### 継承
継承を **継承** に設定すると、スペースまたはコレクションは **親レベルのコンテンツ**に割り当てられたロールを継承します。最上位のスペースやコレクションの場合、この親は組織なので、組織のデフォルトロールを継承します。コレクション内のスペースやサブコレクションの場合、親はそのコンテンツが属するコレクションになります。
スペースがサイトにリンクされている場合、サイト権限も継承ロールに反映されます。各メンバーには、組織ロール、サイト権限、コレクションレベルの権限の中で最も高いロールが付与されます。
### 特定ロールのアクセス
コレクションまたはスペースの権限継承を設定するときに特定のロールを選択すると、 **リセット** され、組織のデフォルトロールが上書きされて、そのコレクションまたはスペース内のすべての **管理者以外** にそのロールが割り当てられます。たとえば、継承を **reader**に設定すると、デフォルトロールに関係なく、組織内の全員がそのスペースまたはコレクションを読み取り専用で利用できるようになります。
ここでも最上位ロールの原則は適用されます。別のレベル（たとえばスペースに直接設定されている、またはチームの上書き経由など）でより高いロールが設定されている場合は、その高いロールが維持されます。
### アクセスなし
また、スペースまたはコレクションのレベルで、管理者以外の組織メンバーからのアクセスを完全に取り消すこともできます。これにより、管理者と、そのスペースまたはコレクションを作成した人以外にはコンテンツが非表示になります。
{% hint style="info" %}
新しく作成されたスペースまたはコレクションのデフォルト継承オプションは **継承**です。つまり、コンテンツが作成されるたびに、既定では親から権限を継承します。
{% endhint %}
### コンテンツ固有の権限を設定する
スペースまたはコレクションの権限継承を決めたら、さらにチームやメンバーに **直接アクセス**.
### チームに直接アクセスを付与する
特定のロールを付けてチームをコレクションまたはスペースに直接追加できます。これにより、そのチームの全員に、そのコンテンツへの指定したアクセス権が付与されます。
{% hint style="info" %}
チームアクセスは、適切な人が適切なコンテンツにアクセスできるようにするのに最適です。誰かがチームに追加されたり削除されたりするたびに、その人はコンテンツに設定された権限を、それぞれ取得または失います。
{% endhint %}
### メンバーに直接アクセスを付与する
チームと同様に、メンバーにも直接アクセスを付与できます。これは権限を管理するうえで最も細かく制御できる方法です。個別のメンバーにコレクションまたはスペースへの直接アクセスを付与すると、その人が持つ可能性のある継承権限を上書きします。コラボレーターを非常に細かく制御する必要がある場合は、メンバーへの直接アクセスが最適です。
スペースレベルで直接アクセスを持つメンバーは、継承パターンから完全に除外されます。彼らのロールは明示的に設定され、組織、サイト、またはコレクションレベルの権限の影響を受けません。
### 権限を常に把握する
最初はかなり複雑に見えるかもしれませんが、GitBook の権限モデルは、必要なときにはしっかり制御でき、不要なときには意識せずに済みます。多くのチームにとっては、 **設定してそのままにする** 権限管理のアプローチだけで十分です。別のチーム、特に大規模な組織では、このレベルのアクセスとワークフローの制御が不可欠です。
#### 設定してそのままにする
チームメンバーを招待して、一緒にコンテンツを編集できればよいだけなら、権限をまったく確認しないままでもよいかもしれません。人を招待し、デフォルトロールを設定すれば、作成するコンテンツはすべて既定でこれらのロールを継承します。細かい設定に深入りする必要はありません。
#### アクセスとワークフローの制御
大規模な組織、組織を複数の明確なコレクションに分けているチーム、またはワークフローを非常に細かく制御する必要があるチームにとっては、細部まで設定することこそが必要です。継承、上書き、チームへの直接アクセス、ユーザーへの直接アクセスを組み合わせることで、管理を維持しながらワークフローとアクセスモデルを構築できます。