🧭 はじめに
管理人のTKGです。今回の記事では、microCMSのコンテンツ作成基盤をMarkdownからリッチエディタに移行した際の具体的な手順と、そこで直面した課題や解決策についてご紹介します。
元々、当サイトではmicroCMSのテキストフィールドにMarkdownで記述し、フロントエンド（Next.js）でHTMLに変換していました。
この構成は、過去にNewtから移行した際にリッチエディタの技術的課題が解決できなかった名残でした。
しかし、より視覚的に分かりやすいコンテンツ、例えば図や写真を効果的に活用したいという思いが強くなり、執筆体験の向上を目指して、本格的なリッチエディタへの切り替えを決断しました。
本記事では、この移行作業をどのように進めたか、そして同様の課題を抱える方がスムーズに移行できるよう、具体的なステップと注意点を共有します。
🧩 リッチエディタ移行の代表的な手順とフェーズ
リッチエディタへの移行は、単にCMSの設定を変えるだけではなく、フロントエンドの実装変更や既存コンテンツの移行まで、複数のフェーズに分かれます。
フェーズ 主な作業内容 担当ノード・AIの役割
- CMSのスキーマ設計
- 既存フィールドの変更は避け、新しいリッチエディタフィールドを追加する。
- microCMS：リッチエディタを新規追加し、既存のフィールドはSEO用途に再定義
- フロントエンドの実装
- Markdownパーサーを廃止し、リッチテキストを安全に表示するライブラリに切り替える。
- Next.js：表示ライブラリを
html-react-parserとisomorphic-dompurifyに変更
- コンテンツの移行
旧フォーマットのテキストを新しいフィールドにコピー＆再設定する。- 手動作業：Markdownからリッチテキストへ手動でスタイルを再適用
🛠️ 移行で使われる主な技術スタック
今回のワークフローで中心となった技術スタックとその役割です。
✅ CMS（コンテンツ管理の起点を作る）
microCMS
主な用途: コンテンツの管理
特徴: APIベースの国産ヘッドレスCMS。
今回は、リッチエディタ機能を持つricheditorフィールドを新規で追加し、コンテンツの入力基盤を刷新。
既存のbodyフィールドは、最終的に不要となったため、動作確認後に削除。
✅ フロントエンドフレームワーク（表示部分を担当）
Next.js
主な用途: ユーザーに記事を表示
特徴: 今回のプロジェクトで採用しているフレームワーク。
microCMSから取得したリッチテキスト形式のHTMLを安全に表示するためのライブラリを導入し、表示ロジックを書き換え。
✅ ライブラリ（知的タスクを担当）
html-react-parser
主な用途: HTML文字列をReact要素に変換
特徴: microCMSから取得したHTMLを、Reactのコンポーネントとして画面に表示するために利用。
Markdownから変換されたテキストではなく、リッチエディタの生のHTMLを扱えるようになる。
isomorphic-dompurify
主な用途: HTMLのサニタイズ（無害化）
特徴: リッチエディタからの入力に悪意のあるスクリプトが含まれるリスクを排除するために導入。
安全なコンテンツ表示を実現する上で不可欠なライブラリ。
🎯 移行作業でつまずいた点と解決策
スムーズに見えた移行作業ですが、いくつかの予期せぬ問題に直面しました。これらは、基本的なデータフローの理解やライブラリの正しい使い方に起因していました。
問題1: リッチエディタの内容が表示されない
- 原因: microCMSからデータを取得する
formatArticleのようなデータ整形処理で、新しく追加したricheditorフィールドの値を最終的なオブジェクトに渡し忘れていたため、フロントエンドにデータが届いていませんでした。 - 解決策: APIレスポンスからフロントエンドの表示コンポーネントまで、データの流れを丁寧に追跡。型定義ファイル（
types/article.ts）にもricheditor?: stringを追加し、データの欠落を防ぎました。
問題2: 画面にHTMLタグがそのまま表示される
- 原因: 表示コンポーネント（
[slug]/page.tsx）で、サニタイズした後のHTML文字列を**parse()関数に渡すのを忘れていました**。 - 解決策: 変更後の表示コンポーネントを
<ReactMarkdown>から{parse(DOMPurify.sanitize(...))}に書き換えることで、HTML文字列が正しくReact要素に変換され、意図した通りに表示されるようになりました。
📝 まとめと今後の展望
今回のリッチエディタ移行作業を通じて、執筆体験の向上と表現の幅の拡大という大きなメリットを得ることができました。
Markdownでの記述は慣れれば高速ですが、特に画像やリスト、見出しの階層などを視覚的に確認しながら作成できるリッチエディタは、コンテンツ作成のクオリティを底上げしてくれます。
今回の移行は、Markdownからリッチテキストへの手動移行という力技でしたが、今後同様の作業が発生した場合、移行スクリプトを作成する方が良いと考えています。
また、リッチエディタの機能をさらに活用し、より複雑なレイアウトのコンテンツや、インタラクティブな要素も取り入れられるよう、引き続き技術的な改善を進めていく予定です。
もし、同様に「もっと魅力的なコンテンツを作りたいけど、CMSの制限に悩んでいる」という方がいらっしゃれば、今回の記事が技術的なヒントになれば幸いです。
Share this post