Contents
【開発者への警鐘】「ChatGPTが教えてくれたコード」をコピペしてはいけない本当の理由：AIパッケージ・ハルシネーション攻撃の全貌
あなたは日々のコーディング業務で、ChatGPTやGitHub Copilotなどの生成AIをどのくらい活用していますか？
「このAPIを叩くPythonコードを書いて」「このデータを処理するのに便利なライブラリを教えて」
そう問いかければ、AIは瞬時に完璧に見えるコードを返してくれます。あとはそれをコピーし、ターミナルで pip install や npm install を実行するだけ…。
これほど便利なことはありません。生産性は劇的に向上しました。
しかし、もしその「AIが教えてくれたライブラリ」が、実はこの世に存在しないものだとしたら？
そして、その「存在しないはずの名前」を先回りして登録し、ウイルスを仕込んでいる攻撃者がいるとしたら？
これこそが、現在セキュリティ業界で懸念が高まっている最新のサプライチェーン攻撃手法、「AIパッケージ・ハルシネーション（AI Package Hallucination）」です。
この記事では、AIを信じ切っている開発者を狙い撃ちにするこの手口のメカニズム、実証された研究データ、そして私たちが身を守るための具体的な検証方法について、5000字以上のボリュームで徹底解説します。
1. AIパッケージ・ハルシネーションとは何か？
まず、この攻撃の前提となる現象「ハルシネーション（幻覚）」について整理し、それがどのように攻撃に転用されるのかを解説します。
AIは「息を吐くように嘘をつく」
ChatGPTなどの大規模言語モデル（LLM）は、事実を検索して答えているわけではありません。膨大な学習データに基づき、「文脈的に最も確率が高い次の単語」を予測して繋げているに過ぎません。
そのため、非常にマニアックな質問や、特定のニッチなタスクについて尋ねると、AIは「実在しないが、いかにもありそうな名前のライブラリやパッケージ」を自信満々に捏造して回答することがあります。これが「パッケージ・ハルシネーション」です。
「タイポスクワッティング」とは違う、新しい罠
これまで、オープンソースのパッケージ管理システム（PyPI, npm, RubyGemsなど）における攻撃といえば、「タイポスクワッティング（Typosquatting）」が主流でした。
- タイポスクワッティング： ユーザーの入力ミスを狙う。
（例：requestsと打つところを、間違えてrequesstsと打つのを待ち構える） - ハルシネーション攻撃： ユーザーは間違えていない。AIが間違えるのを狙う。
（例：ユーザーはAIが出したコードを正確にコピペするが、そのコード内のライブラリ名自体がAIの創作である）
ユーザーは「AIが書いたコードだから正しいだろう」というバイアス（権威バイアス）がかかっているため、パッケージ名を疑うことなくインストールコマンドを実行してしまいます。
2. 攻撃のメカニズム：攻撃者はどうやって罠を仕掛けるのか？
攻撃者は、開発者のPCに侵入するために、以下の手順で「待ち伏せ」を行います。
☠️ 攻撃の4ステップ・シナリオ
- 質問の探索：
攻撃者はChatGPTなどのAIに対し、「〇〇のデータを変換する方法を教えて」「△△のAPIをPythonで操作するコードを書いて」といった、開発者がしそうな質問を大量に投げかけます。 - 幻覚の特定：
AIの回答の中に、公式には存在しないパッケージ名（例：google-cloud-storage-v2-helperのような、いかにもありそうな名前）が含まれていないかチェックします。 - 先回り登録（Trap）：
AIが繰り返し提案してくる「幻覚パッケージ名」が見つかったら、攻撃者は即座にその名前と全く同じパッケージを、PyPI（Python）やnpm（Node.js）の公式リポジトリに登録します。中身には、バックドアや情報を盗むマルウェアを仕込んでおきます。 - 感染（Exploit）：
世界中のどこかの開発者が、同じ質問をAIに投げかけます。AIは再びその幻覚パッケージを含むコードを提示します。開発者はそれを信じてpip install [幻覚パッケージ名]を実行し、攻撃者が用意したマルウェアに感染します。
この攻撃の恐ろしい点は、AI自体をハッキングする必要が一切ないことです。AIの「仕様（癖）」を利用し、外部のパッケージリポジトリに罠を張るだけで成立してしまうのです。
3. 研究事例：実際にどれくらいの確率で起きるのか？
これは理論上の話ではありません。セキュリティ企業による実証実験で、その危険性が証明されています。
Vulcan Cyberによる調査（2023年）
イスラエルのサイバーセキュリティ企業、Vulcan Cyberの研究チーム（Bar Lanyado氏ら）は、この攻撃手法の実現可能性について詳細な調査を行いました。
実験内容
彼らはChatGPTに対し、StackOverflowでよくある開発上の質問などを用いて、10,000回以上のクエリを投げかけ、どのようなパッケージを推奨するかを分析しました。
衝撃の結果
- 幻覚の頻発： ChatGPT（GPT-3.5モデル）は、数多くの「存在しないパッケージ」を回答しました。
- Go言語やJavaScriptでの高リスク： 特にGo言語やNode.js (npm) のライブラリにおいて、幻覚が高い頻度で発生しました。
- 再現性： 特定の質問に対しては、AIは繰り返し同じ「幻覚パッケージ名」を提示する傾向がありました。これにより、攻撃者はターゲットを絞りやすくなります。
実証（PoC）
研究チームは、実際にAIが提案した「存在しないパッケージ名」を使って、npmやPyPIに無害なダミーパッケージを登録してみました。
すると、短期間のうちに、それらのパッケージは数百回以上もダウンロード（インストール）されたのです。
これは、世界中の開発者がAIの回答を鵜呑みにして、検証チームが作ったダミーパッケージを「本物」だと信じてインストールしてしまったことを意味します。
出典：Vulcan Cyber: Can you trust ChatGPT’s package recommendations?
Alibaba Cloudによる観測
また、Alibaba Cloudのセキュリティチームも、npmリポジトリ上で同様の手法を用いたと思われる悪意あるパッケージの増加を観測しています。AIが生成したコードに含まれる「実在しない依存関係」を悪用する動きは、すでに現実の脅威となりつつあります。
4. なぜ私たちは騙されるのか？ 開発者を陥れる心理的バイアス
技術力のあるエンジニアでさえ、なぜこの単純な罠に引っかかるのでしょうか。そこには2つの心理的要因があります。
1. 自動化バイアス（Automation Bias）
人間は、自動化されたシステム（AIやコンピュータ）からの出力を、自分の判断よりも信頼する傾向があります。「高度なAIがそう言っているのだから、裏付けがあるのだろう」と無意識に思い込んでしまうのです。
2. 「まさか、ないはずがない」という思い込み
提示されたパッケージ名が具体的であればあるほど（例：azure-storage-blob-uploader など）、人間は「こんなに具体的な名前なのだから、実在する公式ライブラリだろう」と推測します。AIが単語の確率的組み合わせで名前を「創作」しているとは直感的に理解しづらいためです。
5. 実例で見る：AIが捏造しやすいパッケージの特徴
AIが捏造しやすいパッケージ名には一定の法則があります。これを知っておくだけで、警戒レベルを上げることができます。
パターンA：ハイフンや接続語の組み合わせ
公式ライブラリの名前に似ているが、区切り文字や接続語が異なるパターンです。
- 公式：
python-docx - 幻覚：
docx-python,python-docx-v2
パターンB：機能名をそのままパッケージ名にする
AIは「やりたいこと（機能）」から名前を推測するため、機能名をそのままつなげた名前を捏造しがちです。
- ユーザーの質問：「FastAPIでGraphQLを扱う便利なライブラリは？」
- AIの回答（幻覚）：
fastapi-graphql-client（※実在しそうだが存在しない場合がある）
パターンC：大手ベンダー名を冠する
Google, AWS, Azureなどのサービス名を勝手に含めるパターンです。これが最も危険で、ユーザーは「公式が出しているSDKだ」と誤認して即座にインストールしてしまいます。
- 幻覚例：
aws-s3-stream-uploader,google-drive-api-wrapper
6. 今日からできる対策：インストール前の「3つの確認」
AIを使うなということではありません。AIが提示したライブラリをインストールする前に、以下の「3つの確認」をルーチン化してください。これだけでリスクはほぼゼロになります。
対策1：リポジトリの「公式リンク」を確認する
AIが「pip install xyz-lib を実行してください」と言ったら、まずはその名前（xyz-lib）をGoogle検索するか、PyPI (pypi.org) や npm (npmjs.com) で検索してください。
| チェック項目 | 危険なサイン（赤信号） |
|---|---|
| 作成日 (Published) | 数日前〜数週間前に登録されたばかりである。 （有名ライブラリなら数年の歴史があるはず） |
| ダウンロード数 | 極端に少ない（週に数十回など）。 |
| 作者 (Maintainer) | 公式ベンダー（Google, Microsoft等）のアカウントではない、または匿名性が高い。 |
対策2：GitHubのスター数とIssueを見る
多くの正規ライブラリはGitHubリポジトリと紐付いています。パッケージのホームページとしてリンクされているGitHubを確認しましょう。
- スター数が極端に少ない。
- READMEが空っぽ、あるいはAIが書いたような一般的な説明しかない。
- Issue（不具合報告）やPull Requestの活動履歴がない。
これらに当てはまる場合、それは攻撃者が急造した「ハリボテ」の可能性があります。
対策3：スコープ付きパッケージ（Scoped Packages）を意識する
特にnpmの場合、@owner/package のように「スコープ（@から始まるユーザー名/組織名）」が付いているパッケージは比較的安全です。スコープ部分は所有者しか作成できないため、なりすましが困難だからです。
- 安全な例：
@angular/core（Angular公式が管理） - 注意が必要：
angular-core-helper（誰でも作れる名前）
7. 組織としての防衛策
個人の注意だけでなく、開発チーム全体での対策も重要です。
プライベートリポジトリとプロキシの活用
企業内での開発では、JFrog ArtifactoryやSonatype Nexusなどのリポジトリ管理ツールを導入し、「一度承認されたライブラリしかインストールできない」ように制限をかけるのが最も確実です。これにより、開発者が誤って未知のパッケージをインストールしようとしてもブロックされます。
脆弱性スキャンツールの導入
Snyk、Socket、GitHub Advanced Securityなどのサプライチェーンセキュリティツールは、インストールしようとしているパッケージの評価（評判、作者、作成日）を自動的に分析し、「怪しいパッケージ」に対して警告を出してくれます。これらをCI/CDパイプラインやローカル環境に組み込みましょう。
まとめ：AIは「優秀な助手」だが、「責任者」ではない
AIパッケージ・ハルシネーション攻撃は、AI技術の欠陥ではありません。AIの「確率的に言葉を紡ぐ」という特性と、人間の「権威を信じやすい」という心理の隙間を突いた、非常に人間臭い、しかし致命的な攻撃手法です。
私たちはこれからもAIを使ってコードを書くでしょう。それは止められませんし、止めるべきでもありません。しかし、AIから提案されたコードをコピペするその一瞬、「このライブラリ、本当に実在するのか？」と疑う習慣を持つこと。
それこそが、AI時代におけるエンジニアの必須スキル、「AIリテラシー」の核心なのです。
次回、ChatGPTが「このライブラリを使うと便利ですよ」と教えてくれたら、インストールコマンドを叩く前に、一度ブラウザでその名前を検索してみてください。もしかしたら、そこにはライブラリではなく、口を開けた「罠」が待っているかもしれません。
