WordPressクラシックエディタのカスタマイズ方法｜2026年版の安全な設定術

WordPressクラシックエディタは2026年8月現在も利用でき、ボタン編集は`mce_buttons`系、拡張読み込みは`mce_external_plugins`、編集画面のCSS調整は`add_editor_style()`が基本です。

WordPressの最新安定版は7.0.2で、2026年7月17日に公開されています。この記事では、この2026年のWordPress環境を基準に、クラシックエディタを使いやすくカスタマイズする方法と、古いコードを使う際の注意点まで整理します。

先に核心をまとめると、ボタンの追加・削除には`mce_buttons`系、独自TinyMCEプラグインの読み込みには`mce_external_plugins`、編集画面のCSSには`add_editor_style()`を使うのが基本です。

ただし、インターネット上には古いTinyMCE向けのサンプルコードが大量に残っています。

そのコードを「WordPress 7.0.2でもそのまま動く」と無条件に考えるのは危険です。WordPress公式ドキュメントでも、外部TinyMCEプラグインはWordPressに含まれるTinyMCEのバージョンとの互換性が必要だと説明されています。

この記事では、現在のWordPressで仕組みとして確認できる部分と、実際の環境で動作検証が必要なコードを分けながら解説します。

WordPressクラシックエディタは2026年も使える？

結論から言えば、WordPressクラシックエディタは2026年8月現在も利用できます。

ただし、「WordPress本体の標準エディタなのか」と「クラシックエディタを利用できるのか」は別の話です。

WordPressでは5.0からブロックエディタが導入され、現在の投稿編集環境の中心はブロックエディタになっています。

一方、WordPress.orgのClassic Editorは、従来型のクラシックエディタと旧来の投稿編集画面を復元する公式プラグインとして現在も公開されています。

さらにWordPressの公式開発資料では、Editorコンポーネントについて、WordPress 5.0まで標準だったクラシックエディタの保守とTinyMCEが現在も扱われています。

ここは初心者が混同しやすいポイントです。

「標準ではなくなった」ことと「使えなくなった」ことは同じではありません。

2026年8月12日時点でWordPress.orgのリリースアーカイブに掲載されている最新安定版は7.0.2で、7.0.2は2026年7月17日に公開されました。

一方、Classic Editorの公式プラグインページには、現在も「2024年まで、または必要な期間サポートする」という古い表記が残っています。

この文章だけを見て、「Classic Editorは2024年で終了した」と断定するのも正確ではありません。

実際、Classic Editorは2026年にも更新されており、第三者によるプラグイン情報ではバージョン1.7.0、2026年5月28日更新、WordPress 7.0.2でテスト済みと記録されています。

ただし重要なのは、公式ページのサポート文言が古いまま残っていること自体が、長期利用時の確認ポイントになるということです。

私は、現在クラシックエディタを使っている人へ「すぐにやめるべきだ」とは考えていません。

WordPress本体、Classic Editor、テーマ、関連プラグインの組み合わせで正常に運用できているなら、無理に執筆環境を変える必要はないでしょう。

一方、これから新しくWordPressサイトを立ち上げる場合は、なぜクラシックエディタを選ぶのかを自分の作業効率や運用方針で説明できる状態にしておくことをおすすめします。

「昔から使っているから」という理由だけで固定するのではなく、「文章中心の記事ではこちらのほうが速い」「既存の制作フローと相性が良い」など、目的を明確にすることが重要です。

---

WordPressクラシックエディタのカスタマイズには何を使う？

WordPressクラシックエディタのカスタマイズでは、まず次の3つを覚えておけば全体像をつかみやすくなります。

• `mce_buttons`系：TinyMCEのツールバーに表示するボタンを変更する
• `mce_external_plugins`：外部TinyMCEプラグインを読み込む
• `add_editor_style()`：ビジュアルエディタへCSSを追加する

WordPress公式リファレンスでは、`mce_buttons`、`mce_buttons_2`、`mce_buttons_3`、`mce_buttons_4`が、それぞれTinyMCEの1〜4行目に表示するボタン一覧を変更するフィルターとして定義されています。

また、`mce_external_plugins`は外部TinyMCEプラグインの一覧を変更するためのフィルターです。

ここでは`editor_id`も渡され、通常の`content`だけでなく、ブロックエディタ内のClassic Blockでは`classic-block`が対象になる場合があります。

用途を整理すると次のようになります。

やりたいこと 主に使う仕組み
1行目のボタンを追加・削除 mce_buttons
2行目のボタンを追加・削除 mce_buttons_2
3行目のボタンを追加・削除 mce_buttons_3
4行目のボタンを追加・削除 mce_buttons_4
独自JavaScriptをTinyMCEへ読み込む mce_external_plugins
編集画面へCSSを読み込む add_editor_style()

つまり、クラシックエディタのカスタマイズは「編集画面そのものを直接作り変える」というより、WordPressがTinyMCEへ渡している設定を変更する作業と考えると分かりやすいです。

初心者だった頃の私も、最初は「管理画面を改造する」と考えていたため、PHP、JavaScript、CSSの役割がすべて混ざって見えていました。

しかし、役割を分けてしまえば整理できます。

PHPはWordPressとTinyMCEをつなぐ。JavaScriptはボタンの動作を作る。CSSは見た目を整える。

まずはこの3層で考えるのがおすすめです。

---

WordPressクラシックエディタのボタンを削除する方法

最初にカスタマイズを試すなら、私は独自ボタンを追加するより不要なボタンの整理をおすすめします。

理由は単純で、追加より失敗しにくく、編集画面が変わった効果も実感しやすいからです。

WordPress公式には、TinyMCEの1〜4行目を変更するフィルターが用意されています。

たとえば1行目から特定のボタンを取り除く場合、基本的な考え方は次のようになります。

“`
add_filter( ‘mce_buttons’, ‘yomipo_remove_tinymce_buttons’ );function yomipo_remove_tinymce_buttons( $buttons ) { $remove = array( ‘alignleft’, ‘aligncenter’, ‘alignright’, ); foreach ( $remove as $button ) { $key = array_search( $button, $buttons, true ); if ( false !== $key ) { unset( $buttons[ $key ] ); } } return $buttons;}
“`

このコードで行っていることは3つだけです。

• 削除したいボタン名を配列に入れる
• 現在のボタン一覧から該当するボタンを探す
• 見つかったボタンを一覧から外す

2行目なら`mce_buttons_2`、3行目なら`mce_buttons_3`、4行目なら`mce_buttons_4`というように対象を変えます。

ここで注意したいのは、ボタン名を古い記事から適当にコピーしないことです。

WordPressのバージョン、導入プラグイン、テーマなどによって現在のボタン構成が異なる可能性があります。

そのため、まず実際の編集画面を確認し、何を削除するのかを決めてから変更しましょう。

また、一度に大量のボタンを削除するのもおすすめしません。

まず1つ削除する。

その状態で記事を1本編集する。

問題がなければ次へ進む。

この順序にしておけば、「何を消したことで使いにくくなったのか」が分かります。

副業でブログを運営していると、作業時間を短縮したくて一気に変更したくなります。

しかし、カスタマイズでは一度に大きく変えるより、小さく変えて確認するほうが最終的には速いです。

---

WordPressクラシックエディタに独自ボタンを追加する方法

独自ボタンの追加は、ボタン削除より一段難しくなります。

なぜなら、ツールバーにボタンを表示するだけでは機能しないからです。

WordPress公式の`mce_external_plugins`でも、外部プラグインがボタンを追加する場合には`mce_buttons`系のフィルターを使うことが説明されています。

最低でも次の2つを考える必要があります。

• 独自JavaScriptをTinyMCEへ読み込ませる
• そのJavaScriptが提供するボタン名をツールバーへ登録する

PHP側の基本形は次のようになります。

“`
add_filter( ‘mce_external_plugins’, ‘yomipo_add_tinymce_plugin’ );add_filter( ‘mce_buttons’, ‘yomipo_register_tinymce_button’ );function yomipo_add_tinymce_plugin( $plugins, $editor_id ) { $plugins[‘yomipo_marker’] = get_stylesheet_directory_uri() . ‘/js/yomipo-marker.js’; return $plugins;}function yomipo_register_tinymce_button( $buttons, $editor_id ) { $buttons[] = ‘yomipo_marker’; return $buttons;}
“`

ここで、2026年時点では特に確認しておきたいポイントがあります。

`mce_external_plugins`と`mce_buttons`には現在、`editor_id`という引数も渡されます。

WordPress公式リファレンスでも、`mce_external_plugins`は第2引数として`$editor_id`を受け取ることが明記されています。

そのため、古いサンプルに多い「引数を1つだけ受け取るコード」を見つけた場合も、現在のWordPressの仕様を確認してから使うほうが安全です。

独自ボタンのJavaScriptは古いサンプルをそのまま使わない

インターネット上には、次のようなTinyMCEコードが多数残っています。

“`
(function() { tinymce.PluginManager.add(‘yomipo_marker’, function(editor) { editor.addButton(‘yomipo_marker’, { text: ‘マーカー’, tooltip: ‘選択文字にマーカーを付ける’, onclick: function() { var selectedText = editor.selection.getContent({ format: ‘html’ }); if (!selectedText) { alert(‘マーカーを付ける文字を選択してください’); return; } editor.execCommand( ‘mceInsertContent’, false, ‘<span class=”yomipo-marker”>’ + selectedText + ‘</span>’ ); } }); });})();
“`

しかし、これを「WordPress 7.0.2で検証済みの完成コード」として扱うのは危険です。

WordPress公式は、外部TinyMCEプラグインについて、WordPressに含まれるTinyMCEのバージョンとの互換性が必要だと明記しています。

また、公式リファレンスに残っているユーザー投稿のサンプルには、旧来の`tinymce.create()`や`ed.addButton()`を使ったコードも掲載されています。

これは、古い情報が現在の公式ドキュメント内にも残っていることを意味します。

だから私は、初心者へ「このコードを貼れば完成です」とは言いません。

JavaScript部分は、利用中のWordPress環境でTinyMCE APIとの互換性を確認してから採用する。

これが2026年にクラシックエディタをカスタマイズするうえで、最も誠実な考え方です。

コードは検索結果に長く残ります。

だから「動きそう」ではなく、いつ、どの環境で検証されたコードなのかを見る習慣を持ちましょう。

---

独自ボタンの追加でPHPとJavaScriptは何を担当する？

独自ボタンを作る場合、PHPとJavaScriptの役割を分けて考えると理解しやすくなります。

PHPは、WordPress側からTinyMCEへ設定を渡します。

JavaScriptは、TinyMCE上でボタンを作り、そのボタンを押したときの動作を担当します。

たとえば「マーカー」という独自ボタンなら、処理の流れは次のようになります。

• PHPからJavaScriptを読み込む
• PHPから`yomipo_marker`というボタンをツールバーへ登録する
• JavaScriptで`yomipo_marker`を押したときの動作を定義する

ここを理解せずにコードをコピーすると、「ボタンが出ない」「ボタンは表示されるのに押しても何も起きない」という問題が起こりやすくなります。

原因を切り分けるときは、まずJavaScriptファイルそのものが読み込まれているかを確認します。

次にボタンがツールバーへ登録されているかを確認します。

最後にクリック処理が動いているかを確認します。

一度に全部を疑わないこと。

これはWordPressのカスタマイズ全般で使える重要な考え方です。

私自身、IT初心者だった頃は「動かない＝コード全体が間違っている」と考えがちでした。

しかし実際には、ファイルパスの間違い、関数名の不一致、対象エディタの違いなど、一部分だけが原因になっているケースが少なくありません。

---

独自ボタンの装飾をCSSクラスで管理する理由

たとえば、選択した文字をマーカー風に表示したいなら、JavaScriptから次のようなHTMLを生成する考え方があります。

“`
<span class=”yomipo-marker”>選択した文章</span>
“`

そしてCSSを別に用意します。

“`
.yomipo-marker { background: linear-gradient( transparent 65%, rgba(255, 235, 59, 0.55) 65% );}
“`

この方法のメリットは、HTMLの構造とデザインを分離できることです。

将来マーカーの色を変更したくなった場合も、CSS側を変更すれば済みます。

記事本文に挿入されているHTMLを大量に変更する必要はありません。

逆にJavaScriptの中へスタイルを直接大量に書き込んでしまうと、後からデザインを変更するときに管理しづらくなります。

ブログを長く運営するなら、記事の構造とデザインを分けるというWeb制作の基本をクラシックエディタにも持ち込んだほうが管理しやすくなります。

さらに重要なのは、公開ページと編集画面でCSSの扱いが異なることです。

公開された記事では黄色いマーカーになっている。

しかしクラシックエディタの編集画面では普通の文字にしか見えない。

このようなことは珍しくありません。

原因として考えられるのが、編集画面側にCSSが読み込まれていないことです。

---

WordPressクラシックエディタのCSSを編集画面へ反映する方法

WordPress公式には、TinyMCEのビジュアルエディタへカスタムスタイルシートを追加する`add_editor_style()`が用意されています。

たとえばテーマ側では次のように設定できます。

“`
add_action( ‘after_setup_theme’, ‘yomipo_editor_styles’ );function yomipo_editor_styles() { add_editor_style( ‘editor-style.css’ );}
“`

そしてテーマのルートに`editor-style.css`を用意します。

“`
.yomipo-marker { background: linear-gradient( transparent 65%, rgba(255, 235, 59, 0.55) 65% );}
“`

WordPress公式のテーマ開発資料でも、フロント側のCSSが編集画面へ自動的に読み込まれるわけではなく、`add_editor_style()`を使う方法が説明されています。

ここは初心者が非常につまずきやすいところです。

「公開ページでは黄色いマーカーになるのに、編集画面では普通の文字にしか見えない」

この場合、HTML自体に問題があるのではなく、編集画面側のCSSが不足している可能性があります。

`add_editor_style()`の公式リファレンスでは、テーマルートを基準にしたスタイルシートを指定でき、複数のスタイルシートを配列で渡すこともできると説明されています。

さらに、子テーマを使っている場合には、スタイルシートの探索や優先順位も関係します。

そのためCSSが反映されないときは、単純に「CSSの記述ミスだ」と決めつけないことが重要です。

どの編集画面に、どのCSSが、どのタイミングで読み込まれているのか。

ここを順番に確認することが、トラブル解決の近道です。

---

クラシックエディタとClassic Blockは同じ？

結論として、Classic Editorプラグインで使うクラシックエディタと、ブロックエディタ内のClassic Blockは完全に同じ編集環境ではありません。

見た目が似ているため混同しやすいのですが、カスタマイズでは区別する必要があります。

WordPress公式の`mce_external_plugins`では、`$editor_id`として通常のエディタIDだけでなく、ブロックエディタのClassic Blockから呼ばれる`classic-block`も受け取る場合があります。

つまり、

「クラシックエディタでは動く」

ことと、

「ブロックエディタのClassic Blockでも同じように動く」

ことを同一視してはいけません。

独自ボタンをサイト全体で使うのであれば、最初に対象となる編集方式を決めることが重要です。

たとえば、次のような環境があります。

• Classic Editorプラグインで旧来の投稿編集画面を使う
• ブロックエディタを使い、一部だけClassic Blockを使う
• 投稿タイプによって編集方式を分ける

これらでは必要な検証範囲が変わります。

細かい違いに見えるかもしれません。

しかし本番サイトでは、この小さな違いが「自分の環境だけ独自ボタンが表示されない」といったトラブルにつながります。

---

WordPress 7.0.2でクラシックエディタを使うなら何を確認する？

2026年8月12日時点では、まずWordPress本体のバージョンを確認することが重要です。

現在の最新安定版は7.0.2で、2026年7月17日に公開されています。

さらに7.0.2はセキュリティリリースで、WordPress.orgは更新を推奨しています。

そのため、古いWordPress本体を使ったまま「クラシックエディタのコードだけ新しくする」という考え方はおすすめしません。

確認する順番は次のとおりです。

• WordPress本体のバージョン
• Classic Editorのバージョン
• テーマの種類とバージョン
• PHPのバージョン
• 関連プラグイン
• 独自TinyMCE JavaScript
• 編集画面のCSS
• 投稿タイプごとの編集方式

特に注意したいのが、プラグインごとの「検証済みバージョン」です。

WordPress.orgのクラシックエディタ関連タグを見ると、Classic EditorはWordPress 7.0.2まで検証済みと表示されている一方、Advanced Editor Toolsは6.9.5までと表示されるなど、プラグインごとに対応状況が異なります。

つまり、「どちらもクラシックエディタ関連のプラグインだから、すべてWordPress 7.0.2に対応している」と考えることはできません。

利用しているプラグインごとに確認する。

これが安全な運用の基本です。

---

Classic Editorは2026年にどう考えるべき？

Classic Editorの公式プラグインページには、古い「2024年まで、または必要な期間」というサポート表記が残っています。

一方で、2026年のWordPress環境でもClassic Editorは公開され、WordPress 7.0.2でテスト済みとされる情報も確認できます。

ここは両極端に考えないことが重要です。

「2024年まで」という文章だけを見て終了済みと判断するのも違います。

反対に、「2026年も動いているから、この先も永久に安心」と考えるのも危険です。

私なら、Classic Editorを現在の運用環境の一部として使いつつ、ブロックエディタへ移行できる余地も残しておきます。

具体的には、独自機能をClassic Editorだけに依存させすぎないことです。

記事本文そのものへ不要な独自タグを大量に埋め込まない。

テーマを変更しても復旧できるようにコードを記録する。

WordPress本体やプラグインを更新する前には、可能であればテスト環境で編集画面を確認する。

この「逃げ道を残す設計」が重要です。

便利な編集環境ほど、それが使えなくなったときの影響も大きくなります。

クラシックエディタを使うこと自体が問題なのではありません。

問題になるのは、「その環境でしか記事を編集できない状態」に依存しすぎることです。

---

WordPressクラシックエディタをプラグインでカスタマイズする方法

「コードを書くのは難しい」と感じるなら、無理に自作する必要はありません。

WordPress.orgには、Classic EditorやAdvanced Editor Toolsなど、クラシックエディタを利用・拡張するプラグインが現在も掲載されています。

選び方はシンプルです。

クラシックエディタそのものを使いたいのか、それとも編集機能を増やしたいのか。

ここを分けて考えます。

Classic Editorは、従来のエディタと旧来の投稿編集画面を復元する目的の公式プラグインです。

一方、Advanced Editor Toolsは、ブロックエディタとクラシックエディタの両方を拡張するプラグインとして掲載されています。

考え方としては次のようになります。

• 旧来の投稿編集画面を使いたい → Classic Editor
• 編集機能を増やしたい → 対応する拡張プラグインを検討
• サイト独自のボタンを作りたい → 自作TinyMCE拡張を検討

ただし、プラグインは導入すれば終わりではありません。

更新頻度、対応WordPressバージョン、サポートフォーラム、現在の動作状況などを確認します。

特に副業ブログでは、記事を書くことが本来の仕事です。

編集画面の機能追加に何時間も使ってしまえば、本末転倒になります。

既存プラグインで10分で解決できることを、3時間かけて自作しない。

これも運用設計として非常に重要です。

---

自作カスタマイズとプラグインはどちらがいい？

初心者であれば、まず既存プラグインを探すことをおすすめします。

それで目的を満たせない場合に、自作を考えます。

私はこの順番をすすめています。

理由は、自作コードには必ず保守が必要になるからです。

WordPress本体は更新されます。

TinyMCE関連の実装が変わる可能性もあります。

テーマを変更するかもしれません。

PHPやJavaScriptの環境も変化します。

つまり、今日動いたコードが将来も同じ条件で動き続けるとは限りません。

特にTinyMCEについては、WordPress公式が外部プラグインとのバージョン互換性を明示的に求めています。

そのため、自作する場合はコードそのものだけでなく、どのWordPress環境で動作確認したのかを記録することをおすすめします。

たとえば次のように残します。

“`
WordPress: 7.0.2Classic Editor: 1.7.0テーマ: 使用中のテーマ名・バージョンPHP: 使用中のバージョン検証日: 2026-08-12対象: Classic Editorの投稿編集画面
“`

これだけでも、数カ月後の自分を助けてくれます。

コードを書く人にとって、検証環境の記録は設計図のようなものです。

「なぜこのコードがあるのか」「いつまで動いていたのか」が分からなくなることほど、後の保守を難しくするものはありません。

---

WordPressクラシックエディタで古いコードのコピペが危険な理由

WordPressクラシックエディタのカスタマイズで、私が最も注意したいのが古いコードの無条件なコピペです。

WordPressのカスタマイズ記事は、かなり古い記事でも検索結果に残ります。

2015年の記事。

2018年の記事。

2021年の記事。

それぞれ公開当時は正しい内容だった可能性があります。

しかし、読者が2026年にそのコードを使うなら話は変わります。

WordPress公式の`mce_external_plugins`には、現在も古いTinyMCEプラグインのコード例がユーザー投稿として残っています。

これは「古いコードはすべて間違っている」という意味ではありません。

むしろ、そのコードがいつ、どのバージョンを前提に書かれたのかを確認する必要があるということです。

特にJavaScriptは注意が必要です。

PHPのフック名が現在も存在していたとしても、JavaScript側のTinyMCE APIまで昔と完全に同じとは限りません。

したがって、

「WordPress公式に`mce_external_plugins`が存在する」

ことと、

「ネットで見つけたTinyMCE独自ボタンのコードがそのまま動く」

ことは別の問題です。

この区別ができるだけでも、WordPressカスタマイズの事故はかなり減ります。

コードを見るときに確認したい3つのポイント

古いカスタマイズ記事を参考にするときは、最低でも次を確認してください。

• その記事が書かれた年月
• 動作確認に使われたWordPressやTinyMCEのバージョン
• コメント欄や更新履歴に現在の動作情報がないか

さらに、現在のDeveloper Resourcesでフック自体が残っているかを確認できれば、より安全です。

「検索上位だから新しい情報」とは限りません。

技術情報では、順位より更新日と一次情報を重視することが大切です。

---

WordPressクラシックエディタを安全にカスタマイズする手順

実際に何から始めればいいのか迷う場合は、次の順番がおすすめです。

1. 現在のWordPress環境を確認する

最初にWordPress管理画面から本体のバージョンを確認します。

次にClassic Editorなど関連プラグインのバージョンを確認します。

現在のWordPress 7.0.2は、2026年7月17日公開の最新安定版としてWordPress.orgに掲載されています。

テーマ名、PHPバージョン、対象となる投稿タイプもメモしておくと、後からトラブルを追いやすくなります。

2. 変更前にバックアップする

ここは省略しないでください。

特に`functions.php`などへPHPコードを追加する場合、記述ミスによって管理画面へ入りにくくなる可能性があります。

可能であれば、本番環境ではなくステージングやテスト環境で確認してから反映します。

少なくとも変更前のコードは、すぐ元へ戻せる状態で保存しておきましょう。

3. 不便な操作を1つだけ決める

いきなり編集画面全体を作り変える必要はありません。

たとえば、

• 「マーカーを追加したい」
• 「使わないボタンを3つ削除したい」
• 「編集画面にも独自CSSを表示したい」

この程度で十分です。

一度に目的を増やさないことがポイントです。

4. 既存機能やプラグインで解決できないか確認する

WordPress本体や使用中のプラグインに、すでに目的の機能がないか確認します。

自作は最後で構いません。

カスタマイズの価値は「コードを書いた量」ではなく、作業がどれだけ楽になったかで決まります。

5. 自作するならPHPとJavaScriptを分ける

`mce_buttons`系はボタン一覧。

`mce_external_plugins`は外部TinyMCEプラグインの読み込み。

JavaScriptはボタンの動作。

役割を混ぜないことが重要です。

6. CSSは編集画面と公開画面を分けて確認する

公開ページで正常に表示されていても、編集画面で同じ表示になるとは限りません。

必要に応じて`add_editor_style()`を使い、編集画面側のCSSを確認します。

7. WordPressやプラグインの更新後にも確認する

一度動いたから終わりではありません。

WordPress本体やプラグインを更新したら、記事を1本開いて独自ボタンや装飾を確認します。

これだけでも異常を早期に見つけやすくなります。

---

WordPressクラシックエディタのカスタマイズで起きやすい失敗

ボタンを追加したのに表示されない

まず`mce_buttons`系による登録と、`mce_external_plugins`によるJavaScriptの読み込みを分けて確認します。

ボタン名の不一致やJavaScriptファイルのURL間違いも確認してください。

PHP側では`yomipo_marker`なのにJavaScript側では別名になっている、といった小さな不一致でも動作しません。

ボタンは表示されるのに動かない

JavaScript側のAPIやコードに問題がある可能性があります。

特に古いTinyMCE向けサンプルを使っているなら、利用中のWordPressに含まれるTinyMCEとの互換性を確認します。

WordPress公式も、外部TinyMCEプラグインについて互換性が必要だと説明しています。

公開ページでは装飾されるのに編集画面では装飾されない

編集画面側へCSSが読み込まれているか確認します。

WordPressでは`add_editor_style()`を使い、TinyMCEのビジュアルエディタへカスタムスタイルを追加できます。

公開側と編集側を別々に確認しましょう。

WordPressを更新したらカスタマイズが動かなくなった

まず、WordPress本体、Classic Editor、テーマ、関連プラグインのどれを更新した直後に問題が起きたかを確認します。

一度に複数のものを更新すると、原因が分かりにくくなります。

可能ならステージング環境で順番に更新し、編集画面を確認するのが理想です。

`functions.php`を編集してサイトがおかしくなった

変更前のコードへ戻します。

本番環境で直接編集するより、サイト専用プラグインや子テーマなど、変更を管理しやすい方法も検討してください。

そして、コードを変更した日時と変更内容を記録します。

地味ですが、これが後で効いてきます。

---

クラシックエディタのカスタマイズは「使用回数」で優先順位を決める

ここで、単なる「ボタン追加・削除」の話から一歩進めます。

クラシックエディタのカスタマイズでは、「編集画面を便利にする」ことだけを目的にしないほうがいいと私は考えています。

見るべきなのは、記事作成の工程全体です。

たとえば、

「文章を書く」

↓

「見出しを整える」

↓

「重要部分を装飾する」

↓

「定型パーツを入れる」

↓

「リンクを設定する」

↓

「公開前に確認する」

という流れがあります。

この中で、毎回同じ操作を何度も繰り返している箇所があれば、そこがカスタマイズ候補です。

逆に、月に1回しか使わない機能を独自ボタン化しても、得られる効果はそれほど大きくありません。

つまり、カスタマイズの優先順位は「機能の派手さ」ではなく「使用回数」で決めるという考え方です。

これはクラシックエディタだけの話ではありません。

副業でブログを書く人ほど、この視点を持っておく価値があります。

1回の作業を5秒短縮することは、小さく見えます。

しかし、その操作を1000回繰り返せば5000秒です。

約83分の差になります。

さらに重要なのは、単純な時間だけではありません。

「毎回HTMLを書くのが面倒だから装飾を後回しにする」

「ツールバーが散らかっていて探すのが面倒」

こうした小さな心理的摩擦を減らせることが、作業環境を整える本当の価値だと私は考えています。

記事を書くための環境は、仕事机と同じです。

毎日使うものだからこそ、自分に合わせて整える意味があります。

---

新しい視点：カスタマイズ前に「削除できる作業」を探す

もう一つ私が重視しているのが、機能を追加する前にそもそもその作業をなくせないか考えることです。

たとえば、毎回特定のHTMLを入れるために独自ボタンを作ろうとしているとします。

しかし、その装飾自体が本当に毎記事必要なのか。

テーマやCSS側で一括管理できないのか。

WordPressの既存機能に置き換えられないのか。

ここを先に考えると、コードそのものが不要になる場合があります。

技術好きになると、問題を見るとすぐ「どう自動化しよう」と考えがちです。

私もそうでした。

しかし実務では、最高の自動化は「その作業をしなくて済む状態を作ること」です。

追加ボタンを5個作る前に、不要な作業を1個消せないか。

この視点を持つだけで、編集環境はかなりシンプルになります。

---

考察：2026年のクラシックエディタは「延命」ではなく運用設計で考える

ここからは筆者の私見です。

私は、2026年のクラシックエディタを「古いから捨てるべきもの」とも、「昔と同じだから何も考えず使い続けるもの」とも考えていません。

現在のWordPressではブロックエディタが中心です。

その一方で、WordPress公式の開発資料ではクラシックエディタの保守やTinyMCEが現在もEditorコンポーネントの対象として扱われています。

そしてClassic EditorもWordPress.orgで現在も提供されています。

この状況を見る限り、少なくとも「クラシックエディタはすでに存在しない」と考えるのは正確ではありません。

ただし、公式プラグインページに古いサポート表記が残っている以上、未来まで現在と同じ環境が保証されると断言することもできません。

だから私なら、こうします。

現在クラシックエディタで問題なく記事を書けているなら使い続ける。

ただし、自作カスタマイズを追加するなら、現在のWordPressバージョンとの互換性を確認します。

そして、必要になったときにブロックエディタへ移行できる余地を残します。

これが現実的です。

「新しいものだから正しい」という考え方も危険です。

「昔から使っているから正しい」という考え方も危険です。

判断基準は、読者へ価値ある記事を安定して届け続けられるかどうかに置くべきでしょう。

---

考察：副業ブログではカスタマイズしすぎないことも重要

副業でWordPressを運営している人には、もう一つ伝えたいことがあります。

それは、編集画面のカスタマイズそのものを目的にしないことです。

ボタンを追加する。

CSSを整える。

JavaScriptを書く。

これらは確かに楽しい作業です。

しかし、副業ブログで成果につながる中心業務は、読者が求める記事を作り、改善し、公開することです。

2時間かけて独自ボタンを作り、そのボタンによって1記事あたり10秒しか短縮できないのであれば、投資した時間を回収するまでかなりの回数が必要になります。

一方、毎記事5分かかっている定型作業を1分に短縮できるなら、十分に価値があります。

そのため私は、カスタマイズ前に次のように考えます。

• その操作を1記事で何回行うのか
• 1カ月に何記事書くのか
• 何秒・何分短縮できるのか
• 保守にどの程度の手間がかかるのか

カスタマイズを「便利そう」で判断するのではなく、費やす時間と戻ってくる時間のバランスで判断する。

この考え方は、副業で限られた時間を使う人ほど重要です。

AIや自動化も同じです。

技術は、人を忙しくするためではなく、人が本当に考えるべきことへ時間を戻すために使うものだと私は考えています。

---

考察：WordPress 7.0.2時代だからこそ検証日を残す

もう一つ、今回の記事を更新するうえで重要だと感じたのが「検証日」です。

WordPress 7.0.2が2026年7月17日に公開されているように、WordPressは更新され続けています。

さらに7.1のベータ版も2026年7月には公開されています。

つまり、「この記事のコードはWordPressで動きます」という一文だけでは、読者へ十分な情報を渡せません。

いつの環境で確認したのか。

何を確認したのか。

どの編集画面を対象にしたのか。

こうした情報を明記するほうが、技術記事としてははるかに誠実です。

今回のような内容なら、検証情報を次のような形で残しておく方法があります。

“`
検証基準日：2026年8月12日WordPress：7.0.2対象：Classic Editorによるクラシック編集画面確認項目：TinyMCEボタンフック、外部プラグイン読み込み、エディタCSS
“`

ただし、ここでも注意が必要です。

この記事ではWeb上の公式資料からWordPressの現行フックやバージョン情報を確認していますが、読者それぞれの環境で独自JavaScriptが必ず動くことまで保証するものではありません。

ここを曖昧にしないことが大切です。

技術記事で怖いのは、検証していないコードを「確実に動きます」と断定することです。

私は、分からない部分を分かったふりで書くより、「ここは環境依存なので確認が必要です」と伝えるほうが、長期的には信頼できる情報になると考えています。

---

WordPressクラシックエディタのカスタマイズは何から始めればいい？

初心者なら、いきなりJavaScriptを書く必要はありません。

まず今日の記事作成で、一番面倒な操作を1つ探してください。

たとえば、

• マーカーを付けるたびにHTMLを書く
• 定型文を毎回コピーする
• 使わないボタンが多く目的の機能を探しにくい

このどれかでも構いません。

そして、その問題に対して最小限のカスタマイズを考えます。

不要なボタンなら`mce_buttons`系で整理する。

独自ボタンが必要なら`mce_buttons`と`mce_external_plugins`を組み合わせる。

編集画面の見た目なら`add_editor_style()`を検討する。

WordPress公式資料でも、これらの仕組みは現在のDeveloper Resourcesに掲載されています。

つまり、クラシックエディタは「昔の画面だから何もカスタマイズできない」のではありません。

現在もWordPress側には、TinyMCEを扱うための拡張ポイントが残っています。

ただし、拡張ポイントが現在も存在することと、昔のコードを無条件に使えることは別問題です。

ここだけは覚えておいてください。

---

よくある質問

WordPressクラシックエディタは2026年も使えますか？

使えます。

2026年8月12日時点でもClassic EditorはWordPress.orgで提供されており、WordPress 7.0.2でテスト済みとされる情報も確認できます。

ただし、公式プラグインページには古いサポート表記も残っているため、将来まで無条件に現在と同じ環境が続くと断定するのは避けたほうがよいでしょう。

クラシックエディタのボタンを削除するには何を使いますか？

TinyMCEのツールバーを変更する`mce_buttons`、`mce_buttons_2`、`mce_buttons_3`、`mce_buttons_4`を使います。

それぞれ1〜4行目のボタン一覧を対象にします。

独自ボタンを追加するには何が必要ですか？

基本的には、`mce_buttons`系でボタンを登録し、`mce_external_plugins`で独自JavaScriptをTinyMCEへ読み込ませます。

ただしJavaScript側のTinyMCE APIは、利用中のWordPress環境との互換性を確認する必要があります。

編集画面に独自CSSを反映できますか？

できます。

WordPressの`add_editor_style()`を利用して、TinyMCEのビジュアルエディタへカスタムスタイルシートを追加できます。

公開ページで装飾されているのに編集画面で表示されない場合は、編集画面側のCSS読み込みを確認してください。

WordPress 7.0.2はいつ公開されましたか？

2026年7月17日に公開されました。

WordPress.orgでは7.0系列の最新リリースとして7.0.2が掲載されています。

クラシックエディタとブロックエディタのClassic Blockは同じですか？

完全に同じではありません。

WordPress公式のTinyMCE関連フックでは、Classic Blockから呼ばれる場合に`classic-block`という`editor_id`が渡されることがあります。

そのため、Classic Editorの投稿編集画面とClassic Blockは分けて動作確認したほうが安全です。

`functions.php`へ直接コードを書いても大丈夫ですか？

可能ですが、変更前のバックアップは必須です。

PHPの記述ミスがあると管理画面やサイト表示へ影響する可能性があるため、可能であれば子テーマ、サイト専用プラグイン、ステージング環境など、戻しやすい方法で試すことをおすすめします。

古いTinyMCEのコードはすべて使えないのですか？

すべて使えないわけではありません。

問題は、現在のWordPress環境で検証されているか分からないコードを、そのまま使うことです。

公開年、WordPressの対象バージョン、TinyMCE API、現在の公式リファレンスを確認して判断してください。

---

まとめ：WordPressクラシックエディタは「今の環境」でカスタマイズする

WordPressクラシックエディタは、2026年8月現在も利用できます。

WordPress本体の最新安定版は7.0.2で、Classic EditorもWordPress.orgで現在提供されています。

カスタマイズの基本は明快です。

ボタンの追加・削除には`mce_buttons`系、独自TinyMCEプラグインの読み込みには`mce_external_plugins`、編集画面のCSSには`add_editor_style()`を使います。

ただし、2026年のWordPress環境で最も大切なのは、古いコードをそのまま信じないことです。

WordPress公式も外部TinyMCEプラグインにはバージョン互換性が必要だと説明しています。

だから、ネットで見つけたコードを貼って終わりにはしません。

WordPress本体のバージョン、Classic Editorの状態、TinyMCE、テーマ、PHP、JavaScript、CSSをまとめて確認する。

これが安全なカスタマイズの基本です。

そして、もう一つ忘れないでください。

カスタマイズの目的は、ボタンを増やすことではありません。

コードを書くことでもありません。

記事を書く時間を増やし、面倒な作業を減らすことです。

毎回同じHTMLを書く。

毎回同じ装飾をする。

毎回使わないボタンの中から目的の機能を探す。

そんな小さなストレスがあるなら、そこから1つだけ改善してみてください。

不要なボタンを1つ削る。

必要な機能を1つ追加する。

編集画面へCSSを1つ反映する。

それで十分です。

WordPress 7.0.2のように本体が進化し続ける