注文のその後：AIエージェントがMCPで自分のVPSを運用する方法

エージェントがサーバーを買うデモの多くは、注文が通った瞬間で終わります。それは一番つまらない瞬間です。サーバーは存在し、エージェントは47HZ7YFのようなIDを手にしていて、その後どうなるかは誰も語りません。

その後に来るのは、管理者が考えずにやっていることすべてです。SSHが本当に応答するまで待つ、パスワードを探す、ディスクが埋まりつつあるのに気づく、カーネル更新後に再起動する、月末前に更新する、何かおかしいときにサポートに聞く。エージェントがインフラを持つなら、その部分も担う必要があります。ここでは私たちのMCPサーバーでそれがどう進むかを紹介します。書く前に、各ステップをテスト環境で実行しました。

まだクライアントを接続していない場合は、Claude CodeとCodexまたはClaude DesktopとCursorから始めてください。

最初の1分：「active」は「準備完了」ではない

order_vpsは、注文が残高から支払われた時点で応答します。サーバーはバックグラウンドで作られ、通常は1分ほどです。エージェントの次の呼び出しはget_vps_statusで、何度呼んでも問題ありません。このツールは読み取り専用です。

重要なフィールドは2つです。マシンができるとstatusがactiveになります。accessにはログインに必要なもの、つまりホスト、ポート、そのまま使えるSSHコマンドが入っています。専用IPv4付きプランではポートは22です。NATプランでは個別に転送されたポートで、応答はそれをはっきり示し、外部ポートだけを許可するファイアウォールで締め出されないよう警告まで添えます。

この2つの瞬間の間には、つまずきやすい隙間があります。初回起動ではOSの更新が適用され、数分かかることがあり、その間SSHは接続を拒否することがあります。行儀のよいエージェントは22番ポートを叩き続けるのではなく、access.ssh_readyを待ちます。

注文にSSH鍵がなかった場合は、rootパスワードが待っています。reveal_passwordはそれを一度だけ、しかもVMの起動完了後にだけ渡します。早すぎるとpassword_pendingが返り、一度きりの表示は消費されません。起動中のVMがまだ適用していないパスワードをエージェントが繰り返し取得していたため、この仕組みにしました。とはいえ正直なところ、注文時にssh_keyを渡してこのステップを丸ごと省くのがおすすめです。

2日目：見守る

get_vps_metricsは、CPU、メモリ、ネットワーク、ディスクを直近の1時間、1日、1週間、1か月の時系列で返します。1日1回確認するエージェントなら、小さなサーバーを殺すパターン、つまりOOM killerが犠牲を選ぶまでメモリがじわじわ増える様子に気づけます。外からは原因を直せませんが、あなたに知らせたり、SSHで入って調べたりできます。

power_vpsはstart、stop、rebootができます。テストでの発見を一つ。サーバーがアクティブでない（作成中、または未払いの更新で停止中）と、ツールは先にステータスを確認するよう促す409を返します。200以外をすべて「永遠に再試行」と扱うエージェントは、ここでループします。エラー自体が次の行動を教えてくれます。私たちのエラーメッセージは人と同じくらいエージェント向けに書かれています。

set_hostnameはマシン内で動くゲストエージェントを通じて名前を変えるので、Linuxでは再起動なしで反映されます。qemu-guest-agentを削除するとこのツールは動かなくなり、agent_unavailableを返して何も変更しません。

30日目：お金

エージェントが持つインフラが死ぬのはたいていここです。更新は誰かのカレンダーの予定で、その人は忙しく、サーバーは停止されます。

私たちのところでは、更新はエージェントの記憶に頼りません。各サーバーはプリペイド残高から毎月更新され、期日前にはアカウントのメールにリマインダーが届きます。エージェントは次の引き落とし額より残高を多く保つだけでよく、get_balanceで状況がわかります。

猶予期間はありません。期間の終わりに残高が更新額に足りなければ、サーバーは停止され、専用IPはプールに戻ります。

残高が少なくなると、topup_balanceが暗号資産の支払いリンクを作ります。Base、Ethereum、Polygon上のUSDT、USDC、ETHです。ここがエージェントがあなたを必要とする最初の場所です。請求書は作れますが、ウォレットを渡さない限りトランザクションには署名できません。私たちならウォレットを渡す前によく考えます。実際には数か月分を一度にチャージし、エージェントにそこから使わせるのが一般的です。残高不足で注文や請求書が未払いのまま残った場合は、あなたのチャージ後にエージェントがpay_invoiceを呼べば残高から支払われます。

正直に言うと一つ穴があります。MCPツールでは、サーバーを要求に応じて数か月先まで更新することはできません。毎月の更新は自動で、3、6、12か月分の前払いはダッシュボードかREST呼び出し1回で行います。最初から長い期間にしたい場合は、order_vpsが注文時にmonths（1〜36）を受け付けます。

成長はget_upgrade_optionsとchange_planが担います。プランはその場で変わり、ファイルとOSはそのまま、サーバーは1回再起動し、残り期間の差額は残高から引かれます。エージェントはconfirm: trueを渡す必要があります。「お金を使うのだから、本気で」という私たちなりの意思表示です。

うまくいかないとき

破壊的な操作は、わざと手間がかかるようにしています。reinstall_vpsと即時のcancel_serviceはどちらもconfirmにサーバーの正確なホスト名を求め、説明ではまず人に確認するようエージェントに伝えています。ここがエージェントがあなたを必要とする2つ目の場所で、意図的なものです。

安全な解約であるend_of_periodは、支払い済みの期間が終わるまでサーバーを残します。undo_cancelで取り消せるのは思った以上に大切です。エージェントも人と同じくらい、作業の途中で考えを変えます。

エージェントが行き詰まったら、create_ticketがサーバーに紐づくチケットを開き、reply_ticketでやり取りを続けます。読むのは私たちの側の人間で、チャットボットに答えるチャットボットではありません。

そして人が介入すべきときは、delegate_serviceがその人を1台のサーバーのオペレーターとしてメールで招待します。電源、コンソール、再インストール、ホスト名は使えますが、請求、更新、解約は使えず、エージェントのトークンを見ることもありません。

エージェントにまだできないこと

限界をはっきりさせておくと：

• 残高のチャージ。 チャージ用の請求書を作り、pay_invoiceで請求書を残高から支払うことはできます。暗号資産を残高に入れるにはウォレットが必要で、それは通常あなたです。
• MCPでOSの中の作業をすること。 パッケージ、設定、デプロイはSSHで行います。MCPはマシンを外側から管理します。
• 停止を自分で解除すること。 不正利用でサーバーが停止された場合は人との対話になります。それが本来あるべき形です。

だからといってツールの価値が下がるわけではありません。エージェントのループをツールに合わせて設計しようということです。ステータスを確認し、残高を適正に保ち、チケットでエスカレーションし、データを消す操作の前にはあなたを待つ。

エージェントの作業が短命なら、サーバー1台はそもそも適切な単位ではないかもしれません。VPSかサンドボックスかでは、1分で消えるmicroVMのほうが合う場面を解説しています。そうでなければプランはこちら、MCPリファレンスにはすべてのツールとパラメータが載っています。