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サイトを作ったあと、
で、これどこに公開しよう
となったとき、
「いつものレンタルサーバーでいいじゃん」
という選択肢も思い出してもらえればと思います。