{"meta":{"title":"マルチテナントとサーバーの展開","intro":"マルチユーザー サーバー モードとは、複数の人間、テナント、ワークスペース、または統合アカウントにサービスを提供するバックエンド コードから Copilot SDK を実行することを意味します。 このセットアップでは、アプリケーションは要求のルーティングと承認を所有しますが、SDK とランタイムはセッションごとの状態、セッションごとの認証、および明示的なツール登録を提供するため、あるユーザーのセッションが別のユーザーのツールまたは ID を継承しません。","product":"GitHub Copilot","breadcrumbs":[{"href":"/ja/copilot","title":"GitHub Copilot"},{"href":"/ja/copilot/how-tos","title":"方法"},{"href":"/ja/copilot/how-tos/copilot-sdk","title":"Copilot SDK"},{"href":"/ja/copilot/how-tos/copilot-sdk/setup","title":"Copilot SDK を設定する"},{"href":"/ja/copilot/how-tos/copilot-sdk/setup/multi-tenancy","title":"マルチテナンシー"}],"documentType":"article"},"body":"# マルチテナントとサーバーの展開\n\nマルチユーザー サーバー モードとは、複数の人間、テナント、ワークスペース、または統合アカウントにサービスを提供するバックエンド コードから Copilot SDK を実行することを意味します。 このセットアップでは、アプリケーションは要求のルーティングと承認を所有しますが、SDK とランタイムはセッションごとの状態、セッションごとの認証、および明示的なツール登録を提供するため、あるユーザーのセッションが別のユーザーのツールまたは ID を継承しません。\n\n\n\n\n\n**次の場合に最適です。** 同時ユーザーを処理する SaaS 製品、パートナー統合、内部プラットフォーム、バックエンド サービス。\n\n## このガイドは、次の場合に使用します。\n\nビルドする場合は、次のガイドを使用します。\n\n* Copilotを利用するエージェントを埋め込むマルチユーザー SaaS 製品\n* Copilot Studio または Fabric スタイルのパターンのような、パートナー連携のバックエンド\n* 同時実行ユーザー、ワークスペース、テナント、または要求を処理するすべてのサーバー\n* 複数の SDK クライアントが 1 つの Copilot ランタイム プロセスに接続する共有ランタイム\n\nこのガイドは [スケーリングとマルチテナント](/ja/copilot/how-tos/copilot-sdk/setup/scaling) の姉妹です。 トポロジ、負荷分散、およびストレージ パターンについては、このガイドを使用してください。 SDK レベルのオプションとランタイム分離の選択肢については、このガイドを使用してください。\n\n## 主要な SDK オプション\n\n| オプション | 次の目的に使用します: | メモ |\n| ------------------------------- | ----------------------------------------- | ------------------------------- |\n| `mode: \"empty\"` | アンビエント OS ツールと CLI の既定値を無効にする | マルチユーザーまたは共有のシナリオに必要です。 |\n| `sessionIdleTimeoutSeconds` | アイドル状態のセッションのクリーンアップ | 実行時間の長いプロセスのサーバー側タイムアウトを設定します。 |\n| `baseDirectory` | ランタイム インスタンスごとの `COPILOT_HOME` の分離 | 既存のランタイムに接続するときに無視されます。 |\n| `sessionFs` | ローカル ディスクからセッション ファイル システム ストレージをルーティングする | セッションごとのファイルシステム プロバイダーとペアにします。 |\n| `RuntimeConnection.forUri(url)` | 既に実行されているランタイムの共有 | 言語名は異なります。以下のサンプルを参照してください。 |\n| セッションごと `gitHubToken` | 認証のスコープをリクエスト元のユーザーに限定する | これは、単一の共有ユーザー トークンよりも優先されます。 |\n\n### `mode: \"empty\"`\n\n`mode: \"empty\"` は、オプションの Copilot CLI の動作を既定で無効にします。 マルチユーザー サーバー モードでは、セッションがアクセスできるツール、MCP サーバー、スキル、ワークスペース パスをアプリケーションが明示的に決定する必要があるため、これは安全なベースラインです。\n\n共有サーバーには既定の `mode: \"copilot-cli\"` を使用しないでください。 このモードは、CLI に似たコーディング エージェントを対象としており、アンビエント ホスト ファイルシステムの機能を公開できます。\n\n
\n
TypeScript
\n\n```typescript\nimport { CopilotClient, RuntimeConnection } from \"@github/copilot-sdk\";\n\n// baseDirectory and sessionIdleTimeoutSeconds apply when the SDK spawns the\n// runtime. With RuntimeConnection.forUri(...) configure COPILOT_HOME and the\n// idle timeout on the runtime process itself.\nconst client = new CopilotClient({\n mode: \"empty\",\n connection: RuntimeConnection.forUri(process.env.COPILOT_RUNTIME_URL!),\n});\n\nconst session = await client.createSession({\n sessionId: `user-${user.id}-${crypto.randomUUID()}`,\n model: \"gpt-5.4\",\n availableTools: [\"custom:lookupOrder\", \"custom:createTicket\"],\n gitHubToken: user.githubToken,\n});\n```\n\n
\n\n
Python
\n\n```python\nfrom copilot import CopilotClient, RuntimeConnection\nfrom copilot.session import PermissionHandler\n\nclient = CopilotClient(\n mode=\"empty\",\n base_directory=f\"/var/lib/my-app/copilot/{runtime_instance_id}\",\n session_idle_timeout_seconds=900,\n connection=RuntimeConnection.for_uri(runtime_url),\n)\nawait client.start()\n\nsession = await client.create_session(\n session_id=f\"user-{user.id}-{request_id}\",\n model=\"gpt-5.4\",\n available_tools=[\"custom:lookupOrder\", \"custom:createTicket\"],\n github_token=user.github_token,\n on_permission_request=PermissionHandler.approve_all,\n)\n```\n\n
\n\n
Go
\n\n```golang\nclient := copilot.NewClient(&copilot.ClientOptions{\n Mode: copilot.ModeEmpty,\n BaseDirectory: fmt.Sprintf(\"/var/lib/my-app/copilot/%s\", runtimeInstanceID),\n SessionIdleTimeoutSeconds: 900,\n Connection: copilot.URIConnection{URL: runtimeURL},\n})\n\nsession, err := client.CreateSession(ctx, &copilot.SessionConfig{\n SessionID: fmt.Sprintf(\"user-%s-%s\", user.ID, requestID),\n Model: \"gpt-5.4\",\n AvailableTools: []string{\"custom:lookupOrder\", \"custom:createTicket\"},\n GitHubToken: user.GitHubToken,\n})\n```\n\n
\n\n
.NET
\n\n```csharp\nvar client = new CopilotClient(new CopilotClientOptions\n{\n Mode = CopilotClientMode.Empty,\n BaseDirectory = $\"/var/lib/my-app/copilot/{runtimeInstanceId}\",\n SessionIdleTimeoutSeconds = 900,\n Connection = RuntimeConnection.ForUri(runtimeUrl),\n});\n\nawait using var session = await client.CreateSessionAsync(new SessionConfig\n{\n SessionId = $\"user-{user.Id}-{requestId}\",\n Model = \"gpt-5.4\",\n AvailableTools = [\"custom:lookupOrder\", \"custom:createTicket\"],\n GitHubToken = user.GitHubToken,\n});\n```\n\n
\n\n
Java
\n\n```java\n// setCopilotHome and setSessionIdleTimeoutSeconds are ignored when\n// setCliUrl is used; configure those on the runtime process instead.\nvar client = new CopilotClient(new CopilotClientOptions()\n .setMode(CopilotClientMode.EMPTY)\n .setCliUrl(runtimeUrl)\n);\n\nvar session = client.createSession(new SessionConfig()\n .setSessionId(\"user-\" + user.id() + \"-\" + requestId)\n .setModel(\"gpt-5.4\")\n .setAvailableTools(List.of(\"custom:lookupOrder\", \"custom:createTicket\"))\n .setGitHubToken(user.gitHubToken())\n).get();\n```\n\n
\n\n
Rust
\n\n```rust\nuse std::path::PathBuf;\nuse github_copilot_sdk::{Client, ClientOptions, Transport};\nuse github_copilot_sdk::mode::ClientMode;\nuse github_copilot_sdk::types::SessionConfig;\n\nlet client = Client::start(\n ClientOptions::new()\n .with_mode(ClientMode::Empty)\n .with_base_directory(PathBuf::from(format!(\n \"/var/lib/my-app/copilot/{runtime_instance_id}\"\n )))\n .with_session_idle_timeout_seconds(900)\n .with_transport(Transport::External {\n host: runtime_host.to_string(),\n port: runtime_port,\n connection_token: None,\n }),\n).await?;\n\nlet session = client.create_session(\n SessionConfig::default()\n .with_session_id(format!(\"user-{}-{request_id}\", user.id))\n .with_model(\"gpt-5.4\")\n .with_available_tools([\"custom:lookupOrder\", \"custom:createTicket\"])\n .with_github_token(user.github_token),\n).await?;\n```\n\n
\n\n
\n\n### `sessionIdleTimeoutSeconds`\n\n非アクティブなセッションが自動的にクリーンアップされるように、サーバーに `sessionIdleTimeoutSeconds` を設定します。 これにより、実行時間の長いプロセスでのゾンビ セッションが防止され、メモリとファイル システムの負荷が軽減されます。\n\n| Language | パブリック オプション |\n| ---------- | ---------------------------------------- |\n| TypeScript | `sessionIdleTimeoutSeconds` |\n| Python | `session_idle_timeout_seconds` |\n| Go | `SessionIdleTimeoutSeconds` |\n| .NET | `SessionIdleTimeoutSeconds` |\n| Java | `setSessionIdleTimeoutSeconds(...)` |\n| Rust | `with_session_idle_timeout_seconds(...)` |\n\n製品の会話の有効期間に一致する値を使用します。 チャット バックエンドの場合、通常は 15 分から 30 分が適しています。 ワークフロー エージェントの場合は、ワークフローの完了時にタイムアウト時間が長くなり、明示的に削除されます。\n\n### `baseDirectory`\n\n`baseDirectory` は、ランタイム インスタンスの `COPILOT_HOME` を設定します。 これを使用して、プロセス、ポッド、ワーカー、またはテナントの境界ごとにランタイム状態、資格情報、セッション データを分離します。\n\n```typescript\nconst client = new CopilotClient({\n mode: \"empty\",\n baseDirectory: `/var/lib/my-app/copilot/runtime-${process.env.HOSTNAME}`,\n sessionIdleTimeoutSeconds: 900,\n});\n```\n\nランタイムは、`COPILOT_HOME`を含め、構成された`session-state/{sessionId}`の下にセッション状態を格納します。 アプリで複数のランタイム インスタンスを実行する場合は、意図的に共有ストレージを使用しない限り、各インスタンスに個別のディレクトリを指定します。\n\nSDK が `RuntimeConnection.forUri(url)` を使用してすでに実行中のランタイムに接続する場合、`baseDirectory` は SDK クライアントによって無視されます。 代わりに、ランタイム プロセスで `COPILOT_HOME` を構成します。\n\n### `sessionFs`\n\n`sessionFs` はカスタム セッション ファイルシステム プロバイダーを登録するため、セッション スコープのファイル I/O をランタイムのローカル ディスクではなくアプリケーション ストレージ経由でルーティングできます。 ローカル ディスクが一時的な場合、セッション状態がオブジェクト ストレージに存在する必要がある場合、またはプラットフォームでテナント対応のストレージ パスを適用する必要がある場合に使用します。\n\n```typescript\nconst client = new CopilotClient({\n mode: \"empty\",\n sessionFs: {\n initialCwd: \"/workspace\",\n sessionStatePath: \"/session-state\",\n conventions: \"posix\",\n },\n});\n```\n\nプロバイダー コールバックを公開する言語の場合は、クライアント レベルで `sessionFs` を構成し、セッションの作成時または再開時にセッションごとのファイルシステム ハンドラーを提供します。 永続化の概念とストレージのトレードオフについては、 [セッションの再開と永続化](/ja/copilot/how-tos/copilot-sdk/features/session-persistence) を参照してください。\n\n検証済みのパブリック SDK サーフェス:\n\n| Language | クライアント レベルの構成 | セッションごとのプロバイダー |\n| --------------------------------------- | ---------------------- | ------------------------------- |\n| TypeScript | `sessionFs` | |\n| `createSessionFsAdapter` / プロバイダーコールバック | | |\n| Python | `session_fs` | `create_session_fs_handler` |\n| Go | `SessionFS` | `CreateSessionFSProvider` |\n| .NET | `SessionFs` | `CreateSessionFsProvider` |\n| Rust | `with_session_fs(...)` | `with_session_fs_provider(...)` |\n\nJavaは現在、検証済みのパブリック `sessionFs` オプションを公開していないため、このガイドでは Java `sessionFs` サンプルは表示されません。\n\n### `RuntimeConnection.forUri(url)`\n\n複数の SDK クライアントが既に実行されている 1 つのランタイムを共有する必要がある場合は、外部ランタイム接続を使用します。 これは、ランタイム プロセスが要求ハンドラーとは別に管理されるバックエンド サービスで一般的です。\n\n| Language | 外部ランタイム接続 |\n| ---------- | ------------------------------------------------------ |\n| TypeScript | `RuntimeConnection.forUri(url)` |\n| Python | `RuntimeConnection.for_uri(url)` |\n| Go | `copilot.URIConnection{URL: url}` |\n| .NET | `RuntimeConnection.ForUri(url)` |\n| Java | `setCliUrl(url)` |\n| Rust | `Transport::External { host, port, connection_token }` |\n\n外部ランタイムは、独自のプロセス レベルの認証とストレージを管理します。 ユーザー固有の認証が必要な場合は、セッションごとのトークンを `createSession` または `resumeSession` に渡します。\n\n### セッションごと `gitHubToken`\n\n各セッションで `gitHubToken` を設定して、GitHub 認証の対象を要求元のユーザーに限定します。 これは、ランタイム プロセスを認証するクライアント レベルのトークンとは異なります。\n\n```typescript\nconst session = await client.createSession({\n sessionId: `user-${user.id}-support`,\n model: \"gpt-5.4\",\n availableTools: [\"custom:*\"],\n gitHubToken: user.githubToken,\n});\n```\n\nコンテンツの除外、モデル ルーティング、クォータ チェック、およびユーザー固有のCopilot アクセスには、セッションごとのトークンを使用します。 製品でサービス アカウント セマンティクスを意図的に使用しない限り、ユーザー間で 1 つのサービス トークンを共有しないようにします。\n\n## 統合ID\n\nブランド化されたエージェントを構築するパートナーは、Mission Control 要求の統合 ID を設定できます。 ランタイムは、`GITHUB_COPILOT_INTEGRATION_ID` を読み取り、すべての Mission Control 要求で `Copilot-Integration-Id` HTTP ヘッダーとしてスタンプします。\n\n```bash\nGITHUB_COPILOT_INTEGRATION_ID=my-product-agent copilot --headless --port 4321\n```\n\n既定の統合 ID は `copilot-developer-cli`。 属性やルーティングには、 `my-product-agent` などの安定した値を使用します。 統合 ID は現在、環境変数によってのみ構成されています。これは、ファースト クラスの SDK オプションではありません。\n\nSDK がランタイムを生成する場合は、クライアント環境オプションを使用して環境変数を渡します。\n`RuntimeConnection.forUri(url)`で接続する場合は、ランタイム プロセス自体に環境変数を設定します。\n\n## セッションレベルの分離保証\n\nセッション レベルの分離とは、ランタイムがグローバル共有状態ではなく、ユーザー固有のモデルと状態の情報をセッションのスコープに保持することを意味します。\n\n| Surface | 分離動作 |\n| ----------------------------------------------------- | -------------------------------------------- |\n| モデル リスト キャッシュ | セッションごと。 モデル検索では、セッションのモデル リスト キャッシュが使用されます。 |\n| セッションの状態 | |\n| `COPILOT_HOME/session-state/{sessionId}`配下のセッションIDごと。 | |\n| GitHub ID 情報 | |\n| `gitHubToken` がセッションに設定されている場合は、セッションごと。 | |\n| Tools | |\n| `mode: \"empty\"`では明示的、`mode: \"copilot-cli\"`では暗黙的です。 | |\n| ホスト ファイルシステム | ホスト ツールが使用可能な場合は、ランタイム プロセスによって共有されます。 |\n\n`mode: \"empty\"` は、共有ランタイム パターンを実行可能にする機能です。アプリケーションが登録または許可しない限り、アンビエント OS ツールは公開されません。\n`mode: \"copilot-cli\"`では、OS ファイルシステム アクセスはホスト プロセスを通じて共有されるため、マルチユーザー サーバー モードにはそのモードを使用しないでください。\n\nセッションの状態は、`COPILOT_HOME/session-state/{sessionId}`経由でルーティングしない限り、`sessionFs`に格納されます。 独自のテナントまたはユーザーの境界を含む一意のセッション ID を使用し、セッションを再開または削除する前にアクセス制御を適用します。\n\n## パターンの比較\n\n| Pattern | 次の場合に使用します。 | Trade-offs |\n| --------------------------------- | ------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------ |\n| パターン 1: ユーザーごとに分離された CLI | ユーザーごとに最も強力な分離境界または個別のプロセス資格情報が必要です。 | 強力な分離。より高いリソース コスト。 「[スケーリングとマルチテナント](/ja/copilot/how-tos/copilot-sdk/setup/scaling)」を参照してください。 |\n| パターン 2: CLI との共有: `mode: \"empty\"` | アプリがツール、認証、およびセッション ID を制御している間、1 つのランタイムで多くのユーザーにサービスを提供する必要があります。 | 効率的;には、慎重なツール登録、セッションごとのトークン、およびアプリケーション レベルのアクセス チェックが必要です。 |\n| パターン 3: ハイブリッド | コンピューティング負荷の高い作業をクラウド セッションにルーティングし、軽い作業をローカル セッションにルーティングします。 | 柔軟;には、ワークロード ルーティングとポリシー処理が必要です。 「[クラウド セッション](/ja/copilot/how-tos/copilot-sdk/features/cloud-sessions)」を参照してください。 |\n\n### パターン 2: CLI との共有: `mode: \"empty\"`\n\nこのパターンでは、すべてのユーザーがバックエンド経由で 1 つのランタイム プールに接続します。 アプリケーションはユーザー認証を実行し、セッション ID を選択し、セッションでユーザーのGitHub トークンを渡し、明示的なツール許可リストを提供します。\n\n![図: 説明されたプロセスを示すフローチャート。](/assets/images/help/copilot/copilot-sdk/setup-multi-tenancy-diagram-0.png)\n\n次の規則を使用します。\n\n* 常にクライアントまたはランタイムを `mode: \"empty\"`で起動します。\n* 一意のセッション ID を使用し、所有権メタデータをアプリケーション データベースに格納します。\n* セッション ID を参照する `resumeSession`、 `deleteSession`、または UI アクションの前に所有権を確認します。\n* 要求をユーザーとして実行する必要がある場合は、セッションごとに `gitHubToken` を渡します。\n* セッションに必要なツールのみを登録し、 `custom:*` や `mcp:search_docs`などのソース修飾許可リストを優先します。\n* `sessionIdleTimeoutSeconds`設定し、完了したワークフロー セッションを明示的に削除します。\n\n## よくある落とし穴\n\n* `mode: \"empty\"`を忘れること。 既定の `copilot-cli` モードでは、CLI スタイルの動作が公開され、アンビエント ツールを使用してホスト ファイル システムが公開される場合があります。\n* `sessionIdleTimeoutSeconds`を設定していません。 実行時間の長いサーバーは、クリーンアップしないとアイドル 状態のセッションを蓄積する可能性があります。\n* セッションごとのトークンを渡すのではなく、ユーザー間で 1 つの `gitHubToken` を共有します。\n* バックエンドの所有権を確認せずに、クライアントが提供するセッション ID を信頼する。\n* 既存のランタイムに接続するクライアントで `baseDirectory` を設定し、ランタイム ストレージを移動することを想定しています。 代わりにランタイム プロセスを構成します。\n* 各ツールがユーザーに適しているかどうかを確認することなく、 `builtin:*` などの広範なツール パターンを許可します。\n\n## 参照\n\n* [スケーリングとマルチテナント](/ja/copilot/how-tos/copilot-sdk/setup/scaling): デプロイ トポロジ、ストレージ パターン、分離の比較\n* [バックエンド サービスのセットアップ](/ja/copilot/how-tos/copilot-sdk/setup/backend-services): ヘッドレス サーバー モードでランタイムを実行する\n* [BYOK (独自のキーを持ち込む)](/ja/copilot/how-tos/copilot-sdk/auth/byok): 自分のモデルプロバイダーの認証情報を使用する\n* [クラウド セッション](/ja/copilot/how-tos/copilot-sdk/features/cloud-sessions): 選択した作業をクラウド セッションにルーティングする\n* [セッションの再開と永続化](/ja/copilot/how-tos/copilot-sdk/features/session-persistence): 再開可能なセッション状態の管理\n* [機能](/ja/copilot/how-tos/copilot-sdk/features): ツール、イベント、フック、および高度な SDK 機能"}