Redditで話題のClaude Codeプラグイン「i-have-adhd」を試してみた

Claude Code のプラグイン「i-have-adhd」を入れると、回答が「結論1行 → 番号付きの判断基準 → 次の一手」という構造に変わります。Reddit で大きく盛り上がっていたので実際に導入し、同じ質問をプラグインなし・ありで投げて比較してみました。

Redditで2,800upvoteを集めたプラグイン

きっかけは r/ClaudeAI のこのスレッドです。私が確認した時点で 2,830 upvotes、コメントは 439 件でした。

i-have-adhd は、回答の前置きや締めの挨拶を禁じて、答えから書かせるプラグインです。名前は ADHD の人向けに作られたことに由来します。ただ、答えから書かせるという方針は、当事者かどうかに関わらず役立つものだと感じました。

導入はコマンド2つ

さっそく入れてみます。まず marketplace を追加します。

claude plugin marketplace add ayghri/i-have-adhd

実行すると次のログが出ました。SSH 未設定でも HTTPS に自動でフォールバックしてくれます。

SSH not configured, cloning via HTTPS: https://github.com/ayghri/i-have-adhd.git
Refreshing marketplace cache (timeout: 120s)…
Cloning repository (timeout: 120s): https://github.com/ayghri/i-have-adhd.git
Clone complete, validating marketplace…
Cleaning up old marketplace cache…
✔ Successfully added marketplace: i-have-adhd (declared in user settings)

続けてインストールします。

claude plugin install i-have-adhd@i-have-adhd

✔ Successfully installed plugin: i-have-adhd@i-have-adhd (scope: user)

ここまでで詰まった点は特にありません。使うときはセッションで /i-have-adhd を呼ぶだけです。

同じ質問で比較してみた

「WebアプリのテストってどこまでE2Eで書くべき？」という質問を、素の Claude Code とプラグイン経由の両方に投げました。注目したいのは回答の中身ではなく、答えの並べ方です。

まずは素の Claude Code の回答です。

結論から言うと、クリティカルなユーザーフロー（重要な収益パス）だけに絞るのが定石です。サインアップ、ログイン、決済、主要な購入導線など「ここが壊れたら事業が止まる」経路だけE2Eでカバーし、それ以外の分岐やエッジケースはunit/integrationテストに落とす。E2Eは実行が遅くflakyになりやすく、メンテコストがテスト数に対して非線形に増えるので、網羅性を追い求めると逆にテストスイート全体の信頼性が落ちます。

補足すると、最近主流なのは古典的な「ピラミッド（unit多め）」より Kent C. Dodds の Testing Trophy（integration厚め、E2Eは少数精鋭、unitは最小限）という考え方で、「ユーザーの使い方に近いテストほど価値が高い」という発想です。目安としては、E2Eは全体のテスト数の5〜10%程度に抑え、それ以外はコンポーネント単位のintegrationテストで実装詳細に依存せず振る舞いを検証する、というバランスが実務では扱いやすいです。

何かこの判断で迷っている具体的なプロジェクト（テストフレームワークやCI時間の制約など）があれば、そこに合わせてもう少し具体的な線引きを一緒に考えられます。

内容はしっかりしています。ただ、密な散文が3段落続きます。

次に /i-have-adhd:i-have-adhd（/i-have-adhd の完全修飾形）で同じ質問を投げた結果です。

結論: クリティカルパスだけE2E。それ以外はユニット/インテグレーションに落とす。

判断基準:

1. E2Eにする — ユーザーが実際に踏む主要フロー（ログイン→購入→完了、サインアップ、検索→詳細→アクション等)。壊れたら事業が止まるものだけ。目安5〜15シナリオ。
2. E2Eにしない — バリデーションの分岐、エラーメッセージの文言違い、権限パターンの全組み合わせ、UIの見た目の細部。これはユニット/インテグレーションでカバーする方が速く安定する。
3. API/ロジックはインテグレーションテストで潰す — E2Eでバックエンドの分岐網羅をやると実行時間とflaky率が跳ね上がる。ロジックの正しさはAPIレベルのテストで担保し、E2Eは「画面が繋がって動くか」の確認に絞る。

理由: E2Eは1本あたり実行が遅く（数秒〜数十秒）、環境依存でflakyになりやすい。本数を増やすほどCIが重くなり、メンテコストが線形以上に増える。テストピラミッド（ユニット多数・インテグレーション中間・E2E少数）が今も基本的に正しい。

次の一手: 今のアプリで「これが落ちたら致命的」なユーザーフローを3つ書き出す。それがE2Eの対象リスト。

前置きも締めの挨拶もありません。

変わったのは長さではなく構造

Reddit のスレッドには「短く端的になった」という声もありました。ただ、見比べて分かったのは、短くなるというより情報が整理されるということです。素の回答も結論から入ってはいるのですが、締めは「一緒に考えられます」という逆質問でした。プラグイン版は逆質問の代わりに、今すぐやることを具体的に指定してきます。読み飛ばしながらでも要点が拾えるのがありがたいところです。

一方で気になる点もあります。素の回答にあった Kent C. Dodds の Testing Trophy のような補足は、プラグイン版では出てきませんでした。背景情報や細かい経緯が落ちる場合があるかもしれません。じっくり背景から理解したい場面では、素の Claude Code のほうが向いていそうです。

まとめ：どんな人向けか

Claude Code の回答が長いなと感じている人、つい読み飛ばしてしまう人は、コマンド2つで入るので気軽に試せます。なお、今回の検証は1問だけの比較で、プラグインの中身までは見ていない軽い検証です。質問の種類によって効き方が変わるかまでは分かりません。

Reddit のコメント欄には、Skill として都度呼ぶより output style として設定したほうが定着する、という趣旨の声もありました（こちらは未検証です）。

プラグインを増やしていくと管理が気になってきますが、棚卸しは /doctor に任せられます。以前書いた記事があるので、あわせてどうぞ。

Xをフォローいただけると嬉しいです！

AI駆動開発（特に Claude Code）のノウハウや Tips をよく発信しています！