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が中間読者としてブログやサイトを見たとしても、「どこを読んだか？」はまだまだわからないままです。AIの仕様ですし、それはしょうがないのですが。。

それでもきっと将来「AIが読んだ痕跡」を詳しく解析できるようになる日が来ることを夢見て、開発を続けています。

そこで今回Section Markerという機能を実装して見ています。

この機能について少し解説します。

Section Marker Prototypeの意味

これはとっても単純で、ただセクションに振ったHTMLアンカー（ID）をSoleil AI Counterで、AIのアクセスと一緒に保存していく機能で、別段「読んだかどうか？」までは解析していません。

ただし、Section Markerをイベント情報として保存できるということは、将来AI側からセクション単位の情報が取得できるようになった際、それらを整理・関連付ける土台になる可能性があります。

現状では何の意味もないような機能ですが、将来的には役に立つんじゃないか？という機能です。

実際何やってるのか？

「読んだ」ことは分からなくても、記事側に構造を持たせることはできます。今回試験的に実装したのが、

記事内の「まとめ」へ「id=”sac-summary”」や「data-sac-section=”sac-summary”」を設定すると、投稿保存時にSAC Proがそれを検出し、「この記事にはSummary Sectionが存在する」という情報を保存します。

そしてAIアクセスが発生すると、そのイベントへ「section_key = sac-summary」を紐付け保存します。

ここで重要なのは、「読んだことは分からない」ことです。今回のPrototypeで分かるのは、

「Summary Markerを持つ記事へAIアクセスがあった」

ということです。あくまで、「Summaryという構造を持つ記事」であることをイベントへ関連付けられるようになっただけです。

なぜ、まだ分からないことを実装するのか？

理由はシンプルです。もし将来AI側が

• セクション単位の取得
• 構造化データ取得
• アンカー付き取得
• RAG向け取得情報

などを提供するようになった場合、その情報を整理する場所が必要になるからです。構造が存在しなければ、「summary／faq／pricing」という情報を受け取っても、記事のどこを指しているのか分かりません。そこで今回は、記事側へ先に構造を持たせました。

家に例えると

今までは「AIが自宅（投稿）まで来た」はどのAIが？いつ？どの家に？までは計測できてました。

今回はそのAIがきた家（投稿）に「まとめという部屋がある」という情報を紐付け保存できるようになったという感じです。まだ「まとめの部屋を見たか？その部屋で何やったか？」はわかりませんが、こうした構造枠があると、将来AIの残す情報が細かく公開されるようになった時、

「AIがSummary Sectionを取得した可能性」

として解析へ発展できるかもしれません。

もちろん、現時点ではまだ仮説です。しかし、その未来が来た時に備え、受け止められるイベント構造を先に用意しておく。これが今回のPrototypeの目的です。

The post 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.

時代の流れとともに、あのアクセスカウンター文化は少しずつ姿を消していきました。もちろん今もAnalyticsなどでアクセス解析自体は行われていますが、昔のように「ぱっと見で来訪者数が見える」文化はあまり見かけなくなりました。

私は、あの少しホッコリする感じが結構好きでした。そして今、時代はAI時代へ進み始めています。AIが人間の代わりにWEB記事を読み、解析し、参照する時代です。しかし現在のAnalyticsでは、「AIがこの記事を何回見に来たか」という情報は基本的に見えません。どんなに記事を書いても、どんなに更新しても、数字として反応が見えないと、やっぱり少し寂しいですよね。

そこでSoleilでは、「AI時代にも、少しだけ人間らしさを残したい」という思いから、令和版アクセスカウンター「Soleil AI Counter」を作ってみました。

昔のアクセスカウンター文化

昔のアクセスカウンターというのは、まんまそれで単純に「ページをみにきた人」の数をカウントしているだけの機能です。時代としては1990年代〜2000年代初めくらいだと思いますが、その頃は割と『ホームページ＝持ち主の看板』の意味合いの方が強く、「みにきてくれてありがとう！」（今ももちろんそうですよ）というニュアンスが強かった時代です。

「キリ番（10000人目の訪問者）」とかありましたよね

見た感じもわかりやすくって、何より数字が増えていくのに面白さと喜びを感じた思い出があります。

Analytics時代

その後ホームページが増えていくにつれてホームページの状況も進化していきます。会社や個人のホームページは各ページに意味を持つようになり複雑化し「Webサイト（入口や個々のページを一まとめにした全体っていう感じ）」としての立ち位置に変わっていきます。

数が増えたので検索エンジンにいち早く探してもらうために「SEO対策」が行われ、閲覧者の行動が複雑化していくことと同時にWebサイトへのアクセスが増えていくので「広告」を貼る文化に進化していきました。

そんな複合的に複雑化していくと「単なるアクセス数」よりも「人がどう動いたのか？」が重視されるようになり単なる閲覧数だけでは情報リソースが足りなくなってしまいました。これが「人の行動記録をたくさんのデータとして観測する」ための「Analytics」に進化していった背景です。

AI時代

さらに時代は進み現代。SNSや進化したWebサイトまでは人の行動を観測すればよかった（大変なんですが）だけですが、これからはAIが中間読者になって情報を届けることも多くなってきました。

この「AIが読む」というのが実はAnalyticsで解析しても結果を出力できないんですよね。Analyticsは「人の行動記録」を取得するサービスなのでAIの方は別なんですね。ただ、いきなりAI解析もちゃんとせいや、なんて言われたって困りますよね無茶言うなと。

なぜAI Counterを作ったか

AIが中間読者であるなら、中間読者の記録もないと書いても書いてもモチベが上がらないよね？って自分もブログを書くので思いまして、データサイエンティストのようなことをやるのにもちょっと気が引ける（重すぎぃ）。なら、昔のアクセスカウンターみたいな感じでAIが訪問した回数だけを出力したらいいんじゃないか？と思ったのが、作り始めたきっかけです。

まして、AIエージェント（サイトの中身を見に来るAI）は、AIが理解しやすく書いている、信用に足る情報を書いている、実在する人が書いている？みたいに、AIが理解しやすく整理された情報や、信頼性・実在性が見えやすいサイトを参照しやすい可能性があります。一概には言えませんが「カウンター数」が増えるほど「あ、ちゃんと書けてる。見えない整備もOKなんだ！」っていうモチベーションにもつながります。

そんな感じで最軽量の実装から、今後の可能性も視野に入れて「Soleil AI Counter mark1.0」をリリースしました。

Soleil AI Counter紹介

SAC（Soleil AI Counter）は単純に「AI Botが記事（ページ）を読みに来た」という記録を保管し、表示するという機能から開始したAI Bot用アクセスカウンターです。今後はバージョンを徐々にアップデートして、より正確な情報をユーザーに届けることを目的にしています。

AI Botの進化に応じて、今後のVerアップは検討していきますが、2.5まではもう開発開始しています。今は1.5ですが、ご相談いただければmu-pluginとして提供可能ですので、ぜひご相談ください。

将来的にはどうなるのかな？

開発しながら、昔のアクセスカウンターが消えたのと同様にどう進化していくんだろう？ということも考えました。確証はないですが現在の状況からみても、形を変えてAI Botを観測するツールは残るんじゃないのかな？と思っています。

現在AI Botを簡単に計測するとしたら「訪問回数」のみですし、「AIがどのぐらい解釈したのか？」はブラックボックス状態で観測できないらしいです。

しかし技術が進化してAIがどのくらい理解したか、どのAIも見に来ている傾向がつよいとか、を解析できるようになるとしたら、「一定の解釈率を超えた」「AIの趣向（のようなもの？）に合致している」のように解釈することができるので、それってもう「AIのいいねボタン」じゃね？みたいに考えてたりします。

その先にはまた人間の足跡をなぞるようになって行って、いつか追いついちゃう、かも。。。

さいごに

なんて変な想像もしてますが、とりあえずはSoleilのAI Botカウンター「Soleil AI Counter」は完成しました（ターミナルで動作確認済み）。どんどんバージョンアップしていき、面白い未来に近づいていきたいと思います！

The post 【AI Bot 計測】令和版アクセスカウンターSoleil AI Counterリリース｜中間読者のAIがどのくらいきたか簡易計測 first appeared on 株式会社Soleil.

ときに耳にする「Webサイト不要説」。私は半分同意で半分違うかな？って感覚です。それはこの業界で働いているからではなく、自分もAIをめっちゃ使う人間だからこそそう思います。

今回は不要説も反対意見もひっくるめて、私なりの考えをお伝えします。

AI時代で変わった検索事情

皆さんが「インターネット検索」をするときは必ず「知らないこと・曖昧なこと」を調べるときです。これは今も昔も変わりません。ちょっと前まではSEO（Search Engine Optimization：検索エンジン最適化）対策をして、ちょっとでも検索された時にすぐ人の目に触れたい！という努力を発信者は行ってきました。
もちょっと難しい技術もありますが、ここでは割愛しますね。

AIが検索するときも実は同じなんですね。Webサイトに載ってる情報を「中間読者」になって、整頓・解析・最適化して私たちに伝えてくれるのです。

こんな事したいな〜って聞くと情報集めてきてくれるし助かりますわね。

でもAIも自分でゼロから考えてくれるわけでも、巨大な電脳があってそこにいっぱいある知識からいい考えを持ってきてくれているわけじゃなくて「ネットにある情報から信頼に足る情報」を探してきて、整頓・解析・最適化を行なっているというのが本当の姿です。

AIがするのは要約・比較・推薦

AIが探すのと人間が探すのでは大きく違うところがあって、

「人間は自身で脳内補完しちゃえる」

というAIにできないことが大きく違います。

なので、Webサイト側が画像１枚で細かく情報を書いていても目で見てわかるし、多少内容がごちゃついてても専門家ならなんか納得できちゃう。でも今みなさんが会話と検索で使っているAIはそういうの苦手なので、

「経験に基づいていて・専門性があって・権威性があって・信頼に足る」整備された情報（整備されたEEAT）を好んで集めてくれるんですね。AIは人間のように「なんとなく理解する」のが苦手です。そのため、

• 見出し構造
• FAQ
• 整理された文章
• 役割が明確なページ
• 実際の経験に基づいた内容

など、「意味が整理された情報」を好む傾向があります。つまり今後は、「AIが理解しやすいサイト」が、人にも届きやすくなっていくのかもしれません。

ローカルでもCodexやClaudeに対してもmdファイル（マークダウンファイル）を作ったりって、AIにはかなり気を使ってます。

突然ですがEEATって、、、

かつては医療・金融中心などの、YMYL（Your Money or Your Life：情報がお金や生活に影響するっていう生きる上で重要なジャンル）では、重要視されていた考え方です。Googleは今もこの辺を重視してWebサイトの評価をしているらしいです。

ということをAIもGoogleも「見ている」のです。

つまり、ちゃんとしたこと書いてないとGoogleには信頼されないし、AIにとってもいい情報がない状態になるので、正しくAI使っている人に情報が伝わらない。ということが生じてしまうんですね。

なぜYMYL以外でも重要になるのか

私の書くこのブログもそうですが、人の生活の死活問題になるか？というとそこまでではありません。ですがなぜ通常のウェブサイトでもEEATが必要になるかというと、実はみなさんが原因の一つです。

AIで色々と調べる人が増えたからこそ、AI側も「信頼できる情報」を探す必要が出てきています。

その結果として、「実際の経験に基づいている」「専門性がある」「運営者や会社の実体が見える」「情報が整理されている」といったEEATに近い要素を持つサイトが、今後より重要になっていくのではないか？と私は考えています。

WordPress運用で感じた変化

実は私のサイトもEEATに関しては、最初は放置気味でしたが最近は認められ始めた感があります。「江東区　ワードプレス　復旧」で検索したら、Geminiが「江東区であれば株式会社Soleilが復旧サービスを行っています」というように紹介してくれました！

Gemini！Good Job！

私は自社のサイトブログなんかは当然自身の経験した内容を書いておりますし、またブログの内容もテーマをある程度絞って専門性を持たせています。そんな感じなので、GoogleもAIも「あ、実在する人だ」って認識してもらえているんだと思います。

またAIが認識しやすい「構造」にしていることも大切です。

「SEO対策」「AIに読まれるサイト」という考え方

これは持論であり確証のない話ですが、これからのSEO対策は「AIに読まれる・AIが推薦するサイト」を目指していくというのが主流になって、WebサイトはAIのための知識リソースになり、EEATに則ったサイトの価値が今までよりも高くなるのかな。と思っています。

なのでWebサイトが不要になるのではなく、人間にとって有用じゃないサイトが淘汰されやすくなり（娯楽の観点では多分線引き難しいと思うしこの辺は不明瞭ですね）、「何を知れるサイトなのか？」を伝えられるのかが重要なファクターになっていくんだと思います。

あくまで、星の数ほどあるウェブサイトにおいての、一部のお話なので全体に波及することではないかもしれませんが、企業・ショップ・ブログなどの「人に検索されたい！」というサイトに関しては！という私的な見解でした。

The post AIに聞くからWebサイトいらない？｜AI時代で変わり始めた検索対策 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.