過去2年間、AI コーディングツールを選ぶ際に私たちが悩んでいたのが Claude Code、Codex、Cursor のどれに付くかだったとすれば、DeepSeek Harness（以下 dsh）がもたらした発想の変化は根本的です。基盤となる Runtime は固定したままでよく、能力は完全に自分で組み合わせられる。dsh の核心的な設計信条はただ一言——Everything is a Plugin（すべてはプラグイン）。モデルアダプター、ツールレジストリ、セッションログ、Agent Loop、サンドボックス、ストレージ、タスクスケジューリング、UI、さらには権限ポリシーまで、すべてが Cordis プラグインの形で存在します。ホストは能力を組織することだけを担い、能力そのものは一律にプラグインが提供します。本記事は「DeepSeek Harness 内蔵プラグイン全景」の前半部分であり、dsh の基本フローをすでに走らせ、プラグイン機構と選定ロジックを深く理解しようとしている上級読者に向けたものです。私たちは Cordis の登録とライフサイクルから始め、従来の直列型 Agent と dsh ランタイムの構造的差異を層ごとに分解し、「要件からプラグインへ」のマッピング表を示し、web、tui、headless の3つの Profile がそれぞれどの環境にプラグインをインストールするのかを明確にし、最後にインストールコマンドのフィールド分解と UI 強化四点セットの能力境界に着地します。この段落を読み終えれば、あなたは独立して判断できるはずです。自分のこのワークフローには、どのプラグインを、どの Profile にインストールすべきか、そしてそれが本当にロードされたかをどう検証するか。
Everything is a Plugin：dsh が権限ポリシーまで Cordis プラグインにしたことの意味
dsh のプラグイン化がどこまで徹底しているかを理解するには、まずそれを支えるフレームワーク層——Cordisを理解する必要があります。Cordis は軽量なプラグイン型アプリケーションフレームワークであり、その責務境界は非常に明確です。プラグインの登録、依存解決、ライフサイクル管理を統一的に担う。この3つは素朴に見えますが、まさにこれらが dsh がどのようなエコシステムを育てられるかを決めています。
まず登録について。dsh において、プラグインは「本体プログラムに機能をぶら下げる」外付けの概念ではなく、一等市民です。モデルアダプター、ツールレジストリ、セッションログ、Agent Loop、サンドボックス、ストレージ、スケジューリング、UI、さらには権限ポリシーまで、すべてが Cordis プラグインの形で存在します。別のモデルアダプタープラグインに差し替えれば、dsh は新しいモデルバックエンドを得ます。別のサンドボックスプラグインに差し替えれば、dsh のコード実行分離ポリシーは丸ごと別のものに変わります。この「能力すなわちプラグイン」という登録モデルは、ホストコード内にハードコードされた能力分岐がほとんど存在しないことを意味します。
次に依存解決です。ここはプラグイン型システムが最も失敗しやすいところです。プラグイン一覧が十数個にまで膨らみ、しかも互いに順序要件がある場合（たとえば権限ポリシープラグインはツールレジストリより前に配置されなければならず、UI プラグインはセッションログプラグインの出力構造に依存する）、手作業で順序を並べるのはほぼ必然的に誤ります。Cordis は依存解決をフレームワーク層に集約し、プラグインが何に依存し何を提供するかを宣言すると、フレームワークがロード順序と組み立て関係を決定します。これが dsh のプラグイン構成が「積み重ね」可能である理由でもあります——プラグイン同士は互いに積み重なり、まったく異なる作業環境を形成できるのであり、互いに足を引っ張り合うのではありません。
最後にライフサイクル管理です。プラグインのロード、有効化、無効化、アンロードには、明確なフックと状態境界が必要です。この点は dsh にとって特に重要です。なぜなら dsh は同一のインストール内で複数の Profile を同時に扱えるため、ライフサイクル管理が不十分だと、ある Profile で無効化されたプラグインが別の Profile のランタイム状態を汚染する可能性が高いからです。
では、「権限ポリシーまでプラグインである」とは一体どういうことなのか。ここには三つの意味があると考えており、上級読者には真剣に受け止めていただきたい：
- 第一層：セキュリティ境界は置き換え可能であり、固定的ではない。従来の Agent フレームワークでは、権限モデルは通常フレームワークカーネルの一部である——どのツールがファイルシステムに触れられるか、Shell を実行できるか、ネットワークアクセスに承認が必要か、といったことは往々にしてコードを変更しなければ変えられない設定だ。dsh が権限ポリシーをプラグインにしたことで、チームの規範に合わせてポリシー実装を丸ごと差し替えることもできるし、CI 環境向けにより厳格またはより緩いポリシーに切り替えることもできる。セキュリティはもはや「フレームワークが提供するかどうか」の問題ではなく、「どのプラグインをインストールするか」の問題になった。
- 第二層：権限ポリシーは他の能力プラグインと組み合わせた制約を形成できる。たとえば、ブラウザ自動化プラグイン（ローカル Chrome のログイン状態と Cookie を保持する）と、純粋な UI スキンプラグインでは、システムへの侵入度がまったく桁違いだ。権限ポリシー自体がプラグインであれば、「どの高権限プラグインをインストールしたか」と「どのポリシーでそれを制約するか」を結びつけて見ることができる。事後監査に頼る必要はない。
- 第三層：エコシステムの競争の焦点は下へ移る。権限、サンドボックス、ストレージ、スケジューリング、Agent Loop のすべてがプラグイン化できるようになると、コミュニティが本当に競うのは、誰のチャットウィンドウがより美しいかではなく、誰がより堅牢な低レイヤの能力プラグインを提供できるかになる。これは開発者にとって、プラグインを書くとき、自分がどの層の位置を占めるのかをはっきり考える必要があるということを意味する。
別の角度からこの節をまとめると：dsh は多くの機能を備えた Agent ではなく、プラグインを通じて Agent の能力を絶えず組み立てることができるランタイムである。ホストが行うことはただ一つ——能力を組織することであり、能力そのものはすべてプラグインから来る。これを理解すれば、以降の Profile、インストールコマンド、カテゴリ選定に関するすべての議論は、本質的には「この組織関係をどう編成するか」を議論していることになる。
従来の直列型 Agent と dsh ランタイム：Prompt→モデル→Agent→ツール の構造的差異
dsh の特別さを見極める最良の方法は、それを従来の LLM Agent の構造と並べて対照することだ。
従来の LLM Agent の構造は通常かなり固定的である：Prompt、モデル、Agent、ツールが順に直列につながり、一方向の処理チェーンを形成する。リクエストが入ってくると、まず Prompt の組み立てを経て、次にモデルに渡されて推論され、モデルがどのツールを呼ぶかを決め、Agent がツールを実行して結果をフィードバックし、これを繰り返す。このチェーンは明快で理解しやすいが、隠れた代償がある：能力のほとんどがフレームワークカーネルに封じ込められているのだ。別のインターフェースに変えたい？カーネルを変更する。視覚能力を追加したい？カーネルを変更する。複数の Agent を協調させたい？やはりカーネルを変更する。カーネルはますます肥大化し、しかもチームごとに変更の仕方が異なるため、最終的には分岐を生む。
dsh の構造は別の組織の仕方だ。モデルアダプタ、ツールレジストリ、セッションログ、Agent Loop、サンドボックス、ストレージ、スケジューリング、UI、権限ポリシーのすべてを Cordis プラグインに分割し、ホストはこれらの能力を組織することだけを担う。その結果：私たちは dsh のコアソースコードを変更することなく、その振る舞いを変えられる。この言葉はマーケティングの決まり文句ではなく、直接検証可能なエンジニアリング上の事実である——あなたのあらゆるカスタマイズ操作は、コア層の diff の中ではなく、プラグイン層で行われる。
よりエンジニアリング的な視点で両者の違いを比較してみましょう：
| 比較軸 | 従来の直列型 Agent | DeepSeek Harness |
|---|---|---|
| 構造形態 | Prompt→モデル→Agent→ツールが順に直列接続され、経路は固定 | ホスト + プラグイン群で、能力は Cordis によって動的に組み立てられる |
| 能力の所在 | ほとんどがフレームワークのコアに内包されている | モデルアダプタ、ツールレジストリ、セッションログ、Agent Loop、サンドボックス、ストレージ、スケジューリング、UI、権限ポリシーがすべてプラグイン化されている |
| 変更方法 | コアのソースコードを修正し、フォークが生じる | コアのソースコードを変更せず、プラグインのインストール/無効化によって挙動を変える |
| 組み合わせ能力 | 能力同士がコアで結合しており、自由に積み重ねるのが難しい | プラグイン同士を積み重ねて、まったく異なる作業環境を形成できる |
| 環境分離 | 1つのコードにつき1つの挙動 | 同じ dsh でも Profile ごとに異なるプラグイン構成を読み込め、互いに干渉しない |
| 拡張単位 | 機能モジュール | Cordis プラグイン（権限ポリシーのようなシステムレベルの能力も含む） |
この表で最も考えさせられるのは最後の2行です。従来の方式の拡張単位は「機能モジュール」ですが、dsh の拡張単位は「プラグイン」です。この両者の違いは、プラグインがライフサイクルを持ち、依存関係を宣言でき、Profile によって分離できる実体であるという点にあります。つまり、同じ dsh のインストールでも、Web のシナリオではタスクボードと視覚能力を備えた完全なワークベンチになり、ターミナルのシナリオでは単なる全画面 TUI になり、CI ではヘッドレスのバックグラウンド実行器になり得ます。あなたが向き合っているのは決して「1つの Agent アプリケーション」ではなく、絶えず組み立て続けられる Agent インフラなのです。
ここに、上級読者が見落としがちなポイントがあります。Agent Loop までプラグイン化するということは、セッションループと実行戦略そのものが差し替え可能であるということを意味します。従来のフレームワークでは、Agent の「思考—行動—観察」ループはコアに深くハードコードされており、せいぜいパラメータを調整する程度でした。しかし dsh では、このループを誰が駆動するのか、どのような戦略でいつ停止するかを決めるのか、ループ中にどうサンドボックス検証を挿入するのかは、すべてプラグイン層の決定です。これは、後に dsh_workflow のような「フロー固定化」プラグインが Agent Teams と組み合わせられる理由も説明しています。それらは本質的に、Agent Loop の上にもう一層のオーケストレーション能力を重ねているのです。
この構造の違いを理解したうえで、「要件→プラグイン」のマッピング関係を見返すと、ずっとスムーズになります。あなたは実は「ツールに機能を追加している」のではなく、「ランタイムの部品を交換している」のです。
要件からプラグインへのマッピング表：UI の変更、視覚の追加、マルチ Agent、ブラウザ、コンテキストには何を入れるべきか
dsh を引き継いだばかりのチームにとって、最も実用的な取っ掛かりは、まずプラグインのディレクトリを見ることではなく、自分たちの要件をプラグインの言語に翻訳することです。以下の5組の対応関係が、ほとんどのシナリオをカバーしています：
| 要件 | 方法 | 対応するプラグインの例 |
|---|---|---|
| UI を一新する | UI プラグインをインストールする | dsh-web-ui、dsh-TUI |
| 視覚能力を追加する | 視覚プラグインをインストールする | modlens、dsh-vision-toolkit |
| マルチ Agent 協調 | Agent Teams プラグインをインストールする | dsh-agent-teams |
| ブラウザ自動化 | Browser プラグインをインストールする | dsh-browser、BrowserSkill |
| コンテキスト管理 | Context プラグインをインストールする | dsh-context |
このマッピング表の価値は、「何をインストールすべきか」という曖昧な問いを、「自分はどの次元で能力が欠けているのか」という答えられる問いへと分解してくれる点にあります。以下、各次元の判断基準を順に説明します。
- インターフェースを変える（UI Plugin）：ブラウザからアクセスするワークベンチ、タスクボード、リモートのモバイル機能が必要なら、Web 側の UI Plugin を選びます。SSH リモート開発に慣れ、日常的にターミナルに浸っているなら、ターミナル TUI Plugin を選びます。この層が決めるのは「あなたがどう dsh を使うか」であり、Agent のコア能力を変えるものではありません。
- 視覚を加える（Vision Plugin）：あなたの仕事が OCR、Web ページのスクリーンショット分析、ドキュメント理解、画像内容の抽出に関わるなら、もともとテキスト中心の Agent に画像能力を「外付け」する Vision Plugin が必要です。Vision Plugin ごとに能力の深さは異なる点に注意してください。詳しくは後で区別します。
- マルチ Agent（Agent Teams Plugin）：単一の Agent で複雑なタスクを処理すると、コンテキストがどんどん乱れ、責務がどんどん混ざってくると気づいたら、複数の Agent に分業・協調させることを考えるべきです。この種の Plugin が解決するのは「複数の Agent をどう一緒に働かせるか」です。
- ブラウザ（Browser Plugin）：Agent が本当に本番環境に入ると、コードを読み書きできるだけではしばしば不十分で、Web ページを開き、ページを読み取り、クリックして入力し、ログイン状態を保ったままタスクを実行する必要があります。この種の Plugin は通常、ブラウザ拡張などの追加コンポーネントを伴い、インストール方法は通常の Plugin とは異なります。
- コンテキスト（Context Plugin）：Agent を長く使うほど、本当の問題はモデルが賢くないことではなく、コンテキストがどんどん乱れることである場合が多いです。この種の Plugin は、コンテキストの構成の可視化と管理を中心に展開します。
重要なのは、Plugin 同士はさらに重ね合わせて、まったく異なる作業環境を形成できるという点です。UI Plugin + Vision Plugin + Context Plugin で、日常的な対話型開発に向けた完全なワークベンチが得られます。UI Plugin + Agent Teams Plugin + Workflow Plugin で、タスクオーケストレーション環境が得られます。これこそが「Plugin 化」が「機能スイッチ」に対する本質的な優位性です。スイッチはオンかオフしか選べませんが、Plugin は自由に組み合わせられます。
注意していただきたいのは、dsh の強みは「Plugin が多ければ多いほど強い」ことではなく、自分のワークフローに合わせて自由に組み合わせることだという点です。最初から十数個の Plugin をインストールしないでください。まずコアのワークフローを動かし、その後で徐々に能力を追加していきましょう。
Profile の三つの形態：web、tui、headless はそれぞれ Plugin をどの環境に入れるのか
dsh の Plugin インストールには、通常の npm パッケージや Python パッケージとの明らかな違いが一つあり、この違いは上級ユーザーが必ず直感として身につけるべき点です。Plugin をインストールした後、それがどの環境で動作するかは Profile によって決まります。
言い換えれば、npm install や pip install が解決するのは「パッケージがこのマシンにあるかどうか」であり、dsh の Profile が解決するのは「このパッケージがどのランタイムで有効になるか」です。同じ dsh でも、利用シーンに応じて異なる Plugin の組み合わせを読み込むことができ、異なる Profile 同士は互いに干渉しません。これが dsh で「一度のインストール、複数の形態」を実現する鍵となる仕組みです。
dsh でよく使われる三つの Profile は以下のとおりです。
| Profile | 形態 | 適用シーン |
|---|---|---|
| web | ブラウザからアクセスする Web ワークベンチ | 日常的なインタラクティブ開発、タスクボード、リモートアクセス |
| tui | ターミナル全画面インターフェース | SSH リモート開発、コマンドラインに慣れたユーザー |
| headless | UI なしのバックグラウンド実行 | 自動化スクリプト、CI 統合、定期タスク |
これら三つの形態の設計ロジックは非常に明確で、じっくり掘り下げて解説する価値があります：
- web は「人が画面を見ながら操作する」シーンを対象としています。そのプラグイン構成は通常最も重く、UI 一式、サイドバーワークベンチ、視覚能力、プラグインマーケットがすべてこの段階にインストールされます。Web ワークベンチは、タスクボードや Git グラフのように視覚的な面積を必要とする能力を担うのに本質的に適しているからです。
- tui は「SSH リモート開発を行い、コマンドラインに慣れた」ユーザーを対象としています。そのプラグイン構成は通常最も軽く、ターミナルユーザーは全画面ターミナルインターフェースのプラグインを一つだけ残せば十分かもしれません。これは能力の欠如ではなく、意図的な引き算です。ターミナルのシーンでは、複雑な視覚パネルはむしろノイズを増やすだけです。
- headless は「人間が立ち会わない」シーン——自動化スクリプト、CI 統合、定期タスク——を対象としています。この段階では通常 UI プラグインを一切インストールせず、実行と成果物に専念します。
ここで特に強調したいエンジニアリング上の直感があります：Profile 間の分離には実際的な価値があり、概念遊びではありません。CI パイプラインで headless Profile を実行することを想像してみてください。もしプラグイン構成がローカルの Web Profile と一つの状態を共有していたら、ローカルで何気なくインストールしたブラウザ自動化プラグインが、CI で予期しないネットワーク動作を引き起こす可能性があります。異なる Profile が互いに干渉しないからこそ、本番パイプラインの実行環境を汚染する心配なく、ローカルの Web 環境で大胆にプラグインを試しにインストールできるのです。
もう一つのよくある誤解は、Profile を「テーマ」や「スキン」と捉えることです。そうではありません——Profile が決めるのはどのプラグインが実行に参加するかであり、実行時のアセンブリマニフェストです。一方、スキンはそのマニフェストの中のある種のプラグインにすぎません。この違いは、後で dsh-deep-whale のようなスキンプラグインを扱う際に再び現れます。
Web Profile と TUI Profile のプラグイン構成リスト：dsh-web-ui、dsh-better-sidebar、modlens、dsh-market、そして dsh-TUI
概念の説明は終わったので、実際に使える二つの Profile プラグイン構成を直接見てみましょう。より直感的に理解できるはずです。
典型的な Web Profile のプラグイン構成はこのようになります：
Web Profile
├── dsh-web-ui # Web ワークベンチ
├── dsh-better-sidebar # サイドバーワークスペース
├── modlens # 視覚能力
└── dsh-market # プラグインマーケット
一方、ターミナルユーザーは次のものだけを残すかもしれません：
TUI Profile
└── dsh-TUI # 全画面ターミナルインターフェース
この2つのツリーを並べて見ると、非常に興味深いことが分かります。同じdshでも、まったく異なるプラグインセットを読み込むことができるのです。Web Profileには4つのプラグインがあり、TUI Profileには1つしかありませんが、それらは同じdshインストール、同じプラグイン管理機構を共有しています。これこそがProfile機構の「能力を組織する」ことの直感的な現れです。
Web Profileの4点セットがそれぞれ何を担当しているのか、1つずつ分解してみましょう。
- dsh-web-ui：Web側の中核となるワークベンチプラグインです。単にインターフェースを差し替えるだけでなく、Agentワークフローを中心にタスクボードやGitグラフなどのワークベンチ機能を補完します。言い換えれば、「dshがブラウザ内でどうあるべきか」を解決するものです。
- dsh-better-sidebar：「ワークスペースの組織能力」という問題を解決します。完全なサイドバーワークベンチ——ファイルツリー／エディタ、ターミナル、Git、サブエージェント——を提供し、サードパーティプラグインが新しいTabを登録することもサポートします。dshを「AI IDE」にしたいユーザーに適しています。
- modlens：視覚能力プラグインで、純粋なテキストモデルに画像を扱う能力を与えます（その動作原理は次の段落で詳しく展開します）。
- dsh-market：プラグインマーケットを設定ページに内蔵し、検索、分類、ワンクリックでのインストール・更新を提供します。これはスタート段階で最も優先してインストールすることが推奨されるプラグインです——理由は簡単で、何十ものGitHubリポジトリを手動で探すよりも、まずマーケットに発見とインストールを手伝ってもらう方がよいからです。
一方、TUI Profileのdsh-TUIは別の路線です。Claude Codeスタイルの全画面ターミナルTUIで、ストリーミング思考、ダブルEscによる遡及、ステータスバー、モデル切り替えを提供します。ターミナル内でストリーミング出力とメッセージ遡及を提供し、体験はClaude Codeに近いものです。ターミナルユーザーにはdsh-TUIの方がより推奨されます。それは「弱い」からではなく、ターミナルシーンにおける対話習慣に正確にマッチしているからです——ストリーミング思考とメッセージ遡及という2点は、長いセッションのデバッグ時に特に価値が高いのです。
ここで実戦的なアドバイスを1つ：スタート時はまずdsh-marketをインストールし、その後マーケットを通じて必要に応じて残りのプラグインをインストールし、その後の更新管理もまとめて任せることをお勧めします。まずコアワークフローを動かし、その後で他の能力を徐々に追加していきましょう。この道筋が有効なのは、マーケットプラグイン自体が「プラグインはどこで探すのか」という二次的な問題を解決しているからです——プラグインの発見自体もプラグイン化設計の一部なのです。
dsh plugin --profile addコマンドの分解：Profileの選択から読み込み検証までの完全なインストールチェーン
dshはプラグインに対して統一されたインストール入口を提供しており、1つのコマンドで完了します。コマンドの基本形式は以下の通りです。
# プラグインをweb profileにインストール（--profileは対象環境を指定、必須）
dsh plugin --profile web add <ソース>
# プラグインをtuiターミナル環境にインストール
dsh plugin --profile tui add <ソース>
このコマンドには、しっかり理解すべき3つのフィールドがあります。
- dsh plugin：プラグイン管理の統一入口で、インストールや管理などの操作はすべてここから入ります。
- --profile web / --profile tui：必須パラメータで、プラグインをどの実行環境にインストールするかを指定します。これがdshとnpm/Pythonインストールの最も本質的な違いです——あなたがインストールするのは「ローカルマシンへ」ではなく、「あるProfileへ」なのです。
- add <ソース>：プラグインのソースを指定します。ソースはnpmパッケージ名（例：@linxin666/dsh-web-ui-all@latest）でも、GitHubリポジトリのアドレス（例：github:zhu1090093659/dsh-web-ui）でもかまいません。
dsh-web-ui のインストールを例にします。公式のオープンソースアドレスは https://github.com/zhu1090093659/dsh-web-ui で、対応するコマンドは次のとおりです：
dsh plugin --profile web add @linxin666/dsh-web-ui-all@latest
このコマンドの @latest サフィックスに注意してください。開発段階では最新版を追うのはとても便利ですが、本番環境のプラグインバージョン戦略は別途検討する必要があり、後ほどバージョン固定の話で詳しく展開します。
一連の完全なインストールフローは通常次のようになります：
Profile を選択
↓
プラグインをインストール
↓
依存関係 / README を確認
↓
対応するサービスを再起動
↓
プラグインがロードされたか検証
このチェーンの中で、「対応するサービスを再起動」は初心者が最も見落としやすいステップであり、多くの「確かにインストールしたのに反映されない」問題の根源でもあります。ここでの言い回しが「対応するサービスを再起動」であることに注意してください——指定した Profile の環境にのみ影響し、dsh エコシステム全体を一からやり直す必要はありません。
また、「依存関係 / README を確認」というステップは形式主義ではありません。一部のプラグイン（特にブラウザ系）は追加のブラウザ拡張や外部サービスを必要とし、公式がワンクリックインストールスクリプトを提供します。この種のプラグインは、手動でコマンドを組み立てるのではなく、公式スクリプトや README に厳密に従ってインストールすることをお勧めします——手動で組み立てると拡張登録のような暗黙のステップを見落としやすく、プラグインのロードは成功するが機能が動作しないという事態を招き、トラブルシューティングのコストが極めて高くなるからです。
インストール後、再起動すれば設定のプラグインリストでインストール済みのプラグインを確認できます。このステップが「プラグインがロードされたか検証」の具体的なアクションです。また、左側のリストでプラグインの機能を確認し、スキンを試しに適用することもできます——これは機能確認であると同時に、プラグインの効果を体験する最速の方法でもあります。
プラグインリスト、機能プレビュー、アンインストール入口：設定ページの3つの操作位置
プラグインをインストールした後、日常的な操作は実際には設定ページの3つの位置に集中しています。この3つの位置の役割分担を理解すれば、多くの試行錯誤の時間を節約できます。
1つ目の操作位置はプラグインリストです。インストールして再起動した後、設定のプラグインリストでインストール済みのプラグインを確認できます。これは「インストールされたかどうか」を確認する第一の現場です——ここにプラグインが表示されない場合、問題はインストールチェーンや Profile の指定にあり、プラグイン機能そのものにはありません。
2つ目の操作位置は機能プレビューとスキンの試し適用です。左側のリストでプラグインの機能を確認し、スキンを試しに適用できます。この位置の価値は「ゼロコスト体験」にあります：特にスキン、テーマ、デスクトップペットなどコア能力に影響しないプラグインにとって、リストで効果を確認してから残すかどうかを決める方が、インストールしてからアンインストールするよりもはるかに手間がかかりません。
三つ目の操作スロットはアンインストール入口です。プラグインをアンインストールするには、設定メニューのプラグイン一覧でアンインストールボタンをクリックするだけです。確認をクリックすればアンインストールが完了します。この一連の流れにコマンドラインは一切関与せず、ターミナル操作に不慣れなチームメンバーにとって特に扱いやすいものになっています。
これら三つの操作スロットを並べて見ると、dsh のプラグイン管理 UI 設計が明確な原則に従っていることがわかります。それは発見・プレビュー・クリーンアップをすべて同じリストに集約するというものです。これはプラグインの数が増えた後のメンテナンスにとって極めて重要です——あなたの Profile に十数個のプラグインが積み重なったとき、統一されたリストビューはほぼ唯一の制御可能な手がかりとなるからです。
ここで実戦経験を一つ補足します。新しいプラグインを試しに入れるときは、一度に一つだけ追加し、インストール後すぐに検証して副作用がないか観察することをおすすめします。その理由は、プラグインは重ね合わせることができ、能力が高いプラグインほど実行時の状態への変更が大きくなるからです。一度に五つインストールして問題が起きた場合、どれが原因か判断できませんが、一度に一つなら問題の特定コストはほぼゼロです。この原則は、ブラウザ系やサブスクリプション系など高権限のプラグインをインストールする際に特に重要です。
UI 強化の四本柱：dsh-web-ui、DSH-better-sidebar、dsh-TUI、dsh-at-file の能力の境界
UI 強化とワークベンチのカテゴリのプラグインは、「インターフェースが使いにくい」という問題を解決するもので、dsh をコマンドラインツールから IDE に近い完全なワークベンチへとアップグレードすることを目標としています。このカテゴリでは、四つのプラグインの境界をはっきりさせておく価値があります。なぜなら、名前は似ているのに位置づけは全く異なり、選び間違えればインストールが無駄になるからです。
まず表で四者の位置づけを明確にしましょう：
| プラグイン | 解決する問題 | インストールコマンド |
|---|---|---|
| dsh-web-ui | Web UI オールインワン：タスクボード、Git グラフ、右側パネル、リモートモバイル、デスクトップペット、リアルタイム Token 統計、スキンセンター | dsh plugin --profile web add github:zhu1090093659/dsh-web-ui |
| DSH-better-sidebar | 完全なサイドバーワークベンチ：ファイルツリー / エディタ、ターミナル、Git、サブエージェント、サードパーティプラグインによる新しい Tab の登録をサポート | dsh plugin --profile web add dsh-better-sidebar |
| dsh-TUI | Claude Code スタイルの全画面ターミナル TUI：ストリーミング思考、Esc 二回押しで巻き戻し、ステータスバー、モデル切り替え | dsh plugin --profile tui add @deepseek-harness-tui/dsh-tui |
| dsh-at-file | 入力ボックスで @ によりワークスペースのファイル / ディレクトリを素早く検索して参照 | dsh plugin --profile web add github:omdsh-dev/dsh-at-file |
それぞれの能力の境界を順に説明します：
- dsh-web-ui は「面」の補完です。単にインターフェースを差し替えるだけでなく、Agent ワークフローを中心にタスクボードや Git グラフといったワークベンチ機能を補完します。その機能リストにリアルタイム Token 統計とスキンセンターが含まれている点に注目してください——これは単なる UI シェルではなく、実行時の可観測性の一部も担っていることを意味します。「完全な Web ワークベンチ」を必要とするユーザーに適しています。
- DSH-better-sidebar は「構造」の補完です。これが解決するのは「ワークスペースの組織化能力」の問題であり、常駐サイドバーを提供します。ファイルツリー / エディタ、ターミナル、Git、サブエージェントといった機能がサイドバーに整理され、さらにサードパーティプラグインが新しい Tab を登録できることをサポートしています——これは、それ自体が拡張可能なコンテナであることを意味します。dsh を「AI IDE」にしたいユーザーに適しています。
- dsh-TUI は「ターミナル体験」の補完です。ターミナル内でストリーミング出力とメッセージの遡及を提供し、体験は Claude Code に近いものです。注目すべきは、これがインストールするのが tui Profile であり、web Profile ではない点です——これは四つの中で唯一 Profile をまたぐものであり、Profile メカニズムの必要性を改めて裏付けています。
- dsh-at-file は「入力インタラクション」の補完です。その使い方は非常に直感的で、入力ボックスに @ を入力するだけでワークスペースのファイルを検索して参照できます。使用例：
@runoob-demo/src/main.py を分析してください
@runoob-demo/src/api と @runoob-demo/src/service を比較してください
コード Agent にとって、このインタラクション方式はファイル内容を手動でコピーするよりもはるかに自然です。Agent の能力の上限を変えるものではありませんが、「正しいコンテキストを Agent に与える」ための操作コストを大幅に下げます——エンジニアリングの観点から見ると、これはまさにコンテキスト品質問題の中で最も過小評価されている一环です。
これら四つのプラグインを並べて見ると、明確な分業の論理が見えてきます：dsh-web-ui は「ワークベンチがどんな見た目か」を担い、DSH-better-sidebar は「ワークスペースをどう組織するか」を担い、dsh-TUI は「ターミナルユーザーがどう使うか」を担い、dsh-at-file は「コンテキストをどう素早く参照するか」を担います。これらは重ねて使うことも、必要に応じて取捨選択することもできます。中でも dsh-web-ui と DSH-better-sidebar はコミュニティで最も人気の組み合わせであり、前者は Web インターフェースの機能面を補完し、後者は常駐サイドバーを提供します——dsh を主力の開発環境として使うつもりなら、この二つはほぼ最優先で検討すべき出発点です。
最後にインストール面の細かい点を一つ注意しておきます：これら四つのプラグインのうち三つは web Profile を、一つは tui Profile をインストールし、さらにそれらのソース形式もそれぞれ異なります——npm パッケージ名（dsh-better-sidebar）、@scope 付きのパッケージ（@deepseek-harness-tui/dsh-tui）、github: プレフィックス付きのリポジトリ URL があります。これは、インストールコマンドをコピーする際に、プラグイン名だけでなくソース形式も必ず一緒にコピーしなければならないことを意味し、そうでなければインストールに失敗する可能性が高いです。具体的なソース形式の仕様や、サードパーティプラグインをインストールする際に必ず行うべき四つのセキュリティチェック（ソースコード、ライセンス、依存関係、バージョン固定）については、後半で引き続き展開します。次に、私たちは視覚とマルチモーダル、マルチ Agent とワークフロー、ブラウザ自動化、メモリとコンテキスト移行、プラグインの発見と管理といったコアプラグインカテゴリの深掘り解説に入り、完全なシナリオ別推薦とセキュリティチェックリストを提示します。
前段では、dsh のプラグイン分類、Profile 隔離メカニズム、`dsh plugin` の統一インストール入口、そして一連の UI/ワークベンチプラグインを分解して詳しく説明しました。本段の重点は「能力型プラグイン」に置きます：純テキストモデルをマルチモーダルに補完する視覚アドオンから、マルチ Agent 協調、ブラウザ自動化、さらにコンテキストガバナンスと長期的な管理の姿勢へと進み、最後にそのまま実行できる落地チェックリストを提示します。
視覚能力の外付け：modlens の構造化された視覚証拠と、dsh-vision-toolkit、dsh-vision-router の役割分担
dsh 自体は生まれつきマルチモーダルなランタイムではなく、その戦略は視覚能力をプラグインとして、もともとテキスト中心の Agent に「外付け」することにあります。ここで最も誤解されやすい点は、コミュニティでいわれる「純テキストモデルを瞬時にマルチモーダル化する」というのは、画像をモデルのコンテキストに詰め込んで自力で推測させることではなく、まずプラグインの層で画像を構造化された視覚証拠に変換し、それをテキストモデルに渡して処理させる、ということです。
modlens を例にすると、その中心的な考え方はこうです。会話にウェブページのスクリーンショットを貼り付けると、モデルが受け取るのは「これはウェブページのスクリーンショットです」といった漠然とした一文ではなく、テキストモデルが精読できる一連の証拠です。それには OCR テキスト（ページ上にどんな文字があり、それぞれの内容は何か）、レイアウト情報（ブロックの階層と配置関係）、座標（各要素が画面内のどこに位置するかの境界）、そしてセマンティックラベル（この領域がナビゲーションなのか、ボタンなのか、それとも本文なのか）が含まれます。この出力は下流のテキストモデルにとって非常に扱いやすく、モデルはピクセルを理解する必要はなく、位置と意味を備えた「ページ説明書」を読むだけで、ユーザーの質問に答えられます。たとえば「スクリーンショットのあの送信ボタンはページのどこにあるのか」「本文中の価格はいくらか」といったことです。
この方式のエンジニアリング上の価値は、不確実性をモデル層からプラグイン層へ移せることにあります。OCR の精度、レイアウト復元の忠実度、座標の精度は、すべて視覚プラグインが担い、個別にチューニングできます。テキストモデルは意味推論だけを担当します。問題が起きたときの切り分けも容易です。OCR が文字を誤認識したなら視覚チェーンの問題であり、OCR は正しいのにモデルが誤答したなら推論チェーンの問題です。対照的に、画像をそのまま純テキストモデルに投げると、中間証拠は得られず、どの段階で誤りが生じたのかも判断できません。
コミュニティにある他の2つの視覚プラグインは、異なるトレードオフをしています。dsh-vision-toolkit はより完全な視覚ツールボックスで、意図に基づく Q&A、長いスクリーンショットの OCR、UI 復元、grounding（自然言語の指示対象を画面内の具体的な要素に位置づけること）、そしてピクセル diff（2回のスクリーンショットの差分を比較すること）をカバーします。日々の業務がフロントエンド開発、UI の複製、スクリーンショット比較といった場面に集中しているなら、OCR だけを行う方案よりはるかに実用的です。なぜなら UI 復元に必要なのは文字だけでなく、「このボタンがどんな見た目で、どこにあり、前のバージョンと何ピクセル違うのか」を知ることでもあるからです。一方、dsh-vision-router は無料の視覚チェーンとピクセルレベルのツールという位置づけで、視覚推論をローカルの Ollama や LM Studio にルーティングすることをサポートします。データに敏感で、視覚能力を完全にローカル展開したいチームにとって、この点は特に重要です。画像はマシン外に出ず、モデル呼び出しはローカル推論サービスを通るため、コストを抑えつつコンプライアンス要件も満たせます。
三者の役割分担はこう理解できます。modlens は「画像をテキストモデルが読める証拠に変える」ことを解決し、dsh-vision-toolkit は「フロントエンドと UI の場面でより細やかな視覚操作を行う」ことを解決し、dsh-vision-router は「視覚推論をどこで動かすか、ネット接続が必要か」を解決します。これらは重ねて使えますが、導入初期には全部を入れることはおすすめしません。まず自分の主な場面を明確にしましょう。汎用 OCR と文書理解なら modlens を優先し、フロントエンドの複製なら dsh-vision-toolkit を優先し、ローカル化とコスト重視なら dsh-vision-router を優先します。
以下の表は、3つのプラグインの位置づけと適用範囲を並べて比較し、選定を容易にするものです。
| プラグイン | 中核的な出力 | 典型的な場面 | 展開とコストの傾向 |
|---|---|---|---|
| modlens | 構造化 OCR、レイアウト、座標、セマンティックラベル | ウェブページのスクリーンショット分析、文書理解、画像内容の抽出 | 汎用、外部またはローカルの視覚モデルに依存 |
| dsh-vision-toolkit | 意図に基づく Q&A、長いスクリーンショットの OCR、UI 復元、grounding、ピクセル diff | フロントエンド開発、UI 複製、スクリーンショットの回帰比較 | 機能範囲が広く、深い視覚ワークフローに適する |
| dsh-vision-router | 無料の視覚チェーンとピクセルレベルのツール、ローカル推論にルーティング可能 | ローカル展開、コストとコンプライアンスに敏感な場面 | Ollama / LM Studio によるローカル実行をサポート |
インストールコマンドはすべて dsh plugin --profile web add の入口を通します。たとえば modlens を Web Profile に入れる場合：
# ビジョンプラグインを web profile にインストール
dsh plugin --profile web add @liustack/modlens
# フロントエンドや UI 再現のシナリオではビジョンツールキットを重ねて使える
dsh plugin --profile web add @anionex/dsh-vision-toolkit
# ローカル視覚チェーン：まずローカルの Ollama または LM Studio が準備できていることを確認
dsh plugin --profile web add dsh-vision-router
# インストール後、対応するサービスを再起動し、設定のプラグイン一覧でロード状態を確認するよくあるエンジニアリング上の落とし穴は、ビジョンプラグインを間違った Profile にインストールしてしまうことです。普段ターミナル TUI で作業しているのに、ビジョンプラグインを web Profile に入れてしまうと、ターミナルセッションでは視覚機能が現れません——Profile 同士は隔離されており、プラグインはどの環境に入れたかで、その環境でのみ有効になります。もう一つの落とし穴は、ローカル視覚チェーンを起動する前にルータープラグインをインストールしてしまい、呼び出し時に推論サービスが見つからないことです。推奨される操作順序は、まずローカルモデルサービスが利用可能か確認し、次に dsh-vision-router をインストールし、最後にセッション内でスクリーンショットを使ってエンドツーエンドで検証することです。
スキンとデスクトップペットもプラグイン：dsh-deep-whale と whale-girl/dsh-pet シリーズのインストールの違い
「すべてがプラグイン」という徹底ぶりを最もよく示す証拠を探すなら、スキンとデスクトップペットが最良の例です。従来の Agent では、テーマや外観、イースターエッグは通常コアにハードコードされており、変更するには公式アップデートを待つか、自分でフォークを保守するしかありませんでした。しかし dsh では、「インターフェースがどんな見た目か」「デスクトップにもう一匹ペットがいるかどうか」さえもプラグインであり、いつでも追加・削除でき、コアロジックには互いに影響しません。
最初の例は dsh-deep-whale です。これはクジラ娘のスキンシリーズで、深海メイド工房などのテーマを含み、ライトとダークの両モードをサポートします。その意義は見た目の良さだけではありません。長時間画面を見つめる開発者にとって、ライト／ダークモードの切り替えは実に切実な体験要件です。以前はこうしたニーズをテーマ設定ファイルの変更やスタイルの上書きで対応していましたが、今ではインストールコマンド一つで載せられ、不満なら設定でアンインストールでき、実にすっきりしています。
二つ目の例は whale-girl と dsh-pet シリーズのデスクトップペットです。小さなクジラを作業台に置き、ドラッグしたり、餌をあげたり、インタラクションしたりできます。これは純粋な娯楽のように聞こえますが、まさにプラグインシステムの境界を証明しています。プラグインの権限と能力は十分に大きく、インタラクティブで状態を持つ UI コンポーネントをレンダリングし、Agent の作業台と共存できます。デスクトップペットを動かせるということは、プラグインのロード、ライフサイクル管理、UI マウントポイントという一連の経路がすべて通っていることを示します。
インストールの違いには特に注意が必要です。dsh-deep-whale は標準的な GitHub ソースからのインストール経路をたどります：
# クジラ娘スキンシリーズをインストール（ライト／ダークモード対応）
dsh plugin --profile web add github:Small-tailqwq/dsh-deep-whale一方、whale-girl と dsh-pet シリーズはコミュニティに複数のリポジトリがあり、実装や依存関係、設定項目が互いに異なる可能性があり、すべてをカバーする汎用のインストールコマンドはありません。正しいやり方は各リポジトリ自身の README に従ってインストールすることであり、経験に頼って他人のコマンドをそのまま流用してはいけません。こうしたプラグインは通常、ペットのアセットパックのパス、インタラクションのオン／オフ、初期位置など、いくつかの追加設定を伴います。インストール後は設定のプラグイン一覧に戻って正常にロードされたか確認し、それから対応するサービスを再起動してください。
エンジニアリング上のアドバイスとしては、スキンとデスクトップペットは「純粋なプレゼンテーション層のプラグイン」であり、リスクは比較的制御しやすいものの、依存関係はやはりきちんと見極める必要があります。見た目がただのスキン変更にすぎないプラグインでも、無関係な依存関係を大量に持ち込んだり、追加のネットワーク権限を要求したりする場合は警戒に値します。また、スキン系プラグインはしばしば UI プラグインとスタイルが結合しています。dsh-web-ui とあるスキンを同時にインストールしていてスタイルの競合が起きた場合は、まず両者の読み込み順序とスコープを確認し、必要ならスキンを無効化して問題を切り分けましょう。
マルチ Agent とワークフローの役割分担：dsh-agent-teams がタスクを分解し、dsh_workflow がプロセスを固定する
UI プラグインが解決するのは「dsh をどう使うか」であり、マルチ Agent プラグインが解決するのは「複数の Agent をどう一緒に働かせるか」です。この 2 種類のプラグインは抽象レベルがまったく異なり、だからこそ重ね合わせることで非常に強力なワークフローを構築できます。
dsh-agent-teams の発想は非常に直感的です。現在のセッションを「隊長」にし、隊長がタスクを分解して、会話を続けられる複数の子 Agent に割り当てます。ここでのキーワードは「会話を続けられる」であることに注意してください。子 Agent は一度きりの関数呼び出しではなく、独立した会話コンテキストを持つ実行単位であり、特定の子 Agent にさらに質問したり、修正したり、要件を追加したりできます。さらに、依存関係のあるタスクの編成と自動スケジューリング、および各子 Agent の進捗を観察するためのリアルタイムパネルもサポートしています。
「依存関係のあるタスク」という点は掘り下げる価値があります。実際の開発タスクは平坦であることはほとんどなく、フロントエンドのページはバックエンドのインターフェース定義に依存し、テストはフロントエンドとバックエンドの両方が完了していることに依存し、レビューはテストの通過に依存します。agent-teams ではこうした依存関係を表現でき、スケジューラがトポロジカル順に進めます。すべての子 Agent が一斉に突撃するのではありません。これは実際のエンジニアリングにおいて、大量の人手による待ち時間と手動調整を省けます。リアルタイムパネルは「ブラックボックス不安」を解消します。最終結果を待つのではなく、各子 Agent が今何をしていてどこで詰まっているかを見られるのです。
一方、dsh_workflow が解決するのは別の次元の問題です。すなわち、Agent のワークフローを固定して繰り返し実行することです。公式の説明では、これは生成・保存・復元・観察・ガバナンスが可能な Workflow 層です。エンジニアリングの言葉に訳すと、一度成功した実行パスを再利用可能なプロセス定義として定着させ、次に同種のタスクに遭遇したときは Agent に毎回即興でやらせるのではなく、そのまま実行を復元するということです。
両者の役割分担は一言でまとめられます。agent-teams は「複数の Agent が一緒に働く」ことを解決し、workflow は「Agent のワークフローを固定して繰り返し実行する」ことを解決します。前者は並列性と協調を担い、後者は決定性と再利用性を担います。両者は衝突せず、むしろ補完し合っています。
インストールコマンドは以下のとおりです。agent-teams は npm スタイルのソースを使いますが、dsh_workflow は現在 GitHub ソースである点に注意してください。
# 多 Agent 协作：当前会话变队长
dsh plugin --profile web add @nanmicoder/dsh-agent-teams
# 工作流层：可生成、保存、恢复、观察、治理
dsh plugin --profile web add "github:dsh-external/dsh_workflow#main"
# 注意：生产环境不建议长期追踪 main 分支，建议固定到具体 commitよくある落とし穴は、agent-teams の「隊長」を万能スケジューラだと解釈し、特に重いタスクを際限なく分解してしまうことだ。その結果、子 Agent の数が爆発し、Token コストが制御不能になり、依存関係が誰にも理解できないほど複雑になる。分解には上限を設けることを勧める。たとえば、子 Agent の数は一桁に抑え、依存の階層は三層を超えないようにする。もう一つの落とし穴は、workflow が main ブランチを追うことだ。これは開発段階では問題ないが、このフローがすでに日常の本番運用に入っている場合、main が更新されると「昨日は動いたのに、今日は壊れた」という事態が起こりうる。この点については後の小节でさらに展開する。
Leader/Frontend/Backend/Test/Review 実行チェーン：要件分解から Workflow の反復実行までの完全な流れ
agent-teams と workflow を組み合わせると、完全な実行チェーンを形成できる。このチェーンは、dsh が「ツールからランタイムへ」と向かうことを理解するための最良のサンプルである。
起点は一つの要件だ。この要件がセッションに入ると、現在のセッションが Leader Agent としてまずタスク分解を行う。曖昧な要件を、独立して実行でき、明確な成果物を持ついくつかのサブタスクに翻訳する。続いて、各子 Agent が順に登場する。Frontend Agent は UI 実装を担当し、Backend Agent はインターフェースとデータ層を担当し、Test Agent は検証を担当し、Review Agent は品質チェックを担当する。これらの子 Agent は孤立しているわけではない。それらの間には依存関係があり、自動スケジューラによって順番に進められる。フロントエンドはバックエンドがインターフェース定義を確定するのを待ち、テストはフロントエンドとバックエンドの両方が完了するのを待ち、Review はテスト通過後に開始される。
このチェーンが一度通り抜けられると、その価値は「今回のタスクが完了した」ことだけではなく、この実行パターン自体を Workflow 層 によって固定化できることにある。プロセス定義として保存し、次に同種の要件に遭遇したときに実行を復元する。こうしてプロセスは「毎回オーケストレーションし直す」から「検証済みのパスを再利用する」へと変わり、可観測性にも足がかりができる。各ステップの入出力が見え、問題が起きたときも具体的な段階を特定できる。
このチェーンを書き出すと次のようになる：
要件
↓
Leader Agent（タスク分解：成果物と依存関係を定義）
├── Frontend Agent
├── Backend Agent
├── Test Agent
└── Review Agent
↓
Workflow（プロセスの固定化：生成 / 保存 / 復元 / 観察 / ガバナンス）
↓
最終結果このとき dsh の役割は質的に変化する。もはや「AI がコードを書いてくれる」だけでなく、「AI Agent が自ら複数の実行ユニットを組織してタスクを完了する」のである。開発者は「一行ずつ指示する」ことから「目標と制約を定義する」ことへと変わり、具体的にどう分解し、どうスケジュールし、どう検証するかはランタイムとプラグインに任せる。これが、dsh の価値がどれだけの機能を備えているかではなく、組み合わせ可能なランタイム層を提供している点にあると言われる理由でもある。
エンジニアリング上の注意点として、このチェーンはコンテキストの品質に対する要求が非常に高い。Leader が明確に分解してこそ、子 Agent は逸脱しない。子 Agent 間のインターフェースの取り決めが不明確だと、Frontend と Backend がそれぞれ勝手に書いてしまい、最後に噛み合わなくなりやすい。実践的な提案は、Leader の分解段階で「インターフェース契約」と「受け入れ基準」を明確に書き、サブタスクの明示的な入力とすることであり、子 Agent が自分で推測することを期待しないことだ。
dsh-browser と BrowserSkill：ローカル Chrome を直接駆動しログイン状態と Cookie を保持する
Agent が本当に本番環境に入ると、コードを読み書きできるだけではしばしば不十分であり、Web ページを開き、ページ内容を読み取り、クリックや入力を行い、ログイン状態を保ったままタスクを実行する必要がある。ここがブラウザ系プラグインの出番である。
ここで最も重要な違いは、dsh-browser が本機の Chrome を直接駆動するという点であり、クリーンなヘッドレスブラウザを起動するのではないということです。この違いはエンジニアリング上、決定的です。ヘッドレスブラウザの方式は毎回起動するたびに通常まっさらな状態——ログイン状態も Cookie も、本機のブラウザに蓄積されたセッションもありません。そのため Agent がタスクを完了するには、まずログインの流れを一通りこなす必要があり、CAPTCHA、二要素認証、リスク管理ポリシーに遭遇すると、簡単に詰まってしまいます。
一方 dsh-browser は、本機 Chrome の既存のログイン状態と Cookie を再利用するため、Agent は毎回ゼロからログインする必要がありません。サイトの自動化、バックエンド操作、データ収集、Web テストといったログイン状態を必要とするタスクにとって、これは実に確かな効率の違いです。普段 Chrome でログイン済みのアカウントを、Agent はそのまま使え、タスクは「まずログインを解決する」から「すぐに作業する」へと変わります。
テンセントがオープンソース化した BrowserSkill も同種の発想で、実際にログイン済みのブラウザによる自動化ソリューションを提供しており、その形態は CLI とブラウザ拡張機能です。こうしたソリューションに共通する特徴は、単に npm パッケージをインストールするだけでは済まず、しばしばブラウザ拡張機能やその他の外部コンポーネントを伴う必要があることです。
だからこそ、インストール方法には慎重でなければなりません。コミュニティでは、dsh-browser はリポジトリが提供するワンクリックインストールスクリプト（ブラウザ拡張機能を含む）でインストールし、BrowserSkill はリポジトリの説明に従ってインストールします。正しいやり方は、公式スクリプトまたは README に従ってインストールし、手動でコマンドを組み立てないことです。理由は三つあります。第一に、ブラウザ拡張機能は特定の方法でブラウザに読み込む必要があり、手動でコマンドを組み立てるとこの手順を簡単に漏らしてしまいます。第二に、こうしたプラグインはブラウザと通信するためのローカルポートやブリッジプロセスに関わる場合があり、パラメータが正しくないと接続できません。第三に、拡張機能の権限範囲は比較的大きく、公式スクリプトは通常どの権限を付与するのかを明確に示しますが、手動インストールでは権限をよく理解しないまま拡張機能を入れてしまう可能性があります。
セキュリティの面では特に強調すべきです。ブラウザ自動化プラグインの権限レベルは、UI スキン系のプラグインよりも明らかに高いです。それはログイン済みページの内容を読むことができ、あなたの代わりにクリックや入力ができるため、ひとたびプラグインのコードに問題があれば、影響範囲はあなたのアカウントやデータに及ぶ可能性があります。したがってインストール前に必ずソースコードを確認し、ブラウザ制御、ファイルシステム、ネットワークリクエストに関わる部分を重点的にレビューしてください。バージョンや commit を固定し、出所不明のブラウザ拡張機能をメインブラウザに気軽に入れないでください。
コンテキストのガバナンスと移行：dsh-chat-import による無損失インポート、dsh-context による Token トレンドの可視化
Agent を使う時間が長くなるほど、本当の問題はしばしばモデルが賢くないことではなく、コンテキストがどんどん乱れていくことです——これは Coding Agent を長期間使う開発者なら誰もが直面する現実です。この問題をめぐって、dsh には専用のプラグイン群があります。
dsh-chat-import が解決するのは「移行」の問題です。Claude Code、Codex、ChatGPT、Cursor、Gemini などのツールから履歴セッションを無損失でインポートできます。すでに他の Coding Agent を大量に使っているユーザーにとって、こうした移行プラグインの価値は非常に高いです——過去に蓄積した会話、意思決定の記録、コンテキストの手がかりを捨てる必要はなく、dsh に持ち込んで使い続けられます。これが実際に下げるのは切り替えコストです。以前はツールを変えるとゼロから始めることを意味しましたが、今は履歴を持ったまま入ってこられます。
dsh-context が解決するのは「見える化」の問題です。コンテキストの構成、Token トレンド、圧縮とトリミングの可視化パネルを提供します。現在のコンテキストがどの部分から構成されているか——システムプロンプト、履歴メッセージ、ツール呼び出し結果、ファイル内容がそれぞれどれだけを占めるか——を見られます。Token 消費のトレンドを見て、制御不能な方向に向かっていないかを判断できます。必要に応じて圧縮やトリミングを行い、その効果を観察できます。長時間稼働する Coding Agent にとって、この可視化は付け足しではなく必需品です。コンテキストが見えなければ、コンテキストをガバナンスすることはできません。
ここで、より根本的な判断を提示したい：Agent の効果は大部分が「モデル能力 + コンテキスト品質 + ツール能力 + タスク状態」に依存しており、単純にモデルの benchmark を見るべきではない。多くの人はツールを選ぶときにモデルのスコアばかり気にするが、実際の体験の差は往々にして残りの3項目から生まれる。コンテキスト品質が悪ければ、どんなに強いモデルでも的外れな答えを返す。ツール能力が弱ければ、Agent は空論しか語れない。タスク状態の管理が混乱していれば、何ターンか経つうちに目標を見失う。dsh のプラグイン体系は、まさにこれらの項目をすべてプラグイン可能・観測可能・交換可能な部分に変えており、これこそが「機能が固定された Agent」と比べたときの長期的な価値の所在である。
エンジニアリング上の提案はこうだ。もし他のツールから移行してきたなら、まず dsh-chat-import をインストールして履歴を持ち込み、次に dsh-context をインストールしてコンテキストの可観測性を確立する。この2つのプラグインは dsh-at-file（入力欄で @ を使ってワークスペースのファイルを参照）と組み合わせることで、非常に快適な移行コンボを形成する——履歴セッションがあり、コンテキストが見え、ファイル参照もより自然になる。
# 他の Coding Agent から履歴セッションをインポート
dsh plugin --profile web add dsh-chat-import
# コンテキスト構成、Token トレンド、圧縮 / トリミングの可視化パネル
dsh plugin --profile web add dsh-context
# @ と組み合わせてワークスペースのファイルを参照、例えば：
# @runoob-demo/src/main.py を分析してください
# @runoob-demo/src/api と @runoob-demo/src/service を比較してください注意すべき落とし穴はこれだ。履歴セッションをインポートした後、コンテキストのサイズが急速に膨らみ、かえって応答を遅くしコストを押し上げる可能性がある。正しいやり方は、インポートした直後に dsh-context で一度 Token トレンドを確認し、もう必要のない履歴を圧縮またはトリミングすることであり、すべてを一度にコンテキストへ詰め込むことではない。移行の目的は価値ある意思決定の手がかりを残すことであって、古い荷物をそのまま運び込むことではない。
2026年9月の最新動向：dsh-find-plugin の自然言語によるプラグイン検索と dsh-market の長期的な管理姿勢
プラグインの数がどんどん増えると、新しい問題が自然に生じる。プラグインはどこで探すのか。dsh のこの問題への答えは、その一貫したスタイルに非常によく合っている——「プラグインを探すこと」自体もプラグインなのだ。
dsh-market は設定ページにプラグインマーケットを内蔵しており、検索、カテゴリ分類、ワンクリックでのインストールと更新に対応している。つまり、GitHub でリポジトリを一つずつ漁ったり、インストールコマンドを手で写したりする必要はもうない。よく使うプラグインは設定の中で見つけてインストールでき、その後の更新も任せられる。dsh を長期的に使うつもりの人にとって、これはほぼ最優先のプラグインだ。
dsh-find-plugin はさらに一歩進んでいる。セッション内で直接自然言語を使ってプラグインを探し、説明とインストールコマンドを返す。例えば「ウェブページのスクリーンショットを分析できるプラグインはありますか」と直接尋ねると、プラグイン名、機能説明、対応するインストールコマンドを返してくれる。これにより「プラグインの発見」は「キーワードを知ってから検索する」から「ニーズを説明すれば見つかる」へと変わった。dsh に触れたばかりで、まだプラグインの命名体系に詳しくない新規ユーザーにとって、この入口は非常に親しみやすい。
インストールコマンドは以下の通り：
# 設定ページ内蔵のプラグインマーケット：検索、カテゴリ分類、ワンクリックインストール / 更新
dsh plugin --profile web add dshmarket
# セッション内で自然言語によるプラグイン検索、説明とインストールコマンドを返す
dsh plugin --profile web add dsh-find-plugindsh を長期的に使うつもりなら、推奨される姿勢はこうだ。まず dsh-market をインストールし、次にマーケットを通じて必要に応じて残りのプラグインをインストールし、その後の更新管理もまとめて任せる。最初から何十もの GitHub リポジトリを手動で探すのはやめよう。それは非効率であり、出所不明や非互換のものをインストールしてしまいやすい。まずコアのワークフローを動かし、それから徐々に他の能力を追加していく——これが dsh の最も適した使い方であり、「インストールして、開いて、終わり」ではなく、漸進的に組み上げていくものなのだ。
次に来るのは、本番運用において最も重要な規律の一つです：バージョンまたは commit を固定し、latest や main を追わないこと。dsh はまだ急速なイテレーションの段階にあり、コミュニティプラグインの API も変化する可能性があります。常に main ブランチを追い続けると、「今日は動くのに、プラグイン作者が更新した途端、明日突然壊れる」というリスクがあります。本番環境ではこのような不確実性のコストは非常に高く、プラグイン更新が原因なのか、自分の設定に問題があるのかを即座に判断するのは難しいからです。
| やり方 | 記述例 | 適用段階 | リスク |
|---|---|---|---|
| ブランチを追う | github:dsh-external/dsh_workflow#main | 個人のお試し、新機能の追跡 | 上流が変わると使えなくなる可能性がある |
| commit を固定 | github:xxx/xxx@a1b2c3d | 本番環境、チーム協業 | セキュリティと機能の更新を能動的に追う必要がある |
具体的な構文はプラグインマネージャーの現行バージョンに準じますが、原則は明確です：本番環境では依存を特定の commit に固定し、「アップグレード」を受動的に受け入れるのではなく、意識的でロールバック可能な操作にすることです。両者のトレードオフはこう理解できます：main を追うことで得られるのは最新機能で、支払うのは安定性です。commit を固定することで得られるのは再現性で、支払うのは自分でアップグレードのペースを管理することです。チーム協業の場面では、後者のほうがほとんど常に割が合います。
サードパーティプラグインをインストールする際には、習慣にすべき4つの確認事項もあります：まずソースコードを見る。特に Shell、ブラウザ、OAuth、API Key、ファイルシステム、ネットワーク権限に関わるプラグインでは、README の宣伝文句だけを見てはいけません；ライセンスを見る。商用利用、二次開発、企業内導入を予定している場合は、事前に License の制限を確認してください；依存関係を見る。見た目は単なる UI プラグインでも、不要な依存を大量に取り込んでいるプロジェクトは警戒に値します；バージョンまたは commit を固定する。理由は上述のとおりです。さらに多くのプラグインを探索したい場合は、GitHub topic「dsh-plugin」、コミュニティが保守する厳選リスト、そしてコミュニティのプラグインディレクトリサイトから始めるとよいでしょう。特に注意すべきなのはサブスクリプション系のプラグインです——これらはしばしばアカウント認可やサードパーティサービスに関わり、セキュリティリスクは通常の UI プラグインより明らかに高くなります。「無料モデル」「無料サブスクリプション」といったキーワードだけでインストールせず、必ずソースコード、権限範囲、実際の認可フローを先に確認してください。
まとめとベストプラクティス
ここまでで、dsh の組み込みプラグインとコミュニティプラグインの全体像はほぼ広げ終わりました。全文の要点を実行可能なチェックリストに圧縮すると、次のようになります：
- まず Profile の分離を理解する：プラグインはどの環境（web / tui / headless）にインストールされたかで、その環境でのみ有効になります。間違った Profile にインストールすることが、最もよくある「プラグインが反応しない」原因です。
- インストール入口を統一する：すべてのプラグインは
dsh plugin --profile <target> add <source>を通します。インストール後は対応するサービスを再起動し、設定のプラグイン一覧でロード状態を確認します。 - 視覚能力はシーン別に選ぶ：汎用 OCR とドキュメント理解なら modlens；フロントエンド再現、UI 復元、ピクセル diff なら dsh-vision-toolkit；ローカライズとコスト重視なら dsh-vision-router（Ollama / LM Studio と組み合わせる）。原理は「まず画像を構造化された証拠に変換し、それをテキストモデルに渡す」ことだと覚えておきましょう。
- スキンとデスクトップペットもプラグイン：dsh-deep-whale は標準の GitHub ソース経由でインストールし、whale-girl / dsh-pet シリーズは各リポジトリの README に従ってインストールしてください。他人のコマンドをそのまま流用してはいけません。
- マルチ Agent とワークフローは組み合わせて使う：agent-teams は並列協業と依存スケジューリングを担当し、workflow はプロセスを固定化して繰り返し実行することを担当します。サブ Agent の数と依存階層には上限を設け、コストの暴走を避けましょう。
- 実行チェーンの要点は契約：Leader の分解段階で、インターフェース契約と受け入れ基準をサブタスクに書き込みましょう。サブ Agent が自分で合わせてくれることを期待してはいけません。
- ブラウザプラグインは権限を正しく認識する：dsh-browser はローカル Chrome を直接駆動し、ログイン状態と Cookie を保持します。ヘッドレス方式とは大きな違いがあります。ブラウザ拡張に関わる場合は、公式スクリプトまたは README に従ってインストールし、ソースコードと権限のレビューを優先しましょう。
- コンテキストは治理し、ため込まない：dsh-chat-import は移行を担当し、dsh-context は可視化と圧縮・トリミングを担当します。履歴をインポートしたらすぐに Token の推移を一度確認し、適時クリーンアップしましょう。
- 効果の4要素：モデル能力 + コンテキスト品質 + ツール能力 + タスク状態。どれか一つ欠けても足を引っ張られます。モデルのベンチマークスコアだけを見つめてはいけません。
- 長期的な管理姿勢：まず dsh-market をインストールし、その後は必要に応じて拡張し、更新管理はそれに任せましょう。dsh-find-plugin を使えば、セッション内で自然言語でプラグインを探せます。
- 本番の規律：latest / main を追うのではなく commit を固定する；アップグレードはロールバック可能にし、上流の変更を受動的に受け入れないこと。
- インストール時の4つの確認：ソースコードを確認する（特に Shell、ブラウザ、OAuth、API Key、ファイルシステム、ネットワーク権限を見る）、ライセンスを確認する、依存関係を確認する、バージョンまたは commit を固定する。
- 段階的に構築する：Harness のインストール、Profile の選択、基本プラグインのインストールから始め、順にツール、Agent、Workflow、Memory / Context を追加し、最終的に自分自身の Agent Runtime を形成しましょう。
一文で締めくくると、dsh のコアランタイムは能力をつなぐ役割を担い、Plugin は能力を提供する役割を担い、Profile は能力を組織する役割を担い、そしてあなた自身が自分の Agent を定義する役割を担います。このエコシステムがさらに発展していけば、それは単なる「AI プログラミングツール」にとどまらず、むしろ組み合わせ可能な Agent 実行環境へと近づいていくかもしれません。そして、まさにそこにこそ Everything is a Plugin を研究する最大の価値があるのです。