アシスタントが設定関数を直し、「空文字も処理できるようにした」と言いました。ところが変更をプロジェクトへ戻して動かすと、呼び出し側には古い引数名が残っていて、またエラーになります。
「できた」と言うこと、ファイルを変更すること、実際に動かして確かめることは別々です。変更箇所や確認方法を毎回聞き直すのではなく、依頼と成果を追える場所に置けたらどうでしょう。
まずは、インストール不要の二つのチャットで「範囲と合格条件を書いた依頼票」を作ってみます。そのあと、DeepSeekの公開リポジトリにあるdsh-superagent-prototypeを練習用GitHubリポジトリにつなぎ、小さなREADME修正をPull Request（PR）として受け取るところまで進みます。PRは、プロジェクトへ取り込む前に人が確認できる変更提案です。
まず二つの普通のチャットで、依頼票を作る
二つのAIチャットを開き、ウィンドウAに次の材料を貼り付けてください。
あなたはタスクを整理する担当です。変更作業はしないでください。元の情報：READMEには「npm run demoを実行するとhelloと表示される」と書いてあります。実際の取り決め：npm run demoの出力はHello, world!です。目標、変更してよい範囲、合格条件を含む依頼票を作ってください。変更してよいのはREADMEだけです。プログラム、スクリプト、依存関係は変更しないでください。
Aが作った依頼票に、最初の材料も添えてウィンドウBへ渡します。
依頼票に従い、READMEの変更前と変更後の文章を提示してください。制約を一つずつ満たしているか説明してください。提示された材料だけを使ってください。ターミナルが使えない場合、コマンドを実行したとは言わないでください。
期待する変更は、READMEのhelloをHello, world!に直すことだけです。プログラムと起動コマンドはそのままです。Bの結果をAへ戻し、元の制約と照らし合わせてもらいましょう。もしBが起動コマンドまで変えてしまったら、どこを直してほしいのかを具体的に伝えられます。
回答の言い回しは見本と同じでなくて構いません。見るのは、変更範囲と期待する結果です。この練習で得られるのは文章による納品物であり、プログラムが実行された証拠ではありません。チャットを二つに分けても、間違いが自動でなくなるわけではありません。
ここで身につけたのは、変更範囲と合格条件を一枚の依頼票にまとめると、「できた？」を何度も聞かずに成果を受け取りやすくなるということです。
この依頼票の考え方を、次は実際のリポジトリにつながるSuperagentへ持ち込みます。先ほどの練習は、Superagentをインストールしたことにも、独立した監査役が正しさを保証することにもなりません。
リポジトリの横にある作業台として考える
dsh-superagent-prototypeは、DeepSeek Harness（DSH）の上で動き、GitHubから依頼を受け付けます。GitHubがメッセージを運び、Policyが依頼者を確認し、Ticketが仕事を記録し、独立したセッションと作業ディレクトリで処理します。結果は元の議論へ戻り、たとえばPRとして人が確認できます。
一つのリポジトリを対象にした研究用プロトタイプです。DeepSeekの正式な製品ではなく、チーム内部の実装とも同一ではありません。関連する設計記事にある構想の一部も、このコードにはまだ実装されていません。製品のスイッチを入れる感覚ではなく、アカウント、実行環境、設定を自分で管理するソフトウェアとして扱いましょう。
最初に向いているのは、結果を小さな差分で確かめられる仕事です。
| 仕事 | 依頼に書くこと | 人が見るところ |
|---|---|---|
| ドキュメント修正 | READMEのどの説明をどう直すか | 差分が指定した文章だけか |
| テスト追加 | 対象関数、境界ケース、既存動作を保つこと | テストが追加され、実際に実行されたか |
| 小さな不具合修正 | 再現入力、実際の結果、期待する結果 | 再現条件が解消し、関連テストも通るか |
| Feishuからの依頼 | 設定後、指定したチャットで同じ依頼票を渡す | 元の会話への返答と対応するPR |
どれも活用候補であり、成功の保証ではありません。依頼に情報が足りなければ、PRではなく追加説明を求めることもあります。最初の目標は、練習用リポジトリに届いた変更を自分で読めることです。
どのマシンで動かすかを先に決める
ここで大事なのは、専用の作業ディレクトリは、セキュリティ上の隔離ではないという点です。
公式のデプロイガイドでは、ExecutorとメインSession用のプリセットが、実行サービスと同じOSユーザーでdanger-full-access権限により動きます。プロセスはパスを指定してプログラムを実行でき、そのユーザーのホームディレクトリも読めます。アカウントを切り替えるラッパーは、どの認証情報を使うかを選ぶものです。プロセス自体を閉じ込める仕組みではありません。
机の上の「ロボット用」と書いた鍵箱を想像してください。使う鍵は選べても、同じユーザーから開けられる引き出しまで封じるものではありません。初回は専用OSユーザー、またはロボットの認証情報と練習用リポジトリだけを置いた隔離環境を使うのが無難です。DSHの専用Profileや一つのリポジトリに絞る設定は仕事を整理しますが、個人ファイルを読めなくする境界にはなりません。
以下はPOSIXシェル向けです。Windowsでは、すでに用意したWSLのLinux環境で実行してください。PowerShellへそのまま貼り付ける手順ではありません。公式スクリプトはtmuxやシェル、Pythonのfcntlなどを使います。WSLの導入は別のシステム準備なので、すでに環境がある場合はここを進めます。
場所も二つに分けます。一つはSuperagent本体のリポジトリ、もう一つはSuperagentに作業させる練習用プロジェクトです。本体のリポジトリへインストールしても、作業対象の場所が自動で決まるわけではありません。
手順1：ツールとモデル接続を確認する
選んだLinux／POSIX環境で、以下を一つずつ実行します。
node -v
pnpm -v
git --version
python3 --version
tmux -V
gh --version
dsh --version
SETUPではNode.js 22.19以上または24以上、Git 2.32以上、Python 3.8以上、GitHub CLI 2.48以上に加え、pnpmとtmuxが必要とされています。DSHは、取得したプロジェクトのpackage.jsonにあるengines.dshの条件も満たさなければなりません。バージョンは、実際に使うチェックアウトの記述を基準にしてください。
各コマンドでバージョンが表示されることを確認します。command not foundと出た項目だけを準備リストに加え、先へ進む前に解決します。すでにあるツールを重ねてインストールする必要はありません。
DSHが作業台の土台、Superagentはその上に載せる作業パッケージです。さらにDSHで利用できるモデルサービスを設定します。コードがオープンソースでもモデル呼び出しが無料とは限らず、費用や利用枠は選んだサービスとアカウントによって変わります。まずDSHで普通のモデル会話を一度できるようにしておくと、「モデルが応答しない」のか「GitHubから依頼が届かない」のかを切り分けやすくなります。
手順2：公式のセットアップ案内を使う
Superagent本体を、作業対象の練習用リポジトリとは別の場所へ取得します。
git clone https://github.com/deepseek-ai/dsh-superagent-prototype.git
cd dsh-superagent-prototype
既存のコーディングアシスタントでこのディレクトリを開き、次のように依頼します。
このリポジトリのSETUP.mdを読んで、私と一緒にdsh-superagentをセットアップしてください。
さらに、「最初はGitHubだけ、練習用リポジトリだけを接続する。依頼できるのは自分だけ。自動マージは無効にする。実行前に全体の計画を示し、確認を待つ。認証情報は自分がローカルでログインまたは入力する」と伝えます。
公式のセットアップ手順は、必要な情報を一つずつ集め、全体の計画を提示してから確認を求めます。手元に用意するのは、練習用リポジトリのowner/name、ロボット用GitHubユーザー名、依頼を許可する自分のユーザー名、練習用リポジトリのローカルパス、コミット作者の名前、auto-mergeを使うかどうかです。最初はGitHub only、自分だけを許可、自動マージはNoにすると設定を絞れます。
ロボットには専用のGitHubユーザーアカウントが必要です。そのアカウントを練習用リポジトリへ招待し、書き込み権限を付けます。現在のデプロイ方式はアカウントの通知を読むため、GitHub Appをそのまま代わりにはできません。対象はgithub.comのリポジトリで、GitHub Enterprise Serverはサポート対象外です。
手順3：自分とロボットのGitHubログインを分ける
デプロイガイドは、ロボット用GitHub認証情報を使う独立したghラッパーを用意します。専用環境で実行し、同名ファイルがすでにあれば内容を確認してから扱ってください。
mkdir -p ~/.local/bin
cat > ~/.local/bin/gh-agent <<'EOF'
#!/bin/sh
GH_CONFIG_DIR="$HOME/.config/gh-agent" exec gh "$@"
EOF
chmod +x ~/.local/bin/gh-agent
~/.local/bin/gh-agent auth login
~/.local/bin/gh-agent api user --jq .login
ログイン画面ではロボットのアカウントを選びます。最後のコマンドが返すのはロボットのログイン名です。自分のユーザー名が返った場合は、先へ進まず認証先を確認します。
トークンをチャットへ貼り付ける必要はありません。このラッパーは、机の「ロボット用鍵箱」のような役割をします。正しい鍵を選ぶものの、同じOSユーザーが使える他のファイルを隔離するものではありません。
手順4：インストール、設定、起動を分ける
以下は、Superagent Profileがまだない新規環境でのインストール手順です。コーディングアシスタントには、公式デプロイガイドと照らし合わせて計画してもらいましょう。
npm install -g @deepseek-ai/dsh@0.2.1-rc.3
pnpm install
pnpm build
dsh superagent --from-default-profile web --dump-config > /dev/null
dsh plugin --profile superagent add "link:$PWD"
すべてSuperagent本体のリポジトリのルートで実行します。最初の行はデプロイ文書に記載されたDSHの固定バージョンです。すでにDSHがある場合は、package.jsonの互換範囲を先に確認します。
4行目のProfile作成コマンドは新規インストール用です。既存のsuperagent Profileに再実行すると、設定を置き換えてしまいます。すでに使っている人は、設定を保ったまま公式のUpgrade手順に進みます。
ビルドが成功しても、依頼を受けられる状態とは限りません。 次に、examples/profile.cordis.patch.ymlを参考にマシン設定を整え、絶対パスのstateDirを指定します。新規環境では公式の案内に沿って例を使い、既存設定があるならファイル全体を置き換えず必要箇所だけ編集します。プロファイル用プラグインはPATHやGitの設定にも影響するため、普段使うProfileとは分けて管理し、個別に再起動・更新します。
続いてサービスを起動し、状態を確認します。
scripts/dsh-superagent start
scripts/dsh-superagent status
起動ログに出るアドレスを開き、サイドバーからSuperagentを選択します。標準の計画では127.0.0.1:3082を使いますが、実際のポートは設定に従ってください。
パネルでは四つの設定をそろえます。
- Sources：練習用リポジトリのowner/nameと、ロボット用ghラッパーの絶対パス。
- Policy：自分のGitHubログイン名を許可リストへ追加。リストが空だと依頼はTicketになりません。
- Execution：作業ディレクトリのルートとprepareコマンド。各Ticket用にプロジェクトの作業コピーを作れるよう、実際のクローンパスからworktreeコマンドを組み立ててもらいます。
- Prompts：コミット作者とロボットであることの開示文を設定し、マージは人が行う条件を残します。
電源ケーブルのように、この四つがつながって初めて依頼が動きます。モデルだけを変更しても、GitHubアカウントや作業ディレクトリの設定不足は補えません。設定保存後に再起動を求められたら、サービスが戻るのを待ちます。外部ログインを直した後は、表示されるCheck againで再確認します。
手順5：最初の本物の依頼を送る
Policyで許可したアカウントから、練習用リポジトリのIssueに新しいコメントを投稿します。
@<agent-login> Please correct the README's demo output description.
It should say Hello, world!
Only change README. Do not change the program, scripts, or dependencies.
Please open a PR and explain what changed and how you checked it.
山括弧の箇所をロボットの実際のユーザー名に置き換えます。これは依頼文の例であり、コマンドではありません。
通常はGitHubアカウントの通知を約1分間隔で確認して依頼を受け取ります。既存Issue本文を編集してmentionを足す方法では通知されません。新しいコメントとして投稿してください。また、need-agentラベルを付けるだけでは依頼のトリガーになりません。ラベルから自動で受け付けるには別のルールが必要です。
パネルのOverviewにTicketが作られたか、タスクSessionと元コメントへの返答があるかを確認します。結果はPRのこともあれば、情報の追加依頼のこともあります。確認は三段階に分けましょう。
- Ticketがある：依頼を受け取る経路が動いた。
- PRがある：変更案が作られた。
- 差分と確認記録を見る：依頼した変更範囲と合格条件を満たしたか判断できる。
READMEの練習なら、出力説明が直り、起動コマンドが変わっておらず、プログラム・スクリプト・依存関係が変更されていないことを差分で確認します。「全部通りました」という文章だけでは、実際に何を確認したかの代わりになりません。
statusの終了コードも状況の切り分けに役立ちます。0は正常、1はプロセスまたはランタイムの問題、2はSourceなどのモジュールエラー、3はセットアップ待ちです。2や3の場合、再起動を繰り返しても足りない設定は出てきません。errorsやsetupに表示された詳細を見ます。サービスの状態が正常でも、最初のPRが依頼どおりかどうかは別に確認してください。
一件できたら、任せる範囲を少しずつ広げる
READMEの修正が届いたら、次はテスト環境がすでにあるリポジトリで、小さな関数の境界テストを頼めます。依頼票にテストコマンド、変更してはいけないファイル、失敗した場合の報告方法を加えると、確認しやすくなります。
自分から仕事候補を見つける動作は、明示的な依頼とは別に考えます。SETUPの初期値であるobserveは、候補を記録するだけで実行しません。許可された人から明示的に届く依頼と、エージェントが先回りして見つけた候補は同じものではありません。まず候補の内容を見て、どの範囲まで任せるか決めましょう。
Feishuも後から追加できる入口です。ボットアプリ、権限、専用のlark-cli設定、許可リストが必要になります。依頼を出す場所は増えますが、リポジトリ権限、実行マシン、モデル設定は引き続き必要です。
今は後回しでよいこと
Feishu、自発的なスキャン、複数人からの依頼、自動マージ、本番環境への接続は、最初の一件が届いてから考えれば十分です。最初の目標は、練習用リポジトリに届いた変更を読める小さなPRを一つ受け取ることです。
アイデアを相談するだけなら、いつものチャットも便利です。常駐する作業台の価値は、依頼、状態、納品物を追える場所にまとめられること。PRが戻ってきたら差分を開き、確認結果を読み、取り込むかどうかを自分で決めましょう。
参照した一次資料と適用範囲
以下の公開プロジェクト資料を2026年11月7日に確認しました。コマンドやパネル名はチェックアウトするバージョンで変わることがあります。
- プロジェクトREADME：研究用プロトタイプの位置づけ、対象リポジトリ、内部実装との違い。
- SETUP.md：前提条件、セットアップ時の質問、初期設定、最初の依頼。
- 006 Deployment：アカウント、権限、インストール、パネル設定、通知確認、起動と終了コード。
- package.json：Node.jsとDSHの互換条件、ビルドコマンド。