ADHD（UditAkhourii/adhd）レビュー: 共有コンテキストを断ち切る発散思考スキル

単発推論が最初の一文に固定される問題

README が掲げる出発点は明快である。線形な Chain-of-Thought は、最初に出力した方針にそのまま引きずられる。Tree-of-Thought は探索の幅を広げるが、分岐した先も同一のコンテキストを共有して歩くため、固定は分岐をまたいで残る。ADHD はこれをプロンプトの工夫ではなくアーキテクチャの問題として扱う。狙いは、もっともらしい最初の答えが、検討されなかった他の選択肢を黙って消してしまう現象を減らすことにある。想定読者は coding agent を日常的に使う開発者で、README が名指しする用途は設計判断、曖昧なデバッグ、命名、API 表面の設計、戦略、そして「いくつか案を出して」という形の依頼である。バグ修正の速度を上げる道具ではなく、選択肢の数と質を上げる道具だと考えると位置づけがぶれない。

フレームを歪ませてから隔離する、という機構

README の説明に従えば、処理は二段に分かれる。第一段で N 個の推論プロセスを、意図的に歪めた認知フレームの下で並列に起動する。このとき分岐間でコンテキストを共有しない。共有しないことが要点で、共有すれば元の固定がそのまま再現されてしまう。第二段は critic による別パスで、候補を採点し、クラスタにまとめ、罠を枝刈りし、生き残った案を深掘りする。README の例では 6 フレームを起動し、economic-incentive、async-control-surface、gamification、perceptual-distortion、collective-intelligence、redundancy-race といったクラスタにまたがる 30 以上のアイデアを出し、理由付きで 20 の罠を flag したと記述されている。ここで注意したいのは、枝刈りが独立した評価パスとして設計されている点だ。発散と選別を別工程に分けることで、生成側の勢いが選別を甘くするのを避けようとしている。

公開されている評価の読み方

README には CLI が 90 秒ハングする状況で retry/timeout/UX を設計させる評価問題の比較が載っている。baseline は段階的タイムアウトと 1 回の自動リトライという教科書的なハイブリッドに着地し、罠の指摘はない。ADHD 側は 6 フレームから 30 以上の案を出し、その中で「遅いモデルはこのプロンプトにとって単に間違ったモデルなのではないか」という、即時 abort と安価なモデルへの分岐という案に到達したとされる。独立した LLM judge による採点は breadth 9 対 6、novelty 8 対 3、trap detection 約 8 対約 2 と記載され、手法は documentation/evals.md、生のトランスクリプトは bench/results.json にあるとされている。ただしこれらは README が提示する数値であり、当サイトが追試したものではない。評価問題が 1 問である以上、この差が一般的なタスクに外挿できるかは別に検証が要る。

導入コマンドと対応エージェント

導入は 1 コマンドで、README によれば Claude Code、Cursor、Antigravity、Codex、Cline、Gemini CLI、Windsurf など約 50 種類のエージェントを自動検出する。

npx skills add UditAkhourii/adhd

導入後は /ad で明示的に呼び出す。Node は 18 以上が必要で、インストール手順の詳細は documentation/install.md に置かれている。npm パッケージ名は adhd-agent である。エージェント側の SDK としては Claude Agent SDK と Codex Agent SDK が土台として挙げられており、v0.1.4 のリリースノートには Codex 互換性が入ったと記録されている。設定キーの一覧は今回渡された資料には含まれておらず、フレーム数や採点の閾値をどう変えるかは documentation 側を確認する必要がある。README の範囲では、フレーム数を増やせば候補は増えるが critic の負荷も比例して増える、という構造だけが読み取れる。

向かないタスクと、コストの見えにくさ

最大の制約は、これが発散の道具であって収束の道具ではないことだ。正解が一意に決まるタスク、たとえば既存のテストを通す修正や規約に沿ったリファクタリングでは、N 本の推論を走らせる分だけトークンと待ち時間が増え、得られるものはほぼない。README 自身が「give me a few ways to…」という形の依頼を対象として名指ししており、その裏返しとして、単一の正解を求める依頼は想定外である。二つ目に、critic の採点が最終的な選別の質を決める。採点が浅ければ罠の枝刈りも浅くなり、候補の多さがそのままノイズになる。三つ目に、並列フレームはコンテキストを共有しない設計なので、プロジェクト固有の制約や既存の設計方針を各フレームに与えないと、実装不可能な案が並ぶことになる。README の評価例でも、非自明な採用案はフレーム側から出ており、critic が事実を作り出しているわけではない。

代替手法との違い: 共有コンテキストを残すか切るか

比較対象として素直なのは Tree-of-Thought である。どちらも複数の推論経路を走らせる点は同じだが、Tree-of-Thought は分岐後も同一のコンテキストを歩く。ADHD は発散の段階でコンテキストを共有しないことを設計の中心に置き、その代わりに採点と枝刈りを独立した critic パスへ追い出す。つまり探索の木を広げるのではなく、互いに見えない島を複数作ってから橋を架ける順序になる。この違いは、既存の方針に沿わせたいタスクでは不利に働く。共有コンテキストを保つ手法のほうが、規約や前提を自然に引き継げるからだ。逆に、前提そのものを疑うべき場面では、共有を切る設計のほうが最初の一文への固定を避けやすい。どちらが優れているかではなく、前提を引き継ぐべきか疑うべきかの違いである。

ライセンスと維持コストの見取り

ライセンスは MIT で、リポジトリの LICENSE に置かれている。MIT は商用利用や改変、再配布を許す条件の緩いライセンスだが、無保証である点は他の MIT プロジェクトと同じで、法的な判断は利用側の責任になる。ここは法的助言ではなく、表記の確認にとどめる。維持の面では、最新の記録されたリリースが v0.1.4 であり、バージョン番号から見て API 表面はまだ固まっていない段階と読める。土台に Claude Agent SDK と Codex Agent SDK を置いているため、これらの SDK 側の変更がそのまま影響しうる。ADOPTERS.md に導入事例の表があり、採用プロジェクトが自ら PR を出す運用が案内されているので、追従の状況はそこである程度たどれる。ただし採用事例の数は成熟度の証拠にはならない。確認すべきは、自分のエージェントが npx skills add の自動検出に載るか、そして bench/results.json の評価が自分のタスク形状と噛み合うかである。

編集部の結論

採用を検討すべきなのは、設計判断や命名、API 表面の設計、曖昧なデバッグのように、正解が一つに定まらず候補の広さそのものが価値になる作業を日常的に抱えているチームだ。逆に、既存コードの規約に沿った定型的な修正や、テストが通るかどうかで正誤が決まるタスクでは、N 本の推論を走らせる分だけコストと待ち時間が増える。導入前に確認すべきは、npx skills add UditAkhourii/adhd が自分のエージェントを検出するか、そして bench/results.json と documentation/evals.md に書かれた評価が自分のタスク形状に当てはまるかどうかである。判断は README の主張ではなく、自分のリポジトリで 1 問走らせた結果で行うのが妥当だ。

公式情報源

1. License: MIT
2. Project website
3. README
4. Releases
5. UditAkhourii/adhd on GitHub