DeepSeek Super-Agent: プロアクティブなコーディングエージェントのコストはいくらか
更新日 November 2, 2026 · 初回公開 November 2, 2026
DeepSeekのSuper-Agent(dsh-superagent)は、MITライセンスのリサーチプロトタイプです。GitHubをポーリングし、許可された人からのリクエストをチケットに変え、ワーカーセッションがプルリクエストを開きます。並列ワーカー数(デフォルト3)には上限がありますが、トークンや支出の上限はないため、モデルの請求額を抑えられるのはプロバイダーのキーと設定だけです。
この記事は2026年11月2日にREADMEと報道をもとに最初に公開し、同じ日にリポジトリ自体(ドキュメント、プロンプト、ソース)を読んだうえで書き直しました。事実はプロジェクトのリポジトリとHelp Net Securityに基づいています。Bloombergはこのリリースを報じ、Claude Codeへの挑戦と位置づけました。DeepSeekはClaude Codeとの比較ベンチマークを公表していないため、その見方は結果ではなくポジショニングとして扱ってください。
何をするのですか?
- 取り込み:
ghコマンドラインを通じて、デフォルトで60秒ごとにGitHubをポーリングします。Webhookはありません。メンション、購読しているIssueとプルリクエスト、レビューコメント、CIの結果がこの方法で届きます。Feishuチャットは別のオプションのプラグインで、デフォルトではオフです。ドキュメントのデフォルトはGitHubのみの構成です。 - 受理: 許可された人がエージェントに呼びかけた場合、リクエストは明示的なものになります。それ以外は推測された候補で、モデルが判断する必要があります。許可リストに誰も載っていない間は、どのリクエストもチケットになりません。
- 作業: 小さなルーターセッションが、各トリガーをどう扱うかを決めます。受理された各チケットには、通常はgit worktreeである専用ディレクトリに、永続的なワーカーセッションが割り当てられます。ワーカーは実装、確認、コミット、プッシュを行い、エージェント自身のGitHubアカウントでプルリクエストを開き、その後CIとレビューを追います。
- ステータス: READMEはこれを「参考用のリサーチプロトタイプであり、DeepSeekの公式製品ではない」と呼び、本番利用可能なソフトウェアではなく研究用コードとして扱うよう述べています。
お金はどこにかかりますか?
GitHubのポーリングにモデルのトークンは使いません。支出はモデルが呼ばれたときに始まります。コード上では3か所です。
- ルーターセッションは、受理されたすべてのトリガーを読んで振り分けます。そのため、明示的なリクエストは作業が始まる前に少なくともルーターの1ターン分のコストがかかります。
- アセッサーは、推測された候補を判断します。デフォルト設定ではここが重要です。
observeモードでも、エージェントは評価を実行し、行動する代わりに「受理したはず」と記録するだけです。observeモードは行動に対するシャドーモードであり、コストに対するものではありません。デフォルトではエージェントに宛てられたメッセージだけを受け取るため、宛先のないメッセージがアセッサーに届くのは、Issue、プルリクエスト、コメント、CIに対するリポジトリ全体のobserveスイッチをオンにした場合だけです。 - ワーカーセッションが実際の作業を行います。コードの読み取り、編集、チェックの実行、失敗後の再試行、レビューラウンドの処理です。各ワーカーは独自のコンテキストを持ち、トークンの大半はここで使われます。
ルーター/アセッサー用のモデルとワーカー用のモデルは別々に設定され、ワーカーのモデルはセッション作成時に固定されます。コードにはトークンカウンター、チケットごとの上限、支出台帳がなく、パネルにも使用量やコストは表示されません。予算に関するコードは、再試行中にプロバイダーの「予算超過」エラーを検出してヘルス警告として表示するものだけで、作業を止めることはありません。DeepSeekのドキュメントには、プルリクエストあたりのコストは記載されていません。
どんな制限がありますか?
| 制限 | ドキュメント上の値 |
|---|---|
| 並列ワーカー | デフォルト3、設定可能範囲は1〜16。人のメッセージがワーカーを起こしたときだけ開く、追加のオーバーフロースロットが1つ |
| ポーリング間隔 | デフォルト60秒(60〜3600) |
| 評価のタイムアウト | デフォルト120秒(30〜600)。2回再キューし、その後は利用不可として記録 |
| 一時的なモデルエラー | 15秒、30秒、60秒後に自動で3回再試行。その後チケットは失敗としてマークされ、人の対応を待つ |
| ワーカーのターン後のバックグラウンドジョブ | 30分、その後強制終了 |
| ボットのレビューラウンド | 自動レビュアーごとに、プルリクエストあたり3回(プロンプトの文言であり、強制されるコードではない) |
| 自動マージ | 別のマージ用アカウントを指定しない限りオフ。指定した場合も、変更行数200行未満で、承認がheadコミットをカバーしている準備完了のプルリクエストのみ。これもコードではなくプロンプトの文言 |
バックグラウンドジョブが動いている間、ワーカースロットは占有されたままです。そのためワーカー数の上限は同時のトークン支出の上限でもありますが、各ワーカーがどれだけ使うかの上限ではありません。
何が必要で、リスクは何ですか?
- エージェント専用のGitHubユーザーアカウント(書き込みアクセス付き)。エージェントは通知を読むため、GitHub Appをエージェントにすることはできません。DeepSeek Harness(
dsh)ランタイム、Node、pnpm、git、tmux、ghも必要です。 - フルアクセス。 ワーカーセッションは、オペレーター自身のオペレーティングシステムユーザーとして、フルアクセスの権限プリセットで動きます。プロジェクトは、コマンドのラッパーはデフォルトであってセキュリティ境界ではないとしています。隔離されたマシンまたはアカウントで実行してください。
- 状態が際限なく増える。 アーキテクチャノートによれば、古い記録はまだ削除されません。
トライアルの予算はどう立てますか?
受理したはずのリクエストのログで作業量を見積もり、自社の測定値で価格を付けます。月間支出は、受理された作業項目数 x 項目あたりの平均請求コストです。項目あたりのコストには、ルーターのターン、評価、すべてのワーカー呼び出し、すべての再試行、すべての放棄された試行を含めます。総支出を、受け入れられた変更になった項目数で割ります。成功タスクあたりのコストと同じ考え方です。
想定した入力による例で、DeepSeekのデータではありません。月に200件の作業項目で、項目あたりの平均請求コストを$4と仮定すると$800です。受け入れられた変更になったのが140件だけなら、受け入れられた変更あたりのコストは$800 / 140 = $5.71で、$4ではありません。この差が、放棄された作業と却下された作業の代償です。
最初に設定すべき制御は何ですか?
- 許可リストは小さく保ち、意図的に人を追加します。これが最初の支出ゲートです。
- 受理したはずのログを読むまでは、すべてを受信するスイッチをオフのままにします。宛先のないトラフィックをアセッサーに送るのがこのスイッチだからです。
- トライアルでは
maxWorkersを低く設定し、プロジェクトには上限がないため、実際の支出上限はモデルプロバイダーのキーまたはゲートウェイに置きます。エージェントの3つの予算と本番の支出ガードレールを参照してください。 - プルリクエストを請求額まで追跡できるよう、リポジトリとチケットごとに支出にタグを付けます。
- マージは人に任せ、デリバリープロンプトは担当者のいるポリシーファイルとして扱います。
他のGitHubエージェントとどう比べられますか?
GitHubのリクエストをプルリクエストに変える選択肢は、ほかに3つあります。違いは、支出がどこに表れ、何が上限になるかです。2026年11月2日に確認したものです。各ベンダーのページで再確認してください。
| 選択肢 | トリガーとランタイム | 支出が表れる場所 | ドキュメント上の上限 |
|---|---|---|---|
| Claude Code GitHub Action | IssueまたはPRコメントで@claudeにメンション。GitHubホストのランナーで実行。トリガーしたユーザーには書き込みアクセスが必要で、リストにないボットのアクターは拒否される | GitHub Actionsの分数とClaude APIトークン(OAuthトークンを使う場合はClaudeサブスクリプション) | --max-turns、ワークフローレベルのタイムアウト、GitHubの同時実行制御 |
| GitHub Copilot cloud agent | クラウド環境でバックグラウンドで調査、計画、実装。タスクごとにプルリクエスト1つ | クラウドとActionsのコンピュートは、AIクレジットとは別の、GitHubアカウントの月間枠から消費される。請求の詳細は別ページ | Actionsセッションは最大59分。書き込みアクセスがなければ読み取り専用で、ブランチ保護でブロックされることもある。新しいクラウド体験は2026年10月28日から有料プラン向け |
| OpenHands | MITライセンス、セルフホスト。独自のエージェントまたはサードパーティのエージェントを実行し、モデルは持ち込み。READMEにはGitHub Issueがどう起動するかの記載なし | モデルプロバイダー、またはOpenHands Cloud | READMEには記載なし。サンドボックスなしモードでは、エージェントがファイルシステム全体にアクセスできると警告される |
| DeepSeek Super-Agent | GitHubをポーリング。専用エージェントアカウント。セルフホスト | モデルプロバイダーのキー | ワーカー数とタイムアウトのみ。トークンや支出の上限なし |
実用上の違いは、ホスト型の選択肢がすでに管理している請求(Actionsの枠、ワークスペース制限付きのAPIキー)の内側にあり、ターン数や時間の上限が文書化されているのに対し、Super-Agentはそれらをすべて利用者に任せていることです。ツール単位のコスト比較は、Cursor vs Copilot vs Claude Codeのコストを参照してください。
今すぐ導入すべきですか?
本番ではいいえ。DeepSeek自身が本番利用可能ではないと述べています。重要でないリポジトリで、隔離されたマシンと上限付きのキーを使った限定的なトライアルなら、プロアクティブなエージェントが自社にいくらかかるかを知る安価な方法です。コードは無料で、支出は自社のプロバイダーで見えるからです。判断の指標は、節約できる注意力に対する、受け入れられたプルリクエストあたりのコストであり、他のツールと競合するという見出しではありません。
よくある質問
DeepSeekのSuper-Agentとは何ですか?
dsh-superagentは、DeepSeekによるプロアクティブなコーディングエージェントの、オープンソース(MIT)のリサーチプロトタイプです。GitHubをポーリングし、許可された人からのリクエストを受理し、受理した各チケットに専用ディレクトリのワーカーセッションを割り当て、自身のGitHubアカウントでプルリクエストを開きます。
Super-Agentに支出の上限はありますか?
ありません。並列ワーカー数(デフォルト3、範囲1〜16)、タイムアウト、再試行の上限はありますが、トークンカウンター、チケットごとの上限、支出台帳はなく、パネルにも使用量やコストは表示されません。上限はモデルプロバイダーのキーまたはゲートウェイに設定してください。
Super-Agentは無料ですか?
コードはMITライセンスで無料です。実行にかかるのは、接続するモデル、マシン、ツールの費用です。DeepSeekはタスクあたりのコストの数値を公表していません。
observeモードならモデルのコストは発生しませんか?
いいえ。observeモードは評価を実行し、リクエストに対して行動する代わりに、エージェントが受理したはずであることを記録します。節約できるのはワーカーのコストで、アセッサーのコストではありません。デフォルトではエージェントに宛てられたメッセージだけが受信されるため、宛先のないメッセージが評価されるのは、observeスイッチをオンにした場合だけです。
Super-Agentは本番利用できますか?
できません。READMEはこれを参考用のリサーチプロトタイプでありDeepSeekの公式製品ではないとし、研究用コードとして扱うよう述べています。ワーカーはオペレーターのユーザーとしてフルアクセスで動き、状態は際限なく増えます。
関連記事
この方法を自社の環境にも適用しますか？ プロバイダーの請求書、ゲートウェイログ、主要なワークフローをお持ちください。コスト要因と削減策を整理します。 無料監査を予約 →