RLM（再帰言語モデル）：ツールを呼ぶのではなく、モデルが自分でコードを書いて自分を呼び出す
- RLM とは、モデルが「自分自身を呼び出す」能力を持つこと。メインのエージェントがコードを書いてサブエージェントを生み出し、コンテキストをモデルのウィンドウから変数やファイルへ移します。
- 公式の実測によると、64k コンテキストでは有無の差はわずか。差が顕著になるのは 128k からです。
- 代償も明記されています。レイテンシは高く、トークンも高コスト。その分、正確性と確実性が得られます。
RLM（再帰言語モデル）とは
平たく言えば、RLM は AI モデルに「自分自身を呼び出す」能力を持たせる仕組みです。
この定義だけだと聞き流してしまいがちなので、従来のやり方と並べてみると違いが明確になります。
エージェントに超長いファイルを与えると、その中身をすべて一度に、限られたメモリ（コンテキストウィンドウ）へ詰め込んで分析しなければなりません。
結果として、前の方を覚えていると後ろを忘れたり、要約する段階で大量の詳細が失われたりします。
モデルのオーケストレーションのロジックはコードで書かれます。メインのエージェントが指揮官となり、コードを書いて複数のサブエージェントを生み出し、役割分担させます。これが divide and conquer です。
コンテキストや中間データの大半は変数やローカルファイルに置かれ、コンテキストウィンドウに無理やり詰め込むことはありません。
具体的な違いはこうです。モデルが「本を丸ごと暗記してから答える」必要はなく、「処理の流れを書いておいて、必要なページだけをめくる」ようになります。
動画では触れられていない背景：RLM という概念自体は LangChain が提唱したものではありません。Alex Zhang 氏が2025年10月に書いたブログが発端で、後に正式な論文（arXiv:2512.24601）が出ています。LangChain はこのパラダイムを自社の Agent フレームワークに組み込み、すぐ使えるようにしたという位置づけです。
この記事で解説するのは、LangChain のオープンソースエンジニア Sydney Runkle 氏による、6分36秒の公式テック解説ビデオです。テーマは Deep Agents で RLM を使う方法です。
LangChain 公式デモ全編（6分36秒）。本サイトにて日中バイリンガル字幕を収録。以下、この動画の内容を解説します。
RLM が解決する課題
RLM は主に3つの問題に取り組みます。最初の2つは Agent の長年の課題です。
従来の Agent は、何万行もあるファイルを扱う際、決定的に（行を漏らさず）処理することが困難です。一度読んで理解に基づいて答える方式は、データ量が増えると信頼性が低くなり、すべての行を本当に確認したとは言えません。
コンテキストウィンドウには限りがあります。長い対話が続けば、いずれ要約して場所を確保しなければなりません。しかし要約は情報を失います（lossy）。圧縮された部分に、まさに重要な行が含まれていないとも限りません。
コード駆動になれば、ループ、並列ファンアウト、パイプラインといった複雑なロジック構造も、モデルは簡単に組み立てられます。コードで書けるオーケストレーションは、すべてこの仕組みでも実現可能です。
オーケストレーションをコードに委ねることで、2つのものが得られます。
- 決定的なカバレッジ。コードがすべての行を処理することを保証し、漏れを防ぎます。これは大規模データの問題を扱う際に特に重要です。
- カスタムオーケストレーション。仕事の進め方を自由に設計できます。コードレベルのプリミティブを使うからです。
Deep Agents で使う方法
Deep Agents は、LangChain が公開しているオープンソースのハーネス（フレームワーク骨格）で、複雑な実タスクをこなす汎用 Agent を構築するためのものです。ここで RLM を有効にする手順は2つだけです。
メインのエージェントに、軽量なコード実行環境をマウントします。ここには設計上のトレードオフがあります。この環境は十分に軽量で、モデルがコードを書いて実行できる一方、巨大なサンドボックス全体を動かすほどの重さはありません。
メインのエージェントはコードを書き、組み込みの task 関数を呼び出してサブエージェントを起動・スケジュールし、処理後はメインのエージェントが結果を集約します。task 呼び出しの前後には他のコードも書けます。呼び出し前にはデータ準備、全呼び出し後には集約処理などが可能です。
始め方はとても簡単です。create deep agent プリミティブを使い、code interpreter middleware を渡せば、code mode が有効になります。
ハイライトした2行が RLM の核心です。オーケストレーションはコードであり、task が唯一の分岐点。その前後は通常のコードです。イメージ図であり、動画の文言そのままではありません。
DEMO実演：16のサブエージェントが俳句トーナメント
デモ環境は decode です。LangChain が Deep Agents フレームワークをベースに作ったターミナル用エージェントで、コマンドラインで decode と打てば起動します。
RLM をトリガーするキーワードは workflow です。デモでの指示は「workflow を実行し、朝食の食べ物に関する俳句を16個作り、トーナメント方式で最優秀作品を選ぶ」というものでした。
次に起きたことは次の通りです。メインエージェントが16のサブエージェントを自動生成し、それぞれがすぐに俳句を書きました。そして、コード（JS eval ツールを呼び出す）を書いてラウンドごとに勝ち抜き戦を実施、ベスト16から準々決勝と進んでいきます。途中、コードの誤りをモデル自身が見つけて修正し、最後に優勝作品（ベリーに関する俳句）が決まりました。
このデモ自体は複雑ではありませんが、形を示しています。まず16個に並列ファンアウトし、トーナメント構造でラウンドごとに収束させる。これが「コードプリミティブで仕事を組織化する」ことの実際の姿です。
性能とベンチマーク比較
デモに加えて、公式の実測データがあります。使用したのは Oolongデータセット で、モデルの長いコンテキスト推論とデータ集約能力を試すためのベンチマークです。
SETUPテスト設計
Oolong の AgNews 部分を使用しています。数千行の大きなテーブルで、各行には日付、ユーザー名、そしてラベルなしのニュース見出しが含まれています。
タスクは2段階です。まずモデルに見出しごとに分類を行わせます。選択肢は4つ、world（世界）、sports（スポーツ）、sci/tech（科学/技術）、business（ビジネス）です。次に、このデータに関する分布的な質問をします。
質問は難易度別に3段階あります。
| 難易度 | タイプ | 例 |
|---|---|---|
| 最も簡単 | カウント | 全見出しの中で、最も少ないラベルはどれか |
| 中程度 | フィルタリング後のカウント | 特定のユーザー名の下に、科学/技術の見出しがいくつあるか |
| 最も難しい | 時間推論 | 2004年8月より前、スポーツの見出しは世界の見出しより多かったか |
難しいのはデータ量です。数千行をモデルに一度に与え、分類・集約・推論をさせるのは、RLM か何らかのコードサポートがなければ、ほぼ不可能です。
RESULT2つのコンテキスト長で結果が大きく異なる
比較したのは、Code Interpreterなしの通常のDeep Agentと、Code Interpreterを有効にしたRLMバージョンです。
両者の差はわずかで、ほぼ互角。この帯域では RLM を導入しても明確な利点は見えません。
RLM 版の優位性は顕著。通常版は広範囲で回答不能に陥ります。
バーの長さは傾向を示すイメージです。動画ではグラフの傾向のみ示され、具体的なスコアは非公開でした。
さらに注目すべきは通常の Agent がどこで負けたかです。128k の帯域では、回答に「正確に答えることができません」「計算がブロックされました」といったものが多数見られました。モデルは過大な情報量に圧倒され、回答を放棄してしまったのです。一方、RLM 版はコードのロジックに従ってタスクを分解し、正しい答えを計算できました。
ここから、コンテキストがさらに長くなるか、問題が難しくなれば、RLM 版がさらに差を広げるだろうと推測できます。
TRADE-OFF代償：遅く、高コスト
代償も動画内で明示されています。RLMモードはレイテンシが明確に高く、消費トークンも増加します。その代わりに得られるのは、正確性と確実性です。
ただし、この領域には最適化の余地が残されています。講演者によれば、さらにチューニングすれば、例えば特定の問題の処理方法を説明するスキル（skills）を設計することで、トークン使用量とコストを大幅に削減できるといいます。
核心的な価値のまとめ
巨大なコンテキストウィンドウに頼るのではなく、「コード+サブエージェントによるdivide and conquer」で大量データを処理します。コンテキストは変数とファイルに格納され、必要な部分だけを取り出します。
複雑で大規模な分類、統計、論理推論を、モデルの理解に基づく大まかな回答ではなく、プログラムが厳密に実行します。これにより、Agentは複雑で現実的なビジネスシナリオでの実用性が大幅に向上します。
「自分が導入すべきかどうか」という問いに対する最も実用的な答えが、この実測の境界線です。データ量がコンテキストを圧迫するほどでなければ、導入しても効果は見えず、レイテンシとコストの無駄になります。128k 規模になるか、タスク自体が行を漏らさないことを要求する場合にこそ、その価値が発揮されます。
動画で明かされなかった情報：実験で使用したモデルは最後まで明かされておらず、これは結論を自分のシナリオに適用できるかどうかに直接影響します。レイテンシとコストは定性的な説明のみで、倍率は不明。正確性もグラフの傾向のみで具体的なスコアは非公開。task 関数のシグネチャとサブエージェントの設定方法は詳述されていません。また、デモでのモデルの自己修正が常態なのか偶発的なのかも明示されていません。
モデルが自分でコードを書いて自分を呼ぶ：コンテキストが128kを超えて初めて差が出る
LangChain エンジニアによる6分半の公式デモ。仕組み、俳句トーナメント、導入判断の実測基準を図解で解説
↓ この1ページで完結 · 動く図あり
RLM（再帰言語モデル）は、モデルに「自分自身を呼び出す」能力を与えます。メインエージェントがコードを書き、複数の分身を生成してデータを処理させ、完了後に結果を集約します。この概念はLangChainの提唱ではなく、Alex Zhang氏の2025年10月のブログとその後の論文が由来です。LangChainはこれを自社のDeep Agentsフレームワークに組み込みました。
資料を一度にコンテキストウィンドウへ。収まらなければ要約するが、要約は情報を失い、圧縮された部分がまさに重要な行かもしれません。
オーケストレーションのロジックはコードに。メインエージェントが指揮官となり、コードを書いて複数の分身に処理を分担させます。資料の大半は変数とファイルに置かれ、必要な部分だけを取り出します。
これによって2つが実現します。コードが全行の処理を保証する（決定的カバレッジ）、そしてループ・並列ファンアウト・多段パイプラインといった複雑なスケジューリングも容易に構築できる（カスタムオーケストレーション）ことです。
Deep Agents は、LangChain のオープンソースフレームワークで、複雑な実タスクを処理する汎用 Agent を構築するためのものです。RLM を追加する手順は2つだけです。メインエージェントに軽量なコード実行環境をマウントし（巨大なサンドボックス全体は不要）、次に組み込みの task 関数を使ってコードからサブエージェントをスケジュールします。呼び出しの前後にはデータ準備や結果集約などのコードを書けます。開始方法は create deep agent プリミティブに code interpreter middleware を渡すだけ。トリガーキーワードは workflow です。
公式デモに加え、実測データもあります。OolongデータセットのAgNews部分（数千行のラベルなしニュース見出し）を使用しています。タスクは、まず各見出しを分類（ワールド/スポーツ/テック/ビジネス）し、次に統計に関する質問に答えるものです。難易度は「最も少ないラベルは？」から「特定の月以前はスポーツがワールドより多かったか？」まで幅があります。
128k の帯域では、通常の Agent は「計算不能」「正確に答えられない」といった回答が多数を占め、情報量に圧倒されて回答を放棄しました。一方 RLM 版は、コードのロジックに従ってタスクを分解し、正しい答えを計算できました。
この仕組みで得られるのは2つです。1つは、飽和したコンテキストに頼るのではなく、資料を変数とファイルに置いて必要な部分を取り出すこと。もう1つは、大規模な分類・統計・推論をコードが厳密に実行し、モデルの印象による大まかな回答を排除することです。
✔ タスク自体にループ、並列ファンアウト、多段パイプラインなどの複雑なオーケストレーションが必要な場合
✘ データ量がコンテキストを圧迫するほどでない場合。レイテンシが高くトークンも高コストで、効果が見えない
✘ 手軽さ重視で正確性がそれほど問われないシナリオなら、通常の Agent で十分
動画では使用モデルが明かされておらず、正確性もグラフの傾向のみで具体的なスコアは非公開。レイテンシとコストも方向性のみで倍率は不明です。これらの情報は、結論を自分のシナリオに適用できるかどうかに影響します。
for c in 16個