「前の担当者のHarnessがまだ動いている」「どのAPI Keyで実行されたか分からない」という状態なら、共通アカウントのまま長期運用してはいけません。
低機密のリポジトリを短期間だけ扱う場合は、専用の共通アカウントでも運用できます。複数人が継続利用し、個人の認証情報、顧客別リポジトリ、操作責任を扱う場合は、1人1アカウントに分けてください。顧客や信頼境界が異なる場合は、アカウント分離だけでなくMac環境自体を分けます。
[ SECTION_01 ] この記事の対象者
一台のクラウドMacを複数の開発者へ順番に渡し、どの構成で運用するか決めたいチーム責任者向けです。
DeepSeek Harnessの継続プロセスを管理し、個人アカウントとサービスアカウントの境界を決めたい運用担当者にも適しています。顧客リポジトリ、署名証明書、複数のAPI Keyを扱うセキュリティ担当者は、共用を拒否すべき条件を確認してください。
[ SECTION_02 ] 画面のログイン記録だけでは実行者を特定できません
DeepSeek Harnessの画面やサービス側のログイン履歴に担当者名が残っていても、それはmacOS上でコマンドを実行したユーザーを証明する記録とは限りません。DeepSeekの公式API資料は、API Keyを使ったモデル呼び出しや外部ツールの実行を説明していますが、チームで共用するmacOSアカウントへの安全性を保証していません。(api-docs.deepseek.com)
典型的な失敗は次の順番で起きます。
- 開発者Aが作業ディレクトリでHarnessを起動します。
- Aが画面を閉じても、バックグラウンド処理や子プロセスが残ります。
- 開発者Bが同じアカウントでログインし、別のリポジトリを開きます。
- Bの操作が旧プロセスの作業領域やAPI Keyに紐づきます。
- 事故後に画面の履歴を見ても、AとBの操作を確実に分離できません。
そのため、チームでは「画面上の利用者」ではなく、「macOSアカウント、Harnessプロセス、リポジトリ、認証情報」の対応関係を記録します。
一時的な共用を認める場合も、最低限次の条件が必要です。
- 低機密のリポジトリだけを扱う
- 個人用API Keyを保存しない
- 作業開始時と終了時に担当者、目的、リポジトリを記録する
- Harnessのプロセスを終了し、次の担当者へ引き継ぐ
- 交代後に旧セッション、環境変数、作業ディレクトリを確認する
この5項目を毎回実施できないなら、共用アカウントは採用しません。
[ SECTION_03 ] DeepSeek Harnessをチームで共用するMacで最初に見るべき5つの境界
1. Keychainと環境変数
macOSのKeychainは、パスワードや証明書などの機密情報を管理する仕組みです。Appleの資料でも、Keychainの保護にはログインパスワードが関係し、ログイン用Keychainのロック設定もユーザー単位で扱われます。(support.apple.com)
共通アカウントでは、複数人が同じユーザーコンテキストに入りやすくなります。さらに、シェルの環境変数やプロジェクト内の設定ファイルまで同じ場所に置くと、別の担当者が以前の認証情報を読み込む可能性があります。
認証情報は3種類に分けて扱います。
- 個人API Key：個別のmacOSユーザーに紐づけ、退職時に本人分だけ無効化します。
- チームサービス用Key：専用サービスアカウントに置き、読み取り担当者と停止担当者を決めます。
- コード署名材料：顧客や製品の信頼境界に直結するため、共通アカウントへ置かない運用を基本にします。
判断基準は単純です。Keyの所有者、読み取り者、撤回者を1人ずつ特定できない場合は、アカウントを分けます。
2. ホームフォルダとリポジトリ
macOSはユーザーごとにホームフォルダを持ち、他のユーザー用ホームフォルダや共有領域とは区別します。ファイルやフォルダの読み取り、書き込み、実行権限もユーザーやグループごとに設定できます。(support.apple.com)
しかし、同じホームフォルダ内で名前だけを変えても、アクセス制御にはなりません。例えば、client-a、client-bとフォルダ名を分けても、同じユーザーでログインしていれば、設定、プラグイン、会話ログ、キャッシュを横断して読める場合があります。
次のどれかに該当する場合は、macOSユーザーアカウントを分けます。
- 顧客や案件ごとに守秘義務が異なる
- リポジトリの書き込み権限が担当者ごとに異なる
- Harnessの会話ログに設計情報や顧客情報が含まれる
- プラグインやMCP設定を担当者ごとに変える
- 口頭のフォルダ命名ルールが主な防御になっている
顧客間の信頼境界まで分ける必要がある場合は、個別アカウントだけでは不十分です。専用Mac、仮想環境、または別のクラウドMacへ移します。
注意：ユーザーアカウントの分離は、完全なテナント分離ではありません。管理者権限、共有フォルダ、バックアップ、管理ツール、物理またはコンソールアクセスが残っていれば、上位権限から複数環境へ到達できる可能性があります。
3. セッションログと操作責任
DeepSeek Harnessでは、会話の内容だけでなく、どの作業ディレクトリで何のツールを実行したかが重要です。セッションログが共通の保存先に集まると、別の担当者が過去の指示や出力を読み取ったり、誤って再開したりします。
ログに必要なのは、単なる日時ではありません。
- 担当者またはサービスアカウント
- macOSユーザー名
- リポジトリ識別子
- Harnessの起動方法
- 使用した認証情報の識別子
- 開始、終了、引き継ぎの時刻
- 失敗時の停止者
サービス側のログイン記録は、macOS上のファイル変更者やプロセス所有者を自動的に証明するものではありません。事故調査で必要なのは、画面履歴とOS上の実行主体を結び付ける記録です。
4. 交代後も残るバックグラウンド処理
macOSには、ログイン項目、起動エージェント、起動デーモンなど、ユーザーの画面を閉じた後も動作し得る仕組みがあります。Appleはバックグラウンドタスクの登録状況を確認し、コンソールなどで活動を監視する管理方法を案内しています。(support.apple.com)
したがって、ブラウザを閉じることやリモート画面から切断することを、身份切り替えの完了条件にしてはいけません。運用台帳には、次の4項目を登録します。
- プロセスの所有者
- 起動方式
- 停止または再起動する入口
- 別担当者が引き継ぐための確認条件
交代時には、プロセス一覧、作業ディレクトリ、環境変数、ログ出力先を確認します。旧担当者のKeyを保持したプロセスが残っていれば、次の作業を開始しません。
5. 離職時の回収単位
共通アカウントの最大の弱点は、1人だけを無効化しにくいことです。共通パスワードを変更すると全員が止まり、変更しなければ退職者がアクセスできる状態が残ります。
Appleのファイル権限は、ユーザーやグループ単位で設定できます。つまり、最初から個別アカウントを使えば、ファイル、共有フォルダ、リポジトリへの権限を個人単位で整理しやすくなります。(support.apple.com)
受け入れ時の質問は、「退職者のアカウントだけを削除して、他のタスクを止めずに済むか」です。答えが「共通パスワードを変えて全員を再設定する」なら、回収粒度が粗すぎます。
[ SECTION_04 ] 構成は4段階で決めます
以下の条件分岐を、導入前の判断工具として使います。
- 低機密、短期、個人Keyなし、毎回の引き継ぎを記録できる
→ 専用の共通アカウントを選びます。終了時のプロセス停止と作業領域の確認を必須にします。 - 複数人が継続利用し、担当者別の追跡が必要
→ 1人1つのmacOSユーザーアカウントにします。リポジトリ、Keychain、環境変数、ログをユーザー単位で分けます。 - 定期実行、常駐処理、CIに近い自動処理を動かす
→ 専用サービスアカウントを選びます。個人のログイン情報を入れず、停止担当者と再起動手順を固定します。 - 顧客、契約、署名証明書、規制対象データなどの信頼境界が異なる
→ Mac環境を分けます。個別アカウントだけで済ませる判断は拒否します。
この分類の評価を5点満点で行うと、共通アカウントは「短期性」「低機密性」「引き継ぎ可能性」の3項目を満たす場合だけ合格です。個別アカウントは「個人Key」「担当者別監査」「離職時の個別撤回」の3項目で優位です。環境分離は運用負荷が高い一方、顧客間の境界を最も明確にできます。
[ SECTION_05 ] 運用開始前に行う6段階の確認
1. 対応関係を一枚にまとめる
「担当者—macOSアカウント—Harnessプロセス—リポジトリ—認証情報」を一覧化します。空欄がある項目は、運用開始前に埋めます。
2. 認証情報を分類する
個人Key、サービスKey、署名材料を分けます。Keyの所有者、読み取り者、撤回者をそれぞれ記録します。
3. 作業領域を分ける
ホームフォルダ、リポジトリ、設定、会話ログ、プラグイン、キャッシュの保存先を確認します。フォルダ名を変えただけの分離は合格にしません。
4. 起動経路を確認する
手動起動、ログイン時起動、バックグラウンドタスク、スケジューラーなどを洗い出します。プロセスごとに所有者と停止方法を記録します。
5. 最小タスクで交代試験をする
担当者Aが低リスクの変更を開始し、担当者Bへ引き継ぎます。BがAのKey、セッション、作業領域へ意図せず到達できないことを確認します。
6. 撤回と復旧を実演する
対象者のアカウント、Key、リポジトリ権限、常駐プロセスを回収します。その後、残ったメンバーの作業を再開します。ここまで実演できて初めて、アカウント構成を承認します。
クラウドMacを導入する場合は、先にクラウドMacの利用環境を確認することで、接続方式と運用担当の境界を整理できます。Mac本体の候補を比較する段階では、Mac miniのレンタル構成も確認しておくと、アカウント分離だけで解決できない性能や環境分割の判断がしやすくなります。
[ SECTION_06 ] 共用アカウントよりMac環境を分けるべきケース
次の条件では、個別アカウントへ移すだけでは不十分です。
- それぞれの顧客が別の契約上の管理主体である
- 署名証明書や配布資格情報を顧客ごとに保持する
- 管理者権限を持つ運用担当者が複数いる
- バックアップやスナップショットに複数顧客のデータが混在する
- Harnessのプラグインやツールが強いファイルアクセス権を持つ
- 退職時に環境全体を停止せず、対象者だけを確実に切り離す必要がある
個別アカウントは、責任の帰属と日常の誤操作を改善します。しかし、管理者権限、共有領域、バックアップ、監視基盤まで分離するものではありません。異なる信頼境界を守る目的なら、専用Macまたは独立したクラウドMacを選びます。
[ SECTION_07 ] 共用Macから移行する判断
共通アカウントの利点は、初期設定と引き継ぎが簡単なことです。一方で、個人の操作を追跡しにくく、Keychainや環境変数の境界が曖昧になり、停止漏れのあるHarnessプロセスが次の担当者へ影響します。退職者のアクセスだけを回収しにくい点も、長期運用では大きな欠点です。
そのため、短期の検証なら共通アカウントを条件付きで使い、継続開発へ移る時点で個別アカウントへ切り替える構成が現実的です。顧客や署名材料の境界がある場合は、最初からMac環境を分けます。専用機をすぐ購入せず、期間限定の開発環境や移行確認が必要なら、NOVAKVMのMacレンタルを比較対象に入れると、共通アカウントのまま無理に運用するより、責任単位を切り出しやすくなります。
よくある質問
複数人でDeepSeek Harnessを使う場合、1つのMacアカウントでも問題ありませんか？
低機密のリポジトリを短期間だけ扱い、API Keyを個人単位で持たず、作業開始と終了の記録を必ず残せるなら、専用の共通アカウントで運用できます。ただし、長期利用、顧客情報、署名証明書、複数の個人用認証情報が入る場合は、共通アカウントを避ける判断が安全です。
リモートMacで開発者ごとにAPI Keyを分けるにはどうしますか？
開発者ごとにmacOSユーザーアカウントを分け、Keychain、シェル環境変数、Harnessの設定ファイル、作業ディレクトリを各ユーザーのホーム領域に分離します。共有フォルダへKeyや会話ログを置かず、誰が読み取り、誰が無効化するかを台帳に記録してください。
DeepSeek Harnessのサービスアカウントと個人アカウントはどう使い分けますか？
人が対話しながら修正する作業は個人アカウント、定期実行や常駐処理は専用サービスアカウントに分けます。サービスアカウントには個人のAPI Keyや個人用リポジトリを入れず、起動方法、所有者、停止手順、ログの保存先を明示します。
チームメンバーの退職後、Agent環境をどう回収すればよいですか？
最初に対象者のMacアカウント、API Key、SSH鍵、リポジトリ権限、Harnessの常駐プロセスを一覧化します。その後、認証情報を無効化し、プロセスを停止し、ログと引き継ぎ記録を保全します。1人だけを削除して他の作業を止めずに済むかを、運用開始前に実演できる状態が合格基準です。