Lambda MicroVMsで実現するServerlessなCodex App Server
三菱UFJフィナンシャル・グループ（以下MUFG）の戦略子会社であるJapan Digital Design（以下JDD）でTechnology & Development Divに所属するSatoshi Toyamaです。
OpenAIは Codex as a platform: build on the open agent harness の中で、Codexの中核にあるオープンソースのAgent Harnessを、Codex App Serverとして、新規・既存のアプリケーションへ組み込む方法を紹介しました。
2500万人が利用しているCodexで使われているAgent Harnessを、自社の業務アプリケーションや開発ツールに組み込むためのプラットフォームとして利用できることは魅力ですが、課題になるのは動かす環境です。
Agent Harnessは、単にLLM APIを呼び出すだけではありません。ファイルシステムを持ち、ネットワークアクセスが可能で、開発サーバーのような長時間動作するプロセスを起動することもあります。 そのため、短命のFunction実行環境では十分とはいえず、専用のコンピュータが必要です。
2025年には、こうした実行環境をAPIから作成できる「Agent Sandbox」というカテゴリが大きな注目を集めました。Daytona、E2B、Vercel Sandbox、Cloudflare Sandboxesなど、AIエージェントに隔離されたLinux環境をオンデマンドで提供するサービスの存在感が急速に高まりました。
一方で、日本企業のシステム、とくに認証、ネットワーク、データ、監査、IAMなどの既存基盤がAWS上にある環境では、Agentの実行基盤もAWS内に置きたいケースが少なくないですね。AWSにはECS、Fargate、EKS、EC2など、コンテナやVMを実行するための選択肢が以前からあります。しかし、それらを使って「CodexのThreadごとに、隔離された実行環境を高速に作る」には、Image管理、起動、認証、接続、Ready状態の検出、状態監視、Suspend、Resume、終了処理までを担う仕組みを、自分たちでかなりの部分まで組み立てる必要がありました。Firecrackerを直接使うのであれば、MicroVMを配置し、起動し、安全に接続し、回収する管理基盤そのものを構築することになります。
そこで登場したのが、Lambda MicroVMsです。Lambda MicroVMsは、複数のユーザーやAIエージェントがコードを実行する用途に向けて設計された、VMレベルの分離を持つServerlessな実行環境です。通常のLambda Functionとは異なり、OSパッケージのインストールやファイルシステムのマウント、長時間動作するプロセスなど、エージェントが必要とする「コンピュータ」としての機能を利用できます。
これは試してみるしかないと思い、Lambda MicroVMsでCodex App Serverを実行し、Cognitoで認証したWeb UIから操作できるデモを作りました。
作ったものをさらに調整してLive Reloadもできます
この記事では、このデモを参照しながら、Codex App ServerをLambda MicroVMs上で動かす仕組みと、AWS上でAgent Sandboxを構築する際のポイントを紹介します。
Threadの作成とTurnの開始
このデモで実装したCodex App ServerでThreadを作成しTurn（Codex App Server処理単位）を開始するまでの流れをシーケンス図で表すと以下のようになります。
ポイントはMicroVM内で、Codex App Serverだけでなく、外部からのRequestを処理するHTTP Serverと、Codex App Serverが出力するEventを処理するEvent Handlerを動かしているところです。詳しくは後述しますが、現時点でLambda MicroVMsには、起動したMicroVMにログインして、コマンドを実行し、そのレスポンスをストリームで受ける機能はないです。そのため、コマンドを受け付けるためのhttp serverと、出力を処理するEvent Handlerを用意しています。
また、Event Handlerでは、Codex App Serverの出力DynamoDBに保存しています。これにより、MicroVMがSuspend、あるいは終了した後でも、DynamoDBに保存されたEventからThreadの内容を表示できます。
Turn実行中のCodex App Serverの出力を取得
Codex App Serverの出力はMicroVM内のEvent HandlerでDynamoDBに保存しているので、出力取得用のLambdaでDynamoDBのデータを取得します。これをTurn終了までWebUIで繰り返します。
SSEやWebSocketにすることでより良い体験にできると思いますが、このデモでは実装をシンプルにするためにポーリングしています。
ざっくりとはこんな感じで、MicroVMを起動し、任意のコマンドを実行し、その結果を取得することができます。
次に、このアーキテクチャの中心にあるLamdba MicroVMsやMicroVMの仕組みについて少し紹介します。
Codex App Serverが起動した状態のSnapshotからMicroVMを起動する
Lambda MicroVMsは、Lambda Functionsにも採用されているFirecrackerを利用しています。Firecrackerは、ハードウェア仮想化によって軽量なMicroVMを起動・管理するVMM（Virtual Machine Monitor）です。
MicroVMの起動には、RuntimeやApplication Code、Background Processを含むMicroVM Imageを指定します。Imageの作成時には、Dockerfile とApplicationをまとめたZIPをS3へUploadし、CreateMicrovmImage APIを実行します。LambdaはBase ImageからMicroVMを起動してApplicationをBuild・実行し、/ready への応答後、その時点のDiskとMemoryをSnapshotとして保存します。流れをシーケンス図にすると次のようになります。
この仕組みを今回のデモに当てはめると、Snapshotを作成する前に、まずCodex App Serverを起動し、その出力を受け取るEvent Handlerを設定します。最後にHTTP Serverを起動して /ready へ応答すると、Lambdaがその時点のDiskとMemoryをSnapshotとして保存します。
このSnapshotからMicroVMを起動すると、起動した時点でCodex App ServerやEvent Handler, HTTP Serverは動いており、すぐにThreadを作成することができます。
まとめ
今回のデモで作ったCodexライクなUIは、Codex App ServerをPlatformとして利用するひとつの形です。同じ仕組みは、AIが画面に現れない処理にも組み込めます。
たとえば、業務Applicationの特定の処理で、必要なときだけCodexなどのCoding Agentを起動し、リポジトリの調査やファイルの編集、Testの実行までを任せることができます。また、エンジニアがローカル環境でSkillやCLI、さまざまなToolをCodexと組み合わせて実現しているWorkflowをひとつのApplicationにし、エンジニアリングのBackgroundがない人でも、すぐに実行できる形で提供することもできます。
Agent専用のコンピュータを必要なときに起動でき、その中で動くCodex App ServerをApplicationから操作できる。この組み合わせを応用することで、さまざまなユースケースでCodex App Serverを使って、より良い体験や成果を生み出せる可能性を感じました。
最後までご覧いただきありがとうございました。
Japan Digital Design株式会社では、一緒に働いてくださる仲間を募集中です。カジュアル面談も実施しておりますので下記リンク先からお気軽にお問合せください。
この記事に関するお問い合わせはこちら
Technology & Development Div
Satoshi Toyama
