CH 17 · プラグインインストール
この章の目標
CH 12 で実はすでに 3 つのプラグイン —— dsh-mcp-client、dshmarket、dsh-skill-mcp-panel —— をインストール済みですが、それは「途中でインストール、動けばよい」で、3 つのインストール方法を説明しませんでした。この章では系統的にプラグインのインストールを扱います:プラグインはどこから来るのか、どこにインストールされるのか、異なるインストール方法、管理方法、インストール後の検証方法 —— そして最後に実際に 1 つインストールし、dsh に直接インストールさせます。
まず 1 行覚えてください:プラグインのインストール = profile に npm 依存を追加すること。dsh は「すべてはプラグイン」(CH 08 で扱った)ですが、「インストール」自体は標準のパッケージ管理に従います。インストールを理解したら、CH 18 から最初のプラグインを書き始めます。
まず自分のインストール状況を見る
ターミナルを開き、まず dsh 本体のバージョンを確認:
dsh --version私の出力:
0.1.1-rc.2次に web profile がすでに持っているプラグインを確認:
dsh plugin --profile web list私の出力(CH 12 でインストールした結果):
Legend: production dependency, optional only, dev only
dsh-profile-web C:\Users\mortal\.dsh\profiles\web (PRIVATE)
│
│ dependencies:
├── @deepseek-ai/dsh-mcp-client@0.0.1-rc.1
├── dsh-skill-mcp-panel@2.0.1
└── dshmarket@1.40.0
3 packagesこの 3 行が正確に 3 つのインストール方法に対応していることに注意:mcp-client はコマンドライン経由でインストール、dshmarket もコマンドラインでインストールしたマーケット本体、dsh-skill-mcp-panel はマーケットでワンクリックインストール —— そしてこれらが直接設定ツリーに入って効く理由は 3 つ目の仕組み bundle 自動マウント です。1 つずつ下記で説明します。
プラグインはどこから来るか:4 つのソース
プラグインは本質的に npm パッケージで、ソースは次のとおり:
| ソース | 書き方 | 使いどき |
|---|---|---|
| npm パッケージ | @deepseek-ai/dsh-mcp-client | 最も一般的。公式パッケージは @deepseek-ai/ 接頭辞、コミュニティは独自スコープ |
| GitHub ソース | github:owner/repo | リポジトリの main ブランチをインストールしたい、npm 未公開 |
| ローカルディレクトリ | . または file:../plugin | 自作プラグイン、自分のチェックアウトを直接入れて編集・テスト |
| tarball / Release 成果物 | .tgz の URL またはローカルパス | 作者がビルド成果物のみ配布、GitHub Releases の添付など |
CH 12 でインストールした**dsh-market(プラグインマーケット)**は新しいソースではなく、グラフィカルエントリ:インストール後は設定で閲覧・検索・コミュニティプラグインの 1 クリックインストールができ、裏側では依然として上記のソースを呼んでいます。
どこにインストールするか:Profile レベル、profile に従う
dsh plugin はある profile のプラグインを管理するので、コマンドには --profile <名前> を付ける必要があり、どの環境にインストールするかを決定します。インストール先のパッケージはここに置かれます:
$DSH_HOME/profiles/<名前>/node_modulesWindows では C:\Users\<ユーザー名>\.dsh\profiles\web\node_modules で、pnpm で管理され、profile の package.json にも書き込まれます。
混同しやすい点 —— グローバルと Profile の違い:
- dsh 本体自体はグローバルインストール(CH 03 の
npm install -g @deepseek-ai/dsh)、全 profile で同じ dsh を共有。 - プラグインはデフォルトで profile ごと:
dsh plugin --profile web add xxxは web にのみ効く;headless にも使わせたいなら、headless にもインストールする必要あり。 - マシンレベル設定は別の層:
$DSH_HOME/cordis.patch.ymlは全 profile で共有(公式用語は「machine-local preferences」)、profile 自身のcordis.patch.ymlより優先度が高い —— 全環境に同じ変更を適用したければここに書く。
まずこれらのファイルの場所をはっきりさせ、混同しないでください。profile レベルのものは C:\Users\<ユーザー名>\.dsh\profiles\web\cordis.patch.yml(CH 12 で MCP サーバー設定を書いたあれ);マシンレベルのものは C:\Users\<ユーザー名>\.dsh\cordis.patch.yml —— 注意、このファイルはデフォルトでは存在せず、手動で設定を書いたときにだけ作成され、dsh は起動時に読み、なければスキップします。だから「自分が書いたのはマシンレベルか」を確認するには、.dsh ルート直下にあるか、profiles\<name>\ の下にあるかを見てください。
- 公式組み込みバンドル(
@deepseek-ai/dsh-base、@deepseek-ai/dsh-web-appなど)は dsh に同梱、グローバルインストールから来る;自分で追加したプラグインは profile 自身のnode_modulesに入る。
1 行で:dsh 本体はグローバル、プラグインは profile に従う、マシンレベル patch はサイト全体。
3 つのインストール方法
① コマンドライン dsh plugin:最も基本的
最も基礎的な方法。dsh plugin --profile <name> は引数をそのまま pnpm に渡す —— つまり add、remove、update、why、list などの pnpm 動詞がすべて使え、構文も npm パッケージ管理の構文:
dsh plugin --profile web add @deepseek-ai/dsh-mcp-client公式ドキュメントの典型例は 2 つのサブエージェントプラグインをインストールするもの(これらは任意のバンドル):
dsh plugin --profile web add @deepseek-ai/dsh-subagent-codex @deepseek-ai/dsh-subagent-claude-code
dsh plugin --profile web remove @deepseek-ai/dsh-subagent-codex自作プラグインをローカルディレクトリからインストールするのもこの方法 —— プラグインのソースディレクトリで dsh plugin --profile web add . を実行、インストールされるのは現在のチェックアウト(相対パスはコマンド実行時のディレクトリに固定され、profile ディレクトリではない)。
② プラグインマーケット dsh-market:最も手軽
グラフィカルインストール。まずマーケット本体をインストール:
dsh plugin --profile web add dshmarketインストール後、dsh を再起動(bundle 変更には再起動が必要、下記参照)、設定に新しい「プラグインマーケット」が現れ、カテゴリ別閲覧、検索、コミュニティプラグインの 1 クリックインストールができます。マーケット経由で入れたプラグインはほぼページ更新だけで有効、dsh の再起動は不要;ホストレベルの一部プラグインは「再起動が必要」と表示するので、その指示に従ってください。CH 12 の dsh-skill-mcp-panel はマーケットで検索して 1 クリックでインストールしたものです。
③ Bundle 自動マウント:インストールして設定ツリーへ
必ず疑問に思ったはずの現象に答えます:なぜ mcp-client はインストール後にサーバー設定のため cordis.patch.yml の手動 insert が必要で、dshmarket と dsh-skill-mcp-panel はインストール後設定なしで効くのか?答えはプラグイン自身の package.json にあります —— dsh.bundle を宣言しているかどうかの違い。「インストール時に自動で設定ツリーに入りたい」プラグインは、マニフェストでこのフィールドを宣言する必要があります:
{
"dsh": {
"bundle": {
"patch": "./cordis.patch.yml"
}
}
}dsh は毎回の dsh plugin 実行成功後に** bundle リストを調整**します:dependencies 内で dsh.bundle を宣言して解決されたパッケージは、自動的にその profile の bundle 層(CH 08 で扱った設定ツリー最下部の基盤層)に追加され、手動で insert する必要なし。
例として、宣言ありの 2 つのプラグインの package.json を見ましょう。dshmarket@1.40.0:
"dsh": {
"bundle": { "patch": "./cordis.patch.yml" },
"client": { "inject": ["@deepseek-ai/dsh-client-connection", "..."], "platform": "web" }
}dsh-skill-mcp-panel@2.0.1:
"dsh": {
"client": { "platform": "web", "inject": ["@deepseek-ai/dsh-client-runtime", "..."] },
"bundle": { "patch": "./cordis.patch.yml" }
}両方とも bundle.patch 宣言があるので、両方とも profile マニフェストの bundle リストに自動入ります。web profile の package.json を開くと、bundle 層はこうなっています:
"dsh": {
"profile": {
"bundles": [
"@deepseek-ai/dsh-base",
"@deepseek-ai/dsh-web-app",
"dsh-skill-mcp-panel",
"dshmarket"
]
}
}最初の 2 つは公式組み込みバンドル(グローバル dsh インストールに同梱)、最後の 2 つが自分でインストールして自動マウントされたものです。dsh-mcp-client はどう?これは dsh.bundle 宣言がないので、ただの通常依存 —— profile の package.json の dependencies には現れるが、bundles リストには入らない。比喩:bundle プラグインは「取扱説明書付きのすぐ使える道具」、通常依存は「ただの道具、説明なし」 —— 荷物は届いたが、dsh はその能力を自動でロードしない、自分で設定する必要がある。
dsh-mcp-client は後者:MCP サーバーに接続する「エンジン」、接続方法は知っているが、どれに接続するかは知らない。自分でどのサーバーに接続するか、住所、キーの渡し方を教えなければならない —— その動作が cordis.patch.yml への insert 記述(設定ツリーにサーバー設定行を挿入)。CH 12 で書いた Firecrawl の設定はまさしくそういう insert でした。
もう一点注意:これら 2 プラグインは dsh.client 宣言もしています(platform: web + クライアントプラグイン inject リスト)。だからこそ Web UI 設定に界面を追加できる(プラグインマーケット、MCP 管理)—— bundle でもあり(設定ツリーに入る)、クライアント注入も宣言している(界面に入る)。
必ず覚えるべき境界:bundle メンバー(bundles リストにあるもの)を変更したあとは、profile を再起動しないと効かない —— 実行中の profile は起動時の bundle セットを保持し、新規インストール bundle は次の起動でのみロード。注意、「再起動」は自動ロードさせるためだけで、何か設定させるためではない —— bundle プラグインがロードされればすぐ使えます、設定を触る必要なし。通常の cordis.patch.yml 編集はホットリロードで、再起動不要ですが、bundle の追加/削除/更新には再起動が必須。CH 12 で dshmarket インストール後に再起動したのは、自動ロードさせるためでした。
管理コマンド早見表
| コマンド | 効果 |
|---|---|
dsh plugin --profile web list | この profile がインストール済みのものを一覧(pnpm list 相当) |
dsh plugin --profile web add <source> | インストール、ソースは上記の 4 種 |
dsh plugin --profile web remove <パッケージ> | 削除 |
dsh plugin --profile web update <パッケージ> | 最新版へ更新(bundle 宣言ありは新と調整) |
dsh plugin --profile web why <パッケージ> | なぜこれがインストールされたかを見る(誰が依存しているか) |
インストール完了後の検証は 2 つ:
- 依存と bundle 所属を見る:
dsh plugin --profile web listで依存を表示;bundle 層にあるかは profile のpackage.json(上記のdsh.profile.bundles)を直接見る。 - 設定ツリーに実際にマウントされているか見る:
dsh --profile web --dump-configで完全な設定ツリーが出力され、プラグイン名を検索;bundle 基盤層のみ見たいならdsh --profile web --dump-default-config。
本当に使える 3 つのコミュニティプラグインをインストール
これまでインストールしたものは仕組み説明のためで、同時にプロセスで実際に必要だったものでもありました —— dsh はまさにそういうもの、欲しいものをインストール、すべてはプラグイン。今度は「即体験向上」のコミュニティプラグインを 3 つインストール、ちょうど GitHub ソースと npm ソースから。コマンドは自分で打たず、dsh に任せましょう。
dsh-theme:Web UI にスキンを
独立したテーマプラグイン;インストール後、設定に新しい「Appearance」が現れます:
- 3 つの外観モード:ライト / ダーク / システム追従
- 厳選テーマ 15 種(うち 5 種は読書向け、1 種は Carbon Code テーマ)
- 各テーマは色レベル、UI フォント、コードフォント、フォントサイズを統一設定にまとめ、ワンクリックで切替
- アクセントカラー、背景、前景、サーフェス、サイドバー色を個別にリアルタイム調整
- 設定はブラウザローカルに保存、リフレッシュでも失われない(ブラウザ・profile 跨ぎ同期はなし)
dsh にインストールさせるには、入力欄に:
dsh-theme プラグインを web profile にインストールし、動くことを確認してください;GitHub の oil-oil/dsh-theme リポジトリにあります。オープンソース:oil-oil/dsh-theme。インストール後に web profile を再起動、設定 → Appearance でテーマ切替可能、下の図のような見た目:
dsh-oil-sticky-prompt:スクロール中、最新ユーザーメッセージを上部に固定
長い返答をスクロールしているとき、最新のユーザーメッセージがコンパクトな全幅バーとして会話の上部にピン留めされ、クリックで元の位置にジャンプ:
- 単一の sticky バー、複数トピックで競合なし
- 元の改行は空白に折り畳まれ、最大 2 行
- メッセージを変更せず、セッションログに触れず、設定も保存しない
dsh にインストールさせるには、入力欄に:
dsh-oil-sticky-prompt プラグインを web profile にインストールし、動くことを確認してください;GitHub の oil-oil/dsh-oil-sticky-prompt リポジトリにあります。オープンソース:oil-oil/dsh-oil-sticky-prompt。インストール後に dsh を再起動。下の図は dsh が私のために実際にインストールしてくれた会話 —— Peer dependency 警告が想定動作であることの説明と、次回 web profile 再起動時に有効になる旨が記されています:
dsh-better-sidebar:サイドバーを完全作業台に
最も機能豊富なもので、右サイドバーを「作業台」にアップグレード。レイアウト哲学は Codex のような AI プログラミングツールのサイドバーと同じ —— ファイル、ターミナル、Git を Agent の隣に置き、働きながら見る:
- ファイル作業台:ディレクトリツリー + コードエディタ、画像 / Markdown / HTML / PDF / Office のインラインプレビュー
- 組み込みブラウザ:複数ウェブページタブ、コンテンツは sandbox iframe で実行
- 実ターミナル:xterm + node-pty で実シェル実行、切断時再接続、ターミナルツールをモデルに任意で注入可能
- Git パネル:実 diff、履歴、右クリックで stage / commit / revert
- バックグラウンド Job ページ:サブエージェントトポロジーとバックグラウンド Job(終了コード / ライブ出力 / 強制終了)
- 右サイドバー + 下部パネルのデュアル作業台、レイアウトはセッションごとに記憶
dsh にインストールさせるには、入力欄に:
dsh-better-sidebar プラグインを web profile にインストールし、動くことを確認してください;GitHub の omdsh-dev/DSH-better-sidebar リポジトリにあります(npm パッケージ名 dsh-better-sidebar)。オープンソース:omdsh-dev/DSH-better-sidebar。インストール後に dsh を再起動、ブラウザをハードリフレッシュするとサイドバーが見えます(bundle メンバーのため、再起動でのみロード)、右側のファイルブラウザ + 下部ターミナルが同時に出現:
この 3 つすべてが
bundle宣言を持ち、インストール時に自動マウントされます(③ の仕組み)。GitHub ソースの 2 つを初めてインストールするとき、pnpm の allowBuilds でブロックされたら、「よくある落とし穴」の項目に従って処理してください。
よくある落とし穴
| 問題 | 何が起きているか | 対処 |
|---|---|---|
| インストールしたのに UI 変化なし? | bundle メンバーをインストールしたなら、実行中 profile は自動リロードしない | dsh を再起動し、設定を再確認 |
GitHub ソースプラグインの初回 add で allowBuilds エラー? | pnpm ≥10 はデフォルトでソースパッケージの prepare ビルドスクリプト実行を阻止 | エラー内に表示されるヒントに従い、allow キーを profile ディレクトリ下の pnpm-workspace.yaml にコピーし、add を再実行 |
| dsh-better-sidebar インストール時に「Ignored build scripts」と表示? | pnpm 11 が node-pty などネイティブモジュールのビルドスクリプトを遮断 | profile ディレクトリ(C:\Users\<ユーザー名>\.dsh\profiles\web)で pnpm approve-builds --all を実行、その後ハードリフレッシュ |
| インストール後にサイドバーが 2 つ出る? | 以前手動マウントした行が自動バンドルと二重マウントされた | cordis.patch.yml の古い - insert: ... better-sidebar ... 手動マウント行を削除 |
| 間違った環境にインストールした? | --profile がインストール先を決める | コマンドの profile 名が望むもの(web / headless ...)か確認 |
| インストールしたのに効果なし、エラーもなし? | 通常依存(dsh.bundle 宣言なし)をインストールしたかもしれない | ただ「荷物が届いた」だけ、能力は自分で cordis.patch.yml に insert して接続する必要あり(mcp-client が典型) |
この章で学んだこと
下の項目を自力で達成できれば合格です:
- [ ] プラグインの 4 ソース(npm / GitHub / ローカルディレクトリ / tarball)を言え、プラグインマーケットはソースではなくグラフィカルエントリであることを言える
- [ ]
dsh plugin --profile <name>が profile のプラグインを管理し、そのnode_modulesにインストールされることを知っている - [ ] 区別できる:dsh 本体はグローバルインストール、プラグインは profile ごと、
$DSH_HOME/cordis.patch.ymlはマシンレベルでサイト全体に適用 - [ ] 3 つのインストール方法を知っている:コマンドライン add / マーケット 1 クリックインストール /
dsh.bundle宣言あり依存は自動マウント - [ ] 3 つのコミュニティプラグイン(dsh-theme スキン / dsh-oil-sticky-prompt 吸着プロンプトバー / dsh-better-sidebar サイドバー作業台)の目的を言え、自分でインストールできる
- [ ] bundle メンバー変更には profile 再起動が必要、通常の patch 編集はホットリロードであることを知っている
- [ ]
list/remove/updateでプラグインを管理でき、--dump-configで設定ツリーにマウントされたか検証できる