# Library Eval

> 依存ライブラリやツールを選ぶとき。「どのライブラリを使うべき？」「○○ と △△ を比較して」「この依存を入れて大丈夫か調べて」等で使う。候補を保守状況・採用度・ライセンス・脆弱性・API 適合で比較し、推奨とリスクを出す。成熟した定番ライブラリを優先する方針に沿う。

- Skill: `turntuptechnologies-ai/library-eval` (Agent Skill)
- Install (CLI): `npx skillmds@latest add turntuptechnologies-ai/library-eval`
- Raw SKILL.md: https://api.skillmd.com/api/skills/turntuptechnologies-ai/library-eval/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Integrations & APIs
- Author: turntuptechnologies-ai (https://skillmd.com/u/turntuptechnologies-ai)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/turntuptechnologies-ai/library-eval

---


# 技術選定調査（library-eval）

候補ライブラリ/ツールを意思決定向けに比較し、推奨を出す。**成熟した定番を優先**し、サプライチェーンは lock 層で固める前提。

> **裏取り・出典確認は `deep-research` のエンジンに委ねてよい。** 本 Skill は「選定の型」（評価軸・データ源・判断基準）を足す。`deep-research` が使えない環境では、本 Skill の手順の中で Web 検索・一次情報の参照により同等の裏取りを行う。

## 評価軸

| 軸 | 見るもの | データ源 |
|---|---|---|
| **保守・活発さ** | 最新リリース時期、コミット頻度、未解決 Issue/PR、メンテナ数 | GitHub、リポジトリ |
| **採用度** | DL 数・スター・依存元の多さ（広く使われているか） | npm / PyPI / crates.io、deps.dev |
| **ライセンス** | permissive か（**GPL 系は不可**） | パッケージメタdata、LICENSE |
| **セキュリティ** | 既知脆弱性・勧告、更新の速さ | OSV、GitHub Advisory、deps.dev |
| **API 適合 / DX** | 要件を満たすか、型・ドキュメント・使い勝手 | 公式 docs、README |
| **サプライチェーン** | 依存の深さ・transitive リスク、lock 固定可否 | deps.dev、lockfile |
| **規模・性能** | バンドルサイズ・実行性能（フロント等で重要なら） | bundlephobia 等 |

## 手順

1. **要件と候補を確定する** — 解きたい課題・必須要件（機能/ランタイム/ライセンス制約）と、比較する候補を挙げる。曖昧なら確認する。
2. **軸ごとに証拠を集める** — 上表のデータ源から事実を取る。**推測でなく一次情報**（リポジトリ・レジストリ・勧告 DB）で裏を取る。
3. **比較マトリクスにする** — 候補×評価軸の表で並べ、差が出る軸を強調する。列はこの形で揃える:

```markdown
| 候補 | 最終リリース | 採用度（週DL等） | ライセンス | 既知脆弱性 | API 適合 | 依存の深さ | 備考 |
|---|---|---|---|---|---|---|---|
| lib-a | 2026-06（活発） | 2.1M/週 | MIT | なし（OSV 確認済） | ◎ 要件を全て満たす | 浅い（3） | |
| lib-b | 2024-11（停滞気味） | 300K/週 | Apache-2.0 | CVE-2025-xxxx（修正済） | ○ 一部自前実装が必要 | 深い（27） | 単一メンテナ |
```
4. **推奨を出す** — 要件への適合と総合評価から推す候補を1つ挙げ、**根拠と残るリスク**（保守停滞・脆弱性・移行コスト等）を添える。

## ルール・コツ

- **ライセンスは必ず確認。** GPL 系（GPL/AGPL/LGPL）は不可、permissive（MIT/Apache-2.0/BSD/ISC 等）のみ（→ `license-policy` ルール）。transitive 依存のライセンスも見る。
- **成熟・保守されているものを優先。** 何でも自前実装しない。放置気味・単一メンテナ・低採用のものはリスクとして明記する。
- **既知脆弱性を確認。** OSV / GitHub Advisory で候補と主要依存をチェックする。
- **事実に出典を付ける。** DL 数・最終更新・脆弱性などは確認して数値・日付を示す（→ `deep-research` で裏取り）。
- サプライチェーン対策は依存選定だけでなく lock 固定で担保する前提を明記する。

## 完了条件

以下を全て満たしたら完了。**満たせない項目があれば、黙って省略せず理由を報告する。**

- [ ] 要件と候補を確定してから比較した
- [ ] **全候補のライセンスを確認した**（GPL 系が混ざっていない。transitive 依存も確認）
- [ ] OSV / GitHub Advisory で既知脆弱性を確認した
- [ ] 各事実（DL数・最終更新・脆弱性）に出典・日付を付けた
- [ ] 「比較マトリクス + 推奨1つ + 残るリスク」の形で結論を出した

## 補足

- 結論は「比較マトリクス ＋ 推奨1つ ＋ リスク注記」の形が意思決定しやすい。
- 学術文献は `literature-review`、市場・競合は `market-research` を使う。