--- title: "MermaidとSyntax Highlightを入れた" slug: "mermaid-to-syntax-highlight-wo-ireta" publishedAt: "2026-06-14T02:01:40.265Z" updatedAt: "2026-06-14T02:01:40.337Z" tags: ["ampless","mermaid","syntax-highlight","技術"] excerpt: "amplessにMermaidとSyntax Highlightのプラグインを追加した。AI作画でも図表は作れるが、脳内の構造や状態遷移を少し直しながら示したいだけならMermaidが便利。ソースコードとレンダリング結果を並べて、テキスト作図の感覚を試してみる。" canonical: "https://ishinao.net/mermaid-to-syntax-highlight-wo-ireta" --- amplessに新しく、MermaidとSyntax Highlightのプラグインを追加した。 技術系ブログを書くなら、やっぱりこのへんは欲しい。コードブロックに色が付く。フローチャートやシーケンス図を本文に埋め込める。説明文だけでがんばるより、図やコードをそのまま置けるほうが表現力が上がる。 というわけで、簡単なサンプル記事を書いてみる。 ## コードブロック まずはSyntax Highlight。コードブロックに言語名を付けておくと、それっぽく色が付いて表示される。たとえばTypeScriptならこんな感じだ。 ```ts type PostStatus = 'draft' | 'published' type Post = { title: string body: string status: PostStatus } function canPublish(post: Post): boolean { return post.title.trim().length > 0 && post.body.trim().length > 0 } const post: Post = { title: 'MermaidとSyntax Highlightを入れた', body: 'サンプル記事を書いてみる。', status: 'draft', } console.log(canPublish(post)) ``` 色が付くだけと言えばそれだけなのだが、色が付くだけでかなり読みやすくなる。人間の脳は意外と単純である。黒一色のコードを見ると、急に全部が壁に見える。色が付くと、壁に窓が開く。 もちろん、コードの正しさが上がるわけではない。バグのあるコードは、きれいに色が付いてもバグのあるコードである。着飾ったバグである。ただし、読みやすくなると気づきやすくなることはある。そこはだいじだ。 ## Mermaid 次にMermaid。テキストで図を書くためのツールだ。昔はこの手のものだとPlantUMLがよく使われていた印象がある。PlantUMLも便利なのだが、Java環境やサーバー側のレンダリングをどうするか、みたいな話が少し出てくる。 MermaidはJavaScriptでレンダリングできるので、ブログやドキュメントに埋め込みやすい。GitHubのMarkdownでも使える。テキストで書いた図が、そのままWeb上で図として表示される。ポータビリティが高い。 ただ、Mermaidのブロックをそのままレンダリングすると図になるので、記事上ではソースコードが見えなくなる。なので、ここではまずソースを通常のコードブロックとして載せ、その下に同じ内容をMermaidとしてレンダリングした図を置く。 たとえば、ブログ記事を書く流れをフローチャートにするとこうなる。まずソースはこれ。 ```text flowchart TD A[ニュースを見る] --> B[なんか思う] B --> C[Slackにメモする] C --> D[Codexに投げる] D --> E[下書きができる] E --> F{読み返す} F -->|まあよし| G[公開候補] F -->|なんか違う| C ``` これをMermaidとしてレンダリングすると、こういう図になる。 ```mermaid flowchart TD A[ニュースを見る] --> B[なんか思う] B --> C[Slackにメモする] C --> D[Codexに投げる] D --> E[下書きができる] E --> F{読み返す} F -->|まあよし| G[公開候補] F -->|なんか違う| C ``` こういう図は技術ブログだけのものではない。むしろ、普通のエッセイでも使える。自分の思考の流れを描く。話がどこで分岐したのかを描く。人間がどのように面倒なことを後回しにするのかを描く。だいたい後回しにする。 状態遷移図も書ける。たとえば、下書き記事の状態遷移はこんな感じかもしれない。ソースはこう。 ```text stateDiagram-v2 [*] --> memo memo --> draft: 話の方向が見える draft --> revise: 読み返して違和感 revise --> draft: 直す draft --> published: まあこれでいいか published --> revise: 公開後に誤字を見つける revise --> published: そっと直す ``` レンダリング結果はこうなる。 ```mermaid stateDiagram-v2 [*] --> memo memo --> draft: 話の方向が見える draft --> revise: 読み返して違和感 revise --> draft: 直す draft --> published: まあこれでいいか published --> revise: 公開後に誤字を見つける revise --> published: そっと直す ``` 公開後に誤字を見つける、という状態遷移は本当は存在してほしくない。しかし存在する。現実は仕様書に従わない。 シーケンス図も書ける。技術記事ならAPIの呼び出し順序などを書くのに使うが、別に人間同士のやり取りを書いてもいい。 ```text sequenceDiagram participant Me as わたし participant Slack as Slack participant Codex as Codex participant CMS as ampless CMS Me->>Slack: ネタを雑に書く Me->>Codex: これをエッセイにして Codex->>Slack: スレッドを読む Codex->>CMS: draft投稿 CMS-->>Me: 編集ページ Me->>CMS: ちょっと直す ``` これもMermaidで描画するとこうなる。 ```mermaid sequenceDiagram participant Me as わたし participant Slack as Slack participant Codex as Codex participant CMS as ampless CMS Me->>Slack: ネタを雑に書く Me->>Codex: これをエッセイにして Codex->>Slack: スレッドを読む Codex->>CMS: draft投稿 CMS-->>Me: 編集ページ Me->>CMS: ちょっと直す ``` こうして見ると、かなりそのままだ。というか、最近のishinao.netの記事作成フローがだいたいこれである。図にすると急に業務っぽく見える。業務ではない。趣味である。 ## エッセイにも図は使える Mermaidのような作図ツールは、技術系ブログのものだと思われがちだ。実際、システム構成図、処理フロー、状態遷移、シーケンス図などを書くにはとても向いている。 でも、技術に限らなくても図で表せる話は多い。たとえば包含関係。ある概念がどこに含まれているのか。似ているが同じではないものが、どのくらい重なっているのか。言葉だけで説明すると面倒なことが、図なら一瞬で伝わることがある。 たとえば、こういう雑な心象図もテキストで書ける。 ```text flowchart TB subgraph Internet[インターネット] SNS[SNS] News[ニュースサイト] Blog[個人ブログ] end subgraph Reading[読んだことにする箱] SNS News end Blog --> Thought[あとでちゃんと考える] Thought --> Essay[エッセイになることもある] ``` レンダリングするとこう。 ```mermaid flowchart TB subgraph Internet[インターネット] SNS[SNS] News[ニュースサイト] Blog[個人ブログ] end subgraph Reading[読んだことにする箱] SNS News end Blog --> Thought[あとでちゃんと考える] Thought --> Essay[エッセイになることもある] ``` 今の図は、たぶん構文的には包含関係というより雑な心象図である。だが、そういう雑な図でもいい。むしろエッセイでは、厳密な設計図よりも、考えの置き場所を見せる図のほうが使いやすいかもしれない。 文章だけで書いていると、自分でも話の構造を見失うことがある。Aの話をしていたはずなのに、Bに寄り道し、Cで腹を立て、Dで急に昔話を始める。個人ブログではそれも味ではある。味ではあるが、読み返す自分が迷子になることもある。 そこで図である。 図を書くと、話の流れを自分でも見直せる。読者にも伝えやすい。あと、記事の見た目にちょっと変化が出る。これも地味に大きい。文章がずっと続くと、書いている側も読んでいる側もだんだん山道を歩いている気分になる。途中に図があると、少し休憩所っぽい。 ## AI作画とMermaid 最近はAI作画もかなり実用的になった。図表っぽい画像を作ることもできるし、説明用のイラストやサムネイルのようなものなら、AIに頼んだほうが見栄えのいいものが出てくることもある。 ただ、AI作画は少し重い。プロンプトを考える。生成を待つ。出てきた画像を見て、矢印の向きが違う、ラベルが変、余計なものが入っている、などと気づく。そこからまたプロンプトを直して作り直す。ちょっと一文字変えたいだけなのに、画像全体を作り直す感じになる。 リッチな表現が欲しいなら、それでもいい。雰囲気のある図、見栄えのする絵、視覚的に楽しいものを作りたいならAI作画は強い。 でも、単に脳内の構造イメージを図示したいだけなら、そこまでいらない。AからBへ流れる。BはCとDに分岐する。ここで判断が入り、失敗したら戻る。そういう骨組みを見せたいだけなら、Mermaidのほうがずっと軽い。 ノード名を変えたければ一行直せばいい。分岐を足したければ一行足せばいい。文章を書き換える感覚で図を書き換えられる。リッチさではAI画像に負けるが、思考の骨組みを置く道具としては、Mermaidくらいの素っ気なさがちょうどいい。 ## テキストで図を書く意味 画像として図を作ることもできる。FigmaでもKeynoteでも、なんなら手書きでもいい。だが、テキストで図を書くことには別の便利さがある。 まず、修正しやすい。線を一本動かすために画像編集ソフトを開かなくていい。テキストを一行直せばいい。バージョン管理にも向いている。差分も見える。AIに修正を頼みやすい。 さらに、本文と同じ場所に置ける。図だけ別ファイルにして、どこに保存したか忘れる、みたいなことが減る。図も文章の一部として扱える。これはブログにとってかなり相性がいい。あ、相性がいいという言葉は便利すぎるので気をつけたい。便利すぎる言葉はだいたい雑に使われる。 ともかく、MermaidとSyntax Highlightが入ったことで、amplessで書ける記事の幅は少し広がった。技術記事はもちろん書きやすくなる。コードや処理フローをそのまま見せられるからだ。 そして、普通のエッセイでも使える。考えの流れ、話の分岐、概念の重なり、面倒な作業の遷移、やる気が出てから失われるまでの状態遷移。そういうものを図にしてもいい。 文章を書く道具に、図を書く道具が混ざる。 それだけで、ちょっと楽しい。