Google研究：AIの誤答は『知識不足』でなく『想起失敗』が主因

Google研究：AIの誤答は「知識不足」でなく「想起失敗」が主因

要点: Google ResearchとTechnionの研究者らが発表した論文「Empty Shelves or Lost Keys? Recall Is the Bottleneck for Parametric Factuality」は、フロンティアLLMがWikipedia由来の事実の95〜98%を「学習」しているにもかかわらず、26〜34%を正しく「想起」できないことを、独自ベンチマーク「WikiProfile」（2,150事実×10タスク、約450万応答）で定量的に示しました。 GPT-5.2のエラーの70%以上は知識の欠如ではなく想起の失敗に起因し、この傾向はロングテール（低人気）の事実ほど強まります。 Search Engine Journal（Roger Montti記者、2026年8月17日公開）はこの研究をもとに、コンテンツ内での主語・目的語の語順を検索クエリの一般的な語順に揃えることが有益かもしれないという仮説を、未検証と明記した上で提示しています。

最終更新日: 2026年8月18日

何が起きたのか

きっかけとなったSEJ記事と、その元になった研究

2026年8月17日、Search Engine JournalのRoger Montti記者が「Google: Subject/Object Entity Order Affects AI Answers」と題する記事を公開した。この記事が取り上げているのは、Google ResearchとTechnion（イスラエル工科大学）の研究者ら（Nitay Calderon、Eyal Ben-David、Zorik Gekhman、Eran Ofek、Gal Yonaらが名を連ねる）による論文「Empty Shelves or Lost Keys? Recall Is the Bottleneck for Parametric Factuality（空の棚か、失われた鍵か？パラメトリック事実性のボトルネックは想起である）」だ。この論文はarXivに2602.14080として公開されており、Google Researchの公式ブログでも2026年8月12日付で解説記事が掲載されている。SEJの記事は、この研究発表から19時間前後というタイミングで公開されたものであり、業界内での反応の速さがうかがえる。

研究のタイトルにある「空の棚（Empty Shelves）」と「失われた鍵（Lost Keys）」という比喩は、LLMが事実に関する質問に誤答する際の2つの異なる原因を表している。ある事実の情報を倉庫の「棚」に例えるなら、そもそも棚に商品（知識）が置かれていない状態が「空の棚」＝エンコード失敗（学習していない）であり、商品は棚にあるのに鍵が見つからず取り出せない状態が「失われた鍵」＝想起失敗（学習しているのに引き出せない）である。この研究の核心は、従来の精度指標（正解率）ではこの2つの原因が区別できておらず、モデルが「知らないから間違えた」のか「知っているのに引き出せなかったから間違えた」のかを判別できていなかった、という問題提起にある。

WikiProfileベンチマークの設計と評価規模

研究チームはこの2つの失敗モードを切り分けて診断するために、独自のベンチマーク「WikiProfile」を構築した。WikiProfileはWikipediaから抽出した2,150個の事実を核とし、各事実に対して10種類の異なるタスクを紐づけている。タスクの内訳は次の通りだ。

• エンコード測定用タスク（2種類）: 命題補完タスク。モデルの内部確率分布を用いて、その事実に関する命題文をどの程度正しく完成させられるかを測定し、モデルがその知識を学習（エンコード）しているかどうかを判定する。
• 知識評価用タスク（4種類）: 直接質問と逆質問（順方向・逆方向）を組み合わせた自由記述式の質問応答タスク。モデルが自然文の生成というかたちで、実際にその事実を正しく答えとして引き出せるか（想起できるか）を測定する。
• 認識テスト用タスク（4種類）: 選択肢式（多肢選択）の検証タスク。順方向・逆方向の問いに対して、複数の選択肢から正解を選べるかを測定する。生成を伴わない「認識」ができるかどうかを見る設計になっている。

この10種類のタスクを組み合わせることで、研究チームは「エンコードはできているが直接質問には答えられない」「エンコードもできていない」「エンコードもでき、直接質問にも答えられる」といった複数の知識プロファイルに、個々の事実×モデルの組み合わせを分類できるようにした。ベンチマークの構築パイプラインは完全に自動化されており、人手によるアノテーションに頼らずに大規模な評価を可能にしている点も特徴だ。

評価対象としたLLMは13種類。これらのモデルに対してWikiProfileの全タスクを実施し、合計で約450万件の応答を生成、自動採点した。この規模の評価により、単一モデル・単一タスクでは見えてこなかった「エンコードと想起の乖離」を、統計的に有意な形で示すことに成功している。

主要な数値結果:フロンティアモデルでも26〜34%が想起失敗

研究の中心的な発見は、Gemini-3-ProやGPT-5.2といったフロンティアモデルにおいてすら、エンコード（学習）と想起（引き出し）の間に大きなギャップが存在するというものだ。具体的には次の通り報告されている。

• フロンティアモデルは対象事実の95〜98%をエンコード（学習）しているにもかかわらず、そのうち26〜34%を直接の質問に対して想起できない。
• Thinking（思考プロセスを伴う推論）機能を使った場合でも、11〜12%は依然として想起に失敗する。
• GPT-5.2について詳細に分析すると、エラー全体の70%以上が想起失敗に起因しており、知識そのものの欠如が原因のエラーは少数派である。

この数値が示す意味は大きい。従来「AIが間違った回答をした」という現象は、しばしば「AIがその情報を知らなかった」という説明で片づけられがちだった。しかしこの研究は、フロンティアモデルの誤答の大部分が、実際には「知っているのに引き出せなかった」という、知識獲得とは別次元の問題に起因することを定量的に示している。研究チームはこの結果から、今後のモデルの事実性向上は、単純なパラメータ数の拡大（スケーリング）だけでは限界があり、「知識をどう学習させるか」よりも「学習済みの知識をどう引き出させるか」という想起メカニズムの改善に、より大きな伸びしろがあると結論づけている。実際、研究ではスケーリングがエンコード失敗を減らす効果は確認されている一方で、想起失敗はモデルが大きくなっても顕著に残り続けることが示されている。

ロングテール（低人気）事実ほど「知っているのに答えられない」

研究のもう一つの重要な発見は、事実の人気度（Wikipedia上での知名度や言及頻度などで測定されると考えられる指標）と、エンコード・想起それぞれの失敗率との関係だ。低人気事実（ロングテール）と高人気事実を比較すると、次のような非対称な傾向が見られたと報告されている。

• エンコード率の差: 低人気事実と高人気事実の間で、エンコードされている割合の差は比較的小さい。つまり、マイナーな事実であっても、モデルの学習データにその情報自体が含まれていれば、一定程度は学習されている。
• 想起失敗率の差: 一方、想起に失敗する割合の差は2倍を超える水準まで拡大する。つまり低人気事実は、学習はされていても、質問された際に正しく引き出される確率が高人気事実より大幅に低い。

この結果は、マイナーなブランド名・ニッチな製品名・専門的な固有名詞など、Web上での言及頻度が相対的に少ない事実について、LLMが「知識としては保持しているが、回答として取り出せない」リスクが特に高いことを示唆している。これは知名度の低い中小企業・地域ブランド・専門特化サービスにとって、AI検索経由での正確な言及・引用を得る難易度が構造的に高いことを裏付けるデータとも解釈できる。

主語・目的語の語順（Subject/Object Entity Order）と「逆転呪い」の再検証

SEJの記事タイトルにもなっている「主語・目的語の順序がAIの回答に影響する」という論点は、この研究における「逆転呪い（reversal curse）」の再検証パートに基づいている。逆転呪いとは、LLMが「AはBである」という形で学習した事実について、逆方向の「BはAである」という問われ方をされると正答率が下がる現象として、以前から複数の研究で報告されてきた性質だ。

今回の研究チームは、WikiProfileの知識評価用タスク（直接質問・逆質問）と認識テスト用タスク（多肢選択の順方向・逆方向）の両方を使い、この逆転呪いを開放型生成（自由記述の回答）と多肢選択式の検証という2つの異なるタスク形式で比較検証した。結果は次のように分かれた。

• 開放型生成（自由記述の質問応答）: 訓練時に学習した語順と逆方向の質問（逆質問）のほうが、正答しにくい傾向が確認された。これは従来の逆転呪いの報告と整合する結果である。
• 多肢選択式の検証タスク: 順方向・逆方向の間の差はほぼ見られず、場合によっては逆方向のほうがむしろ答えやすいケースも観測された。

この2つのタスク形式での結果の違いは非常に重要な示唆を持つ。もし逆転呪いが「そもそもその事実を認識・理解できていない」という知識自体の欠如が原因であれば、多肢選択式でも同様に成績が下がるはずだ。しかし多肢選択式ではほぼ差がなかったという結果は、「事実自体はエンコードされ、認識もできているが、訓練時と異なる方向から自由記述で問われると、生成の段階でうまく想起できない」という、想起特有の問題として逆転呪いを説明できることを意味する。つまり主語・目的語の語順の影響は、知識のエンコード段階の問題ではなく、想起（生成時の引き出し）段階に特有の現象であるというのが、この再検証パートの結論だ。

Thinking機能は「新しい知識を生む」のではなく「既存の知識へのアクセスを助ける」

研究ではさらに、思考プロセスを伴う推論（Thinking/reasoning）機能が、この想起失敗をどの程度救済できるかも検証している。結果は次の通りだ。

• エンコード済みだが直接的には想起できない事実のうち、40〜65%を思考のプロセスを通じて正しく想起できるようになる。
• 一方、そもそもエンコードされていない事実については、5〜15%程度しか救えない。

この非対称な効果は、Thinking機能の役割を明確に性格づけている。Thinkingは「モデルが持っていない知識を新たに生み出す」機能ではなく、「モデルがすでに持っている知識へのアクセス経路を補助する」機能として働いているということだ。前述の通りThinking機能を使っても11〜12%の想起失敗が残ることを踏まえると、Thinkingは想起失敗という問題への部分的な緩和策ではあっても、根本的な解決策ではないと言える。

SEJが提示する仮説と、その位置づけ

SEJのMontti記者は、以上の研究結果、特に主語・目的語の語順が想起に影響するという再検証結果を踏まえて、「検索クエリで一般的に使われる語順に、コンテンツ内での事実の記述順序を合わせることが有益かもしれない」という仮説を提示している。ただしこの点についてSEJ自身が、これはあくまで研究結果からの推測であり、実証的に検証されたSEO施策ではないことを明記している。研究論文そのものはSEO・コンテンツ制作を対象にしたものではなく、LLMの内部的な事実性メカニズムを解明する基礎研究であり、「語順を揃えればAI検索での引用が増える」という因果関係を直接実証したものではない点には注意が必要だ。

aiseo-llmo.com ユーザーへの影響

「AIに正しく引用されない」問題の新しい切り口

これまで本サイトで紹介してきたAI引用対策の多くは、コンテンツ側の要因——構造化データの実装、E-E-A-Tシグナルの強化、文章パターンの最適化など——に焦点を当ててきた。今回の研究は、それとは異なるレイヤーの問題、すなわちLLM側の内部的な「想起の限界」という技術的制約が、AIの誤答・不正確な引用の一因になりうることを示している。これは「コンテンツを完璧に作り込んでも、モデル側の想起メカニズムの限界によって、AIが正しく事実を引き出せないケースが一定割合で存在する」という、コンテンツ制作者にはコントロールできない構造的な要因があることを意味する。

もっとも、この研究結果は「コンテンツ対策が無意味になる」ということを示すものでは全くない。むしろ逆で、想起失敗が事実の記述のされ方（語順・言い換えのバリエーションなど）と関連する可能性が示されたことで、コンテンツ側でできる想起支援の工夫に新しい実務的な示唆が生まれたと捉えるべきだ。

エンティティの記述順序という、これまで意識されてこなかった要素

「主語・目的語の順序」という要素は、従来のSEO・LLMO対策ではほとんど議論の俎上に上がってこなかった観点だ。多くのコンテンツ制作ガイドラインは「結論ファースト」「明確な文章構造」「一文一義」といった可読性・構造の観点を重視してきたが、「AとBの記述順序自体がAIの想起精度に影響しうる」という視点は新しい。

ただし前述の通り、この論点はSEJが「未検証の仮説」と明記している通り、研究で直接実証された施策ではない。あくまで「逆転呪いの再検証結果から導かれる推測」という位置づけであることを踏まえた上で、リスクの低い形で対応策に取り入れることが望ましい。

ロングテール・ニッチブランドにとっての警鐘

想起失敗率がロングテール（低人気）事実で2倍以上に拡大するという結果は、中小企業・地域密着型ビジネス・専門特化型サービスなど、Web上での言及量が大手ブランドに比べて少ない事業者にとって重要な警鐘となる。自社ブランド名や製品名についてAIが「学習はしているが、いざ質問されると正しく答えられない」状態にある可能性が、知名度の高いブランドよりも構造的に高いということだ。これは、AIに正確に引用されるためには、単に情報がWeb上に存在するだけでは不十分であり、その情報がAIにとって想起しやすい形——繰り返しの言及、多様な言い回しでの言及、複数の独立した情報源からの言及——で存在している必要があることを示唆している。

今すぐできる対応策

研究のニュアンス（未検証の仮説であること、想起失敗は知識欠如とは別問題であること）を踏まえた上で、実務的にリスクの低い範囲で着手できる対応策を整理する。

1. 事実を双方向の言い換えで明示する

逆転呪いの知見を踏まえ、重要な事実については「AはBである」という順方向の記述だけでなく、「BはAである」という逆方向の言い換えも文中に用意することが有効と考えられる。これは特にFAQ・定義文・比較表など、事実関係を端的に述べる箇所で実践しやすい。

文章例（順方向のみ・従来型）:

「〇〇株式会社は、△△市に本社を置くAI検索最適化ツールの開発企業です。」

文章例（双方向を併記した改善版）:

「〇〇株式会社は、△△市に本社を置くAI検索最適化ツールの開発企業です。AI検索最適化ツールを開発している企業の一つが、△△市に本社を置く〇〇株式会社です。」

同じ内容を主語・目的語を入れ替えた形で1回だけ言い換えるだけでも、モデルが順方向・逆方向どちらの問われ方をされても事実を引き出しやすくなる可能性がある。ただし冗長になりすぎないよう、記事全体で乱用せず、特に重要な事実（企業名と所在地、製品名と機能、人物名と役職など）に絞って適用するのが現実的だ。

2. FAQ設計を順方向・逆方向の両方のクエリ形式でカバーする

FAQセクションを設計する際、「〇〇とは何か」という定義型の問いだけでなく、「△△を提供しているのはどの企業か」という逆質問型の問いも併記することで、想起の起点を複数用意できる。

FAQ設計例:

• 順方向: 「〇〇株式会社が提供しているサービスは何ですか？」→「AI検索最適化ツール『△△』を提供しています。」
• 逆方向: 「AI検索最適化ツール『△△』を提供しているのはどの企業ですか？」→「〇〇株式会社が提供しています。」

このように同一の事実関係を異なる質問の起点から複数回提示することは、AI引用されやすい文章パターンの実証研究で解説してきた「明確な主語・述語構造」の考え方とも整合的であり、既存の文章設計原則の延長線上で無理なく実践できる。

3. 構造化データで事実関係を機械可読な形でも冗長化する

想起失敗は生成（自由記述）段階で特に顕著だったことを踏まえると、構造化データ（JSON-LD）によって事実関係を機械可読な形で明示しておくことは、生成に頼らない事実確認の経路を補強する意味で引き続き重要だ。

Organization schemaでの記述例:

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "〇〇株式会社",
  "url": "https://example.com",
  "makesOffer": {
    "@type": "Offer",
    "itemOffered": {
      "@type": "SoftwareApplication",
      "name": "△△（AI検索最適化ツール）"
    }
  }
}

FAQPage schemaで逆方向クエリもカバーする例:

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "〇〇株式会社が提供しているサービスは何ですか？",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "AI検索最適化ツール『△△』を提供しています。"
      }
    },
    {
      "@type": "Question",
      "name": "AI検索最適化ツール『△△』を提供しているのはどの企業ですか？",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "〇〇株式会社が提供しています。"
      }
    }
  ]
}

構造化データについては用語集: 構造化データや用語集: Schema.orgで基礎を確認できる。

4. ロングテール事実は言及の反復と多元化を優先する

低人気事実ほど想起失敗率が高いという結果を踏まえ、ニッチな製品名・ブランド名・専門用語については、単発の言及ではなく、自社サイト内の複数ページ、および可能な範囲での第三者サイトでの言及を通じて、同じ事実関係が繰り返し・多様な文脈で言及される状態を作ることが望ましい。これは用語集: Grounding（グラウンディング）の観点、すなわちAIが回答生成時に外部情報を参照・裏付けとして活用する仕組みとも関連が深い。関連の深いエンティティ最適化・E-E-A-Tの考え方については用語集: E-E-A-Tも参照されたい。

5. 語順の最適化は「小さく試す」に留める

SEJ自身が明記している通り、語順の最適化は未検証の仮説である。既存コンテンツの語順を大幅に書き換えるような大掛かりな対応は現時点では推奨されない。まずは新規作成するFAQ・定義文において、上記の双方向言い換えを部分的に取り入れる程度に留め、AI引用率のモニタリングツールなどで効果を継続的に確認しながら、必要に応じて範囲を広げていくアプローチが現実的だ。なぜAIに引用されないのかという根本原因の切り分けについては、ChatGPTに引用されない理由と改善策も合わせて参照するとよい。

よくある質問

Q1. この研究が示す「エンコード失敗」と「想起失敗」の違いは何ですか？

エンコード失敗はモデルがその知識を学習していない状態、想起失敗は学習しているのに回答として引き出せない状態です。

研究では前者を「空の棚」、後者を「失われた鍵」という比喩で表現しています。フロンティアモデルは95〜98%の事実をエンコード済みであるにもかかわらず、そのうち26〜34%を直接の質問に対して想起できないという結果が報告されており、多くの誤答が知識不足ではなく想起の問題に起因することを示しています。

Q2. GPT-5.2やGemini-3-Proのようなフロンティアモデルでも誤答は起きるのですか？

はい。研究によれば、これらのモデルでもエンコード済み事実の26〜34%を直接想起できず、GPT-5.2ではエラー全体の70%以上が想起失敗に起因すると報告されています。

Thinking（思考プロセスを伴う推論）機能を使った場合でも、11〜12%は依然として想起に失敗するとされており、フロンティアモデルであっても想起の限界から完全には自由ではないことが分かります。

Q3. Thinking（reasoning）機能を使えばこの問題は解決しますか？

部分的にしか解決しません。エンコード済みだが想起できない事実の40〜65%はThinkingで救済できますが、そもそもエンコードされていない事実は5〜15%程度しか救えません。

この結果は、Thinking機能が「新しい知識を生み出す」のではなく「既存の知識へのアクセスを助ける」機能として働いていることを示しています。知識自体が欠けている場合の効果は限定的です。

Q4. 「主語・目的語の順序」がAIの回答に影響するというのは、どういう意味ですか？

訓練時に学習した語順と逆方向で質問された場合、開放型の自由記述回答では正答率が下がる傾向が確認されました。これは「逆転呪い」と呼ばれる現象の再検証結果です。

一方、多肢選択式の検証タスクでは順方向・逆方向の差がほぼ見られませんでした。この違いから、事実自体は認識できているものの、訓練時と異なる方向から自由記述で問われると生成段階でうまく想起できない、という想起特有の問題として説明されています。

Q5. コンテンツ内の文章の語順を今すぐ書き換えるべきですか？

いいえ、大掛かりな書き換えは推奨されません。SEJ自身がこの語順最適化の効果は未検証の仮説であると明記しています。

新規作成するFAQ・定義文などにおいて、重要な事実を順方向・逆方向の両方の言い回しで補足する程度の小さな対応から試し、効果をモニタリングしながら範囲を検討するのが現実的です。

Q6. ロングテール（マイナーな固有名詞やブランド名）は特に不利になりますか？

はい。低人気事実は高人気事実に比べ、エンコード率の差は小さいものの、想起失敗率の差は2倍を超える水準まで拡大するという結果が報告されています。

これは、知名度の低いブランド名や専門用語について、AIが「学習はしているが正しく引き出せない」状態にある可能性が構造的に高いことを示しています。中小ブランドや地域密着型事業者にとって、AI検索での正確な言及獲得の難易度が高いことを裏付けるデータの一つと言えます。

Q7. WikiProfileベンチマークとはどのようなものですか？

Wikipedia由来の2,150個の事実に、それぞれ10種類のタスク（エンコード測定用2種・知識評価用4種・認識テスト用4種）を紐づけた自動評価ベンチマークです。

命題補完によるエンコード測定、直接質問・逆質問による知識評価、多肢選択式による認識テストを組み合わせることで、事実ごとにエンコード状態と想起状態を切り分けて診断できるよう設計されています。13種類のLLMを対象に約450万件の応答を生成・自動採点した大規模評価です。

Q8. この研究はSEO・AI引用対策の実務にどう関係しますか？

「AIに正しく引用されない」現象の一部が、コンテンツの品質問題ではなくLLM側の想起の限界に起因する可能性を示している点で、これまでにない視点を提供します。

同時に、事実を双方向の言い回しで明示する、FAQを順方向・逆方向の両方のクエリ形式でカバーする、構造化データで事実関係を機械可読な形でも冗長化するといった、コンテンツ側で実践できる具体的な対応の方向性も示唆しています。ただし語順最適化自体は未検証の仮説である点には注意が必要です。

Q9. この論文はどこで読めますか？

arXivに「Empty Shelves or Lost Keys? Recall Is the Bottleneck for Parametric Factuality」（arXiv:2602.14080）として公開されており、Google Researchの公式ブログでも2026年8月12日付で要点解説が掲載されています。

研究者はGoogle ResearchとTechnionに所属するNitay Calderon氏、Eyal Ben-David氏、Zorik Gekhman氏、Eran Ofek氏、Gal Yona氏らです。SEJのRoger Montti記者による解説記事も2026年8月17日に公開されています。

Q10. スケーリング(モデルを大きくすること)で想起失敗は解消されますか？

完全には解消されません。研究では、スケーリングがエンコード失敗を減らす効果は確認されている一方、想起失敗はモデルが大きくなっても顕著に残り続けることが示されています。

研究チームはこの結果から、今後の事実性向上はモデルの大規模化だけに頼るのではなく、学習済みの知識をどう引き出させるかという想起メカニズムの改善に、より大きな伸びしろがあると結論づけています。

関連記事

• LLMO完全ガイド——AI検索時代の最適化戦略の全体像
• AI検索最適化完全ガイド
• AI引用されやすい文章パターンの実証研究
• AI引用の合意形成シグナル——プラットフォーム横断戦略
• ChatGPTに引用されやすい記事の書き方
• ChatGPTに引用されない理由と改善策
• エンティティ最適化でAI引用率3倍——実装ガイド
• 用語集: E-E-A-T
• 用語集: Grounding（グラウンディング）
• 用語集: Schema.org
• 用語集: 構造化データ
• ChatGPTの検索基盤『Retrieval Stack』解明——キャッシュ層とLabrador連携の仕組み
• AI可視性は技術的負債の返済である——長期戦略としてのLLMO
• 『引用されるパッセージ』と『吸収されるパッセージ』の違いをAdvanced Web Rankingが実証
• RedditのChatGPT Search引用が4日で86%急落、Promptwatch報告