JetBrains Researchの研究チームは、AIを活用したプログラミングエージェントの評価方法における根本的なギャップを明らかにし、現在のベンチマークが実際の作業環境において開発者がこれらのツールと対話する方法を正確に反映していないと主張しました。統合開発環境（IDE）を使用する開発者の4,782セッションを分析した結果、研究者たちは、現在のモデルが日常的なプログラミングの複雑な現実とは似ていない理想的な条件下でテストされていることを発見しました。
評価基準と実際の業務のギャップ
調査によると、「SWE-Bench Pro」などの有名なベンチマークは、詳細が完全に記載された1つのメッセージで送信されるバグ修正や新機能の追加のタスクにほぼ完全（93.8%）に依存していることが示されました。しかし実際のプロダクションセッションの分析では、開発者がプログラミングエージェントに要求する内容のうち、バグ修正や新機能の追加に関するものは半分にも満たないことが明らかになりました。
実際の開発者からのリクエストの残りは、次のような多様なタスクに分散しています。
- コード構造についての問い合わせ、およびプロジェクトの特定の部分がどのように機能するかを理解すること。
- 開発プロセスの次のステップを計画すること。
- コードレビューとリファクタリング。
- コードの実行とトラブルシューティング。
さらに、実際のセッションの半分は1つのメッセージで構成されている一方で、残りのセッションは複数のインタラクションに及び、要件がエージェントに段階的かつ断片的に届くことが分かりました。これは、完全なタスクを1つの洗練されたメッセージとして提示する従来の「SWE-Bench」には欠けている点です。
SWE-TaskFlowフレームワーク：ユーザーの行動のより正確なシミュレーションに向けて
この欠点に対処するため、JetBrainsは「SWE-TaskFlow」と呼ばれる新しいフレームワークを導入しました。このフレームワークは、既存の基準を置き換えることを目的としたものではなく、次の3つの主要なメカニズムを通じて、それらをより現実的なものに変換することを目的としています。
- タスクの分割（Task Splitting）： 1つのプログラミングタスクを3つの連続したリクエストに分割し、1つ目が完了するまでエージェントが2つ目のリクエストを確認できないようにすることで、段階的な要件に対処する能力をテストします。
- リポジトリに関する質問の追加（Repository Questions）： タスクの実行前または実行中に、現在のコードの一部を説明することをエージェントに要求する質問を生成します。これは実際の開発者の間で非常に一般的な行動です。
- タスクフローの整合（Task Flow Alignment）： チームが開発した「TFAS」メトリックに基づいて、実際のセッションの分布に一致するようにメッセージのシーケンスと種類を最適化するアルゴリズムを使用します。
実験結果：コスト対精度
研究者たちは、「GPT-5.6 Luna」、「GPT-5.6 Terra」、「Gemini 3.7 Flash」などのいくつかの高度なモデルに対して新しいフレームワークをテストしました。結果として、タスクを複数のメッセージに分割すると、タスクあたりの運用コストが2.0〜2.6倍に増加することが示されました。この増加は、要件が断片的に届いたときにエージェントが払う追加の労力を反映しています。
技術的な観点からは、タスクの分割時にタスク解決モデルの成功率（Resolve Rates）は大幅には影響を受けず、4〜5パーセントポイントのわずかな低下にとどまりました。これは、最大の課題がタスク自体の難しさではなく、リソースと時間の消費の増加にあることを示しています。
開発者や企業にとって実質的に何が変わるのか？
この研究の重要性は、AI業界の焦点を単一ステップでの「プログラミング上の問題の解決」から、長期的な会話を管理し変化する文脈を理解する能力を持つ「インタラクティブなアシスタント」の構築へと移行させることにあります。モデルを開発する企業にとって、これはエージェントの長期記憶能力を向上させ、最終的な目標を見失うことなく次々と入ってくる情報を処理する能力を向上させる必要があることを意味します。
また、「SWE-TaskFlow」は、エージェントの作業品質の段階的な検証の可能性への扉を開きます。最終結果のみを評価するのではなく、開発者は各メッセージの後にエージェントのパフォーマンスを評価できるようになり、AI支援プログラミングのプロセスの早い段階で軌道からの逸脱を発見しやすくなります。