OpenComputeのご紹介
Walker Hildebrand、Sherry Bai 著 - 2026年10月14日 - 読了時間 7分
製品
シェア
エージェントがあなたの眠っている間に仕事をする世界で、どうすればそれらをあなたのインフラ上で実行できるようにするのでしょうか?
エージェントがチャットウィンドウの中に存在する場合、答えはシンプルです。セッション用にセットアップしたマシン上で実行されます。しかし、エージェントがアラートを調査し、非同期のリクエストに対応し、予定されたAutomationsを実行し、日中を通して問題を処理するとなると、問題はオンデマンドのコンピュートになります。もはや必要なのは、エージェントを実行する場所だけではありません。仕事の量に追いつけるコンピュートフリートが必要なのです。
本日、私たちはOpenComputeを発表します。OpenComputeは、Factoryのセルフホスト型オーケストレーターで、お好みのランタイム上でエージェントサンドボックスを実行できるもので、現在プライベートプレビュー中です。
OpenCompute カスタマー管理のインフラストラクチャにオンデマンドのプロビジョニングとライフサイクル管理をもたらし、Factory体験と統合されています。 環境, オートメーション、および リモコン。エージェントは必要なときにコンピュータを手に入れます。そのコンピュータをどこで実行するかはあなたが選択します。
その根底には一つの信念があります:自律型ソフトウェア開発を採用するにあたり、自分のインフラの鍵を他人に渡す必要があるべきではない、ということです。
では、どうやって6週間で、2日でカスタムのオンプレミス環境にデプロイできるものを構築したのでしょうか?
リモートコントロールを基盤として
2026年4月、私たちはDroid Computersを発表しました。これはDroidをオーケストレーションするための永続的なマシンです。お客様はFactoryのクラウド上にコンピューターを作成するか、Remote Controlを通じて自身のマシンを登録することができました。
リモートコントロール体験により、Factory との統合はコンピュートレイヤーに依存しなくなります。任意のマシンで Droid を実行し、Factory に接続して、リモートで操作できます。そのマシンは、ワークステーション、クラウド VM、またはプライベートネットワーク内のサーバーでもかまいません。エージェントの実行ループはそのマシン上で動作するため、Droid はプライベートリポジトリ、パッケージレジストリ、内部環境のサービスと連携できます。顧客は、それらのシステムをエージェントに利用可能にするために、公開する必要はありません。BYOK とセルフホスト推論への対応により、データ主権に関する制御がさらに強化されています。
Remote Controlはそのモデルの価値を証明し、業界全体も同じ方向へと進んできました。しかし、私たちは別の明確なギャップに気付き始めました。エンタープライズのお客様が必要としていたのは、1台ずつではなく、コンピュータのフリートを管理するためのソリューションでした。
マシンはフリートではない
Remote Controlは、特定のユーザーやサービスにスコープされた常設マシンに適しています。設定済みのワークステーション、開発用VM、あるいは特殊なハードウェアを備えたマシンなどです。これは「どうすればエージェントを最も必要な場所に届けられるか」という問いに答えるものです。
しかし、組織全体の要求に応えるコンピュートが必要でした。インタラクティブなセッションを支援しつつ、仕事が発生した際にエージェントが自律的に動作できるようにする必要があったのです。
アラートが、誰かが先にVMをプロビジョニングしなくても調査をトリガーできるべきです。Slackでの委任が集中しても、チームが利用可能なマシン数を数えるようなことがあってはなりません。完了したタスクのせいで、アイドル状態のリソースが無期限に動き続けることも避けるべきです。
私たちのマネージド提供は、すでにそのライフサイクルの一部を処理していました。セルフホストのマシンには、同等のネイティブなプロビジョニング、サスペンド、再開の統合がありませんでした。顧客は好きな場所でDroidを実行できましたが、フリートの運用は自ら行う必要がありました。
どこにでもサンドボックスを
顧客のクラウドインフラには大きなばらつきがあることがわかりました。既存のKubernetesクラスタ上でエージェントを実行したい顧客もいれば、特殊なハードウェア上を望む顧客、開発者がすでに依存している内部プラットフォーム上を望む顧客もいました。新しいmicroVMインフラの導入を進めている顧客や、ソリューションを探している顧客もいました。
私たちの使命は、単に顧客にサンドボックスのフリートを提供することではありませんでした。どんなインフラ上でもフリート管理が機能するようにしなければなりませんでした。すべての顧客を私たちの環境に引き込むのではなく、オーケストレーションを顧客の環境に届ける必要があったのです。
エージェント向けサンドボックス環境の開発は活発に行われており、取り組みには事欠きません。サードパーティのクラウドサンドボックスプラットフォームには、E2B、Daytona、Modal があります。Kubernetes Agent Sandbox、Google の Agent Substrate、AWS Lambda MicroVMs などのプロジェクトも、bring-your-own-cloud や bring-your-own-infrastructure ソリューションへの需要の高まりを示しています。
各プラットフォームは、分離性、永続性、起動速度、運用の簡易さ、デプロイの柔軟性といった点で異なるトレードオフを採っています。短期のタスクに適したバックエンドは、永続的な開発環境には適さないかもしれません。スタートアップにはうまく機能するサービスが、規制の厳しい企業のネットワーク内では利用できないこともあります。そして、6か月後の最良の選択肢は、今日の最良の選択肢とは異なるかもしれません。
私たちは、コンピュートインフラストラクチャの上位にレイヤーを構築することにしました。OpenCompute は共通のライフサイクル、すなわちコンピュータの要求、望ましい状態への移行、アクティビティの追跡、そしてポリシーとプロバイダーの機能に応じたサスペンドや終了を担います。インフラストラクチャの仕組み、つまりそれらの操作を可能にする部分はプロバイダーが担います。これにより、製品の基盤を置き換えて顧客を待たせることなく、エコシステム全体の進歩の恩恵を受けることができます。
インターフェースに仕事をさせる
OpenComputeの開発は、最初からエージェントネイティブに行われました。その始まりは、コンセプトを実証するための Mission でした。私たちの仕事は、境界を定め、動作を仕様化し、正しさをテスト可能にすることでした。Droidsが残りの作業を、人間の指示のもとで担当しました。
そのため、インターフェース設計がとりわけ重要になりました。「このプロバイダーのサポートを構築せよ」は際限のない課題です。「このコントラクトを実装し、これらの適合テストを満たせ」であれば、エージェントに限定された問題と検証可能な成功の定義を与えることができます。
OpenComputeを顧客にとって柔軟にしたのと同じ分離が、構築を容易にしました。新しいドライバー、すなわちプロバイダーごとの統合は、フリート管理を書き直すことなく自身のプロバイダーに集中できました。共有コントロールプレーンは、別のクラウドAPIを学ぶことなく改善できました。
このアプローチにより、AWS Lambda MicroVMs、Kubernetes、EC2、Agent Sandbox、Agent Substrate、およびその他の実験的プロバイダーにわたって統合を開発・評価できました。これらは同一の実装でも、同程度に成熟したバックエンドでもありませんでした。それこそが要点でした。アーキテクチャは、それぞれを別個の製品に変えることなく差異を吸収できたのです。
初回デプロイまでの6週間
最も明確な試練は、最初の顧客デプロイでもたらされました。その顧客は、社内製のプロバイダーインターフェースを持つ独自のオンプレミス環境にOpenComputeを組み込む必要がありました。顧客との面会に向かう飛行機に搭乗する直前に、私たちは手元にある情報をもとに、その環境向けの初期ドライバーを構築するMissionを開始しました。
着陸した頃には、ドライバーは構築済みでした。現地での2日間を経て、顧客はOpenComputeを通じて最初のサンドボックスをプロビジョニングしました。ユーザーの視点では、マネージドなDroid Computerを作成しているように見えましたが、そのサンドボックスは顧客のデータセンター内で動いていました。その顧客のために新しいアーキテクチャを考案する必要はありませんでした。必要だったのは、すでに定義済みのインターフェースへ顧客のインフラを接続することでした。
初期プロトタイプから最初の顧客デプロイまで:6週間。
その最初の統合がエンジニアリング作業の終わりではありませんでした。永続化、リカバリー、デプロイツール、運用の堅牢化は、その後も継続しました。しかし、中心的な賭けは検証されました。新しいプロバイダーの統合は、プラットフォームの書き直しではなく、ドライバーの問題であり得るということです。
アーキテクチャ概要
OpenComputeは、Factoryバックエンドと顧客の基盤となるコンピュートプレーンを接続するセルフホスト型サービスです。
外部へ接続し、内部で実行
OpenComputeはお客様の環境内で動作し、FactoryへのアウトバウンドのTLS保護されたWebSocket接続を確立します。Factoryはその接続を通じて認可されたコンピュートリクエストを送信します。Factoryのために公開OpenComputeエンドポイントを公開したり、インバウンドのファイアウォールポートを開放したりする必要はありません。
登録時に、お客様のOpenComputeデプロイはFactoryに公開鍵を登録します。接続時に、新しいチャレンジに署名することで対応する秘密鍵を保有していることを証明します。秘密鍵はお客様の管理下に置かれ、サポートされたクラウドKMSに保管することができます。
OpenComputeによってプロビジョニングされる各サンドボックスは、今日リモート制御されるコンピュータとまったく同じように、Factoryへの独自のアウトバウンド接続を確立します。内部リポジトリやサービスはプライベートのままにできます。Droidはお客様のネットワークの内側からそれらに到達します。
データ配置に関する注記: コンピュートの配置は、推論ルーティングやセッションストレージとは別物です。セッションデータを完全にローカルに保つかどうかは、お客様の推論および同期の設定次第です。
意図を記録し、その後リコンサイルする
プロビジョニングは単一の信頼性の高いAPI呼び出しではありません。特に未知のプロバイダーを扱う場合はそうです。接続は消滅します。プロバイダーはスロットリングします。リクエストが成功した後、レスポンスが到着する前にプロセスが再起動することがあります。OpenComputeはこれを宣言的なライフサイクルモデルで対処します。そのGo製コントロールプレーンは、お客様の環境内で動作するPostgresデータベースに、希望するコンピュータの状態と観測された状態を記録します。リコンサイラーが継続的に動作し、コンピュータを要求された状態に引き寄せます。
コンピュータの作成は、プロバイダーが完了するまでリクエストを開いたまま保持するのではなく、永続的な意図を記録します。リコンサイラーはプロビジョニングと観測を処理し、回復可能な失敗をリトライし、サポートされたライフサイクル遷移を推進します。意図が永続的であるため、コントロールプレーンの再起動でも未完了の作業は消えません。
コンピュータはイミュータブルなBuildsから起動され、環境の準備とマシンの作成が分離されています。S3互換ストレージがビルドアーティファクトとスナップショットペイロードを保持します。アクティビティシグナルとコンピュータごとのライフサイクル設定が、コントロールプレーンにコンピュータを実行し続けるタイミングとライフサイクルアクションを実行するタイミングを伝えます。
インフラではなく動作を標準化する
各プロバイダー統合は、スタンドアロンのgRPCドライバーとして動作します。ドライバーは、コンピュータの作成、観測、コマンド実行、破棄に関する共通操作を、バックエンドのネイティブなメカニズムに変換します。
プロバイダー固有の動作は、コントロールプレーンのデータベースやリコンシリエーションロジックからは排除されます。ドライバーは、単一の必須ゲストエージェントを採用するのではなく、自身のバックエンドに適したトランスポートとランタイムを使用できます。
しかし、共通インターフェースは、差異について正直である場合にのみ有用です。すべてのバックエンドがコンピュータのサスペンド、ディスクのスナップショット、フォークを行えるわけではありません。そこでOpenComputeは、必須のCore適合プロファイルと、オプションのSuspend、Snapshot、Forkプロファイルを定義しています。ブラックボックステストが、ドライバーがサポートを主張する動作を検証します。サポートされていないリクエストは、永続的な状態を変更する前に拒否され、プロビジョニングの途中でエラーとして表面化することはありません。
このコントラクトはベンダー中立でもあります。FactoryはOpenComputeの考えられる一つのクライアントであり、ドライバーはFactory固有の機能に依存しません。OpenComputeは独自のAPI、CLI、管理パネルを公開しています。お客様のコンピュートを管理するレイヤーは、それを最初に求めた製品に依存せずに有用であるべきだからです。
次に何をするか
OpenCompute をオープンソース化する計画です。その目的は単に実装を公開することではなく、コントラクト、適合性テスト、ドライバーモデルを、エージェントシステムを構築する人々にとって有用なものにすることです。
また、これを Factory の未来の基盤とも位置づけています。インタラクティブセッション、スケジュールされた Automation、インシデント調査、委任された作業は、それぞれが個別のインフラストラクチャの仕組みを必要とすべきではありません。Factory が運用する場合でも顧客が運用する場合でも、同じライフサイクル層を通じて必要な環境をリクエストできるべきです。
この基盤をより多くの人々の手に届け、次にどのプロバイダーが接続されるのかを見られることを楽しみにしています。
エージェントのワークロードの未来は、1 つの企業のクラウドにある 1 種類のマシン上で動くものではありません。OpenCompute は、その未来に向けて構築するための私たちの取り組みです。
OpenCompute は現在プライベートプレビュー中です。OpenCompute の検討にご興味がある場合は、Factory のアカウント担当者までお問い合わせください。