Googleで優先する情報源に追加
これまで人の手で行われてきたWordPressの運用作業は、今後ますます自動化されていくことが予想されます。
デプロイ、アップデート、セキュリティ対応、インフラの変更など、今では一つひとつの工程を担当者が見守らなくても実行できるようになりました。しかし、いまだ解決されていないのが、どの工程に人の目による確認が必要なのかを判断することです。今回は、この課題について掘り下げていきます。
WordPressの運用では、特に注目したい5つの領域があります。Kinstaでは、提供する機能とインフラを通じて、すでにこの4つを考慮したサーバー環境を構築しています。
止まるべきタイミングを判断できないAIエージェントは、自動化のリスクに
AIエージェントは、指示された処理を最後まで実行しようとします。たとえば、WooCommerceのアップデートを本番環境に反映し、ビジュアルリグレッションテストを実行して問題がないことを確認し、キャッシュをクリアして、ログに成功と記録するところまで、一連のワークフローを自動で完了可能です。それでも後になって、買い物客から「決済ができない」という問い合わせが入るかもしれません。
一見すると、これはAIの問題のように思えますが、リグレッションテストでページのレイアウトだけを確認し、その裏側にある決済ゲートウェイとの連携を確認していなければ、不具合を見逃します。AIエージェントは与えられた役割を正しく果たしているだけで、それ以外に何を確認すべきかまでは判断できません。つまり、問題はAIそのものではなく、人間側のワークフロー設計にあります。
だからといって、自動化は避けるべきものではありません。必要な確認を行えるよう、ワークフローの途中に意図的に停止するポイントを設けることが重要です。WordPressのワークフローの多くは、AIエージェントが処理状況を説明し、人間の判断を仰ぐ工程を必要としません。しかし、複雑なワークフローなど、途中で人間による判断が欠かせないケースもあります。難しいのは、どのタイミングで人間が介入すべきかが必ずしも明確ではないことです。
Zylos ResearchによるAIエージェントから人間への引き継ぎパターンの分析によると、本番環境で運用されているAIでは、意思決定の約70〜80%が自動化され、残りは人間による確認を経る形に落ち着くとされています。
WordPressの運用でも、こうした役割分担を踏まえて、あらかじめ人間の判断が必要になる場面を整理できます。
- デプロイ：通常のファイル反映と、実際の注文データに影響するデータベース移行
- アップデート：リスクの低いプラグインの修正と、決済ゲートウェイや会員システムに影響する変更
- コンテンツ公開：予約投稿と、価格、法務、安全性に関わる重要な情報を含むコンテンツ
- セキュリティ対応：脅威の自動的な封じ込めと、何が原因だったのかを判断する作業
- インフラや請求に関する変更：使用量のアラートと、サイトのアップグレード、ダウングレード、移管の判断
このような役割分担は、単に「自動化できなかった作業を人間が担当する」という話ではありません。AIエージェントがこれまでに経験していない状況、たとえば元に戻せない変更や実際の取引に影響する処理ほど、判断を誤った場合の代償が大きくなります。
人間への引き継ぎを誤れば、自動化で削減した以上のコストがかかる
MITのNANDAの調査によると、企業による生成AIの試験導入の95%で、損益への明確な効果が確認されていません。その背景には、以下のようなパターンがあります。
- まずはワークフローの中でも簡単な作業の大部分を自動化する
- 残った作業への対応は後回しにする
- そのわずかに残った作業に大きなリスクが潜んでいることがわかり、結果的にそのコストを負担する
コンテンツ制作のワークフローで、ときどき人間による編集が必要になる程度であれば、多少の遅れは大きな問題にはなりません。たとえば、下書きの確認が1時間遅れても、それほど深刻な影響はないでしょう。しかし、デプロイのワークフローで実際の注文データが破損するとなれば話は別です。発生頻度が低くても、大きな損失につながる以下のようなミスがあります。
- 決済処理中にデータベース移行が失敗すると、単に注文処理が遅れるだけでなく、バックアップ取得後から障害発生までに入った注文が失われる
- 決済ゲートウェイに不具合があってもサイトへのアクセスが続き、問題に気づくまで売上を逃し続ける
- セキュリティ対応を誤ると、本来は封じ込められたはずのインシデントが攻撃そのものより長い障害につながる可能性がある
最新のある調査では、カスタマーエクスペリエンス（CX）部門の責任者の85%が、たった一つでも問題が未解決のまま残れば、顧客を失う可能性があると回答しています。できる限り自動化し、人間への引き継ぎを最小限に抑えるワークフローは、一見すると効率的で理想的に思えます。しかし、必要な場面で人間が介入できる仕組みがなければ、いずれ自動化だけでは解決できない問題が顧客に降りかかり、それを拾い上げる人もいないという状況が生まれます。
人間による判断が欠かせない5つのWordPress運用作業
基本となる考え方は、「元に戻せる作業は自動化し、それ以外は人間に引き継ぐ」です。元に戻せる変更（あるいは判断を誤っても影響が小さい変更）で、これまでにも同じパターンを処理した実績がある場合は、自動化に適しています。
一方、元に戻せない変更や、判断を誤った場合のコストが大きい変更、これまでにないパターンの処理は、人間に判断を委ねなければなりません。ここからは、WordPressの日常的な運用作業の大部分を占める5つの領域で、自動化と人間による判断をどのように使い分けるべきかを見ていきます。
1. デプロイ（ファイルの反映は自動化し、データベース移行は人間が判断）
コンテンツサイトへのファイルの反映であれば、何か問題が起きても比較的簡単に対処できます。バックアップを復元してもう一度反映すればよく、数分程度で済みます。一方、稼働中のWooCommerceサイトで決済処理中にデータベース移行を行う場合は事情が異なります。バックアップの取得後から移行に失敗するまでに入った注文は、復元したデータには含まれません。そのため、ロールバックしても失われた注文を元に戻すことはできません。
Kinstaの選択的プッシュ機能では、このようなリスクを抑えながら変更を反映できます。環境全体を反映するのではなく、ファイルのみ、データベースのみ、またはその両方を選択して反映可能です。また、反映を実行する前には、反映先の環境のバックアップが自動的に作成されます。
これにより、自動化の仕組み側でも、通常のファイル同期と、人間による確認が必要なデータベース移行を区別するために必要な情報を得ることができます。
Kinsta APIを使用してデプロイを行う場合は、以下の流れで処理することで安全性を高めることができます。
POST/sites/environments/{env_id}/manual-backups：本番環境に変更を加える前に、実行時刻が記録されたバックアップを作成PUT/sites/{site_id}/environments：ステージング環境から本番環境に変更を反映POST/sites/cdn/clear-cache：反映後にCDNキャッシュをクリア
各処理ではoperation_idが返され、スクリプトはその処理が完了したことを確認してから次のステップに進みます。いずれかの処理に失敗した場合は、そのまま処理を続行して想定外の状態に陥ることがないよう、その時点でワークフローを停止。各エンドポイントを使用する一連の流れについては、制作会社がCI/CDパイプラインに組み込む例とあわせて、こちらのドキュメントで詳しくご紹介しています。
Kinstaを利用するエージェンシーSodは、こうした区別をワークフローに取り入れることの重要性をよく理解しています。メルボルンを拠点とする同社は400以上のWordPressサイトを管理しており、すべてのサイトを一律に扱うのをやめたことで、より大きな効果を得られるようになったと言います。
Kinsta APIを活用することで、サイトのプロビジョニングなどの重要なプロセスを自動化し、複数のサイトに対して一括操作を実行する社内ツールを開発できるようになりました。これが大幅な時間と労力の削減につながっています
2. アップデート（パッチ適用は自動化し、決済ゲートウェイは人間が確認）
サイトで発生するエラーの多くは、それほど大きなリスクを伴いません。たとえば、一般的な企業サイトでプラグインを更新してレイアウトが崩れても、目で確認して修正できます。注意が必要なのは、決済ゲートウェイや会員システムなど、表からは見えにくい機能です。決済ページが一見正常に表示されていても、裏側では取引処理が機能しなくなっている可能性があり、こうした問題は見落としやすくなります。
そこで活用できるのが、Kinsta自動アップデートアドオンです。プラグインとテーマをアップデートするスケジュールと時間帯を設定でき、各更新の前後にサイトのスクリーンショットを自動で取得して比較します。表示上の変化が検出された場合には、アップデート前のバックアップが自動的に復元されます。
しかし、ビジュアルテストで確認できる問題には限界があります。WP Umbrellaは、アップデート機能に加えて、Kinstaのインフラを活用して独自の監視体制を構築しています。
Kinstaのサポートに問い合わせたところ、わずか数時間で問題が解決。これまで複数のサーバーでサポートを利用してきましたが、これほどスムーズに解決することはほぼありませんでした
同社は現在、自動化で拾いきれない問題が発生した際に、人間が迅速に対応することがどれほど大きな違いを生むのかを、明確なデータとして把握しています。
3. コンテンツ公開（スケジュールは自動化し、内容は人間が判断）
コンテンツ公開のワークフローでは、予約投稿、SEOメタデータの設定、公開後のキャッシュウォーミング（キャッシュの事前生成）、SNSへの投稿などを、人間が介入することなく自動化できます。注意が必要なのは、内容に誤りがあった場合に、現実的な影響が生じるコンテンツです。
たとえば、プラグインのインストール方法を説明するブログ記事に多少の誤りがあっても、影響は比較的小さいことが予想されます。しかし、料金を記載する記事、医療に関するアドバイス、法的要件の解説、具体的な日付を伴う製品リリースの記事は、AIを活用して作成した下書きに誤った料金や古い安全情報が含まれたまま公開されれば、すぐに具体的な問題につながる可能性があります。
人間による確認が必要かどうかを判断する基準は、「AIが書いたかどうか」ではなく、「内容に誤りがあった場合に影響が生じるかどうか」です。料金の変更、YMYL（健康、金融、法律）に関するトピック、日付が決まっている製品リリース、セキュリティに関する注意喚起などは、コンテンツの作成方法にかかわらず、公開前に人間が確認すべきものです。
公開までの流れを自動化することは、効率化につながるものの、何をその流れに乗せてよいかという判断まで自動化してしまうと、本来なら防げたはずの問題を、大規模に公開してしまうことになりかねません。
4. セキュリティ（脅威の封じ込めは自動化し、その後の対応は人間が判断）
サイトやサーバーが攻撃を受けている最中は、迅速な対応が欠かせません。一方、攻撃を封じ込めた後にどう対応するかについては、状況に応じた判断が必要です。この2つでは、求められる対応やプロセスが異なります。
たとえば、悪意があると確認されたIPアドレスをブロックする場合、取るべき対応は基本的に変わらないため、AIエージェントに任せても問題ありません。しかし、トラフィックの急増が競合他社による価格情報のスクレイピングなのか、連携機能の不具合なのか、AIクローラーによるものなのか、あるいはアクセスを許可すべき別のトラフィックなのかを判断するには、自動化されたシステムだけでは得られない背景情報が必要です。
Kinstaのボット対策機能は、受信トラフィックをリアルタイムで分類し、サイトごと、または複数のサイトに一括で適用できる4段階の対策レベルによって悪意のあるアクセスを防ぎます。また、AIクローラーだけをブロックする設定も用意されており、Googlebotなどの検証済みボットは常にそのまま通過します。これにより、AIトラフィックへの対応によって、検索エンジンでのサイトの表示機会まで損なってしまうことを防げます。
ただし、この機能だけでは、通常とは異なるパターンを詳しく調査すべきかどうかまでは判断できません。そこで必要になるのが、人間による判断です。
Kinstaを利用するAdapting Socialは、脅威を適切に封じ込められるようになったことで、問題が起きるたびに対応に追われる時間を減らすことができました。
卓越性への取り組みに見合い、クライアントに自信を持って提供できるサーバーを探していました。信頼性が高く、パフォーマンスに優れ、クライアントサイトを安全かつ確実に保護してくれるサーバーを探し求めた結果、Kinstaにたどり着きました
5. インフラと請求（アラートは自動化し、対応は人間が判断）
5つの領域の中でも、インフラや請求に関する変更は判断の余地が少ないからこそ、誤った対応が大きな問題につながりやすい領域です。問題の検出そのものは自動化しても問題ありませんが、検出後の対応まで自動化するのは、多くの場合リスクを伴います。サイトの移行やDNSの変更をはじめ、本番サイトのトラフィックに影響する作業の多くは、キャッシュのクリアのように簡単に元に戻すことができません。
Kinstaのプランは、このような運用を無理なく行える仕組みになっています。
- 訪問数、ストレージ容量、帯域幅の上限に対して使用量が80%と100%に達すると、超過料金が発生する前に使用量の通知を送信
- プランのアップグレード、ディスク容量アドオンの追加、一時的な超過料金の許容については、予算や利用状況に応じて判断可能
- プランの変更、企業単位のユーザー追加、請求先情報の更新は、アカウントにアクセスできる他のユーザーの権限にかかわらず、企業の所有者または企業の管理者のみ実行可能
最後の仕組みは、これまで見てきた「自動化し、必要に応じて人間に判断を委ねる」という考え方を、ワークフローではなく権限管理に当てはめたものです。使用量がしきい値を超えたときにたまたまログインしていた人ではなく、アカウントに責任を持つ人が費用に関する判断を下します。数百ものクライアント環境を管理する制作会社にとって、こうした仕組みは、予期しない使用量の急増がクライアントとのトラブルに発展するのを防ぐうえで役立ちます。
アラートだけでなく、判断に必要な情報を伝える
人間への引き継ぎで「何を確認する必要があるか」しか伝えなければ、担当者は判断を下す前に、何が起きたのかを一から調べて把握しなければなりません。これでは余計な時間がかかり、対応の遅れにつながります。
スムーズに引き継ぐには、担当者が一から状況を確認しなくても済むよう、次の3つの情報をあらかじめ共有しておくことが重要です。
- ワークフローが停止した時点で何を実行していたのか：処理全体の流れを担当者が推測する手間を省く
- 何が原因で停止したのか：ログファイルを調べなくてもわかるよう、具体的な理由をわかりやすく提示
- 人間による判断を待っている状態なのか：漠然とした問題として提示するのではなく、何を判断すればよいのかを一つの明確な選択肢として提示
停止したデプロイを引き継ぐ担当者が、保留中の反映、その反映先の環境、処理を停止させたリグレッションテストの結果を、一箇所ですべて確認できる状態が理想です。また、承認後は最初からやり直すのではなく、停止した地点からそのままワークフローを再開できるようにします。
Kinsta APIを使用したデプロイであれば、この時点ですでにバックアップが作成され、ステージング環境からのプッシュも準備されています。判断する担当者は、パイプライン全体を確認する必要がなく、目の前の一つの判断に集中することができます。
Kinstaのアクティビティログや「ユーザーの活動」画面にも、規模は異なるものの、同じ考え方が反映されています。それぞれの操作について、誰が、いつ実行し、無事に完了したかどうかを確認できます。
また、各項目の詳細を開くと、その操作についてサポートに直接問い合わせることも可能です。問題の経緯を一から説明し、担当者が状況を整理し直す必要はありません。
予測できる処理は自動化し、それ以外は人間が判断
WordPressのワークフローでは、ほぼあらゆる作業を自動化できるため、「この作業を自動化できるかどうか」だけを考える必要はありません。それよりも重要なのは、ワークフローが想定外の状況に直面したときに、どのように対応するかです。
まず、元に戻せる作業を自動化し、ワークフローの大部分を自動で実行できるようにします。そのうえで、人間に判断を委ねる基準を明確に定め、引き継ぎの際には判断に必要な情報もあわせて渡します。そうすることで、担当者は一から状況を把握することなく、すぐに対応に移ることができます。
Kinsta APIの詳細を確認して、人間に引き継ぐポイントをあらかじめ設定したワークフローをぜひ構築してみてください。また、数十のクライアントサイトをまとめて管理する組織には、Web制作会社向けプランがおすすめです。
