eli5 とは何か
eli5 は Claude Code に入れて使うプラグインだ。中にスキルが一つ入っていて、そのスキル名も eli5 である。
名前は Explain Like I am 5 の略で、五歳児に説明するようにやさしく言ってほしい、という英語圏で長く使われてきた言い回しだ。Reddit などで質問の頭に付けられていた表現が、そのままスキル名になった。
やることは一行で足りる。プロンプトに /eli5 と打ち、一つ空けて主題を書くと、答えがいつもの長文ではなく、絵が中心の HTML 一枚として作られる。
スキルという語が耳慣れないかもしれない。Claude Code でのスキルとは、特定の場面でモデルが従うべき指示をファイル一つに書いておいたものだ。プログラムではなく文章である。スラッシュコマンドで呼ぶとその指示が会話に入り、モデルはそれに従って答えを作る。
プラグインはそのスキルを配布する包装の単位だ。複数のスキルを束ねたものもあるが、eli5 はスキル一つだけの非常に小さなプラグインである。
このスキルが突いている問題
知らない主題を AI に尋ねると、答えはたいてい長い段落と箇条書きで返ってくる。内容が誤っているわけではない。問題は高さだ。
モデルは尋ねた人がその分野の用語をすでに知っている前提で説明する。だから答えの中にまた知らない語が出てきて、それは何かと聞き返す往復が始まる。二、三度往復するうちに最初に知りたかったことがぼやけ、読むこと自体に疲れる。
形式も毎回変わる。やさしく説明してと手で書き足しても、ある日は表が出て、ある日は十段落が出る。同じ文句を使っても結果は運任せだ。
eli5 はその二つを指示の中に打ち込んでいる。高さは何も知らない人に固定し、形式は絵を大きく文字を少なく HTML でと固定する。毎回手で書く必要がなくなり、結果のばらつきも減る。
言い換えれば、読む説明を見る説明に移す装置だ。しかもそれをコード一行なしに、指示一枚でやっている。
インストールは二行で終わる
上の二行を順に実行すればよい。一行目はコミュニティのマーケットプレイスを登録するもの、二行目はそこから eli5 プラグインを入れるものだ。
Claude Code の中で実行してもよいし、ターミナルで claude コマンドとして実行してもよい。入れ終わると、プロンプトで /eli5 と打ち始めたときに補完候補に出る。タブで挿入できる。
一度つまずくのがマーケットプレイスだ。Claude Code には公式マーケットプレイスが最初から登録されているが、eli5 はそこではなくコミュニティ側にある。だから一行目で自分で追加する必要がある。
claude plugin marketplace add anthropics/claude-plugins-community
claude plugin install eli5@claude-community公式マーケットとコミュニティマーケットの違い
どちらも anthropics アカウントのリポジトリなので紛らわしい。しかし性格が違う。
公式側は Anthropic 自身が管理するプラグインの目録で、Claude Code に最初から登録されているため、追加なしでインストールできる。
コミュニティ側は外部から提出されたプラグインが集まる場所だ。リポジトリの説明によれば、これは読み取り専用のミラーであり、一覧は Anthropic 内部のレビュー工程から毎晩同期される。そこに載っているものは提出を経て自動セキュリティ検査を通り、配布の承認を受けている。このリポジトリに直接出されたプルリクエストは自動的に閉じられる。
まとめるとこうだ。eli5 は Anthropic アカウントのリポジトリにあり、作者も Anthropic の人だが、既定登録の公式マーケットのものではない。インストール時に覚えるのは識別子二つだけ、eli5 と claude-community である。
リポジトリのスター数もこの違いを表している。2026 年 8 月 29 日時点で公式が約 3 万 5 千、コミュニティが約 2 千 5 百だ。数が小さいからといって非公式の流出物という意味ではない。登録の経路が違うだけである。
| 区分 | リポジトリ | 既定で登録済みか | インストール識別子 |
|---|---|---|---|
| 公式 | anthropics/claude-plugins-official | 登録済み | 名前だけでよい |
| コミュニティ | anthropics/claude-plugins-community | 自分で追加する | 名前@claude-community |
実際に使ってみると
スラッシュコマンドを入れて一つ空け、聞きたいことを普段話すように書けばよい。あとに書いた文がそのままスキルの主題として渡る。
比較のためスキルなしで同じ問いを投げると、答えはこう来る。エージェントループ、モデル、権限、コンテキスト管理といった項目が段落で並び、説明は詳しいが、初めて見る用語がその中にまた混ざっている。Bedrock や Vertex といった名前が出れば、クラウドを知らない人はそこでまた止まる。
eli5 を付けると、応答は HTML ファイルを一つ作る方向に流れる。会話には五歳版の要約が短く出て、横に HTML ファイルが生成される。開くと文字は最小限に減り、絵が画面を埋めている。
たとえばエージェントループは段落ではなく四枚の絵に分かれて流れが見え、ツールや権限といった項目もそれぞれ一かたまりに配置される。構造を知らない人が全体の形をつかむには、こちらのほうが速い。
違いを一文にすると、左は全部読まないと分からず、右は見るだけで輪郭がつかめる、ということだ。
/eli5 Claude Code がどう動くのか教えて十行を開いてみる
上がファイルの全文だ。切り取ったものではなく、これで全部である。十行、321 バイト。
先頭のダッシュ三つに挟まれた部分はフロントマターと呼ばれる前書きだ。name はスキル名、description はこのスキルをいつ使うべきかをモデルに伝える説明である。スラッシュコマンドで直接呼ぶこともできるし、やさしい図解がほしいと言われたときにモデル自身がこのスキルを選ぶこともある。
本文は二文だ。第一に、この主題を何も知らない人に説明するように説明せよ。第二に、説明には HTML アーティファクトを使い、絵は大きく文字は少なくせよ。前の文が高さを決め、後ろの文が形式を決める。
最終行の $ARGUMENTS はプレースホルダーだ。スラッシュコマンドのあとに書いた文がここにそのまま入ってモデルへ渡る。Claude Code がどう動くのか教えてと書けば、その文が Topic のあとに入る。
このファイルは Anthropic の Claude Code チームに所属する Thariq Shihipar が 2026 年 8 月 21 日に上げた。コミット履歴を見ると、プラグインを追加し、HTML アーティファクトという表現に文言を直し、ライセンス項目を整える過程が残っている。ライセンスは MIT だ。
---
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どこで使うとよいか
使いどころは三つの場面に整理できる。
第一に、非開発の同僚に説明するときだ。今回入れたツールは何かという問いが、企画からもマーケティングからも運用からも来る。人によって前提知識の深さが違うのに、毎回話して高さを合わせるのは骨が折れる。絵を一枚作って渡せば、準備の時間はほとんどかからない。
第二に、新人のオンボーディング初日だ。アーキテクチャ文書五十枚を渡して読んでおいてと言うやり方が広く行われているが、量が多いから分かるわけではない。会社ごとに用語が違うので、最初の週はむしろ詰まる。同じ内容を先に絵一枚で見せ、文書はそのあとに読ませるほうが順序として正しい。
第三に、障害が起きた翌日だ。振り返りを書かねばならず時系列は複雑で、その場には非開発の組織も同席する。何がどの順で起き、いまどこまで来ているかを図にしておけば、会議の時間が縮む。
三つに共通するのは一つだけだ。聞く人の高さに合わせること。難しい用語で一時間説明するより、絵一枚のほうが速いときがある。
知ってから使いたい二つのこと
第一に、このスキルは内容が正しいかを検証しない。固定するのは高さと形式であって、事実の当否ではない。
そしてここに落とし穴がある。絵がもっともらしいほど、誤った内容ももっともらしく見える。段落で書かれた誤りは読みながら引っかかるが、図として描かれた誤りは、すでに検証済みのものとして読まれてしまう。人に渡す前に元資料と突き合わせる段取りを工程に入れておくほうが安全だ。社内アーキテクチャや障害の時系列のように事実関係が重い資料ならなおさらである。
第二に、成果物は HTML ファイルだ。ブラウザで開くにはよいが、Slack や Notion にそのまま貼り付けることはできない。共有するには画面を撮るかファイルを別途送る手間が一つ増える。
だから期待値は正確に置いたほうがよい。完成した共有文書が出てくる道具ではない。言葉で説明するより絵のほうが分かりやすい、という程度であり、その程度でも十分に役に立つ。
ここから持ち帰るもの
eli5 そのものより、このスキルが見せているやり方のほうが長く残る。
スキルは特別な技術装置ではなく指示だ。そして指示は明確で簡潔なほど結果が安定する。eli5 のやることは大きいのに、ファイルは十行しかない。長く書けばよく効く、というわけではないということだ。
近ごろ出回るスキルがおおむね短いのは、ここに理由がある。何をさせるか、結果をどの形式で出すか。この二つがはっきりしていれば、残りはモデルが埋める。
自分で作るときも同じ順序で始めればよい。繰り返し手で書いている指示は何かを探し、それを二、三文に縮めてファイル一つに書く。高さと形式を打ち込むだけで、結果のばらつきは小さくなる。