資料確認：2026年11月3日。公式GitHubの初回コミット表示は10月31日です。公開時刻や別の正式発表日は確認できていません。
AIに開発を頼んだ後、別の会話へ進捗を運び、返答待ちを見張る。そこまで人が担当すると、「任せた仕事」が新しい管理仕事になります。DeepSeek公式GitHubに公開された dsh-superagent-prototype は、その運搬を減らす常駐型コーディングエージェントの研究試作です。
ただしREADMEは、正式なDeepSeek製品ではなく、本番対応のソフトウェアでもないと明記しています。ここでは公開文書の設計を読みます。導入・実行・性能評価はしていません。
1．入口と、仕事ごとの実行を分ける
READMEでは、1つのGitHubリポジトリを対象に、GitHubと必要に応じてFeishuから情報を受け取る構成です。許可された依頼から仕事を起こし、それぞれ専用のセッションとディレクトリで進め、元の会話へ結果を戻すと説明しています。[1]
Domain modelでは、出来事を受けるSource、受付判断のEval、認められた仕事のTicket、実行を結び付けるAssignmentを分けます。[2] 技術的な読みどころは、会話のスレッドと仕事を一対一に決めつけず、何の依頼を、どの担当実行が扱うかを別に残すことです。
これは「複数AIなら自動で正しく分担できる」という実証ではありません。役割を分けた設計資料が公開された、と読むのが適切です。
2．関連情報を読んでも、権限まで広げない
Authorization文書は、メッセージ・コメント・引用文書を判断の入力として扱い、それらが権限を変更するわけではないと説明します。関連スレッドから届く情報も、元の仕事に認められた範囲を広げません。[3]
推測から始める仕事については、既定の observe が「受け付けるだろう」と判断した記録を残しても、実際には受け付けない設計です。一方、明示的な依頼は別扱いです。observeは、あらゆる実行を止める全体スイッチではありません。 [3]
コードや文章を読ませる権限、変更を加える権限、外へ送る権限を別に考える。この区別は、導入前に仕事の仕様を書くときにも使えます。
3．フォルダ分離と安全隔離、レビュー待ちと完了を分ける
Execution文書には大切な限定があります。作業ディレクトリやコマンドのラッパーは既定値を整えるもので、セキュリティ境界ではないとされています。絶対パスで別のプログラムを動かせることも説明されています。[4]
同じ文書では、プルリクエストを伴う ready はレビュー待ちとして扱われます。また、自動マージの判断をプロンプトへ任せる部分と、GitHubのブランチ保護で承認を強制する部分は別です。[4] 「AIが準備できたと言った」と「承認条件がシステムで強制された」を混ぜないことが重要です。
自分の開発へ持ち帰るための設計メモ
以下はこの記事独自の架空例です。DSHの設定形式でも、自動実行されるコードでもありません。
job: review_one_patch
input: 公開可能な架空の差分と受入条件
allowed: 差分を読み、修正案と確認すべき点を作る
approval_required: コミット、プッシュ、公開、マージ
review_ready: 修正案・確認結果・未確認事項がそろった
verified_complete: 完成物と外部の反映結果を担当者が確認した
最初に確かめるのは、同じ入力が再び届いた時に二重の仕事にならないか、停止後に外部操作が残っていないか、人のレビュー待ちを完了に数えていないか、の3点です。この確認案は未実施で、試作の安全性や冪等性を保証しません。
まとめ
面白いのは、常駐すること自体より、依頼の入口・認める範囲・仕事の状態を分ける設計です。今日の一歩は、架空の開発仕事を1つ選び、「読ませる情報」「任せる操作」「完了の証拠」を一行ずつ書くこと。試作を導入しなくても、依頼の曖昧さを減らす準備はできます。
出典と確認範囲
- 公式README — 研究試作・正式製品ではないこと、対象と構成。
- 公式Domain model — 仕事と実行の分離。
- 公式Authorization — 文脈と権限、observeと明示依頼。
- 公式Execution — レビュー、隔離の限定、マージ。
- 公式コミット履歴 — 初回コミット表示2026年10月31日。
図は独自の概念図、表紙はAI生成イラストです。製品画面・実証結果ではありません。文書読解とコードの動作確認は別で、本稿ではリポジトリのテストを実行していません。MITライセンス表記を確認しましたが、本人環境への導入・新規契約・課金はしていません。
文章業務の依頼文と確認手順を整えたい方へ
開発エージェントの導入ではなく、問い合わせ返信の下書きや日報要約など、文章業務1種類の入力ひな形・専用プロンプト・人の確認手順を整理する相談先です。実務プロンプトと運用手順マニュアルの作成。プログラミング、DSHやAPIへの実装、アカウント操作、自動送信は含みません。