DeerFlow 2.0：ByteDanceのオープンソース「スーパーエージェント・ハーネス」、サブエージェント・記憶・サンドボックスを1つのランタイムに

DeerFlowはDeep Exploration and Efficient Research Flowの略で、もともとはByteDanceが公開した深層調査フレームワークだった。READMEはその後の変化を説明している。コミュニティがデータパイプライン、スライド生成、ダッシュボード、コンテンツ自動化などに使い始めたが、これはチームが想定していなかった使い方だった。そこでDeerFlowは単なる調査ツールではなく、エージェントが実際に仕事をするための基盤を与えるハーネス（実行基盤）だと認識し、ゼロから作り直した。2.0は1.xとコードを共有せず、従来の深層調査フレームワークは1.xブランチに残り、活発な開発は2.0へ移っている。READMEは、2.0の公開後、2026年2月28日にGitHub Trendingで1位になったとも書いている。2026年10月13日時点で、リポジトリは約83,766スター、11,654フォーク、MITライセンス、Python製、作成は2025年5月7日、最新の更新は10月13日だ。

READMEの定義では、DeerFlow 2.0は自分で組み合わせるフレームワークではなく、すぐ使えて完全に拡張できるスーパーエージェント・ハーネスだ。LangGraphとLangChainの上に作られ、ファイルシステム、記憶、スキル、サンドボックスを意識した実行、複雑な多段階タスクのために計画してサブエージェントを生み出す能力を備える。モデル非依存で、OpenAI互換APIを実装するLLMなら動く。ただし長いコンテキスト（10万トークン以上）、推論、マルチモーダル入力、強いツール利用を備えたモデルで最も力を発揮するとされ、READMEはDoubao-Seed-2.0-Code、DeepSeek v3.2、Kimi 2.5での実行を強く推奨している。検索とクロールでは、ByteDanceのBytePlusが自社開発したInfoQuestを統合し、無料のオンライン体験もある。

中核機能はいくつかに分けられる。スキルとツール。ワークスペースのサイドバーにある「Capability Center」でプラグイン（MCPサーバーとLark/Feishu連携）とスキルを管理し、組み込みスキルとユーザー作成・インポートのスキルは別に並び、Communityタブでは.skillアーカイブを取り込める。サブエージェント。各サブエージェントは既定で独立したコンテキストで動き、メインや他のサブエージェントの中身は見えないため、目の前のタスクに集中できる。task呼び出しはisolated（既定）とsnapshotを受け付け、snapshotは親が保持する会話と圧縮要約を履歴として渡すが、入力トークンが増える。コンテキストエンジニアリング。セッション内で完了したサブタスクを要約し、中間結果をファイルシステムに退避し、もう要らない内容を圧縮するので、長い多段階タスクでもウィンドウが溢れない。ツール出力にもプレビュー予算と構造化された要約がある。長期記憶はDeerMemという部品が担い、会話、ユーザー、エージェントごとにデバウンスし、既定の静止時間は30秒、最大待機は300秒だ。ほかに、セッション目標、手動のコンテキスト圧縮、チャットアーカイブ、ドキュメント棚付きのプロジェクト、予約タスク（cronの実行時刻のプレビュー、ライフサイクルと安全上限つき）、組み込みのPythonクライアント、端末ワークベンチがある。

実行方法の説明は細かい。クイックスタートでは先にモデルを設定し、Docker（推奨）かローカル開発を選び、デバッグにはLangGraph Studioを使える。既存チェックアウトの更新、複数プロバイダー、既存の実行に対するストリーム操作、個人アクセストークンにも専用の節がある。サンドボックスの節は特に読む価値がある。AIOサンドボックスは、暗黙のシェルの結果が不確かなときやセッション作成の後に再利用されず回収され、回収の前にゲートウェイはコンテナIDまたはPod UIDを隔離ディレクトリに記録する。この記録は停止の失敗やゲートウェイの再起動後も残る。古い記録を消すのは、バックエンドが残存コンテナやPodがないと確認した後だけで、削除の受理応答やヘルスチェックの失敗は十分な証拠とはみなされない。こうした失敗経路の保守的な扱いは、長時間の無人運用を想定して書かれたことを示している。

最初に読むべきはセキュリティの章だ。READMEは、DeerFlowがシステムコマンドの実行、リソース操作、業務ロジックの呼び出しといった高権限の能力を持ち、既定ではローカルの信頼できる環境、つまり127.0.0.1のループバックからのみ到達できる環境への配備を想定していると述べる。LANやパブリッククラウドなど複数端末から到達できる環境で厳格な対策なしに置くと、無許可の呼び出し、インターネットのスキャナーに見つかって高リスク操作が一括で起動される事態、コンプライアンス上・法的なリスクが生じる。Dockerスタックは入口ポートを127.0.0.1にだけ公開し、ローカルのmake devとmake startもループバックにだけ束縛する。他のマシンから使うには.envでBIND_HOSTを設定するが、その前に対策が必要だ。iptablesやハードウェアファイアウォールでIP許可リストを作り、nginxなどのリバースプロキシで強い事前認証を有効にし、エージェントと信頼できる端末を専用VLANに置く。新しいインスタンスにはアカウントがないため、ループバック限定でない配備では、起動直後に/setupで管理者アカウントを作る。READMEはさらに、ゲートウェイ管理者がstdio MCPサーバーを登録でき、それがゲートウェイコンテナ内でコマンドを実行すると明記する。APIは許可リスト（既定ではnpxとuvx）に限り、任意のコードを評価しうる引数を拒否するが、これは多層防御であって境界ではない。ゲートウェイ管理者はホスト上のコード実行と同等の権限として扱うべきだ。

私たちの見方では、DeerFlow 2.0で学ぶ価値があるのはスター数ではなく、その工学上の取捨だ。サブエージェントの隔離、コンテキストの要約、ファイルシステムへの退避、サンドボックスの回収など、通常は内部に隠れる細部が文書化されており、エージェント基盤を自作する人には貴重な参照になる。留意点は三つ。READMEは非常に長く更新が速い。多くの節は現在のソースの挙動を述べているので、配備前に自分のバージョンと照合すること。力とリスクが同じもの、つまりコマンド実行とファイルの読み書きに由来するため、既定のループバック束縛を軽々しく変えてはいけない。モデルの推奨にはベンダー寄りの傾向があり、実際の結果は接続するモデルとタスクによる。まず隔離したコンテナで、テストデータだけを入れたディレクトリを使って動かし、実データや外部チャネルを接続するかはその後に決めるとよい。