agentic-change-governance

エージェントによる変更のガバナンス

エージェントによるコーディングは、ユーザー、計画、既存システムから付与された権限の範囲内にとどめます。

編集前に権限を分類する

変更しようとする内容をそれぞれ分類します。

• スコープ内：ユーザーの依頼または承認済みの計画で直接求められている変更です。
• 局所的な補助：依頼された動作を正しく実現するために必要な、近接する小規模な変更です。
• 設計変更：アーキテクチャ、責任の境界、公開 API、規約、ストレージの形式、デプロイ動作、モジュール間の責任を変更するものです。
• 便宜的な変更：依頼された動作に必要ではない、クリーンアップ、再編成、抽象化、名前変更、スタイルの大幅な変更です。

スコープ内の変更と、必要な局所的な補助変更を実施します。依頼または計画で明示的に承認済みの設計変更は進めてかまいませんが、新たな設計上の判断や、実質的に変更された設計上の判断についてのみ確認を求めます。明示的に依頼されていない便宜的な変更は行いません。近接するクリーンアップが局所的な補助にあたるのは、正しさの確保や変更した経路を理解しやすくするために必要な場合に限られ、単にそのほうが望ましいという理由だけでは該当しません。

人が理解できる構造を保つ

長期にわたるエージェントによる作業によって、エージェントにしか理解できないシステムへとコードベースを変えてはなりません。

新しいパターン、抽象化、ディレクトリ構造、命名規則、データフロー、エラーモデルを導入する前に、次のことを行います。

1. 最も近い既存の例を探します。
2. 既存のパターンでは不十分な理由を説明します。
3. 新しいパターンを可能な限り小規模かつ局所的に保ちます。
4. 計画または最終報告で、設計上の判断であることを明記します。

既存のパターンが見つからない場合は、フレームワークを新たに考案するのではなく、直接的な実装を優先します。

システムのルールを尊重する

プロジェクトのドキュメント、公開インターフェイス、モジュールの境界、リンタールール、テスト、確立された規約は、提案ではなく制約として扱います。

変更を通すためにルールを弱めてはなりません。

• 明示的な承認なしに、テスト、リンタールール、型チェック、境界チェックを無効にしてはなりません。
• 不一致を隠すために、型の範囲を広げたり、検証を緩めたり、エラーを握りつぶしたりしてはなりません。
• 内部実装をインポートして公開 API を迂回してはなりません。
• 正しい動作を決めるのを避けるためだけに、動作を設定可能にしてはなりません。

システムのルールが誤っていると思われる場合は、矛盾を報告し、別個の設計変更を提案します。

エスカレーションの条件

すでに明示的に承認されていない操作によって、次のいずれかが生じる場合は作業を止め、承認または計画の改訂を求めます。

• モジュール間または責任範囲の境界を越えてコードを移動する。
• 新たな横断的抽象化を導入する。
• 公開契約、永続化データの形式、移行動作、デプロイ順序を変更する。
• 確立されたパターンを削除または置き換える。
• 相互に無関係な多数のファイルに手を加える。
• 動作変更と広範なリファクタリングまたはフォーマット変更を混在させる。
• 検証を弱めなければ変更を通せない。

完了の基準

変更は承認済みの権限の範囲内にとどまります。すべての編集が依頼または承認済みの計画に対応しており、未承認の設計変更や便宜的な変更が含まれていないこと、変更が明示的に承認されていない限りシステムのルールが維持されていること、そしてアーキテクチャ、契約、責任範囲、規約に関する変更はすべて、最終報告に記載するだけでなく、明示的に承認されていることが条件です。