> 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/merge-rules.md).

# マージルール

変更リクエストをマージする前に満たす必要がある要件を定義します

マージルールを使うと、変更リクエストをマージする前に満たす必要がある要件を定義できます。たとえば、特定のユーザーによるレビューを必要にしたり、変更リクエストに件名や説明の入力を必須にしたりできます。

これらのルールはコンテンツの品質を維持し、ドキュメントのワークフロー全体で適切なレビュープロセスを確保するのに役立ちます。

マージルールを設定すると、変更リクエストがマージ可能かどうかを自動的に評価します。ルールが満たされていない場合、要件が満たされるまでマージはブロックされます。

これにより、チームのコラボレーション基準とレビュースタンダードを自動的に適用できます。

## マージルールの使用

チームのワークフローに合わせて、さまざまなレベルでマージルールを設定できます。

### 組織レベルの設定

組織では、すべてのセクションが継承する既定のマージルールを設定できます。これにより、複数のセクション間で一貫性を保ちながら、必要に応じて各セクションが個別にルールをカスタマイズすることもできます。

組織のマージルールを設定するには、組織の **ホーム** に戻って **設定** <picture><source srcset="/files/CG9bVSmdbJnQxrYiNbRI" media="(prefers-color-scheme: dark)"><img src="https://4217681718-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FNkEGS7hzeqa35sMXQZ4X%2Fuploads%2FwkBqgOPry9HAcW4cxJk0%2Fsettings.svg?alt=media&amp;token=67bdbb00-ebf3-4a2d-9df8-0c822406f71c" alt=""></picture>、 **管理** をサイドバーでクリックします。設定画面で **マージルール** の **組織** グループをクリックします。ここで組織全体のマージルールを指定できます。

制限なしのマージを選ぶか、プリセット一覧から選択して組織全体の変更リクエストに適用できます。

### セクションレベルの設定

組織全体のマージルールを有効にしているかどうかにかかわらず、各セクションにはコンテンツやチーム構成に合わせた独自のマージ要件を設定できます。

これにより、重要なドキュメントにはより厳しいルールを、下書きコンテンツにはより緩やかなルールを適用できます。

セクションのマージルールを設定するときは、次のいずれかを選べます。

* **継承する** 組織のマージルールを
* **カスタムルールを定義する** そのセクション専用の
* **マージルールを無効にする** 完全に

{% hint style="info" %}
組織のルールを継承すると、組織のマージルールへの変更は自動的にそのセクションに適用されます。
{% endhint %}

セクションのマージルールを設定するには、エディタ左上の **操作メニュー** <i class="fa-ellipsis">:ellipsis:</i> エディタ左上の **マージルール**。ここで、組織のマージルールを継承するか、そのセクション専用の新しいルールを設定するかを指定できます。

## ルールの評価

### ルールの仕組み

誰かが変更リクエストをマージしようとすると、GitBook は設定されたすべてのルールを順に評価します：

* マージを許可するには、構成内のすべてのルールを通過する必要があります
* ルールは設定に表示されている順序で評価されます
* いずれかのルールに失敗すると、適切なエラーメッセージとともにマージはブロックされます
* バイパス機能のあるルールは、それ以前の失敗を上書きできます

### バイパスルール

一部のルールにはバイパス機能があります（たとえば **指定したアクターに要件のバイパスを許可**）。これらの特別なルールは他のルールの失敗を上書きできます。バイパスルールが true と評価されると、他のルールが失敗していてもマージは許可されます。

## ベストプラクティス

マージルールを設定する際は、次の推奨事項を参考にしてください：

* **シンプルに始める**：まずは、少なくとも1件のレビューを必須にするなどの基本的なルールから始めます。
* **段階的に拡大する**：チームの成長とワークフローの成熟に合わせて、より具体的な要件を追加します。
* **バイパスは慎重に使う**：バイパス権限は信頼できる管理者にのみ付与してください。
* **定期的に見直す**：チームの実際のワークフローパターンに基づいてルールを調整します。
* **まずテストする**：可能な場合は、本番セクションに適用する前にテスト用セクションでルール変更を試してください。

## 利用可能なルールタイプ

### レビュー要件

<table><thead><tr><th width="279.703125">ルール</th><th>説明</th></tr></thead><tbody><tr><td><strong>少なくとも1件のレビューを必須にする</strong></td><td>少なくとも1人のチームメンバーが変更リクエストをレビューしてからでないとマージできないようにします。</td></tr><tr><td><strong>すべてのレビューの承認を必須にする</strong></td><td>すべて <strong>完了済み</strong> （未依頼の）レビューはすべて承認でなければなりません。レビュアーの誰かが変更を要求したり変更リクエストを却下した場合、マージはブロックされます。</td></tr><tr><td><strong>指定したアクターによるレビューを必須にする</strong></td><td>指定したすべてのユーザーからの承認が必要です。マージされる前に変更リクエストをレビューして承認しなければならない特定のチームメンバーを選択できます。</td></tr><tr><td><strong>指定したいずれかのアクターによるレビューを必須にする</strong></td><td>指定したユーザーのうち少なくとも1人からの承認が必要です。複数の適格なレビュアーがいるが、グループからは1件の承認だけでよい場合に便利です。</td></tr><tr><td><strong>Docs Agent によるレビューを必須にする（近日公開）</strong></td><td>GitBook の AI エージェントによるレビューが必要です。これにより、マージ前にコンテンツ変更に対して自動の品質チェックが実行されます。</td></tr></tbody></table>

### 変更リクエストの要件

<table><thead><tr><th width="279.703125">ルール</th><th>説明</th></tr></thead><tbody><tr><td><strong>最新の変更リクエストを必須にする</strong></td><td>変更リクエストは、プライマリコンテンツブランチの最新状態でなければなりません。変更リクエスト作成後にプライマリコンテンツが更新されている場合は、マージ前に rebase するか更新する必要があります。</td></tr><tr><td><strong>件名を必須にする</strong></td><td>変更リクエストには説明的な件名/タイトルが必要です。件名が空だとマージはブロックされます。</td></tr><tr><td><strong>説明を必須にする</strong></td><td>変更リクエストには、どのような変更を行い、なぜ行ったのかを説明する内容を含める必要があります。</td></tr></tbody></table>

### 詳細オプション

<table><thead><tr><th width="279.703125">ルール</th><th>説明</th></tr></thead><tbody><tr><td><strong>指定したアクターに要件のバイパスを許可</strong></td><td>他のすべてのマージルール要件をバイパスできる特定のユーザーを指定できます。これは、管理者や、ルールを上書きする必要がある緊急時に便利です。</td></tr><tr><td><strong>カスタム式</strong></td><td>カスタム JavaScript 式を使用して高度なマージルールを作成できます。これにより、変更リクエスト、レビュー、マージしようとしているユーザーのプロパティにアクセスしながら、評価コンテキストに基づく複雑なロジックを定義できます。</td></tr></tbody></table>

#### カスタム式

カスタム式を作成すると、誰かが変更リクエストをマージしようとするたびに評価されます。式が `true`、マージは許可されます。返り値が `false`の場合、マージはブロックされます。

{% hint style="info" %}
カスタム式は標準的な JavaScript 構文（ES2022）をサポートしており、最大長は 1024 文字です。
{% endhint %}

**利用可能なコンテキスト変数：**

* `changeRequest.subject` - 変更リクエストの件名/タイトル
* `changeRequest.description` - 変更リクエストの説明
* `changeRequest.outdated` - 変更リクエストが古いかどうか（真偽値）
* `changeRequest.createdBy.id` - 変更リクエストを作成したユーザーの ID
* `reviews` - 以下を含む各レビューオブジェクトの配列：
  * `reviews[].status` - レビューステータス（`"approved"` または `"changes_requested"`)
  * `reviews[].reviewer.id` - レビュアーの ID
* `actor.id` - マージを試みているユーザーの ID

**よくある式の例：**

{% code title="複数の承認済みレビューを必須にする" %}

```javascript
reviews.filter(r => r.status === "approved").length >= 2
```

{% endcode %}

{% code title="特定のユーザーからの承認を必須にする" %}

```javascript
reviews.some(r => r.reviewer.id === "harry" && r.status === "approved")
```

{% endcode %}

{% code title="緊急変更に説明を必須にする" %}

```javascript
!changeRequest.subject.includes("[URGENT]") || !!changeRequest.description
```

{% endcode %}

{% code title="小規模な変更のみ自己マージを許可する" %}

```javascript
changeRequest.createdBy.id === actor.id ? changeRequest.subject.startsWith("[minor]") : true
```

{% endcode %}


---

# 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 dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://gitbook.com/docs/documentation/ja-gitbook-documentation/collaborate/merge-rules.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.
