awesome-agent-orchestrators徹底解説｜収録199本のstar・更新停止・リンク切れを全件実測

AIコーディングエージェントを1つ動かすツールは飽和した。いま増えているのは、エージェントを何本も同時に走らせて、その面倒を見る側のツールだ。awesome-agent-orchestrators（★1,674）は、その「動かす側」だけを集めたキュレーションリストで、2026-09-06 時点で 199本を8セクションに整理している。

ただしawesomeリストには共通の弱点がある。読む前に、そのリンクがどれだけ生きているのか分からないことだ。そこで収録199本すべてをGitHub APIで実測し、star分布・最終コミット・archived・404を数えた。結果は「多くが死んでいる」という予想を裏切るもので、むしろこのリストは停止したプロジェクトを隔離する仕組みを自前で持ち、それが実際に機能していた。

エージェントフレームワークそのものの選定はAIエージェントフレームワーク比較2026｜LangGraph・CrewAI・Dify等9種をStar数・実コードで検証で扱っている。本記事はその一段上、「複数のエージェントを束ねる層」のカタログをどう読むかに絞る。

awesome-agent-orchestratorsとは——「エージェントが消費するもの」を除外したリスト

このリストの定義は冒頭1文に明記されている。収録対象は「エージェントが何に取り組むか・いつ走るか・どこで走るか・出力をどうするかを決めるもの」で、逆にエージェントが単に消費する側——メモリバックエンド、MCPサーバー、サンドボックス提供業者、スキルライブラリ——は範囲外だと宣言している。

この線引きは実用上かなり効く。「AIエージェント関連OSS」を名乗るリストは大抵MCPサーバーやベクトルDBまで飲み込んで数百件に膨れるが、ここは制御する側だけに絞っているので、199本という規模でも用途が一貫している。単機能ボット（特定タスク専用のもの）も除外され、「任意のタスクを渡せること」が収録条件になっている。

この除外ルールは、探し物をするときの実用的な指針にもなる。たとえば「エージェントに社内Wikiを読ませたい」という目的でこのリストを開いても答えは無い——それはエージェントが消費する側なのでMCPサーバーの領域であり、意図的に範囲外にされている。逆に「複数のエージェントに別々のブランチを触らせて、コンフリクトを自動で解消させたい」なら、それは制御する側なのでこのリストの守備範囲になる。この境界を掴んでおくと、199本を漫然と眺めずに済む。

リポジトリ本体の状態も実測した。

GitHub APIの open_issues_count は46を返すが、これはPRを含んだ数値で、内訳はIssue 4件＋オープンPR 42件だった。オープンPR 42件に対しマージ済み120件という比率は、このリストが「掲載してほしい」という申請を捌ききれていない状態を示す。裏を返せば、収録199本は現時点の全量ではなく、選別を通過した分ということになる。

ライセンスが未指定な点は注意が必要だ。awesomeリストはCC0やCC BYを掲げるのが通例だが、このリポジトリはREADME.md 1ファイルだけで構成され、LICENSEファイルが存在しない。GitHubのライセンス欄がnullなのは「情報なし」ではなく、再利用条件が示されていないということなので、内容を大きく引き写して二次配布する用途には向かない。

収録199本を全件実測——生きているのは何本か

ここからが本題だ。199本すべてについてGitHub GraphQL APIでバッチ取得し、star数・archivedフラグ・既定ブランチの最終コミット日時を集めた。

実測の全体像は次の通り。

404は3本だった。ofekron/better-agent・joewinke/jat・ariana-dot-dev/ariana の3つで、いずれもリポジトリごと削除されたか非公開化されている。GitHub APIは実在するページにもUser-Agent次第で404を返すことがあるため、ブラウザ相当のUser-Agentを付けて再確認したが、3本ともリダイレクトなしの404で確定した。

つまりリンク切れ率は1.5%（3/199）。当サイトでこれまで実測した同規模のキュレーションリストと比べても低い水準で、リンクの管理は行き届いている。

「Resting」は機能しているのか——リストが自前で持つ隔離セクション

このリストの特徴は、停止したプロジェクトを削除せず「Resting」という別セクションに退避する運用を持っていることだ。READMEにはこう書かれている——「数か月pushが無いプロジェクトのwatchlist。活動が再開したら上に戻す」。チェック日として 2026-07-28 が明記されている。

問題は、その運用が実際に効いているかだ。測った。

Restingに入っている16本（1本は404）の最終コミットを並べると、最短でも125日前、中央値173日、最長212日だった。一方、稼働7セクションの中央値は1日。両者は125日という明確な谷で分かれている。

READMEの「数か月」という曖昧な表現は、実測では約125日以上という運用実態に対応していた。この125日を基準に稼働セクション側を数え直すと、5本が基準を満たしているのに隔離されずに残っていた。

5本すべてがstar 92以下である点が示唆的だ。取りこぼしは無作為ではなく、目立たない小規模リポジトリに偏っている。チェック日が 2026-07-28 で本記事の実測が2026-09-06、つまり約40日のドリフトでこれだけ溜まる計算になる。

より確実な兆候は404の2本だ。better-agent と jat はRestingではなく稼働セクション（Desktop & Web）に残っている。削除されたリポジトリは「pushが無い」判定にすら引っかからないため、push日を見る運用では原理的に検出できない。リストを使う側は、Resting行きになっていないことを「生きている証拠」として扱わない方がいい。

なお、archivedフラグが立っている3本（1code・lettabot・mercury）はすべてRestingに入っていた。明示的にアーカイブされたものは取りこぼしがない。

star分布と新しさ——中央値760、しかし33%は200未満

star数は中央値760。ただしこの分布に平均を使ってはいけない。最大の openclaw が389,005starあり、平均を取ると9,185という、実態のどこにも対応しない数字になる。

分布を刻むとこうなる。

3本に1本は200star未満で、有名プロジェクトと個人の実験が同じ棚に並んでいる。ただしこれを「玉石混交」と切り捨てるのは早い。作成から180日以内のリポジトリが85本（43%）を占めるからだ。この分野自体が2026年に入ってから立ち上がったもので、star数は「まだ知られていない」ことしか意味しない場合がある。

実際、当サイトが実機検証した記事を持つプロジェクトを収録リストと突き合わせると、23本が一致した。star 1万超の大物（openclaw・OpenHands・ruflo）から、Agent Orchestrator（AO）とは｜27エージェントを1枚で束ねるAgent IDEを実測で扱った agent-orchestrator、Paseo徹底解説｜複数AIコーディングエージェントを束ねるOSSオーケストレーター【AGPL】の Paseo、Orcaとは｜Claude Code・Codexを並列実行するAIエージェントIDE（ADE）の使い方の Orca まで、star帯を問わず分布している。★397の agent-manager も含まれており、star数と実用性は必ずしも連動しない。

ライセンスの内訳も測った。

NOASSERTION の20本は「ライセンス不明」ではなく、GitHubの標準ライセンス判定に当てはまらないという意味だ（独自の追記条項がある、複数ライセンスの併記、ファイル名が非標準など）。openclaw・cmux・Paseo・humanlayer といった主要プロジェクトがここに入っているため、商用利用を検討する場合は個別にLICENSEファイル本文を読む必要がある。表示なしの8本は再利用条件が示されていない。

収録199本のうち23本は当サイトで実機検証済み

このリストを「知らないツールを探す場所」としてだけ使うのはもったいない。当サイトがこれまで単独記事で実機検証したプロジェクトを収録199本と突き合わせたところ、23本が一致した。リストのどのセクションに、どれだけ検証済みのものが入っているかを見ておくと、残りを読むときの縮尺が掴める。

セクション別の内訳は Personal Assistants 7本、並列（GUI/Web）4本、並列（端末）3本、Swarms 3本、Task 3本、基盤2本、Loop 1本。23本中21本が当日〜4日以内にコミットしており、検証対象として選んだものは結果的に活発なものに偏っていた。

この23本は star で見ると 397〜389,005 と3桁の開きがある。★397の agent-manager はtmux上で複数エージェントの状態を並べ、diffレビューの行コメントをそのままエージェントへ返せる作りで、star数から想像するより完成度が高い。逆に★3,496の MetaClaw は最終コミットが90日前だ。前掲の「125日以上停止」5本には入らないが、90日は超えており停滞気味ではある（稼働セクションで90日以上停止しているものは15本ある）。star数と現在の勢いは別々に見る必要があることが、この23本の中だけでも確認できる。

裏を返せば、残る176本は当サイトが1本も実機検証していない領域だ。特に Agent Infrastructure & Primitives（21本・star中央値160）は、star が低く知名度も無いが最終コミット中央値3日と開発は活発で、「自分でオーケストレータを組む人向けの部品」という性格上、利用者が少なくても止まらない。ここは既存の日本語解説がほとんど無い。

8セクションの読み方——「並列コーディング」が36%を占める理由

「Parallel Coding Agents」の2セクションで72本＝全体の36%を占める。これはリストの重心が「1人の開発者が複数のコーディングエージェントを同時に走らせ、それぞれのdiffをレビューする」という用途にあることを意味する。git worktreeとtmuxで手作業していた領域に、これだけのツールが集中して生まれている。

セクション別に見て特徴的なのはMulti-Agent Swarmsで、最終コミット中央値が27日と他より一桁大きく、125日以上停止の5本のうち3本がここに集中している。「複数エージェントに大きな仕事を分担させる」という発想は魅力的だが、実装の継続率は並列実行系より低い。逆に Agent Infrastructure & Primitives はstar中央値160と最も低いのに最終コミット中央値3日と活発で、こちらは「自分でオーケストレータを作る人向けの部品」なので利用者数が少なくても開発は続く、という構図が読み取れる。

READMEには「How to choose」という選び方の導線も用意されている。

Loop RunnersとTask Runnersの違いが分かりにくいので補足すると、Loop Runnersは「1つのゴールを、検証が通るまで自分で回し続ける」型（いわゆるRalphループ系）、Task Runnersは「Issueトラッカーやボード、スケジュールから仕事を引いてくる」型だ。前者はゴールが1つ、後者は仕事が外部から供給される、という違いになる。

awesome-agent-orchestratorsの健全性を自分で測るコマンド

このリストは常に動いている（2026年に208コミット、直近も日次で更新）。本記事の数値は2026-09-06時点のスナップショットなので、読む時点で測り直せるようコマンドを置いておく。以下はすべて実行して出力を確認済みだ。

まず収録件数を数える。GitHub CLI（gh）が認証済みであることが前提。

gh api repos/andyrewlee/awesome-agent-orchestrators/readme --jq '.content' \
  | base64 -d \
  | grep -oE '^- \[[^]]+\]\(https://github\.com/[^)]+\)' \
  | wc -l

2026-09-06 時点で 199 が返る。

次に、気になった1本の既定ブランチの最終コミットを見る。前述のとおり pushed_at ではなくこちらを見る。

gh api graphql -f query='
query($o:String!,$n:String!){ repository(owner:$o,name:$n){
  nameWithOwner stargazerCount isArchived
  defaultBranchRef{ name target{ ... on Commit { committedDate } } } } }' \
  -f o=Untrivial-ai -f n=agent-orchestrator --jq '.data.repository'

収録全件をまとめて走査するなら次のスクリプトを使う。1本ずつRESTを叩くので199本で数分かかるが、レート制限には収まる。

#!/usr/bin/env bash
set -euo pipefail
gh api repos/andyrewlee/awesome-agent-orchestrators/readme --jq '.content' | base64 -d \
| grep -oE 'https://github\.com/[A-Za-z0-9._-]+/[A-Za-z0-9._-]+' \
| sed 's|.*github.com/||' | sort -u \
| while read -r nwo; do
    gh api "repos/${nwo}" \
      --jq '[.full_name, (.stargazers_count|tostring), (.archived|tostring), .pushed_at] | @tsv' \
      2>/dev/null || printf '%s\t-\t404\t-\n' "$nwo"
  done

404 と表示された行がリンク切れ、true の行がarchivedだ。本記事の実測ではこのスクリプトが199行を返し、404が3本・archivedが3本だった。

まとめ——このリストをどう使うか

実測して分かったのは、awesome-agent-orchestratorsは「リンクが腐ったリスト」ではないということだ。稼働セクションの65%が7日以内にコミットを持ち、停止したものはRestingへ隔離され、archivedは3本とも正しく隔離されていた。awesomeリストとしては上位の健全性だと言っていい。

使う側が意識すべき点は3つに絞られる。

1つ目は、Restingに入っていないことを生存証明として使わないこと。削除された2本は稼働セクションに残っており、push日ベースの運用では検出できない。クリックする前に上のコマンドで1本だけ確認するコストは数秒だ。

2つ目は、star数で足切りしないこと。43%が作成180日以内で、200star未満が33%を占める。当サイトが実機検証した23本にも★397のものが含まれており、この分野ではstar数が成熟度を測れていない。

3つ目は、ライセンス。リスト自体が未指定で、収録側も NOASSERTION 20本＋表示なし8本＝28本（14%）が標準ライセンスに当てはまらない。業務投入を検討するなら個別にLICENSE本文を読む必要がある。

なお、このリストは日次で更新され続けている（2026年だけで208コミット、直近も当日コミットあり）。オープンPRが42本滞留している状態から見ても、収録本数は今後も増える。本記事の数値は2026-09-06時点のスナップショットであり、判断に使うなら測り直してほしい——そのためのコマンドを前節に置いた。

そして最後に、このリストが36%を並列コーディングに割いていることは、それ自体が2026年のAI開発ツールの現在地を示している。単体のエージェントの賢さではなく、何本を同時に走らせ、その出力をどう捌くかが焦点になった、ということだ。

参照ソース

• andyrewlee/awesome-agent-orchestrators — GitHub（README本文・収録199本・セクション定義・Restingの運用方針。2026-09-06 取得）
• GitHub GraphQL API — Repository object（defaultBranchRef / stargazerCount / isArchived の定義。本記事の実測に使用）
• GitHub REST API — Repositories（pushed_at と open_issues_count の仕様。後者がPRを含む点の根拠）