WordPressで技術記事を書く際、コードブロックの可読性は記事品質を大きく左右します。
とくに Google Apps Script（GAS）や JavaScript 系の記事では、シンタックスハイライトが正しく効いているかどうかで、読者の理解度がまったく変わります。
通常のGutenberg操作では問題なく使える Highlighting Code Block（HCB） ですが、
REST API 経由で記事を投稿する場合、コードブロックが意図通りに表示されないケースがあります。
この記事では、REST API から投稿しても HCB のコードブロックとして正しく認識させる方法を、実装ベースで整理します。
結論：Gutenberg ブロックコメント形式で送るのが最も安定する
REST API 経由で HCB を使う場合、
単純に <pre><code> を送るだけでは不十分です。
**Gutenberg が理解できる「ブロックコメント形式」**で本文を構成する必要があります。
HCB が認識する基本構造
HCB は内部的には「Gutenberg の code ブロック」として処理されます。
そのため、本文中に次の形式が含まれていることが重要です。
<!-- wp:code -->
<pre class="wp-block-code"><code class="language-javascript">
function sample() {
Logger.log("Hello World");
}
</code></pre>
<!-- /wp:code -->
この <!-- wp:code --> ～ <!-- /wp:code --> があることで、
- Gutenberg が「これはコードブロックだ」と判断
- HCB がフックしてシンタックスハイライトを適用
という流れになります。
REST API に送る content の具体例
たとえば、Node.js や GAS から REST API を叩いて投稿する場合、content フィールドには そのまま文字列として 以下を含めます。
{
"title": "TypeError: xxx is not a function の原因と対処法",
"status": "publish",
"content": "<!-- wp:code -->\n<pre class=\"wp-block-code\"><code class=\"language-javascript\">function test() {\n const x = {};\n x();\n}\n</code></pre>\n<!-- /wp:code -->"
}
ポイントは次の通りです。
<br>は使わない（必ず\n）- HTML エスケープを二重にしない
language-javascriptは HCB 側の設定と合わせる
よくある失敗パターン
<pre><code> だけ送っている
<pre><code>...</code></pre>
この場合、Gutenberg上ではただのHTMLとして扱われ、
HCB のシンタックスハイライトが効かないことがあります。
HTML エスケープしすぎている
<pre><code>
REST 側でエスケープしすぎると、
WordPress 側で「コードとして解釈されない」状態になります。
送信前のエスケープは最小限にします。
HCB を使うメリット（REST運用でも）
HCB を使うメリットは、REST API 運用でも変わりません。
- 言語指定が明確（
language-javascriptなど） - テーマ変更に強い
- Gutenberg ネイティブなので将来のWP更新に追従しやすい
- 技術記事としての信頼性が上がる
大量の記事を自動投稿する場合ほど、
コードブロックの安定性＝記事品質になります。
ZIDOOKA! での運用メモ
ZIDOOKA! では、
- CLI から Markdown → HTML 変換
- コードブロック部分だけ Gutenberg コメント構造に変換
- REST API で一括投稿
という流れで運用しています。
この方式にしてから、
- コード崩れ
- ハイライト不一致
- テーマ依存トラブル
がほぼなくなりました。
まとめ
REST API 経由で HCB を使う場合は、
- Gutenberg ブロックコメント形式を守る
<pre><code>を単体で送らない- 改行は
\nを使う
これだけで、通常投稿と同じ安定したコードブロック表示が実現できます。
GAS や JavaScript 系の記事を量産するなら、
この実装は一度組んでおくと、あとがかなり楽になります。
