MINARA

ディープリサーチパイプライン

構造化されたマーケットレポートを生成する、独立した6ステップのパイプライン

ディープリサーチ (Deep Research) は、メインのエージェントループと並行して動作する専用パイプラインです。エージェントループが会話形式でパーミッションゲートを通過するのに対し、ディープリサーチパイプラインは単一の構造化レポートを生成する6ステップのステートマシンです。 実装は apps/agent/src/deep-research/pipeline.ts にあります。

なぜエージェントループで反復させず、専用パイプラインにするのか? マルチソースのリサーチには並列データ収集(ファンアウトしてマージ)、LLM-as-judge による品質チェック、そして plan → call → observe という会話的なリズムに合わないリトライロジックが必要です。専用パイプラインにすることで、リサーチ出力を決定論的かつ引用可能な形に保てます。会話型ループではこれを保証できません。

実際の使用例: 機能 → ディープリサーチ では、レポート出力例を交えてユーザー向けの側面を解説しています。

いつ使うか

チャットの返答ではなく、書き物のアーティファクトが目的のときにパイプラインを使います。

  • 特定の資産やテーマについての長文マーケット分析。
  • 各主張を引用付きで示す必要があるマルチソース統合。
  • 後から id で参照できるアーティファクトを残したい、定期実行のリサーチ。

「BTC の価格は?」「ここでロングすべき?」といった素早い会話形式の質問には、エージェントループを使ってください。ディープリサーチパイプラインはレイテンシが高く、ツール使用量の上限が固定されており、進行中の会話のメモリも持ちません。

6つのステップ

deep-research diagram

各ステップは単一の LLM 呼び出しです。ただし collectData だけは例外で、ゴールごとにツールレジストリに対してサブエージェントループを実行します。

メインエージェントループからの分離

パイプラインは意図的に分離されています。

  • チャットの会話履歴を参照しません。
  • スキルシステムのアクティベーション状態を消費しません。
  • 現在アクティブなスキルを使用せず、データ収集専用の限定的なツールサブセットを構築します。
  • ラーニングを発生させません(パイプラインのターンで review-engine は動作しません)。

この分離によって、決定論性(リサーチ実行は毎回同じ状態から開始する)とコスト管理(長いチャットセッションの履歴がリサーチコストに混入しない)という2つのメリットが得られます。

モード

interface ResearchRequest {
  chatId: string;
  userMessage: string;
  mode?: "light" | "heavy";
  language?: string;
}
  • light(デフォルト)。並列コレクションゴールは2つ、最大イテレーション数は小さく設定され、シングルパスでレポートを生成します。典型的なレイテンシは30〜60秒です。
  • heavy。並列コレクションゴールは4つ、イテレーション予算が大きく、より徹底した統合を行います。典型的なレイテンシは2〜5分です。

定期実行やクロンによるリサーチには light を、ユーザーが詳細なレポートを明示的に要求した場合は heavy を選んでください。

シナリオ

レポートはシナリオを中心に構成されます。シナリオとは「ブルケース」「ベアケース」「ベースケース」「規制リスク」「マクロ背景」といった事前定義された切り口です。metaPlan ステップは、トピックに応じて apps/agent/src/deep-research/scenarios.ts のカタログから1〜4つを選択します。

シナリオ選択はレポートの品質に直結します。「マクロ」シナリオのない BTC リサーチレポートは最も重要なコンテキストを欠くことが多く、「ベアケース」のないレポートは確証バイアスを生みます。LLM のシナリオピッカーの信頼性を保つため、カタログは意図的に小さく保たれています。

出力アーティファクト

結果は ArtifactStorereport アーティファクトとして保存されます。

interface ResearchResult {
  report_id: string;
  status: "completed" | "error" | "waiting_for_input";
  title: string | null;
  research_topic: string | null;
  scenarios: string[];
  summary: string | null;
  key_findings: string[];
  report_markdown: string | null;
  error?: string;
  tokens: { input: number; output: number };
}

メイン Agent は report://{id} URI スキームを使って、完成したレポートをユーザーに引用できます。これがリサーチと会話を組み合わせる方法です。ユーザーがリサーチを依頼して report_id を受け取り、そのレポートを参照するフォローアップ質問をチャットで続けられます。

レポート本文はマークダウン形式です。シナリオのヘッダー、インライン引用([text](url) 形式)、および要約ステップが生成する「Key Findings」の箇条書きリストが含まれます。

実行方法

REPL から

メイン Agent が deep-research ドメインスキルをアクティベートし、deep_research_run ツールを呼び出します。

> write me a report on ETH staking yields this quarter
assistant: [activates deep-research skill]
assistant: [calls deep_research_run with mode=heavy]
assistant: ✓ report_id: r_abc123、サマリーはこちらです…

CLI サブコマンドから

REPL を完全にバイパスできます。

minara research "BTC ETF flows this quarter"
minara research "macro risks for Solana" --mode heavy

フラグの全一覧は サブコマンド → minara research を参照してください。

HTTP リクエストから

curl -X POST http://localhost:8080/research \
  -H 'content-type: application/json' \
  -d '{"topic": "BTC ETF flows", "mode": "light"}'

リクエストとレスポンスのスキーマについては API → /research を参照してください。

コストとオブザーバビリティ

各ステップは {provider, model, tokens}source: "deep-research" として監査ログに記録します。ResearchResulttokens フィールドは、簡易的なコスト計算のためのベストエフォートの集計値です。正確なコスト帰属が必要な場合は、監査ログをクエリしてください。

SELECT model, SUM(input_tokens), SUM(output_tokens), COUNT(*)
  FROM audit
 WHERE source = 'deep-research'
   AND trace_id = ?
 GROUP BY model;

ディープリサーチパイプラインは、ほとんどの Minara デプロイにおいて最大の LLM コスト要因です。請求額が予想外に高い場合、まずこのクエリを実行することをお勧めします。

パイプラインの拡張

パイプラインは意図的にコンパクト(pipeline.ts 内で約700行)に保たれています。よくある拡張方法を以下に示します。

  • シナリオを追加する: scenarios.ts のカタログに追記します。メタプランのプロンプトはランタイムにカタログを読み込むため、プロンプトの変更は不要です。
  • コレクションの並列数を変える: PipelineConfigcollectConcurrency を設定します。デフォルトは 4 で、v1 の上限に合わせています。
  • ゴールごとの最大イテレーション数を変える: collectMaxIterations を設定します。デフォルトは 8 です。これはデータ収集サブエージェントごとの LLM ターン予算です。
  • 後処理ステップを追加する: パイプラインクラスに別のメソッドを追加し、summarize とリターンの間で呼び出します。既存のステップにロジックをインラインで追加しないでください。ステップの境界こそがパイプラインをデバッグ可能にしているものです。

パイプラインをメインエージェントループの履歴に接続しないでください。分離はフィーチャーであり、これを破るとチャットのコストがリサーチコストに漏れ込みます。

リサーチに含めるべきでないもの

  • リアルタイムの価格に依存する意思決定。 パイプラインは数分かかり、その間に価格は動きます。現在の執行条件に依存するものはエージェントループを使ってください。
  • 資金移動ツールの呼び出し。 データ収集は資金移動ツールをすべて除外した限定的なツールサブセットを使用します。ツールサブセットに誤って資金移動ツールが含まれていた場合、パイプラインは実行を拒否します。
  • ユーザーのプライベートなコンテキスト。 パイプラインはユーザーのウォレット残高や履歴を読み取りません。公開されているマーケットデータのみを参照します。レポートにユーザー固有のポジションを反映させたい場合は、bootstrap 時にユーザーメッセージにポジションを含めてください。パイプラインはそれを後続のステップに引き継ぎます。

目次