WordPress プラグイン脆弱性問題と、EmDash / Obsidian×Claude Code という第三の選択肢

はじめに — WordPress 一強の時代が静かに終わりつつある

WordPress は世界中の Web サイトの 4 割超を占める巨大プラットフォームです。一方で、その圧倒的シェアを支えてきた「プラグインエコシステム」が、皮肉にも最大のリスク要因になっています。

サードパーティ製プラグインに脆弱性が混入した場合、攻撃者はサイト全体の管理権限を取得できることがあり、毎月のように新しい脆弱性が報告されています。

この問題を解く 2 つのアプローチが、2026 年に注目されています：

EmDash（Cloudflare）— プラグインを完全隔離した次世代 CMS
Obsidian × Claude Code 仮想 CMS — AI ネイティブ Local-first 運用

LINKTH では検討の結果、後者を採用しました。本記事では両者を整理し、第三の選択肢の中身を解説します。

第一の解：EmDash（Cloudflare 発オープンソース CMS）

Cloudflare がオープンソースで公開した EmDash は、WordPress の機能を TypeScript + Astro でゼロから再実装した CMS です。

EmDash の設計思想

WordPress: プラグインがコアと同じ権限で動く
        ↓ 脆弱性 = サイト全体の管理権限が漏洩

EmDash: プラグインを Dynamic Workers の隔離環境で実行
        + permission manifest を経由しないとデータにアクセス不可
        ↓ プラグインが侵害されても、被害範囲は隔離される

主な特徴

TypeScript + Astro 6.0 ベース、MIT ライセンス
Passkey / WebAuthn 認証
Cloudflare R2 / D1、または Node.js + SQLite で動作
WordPress WXR インポート対応

課題

ベータプレビュー段階（v0.1）。本番投入には早い
Dynamic Workers は Cloudflare の有料プラン必須（$5/月〜）
ドキュメントとプラグインエコシステムは育っていない

「WordPress の正統進化」を狙うプロダクトとして将来性はありますが、2026 年時点では「様子見」が現実的です。

第三の選択肢：Obsidian × Claude Code 仮想 CMS

EmDash の議論は「WordPress の良いところを残しつつ、設計から作り直す」アプローチです。一方、LINKTH は別の方向性を採りました。

CMS 自体を持たない。 Markdown ファイルと Git だけで運用する。

linkth-web/
├── content/                        ← Obsidian Vault
│   ├── blog/2026-04-29-foo.md
│   └── news/2026-04-29-bar.md
├── src/                            ← React + Vite
└── api/contact.js                  ← Vercel Serverless

構成

役割	担当
編集体験	Obsidian（ローカルの Markdown エディタ）
共同執筆者	Claude Code（Vault を直接読み書きする AI）
バージョン管理	Git + GitHub
配信	Vercel（自動ビルド・自動デプロイ）
検索／構造化	Obsidian のグラフビュー × バックリンク × タグ

何が新しいのか

Git-backed CMS（Decap、Tina など）は新しくありません。Markdown 配信もよくある。
新しいのは、Claude Code が Vault の能動的な共同執筆者として動く点です。

従来: 人間が記事を書き、CMS にログインして公開する
今回: 人間と AI が同じ Vault に共同で記事を書き、git push で公開される

「Claude Code に AIO 戦略の記事を書いて」と頼めば、適切な frontmatter とタグ付きで content/blog/ に新規記事が生成されます。人間はそれを Obsidian で開いて仕上げる。人間と AI のワークフローが統合された CMSは、これまで存在しませんでした。

なぜこれが「AI ネイティブな次世代 CMS」と言えるか

1. プラグイン脆弱性が原理的に存在しない

動的に実行されるコードは Vercel Functions の api/contact.js のみ（Resend 経由のメール送信）
配信側はすべて静的 HTML/JS/CSS
攻撃面が WordPress の 1/100 以下

2. AI と人間の境界が消える

記事の下書き：AI
仕上げ・トーン調整：人間
ファクトチェック：AI（社内 RAG にアクセス可）
SEO 構造の最適化：AI が見出し階層を提案
内部リンク追加：AI がグラフ全体を見て提案

3. グラフ構造が「ネイティブ」に手に入る

これが SEO/AIO 観点での最大の差別化要因です。

Obsidian で [[他の記事]] と書けば、内部リンクが自動構築
バックリンクパネルが「この記事を参照している記事」を即表示
グラフビューで記事間の関係性が可視化
ネストタグ（#aio/llmo/tracking）でカテゴリ階層が自然に育つ

トピッククラスター戦略は SEO/AIO の中核ですが、WordPress や EmDash で構築する場合「思い出して手動でリンク」が必要です。Obsidian なら、書きながらグラフを眺めて、リンク漏れを即発見できます。

3 つの選択肢の比較

軸	WordPress	EmDash	Obsidian × Claude Code
プラグイン脆弱性	あり（深刻）	隔離設計で原理的に防止	動的コードが極小、原理的に発生しない
状態	成熟	ベータ（v0.1）	既存ツールの組み合わせ、即運用可
運用コスト	中（保守・脆弱性対応）	$5+/月（Workers）	無料（GitHub + Vercel 無料枠）
編集 GUI	あり	あり	Obsidian（クライアント側のみ）／後乗せ可
AI との統合	プラグイン任せ	プラグイン任せ	Claude Code が共同執筆者
グラフ構造	プラグインで	プラグインで	ネイティブ
WordPress 移行	—	WXR 対応	WXR → Markdown 変換スクリプトで可
適性	大規模、編集者多人数	中規模、技術寄り	技術系チーム、SEO/AIO に強いブランド

LINKTH がこの選択をした理由

LINKTH は「AI × データドリブンマーケティング」を主領域とする会社です。

つまり、自社のコンテンツ運用が、自社の主張と一致している必要がある：

「AIO 時代はトピッククラスターが重要」と主張するなら、自社サイトがグラフ構造でクラスター化されているべき
「AI エージェントが運用を加速する」と主張するなら、自社の運用に AI が深く入っているべき
「データ起点で施策設計する」と主張するなら、自社サイトの運用も Markdown という構造化データで管理されているべき

EmDash は良いプロダクトですが、「WordPress を AI 時代向けに作り直す」アプローチであって、「人間と AI が一体化した CMS」ではありません。

LINKTH の文脈では、第三の選択肢が最適解でした。

「これは特殊例ではなく、一般化できるか？」

向いているケース：

✅ 技術系チームが運用するブログ／メディア
✅ SEO/AIO に強くしたいブランドメディア
✅ 専門知識データベース（医療、法務、金融、研究機関）
✅ 知識グラフ的な構造をコンテンツに持ち込みたいオウンドメディア

向いていないケース：

❌ 大量の非エンジニア編集者がいる新聞・雑誌的なメディア（Decap 後乗せで対応可）
❌ コメント機能・会員制・EC など動的機能が中核（別のスタックを推奨）

まとめ

WordPress はプラグイン脆弱性問題が構造的にある
EmDash はそれを設計から解決する有望な後継。ただし 2026 年時点ではベータ
Obsidian × Claude Code 仮想 CMS は、AI と人間が一体化した運用が可能な、Local-first / Git-backed の第三の選択肢

LINKTH ではこの構成を採用し、このブログ記事自身もその仕組みで配信されています。

自社の主張は、自社の運用で証明する。

CMS 選定はリスクとメリットのバランスで決まりますが、「何を主張する会社か」が選定基準に入ると、見え方が変わります。