はじめに
技術ドキュメントの執筆やナレッジ共有ツールとして、Markdown はいまや欠かせない存在です。GitHub、Qiita、Zenn など多くのサービスが Markdown に対応しており、「Markdown が書ければどこでも同じように表示される」と思いがちです。
ところが、プリザンターの Markdown は他のサービスとはちょっと違う部分があります。普段 GitHub や Qiita で書き慣れている Markdown をそのまま持ち込むと、思ったとおりに表示されなかったりすることも。
この記事では、一般的に使われている Markdown サービスとプリザンターの Markdown を比較して、気をつけるポイントを紹介します。
バージョン 1.5.1.0 までを対象にしています
プリザンターの Markdown の特徴
まず、プリザンターの Markdown には他のサービスと大きく異なる特徴があります。
| 特徴 | 内容 |
|---|---|
| パーサー | marked.js v17（GFM モード） |
| レンダリング | クライアントサイド（ブラウザ上で変換） |
| 起動方法 | テキストの1行目に [md] を書く |
| HTML の扱い | 全エスケープ（生 HTML は使用不可） |
| サニタイズ | DOMPurify による多層防御 |
GitHub や Qiita がサーバーサイドでレンダリングするのに対し、プリザンターはブラウザ上の JavaScript（marked.js）で変換しています。これが機能差の背景にもなっています。
[md] プレフィックスが必要
プリザンターで Markdown を使うには、テキストの1行目に [md] と書く必要があります。
[md]
# 見出し
こんにちは **太字** です。
[md] がないと「Notes モード」として扱われ、リンクと画像のみが処理されます。他のサービスから Markdown を持ち込むときは、まずこの [md] の追加を忘れないようにしましょう。
基本構文の比較
見出し、太字、リスト、テーブル、コードブロック、引用、タスクリスト、リンク・画像といった基本的な Markdown 構文は、プリザンターを含めてどのサービスでも問題なく使えます。「普通の Markdown」を書いている分にはサービス間で困ることはありません。
差が出てくるのはここから先です。
改行の挙動に注意
実は、サービスによって改行の扱いが違います。これは地味に引っかかりやすいポイントです。
| 挙動 | Pleasanter | GitHub | Qiita | Zenn | GitLab |
|---|---|---|---|---|---|
単一改行 → <br>
|
対応 | 非対応 | 対応 | 対応 | 非対応 |
末尾2スペース + 改行 → <br>
|
対応 | 対応 | 対応 | 対応 | 対応 |
プリザンター・Qiita・Zenn では、テキスト中で Enter キーを1回押しただけの改行がそのまま改行として表示されます（breaks: true 相当）。
一方、GitHub・GitLab では1回の改行はスペースとして扱われ、改行にならないのが CommonMark の仕様です。改行したい場合は末尾にスペース2つを付けるか、空行を入れる必要があります。
GitHub → プリザンターの移行では、この違いは特に問題になりません。逆に、プリザンター → GitHub への移行時は改行が消えてしまう可能性があるので要注意です。
生の HTML が使えない
ここが最大の違いです。
GitHub や Qiita では details, summary, sup, kbd といった HTML タグを Markdown 内にそのまま書けます。しかし、プリザンターではすべての HTML タグがエスケープされます。
| 構文 | Pleasanter | GitHub | Qiita | Zenn | GitLab |
|---|---|---|---|---|---|
| インライン HTML | 非対応 | 対応 | 一部対応 | 一部対応 | 対応 |
| ブロックレベル HTML | 非対応 | 対応 | 一部対応 | 非対応 | 対応 |
| HTML コメント | 非対応 | 対応 | 対応 | 対応 | 対応 |
具体的に困るケース
GitHub でよく使われる以下のような記法は、プリザンターではそのままテキストとして表示されてしまいます。
<!-- これはコメント（表示されない）-->
<details><summary>クリックで展開</summary>
隠れる内容
</details>
<kbd>Ctrl</kbd> + <kbd>C</kbd>
文字の<sup>上付き</sup>と<sub>下付き</sub>
プリザンターではこれらがタグごとそのまま文字列として表示されるので、HTML タグに頼った表現は使わないようにしましょう。
プリザンターは全 HTML エスケープ + DOMPurify の多層防御で、セキュリティ面では最も厳格です。業務アプリとしては安全性を重視した設計です。
拡張構文の対応状況
数式やダイアグラムなどの拡張構文は、サービスごとの差が大きい領域です。
数式（$\LaTeX$）
| 構文 | Pleasanter | GitHub | Qiita | Zenn | GitLab |
|---|---|---|---|---|---|
インライン数式 $...$
|
非対応 | 対応 | |||
ブロック数式 $$...$$
|
非対応 | 対応 |
ダイアグラム（Mermaid 等）
| 構文 | Pleasanter | GitHub | Qiita | Zenn | GitLab |
|---|---|---|---|---|---|
| Mermaid | 非対応 | 対応 | 非対応 | 非対応 | 対応 |
プリザンターには Mermaid のライブラリが同梱されていますが、Markdown フィールドでは利用されません。
その他の拡張構文
| 構文 | Pleasanter | GitHub | Qiita | Zenn | GitLab |
|---|---|---|---|---|---|
脚注 ([^1]) |
非対応 | 対応 | 対応 | 対応 | |
| アラート / Note 記法 | 非対応 | 対応 | 対応 | 対応 | |
| 絵文字ショートコード | 非対応 | 対応 | 対応 | 対応 | |
| ユーザーメンション | 非対応 | 対応 | 対応 | 対応 | |
| 見出しの自動アンカー | 非対応 | 対応 | 対応 | 対応 |
拡張構文はプリザンターではほぼ非対応です。他のサービスでこれらを使った Markdown をそのまま持ち込んでも表示されないので、基本構文だけで書くことがポイントです。
なお、プリザンターの Markdown は marked.js ベースなので、拡張 API を使って数式や Mermaid などの機能を追加できる余地があります。今後コントリビュートで対応を進めていくかもしれません。
シンタックスハイライトの違い
コードブロックに言語を指定するとシンタックスハイライトが効きますが、仕組みが異なります。
| 項目 | Pleasanter | GitHub | Qiita |
|---|---|---|---|
| エンジン | highlight.js | Linguist ベース | Rouge / 独自 |
| 対応言語数 | 約40言語 | 数百言語 | 多数 |
| 言語未指定時 | 自動検出 | ハイライトなし | ハイライトなし |
| ファイル名表示 | 非対応 | 非対応 | 対応 |
| コピーボタン | 対応 |
プリザンターの特徴は、言語を指定しなくても highlightAuto（自動検出）が働くこと。逆に言えば意図しない言語で色がつく場合があるので、言語指定はしておいたほうが確実です。
また、Qiita で使える「ファイル名付きコードブロック」（```ruby:app.rb）はプリザンターでは対応していません。
プリザンター独自の強み
ここまで「プリザンターは非対応」の話が多かったですが、業務アプリとして独自の良さもあります。
| 機能 | 説明 |
|---|---|
| UNC パスの自動リンク |
\\server\share\path を file:// リンクに自動変換 |
| IBM Notes リンク |
notes:// プロトコルをそのままリンク化 |
| サムネイル・ライトボックス | 画像クリックでモーダル拡大表示 |
| カメラ撮影 | モバイルからカメラ撮影して画像を直接挿入 |
| ビューア切替 | エディタ ↔ プレビューの表示モードを Auto/Manual/Disabled で切替 |
target="_blank" リンク |
外部リンクを新しいタブで開く設定 |
特に UNC パスの自動リンクは、社内ファイルサーバーへのパスを貼るだけでリンクになるので、業務利用では非常に便利です。これは他のサービスにはない機能です。
移行時のチェックリスト
他のサービスとプリザンターの間で Markdown コンテンツを移行する際は、以下をチェックしましょう。
他サービス → プリザンター
-
[md]プレフィックスを1行目に追加する - 生 HTML（
details,sup,kbd等の HTML タグ）を削除・代替する - 数式（
$...$）やダイアグラム（Mermaid）を画像などに置き換える - サービス固有の拡張構文（
:::note,> [!NOTE]等）を除去する - 絵文字ショートコード（
:smile:）を Unicode 絵文字に変換する - ファイル名付きコードブロック（
```ruby:app.rb）の:ファイル名部分を除去する
プリザンター → 他サービス
-
[md]プレフィックスを削除する - 改行の表示を確認する（GitHub/GitLab では単一改行が反映されない）
- UNC パス（
\\server\share）や Notes リンクは手動でリンクに変換する - 画像の
?thumbnail=1パラメータを除去する
まとめ
一般的な Markdown サービスとプリザンターの Markdown を比較してみました。
- 基本構文（見出し・太字・リスト・テーブル・コードブロック等）は全サービスで共通
-
最大の違いはプリザンターの
[md]プレフィックス必須と、生 HTML が完全に無効化される点 -
改行の挙動はプリザンター・Qiita・Zenn が単一改行を
<br>変換、GitHub・GitLab は CommonMark 準拠 - 拡張構文（数式・Mermaid・脚注・アラート等）はプリザンターでは非対応
- プリザンターは業務向けの独自機能（UNC パス自動リンク・カメラ撮影・ライトボックス等）が充実
- セキュリティ面では全 HTML エスケープ + DOMPurify の多層防御で最も厳格
- 数式や Mermaid などの拡張構文は、今後コントリビュートで対応を進めていく予定です
「普通の Markdown」を書いていればサービス間の差はほとんど気になりませんが、便利な拡張構文を使いたい場合はプリザンターの対応状況に注意が必要です。