3行でいうと
- 針探し試験は、長い文章に埋めた一文を見つける試験。やさしい課題で、満点に近くても長文全体を使いこなせる証拠にはならない。
- 2023年の論文では、答えが入力の真ん中にあると正答率が落ちる傾向（U字型）が見つかった。
- 2024年のRULERでは、どのモデルも長さが増えると大きく下がり、「対応」と書かれた長さより短い所で基準を割るモデルが多かった。
- 論文のモデルは当時のものなので、今の最新モデルの数字ではなく、傾向を知る材料として読む。
この記事は、実際に使って確かめた記録ではありません。この記事は公式の文書や論文を読んでまとめたものです。
先に結論
- 「入力できるトークン数（コンテキストウィンドウ）」は、モデルが受け付ける上限です。その長さで、同じ精度で働くことを保証する数字ではありません。
- 長い入力の評価は、課題をやさしくすると満点に近くなります。評価の中身（探すものは1つか複数か、質問と答えの言葉が同じか違うか、紛らわしい文があるか）を見ないと、数字の意味は分かりません。
- 公式文書の側でも、AnthropicもGoogleも、長さによる低下や複数の「針」での精度低下を認めています。
- 実務では、必要な部分だけを入れる、質問を末尾に置く、重要な部分を引用させる、といった「入れ方の工夫」が現実的な対処です（見立てです）。
前提：用語
- コンテキストウィンドウは、AIが一度に参照できる全文の量（トークンで数える）です。入力と、AIが書く出力、思考も合わせた枠です。たとえばAnthropicの文書では、現行の多くのClaudeモデルが100万トークン、OpenAIのGPT-6.1 Solのモデルページでは1,050,000トークンの窓（最大入力922,000）と書かれています。
- トークンは、AIが読み書きする文字量の単位です。
- 針探し試験（NIAH、Needle in a Haystack）は、長い文章（干し草の山）の中に、関係のない一文（針）を埋め込み、AIに見つけさせる試験です。GitHubのKamradtのツールが広まり、モデルの発表でよく使われます。
- ベンチマークは、同じ問題で性能を比べる試験です。
針探し試験の読み方
針探し試験は、とても単純な課題です。Chromaの調査報告は、これを「既知の一文を、無関係な文章の中から取り出す単純な検索課題」で、多くの場合、言葉の一致（字面の一致）で見つけられる、と説明しています。このため、最新のモデルがほぼ満点を取る一方で、「長文脈は解決済み」という誤解を生んだ、と指摘しています。
見立てです。針探しの数字を見るときに、確かめたい点は次の4つです。
| 確かめる点 | なぜか |
|---|---|
| 針は1つか、複数か | Googleの文書は、針が1つの試験で高い性能が出るが、複数だと同じ精度にならず、文脈によって大きく変わる、と書いている |
| 質問と針の言葉が一致しているか | NoLiMaは、字面の一致を避けると、長さで大きく下がると報告している |
| 紛らわしい文（妨害）があるか | 実際の資料は、似て非なる文が混ざる |
| どの長さまでの結果か | 長さごとの結果があるかどうか。一番長い所だけ、が多い |
研究1：Lost in the Middle（2023）
Liuらの論文（TACL 2023）は、複数文書の質問応答と、キーと値の検索で、関連する情報の位置を変えました。要旨によると、位置を変えると性能が大きく落ちうる、最も良いのは情報が入力の先頭か末尾にあるとき、真ん中にあると大きく落ちる、長い文脈に特化したモデルでも同様、とされています。
数字は論文の本文から読みました。
- GPT-3.5-Turboの複数文書QAでは、関連情報の位置によって、性能が20％以上落ちることがあります。
- 最悪の場合、20文書・30文書の設定で、文書を1つも与えない場合（クローズドブック、56.1％）より低くなりました。
- 文脈が拡張されたモデル（長い入力に対応した版）は、同じ入力が両方に収まる場合、元のモデルと同等の成績で、必ずしも入力をよく使えるわけではない、とも書かれています。
条件は、当時のモデル（2023年のGPT-3.5-Turbo、Claude-1.3、MPT-30B、LongChatなど）で、文書の数は10・20・30件（約2千〜6千トークン）です。今の100万トークンのモデルの結果ではありません。
研究2：RULER（2024）
HsiehらのRULER論文（COLM 2024）は、針探しを広げた合成のベンチマークです。複数種類・複数個の針、道筋をたどる課題（multi-hop tracing）、集計（aggregation）など13課題で、17のモデルを評価しました。
要旨の主な結果は次のとおりです。
- 針探しでは、ほぼ満点を取るモデルでも、より複雑な課題では、長さが増えるにつれて大きく下がる。
- どのモデルも32Kトークン以上に対応と書いているが、32Kで十分な成績を維持できたのは半数だった。
論文は、Llama2-7Bの4Kでの成績（85.6％）を基準線にして、これを割らない最大の長さを「実効の長さ」と呼びます。
RULERの表3（抜粋）
論文の表3から抜粋しました。数字は論文のまま、課題13個の平均（％）です。モデルは2024年当時のものです。
| モデル | 公称の長さ | 実効の長さ | 4K | 32K | 64K | 128K |
|---|---|---|---|---|---|---|
| Gemini-1.5-Pro | 1M | 128K超 | 96.7 | 95.9 | 95.9 | 94.4 |
| GPT-4 | 128K | 64K | 96.6 | 93.2 | 87.0 | 81.2 |
| Llama3.1（70B） | 128K | 64K | 96.5 | 94.8 | 88.4 | 66.6 |
| Qwen2（72B） | 128K | 32K | 96.9 | 94.1 | 79.8 | 53.7 |
| Yi（34B） | 200K | 32K | 93.3 | 87.5 | 83.2 | 77.3 |
| Mixtral-8x22B | 64K | 32K | 95.6 | 90.9 | 84.7 | 31.7 |
| Mistral-v0.2（7B） | 32K | 16K | 93.6 | 75.4 | 49.0 | 13.8 |
読み取れること（論文の範囲で）は次のとおりです。
- 同じ表の中で、4Kではほとんど差がないのに、長さが増えると差が大きく開きます。
- Gemini-1.5-Proは、論文が試した最大の長さ（128K）でも基準を上回りました。論文は、より難しい版での確認が今後の課題、と書いています。
- 公称の長さと実効の長さが大きく離れたモデルが多数あります。
この表は2024年当時のモデルの結果です。現在のモデルは含まれていません。
研究3：NoLiMa（2025）
Modarresiらの論文（ICML 2025）は、針と質問の言葉の重なりを最小にして、潜在的なつながりを推論しないと見つけられない針探しを作りました。128K以上に対応するとされる13のモデルを評価した結果は次のとおりです。
- 短い入力（1,000トークン未満）では高い成績。
- 32Kでは、13のうち11が、自分の短い入力での成績の50％を下回った。
- 上位の例外のGPT-4oでも、ほぼ満点の99.3％から69.7％に下がった。
- 推論を強めたモデルや、考えさせる指示（CoT）を使っても、長い入力で維持するのは難しかった。
論文は、字面の一致がない場合に、注意機構（どの語に注目するかの仕組み）が長い入力で見つけにくくなることが原因と考えられる、と分析しています。これは論文の分析であり、確定した説明とは限りません。
研究4：Chroma「Context Rot」（2025年7月）
ベクトルデータベースを作るChromaの技術報告です。GPT-4.1、Claude 4、Gemini 2.5、Qwen3を含む18のモデルを評価しています。課題の難しさを一定にして、入力の長さだけを変えた、と説明されています。
- すべての実験で、入力が長いほど性能が下がった。
- 針と質問の意味の近さ（埋め込みのコサイン類似度）が低いほど、低下が速かった。
- 会話の記憶を測るLongMemEvalでは、関連部分だけの入力（約300トークン）に比べて、全体（約113,000トークン）の成績が、どのモデルでも大きく低かった。
報告は、関連情報が文脈にあるかだけでなく、どう提示するかが大事で、文脈のつくり方（context engineering）が重要、と結論しています。これは企業の調査で、査読を経た論文ではありません。
各社の公式の見解
- Anthropic（Claude Platform Docs）：トークン数が増えると正確さと再現が落ちる現象を「コンテキストロット」と呼び、文脈に何を入れるかを選ぶことが、空き容量と同じくらい大切、と書いています。
- Google（Gemini API）：単純な針探しでは高い性能だが、複数の針ではそうではなく、1回の問い合わせで約99％でも、100件を取り出すには問い合わせが必要で、そのたびに入力料金がかかる、と書いています。繰り返す文脈にはコンテキストキャッシュで費用を下げられる、とも書いています。質問は、長い文脈の末尾に置くと成績が良くなることが多い、とも述べています。
- Anthropicの「Prompting best practices」：長い資料は先頭に、質問は末尾に置く。末尾の質問で、特に複数文書の複雑な入力で、テストによっては回答の質が最大30％上がった、と書いています。長い文書の課題では、先に関連部分を引用させると、関係のない部分を無視しやすくなる、とも書いています。
実務での使い方（見立てです）
見立てです。以下は、読んだ資料からの整理で、検証したものではありません。
- 必要なものだけ入れる。 Googleの文書は、渡す必要のないトークンは渡さないのが最善、と書いています。Chromaの結果（関連部分のみ vs 全体）も同じ方向です。
- 構成を整える。 長い資料は先頭、質問は末尾。引用を先に抜き出させる。
- 重要なことは複数箇所に頼らない。 針が複数あるほど落ちやすいため、取り出すべきものは数を絞るか、段階に分ける。
- 自分の課題で測る。 自分の資料・質問・長さで、位置を変えて試す。論文の枠組み（位置を変える、長さを変える）はそのまま使えます。
- 長いなら検索で絞る（RAG）。 長い入力に全部入れる代わりに、関連部分を検索して入れる方法があります（別記事「RAGの設計」）。
気をつけること
- この記事では、これらの試験を再現していません。数字は論文と報告の本文のものです。
- Lost in the Middle（2023）、RULER（2024）、NoLiMa（2025）の評価対象は、当時のモデルです。2026年10月時点の最新モデルについて、この記事で扱った種類の第三者の評価を、確認できていません。傾向を示す材料として読んでください。
- Chromaの報告は企業の技術報告で、査読を経た論文ではありません。
- 各社の「100万トークン」は、入力できる上限の話です。実際にどこまで正確に使えるかは、モデルと課題で違い、公式の数字だけでは分かりません。
- 「真ん中が弱い」は傾向で、すべてのモデル・課題に当てはまるとは限りません。新しいモデルで改善している可能性があります（確認できていません）。
- モデル名や仕様は2026年10月8日の確認で、変わることがあります。
出典
- Lost in the Middle: How Language Models Use Long Contexts（arXiv:2307.03172、Liuら、TACL 2023、2026年10月8日確認）
- RULER: What's the Real Context Size of Your Long-Context Language Models?（arXiv:2404.06654、COLM 2024、2026年10月8日確認）
- NoLiMa: Long-Context Evaluation Beyond Literal Matching（arXiv:2502.05167、ICML 2025、2026年10月8日確認）
- Context Rot: How Increasing Input Tokens Impacts LLM Performance（Chroma、2025年7月14日、2026年10月8日確認）
- Needle In A Haystack（GitHub、gkamradt/LLMTest_NeedleInAHaystack、2026年10月8日確認）
- Long context（Gemini API、Google、2026年10月8日確認）
- Context windows（Claude Platform Docs、Anthropic、2026年10月8日確認）
- Prompting best practices（Claude Platform Docs、Anthropic、2026年10月8日確認）
- GPT-6.1 Sol（OpenAI API docs、OpenAI、2026年10月8日確認）
更新履歴
- 2026年10月25日 書き方を直しました。
- 前：運営者が使っていないと読める書き方 → いま：「この記事は、実際に使って確かめた記録ではありません」。公式の資料を読んでまとめた記事で、使い心地は書いていない、という意味に直した