AIの饒舌さに終止符を打つ「i-have-adhd」の衝撃
我々エンジニアにとって、AIエージェントの「丁寧すぎる回答」は、時にデッドロックのような苛立ちを覚える瞬間がある。コードの修正を求めているのに、前置きで「素晴らしい質問ですね」と称賛され、末尾には「お役に立てれば幸いです」という定型文が添えられる。この「AIの礼儀」は、コンテキストウィンドウを無駄に消費し、我々の集中力を削ぐノイズでしかない。そんな中、GitHubで3万スターを獲得した『ayghri/i-have-adhd』というClaude Code用スキルが、この饒舌なAIを黙らせる特効薬として注目を集めている。
このスキルは、単なる設定ファイルではない。SKILL.mdというわずか140行の定義ファイルのみで構成された、極めて軽量な「行動変容エージェント」だ。特筆すべきは、その設計思想である。このスキルは常駐プロセスを持たず、/i-have-adhdと明示的に呼び出した瞬間から、セッション終了まで「前置き・要約・締めの挨拶」を徹底的に排除する。まるで、深夜の障害対応中に「余計なことはいいから、ログの該当箇所だけ出せ」と叫ぶシニアエンジニアの要求を、そのままシステムに実装したかのような潔さがある。
検証データによれば、このスキルを導入することで、出力文字数は平均して1,884文字から1,066文字へと、実に43%もの削減を達成した。出力トークン数で見ても34%の削減だ。これは単なる「短縮」ではない。AIの思考プロセスから「社交辞令」というオーバーヘッドを削ぎ落とし、純粋な情報密度を高めるという、エンジニアリングにおける最適化そのものだ。しかし、ここで我々が直面すべきは「情報量のトレードオフ」という現実である。検証では、技術キーワードの出現数も減少傾向にあることが確認されている。つまり、AIは「短く答える」ために、文脈を補完する説明や、時に有用なオプションの提示さえも切り捨てている可能性があるのだ。
数値で見る最適化の代償と実務への影響
今回の検証で最も興味深いのは、単に文字数が減ったことではなく、回答の「密度」が劇的に変化した点だ。Q3のDockerイメージ削減に関する質問では、1,000文字あたりの技術キーワード密度が3.2個から6.6個へと約2倍に跳ね上がっている。これは、AIが冗長な説明を削った結果、本質的なコマンドやパラメータの提示にリソースを集中させたことを意味する。しかし、一方で「中身の入れ替わり」も発生している。例えば、gitのコミットメッセージ修正において、--onlyオプションのような有用な情報が削られ、代わりにトレーラーの削除に関する注意が優先されるといった現象だ。これは、AIの出力が「ユーザーの意図」をどう解釈するかという、確率的な挙動の揺らぎを如実に示している。
以下の表は、検証環境における出力文字数の削減効果をまとめたものである。この数値は、AIエージェントを実務に組み込む際の「コスト対効果」を考える上で、極めて重要なベンチマークとなるだろう。
| 項目 | 対照（通常） | スキルあり | 削減率 |
|---|---|---|---|
| Q1: git修正 | 643字 | 348字 | -46% |
| Q2: CSV集計 | 2,163字 | 1,593字 | -26% |
| Q3: Docker削減 | 2,847字 | 1,256字 | -56% |
| 平均 | 1,884字 | 1,066字 | -43% |
導入コストがほぼゼロ（トークン消費への影響が無視できるレベル）である点は、開発者にとって非常に魅力的だ。しかし、スキル一覧の予算制限により、呼び出し頻度が低いスキルの説明文が自動的に切り捨てられるという仕様には注意が必要だ。disable-model-invocation: trueの設定により、明示的な呼び出しが必要な設計になっているため、誤爆のリスクは低いが、逆に言えば「必要な時に呼び出す」という運用フローをチーム全体で共有しなければ、このスキルの恩恵を享受することはできない。AIを単なるツールとして使うのではなく、自分の開発スタイルに合わせて「調教」する。この感覚こそが、これからのシニアエンジニアに求められるスキルセットではないだろうか。
AIエージェント時代に問われる「エンジニアの判断力」
今回の検証を通じて浮き彫りになったのは、AIの出力制御がいかに「諸刃の剣」であるかという事実だ。43%の短縮は、確かに生産性を向上させる。しかし、それは「網羅性」という安全装置を外すことと引き換えである。もし、AIが提示した短い回答の中に、致命的なセキュリティリスクや、非効率な実装が含まれていたとしたらどうだろうか。我々エンジニアは、AIが生成した「高密度な回答」を鵜呑みにせず、その背後にある意図や、削ぎ落とされた文脈を読み解く能力を、これまで以上に研ぎ澄まさなければならない。
今後、Claude CodeのようなAIエージェントは、単なるコード生成ツールから、開発チームの一員へと進化していくだろう。その時、我々が直面するのは「AIに何をさせるか」という問い以上に、「AIに何をさせないか」という境界線の設計である。i-have-adhdのようなスキルは、その境界線を定義するための第一歩に過ぎない。明日からあなたが取るべき対策は、単にこのスキルを導入することではない。自分の開発フローにおいて、どの程度の冗長性が許容され、どの程度の密度が最適なのかを、自身のプロジェクトで計測することだ。AIの回答が長すぎることに不満を抱くのは簡単だが、その不満を「設定」というコードに落とし込み、チームの標準として定着させられるか。それが、AI時代におけるエンジニアの真の価値ではないだろうか。あなたは、AIという「饒舌な部下」を、自分の意のままに操る準備ができているだろうか？
コメント