開発解説
AIが追加したコードと依存ライブラリを確認する｜ライセンスと保守状態の検収
目次
結論
AIが書いたコードは「testsが通る」だけで採用しない。新しいdependencyについて、実在・導入理由・license互換性・maintenance・known vulnerabilityを台帳化し、不明なpackageは採用保留にする。
比較・判断の対象は GitHub, OpenSSF。ブランドの知名度や一時的な評判ではなく、依存追加の理由・ライセンス・保守状況の台帳 を正本にし、出所 / ライセンス / 依存数 / 更新 / 脆弱性 を同じ条件へ揃えます。未確認項目は0点や「非対応」にせず 未確認/保留 のまま残します。
2026-09-13時点で確認した重要点
- GitHubのAI-generated code 確認 guidanceは、新規packageの実在、active maintenance、license互換性、hallucinated/suspicious packageを明示的に確認するよう求めている。
- dependency 確認/Dependabot等は機械的な差分・脆弱性確認を助けるが、導入理由やlicense判断そのものを自動で正当化しない。
- OpenSSF Scorecardはsecurity postureの補助証拠として使い、単一点数を採用/不採用の唯一の基準にしない。
判断表：依存追加の理由・ライセンス・保守状況の台帳
| Dependency | 追加理由 | 公式/registry URL | License | Maintenance 根拠 | Vulnerability | 判断 |
|---|---|---|---|---|---|---|
| pkg-a | 何のために必要か | URL | SPDX/宣言 | release/maintainer activity | alert/scan | 継続/保留 |
| pkg-b | 既存標準機能で代替不能か | URL | 未確認なら保留 | archive有無等 | alert/scan | 継続/保留 |
| transitive | 直接依存から入る理由 | lockfile/graph | 重要licenseのみ追跡 | version freshness | scanner | 監視 |
この表は本文の言い換えではなく、読者が自分の条件・公式source・実観測を入れて判断を再現するための作業票です。数値欄が空いている場合は、都合のよい仮定で埋めません。
最初に差分からdependencyを拾う
package manifestだけでなくlockfile、container、ワークフロー、scriptの追加も確認する。AIが「便利だから」と入れた依存は、標準libraryや既存dependencyで代替できるなら減らす。
licenseは名前で推測しない
repositoryのLICENSE、package registry、upstreamのofficial metadataを確認する。曖昧なlicenseやprojectのlicenseと両立しないものは、法務判断が必要なら保留へ送る。
maintenanceとsecurityを別に見る
最新releaseがあることと安全であることは同義ではない。archive状態、maintainer activity、Dependabot/Advisory、Scorecard等を別列に残す。
事実・観測・判断を混ぜない
この記事では、次の3種類を分けます。
- Official 事実 — pricing、plan、terms、support、feature availabilityなど、現在の公式情報で確認するもの。
- Local observation — 自分のaccount、端末、文書、ワークフローで実際に起きたこと。時間や品質を数字にするなら実際の観測結果を残す。
- 編集上の得失 — 「柔軟性を優先する」「多少高くても管理を減らしたい」など、読者が決める価値判断。
公式ページに無い数字を埋めたり、他人の体験値を自分の実測として扱ったりしません。仕様変更が起きた場合は、変わった項目だけを最新の情報源へ差し替えて同じ判断手順を再実行します。
実務での判断手順
- 目的を1文に固定する。 機能名ではなく、何を減らす・守る・移す・証明するのかを書く。
- 必須条件を先に置く。
出所を含め、欠けたら採用しない条件を決める。 - 最新の公式情報へ戻る。 検索snippetや古い比較表ではなく、公式help/terms/pricing/documentationの現行ページを読む。
- 自分の対象を固定する。 plan、purchase route、device、account種別、地域など条件を混ぜない。
- 判断表へ証拠を残す。 URL、確認日時、必要なら実際の観測結果を同じ行へ記録する。
- 停止条件を適用する。 不明点を平均点や想定値で埋めず、問い合わせ・小検証・保留へ戻す。
- 最後に費用・使い勝手を比較する。 必須条件を通過した候補だけを得失として比べる。
選ばない・進めない条件
実在・license・必要性のいずれかが確認できない新規dependencyは、動作していてもmergeしない。
これは注意書きではなく判断 gateです。条件が変われば同じ判断表へ戻って再評価できます。
よくある質問
一番おすすめを1つだけ決められますか？
用途、account、device、契約条件が異なるため固定1位にはしません。判断表の必須条件を通過した候補だけを比較します。
公式ページに書かれていない項目はどうしますか？
「ない」と推測せず未確認にします。必要なら提供元へ問い合わせるか、自分の環境で再現可能な確認を行います。
検索で見つけた古い料金・機能表を使ってよいですか？
変わり得る情報には使いません。検索結果は検索意図の確認に使い、公開時の料金・plan・policy・feature availabilityはcurrent 公式情報へ戻します。
一次情報
- GitHub Docs — 確認 AI-generated code — AI-generated codeは検証/securityだけでなく、新規dependencyの実在・maintenance・license互換性を検証するようcurrent guidanceを確認する。
- GitHub Docs — About dependency 確認 — pull requestで追加/更新/削除dependencyを確認するcurrent mechanismを確認する。
- GitHub Docs — About Dependabot alerts — known vulnerable dependencyのalertを確認材料へ加える。
- GitHub Docs — Licensing a repository — repository/dependencyのlicenseを明示的に確認する。
- OpenSSF Scorecard — open-source projectのsecurity postureを複数checkで確認する補助材料として使い、単一点数だけで採否を決めない。
まとめ
AIが書いたコードは「testsが通る」だけで採用しない。新しいdependencyについて、実在・導入理由・license互換性・maintenance・known vulnerabilityを台帳化し、不明なpackageは採用保留にする。
固定rankingではなく 依存追加の理由・ライセンス・保守状況の台帳 を残しておけば、仕様や価格が変わったときも、変化した事実だけを最新の情報源へ差し替えて同じ判断基準で再判断できます。
まとめ
- AIが書いたコードは「testsが通る」だけで採用しない。新しいdependencyについて、実在・導入理由・license互換性・maintenance・known vulnerabilityを台帳化し、不明なpackageは採用保留にする。 固定rankingではなく **依存追加の理由・ライセンス・保守状況の台帳** を残しておけば、仕様や価格が変わったときも、変化した事実だけを最新の情報源へ差し替えて同じ判断基準で再判断できます。