チャットボットに「近くの旨い店を探して」と頼んだあと、数ターン後に「いや、静かなカフェに変えて」と言い直した経験があるだろう。このときチャットボットはどこまで覚えておき、何を捨てるべきなのか。人間なら「旨い店」はすでに破棄された要求だと分かる。ところがLLMエージェント(人の代わりに作業をこなすAI)は、しばしば捨てられたはずの要求を抱えたまま最終回答を出してしまう。研究チームはこの失敗を 「意図ドリフト(intent drift)」 ——変化していく会話の中で古い意図が結果を汚染する現象——と呼ぶ。
本研究は、その失敗をはじめてまともに測定した。検証可能なタスクを統制された会話へと変換するベンチマークIntentFlux(ここでいうベンチマークとは、性能を測るための標準化された問題集のことだ)で定量化し、生成の直前に「いま有効な要求」を明示的に押さえておくStateForgeで、損失の一部を取り戻した。
実際の会話は、一度できれいにまとまってくれない。ユーザーはまず何かを頼み、あとで値を一つ直し、制約を一つ取り下げ、最後に「じゃあそれでお願い」と言う。エージェントはこの流れの中で、どの断片がまだ生きている要求なのかを自力で見分けなければならない。すでに置き換えられたり撤回されたりした断片が最終回答やツール呼び出しに影響を与え続ければ、それが意図ドリフトだ。
ここでよくある誤解を一つ正しておきたい。意図ドリフトは「モデルが会話を忘れること」ではない。むしろ逆だ。破棄されるべき情報を はっきり覚えていて、積極的に使ってしまう ことで結果を誤らせる失敗である。忘却ではなく誤用、というわけだ。
既存のマルチターン(何度もやり取りする)対話評価も、この問題の周辺には触れていた。情報を少しずつ小出しにするとモデルがタスクを取りこぼすという研究(Laban et al., 2025)、引数の開示・修正・タスク転換を加えながら元の採点器を維持した評価(Tack et al., 2026)がある。しかしこれらは「エージェントが結局は変化後のタスクに追従できたか」を見るにとどまり、古い意図が回答を台無しにした失敗を他のマルチターンエラーと切り分けてはいなかった。これをきちんと測るには、二つのことが同時に要る。最終意図が何かを確実に把握していること、そして古い情報を誤って使えばタスク結果が実際に変わるよう設計することだ。
IntentFluxの発想はシンプルだ。正解採点器がすでに存在するタスク(コード、数学、SQL、データ→テキスト変換、要約、ツール使用)を持ってきて、それを「意図が変化していく会話」へと分解する。肝は、元の採点器をそのまま保存する点にある。会話がどれだけこじれても正解基準は最初のタスクのものそのままなので、スコアが落ちたなら、それはタスクが難しくなったからではなく会話構造のせいだ、と言い切れる。
古い情報を仕込むやり方が巧妙だ。二種類あるので、まずは例から見よう。
この最後の条件が重要だ。取り下げた制約が、単に言葉が合わないという程度ではなく 採点に直接影響するもの だけを残すので、エージェントが古いデコイを抱えていれば必ずスコアに表れる。古い状態を「使ったか使わなかったか」を、タスクの成否でテストできるようにしたのだ。
測定設計もすっきりしている。同じ最終タスクを、(1) シングルターンでそのまま与える clean 条件と、(2) 意図が変化していく会話から復元しなければならない drift 条件とで対にして比較する。二条件の完全正解率(いまの本当の意図を基準に完璧に当てた割合)の差が 意図ドリフト・ギャップ(IDG) だ。ターン数が増えたこと自体が原因である可能性を排除するため、意図の修正なしにターンだけ増やした対照群も別に用意した。
処方箋がStateForgeだ。名前のとおり状態を「鍛え上げる(forge)」。タスクを解く仕事と意図を管理する仕事を分離し、別のトラッカー(tracker)モデルが 破棄された意図項目と、そこから派生した結論を取り除いて「いま有効な状態」を推定したうえで、その有効状態を既存の会話履歴に明示的に付け加えて実行エージェントへ一緒に渡す。破棄された情報を状態から差し引くのであって、実行モデルの入力全体から会話履歴まで取り去るわけではない。回答をつくる前に、机の上へ「いま有効な要求」のメモを一枚置いてから始める、という具合だ。
数値は、アブストラクトと本文に明示されたものだけを引用する。核心となる結果は三つだ。
| 実験 | 条件 | 平均タスクスコア |
|---|---|---|
| 627件の較正プール | 易 → 難 | 0.476 → 0.384 |
| General-Test(125タスク) | 基本マルチターン → StateForge | 0.367 → 0.467 |
第一に、古い情報が積み重なるほど成績は落ちた。 627件のタスクを対象に、会話中の破棄・撤回された情報が多くなるよう難易度を上げたところ、平均スコアは0.476から0.384へと下がった。ただしこの実験はバリアント・デコイ・長さを一つずつ切り分けたのではなく、「古い情報の負荷」をまとめて上げたものなので、「古い情報が増えれば性能が落ちる」とまでは言えても、どの要因がどれだけ寄与したかはこの数字だけでは切り分けられない。
第二に、落ちた理由は会話が長いからではなく、意図が変わったからだった。 最近のLLM八種すべてで、同じ最終タスクでも会話から復元しなければならないとき(drift)は、シングルターンで与えたとき(clean)より完全正解率がはっきり低かった。一方、意図の修正なしにターンだけ増やした対照群はシングルターンと同程度だった。採点基準を最初のタスクに固定し、長さの対照群まで併せて見ているので、この低下はタスクの難易度やターン数ではなく 意図の変更から来ている と、比較的強く言える。
第三に、直しはしたが、完全にではなかった。 自然に出てくる反論——「会話履歴をただ要約・圧縮すればいいのでは?」——からまず片付けよう。論文は履歴だけを縮める外付けの補助機構を二種(ローリング要約、二段圧縮)試したが、損失は安定して回復しなかった。圧縮は「何が残ったか」は縮めてくれるが、「残ったもののうち何がまだ有効か」は解いてくれないからだ。StateForgeはまさにその有効性の判定を明示的に引き受け、General-Testの平均を0.367から0.467へ引き上げた。ところが、ここでもう一歩踏み込んだ診断が面白い。推定した状態の代わりに 正解の最終意図をそのまま注入 しても、性能はさらに上がるものの、シングルターンのcleanスコアまでは回復しなかった。有効な要求を完璧に教えてやっても、散らかった会話履歴が目の前にそのまま残っていると、モデルは依然として揺らぐということだ。状態推定の誤りは損失の「重要な一部」にすぎず、全部ではなかった。
もう一つ実用的な発見がある。状態を管理する役割は、タスクを解く本体モデルよりずっと小さなモデルでも担えた——論文は、状態の保持をより小さなトラッカーへ「蒸留」して引き渡せると報告している。役割が狭ければ軽量モデルで十分でありうる、というシグナルだ。
著者たちも率直だ。IDGは「会話から最終意図を復元するのにかかる総損失」をとらえる指標にすぎず、バリアント・デコイ・長さのうちどれが犯人なのかを一つずつ分離してはくれない。ユーザー役を演じるシミュレータと、回答を採点するジャッジを、どちらも同一のモデル(DeepSeek-V4-Flash)が担っている点も、検証の妥当性に問いを残す。事後点検で、注釈された最終意図をGeneral-Testタスクの95%で復元できたという品質管理の数値はあるが、シミュレータが作った会話が実際のユーザー修正の手触りをどれだけ似せているかは別問題だ。何より、StateForgeは「部分的な緩和」である。正解の状態を与えてもシングルターンに追いつけない残差が残っており、その残差の正体はまだ開かれたままだ。
ONTLEのAI PMが頻繁にぶつかる失敗が、まさにこれだ。リクエストボードを思い浮かべてほしい。
顧客が月曜に「Excel収集をつけて、Naverショッピング基準で」と書く。水曜に「ああ、ショッピングじゃなくてCafe24の注文データに変えて」と付け足す。金曜に「ひとまずその日次通知は外しておこう」と、制約を一つ取り下げる。PMが週末に実行(開発タスク生成、デプロイ)へ入るとき、有効なスペックは「Cafe24注文収集、通知なし」だ。ところが長い会話履歴を丸ごと読んだエージェントは、初ターンの「Naverショッピング」(バリアント)や、すでに取り下げた「日次通知」(デコイ)を蘇らせ、見当違いのタスクを積んでしまう。顧客からすれば「ちゃんと変えたのに、なぜまたそれでやったのか」となり、信頼が崩れる。
本研究は、その場面を二つの地点で変える。第一に、実行の直前に 「いま有効な要求」の状態を明示的に立てて おき、そこから派生した古い結論まで取り除いたうえでタスクを生成する。リクエストボードのコメントスレッドを単に要約するのではなく、置き換え・撤回を反映した能動的なスペックへと畳み込むのだ。第二に、その状態追跡を、実行エージェントから分離した小さなモジュールとして置ける。状態の保持をより小さなトラッカーへ渡せるという結果は、ONTLEが全社モデルルーティングの標準の中で、状態保持という狭い役割に軽量モデルを専任で割り当てる 設計がコスト対比で理にかないうることを示唆する。
ただし、正解の状態を与えても残差が残るという警告も併せて刻んでおく。PMが有効なスペックを完璧に整理して渡しても、実行段階が会話ログ全体を抱え込んだままだと、また揺らぎうる。したがってONTLEは、有効なスペックを立てるところで止まらず、実行エージェントへ渡すコンテキストそのものを、有効な状態を中心に絞り込む方向 で、次のAI PMアーキテクチャを具体化していく。