あなたの agent は MCP を話す。ならコンピュータを渡そう

画像提供：Annie Ruygt

Sprite は使い捨てのクラウドコンピュータだ。一瞬で起動し、常に永続ファイルシステムを備え、アイドル時にはほとんどコストがかからない。インターネット上で agent を動かすのに最適で最も安全な場所であり、何十台も作ってほしいと思っている。

Sprite は agent を動かす場所だ。新しい Sprite を手に入れたら、まず claude と入力することを考えるべきだ（あるいは gemini、または codex）。coding agent が Sprite 上で安全に、気持ちよく動けるよう、多大な労力を費やしてきた。ジョン・フォン・ノイマンの言葉（おそらく）を借りれば、「満足した agent は生産性が高い」。

あまり知られていないが、Sprite は agent にとって優れたツールでもある。ある機能の3種類のバリエーションが欲しい？テスト環境が欲しい？連携して動くサービスの一群が欲しい？プロンプトをこう書き始められるのは非常に便利だ：「On a new Sprite, do…」。

Sprite API はシンプルで見つけやすく、まさにこうした用途のために設計されている。唯一の本当の問題は、agent がどうやってそれにアクセスするかだ。ほとんどの人にとって答えは MCP であり、設定はすでに書かれている。

どちらかを選ぶ必要はない

MCP は agent を拡張する間違った方法であり、コマンドラインツールと発見可能な API こそが正道だ——そんな主張が出回っている。これは半分正しく、そして正しい半分のほうが重要なので、真剣に受け止めている。

30個のツール説明をコンテキストウィンドウに詰め込むのは、何かを教える良い方法ではない。すべての Sprite コマンドが毎回のセッションで重要なわけではなく、全部を詰め込めば、モデルにそれらすべてが自分にとって重要だと伝えていることになる。ネットワークポリシーを使わないなら、gemini が設定方法を学ぶためにトークンを1つも消費すべきではない。能力は、agent が CLI のサブコマンドを1つずつ探っていくように、徐々に現れるべきだ。

間違っている半分は、これを MCP に反対する理由にすることだ。漸進的な開示は、モデルに何を伝えるかの話だ。MCP は、バイトがどうやってそこに届くかの話だ：トランスポート、認証、構造化された結果、フラグを推測しなければならないコマンドではなくモデルが呼び出せるツール。これは別のレイヤーの話であり、両方を同時に持つことに何の障害もない。我々のプラグインはまさにその両方を兼ね備えている。

Claude Code プラグインをインストールすると、下層はマネージド MCP server、上層は skills になる。コンテキストに入るのは、新しいコンピュータがいつ欲しくなるかを説明する一文程度だ。残りは必要になったときに現れる。Codex、Cursor、Antigravity、opencode、Grok なども同じ使い方だ。あなたのツールがこのリストになければ、裸のエンドポイントを指定すればそのまま動く。

server も自分の担当領域で強化されている。ファイル読み取りは、貼り付けられた大量のテキストではなく MCP resource を返すので、agent はファイル全体を飲み込まずに特定のファイルを指し示せる。各 tool には安全アノテーションが付いている：読み取り専用操作は読み取り専用と、破壊的操作は破壊的と、exec と service_start は Sprite の境界を越える唯一の2つの操作としてマークされる。これらのアノテーションを気にするクライアントなら、「自分の checkpoints を一覧表示する」と「これを実行する」を区別して扱える。

shell も常に存在する。sprite CLI があり、普通の REST API があり、各 Sprite は /.sprite/llm.txt で機械可読なドキュメントを提供し、中で働く agent にこの場所がどう動くかを教える。agent が tool を呼ぶよりも小さなスクリプトを書くほうを好むなら、そうさせればいい。土台は同じ API だ。

sprites.dev/mcp

この URL を Claude Desktop、あるいは MCP を話せる他の agent ツールに入力する。自分の Fly.io organization のいずれかに認証され、agent が Sprites を話せるようになる。

そして：

On a new Sprite, take this repository and reproduce this bug from issues/913, capturing logs.

On a new Sprite, benchmark this function across 1000 runs and summarize the results.

On a new Sprite, update all the dependencies on this project to their newest versions and test that everything works.

On 3 new Sprites, change this service to use each of these 3 query libraries, and use HTTP to test latency.

On a new Sprite, run this code with bpfwatch and show me what files it touches.

On a new Sprite, run a load generator against this endpoint for 60 seconds and report the results.

On a new Sprite, download this dataset and give me a Jupyter notebook to explore it in.

On a new Sprite, set up a webhook receiver and render a real-time web report of all the payloads it receives.

知らない。自分のプロジェクトについては、あなたのほうがよく分かっているはずだ。まあいい。清潔で安く、使い捨てできるマシンが欲しいことだってある（5台でも）。書いた prompt はどれも、これで動かせる。自分のプロジェクトにどう当てはめるか考えてみてほしい。Sprites なしの暮らしに、すぐに戻れなくなると思う。

「そのうち bot に生活を壊される」と思っている人もいるだろう。同感だ。だからガードレールを用意した。認証時に agent へ渡すのは、Fly.io アカウント配下の指定した組織ひとつだけで、そこからさらにセッションの範囲を狭められる。デフォルトの上限は Sprites 5台、名前のプレフィックスは mcp-。bot だとすぐ分かるし、潰すのも簡単だ。どちらも自分で変更できる。

ステートレスサンドボックスはもうたくさんだ

何度でも言う。業界はまだ「サンドボックス」という発想に縛られていて、それで agent にコードを走らせている。サンドボックスはとっくに役目を終えている。Agent が欲しがっているのは本物のコンピュータで、本物のファイルシステムがあり、本物のネットワークにつながっている。技術的にそれを与えない理由など何もない。

Sprites は、一度に大量に作っても安心できるように設計した。チームの Web アプリをホストできるだけの応答速度があり、アイドル時はスリープしてほとんど費用がかからない。Fly.io でこれを使っている人なら、最後には20〜30台を抱えている。

コンピュータを必要なだけ引き寄せて問題を解けるようになれば、もっといいものが作れるようになる。あなたの agent はもう1台欲しがっている。渡してやろう。