サーバーレスエージェント

エージェントを構築することは簡単ではありません。

一年前、私たちはコンテキストとメモリを自分で管理し、RAGとベクターデータベースについて考え、ツール使用精度を非常に慎重に調整する必要がありました。Claude Code / Claude Agent SDKの登場がこのすべてを変えました。今、ますます多くのチームがClaude Agent SDK + VMを使用して直接エージェントを構築し始めています。問題はシンプルになったでしょうか？いいえ。

VMでClaude Codeを実行することはまだ非常に挑戦的なことです。

1. すべてのユーザーセッションには独立したVMが必要です。一部のシナリオでは、VMの永続化能力が有用ですが、VMのアップグレードと調整も難しくなります。例えば、ユーザーの観点から見ると、VMにインストールされたソフトウェアが数ヶ月後もまだ利用可能であることを望んでいます。しかし、オーケストレーション層と通信するVM上の部分もアップグレードをロールアウトできる必要があります。

2. 大規模なVMの作成と調整。単一のk8sクラスターは約数千のポッドの調整をサポートします。これはアプリケーションサービスクラスターには十分です。しかし、すべてのセッションがclaude codeポッドを起動する必要があるシナリオには十分ではありません。

3. k8sソリューションを使用するとk8sによる遅延が生じ、1秒以内のパフォーマンスを達成することが困難です。

4. e2bソリューションを使用するには、自分で永続化を行う必要があり、ファイルのアップロード/ダウンロードは非常に遅いです。

5. e2bソリューションは特定のネットワーク環境要件を満たすことができず、プライベート展開が面倒です。

これらの問題をどのように解決しますか？歴史から学びましょう。十年以上前の2012年当時、世界にはサーバーレスもk8sもdockerもありませんでした。バックエンドエンジニアは物理マシン上でサービスプロセスを手動でメンテナンスしてサービスを実行する必要がありました。当時、sshとansibleはサーバーエンジニアにとって標準ツールでした。サービスプロセスは物理マシン上のさまざまなツール環境に大きく依存していました。物理マシン間で一貫したツール環境設定を達成することは非常に困難であり、大規模なスケーリングはチームが事前に準備する必要のある主要な取り組みでした。あるエンジニアが一台のマシンの環境を変更して他のマシンの環境への同期を忘れ、本番環境で非常に追跡困難なゴーストバグを引き起こしたときのことをまだ覚えています。あの時代は非常に痛みを伴う過去の時代でした。

2012年、Dockerが登場しました。Dockerはすべてのツール環境を一つの単一イメージにパッケージ化し、環境の不整合問題を解決しました。コミュニティは徐々に、物理マシン上の仮想マシンで実行されているサービスプロセスが物理マシン上のプロセスのように管理できることに気づきました。しかし、Dockerオーケストレーションには依然としてエンジニアリングチームがオーケストレーションシステムを構築する必要がありました。そして、Docker内のサービスプロセスが物理マシンのネットワークとファイルシステムに結合されると、オーケストレーションは非常に困難なことになりました。

2014年、ステートレスサービスがメインストリームトレンドになり始めました。その年、KubernetesとAWS Lambdaが誕生しました。それぞれが異なる角度からステートレスサービスの未来を描きました。ステートレスサービスとは、サービスロジックがネットワークアドレスとの結合を避け、永続的なファイルシステムにローカルで依存しなくなることを意味しました。

そして10年間のクラウドネイティブが来ました。ステートレスサービスの波は大量のクラウドネイティブインフラを生み出しました。例えば：

• サービスゲートウェイ Istio/Linkerd/Envoy/Traefik
• CI/CDプラットフォーム Argo CD / Flux
• オブザーバビリティプラットフォーム Prometheus/Grafana/ELK Stack
• コールチェーン分析 Jaeger/Zipkin/OpenTelemetry
• ストレージ Rook/MinIO/JuiceFS

そして私たちは今、新しい始まりにいます。十年前、計算単位はjava/python APIサービスプロセスでした。今年から、この計算単位はコーディングエージェントになりました。

ACFSは物理マシン上でサービスプロセスを手動でメンテナンスしていた時代のようなものです。E2BはDockerのようなものです。タスクオーケストレーションプラットフォーム、オブザーバビリティプラットフォーム、分散状態永続化ストレージ機能がなければ、スケーラビリティはコーディングエージェントにとってまだ困難なことです。そして私が期待するServerless Agent Infraはこれらの機能を持っています：

1. コンテキストを失わずにコーディングエージェントのセッションと作業ディレクトリを適切に永続化できる。
2. 超高速で、100ms以内にコーディングエージェントを起動できる。
3. 人間が理解しやすいエージェント動作のためのLogging / Metric / Tracingを持っており、人間がエージェントの動作パターンを理解し調整しやすくする。
4. 開発者は仮想マシン、コンテナ、その他のops詳細などの詳細を気にする必要がなく、大規模なオーケストレーションを非常に簡単にする。

これらの機能を満たすことができるインフラはすでに準備ができていると思います。例えば、Firecrackerはマイクロ VM のパフォーマンスと安定性を検証しており、分散オブザーバビリティプラットフォームとファイルストレージシステムにも多くの選択肢があります。しかし、e2bを使用してClaude Codeをカプセル化した経験のある開発者として、これらすべてを統合することはまだ非常に困難です。例えば、E2BのClaude CodeがOOMによって予期せず中断されると、エンジニアがこれを監視することは困難であり、その時のシーンとログを取得することはさらに困難です。

2026年以降の開発者は、ちょうど2026年のほとんどのエンジニアがもはやsshを使用して物理マシンを手動で初期化する必要がないように、このような苦痛なプロセスを経験する必要がないことを願っています。

これがVM0の夢です。いつかエルゴノミックなAPIを通じてコーディングエージェントを操作できることを願っています。例えば：

const agent = vm0.run({
	framework: 'claude-code',
	prompt: 'buy me a coffee'
})