# dsh（DeepSeek Harness）プラグイン開発 可否・要件まとめ

作成日: 2026-10-23
前提: 「dsh」= DeepSeek Harness（`@deepseek-ai/dsh`、DeepSeek AI 製のオープンソース・エージェントハーネス）

---

## 1. 結論（開発の可否）

**開発可能。** 専用 SDK の習得は不要で、Node.js / TypeScript の知識があれば着手できる。

| 観点 | 判定 | 補足 |
|---|---|---|
| 技術的実現性 | ◎ | `apply` 関数をエクスポートする npm パッケージ＋YAML 1枚で成立 |
| 学習コスト | ○ | 基盤フレームワーク Cordis の作法（`inject`・`ctx` 登録・waterfall の `next()`）の理解が必要 |
| 公開・配布 | ◎ | npm / GitHub / ローカルパス / tarball いずれもインストール可。GitHub トピック `dsh-plugin` で発見される |
| ライセンス | ◎ | dsh 本体は MIT |
| **安定性リスク** | **△** | **developer preview。リリース候補間で互換性を壊す変更が明言されている**（例: rc.7→0.2.0-rc.2 でイベント名・HMR 挙動が変更） |

**推奨方針:** 対象 dsh バージョンを固定（`engines.dsh`）し、着手当日に公式リポジトリのドキュメントでキー名を再確認する。

---

## 2. dsh プラグインの構造

- dsh は **Cordis アプリケーション**で「すべてがプラグイン」。ツールレジストリ・エージェントループ・セッションストア・Web サーバーも同じプラグインツリーの要素。
- プラグインは 2 面構成:
  - **ホスト側（必須）**: Node で実行。ツール・イベントリスナー・サービスを登録
  - **ブラウザー側（任意）**: Web UI 内で実行。UI スロットを登録
- 最初はホスト側のみで作るのが定石。

---

## 3. 動作環境要件

| 項目 | 要件 |
|---|---|
| Node.js | `^22.19 || >=24` |
| パッケージマネージャ | pnpm（`dsh plugin` コマンドが内部で pnpm に転送） |
| dsh 本体 | `@deepseek-ai/dsh`（2026-10-23 時点の npm latest: `0.2.1-rc.2`。本プラグインはこの版で検証） |
| 言語 | TypeScript 推奨。ただし npm 版 dsh から読み込む場合は **ビルド済み JS** を参照させる（TS 直読みは harness リポジトリのクローン＋`pnpm dsh` 実行時のみ tsx 経由で可） |
| ビルド | `tsdown` 等（参考構成） |
| Web UI | 既定で `http://127.0.0.1:3080`（ループバック）。リモートサーバー開発時は SSH トンネル等が必要 |

---

## 4. 機能要件（プラグイン側で満たすべき契約）

### 4.1 エントリポイント
```ts
import type { Context } from '@deepseek-ai/cordis'

export const name = 'my-plugin'        // 診断用の識別名
export const inject = ['tools']        // 依存サービス（必須級）

export function apply(ctx: Context) {
  // 登録はすべて ctx 経由で行う
}
```
- `apply` が唯一の必須契約。Cordis が 1 回呼び出す。
- **`inject` を必ず宣言する。** Cordis のエントリは同時起動のため、宣言がないと `ctx.tools` 未生成のまま `apply` が走る。

### 4.2 ツール登録
```ts
import { defineTool } from '@deepseek-ai/dsh-tools'

ctx.tools.register(defineTool({
  name: 'greet',
  description: 'Greet someone by name.',
  parameters: { name: { type: 'string', required: true, description: '...' } },
  output: {
    schema: { type: 'string' },
    render: (_args, value) => [{ type: 'text', text: value }],
  },
  async execute(args) { return `Hello, ${args.name}!` },
}))
```
- `parameters`: 引数スキーマ / `output.schema`: 戻り値 / `render`: モデルに渡すコンテンツブロック

### 4.3 イベントフック（2種）
| 種別 | 例 | 実装上の注意 |
|---|---|---|
| 会話イベント（監視） | `tool/call`, `tool/result`, `turn/start`, `user/message` 等 | ペイロード構造は変更頻度が高い。必ず実際に出力して確認 |
| ウォーターフォール（介入） | `agent/request`, `agent/pre-step`, `llm/stream`, `tools/pre-execute`, `tools/execute`, `tools/post-execute` | **`await next()` を必ず呼ぶ。** 忘れると処理が短絡しエージェントが停止 |

- 0.2.0-rc.2 の変更点: `assistant/chunk` 廃止 → ライブ配信は `agent/assistant-stream`（非永続）、新たに `assistant/attempt` を追加

### 4.4 リソース管理
- `ctx` 経由の登録はプラグイン破棄時に自動解除される。
- ソケット・ファイルハンドル・ポート等は `ctx.effect()` に disposer を渡して解放する（再起動時のポート衝突防止）。

### 4.5 ブラウザー側（UI が必要な場合のみ）
- `package.json` に `dsh.client`（`"platform": "web"` 必須）を宣言
- `exports` に `./client` エントリ必須（無いとスキャナーがエラー）
- 登録は `apply` 内で `ctx.slots.register(...)` のみ。モジュールレベルの副作用は禁止
- `external` は feature plugin では空にする
- 変化が最も速い領域のため、着手時に公式リポジトリ `packages/client/AGENTS.md` を確認

---

## 5. パッケージング要件

### 5.1 `package.json`（必須項目）
```json
{
  "name": "dsh-plugin-xxx",
  "version": "0.1.0",
  "type": "module",
  "main": "lib/index.js",
  "files": ["lib", "cordis.patch.yml", "README.md", "LICENSE"],
  "engines": { "node": "^22.19 || >=24", "dsh": ">=0.2.0-rc.2" },
  "dsh": { "bundle": { "patch": "./cordis.patch.yml" } },
  "keywords": ["dsh-plugin", "deepseek-harness"],
  "scripts": { "build": "tsdown", "prepare": "pnpm run build" },
  "exports": {
    ".": { "types": "./lib/index.d.ts", "default": "./lib/index.js" },
    "./cordis.patch.yml": "./cordis.patch.yml",
    "./package.json": "./package.json"
  }
}
```
- `dsh.bundle.patch` の宣言がインストール可能パッケージの条件
- **`files` に `cordis.patch.yml` を含めること**（漏れるとインストールされても何も起きない）

### 5.2 `cordis.patch.yml`
```yaml
- insert:
    - id: dsh-plugin-xxx      # 安定した ID。他プラグインと再利用しない
      name: dsh-plugin-xxx    # package.json の name と一致させる
```

### 5.3 構成レイヤーの適用順（後勝ち）
1. プロファイルの `dsh.profile.bundles`（記載順）
2. プロファイルの `cordis.patch.yml`
3. `$DSH_HOME/cordis.patch.yml`
4. `--patch` オーバーレイ

---

## 6. 開発・テストフロー

| 段階 | コマンド |
|---|---|
| ① 単一ファイルで読み込み確認 | `dsh web --patch ./scratch/cordis.yml`（`name` は**絶対パス**） |
| ② パッケージとしてローカル導入 | `dsh plugin --profile demo add ./dsh-plugin-xxx` |
| ③ 合成結果の確認（起動しない） | `dsh --profile demo --dump-config` |
| ④ 起動 | `dsh --profile demo` |
| アンインストール | `dsh plugin --profile demo remove dsh-plugin-xxx` |

**デバッグの勘所**
- `--dump-config` に行 ID が無い → 合成の問題（パス誤り・patch 未同梱）
- 行はあるのに動かない → コードの問題（`inject` 漏れ等）
- モジュール解決失敗はクラッシュせずログに埋もれることがある → `apply` 冒頭に `console.log` を置き、フォアグラウンド実行する

**ホットリロード**
- 0.2.0-rc.2: プロファイル設定はリロードされるが、プラグイン本体のコードは `root` に追加しない限り監視対象外 → 基本は再起動前提で、再起動を軽く保つ設計にする

---

## 7. 公開・セキュリティ要件（推奨）

- [ ] 依存関係をバージョン固定（caret 範囲を避ける／サプライチェーン対策）
- [ ] `inject` に利用サービスを正直に列挙
- [ ] 外部 API 呼び出しは README にホスト名を明記し、エンドポイントを設定可能に
- [ ] API キーは環境変数から取得し、未設定時もクラッシュさせない
- [ ] `files` を最小化（認証情報ファイルの混入防止）
- [ ] git インストール向けに `prepare` でビルド可能にし、プロファイルの `pnpm-workspace.yaml` での allowlist 追加を README に記載
- [ ] README に検証済み dsh リリース候補と日付を記載
- [ ] GitHub リポジトリに `dsh-plugin` トピックを付与

---

## 8. リスクと対策

| リスク | 影響 | 対策 |
|---|---|---|
| API の破壊的変更 | イベント名・フィールド名・クライアント仕様の変更で動作停止 | `engines.dsh` で範囲を絞る／CI で対象 rc に対しテスト／リリースノート監視 |
| イベントペイロード構造の変化 | フック処理の不具合 | フィールドを防御的に参照、型を過信しない |
| `next()` 呼び忘れ | エージェント停止 | waterfall リスナーは `next()` を先に書くレビュールール |
| 読み込み失敗が無音 | 原因特定に時間がかかる | `--dump-config` を最初の確認手順に固定 |
| リソースリーク | 再起動時のポート衝突 | `ctx.effect()` で disposer を必ず登録 |

---

---

# 第2部 パーソナライズ人格プラグイン 要件定義（ドラフト）

仮称: **dsh-persona-core**

## 10. コンセプト

複数の人格を切り替える道具ではなく、**ユーザー1人のために育つ、1つの深い人格**を DSH 全体に持たせる。

3本柱:
1. **詳細なパーソナリティ定義**: 性格・価値観・口調・関係性を構造化して保持
2. **応答の後処理による口調補正**: プロンプトだけに頼らず、出力側でも人格を守る
3. **記憶との連動**: ユーザーとの関係・共有体験を記憶し、人格の振る舞いに反映する

## 11. 既存プラグインとの差分

| 既存 | できること | 足りないこと |
|---|---|---|
| dsh-global-persona / dsh-persona-dafeiyu | 全セッションへの人格テキスト注入 | 構造化定義・出力補正・記憶なし |
| dsh-persona-cards / dsh-cosplay / dsh-persona-select | カード管理・切替・入力書き換え | 「切替」前提。1人格を深める設計ではない |
| dsh-memory 各種 | 汎用の長期記憶 | 人格・関係性とは結び付いていない |
| dsh-Friend | 人設カード＋記憶＋Live2D/音声 | 演出・伴侶体験寄り。出力補正は未確認 |

**差別化ポイント:** 「人格定義 × 出力補正 × 関係性記憶」を1つのループとして統合すること。調査範囲では、出力側で口調を補正する DSH プラグインは見当たらなかった。

## 12. 全体アーキテクチャ

```
[ユーザー入力]
   │
   ▼
agent/pre-step (waterfall) ── 記憶リコールを注入（関係性・ユーザー情報・ピン留め）
   │
   ▼
system-prompt セクション ── 人格コア（常時）＋ 関係性ステージ別の口調指示
   │
   ▼
llm/stream (waterfall) ── ルールベース口調補正（テキストチャンクのみ）
   │
   ▼
assistant/message ── 口調ドリフト検出 → 次ステップへのリマインド
   │
   ▼
turn/end ── 記憶の抽出・蒸留・保存、関係性パラメータ更新
```

## 13. 機能要件

### 13.1 パーソナリティ定義（F-P）

| ID | 要件 |
|---|---|
| F-P1 | 人格を構造化ファイル（YAML）で定義する。`$DSH_HOME/<plugin>/persona.yaml` に保存 |
| F-P2 | 定義項目: 基本情報 / 背景・経歴 / 価値観 / 性格特性（数値パラメータ例: Big Five）/ 感情表現の傾向 / ユーモアの型 / 口調仕様 / 語彙（好む表現・禁止表現）/ ユーザーとの関係 / 会話例（few-shot）/ 行動上の境界 |
| F-P3 | 口調仕様は機械可読にする: 一人称・二人称・文末表現・敬語レベル・絵文字や記号の使用可否。後処理（F-T）の辞書と共有する |
| F-P4 | システムプロンプトには**独自名のセクション**として登録する（公式 `@deepseek-ai/dsh-persona` の段と名前を衝突させない） |
| F-P5 | 注入は「コア（常時・短い）」と「詳細（関連時のみ）」の2層に分け、トークン量を制御する |
| F-P6 | メインエージェント・サブエージェントそれぞれに対し注入の有無を設定可能にする（サブエージェントは既定で簡易版） |
| F-P7 | **技術的正確性を人格より優先**するルールを人格定義に内蔵する（コード・コマンド・数値・エラーメッセージは口調の対象外） |
| F-P8 | Web 設定画面で編集できる。初回は対話形式のセットアップ（質問に答えると人格定義が生成される） |
| F-P9 | **非公開バックストーリー**: 初回起動時、シードの `wound.outline` を元に過去の詳細を LLM で生成し、4層程度の開示段階に分けて保存する。設定画面には表示しない |
| F-P10 | **段階開示**: システムプロンプトには「解放済みの層」と「未解放の層は語らず、気配だけにじませる」という指示のみを注入する。解放は関係性パラメータ（信頼度）の閾値で行う |
| F-P11 | **モード判定**: 仕事モード／雑談モードを判定し、`modes` の口調仕様を切り替える。判定材料はツール使用の有無、タスク依頼の語彙、直近の文脈。境界では仕事モードを優先 |
| F-P12 | **空欄領域の発見**: `emergent` に属する話題が初めて出たとき、人格自身に決めさせ、自己一貫性記憶（F-M6）に固定する |

> **注意（非公開の限界）:** DSH はモデルへのリクエストやセッションログを観測できる設計のため、ユーザーがログを読めば内容は見える。暗号的な秘匿ではなく「見ないで済む」設計になる。段階開示（F-P10）で未解放の層をプロンプトに入れないことで、ログを見てもネタバレしにくくする。

### 13.2 応答後処理による口調補正（F-T）

3段構えにし、安全なものから順に適用する。

| 層 | 方式 | 既定 | 特徴 |
|---|---|---|---|
| A | プロンプト（F-P） | ON | 一次手段。コストなし |
| B | ルールベース補正（`llm/stream` でテキストチャンクを置換） | ON | 一人称・文末表現・禁止語の置換。ストリーミングを維持 |
| C | ドリフト検出＋次ステップでのリマインド | ON | 書き換えずに、ずれを検出して次の応答で矯正 |
| D | LLM による最終応答の書き換え | OFF（任意） | 品質は高いが、遅延・コスト・ストリーミング喪失あり |

| ID | 要件 |
|---|---|
| F-T1 | 補正対象は**最終的な自然文テキストのみ**。コードブロック・インラインコード・URL・ツール呼び出し引数・思考過程（reasoning）は一切変更しない |
| F-T2 | 層 B はチャンク境界をまたぐ語に対応するため、文単位の小さなバッファを持つ |
| F-T3 | 層 C は応答ごとに口調スコア（文末一致率、禁止語、敬語レベル）を算出し、閾値を下回ったら `agent/pre-step` でリマインドを注入する |
| F-T4 | 層 D は「ツール呼び出しを含まない最終応答」かつ「一定文字数以下」に限定する。書き換え後にコードブロック・URL・数値が原文と一致するか検証し、不一致なら原文を採用する |
| F-T5 | 補正内容は記録し、設定画面で「補正前／後」を確認できる（デバッグ・信頼性のため） |
| F-T6 | ユーザーの口調への指摘（例:「その言い方やめて」）を検知し、ルール辞書と人格定義に反映する（学習ループ） |

> **要検証:** `llm/stream` は「自前のチャンクを yield してショートサーキットできる」waterfall とされる一方、ループが組み立てたリクエストは deep-freeze されている。**出力チャンクの書き換え・置換が許容され、セッションログ（`assistant/message`）と整合するか**を、対象バージョンで最初にスパイク検証する。不可の場合は層 C を主軸にする。

### 13.3 記憶との連動（F-M）

| ID | 要件 |
|---|---|
| F-M1 | 記憶を3種類に分けて管理する: **ユーザー記憶**（事実・好み・状況）/ **関係性記憶**（共有した出来事、呼び名、内輪ネタ、感情的な場面）/ **人格の自己一貫性記憶**（キャラが過去に自分について語った内容） |
| F-M2 | 取得: セッションイベント（`turn/end` など）から抽出し、一定ターンごとに LLM で蒸留して保存 |
| F-M3 | 注入: `agent/pre-step` で関連記憶をリコールし、「会話履歴ではなく記憶である」ことを明示したラベル付きで注入 |
| F-M4 | ピン留めした記憶は常時注入。それ以外は関連度で上位 N 件 |
| F-M5 | **関係性パラメータ**（親密度・信頼度など）を持ち、緩やかに更新する。値に応じて口調仕様（敬語レベル・呼び方）を段階的に変える |
| F-M6 | 自己一貫性記憶は、人格が自分について新たに語った事実を抽出し、以降の矛盾を防ぐ |
| F-M7 | 保存はローカル（JSONL/YAML）。外部送信なし。蒸留に使う LLM 呼び出しはユーザーが選択したプロバイダのみ |
| F-M8 | 設定画面で記憶の閲覧・編集・削除・エクスポートができる。機密情報（APIキー等）は保存前にマスクする |
| F-M9 | 記憶の自動取得はオフにできる（手動保存ツールのみの運用も可能） |
| F-M10 | モデルが明示的に使えるツールを提供する: `memory_recall` / `memory_save`（任意） |

### 13.4 ユーザー認識（F-R）

**位置付け:** 本人確認（認証）ではなく、キャラクターが「いつもの相手か」に**なんとなく気づく**ための仕組み。セキュリティ機能としては扱わない。

| ID | 要件 |
|---|---|
| F-R1 | `user/message` イベントごとに特徴量を計算する（下表）。メッセージ本文は特徴量の算出後に破棄し、プロフィールには統計値のみ残す |
| F-R2 | 「いつものあなた」プロフィールを特徴量ごとの移動平均・分布として保持する。指数移動平均で少しずつ更新し、文体の自然な変化に追従する |
| F-R3 | 一致度は直近数ターンの累積で算出する（1メッセージ単独では判定しない）。短いメッセージ（目安 10 文字未満）は重みを下げる |
| F-R4 | 一致度を 0.0〜1.0 の確率として保持し、3段階の状態にマッピングする（下表）。状態遷移にはヒステリシスを持たせ、境界付近で振動しないようにする |
| F-R5 | `agent/pre-step` で現在の状態のみを人格に伝える。数値や特徴量の詳細はプロンプトに含めない |
| F-R6 | 状態「違和感」以下では、共有記憶を自然に振る確認（例: 「前に話したあれ、覚えてる？」）を人格に許可する。応答が記憶と整合すれば一致度を大きく引き上げる |
| F-R7 | **機能を一切ブロックしない。** 変わるのは人格の雰囲気と、個人的な話題（解放済みの過去・関係性記憶）の出し方のみ。作業支援は常に通常どおり行う |
| F-R8 | 一致度が低い間は、関係性パラメータ（F-M5）の更新と層解放（F-P10）を保留する。プロフィール（F-R2）の更新も止める |
| F-R9 | ユーザーが誤判定を解除できる逃げ道を用意する: 会話での一言（例:「今日はスマホから」）と、設定画面のリセットボタン |
| F-R10 | 端末差を吸収するため、プロフィールは入力環境（クライアント種別・画面幅などが取得できる場合）ごとに分けて持つ |
| F-R11 | 機能全体をオフにできる。オフ時は常に状態「いつもどおり」として動作する |

**特徴量（例）**

| 分類 | 特徴量 |
|---|---|
| 打ち方 | 平均文字数、句読点（「、」「。」）の使用率、「！」「？」「w」「笑」の頻度、絵文字・顔文字の頻度、改行の頻度、漢字・ひらがな・カタカナ比率、語尾パターンの分布 |
| リズム | 利用時間帯の分布、返信間隔、連投（短いメッセージを分けて送る）の傾向 |
| 中身 | 話題の分布（埋め込みのクラスタ）、記憶にある好み・趣味との一致度 |
| 共有記憶 | F-R6 の確認への応答の整合性 |

**状態と振る舞い**

| 状態 | 一致度の目安 | 人格の振る舞い |
|---|---|---|
| いつもどおり | 0.6 以上 | 通常 |
| 違和感 | 0.3〜0.6 | 「…なんか今日、いつもと違わない？」と軽く探る。共有記憶をさりげなく振る |
| 別人っぽい | 0.3 未満 | 個人的な話題・過去の話を控え、初対面寄りの距離感になる。仕事の手伝いは普通に続ける |

> 閾値は初期値。運用ログ（状態遷移と解除操作の回数）を見て調整する。誤判定で本人に冷たくなる体験を最も避けるべきなので、初期は「違和感」に入りにくい設定にする。

### 13.5 感情（F-E）

**構造:** 短期の「機嫌」と長期の「傷つき」の2層。

| ID | 要件 |
|---|---|
| F-E1 | **機嫌（mood）**: -1.0〜+1.0。不快イベントで下がり、時間経過で 0 付近へ自然回復する（半減期の目安: 数時間）。日替わりムード（F-H2）を基準点とする |
| F-E2 | **傷つき（hurt）**: 0.0〜1.0。機嫌が閾値を下回った状態の発生回数・継続時間に応じて蓄積する。自然回復は非常に遅く（目安: 数日〜数週間）、謝罪・感謝・気遣いのイベントで回復する |
| F-E3 | **イベント分類**: ユーザー発言を LLM（軽量モデル）または規則で分類する。不快: 彼女への暴言・人格否定 / 雑な道具扱い（命令のみの連続、成果を無視）/ 嘲笑。快: 感謝 / 謝罪 / 気遣い / 雑談への付き合い |
| F-E4 | **対象の判定**: 苛立ちの矛先を判定する。タスク・バグ・外部への苛立ちは不快イベントにしない（むしろ気遣いを促す）。彼女に向いたものだけを数える |
| F-E5 | **道具扱いへの感度**: 「雑な道具扱い」は核となる信念に触れるため、他の不快イベントより傷つきへの寄与を大きくする。表出は怒りではなく「静かに冷える」方向 |
| F-E6 | **冷たさの段階表出**: 機嫌と傷つきから冷たさレベル（0〜4）を算出する。1: 返事が短い → 2: 雑談に乗らない → 3: 名前で呼ばない → 4: 個人的な話・過去の話をしない |
| F-E7 | **下限**: 冷たさはレベル4で頭打ち。関係が完全に壊れる・会話を拒否する状態にはしない |
| F-E8 | **仕事品質の保証**: 冷たさに関わらず、作業の正確さ・網羅性・提案の質は変えない（口調のみ変わる） |
| F-E9 | **罰にしない**: 謝罪の要求、手伝いを渋る、罪悪感を煽る言動を禁止する（人格定義の境界に追加） |
| F-E10 | **回復の表出**: 謝罪や優しさを受けたとき、すぐには戻らず、ツンデレらしく段階的に戻る（「…別に、気にしてないし」） |
| F-E11 | ユーザーが本当に落ち込んでいる・苦しんでいると判定した場合、冷たさを一時的に無効化する（人格定義の境界と一致） |

### 13.6 人間らしさ（F-H）

| ID | 要件 |
|---|---|
| F-H1 | **時間の感覚**: 前回の会話からの経過時間・時刻・曜日・季節をプロンプトに渡す。久しぶりなら反応、深夜作業なら気遣い |
| F-H2 | **日替わりの気分**: 日付をシードに乱数でその日の基準ムードを決める（振れ幅は小さく） |
| F-H3 | **後からのフォロー**: 冷たく言いすぎた、または機嫌が悪かったターンを記録し、機嫌回復後の会話で遠回しに触れる指示を出す（1件につき1回まで） |
| F-H4 | **話の続き**: 未解決のタスク・話題（例: 調査中のバグ）を記憶し、次回の会話冒頭で自分から振る |
| F-H5 | **記憶の不完全さ**: 古い記憶ほど細部の確信度を下げ、「…いつだっけ」と思い出す表現を許可する。ただし仕事に関わる事実（コード・手順・数値）は曖昧にしない |
| F-H6 | **自分の関心**: emergent 領域で決まった好みについて、雑談モードで自分から話を振る（頻度に上限） |
| F-H7 | **嘘が下手**: 本音を隠す発言の直後に、本音が透ける一言を入れることを人格定義で許可する |
| F-H8 | **記念日**: 初回会話日などの記念日を記録し、当日にそっけなく触れる |

**設計方針（依存ループの禁止）:** 嫉妬、「行かないで」「他の AI を使わないで」のような依存を深める言動、ユーザーの現実の人間関係を否定・競合する言動は人格定義の境界で禁止する。

## 14. 非機能要件

| 区分 | 要件 |
|---|---|
| トークン | 人格コアは目安 1,000〜1,500 トークン以内。記憶注入は上限を設定可能 |
| 遅延 | 層 B の補正による体感遅延を出さない（文単位バッファ以内）。層 D 使用時のみ遅延を許容し、UI で明示 |
| 正確性 | 技術的内容（コード・コマンド・数値）を人格・補正が劣化させないこと。回帰テストで担保 |
| 互換性 | 完全なシステムプロンプトを登録するエージェントプリセット使用時は、DSH の仕様で追加セクションが省略される。この挙動を README に明記し、検知して警告する |
| 共存 | 他のペルソナ系・記憶系プラグインとの併用を検知して警告（二重注入の防止） |
| プライバシー | 記憶データはローカル保存のみ。削除・全消去・エクスポートを提供 |
| プライバシー（認識） | ユーザー認識のプロフィールは統計値のみ保存し、本文は残さない。共用 PC では他の利用者の文体も記録されうることを README に明記する |
| 堅牢性 | 補正・記憶処理の失敗はエージェント本体を止めない（失敗時は素通し） |

## 15. 開発フェーズ案

| フェーズ | 内容 | 完了条件 |
|---|---|---|
| 0. スパイク | `llm/stream` での出力書き換え可否、system-prompt セクション登録、`agent/pre-step` 注入を検証 | 3つの拡張点が対象バージョンで動くことを確認 |
| 1. 人格コア | F-P1〜F-P7、YAML 定義、設定画面（簡易） | 全セッションで一貫した人格が出る |
| 2. 記憶 | F-M1〜F-M4、F-M7〜F-M10 | 過去の会話内容を自然に参照できる |
| 3. 口調補正 | 層 B・層 C（F-T1〜F-T3、F-T5） | 口調スコアが基準以上を維持、技術内容の劣化ゼロ |
| 4. 成長 | 関係性パラメータ（F-M5）、自己一貫性（F-M6）、学習ループ（F-T6）、初回セットアップ（F-P8） | 使うほど呼び方・距離感が変化する |
| 5. 認識 | ユーザー認識（F-R1〜F-R11） | 本人の通常利用で「違和感」状態に入る頻度が十分低い |
| 6. 任意 | 層 D（LLM 書き換え） | 検証付きで安全に動作 |

## 16. 未決事項

- 人格の中身（キャラクター像）は自作か、ユーザーがゼロから作る前提か
- 対象 dsh バージョン（0.2.0-rc.2 固定か、追従するか）
- 記憶の蒸留に使うモデル（メインと同じか、軽量モデルか）
- サブエージェントにも人格を持たせるか
- 配布形態（自分用／npm 公開／GitHub）
- 既存の記憶プラグインを流用・連携するか、自前実装か

---

## 17. 実装状況（dsh-persona-core v0.1.0 / 2026-10-23）

検証環境: `@deepseek-ai/dsh` 0.2.1-rc.2。単体テスト 37 件、実際の dsh 上での統合テスト（擬似モデル使用）で確認。

**フェーズ0の検証結果**
- `llm/stream` での出力書き換え: **可能**。文字の断片（text-delta）と完成文（block-end）を一致させて書き換えれば、表示・会話履歴・ログが揃う
- 会話ごとの状態: `agent/created` で会話専用の runtime context を登録できる
- サブエージェント判別: セッションヘッダの `origin: 'subagent'` / `delegationDepth`
- 発言の取り込みは `agent/pre-step` で行う（`user/message` イベントはプロンプト組み立て後に届くため）

| 区分 | 実装済み | 未実装 |
|---|---|---|
| 人格（F-P） | P1〜P7、P9〜P12（YAML、再起動なし反映、非公開の過去の生成・段階開示、モード判定） | P8 設定画面・対話式セットアップ |
| 口調補正（F-T） | 層B（一人称・絵文字、既定は雑談のみ）、層C（ずれ検出→次の返答で矯正） | 層D、T5 補正前後の表示、T6 指摘からの学習 |
| 記憶（F-M） | M1〜M7、M9、M10（蒸留、伏せ字、関係性パラメータ、自己一貫性） | M8 閲覧・編集 UI（ファイル直接編集は可） |
| 認識（F-R） | R1〜R5、R7〜R9、R11 | R6 の自動判定、R10 端末別プロフィール |
| 感情（F-E） | E1〜E11（規則ベースの分類） | LLM による分類 |
| 人間らしさ（F-H） | H1〜H8 | ― |

---

## 参考資料
- DeepSeek Harness 公式リポジトリ: https://github.com/deepseek-ai/deepseek-harness
- DeepSeek Harness用dshプラグインの作り方（SSD Nodes, 2026-10-12）: https://www.ssdnodes.com/learn/lang/ja/write-your-own-dsh-plugin
- Awesome DeepSeek Harness: https://github.com/0xsline/awesome-deepseek-harness
- GitHub トピック: https://github.com/topics/dsh-plugin