Skip to main content
このガイドでは、DevinにおけるSSO (シングルサインオン) の導入からIdPグループの設定まで、SSO (シングルサインオン) のライフサイクル全体をEnterprise管理者向けに説明するとともに、ユーザーのプロビジョニングに関する選択肢を解説します。 プロバイダ別の設定手順については、Okta、Microsoft Entra ID、SAML、またはGeneric OIDCを参照してください。自動プロビジョニングについては、SCIM Setupを参照してください。

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

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

ご利用の IdP (Identity Provider) (Okta、Microsoft Entra ID、または SAML/OIDC に準拠した任意の IdP) でアプリケーションを作成し、以下の認証情報を Cognition の担当チームに共有してください。
また、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、Microsoft Entra ID など) にリダイレクトされます
  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 を提供しています。

​
2. ユーザープロビジョニングのオプション

Devin は、2 つのプロビジョニングモデルをサポートしています。

​
オプション A: ログインベースのプロビジョニング

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

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

新入社員をオンボーディングする際、管理者は事前に招待する (Settings → Enterprise → Members → Invite、または API 経由) か、初回ログイン時に自動的にプロビジョニングさせることができます。

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

これはログインベースのプロビジョニングにおける運用上の最大のギャップです。従業員をオフボードする際は、管理者が別途 Devin からそのユーザーを削除する必要があります (Settings → Enterprise → Members → Remove、または API 経由) 。これを自動化するには SCIM を使用してください。

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

管理者が誰かの IdP グループを変更した場合 (たとえば Engineering から Sales に移動した場合) 、Devin に反映されるのは、そのユーザーが再度ログインしたときです。それまでは、ユーザーは以前のグループベースのロールと組織へのアクセスを保持します。

​
オプションB: SCIMプロビジョニング

Devinは、IdPからの自動リアルタイムプロビジョニングにSCIM 2.0をサポートしています。
  • 事前プロビジョニング — ユーザーがアプリに割り当てられると、初回ログイン前でもDevinに作成されます
  • 自動プロビジョニング解除 — IdPでユーザーを無効化または割り当て解除すると、Enterpriseのメンバーシップが直ちに削除されます
  • リアルタイムグループ同期 — グループメンバーシップの変更は、次回のログインを待たずに発生時点でプッシュされます
セットアップ手順については、SCIM Setupを参照してください。

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

このセクションでは、Devin のグループモデルの仕組みと、ログインベースのグループ同期のために IdP を正しく設定する方法について説明します。SCIM を利用している場合、グループは IdP からプッシュされるため、このクレーム設定は不要です。

​
前提情報: Devin が IdP Groups を利用する方法

IdP が基準となります。グループは IdP のディレクトリで定義され、グループメンバーシップはログイン時に SAML/OIDC のクレームを通じて、または SCIM group push を介して Devin に渡されます。重要なのは、適切なグループが 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は不要です。(SCIM 経由でDevinをプロビジョニングする場合は、Push Groupsタブでグループをプッシュしてください。)
  4. 他のアプリでSCIM Group Syncを無効化します:
    • 下流アプリが再び基準となるものとして扱われないよう、“Import Groups” がオフのままであることを確認します
Devinについては、特別な移行は必要ありません。上記のステップ1〜3 (IdPでグループを定義し、クレームを設定し、Devinでマッピングを設定する) が完了していれば十分です。

​
主な注意点

ログイン同期グループでは、グループ名の変更は新しいグループとして扱われます。以前のグループのロールマッピングは自動的には引き継がれないため、Devin の設定で新しいグループ名を再設定する必要があります。SCIM 経由で名前が変更されたグループはマッピングを維持します。
SCIM を使用しない場合、Devin にマッピングされた IdP グループにユーザーを追加しても、そのユーザーがログインするまではアクセス権は付与されません。
SCIM を使用しない場合、ユーザーを 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 は自動的に以下を実行します:
  • 新規ユーザーの場合は自動で作成します
  • グループを完全同期します (新しいグループを追加し、不要になったグループを削除します)
  • グループからロール および 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によるプロビジョニング／デプロビジョニング
  • すべてのログインとメンバーシップの変更に対する完全な監査証跡

​
ログインベースのプロビジョニングの制限事項

  • ログイン間でリアルタイムにグループを同期できない — グループが更新されるのは、ユーザーがログインしたときのみです
  • 自動プロビジョニング解除なし — IdP でユーザーを削除しても、Devin で手動で削除するまで何も起こりません
  • 停止/再有効化など、IdP 起点のライフサイクルイベントなし
SCIM を使用すると、グループの変更がリアルタイムで同期され、プロビジョニング解除によりログインを待たずに Enterprise のメンバーシップが即座に削除されます。どちらのモデルでも、既存のセッションは期限切れまでアクティブなままです。