RLMエージェントにタスク指示を直接渡せるようになり、REPLの仕組みを理解するための無駄な試行が減ります。
この記事では、オープンソースのRLM実装「fast-rlm」v0.2.0で追加されたシステムプロンプト注入機能の概要と使い方、従来手法との違いを解説します。
この記事でわかること
- fast-rlm v0.2.0の
instruction引数で何が変わったか - システムプロンプト注入がRLMの挙動に効く理由
- ルートエージェントとサブエージェントへの指示の渡し方
- 長文コンテキストのカウントベンチマークでの検証結果
fast-rlmとは
fast-rlmは、Recursive Language Models（RLM）を実装したPythonライブラリです。開発者はYouTubeチャンネル「Neural Breakdown with AVB」のAVB氏。MIT CSAILの研究者らが提唱したRLM論文（arXiv:2512.24601）の考え方を、DenoとPyodideで動くREPL上に独自実装したもので、論文著者とは無関係の独立プロジェクトです。
RLMは、LLMが外部REPLを通じて任意に長いプロンプトを扱う推論手法です。モデルはPythonコードを書いて入力を探索・分解し、必要に応じてllm_query()でサブエージェントを再帰的に呼び出します。サブエージェントの応答は親のコンテキストにそのまま載せず、REPL内の変数として返すのが特徴です。これにより、モデルのコンテキストウィンドウを超える長文もプログラム的に処理できます。
課題：REPL内に指示を書くとエージェントが迷う
fast-rlmのエージェントは、タスク遂行のためにREPLでPythonコードを書きます。従来、開発者がエージェントに追加の制約や方針を伝えたい場合、プロンプト本文やREPL内のprint出力に指示を埋め込む必要がありました。
この方法には弱点があります。エージェントはまずREPLの仕組みを理解し、指示をコード内で参照する手順を組み立てなければなりません。長文コンテキストのカウントのような単純なタスクでも、REPL操作に思考リソースを割かれ、本来の作業に到達するまでに時間がかかります。LLMはシステムプロンプトへの追従で学習されているため、REPL内の断片的な指示よりも、システムプロンプトへの直接注入の方が軌道を制御しやすいというのが、開発者AVB氏の主張です（参考）。
v0.2.0の変更点：instruction引数
2026年6月19日、AVB氏がXでfast-rlmの最新版を発表しました。PyPIではv0.2.0として公開されており、中核となる新機能はinstruction引数です。
fast_rlm.run()にinstructionを渡すと、エージェントのシステムプロンプト末尾に次の形式で追記されます。
Here is the user's instructions - you must follow it closely:
{instruction}
エージェントはREPL内で指示をprintする必要がなく、システムプロンプトから直接タスク方針を読み取れます。
ルートエージェントへの指定
import fast_rlm
result = fast_rlm.run(
"Summarize the attached incident report.",
instruction="Write all output in formal British English and never use bullet points.",
)
instructionはRLMConfigのフィールドではなく、run()の呼び出しごとに渡す引数です。省略時はシステムプロンプトに何も追加されません。
サブエージェントへの指定
指示はエージェントごとに独立しており、親から子へは自動継承されません。サブエージェントに制約を与えるには、REPL内のllm_query()呼び出し時に明示的に渡します。
result = await llm_query(
chunk,
instruction="Extract only dollar amounts; return them as a JSON list.",
)
この設計は「再帰的・非継承」です。各エージェントは自分を起動した側が渡した指示だけを見ます。子エージェントがさらに孫を呼ぶ場合も、新たにinstruction=を指定しない限り指示は空のままです。ラン全体に一律で適用するグローバル指示は意図的に設けられていません。
公式ドキュメントでは、強い指示はビルトインプロンプトの後に追記されるため、出力形式やタスク自体を上書きし得る点に注意が促されています。タスク内容の再述ではなく、「どう答えるか」に絞って書くのが推奨です（参考）。
長文カウントベンチマークでの効果
AVB氏はGLM-5.2を使い、長文コンテキストのカウントベンチマークでinstructionの有無を比較しました。instructionを使わない場合、エージェントはREPLの仕組みを理解するための試行錯誤に時間を費やす一方、システムプロンプト注入後はタスクに直接取りかかれるようになり、結果に大きな差が出たと報告しています（参考）。
fast-rlmリポジトリにはbenchmarks/oolong_synth_benchmark.pyやbenchmarks/longbench_benchmark.pyなどの評価スクリプトも同梱されており、長文処理の性能検証を自分の環境で再現できます。ベンチマーク実行にはuv sync --extra benchmarksで依存関係を入れたうえで、各スクリプトを実行します。
検証に使われたGLM-5.2は、Z.AIが2026年6月17日に公開したフラッグシップモデルで、100万トークンのコンテキストを安定して扱える点が特徴です。fast-rlmではOpenRouter経由でz-ai/glm-5系のモデル名をprimary_agentに指定して利用できます。
使い方の全体像
fast-rlmの導入はpip install fast-rlmで行います。実行にはPython 3.10以上とDeno 2以上が必要です。APIキーは環境変数RLM_MODEL_API_KEYに設定し、デフォルトではOpenRouterのOpenAI互換APIに接続します。
from fast_rlm import run, RLMConfig
config = RLMConfig.default()
config.primary_agent = "z-ai/glm-5"
config.sub_agent = "minimax/minimax-m2.5"
config.max_depth = 5
result = run(
"Count the r's in 50 fruit names",
instruction="Focus on accuracy; return only the final integer count.",
config=config,
)
CLIからも同様の指定が可能です。fast-rlmコマンドにプロンプトと--primary-agentなどのオプションを渡してワンショット実行できます。
既存機能との関係
instructionは既存の仕組みを置き換えるものではありません。カスタムPythonツールの登録、MCPサーバー連携、Pydanticによる構造化入出力、予算上限（max_money_spentやmax_depth）など、v0.1系からの機能はそのまま併用できます。
環境変数の注入（env_variables）は全エージェントに継承されるのに対し、instructionはエージェント単位で個別指定する点が対照的です。APIキーをREPLに渡しつつ、ルートとサブで異なる作業方針を与えたいケースに向いています。
他の長文処理手法との違い
コンテキスト圧縮（compaction）や検索エージェントは、入力の一部を要約・抽出してコンテキストに載せる手法です。RLMは入力全体をREPL上の変数として保持し、コードで必要な部分だけを都度参照します。RLM論文では、GPT-5をベースにしたRLMが複数の長文ベンチマークで圧縮やCodeActなどの手法を大きく上回ると報告されています（参考）。
fast-rlmはこのRLMパラダイムを手軽に試せる実装として位置づけられ、instruction追加により開発者がエージェントの振る舞いをより細かく制御できるようになりました。長文ドキュメントの要約、ログ解析、大規模テキストからの情報抽出など、RLMを使ったエージェント開発を進めている場合は、v0.2.0へのアップデートを検討する価値があります。