Variable（可変性のある）テーマはその名の通り、色々なテーマ（Skin：見た目）と融和する構造体としてのテーマです。なので単体実装時は見た目は最低限のスタイルだけで、導入後には「子テーマ」としてスキンを設定することで、通常のウェブサイトのように振る舞えるようになります。

今回はVariableテーマの導入による利点と導入方法や、AIへの命令環境を含めた、最終的には自身だけで導入完了ができるようにするための内容を、一部会員向けコンテンツとしてご案内いたします！

Variableテーマの導入メリットとデメリット

以前の記事でも軽く触れましたが、Variable Themeは現在〜将来のWordPressサイトにおける、アップデート耐性やAI対策、セキュリティ対策に特化した、標準化を目的とした構造体のテーマです。

見た目や表現方法に左右されないので、あらゆる見た目のWordPressサイトの基本として利用いただけます。また、WordPress公式のバージョンアップ情報に常に対応してアップデートをしていくので、ユーザーはアップデートの際のエラー不安等に悩まされることは少なくなります。

唯一デメリットとしては、単純にVariableテーマのままですと、味気のないフレーム構造となるというところで、子テーマによるデザイン表現が必須となります。子テーマの実装はいわゆるWordPressの専門業者やお付き合いのあるデザイン会社さんにお願いしなくてはならないのがデメリットといえます。

子テーマ（スキン）の導入で守られるもの

スキン（子テーマ）とvariableのような親テーマと分岐することは、実はサイトにとってはとても有益です。まず、「見た目」と「構造」を分岐するので、構造とうセキュリティに欠かせないフレームが、WordPressのアップデートと並んで行われるので、アップデート時のエラーや表示崩れを大きく軽減できます。

また、見た目に関係なく構造がAIも読みやすい構造として作られているため、中間読者としてのAIBotがコードに邪魔されずに内容を拾い上げてくれるようになりますので現代の検索体験に寄るSEO対策（AIO/GEO）にも大きく貢献できます。

弊社でも当然そのスキン（子テーマ）を作ってご提供することはできますが、内製化を行なっているお客様にとっては、Variableテーマは少し面倒の多いテーマとなってしまいます。

そしてそれがデメリットでもありますが、

この工程（スキン制作）を自身・自社内でできたらどうでしょう？

Soleilでは、新たに会員登録いただいた方に向けて、作業工程や自社での導入方法、AIと組み上げるためのルール（markdownファイルやフォルダ環境）、またローカルでの開発作業方法を、実例をもとにしながらご案内するコンテンツをご用意しました。

会員向けコンテンツの内容

会員向けコンテンツのシリーズ「Soleil Suite」では、未導入だけどオリジナルテーマを運用中の方のために、導入方法から現在のデザインと同じまま構造だけ最新でアップデート耐性に強いサイトを作るための流れをご案内します。

1. Local環境でWordPressサイトを修繕するための準備
2. AIエージェントに作業させるためのプロンプトとマークダウンファイルの提供（一部有料）
3. 修正対応中の人間の行動について
4. チェック項目と作業方法
5. 本番環境へのアップロード
6. 実際の運用

このようなコンテンツを会員限定にて配信しております。

まとめに

この記事では

• Variable導入の考え方
• 社内でAIを活用する準備
• 導入前に知っておくべきポイント

をご紹介しました。ここまででも導入判断はできるはずです。一方で、「実際の移行手順やAIとのやり取りまで知りたい」という方向けに、会員向けコンテンツでは実際の作業ログや設計資料を公開しています。

会員向けコンテンツとして初の試みですが、ウェブ制作においては局所的に迷う点が制作側には多いという悩みを私も同じく持っています。

そのために、実例を交えながら「こう困ったときにどうした？」という情報を、当人から詳しく聞けるコンテンツとして試みております。

いわゆる広く公開できない情報等を発信するためのコンテンツです。

実際に使用したファイルの中でも、転用可能なファイル（AI用のマークダウンファイルや階層構造など）は一部有料ですが配信もしております。

弊社サイトはデザイン会社のサイトであると共に、学べて使えるサイトとしても将来の姿を見据えています。

皆様にとって有益な情報を配信できるよう努めてまいりますので、どうぞよろしくお願いいたします。

The post 【内製化支援】Variableテーマを社内でAIと共に導入するための準備 first appeared on 株式会社Soleil.

最初は「AI Botをカウントするツール」から始まったSACですが、今はAIという新しい読者を理解するための解析ツールへと軸が移ってきました。

今後の展開も視野に入れて、一度Soleilのビジョンを公開したいと思います。

現在のSoleil AI Counter

現在のSACは、「AIがサイトに来た事実」のみを取得しているツールです。そこから日付・ページ・どのBotかなどの枝葉になる情報を取得しています。言うなれば、mixiなどの足跡機能です。

足跡からでもわかることは多いのですが、それだけでは現代の検索での結果として考えると、もっと知りたいことがあります。

今までなら「人間しか検索しないし人間がウェブサイトを見る」という状況だったので、GA4で十分だったのですが、AIも見るとなったらGA4レベルじゃなくても、解析の対策を必要とする時代になると思っています。

仮説：中間読者の読み取り方の進化

今はAIチャットに質問を渡すと、AIが調べに行って私たちに情報をくれます。これを私は中間読者と呼んでいますが、AIの動きを今現在でどこまで調べようか？としてもいいところ「足跡とそれを取り巻く情報」までしか手に入れることができません。

SACで分かるのは

• どのBotが来たか
• いつ来たか
• どの記事へ来たか
• 何回くらい来たか

くらいのものですが、これを細かく検証していく中で、SACのスタンスとして「これ」を知れたらすごく進化しそう！と思うものがあります。それは、いわゆる「どのクラス名を読んだか？」を将来的に取得できる仕組みが実現できれば、「ページのどのセクションを重点的に読んでいたのか」ということを取得できるようになるかも知れません。

そうなると正直ヒートマップより、取りこぼしがないのかな？なんて思ったりもしますが、現段階ではそれの取得ができるようになるための下地づくりに励んでいる感じです。

仮説：もしAIが読む場所まで取得できたら？

こうして進化をしていくと、あえて擬人的に表現しますがウェブサイトに書いてあるものを「AIが好んで読むもの」「そうでないもの」が登場し始めるかと思います。そしてその「AIが読んでいる」背後には大きく二つのステップがあります。

その１：そもそも「AIに見せます／見せません」という壁

これは、サーバー側でのセキュリティ（WAFなど）と.htaccessでの、防御壁みたいな機能と、robots.txtによる意思表示・公開方針といった操作になります。

サーバー側のセキュリティを「物理的な防御壁」だとすると、robots.txtは通行手形を持ってるかどうかを確認する門番みたいな感じですね。

ここの設定がそもそものアクセスを決めるので、会員制サイトや自社でも検索させたくない場所がある場合はここで制御することが多いです。

その2：AIが読みやすい構造に近づいているか？

AIに読ませます！の前提で考えた時に、そもそもAIが読みやすいか？ということが重要になります。Soleilではそれを標準化の一部として取り扱っていますが、AIがサイトを読みに来た時に、AIが理解しやすいかどうか？は普段目に見えていない「HTML構造」で半分くらいは決まります。

AIに遜るわけではないですが、人間が視覚的に補完して読んでしまいますが、AIはちゃんと構造側から読んでいる（「右クリック」→「ソースを見る」で見れるコードを読んでいると思って概ね間違いないです。）ので、AIにも読みやすいように構造を整えておく必要があります。

この2つを整えていくことがAIに読んでもらうための準備（下拵え）です。

人がAIに質問する場合、今まで人間がやっていた「検索結果画面から探して読む」というのを変わってくれるだけであって、AIは必ずいろいろなサイトの内容を情報源として人間に提供しています。なので、AIに読まれるということは誰かに伝わっているということに限りなく近いのではないか？と考えています。

ちなみに読まれたくない場合に「読みにくい構造にすれば？？」という考えもありましたが、通常のSEO等検索対策への被害の方がデカいのでやめといた方がいいなと思いました。

展望：AIの解析が進むその先

もし将来、AIが「ページのどこを重点的に読んでいたか」が取得できるようになれば、Soleil AI Counterは単なるアクセス解析ではなく、「AIが興味を持った場所」を可視化するツールへ進化できるかもしれません。

例えば、

• AIが最後まで読んだセクション
• AIが何度も参照した見出し
• AIが引用しやすかった説明

そうした情報が積み重なれば、人間向けのヒートマップとは違う、新しい解析が生まれます。

私はこれを半分冗談で、「AIいいね」と呼んでいます。

もちろん、本当に「いいね」を押しているわけではありません。ですが、多くのAIが繰り返し参照する場所は、「AIが価値を感じた情報」と考えても大きくは外れていないはずです。

Soleil AI Counterが目指しているのは、アクセス数を数えることではなく、AIという新しい読者が、何を価値ある情報として受け取ったのか。そこまで見える世界です。

まだ道半ばですが、小さなアップデートを積み重ねながら、その景色を少しずつ形にしていきたいと思っています。出できることを目指したいと思います。

AI検索時代は始まったばかりです。Soleil AI Counterも、小さなアップデートを積み重ねながら、「AIという新しい読者」を理解するためのツールへ育てていきます。

The post Soleil AI Counterの小さいアップデートから目指すもの first appeared on 株式会社Soleil.

さて今回「SEO改善」という皆様にもとても気になるご相談をいただきまして、「もし改善が難しければリニューアルも視野に入れて」というお悩みでした。

実際昨今ではSNSもありますし、SEOよりも検索体験を重視している店舗さんも多いですが、HPはないと困るし、せっかく持つなら検索で目立ちたい」というのは皆様共通の願い。ウチもそうです。

SWDで当初提案した内容と180度変わってしまった案件でしたので、SDWの実態の紹介も兼ねてご紹介します。

初回診断での見立て

SWDでは必ず最初に提案ではなく初回診断を行い、現状を把握しお客様と共有します。今回は予約必須の個別ボディメイクジムの店舗サイトの方からご相談をいただきました。

まずはご相談をいただいた段階では、サイトのURLと症状をお送りいただくだけなので、表面的に「どんな症状なのかな？」というのを見ます。今回はエラーはなく「SEOの評価診断とこれから改善ができるのか？」がメインとのことでした。

SEOの評価チェックは表面的にも行えますが、より詳しく診断するために、初回診断（￥3,300-）をご案内します。そのタイミングでWordPressダッシュボードのログイン情報を共有いただき、より詳しい診断を行います。（SWDは主にWordPressの診断サービスですが、それ以外もご相談いただけます）

今回も初回診断をご注文いただきましたので診断を行いました。概ね1時間ほどで初回診断は完了します。

その結果としては、

• テーマロックインした機能が見られる（かも）
• Google Search Console等の未接続
• SiteMapが見当たらない
• 著作者情報の不明
• 謎の重いデータでLCPが極端に遅い
• セクション構造が不明瞭（タイトル要素）

といったことから、

1. 構造的な標準化を優先項目に入れ、Variableテーマを実装させる
2. リニューアル（新規デザイン）にせずに、今のビジュアルを守る
3. 積み上げたブログ記事等を守るためにスラッグ等は操作しない（NGのところはRedirectionで離脱防止させる）
4. 上記を満たした上で、SEO対策をさらに行う

というプランにてご提案しました。先方が一番気にしていた、WEB記事の登録の仕方がかわったらどうしたら？？ということや、今までのブログが消えないかどうか？は、どちらも心配いらないことをご理解いただき、約1週間ほどで完了することで快諾いただき作業を開始することになりました。

SWDを受注した後の作業

SWDを正式にご注文いただいた後は、サーバー情報とFTP情報をいただき、ローカルに環境を作っておきます。これはこちらの作業中にウェブサイトが停止するようなことを回避する意味と、バックアップのためです。

今回もローカル環境にサーバーと同じ情報をインポートしてネットと隔絶したWordpressサイトを作りました。完了したらここからアップします。

ローカル環境なら詳しくスキャンができます

環境がオンラインからローカルに移行することで、より詳しく現在の状態を確かめることができます。今回診断で見つけた要確認箇所をさらに詳しく調べますと、初回診断では分からなかったことが見えてきました。

まず重いデータの正体ですが、なんとフォントでした。そしてそのフォントはテーマに依存していて、テーマ側でその選択を解除することでLCPが10ポイントほど改善されました。

そしてテーマロックインしているところと、構造が不明瞭だった点も、元々利用しているブロックテーマの思想に則った作りになっているだけで、しっかりとした構造だったということがわかりました。

つまり

「Variableテーマに変えない方がいいじゃん！」

っていう結論に至りました。

今回達成しないといけない相談内容は、「SEO改善と集客」なので、リニューアルよりもGoogleのビジネスプロフィールやEEATの強化、SearchConsole対策とプラスαでCTAを設置したりすることが最重要項目に変わります。

提案の方針変更

なぜ作業方針を変更したのか

今回のケースでは、Variableテーマへの移行は十分実現可能でした。しかし、SWDの目的はVariableテーマを導入することではありません。お客様の目的は、「SEO改善と集客」です。

テーマの導入は、そのための手段に過ぎません。もし手段が目的より優先されてしまうのであれば、それは本来のSWDではないと考えています。

診断の結果、「現状のテーマを活かした方が目的達成に近い」という判断に至ったため、今回は方針変更を行いました。

ので今回も、

「すみません初回の見立てでテーマの入れ替えを提案・発注いただいたんですが、詳しく調べたらやらない方が良さそうなんで、こちらの別提案にした方がいいという判断なのですが、いかがですか？価格としては新規導入分が減額になります。」

という感じで作業の方針変更を行いました。（やり取りは公式ラインで行ってます。）

お客様的にもその点はご納得いただき、方針変更が決定しました。

方針変更後はスムーズに作業

方針変更後は、サイトの未接続の配線を繋ぎ直したり、足らないパーツを作りつなげたり、さらに少し荒れ荒れになった部分を直す作業に集中になります。

スラッグの不備やSearch Consoleの不備は自身でサイトを運営しているとありがちなことです。違うサイトに行って難しい接続とか何やってるのか分からんってなること多いですし。

そんなこんなで今回の案件は概ね1日で完了致しました。

The post 【実践記録】サイトを作り直さなかった理由 first appeared on 株式会社Soleil.

その名の通り「可変性のあるテーマ」を目指しています。WordPressの思想に沿いながら、オリジナルテーマを持ってもそこから乖離しないという理想の元、開発をし公開レベルに達したので、市販テーマからオリジナルに切り替えました。

このWPテーマ、作ってみたら結構汎用性あるので提供できるレベルまで開発を進めたいと思います。

ただデザインをテーマに落とし込むだけじゃないテーマ

WordPressのテーマというと、まずデザインに注目されることが多いと思います。実際、市販テーマもオリジナルテーマも、最初に目に入るのは見た目です。

これまで多くのサイト制作や保守を行う中で感じていたのは、オリジナルテーマを作るほどWordPress本来の思想から離れてしまい、逆に市販テーマでは運用や拡張に限界があるということでした。

そこでSoleilでは、「WordPressの標準に沿いながら、必要な部分だけを柔軟に変えられるテーマ」を目指して開発を始めました。

Variableは、単なるデザインテンプレートではありません。

といった、サイトを長く育てていくための土台を重視しています。

今回まずは自社サイトへ実装し、実運用を開始しました。実際に運用しながら改良を重ね、将来的には一般提供も視野に入れています。提供する各種サービスでも言っていますが

「サイトは完成した瞬間がゴールではありません。」

自社サイトでも同様に実践して、皆様により良い環境を提供できることを目指していきたいと思います。

Variableテーマの特徴

このテーマの特徴は以前の「標準化」に関する記事でも述べた思想に準じた特徴になっていて、ちょっとプロっぽく言うと

モジュール化された共通構造と再利用可能なコンポーネント群を持つWordPressテーマ

となっています。思いっきり噛み砕いて言うと

ガンプラの内部フレームのような共通骨格があり、
その上にデザインという装甲を取り付け、
必要な機能は戦隊ヒーローのロボットのように合体させていくテーマです。

実際にサイト制作を続けていると、業種やデザインは違っても、サイトがやっていることは意外と似ています。

会社情報を掲載する。
サービスを紹介する。
お問い合わせを受ける。
お知らせを発信する。
よくある質問を掲載する。

見た目は全く違っても、基本構造は共通していることがほとんどです。

そこでVariableでは、こうした共通部分をフレームとして標準化し、デザインや機能は後から自由に組み合わせられるようにしました。

だから名前も「Variable（可変）」です。

サイトごとに姿を変えながらも、中身は共通の思想で運用できる。

それがVariableテーマの目指している形です。そして私はガンダムが大好きなんです。

Variableテーマはこんな方におすすめです

• サイトをリニューアルするほどの予算はないけど、改善はしたい
  デザインはそのままでも、内部構造を整理することで運用しやすくなる場合があります。
  
• 制作会社や担当者が変わっても運用しやすいサイトにしたい
  特定の担当者しか触れない状態ではなく、引き継ぎしやすい構造を目指します。
  
• WordPressのアップデートや保守が不安
  標準化された構造を意識することで、将来的な保守や更新もしやすくなります

事業の成長に合わせて少しずつ機能を追加したり改善したりできる土台を作るためのテーマなので、

今の見た目（デザイン）をそのままに、構造だけ標準化

にも対応可能です。

Variableは、Soleilが普段行っているWordPress健康診断や標準化の考え方をテーマとして形にしたものでもあります。

Variableの今後

今回公開したVariableは、まだVol.1です。まずは自社サイトへの導入を行い、実際の運用を通じて改善を続けていきます。

今後は、

• 各業種向けスキンの開発
• FAQやサービス情報などの標準モジュールの拡充
• AIとの連携を考慮した構造設計
• WordPress健康診断（SWD）との連携

などを進めていく予定です。

また、既存サイトのデザインを活かしたまま構造だけを標準化する手法についても検証を進めています。

サイト制作の現場では、「全部作り直す」か「何もしない」の二択になりがちです。

Variableでは、その中間にある「今ある資産を活かしながら改善する」という選択肢も作れればと考えています。

SWDとの連携について

Variableはテーマとして公開していますが、本来の価値は導入後にあります。

WordPressもテーマも、公開したら終わりではありません。

WordPress本体のアップデート、新しい機能への対応、セキュリティ対策、運用方法の変化など、サイトを取り巻く環境は常に変化しています。

そのため、SWD（Soleil WordPress Dock）をご利用いただいているお客様については、Variableのアップデートや改善内容を継続的に反映できる仕組みも検討しています。

サイトを作って終わりではなく、定期的な健康診断を受けながら、必要に応じて機能を追加し、長く安心して運用できる状態を維持する。

Variableは、そのための共通フレームとして開発しています。

これからも実運用を通じて改良を重ねながら、より安心して使えるテーマへ育てていきたいと思います。

The post 【テーマ更新】VariableテーマVol.1を実装しました。 first appeared on 株式会社Soleil.

私も紹介してましたがいわゆる「WordPressの推奨する標準化」と「Soleilの考える標準化」が合致する形を「標準化」とする

と言う頭の痛くなるようなお話ですが、ちゃんとここで説明しておきたいと思います。「標準化？？いやウチはデザインに拘るんで」と考えている方にはぜひご一読いただきたいです！

標準化と標準化してないの差

システムや機能の話ではなく、とっても単純な話です。Soleilの考える標準化は車で言うところの「車検に通る形」にすると言うことです。

フェラーリもポルシェも（ハイデザイン）、FitもMarchもジムニーも（親しみやすデザイン）、昔私が乗ってたシトロエン（？）も、全部ハンドルがついててブレーキがついてて、操作環境に大きな差はなく、日本も海外もある程度走れますよね？

そうです。ウェブサイトは車で、投稿する人は運転手。車に例えてみればわかりやすいですよね。

もしも、フェラーリのブレーキは天井にあって、ポルシェのウィンカーのスイッチは助手席にあるから必ず二人で乗りましょう。とかだったら、免許の後に車種に合わせた勉強が必要になっちゃいます。んなアホなと。

標準化というのはもうこの節で言ったとおり、「Webサイト界の車検みたいなの（無いけど）を通る設計にする」ことで、ビジュアルは尖ったデザインにするもよし、安定したデザインにするもよしなのです。

WordPressはユーザーを選ばない設計思想

WordPressはそもそもの思想が、ユーザーの技術力や認識を厳しく制限しない設計思想です。それは、投稿システムで採用されているブロックエディタ「Gutenberg【グーテンベルグ】（5.0より採用）」にも現れています。

グーテンベルグって言うと何かピンと来る人いませんか？

そうです。活版印刷機の発明者です。このWordPressの標準ブロックエディタは活版印刷機の発明者から取られています。

活版印刷はそうです、たくさん印刷するアレです。そして活版印刷機で一番齎された恩恵を僕は、「知識の標準化」だと思っています。

1. 活版印刷によって書籍が量産される
2. 大量生産によって人の目にたくさんの情報が届く
3. 伝達される情報の誤差が減る
4. 学習機会が増える
5. 知識の蓄積速度が上がる
6. 以下ループ

といった感じで影響が凄まじかった大発明だったのだと思います。活版印刷が知識の流通を加速させたように、WordPressもまた、誰もが情報発信をできる世界を目指しているんだと思います。

WordPressの標準化が必要なワケ

ウェブサイトはまさしく会社の「顔」の一つです。つまり千差万別。作り方も人（サイト）それぞれ。

WordPressはいかなる見た目にも対応可能なほど自由度が高いので、個性や特色が出て自社をPRするためのサイト作りにおいて選択肢の一つになることが多いです。

それゆえに「独自のカスタマイズ」が溢れ、それによりブラックボックス化（オイオイ誰がどうやってこうなったんだよ！もう知らん！化）が発生することも多く、仮に一度作ったWPサイトを「ちょっと変えたいな」と思っても「あ、無理っすね。作り直しの方が安いっす」になることもよくあります。

WordPressの制作会社も想定以上のカスタマイズには対応できない場合はもちろんあります。例えばバイクで思いっきり改造しまくってジョッキーシフト仕様にしたとします。

オーナーは当然乗れますが「中免持ってるでしょ？とりあえず運転して！」って言って、鍵を別のバイカーに渡しても多くの人は戸惑うでしょう。それと同じ感じです。いわゆるこれが「WordPressの魔改造」です。

自社のサイトが「魔改造されているかどうか？」はオーナーならわかることもありますが、「誰でも触れるようになっているかどうか？」は、プロじゃないと判別はつきにくいのです。

標準化すると何がいいの？

ここですよね？「車検通ると何がいいの？」は「乗れる」と単純ですが、ウェブサイトをそう考えると、どんな状態であっても「見れる」ので、大丈夫そうです。

しかし標準化することで「見れる」以上の効果を得ることができるとSoleilは考えています。

• 管理者や制作会社が変わっても、迷わず修正や変更が伝達コストなくできる。
• 社内での更新の場合も、担当者に捉われず対応できるようになる。
• AIや各種ツールがサイトの情報を理解しやすくなり、今後の拡張にも対応しやすくなる
• WordPressのバージョンアップに対応するので、セキュリティが上がる
• 将来の改修コストを抑えられる

というメリットがあります。

まとめ

Soleilは、フェラーリをFitにしたいわけではありません。フェラーリはフェラーリのまま、ジムニーはジムニーのまま。

ただし、次の担当者や制作会社が困らずに整備できる状態にはしておきたい。それが私たちの考える「標準化」です。見た目の個性を消すことではなく、将来も安心して運用できる状態を作ること。WordPressを長く活用していくための土台づくりだと考えています。

The post 【Webの車検】標準化って何？フェラーリデザインもジムニーデザインにも通る設計の話 first appeared on 株式会社Soleil.

Soleilのウェブサイトも若干遅く（7.0にした時に診断してますが遅かった）、ちゃんと標準化しておかないとな。と思っておりましてSWDのサービスとして記録を作ってみました。実際のサービスもこのような流れになるので、ご紹介します。

症状の確認

通常はお申し込みいただいた後、悩まれている相談をもとに、初回診断（診断のみの場合は¥3,300税込）を行うかどうか？をご相談します。今回は自身のサイトなので、そのまま初回診断へ。

症状としては、表示や動作などは問題のある箇所はなく、セキュリティに関しても大きく邪魔をしている様子もありませんでしたが、表示までの時間がとてもかかる（重い）症状が気になるという感じです。

申し込みとか欲しいのにアクセスが重いのは機会損失になるので何とかしないとな。

調査はあくまで予測ですが、サーバーやデータベースやプラグインなどを最初に疑います。しかし大丈夫そう。ただPageSpeed Insightsでは、LCP・TBTが長い（680msくらい）と出てたので、たぶんJSの読み込みで時間食ってるんじゃないかな？という見立てです。

診断をより深めるためにサイトの中を見ると、functions.phpを経由してjsを全てのページに読み込む仕様になってました。これ自体（functions.phpで読み込むこと）は決して悪いことじゃなく、通常のサイト運用では結構やってます。どのページでも必要なスクリプトならそう読み込むことが正解なわけですし。

ただ、全部が全部読み込んでOKっていうのはちょっと違くて、全く使わないのにJSとかCSS読み込んでんだよなあ、ってなるとブラウザで見る時どうしても読み込みにかかる時間が重なってしまい、結果として遅くなるということです。

診断結果

調査及び診断をした場合（初回診断後）、下記のような診断書兼お見積書をお渡しします。診断後はそのまま修復依頼をいただくことも可能ですし、お付き合いのある制作会社様や自身で行う場合の指標として活用いただくことも可能です。今回は「うちのサイト」なのでそのまま進みます。

今回お見せしている診断書は、最後までやった後の診断書なので「作業ログ」や「完了報告」も載っちゃってますが、通常ご発注いただいた時のみ症状について詳しく記載するようになります。

修正説明①：読み込み箇所分解

まずは、JSをfunctions.phpで全部読み込みます！をやめにします。次のステップに向けて、JSが何だったか？をもう一度切り分けるために、どこで何が動いているか？をJSの役割と照らし合わせて分担を整理しました。ファイルはバラバラでしたが、読み込みを統一していたので、条件分岐（決まったページの時だけ読み込まれなさい！という命令）をこの時点で行いました。

修正説明②：mu-plugin化

テーマやプラグイン依存になりがちな部分でも、より「運用」に近い機能（CF7制御系・reCAPTCHA制御・Site Kit連携など）は運用層に寄せるためにmu-plugin（必須プラグイン）に分化します。

こうすることで、市販テーマによくあるテーマのアップデートにも強く耐えられます。自作テーマの場合でも、セキュリティや保守、表示のキモになる部分をテーマ側で、運用に近い部分をmu-pluginに分けることで、機能の責任分化ができて更新しやすく、事前のエラーチェックの場合にも原因追及が楽になります。

修正説明③：画像のWebp化

わかりやすいことですが、画像を軽くします。でもここまで①・②まで詰めていけば「あとは画像を軽くするだけだぜ！」っていう状態になるので、かえってわかりやすかったりします。functions.phpを魔改造している場合なんかだと、画像の形式変えて軽くしても表示事故を起こしたりします。okkane-。

軽量化の中で、今まで更新してきておざなりだった「プログラムの責任の所在」を一緒に整理することで、物質的な整頓だけでなく心理的な整頓にもなるので、これから先の運用でも不安が減りそうです。特にAPIとかで外のサイトと繋がることが多くなっていく中では、「APIという配線がちゃんと整備・配備されている」というのはメンテナンスにおいては最重要です。

「高速化」より大事だったこと

今回重要だったのは、単にスピードスコアの点数を上げることではなく、“問題箇所を切り分けられるWordPress”へ戻すことでした。いわば初期状態から、WP側にとっての最適化された状態にどこまで近づけるか？という感じです。

でもせっかくなんで、点数の結果としては、こんな感じ

TBTの激減ぶりに感涙ですな。これによって、単純に表示速度も速くなったし、それ以上に責任分化されたので、今後の運用も安心というわけです。

ここまでで作業としては完了となり、診断書兼報告書に症状・実施内容・今後の対策や気をつけた方がいいかもしれないということをまとめて、現場納品をいたします。

通常のサービスでは、エラーからの復旧や特急お直しを除き、ローカル環境にて作業を行いサイトに納品させていただきますので、HPが表示されない期間なく、安心してサイト健康診断・改善対策サービスをご利用いただけます。

まとめに

WPサイトは使い続けていく中で重くなったりすることが多く、プラグインを止めても、更新しても、サーバー情報と睨めっこしても解決しないこともあります。SWDではWPの標準化を軸に改善点を提案し、ご了承いただいた後に安全に作業をすすめご満足いただけるように心がけております。

• 自社サイトも重い
• 何が原因か分からない
• pluginを減らしても改善しない
• 更新が怖い

そんな場合は、まず健康診断からご相談ください。

The post ノロノロ魔改造WPサイトでも一旦リセット｜市販テーマを“壊さず”高速化・標準化した記録 first appeared on 株式会社Soleil.

「サイトを常に最新に保っておけばセキュリティ的にも安全です！」「最新の技術でもっと利便性を実感」「より検索対象順位を上に上げるために」などなどの理由ももちろんありますが、何よりの理由は私の失敗経験に由来します。それは

「受注したサイトがガチでクラッキング（サイトをぶっ壊す行為）された」

というトラウマ級経験から「あの思いは誰にも経験させたくない」というのが本当の理由です。今回はその失敗談をご紹介していきたいと思います。

ことの背景

かれこれ10年以上前、私はその頃社会人からのWeb経験でしたが、5年くらいやってきた30歳くらいの会社員でした。WordPressに触れてからPHPを学び、半人前だけどちょっとずつ作ったりできるようになってきた頃です。とある任意団体のウェブプレゼンに勝ち、ウェブサイトの制作・運営・保守を長期で請けることができました。

そのサイトでまさかのサイト改ざん（いわゆるハッキング）

ある朝会社に行くと、怒号の電話。「どうしたんですか？」と。

「サイトがおかしなことになってるから、なんとかして！」

開くと、私がデザイン・制作を行ったサイトのFV（トップの最初の画像とかをそういう）が、中東系？と思しき女性が中指を立てている画像に差し代わっているじゃありませんか。

なかなかどうして、お堅い系のサイトでは珍しいデザインではありますが、私はもちろん、社内でもそんな画像を調達して差し替える人なんか居ません。

まして制作チームはごくごく少数どころか私と営業補助の一人だけで、ほぼ私が行なっており

「あ、こりゃやられた（遠のく意識）。。。。」

と、事実を受け止めるのに数秒のタイムラグを必要としました。

まあ、あまり縁のない方にもお察しいただけるんではないでしょうか？運営しているサイト（いわゆる商品）が、ぶっ壊されるという事実。まあお客様のものですし、なおさら意識が飛びますよ。

当時の反省：セキュリティ的にどうだったんだろう？

ウェブのセキュリティっていうのは、もう数えきれないほどの手法があります。あの頃は「とにかく動かしてお客さんの要望する稼働を実現しよう」としていて、セキュリティに対する知識や見識に関しては、今と比べるとえらく低かったんじゃないかな？と思います。

実際に起きた症状と原因いついての詳細は伏せますが、ざっくりいうと投稿系の機能に使うユーザーパスワードの管理の仕組みが「ザル中のザル」だったという感じです。自作のPHP系サイトであったのもあって、正直今考えるとゾッとします。

現在はその反省を活かした提供にはなっていると胸を張って言えますが、あの頃はちょっと「知ったかぶり」もあったんだろうなあ。。。

今だから分かる危険性

業界的にサイト改ざん（いわゆるハッキング）されるなんてのは、「ダメダメサイト認定！」でして、持ち主はもちろん、製作者、管理者、サーバー会社、ありとあらゆるところに迷惑をかけ、アカウントも停止してしまい、ドメインを使うこともできなくなります。この時もクライアントやサーバー会社に始末書やクリーンアップ対応等の業務で地獄のような日々を過ごしたことを思い出します。

だからこそ、声を大にして伝えたい。

アップデートしてセキュリティ対策を万全に！

WordPressは、世界のサイトの48%を占める巨大プラットフォームです。だからこそ、セキュリティの進化も早く、その反面攻撃対象としても必ず入ります。これはサイトとしてのメリットデメリットであり、イタチごっこの世界。WPであろうがなかろうが、悪意と技術がある限り必ず付きまとう宿命のようなものです。

私がSWD（Soleil WordPress Dock）を進める理由は大事なことなんでもう一度。

自分がえらく痛い目にあったから

です！

まとめに

どうか皆様のサイトにそのような事がないように願いながら、SWDを進める理由をご紹介させていただきました。改ざんを含むサイトの事故は、誰にでも起こりうる危険性を孕んでいます。「何もしてないけど今動いているから大丈夫」の時が一番危険です。少しでも不安や気になる事があれば、お気軽にお問い合わせを！

相談までは無料！初回診断のみのご依頼ももちろんOKです！初回診断後は診断書をお渡ししますので、既存の制作会社様との打ち合わせや、自身で直すときの指標にもご利用いただけます！

サイトが壊れるその前に、ぜひSWDをご利用ください！

The post サイトの健康診断を勧める本当の理由 first appeared on 株式会社Soleil.

• 更新前に何を確認するべきか
• 更新後にどこを見るべきか
• 実運用サイトで問題が起きるのか

を観測することです。

リリース前に確認した検証環境

環境は以下の通りで、エックスサーバーでの「一般的」な環境での検証になります。うちはドメインとかもちょこちょこ操作していますが、今回はWPの更新なのでデータベースとPHPのバージョンとかその辺だけの確認でも十分です。

条件としてはこのくらい調べておけば、まず1段階目の判断として「アップデートしても大丈夫？」がわかります。

PHPとデータベースの環境が、WordPress推奨環境（PHP Version 8.3以上・MariaDB 10.6+ or MySQL 8.0+.・HTTPS）と少し違いますが、テスト環境では動いてたので特に問題ないという判断で入れてみることにしました。

ただしこれは「10.5で完全保証される」という意味ではなく、あくまで今回の構成・プラグイン群・運用状態での検証結果です。実際の現場では、WordPress推奨値と国内レンタルサーバーの実環境に差があるケースも多く、その意味でも「事前観測」が重要だと感じました。

ヘルスケアチェック

WordPressにはサイトヘルスケアという機能があり、解決するわけではないんですがレポートを吐き出してくれる機能があります。この機能を使えば現在の健康状態をある程度わかります。
こんな感じで、「これを解決するととっても健康体になるよ！」って教えてくれる簡易診断書です。簡単に解説すると

私のサイトの簡易健康診断結果です（SWDではもうちょっと突っ込んだ健康診断を行います）。

大丈夫そうじゃないかな？と思うので思い切ってアップデートしてみます（ローカルでは確認ずみ）。

アップデート

アップデートは非常に簡単です。極端な話、大丈夫な環境である確認さえ取れていれば（これが大変なのですが）、ボタンを押したらコンニチワ状態です。ものの30秒くらいで終わりますが、確認には日々メンテしている状態でも30分くらいかかります。

確認が不安であればSWDに

動作確認

動作確認ができるということは、致命的なエラーが起きてないということ。便りがないのは良い便り。早速動作確認を行いますが、チェックするのは以下のような点を、それぞれのサイトのサービスに合わせて行います。

こんな感じの点をチェックして回ります。この時点でどこかに表示のエラーがある場合は適宜対処しますが、事前に調査して事故が起きそうな場所を把握しておけば何も怖くはないです。

私のサイトの場合は、注文や問い合わせを受けた際の記録台帳を外部に作っていてそこをAPIで繋いでいますので、そこの挙動や、カスタムテンプレートを使っているところや、自作のmu-plugin（必須プラグイン）の挙動が問題なければ、概ね問題ないだろうという判断でした。

最終的にどのチェック事項もクリアになったのでアップデートに関してはほぼほぼOKと言えるでしょう。

まとめ

WP7.0のアップデートは確かに環境によっては危険なこともあるかと思います。ですが、事前に環境を整えてアップデートに耐えうる健康状態を一度作ってしまえば、そこからのアップデートは自身でも不安なく行なっていけるようになります。

さらに、WP7.0以降はAIとの親和性も高くなっていくので、より構造をシビアに考えられている環境が求められる段階でもあります。この機会に是非、アップデートを備えた健康診断をご検討ください！

あとがき

7.0にアップデートした後、念のためにClaudeにfunctions.phpの状況を監視してもらって感想を聞いたら、「危険３箇所」「標準化からのズレ4箇所」「その他2か所」と、多分100点満点中60点くらいの指摘をされました。

言い訳ですが新機能追加した時に結構いじったからなあ。。まあ、毎日いじってたってこの位の点数つけられちゃうってことでさらに言えば、こういった「少しずつ積み上がるズレ」は、普段サイトが動いていると気付きにくいものでもあります。今回改めて感じたのは、「壊れてから直す」より、「壊れにくい構造へ少しずつ整える」ことが大事ですね。

はい！直しまーす！

The post WordPress 7.0へ実際に更新してみた｜事前チェックから更新後確認まで first appeared on 株式会社Soleil.

ただし、事前にサイトの健康診断や整理を行っておけば、必要以上に不安になる必要はありません。むしろ、アップデートによる性能向上や安全性向上などの恩恵を受けやすくなる可能性もあります。今回は、WordPress 7.0に向けて予想される変更点や、事前に確認しておきたいポイントについてまとめていきます。

WordPress 7.0とは何か

WordPressが現在の6.9から7.0へ変わるにあたり、公式の変更内容を簡単にご説明します。5.0の時のように「Gutenberg登場！」という大型変更ではなく、「WordPressの思想設計が次のフェーズに入る」というイメージでしょうか。具体的には

• Gutenberg Phase 3（共同編集機能・ブロックエディタの成熟）
• PHP要件の整理・モダン化
• AI連携を見据えたAPI整備
• 管理画面や内部構造の近代化

という感じで、このあとちょっと詳しく説明させていただきます。

わかる人にはわかる的な表現ですが、5で大きく舵を切ったブロック要素を磨き上げた感じで、運用思想を磨き上げるとともに、AI介在も視野に入れた設計思想にグレードアップって感じっすかね。AIと繋がっちゃうのはもうスタンダードになるってことですな。
ルールというか、考え方を強化したアップデートって感じかと思います。

Gutenberg Phase 3

ブロックエディタのGutenbergは5.0からの新機能で7.0ではより使いやすくなってる印象を受けました。共同編集機能とはいっても、まだ基盤が作られた段階で、「チーム運用」にシフトしていくっていうイメージらしいです。

GoogleDocmentのようにリアルタイムにみんなで編集可能だよっていうのの一歩手前って感じだそうです。

PHP要件の整理・モダン化

PHP要件の整理・モダン化とは、簡単に言えば「古いサーバー環境を少しずつ卒業していく流れ」です。
WordPress 7.0では、PHP 7.2 / 7.3系のサポートが終了し、最低サポート環境がPHP 7.4以上へ引き上げられます。
これは、WordPress本体をより安全に、より現代的に動かしていくための整理です。ただし、古いテーマやプラグイン、昔のままのカスタマイズが残っているサイトでは、このタイミングで不具合が表面化する可能性があります。

画像のようにエラーになることがあると思いますが、コレはWordPressが悪いんじゃなくて、古いサーバーの状態だよって言ってる感じです。

AI連携を見据えたAPI整備

これはAIがWordPressを作ってくれるよなんて話ではなくて、プラグインなどのサードパーティ製品や外部サービスと繋がる前提に進化したよ！っていう意味合いが強い感じですね。

ページ内の構成をHTMLで直接打つ時には「AIだったらここをちゃんとした構造にしないと理解しないな」って考える必要があったのを、WordPress側が「そこを見据えた構造」にしておいてくれているという認識が正しいかもしれません。

これは人間にとってもメリットがあり、「誰が見ても分かりやすい構造」を作りやすくなる方向とも言えそうです。

管理画面や内部構造の近代化

エディタ周りも進化しています。基本的なCSSは組み上げていく中で大丈夫だと思うけど、ところどころ記事なんかでイレギュラーな部分なんかは、とても役立ちそうです。

ブロックエディタに寄せているのがわかるけど、HTMLとCSSが煩雑になって事故を起こすくらいなら、Gutenbergに乗り換えちゃった方がおすすめな気はしますね。

私は結構前からブロックエディタに乗り換えてます。（もちろん直打ちもする時ありますよ）

実はコレ以外にもまだまだ新機能はあるのですが（theme.json中心になったり裏で動いているData Viewsが構造化されたものを扱いやすくする感じ）、特に目立ちそうな新機能の紹介です。

ふと昔のアップデート禁止文化が思い出される

以前記事で書いた、「WordPressはアップデートしないで！の謎文化の回」でもお話ししましたが、当時はそれが悪かったわけではなく、むしろ“柔軟に作れる”ことがWordPressの強みでもありました。でも今はメジャーアップデートだからこそ、気をつけないとならないことが多いです。

• 制作会社もちょっと様子見
• functionに色々書きすぎ
• PHPのバージョンアップに対応できるかわからん
• CSSがめちゃくちゃ状態

これでは、新しいWordPressの新バージョンの恩恵を受けることはできませんし、何よりPHPは実質7系統の環境を足切りしているので、いつかアップデートを余儀無くされるだろうなあという感想です。

来るAI時代や、セキュリティ的な目線からもあまり推奨できない感じだなと正直思います。

【SWD記事】謎文化だった「WordPress更新しないで！」という不思議な圧 - 株式会社Soleil

私がデザイナーとして就職したのは約20年前の2007年ですが、その頃はまだ、WEBサイトというのは「看板」の役

株式会社Soleil - WordPressを中心に、Web運営を支えるサービスとプロダクト

健康診断（SWD）のおすすめ

実際にLocak環境で操作してみた感じでは、然るべき対応をしていれば恐るるに足らずではあるんですが、それでも自分のサイトでやってみるには事前調査はしてあります。サイトの健康診断はかかしておりません。

正式リリース前にBeta版でローカルにて実装を確かめていますので、概ね危険性がない確認をとって私もアップデートをしていくと思いますが、何より「今動いているからOK」という状況でサイトを運用しないことが大切です。

かならずアップデートをしないといけない時が数年以内にやってくるはずですが、PHPの足切りなんかは戻らないだろうと思うし、そもそもサイトの構造が古すぎたり、壊れかけだったりしたら、アップデートしただけで大事故に繋がりかねません。

今後のWordPressは、「更新しないで延命する」より、「更新できる構造を維持する」方が重要になっていくのかもしれません。

すこしでも不安がある場合はお気軽にSWDにおといあわせください！アップデートに備えた健康診断を絶賛受付中です！

The post WordPress 7.0時代が来る前に、サイトの“健康診断”をしておいた方がいい理由 first appeared on 株式会社Soleil.

 お話の前に「標準化」について触れておきたいと思います。

標準化とは？

Soleilでは標準化というのを2つの意味で捉えています。

と言う感じで認識を分けているイメージです。

その基準に則って、ジムサイトの設計を実際の形に落とし込んでいきました。今回は特に、

• ChatGPT（当社では「乃木さん」と呼んでいます）
• エージェント作業員の「Codex」

この2つをフルに活用しながら、構造を整理した実例の紹介です。

作業自体はそこまで複雑ではありませんが、 「どう分解して、どう進めるか」ここを間違えると一気に面倒になります。逆に言えば、この部分を整理できれば、 オペレーションはかなり楽になるはずです。一人でも5人分くらいの作業短縮！今回は、そのプロセスを実例ベースでご紹介していきます。

まずは作業場所を作ります

今回の作業は案件の時間的に余裕がありましたので、すべてローカル環境で行いました。WordPressの修正や構造変更を直接本番環境で行うと、意図しない表示崩れや不具合がそのままユーザーに見えてしまうためです。そりゃそうですわ。

特に今回のように、「構造の見直し・テンプレートの変更・カスタム投稿の追加」といった作業を行う場合は、 ローカル環境で検証しながら進めるのが前提になります（にしておいた方が絶対いいです）。

小規模な制作では、そのまま本番で触るケースも少なくないと思いますが、今回のように「標準化」や「構造整理」を行う場合は、ローカル環境を用意しておくことで、 安心して壊せる状態を作ることができます。

入れるソフトウェアはこれがおすすめ

Local

ローカル環境を自分のPCにつくりたいなら、これを私は使っています。「Local」っていうソフトなんですが、基本無料でWordPressを自身のPC上で動かせるソフトという感じです。そのほかにもMAMPとかいろいろありますが、MAMPほど深く開発環境を欲しているわけではないので、「とにかくローカルで動く」を前提にLocalを選択しました。

ちょっと自分のPCにWPを入れたいなあという人がいたら、Localくらいの方が楽ですよ。公開済みのサイトじゃそうはいかないですが、「安心して失敗できる環境」があると作業の質が向上します。

場所ができたので、状況と工程を整理しましょう

場所ができたので、実際にやる工程を説明していきます。工程を知れれば、物事は処理しやすいですよね。工程は全部で6つです。

工程1〜3はもどかしいが基本的には「調査・考える」時間。工程4〜5から実装の工程。工程6は一人でデバック。こんな感じに進めていくのが修正・標準化の工程ですかね（一般的と言うか社内ではこうって言う感じです）。

この全工程で起きること

工程として分解してますが、やっていることは全て「標準化してから機能追加（検討・実装）」の繰り返しです。その機能はどこにつける？を常に検討しながら進んでいます。

WordPressは便利です。自由度が高すぎるくらい高いので、あまり言うべき言葉じゃないですが「なんでもできちゃいます」。まあその分労力とお見積りが、、、、と言うのもありますけどね。ただ前の記事でも言いましたが、WordPressに全振りや、プラグイン依存、親テーマ依存なんてことになると、とても危険なので、やはりやり過ぎにならないように安全な設計が必須です。

なので、「標準化してから機能追加（検討・実装）」が大切なのですね。実際こうやって標準化しておいたので、後述になると思いますが、店舗情報の追加やカスタマイズなどの拡張性は抜群になり（200店舗とか登録する！ってなっても問題は起きなそう）、店舗ページのデザイン変更をしても本体のスタイルに邪魔をしないなど、運用者にも制作・保守側にも利点の多い更新となりました。

まとめ

工程はこんな感じですが、次回はもう少し突っ込んだ各工程の伝えたいことをご説明したいと思います。今回紹介している修正は、SWDというサービスが始まる前の事案です。ですが、この時点でSWDの基準のような仕組みはできていて、サービスとして展開しているSWDと同じことをやっているよ言える内容です。

自身のサイトや自社のサイトの健康診断・エラーが発生する前にやっておけば安全な対策として、ぜひSWD（Soleil WordPress Dock）をご利用・ご検討いただければと思います。

The post 【問題点の発見と標準化】WordPressサイトメジャーアップデートした話② first appeared on 株式会社Soleil.