メインコンテンツへスキップ

Documentation Index

Fetch the complete documentation index at: https://docs.devinenterprise.com/llms.txt

Use this file to discover all available pages before exploring further.

このガイドでは、DevinにおけるSSO (シングルサインオン) の導入からIdPグループの設定まで、SSO (シングルサインオン) のライフサイクル全体をEnterprise管理者向けに説明するとともに、SCIMを利用せずにDevinがユーザーのプロビジョニングをどのように処理するかを解説します。 プロバイダ別の設定手順については、Okta、Azure AD、SAML、またはGeneric OIDCを参照してください。

​
1. SSO (シングルサインオン) の設定

​
SSO (シングルサインオン) アプリケーションの作成

ご利用の IdP (Identity Provider) (Okta、Azure AD、または SAML/OIDC に準拠した任意の IdP) でアプリケーションを作成し、以下の認証情報を Cognition の担当チームに共有してください。
Connection TypeProtocolWhat to Provide
OktaOIDC (Okta Workforce Identity)Okta ドメイン、クライアント ID、クライアントシークレット、スコープ
Azure ADOIDC (Microsoft Entra ID)Azure AD ドメイン、クライアント ID、クライアントシークレット
SAMLSAML 2.0 (any IdP)サインイン URL、X.509 署名証明書
Generic OIDCOIDCDiscovery URL、クライアント ID、クライアントシークレット、スコープ
また、Devin が IdP から提供されるどのメールアドレスを信頼すべきか判断できるよう、確認済みのメールドメインも共有してください。

​
セットアップ後の動作

Cognitionチームがお客様の認証情報を受け取ると、SSO (シングルサインオン) (シングルサインオン) 接続を設定します。セットアップが完了すると、次の状態になります。
  1. SSO (シングルサインオン) 接続がお客様のDevin Enterpriseに紐付けられます
  2. ログイン時の自動メンバー追加 が有効になり、SSO (シングルサインオン) 経由で認証したユーザーは自動的にお客様のEnterpriseに追加されます
  3. お客様のメールドメインが信頼済みとして登録され、それらのドメインのメールアドレスのみ受け付けられます
  4. グループベースのロール割り当て (RBAC) が有効になり、ログイン時に送信されるIdPグループをDevinのロールにマッピングできるようになります
  5. 既定のソーシャルログイン (Google、GitHub) が無効になり、SSO (シングルサインオン) が必須の認証方法になります

​
ユーザーのログインフロー

  1. ユーザーがお使いのDevin URLにアクセスします
  2. 設定済みのIdP (Okta、Azure AD など) にリダイレクトされます
  3. ユーザーが通常どおり認証します
  4. IdPがユーザー情報とグループ所属情報をDevinに送信します
  5. Devinは自動的に以下を行います:
    • 初回ログイン時にはユーザーのアカウントを作成します (ジャストインタイムプロビジョニング)
    • デフォルトのEnterprise Memberロールを割り当てます
    • IdPグループ所属情報を同期し、新しいグループを追加して滞留したグループを削除します
    • ログインをEnterpriseの監査ログに記録します

​
セルフサービスによる管理

以下の機能は、Enterprise 管理者がDevin webapp上で直接利用できます。

​
IdP グループ管理

設定 → Enterprise → Identity Provider Groups
  • ユーザーログインを通じて同期されたすべてのグループを閲覧する
  • グループを Enterprise 全体のロールに割り当てる (例: 「Engineering-Admins の全員に Enterprise Admin ロールを付与する」)
  • グループを特定の org に特定のロールで割り当てる (例: 「Team-Backend に Backend org で Member 権限を付与する」)
  • 複数の org にまたがってグループを一括で追加／削除する
  • 各グループがいくつの org に割り当てられているかを閲覧する

​
メンバー管理

設定 → Enterprise → メンバー
  • 所属するIdP グループを含む、Enterprise のすべてのメンバーを閲覧する
  • メールで新しいメンバーを招待する
  • メンバーのロールを変更する
  • メンバーを削除する

​
カスタムロール

設定 → Enterprise → ロール
  • 細かな権限を設定したカスタムロールを作成
  • カスタムロールを個々のユーザーまたはIdPグループに割り当て
詳細は、Custom Roles & RBACを参照してください。

​
自動化向け API

Devin では、メンバー管理を自動化できる V2 API を提供しています。
アクションAPI エンドポイント
すべてのメンバーを一覧表示GET /v2/enterprise/members
ユーザーをメールで一括招待POST /v2/enterprise/members/invite
メンバーを削除DELETE /v2/enterprise/members/{user_id}
メンバーのロールを一括更新PATCH /v2/enterprise/members/roles
メンバーのロールを移行PATCH /v2/enterprise/members/migrate-roles
すべてのロールを一覧表示GET /v2/enterprise/roles
すべての IdP グループを一覧表示GET /v2/enterprise/groups
IdP グループを事前作成PUT /v2/enterprise/groups
グループの org への割り当てを取得GET /v2/enterprise/groups/{group_name}

​
2. SCIMを使わない場合のDevinの仕組み

Devinは現在、SCIMプロトコルに対応していません。ユーザーとグループの管理は、SSO (シングルサインオン) (シングルサインオン) のログインイベントとDevin UI/APIを通じて行われます。実際には、これは次のことを意味します。

​
ユーザープロビジョニング: ログイン時のみ

SCIM ありDevin (SCIM なし)
ユーザーが作成される方法ユーザーが割り当てられると、IdP が直ちにアプリにユーザー作成を反映するユーザーは、初回の SSO (シングルサインオン) ログイン後、または UI もしくは API 経由で手動招待された後にのみ Devin 上に作成される
発生するタイミング管理者がユーザーにアプリを割り当てる → 数秒以内にユーザーが表示される管理者がユーザーにアプリを割り当てる → ユーザーがログインするまで、Devin では何も起こらない
事前プロビジョニングユーザーがアプリを初めて利用する前に、アカウントの準備が完了している管理者が Devin の UI または API で明示的に招待しない限り、事前プロビジョニングは行われない
新入社員をオンボーディングする際、管理者は事前に招待する (Settings → Enterprise → Members → Invite、または API 経由) か、初回ログイン時に自動的にプロビジョニングさせることができます。

​
ユーザーのプロビジョニング解除: 手動のみ

SCIM ありDevin (SCIM なし)
ユーザーの削除方法IdP がユーザーを無効化または削除すると、アプリがそのユーザーを即座に無効化IdP でユーザーを無効化または削除しても、Devin 側では何も起こらない
オフボーディングオフボードされた従業員は数分以内にアクセスを失うオフボードされた従業員は、Devin から手動で削除され、かつセッションの有効期限が切れるまでアクセスを保持する
コンプライアンスコンプライアンス対応を自動化 — 孤立したアカウントは発生しない管理者が両方のシステムを管理しない限り、孤立したアカウントが発生するリスクがある
これは運用上の最大のギャップです。従業員をオフボードする際は、管理者が別途 Devin からそのユーザーを削除する必要があります (Settings → Enterprise → Members → Remove、または API 経由) 。アクティブなセッションは自然に期限切れになるまで継続し、IdP によって即時にセッションが失効することはありません。

​
グループ同期: ログイン時のみで、リアルタイムではない

SCIMあり (グループプッシュ)Devin (SCIMなし)
同期のタイミングIdP がグループメンバーシップの変更をリアルタイムで反映グループが同期されるのは、ユーザーのログイン時のみ
グループへの追加管理者がユーザーをグループに追加 → アプリに即座に反映される管理者がユーザーをグループに追加 → Devin が認識するのは、ユーザーの次回ログイン時
グループからの削除管理者がユーザーをグループから削除 → アプリに即座に反映される管理者がユーザーをグループから削除 → Devin には次回ログインまで以前のメンバーシップが表示される
基準となる情報源IdP が常に基準となる情報源IdP が基準となる情報源なのはログイン時のみ — ログインとログインの間にずれが生じることがある
管理者が誰かの IdP グループを変更した場合 (たとえば Engineering から Sales に移動した場合) 、Devin に反映されるのは、そのユーザーが再度ログインしたときです。それまでは、ユーザーは以前のグループベースのロールと組織へのアクセスを保持します。

​
SCIM の代替となる組み込み機能

Devin には、SCIM の一般的なユースケースに対応する機能がいくつかあります。
  1. ジャストインタイム プロビジョニング — ユーザーは初回の SSO (シングルサインオン) (シングルサインオン) ログイン時に、デフォルトの Enterprise ロールで自動的に作成されます
  2. ログインごとの完全なグループ同期 — ユーザーがログインするたびに、Devin はそのユーザーの IdP グループとの差分を完全に確認し、新しいグループを追加し、不要になったグループを削除します
  3. グループベースの RBAC — Devin の設定で、IdP グループを Enterprise ロールや org へのアクセスにマッピングでき、次回のログイン時に反映されます
  4. 自動化のための V2 API — 招待、削除、一括でのロール変更をスクリプト化して、プロビジョニング／プロビジョニング解除のギャップを埋められます
  5. 監査ログ — すべてのログインが記録されるため、誰が Devin にアクセスしたかを確認できます

​
3. IdP 管理グループの設定

他のアプリケーション (Slack や Box など) でも SCIM を利用している場合、このセクションでは Devin のグループモデルの仕組みと、IdP を正しく設定する方法について説明します。

​
前提情報: SCIM Groups と IdP Groups

  • SCIM Groups: 下流のアプリが、どのグループが存在するかを IdP に伝えます (IdP はそれらを「インポート」します) 。グループ構成の基準となるのはアプリです。IdP は、アプリで定義されたそれらのグループにユーザーを同期します。
  • IdP Groups (Devin で利用するもの): IdP が基準となります。グループは IdP のディレクトリで定義され、グループの所属情報はログイン時に SAML/OIDC のクレームを通じて Devin に渡されます。
Devin は SCIM を利用しないため、すでに「IdP groups」モードで運用されています。重要なのは、適切なグループが IdP から送信され、Devin で正しくマッピングされていることを確認することです。

​
ステップ 1: IdP でグループを定義する

IdP の管理コンソールで設定します (以下の例では Okta を利用します) :
  1. Directory → Groups に移動します
  2. Devin のアクセスレベルに対応するグループを作成します (例: Devin-Engineering, Devin-Admins, Devin-DataScience)
  3. ユーザーをこれらのグループに割り当てます
これらは IdP ネイティブのグループです。どのユーザーがどのグループに属するかは、IdP が基準となります。

​
ステップ 2: IdP アプリでグループクレームを設定する

Devin がグループ情報を読み取れるようにするため、認証応答にグループを含める必要があります。

​
SAML 接続の場合

  1. Applications → [Devin App] → SAML Settings → Edit に移動します
  2. Group Attribute Statements で、以下を追加します:
    • Name: groups
    • Filter: “Starts with” → Devin- (または、より複雑なパターンには “Matches regex” を利用します)
  3. これにより、IdP は一致するグループ名を SAML アサーションに含めます

​
OIDC 接続の場合

  1. Applications → [Devin App] → Sign On → Edit に移動します
  2. OpenID Connect ID Token → Groups claim type で「Filter」を選択します
  3. フィルターが Devin のグループに一致するよう設定します (例: 「Starts with」 → Devin-)
Devin- のようなプレフィックスでフィルタリングすると、必要なグループだけが送信されます。組織内のすべての IdP グループを送信する必要はありません。

​
ステップ 3: Devin でグループをロールと組織にマッピングする

ログイン時にグループ情報が渡されるようになったら、Devin でそれらをマッピングします。

​
Devin UIで

  1. Settings → Enterprise → Identity Provider Groups
  2. そのグループのメンバーが1人でもログインすると、グループが自動的に表示されます
  3. グループをクリック → Enterprise レベルのロール (例: Enterprise Admin またはカスタムロール) を割り当てます
  4. グループをクリック → 特定のorgに、特定のorgレベルのロールを割り当てます

​
API 経由 (事前設定または自動化向け)

  • ユーザーがログインする前にグループを事前作成: PUT /v2/enterprise/groups
  • グループとその org への割り当てを一覧表示: GET /v2/enterprise/groups

​
ステップ4: 他のアプリでSCIM Groupsから移行する場合

ツール全体 (Devinだけでなく) で、SCIM管理グループからIdP管理グループへ移行する場合は、次の手順に従ってください。
  1. 他のアプリでSCIM Group Importingを停止します:
    • IdPでアプリのProvisioning → Integrationタブを開き、“Import Groups” のチェックを外します
    • これにより、下流アプリがグループの基準となるものではなくなります
  2. IdP Directoryで対応するグループを作成します:
    • Directory → Groupsに移動し、下流アプリに存在していたグループを反映したグループを作成します
    • ユーザーをそれらのIdPネイティブなグループに割り当てます
  3. Group Pushを設定します (対応しているアプリの場合) :
    • アプリのIdP設定で、Push Groupsタブ → グループ名で検索 → 既存の下流グループにリンクします
    • これにより、IdPがアプリ内のメンバーシップを上書きし、IdPが唯一の基準となるものになります
    • Devinはログインアサーションからグループを直接読み取るため、Group Pushは不要です
  4. 他のアプリでSCIM Group Syncを無効化します:
    • 下流アプリが再び基準となるものとして扱われないよう、“Import Groups” がオフのままであることを確認します
Devinについては、特別な移行は必要ありません。上記のステップ1〜3 (IdPでグループを定義し、クレームを設定し、Devinでマッピングを設定する) が完了していれば十分です。

​
主な注意点

グループ名が変更されると、Devin はそれを新しいグループとして扱います。以前のグループのロールマッピングは自動的には引き継がれないため、Devin の設定で新しいグループ名を再設定する必要があります。
Devin にマッピングされた IdP グループにユーザーを追加しても、そのユーザーがログインするまではアクセス権は付与されません。
ユーザーを IdP グループから削除しても、そのユーザーの Devin へのアクセスはすぐには取り消されません。次回ログイン時に Devin が同期を行い、滞留したグループメンバーシップを削除します。グループ外で直接割り当てられたメンバーシップには影響しません。
IdP のグループ名は、Devin が認識する名前と完全に一致している必要があります。大文字と小文字は区別されます。
Devin はネストされたグループや階層型グループをサポートしていません。IdP から親グループが送信されても、子グループのメンバーは自動的には含まれません。各グループを明示的に割り当てる必要があります。
SCIM を使わずにできるだけ厳密に制御したい場合は、次の方法に従ってください。
1

Identity Provider を設定する（基準となる情報源）

  1. グループを定義します: Devin-Admins、Devin-Backend、Devin-Frontend など
  2. ユーザーをグループに割り当てます
  3. 「Starts with: Devin-」でフィルタした SAML/OIDC のグループクレームを設定します
2

Devin はログインのたびに同期します

ユーザーが SSO (シングルサインオン) (シングルサインオン) 経由でログインすると、Devin は自動的に以下を実行します:
  • 新規ユーザーの場合は自動で作成します
  • グループを完全同期します (新しいグループを追加し、不要になったグループを削除します)
  • グループから role および org へのマッピングを即座に適用します
3

任意: V2 API で自動化する

SCIM で補いきれない部分を埋めるために、定期実行ジョブを設定します:
  1. IdP API からアクティブなユーザーを取得します
  2. GET /v2/enterprise/members から Devin のメンバーを取得します
  3. POST /v2/enterprise/members/invite で新入社員を招待します
  4. DELETE /v2/enterprise/members/{user_id} で退職者を削除します
これにより、SCIM がなくてもプッシュ型のプロビジョニングとプロビジョニング解除を実現できます。

​
これにより得られること

  • グループ構成とメンバーシップの単一の基準となるIdP
  • ログインのたびにグループベースのアクセス制御を自動で適用
  • 通常はSCIMが担う部分を補完する、APIによるプロビジョニング／デプロビジョニング
  • すべてのログインとメンバーシップの変更に対する完全な監査証跡

​
現在の制限事項

  • ログイン間でのグループのリアルタイム同期 — グループはユーザーのログイン時にのみ更新されます
  • プロビジョニング解除時のセッションの即時失効 — セッションは有効期限が切れるまで継続します
  • suspend/reactivate のような IdP 主導のライフサイクルイベント はサポートされていません