Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

はじめに — このシリーズを書きながら実際に経験したこと
スター数は何を語り、何を語らないのか
メンテナンスのシグナルを自分で数える方法
ライセンスは常識で当て推量してはいけない
本番導入前のチェックリスト
最後に — 数字は時点の値である
リンク

はじめに — このシリーズを書きながら実際に経験したこと

前の5本を書きながら、リポジトリ59個を GitHub で直接確認しました。その過程で学んだことは、リストそのものよりも役に立つかもしれないと思いました。

いちばんはっきりした教訓はこれです。自分が知っていると思い込んでいた情報のかなりの部分が間違っていました。リポジトリが別のアカウントに移されていたり、ライセンスが記憶と違っていたり、活発だと思っていたプロジェクトの最新プッシュが3か月前だったりしました。確認していなければ、すべてそのまま書いていたはずです。

スター数は何を語り、何を語らないのか

スターは過去に誰かが関心を持ったという事実だけを教えてくれます。取り消されることがほとんどないので、事実上一方向にしか積み上がりません。プロジェクトが放置されても数字は減りません。

シリーズに出てきた具体例を見てみます。open-telemetry/opentelemetry-collector はスターが7,377個で、第4回のリストでは最も少ない部類でした。しかしこの部品は、数多くの組織のオブザーバビリティ・パイプラインのど真ん中にあります。プロジェクトがリポジトリを複数に分けているために、関心が分散しているだけです。

逆に browser-use/browser-use は、2024年10月に作られたリポジトリでありながらスター108,900個に達しました。大きな数字ですが、その数字がインターフェースの安定性を保証してくれるわけではありません。

スターは規模を測るものさしではなく、話題性を測るものさしです。

メンテナンスのシグナルを自分で数える方法

数字で確認できるものから見ます。以下は認証なしでも動きますが、1時間あたりのリクエスト制限が低いので、複数のリポジトリを見る予定ならトークンを付けたほうがよいです。

# 例: 基本情報と直近のリリース周期をまとめて確認
OWNER_REPO="ossf/scorecard"
curl -s "https://api.github.com/repos/${OWNER_REPO}" \
  | jq '{full_name, license: .license.spdx_id, stars: .stargazers_count, pushed_at, archived}'
curl -s "https://api.github.com/repos/${OWNER_REPO}/releases?per_page=5" \
  | jq -r '.[] | "\(.published_at[0:10])  \(.tag_name)"'

ここで見るべきものは次のとおりです。

最新コミットの日付: 数日単位なのか数か月単位なのか。第5回の bentoml/BentoML は確認時点の最新プッシュが 2026-08-03 で、第1回の Aider-AI/aider は 2026-05-22 でした。どちらも死んでいるという意味ではなく、もっと見るべきだというシグナルです。
リリース間隔: 日付が規則的か、最後のリリースからどれだけ経っているか。コミットはあるのにリリースが長らく出ていないなら、ユーザーに届くまでの流れが止まっているという意味かもしれません。
archived の値: 真ならリポジトリは凍結された状態です。
イシューへの応答: 最近開かれたイシューにメンテナーが数日以内に反応しているか。数ではなく、応答があるかどうかを見ます。
コントリビューターの分布: コントリビューターの数よりも、最近のマージを実際に実行した人の数が重要です。コントリビューターが数千人いても、マージ権限が2人に集中していればバス係数は2です。

最後の項目は自動化しにくく、いちばん重要です。このブログのバス係数についての記事でより詳しく扱いました。

ossf/scorecard（Apache-2.0、スター5,628個、最新プッシュ 2026-08-10 · 2026-08-12 時点）は、こうした点検のかなりの部分を自動化してくれます。ただし、スコアをそのまま合格基準として使うよりも、どの項目で減点されたのかを読むための道具として使うほうがよいです。

ライセンスは常識で当て推量してはいけない

このシリーズでいちばん驚いた部分です。59個のうち6個は GitHub がライセンスを自動分類できず、LICENSE ファイルを直接開いてみると内容はそれぞれ違っていました。

open-webui/open-webui は BSD 3条項の形に、ブランディングの削除を禁じる条項が加えられています。使用制限があるため、OSI が定義するオープンソースではありません。
oven-sh/bun の LICENSE は、Bun 自体は MIT であるという点と、LGPL-2 のライブラリを静的リンクするという点、そしてそれに伴う条件を併せて説明しています。
zed-industries/zed は LICENSE-GPL と LICENSE-APACHE を併せて置いています。
BerriAI/litellm と SigNoz/signoz は、特定のディレクトリだけ別のライセンスに従うと宣言しています。
pgvector/pgvector は、Postgres 系の寛容なライセンス文言を含んでいます。

まとめるとこうです。GitHub のサイドバーのライセンス表示は要約であって原文ではありません。そして、ソースを見られるという事実はオープンソースだという意味ではありません。AGPL のように条件は強くても OSI 承認のオープンソースである場合と、使用制限が付いていてオープンソースではない場合とを区別してください。

ライセンス全文を自分で確認し、商用導入は法務レビューを通してください。この記事は法律アドバイスではありません。

本番導入前のチェックリスト

技術的な検討が終わったあと、導入を決める前に、次のことを文書として残しておくことをおすすめします。

正確な owner/repo のパスを記録したか。名前の似たリポジトリや古いパスを参照していないか。
LICENSE ファイルの原文を読んだか。社内利用、再配布、サービス提供のうち、自分たちの用途はどれに当たるか。
最近のコミット、最近のリリース、イシューへの応答を自分で確認したか。
マージ権限は何人が持っているか。その人たちが抜けたらどうなるか。
プロジェクトは自分自身を何だと言っているか。1.0 より前だ、あるいは実験的だと明かしていないか。
自分たちが依存しようとしている機能は、オープンソースのリポジトリの中にあるか、それとも商用製品にしかないか。
離脱コストはいくらか。データを標準的な形式で取り出せるか。
脆弱性が公開されたとき、誰がいつ知ることになるか。

8つのうち1つでも答えられないなら、それが次に確認する項目です。

最後に — 数字は時点の値である

このシリーズのすべての数値に日付を付けた理由がここにあります。スター数と直近の活動は変わり続けます。日付のない数字は検証できず、検証できない数字は根拠になりません。

みなさんがこの記事を読む時点では、数字はすでに変わっているはずです。だからこそ、リストよりも確認する手順のほうが長持ちします。

リポジトリ情報（スター数・ライセンス・直近の活動）は 2026-08-12 に GitHub で直接確認した時点の値です。数値と状態は変わります。

リンク

シリーズ: 前の記事 — データと ML パイプライン · シリーズ最初の記事 — AI エージェントと LLM ツール

このブログの関連記事:

ツール: curl コマンドビルダー · JSON フォーマッター