turntuptechnologies-ai 技術選定調査（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 等 |
手順
- 要件と候補を確定する — 解きたい課題・必須要件（機能/ランタイム/ライセンス制約）と、比較する候補を挙げる。曖昧なら確認する。
- 軸ごとに証拠を集める — 上表のデータ源から事実を取る。推測でなく一次情報（リポジトリ・レジストリ・勧告 DB）で裏を取る。
- 比較マトリクスにする — 候補×評価軸の表で並べ、差が出る軸を強調する。列はこの形で揃える:
| 候補 | 最終リリース | 採用度（週DL等） | ライセンス | 既知脆弱性 | API 適合 | 依存の深さ | 備考 |
|---|---|---|---|---|---|---|---|
| lib-a | 2026-06（活発） | 2.1M/週 | MIT | なし（OSV 確認済） | ◎ 要件を全て満たす | 浅い（3） | |
| lib-b | 2024-11（停滞気味） | 300K/週 | Apache-2.0 | CVE-2025-xxxx（修正済） | ○ 一部自前実装が必要 | 深い（27） | 単一メンテナ |
- 推奨を出す — 要件への適合と総合評価から推す候補を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を使う。