Obsidianでノートを取っているとき、文章で書いた内容を図にしたくなる瞬間がありますよね。フローチャートにしたい、マインドマップに整理したい、でも図のJSON構造を手で書くのは面倒だし、Mermaidの構文エラーに何度も引っかかる。そんな摩擦を、Claude Codeのプロンプトベースの仕組みで解消しようとしたのが、このリポジトリです。紹介と設計の両面から見ていきます。
どんなSkill集か
AxtonLiu氏が公開したこのリポジトリは、Claude Code向けの「Skill」と呼ばれるマークダウンファイル群です。Skillとは、MCPサーバーのような複雑なセットアップを必要とせず、Claude Codeがオンデマンドで読み込むプロンプト定義のこと。このSkill集には3種類が同梱されています。Excalidraw図形ジェネレーター、Mermaid可視化ツール、そしてObsidian Canvas作成ツールです。
ユーザーは「Create an Excalidraw flowchart showing the CI/CD pipeline」のような自然言語の指示を送るだけで、Obsidianで直接開けるファイルが生成されます。対応する図の種類はフローチャート・マインドマップ・タイムライン・シーケンス図など幅広く、日本語（CJK文字）のテキストも扱えます。スター数が3,352を超えていることからも、図解を自動化したいと考えているObsidianユーザーの数が相当いることが伝わってきます。
設計でここが上手い
Skillファイルの単体完結
各Skillは SKILL.md という単一ファイルで定義されており、それ自体がClaudeへの指示書になっています。MCPのようにデーモンを立てたり、環境変数を設定したりする手順がありません。~/.claude/skills/ に置くだけで動く。導入コストの低さが設計の出発点になっているのは、ドキュメントの随所から伝わります。
トリガーワードによるオンデマンド起動
Skillは「呼ばれたときだけ」ロードされる構造になっています。たとえばExcalidrawのSkillは「Excalidraw」「diagram」「画图」などのキーワードが入力に含まれるときに発火します。常駐するわけではないので、図の生成が不要な会話でコンテキストウィンドウを圧迫しません。この設計はトークン消費の観点でも合理的で、実際に「Skills are simple markdown files that Claude loads on demand」と明記されています。
出力モードの段階的分岐
Excalidrawの例が分かりやすいのですが、「Obsidianで開く用」「excalidraw.comで編集する用」「アニメーション出力用」と3つの出力モードを持っています。同じ図でも用途によって出力先が変わるという設計は、後から「やっぱり共有したい」「動かしたい」という要求変化を想定したものです。トリガーワードで切り替えられるので、ユーザーは余分なオプション設定をする必要がありません。
構文エラー予防の組み込み
MermaidのSkillには「built-in syntax error prevention」が組み込まれています。リスト表記の競合、サブグラフの命名衝突、特殊文字の扱いといった、Mermaidを手書きするときに起こりがちな落とし穴をSkill定義の中であらかじめ回避するよう設計されています。これは利用者が何度もエラーを経験して初めて気づく知識をSkillに埋め込んだということで、実運用の経験が設計に還元されているといえます。
references/フォルダによるスキーマ参照
各SkillのディレクトリにはJSON Canvas仕様やExcalidrawのスキーマを入れた references/ フォルダが存在します。Claude Codeが出力を生成するとき、このスキーマを参照しながら有効なファイルを作れるようにしている構造です。プロンプトだけに頼るのではなく、仕様書を引数として渡す発想は、出力の安定性を高めるうえで実用的なアプローチです。
こういう人に向くかも
Obsidianを日常的なナレッジベースとして使っていて、かつClaude Codeも手元に入っている人が最も恩恵を受けやすいでしょう。特に、会議のメモや記事の要点を図に落としたいケースや、アーキテクチャ設計を素早く可視化したい開発者の場面と相性がよいです。
一方、ObsidianもClaude Codeも使っていない人は、前提が二重に必要になります。どちらかひとつしか持っていない場合は、まずツールの準備から始める必要があります。また、READMEに「Status: Experimental」と明記されており、AxtonLiu氏自身が「デモ用プロトタイプであり、すべての入力規模やエッジケースを網羅していない」と書いています。プロダクション環境で安定稼働させたい用途よりも、日常の思考整理や試作フェーズで使うほうが実態に合うかもしれません。
設計の良し悪しをどこで見るか
機能の単一性と範囲のバランス
このリポジトリは「図を生成する」という機能に絞っていますが、Excalidraw・Mermaid・Canvasと3ツールをカバーしています。単一機能かというと少し広いのですが、いずれも「ObsidianでビジュアルなファイルをClaudeに作らせる」という文脈に収まっているため、散漫には見えません。ただし、将来さらに出力形式が増えると、Skillファイルの肥大化と、Claude Codeが何を使うべきか迷う可能性が出てくるかもしれません。
ドキュメントの深度
READMEは英語と中国語の両対応で、デモ動画・トリガーワード一覧・ファイル構造・トラブルシューティングまで整備されています。CJKフォントが表示されない場合の対処手順（オンライン・オフラインの2通り）まで書かれているのは、実際に詰まったユーザーからのフィードバックを反映した形跡です。日本語向けのドキュメントはまだなく、日本のObsidianユーザーが自力でセットアップする際にはREADMEを読み解く必要があります。
想定外の使われ方への備え
ExcalidrawのCJKフォント問題は「ネットワークに繋がっていれば動く」という前提を持っており、オフライン環境やファイアウォール環境ではフォント表示が崩れます。この点はREADMEに明示されているので驚かされませんが、企業のセキュアな開発環境で使おうとしている人は事前に確認が必要です。Mermaidについては「GitHubやObsidianで使えるよう互換性を確認済み」と書かれており、出力先が複数あることを見越した記述があります。
メンテナンスの継続性
ここは正直に書かれています。「My primary focus is demonstrating how tools and systems work together, not maintaining this codebase.」この一文は正直さとして評価できます。長期メンテを期待するよりも、自分のチームでフォークして育てる前提で導入するほうが現実的です。MITライセンスなので、フォークして修正する自由は明確に保証されています。
トークン経済性
オンデマンドでSkillをロードする設計は、常駐型の仕組みと比べてコンテキスト消費を抑えます。ただし、references/ に置かれたスキーマファイルはSkill起動時にコンテキストへ読み込まれると思われるため、スキーマの量次第では起動コストが上がる場面もあります。実際のトークン消費量は、扱う図の複雑さとモデルのバージョンで変わるので、使いながら感覚をつかむのが早いです。
自分が書くなら、どこを変えるか
真っ先に気になるのは、Skillが3つあるときの「どのSkillを使うべきか」の判断基準が、ユーザー側のトリガーワードに委ねられている点です。「mind map」というキーワードはExcalidrawにもCanvasにも反応するので、同じ入力に対して複数のSkillが競合する可能性があります。ユーザーが意図しないSkillが起動したとき、そのことに気づきにくいかもしれません。
もし手を加えるなら、どのSkillが使われたかをClaudeが一言で宣言してから出力に入る構造を、SKILL.mdの冒頭に書き加えると良いかなと思います。「ExcalidrawのSkillを使います」「Mermaidで作ります」のようなひと言が入るだけで、ユーザーは意図通りかどうかをすぐ確認できます。また、日本語のトリガーワードが現状は中国語のみなので、日本語（「フロー図」「図解」「マインドマップ」など）も追記しておくと、日本のユーザーにとって使いやすくなるでしょう。
導入を検討するときのチェック観点
- Claude Codeがローカルにインストールされているか（このSkillの動作前提）
- ObsidianのExcalidrawプラグインを入れているか（Excalidraw Skillを使う場合に必要）
- 開発環境からexcalidraw.comへのアクセスが可能か（CJK文字をHandwriting体で表示したい場合）
- チームで共有する場合、スキルファイルをどこに置くか決めているか（個人の
~/.claude/か、リポジトリ内に同梱するか） - 生成されたCanvas・Excalidraw・Mermaidファイルを誰がレビューするか、品質の確認フローがあるか
- 「Experimental」ステータスを踏まえて、エッジケースが出たときに自分で修正できる体制があるか
- 既存のObsidianテンプレートや他のプラグインと競合しないか、一度サンドボックスで試したか
SkillとMCPの分岐点
このリポジトリを見て一番考えさせられるのは、「Skillで十分な仕事とMCPが必要な仕事はどこで分かれるか」という問いです。Skillはセットアップが軽い反面、Claude Codeの外部にアクセスしたり、状態を持ったりすることはできません。Obsidianのファイルを生成するだけであれば、Skillで完結する範囲に収まります。しかし、既存のノートを参照しながら図を更新したり、Vault全体を走査して関係図を作ったりしようとすると、ファイルシステムへのアクセスが必要になり、MCPや別の仕組みが要ります。
自分のユースケースがどちらに当たるかを先に整理してから導入を検討すると、後から「これだとできなかった」と気づくことを避けられるかもしれません。
