diagram-designとは？Claude Code向け図表生成ガイド

症状：Claude Codeに図表を頼むと、内容は合っていても汎用的な箱と矢印になり、ブログへそのまま掲載できません。
最短解決策：diagram-designをClaude Codeのスキルとして導入し、自然言語から自己完結型HTMLとインラインSVGを生成してください。ただし、設計内容の正しさは必ず人が確認します。

このガイドが役立つ人

Claude Codeを使ってブログ、README、設計書のアーキテクチャ図を作っている開発者向けです。図表の色やフォントを記事ごとに揃えたい技術コンテンツチームにも適しています。

また、短期の執筆作業だけローカルMacで行うか、常時稼働するリモートMac環境を用意するか判断したい責任者にも、導入条件と受け入れ基準を整理しています。

Last updated

2026年8月14日。公式リポジトリのREADME、スキル構成、インストール手順、エクスポート関連ドキュメントを確認して更新しています。diagram-designの機能や導入方法は変更される可能性があるため、利用前に公式リポジトリの最新状態も確認してください。 (github.com)

diagram-designは何をするツールですか？

diagram-designは、独立したオンライン作図サービスではありません。Claude Codeなどのエージェントに読み込ませるスキルで、文章による要件や既存の図表ソースをもとに、技術向けの図表ファイルを生成します。

公式リポジトリでは、アーキテクチャ図、フローチャート、シーケンス図、状態図、ER図、タイムライン、スイムレーン、2軸マトリクス、データフロー図などが案内されています。現在のREADMEには27種類のビジュアルタイプが記載されています。 (github.com)

主な出力は、外部ライブラリに依存しないHTMLです。図形部分はインラインSVGとして保持されるため、Webページへ組み込みやすく、SVGだけを取り出して別の編集環境やスライド制作へ渡すこともできます。 (github.com)

一般的な画像生成ツールとの違いは、画面の見栄えだけでなく、ノード、関係、順序、階層を図表の構造として扱う点です。Mermaidのコード生成器のように記法を書くことだけが目的でもなく、自由なホワイトボードのように共同編集するサービスでもありません。

注意：図表の構造が整っていても、モデルが推測したサービス名、依存関係、通信経路が実システムと一致するとは限りません。設計レビュー前の資料では、生成物を事実の証拠として扱わないでください。

Claude Codeでの導入と操作

公式READMEでは、Claude Codeのプラグインとして次の流れが示されています。

/plugin marketplace add cathrynlavery/diagram-design
/plugin install diagram-design@diagram-design

既存のスキルディレクトリを直接管理したい場合は、リポジトリ内の skills/diagram-design/ をローカルへ配置する方法もあります。公式説明では、スタイルガイドを継続的に編集したい場合、ローカルのチェックアウトとシンボリックリンクを使う構成が案内されています。 (github.com)

導入後は、たとえば次のように依頼します。

このアプリの構成図を作成してください。
フロントエンド、APIサーバー、認証サービス、データベース、
キャッシュの関係を示し、ブログ掲載用のHTMLとして保存してください。

毎回、正しい種類が自動選択されるとは限りません。用途を明示した方が安定します。

• 時系列の通信を示す：シーケンス図
• 条件分岐を示す：フローチャート
• 状態の変化を示す：状態図
• 複数の処理担当を示す：スイムレーン
• データの流れを示す：データフロー図
• 構成要素と接続を示す：アーキテクチャ図

Claude Codeのスキルは、ローカルファイルを読み書きする権限に依存します。プロジェクト内のREADME、設定ファイル、既存のMermaidソースを参照させる場合は、対象ディレクトリと機密情報の範囲を先に決めてください。スキルを追加しただけで、すべての依頼が自動的に正確な図表へ変換されるわけではありません。Claude Codeのスキルがどのように読み込まれるかは、公式ドキュメントでも確認できます。 (docs.anthropic.com)

どの図表をどの担当者が使うべきですか？

開発者向け：構成と処理経路を短時間で整理する

技術者が最初に使いやすいのは、アーキテクチャ図、シーケンス図、状態図、データフロー図です。たとえば、認証処理の説明では、ブラウザーからAPI、認証処理、データベースへ進む経路を文章で指定し、失敗時の分岐も含めて生成できます。

ただし、図表が読みやすいことと、設計が正しいことは別です。実際のコード、設定ファイル、デプロイ定義と照合し、存在しない接続や省略された障害経路を確認してください。

技術ライター向け：HTMLとSVGを記事の構造に合わせる

ブログやREADMEでは、画像ファイルだけでなく、自己完結型HTMLが便利です。ページへ直接配置しやすく、生成物をプロジェクト内で管理できます。SVG図表は拡大縮小に強い一方、文字量が多いとスマートフォンで読みにくくなります。

記事へ掲載する前に、次の点を調整してください。

• ノード内の文章を短くする
• 重要な経路だけをアクセントカラーで示す
• 横幅の広い図はモバイル表示で確認する
• 図表の前後に本文による要約を置く
• SVGにタイトルと説明を付ける

インラインSVGでは、title、desc、aria-labelledbyを使って図表の意味を補足できます。MDNも、短い名称にはtitle、より長い説明にはdescを使う方法を説明しています。 (developer.mozilla.org)

デザイン・ブランド担当者向け：統一感と承認を分ける

diagram-designにはスタイルガイドがあり、色、背景、文字の役割を調整できます。公式説明では、Webサイトから色やフォントの候補を抽出し、図表のトークンへ反映するオンボーディング手順が示されています。 (github.com)

これは記事間の視覚統一には有効ですが、ブランド審査の代わりにはなりません。ブランドフォントの利用許諾、代替フォントの表示差、印刷時の色、背景と文字のコントラストは人が確認してください。本文の小さな文字では、WCAGの通常テキストに対する4.5:1以上のコントラスト基準も確認材料になります。 (w3.org)

生成物は編集できますか？

「編集できる」の意味を分けて考える必要があります。

HTMLを直接編集すれば、見出し、ノード、色、SVG要素を変更できます。SVGだけを取り出す運用も可能ですが、複雑なレイアウトをデザインソフトで自由に動かす専用ファイルとは異なります。公式のエクスポート手順では、SVGは図表部分を抽出し、PNGはPlaywrightとChromiumを使って画像化する流れが示されています。 (github.com)

したがって、編集性は次のように評価すると判断しやすくなります。

• 文章や色を直す：HTML・SVGの直接編集に向いています
• Web記事へ埋め込む：自己完結型HTMLが向いています
• スライドへ貼る：SVGまたはPNGへ書き出します
• 複数人がキャンバス上で同時編集する：別の共同作図ツールを検討します
• 厳密な設計記法を長期管理する：Mermaid、draw.ioなどの元ソースも保存します

つまり、diagram-designは「最終図を一度作って終わり」にするより、元データと生成ファイルを分けて管理する方が安全です。

第一歩：小さな図表で導入を検証する

いきなりチーム全体へ配布せず、1つのREADMEか記事で試してください。

1. 対象リポジトリを複製し、図表専用の作業ブランチを作成します。
2. 図表の目的、読者、掲載場所、必要な詳細度を文章で指定します。
3. Claude Codeへ図表の種類と出力形式を明示します。
4. 生成されたHTMLをローカルのブラウザーで開き、文字の重なりと横幅を確認します。
5. SVGを書き出し、記事、スライド、画像ビューアーで表示を比較します。
6. ドメイン担当者がノード名、接続、順序、例外経路をレビューします。
7. 元のプロンプト、HTML、SVG、修正差分を同じ変更履歴へ保存します。
8. 承認済みのスタイルガイドだけをチーム標準として再利用します。

GitHubのプルリクエストでは、変更されたファイルやコミットを確認し、コメントや承認を残せます。図表の変更もコードと同じようにレビュー対象へ含めると、意図しない依存関係の追加を追跡しやすくなります。 (docs.github.com)

導入前の受け入れチェック

• [ ] 生成対象の図表タイプを指定できる
• [ ] HTMLをローカルで単独表示できる
• [ ] SVG出力を記事とスライドで確認した
• [ ] スマートフォン幅で文字を読める
• [ ] titleやdescなどの説明を確認した
• [ ] 実システムとの照合担当者を決めた
• [ ] スタイルガイドとフォントの利用条件を確認した
• [ ] HTML、SVG、元プロンプトを変更履歴へ保存した
• [ ] ローカルファイルの読み書き権限を限定した

どの実行環境を選ぶべきですか？

図表を数枚作るだけなら、現在使っているMacへ導入するのが最も簡単です。ローカルファイルをすぐ確認でき、ブラウザーでHTMLを開きながら修正できます。ただし、個人の端末設定に依存しやすく、チームで同じ環境を再現する場合は準備項目が増えます。

常時稼働するリモートMacは、複数人が同じ作業環境を使う場合や、夜間に大量の図表を生成する場合に向いています。一方で、アクセス権、秘密情報、ブラウザー実行環境、ファイル回収、セッション管理を設計しなければなりません。

Kvmjetのインフラ構成と利用環境の説明を確認すると、常用環境と一時環境の違いを比較しやすくなります。長期の重い処理や物理デバイス接続が必要な場合は、自前のMacの方が適することもあります。

現在の方法からMac環境へ切り替えるべき場面

手元のWindowsやLinux環境だけで続ける方法は、費用を増やさず始められる反面、Claude Codeの設定、ブラウザー描画、Playwright、フォント、ファイル権限が担当者ごとにばらつきやすい点が弱点です。共有サーバーだけに寄せる場合も、GUI確認がしにくい、セッション切断で書き出しに失敗する、生成物の回収場所が曖昧になるという問題が起こります。

diagram-designを継続的に使うなら、図表生成とブラウザー確認を同じMac環境へ寄せることで、導入手順、フォント、書き出し方法を揃えやすくなります。ただし、短期の検証だけならローカルMacで十分です。複数人が同じClaude Code環境を使う、納期中だけ作業端末を増やす、生成ファイルを分離して管理する、といった条件なら、KvmjetのMac環境に関する相談窓口で必要期間と運用条件を確認してください。レンタルが常に最適とは限らないため、作業期間、同時利用者、機密性、ファイル回収方法を先に決めるのが安全です。