こんにちは。LINEヤフー研究所の大神と田口です。パスワードを使わない認証方法として、「パスキー（Passkey）」を目にする機会が増えてきました。パスキーを使う認証（パスキー認証）では、端末の画面ロ...

ビジネスのデジタル化が進む中、もはや「ただのオンラインストレージ」の枠を超え、チームの共同作業プラットフォームとして欠かせない存在になった Dropbox。 しかし、いざ導入や見直しを検討すると「Standard、Advanced、Enterprise……結局、自社にはどれが最適なの？」という壁にぶつかりがちです。プランを間違えると、コストが無駄になったり、逆にセキュリティ要件を満たせなかったりすることも。 今回は、企業向けDropboxの3プランの決定的な違いと、迷わず選ぶための「簡単選択ガイド」をお届けします。 特に、次のようなお悩みをお持ちの方は必見です。 「プランが多すぎて、どこから比較すべきか分からない」 「急増するデータの容量不足や、情報漏洩対策に頭を悩ませている」 「ファイルサーバーからの移行、業務を止めずにできるか不安……」 この記事を読めば、自社に最適なプランと、スムーズな導入の進め方が見えてきます。 企業向けDropbox 3プランの比較表 まずは、主要な機能を横並びで比較してみましょう。                機能・項目 Standard Advanced Enterprise 主な対象 小規模なチーム 中堅〜大規模組織 主に大規模企業 高度な管理・制限が必要な組織 ストレージ容量 合計5TB（チーム全体） 15TB〜（5TB xユーザ数） 必要なだけ ファイル単位のアクセス履歴 なし ✓ ✓ SSO連携 なし ✓ ✓ ランサムウェアの検知と復元 なし ✓ ✓ 不審なアクティビティのアラート なし ✓ ✓ エンタープライズモビリティ管理連携 （モバイルデバイスの制限） なし なし ✓ データ保持/復元 180日間 365日間 365日間   ズバリ、自社にはどれ？「簡単選択ガイド」 「機能一覧を見てもピンとこない」という方のために、判断基準をシンプルにまとめました。 【Standard】を選ぶべきケース 利用人数が10名以下で、扱うデータがテキストや一般的なOffice文書中心（合計5TBで足りる）。 まずは手軽に、場所を選ばない働き方を実現したい。 【Advanced】を選ぶべきケース 「容量不足を気にしたくない」 。動画やCADデータなど重いファイルを頻繁に扱う。 「誰が、いつ、何をしたか」 を詳細なログで追跡する必要がある。 シングルサインオン（SSO）を導入して、ID管理を一元化したい。 【Enterprise】を選ぶべきケース 数千名規模のユーザを管理する必要がある。 高度なガバナンス （モバイルデバイスの利用制限、社内での個人アカウントの利用制限など）が必須。 ストレージ容量が1PBを超えてくる可能性がある。   「ライセンスを買って終わり」にしない。SCSKが選ばれる理由 Dropboxは非常に使いやすいツールですが、企業導入において最大のハードルとなるのが「既存環境からの移行」 と 「運用ルールの徹底」です。 SCSKでは、単なるライセンス販売にとどまらず、お客様の「困った」を解決する以下のメニューを揃えています。 ① 移行の不安を解消する「データ移行支援」 セルフデータ移行ツールの提供 「自分たちで安価に、でも確実に移行したい」という方向けに、SCSK独自の移行支援ツールを提供しています。 関連記事： 【決定版】Dropboxへのデータ移行を自力で効率化！SCSK「セルフデータ移行ツール」忖度なしレビュー – TechHarmony 移行作業の請負（大規模案件向け） 「ファイルサーバーに数テラバイトのデータがあり、業務を止めずに移行するのは無理……」という場合は、SCSKのプロフェッショナルが移行計画の策定から実作業までを代行します。 100TBを超えるような超大規模の移行実績 もございますので、安心してお任せください。            関連記事： 東急建設株式会社 様｜お客様事例｜SCSK株式会社 ② 「使いこなし」を加速するトレーニング 導入しても使われなければ意味がありません。 管理者が安心して運用するための 管理者向けトレーニング ユーザーが迷わず使いこなすための 利用者向けトレーニング これらをセットで実施し、スムーズな定着を支援します。 ③ 安全性を高める「認証システム連携」 Microsoft Entra ID（旧 Azure AD）やIDaaSとの連携設定も、技術的な知見を持つSCSKにお任せください。セキュアで利便性の高いSSO環境を構築します。   まとめ Dropboxのプラン選びは、現在の人数だけでなく、「将来のデータ量」 と 「必要なガバナンスレベル」を見極めるのがコツです。 「自社の要件だと、Advancedで足りるかな？」「移行のコスト感を知りたい」といった具体的なご相談があれば、ぜひお気軽にお問い合わせください。日本初のDropbox認定サービスパートナーとして培ったノウハウで、最適な環境づくりをお手伝いします。 本投稿に関するお問合せ先：　 Dropbox-sales@scsk.jp SCSKのDropbox取り組み紹介： https://www.scsk.jp/product/common/dropbox/index.html

ニフティで利用しているAWS、Notion、GitHubなどのクラウドやSaaSの管理・運用を担当している石川です。 最近社内で利用しているIDaaS（Identity as a Service）をOneLoginからMicrosoft Entra ID（旧Azure AD）へ移行しました。 同じ「IDaaSの切り替え作業」でも、アプリケーションごとに事情はまったく異なり、想定外のハマりどころが数多くありました。本記事では、実際の移行作業を通じて得られたノウハウを共有します。今回は私が移行したアプリの中でも AWS、GitHub Enterprise 、 Notion 、Redash の4つを例に取りつつ説明していきます。 この記事の読み方 各セクションの内容を 一般論 （IDaaS移行全般で押さえるべき知識）と 体験談 （筆者が実際に経験した具体事例）に分けています。 IDaaS移行は「認証設定の差し替え」だけではない 1. ユーザープロパティの確認と表示名の定義 移行を機にデータが「整理」されることがある 表示名の設計は悩みどころ 2. Entra IDのグループ管理の注意点 3. IDaaSごとに異なるマッピングの仕様 4. アプリごとに異なるプロビジョニングの挙動 5. IDaaS移行時のセッション・トークンへの影響 6. グループプロビジョニングの罠 ネストされたグループは同期できない 旧IDaaSで作成されたグループは引き継げない グループ削除時の権限孤立リスク Entra IDのプロビジョニング間隔は40分固定 OneLoginからの移行で行ったグループ切り替え手順 Notionでの権限孤立チェックの限界 グループプロビジョニングは多用しないのが無難 7. アプリのバージョンが古い場合のリスク 対応策の検討 8. 申請フロー・運用ワークフローの再構築 AWS IAM Identity Centerグループ管理のTerraform化 まとめ IDaaS移行は「認証設定の差し替え」だけではない IDaaSを変えるというと、SAML設定のURLや証明書を貼り替えるだけに思えるかもしれません。しかし実際には、以下のような周辺領域にまで影響が波及します。 ユーザープロパティのマッピング （表示名・属性情報などの紐付け） IDaaS/SaaSごとのプロビジョニング（SCIM）挙動差異の把握 グループ管理の方式変更 既存セッションや認証トークンへの影響 申請フロー・運用ワークフローの再構築 認証設定そのものよりも、これらの周辺対応のほうがボリュームが大きいです。 1. ユーザープロパティの確認と表示名の定義 一般論 新旧のIDaaSで連携するADやLDAPが同じでも、 IDaaS側でのプロパティの持ち方や参照先が異なる ことがあります。 移行を機にデータが「整理」されることがある IDaaS移行のタイミングで、AD側の属性を正しいフィールドに寄せ直す（＝綺麗にする）動きが起きることがあります。その上で「名」と「体」が合っていないフィールドがあると、 一時的なものか恒常的なものかを事前に確認 しておかないと、マッピングで使っている値が突然変わるリスクがあります。 表示名の設計は悩みどころ SaaS側のユーザー表示名をどう構成するかは意外と悩むポイントです。 SaaSの挙動で特に確認すべき点は以下の2つです。 ユーザーサジェストはどのフィールドに対して行われているか → 表示名でしか行われないとローマ字でユーザーを検索できない、逆も然り 同姓同名の区別が付くか → ユニークなIDがないと区別が付かない → サジェスト時は補助情報としてユニークなIDが出て区別が付くが、設定後は区別が付かない場合もあり 体験談 検索サジェストやユーザー名オンマウスで、固有ID（メールアドレス or ユーザーID）を併記してくれているアプリに関しては表示名を 姓 名 。そうでないものに関しては 姓 名 メールアドレスのユーザー部 という併記構成にしています。冗長に見えますが、以下のメリットがあります。 常に同姓同名の区別 がつく 漢字の読み方がわからない場合もメールアドレスにある ローマ字で補完 できる TIPS : 通常であれば表示名には英字を推奨します。日本語話者が圧倒的多数の環境では 漢字 + ローマ字 の併記が現実的な妥協点になります。サジェストが前方一致でしか機能しないサービス（Amazon Qなど）もあるので、 ローマ字 + 漢字 のパターンも有効です。 2. Entra IDのグループ管理の注意点 一般論 アプリによっては、全社員にデフォルトで権限を与えるものがあります。その場合、以下のような流れでライセンスが消費されます。 Entra IDにユーザーが追加される Entra IDの特定グループ（動的グループ）に自動で追加される そのグループにアプリの利用権限が付与されている アプリにユーザーがプロビジョニングされる アプリの利用シートが増える つまり、Entra IDにユーザーを追加すると同時に、アプリのユーザー数が増えてライセンスが消費または追加されます。 事前に確認すべきポイントは2つです。 動的グループがどのような基準で構成されているか その基準に合致するプロパティが、どのような運用で付与されるか 例えば、Entra ID上でテストアカウントを作成したところ、意図せず動的グループに含まれてしまい、アプリ側のユーザーが自動生成されてライセンスが消費される、といったことが起こり得ます。 体験談 移行前に確認したところ、人間だけのはずのグループにテストアカウントが含まれていたり、入社の数ヶ月前からアカウントが存在していてライセンスが無駄に消費されていたりするケースがありました。 また過去には、LDAPで更新ミスが発生し大量のユーザーが削除されたことがありました。その際、LDAP連携していたIDaaSおよびプロビジョニング先のアプリ側でも、大量のユーザーが無効化される障害が発生しました。 ユーザーの無効化・削除によって保管データに不可逆な変化が生じるタイプのアプリでは、プロビジョニングの誤削除防止機能を有効化し、閾値を設定することを強く推奨します。 Microsoft Entra プロビジョニング サービス で誤削除防止機能を有効にする – Microsoft Entra ID | Microsoft Learn 3. IDaaSごとに異なるマッピングの仕様 一般論 Entra IDでは、プロビジョニング時の属性マッピングに 独自の式 を使います。 Join() 、 IIF() 、 Replace() などの関数を組み合わせてフィルターや値変換を行うことができます。 Microsoft Entra アプリケーションのプロビジョニングで属性マッピングの式を記述するためのリファレンス – Microsoft Entra ID | Microsoft Learn 体験談 # 表示名を 姓 名 メールアドレスのユーザー部にする式 Join(" ", [surname], [givenName], Item(Split([mail], "@"), 1)) # 特定のグループは同期先では別名に置換、決まったprefixが付いたグループはprefixを置換して同期 IIF( [displayName] = "ほげほげ", "group-hogehoge", IIF( [displayName] = "ふがふが", "group-fugafuga", IIF( InStr([displayName], "YourApp-team-", , ) > 0, Replace([displayName], "YourApp-team-", , , "team-", ), [displayName] ) ) ) 上の例はNotionの表示名マッピングですが、こうした式を 本番で一発勝負で試すのは危険 です。 SCIMに対応した検証用アプリを用意して、本番適用前にマッピング式の動作確認をしましょう。Entra IDには式ビルダーのテスト機能もありますが、実際のプロビジョニング結果で確認するのが確実です。 4. アプリごとに異なるプロビジョニングの挙動 一般論 SCIMプロトコルを使っていても、 利用するIDaaSとSaaSによって挙動が異なります 。 体験談 過去、実際に遭遇した問題は以下のとおりです。 SaaSのSCIMエンドポイントへの アクセス過多でエラー （初回同期時） IDaaS or SaaSのSCIMが RFCどおりに実装されておらず 、一部の同期処理が失敗 IDaaS or SaaSが グループ名変更やグループ削除に対応していない グループプロビジョニングで メンバーの同期状態と実態に齟齬 がよく出る サポートに依頼して改修してもらったり、自前でSCIM APIを叩いて同期用Lambdaを動かしたりと、正常な状態にするまでにはそれなりに時間がかかります。 そのため、できる限り検証環境を用意して事前に確認することを推奨します。ただし、SaaSでは 検証環境の用意が難しい ため、本番環境で一発勝負になることもあります。 今回は、自前での用意が難しいものだけ検証なしで本番一発勝負で切り替えました。 Notion：本番環境で一発勝負 SAML SSOはOrganizationレベルの設定のため、Workspaceごとの事前検証が不可能 GitHub Enterprise Cloud：日常的に使っていないOrganizationで検証 SAML SSOをEnterpriseレベルで行うとSCIMが利用できないため、Organizationレベルで設定 AWS：検証用の別Organizationで検証 Redash：検証用の別環境を作成 TIPS: GitHubのSCIM設定で、Azure AD OAuthアプリがひとつでもOrganizationに対して承認状態になっていると、SCIMセットアップ時のGitHub OrganizationにGrantする画面が表示されないという問題に遭遇しました。個人設定のOAuthアプリからRevokeすることで解消しましたが、ドキュメントに記載がないのでハマりどころです。 5. IDaaS移行時のセッション・トークンへの影響 一般論 SAMLのIdPを切り替える際は、既存セッション・認証トークンへの影響をアプリケーションのサポートに事前確認することが重要です。 体験談 GitHubでの移行時に、影響範囲を事前にGitHubサポートへ確認しました。 Enterprise管理者のアカウントから英語で質問するとレスポンスが早い気がします。 項目 影響 対応 ブラウザアクセス 再認証が必要 SAMLで保護されたリソースにアクセスする際に、新しいIdP（Entra ID）での認証が必要 既存セッション 有効期限まで維持 強制的なログアウトはないが、期限切れ後の再ログイン時に再認証 OAuth/PAT 機能継続 特別な対応不要 Copilot 初回のみ再認証 変更後の初回使用時に再サインインとSAML SSO完了が必要 GitHub OrganizationのIDaaS切り替え時の認証情報への影響 TIPS: IDaaS変更についてドキュメントに具体的な記載がないことがままあります。影響がないかサポートに問い合わせましょう。また影響があるにしろないにしろ、切り替え前にユーザーへの周知を忘れずに。あとで来る問い合わせの量が減ります。 6. グループプロビジョニングの罠 IDaaSとの連携で一番厄介だと思っているのがグループプロビジョニングです。 一見便利なのですが運用まで考えると考慮しないといけない事項が多くて、有効活用できるシーンは限られます。 一般論 ネストされたグループは同期できない Entra IDのSCIMプロビジョニングは、 ネストされたグループ（Group in Group）のメンバーを読み取れません 。直接メンバーとして割り当てられたユーザー・グループのみが同期対象です。 Nested groups.  The Microsoft Entra user provisioning service can’t read or provision users in nested groups. The service can only read and provision users that are immediate members of an explicitly assigned group. Understand how Application Provisioning in Microsoft Entra ID – Microsoft Entra ID | Microsoft Learn グループ設計時にネストを前提としている場合、フラットな構造に見直す必要があります。 旧IDaaSで作成されたグループは引き継げない 旧IDaaSのグループプロビジョニングで作成されたグループを、Entra IDで そのまま同期状態で引き継ぐことはできません 。グループにはメールアドレスのようなユニークIDにしやすい項目が存在しないため、IDaaS側が独自にIDを割り振ります。そのため、移行時にIDを引き継げず、グループの再作成が必要になります。 グループ削除時の権限孤立リスク 削除予定のグループだけに権限が付いたリソースがないか、事前に確認が必要です。そのグループが唯一の権限付与先になっている場合、削除後にリソースへアクセスできなくなります。 Entra IDのプロビジョニング間隔は40分固定 Entra IDのグループプロビジョニングは約40分間隔で実行されます。即時性がないため、急ぎのオペレーションにはグループプロビジョニングは不向きです。ユーザー単位のプロビジョニングならばオンデマンドで実行できるため、少数であれば手動での即時同期が可能です。 体験談 OneLoginからの移行で行ったグループ切り替え手順 OneLoginで作成されたグループをEntra IDに引き継げなかったため、以下の手順で対処しました。 旧グループを事前にリネーム （古いことを記すプレフィックスを付与）して名前の衝突を回避 Entra ID側で 新しいシンプルな命名規則 （YourApp- team-xxx ）でグループを再作成 グループプロビジョニング グループへの権限付与などを利用者に依頼（APIで再付与できない場合） 旧グループは棚卸しタイミングで削除 TIPS: グループのリネームはAPIがないと手作業になります。システム的にカバーできない手順がある場合は、数日前から計画的に進めるのがおすすめです。 Notionでの権限孤立チェックの限界 Notionではコンテンツ検索で対象グループが権限を持つページを洗い出せますが、 そのグループ「だけ」が権限を持っているかどうかは目視確認が必要 で、網羅的なチェックは困難でした。 グループプロビジョニングは多用しないのが無難 実際に運用を考えてみると、追加・削除・統合が発生する組織変更のたびにグループの付け替えや廃止管理に悩まされます。SaaS側にグループ管理の手段がSCIMしかない場合を除き、グループプロビジョニングは最小限にとどめるのがよいと感じています。 7. アプリのバージョンが古い場合のリスク 一般論 SaaSではなくオンプレでOSSを動かしている場合、アプリケーションのバージョンが古いとIDaaSのSAML構成をそのまま組めないことがあります。 体験談 実際にこの問題に直面しました。利用しているRedash v10.1.0ではマニュアル通りでは動きません。 SAML & Azure/Entra · getredash redash · Discussion #7026 Authentication Options (SSO, Google OAuth, SAML) 対応策の検討 案 結果 Redashをアップグレード アップグレード後の動作確認に手間がかかるため最終手段 別のIdPを使う（AWS IIC等） 動作はしたので選択肢としてあり 設定だけで回避する 動作したので採用 Redash v10.1.0だとEntra IDのSAML認証が通らないバグ、どこかで見た話だなと思ったら過去にOneLoginでも同じような不具合を喰らっていました。 RedashをECS Fargate構成にしてv7からv10へアップグレードする – NIFTY engineering マニュアルだとEntity IDにRedashインスタンスのURLを入れるようにと書いてますが、Microsoft Entra Identifierを入れれば利用できるようになります。これならコード修正・イメージ再作成も不要です。 TIPS: OSSのドキュメントやIssueの情報を鵜呑みにせず、実際に試してみることが大事です。なお、FirstName, LastNameのクレーム名に名前空間は不要でした。 8. 申請フロー・運用ワークフローの再構築 一般論 IDaaS移行に伴い、以下のような 運用フローの再構築 が必要になる場合があります。 アプリ利用者の追加・削除フロー グループ作成・メンバー変更の申請フロー 例外的なメンバー追加の手順 退職者管理の仕組み 一連の自動化処理 この部分は日常的な運用工数や利用者の使い勝手に直結するため、しっかりとフローを設計して手作業の運用は可能な限りゼロにすることを目指しましょう。 体験談 AWS IAM Identity Centerグループ管理のTerraform化 AIで加速するAWS運用効率化 〜IAM Identity Center IssueOpsとセキュリティ基準自動作成〜 | ドクセル AWS IAM Identity Center（以下AWS IIC）への権限割り当てには、TerraformによるGitOpsを採用しています。今回の移行に伴い、グループ作成とメンバー割り当てもできるように改修しました。 グループへの割り当てでは、実際に誰が何の権限を得るのか分かりにくくなるため、レビューをサポートするGitHub Actionsを追加しました。 まとめ IDaaSの移行は、表面的には「認証設定の差し替え」ですが、実態は アプリケーションごとの仕様差異・制約・運用フロー再構築との格闘 です。 IDaaS移行で押さえておきたいポイント ユーザープロパティの差異 を事前に洗い出す Entra IDのグループ管理 の基準や動的グループの挙動を確認する マッピング式 はIDaaSごとに仕様が異なるため、検証環境でテストする プロビジョニング挙動はアプリごとに異なる 前提で、できること・できないことを整理する セッション・トークンへの影響範囲 をサポートに確認し、ユーザーへ周知する グループのネスト非対応 やグループ引き継ぎ不可など、SCIMの仕様制約を把握する アプリのバージョン が古いとそもそもSAML構成ができないことがある 運用フローの再構築 （申請・自動化）まで含めて移行計画を立てる 同様の移行を検討されている方の参考になれば幸いです。