---
title: シングルサインオン
url: https://platform.claude.com/docs/ja/managed-agents/self-hosted/configure
description: ユーザーやサービスが、IDプロバイダーのトークンを使ってセルフホスト型Claude Managed Agentsサーバーを呼び出せるようにします。
---

<Note>
  セルフホスト型Claude Managed Agentsへのアクセスをリクエストするには、Anthropicのアカウントチームにお問い合わせください。
</Note>

デフォルトでは、サーバーは1つの共有キーである[サーバーAPIキー](https://platform.claude.com/docs/ja/managed-agents/self-hosted#the-three-credentials)を受け付けます。「single sign-on」（シングルサインオン）では、各ユーザーやサービスは「OpenID Connect」、すなわちOIDCのIDプロバイダーから取得したトークンでもサーバーを呼び出せます。サーバーは、トークン内のグループに基づいて呼び出し元にロールを付与します。サーバーAPIキーは管理者の認証情報として引き続き機能します。

このページでは、IDプロバイダーを追加する方法、各ロールでできること、および開発者がターミナルからログインできるようにする方法を示します。

## IDプロバイダーを追加する

<Steps>
  <Step title="IDプロバイダーにサーバーを登録する">
    `api://cma-server`などの識別子を持つAPIとしてサーバーを登録し、クライアントにそのトークンを要求させます。
  </Step>

  <Step title="設定ファイルにIDプロバイダーを列挙する">
    [設定ファイル](https://platform.claude.com/docs/ja/managed-agents/self-hosted/configuration-reference#where-settings-go)の`auth.issuers`の下にエントリを追加します。

    ```yaml
    auth:
      issuers:
        - name: okta
          issuer_url: https://login.example.com/oauth2/default
          audiences: [api://cma-server]
          roles:
            - group: cma-admins
              role: admin
            - group: "eng-*"
              role: developer
    ```

    * `name`はログ行で発行者を識別するラベルであり、サーバーはこれを各リソースの作成者の一部として記録します。ユーザーがリソースを作成した後は変更しないでください。
    * `issuer_url`はトークンの`iss`クレームと一致する必要があります。
    * `audiences`は、最初のステップで設定した識別子など、トークンの`aud`クレームが持つことのできる値を列挙します。
    * `roles`は、グループを`admin`、`developer`、または`user`にマッピングします。一致したロールのうち最も高いものが適用されます。

    その他のフィールドについては、[発行者エントリ](https://platform.claude.com/docs/ja/managed-agents/self-hosted/configuration-reference#issuer-entries)を参照してください。プロバイダーがMicrosoft Entra IDの場合は、[Microsoft Entra ID](https://platform.claude.com/docs/ja/managed-agents/self-hosted/configure#microsoft-entra-id)も参照してください。
  </Step>

  <Step title="サーバーを再起動してサインインを確認する">
    サーバーを再起動します。呼び出し元は、サーバーAPIキーを受け付ける任意のルートで、トークンを`Authorization: Bearer <token>`として送信します。

    トークンで認証されたすべてのリクエストについて、サーバーは`auth=oidc`、発行者の`name`、および呼び出し元のサブジェクト（`sub=`）をログに記録します。
  </Step>
</Steps>

### サインインが失敗した場合

| レスポンス                 | 原因                              | サーバーのログ行に含まれる内容       |
| --------------------- | ------------------------------- | --------------------- |
| `401`（誤ったAPIキーの場合と同じ） | トークンがチェックに失敗しました。理由はログ行に記録されます。 | `oidc token`          |
| `403`                 | トークンのグループがどの`roles`エントリにも一致しません | `token holds no role` |

### Microsoft Entra ID

Entra IDは、次の2点で他のプロバイダーと異なります。どちらの設定も発行者エントリに記述します。

* **ユーザー：** Entra IDはクライアントアプリケーションごとに異なる`sub`をユーザーに付与するため、デフォルトでは1人のユーザーが複数の作成者として記録されてしまいます。`subject_claim: oid`を設定してください。
* **グループ：** ユーザーが多数のグループに所属している場合、Entra IDはトークンから`groups`クレームを省略します。その場合、そのユーザーはどの`roles`エントリにも一致しなくなります。これを防ぐには、アプリケーションに割り当てられたグループのみをEntra IDに出力させてください。または、Entra IDでユーザーにアプリロールを割り当て、`groups_claim: roles`を設定して、サーバーがグループの代わりにアプリロールを読み取るようにしてください。

## 各ロールでできること

| ロール                  | エージェント、スキル、セッション、ボールト、メモリストア | 環境                        |
| -------------------- | ---------------------------- | ------------------------- |
| `admin`、およびサーバーAPIキー | すべてを参照・変更できる                 | 作成、変更、削除、およびキーの作成ができる     |
| `developer`または`user` | その呼び出し元が作成したもののみ参照・変更できる     | 一覧表示、読み取り、およびセッションの実行ができる |

`developer`と`user`のアクセス権は同じです。いずれかのロールを持つ呼び出し元は、次のようになります。

* **他の誰かが作成したリソースを参照できません。** そのリソースはリストに表示されず、そのIDに対するリクエストは不明なIDに対するリクエストと同じ応答を受け取ります。これには、シングルサインオンを有効にする前にサーバーAPIキーで作成されたすべてのものが含まれます。
* **リソースを共有できません**（他の呼び出し元やグループとの共有）。

`admin`は正確なグループ名にマッピングしてください。管理者は任意のユーザーのボールトを使用するセッションを開始することもできます。そのため、このロールは全ユーザーのMCPトークンを任せられるグループにのみ付与してください。

## 開発者がターミナルからログインできるようにする

開発者は、IDプロバイダー経由でログインし、サーバーAPIキーを使わずに自身のIDで`ant` CLIを使用できます。最初の2つのステップは管理者が行い、3つ目のステップは各開発者が行います。

<Steps>
  <Step title="IDプロバイダーにアプリケーションを登録する">
    次の条件を持つネイティブ（「パブリック」）アプリケーションを登録します。

    * クライアントシークレットなし
    * PKCE付きの認可コードグラント
    * リダイレクトURI`http://127.0.0.1/callback`

    一部のプロバイダーでは、[その他のリダイレクトURI](https://platform.claude.com/docs/ja/managed-agents/self-hosted/configure#other-redirect-uris)のいずれかが必要です。
  </Step>

  <Step title="発行者エントリにアプリケーションを追加する">
    発行者エントリに`login_client_id`と`login_scopes`を追加して、サーバーを再起動します。

    ```yaml
    login_client_id: 0oa1b2c3d4e5f6g7h8i9
    login_scopes: [openid, cma-server.access]
    ```

    `login_scopes`には、`aud`クレームが発行者エントリの`audiences`リストに含まれるトークンを発行するためにプロバイダーが必要とするスコープを列挙します。
  </Step>

  <Step title="ログインする">
    各開発者は、展開したアーカイブの最上位からログインを実行します。

    ```bash
    ./cma-server-admin login https://cma.example.com
    ```

    サーバーのURLは`https://`であるか、`localhost`、`127.0.0.1`、または`::1`への`http://`である必要があります。[その他のリダイレクトURI](https://platform.claude.com/docs/ja/managed-agents/self-hosted/configure#other-redirect-uris)のいずれかを使用する場合は、そのフラグをコマンドに追加します。

    このコマンドはブラウザでプロバイダーのサインインページを開き、その後`cma-server`という名前の`ant` CLIプロファイルを書き込みます。任意の`ant`コマンドに`--profile cma-server`を渡すか、`ant profile activate cma-server`を実行してそのプロファイルをデフォルトにします。
  </Step>
</Steps>

トークンの有効期限が切れたら、開発者は再度`login`を実行します。代わりに`ant` CLIにトークンを更新させるには、`login_scopes`に`offline_access`を追加します。

### その他のリダイレクトURI

| プロバイダー                | 登録するリダイレクトURI                                   | 開発者が`login`コマンドに追加するフラグ  |
| --------------------- | ----------------------------------------------- | ------------------------ |
| Microsoft Entra ID    | `http://localhost/callback`                     | `-listen localhost:0`    |
| リダイレクトURIにポートを必要とするもの | `http://127.0.0.1:8123/callback`のような固定ポートを持つURI | `-listen 127.0.0.1:8123` |

その他のフラグを一覧表示するには、`login`コマンドに`-h`を追加します。

## サーバー上のコンソールにユーザーがサインインできるようにする

サーバー上のコンソールは、[ターミナルログイン](https://platform.claude.com/docs/ja/managed-agents/self-hosted/configure#let-developers-log-in-from-a-terminal)用に登録したアプリケーションを通じてユーザーをサインインさせます。セットアップを完了するには、[サインインを設定する](https://platform.claude.com/docs/ja/managed-agents/self-hosted/console#set-up-sign-in)を参照してください。