公式 README では、DeepSeek Harness の Web UI は既定で 127.0.0.1:3080 で起動すると説明されています。これは、同じ Mac 上で複数の利用者や複数の実行環境を扱う場合、Preset の配置を単なる保存先ではなく、実行境界として管理すべきことを示します。(github.com)
個人の試験と高速な改変はユーザーレベル、チームに配布する標準ワークフローはシステムレベルに置いてください。共有 Mac では「システムレベルの読み取り専用基線＋ユーザーレベルの限定的な拡張」が最も扱いやすい構成です。
この判断で迷っている開発者、チーム向けの Agent Preset を配布するプラットフォーム担当者、共有またはクラウド上の Mac で書き込み権限と変更監査を管理するセキュリティ担当者が対象です。個人の設定を残しながら、他の利用者の実行条件を壊したくない場合にも使える考え方です。
SECTION 01DeepSeek Harness Agent Preset の信頼境界
Agent Preset のシステムレベルとユーザーレベルの違いは、ディレクトリの見つけやすさではありません。どの配布元を信頼し、誰が変更を承認し、事故が起きたときに誰が元へ戻すかという責任の違いです。
公式の設定カタログでは、Preset のスキャン対象に複数の root を指定でき、root ごとに system または user の信頼属性を記録できます。ユーザールートの Preset は、利用者本人だけでなく、ローカルの Agent が作成した可能性もあるため、正常に読み込めたことだけを理由に、チーム基線として扱ってはいけません。(github.com)
また、DeepSeek Harness は Cordis の上で動作し、モデルアダプター、ツールレジストリ、セッションログ、Agent Loop などもプラグインとして構成されます。そのため、Preset は見た目を切り替える設定ではなく、実行時にどのサービス構成を組み立てるかを決める構成単位です。(github.com)
ここで、Agent Preset と次の概念を混同しないでください。
- 権限プリセット：ファイル操作やシェル実行など、許可範囲を決めるポリシーです。
- Plan Mode：作業を計画中心で進める実行モードです。
- Skills：Agent が発見して利用する機能や手順の単位です。
- Agent Preset：複数のサービスや設定行を組み合わせた Agent の構成です。
権限プリセットを厳しくしても、Agent Preset の出所や上書き責任が明確になるわけではありません。逆に、信頼できる Agent Preset でも、シェルやファイル操作の権限設定が適切とは限りません。
注意：Preset に API キー、顧客固有のパスワード、個人の認証情報を埋め込まないでください。Preset は配布物として扱い、認証情報はアカウントまたは秘密情報管理の別レイヤーに分離します。
SECTION 02同名 Agent Preset とスキャン順序
DeepSeek Harness の設定カタログでは、Preset root は優先順位付きで走査され、同じ ID が複数の root にある場合は、先に走査された root の定義が優先されます。ユーザールートを有効にする設定も、構成済み root の後ろにユーザールートを追加する動作として定義されています。(github.com)
したがって、同名 Agent Preset が読み込まれる順序は、画面に表示された名称から推測してはいけません。設定ファイル上の roots の順序、ユーザールートの有効状態、各 root に付与された trust 属性を記録してください。
DeepSeek Harness 自動 Preset の配置先を確認する場合は、次の順で調べます。
- 使用中の Release とコミットを固定します。Developer Preview では互換性を壊す変更があり得るため、バージョンを記録しない調査結果は再現性がありません。(github.com)
- 現在の設定カタログで
@deepseek-ai/dsh-agent-presetsのroots、default、includeUserRootを確認します。 - 実際に起動するプロファイルを決め、
dsh --profile <profile> --dump-configで起動時の構成を出力します。公式アーキテクチャ文書も、このコマンドで実際の起動ツリーを確認する方法を案内しています。(github.com) - system root と user root に、内容を含まない検証用の同名 Preset を一時的に置きます。
- 出力、ログ、Preset 内の識別用フィールドを照合し、どちらが有効になったかを記録します。
- 検証用 Preset を削除し、同名 ID の重複を本番環境に残さないことを確認します。
この最小同名テストは、ディレクトリを推測するより確実です。特に、運用担当者が異なる Mac に手作業でコピーした場合、設定ファイルの見た目が同じでも、実際には別 root が先に読み込まれている可能性があります。
経験則：同名衝突を「あとで確認すればよい問題」として残すと、変更後にどの Preset が効いたのか説明できなくなります。チーム配布では、ID に世代名を含めるか、同名を禁止する検査を先に入れてください。
SECTION 03システムレベルとユーザーレベルの運用分担
システムレベルは、複数のアカウントや再構築された Mac でも同じ構成を再現したい場合に向いています。チームが必ず使うツール構成、標準的な Agent の組み合わせ、監査対象となる実行フローは、システムレベルの読み取り専用 Preset として配布します。
ただし、システムレベルに置いただけでは標準化になりません。次の証跡が必要です。
- 配布元のリポジトリまたはアーカイブの識別子
- 適用した Release またはコミット
- Preset の ID と想定される trust 属性
- root のスキャン順序
- ファイル所有者と書き込み権限
- 同名検証の結果
- 直前の回退版と復元手順
一方、ユーザーレベルに残すべきなのは、個人の試験的な Agent 構成、短期のツール組み合わせ、作業者だけが使うプロンプト調整です。個人の変更をすぐ試せる利点がありますが、チームの安全境界、顧客プロジェクトの分離、標準納品条件をユーザーレベルに置くと、利用者ごとの差分が見えにくくなります。
公式アーキテクチャでは、プロファイルに登録された bundle、プロファイルの cordis.patch.yml、Harness home 側の設定、起動時の patch overlay が順序付きで適用されます。つまり、Preset だけでなく上位レイヤーの patch も実行結果を変えるため、Preset のファイルだけをバックアップしても完全な回退証拠にはなりません。(github.com)
SECTION 04共有 Mac の書き込み責任
共有 Mac で利用者に既定 Preset の自由な変更を許すと、三つの問題が起きます。
- アカウント間の再現性が崩れること：同じ名前の Preset でも、ユーザー root の内容によって実行結果が変わります。
- 顧客プロジェクトの境界が曖昧になること：ある利用者が追加したツールやパスが、別の利用者の作業に混入する可能性があります。
- 事故後の回収が遅れること：書き込み元が複数あると、どの変更を取り消せばよいか判断できません。
共有 Mac の治理方式は、次の三段階で選びます。
- システムレベル読み取り専用基線：チーム共通の Preset は管理者だけが更新し、利用者は読み取りだけにします。最初に選ぶ方式です。
- ユーザーレベルの限定的拡張：個人実験を許可しますが、ID、認証、顧客データに関わる設定は変更対象から外します。
- 完全な環境分離：顧客ごとにアカウント、Harness home、ワークスペース、Preset root を分けます。監査要件や顧客間の分離要件がある場合は、同じ root を共有しないでください。
判断を迷ったら、次の条件分岐を使います。
- 個人だけが使い、失敗しても本人の環境だけを戻せばよいなら、ユーザーレベルを選びます。
- 複数の利用者が同じ Agent 構成を使い、再インストール後も同じ状態が必要なら、システムレベルを選びます。
- 標準構成を維持しながら、個人の試験も許可したいなら、システムレベルの読み取り専用基線とユーザーレベルの限定拡張を組み合わせます。
- 利用者や顧客ごとに回退責任が異なる、または事故時に即時回収が必要なら、共通 root の利用をやめ、アカウントまたは環境を分離します。
- Preset の変更が安全ポリシー、認証、顧客データへのアクセスに影響するなら、ユーザーレベルへの書き込み許可には戻さず、管理者承認を必須にします。
SECTION 05配布方式の比較
| 判断項目 | システムレベル | ユーザーレベル | 二層構成 |
|---|---|---|---|
| 主な用途 | チーム標準、再構築可能な環境 | 個人実験、短期の試行 | 共有 Mac、標準と自由度の両立 |
| 信頼の扱い | 管理者が出所を確認 | 個人または Agent 作成の可能性 | 基線は管理者、拡張は個人 |
| 書き込み権限 | 原則として管理者のみ | 利用者に許可しやすい | system は読み取り、user は範囲限定 |
| 同名 ID の扱い | 重複を禁止または検査 | 衝突しやすい | system の優先順を固定し、user の衝突を監視 |
| 回退 | 版管理と再配布が可能 | 利用者ごとの確認が必要 | 基線を戻し、個人拡張を無効化 |
| 向かない場面 | 個人の頻繁な試行 | チーム必須の安全境界 | 完全な顧客分離が必要な環境 |
DeepSeek Harness は開発者プレビューとして更新が速く、公式リポジトリも互換性を壊す変更があり得ると明記しています。運用環境では、構成カタログ、Release、同名検証の三つを同じ変更記録に残してください。(github.com)
個人の作業用 Mac であれば、ユーザーレベルに置くことで試行錯誤は速くなります。しかし、共有 Mac や短期利用のリモート Mac では、手作業コピー、所有者不明のファイル、検証されていない同名 Preset が残りやすく、再構築時の確認項目が増えます。環境を都度用意する場合は、MACNOX の Mac 利用案内と、利用料金と構成の確認ページを見ながら、必要な期間とアカウント分離の条件を先に決めてください。
自前の共有 Mac で同じ root を使い続ける方式は、初期費用を抑えられる一方で、書き込み責任が曖昧になり、同名衝突の調査、利用者ごとの差分回収、事故後の環境清掃が運用負担として残ります。短期の検証、チーム向けの再現環境、利用者を分けたリモート Mac が必要なら、MACNOX のレンタル環境を選ぶほうが、少なくとも「誰が変更したか」と「どの環境を戻すか」を切り分けやすくなります。長期の固定負荷や物理インターフェースが必要な案件では自前の Mac が適しますが、期間限定の算力や安全な試験環境を求めるなら、二層 Preset とアカウント分離を前提に構成するのが現実的です。