必要な文脈だけをAIへ渡し、セッションを越えて知識を引き継ぎ、実行結果を検証し、次の改善までつなげる開発基盤。
その説明さえ、実は信じてはいけないことがある。
AIは、コードが書けないから失敗するのではない。憶えていないから失敗する。
ある条件下で、AIは「完了しました」と報告しながら、実際には何も変えていなかった。エラーログすらなかった。AIの自己申告を信じない — これがFORGEの出発点になった。
1件の実測値を120試行に単純比例させれば「約92時間」という数字は計算できる。しかしこの数字を根拠として使うこと自体が、不誠実である。n=1の比例計算は統計ではなく、ただの算数に過ぎない。
大規模なリポジトリを解析し、関連するソースと関連するコード領域だけを、圧縮された文脈としてAIへ渡す。文脈の粒度は、ソースの性質によって変わる。
上の1,269 → 8は、2026.08.14に実際のHarnessリポジトリを対象として実測した歴史的な結果。すべてのターンが常に同じ削減率を再現するという主張ではない。
AIが作業し、意味のある変更が生まれたら、セッションはその内容をレビューし、引き継ぎ情報を更新する。次のセッションは、そこから続く。
プロジェクトの記憶・引き継ぎ情報を整理し続ける。
実際の運用証拠から改善候補を見つけ、独立した検証へ渡す。詳細はSelf Improvementを参照。
AIは常に、今の作業に必要な情報だけを、今の状態のまま受け取る。
なぜその設計を選んだのか — 積み重ねた判断が、そのまま残る。
セッションが変わっても、作業は振り出しに戻らない。
あるプロジェクトの文脈が、別のプロジェクトに混ざることはない。
知識は出所・時点・状態を持って記録される。過去の事実を無条件に上書きするのではなく、変化の履歴を追跡できる。
開発者がプロジェクトを開けば、その先は人間が説明しなくてもAIが続きを始める。ひとつの論理的なターンが、開発フロー全体を通じて一貫して追跡される。
前回のセッションから、何日経っていても関係ない。
何を作っていて、何が終わっていて、何が途中なのか。
実リポジトリを解析し、今のターンに必要なFocused Sourceを構成する。
2026.08.14実測(歴史的監査): 1,269 audited sources → 8 focusedゼロからの推測ではなく、引き継いだ文脈の上で。
「できました」という自己申告ではなく、実行結果で確認する。
この瞬間の状態が、次のターンの出発点になる。
実際に使ったファイルとシンボルが、そのターンと結び付けて記録される。
Real Turn → Real File → Real Symbol最初からではなく、続きから。
注記 — 文脈に含まれていたことと、原因であることは別の概念である。あるファイルがそのターンの文脈に参加していたという事実だけから、それが問題の原因だったと断定することはない。
サンプルや推定ストーリーではなく、実行結果とJUnit XMLで確認する。歴史的な測定と、現在の運用状態は、はっきり分けて示す。
このプロジェクト自身をProduction Context Engineで解析。初期プロンプトへ渡すFocused Sourceを8件に集約した。これは2026.08.14時点の実測であり、その後のリポジトリ変化を継続的に再測定するものではない。
生成されたFocused Promptと、プロバイダー実行境界が受け取ったPromptの完全一致を検証。
既存資料には全体回帰試験の件数が記録されていますが、実行日を特定できないため、現在の結果として数値を掲示しません。2026.08.14のContext Auditとは対象・範囲が異なります。
実際の本番フックが、実ターンと、実際のリポジトリ相対ファイル・抽出されたシンボルを結び付けて記録した。ファイルパスやシンボル名そのものは非公開。
モック化された単体テストだけでなく、使い捨てのfixture上で実際のGit操作を伴う検証を実行。失敗時の再試行・回復経路も対象に含む。
実際に使用するAI実行経路を、隔離された検証環境で確認した。すべてのプロバイダーが同一水準で検証済みであることを主張するものではない。
MEASUREMENT SCOPE — Context Diet の1,269→8とTest Regressionは、それぞれ別時点・別範囲の実測値。検証範囲の詳細はREADMEを参照。
READMEで検証範囲を見る実際の運用証拠を出発点に、改善の候補を見つけ、独立した検証へ渡す。根拠が無ければ、進めない。
Isolated Candidate — 生成された変更は、まず本体から隔離された候補として扱われる。独立した検証を通過するまで、実プロジェクトには触れない。
根拠となる実測が無ければ、DEFER。実際に、対象となる改善機会が無かった場面で、システムは正しくDEFERを選んだ。改善の発見自体は実証済みだが、自動的なスケジュール実行は現時点でOFF。
このプロポーザル境界は、開発中に実際に検証された — 詳細はIndependent Verificationを参照。
Proposer ≠ Judge。通常の提案は、自分自身を判断する検証ルールを書き換えられない。
採用されるのは、独立した検証を通過した変更だけ。失敗は黙って受け入れられず、昇格に失敗した場合の回復処理を持つ。回復できない異常な状態は、そのまま進み続けるのではなく停止する。リモートへの自律的なpushはない。
ルールは、文書ではなくビルドに置いた。
自律改善機能の実装中、生成側コードが本来越えてはいけない検証境界へ依存した。既存のArchitecture Guardがビルド時にこれを検出し、その変更はそのまま採用されなかった。
実装の詳細ではなく、今の状態だけを見せる。
| Capability | Status |
|---|---|
| Context Diet | PRODUCTION |
| Living / Semantic Handover | PRODUCTION |
| Turn Tracking | PRODUCTION |
| Turn Provenance | PRODUCTION |
| Evidence-to-Code Attribution | FLAGGEDlimited rollout |
| Temporal Memory | SHADOW保存済みの試験範囲。現在値ではありません。 |
| Independent Verification | PRODUCTION |
| Improvement Discovery | PROVEN / GATED |
| Automatic Self-Improvement Execution | OFFgated |
| Temporal Default Rollout | PENDING EVIDENCE |
SHADOW — 影で動作中、まだ既定のふるまいではない。GATED — 実装済みだが自動実行は制限されている。FLAGGED — 限定ロールアウト中。
複数の独立した実プロジェクトが、同じOSの上で日常的に動いている。