DeepSeek Harness 全景解説：Agent = Model + Harness と「すべてが Plugin」設計

2026年になってもまだ「結局どのモデルがコードを書くのが強いのか」で悩んでいるなら、あなたはこの年で最も重要なエンジニアリングの転換点をすでに見逃しているかもしれません。DeepSeek AI は2026年8月に DeepSeek Harness（コマンドライン名 dsh）を正式にオープンソース化し、提示した公式は Agent = Model + Harness、スローガンは Everything is a Plugin.（すべてはプラグイン）です。これはまた「いくつかの agent をラップしたライブラリ」ではなく、モデルの実行環境を中心に構築されたプラグイン型インフラストラクチャの一式です。モデル、ツール、スキル、セッション、サンドボックス、ストレージ、ループ、スケジューリング、UI のすべてがプラグインによって組み合わされ、設定レイヤーで置き換え可能であり、ソースコードを変更する必要はありません。本記事は前後編に分かれます。前編ではまず「なぜ Harness が必要なのか」「dsh とは何か」「すべてはプラグインとは具体的にどう実現するのか」を徹底的に解説します。Cordis カーネル、無特権カーネル、Profile + バンドル + patch の四層の重ね合わせ順序、4つの実行モードを含み、そのまま貼り付けて実行できるコマンドとコードも示します。後編ではプラグイン開発、イベント駆動の拡張ポイント、実践的なワークフローに入ります。

Agent = Model + Harness：なぜ2026年のボトルネックはモデルの知能から実行環境へ移ったのか

まず公式のあの言葉の完全な表現を見てみましょう：モデルは Agent の魂であり、Harness は Agent に環境を理解し、ツールを使い、現実のシナリオで継続的に作業する能力を与える。この言葉は責任の切り分けを非常に明確にしています。モデルは「考える」ことを担当し、次に何をすべきか、どんなコードを書くか、どのツールを呼ぶかを決めます。Harness は「生きる」ことを担当し、モデルの意図をファイルシステム、ターミナル、検索サービス、サブ Agent への実際の操作に翻訳し、その操作結果をモデルが理解できるコンテキストに再構成して、次のラウンドへ送り返します。魂がどんなに賢くても、誰かが手足、記憶、感覚を与えなければ、実際のプロジェクトで一度の git status すら実行できません。

これこそがこの公式の深い意味です：Agent はモデルではない。Agent はモデルにハーネス層を加えたものである。2023年から2025年にかけてモデル能力が急速に横並びになった後、業界の多くのチームが、同じモデルでも実行環境を変えると出力品質が大きく差が出ることに気づきました。素材では非常に説得力のある2つの傍証が示されています。1つは OpenAI チームの100万行コード実験の記録で、5か月間に生成されたすべてのコードは Agent によって完成され、エンジニアは1行もコードを書かなかったというもの。もう1つは LangChain の対照実験で、外部のハーネス環境（ドキュメント構造、検証ループ、トレーシングシステム）だけを最適化したところ、コーディング Agent の Terminal Bench 2.0 でのスコアが 52.8% から 66.5% に向上し、世界ランキングが30位から5位へ躍進した一方で、基盤モデルのパラメータは1つも変えていないというものです。

この2つを合わせて考えると、結論は非常に明白です：ボトルネックはモデルの知能ではなく、インフラストラクチャにある。モデルがどんなに強くても、コンテキストの与え方が乱雑で、ツール呼び出しに検証ループがなく、エラーに可観測なトレーシングがなければ、Agent は「賢く見えるが使うと失敗する」ブラックボックスです。逆に、普通のモデルでも、制約が明確で、フィードバックが迅速で、状態が追跡可能な環境に置かれれば、エンジニアリングの全チェーンを安定して走り切ることができます。これが、2026年の議論の焦点が「モデルランキング」から「Harness をどう作るか」へ移った理由です。

dsh の公式な位置づけもこの点を裏付けている：それはモデル自体を最適化するのではなく、モデルが動作する環境を最適化する。この言葉はマーケティング文句のように見えるかもしれないが、コードレベルに落とし込むと非常に具体的である——モデルの動作に必要な制約、フィードバック、ツール、記憶、可観測性をすべて組み合わせ可能なプラグイン基盤にし、各チームが自分たちのやり方で AI を操縦できるようにし、ベンダーによって固定機能のブラックボックスに囲い込まれないようにする。入門読者にとって、この層を理解する上で最も重要なマインドセットの転換は：あなたはもはや「モデルを呼び出している」のではなく、「実行環境を構成している」のである。気にするべきなのは、prompt の何文字目をどう変えるかではなく、この環境にどのような能力があり、それらがどう協調し、エラー時に何が起きたかをどうやって見るかである。

また、モデルではなく実行環境であるからこそ、dsh は自然にいくつかのエンジニアリング特性を備えている：能力はプラグイン可能、状態は再生可能、構成は監査可能、モデルは交換可能。これらの特性は以下の各節で繰り返し現れる。なぜならそれらは散発的な機能ではなく、同じ設計判断の異なる側面だからである。「Agent = Model + Harness」を理解すれば、後続の「なぜプラグイン化なのか」「なぜ無特権カーネルなのか」「なぜ dump-config なのか」という問いはすべて容易に解決する。

Prompt から Context、そして Harness Engineering へ：三度のパラダイムシフトにおける最適化対象の対照

Harness がなぜ重要かを真に理解するには、まず私たちがどのようにしてここまで来たのかをはっきりと見る必要がある。この技術は三度のパラダイムシフトを経ており、そのたびに共通しているのは：前世代の方法は間違っていたのではなく、ただ不十分になっただけである。

第一は プロンプトエンジニアリング（Prompt Engineering）で、おおよそ 2023 年から 2024 年である。その最適化対象は入力の言い回し——prompt をどう表現し、どの形式を使い、例をいくつ入れるかであった。解決した問題は単一の会話の品質であり、対話モードは基本的に一問一答であった。その時期、皆が競っていたのは誰がより「物事を明確に言えるか」であった。

第二は コンテキストエンジニアリング（Context Engineering）で、およそ 2025 年である。その最適化対象は情報入力——文書、コードスニペット、履歴会話をどのようにコンテキストに組み込むかへと変わった。解決した問題は知識の境界とハルシネーションであり、対話モードは「情報注入 → 生成」であった。この時、皆が競っていたのは誰がより AI に情報を与えられるかであった。すぐに、情報を与えるだけでは不十分だと気づいた：知識の境界が明確でも、Agent はマルチターンのツール呼び出しで迷子になるのである。

第三は ハーネスエンジニアリング（Harness Engineering）で、2026 年から始まる。その最適化対象は実行環境——制約、フィードバックループ、制御システムである。解決する問題は Agent の信頼性と持続可能性であり、対話モードは「人間が舵を取り、Agent が実行する」である。この時、競われるのはもはや言い回しや餌やりではなく、誰がモデルを安定し、可観測で、交換可能な実行環境に置けるかである。

この表で最も重要な読み方はこれです：三つのパラダイムは置き換えの関係ではなく、積み重ねの関係にあります。ハーネスエンジニアリングは、もう prompt を書くなと言っているのではなく、prompt とコンテキストだけではもはや不十分であり、実行環境という層に誰かが責任を持つ必要がある、と言っているのです。そして dsh が対応するのはまさにこの「実行環境」の層です——それは制約、フィードバック、可観測性、交換可能性をすべて実装に落とし込んだオープンソース実装であり、ハーネスエンジニアリングを方法論にとどめず、すぐに使えるインフラにします。

入門読者にとって、ここには非常に実用的な判断基準があります：もし「prompt の言い回しを調整する」ことに費やす時間が、「ツールが何を返すか、エラーをどうフィードバックするか、状態をどう保存するかを設計する」ことよりもはるかに多いなら、あなたはまだ前世代のパラダイムの中で堂々巡りしているかもしれません。Agent の信頼性は、ある魔法のようなプロンプトから来るのではなく、環境の中の制約とフィードバックループから来ます——権限ポリシーが越権操作を遮り、検証ループが失敗情報をモデルに戻し、トレーシングシステムが各ステップを振り返り可能にします。これらこそまさに Harness の責務です。

dsh とは何か：MIT ライセンス、TypeScript で記述、2026 年 8 月にオープンソース化された開発者プレビュー版

まずプロジェクトの身元情報をはっきりさせておき、後の議論で概念がずれないようにしましょう。

• 正式名称と別名：DeepSeek Harness、コマンドラインのエントリポイントは dsh、npm パッケージ名は @deepseek-ai/dsh。
• 開発者：DeepSeek AI。
• オープンソース化の時期：2026 年 8 月に正式にオープンソース化。
• ライセンス：MIT ライセンス——これは自由に使用、改変、配布でき、商用利用も含むことを意味します。
• 言語：TypeScript で記述。
• 段階：現在は開発者プレビュー段階にあり、将来的に互換性を破壊する変更があることを公式が明確に警告しています。
• 位置づけ：Agent Harness（エージェントフレームワーク）であり、モデル自体を最適化するのではなく、モデルが動作する環境を最適化します。

ここで特に下線を引くべきは最後の二点です。多くの初学者は「オープンソース化された」という言葉を見ると、それを安定版だと勝手に思い込み、そのまま本番環境に投入し、その後あるアップグレードで設定が合わなくなったり、プラグインがエラーを出したりします——これは dsh のバグではなく、プレビュー段階での想定された挙動です。公式の表現は明確です：将来的に互換性を破壊する変更があります。この一文のエンジニアリング上の意味は次のとおりです：

1. 設定ファイルの構造、プラグイン API、イベント名はすべて変わりうるので、素早く反復できない本番システムにそれらをハードコードしないこと。
2. アップグレード前に変更履歴を確認する習慣をつけ、アップグレード前に dsh --profile web --dump-config で設定ツリーの差分を比較すること。
3. 学習や社内試験のためのツールとしては非常に適していますが、外部に約束する長期的なインフラとしては、移行コストを見込んでおく必要があります。
4. MIT ライセンスは、たとえ上流で破壊的変更が起きても、理論上は fork して自前で保守できることを意味しますが、その代償は上流の更新を失うことです。

また、dsh は TypeScript で書かれていますが、これはTypeScript ができなければ使えないという意味ではありません。素材に示された基礎能力の要件は非常に控えめです：コマンドラインの基本操作（必須、ターミナルを使え、環境変数を設定できる）、Node.js の基礎（必須、npx / pnpm で dsh をインストールして起動できる）、基本的な API の概念（理解しておけばよい、API Key とは何かを知っていれば十分）、プラグインと設定ファイルの概念（理解しておけばよい、上級章で使う）、Git の基礎（任意）。オペレーティングシステムについては、Linux、macOS、または Windows に Node.js が入っていれば動作します。AI 研究の背景や深い機械学習の知識は要求されません。

まず界面を動かして一目見たいだけであれば、コマンド一行で済みます：

# Node.js をインストール後、コマンド一行で Web UI を起動（デフォルト http://127.0.0.1:3080）
npx @deepseek-ai/dsh web

ソースからインストールし、ついでにプロジェクトがどんなものか見てみたい場合は、以下の手順を使えます（pnpm が必要）：

# ソースからインストールして起動
git clone https://github.com/deepseek-ai/deepseek-harness.git
cd deepseek-harness
pnpm install
pnpm run build
pnpm dsh web

Web UI の入門はわずか三步です：第一步、設定 → モデルを開き、DeepSeek API キーを入力して保存すると、モデルルーティングが即座に利用可能になり、再起動は不要です；第二步、ワークスペースを選択し、dsh を起動したときのプロジェクトディレクトリを追加して選択します（注意：選択するまでセッション入力欄は使用できません。これは初心者が最もよく遭遇する「なぜ文字が打てないのか」の原因です）；第三步、タスクを一つ送信します。例えば Summarize this repository と入力すると、Agent はファイルの読み書きやコマンドの実行、サブエージェントへの委任を開始し、権限ポリシーを超える操作はまずあなたの承認を求めます。この三步には、掘り下げる価値のある二つのエンジニアリング上のポイントが隠れています：モデルルーティングは再起動不要と権限を超える操作には承認が必要です。前者はモデル非依存設計の現れであり、後者は制約ループの現れであり、いずれも以下で引き続き掘り下げます。

Cordis カーネルが行うことは三つだけ：プラグインのロード、アンロード、依存関係管理

「すべてがプラグイン」を理解した次に、最も直感に反する点はこれです：すべてがプラグインなら、カーネルには一体何があるのか？答えは——ごくわずかです。dsh の基盤はオープンソースのプラグインシステム Cordis によって駆動されており、Cordis カーネルはプラグインのロード、アンロード、依存関係管理のみを担当します。モデル、ツール、スキル、セッション、サンドボックス、ストレージ、ループ、スケジューリング、UI のいずれの能力も提供しません。これらの能力はすべてプラグインによって提供されます。

これは非常に過激で、非常にクリーンなアーキテクチャ上の決定です。従来の Agent フレームワークは通常「カーネルに中核能力を詰め込み + いくつかの拡張ポイントを残す」もので、変更できるのは許可されたいくつかの場所だけで、組み込みのセッションストレージやスケジューリングロジックを置き換えたいなら fork する必要があります。dsh は逆です：カーネルは極めて薄く、能力はすべてプラグインにあるため、「ある能力を置き換える」ことはもはや「カーネルに侵入する」ことではなく、「プラグインを一つ交換する」ことになります。

ではプラグイン同士は何によって協調するのか？Cordis が提供する二つの仕組み、サービス（Service）とイベント（Event）によります。こう理解できます：サービスはプラグインが外部に公開する能力インターフェースであり、例えばあるプラグインが「セッションストレージサービス」を提供する場合、他のプラグインがセッションを保存したいときはこのサービスを呼び出すだけで、その背後がデータベースなのかファイルなのかを知る必要はありません；イベントはプラグイン間でブロードキャストされるシグナルであり、あるプラグインがイベントを発すると、それに関心のあるプラグインがリスナーを登録して応答でき、双方は互いを知りません。この「サービス + イベント」の組み合わせにより、すべての能力が自由に置き換えられ、柔軟に再構成できます。

なぜイベント駆動がここで特に重要なのか？それは Agent の動作が高度に時系列化されているからです：一往復の会話が始まり、コンテキストが注入され、モデルが返し、ツールが呼び出され、ツールが結果を返し、サブ Agent がスケジュールされる……各ステップが自然な拡張ポイントです。もしこれらの拡張ポイントが継承とオーバーライドに頼るなら、プラグイン間の結合は急速に制御不能になるでしょう；イベントブロードキャストなら、どの能力もその傍らに「ポリシーとアダプタをマウント」でき、他人のコードに触れることなく、いつでもモデル、ツール、ストレージを交換できます。資料には、dsh のイベント駆動拡張ポイント体系がセッション / Agent / 能力の三級イベントに分かれていると明記されており、この設計の背後には学術的な裏付けもあります——Cordis の設計思想は論文「A Programming Paradigm for Spatiotemporal Composability」に対応します。入門読者にとって、論文を読む必要はありませんが、この結論は覚えておく必要があります：dsh の拡張方法は、新しいプラグインを他のプラグインの傍らにマウントすることであり、既存のコードを修正することではない。

カーネルの責務を狭めることによる直接的な利点は、可観測性とデバッグ容易性です。機能はプラグインであり、プラグインには依存関係があり、依存関係はカーネルによって管理されるため、任意の時点で動作している dsh は本質的に列挙可能なプラグインツリーです。それを出力し、検査し、置き換えることができます——これが次節で説明する設定レイヤー機能の基盤です。逆に言えば、フレームワークのカーネルに大量の暗黙的なロジックが隠れている場合、「自分のマシン上で実際に何が動いているのかを検査する」ことはできません。

特権なきカーネルと可逆的な副作用：dsh の拡張にパッチが不要な理由

Cordis アーキテクチャにおける最も重要なエンジニアリング制約は、実行時にパッチを当てる必要のある特権カーネルが存在しないことです。この一文は一字一句分解する価値があります。

多くのシステムでは、カーネル機能は「特権的」です。一度登録すると取り消すことができず、その動作を変えるにはパッチを当てるかモンキーパッチするしかなく、そうするとシステム全体が「作者だけが実際の動作を知っている」状態に陥ります。dsh はこの道を明確に避けています：すべての機能登録は可逆的な副作用であり、プラグインのアンロード時に自動的に取り消されます。

「可逆的な副作用」とは何でしょうか。平たく言えば、プラグインはロード時に自身が提供する機能をカーネルに登録し（たとえばツールの登録、サービスの登録、イベントリスナーの装着など）、これらの登録操作はカーネルによって記録され、そのプラグインがアンロードされるとカーネルはこれらの登録をすべて取り消します——ツールは消え、サービスは停止し、リスナーは解除され、システムはロード前の状態に戻ります。ちょうど関数に正方向と逆方向の対になる操作があり、ロードとアンロードが厳密に対称であるかのようです。

この制約はエンジニアリング実践に大きな影響を与える三つの実用的な利点をもたらします：

• 拡張にパッチが不要：機能を追加したいなら、新しいプラグインを書いて他のプラグインの隣にマウントすればよい。機能を変更したいなら、設定レイヤーで patch を使って置き換えればよい。ソースコードは決して触る必要がない。
• プラグインを安全に試行錯誤できる：アンロード即取り消しとは、実験的なプラグインをマウントして一巡動かし、不満ならアンロードしても、「ゴースト登録」が残って後続の実行を汚染することがないということです。
• システム状態を推論できる：任意の時点でシステムにどんな機能があるかは、現在どのプラグインがロードされているかに依存し、「歴史的に何がパッチされたか」には依存しません。これにより可観測、再生可能、再現可能が実現します。

これを「すべてはプラグイン」と結びつけて見ると、dsh の拡張哲学が非常に一貫していることがわかります：機能はプラグインから来て、プラグインは設定によって組み合わされ、アンロードは自動的に取り消され、拡張とはマウントすることです。素材の原文はこうです：dsh を拡張する方法は、新しいプラグインを他のプラグインの隣にマウントすることです。この一文には「ソースコードを変更する」余地が一切ありません——そもそも必要ないからです。

ここで初心者によくある落とし穴を先に指摘しておく価値があります：まさに登録が可逆的な副作用であるからこそ、プラグイン間の依存順序と依存宣言が非常に重要になります。あなたのプラグインがあるサービスに依存していて、そのサービスを提供するプラグインがまだロードされていない場合、登録時に失敗します。これがカーネルが「依存関係管理」を担当する理由でもあります。「サービスが存在しない」類のエラーに遭遇したとき、最初にすべきはプラグインのロード順序と依存宣言を確認することであり、カーネルを変更することではありません。次回プラグイン開発を扱う際に具体的な書き方を示します。

Profile + バンドル + patch：プラグインツリーの四層の積み重ね順序

動作中の dsh がプラグインツリーであるなら、このツリーはどのように成長するのでしょうか。答えは階層的な積み重ねです。素材は正確な積み重ね順序を示しており、全部で四層、最初から最後へ順に次のとおりです：

1. profile に列挙された順序で、各バンドル（Bundle）を適用します。profile はどの組み合わせを使い、どの順序でインストールするかを決めます。これは最も基本的な層であり、このツリーの幹を決めるものです。
2. profile 自身の cordis.patch.yml を重ねます。バンドルのインストールが終わったら、この patch ファイルで profile レベルでの修正や補足を行います。
3. home レベルの patch を重ねます。これはユーザーレベル（ホームディレクトリレベル）の個別設定で、単一の profile よりも適用範囲が広く、「すべてのプロジェクトで欲しい調整」を置くのに適しています。
4. 最後に任意の --patch overlay です。コマンドラインから一時的に渡されるオーバーレイで、優先度が最も高く、一度きりの実験やデバッグ、一時的な機能の差し替えに適しています。

この「Profile + バンドル」という階層モデルには、非常に実用的なエンジニアリング上の価値があります。それは関心の分離です。バンドルは他人が書いた機能の集合であり、profile はあなたのシナリオ選択であり、profile の patch はシナリオレベルの微調整であり、home レベルの patch はあなたの個人的な好みであり、--patch は今回の実行における一時的な決定です。4つの層がそれぞれ一区画を担い、互いを汚染しません。「この変更はどの層に置くべきか」が分からなくなったときは、「影響範囲が小さいほうから大きいほうへ逆算する」ようにしてください。今回の実行にしか影響しないなら --patch、この profile にしか影響しないなら profile の patch、自分のすべての作業に影響するなら home レベルの patch です。

4つの層を表で分かりやすく対照してみましょう:

この表は上から下へ層ごとに重ねていく読み方であり、互いに置き換えるものではないことに注意してください。後の層は前の層の結果に対してさらに変更を加えます。これは、設定の問題を調査するときに、まず「実際に有効になっている設定ツリー」を見なければならず、単一の patch ファイルだけを見てはいけない理由でもあります。あなたが見ている単一のファイルが、最終的に有効になる姿とは限らないのです。これが次の節のあのコマンドにつながります。

dsh --profile web --dump-config: 実際に起動する完全な設定ツリーを1行のコマンドで確認する

4 層の重ね合わせは一つの問題を引き起こします。設定があちこちに分散しているとき、「今この瞬間に実際に有効なのは何か」をどうやって確定すればよいのでしょうか。dsh が用意した答えは --dump-config です。素材にあるサンプルコマンドは次のとおりです。

# マシン上で実際に起動された完全な設定ツリーを出力する
dsh --profile web --dump-config

# 出力されたどのエントリも、自分の patch で置き換えられる

この一行は何の変哲もないように見えますが、これは「オープンで制御可能」という約束全体を果たす方法です。やっていることは、現在の profile のもとで、4 層の重ね合わせを経た後に実際に有効な完全な設定ツリーを出力することです。注目すべきキーワードは「実際に有効」——ある一つの patch ファイルの内容ではなく、重ね合わせた後の結果です。入門者にとってこれは、4 層の重ね合わせを頭の中でシミュレートする必要はなく、そのまま出力して見ればよいということを意味します。

なぜこれがエンジニアリング上それほど重要なのか。それは「自分の Agent が一体どんなものか」をブラックボックスの問題から読める問題へと変えるからです。次のようないくつかの場面で繰り返し使えます。

• 設定が効かないときの調査：patch を変更したのに挙動が変わらないとき、dump すれば自分の patch が読み込まれていないのか、後の層に上書きされたのかが分かります。
• アップグレード前の差分比較：プレビュー段階には互換性を壊す変更があります。アップグレードの前後でそれぞれ dump し、diff を取れば設定ツリーのどこが変わったかが分かり、変更ログを読むより直接的です。
• 他人の設定を学ぶ：ある profile を手に入れたら、dump すればどのバンドルを入れ、どの能力を置き換えたかがはっきり分かります。
• 置き換えの出発点にする：ある能力を置き換えたいとき、まず dump 結果の中で対応するエントリを見つけ、それに対して自分の patch を書きます。

素材にあるあのコメントが本節の鍵です。出力されたどのエントリも、自分の patch で置き換えられる。これは dump-config が単に「見る」だけでなく、「変える」ための入口であることを意味します——目にする一つ一つの項目は、あなたが引き継げる対象なのです。これが「あなたの Agent がどんなものかは、あなたが決める」の具体的な操作経路です。まず審査し、それから置き換える。

ここには非常に踏みやすい落とし穴があります。dump 結果を見る前に patch を書き始めてはいけません。4 層の重ね合わせが存在するため、書いた patch がより高い優先度の層と衝突する可能性があります。正しい順序は常に、まず --dump-config で現在有効な値を確認する → 変更したいエントリがどの層で設定されているかを特定する → より高い（または同じ層でもより遅い）層に patch を書く、です。この習慣が「変えたのに反応がない」という困惑を大量に省いてくれます。

4 つの実行モードの対照：標準 / PTC / 極簡 / 創造それぞれの能力構成

dsh は箱から出してすぐに 4 つの実行モードを提供し、「機能完備のコーディング Agent」から「最小限のベンチマーク」、さらには「自分で新しいモードを作る」までの全スペクトルをカバーします。これら 4 つのモードの違いは UI スキンではなく、能力構成の違いです——つまりどのプラグインを入れ、どのツールを露出しているかです。それらの構成の違いを理解すれば、正しいモードを選べるようになり、「すべてはプラグイン」という言葉が実践で持つ意味も分かります。

一つずつ見ていくと、より実感が湧く。

標準モードは機能が完全なコーディング Agent であり、能力リストにはファイル編集、Shell、ファイルとウェブの検索、Skills、計画、目標、サブエージェント、ワークフローが含まれる。これはかなり完全なツールセットだ。検索は情報を見つけさせ、ファイル編集はコードを変更させ、Shell はコマンドを実行して検証させ、計画と目標は長いタスクを組織させ、サブエージェントはサブタスクを委任して並列または隔離して処理させる。ほとんどの入門シナリオでは、標準モードからそのまま始めればよい。

PTC モードは、この体系の中で最も研究色の強いものだ。標準モードのすべての能力を備えるが、ツールの提示方法が異なる——Code Mode SDK を通じてツールを提示し、モデルに一段の TypeScript プログラムで複数ステップのツール呼び出しを組み合わせさせる。素材の表現は「PTC モード（モデルが一段の TypeScript プログラムで複数ラウンドのツール呼び出しを組み合わせる）」だ。この違いは入門読者には次のように理解できる。通常モードではモデルは一歩ずつツールを呼び出し、結果を待ち、次の一歩を考える。PTC モードではモデルはまずプログラムを書いて、これらの複数ステップの操作を一連につなげることができる。これは多段階で、パターン化され、正確な組み合わせを必要とするタスクにとって非常に価値がある——これが素材で PTC を AI/ML 従事者を惹きつける特性として挙げている理由でもある。

極簡モードは最も個別に説明する必要がある。その能力構成が非常に抑制的だからだ。永続 bash と str_replace_editor の二つのツールのみを保持し、最小化環境でのモデル評価に用いる。なぜこのような「簡素な」モードが必要なのか。モデル評価を行うときは、変数をできるだけ少なくしたいからだ——ツールが多ければ多いほど、振る舞いは豊かになり、それがモデルの貢献なのか環境の貢献なのかを判断するのが難しくなる。ツールを二つだけに削れば、クリーンで制御可能な基盤の上でモデル自体の性能を観察できる。これは逆に「すべてはプラグイン」の威力を裏付ける。モード間の違いは異なるプラグインを入れただけであり、カーネル内に異なるハードコードされた分岐があるわけではない。

創造モードは「自分でモードを作りたい」人のために用意されている。標準モードのすべての能力を備え、さらに実行時検査、プラグイン実験、preset 創作指導を提供する。つまり、実行時にシステム状態を観察し、プラグインを試し、指導の下で自分の preset を創作し、自分だけの新しいモードを組み合わせることができる。上級読者にとって、これは「dsh を使う」から「dsh をカスタマイズする」への入口であり、次回で展開する。

これら四つのモードを並べて見ると、それらが実は同じプラグイン機構の異なる組み合わせ結果であることに気づくだろう。標準モードは「全量ツール」、PTC モードは「ツールの提示方法を変える」、極簡モードは「二つのツールだけに削る」、創造モードは「自分で作るためのツールを渡す」。モードはカーネル内のハードコードではなく、プラグイン組み合わせのレシピである。これこそが「すべてはプラグイン」がスローガンから実行時へと降りてきた姿だ。

ここまでで、前編は dsh のマクロな全体像を広げてきた。Agent = Model + Harness の分業ロジック、プロンプトエンジニアリングからハーネスエンジニアリングへの三度の跳躍、dsh のプロジェクトとしての身分とプレビュー段階の注意事項、Cordis カーネルがロード/アンロード/依存管理のみを担うこと、特権なきカーネルと可逆な副作用がもたらす拡張方法、Profile + バンドル + patch の四層の重ね合わせ順序、--dump-config で実際に有効な設定ツリーを確認すること、そして四つの実行モードの能力構成の違いである。しかしこれらはすべて「使う」と「設定する」の層である。dsh をどれだけ深く使えるかを本当に決めるのは、プラグインをどう書くか、イベント拡張点をどこに掛けるか、能力がどう patch で置き換えられるか、セッションログと Trajectory がどう可観測性とリプレイを支えるか——これらが次回で分解する部分である。先に進む前に、まず本記事の二つの例に従って環境を動かし、一度 dsh --profile web --dump-config を実行して、あなたのマシン上のプラグインツリーを自分の目で見てみることを勧める。

前回のセクションでは、DeepSeek Harness（以下 dsh）の全体骨格をすでに分解しました。Cordis カーネルが中央に位置し、能力プラグインがその周囲を囲み、モデル、ツール、スキル、セッション、サンドボックス、ストレージ、ループ、スケジューリング、UI のすべてをプラグインが提供します。そして Agent = Model + Harness という一文で、「モデルは知能を担い、Harness は信頼性の高い運用を担う」という役割分担を言い切っています。このセクションではレンズをぐっと寄せ、TypeScript プログラムがどのように複数ステップのツール呼び出しを組み合わせるかから始め、セッションログ、イベント体系、2 つのインストール経路、Web UI の 3 ステップ、多形態 SDK の役割分担までを一気にたどり、最後に 2026 年 9 月時点のコミュニティの遊び方と実行可能なチェックリストに着地します。

PTC モードと Code Mode SDK：モデルに 1 つの TypeScript プログラムで複数ステップのツール呼び出しを組み合わせさせる

まず、多くの人が Agent を初めて使うときの痛点を挙げましょう。少し複雑なこと、たとえば「リポジトリ内で古い設定フィールドを参照しているすべてのファイルを見つけ、1 つずつ読み出し、フィールド名を置換し、さらに型チェックを 1 回走らせて壊れていないことを確認する」をやりたいとき、モデルはしばしば十数ラウンドを行き来しなければなりません。ディレクトリを読む、ファイル A を読む、ファイル B を読む、ファイル A を書く、ファイル B を書く、tsc を走らせる、エラーを見る、また直す……。各ラウンドは「モデルが考える → ツール呼び出しを出力する → 実行する → 結果を戻す」という完全なサイクルです。ラウンド数が増えると、遅延が蓄積し、コンテキストが膨張し、途中のあるステップの一時変数を置く場所もなくなり、最後にはモデル自身も迷子になりやすくなります。

dsh の PTC モードは、まさにこのシナリオに向けたものです。PTC の正式名称は「プログラム的ツール呼び出し」という考え方に対応します。標準モードの能力の上に、さらに Code Mode SDK を通じてツールをモデルに提示します。ここが重要で、提示のされ方が変わります。ツールはもはや「呼び出し可能な関数シグネチャ」ではなく、モデルが直接書ける TypeScript API の一式になります。するとモデルは「1 回呼んで、1 回待って、また呼ぶ」必要がなくなり、複数ステップの操作を 1 つに編成した完全な TypeScript プログラムを書き、一度に提出します。

このことの価値は次のように理解できます。標準モードではモデルは「一問一答式にツールを駆使する」のに対し、PTC モードではモデルは「コードでツールをパイプラインにつなぐ」のです。 前者は対話ラウンドに制約され、後者はプログラムの表現力に制約されます。そしてプログラムの表現力は明らかにずっと広いものです。その TypeScript の中では、ループを書き、条件分岐を書き、try/catch を書き、中間結果をローカル変数に保存し、提出前に一度検証を行うことができます。本来十数ラウンドの往復が必要だった作業が、1 つのプログラムの中に収束して完走します。

PTC の位置づけは「標準モード + Code Mode SDK」です。つまり、ファイル編集、Shell、ファイルと Web の検索、Skills、計画、目標、サブエージェント（subagent）、ワークフローといった標準モードの能力は 1 つも欠けておらず、ただコード編成という表現の層が 1 つ増えているだけです。実際の使用にどう落とし込むのか。直感的なイメージは次のとおりです。

// 概念的なイメージ：PTC モードでは、モデルはこのような TypeScript プログラムを書ける
// 「ファイルを読む → フィールドを変更する → 検証を走らせる」というパイプラインを一度に提出し、十数ラウンドの対話に分割しない
import { tools } from "@deepseek-ai/dsh/code-mode";

const targets = await tools.file.search({ pattern: "src/**/*.ts", grep: "legacyFieldName" });

for (const file of targets) {
  const source = await tools.file.read({ path: file.path });
  if (!source.includes("legacyFieldName")) continue;
  const patched = source.replaceAll("legacyFieldName", "newFieldName");
  await tools.file.write({ path: file.path, content: patched });
}

// すべて変更し終えたら一度に検証を走らせ、失敗したらエラー情報をモデルに持ち帰る
const check = await tools.shell.run({ command: "pnpm run typecheck" });
if (check.exitCode !== 0) {
  return { ok: false, log: check.stdout };
}
return { ok: true, changed: targets.length };

注意していただきたいのは、上記は概念を示すサンプルコードであり、「1つのプログラム = 複数ラウンドのツール呼び出し」という直感を養うためのものです。具体的なインポートパスと API 名は、お使いの dsh バージョンの Code Mode SDK ドキュメントを参照してください。真のエンジニアリング的価値は次の3点にあります：

• ラウンドの収束：複数ステップの操作が1回のプログラム実行に圧縮され、「モデルの往復」という最も高コストなオーバーヘッドが削減され、長いタスクが途中で脱線しにくくなります。
• 中間状態の置き場所がある：ローカル変数が一時ストレージを担い、各ステップで結果をコンテキストに戻す必要がなくなり、コンテキストがよりクリーンになります。
• 失敗を一括で処理できる：プログラム内で通常のエラーハンドリングロジックを使って失敗に対応でき、モデルが次のラウンドで「どこが間違っていたか推測する」必要がありません。

これと対照をなすのがミニマルモードです：永続 bash と str_replace_editor の2つのツールのみを保持し、最小化環境でのモデルベンチマークテストに特化しています。ミニマルモードが求めるのは「変数を最小限に抑え、モデルの素の能力を見る」こと；PTC モードが求めるのは「オーケストレーション能力を最大限に引き出し、Harness の付加価値を見る」ことです。同じフレームワーク内でこの2つの極端を共存させること自体が、dsh の「すべてはプラグイン」の表れです——能力の構成は設定によって決まるものであり、ハードコードされているわけではありません。

追記専用セッションログ：システムプロンプト、思考連鎖、ツール呼び出し、サブ Agent スケジューリングのすべてをディスクに記録

Agent で最もトラブルシューティングが難しい問題は何か？それは「なぜそうしたのか」です。ファイルを削除したのは見えても、削除する前に頭の中で何を考えていたかは見えません。サブエージェントを呼び出したのは見えても、そのサブエージェントにどんなコンテキストを詰め込んだかは見えません。ブラックボックス Agent のデバッグ体験は、ほぼ推測と同じです。

dsh のこの問題に対する答えは非常に明快です：モデルが見たものすべてがセッションログに書き込まれる。システムプロンプト、思考連鎖、ツール呼び出しと結果、サブ Agent スケジューリング、あらゆるコンテキスト注入——すべてがディスクに記録されます。しかもこのログは追記専用（append-only）設計を採用しています：前にしか書かず、後戻りして変更しません。これは地味に聞こえますが、多くの性質をもたらします：

• 追跡可能：あらゆるアクションについて、どのコンテキスト、どのツール結果に誘発されたものかをログに沿って振り返ることができます。
• 復元可能：セッションが中断しても、ログのイベントストリームから続きを進められ、前のステップを再実行する必要がありません。
• 分岐可能：あるノードで別の進め方を試したい？そこから新しいブランチを fork し、元のパスはそのまま保持されます。
• 検索可能：イベントストリームはクエリ可能なオブジェクトであり、「この実行でツール呼び出しが合計何回失敗したか」を問い合わせるのに人手でページをめくる必要がなくなります。
• 再生可能：復元、分岐、検索、再生が同じイベントストリームを共有するということは、再生で見るものがその時実際に起きたことそのものであり、「ログと実際の実行が不一致」ということがありません。

これらの能力の実装方法は特筆に値します：それらは4つの別々のシステムではなく、同じイベントストリームの4つの使い方です。これが append-only 設計の利点です——データは1つしかなく、誰もがそのビューです。もしログが自由に上書き可能であれば、復元と再生は互いに衝突するでしょう；変更不可だからこそ、4つの使い方が共存し自己整合的でいられるのです。

このログを消費するインターフェースは Trajectory ビューです。ソース別に閲覧します：システムプロンプトは1つのソース、思考連鎖は1つ、ツール呼び出しと結果は1つ、サブ Agent スケジューリングはまた1つ、コンテキスト注入もまた1つ。ある実行の結果が期待と合わないとき、Trajectory ビューでソースに沿って「プロンプトの説明が不明確だったのか」「ツールが汚いデータを返したのか」「サブエージェントが受け取ったコンテキストが切り詰められたのか」を特定できます。研究者にとってこれはほぼ必須です——完全に観測可能なイベントストリームはそれ自体が研究材料です；エンジニアにとってこれは、Agent を「神秘」から「エンジニアリング」へ引き戻す綱です。

もう一つ見落とされがちな細部がある。素材は特に、モデルが見るあらゆるコンテキスト注入がディスクに永続化されると述べている。コンテキスト注入は目立たないものだ——あなたのコードを変えるわけではないが、実際にモデルの振る舞いを変えてしまう。それをイベントストリームに記録することは、「見えざる手」を机の上に広げて見せることに等しい。

セッション / Agent / ケイパビリティの三層イベント：イベント駆動の拡張ポイントにポリシーとアダプタをどうマウントするか

「すべてはプラグイン」が本当に成り立つには、プラグインローダーだけでは足りない。十分に細かいフックの網も必要だ——プラグイン同士は何によって協調するのか？ Cordis の Service（サービス）と Event（イベント）によってだ。dsh はイベント拡張ポイントを三層に分けている：セッション層、Agent 層、ケイパビリティ層。

この区分は思いつきではない。Agent ランタイムの三つの尺度に対応している。セッション層のイベントは「一回の完全なセッションのライフサイクル」に注目する。たとえばセッションの開始、終了、復元、分岐などだ。Agent 層のイベントは「一回のタスク実行の過程」に注目する。たとえば Agent の起動、計画、サブエージェントへの委譲、完了などだ。ケイパビリティ層のイベントは「ある具体的なケイパビリティの呼び出し」に注目する。たとえばあるファイル読み書き、ある Shell 実行、ある検索などだ。ざっと見れば三層だが、細かく見れば三つの粒度だ：セッションは容器、Agent は実行体、ケイパビリティは動作。

開発者はこの三層をどう使うのか？ 答えはポリシーとアダプタのマウントだ。ポリシー系プラグインはイベントを監視して意思決定を行う——たとえばケイパビリティ層のイベントに「書き込み操作はまずいったん止めて承認を待つ」というポリシーをマウントする。アダプタ系プラグインはイベントを監視して翻訳を行う——たとえば Agent 層のイベントで、あるプロバイダの応答フォーマットを統一フォーマットに翻訳する。以下の対照表は、三層の着眼点、典型的な用途、置き換え可能なものを示している：

三層が重なることで、死角のない拡張網が構成される。モデルを替え、ツールを替え、ストレージを替えても、その全過程でソースコードを一切変更する必要がない——変えるのは設定とプラグインの組み合わせだ。この言葉の重みはここにある：クローズドソース Agent の能力の境界はベンダーが引くが、dsh の能力の境界はあなた自身が引く。

その背後には、もう一つ非常に重要なメカニズムの約束がある：実行時にパッチを当てる必要のある特権カーネルは存在しない。すべてのケイパビリティ登録は可逆な副作用であり、プラグインのアンロード時に自動的に取り消される。この言葉が解決するのは「プラグインシステムによくある難題」だ——プラグインの導入は簡単だが、きれいに取り除くのは難しく、残留したグローバル状態がシステムをますます不安定にする。dsh は「登録は副作用、アンロードは取り消し」をカーネルレベルの制約にした。そのため dsh を拡張する方法はとても軽いものになる：新しいプラグインを他のプラグインの隣にマウントする。特権層がなければ、パッチの居場所もない。

基盤となる Cordis の設計思想は論文「A Programming Paradigm for Spatiotemporal Composability」に対応しており、学術的な裏付けがある。その場ででっち上げた車輪ではない。イベント駆動 + 可逆な登録 + 設定レイヤーの合成、この三つが揃ってこそ、「すべてはプラグイン」というスローガンが成り立つ。

npx @deepseek-ai/dsh web とソースからのインストール：二つの導入経路の完全なコマンド

理論はここまでにして、実際に手を動かそう。dsh の前提条件はとても軽い：Node.js がインストールされていればよく、OS は Linux、macOS、Windows のいずれでも構わない。コマンドラインの基本操作、Node.js の基礎、API Key とは何かをおおよそ知っていれば十分で、AI 研究のバックグラウンドも、深い機械学習の知識も必要ない。

一つ目の経路は npx によるワンコマンド起動で、まず動かして見てみたい人に適している：

# 方法一：npx で Web UI をワンコマンド起動（事前のグローバルインストール不要）
npx @deepseek-ai/dsh web

# 起動後、ブラウザでデフォルトアドレスにアクセス
# http://127.0.0.1:3080

この一行のコマンドが裏で行っているのは：@deepseek-ai/dsh という npm パッケージを取得し、web profile で起動し、Web UI を http://127.0.0.1:3080 に公開する。デフォルトではローカルループバックアドレスにバインドされ、外部には公開されない点に注意。

二つ目の経路は ソースからのインストールで、コードを読みたい、プラグインを改変したい、コントリビュートしたい人に適している：

# 方法二：ソースからインストール
git clone https://github.com/deepseek-ai/deepseek-harness.git
cd deepseek-harness
pnpm install
pnpm run build
pnpm dsh web

四つのステップはそれぞれ：リポジトリのクローン、依存関係のインストール、ビルド、web profile での起動。ここで npm ではなく pnpm を使うのはリポジトリの取り決めであり、そのまま打ち込めばよい。二つの経路の違いは機能ではなく、「どこまで深く改変できるか」にある：npx の経路では組み立て済みの完成品が手に入り、ソースの経路では自分で分解できる一台丸ごとが手に入る。

どちらの経路を取っても、インストール後にまずやるべきことは同じステップだ——実際に起動される設定ツリーを確認する：

# 現在の profile が実際に起動する完全な設定ツリーを出力
dsh --profile web --dump-config

# 出力されたどの項目も、自分の patch で置き換え可能

なぜこのステップが重要か？dsh の設定は階層的に積み重なるからだ：起動時にはまず profile が列挙する順序で各 Bundle を適用し、次に profile の cordis.patch.yml、次に home レベルの patch、最後に任意の --patch overlay を適用する。つまり、実行中の dsh は複数の層が積み重なってできたプラグインツリーである。--dump-config を使えば「このツリーが今どんな姿か」を見ることができ、出力内のどの項目も自分の patch で置き換えられる。これこそが「オープンで制御可能」をスローガンから事実に変える鍵となる一歩だ：信じられない？ならば設定ツリーを出力して見てみよう。

まず前提として必ず覚えておくべきことがあります。dsh は現在開発者プレビュー段階にあり、MIT ライセンスを採用しており、将来的に互換性を破壊する変更が入ることを公式が明確に警告しています。これは二つのことを意味します。一つ目は、アップグレード前に変更履歴を確認し、本番フローをプレビュー版の安定性に賭けないこと。二つ目は、MIT でオープンソースであり設定レイヤーが組み合わせ可能であるがゆえに、自分の patch レイヤーで挙動を固定でき、上流のデフォルト値の変更に影響されないということです。

Web UI の三步走：設定 → モデルにキーを入力、ワークスペースを追加、タスクを送信

Web UI は dsh で最も手軽な入口で、デフォルトのアドレスは http://127.0.0.1:3080 です。始めるのはわずか三ステップです：

1. モデルを設定：「設定 → モデル」を開き、DeepSeek API キーを入力して保存します。ここがポイントです——モデルルーティングは即座に有効になり、再起動は不要です。この機能は小さく見えますが、体験の差は大きいです。モデルを切り替えるのにサービスを止める必要がなく、長いタスクを実行している人にとっては中断できるかどうかの違いになります。
2. ワークスペースを選択：dsh を起動したときのプロジェクトディレクトリを追加して選択します。ここには陥りやすい罠があります——ワークスペースを選択するまで、セッションの入力ボックスは使用できません。初めて使う人はインターフェースが固まったと勘違いしがちですが、実際には Agent に「どのプロジェクトで作業するか」をまだ伝えていないだけです。この設計は意図的です。Agent には明確なファイルシステムの境界があり、どこでも読み書きできるわけではありません。
3. タスクを実行：例えば「Summarize this repository」のようなタスクを送信します。すると Agent はファイルを読み書きし、コマンドを実行し、サブエージェントに委任します。権限について——権限ポリシーを超える操作はまずあなたの承認を求めます。黙って実行されることはありません。このゲートは多段階のイベント体系において「能力レベルのイベントにポリシープラグインを掛ける」使い方に対応し、Agent を実際のプロジェクトに投入する際の基本的な安全ラインでもあります。

三ステップを並べて見ると、dsh の設計意図は明確です。まずモデルを定め（魂）、次に境界を定め（ワークスペース）、そしてタスクを放つ（実行）。順序は恣意的ではなく、「モデルはどこから来るのか、何に触れられるのか、何をすべきか」という必ず答えるべき三つの問いに対応しています。

多形態での利用：Web UI、headless、CLI、Python SDK、TypeScript SDK の役割分担

dsh は一つのインターフェースだけではありません。その多形態設計は異なる利用シーンに対応しており、形態を間違えるとぎこちなく感じ、正しく選べばとてもスムーズです。

違いを一つずつ説明します。

Web UI は最も機能が充実した形態で、「人が立ち会う」ときに適しています。何をしようとしているのかを見たい、あるラウンドのツール呼び出しが何を返したのかを見たい、Trajectory ビューでソースごとに調査したい——そういう場面はここです。headless は逆に、タスクを一度に実行し、最終的な答えを出力して終了します。この形態はスクリプトや CI に生まれつき向いています。なぜなら「UI 上であなたがクリックするのを待つ」という段階が存在しないからです。たとえばパイプラインに自動チェックを一つ追加するなら、headless 形態が最も自然です。

CLI はターミナルからの入口であり、dsh --profile web --dump-config のような設定確認コマンドを実行する入口でもあります。Python SDK の系統には非常に実用的な細部があります。pip install deepseek-harness-sdk であり、しかもランタイムを同梱しており、システムの Node.js は不要です。Python チームにとってこれは価値が高い——Agent を一つ組み込むために環境へ余分に Node ランタイムを詰め込む必要がなく、依存の範囲がずっと小さくなります。以下に、Agent を Python ワークフローに組み込む概念的なサンプルコードを示します。

# 概念的なサンプル：Python SDK で dsh を自分のワークフローに組み込む
# インストール：pip install deepseek-harness-sdk（ランタイム同梱、システムの Node.js 不要）
from deepseek_harness_sdk import Harness

# プロジェクトディレクトリを指し、使い捨ての Harness セッションを構築する
harness = Harness(workspace="./my-repo")

result = harness.run(
    "このリポジトリのモジュール依存関係を整理し、Markdown の概観を出力する",
    # 権限ポリシーを超える操作はまず承認コールバックを発火する。ここではすべて自動的に拒否する
    on_approval=lambda req: False,
)

print(result.final_answer)
# 完全なイベントストリームは別途エクスポートでき、リプレイや検索に使える
result.export_events("run-events.jsonl")

同様に、これは概念的なサンプルコードです。フィールド名とコールバックのシグネチャは公式 SDK ドキュメントに従ってください。重要なのは「Harness を構築 → タスクを渡す → 最終的な答えを得る → イベントストリームをエクスポートする」というこの一連の流れを理解することです。最後のイベントストリームをエクスポートする行に注目してください。これは先に述べた append-only のセッションログの価値を SDK に持ち込むものです。Web UI で見られるだけでなく、自分のデータパイプラインに接続することもできます。

TypeScript SDK は TS エコシステムとの深い統合を志向しており、プラグイン開発や Code Mode SDK と同じく TS 側の能力に属します。あなたのチームがもともと TypeScript を書いているなら、プラグインからオーケストレーションまで同じ言語スタックで完結でき、認知負荷が小さくなります。

五つの形態を並べて見ると、dsh の位置づけがはっきりします。それは「また一つ、agent をいくつか書くためのライブラリ」ではなく、SDK とフレームワークの上に位置し、「Agent がいかに信頼性高く動作するか」を解決する完全な一層です。この位置づけの線を示すために、現在のいくつかの人気ツールを一つの表に並べて比較できます。

この表で最も覚えておくべき一文は最後の行です：フレームワークの構築と Harness は同じ層の問題ではない。LangGraph のようなライブラリで Agent を組み上げるのは「構築」です；組み上げた後、それが安定しているか、落ちても復旧できるか、モデルを変えるのにソースコードを触る必要があるか、問題が起きたときにリプレイできるか——それは「運用」です。dsh は後者の層に立っています。

ついでに業界の背景データも並べておきます。これらの素材にはすべて含まれています：OpenAI チームの 100 万行コード実験では、5 か月間の成果がすべて Agent によって完了し、エンジニアは一行もコードを書きませんでした；LangChain は外部のハーネス環境（ドキュメント構造、検証ループ、トレーシングシステム）だけを最適化し、コーディング Agent の Terminal Bench 2.0 でのスコアを 52.8% から 66.5% に引き上げ、世界ランキングを 30 位から 5 位に上げましたが、基盤モデルのパラメータは一つも変えていません。ボトルネックはモデルの知能ではなく、インフラストラクチャにある——これこそが Harness が存在する理由です。

AI エンジニアリングパラダイムの進化を整理すると、三つの跳躍が見えてきます：プロンプトエンジニアリング（2023~2024、最適化対象は入力の言い回し、単一の対話品質を解決、インタラクションモードは一問一答）、コンテキストエンジニアリング（2025、最適化対象は情報入力、知識の境界とハルシネーションを解決、インタラクションモードは情報注入後の生成）、ハーネスエンジニアリング（2026 年以降、最適化対象は実行環境、Agent の信頼性と持続可能性を解決、インタラクションモードは人間が舵を取り、Agent が実行する）。dsh はハーネスエンジニアリングの理念を完全に製品化して落とし込んだものです。

2026 年 9 月の最新動向：dsh --dump-config から始まるプラグインコミュニティと preset 実践

2026 年 9 月までに、dsh をめぐるエコシステムはかなり明確な遊び方の道筋を育てており、その道筋の起点はちょうど前節で述べたコマンドです：dsh --profile web --dump-config。なぜそこから始めるのか？それは「システムが実際にどのような姿をしているか」を広げて見せるからです。あなたが見る各エントリは、置き換え可能な組み付けポイントです；そしてコミュニティの遊び方とは、本質的には「他人のプラグインでこれらのポイントを埋める、あるいは自分のプラグインをこれらのポイントに差し込む」ことです。

プラグインを探す場所は GitHub topics: dsh-plugin です。一つの topic でプラグインエコシステムを収束させる利点は非常に現実的です：検索、購読、トピック別閲覧はすべて GitHub ネイティブの機能で行え、追加の中央集権型マーケットプレイスは不要で、「マーケットが閉じたら全部なくなる」という単一障害点も存在しません。これは MIT オープンソース、テレメトリなし、クラウドロックインなしという全体的な志向と一致しています。

9 月前後で非常によく注目すべきもう一つの方向は創造モードです。その位置づけは「カスタム Agent preset」であり、能力構成は標準モードのすべての能力 に加えて、ランタイム検査、プラグイン実験、preset 作成指導です。言い換えれば、創造モードは単なる実行ティアではなく、「Agent を作る作業台」のようなものです：その中でランタイム状態を検査し、プラグインのマウントを試し、そして指導に従って一つの preset を組み上げます。

preset とは何か？「一整套のプラグイン組み合わせ + 設定の重ね合わせ」のスナップショットと理解できます。先に述べた重ね合わせ順序に戻ると：profile がバンドルパッケージを列挙 → 各バンドルパッケージを適用 → profile の cordis.patch.yml → home レベルの patch → --patch overlay。preset とは、このチェーン上の某一層の組み合わせを固定し、パッケージ化して再利用することです。そこでコミュニティで最も自然な二つの遊び方が現れます：

• 横の遊び方：部品を交換する。モデル、ツール、スキル、セッション、サンドボックス、ストレージ、ループ、スケジューリング、UI のうち任意の一つを、コミュニティプラグインで置き換えられます。たとえば、デフォルトのストレージをあなたのチーム内部のストレージアダプタに替えたり、検索を自前で構築したナレッジベースに替えたりできます。
• 縦の遊び方：preset を重ねる。部品は変えず、組み合わせ方を変えます。「フロントエンドリファクタリング」「データパイプライン保守」「ドキュメントサイト生成」といった細分化されたシナリオごとに、それぞれ preset を組み、使うときに切り替えれば別の Agent の振る舞いになります。

4 つの実行モードの系譜は、この時点では特に理解しやすくなります。標準モードは機能が完全なコーディング Agent（ファイル編集、Shell、ファイルとウェブの検索、Skills、計画、目標、サブエージェント、ワークフロー）です。PTC モードは標準機能の上に Code Mode SDK を重ね、モデルが 1 つの TypeScript プログラムで多段のツール呼び出しを組み合わせられるようにします。極簡モードは永続 bash と str_replace_editor だけを残し、最小限のベンチマークに用います。創造モードは標準機能にランタイム検査、プラグイン実験、preset 創作指導を加えたものです。最初の 3 つは「どのギアで走るか」、4 つ目は「新しいギアをどう作るか」です。

ここでは実践レベルの設定スケルトンの一例を示し、「patch がどこから来て、どこに重なるのか」を具体的に理解できるようにします。

# 実践例：--patch overlay を使い、ソースを変更せずに機能を置き換える
# 1) まず現状をはっきり確認する
dsh --profile web --dump-config > current-config.txt

# 2) 自分の patch レイヤーを用意する（命名は例示。公式 patch 形式に従うこと）
#    ログストレージをチーム内部バックエンドに向け、書き込み承認ポリシーを付ける
cat > my-overlay.patch.yml << 'EOF'
storage:
  driver: team-internal-store
policies:
  - name: approve-writes
    on: capability.file.write
    action: require-approval
EOF

# 3) overlay を付けて起動すれば、設定が有効になる
dsh --profile web --patch my-overlay.patch.yml

繰り返しますが、これは構造の例示であり公式の設定サンプルではありません。フィールド名は使用しているバージョンのドキュメントに従ってください。ここで伝えたいのは、そのエンジニアリング上の習慣です——まず現状を dump し、次に自分の patch を重ね、最後に overlay を付けて起動する。この習慣があれば、プレビュー版が進化し続ける中でも常に主導権を握れます。上流のデフォルト値がどう変わっても、あなたの overlay はあなたの手元にあります。

最後に、9 月前後に特に留意すべきエンジニアリング事項を 3 つ挙げます。第一に、プレビュー期の心構えです。公式は将来破壊的な互換性変更があると明確に注意喚起しているので、カスタムロジックはできるだけ自分の patch とプラグインに収め、上流のソースを直接変更しないようにしましょう。アップグレード時の苦痛がずっと小さくなります。第二に、可観測性を先にです。実行のたびに append-only ログに書き込まれ、Trajectory ビューでソース別に確認できるのですから、何か問題が起きてから思い出して調べるのではなく、第一手の調査ツールとして使いましょう。第三に、権限ポリシーは早めに設定です。権限ポリシーを超える操作はまず承認を求められます。これは良い仕組みですが、デフォルトポリシーがあなたのプロジェクトに合うとは限りません。早い段階でプラグインを通じてチームの習慣に合わせておくほうが、後から補正するより手間が省けます。

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

全文の要点を、そのまま実行できるチェックリストに圧縮します。

1. まず主線を覚える：Agent = Model + Harness。モデルは魂であり、Harness は環境を理解し、ツールを使い、現実のシナリオで継続的に作業する役割を担います。ボトルネックは通常、モデルの知能ではなくインフラにあります。
2. アーキテクチャの中核を理解する：Cordis カーネルはプラグインのロード、アンロード、依存関係管理だけを担当します。モデル、ツール、スキル、セッション、サンドボックス、ストレージ、ループ、スケジューリング、UI はすべてプラグインが提供し、Service と Event を通じて協調します。実行時にパッチを当てる必要のある特権カーネルはなく、登録は可逆的な副作用であり、アンインストールで自動的に取り消されます。
3. 場面に応じてモードを選ぶ：シナリオ別に実行モードを選びます——標準モードは完全なコーディング Agent。PTC モードは Code Mode SDK で多段のツール呼び出しを 1 つの TypeScript プログラムに収束。極簡モードは bash と str_replace_editor だけを残してベンチマーク。創造モードはランタイム検査、プラグイン実験、preset 創作に使用。
4. 可観測性をデフォルト動作にする：モデルが見るものはすべて append-only のセッションログに書き込まれます（システムプロンプト、思考の連鎖、ツール呼び出しと結果、サブ Agent のスケジューリング、コンテキスト注入）。復元、分岐、検索、再生は同じイベントストリームを共有し、Trajectory ビューでソース別に確認します。
5. 3 段階のイベントで拡張を掛ける：セッション級はライフサイクル、Agent 級はタスク過程、機能級は具体的な呼び出しを管理します。ポリシーを掛けて承認と検証を行い、アダプターを掛けてフォーマットとバックエンドを置き換え、モデル、ツール、ストレージをソース変更なしで交換できるようにします。
6. インストールで悩まない：すぐ試したいなら npx @deepseek-ai/dsh web。ソースを読みプラグインを変更するなら git clone → pnpm install → pnpm run build → pnpm dsh web。前提は Node.js がインストールされていることです。
7. Web UI は 3 ステップ：設定 → モデルで DeepSeek API キーを入力（ルーティングは即時有効、再起動不要）→ ワークスペースを追加して選択（未選択時は入力欄が使えない）→ タスクを送信。権限を超える操作はまず承認が必要です。
8. 適切な利用形態を選ぶ：対話的な調査は Web UI（デフォルト http://127.0.0.1:3080）。スクリプトと CI は headless（一度だけ実行し、最終回答を出力して終了）。ターミナル操作は CLI。Python ワークフローは pip install deepseek-harness-sdk（ランタイム同梱、システム Node.js 不要）。TS の深い統合は TypeScript SDK。
9. 設定を dump する習慣を身につける：作業前にまず dsh --profile web --dump-config を実行し、profile → バンドル → cordis.patch.yml → home 級 patch → --patch overlay の重なり結果を確認します。挙動を変えたいときは自分の patch やプラグインを書き、上流のソースは変更しません。
10. コミュニティについていく：プラグインは GitHub topics: dsh-plugin で探せます。自分の Agent を作りたいなら、創造モードの preset 創作指導を使い、「プラグインの組み合わせ + 設定の重ね合わせ」を固定化し、細かなシナリオごとに再利用します。
11. プレビュー期の 3 つの規律：アップグレード前に変更説明を確認する（公式は破壊的な互換性変更があるとすでに注意喚起しています）。カスタムロジックは自分の patch レイヤーに収める。権限ポリシーは早めにチームの習慣に合わせて設定する。
12. ライセンスと境界を覚える：MIT ライセンス、テレメトリなし、クラウドロックインなし、設定レイヤーは自由に組み合わせ可能、能力の境界はあなたが引く——これこそが「Everything is a Plugin.」をエンジニアリングに落とし込んだ意味です。

ひとことだけ持ち帰るなら、これです：dsh は「AI を御すること」を方法論から、組み合わせ可能で、観測可能で、差し替え可能なインフラへと変える。Agent をゼロから書く必要もなければ、他人のブラックボックスに閉じ込められる必要もありません——モデルを差し込み、Plugin を自分のやり方で取り付け、あとは Trajectory ビューで作業が一歩ずつ完了していくのを見守るだけです。