Claude Code 図解スキル3種を比較 — eli5 / show-me / diagram-design は何が違い、どれを入れるべきか

なぜ2026年8月に「図解スキル」が流行ったのか

2026年8月、Claude Code のコミュニティで図解系スキルが立て続けに話題になった。 きっかけは8月21日、Claude Code チームの Thariq Shihipar 氏が X で「Anthropic 社内で最近よく使われているスキル」として eli5 を紹介したことだ。 中身を見た人が驚いた。SKILL.md はわずか321バイト、指示は実質1文しかない。

同時期に、HumanLayer の Dex Horthy 氏が「エージェントの返答が冗長で読めない」という不満から show-me を公開し（8月12日）、 Cathryn Lavery 氏の diagram-design は「Mermaid の量産品みたいな図はもう嫌だ」というデザイナー側の不満から、GitHub Stars 1万を超えるまでに伸びた。

3つとも「Claude に図を描かせる」スキルだが、設計思想がまったく違う。 本記事では、それぞれの SKILL.md の中身、出力の性格、第三者による実測データを並べて、「結局どれを入れるべきか」を整理する。

3スキルの正体 — 一覧比較

まず全体像を1枚で示す。注目すべきは SKILL.md のサイズだ。321バイト・3.3KB・39.5KB と、およそ10倍ずつ離れている。 このサイズ差が、そのまま「スキルがどれだけ Claude の判断を代替するか」の差になっている。

eli5 — 321バイトが効く理由

eli5 の SKILL.md は、全文を引用してもコードブロック1つに収まる。

---
name: eli5
description: Explain a topic like I'm a 5 year old. Use when the user types /eli5 <topic> or asks for a dead-simple picture explainer of how something works.
---

# eli5

Explain like I'm someone who knows nothing about this topic, using a HTML artifact with big pictures and few words.

Topic: $ARGUMENTS

これだけだ。図の描き方も、色も、構成も指定していない。それでも効くのは、この1文がClaude が勝手に決めてしまう「出力ポリシー」を5点だけ固定しているからだ。

1. 読者の前提知識：「何も知らない人」に固定する。専門用語を使う言い訳がなくなる
2. 媒体：HTML アーティファクトと決める。段落テキストではなくレイアウトを組ませる
3. 絵の比率：「大きな絵」と言い切る。図が添え物にならない
4. 言葉の量：「少ない言葉」で冗長さを禁止する
5. 入力の再利用：$ARGUMENTS で /eli5 RAGとは のように即座に呼べる

たとえば RAG を頼むと「📚 文書を集める → ✂️ 細かく切る → 🔍 似たものを探す → ✍️ 読んで答える」のような、絵文字付き4ステップの1枚ページが返ってくる。難しいことをしているのではなく、Claude がもともと持っている説明能力から「冗長さ」と「専門用語」を取り除いているだけ——これが321バイトで済む理由だ。

show-me — 「最小のビュー」を選ばせる

show-me の思想は、HumanLayer のブログタイトルにそのまま出ている——compact visual representations（コンパクトな視覚表現）。 Dex Horthy 氏は「エージェントは紙の上では賢くなったのに、使う体験はこの次元で明らかに悪化した」と書く。 返答が長く、読むのに時間がかかる。人間の視覚野は何百万年もかけて豊かな視覚情報を楽に処理するよう鍛えられているのだから、それを使えばいい、という発想だ。

eli5 との決定的な違いは、HTML を最終手段にしている点だ。SKILL.md は8系統の表現形式を並べ、「要点が伝わる最小のビューを選べ」と指示する。

コード解説を頼んだとき、show-me はファイルを一切作らず、チャット内に Mermaid とコールツリーを返して終わることが多い。 実測で最速だったのはこのためだ（後述）。 「前置きを省け」「散文は短く」「図は説明文の隣に置け」「全部の形式を一度に使うな」というルールも入っており、出力の規律を標準化するスキルと言える。

diagram-design — 39種類の「編集部品質」ダイアグラム

diagram-design は前2つとは目的が違う。理解の補助ではなく、そのまま人に見せられる図を作るスキルだ。 README の言葉を借りれば「Editorial diagrams your designer won't hate（デザイナーが嫌がらない編集部品質の図）」。 リポジトリの説明に「No shadows. No Mermaid slop.」と書いてあるのが象徴的で、Mermaid の既定スタイルが生む「丸い箱と矢印の量産品」を明確に否定している。

39種類の図型と厳格なデザインルール

公開当初は27種類、v2.5.10 で Sankey・フィッシュボーン・Wardley map・かんばん・ユーザージャーニー・依存グラフ・UML クラス図・DB スキーマなど10種類が追加され、39種類になった。 それぞれに「意味論的パターン」（キュー、トレース、セキュリティレイヤーなど）とレイアウト文法が分離して定義されている。

デザインルールは具体的で、SKILL.md が39KBに膨らむ主因はここにある：

• 影（shadow）を使わない。線は 1px のヘアライン
• 角丸は 最大10px。座標はすべて 4px の倍数
• アクセントカラーは1色、焦点となる要素1〜2個にだけ使う
• 書体は3つに固定——Instrument Serif（タイトル・注釈）、Geist Sans（ノード名）、Geist Mono（技術ラベル）
• 出力は自己完結の HTML + インライン SVG。外部依存なし、オフラインで開ける、ARIA ラベル付き

さらに「ブランドオンボーディング」機能があり、自社サイトの URL からパレットとタイポグラフィを読み取って図に反映する。 draw.io や Mermaid のファイルを読み込んで、サイズ・詳細度・想定読者を変えて描き直すこともできる。 PNG は Playwright 経由で2倍解像度に書き出す。

実測比較 — 10.6倍の差はどこから来るか

日本語ブログ「AI氣道」が2026年8月24日に、3スキルを同一プロンプト・同一モデル（Sonnet）・claude CLI のヘッドレス実行で比較した結果が興味深い。 タスクは2種類——A「非エンジニアの経営層向けに DB インデックスを説明」、B「実際の Python スクリプトのコード解説」。

「10.6倍」は、タスクBの show-me（40.5秒）と diagram-design（428.7秒）の比だ。 ただしこれはshow-me が速いというより、show-me が「ファイルを作らない」という選択をした結果と読むべきだ。 同じタスクでスキルなしの Claude は HTML を作って193.9秒かかっている。show-me は「最小のビュー」を選ぶルールに従って、Mermaid をチャットに返して終わった。

逆に diagram-design の4〜7分は、39KBの指示と参照ファイルを読み込み、デザインルールに沿って SVG を組む正当なコストだ。納品物として図が必要なら、この時間は妥当。理解の補助として毎回払うには重すぎる。

見落としがちな問題 — 勝手に発火する

同記事のもう1つの発見が重要だ。diagram-design は「アーキテクチャ図を描いて」といった自然言語で発火するよう description が書かれているため、明示的に頼んでいないのに4回中1回、勝手に発火した。その回だけコストが $0.62 → $1.03 に跳ねている。

Agent Skills は、インストールした時点で全スキルの name と description がシステムプロンプトに常駐し、Claude が「今このスキルを使うべきか」を毎ターン判断する。 つまりスキルは「棚に置いた瞬間から、AI が勝手に手を伸ばす候補になる」。 diagram-design のように重く、かつ description が広いスキルを常駐させると、意図しないタイミングで数分と1ドル余りが消える。

使い分けフロー

ここまでを踏まえると、判断基準は「誰が見るか」と「図がそのまま成果物になるか」の2軸に絞れる。

flowchart TD
    A[図が欲しい] --> B{その図は<br/>そのまま人に渡す<br/>成果物か?}
    B -->|Yes: 設計書・記事・スライド| C[diagram-design<br/>スキル名を明示して呼ぶ<br/>4〜7分・約$1.5を許容]
    B -->|No: 自分が理解したい| D{読者は誰か?}
    D -->|非エンジニア・初学者<br/>1枚で伝えたい| E[eli5<br/>/eli5 topic<br/>約1分・HTML 1枚]
    D -->|自分・同僚エンジニア<br/>実装の途中| F[show-me<br/>/show-me<br/>最小ビューをチャット内に]
    F --> G{Mermaid で<br/>密度が足りない?}
    G -->|Yes| H[show-me が HTML を<br/>1ファイルだけ書く]
    G -->|No| I[Mermaid / ツリー / diff で完了<br/>ファイル生成なし]

    style C fill:#7c2d12,stroke:#f97316,color:#fff
    style E fill:#5b21b6,stroke:#8b5cf6,color:#fff
    style F fill:#1e3a8a,stroke:#3b82f6,color:#fff
    style I fill:#14532d,stroke:#22c55e,color:#fff

実務での結論はシンプルだ。常駐させるのは show-me だけ。eli5 は軽いので入れておいても害はないが、発火条件が /eli5 にほぼ限定されているので必要なときに呼ぶ形になる。 diagram-design は「図を納品する日」に入れて、明示的に呼ぶ。

3スキルが教える「スキル設計のスペクトラム」

最後に、この3つを自分でスキルを書くときの教材として見てみたい。 321バイト・3.3KB・39.5KB という差は、スキルが Claude の判断をどこまで代替するかの3段階に対応している。

ここから読み取れる原則は2つある。

1つ目、スキルの長さは「モデルに何を任せられないか」の量で決まる。 eli5 が短いのは、Claude が図解も HTML も書けると分かっているからだ。足りないのは「誰向けにどれだけ書くか」の判断だけで、そこだけ固定した。 逆に diagram-design が長いのは、Claude の既定のデザイン感覚では「デザイナーが嫌がらない」水準に届かないと判断し、感覚を仕様で置き換えたからだ。

2つ目、description の広さは、そのスキルのコストに反比例させる。 重いスキルほど発火条件を狭く（明示コマンドに近く）書き、軽いスキルほど自然言語で広く拾わせる。 diagram-design の「勝手に発火」問題は、39KB のスキルに「アーキテクチャ図を描いて」という広い発火条件を付けた組み合わせから生じている。 自作スキルでも、description を書く前に「これが誤爆したら何分・何ドル失うか」を一度見積もる価値がある。

まとめ

• eli5は321バイトの「制約型」スキル。読者を「何も知らない人」に、媒体を「大きな絵と少ない言葉の HTML」に固定するだけで、Claude の冗長さを取り除く。非エンジニアへの1枚説明に向くが、読者レベルの調整はできない
• show-meは3.3KBの「選択肢型」スキル。8系統の表現形式から「要点が伝わる最小のビュー」を選ばせ、HTML は最終手段。実装中の理解補助に最適で、日常的に常駐させる1本として推奨される
• diagram-designは39.5KBの「仕様型」スキル。39種類の図型と厳格なデザインルール（影なし・1pxヘアライン・4pxグリッド・3書体）で納品品質の HTML+SVG を出す。1回4〜7分・$1.5前後かかり、勝手に発火する問題があるため都度呼び出しが現実的
• スキルの長さは「モデルに任せられないことの量」で決まり、description の広さはコストに反比例させる——3スキルは自作スキルの設計教材でもある