Claude CodeやCodexに、

小さな会社のWebサイトを作って

と頼む。

少し修正を指示する。

数分後にはHTML/CSS/JavaScriptができている。

ここまでは、かなり簡単になりました。

でも最後にこう言いたくなります。

じゃあ公開して

ここで急に話が変わります。

Vercel、Netlify、CloudflareならCLIも整っていて、AIエージェントとの相性もいい。

一方、日本にはすでに大量のレンタルサーバーがあります。

XServerを契約している
さくらのレンタルサーバにドメインがある
ロリポップ！で昔から会社サイトを運用している
顧客からFTP/SFTP情報だけ渡された
WordPressの横にLPを追加したい
静的な会社サイトのためだけに別サービスへ移したくない

こういうケースまで、全部新しいホスティングへ持っていく必要はありません。

public_html にファイルを置けば公開できるなら、AIにもそこまでやってもらえばいい。

そのために spush というCLIを作りました。

npm install -g @shuent/spush

spush init --provider xserver
spush push --dry-run
spush push --verify

要するに、

AIで作る
   ↓
spush
   ↓
いつものレンタルサーバー

です。

TL;DR

spush は、Claude Code / CodexなどのAI coding agentやローカル環境から、FTP / FTPS / SFTP対応サーバーへWebサイトをデプロイするCLIです。

例えばClaude Codeに、

このサイトをspushで公開して。
先にdry-runして、問題なければverify付きでpushして。

と頼めます。

対応するのは特定のホスティング会社ではありません。

FTP / FTPS / SFTPが使えれば基本的に同じインターフェースで扱います。

国内向けには現在、

spush init --provider xserver
spush init --provider sakura
spush init --provider lolipop

というpresetも用意しています。

なぜ「とりあえずVercel」でなくてもいいと思ったのか

先に書いておくと、VercelやCloudflareを否定したいわけではありません。

Next.jsのSSR、Edge Functions、Preview Deploymentなどを使うなら、専用プラットフォームを使う方が圧倒的に楽です。

でもAIが作るWebサイトの中には、もっと単純なものも大量にあります。

index.html
about.html
assets/
  style.css
  app.js

あるいは、

npm run build
     ↓
dist/

だけ。

会社サイト、店舗サイト、LP、採用ページ、キャンペーンページなどはこれで十分なケースも多い。

さらに日本では、

すでにレンタルサーバーを契約している

という状況がかなりあります。

だったら、

npm run build
spush push

でよくないか。

というのが発端です。

「Claude CodeならFTPくらい勝手にできるでしょ」

できます。

Claude Codeに、

このサーバーへアップロードして

と頼めば、環境にある scp、sftp、lftp などを探して何とかしようとしてくれます。

ただ、本番サイトへのデプロイとなると、実際には結構いろいろ決める必要があります。

FTPなのかFTPSなのかSFTPなのか
hostnameは何か
portはいくつか
ユーザー名はどこにあるか
パスワードや秘密鍵をどう渡すか
ローカルのどこをアップロードするか
リモートのどこへ置くか
public_html なのかドメイン別ディレクトリなのか
.env やソースコードを送らないようにするにはどうするか
削除されたファイルをどう扱うか
本当にそのディレクトリへ送って大丈夫か
公開後にどう確認するか

一度ならAIに全部考えさせてもいい。

でも更新するたびに同じ判断をさせるのは無駄です。

しかもAIが本番サーバーを触るなら、

賢く自由に操作してもらうより、狭く決められた操作をさせたい。

そこで、

spush push

というインターフェースに閉じ込めることにしました。

30秒で使ってみる

Node.js 24以上が必要です。

まずインストール。

npm install -g @shuent/spush

プロジェクトへ移動します。

cd my-website

例えばXServerなら、

spush init --provider xserver

設定ファイルと環境変数のサンプルが生成されます。

接続情報を入れたら、

spush check --env-file .env.spush

で接続確認。

いきなり本番には送りません。

spush push --dry-run

まず何が送られるか確認します。

問題なければ、

spush push --env-file .env.spush --verify

これでアップロードし、最後に公開URLへHTTPアクセスして簡単な確認まで行います。

AIから使うとこうなる

人間が直接コマンドを打ってもいいですが、作った理由はAIから使いたかったからです。

Claude CodeやCodexに、

サイトを修正して。
完了したらbuildして、spushでdry-run。
問題がなければ本番へpushして、公開URLも確認して。

と渡します。

するとイメージとしては、

コード修正
    ↓
npm run build
    ↓
spush push --dry-run --json
    ↓
変更内容を確認
    ↓
spush push --verify --json
    ↓
公開確認

という流れになります。

AIにFTPの使い方を考えさせるのではなく、

デプロイという決められた仕事をCLIへ委譲する

形です。

`spush.yaml` をプロジェクトに置く

公開方法は spush.yaml に宣言します。

例えば、

source: dist

connection:
  protocol: sftp
  host: { env: SFTP_HOST }
  port: 22
  user: { env: SFTP_USER }
  password: { env: SFTP_PASSWORD }

remote_dir: /home/example/example.com/public_html
url: https://example.com/

こんな感じです。

これを置いておくことで、

このプロジェクトは

dist を
SFTPで
このサーバーの
このディレクトリへ
公開する

という情報がコード側に残ります。

人間にとっても便利ですが、AIにとっても都合がいい。

毎回プロンプトに、

FTPサーバーは〜
ディレクトリは〜
ビルド結果はdistで〜

と書く必要がありません。

プロジェクトを見れば公開方法が分かります。

パスワードをAIのコンテキストに書かない

秘密情報はconfigへベタ書きしなくてもよくしています。

connection:
  host: { env: SFTP_HOST }
  user: { env: SFTP_USER }
  password: { env: SFTP_PASSWORD }

.env.spush 側に、

SFTP_HOST=example.com
SFTP_USER=example-user
SFTP_PASSWORD=secret

を書きます。

そして、

spush push --env-file .env.spush

とする。

AIには、

SFTP_PASSWORDの値はこれです

ではなく、

spushでdeployして

とだけ言えるようにしたかった。

AIに本番を触らせるので、削除はかなり慎重にした

FTP同期ツールで一番怖いのは削除です。

例えばローカルにWordPress本体がない状態で、

ローカルに存在しないファイルを全部消す

みたいな同期をしてしまうと大事故になります。

そこで通常の、

spush push

ではリモートのファイルを削除しません。

削除したい場合だけ、

spush push --delete

を明示します。

さらに --delete を指定しても、

spush自身が過去に追跡したファイルだけ

を削除対象にしています。

.spush/manifest.json に前回の状態を保存して、

spushが管理していた
+
ローカルから消えた

ものだけを削除します。

サーバーに昔から存在している未知のファイルを、勝手に掃除しません。

AIに本番を触らせるなら、こういう制約の方が重要だと思っています。

`--dry-run` と `--json` はAI向け

人間向けCLIなら、

Uploading...
Done!

だけでも何とかなります。

AIから呼び出すなら、もう少し機械的に扱える方が便利です。

そのため、

spush push --dry-run --json

も用意しています。

例えば、

{
  "ok": true,
  "command": "push",
  "dryRun": true,
  "uploaded": 2,
  "skipped": 4,
  "deleted": 0,
  "bytes": 1821
}

のような結果を返します。

終了コードもエラー種類ごとに分けています。

AI agentやCIから、

成功したのか
設定がおかしいのか
認証に失敗したのか
転送に失敗したのか
verifyに失敗したのか

を判断しやすくするためです。

変更がないファイルは送らない

毎回サイト全体をアップロードするわけではありません。

spush はSHA-256のmanifestを持ちます。

前回と比較して、

変更あり → upload
変更なし → skip

にします。

AIに、

文言1ヶ所だけ直して

と頼んだあと、サイト全部を送り直す必要はありません。

小さな変更をAIに繰り返させる用途とも相性がいいと思っています。

既存サイトをAI側へ持ってくることもできる

新しく作ったサイトだけならpushだけで済みます。

でも実際のレンタルサーバー案件は、

GitHubには何もない
サーバー上には10年前からファイルがある

みたいなものも多いです。

そのためimportも入れました。

spush import --dry-run
spush import --write-manifest

例えば、

既存の会社サイト
    ↓
spush import
    ↓
ローカルへ取得
    ↓
Git管理
    ↓
Claude Codeで修正
    ↓
spush push

という流れにできます。

個人的には、新規サイトの公開以上にこの用途は結構あるのではと思っています。

WordPressのテーマだけAIで直す、みたいな使い方もできる

spushはWordPress専用ツールではありません。

単にファイルを転送しているので、テーマディレクトリだけを対象にすることもできます。

例えば、

source: wp-content/themes/my-theme

connection:
  protocol: sftp
  host: { env: SFTP_HOST }
  user: { env: SFTP_USER }
  password: { env: SFTP_PASSWORD }

remote_dir: /home/example/example.com/public_html/wp-content/themes/my-theme

として、

spush push

とする。

これなら、

このWordPressテーマのヘッダー直して
↓
確認
↓
デプロイ

というところまでAIに任せられます。

ただしWordPressの場合、管理画面からの更新などによってリモート側だけ変わるケースがあります。

その場合は単純なGit管理と同じ感覚では扱えないので注意が必要です。

国内レンタルサーバー側もAI対応を始めている

これを作り始めた頃より、国内レンタルサーバー側もかなり面白いことになっています。

2026年にはXServerが公式MCP Server / CLIを提供し、Claude CodeやCodexなどからサーバー管理を行えるようになりました。ロリポップ！もAIエージェントSkillsを公開し、Claude CodeやCodex等からサイト作成・公開、さらにドメイン・SSL設定まで行う方向へ進んでいます。

つまり、

AI
 ↓
レンタルサーバー

という組み合わせ自体が、特殊なものではなくなりつつあります。

spushが少し違うのは、

特定のレンタルサーバー事業者のAPIには依存しない

ところです。

XServer
さくら
ロリポップ！
海外shared hosting
顧客のSFTPサーバー
自社サーバー

でも、

FTP / FTPS / SFTPさえあれば、

spush push

という同じ形にしたい。

専用APIが提供されているなら専用CLIを使うのも当然ありです。

spushはその一段下の、昔からあるファイル転送プロトコルを共通レイヤーにしています。

Vercelを置き換えたいわけではない

ここは重要なので繰り返します。

spushでできないことは普通にあります。

例えば、

Next.js SSRの実行環境を作る
Serverless Functionsを動かす
Edge Runtimeを提供する
Dockerをdeployする
DNSを管理する
DB migrationをする
Node.jsの常駐プロセスを管理する

こういう用途なら、それに合ったプラットフォームを使うべきです。

spushがやりたいのはもっと地味です。

AIが作ったファイルを
今あるWebサーバーへ
安全寄りに置く

これだけです。

でも会社サイトやLP、静的サイト、PHP、WordPressテーマなどでは、その「これだけ」で十分なケースが結構あります。

レンタルサーバーはAI時代でも案外悪くない

AI coding agentが普及すると、個人的にはレンタルサーバーの価値が少し変わると思っています。

以前は、

FTP？
管理画面？
手動アップロード？
古い

と感じていました。

でもAI側から見ると、

決められたコマンドを実行して
決められた場所へファイルを送る

だけなら、それほど難しい話ではありません。

一度設定してしまえば人間は、

直して
公開して

と言うだけになる。

だったら、

既存の契約をそのまま使える
国内向けサービスが多い
円建て
定額
WordPressやPHPも使える
ファイルを普通に持ち出せる

という従来型レンタルサーバーの特徴も、AI時代にはまた違って見えてきます。

最先端のアプリ実行環境としてではなく、

「普通のWebサイトを置く、安くて分かりやすい場所」

としてです。

使ってほしい

まだ改善したいところはいろいろあります。

特にprovider presetは実際の環境で使った情報を増やしたいです。

現在は、

spush init --provider xserver
spush init --provider sakura
spush init --provider lolipop

を用意しています。

他のレンタルサーバーで動いた、presetをこうした方がいい、ここで詰まった、という情報があればIssueやPRをもらえると助かります。

AIでWebサイトを作ったあと、

で、これどこに公開しよう

となったとき、

「いつものレンタルサーバーでいいじゃん」

という選択肢も思い出してもらえればと思います。