recursive-decomposition

再帰的分解

長い入力は劣化します。詳細を見落とし、離れた箇所同士を推測で結び付け、推論がぶれていきます。RLM 論文ではこれをコンテキストの劣化と呼んでいます。入力全体をコンテキストウィンドウに読み込まないでください。入力を照会する環境として扱い、規模を測り、範囲を絞り、分割し、独立した部分をサブエージェントに渡し、小さなウィンドウで検証して、コードで統合します。Recursive Language Models（Zhang、Kraska、Khattab、2025）に基づいています。

使い方

• /recursive-decomposition：現在のタスクに以下のプロトコルを適用します。
• /recursive-decomposition <path or question>：まずその入力の規模を測り、その後プロトコルを実行します。

適用する場面

適合するかどうかは判断基準ではありません。大規模な作業でも、100 万トークンのウィンドウ内で劣化することがあります。論文では、OOLONG-Pairs は 32k トークンで、GPT-5 の F1 スコアは 0.1％ですが、RLM(depth=1) は 58.0％に達します（arXiv:2512.24601、表 1）。以下の 30k と 50k はハーネスの上限です。

状況	アプローチ
1 つのファイル、1 つの関数、または単一の情報を探す場合	直接読む
線形集計またはすべてを列挙する作業で、網羅性が重要な場合	分解する（このスキル）
散在するソースを横断するペアワイズ、二次的、またはマルチホップの作業	30k トークン未満でも分解する
10 ファイル以上、または 50k トークン以上	分解する
30k トークン未満で、答えが局所的な場合	直接読む

プロトコル

1. 入力の規模を測る：何かを読む前に、ファイル数（glob、find）、行数（wc -l）、バイト数（ls -lh）、PDF のページ数を数えます。
2. 検索で絞り込む：ファイルを開く前に、検索（内容検索、ファイルパターン、キーワード、ファイル形式）で対象範囲を絞ります。ファイル形式、次にキーワード、最後に意味の順にフィルターを連結します。
3. チャンクに分割する：残った対象を、関数、クラス、セクションなどの自然な単位、行範囲、またはキーワードごとに分割します。1 バッチは 5～10 ファイルにします。
4. 深さ 1 で再帰する：独立した各バッチに 1 つのサブエージェントを割り当て、自己完結した指示（ファイル、質問、出力スキーマ）を与えます。並列実行は 1 回のウェーブにします。最初にバッチ数を書き出してください。さらにバッチが残っている場合は、統合後に次のウェーブを実行します。サブエージェントは回答するだけで、サブエージェントを起動してはいけません。
5. 検証する：統合した回答をより小さなウィンドウで検証します。必要最小限の根拠を抜き出して再確認し、意見の相違は対象を絞って読み直して解決します。
6. プログラムで統合する：構造化された結果を集約し、重複を除き、分類してから、ファイルと行の参照を付けて回答を作成します。

ルール

• 入力の規模を測ってから読み始めなければなりません
• ディレクトリを読む前に検索しなければなりません。検索の代わりに再帰的にツリーを一覧表示してはなりません
• 大きなファイルは行範囲を指定して読まなければなりません。2,000 行または 50 KB を超えるファイルを一度に読んではなりません。100 ページまたは 30 MB を超える PDF は、メタデータで確認するか分割しなければなりません
• PDF と Office ファイルは推論の前に Markdown に変換しなければなりません。Firecrawl の convert-documents-to-markdown スキルにあるローカルの anydoc（npx -y @firecrawl/anydoc FILE -o .firecrawl/FILE.md）を優先してください。OCR（--ocr hosted / firecrawl parse）、-Q、または -S にはクラウドの firecrawl parse を使用します。バイナリをコンテキストに出力してはなりません。クラウド解析の上限は 50 MB で、PDF 1 ページあたり約 1 クレジットです。それより大きい場合は先に分割してください
• バッチ計画を文書化せずに、5 ファイルを超えてメインコンテキストに読み込んではなりません
• 各サブエージェントには、ファイル、質問、出力スキーマを含む独自のコンテキストを与えなければなりません
• 再帰の深さは 1 に保たなければなりません。サブエージェントは回答し、サブエージェントを起動してはなりません
• 起動前にバッチ数を書き出さなければなりません。並列実行は 1 回のウェーブにして、その後に統合します。次のウェーブを実行できるのは、その統合の後だけです
• 回答する前に、統合結果をソースと照合してスポットチェックしなければなりません
• 定義を先に読み（grep -n "function"）、本体は後で読むことが望ましいです。全文を読む前に目次と要旨を確認してください
• 同じ内容に対して同じクエリを複数のサブエージェントで実行してはなりません。対象は一度だけ、重複しないバッチに分割してください
• 統合結果が薄く見えても、再帰の深さを増やしてはなりません。意見の相違を読み直してください

ツール、エージェントに依存しない

必要な作業	使用するもの
ファイルを探す	ファイル検索または glob ツール、または find
コンテンツを探す	コンテンツ検索または grep ツール。全体を読み込むのは避ける
サイズを確認する	wc -l、ls -lh、ページ数（利用可能なら pdfinfo）
読み込む	オフセットと上限を指定できるファイルリーダー、または sed -n 'START,ENDp'
PDF または Office ファイル	まず anydoc（npx -y @firecrawl/anydoc FILE -o .firecrawl/out.md）を使い、その後 Markdown を grep します。OCR、-Q、または -S にはクラウドの firecrawl parse を使います。それ以外の場合は pdfinfo と分割を使います。バイナリ全体を読み込むのは避けてください
委任する	サブエージェントまたはタスクツール。バッチごとに簡潔な指示を 1 つ用意します
集約する	一時ファイルまたは構造化したメモを使い、最後に 1 回確認します

ツール名はエージェント（Claude Code、Codex、Cursor、Gemini CLI）によって異なります。各行に対応するエージェントの同等ツールを使ってください。

パターン

コードベースの分析

「すべてのエラー処理パターンを見つけてください。」ソースファイルを glob で探し、catch|throw|Error|except を grep し、該当箇所をモジュールごとに（ファイル 5〜10 個）まとめ、各バッチを固定のレポート形式で 1 つのサブエージェントに割り当て、ファイル参照付きのカテゴリ別要約に統合します。実例：references/codebase-analysis.md。

複数文書の質疑応答

「すべての PRD を通して、どのような機能が計画されていますか？」文書を glob で探してサイズを確認し、抽出スキーマ（名前、優先度、ステータス、四半期）を定め、文書グループごとに 1 つのサブエージェントを割り当て、重複を除いて分類し、3 件をソースと照合して抜き取り確認します。実例：references/document-aggregation.md。

集約

「すべての TODO コメントを要約してください。」TODO|FIXME|HACK を grep し、モジュールごとにまとめ、各グループの文脈と優先度を抽出して、優先順位付きリストを作成します。

大容量の PDF

*.pdf を glob で探し、バイト数とページ数（pdfinfo）を確認します。100 ページまたは 30 MB を超える場合は、取り込まないでください。anydoc を使って .firecrawl/ に変換し（Firecrawl スキル convert-documents-to-markdown）、その後 Markdown を grep してチャンクに分割します。anydoc が 3（スキャンページ）で終了した場合は、--ocr hosted または firecrawl parse（Firecrawl スキル firecrawl-parse、50 MB／ページあたり約 1 クレジット）で再実行します。文書ごとにバッチ処理し、深さは 1 として、タイトルを PDF メタデータと照合して抜き取り確認します。

1 ページの Markdown 変換ジョブはこのスキルの対象ではありません。anydoc または firecrawl parse のみを使って処理してください。

長い出力

出力をセクションに分割し、それぞれを個別に生成して中間結果をファイルに保存し、最後に一貫性を確認しながら結合します。

コストと品質

論文（arXiv:2512.24601、Table 1 および Figure 1）では、RLM（GPT-5、深さ=1）は BrowseComp-Plus（600 万〜1,100 万トークン）で 91.3% を記録し、平均コストは 0.99 ドルでした。一方、圧縮は 70.5% でした。OOLONG では GPT-5 を 28.4% 上回りました。OOLONG-Pairs では、ベースラインが 0.1% のところ、F1 が 58.0% に達しました。Figure 1 では、入力を 2^13 から 2^20 トークンまで拡大しています。中央値のコストはベースモデルと同程度ですが、外れ値となる軌跡では平均コストが上昇することがあります。しきい値：references/cost-analysis.md。

アンチパターン

アンチパターン	対処方法
「文脈を把握するため」に最初にすべてを読む	サイズを確認して絞り込んでから、範囲を指定して読む
PDF のバイナリをウィンドウにそのまま出力する	Markdown に解析してから、grep してチャンクに分割する
単一の手掛かりの検索や 1 ファイルだけの確認を分割する	直接読む
質問やスキーマを与えずにサブエージェントに委任する	自己完結した指示を与える
サブエージェントに別のサブエージェントを起動させる	深さは 1 にする。サブエージェントは回答し、再委任しない
統合した回答を鵜呑みにする	小さな範囲で抜き取り確認する
同じ内容を複数のサブエージェントに再問い合わせする	一度だけ分割し、重複のないバッチにする

参考資料

• references/rlm-strategies.md：論文で紹介されている分解戦略
• references/cost-analysis.md：分解するタイミング、損益分岐点のしきい値
• references/codebase-analysis.md：コードベース全体のエラーハンドリングの具体例
• references/document-aggregation.md：複数の PRD にまたがる機能抽出の具体例
• 論文：再帰的言語モデル、Zhang、Kraska、Khattab、arXiv:2512.24601