AIが追加する危ない依存パッケージをツール「safer-dependencies」はどう防ぐのか

「開発にAIのコーディング支援を入れたら、知らないパッケージ（外部の部品として取り込むソフトウェア）がいつの間にか増えていた」「AIが選んだ版に既知の脆弱性がないか、誰がいつ確かめているのか分からない」——開発部門にAIエージェントを広げ始めた企業の、情報システムやセキュリティの担当者から聞こえてくる声です。どちらも、検査の道具を一つ足せば済む話に見えます。けれど本当に問われているのは道具の有無ではありません。AIが部品を選んで書き込む流れの中に、誰がどこで確認を挟むのかが決まっていないことです。この記事では、Claude Code（Anthropic のコーディング用AIエージェント）が依存パッケージを追加するときに割り込んで調べ、危ない版を自動で直すツール「safer-dependencies」を取り上げます。確かめられる事実、守れる範囲と守れない範囲、ライセンスの条件、企業が導入前に決めておくべき点を整理します。導入や操作の手順は扱いません。

safer-dependenciesとは何か。2026年10月時点で確かめられる事実

safer-dependencies は、GitHub で公開されているツールです。リポジトリの説明によれば、Claude Code がプロジェクトに部品を加える前後に割り込み、危ない依存パッケージを見つけて直す安全の層です。対象は npm・PyPI・RubyGems・Maven・Go・Rust の6つの配布元で、README では PHP の Composer を加えた7つが挙げられています。リポジトリの概要欄と README で数が食い違っている点は、導入前に確かめたい細部の一つです。

公開の時期と規模も押さえておきます。リポジトリの作成は2026年6月30日で、リリースの一覧では7月1日の版が「最初の公開版」とされています。最新の版は8月31日の0.6.1で、それ以降は2026年10月23日の確認時点で更新が見当たりません。スターは41、フォーク（派生のリポジトリ）は0、コミットは8件と、まだ小規模で、利用の実績が積み上がっている段階ではないことが分かります。

作者は Robert Auger 氏の個人アカウントです。アカウントの作成は2025年1月で、公開しているリポジトリはこの1件だけでした。プロフィールにはセキュリティ関連のサイトが載っていますが、運営の体制や作者の実績を一次情報だけで評価することは難しいのが現状です。GitHub のセキュリティ勧告の欄には、確認時点で公表された勧告はありませんでした。

なぜ今、AIが選ぶ依存パッケージが問題になるのか

README は、このツールが生まれた問題を率直に書いています。AIのコーディング支援がパッケージを加えるとき、既知の脆弱性があるか、保守が続いているか、有名な部品に似せた偽物ではないかを確かめずに、もっともらしい版を選びがちだ、という指摘です。人が部品を選ぶときに無意識に行っていた確認が、AIに任せた瞬間に抜け落ちやすくなります。

部品の供給網（サプライチェーン）を狙う攻撃は、AI以前から続いてきました。有名な部品と一文字違いの名前で不正な部品を配る手口や、公開されたばかりの版に不正なコードを紛れ込ませる手口です。AIエージェントが人の確認なしに部品を加え、そのまま取り込みの処理まで進めるようになると、人が一瞬立ち止まって名前や版を見直す機会が減るという変化が起きます。

さらに、AIは存在しない部品の名前を作り出してしまうことがあると広く指摘されています。公式文書も、配布元に実在しない名前を「AIの作り話か、社内専用の部品の可能性がある」として知らせる検査を備えています。つまりこのツールは、AIが部品を選ぶ流れに、人が行っていた確認を機械として差し込む試みだと捉えると分かりやすくなります。

仕組みの全体像：手順書（スキル）とフックの組み合わせ

README によれば、このツールは一つの手順書ではなく、スキルとフックの組み合わせです。スキルは、AIエージェントに読ませる作業の手順書のことで、どんなときにどう調べるかが書かれています。フックは、Claude Code がファイルを書く・命令を実行するといった操作の前後に、決まった処理を自動で走らせる仕組みです。

なぜ両方が要るのかは、公式の質問集が説明しています。スキルは、AIが「この場面に当てはまる」と判断したときにしか動かず、動かなかった記録も残りません。手順書だけでは、AIの判断しだいで確認が抜けるため、AIの判断に関係なく操作のたびに必ず動くフックで網を張る、という設計です。一方でスキルには、取り込み先の書き換えや大きな版の上げ下げの判断など、フックにはできない作業が残されています。

この設計は、AIエージェントに安全の確認を任せるときの一般的な教訓とも重なります。AIの良識や判断に頼る確認は、確認しないこともありうる。だから、必ず通る場所に機械の関門を置く。safer-dependencies は、その考え方を部品の選び方に当てはめた例と言えます。

5つの場面で動く監視の網

README は、動く場面を5つに分けて説明しています。一つ目は、AIが取り込みの記述や部品の追加を書くときにスキルとして調べる場面です。二つ目は、部品の一覧を書いたファイル（マニフェスト）や、実際に使う版を固定したファイル（ロックファイル）が書き込まれた直後に動くフックで、脆弱な版を安全な版にその場で書き換え、安全な版がなければ一覧から外すとされています。

三つ目は、AIが部品の取り込みの命令を実行する前に動くフックで、明示された版に既知の脆弱性があれば実行を止めます。四つ目は、命令の実行後に動くフックで、新たに変わったロックファイルを調べ、部品が間接的に呼び込む別の部品（推移的な依存）の脆弱性を拾います。五つ目は、AIが下請けのエージェント（サブエージェント）に作業を任せたとき、戻ってきた後にその間の書き込みをまとめて調べる仕組みです。

このように、書き込み・命令・下請けという複数の通り道に網を張っている点が、このツールの特徴です。ただし公式文書は、Claude Code の外で行われた書き込みは対象外だと明記しています。開発者が自分の編集画面で保存した変更や、別の端末の操作は見ていません。網の範囲はあくまで、AIエージェントの操作に限られます。

何を調べるのか：既知の脆弱性・紛らわしい名前・放置されたパッケージ

公式文書が挙げる検査は8種類です。中心になるのは、公開の脆弱性情報の集積である OSV への照会と、配布元ごとの検査の道具による既知の脆弱性（CVE など）の確認です。加えて、有名な部品と綴りが1〜2文字だけ違う名前を「紛らわしい名前（タイポスクワット）」として知らせます。

保守が止まった部品にも目を向けています。作者がまとめた「放置された部品」の一覧に当たるものは、代わりの候補を示したうえで止め、安定版が2年以上出ていない部品には参考の警告を出します。そのほか、配布元に実在するかの確認、PyPI の部品の改ざん検知のための照合、署名ファイルの有無の確認、一度直した版が再び持ち込まれていないかの確認があります。

注意したいのは、署名は「あるかどうか」だけを見て、正しいかどうかは検証していない点です。公式の質問集は、署名の普及が進んでいない配布元が多く、検証しても安全の証明にはならないと理由を説明しています。紛らわしい名前の検知についても、取りこぼしを避ける調整のため誤検知が出ることを前提にしており、名前が似ているだけの正規の部品も止まることがあると明記しています。そのため、この検知では部品を外さず、利用者に確認を求める動きになっています。

README は、見つかった問題を4段階の重さで知らせるとしています。紛らわしい名前のように最も重いものは作業を止めて利用者に尋ね、既知の脆弱性や公開から日の浅い部品は警告を出したうえで先へ進みます。つまり、警告が出ても作業そのものは続くことが多い設計です。警告を誰が読み、どう判断するかを決めておかないと、表示が流れて終わるおそれがあります。

新しすぎる版を避ける「待機期間」という考え方

このツールの特徴の一つが、公開から7日たっていない版を避ける待機期間です。README によれば、7日以上前に公開された最新の安定版を選び、試験版は除きます。公開直後の版に不正なコードが紛れ込み、数日で発覚して取り下げられる、という供給網攻撃の典型に備える考え方です。

待機期間には例外があります。より新しい版が、使おうとしていた版の脆弱性を直したものだと OSV に記録されている場合だけ、待機期間を飛ばしてその版を選びます。公式の質問集は、リリースの説明文の「修正済み」という記述は信じないと書いています。乗っ取られた配布者が説明文を偽れるため、第三者の脆弱性情報だけを根拠にするという判断です。

一方で、限界も公式文書に書かれています。待機期間は、npm・PyPI・RubyGems・Rust の配布元でしか効かず、Maven と Go には掛かりません。また、7日を過ぎるまで待つ攻撃者は、この関門をそのまま通れるとも明記されています。待機期間は被害の多くを減らす工夫であって、すべてを防ぐ壁ではありません。

社外に出る情報と、手元に残る記録

社内で使う道具を選ぶとき、何が社外へ送られるかは必ず確かめたい点です。公式のプライバシーの文書によれば、外部へ送るのは、部品の名前と版、配布元の種類で、送り先は OSV と各配布元の公開の窓口、GitHub の窓口です。部品の一覧のファイルの中身、ソースコード、ファイルの場所、環境の設定、利用者を識別する情報は送らないとされています。

例外として、利用者が GitHub の認証用の鍵を環境に設定している場合、その鍵を GitHub の窓口への問い合わせに使うと書かれています。また、利用状況を作者に送る仕組み（テレメトリ）はないと明記されています。ただし、これらは作者の説明であり、この記事では実際の通信を確かめていないことを添えておきます。

手元には、検査の結果を月ごとに残す監査ログが作られます。ここにはプロジェクトの場所を示す完全なパスが記録されるため、社内の案件名がフォルダ名に入っている組織では、ログの扱いにも気を配る必要があります。公式文書には、パスや部品名を伏せて記録する選択肢があることも書かれています。社内専用の部品の名前が公開の窓口に問い合わせられる点も含め、社内の部品名そのものが外に出てよい情報かを、事前に判断しておくことが大切です。

類似の手段との違い

依存パッケージの安全を確かめる手段は、ほかにもあります。人による確認、依存関係を自動で更新する仕組み、継続的インテグレーション（変更のたびに自動で試験を回す仕組み）の中での脆弱性検査などです。safer-dependencies は、これらと競うというより、AIエージェントが書き込む瞬間という、これまで手薄だった地点を埋める位置にあります。

手段	確かめる時点	強み	弱み・注意
人による確認	取り込みの依頼を見るとき	文脈を踏まえて判断できる	量が増えると見落としが出る
依存関係の自動更新の仕組み	定期的・脆弱性の公表時	既存の部品を継続的に見直す	AIが書き込む瞬間は見ていない
継続的インテグレーションでの検査	変更を共有の場に送った後	全員の変更に同じ基準を掛けられる	手元で取り込みが済んだ後になる
safer-dependencies（このツール）	AIが書き込む・取り込む前後	AIの操作に即座に割り込み、自動で直す	AIの操作以外は見ない。調べられないときは通す

表のとおり、どの手段にも見ていない場所があります。このツールは手元の最初の地点で効く代わりに、すでに入っている部品の継続的な見直しはしないと公式文書に書かれています。手元の関門と、共有の場での検査を重ねて使うのが、現実的な組み合わせだと考えられます。

安全性の評価：注意付きとした根拠

このラインでは、扱うツールをクローン・導入・実行せず、公開されている情報だけで安全性を判定しています。safer-dependencies の判定は「注意付き」です。根拠は4点あります。一つ目は、リポジトリのライセンス欄が判別不能と表示され、中身は独自の条件付きライセンスであること。二つ目は、Claude Code のフックとして動き、部品の一覧のファイルを自動で書き換えることです。

三つ目は、作者の公開リポジトリがこの1件だけで、運営の実績を外から評価しにくいこと。四つ目として、確認時点で公表されたセキュリティ勧告はなく、取り込み時に自動で動く処理を置いたファイルもリポジトリの最上位には見当たりませんでした。勧告がないことは良い材料ですが、公開から4か月ほどで利用者も少ないため、問題が見つかっていないのか、まだ見つける人が少ないのかは区別できない点に注意が要ります。

このツールそのものは防御のための道具で、悪意を示す材料は見つかっていません。ただし、問題が見つからなかったことは安全の保証ではありません。開発者の端末で、AIエージェントの操作のたびに動く処理である以上、一般的な社外の道具よりも慎重な評価が求められます。

ライセンスの注意：ソースは公開されているがOSSではない

GitHub の表示ではライセンスが判別不能になっていますが、ライセンスの本文を読むと、作者独自の条件を定めた第1版のライセンスです。README とライセンス本文の双方で、意図してOSI承認のオープンソースのライセンスにしていないと明記されています。そのため、この記事ではOSSではなく「ツール」と呼んでいます。

条件の中身は、社内で使う企業には比較的ゆるやかです。営利企業を含め、自社の目的で無償で使え、改変も再配布もできます。自社の製品を作る・試す・守るために使い、その製品を売ることも妨げられません。一方で、ツールそのものを売る、販売する製品に組み込む、有償のサービスとして他社に提供する場合は、別の契約が必要とされています。再配布や改変版では、ライセンスと出典の表示を残す義務もあります。

保証はなく、現状のまま提供されるとも書かれています。社内の開発基盤にこのツールを組み込み、顧客向けのサービスの一部として提供するような使い方を考えている組織は、法務の確認を通してから判断するのが安全です。社内の開発者が自分の端末で使う範囲でも、独自ライセンスの道具を使ってよいかの社内規程があれば、それに従ってください。

自動で書き換えることと、調べられないときに通す設計

このツールの性質で最も注意したいのは、部品の一覧のファイルを人の確認なしに書き換える点です。公式の質問集によれば、脆弱な版は安全な版にその場で書き換えられ、放置された部品や安全な版のない部品は一覧から外されます。便利な一方で、どの部品がいつ、なぜ変わったのかを人が把握していないと、後から動作の変化に気づいても原因をたどりにくくなります。

書き換えは、書き込みの直後に行われます。公式の質問集は、書き込みを止める方式にしなかった理由として、検査の失敗で作業が止まらないようにするためと説明し、その代わり1〜5秒ほど、脆弱な版がファイルに書かれたままの時間があると認めています。

もう一つが、調べられないときは通す設計です。公式文書によれば、脆弱性情報の窓口が応答しない、必要な実行環境がない、時間切れになった、といった場合、既定では警告だけ残して操作を許してしまうとされています。止める側に切り替える設定もありますが、効くのは取り込みの命令の前の関門だけで、書き込みの後の書き換えは通す動きのままです。ネットワークを絞った環境や、外への通信を遮る社内網では、検査が成り立たず素通りになる可能性があります。

守れない範囲を先に知っておく

公式文書は、守れない範囲を正直に列挙しています。まだ公表されていない脆弱性、脆弱性情報や配布元そのものが侵害された場合、配布者のアカウントの乗っ取りは、勧告が出るまで見抜けません。有名な名前のまま中身がすり替えられた部品や、見た目の似た別の文字を使った名前も対象外です。

取り込み時に部品が自動で走らせる処理も、このツールは隔離していません。すでに入っている部品の継続的な見直し、書き込みで触れられなかった既存の部品、対象外の配布元の部品も見ません。対象外の配布元には「調べていない」という目印を付けるだけです。

つまりこのツールは、AIが新しく部品を持ち込む瞬間の、公表済みの危険に強い道具です。それ以外の守りは、別の手段で担う必要があります。導入の判断では、この範囲を社内に説明し、「入れたから部品の安全は大丈夫」という誤解が広がらないようにすることが欠かせません。

悪用されうるリスク

safer-dependencies は防御の道具ですが、使い方や置かれ方によっては危うさも生まれます。ここでは概要の水準で、推測を含むものは推測として挙げます。一つ目は、守りの道具そのものが入り口になる可能性です。このツールは開発者の権限で、AIの操作のたびに自動で動きます。公式のセキュリティの文書は、更新の取り込みで作者のアカウントと GitHub の通信の安全を信頼する前提にあり、版の署名による検証はしていないと明記しています。作者のアカウントが乗っ取られた場合の影響は、一般論として小さくないと考えられます。

二つ目は、守れない範囲の一覧が公開されていることです。守る側には誠実な情報ですが、攻撃者にとっては避けて通る道の地図にもなりえます。待機期間を過ぎるまで待つ、対象外の配布元を使う、といった回避は、公式文書自体が限界として認めているものです。三つ目は、自動で直してくれるという安心が、人の確認を減らしてしまうことです。これは道具の欠陥ではなく、使う組織の側で起きうる問題です。

導入を検討するときに確かめること

導入を考えるなら、操作の手順より先に、組織として決めておくことがあります。次の順に確かめると、判断の抜けを減らせます。

企業が取るべき対策

このツールを入れるかどうかにかかわらず、AIエージェントが部品を選ぶ時代の対策として、企業が整えておきたい点は次のとおりです。一つ目は、AIエージェントが部品を加えたことを、人が必ず見る地点を作ることです。部品の一覧やロックファイルの変更は、共有の場に反映する前の確認で必ず目に入るようにします。

二つ目は、手元の関門と共有の場の検査を重ねることです。手元の道具は個人の端末の設定に左右され、外されたり古いまま放置されたりします。変更を集める場所で、同じ基準の脆弱性検査を全員に掛けておくと、手元で漏れたものを拾えます。三つ目は、使ってよい部品と配布元を社内で決めておくことです。社内専用の部品の名前が公開の配布元で乗っ取られる手口にも備えられます。

四つ目は、開発者の端末で動く拡張やフックの台帳を作ることです。AIエージェントに足した手順書やフックは、それ自体が社外から持ち込んだソフトウェアです。誰がどの端末に何を入れたか、版はいつ更新したかを把握しておくと、作者側で問題が起きたときにすぐ影響の範囲をつかめます。

AIに任せる範囲と、人が決める範囲

このツールは、部品の安全の確認の一部を機械に任せるものです。だからこそ、人が決める範囲をはっきりさせておく必要があります。どの部品を使ってよいか、自動の書き換えを受け入れるか、警告をどう扱うかは、AIにもツールにも判断させず、人が決めます。

AIに任せてよいのは、決めた基準の範囲で候補を調べ、理由を添えて示すところまでです。公式文書でも、大きな版の上げ下げなどはスキルの側で判断し、紛らわしい名前の疑いでは利用者に確認を求める設計になっています。変更には根拠を書かせ、根拠ごと人が確かめてから取り込むという進め方を崩さないことが大切です。次のような使い方は避けてください。

• ツールを入れたことを理由に、AIが加えた部品の差分を人が見なくなる
• 警告が出ても作業が続くからと、警告の中身を誰も読まない
• 調べられないときは通す設計を知らないまま、外への通信を絞った環境で頼り切る
• ライセンスを確かめずに、顧客向けのサービスや販売する製品に組み込む
• 作者の更新を確かめないまま、古い版を開発者の端末に置き続ける

• この記事の内容は、safer-dependencies のリポジトリ・README・公式の文書・リリースの一覧・セキュリティ勧告の欄を2026年10月23日に確かめた範囲に基づきます。ツールは導入・実行しておらず、通信や書き換えの動きは作者の説明によるものです
• 対象の配布元の数は、リポジトリの概要欄（6つ）と README（7つ）で食い違っています。仕様や条件は変わることがあるため、導入前に最新の一次情報を確かめてください

まとめ

safer-dependencies は、Claude Code が依存パッケージを加える瞬間に割り込み、既知の脆弱性・紛らわしい名前・放置された部品・公開直後の版を調べて自動で直すツールです。手順書（スキル）だけでなく、AIの判断に関係なく動くフックで網を張る設計は、AIの判断に頼らない確認を必ず通る場所に置くという考え方の良い見本です。

一方で、ソースは公開されていても独自ライセンスでOSSではなく、販売や有償サービスへの組み込みには別の契約が要ります。部品の一覧を自動で書き換え、調べられないときは通す設計で、AIの操作の外や未公表の脆弱性は守れません。作者の公開リポジトリは1件だけで、利用の実績もまだ小さい段階です。

導入を考える企業は、ライセンス・社外に出る情報・自動の書き換えを人が確かめる流れ・調べられないときの扱いを先に決め、試験用のプロジェクトで小さく試してください。道具が何を見て何を見ないかを知り、最後の判断は人が持つことが、AIに部品を選ばせる開発を安全に進める土台になります。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。