本記事はローカル LLM による自動執筆パイプラインで生成されました。現段階ではクラウド AI（Claude 等）の補助や人間の編集が介在していますが、pareido.jp では最終的に AI が自律的にコンテンツを制作できる仕組みの構築を目指しています。
こんにちは、パレイド技術部です。
前回はブログカードの往復変換を実装しました。今回は、WordPress プラグインが追加するカスタムブロックの扱いについてです。
問題：プラグインブロックは無数にある
WordPress の強みはプラグインの豊富さですが、それは同時に Gutenberg ブロックの種類が際限なく増えることを意味します。pareido.jp で利用している Cocoon テーマだけでも、ブログカード、ハイライト（マーカー）、タブボックス、アコーディオンなど、独自ブロックが多数あります。
これらすべてに個別の Markdown 記法と変換ロジックを用意するのは現実的ではありません。新しいプラグインを導入するたびに変換コードを書き足すことになり、メンテナンスが追いつかなくなります。
方針：変換せずにそのまま通す
そこで採った方針は「プラグインブロックは変換しない」です。Gutenberg のコメントタグをそのまま Markdown ファイルに保持し、アップロード時にもそのまま WordPress に戻します。
具体的には、wp:名前空間/ブロック名 という形式のブロックを「プラグインブロック」として検出します。WordPress 標準のブロック（wp:paragraph、wp:heading 等）は名前空間を持たないため、この区別は明確です。
wp:paragraph → 標準ブロック（Markdown 変換対象）
wp:cocoon-blocks/blogcard → プラグインブロック（パススルー）
wp:cocoon-blocks/highlighter → プラグインブロック（パススルー）ダウンロード時：ブロックをそのまま保持
WordPress から記事をダウンロードする際、通常の Gutenberg コメントタグ（<!-- wp:paragraph --> 等）は除去して Markdown に変換します。しかしプラグインブロックは、タグも中身もそのまま Markdown ファイルに書き出します。
# プラグインブロック（名前空間付き）をプレースホルダに退避
PLUGIN_RE = re.compile(
r'<!-- wp:[a-zA-Z0-9_-]+/[a-zA-Z0-9_-]+ .*?-->.*?'
r'<!-- /wp:[a-zA-Z0-9_-]+/[a-zA-Z0-9_-]+ -->',
re.DOTALL,
)
def stash(m):
key = f"WPPLUGBLOCK{len(placeholders):04d}"
placeholders[key] = m.group(0)
return key
text = PLUGIN_RE.sub(stash, raw_content)
# ... 標準ブロックの変換・Markdown化 ...
# プレースホルダを元のブロックに復元
for key, block in placeholders.items():
text = text.replace(key, block)結果として、Markdown ファイルの中にこんな断片が現れます。
前の段落のテキスト。
次の段落のテキスト。見た目は少々雑多ですが、Markdown のプレビューでは HTML としてそのまま表示されるため、内容の確認には困りません。
アップロード時：ブロックをそのまま復元
アップロード側でも同じ仕組みです。Markdown → HTML 変換の前にプラグインブロックをプレースホルダに退避し、変換エンジンに触らせないようにします。最終的な Gutenberg 出力で元のブロックに復元します。
このパススルーにより、WordPress 側で Cocoon のハイライトを設定した記事をダウンロードし、Markdown 上でテキストだけ修正してアップロードし直しても、ハイライトの設定はそのまま保持されます。
往復の信頼性
このパススルー方式の利点は、知らないブロックでも壊さないことです。新しいプラグインを入れても、変換コードの修正は不要です。wp:名前空間/ブロック名 の形式に従っている限り、自動的にパススルーされます。
一方で制約もあります。
- Markdown ファイル上でプラグインブロックの中身を編集すると、WordPress 側のブロック構造が壊れる可能性がある
- Markdown のプレビューではブログカードのような見た目にはならない（生 HTML が表示される）
- 新規記事をゼロから Markdown で書く場合、プラグインブロックを使いたければ Gutenberg のタグを直接書く必要がある
実運用としては、プラグインブロックの追加・編集は WordPress 側で行い、テキスト本文の修正は Markdown 側で行う、という棲み分けが自然です。
Markdown で簡易記法を用意する余地
前回のブログカード（
）のように、よく使うプラグインブロックには Markdown 側の簡易記法を用意する余地はあります。例えば Cocoon のハイライトなら：
==ハイライトしたいテキスト==のような記法を定義して、アップロード時に wp:cocoon-blocks/highlighter に変換する、といった拡張です。ただし、現時点では需要と実装コストのバランスを見て、今後の ToDo としています。
まとめ
プラグインブロックの扱いは「全部個別対応」ではなく「まるごとパススルー」にすることで、メンテナンスコストを最小限に抑えました。名前空間付きブロックを自動判別し、変換を迂回させるだけのシンプルな仕組みですが、往復変換の信頼性を大きく高めてくれます。
このシリーズの次回以降では、実際の運用で見つかったエッジケースや、同期のコンフリクト解決について掘り下げていく予定です。
