AIが薦める「存在しない機能」で開発依頼がやってくる。SF世界のような開発依頼に技術者はどう向き合うか

クライアントから届いた開発依頼に、聞いたことのないAPIやサービスの名前が並んでいる。それらを使った開発をしてほしいとのことなのだが、念のため調べると、やはりそれらは存在しない。

依頼側は「AIを使った」とは言わない。しかし、その仕様書の構成やトーンを見ると、AIが「依頼側に向けて要件をまとめた」であろうことがわかる。箇条書きは整然としており、専門用語らしき言葉が散りばめられているが、何かがおかしい。いざ調査すると、依頼内容に記載されたサービス自体が存在しなかったり、APIの処理メソッドが架空のものだったりする。

こうした事例が2024〜2025年にかけて急増している。AIハルシネーションが、静かに開発現場に波及し始めている。

プログラミングが効率化されていく中で、開発現場に怪しい影が忍び寄っているのも事実だ。

何が起きているか

パターン1：存在しないパッケージ・ライブラリの推奨

「スロップスクワッティング（Slopsquatting）」という言葉をご存知だろうか。 AIが生成したコードに含まれる、存在しないパッケージ名を悪用したサプライチェーン攻撃の手口だ。

2025年3月の調査によると、AIが生成したPython・JavaScriptのコードサンプルの約20%に、実在しないパッケージが含まれていた。 ChatGPT-4でも約5%のハルシネーション率があり、オープンソースモデルではさらに高い。特筆すべきは、同じプロンプトに対して43%の架空パッケージが繰り返し一貫して出力される点だ。つまり、AIは「確信を持って」存在しないものを推奨し続ける。

実際の被害事例も報告されている。「huggingface-cli」という架空パッケージはわずか3ヶ月で30,000回以上ダウンロードされたが、その実態はマルウェアだった。 AIの推奨を信じたユーザーが、悪意ある第三者が事前に用意したパッケージをインストールしてしまったのだ。

参考：AI-hallucinated code dependencies become new supply chain risk（BleepingComputer）

パターン2：存在しないAPIメソッドの推奨

パッケージだけではなく、実在するフレームワークの「存在しないクラスやメソッド」を推奨されるケースも頻発している。

典型的な事例として、ChatGPTがSpring Frameworkの SqlParameterSourceUtils クラスを「SQLパラメータの確認に使える」として推奨したケースがある。しかしこのクラスは実在しない。開発者は実際に実装しようとして初めてそれに気づき、時間を無駄にした。

参考：Hallucinating AI - ChatGPT suggests APIs that never existed（ZEN Software）

公式APIドキュメントに情報の空白があると、AIはそこを「もっともらしい情報」で補完する。ドキュメントが古い・不完全なほど、ハルシネーションが起きやすくなる。

パターン3：バイブコーディングが生む「SF仕様書」

「バイブコーディング（Vibe Coding）」とは、コードを書けない非技術者がAIに開発を全委任するスタイルを指す。 Replitのデータによれば、そのユーザーの75%は自分ではコードをまったく書かない。

この流れで生まれるのが、技術的に不可能な要件が混在した仕様書だ。 AIは依頼者に向けて「できそうに聞こえる」文章を生成するため、受け取った技術者にとっては「どう見てもSFの世界」な要件が、整然とした箇条書きで届くことになる。

Lovableというバイブコーディングプラットフォームでは、2025年5月の調査で1,645アプリ中170件にセキュリティ脆弱性が確認された。さらに、AIが生成したコードは人間が書いたものと比べて1.7倍の主要な問題、2.74倍のセキュリティ脆弱性を含むという報告もある。

参考：Vibe coding is not the same as AI-Assisted engineering（Addy Osmani）

なぜ発生するか

LLMは「もっともらしい回答を生成する」ように設計されている。「知らない」のではなく、「知識のギャップを確信を持って補完してしまう」のが問題の本質だ。

依頼側がこの特性を理解せずにAI回答をそのまま仕様化すると、技術者の手元には「整合性はとれているが実在しない要素が混在した文書」が届く。仕様書として体裁は整っているだけに、読み込むまで気づきにくい。

参考：AI hallucinations: what they are, why they happen（Mintlify）

技術者はどう対応するか

まず「検証」を工程に組み込む

仕様書に記載のAPI・ライブラリは、着手前に必ず公式ドキュメントで実在を確認する。これを習慣化するだけで、後戻りの大半を防げる。可能であれば、存在確認チェックリストをクライアントとの合意文書に含めておきたい。

技術者自身もAIを利用する場合は同じリスクがある。コード生成後、パッケージ名は必ず npm info や pip show で実在確認することを習慣にする。

参考：SOK: Exploring Hallucinations and Security Risks in AI-Assisted Software Development（ArXiv）

「AIが言った」は要件の根拠にならない旨を伝える

見積もり・要件定義の段階で「AI推奨情報は事前に実在確認が必要」という旨を伝えておく。口頭でなく、メールや議事録に残しておくことが重要だ。問題が起きたときの証跡になる。

依頼側がAIを使ったとは言わない場合でも、仕様書の構成を見れば判断できることが多い。「AIでまとめてもらった内容をそのまま持ってきた」と気づいたなら、確認の一手を入れる習慣を持つことだ。

建設的に返す

クライアントは悪意があるわけではない。 AIを信じて、良かれと思って依頼してくる。架空のAPIを批判するのではなく、「このサービスは現時点では存在しませんが、同じことはこちらの方法で実現できます」と翻訳して返す。

"幻の仕様"を実現可能な形に変換することが、今の技術者に求められる新しいスキルのひとつになっている。

自分が使うときも検証を怠らない

Stack Overflowの調査では、AIコーディングツールを「高度に信頼する」と答えた開発者はわずか3%だった。現場の実感として、技術者はすでにAIの限界を知っている。だからこそ、依頼側との認識ギャップが生まれる。

自分が使う側のときも同様だ。AIの出力はあくまで「出発点」であり、そのまま信頼できるものではないという前提で使う必要がある。

まとめ

AIの普及は、技術的に不可能な要件を整然とした形で持ち込む依頼を増やした。これは「困った問題」ではあるが、同時に技術者に新しい役割を与えている。

仕様の翻訳者、検証者、そして非技術者とAIの間に立つ調停者。その役割をうまく担えるかどうかが、これからの技術者の価値にも関わってくる。

「存在しない機能」の依頼が来たとき、それをただ断るのではなく、実現可能な形に変えて提案できる技術者が求められている。

参考リンクまとめ：