プロトタイプからエンタープライズ本番環境へ：アンドリュー・ン氏の「3つのループ」を拡張する

ある 2026年6月下旬のレターで、アンドリュー・ン氏は、週末に娘のためにタイピング練習アプリを構築した経験を、0から1のAI製品開発における「3つの入れ子状のループ」の具体的な例として挙げました。その際、コーディングエージェントは約1時間自律的に動作し、何度もブラウザを開いて自身の作業を確認していました。この3つのループとは、エージェントによるコーディングループ（数分単位）、開発者のフィードバックループ（数時間単位）、そして外部フィードバックループ（数日から数週間単位）です。これらのループそのものについては、それぞれのクロック、失敗モード、必要なテレメトリを含め、別の記事で解説しました。 大規模な運用ループに関する補足記事。本稿では、ン氏のフレームワークの別の側面、つまりexplainx.aiによるレターの解説記事でエンタープライズ分野の読者が指摘した点について掘り下げます。それは、製品が週末のアプリではなくエンタープライズシステムである場合、外部ループはどうなるのかという問いです。ン氏のレターでは、外部ループとは「友人、アルファテスター、A/Bテストによる本番環境」であると率直に述べられています。これに対し、エンタープライズ分野の読者は、規制の厳しい環境では、外部ループには消費者向けの実験だけでなく、ポリシー、ガバナンス、監査、説明責任も含まれるべきだと主張しました。本稿は、まさにその境界線に焦点を当てています。3つのループという手法は有用な区別を示しており、エンタープライズの現場でも有効ですが、外部ループには週末のアプリ開発では直面しない要件が加わります。それらを満たすことこそが、デモ用のプロトタイプと、企業内で実際にリリースされる製品との違いです。後半では、これらの要件を文書化されたメカニズムにマッピングします。ただし、常に忘れてはならないのは、インフラストラクチャは手法を支えるものであり、その中心にある判断を置き換えるものではないという点です。

1. フレームワークは維持されるが、外部ループは現場で変化する

まずはン氏のフレームワークを正当に評価することから始めましょう。本稿の論旨は、その正当性を前提としているからです。3つのループは現実を的確に捉えています。内側のエージェントループは、人間が製品の意思決定（中間のループ）に集中できるよう、十分に高速にコードを記述・検証します。そして、全体の価値はビジョンを検証する外部シグナル（外部ループ）の質に依存します。ン氏の週末アプリが完璧な例である理由は、まさにその規模の小ささにあります。外部ループは「娘がアプリを使い、彼が猫のコスチュームや親のログインフローについて考えを変える」というものです。これを構築するのは決して簡単ではありませんが、外部ループの 義務 は軽微です。タイピングアプリを監査する者はおらず、コンプライアンス責任者が承認印を押すこともなく、変更の承認者を問う監査人もいません。では、同じ手法を企業に持ち込んでみましょう。内側のループは変わりません。エージェントは依然として数分おきにコードを書き、テストします。中間のループも形は変わりません。人間が数時間単位で舵取りを行います。しかし、外部ループは変容します。「ユーザーへのリリース」は、 顧客へのリリースを意味し、 ポリシーに従い、 説明責任を伴うものとなります。そして、重要な外部フィードバックには「人々がそれを気に入るか」だけでなく、「ビジネスが責任を負う制約を満たしているか」が含まれるようになります。これはン氏のフレームワークへの批判ではなく、explainx.aiの解説記事でエンタープライズ分野の読者が指摘した「エンタープライズにおける適用例」であり、開発が単なるビルドから製品へと変わる地点なのです。

2. 本番環境への移行は「外部ループ」の課題である

プロトタイプで3つのループ手法を試したチームにとって心強いのは、本番環境への移行にあたって、構築方法そのものを変える必要はないという点です。もちろん、ガバナンスは移行の重要な一部ですが、それがすべてではありません。チームには依然として従来通りの本番エンジニアリング（デプロイ、信頼性、キャパシティ、ロールバック、インシデント対応、セキュリティ、アプリケーションレベルのテスト）が必要です。コントロールプレーンは、そのより大きなシステムにおけるガバナンスやモデル／ツールトラフィックの層を管理します。内側のループ（仕様策定、エージェントによる反復、検証ゲート、実行ごとの予算上限）は、出力がタイピングアプリであれ、保険金請求処理システムであれ、同じ規律が求められます。変わるのは、その 周辺にあるものすべてです。 ループは変化します。外側のループが新たな責務を内側へと広げるからです。これまで開発者のPC上で個人の認証情報を使って実行されていたエージェントには、独自のIDが必要になります。「誰がこれを行ったのか」という問いに対し、「開発者のキー」以外の答えが求められるようになるためです。週末に個人のサブスクリプションで利用されていたエージェントには、所有者が管理する予算が必要になります。経費項目として誰かが責任を負わなければならないからです。テストデータのみを扱っていたエージェントが実際のユーザーデータを扱うようになれば、入出力の監視が不可欠となります。また、ターミナルで全アクションを確認できていたエージェントが、他者によるレビューが可能な環境で実行されるようになれば、永続的な記録が必要となります。これらはビルドループの懸念事項ではなく、エンタープライズの観点における「アウターループ」の懸念事項、つまりエンタープライズ・ガバナンスの文脈におけるポリシー、ガバナンス、監査の領域です。その多くは周辺インフラストラクチャを通じて強制可能であり、エージェントやアプリケーション側は引き続きタスク設計、データ最小化、ツールセマンティクス、ビジネスロジックを担うことができます。これが、卒業（本番環境への移行）が現実的である大きな理由です。アプリケーションのモデルと登録されたMCPトラフィックが適切なゲートウェイを通じて統合されれば、チームはエージェントごとに個別に再実装するのではなく、トラフィックレベルの制御を一元管理できるようになります。統合には依然として認証情報、エンドポイント、ポリシーの適用、エージェント登録、メタデータ、ツールルーティングの設定が必要です。

3. 3つのループの卒業：TrueFoundryがそれぞれに適合する場所

Ng氏のループを1つずつ取り上げ、それぞれに付随するエンタープライズ要件を、文書化されたメカニズムにマッピングします。 インナーループはそのまま維持されます — 意図的に。検証ゲートと実行ごとのコスト上限を備えたエージェント型コーディングループは、そのまま維持すべき部分です。もしマネージドランタイムで実行されるのであれば、 Agent Harness がオーケストレーション、状態管理、ツール実行、ステップレベルの可観測性を提供し、複数の関係者が確認できるようになります。仕様、テスト、検証基準、停止条件の定義は、引き続きアプリケーション側が行います。 ミドルループは、評価と段階的ロールアウトへと進化します。 Ng氏はすでに、同じ失敗が繰り返される場合に評価（evals）を推奨していますが、本番環境ではその直感がインフラストラクチャとなります。ゲートウェイのテレメトリが、接続されたオンラインまたはオフラインの評価システムにフィードされる仕組みです（評価パターン）。スコアラー、サンプリングポリシー、キャリブレーション、回帰検知、プロモーションロジックはチームが実装または統合する隣接ワークフローとして残り、仮想モデルの重み付けによってトラフィックの制御された割合を候補ターゲットへ振り分けます。これは、呼び出し側が使用するモデル名を変更することなく、意図的な設定によって拡大や復元が可能です。これが、当社の ルーティング分析 で詳述するメカニズムです。言い換えれば、開発者のステアリングフィードバックに安全装置が備わることになります。仕様を変更し、トラフィックの5%に適用し、評価を監視し、拡大またはロールバックするのです。 アウターループは、ガバナンスの側面を獲得します。 報告されたガバナンス上の観測結果が、設定として反映される場所がこちらです： モデルアカウントのアクセス制御 は、どのユーザー、チーム、アプリケーションが承認済みモデルを呼び出せるかを管理します。一方、MCPゲートウェイおよびエージェントゲートウェイのトラフィックにおけるエージェントレベルの帰属については、個別に管理される各エージェントが登録済みの エージェントIDを提示します。これにはエージェント登録情報と関連ポリシーが含まれ、誰がそのエージェントを呼び出せるか、誰のために動作できるか、どのダウンストリームリソースにアクセスできるかが定義されています。 予算 は、所有者に利用額を割り当て、強制適用が有効な場合は厳格な制限を課します（警告のみのモードでは、トラフィックをブロックせずに通知を行います）。設定されたゲートウェイポリシーにより、モデルの要求と応答、および関連するゲートウェイを通過する登録済みMCPツール呼び出しを検査できます。各MCPツールの呼び出しは個別に評価されます。これはアプリケーション側の任意のツールには適用されず、出力ガードレールにはストリーミングではない完全な応答が必要です。これにより、プロトタイプでは確認できなかった実際のユーザーデータを保護します（ガードレールのドキュメント）。そして、 メトリクスダッシュボード は、利用額、ボリューム、エラー、レイテンシ、ルーティング、ガードレールの結果に関する集計データを提供します。一方、リクエストトレースとリクエストログは、「説明責任」が具体的に何を意味するのかを示すリクエストレベルの証拠となります。ログ設定は、リクエストおよびレスポンスの本文を保持・編集するかどうかを個別に決定します。コスト、トークン、レイテンシ、リクエストのメタデータは引き続き記録されます。Ng氏の コンテキストアドバンテージのポイント は、開発ループにおける責任として残ります。チームは、仕様、プロンプト、データセット、評価、レビューを通じて、ユーザーのニーズ、ドメインの制約、コンプライアンス要件、製品の意図をコード化します。これとは別に、Agent Harnessは、明示的な承認決定が下されるまで機密性の高いツール呼び出しを一時停止できます。これは実行チェックポイントであり、認可やアップストリームのコンテキストエンジニアリングの代わりではありません。明示的なレビューが必要な機密性の高いアクションについては、承認ポリシーによって、重要なステップでツールが実行される前に人間によるチェックポイントが作成されます。これが、私たちが タスクベースのアクセス 分析で展開しているパターンです。手法に変更はありません。外側のループに強制力が備わり、その仕組みが文書化されただけです。

‍