AIが嘘のAPIを使ったコードを書いたときの見抜き方

なぜAIは架空のAPIを書くのか

AIは「このライブラリを使ってこの処理をしたい」という文脈から、存在しそうな名前を補完します。学習データに含まれるドキュメントやサンプルコードのパターンを参照しているため、命名の「雰囲気」は本物に近くなります。しかし学習データに古いバージョンの情報が混在していたり、複数の似たライブラリの仕様が混ざったりすることで、実際には存在しない名前が出力されます。

特に起きやすいのは次の場面です。

• メジャーバージョンが変わったライブラリ：旧バージョンのメソッド名を現在も有効なものとして書く。
• 類似ライブラリの混同：three.jsとbabylon.jsのように目的が同じ複数ライブラリの仕様を混ぜて書く。
• ブラウザAPIの細部：Web Audio APIやCanvas APIは実在しますが、存在しないショートカットメソッドを追加することがあります。
• フレームワーク固有のユーティリティ：Phaser・PixiJSなどゲーム向けライブラリは機能が多く、AIが似た名前を創作しやすいです。

架空のAPIを見抜く三つの兆候

兆候1：実行前からエディタが警告しない

VSCodeや型定義ファイル（.d.ts）が整っている環境では、存在しないメソッドを呼び出した時点で波線が引かれます。AIが生成したコードをエディタに貼り付けて、赤や黄の下線がつく箇所がないか先に確認することが最初のステップです。TypeScriptで書かれたプロジェクトならこの確認は特に有効です。

兆候2：エラーメッセージが「is not a function」か「is not defined」

ブラウザのコンソールに TypeError: xxx.yyy is not a function と表示されたとき、yyyがそのオブジェクトに存在しないメソッドである可能性が高いです。ReferenceError: yyy is not definedは変数そのものが未宣言なケースで、これも架空のグローバル関数を呼び出しているときに出ます。どちらも「名前自体が間違っている」サインです。

兆候3：公式ドキュメントに載っていない

「使い方は分かるがドキュメントで確認できない」という状態は危険です。MDN Web Docs・各ライブラリの公式サイト・GitHubのソースコードで、AIが書いたメソッド名を検索して見つからなければ、架空の可能性が高いと判断できます。検索してヒットするのがAI生成とおぼしきブログ記事だけ、という場合も要注意です。

確認の手順

ステップ1：AIに根拠を聞く

「このcanvas.fillCircle()はどのバージョンから存在しますか？MDNのページURLを教えてください」と返します。AIが「すみません、このメソッドは存在しません」と訂正すれば、その場で架空と確定できます。URLを答えてきた場合は、必ず自分でそのURLにアクセスして確認してください。AIはURLも架空のものを生成することがあります。

ステップ2：公式ドキュメントで名前を検索する

MDN Web Docsの検索欄、またはライブラリの公式ドキュメントの検索機能でメソッド名をそのまま入力します。引数のパターンまで一致することを確認してください。メソッド名は存在するが引数の順番や型が違う、という「半分嘘」のケースもあります。

ステップ3：GitHubのソースコードで直接確認する

ライブラリ本体のリポジトリを開き、該当のメソッド名でコード検索（t:キーや検索窓）をかけます。定義が見つかれば本物、見つからなければ架空と確定できます。これはドキュメントの更新漏れを拾えるため、最も確実な方法です。

ステップ4：代替メソッドをAIに再生成させる

「このメソッドは存在しないと確認できました。代わりに実際に存在するAPIだけを使って同じ処理を書き直してください。メソッド名は使用前に公式ドキュメントで確認可能なものに限定してください」と伝えます。この一文を最初のプロンプトに添えるだけでも、架空APIの発生率を下げる効果があります。

ジャンル別の確認先

架空APIが多く出やすい領域と、確認すべき一次情報源を整理します。

• Canvas / Web Audio / Pointer Events など、確認先：MDN Web Docs
• Phaser（HTML5ゲームフレームワーク）、確認先：Phaser公式ドキュメント・GitHubリポジトリ
• PixiJS、確認先：PixiJS公式ドキュメント・APIリファレンス
• Three.js、確認先：Three.js公式ドキュメント（バージョン番号を揃えて確認）
• Tone.js（音声生成）、確認先：Tone.js公式ドキュメント
• npm パッケージ全般、確認先：npmjs.comのパッケージページ、GitHubのREADME

バージョン番号のずれは見落としやすい落とし穴です。AIに「Three.js r160を使ってください」のようにバージョンを明示すると、古いAPIを混在させるリスクが減ります。ドキュメントを確認するときも同じバージョンのページを参照してください。

プロンプトで予防する

見抜く手間を減らすには、最初のプロンプトで架空APIを防ぐ指示を入れるのが効率的です。以下の文言を要件の最後に付け加えるとよいです。

• 「使用するメソッドはすべてMDNまたは公式ドキュメントで確認できるものに限定してください」
• 「存在するか不確かなAPIを使う場合は、その旨をコメントに書いてください」
• 「独自のユーティリティ関数が必要な場合はファイル内で定義し、外部ライブラリのメソッドとして書かないでください」

AIは「不確かな場合はコメントで示す」という指示に比較的従います。コメントに「このメソッドの存在は要確認」と書かせるだけで、確認すべき箇所が一目でわかるようになります。

次の行動

生成されたコードをブラウザで動かす前に、エラーが出た行のメソッド名をMDNまたは対象ライブラリの公式ドキュメントで1件ずつ確認する習慣をつけてください。最初のプロンプトに「存在しないAPIは使わない」と一行加えるだけでも架空APIの頻度は下がります。確認済みのコードが動くようになったら、アソバースにHTMLファイルやZIPとして投稿して公開することができます。

参考資料

• MDN Web Docs（Mozilla Developer Network）
• Phaser 公式ドキュメント
• PixiJS 公式 API リファレンス
• Three.js 公式ドキュメント（バージョン別）
• npmjs.com パッケージ詳細ページ