注意: 本記事はドキュメント・公開情報をもとにした評価記事です。コード例はシミュレーションです。
3行要約
- コーディングエージェントが回答の核心を冗長な説明の中に埋める問題を、出力を強制制御することで解決する
- 出力を「簡潔な要約」「変更点」「実行手順」に構造化し、AIとのやり取りにおける認知負荷を最小化する
- ClineやCursorをヘビーに使い、AIの丁寧すぎる解説に「早くコードを見せろ」と感じている全エンジニアが使うべき
📦 この記事に関連する商品(楽天メインで価格確認)
GeForce RTX 4090ローカルLLMで複雑な指示を高速処理するなら24GBのVRAMは正義
※アフィリエイトリンクを含みます
結論から: このツールは「買い」か
結論から言えば、CursorやCline(旧Claude Dev)を使って実務をこなす全エンジニアにとって「必須級のプロンプト・フレームワーク」です。★評価は5点満点中4.8。
このツールの真価は、AIの「解説おじさん化」を物理的に封じる点にあります。 開発者が本当に欲しいのは「動くコード」と「どこを変えたか」の2点だけであり、そこに至るまでの1000文字の解説は、読む時間の無駄であるだけでなく、トークン料金の無駄でもあります。
特に、1日に数十回、数百回とエージェントに指示を出すプロの開発者にとって、1回あたりのレスポンス待ち時間を3秒短縮し、スクロールの手間をゼロにする効果は計り知れません。 ただし、AIに「なぜそうしたのか」という教育的な側面や、丁寧な対話を求める初心者には、少し冷たすぎると感じるかもしれません。
このツールが解決する問題
従来のコーディングエージェント、特にClaude 3.5 Sonnetのような賢いモデルは、非常に丁寧です。 「はい、承知いたしました。ご指摘の箇所のバグを修正するために、まず現在のクラス構造を分析し、以下の3つのステップで修正を行います。まず1つ目は……」といった具合に、本題のコードに辿り着くまでにスマートフォンの画面2枚分くらいの解説を挟んできます。
これが実務、特に締め切りに追われている時や、複雑なロジックをデバッグしている時には致命的なノイズになります。 人間は「変更されたコード」を探すためにスクロールを強いられ、その過程で本来考えていた設計のコンテキストを忘れてしまう。 これこそが、ツール名にもある「ADHD的な注意力の散漫」を引き起こす原因です。
ayghri/i-have-adhd は、このレスポンス構造を強制的に矯正します。 AIに対して「余計な挨拶を省け」「まず結論(変更内容)を箇条書きにしろ」「コードブロックを最後にするな」といった、極めて厳格な出力ルールを課します。 これにより、開発者はレスポンスが始まった瞬間に「何が変わったか」を理解し、すぐに動作確認に移れるようになります。 実務レベルでは、1回のターンバック(指示から回答まで)の認知負荷が50%以上削減される感覚があります。
実際の使い方
インストール
このツールはライブラリというよりは、エージェントへの「命令セット(スキル)」です。
ClineのようなMCP(Model Context Protocol)対応ツールや、Cursorの.cursorrulesに組み込んで使用します。
GitHubからプロンプトの定義を取得し、エージェントの設定ファイルに追加するだけで導入は完了します。 pipで何かを入れる必要はなく、設定の書き換えだけで済むため、動作確認までは慣れていれば2分もかかりません。
基本的な使用例
エージェントのシステム指示(Custom Instructions)に以下のエッセンスを組み込みます。公式のREADMEに基づいた、最も効果的な「指示の型」は以下の通りです。
# Role: ADHD-Friendly Coding Assistant
## Response Rules:
1. NO conversational filler (e.g., "I understand", "Sure").
2. Start with a 1-sentence TL;DR of the change.
3. List changes in a concise bulleted list.
4. Provide the code blocks immediately after the list.
5. Keep explanations to a minimum (max 2 sentences per block).
この指示を、例えばClineの settings.json や、プロジェクト直下の .cursorrules に貼り付けます。
これにより、AIの出力が劇的に変化します。
応用: 実務で使うなら
私はこれをさらに拡張し、大規模なPythonプロジェクト(FastAPI + SQLAlchemy)の既存コードベースに適用しています。 特に効果が高いのは、リファクタリング時です。
{
"mcpServers": {
"i-have-adhd": {
"command": "npx",
"args": ["-y", "@ayghri/i-have-adhd-mcp"],
"env": {
"STRICT_MODE": "true",
"LOG_LEVEL": "info"
}
}
}
}
実務でのカスタマイズポイントは、出力の最後に「次に実行すべきコマンド」を1行だけ書かせることです。
例えば「pytest tests/test_auth.py を実行して確認してください」といった具合です。
これにより、思考を停止させることなく「AIの回答を読む → コマンドをコピーする → 実行する」というワークフローが高速に回転します。
20件以上の機械学習案件をこなしてきた経験から言わせてもらえば、AIエージェントの最大の敵は「待ち時間」ではなく「情報のオーバーロードによる集中力の切断」です。 このツールは、その切断を物理的に防いでくれます。
強みと弱み
強み:
- 圧倒的な視認性: 出力が構造化されるため、スクロールせずに修正箇所を特定できる。
- トークンコストの削減: 無駄な挨拶や解説がなくなることで、1リクエストあたり50〜200トークン程度を節約。月間数千回のやり取りをするなら無視できない金額(約$10〜$30程度)の差になる。
- 実装漏れの防止: 変更点が箇条書きで強制されるため、AIが「言ったのに直していない」というミスに気づきやすくなる。
弱み:
- 初心者の学習には不向き: なぜそのコードになったかの詳細な解説が削られるため、学習目的でAIを使っている人には不親切。
- モデルの性能に依存: 小規模なLLM(Llama 3 8Bクラスなど)だと、制約が強すぎて逆に指示を無視したり、出力が崩れたりすることがある。Claude 3.5 SonnetやGPT-4oクラスでの運用が前提。
- 日本語環境での微調整が必要: デフォルトは英語ベースの指示なので、日本語で回答させたい場合は「日本語で簡潔に」という指示を別途加える必要がある。
代替ツールとの比較
| 項目 | ayghri/i-have-adhd | Cursor標準(Rulesなし) | Aider (Architect mode) |
|---|---|---|---|
| 冗長性 | 極めて低い(核心のみ) | 高い(丁寧すぎる) | 中程度(技術的) |
| 導入コスト | 低(プロンプト貼付のみ) | なし | 中(CLI操作習得) |
| 認知負荷 | 最小 | 高い | 低い |
| 適した場面 | 爆速開発・デバッグ | 学習・初めての導入 | ターミナル完結の開発 |
「Aider」は非常に優れた代替ツールですが、GUI(Cursor等)で開発したい人には i-have-adhd のようなプロンプト制御の方が取り回しが良いでしょう。
一方で、完全にチャットを排除したいならAiderの方が向いています。
料金・必要スペック・導入前の注意点
このツール自体はOSSであり、GitHubから無料で利用可能です。 商用利用についても、プロンプトの概念であるため制限はありません。
必要スペックとしては、ローカルLLMで運用する場合、最低でも RTX 4070 Ti(VRAM 12GB以上) クラスが必要です。 Llama 3 70Bクラスをサクサク動かしてこの指示を守らせるなら、RTX 4090 24GB が理想的です。 VRAMが足りないと、推論速度が落ちてしまい、せっかく出力を短くしても「トータルの待ち時間」が増えて本末転倒になります。
また、Macユーザーであれば、メモリ32GB以上のM2/M3チップ搭載モデル(MacBook Pro等)であれば、LM StudioやOllama経由で快適に動作します。 もしこれから環境を整えるなら、Mac miniの32GB/64GB盛り を検証用サーバーにするのが、コストパフォーマンスと静音性の面で最も賢い選択です。
私の評価
私の評価は ★4.8 です。 「AIを道具として使い倒す」エンジニアにとって、これほど「分かっている」ツールはありません。 エンジニアの生産性は「フロー状態」をいかに維持するかにかかっています。 AIの冗長なレスポンスを待つ数秒間、そしてそれを読み飛ばす数秒間が、私たちの集中力を少しずつ削っている事実に気づくべきです。
万人におすすめするわけではありません。 「AIに優しく導いてほしい」という人には不要です。 しかし、「俺の書いた仕様通りに、さっさとコードだけ出せ」と思っている実務家にとっては、今日から導入すべき神ツールです。
よくある質問
Q1: 既存のプロンプトエンジニアリングと何が違うのですか?
個別のテクニックではなく、「ADHD(注意欠陥・多動性障害)」という特性を逆手に取り、認知リソースを無駄にしないための「出力レイアウト」に特化している点がユニークです。単に「短くして」と言うよりも、構造が安定します。
Q2: 日本語でプロンプトを書いても効果はありますか?
効果はありますが、LLMの特性上、指示自体は英語で行い、最後に「Response in Japanese」と付け加えるのが最も命令遵守率が高くなります。英語の方がトークンあたりの密度が高く、モデルの制御が効きやすいためです。
Q3: 対応しているエージェントツールはどれですか?
Cursor, Cline (Claude Dev), Aider, Windsurfなど、システムプロンプトやカスタムインストラクションを編集できるツールであればすべて対応可能です。MCPサーバーとして導入すれば、さらに強力な制御が可能になります。






