Googleで優先する情報源に追加
最近のAIエージェントは、質問に答えるだけでなく、実際の作業も行えるようになっています。
WordPressサイトであれば、ステージング環境のセットアップ、プラグインの更新、各種チェック、承認された変更の本番環境への反映、キャッシュのクリア、実行内容の記録などを任せられます。これまで開発者やサイト管理者が手作業で対応してきた定型的なタスクをエージェントに任せ、重要な判断は引き続き人間が行うという使い方ができます。
ただし、AIシステムに本番環境への無制限のアクセスを与えるわけではありません。AIエージェントがアクセスできる範囲や実行できる操作、人間の承認が必要になるタイミングをあらかじめ設定し、その範囲内でタスクを任せます。
このように、人間がすべての作業を手動で行うのではなく、どこまで自動化するかを人間が決めたうえで、反復的なタスクをAIエージェントに任せるのが「人間の監督下での自動化」です。今回はこのトピックを掘り下げていきます。
AIエージェントは「回答」から「実行」する存在へ
すでに多くの企業や組織で、AIが業務のアシスタントとして活用されています。質問への回答、文章の作成、問題のトラブルシューティングなどには役立ちますが、その情報をもとに実際の作業を行うのは人間です。
AIエージェントでは、この関係が変わります。提案や回答だけで終わるのではなく、連携したツールを使用して、実際にタスクを実行できます。情報を収集し、あらかじめ定められたルールに従って判断を下し、承認された操作を実行して、その結果を報告するという一連の流れを担います。
Gartnerは、このようなAI活用が急速に広がると予測しています。2028年までに、従業員の業務を単に支援するツールよりも、ワークフローの成果に責任を持つプラットフォームを選ぶ企業が半数を超えるとしており、人間がすべての手順を自らこなすのではなく、自分たちに代わって作業を実行するシステムを監督する形へと移行していくと考えられています。
WordPressにも、こうした変化を支える仕組みがすでに登場しています。Abilities APIを使用すると、WordPressコア、プラグイン、テーマで実行できる操作と、その入力、出力、権限を共通の形式で定義できます。さらにWordPress MCP Adapterを使用することで、選択した操作をAIエージェントが利用可能なツールとして公開し、エージェントから実行できるようになります。
もちろん、WordPressのあらゆる作業を自動化すべきということではありませんが、技術的に可能な範囲は大きく広がります。AIが開発者に作業方法を説明するだけでなく、適切なアクセス権限を与えることで、その作業の一部を実際に担えるようになります。
そこで重要になってくるのが、「サイト運営のどの作業をAIエージェントに任せるべきか」という点です。
AIエージェントを活用したサイト運用
AIエージェントをサイト運用にどう活用できるのかをイメージするには、WordPressサイトで日常的に行われている業務を考えるとわかりやすいです。メンテナンス、デプロイ、トラブルシューティング、管理業務などには、AIエージェントに任せられる作業が多数あります。
メンテナンスとアップデート
プラグインやテーマのメンテナンスは、AIエージェントを活用しやすい領域の一つです。各サイトを手作業で確認する代わりに、エージェントに利用可能なアップデートを検出させ、対応が必要なものを選別し、承認済みのアップデートの適用、動作確認、結果の報告まで任せることができます。
リスクの高いアップデートについては、ステージング環境で作業を行うように設定することも可能です。テストに失敗した場合は、そのまま処理を進めるのではなく、問題を報告したり、変更をロールバックしたりできます。
こうした仕組みの一部は、AIを使わずともすでに実現されています。Kinsta自動アップデートアドオンでは、更新前に自動でバックアップを作成し、プラグインやテーマを更新した後、更新前後のスクリーンショットを比較。ビジュアルテストで問題が検出された場合には、バックアップが復元されます。
AIエージェントを活用すれば、このような自動化された処理を複数のサイトにまたがって管理し、人間による対応が必要な場面を判断することもできます。
ステージングとデプロイ
デプロイにも、繰り返し行う一連の作業があります。たとえば、ステージング環境の作成、承認済みの変更の適用、テストの実行、結果の収集、本番環境への反映準備までをエージェントに任せ、最後に開発者が結果を確認して本番環境へのデプロイを承認する、といった流れが考えられます。
Kinsta APIでは、こうしたサーバー関連の操作の一部をプログラムから実行できます。APIを通じて、ステージング環境の作成、ステージング環境から本番環境への反映、サイトやCDNのキャッシュクリア、プラグインやテーマの更新、時間のかかる処理の進捗確認などを行えます。
これらを組み合わせれば、定型的な処理はエージェントに任せながら、本番環境に変更を反映するかどうかは開発者が判断するというワークフローを構築できます。
パフォーマンスとトラブルシューティング
サイトの表示が遅くなったり、エラーが発生したりした場合、まずは原因を特定しなければなりません。何が変わったのかを把握するため、アクセス解析、ログ、最近のアップデート、キャッシュの状況、リソース使用量などを確認することになります。
AIエージェントを使えば、こうした情報の多くをあらかじめ収集することができます。
たとえばKinsta APIでは、サイトのアクセス解析データやサーバーログを自動で取得可能です。分析関連のエンドポイントでは、訪問数、帯域幅、レスポンスコード、アクセス元の地域などのトラフィックデータを、ログ関連のエンドポイントでは、エラーログ、アクセスログ、キャッシュパフォーマンスに関するログを取得できます。
エージェントはこれらの情報をまとめて分析し、考えられる原因を絞り込んだうえで、次に取るべき対応を提案したり、あらかじめ許可されたリスクの低い操作を実行したりできます。
コンテンツと管理業務
同じ仕組みは、WordPress内の作業にも活用できます。コンテンツ更新の準備、クライアント向けレポートに必要な情報の収集、あらかじめ指定された設定の変更、WordPressのツールやAPIを通じた定型的な管理業務などをエージェントに任せることができます。
そのために、エージェントにサイト全体の操作権限を与える必要はありません。まずはこれまで手作業で行っていた個々の工程をエージェントが実行できるタスクに置き換え、それぞれについてどこまでの操作を許可するかを決めることが現実的です。
自動化＝完全な自律化ではない
注意したいのは、「手作業を続けるか、AIエージェントにすべての権限を与えるか」の二択ではないということです。リスクに応じて人間が関与するポイントを残しながら、段階的に自動化の範囲を広げることが可能です。
たとえば、以下のような段階に分けて考えてみます。
- 確認：エージェントが情報を取得し、確認した内容を報告する
- 提案：あらかじめ設定されたルールや取得したデータをもとに、次の対応を提案する
- 準備：ステージング環境の作成やステージング環境での変更など、元に戻せる作業を行う
- 承認後に実行：人間が内容を確認して承認した場合にのみ、次の操作を実行する
- ルールの範囲内で実行：明確に定められた範囲内であれば、リスクの低いタスクを自律的に実行する
自動化の難易度は、タスクによって異なります。アクセス解析データの取得や古いプラグインの検出であればリスクは比較的低い一方、本番環境へのコードの反映やバックアップからの復元となれば話は別です。このような操作は、実行前に人間が確認する運用が適しています。
AIエージェントにあらゆる状況への対応を任せる必要はありません。どのタスクを任せるのか、どの時点で処理を止めて人間に引き継ぐのかを明確にしておくことが重要です。
まずは定型的なタスクから自動化し、影響の大きい操作には人間が関与する形が現実的です。ークフローの信頼性が高まってきたら、エージェントに任せる範囲をどこまで広げるかを検討することができます。
自動化が進むほど重要になる安全対策
AIツールから誤った回答が返ってくることと、AIエージェントが本番環境に誤った変更を加えることでは、影響の大きさが異なります。
エージェントに任せる作業が増えるほど、アクセス権限の適切な管理が重要になります。
各エージェントには、その役割に必要な権限だけを与えます。アクセス解析データを取得するだけなら、DNSを操作する権限は必要ありません。プラグインの更新状況を確認するだけなら、サイトの削除やユーザー管理の権限は不要です。アクセスできる範囲を必要最小限に抑えることで、問題が発生した場合の影響も抑えられます。
また、リスクの高い操作には、人間による承認を挟むことも欠かせません。本番環境へのデプロイ、バックアップからの復元、DNSの変更、ユーザー管理など、サイトダウンやデータ損失、意図しないサイト上の変更につながる可能性がある操作がこれに該当します。
万が一問題が発生した場合は、変更を元に戻せる仕組みも必要になります。ステージング環境、バックアップ、テスト、ロールバックの手順を整えておくことで、問題が発生した際に対応しやすくなります。エージェントに任せる範囲が広がるほど、こうした安全対策の重要性も増します。
重要なのは、エージェントが常に正しく動作することを前提にするのではなく、問題が起きてもすぐに検出し、可能な限り簡単に元の状態へ戻せる仕組みを整えておくことです。
エージェントに作業を任せるなら、実行内容を把握できる仕組みも必要
自動化が進んでも、実行内容を把握する必要性が下がるわけではなく、むしろその重要性は高まります。
開発者が手作業で変更を行う場合は通常、何をなぜ変更したのかを本人が把握しています。一方、エージェントがワークフローの一部を担うようになると、後から一連の処理をたどらなくても、何が行われたのかをチームが確認できる仕組みが必要です。
少なくとも、以下の点を確認できるようにしておく必要があります。
- どのような操作が実行されたか
- 何をきっかけに実行されたか
- どのサイトや環境が対象になったか
- 正常に完了したか
- 何が変更されたか
- 変更を元に戻せるか
Kinstaには、こうした情報を確認するための仕組みがあります。MyKinstaのアクティビティログには、アカウントやサイトで実行された操作に加え、実行者、実行日時、成否などが記録されます。またKinsta APIからも企業のアクティビティログを簡単に取得でき、サイト、ユーザー、カテゴリ、使用されたAPIキーなどで絞り込むことができます。
アクセス解析データやログからは、さらに詳しい状況を把握可能です。Kinsta APIでは、サイトのアクセス解析データ、バックアップ、サイトログを取得できるため、自動化されたワークフローでも、チームが問題の調査に使用する情報を活用できます。
より複雑なパフォーマンス問題の調査には、Kinsta APMが便利です。WordPressで処理に時間がかかっているリクエストを、PHPプロセス、データベースクエリ、プラグイン、フック、外部リクエストなどに分けて詳しく確認できます。
エージェントに任せる作業が増えれば、人間が直接操作する機会は減っていきます。それでも、エージェントが何を行ったのかを把握し、問題をすばやく発見して、必要に応じて人間が対応できるだけの情報は欠かせません。
APIがサイト運用の実行基盤に
AIエージェントがサイトを運用するには、管理対象のシステムと確実にやり取りできる仕組みが必要です。サイト運用では、主にAPIなどの構造化されたインターフェースがその役割を担います。
これまでのワークフローが、「人間 → ダッシュボード → 操作」だったとすれば、AIエージェントを活用する場合は、「人間 → エージェント → APIまたはツール → 操作 → 結果 → 人間による確認」という流れになります。
ダッシュボードが不要になるわけではありませんが、すべての作業をダッシュボード上で行う必要はなくなります。
Kinsta APIは、サイトの作成や複製、ステージング環境の作成、本番環境への反映、プラグインやテーマの更新、キャッシュのクリア、バックアップの管理、アクセス解析データやログの取得、ドメインの管理、各種環境設定の変更など、WordPressサイトのあらゆる運用操作に対応しています。
そのため、エージェント向けにサーバー操作の仕組みを一から用意する必要はありません。開発者がスクリプトや外部サービスとの連携、その他の自動化に利用しているAPIを、エージェントからも活用できます。
Kinsta APIと連携するMCPサーバーを使用した例はこちらでご紹介しています。この例では、AIアシスタントがMCPサーバーから提供されるツールを通じて、WordPressサイトの一覧取得、環境情報の確認、キャッシュのクリアなどを行います。エージェントが利用できるツールはチーム側で制御でき、操作の実行には明示的な承認が必要になる仕組みです。
ここで重要なのは、APIとエージェントの役割の違いです。APIが実際の操作を行うための基盤となり、エージェントはそのAPIをいつ、どのように利用するかを柔軟に判断します。
プログラムから実行できるサイト運用の操作が増えれば、メンバーが毎回ダッシュボードを開いて、一つひとつ操作する必要も減っていきます。あらかじめ決めた範囲の作業はエージェントに任せつつ、MyKinstaは直接の管理や確認、必要に応じた対応に引き続き利用できます。
AIエージェントが制作会社のサービス提供をどう変えるか
制作会社にとって、AIエージェントがもたらす最も大きな変化は、技術面ではなく業務の進め方にあるかもしれません。
日常的なメンテナンスやレポート作成をエージェントに任せることで、制作会社の負担を軽減できます。とはいえ、もちろん開発者やクライアント対応を担うチームが不要になるわけではありません。変わるのは、時間の使い方です。
すべての工程を手作業で進める代わりに、ワークフローそのものの設計により多くの時間を使えるようになります。どのタスクをエージェントに任せるのか、どのような条件を満たす必要があるのか、どこで処理を止めるのか、どのタイミングで人間が対応するのかを決定します。
その結果、以下のような人間の判断が必要な業務に、より多くの時間を充てられます。
- ワークフローの設計
- 自動化で想定外の問題が発生した際の対応
- アーキテクチャやパフォーマンスに関する判断
- セキュリティとアクセス権限の管理
- 複雑な問題のトラブルシューティング
- クライアントとの優先事項や今後の方針の検討
自動化は、メンテナンスサービスの提供方法にも変化をもたらします。制作会社では、定期的な更新やチェック、レポート作成など、クライアントからは見えにくい作業にも多くの時間を費やしています。こうしたタスクをエージェントに安全に任せられるようになれば、成果、対応スピード、安定性、管理するサイト全体の健全性などに、より多くのリソースを割けます。
さらに、事業を拡大しやすくなるというメリットも挙げられます。新規クライアントが増えるたびに同じ量の定型作業を増やすことなく、より多くのサイトを管理できるようになります。開発者は複雑な問題により多くの時間を使えるようになり、制作会社は日々のメンテナンス業務を同じ割合で増やすことなく、より積極的なサポートを提供できます。
そこで制作会社にとって考えたいのが、「管理するサイトが2倍になっても、定型作業を2倍に増やす必要がなくなったら、サービスの提供方法はどう変わるのか」という点です。
単に同じ仕事をより少ない人数でこなすという話ではなく、定型業務に費やす時間を減らし、判断が求められる意思決定や想定外の問題への対応、クライアントとのやり取りに、より多くの時間を使えるようになるということです。
将来を予測せず、今からAIエージェントに備える
AIエージェントを活用したサイト運用に備えるために、現在のワークフローを大きく変える必要はありません。まずは既存のプロセスを見直し、それぞれの手順をより明確かつ安全で、自動化しやすい形に整えることから始めてみてください。
具体的には、以下の点を検討できます。
- タスクをリスク別に分類する：エージェントだけで実行できるタスクと、人間による承認が必要なタスクを分ける
- APIが利用できるか確認する：システムがAPIを提供していれば、タスクを自動化しやすくなる
- ステージングとロールバックの仕組みを整える：エージェントが安全に変更を加えられる環境と、問題が起きた場合に確実に元に戻せる手段を用意する
- 権限を整理する：ワークフローの各工程で使用するアカウントや認証情報、システムと、それぞれのアクセス権限を把握する
- 実行内容を記録する：何がいつ変更されたのか、問題が発生した場合にどこを確認すればよいのかを社内で把握できるようにする
- 小さなタスクから始める：最初からメンテナンス全体を任せるのではなく、まずは複数サイトの古いプラグインを検出するといった、範囲の限られたタスクから始める
これらは、AIエージェントが完全に自律して動けるようになるのを待たなくても実践可能です。現在のサイト運用を自動化・管理しやすくすると同時に、AIエージェントを活用したワークフローが発展した際の選択肢を広げることにもつながります。
Kinstaではすでに、APIや各種自動化機能を通じてこうしたワークフローの多くを実現可能です。今ある仕組みを活用することで、AIエージェントを取り入れたサイト運用に向けた準備を今から進めることができます。
サイト運用の主体はこれからも人間
忘れてはいけないのは、AIエージェントに任せられる定型業務が増えても、最終的な判断と責任を担うのは人間だということです。
開発者がアーキテクチャについて判断し、制作会社が各クライアントにとって何が重要かを把握することに変わりはありません。どのタイミングで人間が介入するのか、どこまでのリスクを許容するのか、ワークフローが想定どおりに進まなかった場合にどう対応するのかも、チームで判断します。
変わるのは、日々のサイト運用で人間が手作業で行う部分です。意思決定を行い、その結果に責任を持つのは引き続きチームですが、その間に発生する作業の多くをソフトウェアに任せられるようになります。
今後、サイト運用の実作業を担うのはAIエージェントになるかもしれません。より大きな変化は、チームがサイトを直接操作することに費やす時間が減り、「サイトをどのように運用するか」を考えることに、より多くの時間を使えるようになることです。
