AIが提案するライブラリを鵜呑みにしない｜依存追加前の確認
AIに書いてもらったコードを眺めていると、見慣れないライブラリを import してくることがありますよね。 「へえ、こんな便利なのがあるのか」と思って、そのまま npm install や pip install。動いた。よし次へ——。
その気持ち、よく分かります。せっかくAIがきれいに書いてくれたのに、いちいち止まって調べるのは面倒だし、動いているものを疑うのも気が引ける。でも、依存を1つ足すというのは、そのライブラリと長く付き合う決断でもあります。あとから「これ、もう更新されてないぞ」「そもそもこんなパッケージ、存在しなかった」と気づくと、直すのはけっこう骨が折れます。
この記事は、AIが提案してきたライブラリを、取り込む前の数分で確かめる型の話です。全部を疑ってかかろう、という話ではありません。「一度手を止めて、実在・生存・妥当性の3点だけ見る」——それだけで、後々の事故がかなり減ります。責める話ではないので、気楽に読んでください。
結論：AIが提案したライブラリは、install する前に3点だけ確認します。①実在するか（公式のレジストリ＝npm・PyPIなどに、その名前のパッケージが本当にあるか。AIは"それっぽい存在しない名前"を作ることがある）、②生きているか（最終更新・メンテ状況・スター/ダウンロード数。何年も放置されていないか）、③この用途に妥当か（標準ライブラリや既存の依存で足りないか、ライセンスは自社で使えるか、大げさすぎないか）。この3つは、パッケージのページを開けばだいたい3分で分かります。迷ったら、AIに"なぜこのライブラリなのか・標準機能では無理なのか"を説明させてから決める。依存は足すのは一瞬、外すのは大変。入り口でひと呼吸おくのが、いちばん安い保険です。
一度に全部やろうとしなくて大丈夫です。 まずは「見慣れない名前が出てきたら、install の前に一拍おく」。ここから始めましょう。
何が起きているのか——AIは「それっぽい名前」を出せてしまう
まず、なぜ確認が要るのかを共有させてください。AIが賢くない、という話ではありません。AIの得意なことの裏側に理由があります。
AIは、大量のコードを学習して「こういう処理には、こういうライブラリを使う」というパターンを覚えています。だから多くの場合、妥当な提案をしてくれます。ただ、AIは「もっともらしい名前」を作ることそのものが得意でもあります。その結果、こんなことが起きます。
- 実在しないパッケージ名を出す：
json-easy-parserのような、いかにもありそうで実際には存在しない名前をAIが生成することがあります。これは「ハルシネーション（もっともらしい誤り）」の一種です。厄介なのは、こうした"AIがよく口にする架空の名前"を狙って、悪意ある人が同じ名前の中身が危険なパッケージを先に公開しておく手口が知られていること。うっかり入れると、それを踏んでしまう恐れがあります。 - もう更新されていないライブラリを勧める：学習データが少し前の情報だと、数年前に主流だったが今は放置されているライブラリを、いまのおすすめのように提案することがあります。
- 大げさな依存を足す：数行の標準機能で足りる処理に、わざわざ大きな外部ライブラリを持ってくることがあります。動きはしますが、依存が1つ増えるぶん、保守もセキュリティ更新も付いて回ります。
- 用途とライセンスが自社に合わない：動作は問題なくても、ライセンスの条件が自社の使い方に合わないことがあります。これは動かして確かめても気づけません。
どれも、動かせば一見うまくいってしまうのが共通点です。だから「動いたからOK」で通してしまいやすい。 ここで一拍おいて、名前・生存・妥当性を見る。次から、その具体的な見方を順にいきます。
① 実在するか——「その名前のパッケージ、本当にある？」
いちばん先に、そして一番簡単に効くのが実在チェックです。存在しないパッケージ名を install しようとして事故る、という一番こわい入り口をここで塞ぎます。
やることはシンプルです。
- 公式レジストリで名前を検索する：JavaScriptなら npm 、Pythonなら PyPI 、といった公式のパッケージ置き場で、その名前をそのまま検索します。ヒットしなければ、実在しない可能性が高い。AIが名前を少し変えて覚えている（
-と_の違い、単数複数など）こともあるので、正確な綴りで確認します。 - 公式リポジトリ（GitHubなど）に飛べるか：レジストリのページから、ソースの置き場（GitHubなど）へのリンクをたどれるか見ます。まっとうなライブラリなら、たいていリポジトリが紐づいています。リンク切れや"それらしいが中身が薄い"ものは要注意。
- 「名前がそれっぽすぎる」ときほど疑う：
super-fast-xxxeasy-yyy-parserのように、機能をそのまま並べたような名前が突然出てきたら、一度立ち止まる合図です。
install してから確かめない：「とりあえず入れて動かしてみる」は、実在チェックだけは避けたいところです。存在しない名前を打ち込んだ瞬間に危険なものを拾う手口がある以上、"入れる前にページを見る"の順番を守るのが安全です。
ハルシネーションそのものの見抜き方は、AIのハルシネーションを見抜く前提と手順にもまとめています。パッケージ名は、その中でも特に確かめやすい（レジストリで一発で分かる）タイプなので、習慣にする価値があります。
② 生きているか——最終更新とメンテの気配を見る
実在しても、もう手入れされていないライブラリは別のリスクです。バグが直らない、脆弱性が放置される、新しい環境で動かない——将来の自分が困ります。パッケージのページで、次を軽く見ます。
- 最終更新（最新リリース）の日付：直近でリリースがあるか。何年も止まっているなら、採用は慎重に。分野によっては「枯れて安定」の場合もあるので、次の項目と合わせて判断します。
- ダウンロード数・利用数：極端に少ないものは、情報も少なく、詰まったときに頼れる先がありません。多ければ良いとは限りませんが、あまりに閑散なら一段警戒します。
- 未解決の問題（Issue）の様子：重大な不具合が放置されたままになっていないか、メンテナが反応しているか。ざっと眺めるだけでも空気は伝わります。
- スター数や「後継が出ている」情報：READMEに「このライブラリは非推奨。後継は◯◯」と書かれていることもあります。ここを見落として旧版を掴むのは、もったいない事故です。
全部を精査する必要はありません。「最終更新はいつか」「使われている気配があるか」の2つをまず見れば、生きているかどうかの大枠はつかめます。 AIが古い情報を今のおすすめのように出す件は、古い情報を学習したAIに最新仕様を扱わせるときの注意でも触れています。「いつ時点の話か」を自分で確かめるのが、ここでも効きます。
③ この用途に妥当か——「そもそも要る？」を最後に問う
実在して、生きている。それでも最後に一度、「これ、本当に足す必要ある？」を問い直します。依存は少ないほど、保守もセキュリティ更新も軽くなります。
- 標準ライブラリ・既存の依存で足りないか：言語の標準機能や、すでにプロジェクトに入っているライブラリで同じことができないか。数行で済む処理のために新しい依存を足すのは、たいてい割に合いません。
- 役割が大きすぎないか：やりたいのは小さな1機能なのに、何でもできる巨大ライブラリを丸ごと入れていないか。目的に対して過剰なら、もっと小さい選択肢を探します。
- ライセンスは自社で使えるか：商用利用の可否、表示義務、コードを公開する義務がないか。ここは動かしても分からないので、必ずページで確認します。AI生成物のライセンスの扱いはAIが書いたコードのライセンス・著作権リスクの実務に整理しています。
- セキュリティ面で不安がないか：既知の脆弱性が報告されていないか、権限を余計に要求しないか。判断に迷う所はAI生成コードのセキュリティ確認｜見落としやすい穴も合わせてどうぞ。
判断に迷ったら、AI自身に理由を説明させるのが手っ取り早いです。 「なぜこのライブラリを選んだの？標準機能では実現できない理由は？もっと軽い代替はある？」と聞くと、選定の前提が言葉になって出てきます。その説明を読んで納得できれば採用、あやしければ差し替え。頼む前提のそろえ方はAIにコードを書かせる前に渡す前提と制約が下敷きになります。
明日からやること（install の前の3つ）
重い仕組みは要りません。まずこの3つだけ。
- 見慣れない import が出たら、install の前にレジストリで名前を検索する：npm や PyPI で綴りどおりに引く。ヒットしなければ採用しない。これだけで一番こわい事故を防げます。
- パッケージのページで「最終更新」を1回見る：直近に動きがあるか。何年も止まっていたら、代替を一度探す。
- 「標準機能で足りないか」を一言、自分かAIに問う：足す前に「そもそも要る？」を1回だけ挟む。要らない依存は、足さないのが最善の対処です。
この3つは、慣れれば合わせて3分ほどです。install してから戻すことを思えば、ずっと軽い。 全部を毎回きっちりやらなくても、「名前の実在だけは必ず見る」から始めれば十分です。
依存を追加する前のチェックリスト
AIが提案したライブラリを取り込む前に、さっと確認します。全部に○が要るわけではなく、その依存で気になる所だけで十分です。
① 実在
- 公式レジストリ（npm / PyPI など）に、その名前のパッケージが実在するか
- 公式リポジトリ（GitHub など）へたどれて、中身が伴っているか
- 綴りが正確か（
-/_・単複の取り違えがないか） - 「機能を並べただけの、それっぽすぎる名前」で油断していないか
② 生存
- 最終更新（最新リリース）はいつか。何年も止まっていないか
- 使われている気配（ダウンロード数・利用数）があるか
- 重大な不具合が放置されていないか、後継への移行案内がないか
③ 妥当
- 標準ライブラリ・既存の依存で代替できないか
- 役割が目的に対して大きすぎないか
- ライセンスが自社の使い方に合うか
- 既知の脆弱性・余計な権限要求がないか
- （迷ったら）AIに「なぜこれ？標準では無理？」を説明させたか
この記事のまとめ
AIが提案するライブラリは、たいてい役に立ちます。 それでも、取り込む前のひと呼吸——実在するか、生きているか、この用途に妥当か——を挟むだけで、後から効いてくる事故がずいぶん減ります。全部を疑う必要はありません。「見慣れない名前は、install の前にページを見る」。まずはこの一手からで十分です。
依存を1つ足すか足さないかは、地味だけど大事な判断です。 今日、「見慣れないパッケージ名を、入れる前にひとつ確かめられた」なら、それはもう将来の自分を助ける一手です。名前の見抜き方はハルシネーションを見抜く手順、受け取ったコード全体の見方はAI生成コードのレビュー・検証チェックリストも、必要なときにのぞいてみてください。