DeepSeek Super Agent入門：小さな開発タスクを任せるには

Webページを修正しているときに、「READMEの起動コマンドが動かないので、ついでに直してほしい」と頼まれた。小さな修正でも、手を止めてファイルを調べる必要があります。

DeepSeek Super Agentは、依頼を受け付け、複数のAIエージェントに作業を振り分け、結果を人に返す仕組みです。 公開版は1つのGitHubリポジトリを対象にし、必要に応じてFeishuとも連携できます。リポジトリとは、プロジェクトのコードを置く場所です。公式の概要

最初に確認したいのは、公式がこれを「研究用のプロトタイプ」と位置付けていることです。DeepSeekの正式製品ではなく、公開コードは社内版とも異なります。設計記事で紹介された構想の一部は、まだ実装されていません。公開版の位置付け

複数のエージェントはどう分担する？

Routerが依頼を振り分け、Workerが個別の作業を進めます。 エージェントは、依頼を受けてツールを使えるAIの助手です。セッションには、その助手の会話や作業の記録が残ります。公式の用語説明

役割	人のチームに例えると	担当すること
Router	進行役	新しい依頼を判断し、作業を割り当てたり、既存のタスクへ連絡をつないだりする
Worker	作業担当者	チケットという作業記録を受け持ち、自分のセッションとディレクトリで進める
バックグラウンドのスケジューラ	作業の順番表	実行枠が空けば開始し、空きがなければ待機させる

Workerは、必要に応じて子エージェントを呼び出すこともできます。RouterからWorkerへの分担に加え、Workerの作業内でも助手に手伝ってもらう形です。Workerと子エージェント

起動説明の修正とフォームの修正を分ける例

たとえば「起動説明を直す」「フォームの入力不足のメッセージを直す」という独立した依頼があれば、別々のWorkerへ割り当てられます。

2つの依頼
    ↓
Router：受け付け・割り当て
    ├─ チケットA → Worker A：起動説明を修正 → 結果A
    └─ チケットB → Worker B：フォームを修正 → 結果B

通常の新規作業に使える実行枠が2つあれば、両方を並行して進められます。1つなら順番待ちです。タスクAの元のスレッドに追記されたコメントは、そのタスクを担当するWorkerへ届けられます。同時実行のルール、追加メッセージの扱い

複数の仕事を管理できても、大きな依頼が必ずうまく分解され、正しく完成するとは限りません。 公開版が管理するのは、実行基盤であるDeepSeek Harness上のセッションです。実際の変更が依頼に合っているかは、返ってきた結果で確認します。実行器の仕組み

最初は、結果を確かめやすい仕事を選ぶ

範囲が小さく、何を見れば正解か分かる依頼が向いています。 起動説明なら、次のように頼めます。

「READMEの起動コマンドを、プロジェクトの実際の起動スクリプトと照らし合わせて修正してください。」

READMEはプロジェクトの説明ファイルです。この依頼なら、調べる対象と修正の根拠が分かります。「プロジェクトを見ておいて」よりも、結果を確認しやすくなります。

フォームの不具合なら、「入力が不足したまま送信してもメッセージが出ない。まず再現を確認してから直してほしい」と、起きていることを具体的に伝えます。操作手順と期待する動作も添えましょう。

これらは依頼文の例です。完了できるかどうかは、問題と実行環境によります。設計上、結果は元の会話へ返り、PRが付くこともあります。PRは「この変更を確認してください」というレビュー依頼です。結果の返し方

どんな人に向いている？

環境を用意でき、変更内容を確認できる開発者が試しやすいプロトタイプです。 これは公式の導入条件と研究段階という位置付けからの判断です。

すでにGitHubプロジェクトがあり、文書の修正や小さな不具合をよく扱うなら、テスト用プロジェクトから試せます。何を直してほしいか説明でき、修正が正しいか判断できることが大切です。インストール、アカウント、運用を担当する人も必要です。導入条件

一方、すぐ使えるチャットアプリを探している人や、コードの変更をまだ確認できない人には、準備とレビューが負担になる可能性があります。公式READMEも、自分の環境に入れる前にコードを確認し、必要に応じて調整するよう案内しています。公式README

3ステップで始める

テスト用プロジェクトで小さな依頼を1つ完了し、結果を確認してから利用範囲を広げます。 以下は導入の道筋です。依存ソフトやアカウントの具体的な設定は、公式ガイドに沿って進めてください。

ステップ1：プロジェクト・専用アカウント・モデルを用意する

まず、どのプロジェクトで、誰の名前で作業させるかを決めます。テスト用のGitHubリポジトリ、エージェント専用のGitHubアカウント、利用できるモデルサービスを用意します。専用アカウントを使うのは、エージェントが書いた内容を区別できるようにするためです。準備する項目

動作の土台にはDeepSeek Harnessを使います。Harnessとプラグインのバージョンが対応しているかも、公式ガイドで確認します。

ステップ2：ソースを取得し、コーディング助手と導入する

ターミナルを使える場合は、まず公式ソースを取得します。

git clone https://github.com/deepseek-ai/dsh-superagent-prototype.git
cd dsh-superagent-prototype

次に、使っているAIコーディング助手に、このディレクトリのSETUP.mdを読んでもらいます。公式も、このファイルを導入の入口にしています。公式の導入ガイド

依頼文の例です。

このリポジトリのSETUP.mdを読み、dsh-superagentの導入を手伝ってください。
必要な設定を確認し、全体の計画を見せてから進めてください。
接続先は私が指定するテスト用プロジェクトだけにし、observeモードを維持してください。
変更のレビューとマージは私が行います。
ログインと秘密情報の入力は、ローカルのターミナルで私が行える手順を示してください。

observeは、受け付ける候補の仕事を記録して様子を見るモードです。autoへ切り替える前に、どんな仕事が候補になったかを確認します。

ステップ3：小さな依頼を出し、変更を確認する

設定が終わったら、依頼を許可されたアカウントでIssueを作るかコメントし、エージェントをメンションします。次の例を自分のプロジェクトに合わせて使えます。

@自分の-agent-アカウント
READMEの起動コマンドを、実際の起動スクリプトと照らし合わせて修正してください。
必要な文書だけを変更し、アプリのコードは変更しないでください。
変更箇所と根拠、確認できなかった点を説明してください。
レビューとマージは私が行います。

結果が返ったらPRを開き、依頼どおりか確認します。フォームの不具合を頼む場合は、操作手順と期待する結果を追加します。

進捗はSuperagentパネルで確認する

HarnessのWeb画面にあるSuperagentパネルが、作業状況を見る場所です。 人の対応が必要な項目を優先して表示します。まず依頼が届いたか、受け付けられたかを確認し、次に作業中なのか、回答やレビューを待っているのかを見ます。パネルの公式説明

参考資料

現在の機能と導入条件は、公式ドキュメントで確認してください。

1. 公式リポジトリとREADME：対象範囲、研究用プロトタイプの位置付け、結果の返し方。
2. 001 Domain model：役割とチケットの考え方。
3. 002 Authorization：依頼の許可、observeモード、追加メッセージ。
4. 003 Execution：実行枠と子エージェント。
5. 005 Panel：進捗と人の対応が必要な作業。
6. SETUP.md：導入手順と前提条件。
7. 006 Deployment：設定と運用。
8. 007 Architecture：実行器とセッションの管理。