ここ最近2日間、AI開発者コミュニティはほとんど同じ名前で埋め尽くされている——DeepSeek Harness、コミュニティではより慣習的にdshと呼ばれている。これがオープンソース化されてわずか2日で、すでに約100k個のStarを獲得した。このペースでいけば、もしかすると本当にOpenClawのStar数を追いかけるチャンスがあるかもしれない。しかし私がもっと気にしているのは数字ではなく、一つの疑問だ。なぜDeepSeekは自前でHarnessを作るのか？私が使い慣れているClaude CodeやCodexとは本質的に何が違うのか？この問いに答えるため、私は丸一日を全力で実測した。インストール、Keyの設定、ディレクトリの選択、権限の調整から、タスクの軌跡をじっと見つめて一歩一歩作業する様子まで、踏んだ穴と快感のポイントをすべて記録した。このチュートリアルは入門したばかりのアプリケーション開発者向けで、「すべてがプラグイン」という設計理念を分解して説明し、dsh webの完全な導入経路を一歩ずつたどり、どのいくつかの箇所が最も人を挫折させやすいかも伝える。読み終えれば、少なくとも自力でdshを動かせるようになり、各スイッチの裏で実際に何が動いているのかが分かるはずだ。

「モデルは脳」から始める：なぜDeepSeekは自前でHarnessを作るのか

DeepSeek Harnessの意義を理解するには、まず「Harness」という言葉をはっきりさせなければならない。多くの初心者はこの言葉を初めて見ると戸惑う。なぜなら、フレームワークにもSDKにも見えないからだ。実は非常に率直な比喩が使える。モデルは脳であり、Harnessはモデルの身体である。脳がどんなに賢くても、コマンドを打つ手がなく、ファイルを読む目がなく、前に何が起きたかを覚える記憶がなければ、それはただのおしゃべりできる思考マシンにすぎない。Harnessがやるべきことは、この身体を完全に整えることだ。ツールを呼び出せる両手、ファイルやディレクトリを読める目、コンテキストを管理できる記憶システム、そしてその行動を制約する一連のガードレールを与える。

この比喩を土台にして、すでに馴染みのあるAgentという概念を再び分解すると、非常にすっきりした公式が得られる。Agent = LLM + Harness。ここでLLMは「考える」を担当し、Harnessは「行う」を担当する。考える部分はモデルの重みの中の話であり、行う部分はエンジニアリングの話だ——ツールをどう登録するか、結果をどう埋め戻すか、コンテキストが超過したらどう圧縮するか、危険な操作を止めるかどうか。これまで私たちがAIアプリケーション開発を行うとき、実はほとんどの精力を「行う」半分、つまり自分でHarnessを書くことに費やしてきた。これは、dshというフレームワークが出たときにみんながこれほど興奮した理由も説明している。Harnessという層を直接オープンソース化し、しかも改造のための十分に大きな口を残したのだ。

次にDeepSeekの今回の役割の変化について。以前私たちがDeepSeekモデルを使うとき、その経路は基本的にすでに誰かが作ったAgentに接続することだった——オープンソースのAgentフレームワークであれ、あるCoding Agentであれ、DeepSeekはその中で「呼び出される脳」の役割を演じるだけで、身体は他人が与えたものだった。モデルベンダーの立場は実はやや受け身だった。自社のモデル能力がどんなに強くても、最終的に出てくる効果はホストHarnessのツール設計とコンテキスト戦略に制約される。ユーザーがカクつきを罵るとき、その責任はモデル側には全くないかもしれない。今回DeepSeekが自ら参入し、自社モデル専用のAgentフレームワークを作ったことは、「脳」と「身体」の適応権を自分たちの手に取り戻すことに等しい。公式の入口はhttps://www.deepseek.com/harness/にあり、ここから入るとインストール方法とドキュメントが見られる。

そしてその最もクールな点は、五つの言葉で要約できる。すべてがプラグイン。これはマーケティングのスローガンではなく、非常に具体的なアーキテクチャ上の決定だ。dshでは、モデル、ツール、戦略、ストレージ、サンドボックス、コンテキスト管理、さらにはUIまで、すべてが積み木のように組み立てたり外したりできるプラグインとして抽象化されている。ツールだけを替えてモデルは動かさないこともできるし、コンテキスト戦略だけを替えてUIは動かさないこともできる。この自由度の価値は、「Agentを再組み立てする」ことを、一度の書き直しのエンジニアリングではなく、設定可能な事柄に変える点にある。入門開発者にとっては、コードを書かずに、設定と組み合わせを通じて、Agentの各構成部品がどうかみ合っているのかを理解することから始めてもいい。

「すべてがプラグイン」をより具体的に説明するために、交換可能な部品の次元に分解し、従来のやり方と dsh の考え方を比較してみます：

部品の次元従来の自作 Harness のやり方dsh「すべてがプラグイン」の考え方
モデル（Model）コード内に特定ベンダーの API とパラメータをハードコードする交換可能なプラグインとして扱い、モデルを替えても他の部分は変更不要
ツール（Tool）関数レジストリと JSON Schema を手書きする100 以上のプラグインを内蔵し、必要に応じて有効化・交換
ポリシー（Policy）権限判定が各ツールの実装に散在しているポリシープラグインとして集約し、権限レベルを一元管理
ストレージ（Storage）自分でデータベースやローカルファイルに接続するストレージプラグインとして抽象化し、実装を交換可能
サンドボックス（Sandbox）自分でコンテナや仮想マシンの分離を構築するサンドボックス機能をプラグイン化し、分離強度を調整可能
コンテキスト管理切り詰めや要約のロジックを自分で書くコンテキスト管理をプラグイン化し、圧縮戦略を交換可能
UIフロントエンドを自作するか、CLI のみを提供するUI もプラグイン層であり、公式が Web UI をそのまま提供

この表は、よくある疑問に実は答えています。なぜ既製の Agent を使い続けるのではなく、dsh をわざわざ別途学ぶ価値があるのか。なぜなら、学べるのは「あるツールの使い方」だけでなく、「一つの Agent がどの部品から組み立てられているか」だからです。このメンタルモデルは、別のフレームワークに移ってもそのまま使えます。

dsh web は CLI ではない：コマンド一つで Web UI を開くインストール手順

ここからは実践です。まずインストールですが、今回私はかなり「AI Native」な方法を使いました：AI に任せられることは AI に任せる。インストールドキュメントを一行ずつ読んで打ち込むのではなく、普段使っている Agent を開き、次の自然言語プロンプトを送りました：

DeepSeek Harness https://www.deepseek.com/harness/ をインストールして

このプロンプトのポイントは公式リンクを含めることです。Agent がページ上のインストール手順を自分で読み、どのコマンドを実行すべきか判断します。全体の所要時間は約 5 分でインストールでき、途中はほぼ介入しませんでした。この体験自体が象徴的です。dsh のインストールを別の Agent が完了できるということは、外部に公開しているインターフェースが十分に明確で、プログラムが理解できることを示しています。

インストール後、次のコマンドを実行します：

dsh web

するとブラウザが自動的にウェブページを開きます。正直に言うと、最初は少し戸惑いました。私の予想では、dsh は Claude Code のような CLI Coding Agent か、Codex のようなデスクトップアプリだと思っていたのに、開いたのは Web UI だったからです。これは確かに少し意外で、DeepSeek がインタラクションの形態でまた一波のイノベーションを起こしたと言えます。

ここでは三つの形態の違いをはっきり説明しておく必要があります。形態は、あなたがそれをどう使えるか、そして誰に適しているかを直接決めるからです：

形態代表インタラクションの入口導入ハードルと対象ユーザー
CLI コマンドラインClaude Codeターミナルでコマンドを打つハードルはやや高め、ヘビーな開発者には手に馴染む
デスクトップCodex独立した App ウィンドウハードルは中程度、グラフィカルなインターフェースに慣れた開発者に適する
Web UIDeepSeek Harness（dsh web）ブラウザで開くローカルページハードルは低め、ページがそのままワークベンチだが、設定項目はやや硬派

Web UI を選ぶことには見落とされがちな利点があります。それは「会話履歴」「タスクエリア」「タスク軌跡」といった情報を同じ画面に広げて配置するのに本質的に向いており、情報密度がターミナルでのスクロール出力よりずっと高いことです。しかしこれも諸刃の剣で、ページ上の要素が多くなると、初心者はかえってどこから手を付ければいいか分からなくなりがちです。そこで次の節では、まず最も重要な接続性を確実に通します。

もう一つ、エンジニアリング上のちょっとした注意点があります。dsh web は本質的にローカルサービスを起動するもので、ブラウザはあくまでフロントエンドの外殻にすぎません。つまりページが使えるかどうかは、背後にある dsh プロセスがまだ生きているかどうかにかかっているということです。この点については後で落とし穴を一つ專門に説明しますが、ここではまず覚えておいてください。タスクが詰まったとき、最初にすべきはターミナル内のプロセスを見ることではなく、Web ページ上のタイマーをぼんやり眺めることではありません。

API Key を手に入れたら：Key を入力し、残高をチャージし、最初の会話を動かす

Web ページは開きましたが、この時点ではまだ作業できません。dsh を実際に動かすには、以下の三つの手順を順番に完了する必要があり、どれか一つでも欠けると動きません：

  1. DeepSeek 公式 API プラットフォームで API Key を作成します。これは dsh が DeepSeek モデルを呼び出すための身分証明であり、これがなければ頭脳がつながっていないのと同じです。
  2. Key をコピーして dsh の Web ページに貼り付けます。ページに入力欄が用意されており、貼り付けて保存すれば、dsh はモデルを呼び出す資格情報を手に入れます。
  3. あらかじめ DeepSeek アカウントにお金をチャージしておきます。モデルの呼び出しで消費される Token は課金対象であり、残高が不足するとリクエストは失敗します。

ページ上のこれらの重要な位置を文章で説明しておくので、照らし合わせて探してください。dsh のページに入ると、左側は皆さんお馴染みの会話履歴エリアです。中央はタスクエリアで、作業ディレクトリと実行モードを選べます。API Key を入力する入口は、ページの設定関連エリアにあります。Key を入力すれば、dsh は正常に使えるようになります。

この三つの手順のうち、最も見落とされやすいのは三番目です。多くの人は Key を入力すれば万事整ったと思い込み、いざタスクを送るとエラーになり、半日かけて原因を探ってネットワークの問題だと思い込むのですが、実際はアカウント残高がゼロなのです。ですから私の提案はこうです。まずチャージを済ませてから、最初の会話をクリックする。これで無駄な自己懷疑をかなり省けます。

もう一言注意しておくと、API Key は機密性の高い資格情報です。公式プラットフォームで権限範囲と额度上限を設定しておき、むやみに公開の場に貼り付けないことをおすすめします。dsh は Key をローカル設定に保存するので、設定ファイルを Git リポジトリにコミットしない習慣を身につけてください。これはサードパーティのモデル API を組み込むあらゆるプロジェクトと同じです。

まず作業ディレクトリを選んでから話し始める：dsh のタスクエリア三種の神器

DeepSeek Harness を初めて開くときは、まず 2 か所を見て、ページの空間構造を覚えることをおすすめします。左側は会話履歴、中央はタスクエリアです。タスクエリアでは最も重要な 2 つのこと、つまり作業ディレクトリの選択と実行モードの選択ができます。この 3 つ（履歴、ディレクトリ、モード）が dsh の基本的な操作フレームワークを構成しており、私はこれを「タスクエリア三種の神器」と呼んでいます。

ここで必ず強調しておきたい厳格な前提があります。dsh はまず作業フォルダを選択しなければ、会話を行うことができません。つまり、普通のチャットボットのように開いてすぐ質問できるわけではありません。この設計は実際には Harness の本質によって決まっています。Agent には「身体」が必要であり、身体には活動範囲が必要です。作業ディレクトリは、その手足が届く地面の一片です。範囲を指定しなければ、どこでファイルを読み、どこでファイルを書くべきか分かりません。

正しい順序は次のとおりです。

  • まずコンピュータ上に作業ディレクトリを新規作成します。たとえば今回のタスク専用のフォルダを別に作り、メインプロジェクトを汚染しないようにします。
  • 次に dsh のタスクエリアで、dsh にこのディレクトリを開かせます。
  • ディレクトリの読み込みが完了してから、通常の会話やタスクの開始を行います。

コマンドライン環境から来た方なら、次のコマンドでクリーンな作業ディレクトリを用意するとスムーズです。

mkdir -p ~/workspace/dsh-demo && cd ~/workspace/dsh-demo
git init
echo "# dsh demo workspace" > README.md
git add . && git commit -m "chore: init dsh demo workspace"

こうする理由は非常に現実的です。1 つ目は、試験環境と実際のプロジェクトを分離することで、たとえ Agent が誤ってファイルを変更しても損害を制御できることです。2 つ目は、事前に git init しておけば、あらゆる変更を git diff で追跡でき、Agent の操作にロールバック可能な安全クッションを敷くことになるからです。dsh の挙動に十分慣れ、十分信頼できるようになってから、メインプロジェクトを直接開かせても遅くはありません。

ついでに言うと、タスク実行後、dsh は今回のタスクの Token 消費量やキャッシュヒットなどの情報を一覧表示します。このフィードバックループは非常に重要で、「今回のアイデアにいくらの価値があったか」を直感的に確認できます。また、コンテキストが膨らみすぎてキャッシュヒットが低下し、コストが高くなっていないかを判断するのにも役立ちます。毎回のタスク後にこれらの数字をちらっと見る習慣を身につけることは、後から請求書を確認するよりはるかに有用です。しかも、要約だけでなく、今回のタスクの完全な軌跡も表示され、それが実際にどのように一歩ずつ作業したのかを振り返ることができます。モデルがどんなプロンプトを受け取ったか、どのツールを呼び出したか、どのファイルを変更したか、どのようにコンテキストを圧縮したか、すべてそこに残っています。Agent の実行プロセスを学びたい人にとって、これは基本的にブラウザの開発者ツールにおけるリクエスト追跡と同じであり、追跡対象が Agent の思考と行動に置き換わっただけです。

権限 3 段階の選び方：Read Only / Workspace Write / Full Access

作業ディレクトリを選んだら、次に向き合うのはダイアログボックス左下の権限コントロールです。この 3 段階の権限は、dsh が実際にあなたのファイルを触れるかどうかを決めるもので、安全性において最も重要なスイッチです。必ず理解してから操作してください。

3 つの段階の境界を 1 つずつ分解します。

権限段階できること範囲を越えたときに何が起こるか推奨される使用場面
Read Only（読み取り専用）デフォルトではファイルを読むことだけができ、変更はできませんあらゆる書き込み操作がブロックされますコードを見てもらう、コードレビュー、質問への回答だけをしたい場合
Workspace Write（ワークスペース書き込み）現在の作業ディレクトリ内のファイルを変更できます作業ディレクトリの範囲を超える操作に遭遇すると、まず確認を求めます日常で最もよく使う段階で、プロジェクト変更の第一選択
Full Access（完全アクセス）作業ディレクトリ内外のファイルを変更できます確認は表示されず、直接実行されます次に何をするのか完全に把握している場合にのみ使用

こうして比べてみるとよく分かります。Read Only は「まず見てから判断する」探索型のタスクに向いています。たとえばコードベースを一通り読ませたり、ある関数がどこにあるかを特定してもらう場合です。Workspace Write は普段最もよく使う段階で、プロジェクトのファイルを直接変更でき、同時に範囲外へのアクセス時に確認を求めるというゲートも残しているため、安心感が比較的高いです。Full Access は事実上ガードレールを外した状態で、作業ディレクトリの内外を問わずファイルを変更でき、しかも確認ダイアログが表示されなくなります。

Full Access について、私の態度は明確です。この権限は気軽に有効にしないでください。次に何をするかを明確に予測でき、かつバックアップやバージョン管理による保護をすでに用意している場合にのみ、この段階への切り替えを検討してください。理由は簡単です——dsh の強みは自律的な実行にあり、自律的な実行が「確認なし + 全書き込み可能」と組み合わさると、エラーが起きたときに注意を促す機会すら得られません。入門者にとっては、ほとんどのタスクは Workspace Write にとどまれば十分であり、ディレクトリ外のファイルを読む必要があるときに一時的に調整すればよく、最初からすべてを開放する必要はありません。

権限のほかに、ダイアログの右下では DeepSeek モデルと推論レベル も選択できます。私がページ上で見たデフォルトの選択肢には DeepSeek V4 Pro と DeepSeek V4 Flash があります。同時に、タスク領域には実行モードの選択肢がもう一组追加されています。これらのモード名は威圧的に聞こえますが、4 つのモードの違いは実はそれほど複雑ではありません。まずそれらと権限の関係を整理して、全体像を把握しやすくしましょう。

  • 標準モード：普段はこの段階で十分です。ファイルの閲覧、コードの変更、コマンドの実行、情報の検索、Skills の呼び出し、サブ Agent の手配など、これらの一般的な操作がすべて可能です。
  • PTC モード：ステップが多く、フローの長いタスクに適しています。標準モードのすべての能力を持ち、違いは複数のツール操作を TypeScript プログラムとして記述し、それを連結して実行する点です。
  • 極簡モード：モデルに残すのは 2 つの基本ツールだけです。1 つは Bash コマンドを実行するもの、もう 1 つはファイルを変更するもので、その他の能力はすべて取り除かれます。
  • 創造モード：自分で Agent をカスタマイズしたい人向けに用意されています。現在の実行環境を確認し、さまざまなプラグインを試し、必要なツールと能力を組み合わせて新しい Agent モードを作れます。

この中で最も掘り下げる価値があるのは PTC モード です。なぜなら、これは dsh のコンテキスト管理における巧みな設計を体現しているからです。通常モードでは、モデルがツールを呼び出すたびに、その結果を新たな入力としてモデルに戻す必要があります。やり取りの回数が多くなると、コンテキストが膨らみやすくなり、Token を浪費するうえに要点を見失いやすくなります。PTC モードのやり方は、複数のツール操作をTypeScript プログラムとして記述し、それを連結して実行するというものです。こうすれば中間データを一巡ごとにモデルに戻す必要がなく、最後に結果だけをコンテキストに送り返します。ツール呼び出しが特に多いタスクでは、やり取りの回数を減らせると同時に、コンテキストがどんどん膨らむのを避けられます。たとえばファイルの一括処理、データの連続クエリ、あるいは一連の操作フローを実行する場合、このモードがより適しています。

具体的な比較で 2 つのモードの違いを感じてみましょう。タスクが、あるディレクトリ下の一群のファイルを統一的に処理することだとします。標準モードでの経路はおおよそ「ツールを 1 回呼ぶ → 結果がモデルに戻る → また呼ぶ → またモデルに戻る」という繰り返しです。一方、PTC モードは以下のように複数のステップを 1 つのプログラムに連結した形に近くなります。

// PTC モードの考え方の示意：複数のツール操作を 1 つのプログラムに連結して統一的に実行
// 中間結果はプログラム内部に留め、最終結果だけをコンテキストに書き戻す
type Step = { name: string; run: () => Promise<unknown> };

async function runPipeline(steps: Step[]) {
  const results: Record<string, unknown> = {};
  for (const step of steps) {
    // 各ステップはプログラム内で完結し、モデルのコンテキストに逐条戻すことはしない
    results[step.name] = await step.run();
  }
  // 集約された結果だけをコンテキストに送り返す
  return results;
}

// 使用例
export async function main() {
  const steps: Step[] = [
    { name: "scan", run: async () => "対象ディレクトリのファイル一覧をスキャン" },
    { name: "filter", run: async () => "処理が必要なファイルを絞り込む" },
    { name: "transform", run: async () => "変換操作を一括実行" },
    { name: "summary", run: async () => "処理結果のサマリーを生成" },
  ];
  const out = await runPipeline(steps);
  console.log(out);
}

main();

このコードは dsh の内部実装ではなく、PTC の「複数ステップのツール操作を一つのプログラムに収束させる」という思考モデルを理解するためのものです。重要なのは中間結果をどこで処理するかです。それはプログラムの内部を流れ、モデルとツールの間を行き来して運ばれるのではありません。これを理解すれば、どのタスクを PTC に切り替えるべきか、どのタスクは標準モードのままでよいかを判断できるようになります。

ミニマルモードについては、どちらかといえばモデルに「ベアメタルテスト」を行うようなものです。コマンドラインとファイル編集という二つのツールだけに頼って、モデルがどこまでできるかを見ます。日常的に使うならわざわざ選ぶ必要はありませんが、モデルの「基礎体力」を観察したいなら、このモードはとても面白いです。クリエイションモードはカスタマイズ派に残されたもので、前の三つのモードは仕事をこなすためのもの、このモードは「モードを作る」ためのものです。プラグインを設定したい場合は設定ページで探せます。現在、公式の組み込みプラグインはすでに 100 以上あり、今後もさらに増えていきます。

最後に、私が実測で踏んだあの落とし穴に戻ります。これは権限やモードと同じく「見なければ引っかかる」タイプのものだからです。dsh が特定のタスクで長時間止まっていることに気づいたら、まずぼんやり待たないでください。ターミナルを開いて、dsh web が本当にまだ動いているかを確認するのがよいです。私もこの落とし穴を踏みました。すでに dsh web プロセスを終了していたのに、ページの「Deep diving」はまだカウントを続けていて、DeepSeek がバックグラウンドでまだ猛烈に考えているように見え、非常に紛らわしかったのです。つまり、ページ上の時間が増え続けているのを見ても、タスクがまだ生きているとは限らないということです。この体験はかなりちぐはぐです。解決策は簡単です。「ターミナルのプロセス状態を見る」ことをトラブルシューティングの第一歩にし、ウェブのタイマーを眺めないことです。

権限をはっきりさせ、モードを正しく選び、プロセス状態を見られるようになれば、ここまでで実は dsh を動かし、一回の本物のタスクを完了できるようになっています。しかし、このフレームワークを他の Agent と本当に区別させるのは、一回のタスクの背後に残される観測可能な情報です。完全な実行軌跡、Token 消費の分布、コンテキスト圧縮の過程です。これらの情報をどう読み、読み取って何が解決できるのか、そして私が dsh + DeepSeek V4 Pro で走らせた実際の効果が「圧倒的だったのか、それともダメだったのか」——それは次の部分で引き続き分解していきます。

前の段落では、dsh をインストールから API Key の設定、作業ディレクトリの選択、権限の三档（Read Only / Workspace Write / Full Access）まで一通りたどりました。あなたはもうブラウザで正常にタスクを開始できるはずです。しかし「同じモデルなのに、なぜある人は速くて安く走らせ、ある人はずっと Token を燃やし続けるのか」を本当に決めるのは、次に出てくる二組のスイッチです。モデルと推論レベル、そして実行モードです。この段落では、一つずつ分解して説明します。

モデルと推論レベル：DeepSeek V4 Pro と V4 Flash をどう選ぶか

dsh の対話ボックスの右下に、二つの連動するドロップダウンがあります。一つはモデル選択、もう一つは推論レベルです。素材には、ページ上でデフォルトで見えるモデルオプションは DeepSeek V4 Pro と DeepSeek V4 Flash の二つだと明確に述べられています。この二つの名前は適当につけられたものではなく、その位置づけの違いは非常に大きく、間違えると代償も直接的です——遅いか、高いか、正確でないかです。

まず一つの前提をはっきりさせましょう。モデルは脳であり、Harness は身体です。dsh は V4 Pro と V4 Flash という二つの「脳」自体のパラメータ規模や訓練方法を変えることはできません。それがするのは身体を組み立て、脳がツールを使えるようにすることです。ですからあなたが選ぶモデルは、今回のタスクの知能の上限です。あなたが選ぶモードは、今回のタスクで身体がどれだけの動作をできるかの上限です。この二つの次元は掛け算の関係であり、代替の関係ではありません。

では具体的にどう選ぶのか？最もよくあるいくつかのシナリオに分けて整理してみます：

  • DeepSeek V4 Pro：能力がより高く、多段推論、ファイル横断的な理解、複雑なリファクタリング、難解なバグの調査が必要なタスクに適しています。実測では、私の「深水区」寄りのテストはすべて V4 Pro で実行しました——コンテキスト内の複数の手がかりを結びつけられ、途中で脱線しにくいからです。
  • DeepSeek V4 Flash：応答がより速く、「何をすべきかは分かっていて、ただ素早く実行してほしい」タスクに適しています。たとえば、一批のファイルの命名を一括変更する、確定したロジックをフォーマットに当てはめる、すでに考えが固まっているコマンドを実行する、構造が既知のデータを整理する、といったものです。

推論レベルについては、モデルが答えを出す前に「どれだけ考えるか」を制御します。レベルが高いほど、モデルが内部で展開する推論ステップが多くなり、難問に適します。レベルが低いほど、直接答えを吐き出すのが速くなり、簡単なタスクに適します。エンジニアリングで最もよくある間違いは、Pro + 高推論レベルで、Flash + 低レベルなら一瞬で終わることをやってしまうことです。結果として、コストは何倍もかかり、速度も半拍遅くなります。

選択の対照表をまとめたので、そのまま参照して選べます：

タスクの特徴推奨モデル推奨推論レベル理由
単一ファイルの小さな変更、命名置換、フォーマットV4 Flash低タスクが確定しておりステップが短い。長い推論は不要
バッチファイル処理、連続データクエリV4 Flash または V4 Pro中PTC モードと組み合わせて多段ツール操作を一つのプログラムに圧縮する
ファイル横断的なリファクタリング、アーキテクチャレベルの変更V4 Pro中〜高全体の依存関係を理解する必要がある。Flash は局所しか見られない傾向がある
難解なバグの特定、ログからの根本原因の逆推V4 Pro高手がかりが複数箇所に散在しており、長い連鎖の推論が必要
モデルの「素の能力」の下限を観察するV4 Pro必要に応じて極簡モードと組み合わせて対照実験を行う

ここで追加の注意点が一つ：モデル選択は一度きりの設定ではありません。同じセッション内で、まず V4 Pro でコードを読み、考えを整理してから、V4 Flash に切り替えて後続の繰り返し作業を行うことも十分可能です。これは最初から最後まで一つのモデルを使うより経済的です。逆に、最初に Flash を使ってみて、誤ったファイルを繰り返し修正したり、堂々巡りしたりするなら、無理をせず Pro に切り替えてやり直してください。無駄になる時間のほうが、節約した Token より高くつきます。

ちなみに、Token 消費とキャッシュヒットの状況は、タスク終了後に dsh が一覧表示します。このデータは非常に重要です——「今回モデル選択が正しかったかどうか」を判断する唯一の客観的な根拠だからです。あるタスクでキャッシュヒットが異常に低いのに Token 消費が高い場合、通常は会話コンテキストが頻繁に書き換えられていることを意味します。その場合は、モードを変えるか、タスクを小さく分割してください。

標準モード：ファイルを見る、コードを直す、コマンドを実行する、Skills を呼び出すデフォルトの設定

権限が解決するのは「あなたのファイルに触れられるかどうか」、モードが解決するのは「どのような姿勢で作業するか」です。dsh が提供する実行モードは一つではありませんが、一つだけ覚えるなら、それは標準モードです。

標準モードがカバーする操作の集合は、素材の記述に基づくと次のようないくつかのカテゴリにまとめられます：

  1. ファイルを見る：作業ディレクトリ内のソースコード、設定、ドキュメントを読み、プロジェクトへの理解を築きます。
  2. コードを変更する：ファイルの内容を直接編集し、具体的な変更を反映します。
  3. コマンドを実行する：shell コマンドを実行します。たとえばテストの実行、ビルドの実行、依存関係のインストール、プロセス状態の確認などです。
  4. 資料を調べる：外部情報を検索してコンテキストを補います。
  5. Skills を呼び出す：あらかじめ用意されたスキルをツールとして使い、その能力の境界を広げます。
  6. サブ Agent を配置する：つまりサブ Agent オーケストレーションで、大きなタスクをいくつかの小さなタスクに分割して配分します。

判断基準は非常に明快です：dsh に通常の開発タスクを完了させたいだけなら、そのまま標準モードを選んでください。コードを読む、バグを修正する、コマンドを実行して検証する、依存関係をインストールする、スキルを呼び出す、サブタスクを分割する——これらの一般的な動作はすべてその能力範囲内にあり、追加の設定は必要ありません。

標準モードがなぜデフォルトの階層になれるのか？核心は、それが「能力を全面的にカバーし、動作が予測可能」な階層であることにあります。ミニマルモードのように意図的にツールを削ることもなく、PTC モードのように実行方法をプログラムへ書き換えることもなく、その対話のリズムは最も直感的なものです：モデルが一歩考え、ツールを一度呼び出し、結果を見て、また次の一歩を考えます。

このリズムの代償は：各ステップの中間結果をすべてモデルのコンテキストに戻さなければならないことです。タスクのステップ数が増えると、コンテキストは雪だるま式に大きくなり、Token 消費を押し上げるだけでなく、コンテキスト圧縮を引き起こしやすくなり、圧縮の過程で重要な情報が失われる可能性もあります。したがって、標準モードが最も快適な領域は、「ステップ数が適度で、モデルが中間結果に応じて随時戦略を調整する必要がある」タスクです。

そのまま貼り付けて実行できる例を挙げます。標準モードでの dsh の典型的なワークフローを見るためのもので、指定した作業ディレクトリでファイルを読み、コマンドを実行し、さらにファイルを変更します。まず作業ディレクトリを作成し、バグのあるスクリプトを書きます：

mkdir -p ~/dsh-demo && cd ~/dsh-demo
cat > stats.py << 'EOF'
def average(nums):
    total = 0
    for n in nums:
        total += n
    return total / len(nums)

if __name__ == "__main__":
    print(average([10, 20, 30]))
    print(average([]))
EOF
python3 stats.py

実行してみると、2 行目で直接 ZeroDivisionError がスローされることがわかります。空のリストで除算を行っているためです。このとき dsh で作業ディレクトリを ~/dsh-demo に指定し、権限で Workspace Write を選び、モードで 標準モード を選び、そして十分に明確な指示を与えます：

stats.py を読んで、一度実行してエラーの原因を確認し、
修正案を示してファイルを直接変更してください：入力が空のリストのときは 0 を返し、
最後にもう一度実行して 2 つの出力がどちらも正常であることを確認してください。

「ファイルを読む → コマンドを実行してエラーを再現する → ファイルを変更する → もう一度コマンドを実行して検証する」という順序で一連の流れを進めるのがわかります。タスク終了後、右下に今回の Token 消費とキャッシュヒットの情報が表示されます。このようなタスクは標準モードの得意領域です：ステップ数は多くありませんが、各ステップで結果を見てから次のステップを決める必要があります。

注目すべきエンジニアリング上の細部が一つある。標準モードでは、受け入れ基準をプロンプトに書き込むことで往復を大幅に減らせる。上の「最後にもう一度再実行して、二つの出力がどちらも正常であることを確認する」という一文が、まさに受け入れ基準である。dsh は明確な基準を受け取ると、自分でセルフチェックのループを完結させる。修正が終わったらそこで止まってフィードバックを待つ、ということにはならない。

PTC モード：複数のツール呼び出しを一つの TypeScript として書いてから実行する

PTC モードは、この記事全体の中で最も時間をかけて理解する価値のある項目である。まず結論から言うと、標準モードの能力をすべて備えている。両者は「何ができるか」に差はなく、差は「どうやるか」にある。

標準モードの実行ループはこうだ：モデルが考える → ツール A を呼ぶ → 結果がモデルに戻される → モデルが考える → ツール B を呼ぶ → 結果がモデルに戻される……。各ステップの中間結果をすべてコンテキストに押し戻さなければならない。PTC モードは別の道を選ぶ。複数のツール操作を一つの TypeScript プログラムとして書き、それを連結して実行する。中間データを一ラウンドずつモデルに戻す必要はなく、プログラムが走り終わったあとに、最終結果だけをコンテキストへ返す。

この違いがもたらす利点は非常に実用的である：

  • やり取りの往復が数回減る：本来 N ラウンド必要だった「モデル—ツール—モデル」の往復が、一度のプログラム実行に圧縮される。
  • コンテキストが膨らみにくい：中間プロセスはプログラム内部に留まり、モデルのコンテキストに入らない。そのため圧縮が発動しにくく、情報も失われにくい。
  • 実行がより安定する：バッチ操作がコードに書き込まれ、順序も条件も決定的であり、あるラウンドでのモデルのランダムな判断によって逸れることがない。

素材で名指しされている典型的なシナリオは、ファイルのバッチ処理、データの連続クエリ、あるいは一連の操作フローの実行である。これら三種類のタスクに共通するのは、ツール呼び出しの回数は多いが、各ステップのロジック自体はモデルが何度も判断する必要がないという点だ。これを標準モードに任せると、中間結果が絶えずコンテキストに入ることでモデルが妨害される。PTC モードに任せれば、モデルは冒頭でプログラムをうまく書くだけでよく、あとは決定的な実行に委ねられる。

両者の仕組みの違いを並べて見るための比較表を挙げる：

観点標準モードPTC モード
能力セットファイルを見る、コードを変更する、コマンドを実行する、情報を調べる、Skills を呼ぶ、子 Agent標準モードと完全に同じ
実行形態ツール呼び出し一回につき一往復複数ステップの操作を一つの TypeScript にコンパイルして直列実行
中間結果の行き先ラウンドごとにモデルのコンテキストへ戻すプログラム内部に留まり、戻さず、最終結果だけを返す
コンテキストの負荷ツール呼び出し回数に応じて増大する大幅に低い
適したタスク結果を見ながら戦略を調整する必要があるファイルのバッチ処理、連続クエリ、一連のフロー実行

以下はそのまま貼り付けて実行できる例である。あるディレクトリに数百個のログファイルが詰まっていて、それらを一括でクリーンアップし、日付ごとに分類したいとしよう。標準モードでは、これによって数百ラウンドのツール呼び出しの往復が発生する。PTC モードなら、この TypeScript スクリプトの意図を渡すだけでよく、複数ステップの操作を連結して実行する役割を担い、最後に「何個のファイルを処理し、どのディレクトリに分類したか」といった集計結果だけをコンテキストに持ち帰る：

import { readdir, readFile, mkdir, writeFile } from "fs/promises";
import { join } from "path";

const SRC = "./logs";
const OUT = "./logs-cleaned";

async function main() {
  await mkdir(OUT, { recursive: true });
  const files = await readdir(SRC);
  let moved = 0;

  for (const f of files) {
    if (!f.endsWith(".log")) continue;
    const raw = await readFile(join(SRC, f), "utf8");
    // 空行と行頭のタイムスタンプノイズを除去
    const cleaned = raw
      .split("\n")
      .filter((line) => line.trim().length > 0)
      .filter((line) => !/^\d{4}-\d{2}-\d{2}/.test(line))
      .join("\n");
    // ファイル名の日付プレフィックスごとにサブディレクトリへ分類
    const date = f.slice(0, 10);
    const dir = join(OUT, date);
    await mkdir(dir, { recursive: true });
    await writeFile(join(dir, f), cleaned, "utf8");
    moved++;
  }
  return { moved, out: OUT };
}

main().then((r) => console.log(JSON.stringify(r)));

このコードの要点に注目してください。ループ内の readFile / mkdir / writeFile はすべてプログラム内部で完結しており、モデルは各ファイルの中身を一切見る必要がありません。最終的に得られるのは {"moved": 312, "out": "./logs-cleaned"} という一行のサマリーだけです。これが PTC が Token を節約する根本原理です——「プロセス」はプログラム内に残し、「結果」だけをコンテキストに持ち帰る。

どういうときに PTC を使うべきではないのでしょうか。タスク自体が中間結果に基づいてモデルに判断を求める場合——たとえば「まずテストがどこで落ちているかを見て、それからどのコードを修正するか決める」——なら、標準モードのほうが適しています。PTC の前提は、着手前に手順を明確に書き出せることだからです。書き出せないタスクに無理やり PTC を当てはめると、かえって実行し終えてから論理の誤りに気づくプログラムが出来上がってしまいます。

ミニマルモード：Bash 実行とファイル修正の二つのツールだけを残す

ミニマルモードの位置づけは、これまでのモードとはまったく異なります。それはモデルに二つの基本ツールだけを与えます。一つは Bash コマンドを実行するため、もう一つはファイルを修正するためで、その他の能力はすべて取り除かれます。Skills も、サブ Agent も、追加の調査ツールも、何もありません。

なぜこんなモードを作るのか。素材によれば、これはどちらかといえばモデルに対する「ベアメタルテスト」のようなもので、コマンドラインとファイル編集だけでモデルがどこまでできるかを観察するのに適しています。言い換えれば、これまでのモードが試すのは「Harness という身体がどれだけうまく組み立てられているか」であり、ミニマルモードが試すのは「この頭脳そのものがどれだけ強いか」なのです。

これは日常利用には向いていません。その点は素材ではっきり示されています。日常開発のほとんどのタスクでは、これを選ぶべきではありません。なぜなら、すでに手間を省いてくれる Skills やサブ Agent オーケストレーションといった能力を無駄に失うからです。その価値は実験シナリオにあります：

  • V4 Pro と V4 Flash が「コマンドライン + ファイル編集のみ」という条件でどれほど差があるのかを知りたいなら、極簡モードで同じタスク群を実行して比較します。
  • ある問題がモデル能力の不足によるものなのか、それとも Harness のツール設計が足を引っ張っているのかを検証したいなら、能力を最小限まで削ります。それでも問題が残るなら、原因はモデル側にあります。
  • Agent の最小実行ループがどのようなものかを研究したいなら、極簡モードが最も素朴なバージョンを示してくれます。

陥りやすい落とし穴が一つあります。極簡モードでは、モデルは Bash とファイル編集で多くのことを達成できますが、その各ステップを自分でコマンドラインで組み立てる必要があります。つまりコマンドへの依存度が非常に高く、少し複雑な操作は長い shell の連結になり、それに応じてエラーの確率も上がります。これは bug ではなく、「ベアメタル」を自ら選んだ必然的な代償です。したがって実験するときは、タスクを小さく分割し、一度に一つの変数だけを観察することをおすすめします。そうでなければ結果の帰属を判断するのが難しくなります。

創造モード：実行環境を確認し、プラグインを試し、自分だけの Agent モードを組み上げる

標準、PTC、極簡の三つが仕事をこなすためのものだとするなら、創造モードは「モードを作る」ためのものです。これは自分で Agent をカスタマイズしたい人のために用意されています。

創造モードでは三つのことができます：

  1. dsh の現在の実行環境を確認する：現在のこの Harness が何をロードし、何にアクセスできるのかを把握します。
  2. さまざまなプラグインを試す：素材では、公式の組み込みプラグインは現在すでに百個以上あり、今後も数は増え続けると述べられています。これらのプラグインは創造モードで一つずつ試せます。
  3. 必要なツールと能力を組み合わせて新しい Agent モードにする：どのプラグインが使いやすく、どの組み合わせが有効かを試した後、それらを組み立てて自分だけのモードを形成します。

このステップは「すべてはプラグイン」という設計理念のもとで理解する必要があります。dsh はモデル、ツール、ポリシー、ストレージ、サンドボックス、コンテキスト管理、UI といった能力を、積み木のように分解・組み立て可能なものにしています。創造モードは、積み木を組み立てるための作業台です。前述の三つのモードは本質的に、公式があらかじめ組み立てた三つの積み木セットです。創造モードは積み木を目の前に広げ、自分で組み立てさせるものです。

プラグインを設定したい場合は、設定ページで見つけられます。一つの提案は、最初からプラグインを積み上げないことです。プラグインを一つ増やすごとに、モデルが見る利用可能なツールが増え、選択コストも上がります。まず標準モードで、あるタスクに本当にどの能力が必要なのかを把握し、それから創造モードに戻って足し算ではなく引き算をしましょう。本当に使えるものだけを付け外しするほうが、プラグインで埋め尽くすよりも安定したモードになります。

創造モードにはもう一つ隠れた価値があります。それは「すべてはプラグイン」を理解するための最速の入口であることです。標準モードで見えるすべての挙動、たとえばコンテキストがどう圧縮されるか、ツールがどう呼び出されるかは、創造モードで対応する設定項目を見つけられます。dsh を長期的に使うつもりなら、この領域はいずれ触ることになります。

まとめとベストプラクティス

このセクションの要点を、そのまま実行できるチェックリストに圧縮します：

  1. まず権限を決め、それからモードを決める。コードを見るだけなら Read Only、通常のプロジェクト変更なら Workspace Write、Full Access は何をするのか完全に分かっているときだけ有効にします。
  2. モデルはタスクの難易度で選ぶ。単一ファイルの小さな変更、命名の置換、フォーマットには V4 Flash、ファイルをまたぐリファクタリングや難解な bug の特定には V4 Pro を使います。同じセッションの途中で切り替えてもよく、前半は Pro で方針を整理し、後半は Flash で反復作業を行います。
  3. 推論レベルを一律に最大にしない。タスクが確定的であるほどレベルは低くし、手がかりが分散していて長い連鎖の推論が必要なときだけ上げます。
  4. 通常の開発タスクはそのまま標準モードを使う。ファイル閲覧、コード変更、コマンド実行、資料検索、Skills 呼び出し、サブ Agent オーケストレーションをカバーし、直感に最も合うデフォルト段階です。
  5. 受け入れ基準をプロンプトに書く。たとえば「最後にもう一度実行して二つの出力が正常であることを確認する」とすると、dsh 自身に自己チェックの閉ループを完了させられ、やり取りを大幅に減らせます。
  6. ツール呼び出しが多く手順が長いタスクは PTC モードに切り替える。バッチファイル処理、連続的なデータ照会、一連のフロー実行は、多段操作を TypeScript の一連の処理にコンパイルして直列実行するのに適しています。中間データはモデルに戻さず、最終結果だけを返すため、コンテキストの負荷が大幅に下がります。
  7. 結果を見ながら方針を変える必要があるタスクは、引き続き標準モードを使う。手順を明確に書けないタスクに無理に PTC を当てはめると、実行し終えてから論理が間違っていたと分かるプログラムができるだけです。
  8. 極簡モードはモデルの下限を観察するためだけに使う。Bash 実行とファイル変更の二つのツールだけを残す「ベアメタルテスト」であり、日常開発に使ってはいけません。
  9. 創造モードは自分のモードを組み立てるために使う。その中で dsh の実行環境を確認し、プラグインを試し（公式組み込みはすでに百個以上あり、増え続けています）、さらに能力を再構成して新しいモードにします。組み立てるときは引き算をし、プラグインで埋め尽くさないようにします。
  10. 各タスク終了後に Token 消費とキャッシュヒットを確認する。これはモデルとモードの選択が正しかったかを判断する唯一の客観的根拠です。ヒットが低く消費が高い場合は、通常コンテキストが頻繁に書き換えられていることを意味するので、モード変更やタスクの細分化を検討します。
  11. 「Trajectory」で実行過程を振り返る。モデルがどんなプロンプトを受け取り、どのツールを呼び出し、どのファイルを変更し、どうコンテキストを圧縮したかは、Trajectory をたどって振り返れます。どのステップで誤りが起きたか、Token がどこで使われたかも特定できます。

これらのポイントを正しく押さえれば、同じ V4 Pro でも、あなたの手元と初心者の手元では、出てくる効率に桁違いの差が生まれます。次の段落では実際のタスク検証に入り、これらのパターンの組み合わせが実際のエンジニアリングでどれほど機能するのか、そしてあの「プロセスページを閉じてもまだ計時している」という落とし穴をどう避けるのかを見ていきます。

前の段落では、DeepSeek Harness の位置づけ、インストール経路、権限ティア、4 つの実行モードを一通り分解し、それが誰に向いていて誰に向いていないかについても話しました。この段落ではさらに深く掘り下げます。「すべてがプラグイン」の背後にある着脱可能な構造、タスク軌跡の読み方、Token 請求の突き合わせ方、落とし穴チェックリストの並べ方、そして最後にそのまま実践できる実践チェックリストを提示します。

100+ の組み込みプラグインと「すべてがプラグイン」：モデル、ツール、ポリシー、ストレージ、サンドボックス、コンテキスト、UI がすべて着脱可能

まず、最も見落とされやすい一方で、実は DeepSeek Harness の天井を最も大きく左右する点から話します。その設計理念はたった 5 文字——すべてがプラグインです。この 5 文字はマーケティングスローガンのように聞こえますが、エンジニアリングに落とし込むと、dsh の中で見えるもの、呼び出せるもののほぼすべてが交換可能な積み木であることを意味します。

これまでに Claude Code や Codex のようなツールを使ったことがあるなら、それらの多くが「モデル接続」「ツール呼び出し」「コンテキスト管理」といった环节を 1 つの固定フローに溶接してしまい、限られた設定項目の中で取捨選択するしかないことに気づくでしょう。dsh は別の道を進みます。Agent パイプライン全体を、いくつかのカテゴリの交換可能なコンポーネントに分解し、各カテゴリに独自のプラグインスロットを持たせています。

具体的にどこまで細かく分解されているのか。実測したページ構造と素材情報を踏まえると、次のように整理できます。

  • Model：基盤としてどの DeepSeek モデルを使うかは、プラグイン層が決めます。ページ上では既定で DeepSeek V4 Pro と DeepSeek V4 Flash を選択できますが、これはあくまで現在の組み込みオプションであり、モデル側自体がプラグインスロットです。
  • Tool：モデルが呼び出せる能力、たとえばファイルの読み書き、コマンド実行、情報検索、Skills の呼び出しなどは、すべてツールプラグインに載っています。ミニマルモードで Bash + ファイル変更の 2 つだけを残せるのは、まさにツール自体が丸ごと取り外せる積み木だからです。
  • Policy：権限ティアや実行モードといった「意思決定ルール」を含みます。Read Only / Workspace Write / Full Access の 3 段階の権限、および標準 / PTC / ミニマル / 創造の 4 モードは、本質的には異なるポリシーの組み合わせです。
  • Storage：会話履歴、タスク記録、実行軌跡といったデータの永続化方式も同様にプラグインスロットであり、必要に応じて交換できます。
  • Sandbox：モデルがコードやコマンドを実行する際の隔離環境も着脱可能で、どのファイルに触れ、どんなコマンドを実行できるかを決めます。
  • Context：プロンプトをどう組み立てるか、コンテキストをいつ圧縮するか、圧縮後に何を残すか。この一連のロジックもプラグイン化されており、後で軌跡を読むときにその痕跡が特に顕著に見えます。
  • UI：最も外側の Web インターフェースもプラグインの範疇です。これが、dsh が開く形態が Web UI であり、Claude Code のように CLI 寄りでも、Codex のようなデスクトップ形態でもない理由でもあります。インターフェース自体が組み立てられた 1 枚の殻であり、DeepSeek は今回のラウンドで形態上の選択を行ったのです。

このリストを理解すれば、なぜ dsh が「自由度が非常に高い」と言えるのかが分かります。それは固定された Agent を渡すのではなく、Agent の組立ラインを渡すのです。モデルを変えたい、ツールの組み合わせを変えたい、コンテキスト戦略を変えたいと思うとき、本質的にはソースコードを変えているのではなく、プラグインを交換しているのです。

では、これらのプラグインはどこで見て、どこで設定するのか？その答えは設定ページです。素材で言及されている重要な数字の一つは、現在公式の組み込みプラグインがすでに100 以上あり、今後もさらに増え続けるということです。この数字の意味は「多い」ことではなく、「箱を開けたらそのまま使える」という敷居をすでに越えているという点にあります。最初から自分でプラグインを書く必要はなく、組み込みの 100 以上だけでも、かなり多様な Agent の形を組み立てることができます。

「同じ土台、異なるプラグインの組み合わせ」ということを明確に説明するために、4 つの実行モードとそれに対応するプラグインの取捨選択を 1 つの表にまとめました：

実行モードツールプラグインの保持範囲コンテキストと実行の特徴典型的な適用シーン日常利用に適するか
標準モードファイル閲覧、コード修正、コマンド実行、情報検索、Skills の呼び出し、サブ Agent の手配通常のツール呼び出し、モデルと一巡ずつ対話通常の開発タスク、日常の主力適する、デフォルトの第一選択
PTC モード標準モードの全機能を備える複数のツール操作を 1 つの TypeScript プログラムとして書いてから連続実行し、中間データはモデルに戻さず、結果だけをコンテキストに返すステップが多く、フローが長く、ツール呼び出しが密集するタスク。例：ファイルの一括処理、連続的なデータ照会特定の重いフロータスクに適する
極簡モード基本ツールを 2 つだけ残す：Bash を実行するものとファイルを修正するもの。その他の機能はすべて外す「ベアメタルテスト」に近く、コマンドラインとファイル編集だけに頼る最小限の機能セットでモデルの挙動を観察する適さない、日常でわざわざ選ぶ必要はない
創造モード実行環境の閲覧、プラグインの試験、ツールの組み合わせを開放「モードを作る」こと自体に向き合い、新しい Agent モードを組み合わせられるAgent をカスタマイズする人、異なるプラグインを試験するカスタマイズ向けで、作業向けではない

この表で最も注目に値するのは PTC モードです。標準モードとの違いは「できるかどうか」ではなく「どうやるか」にあります：標準モードでは、モデルがツールを 1 回呼び、結果を 1 回受け取り、次のステップを考えるという流れで、中間データは一巡ごとにコンテキストに戻されます。一方 PTC モードでは、複数のツール操作をまず 1 つの TypeScript プログラムとして書き、連続実行し、中間データを往復させず、最後に結果だけをコンテキストに返します。この設計の直接的な利点は 2 つあります：1 つはやり取りの回数が減ること、もう 1 つはコンテキストがどんどん膨らみにくいことです。ファイルの一括処理、連続的なデータ照会、一連の操作フローの実行といったタスクでは、効果が特に顕著です。

すでに dsh をインストール済みで、プラグインスロットが実際にどんなものか自分の目で見てみたい場合は、以下のコマンドをターミナルで直接実行し、dsh のインストールディレクトリ構造を一覧表示して、それに照らしてプラグイン関連のディレクトリを探すことができます：

# dsh のグローバルインストール位置とプラグインディレクトリ構造を確認
# ステップ 1：dsh コマンド自体が利用可能か確認
dsh --version

# ステップ 2：グローバル npm パッケージディレクトリ下の dsh のインストールパスを一覧表示
npm ls -g --depth=0 | grep -i dsh

# ステップ 3：dsh パッケージディレクトリに入り、プラグインと設定関連のフォルダを探し出す
# 注意：<あなたのグローバル node_modules パス> を前のステップで出力された実際のパスに置き換えてください
ls -la <あなたのグローバル node_modules パス>/deepseek-harness

# ステップ 4：パッケージ内に plugins / skills / policies などのディレクトリがあるか確認
find <あなたのグローバル node_modules パス>/deepseek-harness -maxdepth 2 -type d | sort

これらを一通り実行すれば、「プラグインが結局どの層に入るのか」ということがほぼ把握できるはずです。設定ページを開いて照らし合わせて見れば、対応が取れます。ページ上で見えるモデルのドロップダウン、モード選択、権限レベルは、その背後でいずれも何らかの種類のプラグイン設定に対応しています。

もう一つ強調しておきたい細かい点があります。AI にやらせられることは AI にやらせるということです。素材で示されているインストール方法自体がこの考え方を表しています——いつも使っている Agent にそのまま一言送って、インストールさせるのです：

DeepSeek Harness https://www.deepseek.com/harness/ をインストールして

実際に試したところ、およそ 5 分でインストールできました。インストール後に dsh web を実行すると、ブラウザが直接 Web UI を開きます。ここで多くの人が最初に一瞬戸惑うポイントがあります。dsh は Claude Code のように CLI Coding Agent だろうと思っていたり、Codex のようにデスクトップ Agent だろうと思っていたのに、実際には Web UI が提供された、という点です。これは適当に選ばれた形態ではなく、「UI もまたプラグインである」という理念の自然な帰結です。インターフェースを着脱できるのであれば、当然ながら Web という層の殻として現れることも選べるのです。

続く初期化の操作もとても簡単です。DeepSeek 公式 API プラットフォームで API Key を作成し、その Key を dsh の Web ページにコピーして入力すれば、普通に使えます。唯一あらかじめ気に留めておくべきなのは、使用前に DeepSeek アカウントにお金をいくらかチャージしておくことです。モデル呼び出しで消費される Token は課金対象だからです。この点は後で説明する「請求ビュー」に直接関係します。

タスクトラジェクトリの読み方：プロンプト、ツール呼び出し、ファイル変更、コンテキスト圧縮がすべて記録に残る

もし dsh から一つだけ機能を選んで、Agent を学びたい人に勧めるとしたら、私はタスクトラジェクトリを選びます。

まず、それがどんな見た目で、なぜ読みやすいのかを話します。素材のたとえは非常に的確です。それはどことなくブラウザの開発者ツールにあるリクエスト追跡に似ています。DevTools の Network パネルで一度ページ読み込みを見ると、各リクエストの発生日時、パラメータ、レスポンス、所要時間が見えます。トラジェクトリパネルが与えてくれるのは、Agent が一度タスクを実行するときの同じ視点です——ただし追跡される対象が HTTP リクエストからモデルの各ステップの動作に変わっただけです。

鍵となるのは、トラジェクトリが記録するのは最後のチャット内容だけではないという点です。これは多くの人が初めて使うときに過小評価します。実際に残されるものには次が含まれます：

  • モデルがどんなプロンプトを受け取ったか：つまり各ラウンドでモデルに送られた完全な入力で、システムレベルのプロンプト、コンテキストの組み立て結果、現在のタスク記述を含みます。
  • どのツールを呼び出したか：各ステップでどのツールを選び、どんなパラメータを渡したか。
  • どのファイルを変更したか：書き込み操作がどのパスに落ち、内容のどの部分に触れたか。
  • どのようにコンテキストを圧縮したか：コンテキストがどのタイミングで圧縮され、圧縮後にどんな情報が保持されたか。

これら四種類の情報を並べて見ることは、実行チェーン全体に再生可能なログ層を備え付けることに等しいです。その結果、最も頭を悩ませる二つの問題にどちらも解決策が生まれます。どのステップでエラーが出たのかは、トラジェクトリをたどって逆に探せばよい。Token がどこで使われたのかも、同じくトラジェクトリをたどって逆に探せばよい。素材の原文はうまく言い表しています——基本的にすべてトラジェクトリをたどって逆に調べられる、と。

では、実際の操作ではどうやって一つのトラジェクトリを読むべきでしょうか。私はそれを四段階の方法に分解しました。順番に進めば基本的に迷いません：

  1. まず失敗点を特定し、それから成功パスを見る。タスクが失敗したら、最初から最後まで読むのではなく、まず最後にエラーが出たステップや成果物がおかしい箇所を探し、そのノードを特定してから、その入力がどこから来たのかを上流へたどる。
  2. プロンプトの組み立てを見る。同じツール呼び出しが失敗する場合、多くの場合はモデルがダメなのではなく、そのラウンドで受け取ったプロンプトに重要な情報が欠けているからだ。モデルに送られた完全な入力を確認すれば、「モデルの判断ミス」なのか「コンテキストが渡されていない」のかを素早く判断できる。
  3. ツールのパラメータを見る。ファイルパスの書き間違い、コマンド引数のスペルミスなど、初歩的だが頻度の高い問題は、ツール呼び出しノードで一目でわかる。
  4. コンテキスト圧縮ノードを見る。長いタスクで最も不可解な問題が起きやすいのは圧縮の周辺だ。圧縮前にモデルが覚えていた情報が、圧縮後には失われている可能性がある。あるノード以降でタスクが突然「記憶喪失」になったら、まずここを疑う。

この読み方をより具体的にするため、ブラウザ DevTools のトレース機能と対比し、ついでに「Trajectory にはどんなフィールドがあるのか」も明確にしておこう：

対比の軸ブラウザ DevTools のリクエストトレースDeepSeek Harness のタスクトラジェクトリ
トレース対象HTTP リクエスト / レスポンスモデルの各ラウンドのプロンプト、ツール呼び出し、ファイル変更
主な用途API エラー、パフォーマンスボトルの特定実行エラーステップ、Token の行き先の特定
最終成果物を含むかレスポンスボディを含む最後のチャット内容だけでなく、中間プロセスも含む
主要な記録項目URL、Method、Headers、Payload、Status、Timingプロンプト、ツール名とパラメータ、ファイル変更、コンテキスト圧縮記録
典型的な調査シナリオAPI 500、リクエストタイムアウトタスクのスタック、結果の誤り、Token の異常な増加
学習価値フロントエンドとバックエンドのやり取りの理解Agent の実行ロジックとツール呼び出し順序の理解

Agent の実行プロセスを学びたい人にとって、この表の右列はまさに既成の教材だ。モデルが何を受け取り、どう判断し、何を呼び出し、何を変更し、どう圧縮したか、すべて記録が残る。多く見ているうちに、「なぜ Agent はこう動くのか」という直感が自然と身につく。これは最終回答だけを見るよりはるかに価値がある。

ここでエンジニアリング上の実用的な提案をもう一つ：Trajectory を回帰テストとして使う。同じタスクを今日実行し、明日プラグインを変更したりモードを切り替えたりしてまた実行し、二つの Trajectory を比較すれば、「プラグインの変更が挙動の変化を引き起こしたのか、それともモデル自体の揺らぎなのか」が非常に直感的にわかる。これはカスタムプラグインのデバッグ時に特に役立つ——比較できるベースラインが常に必要だからだ。

Token 消費とキャッシュヒット：各タスク終了後の請求書ビュー

Trajectory が解決するのは「どう動いたか」、請求書ビューが解決するのは「いくら使ったか」だ。この二つは dsh では別々に表示されるが、続けて見るべきものだ。

素材で明確に言及されている点の一つは：タスク実行後、dsh は今回のタスクの Token 消費とキャッシュヒットなどの情報を一覧表示する。これは各タスク終了後に自動的に提供される請求書であり、わざわざ API プラットフォームで記録を探す必要はない。

この請求書を侮ってはいけない。それが現れるタイミングは絶妙で——ちょうど今回のタスクについての印象が最も強いときだ。すぐに三つのことを突き合わせられる：

  • どれだけの Token を消費したか：今回のタスク全体の使用量。
  • キャッシュヒットの状況：入力のうちどれだけがキャッシュヒットで再利用されたか。ヒットした部分としなかった部分ではコストが大きく異なるので、この数字が今回のタスクが高いかどうかを直接決める。
  • タスクの複雑さがコストに見合っているか：一見簡単な小さなタスクなのに Token 消費が異常に高いなら、通常はコンテキストが繰り返し運ばれているか、圧縮戦略が効いていないことを意味する。

そしてこの請求書と前節の軌跡は互いに裏付け合うことができる。あるタスクの Token 消費が高いと気づいたら、ただ眺めていてはいけない。軌跡に戻って探そう：同じ内容が繰り返しコンテキストに詰め込まれていないか？圧縮ノードが来るのが遅すぎないか？あるツール呼び出しが何ラウンドもループしていないか？これらは軌跡に痕跡が残っている。

これが、先に PTC モードを説明するときに「中間データを一ラウンドずつモデルに詰め戻す必要はない」と特に強調した理由でもある。請求書の視点から見ると、PTC モードの価値は「やり取りが何回か少なくなる」ことだけでなく、Token を中間の運搬にではなく、直接結果に使うことにある。ツール呼び出しが密集する長いフローのタスクでは、この違いは請求書にはっきりと表れる。

もう一つ、お金に直接関係する注意点：使用前に DeepSeek アカウントにいくらかチャージしておくこと。Token 消費は課金される。これはオプションではなく、前提条件だ。請求書ビューはコスト意識を養うのに役立つが、アカウント残高はチャージすべきときにチャージしなければならない。

止まって動かないときはまず待つな：dsh web プロセスと「Deep diving」タイマーが一致しない場合の調査チェックリスト

次はこの実測の中で最も単独で取り上げる価値のある落とし穴だ。なぜなら非常に紛らわしいからだ。

シナリオはこうだ：タスクを開始すると、ページに 「Deep diving」 が表示されて計測が続き、時間がずっと増えていき、DeepSeek がバックグラウンドでまだ猛烈に考えているように見える。あなたは待ちに待ち、かなり長く待つかもしれない。しかし実際の状況は——素材の実測体験によれば：dsh web プロセスはずっと前に閉じられていたのに、ページの「Deep diving」はまだ計測を続けている。

この現象は言ってしまえば複雑ではないが、杀伤力は小さくない。ページのタイマーが動いていることと、バックグラウンドのタスクが生きているかどうかは別物だ。プロセスがなくなっても、フロントエンドのタイマーはまだ動いている。だからあなたが見ている「ずっと考えている」は実は偽の姿だ。素材での評価は「体験がかなりちぐはぐだ」というもので、この表現はとても的確だ。

だから最初の規律はこれだ：dsh があるタスクで長く止まっていると気づいたら、まず愚かに待つな。待ち続けることは結果があることと同じではない。

正しい行動の順序を、以下の調査チェックリストにまとめた。これに従えば、ほとんどの「偽のフリーズ」はほぼ排除できる：

  1. ターミナルを開き、dsh web が実際にまだ動いているか確認する。 これが最初の動作であり、素材で明確に示された提案でもある。ブラウザでページを更新して解決しようとせず、まずプロセスを見る。
  2. プロセスがなくなっていれば、直接 dsh web を再起動する。タスクはおそらく再開始が必要だ。 ページのタイマーはタスクが本当に生きていることを意味しないので、待ち続けても成果物は出ない。
  3. プロセスがまだあれば、本当に長いタスクを実行しているのかを判断する。 このときはタイマーを睨むよりも軌跡を見るほうがはるかに役立つ——軌跡に新しいツール呼び出しがあるか、新しいファイル変更があるかが、タスクが生きている証拠だ。
  4. プロセスがあり、軌跡も動かないなら、それは本当に詰まっている。 このときはモードを変える、タスク範囲を狭める、あるいはコンテキストに詰め込みすぎていないかを確認することを検討する。
  5. 習慣にしよう：長いタスクではページだけを信じない。 ページのタイマー増加 ≠ タスクが生きている。この等式は dsh では成り立たない。

プロセスの生存状態とページの表示を突き合わせると、よりはっきりします：

ターミナル側の dsh web プロセスページの「Deep diving」タイマータスクの実際の状態あなたがすべきこと
まだ実行中増え続けているおそらく本当に実行中Trajectory で新しい動作があるか確認し、気長に待つ
すでに終了しているまだカウントアップしているタスクは実際にはもう存在しない（まだ考えていると誤判定しやすい）dsh web を再起動し、タスクを再投入する
まだ実行中増えているが Trajectory に新しい動作がない本当にハングしている疑いモードとコンテキストを確認し、タスクを絞るか段位を変えることを検討する

この表の核心的な結論はただ一言です：ページ上の時間が増え続けているからといって、タスクがまだ生きているとは限らない。これを覚えておけば、大量の無駄な待ち時間を節約できます。

プロセスの状態を素早く確認するには、以下のコマンドを使います。「動いているように見える」で判断せず、コマンドの出力で判断してください：

# dsh がまだ動いているか調査する：まずプロセス、次にポート

# 1. dsh 関連のプロセスが生きているか確認する
ps aux | grep -i "dsh" | grep -v grep

# 2. dsh web がローカルポートをリッスンする場合、そのポートでまだプロセスが待ち受けているか確認する
# 3000 を実際に見えているポート番号に置き換える
lsof -i :3000

# 3. とりあえず一度素早く確認したいだけなら：出力あり=プロセスあり、出力なし=プロセスはもうない
# このステップの出力結果こそが、タスクが生きているかを判断する根拠になる

これらのコマンドの使い方はとてもシンプルです：ステップ 1 はプロセス、ステップ 2 はポート、ステップ 3 は怠け者向けの素早い判断です。「まずターミナルを見てから結論を出す」という習慣を身につければ、もうタイマーに騙されることはありません。

2026 年 9 月に Harness を再び見る：プラグインエコシステムの膨張後の 3 つの新しい使い方

実測の現在から少し先を見据えると、DeepSeek Harness で最も期待されるのは今日何ができるかではなく、コミュニティのプラグイン規模が拡大し続けた後、何を組み立てられるようになるかです。素材の姿勢は明確です：最も価値があるのは、コミュニティに大きな改造の余地を残していること；エコシステムがますます狂気じみてくると、その後の姿はなかなか想像できません。この線を合理的に延長すると、2026 年 9 月という時点で、注目に値する 3 つの使い方の方向性がおそらく浮かび上がってきます。

第一：垂直なシーンを中心に専用 Agent を「組み立てる」。 モデル、ツール、プロンプト、コンテキスト、UI のすべてがプラグインを通じて調整できる以上、最も自然な遊び方は汎用 Agent で妥協するのをやめ、自分の実際のニーズを中心にこれらのコンポーネントを組み直すことです。同じ土台から、ある種のコードベースだけを理解するアシスタントが組み上がることもあれば、ある種のデータフローを専門とする実行体が組み上がることもあります。前述の 4 つのモードがすでにシグナルを示しています：標準モードは仕事を担当し、PTC モードは密集したフローを担当し、極簡モードは能力を絞ってテストを担当し、創造モードはモードを作ることを担当する——プラグインエコシステムが十分に豊かになったとき、創造モードの産出物が本当に価値を発揮します。

第二：プラグインでコンテキストとコストの問題を解決する。 コンテキスト管理自体がプラグインの枠であるということは、「いつ圧縮するか、圧縮後に何を残すか、どの内容を常駐させるか」といった戦略をすべてカスタマイズできるということです。請求ビューが示す Token 消費とキャッシュヒットの情報と組み合わせれば、自分のタスク種別に特化したコンテキスト戦略を調整し、コストを抑えられます。これは純粋なエンジニアリング上の利益であり、モデルを変えるよりも制御しやすいです。

第三の方法：Trajectory をチーム内のデバッグ規範として扱う。 Trajectory はプロンプト、ツール呼び出し、ファイル変更、コンテキスト圧縮を記録する。このトレーサビリティ能力は個人の学習用だけではない。Plugin の組み合わせが増え、挙動が複雑になると、「問題が起きたらまず Trajectory を見る」は個人の習慣からチームの規範へと変わる——なぜなら「どのステップで間違えたか」と「Token がどこに消えたか」の両方に同時に答えられるのは、それだけだからだ。

ただし、ハードルの高さも同時にはっきりさせておく必要がある。素材における dsh の位置づけは非常に率直だ：それは本質的に開発者向けである。これは、一般ユーザーには向かない可能性があることも意味する——たとえば事務作業に使おうと思っても、おそらく使いにくいと感じるだろう。あのハードコアな設定や機能は、理解できないし使いこなせない。さらに現実的な制約がもう一つ：現時点ではワンクリックインストールできる Skill マーケットが存在しない。Plugin の数は多いものの、「クリック一つでインストール完了」という統一的な入口がなく、非開発者にとってはまさに分厚い壁だ。

メリットとハードルを並べて見れば、自分が乗るべきかどうかを判断しやすくなる：

次元開発者にとっての意味一般ユーザーにとっての現実
すべてが Plugin自由にカスタマイズ可能。モデル/ツール/プロンプト/コンテキスト/UI をすべて交換できるハードコアな設定が多く、理解もできず使いこなせない
100 以上の内蔵 Plugin箱を開けた時点で組み立てるのに十分な素材があるどれを選べばいいか、どう設定すればいいか分からない
タスク TrajectoryAgent の実行ロジックをデバッグし学習するための利器情報量が多く、使う動機が乏しい
ワンクリックインストールの Skill マーケットがない許容範囲。自分で書くか手動で設定する参入ハードルが明らかに上がる
事務系の日常タスク通常は自分でツールを書く方が手に馴染むおそらく使いにくいと感じる

したがって 2026 年 9 月時点の判断は実は複雑ではない：Plugin エコシステムの膨張により dsh は開発者の手の中でますます強力になるが、その開発者向けの位置づけと欠けているワンクリックインストールマーケットは、短期的には自然に消えることはない。その恩恵を受けるには、自分で手を動かして組み立てる意思があることが前提だ。

まとめとベストプラクティス

最後に、この実測記事の核心的な結論を実行可能なチェックリストに圧縮する。インストール後にこれに従えば、かなりの落とし穴を避けられる：

  1. まず前提条件を片付ける。 普段使っている Agent からインストールコマンドを一行送るだけでよく、実測で約 5 分；dsh web を実行して Web UI を開く；DeepSeek 公式 API プラットフォームで API Key を作成しページに入力する；先にアカウントにいくらかチャージしておく——Token は課金対象だ。
  2. 会話の前にまず作業ディレクトリを作る。 dsh は作業フォルダを選択しないと開始できない。まずパソコン上にディレクトリを作り、それから dsh にそれを開かせる。
  3. 権限は必要に応じて選び、いきなり Full Access にしない。 コードを見るだけなら Read Only；プロジェクトを変更するなら Workspace Write（日常で最もよく使う。範囲外なら先に確認してくれる）；Full Access はガードレールを外すのと同じで、何をするか明確に分かっている時だけ使う。
  4. モードはタスクに応じて選ぶ。 日常開発には標準モード；ファイルの一括処理や連続的なデータ照会など、ステップが多く呼び出しが密集するタスクには PTC モード；極簡モードはモデルの素の性能を観察するのに使う；創造モードはカスタム Agent を組み合わせるのに使う。
  5. Trajectory を第一のデバッグ入口とする。 まず失敗点を特定し、次にプロンプトの組み立て、ツールパラメータ、コンテキスト圧縮のノードを見る；タスクが突然「記憶喪失」になったら、まず圧縮を疑う。
  6. タスクが終わるたびに一度請求を照合する。 Token 消費とキャッシュヒットを見る；消費が異常に高い場合は Trajectory に戻ってコンテキストの運搬と圧縮のタイミングを調べる。
  7. 詰まったらまずターミナルを開く。 dsh web プロセスがまだ生きているか確認する；ページの「Deep diving」タイマーが増えていてもタスクが生きているとは限らない；プロセスが消えていたら再起動して再送する。
  8. Plugin 設定ページを活用する。 公式内蔵 Plugin はすでに 100 以上あり、今後も増え続ける。まず一通り見てから自分で書くかどうかを決める。
  9. 自分に正直になる。 あなたが開発者なら、dsh の自由度と Trajectory 能力はきっと性に合う；主に事務作業を処理したいなら、現時点でワンクリックインストールの Skill マーケットがなく設定もハードコア寄りなため、おそらく使いにくいと感じるだろう。

加点として挙げたい実践が三つあります：

  • 同じタスクを二回実行し、二つの Trajectory を比較する。これにより、振る舞いの変化が Plugin によるものか、モデルの揺らぎによるものかを判断できます。
  • 長いタスクでは PTC を優先する。中間データをプログラム内に留め、何度もコンテキストに詰め戻さないようにします。
  • 「プロセスが生きているかどうか」をタスク状態を判断する第一の根拠とする。ページ上のタイマーはあくまで参考程度にします。

全体を通して実測した結果、私の結論はこうです：dsh は期待に値しますが、その価値は「箱から出してすぐどれだけ快適か」にあるのではなく、コミュニティに大きな改造の余地を残していることにあります。モデル、ツール、プロンプト、コンテキスト、UI のすべてを Plugin で調整でき、自分の実際のニーズに合わせて Agent の能力と働き方を組み直せます。確かに非常に開発者向けであり、確かに落とし穴もあります——特に、プロセスはすでに終了しているのにタイマーがまだ動き続けるあのちぐはぐな体験です。しかし、Plugin、Trajectory、課金の三つをうまく使いこなせるようになると、「すべては Plugin」という五文字がなぜ繰り返し語られる価値があるのか、理解し始めるはずです。