Amazon Bedrock AgentCore でコンテキストウィンドウの壁を突破する

数百万文字にわたる文書を分析すると、コンテキストウィンドウの壁にぶつかり、最大のコンテキストウィンドウさえも不十分になります。モデルは入力を拒否するか、不完全な情報に基づいて回答を生成します。収まらない文書に対してどのように推論すればよいのでしょうか？ この記事では、[Amazon Bedrock AgentCore](https://aws.amazon.com/bedrock/agentcore/) のコードインタープリタと [Strands Agents SDK](https://strandsagents.com/) を使用して、再帰型言語モデル（Recursive Language Models: RLM）を実装する方法を学びます。最後には、以下ができるようになります。 - コンテキストサイズの上限なしで、さまざまな長さの文書を処理する。 - 反復的な文書分析のための永続的な作業メモリとして Bedrock AgentCore Code Interpreter を使用する。 - 特定の文書セクションを分析するために、サンドボックス化された Python 環境内でサブ大規模言語モデル（sub-LLM）呼び出しをオーケストレーションする。 ## コンテキストウィンドウが不十分な理由 単一企業の 2 年分の年次報告書の指標を比較するという典型的な財務分析タスクを考えてみましょう。各報告書は 300〜500 ページに及びます。アナリストレポート、SEC 提出書類、補足資料を加えると、合計で数百万文字に達します。 これらの文書を直接モデルに送信すると、入力がモデルのコンテキストウィンドウ制限を超えてリクエストが失敗するか、あるいは入力は収まるものの、モデルが長い入力内の中央部分にある情報に注意を向けるのが難しくなるという問題（「真ん中で失われる」問題として知られています）が発生します。 両方の失敗モードは、コンテキストウィンドウサイズがプロンプトエンジニアリングだけでは解決できないハードリミットであるために存在します。文書サイズをモデルのコンテキストウィンドウから切り離すアプローチが必要です。 ## RLMs: コンテキストを環境として扱う Zhang らによって [arXiv:2512.24601](https://arxiv.org/abs/2512.24601) で紹介された RLM（再帰型言語モデル）は、この問題を再定義します。文書全体をモデルのコンテキストウィンドウに読み込むのではなく、RLM は入力をプログラム的に操作できる外部環境として扱います。 ![image](https://d2908q01vomqb2.cloudfront.net/f1f836cb4ea6efb2a0b1b99f41ad8b103eff4b59/2026/05/07/ML-20487-image-1.png) *図 1. 再帰型言語モデルは反復ループとして動作します：ルート LLM が文書環境を検索するためのコードを生成し、選択されたチャンクに対してセマンティック分析をサブ LLM に委譲し、結果をワーキングメモリに蓄積した上で次のステップを精緻化します。 モデルが受け取るのは、問い合わせと利用可能な環境の説明のみです。その後、モデルは文書を検索・分割・分析するためのコードを記述し、反復的に処理を行います。特定のセクションのセマンティック理解が必要な場合、その分析をサブ LLM の呼び出しに委譲し、結果はコンテキストウィンドウのスペースを消費するのではなく、Python 変数としてワーキングメモリに保持します。 これにより再帰構造が形成されます：ルート LLM がコードを通じて分析を調整し、セマンティックタスクが必要に応じてサブ LLM を呼び出しますが、文書全体はモデルのコンテキストウィンドウに入ることはありません。 ## アーキテクチャ ここでは、Amazon Bedrock AgentCore Code Interpreter を実行環境として用いて RLM（Reinforcement Learning Loop）を実装する方法を示します。Amazon Bedrock AgentCore Code Interpreter は、実行間でも状態を保持するサンドボックス化された Python ランタイムを提供します。このアーキテクチャには、3 つのコンポーネントが連携して動作しています。 Strands Agents SDK を用いて構築されたルート LLM エージェント（LLM: 大規模言語モデル）がユーザーの問い合わせを受け取り、実行すべきコードを決定します。Amazon Bedrock AgentCore Code Interpreter セッションは PUBLIC ネットワークモードで実行され、完全なドキュメントが Python 変数として読み込まれています。サンドボックスに注入された llm_query() 関数は、Code Interpreter 内部から直接 Amazon Bedrock を呼び出すため、サブ LLM の結果は Python 変数内に留まり、ルート LLM のコンテキストウィンドウ（文脈の保持範囲）へ流れ込むことはありません。 *![image](https://d2908q01vomqb2.cloudfront.net/f1f836cb4ea6efb2a0b1b99f41ad8b103eff4b59/2026/05/07/ML-20487-image-2.png)* *図 2. Amazon Bedrock AgentCore Code Interpreter を用いた RLM アーキテクチャ。ルート LLM エージェントは、完全な入力データが事前に読み込まれたサンドボックス環境内で反復的に Python コードの記述と実行を行います。このサンドボックス内から、エージェントは特定のセクションの意味解析のために Amazon Bedrock を経由してサブ LLM を呼び出すことができます。中間結果はサンドボックス内の Python 変数として保持されるため、ルート LLM のコンテキストウィンドウはオーケストレーション（調整・制御）に集中した状態を維持できます。* Amazon Bedrock AgentCore Code Interpreter の PUBLIC ネットワークモードは、サンドボックスから Amazon Bedrock へのアウトバウンド API 呼び出しを許可することでこれをサポートします。永続的なセッション状態により、変数、中間結果、抽出データが複数のコード実行にわたって蓄積され、分析全体を通じて持続するモデルの作業メモリが提供されます。 ## Implementation Amazon Bedrock AgentCore Code Interpreter を使用して RLM をセットアップし実行するには、以下の手順に従ってください。 ## Prerequisites 本記事の手順を追うには、以下の準備が必要です： - Amazon Bedrock 基盤モデル（FMs）へのアクセス権限を持つ AWS アカウント。 - Python 3.10 以降。 - 適切な認証情報で設定された AWS Command Line Interface (AWS CLI)。 - Python および基本的な AWS SDK (Boto3) の使用に関する知識。 - PUBLIC ネットワークモードに設定された Amazon Bedrock AgentCore Code Interpreter。 - bedrock:InvokeModel、bedrock-agentcore:StartCodeInterpreterSession、bedrock-agentcore:InvokeCodeInterpreter、および bedrock-agentcore:StopCodeInterpreterSession に対する IAM 権限。 **1: Code Interpreter セッションの開始とドキュメントの読み込み** Amazon Bedrock AgentCore Code Interpreter セッションを作成し、ドキュメントをサンドボックスに書き込んでください： import boto3 import json # Bedrock AgentCore のコードインタプリタセッションを開始する client = boto3.client('bedrock-agentcore', region_name='us-east-1') response = client.start_code_interpreter_session( codeInterpreterIdentifier=code_interpreter_id, name="rlm-session", sessionTimeoutSeconds=3600 ) session_id = response["sessionId"] # ドキュメントをサンドボックスに書き込む client.invoke_code_interpreter( codeInterpreterIdentifier=code_interpreter_id, sessionId=session_id, name="writeFiles", arguments={"content": [{"path": "_context.txt", "text": document}]} ) **2: ドキュメントを初期化し、サンドボックス内で llm_query() ヘルパー関数を定義する** サンドボックス内でドキュメントを読み込み、サブ LLM（大規模言語モデル）の呼び出しで使用される llm_query() 関数を定義します: # Bedrock AgentCore のコードインタプリタサンドボックス内で実行されます with open('_context.txt', 'r') as f: context = f.read() def llm_query(prompt: str) -> str: """サンドボックス内からサブ LLM にクエリを実行する。""" response = bedrock_client.invoke_model( modelId=sub_model_id, body=json.dumps({ "anthropic_version": "bedrock-2023-05-31", "max_tokens": 4096, "messages": [{"role": "user", "content": prompt}] }) ) result = json.loads(response['body'].read()) return result['content'][0]['text'] **3: Strands Agent を作成し、クエリを実行する** セッション内でコードを実行する単一の execute_python ツールを持つ Strands Agent を作成し、質問を送信します: from strands import Agent agent = Agent( model="us.anthropic.claude-sonnet-4-5-20250929-v1:0", system_prompt=rlm_system_prompt, tools=[execute_python], ) answer = agent("What are the key revenue trends across these reports?") The agent iteratively writes and executes Python code to explore the document, extract relevant sections, and call llm_query() when it needs semantic analysis of specific chunks. ## Evaluation In our evaluation, we compare RLM against two baselines, namely *Base* and *Long Context*. In the Base approach, the full document is sent directly to the model in a single API call with 200K token context window. This is the most straightforward strategy but fails when documents exceed the model's context window. In the Long Context approach, we use Claude's extended 1 million token context window, which handles larger inputs but still has an upper bound and can suffer from problems like "lost in the middle". We evaluated this approach on the Financial Multi-Document QA subset of [LongBench v2](https://huggingface.co/datasets/zai-org/LongBench-v2), a benchmark designed to test LLM performance on tasks requiring reasoning across long contexts. This subset contains 15 multiple-choice questions, each requiring analysis across multiple financial reports with context lengths up to approximately 2 million characters. 私たちは2つの指標を報告します：*成功率*は、モデルが入力制限を超えずにエラーに遭遇することなく処理できる質問の割合であり、*精度*は、尋ねられた全質問に対する正解回答の割合です（未回答の質問は不正解としてカウントされます）。 前述の3つのアプローチを比較しました：*Base*、*Long Context*、および*RLM*です。RLMは、4つのClaudeモデル（ルートLLMとして機能）に対して評価を行いました。サブLLMには、パフォーマンスと効率のバランスを取るため、同じモデルまたはHaiku 4.5が設定されました。ローカライズされたチャンクレベル分析において、著しく低いレイテンシとコストを提供するため、サブLLMとしてClaude Haiku 4.5を使用します。一方、ルートモデルはグローバルな推論とオーケストレーションの責任を保持します。 *Table 1. LongBench v2 Financial Multi-Document QA (15 questions). Human expert accuracy from the LongBench v2 paper.* *Claude Sonnet 4.6 および Opus 4.6 の Base 結果は省略されています。これらのモデルはデフォルトで100万トークンのコンテキストウィンドウを持つため、Base と Long Context アプローチが同等となるからです。 **Model** **Approach** **Success rate** **Accuracy** Claude Haiku 4.5 Base 46.7% 33.3% Claude Haiku 4.5 + Haiku 4.5 RLM 100.0% 66.7% Claude Sonnet 4.5 Base 46.7% 26.7% Claude Sonnet 4.5 Long Context 93.3% 66.7% Claude Sonnet 4.5 + Haiku 4.5 RLM 100.0% 66.7% Claude Sonnet 4.6 Long Context 93.3% 60.0% Claude Sonnet 4.6 + Haiku 4.5 RLM (Reinforcement Learning from Human Feedback) 100.0% 73.3% Claude Opus 4.6 Long Context 93.3% 66.7% Claude Opus 4.6 + Haiku 4.5 RLM (Reinforcement Learning from Human Feedback) 100.0% **80.0%** Human Expert – – 40% この結果は、3 つの重要な知見を示しています： - RLM はコンテキスト長に起因する失敗を軽減します。ベースラインおよびロングコンテキストのアプローチは、コンテキストの制限により一部の入力を処理できません。ベースラインアプローチでは成功率が 46.7 パーセント（15 問中 7 問）であり、ロングコンテキストでは 93.3 パーセント（15 問中 14 問）です。一方、RLM は文書サイズとコンテキストウィンドウサイズの完全な分離により、評価されたすべての構成で 100 パーセントの成功率を達成します。文書の規模が大きくなるにつれて、この信頼性の優位性は実用的な展開においてますます重要になります。 - RLM はほとんどのモデルで精度を向上させます。RLM は Claude Sonnet 4.6 および Opus 4.6 の精度を、それぞれロングコンテキストの 60.0 パーセントおよび 66.7 パーセントから 73.3 パーセントおよび 80.0 パーセントに向上させ、Claude Haiku 4.5 ではベースラインの 33.3 パーセントから 66.7 パーセントに引き上げます。最も大きな改善が観測されるのは Claude Haiku 4.5 ですが、より強力なモデル（Sonnet 4.6, Opus 4.6）では一貫した改善が見られるものの、その幅は小さくなります。Claude Sonnet 4.5 はロングコンテキストベースラインと比較して改善を示さず、両方の設定で 66.7 パーセントを達成しています。これは、RLM の効果向上が、ルートモデルがタスクをサブクエリに分解する能力の効率性に依存しており、この設定では Sonnet 4.5 における改善が制限される可能性があることを示唆しています。 - サブ LLM の選択は本設定において限定的な影響しか持ちません。追加の実験として、Claude Haiku 4.5 をサブ LLM として使用する場合と、ルートモデルおよびサブ LLM の両方に同じモデルを使用する場合を比較しましたが、構成全体で精度に有意差は見られませんでした。これは、このタスクにおいては性能が主に、サブクエリを実行するサブ LLM の能力ではなく、効果的なサブクエリを生成できるルートモデルの能力によって駆動されていることを示唆しています。 ## コードリポジトリ理解へのスケーリング：LongBench v2 CodeQA Financial QA 評価は、長文ドキュメントの推論に焦点を当てています。次に、異なる領域への一般化、すなわち**コードリポジトリの理解**を検証します。これは大規模なコードベースのナビゲーション、関数依存関係の解決、ファイル間でのロジスの追跡を必要とする設定です。この設定は、コード実行を通じたプログラムによる探索に特に適しています。 これをテストするため、LongBench v2 のコードリポジトリ理解サブセットで評価を行いました。ここには 50 問の多肢選択式問題が含まれています。各問題は、文脈として完全なコードリポジトリ（約 10 万文字から 1,600 万文字以上まで）を提供し、コードベースをナビゲートして理解する必要がある実装の詳細、API の動作、またはアーキテクチャ上の決定について質問します。 アーキテクチャは Financial QA と同じで、完全なリポジトリが単一のコンテキスト変数として Code Interpreter（コード実行環境）のサンドボックスに読み込まれます。モデルは Python コードを記述して関連ファイルを検索し、関数定義を抽出し、呼び出しチェーンを追跡し、llm_query() を使用して特定のコードセクションを分析します。 4 つの Claude モデルを用いて、同じアプローチで 50 問すべてを評価しました。Financial QA の知見に基づき、強力なモデルではサブ LLM（大規模言語モデル）の選択が限定的な影響しか持たないため、RLM（Reinforcement Learning with Models? ※文脈より推測：リソース制限下での学習や実行）の実行全体でサブ LLM を Claude Haiku 4.5 に固定しました。 *表 2. LongBench v2 コードリポジトリ理解 (50 問)* **モデル** **アプローチ** **成功率** **精度** Claude Haiku 4.5 ベース 30.0% 20.0% Claude Haiku 4.5 + Haiku 4.5 <td

Amazon Bedrock AgentCore でコンテキストウィンドウの壁を突破する

背景や根拠まで確認しますか？

関連記事

調べる

選ぶ

サイト