DeepSeekのコーディングエージェント基盤「Harness」のチームが2026年10月31日、「dsh-superagent-prototype」というリポジトリをMITライセンスで公開した。GitHubのリポジトリとチャットを見張り、頼まれた仕事を自分で拾って、Pull Requestとして返してくるエージェントの試作品である。

新しいモデルの発表ではない。公開されたのは、モデルの外側にある「エージェントをどう組むか」の設計と実装だ。それでも、Claude や Cursor のようなコーディング支援AIを選ぶ読者にとっては、次に各社が競う場所がどこかを示す資料として読む価値がある。

⚠ 情報の鮮度について
一次情報はGitHub上のリポジトリのREADMEで、公開日は2026年10月31日です。同日から11月1日にかけて、AI Weekly、Startup Fortune、Developers Digestなどが内容を紹介しています。本記事は公開から1〜2日が経った時点の解説で、「何が出たか」より「選ぶ側にとって何を意味するか」に重心を置いています。READMEで確認できた事項と、解説記事の記述にとどまる事項は、本文で区別して書きます。

何が公開されたのか──モデルではなく「エージェントの組み方」

前提を整理しておく。DeepSeekは2026年8月13日に、エージェントを動かすための土台「Harness」(略称dsh)をMITライセンスで公開している。Harnessは、モデルとの接続、道具、セッション、サンドボックス(隔離された実行環境)などを部品として差し替えられる作りになっていて、開発者向けのプレビュー版という位置づけだ。

今回のdsh-superagent-prototypeは、そのHarnessの上に乗る別のリポジトリである。READMEの説明を要約すると次のようになる。

01
対象は「1つのGitHubリポジトリ」

見張る対象は1つのリポジトリで、任意でFeishu(中国発のビジネスチャット)も入力元にできる。社内の全コードを横断して動くものではない。

02
許可された人の依頼で動き出す

許可された人が頼むと作業項目(work item)を作り、専用のエージェントセッションと作業ディレクトリで処理して、依頼のあった会話の中に結果を返す。結果の例が、Pull Requestだ。

03
人の注意は「画面」に集める

人の判断が要るものは、Webパネルに一覧で出る。READMEが掲げる方針は、人の注意を極力使わず、そのうえで価値を最大にすることだ。

一言でまとめると──「チャットで頼むたびにAIが一往復する道具」から、「見張り役が常駐して、仕事の受付から実行までを回す仕組み」へ。その最初の設計図が、MITライセンスで公開されました。

dsh-superagentとは──Router(受付)とWorker(作業員)の二層構造

この試作品の名前の由来は、READMEが引く設計論文のタイトル「Exploring Super-agent Design: Towards a More Autonomous Agent System」にある。論文へのリンクはREADMEに無く、全文は確認できていない。以下の二層構造の説明は、AI Weekly、Startup Fortune、Developers Digestの3本の解説に共通する内容だ。

Router

常駐する受付役 GitHubやFeishuから届く依頼を一手に受け、許可された人のものかを確かめて、引き受けるかどうかを決める。利用者との会話はここが担当する。

Worker

仕事ごとに分かれた作業員 引き受けた仕事ごとに、隔離されたセッションが立ち上がる。道具は一通り使えるが、結果は人ではなくRouterに報告し、Routerが元の会話に返す。

この分け方の利点は、受付が作業で塞がらないことにある。長い作業の最中に別の依頼やコメントが届いても、受付役は応答し続けられる。人間のチームで、窓口担当と実務担当を分けるのと同じ発想だ。解説記事のひとつは、Routerには軽いモデルを当てるやり方も考えられると述べているが、これは筆者の見解であり、READMEには対応モデルの記載が見当たらない。

ⓘ「常駐」と「自動で何でもやる」は別物です
READMEによれば、このエージェントが動くのは「頼まれたとき」か「チームが書いたルールが許可したとき」だけです。解説記事(Startup Fortune)も、無制限に回り続ける自律ループではなく、リポジトリで起きる出来事に反応して動く設計だと説明しています。つまり、勝手に何でも始めるのではなく、誰の依頼を受け付けるかを決める部分が設計の中心にあります。

「公式製品ではない」と書かれている意味

READMEの冒頭近くには、はっきりした断り書きがある。

研究用のプロトタイプであり、参考用にとどまる。DeepSeekの公式製品ではない。本番利用を前提としたソフトウェアではなく、研究用のコードとして扱ってほしい。

— READMEの注意書きの要約(2026年10月31日公開版)

READMEはさらに、バグが残っている可能性があること、コードの書き方が揃っていない可能性があることを自ら挙げ、自分の環境で使う前に見直して調整するよう求めている。社内で動いているものと同一ではなく、設計論文に書かれた内容の一部は未実装だとも明記されている。

AI Weeklyによれば、READMEには、開発の多くをコーディングエージェントが担ったという趣旨の記述もある。AIで使う道具を、AIに作らせて出す。このジャンルの現在地がよく表れている。

⚠ 試す前に押さえておきたい安全面の指摘
Developers Digestの解説は、Workerがユーザーの承認を挟まずに、運用者のOSユーザー権限でコマンドを実行する点を指摘しています。同記事はあわせて、禁止コマンドの一覧は初期設定にすぎず、安全の境界ではないこと、外部からのイベントを受ける常駐エージェントはプロンプトインジェクション(文章に紛れ込ませた命令で乗っ取る手口)にさらされることも述べています。これらはREADMEの本文では確認できておらず、解説記事の記述として扱ってください。Harnessの側についても、Startup Fortuneは、セキュリティ監査を受けておらず、隔離や承認の仕組みが分離を保証するものではないと伝えています。

以上を踏まえると、このリポジトリは「導入して使う製品」ではなく「読んで構造を学び、隔離した環境で試す教材」と見るのが妥当だ。

ClaudeやCursorを選ぶ人にとって、何が変わるのか

今日のコーディング支援AIの多くは、人が画面の前で指示して、返事を待つ使い方が中心だ。dsh-superagentが示したのは、その次の段階である。人が指示する場所が、エディタではなくリポジトリやチャットの側に移る。

同じ方向の動きは、すでにこのサイトでも取り上げている。Anthropicが公開した、向こうから話しかけてくるエージェント「Claude Duet」や、PRを自分で追いかけるようになったCursorのクラウドエージェントがそうだ。今回の違いは、中身を読んで改造できる形で出てきたことにある。

A
今のツールで足りている人:何も変えなくてよい

エディタ上でClaudeやCursorに指示して使っているなら、今回の公開で乗り換える理由は生まれない。対応モデルや性能の数字もREADMEには無く、比べる材料自体が無い。

B
常駐型に関心がある人:今は「読む」段階

ClaudeやCursorの常駐型機能の登場を待つあいだに、設計を読んでおく価値はある。誰の依頼を受けるのか、結果をどこに返すのかといった部分は、製品を選ぶときの質問にそのまま使える。

C
社内の開発を預かる人:試すなら使い捨ての環境で

本番のリポジトリや認証情報に繋がない。権限を最小にしたユーザーで、価値のないテスト用リポジトリに向けて動かす。READMEの「環境に合わせて見直す」という要求は、ここに最初に当てはまる。

💡 常駐型エージェントを見るときの3つの質問
1. 誰の依頼を受け付けるのか(許可の仕組みがあるか)。2. 作業員は何の権限で動くのか(承認なしでコマンドを実行できるか)。3. 結果はどこに返るのか(Pull Requestで人の目を通るのか、自動で取り込まれるのか)。どの製品でも、この3点が書かれていなければ、安全面の説明が足りていません。

編集部の見立て

Editor's Opinion

この公開でいちばん価値が高いのは、完成度ではなくREADMEの正直さだと考えます。参考用であること、バグがありうること、社内版と同じではないこと、設計論文の一部は未実装であること。普通なら隠したくなる点を先に並べていて、試作品として何を信用してよいかが読み取りやすくなっています。

一方で、解説記事が指摘する承認なしの実行は、常駐型に共通する難しさをそのまま示しています。人が画面の前にいない以上、承認ダイアログで止めるやり方は成り立ちません。止める役を誰が担うのかは、これからの各社の差になりそうです。

READMEで確認できた事実と解説記事の記述は、分けて書きました。READMEには性能の数字が無く、解説記事のものは条件が食い違うため、ここには載せていません。速さや賢さを比べられる材料が出るまでは、乗り換えの判断をする段階ではないと考えています。

まとめ

2026年10月31日、DeepSeekのHarnessチームが、常駐型のコーディングエージェント「dsh-superagent-prototype」をMITライセンスで公開しました。GitHubの1つのリポジトリとFeishuを見張り、許可された人の依頼を受けて、Pull Requestなどの形で返す試作品です。

解説記事によれば、構造は常駐するRouterと、仕事ごとに隔離されたWorkerの二層です。READMEは、公式製品ではなく、本番利用を前提とせず、一部は未実装だと自ら断っています。

安全面では、Workerが承認なしでコマンドを実行する点などが解説記事で指摘されています。READMEで確認できていないため、試すなら使い捨ての環境と最小の権限が前提になります。

次に確かめたいのは、READMEが挙げる認可(Authorization)と実行(Execution)の文書で、誰の依頼を受け、何の権限で動くのかがどこまで書かれているかだ。ここが固まった時点で、ClaudeやCursorの常駐型機能と同じ物差しで比べられるようになる。