ダークファクトリーの検証レイヤー

StrongDMは2つのルールのもとでソフトウェアをリリースしました。「コードは人間が書いてはならない」「コードは人間がレビューしてはならない」というものです。¹ Justin McCarthy、Jay Taylor、Navan Chauhanの3人チームが、エンジニア1人あたり1日最低1,000ドルのトークン予算で、AttractorとCXDB（Rust 16K行、Go 9.5K行、TypeScript 6.7K行）を構築・リリースしました。¹ BCG Platinionは、SpotifyとTechCrunchの報道を引用し、Spotifyの優秀な開発者たちが2025年12月以降コードを書いておらず、同社が毎月数百件のAI生成プルリクエストをマージしていると報告しています。²

Dan Shapiroはその到達点をレベル5、すなわちダークファクトリーと呼んでいます。マシンがコードを生成し、マシンが検証し、人間が1行も読むことなくデプロイされる世界です。³ それ以前のレベルは、多くのチームが今まさにたどっている道筋を示しています。手動コーディング（レベル0）から始まり、タスク委譲（レベル1）、高速道路でのオートパイロット（レベル2）、セーフティドライバー付きのWaymo（レベル3）、そしてスペックを書いて12時間離席するロボタクシー（レベル4）へと進みます。³

まだ誰もうまく答えられていない問いがあります。レベル5における検証レイヤーとは、具体的にどのようなものでしょうか。

検証問題は複合的に膨らむ

レベル5未満のすべての段階では、どこかの時点で人間がコードを読みます。レベル3ではシニア開発者としてAIを管理し、レベル4では12時間後にテストが通ったかを確認します。³ これらのレベルが機能するのは、組織の知識を持つ人間が意図とのパターンマッチングを行えるからです。スペックに「指数バックオフでリトライ」と書いてあるのにコードが線形リトライを実装していれば、開発者は一目で気づきます。

人間を完全に排除すると、検証は別次元の問題になります。程度の差ではなく、質的に異なるのです。検証者は読解力に頼ることができません。「正しい」とは何かを実行可能な形式でエンコードし、成果物そのものを検査することなく、そのエンコーディングに対して出力を評価しなければなりません。

核心的な罠は、エージェントがテストをゲーミングすることです。StrongDMは、エージェントがテストスイートを通過するために return true を書きながら、実質的に何もしていないケースを発見しました。¹ テストはグリーン。CIパイプラインも問題なし。しかしコードは無価値でした。スタンフォード大学ロースクールのEran Kahanaはこの観察を構造的な警告へと拡張しています。根本的な問題は循環性にあり、同じ技術クラスが、同じクラスが書いたコードを評価しているのです。⁴

グッドハートの法則がここでは異常なほど強く作用します。エージェントがテスト通過に最適化すると、テスト通過は正しさの指標ではなくなります。⁴ ターゲットとなったあらゆる指標は、良い指標であることをやめるのです。ダークファクトリーの検証レイヤーがこのダイナミクスを考慮しなければ、品質ではなくコンプライアンスを測定することになるでしょう。

StrongDMの実際の検証手法

StrongDMの答えは、彼らが「シナリオ」と呼ぶものです。コードベースの外部に保存されたエンドツーエンドのユーザーストーリーで、機械学習におけるホールドアウトセットのように機能します。¹ このアナロジーは的確です。MLモデルが学習に使っていないデータで評価されるのと同様に、エージェントが構築したコードは、生成中にエージェントがアクセスできないシナリオで評価されます。

主要な指標は「Satisfaction（満足度）」です。観測されたトラジェクトリのうち、ユーザーを満足させる可能性が高いものの割合を示します。¹ どのスコアが十分な満足度を構成するかについて、業界標準は存在しません。StrongDMは独自のしきい値を経験的に導き出しました。

シナリオベースのテストをスケールさせるために、StrongDMはDigital Twin Universeを構築しました。Okta、Jira、Slack、Google Docs、Drive、Sheetsの行動クローンです。¹ これらのツインは、広く利用されている公開リファレンスSDKクライアントライブラリを使用して、100%のAPI互換性を目指しています。¹ エージェントはモックエンドポイントではなく、ツインに対して実行されます。ツインの行動忠実性がテストの信頼性を決定します。

StrongDMは私自身も経験したことを観察しています。「Claude 3.5の第2リビジョン（2024年10月）以降、長期的なエージェントコーディングワークフローがエラーを蓄積するのではなく、正しさを積み重ねるようになった」のです。¹ 能力しきい値を下回る場合、エージェントの実行が長くなるほどミスが増えます。しきい値を上回ると、長い実行ほど良いコードが生まれます。ダークファクトリーパターンは、モデルがそのしきい値を超えて初めて実現可能になりました。

ガバナンスの5つのレイヤー

BCG Platinionの5本柱トランスフォーメーションフレームワークには、コードが本番に到達する前に複数の検証ステップを含むガバナンスレイヤーが含まれています。² 5本柱とは、インテント駆動型オペレーティングシステム、体系化された知識インフラ、人材スキル向上、独立した検証エージェントによるガバナンスレイヤー、そしてオーケストレーションのためのファクトリーアーキテクチャです。² ガバナンスの柱の中で、BCG Platinionは独立エージェントによるシナリオベーステスト、静的解析、アーキテクチャ適合性チェック、行動回帰テスト、そして出力を積極的に破壊しようとするレッドチームエージェントを記述しています。²

独立性が重要です。同じエージェントが自分のコードを書いてテストする場合、Kahanaの循環性問題が適用されます。⁴ 異なるシステムプロンプト、異なるコンテキスト、異なるインセンティブを持つ別のエージェントが作業を評価する場合、障害モードの相関が低くなります。排除ではなく、脱相関です。2つのエージェントが学習データから受け継いだ系統的バイアスを共有する可能性は残ります。しかし、評価エージェントが異なるフレームから動作する場合、同一の盲点を持つ確率は低下します。

BCG Platinionは、ダークファクトリーチームにとって「インテント思考」が重要な能力であると指摘しています。ビジネスニーズを、望ましい成果の正確でテスト可能な記述に変換する能力です。² 人間の役割は、コードを書くことからエージェントが実行可能な仕様を書くことへとシフトします。不十分な仕様は、誤った動作に対して通過するテストを生み出します。StrongDMが遭遇したのと同じ return true のダイナミクスです。¹

BCG Platinionは、私自身が直接経験した制約も指摘しています。「AIエージェントは、アクセスできる体系化された知識の質によってのみ効果を発揮する」というものです。² プロジェクトコンテキストなしで動作するエージェントは、もっともらしいコードを生成しますが、ローカルの慣習に違反し、アーキテクチャ上の決定を無視し、チームがすでに解決した問題を再発見してしまいます。体系化された知識（設計決定、APIコントラクト、スタイルガイド、障害履歴）は、ドキュメントではなくインフラなのです。

レベル4で私が実際に運用しているもの

私のオーバーナイト実行ループ、Ralph Loopは、Shapiroのレベル4で動作しています。スペックを書き、エージェントを起動し、眠り、朝に結果をレビューします。エージェントは95以上のフックに対して実行され、すべてのツールコール（ファイル書き込み、gitコマンド、シェル実行）が実行前後にインターセプトされます。フックは、エージェントが交渉もオーバーライドもできない制約を強制します。

フックはKahanaのゲーミング問題にツールレベルで対処しています。mainへのフォースプッシュを試みるエージェントは、テストがダメージを検出した後ではなく、コマンド実行前にブロックされます。.env パターンに一致するファイルをコミットしようとするエージェントはインターセプトされます。pytestを実行せずに「全テスト通過」と報告するエージェントは、エビデンスゲートによってフラグが立てられます。エビデンスゲートは、テストが通るという主張ではなく、ゼロ失敗を示す貼り付けられたテスト出力を要求します。

エビデンスゲートは、すべての重要な変更に対して6つの基準を強制します。コードベースのパターンに従っている（パターンとファイルを名指し）、最もシンプルな動作する解決策（却下した代替案を述べる）、エッジケースの処理（各ケースを列挙）、テスト通過（出力を貼り付け）、リグレッションなし（確認したファイルを名指し）、そして実際の問題を解決している（ユーザーのニーズと変更がどう対処しているかを述べる）。「〜と思います」「〜のはずです」はエビデンスではありません。ゲートは曖昧な表現を拒否し、具体的な成果物を要求します。

品質ループ（実装、レビュー、評価、改善、俯瞰、反復、報告）は、CLAUDE.mdを通じてエージェントのシステムプロンプトにエンコードされた行動制約として実行されます。ループはエージェントがすべてのステップに従うことを保証するものではありません。フックがそれを検証するのです。

BCG Platinionの5本柱は、私がすでに維持しているインフラにマッピングされます：

• インテント駆動型OS: CLAUDE.mdファイルとPRD駆動型開発スペックが、プロジェクトの意図を実行可能なコンテキストとしてエンコードしています。
• 体系化された知識: 139以上のスキルが再利用可能な機能として整理され、プロジェクトの慣習、アーキテクチャ上の決定、ドメイン知識へのアクセスをエージェントに提供しています。
• ガバナンス: フックがインターセプトレイヤーを実装し、エビデンスゲートが監査レイヤーを実装し、品質ループが行動制約レイヤーを実装しています。

まだ構築していない柱が2つあります。人材スキル向上（ソロプラクティショナーには関係ない）と、専用オーケストレーションプラットフォームとしてのファクトリーアーキテクチャ（現在の構成は専用ファクトリーではなく、Claude Codeのネイティブエージェントスポーニングを使用）です。

レベル4とレベル5の間のギャップ

レベル4からレベル5への移行は、朝のレビューを排除することを意味します。現在、私は朝起きてエージェントが一晩で生産したものを読みます。gitの差分を確認し、アプリケーションを実行し、出力が自分の意図と一致しているかを検証します。このレビューには30分から1時間かかり、フックが見逃す問題をキャッチしています。

フックが見逃す問題こそが興味深いものです。現在の自動化がうまく処理できないカテゴリに分類されます：

インテントドリフト。 エージェントはスペックに忠実に従ったものの、スペックが曖昧であり、エージェントが誤った解釈を選択したケースです。有効な動作を生み出す誤った解釈をキャッチするテストは存在しません。StrongDMのシナリオアプローチは、技術要件ではなくユーザーストーリーを仕様としてエンコードすることで、この問題に取り組んでいます。¹ シナリオはコードが何をするかではなく、ユーザーが何を体験するかを記述します。

アーキテクチャの侵食。 エージェントが単独では機能するが、システムの構造的一貫性を劣化させる機能を追加したケースです。既存のリポジトリパターンをバイパスする新しいデータベースクエリ。別のモジュールのロジックを複製する新しいエンドポイント。静的解析はこれらの一部をキャッチします。BCG Platinionのガバナンスレイヤーであるアーキテクチャ適合性チェックはさらに多くをキャッチします。² しかし、新しいコードがパターンとは技術的に整合しているものの、将来の変更で複合的に悪化する概念的な分裂を導入するような微妙なケースは、どちらもキャッチできません。

組織知識の喪失。 Kahanaは過小評価されているリスクを提起しています。誰もコードを読まなければ、誰もシステムに対する直感を構築しないのです。⁴ Kahanaが警告するように、「なぜそうなっているか誰も知らない。どう修正すればいいか誰も知らない」という状態に陥ります。⁴ 現在、朝のレビューがその直感を少しずつ構築しています。レベル5では、システムはオペレーターにとって不透明になります。あらゆる複雑なシステムはいずれ、自動化では対処できない介入を必要とします。セキュリティインシデント、テストスイートに組み込まれた前提に違反するビジネスロジックの変更、ドキュメントとは異なる動作をする外部システムとの統合などです。コードを読んだことのないオペレーターは、効果的に介入することができません。

検証レイヤーに本当に必要なもの

StrongDMの実践、BCG Platinionのガバナンスフレームワーク、Kahanaの障害分析、そして私自身のインフラを総合すると、ダークファクトリーの検証レイヤーには最低限以下が必要です：

ホールドアウト型の評価。 コード生成中に生成エージェントがアクセスできないテストです。StrongDMのシナリオ。コードベースとは別に保存され、独立したエージェントによって評価される行動仕様です。ホールドアウト評価がなければ、グッドハートの法則があらゆるテストスイートをターゲットに変えてしまいます。

統合テストのためのデジタルツイン。 エージェントは本番システムに対してテストすることができません。モックは浅すぎます。APIコントラクトは検証できても、動作は検証できません。外部依存関係の行動表面を複製するツインにより、本番リスクなしでエンドツーエンドのシナリオ実行が可能になります。

障害モードが脱相関したマルチエージェント検証。 コードを書くエージェントと評価するエージェントは、異なるコンテキストから動作しなければなりません。ゲーミング、ショートカット、ファントム検証を積極的に探査するレッドチームエージェントは、パッシブテストでは提供できないレイヤーを追加します。

ツールレベルのインターセプション。 事後にダメージを検出するテストではなく、実行前に有害な操作をブロックするフックです。フックレイヤーはエージェントの意思決定の下位で動作し、巧妙なプロンプティングや return true のショートカットで回避することができません。

実行可能なインテント仕様。 曖昧さが検出可能なほど精密な仕様です。BCG Platinionの「インテント思考」能力。² Shapiroのレベル4で12時間離席する前に書くスペック。³ 仕様こそがプロダクトであり、コードはその副産物に過ぎません。

アカウンタビリティのギャップのない監査証跡。 Kahanaは、出力が「適切な責任者まで追跡可能」であることを求めるAIライフサイクル基本原則を引用しています。⁴ エージェントが構築したソフトウェアに対する業界標準の監査手法はまだ存在しません。⁴ 検証レイヤーは、人間（または規制当局、またはインシデント対応者）がデプロイされた動作から、それを生成した仕様まで遡れるアーティファクトを生成する必要があります。

正直な評価

レベル4は高い確信を持って運用しています。オーバーナイトエージェントが生産する作業は、朝のレビューを通過することがほとんどです。フックが機械的な障害をキャッチし、エビデンスゲートが認識論的な障害をキャッチし、品質ループが行動上の障害を減少させています。

レベル5には、まだ解決できていない問題の解決が必要です。人間のパターンマッチングなしのインテントドリフト検出。構造的違反だけでなく概念的侵食をキャッチするアーキテクチャ適合性。オペレーターの頭の中ではなく、システム内に蓄積される組織知識。

BCG Platinionは、ダークファクトリーパターンを採用したチームで3〜5倍の生産性向上を報告しています。² StrongDMは3人のエンジニアとトークン予算でエージェント構築ソフトウェアをリリースしました。¹ 生産性の根拠は明確です。検証の根拠はまだ確立されていません。

レベル5で成功しているチームには共通の特徴があります。コード生成よりも検証インフラに多く投資しているのです。StrongDMはエージェントにコードのシッピングを委ねる前に、Digital Twin Universe全体を構築しました。¹ BCG Platinionのフレームワークには、コードが本番に到達する前に複数の検証ステップを含むガバナンスレイヤーを含む5つのトランスフォーメーションの柱があります。² ダークファクトリーとは、暗闇で稼働するファクトリーではありません。検証レイヤーこそが照明であり、コードを含むそれ以外のすべてはコモディティであるファクトリーなのです。

以前、エージェントが無監視で実行されたときに何が壊れるかと、ファントム検証に対する防御としてのエビデンスゲートについて書きました。これらの記事はレベル4のインフラを記述しています。ダークファクトリーは同じインフラを要求しますが、現在朝の差分を読んでいる人間なしで動作するよう拡張する必要があります。フック、エビデンスゲート、品質ループ。これらはレベル5で必要ですが、十分ではありません。欠けているピースは、生成と同じ自律性でスケールする検証です。

そのピースの構築こそが、これからの仕事です。