> ## Documentation Index
> Fetch the complete documentation index at: https://adcp-docs-ja.pier1.co.jp/llms.txt
> Use this file to discover all available pages before exploring further.

# RFC プロセス

> AdCP への実質的変更を提案し批准する方法 — 提案テンプレートと決定記録形式を含む、ドラフトから仕様変更までのライフサイクル。

プロトコル提案は、実質的変更が仕様に到達する前に動機付けられ、レビューされ、記録されることを保証するため、軽量な RFC（Request for Comments）プロセスを使います。このページは、プロセスがいつ適用されるか、提案をどう提出するか、決定記録がどう見えるかを説明します。

## 何が RFC を必要とするか

| Change                                       | Requires RFC |
| -------------------------------------------- | ------------ |
| スキーマフィールドの削除またはリネーム                          | Yes          |
| タスクの追加または削除                                  | Yes          |
| 規範的言語の変更（`MUST` / `SHOULD` / `MAY`）          | Yes          |
| 互換性表面の変更 — デフォルト値、フィールドタイプ、required↔optional | Yes          |
| オプションスキーマフィールドの追加                            | No           |
| 新 enum 値の追加                                  | No           |
| セマンティック変更なしのドキュメント文言明確化                      | No           |
| タイポ修正                                        | No           |
| 内部ツール、CI、インフラ                                | No           |
| ドキュメントナビゲーション変更（`docs.json`）                 | No           |

疑わしいとき: 変更が下流実装に動作し続けるためコード更新を強いる場合、RFC が必要です。

## ライフサイクル

<Steps>
  <Step title="Draft">
    [proposal template](#proposal-template) をボディとして使い GitHub issue を開きます。タイトル形式: `RFC: <short description>`。`rfc` ラベルを追加します。作成者は正式レビューを要求する前にワーキンググループメンバーまたは影響を受ける実装者から早期フィードバックを求めるべきです。
  </Step>

  <Step title="WG review">
    issue は次のワーキンググループセッションのためキューされます。WG が投票する前に少なくとも 2 人の [ワーキンググループメンバー](/docs/community/working-group) がレビュアーチェックリストを完了しなければなりません。レビュー期間は issue 提出後最低 7 暦日です。
  </Step>

  <Step title="Decision">
    WG は決定 — accepted、rejected、または deferred — を、RFC issue へのコメントとして [decision record](#decision-record-format) を投稿することで記録します。合意に達しても反対は記録されなければなりません。
  </Step>

  <Step title="Specification change">
    決定記録が存在しそのステータスが **accepted** の後、任意のコントリビューターが spec PR を開けます。PR は `Refs #N`（`Closes #N` ではない）で RFC issue を参照しなければならず、決定記録が存在するまでマージできません。spec PR レビュアーは diff が accepted された RFC スコープに一致することを確認します。最終 spec PR は、マージ時に RFC issue をクローズするため `Closes #N` を運びます。

    accepted された RFC は各 spec ライフサイクルステージ遷移の必須トリガーです: それが機能を Draft → Proposed に移し、または Deprecated → Sunset をゲートします。追跡可能な accepted された決定記録なしにライフサイクル遷移は有効ではありません。
  </Step>
</Steps>

## Proposal template

RFC を提出するとき、これを GitHub issue ボディにコピーします:

```markdown theme={null}
## Motivation

<!-- Why does the protocol need this change? What problem does it solve? -->

## Scope

<!-- Exactly what changes — schemas, tasks, normative text. Be specific about field names,
     enum values, and affected task types. -->

## Alternatives considered

<!-- What other approaches were evaluated? Why were they ruled out?
     Include at least one non-obvious alternative. -->

## Compatibility impact

<!-- Is this breaking? What must downstream implementers change to keep working?
     State explicitly: breaking or non-breaking, and why. -->

## Reviewer checklist

- [ ] Motivation is clear and not redundant with existing functionality
- [ ] Scope is specific enough to implement without further clarification
- [ ] Alternatives section covers at least one non-obvious alternative
- [ ] Compatibility impact accurately states breaking vs. non-breaking
- [ ] Wire-format or schema snippet included (for schema or task changes)
```

## Decision-record format

WG 投票の後、これを RFC issue へのコメントとして投稿します。`Dissent` セクションは必須です — それを省略することはすべてのレビュアーが少数派の立場が存在しないことを明示的に確認したことを示します。

```markdown theme={null}
## Decision record

**Status:** accepted | rejected | deferred
**Date:** YYYY-MM-DD
**Discussion:** <!-- link to WG meeting notes or async discussion thread -->
**Vote outcome:** N in favor, N opposed, N abstained

## Rationale

<!-- 2–4 sentences on why the WG reached this conclusion. -->

## Dissent

<!-- Record any minority position, even when it did not change the outcome.
     Example: "Two reviewers preferred adding the field as optional rather than
     required, citing implementation burden for smaller sellers. The WG agreed
     that required enforcement is necessary for audit correctness."
     If the vote was unanimous and all reviewers confirmed no dissent: state that explicitly. -->

## Next steps

<!-- Who is opening the spec PR? Any conditions on the implementation? -->
```

## 関連項目

* 仕様ライフサイクル — accepted された RFC が spec ライフサイクルステージ遷移（Draft → Proposed → Final、および Final → Deprecated）を駆動します。専用ページは [#2441](https://github.com/adcontextprotocol/adcp/issues/2441) で追跡
* [ガバナンス概要](/docs/governance/overview) — 三者モデルとキャンペーンガバナンスドメイン
* [埋め込まれた人間の判断](/docs/governance/embedded-human-judgment) — ほとんどの RFC が寄与するガバナンスシステムの背後にある原則