dsh プラグインの作り方：DeepSeek Harness プラグイン開発入門

DeepSeek Harness（dsh）プラグインの作り方を解説。Cordis のサービスとイベント、能力の継ぎ目、品質ゲート、自分のプラグインをディレクトリに掲載する方法まで。

最終更新: 2026-08-13

dsh プラグインとは実際には何か

DeepSeek Harness のプラグインは Cordis プラグイン です。Cordis は内部にあるメタフレームワークで、ロード、アンロード、依存解決だけを担います。ハーネスの具体的なコンポーネント ―― ツール、ストレージ、ポリシー、エージェントループ、UI パネル ―― はすべて Cordis プラグインで、プラグイン同士は サービスとイベント で協調します。

メンタルモデルの転換はここです。プラグインは付け足しではありません。エージェントの 任意の 部分を置き換えも拡張もできます。

モデルが呼べるツールを追加する（タイトル生成器、データベースコネクター…）
システムプロンプトやエージェントループ全体を交換する
ツール実行をインターセプトして承認・ログ・書き換えする
新しい UI パネル、ステータスバー、テーマを登録する
サンドボックスバックエンドやモデルプロバイダーを追加する

知っておくべき公式アンカー：

npm パッケージ：@deepseek-ai/dsh
CLI コマンド：dsh（インストール：npm install -g @deepseek-ai/dsh、起動：dsh --profile web）
コミュニティプラグイン用 GitHub トピック：dsh-plugin
フレームワーク：Cordis

能力の継ぎ目：service・provider・consumer

すべての能力（コマンド実行、ファイル読み取り、ネットワークアクセス、モデル呼び出し、サンドボックス隔離）は 3 つの独立した役割に分割されています。

Service ―― インターフェース定義
Provider ―― 具体的な実装
Consumer ―― その能力を使うコード

3 つは疎結合なので、背後にどのプロバイダーがいてもモデルには常に安定したインターフェースが見えます。検索エンジンを交換したい？別の provider を登録するだけです。consumer とモデルからは何も変わって見えません。コミュニティプラグインがハーネスの大部分を交換できるのは、まさにこの仕組みのおかげです。

プラグインツリー

実行中の dsh は、積層設定から組み立てられるプラグインのツリーです。bundles（公式セット）、profiles（自分の名前つき構成）、patches（自分のオーバーライド。単一プラグインエントリーまで指定可能）。上位レイヤーが勝ちます。プラグインが取り除かれたら登録したものはすべて取り消されます。登録は可逆な副作用でなければなりません。

最小のプラグイン（概念的に）

すべてのプラグインは関数（またはライフサイクルフックを持つオブジェクト）で、Cordis の コンテキスト を受け取り、提供するものと消費するものを宣言します。骨格はこのような形です。

import { Context, Service } from '@cordisjs/core';

export const name = 'my-plugin';

// 1. A service the plugin provides
export class Greeting extends Service {
  constructor(ctx: Context) {
    super(ctx, 'greeting');
  }

  hello() {
    return 'hello from my-plugin';
  }
}

// 2. The plugin itself
export function apply(ctx: Context) {
  ctx.provide('greeting', new Greeting(ctx));

  // 3. React to an event — e.g. run when the agent starts
  ctx.on('agent/start', () => {
    ctx.logger.info('my-plugin loaded');
  });
}

正確な API は速いペースで変化しています（プロジェクトは v0.1 で急速に反復中）。スニペットは契約ではなく形として扱い、最新の慣例は必ず公式ドキュメントと plugin-template リポジトリで確認してください。

リポジトリが強制するエンジニアリング慣例

公式リポジトリの自動ゲートが規定しているルールは、自分のプラグインにもコピーする価値があります。

登録は可逆でなければならない ―― アンインストールで残骸を残さない
設定エラーはロード時に大きく失敗させる ―― 黙ってスキップしない
境界を越える識別子には branded 型を使う ―― レイヤー間に生の文字列を漏らさない
デプロイごとに変わるパラメーターは設定に置く ―― ハードコードしない

品質ゲート：ソースファイルごとの単体テストカバレッジ 100%、API キーなしで走るスナップショットリプレイテスト、実 API の E2E テスト、ファイル横断のコードクローン検出、ドキュメントが古いと CI を止める docs-sync チェック。

プラグインコードが差し込まれる場所

作るものによって継ぎ目は変わります。

ツール ―― モデルが呼べるツールを登録。組み込みツールと同じパイプライン（承認、ガード、ログ）を通ります
エージェントイベント ―― turn/start、step/start、ツール実行、モデルリクエストの前後のフック
UI ―― Web UI 自体が第 2 のプラグインツリー。ページはマウントポイント（サイドバー、チャットエリア、入力欄、設定）を宣言し、プラグインがそこにコンポーネントを登録します
ストレージ / セッション ―― セッションとログの永続化方法を置き換え
サンドボックス / モデル ―― 独自のバックエンドやモデルアダプターを提供（任意の OpenAI 互換エンドポイントが使えます）

公開して掲載されるまで

プラグインを公開 GitHub リポジトリに push します。
一行の説明、インストール手順、（できれば）必要なアクセス範囲を書いた README を用意します。
リポジトリに dsh-plugin トピックを付けます。他のツールやディレクトリが発見に使う公式 GitHub マーカーです。
私たちの awesome リスト ―― このディレクトリの単一の正本 ―― に PR を出します。
- cccakeee/awesome-dsh-plugins ―― 該当するカテゴリ見出しの下に一行追加します（英語または中国語）。
任意で npm レジストリ風のインデックスにも載せ、dsh ツール群から見つけられるようにします。

マージされれば、このディレクトリが次回の同期であなたのプラグインを拾います（仕組みはエコシステムガイドを参照）。

最後の警告

プラグインはエージェントの権限で動くコードです。他人のプラグインをインストールする前に、ソースを読み、ライセンスと権限を確認し、隔離されたワークスペースで試してください。自分のプラグインも、何を読み、何を書き、ネットワークに何を送るかについて、同じくらい正直であるべきです。

次に読む

信頼できるプラグインのインストール方法 ―― インストール行の向こう側
dsh プラグインとは？ ―― あなたが作るもののユーザー側の見え方
プロファイル・パッチ・プリセット ―― あなたのプラグインがツリーのどこに載るか
サンドボックス・承認・シークレット ―― あなたのプラグインが差し込まれる安全モデル
プラグインを投稿 ―― 掲載チェックリストの完全版