前回のおさらい
前回は、サイトの基本デザインやプラグイン、固定ページといった「基本設計」を固めました。地味な不具合にいくつか出会いながらも、土台はしっかり整ってきた実感があります。
今回はいよいよ、外の世界とつながる部分の話です。メニュー、メール、Cookie同意まわり。ここでも、WordPress本体の仕様そのものに関わる発見がいくつかありました。
メニュー作成で、また「反映待ち」に出会った話
まずはヘッダーに表示するグローバルナビの作成です。「ホーム」「AIエージェント実践記」「ベテランエンジニアの生存戦略」「セカンドキャリア×AI」「AIニュース解説」の5項目を、API経由で一気に作る計画でした。
最初の本番実行では、メニューと項目の作成自体は成功したものの、その直後に一覧を取得して確認する処理が「見つからない」という結果を返し、安全装置が働いてロールバックしました。ここまでは、実は前回までに何度も出てきたパターンです。作成した直後の一覧取得には、毎回のように反映待ちの時間差がある。今回もまた同じ理由だろうと当たりをつけ、検証方法を「一覧をまるごと取得する」のではなく、「作成したメニューのIDを直接指定して、ピンポイントに取得する」方式に切り替えました。
一休みポイント:検証方法をどう変えたか
❌ 反映待ちに引っかかる確認方法
メニュー作成 → 一覧をまるごと取得 → その中から探す
(一覧への反映が遅れていると「見つからない」= 失敗と誤判定)
✅ 効いた確認方法
メニュー作成 → 返ってきたIDを使って個別に取得
(対象を名指しで聞くので、反映待ちの影響を受けにくい)「一覧から探す」より「名指しで聞く」方が反映待ちに強い、というのは、以前プラグインの導入判定でも学んだのと同じ教訓でした。
この検証方法に切り替えた2回目の実行で、メニューは無事に作成・登録されました。ただし、ここでもう一つ、ちょっと意外な事実に気づきます。メニューのURL識別子(スラッグ)として、こちらが指定した値を送っていたはずなのに、実際に保存されたのは、メニュー名から自動生成された別の値だったのです。
調べを進めると、これはこちら側の送り方の問題ではなく、WordPress本体の内部処理そのものが、この項目を常に「指定なし」として扱う作りになっている、ということが分かりました。表向きの仕様上は指定できることになっているのに、実際の内部処理では無視される。ここまで来ると、もう自分たちのコードを疑う話ではありません。「指定できるはずの項目が、土台の側の都合で実は機能していない」というのは、長年いろいろなシステムを見てきた中でも、たまに出会う類の話です。実害はなかったため、メニュー名の方を管理上の目印として扱うことにして、次に進みました。
メール到達までの、地味に長かった道のり
お問い合わせフォームからのメールを、きちんと自分たちの受信箱まで届ける。言葉にすると簡単ですが、実際にはいくつもの工程が連なっていました。
まず、送信元をどう用意するかです。すでに契約していたMicrosoft 365の仕組みを使い、問い合わせ専用の共有メールボックスを用意しました。WordPressからメールを送る際には、パスワードを直接埋め込む方式ではなく、OAuth認証という、都度の認可に基づいて送信する仕組みを選んでいます。パスワードをサーバー側に保存し続けるより、認可の記録が残るこちらの方式の方が、後から見返したときに安心できるという判断です。
このOAuth連携の設定そのものは、あえてAIエージェントには任せませんでした。外部サービス側での申請作業や、認可画面でのボタン操作といった、本人確認の意味合いが強い工程だったからです。ここは自分の手で、画面を見ながら一つずつ進めました。一方で、お問い合わせフォーム自体の組み立てや、送信テストの確認といった部分は、これまでと同じくAPIやコマンドライン経由で進めています。
不正な自動送信を防ぐための仕組みも、フォームに組み込みました。送信ボタンを押す前に、人間かどうかを裏側で静かに判定してくれるサービスです。昔ながらの「歪んだ文字を読み取って入力する」タイプの認証と違い、利用者側にはほとんど負担を感じさせない作りになっていて、地味にありがたい進化を感じました。
すべてを組み上げた後、実際にフォームから一通テストメールを送ってみました。共有メールボックスにきちんと届き、迷惑メール扱いにもなっていないことを確認できたときは、この回の中で一番ほっとした瞬間でした。設定項目の数だけ見ると地味な作業の連続でしたが、「本当に届くかどうか」は、最後の最後まで実際に送ってみないと分からないものです。
Cookie同意ツールの限界と、割り切り
最後に、Cookie同意まわりの話です。海外では法律で細かく求められることの多いこの分野、専用のプラグインを使って対応を進めていたのですが、ここで一つ、想定していなかった制約に突き当たりました。
このプラグインの無料版は、対象とする法域(どの国・地域の法律に合わせるか)を一つだけ選ぶ仕様になっていて、選択肢の中に日本の法律に合わせた設定が用意されていなかったのです。海外の法域を仮に選んで動かすこともできなくはないのですが、それでは実態と合わない説明をサイトに載せることになりかねません。
そこで、無料のCookie同意プラグインを「主役」として使うのではなく、あくまで補助的な役割に位置づけることにしました。プライバシーポリシーなど、法的な説明の正本は自分たちの言葉で書いた日本語の文書として管理し、プラグイン側はCookieの制御機能だけを保守的に使わせてもらう、という役割分担です。
もう一つ、細かい制約にも気づきました。このプラグインの設定画面では、サイト内の「プライバシーポリシーのページ」として、公開済みの固定ページしか候補に出てこない仕様でした。今回はまだ固定ページを下書きのまま慎重に確認している最中だったため、この紐付け作業は、ページを公開するタイミングまで持ち越すことにしています。
今回の教訓
今回あらためて感じたのは、「反映待ちの時間差」という同じパターンが、テーマ、プラグイン、そして今回のメニューと、まったく違う機能をまたいで何度も顔を出したことです。一つの現象を「そのときだけの偶発的な不具合」と捉えるか、「この基盤に共通するクセ」と捉えるか。後者として扱ったことで、以降の検証はだいぶ書きやすくなりました。
もう一つは、外部サービスとの認可や、法律が絡む判断のように、「効率化のためにあえて自動化しない」工程があったことです。すべてをAIエージェントに任せるのではなく、本人確認や最終的な法的判断は人間の役割として残す。この線引きは、第3回のライセンス認証のときと同じ考え方でした。
次回予告
これでひとまず、サーバー契約から公開設定まで、一連の構築作業をお伝えしてきました。次回は番外編として、ここまでで組み上げたシステム全体の構成を、図を交えて振り返ってみようと思います。
次回、「番外編:システム構成解説」でお伝えします。
コメント