RFC プロセス

RFC は、実装前にプロジェクトレベルの永続的な意思決定を記録します。このプロセスは、設計上のトレードオフを明らかにし、メンテナーやコントリビューターが早い段階で異議を唱える機会を設け、意思決定に至った_理由_を検索可能な記録として残すために存在します。

ほとんどの作業にRFCは必要ありません。RFCを起動する条件は意図的に絞られており、プロジェクトレベルの判断が本当に必要な提案が、通常の機能に埋もれて順番待ちにならないようにしています。

RFC の対象範囲、議論の時期、および批准ルールは、#9496 によって最後に定められ、2026-08-10 に承認され、FND-003 Rev. 15 として採用されました。永続的なプロトコルについては、FND-003 を参照してください。

RFCを提出すべきか、それともPRだけで十分か

実装前に永続的なプロジェクトレベルの決定が必要な提案、つまり少なくとも次のいずれかに該当する場合は、RFCを提出します。

新たなセキュリティレイヤー、またはプロジェクトのセキュリティモデルへの重大な変更;
ガバナンス、コントリビューションプロセス、またはプロジェクトの権限に関する変更;
既存の境界をまたいで所有権または契約を変更する、横断的なアーキテクチャのリファクタリング。または
新しいサブシステム、またはプロジェクト全体に関わる別の機能境界。

作業に以下が含まれるというだけの理由で、RFC を提出しないでください：

通常の機能追加;
スキーマまたはデータの移行;
設定項目またはデフォルト値の変更、または
範囲を限定した実装のリファクタリング。

これらは issue と PR を通します。新しいチャネル、新しいプロバイダー、新しいツール、バグ修正は、diff がどれほど大きくても、すべて通常の作業です。実質的な影響が上記4つのトリガーのいずれかにも該当する場合に限り、RFC が必要になります。

この判定が基準とするのは、課題のタイトル、作成者、ドラフトが AI の支援を受けたかどうか、あるいはマイグレーション、機能、デフォルトの変更が単に含まれているかどうかではなく、プロジェクトに対する実質的な影響です。判断に迷う場合は、通常の issue を作成し、どのトリガーに該当する可能性があると考えているのか、その理由を記載してください。メンテナーが RFC に格上げできます。そのほうが、RFC を停滞させるよりもはるかにコストがかかりません。

セキュリティ脆弱性は SECURITY.md に従って非公開で報告し、公開 RFC として報告することは決してありません。

メンテナーは、提出された RFC がトリガー条件を満たさない場合、それを通常の issue、機能リクエスト、または実装フォローアップとしてラベルを付け替えたり、クローズしたりすることがあります。その扱いは、基盤となる作業が引き続き有効かどうか、またどこで継続されるかを示すものであり、内容そのものに対する却下ではなく、振り分けの判断です。

RFCの提出

RFCは type:rfc タグ付きのGitHub Issueです。タイトル形式:

RFC: <short description of the proposal>

本文の構成: 提案の規模に合わせて調整してください:

問題: どのようなユーザーの不便やシステムの欠陥がこれを引き起こしているのか?
提案: 何をしようと提案していますか?
設計: 詳細、コードスケッチ、スキーマの形状、マイグレーション計画
検討した代替案: 他に何を評価し、なぜ採用しなかったのか？
非目標: この提案が明示的に解決しようとしていないこと
リスクと軽減策: 何が問題になり得るか、そしてロールバックの手順
ロールアウト: フィーチャーフラグ管理されているか？スキーマがバージョン管理されているか？破壊的変更のウィンドウは？

提出された RFC は、公開された提案について最低限の議論期間を経ます。通常の RFC は 48 時間、例外的な全会一致の手続きを求める RFC は 72 時間です。誰でもコメントできます。メンテナーが意見を述べます。作成者はそれを受けて本文を改訂します。

議論中の通常の修正や明確化では、期間のカウントはリセットされません。提案された決定を実質的に変更する修正は、新たな安定したスナップショットを確立し、それを公開して識別できるようにしたうえで、適用される最低期間のカウントを再開させます。投票は、その期間が経過し、提案が安定した後にのみ開始されます。

承認

投票は、変更不可能なアーティファクトまたはコミット、あるいは記録された issue 本文のダイジェストと簡潔な意思決定の要約によって識別される、変更不可能な提案スナップショットを対象に 72時間 実施されます。投票開始コメントには、スナップショット、割り当てられた投票資格者、閾値とその適用理由、正確な UTC の締切日時が記録されます。

投票資格者。 アクティブな Core コントリビューターとは、過去30日以内に正式に開始された RFC 投票で明示的な投票を行った、現在の Core Team メンバーを指します。その集合に含まれない現在の Core Team メンバーも引き続き投票できます。そうすることで、その投票の投票資格者に加わり、後続の投票に向けて再びアクティブになります。

投票は APPROVE、REVISE、または REJECT です。REVISE は承認を保留しますが、拒否権を行使するものではありません。REJECT はブロッキングとなる異議であり、具体的な理由が必要です。締め切り前に行った最新の投票が、それ以前の投票に優先します。

しきい値。 デフォルトでは最終的なアクティブ投票者の3分の2とし、投票者数の整数に切り上げます。定足数には少なくとも2票の明示的な投票が必要であり、沈黙は定足数に算入されません。定足数に達すると、通常の投票では投票者の沈黙を APPROVE とみなします。全会一致は、コストや不可逆性のために特別多数では不十分となる決定（ライセンスや法的所有権の変更など）に限られます。全会一致には割り当てられたすべての投票者による明示的な APPROVE が必要であり、沈黙によって成立することはありません。

結果（次の順序で適用）:

保留: 明示的な投票が2件未満です。終了記録には、再開できる時期が記載されます。変更のない保留中の提案は、議論を繰り返さずに新たな72時間の投票にかけることができます。
却下: 定足数を満たし、最終投票のいずれかが REJECT。ブロッキングとなった異議を記録し、根本的な問題が継続している issue があればリンクして、Issue をクローズします。これは提案を却下するものであり、必ずしも問題そのものを却下するものではありません。
承認済み: 定足数を満たし、REJECT がなく、少なくとも3分の2が明示的に、または沈黙によって承認している。Issue には status:accepted が付与され、終結記録では REVISE の懸念を破棄せず、すべて対応している。その引き継ぎが確認できれば、実装 PR を進められる。
議論に戻りました: 上記のいずれでもありません。未解決の修正リクエストが記録されています。
取り下げ: 提案者が撤回します。再提案を妨げずにクローズされます。

投票は、最終的なアクティブ投票者全員が明示的に承認し、非アクティブな Core コントリビューターから全期間を求める要請がない場合に限り、早期に終了できます。終了記録には、早期に終了した理由を記載する必要があります。

現行のプロトコルは、批准後に開始された RFC の投票に適用されます。以前に承認された RFC が自動的に無効になるわけではありません。過去のプロセスの監査および修正作業は、別途追跡されます。

採用されたRFCの実装

実装のPRには以下が含まれているべきです：

実装を開始する前に、RFC issue に最終的に承認された形と恒久的な処理結果が記録されていることを確認してください
RFCのissue番号を参照してください（Implements #5574 phase 1）
承認された設計の範囲内で対応し、実装中に詳細が変更された場合は、RFC 本文を更新するか、フォローアップの明確化のための issue を作成してください
RFCで段階的なロールアウトが求められている場合は、フィーチャーフラグの背後に配備してください。
破壊的変更の影響を受けるユーザー向けの移行パスを含める

大きなRFCは、複数のリリースにわたって複数のPRで提供されることがよくあります。RFCの追跡コメントは、フェーズが実装されるたびに更新されます。

現在公開されているRFC

Open RFCは、ZeroClawにおける「次に来るもの」の最も良い一次情報源です。閲覧:

sh

gh issue list --repo zeroclaw-labs/zeroclaw --label type:rfc --state open

そのクエリが正式な情報源です。このページでは、意図的にそのスナップショットを反映していません。手作業で管理するリストは、誰も気づかないうちにすぐ古くなってしまうためです。

承認された基礎的なRFC

これらは他のすべての要素に影響を与えます。横断的な変更を提案する前に、これらをお読みください：

#5574: マイクロカーネルへの移行: クレート分割、フィーチャーフラグの分類、v1.0 への道筋
#5576: ドキュメント標準とナレッジアーキテクチャ
#5577: プロジェクトガバナンス: コアチーム、および本ドキュメントの権限。このRFCの適用範囲と投票のしきい値は、#9496 (FND-003 Rev. 15) により置き換えられています
#5579: エンジニアリング基盤: CIパイプライン、リリース自動化
#5615: コントリビューション文化: 人間とAIの共同作成に関する規範
#5653: 妥協なし: エラーハンドリング、デッドコードポリシー、リリース準備基準

AIが作成したRFC

RFCの著者としてAIアシスタント（人間のスポンサー付き）が関与することは、RFC #5615により明示的に許可されています。もしRFCがAIの助けを借りて作成された場合:

本文に明記する（“drafted with Claude, reviewed by @maintainer”）
スポンサーの人間は、正確性とレビューへの対応を担当します。
現在の Core Team メンバーのみが拘束力のある票を投じます。AI が下書きした RFC のスポンサーになっても投票権限は生じず、提案が AI の支援を受けて作成されたというだけで、その提案が RFC トリガーの条件を満たすかどうかが変わることもありません。

これまでのところ、この方法はうまく機能しています。AIによるドラフトを正規のものとして扱いつつも、最終的な責任はスポンサーにあることを忘れないでください。

ZeroClaw Docs