WordPressサブディレクトリ環境でプラグイン管理画面が404になる原因と対処
WordPress をサブディレクトリに置いている環境で、一部プラグインの管理画面にアクセスすると「ページが見つかりません（404）」になる。これはプラグイン内部で作られた管理画面の URL が、実際のディレクトリ構造と合っていないのが主な原因だ。プラグインの更新で修正されることが多く、一時的に URL へ正しいパスを手動で加えればすぐに操作を再開できる。
なぜ管理画面のプラグインページが404になるのか
WordPress の管理画面は通常 /wp-admin/ で始まるが、Bedrock（roots.io スタック）のようなカスタム構成では、コアファイルを /wp/ の下に配置する。管理画面の URL は /wp/wp-admin/ のようにサブディレクトリが一段深くなる。ここで、プラグインが管理画面へのリンクを作る際に「/wp-admin/ はルート直下にある」という前提でコードを書いていると、リンク先が https://example.com/wp-admin/... のようにサブディレクトリを反映しない形になり、フロントエンドで処理されて結果的に404になる。
これはコアファイルの場所を変更していない標準的なインストールでは表面化しない。Bedrock や独自に /cms/ などへ配置を変えているサイトで、かつプラグインが管理画面のパスをハードコード（直書き）している場合に限って起こる。エラーログには何も残らず、ただ「ページが見つかりません」と表示されるため、原因の特定に手間取ることが多い。
上記デモのとおり、プラグインが出力したパスに /wp/ が1つ欠けているために「そんなページはフロントエンドに存在しない」と判断され、404 が返っている。見た目はありふれた存在しないページへのアクセスと変わらず、管理画面の一部だけが突然消えたように感じる。
サブディレクトリ環境で発生する404の一時的な回避策
プラグインのアップデートを待たずに、今すぐ該当画面を操作したい場合は、ブラウザのアドレスバーで404になった URL を直接編集する。たとえば /wp-admin/ の直前に、自分の環境で実際に使っているサブディレクトリ名（Bedrock なら /wp/）を挿入して再度アクセスすれば、多くの場合そのまま画面が開く。修正後の正しいパスは /wp/wp-admin/admin.php?page=... の形になる。
この操作はあくまで一時しのぎで、管理画面内の他のリンクも同じ問題を抱えている可能性がある。ページを移動するたびに手動で URL を直すのは現実的ではないため、根本的な解決にはプラグインの修正が必要になる。
プラグインのアップデートで完全に解決する
この種の不具合は、プラグインが WordPress 標準の関数（admin_url() など）を使わずにパスを決め打ちで書いてしまったために起こる。開発者がこの問題に気づけば、次のバージョンで修正されるのが一般的だ。実際、今回の事例の Milo Subscriptions でも、内部の管理画面リンクを WordPress が返す正しい URL から組み立て直す修正がバージョン 1.8.7 で適用された。まずは管理画面の「プラグイン」から当該プラグインの更新がないか確認し、最新版が提供されていれば即座に適用する。
更新がすぐに提供されていない場合でも、問題が発見された後のバージョンでは修正されていることが多い。プラグインの公式ページの「Changelog（変更履歴）」に “Fix admin URLs on subdirectory installs” のような記載があれば、それを当てるだけで解決する。
恒久的な修正のためにプラグイン開発者へ報告する
まだ修正されていないプラグインで同じ症状が出るなら、サポートフォーラムや公式リポジトリの Issues で「サブディレクトリ構成だと管理画面のリンクが404になる」と具体的に伝えるのが最も建設的だ。報告の際は、自分の WordPress が /wp/ や /cms/ などのサブディレクトリにインストールされていること、問題が起こる画面の URL、使っているテーマや主要プラグインのバージョンを添えると、開発者が原因を特定しやすい。サブディレクトリ環境に限ったバグはテストで見落とされやすいため、利用者からの報告がなければ長期間放置される可能性がある。
よくある質問
サブディレクトリへ WordPress をインストールするのは特別なのか
標準的な構成であっても、WordPress 本体を /wp/ や /cms/ といったサブディレクトリに置くことは公式にも認められた設定だ。Bedrock や一部のセキュリティ寄りのスタックは、コアファイルをルートから分離する目的でこの構造を採用している。ただし、プラグインやテーマの開発者が標準構成だけを想定してテストしていると、今回のようなパス解決のミスが残りやすい。
サブディレクトリ環境だと他にどんな不具合が起きるのか
管理画面のリンク切れ以外にも、REST API や Ajax のエンドポイントが見つからずに動作が止まるケースがある。たとえば画像の一括処理やリアルタイム検索が動かなくなることがある。いずれも WordPress が提供する URL 取得関数（rest_url() や admin_url()）を使わずにパスを直書きしていることが原因だ。
自分でプラグインのコードを修正してもよいのか
管理画面のリンクをすぐに直す必要があるなら、プラグインの該当ファイルを子テーマやカスタムプラグインで上書きできれば対処できる。ただし、元のプラグインが更新されると上書きが無効になるため、恒久的な対応としては推奨しない。一時しのぎと割り切ったうえで、開発者へのフィードバックとセットで行うのが現実的だ。
Bedrock 以外の構成でも同じ問題は起こるのか
WordPress を /wp/ 以外の任意のディレクトリ（/cms/ /admin/ など）に配置している場合、まったく同じ仕組みで発生する。また、マルチサイトのサブディレクトリ構成でも、特定の管理画面リンクが正しく生成されないことがある。原因の構造は共通しているため、対処の考え方は変わらない。
この記事のポイント
- サブディレクトリ環境ではプラグインの管理画面リンクが404になることがある
- 原因はプラグインがパスをルート相対でハードコードしていること
- 一時的には URL へ正しいサブディレクトリを手動で挿入すればアクセスできる
- プラグインの最新版を確認し、修正があればすぐに更新する
- 修正がまだなら開発者へ具体的な環境情報を添えて報告する
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
Amazon Bedrock AgentCoreにWeb Search機能が一般提供開始、AIエージェントの回答を最新Web情報で根拠づけ
AWSは2026年6月17日、Amazon Bedrock AgentCoreにWeb Search機能の一般提供を開始した。AIエージェントがユーザーからの質問に対し、最新のWeb情報を参照しながら根拠のある回答を提示できるようにする。トレーニングデータだけではカバーしきれない直近の出来事や新事実を、AWS環境内で安全に取得できる点が最大の特徴だ。
この機能は、Amazonが長年培ってきた検索インフラ上に構築されている。Alexa+やAmazon Quick、Kiroといった製品で実績のある基盤を活用し、WebインデックスとAmazon Knowledge Graphを組み合わせたマルチソースな根拠付けを実現する。検索クエリは外部APIプロバイダに送信されず、AWS環境内で完結するため、企業のガバナンス要件にも適合する。
本記事では、Bedrock AgentCore Web Searchの仕組み、料金体系、導入事例を詳しく解説する。
Web Search機能の概要と背景
Bedrock AgentCoreの位置づけ
Amazon Bedrock AgentCoreは、AIエージェントの構築と運用を管理するフレームワークである。エージェントに必要なツールやデータソースとの接続をGatewayという仕組みで一元管理し、モデルの推論と外部機能の呼び出しを連携させる。今回発表されたWeb Searchは、AgentCore Gateway上で利用できる組み込みコネクタターゲットのひとつだ。
Web Searchが解決する課題
LLM（大規模言語モデル）は、学習時点のデータに基づいて回答を生成するため、つねに最新の情報を反映できるとは限らない。たとえば、企業の決算発表や法改正、製品アップデートなど、学習後に発生した出来事には対応できない。Web Searchを用いれば、エージェントがリアルタイムにWeb検索を実行し、得られたスニペットやURLを参照して回答を生成できる。回答には引用元が明示されるため、情報の信頼性をユーザーが確認しやすくなる。
仕組み：MCP接続とAmazon知識グラフによる根拠付け
MCP（Model Context Protocol）の役割
Web Searchは、MCP（Model Context Protocol）と呼ばれる標準プロトコルを介してAgentCore Gatewayに接続される。MCPを使うことで、エージェントは自然言語のクエリを送信し、関連性の高い検索結果（スニペット、URL、タイトル、公開日）を取得できる。GatewayがMCPターゲットとしてWeb Searchツールを仲介するため、開発者が個別に検索APIを実装する必要はない。
Amazon知識グラフとの統合
一般的なWeb検索に加え、Amazon Knowledge Graphの構造化データが検索結果に組み込まれる。これにより、単なるWebスニペットではカバーしきれない検証済みの事実情報をエージェントが参照できるようになる。AWSのブログ記事によれば、このマルチソースアプローチが従来のWeb検索だけに頼る場合と比較して、より的確な回答につながるとされている。
エージェントが回答を生成するまでの流れ
以下のデモは、ユーザーが質問してからエージェントが根拠付き回答を返すまでの一連のステップを図示したものだ。
STEP 3の段階でAmazon Knowledge Graphが活用される点が、単なるWeb検索を超えた信頼性につながる。エージェントは受け取った情報をそのまま返すのではなく、モデルが内容を推論した上で回答を構成するため、質問の文脈に合った自然な応答になる。
AWS環境内で閉じるセキュアなWeb検索の価値
多くのAIエージェント向けWeb検索ソリューションでは、ユーザーのクエリやプロンプトが外部の検索APIプロバイダに送信される。これに対しBedrock AgentCoreのWeb Searchは、Amazon自身の検索インフラを使用するため、データがAWS環境の外に流出しない。これにより、機密性の高い業務データを扱う企業でも、ガバナンスやコンプライアンスの要件を満たしながらエージェントにWeb検索機能を組み込める。
AWSの説明によれば、この仕組みはAlexa+やKiroなどのプロダクトで培われた検索技術を基盤にしており、信頼性とスケーラビリティの両面で実績がある。ユーザーは外部の検索サービス契約やAPIキー管理を気にすることなく、AgentCoreの設定画面上でWeb Searchを有効化するだけで利用を開始できる。
料金体系と利用開始手順
料金詳細
Web Searchの料金は従量課金制で、エージェントが実行した検索クエリの数に応じて計算される。具体的には、1,000クエリあたり7ドルである。新規のAWS顧客には最大200ドル相当の無料利用枠も提供される。利用料はすべてAWSの請求に統合されるため、別途外部サービスへの支払い管理は不要だ。
セットアップ手順
Bedrock AgentCoreコンソール（us-east-1リージョン）にアクセスし、Gatewayを作成する。ターゲットの追加時に「MCP target」プロトコルと「Connectors」タイプを選択し、プリコンフィギュアされた「Web Search tool」を指定する。Gatewayの詳細ページに遷移すると、PythonやMCP Inspectorを用いた呼び出しコードのサンプルが表示されるため、これをコピーして自環境に組み込むだけで統合が完了する。
テスト用途であれば、MCP InspectorをGatewayのリソースURLに接続し、Web Searchツールにクエリを直接入力して動作を確認できる。実運用では、エージェントのプロンプト設計にWeb検索の呼び出しトリガーを組み込み、回答生成時に適宜検索が走るように構成することになる。
企業での活用事例
Benchling：科学研究の加速
ライフサイエンス分野のR＆Dプラットフォームを提供するBenchlingは、早期アクセスを通じてWeb Searchを試験導入した。同社AIエージェント責任者Nicholas Larus-Stone氏によると、科学者が研究対象について質問すると、Benchling内の組織データと公開文献の両方に基づく回答が得られるようになったという。これにより、仮説生成の質が向上し、顧客のデータ管理ポリシーにも適合する安全な環境を維持できている。
Gen Digital：オンライン評判管理の強化
消費者向けセキュリティ製品を展開するGen Digital（Nortonブランド）は、Norton RevampというサービスにWeb Searchを組み込んだ。プロフェッショナルが自身のオンライン評判を構築する際、最新のトレンドや事実に基づいたコンテンツアイデアをエージェントが提案できるようになる。同社AI・イノベーション部門シニアディレクターIskander Sanchez-Rola氏は、すべてのクエリが信頼できるAWS環境内で処理される点を高く評価しているとコメントした。
いずれの事例でも、外部サービスを利用せずにAWS内で完結するセキュリティと、Amazon独自の検索インデックスによる高精度な情報取得が決め手となっている。
この記事のポイント
- Amazon Bedrock AgentCoreでWeb Search機能が一般提供開始。MCP経由でWeb検索と知識グラフを統合し、エージェントの回答を最新情報で根拠づける
- 検索クエリはAWS環境外に出ず、Amazonの検索インフラで処理されるため、データガバナンスとコンプライアンスに対応
- 料金は1,000クエリあたり7ドルの従量課金。新規顧客向けに200ドル分の無料枠あり
- BenchlingやGen Digitalなどの企業がすでに導入し、研究支援や評判管理の精度向上に活用している
- us-east-1リージョンで利用可能。AgentCoreコンソールから数ステップで設定できる
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
AWS最新動向（5月11日週） Bedrock AgentCoreの支払い機能とAgent Toolkitを解説
2026年5月11日の週、AWSはAIエージェントの自律的な動作を根本から変える発表を相次いで行った。最も注目すべきは、Amazon Bedrock AgentCoreがエージェント自身による支払い機能のプレビューを開始したことだ。これによりAIエージェントはAPIや外部サービスの利用料を自ら決済し、実行タスクに必要なリソースを動的に調達できるようになる。
AWS News Blogの著者であるChanny Yun氏が執筆した週次ラウンドアップによれば、この支払い機能はCoinbaseおよびStripeとの提携で構築された。さらに、AIコーディングエージェント向けの「Agent Toolkit for AWS」や、エージェントにデスクトップ環境を提供する「WorkSpaces for AI agents」も発表されている。本記事ではこれらの新機能を技術面とビジネスインパクトの両面から分析する。
Amazon Bedrock AgentCoreの支払い機能が示す「エージェント経済圏」の到来
AIエージェントが「考える」だけでなく「支払う」時代が来た。Amazon Bedrock AgentCoreにプレビューとして追加された支払い管理機能は、エージェントがAPI、MCPサーバー、Webコンテンツ、さらには他のエージェントの利用料を自律的に支払うことを可能にする。これは単なる便利機能ではない。エージェントが経済活動の主体になるための第一歩といえる。
この図が示すように、従来は有料サービスへのアクセスがエージェントのボトルネックだった。AgentCore Paymentsによってその制約が取り払われる。
CoinbaseとStripeとの提携が意味するもの
AWSはこの支払い基盤を単独で構築しなかった。暗号資産ウォレットのCoinbase（CDP Wallet）と決済プラットフォームのStripe（Privy Wallet）という、まったく異なる決済レイヤーの企業と提携している。Coinbase連携によりオンチェーン決済が可能になり、Stripe連携は従来型の法定通貨決済をカバーする。この二段構えが示唆するのは、AWSが特定の決済手段に依存せず、マルチペイメントレイヤーのエコシステムを目指しているということだ。
セッション単位の支出制限とガバナンス設計
エージェントに支払い権限を与えると聞いて、真っ先に浮かぶ懸念は「使いすぎ」や「不正利用」だろう。AWSはこの点をセッションレベルの支出制限で対策している。開発者はエージェントの実行セッションごとに予算上限を設定でき、その範囲内でのみ決済が実行される。企業の与信管理と同じ考え方をエージェント単位に落とし込んだ設計だ。
さらに、認証情報管理とコンプライアンス対応も組み込まれている。各エージェントは決済手段に直接アクセスするのではなく、事前に登録されたウォレット接続を通じて取引を実行する。AWSのIAM（Identity and Access Management）に似た権限管理の考え方が、支払い領域にも適用された形だ。
エージェント経済圏が実務にもたらす変化
Channy Yun氏がブログ記事で最も興奮していると述べたポイントは、この機能が解き放つユースケースの広がりだ。たとえば、リサーチエージェントがリアルタイムの市場データを動的に購入して分析に組み込む、あるいはコーディングエージェントがタスク実行中に有料APIを呼び出して機能を補完する、といった動作が実現する。
これはクラウドの従量課金モデルをエージェント自身が直接操作できるようになることを意味する。開発者はあらかじめすべてのAPI契約を整備する必要がなくなり、エージェントが実行時に必要なリソースを判断して調達する。インフラ構築の手間が一段階抽象化されるわけだ。
Agent Toolkit for AWSが実現する「AI時代のインフラ構築」
AgentCore Paymentsと並んで注目を集めたのが、AIコーディングエージェント向けの「Agent Toolkit for AWS」の発表だ。これはエージェントがAWS上で構築作業を行う際のエラー削減、トークンコスト低減、エンタープライズグレードのセキュリティ制御を実現する本番環境向けツールスイートである。追加料金なしで利用できる。
AWS MCPサーバーの一般提供とAgent Toolkitの関係
Agent Toolkitの中核コンポーネントとして、AWS MCP Serverが一般提供（GA）に移行した。MCP（Model Context Protocol）サーバーは、AIエージェントやコーディングアシスタントがAWSの全サービスに対して安全かつ認証付きでアクセスするためのマネージドなリモートサーバーだ。少数の固定ツールセットを通じて、複雑なAWS APIを抽象化する。
端的にいえば、エージェントに「AWS全体への安全なアクセス権」を渡す仕組みである。従来は開発者がIAMポリシーやAPIキーを個別に設定し、エージェントに渡す必要があった。MCPサーバーを使えば、これが統合認証のレイヤーで一元管理される。
ツールキットがエンジニアのワークフローをどう変えるか
Agent Toolkitは、これまでAWS Labsで提供されていたMCPサーバーやプラグイン、スキルの後継に位置づけられる。実験段階から本番利用への移行を意図した製品だ。具体的には以下の3つの価値を提供する。
- エラー削減: エージェントがAWSリソースを操作する際の設定ミスや権限違反を減らす
- トークンコスト低減: 最小限のツール呼び出しで済むよう最適化され、LLMのAPI利用料を抑える
- セキュリティ制御: 企業のセキュリティポリシーに準拠したアクセス制御を適用できる
開発者にとっては、AIエージェントに「AWSの操作方法」を一から教え込む必要がなくなる点が大きい。ツールキットが提供するスキルとプラグインを組み込むだけで、エージェントはAWSリソースのプロビジョニングや監視、トラブルシューティングを標準化された方法で実行できる。
AIエージェントにデスクトップを提供するWorkSpacesの狙い
プレビューとして発表された「Amazon WorkSpaces for AI agents」は、一見すると奇妙な機能に思える。AIエージェントが仮想デスクトップを使うとはどういうことか。狙いは、エージェントにGUIアプリケーションを操作させることにある。
多くの企業には、Web APIを持たない古い業務アプリケーションが残っている。WorkSpaces for AI agentsは、エージェントがこうしたGUIアプリケーションの画面を認識し、クリックやキー入力をエミュレートすることで、人間のオペレーターと同じ操作を実行できるようにする。
セキュリティ面では、エージェント専用のマネージドWorkSpaces環境が割り当てられ、エンタープライズグレードのガバナンスとコンプライアンスを維持したまま動作する。企業が長年抱えてきた「API化できない業務の自動化」という課題に対する、AWSなりの回答といえる。
第6世代Intel搭載の新型EC2インスタンスがもたらす性能向上
AI関連の発表に隠れがちだが、基盤となるコンピュートリソースにも重要なアップデートがあった。Amazon EC2のM8idn/M8idbおよびR8idn/R8idbインスタンスが発表されたのだ。これらはAWS専用にカスタマイズされた第6世代Intel Xeon Scalableプロセッサと、最新の第6世代AWS Nitroカードを搭載する。
vCPUあたり最大43%の性能向上
発表データによれば、前世代インスタンスと比較してvCPUあたりのコンピュート性能が最大43%向上している。この数字は単なるベンチマーク上の改善ではない。同じコストでより多くのワークロードを処理できることを意味する。
ネットワーク帯域とEBS帯域の強化
インスタンスタイプによって提供されるネットワーク性能も明確に差別化されている。M8idn/R8idnは最大600Gbpsのネットワーク帯域を提供し、M8idb/R8idbは最大300GbpsのEBS（Elastic Block Store）帯域に対応する。前者はネットワーク集約型ワークロードに、後者はストレージI/Oが重要なデータベースや分析ワークロードに最適化されている。
実務的には、機械学習のトレーニングデータを高速に読み込む必要があるケースや、大規模な分散データベースを運用するケースで効果を発揮する。M8idnとR8idnの選択肢が増えたことで、ワークロード特性に応じた細かいインスタンス選定が可能になった。
ValkeyとS3 Vectorsに見るデータ基盤の「ベクトル化」と「オープン化」
5月11日の週には、データ基盤に関する注目すべき動きもあった。OSS（オープンソースソフトウェア）のキーバリューストアであるValkeyが2周年を迎え、Amazon S3 VectorsとAurora PostgreSQLの統合に関する詳細なガイドが公開された。
Valkeyの急成長が証明するコミュニティ駆動開発の強さ
AWSのデータベースブログが報じたところによれば、ValkeyはDocker Pull数が1億を突破し、前年比17倍という急成長を遂げた。225人以上のコントリビューターが1,500以上のプルリクエストを提出しており、これは同期間におけるRedisの開発ペースの約2倍に相当する。
この数字が示すのは、単一ベンダー主導の開発モデルよりも、オープンでコミュニティ駆動の開発の方が速く、広範囲にイノベーションを起こせるという事実だ。Valkey 9.0はすでにAmazon ElastiCacheでも利用可能になっており、マネージドサービスとしての利便性とOSSの革新性を両立させている。
10億スケールのベクトル検索をSQLで
Aurora PostgreSQLからS3 Vectorsを標準SQLでクエリできるようになったことも見逃せない。具体的には、ベクトル類似度検索の結果とリレーショナルフィルタを1つのSQL文で組み合わせられる。たとえば、「意味的に最も類似した商品を検索し、その中から価格や在庫状況で絞り込む」といったクエリが単一ステートメントで完結する。
これはベクトルデータベース専用のクエリ言語を習得する必要がなくなることを意味する。すでにSQLを使いこなしているエンジニアであれば、追加学習なしでベクトル検索を業務に組み込める。データ基盤の民主化という観点から、非常に実用的なアップデートだ。
この記事のポイント
- Amazon Bedrock AgentCoreに支払い管理機能が追加され、AIエージェントが自律的にAPIやサービスの利用料を決済できるようになった
- Agent Toolkit for AWSが発表され、AIコーディングエージェントのエラー削減やトークンコスト低減を実現する
- WorkSpaces for AI agentsのプレビュー開始により、レガシーGUIアプリケーションの自動化が現実的になった
- 新型EC2インスタンスはvCPUあたり最大43%の性能向上を達成し、ネットワーク帯域とEBS帯域も強化された
- Valkeyの成長とS3 VectorsのSQL統合は、データ基盤のオープン化とベクトル検索の民主化が加速していることを示している
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験