最近、技術コミュニティで DeepSeek がオープンソース化したあのコマンドラインツールを目にしたなら、おそらくその二つの対照的な印象に打たれるだろう。一つは 8 月 13 日のオープンソース化後、わずか一日で5 万以上の star に達した熱気であり、もう一つは README がわずか 1700 字程度で、スクリーンショットも機能一覧もなく、「これが一体何なのか」すら明確に書かれておらず、全文ただ一言——Everything is a Plugin——を投げ出すだけだということだ。このプロジェクトは deepseek-harness と呼ばれ、コマンドラインでの略称は dsh である。これは普通のチャットクライアントではなく、モデル、ツール、プラグイン、Agent プリセットのすべてを同一のランタイム上に載せるプログラマブルなスキャフォールドである。まさに「すべてがプラグイン」であるがゆえに、そのインストールと設定の道筋は一般的なツールよりもいくつか分岐が多い。ちょっと試したいだけの人もいれば、毎日使いたい人もおり、本流のコードを追いたい人もいれば、国産モデルの Coding Plan に接続したい人もいる。この記事では「まずインストールでき、次に快適に使え、最後に完全に設定する」という順序に従い、macOS 上の完全なフローをコピー＆ペースト可能な手順に分解する。本段落ではまずインストールと環境確認を解決し、次に初めて Web UI に入るときの三つのことを説明し、最後に四つのモデルモードのトレードオフを徹底的に解説することで、実際に対話を始める前に、頭の中にすでに明確な地図があるようにする。

dsh --version が 0.1.1-rc.2 を返す：まずあなたの環境に本当にインストールされているかを確認しよう

多くの初心者がツールをインストールした後にやってしまう最初の悪い癖は、いきなりコア機能を動かしてみて、動かないと分かってから人生を疑い始めることだ。dsh のようなローカルサービスを起動し、さらに実行時に Plugin をマウントする必要があるコマンドラインツールでは、最初にやるべきことは常に「インストールされているか、どのバージョンが入っているか」の確認だ。公式の検証方法は非常に素朴で、バージョン照会コマンドを一つ実行するだけだ。現在のバージョン番号は 0.1.1-rc.2 を返す。この番号には rc というサフィックスが付いている点に注意してほしい。これは release candidate、つまり候補リリース版を意味し、プロジェクトがまだ急速なイテレーション期にあり、インターフェースやデフォルトの挙動が変わりうることを示している。あなたのマシンで実行した結果がこの番号でなくても、慌てる必要はない。インストール時にすでに公式がより新しい rc をリリースしていたか、あるいはより古いスナップショットをインストールしたかのどちらかだ。バージョン文字列が正常に出力されれば、実行ファイルが PATH に入っており、コマンド解析の経路が通っている証拠だ。

dsh --version
# 0.1.1-rc.2

このコマンドは単純に見えるが、実に多くの問題を排除してくれる。dsh がインストールできない典型的な症状は、ターミナルが直接 command not found を返すことだ。これは通常、次の三つの状況のいずれかを意味する。グローバルインストールが成功していない、npm のグローバル bin ディレクトリが PATH に入っていない、あるいは nvm などのバージョンマネージャで Node のバージョンを切り替えたためにグローバルパッケージが別のディレクトリに置かれている、のいずれかだ。command not found に遭遇したら、まず npm root -g と npm bin -g（新しい npm では npm prefix -g）でグローバルディレクトリがどこにあるかを確認し、そのディレクトリが echo $PATH の出力に含まれているかを見よう。これはすべての Node コマンドラインツールに共通する問題であり、dsh 固有の落とし穴ではない。事前に知っておけば 30 分のトラブルシューティングを節約できる。

作業を始める前に、dsh の位置づけをはっきりさせておく価値がある。それが後続のすべての設定ロジックを決定するからだ。このプロジェクトは 8 月 13 日に DeepSeek によってオープンソース化され、1 日で star 数が 5 万を超えたが、README は極めて控えめで、1700 字ほど、スクリーンショットは一枚もなく、機能の列挙もなく、最も核心的な表現はあの Everything is a Plugin という一言だ。この言葉はマーケティングのスローガンではなく、そのアーキテクチャの事実である。モデルプロバイダは Plugin、ツールは Plugin、あなたがカスタマイズした Agent プリセットさえも Plugin だ。公式はソースコード内で「創造モード」について非常に率直に説明している。それを Shell を持つセッションとして扱え、なぜなら cordis_mount が生きたランタイム上でモデルが書いた JavaScript を実行するからだ。この点を理解すれば、後で「モデルプロバイダを自由に追加できる」「モードを切り替えられる」「サードパーティがサイドバー Plugin をインストールできる」といった話を見ても散漫には感じないだろう。それらはすべて同じ Plugin メカニズムの異なる側面にすぎない。

したがって本節の結論は明確だ。インストールしたらまず dsh --version を実行し、バージョン番号を確認してから先に進もう。このステップのコストは 10 秒未満だが、「機能が動かない」という霧の中からあなたを直接引き出してくれる。環境が利用可能であることを確認したら、次はインストールルートを選ぶ。公式は三つの道を用意している。npx による一時実行、npm によるグローバルインストール、ソースからのビルドだ。三つの道は三種類のユーザーに対応しており、以下で順に展開していく。

npx @deepseek-ai/dsh web：ディスクに残さない一時的な試用ルート

公式ドキュメントでは npx 方式を「一時実行」と位置づけており、公式が推奨する最初の方式です。最大の特徴はディスクに残さないこと——事前にグローバルインストールする必要はなく、npx が自ら npm レジストリからパッケージを取得して実行します。このツールがどんなものか眺めてみたいだけで、長期的に使うつもりのない人にとっては、最もコストの低いルートです。

# 方式一：临时运行（官方推荐）
npx @deepseek-ai/dsh web

このコマンドを実行すると、インストール過程が一度停止して確認を求められます。ターミナルで「続行しますか」といった質問が表示されるので、y を入力して Enter を押すだけです。この手順は npm エコシステムの標準的な動作で、リモートパッケージを一時的にダウンロードして実行しようとしているため、npm は明示的な許可を必要とします。確認後、パッケージが取得されてそのまま起動し、ターミナルがログを出力し始め、最終的にローカルサービスが起動し、リッスンアドレスは http://127.0.0.1:3080 になります。このアドレスをブラウザにコピーして開けば、Web UI に入って体験を始められます。

ここで展開する価値のあるエンジニアリング上の詳細が三つあります。第一に、localhost ではなく 127.0.0.1 という記述は、サービスが本機のループバックアドレスにのみバインドされることを意味し、LAN 内の他のデバイスからはデフォルトでアクセスできません。これは個人の開発環境にとって安全なデフォルト値です。もし本当にスマートフォンや他のマシンからアクセスする必要があるなら、自分でバインド設定を確認すべきであり、アドレスをいきなり 0.0.0.0 に書き換えて済ませるのは避けてください。それはあなたの API Key を同一ネットワークセグメントの全員に晒すことになります。第二に、3080 というポートはハードコードされたデフォルト値です。本機で既に別のサービスが 3080 を占有している場合、起動は失敗するか挙動がおかしくなります。その際は占有しているプロセスを先に停止するか、コマンドで別のポートを指定してください（具体的なパラメータは dsh web --help のリアルタイム出力を基準にしてください。rc バージョンではパラメータが変わる可能性があるためです）。第三に、npx のキャッシュ挙動：npx はダウンロードしたパッケージを npm のキャッシュディレクトリに置くため、二回目の実行は通常少し速くなりますが、毎回バージョンを確認しに行く可能性があります。つまり、ある日挙動が一致しないと気づいたら、キャッシュ内で新しいバージョンに変わった可能性が高いです。その際は npx @deepseek-ai/dsh --version で実際に取得されたバージョンを比較すれば、「昨日は問題なかったのに」という類の問題のほとんどを説明できます。

npx を使うことにはもう一つ暗黙のコストがあります：毎回解析と取得のプロセスを経る必要があるため、起動速度はグローバルインストールほど安定せず、ネットワークが制限された環境では詰まったり失敗しやすくなります。したがって公式の位置づけは非常に的確です——「試用に適した人向け」。頻繁に使うと決めたら、グローバルインストールに切り替えるべきです。

npm install -g @deepseek-ai/dsh でグローバルインストールした後の dsh web の日常的な使い方

dsh を日常的なツールとして使うつもりなら、グローバルインストールが唯一合理的な選択です。npx との本質的な違いは、パッケージが実際にグローバルの node_modules にインストールされ、グローバルの bin ディレクトリに安定した dsh 実行エントリが生成されることです。以降の起動では、毎回取得するオーバーヘッドがなくなり、npm の一時キャッシュにも依存せず、起動パスが固定され、動作が予測可能になります。

# 方式二：全局安装后可直接用 dsh web
npm install -g @deepseek-ai/dsh
dsh web # 拉起 Web UI，默认 3080 端口

インストール後は、以降毎回の使用で dsh web を実行するだけで Web UI を起動でき、デフォルトはやはり 3080 ポートです。このコマンドの利点は、「インストール」と「実行」を完全に分離できることです。インストールは一度きり、実行は高頻度であり、日常的には dsh web の1つだけ覚えておけばよいのです。前述の dsh --version による検証は、グローバルインストールの場面では特に意味があります。なぜならグローバルパッケージは Node のバージョン切り替え、権限問題、ミラーソース問題の影響を受けるため、バージョン番号が最も迅速なヘルスチェックになるからです。

グローバルインストールにはよくある2つの落とし穴があり、ここで先に明確にしておきます。1つ目は権限問題です。システム標準の Node を使ってインストールした場合、グローバルディレクトリが /usr/local のような sudo が必要な場所にあることがあり、そのまま npm install -g すると EACCES が発生します。正しい対処法は、無闇に sudo を付けることではなく（それはファイルの所有者を混乱させ、以降のアップグレードで様々な奇妙なエラーを引き起こします）、nvm や fnm で Node を管理し、グローバルディレクトリをユーザーディレクトリ配下に置くことです。2つ目はミラーソース問題です。国内ネットワークでインストールが止まる場合は、一時的に国内ミラーに切り替えてインストールし、完了後に公式ソースへ戻せばよいですが、ミラーは同期が遅れる可能性があり、特に rc バージョンは1〜2のマイナーバージョン遅れることが多い点に注意が必要です。これもインストール後に必ず dsh --version で確認すべき理由です。2つのルートのトレードオフを一目で把握できるよう、以下の表で主要な観点を揃えました。

比較観点npx 一時実行npm グローバルインストール
典型的なコマンドnpx @deepseek-ai/dsh webnpm install -g @deepseek-ai/dsh、その後 dsh web
ディスクへの保存グローバルには保存されず、npm キャッシュを利用グローバルの node_modules に保存され、dsh エントリを生成
インストール時の対話確認を求められ、y を入力そのままインストール、追加確認なし
起動速度やや遅い、キャッシュとネットワークに依存高速かつ安定、パス固定
対象ユーザー試したいだけ、一時的に見たい人頻繁に使用、日常ツールとして使う人
デフォルト待ち受けhttp://127.0.0.1:3080http://127.0.0.1:3080
バージョン確認npx @deepseek-ai/dsh --versiondsh --version

一言で結論を言えば、試すなら npx、長期的に使うならグローバルインストールです。どちらも最終的には同じ Web UI に到達し、ポートとインタラクションは完全に一致し、違いは起動方法と安定性だけです。そして、もしあなたが「常に主干を追いかけ、新しい Plugin 機構をいち早く試したい」というタイプなら、さらに第三の道——ソースコードビルドがあります。

ソースからのビルド：clone、pnpm install、pnpm run build、pnpm dsh web の4ステップ

公式が提示している第3の方法は、ソースコードからのワンクリックインストールです。このルートが用意されているのは、dsh の Plugin 機構そのものがオープンだからです。自分で Plugin を書きたい、ランタイムの挙動を変更したい、まだリリースされていない新機能を検証したい、といった場合はソースコードを取得して自分でビルドする必要があります。その手順は標準的なフロントエンド monorepo の流れで、全部で4ステップ、どのステップも欠かせません。

git clone https://github.com/deepseek-ai/deepseek-harness.git
cd deepseek-harness
pnpm install
pnpm run build
pnpm dsh web

この4ステップを分解して見ていきます。第1ステップの git clone、リポジトリのアドレスは https://github.com/deepseek-ai/deepseek-harness.git です。このアドレスはそのままブックマークしておくことをおすすめします。今後 Plugin 機構を調べたり、モードのソースコードを見たり、issue を投稿したりする際に必ずここへ戻ってくることになるからです。第2ステップの cd でリポジトリのディレクトリへ移動、このステップに技術的な中身はありませんが極めて重要です。以降の pnpm コマンドはすべてリポジトリのルートディレクトリで実行しなければなりません。第3ステップの pnpm install、ここは npm ではなく pnpm である点に注意してください。このプロジェクトはパッケージマネージャーとして pnpm を使っています。本機に pnpm が入っていない場合は、まず corepack か npm でグローバルにインストールする必要があります。pnpm プロジェクトを npm install でインストールすると、依存関係の巻き上げ方式の違いから「インストールはできたのにビルドでエラーが出る」という難解な症状が発生しやすく、これはソースビルドで最もよくある落とし穴の一つです。第4ステップの pnpm run build、このステップで TypeScript のソースコードを実行可能な成果物へコンパイルします。フロー全体の中で最も時間がかかる工程であり、ビルド途中のエラーは通常 Node のバージョンが低すぎるか、システムレベルの依存関係が欠けていることが原因です。エラーは最後の行ではなく最初の行を見てください。最初の行こそが根本原因であることが多いです。第5ステップの pnpm dsh web、ここは直接 dsh を叩くのではなく、pnpm を経由してリポジトリローカルの dsh エントリへ転送している点に注意してください。こうすることで、いまビルドしたばかりのこのコードが起動され、グローバルインストールされたバージョンではないものが動きます。

ソースビルドのルートは3種類の人に向いています。dsh に Plugin を書きたい開発者、ランタイムのマウント挙動をデバッグしたい研究者、そして特定の commit を固定して内部デプロイを行いたいチームです。その代償はメンテナンスコストの高さです——上流の更新を pull するたびに install と build をやり直す必要があり、依存関係もそれに伴って変化する可能性があります。したがって、あなたの目的が単に「使うこと」であれば、グローバルインストールで十分です。「それを改変する」あるいは「それがどう動くかを見る」必要があるときに初めて、ソースのルートが価値を持ちます。3つのインストールルートの適用シーンは、簡単に一言で覚えられます：試すなら npx、日常はグローバル、改造はソース。インストールが済んだら、本当の本番はここから始まります——初めての Web UI へのアクセスです。

初めて Web UI に入る：API Key、UI 言語、ワークスペースの 3 つの順序

ターミナルでローカルサービスの起動ログがすでに確認できていると仮定し、ブラウザで http://127.0.0.1:3080 を入力してページを開きます。初めて入ると、UI が 3 つのことを完了するよう案内します。順序は非常に重要です：まず API Key を入力し、次に UI 言語を切り替え、最後にワークスペースを追加します。順序を間違えても作業自体は進められますが、英語の UI の中で余計に回り道をすることになります。

最初のステップは案内に従って deepseek API key を入力することです。Key を持っていない人は、まず公式サイトで生成する必要があります。アドレスは platform.deepseek.com/api_keys です。ここで重要な認識は、harness 自体はモデル能力を提供せず、単なるオーケストレーション層であるということです。すべての推論は、あなたが設定したプロバイダーと Key を通じて転送されます。したがって、Key の有効性が、その後の対話が可能かどうかを直接左右します。Key を入力する際は注意してください。入力欄は通常一度しか表示されないか、マスク処理が行われます。貼り付けるときは、先頭や末尾の空白が入っていないことを確認してください。「Key は明らかに正しいのに認証失敗になる」という類の問題は、9 割がコピー時に余分な空白文字が入ったか、文字が欠けたことによるものです。

2 番目のステップはUI 言語の切り替え（任意）です。英語の UI が見づらい場合は、左下の 「Settings」 ページをクリックし、言語を中国語に切り替えるだけです。この手順は任意ですが、入門者には先にやっておくことを強くおすすめします。なぜなら、後でワークスペースの追加、モデルの選択、プロバイダーの設定を設定ページで行ったり来たりすることになり、母語で操作すると理解コストを大幅に下げられるからです。言語の切り替えは UI の文言にのみ影響し、実行時の動作には一切影響しません。いつでも元に戻せます。

3 番目のステップはワークスペースの追加です。いわゆるワークスペースとは、本質的には「プロジェクトを 1 つ追加する」ことであり、ローカルのプロジェクトディレクトリを選択する必要があります。このステップに対応するエンジニアリング上の意味は、dsh がこのディレクトリの範囲内でファイルの読み書き、ターミナルコマンド、プラグインのマウントを実行するということです。したがって、ディレクトリの選択が、モデルがどのファイルに触れられるかを決定します。入門段階では、専用のテストディレクトリや独立した git リポジトリを選ぶことをおすすめします。いきなりユーザーのホームディレクトリ全体や、機密設定を含むディレクトリを放り込まないでください。実行時には Shell 能力とファイル変更能力があるため、範囲を広くするほど、誤操作の影響範囲が大きくなります。ディレクトリを選んだ後は、さらにモデルを選択する必要があります。ここまでで、設定の最小閉ループがようやく完成し、対話 UI に入って接続性をテストできるようになります。

この 3 つのステップをつなげると、実は 1 本の最小可用パスになります：Key を入力 → 中国語に切り替え → ワークスペースを追加してモデルを選択。最初の 2 つは設定ページで一度に完了できますが、3 番目は新しいプロジェクトを開くたびにやり直す可能性があるため、後でモデル設定の完全なやり方について改めて説明します。今はまず、モデル選択の分岐点をはっきりさせておきます。

flash か pro か：ワークスペースでモデルを選ぶときのトレードオフ

ワークスペースを追加すると、インターフェースでモデルを選択するよう求められます。素材で明確に示されている2つのグレードは flash と pro です。公式の選択に関する推奨は非常に控えめで、「あなたのタスク次第」という一言だけで、この2つのグレードの具体的なパラメータはドキュメントに記載されていません。この点は正直に説明する必要があります：本記事では、示されていないパラメータを一切捏造しません。例えばコンテキスト長、トークンあたりの価格、毎分のレート制限といった数値は、素材にないので作りません。あなたが頼りにできる判断根拠は、グレードの一般的な意味合いです：flash は軽量さと高速さに寄り、pro はより強力な能力とより高いコストに寄っています。

この意味合いに基づくと、入門者への実用的なアドバイスは次のとおりです：もしあなたが行っているのが小さなバグの修正、独立した関数の記述、コードの一部の説明、簡単な質疑応答の1回の実行であれば、flash で十分です。応答が速く、試行錯誤のコストが低く、まずフローを通すのに適しています。もしあなたが直面しているのが複数ファイルにまたがるリポジトリレベルの変更、より大きなコードベースの構造を理解する必要があるタスク、あるいは結果の品質により高い要求がある場面であれば、pro に切り替えましょう。このトレードオフの論理は、ほとんどの2グレードモデルと一致しています：まずタスクの複雑さを判断し、それからグレードを決めるのであって、デフォルトで常に最強のものを使うのではありません。なぜなら harness はツールを連続して呼び出し、多ラウンドの往復を行う実行者であり、1回の会話で何度もモデル呼び出しが発生する可能性があるため、グレードを高く選ぶとタスク全体の消費が増幅されます。

注意が必要なのは、モデル選択は一度きりではないということです。それはワークスペースレベルで調整でき、また後からモデル設定ページでさらに多くのプロバイダーを接続した後、公式プリセットの deepseek 以外に、GLM、通義千問、小米、火山方舟などのモデルを選べます。つまり、flash と pro は「公式プリセット」で最初に出会う分かれ道であり、モデル設定体系全体はこの2つの選択肢よりもはるかに豊富です。この完全な設定体系は、本チュートリアルの第2部の目玉です。ここでは伏線を張っておきます：公式プリセットモデルは Key が有効であれば、追加後にモデルリストが自動的に取得され、大量のパラメータを手入力する必要はありません。

標準 / PTC / ミニマル / クリエイト：4つのモデルモードはそれぞれ誰に適しているか

モデルを選んだ後、さらに深い選択があります：モデル設定内のモードです。素材が示す公式の推奨は「初心者はデフォルトの標準モードで十分」であり、同時に4つのモードの位置づけを列挙しています。これら4つのモードはモデルのグレードではなく、モデルがどのツールを呼び出せるか、どのようにツールを呼び出すかのランタイム設定です。これらを理解すれば、dsh がなぜ「Everything is a Plugin」と言えるのかがわかります——「モデルがどうツールを使うか」という事柄自体が設定可能なプラグインの組み合わせなのです。

1️⃣ 標準モード：位置づけは「通常のコーディング、リポジトリの変更」。これはバランスの取れたデフォルトであり、ツールセットは完全で、動作は大多数の直感に合致し、日常の主力として適しています。初心者は迷わずこれを選び、まずツール呼び出しのリズムに対する感覚を養いましょう。

2️⃣ PTC モード：PTC は Programmatic Tool Calling の略称で、4つのモードの中で最も仕組みが特殊であり、最も詳しく解説する価値があります。その核心的な変化は：モデルが一往復ごとにツールを呼び出すのではなく、TypeScript を書き、Code Mode SDK を通じて複数ステップを一度に組み合わせ、システムが run_code で実行することです。これをエンジニアリングの言葉に翻訳すると——従来のツール呼び出しは「モデルが A を呼べと言い、システムが A を実行し、結果をモデルに返し、モデルがさらに B を呼べと言う」というもので、各ツール呼び出しが完全なモデルの往復でした。一方 PTC はこの一連の往復をコードの一区間に圧縮し、モデルが頭の中で手順を組み立てて TypeScript として書き、ランタイムに一度に実行させます。素材には非常に具体的な定量的記述があります：5回の往復を1回にまとめられる。これは、複数のツールを連続して操作する必要がある複雑なタスクにおいて、PTC が往復のオーバーヘッドを大幅に削減し、「1ステップで多くのツールを連鎖させる」ことを現実にすることを意味します。

ただし PTC の暗黙の前提に注意してください：モデルが TypeScript を書き run_code に渡して実行する以上、この能力は本質的に標準モードより強力であり、より信頼境界を必要とします。これは、タスクの手順がすでに明確で、モデルに効率的にバッチ実行してほしいシナリオに適しています。例えば「3つの設定ファイルを読み取り、差分を比較し、ルールに従って2つのファイルを変更し、さらに検証を一度実行する」といった典型的なパイプライン的操作です。固定的な反復フローであるほど、PTC の利益は顕著になります。

3️⃣ ミニマルモード：素材の説明はわずか一言——「ターミナル + ファイル変更だけ」。残すのは2つだけです：永続 bash、そして絶対パスでファイルを変更する str_replace_editor。これは意図的に引き算を行ったモードで、ツール面を最小集合に絞り込み、軽量なタスクや、モデルにコマンドを打てて指定ファイルを変更できる最小環境だけを与えたい場合に適しています。その詳細については、次の節で個別に展開します。

4️⃣ クリエイトモード：位置づけは「自分の Agent プリセットを作る」。標準モードの全能力を持ち、さらに Harness 自体を変更する能力を備えています：ランタイムの検査、プラグインの試用、新しい Agent preset の作成。カスタムプリセットは ~/.dsh/.agent-presets/ ディレクトリに保存されます。素材がそのソースコードコメントを引用した内容は非常に率直です：これを Shell のあるセッションとして扱え、なぜなら cordis_mount は生きたランタイム上でモデルが書いた JavaScript を実行するからだ。この言葉は修辞ではなく、セキュリティ上の注意です——クリエイトモードはモデルが実行中のランタイムを変更でき、自分が書いたプラグインをマウントできることを意味し、その能力は自分が何をしているかを明確に理解していることを要求するほど強力です。これはプラグイン作者と Agent プリセット開発者のために用意されたものであり、日常のコーディングにおけるデフォルト選択肢ではありません。

これら4つのモードの違いを一度に明確に見るために、以下に表でそれらの主要な特徴を揃えます。

モード公式の位置づけツール能力の範囲適している人
標準モード通常のコーディング、リポジトリの変更完全な通常ツールセット初心者のデフォルト、日常の主力
PTC モードProgrammatic Tool Callingモデルが TypeScript を書き、Code Mode SDK を通じて複数ステップを組み合わせ、run_code で実行；5回の往復を1回にまとめられるツールをバッチで連続呼び出しする必要があるパイプラインタスク
ミニマルモードターミナル + ファイル変更だけ永続 bash と絶対パスでファイルを変更する str_replace_editor のみ軽量タスク、最小環境
クリエイトモード自分の Agent プリセットを作る標準モードの全能力に加え、ランタイムの検査、プラグインの試用、新しい Agent preset の作成；プリセットは ~/.dsh/.agent-presets/ に保存プラグイン作者、Agent プリセット開発者

この表を見れば、4つのモードの選択ロジックは明確になる：不確かなら標準、フローが固定で速度を上げたいなら PTC、コマンドを打ってファイルを変更するだけなら極簡、ランタイムやプラグインを動かすなら創造。モード間は能力が段階的に進む単純な序列ではなく、異なるタスク形態に向けた調整であることに注意してほしい——極簡は引き算、PTC はパラダイムの転換、創造は権限の追加だ。これも「Everything is a Plugin」がモデル層で体現されているものである：同じランタイムでも、異なるツールプラグインの集合を入れ替えることで、まったく異なる作業方式が得られる。素材に登場したサードパーティ製プラグイン DSH-better-sidebar は、この理念が UI 層に延伸したものである——右サイドバーと下部パネルによるデュアルワークベンチを拡張しており、後の設定部分でインストール方法を説明する。

ミニマルモードは永続 bash と str_replace_editor の二つだけを残す

ミニマルモードを単独で取り上げるのは、その設計哲学が他の三つのモードとはまったく異なるからだ。標準モードは「何でもできる」ことを追求し、PTC は「より速くやる」ことを追求し、創造モードは「最も強力な能力」を追求する。そしてミニマルモードが追求するのは最小限の実用的なツール面である。資料におけるその記述は非常に正確だ。二つだけ残す、永続 bash と絶対パスでファイルを変更する str_replace_editor である。

まず永続 bash を見てみよう。キーワードは「永続」——つまりこれは持続的に存在するターミナルセッションであり、コマンドごとに新しいシェルを開くのではない。永続セッションの利点は状態が継続することだ。あるディレクトリに cd した後も、後続のコマンドはそのディレクトリにいる。export した環境変数は、後続のコマンドでも読み取れる。バックグラウンドで起動したプロセスは、そのまま動き続けている。同じ環境で連続して操作する必要があるタスクにとって、これは毎回クリーンなシェルから始めるよりもはるかに自然だ。また、モデルが人間のようにターミナルで「前のステップの続きから作業する」ことができることも意味する。

次に str_replace_editor を見てみよう。その重要な修飾語は絶対パスでファイルを変更するである。これは二つの重要な情報を明かしている。第一に、その中核操作は置換式の精密編集であり、ファイル全体の書き換えではない。これはコード変更にとってより安全な方法であり、変更範囲が制御可能で diff も明確だ。第二に、絶対パスの使用を要求しており、相対パスではない。この点は初心者がつまずきやすい——習慣的に相対パスを渡すと、ファイルが見つからない、あるいは誤った場所を変更する問題に遭遇する可能性がある。特に永続 bash の作業ディレクトリとエディタのパス解決基準が一致しない場合、絶対パスはこうした曖昧さを解消できる。絶対パスを使うのがこのツールセットで最も手間のかからない使い方であり、楽をしようと相対パスを書いてはいけない。

なぜミニマルモードが必要なのか。それは「モデルができること」を最低限まで圧縮し、その直接的な利益は振る舞いがより予測可能になり、コンテキスト占有がより少なくなり、誤操作の範囲がより小さくなることだ。あるディレクトリでモデルにいくつかコマンドを打たせ、ついでに一つのファイルを変更させたいだけなら、完全なツールセットを使うことはむしろ妨害になる。ミニマルモードは本質的に、こうした軽量なシナリオのために用意されたメスであり、スイスアーミーナイフではない。その存在は四つのモードの関係を再び裏付けている——それらは同じものの異なる強度ではなく、異なるタスクに合わせて切り出された異なるツールの組み合わせである。

ここまでで、あなたは「インストールできたかどうか」から「Web UI に入る」、さらに「モデルを選び、モードを選ぶ」までの完全な入門チェーンを完了した。最小の閉ループはこうだ。dsh --version を実行してバージョンが 0.1.1-rc.2 であることを確認し、npx または npm install -g でインストールし、ブラウザで http://127.0.0.1:3080 を開き、deepseek API Key を入力し、左下の Settings で中国語に切り替え、ワークスペースディレクトリを追加し、flash と pro の間でタスクに応じて取捨選択し、最後に標準、PTC、ミニマル、創造の四つのモードから一つを選んで始める。このチェーンが通れば、あなたの環境、Key、ディレクトリ権限、ランタイムマウントに問題がないことがわかり、次の段階の正式な設定に進める。そして上記の手順を操作する過程で、モデルプロバイダーの欄が deepseek だけではないことにすでに気づいているかもしれない——GLM CodePlan、アリババ qwen-token-plan-cn、シャオミ xiaomi といったプリセットプロバイダー、そして火山方舟のようにカスタムプロトコルが必要なプロバイダーが、接続されるのを待っている。それらをどう設定するか、Key はどこから来るのか、プロトコルをどう選ぶか、モデルリストをどう取得するか——まさに本チュートリアル第 2 部で解決するモデル設定の全フローである。

前の段落では、dsh を npm グローバルインストールから Web UI で動作させるまで一気に進め、ワークスペースの追加と四つのモードの選択を完了した。この段落では続けて進む。まず「創造モード」とそれがディスクに書き出すカスタムプリセットディレクトリを徹底的に解説し、次に対話インターフェースに戻って一度接続性を検証し、それから三家の公式プリセットプロバイダー、二家の実測モデル、火山方舟のカスタム接続を一つずつ打通し、最後にデスクトップクライアントとサードパーティプラグインを補い、締めくくりに実行可能な運用チェックリストを提供する。

創造モードと ~/.dsh/.agent-presets/：カスタム Agent プリセットはどこに保存されるのか

まず4つのモードの関係を整理しておこう。そうしないと、後でモデルを設定するときに、自分が誰のために設定しているのか分からなくなる。標準モードはデフォルトの枠であり、能力の境界は「普通にコードを書き、リポジトリを変更する」ことだ。ファイルを読み書きし、コマンドを実行し、結果を見て、また修正する。これは通常の Agent クローズドループである。その上の第一層が PTC モードで、正式名称は Programmatic Tool Calling。標準モードとの違いはツールの数ではなく、呼び出しの形態にある。標準モードではモデルが一往復ごとにツールをクリックし、1回の往復でほんの少ししか進まない。PTC モードではモデルは逐次ツールをクリックせず、直接 TypeScript を書き、Code Mode SDK を通じて複数ステップを組み合わせ、システムが run_code で実行する。素材の表現は非常に直感的だ。5回の往復を1回にまとめられる。「まずファイルを検索し、次に3か所を修正し、さらにテストを実行し、エラーに応じて修正し直す」といったチェーン状のタスクでは、PTC の効果は非常に顕著である。

第二層は極簡モードで、これは足し算ではなく引き算を行う。残すのは2つだけ——1つの永続 bash、そして絶対パスでファイルを変更する str_replace_editor だ。ツール面は最小限に削られ、モデルが使える「手」は減るが、その分だけ制御性は高くなり、制御されたディレクトリ内で小さな修正だけを行わせたい場面に適している。

第三層が本節の主役、創造モードである。これは「極簡モードの対極」ではなく、標準モードの全能力の上に、さらに Harness 自身を改変する能力を重ねたものだ。この文は分解して読む必要がある。標準モードでできることはすべてできる。それに加えて、ランタイムを検査し、プラグインを試し、新しい Agent preset を書くこともできる。つまり、モデルはこのツールの利用者であるだけでなく、同時にこのツールの改造権も手に入れている。

カスタムプリセットの保存先は固定されている。~/.dsh/.agent-presets/ だ。創造モードで dsh に生成させた Agent プリセットは、最終的にすべてこのディレクトリに書き込まれる。これを理解することは重要である。なぜなら、プリセットはファイル形態のバージョン管理可能な資産であり、どこかの UI 状態に閉じ込められたブラックボックス設定ではないからだ。git で管理でき、バックアップでき、マシンを乗り換えるときにそのままコピーでき、問題が起きたときはあるディレクトリを削除してクリーンな状態に戻せる。

ここでリスク点を先に説明しておかなければならない。cordis_mount は生きたランタイム上でモデルが書いた JavaScript を実行する。素材の原文表現は「それを Shell 付きのセッションとして扱え」であり、この文をそのまま安全原則として使うことを勧める。この文には2つの意味がある。第一に、創造モードが与える能力は Shell 付きのセッションと等価であり、モデルが到達できる範囲は「コードを少し直す」をはるかに超えている。第二に、cordis_mount が実行するのは生きたランタイム上の JavaScriptであり、サンドボックス内の静的設定ではない——実際に現在のプロセス内で動く。したがって、創造モードに Key を設定する前に、次の3点をはっきり考えておくべきだ。

  • ディレクトリ境界：ワークスペースがどのプロジェクトディレクトリを指すかで、創造モードの活動半径はほぼその周辺になる。気軽にホームディレクトリやディスク全体のルートディレクトリを指してはいけない。
  • 資格情報の境界：創造モードが見える API Key や環境変数は、それを使う権限があるのと同じである。本番環境の資格情報を試遊環境と混ぜてはいけない。
  • ロールバックコスト：プリセットは ~/.dsh/.agent-presets/ に保存される。利点は削除すれば復元できることだが、生きたランタイムで実行した動作（たとえば変更したファイル、実行したコマンド）は、プリセットを削除してもロールバックできるとは限らない。まずクリーンなプロジェクトで試す習慣を身につけよう。

4つのモードを表にして比較すれば、選定時に見比べるだけで十分だ。

モード中核メカニズムツール面適した場面リスクレベル
標準モード通常の Agent クローズドループ。逐次ツールを呼び出し、一往復ずつ進む完全（ファイル読み書き + コマンド + リポジトリ操作）初心者のデフォルト枠。日常的なコーディング、リポジトリ変更中
PTC モードProgrammatic Tool Calling：モデルが TypeScript を書き、Code Mode SDK 経由で複数ステップを組み合わせ、run_code が実行完全だが、コードで組み合わせてバッチ呼び出しチェーン状の長いタスク。複数回の往復を1回にまとめたい中高
極簡モード永続 bash と、絶対パスでファイルを変更する str_replace_editor のみを保持最小（2つ）制御されたディレクトリ内での小さな精密修正低
創造モード標準モードの全能力 + Harness 自身の改変：ランタイム検査、プラグイン試用、Agent preset 作成「改造権」を追加。プリセットは ~/.dsh/.agent-presets/ に保存自分用の Agent プリセット作成、ツールチェーンの拡張高（cordis_mount が生きたランタイムでモデルの書いた JavaScript を実行）

よくある実践的な進め方は次のとおりです。まず極簡モードでクリーンな小規模プロジェクトを使い基礎的な経路に問題がないことを確認し、標準モードに切り替えて実際のタスクを1つか2つ通して信頼を築き、その後タスクの形態に応じて PTC モードを導入して往復を省くかどうかを判断します。これらがすべて順調に動作し、全体像を把握できた段階で、最後に創造モードを開いて自分の preset を書きます。順序を逆にすると、ツールの境界を把握しないまま改造権を手放すことになり、問題が発生した際にどの环节が原因かを特定するのが難しくなります。

インストール後まず1つのプロンプトを実行：対話テストで接続性を検証

ワークスペースを追加し、モデルを選択した後、実際のプロジェクトタスクをいきなり投入しないでください。正しい方法は対話インターフェースに戻り、まず最もシンプルなプロンプトを1つ送信し、接続性検証を行うことです。このステップの価値は問題領域を切り分けられる点にあります。シンプルなプロンプトでエラーが出るなら、それは Key、プロトコル、ネットワーク、またはプロバイダー設定の問題であり、あなたのプロジェクトコードとは無関係です。このステップが通れば、その後エラーが発生しても、調査範囲は自動的にワークスペースや具体的なタスクに絞り込まれます。

接続性検証は以下の順序で行うことを推奨します。各ステップはごくわずかなコストしか消費しません：

  1. まずサービスが動作していることを確認：ブラウザで http://127.0.0.1:3080 にアクセスしてインターフェースが開けば、ローカルサービスは正常です。ついでにターミナルでバージョン確認を1回実行し、CLI が正しくインストールされていることを確認します。
  2. プレーンテキストのプロンプトを送信：例えば簡単な挨拶をさせたり、現在選択されているモデルを説明させたりします。ファイルの読み書きは伴いません。このステップで検証するのは API Key からモデルまでの経路です。
  3. ツール呼び出しを1回伴うプロンプトを送信：例えば現在のワークスペースのルートディレクトリのファイルを一覧表示させます。このステップで検証するのはワークスペースのマウントとツール実行の経路です。
  4. 戻り値を観察：正常に内容が返れば、KKey が有効で、プロトコルが一致し、プロバイダー設定が正しいことを示します。ローディングで止まったり、直接認証エラーが出たりする場合は、プロバイダー設定ページに戻って Key とプロトコルタイプを確認してください。

2番目のコマンドはそのまま使えます：

# 确认 CLI 已正确安装，并查看当前版本
dsh --version
# 0.1.1-rc.2

# 确认本地 Web 服务可访问（返回 200 即服务正常）
curl -s -o /dev/null -w "%{http_code}\n" http://127.0.0.1:3080

バージョン番号 0.1.1-rc.2 は rc（release candidate）のプレリリース版であることに注意してください。この情報は運用上有意義です。プレリリース版の機能はバージョンによって急速に変化する可能性があるため、動作の不一致に遭遇した際は、慌てて設定を変更するのではなく、まず双方のバージョン番号が一致しているかを確認することが重要です。

公式プリセットプロバイダー：zai-coding-cn、qwen-token-plan-cn、xiaomi の追加方法

接続が完了したら、いよいよモデルの設定に移ります。dsh のモデル設定の入口パスは統一されており、まずこの流れを覚えておきましょう。後述する3つのプリセットと1つのカスタムはすべて同じ幹線を通り、途中で選ぶ「プロバイダー」が異なるだけです：

「設定」→「モデル」→「プロバイダーを追加」→「プロバイダー」で対応する識別子を選択 → API-KEY を入力 → 保存

3社の公式プリセットプロバイダーの識別子はそれぞれ以下の通りです：

  • GLM CodePlan：プロバイダーで zai-coding-cn を選択し、API-KEY を入力して保存するだけです。
  • Alibaba Qwen 個人 tokenplan：プロバイダーで qwen-token-plan-cn を選択し、API-KEY を入力して保存するだけです。
  • Xiaomi 個人 API-Key：プロバイダーで xiaomi を選択し、API-KEY を入力して保存するだけです。

この3社に共通する重要な挙動があります：この種の公式プリセット済みモデルリストは手動で設定する必要がありません。API Key が有効で、追加設定が成功していれば、モデルリストは自動的に取得されます。この点は、後述する Volcengine Ark のカスタム接続とは対照的です——プリセットプロバイダーでは Key を1つ渡すだけで、残りは dsh に任せられます。カスタムプロバイダーでは、プロトコルを自分で入力し、アドレスを自分で入力し、モデルを手動で選び出す必要があります。

なぜプリセットは自動取得でき、カスタムは手動なのか？本質的な違いはメタ情報が既知かどうかにあります。プリセットプロバイダーのプロトコルタイプ、接続アドレス、モデル一覧は、dsh 側にすでに内蔵されています。あなたが提供する API Key は最後のピースにすぎず、それを嵌めればリストを取得しに行けます。カスタムのシナリオでは、プロトコルとアドレスを自分で入力する必要があり、モデル一覧も実際に一度リストリクエストを発行しないと分からないため、「利用可能なモデルを取得」という一手間を加えて設定が正しいか確認する必要があります。

ここで運用面での小さなアドバイスを1つ：3社のプロバイダーを一度に全部設定しないでください。まず1社を設定し、テストを通し、利用可能を確認してから、次の1社を設定します。理由は簡単です——もし同時に3社を設定してエラーが出たら、あなたは多変数問題に直面することになり、Key の問題なのか、プロバイダーサービスの問題なのか、それともローカルネットワークの問題なのかを判断するのが難しくなります。変数を1つずつ導入することが、トラブルシューティングコストを最も低くする方法です。

GLM-5.2 と Qwen3.8-Max-Preview 実測：プリセットモデルはホームに戻って直接選択

プリセットプロバイダーを設定した後は、使用パスが非常に短くなります：ホームに戻り、モデルリストから該当するモデルを選択してそのまま使用する。モデルレベルでの手動設定は一切不要です。

素材で示された実測結論は2つあり、選定の参考としてそのまま使えます：

  • GLM の Coding Plan における GLM-5.2 モデルは、テスト正常。
  • アリババ千問の Coding Plan における Qwen3.8-Max-Preview モデルは、テスト正常。アリババ Coding Plan の API Key 取得先は platform.qianwenai.com/home/api-keys です。
  • さらに、Xiaomi の API Key も正常に使用できます。

この3つをまとめて見ると、初心者にとって非常に有用な結論が得られます：公式プリセットの接続パスは検証済みで安定したメインパスである。プロトコルの詳細を調べる必要も、アドレスを手書きする必要も、モデルを一つずつ選ぶ必要もなく、有効な API Key を取得して入力し、ホームに戻ってモデルを選べば動きます。「とにかく早く使いたい」というニーズにとって、このパスが最適解です。

逆に言えば、いつカスタムを使う必要があるのか？答えは：接続したいプロバイダーが公式プリセットリストにない場合です。例えば火山方舟のように接続アドレスを自分で指定する必要があるシーンでは、次のセクションのフローに従う必要があります。したがって判断基準は明確です——まずプリセットリストで探し、見つからなければカスタムする。プリセットが既にサポートしているのに無理にカスタムを通すのは避けてください。それは自ら進んでエラーになりうる2つのフィールドを増やすことと同じです。

また、見落とされがちな点を一つ注意喚起します：Coding Plan タイプの Key と従量課金の API Key は意味的に異なります。素材ではこの2種類を分けて記述しています——従量課金の API Key で deepseek、xiaomi をモデルプロバイダーとして設定；Coding Plan の API Key で標準テンプレートとしてアリババ千問、智谱を設定；さらに Coding Plan の API Key でカスタム方式として火山引擎を設定。この分類自体が一つの運用上の手がかりです：まず手持ちの Key がどちらの種類に属するかを確認し、それから対応するパスで設定することで、「なぜ Key を入力したのにモデルが取得できないのか」という多くの困惑を省けます。

Volcano Ark カスタム接続：openai-completions / openai-responses プロトコルと利用可能モデルの取得

ここからはカスタムパスを使います。例としてVolcano Ark の Coding Plan を取り上げます。これは公式プリセットリストに含まれていないため、プロトコルとアドレスを自分で入力する必要があります。Volcano Ark の設定説明ドキュメントのアドレスは console.volcengine.com/ark/region: です。フロー全体のキーとなるフィールドは4つあり、順に説明します：

  1. プロトコル選択：OpenAI 互換インターフェースプロトコルに対応したツール、つまり openai-completions または openai-responses を選択します。どちらを選ぶかは、使用予定のモデルがどちらのインターフェース形式に対応しているかによります。
  2. API アドレス：ark.cn-beijing.volces.com/api/coding/… という coding 接続アドレスを入力します。
  3. API Key：ご自身の Volcano Ark Key を入力します。
  4. モデル選択：「利用可能モデルを取得」をクリックし、取得されたリストからチェックを入れます。

「利用可能モデルを取得」のステップは、カスタムフロー全体の検証アンカーです：モデルリストを取得できれば、設定は正しいということになります。この一文の重みは非常に大きく、「プロトコルが正しいか、アドレスが正しいか、Key に権限があるか」という3つの問題に一度に答えてくれます。クリックしてもモデルが1つも取得できない場合、モデル自体を疑う必要はなく、問題は必ずこの3つのフィールドのいずれかにあります。したがって、正しいトラブルシューティングの順序は、まずプロトコルが OpenAI 互換であることを確認し、次にアドレスの綴りを照合し、最後に Key の権限範囲を確認する、という流れになります。

次に、このフローで最もハマりやすい落とし穴です：Volcano のこのモデルリストは100以上あります。素材にある愚痴は非常にリアルです——「よく使ういくつかを選べばいい、そうしないとリストが大きすぎて見られない」、そして明確に「公式は反選択機能を追加すべきだ、こういうモデルリストが多い場合は一つずつクリックするのが面倒すぎる」と指摘しています。この言葉はチュートリアル内でエンジニアリング経験として個別に取り上げる価値があります：

  • 大きなリストを取得した後に全選択しないこと。100以上のモデルをすべて追加すると、以降のモデル選択リストが長くなりすぎて使えなくなります。
  • どれが必要かを先に考えてから選択すること。一般的な方法は、今回のタスクで使うモデルをまず決め、それだけにチェックを入れ、本当に2つ目のニーズが出てきたときに戻って追加するというものです。
  • 反選択機能に期待する：素材では現在反選択機能が欠けていることが明確に言及されています。同じ課題を感じているなら、これはプロジェクトにフィードバックできる改善点です。反選択機能が登場するまでは、初回選択の数を制御することが最も現実的な戦略です。

選択が終わったら、不要なモデルを削除し、その後「プロバイダーを作成」をクリックします。この「先に精簡してから作成」という順序は逆にできません——作成後にクリーンアップするのは、無駄な作業をもう一度やるのと同じです。作成完了後、Volcano のモデルを1つ選んでテストし、正常であれば OK です。

プリセットパスとカスタムパスを並べて比較すると、両者の違いは一目瞭然です：

比較項目公式プリセットプロバイダーカスタムプロバイダー（例：Volcano Ark）
代表識別子 / 名称zai-coding-cn、qwen-token-plan-cn、xiaomiVolcano Ark Coding Plan
手動入力が必要なフィールドAPI-KEY のみプロトコルタイプ + API アドレス + API Key
プロトコル内蔵済み、選択不要OpenAI 互換インターフェースプロトコルを選択：openai-completions または openai-responses
アドレス内蔵済みark.cn-beijing.volces.com/api/coding/…
モデルリストの取得API Key が有効で設定追加後に自動取得手動で「利用可能モデルを取得」をクリックして設定を検証
モデル数のリスク対応不要100以上、厳選が必要、現在反選択機能なし
締めのアクション保存後にホームへ戻り直接モデルを選択不要なモデルを削除 → プロバイダーを作成 → モデルを1つ選んでテスト

もう一つ、フロー上の細かい点として定着させておく価値があるのは、「素材には『火山のモデルを一つ選んでテストしてみて、正常ならOK』と書かれている」ということです。この「テストしてみる」が、カスタム接続全体における最後の関門です。多くの人は設定が終わるとすぐに本番作業を始めてしまい、最初の実タスクが失敗すると、接続設定が悪いのかタスク自体が難しいのか区別できなくなります。設定完了後は、まず軽量なリクエストで検証する。この規律は、プリセットパスでもカスタムパスでも成り立ちます。

ブラウザのタブを開きたくない？DSH Desktop がローカル dsh web を自動起動

ここまでのすべての操作は、「ブラウザにタブを一つ開いている」という前提の上に成り立っています。タブをずっと開いておきたくない場合、あるいは本機に Node 環境がない場合、コミュニティにはすでに既製の代替案があります。DeepSeek Harness をベースに構築されたオープンソースのデスクトップクライアント DSH Desktop で、現在すでに約2万個の star を獲得しており、公式サイトのアドレスは www.dshdesktop.cn です。

これが解決する問題は非常に具体的です。dsh をブラウザから切り離し、ネイティブウィンドウで直接実行できるようにする。機能面では、日常利用に最も役立つ3つのポイントがあります：

  • マルチウィンドウ：複数のウィンドウを同時に開いて、異なるワークスペースや異なるタスクを実行でき、ブラウザのタブをあちこち切り替える必要がありません。
  • システムトレイ常駐：ウィンドウを閉じてもサービスが停止するわけではなく、トレイからいつでも呼び戻せます。
  • ローカルサービスの自動起動：起動時に dsh web ローカルサービスを自動で立ち上げます。つまり、先ほどの CLI コマンドを手動で実行する必要はまったくありません。

インストール方法は初心者に極めて優しいです。公式サイトではパッケージ済みのインストーラーを提供しており、Mac と Windows の両方でワンクリックインストールに対応、すぐに使えて、インストール後そのまま開けば使えます。ここで利用パスの切り替えに注意してください。DSH Desktop を使う場合、ターミナルで手動で dsh web する必要はなく、クライアントがローカルサービスを立ち上げてくれるので、あなたは直接インターフェースに向き合うだけです。

では、いつブラウザを選び、いつデスクトップクライアントを選ぶべきでしょうか。次のように判断できます：

  • 一時的に試してみたい、まずこれがどんなものか見てみたい：ブラウザ方式で十分です。npx の一時実行ならグローバルインストールは不要です。
  • 本機に Node 環境があり、コマンドラインに慣れており、ソースコードに最も近い制御感を求める：npm install -g @deepseek-ai/dsh でグローバルインストールし、その後 dsh web を実行します。
  • Node 環境がない、あるいはブラウザのタブをずっと開いておきたくない、マルチウィンドウとトレイ常駐を求める：DSH Desktop を直接使い、ワンクリックインストーラーで解決します。

3つの実行方式を並べて見るとより明確になります。npx の一時実行は一度だけ試すのに適しており、グローバルインストール + dsh web は頻繁に使用する開発者に適しており、DSH Desktop はブラウザから切り離してすぐに使いたいユーザーに適しています。3つのパスは最終的に同じローカルサービスを指しており、入口が異なるだけです。

2026年9月に改めてDSH-better-sidebarを見る：プラグイン式で拡張するサイドバーとボトムパネル

DSH Desktopが解決するのは「どこで使うか」という問題であり、サードパーティ製プラグインが解決するのは「インターフェース上に何があるか」という問題です。ここで取り上げるプラグインはDSH-better-sidebarで、その役割は右サイドバー＋ボトムパネルのデュアルワークベンチを拡張することです。GitHubプロジェクトのアドレスはgithub.com/omdsh-dev/D…です。インストール方法は非常にシンプルで、コマンド一行です：

# 安装 DSH-better-sidebar 插件
curl -fsSL https://raw.githubusercontent.com/omdsh-dev/DSH-better-sidebar/main/scripts/install.sh | bash

インストール完了後、必ず行うべき操作が二つあり、どちらか一方でも欠けると効果が確認できません：

  1. DSHを再起動する。プラグインは実行時にロードされるため、再起動しないと有効になりません。
  2. ブラウザをハードリフレッシュする：Cmd/Ctrl+Shift+R。通常のリフレッシュではキャッシュにヒットし、インターフェースが古いままになる可能性があるため、必ずハードリフレッシュしてください。

この二つの手順を終えると、サイドバーが表示されます。「再起動＋ハードリフレッシュ」という組み合わせは小さなテクニックのように見えますが、実はこれはプラグイン式アーキテクチャの一般的な法則です：サーバー側はプラグインを再ロードし、クライアント側はキャッシュを破棄してリソースを再取得する必要があり、両方がリフレッシュされて初めて完全に有効になります。今後どのようなdshプラグインをインストールする場合でも、この一連の操作を踏襲できます。

このプラグインを2026年9月に改めて取り上げる価値がある理由は、プロジェクト全体の最も核心的な宣言——Everything is a Plugin——を裏付けているからです。全文を振り返ると、この原則が一貫していることがわかります：

  • 能力レイヤー：四つのモードは本質的に異なる能力の組み合わせであり、ミニマルモードは二つだけを残し、クリエイトモードはHarness自体を改変する能力を重ねます。
  • モデルレイヤー：公式プリセットプロバイダー（zai-coding-cn、qwen-token-plan-cn、xiaomi）は標準テンプレートを使用し、Volcano Arkはカスタムプロトコルを使用するという二つのパスが併存しており、モデル設定も同様に非常に柔軟です。
  • インターフェースレイヤー：DSH-better-sidebarはcurl一行でサイドバーとボトムパネルに新しいワークベンチを追加します。

2026年9月という時点で見ると、プラグインエコシステムの意義は次の点にあります：コアリポジトリは非常に薄いままに保ち、能力はプラグインから生えてくる。先に触れたように、当初のREADMEはわずか1700字程度で、スクリーンショットも機能リストもなく、Everything is a Pluginという一言だけを投げ出していました——当時は何も語っていないように見えましたが、今振り返ると、それは実はプロジェクト全体の拡張モデルを語っていたのです。ただし、運用の観点からは冷静さも必要です：プラグインの能力が強力になるほど、インストールスクリプトの出所の信頼性がより重要になります。上記のようなcurl | bashのインストール方式では、実行前に少なくとも出所が公式またはコミュニティで認められたプロジェクトアドレスであることを確認し、出所不明のスクリプトを気軽にコピーしないようにしましょう。

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

この記事全体を、そのまま実行できるチェックリストに圧縮します。順番に実行し、問題が発生したら項目ごとに遡って確認してください。

  1. インストール方法を選ぶ：お試しなら npx @deepseek-ai/dsh web（途中で確認を求められるので y を入力）。常用するならグローバルインストール npm install -g @deepseek-ai/dsh、以降は直接 dsh web、デフォルトポートは 3080。ソースからのワンクリックインストール（clone → cd → pnpm install → pnpm run build → pnpm dsh web）も可能です。
  2. インストール成功を確認する：dsh --version を実行し、0.1.1-rc.2 のような出力が表示されれば正常です。rc 标识はプレリリース版を意味するため、トラブルシューティング時はまずバージョン番号を確認してください。
  3. 画面を開き、3つの初期設定を完了する：ブラウザで http://127.0.0.1:3080 にアクセス。ガイドに従って deepseek API key を入力（公式サイト platform.deepseek.com/api_keys で生成）。任意で左下の「Settings」から UI 言語を中国語に切り替えられます。
  4. ワークスペースを追加しモデルを選ぶ：プロジェクトディレクトリをワークスペースとして追加し、タスクに応じて flash か pro を選択します。
  5. モデルモードを必要に応じてアップグレードする：初心者はまず標準モード。複数回の往復を1回のコード実行にまとめたい場合は PTC モード。制御されたディレクトリ内で小さなステップの精密な修正を行いたい場合は極簡モード。独自の Agent preset を書きたい場合のみ創造モードを有効にします。
  6. 創造モードの安全規律：カスタム preset は ~/.dsh/.agent-presets/ に配置されます。cordis_mount は稼働中のランタイム上でモデルが書いた JavaScript を実行することを肝に銘じ、Shell を持つセッションとして扱い、ワークスペースをホームディレクトリやディスクルートに向けないでください。
  7. 設定前に接続性を検証する：対話画面に戻り簡単なプロンプトを送信し、疎通を確認してから実際のタスクに進み、設定問題とタスク問題を完全に切り分けます。
  8. 公式 preset を優先する：統一パスは「設定 → モデル → 提供元を追加 → 提供元を選択 → API-KEY を入力して保存」。3社の标识はそれぞれ zai-coding-cn（GLM CodePlan）、qwen-token-plan-cn（阿里千問個人 tokenplan）、xiaomi（小米個人 API-Key）。API Key が有効であれば設定追加後にモデルリストが自動的に取得されます。
  9. preset 設定後はホームページから直接選択：GLM-5.2（GLM Coding Plan）と Qwen3.8-Max-Preview（阿里千問 Coding Plan）はいずれも実測で正常、小米 API Key も同様に正常に使用できます。
  10. preset が見つからなければカスタムで対応：火山方舟を例にすると、プロトコルは OpenAI インターフェースプロトコル互換の openai-completions または openai-responses を選択し、API アドレスには ark.cn-beijing.volces.com/api/coding/… を入力、Key を入力後に「利用可能なモデルを取得」をクリック——リストが取得できれば設定は正しいです。
  11. 大量のモデルリストを処理する：火山には100以上のモデルがあるため、よく使ういくつかだけを選び、リストが大きすぎて表示できなくなるのを避けます。現在は反選択機能がないため、初回選択数を制御するのが最も現実的な戦略です。まず不要なモデルを削除してから「提供元を作成」をクリックし、最後に1つのモデルを選んでテストし、正常なら完了です。
  12. ブラウザタブを開きたくない場合はデスクトップクライアントを使う：DSH Desktop（約2万 star、www.dshdesktop.cn）は Mac/Windows のワンクリックインストールに対応し、マルチウィンドウ + システムトレイ常駐、起動時に dsh web ローカルサービスを自動起動し、CLI コマンドを手動で実行する必要はありません。
  13. 必要に応じてプラグインをインストールし確実にリフレッシュする：DSH-better-sidebar を1行の curl でインストール後、DSH を再起動し Cmd/Ctrl+Shift+R でハードリフレッシュすると、サイドバーと下部パネルのデュアルワークベンチが表示されます。
  14. 設定総量の参考：ここまでで、合計5つのモデルプロバイダーを設定できます——従量課金 API Key で deepseek、xiaomi を設定。Coding Plan API Key を標準テンプレートで阿里千問、智谱を設定。Coding Plan API Key をカスタムで火山引擎を設定。
  • 中核となるメンタルモデル：Everything is a Plugin。能力、モデル、インターフェースの三層はいずれも「プリセット + プラグイン」の方式で拡張される。この点を理解しておけば、後でどんな新しいベンダーや新しいプラグインに出会っても、対応する接続経路を素早く見つけられる。
  • トラブルシューティングの口诀：画面が開かない → サービスが 3080 で動いているか確認；プロンプトを一句入れただけでエラー → Key とプロトコルを確認；モデルが取得できない → プロトコル、アドレス、Key の権限を確認；プラグインを入れたのに反応がない → 再起動 + ハードリフレッシュ。
  • セキュリティの最低ライン：創造モードとプラグインのインストールというこの二つは、いずれも追加の慎重さが必要だ。前者は稼働中のランタイムでモデルコードを実行することに関わり、後者はサードパーティのインストールスクリプトを実行することに関わるため、ソースの信頼性は自分で必ず見極めなければならない。

ここまでで、インストール、初期設定、モデル接続から、デスクトップクライアントとプラグイン拡張まで、チェーン全体が完成した。冒頭の「README がわずか千七百字ほどで、機能一覧もない」プロジェクトを振り返ると、それは複雑さをドキュメントから拡張メカニズムへと移している。そしてこのチェックリストの役割は、その拡張経路を順番に一度たどってあげることにある。あとはこれを自分のワークスペースに接続して、作業を始めるだけだ。