Kinsta APIを用いたWordPress代行業の自動化

WordPressサイトを1つひとつ管理するのは時間がかかります。数十、数百のサイトを運営するWeb制作会社では、環境の作成、キャッシュの削除、ドメインの追加、バックアップの復元といった作業がすぐに積み重なり、繰り返しの負担でチーム全体の動きが鈍くなってしまいます。

よくある流れはこんな感じです。

• 新しい顧客を受け入れる → 開発者がWordPressを手作業でセットアップし、ドメインを追加してプラグインを設定する
• 誰かがデプロイを行う → チームがログインしてキャッシュを手作業で削除する必要がある
• 顧客から不具合の報告がある → 担当者がログを確認し、必要に応じてバックアップからサイトを復元する

どれも複雑な作業ではありませんが、繰り返すことで本来もっと重要な業務に使える時間を奪ってしまいます。

そこでKinstaでは、使いやすい直感的な管理画面に加え、Kinsta APIも用意し、Web制作会社が日々行うルーティンタスクを自動化できるようにしています。

ここからは、Web制作会社がKinsta APIを活用して自動化できるWordPress管理タスクをいくつかご紹介します。

WordPressサイトの作成と複製

新しいWordPressサイトのインストールは、おそらくチームが最も頻繁に行う作業のひとつです。Web制作会社を立ち上げたばかりの頃は、週に5〜10サイト程度しか立ち上げないため、それほど負担には感じないかもしれません。しかし、事業が成長するにつれて状況は変わります。ブラックフライデーのような繁忙期や、数日のうちに何十ものサイトを公開しなければならない大規模な顧客案件に直面することもあります。

そのようなとき、手作業では規模を拡大できません。作業ペースを落として人員を増やし教育する（時間もコストもかかる）か、自動化に頼るしかありません。

Kinsta APIを使えば、社内ツールや管理画面に組み込み、新しいWordPressサイトをワンクリックで作成できるようになります。

例えば、自社サイトで顧客が登録と支払いを済ませたとします。そのとき、サインアップフォームの結果を受け取り、APIを呼び出して、あらかじめ用意した基本テーマで新しいWordPressサイトを自動作成するスクリプトを用意しておけます。

これは机上の空論ではありません。APIにはすでに必要な機能が揃っています：

• POST /sites – 新しいWordPressサイトを作成
• POST /sites/clone – 既存の環境をクローン
• GET /operations/{operation_id} – サイト作成ステータスを確認
• GET /sites – 全サイトの一覧を取得（管理画面での利用に便利）

多くのサイトを抱えている場合でも、毎週のセットアップ作業にかかる時間を大幅に短縮できます。

プログラムでドメインを管理

クライアントのサイトを大規模に管理している場合、この機能は欠かせません。

エージェンシーは、オンボーディングやフルリブランドの際に、定期的にドメインの追加や変更を行います。大規模な代理店であれば、MyKinstaをクリックしてドメインを追加し、DNSを確認し、SSLを設定する時間を短縮したいと思うかもしれません。

Kinsta APIを使用すると、このすべてを自動化されたワークフローに移行することができます。

よくある実世界の例を紹介します： 新しいクライアントがサインアップします。あなたはすでにCRMでドメイン名とDNSを設定しています。あなたの内部システムは、DNSレコードがKinstaを指していることを確認し（多分、裏でDNSルックアップを使用する）、それが確認された瞬間にAPIを呼び出します。

• ドメインをアタッチする
• プライマリドメインとして設定する
• 必要に応じてカスタムSSLをアップロードする

「✅clientdomain.comがアタッチされ、SSLがアクティブになりました」とSlackで通知することもできます。

もう一つの例：20のクライアントサイトを一括でリブランディングするとします。各環境を新しいドメインで更新し、切り替え、SSLを自動的に適用するには、手作業で更新するのではなく、すべてのドメインの変更をキューに入れ、APIでループさせます。

これを可能にするエンドポイントのいくつかは以下の通りです。

• POST /sites/environments/{environment_id}/domains– ドメインの追加
• PUT /sites/environments/{environment_id}/change-primary-domain– プライマリドメインの変更
• DELETE /sites/environments/{environment_id}/domains– ドメインの削除

これは単なる便利機能ではありません。このような自動化は、週に5～10回この作業を行うWeb制作会社にとって、文字通り時間の節約と人的ミスの排除につながります。

さらに進めたいのであれば、あなた自身の内部ダッシュボードでこのコントロールを公開することもできます。ドメインを割り当てる」をクリックし、サイトとドメインを選択すると、アプリがKinsta APIを呼び出します。

バックアップの管理：リスト、リストア、ダウンロード

デプロイが失敗したり、プラグインが不具合を起こしたり、顧客からライブサイトの問題が報告されることがあります。MyKinstaには信頼できるバックアップ機能がすでに備わっていますが、複数のサイトを管理し迅速な対応が求められる場合には、ワークフローに直接組み込めるバックアップコントロールが役立ちます。

そこで登場するのがAPIです。Web制作会社はこれをデプロイパイプラインに組み込み、例えば次のように活用しています。

• 手動バックアップをデプロイ直前に作成する
• 問題が発生した場合、自動でリストアが実行される
• チームがサイトをロールバックする際にSlackや管理画面から離れる必要がない

例えば、次のようなSlackコマンドを設定できます。

/restore site-name to yesterday

この仕組みは内部サービスを呼び出し、リストアのエンドポイントを実行します。あるいは、社内ツールに「クイックリストア」ボタンを用意して、MyKinstaにログインすることなくAPI経由でサイトをワンクリックで安定した状態に戻すこともできます。

利用できるエンドポイントは以下の通りです。

• GET /sites/environments/{environment_id}/backups – 利用可能なバックアップの一覧（日次・手動・システム）
• POST /sites/environments/{targetEnvId}/backups/restore – バックアップの復元
• POST /sites/environments/{environment_id}/manual-backups – 手動バックアップの作成
• GET /sites/environments/{environment_id}/downloadable-backups – バックアップのダウンロード
• DELETE /sites/environments/backups/{backup_id} – バックアップの削除

APIを活用すれば、特に緊急性の高い状況でも素早く対応できます。

プラグインとテーマの一括更新

Kinsta APIを活用して、1つの管理画面から複数のWordPressサイトにある古いプラグインをまとめて確認・更新できるシンプルなツールの作り方を紹介しています。

Kinstaでは現在、プラグインとテーマの自動アップデートを有料アドオンとして利用できます（ビジュアルテストや自動ロールバックも実行されます）。ただし、この仕組みと同じ考え方は今も有効です。

しかし、チームが別のタイプのコントロールを求めるなら、APIを使って自由に仕組みを構築できます。顧客サイト全体のプラグインを1つのビューで一覧表示し、古いものを強調表示して、開発者に更新対象を選ばせることが可能です。

QAチームには、本番環境にアップデートを反映する前にテスト用にいくつかマークさせることもできます。また、非アクティブなプラグインをフィルタリングして直接削除することで、不要に膨らんだプラグインを整理することもできます。

pluginsエンドポイントは、以下のような具体的な情報を返します。

{
  "name": "akismet",
  "title": "Akismet Anti-Spam",
  "status": "active",
  "version": "1.0.0",
  "update": "available",
  "update_version": "1.0.1"
}

この情報を使って、好きなロジックを構築できます。

• サイトごとのプラグイン数を表示する
• バージョンのずれを検出する
• 複数の環境でアップデートを実行する
• このサイトには古いプラグインが4つある

新しいアドオンで多くのチームのプラグイン管理は解決できますが、APIなら可視化とカスタム自動化の幅が広がり、チームのワークスタイルに合うかもしれません。

キャッシュのクリア、PHPの再起動、本番環境へのプッシュ

キャッシュ削除やPHP再起動のエンドポイントは、Kinsta APIの中でも特に利用頻度が高いトップ3に入っており、その理由は明白です。

デプロイ直後にキャッシュを削除するのは、ほとんどの場合最初のステップです。PHPの再起動も同じく頻繁に行われます。どちらも「派手な」作業ではなく、チームが繰り返し行うものだからこそ、自動化すべき処理です。

もしチームがすでにSSH経由でGitを使ってKinstaにデプロイしているなら、これらのAPIコールをCIパイプラインに直接組み込むことができます。MyKinstaにログインする必要はなく、ワンクリックのクリーンプッシュで環境をすべてリセットできます。

以下はパイプラインの例です。

name: Deploy to Kinsta and clear cache

on:
  push:
    branches:
      - main

jobs:
  deploy:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Deploy through SSH
        uses: appleboy/[email protected]
        with:
          host: ${{ secrets.KINSTA_SERVER_IP }}
          username: ${{ secrets.KINSTA_USERNAME }}
          password: ${{ secrets.KINSTA_PASSWORD }}
          port: ${{ secrets.KINSTA_PORT }}
          script: |
            cd /www/your-site/public
            git fetch origin main
            git reset --hard origin/main

      - name: Clear Kinsta cache
        run: |
          curl -X POST https://api.kinsta.com/v2/environments/${{ secrets.KINSTA_ENV_ID }}/tools/clear-cache \
          -H "Authorization: Bearer ${{ secrets.KINSTA_API_KEY }}" \
          -H "Content-Type: application/json"

      - name: Restart PHP
        run: |
          curl -X POST https://api.kinsta.com/v2/environments/${{ secrets.KINSTA_ENV_ID }}/tools/restart-php \
          -H "Authorization: Bearer ${{ secrets.KINSTA_API_KEY }}" \
          -H "Content-Type: application/json"

これはシンプルながら非常に強力です。さらに発展させることもできます。

• 社内管理パネルに「キャッシュのクリア」ボタンを追加する
• Slack経由でキャッシュ削除を実行する（例：/cache-clear client-name）
• ステージングから本番へのデプロイフローに、キャッシュ削除とPHP再起動を組み込む

さらに、Push to Liveエンドポイントを使っている場合、面白い活用方法があります。APIはpush_files_option: 'SPECIFIC_FILES'を使った選択的ファイルプッシュをサポートしているため、すべてをプッシュする必要はありません。

その結果、プラグインやテーマの変更だけを反映するようにデプロイを調整できます。

{
  "source_env_id": "54fb80af-576c-4fdc-ba4f-b596c83f15a1",
  "target_env_id": "54fb80af-576c-4fdc-ba4f-b596c83f15a1",
  "push_db": true,
  "push_files": true,
  "run_search_and_replace": true,
  "push_files_option": "SPECIFIC_FILES",
  "file_list": [
    "wp-content/plugins",
    "wp-content/themes",
    "wp-content/uploads"
  ]
}

このような機能により、開発者は楽になり、顧客はよりスムーズに作業を進めることができます。

モニタリングやデバッグのためのログへのアクセス

Web制作会社として、あなたのチームは多くの顧客のサイトを管理しています。顧客が「サイトがダウンしている」と言う頃には、たいていしばらく壊れていることを、あなたはすでに知っています。

そこでログエンドポイントの出番です。顧客からの苦情を待つのではなく、API経由で直接ログを取得し、社内の管理画面に表示できます。さらに良いのは、異常を検知したときにSlackやメールでチームに通知するシンプルなアラートを用意できることです。

誰かが500エラーを報告するたびにMyKinstaを開く必要はありません。最新のエラーログやアクセスログを取得し、出力を解析して、チームがすでに作業している場所に結果を表示するだけです。

必要なのは、環境IDと、error、access、kinsta-cache-perfのようなログタイプだけです。返される行数を制限することもできます。

curl -i -X GET \
  'https://api.kinsta.com/v2/sites/environments/{env_id}/logs?file_name=error&lines=1000' \
  -H 'Authorization: Bearer '

返されるログはプレーンテキストなので、そこからワークフローに合わせた仕組みを自由に構築できます。

• Web制作会社の管理画面に、各顧客サイトの最新エラーログを表示する
• 500エラー、遅いクエリ、失敗したcronジョブを強調表示する
• エラーが急増したときにアラートをトリガーする
• 開発者がSlackで/show-logs client-xを入力すると、ライブのログ出力を即座に表示する

このような可視性を持つことで、顧客との通話中に「しまった」と思う瞬間をなくせます。

実例：SodはどのようにAPIを使用して400以上のサイトを管理しているか

実際にWeb制作会社がKinsta APIをこのように活用しているのか気になるかもしれませんが、実際に活用されています。

オーストラリア・メルボルンのフルサービスのWeb制作会社、Straight Out Digital（Sod）は400以上のWordPressサイトを管理しています。顧客数が急増したとき、手作業では追いつかなくなり、Kinsta APIを基盤に内部ツールを構築して、サイトのプロビジョニングからプラグイン更新までを自動化しました。

同社がKinsta APIを使っている具体例は次のとおりです。

• 顧客のオンボーディング時に新しいサイトを自動で立ち上げる
• 管理画面に入らず既存セットアップをクローンする
• ポートフォリオ全体の一括プラグインチェックと更新
• ログにエラーが出た際にアラートをトリガーする
• 顧客のチケットを待たずに問題を先回りして対処する

現在もMyKinstaを毎日利用していますが、APIのおかげで繰り返し作業を避けられています。彼らの言葉を借りれば…

Kinsta APIによって、サイトのプロビジョニングのような重要なプロセスを自動化する内部ツールを開発し、当社のWebサイト全体で一括操作を実行できるようになりました。

これは、こうしたワークフローが机上の空論ではないことの証拠です。SodのようなWeb制作会社はすでにAPIを活用しており、その結果として400サイトを超える規模に成長しています。

まとめ

複数のWordPressサイトを運営するWeb制作会社であれば、Kinsta APIは単なる便利な道具ではありません。時間を取り戻すための有効な手段です。

CIパイプラインに組み込むか、社内ツールから処理を起動するか、あるいは開発者の作業を楽にしたいだけでも、必要な要素はすでに揃っています。プロセスをゼロから作り直す必要はありません。チームの作業を最も遅らせている部分だけをつなぎ込めば十分です。

SodのようなWeb制作会社が示すとおり、規模が大きくなるほど効果は大きくなります。

KinstaのAPIドキュメントで可能なことを確認し、MyKinstaでAPIキーを生成し、Slackボットの構築、Git経由でのデプロイなど、ステップバイステップの解説をご覧ください。