第一条：働く「人」を固定する

1回の評価・デプロイサイクルにおいて、モデル、コーディングエージェントのランタイム、ネイティブツールインターフェースの3つを固定します。この3つのうちどれか1つでも変わったら、たとえ世代が1つ進んだだけでも、環境全体を再検証する必要があります。

ブラックボックスを固定する利点は、失敗の原因を特定しやすくなることです。明らかに有能なエージェントがタスクを達成できない場合、その原因は通常5つの場所にあります。関連する組織コンテキストの欠如、実際に使える能力の欠如、有用なフィードバックループの欠如、権限の欠如、そして出口での証拠の欠如です。これら5つはすべてデプロイ環境の属性であり、調査可能で、変更可能です。ブラックボックスを固定しなければ、「モデルが悪いのか、それとも自分の設定が悪いのか」という堂々巡りから永遠に抜け出せません。

世代交代がどれほどの差をもたらすか、2つの数字があります。GPT-5.2 がリリースされたとき、彼は休暇中でした。戻ってみると、チームは追加の環境投資なしで、エンジニア1人あたり毎日1〜2件多くのPRを生み出していました。その後、別の Symphony 環境改修では、エンジニア1人あたりの週間PR数が10倍になったと報告されています。前者はモデル世代交代によるもの、後者は環境改修によるものです。この2つは分けて考える必要があり、それこそがブラックボックスを固定する意味です。

内部ループのレイテンシも検証範囲です。エージェントがどこまで推論できるかは、1回の実行（トラジェクトリ：エージェントがタスクを開始から完了まで処理する全過程）が脱線するまでに得られるフィードバックの量に依存します。GPT-5.2 時代の Codex 環境にはバックグラウンドシェルがなく、エージェントはブロックするビルドスクリプトが完了するまで素直に待っていました。GPT-5.3 でバックグラウンドシェルが追加されると、エージェントは待たなくなりました。チームは1週間かけて、リポジトリのビルドを独自スクリプトから専門のビルドツール（Bazel、Turbo、Nx を順に試行）へと置き換え、全量ビルドが1分以内になる地点で停止しました。この1分がハードリミットと定められ、超えそうになると、手元の作業を止めてビルドグラフの分割に取り掛かります。

検証には引き算も含まれます。エージェントにUIを見せるため、チームはかつて仮想ディスプレイと画面録画の仕組みを自作していました。モデルが自ら画面を見てクリックできる機能（computer use）が登場すると、この仕組みはすべて削除されましたが、エンドツーエンドの検証は失われませんでした。

第二条：社内プロセスデータの水面下を実装する

汎用モデルの重みに含まれているのは、組織ナレッジのほんの一角にすぎません。水面下こそが、実際の作業に必要なものであり、それらは社内固有で、変化し続けています。

この条項は、2つのものを明確にすることを求めます。1つは「データ本体」です。どのようなエンティティ、指標、識別子があり、それらの関係はどうなっているのか。もう1つは「作業本体」です。どのような成果物、ワークフロー、役割、ツール、例外、証拠、承認関係があるのか。

良い例があります。社内データエージェントにデータウェアハウスへの権限を与えるだけでは不十分で、「売上」と「アクティブユーザー」という言葉が社内で衝突する定義を解決できません。エージェントは、会社にどのような製品ラインがあるか、顧客がどのようにセグメント化されているか、どのようなチームがあるか、どの顧客がパイロット中か、現在の計画は何か、共有の指標定義がどのように書かれているかを知る必要があります。これらの関係があって初めて、その会社に固有の答えを出せるのです。

組織形態として、そのまま真似できる方法があります。Basis 社には2つのリポジトリがあります。Arnold は本番用のモノレポ、Atlas は2つ目のリポジトリで、会社のコンテキスト専用であり、本番コードツリーの外にあります。Codex は個人メモ、会社の運営ナレッジ、本番コードを組み合わせて使用できますが、これら2つの情報はそれぞれ独立した更新パスを保持します。実装形態は非常に簡素で、彼の言葉を借りれば「Codex と Markdown で満たされた Git リポジトリ」です。

この層にはもう1つ重要なことがあります。安定した決定は、それを管轄できる層に引き上げるべきです。あるチームがセキュリティ部門と共に、承認済みの暗号化実装を選択しましたが、この決定は Slack に残ったままでした。その後、新しいエンジニアが Codex を使って作業したところ、Codex は別の npm 暗号化パッケージをインストールしました。チームはこの決定を回収し、リポジトリにガードルールとして書き加え、その変更を再実行しました。

第三条：仕事は1つのエージェントに丸ごと任せる

委任するのは結果です。1つのメイントラジェクトリに、分解、実行、統合、証拠提示、安全な完了までを一任し、手順はエージェント自身に決めさせます。人間が介入するのは、方向性、判断、そして結果を伴う承認の3箇所だけです。

彼はしばしば、ほぼ制約のないプロンプトを与えます。このようなプロンプトを彼は「怠惰なプロンプト」と呼びます。方法を空欄にし、どう進めるかをエージェント自身に決めさせるからです。この疎な委任は、同時にテスト手段でもあります。環境が、本当の要求をエージェント自身が見つけ出せるようにできているかを試すのです。エージェントが誤解した場合、露呈するのは環境のどの部分が未整備かということです。これに付随するループは「提案、観察、改善、再実行」です。トラジェクトリを確認し、環境を改善し、今回の結果を破棄して、再実行します。

反例2つは、正例よりも参考になる

1つの依頼は通常、機能的な結果のみを述べます。互換性、保守性、アクセシビリティ、ロールバック、成果物の同期、そして将来の変更ニーズは、すべて暗黙のうちに含まれます。これらの暗黙の要求には、「問題の背後にある問題」という名前があります。エージェントはそれらを自分で見つけ出す必要があります。リポジトリを調べ、現在の動作を確認し、履歴を調査し、この結果とユーザーの関係を理解します。掘り下げても見つからず、しかも欠けている答えが製品意図を変えたり、予期しないリスクを負わせたり、持っていない権限を必要としたりする場合にのみ、人間に質問します。

第四条：千ページのマニュアルを、一枚の索引に

ナレッジベースは大きく検索可能に、作業セットは小さく。ルートにあるガイドは一枚の地図であるべきです。

この条項には由来があります。彼らが最初に作ったモノリシックなエージェントマニュアルは、大きすぎて使えませんでした。それを、短いルート索引に置き換え、背後に索引付けされた設計ドキュメント、製品仕様、実行計画、参考資料を配置しました。段階的開示（プログレッシブ・ディスクロージャー）をリポジトリ自身が管理する機能とし、リンクチェックと鮮度チェックでこれらのルートの信頼性を保証しました。

コンテキストウィンドウが大きくなっても、解決されるのは容量の問題だけです。注意力、検索品質、命令同士の衝突、そして「このステップで実際に重要な事実はどれか」という点は、依然として希少です。決定論的にコンテキストへ物を詰め込むことは、複数回の圧縮を経ると必ず機能しなくなります。エージェントが再びその道を見つけ出せる能力が不可欠であり、最初に詰め込んだものがまだ残っていると期待するのは当てになりません。

ナレッジベースをどう検証するか

新しいセッションを開始し、エージェントが実際にそれを検索し、実際に行動を変えるかどうかを見ます。ドキュメントが存在することは、書かれたことを証明するだけです。さらに一歩進んでアブレーション試験：このコンテキストを外して再実行し、効果が持続しないものは削除します。

このリポジトリ自体がこの条項のサンプルです

自分で確認できる4つの構造的事実：

未解決の決定がルートを決める。目標システムのローカルな証拠が、そのいずれも必要とせずに解決するかもしれません。本当にコンテキストが必要な場合、そのうちの1つから始め、別の独立した決定がまだ保留されている場合にのみ、2つ目を追加してください。 AGENTS.md、リポジトリルート

第五条：ツールが出力するすべての文字が、次のステップのコンテキスト

ある能力が実際に使えるようになるには、6つのステップを完了する必要があります。発見する、今回使うべきだと認識する、正しく呼び出す、返ってきた結果を理解する、エラー時に修正できる、そして最後に実際のシステムで効果を確認する。このサイクルのどこか1つでも欠けると、その能力は形骸化します。

結果の解釈でエラーが見つかった場合は修正に戻り、再呼び出ししてループを形成します。

MCP と通常のコマンドラインの選択は、2つの点でトレードオフがあります。MCP サーバーはツール名と入力形式をすぐにブロードキャストできますが、モデルは新しい呼び出しと戻り値の形状を毎回学習する必要があります。通常の POSIX コマンドは、モデルの強い先験的知識を利用できますが、エージェントがその存在を知るまでは見えません。実際の移行事例があります。チームは当初 MCP を使って Codex が Chrome DevTools プロトコル経由で自社の Electron アプリに接続していましたが、同僚がローカルの TypeScript デーモンと小さなコマンドラインに置き換えました。実際に必要な操作が2、3個だったからです。切り替え後もワークフローは中断しませんでした。

良いツールの7つの行動

誰もが踏む落とし穴

見分けやすい失敗の形があります。エージェントが高価なコマンド（例：cargo test）の出力を減らすため、予防的に head や tail にパイプすることがあります。

解決策はプロンプトではなく、ツールの境界にあります。リポジトリ自身が所有するラッパーがタスクを完全に1回実行し、実際の終了ステータスと全出力を保持し、次の決定に必要なセマンティックな失敗サマリーのみを返し、基盤となる証拠は再実行なしで照会可能にします。

不足があれば掘り下げ、使えるところまで掘る

仕事を丸ごと任せると、能力のギャップが外から内へと層状に露呈します。当初の目標は、Codex が Slack を読み、報告された障害を特定できるようにすることでした。そうすれば、人がメッセージを一つずつ会話に貼り付ける必要がなくなります。

このような能力の探索は、下方に6〜8層再帰します。底に達して使える基本部品を手に入れたら、再び層を上って最初の障害トリアージの目標に戻ります。このような探索のたびに、将来すべてのエージェントが実行できる仕事の範囲が広がります。逆に、使い捨ての人間による中継で回避すると、同じ穴を次の探索にそのまま残すことになります。

第六条：コードはプロンプト

エージェントが読むすべてのファイルが、次の予測に影響します。原文：リポジトリ内のコードはプロンプトです。

モデルの頭の中には、何十ものもっともらしいやり方があります。リポジトリの役割は剪定です。繰り返し現れる構造によって、チームが選択した方法を浮かび上がらせます。一貫性はコンテキスト需要を直接圧縮します。ある可観測性ソリューションがあれば、エージェントが1つのファイルで学んだことをリポジトリ全体に転移できます。6つのソリューションがあれば、呼び出しのたびに、ここではどのソリューションを使うべきかを再調査する必要があります。

逆もまた真で、例は欠陥も良い判断も同じ速さで伝播します。中途半端な移行は、互いに矛盾する2セットのプロンプト材料を生み出します。うまく書かれていないヘルパー関数は、同様の動作を必要とするすべてのパッケージに拡散します。

1つの概念には、1つの正統な出自を

パーサー、リスト型、バージョン定数、状態表現、フィクスチャコンストラクタ、ポリシーチェック、コマンドを作成する前に、既存の概念の出自を探し、必要に応じてそのインターフェースを拡張します。以下は「明確な出自がない」ことを示すシグナルです。

出自が重複するたびに、「ローカルでももっともらしい」継続方向が生まれます。エージェントは身近なすべての前例に忠実に従いながら、リポジトリ全体をより非一貫性にすることができます。

第七条：実行と承認は2つの別々の契約

能力は、どのようにして効果を生み出すかについてです。権限は、どのアイデンティティが、どのリソースに対して、どの環境で、どの効果を、どのくらいの期間、誰の承認を得て、どうロールバックするかについてです。

この2つの契約を分離すると、セキュリティの問題は「ランダムなシステムにゼロエラーを要求する」ことから、「結果はどの程度大きく、回復可能か」へと移行します。資格情報の管理はトラジェクトリの外側に置きます。プロキシプロセスがアクション境界で、セキュアストレージから範囲の狭いキーを取得し、gh が普通のコマンドのように使えるようにします。キーはモデルのコンテキストにもリポジトリにも入りません。さらに2つの保険を追加します。読み取り専用アイデンティティにより、チェックは有用だが変更はできないようにします。エンドポイントバインドされたアクセスにより、基盤となる資格情報をローテーションせずに、特定のエージェント向けチャネルを個別に無効化でき、実行中のトラジェクトリも権限を剥奪できます。

影響のある操作は段階に分け、各段階に必要な権限のみを

Loki は彼の自宅のロボット掃除機で、オープンソースの Valetudo ファームウェアを実行しています。唯一のリモートアクセス経路は、カスタムの Tailscale デーモンです。このデーモンを v1.90.8 から v1.96.4 にアップグレードする際の問題は、アップグレード自体が、失敗したデプロイを復旧するための唯一の経路を壊す可能性があることです。

指示もこの権限契約を通じて解釈します。「マージ」はリポジトリの保護されたマージフローを完了することを意味し、バイパス権限を暗黙に付与しません。「デプロイの準備」が付与する範囲は準備までであり、本番切替は別途承認が必要です。不可逆的な目標や範囲が、ローカルポリシーを確認しても依然として曖昧な場合、エージェントはその境界を越える前に質問すべきです。

安定した承認ルールは、IDポリシー、型付きドメイン操作、スコープ付きツール、環境境界、テスト、マージゲートに落とし込むべきです。結果が重要な場所では、誤ったアクションを不可能にすることが、ルールを書くよりも効果的です。ルールは人間が常に覚えている必要がありますが、仕組みはそうではありません。

第八条：緑のチェックは、それ自身の1項目しか証明しない

検証は、ユーザー、オペレーター、または下流システムが実際にこの結果に依存する境界で行うべきです。ユニットテスト、型チェック、lint、ビルドは内部属性を確立しますが、外部のことを証明することはできません。

この条項を実践する上で最も役立つのは、対照表です。あなたの結論が何であれ、証拠はその境界で取らなければなりません。

この表は、エンジニアリング以外の作業にも当てはまります。中間のコードがエージェントの実行プロセス内に留まり、ユーザーが見ない場合、証明パッケージはユーザーが理解できる言葉で提供する必要があります。スプレッドシートの数式、レンダリングされたスライド1枚、出典付きの結論、完了した状態遷移などです。隠れたスクリプトのテスト成功は、内部属性を確立するだけです。

また、実際のシステムをエージェント自身に見せるべきです。アプリを起動し、ブラウザを操作し、ログを読み、メトリクスとトレースを調べ、永続的な副作用をチェックし、生成コーパスを比較し、CI/CDを監視できるようにします。人間がエージェント自身で見られる証拠を中継すべきではありません。中継は遅延を増やし、診断に必要な状態を剥奪します。セマンティックビューとレンダリングビューを併用します。DOMスナップショットと構造化状態は、ロール、値、関係を見るのに適しています。スクリーンショット、録画、直接の画面操作は、レイアウト、クリッピング、フォーカス、インタラクションの欠陥を露呈させます。

証拠が証明していないことを明記する

前述のセキュリティ勧告のケースでは、レポートに明確に記載されていました。データ破損を引き起こすには、カスタムハッシュ実装と、プログラムクラッシュ後の復旧実行が必要であり、この再現器はデフォルトパスでのメモリ不安全を証明するものではありません。当時の指示は、報告された各問題に影響または悪用可能性を証明することであり、セキュリティ発見らしき推測的な出力では要件を満たしませんでした。

証明の負担は結果に応じて増大します。タイプミス1つ、パーサー移行1回、リモートアップグレード1回、本番リリース1回では、必要な証拠と権限はまったく異なる規模になります。

第九条：一度修正したことは、二度と修正しない

繰り返し発生する修正は、次回の実行を形作る環境へと変換します。この条項は、前述のすべての条項が時間とともに蓄積できるかどうかを決定します。

まず、正確な反例を見てみましょう。ある人はエージェントに具体的なGoインターフェース修正を与えました。元々「成功したかどうか」だけを返していた関数を、「なぜ失敗したか」を説明できる具体的なエラー値を返すように変更するというものでした。エージェントは指名された関数だけを変更しました。その指示の背後にはインターフェース設計に関する一般的な原則がありましたが、今回の修正では、同じ原則が適用される他のインスタンスを検索しませんでした。

繰り返し発生する修正に直面したら、システム問題として扱い、5つのステップを踏みます。

どの層で変更するかは、その教訓がどの程度成熟しているか、結果がどの程度大きいかによって決まります。

判断力が資産になるまでの完全な連鎖

起点は、公開 openai/codex リポジトリに送信された1つのPRです。pnpm をアップグレードしていくつかの脆弱性を修正し、インストール後の自動スクリプト実行を禁止するものでした。このパッチから遡って推論すると、4つの原則が浮かび上がります。パッケージマネージャーは高リスク境界である、依存関係は最新に保つ、インストールプロセスはCIで任意のコードを実行すべきではない、例外には人間のレビューが必要である。

特筆すべきは2回目の昇格です。スキャナ導入後、Slack でのフィードバックによると、スキャナは具体的なインスタンスを捕捉しやすい一方、セキュリティエンジニアの頭の中にある一般的な参照枠組みは捕捉できませんでした。チームは欠落していたガードと調査シグナルを SECURITY.md に追加しました。この原則はその後、毎日スキャナと、新たに追加された依存関係深度・ライセンススキャナの両方に供給されます。このようにして、判断力はラウンドごとに蓄積されていきます。

第十条：一貫性を守り、長期的なリスクを引き受ける

実装が安価になった後、希少になるのは将来の一貫性と長期的な所有権です。受け入れられた各変更は、共有システムに制約と保守義務を追加し続けます。

この条項には、全体で最も誠実な部分があります。あの5ヶ月で100万行になった社内プロダクトでは、社内リリースと採用証明戦略はスタートアップ期には機能しました。しかし、アーキテクチャの一貫性が「数年」という時間スケールでどう進化するかは、原文が公に認める未解決の問題です。

もう1つの誠実な点は、自身のプロジェクトを使って「エージェントは難しい仕事を一気にこなせる」という印象に反論していることです。Artichoke の状態モデルリファクタリングは、当初114ファイルからなる巨大な変更で、コンパイルすら通りませんでした。その後、50件の準備PRに分割して順次マージし、同時期にリポジトリには他に200件のPRが入り、さらに数回の大規模な統合試行とランタイム障害を経て、ようやくマージされました。

変更のサイズや実行時間は、安全なルートが既に分かっているかどうかをほとんど示しません。違いはルート自体が確定しているかどうかにあります。彼はこの欠落した能力に名前を付けました。「あと50件のPRが怖い」です。将来の変更で自分がどれだけ後悔するかを予測する能力です。彼はこれを、依然として解決されていない能力の問題として明確に挙げています。

何が書き換えを生き残らなければならないか

実装自体は破棄可能な一回のレンダリングです。以下の6つが守るべきものです。

Symphony はまさにこれを実行しています。動作仕様を公開し、他のチームがそれに基づいて独自の独立した実装を生成できます。この形態は「ゴーストライブラリ」と呼ばれ、共有されるのはコードパッケージではなく契約です。

第十一条：方向が決まった仕事は、常駐ループにする

方向性がとっくに決まっているのに、スケジュールに入らない仕事のカテゴリがあります。ローカライゼーション、計装の追加、依存関係の最新維持、時代遅れの互換パスの削除、アーキテクチャドリフトの修正、生成データとドキュメントのリフレッシュなどです。望ましい結果、証明方法、承認境界の3つが明確になれば、これらの仕事は自動的に前進し続けることができます。

ループを立ち上げられるかどうかは、5つの質問に答えられるかどうかで決まります。

ここでは「タスク」と「目標」を区別します。「この不安定なテストを直す」は1つのパッチで終わります。「CIのp95レイテンシをN分以内に保つ」は目標であり、システムを継続的に監視し、介入を生成・テストし、必要に応じて人間の承認を要求し、明確な引退条件が必要です。

緊急対応に関する主張もあります。コードレッドアラートはメトリクスが緑に戻ったことで終わるべきではなく、保守ループを残すべきです。対応プロセスで、人間はどの不変条件が重要か、どのシグナルがドリフトを予示するか、どの介入が効果的かを学びます。これらは、目標、センサー、承認済みアクション、エスカレーションパス、そしてこのループの所有者とともに記録されるべきです。エージェントの実行が十分に安価になれば、新たに発見された不変条件の中には、常駐チームなしで保守され続けるものもあります。

環境自体も雑草が生えます。ドキュメントは古くなり、コードには矛盾する書き方が生まれ、レビューコメントは欠落したガードを露呈し、かつて有用だったツールがモデル世代交代後に冗長になります。OpenAI 側では、毎週の手動クリーンアップを常駐バックグラウンドタスク群に置き換えました。確立された原則から逸脱している箇所のスキャン、品質評価の更新、焦点を絞ったリファクタリングPRの起票、古いドキュメントのクリーンアップなどです。小さな修正は、悪い書き方が将来のプロンプト材料になる前に実行されるべきです。

人間の位置はこの条項で明確にされています。ループが維持するのは、すでに選択されたポリシーと変化する世界との関係です。「どの世界を築く価値があるか」は依然として人間の仕事です。

第十二条：実測された有効性で最適化する

トークン、コード行数、エージェント数、チェック項目、これらはすべて入力です。最適化すべきは、希少な人間の注意力1単位あたりに換算された、受け入れられた結果です。

トークンランキングは、虚栄の指標の1つです。それが報酬とするシグナルは、価値が横ばいでも増え続けます。「エンジニア1人あたり毎日10億トークン」という表現には、後に結果ゲートが追加されました。これらの作業は、メインブランチにマージされ、ユーザーエクスペリエンスを改善しない限り、カウントされません。

3つの概念を分ける必要があります。到達可能性エージェントがこの仕事のどの部分に触れられるか。リポジトリ、ローカルアプリ、テスト、ブラウザ、ログ、デプロイ、証拠はすべて到達可能性を広げる、活動量（トークンとビジー時間）、そして有効利用率実際に受け入れられた結果に到達した、または再利用可能な証拠を生み出した活動の割合。予防可能な破棄、やり直し、修正はこれを削るです。

4つの時計は分けて計る

なぜ分ける必要があるか、2つの例を並べれば明らかです。あの60時間のリファクタリングは、実際の所要時間は長く、3〜4日に及びましたが、人間との同期インターフェースは初期プロンプトと2回の追加質問だけで、約3.3〜3.5億トークン、2800ドルを消費し、1つのPRを生成しました。彼は自分で手作業なら3週間かかると見積もっています。対照的に、2023年のChatGPTとのペアプロは、コードがエディタとブラウザ間を行き来し、テスト結果を人肉でチャットに転記し、1回のセッションで数百のプロンプトを使用しました。実際の所要時間は長くありませんでしたが、人間の注意力は1時間で枯渇しました。

探索、やり直し、無駄は3つの異なるもの

破棄は生産的であり得ます。最終的なインターフェース形状が未定の不確実性の高いリファクタリングでは、彼はエージェントに最大5万行の探索的変更を生成させ、レビューのためにPRを押し出し、その後破棄させます。この試行は、エージェントがどこで失敗しそうか、最終的な切替に必要なインターフェースの継ぎ目がどこかを露呈させました。彼はこの失敗マップを約15の準備・準備PRに変換し、その後実際の切替に戻りました。

この十二条を自分のプロジェクトにどう使うか

リポジトリの playbooks ディレクトリには、境界が明確で再実行可能な実タスク向けの、そのまま使えるプロセスが用意されています。

5番目のステップの「新規」には理由があります。新しいセッションと、隔離された同等の開始状態を使用し、再実行が当初の実装会話から暗黙の助けを引き継がないようにします。また、今回の介入が実際に検索されたか、呼び出されたか、そして今回の再実行と関係があるかを個別に確認する必要があります。一度の成功した結果は、使用されなかった指示やツールに対する証拠にはなりません。

以下の3つのテンプレートは、そのまま自分のプロジェクトにコピーできます。

対象システムとバージョン：
関連する外部状態：
固定されたモデルとコーディングエージェント設定：
代表的なタスク：
受け入れ可能な結果：
その結果を証明できる証拠：
権限範囲と承認境界：
予算と停止条件：
不足が疑われる箇所：

もし【それを最も早く制御できる場所】に【何らかの変更】を加えれば、固定されたエージェントは【代表的なタスク】で【観察可能な行動変化】を示すだろう。なぜなら【メカニズム】だから。

この仮説を支持できる証拠：
この仮説を弱める可能性のある証拠：
予想される保守コストと帰属：

タスクと受け入れ可能な結果：
対象バージョンと外部状態：
固定されたエージェントと権限範囲：

ベースライン証拠：
最初に壊れた受渡し、およびその責任の所在：
変更内容と期待されるメカニズム：
実施した検証：
新規での再実行の証拠：

結果の比較：
証拠の比較：
人間による中継と遅延の比較：
リスクと保守コストの比較：
もし「それを外してもう一度実行」した場合の結果：

決定：維持 | 変更 | 削除
長期的な帰属と記録された教訓：
後続アクションまたは引退条件：
既知の限界：

どのような場合に比較実験が無効になるか

無効化リストも別途あります。いずれか1つに該当した場合、その評価は目的とする結論を裏付けることができません。

十二条は三層に分かれます。上3条は境界を定め、責任を追跡可能な環境を固定します。中6条は日々調整する操作のテコです。下3条は、このシステムが時間とともに価値を増すかどうかを決定します。境界の固定が起点です。モデル世代交代やエージェント設定変更があれば、環境全体を再検証する必要があります。そうしないと、タスクが失敗したとき、モデルが悪いのか環境の設定が悪いのか区別できません。

リポジトリ内のコードはエージェントに与えるプロンプトです。1つの書き方が繰り返し現れれば、エージェントはそれを模倣します。2つの書き方が並存すれば、両方とも複製されます。修正も同様で、一度の指名修正が指摘された箇所だけを直した場合、同種の問題は別の場所でそのまま再発します。

本文には、そのままコピーできる3つの穴埋めテンプレートと、「今回の比較実験が有効かどうか」を判断する9項目チェックリストも用意されています。

以下の数字はすべて Ryan Lopopolo 氏自身のプロジェクトでの実測値であり、第三者による検証はありません。