DeepSeekは2026年10月31日、複数の作業を並行して進めるAIエージェント「Super-agent」の設計と、常駐型コーディングエージェントの研究用コードを公開した。単一のGitHubリポジトリを担当し、依頼や通知を受け取りながら個々の作業を進める仕組みだ。正式な製品ではなく、社内で使用しているバージョンとも異なるが、複数のAIを並列に動かすだけでなく、人が会話を逐一監督せずに仕事を任せるための設計が明らかになった。その中核にあるのは、新しい仕事を始めるための許可と、進行中の仕事に情報を追加する処理を分離する考え方だ。例えば、CI（継続的インテグレーション）の実行結果が届いても、その通知だけで新たな修正作業まで許可されたことにはならない。
1つのリポジトリに常駐する研究試作
DeepSeekがGitHubで公開した「dsh-superagent」は、単一のGitHubリポジトリを対象とする常駐型コーディングエージェントだ。任意で業務チャットのFeishuにも接続でき、許可されたユーザーからの依頼や、チームが事前に定めたルールに従って作業を開始する。成果はプルリクエスト（PR）などの形で、依頼があった元の会話に報告する。コードはMITライセンスで公開されているものの、READMEには正式製品でも本番運用に対応した実装でもないと明記されている。公開用に調整されたコードであり、設計記事で説明されている構想の一部はまだ実装されていない。
システムは大きく「調整役」と「作業担当」に分かれる。調整役はGitHubなどから届く依頼や通知を受け取り、仕事を振り分けるとともに、人とのやり取りを担当する。一方、作業担当は個々の仕事に割り当てられた独立したセッションで、具体的なコードの修正などを進める。全体の状況を把握して仕事を管理する役割と、実際の作業を進める役割を分離することで、複数の依頼を並行して処理する構成だ。
特徴的なのは、仕事の状態をAIとの会話だけで管理しない点にある。設計文書で「Ticket」と呼ばれる作業票には、許可された作業範囲や、許可を判断した際に適用された方針のバージョンが記録される。作業票と実行担当者、実行セッションの関係は別に管理されるため、会話やセッションが終了しても、仕事そのものの状態は独立して保持される。これにより、作業の途中で情報を追加したり、再起動後に処理を復旧したりする際にも、何を依頼され、どこまで許可されていたかを確認できる。
単に会話の続きを別のAIへ引き継ぐ方式では、依頼内容と実行セッションの状態が密接に結び付きやすい。これに対してDeepSeekの設計では、作業票を独立させることで、担当するセッションが変わっても仕事の内容と権限を追跡できるようにしている。複数のAIに会話を振り分けること自体よりも、個々の仕事を継続的に管理できることを重視した仕組みといえる。
新しい仕事の許可と、進行中の仕事への情報追加を分離
DeepSeekの権限管理に関する設計文書では、新しい仕事を開始する際の判断と、既存の仕事に情報を届ける処理が明確に分けられている。後者を担うのが「Subscription（購読）」と呼ばれる仕組みで、作業担当は購読しているスレッドに新しい発言が届くと、その内容を受け取れる。人のメッセージだけでなく、botやCIからの通知も対象となる。ただし、情報が届いたことは新しい作業の許可を意味せず、作業担当は当初認められた範囲内でしか仕事を進められない。
例えば、コード修正を担当しているAIにCIの失敗通知が届けば、その情報を現在の作業に反映できる。一方、同じスレッドに別の機能の改修依頼が書き込まれた場合、元の許可範囲を超えるなら、そのまま新しい仕事として引き受けることはできない。作業担当は依頼を調整役へ差し戻し、必要に応じて改めて許可を判断する。調整役から送られる補足情報も新しい権限を与えるものではなく、終了した作業を再開する際には権限の有効性を再確認する。通知を受け取る経路と、仕事を引き受ける権限を分けることで、会話が続くうちにAIの作業範囲が無制限に広がることを防ぐ設計だ。
作業票には、許可された範囲だけでなく、その判断に使われた方針のバージョンも記録される。そのため、後から届いたメッセージだけを根拠に権限を判断し直すのではなく、当初の許可内容に照らして対応できる。同じスレッドに届いた発言でも、進行中の仕事に必要な情報なのか、新たな許可を要する依頼なのかによって扱いが変わる。
新しい仕事の受付には、off、observe、autoという3つのモードが用意されており、既定値はobserveだ。このモードでは、AIが自律的に見つけた作業候補について、着手する条件を満たすかどうかを評価して記録するが、実際の作業は開始しない。offでは自動的に推定された作業候補を受け付けず、autoでは条件を満たした候補について自動的に着手できる。ただし、許可されたユーザーからの明示的な依頼は、どのモードでも受け付けるため、observeはすべての作業を停止する設定ではない。また、autoで自動的に仕事を始める場合も、事前に定められた有効なルールに少なくとも1つ一致する必要がある。
こうした権限管理は、AIが端末上で実行できる操作を制限する仕組みとは別のものだ。新しい仕事の受付、既存の仕事への情報追加、端末でのコマンド実行、成果物の取り込みには、それぞれ異なる安全上の境界がある。DeepSeekの権限管理、実行制御、導入・運用に関する文書を基に、それぞれの役割と制約を整理すると次のようになる。
| 管理対象 | 公開試作で管理されること | 別途対策が必要なこと |
|---|---|---|
| 新しい仕事の受付 | 依頼者や事前のルールを確認し、許可された作業範囲を記録する | 端末上でアクセスできるファイルや認証情報の制限 |
| 既存の仕事への情報追加 | 購読しているスレッドの発言やCI結果を作業担当へ送る | 新しい仕事や許可範囲外の操作を実行するための権限 |
| 端末でのコマンド実行 | 実行プロセスのOSユーザー権限でコマンドを実行する | OSレベルの隔離。専用ディレクトリやコマンドのラッパーだけでは隔離できない |
| 成果物の取り込み | プロンプトを通じて自動マージの条件を指定する | 実行基盤によるマージ専用の強制的な判定機構。GitHub側のブランチ保護設定が必要 |
この区別は、公開試作の設計上の責任範囲を整理したものであり、システム全体の安全性が実証されたことを意味しない。AIに仕事を依頼できるユーザーを制限しても、AIが動作するプロセスのアクセス権限まで制限されるわけではない。仕事を始める権限と、実行環境で許される操作の範囲は、それぞれ適切に管理する必要がある。
5秒でコマンドをバックグラウンド化、人の介入用に実行枠を確保
DeepSeekの実行制御に関する仕様では、調整役と作業担当が実行するシェルコマンドは、前面での実行が5秒を超えるとバックグラウンド処理へ移行する。これは5秒以内に仕事が終わるという性能上の目標ではなく、長時間かかるコマンドの完了を待つ間も、AIが新しいメッセージを受け取れるようにする仕組みだ。ビルドやテストなどの処理を待ち続けることで、他のやり取りまで止まってしまう状況を避ける狙いがある。
作業票ごとに専用の実行セッションとディレクトリが割り当てられ、個々の仕事は独立した環境で進められる。ただし、コマンドがバックグラウンドに移行しても、作業担当が使用している同時実行枠は解放されない。バックグラウンド処理を増やすことで、設定された同時実行数の上限を回避できるわけではない。CIなどから届く自動通知によって作業を再開する場合も、通常の実行枠が空くまで待つことになる。
これに対して、人からのメッセージや状況確認の要求には、通常の同時実行上限とは別に追加の1枠が用意されている。通常の枠がすべて埋まっていても、人が進行中の仕事に介入するための余地を確保する設計だ。大量の作業を同時に処理できても、人が途中で停止を指示したり、状況を確認したりできなければ、かえって管理が難しくなる。この追加枠はそうした事態を避けるためのものだが、常に即座に応答できることまで保証するわけではない。
ここで重要なのは、長時間実行するコマンドの待機、同時に動かせる作業数、人の介入を受け付ける余地が、それぞれ別の仕組みで管理されていることだ。コマンドをバックグラウンドへ移しても実行枠は空かず、介入用の枠を追加しても個々の仕事の処理時間が短くなるわけではない。単純な並列実行数だけでなく、どの処理を待たせ、どの要求を優先するかまで設計されている。
複数の仕事を継続的に管理するには、処理の状態を確実に記録する仕組みも欠かせない。内部アーキテクチャの仕様によると、仕事や判断に関する状態変更は「Engine」と呼ばれる処理部に集約され、SQLiteのトランザクションを使って保存される。作業担当がそれぞれ全体の状態を直接書き換えるのではなく、変更を確定する経路を一元化している。これにより、複数の仕事が同時に進行しても、記録の整合性を維持しやすくなる。
外部システムへの操作についても、まず内部の記録を保存し、トランザクションの確定後に処理を実行する構成だ。これにより、システムがどのような操作を決定し、何を実行しようとしたのかを追跡できる。ただし、内部の状態を復元できることと、GitHubなどへの操作を安全に再実行できることは別の問題である。記録が残っていても、外部への操作が必ず一度だけ実行されるとは限らない。
そのため、再起動後は作業担当に復旧用の情報を渡し、外部操作を繰り返す前に作業ディレクトリやGitの履歴、GitHub上の結果を確認するよう指示する。処理に失敗した仕事や、問題が発生して続行できなくなった仕事には、自動通知による入力を保留する仕組みもある。CIが成功したという通知だけをきっかけに、停止中の仕事を無条件で再開するわけではない。常駐型エージェントには、処理を継続する能力だけでなく、復旧できる仕事と人の確認を待つべき仕事を区別する能力も求められる。
模擬実験では作業完了まで中央値12.4分
DeepSeek製品部が公開したSuper-agentの設計記事では、複数のエージェントを管理する方式の違いを、合成負荷を使った実験で比較している。実験では、1回当たり約300件のメッセージを処理させ、そのうち約20件を実際の作業依頼とした。各方式について5回ずつ実行し、コーディング作業は一定時間を消費する模擬ツールに置き換えた。また、メッセージの到着間隔と作業時間は実際の想定値の4分の1に圧縮し、AIモデルの呼び出しにかかる時間には実測値を使用した。したがって、この実験が測定しているのは仕事の振り分けや調整にかかる時間であり、実際のコーディング能力ではない。
実験結果によると、Super-agentでは依頼から完了までの時間が中央値で12.4分、95パーセンタイル値（p95）で15.7分だった。一方、単一のセッションから必要に応じてサブエージェントを呼び出す方式では、中立的な指示を与えた場合のp95が29.5分となった。この比較対象では5回の実験を通じてサブエージェントが一度も呼び出されず、すべての仕事がメインセッションで処理されていた。
また、進行中の仕事に通知を直接転送する仕組みを取り除いた場合、作業完了までの時間はほとんど変わらなかったものの、調整役による判断の回数が約30%増加した。キャッシュから読み込むトークン数も2,323万から3,177万へと約37%増えている。ただし、これはキャッシュ読み込みトークンの増加率であり、全トークン消費量や実際の請求額が同じ割合で増加したことを意味しない。実験はあくまで限定された合成負荷によるもので、実際の開発現場におけるコード品質や作業速度の優劣まで示すものではない。
実用化にはOSレベルの隔離とGitHub側の保護が必要
公開試作にはOSレベルの隔離機構が組み込まれておらず、DeepSeekの導入・運用に関する文書では、専用のOSアカウントで実行するなどの対策を推奨している。作業担当が実行するコマンドは、実行プロセスのOSユーザー権限で動作し、操作のたびに承認を求めることはない。作業ごとに専用ディレクトリを設けても、その外側にあるファイルへのアクセスが制限されるわけではない。そのため、AIエージェントに利用させるファイルや認証情報については、実行プロセスに与える権限を含めて管理する必要がある。
特定のコマンドを制限するラッパーも、それ自体が強制的な安全境界になるわけではない。実行ファイルを絶対パスで指定すれば、ラッパーを経由せずにコマンドを起動できるためだ。AIが何をしてよいかを記録する権限管理と、OS側で実際にアクセスできる範囲を制限する仕組みは、両方を用意する必要がある。
成果物の取り込みについても、同様の区別がある。公開試作では、自動マージの条件を「Delivery requirements」というプロンプトで指定するが、実行基盤にはマージだけを対象とする強制的な判定機構がない。DeepSeekはGitHub側でブランチ保護を設定し、必要な承認を要求するとともに、変更内容が更新された場合には古い承認を無効にすることを推奨している。AIにマージ条件を守るよう指示するだけでなく、条件を満たさない変更をGitHub側でも取り込めないようにする必要がある。
DeepSeekが設計方針として掲げるのは、人がAIの管理に費やす注意や時間をできるだけ減らすことだ。許可された範囲を維持しながら必要な情報を届け、人の介入や障害からの復旧を管理する仕組みは、通知の確認や作業の振り分けに伴う負担を減らす可能性がある。ただし、現時点で示されている性能評価は合成負荷によるものであり、実際の開発業務における成功率や総運用費用、人によるレビュー時間がどれほど改善するかは明らかになっていない。こうした効果を実環境で確認し、安全な実行環境と適切な承認手続きを整えられるかが、常駐型AIエージェントの実用化に向けた重要な課題となる。
