Claude Codeの図解にdiagram-designが選ばれる理由

Claude Code や Codex で図解を生成しようとしたとき、Mermaid の自動レイアウトが微妙にずれていたり、色使いが「AI が生成した見た目」から抜け出せなかったりして、結局 Figma を開き直す。そんな経験を持つエンジニア・テクニカルライター・PM は少なくないはずです。

一方で、記事や社内ドキュメントで図解を使いたい場面は増え続けています。アーキテクチャ、シーケンス、ユーザージャーニー、比較表——テキストだけでは伝わりにくい構造を、意思決定のスピードを落とさずに図に落とし込みたい。

そこで注目されているのが、cathrynlavery/diagram-design という OSS です。Claude Code / Codex / Pi 向けの Agent Skill / Plugin として提供され、38 種類の編集品質ダイアグラムを自然言語プロンプトから生成できます。GitHub リポジトリは 2026 年 8 月 21 日時点で 24,955 スター・MIT ライセンスと、注目度と使いやすさの両方を備えています。

ただし「Claude Code 向けの図解 OSS」というカテゴリには、Mermaid や mingrammer/diagrams など先行するツールも複数存在します。初見のエンジニアが判断すべきは、これらとの違いを踏まえた上で 自プロジェクトに採用すべきかどうか、そして どの場面で使い分けるか という選定軸です。

本記事では、公式リポジトリ・README・公式ギャラリーのドキュメントに基づき、diagram-design の機能・設計思想・類似 OSS との違い・メンテナンス状況を整理します。実際にインストールして検証した内容ではなく、公開情報からの整理に限定していますので、採用判断の一次スクリーニングとしてお役立てください。

diagram-design とは

cathrynlavery/diagram-design は、Claude Code / Codex / Factory Droid / Pi といったコーディングエージェント向けに提供される Agent Skill / Plugin 形式の OSS です。自然言語プロンプトで指示すると、38 種類の「編集品質」ダイアグラムを HTML + SVG の自己完結ファイルとして出力します（GitHub: cathrynlavery/diagram-design）。

リポジトリの説明文には「38 editorial diagram types for Claude Code, Codex, and Pi. Self-contained HTML + SVG. No shadows. No Mermaid slop.」と記されています。「No Mermaid slop（Mermaid っぽい雑な見た目を出さない）」というキーワードが、このプロジェクトが解決しようとしている課題を端的に示しています。

想定されるユーザーは、記事・社内ドキュメント・プロダクトデッキを継続的に作成するライター、エンジニア、PM です。Figma でゼロから作図する時間は取れないが、Mermaid や draw.io の標準出力そのままでは編集品質を担保できない、という中間的なニーズに応える位置づけです。

リポジトリのメタ情報は下記のとおりです（数値は 2026 年 8 月 21 日時点の GitHub API 取得値）。

アーカイブ済みでもフォークでもない本家リポジトリで、公開状態も public として維持されています。ライセンスは商用利用にも扱いやすい MIT が付与されており、公式ドキュメント上は導入時に法的リスクを気にせず評価できる状態です。

なぜ「編集品質の図解生成」が求められるのか

Mermaid や draw.io は、フローチャート・シーケンス図・ER 図といった標準的な図を短時間で生成できる点で優れています。しかし、公開する記事・意思決定資料・営業提案書のように「見た目の品質」が読み手の印象に直結する場面では、いくつかの共通する課題が指摘されてきました。

• レイアウトが自動計算のため、ノードやラベルの配置に美的整合性を持たせにくい
• デフォルトの配色が「AI が生成した見た目」に寄りやすく、ブランドトーンと合わない
• 影・グラデーションなど装飾が付きすぎ、コンテンツの主役が伝わりにくい
• 図と本文のタイポグラフィが分断され、資料全体としての一体感が損なわれる

diagram-design の README 冒頭では、この状況を「Figma で 30 分色選びをするか、図解を諦めるか」というライター・エンジニア・PM の二者択一として提示しています（GitHub: cathrynlavery/diagram-design）。この二者択一を回避するために、後述する 4px グリッド・1色アクセント・No shadows といった「編集品質の型」を Skill 側にあらかじめ組み込む設計思想が採用されています。

つまり diagram-design は「自動生成の速度」と「編集品質のデザイン制約」の両立を狙ったプロジェクトです。この立ち位置を押さえておくと、後段の類似 OSS 比較（Mermaid・mingrammer/diagrams など）で棲み分けが判断しやすくなります。

diagram-design が提供する 38 タイプの図解カテゴリ

diagram-design は、リポジトリの説明文に記載のとおり 38 editorial diagram types を提供します。README 本文の一部や公式ギャラリーには 39 タイプや「50+」のリスト表示もありますが、GitHub リポジトリの description が canonical な数値のため、本記事では 38 タイプを基準とします。図解タイプは、大きく次の 8 カテゴリに整理できます。

網羅性の観点で興味深いのは、フローチャートやシーケンスといった「開発ドキュメント寄り」の図に加え、Quadrant（優先度マトリクス）・Wardley map（戦略マップ）・User journey（ユーザージャーニー）・Sankey（フロー配分）のような「編集・意思決定寄り」の図が同じ Skill から生成できる点です。これにより、技術記事・プロダクト仕様・企画資料・営業デッキといった横断的な用途を単一のツールでカバーできます。

各タイプがどのようなアウトプットになるのかは、公式ギャラリーで実物の SVG を確認できます（Diagram Design · gallery）。ギャラリー側では Minimal light / Minimal dark / Full editorial の 3 テーマを切り替えて表示でき、自プロジェクトのトーンに合わせられるかを事前に判断しやすくなっています。

自プロジェクトで必要な図解タイプが揃っているかを確認する際は、まず「用途」から逆引きするのが実用的です。たとえばアーキテクチャ紹介記事なら Architecture / Sequence / ER が候補、プロダクト戦略記事なら Quadrant / Wardley map / User journey が候補、といった具合に、記事テーマとカテゴリを対応づけていくと過不足が可視化できます。

60 秒ブランド適応と「No shadows / No Mermaid slop」の設計思想

diagram-design を単なる「図解ライブラリ」と区別する要素が、ブランド適応と編集品質のデザイン制約です。README には、次の 3 点が特徴として整理されています。

60 秒でブランドカラー・フォントを自動抽出する仕組み

README のオンボーディング説明では、ユーザーサイトから色・フォントを 60 秒で抽出し、以降生成する全図解に反映する挙動が説明されています。個々の図解ごとに配色を指定しなくても、サイト全体で統一されたビジュアルが得られる設計です（GitHub: cathrynlavery/diagram-design）。

複数の記事・スライドを継続的に生成する用途では、この「一度設定すればブランド適用が続く」性質が、Mermaid 等でカラーコードを毎回指定する運用と比べて工数削減につながります。

デザイン原則（4px grid / 1px hairlines / 1色アクセント / No shadows / No Mermaid slop）

diagram-design は以下のデザイン原則を Skill 側で強制する設計を採用しています。

タイポグラフィも同様に整理されており、タイトルやイタリック用途に Instrument Serif、ノード名に Geist Sans、技術ラベルに Geist Mono を採用する構成です。ユーザーが個別に選定しなくても、編集品質を担保するデフォルトが最初から適用されます。

出力形式（HTML + SVG の自己完結型、外部依存なし）

生成物は HTML + SVG の自己完結型ファイルで、ビルドステップ・追加の JavaScript・外部画像は不要です。ブラウザで直接開けば描画され、CMS へのアップロードやスライドへの貼り付けも扱いやすくなります。PNG 出力を行う場合のみ、任意で Playwright（pip install playwright && playwright install chromium）を追加する構成です。

CI 統合の観点では、README で python3 scripts/lint-skin.py --all --baseline・python3 scripts/verify-semantic-motion.py・python3 scripts/verify-drawio-import.py といった検証スクリプトの存在が案内されています。デザイン制約が守られているか、モーションや draw.io インポートが期待どおり動作するかを、リポジトリ側の仕組みで検査できる構成です。

対応環境と導入方法（Claude Code / Codex / Factory Droid / Pi）

diagram-design は複数のコーディングエージェントに対応する Skill / Plugin として配布されています。README「Install」セクションに記載されているインストールコマンドは以下のとおりです。

# Claude Code
/plugin marketplace add cathrynlavery/diagram-design
/plugin install diagram-design@diagram-design

# Codex
codex plugin marketplace add cathrynlavery/diagram-design
codex plugin add diagram-design@diagram-design

# Pi
pi install https://github.com/cathrynlavery/diagram-design

（出典: GitHub: cathrynlavery/diagram-design – Install）

Factory Droid・Claude Cowork 経由でも Marketplace からインストールできる旨が README で案内されています。既にいずれかのエージェントを常用している開発チームであれば、追加ツールを増やさずに図解生成の Skill を組み込める構成です。

使い方は、対応エージェントに対して自然言語でプロンプトを渡す形式です。README「Quickstart」では、次のような指示例が示されています。

Make me an architecture diagram of my app: frontend, backend, database, Redis cache.

I need a quadrant showing Q2 projects by impact vs effort.

Give me a sequence of a bearer call with token refresh on 401.

（出典: GitHub: cathrynlavery/diagram-design – README）

上記のように「作りたい図の目的と要素」を自然言語で書けば、対応するテンプレートが選択され HTML + SVG のファイルが生成される流れです。テンプレートには最小構成の template.html、編集用途の template-full.html、アニメーション付きの template-motion.html の 3 種が用意されています。

Pi 環境では、既存資産の取り込みや個別スライドの書き出しに対応した専用コマンドも整備されています。

/diagram-design:import-drawio platform.drawio --size=slide-16x9 --detail=simplified
/diagram-design:import-mermaid README.md --diagram=all
/export-diagram path/to/diagram.html --svg-only

（出典: GitHub: cathrynlavery/diagram-design – README）

import-mermaid があることは重要な設計判断です。既存の README や記事に埋め込まれた Mermaid ソースを diagram-design の形式に一括変換できるため、Mermaid を捨てて置き換えるのではなく 後段のスタイリング層として重ねる運用が可能になります。draw.io からのインポートも同様に、既存のアーキテクチャ図資産を活かしたまま編集品質を引き上げる導線として機能します。

類似 OSS との比較（Mermaid・mingrammer/diagrams との違い）

diagram-design を採用すべきかを判断する上で欠かせないのが、類似 OSS との使い分けです。用途領域が一部重なる代表的なプロジェクトとして、mermaid-js/mermaid と mingrammer/diagrams を取り上げ、比較軸を整理します。なお比較表内の mermaid-js/mermaid および mingrammer/diagrams のスター数は、各リポジトリの GitHub 公開情報（2026 年 8 月時点）に基づく参考値です（mermaid-js/mermaid / mingrammer/diagrams）。

※ diagram-design のスター数は 2026 年 8 月 21 日時点の GitHub API 取得値。mermaid-js/mermaid および mingrammer/diagrams のスター数は各リポジトリの GitHub 公開情報（2026 年 8 月時点）の参考値であり、日次で変動します。

Mermaid との違い（テキスト DSL・GitHub 内蔵レンダリング vs 編集品質・Agent Skill）

Mermaid は「テキストで書けば GitHub や Notion がそのままレンダリングしてくれる」という運用の軽さが最大の強みです。一方で、レイアウトは自動計算のみで、diagram-design が組み込んでいる「4px グリッド・1色アクセント・No shadows」といった編集品質のデザイン制約は持ちません。

したがって、次のような使い分けが実務的です。

• README・PR ディスクリプション・Issue のような開発内向けドキュメント → Mermaid（Markdown インライン描画で十分）
• 記事・営業デッキ・意思決定資料のような編集品質が求められる成果物 → diagram-design（型化されたデザイン制約が効く）
• 既存の Mermaid 資産をそのまま磨きたい場合 → /diagram-design:import-mermaid で diagram-design 側に取り込む

mingrammer/diagrams との違い（クラウドアーキテクチャ特化 vs 汎用編集品質図解）

mingrammer/diagrams は Python の DSL でクラウドアーキテクチャ図を宣言する OSS で、AWS / GCP / Azure などの公式アイコンを扱える点で強みがあります。ただし対象領域はクラウド構成図に特化しており、Quadrant / Sankey / Wardley map など編集記事で用いる非アーキテクチャ図は対象外です。

したがって次のような使い分けになります。

• クラウドアーキテクチャ図（公式アイコンを厳密に使いたい場合） → mingrammer/diagrams
• アーキテクチャ以外の 30+ 種の編集向け図解を横断で扱いたい場合 → diagram-design
• Python パイプラインに図生成を組み込みたい場合 → mingrammer/diagrams
• コーディングエージェント（Claude Code / Codex / Pi 等）の自然言語ワークフローで図を生成したい場合 → diagram-design

このように、いずれの類似 OSS も「置き換え関係」ではなく「重なる部分もある補完関係」として捉えるのが実態に近い構図です。既存の Mermaid・mingrammer/diagrams 運用を否定せず、diagram-design を編集品質レイヤーとして追加する形が、初期導入時のリスクを抑えつつ効果を検証しやすい進め方といえます。

採用判断のポイント（メンテナンス性・ライセンス・不足領域）

初見のエンジニアが「本番導入して問題ないか」を判断する際に確認すべきポイントを、公開情報から整理します。

リポジトリの健全性

GitHub API から取得した数値ベースでの健全性は次のとおりです（diagram-design の数値は 2026 年 8 月 21 日時点の GitHub API 取得値、比較対象の Mermaid・mingrammer/diagrams の数値は 2026 年 8 月時点の GitHub 公開情報に基づく参考値）。

• スター数: 24,955 — 類似 OSS（Mermaid 約 89K、mingrammer/diagrams 約 42K）と比べれば小さいが、公開から数ヶ月で 25K 目前に到達しており勢いがある
• フォーク数: 1,521 — 派生開発・カスタマイズを行っているユーザーが一定数存在
• 最終更新（pushed_at）: 2026-08-21 — 本記事時点で直近の更新が続いている
• 公開状態: archived=false / fork=false — 本家リポジトリとして継続開発中
• ライセンス: MIT — 商用利用・改変・再配布に対する制約が緩い

長期メンテナンスの保証は OSS の性質上どのプロジェクトでもできませんが、上記の指標からは「導入検討時に廃止リスクを高く見積もる材料は現時点で見当たらない」水準にあります。

ライセンスと商用利用

リポジトリのライセンスは MIT で、LICENSE ファイルおよび THIRD_PARTY_LICENSES.md がリポジトリ直下に同梱されています（LICENSE - cathrynlavery/diagram-design）。商用サービスの記事・営業資料・社内ドキュメントに生成物を組み込む用途でも、著作権表示を含めれば取り扱いやすいライセンスです。

第三者ライセンスも同梱ファイルで管理されているため、依存関係の透明性という観点でも確認しやすい構成です。

現時点の制約・不足領域

一方で、採用前に把握しておきたい制約・不足領域もあります。公開情報からわかる範囲では次のとおりです。

• PNG 出力を行う場合は Playwright（pip install playwright && playwright install chromium）の追加インストールが必要
• README で想定されている図のサイズは横長スライド系（例: --size=slide-16x9）が中心で、縦長のドキュメント埋め込み特化ではない
• 図解タイプ数の記載に揺れがあり（description 38、README 本文の一部 39、公式ギャラリー UI 50+）、最新の canonical 数値としては description の 38 を採用する必要がある
• 日本語圏での指名検索需要は現時点では英語圏より薄く、日本語のトラブルシューティング記事の蓄積は今後増えていく段階

これらは致命的な問題ではなく、社内向けの「導入判断チェック項目」として明示的に押さえておけば運用上の混乱を避けられる範囲の制約です。

まとめと導入判断のためのチェックリスト

cathrynlavery/diagram-design は、Claude Code / Codex / Factory Droid / Pi 向けの Agent Skill として 38 種類の編集品質ダイアグラムを HTML + SVG の自己完結ファイルとして生成する OSS です。60 秒で完了するブランド適応、4px grid / 1色アクセント / No shadows といったデザイン制約の型化、/diagram-design:import-mermaid による既存 Mermaid 資産の取り込みまでを備え、Mermaid や mingrammer/diagrams と競合するのではなく 編集品質レイヤーとして重ねる設計が特徴です。

自プロジェクトへの採用を判断する際は、次のチェックリストで整理すると意思決定がスムーズです。

• Claude Code / Codex / Factory Droid / Pi のいずれかを日常的に使っているか
• 記事・社内ドキュメント・営業デッキなど「編集品質」が読み手の印象に直結する成果物を継続的に生成しているか
• Mermaid や draw.io の標準出力では見た目の統一感が担保できずに困っているか
• ブランドカラー・フォントを図解に反映する必要があり、都度手動指定する運用を避けたいか
• 生成物を HTML + SVG の自己完結ファイルとして扱える運用体制（CMS 貼り付け・レビュー環境等）を整えられるか
• MIT ライセンスと Playwright（PNG 出力時のみ）の追加要件を許容できるか

上記のうち複数に当てはまるプロジェクトであれば、まず 1〜2 本の記事や社内資料で試験的に導入し、既存の Mermaid・draw.io 資産を import-mermaid / import-drawio で取り込みながら効果を検証する進め方が現実的です。より詳細な図解一覧やテーマ切替の実物は、公式ギャラリー（Diagram Design · gallery）で確認できます。

開発体制のご相談

図解を含む記事・社内ドキュメント・プロダクト資料の制作体制、あるいは Claude Code / Codex 等の AI 開発エージェントを組み込んだ開発フローの設計にご関心のある方は、お問い合わせフォーム からご相談いただけます。要件整理の段階からのご相談も承っております。

フリーランス案件をお探しの方へ

Claude Code や Codex を活用した開発案件・技術検証案件など、フリーランスエンジニア向けの案件情報は Workee（フリーランス向け） で公開しています。ご自身のスキルセットに合う案件を探されている方はご覧ください。