大規模言語モデルは次のトークンを予測するように訓練されており、特定のAPI内で行動するようには訓練されていない。論文は、ニッチな企業向けSaaSワークフロー——正しいエンドポイントに、正しいネストされた引数で、正しい順序で到達することが成功条件となる作業——では、この目的の不一致が静かな失敗として現れると指摘する。必須フィールドの欠落、存在しないツールの幻覚、一度の読み取り後の早期停止などである。著者らは、検証可能報酬による強化学習（RLVR）を対象環境に直接適用すれば、このギャップを埋められるかを問う。
概念実証として、研究チームはJira REST v3およびConfluence v2 APIをスキーマ忠実度で模倣する5つの合成環境を構築した。重要な設計は、報酬がツール呼び出しトレースのみから計算される点にある。生きたAPI、学習型ジャッジ、人手によるラベルはループに含まれない。つまり、模型が操作を正しく完了したかどうかは決定論的チェッカーが直接判定し、GRPO訓練に使うチェッカーと評価に使うチェッカーが同一になる。
実験ではプロンプトを与えたQwen3-1.7BとQwen3.5-4Bを比較した。結果として、5つのうち報酬が非退化な4シナリオで、強化学習済みポリシーは平均報酬を4Bベースラインの0.35–0.92の範囲から0.95–1.00へ引き上げた。最も大きな改善はConfluenceページ作成タスクで、報酬は0.35から1.00へ上昇し、多段階操作をほぼ完了できなかった模型が安定して成功するようになったことを示す。
著者らは本成果を、ニッチな企業API向けの結果最適化された小型モデルに向けた予備的な一歩と位置づけており、完成した解法とは見ていない。論文は読者が考慮すべき2つの限界を明示する。第一に、検証可能報酬を手作業で構築する手法は本稿で報告した少数のエンドポイントを超えてスケールせず、報酬設計そのものが規模拡大のボトルネックになり得る。第二に、5シナリオのうちチケット遷移（ticket-transition）タスクは報酬形状が飽和しており、プロンプト済みの4Bモデルが既に満点を達成しているため、RLVRの利得を示せない。
本論文は2026年7月1日にarXivへ投稿され、番号はarXiv:2607.01465、分類はcs.AI、著者はKarthikeya Aditya Vissaほか4名、投稿者はHarshit Rajgarhiaである。範囲は限定的だが、特定のAPI環境で検証可能報酬を用いて小型モデルを直接最適化するという考え方に明確なベースラインを与えるとともに、報酬設計とシナリオ選択が結論に与える影響の大きさも示している。