こんにちは。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

Control Plane 部 認証認可グループ（※1）のエンジニアリングマネージャーをしている先山( @ksakiayma134 )です。 現在キャディは、CADDi Drawer と CADDi Quote といった複数のアプリケーションをお客様へ提供する「コンパウンド戦略（マルチプロダクト化）」を推し進めています。 こうした複数アプリケーションを展開するアプリケーションアーキテクチャでは、共通利用する機能をプラットフォームレイヤーとして切り出すことが一般的です。私たちも認証・認可機能をプラットフォーム化し、各アプリ開発者へ提供しています。 本記事では、現在のキャディの認証認可を支えているシステム群についてご紹介します。 Control Plane 部について 一般的な説明 まず、「Control Plane」という言葉について簡単に触れておきます。 一般的に SaaS アーキテクチャにおける Control Plane とは、 AWS のホワイトペーパー 等でも定義されている通り、「テナント（顧客）の管理」と「アプリケーションの機能」を分離した管理層のことを指します。 具体的には、テナントのライフサイクル管理（作成・削除）、認証・認可、課金、メトリクス集計など、すべてのテナントに横断的に適用される運用機能を担うシステム群です。これらをアプリケーション層（Application Plane）から切り出すことで、各アプリチームは純粋な機能開発に集中できるようになります。 認証認可グループの位置づけ 認証認可グループは、現在この Control Plane 部に所属しています。 これは「逆コンウェイの法則」を意識した組織設計です。つまり、システムの「ありたい姿（認証認可が独立したプラットフォームである状態）」を先に定義し、それに合わせて人員配置や組織構造を決定しました。 もともと認証認可グループは、CADDi Drawer の認証認可のみを責務としていました。しかし、コンパウンド戦略を遂行するにあたり、CADDi Drawer と密結合だったシステムを切り離し、独立して運用する必要があります。 すでに切り離しが完了したものもあれば、まだ密結合で疎になっていないものもあり、現在進行系で鋭意分離を進めているフェーズです。 Control Plane を支えるシステムたち 認証プラットフォーム CADDi Drawer や CADDi Quote 等、全アプリの認証を支える共通基盤です。 以前は、すべてのアプリケーションが個別に nextjs-auth0 SDK を組み込み、それぞれが OIDC Client として機能する構成をとっていました。 各アプリがそれぞれOIDC Clientを実装するイメージ この方法でもスケーラビリティは担保できますが、組織が拡大するにつれて以下のような課題が目立ってきました。 変更容易性の低下: 認証認可グループ側で基盤的な修正を入れたい場合、各アプリ側の設定変更やデプロイまで面倒を見なければならない。 コミュニケーションコストの増大: 新規アプリの立ち上げ時、開発者が OIDC/OAuth2 のパラメータ（Callback URL や Scope 等）を深く理解していないと設定が完了せず、都度認証認可グループのサポートが必要になる。 ライブラリ依存のリスク: 例えば nextjs-auth0 v4 のような破壊的な変更が入った際、各アプリチーム側でのバージョンアップ対応負荷が高く、統制が取りづらい。 そこで私たちは、各アプリが個別に OIDC フローをハンドリングするアーキテクチャをやめ、認証フローそのものを中央でコントロールする仕組み（Gateway/Proxy パターン）に切り替えました。 アーキテクチャのイメージとしては、OSS の oauth2-proxy に近いです。 認証 Proxy で実装したイメージ また、この刷新に合わせて、システム内部では Auth0 のトークンではなく、CADDi 独自の Internal Token を利用するよう変更しました。これは、JWT の Claim（情報）を自分たちで柔軟にコントロールするためです。 外部 IDaaS である Auth0 に内部ロジックやデータを依存させると見通しが悪くなるため、Auth0 は「認証」に特化させ、複雑な「認可」情報は Internal Token へ寄せる判断をしました。 M2M Token Issuer ユーザーの操作を介さないシステム間通信（System-to-System Call）や、バッチ処理などのワークロードに向けた仕組みです。 先の認証プラットフォーム刷新により、システム内部の API 認証は Internal Token に統一されました。そのため、ユーザー操作を伴わないワークロードであっても、同様に Internal Token を取得できる手段が必要になります。 そこで、OAuth2 の Client Credentials Flow を用いた、社内専用のトークン発行システム「M2M (Machine to Machine) Token Issuer」を開発しました。 現在はシンプルに client_id / client_secret を各ワークロードに配布して運用していますが、将来的にはこのような手動での鍵配布（アウトオブバンド運用）が不要な方式への移行を展望しています。 例えば OAuth 界隈でも OAuth SPIFFE Client Authentication がドラフトとして存在しているように、ワークロードの Identity をどう証明・管理するかという課題にも、認証認可グループとして積極的に向き合っていく予定です。 Tenant Platform Control Plane の中核である「テナント管理」も、認証認可グループの重要な責務です。 現在、私たちはテナント情報（どの顧客が何のプランを利用しているか、どの機能オプションが有効か等）を Tenant Platform というシステムにて保管しています。 以前これらの情報は CADDi Drawer のデータベース内に格納されていましたが、独立したサービスとして分離し、CADDi Quote 等の他システムからも統一されたインターフェースで参照できる状態にしています。 こうしてデータを中央に集約することで、各アプリ開発チームが個別に似たような管理データを持つ必要がなくなります。 また重要な点として、ここには「マルチテナント SaaS を制御するための管理データ（Metadata）」のみを保存しており、お客様の業務データ（図面データ等）は保存していません。このように責務を明確に分離することで、お客様の保存するデータ領域（Data Plane / Application Plane）との境界線を明確に引くアーキテクチャを実現しています。 顧客のテナント管理UIシステム お客様側の管理者（Administrator）のみが実行可能な操作を提供するフロントエンドアプリケーションです。 ユーザーの招待、権限（ロール）変更、アカウントブロックなどを行える画面等をホスティングしています。 このような管理画面は各アプリチームが独自に開発するのではなく、認証認可グループが提供する UI を利用することとしています。 まだ公開できないシステムたち ここで紹介したもの以外にも、鋭意開発中のシステムや、まだ公開できないプロジェクトが複数動いています。 正直に申し上げますと、システムの分離はまだ完全ではありません。今でもレガシーな構成で残っているシステムは存在します。 切り離しを確実かつ安全に進めていけるような体制やプロジェクトを、着実に組成していく予定です。 また R&D の一環として、Google Zanzibar や昨今の認可技術の潮流（※2）を参考に、社内で利用可能な「汎用的な認可制御システム」の検証なども行っています。 We're hiring! Control Plane 部では、現在バックエンドエンジニア、および認証認可エンジニアを絶賛募集中です！ 現時点で OIDC や OAuth の深い知識がなくても、入社後にキャッチアップしていただければ問題ありません。 特定のプロトコルに詳しいことよりも、「スケーラブルなプラットフォームをどう設計・構築するか」という視点や、バックエンドエンジニアとしての汎用的な設計力を重視しています。 また、認証認可エンジニアの方にとっては、「自分たちで OIDC をスクラッチ実装できないから退屈」と思われるかもしれません。しかし、逆に言えば、認証のコアを Auth0 に任せることで、より高度な認可制御やプラットフォーム全体のアーキテクチャ設計にレバレッジを効かせられる環境でもあります。 技術スタックとしては、バックエンドでは Go を積極的に採用しており、サービスメッシュ層での認証制御なども行っています。 SaaS を支える共通基盤（Control Plane）という、攻めがいのある領域に興味がある方、ぜひ一度お話ししましょう。 カジュアル面談はこちらから！ open.talentio.com ※1: 社内では IAM (Identity and Access Management) Group という名称で活動しています。 ※2: AWS の Cedar や SpiceDB などが台頭してきている印象を持っています。