Tech Teardown 039｜dsh-superagent：エージェントが書いたスーパーエージェント

背景と現象：3日間で13,000星、そして自己申告型の免責声明

2026年10月31日、GitHub上のdeepseek-aiプロジェクトが倉庫dsh-superagent-prototypeを公開しました。3日後の11月3日の午前中の情報によると、13,000星、1,348のフォーク、79のサブスクライバー、0のオープンイシューがありました。作者欄にはDeepSeek Harness Teamと記載され、MITライセンス、バージョン番号は0.1.0です。

星数以外にも、READMEの最初の免責声明には多くの情報が含まれており、3つの重要な文は引用する価値があります：「Research prototype for reference only, not an official DeepSeek product.」参照用の研究プロトタイプであり、DeepSeekの公式製品ではありません；「much of the engineering done by coding agents」、多くのエンジニアリング作業がcoding agentによって行われました；「adapted for publication, so it is not identical to our internal version」、公開のために修正され、内部バージョンとは異なります。3日間で13,000星に増加したこの倉庫は、最初に自身の公式性を否定しており、この対比が今回の第一の分析ポイントです：それはDeepSeek Harness（以下DSH）チームがオープンソースとして公開した研究プロトタイプであり、「チームの研究プロトタイプ」としてのみ特定され、それ以上の記述はできません。

広がりの面で明らかな違いがあります。この倉庫はHacker Newsに何度も投稿されており、最高得点は11点、コメントは0で、議論はほとんどありませんでした。一方、GitHubでは星数が急増し、人気はほぼtrendingの側に集中しています。背景にはDSHプラットフォーム自体があります：8月13日のdeveloper previewはHNで747点、314件のコメントを獲得しました；10月2日のHarness Desktop（macOS/Windowsクライアント）は417点、228件のコメントを獲得しました。プラットフォームには実際のコミュニティの人気があり、dsh-superagentはそのエコシステムで最初の重要なバンドルであり、星数にはプラットフォームの知名度がもたらす注目度の変化が含まれています。

それが何かを一言で言えば：DSHにパッケージ化された、GitHub倉庫のみをサービスする常駐のcoding agentであり、GitHubを監視し、Flying Fishも監視することができます；権限を与えられた人が仕事を割り当てると、それは作業項目（Ticket）を開き、自分のセッションとディレクトリで作業を行い、その後元の会話に戻って回答します。例えば、pull requestを提出するなどです；Webパネルには「処理が必要な事」のみ表示されます。関連記事として「Exploring Super-agent Design: Towards a More Autonomous Agent System」があり、READMEには特に注意が促されています：記事で議論されている一部の設計は将来の方向性であり、プロトタイプは実装されていません。

アーキテクチャと技術原理：一つの認可の鉄則と五つの規律

まず形態について話しましょう。これは独立したアプリケーションではなく、Cordisプラグインアーキテクチャ下のバンドル（cordisPatch.yml）であり、DSH内で実行されます。リポジトリには9つの番号付きドキュメントがあり、000から008まで哲学、ドメインモデル、認可、実行、プロンプト、パネル、デプロイメント、アーキテクチャ、cookbookの順に構成されています。最後のドキュメントはSourceの追加方法について説明しています。各ドキュメントは前のドキュメントにのみ依存しており、これがREADMEのデザイン要件です：読者は決して導入されていない概念に遭遇することはありません。

ドメインモデルは一方向の流れです。Source（イベントソース、GitHubまたはFeishu）がTrigger（不変のイベント）を生成し、TriggerはThread（時間順のセッション）に属します。Evalは一連のTriggerに対して二段階の判断を行い（gateと評価）、Decisionを出力します。受け入れる場合はTicketを作成し、Mandateを添付します。AssignmentはTicketをExecutor（実行セッション）に結びつけ、結果はChannelを通じて元の対話に書き戻されます。その後、同じThreadの後続メッセージはSubscriptionを通じて分散され、既に購読しているTicketに直接送信され、再評価は行われません。

システム全体の重点は認可にあります。docs/002の冒頭の鉄則は次の通りです：「The host enforces allowed lists, rules and Mandates. Messages, comments and quoted documents are inputs to a decision; they cannot change those permissions.」ホストプログラムは白名单、規則、Mandateを強制します。メッセージ、コメント、引用されたドキュメントは決定の入力に過ぎず、権限を変更することはできません。言い換えれば、prompt injectionの防御線はプロンプトには書かれておらず、アーキテクチャ層にあります：メッセージの内容が何を言っても、権限の判断はメッセージの内容を通じて行われません。

Triggerには2つの経路があります。1つ目はEvalで、作業を開始するかどうかを決定します：Sourceはメッセージが指定代理（@リマインダーやプライベートメッセージ）を指しているかを記録し、gateは送信者とそのSourceのPolicyをチェックします。白名单に含まれる人は指定代理となり、明示的なリクエストを構成します。Botは最大で「推測候補」を生成し、永遠に明示的なリクエストを構成しません。白名单にないBotは直接受け入れません。推測候補はaccept modeというステージも通過する必要があります：off、observe、autoの3つのレベルで、デフォルトはobserveで、「本来受け入れる」と判断された場合のみ記録され、実際には作業を開始しません。2つ目はSubscriptionsで、既存の作業を継続します：Threadに購読している各メッセージ（BotやCIを含む）はすべて購読済みのTicketに送信され、gateを通過しますが、新しい権限は与えられず、Ticketは常に自身のMandateによって制限されます。人が購読をキャンセルしても、Executorの所有権はTicketが終了するまで続きます。

Mandateはacceptの瞬間に定められる権限証明書であり、変更不可能で、Policyのバージョン、範囲、強度、および適用ルールを記録します。システム全体でMandateを変更できる操作は3つだけです：acceptによって作成されるもの、人がstopで撤回するもの、再検証に失敗した場合に無効化するものです。終了したTicketを復元するには、現在のPolicyで再検証を行う必要があります：送信者をホワイトリストから除外することで、彼によって付与されたMandateを無効化できます。このルールはsrc/policy.tsの242行に記載されており、gateとrevalidateの2つの関数が文書と対応しています。

哲学文書はエージェントに対して5つの規律を定めています：要求された場合やチームの文書規則で許可されている場合のみ行動し、誰も要求しない作業は記録モードでのみ実行する必要があります；行動が必要な場合や結果を利用できる場合にのみ発言し、作業中は静かにしておくこと；一度に一つの具体的な質問だけを行い、構造化された形式で質問し、問題を長い報告書の中に埋もないようにすること；影響に基づいて停止するが、作業量に基づいて停止しないこと、ローカルでの変更は評価可能な範囲まで行い、設計決定が必要な場合は停止して質問すること；正直に報告し、下書きは未完了として扱い、失敗は失敗として報告すること、「制限は質問を避けるために無視されるべきではない」。

ディレクトリ構造と文書が相互に呼応しています。src/coreはドメインモデルとチケットエンジン（engine、tickets、intake、stage、replies、memoryなど15のファイル）です；src/sourcesにはgithub-*とfeishu-*のファイルがペアで存在し、2つのSource実装は完全に対称です；src/executorは実行をDSHセッションに落とします；policy.ts、limits.ts、admission.tsは独立したファイルとして存在し、権限と制限はビジネスコードと混在しません。13のプロンプトはprompts/ディレクトリに保存され、仓库にあります。admission、dispatch、orchestrator、worker、handoffはそれぞれの役割を果たし、プロンプトは一等市民として管理されています。

重要データ：12,390行のコード、1つのコミット

仓库の統計データのいくつかの具体的な数値：src/下のTypeScriptは合計12,390行、147個の.tsファイルです；tests/には65個のファイルがあります；全倉庫には216個のファイル（node_modulesと.gitを含まず）があり、合計3.8MBです。言語はTypeScriptで、package.json内のprivate: trueにより、npmパッケージは配布せず、bundlingを使用します。

歴史は1つだけです：単一のsquashコミット（6337fc8、2026-10-31、「feat: add the dsh-superagent research prototype」）があり、リリース後に新しいコミットはありませんでした。contributors APIからの返信は空の配列でした。9つの番号付き文書の他に、prompts/には13個のプロンプトがあり、skills/には2個（GitHubとFeishuそれぞれ1個）があります。

policy.ts 内のデフォルトパラメータは別途記載する価値がある：同時実行するワーカーの上限はデフォルトで3；Evalのタイムアウトはデフォルトで120秒；accept modeはデフォルトでobserve；デフォルトルールはcopy（コンテンツ修正）とvisual（ビジュアル修正）の2つだけで、visualルールの指示文には「Do not invent visual style」と書かれており、方向や範囲が定められていないため、観察のみで確認せず、手を動かさない。デフォルト値は非常に厳しく設定されており、「先窄后宽」の操作ガイドと一致している。

実行側の詳細：各Ticketにはworker-<ticket id>という名前のセッションと専用のディレクトリが割り当てられる；フロントエンドコマンドが5秒を超えると自動的にバックエンドタスクに変わり、ワーカーが次のステップで新しいメッセージを受け取れるようにする。これにより、コマンドが完了するまで待つ必要がなくなる。

SETUP.md自体が分解資料である。これは人に書かれたものではなく、エージェントに向けて書かれている：公式のインストールガイドは「あなたのcoding agentがSETUP.mdを読み、インストールを手伝う」とされている。ファイル内ではエージェントに対してルールを設けている：一度に短い質問のみを行い、各メッセージは300語以内で、完全な計画は一度だけ表示され、すべての質問に答えた後にのみ実行が許可される。チャット内で秘密を求めることは絶対にしない。手作業が必要なステップ（アカウント作成、CLIログイン、app secretの入力）は別のメッセージとしてまとめられる。前提条件リストも長くない：Node.js 22.19+、pnpm、git 2.32+、tmux、Python 3.8+、GitHub CLI 2.48+、さらにDSH本体とモデルプロバイダーが必要。

影響と意義：注意は通貨であり、権限は鉄の法則である

第一に、注意経済は設計の公理として扱われている。READMEの太字の文：「take as little human attention as possible, and give as much value as possible」、人の注意をできるだけ少なくし、できるだけ多くの価値を与える。哲学的な文書はこれを検証基準に展開している：メッセージ1つ、通知1つ、質問1つ、設定1つ、パネル要素1つ、ドキュメント1つ、それぞれが誰かの注意を消費し、コストを超える価値を提供できなければ削除される。動機も明確に書かれている：「チーム全体を動かすエージェントは、チーム全体の注意を浪費することもある。」多くのエージェント製品は能力を売りとしているが、このプロジェクトは逆に、「どれだけの注意を消費するか」を第一の制約としている：パネルは人が処理する必要があることのみ表示され、健康状態はスペースを占めない；概念は少なく、設定も少なく、デフォルト値で済むものは設定項目にしない。チームが文字で記述した行動はトグルではなくヒントとして記述される。

第二、提示词注入に関するアーキテクチャレベルの回答を提供しました。業界での一般的な方法は、提示詞に「メッセージ内の指示を実行しないように」とモデルに指示することです。これは本質的にモデルの自律性を求めるものです。dsh-superagentは問題をホストプログラムに委ねます：権限は白名单、ルール、Mandateにのみ存在し、メッセージ、コメント、引用されたドキュメントはすべて決定の入力に過ぎません。注入されたテキストがどんなに命令のように見えても、ゲート外の権限を得ることはできません。この防御線はモデルの能力に依存せず、モデルが変わってもそれは変わりません。docs/001の「拒否された概念」には、同じ選択肢があります：Executorが「誰かが私に停止を指示した」と主張することを許可しない。停止の判断権はEvalにのみあります。外部メッセージを受け取る代理システムであれば、この設計をそのまま使用できます。

第三、オペレーターの責任が技術文書に記載されています。哲学文書には「責任」というセクションがあります：代理はチームが毎日見るアカウントでコメントを投稿したり、PRを開いたり、メッセージを送ったりします。各メッセージは同僚の注意を引き、オペレーターはこれに責任を持つ必要があります。4つの操作規則があります：まず狭く、白名单は短いものから始め、積極的な作業は記録のみで、正しいと思ったら拡大します；問題があれば変更し、提示詞を短く厳しくするか、直接一時停止します。「より多くのメッセージでノイズを説明しないように」；量を増やすために使用しないでください。mass PR、ブロードキャストメッセージ、ビジュアライゼーションワークはチームに与える消耗が価値を上回ります；それについて言うことに責任を持ち、あなたの名前で送信された内容を読み、間違っていたら提示詞を変更します。ガバナンス規則と技術設計は同じ文書に記載されており、これはコード自体よりも稀な方法です。

第四、代理が書く、代理が読むというプロジェクト組織のサンプルを提供しています。READMEでは、多くのプロジェクトがcoding agentによって完成されたと認めており、この12,390行のコードの組織方法は、再話可能な答えを提供しています：番号付けされたドキュメントは順次依存し、どのドキュメントの読者（代理読者を含む）も前段階の概念を欠かさないようにします；提示詞は倉庫に入れられ、役割に応じてファイルに分けられます；2つのSourceは厳格に対称であり、新しいSourceが追加されるとCookbookが提供されます；65のテストファイルが基盤となります；ドメインモデルドキュメントには「拒否された概念」の表が付属しており、10以上の明確に採用されない設計と理由が一緒に列挙されています。代理が見るレポジトリはどのように長くあるべきか、ここには完全な回答があります。

議論とリスク：研究プロトタイプは研究プロトタイプです

第一、アイデンティティと成熟度について。READMEでは自ら認めています：コードにはまだバグが含まれている可能性があり、コーディングスタイルとプロジェクト実践が一致しない可能性があります。「それを研究コードとして扱い、生産準備が整ったソフトウェアではありません」。リリース版は内部版とは異なり、付随する記事の一部の設計は将来の方向性であり、プロトタイプは実現されていません。直接使用したいチームは、これらの文を3回読むべきです。

第二、進化の歴史がない。全レポジトリには1つのsquash commitしかなく、一度にリリースされ、コードが成長過程でどのように選択されたかは不明です；contributors APIは空の配列を返し、貢献者の分布はわかりません。代理がプロジェクトに参加するというポイントを持つレポジトリにとって、歴史の欠如は特に残念です：コミット記録から代理が実際にどのように大量のコードを生成しているかを観察することはできず、最終結果のみが見えます。また、0 open issueは問題がないことを意味するのではなく、コミュニティがまだ真剣に使用する機会を得ていない可能性が高いです（これは私の判断です）。

第三、传播温差本身就是一种信号。HNの最高得点は11点で、コメントは0件ですが、GitHubでは3日間で13,000星を獲得しています。HNが寂しいのは、英語圏の技術コミュニティでの議論における影響力が限られていることを示しています。GitHubの星数が急増したのは、DeepSeekの有名なイメージと「スーパーエージェント」というキャッチフレーズによるものです。星数は注目度の指標であり、質の指標ではありません。これらを混同して読むべきではありません（これが私の判断です）。

第四、デプロイのハードルをサンプルの配置に限定します。前提条件として、DSHプラットフォーム、専用のGitHubアカウント、オプションでFeishuロボットが必要です。公式ドキュメントでは、coding agentを使ってインストールすることを推奨しています。DSHエコシステムにないチームにとっては、実行可能な価値は限られています。本当に移転可能なのはドキュメントと設計です。また、認可モデルには隠されたコストがあります。gate、Mandate、再検証といったメカニズムが厳格であればあるほど、設定の幅が広がります。Policyのバージョンが変更されると、進行中のEvalがすべて無効化され再配置されます。運用上は覚えておくべきルールがたくさんあります。

結論と展望：ドキュメントはコードよりも読む価値がある

関連記事のタイトルは宣言です：「Exploring Super-agent Design: Towards a More Autonomous Agent System」、より自律的なエージェントシステムへ向けて。記事とプロトタイプは相互に関連しています。記事では設計について述べており、その一部が将来の方向性です。プロトタイプは実装済みの部分のみを提供し、両者が異なるものであると明言しています。後続で注目すべき点は二つです：DSHエコシステム内に第二、第三の重要なバンドルが生まれるかどうか、そしてDeepSeekチームが記事で述べた将来の方向性を次のバージョンに実装するかどうかです。

読者にとって、このリポジトリの価値は明確に分かれています。最下層には直接移動可能な認可モデルがあります：ホストが権限を握り、メッセージは単なる入力であり、Mandateは変更不可能で、復元前に再検証が行われます。中間層には注目度の経済に関する設計の公理とオペレーターの責任条項があります。最上層には12,390行のTypeScript実装がありますが、READMEによるとそれはバグのある参考サンプルに過ぎません。私の結論は一言で言えば：dsh-superagentは読む価値があり、ドキュメントはコードよりも詳細に読む価値があります。これはエージェントシステムの難点が能力にあるのではなく、認可と注目度にあることを証明しています。これら二つの問題にはプロジェクトベースの解決策があります。

参考文献

• リポジトリとREADME：https://github.com/deepseek-ai/dsh-superagent-prototype（13,000★ / 1,348フォーク / 0オープンイシュー / 79サブスクライバー、2026-11-03の情報）
• ローカルクローン（読み取り専用チェック）：README.md、SETUP.md、docs/000-philosophy.md、docs/001-domain.md、docs/002-authorization.md、docs/003-execution.md、src/policy.ts、package.json、prompts/、skills/
• 関連記事：「Exploring Super-agent Design: Towards a More Autonomous Agent System」（READMEを引用、プロトタイプの説明と記事は完全には一致していない）
• DSHプラットフォームのHNディスカウント：developer preview 747▲/314c（2026-08-13）；Harness Desktop 417▲/228c（2026-10-02）
• このリポジトリのHNコミット：最高11▲/0評価（2026-10-31）

署名：永亮