宮本です。WordPressのビジュアルエディタで記事を一つひとつ手打ち入稿していると、見出しレベルの付け間違いや装飾の統一漏れが起きやすく、記事本数が増えるほど手間がかさみます。とはいえ、独自ブロックをJS/PHPで開発するほどの本格的な仕組みは、日々の記事更新には大掛かりすぎることも少なくありません。

本記事では、既存ブロックのHTML規則を理解してコーディングで入稿するという、その中間にあたる実践的な方法を解説します。

そもそもGutenbergの「ブロック」とは？HTML構造を理解する

Gutenbergブロックエディタで作成した記事は、見た目上は普通の記事に見えますが、内部的には<!-- wp:paragraph -->のようなHTMLコメントで一つひとつの要素が区切られています。この構造を理解しておくことが、コーディングによる入稿の第一歩です。

ブロックは<!-- wp:paragraph -->のようなHTMLコメントで区切られている

このコメントは、WordPressがどの部分をどのブロック種別として扱うかを識別するための目印です。ブラウザ上には表示されず、記事の見た目には一切影響しません。

一方で、このコメントの対応関係を壊してしまうと、エディタを開いたときに次のようなエラーが表示されます。

コーディングで入稿する際は、開始コメントと終了コメントを必ずペアで記述する意識が重要です。

主要ブロックのHTML例とwp-block-クラスの命名規則

代表的なブロックの最小構成は、次のような形になります。

<!-- wp:paragraph -->
<p>段落のテキストです。</p>
<!-- /wp:paragraph -->

<!-- wp:heading {"level":2} -->
<h2 class="wp-block-heading">見出しのテキスト</h2>
<!-- /wp:heading -->

主要なブロックとクラスの対応をまとめると、次のとおりです。

ブロック	ブロックコメント	主なタグとクラス
段落	wp:paragraph	<p>（クラスなし）
見出し	wp:heading {"level":3}	<h3 class="wp-block-heading">
画像	wp:image	<figure class="wp-block-image size-large">
リスト	wp:list / wp:list-item	<ul class="wp-block-list">
テーブル	wp:table	<figure class="wp-block-table">
コード	wp:code	<pre class="wp-block-code">

表のとおり、多くのブロックにはwp-block-〇〇という命名規則のクラスが付与されますが、標準の段落ブロックだけは例外でクラスが付きません。「すべてのブロックに共通のクラスがある」と思い込んで存在しないクラスを書き足したり、逆に必要なクラスを付け忘れたりすると、テーマのスタイルが正しく当たらず表示が崩れる原因になります。

「カスタムHTMLブロック」と「コードエディター」は別物

Gutenbergには名前が似ている機能が二つあり、既存の解説記事でも混同されがちです。ここで明確に整理しておきます。

	カスタムHTMLブロック	コードエディター
対象範囲	記事の中の1ブロックだけ	記事全体
主な用途	地図・動画・広告タグの埋め込み	記事まるごとの貼り付け・一括編集
呼び出し方	ブロック挿入メニューから追加	右上のオプションメニュー →「コードエディター」

カスタムHTMLブロックは記事内の一部に埋め込む部品

「カスタムHTML」は、あくまで記事の中にある一つのブロックです。Googleマップの埋め込み、YouTube動画の埋め込み、広告タグの挿入など、記事の一部分だけをHTMLとして扱いたい場合に使います。

コードエディターは記事全体をHTMLで直接編集するモード

一方の「コードエディター」は、右上のオプションメニュー（︙）にある「コードエディター」から呼び出せる、記事全体をHTMLとして直接編集・貼り付けできるモードです。Ctrl + Shift + Alt + M（Macは⌘ + Shift + Option + M）のショートカットでも切り替えられます。

本記事で扱う「ブロックのコーディング入稿」は、この記事全体を貼り付けられるコードエディターを使う手法を指します。カスタムHTMLブロックとは対象範囲も用途も異なるので、混同しないよう区別しておきましょう。

なぜ「手動コーディング入稿」が効率的なのか

ビジュアルエディタでの手打ちはミス・表記ブレが起きやすい

ビジュアルエディタで一つずつ操作しながら入稿していると、こまかなミスが積み重なりやすくなります。実際によく起きるのは、次のようなものです。

• 見出しレベル（H2/H3）の付け間違い・入れ子の崩れ
• 画像のaltテキストの入れ忘れ
• 太字や箇条書きの使い方が記事ごとにバラつく
• 全角・半角や記号の表記ゆれ

特に複数の記事を並行して作る場面では、こうしたブレが一気に増えます。

Markdown原稿からHTMLへ変換する流れなら再現性とスピードが上がる

執筆はMarkdown（draft.md）、コーディングはブロックHTML（block.html）、入稿はコードエディターへの貼り付け、というように工程を分離すると、それぞれの作業に集中できて再現性が高まります。原稿の内容確認とHTMLの構文確認を同時にやろうとしないだけでも、ミスは大きく減らせます。

チーム全員で同じマークアップに揃えられる

ブロックのHTML規則さえ共有しておけば、担当者が誰であっても同じ見た目・同じマークアップの記事に仕上がります。ビジュアルエディタの操作手順を都度説明するよりも、次の2つを用意して渡すほうが、引き継ぎも属人化の解消もスムーズです。

• コーディング規約のドキュメント：使用するブロックの種類、クラス名の付け方、画像の扱い方をまとめておく
• ブロックパターンのテンプレート：「見出し + 本文 + 画像」など繰り返し登場する構成を雛形として保存しておく

カスタム投稿タイプでのブロックエディタ運用を長く続けるほど、こうした資産が効いてきます。

カスタム投稿タイプでブログを運用するメリットと注意点

標準の「投稿」と切り離してコンテンツを整理できる

WordPressの標準機能である「投稿」だけで運用すると、お知らせ・採用情報・ブログなど性質の異なるコンテンツが一箇所に混在してしまいます。カスタム投稿タイプを使えば、これらをblogやnewsのように分けて管理でき、テンプレートや一覧表示のロジックも投稿タイプごとに独立させられます。

カスタム投稿タイプでブロックエディタを使うための設定ポイント

カスタム投稿タイプをregister_post_type()で登録する際、show_in_restをtrueにしないとブロックエディタ（Gutenberg）が有効になりません。ブロックエディタはREST APIを経由して動作する仕組みのため、この設定が抜けているとクラシックエディタのままになってしまいます。あわせてsupportsにeditorを含めておく必要もあります。

register_post_type( 'blog', array(
    'label'        => 'ブログ',
    'public'       => true,
    'has_archive'  => true,
    'show_in_rest' => true, // これがないとブロックエディタにならない
    'supports'     => array( 'title', 'editor', 'thumbnail', 'revisions' ),
) );

またカスタム投稿タイプを新規追加・変更した直後は、パーマリンク設定画面を開いて更新を行わないと、記事ページが404になってしまうケースがあります。運用を始める前に、次の点をチェックしておくと安心です。

• show_in_restがtrueになっているか
• supportsにeditorが含まれているか
• パーマリンク設定を一度保存し直したか
• 一覧画面（edit.php?post_type=xxx）から投稿タイプが正しく確認できるか

実践フロー：Markdown原稿からblock.htmlを作りコードエディターへ貼り付ける

ここからは、ブログ運用例を4ステップのフローを紹介します。

1. Markdownで下書き（draft.md）を作成する

まずは見出し・箇条書き・画像プレースホルダーをMarkdown記法で整理しながら、記事の下書きを作成します。この段階でHTMLの細かい構文を意識する必要はなく、構成と文章の質に集中できるのがMarkdownで書く一番のメリットです。

2. 画像を先にメディアライブラリへアップロードする

ここが最初のつまずきポイントです。ブロックHTMLを書き始める前に、使う画像をすべてメディアライブラリへアップロードしておきます。

手元のimages/section-03.jpgのような相対パスをそのまま貼り付けても、画像は表示されません。WordPressのアップロード先を指す絶対URLで書く必要があります。さらに、アップロード時に割り当てられる添付ファイルIDをid属性とwp-image-〇〇クラスに入れておくと、WordPressがレスポンシブ画像（srcset）を自動生成してくれます。

<!-- wp:image {"id":8206,"sizeSlug":"large"} -->
<figure class="wp-block-image size-large">
<img src="https://example.com/wp-content/uploads/2026/07/section-03.jpg"
     alt="画像の内容を表す代替テキスト" class="wp-image-8206"/>
</figure>
<!-- /wp:image -->

添付ファイルIDは、メディアライブラリで画像を開いたときのURL（upload.php?item=8206）から確認できます。

なお、アイキャッチ画像はブロックHTMLには含まれません。コードエディターへの貼り付けとは別に、投稿画面のサイドバーから設定してください。

3. 見出し・段落・リストをGutenbergブロックのHTML規則に沿って変換する

画像の準備ができたら、Markdownの記法をブロックのHTMLに置き換えていきます。対応関係は次のとおりです。

Markdown記法	変換先のブロック
# ## ###	wp:heading（level属性で階層を指定）
通常の段落	wp:paragraph
- * の箇条書き	wp:list + wp:list-item
	wp:image
表組み	wp:table
コードブロック	wp:code

見出しレベルは、テーマがどのレベルを本文の大見出しとして想定しているかに合わせます。記事タイトルがH2で出力されるテーマなら本文はH3から始める、といった具合です。

4. コードエディターに貼り付けてビジュアル表示で確認する

block.htmlが完成したら、WordPress管理画面でコードエディターに切り替え、内容をまるごと貼り付けます。貼り付けて終わりにせず、必ずビジュアルエディタに戻して表示崩れがないか確認する一手間を欠かさないことが、コーディング入稿を安全に運用するコツです。

手動コーディング入稿でよくあるつまずきポイントと対処法

コーディングでの入稿に慣れないうちは、いくつか共通してつまずきやすいポイントがあります。あらかじめ知っておくと、原因の切り分けがスムーズになります。

閉じタグ漏れ・クラス名のズレでブロックが壊れる

先ほどの「このブロックには、想定されていないか無効なコンテンツが含まれています」というエラーは、開始コメントと終了コメントの対応が崩れていたり、wp-block-〇〇のクラス名が抜けていたりする場合によく発生します。エラーが出たときは、該当ブロックのコメントとタグの対応を上から順に見直すのが確実です。

画像が表示されない・レイアウトが崩れる

画像まわりは特にトラブルが起きやすい箇所です。次の4点をチェックリストにしておくと安心です。

• srcが相対パスのままになっていないか（絶対URLが必須）
• id属性とwp-image-〇〇クラスが入っているか（抜けるとsrcsetが生成されない）
• figureタグで囲めているか、size-largeなどのサイズクラスが付いているか
• altテキストを入れ忘れていないか（SEO・アクセシビリティの両面で見落としやすい）

貼り付け後の確認を省略しない

コーディングに慣れてくると、貼り付けた後の確認作業を省略したくなりますが、これは避けたい落とし穴です。プレビュー確認をルーティンとして毎回組み込むことで、公開後に崩れが見つかるといったトラブルを未然に防げます。

まとめ

Gutenbergのブロック構造を理解し、Markdown原稿からHTMLへコーディングして入稿する方法は、独自ブロック開発ほど大掛かりではなく、ビジュアルエディタでの手打ちよりも速く正確に記事を仕上げられる手法です。カスタム投稿タイプの運用と組み合わせれば、制作会社レベルで記事を量産する体制にも耐えられるフローになります。