最終更新：2026年8月18日。公開されているDeepSeek HarnessのREADMEでは、セッション保存、ワークスペース内に操作範囲を制限する仕組み、用途別に分けられた3種類のProfileが示されています。(github.com)
この構成から導ける結論は明確です。依存関係が近く、同時実行が少なく、データの権限領域も同じ個人プロジェクトなら、1台のMacで共用して構いません。ただし、作業フォルダー、セッション、設定、認証情報は分けます。顧客コード、長期Agent、プラグインの衝突、異なる権限領域がある場合は分離を優先します。
この判断が必要な人
独立開発者は、試用コストを抑えながらプロジェクトの文脈混在を避けたい場面で役立ちます。小規模チームは、共有環境の手軽さと担当範囲の分離を比較できます。
安全性を重視するチームは、リポジトリ数ではなく、データ、認証情報、承認、障害対応の責任者が同じかどうかを確認してください。
DeepSeek Harness複数プロジェクト展開の判断軸
判断の基準は、保有するリポジトリの総数ではありません。重要なのは、同じ時間帯に何個のタスクが動くか、1つのタスクがどれだけ長くセッションを占有するか、失敗時に再実行やログ確認がどれだけ発生するかです。
たとえば、午前中に順番にコードレビューを実行する構成なら、同じMacを使っても競合は限定的です。しかし、複数のAgentが同時にファイルを変更し、テスト、ビルド、外部ツール呼び出しを継続する場合、プロセスとセッションの管理責任が急に重くなります。
Gitのworktreeは、1つのリポジトリから複数の作業ツリーを持つための仕組みです。ブランチごとの作業場所を分けるには有効ですが、リポジトリ設定の一部は共有されるため、これだけで完全な環境分離になるわけではありません。(git-scm.com)
mkdir -p ~/dsh-workspaces/{personal,client-a,internal}
git clone "$REPO_URL" ~/dsh-workspaces/client-a/main
cd ~/dsh-workspaces/client-a/main
git worktree add ../client-a-hotfix hotfix
git worktree list
出力例：
/Users/dev/dsh-workspaces/client-a/main abc1234 [main]
/Users/dev/dsh-workspaces/client-a/client-a-hotfix def5678 [hotfix]
ここで重要なのは、作業ツリーを増やすことではなく、Agentが現在どのパスを操作しているかを毎回確認できる運用です。誤ったディレクトリを選んだ場合は、処理を続けず、セッションを停止してから作業対象を修正するルールを設けます。
注意：フォルダー名にclient-aと書いてあっても、そこに顧客専用の認証情報やログ閲覧権限が自動で付与されるわけではありません。名前による区別と、実際のアクセス制御は別に設計します。
1台のMacで同時に複数プロジェクトを動かす場合
共用が適するのは、個人管理のリポジトリ、似た依存関係、同じ権限領域、短時間のタスクが中心となる構成です。空いているセッションを使い回せるため、導入時の管理対象を増やさず、プロジェクトごとに環境を複製する手間も抑えられます。
ただし、共用には少なくとも3つの隠れた制約があります。
- プロセスの競合：複数のAgentが同時にビルド、テスト、パッケージ導入を行うと、CPU、メモリ、ディスクI/Oの取り合いが起きます。
- セッションの混在：再開時に別プロジェクトの履歴を開くと、前提条件や変更方針を誤って引き継ぐ可能性があります。
- 設定の波及：共通Profileやプラグインを更新すると、安定稼働中の別プロジェクトまで動作条件が変わる場合があります。
したがって、共用を選ぶ場合は「同時に動くタスク」を先に整理します。プロジェクトが多くても順番に処理できるなら共用寄り、プロジェクトが少なくても長時間のAgentが常駐するなら分離寄りです。
共用を始めるための実施手順
- プロジェクト台帳を作成します。 リポジトリ、担当者、データ分類、利用する認証情報、常駐の有無を一覧にします。
- 作業パスを固定します。
~/dsh-workspaces/プロジェクト名/のように、プロジェクトごとにルートを分けます。 - セッション名を用途で分けます。 例として
client-a-review、internal-buildのように、顧客名や処理内容を含めます。 - Profileと設定ファイルを確認します。 共通設定に依存せず、プロジェクト単位でモデル、ツール、承認方法を確認できる状態にします。
- 開始時に対象パスを表示します。 Agentを起動する前に
pwd、Gitのブランチ、利用Profileを確認します。 - 誤選択時の停止条件を決めます。 対象パス、ブランチ、顧客名のいずれかが一致しなければ、ファイル操作や外部送信を実行しません。
- 失敗時の復旧担当を決めます。 セッションの再開、ログ確認、設定の差し戻しを誰が行うかを記録します。
この手順を省いて「同じMacだから便利」と考えると、問題が起きたときに、どのセッション、設定、プラグイン、認証情報が影響したのか追跡しにくくなります。
顧客コードと内部コードは権限領域で分けます
顧客プロジェクトを別フォルダーに置くだけでは、十分な境界とはいえません。顧客ごとにGitアクセス、クラウドサービス、デプロイ先、ログ、APIキーの権限が異なるなら、少なくともProfile、シェル環境、認証情報の保管場所を分ける必要があります。
macOSのKeychainは暗号化されたデータベースとして秘密情報を保存し、アプリごとのアクセス制御も扱えます。とはいえ、同じユーザーアカウントで複数プロジェクトを運用する場合、Agentやプラグインがどの認証情報を参照できるかは、利用するツールの実装と設定に左右されます。(developer.apple.com)
顧客コードを分離すべき典型例は次のとおりです。
- 顧客ごとに異なるGit、クラウド、デプロイ権限がある。
- 顧客契約上、ログやコードの閲覧者を限定する必要がある。
- 内部プロジェクトのAgentが、顧客リポジトリを参照する必要がない。
- 片方のプロジェクトで漏えい、誤削除、誤デプロイが起きた際に、もう片方を止めたくない。
リポジトリ単位のSSHキーや読み取り専用キーを使える場合は、個人アカウントの広い権限を共用環境へ置かずに済みます。単一リポジトリに紐づくデプロイキーという考え方は、権限を対象リポジトリへ限定する手段として説明されています。(docs.github.com)
ただし、独立環境に分けたから自動的に契約上の適合性が得られるわけではありません。 データの保存先、ログの保持、アクセス記録、バックアップ、管理者権限まで確認して初めて、分離の効果を評価できます。
プラグインと長期Agentは別の運用責任にします
プラグインの開発や更新を行う環境は、安定稼働を目的とする環境と相性がよくありません。インストール、更新、設定変更、起動処理のデバッグが、同じProfileやセッション管理に影響する可能性があるためです。
DeepSeek Harnessの公開READMEでは、Profileごとに利用ツールの構成を変えられる設計が示されています。core、corpus、fullのように用途別のツール集合を切り替える場合、どのプロジェクトがどのProfileを使うかを固定し、実験用の変更を継続タスクへ持ち込まないことが重要です。(github.com)
長期Agentも同じ考え方で扱います。短時間のコード整形やレビューは空きセッションで共用できますが、常駐監視、定期処理、継続的な調査を行うAgentは、プロセス、ログ、再起動、失敗時の通知を持続的に消費します。
次のどれかに該当する場合は、独立環境へ分ける判断が妥当です。
- そのAgentが停止すると別プロジェクトの納期や監視も止まる。
- 再起動や設定変更の担当者が他プロジェクトと異なる。
- 実験的なプラグインを頻繁に追加、削除する。
- 失敗時にセッション履歴やログを別チームへ渡す必要がある。
共用・分離・二重運用を決める比較表
下表では、プロジェクト数ではなく、同時実行、データ境界、設定変更、故障範囲、運用責任から判断します。
| 判断項目 | 1台で共用 | 分離して運用 | 二重運用 |
|---|---|---|---|
| 同時実行 | 順番に処理する | 複数タスクを継続実行する | 通常業務と実験を分ける |
| ワークスペース | 明確なパス分けが必須 | 環境ごとに固定しやすい | 重要案件だけ独立させる |
| 認証情報 | Profileと保管先を厳密に分ける | 権限領域ごとに管理しやすい | 顧客用だけ分離する |
| プラグイン | 安定版に限定する | 実験と本番を分けやすい | 実験用Macを別にする |
| 障害の影響 | 同じ環境へ波及しやすい | 影響範囲を限定しやすい | 重要処理の停止を避けやすい |
| 向いているケース | 個人、低リスク、低並行 | 顧客、長期Agent、権限分離 | 小規模チーム、移行期 |
同じリポジトリでも、担当者や権限領域が異なるなら分離対象です。反対に、別リポジトリでも、同じ担当者が順番に扱い、認証情報とデータ分類が共通なら、まず共用を試せます。
次の表は、今週の構成判断に使える条件表です。
| 条件 | 判定 | 推奨アクション |
|---|---|---|
| 依存関係が近く、同時実行が少ない | 共用候補 | ワークスペースとセッションを分けて開始 |
| 複数Agentが同じ時間帯に常駐する | 分離候補 | 長期Agent単位で環境を分ける |
| 顧客ごとに権限、秘密情報、ログ範囲が異なる | 分離 | 顧客または権限領域単位で分ける |
| プラグインを頻繁に試す | 二重運用 | 安定環境を残し、実験環境を別にする |
| 1つの障害が他案件を止める | 分離 | 故障ドメインを分ける |
| 誰が更新、承認、ログ確認を行うか不明 | 分離 | 共有アカウントを増やさず責任範囲を先に定義 |
運用上の経験則として、分離のトリガーは「プロジェクトが増えた日」ではなく、「別のプロジェクトを止めずに変更、再起動、認証更新を行えなくなった日」です。
今週の推奨アクション
まず各プロジェクトに対して、次の5項目を記録します。
project:
data_boundary:
credential_domain:
concurrent_agent:
plugin_change_frequency:
failure_owner:
data_boundaryまたはcredential_domainが異なる案件、長期Agentが常駐する案件、プラグイン変更が多い案件は、共用候補から外します。残った低リスク案件だけを1台のMacへまとめ、順番実行から始めます。
その後、セッションの誤再開、対象パスの誤選択、設定変更の波及、再起動後の復旧手順を確認します。復旧担当が決まらない、または1件の失敗で他案件も停止するなら、プロジェクト数を増やす前に環境を分けるべきです。
長期的にMacを使う場合でも、用途別のMacレンタル構成と注文方法を確認し、顧客案件の実行場所を権限領域ごとに整理できます。地域や交付条件を比較したい場合は、東京向けのMac環境やシリコンバレー向けのMac環境も候補になります。
現在の構成が1台のローカルMacだけだと、同時実行時の資源競合、担当者交代時の設定引き継ぎ、故障時の全案件停止が起きやすくなります。反対に、案件ごとに無計画にMacを増やすと、認証情報、更新、費用、監視対象が過剰になります。
そのため、短期の試用や検証、担当者別の作業環境、顧客ごとの権限領域を切り分けたい場合は、NodeMiniのクラウドMacを「リポジトリ数」ではなく「同時稼働するタスク数」と「独立させる権限領域数」で相談するのが現実的です。長期の安定した重負荷処理や物理インターフェースが必要な用途では自前Macが適しますが、構成を試しながら分離条件を検証する段階では、必要な環境だけをレンタルする方が責任範囲を整理しやすくなります。