ADHD：Coding Agent に Tree-of-Thought 型の並列推論エンジンを載せる

CLI から LLM を呼び出すと、ときどき 90 秒ほど固まる。retry と timeout はどう設計すべきでしょうか。教科書的な答えなら、指数バックオフに jitter を足し、絶対 timeout を置き、1 回だけ自動 retry する、となります。間違いではありません。ただ、もっと鋭い問いが残ります。遅いのは本当にネットワークなのか。それとも、そもそも選んだモデルが違うのか。待ち時間が長くなるほどボタンの緊急度を上げ、ワンクリックでより速いモデルへ切り替えるべきではないのか。

ADHD が扱うのは、この種類の問題です。Agent に「もう一度考えて」と言う prompt ではありません。AI コーディングエージェント向けの並列推論構造です。複数の隔離された分岐が異なる認知視点から同時に発散し、そのあと独立した critic が採点、クラスタリング、罠の枝刈り、生き残った案の深化を行います。ここでは、この skill の仕組み、境界、使うべき判断点を整理します。

ADHD とは何か（prompt テクニックではない）

ADHD の位置づけは明確です。自己回帰推論における早すぎる収束を直そうとするもので、prompt に励まし文句を足すものではありません。

自己回帰モデルは token を 1 つずつ生成します。最初の数 step である方向を選ぶと、そのあとの内容はその方向を中心に展開されます。これは効率的ですが、オープンなエンジニアリング課題では副作用があります。最初にもっともらしい答えが anchor になり、モデルはよくある、教科書的な path に滑っていきます。その答えは十分に正しいことが多い一方で、目立たないがより価値の高い選択肢を落としがちです。

普通の prompt でも、「複数案を比較して」「違う角度から考えて」「早く結論を出さないで」と言えます。問題は、それらの分岐が同じ context を共有することです。モデルは同じ空間の中で生成と評価を行います。早い段階で 1 つの方向が書かれると、後続の分岐はそこから逃げにくくなります。

ADHD はもっと硬い方法を取ります。発散フェーズを N 個の完全に隔離された Agent SDK 呼び出しに分けます。各分岐が見るのは、元の問題、1 つの認知 frame、評価を禁じる system prompt だけです。分岐同士は context を一切共有しません。その後の focus フェーズで、独立した critic 呼び出しが結果を採点、クラスタリング、枝刈り、深化します。

一言で言えば、CoT は 1 つの頭にもっとゆっくり考えさせ、Tree-of-Thought は 1 つの頭により広く探索させ、ADHD は複数の頭に並列で違う考え方をさせてから critic に選ばせます。

2 段階の仕組み：Diverge/Focus の間にある硬い壁

ADHD の核は 2 つの段階です。Phase 1 Diverge と Phase 2 Focus。両者の間には硬い壁があります。発散中は評価を禁じ、Focus に入ってから初めて収束を許します。

Phase 1 Diverge：N 本の並行・隔離分岐

第 1 段階では N 個の認知 frame を選びます。デフォルトは N=5 です。そのうえで、N 個の隔離された Agent SDK query を並列に起動します。各分岐の入力は 3 つだけです。

1. 元の問題。
2. 1 つの frame の視点 prompt。たとえば latency、memory layout、規制、on-call、反転思考から問題を問い直します。
3. 評価、ランキング、ためらいを禁じる system prompt。

分岐同士は互いに見えません。規制監査の分岐は speedrunner の分岐が何を書いたか読めません。hardware engineer の分岐も、10 歳の子どもの分岐に anchor されません。各分岐は独立した stateless session です。anchor をモデルの自制で抑えるのではなく、構造として断ち切ります。

並行数は semaphore で制御され、デフォルトは concurrency=4 です。token コストは分岐数に対して線形に増えます。つまり O(N×各分岐) であり、N² ではありません。後続の分岐が先行分岐の全文を読み直さないためです。

Phase 2 Focus：独立した critic 呼び出し

第 2 段階では、独立した critic 呼び出しに切り替わります。やることは 3 つです。

1. score：各分岐の novelty、viability、fit を 0〜10 で評価し、罠には仕組みレベルの理由を付けます。
2. cluster：表面的な keyword ではなく、根底にある角度で案をグループ化します。
3. deepen top-K：デフォルト K=3 の生き残り案を深掘りし、スケッチ、重要リスク、最初の行動、3〜5 個のサブアイデアを補います。

重要なのは、generator と critic の分離が機械的であることです。generator フェーズでは評価してはいけません。critic フェーズでは評価しなければなりません。これは 1 つの会話内の 2 つの約束ではなく、異なる system prompt と反対の姿勢を持つ 2 回の API 呼び出しです。

隔離分岐の呼び出し形は、おおよそ次のようになります。

const branches = await Promise.all(
  frames.map((frame) =>
    withSemaphore(concurrency, () =>
      callLLM({
        systemPrompt: `${frame.vantage}\n\nFORBIDDEN: evaluation, ranking, hedging. JSON array out.`,
        userPrompt: `${problem}\n\n${context ?? ""}`,
      }),
    ),
  ),
);

冒頭の retry/timeout の例に戻ります。baseline は、15 秒の first-token timeout、30 秒の inter-token timeout、90 秒の hard cap、1 回の自動 retry という標準的な hybrid を出しがちです。ADHD の価値は、この答えを長くすることではありません。「待ち時間が長くなるほどボタンを熱く見せ、キャンセルして速いモデルで再実行できるようにする」といった案を追加で拾い、「token を逆順に stream する」「忍耐力で課金する」といった面白いが危険な案を、実装前に落とせることです。

CoT/ToT との構造比較

次元	Chain-of-Thought (CoT)	Tree-of-Thought (ToT)	ADHD
thread 数	1 本の線	1 本の探索木	N 本の並列・隔離分岐
共有 context	yes、全体を共有	yes、多くは一部共有	no、硬く隔離
generator/critic	同じ context 内で同時に評価	同じ model が生成と評価を交互に行う	段階も呼び出しも分離し、姿勢も逆
分岐の駆動	明示的な分岐なし	次の一手の変形	認知 frame が問題全体を問い直す
並行性	なし	多くは順次	semaphore 制御の実並行
向く問題	多段論理、数学推論	探索、計画、パズル	オープンなエンジニアリング設計と構想

3 つの重要な違い

第 1 に、ADHD は探索ではなく隔離です。ToT の分岐は同じ木の中で展開されるため、早期 node が後続 node に影響します。ADHD の分岐は発散中に互いを見ないので、anchor は構造上取り除かれます。

第 2 に、ADHD は next-step variant ではなく frame を使います。ToT は多くの場合、「次に何をするか」を広げます。ADHD は別の認知位置から問題全体を問い直します。少し parameter を変えるのではなく、latency、物理制約、規制責任、午前 3 時の on-call 圧力から見直します。

第 3 に、generator-critic の分離は約束ではなく機械的なものです。同じ context の中で「まだ評価しないで」と言っても、モデルは生成中にこっそり比較できます。ADHD は異なる呼び出し、異なる system prompt、異なる姿勢でこの作業を分けます。

もう 1 点、frame は persona ではありません。persona は「あなたはこのような人物です」と言います。frame は「この制約と語彙で問題を問い直してください」と言います。前者は肩書きを変え、後者は問題の枠組みを変えます。

15 個の認知 frame とカスタマイズ方法

ADHD には 15 個の認知 frame が内蔵されており、同じ問題を異なる方向に曲げます。codeMode はデフォルトで code/design 寄りの視点を選び、各回に 1 つの wild slot を残すため、発散が整いすぎません。

内蔵 frame の例

frame	視点
Hardware engineer	latency、memory layout、物理制約から考える
Regulatory audit	compliance、risk、説明責任から考える
10-year-old child	平易な言葉と単純な論理で考える
Competitor trying to break it	脆弱性や弱点を攻撃者目線で考える
Biology	進化、生態系、代謝制約から考える
Logistics	supply chain、倉庫、輸送制約から考える
Game design	player experience、balance、feedback loop から考える
Market	pricing、competition、positioning から考える
Inversion	望む結果から逆算する
$0 or infinite budget	極端な予算制約で考える
Remove load-bearing assumptions	当たり前だと思っている前提を外す
Speedrunner	最小 step で目標に到達する
Ant colony	分散型で中心を持たない協調として考える
3 a.m. on-call	緊急、疲労、限られた資源の下で考える
wild slot	ランダムな視点を 1 つ残す

選択ルール

• 同じ問題と同じ seed なら、同じ frame set が選ばれます。再現しやすくなります。
• codeMode はデフォルトで code/design frame を優先するため、エンジニアリング課題が関係の薄い比喩だけに渡されることはありません。
• 毎回 1 つの wild slot を残し、整いすぎた frame set から抜ける機会を作ります。

custom frame

custom frame は長く書く必要はありません。必要なのは、問題の見方を本当に変えることです。よい frame は、次の 3 条件のうち少なくとも 2 つを満たします。

1. 独自の語彙を持つ。「多角的に考える」だけでは足りません。
2. 独自の姿勢を持つ。対抗的、建設的、素朴、極端な制約などです。
3. 再現可能な歪みを持つ。毎回、推論方向を安定して変えられます。

たとえば subscription product 向けには、次のような frame が書けます。

name: subscription_retention
vocabulary: ["subscription", "retention", "churn", "renewal", "lifecycle"]
stance: "Think in terms of subscription churn and lifetime value, not one-time transactions"
distortion: "Assume users will churn; design mechanisms that reduce churn"

これは単にモデルへ「growth lead」と名乗らせるものではありません。retention、churn、lifetime value という制約に問題を押し込みます。

使うべき場面、使わない場面

ADHD は判断点のための道具であり、毎回の補完に使うものではありません。簡単な判定があります。junior developer が Google で解けるなら baseline の勝ち。senior developer が「別の角度から少し考えたい」と止まる場面なら、ADHD の出番です。

向いている場面

場面	向いている理由
アーキテクチャ/設計判断	コストが高く、多角的な検討が必要で、罠を見落としやすい
API/SDK/CLI インターフェース設計	ユーザーの mental model が複数ある
命名	役割によって言葉の解釈が変わる
曖昧なデバッグ	根本原因が不明で、検証前に仮説生成が必要
移行・リファクタリング計画	performance、security、compatibility、展開速度が衝突する
code review の視点拡張	異なる reviewer の関心を疑似的に取り入れたい
戦略・pricing	business 制約は対抗視点や market frame と相性がよい

向いていない場面

場面	向いていない理由
事実確認	正解が 1 つで、発散は不要
原因がわかっている bug 修正	因果関係が明確で、発散は修正を遅らせる
検索すればすぐわかる答え	baseline のほうが速く安い
内側ループ/逐次補完	30〜90 秒の遅延は受け入れにくい
正解が 1 つの問題	分岐を増やしても有効情報は増えにくい

インストールと起動

インストール前に第三者 skill を確認してください。最低限、SKILL.md を読みます。Agent に何をさせるのか、外部コマンドを実行できるのか、触ってほしくない directory に触れる可能性があるのかを見ます。確認観点は OpenClaw スキル安全レビュー実践ガイド が参考になります。

汎用インストール

汎用インストールコマンドは次のとおりです。

npx skills add UditAkhourii/adhd

Claude Code、Cursor、Antigravity、Codex、Cline、Gemini CLI、Windsurf など約 50 種類の Agent を自動認識し、対応する skill file をインストールします。

Codex 専用インストール

汎用コマンドで Codex に登録されない場合は、target を明示します。

npx skills add UditAkhourii/adhd -a codex -g

手動インストールもできます。

curl -o ~/.codex/skills/adhd/SKILL.md https://raw.githubusercontent.com/UditAkhourii/adhd/main/SKILL.md

手動で入れたあとは、Codex を再起動して skill directory を再読み込みします。

起動方法

起動は次の形式です。

/adhd "問題"

例：

/adhd "CLI から LLM を呼び出すと、ときどき 90 秒固まる。retry/timeout/UX はどう設計すべき？"

毎回の補完に組み込まないでください。よりよい使い方は、アーキテクチャ、インターフェース設計、命名、曖昧なデバッグの判断点で明示的に起動することです。

コストと価値

コストデータ

次元	データ
LLM 呼び出し回数	約 10 回：N=5 の発散 + 1 回の採点 + 1 回のクラスタリング + K=3 の深化
時間	通常 30〜90 秒
コスト倍率	単発の 5〜10 倍
token コスト	O(N×各分岐)、線形増加であり N² ではない

価値の位置づけ

プロジェクト側の位置づけは、0.30 ドル程度を使って 5 万ドル級のアーキテクチャ判断を支える、というものです。これは小さな疑問すべてに ADHD を走らせるべきだという意味ではありません。オープンなエンジニアリング判断を間違えたときのコストは、1 回の多分岐推論よりずっと高くなり得る、という注意喚起です。

実プロジェクトでは context コストも効きます。Claude Code や類似の Agent session では、各分岐が基礎 project context、tool instructions、repository rules を読み直すことがあります。純粋な algorithm としては O(N×各分岐) ですが、実際の請求感は N×(base context + branch work) に近づきます。だからこそ、これは「次の 1 行は何か」ではなく、「この設計でよいのか」に使う道具です。

eval 結果の読み方

ADHD プロジェクトは自己評価を公開しています。6 つのオープンなエンジニアリング課題、同一 model、独立した LLM 評価、A/B 順序はランダムです。この範囲は見えるようにしておくべきです。第三者の学術 benchmark でも、人間評価でもありません。

5 軸の比較表

次元	ADHD	baseline	向上
breadth（案の広さ）	9.00	4.83	1.9x
novelty（新規性）	7.83	2.67	2.9x
trap detection（罠の発見）	9.50	1.83	5.2x
actionability（実行可能性）	9.50	6.50	1.5x
builder usefulness（builder にとっての有用性）	7.67	6.83	1.1x

評価条件の注意

この数字は方向を見るには役立ちますが、権威ある benchmark として扱うものではありません。「ADHD があらゆる推論戦略に勝つ」とは言えません。より狭く読むなら、オープンなエンジニアリング prompt では、隔離発散と独立 critic によって、案の広さ、新規性、罠の発見が目に見えて変わり得る、ということです。

そのため、「業界 benchmark で首位」といった書き方は避けるべきです。より安全なのは、「プロジェクト自己評価では 6 つのオープンなエンジニアリング課題のうち 5 つで ADHD が勝ち、特に trap detection の差が大きかった」と書くこと。事実の境界を守れば、読者はその数字の重みを自分で判断できます。

まとめ

ADHD が面白いのは、答えを長くするからではありません。「違う考え方をする」を構造にしているからです。分岐は隔離され、frame は問題を問い直し、独立した critic が結果を枝刈りします。この構造は、オープンなエンジニアリング課題で Coding Agent が抱えがちな弱点、つまり最初にそれらしく見える答えへ早く収束しすぎる問題と噛み合います。

毎回の補完ではなく、判断点で使ってください。アーキテクチャ、インターフェース、命名、移行、曖昧なデバッグには 30〜90 秒を足す価値があります。事実確認、原因がわかっている bug、1 行の boilerplate は baseline のほうが向いています。

AI コーディング toolchain を整理しているなら、2026 年 AI コーディングツール全体像 でこの種の skill の位置づけを確認できます。より長い推論 chain をどう組み立てるかは、DeepAgents アーキテクチャ解析 も参考になります。