AIが作った業務システムに入り込む外部部品を点検する五つの観点

AI が作った業務システムは、自分で書いたコードより、外から持ち込んだ部品のほうを先に点検してください。AI は動くものを早く作るために、パッケージという既製の部品を何本も呼び込みます。その名前が本物か、版が固定されているか、既知の欠陥が見つかっていないか、本当に使われているか、更新を誰が入れるか。この五つを確かめる点検です。画面や設計の点検とは別の作業で、見落とすと、自社のコードに誤りが一行もなくても事故が起きます。

外から来る部品は、コードの大部分を占める

業務システムは、外部のパッケージの上に載っています。直接使うものだけでなく、そのパッケージが呼ぶ別のパッケージ（間接の依存）も含みます。AI に画面を作らせると、依存の数は人が選ぶときより増えやすくなります。必要になるたびに、AI が手近な部品を足していくからです（これは推測です。今回の調査で数を測ったわけではありません）。

OWASP は2025年の Web アプリケーションの主なリスクの一覧で、「ソフトウェアサプライチェーンの不備」を3位に置きました。開発の過程や配布、更新のどこかで、脆弱な、あるいは悪意のある外部のコードや道具が入り込むことを指します。OWASP の集計では、この分類の平均の発生率は5.19%で、全分類のなかで最も高い値でした。コミュニティ調査でも、回答者の50%が1位に挙げています。

自社のシステムを点検するとき、サプライチェーンという言葉は大きすぎます。作業としては、「このシステムが使っている外部部品の一覧を作り、一つずつ確かめる」ことです。以下の五つの観点で進めます。

1. その名前は本物か

AI が書いたコードに、存在しないパッケージ名が出てくることがあります。USENIX Security 2025 に載った研究は、16種類のコード生成モデルに57万6,000件のコードを書かせ、依存として挙げられたパッケージを調べました。実在しない名前の割合は、平均で商用モデルが5.2%以上、オープンモデルが21.7%でした。存在しない名前は、重複を除いても20万5,474種類ありました。

この数字は、研究用に用意された依頼文に対する結果です。自社の依頼でこの割合になるとは限りません。しかし、論文が指摘するリスクは、割合の大小にかかわりません。実在しない名前と同じ名前のパッケージを、悪意のある人が先に公開しておけば、AI の提案をそのまま入れた人の環境に、その部品が入ります。論文はこれを、パッケージの取り違えを狙った攻撃として説明しています。この論文が示したのは、起こりうる経路と、名前が実在しない割合までです。実際の被害の件数は、論文からは分かりません。

点検は簡単です。依存の一覧にある名前を、公式のレジストリで一件ずつ引きます。たとえば npm なら、次のコマンドで存在と作成日が分かります。

npm view express version time.created

実在すれば版と作成日が返り、無ければ E404（見つからない）で止まります。この記事を書いた環境で、実在する express と、存在しない名前の両方で確かめました。名前が実在しても安心はできません。作成日が数日前、公開者が一人、ダウンロード数が極端に少ないといったものは、AI が名前を出したことを理由に採用せず、人が用途と照らして選び直します。

2. 版は固定されているか

AI が組んだ画面が、ある日急に動かなくなる。原因を調べたら、部品の新しい版が自動で入っていた。こうした事故は、版を固定していないと起きます。

npm では、package-lock.json がその役目を持ちます。npm の文書によれば、この文書は、生成されたときの依存の木を正確に記録し、あとの導入で同じ木が再現できるようにするものです。各部品について、版、取得元、ダウンロードした中身を確かめるための署名値（sha512 など）が書かれています。

配置するときは、npm install ではなく npm ci を使います。npm ci は、ロックファイルが無ければ失敗し、package.json と食い違っていれば、ロックファイルを書き換えずにエラーで止まります。入れる中身が、点検したときのものから一つもずれないことを機械で保証する使い方です。

見る点は三つです。ロックファイルがリポジトリに入っているか。配置の手順が npm ci になっているか。AI に直させたとき、ロックファイルの差分が人の目に見える形で出ているか。他の言語にも同じ目的の仕組みがありますが、ここでは npm の文書だけを確かめました。

3. 既知の脆弱性は見つかっていないか

版を固定すると、その版に既知の欠陥があるかを後から機械で調べられます。npm には npm audit があり、プロジェクトの依存の一覧をレジストリに送って、既知の脆弱性の報告を受け取ります。報告には、深刻度と、影響を受ける版の範囲が書かれています。npm の文書は、既定ではロックファイルが無いと実行できないとしています。ロックファイル無しで実行すると、そのたびに依存の木が組み直され、結果が実行ごとに変わりうるためです。

言語をまたいで調べたいときは、OSV があります。OSV は、複数の脆弱性データベースを OpenSSF の共通の形式でまとめて引けるようにしたもので、版を指定して問い合わせる API と、それを使う公式の道具 OSV-Scanner が用意されています。

npm audit

結果を読むときの注意が二つあります。深刻度が高い警告のすべてが、自社の使い方で悪用できるわけではありません。たとえば開発時にしか使わない部品の警告は、本番の画面には関係しない場合があります。反対に、警告が出ていないことは、欠陥が無いことの証明ではありません。登録されていない欠陥は、調べても出てきません。だから、警告ゼロを合格の条件にするより、「出た警告を一件ずつ、直す、使わない、受け入れるのどれにしたか」を記録することを条件にします。

4. 本当に使われているか、まだ保守されているか

AI に何度も作り直させた画面には、使われなくなった部品が残りがちです。OWASP の防止策は、使っていない部品と機能を取り除くこと、直接の依存だけでなく間接の依存も数えること、保守が止まった部品に注意し、パッチを当てられないなら別の部品への移行を考えることを挙げています。

棚卸しで確かめるのは次の三つです。

• コードのどこからも呼ばれていないのに、依存の一覧に残っている部品はないか。
• 公開元が更新を止めている部品はないか。最後の公開日と、修正の依頼への返事の有無で見ます。
• 同じ働きの部品が二つ入っていないか。AI は、別々の依頼のたびに別の部品を選ぶことがあります。

OWASP はこの管理を支える形として、部品の一覧（SBOM）を中央で管理することを勧めています。工場の部品表と同じ考え方で、何がいつ入ったかを一枚で追えるようにします。立派な道具を入れなくても、最初は依存の一覧とロックファイルを版管理に入れておくだけで、変更の履歴は残ります。

5. 更新は誰が、いつ、どう入れるか

点検は一度で終わりません。部品の新しい版は出続けます。OWASP は、依存の版を意図して選び、必要があるときに上げること、更新を全部のシステムに一度に配らず、段階的に配ることを勧めています。部品の配布元が乗っ取られたときの被害を小さくするためです。

工場の業務システムで置き換えると、次のような運用になります。

• 緊急の脆弱性の修正は、すぐ入れる。ただし、先に試験用の環境で、受入検査の画面や帳票が動くことを確かめる。
• それ以外の更新は、月に一度のように日を決めてまとめて入れる。AI に「全部最新にして」と頼んで、確かめずに配らない。
• 配置は一つの工場や一つの部署で先に使い、問題が無ければ広げる。

誰がやり、何を残すか

この五つは、AI が作ったコードを読める人でなくても進められます。名前が実在するか、ロックファイルが入っているか、警告に誰がどう答えたかは、一覧と日付を見れば分かるからです。社内に専門の技術者がいない場合も、依頼先に次の三つを出してもらえば足ります。依存の一覧（名前と版）、npm audit のような既知の脆弱性の検査結果、更新の手順と担当者です。

OWASP は、担当を分けることにも触れています。コードを書いて本番に出すまでを、一人がすべて通せる状態にしないこと。AI に作らせた場合は、AI と、それに指示した人が、実質一人の役割になりがちです。点検する人と、配置を承認する人は、別にしてください。

記録は、画面の受入の記録と同じ場所に置きます。依存の点検は、AIが生成したシステムの設計を点検するで挙げた設計の観点と対になるものです。画面の動作と受入の確認は、AIが作った業務画面を、誰がどうテストするのかで整理しました。三つの記録が同じ版を指していれば、「この日に配置したものは、何を使っていて、誰が確かめたか」を後から答えられます。

この記事では、npm のコマンドを使った点検だけを確かめました。Python やその他の言語の依存の管理、自社の特定のシステムに対する実際の検査の結果は、今回は測っていないので書いていません。