OSS プロジェクトの健全性をどう定量化するか
機能の先にある問い
技術選定の際、チームは機能、性能、API 設計を丁寧に比較します。しかし体系的に評価されることの少ない問いが一つあります。このプロジェクトは 3 年後も誰かが保守しているのか、という問いです。
これは杞憂ではありません。部品がひとたび依存ツリーに入れば、その保守状況はそのまま自社のリスクになります。保守が止まったプロジェクトが意味するのは、新しい脆弱性に修正が出ないこと、新しい実行環境に追随しなくなること、そしてセキュリティ事案が起きたとき自力で対処するしかないことです。そして移行のコストは、導入時に評価へ二日多く費やすコストより、ほぼ確実に高くつきます。
健全性評価の価値はここにあります。それが予測しているのは「脆弱性が出てからどれだけ早く修正が届くか」であり、この数字がそのままリスクの露出度を決めます。
定量化できる 4 分類
### 1. リリースとコミットの周期
最も基本的な活動の指標ですが、見るべきは絶対的な頻度ではなく規則性と傾向です。
- 直近のリリースからどれだけ経っているか。1 年以上は通常、明確な警戒信号です（本当に完成している小さなユーティリティは例外です）。
- リリース間隔は安定しているか。それとも月次から半年に一度へ変わったか。
- コミットの推移は横ばいか、増加か、それとも継続的に減衰しているか。
「成熟して安定している」と「事実上停止している」を区別してください。判定方法は、issue と PR に応答があるかどうかです。リリースは止まっていても質問には答えているプロジェクトと、すべての経路が沈黙しているプロジェクトでは、リスクがまったく異なります。
### 2. 貢献者の集中度（bus factor）
最も見落とされやすく、最も予測力のある指標です。
bus factor が問うのは、中核の貢献者が何人同時に離れたらプロジェクトが停滞するか、です。値が 1 であれば、プロジェクト全体が一人に依存していることを意味します。
測定できる観点には、直近 1 年のコミット数上位 3 名が全体に占める割合、コミット権限を持つ人数、維持者が何らかの組織に属しているか（組織の後ろ盾は継続的な資源の投入と後継の仕組みを意味します）などがあります。
xz 事案の兆候を振り返る：あの事案で攻撃者が長期にわたり浸透し最終的に維持権限を得られたのは、まさに元の維持者が一人で担い、消耗し、助けを強く必要としていたからでした。事後に見れば、「単独維持 + 長期の負荷 + 突然現れた熱心な貢献者」は一組の完全なリスク信号です。そしてこれらの信号は、事案の発生前にすべて公開されていて誰でも見られる状態にありました。
### 3. 応答速度
コミュニティがまだ「生きている」ことの最も直接的な証拠は、外部からの入力への応答です。
- issue の応答時間の中央値はどれくらいか。一度も返答のない issue はどれだけあるか。
- PR は提出から審査までどれくらいかかるか。長期間放置されている PR はどれだけあるか。
- セキュリティ問題の専用報告経路（security.txt、SECURITY.md）はあるか。過去のセキュリティ対応の速度はどうだったか。
最後の点はセキュリティ評価で特に重要です。セキュリティ対応の手順を持たないプロジェクトは、コード品質がいかに高くても、脆弱性が出たときに確実性を与えてくれません。
### 4. 資金と統治構造
やや定性的な指標ですが、長期的な持続可能性を左右します。
- 財団（Linux Foundation、Apache、CNCF）がホストしているか、企業の支援があるか。
- 統治文書、意思決定の手順、貢献者協定が明示されているか。
- 資金源はあるか（スポンサー、商用製品、中核維持者の雇用）。
個人の余暇プロジェクトが使えないという意味ではありません。優れた基盤ライブラリの多くがそこから始まっています。ただしリスクの性質が異なることを意味するので、既定で無視するのではなく、導入審査の記録に明記すべきです。
既存のデータ源
この評価をゼロから構築する必要はありません。
- OpenSSF Scorecard はプロジェクトを自動採点し、コードレビュー、ブランチ保護、依存関係の更新、CI のセキュリティテストなどを覆います。基準としてそのまま参照できます。
- リポジトリのメタデータ（貢献者、コミット履歴、リリースの時系列）だけでも、指標の大部分は算出できます。
- セキュリティ対応の履歴は CVE の記録から逆算できます。そのプロジェクトの過去の脆弱性について、公開から修正までどれだけかかったか。
注意を促しておきたいのは、スター数が最も当てにならない指標であるという点です。それが表すのは過去の話題性であって現在の健全性ではなく、スターの多いプロジェクトが実は長く停止しているという例はいくらでもあります。
導入審査に組み込む
健全性評価を実務に落とす方法は、導入判断の明示的な工程にし、依存の重要度に応じてしきい値を変えることです。
中核依存（本番に入り、差し替えが難しい）——要求は高めに。活発な保守、bus factor が 1 より大きいこと、セキュリティ対応の経路があること。満たさない場合は、アーキテクチャ上の隔離案か代替品の評価を求めます。
一般依存——健全性の評点を記録し、定期的な見直しに含め、衰退の兆候が出た時点で移行を前倒しで計画します。
開発ツールの依存——しきい値は緩めてよいものの、登録は必要です。ビルド環境も攻撃面だからです。
同じく重要なのが継続的な監視です。健全性は変化します。導入時点では活発だったプロジェクトが、2 年後には停止していることもあります。健全性を定期的な依存関係の見直し（たとえば四半期ごと）に組み込むほうが、導入時に一度見るだけよりはるかに有効です。
より根本的な視点
コミュニティの健全性を評価することは、本質的には長期的な関係を評価することです。単にコードを使っているのではなく、自社の信頼性の一部を、会ったこともない人々に託しているのです。
これは OSS を避ける理由にはなりません。現代のソフトウェアは OSS なしには成り立ちません。しかし「誰が、どれだけの期間保守するのか」という問いを、「機能が要件を満たすか」と同じ重要度の位置に置く理由にはなります。
---
関連記事：企業の OSS 導入審査制度をどう築くか · EOL となった OSS 部品のリスク対応 · OSS・SBOM 実践ガイドのプロジェクト健全性項目
