AIのアイデア出しを並列化するOSS「adhd-agent」の仕組み

コーディングエージェントに「このキューをどうシャーディングすべきか、案を5つ出して」と投げたことがある方なら、返ってくる答えのパターンに心当たりがあるはずです。ハッシュベース、レンジベース、コンシステントハッシュ、と教科書的な選択肢が並び、5つ目にいたっては1つ目の言い換えに近い。実装作業では頼りになるエージェントが、選択肢を広げてほしい場面に限って役に立たない、という感覚です。

これはプロンプトの書き方が下手だから起きているわけではありません。単一のコンテキスト上で逐次的にトークンを生成する限り、2つ目以降の「代替案」は必ず1つ目の答えを読んだ状態で書かれます。最初に出た案がアンカーとなり、以降の出力がそこへ引き寄せられる。構造上そうなるようにできています。

この収束を、プロンプトの工夫ではなくアーキテクチャの側で断とうとしているのが、Udit Akhouri 氏が公開している OSS UditAkhourii/adhd（npm パッケージ名 adhd-agent）です。互いに見えない N 本の推論プロセスを並列に立ち上げ、それぞれに異なる「認知フレーム」を与えて発散させ、そのあと別の批評プロセスでスコアリングと剪定を行う、という2段構成を取ります。

なお、GitHub には ayghri/i-have-adhd というまったく別のプロジェクトが存在し、こちらも「ADHD」を冠しています。ただし後者はエージェントの応答を行動優先のフォーマットへ整形するスキルであり、本記事が扱う UditAkhourii/adhd とは目的も機構も異なります。名前が紛らわしいため、両者の違いはのちほど改めて整理します。

本記事では、公開されている README・公式ドキュメント・GitHub API から取得したメタデータのみに基づき、adhd-agent の仕組み、Chain-of-Thought や Tree-of-Thought との構造的な違い、3つの導入形態、そして公開されている評価結果とその限界・コスト構造までを整理します。ローカル環境へのインストールや実行による動作検証は行っていないため、実行速度や使用感の評価は含みません。数値はいずれも2026年8月29日時点で取得した公開情報に基づきます。

adhd-agentとは｜コーディングエージェントの発想を並列分岐させるOSS

adhd-agent は、README で自らを "An architectural fix for premature convergence in autoregressive reasoning."（自己回帰的推論における早すぎる収束へのアーキテクチャ的な対処）と位置づけています。日本語にすると「AI が早々に1つの答えへ収束してしまう問題を、プロンプトではなく構造で解く」という主張です。

対象とする問いの形は README に明示されており、"any prompt of the shape 'give me a few ways to…'"（「〜する方法をいくつか挙げて」という形のあらゆるプロンプト）とされています。具体的にはアーキテクチャの設計判断、API サーフェスの設計、原因の見当がついていないデバッグ、命名、戦略立案といった領域です。実装基盤は Claude & Codex Agent SDK で、動作要件は Node.js 18 以上です。

ソースコードは GitHub リポジトリ、解説は 公式ドキュメントサイト で公開されています。

リポジトリの基本情報とメンテナンス状況

GitHub API から取得したリポジトリのメタデータは以下のとおりです。

採用判断で最初に見るべき項目を先に押さえておきます。このリポジトリはアーカイブされておらず、他リポジトリからのフォークでもありません。オリジナルのプロジェクトとして能動的に開発が続いており、最終 push は2026年8月23日です。ライセンスは MIT が明示的に設定されており、商用利用や改変の可否で追加の確認が必要になる要素はありません。

npm 側の情報も同様で、パッケージ adhd-agent は MIT ライセンス、engines に node: ">=18" が指定されています（npm パッケージページ）。

スター 3,982・フォーク 273 という数字は、この規模の開発ツールとしては十分な関心を集めている水準です。ただし後述するとおり、公開されている性能評価の大部分は作者自身によるものであり、スター数と検証の厚みは別の指標として扱う必要があります。

同名の「i-have-adhd」とは別プロジェクト

冒頭で触れたとおり、GitHub 上には ayghri/i-have-adhd という別プロジェクトが存在します。スター 25,362（2026年8月29日時点）と本記事の対象より広く知られており、日本語で「ADHD スキル」と検索するとこちらの情報に行き当たることも少なくありません。

両者は目的が根本的に異なります。

つまり「答えの候補を増やしたい」なら adhd-agent、「答えが長文に埋もれるのを防ぎたい」なら i-have-adhd、という住み分けになります。後者については別途 i-have-adhdでClaude Code出力を行動優先にする方法 で扱っているため、出力の読みづらさが主な課題であればそちらが参考になります。

外部での採用状況

作者以外の場での動きも、健全性を測る材料になります。README の Featured 節および ADOPTERS.md には以下が記載されています。

• OSS プロジェクト repowire が PR #313 のマージによって adhd-agent を正式に採用
• ADOPTERS.md 時点で 17以上のプロジェクトが導入・統合を報告（repowire / mstack / zk-flow-oss / han / wtfismyrepo / awesome-prompts ほか）
• 技術メディア The New Stack が特集記事を掲載

なお The New Stack の記事は、見出し自体が「Researcher 'gave Claude Code 'ADHD'… and it thinks 2x better now.' Outside experts want more proof.」（研究者は Claude Code に「ADHD」を与え、2倍うまく考えるようになったと主張。外部の専門家はさらなる証拠を求めている）となっており、成果の主張と検証の不足の両方を扱った内容です（The New Stack）。加えて第三者による evidence-based レビューも公開されており、その指摘は issues #16〜#18 で追跡されています。

このあたりの温度感は、採用判断において重要です。「話題になっている」ことと「効果が独立に検証されている」ことは別であり、後者の材料については後半で改めて整理します。

なぜ単一のAIエージェントの発想は似通うのか

仕組みの説明に入る前に、adhd-agent が解こうとしている課題を先に定義しておきます。ここで「自分にはその課題がない」と判断できるなら、以降の検討は不要です。

公式ドキュメントが問題として名指ししているのは premature convergence（早すぎる収束） です。整理すると次の構造になります。

• 線形の Chain-of-Thought は、最初に出力した内容にアンカリングする。思考の各ステップは直前までの出力を読んだ状態で生成されるため、序盤で選んだ方向性が終盤まで効き続けます
• Tree-of-Thought は探索を広げるが、アンカリングは消えない。木構造で複数の経路を辿っても、その探索は単一の共有コンテキスト上を歩くため、初期の前提がブランチをまたいで持続します

つまり公式の立場は、これはプロンプトの問題ではなくアーキテクチャの問題である、というものです。

「1つのエージェントに5案出させれば同じでは？」への回答

ここで多くの読者が抱く疑問に、公式ドキュメントが直接答えています。「単一のエージェントに『選択肢を5つ挙げて』と指示すれば同じことでは？」という問いです。

ドキュメントの回答は明快で、単一チェーンに代替案を求めても、それらの代替案は共有コンテキストへ逐次的に生成されるという点が本質だとしています。最初に出した案を読んだ状態で2案目が書かれ、1案目と2案目を読んだ状態で3案目が書かれる。結果として、構造的に異なる角度ではなく同一テーマのバリエーションが並ぶことになり、「N個挙げよ」という指示は番号付きリストの形をした Chain-of-Thought にすぎない、という整理です。

ドキュメントはこの差を一文で要約しています。"'list alternatives' varies the output; ADHD varies the generator."（「代替案を挙げよ」は出力を変える。ADHD は生成器そのものを変える。）詳細は vs CoT & ToT のドキュメント に記載されています。

自分の困りごとがこの「似通った案しか出てこない」に該当するかどうかが、最初の判断分岐です。エージェントの出力が長すぎて読みにくい、指示どおりに動かない、といった課題であれば、adhd-agent は守備範囲外のツールになります。

adhd-agentの仕組み｜発散と収束を分ける2段ループ

adhd-agent の中核は、Diverge（発散）と Focus（収束）という2つのフェーズを、その間に「硬い壁」を置いて分離する構成です。ここが他手法との差が生まれる場所なので、順に見ていきます。以下の記述はすべて how-it-works のドキュメント に基づきます。

発散フェーズ｜隔離されたN本の並列ブランチ

第1フェーズでは、フレームライブラリから N 個の認知フレームを選択し、N 本の並列な Agent SDK クエリを起動します。重要なのは、それぞれが新しい隔離セッションとして立ち上がる点です。

各ブランチが見ることのできる情報は、以下の3つに限定されます。

1. 問題文
2. 割り当てられた1つのフレームの vantage prompt（視点を規定するプロンプト）
3. 評価・ランキング・ヘッジ（曖昧化）を禁止するシステムプロンプト。純粋な生成のみを行い、散文ではなく JSON 配列で出力するよう指示される

ブランチ同士は互いの出力を見ません。共有コンテキストがゼロであるため、アンカリングも収束圧力も発生しない、というのが設計上の主張です。実装としては並列 query() 呼び出しと設定可能なセマフォ（concurrency のデフォルトは4）で制御されます。

各発散ブランチは query() 単位のステートレスセッションであり、KV キャッシュもメッセージ履歴も共有しません。過去のブランチを後続へブロードキャストしないため、トークンコストはブランチ数に対して線形（O(N × per_branch)）に収まり、二次的には増えないと説明されています。

収束フェーズ｜スコア・クラスタ・深掘りの3パス

第2フェーズでは critic（批評器）を別途起動し、3つのパスを順に実行します。

1. Score: 全リーフを novelty（新規性）／viability（実現可能性）／fit（適合度）の3軸、各0〜10で採点します。地雷になり得るアイデアには機構的な理由を添えてトラップとしてタグ付けします。ドキュメントに挙がっている例は "shelve isn't thread-safe under multi-writer load"（shelve は複数ライタ負荷下ではスレッドセーフではない）といった具体度です
2. Cluster: 表層のキーワードではなく「根底にある切り口」でクラスタリングします。"remove-the-server plays"（サーバーを消す系）、"cache-shaped plays"（キャッシュ形状の系）といった単位でまとめることで、設計空間の形を可視化します
3. Deepen top-K: スコア上位 K 件（デフォルトは K=3）について、スケッチ・load-bearing risk（設計を支える前提が崩れるリスク）・最初の具体的な一歩・3〜5個の子アイデアを生成します

剪定はヒューリスティックな閾値でも logit バイアスでもなく、critic の構造化出力そのものが剪定の判断になるという点が特徴として挙げられています。

出力に含まれるもの

1回の実行で返るのは、単なるアイデアのリストではありません。ドキュメントによれば以下が含まれます。

• クラスタ化された広いアイデア集合
• 2〜4件のショートリスト
• non-obvious-but-viable pick（明白ではないが実現可能な1案）が明示フラグ付きで
• 理由付きのトラップリスト
• 深掘りされたブランチ
• 1つの provocation（ワイルドカード的な問い）

「明白ではないが実現可能な案」が独立した項目として出力される点は、この種のツールの目的をよく表しています。最も無難な案は単一エージェントでも出てきます。adhd-agent が取りに行っているのは、そうでない側です。

15の認知フレームとは何か

発散の質を決めるのがフレームです。frames のドキュメント では、フレームは vantage operator（視点演算子） であり、ペルソナでも領域専門家でもないと明確に定義されています。「あなたは34歳のエンジニアの John です」という役割演技ではなく、「問題全体を別の認知的な立ち位置から問い直させるシステムプロンプトのペイロード」だという整理です。

標準搭載は15フレーム。ドキュメントに記載されている主なフレームを抜粋します。

フレーム選択にはいくつかの制御が入っています。codeMode（デフォルトは true）が有効な場合はエンジニアリング寄りのフレームへ選択がバイアスされます。また wild タグのフレームは毎回1枠が予約されており、発散が無難さに寄りすぎないようになっています。選択はシードごとに決定的であるため、同じシードなら再現できます。

自作フレームの条件も明示されています。独自の語彙／独自のポスチャ（敵対的・構築的・素朴・最大主義など）／再現可能な歪みのうち2つ以上を満たすこと、というのが要件で、実装自体は src/frames.ts に約5行を追加する程度とされています。

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

すでに Tree-of-Thought を知っている読者にとって、最も重要なのがこの比較です。公式ドキュメントが提示している対比表を日本語化すると以下になります。

ドキュメントはこのうち3点が load-bearing（構造を支える本質的な差） だとしています。

1. 探索ではなく隔離。CoT も ToT もコンテキストウィンドウを共有するため、ステップ4の時点でステップ1〜3の内容にアンカリングしています。adhd-agent は共有そのものが無いため、構造上アンカリングが発生しません
2. 次手のバリエーションではなくフレーム。変えるのは生成される候補ではなく、生成器の視点そのものです。その結果、近傍のアイデアではなく構造的に異なるアイデアが出るという主張になります
3. 生成器と批評器の分離が、約束ではなく機構。「評価せずにまず挙げてください」とプロンプトで頼むのではなく、評価を禁止するシステムプロンプトの独立した API 呼び出しとして発散を行い、収束は逆の姿勢を持つ別呼び出しで行います

なお、ドキュメントには「並列5エージェントは単一プロンプトの約3倍の頻度で実質的に異なるアイデアを出す」という外部の観察も引用されています。ただしこの数値については、公式ドキュメント自身が逸話的な観察であり測定結果ではないと明記しており、追試は issue #13 で追跡されています。記事としても、この数字は方向性の示唆であって性能保証ではないものとして扱います。

もう1点、ペルソナ研究との関係についても但し書きがあります。「あなたは〇〇です」型のペルソナ研究は模擬アイデンティティを扱うものであり、vantage operator であるフレームとは機構が異なるため、ペルソナ研究の知見をフレーム選択にそのまま適用することはできない、という整理です（issue #17 で追跡）。

adhd-agentの導入方法と3つの利用形態

adhd-agent は、エージェントスキル・CLI・TypeScript ライブラリという3つの形態で提供されます。導入手順の詳細は install のドキュメント、API 仕様は api のドキュメント にまとまっています。いずれの形態も Node.js 18 以上が前提です。

以下では README に記載されているコマンド例をそのまま引用します。実行結果については動作検証を行っていないため触れません。

エージェントスキルとして導入する

既存のコーディングエージェント環境に組み込む形態です。

npx skills add UditAkhourii/adhd

（出典: README）

README によれば、このコマンドは Claude Code / Cursor / Antigravity / Codex / Cline / Gemini CLI / Windsurf を含む約50の環境を自動判別します。導入後は /adhd "your problem" の形で明示的に起動できるほか、アイデア出しの意図が検出された際に自動でトリガーされる設計です。

すでにエージェント環境を日常的に使っており、既存のワークフローに差し込みたい場合はこの形態が最も摩擦が小さくなります。

CLIとして使う

エージェント環境とは独立に、単発の壁打ちとして使う形態です。

npm install -g adhd-agent     # CLI
npm install adhd-agent        # library

（出典: README）

README の Quickstart には次の呼び出し例が示されています。

adhd "design a rate limiter that survives a leader election"
adhd "name this function" --frames 3 --ideas 8 --top 2

（出典: README）

2行目のように --frames（使用するフレーム数）・--ideas（生成するアイデア数）・--top（深掘りする上位件数）を指定でき、問題の重さに応じて発散の幅とコストを調整できます。後述するコスト構造とあわせて、この3つのオプションが実質的なコスト制御レバーになります。

TypeScriptライブラリとして組み込む

自作のエージェントやツールへ埋め込む形態です。

import { run, renderText } from "adhd-agent";

const result = await run({ problem: "How should we shard this queue under bursty load?", framesPerRun: 5, topK: 3 });
console.log(renderText(result));
// result.shortlist · result.nonObviousPick · result.traps · result.deepened · result.clusters

（出典: README）

返り値には shortlist（ショートリスト）・nonObviousPick（明白ではないが実現可能な案）・traps（トラップ）・deepened（深掘り結果）・clusters（クラスタ）が構造化されて含まれます。エージェントループの内部で、早すぎる収束のコストが高い意思決定ポイントにだけ差し込む、といった使い方はこの形態が前提になります。

形態選択の目安は次のとおりです。既存のエージェント環境で日常的に使うならスキル、環境に依存せず単発で相談したいなら CLI、自作システムへ組み込んで条件付きで発火させたいならライブラリ、という切り分けになります。後述するコスト面では、スキル形態が最も割高になる点に注意が必要です。

類似リポジトリとの違い

「発散思考をコードで支援する」という発想自体は新しくありません。既存の選択肢との位置関係を整理します。以下のメタデータはいずれも2026年8月29日時点で GitHub API から取得した値です。

Tree-of-Thoughtの実装との違い

princeton-nlp/tree-of-thought-llm は NeurIPS 2023 の論文 "Tree of Thoughts: Deliberate Problem Solving with Large Language Models" の公式リファレンス実装です（論文）。Game of 24 のようなタスクで GPT-4 の Chain-of-Thought が 4% にとどまるところ 74% を達成した、という論文の数値がよく知られています。kyegomez/tree-of-thoughts は、その ToT をより汎用的に任意のタスクへ差し込めるようにした実装です。

これらと adhd-agent の差は、機能の優劣というよりそもそも解こうとしている問題が違う点にあります。ToT 系の2件は「正解が定義できるタスクで、探索によって正答率を上げる」ための探索アルゴリズムの実装です。対して adhd-agent は「正解が定義できないオープンエンドな設計判断で、選択肢の幅を広げる」ための、日々の運用に差し込むスキルです。Game of 24 に adhd-agent を使う理由はありませんし、キューのシャーディング方式の選定に ToT の探索を持ち込んでも、評価関数を定義できないため探索が機能しません。

もう1つ、採用判断で見落とされやすいのがメンテナンスの活性度です。ToT 系2件の最終 push はそれぞれ2025年1月・2025年7月であるのに対し、adhd-agent は2026年8月23日です。論文実装は再現性のために更新が止まっていること自体が自然でもあるため、これは一概に優劣ではありません。ただし「LLM の API 仕様が変わったときに追随されるか」という観点では、実質的な差になります。

同名のi-have-adhdとの違い

前述のとおり ayghri/i-have-adhd は名称のみが類似する別プロジェクトで、扱う層が異なります。adhd-agent が変えるのはアイデアの生成過程であり、i-have-adhd が変えるのは出力の提示形式です。両者は排他ではなく、理屈のうえでは併用も成り立ちます。検索でこの2つを混同したまま比較検討に入ると、判断の軸が定まらなくなるため注意が必要です。

使いどころとコスト｜採用前に押さえる判断材料

ここまでが「何をするツールか」の整理でした。以降は採用判断に直結する材料です。when-to-use のドキュメント と evals のドキュメント に基づいて整理します。

向く場面・向かない場面

公式ドキュメントは、向く場面と向かない場面をかなり明確に線引きしています。

向く場面

• アーキテクチャ・設計判断（ストレージ層、シャーディング、認証モデル、キュー構成、リトライ戦略）
• API・SDK・CLI のサーフェス設計
• 原因の見当がついていない曖昧なデバッグ（仮説クラスの生成）
• 移行・リファクタリング計画
• 命名
• コードレビューの視野拡張
• 戦略・ポジショニング・価格設定
• エージェントループ内部で、早すぎる収束のコストが高い意思決定ポイント

向かない場面

• 調べれば分かる質問
• 原因がすでに特定されているバグの修正
• 検索一発で答えが出るもの
• インナーループやキーストローク単位の低レイテンシ用途
• 唯一解のある問題

ドキュメントが示している判定基準は実務的でわかりやすいものです。要約すると「ジュニアがググって答えを見つけられる問いなら、通常のベースラインのほうが勝つ。シニアが『うーん、もう少し違う角度から考えさせてほしい』と言う場面が出番」という切り分けです。

公開されている評価結果とその限界

公式には、オープンエンドなエンジニアリング課題6問における平均スコア（0〜10）が公開されています。同一モデルの単発ベースラインとの比較です。

6問中5問で adhd-agent が勝利し、最大の差が出たのは trap detection でした。評価は独立した LLM に「懐疑的なスタッフエンジニア」というプロンプトを与えて判定させ、A/B の提示順もランダム化されています。

ただしこの数値の性格は正確に把握しておく必要があります。 これは LLM-as-judge による評価であり、かつプロジェクト自身が公開している自己評価です。第三者による独立したベンチマークではありません。サンプル数も6問と限られています。前述の The New Stack の見出しが「外部の専門家はさらなる証拠を求めている」となっていたのは、まさにこの点を指しています。

一方で、独立した第三者による計測も公開されています。miyagadget による検証は2問・ブラインドスコアリング・A/B 位置の入れ替えという条件で行われ、2問とも adhd-agent が優位という結果でした。スコアは novelty が 4.5 → 9.0、trap detection が 5.0 → 9.0 と改善しています。ただし同時に、実行時間が約2.26倍（95.4秒 → 216.1秒）、出力量が約1.93倍（5,623文字 → 10,697文字） というコストが報告されており、「数回実行しただけで Claude のサブスクリプションのセッション上限に達した」とも記されています（miyagadget による検証）。

改善幅が第三者の測定でも再現されている点は評価材料になりますが、同時にコストも実測で裏付けられた形です。品質とコストはセットで判断する必要があります。

コスト構造｜「呼び出し回数」で見積もると誤る

コストについては、公式ドキュメントが明確な注意喚起をしています。

1回の実行はおおむね「N 本の発散呼び出し（デフォルト5）＋ スコアリング1回 ＋ クラスタリング1回 ＋ K 回の深掘り（デフォルト3）」＝ N + K + 2 回、デフォルト設定なら約10回の呼び出しです。ところがドキュメントは、呼び出し回数は誤った単位であると明言しています。支払っているのはトークンコストであり、その大半は「ブランチごとに再ロードされるコンテキスト」が占めるためです。

公式に示されているコスト式は以下です。

cost ≈ N × (base_context + branch_output)   ← divergence
     + critic_context                        ← score + cluster see all N×k ideas
     + K × deepen_context                    ← focus passes

（出典: when-to-use のドキュメント）

ポイントは base_context に N × が掛かっていることです。ドキュメントの例示では、基盤コンテキストが約26Kトークンある場合、5ブランチはアイデアを1トークンも生成する前に約130Kトークンを再ロードすることになります。「10回呼び出すだけ」という言い方が隠しているのは、この部分です。

実行形態によって割増率が変わる点も、形態選択に直結します。

• スタンドアロンのライブラリ / CLI: 基盤コンテキストが小さいため、割増は素朴な5〜10倍に近い水準にとどまります
• Claude Code セッション内のスキル: 各ブランチが CLAUDE.md やツールのコンテキストを再ロードするため、割増はライブラリより明確に大きくなります。セッションの基盤コンテキストに比例して増えるため、1 × base ではなく N × base で見積もる必要があります

ドキュメントが示す目安は「高リスクな判断の選択肢を広げるために数セント〜数ドル」という水準ですが、正確な額は N・基盤コンテキストの大きさ・API 料金に依存するため各自の環境で計算すべき、という立場です。そして運用上の推奨は明確で、キーストロークごとではなく意思決定ポイントで実行することとされています。

前述の CLI オプション --frames / --ideas / --top は、この式の N と K を直接動かすレバーです。全案件でデフォルトの5ブランチを回すのではなく、判断の重さに応じて絞る運用が現実的な落としどころになります。

まとめ｜adhd-agentの採用が向くプロジェクトの条件

ここまでの内容を、採用判断のチェックリストに畳みます。以下の4つがすべて当てはまるなら、限定的な範囲での試用を検討する価値があります。

1. 正解が定義できない設計判断が、定期的に発生している。アーキテクチャ選定・API サーフェス設計・移行計画・命名といった、選択肢の幅そのものが成果を左右する意思決定が業務に含まれている
2. その判断を誤ったときのコストが、数ドルの API 費用より明確に大きい。あとから設計をやり直す手戻りが数人日単位で発生する種類の判断である
3. 実行を意思決定ポイントに限定できる運用が組める。常時起動ではなく、重い判断のときだけ呼び出すという規律を運用に落とし込める
4. TypeScript / Node.js 18 以上の環境、またはスキル対応のエージェント環境をすでに使っている

逆に、採用を見送ってよいケースも明確です。エージェントの用途が実装作業と調査中心で、選択肢を広げる場面がそもそも少ない場合。エージェントの出力が読みにくいことが主な課題である場合（これは出力整形側のツールの領域です）。低レイテンシが要求されるインナーループでの利用を想定している場合。そして、性能の裏付けとして独立した大規模ベンチマークを社内基準として求められている場合です。最後の点については、公開されている評価が6問の自己評価と2問の第三者検証にとどまる現状では、基準を満たさない可能性があります。

このカテゴリのツールは、「高機能かどうか」で選ぶと判断を誤ります。自分たちのエージェント運用のどこで詰まっているのかを先に言語化し、それが「早すぎる収束」なのかどうかで切り分けるほうが確実です。本記事の前半で挙げた「似通った案しか出てこない」という症状に心当たりがあるかどうかが、最初にして最大の分岐点になります。

さらに踏み込んで検討する場合は、設計思想の背景が 公式ドキュメントサイト と 著者によるプレプリント にまとまっています。特にコスト式と使いどころの線引きは、社内で導入可否を議論する際にそのまま材料として使える粒度で書かれています。

関連情報

AI エージェントを前提とした開発プロセスの設計や、社内向けツールの選定・構築についてご相談を承っています。ご検討中の方は お問い合わせフォーム からお問い合わせください。要件が固まる前の整理段階からご相談いただけます。