• NeurIPS 2025 spotlight

• 既存のCUA (Computer Use Agent)は、訓練データやアーキテクチャ、開発プロセスの詳細が非公開。

• 主な貢献
• 訓練データセット作成のアノテーション基盤作成
• 訓練データからClaude sonnetを使ったReflectionでデータを増強する戦略を提案。
• 実際にQwen2.5-VL-70Bベースで訓練させて主要ベンチマークで、Claude Sonnet 4に匹敵する結果を獲得。(OSSでは最高)
• 効率的な評価ベンチマーク作成

• 残りは以下
2508.09123.pdf
34.9 MiB
 

• デバイスで動かすような小型の言語モデル（SLM）にメモリ能力を持たせたい

• 既存のメモリシステムはLLMが前提となっているものが多い
• Mem0は会話履歴からの情報抽出・メモリの更新をそれぞれ別の（Tool Call能力のある）LLMに実行させ、長大なプロンプトを使って制御している。これはSLMには厳しい。
Mem0のプロンプト例（情報抽出）

• 提案: LoRAベースの専門アダプタを付与して、単一のSLMが短いプロンプトで複数の役割をこなせるようにする



• LoRAアダプタは3種類
• 情報抽出（会話履歴などから保存すべき情報を抽出）
• メモリ更新（抽出されたデータを元にメモリを更新）
• 回答生成（メモリを使いつつ質問に回答）
• VQAタスクで使うアダプタも別途用意
• 長大なプロンプトが必要だったものは、SLMに求める動きをLoRA学習時に組み込むことで、実行時は一行程度のプロンプトでも適切に動くようになり、コンテキストウインドウを節約できる。
• 情報抽出:
• メモリ更新:
• 学習は教師モデル（Gemma2-27B, gpt-oss-120B）からの蒸留

• 結果: 推論に必要なリソースを押さえた上で、LLMと同程度以上の結果に

• Saga パターンは、1987 年に Hector Garcia-Molina と Kenneth Salem によって発表された論文「Sagas」で初めて提唱された概念
• 複数のサービスにまたがるビジネス処理を、一連のローカルトランザクションの連鎖として実装する設計パターン
オンライン注文システムの例

• 補償トランザクション
• 失敗時のデータ整合性を保つための仕組み
• 途中で失敗した場合、それまでに実行された全てのトランザクションに対応する補償トランザクションが、逆順で実行される
• e.g. 在庫を 1 個減らしたトランザクションの補償は、在庫を 1 個増やすトランザクション

• トランザクション種類の分類
• 補償可能トランザクション（Compensatable Transaction） 
• 後続のステップで失敗が発生した場合に、対応する補償トランザクションによって取り消すことができるトランザクション
• これらのトランザクションは、Saga の前半部分に配置され、ビジネスルールの検証や外部システムとの連携など、失敗の可能性があるステップの前に実行されます。
• ピボットトランザクション（Pivot Transaction）
• Saga における 決定点（Go/No-Go Point） として機能する特別なトランザクション
• ピボットトランザクションが成功すると、Saga は最後まで実行されることが保証されます。逆に、ピボットトランザクションが失敗した場合は、それまでに実行された補償可能トランザクションの補償処理が実行されます。
• 再試行可能トランザクション（Retriable Transaction）
• ピボットトランザクション成功後に実行され、必ず最終的に成功することが保証されているトランザクション
• これらのトランザクションは失敗しても補償処理を行わず、代わりに成功するまで再試行を続けます。

• フェーズ構造による最適化
• フェーズ 1（検証・確認） : 赤色
• 補償可能トランザクションを集約し、失敗時は即座に処理を終了できます。外部在庫確認などのリスクの高い処理をここで実行します。
• フェーズ 2（決定） : 黄色
• ピボットトランザクションである決済処理を実行します。この段階の成功により、以降の処理完了が保証されます。
• フェーズ 3（実行・確定） : 緑色
• 再試行可能トランザクションを順次実行し、データの確定と関係者への通知を行います。

参考：ZennRAGで非構造データを整理する手法「BookRAG」

背景

• 構造や意味の欠落
• テキストベースの手法：ドキュメントのレイアウトを無視してしまう
• レイアウト解析：ブロック間の繋がりが捉えられない

• 検索フローの静的性
• シンプルな質問と複雑な質問の検索プロセスが同じなので、非効率

手法

データの作り方

• 階層ツリー：ドキュメントの目次構造（章、節、パラグラフ…）をそのままツリーにする

• ナレッジグラフ：ドキュメント内の詳細なエンティティ（用語、概念）とそれらの関係性を抽出してグラフ化

検索方法

以下の操作のうち必要なものを選択して実行する。 （参考：ZennRAGで非構造データを整理する手法「BookRAG」）

• Formulator：入力されたクエリをエンティティやサブクエリに分解

• Selector：重要単語との関係性や構造的な条件を元に参照するデータを選択

• Reasoner：関連するドキュメントの関連度を評価

• Synthesizer：回答を生成

結果

効果：推論ステップ数の劇的減少

• トークン1000個生成 → 1000ステップ

• CALM → 250ステップ

エンコーダの工夫

• Variational Autoencoder (VAE) を採用
VAE は latent を 確率分布（平均 μ と分散 σ²） として扱う。
つまり、
• 「圧縮された latent は点ではなく 分布 として表現」
• decoder は latent の揺らぎに耐えられるよう学習する
これにより、
• latent が多少ズレても意味的に同じトークン群を復元

• KL-clipping

• ランダムマスキング・ドロップアウト

Likelihood-free 学習方式

• 正解ベクトルに近づく

• 同時に多様性を失わない（collapseしない）

評価指標

• ベクトルからサンプリングして

• 復元された n-gram (多分 SentencePiece / BPE ベース)がどれだけ正解に一致するか

実験結果：高速かつ高性能

• CALM-M（371M） が
• 通常の Transformer（281M）を 精度で上回る
• 訓練計算量 44%削減
• 推論計算量 34%削減

まとめ

• パラメータ数

• データ量

• 訓練ステップ数

• コンテキスト長

• K=1（従来のトークン生成）

• K=4（4トークンまとめて生成）

• Kを大きくするほど高速化・効率化が進む

1. イントロダクション (Introduction)

• 背景: 大規模言語モデル（LLM）の進化により、自律的にタスクをこなす「AIエージェント」への注目。コーディングだけでなく、金融、保険、教育など多様な分野での導入の進展。

• 課題: しかし、エージェントの導入成功率は低く（ある研究では95%が失敗）、成功と失敗を分ける要因についての技術的知見の不足。

• 研究の独自性: 本研究は、研究室のプロトタイプではなく、「実際にユーザーに使われているデプロイ済みエージェント」に焦点を当てた初の大規模調査という位置づけ。

2. 関連研究 (Related Work)

• これまでの調査は、「将来の市場予測」や「経営幹部の意識調査」、あるいは「学術的分類（Taxonomy）」が中心。

• 本研究は、現場のエンジニアから直接収集した技術的データ（アーキテクチャ、ツール、評価手法など）に基づく点が特徴。

3. 方法論 (Methodology)

• アンケート調査: 306件の有効回答の取得。そのうち86件が「本番運用中」または「パイロット運用中」のシステムに関する回答。

• 詳細インタビュー: 20のチームに対する詳細ヒアリングの実施。いずれも実ユーザーを持つシステムであり、スタートアップから大企業まで多様な組織が対象。

• 定義: 「プロダクション（本番）」とは、ターゲットエンドユーザーが実業務環境で実際に利用している状態の指示。

4. RQ1: アプリケーション、ユーザー、要件 (Applications, Users, Requirements)

4.1 エージェント導入の動機

• 生産性が最優先: 導入理由の圧倒的1位は「生産性向上と効率化（72.7%）」、次点は「人的作業時間の削減（63.6%）」という傾向。

• リスク回避は二の次: 「リスク軽減」や「障害対応迅速化」を理由とするケースは少なく（10〜20%台）、効果測定の難しさが要因と推測。

4.2 適用ドメイン

• 多様な業界: コーディング支援に加え、金融・銀行（39.1%）、テクノロジー（24.6%）、企業サービス（23.2%）など、26以上の多様ドメインでの稼働。

4.3 ユーザー層

• 対人間: 92.5%のシステムが、他のAIではなく「人間」へのサービス提供。

• 社内利用が中心: ユーザーの過半数（52.2%）が社内従業員という構成。社内利用であればエージェントのミスによるリスクが低く、人間監督（Human-in-the-loop）の容易さが背景。

4.4 レイテンシ（応答速度）の要件

• 遅くても許容: 応答に「数分」を許容するシステムが最多で、即時応答（サブ秒）を求めるケースは少数。

• 理由: エージェントが代替するタスクは、人間なら数時間〜数日かかるケース（例：保険審査、障害ログ調査）が多く、数分の思考時間でも「十分高速」とみなされる状況。

• 例外: 音声対話のようなインタラクティブシステムではレイテンシが深刻課題。

5. RQ2: モデル、アーキテクチャ、技術 (Models, Architectures, Techniques)

5.1 モデルの選択

• プロプライエタリ（商用）モデルの優勢: 20件のインタビュー中17件がOpenAI (GPT-4) や Anthropic (Claude) などのクローズドソースモデルを採用。

• オープンソースの役割: コスト削減やデータの社外持ち出し禁止（規制）など制約下での利用が中心。

• 複数モデルの利用: 半数のチームが複数モデルを使い分け。理由は推論能力よりも、コスト最適化やモデル更新時の挙動変化（ドリフト）管理。

5.2 重み調整（ファインチューニング）

• ほぼ未実施: 70%のケースで追加学習（ファインチューニングや強化学習）の非実施。

• プロンプトで十分: 高性能モデルへの適切プロンプト付与のみで多くのユースケースに対応可能という状況。ファインチューニングはメンテ負荷の高さやアップデート脆弱性が理由で敬遠。

5.3 プロンプティング戦略

• 手動作成が基本: プロンプトは人手による作成・修正が中心。DSPyのような自動最適化ツールは約5%とレアケース。

• 長大プロンプト: 多量のコンテキスト保持のため、1万トークン超のプロンプトが12%存在。

5.4 エージェントアーキテクチャ

• 自律性の制限: エージェントの連続実行ステップ数を10ステップ以下に制限するシステムが全体の68%。

• 静的ワークフロー: 自律プランニングより、定義済手順（RAGパイプラインなど）に従う静的ワークフローの選好。

5.5 開発フレームワーク

• アンケートと実態の乖離: アンケートでは6割がLangChainなどの利用と回答する一方、成功インタビュー事例（20件）の85%がフレームワーク非使用（自社製スクラッチ実装）。

• 理由: 抽象化過多によるデバッグ難、依存関係の複雑化などを懸念し、自前APIコールの方が制御しやすいという判断。

6. RQ3: 評価手法 (Evaluation)

6.1 ベースラインとベンチマーク

• 比較対象の不在: 多くのシステム（61.3%）が既存非エージェントシステムとの厳密比較を未実施。

• 独自ベンチマーク: 汎用ベンチマークの実業務非適合により、25%が独自テストセット（ゴールデンセット）を作成。残り75%は正式ベンチマーク不保持でA/Bテストやユーザーフィードバックによる評価。

6.2 評価方法

• 人間評価が中心: 74.2%のチームがHuman-in-the-loop（人間確認）を実施。開発時のみならず実行時にも人間が最終チェックを担当。

• LLM-as-a-judge: LLMによる評価手法も51.6%で採用。ただし単独利用はなく、必ず人間検証との併用（信頼度スコア確認など）。

7. RQ4: 開発の課題 (Challenges)

7.1 信頼性と評価の難しさ

• 最大課題: 全ステージで「信頼性（Reliability）」が最大課題。

• 正解不明問題: エージェント出力の正否を自動判定する検証メカニズムの不在（例：生成文の質）による評価困難。

7.2 レイテンシの課題

• ブロッカーではない: レイテンシは課題として挙がるものの、導入断念レベルの決定的問題となるのは15%程度。

• 非同期処理: 多くのシステムがバックグラウンドでの非同期処理により、ユーザー体験を損なわず時間をかけた処理を実現。

7.3 セキュリティとプライバシー

• 優先度中程度: セキュリティは重要ながら、出力品質や正しさ（信頼性）に比べると優先度は低下。

• 対策: サンドボックス環境での実行、データベースへの書き込み権限不付与（Read-only）によるリスク管理。

8. ディスカッション (Discussion)

8.1 制約による信頼性の確保

8.2 豊富な応用機会

8.3 未解決の研究課題

• 失敗検知: エージェントの失敗を実行時に検知するツール・手法の必要性。

• 事後学習: ファインチューニングをより手軽かつモデルアップデート耐性の高いものとする研究の必要性。

• 推論時探索: 複数モデルを用いた推論時探索（inference-time search）手法の実用化への期待。

9. 結論 (Conclusion)

感想

• 脱フレームワークや少ないステップ数でのエージェント開発が主流。自律性よりもコントローラビリティとシンプルさ、手軽さ優先。

• 遅くて信頼（人間の介入有り）＞早くて不安（完全自動）。

• 評価セットは自作する。汎用ベンチマークは業務を反映していない。