2026 年 5 月、gihyo.jp が Vercel Labs、Markdownの表示・操作体験を定める仕様案「MDXG」を提案 を報じました。Markdown 拡張仕様 MDX に「ユーザー体験（Gestures）」レイヤを追加し、コードブロックのタブ切替・展開可能ブロック・LLM 差分表示・インタラクティブ要素などを 仕様として定義する動きです。
この提案が刺さるのは **「LLM が生成した Markdown を、UI として安定的にレンダリングする」領域です。弊社の受託案件でも Astro / Next.js / Notion ベースのドキュメント基盤を構築する際、「Markdown のレンダリングルール」**を クライアントごとにバラバラに実装してきた現実があります。MDXG の仕様化は、この受託の “車輪の再発明”を 根本から削減する可能性を持ちます。
なぜ「Markdown UI 標準化」が今必要か
| 状況 | 従来 | MDXG 提案後 |
|---|---|---|
| コードブロック表示 | カスタム実装 | 標準コンポーネント |
| LLM 差分（diff）表示 | 各社実装 | 仕様で定義 |
| タブ切替 | 各社のシンタックス | 仕様で統一 |
| 展開可能ブロック | details/summary 直書き | 標準コンポーネント |
| 多言語切替 | i18n キー直書き | データ属性で表現 |
特に 「LLM 出力を Markdown でレンダリングするとき」の フォーマット崩れは、チャット UI / ドキュメント / 社内 Wikiで 同じバグを各社が踏み続けてきた領域です。MDXG は この問題を仕様レベルで解決しようとしています。
受託でドキュメント基盤を再設計する 4 つの設計原則
原則 1: 「Markdown は仕様、UI は実装」を分離する
Markdown 本文と MDXG が定義する UI 拡張を 明確に分離します。Markdown 本文は GitHub / Notion / Wiki に保存し、MDXG レンダラはサイト側で実装する構成にします。これにより、コンテンツの保管場所と表示エンジンを独立進化させられます。これは Astro と Cloud Build の連携 で扱った 「コンテンツとサイトの境界」を より厳密に運用する設計です。
原則 2: LLM 出力レンダラは「再生可能性」を担保
LLM が 同じ入力で同じ Markdown を返す保証はないため、MDXG レンダラ側で「不正なネスト」「壊れたタブ」を graceful に処理する必要があります。fail-soft な実装が必須です。
原則 3: バックエンドエディタとフロントレンダラを「同一コントラクト」で結ぶ
Notion / Wiki / GitHub側のエディタが MDXG 拡張をサポートしていない場合、「書ける範囲」と「表示できる範囲」が 乖離します。受託ではエディタ側に MDXG パーサを組み込み、プレビュー一致を担保します。
原則 4: アクセシビリティを仕様レベルで担保
タブ・展開可能ブロックは キーボード操作 / スクリーンリーダー対応が必須です。MDXG 標準コンポーネントは aria 属性を仕様で固定し、アクセシビリティ監査の作業コストを削減します。
受託で構築する 4 つのフェーズ
フェーズ 1: 既存ドキュメント基盤の棚卸し（2 週間）
社内 Wiki / 顧客向けドキュメント / 製品ヘルプで 使われている Markdown 拡張を棚卸しし、MDXG への移行コストを試算します。
フェーズ 2: MDXG レンダラの実装（4 週間）
Astro / Next.js / Remixいずれかで MDXG 仕様準拠のレンダラを実装します。コードブロック・タブ・LLM 差分・展開可能ブロックの 4 つを最低保証とします。
フェーズ 3: 既存ドキュメント移行（4 〜 6 週間）
既存の独自拡張を MDXG 構文に書き換え、自動変換スクリプト + 目視レビューで移行します。
フェーズ 4: LLM 出力ライターと統合（3 週間）
Claude / GPT-5 が出力する Markdownを MDXG 仕様で出すよう、システムプロンプトを設計し、fail-soft レンダラと組み合わせて本番投入します。
受託向け技術スタック標準セット
| レイヤ | 推奨技術 | 代替 |
|---|---|---|
| MDX 基盤 | MDX 3 + remark / rehype | markdown-it + plugins |
| MDXG レンダラ | Astro Content Collections / Next.js MDX | Docusaurus |
| エディタ | TipTap + MDX 拡張 | Lexical |
| コードハイライト | Shiki | Prism |
| diff 表示 | diff2html | jsdiff |
| アクセシビリティ監査 | axe-core | Pa11y |
| LLM 出力検証 | Zod でスキーマ検証 | JSON Schema |
Vercel Open Agents — メンテナンス受託 や Vercel コスト × Bot 防御 — Web ホスティング受託 と組み合わせると、「Vercel エコシステム上で完結するドキュメント基盤」を 受託パッケージ化できます。
どの案件で刺さるか
| 向く案件 | 効果 |
|---|---|
| 製品ヘルプ / API ドキュメント | コードブロック / タブ統一 |
| 社内ナレッジ Wiki | LLM 出力の自動レンダリング |
| 開発者向けマニュアル | diff 表示で更新点を明示 |
| マルチ顧客 SaaS ドキュメント | 顧客別の拡張差分を吸収 |
| AI チャット UI | LLM 出力 Markdown の安定表示 |
受託契約に書く 5 つの条項
| 条項 | 内容 | 顧客が確認すべきこと |
|---|---|---|
| MDXG 仕様準拠範囲 | どの拡張を実装するか | 仕様未確定要素の扱い |
| 既存ドキュメント移行責任 | 受託 / 顧客の分担 | 移行漏れの責任 |
| LLM 出力の品質保証 | fail-soft の対応範囲 | 表示崩れの責任 |
| アクセシビリティ準拠 | WCAG レベル | 法的要件との整合 |
| 将来仕様変更への追従 | 月次 / 四半期で追従 | 改修範囲と費用 |
価格モデル — MDXG ドキュメント基盤受託パッケージ
| プラン | 金額 | 対象 | 内容 |
|---|---|---|---|
| 棚卸し評価 | 40 万円〜 | 2 週間 | 既存ドキュメント分析 + 移行試算 |
| Lite | 350 万円〜 | 8 週間 | レンダラ実装 + 1 サイト分の移行 |
| Standard | 900 万円〜 | 3 ヶ月 | 上記 + LLM 統合 + エディタ拡張 |
| Care（運用代行） | 月 35 万円〜 | 12 ヶ月〜 | 仕様追従 + ドキュメント運用代行 |
ハマりやすい 4 つの落とし穴
落とし穴 1: 「仕様策定中」を本番投入
MDXG は 2026 年 5 月時点でまだ仕様提案段階です。仕様の破壊的変更リスクを 設計初日に想定し、抽象化レイヤを必ず挟みます。
落とし穴 2: エディタ側の対応遅れ
Notion / Confluenceが MDXG 拡張をサポートしていない場合、「書く側」と「見る側」が乖離します。コメント記法 + プリプロセッサで 回避策を準備します。
落とし穴 3: LLM 出力の不安定さで本番表示が壊れる
LLM が壊れた MDXG を出した瞬間にページ全体が落ちる実装はアウトです。段落単位の fail-softで 「壊れた部分だけプレーンテキストに退化」させる graceful degradation を組み込みます。
落とし穴 4: アクセシビリティ要件の後付け
展開可能ブロック / タブを 後からアクセシブルにするのは大改修になります。初日から axe-core を CI に組み込み、規約違反を即時検出します。これは Astro Cloud Build エラー対応 のように CI 段階で品質を担保する思想です。
まとめ — 「Markdown は仕様、UI は実装」が標準になる
Vercel Labs MDXG 提案は、Markdown を「テキストのフォーマット」から「UI 仕様」へ昇格させる動きです。受託で繰り返してきた “車輪の再発明”を MDXG 準拠レンダラ + fail-soft 設計で 大幅に削減できる時代になりました。
弊社では 棚卸し評価 / Lite / Standard / Care の 4 段階で MDXG ドキュメント基盤受託パッケージを提供しています。「LLM 出力ドキュメントの表示が安定しない」「社内 Wiki と公開ドキュメントの体験を統一したい」というご相談は お問い合わせフォーム からお気軽にどうぞ。
