> For the complete documentation index, see [llms.txt](https://gitbook.com/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://gitbook.com/docs/documentation/ja-gitbook-documentation/collaborate/member-management/permissions-and-inheritance.md).
# 権限と継承
GitBook で権限がどのように機能するか、誰がコンテンツにアクセス・編集できるかを制御する方法を理解しましょう
GitBook には柔軟な権限モデルがあり、必要に応じて権限を細かく、あるいは最小限に制御できます。GitBook の権限モデルは [**ロールベースの**](/docs/documentation/ja-gitbook-documentation/collaborate/member-management/roles.md#roles-in-gitbook)**、継承連鎖する** モデルです。つまり、まず既定値を設定し、その後はコンテンツの任意の階層で、その既定値を継承するかどうかを決めます。
権限は 4 つのレベルで設定できます: **組織**, **site**, **コレクション**を読み取り、 **space**.
### 組織の既定ロール
メンバーを組織に追加するときに、 [そのメンバーの既定ロール](/docs/documentation/ja-gitbook-documentation/collaborate/member-management/roles.md). このロールは、権限を組織の既定値から継承するあらゆるコンテンツに適用されます。
### 権限の継承の流れ
GitBook の権限は、 **優先順位**で解決され、すべてのレベルの中で最も高いロールで決まるわけではありません。
継承モードのスペースでは、GitBook は次の順序でアクセス権を解決します:
* **スペースキーを** — スペース上のメンバーおよびチームによる直接上書き
* **Site** — 親サイトの権限
* **コレクション** — 親コレクションの権限（存在する場合）
* **組織** — 各メンバーに設定された既定ロール
つまり、継承モードのリンク済みスペースでは、サイトの権限が組織の既定値と親コレクションの既定値より優先されます。ただし、スペースレベルでの直接上書きは、引き続き他のすべてより優先されます。
実際にこれがどのように機能するか、2 つの例を示します:
例 1
あるメンバーは組織レベルで Creator ロールを持っています。リンク済みスペースは継承モードで、親サイトはそのメンバーを Commenter に設定しています。このメンバーはそのスペースで Commenter アクセスを取得します。サイトが組織の既定値より優先されるためです。
例 2
あるコレクションはスペースを Reader に設定し、親サイトはそれを Commenter に設定しています。継承モードではサイトの権限が親コレクションより優先されるため、そのスペースでは Commenter が使用されます。さらに、ある 1 人のメンバーにそのスペースで直接 Creator アクセスを付与すると、そのメンバーに対してはその直接上書きが優先されます。
{% hint style="info" %}
**注：** サイトの権限は、継承モードのスペースにのみ適用されます。スペースに独自の権限設定がある場合、つまり継承モードではない場合は、それが優先され、サイトレベルの権限は影響しません。
{% endhint %}
### 継承の管理
コレクションやスペースを作成するたびに、希望する継承タイプを設定できます。コンテンツの継承を設定するときには、主に 3 つの選択肢があります:
### 継承する
継承を **継承** に設定すると、スペースまたはコレクションは **親レベルのコンテンツ**で割り当てられたロールを継承します。最上位のスペースやコレクションでは、この親は組織になるため、組織の既定ロールを継承します。コレクション内のスペースやサブコレクションでは、親はそのコンテンツが属するコレクションになります。
スペースがサイトにリンクされ、継承モードのままである場合、GitBook は次の順序でアクセス権を解決します: 直接のスペース上書き、次に親サイト、次に親コレクション、最後に組織。サイトの権限は組織およびコレクションの既定値より優先されますが、直接のスペースレベル上書きは変更しません。
### 特定のロールへのアクセス
コレクションまたはスペースの権限継承を設定するときに特定のロールを選択すると、 **リセット** され、組織の既定ロールが **管理者以外の** 全員に、そのコレクションまたはスペース内でそのロールを割り当てます。たとえば、継承を **reader**に設定すると、既定ロールに関係なく、組織内の全員がそのスペースまたはコレクションを閲覧のみ可能になります。
そのコレクションまたはスペースでメンバーやチームに直接アクセス権を付与している場合は、この継承設定を上書きできます。スペース自体に特定のロールを設定すると、そのスペースはもはや継承モードを使用しないため、サイトの権限は影響しません。
### アクセス権なし
また、スペースまたはコレクションのレベルで、管理者以外の組織メンバーのアクセス権を完全に取り消すこともできます。これにより、管理者とそのスペースまたはコレクションを作成した人以外にはコンテンツが表示されなくなります。
{% hint style="info" %}
新しく作成されたスペースまたはコレクションの既定の継承オプションは **継承**です。これは、コンテンツが作成されるたびに、既定で親から権限を継承することを意味します。
{% endhint %}
### コンテンツ固有の権限を設定する
スペースまたはコレクションの権限継承を決めたら、さらにチームやメンバーに **直接アクセス権**.
### チームに直接アクセス権を付与する
特定のロールを指定して、チームをコレクションまたはスペースに直接追加できます。これにより、そのチームの全員に、指定したアクセス権がそのコンテンツに付与されます。
{% hint style="info" %}
チームへのアクセス権付与は、適切な人に適切なコンテンツへのアクセスを確実に与える優れた方法です。誰かがチームに追加されたり削除されたりすると、その人はコンテンツに設定された権限をそれぞれ取得または失います。
{% endhint %}
### メンバーに直接アクセス権を付与する
チームと同様に、メンバーに直接アクセス権を付与することもできます。これは、権限を管理する最も細かい方法です。個々のメンバーにコレクションまたはスペースへの直接アクセス権を付与すると、そのメンバーが持つ可能性のある継承権限を上書きします。コラボレーターを非常に細かく制御する必要がある場合、メンバーへの直接アクセス権は最適です。
スペースレベルで直接アクセス権を持つメンバーは、継承パターンから完全に外れます。ロールは明示的に設定され、組織、サイト、またはコレクションレベルの権限の影響を受けません。
### 権限を常に把握する
最初はかなり複雑に見えるかもしれませんが、GitBook の権限モデルは必要なときには制御を可能にし、不要なときには前面に出ません。多くのチームにとっては、 **設定したら放置する** 権限管理のアプローチだけで十分です。ほかのチーム、特に大規模な組織では、このレベルのアクセスとワークフローの制御が不可欠です。
#### 設定したら放置
チームメンバーを招待して一緒にコンテンツを編集できるようにしたいだけなら、権限を確認する必要すらないかもしれません。人を招待し、既定ロールを設定すれば、あなたが作成するコンテンツはすべて自動的にこれらのロールを継承します。細かな設定に入り込む必要はありません。
#### アクセスとワークフローの制御
より大規模な組織、組織を個別のコレクションに分けるチーム、またはワークフローをきめ細かく制御する必要があるチームにとっては、細部まで踏み込むことこそがまさに必要なことです。継承、上書き、チームへの直接アクセス、ユーザーへの直接アクセスを組み合わせることで、制御を維持しながらワークフローとアクセスモデルを構築できます。
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://gitbook.com/docs/documentation/ja-gitbook-documentation/collaborate/member-management/permissions-and-inheritance.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.