- ELI5スキルの一次ソース——Anthropicのエンジニアが投稿した原文と、その正確な時刻
- 「公式スキル」なのか——3つの配布先を実測して切り分けた結果
- スキル本体の全文——321バイト・実質3行という中身と、名前と指示文のズレ
- git履歴に残る6分間——プロンプトが2回書き換えられた記録
- インストール手順と常駐コスト（約39トークン）の実測
- 同名スキルとの見分け方——検索上位を入れると別物が入る
- もう一つのeli5——3,242バイトの「レビュー用eli5」との使い分け
- eli10は実在するのか——全数調査の結果（eli5 約190件 対 eli10 3件）
- 31バイトのA/B実測——
disable-model-invocationが自動起動を止めるか
Claude Codeの開発チームに所属するThariq氏が、「Anthropicの人たちが最近よく使っているスキル」としてELI5を紹介しました。使い方は /eli5 <説明してほしいこと> の一行だけ。返ってくるのは、大きな絵と少ない言葉でできた1枚のHTMLアーティファクトです。
Claude Code全体の導入と運用は Claude Code｜2026年版・インストールからCLAUDE.md・Hooks・本番運用までの実装手引き にまとめています。本稿はその中の「スキル」という仕組みが、実際にどこまで小さく作れるのかを示す一例として読めます。
ELI5スキルとは——Anthropicのエンジニアが公開した「1行の指示文」
一次ソースは、Claude Code開発チームのThariq氏（@trq212、プロフィール上は「Claude Code @anthropicai」）が投稿した1本のポストです。投稿時刻はUTC 2026-08-21 19:32:50、日本時間では2026-08-22 04:32でした。
投稿の本文は次の3要素だけで構成されています。
・Anthropicの人たちが最近よく使っているスキルとしてELI5を紹介する一文
・使い方の書式 /eli5 <what you want explained>
・スキルの中身にあたる指示文（引用符つきで1行）
3つ目の指示文は、日本語にするとこうなります——「このトピックについて何も知らない人に対して説明してほしい。大きな絵と少ない言葉を使ったHTMLアーティファクトで」。
投稿には約9.8秒の動画が添付されており、実際の出力が動く形で示されています。反応は2026-08-22時点で約4,900いいね・約30万表示に達していました（数値は変動します）。
同氏はこれ以前にも、Anthropic社内で数百のスキルを運用した知見を公開しています。設計論の側は ClaudeチームThariqが明かしたSkills設計9カテゴリ｜Anthropic社内で数百個動かす実践則 で扱いました。本稿はその対極——設計論ではなく、実際に配られた1本のスキルの中身を開けてみる話です。
「公式スキル」なのか——3つの配布先を実測して切り分ける
「Anthropicの人が使っている」という紹介のされ方から、これを公式スキルだと受け取るのは自然な反応です。しかし配布先を実際に確認すると、もう少し込み入っています。
Anthropicが管理する配布先は用途の違う3つがあり、2026-08-22時点でそれぞれを機械的に確認した結果は次のとおりです。
| 配布先 | 位置づけ | 収録数 | eli5の有無 |
|---|---|---|---|
anthropics/skills |
Anthropicが書いた一次スキル集 | 19スキル | 無し（リポジトリ全体の一覧で0件） |
anthropics/claude-plugins-official |
公式プラグイン・マーケットプレイス | 286プラグイン | 無し |
anthropics/claude-plugins-community |
コミュニティ・マーケットプレイス | 2,282プラグイン | 有り |
つまり正確な言い方はこうなります——eli5は「Anthropicの一次スキル集に収録された公式スキル」ではなく、「Anthropicのエンジニアが書いて、コミュニティ向けマーケットプレイスに登録したプラグイン」です。
この区別は言葉遊びではありません。anthropics/claude-plugins-community は、リポジトリの説明文自身が「Read-only mirror」（投稿されたものを複製しているだけ）であると明記しており、投稿窓口も別に案内されています。anthropicsという組織名の下にあること自体は、Anthropicによる推奨や保守を意味しません。
plugin.json）には作者として Thariq Shihipar の名前が記録されており、後述するgitのコミット履歴もすべて同一名義です。素性の分からない第三者が投稿したものではありません。ライセンスはMIT、バージョンは1.0.0です。
ELI5スキルの本体は全文3行——321バイトの中身を逐条で読む
では中身です。eli5/skills/eli5/SKILL.md を取得して行数とバイト数を数えると、ファイル全体で10行・321バイト。うち前半はfrontmatter（メタ情報）なので、モデルに渡る本文は実質3行しかありません。
構造は次の2層に分かれています。
① frontmatter（いつ起動するかを決める部分）
・name — eli5
・description — 「トピックを5歳児のように説明する。ユーザーが /eli5 <topic> と打ったとき、または仕組みの極めて単純な絵解きを求めたときに使う」という趣旨の一文
② 本文（何を出力するかを方向づける部分）
・見出し # eli5
・指示文——「このトピックについて何も知らない人に説明するように、大きな絵と少ない言葉を使ったHTMLアーティファクトで」
・Topic: $ARGUMENTS —— /eli5 に続けて書いた文字列がここへ入る
注目すべきは、①と②で語彙が食い違っていることです。 起動条件を書く description 側には「5歳児のように（like I’m a 5 year old）」が残っているのに、出力を方向づける本文側は「何も知らない人」に変わっています。
この食い違いは意図的な可能性が高く、しかも理にかなっています。役割が違うからです。
| 部分 | 役割 | 語彙 | なぜその語彙が適切か |
|---|---|---|---|
description |
起動の判断材料。ユーザーの発話と照合される | 「5歳児のように」 | 「かみ砕いて説明して」という要望と結びつきやすい、通りの良い言い回し |
| 本文 | 出力の方向づけ。実際の生成を左右する | 「何も知らない人」 | 幼児語に寄せず、前提知識だけを外させる |
「5歳児に説明して」と本気で指示すると、モデルは語彙を幼児向けに寄せ、説明の正確さそのものを落とし始めます。一方「このトピックを何も知らない人へ」なら、落とすのは前提知識だけで、内容の精度は保たれます。名前とdescriptionは見つけてもらうための言葉、本文は正しく効かせるための言葉——そう読むと筋が通ります。
『5歳児のように』"] D -->|"ここは見つけてもらうための言葉"| S["スキルが起動"] S --> B["本文の指示が効く
『何も知らない人に』"] B -->|"ここは正しく効かせるための言葉"| O["出力：大きな絵＋少ない言葉
HTMLアーティファクト1枚"]
git履歴に残る6分間——プロンプトは2回書き換えられた
このスキルが面白いのは、書かれる過程がそのままgitに残っている点です。コミット履歴をたどると、初版から完成までがUTC 2026-08-21の5分44秒に収まっていることが分かります。
差分を追うと、指示文が2回書き換えられていることが分かります。
・18:52:33「初版を追加」 —— このときの指示文は「Explain like I’m an idiot that knows nothing about this topic, in a HTML page with big pictures and few words.」
・18:53:29「HTML artifactの表現に変更」 —— 「HTML page」→「HTML artifact」。READMEも同時に書き換えられている
・18:55:01「指示文を言い換え」 —— 「an idiot（間抜け）」→「someone（誰か）」
・18:58:11〜18:58:17 —— LICENSEファイルを削除しつつ、マニフェスト上のMIT表記は残す整理
1つ目の書き換えは技術的な意味を持ちます。「HTML page」は単なるファイルですが、「HTML artifact」はClaudeの成果物パネルを指す固有の概念です。出力先の器を名指ししたわけです。
2つ目は語調の調整です。初版の「an idiot」は自虐的な言い回しとしては通じますが、社外に配るスキルの語彙としては角が立ちます。中立な「someone」に落ち着いた——そしてこの語が、前述した「5歳児ではなく知識ゼロの人」という設計を決定づけました。
インストールと使い方——常駐コストは約39トークン（実測）
導入はClaude Codeから2コマンドです。本稿では Claude Code 2.1.220 で、既存の設定に影響しない隔離した設定ディレクトリを用意して実行し、いずれも終了コード0で完了することを確認しました。
# 1. コミュニティ・マーケットプレイスを追加する
claude plugin marketplace add anthropics/claude-plugins-community
# 2. eli5 を導入する（@以降でマーケットプレイスを明示する）
claude plugin install eli5@claude-community
導入後は、聞きたいことを続けて書くだけです。
/eli5 how does DNS work
/eli5 このリポジトリの認証まわりがどう動いているか
気になるのは入れっぱなしのコストです。スキルは起動していなくても、description が毎セッションのコンテキストに載ります。claude plugin details eli5 で確認したところ、内訳は次のとおりでした。
| 項目 | 実測値 |
|---|---|
| 収録コンポーネント | スキル1個のみ（エージェント・フック・MCPサーバー・LSPサーバーはいずれも0） |
| 常駐コスト | 約39トークン（毎セッションに加算） |
| 呼び出し時コスト | 約40トークン（発動のたび） |
MCPサーバーを含むプラグインが常駐で数千トークンを要求することを思えば、この軽さは際立ちます。入れておいて損がないタイプの拡張と言えます。
マーケットプレイスを追加したくない場合
claude plugin marketplace add は、2,282件のプラグインを抱えたマーケットプレイス全体を設定に登録します。3行のスキル1本のためにそこまでしたくない、という判断は十分に合理的です。
その場合は、個人用のスキルディレクトリに直接置く方法があります。Claude Codeの claude plugin init <name> は ~/.claude/skills/<name>/ に雛形を作り、次回セッションから自動で読み込まれる旨を案内します。つまりこのパスに SKILL.md を1枚置けば済みます。
mkdir -p ~/.claude/skills/eli5
# ~/.claude/skills/eli5/SKILL.md を作り、frontmatter に name と description を書き、
# 本文に「知識ゼロの人へ、大きな絵と少ない言葉のHTMLアーティファクトで」という指示と
# Topic: $ARGUMENTS を置く
・マーケットプレイス経由 —— 作者名義やバージョンが辿れる。更新も追える。他のプラグインも探したいなら断然こちら
・手動配置 —— 設定に余計なものを増やさない。中身が3行なので、写して置くコストがそもそも低い
中身を自分の言葉で調整したいなら、後者のほうが素直です。
「大きな絵＋少ない言葉」は何を解決するのか
ここまでで「中身は3行」と分かりました。では、なぜわざわざスキルにするのでしょうか。毎回プロンプトに書けば済むはずです。
答えは、このスキルが解決しているのが「説明の質」ではなく「説明の形式」だからです。
AIに「これを説明して」と頼むと、たいていよくできた長文が返ってきます。正確で、網羅的で、そして——他人に渡せません。前提知識を持つ人が読めば良い解説でも、知らない人の前に置くと最初の段落で止まります。
ELI5が固定しているのは次の3点です。
・出力先 —— チャットの返信ではなく、HTMLアーティファクト（独立した1枚の成果物）
・情報密度 —— 「少ない言葉」。書ける量に上限がかかるので、削る判断が強制される
・表現手段 —— 「大きな絵」。文章で逃げられないので、構造を図に落とすことになる
3つ目が効きます。文章は分かっていなくても書けてしまいますが、図は構造を理解していないと描けません。 「絵で説明しろ」という制約は、説明する側に理解の整理を強います。
・オンボーディング —— 「この認証フローを新メンバーに説明して」
・非エンジニアへの共有 —— 障害の原因や技術選定の理由を、そのまま渡せる1枚に
・自分の理解の点検 —— 図に落ちない部分は、自分がまだ分かっていない部分
冒頭に置いた図は、公開されている指示文をそのまま実行して再現したものです。お題は公式READMEが例示している「DNSの仕組み」を選びました。手順が4つ、1手順あたり十数文字、結論は「名前→住所」の5文字——ふつうの技術解説なら数千字かかる内容が、この密度まで削られています。
なお、削られている以上これは入門用の像であって、正確な全体像ではありません。DNSの実際の解決過程にはキャッシュや複数階層の問い合わせがあります。ELI5の出力は「最初の1枚」として使い、詳細は別に当たる——という前提で扱うのが妥当です。
同じ型で自分のスキルを書く
ELI5の構造を抽象化すると、3行スキルの型が見えてきます。実装が要らない代わりに、次の3つを言い切れるかどうかが成否を分けます。
| 決めること | ELI5での答え | 自分で書くときの問い |
|---|---|---|
| 出力先の器 | HTMLアーティファクト | 成果物はチャットの返信か、ファイルか、独立した1枚か |
| 量の上限 | 「少ない言葉」 | どれだけ削らせたいか。上限を書かないと必ず長くなる |
| 表現手段 | 「大きな絵」 | 文章・図・表・コードのどれで答えさせたいか |
逆に言えば、この3つを指定していないプロンプトは、毎回ぶれます。「分かりやすく説明して」だけでは、出力の形が固定されないからです。ELI5がやったのは知識の追加ではなく、ぶれる余地を先に潰したことでした。
「eli5」という名前は混み合っている——検索して入れると別物が入る
最後に、実務上いちばん引っかかりやすい点です。
本稿の調査時点（2026-08-22）にGitHubで eli5 claude skill を検索すると11件ヒットし、そのうちリポジトリ名が実際に「eli5」なのは3件でした（残りはREADMEでELI5に言及しているだけの別プロジェクトです）。そしてヒットした11件はすべて、今回の投稿より前に作られています（最も新しいもので2026-08-12作成）。つまり検索で見つかるものは、名前が似ているだけの無関係なスキルです。
さらに範囲を広げると、名前に「eli5」を含むリポジトリはGitHub全体で492件あります。最もスターが多いのは TeamHG-Memex/eli5（★2,779）で、これは機械学習モデルの予測を説明するPythonライブラリ——Claudeのスキルとはまったく無関係です。facebookresearch/ELI5 に至ってはNLPの データセットです。この語はもともと踏み荒らされた名前空間だと理解しておく必要があります。
| リポジトリ | ★ | 作成日 | 実際の中身 |
|---|---|---|---|
DreambigOu/ELI5 |
26 | 2026-03-17 | 相手（子ども・上司・エンジニア等）に合わせて語調を変えるスキル。HTMLアーティファクトは主眼ではない |
nathanksou/eli5 |
3 | 2026-04-06 | トークン削減スキル caveman（★100,165）のフォークを改名したもの。目的は出力の圧縮 |
TrystonPerry/eli100iq |
1 | 2026-08-12 | 逆方向。「5歳児扱いしない、賢い大人向けの平易な説明」を掲げるスキル |
とりわけ2つ目は紛らわしい例です。nathanksou/eli5 はフォーク元が caveman、つまり「原始人のように短く話してトークンを削る」というまったく別の目的のスキルを改名したものです。名前だけ見て入れると、大きな絵は出てきません。
claude plugin install eli5@claude-community のようにマーケットプレイス名まで含む識別子で指定してください。導入後に claude plugin details eli5 を実行し、作者が Thariq Shihipar であることを確認できます。
なお投稿の翌日には、同じ発想をCodex向けに実装したリポジトリ（zdrjson/codex-eli5、2026-08-22作成）も現れています。この名前空間は今後さらに混み合うと見ておいたほうが安全です。
もう一つのeli5——dzhng/skills の「設計レビュー用」eli5
前節の結論は「検索で出てくる同名スキルは無関係」でしたが、2026-09-04時点で再調査したところ、これは言い過ぎでした。無関係な同名スキルに混じって、真剣に作られた第2のeli5が存在します。dzhng/skills（★860・MIT・作成2026-07-02）の skills/engineering/eli5/SKILL.md です。
同じ「eli5」を名乗りながら、Thariq版とは設計思想が正反対です。なお本節のスター数はいずれも2026-09-04 02:50 JST時点の実測値です（humanlayer/skills は同日の1時間で★1,124→1,158と動いており、この種の数値は短時間で変わります）。
Thariq版 eli5@claude-community |
dzhng版 dzhng/skills |
|
|---|---|---|
| SKILL.md のサイズ | 321バイト（実質3行） | 3,242バイト |
| 想定読者 | 「何も知らない人」 | 「コードを読んでいない技術者」 |
| 出力の形 | HTMLアーティファクト（大きな絵） | Markdown 3見出し固定（Problem / Solution / Schema changes） |
| 対象 | 任意のトピック（/eli5 DNS） |
仕様書・未コミットの差分 |
| アナロジー | 積極的に使う | 「主張をアナロジーで置き換えない」と明示的に禁止 |
| 自動起動 | 制限なし | disable-model-invocation: true で禁止 |
| 導入 | claude plugin install eli5@claude-community |
npx skills add dzhng/skills |
npx skills add が実際にディスクへ何を書くかは skills.shとは｜npx skills add がディスクに何を書くかを実測 で検証しています。
決定的な違いは「何を簡単にするか」です。Thariq版は説明の粒度を落とします。dzhng版は逆で、SKILL.md本文にこう書かれています——「simplify the telling, never the claims（語り方は簡単にしてよいが、主張は決して簡単にするな）」。実際、本文には「疑似コードを使え」「初出の専門用語はすべて定義しろ」「スキーマ変更は網羅的に列挙しろ（変更が無いなら無いと明記しろ）」という指示が並びます。5歳児向けではなく、レビュアー向けのスキルです。
- Thariq版——概念を人に見せる。DNSとは、OAuthとは。成果物は1枚の絵
- dzhng版——自分の変更を他人にレビューさせる前に、言葉で成立しているか確かめる。成果物はPR説明文にそのまま貼れるMarkdown
dzhng/skills は22スキルを収める個人ライブラリで、eli5はその engineering カテゴリの1本です。同じリポジトリには codex スキルも同居しています——本記事のGSC実測では eli5 codex（平均2.9位）・codex eli5（同3.7位）というクエリが実際に流入しており、両者が同じリポジトリに同居している事実は知っておく価値があります（ただしクエリの発生原因がこの同居にあると示す証拠はありません）。
実測：31バイトの1行で自動起動が消える——disable-model-invocation のA/B
dzhng版eli5の disable-model-invocation: true は、「呼ばれない限り絶対に発動しない」ことを宣言する1行です。これが本当にランタイムで効いているのかを、単一変数のA/Bで実測しました。
.claude/skills/eli5/SKILL.md を置く。片方は公式のまま、もう片方は disable-model-invocation: true の1行だけを削除（3,232バイト→3,201バイト、差は31バイト。本文はバイト単位で同一であることをプログラムで確認済み）。同一プロンプトを投げ、--output-format stream-json --verbose で Skill ツールの発火を直接観測する。
プロンプトは、dzhng版eli5のdescription（”Explain a technical spec or proposed change in plain language: what problem it solves, how the solution works, and every schema change.”）にわざと寄せた次の1文です。
In plain language, explain what problem the uncommitted change solves, how the solution works, and every schema change.
結果は明確に割れました。
| 条件 | frontmatter | Skill ツールの発火 |
ターン数 | 出力トークン |
|---|---|---|---|---|
| C2 | disable-model-invocation: true あり |
0回 | 5 | 4,059 |
| D2 | 同 なし（31バイト削除） | 1回（Skill{"skill":"eli5"}） |
8 | 5,504 |
D2では Skill 呼び出しが最初のツール実行として出ています。C2ではモデルはスキルを一切呼ばず、自力で git diff を読んで手作業で答えました。31バイトの差だけで、自動起動が消えます。
Skill tool_use で行った「ガードが無ければ必ず起動する」わけではない
同じ実験を、description に寄せていない素朴なプロンプト（Explain the uncommitted change in this repo.）でも回しました。こちらはガードの有無にかかわらず両方とも発火0回でした。
| プロンプト | ガードあり | ガードなし |
|---|---|---|
Explain the uncommitted change in this repo. |
発火0 | 発火0 |
| description に寄せた文（上記） | 発火0 | 発火1 |
つまり自動起動は「スキルを置けば起きる」ものではなく、プロンプトとdescriptionの一致度に依存する確率的な挙動です。disable-model-invocation: true の価値は「起動を減らす」ことではなく、その確率的な挙動を「絶対に起きない」に固定できる点にあります。逆に言えば、ガードが無いスキルを入れても、期待した場面で起動する保証はありません。
出力はどう変わったか
同一プロンプトに対する2つの出力を並べると、差は「賢さ」ではなく形に出ました。
・C2（スキル非適用） —— 見出しはプロンプトの言い換え（”What problem this solves” / “How the new solution works” / “Schema changes”）。散文中心で、fetchone() / fetchall() といった実装シンボルを地の文で使う
・D2（eli5適用） —— 見出しはSKILL.mdが指定した Problem / Solution / Schema changes そのまま。加えて、SKILL.mdが求める「一つの具体シナリオを最後まで歩く」が実際に現れ、save(db, "s1", "turn A") → save(db, "s1", "turn B") → 「”turn A” is gone, permanently」と実際の呼び出し列で説明した
MIGRATION 定数という同じ落とし穴を指摘できていました。eli5が足しているのは正確さではなく、出力の「形」の再現性です。毎回 Problem / Solution / Schema changes が同じ順で並び、具体例が必ず1本入る——PR説明文のテンプレートとして使うなら、この再現性のほうが価値があります。
disable-model-invocation: true"} B -- "あり" --> C["自動起動しない
（実測：発火0回）"] C --> D["明示呼び出しでのみ動く
／eli5 または Skill ツール"] B -- "なし" --> E{"プロンプトが
description と一致するか"} E -- "一致度が高い" --> F["自動起動する
（実測：発火1回）"] E -- "素朴な言い回し" --> G["自動起動しない
（実測：発火0回）"]
eli10は実在した——ただしeli5 約190件に対して3件
「eli5があるならeli10もあるのでは」という素朴な疑問を、GitHubコード検索で実測しました。
ここで注意が要ります。eli10 という語での件数検索は信用できません。実際に "eli10" filename:SKILL.md は7,072件を返しますが、同じ形の "eli5" は1,908件しか返しません。eli10がeli5より多いはずがなく、返ってきた実物を開くと eli100iq のような部分一致を拾っていました。そこで、frontmatterの宣言そのものを条件にし、ヒットした全件を実際にダウンロードして中身を確認する方法に切り替えました（存在しない文字列で対照実験し、0件が返ることも確認済み）。
| 検索条件 | 件数 | 確認方法 |
|---|---|---|
"name: eli5" filename:SKILL.md |
約190件 | 同日中の再測定で190→191と動いた |
"name: eli10" filename:SKILL.md |
4件 | 全4件をダウンロードして中身を確認 |
"name: zqxwvu9821"（対照群） |
0件 | 検索が実際に絞り込んでいることの確認 |
4件のうち name: が厳密に eli10 なのは3件で、残る1件は eli10-explainer でした。eli5 約190件に対し、eli10 は実質3件です（コード検索の索引は生きているため件数は数分単位で動きます。ここでは桁の差だけを主張しています）。しかも中身を見ると、性格がばらばらでした。
| リポジトリ | ★ | サイズ | 中身 |
|---|---|---|---|
sasamuku/dotfiles |
9 | 643バイト | 日本語。「地頭のよい知的好奇心が旺盛な10歳向けの図解説明」。HTMLアーティファクトを出力 |
Esteban-Bermudez/dotfiles |
1 | 2,550バイト | 英語。「短い文・専門用語なし・日常のたとえ」。Not sticky（その1メッセージ限り）と明記 |
aelaguiz/arch_skill |
1 | 13,472バイト | 英語。ELI10/ELI16を「最大可読性スタイル」として定義。dzhng版eli5に近い思想（正確さを保ったまま読みやすくする） |
Ankit-euphemism/AI_master_skils |
0 | 8,694バイト | name: は eli10-explainer |
とりわけ sasamuku/dotfiles の1本は、日本語話者にとって実用的です。全文で643バイトしかなく、Thariq版eli5と同じ「大きな図と短い文で構成したHTML Artifact」を出力しつつ、対象年齢を10歳に上げて「簡単にするのは概念であって、言葉ではない」「子ども扱いした言い回しはしない」と釘を刺しています。Thariq版の発想を日本語で書き直した派生と読めます。
本当に広く使われている「ELI10」は、スキルではない
もう一つ、件数では見えない使われ方があります。★131,109の garrytan/gstack では、qa/SKILL.md の中で ELI10が「スキル名」ではなく「出力に必ず含めるべき節の名前」として6回登場します。定義は「16歳が追える平易な英語で2〜4文、何が懸かっているかを述べる」で、末尾のチェックリストには - [ ] ELI10 paragraph present という項目まであります。
/eli10 を探してもほとんど見つからないのは、この語がそもそもコマンド名ではなく書式の名前として定着しつつあるからです。
show-me——「図で見せる」スキルは、自動では起動しないことがある
もう1本、同じ「説明の仕方を変える」系のスキルとして humanlayer/skills（★1,158・MIT）の show-me を実測しました。SKILL.mdは3,297バイトで、disable-model-invocation はありません（＝自動起動しうる）。
中身は「何をどの図で見せるか」の対応表です——ロジックは疑似コード、実行時の流れはコールツリー、UI構造はコンポーネントツリー、ファイル責務は浅いツリー、相互作用はMermaid、変更が主題なら diff。最後に「これらを全部使うことはまずない、判断して選べ」と釘を刺しています。
実測では、同じスキルが起動したりしなかったりしました。
| プロンプト | Skill 発火 |
出力の形 |
|---|---|---|
Help me understand how save() and load() work in this repo. |
0回 | 通常の散文＋箇条書き。図は無し |
| （別セッションでの実行） | 1回 | diff ブロック3本＋Mermaid sequenceDiagram |
起動したときの出力は、SKILL.mdが挙げた道具立てがそのまま現れます。スキーマ変更は diff ブロックで「消えた行・増えた行」として示され、保存フローはMermaidのシーケンス図になりました。起動しなかったときは、同じ質問に対して図が1つも出ませんでした。
これは前節の結論と同じ形をしています——ガードの無いスキルは「起動しうる」だけで、「起動する」保証はありません。show-meのように出力形式を変えるスキルを確実に効かせたいなら、/show-me のように明示的に呼ぶのが確実です。
常駐コストの実測（トークナイザを明記）
3本のSKILL.mdについて、常駐分（name + description）と呼び出し時（全文）のトークン数を実測しました。トークナイザによって値が変わるため、両方を併記します。
| スキル | バイト | 常駐（name+description） |
全文 |
|---|---|---|---|
dzhng/eli5 |
3,242 | 48（cl100k: 31） | 1,025（cl100k: 687） |
humanlayer/show-me |
3,297 | 49（cl100k: 25） | 1,173（cl100k: 772） |
sasamuku/eli10（日本語） |
643 | 96（cl100k: 94） | 243（cl100k: 250） |
太字は Anthropic の count_tokens API（claude-opus-5）による実測で、メッセージ封筒ぶん7トークンを含みます。括弧内は tiktoken の cl100k_base です。
count_tokens ÷ cl100k が1.46〜1.52倍（cl100kは少なく見積もる）でしたが、日本語の sasamuku/eli10 だけは0.97倍——cl100kのほうが多く出ました。倍率が対象によって逆転するため、一律の換算係数は使えません。トークン数を語るときは、必ずどちらで測ったかを併記してください。
本記事冒頭で示したThariq版の「常駐約39トークン」は、claude plugin details がCLI上で表示する見積もり値であり、上表の count_tokens 実測とは測り方が違います。同じ土俵で比べた数字ではない点にご注意ください。
まとめ——3行のスキルが示していること
ELI5について、実測で確かめられたことを整理します。
・出所 —— Claude Code開発チームのThariq氏が2026-08-22 04:32 JSTに告知。plugin.json上の作者名義も同氏
・配布先 —— Anthropicの一次スキル集（19件）にも公式プラグイン集（286件）にも無く、コミュニティ・マーケットプレイス（2,282件）にある
・中身 —— SKILL.md全体で321バイト、モデルに渡る本文は実質3行。コードは0行
・名前と実体のズレ —— descriptionは「5歳児のように」、本文は「何も知らない人に」。効いているのは後者
・コスト —— 常駐約39トークン。入れっぱなしでほぼ負担にならない
・注意点 —— 同名の別スキルが多数あるため、eli5@claude-community で指定する
・もう一つのeli5 —— dzhng/skills に3,242バイトの「レビュー用eli5」がある。出力は Problem／Solution／Schema changes の3見出し固定
・eli10 —— 実在するが実質3件（eli5は約190件）。むしろ★131,109の garrytan/gstack で「出力の必須節の名前」として使われている
・自動起動 —— disable-model-invocation: true の31バイトを外すと Skill 発火が0回→1回に変わる。ただしプロンプトがdescriptionに寄っていなければ、ガード無しでも起動しない
このスキルの本当の教材価値は、「スキルは3行でも成立する」と示したことにあります。 そしてもう一つ、実測から言えることがあります——スキルを「入れた」ことと「効いている」ことは別です。disable-model-invocation のA/Bが示すとおり、自動起動はプロンプトとdescriptionの一致度に左右される確率的な挙動で、入れただけでは期待した場面で効く保証がありません。確実に効かせたいなら明示的に呼ぶ——これが3本のスキルを実測して残った、いちばん実務的な結論です。 スキルというと大掛かりな仕組みを想像しがちですが、実体は「出力の形式を先に固定する短い指示文」でも十分に機能します。
スキルという仕組み自体を体系的に知りたい場合は Claude Skillsとは｜「スキル=フォルダ」の仕組みと作り方・使い方を徹底解説 をあわせてご覧ください。あなたが毎回同じ前置きをプロンプトに書いているなら、それはもう3行のスキルにできる、というのがELI5の示した最も実用的な示唆です。
