AIエージェント基盤にDeerFlowが選ばれる理由と類似OSSの違い

自社サービスに AI エージェントを組み込む検討を始めると、まず候補として挙がるのは GPT Researcher や CrewAI、AutoGen、LangGraph などです。そこに 2026 年 2 月末、ByteDance が公開した「DeerFlow」が加わり、GitHub Trending 1 位を獲得したこともあって「これも候補に入れるべきか」と迷う開発者が増えています。

しかし OSS の紹介記事は機能の羅列に偏りがちで、「自プロジェクトに DeerFlow を採用すべきか、既存候補の GPT Researcher や CrewAI を選ぶべきか」という一次意思決定を助ける情報にたどり着きにくいのが実情です。ByteDance 発 OSS のメンテナンス継続性・ライセンス・セキュリティ懸念も気になるところでしょう。

本記事では、公式 README・公式サイト・GitHub API の公開情報を突き合わせ、DeerFlow のポジショニング・アーキテクチャ・類似 OSS との差分・導入時の注意点を整理します。読み終えたときに「触ってみる価値がある／別 OSS を優先する」の判断材料が揃うことを目標とします。

なお本記事はドキュメントベースの調査記事であり、実行や環境構築を伴う動作検証は行っていません。数値・仕様の一次情報は公式リポジトリ bytedance/deer-flow および公式サイト deerflow.tech を参照しています。

DeerFlowとは何か

DeerFlow は、ByteDance（TikTok を運営する中国発のテクノロジー企業）が公開しているオープンソースの AI エージェントハーネスです。名称は "Deep Exploration and Efficient Research Flow" の頭文字に由来しており、ロゴにも鹿（Deer）のモチーフが使われています。

公式リポジトリ bytedance/deer-flow の GitHub API 情報（2026-07-03 時点）は次のとおりです。

archived / fork / disabled のいずれも false であり、本記事執筆時点（2026-07-03）でも活発にコミットが行われているアクティブなリポジトリです。スター数が 75,000 を超え、フォーク数も 10,000 を超えている点、直近まで push が続いている点から、当面のメンテナンス継続性は健全と判断できます。ライセンスは商用利用にも扱いやすい MIT です。

DeerFlow は自らを「framework（フレームワーク）」ではなく「harness（ハーネス）」と呼びます。公式 README では次のように位置づけられています。

DeerFlow 2.0 is no longer a framework you wire together.
It's a super agent harness — batteries included, fully extensible.

出典: bytedance/deer-flow README

「配線して組み立てるフレームワーク」ではなく、「箱を開ければすぐに動く、拡張可能なハーネス」というのが DeerFlow の自己認識です。GitHub API から取得できる description は次のとおりで、この位置づけを裏付けています。

An open-source long-horizon SuperAgent harness that researches, codes, and creates. With the help of sandboxes, memories, tools, skill, subagents and message gateway, it handles different levels of tasks that could take minutes to hours.

キーワードは「long-horizon（分〜時間単位の長時間タスク）」「researches, codes, and creates（研究・コーディング・生成）」「sandboxes, memories, tools, skill, subagents, message gateway（同梱される主要コンポーネント）」です。単発の質問応答ではなく、複数ステップにまたがるタスクを 1 つのハーネス内で完結させることを狙った OSS だと言えます。

2026 年 2 月 28 日には v2.0 のリリースに合わせて GitHub Trending 1 位を獲得しており、既に指名検索が発生している状態のプロダクトです。日本語ドキュメントも公式で用意されているため（README (日本語)）、日本語話者のエンジニアでも一次情報にアクセスしやすい点は好材料です。

DeerFlow 2.0 で刷新された点

DeerFlow は v1 と v2 で性格が大きく異なる OSS です。この差を理解しないと、Web 上に残っている v1 前提の解説記事を読んで混乱する可能性があります。

v1 は「Deep Research 用フレームワーク」として設計されていました。マルチステップで Web を調査し、レポートを生成する用途に特化していた OSS です。

v2 は 2026 年 2 月に公開された完全書き直しバージョンで、公式 README では「1 行も v1 のコードを共有していない ground-up rewrite」と明言されています。役割も再定義され、「Super Agent Harness」として研究以外の用途（コーディング・スライド生成・動画生成など）まで対象範囲を拡張しています。

重要なポイントは、v1 が捨てられたわけではないという点です。v1 は main-1.x ブランチ で保守が継続されており、Deep Research 用途で v1 を採用しているプロジェクトはそのブランチを追跡できます。v2 は main ブランチで開発が進んでいます。

初見のエンジニアにとって意識すべきは以下の 2 点です。

• 「DeerFlow 使い方」で検索して出てくる古い日本語記事の一部は v1 前提である可能性があります。バージョンを確認しながら読む必要があります
• v2 は「framework」ではなく「harness」を名乗る通り、自分で配線する部品セットというより、動く状態で提供されるアプリケーションに近いです。既存の LangChain / LangGraph 資産と組み合わせて「自分のフレームワーク」を組みたい場合には、後述する CrewAI や LangGraph 直接利用の方が適合するケースもあります

主要機能とアーキテクチャ

ここからは DeerFlow を構成するコアコンポーネントを整理します。ここでの解説は README の Core Features 節（bytedance/deer-flow#core-features）を一次情報とし、各コンポーネントが「なぜその構造なのか」までを含めて紹介します。

スキルとツール

DeerFlow の機能拡張は「スキル」と「ツール」の 2 層で提供されます。

• スキル（Skills）: Markdown で定義された機能モジュール。ワークフロー・ベストプラクティス・参照リソースが構造化されて記述されており、エージェントに「特定領域の仕事の進め方」を教える単位となります。組み込みスキルとして research（調査）、report generation（レポート生成）、slide creation（スライド作成）、web page（Web ページ生成）、image / video generation（画像・動画生成）が用意されています。カスタムスキルも追加可能です
• ツール（Tools）: web search / web fetch / rendered web capture（レンダリング済み Web キャプチャ）/ file operations / bash execution といった実行系の道具。MCP サーバー・Python 関数経由でカスタムツールも追加可能です

差別化ポイントとして注目したいのが「スキルの進歩的ロード」です。全スキルを常時ロードするのではなく、タスクが必要とした時点でのみロードされます。これは LLM のトークンコンテキストを消費させないための設計で、スキルの数が増えても常時のコンテキスト圧迫を避けられます。ユーザーが /data-analysis analyze uploads/foo.csv のようなスラッシュコマンドで明示的にアクティベートすることも可能です。

動的サブエージェント

DeerFlow は「Lead Agent（親エージェント）」がタスクの状況に応じて「サブエージェント」を動的に spawn するアーキテクチャを取っています。

• 各サブエージェントは独立したコンテキスト・ツール・終了条件を持ちます
• サブエージェントは並列実行されます
• 結果は Lead Agent が統合します

事前にロールと目標を静的に定義する CrewAI 型のマルチエージェントとは対照的なアプローチです。タスクの複雑さに応じて必要な数のサブエージェントを動的に立ち上げられるため、事前設計コストを抑えつつ複雑タスクを扱えることが期待できます。この差分は後述の「DeerFlow と類似 OSS の違い」で改めて整理します。

サンドボックスとファイルシステム

DeerFlow は各タスクに独立した実行環境（サンドボックス）を割り当てます。1 タスク 1 サンドボックスで、以下が同梱されます。

• filesystem（ファイルシステム）
• skills（当該タスクに必要なスキル）
• workspace（作業領域）
• uploads（アップロードファイル）
• outputs（生成物）

サンドボックスは Docker / Kubernetes 上での実行に対応しつつ、ローカル実行モードも選択できます。GPT Researcher や CrewAI では別途構築が必要になる「隔離されたコード実行環境 + ファイルシステム」を、DeerFlow は同梱パッケージとして提供している点が特徴です。長時間タスク（バックグラウンドで数十分〜数時間走らせるジョブ）を扱うことを前提にした設計と読み取れます。

長期メモリと Context Engineering

DeerFlow はセッション横断で保持される永続メモリを持ちます。ユーザーのプロフィール・好み・過去に得た知識が蓄積され、Settings > Memory から内容を確認できる仕組みです。

Context Engineering という概念も導入されており、これはサブエージェント間のコンテキスト分離・要約・オフロード・圧縮を含む一連の工夫を指します。長時間タスクではコンテキスト長が肥大化しがちですが、Context Engineering によって「関連情報だけを次のステップに渡す」設計が明示されている点は、long-horizon 志向のハーネスとして重要な設計判断と言えます。

このほかにも Message Gateway（Telegram / Slack / Feishu / WeChat / WeCom / DingTalk から DeerFlow にタスクを投げられる仕組み）や、/goal コマンドによるセッション完了条件の紐付けなど、周辺機能が数多く同梱されています。詳細は README の Core Features 節（bytedance/deer-flow#core-features）に一覧されています。

DeerFlow と類似 OSS の違い

DeerFlow を候補に入れるか判断する上で、既存の代表的なエージェント OSS との差分整理は避けて通れません。ここでは特に検索需要の高い GPT Researcher と CrewAI を対象に、位置づけ・アーキテクチャ・想定用途を比較します。

GPT Researcher との違い（研究特化 vs 汎用ハーネス）

assafelovic/gpt-researcher は自律型ディープリサーチエージェントの代表格です。マルチソース Web 調査から引用付きの構造化長文レポートを生成することに特化しており、ネストされた並列グラフパターンを採用して約 3 分という高速な完了時間を実現しています。

DeerFlow との差分は以下の 3 点に集約されます。

1. タスク範囲: GPT Researcher は「リサーチ完結型」。DeerFlow は v2 でリサーチに加えてコーディング・スライド作成・動画生成まで対象範囲を拡張しています
2. 時間軸: GPT Researcher は 3 分で結論を出す高速志向。DeerFlow は分〜時間単位の long-horizon 志向
3. 同梱範囲: GPT Researcher にはサンドボックス・永続メモリ・IM チャネル連携がない。DeerFlow はこれらを同梱します

「Web 調査 → 引用付きレポート」以外の要件がなく、高速・軽量に済ませたい場合は GPT Researcher が有力候補になります。一方、「調査結果をもとにコードやスライドを生成する」「バックグラウンドで長時間ジョブを走らせる」「Slack や Telegram からタスクを受け付ける」といった要件が絡む場合は、それらを別途構築する手間を DeerFlow が同梱で肩代わりしてくれるため、DeerFlow が有利になります。

CrewAI との違い（静的ロール vs 動的サブエージェント）

crewAIInc/crewAI は「Role（役割）」「Goal（目標）」「Backstory（バックストーリー）」をエージェントごとに事前定義し、Crew（チーム）として編成する OSS です。業務プロセス自動化やロール分業型ワークフローで採用実績が多く、ツール統合エコシステムが広く成熟しています。

DeerFlow との差分は次のとおりです。

1. エージェント構成: CrewAI は「事前に役割定義したエージェント群」を組む静的構成。DeerFlow は「Lead Agent が動的にサブエージェントを spawn」する動的構成
2. サンドボックス: CrewAI にはサンドボックス実行環境（filesystem + bash execution）が組み込まれていません。DeerFlow は同梱です
3. スキル管理・IM チャネル: CrewAI にはスキルの進歩的ロード機構・IM チャネル連携が組み込まれていません

事前に「営業担当エージェント」「技術担当エージェント」といった役割分担が明確なユースケースや、既存の CrewAI ツールエコシステムを活用したいケースでは CrewAI が引き続き有力です。一方、タスクの複雑さが事前に見えず「必要になったサブエージェントを動的に立ち上げたい」「同一ハーネス内でコード実行・ファイル操作まで完結させたい」という要件では DeerFlow が候補に上がります。

なお、招待制のクローズドサービスである Manus AI の代替候補として DeerFlow が挙げられる文脈も存在します。ブラウザ操作・コード実行・ファイル管理を自律実行する完全自律型エージェントの OSS 版アプローチとして、DeerFlow / GPT Researcher / CrewAI が並列で比較されるケースが増えています。

対応モデル・セットアップ手段

意思決定材料として、対応モデルとセットアップ形態を整理します。詳細な設定手順は公式の Configuration Guide に集約されています。

対応 LLM モデル

DeerFlow はモデル非依存で、OpenAI-compatible API を実装する任意の LLM に接続できます。ByteDance の README では次のモデルが推奨として挙げられています。

• Doubao-Seed-2.0-Code
• DeepSeek v3.2
• Kimi 2.5

加えて、CLI 経由の Codex CLI・Claude Code OAuth もサポートされており、Qwen3 等の vLLM ローカル LLM にも対応します。「自社が契約している LLM プロバイダーで動くか」を判断する場合、OpenAI 互換 API を提供しているモデルであれば基本的に接続可能と考えられます。

セットアップ形態

DeerFlow は用途に応じて 5 種のセットアップ形態を提供しています。

いずれも Web UI は http://localhost:2026 でアクセスします。TUI モードは Gateway / frontend / nginx / Docker を要求しないスタンドアロン実行が可能で、Web UI とスレッドを共有します。

想定リソース要件

README のリソース目安は次のとおりです。

• 最低構成: 4 vCPU / 8 GB RAM / 20 GB SSD（ローカル評価）
• 推奨構成: 8 vCPU / 16 GB RAM
• 本番: 8 vCPU / 16 GB RAM 以上、Linux + Docker が推奨環境

「まず手元で動作を確認して感触を掴む」段階であれば 4 vCPU / 8 GB RAM の一般的な開発機で足りますが、本番運用では 8 vCPU / 16 GB 以上を確保することが推奨されます。long-horizon タスクを想定した OSS のため、常時稼働するサーバー側リソースも予算に組み込むと安全です。

導入時の注意点

意思決定支援の観点から、「本番運用で踏みそうな落とし穴」を先に共有しておきます。特に重要なのが公式が明記しているセキュリティ警告です。

Security Notice（公式警告）

README の Security Notice 節では、DeerFlow のデフォルト設定について次のように注意喚起されています。

• デフォルトは 127.0.0.1（loopback）バインドを前提とした「信頼済みローカル環境向け」の設定です
• LAN・パブリッククラウド・多エンドポイント環境では、未認可の呼び出しリスクが存在します
• DeerFlow はシステムコマンド実行・ファイル読み書きといった高権限機能を持つため、そのままインターネットに公開しないでください

対策として README は次のような多層防御を推奨しています。

• IP allowlist（iptables やハードウェアファイアウォールによる制限）
• 認証ゲートウェイ（nginx リバースプロキシに事前認証を挟む構成）
• ネットワーク分離（専用 VLAN 上でのみアクセス可能にする）

自社サービスに組み込む場合は「デフォルト設定のまま本番デプロイしない」ことを大前提とし、認証・ネットワーク境界の設計を先に決める必要があります。ここは PoC の段階からセキュリティ担当と方針を握っておくと後戻りが減ります。

ライセンスと依存基盤

• ライセンスは MIT。商用利用も含めて扱いやすいが、依存パッケージ側のライセンスは別途確認が必要です
• 実装基盤として LangChain / LangGraph に強く依存しています。両者の破壊的変更が入った際の追従コストは、DeerFlow を採用する時点で内包することになります
• 対応 IM チャネル（Telegram / Slack / Feishu / WeChat / WeCom / DingTalk）はいずれも long-polling / WebSocket 経由。導入時にはインバウンド通信を許可するネットワーク設計が必要になります

v1 系記事との混同

前述のとおり、v1 は Deep Research 用フレームワークで、v2 は Super Agent Harness です。「DeerFlow 使い方」「DeerFlow Deep Research」で検索した際、v1 前提の日本語記事や、v2 の記述と混在した記事に遭遇する可能性があります。最新の情報を追う場合は、まず公式 README（英語・日本語）と公式サイト deerflow.tech を一次情報として押さえ、外部記事はバージョンを確認しながら読むのが安全です。

まとめ — どのようなプロジェクトに向いているか

最後に、これまでの整理をもとに DeerFlow の採用判断ガイドをまとめます。

DeerFlow が向くケース

• 単発のリサーチではなく、「調査 → 生成物制作（レポート / コード / スライド / 動画）」まで含む long-horizon タスクを 1 つのハーネスで扱いたい
• サンドボックス（filesystem + bash 実行）や永続メモリを自前で構築せず、同梱パッケージとして受け取りたい
• Telegram / Slack / Feishu / WeChat / WeCom / DingTalk から自然にタスクを投入するインターフェースが欲しい
• 事前に役割を静的定義するのではなく、Lead Agent が動的にサブエージェントを spawn する構成に共感できる
• OpenAI 互換 API を提供する任意モデル（ByteDance 推奨は Doubao-Seed-2.0-Code / DeepSeek v3.2 / Kimi 2.5）と組み合わせて使いたい

別 OSS を優先すべきケース

• 「Web 調査 → 引用付きレポート」だけを高速・軽量に完結させたい → GPT Researcher を優先
• 事前に定義した役割分担（営業担当・技術担当など）でチームを組ませたい／CrewAI の既存ツールエコシステムを活用したい → CrewAI を優先
• LangGraph を直接使って自分でエージェントグラフを組み立てたい → LangGraph 直接利用が候補になる

最初の一歩

DeerFlow を候補に残す判断をした場合、最初の一歩は次のとおりです。

• 公式サイト deerflow.tech で最新の全体像を確認する
• 公式リポジトリ bytedance/deer-flow の README を英語または日本語版で通読する
• Configuration Guide で自社の LLM 契約・インフラ制約と接続可能か確認する
• 本番導入を検討する場合は、README の Security Notice を必ず先に読み、ネットワーク境界・認証の方針を設計に組み込む

DeerFlow はスター数 75,954・フォーク数 10,268 という OSS として十分な規模と、直近まで続くコミット・MIT ライセンス・公式日本語ドキュメントを備えた OSS です。「long-horizon タスクを 1 つのハーネスで扱いたい」という要件があるプロジェクトにとっては、GPT Researcher・CrewAI と並べて一度は評価する価値のある選択肢と言えます。