共有バックエンドを多人向けの隔離機能と見なさず、別々の課題プロジェクトを同じmacOSユーザーのセッションで扱わないでください。OSアカウント、作業フォルダ、認証情報、遠隔接続の範囲を検証できる場合に限り、同じMacを使う構成を候補にします。
この記事の対象は、OpenCode 2.0を複数人で使うか判断する課題グループの責任者、アカウントやサービスを管理する研究室の管理者、個人環境からチーム利用へ移行する研究ソフトウェア開発者です。
最終更新：2026年11月3日。OpenCodeのV2公式文書と公式変更記録を確認しています。機能や接続方法は更新で変わるため、実運用前にもCLI文書と公式変更記録を照合してください。
OpenCode 2.0を複数人で共用するMacでは、何が共有されるのか
「同じMacを使う」ことと「同じアプリケーションの状態を使う」ことは別です。OpenCode V2の公式文書では、既定の共有バックエンドサービスが、現在のユーザーアカウントに対してセッション、設定、連携機能、権限、ツール実行を管理すると説明されています。CLIの共有サービスの説明を根拠にできるのはここまでです。多人の利用者を自動で隔離するという保証ではありません。
| 利用形態 | 境界として確認するもの | 判断の目安 |
|---|---|---|
| 1つのmacOSアカウントを複数人で使う | 同一ユーザーのセッション、設定、ファイル、認証情報 | 異なる課題の同時利用には避ける |
| macOSの別アカウントで使う | ログインユーザー、各ユーザーのサービス接続先、ファイル権限 | 各アカウントからの分離を実地確認する |
| 複数のクライアントから同じOpenCodeサービスへ接続する | 接続先サーバー、共有サービスの利用者、セッション表示範囲 | クライアントが別でも隔離済みとは判断しない |
OpenCode V2のCLI文書は、standaloneでの利用と、指定したサーバーへの接続方法を説明しています。つまり、接続方法が異なることは確認できますが、それだけで利用者ごとのセッション境界があるとは言えません。チーム導入前に、V2の設定項目と実際の接続先を確認してください。
セッションと設定の混在は、利用者と接続先から切り分けます
「各自が別のクライアントを開いている」だけでは、セッションや設定の共有範囲は判定できません。まず、ログイン中のmacOSユーザー、接続しているサービス、表示されるセッション、読み込まれる設定ファイルをそれぞれ記録します。
[ ] macOSのログインユーザー名を利用者ごとに確認する
[ ] OpenCodeクライアントが接続するサービスのアドレスを確認する
[ ] それぞれの利用者でセッション一覧を開き、別利用者の作業が表示されるか確認する
[ ] 設定ファイルの場所と所有ユーザーを確認する
[ ] 読み取り専用のテスト用プロジェクトで、設定変更がどこに反映されるか確かめる
確認結果は、操作したmacOSアカウントと接続先をセットで記録してください。同じ画面や同じセッションが見える場合は、別のクライアントを使っていることを隔離の根拠にしないでください。V2の権限の説明は公式の権限文書で確認できますが、アプリ内の許可設定とOSのアカウント境界は別のものです。
作業フォルダの取り違えは、セッション分離だけでは防げません
サービスが別のセッションを扱っていても、利用者が同じ作業コピーを開けば、変更は同じファイル群に書き込まれる可能性があります。共有バックエンドのセッション境界と、ファイルシステム上のプロジェクト境界を分けて検証します。
| 確認対象 | 混線につながる状態 | 導入前に行う確認 |
|---|---|---|
| 作業パス | 別の課題のディレクトリを誤って開く | 起動時のパスを記録し、対象プロジェクトと照合する |
| Git作業コピー | 複数人が同じ作業コピーを変更する | テスト用リポジトリでブランチと変更内容を照合する |
| 出力先 | 解析結果や生成物が共有ディレクトリに書き込まれる | 出力先と書き込み権限を利用者ごとに確認する |
検証には、機密情報を含まないテスト用リポジトリを使います。別々の利用者で作業パス、ブランチ、ファイル変更、出力先を確認し、意図しない共有があれば実データを置く前に止めてください。作業コピーを分ける方法としては、Git公式のgit worktree説明を参照できます。ただし、worktreeを分けてもmacOSの認証情報やサービス接続先まで分離されるわけではありません。
認証情報とコマンド権限はOSユーザーの境界で点検します
OpenCodeの権限設定だけを見て、他の利用者からファイルやキーが見えないと判断するのは危険です。同じmacOSユーザーとして操作できる人は、そのユーザーがアクセスできるファイルや環境変数、設定済みの提供者認証情報にもアクセスできる可能性があります。
[ ] OpenCodeのコマンド実行権限を確認する
[ ] 環境変数と提供者の認証情報が保存されている場所を確認する
[ ] テスト用の秘密情報を使い、別アカウントから読み取れるか確認する
[ ] 共有ディレクトリと個人ディレクトリのアクセス権を確認する
[ ] 実験データや認証情報を扱う前に、研究機関のルールと照合する
macOSではユーザーを追加でき、ファイルやフォルダにはアクセス権を設定できます。それぞれの手順はMacへのユーザー追加に関するAppleの案内、ファイル共有の設定、ファイルとフォルダのアクセス権で確認できます。アプリ内の許可設定をOSユーザーの分離と同一視せず、実際のファイルアクセスで確かめてください。
遠隔接続では、公開範囲と認証を別に検証します
OpenCodeの遠隔接続は、サービスを有効にしたかどうかを先に確認します。公式のWeb・遠隔サービス文書で現在の設定方法を確認し、本機だけの接続、研究室内のネットワークからの接続、外部からの接続を混同しないようにします。
接続先の待ち受け範囲、認証の有無、接続を許す送信元をそれぞれ確認します。パスワード設定や暗号化通信があっても、研究機関のデータ管理審査やアクセス承認に代わるものではありません。設定名や挙動を過去の手順から決めつけず、利用するOpenCodeのバージョンに対応した公式文書と変更記録を照合してください。
共用アカウントか分離アカウントかを条件で決めます
利用形態は、次の条件分岐で決めてください。確認できない境界が残る場合は、同じユーザー会話で複数課題を扱わず、アカウントまたは環境を分けます。
- 単独利用で、作業データと認証情報が本人だけの管理下にある場合は、既定のサービス接続をテストしてから利用します。
- 同じMacを複数人が使い、OSアカウント、作業フォルダ、認証情報、接続先を個別に検証できる場合は、分離アカウントでの利用を候補にします。
- 同じOSアカウントを共有する必要がある場合、またはセッションやファイルの境界を証明できない場合は、異なる課題の作業を同じ利用環境に置かないでください。
- 遠隔接続を使う場合、アクセス元と認証の範囲が承認済みか確認できなければ、サービスを外部向けに有効化しないでください。
- 研究データの扱いが機関の規則に合うか判断できない場合は、管理者や情報セキュリティ担当者に確認するまで実データを置かないでください。
導入後も、OpenCodeのバージョン変更時や公式のサービス・認証機能の変更時には、接続先、セッション表示、ファイルアクセスを再確認します。サービスが動くことと、多人利用の境界が適切であることは別々に記録してください。
研究室の既存Linux・Windows環境を使い続ける方法は、予算を抑えやすい一方、macOS専用ツールの実行環境がなく、共有サーバーの権限設計や課題ごとの作業領域管理も必要です。交互利用の単一Macでは、利用者が同じアカウントを使うと認証情報や作業ファイルの境界が曖昧になりやすくなります。macOSを使えるホスト自体が必要な場合は、metalvncの東京環境に関する案内や料金・利用プランを確認し、研究機関のデータ規則とアカウント分離を先に検証してください。レンタルMacは作業環境の選択肢であり、それだけで多人隔離やデータの適合性が保証されるわけではありません。
作業環境を分けて、チーム開発をより安心に
metalvncなら、物理マシンを専有できる開発環境を用意し、共有ホストによるリソースの競合を避けられます。