1Password SCIM自動プロビジョニング設定手順 2026|SCIM Bridge構築とIdP連携
1Password の SCIM 自動プロビジョニング設定を、前提プラン・デプロイ方式の選び方・IdP 連携・つまずき早見表・検証まで手順で解説。ホスト型とセルフホスト SCIM Bridge の使い分けも整理します。

本記事にはプロモーション(アフィリエイトリンク)が含まれます。
1Password の SCIM 自動プロビジョニングは、IdP(Okta や Microsoft Entra ID など)で従業員を追加・削除すると、1Password 側のアカウント発行・グループ付与・退職者の凍結までを自動同期する仕組みです。必要なのは Business 以上のプランと、SCIM Bridge(またはホスト型 automated provisioning)の 2 つだけ。本記事は前提の確認からデプロイ、IdP 連携、検証、ロールバックまでを手順順に整理し、つまずきやすい設定ミスを早見表で先回りして回避できるようにまとめます。
SCIM 自動プロビジョニングとは — まず結論と前提条件
SCIM(System for Cross-domain Identity Management)は、IdP と SaaS の間でユーザー情報を同期するための標準仕様です。1Password では、IdP をソース・オブ・トゥルースとして「入社したらアカウント発行」「異動したらグループ変更」「退職したら凍結」を自動化できます。手作業の招待・削除をなくし、退職者アカウントの消し忘れという情報漏洩リスクを構造的に減らせるのが最大の狙いです。
まず必須の前提条件を確認します。ここが揃っていないと後工程で必ず詰まります。
- プラン: SCIM 連携は 1Password Business または Enterprise が前提。Individual / Families / Teams Starter Pack では使えません
- 管理権限: 1Password の Owner または Administrator 権限(プロビジョニング設定と scimsession 発行に必要)
- 対応 IdP: Okta / Microsoft Entra ID / Google Workspace / JumpCloud / OneLogin / Rippling など
- デプロイ先(セルフホスト時): Google Cloud / DigitalOcean / Azure Container Apps / Kubernetes / Docker のいずれか
プラン別のコスト感を先に固めたい場合は、社員規模ごとの試算を整理した 1Password Business プランのコスト比較 を先に確認しておくと、SCIM の運用設計まで見通しやすくなります。
デプロイ方式の選択:ホスト型 automated provisioning vs セルフホスト SCIM Bridge
2026 年時点の 1Password では、SCIM を動かす方式が 2 つあります。どちらを選ぶかで初期構築の手間が大きく変わるため、最初に決めます。1Password は Okta と Microsoft Entra ID 向けに、自前でサーバを立てずに使える「ホスト型 automated provisioning」を提供しており、対象 IdP がこの 2 つで完結するなら構築コストを大幅に削減できます。それ以外の IdP や自社インフラ要件がある場合は、Docker イメージ(1password/scim)を自分でデプロイするセルフホスト SCIM Bridge を選びます。
| 観点 | ホスト型 automated provisioning | セルフホスト SCIM Bridge |
|---|---|---|
| 対応 IdP | Okta / Microsoft Entra ID | Okta / Entra ID / Google Workspace / JumpCloud / OneLogin / Rippling ほか |
| インフラ | 不要(1Password がホスト) | 自前(GCP / DigitalOcean / Azure Container Apps 等) |
| 運用負荷 | 低(サーバ管理・アップデート不要) | 中(再デプロイ・監視・証明書更新が必要) |
| SCIM エンドポイント | https://provisioning.1password.com/scim/v2 | 自分でデプロイした URL の /scim/v2 |
| 向くケース | Okta / Entra ID 中心で手早く始めたい | 対応 IdP を広く使う・データ所在を自社で管理したい |
ケース別の勝者はシンプルです。IdP が Okta か Entra ID なら、まずホスト型を試すのが最短。Google Workspace や JumpCloud を使う、あるいはネットワーク要件でエンドポイントを自社管理下に置きたいなら、セルフホスト SCIM Bridge が現実解になります。

セルフホスト SCIM Bridge を構築する手順
セルフホスト方式の構築は、大きく「認証情報の発行 → デプロイ → IdP 接続」の 3 段階です。以下のチェックリスト順で進めれば迷いません。
- 1Password 管理画面の「プロビジョニング」設定を開き、scimsession ファイルと bearer token を発行する
- デプロイ先を決める(Google Cloud / DigitalOcean / Azure Container Apps / Kubernetes / Docker)
1Password/scim-examplesリポジトリの環境別テンプレートを使い、scimsession を Secret として渡して SCIM Bridge をデプロイする- デプロイした SCIM Bridge のドメインに HTTPS で到達できることを確認する(TLS 証明書が有効であること)
- IdP 側に 1Password アプリを追加し、SCIM URL(
https://<your-bridge>/scim/v2)と bearer token を設定する - 属性マッピングを設定し、テストユーザー・テストグループで同期を実行して結果を確認する
デプロイ後の疎通確認は、SCIM Bridge の /Users エンドポイントに bearer token 付きでアクセスして応答が返るかで判断できます。
curl https://<your-scim-bridge-domain>/scim/v2/Users \
-H "Authorization: Bearer <bearer-token>"
各環境のデプロイテンプレートやパラメータは公式の scim-examples リポジトリに揃っているため、ゼロから書く必要はありません12。招待からアクセス定着までを含めたチーム全体の導入設計は 1Password のチーム導入オンボーディング設計ガイド に手順をまとめているので、SCIM 導入と並行して整えると運用が安定します。
scimsession と bearer token の役割
scimsession は SCIM Bridge が 1Password テナントへアクセスするための資格情報、bearer token は IdP が SCIM Bridge を認証するためのトークンです。scimsession は Secret Manager や環境変数の Secret として安全に渡し、リポジトリやログに平文で残さないことが鉄則です。両者はセットで管理し、どちらかを再発行したらもう一方の設定も更新します。
IdP 側の設定とつまずきポイント早見表
IdP 側では「SCIM URL」「認証トークン」「属性マッピング」「同期対象グループ」の 4 点を設定します。ここでの取りこぼしが、同期されない・エラーになる原因のほとんどを占めます。よくある症状と対処を早見表にまとめました。
| 症状・エラー | 原因 | 対処法 |
|---|---|---|
| ユーザーが同期されない | アプリにグループが割り当たっていない / 必須属性が未マッピング | IdP でアプリにグループを割り当て、email など必須属性をマッピングする |
| 401 Unauthorized | bearer token の不一致 | IdP に入力した token と SCIM Bridge の scimsession が対応しているか確認し、必要なら再発行 |
| Entra ID で接続テストが失敗 | Base URL の末尾にスラッシュが付いている | 末尾スラッシュを外し .../scim/v2 で終える(Entra ID で頻出のミス) |
| SCIM Bridge に接続できない | TLS 証明書・独自ドメインが未設定 | HTTPS で到達可能か、証明書が有効かを確認する |
| グループは同期されるがメンバーが空 | プッシュ設定でグループメンバーシップが未有効 | IdP 側で「Push groups」やメンバー同期のオプションを有効化する |
とくに Microsoft Entra ID の Base URL 末尾スラッシュは、接続テストが通らない典型パターンです。中規模以上でアクセス権限を継続的に棚卸ししたい組織にとっては、1Password Business の SCIM 連携で「誰がどの Vault に入れるか」を IdP のグループに一元化できることが、運用負荷を下げる最大の効果になります。
同期の検証とロールバック手順
本番のユーザー全員をいきなり同期対象にするのは危険です。必ずテストグループで検証してから範囲を広げます。検証の観点は次の 3 つです。
- 作成: IdP でテストユーザーをアプリに割り当て、1Password 管理画面にアカウントが発行されるか
- 付与・剥奪: グループを付け外しして、対応する Vault へのアクセスが増減するか
- 凍結: IdP でユーザーを無効化して、1Password 側で suspend(凍結)されるか

うまくいかない場合は、IdP 側でプロビジョニングを一時停止すれば同期を止められます。緊急時は bearer token を失効させることで SCIM Bridge 経由の変更を即座に遮断できます。SCIM で凍結・剥奪した操作の証跡を残したい場合は、1Password の監査ログ運用ガイド で Events API や SIEM 連携の設計を整理しています。
弊社でも社内および AI 受託開発の認証情報を 1Password で運用しており、SCIM 連携や SSO 接続の設計・検証を支援できる体制です。導入初期の属性マッピング設計やテスト運用の切り分けは、ここでつまずくと差し戻しが増えるため、最初の設計で押さえておくのが安全です。
まとめ:SCIM 自動プロビジョニングで権限管理を自動化する
1Password の SCIM 自動プロビジョニングは、Business 以上のプランと SCIM Bridge(またはホスト型 automated provisioning)があれば構築できます。ポイントは 3 つ。(1) Okta / Entra ID ならホスト型で手早く、それ以外はセルフホストを選ぶ、(2) scimsession と bearer token を安全に扱い、Entra ID の Base URL 末尾スラッシュなど定番ミスを早見表で先回りする、(3) 本番前に必ずテストグループで付与・剥奪・凍結を検証する。この順で進めれば、退職者アカウントの消し忘れをなくし、アクセス権限の棚卸しを IdP に一元化できます。まずは自社の IdP がホスト型対応かどうかの確認から始めましょう。
※情報は 2026-07-06 時点の内容です。最新情報は公式サイトをご確認ください(料金は https://1password.com/jp/pricing 、GCP デプロイ例は https://support.1password.com/scim-deploy-gcp/ を参照)。
※本記事には PR を含みます。
Footnotes
-
1Password Support「Set up automated provisioning using the 1Password SCIM Bridge」 https://support.1password.com/scim/ ↩
-
1Password/scim-examples(GCP / DigitalOcean / Azure Container Apps などのデプロイテンプレート) https://github.com/1Password/scim-examples ↩
よくある質問
関連記事

1Password Business プラン徹底比較 2026 - 社員規模別コスト目安と Teams Starter Pack の使い分け


