2026 年、エンタープライズ チームは、インシデント管理チケットを読み取り、そこから事後分析を生成し、修復項目を自動的に作成するエージェントを構築しました。同じチームの 2 人目のエージェントは、新しい作業項目を監視し、開発者が作業を開始できるように、それぞれの作業項目のドラフト PR を開きました。開発者はそれらの PR の 1 つをレビューし、妥当であると判断して承認し、メイン ブランチにマージしました。

**問題は、この変更が完全に捏造されたものであったことです。**

エージェントは、説明どおりには存在しなかった問題に対して、もっともらしく見える修正方法を発明しました。この変更により、実際の運用シナリオが後退してしまいました。実際の顧客は気づきました。停電がありました。

これが EDD 憲法が存在する理由です。

構成は、コードベースに対するあらゆる重要な変更を管理する単一のファイルです。これは、完成した変更がどのようなものであるか、変更にどのような証拠を含める必要があるか、範囲を絞った監査で何をカバーする必要があるか、ルール自体がどのように進化するかを定義します。リポジトリに触れるすべてのエージェントとすべての人間が、セッションごとにリポジトリをロードします。バーはただ上がっていくだけです。

この投稿では、憲法を段階的に説明します。憲法の動機となった出来事、それが答える設計上の疑問、憲法がどのように構成されているか、どのように書かれたか (そして初期段階で間違っていたこと)、修正がどのように機能するか、完全なキットがどのように新しいリポジトリに展開されるかについて説明します。

ステップ 1 - それは何ですか

このインシデントは、EDD が防止するように設計された障害モードを最も明確に示しています。エージェントはランダムに幻覚を見せたわけではありません。これにより、一貫性があり、読みやすく、専門的にフォーマットされた PR が作成されました。それをレビューした開発者は、開発者が行うことと同じことを行いました。つまり、意図を読み取り、その意図がもっともらしいと判断し、承認されました。ギャップは気配りではありませんでした。ギャップは証拠の欠如でした。レビュープロセスでは、エージェントが修正すると主張した問題が実際に存在すること、修正が実際の動作に対処していること、または変更が何も後退していないことを証明することをエージェントに要求するものは何もありませんでした。

EDD は、そのギャップに 1 つの厳しい要件で答えます。エージェントがそれを証明できない場合、タスクは完了しません。証明は要約ではありません。証明は自信を表明するものではありません。証拠とは、失敗したテスト、スキャナー出力、前後のスクリーンショット、計画の差分など、個別に検証できる成果物です。 PR にアーティファクトが含まれているか、PR が不完全です。

憲法は「docs/methodology/CONSTITUTION.md」にあります。プロジェクトで構成されたすべての AI エージェントは、独自のローダー ファイルを通じてセッションごとに AI エージェントを読み込みます。本文はエージェント中立です。ツール名やプラットフォーム固有の構文はありません。これは、9 つ​​の基本原則、安定したスラッグ ID を伴うハード制約、10 ステップの実装ループ、監査次元、変更タイプごとの証拠受容基準、低リスク作業の自明性カーブアウト、および修正条項を定義しています。

各ハード制約には「[HC-EVIDENCE-BEFORE]」のようなスラッグがあり、バー (何が真である必要があるか)、検証 (遵守がどのようにチェックされるか)、およびパターン ソース (実装ガイダンスを詳しく説明する命令ファイル) の 3 つを宣言します。

10 ステップのループは運用の中心です。完了を定義し、ギャップを証明するテストを作成し、失敗するのを観察し、事前証拠を取得し、実装し、テストが合格するのを監視し、事後証拠を取得し、ドキュメントを検証し、宣言された次元全体で監査し、その後人間によるレビューを行います。ステップ 1 ～ 4 は、実装を編集する前に行われます。この事件は、合憲でない場合に何が起こるかを正確に示しているため、この命令は合憲である。

追加の安全策として、EDD は TDD から核となる原則を借用しています。つまり、作業を開始する前にシナリオが失敗することが証明されなければなりません。変更の最後に合格したという証明だけでは十分な証拠とはなりません。変更前にもテストに合格した場合、エージェントは決して壊れなかったものを修正した可能性があります。これは、AI 支援ワークフローに特有の障害モードです。エージェントがもっともらしい修正を生成し、検証がたまたま満たされ、あたかも実際の問題を解決したかのように変更が出荷されます。実装を開始する前に障害状態の文書化を要求することで、そのギャップが解消されます。証拠前のステップは、単なる比較のベースラインではなく、解決されている問題が現実のものであることを証明するものです。

この憲法を通過したすべての厳しい制約のうち、2 つは他のすべてを合わせたよりも多くの欠陥を発見しており、間違いなく、EDD が AI 支援ワークフローに対して行う最も重要なアップグレードの 1 つである「[HC-EVIDENCE]」と「[HC-EVIDENCE-INTEGRITY]」です。どちらも `.github/copilot-instructions.md` で宣言されます。これは、すべてのセッションでエージェントのコンテキスト内にある積極的にロードされるファイルです。

「[HC-EVIDENCE]」では、すべての PR が実際の前後のアーティファクトを保持することを要求します。アーティファクトが示す内容の説明や、エージェントが起こったと信じている内容の概要ではなく、生の出力を保持する必要があります。 「[HC-EVIDENCE-INTEGRITY]」はさらに進んでおり、PR 内の証拠が実際に行われた作業まで遡ることができることを要求しています。 PR に記載されている内容が PR に含まれていることを検証します。

これら 2 つの制約を組み合わせることで、AI によって生成された何百ものバグがレビューに至る前に捕らえられました。彼らが警戒する失敗モードは、明白な意味での幻覚ではありません。これは微妙な動作です。エージェントはタスクに完了のマークを付け、自信を持った PR 説明を書き、証拠として読み取れるものを含めますが、証拠は作成されたものであり、キャプチャされたものではありません。エージェントは、コマンドを実行して実際の出力を含めるのではなく、出力がどのようになるかを説明しました。

`[HC-EVIDENCE-INTEGRITY]` は、いわゆる「それはできませんでした」パターンを捕捉するのに特に効果的です。難しいタスクや不慣れなタスクに直面しているエージェントは、そのタスクに挑戦するのではなく、そのタスクは不可能である、または範囲外であると主張することがあります。この主張は、多くの場合、存在しないツール、アプローチを妨げる制約、操作をサポートしない環境などの制限として組み立てられます。 `[HC-EVIDENCE-INTEGRITY]` はこれを明らかにしています。エージェントがタスクを実行できなかったと主張している場合、PR はそのタスクが本当に試みられ、障害が現実であるという証拠を示さなければなりません。 「テスト スイートを実行できませんでした」には、障害が発生したというステートメントではなく、障害を示すターミナル出力が必要です。この要件がないと、エージェントが困難な作業を回避していることはレビュー時に認識されず、タスクは完了したかのように未完了のまま出荷されます。

ステップ 2 - ここに至るまでの経緯

憲法は教訓の積み重ねではありません。これは、最初に尋ねられた設計上の 1 つの質問に対する答えです。回避不可能で、人間が質問することを覚えていることに依存しない方法で、AI エージェントに毎回その動作を証明させるにはどうすればよいでしょうか?

その質問に答えるには、分解が必要でした。証明するには、実装が開始される前に、何がどのように行われるかを知る必要があります。これにより、文書化のステップが発生します。証明には、変更前に失敗し、変更後に合格するテストが必要です。これにより、不合格/合格のテスト規律が生成されました。証明には、実装が何かに触れる前にキャプチャされた前の状態、つまり前の証拠の要件が生成されることが必要です。証明には、変更ごとの証拠では把握できないもの、つまり監査の次元を生み出す独立した監査が必要です。そして、証拠は緩和されることなくレビュープロセスを生き延びなければなりません。そのため、人間のレビュー担当者が最終ゲートであり、自動化できない唯一のゲートであるという厳しい制約が生じました。

結果は 10 ステップのループになります。すべてのステップが存在するのは、それを削除すると、証明されていない作業が通過できる穴ができるためです。ループはチェックリストではありません。それは因果連鎖です。

そこから、質問は次のようになりました。ループがデフォルトで捕捉しない、エージェントが生成できる障害のカテゴリは何ですか?それが厳しい制約を生み出しました。ルールがダウングレードされている間、セキュリティ lint はサイレントであり、`[HC-SECURITY-LINT]` が生成されました。デプロイされたアーティファクトでの文字エンコーディングの失敗により、「[HC-ASCII-PUNCT]」が生成されました。各 HC は、特定の自動検証を使用して特定の障害クラスをクローズします。検証の名前を指定できないルールは拒否されました。チェックを自動化できない場合、そのルールは願望的なものであり、合憲ではありません。

設計上の最後の質問は、誰が憲法自体を統治するのかということでした。答えはラチェットです。憲法は厳しくなるばかりだ。修正には、エージェントの行動が改善または維持されるという証拠が含まれている必要があります。床が下に下がることはありません。これは、憲法が、生活スタイルガイドでは不可能な方法で、長期にわたって信頼できることを意味します。どのバージョンも、以前のものよりも厳密に強力です。

ステップ 3 - どのように構成されているか

構成は 3 層のアーキテクチャに従っています。

**レイヤー 1: 正規の本文。** 1 つのファイル、`docs/methodology/CONSTITUTION.md`。これが真実の源です。これはエージェント中立であり、どの AI ツールが使用されているかについて何の仮定も行いません。それは原則、厳しい制約、ループ、監査の次元、証拠の受け入れ基準、自明性のカーブアウト、および自己改善条項を定義します。本文が約 250 行を超えると、特定のパス パターンに適用されるルールがパス スコープ ファイルに取り出され、本文に 1 行のポインターが残ります。

**レイヤー 2: エージェント ローダー。** 構成されたすべてのエージェントは、エージェントが熱心にロードする場所にあるローダー ファイルを 1 つだけ取得します。 GitHub Copilot の場合、それは `.github/copilot-instructions.md` です。クロードの場合、それは「CLAUDE.md」です。ローダーは、プラットフォームが現在サポートしている内容に応じて、構成本体をインポートまたはインライン化します。ローダーは標準ボディから機械的にレンダリングされます。手作業で編集されていません。プロジェクトで 3 つの AI ツールを使用する場合、3 つのローダー ファイルがあり、すべて同じ構成コンテンツをレンダリングします。

**レイヤー 3: パススコープのルール。** 一部のルールは、特定のファイル タイプにのみ適用されます。アクセシビリティとローカリゼーションのルールは、インフラストラクチャ テンプレートではなく、JSX ファイルと CSS ファイルに適用されます。これらのルールは、フロントマター グロブを含む命令ファイル内に存在します。

エージェントは、一致するパスにアクセスした場合にのみ、これらのファイルをロードします。これにより、即時読み込みコンテキストの予算がタイトに保たれ (コア ルールが常に存在し、特殊なルールがオンデマンドでロードされる)、アクセシビリティ ガイダンスが Bicep テンプレート編集に表示されなくなります。

サポート ファイルによって構造が完成します: `.github/prompts/` の `/constitute` コマンド本体、`docs/methodology/features/` の機能ごとのフォルダー、`docs/methodology/eval/scenarios/` の eval シナリオ、および CI ゲートの順序を定義するリポジトリ ルートの `verify-sequence.yaml`。

ステップ 4 - 作成方法

**コンテキストがすべてです。コンテキストにないものはエージェントにとって無効です。**

これは、AI による開発のための憲法の作成に関する最も重要な洞察です。エージェントがロードしないファイルに存在するルールは存在しません。特定のファイル パスがタッチされた場合にのみロードされるドキュメントに埋め込まれたハード制約は、他のパスに対するハード制約ではありません。憲法は常に文脈の中に存在しなければならず、常に適用されなければならないすべてのものはそこに存在しなければなりません。

これにより、次の 3 つのオーサリング決定が推進されます。

**トークンの最適化は交渉の余地がありません。** 正規本体は 300 行と 8,000 トークン未満をターゲットとしています。すべての修正はトークンの効率を維持または改善する必要があります。簡潔なものを達成できる冗長なルールは、その理由だけで拒否されます。これはスタイルの好みではありません。それは負荷制約です。憲法が予算を超える場合、より小さなコンテキスト ウィンドウ内のエージェントはその予算を切り捨て始め、切り捨てられたルールはルールではなくなります。

**フロントマターによる条件付きロード。** 特定のファイル タイプにのみ適用されるルールは、正規本体から取り出され、フロントマター グロブ宣言を持つパス スコープの命令ファイルに組み込まれます。アクセシビリティとローカライゼーションのガイダンスは、エージェントが JSX または CSS に触れた場合にのみ読み込まれます。インフラストラクチャ ガイダンスは、エージェントが上腕二頭筋に触れたときにのみロードされます。正規の本体は 1 行のポインタを保持します。エージェントは、関連する場合にのみ、パス スコープのファイルをロードします。これは単なる効率化ではなく、アクセシビリティ ガイダンスがインフラストラクチャ編集の邪魔になることを防ぎ、エージェントがそれを無視するように訓練します。

このプロジェクトは、フロントマターで分離されたルール ファイルを使用しません。これは、構成がコンテキスト内で完全に読み込むのに十分なほど小さいためです (単一の開発者、焦点を絞ったスコープ、無駄のないルール セット)。大規模なチームの場合、計算は変わります。現在 EDD を実行しているエンタープライズ規模のプロジェクトには、セキュリティ、コンプライアンス、アクセシビリティ、プラットフォーム固有の要件にわたって 75 の厳しい制約があります。 75 個すべてを 1 つの Eager-load ファイルにインライン化すると、その構成はほとんどのエージェントのコンテキスト バジェットをはるかに超えてしまいます。フロントマター分割では、正規の本文 (ドメインごとのサマリー ポインター) が 250 行未満に保たれ、エージェントが一致するパスに触れた場合にのみ完全なルールの詳細が遅延ロードされます。体質は速くてスリムなままです。ルールは完全なままです。トークンのコストは制限されたままです。

**変更の単位としての修正。** 憲法修正は、マークダウン ファイル内の単語の変更ではありません。これは、正確なルール デルタ、将来の違反を捕捉する検証メカニズム、エージェントの動作が改善されたことを証明する動作評価シナリオの 3 つのアーティファクト バンドルです。 3 つはすべて同じ PR で一緒に出荷されます。この修正は原子的なものです。後で検証を追加することを約束する部分的な修正は拒否されます - 後では来ず、検証不可能なルールはお飾りです。

**eval とルーブリックは、必要だと思う前に書いてください。** eval はラチェットです。それがなければ、修正案は善意に基づいて受け入れられ、憲法は漂流してしまいます。ルーブリックは、現実的なシナリオにおけるエージェントの行動をスコア化します。新しいルールごとに、少なくとも 1 つのシナリオが生成されます。ルーブリックは数値スコアを生成します。この修正は、ワーキングツリーのスコアがベースラインを満たすかそれを超えている場合にのみ可決されます。

**カバーできるものとカバーできないものを文書化します。報道に関して自分に嘘をつかないでください。**

初期の段階では、アクセシビリティのハード制約により、新しいインタラクティブ UI サーフェスには axe-core を使用した e2e a11y カバレッジが必要であると宣言されていました。これは包括的なものだと感じました。実際にはそれは甘かった。 axe-core は、WCAG の意味のあるサブセットを処理します。DOM が完全にレンダリングされ、色が解決される場合に、欠落しているラベル、ランドマーク構造、フォーカス順序、コントラストを捕捉します。スクリーン リーダーのアナウンス ロジック、認識負荷パターン、複雑なウィジェット キーボード コントラクト、または計算された色を解決できないグラデーションや SVG 画像ノードに関連するコントラストの問題は捕捉しません。

検証に axe-core を使用した `[HC-A11Y-GATE]` を使用しても、a11y のバグがゼロになるわけではありません。これは、レンダリングされた DOM に対して特定の axe-core ルールセットが実行されることを意味します。この違いは、PR 報道の主張において非常に重要です。

修正は分解でした。 「axe-core clean」の代わりに、axe-core ルールセットが確定的にカバーする WCAG 成功基準 (非テキスト コンテンツについては 1.1.1、情報と関係については 1.3.1、解決可能な場合はコントラストについては 1.4.3、名前/役割/値については 4.1.2) と自動化された対象範囲がゼロのもの (1.3.3 感覚特性、2.4.6 見出しとラベルのセマンティクス、 3.x のすべての理解可能な基準）。監査ディメンションの既知のギャップ セクションに、axe-core がこれらの基準を処理することが明示的に示されるようになりました。これらについては手動スキャンが必要です。 PR 査読者は、誤った信頼性の概要ではなく、実際の報道内容を確認します。

より広範な原則: すべての検証で、何が捕捉され、何が捕捉されないかを文書化します。 「セキュリティ lint がパスする」ということは、コードベースが安全であることを意味するものではありません。 「axe-core clean」は WCAG 2.2 AA 準拠を意味するものではありません。 Name the gap.それを監査ディメンションに記録します。ギャップ表面を手動でスキャンする必要があります。自動チェックで代替できない人間の判断を代替させないでください。

ステップ 5 - 修正案の書き方

修正案が修正案として開始されることはほとんどありません。それらはバグとして始まります。

バグが表面化します。修正が適用されます。出荷前に、「/reflect」は 1 つの質問をします。これは 1 回限りのものでしょうか、それともこのクラスの障害を検出する構成に何かが欠けているのでしょうか?答えが 1 回限りの場合は、修正が出荷され、それで終わりです。何かが足りないという答えがあれば、それは `/constitute` が呼び出されるときです。

**/reflect -> ギャップ -> 修正パス。** `/reflect` は修正を調べて、構成ギャップ (このクラスの障害をカバーするルールがなかった) または検証ギャップ (ルールは存在したが、それを強制する自動チェックがなかった) に分類します。どちらのルートも「/constitute」につながります。体質のギャップが新HCを生む。検証ギャップにより、既存の HC に対するより厳密な検証が行われます。通常は、新しい監査ディメンションのサブセクション、新しいスキャナ ルール、または新しい評価シナリオです。

**必要な 3 つのアーティファクト。** `/constitute` は、同じ PR 内に 3 つすべてがなければ続行を拒否します。

• **ルール デルタ。** 分類された正確なテキスト変更: 新しいルール、修正された文言、置換 (古いルールを置き換えて削除)、置き換え (古いルールを下限としてバーを上げる)、または再配置。重複は一目で拒否されます。
• **検証メカニズム。** 今後の違反を捕捉する特定のゲート - テスト名、lint ルール ID、監査ディメンション サブセクション、スキャナー終了コード チェック、または動作評価シナリオ。コミット時に存在する必要があります。検出可能な違反がないルールは装飾的なものです。
• **評価シナリオ。** `docs/methodology/eval/scenarios/<id>.md` に保存されます。古いルールが誤ったエージェントの動作を生成し、新しいルールが得点可能な正解を生成するという現実的な状況を説明します。

**ラチェット。** 3 つの成果物がすべて承認された後、修正がブランチに適用されます。評価はメインブランチ ルールとワーキング ツリー ルールに対して実行されます。ルーブリックでは両方のスコアが得られます。パスには、すべてのシナリオで working-tree >= main が必要です。回帰は、文言が修正されるまで修正案をブロックします。ラチェットは明らかな修正の場合はオプションではありません。修正によっても微妙な後退が生じる可能性があり、eval は修正が着地する前にそれを捕捉する唯一のメカニズムです。

**遡及的スイープ。** 修正により、新しいコードのルールが即座に修正されます。「/audit」の差分スコープは、修正が適用された瞬間から新しい作業が新しい基準を満たすことを意味します。新しいルールに違反する既存のコードは、「/rollout」を介してキューに入れられた別のスイープ PR によって処理されます。修正サイトは、既存のすべてのインスタンスをインラインで修正する必要はありません。そうなると修正には法外な費用がかかることになる。代わりに、新しいコードはすぐに新しい基準に達し、古いコードはロールアウト キューにあり、スイープ PR には既存のインスタンスが解決されたという独自の証拠が含まれます。

`/constitute` の 4 つの有効なトリガーは、バグ、インシデント、事後分析、および新しい契約基準です。 4 つのトリガーのいずれも指定されていない「おそらく...」という形式の提案は拒否され、代わりに「/reflect」にルーティングされます。

ステップ 6 - どのように展開するか

ポータブル メソドロジー キット (`EDD - ポータブル メソドロジー キット.md`) は、`/begin` を実行する指示とともに AI エージェントに渡す自己完結型のドキュメントです。エージェントはリポジトリを検査し、検出パスを実行し、検出された値を 1 つのテーブルで確認し、検出で答えられないものだけを質問し、プロジェクトの実行可能な最小限のスキャフォールディングを生成します。 1 回のセッションで完全な EDD インフラストラクチャを立ち上げます。

それをどのように展開するかは、新たに開始するか、既存のコードベースに取り込むかによって完全に異なります。 2 つのパスは別々に扱うことができるほど異なっています。

**グリーンフィールド** 新しいプロジェクトでは、初日から考えられるすべてのルールを憲法に盛り込みます。監査すべき既存のコードも、保護すべきチーム プラクティスも、祖父にすべき既存の PR もありません。初日の厳格さのコストはほぼゼロです。すべてのハード制約、すべての監査ディメンション、すべてのパス スコープのルールを追加します。次に、ループを実行します。すぐにわかるのは、憲法が摩擦を生み出す場所です。すべての変更が完全な監査をトリガーするために膨張するビルド時間、現在の複雑さに対してカバレッジの基準が高すぎるために設定されているテスト スイート、正規の本体が冗長すぎるために厳しいトークン バジェットです。初日の厳格さにより、運用環境ではなく開発段階でこれらの問題が表面化します。次に、ビルド ゲートを厳しくし、カバレッジ ルールを調整し、構成体を最小限にトリミングして最適化します。顧客やチームに影響を与えることなく、すべてを一度に安定化できます。短期的なコストは、最初のスプリントが若干遅くなるということです。長期的な利益は、最初のコミットからストレステストが行​​われた体質です。

**ブラウンフィールド。** 既存のコードベースには、EDD に従っていない既存のチーム、既存のプラクティス、および既存の PR が含まれています。ここでの展開は段階的であり、破壊的ではなく追加的である必要があります。最初の 1 か月の目標は、過去のすべての決定を修正することではありません。EDD を信頼できるものにするための担保の生成を開始することです。つまり、現実のものを捉える 1 つの監査次元、チームが既に手動で行っていたレビュー チェックを自動化する 1 つの厳しい制約、エンドツーエンドの 1 つの修正サイクルです。チームの既存の品質シグナルを原材料として使用します。チームがすでにセキュリティのための lint ルールを持っている場合は、`[HC-SECURITY-LINT]` を追加して既存のゲートを指定します。開発者にとっては何も変わりませんが、構成記録にはゲートが実際に施行する内容が反映されるようになりました。

ブラウンフィールドにおける鉄則は、議論に勝つ前に味方を獲得することだ。コードベースのあらゆる領域に関わる完全な構成を最初の 1 週間で押し付けないでください。チームがすでに最も関心を持っている側面、通常はセキュリティまたは信頼性から始めます。修正プロセスによって、これまでに見られた実際のギャップが埋まるということを示してください。そこからラチェットをコンパウンドさせます。 EDD が既存のプロセスをすり抜けた実際のバグを 1 つ発見したことを経験したチームは、次のルールを受け入れる余地を作るでしょう。自分たちがすべて間違ったことをしてきたことを伝える文書として EDD に出会ったチームは、それを回避することになります。

**それが解き放つもの** グリーンフィールドであろうとブラウンフィールドであろうと、展開を行う理由は憲法文書ではありません。検証機構が稼働すると、それが憲法によって可能になるのです。

実稼働コードの品質と配信速度は、実際に見たことのない人にとってはまったく直観に反する形で組み合わされます。エンジニアはコンテキストの切り替えを停止して、ループが検出した可能性のある回帰をデバッグします。 PR には説明ではなく証拠が含まれるため、レビューサイクルが短縮されます。監査は自動的に実行され、最も経験豊富なレビュー担当者が発見したであろう問題にフラグを立てます。これにより、レビュー担当者は実際に判断が必要なアーキテクチャ上の決定に集中できるようになります。

これの最も明白な証拠は、チームに加わった新しいエンジニアは、構成、機能仕様、およびループへの完全なアクセス権を持ち、初日から 48 時間以内に本番品質の機能コントリビューションをメインにチェックインできることです。おもちゃの変化ではありません。ドキュメントの更新ではありません。完全な監査に合格した、証拠を備えた本物の機能。それはまぐれではありませんし、特に珍しいエンジニアでもありません。ガードレールにより、熟練した開発者は初日からチームの品質基準で作業できるようになります。品質基準は、最も長く働いている人の頭の中に組織的な知識として保持されるのではなく、自動的に文書化され、検証可能で、強制されるためです。

それが到達する形です。AI が検証作業を行い、ガードレールがコード レビューをすり抜けてしまうような失敗クラスをキャッチし、エンジニアが実際にエンジニアリング上の判断が必要な問題に思考時間を費やすチームです。

これは、最初は個人プロジェクト、次に中規模のチーム、次にエンタープライズ規模の組織というさまざまな規模で検証されています。メカニズムは 3 つすべてに適用されます。 unfurl コストは異なります (個人開発者は要件レジストリとベンダー間の敵対的レビューをスキップできますが、エンタープライズ チームにはそれらが必要です)。修正の頻度は異なります (単独のプロジェクトでは、「/constitute」の呼び出しの間に数週間かかる場合がありますが、複数の貢献エージェントを持つエンタープライズ チームでは毎週実行されます)。ただし、コア ループ、ラチェット、および証拠要件は、チームの規模に関係なく同じように動作します。品質の下限は上がるだけで、その週にその部屋で最も経験豊富なレビュー担当者が誰であるかに依存することなく、検証機械が下位を維持します。

AIフック

この構成は、ロードされたコンテキストを通じてエージェントの動作を管理します。フックは、作業が完了して PR がすでにオープンされる前に、アクションの瞬間にそれを強制します。フックがないと、違反はレビュー時に捕捉されます。エージェントはすでにコードを記述しており、PR が存在し、それを修正することは作業をやり直すことを意味します。フックを使用すると、キーストロークの前にインターセプトが発生します。

**Claude Code と GitHub Copilot は両方とも、プロンプト送信時にフックを実行します。** 新しいタスクが到着すると、エージェントが何かを行う前にフックが起動されます。その仕事は、タスクが自明ではないかどうかをチェックし、タスク リストを `/wow` ループに再配線することです。これは、エージェントが何かを出荷する前に従う必要がある 10 ステップの EDD シーケンスです。

ステップ 1 ～ 4 を完了せずにステップ 5 に到達したエージェントは、ループに違反しています。フックは、事後ではなく、セッションの開始時にシーケンスを確立します。

**Claude Code** は、ファイル書き込み、ターミナル コマンド、または git 操作の前に、ツール呼び出し前フックをさらに起動します。ループステップが満たされていない場合、コミットを試行することはできません。

**GitHub Copilot** はさらに PR 作成フックを起動します。 PR の記述が完成する前に、フックはセルフレビュー モードで `/audit` を実行し、人間のレビュー担当者がドラフトを見る前に、ディメンション違反、証拠の欠落、および空のテスト計画を検出します。査読者に届くものはすでに事前に審査されています。

**Codex およびその他のエージェント** には、この記事の執筆時点ではネイティブ フック サーフェスがありません。フォールバックは、作成直後に PR にコメントし、違反にフラグを立てる CI ウォッチャー ボットです。これはバックストップであり、第 1 面ゲートではありません。作業は起動するまでにすでに完了しているため、フックによって排除される再作業を防ぐことはできません。

アクティブなフックのあるプロジェクトでは、セッション中に違反がインラインで修正されます。エージェントはギャップを捉え、証拠を提出し、最初からそれを含めます。レビュー時間が短縮されます。リワークが消えます。この構成は、エージェントが読む文書から、エージェントが内部でリアルタイムに操作する制約に移行します。

付録 - 憲法全文

以下は、このプロジェクトの実際の `CONSTITUTION.md` です。このプロジェクトは、単一の開発者による完全に自律的な AI 支援開発プロジェクトです。これは、このコードベースに加えられたすべての重要な変更を管理します。これはテンプレートやイラストではありません。これは、セッションごとにすべてのエージェントによってロードされるライブ ドキュメントです。