依存関係
ライブラリやパッケージを取り込んで使うことを依存と呼びます。依存の実体は、他人が書いて他人が保守しているコードを、自分の製品の権限で実行することです。この一文を覚えておくと、リスクも対策も素直に見えてきます。
依存のリスク
他人のコードの脆弱性は、そのまま自分の製品の脆弱性になります。他人が保守をやめれば、そのコードの面倒は自分が見ることになります。そして依存が増えるほど、更新と引き継ぎの手間が積み上がります。
実行の機会は、製品が動く時だけではありません。多くのパッケージはインストール時に付属の処理を実行できるため、追加した時点でそのコードはあなたの権限で動いています。プログラムを実行することの意味はClaudeへの権限で説明しています。
だから依存の追加は「動いたから採用」ではなく、理由を確認してから受け入れます。判断材料はClaudeに集めてもらえます。
プロンプトの例
このライブラリを追加する理由と、追加しない場合の代替案を説明して
このライブラリの最終更新、利用実績、保守の状況を調べて
既知の脆弱性を確認する
広く使われるライブラリの脆弱性は公開データベースへ集約されており、自分の依存にそれが含まれるかは機械的に調べられます。公開前と、公開後も定期的に確認します。
プロンプトの例
依存に既知の脆弱性がないか調べて、危険なものは更新して
ライセンス
公開されているコードには利用条件（ライセンス）が付いています。多くは商用利用できますが、コードの公開義務など条件付きのものもあります。リポジトリをpublicにする前や、製品を販売する前に確認します（リポジトリの公開範囲）。
プロンプトの例
依存のライセンスに、商用利用や公開の制約があるものがないか確認して
放置しない
依存は放置すると、脆弱性と互換性の問題が溜まり、まとめて更新する時の危険が増します。運用中の製品では時々まとめて更新し、動作確認まで含めてClaudeに任せます。
プロンプトの例
依存を最新にして、テストと主要画面の動作確認までやって