AgentHub は誰が作ったものですか？

Andrej Karpathy が公開したプロジェクトです。ただし本家リポジトリは現在参照できず、内容は fork に残るREADMEで確認できます。そのREADMEは「私の以前のプロジェクトである autoresearch」と一人称で書かれており、原文が保存されています。

なぜ main ブランチや PR を持たない設計にするのですか？

READMEは「main ブランチもPRもマージもない、あらゆる方向へ伸びる commit の DAG があるだけ」と説明しています。結果の大半が採用されない前提では、1本の正解へ集約する操作より、どの枝で何が試されたかをたどる操作のほうが主になるためです。

作業の系譜をたどるにはどうしますか？

AgentHub の CLI には ah children（この上で何が試されたか）、ah leaves（子を持たない先端の commit）、ah lineage（根までの系譜）が用意されています。マージ済みかどうかではなく、枝のつながりで探します。

エージェントの協働にはどんな型がありますか？

Anthropic は公式記事で prompt chaining、routing、parallelization、orchestrator-workers、evaluator-optimizer の5つを挙げています。いずれも単純で組み合わせやすい形として提示されたものです。

動的ワークフロー（dynamic workflows）とは何ですか？

公式ドキュメントによれば、サブエージェントを大規模に指揮するJavaScriptのスクリプトです。Claudeが与えられたタスク用にそのスクリプトを書き、ランタイムが背後で実行します。Claude Code v2.1.154以降で利用できます。

同時に何体まで動かせますか？

公式ドキュメントは同時実行を最大16エージェント（CPUコア数が少ない機械ではそれ以下）、1回の実行あたり合計1,000エージェントと明記しています。前者は手元の資源を抑えるため、後者は暴走ループを防ぐための上限です。

大量に動かすと警告は出ますか。実行は止まりますか？

25エージェントを超える計画、または見込みトークン総量が150万を超える場合に「Large workflow」警告が出ます。ただし公式ドキュメントは、この警告は助言であって実行を一時停止も制限もしないと明記しています。

途中で止まった場合、どこから再開されますか？

公式ドキュメントによれば、再開はエージェントの起動順に沿って進み、最初に完了しなかったエージェント以降は、完了済みであっても再実行されます。そのため公式は、長い1体より小さく分けたほうが進捗が残ると述べています。

Bun の書き換えではどれくらいのコードが生成されましたか？

公式ブログには2つの記述があります。2026年5月28日の記事は「75万行のRust、初コミットからマージまで11日、既存テストの99.8%が通過」と述べ、2026年7月16日の記事は「100万行が2週間未満で生成」「マージ前にCIで既存テストが100%通過」「マージ後に19件のリグレッションが表面化し、すべて修正済み」と述べています。

並列化すればコストは下がりますか？

下がりません。Bun の事例では、キャッシュされていない入力トークン59億、出力トークン6.9億、API価格で約16万5000ドルと公表されています。公式ドキュメントも、大きなタスクに踏み切る前に狭い範囲で一度試して費用感をつかむよう助言しています。

commitを探索グラフとして扱う：AIエージェント協働と並列化の設計【2026年版】

この記事の概要

項目	内容
対象読者	AIエージェントを複数動かす開発者、および記録と統制の設計を考えるDX担当者
対象テーマ	複数のエージェントが同時に動くときの記録の残し方、協働の型、並列化の上限とコスト
想定読了時間	約14〜18分
最終更新	2026年8月2日
出典基準	公開されている一次ソース（公式リポジトリ、公式ドキュメント、公式ブログ）のみを事実として記述。かなうテックの見解は文中で明示して区別

本記事は全3回シリーズの第2回です。第1回ではエージェント1体のループ設計を扱いました。第3回では知識をグラフとして持つべき場合と持つべきでない場合を扱います。

イントロ：1体で回るようになった次に、何が問題になるか

第1回では、判定を1つに定め、時間を固定し、1周ごとに残すか捨てるかを決めるループを扱いました。この形が成り立つと、次に出てくるのは「同じことを何体でやらせるか」という問いです。

ここで、人間向けに作られた仕組みの前提が崩れ始めます。バージョン管理も、レビューも、マージも、書き手が少なく、書いたものの大半が採用される前提で設計されています。エージェントが数百体動き、結果の大半が採用されない状況では、その前提が成り立ちません。

本記事では、その前提が崩れたときに何が置き換わるのかを見ます。

Part 1: commit を探索の記録として扱う

1-1 帰属について先に断っておく

AgentHub は Karpathy が公開したプロジェクトです。ただし本家リポジトリは現在参照できません。以下は fork に残るREADMEで確認できる範囲です^[1]。そのREADMEは autoresearch を指して「私の以前のプロジェクト」と一人称で書いており、原文が保存されていると読めます。

そのREADMEは、AgentHub と autoresearch の関係をこう説明しています^[1]。 autoresearch は1人の博士学生が研究している状態を模したもので、AgentHub はその集まり、つまり自律的な研究コミュニティを模す。インターネット上の各人が autoresearch を走らせ、自分のエージェントをコミュニティへ寄与する、という構想です。

READMEは冒頭で「まだ進行中。ただのスケッチ。考えているところ」とも述べています^[1]。完成した製品として読むものではありません。

1-2 main もPRもマージも持たない

READMEはこの設計をこう表現しています^[1]。 main ブランチもPRもマージもない、簡素化されたGitHubのようなもので、あらゆる方向へ伸びる commit の DAG があるだけ。そこにエージェントどうしが調整するための掲示板が付く。

構成は素朴です^[1]。 Goのバイナリ1つ、SQLiteのデータベース1つ、ディスク上のbareなGitリポジトリ1つ。 HTTP APIを薄く包んだCLIが1つ付きます。

なぜ main を持たないのか。ここからはかなうテックの解釈ですが、集約すべき1本が存在しないからだと考えています。数百の試行のうち採用されるのが数個という比率では、「本流へ取り込む」操作の出番がほとんどありません。代わりに主になるのは、どの枝で何が試されたかをたどる操作です。

1-3 系譜をたどるためのCLI

CLIの構成も、その考え方に沿っています^[1]。

ah children：この commit の上で何が試されたか
ah leaves：子を持たない先端の commit
ah lineage：根までの系譜
ah diff：2つの commit の差分

READMEはGit層の役割を、任意の commit を取得し、DAGを見て回り、children と leaves と lineage を見つけ、commit 間の差分を取ること、と説明しています^[1]。探すときの単位が「マージ済みかどうか」ではなく「枝のつながり」になっています。

1-4 掲示板が担うもの

仮説や失敗は、commit の属性としてではなく掲示板に置かれます。 READMEは掲示板をチャンネルと投稿とスレッド返信からなるものとし、エージェントは結果、仮説、失敗、調整のためのメモなど、好きなものを投稿すると説明しています^[1]。

プラットフォーム側は中身に関与しません。 READMEは、このプラットフォームは汎用であり、エージェントが何を最適化しているかを知らないし気にしない、と明記しています^[1]。何を投稿し、結果をどう書くかという作法は、プラットフォームではなくエージェントへの指示から来る、という設計です。

防御の仕組みも素朴に置かれています^[1]。エージェントごとのAPIキー、レート制限、バンドルサイズの上限です。

1-5 中小企業の業務に置き換えると

この設計から持ち帰れるのは、Gitの使い方ではありません。記録の単位を「最終的に採用されたもの」から「試したこと全部」に変える、という発想です。

多くの職場では、決まったことだけが残ります。検討して見送った案は、議事録の片隅に残るか、どこにも残りません。その結果、半年後に同じ案が再提案され、同じ議論が繰り返されます。

試した内容と、その結果と、採用しなかった理由が、たどれる形で残っていれば、この繰り返しは減ります。必要なのは高機能なツールではなく、残す単位を決めることです。

Part 2: 協働の型は5つに整理されている

2-1 workflows と agents の違い

Anthropic は2024年12月19日の公式記事で、この2つを定義として区別しています^[2]。 workflows は、あらかじめ定められたコードの経路を通してLLMとツールが組み立てられる仕組み。 agents は、LLMが自分の処理とツールの使い方を動的に方向づけ、どう達成するかの制御を保つ仕組み。

違いは、次の一手を誰が決めるかです。経路が先に決まっていれば workflows、実行時にLLMが決めれば agents になります。

2-2 5つのパターン

同じ記事は、組み立ての型として次の5つを挙げています^[2]。

prompt chaining：出力を次の入力へ渡して段階的に処理する
routing：入力を分類して適切な処理へ振り分ける
parallelization：同じ入力を並行して処理し、結果をまとめる
orchestrator-workers：指揮役が仕事を分けて作業役へ配る
evaluator-optimizer：生成役と評価役を分け、評価に基づいて作り直す

2-3 どれから始めるか

同じ記事は、進め方についてこう述べています^[2]。単純なプロンプトから始め、包括的な評価で最適化し、単純な解では足りないときにだけ多段のエージェント構成を足す。

第1回でも引いた一文ですが、複数体を動かす段階ではより効いてきます。構成を先に増やすと、うまくいかないときに、パターンの選択が悪いのか、対象の性質が合っていないのかを切り分けられなくなります。

Part 3: オーケストレーション自体をモデルに書かせる

3-1 動的ワークフローとは何か

Claude Code の公式ドキュメントは、動的ワークフローを次のように定義しています^[3]。サブエージェントを大規模に指揮するJavaScriptのスクリプトである。 Claude が与えられたタスク用にそのスクリプトを書き、ランタイムが背後で実行する。そのあいだセッションは応答可能なまま保たれる。

利用には Claude Code v2.1.154 以降が必要だと明記されています^[3]。

開発者が固定の並列処理を書くのではなく、その場のタスクに合わせた指揮のプログラムをモデルが書く、という段の移動が起きています。

3-2 中間結果はどこに残るか

公式ドキュメントは、この点を仕組みの中心として説明しています^[3]。ワークフローのスクリプトが、ループも分岐も中間結果も自分で抱える。だからClaudeのコンテキストには最終的な答えだけが残る。

サブエージェント、スキル、エージェントチームとの比較表でも、中間結果の置き場所は「スクリプトの変数」と示されています^[3]。他の3つはいずれも「Claudeのコンテキストウィンドウ」または「共有のタスクリスト」です。規模の欄では、ワークフローだけが「1回の実行あたり数十から数百のエージェント」となっています。

なお、サブエージェントがそれぞれ独立したコンテキストを持つ点は、サブエージェント側の公式ドキュメントに記載があります^[4]。

3-3 上限と警告

公式ドキュメントは、ランタイムが課す制約を表として明示しています^[3]。

制約	理由（公式の記述）
同時実行は最大16エージェント。CPUコア数が少ない機械ではそれ以下	手元の資源の使用量を抑えるため
1回の実行あたり合計1,000エージェント	暴走ループを防ぐため
実行中にユーザーが入力することはできない	段階ごとの承認が必要なら、各段階を別のワークフローとして実行する
ワークフロー自体はファイルにもシェルにも直接触れない	読み書きとコマンド実行はエージェントが行い、スクリプトはエージェントを調整する

規模の目安を設定する仕組みもあり、small は5未満、medium は15未満、large は50未満のエージェント数を目安としてClaudeに伝えます^[3]。既定は medium です。

そのうえで、25エージェントを超える計画、または見込みトークン総量が150万を超える場合に「Large workflow」警告が出ます^[3]。ここは読み違えやすいところですが、公式ドキュメントはこの警告について、助言であって実行を一時停止も制限もしないと明記しています^[3]。止めるかどうかは人が決めます。

3-4 途中で止まったらどこから再開するか

再開の規則は、実務で最も効いてくる部分です。公式ドキュメントはこう説明しています^[3]。再開はエージェントの起動順に沿って進む。キャッシュされた結果は、最初に完了しなかったエージェントのところで止まる。そのエージェントより後に起動したものは、たとえ完了していても再実行される。

そして公式は、そこから次の結論を導いています^[3]。多数の小さなエージェントに仕事を分けたワークフローのほうが、1体の長いエージェントより多くの進捗が残る。

第1回で述べた「1回に1つしか変えない」という規律は、ここで別の理由から裏付けられます。やり直しの単位が小さいほど、中断で失うものが少なくなります。

3-5 中小企業の業務に置き換えると

並列で動かす仕組みを自社で組む機会は、当面は多くないかもしれません。それでも、この設計から取り出せる判断が2つあります。

1つは、承認を挟みたい工程は分けるということです。公式ドキュメントが「段階ごとの承認が必要なら各段階を別のワークフローとして実行する」と述べているのは、実行中に人が割り込めない仕組みだからです。自動化を設計するときも、人の承認が要る箇所は、自動処理の途中ではなく境目に置くほうが素直になります。

もう1つは、やり直しの単位を先に決めることです。 1つの長い処理として組むと、途中で止まったときに最初からになります。工程を分けておけば、止まった箇所から先だけを流し直せます。

Part 4: 並列化は速いが、安くはない

4-1 2026年5月28日の発表

動的ワークフローの導入事例として公表されたのが、JavaScriptランタイム Bun の書き換えです。 Anthropic の公式ブログは2026年5月28日の記事で、次の数字を挙げています^[5]。 75万行のRust。初コミットからマージまで11日。既存テストの99.8%が通過。

4-2 2026年7月16日の追報

同じ移行について、公式ブログは2026年7月16日の記事でより詳しい数字を出しています^[6]。 100万行のコードが2週間未満で生成された。マージ前の時点で、Bun の既存テストスイートはCIで100%通過していた。マージ後に19件のリグレッションが表面化し、すべて修正済みである。

成果の側も公表されています^[6]。ベンチマークでのメモリ使用量は6,745MBから609MBへ。バイナリはLinuxとWindowsで19%小型化。 HTTP配信と実際のワークロードで2〜5%高速化。 Rustコードのうち約4%が unsafe ブロックの中にある。

4-3 2つの数字の差が示すこと

ここからはかなうテックの見解です。

同じ移行について、2つの公式記述が異なる数字を示しています。 5月の発表では「テストの99.8%が通過」、7月の追報では「マージ前にCIで100%通過し、マージ後に19件のリグレッション」。どちらも公式であり、どちらかが誤りだという話ではありません。時点が違い、測っている対象が違います。

ここに、このシリーズが扱っている主題がそのまま出ています。発表時点の数字は、その時点で観測できた範囲の要約です。時間が経ち、実際に動かした結果が積み上がると、より確定的な記述に置き換わります。

自社の自動化を評価するときも同じことが起きます。導入直後の「テストが通った」は、まだ見積もりに近い。本番で動かし、表面化した不具合を数え、修正まで追えて、はじめて証拠になります。数字を引用するときは、いつ時点の何を測ったものかを一緒に持っておく必要があります。

4-4 コストの実測

同じ7月の記事は、消費量も公表しています^[6]。キャッシュされていない入力トークンが59億、出力トークンが6.9億。 API価格でおよそ16万5000ドル。

並列化は時間を短縮しますが、費用を下げるものではありません。公式ドキュメントも、大きなタスクに踏み切る前に狭い範囲で一度試して費用感をつかむよう助言しています^[3]。 1つのディレクトリだけ、あるいは狭い問いだけで走らせてみる、という進め方です。

まとめ：協働の設計とは、やり直しの単位を決めること

複数のエージェントを動かす設計で決まるのは、速さだけではありません。何を記録として残すか、どこで止められるか、止まったときにどこからやり直すかが決まります。

試したこと全部を枝としてたどれる形にすること。承認が要る箇所を工程の境目へ置くこと。やり直しの単位を小さく保つこと。この3つは、エージェントを使うかどうかに関わらず、業務の設計として成立します。

次回は、ここまで扱ってきた「作業の記録」とは別の記憶、つまり業務の知識そのものをどう持つかを扱います。そして、グラフにすべきでない場合についても書きます。

回	テーマ	示す内容
第1回	ループ設計	3つのファイルに分ける構造、1回1変更の規律、任せられる仕事の4条件
第2回（本記事）	協働と探索グラフ	変更履歴を探索の記録として扱う設計、協働の5パターン、並列化の上限とコスト
第3回	知識の置き場所	作業の系譜と知識を分ける理由、導入順序、グラフが不要な場合

自動化のどこに承認を挟み、どこまでを自動で流すかの設計は、無料相談でも承っています。

参考文献

すべての出典は2026年8月2日時点のものです。

agenthub 公式リポジトリのREADME（fork に保存された原文） — https://github.com/ottogin/agenthub
Anthropic「Building Effective AI Agents」（2024年12月19日） — https://www.anthropic.com/engineering/building-effective-agents
Claude Code 公式ドキュメント「Orchestrate subagents at scale with dynamic workflows」 — https://code.claude.com/docs/en/workflows
Claude Code 公式ドキュメント「Subagents」 — https://code.claude.com/docs/en/sub-agents
Anthropic「Introducing dynamic workflows in Claude Code」（2026年5月28日） — https://claude.com/blog/introducing-dynamic-workflows-in-claude-code
Anthropic「How Anthropic runs large-scale code migrations with Claude Code」（2026年7月16日） — https://claude.com/blog/ai-code-migration

注記：AgentHub について本記事が記述した内容は、いずれも fork に保存されたREADMEで確認できる範囲です。本家リポジトリ（karpathy/agenthub）は本記事執筆時点で参照できません。READMEが「まだ進行中。ただのスケッチ」と述べているとおり、完成した製品ではなく設計の素描として読むべきものです。Anthropic の動的ワークフローの仕様（同時実行16、1実行あたり1,000、警告の閾値、必要バージョン）は公式ドキュメントの記載であり、いずれも変更されうるため、導入前に公式ページでご確認ください。Bun の移行に関する数値は2026年5月28日と2026年7月16日の2つの公式記述に基づき、時点によって異なります。Part 1-2 の「なぜ main を持たないのか」の解釈、Part 1-5、Part 3-5、Part 4-3、およびまとめは、かなうテック（屋号：Kanau Tech™）の見解であり、公式に述べられたものではありません。