DeepSeek、コーディング作業を並行処理する「Super-agent」のプロトタイプを公開

複数の作業を同時に処理するコーディングエージェント

DeepSeekのHarnessチームは2026年10月31日、Super-agentの設計を公開するとともに、GitHubリポジトリへの依頼を個別のコーディングセッションに振り分けるMITライセンスの研究用プロトタイプを発表した。開発者が会話を切り替えたり進捗を確認したりする時間を減らしながら、複数の作業を同時に進めることを目指す。

チームが行った予備実験では、約20件の作業依頼を含む約300件のシミュレーションメッセージを使用した。Super-agentは12.4分以内にタスクの半数を、15.7分以内に95％を完了した。メインセッション1つから補助エージェントを利用する比較システムは、中立的な指示の下で95％に達するまで29.5分かかった。

DeepSeekの公開プロトタイプリポジトリ「dsh-superagent-prototype」は、より範囲を絞った実用的なリリースとして、DeepSeek Harness向けのバンドル形式で提供する、単一のGitHubリポジトリ用の自律型コーディングエージェントを示している。GitHubと、任意でFeishuを監視し、権限を持つユーザーが作業を依頼するとタスクを作成する。元の会話に返信し、コード変更を提案するプルリクエストを作成することもある。

READMEには明確な注意書きもある。公開コードは内部システムや設計文書の一部とは異なり、提案されている機能の中には今後の開発課題も残る。DeepSeekはこのリリースを完成品ではなく研究用コードと位置付けている。

プロトタイプを保守するDeepSeek Harnessチームは、READMEでその位置付けを次のように記している。

参考用の研究プロトタイプであり、DeepSeekの公式製品ではありません。

開発者にとって、このリリースは調査や改変が可能なコードを提供するものだ。中心となる実験では、エージェントがどのように作業を整理し、関連する会話を記憶し、人の介入が必要なタイミングを判断するかを検証している。

DeepSeekがセッション管理を見えなくしようとする理由

DeepSeekの設計は、自社での業務から得たある観察を出発点としている。人が同時に追えるエージェントのセッションは、通常3〜5件ほどだ。各セッションは独自の会話履歴を持つため、開発者はどのタスクがどこで進んでいるか、各エージェントにどんな指示を出したかを覚えておく必要がある。

ハーネスとは、ツール、ファイル、会話、実行を管理するAIモデル周辺のソフトウェアを指す。モデルがタスクについて推論し、ハーネスがタスクをモデルに届け、その処理を実行する方法を決める。Super-agentは、複数の作業を調整する責任の多くを、この周辺ソフトウェアに担わせる。

チームは4つの目標を掲げる。会話をまたいだ継続性、効率的な並列実行、イベントへの先回りした応答、そして障害から復旧できる継続的な稼働だ。例えば、開発者がチャットで方針を決め、後からGitHubのコメントで変更した場合、システムはそのやりとりを関連付けて同じタスクを更新する必要がある。

今回のリリースに先立ち、DeepSeekは10月3日、Harness v0.2.1-alpha.1でClaude Code拡張機能との互換性を試す実験を行った。この更新では拡張機能をつなぐ仕組みを検証したのに対し、Super-agentはハーネス自体が継続中の作業をどう調整できるかを探る。Yujia Qiaoがシステムの実装と設計文書の執筆を担当し、ほかに15人がレビューや議論への参加者として記載されている。

1つのRouterが調整し、複数のWorkerが実行

Super-agentは、常駐するRouterと個別のWorkerに役割を分ける。Routerは人とのやりとりを受け取り、タスク間で共有する情報を管理し、作業を割り当てる。コーディング自体は行わないため、ほかのセッションが作業中でも調整役を担い続けられる。

個々の作業はWorkerが担当する。それぞれが独自の会話コンテキストと実行ツールを持つため、バグ調査、コードレビューへの対応、機能変更を並行して進められる。Workerは結果をRouterに報告し、複数のセッションがそれぞれ独立して返信するのではなく、Routerが人とやりとりする。

DeepSeekによると、振り分けには軽量なモデルで対応できる場合が多く、コード品質を左右する作業にはより高性能なモデルを使う。複雑な依頼ではWorkerが補助エージェントを作成することもできる。Routerは、各作業の手順をすべて計画するのではなく、タスク間の関係を管理する。

プロトタイプでは、各作業項目に専用のセッションとディレクトリを割り当て、設定した上限まで同時に起動する。そのため、運用者は並行して開始する作業量を制御できる。会話履歴を分けることで、あるタスクの詳細が別のタスクを圧迫する可能性を抑えつつ、Routerが全体を見渡せる状態を保つ。

絶え間ない割り込みを避けながら、メッセージをタスクに変える

チャットメッセージ、コードレビューのコメント、自動テストの結果は、アクションを起こすきっかけとなるイベントになる。より広い設計では、メールやカレンダーのリマインダーも想定している。継続的インテグレーション（CI）とは、変更後のコードをビルドまたはテストする自動チェックを指し、エージェントが対応できる結果を生成する。

DeepSeekは、2段階でイベントを絞り込む。まず通常のプログラム規則で、発信元、グループ、許可されたユーザーなどを確認する。その後、モデルがコンテキストと文書化されたポリシーに基づいて、残った候補を評価する。対応不要の定型メッセージに対するモデル呼び出しを減らせる。

関連するイベントは、1つのプルリクエストに付いたコメントや、1つのチャットトピックなどの単位で「Thread」にまとめられる。Workerが担当を引き受けると、そのThreadを購読する。後から追加されたコメントやテスト結果は、Routerに再割り当てを求めず、直接Workerに届く。

複数のWorkerが同じThreadを購読することもある。同じプルリクエストに関わる複数のWorkerが更新を受け取ることで、それぞれの作業に影響する変更を把握できる。Workerは関連する複数のThreadを追うことも、担当範囲外のイベントをRouterに戻すこともできる。

早めに動き、役立つときだけ伝える

DeepSeekによると、社内のSuper-agentはすでに継続稼働し、問題の再現と修正、コードレビューへの対応、Harness自体の開発支援を行っている。文書化されたルールにより、グループチャットでバグが言及されれば、エージェントに直接メンションされていなくても調査できる。

このルールでは、まず静かに調査する。報告された問題の再現を試み、簡単な修正方法を探してから、役立つ結果を提示する。ある例では、開発者がチルダが取り消し線の書式として表示される問題について話していたとき、エージェントはすでに修正案を含むプルリクエストを作成していた。

HarnessチームはREADMEで、運用の基本方針を次のように説明している。

人の注意をできるだけ使わず、できるだけ大きな価値を提供する。

プロトタイプが動作するのは、権限を持つ人から依頼があった場合、またはチームが定めたルールで許可された場合だ。Webパネルには、人の対応が必要な作業項目が表示される。あらゆるツール呼び出しや途中の思考ではなく、判断と利用可能な成果にインターフェースを集中させる。

過去のコンテキストと新しい指示を参照可能にする

DeepSeekの設計では、モデルが一度に扱える情報量に上限がある「コンテキストウィンドウ」をキャッシュのように捉える。頻繁に必要となる情報は手元に置き、長い履歴や関連性の低い情報は、必要になるまでウィンドウの外に残す。

設計文書では、この操作を「Inline」と「Spill」と呼ぶ。Inlineは、近くのチャットメッセージ、識別子、短いプレビューなど、役立つ詳細を現在のコンテキストに直接配置する。Spillは、長い内容を別の場所に置き、モデルがさらに読み進められる参照情報を残す。

「Chain of Recall」は、こうした参照情報をつなぐ。イベント、Thread、Workerのセッションには一意の識別子が付与され、エージェントは現在のメッセージからその議論、関連するWorker、さらに別のコードレビューへとたどれる。目的は、履歴全体を何度も読み込まずに、チャネルをまたいで過去のタスクを見つけられるようにすることだ。

DeepSeekは、より直接的な割り込みの問題にも対処する。長時間かかるコマンドが従来型のエージェントをふさぎ、応答できなくなる問題だ。非同期の仕組みでは、バックグラウンドで作業を開始し、結果を新しいイベントとして返す。ユーザーはその間も指示を続けられ、方針の変更や停止を求めることもできる。

チームによると、この仕組みはDeepSeek Harnessに実装されているが、デフォルトでは有効になっていない。チャネルごとにコミュニケーションのルールも異なる。設計では、インスタントメッセージへの返信を1回につき100語までとする一方、プルリクエストや文書では、変更内容と検証結果をより体系的に説明する。

クラウドで調整し、ローカルコンピューターで作業する

DeepSeekは、エージェントを動かす計算環境、保存されたセッション履歴、コマンドを実行するマシンを分離する。提案された構成では、エージェントの処理ループはクラウドコンテナで動作し、セッションの状態はデータベースに保存され、軽量なローカルサービスがコマンドを実行して結果を返す。

この構成は「Bring Your Own Machine（BYOM）」に対応する。開発者は、リポジトリ、ツール、未完了の変更を含む既存のコンピューターを接続でき、すべてを新たなリモート環境に移す必要がない。そのコンピューターが切断されている間もクラウド側の調整機能は利用でき、端末が必要なタスクは再接続されるまで待機する。

独立したWatchdogセッションが、障害や作業の停滞を確認する。単にエラーメッセージを検知するだけでなく、モデルの判断を使ってWorkerが実際に進んでいるか、目標から逸れていないかを評価し、必要に応じて復旧を試みる。

DeepSeekは、これらの要素をより広範なアーキテクチャの検討の一部として示している。READMEは、公開バンドルと内部実装が異なると注意を促しており、特定の設計機能を前提にする前に、開発者が公開コードを確認するよう求めている。

実験で測定した内容

DeepSeekは各実験設定を5回ずつ繰り返し、イベントを直接配信する機能のないSuper-agentと、補助エージェントを備えた単一セッションの2つの構成を比較した。作業負荷には、合成メッセージと、長時間のコーディング作業を模擬するツールを用いた。メッセージの間隔と作業時間は4分の1に短縮した。

中央値の12.4分は、タスクの半数がその時点までに完了したことを意味する。95パーセンタイルの15.7分は、95％がその時間内に完了したことを示す。中立的な指示を与えた単一セッションの95パーセンタイル29.5分と比べると、Super-agentはこの指標を13.8分、約47％短縮した。

委任の挙動が結果の背景を示している。中立的な指示の下では、単一セッションは5回の実行すべてで補助エージェントを呼び出さなかった。委任を優先するよう指示すると、4回は作業を委任し、残る1回は自ら処理した。Super-agentでは、調整と実行を分離することが構造上の選択となっている。

テストでは、シミュレーションによる実行を用いてスケジューリングと調整を評価した。実際のコーディング品質、独立した性能測定、実ユーザー数は公表されておらず、チーム自身も測定結果を予備的なものとしている。DeepSeekは製品版のリリース日を示していない。

調整の高速化にはキャッシュトークンの増加が伴う

Super-agentの並行処理では、キャッシュされた入力の使用量が増加した。キャッシュトークンの読み込み量は2,323万トークンで、単一セッションの2つの構成では605万、1,082万トークンだった。トークンはモデルが処理するテキストの小さな単位で、キャッシュ読み込みでは以前のリクエストから保持された入力を再利用する。

イベントの直接配信をなくすと、キャッシュ読み込み量は2,323万から3,177万に約37％増え、Routerの判断回数も約30％増加した。後続の情報を担当Workerに直接送ることで、並列処理の仕組みにおける調整作業を減らせた。

バッチ処理は、負荷が高い状況でのRouterの管理に役立った。イベントの到着頻度が毎分約1件から40件に増えると、平均バッチサイズは1.0から2.8に上昇し、リクエストの所要時間は2.5秒から3.9秒に延びた。一方、Routerの判断1回当たりに割り当てられた推論時間は6.4秒から1.6秒に減った。

実用面では、人の待ち時間を減らす一方、複数のセッションでモデル処理が増えるというトレードオフがある。トークン数は金額を示すものではない。導入を検討するチームは、モデルの料金、同時実行の設定、実際の作業負荷を考慮する必要がある。

ローカルの権限がセキュリティ上の重要課題に

プロトタイプの実行に関する文書によると、Workerのコマンドは運用者のOSアカウントで、承認なしに実行される。フォアグラウンドのシェルコマンドは5秒後にバックグラウンド実行へ移り、バックグラウンド処理には1ターン当たり最大30分が与えられる。そのため、運用者アカウントの権限は具体的な導入上の懸念となる。

接続されたマシンには、認証情報、非公開コード、機密ファイルが保存されている可能性がある。プロンプトインジェクションとは、エージェントが読み取る内容を通じて、悪意あるコンテンツがエージェントの動作を意図しない方向へ誘導しようとする攻撃だ。受信メッセージやリポジトリの内容がそのマシン上のコマンドに影響する場合、特に深刻な問題になる。

DeepSeekは、セキュリティとプライバシー、Routerのスケーリング、長期間にわたる記憶、エージェント間の通信を未解決の課題として挙げる。READMEでは、バグや一貫性に欠けるエンジニアリング手法が残っている可能性があるとして、コードの確認と改変を利用者に求めている。開発作業の多くは、コーディングエージェント自身によって行われた。

公開後、Hugging Faceのリサーチ責任者Leandro von Werraの投稿を含め、急速に注目が集まった。プロトタイプが短期間で広まった経緯は次の通りだ。

• 2026年10月31日09時32分（UTC）：GitHubリポジトリを作成。
• 10月31日：Harnessチームが設計文書を公開。同日22時10分までに、リポジトリは2,046個のスターと172件のフォークを獲得。
• 11月1日04時20分（UTC）：リポジトリのスター数が3,433に到達。

エンジニアリングチームにとって、当面の判断は、実験段階の調整システムを調査し、改変するかどうかだ。より少ない割り込みで多くの作業を処理できる可能性が魅力となる一方、コードの確認、権限の設定、人の判断を必要とする操作の選定が求められる。

要点

• DeepSeekは、単一のGitHubリポジトリでのコーディング作業向けに、Feishu連携を任意で利用できるMITライセンスの研究用プロトタイプを公開した。
• Routerが調整を担い、複数のWorkerがタスクを並行して実行する。
• 内部システムは、文書化されたルールに基づき、直接メンションされなくても報告されたバグを調査できる。
• 合成テストでは、完了時間の中央値が12.4分、95パーセンタイルが15.7分となった。一方、単一セッションの構成よりキャッシュトークンの使用量は多かった。
• Workerは運用者のアカウントで承認なしにコマンドを実行するため、権限と認証情報が重要な懸念事項となる。
• 公開コードは内部システムとは異なり、DeepSeekの公式製品ではなく研究用プロトタイプにとどまる。