📌 この記事の要約

• 1000件まとめて渡すとAIの処理精度が急落
  カーディフ大学の研究チームが16種類のLLMを検証したところ、1件ずつなら簡単な作業でも、処理件数を増やすと成功率が急落する現象が確認された。

• 200件超で低下が加速し、1000件以上で全モデル40%未満に
  コンテキストウィンドウに収まっていても、200件を超えたあたりから成功率の低下が目立ち、2000件では全モデルが20%未満まで落ち込んだ。

• 原因は文章の長さではなく処理件数
  データの長さを2倍以上に伸ばしても成功率はほぼ変わらず、件数の増加のほうが性能低下と強く結び付いていた。

• 実務対策は「AIに判断、機械に集計、人が確認」
  50〜100件ずつに分割し、IDで結果を保存、集計は表計算やプログラムに任せ、件数の一致を自動で確認する運用が推奨される。

生成AIに1000件のアンケートを渡して、「不満の内容を分類し、項目別の件数を集計して」と頼んだとします。長い文章を扱える最新モデルなら、まとめて片付けてくれそうです。ところが、1件ずつならほぼ確実に解ける単純な作業でも、処理件数を増やすと成功率が急落しました。

カーディフ大学のJingxuan Chen氏、Mohammad Taher Pilehvar氏、Jose Camacho-Collados氏は、2026年4月20日に論文「Understanding LLM Performance Degradation in Multi-Instance Processing：The Roles of Instance Count and Context Length（複数インスタンス処理におけるLLM性能低下の理解：インスタンス数とコンテキスト長の役割）」の改訂版を公開しました。16種類のLLMに最大2000件のデータを処理させ、入力の長さとデータ件数のどちらが性能低下に強く影響するのかを調べています。

実験の結果、利用者にとってはうれしくない傾向が明らかになりました。コンテキストウィンドウに収まっていても、全件を正しく処理できるとは限らないのです。

同じレビューでも、1件ずつ判定する場合と、まとめて判定して集計する場合では結果が変わることがあります。

1件なら解ける簡単な仕事が大量処理で難題に変わる

研究チームが調べたのは、複数インスタンス処理(MIP)と呼ばれる処理方法です。インスタンスとは、レビュー、記事、文章、数値など、処理対象となる1件分のデータを指します。

映画レビューを1件読んで、肯定的か否定的か判断する作業は単一インスタンス処理(SIP)です。100件のレビューをすべて判定し、そのうち何件が肯定的だったか数える作業がMIPです。顧客アンケートの分類、問い合わせ履歴の集計、請求明細の確認など、多くの業務が同じ構造を持っています。

MIPでは、すべてのデータを読み、1件ずつ判断し、最後に結果を合計しなければなりません。関連する情報だけを検索して回答に使うRAGとは負荷のかかり方が異なります。多くのデータを読みながら、同じ判断を何十回、何百回と繰り返し、その結果を漏れなくまとめる必要があるからです。

実験には、DeepSeek R1やgpt-oss-120b、Llama 4 Maverick、Qwen3-Thinkingなどのオープンウェイトモデル9種類と、Claude Sonnet 4.6、Gemini 3.1 Pro、GPT-5、Grok 4などのクローズドモデル7種類が使われました。

課題は8種類です。加減算問題の答えの合計、ニュース記事の分類、文章の言語判定、人名の出現数の集計、奇数の個数の計算、映画レビューの感情判定、特定単語の出現回数の集計、文中の「apple」が企業と果物のどちらを指すかの判定です。処理件数は2件、5件、10件と増やし、最大2000件まで試しています。

研究チームは、個々の問題が難しかったために失敗した可能性も排除しました。比較対象のモデルすべてが1件ずつなら正解できたデータだけを選び、その同じデータを束ねて渡しています。大量処理で起きた失敗は、問題の難しさよりも、処理と集計を何度も繰り返す負荷から生じたと考えられます。

1件だけなら高い精度で解ける8種類の課題を使い、処理件数を最大2000件まで増やしました。

200件を超えると成功率の低下が加速し、1000件以上で40％未満になる

実験結果のグラフを見ると、処理件数が増えるにつれて曲線が緩やかな坂から急な崖へ変わります。20件から100件程度までは低下幅が小さく、多くのモデルが高い成功率を保ちました。200件を超えたあたりから低下が目立ち、1000件以上になると成功率が40％を上回るモデルがなくなります。2000件では、全モデルが20％未満まで落ち込みました。

全条件の平均成功率は、GPT-5が81.8％、Gemini 3.1 Proが80.3％でした。上位モデルは少ない件数で高い性能を発揮しています。ただし、この平均には2件や5件といった軽い条件も含まれます。件数を増やしていくと、上位モデルにも同じように限界が現れました。

高性能なモデルに乗り換えるだけでは、大量処理の問題は消えません。モデルによって崩れ始める件数には差があるものの、最終的にはすべてのモデルが失速しています。

データを並べる順番も検証されました。同じデータを2通りに並べ替えて再実行しても、成功率はほぼ同じ傾向で低下しました。特定のデータが先頭や末尾に置かれたために偶然失敗した、というわけではなさそうです。

しかも、AIは失敗したときにエラー画面を出して止まるとは限りません。大量の入力を受け取り、指定どおりの形式で結果を返していても、内容だけが間違っているケースがあります。見た目は正常に終わっているため、担当者が検算しなければ誤りに気付きにくいのです。

試験段階で30件を処理して問題がなかったとしても、本番で1000件を投入したときに同じ精度が続く保証はありません。少量のデータで問題なく動いたという結果が、大量処理への過信につながります。

モデルごとに差はありますが、処理件数を増やすほど成功率が下がり、1000件以上では全モデルが40％未満になりました。

長文を読めることと大量のデータを正確に扱えることは別の能力

大量処理で性能が落ちる理由として、まず考えられるのが入力の長さです。データを増やせばプロンプト全体も長くなるため、コンテキスト長が性能低下を招いたようにも見えます。

そこで研究チームは、データの件数や判定対象となる内容を変えず、各データに意味のない英文を追加しました。1件当たりの平均トークン数は約136から326へ増え、約2.4倍になりました。

ところが、処理件数を同じにした状態で比べると、元のデータと長くしたデータの成功率はよく似た曲線を描きました。追加した文章を先頭、中央、末尾、ランダムな位置へ入れても、大きな違いは出ていません。

相関分析でも、件数の影響が強く表れました。成功率とインスタンス数のスピアマン相関係数はマイナス0.61、総コンテキスト長との相関はマイナス0.37でした。どちらも増えるほど成功率が下がりますが、件数の方が性能と強く結び付いています。

さらに処理件数を固定し、文章の長さだけを変えて調べると、コンテキスト長と成功率の相関はマイナス0.15からプラス0.15の範囲に収まりました。少なくとも今回の条件では、文章の長さだけで性能低下を説明するのは困難です。

コンテキストウィンドウの大きさは、作業机の広さに似ています。机の上に1000枚の書類を置けたとしても、すべてを読み、分類し、正しい合計を出せるとは限りません。入力できる量と、正確に処理できる量は分けて考える必要があります。

生成AIサービスでは、「何万トークンまで入力可能」といった数字が性能指標として示されます。しかし、業務で確認すべき数字はトークン数だけではありません。レビューが何件あるのか、明細が何行あるのか、何回の判定と集計を繰り返すのかも、精度を左右します。

1件当たりの文章を2倍以上に伸ばしても、処理件数が同じなら成功率は大きく変わりませんでした。

もっともらしい答えの中に個別判定と集計のミスが重なっていく

件数が増えると、間違い方も複雑になります。1件のデータを誤って分類するだけでなく、個々の分類が合っているのに最後の合計を間違えるケースもありました。個別判定と集計を同時に誤るケースも増えています。

100件を超えると、個別判定と集計の両方を誤る複合ミスが目立ち始め、失敗全体の約25～45％を占めました。2000件では、出力されたJSONを正しく読み取れない解析エラーも約30％に達しています。件数が増えるほど、答えの中身だけでなく、出力形式まで崩れやすくなりました。

処理を途中で投げ出すモデルもあります。4620回の実験のうち、最初の数件だけ回答し、残りを省略したケースが171回ありました。そのほとんどは500件以上の条件で起きています。ところが、分割処理を提案したのは27回だけです。

GPT-5 Nanoは、処理を途中で打ち切った28回のうち19回で、自身の限界を伝えて分割処理を提案しました。ほかの多くのモデルは警告を出さず、途中まで処理した結果をそのまま返しています。

利用者にとっては、明らかなエラーよりも、こうした失敗の方が危険です。「処理できません」と表示されれば、別の方法を選べます。もっともらしい結果が返ると、正しいものとして次の作業へ流れてしまいます。誤った集計結果が会議資料に使われ、経営判断に影響すれば、後から原因をたどるのも容易ではありません。

論文では性能低下の原因を調べていますが、分割処理や外部ツールによる改善効果までは検証していません。それでも、実務で取るべき方針は見えてきます。

1000件を一度に渡すのではなく、50件や100件などのまとまりに分け、各データのIDと判定結果を保存する方法が考えられます。合計や件数の計算は、表計算ソフトやプログラムに任せます。入力件数と出力件数が一致しているか、分類別の合計が総数と一致するかも、自動で確認するとよいでしょう。

AIには文章の意味を読み取る仕事を任せ、合計や整合性の確認には答えが一意に決まる道具を使ったほうがよいでしょう。役割を分ければ、どの段階で間違いが起きたのかを追いやすくなります。

件数が増えると、個別の誤判定だけでなく、集計ミスや出力形式の破綻も増えていきます。

大量処理ではモデルの賢さより作業工程の設計が結果を左右する

今回の実験は、正確な件数や合計を求める課題を中心にしています。大まかな傾向をつかむ要約や、重要な論点を抜き出す作業に、今回の数値をそのまま当てはめることはできません。別途検証が必要です。また、英語中心のデータを使い、プロンプトを固定し、対象モデルも限定した実験である点には注意が必要です。

それでも、「入力欄に収まったから処理できる」という判断が危ういことは明確です。大量のアンケート、レビュー、問い合わせ、明細を扱うときは、トークン数に加えてデータ件数も管理しなければなりません。

生成AIへ一括で渡せば、作業が一瞬で終わったように見えます。しかし、途中結果が残らず、検算もできない処理は、間違った数字を短時間で作る仕組みにもなります。

AIを業務で使う際は、何件までまとめるのか、どの単位で分割するのか、どこで件数を照合するのかを先に決めておく必要があります。モデルの回答を信じるか疑うかという精神論より、間違いを発見できる工程を用意する方が確実です。

大量処理で問われるのは、AIがどれほど賢いかだけではありません。AIに意味の判断を任せ、表計算ソフトやプログラムに集計させ、人間が異常を確認できる流れを作れるかどうかです。1000件を一度に投げ込めることより、1000件を最後まで検証できる仕組みを作ることの方が、実務では重要です。