2026年10月22日 21時時点の情報に更新しました(初版は9時時点)

10月21日の夜、世を騒がせたPHPの脆弱性をまとめます

エックスサーバーの管理画面に入れませんでした
PHP本体に見つかった脆弱性「php2shell」の公表に備えて、エックスサーバーが公式サイトや管理画面を止めていたためです
javeo.jpのほうは、普通に表示されたまま

結論から言うと、エックスサーバーは22日6時45分のお知らせで、PHP 8.2〜8.5の修正パッチを対象のすべてのサーバーに当て終えたと発表しています
古いバージョンも14時までに5.6〜8.1の適用が終わり、残るのは5.5以下だけです
私が借りているサーバーでも、入っているPHPのうち8.2〜8.5は朝の6時16分に、8.1以前は10時に入れ替わっていました

管理画面は22日の9時半から順に再開し、公式サイトも20時10分から戻っています

PHP本体を直すのはサーバー会社です
利用者がやることは大きく2つ
使っているPHPのバージョンの確認と、サイトの点検

php2shellとは PHP本体に見つかった2件の脆弱性

php2shellは、PHP本体に見つかった2件の脆弱性(CVE-2026-109618とCVE-2026-109619)の通称です
研究者や報道が使う呼び名で、PHP公式の告知には出てきません

PHPは、多くのWebサイトを動かしているプログラミング言語
WordPressもPHPで動いているので、php2shellはWordPressのサイトにもそのまま関わります
PHP公式の評価は、深刻度を表すCVSS v4.0で9.2(Critical=緊急)です

• CVE-2026-109618は、メモリが足りなくなったときの後片付けで、作りかけのデータを正しいデータとして扱ってしまう不具合
• CVE-2026-109619は、前のアクセスで使った情報がメモリの解放後も残り、次のアクセスの処理がそれを使ってしまう不具合(メモリの中身が漏れることもある)

どちらも、ログインも利用者の操作もいらない状態で、攻撃者にサーバー上のプログラムを動かされるおそれがあります
PHP公式は、PHPの動かし方(PHP-FPM・mod_php・CGIなど)を問わず、Webのアクセスを処理しているPHPをすべて対象としています
実際に攻撃が確かめられたのはmod_phpとPHP-FPMで、リスクがいちばん高いのはmod_php

修正版は8.2〜8.5の4つ 8.1以前は新しい版が出ない

PHP公式が出した修正版は、サポート中の4系列ぶん

※7.4・8.0・8.1には、ソースから自分で組み立てる人向けの最小限の修正だけが公開されています

PHP公式のリリース告知には「There are no complete mitigations, updating is the only safe choice.」とあります
完全な回避策はなし
安全なのは更新だけです

公式が影響を受けるバージョンとして挙げているのは、この8.2〜8.5
ただ、7.4〜8.1にも修正を出している以上、8.1以前なら影響が無い、とは読めません
GMO Flatt Securityや発見者のWizは、5.x系を含む古いバージョンにも及ぶ可能性を指摘しています

予定の23時より早く公開された

当初の予定は日本時間の21日23時でしたが、遅くとも22時34分には、GitHubでPHP公式の勧告が公開されていました
報道やエックスサーバーの案内では「23時ごろ」とされていて、1時間ほどずれています

公開前に情報の一部が出回っていました
PHP側も、詳細が公になったり悪用が出たりしたら前倒しすることがある、と予告していました

見つけたのはセキュリティ企業のCalifとWizで、AIを使って発見し、OpenAIの取り組みの枠組みで対応した、とGIGAZINEは伝えています
CVEの記録では、OpenAIも発見者に名前があります

php2shellで最悪どうなる？ サーバーの乗っ取りと情報漏えい

攻撃が成功すると、サーバー上でPHPを動かしているアカウントの権限で、攻撃者が好きなプログラムを動かせます
サイトのファイルの書き換えや、データの持ち出しにつながります

日本ハッカー協会の杉浦隆幸代表理事は、TBS NEWS DIGの取材に「攻撃が成功しますと、サーバーを乗っ取ることができるほか、データを盗んでさらに暗号化することも可能ですし、破壊することも可能となる」と話しています

CVE-2026-109619には、メモリの中身が漏れるおそれもあります
メモリに載っているのは、PHPがそのとき扱っている情報
たとえばWordPressなら、データベースのパスワードもPHPが読み込んで使っています

厄介なのはその先です
もし入られていたら、裏口(外からサーバーを操作するための不正なファイル)を置かれているかもしれません
PHPを修正版に入れ替えても、先に置かれたファイルは消えません

ただし、PHP公式の評価では攻撃の複雑さは「高」で、攻撃が通るための条件もあるとされています
どのサイトでも簡単に乗っ取れる、とまでは言えない評価です
ただしmod_phpでは、既定の設定のまま攻撃が実証されています

修正版の公開前から、ホスティング事業者から悪用の事案が報告されたとの情報(詳細は非公開)もあります
一方で、侵入の成功を具体的に示した公表は、22日の時点で見つかっていません
IPA(情報処理推進機構)も、修正版の公開前に出した注意喚起の中で、悪用した攻撃を確認しているわけではないとしています

ジャベ雄

試みと成功は別物ですが、入られていないとも言い切れません

メンテナンスのために止まったサービスの例

21日の午後から深夜にかけて、ネットショップ・イラスト投稿・ゲームなどのサービスが、PHPの修正版の公開に合わせて相次いで止まりました

piyologは22日午前の更新で、告知を確認できた211の組織を業種別にまとめています
ゲームやホスティングの会社のほか、国の機関・金融機関・自治体の名前も

21時55分には、高市総理がXで「皆様に、今夜に対応して頂きたい大至急のお願いです」と投稿しました
投稿は、Webサイトの一時停止もリスクを下げる有効策の一つとしています
ITmedia NEWSは、首相が個別の脆弱性でXから直接呼びかけるのは異例と伝えています

目立ったのは前倒し
ウマ娘とグランブルーファンタジーは、23時の予定を22時に早めています

※1 pixivの告知にPHPの記載は無く、理由は「サービスの安全性確保のため」(報道ではPHPへの対応として扱われています)
※2 DMM版・GREE版を除く
※3 22日3時5分に、一部のサーバーでサイトも一時的に止めると告知

同じ時間帯には、さくらのレンタルサーバ・ConoHa WING・mixhostもメンテナンスや一部の停止をしていました
ただ、3社とも告知にPHPの名前は無く、今回の件のためだったかははっきりしません

エックスサーバーの対応と、借りているサーバーで確かめた結果

エックスサーバーは、利用者のサイトとメールを動かしたまま、公式サイトや管理画面を止めて、PHPの修正を進めました
停止から8.2〜8.5の適用完了の発表までは、およそ15時間でした

管理画面は止まり、サイトとメールは動いていた

停止は21日(水)の16時から
お知らせの題は「予防的な安全対策に伴う公式サイト・管理画面等の一時停止のお知らせ」です

管理画面に入れないと、サイトまで止まったのかと心配になります
公式のお知らせの、利用中のサーバーについての記述がこちら

お客様のご利用サーバーは稼働を継続しており、Webサイトの表示やメールソフトでの送受信に影響はございません。— エックスサーバー「予防的な安全対策に伴う公式サイト・管理画面等の一時停止のお知らせ」

私のサイトも、普通に表示されていました

止まっていたのは次のとおり

• 公式サイト(各種サービスサイト・コーポレートサイト)
• アカウント管理画面・サーバーパネル
• WEBメール・ファイルマネージャ
• 各種API・MCP
• 新規申し込み・契約更新・支払いなどの手続き

サポートも一部だけでした
メンテナンス中はチャットとお問い合わせフォームが使えず、電話も情報を参照できないため具体的な案内はできないとされていました
契約更新や支払いは再開しましたが、20時10分の時点でも一部の決済手段はメンテナンス中なので、期限が近い方は確かめておくと安心です

メンテナンス中のお知らせには「本対応は当社サービスに対する不正アクセスの発生に伴うものではございません」ともありました
止めた理由は不正アクセスではないとの説明です
利用者のサイトが無事だった保証とは別の話

同じ夜、ロリポップ!は22日3時5分に、一部のサーバーで利用者のサイト自体を一時的に止めると告知しています
エックスサーバーは、利用者のサイトの表示とメールは止めませんでした

21日16時の停止から22日20時10分の再開まで

公式ニュースの「主な対応経過」をもとに、流れをまとめました

※公式Xの投稿の時刻は、この表と数分ずれるものがあります(6:44・12:08・14:03)

修正版が出ていない古いバージョンについて、エックスサーバーは22日1時22分の公式Xで「弊社独自の修正を進めております」と説明していました
公式の修正版がある8.2〜8.5から当てて、古いバージョンは独自に作った修正を後から当てた流れです

ただ、PHP公式は、緩和策は攻撃の経路を減らすだけで安全にはならないとしています
8.2〜8.5は22日6時45分まで、7.4〜8.1は12時まで、5.6〜7.3は14時まで、この状態でサイトが動いていました
5.5以下は、まだ途中です
20時10分の時点でも、修正の作成と検証が続いています

管理画面は9時半から順に再開しましたが、12時8分の公式Xでも、アクセスが集中して一部つながりにくいと案内されていました
私も昼は入れませんでした
20時10分の時点では、サーバーパネルも再開(一部の機能はメンテナンス中)となっています

借りているサーバーのPHPは、10時までに全部入れ替わっていた

エックスサーバーの共用サーバーには、サーバーパネルの「PHP Ver.切替」で選べるように、いくつものバージョンのPHPが1台の中に並んで入っています
サイトが使うのは、そのうちドメインごとに選んだ1つだけ

22日の8時43分と21時27分の2回、SSH(サーバーに直接つないで操作する方法)で私が借りているサーバーに入り、並んでいるPHPのバージョンを1つずつ確かめました

8.2〜8.5は、どれも修正版の番号でした
ファイルの日時は4つとも6時16分で、6時45分の「適用完了」のお知らせの約30分前

8.1以前は、8時43分の時点ではまだ入れ替わっていませんでした
21時27分に見直すと、8.1・8.0・7.4のファイルは10時0分に入れ替わっていて、組み立てた日時も22日の4時台に変わっていました
番号は8.1.34のまま

8.1以前は、修正されても番号が変わりません
公式の新しい版が出ない系列に、エックスサーバーが独自の修正を当てたためと考えられます

どれもサーバーに入っているファイルの話で、自分のサイトがこのうちどれを使っているかは、次の節のサイトヘルスで確かめられます
javeo.jpが使っていたのは、修正版の8.3.36でした

アクセスログ(サイトへのアクセスの記録)も見ました
POST(データの送信)が続いた記録はあっても、似た形のアクセスは19日・20日にも来ていました
php2shellを狙ったものかは判定できず
アクセスログには送られたデータの中身が残らないので、ログだけで攻撃の有無を見分けるのは難しいと感じています

※XServer VPS・XServerビジネス・シン・レンタルサーバーなど、ほかのサービスの扱いは未確認
VPSはPHPを自分で入れて管理するサービスなので、共用サーバーとは事情が違うはずです
使っている方は、各サービスのお知らせを見てください

ジャベ雄

8.1以前は、番号を見ても直ったかどうか分かりません

エックスサーバーの利用者がこのあと点検すること

最初に確かめたいのは、サイトが使っているPHPのバージョンです
8.2〜8.5なら修正版に入れ替わっているはずで、8.1以前なら8.2以上への切り替えを考える場面

自分のサイトのPHPが何系か、すぐに答えられますか？

ジャベ雄

確かめるだけなら、サーバーパネルに入らなくてもWordPressで足ります

STEP

サイトが使っているPHPのバージョンを確かめる

確かめられる場所は、サーバーパネルの「PHP Ver.切替」と、WordPressの管理画面の2つ
サーバーパネルは22日の昼の時点でもつながりにくかったので、ここではWordPressで見る方法を紹介します

WordPressの管理画面で、「ツール」→「サイトヘルス」→「情報」タブ→「サーバー」の順に開くと、「PHP バージョン」の行にバージョンが表示されます

私のサイトは8.3.36で、修正版になっていました
8.2〜8.5なら、表示されたバージョンが上の修正版の表と同じか、それより新しければ修正済み
8.1以前は判断できません
修正されても番号が変わらないからです
エックスサーバーの発表では、5.6〜8.1は22日14時までに適用が終わっています
サイトを複数持っているなら、サイトごとに見ておくと確実です

phpinfoを表示するファイルを置く方法もありますが、消し忘れるとサーバーの設定が外から見えてしまうのが難点
サイトヘルスなら心配無用です

STEP

8.1以前なら、8.2以上に切り替える

8.1以前のPHPには、PHP公式の新しい版が出ません
8.1のサポートは、2025年12月31日で終了済み
7.4・8.0・8.1向けに出たのは、ソースから自分で組み立てる人向けの最小限の修正だけです

エックスサーバーは5.6〜8.1にも独自の修正を当て終えましたが、PHP公式のサポートが戻るわけではありません
実際、8.1以前は修正の完了が8.2〜8.5より5〜7時間遅れました
次に同じようなことが起きたときも、古いバージョンほど守りの薄い時間が長くなります

切り替え先は、8.3以上がおすすめです
8.2のサポートは2026年12月31日までで、8.2を選ぶと2か月ほどでまた切り替えが要ります

• 8.3:2027年12月31日まで(すでにセキュリティの修正だけの段階)
• 8.4:2028年12月31日まで
• 8.5:2029年12月31日まで

長く使うなら、プラグインとテーマが対応している範囲で新しいほうを選びます

切り替える前に、使っているプラグインとテーマが新しいPHPで動くかを、配布元の案内で確かめておきます
切り替えの操作は、サーバーパネルの「PHP Ver.切替」で

STEP

WordPress本体・プラグイン・テーマを更新する

WordPressやプラグインを更新しても、PHP本体の脆弱性は直りません
直るのは、サーバー会社がPHPを修正版に入れ替えたときだけです

それでも更新は普段どおり
古いままのプラグインは新しいPHPで動かないことがあるので、先に更新しておくとPHPの切り替えも楽になります

更新ボタンを押す前の確認は、WordPressの更新前に確かめたい注意点が参考になるはず

STEP

知らない管理者と、覚えのないファイルの更新がないか見る

入られていた場合の手がかりとして、次の2つを確かめます

• WordPressの「ユーザー」の一覧に、知らない管理者がいないか
• サイトのフォルダやwp-contentの中に、身に覚えのない日時に更新されたファイルがないか(特にindex.php・テーマのfunctions.php・.htaccess・.user.ini)

ファイルの日時を見るなら、FTPソフトかファイルマネージャ
プラグインを更新しただけでも日時は変わるので、日時だけで改ざんと決めつけないようにします
逆に、日時は書き換えることもできるので、古い日時だから無事とも言えません

怪しいファイルを見つけても、自分の判断で消さないでください
消したファイルによっては、サイトが表示されなくなることも
WordPress公式のハッキングされたときのFAQも、取り除くなら使っていたのと同じバージョンを入れ直すこと、レンタルサーバー会社に確認を取ることを案内しています
見つけたときは、エックスサーバーのサポートへ相談するのが近道です

STEP

バックアップを確かめ、今の状態も手元に残す

エックスサーバーには自動バックアップがありますが、残しておける期間には限りがあります
心配なら、早めに今の状態を手元にも保存しておくのがおすすめ

WordPress公式のFAQも、元に戻す前に、今の状態を別に保存しておくよう案内しています
保存するのは、ファイルとデータベースの両方です
ファイルはFTPソフトで取れて、データベースはサーバーパネルから入るphpMyAdminで書き出せます

STEP

パスワードは、侵入の兆候があれば変える

上の確認で侵入の兆候が見つかったら、パスワードの変更は必須です
WordPress公式のFAQでは、WordPressの管理画面・FTP/SFTP・サーバーの管理画面・データベースのパスワードと、wp-config.phpの認証用キーを変える手順が挙がっています

兆候が無ければ、念のための扱い
エックスサーバーやPHP公式から、利用者全員にパスワードの変更を求める案内は見当たりません
CVE-2026-109619はメモリの中身が漏れることもあるので、気になるなら変えておくのも手です

STEP

エックスサーバーのお知らせを、ときどき読む

エックスサーバーは、利用状況によっては利用者にも追加の対策をお願いする場合があると案内しています
その際は改めて知らせるとしているので、公式のお知らせをときどき確かめておきます
5.5以下を使っている方は、修正がまだなので特に

自分でやらなくていいこと 暫定策の設定は試さない

修正版が出る前には、PHPの設定で穴をふさぐ暫定策もネットに出回っていました
共用サーバーの利用者は、次の3つには手を出さないのがおすすめです

• php.iniや.user.iniでsession.upload_progressを切る
• .htaccessでPHPの設定を書き換える・PHPを止める
• WordPressのメンテナンスモードで守ろうとする

共用サーバーの利用者が自分でやっても、効かないか逆効果になりやすいものばかりです

• session.upload_progressを切る方法は、同じ日のうちに単体では完全な対策にならないと訂正されています(窓の杜)
  PHP公式も、この種の設定はphp.iniやサーバー側で入れるものとして、.user.iniには頼らないよう書いています
• .htaccessでPHPの設定を書き換えると、PHPの動かし方によっては500エラー(サイトが表示できない状態)の原因に
  止め方を間違えると、PHPのファイルの中身がそのまま見えてしまうこともあります
• PHP公式によると、攻撃はWordPressなどのアプリのコードが動く前に起きうるため、PHPの上で動くメンテナンスモードでは防げません
  サーバー側でサイトへのアクセスそのものを止める一時停止(ロリポップ!が一部のサーバーでしたもの)とは別物です

PHP本体の修正は、エックスサーバーが当てています(5.5以下はまだ作業中)
利用者が自分で設定をいじると、サイトが表示できなくなる危険のほうが大きいと思います

エックスサーバーとWordPressの組み合わせを一から整理したいときは、契約からテーマの設定までの手順を別の記事にまとめています

あわせて読みたい

WordPressブログの始め方｜エックスサーバー＋SWELL 初心者向けにWordPressブログの始め方をまとめました、エックスサーバーのクイックスタートで約10分で開設し、テーマSWELLで見た目を整えるまでの全手順を、実際にこのブログを運営する私が解説します

まとめ PHPのバージョンを確かめてから、サイトの点検へ

php2shellは、PHP本体に見つかった2件の脆弱性です
エックスサーバーは22日6時45分にPHP 8.2〜8.5、14時までに5.6〜8.1の修正の適用完了を発表していて、残るのは5.5以下です

やることを4つに絞ると、次のとおり

• サイトヘルスでPHPのバージョンを確かめる
• 8.1以前なら、プラグインとテーマの対応を見てから8.2以上(できれば8.3以上)へ
• 知らない管理者と、覚えのないファイルの更新がないか見る(怪しいファイルは消さない)
• エックスサーバーのお知らせを、ときどき読む

WordPressやプラグインの更新だけでは、PHP本体の穴は直りません

AI検索に載りたいなら llms.txt を置きましょう、という記事をあちこちで見かけます
ただ、自分のサイトに置く前に調べてみたら、llms.txt は意味ないと言われるだけの根拠がひととおりそろっていました

Googleは「どのAIシステムも使っていない」という立場で、38,000サイト分の実測でも97%が一度もリクエストされていません
しかも、AIは置いていないサイトを探しに来ることすらしていませんでした

なのでAI検索に引用されたくて置くなら、いまのところ効果の裏づけはありません
ただ、Claude Code のようなコーディングエージェント向けだと話が変わってきます

llms.txt とは AIに読ませるサイトの案内図

サイトのルートに置く llms.txt は、AIに「うちはこういう構成なので、詳しくはここを読んで」と伝えるマークダウンファイルです
提案は Jeremy Howard 氏、初版の公開は2024年9月3日

狙いはシンプルで、広告やJavaScriptだらけのHTMLをAIに読ませる代わりに、要点だけを整理した場所を1か所用意しておこう、という発想
置き場所は /llms.txt が基本で、/docs/llms.txt のようなサブパスでも構いません

名前が似ているので robots.txt と混同しがちですが、役割はぜんぜん別もの

robots.txt が門番だとすると、llms.txt は受付に置いてある館内マップみたいなものです
置いたからといって入館者が増えるわけではない、というのがこのあと出てくる話につながります

中身はマークダウンで書く

仕様で必須とされているのは プロジェクト名のH1が1つだけで、あとは全部おまけです
概要をブロック引用で添えて、H2で区切ったリンク集を並べる、というのが標準的な形になります

# サイト名

> このサイトが何なのかを1〜2行で

## 主要な記事

- [記事タイトル](https://example.com/foo/): どんな内容か
- [記事タイトル](https://example.com/bar/): どんな内容か

形式がマークダウンなのは、人が読んでも分かるし機械もパースできるからです
仕様そのものは止まっているわけではなく、2026年8月10日に v2 が出ています

ジャベ雄

ここまでは、なかなか良さそうな仕組みに見えるんです

Googleは「どのAIも使っていない」と言っている

GoogleのJohn Mueller氏は、llms.txt を「現時点では完全に憶測の域」と表現しています
理由はファイル自体は何年も前からあるのにどのAIシステムも使っていないから、という指摘

Google の見解はここがはっきりしていて、llms.txt も著者情報版の llms-author.txt も使っていません
そのうえで氏が挙げていた判断の目安が、ちょっと現実的でおもしろかったです

要するに、需要が発生してから作っても遅くないという話なんです
出典はSearch Engine Journal の記事(2026年6月2日)で、氏の発言をまとめたものになります

ちなみに Mueller 氏が代わりに評価していたのは WebMCP のほうでした
すでにサイトへ来ているAIエージェントに、どうやって正しく作業させるかという発想の規格で、Chromeが対応しています

97%は一度もリクエストされていない

Ahrefs が2026年6月15日に公開した調査で、llms.txt を置いた約38,000サイトのうち97%が、1か月間まったく取得されていなかったという結果が出ています
今回いちばん効いた材料がこれでした

97% of those files received zero traffic in May 2026.

Ahrefs「We Analyzed 137K Sites: 97% of llms.txt Files Never Get Read」

出典は Ahrefs の調査記事
数字だけ見ると強烈ですが、どうやって測ったのかも明記されているので、そこも見ておきます

調査の方法と規模

対象は、Ahrefs のアクセス解析を入れていて2026年5月にトラフィックがあった 137,210ドメイン
各ドメインのルートを叩いて llms.txt が HTTP 200 で返るかを確認し、中身がちゃんとマークダウンのものだけを有効と数えています

• 調査ドメイン:137,210
• 有効な llms.txt を持っていた:38,360(28%)
• 2026年5月にリクエスト0件:そのうち97%
• 何かしら取得されたのは:約1,100ドメイン

HTMLやソフト404を弾いている点が大事なところで、「置いたつもりで実は壊れていた」ぶんは最初から除かれています
ちゃんと動いている llms.txt に限っても97%が無風だった、ということなんです

取りに来ていたのは主にSEOツール

残り3%に届いたリクエストも、96%はボットで人間は4%
その内訳がこちら

いちばん多いのが SEO監査ツールの21.7%で、いちばん少ない部類がAI検索の取得ボットの1.1%です
「AI検索に引用されたいから置く」という動機に対して、その用途で読みに来ているのは全体の1%ちょっと、という話になります

置いた人を見に来ているのが、AIではなくSEOツールだった
この構図は皮肉というより、新しい規格が出たときにだいたい起きることなのかもしれません

読まれていても価値があるとは限らない

ここで「SEOツールが2割も読んでるなら、置く意味はあるんじゃないか」と思いたくなりませんか？
私も一度そう考えたんですが、読まれた先で何が起きるかを追うと話が続きませんでした

SEO監査ツールが取得したデータの行き先は、そのツールのデータベース
そこを見るのは競合分析をしている他人で、こちらの順位にも流入にも被リンクにも触れません

そもそもこれらのツールは、llms.txt があろうとなかろうとサイト全体をクロール済み
1ファイル増えたところで、向こうから見えるものは変わらないんです

21.7%という数字は取得された分の内訳であって、価値の指標ではありません
分母は「97%がそもそも0件」なので、残り3%の中の割合を効果として読むのは二重の誤読

内訳をもう一度見ると「GEO / AEOツール 5.8%」という行が見つかるでしょう
この手のサイト診断ツールは、llms.txt が無いと減点してくることがあるんです

スコアは順位でも流入でもない、途中の目安

そこを目的にして置くと、手段と目的が入れ替わってしまうんです

AIは置いていないサイトを探しに来ない

この調査でいちばん効くのは、割合の話よりこっちだと思います
Ahrefs は、llms.txt が存在しないサイトに対して、AIボットからのリクエストは1件も来ていなかったと報告しています

ここが分かると、「置いていないから損をしている」という不安はいったん消せます
探しに来ていない相手に向けて、置いていないことを気に病んでも仕方がないので

ジャベ雄

置いてないと不利、というわけではないんです
そもそも見に来ていないので

いちばん取りに来ていたのは Claude Code だった

ここから話が少しひっくり返ります
名前が分かるボットに絞って見ると、AIボットからのリクエストで最多だったのは GPTBot の4.51%で、そのすぐ後ろに Claude-Code が付けていました

Claude-Code は Anthropic のコーディングエージェント
そしてこの Claude-Code が、AI検索の取得ボット・AIアシスタント・AI学習クローラーのどれよりも多く llms.txt を取りに来ていたと報告されています

llms.txt は読まれていないというより、読む相手が想定と違ったということなんです

Claude Code に何かを調べさせたとき、そのサイトの構造をつかむために llms.txt を踏む
そういう使われ方だったりすると、確かに噛み合います

だから、ドキュメントサイトやAPIリファレンスを持っている人には、いまでも置く理由があります
逆に個人ブログでこの用途を期待するのは、やっぱり少し無理があるかなと思います

Claude Code 自体が読む設定ファイルの話は、別の記事にまとめてあります

あわせて読みたい

Claude Code 設定ファイル早見表 役割と場所 Claude Codeを触っていると次々に登場する設定ファイル(CLAUDE.md・settings.json・AGENT.md・SKILL.mdなど)を、保存場所と役割で一覧化した早見表記事です、微調整目線で抑えたい初心者〜中級者向けにまとめました

大手のドキュメントサイトは置いている

実際どうなっているのか気になったので、有名どころのURLを直接叩いて試してみたところ、はっきり分かれました
2026年8月22日時点の結果がこちら

開発者向けドキュメントを持っている会社は、だいたい設置済み
ただ、置いている理由は前の節とつながっていて、AI検索対策というよりコーディングエージェントに読ませるためだと考えると筋が通ります

Anthropic のような提供側が整備を進める一方で、Ahrefs の集計だとAI検索の取得は1.1%どまり
作る側と読む側で温度が違うのが、この規格のいまの位置なんでしょう

AI検索まわりの用語がぼんやりしている方は、AI用語集にクローラーや学習まわりの言葉をまとめてあります

WordPressで置いてみて分かったこと

結論から言うと、プラグインを入れて5分で終わりとはいきませんでした
初期設定のままだと、案内図として使えないものができあがるんです

使ったのは Website LLMs.txt という無料プラグイン
この記事を書きながら、実際に javeo.jp へ入れて確かめました

入れただけでは生成されない

有効化しただけで /llms.txt を叩くと、返ってくるのはまだ404
ただ、返ってきたのはWordPressのエラーページではなく、プラグイン自身の「まだ生成されていません」という一行でした

管理画面の「ファイルステータス」に Generate now というボタンがあって、これを押して初めてファイルができます
入れて満足して終わっている人、いるんじゃないでしょうか

初期設定のままだと古い記事が落ちる

ここが一番の落とし穴
「タイプごとの最大投稿数」の初期値が 100 なので、それを超えるぶんは古い順に切り捨てられます

このブログは公開記事が128本あるので、27本が黙って落ちていました
古い順に切られるので、長く読まれてきた記事から先に消えます

落ちていた中には、いまでも検索から人が来る記事がいくつも混ざっていたんです
案内図を作るつもりで、案内したい場所を外していたわけです

200に上げて作り直したら、128本すべて入りました

説明文を入れるとかえって読めなくなる

「投稿の抜粋 / メタディスクリプションを含める」をONにすると、各リンクに説明が付きます
ところがその説明が、全件そろって23字で切れました

- [Excelのセルの書式設定 表示形式とユーザー定義の書式コード](https://javeo.jp/excel-format-cells/): Excelのセルの書式設定で主役になるの...

設定には「最大文字数 250」という欄があるのに、そちらは効いていません
切り捨てられた残りは Detailed Content という別セクションに回るんですが、そこにはタイトルもURLも書かれていませんでした

投稿128件に対して説明は77件しかないので、並び順で対応づけることもできません
AIが読んだら、別の記事の説明として受け取るほうが自然なんじゃないでしょうか

なのでOFFに戻しました
タイトルとURLだけの素直なリストになって、ファイルも44KBから14KBまで落ちています

ひとつ安心した点もあって、下書きや非公開の記事は入っていませんでした
この記事自体を下書きのまま試したので、そこは実物で確かめられました

ジャベ雄

入れて終わりにすると、上から100本だけの案内図ができます

置いた初日にClaudeBotが来た

生成した日のアクセスログを見たら、もう取りに来られていました
テスト用に自分で叩いたぶんを除くと、初日の /llms.txt へのアクセスは4件

ここで引っかかったのがどうやって見つけたのかという点
サイトマップにも robots.txt にも llms.txt は入れていません

ページのソースを見たら、プラグインが全ページの head にこれを出していました

<link rel="llms-sitemap" href="https://javeo.jp/llms.txt"/>

AIが探しに来たわけではなく、こちらがHTMLで置き場所を教えていたということ
Ahrefs が「AIは存在しない llms.txt を探しに来ない」と報告していたのとも、これなら矛盾しません

結局 llms.txt は置くべきか

私の結論は、個人ブログなら急いで置かなくていいです
AI検索に引用されたいという動機に対しては、効果を支える材料がいまのところ見当たりません

判断が分かれるのは、サイトの性格のほうだったりします

でも、置くこと自体に害はありません
私もこの記事を書きながら入れてみましたが、狙いは効果を期待したからではなく、これから誰が取りに来るのかを自分のログで確かめるためです

もっと言うと、この手の規格は数か月で状況が変わります
Mueller 氏の「必要だと言われたら作ればいい」という目安は、いまのところ現実的な立ち位置なんじゃないでしょうか

• llms.txt はAIに読ませるサイトの案内図、2024年9月の提案で仕様は今も更新されている
• Google は使っておらず、現状を「憶測の域」と表現している
• 実測では約38,000サイトの97%が1か月間まったく取得されていない
• 取りに来ていた最多はSEO監査ツール、AI検索の取得は1.1%どまり
• AIボットは llms.txt が無いサイトを探しに来ていない
• 例外はコーディングエージェントで、Claude Code が実際に取りに来ている
• WordPressのプラグインで置く場合、初期設定のままだと古い記事が切り捨てられる

ジャベ雄

置くなら、AI検索でなく Claude Code のために置く、が現時点の答えです

「ブログを始めてみたいけど、何から手をつければいいのか分からない」——最初はみんなそこでつまずきますよね

結論から言うと、WordPressブログに必要なものはサーバー・ドメイン・テーマの3つだけで、今は申し込みから約10分で開設できるところまで簡単になっています

この記事では、実際にこのブログ（javeo.jp）をエックスサーバー＋SWELLで運営している私が、サーバー契約からWordPressの開設、テーマ導入、最初の記事を出すところまでの全手順を、初心者向けに順番にまとめてみました

WordPressブログに必要なもの3つと費用の全体像

まず全体像をつかんでおきましょう、WordPressでブログを作るのに要るものはたった3つです

• レンタルサーバー：サイトのデータを置く「土地」にあたるもの
• 独自ドメイン：サイトの「住所」、このブログでいう javeo.jp の部分
• WordPressテーマ：サイトの「見た目」を決めるデザインの着せ替え

WordPress本体は無料で、上の3つにかかる費用の目安はこんな感じです（料金は記事執筆時点のもので、最新は各公式ページで確認してくださいね）

合計しても月1,000円前後＋テーマ代くらいで始められます、無料ブログと違って独自ドメインのサイトは自分の資産になりますし、広告やデザインの自由度も高いので、本気で続けたいならWordPressで作っておくのが安心ですね

【STEP1】レンタルサーバーを選ぶ

最初の関門がサーバー選びですが、ここで迷いすぎると前に進めません、初心者がチェックすべきポイントは表示速度・安定性・実績・管理画面の分かりやすさくらいで十分です

そのうえで私がおすすめするのはエックスサーバーです、理由はシンプルで、このブログ自体もエックスサーバーで動かしているからで、長く使っていて速度も安定性も不満がなく、利用者が多いぶんネット上に情報が多くて困ったときに調べやすいんですね

とはいえ比較なしに勧めるのもフェアじゃないので、もう一つの定番であるConoHa WINGと並べてみます、どちらも質が高いので、最後は好みで選んで問題ないレベルです

「とりあえず鉄板で間違いないものがいい」ならエックスサーバー、「管理画面の新しさや最安の月額を重視したい」ならConoHa WING、という選び方で大丈夫です、この記事ではこのあとエックスサーバーで開設する手順を例に進めていきますね

ConoHa WINGが気になる人はこちらもどうぞ、こちらも独自ドメインが最大2つ無料で付いてきます

【STEP2】クイックスタートでWordPressを開設する

サーバーが決まったら、いよいよ開設です、昔はサーバー契約・ドメイン取得・WordPressインストール・SSL設定をバラバラにやる必要がありましたが、今はクイックスタートを使えば、この4つを申し込みフォームの流れの中でまとめて終わらせられます

実際の流れはこんな感じです、画面の案内に沿って入力していくだけなので、身構えなくて大丈夫ですよ

支払いまで終えてWordPressのログイン画面が開けば、もうあなたのブログは世界に公開されている状態です、ここまでで一番の山は越えました

【STEP3】WordPressの初期設定（最初にやる5つ）

開設できたら、記事を書き始める前に最低限の初期設定をすませておきます、ここを整えておくと後で困りません、特にパーマリンクは最初に決めておくのが大事です

【STEP4】テーマをSWELLにして見た目を整える

WordPressは「テーマ」を入れ替えるだけでサイト全体の見た目がガラッと変わります、無料テーマでも始められますが、デザインや使い勝手で時間を取られたくないなら、最初から完成度の高い有料テーマを入れてしまうのが結局は近道です

私が使っているのがSWELLというテーマで、このブログもSWELLで作っています、おすすめする理由はこのあたりです

• ブロックエディターに完全対応で、マウス操作だけで装飾できる（コード不要）
• 表示速度を上げるキャッシュや遅延読み込みの機能が最初から入っている
• ボタンや吹き出し、ステップなどの装飾ブロックが標準でそろっている

価格は17,600円（税込）の買い切りで、月額はかかりません（執筆時点・最新は公式で確認してくださいね）、バージョンアップも無料で、しかも複数のサイトで使い回せるので、ブログを増やしても買い直す必要がないのは大きいです

それと、ここまでの手順どおりエックスサーバーを契約しているなら、エックスサーバー経由でSWELLを買うと5%OFF（17,600円→16,720円）になります、サーバーをエックスサーバーにそろえておくと、こういう細かい得もあるんですね

導入の手順もシンプルです

デザインで悩む時間を減らしたいなら

SWELLは買い切りで複数サイトに使えるので、ブログを長く続けるつもりなら早めに入れてしまうほうがトータルでは得をしやすいです、公式で機能やデモを見てみてください

ちなみに、すでにCocoonなど別のテーマでサイトを持っていて「SWELLに乗り換えたい」という人は、移行の手順を別記事にまとめています、CocoonからSWELLへの移行手順もあわせてどうぞ

【STEP5】最初の記事を書いて公開する＋運営のコツ

ここまで来たら、あとは書くだけです、いきなり完璧な記事を目指さず、まずは1本公開してみるのがおすすめですよ

記事を書き始める前に、最低限そろえておくとよいのがこのあたりです

• 固定ページ（プロフィール・お問い合わせ・プライバシーポリシー）を用意する
• 記事のカテゴリーをいくつか決めておく（書くテーマの軸になる）
• アクセス解析（GA4）とサーチコンソールは、落ち着いてからつなげばOK

続けるコツは、最初から飛ばしすぎないことだと思います、テーマを絞って、自分が書きやすいジャンルから出していくと、無理なく記事がたまっていきます、完璧主義になりすぎず「直せばいい」くらいの気持ちで公開していきましょう

追加でドメインが欲しくなったら（XServerドメイン vs お名前.com）

クイックスタートでは独自ドメインが1つ無料で付いてくるので、最初のブログはそれで十分です、ただ、2つ目のサイトを作りたくなったり、別ジャンルで新しい独自ドメインを取りたくなったときは、ドメイン取得サービスを使うことになります

定番はXServerドメインとお名前.comの2つです、軽く比較しておきますね（料金は執筆時点・税込）

すでにエックスサーバーを使っているなら、管理画面をまとめられるXServerドメインが楽です、更新費を少しでも抑えたい・いろんな種類のドメインから選びたいならお名前.comも候補になります、ここも用途で選べば大丈夫ですよ

まとめ｜まずはサーバー契約から動き出そう

WordPressブログの始め方を振り返っておきます、やることは大きく3ステップでした

• サーバーを選ぶ（迷ったらエックスサーバー、最安重視ならConoHa WING）
• クイックスタートで開設する（サーバー・ドメイン・WordPress・SSLを一括で）
• テーマをSWELLにして見た目を整える

頭で考えているうちは何も始まりませんが、サーバーさえ契約してしまえば、あとは流れで開設まで進めます、最初の一歩はまずはサーバー契約からです、思い立った今日のうちに動いてしまいましょう

無料テーマのCocoonから有料テーマのSWELLへ乗り換えようか迷っていて、「移行作業ってどれくらい大変なんだろう」「記事の装飾とか全部やり直しになるのかな」と不安になっていませんか？

この記事は、私が実際にこのブログ(javeo.jp)を CocoonからSWELLへ移行した体験記と手順ガイドです、やった順番に沿ってまとめていきます

結論から言うと、移行そのものは思っていたよりずっとスムーズでした、記事本文の装飾は乗り換えサポートプラグインがほぼ吸収してくれて、大きく詰まる場面はほとんどなかったです

ただ、ひとつだけ「あ、これは自分で作り直すのか」となった山場があって、それが トップページのカスタマイズとサイドメニュー(サイドバー)でした、このあたりは後半でじっくり書きます

ちなみに移行作業の一部では Claude Code Desktop(ローカルのファイルやデータをAIに操作してもらえるツール)を使ってラクをしました、そのあたりの活用例も具体的に紹介していきます

Claudeってそもそも何という方は、Claudeの使い方を初心者向けに解説した記事から入ると全体像がつかみやすいですよ

なぜCocoonからSWELLへ移行したのか

まずは技術的な話の前に、そもそもなぜ乗り換えたのかという素直な動機から書いておきます

ブログに本腰を入れる心機一転

いちばん大きい理由は、ブログ活動に改めて本腰を入れて取り組もうと思ったことです

これまでもCocoonでぼちぼち書いてはいたんですが、せっかく腰を据えてやるなら、見た目から気分を変えたいなと思ったんですよね、形から入るタイプです

SWELLのほうが「本格的」に感じた

もうひとつは、単純な好みの問題です、SWELLのデザインや雰囲気のほうが「本格的」に感じたんですよね

Cocoonはとても優秀な無料テーマで、機能面でも全然不満はなかったです、ただ並べて見たときに、SWELLのほうが「ちゃんとしたメディアっぽい」空気が出るなと感じました

このへんは完全に主観なので、「Cocoonのほうが好き」という方もたくさんいると思います、私の場合はSWELLの見た目に惹かれた、という話です

技術的なメリットを並べて理屈で決めたというより、気分とデザインの好みで踏み切ったのが正直なところです

SWELLってどんなテーマ？価格とお得な買い方

移行手順に入る前に、SWELLがどんなテーマで、いくらするのかを整理しておきます、まだ購入していない方はここが気になりますよね

SWELLの特徴をざっくり

SWELLは国産の有料WordPressテーマで、ブロックエディタ(Gutenberg)との相性がよく、コードを書かなくても見た目を整えやすいのが特徴です

特に気に入っているのは次のようなところです

• ブロックエディタで装飾が完結する:ボタンやマーカー、ボックスなどが標準で用意されている
• デザインの統一感が出しやすい:設定をいじるだけで全体の雰囲気がまとまる
• 表示速度への配慮:高速化系の設定がテーマ側に組み込まれている
• 利用者が多い:情報が探しやすく、困ったときに記事が見つかりやすい

逆に「無料がいい」「カスタマイズを自分で全部コントロールしたい」という方にはCocoonのほうが向いていると思います、このへんは好みと運営方針しだいです

価格は17,600円の買い切り(複数サイト使い回しOK)

気になる価格ですが、SWELLは 通常17,600円(税込)の買い切り型です

月額のサブスクではなく、一度買えばずっと使えるタイプで、しかも 複数サイトで使い回しOKです、ブログを増やしても追加料金がかからないのは地味にうれしいポイントですね

「有料テーマってちょっと高いな」と感じる金額ではありますが、一度きりの出費で複数サイトに使えると考えると、長く運営するつもりなら元は取りやすいんじゃないかなと思います

エックスサーバー経由なら5%オフの16,720円で買える

ここでひとつ、私と同じでレンタルサーバーにエックスサーバーを使っている方に向けたお得情報です、エックスサーバーなら、サーバーの管理画面経由でSWELLを買うと割引が効きます

具体的には、通常17,600円のところ5%オフの16,720円で買えます、差額は880円とそんなに大きい額じゃないですが、せっかく使える特典なら活用しておきたいですね

仕組みとしては、エックスサーバーが有料テーマの優待販売をやっていて、SWELLもその対象に入っている、という流れですね、私もエックスサーバーユーザーなので、この優待価格で購入しました

買い方の手順はこんな感じです

1. エックスサーバーのアカウント(Xserverアカウント)にログイン
2. 左側メニューから 「WordPressテーマ」を開く
3. 「有料WordPressテーマの購入はこちら」から一覧を表示
4. SWELLを選んで決済(ここで優待価格が適用される)

ちなみに すでにエックスサーバーを契約している既存ユーザーでも、この割引はちゃんと使えます、新規契約じゃないと駄目、ということはないので安心してください

SWELL公式サイトから買っても通常価格(17,600円)なので、エックスサーバーを使っているなら管理画面経由のほうがお得、というのを覚えておくといいと思います

移行前にやっておきたい準備(バックアップは必須)

ここから実際の移行手順です、まずは移行前の準備から、ここをサボると後で泣くので、面倒でもひと手間かけておくのがおすすめです

バックアップだけは取っておく(ファイル+データベース両方)

テーマ移行で 最優先でやるべきはバックアップです、何かあったとき元に戻せる状態を作っておくのが、すべての保険になります

多少雑でもいいや、というスタンスでも、ここだけは妥協しないほうがいいです、私も「他は雑でいいけどバックアップは取る」と決めて進めました

バックアップは ファイル(wp-content等)とデータベース(MySQL)の両方が必要です、片方だけだと完全には戻せません

取り方は主に次のパターンです

1. レンタルサーバーの自動バックアップ機能を確認しておく(エックスサーバーなどは標準装備)
2. All-in-One WP MigrationやUpdraftPlusなどのプラグインで手動バックアップ
3. FTP+phpMyAdminで自力エクスポート(中級者向け)

個人的には、サーバー側の自動バックアップがある状態で、念のためプラグインでも「移行直前のスナップショット」を取っておくと安心感が違うのでおすすめです

いま使っている装飾とプラグインを把握しておく

もうひとつの準備が、現状の把握です、Cocoonで何を使っているかをざっと棚卸ししておくと、移行後に「どこが崩れたか」がわかりやすくなります

特にチェックしておきたいのは次のあたりです

• Cocoon独自の装飾クラス(マーカーや赤字強調など)を記事でどれくらい使っているか
• 導入済みプラグインの一覧(Cocoon依存のものがあるか)
• メタディスクリプションを記事ごとに設定しているか(後述の盲点に直結)
• トップページとサイドバーの構成(これが最大の山場)

このへんを先に押さえておくと、移行後に慌てずに済みます、私もここを整理しておいたおかげで、何を作り直せばいいかの見通しが立てやすかったです

この記事の作業はClaude Code Desktopにも手伝ってもらった

少し先取りすると、私はこの移行作業の一部を Claude Code Desktopに手伝ってもらいました

Claude Code Desktopは、自分のパソコンのファイルや、設定したデータにAIがアクセスして作業してくれるツールです、ターミナル(黒い画面)でコマンドを打たなくても、お願いベースで動いてくれます

今回でいうと、記事のメタディスクリプションをまとめて退避したり、テーマやプラグインの状態を機械的に確認したりという地味だけど手間のかかる作業を任せました、ここがどう効いたかは、このあと該当する場面で具体的に書いていきます

「自分はそんなツール使ってないよ」という方も、手作業でやれば同じことはできるので大丈夫です、AIに任せると一瞬だった、という体験談として読んでもらえればと思います

乗り換えサポートプラグインを入れる

準備ができたら、いよいよSWELL導入に進みます、その前に 乗り換えサポートプラグインを入れるのがコツです

「【SWELL】乗り換えサポート from Cocoon」とは

SWELLは公式で 「【SWELL】乗り換えサポート from Cocoon」という専用プラグインを用意してくれています、導入の流れはSWELL公式の乗り換えガイドにもまとまっているので、合わせて目を通しておくと安心ですよ

これが何をしてくれるかというと、Cocoon時代に使っていた装飾を、SWELLでもなるべく崩れないように表示してくれる仕組みです

CocoonとSWELLは装飾の中身(CSSクラスなど)が別物なので、本来なら単純にテーマを切り替えただけだと、マーカーやボックスが効かなくなってガタガタになります

そこをこのプラグインが間に立って吸収してくれるので、過去記事を一気に手直ししなくても、ある程度きれいなまま表示されるというわけです、これはかなりありがたい存在でした

SWELLマイページから入手して有効化

このプラグインは SWELL購入者向けのマイページからダウンロードできます

手順としてはこんな流れです

1. SWELLのマイページにログインして、乗り換えサポートプラグイン(Cocoon用)のzipをダウンロード
2. WordPress管理画面 → プラグイン → 新規追加 → プラグインのアップロード
3. ダウンロードしたzipを選んでインストール
4. 有効化する

ポイントは テーマを切り替える前に、このプラグインを先に有効化しておくことです、先に入れておくと、テーマ切替の瞬間から装飾の引き継ぎが効いてくれます

SEO SIMPLE PACKを入れる(メタ管理用)

もうひとつ、テーマを切り替える前に入れておきたいプラグインがあります、それが SEO SIMPLE PACKです

SWELL本体にはメタディスクリプション機能がない

ここがCocoonとの大きな違いなんですが、SWELL本体には、記事ごとのメタディスクリプションを設定する機能が入っていません

メタディスクリプションというのは、検索結果でタイトルの下に表示される、記事の説明文のことです、SEO的にも、クリック率的にもけっこう大事なやつですね

Cocoonはこれをテーマ側の機能として持っていたので、記事編集画面でサクッと設定できていました、ところがSWELLにはその機能がないので、別のプラグインで補う必要があるというわけです

SWELL作者も推奨するSEO SIMPLE PACK

そこで定番になっているのが SEO SIMPLE PACK という無料プラグインです、実はこれ、SWELLと同じ作者さんが作っているプラグインで、相性がいいことで知られています

メタディスクリプションやOGP(SNSでシェアしたときに出る画像や説明)の設定をまとめて管理できる、シンプルで使いやすいプラグインです

入れ方は普通のプラグインと同じです

1. WordPress管理画面 → プラグイン → 新規追加
2. 検索窓に 「SEO SIMPLE PACK」と入力
3. 今すぐインストール → 有効化

このプラグインを入れておくことが、次に説明する メタディスクリプションの引き継ぎ問題の前提になります、ここまでが準備の総仕上げという感じですね

SWELLを有効化してテーマを切り替える

プラグインの準備が整ったら、いよいよ SWELLを有効化してテーマを切り替えます

親テーマと子テーマの両方をインストール

SWELLには 親テーマ(SWELL本体)と子テーマ(SWELL CHILD)の2つがあります、どちらもSWELLのマイページからダウンロードできます

子テーマというのは、カスタマイズ用に用意された、親テーマを土台にする薄いテーマのことです、自分でCSSなどを追記したいとき、子テーマ側に書いておくと、親テーマのアップデートで上書きされずに済みます

手順はこんな感じです

1. 管理画面 → 外観 → テーマ → 新規追加 → テーマのアップロード
2. まず 親テーマ(SWELL本体)のzipをアップロードしてインストール(この時点では有効化しない)
3. 続けて 子テーマ(SWELL CHILD)のzipもアップロードしてインストール
4. 最後に 子テーマ(SWELL CHILD)を有効化する

原則として 有効化するのは子テーマのほうです、親テーマは土台として入れておくだけ、実際に表に立てるのは子テーマ、と覚えておくとわかりやすいです

切り替えた瞬間に過去記事の装飾は引き継がれる

子テーマを有効化した瞬間が、いわゆるテーマ切替のタイミングです、ここでサイトの見た目がガラッとSWELLに変わります

ドキドキの瞬間なんですが、先に乗り換えサポートプラグインを入れておいたおかげで、過去記事の本文はそこまで大きく崩れませんでした、マーカーやボックスもそれなりに表示されていて、ひと安心という感じでした

ただ、ごく一部は乗り換えサポートプラグインでも吸収しきれず、個別に手直しが必要な崩れもありました

もちろん細かく見れば「ここはちょっと違うな」という箇所はあります、ただ パッと見で「全記事ぶっ壊れた」みたいな悲惨な状態にはならないので、乗り換えプラグインの効果は大きいです

ちなみにCocoon時代のマーカーや赤字強調のクラス(marker-underやbold-redなど)は、SWELLでは本来効きません、これも乗り換えプラグインが見た目を吸収してくれている、という理解でOKです

新しく書く記事はSWELL標準の装飾で書いていけばいいので、過去記事は当面そのまま、新規記事からSWELL流にという方針で問題なかったです

メタディスクリプションは乗り換えで引き継がれない(盲点)

ここが今回いちばん「知っておいてよかった」と思った 盲点です、テーマを切り替えたあとに気づくと地味にショックを受けるやつなので、先に共有しておきます

乗り換えプラグインは「装飾」は引き継ぐが「メタ」は引き継がない

さっき書いた乗り換えサポートプラグイン、記事の装飾はしっかり引き継いでくれます、ところが メタディスクリプションは引き継いでくれません

どういうことかというと、Cocoon時代に記事ごとに設定していたメタディスクリプションは、Cocoon独自の場所に保存されています、SEO SIMPLE PACKはその場所を読みにいかないので、切り替えた直後はメタディスクリプションが全部空っぽになるんです

「装飾は引き継いでくれたから、メタもいけるだろう」と油断していると、ここで足をすくわれます、私のブログでも、放っておけば 過去に設定したメタディスクリプションが全記事で消えた状態になるところでした

メタディスクリプションは検索結果の説明文に使われるので、空っぽのまま放置するとSEO的にもったいないです、ここは別途、自分で移行作業をする必要があると覚えておいてください

手動でやるなら「切替前の退避」が肝心

対策の考え方はシンプルで、テーマを切り替える前に、Cocoonに入っているメタディスクリプションを退避(コピー)しておくことです

退避しておけば、SEO SIMPLE PACKを入れたあとに、その退避データを記事ごとに貼り戻していけば復元できます、流れにすると次のとおりです

1. 切替前:各記事のメタディスクリプションをメモやファイルに退避しておく
2. 切替後:SEO SIMPLE PACKを有効化する
3. 復元:退避したメタディスクリプションを、記事ごとにSEO SIMPLE PACKの欄へ貼り戻す

記事数が少なければ手作業でも十分ですが、数十記事あると1記事ずつコピペするのはなかなかの手間です、ここで私は Claude Code Desktopに手伝ってもらいました

Claude Code Desktopで一括退避・一括書き戻しした話

私のブログには記事が79本あって、そのうち 47本にメタディスクリプションが設定されていました、これを1本ずつ手でコピペするのは、考えただけでうんざりする作業ですよね

そこでClaude Code Desktopに、全記事のメタディスクリプションを一括で吸い出すスクリプトを書いてもらって、まとめて退避しました、79記事から47件を吸い出すのが、ほぼ一瞬で終わりました

テーマをSWELLに切り替えてSEO SIMPLE PACKを入れたあとは、逆向きの作業をお願いしました、退避しておいた47件を、SEO SIMPLE PACK側へまとめて書き戻してもらった形です、これも手作業なら何時間もかかるところが、あっという間でした

もうひとつ地味に効いたのが、作業のたびに現状を機械的に確認できたことです

テーマやプラグインの状態も、Claude Code Desktopに頼めば いまアクティブなテーマと有効なプラグインをその場で確認できます、頭の中のイメージと実際の状態にちょっとした違いがあっても、その場で見て揃えられるので、迷わず進められました

メタの書き戻しも、現在の状態をきちんと確認したうえで進められたので、スムーズに対応できました、いつでも実際の状態を見られる安心感のなかで作業できたのは大きかったです

このあたりは、Claudeに細かいファイルやデータの作業を任せる感覚が掴めてくると、いろんな場面で応用が効きます、興味があればClaude Codeの拡張機構を解説した記事ものぞいてみてください

ちなみに、こういうツールに自分のサイトのデータを触らせるときは、セキュリティ面の基本も押さえておくと安心です、そのあたりはClaude Code Desktopの初心者向けセキュリティガイドにまとめているので、合わせて目を通しておくのがおすすめですよ

【山場】トップページとサイドメニューは作り直しが必要

さて、ここが今回の移行で いちばんの山場でした、データの移行はスムーズだったのに、ここだけは「自分で組み直すしかないのか」となった部分です

記事本文は引き継げても「サイトの見た目の核」は別物

ここまで書いてきたとおり、記事の本文やメタディスクリプションといった「データ」は、わりとすんなり移行できました、装飾は乗り換えプラグイン、メタは退避と書き戻しでなんとかなります

ところが、トップページのカスタマイズと、サイドメニュー(サイドバー)は、乗り換えでは引き継がれません

これはなぜかというと、トップページの構成やサイドバーの中身は、テーマごとに仕組みがまったく違うからです、Cocoonの設定の置き場所と、SWELLの設定の置き場所は別物なので、自動では移せません

言い換えると、「サイトの見た目の核」になる部分ほど、テーマ依存が強くて手動になるということです、ここは事前に知っておかないと、切り替えた直後に「あれ、トップがのっぺりしてる」と焦ると思います

トップページのカスタマイズはSWELL流に組み直す

Cocoonでは、トップページの構成を Cocoon設定やカスタマイザーで組んでいた方が多いと思います、ヘッダーのスライダーやおすすめ記事の並びなどですね

SWELLでは、これらを SWELL側の仕組みで一から組み直すことになります、具体的には次のようなところを設定し直す感じです

• メインビジュアル(トップ上部の大きな画像やスライダー)
• 記事一覧の表示形式(カード型・リスト型などのレイアウト)
• ピックアップ記事やカテゴリの見せ方
• トップ独自のセクション(SWELLはブロックでトップを組むこともできる)

面倒に聞こえるかもしれませんが、SWELLはこのあたりの設定がわかりやすく整理されているので、触っているうちに「なるほどここか」と掴めてきます、むしろ 移行を機にトップを見直すいい機会になりました

私の場合は、Cocoon時代の構成にこだわらず、SWELLらしい見せ方に思い切って作り替えたほうがしっくりきました、せっかく心機一転で乗り換えたので、ここは楽しみながらいじるのがおすすめです

サイドバー(ウィジェット)も並べ直しになる

サイドメニュー、つまりサイドバーのウィジェットも同じく作り直しです

ウィジェットというのは、サイドバーやフッターに置く「部品」のことです、プロフィール、人気記事、カテゴリ一覧、検索窓みたいなやつですね

テーマが変わると、ウィジェットを置ける場所(ウィジェットエリア)の構成も変わるので、どこに何を置くかを並べ直す必要が出てきます、設定場所は管理画面の 外観 → ウィジェット です

やることを整理すると、こんな感じです

1. 管理画面 → 外観 → ウィジェットを開く
2. SWELLのサイドバー用エリアに、表示したい部品(ウィジェット)を追加していく
3. プロフィール・人気記事・カテゴリなど、よく置く部品を並べ直す
4. パソコン表示・スマホ表示の両方で、崩れていないか確認

ここでの教訓をまとめると、記事本文やメタといった「データ」は移行できても、トップとサイドバーという「サイトの骨格」は手で組み直すということです

逆にここさえ覚悟しておけば、移行作業全体の見通しはぐっと立てやすくなります、私も「データはなんとかなる、骨格は作り直す」と切り分けて考えたら、気持ちがラクになりました

表示確認とキャッシュ削除を忘れずに

ひととおり組み直したら、最後に 表示確認とキャッシュ削除をやります、ここを飛ばすと「直したはずなのに反映されない」とハマるので、地味だけど大事な締めの作業です

キャッシュが残っていると古い表示のまま見える

WordPressではキャッシュ系のプラグイン(WP Fastest CacheやWP Super Cacheなど)を入れている方が多いと思います、ページを高速表示するために、作ったページを一時保存しておく仕組みですね

このキャッシュがクセモノで、テーマを切り替えたりメタを書き戻したりしても、キャッシュを消さないと古い表示のまま見えることがあります

実際、私もメタディスクリプションを書き戻したあとに確認したら、一部のページが古いまま(空のまま)表示されていて、一瞬「あれ、書き戻し失敗した？」と焦りました、原因は単にキャッシュが残っていただけでした

なので テーマ切替やメタ変更のあとは、キャッシュをいったん全部削除するのを習慣にしておくのがおすすめです、キャッシュ系プラグインの設定画面に「キャッシュを削除」みたいなボタンがあるはずなので、それを押すだけです

確認したいチェックポイント

キャッシュを消したら、ログアウト状態(または別ブラウザ)で実際の見え方をチェックします、確認したいのは次のあたりです

• トップページが組み直したとおりに表示されているか
• サイドバーのウィジェットが意図どおり並んでいるか
• アクセスの多い記事から優先的に、本文の装飾が崩れていないか
• メタディスクリプションが記事ごとに反映されているか(ソース表示で確認できる)
• スマホ表示でも崩れていないか

全記事を一気に完璧にしようとすると疲れるので、アクセスの多い記事から順に、気になるところだけ直していくくらいの気楽さで十分だと思います

乗り換えプラグインが吸収してくれている部分は、無理に今すぐ手直ししなくてもOKです、徐々にSWELL流の装飾に置き換えていけば、それでいいんじゃないかなと思います

まとめ:移行してよかった、これから書いていく

CocoonからSWELLへの移行をひととおりやってみて、移行してよかったというのが率直な感想です

この記事のポイントをおさらいすると、次のとおりです

• SWELLは通常17,600円の買い切り、エックスサーバー経由なら 5%オフの16,720円でお得に買える
• 移行前にバックアップ(ファイル+データベース)だけは取っておく
• 切替前に乗り換えサポートプラグインとSEO SIMPLE PACKを入れておく
• 装飾は乗り換えプラグインが吸収、ただし メタディスクリプションは引き継がれないので別途退避・書き戻し
• 最大の山場は トップページとサイドバー、ここは手で組み直す
• 仕上げにキャッシュ削除と表示確認を忘れずに

全体を通して感じたのは、「データの移行はスムーズ、サイトの骨格は作り直し」という切り分けさえできていれば、そこまで身構えなくていい作業だな、ということでした

メタディスクリプションの一括退避や状態確認をClaude Code Desktopに任せられたのも、地味だけど大きかったです、手作業だと心が折れそうな部分を丸ごとお願いできたので、移行のハードルがだいぶ下がりました

Claudeにこういう作業を任せる感覚をもっと知りたい方は、Claudeの使い方を初心者向けに解説した記事やClaude Codeの拡張機構を解説した記事から入ると、できることの幅が見えてくると思います

新しいテーマで気分も新たになったので、ここから改めて記事をどんどん書いていこうと思います、同じようにCocoonからSWELLへの移行を考えている方の、背中を少し押せていたらうれしいです

発生するテーマは？

私はSwellとCocoonを使っていますが”Swell設定”では発生しなかったので全てのテーマにある設定変更で発生するわけではないようです

後述する原因見れば納得ではあるものの、Cocoonは変更できる設定が鬼のようにあるのでこれが仇になってしまった感

同じようにコアなところまで設定できるテーマだと同じ事象が発生するかもしれません

もう一つ、半分ネタバレになりそうですが私はXserverでWordpressを利用しているわけですが、ConoHaなど他のレンタルサーバーは仕様がわからないので発生しないかもしれませんし、発生するなら同じ設定が理由になると思います

発生事象がこちら

どんな状況になるかと言うと”変更をまとめて保存”ボタンを押したら・・

特定のタブとかではなくて何をやってもこの画面になるのでなかなか焦ります

結局のところ原因は

早速原因ですが、WordpressじゃなくてXserver側の設定の”WAF設定“にありました

WAFはセキュリティ周りの設定で、悪意のあるプログラムが設定を変えないようにブロックしてくれるんですが”Cocoon 設定”までブロックしてしまうようです

対処方法

原因がわかれば簡単、一旦OFFにしてあげれば変更できるようになります

ただOFFに設定してもすぐには反映しない点だけ注意でして、確かに”最大で1時間程度かかります“とは書いてあるもののこの手の話は実はそんなことないですよだと思うじゃないですか

今のところ本当に1時間はかかることは経験してませんが20分～30分かかることは結構あります

あとがき

WAFの設定なんて意識高い系じゃないと最初はデフォルトのOFFのまま色々操作しちゃうと思うので、しばらくして遭遇しがちな現象だと思います

ちなみに設定のためにWAFをOFFにした場合、セキュリティ的には面倒くさがらずONに戻すが吉です