個人ブログを書いていると、以前より検索からの流入が読みにくくなったと感じます。
検索結果の上位には企業サイトが並び、AIで作られたような網羅記事も増えました。さらにGoogle検索ではAIによる概要が表示され、検索結果の画面だけで疑問が解決する場面も増えています。
Pew Research Centerが2025年7月に公表した調査では、Googleの検索結果にAI要約が表示された場合、検索結果リンクをクリックしたユーザーは8%にとどまり、AI要約が出なかった場合の15%より低かったと報告されています。
これは「個人ブログへの流入が半減した」という意味ではありません。あくまで「AI要約が表示された検索では、検索結果ページから外に出る人が減る傾向がある」というデータです。
ただ、個人ブログを書いている側としては、検索から読者に来てもらう導線が以前より細くなっているという肌感覚を誰もが持っているかと思います。
不安ですよね…

WordPressブログは、もう古いのか。
AI時代には、Markdownや静的HTMLサイトの方が強いのか。
今からでもWordPressをやめた方がいいのか。
私もWordPressでブログを書いています。Cocoonを使い、Search ConsoleやBing Webmaster Toolsを見ながら、過去記事を直したり、新しい記事を書いたりしています。だからこそ、「WordPressを捨てるべきか」という話は、単なる技術論ではなく、かなり現実的な悩みです。
先に結論を書くと、現在私はこう考えています。
WordPressは、AI時代において優位性は薄れていると思います。
けれど、すでにWordPressでブログを運営しているなら、今すぐ捨てる必要もありません。
これからの問題は、WordPressを使うことではありません。
問題は、AI時代なのに自分の記事資産をWordPressの中だけに閉じ込めてしまうことだと考えています。
これからの個人ブログは、次のように役割を分けて考えた方がよいと思っています。
- Markdownは、AIに読み込ませやすいように記事と知識を保存する場所
- YAMLは、AIに条件を伝えるための整理メモ
- Gitは、変更履歴とバックアップ
- HTML部品は、読者が判断しやすくなる道具
- WordPressは、記事を公開する場所
- AIは、制作と整理を助ける相棒(というか大先生)
つまり、WordPressを捨てるのではなく、WordPressだけに任せない。
この記事では、AI時代にWordPressブログをどう扱えばいいのかを、Markdown、YAML、HTML部品との関係から整理します。
WordPressは「古い」のか

技術的に見れば、WordPressには確かに古さがあります。
データベース、PHP、テーマ、プラグイン、ブロックエディタが絡み合い、記事はテキストファイルとして単純に置かれているわけではありません。WordPressの仕組みの中に保存されています。
AIに過去記事をまとめて読ませたい。
内部リンクを横断的に整理したい。
似たテーマの記事を統合したい。
そう考えると、Markdownファイルがフォルダに並んでいる構造の方が扱いやすいのは事実です。
一方で、WordPressが終わったわけではありません。
W3Techsの統計では、2026年5月時点で、WordPressはCMSが判定できるサイトの59.6%、Web全体でも42.2%で使われています。個人ブログから企業サイト、メディア、ECまで、用途を問わず使われ続けている巨大な標準です。
つまりWordPressは、最先端の技術ではないかもしれません。
でも、実務で動き続けている公開基盤です。
ここを分けて考えた方がいいです。
WordPressが古いから捨てる。
これは少し短絡的です。
一方で、WordPressだけに記事資産を閉じ込める。
これはAI時代には少し弱いです。
AIと相性が悪いのは「WordPressそのもの」ではなく「閉じた運用」

WordPressは、人間が管理画面から記事を書いて公開する流れにおいては、いまだに強い道具です。
記事を書く。
画像を入れる。
カテゴリとタグを設定する。
SEO用のタイトルや説明文を整える。
公開ボタンを押す。
この一連の流れは分かりやすいです。非エンジニアにとって、WordPressは今でもかなり便利な道具です。
問題は、AIにブログ全体を扱わせようとした瞬間に出てきます。
たとえば、AIに次のような作業を頼みたいとします。
- 過去記事を読み直して古い情報を洗い出す
- 関連記事を整理して内部リンク候補を出す
- 似たテーマの記事を統合する
- 記事ごとの検索意図を分類する
- リライト前後の差分を確認する
- カテゴリ設計を見直す
こうした作業をWordPressだけで完結させようとすると、REST APIで記事を取り出したり、エクスポートしたり、HTMLタグやブロックコメントを整えたりする必要があります。
ショートコード、テーマ依存の装飾、プラグイン独自の構造も混ざります。
もちろん、不可能ではありません。
ただ、AIにとって自然な入力ではありません。
ここで誤解したくないのは、Markdownで書けばSEOに強くなるとか、静的サイトにすればAI検索で必ず有利になるとか、そういう話ではないことです。
MarkdownやGitが効くのは、検索順位そのものではありません。
運営者側の資産管理、再利用、AIとの共同作業の場面です。
書く場所、保存する場所、公開する場所を分ける。
そう考えると、かなり整理しやすくなります。
非エンジニアにとってはWordPressはまだまだ価値があるものだと思いますが、エンジニアの方がこれからブログを始めたいというのであれば、正直WordPressじゃないほうがいいような気もしています。
静的サイト・Markdownが魅力的に見える理由と、その落とし穴

AIを前提にすると、Markdownベースの静的サイトが急に魅力的に見えてきます。
AIが読みやすい。
Gitで履歴を追いやすい。
表示が速い。
ログイン画面もデータベースもないので、攻撃面も小さい。
記事を長く育てたい人にとって、MarkdownとGitの組み合わせはかなり強力です。
セキュリティ面でも、この差は大きいです。WordPress公式の「Hardening WordPress」では、WordPressのセキュリティは重視されているとしつつ、基本的な予防策を取らなければ潜在的な問題が起こりうると説明されています。
WordPressは便利です。
でも、便利な機能が多い分、ログイン画面、プラグイン、テーマ、PHP、データベースと、守るべき場所も増えます。
一方で、静的サイトに乗り換えれば全部解決する、というわけでもありません。
Git運用。
ビルド。
デプロイ。
ホスティング選定。
リダイレクト設計。
画像最適化。
サイトマップ。
構造化データ。
それまでWordPressが裏側で吸収してくれていた仕事が、自分の手元に降りてきます。
ブログの目的がWeb開発の練習なら、むしろ歓迎すべき手間かもしれません。
でも、目的が記事を書くことなら、環境構築に時間を持っていかれるのは本末転倒です。
さらに、既存ブログの全面移行には事故がつきものです。
URL変更。
リダイレクト漏れ。
画像パスの崩れ。
内部リンク切れ。
構造化データの抜け。
きれいな仕組みに移ったつもりが、検索流入や読者導線をまとめて壊してしまう可能性もあります。
だから、静的サイトが技術的に魅力的でも、既存のWordPressブログをいきなり全面移行するのは慎重に考えた方がいいです。
それでもWordPressを残す価値

WordPressの一番の強みは、書いてから公開までが速いことです。
管理画面で書き、画像を貼り、プレビューし、公開する。
この地味な流れが摩擦なく回ることのありがたさは、別環境を組もうとするとよく分かります。
SEO周辺の運用も成熟しています。
サイトマップ、OGP、パンくず、構造化データ、リダイレクト、RSS。
こうした要素を、テーマやプラグインの組み合わせで現実的な手間で扱える点は、WordPressの大きなメリットです。
もちろん、WordPressを使えば自動でSEOに強くなるわけではありません。
Google Search CentralのSEOスターターガイドでも、SEOとは、検索エンジンがコンテンツを理解し、ユーザーが訪問するかどうか判断しやすくする取り組みとして説明されています。
WordPressは、そのための道具がそろっている。
そう言うのが正確だと思います。
加えて、既存ブログには過去記事、内部リンク、カテゴリ設計、Search Consoleのデータ、Bing Webmaster Toolsのデータ、画像、広告設定、テーマカスタマイズ、読者の動線といった、お金で買い直せない資産があります。
これを一気に手放すのは、移行で得られるメリットよりリスクが大きい場面が多いはずです。
WordPress側もAI時代を傍観しているわけではありません。WordPress.orgでは2025年5月にAI Teamの発足が告知され、エコシステム全体のAIプロジェクトを調整する動きが始まっています。
ただし、これはWordPressをすぐにMarkdownやGit中心の仕組みに作り替えるという話ではないと思います。
WordPressは巨大な生態系です。
テーマ、プラグイン、ホスティング、EC、会員サイト、既存ユーザーなど、さまざまな要素が絡みます。
おそらくWordPressのAI対応は、WordPressを根本から別物にするというより、今のWordPressにAI補助機能を足していく方向に近いはずです。
だからこそ、個人ブロガー側の現実的な落としどころは、こうなります。
WordPressを公開基盤として使い続ける。
ただし、記事資産の中心はWordPressの外に置く。
比較表:WordPressと静的サイトの得意・不得意
| 項目 | WordPress | Markdown・静的サイト |
|---|---|---|
| 公開までの速さ | 管理画面で完結しやすい | Git・ビルド・デプロイの理解が必要 |
| AIとの共同作業 | DB・ブロック・プラグインが障害になりやすい | ファイル単位で素直に渡せる |
| 表示速度 | テーマとプラグイン次第 | 構造的に軽くしやすい |
| セキュリティ | 守る面が広い | 攻撃面が小さい |
| SEO運用 | プラグインとテーマの蓄積が豊富 | 自前で設計する範囲が広い |
| 既存資産の継承 | そのまま継続できる | 移行で崩れるリスク |
| 長期的な記事管理 | 内部に閉じると弱い | Gitと相性が良い |
技術的に整っているのは静的サイトです。
でも、個人ブロガーが無理なく続けやすいのはWordPressです。
一方を選ぶというより、役割で分けるのが妥当だと考える理由がここにあります。
HTML部品は、記事を「読むもの」から「使うもの」に変える

AI時代に個人ブログが価値を出せるのは、一般論を上手にまとめる部分ではなくなっています。
たとえば、「H.264とHEVCの違い」を平易に説明するだけなら、AIの方が速いかもしれません。
でも、読者が本当に知りたいのは、その先です。
自分はどちらを使えばいいのか。
iPhoneで見るだけなのか。
Windowsにも渡すのか。
編集するのか。
容量を減らしたいのか。
長期保存したいのか。
条件によって答えは変わります。
そこで使えるのが、記事内に埋め込む小さな対話的部品です。
ここではClaudeのArtifactsのように、AIが生成できるHTMLやJavaScriptの小さな部品を、広い意味で「HTML部品」と呼びます。Claude公式ヘルプではArtifactsを、アイデアを共有可能なアプリ、ツール、コンテンツ、ビジュアライゼーション、体験に変える機能として説明しています。
具体的には、たとえば次のようなものです。
- 条件入力で配送方法を絞り込む発送方法チェッカー
- 用途と再生環境から推奨コーデックを示す動画形式の選び方診断
- 部屋数と用途からスピーカー構成を提案するSonos構成シミュレーター
- 心拍変動値の傾向を入力して読み解き方を返すApple WatchのHRVガイド
- モデル、速度、精度、用途から選べるWhisperモデル比較ツール
共通しているのは、本文では「AかBかは場合による」と書かざるを得ない部分を、読者自身の条件入力に置き換える点です。
文章は文脈を伝える。
HTML部品は判断を助ける。
この役割分担は、AI時代の個人ブログと相性が良い構造です。
ただし、HTML部品を入れればそれだけで良くなるわけではありません。
重要な結論は、必ず本文にも書くべきです。
スマホでざっと流し読みする読者は、ボタンを押さないかもしれません。JavaScriptが期待どおりに動かない環境もあります。WordPressでは、テーマ、キャッシュ、広告、セキュリティプラグインの干渉で挙動が崩れることもあります。
検索エンジンやAIがJavaScript生成コンテンツを常に完全に理解する保証もありません。Google Search Centralの「JavaScript SEO Basics」でも、JavaScriptアプリを検索に適した形にする考え方が案内されています。
本文だけで理解できる。
HTML部品があれば判断がさらに速くなる。
この設計が安全です。
なお、なぜ今HTMLがAI時代に再評価されているのか、Markdownとどう使い分けるべきなのかは、別記事で詳しく整理しました。>なぜ今、HTMLが再評価されているのか|Markdownとの違いとAI時代の情報設計
Markdownは資産、YAMLはAIへの白線

ここで、MarkdownとYAMLが具体的にどう効くのかを整理します。
Markdownは記事をプレーンテキストとして残せる形式です。
WordPressに直接書く前に、まずMarkdownで下書きを残しておく。
それだけで、あとからObsidian、Cursor、GitHub、静的サイトジェネレーターなどに移しやすくなります。
AIにも丸ごと渡しやすいです。
要するにMarkdownは、記事資産をWordPressに人質に取られないための保険です。
一方、YAMLは、AIに条件を伝えるための整理メモとして機能します。
たとえば記事ごとに、以下のような情報を残しておくイメージです。
title: AI時代にWordPressブログは古いのか
target_reader: WordPressで個人ブログを書いている非エンジニア
goal: WordPressを捨てるべきか迷っている人に現実的な運営方針を示す
main_message: WordPressを捨てるのではなく、記事資産をWordPressだけに閉じ込めない
tone: ですます調、自然で少しくだけた文章
include: [WordPress, Markdown, YAML, Git, HTML部品, AI検索]
avoid:
- 強すぎる断定
- 技術者向けに寄りすぎる説明
- WordPressを一方的に否定する表現
これは読者に見せるための文章ではありません。
自分とAIが、記事の目的を見失わないための白線です。
「初心者向けにやさしく、でも薄くならず、SEOも意識して読みやすく書いてください」と長文で頼むこともできます。
ただ、それだと条件がぼやけます。
対象読者、目的、含める要素、避ける表現を構造化して渡すと、出力は引き締まりやすくなります。半年後にリライトを頼むときも、当時の意図がYAMLに残っていれば、AIに同じ前提を渡しやすくなります。
以前、「非エンジニアこそMarkdownを使うべき理由」という記事を書きました。
また、「YAMLとYMYLを勘違いしていた話」では、YAMLをAIへの白線として考えました。
今回の話は、その続きです。
Markdownで記事を保存し、YAMLでAIへの指示を整理し、Gitで変更履歴を残す。
この3つをWordPressの外に持っておくだけで、ブログ運営はかなり身軽になります。
Markdownを記事資産として残す考え方については、以前「非エンジニアこそMarkdownを使うべき理由」という記事でも詳しく書きました。
YAMLをAIへの白線として使う考え方については、「YAMLとYMYLを勘違いしていた話」で詳しく整理しています。
三層モデルで運営する

これからの個人ブログは、保存・公開・体験の三層で考えると整理しやすくなります。
1. 保存する層
ここはMarkdown、YAML、Gitの領域です。
下書き、調査メモ、比較表の元データ、AIとのやり取り、過去記事のバックアップ、リライト履歴を残します。
ここが知識資産そのものです。
WordPressの管理画面だけに置くのではなく、手元にも残す。
これが最低条件です。
2. 公開する層
ここはWordPressです。
記事を世に出し、カテゴリ、タグ、画像、内部リンク、SEO設定、サイトマップを管理します。
WordPressは倉庫というよりショーケースです。
読者と検索エンジンに届ける窓口として使う。
でも、すべての資産をここに預け切らない。
この距離感が大事です。
3. 体験の層
ここはHTML部品です。
比較表、診断、フローチャート、簡易シミュレーターのように、読者が自分の条件で答えを出せる仕掛けを置きます。
AI要約が強くなるほど、どこにでもある説明だけの記事は弱くなります。
個人ブログが出せる価値は、実際に悩んだ条件、選ばなかった理由、失敗した点、比較した過程、そして読者自身が判断できる道具です。
「読む記事」だけでなく、「使える記事」を増やしていく。
ここに、AI時代の個人ブログの生存戦略があると思っています。
移行ではなく、整理から始める
私なら、WordPressをいきなり捨てません。
記事、内部リンク、Search Consoleのデータ、Bing Webmaster Toolsのデータ、Cocoonや広告まわりの設定は、それ自体が資産です。これを全部チャラにする決断は、割に合わない場面が多いと思います。
先にやるべきは移行ではなく整理です。
まず、新規記事の下書きをMarkdownで作り、完成後にWordPressへ貼り付けて公開する運用に切り替えます。これだけで、WordPressを使い続けながら手元に原稿の正本が残ります。
次に、重要な記事には対象読者、目的、検索意図、含める内容、避ける表現をYAMLで添えておきます。あとからAIにリライトを頼むときの指示が一気に楽になります。
過去記事は、全部Markdown化する必要はありません。検索流入が出ているもの、収益に効いているもの、今後も育てたいものから順に手元へ引き上げれば十分です。
差分管理にはGitを使います。AIにリライトを頼むほど、どこを変えたのか、前に戻せるのか、余計な改変が混じっていないかを確認したくなります。Gitがあると、ここの不安が減ります。
HTML部品は、比較、診断、選び方、料金計算のように読者が迷う記事だけに入れれば足ります。派手さではなく、読者の判断を速くすることが目的です。
WordPressは引き続き公開基盤として使い、得意なSEO運用を任せる。
ただし、原稿と設計図は外に持つ。
これなら、既存資産を壊さずにAI時代へ踏み出せます。
WordPressブログは古いのか、という問いへの答え
WordPressブログは古いから終わり、ではありません。
ただし、WordPressだけで完結する運営は、AI時代には脆くなります。
これから問われるのは、どのCMSを使うかではなく、自分の記事資産をどう持つかです。
WordPressは公開。
Markdownは保存。
YAMLはAIへの指示整理。
Gitは履歴管理。
HTML部品は読者体験。
役割が違う以上、どれか一つに全部背負わせる必要はありません。
WordPressを捨てるのではなく、WordPressに閉じ込めない。
これが、今の個人ブロガーにとって一番現実的な生存戦略です。
参考サイト
- Pew Research Center「Google users are less likely to click on links when an AI summary appears in the results」
https://www.pewresearch.org/short-reads/2025/07/22/google-users-are-less-likely-to-click-on-links-when-an-ai-summary-appears-in-the-results/ - W3Techs「Usage Statistics and Market Share of WordPress」
https://w3techs.com/technologies/details/cm-wordpress - WordPress.org News「Announcing the Formation of the WordPress AI Team」
https://wordpress.org/news/2025/05/announcing-the-formation-of-the-wordpress-ai-team/ - WordPress Developer Resources「Hardening WordPress」
https://developer.wordpress.org/advanced-administration/security/hardening/ - Google Search Central「Search Engine Optimization (SEO) Starter Guide」
https://developers.google.com/search/docs/fundamentals/seo-starter-guide - Google Search Central「Understand JavaScript SEO Basics」
https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics - Claude Help Center「What are artifacts and how do I use them?」
https://support.claude.com/en/articles/9487310-what-are-artifacts-and-how-do-i-use-them - 関連記事:非エンジニアこそMarkdownを使うべき理由
https://today-is-the-first-day.com/non-engineer-markdown-reason - 関連記事:YAMLとYMYLを勘違いしていた話
https://today-is-the-first-day.com/yaml-ymyl-obsidian


コメント