【YC W26】AIエージェント版Vercel？ファイル操作に特化したデプロイ基盤「Terminal Use」が登場

Hacker Newsの皆さん、こんにちは！Terminal Use（https://www.terminaluse.com/ ）のFilip、Stavros、Vivekです。私たちは、サンドボックス環境で動作し、ファイルシステムを駆使してタスクを実行するAIエージェントを簡単にデプロイできるプラットフォーム「Terminal Use」を開発しました。コーディングエージェント、リサーチエージェント、文書処理、あるいはファイルの読み書きを行う社内ツールなどの開発に最適です。

デモ動画はこちら：https://www.youtube.com/watch?v=ttMl96l9xPA

エージェントのホスティングにおける最大の苦労は、エージェントのパッケージ化、サンドボックスでの実行、ユーザーへのメッセージのストリーミング、ターンをまたいだステート（状態）の保持、そしてワークスペースへのファイル転送といった、バラバラの要素をパッチワークのように繋ぎ合わせる必要があることでした。

私たちが求めていたのは、ReplicateのCogのエージェント版のようなものです。リポジトリからエージェントのコードをパッケージ化し、クリーンなAPI/SDKの背後で提供するシンプルな方法です。エージェントのロジックやフレームワークを制限することなく、通信プロトコルだけを提供したいと考えました。

Terminal Useでは、リポジトリ内の config.yaml と Dockerfile でエージェントをパッケージ化し、CLIでデプロイします。開発者は、タスク（会話）のライフサイクルを追跡する3つのエンドポイント（on_create, on_event, on_cancel）のロジックを定義するだけです。config.yaml にはリソース設定やビルドコンテキストなどの詳細を記述します。

標準で Claude Agent SDK や Codex SDK のエージェントをサポートしており、SDKのメッセージタイプを独自の形式に変換するアダプターを提供しています。自作のフレームワークを使いたい場合は、Vercel AI SDK v6互換の型でメッセージを送信できます。フロントエンド向けには Vercel AI SDK プロバイダーを用意しているため、ストリーミングや履歴の永続化を自分で行う必要はありません。

私たちが「他とは決定的に違う」と考えているのは、ストレージの扱いです。

Terminal Useでは、ファイルシステムをタスクのライフサイクルから切り離し、「第一級のプリミティブ」として扱います。つまり、ワークスペースを複数のターンで維持したり、異なるエージェント間で共有したり、サンドボックスの起動状態に関係なくファイルをアップロード・ダウンロードしたりできるのです。さらに、ファイルシステムSDKは「署名付きURL」を発行できるため、ユーザーがバックエンドをプロキシすることなく直接ファイルをやり取りでき、転送処理が非常にシンプルになります。

エージェントのロジックとファイルストレージが疎結合であるため、サンドボックス内のファイルを心配することなくエージェントの改善を回せます。バグを修正してデプロイすれば、実行中の全タスクを新環境に自動移行できますし、破壊的変更がある場合は、既存タスクは旧バージョンのまま維持し、新規タスクから新バージョンを適用するといった制御も可能です。

現在は、マウントパスや読み書きモードを細かく設定できる「マルチファイルシステムマウント」もサポート予定です。これにより、ストレージの耐久性と再利用性を保ちつつ、タスクごとに最適なマウント構成を実現できます。

デプロイ面では、モダンな開発プラットフォームを参考にしました。シンプルなCLIデプロイ、プレビュー/本番環境、Gitベースの環境指定、ログ、ロールバックなどを備えています。ビルドやリソース管理に必要な設定はすべて config.yaml に集約されているため、CI/CDパイプラインへの組み込みも容易です。

最後に、私たちはこのプラットフォームを自分たちのコーディングエージェント開発に活用し、テストと改善を繰り返してきました。CLIを使えば、デプロイ済みのエージェントにメッセージを送り、ファイルシステムの内容をダウンロードして出力を確認できます。よくやるテスト手法は、検証したいシナリオをMarkdownに書き、Claude Codeに「ユーザー役」を演じさせて、デプロイした自分たちのエージェントと対話させる方法です。

まだ不足している点もあります。汎用的なサンドボックスプロバイダーと比較すると、プレビューURL機能や低レイヤーの sandbox.exec(...) 形式のAPIは現在ロードマップにある段階です。

皆さんのご意見や質問、懸念点など、ぜひコメントで聞かせてください！

既存のNFSツール（archilやdaytona volumesなど）で役に立ったものはある？それとも自前で用意するしかなかった？チェックポインティングやリトライに関しても同じ疑問があるんだ。今のツール市場はすごく流動的というか、定まっていない感じがするね。

We built Terminal Use to make it easier to deploy agents that work in a sandboxed environment and need filesystems to do work.

これを読んでFly.ioのsprites.devを思い浮かべたんだけど、考え方は合ってるかな？それとも、これは全く別の領域のプロダクトと捉えるべき？もし後者なら、初心者にもわかるように教えてくれる？

すごく興味深い、ローンチおめでとう。今解決しようとしているユースケースは、開発環境を確実にセットアップできるコーディングエージェントプラットフォームの構築なんだ。いくつか質問がある！

自分の場合、Docker-in-DockerでSupabase環境を立ち上げ、NextJSアプリを実行して、CIを監視しながら反復的に動作する「一発勝負型（one-shot）」のコーディングエージェントプラットフォームを作ろうとしているんだ。

1. これをChatGPT ProやClaude Maxのサブスクリプションと一緒に使える？

K8s対エージェントインフラという議論は興味深いね。K8sはプロセスやネットワークの隔離は提供してくれるけど、欠けているのは「タスクごとの認可スコープ」だよ。

エージェントコンテナはデプロイ時に認証情報が定義されるけど、その範囲はタスク1（リポジトリの読み取り）とタスク2（ユーザーアップロードの処理）の間で変わらない。もしタスク1でプロンプトインジェクションを受けたら、同じ権限を持ったままタスク2へ引き継がれてしまう。

足りないのはインフラじゃなくてポリシーだね。アクセス可能なデータに対して、タスク単位で何を許可するか？書き込みはできるのか、読み取りだけか？外部URLへのエクスフィル（データ流出）は許可するか、それとも/outputへの書き出し限定か？そして重要なのは、後からインシデント調査ができるように、実際の行動が追記型で記録されているかという点だ。

K8sはコンテナの境界は管理できるけど、その上の認可レイヤー（タスクごとの許可、行動の可視化、タスク途中での権限取り消し）は既存のインフラ抽象化では解決されていない。このギャップはK8s、Modal、あるいは今回のプロダクトを使おうが現実として存在する。

https://shellbox.dev とはどう違うの？（他のexe.dev、sprites.dev、blaxel.aiなども含めて）

ファイルシステムを第一級プリミティブとして扱うという抽象化は正しいね。自分はスケジュール実行型（cronベース）の永続ワークスペース付きエージェントを動かしているけど、誰も語らないのは「生のファイル永続化だけでは不十分」ということだ。セマンティックな（意味論的な）永続化が必要なんだよ。

構造の継続性（呼び出し間でファイルが存在し続けること）は簡単だけど、セマンティックな継続性（それらのファイルの中で何が重要かを知っていること）は難しい。自分はただ保存した内容ではなく、学んだ内容を要約した構造化されたMEMORY.mdを保持している。生のログはすぐに溜まってノイズになるからね。エージェントのためにファイルシステムの状態をインデックス化・要約するレイヤーがないと、ファイルはそこにあるのに記憶喪失になるエージェントが出来上がってしまう。

面白い設計上の問いは、このセマンティックな継続性がツール側の問題（エージェントが自らファイルをクエリできるツールを渡す）なのか、プロンプトの問題（起動時に要約を注入する）なのか、それとも新しいプリミティブ（ファイルシステムの上に置くクエリ可能な状態レイヤー）なのか、という点だ。今の抽象化はこれをユーザーに委ねているけど、現時点ではそれが正解だと思う。ただ、多くのチームがそこで苦労することになるだろうね。

ドキュメントとAPIから推測するに、このファイルシステムの抽象化はオブジェクトストレージをバックエンドにしたCopy-on-Mountだろうね。

おそらくこう動いているはず：タスク開始時にS3/R2/GCSからローカルディレクトリにファイル内容を同期して、それをコンテナにバインドマウントする。エージェントは通常通り読み書きするから、FUSEもファイル操作ごとのネットワーク往復も発生しない。タスク完了時か明示的な同期時に、変更分をオブジェクトストレージにフラッシュバックする。アップロード/ダウンロードの事前署名付きURLをサポートしている点が、オブジェクトストレージが信頼できるデータ源（source of truth）であることを物語っているよ。

エージェントのワークロードに対しては、FUSEよりもはるかに理にかなっている。エージェントは数千もの細かい読み取り（find、grep、git status）を行うけど、FUSEだとそのたびにネットワーク呼び出しが発生してしまうからね。Copy-on-Mountなら、初回同期以降はすべてローカルディスク速度で動く。

タスク間での共有も自然に実現できる。同じファイルシステムIDをマウントするタスクが2つあれば、それは同じS3プレフィックスから同期するコンテナが2つあるというだけのことだ。分散ロックではなく「最後の書き込みが優先される（Last-write-wins）」方式だろうけど、エージェントが同じファイルを同時に書き換えることは稀だから、それで十分だね。

ローンチおめでとう！エージェントのCLIやSDKはローカル利用向けに作られていたから、それらをプロダクションで動かすためのインフラには多大な労力が必要だった。この分野が成熟していくのが純粋に楽しみだよ。

自分もOSSのセルフホスト可能なエージェント用インフラスイートを https://ash-cloud.ai で構築しているところなんだ。

いつか情報交換できたら嬉しいな！

なるほど…これはComputer UseやBrowser Useとはカテゴリが違うんだね。アイデアは大好きだよ。適切に定義・制御されたサンドボックスは本当に便利だ。

話はそれるけど、3ヶ月前にComputer UseとBrowser Useを試した時は正直がっかりしたよ。基本的なタスクの多くが完了できなかったからね。特にBrowser Useは、少しでも普通じゃないウェブサイトだとすぐ失敗する。divで実装されたセレクトボックスは見つけられないし、送信ボタンが無効化されていると無限ループに陥る。挙げ句の果てには、READMEのデモさえ完了できなかったんだ！オープンソースがバグだらけなのはいいとしても、VCから出資を受けていて、豪華なランディングページを作り、大企業にサービスを提供して有料プランまで出している会社なら、最低限デモくらいは動くようにしておくべきだと思う。

構築している中で、自身の作成したエージェントSDKを使うだけでなく、実際にClaude CodeやCodexハーネスを動かしたいという考えや感覚は持たなかったの？