FTPもサーバー情報も不要、WPプラグインでAIからデプロイ自動化

これまで私の常識は、サーバーにファイルをアップロードするのはFTPがなければいけない。サーバーのコントロールパネルからファイルサーバーでファイルをアップロードする方法、もしくはファイルマネージャー系プラグインを使っていた。エンジニアではない私はそれが常識だった。

全てのクライアントがFTP情報を送れるわけでもないし、サーバーのアカウント情報を共有してくれるわけではない。中にはWordPressのアカウントしかもらえないときも多い。

そんな中でエンジニアではない私はFTPさえあれば、もしくはサーバーのアカウントさえあればもっと効率的にデプロイできるのに、と悩んでいた。

2026年3月時点では、WordPressもバイブコーディングで作れるようになってきた。WordPressサイトの改修をAI（Claude CodeやAntigravity）にチャットで依頼し、コード修正からサーバー反映までを通して任せられる運用が実用的になってきている。

現在は、WordPressの管理者アカウントがあれば、REST APIを通じてAIがファイル操作やページ更新を含むデプロイできる。FTP情報もサーバーのSSH鍵も要らない。しかも安全に素早く確実にAIがデプロイしてくれるようになった。

環境に応じた3段階のデプロイ方式と、それぞれの技術的な仕組みを紹介する。

WordPressの3つのデプロイ方式

クライアントや自社の環境によって、サーバーへのアクセス手段はSSHが使える場合もあれば、FTPしか許可されない場合もあり、サーバー情報を一切もらえない場合もある。どの環境でもAIによるデプロイを実現するために、3段階の方式を設計し実際に試した。

Tier	方式	必要な情報	デプロイ速度	適用場面
1	SSH / SCP	SSH鍵 + ホスト情報	1秒未満	自社サイト、SSH設定可能なサーバー
2	FTP / FTPS	FTPホスト・ユーザー・パスワード	5～15秒	クライアントからFTP情報を受領できる場合
3	WordPress REST API	WordPress管理者アカウントのみ	3～10秒	FTP不可・サーバー情報不可の環境

クライアントからFTP情報を共有してもらえらる場合はFTPをAIが操作してデプロイできる。クライアントからサーバー情報をもらえる場合はAIがSSHを使ってデプロイできる。クライアントからサーバー情報もFTPも共有してもらえなければ、AIがWordPressのREST APIを使いデプロイすることができる。

つまりどのパターンでもAIがデプロイできる。

これによってあらゆるパターンでデプロイまでの工数と時間が短縮できるようになった。

SSH　最速のデプロイ方式

SSH（Secure Shell）はサーバーと暗号化された直接通信チャンネルを確立するプロトコルだ。SCP（Secure Copy Protocol）はそのチャンネル上でファイルを転送する。

AIがCSSファイルを修正した後、1行のSCPコマンドでサーバーに転送する。転送時間は1秒未満。認証は公開鍵暗号（RSA）で行うため、パスワード入力は不要だ。転送後はOPcacheリセットとPlaywright（ヘッドレスブラウザ）によるビジュアル検証が自動実行される。

「改修依頼→コード修正→サーバー反映→表示確認」の全工程がチャットでの1回の依頼で完結する。

レンタルサーバーでもSSHは使える

「SSHはAWSや専用サーバーでないと使えない」と思われがちだが、意外とレンタルサーバーでも使える。ConoHa WINGのような月額1,000円台のレンタルサーバーでもSSH接続は標準サポートされている。管理画面から公開鍵を登録し、ポート番号とSSHユーザー名を確認するだけで、30分程度で接続が確立する。

デプロイ速度はAWSの専用サーバーと遜色ない。月額数万円のクラウドサーバーでなくても、本格的なAI連携デプロイは実現できる。

FTPが残る理由

SSHは最速だが、全てのサーバーで利用できるわけではない。クライアントのサーバーでSSH鍵の登録が許可されていない場合や、共用サーバーでSSHポートが開放されていない場合がある。

FTP/FTPSはほぼ全てのレンタルサーバーが対応している。FTPSはFTPにSSL暗号化を加えた方式で、転送中のデータが暗号化される。AIはFTP認証情報（ホスト・ユーザー名・パスワード）を環境変数から読み込み、SSHと同じパイプラインでデプロイを実行する。

転送速度はSSHより遅い（FTPSのハンドシェイクに数秒かかる）が、ファイル転送後のOPcacheリセットとビジュアル検証は同じ仕組みで動作する。弊社のサイトでも最初はFTP情報を使ってAIがデプロイをしていたが、毎回AIがデプロイ用スクリプトを作り、それを使ってデプロイをしていた。つまり、その分でデプロイまで待たされる感があった。「これからデプロイしますね」、とAIが回答してからデプロイされ、私が実際に確認できるまで数分のタイムラグが起こっていた。自分でFTPを上げれば1分もかからないが、AIがデプロイを体験すると手デプロイが面倒に感じる。そのため多少数分かかっても、AIにデプロイまで任せることに恩恵を感じていた。

そこからさらに欲が出て、デプロイまでもう少し早くなればと思うようになり、FTP以外のデプロイ方法を模索していた。デプロイまでにかかる時間はSSHやREST APIを使う方が早くストレスがない。FTPは最後の手段と言ってもいいだろう。

WordPressアカウントだけで動くdev-toolsプラグイン

クライアントから「FTP情報は共有できない」「サーバーのログイン情報は渡せない」と言われるケースは珍しくない。そのため今まではステージング環境で構築したWordPressを引っ越しプラグインなどで本番環境へアップロードしていた。だが実際は本番環境でも不具合が出たり、クライアントからの要望で修正対応をしなければならないこともある。そんな時にFTPも使えずサーバーのログイン情報も渡せないと言われると、余計な工数が大幅にかかってしまう。このとき、WordPress管理画面の管理者アカウントがあれば、AIによるファイル操作やページ更新に対応できる。

私はこの自社プラグインを使ってデプロイしたときに、魔法の扉のようだと感じた。クライアントに「ここを直して」「ここはこういう風にしたい」など、後出しで要望を出されたときに、それがWordPressの標準機能やテーマにない機能があったとしても、AIに依頼するだけで魔法のように要望に応えることができる。

仕組み

WordPress 4.7以降、REST APIがコアに組み込まれている。これはWordPressの全データ（ページ・投稿・メディア・設定）をHTTPリクエストで操作できるインターフェースだ。サーバーの種別を問わず、WordPressが動いていれば /wp-json/wp/v2/ エンドポイントが使える。ConoHa WINGであれ、さくらインターネットであれ、エックスサーバーであれ、追加費用なしで利用可能だ。

ただし、WordPress標準のREST APIではサーバー上のファイル操作（CSS書き換え、テーマファイル更新等）はできない。これを解決するために、自社開発のdev-toolsプラグインを設計した。

dev-toolsプラグインの4つのエンドポイント

エンドポイント	メソッド	機能
/dev-tools/v1/file	GET	サーバー上のファイル内容を取得
/dev-tools/v1/file	POST	サーバー上のファイルを作成・上書き（自動バックアップ付き）
/dev-tools/v1/list	GET	ディレクトリ内のファイル一覧を取得
/dev-tools/v1/status	GET	プラグインの稼働状態・ログ件数を確認

認証にはWordPress 5.6以降の標準機能であるアプリケーションパスワードを使用する。管理者権限（manage_options）を持つユーザーのみ操作可能だ。

セキュリティ設計

• パストラバーサル防止: .. を含むパスを全て拒否。wp-contentディレクトリ外へのアクセスを遮断
• PHP書き込み禁止: .phpファイルの書き込みをブロック。CSSやHTML等の非実行ファイルのみ操作可能
• 自動バックアップ: ファイル上書き時に既存ファイルを自動保存
• 操作ログ: 全操作をJSON形式で記録（日時・ユーザー・操作内容・IPアドレス）
• 有効期限: クライアント案件ではタイマーを設定し、期間経過後に自動で無効化

導入手順

1. WordPress管理画面 → プラグイン → 新規追加 → プラグインのアップロード → dev-tools.zipを選択してインストール
2. プラグインを有効化
3. ユーザー → プロフィール → アプリケーションパスワード → 新しいパスワードを発行
4. 以後、AIツール（Claude Code / Antigravity）にサイトURLとアプリケーションパスワードを設定すれば、チャットでの改修依頼→デプロイが完結する

つまりアプリケーションパスワードをユーザー設定画面で設定できれば、どんなワードプレスにも対応できる。

FTPソフトのインストールも、サーバーへのログインも、ファイルの手動アップロードも不要になる。

デプロイ速度とPDCA回転数の関係

技術的な解説を踏まえた上で、これがマーケティングの成果にどう直結するかを整理する。

	従来型（FTP手動）	AI連携（Tier 1～3）
1回の改修時間	4～8時間	1～5分
月間改修件数	約20件	200件以上
PDCA回転数	週1～2回	週5～10回

改修が5分で完了すると、残りの時間の使い方が根本的に変わる。

• CTAのテキストを変更する（5分）→ その日のうちにクリック率の変化を確認する
• ランディングページの構成を変える（5分）→ Before/Afterのスクリーンショットで比較検証する
• A/Bテストの仮説を3つ立てる → 3つとも当日中にデプロイして翌日データを確認する

従来の運用では「改修して、来週データを見る」が精一杯だった。AI連携運用では「改修して、今日データを見て、明日また改修する」が日常になる。特に、トラフィックが月間100万PV以上の大量のトラフィックがあり、かつB2C商材を扱っているクライアントにとっては高速PDCAを回せるようになった。

デプロイだけではなく、BigQueryやGTMもAIが操作して、データ抽出、分析、ABテストのデプロイまでAIに日本語の指示でできるようになった。もちろんデータの整合性を確認するために人間の目視チェックは欠かせないが、デプロイからデータの抽出までAIができるようになると、作業という名の作業はなくなる。

デプロイ速度から利益率まで

デプロイが速くなると、改修に使っていた時間が空く。その時間をデータ分析や次の施策の立案に回せる。PDCAの回転数が上がれば、「何が効いて何が効かなかったか」の知見が蓄積されるペースも上がる。知見が積み上がれば、次の施策の精度が改善し、広告費・制作費に対するリターンが上がる。結果として利益率の改善につながる。

ただし、デプロイが速くなっただけでは成果は変わらない。何を測定するか、どんな仮説を立てるかが明確でなければ、回転数が増えても得られるものは同じだ。速度はあくまで手段であり、次の改修にデータを活かせる体制が前提になる。

品質チェックの仕組み

「速くすればミスが増えるのでは」という懸念に対して、AIは4層の品質防御を自動実行する。

層	内容	タイミング
Layer 1	過去の失敗教訓をHookで毎回強制注入	コード生成前
Layer 2	WordPress仕様に準拠したHTMLのみ生成	コード生成時
Layer 3	HTMLバリデータでh2/h3/table/CSSを検証	デプロイ前
Layer 4	Playwrightで実ブラウザのスクリーンショット比較	デプロイ後

HTMLバリデータがWordPressのブロッククラス（wp-block-heading等）の付け忘れを検出し、Playwrightがデプロイ後の表示崩れを検知する。目視では見落としやすい箇所を機械的にカバーする仕組みだ。とはいえ、フォームの動作やデータベースへの影響までは検出できないため、大規模な変更では手動テストも併用する。

まとめ

FTP情報がなくても、サーバーのログイン情報がなくても、WordPressの管理者アカウントがあればAIにデプロイを任せられる。レンタルサーバー（ConoHa WING等）で十分動作し、AWSや専用サーバーは必要ない。

デプロイが速くなった分の時間をデータ分析と施策立案に使えば、PDCAの回転数が上がる。施策の結果が次の判断材料になり、改善の精度が上がっていく。

---

この記事で紹介した3ティアデプロイ方式とdev-toolsプラグインは、弊社が自社サイト・クライアントサイトで実際に運用しているアーキテクチャに基づいている。