DeepSeekの常駐AI試作を読む：仕事の受付・権限・レビュー待ちを分ける
シン＠AI統制＆マルチエージェント
資料確認：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]
初稿：2026年11月3日。資料を11月8日に再確認。公式GitHubの初回コミット表示は10月31日です。公開時刻や別の正式発表日は確認できていません。
同じ文書では、プルリクエストを伴う ready はレビュー待ちとして扱われます。また、自動マージの判断をプロンプトへ任せる部分と、GitHubのブランチ保護で承認を強制する部分は別です。[4] 「AIが準備できたと言った」と「承認条件がシステムで強制された」を混ぜないことが重要です。
自分の開発へ持ち帰るための設計メモ
以下はこの記事独自の架空例です。DSHの設定形式でも、自動実行されるコードでもありません。
対象：架空の差分1件。許可：差分を読み、修正案と確認点を作る。要承認：コミット・プッシュ・公開・マージ。レビュー待ち：修正案・確認結果・未確認点がそろう。完了：担当者が完成物と外部への反映を確認する。
最初に確かめるのは、同じ入力が再び届いた時に二重の仕事にならないか、停止後に外部操作が残っていないか、人のレビュー待ちを完了に数えていないか、の3点です。この確認案は未実施で、試作の安全性や冪等性を保証しません。
まとめ
面白いのは、常駐すること自体より、依頼の入口・認める範囲・仕事の状態を分ける設計です。今日の一歩は、架空の開発仕事を1つ選び、「読ませる情報」「任せる操作」「完了の証拠」を一行ずつ書くこと。試作を導入しなくても、依頼の曖昧さを減らす準備はできます。
出典と確認範囲
1. 公式README — 研究試作・正式製品ではないこと、対象と構成。2. 公式Domain model — 仕事と実行の分離。3. 公式Authorization — 文脈と権限、observeと明示依頼。4. 公式Execution — レビュー、隔離の限定、マージ。5. 公式コミット履歴 — 初回コミット表示2026年10月31日。
図は独自の概念図、表紙はAI生成イラストです。製品画面や実証結果ではありません。本稿ではリポジトリのテスト、本人環境への導入、契約や課金は行っていません。
この記事の販売者
