ADHD：並列発散推論でコーディングエージェントの「早すぎる収束」を直す

エージェントに自由記述型の問題を出すと、決まった弱点が出ます。最初にもっともらしく見えた案に飛びつき、そのまま 1 本道で書き進めてしまうのです。README に分かりやすい実例があります。ある CLI が LLM を呼び出すと、ときどき 90 秒ほど固まる。そこで「retry と timeout の戦略を設計して」とエージェントに頼む。単発のエージェントは、とても標準的な答えを返します。最初のトークンまで 15 秒、トークン間 30 秒、絶対上限 90 秒、加えて自動リトライを 1 回、Google SRE 本の 22 章を引用しながら。文句のつけようはありません。ただ最後まで、こう問うことはありません。そもそもこの問題でモデルを選び間違えていないか、遅い呼び出しはリトライではなく、もっと速いモデルで再実行すべきではないか、と。

ADHD はこの 1 手を補うためのオープンソース skill です。npm パッケージ adhd-agent、MIT ライセンスで、Claude と Codex の Agent SDK 上に作られています。やることは、1 つの問題を互いに隔離した複数の認知フレームで並列に発散させて数十個のアイデアにし、別の critic 呼び出しで採点・クラスタリング・罠の剪定・有望なものの深掘りをすることです。このローカル LLM シリーズの中では少し特殊な役回りで、「モデルをどこで動かすか」ではなく「重要な判断点でエージェントが十分に広く考えられているか」を扱います。

まず結論：直すのは「早すぎる収束」

早すぎる収束（premature convergence）は自己回帰モデルの構造的な問題です。モデルはトークンを 1 つずつ生成し、新しいトークンはすでに書いた内容に引きずられます。だから最初に出る案は、学習データの中でもっとも典型的で教科書的なものになりがちです。その答えはたいてい間違ってはいませんが、たいてい新しさもなく、さらに厄介なことに、見慣れているせいで正しく見えるだけの罠であることが多いのです。

これが本当に問題になるのはどんなときでしょうか。ストレージ階層・シャーディング・認可モデル・キュー構成のようなアーキテクチャ判断のとき、関数・プロダクト・環境変数に名前を付けるとき、原因がはっきりしない曖昧なバグに対してまず仮説のクラスを並べるときです。共通点は、答えが一意でないことです。そして目立たないが実行可能な選択肢を逃すと、数か月後の作り直しという代償になりかねません。

逆に、答えがはっきりしていることに使ってはいけません。API の呼び方を調べる、すでに原因を特定したバグを直す、ひと検索で答えが出ることに使うのは、金と時間の無駄です。一言で線を引くなら、ジュニアが Google で見つけられることは baseline に任せ、シニアが「これは少し違う角度で考えたい」と立ち止まる瞬間こそ ADHD の出番です。

仕組み：2 つのフェーズの間に硬い壁がある

ADHD の核心は 2 フェーズのループで、その間に硬い隔離があります。作者は、発散と評価を混ぜることこそアイデアの質を壊す原因だと繰り返し強調します。評価がその場で生成を絞め殺してしまうからです。

Railway - モダンなデプロイプラットフォーム、煩わしい運用から解放、数分で公開

今すぐ始める →広告

発散：互いに見えない隔離ブランチ

第 1 フェーズでは N 個の認知フレームを選び、N 本の Agent SDK 呼び出しを並行で起動します。それぞれが新しいステートレスなセッションです。各ブランチが見えるのは 3 つだけです。元の問題、ある 1 つのフレームの視点プロンプト、そして評価とランク付けを禁じる system prompt。肝心なのは、ブランチ同士が互いに見えないことです。「規制当局」の視点を担うブランチは、「スピードランナー」のブランチが何を書いたかを読みません。共有コンテキストがないので、アンカリングはプロンプトで抑え込むのではなく、構造上そもそも存在しません。

収束：1 回だけの独立した critic 呼び出し

第 2 フェーズで初めて critic が動き、3 つのことをします。まず採点で、各アイデアの新規性・実現性・適合度を 0〜10 で付け、罠には「shelve はマルチライターの状況ではスレッドセーフではない」のように仕組みに即した理由を添えます。「リスクがある」と曖昧に書くのではありません。次にクラスタリングで、表面的なキーワードではなく根っこの角度でまとめ、設計空間全体の形を見えるようにします。最後に上位 K 個（デフォルトは 3）の深掘りで、スケッチ、要となるリスク、最初の一歩、3〜5 個の子アイデアを出します。

ここに見落としやすい設計があります。generator と critic の分離は機械的で、2 回の異なる API 呼び出しに 2 つの正反対の system prompt を組み合わせて実現します。同じプロンプトの中でモデルに「まず発散してから収束して」と口頭で頼むのではありません。隔離ブランチの呼び出しの形は、おおよそ次のようになります。

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 ?? ""}`,
  })))
);

トークンコストはブランチ数に対して線形に増え、二次的には膨らみません。後のブランチが前のブランチの内容を読み直さないからです。並行数はセマフォで制御し、デフォルトは 4 です。

1 回実行して得られるのは長文ではなく、構造化された結果です。クラスタリング済みのアイデア集合、2〜4 個の候補リスト、別枠で示される「目立たないが実行可能」な選択肢、理由つきの罠リスト、深掘りされたいくつかのブランチ、そして 1 つのワイルドカード的な挑発的問いです。冒頭の retry 問題に戻ると、単発は教科書的なハイブリッドを返しただけでしたが、ADHD が 30 以上のアイデアから拾ったのは「待つほどボタンが熱くなり、ワンクリックでキャンセルして、より速い Haiku 系モデルへ投げ直す」という案でした。同時に「トークンを逆順でストリーミング」「待った分だけ課金」のような、面白そうでも実は罠のアイデアを、実装に手を出す前に印を付けて外しています。

Chain-of-Thought や Tree-of-Thought との違い

この 3 つはもっとも混同されやすいのですが、構造はまったく違います。

本質的な違いは 3 つです。第 1 に、探索ではなく隔離だということ。CoT と ToT のブランチは 1 つのコンテキストウィンドウを共有するので、4 ステップ目にはモデルは最初の 3 ステップにアンカーされています。ADHD のブランチは発散中に互いを見ないので、アンカリングは構造上消えます。第 2 に、変えるのは次の一手ではなくフレームだということ。ToT のブランチはふつう次の動作を変えますが（この数を試す、あの数を試す）、ADHD は問題全体の視点を変えます。「この問題をハードウェアの問題として問い直す」ようなもので、近いバリエーションではなく構造的に異なるアイデアが出ます。第 3 に、generator と critic の分離が約束ではなく機械的だということです。

1 つ補足します。ADHD 自体が Tree-of-Thought の一種で、深掘りフェーズは確かに上位 K のノードを展開します。新しいのは、ブランチをフレームで駆動する点と、評価の分離を本当に 2 回の呼び出しで担保する点です。

Vultr - 高性能NVMeクラウドサーバー、世界32拠点、Dockerワンクリック展開対応

価格を見る →広告

フレームとは：問題全体の視点を入れ替える

フレームはロールプレイではありません。視点オペレーターであり、問題全体をある認知的な立場から問い直す system prompt です。「あなたは 34 歳のエンジニア、田中さんです」といった persona プロンプトの研究とは違い、フレームはモデルに誰かを演じさせるのではなく、自然には漂っていかない思考の隅へ追い込みます。

プロジェクトには 15 個のフレームが組み込まれていて、codeMode（デフォルトでオン）ではエンジニアリング寄りの視点に偏ります。具体的にいくつか挙げます。ハードウェアエンジニアは遅延・メモリ配置・物理的制約で考えます。深夜 3 時のオンコールは「どんな設計なら呼び出されずに済むか」を考えます。要となる前提を外すフレームは「フレームワーク・データベース・ネットワークが全部なかったら、どうするか」を問います。実行ごとにシードで決定的にフレームを選び、必ず 1 枠を wild slot として残すので、発散が整いすぎません。

領域をまたぐフレームは、移植可能なアイデアを引き出すのに特に効きます。生物学は免疫系・神経可塑性・細胞シグナルで例えます。物流はキュー・バッチ処理・ジャストインタイム・ハブアンドスポークで考えます。ゲームデザインはループ・報酬・摩擦・セーブポイント・スピードラン技で考えます。自由記述型の問題の本当に良い答えは、たいてい単一領域の定石の外にあり、別の場所の仕組みを持ち込む必要があります。領域横断フレームがあるのは、まさにそのためです。

自分でフレームを書くなら、だいたい 5 行のコードで足ります。良いフレームは 3 つのうち少なくとも 2 つを満たします。他のフレームが使わない独自の語彙があること、他の視点とは異なる姿勢（対立的・建設的・素朴・極端）があること、そして他のフレームには出せないアイデアを安定して引き出せること。領域名を入れ替えただけで中身が同じなら、合格ではありません。

いつ使うか、いつ使わないか

これはキーを打つたびの道具ではなく、判断点の道具です。下の表はそのまま判断に使えます。

コストは把握しておきます。デフォルトの 1 回はおよそ 10 回の LLM 呼び出しです。発散がデフォルト 5 回、採点 1 回、クラスタリング 1 回、深掘り 3 回で、全体としては単発の 5〜10 倍、実時間は 30〜90 秒です。作者の位置づけは実践的です。5 万ドルのアーキテクチャ判断を広げるために 0.3 ドル程度を使う、キーを打つたびに走らせず、判断点で走らせる、と。もう 1 つ現実的な注意があります。大きな CLAUDE.md とツールコンテキストを抱えた Claude Code セッションでは、各ブランチがこの基盤コンテキストを読み直すので、実際のトークンは「ブランチ数 × （基盤 + ブランチ）」に近づき、純粋なアルゴリズム上のコストより高くなります。

インストールと起動

インストールは 1 つのコマンドで、Claude Code、Cursor、Antigravity、Codex、Cline、Gemini CLI、Windsurf など約 50 種のエージェントを自動判別します。

KiloClaw - 企業向けマネージド OpenClaw、AI エージェントのオーケストレーションとスマートルーティングを加速

今すぐ始める →広告

npx skills add UditAkhourii/adhd

入れたら /adhd "あなたの問題" で明示的に起動するか、発想系の意図で自動起動させます。Codex には独自の探索パスがあるので、共通コマンドが登録できないときはターゲットを明示します。

npx skills add UditAkhourii/adhd -a codex -g

SKILL.md を Codex の skill ディレクトリ ~/.codex/skills/adhd/ に手動でコピーしてもよく、再起動すれば /adhd "design a rate limiter" がこの skill を通ります。CLI とライブラリの使い方もあります。CLI は npm install -g adhd-agent、ライブラリとして使うなら npm install adhd-agent です。

サードパーティの skill を入れる前に、その SKILL.md がエージェントに何をさせるか、特に外部コマンドを呼ぶかどうかを一度見ておくとよいです。これは OpenClaw スキルセキュリティレビュー実践ガイド が参考になります。権限の境界に 5 分かけるほうが、後始末より割に合います。

ローカルモデルについては正直に言っておきます。ADHD は Agent SDK 上に作られていてデフォルトは Claude 系モデルなので、ローカルで箱から出してすぐ使えるツールではありません。Ollama などのローカルモデルをつなぐには、呼び出し層で自前のアダプタを書く必要があり、その道がスムーズだとはプロジェクト側も約束していません。これをローカル LLM シリーズに置くのは、エージェントの推論構造というレイヤーでの考え方を評価しているからで、小さなローカルモデルにそのまま渡せるという意味ではありません。

まとめ

ADHD は、判断点で取り出して使う道具として捉えます。ワークフロー全体を乗っ取らせるものではありません。価値があるのは「たくさん考える」ことではなく、「違う考え方をする」ことと、罠を名指しする独立した評価が入ることです。すでに答えを持っているアーキテクチャ判断で一度走らせ、返ってきた目立たない選択肢を自分の案と比べてから、エージェントのループに組み込むかどうかを決めるとよいです。

続けて読むなら、2026 年 AI プログラミングツール総ざらい でツール地図の中の位置を、DeepAgents アーキテクチャ解説 でサブエージェントと計画ツールがどう推論を組み立てるかを確認できます。