---
title: "Deep Research で長時間の調査を実行する"
description: "複数ソースの調査を Background Agent Job に移し、プラグ可能な調査方法で、独立したレビュー後に出典付きのレポートを納品します。"
url: "https://ankole.agentbull.com/ja-JP/docs/deep-research-job/"
lang: "ja-JP"
---

> AI Agent 向けドキュメント索引: https://ankole.agentbull.com/ja-JP/llms.txt

# Deep Research で長時間の調査を実行する

Deep Research は、文献レビュー、競合調査、複数ソースの事実確認、いくつかの説明を比較しなければならない予測、既知の結果に対する以前の予測のレビューに向いています。この種の作業は、繰り返しの検索、読み取り、相互チェックを必要とします。Agent はそれを [Background Agent Job](https://ankole.agentbull.com/ja-JP/docs/background-jobs/index.md) に移し、あなたの他のメッセージを引き続き処理します。

これは、いくつかの Web ページを検索して要約することと同じではありません。Job は独自の耐久性のあるワークスペースで段階的に動きます。計画し、並行して収集して材料をソースノートに書き出し、その証拠から結論を導き、研究プロセスを見られない検証者にレポートを渡し、最後に各成功基準に対してレポートを監査します。本格的な調査は通常 30–90 分かかります。素早い回答だけが必要なら直接尋ねて、Deep Research は使わないでください。

## 始める前に

[Quick start](https://ankole.agentbull.com/ja-JP/docs/quickstart/index.md) を完了し、Agent がchat channelで返信できることを確認してください。Agent が公開 Web ページを検索する必要がある場合は、`web_search` と `web_fetch` の model profile を設定してください。

Job は常に AIGateway を使います。ChatGPT サブスクリプション容量を使うには、[ChatGPT subscription provider](https://ankole.agentbull.com/ja-JP/docs/chatgpt-subscription-provider/index.md) を作成し、**Console → Agents → Background Agent Jobs** で選択してください。

Job は、Agent で有効化され Background Agent Jobs で許可されたすべての Skill を自動的に受け取ります。インスタンスがデータソース Skill（例えば金融データインターフェースや内部システム接続）を有効にしている場合、Job は公開 Web を検索する前にそのデータを使います。Job を別途承認する必要はありません。

## 調査を開始する

対象、時間範囲、証拠規則、出力形式を述べてください。バックグラウンド実行を求めます:

```text
Run this as a Deep Research Background Agent Job.
Compare the pricing and product updates from these three vendors over the last
two quarters. Cite primary sources, separate facts from inference, and return
a report with links. Ask me before you expand the scope or use paid data.
```

### 作成前の明確化

Agent は 1 文から作業を開始しません。Job を作成する前に、未解決の各調査選択についてあなたにインタビューします。目標とその用途、成功基準、スコープと時間境界、証拠規則、納品物です。一度に 1 つの質問をし、推奨する回答を示します。環境が供給できる事実は調べ、本当の決定だけをあなたに持ち込みます。Job はあなたが確認した後にのみ作成されます。

この数分はコストに見合います。誤った調査方向は、次の 60 分の収集と分析を無駄にしますが、1 文で質問を解決できます。

インタビューを望まない場合は、「聞くのをやめて、Job を直接作成して、残りは自分で決めてください」と言ってください。その場合 Agent は、あなたのために行った仮定と Job に委ねる選択を述べ、Job を作成します。

### 良いリクエストが含むもの

定義されたスコープは「深く調査して」より有用です。リクエストが次の項目を述べると、レポートは必要なものに近づきます:

- **対象と答えるべき質問**。トピックだけではありません。「再生可能エネルギー業界を分析して」と「この 3 社のうち、次の 2 四半期に価格を下げる可能性が高いのはどれか、その根拠は」は非常に異なるレポートを生みます。
- **時間範囲と情報のカットオフ**。レビューや以前の判断の再構成では、この項目が、後に利用可能になった情報を Job が使えるかどうかを決定します。
- **証拠規則**: 一次ソースのみ、引用必須、事実と推論の分離。
- **分析方法**（必要なら）。例えば、ACH で競合仮説の比較を求めたり、過去の事例を使う前方視的分析を求めたりできます。名前を指定しないとき、Job は方法を自分で選択します。
- **納品物と言語**。デフォルトは Markdown レポートです。PDF、PPT、Web ページを要求するとき、Job は Markdown ソースも求めない限りその形式だけを提供し、スタイルを指定しないときは Agent の `DESIGN` ビジュアル規則を適用します。
- **境界**: 予算、有料データソース、スコープ拡張、締め切り。

述べられた長さは概算のターゲットです。「3 ページの PDF」は、正確な値を求めない限り約 3 ページを意味します。

## Job の仕組み

Job の内部メソッドの知識は、進捗を読み、結果にふさわしい信頼を判断し、何を尋ねるべきかを知るのに役立ちます。各 Deep Research Job は、独自の耐久性のあるワークスペースで 4 つの段階を進みます。

### 1. 計画

Job は最初にワークスペースで利用可能な Playbook を一覧し、質問に適用される方法を読みます。スコープが広い、対象がまだ明確でない、または関連する事実がモデルの知識の後に変わった可能性があるとき、Job は 1 つのサブ Agent を送って素早い探索を行います。この探索は証拠を収集せず、結論も作りません。対象の現在の意味と境界を確立し、モデルが見落とせる主要概念、調査の次元、検索語、データソースを見つけます。

次に Job は詳細な収集計画を準備します。計画がモデルの記憶にある古いバージョンの世界ではなく現在の事実から始まるように、探索は計画の前に行われます。

### 2. 証拠を収集する

複数のサブ Agent が収集計画を並行して実行します。有用な材料はすべて `sources/` の下の Markdown ノートになり、ファイルの冒頭の YAML に、出典、公開時刻、作者、信頼度、リンクが入ります。その後のすべての分析は、1 回の検索の一時的な印象ではなく、これらのノートを引用します。

収集は 1 つの所有権規則に従います: 各データソースと各一次ドキュメントには 1 つのオーナーがいます。オーナーはそれを 1 回収集し、結果をファイルに書きます。他のサブ Agent はそのファイルを読み、リクエストを繰り返しません。Job は 1 つの発表、ファイリング、データセットを 1 回だけダウンロードし、後のサブ Agent が見つけられるように識別子でファイル名を付けます。ツールがリストを受け入れるとき、Job は 1 回の呼び出しでバッチ全体を要求します。

有効な Skill からのデータは、公開 Web 検索より前に来ます。Job は最初に Skill ドキュメントを読み、Skill が供給しないもの、または Skill 呼び出しがデータの不在を示した後のものにのみ `web_search` や `web_fetch` を使います。データインターフェースから得るべきデータを置き換えるために公開 Web サイトを読みません。Skill が供給できないものは、`sources/` の記録された証拠ギャップになり、暗黙の省略にはなりません。

すべての情報が検索から来るわけではありません。必要に応じて、Job は上流の生データを処理するスクリプトを書き、構造化データから必要な値を導出します。最初の整理の後、Job は情報がまだ欠けていないか、一部の情報が衝突していないか、後の分析が必要とするコンテキストが完全かどうかを調べます。必要に応じてさらに収集します。

### 3. 分析と検証

結論は、利用可能な情報からステップバイステップで続き、論理の閉じた連鎖を形成しなければなりません。Job は最初に判断を選んでから支持を探しません。レポートは事実、意見、仮説、推論を分けます。現在の証拠が複数の解釈を許すとき、Job はすべてを列挙し、どれを好むかを述べ、信頼度を与えます。ニュースやマーケティングの主張には健全な懐疑心を保ち、執筆中に確証バイアス、サンプリングバイアス、物語の誤謬に対して働きかけます。

その後、独立した検証者が分析をレビューします。この検証者は会話ターンを継承せず、Job のプライベートな作業状態も受け取りません。レポートとあなたの調査目的だけを受け取ります。形式と実質の両方をレビューします。形式では、レポートが事実、意見、仮説を分けているか、十分な引用を与えているか、実質的な情報価値のある結論を与えているかを確認します。実質では、レポートを敵対的にレビューします。論理が内部で一貫しているか、他の説明が可能か、レポートが因果を逆転させていないか、矢を射た後に標的を設定していないか。

検証者は助言し、最終判断を所有しません。各実質的な不一致は、影響を受ける分析とレポートを変更するか、その理由とともにレポート内で見えるままにします。不一致は見かけの一致に平らにされません。

### 4. 納品

納品は基準監査から始まります: レポートはすべての成功基準に説明しなければなりません。引用付きの証拠で基準を満たすか、結論への影響とともに公開ギャップとして基準を述べます。ギャップが調査目的を妨げ、時間が許す場合、Job はまだ到達できる追加の証拠を収集します。遅れたレポートは、不完全なレポートと同じくらい確実に目的を失敗させます。

次に Job は、要求された形式で納品物を生成し、1 つのサブ Agent に軽い最終チェックを渡します。レポートはあなたの言語を使い、ジョージ・オーウェルの 6 つの執筆規則に従い、免責事項を追加しません。

### 作業状態、回復、再起動

Job はプライベートな作業状態をワークスペースの `research-state.md` に保持します: 各成功基準とその現在のステータス、支持に開いたギャップを持つ候補結論、理由付きの拒否された方向、収集された情報の妥当性についての未解決の懸念。このファイルは作業 memory であり、納品物ではありません。独立レビューが自身の見解を形成し、研究者の推論に従わないように、どの検証者もこれを受け取りません。

このファイルは進捗を生き残らせます。Worker の中断やコンテキストの喪失後、Job はこのファイルから続き、既に確定したものを再探索しません。

調査中に Job がフレームが間違っていることを見つけたとき（対象の誤認、質問の読み間違い、コア仮定の破損）、分析にパッチを当てません。修正されたフレームを `research-state.md` に記録し、間違ったフレームが無効化する分析を破棄し、影響を受ける段階をやり直します。収集した `sources/` は保持し、修正されたフレームが不十分にするものだけを再収集します。誤ったフレームに基づくレポートは Job 全体を無駄にするため、再起動は見た目より安いです。

## Playbook: プラグ可能な調査方法

Playbook は、Job ワークスペースの `playbooks/` ディレクトリにあるメソッドファイルで、deep-research Agent Plugin のワークスペーステンプレートとともに配布されます。各 Playbook は、冒頭で適用時期を宣言します。計画中、Job はすべての Playbook を一覧し、関連するものを読みます。

Playbook は追加の助言以上のものです。デフォルトの分析、検証、レポート順序を独自のプロトコルで置き換えられます。ACH がデフォルトの単一パスレビューとしているのと同様です。したがって方法論は置き換え可能で拡張可能です: 調査方法はファイルであり、モデルやコードに固定されていません。

2 つの一般的な方法が組み込まれています。

### ach: 競合仮説の分析 (Analysis of Competing Hypotheses)

情報が不完全、矛盾、または欺瞞の可能性があるとき、重要な予測や診断はいくつかの合理的な説明を比較しなければなりません。ACH はその比較を明示にし、判断を監査可能にします。悪い証拠を改善せず、あなたの代わりに答えを計算もしません。

意味のある答えが 1 つしかない事実照会は ACH を必要としません。信頼できるデータと適切な統計的または因果モデルが質問に答えられるときは、そのモデルを使って、ACH を代替として扱わないでください。

**仮説は証拠より前に来る。** Job は最初に正確な質問、情報のカットオフ、予測の場合はホライズンと結果の定義を述べます。次に、証拠を評価する前にすべての合理的な仮説を生成します。この順序は、最初の妥当な説明が分析全体を定義するのを防ぎます。各仮説は同じ質問に同じレベルで同じ期間に答え、Job は仮説が相互排他的か、合理的な可能性をカバーしているかを述べます。必須の仮説数はありません: 比較が改訂理由を与えるまで仮説は残ります。なぜなら支持の欠如は反証ではないからです。

**証拠はツールがチェックできる行列に入る。** Job は、仮説横断比較を所有する 1 つの `competing-hypotheses.yaml` ファイルを保持します。各行は、すべての仮説に対して評価できる 1 つの命題です: 観察、報告された主張、期待されたが存在しないシグナル、分析的仮定、論理的議論、またはベースレート。各行は、実際のタイプ、ソースパスまたは分析的根拠、ソースの資格を記録します。「疑惑」と言うソースは、それを事実として確立しません。次に Job は構造チェックを実行します:

```bash
bun tools/ach_check.ts
```

チェッカーは構造的な省略と、安全でないまたは欠落したローカルソースパスのみを見つけます。仮説が妥当か、命題が真か、ソースがそれを支持するか、関係が正しいかを判断しません。ツールは機械がチェックできるものを所有し、判断はモデルとあなたに残ります。

**比較は支持の量ではなく判別力を使う。** 各行について、Job は仮説が真ならばこの情報がどれだけ期待されるかを尋ね、情報が仮説を証明するかではありません。関係は 6 つだけ使います — expected、compatible、tension、contradicts、unknown、not applicable — それぞれ短い理由付きです。判別力が 1 行内の違いから来るため、仮説を下に読む前に、行を横に読みます。すべての仮説と互換性のある情報は重要ですが、区別にはほとんど役立ちません。

**依存と channel カバレッジ。** コピーされたレポートは 1 つの情報起源です。1 つのイベントが生み出す複数の指標、または 1 つのデータセットから導出された複数の結果も、独立した支持ではありません。相関する行は有用な詳細を保てますが、独立した支持を作れません。channel カバレッジは見落としやすいです: 異なる仮説は異なる channel に現れ、ある仮説の証拠が誰も検索しなかった channel にある場合、比較は世界ではなくあなたの検索カバレッジを測定します。そのため各仮説は現れる channel を名指し、Job はその channel から収集するかカバレッジギャップを記録します。

**欠落シグナルとリンチピン。** 欠落は、期待されたシグナルが観察可能で、検索が合理的に見つけられたときのみ否定的証拠になります。Job はまた、結果を駆動する少数のリンチピンアイテムと仮定を特定し、それぞれをテストします: そのアイテムが偽、誤解を招く、不完全、別のアイテムに依存、または意図的に欺くために作られた場合、判断はどう変わるか。判断全体への信頼は、仮説カバレッジ、証拠品質、依存、感度に依存し、収集された材料の量には依存しません。

**漸進的開示による 3 パス検証。** ACH はデフォルトレビューを独自のプロトコルで置き換えます。同じ検証者が 3 回通過し、順序が保護です:

1. **パス A: ソースからの独立した再構成。** 検証者は、あなたの調査目的、正確な ACH 質問、情報のカットオフ、`sources/` へのアクセスのみを受け取ります。行列、レポート、研究者が好む仮説、研究者の推論を見ません。妥当な仮説、最も判別力のある情報、各アイテムの各仮説への関係、リンチピンを特定し、自身の暫定的評価を記録します。欠落シグナル、隠れた仮定、ソース依存、カットオフ漏れ、可能な欺瞞、代替案を分離する次の観察も特定します。
2. **パス B: 行列との比較。** 検証者が自身の再構成を記録した後にのみ `competing-hypotheses.yaml` を受け取ります。2 つの分析を比較し、ソースに裏付けられた主張をノートに追跡し、各リンチピンと争いのある行の元の材料を検査し、理由付きの具体的な欠陥を報告します。
3. **パス C: レポートのレビュー。** すべてのパス B の不一致が処理された後、レポートは行列から書かれ、同じ検証者に渡されます。レポートが相対的評価、判別情報、反証、未解決の問題、信頼の根拠と限界を忠実に提示しているかを確認します。

再構成を保護するのは順序であり、別の検証者ではありません: 行列は、検証者が自身の再構成を記録した後にのみ開示されます。結論を先に見る検証者はそれをアンカーにします。

**行列は確率にならない。** 定性的な行列は事後確率を作りません。ラベルは尤度ではなく、行数は確率ではありません。レポートが数字を与えるとき、明示的に主観的な推定と計算されたベイズ結果を区別し、ベイズ計算は可能性の一貫した分割、または明示的な結合モデル、事前、条件付き尤度、証拠依存の扱いを必要とします。

**証拠不十分は所見ですが出口ではありません。** それは最も弁護しやすい判断なので、利用可能な証拠が決定できた分析を吸収できます。比較が仮説を分離できないとき、レポートはそれがあなたにとって何を意味するか、拒否された仮説が真なら何が失われるか、どの観察が分離するかを述べます。さらなる研究は、追加できる情報量ではなく、仮説を分離する力で選ばれます。

### analogical-foresight: 前方視的分析のための歴史的ケース

歴史的ケースは、前方視的分析にメカニズム、変数、テストを供給できます。類比分析の単位は転移主張です:

```text
supported source-case mechanism -> specific target mapping
  -> conditions required for transfer -> target-side observation
```

履歴は、この連鎖が完全なときのみ証拠になります。表面的な類似性と説得力のある歴史物語は、同じメカニズムが対象で動くことを確立しません。

**ケースを名指す前に対象をフレームする。** Job は対象の質問、情報のカットオフ、ホライズン、現在の段階を述べ、十分な対象情報を収集し、歴史的ケースを名指す前に対象構造をスケッチします: 今までの観察された前提条件、イベントシーケンス、制約、結果。各推論の証拠付きの推論された因果関係。分析を変えうる未知の要因と説明されていない段階。逆の順序では、鮮やかなケースがあなたのために問題を定義します。再構成された予測では、後の対象イベントはケースを選択し、対象構造を定義し、マッピングを判断できません。

**因果ギャップから候補を生成する。** 候補ケースは、対象フレームの不確実な関係、欠落要因、説明されていない段階から来ます。Job は異なるアクター、期間、ドメインにまたがって同じ有向関係、因果ダイナミクス、または機能制約を検索し、最初の馴染みのあるケースが検索を終わらせないように、評価の前に候補を生成します。候補プールが 1 つの馴染みのあるドメイン内に留まるか、1 つの歴史物語を繰り返すとき、Job は対象フレームだけを見るコンテキスト分離サブ Agent に、クロスドメインケース、失敗ケース、逆の結果のケースを提案させられます。そのサブ Agent は候補を生成し、対象を判断しません。

**ソースケースのメカニズムを最初に確立する。** イベントシーケンスはまだ因果説明ではありません。Job は保持された各ケースの事実を検証し、主張されたメカニズムを支持する証拠を特定し、共通原因、代替メカニズム、偶然、選択効果、または後付けの物語が同じシーケンスを説明できるかを確認します。同じエピソードのエイリアス、サブイベント、スーパーセット、または別の説明は、独立した支持を与えられません。逆の関係、失敗した転移、異なる段階、壊れた境界条件を持つケースは、反例またはメカニズムの限界の証拠として有用なままです。

**各転移主張を監査する。** 答えに影響しうるすべての類比由来の主張は、6 つの部分を一緒に保ちます: その証拠付きのソースメカニズム。マッピングされる具体的な対象関係。前提条件、役割、方向、タイミング、規模、スコープ、インセンティブの実質的な違い。転移仮定。共有ソース、ネストされたイベント、共通ショック、政策コピー、共通制度、共通測定などの依存関係。転移を支持または弱めうる対象側の観察。アクターの行動には、そのアクター自身の目標、制約、インセンティブ、情報、決定プロセスを使います。同じ立場でのあなた自身の期待される行動は、そのアクターについての証拠ではありません。保持されたケースは、少なくとも 1 つの候補メカニズム、欠落変数、条件付きパス、対象側指標、反例、または境界条件に貢献しなければなりません。歴史物語だけに貢献するケースは削除されます。

**ケースを結合する前に依存を確認する。** いくつかの独立して有益なケースは、1 つの歴史物語への依存を減らせますが、メカニズムが対象で動くことをまだ示しません。Job は、見かけの繰り返しが同じエピソード、制度、ソース物語、ショック、伝播経路、政策拡散、または測定方法から来るかを調べます。正のパターンが重要などき、提案された要因が存在したが結果がなかったケース、または結果が別のメカニズムを通じて起きたケースも探します。意図的に選ばれた類比セットは参照クラスではないため、そのケース数はベースレート、確率、または信頼レベルではありません。

**「弁護可能な類比がない」は許可された結論です。** 分析は、答えに影響するすべての類比由来の主張が、そのメカニズムと実質的な代替説明と区別する証拠を特定するときのみ完了します。方向、段階、スコープ付きで対象にマッピングされた具体的な関係。実質的な違い、依存関係、転移条件。それを支持または弱めうる対象側の観察。発見されたすべての反例と失敗したマッピングは説明されます。候補が転移連鎖を満たせない場合、正しい結論は弁護可能な類比が見つからなかったことであり、レポートに留まる説得力のあるケースではありません。

### 2 つの方法は連携する

それらは異なる問題を解決し、1 つの調査タスク内で接続できます。類比は ACH 仮説を提案したり、求めるべき証拠を特定したりでき、ACH はその後その仮説間の判別比較を行います。歴史的ケースは対象の直接観察ではありません。明示的で弁護可能な転移主張を通じてのみ対象主張を支持します。

### ドメイン用の Playbook を追加する

プライベートデプロイは、ワークスペーステンプレートに独自のメソッドファイルを追加できます。例えば、内部デューデリジェンス手順、業界データソースカタログ、ある種の決定のレビュー基準などです。ファイルは `name` と `description` フィールドで発見可能になります。新しい Job は計画中に自動的にそれらを見て、質問が関連するときに読みます。モデルやコードを変更する必要はありません。

## Job の実行中

Agent が Job を作成した後、現在のチャットは利用可能なままです。Agent と話し続けられ、**Console → Background Agent Jobs** を開いて計画、進捗、モデル使用、現在のステータスを確認できます。

Job が決定を必要とするときは、元の会話で尋ねます。続けられるようにそこに返信してください。`waiting_on_user` は Job があなたの回答を必要としていることを意味します。失敗ではありません。元の会話でいつでも材料を追加したり要件を修正したりできます。メイン Agent がそれらを Job に転送します。

## 結果を読む

Job が完了すると、メイン Agent は結果を提供する前にレポートを読みます。レポートが調査目的を害するギャップや制限を述べるとき、Agent はそれを伝えます。欠けている部分が Agent が保持する情報またはあなたからの決定であるとき、目的に役立たないレポートを転送する代わりに、それを Job に供給して Job を続けさせます。

レポートでこれらの点を調べてください: ソースが結論を支持するか、時間範囲が正しいか、事実が推論から分離されているか、レポートがギャップと信頼度を正直に述べているか。レポートは自己完結でなければなりません。他のファイルなしで結論、証拠、限界、不確実性を理解できるように。1 つの証拠を調べるには、Agent に Job ワークスペースから関連するソースノートを読むよう依頼してください。ACH 分析の後、仮説行列の 1 行の理由を尋ねることもできます。

さらなる作業が必要なら、全体の背景を再説明せずに Agent に同じ Job を続けさせてください。Job が失敗したまま、またはキューに留まっている場合は、詳細を開いてステータスかエラーを読みます。ステータスの意味、キャンセル、ランタイム設定については [Background Agent Jobs](https://ankole.agentbull.com/ja-JP/docs/background-jobs/index.md) を参照してください。

## 参考文献と Ankole の違い

Ankole Deep Research の設計は以下の公開研究と一致し、その研究からもアイデアを得ました。各論文は、独自のベンチマークでの最先端の結果を報告します。私たちの問いは異なります: これらの原則がプライベートなエンタープライズデプロイ内でどう成立するかです。

- Chen, Y., Chen, G., Sun, Y., & Zhang, K. (2026). <a href="https://arxiv.org/abs/2607.13602" target="_blank" rel="noreferrer">Analogical Deep Research: Retrieving and Integrating Historical Analogies for Foresight Analysis</a>. arXiv:2607.13602.
- Zhu, C., Xu, B., Du, M., Wang, S., Wang, X., Mao, Z., & Zhang, Y. (2026). <a href="https://arxiv.org/abs/2602.01566" target="_blank" rel="noreferrer">FS-Researcher: Test-Time Scaling for Long-Horizon Research Tasks with File-System-Based Agents</a>. arXiv:2602.01566.
- MiroMind Team. (2026). <a href="https://arxiv.org/abs/2603.15726" target="_blank" rel="noreferrer">MiroThinker-1.7 & H1: Towards Heavy-Duty Research Agents via Verification</a>. arXiv:2603.15726.

**方法はファイルであり、モデルトレーニングではありません。** CANA は agentic framework です。MiroThinker は agentic な中間トレーニング段階で各ステップの信頼性を改善し、モデル自身の推論プロセスに検証を組み込みます。どちらもモデルに付属します。私たちは調査方法をワークスペースの Playbook ファイルに書き、Job は計画中にそれを読み、Playbook はデフォルトのレビュープロトコルを置き換えられます。コストは、実行品質がモデルが指示にどれだけ従うかに依存することです。利点は、モデルの変更に再トレーニングが不要で、プライベートデプロイが自ドメインの方法を追加・削除できることです。これはエンタープライズ調査の通常のケースであり、本当の違いは業界方法と内部データソースにあり、一般的な能力にはありません。

**独立性は自己監査ではなく情報管理から来ます。** MiroThinker は推論中に自身の推論軌跡を監査します。私たちの検証者は会話ターンを継承せず、`research-state.md` も受け取らず、ACH の下では最初に `sources/` だけから比較を再構成しなければなりません。その後にのみ行列を見て、最後にレポートを見ます。理由は直接的です: 自分の軌跡の監査は、それを生み出した同じ事前分布を持ち、結論を先に見る検証者はそれをアンカーにします。

**永続性はコンテキストウィンドウの外だけでなく、Job ライフサイクルにあります。** FS-Researcher はファイルシステムを使ってコンテキストウィンドウを超えて作業し、私たちのソースノートとワークスペースはこれに完全に同意します。違いは、私たちのワークスペースが、リース、回復、後のメッセージ、あなたの回答への待機状態を持つ Background Agent Job に属することです。Job は Worker が停止した後も続き、コンテキストがあふれた後だけではありません。また、固定のライブラリアン・ライター分割も使いません。執筆は完全な分析連鎖を必要とし、硬い分割はレポートをノートの言い直しにします。収集側では、各データソースに 1 つのオーナーという所有権規則を使い、分離は検証者にのみ強制します。

**類比は反証可能な転移連鎖を与えなければならない。** ADR は、モデルが根本のメカニズムではなく表面特性で類比を見つけることを示し、メカニズムの整列とクロス類比確認を提案します。私たちは同意し、analogical-foresight Playbook はこれを完全でなければならない転移連鎖に変えます。2 つの要件を追加します。依存関係はケースを結合する前にチェックされます。1 つのショック、1 つのソース物語、または 1 つの測定方法から来る繰り返しは確認のように見え、そうではないからです。そしてすべての転移主張は対象側の観察を与えなければなりません。類比がレポートで説得力があるように聞こえるだけでなく、後で間違いだと証明されうるように。

**終点はあなたが確認した目的であり、ベンチマークスコアではありません。** 論文はベンチマークに対して最適化します。私たちは、1 人の人がこのレポートで何をするかに対して最適化します: 成功基準は作成前に明確化され、納品前に 1 つずつ監査され、各ギャップは結果を述べます。ギャップが目的を妨げるとき、メイン Agent はできるものを供給し、Job を続けさせます。収集も同じ規則に従います。有効な Skill データソースが公開検索より前になり、Skill が満たせないギャップは証拠ギャップとして記録されるからです。使用可能なエンタープライズレポートは、権威のあるデータを使ったか、できなかったことを正直に述べたかに依存し、どちらも一般的なベンチマークのスコアシートには現れません。

ワークスペースの Playbook、検証プロトコル、調査状態ファイル、納品監査は、AgentBull Ankole チームによって設計・実装されています。
