Googleで優先する情報源に追加
WordPressサイトはこれまで、常に人間による利用を前提に設計されてきました。訪問者はページを開き、サイト内を閲覧したり、フォームに入力したり、ボタンをクリックしたり、アカウントを作成したりします。こうした操作の中心にあるのがブラウザであり、開発者も画面上で行われる操作を前提にサイトを構築してきました。
しかし、AIエージェントは必ずしも人間の訪問者と同じようにサイトを操作するわけではありません。ページや管理画面を開くことなく、情報を取得したり、機能を呼び出したり、タスクを実行したりすることができます。WordPressでは、このような使われ方に対応するため、Abilities APIやMCP Adapterなどを通じて、ソフトウェアがサイトの機能を直接検出し、利用できる仕組みの整備が進められています。
このようなやり取りが一般化しつつある今、開発者は人間だけでなく、AIエージェントによる利用も考慮する必要があります。人間とAIエージェントの両方を想定してWordPressを構築するとなると、API、権限、認証、パフォーマンス、さらには問題発生時の処理についても、これまでとは異なる視点で設計しなければなりません。この記事では、AIエージェントにも対応するWordPressサイト設計について掘り下げていきます。
AIエージェントと人間のWordPressの利用方法は異なる
私たちは、サイトに訪問すると、その場で状況を判断しながら操作を進めていきます。メニューを見て必要な項目を探したり、画面上の情報から操作方法を判断したり、説明を読み直したり、うまくいかなければ別のボタンを試したりできます。
AIエージェントには、このような柔軟性はありません。実行できる操作や入力形式が明確に定義され、認証方法が用意されていること、さらに返される情報を確実に解釈できることが重要になります。
そのため、WordPressのアーキテクチャを考えるうえで、これまで前提としてきたことの一部を見直す必要があります。
| 人間による操作 | AIエージェントによる操作 |
| ナビゲーションメニューやボタン | 利用可能な機能の検出 |
| フォーム | 構造化された入力とAPI |
| ログイン画面 | プログラムによる認証 |
| 画面上のフィードバック | 構造化されたレスポンスとエラー |
| ページビューとセッション | API呼び出しとツールの実行 |
また、AIエージェントとクローラーの違いも重要です。クローラーは主に情報の取得やインデックス作成を行いますが、AIエージェントはさらに一歩進んで、ユーザーに代わって操作を実行できます。在庫の確認、アカウント情報の取得、下書きの作成、データの送信、ワークフローの実行などがその例です。
ソフトウェアがコンテンツを読み取るだけでなく、実際に操作を行うようになれば、アーキテクチャの設計では権限や認証、エラー発生時の処理、各操作によって生じる影響まで考慮する必要があります。そのため、AIエージェントが利用しやすいサイトにするには、単に情報を見つけやすくするだけでは不十分です。AIエージェントがWordPressを安全かつ確実に操作できる仕組みを明確に設ける必要があります。
ページだけでなく「できること」を設計する
従来のウェブデザインでは、ユーザーの行動の流れをもとに構成されます。訪問者がページにアクセスし、リンクやボタンをクリックし、フォームに入力して、確認画面にたどり着くといった流れです。
AIエージェントの場合、このような流れをすべて省略することがあります。必要な機能に直接アクセスできれば、画面を見る必要はありません。
たとえば、ドキュメントの検索、在庫の確認、見積もり依頼の送信、下書きの作成などが挙げられます。人間が画面上で行う一連の操作をAIエージェントに再現させるのではなく、それぞれの操作をソフトウェアが理解して利用できるかたちで提供することができます。
WordPressのAbilities APIを使用すると、このような機能をよりわかりやすいかたちで外部に提供できます。外部ツールにページを操作させたり、HTMLから情報を取得させたりする代わりに、実行する操作、その操作に必要なデータ、返される結果、利用できるユーザーなどを直接定義できます。
ただし、すべてのボタンにAIエージェントから利用できる機能を用意する必要はありません。どの機能を外部から利用できるようにするのか、誰に利用を許可するのか、どのような制限を設けるのかを検討することが重要です。
そのため、開発時には新たに「このサイトでは、人間とAIエージェントにどのような操作を安全に許可できるか」という視点も必要になってきます。
認証と権限の重要性が高まる
AIエージェントがWordPress上で操作を実行できるようになると、重要なのは「接続できるか」ではなく、「何を許可するか」になります。
独自の認証情報や権限を使用して動作するソフトウェアが増えるにつれ、この違いはますます重要になります。CyberArkが2025年に実施したIdentity Security Landscape調査によると、68%の組織がAI向けのIDセキュリティ対策を導入していません。AIエージェントにアクセスを許可すること自体は簡単ですが、その権限を必要な範囲だけに制限するには、十分な検討が必要です。
AIエージェントなどのソフトウェアから利用できる機能を設計する際、開発者は以下の点を確認する必要があります。
- 誰がリクエストを送信しているのか
- 誰に代わって操作しているのか
- どの情報を読み取れるのか
- 何を変更できるのか
- どの操作に追加の承認が必要なのか
AIエージェントには、実行するタスクに必要な範囲だけアクセスを許可することが重要です。ドキュメントを検索するツールに投稿を編集する権限は必要ありません。また、下書きを作成するツールに、必ずしも公開権限まで与える必要はありません。アカウントの変更、コンテンツの削除、決済の処理など、影響の大きい操作には、より厳格な制限を設ける必要があります。
WordPress Abilities APIを使用すると、このような権限の範囲を設定しやすくなります。それぞれのAbilityに入力と出力を定義し、個別に権限チェックを設定できます。外部サービスに管理者権限を与え、必要な操作だけを行うことを前提とするよりも、細かくアクセスを制御できます。
基本となるのは、一般的なセキュリティ対策と変わりません。AIエージェントから送信されたデータは、WordPressで処理する前に検証する必要があります。また、認証情報をプロンプト、フロントエンドのコード、ログなどに含めることも避けるべきです。コストが大きい操作や、簡単には元に戻せない操作を実行する場合は、事前に人間による承認を挟むのが安全です。
1つのタスクを実行するためだけに、AIエージェントへWordPress全体への広範なアクセス権を与える必要はありません。必要な操作を実行できる最小限の権限だけを付与することが重要です。
AIエージェントの利用を想定したパフォーマンス設計
人間の訪問者は、自然なペースでサイトを閲覧します。ページを読み込み、内容を確認し、何かをクリックして、次のレスポンスを待ちます。一方、AIエージェントははるかに高速に動作します。必要な情報を集めたり、ツールを呼び出したり、結果を比較したりしながら複数のステップを処理するため、わずか数秒の間に複数のリクエストを送信することがあります。
AIエージェントを使用する場合でも、基本的なセキュリティ対策は変わりません。WordPressに送られるデータは引き続き検証する必要があり、認証情報をプロンプト、フロントエンドのコード、ログなどに含めることも避けるべきです。また、コストが大きい操作や簡単には元に戻せない変更を行う場合には、処理を続行する前に人間による確認を挟むことが重要です。
AIエージェントによる処理は、人間がサイトを操作する場合よりもWordPressに大きな負荷をかける可能性があります。そのため、不要な処理をできるだけ減らすことが重要です。たとえば、API呼び出しをまとめる、読み取り専用のレスポンスをキャッシュする、同時に処理するリクエスト数を制限する、時間のかかる処理をバックグラウンドで実行するといった方法があります。レート制限や適切なタイムアウトを設定すれば、1つの自動化された処理がリソースを占有し、他のユーザーに影響を与えることも防げます。
ポイントは、必要以上の処理をWordPressに行わせないことです。たとえば、AIエージェントが3つの情報を必要としている場合、それぞれを個別にリクエストしてその都度データベース処理を発生させるよりも、1つの適切に設計されたエンドポイントからまとめて取得する方が効率的です。
タイムアウトには注意が必要です。AIエージェントがレスポンスを受け取れなかったとしても、リクエスト自体は正常に処理されている可能性があります。同じリクエストを再送しても、単なる情報の取得であれば大きな問題にはなりません。しかし、最初のリクエストで何かを作成または変更していた場合は、二重に処理されるおそれがあります。そのため、再試行する前に、すでに処理が完了しているか確認できる仕組みが必要です。
AIを支えるインフラに求められる要件については、すでにさまざまな議論があります。ここで重要なのは、今後のパフォーマンス設計では、すべての操作が人間と同じ速度で行われることを前提にはできないという点です。
AIエージェントがWordPressを利用する新たなユーザーとなるにつれ、インフラには、機械によるアクセスが短時間に集中しても、同時にサイトを利用している人間のパフォーマンスに影響を与えない設計が求められます。
AIエージェントには予測可能なレスポンスと処理状況の可視化が必要
AIエージェントは、リクエストを送信するたびに、その結果を明確に把握できる必要があります。レスポンスが曖昧だと、処理がまだ続いているのか、失敗したのか、あるいは完了したもののレスポンスが返ってこなかったのかを判断できません。
複数のステップからなる処理では、さらに対応が難しくなります。途中で結果がはっきりしないと、AIエージェントが同じ処理を繰り返したり、次のステップに進んだり、前の処理が完了する前に別の処理を実行したりする可能性があります。
同じドキュメントを2回取得する程度であれば、大きな問題にはなりませんが、同じ注文を2回作成するとなれば話は別です。コンテンツの公開や削除についても同様です。リクエストを再送する前に、すでに何が実行されたのかを確認できる仕組みが必要になります。
Kinsta APIでは、時間のかかる一部の処理にオペレーションIDを使用しています。リクエストを処理が終わるまで待機させるのではなくIDを返し、ソフトウェア側からそのIDを使って、処理中なのか完了したのかを後から確認できます。
また、処理に問題が発生した際には、原因を特定できるだけの情報も必要です。最後に表示されるエラーメッセージだけでは、十分な情報が得られないことがあります。どのリクエストで処理が止まったのか、WordPressから別のサービスが呼び出されたのか、データベースで何が起きたのか、AIエージェントが同じリクエストを複数回送信していないかなどを確認する必要があります。
Kinsta APMやサーバーログを利用すると、このような処理を追跡できます。また、ステージング環境を利用すれば、AIエージェントによる処理を本番データに影響を与えることなく、より安全にテストできます。
人間がサイトを操作している場合、処理に問題があればすぐに気づくことができますし、エラーを目にしたユーザーから報告を受けることもあります。一方、AIエージェントの場合、複数の処理が自動で実行されるため、その途中で発生した問題を見落としやすくなります。処理結果を明確に返し、処理状況を追跡できるようにすることで、問題の発見と解決が容易になります。
サーバー環境にもAIエージェント向けのインターフェースを用意する
AIエージェントへの対応を考える際は、WordPressだけでなく、それを支えるサーバー環境も考慮する必要があります。
WordPressでは、Abilities APIやMCP Adapterを通じて、外部ツールからコンテンツや機能を利用できるようにすることができます。AIエージェントがデータを取得したり、コンテンツを作成したり、プラグインの処理を実行したりすることが可能です。一方、サーバー側では、通常であれば管理画面から行う操作をAPI経由で実行できます。
Kinsta APIを使用すると、サイトや環境に関する情報の取得、ドメインやキャッシュの管理など、さまざまなサーバー操作をプログラムから実行できます。これにより、WordPressそのものを超えたワークフローも構築できます。たとえば、操作を実行する前に環境の状態を確認したり、サーバー側の処理を実行したり、取得した情報をより大きな自動化ワークフローに組み込んだりすることが可能です。
Kinstaでは、Kinsta APIを利用したMCPサーバーの構築例もご紹介しています。これを利用すると、AIクライアントから一部のサーバー機能をツールとして使用可能です。環境の確認、キャッシュのクリア、サイトの複製、プラグイン情報の確認などを、操作のたびにMyKinstaを開くことなく実行できます。
ただし、AIエージェントにサーバーアカウント全体へのアクセスを許可する必要はありません。キャッシュのクリア、環境の確認、プラグイン情報の取得だけが必要であれば、それらの操作に必要な権限だけを与えるべきです。接続できるからといって、それ以上の権限を与えるメリットはありません。
MyKinstaは引き続き、設定の確認、トラブルシューティング、日常的なサイト管理タスクなど、人間が行う操作に使用できます。一方APIは、こうしたサーバー操作をデプロイプロセス、社内ツール、制作会社のワークフロー、AIシステムなど、別の仕組みと連携させる場合に役立ちます。
制作会社のアーキテクチャ設計にAIエージェントへの対応も取り入れる
現時点ですべてのWordPressプロジェクトにAIエージェントやMCPを導入する必要はありません。ただし、サイトの完成後にクライアントから導入を求められる可能性も考え、将来的な対応を難しくするような設計は避けておくのが賢明です。
サイトを新規構築または大幅にリニューアルする際には、以下の点を検討しておくとよいでしょう。
- 将来的に、顧客や従業員がAIエージェントに任せる可能性のある作業は何か
- AIエージェントなどのソフトウェアから、どのデータやサイト機能へのアクセスを許可するか
- 必ず人間の承認を必要とする操作は何か
- AIエージェントの認証と権限管理をどのように行うか
- 自動化されたアクセスが急増した場合にどう対応するか
- ワークフローに問題が発生した際、どのように検出して原因を特定するか
こうした検討事項は、プラグインの選定やAPI設計から、権限設定、サーバー環境まで、さまざまな判断に影響します。また、より細かな設計にも関係します。たとえば、特定の管理画面からしか実行できない処理よりも、別のシステムから直接呼び出せる機能として設計しておく方が、将来的に再利用しやすくなります。
Sodの導入事例では、このような柔軟な設計が実際にどのように活用されているかをご紹介しています。同社は400以上のWordPressサイトを管理しており、Kinsta APIを活用して、これまで手作業で管理する必要があったさまざまなタスクを自動化しています。
これはAIエージェントを使用したワークフローではありませんが、すべての操作を管理画面から行うのではなく、ソフトウェアからサーバー操作を実行できる仕組みを用意しておくことのメリットがよくわかる事例です。
こうした柔軟性は、クライアントのニーズが変化するにつれて、さらに重要になります。現在は社内向けの自動化として構築したワークフローでも、将来的にはAIアシスタントやMCPクライアント、その他のビジネスシステムと連携する可能性があります。必要な機能にアクセスするための明確なインターフェースと適切な権限設定がすでに用意されていれば、新たな仕組みとの連携も容易になります。
AIエージェントへの対応を考える際にも、同じことが言えます。現時点ですべてのワークフローを自動化する必要はありません。重要なのは、情報の取得や操作の実行、システムの管理を常に人間が行うことを前提としたサイト設計を避けることです。
サイトの設計段階からAIエージェントへの対応を考慮しておくことで、将来新たなワークフローを導入する際にも、サイト全体を一から設計し直すことなく柔軟に対応できるようになります。
人間と、人間に代わって操作するソフトウェアの両方を想定する
WordPressでは、これからもまず人間が使いやすいサイトを構築することが重要です。ページ、フォーム、ナビゲーション、優れたユーザー体験の必要性がなくなるわけではありません。ただし今後は、人間やソフトウェアがサイトを利用する方法が、それだけではなくなります。
WordPressの画面を人間が操作することなく処理が行われるケースも増えています。AIエージェントは情報を取得し、必要な操作を実行して、わずか数秒で次のステップへ進むことができます。そのため、それを支える仕組みがこれまで以上に重要になります。開発者は、AIエージェントがどの機能や情報にアクセスできるのか、どこまで権限を与えるのか、サイトがその処理負荷に対応できるのか、問題が発生した際にどこを確認すべきかを明確にしておく必要があります。
今すぐWordPressサイトをAIエージェント向けに作り直す必要はありませんが、今後もすべての操作が人間によるブラウザの利用から始まるとは限りません。KinstaのWordPress専用マネージドクラウドサーバーは、人間の訪問者だけでなく、増え続ける自動化ワークフローにも対応できるパフォーマンス、監視機能、各種ツールを提供します。
サイトを利用する顧客が人間であることは変わりありませんが、今後はその人に代わってソフトウェアがサイトを操作する場面が増えていくことが予想されます。
