前回のおさらい
前回、SWELLの導入まで完了しました。サーバー・WordPress・テーマと、ひととおりの土台が揃った状態です。
今回は、そこから先の「見た目と運用ルールを決める」フェーズの話です。前半は「AIエージェントに任せると何が起きるか」がよく見える内容で、後半は相変わらずの地味なトラブルシューティングです。
決めることは6つありました。サイトの基本デザイン、ヘッダー・フッター、必須プラグイン、固定ページ、SEO・OGP、バックアップ方針です。
デザインを「言葉」で決めない
最初につまずいたのは、配色の相談でした。「安心感を与えつつAIの新しさも感じさせたい」というような言葉で聞かれても、正直イメージが湧きません。長年インフラの現場にいると、UIデザインの語彙にはあまり縁がないものです。
そこで、文字でのやり取りをやめて、実際に3パターンのホームページの見た目を作ってもらいました。暗めの配色、明るい配色、未来感のある配色。3つ並べて見比べると、一瞬で「これだ」と選べました。言葉で考えるより、目で見て選ぶ方が圧倒的に早い。この感覚は、UIのモックアップを外部のデザイナーに作ってもらっていた時代とそう変わらないのですが、今は指示してから数分で3案出てくるという点が違います。
選んだのは、白ベースで落ち着いた配色の案でした。
OGP画像で見えた、AIの「クセ」
その後、SNSでシェアされた際に表示される画像(OGP画像)のデザインを相談していたときに、面白いことがありました。最初に出てきた案を見て、「あ、これChatGPTとかClaudeでよく見るデザインだ」と気づいたのです。
一休みポイント:何が「AIっぽい」と感じたのか
最初の案の特徴
・角の丸いソフトな光の演出(グラデーションの丸いぼかし)
・カテゴリ名を丸いピル型のタグで表示
・全体的に「無難に整っている」印象
指摘した後に出てきた案
・装飾を削って、太い一本の帯線と大きな文字だけで構成
・雑誌の表紙のような、直球のレイアウト
・別案として、ターミナル画面を模したデザインも試した装飾を削るだけで、印象がずいぶん変わりました。AIエージェントは「無難に整ったデザイン」を出す傾向があるようで、そこに気づいて「もっと削って」と言えるかどうかは、結局こちら側の目線に懸かっています。
これは今回、地味に一番印象に残った出来事でした。AIエージェントは指示されたことは器用にやってくれますが、「よくあるパターンに寄る」クセがある。そこに気づいて軌道修正するのは、まだ人間の役割なんだと感じました。
調べ物は、任せた方が早い
一方で、「Rank MathとSWELL標準のSEO機能、どちらを使うべきか」という判断は、AIエージェントに調査を任せた方が圧倒的に早かったです。
両方の機能を比較し、実際にSWELLの公式フォーラムでどんな不具合が報告されているかまで調べてもらい、最終的に「SWELLと同じ開発元が作っているプラグインの方が、構造化データの二重出力が起きにくい」という結論に至りました。これは自分一人で調べようとしたら、半日以上かかっていたと思います。
「デザインの好みを言葉で伝えるのは苦手だが、技術的な比較調査を任せるのは得意」という、自分なりの向き不向きが見えてきたのも収穫でした。
プラグイン導入で、あわや誤ロールバックしかけた話
必須プラグインの選定が終わったところで、実際の導入作業に移りました。お問い合わせフォーム用、バックアップ用、Cookie同意バナー用、SEO用と、4つをまとめて有効化する段取りです。
導入スクリプトを実行すると、4つとも無事にインストール・有効化されました。ところが、その直後に一覧を取得して確認したところ、なぜか3つ分しか反映されていません。「1つ失敗したのか」と身構え、念のため個別に状態を再確認してみると、実際には4つとも正しく有効化されていました。原因は、有効化直後の一覧取得にも、前回までに何度も出てきた「反映待ちの時間差」があったことでした。
もう一つ、別の落とし穴も重なっていました。導入に失敗したと誤判定した場合に備えて、該当プラグインを削除するロールバック処理を用意していたのですが、このロールバック先のURLを組み立てる際、プラグインの識別子に含まれる区切り記号(スラッシュ)の扱いが少しズレていました。結果として、ロールバックしようとした先のURLがサーバー側の想定と一致せず、「見つからない」というエラーになっていたのです。
幸い、この時点ではまだ実際の削除は実行されておらず、状態を再確認する処理を先に挟んでいたおかげで、正しく動いている4つのプラグインを誤って消してしまう事態には至りませんでした。反映待ちの時間差と、URLの組み立てのズレ。この2つが重なると、「成功しているのに失敗したと誤判定し、さらに誤って後片付けをしようとする」という、地味に怖いパターンになります。判定用の処理を一覧取得ではなく個別の確認に切り替え、URLの組み立ても見直したことで、以後は安定して動くようになりました。
固定ページの中身が、なぜか空っぽで保存された話
運営者情報・お問い合わせ・プライバシーポリシー・免責事項という4つの固定ページを作成する段階でも、手強い不具合に遭遇しました。
ページ自体はきちんと作成され、タイトルやURLも意図した通りに設定されているのに、肝心の本文だけが空っぽで保存されてしまったのです。エラーは一切出ていません。API側からは「成功」としか見えない状態で、なぜ本文だけが消えるのか、最初は原因の見当がつきませんでした。
調べていくと、このサイトのWordPressでは、ページの本文やタイトルを送信する際に、単純な文字列としてではなく、「これは元データですよ」という印を付けた入れ子の形で渡すことを求める作りになっていることが分かりました。今回は、この入れ子の形を使わず、素の文字列としてタイトルと本文を送ってしまっていたため、タイトルとURLの部分だけはそれらしく保存され、本文だけがどこにも渡らず黙って消えていた、というわけです。
一休みポイント:本文だけが消えた理由
❌ 送っていた形
{ "content": "本文のテキスト..." }
→ タイトルとURLだけ保存され、本文は無視される
✅ 実際に必要だった形
{ "content": { "raw": "本文のテキスト..." } }
→ 「元データ」の印が付いた形で、本文も正しく保存されるエラーが出ない分、「送った通りに保存されているはず」という思い込みに気づくまでに時間がかかりました。
対応としては、書き込む前に必ずそのサイトの実際の受け入れ形式を確認してから、形式に合わせて送信するよう手順を改めました。加えて、書き込んだ後にもう一度中身を取得し、元の原稿と一致しているかを突き合わせるところまでをワンセットにしています。幸い、4ページとも公開前の下書き段階で気づけたため、実害はありませんでした。ただ、「成功のレスポンスが返ってきても、実際に欲しいデータが渡っているとは限らない」という、前回にも通じる教訓を、また一つ積み増す出来事でした。
免責事項という、地味だけど大事な話
固定ページの中でも、免責事項は思っていたより中身のある話でした。単に「当ブログは責任を負いません」と書けば済むと思っていたのですが、実際には2023年10月に施行された景品表示法の「ステルスマーケティング規制」など、アフィリエイトを扱うブログとして今どき気にしておくべき法律の話まで絡んできます。
長年インフラの世界にいると、法律関係の話は正直不得意な領域です。ここも、法律の趣旨と一般的な対応方法をAIエージェントに整理してもらい、それを踏まえて自分の言葉で文章に仕上げる、という進め方になりました。
バックアップは、二重にしておく
最後にバックアップ方針を決めました。調べてみると、実はエックスサーバーには標準で14日分の自動バックアップ機能が無料でついていることが分かりました。知らずにいたら、わざわざ同じような設定を一から作ってしまうところでした。
そこで、サーバー標準の14日分に加えて、週1回のオフサイトバックアップも用意することにしました。最初は、契約済みのMicrosoft 365にひもづくOneDriveへ保存するつもりでいたのですが、ここで一つ計算違いがありました。使う予定だったバックアッププラグインの無料版は、OneDriveへの保存に対応しておらず、有料版へのアップグレードが必要だったのです。
「すでに持っているものを組み合わせる」つもりが、思わぬところで追加コストの壁にぶつかった形です。結局、同じ無料版で問題なく使えるGoogle Driveを保存先に選び直しました。新しく何かを契約するのではなく、すでに持っている無料の手段の中で組み合わせる。方針そのものは変わっていませんが、「持っているつもりのもの」が実際には使えない、という小さな見落としでした。
今回の教訓
AIエージェントは、調べ物や比較検討のような「正解に近いものがある作業」は非常に得意です。一方で、デザインの好みのような「正解がない作業」は、こちら側が具体的な選択肢を示して判断していく必要があります。そして、AIエージェントが出してくる「無難な一次案」に、こちらの経験で一手加えられるかどうかが、地味に効いてくる。今回はそれを一番強く感じた回でした。
次回予告
基本設計が固まったので、次はいよいよメニューやメール、Cookie同意まわりといった外部連携の設定と、公開に向けた最終調整です。ここでもまた、WordPress本体の仕様に絡む、ちょっとした発見がありました。
次回、「外部連携・公開編」でお伝えします。
コメント