アメブロ的な「WYSIWYGでポチポチ組み立てる」エディターで作るのは古い！

ショーガック（正覚）

こんにちは！黒帯兄さんこと八木橋ショーガック（正覚）です。

「ブログを書く」というと、いまだに多くの人がアメブロのような画面を思い浮かべます。ツールバーのボタンをポチポチ押して、文字を大きくしたり色をつけたり、画像をドラッグ&ドロップで配置したり――いわゆるWYSIWYG（What You See Is What You Get）方式です。

WordPressのブロックエディター（Gutenberg）も、突き詰めれば同じ発想の上に成り立っています。パーツ（ブロック）を一つずつ積み木のように並べていくやり方は、直感的ではあるものの、「思い通りのデザインにならない」「モバイルで崩れる」「毎回同じ調整をやり直す」という壁にぶつかった経験がある方は多いはずです。

結論から言うと、この「ブロックをポチポチ組み立てる」制作スタイルは、そろそろ役目を終えつつあります。今は、HTMLの基礎だけ押さえて、ClaudeのようなAIに土台を作ってもらい、Vibe Codingで自分の手で仕上げる――そういう時代に移り変わっています。この記事では、その理由と具体的な移行の仕方を解説します。

WYSIWYGエディターが抱える構造的な限界

アメブロ的なブログエディターや、WordPressのブロックエディターに共通する弱点は「見た目の自由度と構造の自由度がイコールではない」ことです。

ツールバーで用意されているボタンの範囲でしか装飾できないため、「もう少し余白を詰めたい」「このセクションだけ背景色を変えたい」といった細かい要望に応えようとすると、用意された機能の組み合わせでは限界が来ます。結果として、装飾用の空白ブロックを無理やり挟んだり、同じような調整を記事ごとに毎回やり直したりすることになり、記事が増えるほど保守性が下がっていくという悪循環に陥りがちです。

さらにブロックエディターの場合、レスポンシブ対応（スマホでの見え方）はブロックの標準機能に依存する部分が大きく、デザインを凝ろうとするほど、逆に「ブロックの外」でどうにかしたくなる場面が増えていきます。

クラシック依存はもう安全な選択とは言えない

WordPress歴が長い人ほど、いまだにTinyMCE系のクラシックエディター機能に頼っている場面があるのではないでしょうか。ここには見落とされがちなリスクがあります。

かつて「TinyMCE Advanced」という名前で親しまれていたプラグインは、現在「Advanced Editor Tools（TinyMCE）」に名称変更されています。名前が変わっただけでなく、内部的な位置づけも徐々に変化しており、コピー&ペーストや特定の操作で「クラシック版の段落」がブロックとして挿入されてしまい、Gutenbergの標準ブロックとして編集できなくなる、という不具合報告は今も各所のフォーラムで見られます。クラシック機能に依存した記事ほど、あとから編集しづらくなるリスクを抱えているということです。

Gutenberg本体側の動きも見逃せません。WordPress開発チームは2026年、Classicブロック（core/freeform）をエディターの挿入メニューから標準で非表示にし、将来的には完全にオプトイン化・廃止する計画を進めていました。理由として挙げられていたのは、パフォーマンス（使っていないサイトでもTinyMCEが常時読み込まれる無駄）、アーキテクチャの一貫性（Classicブロックだけが「ブロックツリーではなく別エディターで描画される不透明なHTML」という特殊な存在であること）、利用率の低下、保守コストの増大などです。

ただし2026年7月、この方針は一部撤回されました。WordPress 7.1ではClassicブロックは引き続き挿入メニューに表示されることになり、開発チームは「Classicブロックは force（強制）ではなく choice（選択）によって自然に使われなくなるべきだ」という考え方を示しています。つまり、無理やり締め出すのではなく、ブロックエディター側の代替機能を磨くことで自然に移行してもらう、という方針転換です。

これは一見、クラシック依存でも当面は安泰に見えるかもしれません。しかし本質は変わっていません。WordPress開発チーム自身が「Classicブロックはコア内で唯一の特殊な存在」「保守負担が大きい」と明言している以上、長期的な立ち位置が不安定であることに変わりはないのです。今は使えても、数年単位で見れば「いつか整理される機能」の上に自分のコンテンツ資産を積み上げ続けるのは、得策とは言えません。

だからこそ、最初から「カスタムHTML」で作る

こうした背景を踏まえると、答えはシンプルです。クラシックにもブロックの寄せ集めにも依存せず、最初からカスタムHTMLブロックで記事本体を組み立ててしまう、という制作スタイルです。

まず画像は、Base64でHTMLに直接埋め込むのではなく、メディアライブラリにアップロードしてURLで指定します。Base64埋め込みは、ごく小さなアイコン画像であれば通信回数を減らせるメリットもありますが、通常のブログ用の写真サイズになるとHTML自体が肥大化し、ブラウザのキャッシュも効かなくなり、表示速度やCore Web Vitalsにマイナスに働きます。URL指定であれば、WordPress側の画像最適化（EWWW Image Optimizerなどのプラグイン）もそのまま活用できます。

次に、レイアウトや装飾はCSSで組み立てます。サイト全体に関わる部分は「追加CSS」に、その記事固有のデザインはカスタムHTMLブロックの中に直接<style>として埋め込んでおけば、記事ごとに独立したデザインを持たせつつ、テーマ側の変更に振り回されにくくなります。モバイル用のレイアウトも、メディアクエリをそのCSSの中に最初から仕込んでおけば、ブロックの標準機能に頼らずに狙い通りの見え方を作れます。

この作り方の最大の利点は、「エディターの仕様変更に振り回されなくなる」ことです。ブロックの挙動がアップデートで変わっても、TinyMCEやClassicブロックの将来がどうなっても、HTML・CSSという最も基礎的で普遍的な技術で作られたコンテンツは、そのまま動き続けます。

ClaudeとVibe Codingで、この作り方は「誰でもできる」領域に入った

「HTMLとCSSで組み立てる」と聞くと、ハードルが高く感じる方もいるかもしれません。ですが、いまはその心配はほとんど不要です。

やることはシンプルで、まずClaudeに「こういう見た目・こういう構成の記事を、画像はURLで指定する形のカスタムHTML＋CSSで作って」と伝えれば、たたき台となるコードを一気に生成してもらえます。そのあとは、自分の目で見ながら「ここの余白をもう少し空けたい」「この色をブランドカラーに変えたい」といった微調整を、Vibe Coding（AIと対話しながらコードを書き換えていくスタイル）で仕上げていきます。

ここで必要になるHTML・CSSの知識は、「ゼロから自分だけで書き上げる」レベルではなく、「タグやプロパティの意味がだいたい分かり、AIが出したコードのどこを直せばいいか判断できる」レベルで十分です。この最低限のリテラシーさえ持っていれば、ブロックエディターの制約にもクラシック機能の先行き不安にも縛られない、自由度の高い記事制作ができるようになります。

これは、アメブロ的なWYSIWYGエディターで「用意されたボタンの中で頑張る」時代から、「自分のやりたいことを、AIの力を借りながらコードで直接表現する」時代への転換だと言えます。ブログ制作における一種のパラダイムシフトが、すでに始まっているのです。

まとめ：エディターに合わせるのをやめて、コードで表現する側に回ろう

• アメブロ的なWYSIWYGエディターも、WordPressのブロックエディターの「ブロック積み木」方式も、細かいデザイン調整では限界がある
• TinyMCE Advanced改め「Advanced Editor Tools」や、Gutenbergの Classicブロックは、当面は使えるとしても長期的には不安定な立ち位置にある
• 画像はURL指定、CSSは追加CSS＋カスタムHTML内に埋め込みという形で、最初からカスタムHTMLブロックで記事を組み立てるのが今の最適解
• Claudeでたたき台を作り、Vibe Codingで仕上げるスタイルなら、HTML・CSSの深い専門知識がなくてもこの制作スタイルは実践できる

エディターの機能に振り回される制作から、そろそろ卒業しませんか。次回は、実際にClaudeでカスタムHTML＋CSSのテンプレートを作りながら、モバイル対応まで含めた具体的な手順を紹介していきます。

参考：The Classic block stays in the inserter for WordPress 7.1 – Make WordPress Core ／ Block Library: Deprecate Classic Block and TinyMCE · Issue #78067