DeepSeek Harnessはループです。エージェントはワークスペースを読み込み、ファイルを編集し、bashツールを通じてコマンドを実行し、その出力に基づいて次に何をすべきかを決定します。では、なぜあなたのAPIテストはそのループに含まれていないのでしょうか？それらはGUIのApidogの背後にあり、誰かがクリックすることを思い出したときに実行されます。エージェントがそれらに触れることはありません。
解決策は1つの設定ブロックです。Apidog CLIはnpmパッケージ `apidog-cli` であり、Apidogで構築したテストシナリオをターミナルから直接実行します。CLIがインストールされ、DeepSeek Harnessがその存在を認識すると、エージェントはユニットテストを実行するのと同じ方法でApidogシナリオを実行します。つまり、コマンドを実行し、終了コードを読み取り、赤（失敗）であればコードを修正します。
これを行うためのトークン引数もあります。ハンドラーコードを再読し、レスポンスの形状について推論することでAPIがまだ機能していることを確認するエージェントは、実行のたびにコンテキストを消費します。1つのコマンドを実行するエージェントは、数行で真の情報を得ます。CLIは「APIは正しいか？」を終了コードに圧縮し、エージェントはその代わりに修正にコンテキストを費やします。
このガイドでは、一般的なインストールガイドが省略しているハーネス固有の部分、つまりDeepSeek Harnessが実際にどの命令ファイルを読み込むのか、そのbashツールがapidog runをどのように実行するのか、そしてループを正直に保つ方法について説明します。CLIをまだインストールしていない場合は、まずそれを行ってください。AIコーディングエージェントでApidog CLIをインストールする方法では、npmインストール、認証、および初回実行について説明しています。本記事は、apidog --versionが数値を表示し、お使いのPCが認証済みであることを前提としています。
ここで言及するDeepSeek Harnessについて
コマンドラインではdshとして知られるDeepSeek Harnessは、2026年8月13日にDeepSeekがV4-ProとともにAPIでリリースしたオープンソースのエージェントハーネスです。MITライセンスで、github.com/deepseek-ai/deepseek-harnessにあり、8月20日時点で16万9千以上のスターを獲得しています。npx @deepseek-ai/dsh webで起動し、http://127.0.0.1:3080でローカルWeb UIを提供します。そこでワークスペース（起動したプロジェクトディレクトリ）を選択すると、エージェントはその中で動作します。ファイルの読み書き、コマンドの実行、そしてアクティブなパーミッションポリシーの下で承認が必要な操作の前に確認を求めます。
以下のすべては2つの事柄によって形成されます。まず、このハーネスは開発者プレビューです。READMEには、互換性を損なう変更があることが大文字で警告されているため、ここに記載されているファイル名と設定キーは2026年8月後半の時点での正確なものとして扱い、何か読み込めない場合はリポジトリのドキュメントと再照合してください。次に、dshのすべてはCordisアーキテクチャに基づいたプラグインであり、これにより以下の実用的な質問に答えることができます：どのプラグインがプロジェクトルールを読み込み、何を探しているのか？詳細については、DeepSeek Harnessとは何かをご覧ください。既存のツールと比較してどうなのかについては、DeepSeek Harness vs Claude Codeをご覧ください。
ステップ1: AGENTS.mdにCLIを配置する
DeepSeek Harnessは、@deepseek-ai/dsh-agent-instructionsプラグインを通じてワークスペースの指示を読み込みます。他のエージェントを使用したことがある方には、デフォルト設定は使いやすいでしょう。プラグインのソースと設定カタログによると、ローダーはセッションの作業ディレクトリからプロジェクトルート（.gitでマークされている）まで上向きに辿り、途中の各ディレクトリでAGENTS.mdをロードし、存在しない場合はCLAUDE.mdにフォールバックします。AGENTS.local.mdまたはCLAUDE.local.mdという名前のローカルオーバーレイはベースファイルの後にロードされ、$DSH_HOME（デフォルトは~/.dsh）にある固定のユーザーグローバルAGENTS.mdはプロジェクト全体に適用されます。1MiBを超えるファイルは無視されますが、あなたのルールファイルがそのサイズに近づくことはないでしょう。
以下に、短いApidogブロックをAGENTS.mdに追加します。
## API testing with the Apidog CLI
- To test the API, run the Apidog scenario. Do not click through the GUI.
- Command: apidog run -t <scenario_id> -e <env_id> -r cli
- Exit code 0 means every assertion passed. Non-zero means a failure; read the report and fix the code.
- The machine is already authenticated. Never add an --access-token flag and never put a token in this file.
これが、ルールファイルがチャットよりも優れている理由です。セッションコンポーザーに入力されたシナリオIDは、セッションが終了すると消えてしまいます。AGENTS.mdに書き込まれたものは、リポジトリをクローンするすべてのマシンで、すべてのチームメイトのために、新しいセッションごとに読み込まれます。複数のプロジェクトで作業している場合、ユーザーグローバルの~/.dsh/AGENTS.mdは習慣（「APIの変更は常にプロジェクトの`apidog run`コマンドで検証する」）を保持し、各リポジトリ自身のファイルは実際のIDを保持します。
ステップ2: Apidogからコマンドを取得する
シナリオと環境のIDを推測する必要はありません。Apidogでテストシナリオを開き、CI/CDタブに移動して生成されたコマンドをコピーしてください。それは次のようになります。
apidog run -t 123456 -e 789012 -r cli
-tフラグはテストシナリオID、-eは環境ID、-r cliは結果をインラインで出力するレポーターを選択します。これはエージェントが読み取るために必要なものです。実際のIDをAGENTS.mdブロックに貼り付け、エージェントが推測ではなくApidogが生成したコマンドを実行するようにします。
ステップ3: エージェントにテストを実行させる
ワークスペースを選択した状態でdsh Web UIでセッションを開始します。命令ローダーはすでにあなたのAGENTS.mdをエージェントのコンテキストに供給しており、エージェントはCLIの存在を知っています。APIに影響を与える変更を行うか、単に尋ねてください。
Apidogテストシナリオを実行して、終了コードを教えてください。
エージェントはbashツールを通じてそれを実行します。そのツールの動作を知っておくことで、後でデバッグセッションを節約できます。ツールカタログによると、デフォルトのbashツールは各コマンドを新しいシェルで実行します。呼び出し間で作業ディレクトリ、変数、関数は保持されず、workdirが渡されない限り、コマンドはセッションのワークスペースから実行されます。apidog runのような単一で自己完結型のコマンドには問題ありませんが、エージェントは最初にどこかにcdしてからテストを2番目のステップとして実行することはできません。シナリオがサブディレクトリから実行されなければならない場合は、完全な呼び出しをルールファイルの1行に記述してください。
さらに知っておくべき動作が2つあります。ゼロ以外の終了コードは明示的な[exit code: N]マーカーとして返されるため、長い出力が末尾に切り詰められた場合でも合否のシグナルは残ります。また、コマンドはファイルサンドボックスの下で実行される場合があります。ブロックされた操作はコマンドの失敗ではなく、ポリシー拒否として報告されます。読み取り専用のテスト実行ではこれが問題になることはめったにありませんが、HTMLレポーターが./apidog-reportsに書き込む場合は、アクティブなポリシーによっては問題となる可能性があります。
実行に最初にあなたのクリックが必要かどうかは、その同じパーミッションポリシーに依存します。ユーザーガイドによると、Web UIは、そのポリシーの下で承認が必要な操作の前に尋ねてきます。apidog runのプロンプトが表示されたら、それを承認してください。ステージングに対するテストシナリオは、承認フローが存在するまさに安全で読み取りが主となるコマンドです。
ステップ4: レポートを読む
実行が赤（失敗）になったら、レポートに答えがあります。-r cliを使用すると、エージェントはインラインで読みやすい内訳（各リクエスト、各アサーション、そして期待値と実際の値とともに失敗したアサーション）を取得します。失敗したアサーションは正確なフィールド名またはステータスコードを特定し、これは通常、あなたが翻訳することなくエージェントが修正箇所を特定するのに十分です。
ブラウザで開いたり、チームメイトに渡したりできるレポートが必要な場合は、HTMLレポーターを追加してください。
apidog run -t 123456 -e 789012 -r cli,html
htmlレポーターは自己完結型のファイルを./apidog-reportsに書き込みます。エージェントが次のステップを決定するために読み取るインライン出力を引き続き取得できるように、リストにcliを残しておいてください。
エンドツーエンドのループ
このセットアップで得られるものは以下の通りです。エージェントがチェックアウトハンドラーを編集しているとします。CLIがない場合、そのループは「コードは正しいようだ」で終わります。AGENTS.mdのブロックがあれば、ループは拡張されます。ハンドラーを編集し、apidog run -t 123456 -e 789012 -r cliを実行し、結果を読み取ります。緑（成功）であれば、次に進みます。赤（失敗）であれば、[exit code: 1]を確認し、どのアサーションが失敗したか（200が期待されるところに500、totalフィールドの欠落、誤った通貨コードなど）を読み取り、ハンドラーを修正して再実行します。API契約のチェックは、エージェントがすでにユニットテストを実行しているのと同じ編集-テスト-修正サイクルの一部となります。
エージェントが何をしなかったか注目してください。APIが機能することを確認するためにすべてのルートファイルを再読することはありませんでした。シナリオはすでに期待される動作をエンコードしており、APIの所有者がApidogで視覚的に構築しています。エージェントは検証を決定論的なツールに委任し、判断が必要な箇所にトークンを費やします。その分業こそがこのパターン全体です。dshはコードを書き、CLIはAPIレイヤーを検証し、あなたはテストコードを一切書くことなくApidogでシナリオを作成します。
dshが実際に実行したことを確認する
エージェントは、実際には達成していない成功を報告することがあり、開発者プレビューのハーネスでは、記述を鵜呑みにすべきではありません。問題を捕捉する順番で、3つのチェックがあります。
まず、コマンドが実行されたことを確認します。dsh Web UIには、セッション中のエージェントのツール呼び出しとその出力が表示されます。文字通りのapidog run ...というbash呼び出しとその結果を探してください。エージェントがテストを実行したと言っているのにそのような呼び出しが表示されない場合、それは実際には行われなかったことを要約しただけです。再度実行して生出力を表示するように依頼してください。
次に、終了コードを確認します。直接尋ねてください。「そのapidog runコマンドの終了コードは何でしたか？」ハーネスは失敗時に明示的な[exit code: N]マーカーをエージェントに渡すため、曖昧さが隠されることはありません。エージェントの要約が「テストは合格した」と述べていても、マーカーがゼロ以外を示している場合、マーカーが正しいです。
3番目に、それが実際のシナリオを使用したことを確認します。「シナリオが見つかりません」という失敗は、通常、エージェントがIDを捏造したか、間違って覚えていることを意味します。AGENTS.mdブロックとApidogのCI/CDタブにあるコマンドに対して、-tと-eの値を再確認してください。ルールファイル内のIDが真実であり、エージェントが入力した他のものは推測です。
オプション: 仕様アクセス用にApidog MCPサーバーを追加する
シナリオを実行することは検証をカバーします。コードを書きながらエージェントにAPI仕様を読み取らせたい場合は、それはMCPの仕事であり、ここでは正直な情報が重要です。2026年8月後半の時点では、MCPのサポートはDeepSeek HarnessのコアREADMEやユーザーガイドには文書化されていません。存在するのは、エコシステムの他の部分と同様にdsh-plugin GitHubトピックを通じて発見されたコミュニティプラグイン hyqhyq3/dsh-mcp-managerです。これは設定にMCPページを追加し、リモートHTTPおよびローカルstdioサーバーをサポートし、ツールをmcp__<name>__*として登録し、<workspace>/.dsh/dshmm/mcp.jsonからプロジェクトごとのサーバー定義を読み取ります。
それを通じてApidog MCPサーバーに接続できます。これはMCP経由でAPI仕様を公開し、シナリオが失敗した後ではなく、ハンドラーを記述する前にエージェントがエンドポイントの実際のスキーマをチェックできるようにします。コミュニティプラグインと開発者プレビューホストの組み合わせは、どちらかの側の更新で壊れる可能性があるため、ボーナスレイヤーとして扱ってください。上記のCLIパスは主要なものであり、シェル以外何も必要ありません。
プレビューに関する注意点と今後の展望
DeepSeek Harnessは急速に進化しており、互換性を損なう可能性があると警告しています。最も変更される可能性が高いのは、ここで挙げられている詳細です。つまり、指示プラグインのファイル候補、bashツールのサンドボックスレポート、そしてコミュニティMCPプラグインが触れるあらゆるものです。しかし、このパターンはポータブルです。「この1つのコマンドでAPIを検証する」と記述されたルールファイルと、クリーンな終了コードを返すCLIは、Claude Codeやこのシリーズの他のすべてのハーネスで機能するのと同じ理由で、今日のdshでも機能します。エージェントはコマンド出力を読み取るのが得意であり、それなしでは信頼性が低いからです。
というわけで、Apidogをダウンロードし、1つのテストシナリオを視覚的に構築し、CI/CDタブからそのapidog runコマンドをコピーして、リポジトリにすでにある可能性のあるAGENTS.mdにブロックを挿入してください。次回DeepSeek HarnessがあなたのAPIコードに触れるとき、作業が完了したと伝える前に、自身で作業を確認するでしょう。
よくある質問
DeepSeek HarnessはAGENTS.mdをネイティブに読み込みますか？はい。@deepseek-ai/dsh-agent-instructionsプラグインは、プロジェクトルートおよびセッションの作業ディレクトリより上位のディレクトリからAGENTS.md（またはフォールバックとしてCLAUDE.md）をロードし、さらにAGENTS.local.md/CLAUDE.local.mdオーバーレイと、~/.dshにあるユーザーグローバルのAGENTS.mdをロードします。他のエージェントのためにすでにAGENTS.mdを保持している場合、dshはそれを変更せずに読み込みます。
dshでApidog CLIを使用するためにDeepSeekの有料プランが必要ですか？いいえ。ハーネスはMITライセンスのオープンソースであり、モデルはご自身で用意します。カタログプロバイダーはAnthropic、OpenAI、Bedrock、Vertex、Azureをカバーしており、カスタムゲートウェイはDeepSeek Harnessで任意のモデルを実行する方法で説明されているように、settings.yamlを通じて機能します。Apidog CLI自体は無料のnpmパッケージであり、特定のモデルではなくApidogテストシナリオと認証が必要です。
エージェントの2番目のコマンドが、最初のコマンドで変更したディレクトリを忘れるのはなぜですか？設計によるものです。デフォルトのdsh bashツールは、すべての呼び出しを新しいシェルで実行するため、cdはコマンド間で保持されません。ツールのworkdirパラメーターを渡すか、より簡単に、ルールファイル内で完全なapidog run呼び出しを1行に保つことで、何も忘れることはありません。
dshは毎回尋ねずにシナリオを実行できますか？それはアクティブなパーミッションポリシーに依存します。Web UIは、そのポリシーの下で承認が必要な操作の前に尋ねます。ユーザーガイドにはポリシーレベルが列挙されていないため、お使いのデプロイメントが何を許可しているかを確認するには、ビルドの設定をチェックしてください。プロンプトが表示された場合、ステージングに対するapidog runを承認することは安全な「はい」です。