Recursive Video In-Context Learning for Agenticに見るtool use設計

description: LLMエージェントがfrozen VLAポリシーを呼び出しながらエピソードをまたいで改善する仕組み、Recursive Video In-Context Learningの技術的な構造と、tool use・MCPへの示唆を整理します。

meta description: Recursive Video In-Context Learning for Agenticの仕組みを解説。テキストメモリの限界をデモ動画の再帰的参照で補う設計と、LLMエージェントのtool use実装への応用ポイントをまとめます。

---

何が出たのか

2026年10月上旬、ロボティクス分野の研究コミュニティで「Recursive Video In-Context Learning for Agentic Robot」と題した論文・実装が注目を集めました。HuggingFaceのデイリートレンドやRedditのr/MachineLearningでも取り上げられ、エージェント設計に関心を持つエンジニアの間で議論が広がっています。

この研究が扱う問題設定はシンプルです。LLMエージェントがfrozen VLA（Vision-Language-Action）ポリシー——つまりパラメータを固定したまま使う視覚・言語・行動の統合モデル——をツールとして呼び出しながらタスクをこなすとき、エピソード（1回の試行）をまたいで「何をやったか」はテキストメモリに残せます。しかし「どうやればうまくいくか」という手続き的な知識は、テキストだけでは十分に記録・再利用できません。

デモ動画を参照すれば手続きは伝わります。ただし動画をそのままコンテキストに詰め込むとトークン数が爆発し、長くなるほど関連フレームを見つけにくくなります。Recursive Video In-Context Learning（以下、R-VICL）はこの問題に対して、「過去の成功エピソードの動画を再帰的に検索・圧縮してコンテキストに差し込む」という設計で応答しています。

---

技術的に面白い点

R-VICLの構造を整理すると、大きく3つの仕組みが組み合わさっています。

エピソードメモリの二層構造

テキストメモリ（何をしたか）と動画メモリ（どうやったか）を分けて管理します。テキスト側はLLMが直接読めるJSON形式のログで、動画側はフレーム列をベクトル化してベクトルDBに格納します。クエリ時は現在の状態観測をキーにして、過去エピソードの中から「今の状況に近い瞬間」を含むフレームセグメントを取り出します。

再帰的な圧縮と参照

取り出したフレームセグメントをそのまま使うのではなく、VLMで要約テキストと代表フレームのペアに圧縮します。この圧縮済みサマリーを次のエピソードでも参照可能なメモリとして保存し直すため、「圧縮→参照→再圧縮」のサイクルが再帰的に回ります。結果として、エピソード数が増えても1回のコンテキスト長は一定範囲に収まります。

frozen VLAポリシーをツールとして呼び出す設計

LLMはプランニングと記憶管理を担い、実際の低レベル行動（ロボットアームの軌道生成など）はfrozen VLAポリシーに委譲します。LLMはVLAを「tool call」として呼び出し、戻り値（成功・失敗・観測）を受け取ってメモリを更新します。このtool use構造は、ロボット制御に限らずLLMエージェントが外部APIやモデルを呼び出す一般的なパターンと同型です。

ベンチマーク上では、テキストメモリのみのベースラインと比較してタスク成功率が複数のロボット操作タスクで有意に向上しており、特に「初見では失敗するが数エピソード後に成功率が上がる」という学習曲線の改善が報告されています。

---

既存の流れとの違い

LLMエージェントがエピソードをまたいで改善する手法は、ReAct（Reasoning + Acting）やReflexionなど既存のフレームワークでも試みられてきました。R-VICLとの差分を整理します。

Reflexionとの比較

Reflexionはエピソード終了後にLLMが自己評価テキストを生成し、次のエピソードのプロンプトに追加します。テキストのみで完結するため実装はシンプルですが、「どう動いたか」という視覚的・手続き的な情報は落ちます。R-VICLはここに動画モダリティを加えることで、テキストでは表現しにくい「力加減」「タイミング」「空間的な経路」を記憶に含められます。

RAG（Retrieval-Augmented Generation）との比較

RAGはテキストや画像をベクトル検索で取り出す手法として広く使われています（外部知識をLLMに動的に渡す仕組み）。R-VICLはRAGの動画版と見ることもできますが、「圧縮→再帰的保存」のサイクルがある点が異なります。通常のRAGは元データを変更しませんが、R-VICLはエピソードを重ねるごとにメモリ自体が更新・圧縮されていきます。

MCPとの関係

MCP（Model Context Protocol）はツール定義とコンテキスト管理を標準化するプロトコルです。R-VICLのtool use構造——LLMがツールを呼び出し、結果をメモリに書き戻す——はMCPのtool callスキーマと整合性が高く、MCPサーバー上にVLAポリシーや動画メモリ検索をツールとして実装する構成が自然に考えられます。

---

エージェント実装で詰まりやすい点

R-VICLの設計を自社プロダクトやシステムに応用しようとすると、いくつかの実装上の論点が出てきます。

動画フレームのベクトル化コストとレイテンシ

フレームをVLMでエンコードする処理はバッチ推論でも無視できないコストです。リアルタイム性が求められるユースケースでは、エピソード終了後に非同期でインデックスを更新する設計が現実的です。同期的に処理しようとするとtool callの応答待ちが長くなり、エージェントループ全体のレイテンシに影響します。

圧縮精度の評価とfallback

VLMによる動画要約は「何を残すか」の判断をモデルに委ねます。重要なフレームが要約から落ちた場合、後続エピソードで誤った手続きを参照するリスクがあります。圧縮前後の情報量を定量的に評価する指標（例：タスク関連キーフレームの再現率）を定義し、閾値を下回ったら元フレームを保持するfallbackを設けることが安全策になります。

メモリの肥大化と権限管理

エピソードを重ねるとベクトルDBのエントリが増え続けます。古いエピソードの削除ポリシー、ユーザーやタスクごとのメモリ分離、誰がメモリを読み書きできるかの権限設計は、プロダクト運用では早めに決める必要があります。特にマルチユーザー環境では、あるユーザーの失敗エピソードが別ユーザーの推論に混入しないよう、メモリのスコープをAPIレベルで明示的に管理する必要があります。

ログと再現性

エージェントがどのエピソードメモリを参照してtool callを発行したかをログに残さないと、デバッグが困難になります。tool callのリクエスト・レスポンス、参照したフレームセグメントのID、圧縮サマリーのバージョンをセットで記録する設計が、後から挙動を追跡するために有効です。

frozen前提の崩れ

R-VICLはVLAポリシーをfrozenとして扱います。しかし実際のプロダクトでは、依存するモデルやAPIがバージョンアップされることがあります。ポリシーが更新されると過去の動画メモリとの整合性が崩れる可能性があるため、モデルバージョンをメモリのメタデータとして記録し、バージョン不一致時はメモリを無効化するか再インデックスするフローを用意しておくことが望ましいです。

---

Spectralの見解

1. 技術的な読み

R-VICLが示す最も重要な設計原則は、「エージェントのメモリをモダリティごとに分けて管理し、それぞれに適した検索・圧縮を当てる」という点です。テキストメモリと動画メモリの二層構造は、ロボット制御に限らず、画面操作ログや音声インタラクションを扱うエージェントにも転用できる考え方です。また、frozen外部モデルをtool callで呼び出し、LLMはオーケストレーションに専念するという役割分担は、現在のLLMエージェント設計のベストプラクティスと一致しており、MCPベースの実装との親和性も高いと判断しています。

2. PoCで確認すべき点

実際に試す場合、まず確認すべきは「動画メモリ検索の精度がタスク成功率にどの程度寄与するか」です。ベクトル検索のクエリ設計（現在の観測をどう埋め込むか）と、圧縮サマリーの品質が結果を大きく左右します。PoCでは、テキストメモリのみのベースラインと比較したA/Bテストを設計し、動画メモリの追加コスト（レイテンシ・ストレージ・推論費用）に見合う成功率の改善があるかを定量的に確認することを推奨します。

3. 業務・プロダクト実装に移す時のリスク

最大のリスクは運用コストの見積もり誤りです。フレームエンコードとベクトルDB管理は、エピソード数が増えるにつれてストレージと推論コストが線形以上に増加する可能性があります。また、圧縮による情報損失が蓄積すると、エピソードを重ねるほど参照メモリの質が下がる「劣化サイクル」に入るリスクがあります。導入前にエピソード数に対するコストと精度の変化を小規模で計測し、スケールアップの判断基準を数値で持っておくことが重要です。意思決定者の視点では、「何エピソード試せば効果が出るか」「効果が出なかった場合の撤退基準は何か」を事前に定義することが、プロジェクトリスクの管理につながります。

---

まとめ

Recursive Video In-Context Learningは、LLMエージェントが外部ツール（frozen VLAポリシー）を呼び出しながらエピソードをまたいで改善するための、動画メモリを活用した設計パターンです。テキストメモリだけでは記録しにくい手続き的な知識を、動画フレームの再帰的な圧縮・検索によって補う点が既存手法との主な差分です。

実装上は、レイテンシ管理・圧縮精度の評価・メモリの権限設計・ログの構造化・モデルバージョン管理が主な論点になります。MCPのtool callスキーマとの整合性が高いため、既存のLLMエージェント基盤に動画メモリレイヤーを追加する形でPoCを組みやすい構造です。

ロボット制御という文脈で提案された手法ですが、その設計原則——モダリティ別メモリ管理、frozen外部モデルのtool use、再帰的な圧縮——は、画面操作エージェントや業務プロセス自動化など、より広いエージェント実装に応用できる考え方として注目しています。

---

*Spectralでは、LLMエージェントの設計・PoC・プロダクト実装に関する技術支援を行っています。tool use設計やMCPベースのエージェント構築について相談したい場合は、お問い合わせフォームからご連絡ください。*

関連論点として FlowEvo Self-Evolving Agents through the: AIエージェント実装の詰まりどころ もあわせて読むと、この技術動向の背景を追いやすくなります。

Spectralでは、技術調査からPoC設計、プロダクト実装まで支援しています。実現性の確認や事業活用の相談は サービス詳細 と お問い合わせ をご覧ください。