レンタルサーバーの「AI対応」は3種類ある — ロリポップ・エックスサーバー・ConoHa WING を同じ物差しで比べた

2026年、レンタルサーバー各社が相次いで「AI対応」を打ち出した。エックスサーバーは5月に MCP サーバーと CLI を出し、ロリポップは公開 API と MCP サーバーを用意し、ConoHa WING は AI コーディングエージェント向けのファイルを公開した。

見出しだけを並べると、どこも同じことをしたように見える。だが実際に3社のドキュメントと API 仕様を突き合わせると、中身は3通りに割れていた。しかも「どこまで AI に任せられるか」は、桁が違う。

当社は自社サイトのロリポップに MCP と API を実際に導入した。その過程で、ドキュメントを読んだだけでは分からないことがいくつも出てきた。この記事は、3社を同じ物差しで並べ直したものである。

先に立場を明かしておく。当社はエックスサーバーのビジネスパートナーである。 そのうえで、以下の比較は各社が公開している一次資料（公式ドキュメント・OpenAPI 仕様）から数字を取り、当社が実際に測った結果と区別して書いた。エックスサーバーにとって不利な点も同じ強さで書いている。

1. 結論 — 同じ土俵に乗っていない

	ロリポップ！	エックスサーバー / XServerビジネス	ConoHa WING
REST API	あり（4領域）	あり（133エンドポイント）	なし
MCP サーバー	あり（リモート HTTP）	あり（ローカル・npx）	なし
公式 CLI	なし	あり	なし
公式 Agent Skill	なし	あり	あり（これだけ）
AI が触れる範囲	ドメイン・SSL・WordPress	サーバー設定のほぼ全部	ファイル転送だけ
削除の API	ある	ある	そもそもない
課金操作の API	ない	ある	ない
復元（undo）の API	ない	ある	—

言葉にすると、こうなる。エックスサーバーは133本のエンドポイントでサーバー設定のほぼ全部を開けており、契約の購入までできる代わりに、バックアップからの復元 API も持っている。ロリポップはドメイン・SSL・WordPress の4領域に絞って開けており、導入は最も軽いが、undo がない。ConoHa WING は API を開けておらず、AI にできるのは FTPS でのファイル転送だけで、削除は最初から実装されていない。

以下は、なぜこうなるのかの説明である。

2. 「AI対応」は3つの層に割れている

3社がやったことは、こう整理できる。

① API と MCP を出した — ロリポップ！

https://lolipop.jp/api/v1 に REST API があり、/mcp に MCP サーバーがある。認証は lp_pat_ で始まる Personal Access Token の Bearer 認証。触れるのは独自ドメイン・サブドメイン・無料SSL・WordPress簡単インストールの4領域だけである。

MCP はリモート HTTP 方式で、事業者側のサーバーで動く。使う側は URL とトークンを設定するだけでよく、Node.js も追加ソフトも要らない。導入の軽さでは3社で一番だ。

② API・CLI・MCP・スキルを全部出した — エックスサーバー / XServerビジネス

2026年5月12日提供開始。REST API に加えて公式 CLI があり、MCP サーバーがあり、さらに AI エージェント用の公式スキルまである。4点セットで最も厚い。詳細は次節。

③ API を出さず、スキルだけ出した — ConoHa WING

ConoHa WING には公開 API も MCP サーバーもない。機能一覧ページを当たっても記載がない。代わりに SKILL.md と Python スクリプトの2ファイルを公開している。その正体は FTPS でファイルを上げ下げするツールである。

ここは混同されやすいので明確にしておく。ConoHa の MCP サーバーは VPS 向けだけだ。2025年7月に「国内クラウド事業者初」として公開されたのも ConoHa VPS で、WING ではない。また「ConoHa WING で Claude Code から WordPress に投稿できた」という記事がいくつかあるが、あれは WordPress 側の REST API やプラグインの話であって、ConoHa が API を出しているわけではない。

3. エックスサーバーの厚み — 133本という実数

エックスサーバーは OpenAPI 仕様を公開している。3本ある仕様ファイルを実際にダウンロードして、エンドポイントを数えた。

仕様	エンドポイント数	主な内容
server	79	契約・自動バックアップ・Cron・SSH鍵・リソースモニター・アクセス拒否・WordPress・メール一式（SPF/DKIM/DMARC含む）・FTP・MySQL・PHPバージョン・php.ini・ドメイン・SSL・DNS・ログ・キャッシュ・WAF
domain	13	ドメイン取得・移管・契約更新・ネームサーバー・DNS・Whois・レジストラロック
wphosting	41	サイト作成/削除・ステージング・バックアップ/復元・プラグイン・テーマ・WPユーザー
合計	133

ロリポップの4領域と比べると、サーバーパネルの主要機能がほぼ全部 API になっていることが分かる。

保守の現場から見て効くのは、次の2つだ。

ステージング環境の作成 API がある。 WordPress ホスティングの仕様には、ステージング作成のエンドポイントが含まれている。検証環境を作って確かめてから本番に反映する、という保守の型が API で回せる。

復元 API がある。 自動バックアップの取得と復元、MySQL バックアップ、WordPress ホスティングのバックアップ復元。この「戻せる」手段を API として持っているのは3社でエックスサーバーだけである。

これは思っている以上に大きい。ロリポップの API には undo がない。当社が自社サイトで運用ルールを作ったとき、「変更前の状態を書き留めたファイルだけが唯一の復旧手段」という前提から設計せざるを得なかったのは、この差による。

4. だが、エックスサーバーの API は「お金を使える」

ここで話が変わる。

エックスサーバーの API には、POST /v1/server というエンドポイントがある。仕様の説明はこうだ。

POST /v1/server は、プリペイド残高から料金を支払い、サーバー契約を作成するAPIです。

ドメイン側も同じである。POST /v1/domain（ドメイン取得）、/renew（契約更新）、/transfer（移管）。いずれも実際に契約が発生し、金が動く。

エラーコードの一覧に 402 Payment Required — 新規お申し込みに必要なプリペイド残高が不足 という行が用意されている。API が金を使う前提で設計されている、ということだ。

つまり、AI エージェントに繋いだ先には「サーバーを買う」ボタンがある。

これが、この比較で最も重要な発見だった。機能表を眺めているときは「エックスサーバーは何でもできて便利だ」という話だったのが、ここで反転する。できることが多いというのは、間違えたときに起きることも多い、と同じ意味である。

そして事業者もそれを分かっている。仕様には「新規申込の安全な実行」という専用の節があり、4つのロックが掛けられている。

1. まず dry_run=true で申込内容と税込合計金額を確認する
2. 実申請では、価格取得 API が返した total_price を expected_total_price に指定する。食い違えば PRICE_MISMATCH で弾かれる
3. agree_to_terms=true を送る
4. Idempotency-Key ヘッダーを送る。応答を受け取れなかった場合、同じキーの再送は48時間 409 DUPLICATE_REQUEST になる

さらに MCP 側でも二重に閉じている。新規申込を実行するには、環境変数 XSERVER_MCP_ENABLE_HIGH_RISK_EXECUTE と、API キー側の許可設定の両方が必要だと明記されている。

よく考えられている。ただし1つだけ、読み飛ばすと危ない仕様がある。

dry_run を省略すると false となり、実申請として処理されます。

既定値が「実行」なのだ。 安全側が既定ではない。ここは知らずに触ると事故になる。

5. 事業者はどう守っているか — 3社の設計を読み比べる

「AI に何をさせないか」を、3社は3つの違うやり方で表現している。読み比べると、それぞれの立場がよく見える。

エックスサーバー — 鍵と設定ファイルの二段で絞る

API キーの発行時に、キー名・有効期限・対象サーバーアカウント・権限を指定できる。権限は「すべての操作」「読み取り専用」「カスタム」の3種類。ドメインの取得・移管・更新については、専用のチェックボックスが別に用意されている。

そのうえ MCP 側でも --services=server|domain|wphosting で面を絞れる。ドメイン取得（＝課金）を触らせたくなければ、--services=server だけで起動すればよい。鍵で絞り、設定ファイルでもう一度絞れる。二段で絞れるのは3社でエックスサーバーだけである。

もう1つ、公式スキルの冒頭に置かれた記述を引用したい。

– API キーをチャット本文に貼るよう案内してはならない

– API キーを echo / printf 等でコマンドに含めてはならない

– API キーはファイルに直接書き込んではならない

– API キーは環境変数経由でのみ受け取る

事業者自身が「コマンドに鍵を載せるな」と書いている。 これは軽い注意書きではない。コマンドの引数に書いた文字列は、同じマシンで動いている他のプロセスから一覧で読める。書いた本人の画面には出てこないが、外からは見えている。

当社も今年8月、まさにこの形でトークンを露出させた。幸いだったのは、それが自社の学習・開発用に発行したトークンで、クライアントの資産にも本番環境にも繋がっていなかったことだ。

だが、「幸いだった」というのが問題なのである。被害が出なかったのは設計のおかげではなく、たまたま渡していた鍵が軽かったからにすぎない。 同じ手順で、同じ書き方で、もし顧客データを読める鍵を渡していたら。本番サーバーを操作できる鍵を渡していたら。手順は何ひとつ変わらないまま、結果だけが変わる。

そして本記事で扱っている API キーは、まさに本番サーバーを操作できる鍵である。ドメインを解除でき、WordPress を消せて、エックスサーバーに至っては契約を購入できる。軽い鍵で助かった経験は、重い鍵を渡す前にしか活かせない。

公式スキルにこの一行があるかどうかで、その事業者がどこまで考えているかが分かる。

ロリポップ！ — 領域ごとに3段階

API キーの権限は「ドメイン設定」「SSL設定」「WordPress設定」の3領域それぞれに、「すべての操作」「読み取り専用」「利用不可」の3段階。有効期限も選べる。

ただし、粒度が「領域 × 読み書き」の2軸しかない。 動詞の単位では切れない。つまり 「ドメインの追加はできるが、解除はできない」鍵は作れない。 書き込みを許した時点で削除も付いてくる。

これは実務では効いてくる。ロリポップの DELETE /domains/{domain} は、仕様に「関連するサブドメイン・SSL の設定も削除されます」と明記されている。1コマンドでドメインとその配下がまとめて消える。 しかも API に undo がない。

ConoHa WING — 文章で禁じる

API がないので、絞る設定そのものが存在しない。代わりに SKILL.md に「できないこと」が並んでいる。

ファイル・ディレクトリの削除／ディレクトリの同期(mirror)／.htaccess などサーバーが管理するファイルの操作／WordPress のインストール・構築・運用／データベースの操作／SSH 接続、サーバー設定の変更

「削除しない」を仕様として宣言している。 API を出さなかった代わりに、スキルの文面が唯一の歯止めになっている。

なお、このスキルは教材としてよくできている。AI に対して「専門用語を使わず言い換えろ」と指示し、index.html を「サイトの入口ページ(トップ)」と呼べ、とまで書いてある。初心者に届けることを本気で考えた設計だ。

6. しかし、書いてあっても機械は止まらない

ここからは当社の実測の話である。

当社は自社サイトのロリポップに MCP と API を導入した。スコープは全権のまま運用すると決めた。前節で書いたとおり、絞っても削除は塞げないからだ。ならば歯止めは呼び出し側に置くしかない。

そこで4段の歯止めを、別々の場所に置いた。①MCP の破壊的ツールを設定で拒否する ②コマンド経路を監視するフックを入れる ③実行スクリプト自体を既定ドライランにする ④それらが本当に効いているかの判定表を作る。

この過程で、ドキュメントには書かれていないことが3つ分かった。

MCP のエラーは HTTP 200 で返ってくる。 権限が足りないときも、通信としては 200 が返り、本文の中に isError: true が入っている。「200 だから成功」と読むコードを書くと、失敗を握り潰す。

ツール一覧には、使えないツールまで並ぶ。 MCP の tools/list を叩くと、今の権限では呼べないメール操作・PHP バージョン変更・サーバー情報のツールが返ってきた。実際に呼ぶと権限不足で弾かれる。つまり将来キーを作り直して権限が増えた瞬間、何もしていないのに使えるようになる。先回りして塞いでおく必要がある。

そして、書いた歯止めが最初の一発目で誤爆した。 コマンドを監視するフックを作ったところ、最初に止めたのは危険な操作ではなく、そのスクリプトを保存しようとした自分自身だった。ファイルの中身に「実行」という文字列が入っていたからである。「危険な語が出てくるか」ではなく「危険なコマンドの形をしているか」で判定し直して、やっと通った。

そしてもう1つ、歯止めが効いたときの効き方が予想より強かった。

拒否設定を入れて Claude Code を再起動したところ、サーバーが提供している25個のツールのうち、AI に渡されたのは21個だった。消えた4個は、拒否リストに書いた4個と完全に一致していた。

つまりこの設定は「危険な操作を頼まれたら断る」のではない。AI の手元に、その選択肢が最初から存在しない。断る判断が要らないので、判断を誤ることもない。一方、確認を求める設定にしたツールは21個の中に残っていて、呼ぶたびに人に聞いてくる。「渡さない」と「聞いてから渡す」を、操作ごとに書き分けられる。

この4つは、どれもドキュメントを読んだだけでは出てこない。実際に繋いで、動かして、間違えて初めて出る。

そして最も大事な結論はこれだ。規約に書いてあっても、機械は止まらない。

ConoHa WING のスキルは「削除しない」と宣言している。立派な設計だが、それは AI がその文章を読んで従うことを前提にしている。読まなかったとき、あるいは別の手段を思いついたときに止めるものが、そこにはない。

対して、拒否設定で消えたツールは読む・読まない以前に存在しない。ここが決定的な差である。文章による禁止は「守られるかどうか」の話だが、渡さないことは「できるかどうか」の話だ。当社がフックとスクリプトの二重で機械的に塞いだのも、同じ理由による。自社で書いた手順書が読まれずに同じ失敗を繰り返した経験が、先にあった。

7. どう選ぶか

用途で割り切れる。

保守案件を AI で回すなら、エックスサーバー / XServerビジネス。 理由は3つある。①面が広く、保守作業のほとんどが API に載っている ②復元 API がある（他2社にはない） ③読み取り専用キー・対象サーバー限定・有効期限で、AI に渡す鍵を無害化できる。特に③は、検証や調査の段階で「書き込む経路そのものが存在しない鍵」を作れるということで、他人の環境を預かる立場では決定的に効く。

ただし、面が広い分の宿題がある。 課金操作を持つこと、MCP がローカル動作で Node.js を要すること、そして歯止めを自分で用意する必要があること。133本のエンドポイントに全権の鍵で繋ぐのは、勧められない。エックスサーバーを選ぶということは、鍵の設計と歯止めの設計を引き受けるということでもある。

静的サイトを公開するだけなら、ConoHa WING のスキルで足りる。 API を持たないのは弱点だが、削除できないということは、削除の事故が起きないということでもある。 用途が限定されているなら、これは欠点ではなく仕様だ。

まず試すならロリポップ！が一番軽い。 リモート MCP なので Node.js も追加ソフトも要らず、設定は URL とトークンだけで済む。触れる範囲が4領域に限られているのも、最初の一歩としてはむしろ都合がよい。ただし undo がないので、書き込みを任せる前に「変更前の状態を控える」手順を必ず用意すること。

8. 最後に

「レンタルサーバーが AI 対応した」という一語で選ぶと、間違える。実際には、AI に渡している鍵の重さが3社でまったく違う。

そして、どの会社を選んでも共通する仕事が1つ残る。AI に何をさせないかを、文章ではなく仕組みで決めること。 事業者が用意した安全装置は、鍵の権限と設定ファイルまでだ。その先──「この操作は承認を取ってからにする」「消える前に控えを取る」──は、使う側で組む必要がある。

当社はエックスサーバーのビジネスパートナーである。そのうえで、この記事の数字は各社の公開仕様から取り、当社が実際に測った結果とは区別して書いた。エックスサーバーを勧める理由は、パートナーだからではなく、復元 API と鍵の絞り方という、他社にない具体的な2点があるからだ。

実務で使える形にしたい方へ

当社は、この記事で扱ったような内容も含めて、実務で使える AI 導入研修を行っている。サーバーを AI から触る話にかぎらず、鍵の絞り方・変更前の控えの取り方・歯止めの作り方を、貴社の環境で手を動かしながら組み上げるところまでを範囲としている。

→ AI 導入研修のご相談はこちら

出典

• ロリポップ！ MCP 利用ガイド https://lolipop.jp/developers/rentalserver/mcp/
• ロリポップ！ 公開API リファレンス https://lolipop.jp/developers/rentalserver/api/
• XServer 開発者ドキュメント https://developer.xserver.ne.jp/
• XServer MCP Server マニュアル https://www.xserver.ne.jp/manual/man_tool_mcp.php
• XServer MCP Server / CLI 提供開始のお知らせ https://www.xserver.co.jp/news/news-article.php?id=139
• ConoHa サイト公開スキル https://www.conoha.jp/function/skills/
• ConoHa WING 機能一覧 https://www.conoha.jp/wing/function/
• ConoHa VPS MCP https://vps.conoha.jp/function/mcp/

（エンドポイント数は各社が公開する OpenAPI 仕様を 2026-08-31 に取得して集計した実数。

ロリポップの挙動に関する記述は当社が同日に実測したもの。

エックスサーバー・ConoHa WING については公式ドキュメントの記載に基づく。）