文書構造モデリングと協調的ツール利用

Document Parsing and Index Building (文書解析とインデックス構築)

• DeepReadが想定する現代のOCRは、文字だけでなく、文書の持つ「構造」を正確に抽出します。Sequence (連続性): 段落の並び順やテキストの流れを認識します。

• Hierarchy (階層性)
• 章、節、小見出しといった文書の階層構造。

• Doc Schema (文書スキーマ)
• OCRによって抽出された構造情報は、「Doc Schema」として整理されます。図の左中央にあるツリー構造は、文書の目次（Table of Contents: TOC）のメタデータを示しています。
• 例えば「1. Intro」「2. Method」「2.1 Model」「2.2 Tool」といった階層的な見出しがあり、それぞれの見出しには、その下にどれくらいの段落があるか（paragraphs=Num）、どれくらいのトークン数か（tokens=Num）、そして子ノード（サブセクション）があるか（children=[ID list]）といった情報が付与されています。また、各段落には「Hierarchy ID」や「Paragraph Interval」といった具体的な「座標」が割り当てられます。
• これをプロンプトに入れる。これにより次が可能に
• グローバルなプランニングと初期探索の方向付け
• より絞ったクエリ生成が可能に
• 読解コストの見積もりとツール選択の最適化
• 効率的な局所的文脈の拡大
• 探索履歴の活用と無駄な重複回避

DeepRead Agent & Tool Set (DeepReadエージェントとツールセット)

• ツールを装備した大規模言語モデル
• 質問に対する回答を生成するために、自律的に思考し、適切なツールを選択して使用します。
• Tool (ツール)
• LLMは、人間のように賢く文書を読み解くために、2つの異なる種類のツールを使用します。
• Retrieve (検索):
• 入力: QueryText w/ Hierarchy & Sequence (LLMが生成した検索クエリ)
• 機能: 文書全体の中から、セマンティック（意味的）に最も関連性の高い「情報断片」（通常は段落）を素早く見つけ出し、そのテキストと「座標」を返します。
• Span Window: 図に示されているように、このツールは単一の関連段落だけでなく、その前後の段落（設定されたウィンドウサイズW=(w↑, w↓)の範囲）も一緒に取得します。これは、人間が関連する文を見つけた際に、その周辺の文脈も一緒に目を通す「スキャニング」の動作を模倣しています。
• ReadSection (セクション読み込み):入力
• 機能: 特定の文書の、特定のセクション内にある、指定された範囲の段落を連続的に、かつ正しい順序で読み込み、そのテキストと座標を返します
• 「context fragmentation (コンテキストの断片化)」を軽減する上で非常に重要なツールです。
• Tool Parameters (ツールパラメータ): LLMは、これらのツールを呼び出す際に、適切な引数（検索クエリ、読み込みたい範囲の座標など）を渡します。

処理フロー

• Turn 1 (Retrival): まず、ユーザーの質問に対し、LLMは関連しそうな情報を広範囲に検索（Retrieve）しようとします。

• Turn 2 (Retrival): 最初の検索結果から、さらに別の検索クエリを生成し、情報を絞り込んだり、別の側面を探したりするために、再度検索（Retrieve）を行います。

• Turn 3 (Read): 検索結果から、あるセクションに重要な情報がまとまっていると判断すると、LLMはRetrieveツールで得た座標を元に、そのセクションをじっくりと連続的に読み込む（ReadSection）ツールを呼び出します。これにより、文脈を損なわずにまとまった情報を取得します。

• Turn 4 (Retrival): 読み込み結果から、まだ情報が不足していると判断した場合、あるいは別の情報源が必要な場合、再度検索（Retrieve）に戻ります。

• Turn 5 (Read): 最終的な回答に必要な情報が特定のセクションにあると判断すれば、そのセクションを再度じっくりと読み込む（ReadSection）**ことで、回答を完成させます。

• タイトル: Improving Deep Agents with Harness Engineering

• 著者 / 組織: LangChain Team

• 公開日: 2026年2月17日

• URL: https://blog.langchain.com/improving-deep-agents-with-harness-engineering/

1. どんな記事？

2. 何が課題だったのか？

• エージェントが同じファイルを何度も編集し続ける「ドゥームループ（Doom Loop）」に陥り、トークンと時間を浪費する問題

• 推論トークンを常に最大で使うとタイムアウトが頻発し、逆にスコアが低下する（extra-high固定で 53.9% にとどまる）

• エージェントが実行環境（ディレクトリ構造・利用可能ツール）を自力で探索するコストが大きく、本質的な問題解決に集中できない

• タスク完了前の自己検証が不十分で、誤った回答をそのまま提出してしまう

• 失敗原因の分析が手作業に依存しており、改善サイクルが遅い

3. アーキテクチャ・技術的アプローチ

1. システムプロンプト — タスクの構造化、行動指針の注入

2. ツール — エージェントが利用できる外部機能群

3. ミドルウェア — モデルの入出力に介入する制御レイヤー

4. 設計上のこだわり・工夫

Build & Self-Verify Loop

• 「計画→実装→検証→修正」の4フェーズに構造化

• で、タスク完了前に必ず検証パスを通過させる設計

• テストを「正しさの担保」かつ「エージェントへのフィードバック信号」として活用

Environmental Context Injection

• がディレクトリ構造・利用可能ツールを事前マッピングしてエージェントに注入

• 「プログラム的テストで評価される」ことを明示的に伝達し、行動バイアスを調整

• 時間予算の警告を組み込み、期限内完了を促進

Loop Detection

• がファイルごとの編集回数をツールフックで追跡

• N回超過時にアプローチの再考を促すプロンプトを自動挿入

Reasoning Sandwich 戦略

• 計画・検証フェーズ → extra-high 推論 / 実装フェーズ → high 推論

• フルextra-highでは53.9%（タイムアウト多発）だが、このハイブリッド方式で 63.6〜66.5% を達成

• トークン効率と精度のトレードオフを、フェーズごとの推論予算配分で解決

トレース分析のブースティング的アプローチ

• 機械学習のブースティング（Boosting）に着想を得て、前回の失敗モードに集中して次の改善を行う反復サイクルを構築

5. 現時点の制約と今後の展望

制約

• ハーネスの最適設計はモデルアーキテクチャごとに異なるため、モデル変更時に再チューニングが必要

• ループ検出等のガードレールは現行モデルの制約に対する一時的な対策であり、モデル進化に伴い不要になる可能性

今後の展望

• マルチモデルハーネス — 大型モデルで計画、小型モデルで実装を分担するオーケストレーション

• RLM（Reinforcement Learning from Model outputs） — モデル出力からの強化学習による自律的改善

• メモリシステム — エージェントが過去の経験を蓄積し、継続的に自律改善するアーキテクチャ

6. Take Home Message

1. モデルを変えなくてもハーネス設計で性能は大幅に変わる — 同一モデルで+13.7ptの改善は、プロンプトやツール設計への投資対効果が極めて高いことを示す

2. エージェントに環境を自力探索させるな、事前に与えよ — コンテキスト注入により、エージェントは本質的な問題解決に集中できる

3. トレース分析による反復改善が鍵 — 失敗モードを体系的に分析→対策する「ブースティング的サイクル」が継続的な性能向上を可能にする

4. 推論予算はフェーズごとに最適配分せよ — 常に最大推論では逆効果。計画・検証に厚く、実装に薄く配分する「サンドイッチ戦略」が有効

7. 関連リソース

1. Terminal Bench 2.0 — エージェントコーディングベンチマーク。ML・デバッグ・生物学分野の89タスクで構成。本記事の評価基盤。

2. Deep Agents（LangChain OSS） — 本記事の成果物として公開されたPython/JavaScript実装。ハーネス設計の具体的なリファレンス。

3. LangSmith — エージェントのトレース・観測・分析プラットフォーム。トレースベースの反復改善サイクルを実現する基盤ツール。