ほとんどのホスティングは、キーボードの前にいる人間を前提に設計されてきました。登録フォーム、クレジットカード、ダッシュボード、何か問題があったときのメール。計算資源を必要とする AI エージェントは、そのどのステップにも合いません。CAPTCHA は解けず、メンテナンスページと壊れたページの区別もつかず、同じサーバーを 40 回作ってしまっても気づきません。
「とりあえず API を渡せばいい」と言いたくなります。しかしそれは最初の要件であって、最後ではありません。以下は、エージェント向けに自前の MCP サーバーと REST API を作ってきた経験から、私たちが重要だと考える 7 つの要件です。それぞれについて、それがないと何がうまくいかないかを挙げます。
1. エージェントに必要なことはすべてプログラムで操作できる
リソースの作成、確認、サイズ変更、削除は、ブラウザーなしで動かなければなりません。地味な部分も含みます。購入前に価格を調べる、あるロケーションに空き容量があるか確かめる、新しいマシンのパスワードを読み取る、解約する。
これがないと： エージェントは道のりの 80% まで進み、クリックが必要な 1 ステップで止まり、結局人間が仕事を仕上げることになります。中途半端な API は、完了できない自動化を誘うので、ないよりも悪いことがよくあります。
2. プログラムが判断に使えるエラー
エージェントはレスポンスを読み、次に何をするかを決めます。安定したコードを持つ JSON ボディ（402 insufficient_balance、409 sandbox_paused、リセット時刻付きの 429 budget_exceeded）なら、それに基づいて分岐できます。HTML のエラーページや曖昧なメッセージの 500 では推測するしかなく、決して成功しない処理を繰り返すことがよくあります。
これがないと： 再試行のループです。エージェントの失敗で最も高くつくのは、たいてい誤った判断ではなく、同じ失敗した呼び出しを何千回も繰り返すことです。
3. 人間を介さない支払い
カード決済には、人間がその場にいることを確かめるためのステップがあふれています。3-D Secure のコード、銀行アプリでの承認、本人確認。不正防止には役立ちますが、ソフトウェアには突破できません。事前にチャージしておく前払い残高（私たちの場合はステーブルコインでのチャージが多い）なら、人間が 1 件ずつ承認しなくても、エージェントは使った分を支払えます。
これがないと： 人間がすべての購入を承認する（それでは意味がない）か、誰かがエージェントにカードを渡す（誰も取るべきでないリスク）かのどちらかになります。
4. 支出の厳格な上限
前払い残高は最悪の場合の損失を残高の範囲に抑えます。それでも大きな額になりえます。エージェント自身の善意ではなくプラットフォームが強制する、ドル建ての 1 日と 1 か月の上限があれば、ループに陥ったエージェントは小さな損失で済みます。上限ははっきりと失敗し、エージェントが認識できるエラーを返して、動いているものを停止または一時停止すべきです。
これがないと： ループに気づくのは残高を見たときです。私たちのサンドボックスの課金に上限があるのはこのためで、MCP のガードレールのページでは、そもそもどの操作に人間の承認を必要とすべきかを提案しています。
5. 適切な粒度の計算資源
エージェントが生み出す作業には、まったく異なる 3 種類があります。
- 秒： 生成したコード断片の実行、答えの確認、修正の試行。
- 時間： 評価、スクレイピング、長いビルド。
- 常時稼働： ボット、API、定期実行のワーカー。
月額サーバーしか提供しないプラットフォームでは 1 つ目がばかげたほど高くつき、短命なサンドボックスしか提供しないプラットフォームでは 3 つ目が不安定になります。時間課金のマシンで 20 秒のタスクを動かせば、59 分間の「何もしない時間」に支払うことになります。秒単位課金の仕組みでは、それぞれのモデルがどこで意味を失うかを示しています。
これがないと： エージェントは短い作業に払いすぎるか、動かし続けることを想定していないインフラで長時間稼働のサービスを動かすことになります。
6. デフォルトでの隔離
エージェントが書くコードは、誰もレビューしていないコードです。価値のあるものが何もない場所で動かすべきです。エージェント自身のホストでも、あなたのキーがあるサーバーでも、メールを送るマシンでもない場所です。実際には、タスクごとに別の VM か microVM を用意し、終わったら削除するということです。選択肢の比較は信頼できないコードのための隔離レベルで、独自のカーネルがなぜ重要かは Firecracker microVM をやさしく解説 で説明しています。
これがないと： 生成されたコードに紛れ込んだ最初のプロンプトインジェクションが、エージェントのホストから届くすべてにアクセスできてしまいます。
7. 可視性と停止スイッチ
エージェントに責任を持つ人間は、エージェントが何をしたかを把握し、すぐに止められなければなりません。つまり、リソースごとの使用量と費用、エージェントが作ったものすべての一覧、そしてそれらをまとめて削除する手段が必要です。認証情報は失効でき、漏れたものが永遠に有効にならない程度に短命であるべきで、人間を介さずに更新する方法も必要です。
これがないと： 後片付けが考古学になります。忘れられたリソースは課金され続け、漏れたトークンは使え続けます。
エージェントに不要なもの
役に立たないものも同じくらい示唆的です。アップセルのために設計されたダッシュボード、オンボーディングメール、本当の制限が脚注に書かれたプラン、登録後にしか表示されない価格。どれもソフトウェアには読めず、テキストを文字どおりに受け取るモデルにとっては、積極的に誤解を招くものさえあります。
まだ解決されていないこと
ここに挙げたすべてが、工学的に解決済みの問題というわけではありません。
- 責任。 エージェントがアカウントで行うことには誰かが責任を負います。プラットフォームには、その人にすべてのステップを踏ませることなく、自動化された活動を責任者に結びつける方法が必要です。
- 不正利用。 開かれた、完全に自動化された登録は、不正利用者が望むものでもあります。エージェントにサービスを提供するプラットフォームはどこも、摩擦のないアクセスと、アカウントの量産やマイニングとの間でバランスを取っており、完璧な答えを持つところはありません。
- 長い処理。 エージェントは今でも、単発の呼び出しより 10 ステップの処理の方が失敗しやすい状況です。インフラは、各ステップを冪等にし、その状態を照会しやすくすることで助けになれます。そうすれば再試行は重複ではなく続きになります。
私たちがたどり着いたところ
私たちは、これらの要件を避けて通るのではなく、それに合わせて作ろうとしてきました。ライフサイクル全体をカバーする MCP サーバーと REST API、機械が読めるエラー、前払い残高、支出上限、短い作業のための秒単位のコードサンドボックス、そして長い作業のための AI agent プランのような月額サーバーです。サンドボックス側の流れは AI エージェント向けサンドボックスで紹介しています。このリストは、それ自体の価値で判断していただければと思います。エージェントを自由に動かすことになるどんなプラットフォームにも使える、便利なチェックリストです。
コメント
まだコメントはありません。最初になりましょう。