• Perch 2.0 という鳥類、哺乳類、両生類、昆虫を含む14,597種で事前学習された教師あり生物音響基盤モデルおよびPerch2.0を利用した生物音響分類手法の提案

• 課題感
• 海洋生物の音響データは収集コストが高いので、データがたくさんある鳥類などの陸上生物で学習した基盤モデルでなんとかしたいよね。

• Perch 2.0
• Xeno-Canto、iNaturalist、Tierstimmenarchiv、FSD50Kといったデータベースから収集された、150万件以上のラベル付き録音データを使用
• モデル構造は EfficientNet-B3
• ラベルを当てる分類タスク（教師あり学習 ）+ 元データの予測による自己教師あり学習で学習

• 推論・評価
• Perch 2.0 に音声データを入力した得られた（windowごとに分割、平均を取る） embedding を利用する。
• クラスごとにk個ずつサンプリングし、分類モデル（ロジスティック回帰）を学習する。
• サンプリングして学習に利用しなかったサンプルで評価する。

• 評価データセット（こんなんあるんですね、面白い。）

• 評価結果
• 黒実線（提案手法）が全体的に強い。特に、海洋生物系のデータセットで強いのが素晴らしい。
• くじら特化の Google multispecies whale model（GMWM） とくじらデータセットの NAAA PIPAN の組み合わせや、サンゴ + 鳥類データで学習した SurfPerch とサンゴデータセットのReefSetの組み合わせなどでいい勝負（しかもこれら特化モデルはリークしている）

• みんだ大好き tSNE で embedding をマッピングしたら、なんかうまく分類できている気がする。

• 考察：なんで少数サンプルクラスもうまいこと分類できる？
• スケーリング即の話。
• 鳥類の音響分類タスクが十分に難しいため、それができるならくじらとかも当てれるようになるのでは？
• 生物学的な観点として、鳥類も海洋哺乳類は全く異なる進化をしてきているが、発声の物理的メカニズムには共通する部分があるのでは？

• Claude Codeの中心的な開発者であるBoris Cherny氏が、インタビューで「コード検索においてRAG（検索拡張生成）の採用をやめ、Agentic Searchを選んだ」と語った

• リアルタイム性の欠如（同期ずれ）: 開発中のコードは絶えず変化するため、ローカルでコードを書いてもインデックスへの反映が遅れ、最新情報が検索できない。

• 権限管理の壁: 誰がどのインデックス（他人のデータなど）にアクセスできるかの制御が非常に困難だった。

• Agentic Searchの正体は、AIエージェント自身にとを使わせるという極めてシンプルな手法です。

• 従来のRAGは「人間は適切な検索キーワードを思いつけない」という前提のもと、システム側でベクトル化して「意味検索」をサポートしていました。

• しかし、現在のLLMエージェントは賢いため、自ら曖昧な意図を具体的なキーワード（例:）に変換し、ディレクトリ構造を読み解きながら、情報が見つかるまで検索を何度も試行錯誤（反復）できます。

• つまり、検索システム（パイプライン）を賢くするのではなく、「エージェント自身の知性」に検索を委ねたのが最大の違いです。

1. 人間の手による構造化: ファイルの命名規則やディレクトリ構成を人間が整理しておくこと。

2. 検索ガイドの整備: プロジェクト内にのようなファイルを用意し、エージェント向けに構造や規約を自然言語で案内すること。

3. エージェントの検索能力: LLMがツールを使いこなす十分な推論能力を持つこと。

• 人間向けの検索システムでは依然としてRAGは有効

• しかし、AIエージェントにコードや文書を探させる場合は、複雑なRAGシステムを構築・維持するよりも、人間がドキュメントを整理してガイドを書き、あとはAgentと単純な検索ツール（grep等）に任せる分業スタイルの方が理にかなっています。

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

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）**ことで、回答を完成させます。

実験

• 従来のSearch-o1は、文書を「平坦で構造のないチャンクの集合」として扱う。このため、情報を断片的にしか捉えられず、本来連続しているはずの文脈が途切れてしまう（「コンテキストの断片化」）問題があった。

• DeepReadのReadSectionツールは、Retrieveツールで特定した座標に基づいて、関連するセクション内の段落を連続的に、かつ正しい順序で読み込むことができる。これにより、人間が自然に行うような「文脈を理解しながら読む」ことが可能になり、情報の断片化が大幅に軽減され、特にContextBenchのような複雑な長文タスクで大きな性能向上に繋がった。

Appendix

• タイトル: 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 — エージェントのトレース・観測・分析プラットフォーム。トレースベースの反復改善サイクルを実現する基盤ツール。