AI を使い始めて少し慣れた頃、誰もが一度はやられるのが「AI が自信満々で間違える」現象です。明らかな嘘ではなく、もっともらしい誤りを混ぜてくるので、レビュー時に見抜きにくいです。
経験上、AI が間違えるのはランダムではなく、特定の領域で系統的に起きます。どの領域で間違えやすいかを地図化しておけば、「ここは AI の弱点だから二重チェック」と勘所が育ちます。今回は私が現場で遭遇した実例を起点に、AI の失敗領域マップを整理します。
なぜ「失敗領域マップ」が必要か
AIの間違いはランダムではない
AI が間違えるとき、間違える先には特徴的なパターンがあります。
- 学習データの少ない領域（ニッチな業界・新興技術）
- 学習データのカットオフ後に出た情報（最新仕様・最近のリリース）
- 似たもの同士の混同（同名製品の異なるバージョン、似た用語）
- 確率的に「ありそう」な情報の捏造
逆に言うと、AI が得意な領域もパターン化できます。普及度の高い言語仕様、メジャーなライブラリの基本機能、汎用的なアルゴリズムなどは安定して正確です。
全てを検証するのはコスト的に無理
AI の出力を全て一次情報と突き合わせて検証していたら、AI を使う意味が薄れます。「ここは検証必須、ここは斜め読みで OK」の判断ができれば、レビュー時間を集中投下できます。
そのために必要なのが「AI が何を知らないか」の地図です。
実例：FF14 の PTR 誤認
私が実際に遭遇した事例です。MMOのリリース運用について調べていたとき、AI に「FF14 と WoW の Public Test Realm（PTR）の運用比較」を頼みました。AI は両者の PTR 運用を詳細に説明し、それぞれの違いを表にまとめてきました。
ところがFF14 は PTR を公開していません。FF14 はクローズドベータや限定的な「ベンチマーク版」はあっても、WoW のような公開 PTR は提供していません。AI は「PTR がある」前提で情報を作り、もっともらしい比較表を返してきました。
これは典型的な「似たもの同士の混同」です。MMO というジャンルが同じで、両者ともリリース運用に注力しているという共通点から、AI は「あって当然」と推測したわけです。
ユーザーの指摘で発覚し、修正した結果、本題は「WoW の PTR 運用」一本に絞りました。ゲーム業界という枠で見ると AI は強そうに見えるのに、各タイトルの個別事情では弱いという発見になりました。
AI の失敗領域マップ（5カテゴリ）
カテゴリ1: 新興分野・最新仕様
特徴: 学習データのカットオフ後に登場した情報。リリース直後のフレームワーク、最新版の API、新しい仕様。
典型的な間違い:
- 「v2 で追加された機能」と言われたが、実は v3 で追加された
- 「このメソッドは廃止されました」と言われたが、現役
- 新しい仕様の構文を、古い構文で書いてしまう
検証コスト: 低（公式ドキュメントを見れば即判定）
対処:
- Context7 MCP のような最新ドキュメント参照ツールを使う
- 「あなたの知識のカットオフはいつですか？それ以降の情報は別途検索してください」と前置き
- 自分の使うバージョンを明示してから依頼
カテゴリ2: ニッチドメイン
特徴: 学習データに含まれる量が少ない業界・領域。規制業種、地方の商習慣、専門性の高い学術領域。
典型的な間違い:
- 業界固有の規格名が架空のものになっている
- 規制要件を一般的な内容で代用してくる
- 専門用語の意味を、似た一般用語で誤解する
検証コスト: 高（一次情報が分散しており、確認に時間がかかる）
対処:
- 専門知識のある関係者に最終確認させる
- AI には「この領域は知らない可能性があるので、不確実な部分は明示して」と前置き
- 一次情報（規格書・公式ガイドライン）を都度添付
カテゴリ3: 固有名詞・組織情報
特徴: 個別の製品名、企業名、人名、サービスの個別仕様。先のFF14のような「実在するが詳細を間違える」パターン。
典型的な間違い:
- 製品の機能を別製品の機能と混同
- 「○○社が提供する△△」が架空
- 組織の歴史・買収関係を混同
検証コスト: 中（公式サイトや一次情報で確認可能）
対処:
- 固有名詞が出てきたら一旦止めて、公式情報で照合
- 「この製品の機能を一覧してほしい。架空の機能を含めないこと」と明記
- 比較表を作らせるときは、各項目の出典を求める
カテゴリ4: 数値・統計
特徴: 具体的な数字。市場規模、利用率、ベンチマーク値、価格。
典型的な間違い:
- 「○○の市場規模は〜億円」が古い・架空
- 「ベンチマークでは△△%高速」の数字に出典がない
- 「利用者の○割が〜」の根拠が見つからない
検証コスト: 中〜高（出典を辿る必要がある）
対処:
- 数値は「出典を明記してください」と毎回指示
- 出典が示せない数値は使わない
- 「〇〇程度」「数百万規模」のように丸めて使うのは可
カテゴリ5: 時系列・順序
特徴: いつ何が起きたか、どの順序で発展したか。
典型的な間違い:
- 「2020年に発表」が実は2022年
- 「Aの後にBが派生した」順序が逆
- バージョン履歴の前後関係が混乱している
検証コスト: 低〜中
対処:
- 時系列を含む出力には「年月日と出典」を求める
- 重要な時系列は別途タイムラインを作って AI に検証させる
- 自分の記憶と AI の出力が食い違ったら、まず自分の記憶を疑い、次に AI を疑う
現場で使う「3秒判定」
5カテゴリを覚えておくと、AI の出力を見た瞬間に3秒で「ここは検証必要」と分かるようになります。
検証スキップ可（AI が安定して正確）
- 一般的なアルゴリズムの説明
- メジャーなライブラリの基本機能
- 普及した言語仕様
- 汎用的な設計パターン
- コーディング規約・ベストプラクティス
検証必須（カテゴリ1-5に該当）
- 最新版の API 仕様
- ニッチ業界の規格・要件
- 個別製品の機能一覧
- 統計値・ベンチマーク
- 時系列・順序の主張
文脈依存（プロジェクト固有）
- 自プロジェクトのコードベース知識
- 自社の運用ルール
- チームの暗黙の合意
これらは AI の知識の問題ではなく、そもそも AI が知り得ない領域なので、CLAUDE.md やプロンプトで補強する必要があります。
エンジニアにとっての価値
1. レビュー時間を集中投下できる
AI 出力を全箇所同じ重みで読むのではなく、カテゴリ1-5該当箇所に時間を集中させます。検証スキップ可な部分はサラッと読むだけで済みます。
2. 自分の専門領域の AI 弱点が見える
AI を使い続けると、自分の専門領域の中で「ここは AI が弱い」というポイントが見えてきます。これは自分の専門性の価値が確認される瞬間でもあります。AI に置き換えられない領域は、まさに AI が知らない領域です。
3. チームへの注意喚起ができる
「AI を使い始めたメンバー」に対して、5カテゴリを共有すると、初心者の事故が大きく減ります。「AI は便利だけど、これとこれは必ず確認して」と言える共通言語になります。
落とし穴と対処
落とし穴1: 「カテゴリ外なら絶対正しい」と過信
検証スキップ可リストに入っていても、まれに間違えます。特に「複雑な組み合わせ」（複数ライブラリの相互作用、エッジケース）は要注意です。スキップ可は「平均的に正確」であって「絶対正確」ではありません。
落とし穴2: カテゴリ判定に時間をかけすぎる
「これはカテゴリ2かカテゴリ3か」を細かく分類しても意味がありません。「検証必要 / 不要」の2択判断ができれば十分です。カテゴリは検証の方向性を示す目安にとどめます。
落とし穴3: 自分の弱点領域も AI 任せにする
自分が知らない領域は、AI の出力が正しいかどうかも判断できません。「自分も AI も知らない領域」は最も危険です。専門家に確認するか、一次情報を読み込むまでは決定を保留します。
落とし穴4: 検証コストを払わずに「ハルシネーション！」と騒ぐ
AI が間違えたとき「使えない」と切り捨てるのは早計です。**カテゴリを把握した上で「ここは検証必須」**と分かっていれば、間違いは事前に予測でき、検証コストも見積もれます。AI の限界を知ることと、AI を諦めることは別です。
適用範囲
このマップが効くシーン：
- AI が出力した情報をレビューする全ての場面
- 技術記事・ブログを AI 補助で書く時
- 新しい技術を AI に教えてもらう時
- AI を使った調査・リサーチ
- AI 出力を社外公開する前のチェック
まとめ
| カテゴリ | 失敗例 | 検証コスト | 対処 |
|---|---|---|---|
| 1. 新興・最新仕様 | バージョン誤認 | 低 | 公式ドキュメント参照 |
| 2. ニッチドメイン | 規格名の架空化 | 高 | 専門家確認 |
| 3. 固有名詞 | 製品機能の混同 | 中 | 公式情報照合 |
| 4. 数値・統計 | 出典のない数字 | 中〜高 | 出典明示の指示 |
| 5. 時系列・順序 | 年代誤認 | 低〜中 | 別途タイムライン作成 |
「AI が何を知らないか」の把握は AI 上級者の必須スキルです。失敗領域マップを持っていると、レビュー時間を集中投下でき、AI を諦めずに使い続けられます。FF14 の PTR 誤認のような「もっともらしい間違い」に出会ったとき、それを地図に書き加える気持ちで扱うと、長く使うほど自分の AI 運用が強くなっていきます。