15 個のオープンソース編成ツール、2026-09-22 当日の数値を一か所に

すべて 2026-09-22 の GitHub API の値で、各数値のあとに取得日を書いてある。使えるかは用途しだい：桁感と相対位置に使うなら一日の差は結論を変えない（Orca 75,454 対 二位目 28,168）；正確な数値に使うなら無理で、Orca 一本だけで同日に 1,700 増えている。引用するなら 2026-09-22 の記録に戻るか、その日に自分で取り直す。2026-10-19 確認。

いいえ。NOASSERTION は GitHub の自動照合が LICENSE ファイルを既知の条項に当てられなかっただけで、この 15 件の中に 3 件その表示があります。2026-10-19 にこの三件の README を見直すと、cmux の節には GPL-3.0-or-later でオープンソースだと書かれ、同じ段落に server ソフトウェアは BSL 1.1 とあります。Superset は app 全体をリポジトリに置き Elastic License 2.0 とし、除外しているただ一つの事柄は Superset そのものを販売するサービスに作り直すことだと書かれています。Worktrunk のバッジは MIT OR Apache-2.0 です。だからこの欄は README か、リポジトリの LICENSE ファイルで読むもので、判別失敗をライセンスなしには読み替えません。

7 件が MIT、5 件が Apache-2.0、1 件が AGPL-3.0（claude-squad）、Worktrunk は MIT と Apache-2.0 のどちらかを選べます。cmux は README によれば GPL-3.0-or-later、Superset は Elastic License 2.0 です。条項名のほかに、各 README はその条項が実際に何を認め何を禁じるかも書いています。Superset は ELv2 のもとで使えること、fork できること、改変できること、チーム用にセルフホストできることを述べています。cmux はその server ソフトウェアを Business Source License 1.1 に置いており、読み・改変・本番環境以外での実行は認めるが、本番での利用か自前運用には商用ライセンスが必要だと書き、同じ節に GPL に従えない組織には商用の条項が用意される場合があると添えています。MIT と Apache-2.0 の側では README に一行の許諾声明だけが残され、条項の本文はそれぞれがリンクする LICENSE ファイルに置かれています（emdash と agent-orchestrator はどちらもそうです）。AGPL はネットワーク越しに提供した場合のソースコード開示義務、ELv2 は製品そのものをサービスとして再販売することの明示的な禁止、GPL は派生物への伝播条件があり、いずれも「自由に使ってよい」MIT とは異なります。社内利用か外部向けサービスかでも結論が変わります。条項の全文は各リポジトリの LICENSE と README にあります。ライセンス分布の数は 2026-10-19 に確認し、引用した README の文は 2026-10-19 に取得したものです。

公開情報で見つかるのは使用者の自述で、基準測定ではありません。Orca の issue #10769（2026-07-26 投稿、取得日時点で open）は当時、あるリポジトリで 297 の worktree が生きているとき git commit の中央値が約 1.5 秒から 8.9 秒に上がり、ピーク 21.6 秒、.git は 1.1G で、原因は共有オブジェクトストアの自動保守の劣化だと述べていました。その因果は、投稿者本人によって後から覆されています。同じ本文の先頭には本人の追記が置かれ、後続の計測で当初の因果判断は否定され、301 の worktree は実測上の主因ではなく、--indexed-objects を足しても列挙のコストはほぼ変わらず、約 35 秒の重さは --reflog が 7,330 個の reflog ファイルを数える側にありました。その多くは Orca が管理する fork の remote が全てのブランチを引いたことで生まれており、fork ひとつだけで 2,470 個の ref と reflog ファイルが出ています。追記はさらに、worktree の数は手がかりとして役に立つが、このデータでは ~100 のような個数の閾値を Git のコスト予測にはできないと書き、元の報告は調査の経過として残しています。今も生きているのは製品側の課題です。遅い Git 操作が UI に見えず、ワークスペースや共有ストアの健全性へ症状からたどる道がないことです。示された実装方針は、管理する fork の fetch を --no-tags でそのブランチ一本に絞り、条件に合う、Orca が起こした commit と fetch がクリティカルパス上で自動保守を引き起こさないようにするものです。単一リポジトリ・単日の記録で、リポジトリの大きさや worktree 数が違えば結果も異なり、対象も Orca 一件だけです。自分が該当するかを見るなら、数えるのは自分のリポジトリの ref と reflog の規模、そして Orca が管理する fork が何本のブランチを引くかであって、worktree の個数ではありません。2026-10-19 に再確認。

表の中にちょうど逆の例があります：3 件は直近 push が 2026-06-01 より前で止まっており、その一つ crystal は ★3,120 でも最新 release は 2026-02-26 です。一方末尾の sculptor は ★232 で、最新 release は 2026-09-21 と、star の多いいくつかより新しいです。2026-10-19 に取り直すと sculptor は ★240 で、その日に sculptor-v0.49.0rc2 が出されていました。同じ回で取った crystal の README には Nimbalyst に置き換えられたと書かれ、★1,935 の nimbalyst の README もこの回で取得しました。選ぶ基準は制約への適合（ライセンス・形態・リポジトリの規模）と保守の活発さで、star は検索での注目度の副産物です。

2026-09-22 の回は 11 件の README 全文を取得して一字一句で照合し、残りの 4 件（nimbalyst、parallel-code、uzi、terragon-oss）はそのとき API のメタデータだけでした。だからあの三欄には「未取得」と書いてありました。2026-10-19 の回でこの 4 件の README をすべて取り直し、当日の原文どおりに埋め、取得日を行に書きました。ほかの 11 件の三欄は 2026-09-22 時点の原文のままです。この三欄が答えるのは「そのリポジトリの README にこの文があるかどうか」という問いです。原文があるときだけ内容が入り、あるリポジトリの言い回しを別の家には移しません。横評でいちばん高い間違いは、評価対象に言っていないことを言わせることです。