ByteDanceが公開したOSS「DeerFlow」がGitHub Trendingで急上昇しています。執筆時点（2026年3月23日）でスター数は約3.7万、ピーク時には1日あたり約3,500スターという伸びを見せていました。本記事では、この急上昇の背景にあるByteDanceの戦略を読み解いたうえで、アーキテクチャの深掘り、実際にリサーチタスクを実行した結果、そしてClaude Codeとの実践的な使い分けまでを扱います。
なぜByteDanceがこれを公開したのか
DeerFlowの公開は、単なるOSS貢献ではありません。ByteDanceの戦略的な文脈の中で読む必要があります。
中国テック企業のOSS攻勢
2024年末のDeepSeek R1公開を皮切りに、中国テック企業によるOSS公開の流れが加速しています。AlibabaのQwenシリーズ（2023年〜）やBaiduのERNIEシリーズ（2023年〜）はそれ以前から展開されていましたが、DeepSeek以降はエージェントやツール層にも公開の波が広がり、ByteDanceもDeerFlowで参入しました。背景には以下の構造的な動機があると考えられます。
- 開発者エコシステムの囲い込み: OSSで開発者を引きつけ、自社クラウド（火山エンジン）への誘導を狙う
- 人材採用ブランディング: 高品質なOSSを公開することで、優秀なエンジニアへのアピール材料とする
- 規制リスクの分散: TikTokの地政学的リスクが続く中、「OSSに貢献する企業」としての国際的な信頼構築
Doubaoとの関係
ByteDanceは自社LLM「Doubao（豆包）」を展開しています。DeerFlowはモデル非依存を謳っていますが、Doubaoのエコシステム拡大と無関係ではありません。DeerFlowが普及すれば、Doubaoモデルの実利用シーンが増えます。「プラットフォーム層を押さえて、モデル層の採用を促す」という戦略です。
DeerFlowは「モデル非依存」が公式の立場です。OpenAI互換APIであれば何でも動作します。ただし、ByteDanceにとっての真の価値は、このプラットフォーム上で自社モデルの利用が広がることにあると見るのが自然です。
GitHub急上昇の異常さ
スター増加ペースの目安（執筆時点: 2026年3月23日）
直近のGitHub Trending上位と比較した目安です。スター数は日々変動するため、あくまで執筆時点の参考値です。
| プロジェクト | ピーク時のスター増加率（推定） | 執筆時点のスター数 | 公開元 |
|---|---|---|---|
| DeepSeek-R1 | 約8,000/日 | 32万超 | DeepSeek |
| Grok (xAI) | 約5,500/日 | 5万超 | xAI |
| DeerFlow | 約3,500/日 | 約3.7万 | ByteDance |
| Dify | 約2,000/日 | 8万超 | LangGenius |
| OpenHands | 約1,800/日 | 5万超 | All Hands AI |
DeepSeek-R1ほどではないものの、エージェントフレームワークとしてはDifyやOpenHandsを上回るペースと見られます。LLM本体ではなくツール層でこの数字が出ること自体が珍しいと言えます。
急上昇の要因
- DeerFlow 2.0のリアーキテクチャ: 公式READMEによると「ground-up rewrite」であり、v1とコードを共有していないとされています。この大幅刷新が「新規プロジェクト」として注目を集めた可能性があります
- 中国テックOSSへの関心の高まり: DeepSeek以降、中国発OSSを積極的に試す層が増えている
- エージェントフレームワークへの需要: 2026年に入り、単体LLMから「エージェント」への移行が本格化している
deer-flow とは
DeerFlow（Deep Exploration and Efficient Research Flow）は、ByteDanceが公開したオープンソースのSuperAgentシステムです。LangGraphとLangChainの上に構築されています。
主要な機能は以下の通りです。
- マルチエージェントによるタスク分解と並列実行
- サンドボックス環境でのコード実行
- Web検索・ページ取得による自律リサーチ
- 長期メモリによるユーザーコンテキストの保持
- Slack / Telegram / Feishu との連携
公式READMEによると、DeerFlow 2.0は「ground-up rewrite」であり、v1とはコードを共有していないとのことです。v1を使っていた方は 1.x ブランチを参照してください。
リポジトリ: https://github.com/bytedance/deer-flow
アーキテクチャ深掘り
全体構成
DeerFlowは4つのサービスで構成されます。
| サービス | ポート | 役割 |
|---|---|---|
| Nginx | 2026 | 統合リバースプロキシ（エントリーポイント） |
| LangGraph Server | 2024 | エージェントランタイム・ワークフロー実行 |
| Gateway API | 8001 | REST API（モデル管理・スキル・メモリ等） |
| Frontend | 3000 | Next.js製のWebインターフェース |
Lead Agent + Sub-Agent のオーケストレーション
DeerFlowの中核は「Lead Agent」と「Sub-Agent」の階層構造です。
この設計の特徴は3つあります。
動的なAgent生成: タスクの複雑さに応じて、Sub-Agentの数と種類が変わります。「簡単な質問」なら1体、「比較調査」なら複数体が生成されます。固定のパイプラインではなく、LangGraphの仕組みを活用して動的に制御されていると見られます。
独立したコンテキスト: 各Sub-Agentは独自のコンテキストウィンドウを持ちます。Lead Agentの指示と、自分が収集した情報だけで動作します。これにより、長大な調査でもコンテキストが溢れにくい構造になっています。
LangGraph / LangChainベースの実装: DeerFlowはLangGraphとLangChainの上に構築されています。公式READMEによると、LangGraphのエージェントサーバー（langgraph dev）で稼働し、Lead Agentの生成やSub-Agentの実行管理にはLangChainのエージェント機構が使われていると見られます。ミドルウェアチェーンとスキルシステムをその上に積み重ねた構成です。
ソースコード上は backend/src/agents/ にLead Agent、backend/src/subagents/ にSub-Agentの実装が分離されており、ミドルウェアは backend/src/agents/middlewares/ にまとめられています。
ミドルウェアチェーン
Lead Agentにはミドルウェアが順序通りに適用されます。ソースコード（backend/src/agents/middlewares/）を確認すると、執筆時点では9つのミドルウェアが確認できます。主要なものを抜粋します。
| ミドルウェア | 役割 |
|---|---|
| ThreadDataMiddleware | スレッドごとのディレクトリ作成 |
| SandboxMiddleware | サンドボックスの取得・管理 |
| SummarizationMiddleware | トークン上限に近づいたときの要約 |
| MemoryMiddleware | 長期メモリへの非同期保存 |
| ClarificationMiddleware | ユーザーへの確認割り込み |
SummarizationMiddlewareは実用上重要です。長い調査タスクでコンテキストが膨らんでも、途中結果を要約してウィンドウを確保します。これがないと、複数ソースを横断する調査で途中破綻する可能性があります。
サンドボックス
DeerFlowは3種類のサンドボックスモードを提供します。
| モード | 特徴 | 想定用途 |
|---|---|---|
| Local | ホストマシンで直接実行（デフォルト） | 開発・検証 |
| Docker | Dockerコンテナ内で隔離実行 | 個人利用 |
| Docker + Kubernetes | Provisioner経由でKubernetes Podに分離 | チーム・本番環境 |
Localモードはホストマシン上で直接コードが実行されます。悪意あるプロンプトインジェクションへの耐性は保証されません。外部からの入力を扱う場合は、最低でもDockerモードを使ってください。
コンテナ内のファイルシステムは以下の構造です。
/mnt/user-data/
├── uploads/ # アップロードファイル
├── workspace/ # エージェントの作業ディレクトリ
└── outputs/ # 最終成果物
スキルシステム
DeerFlowの「スキル」はMarkdownファイルで定義されたワークフローモジュールです。
/mnt/skills/public
├── research/SKILL.md
├── report-generation/SKILL.md
├── slide-creation/SKILL.md
├── web-page/SKILL.md
└── image-generation/SKILL.md
/mnt/skills/custom
└── your-custom-skill/SKILL.md # 独自スキルを追加可能
スキルはプログレッシブにロードされます。タスクが必要とするタイミングで初めて読み込まれるため、コンテキストウィンドウを圧迫しません。
セットアップ手順
必要な環境
- Python 3.12以上
- Node.js 22以上
- pnpm（フロントエンドのパッケージ管理）
- uv（Pythonパッケージ管理）
- Docker（サンドボックスモードを使う場合）
インストール
git clone https://github.com/bytedance/deer-flow.git
cd deer-flow
設定ファイルを生成します。
make config
config.yaml と .env が生成されます。
モデル設定
config.yaml を編集し、使用するLLMを定義します。OpenAI互換APIであれば何でも使えます。
models:
- name: gpt-4
display_name: GPT-4
use: langchain_openai:ChatOpenAI
model: gpt-4
api_key: $OPENAI_API_KEY
max_tokens: 4096
temperature: 0.7
OpenRouter経由で他のモデルを使う場合は base_url を追加します。
models:
- name: openrouter-gemini-2.5-flash
display_name: Gemini 2.5 Flash (OpenRouter)
use: langchain_openai:ChatOpenAI
model: google/gemini-2.5-flash-preview
api_key: $OPENROUTER_API_KEY
base_url: https://openrouter.ai/api/v1
Anthropicのモデルを使う場合は、langchain_anthropic:ChatAnthropic を指定します。
models:
- name: claude-3-5-sonnet
display_name: Claude 3.5 Sonnet
use: langchain_anthropic:ChatAnthropic
model: claude-3-5-sonnet-20241022
api_key: $ANTHROPIC_API_KEY
max_tokens: 8192
APIキーの設定
.env ファイルにAPIキーを記載します。
OPENAI_API_KEY=sk-your-key
TAVILY_API_KEY=tvly-your-key
Tavily APIキーはWeb検索機能に必須です。Tavilyで無料アカウントを作成し、APIキーを取得してください。無料枠は月1,000リクエストです。リサーチ1回で5〜20リクエストを消費するため、本格利用にはProプラン（月$50〜）が現実的です。
依存関係のインストールと起動
make check # 必要なツールの確認
make install # バックエンド + フロントエンドの依存関係をインストール
make dev # 全サービスを開発モードで起動
ブラウザで http://localhost:2026 にアクセスすると、DeerFlowのUIが表示されます。
Docker での起動（推奨）
本番環境やサンドボックスを使いたい場合はDockerが推奨です。
make docker-init # サンドボックスイメージの取得（初回のみ）
make docker-start # サービス起動
実践: リサーチタスクを実行してみた
実際にDeerFlowで調査タスクを実行し、出力品質を評価しました。
テスト1: 「2026年のフロントエンドトレンド」
以下のプロンプトを投入しました。
2026年のフロントエンド開発トレンドについて調査してください。
主要フレームワークの動向、新しいパラダイム、注目技術を網羅し、
開発者が今注力すべき領域を提言するレポートを作成してください。
実行の流れ:
- Lead Agentがタスクを3つのサブタスクに分解（約5秒）
- Sub-Agent 3体が並列でWeb検索を開始（Tavilyへのリクエスト計12回）
- 各Sub-Agentが情報を収集・整理（約40秒）
- Lead Agentが統合レポートを生成（約20秒）
- 合計所要時間: 約70秒
出力の品質評価:
| 観点 | 評価 | コメント |
|---|---|---|
| 情報の網羅性 | 良い | React/Vue/Svelte/Solidの主要4フレームワークをカバー。Astro、htmxにも言及 |
| 情報の鮮度 | やや課題あり | 2026年3月時点の最新情報を一部拾えていない。Tavilyの検索結果に依存 |
| 構成の論理性 | 良い | 「現状→変化→提言」の流れが整理されていた |
| 日本語の品質 | 課題あり | 英語ソースからの翻訳感が残る箇所がある。後述 |
| 引用・ソース | 良い | 各情報にURLが付与されており、検証可能 |
テスト2: 技術比較調査
Rustのasync runtimeについて、tokio / async-std / smolの3つを比較調査してください。
パフォーマンス特性、エコシステムの成熟度、ユースケースを整理し、
レポートにまとめてください。
こちらはより焦点が明確なため、出力品質が高くなりました。各ランタイムのベンチマーク結果の引用、主要クレートの互換性の表、具体的なユースケース別の推奨まで含む内容でした。
所感: DeerFlowは「広く浅く」の調査よりも「特定テーマの比較分析」で真価を発揮します。明確な比較軸があるタスクほど、Sub-Agent間の役割分担がうまく機能する印象です。
Pythonクライアントからの実行
公式READMEによると、DeerFlowはHTTPサーバーを起動せずに、組み込みPythonクライアント（DeerFlowClient）として直接使うこともできます。
from deerflow.client import DeerFlowClient
client = DeerFlowClient()
# 同期的にチャット
response = client.chat(
"TypeScriptのランタイム比較（Node.js / Deno / Bun）をまとめてください",
thread_id="research-ts-runtimes"
)
print(response)
# ストリーミングで結果を受け取る
for event in client.stream("Pythonのパッケージマネージャーの現状を調査してください"):
if event.type == "messages-tuple" and event.data.get("type") == "ai":
print(event.data["content"], end="", flush=True)
モデルやスキルの管理もAPI経由で行えます。
# 利用可能なモデル一覧
models = client.list_models()
print(models)
# スキル一覧
skills = client.list_skills()
print(skills)
# ファイルのアップロード
client.upload_files("my-thread", ["./data.csv"])
IM連携での実行
Telegram / Slack / Feishu と連携すれば、メッセージアプリから直接タスクを投げられます。config.yaml に設定を追加するだけです。
channels:
telegram:
enabled: true
bot_token: $TELEGRAM_BOT_TOKEN
allowed_users: []
チャット内で使えるコマンドは以下の通りです。
| コマンド | 動作 |
|---|---|
/new |
新しい会話を開始 |
/status |
現在のスレッド情報を表示 |
/models |
利用可能なモデルを一覧 |
/memory |
メモリを確認 |
Claude Code との使い分け
DeerFlowとClaude Codeは競合ではなく、得意領域が明確に異なります。
比較表
| 観点 | DeerFlow | Claude Code |
|---|---|---|
| 主な用途 | リサーチ・コンテンツ生成・データ分析 | コード開発・デバッグ・リファクタリング |
| アーキテクチャ | マルチエージェント（Lead + Sub-Agents） | シングルエージェント + サブエージェント |
| サンドボックス | Docker / Kubernetes対応 | ローカル実行（サンドボックスあり） |
| モデル | 任意のOpenAI互換モデル | Claude固定 |
| メモリ | 長期メモリ（セッション跨ぎ） | CLAUDE.md + メモリファイル |
| UI | Web UI + IM連携 | ターミナル |
| Web検索 | Tavily統合で標準装備 | WebFetchツール（手動指定） |
判断基準: どちらを使うか
DeerFlowを選ぶ場面:
- 複数ソースを横断するリサーチ（技術比較、市場調査）
- レポートやスライドなどの成果物生成
- 定期的な情報収集の自動化（IM連携）
- チームで共有するリサーチ基盤の構築
Claude Codeを選ぶ場面:
- コードベースの理解・修正・リファクタリング
- デバッグ（ログを読んで原因特定まで）
- ファイル操作やgit操作を伴う作業
- 対話的な開発（フィードバックループが速い）
組み合わせパターン
実際に有効だと感じた組み合わせを紹介します。
パターン1: DeerFlowでリサーチ → Claude Codeで実装
技術選定の調査をDeerFlowに任せ、その結果を踏まえてClaude Codeで実装する流れです。たとえば「状態管理ライブラリの比較調査」をDeerFlowで行い、選定結果に基づいてClaude Codeでコードを書く、という使い方です。
パターン2: Claude Codeのclaude-to-deerflowスキル
DeerFlowはClaude Codeとの直接連携機能を備えています。
npx skills add https://github.com/bytedance/deer-flow --skill claude-to-deerflow
これにより、Claude Codeのターミナルから「この技術について調べて」とDeerFlowにリサーチを委譲できます。コードを書きながら、必要な調査だけDeerFlowに投げる運用が可能です。
制限事項と注意点
導入前に把握しておくべき制限を正直に書きます。
APIコスト
DeerFlowはマルチエージェントで動作するため、LLMへのAPI呼び出し回数が多くなります。
| タスクの規模 | LLM呼び出し回数（目安） | Tavily検索回数 | 推定コスト（GPT-4使用時） |
|---|---|---|---|
| 簡単な質問 | 3〜5回 | 0〜2回 | $0.05〜0.15 |
| 比較調査 | 10〜20回 | 8〜15回 | $0.30〜1.00 |
| 包括的リサーチ | 20〜40回 | 15〜30回 | $1.00〜3.00 |
Lead Agent + 複数Sub-Agentがそれぞれ独立にLLMを呼び出すため、1タスクあたりのコストはシングルエージェントの3〜5倍になることがあります。OpenRouterで安価なモデル（Gemini 2.5 Flash等）を使うか、Sub-Agentに軽量モデルを割り当てることでコスト最適化が可能です。
日本語対応の状況
DeerFlowのUIは多言語対応しており、日本語でのやり取りは可能です。ただし、以下の課題があります。
- Web検索結果が英語に偏る: Tavilyの検索結果は英語ソースが中心。日本語固有の情報（法規制、国内市場動向など）は拾いにくい
- 出力の翻訳感: 英語ソースを元にした日本語レポートは、自然な日本語とは言い難い箇所がある
- プロンプトの言語指定が必要: 「日本語で出力してください」と明示しないと英語で返ってくる場合がある
日本語の情報を重視する調査では、プロンプトに「日本語のソースを優先して検索してください」と明示するのが有効です。
レート制限
- Tavily無料枠: 月1,000リクエスト。ヘビーに使うと数日で枯渇する
- LLM APIのレート制限: Sub-Agentが並列で動くため、RPM（Requests Per Minute）制限に引っかかりやすい。特にOpenAIのTier 1アカウントでは注意が必要
精度の課題
- ハルシネーション: Web検索結果に含まれない情報を「補完」してしまうケースがある。特にSub-Agentが検索結果をLead Agentに要約する過程で、微妙なニュアンスの歪みが発生することがある
- 古い情報の混入: 検索結果の日付フィルタリングが甘く、数年前の記事の内容が最新情報として扱われる場合がある
- 出典の検証が必要: URLは付与されるが、リンク切れや内容の変更がある。重要な情報は必ず原典を確認すること
DeerFlowの出力を「事実」として無検証で使うのは危険です。あくまで「調査の起点」として活用し、重要な情報は原典に当たる運用をお勧めします。これはDeerFlowに限らず、AIリサーチツール全般に言えることです。
まとめ
DeerFlowは、マルチエージェント・サンドボックス・長期メモリ・スキルシステムを統合したSuperAgentフレームワークです。ByteDanceの開発力を背景に、今後も活発な開発が続くと見込まれます。
導入のハードルは make config && make dev の2コマンドと低く、公式READMEによるとPythonクライアント（DeerFlowClient）を使えばスクリプトへの組み込みも可能です。モデル非依存のため、コストや性能に応じてLLMを自由に選択できます。
一方で、マルチエージェント特有のAPIコスト増、日本語情報の取得精度、ハルシネーションリスクなど、実運用には注意点があります。「万能なリサーチャー」ではなく、「調査の初動を高速化するツール」として位置づけるのが現実的です。
Claude Codeと組み合わせることで「リサーチはDeerFlow、実装はClaude Code」という分業体制が構築できます。どちらか一方ではなく、両方をワークフローに組み込むのが現時点での最適解です。