オンプレファイルサーバーからBoxへ移行する際に見直すべき権限設計とは、ファイルサーバーのアクセス権限をそのままBoxに置き換えるのではなく、Box特有の権限継承や共有リンクの仕組みに合わせてフォルダ構成・権限ルールを再設計することです。
移行を単なるデータ移行だけで終わらせると、意図しない社内外への公開や過剰な権限付与が起こりやすくなります。
【結論】 ファイルサーバーとBoxとでは権限の仕組みが異なるため、フォルダ構成や権限をそのままコピーすると意図しない権限が発生しやすくなります。
ファイルサーバーのACL（許可・拒否）とBoxの権限モデルは仕組みが異なる
Boxのコラボレーター権限は上位フォルダから下位フォルダへ引き継がれる「ウォーターフォール構造」で、NTFS ACLのような明示的な「拒否（Deny）」は設定できない
移行時は、現行権限の棚卸し→フォルダ階層の再設計→グループとロールの対応表作成→外部共有ルールの決定→管理コンソール設定、の順で見直す
移行後も定期的な権限棚卸しと異動・退職時の権限見直しを運用に組み込むことが重要
本記事では、ファイルサーバーとBoxの権限モデルの違いを整理したうえで、移行時に権限設計を見直す具体的な手順と、よくある失敗を解説します。
1. オンプレファイルサーバーとBoxで権限の仕組みは何が違うか？
ファイルサーバーとBoxでは、権限を管理する単位や継承の仕組みが根本的に異なります。
多くのオンプレファイルサーバーでは、Windows OSのNTFSアクセス制御リスト（ACL）によって、フォルダやファイルごとに「許可」と「拒否」を細かく設定できます。
多くの企業では、Active Directory（AD）のセキュリティグループに対して読み取り・書き込み・フルコントロールといった権限を割り当て、部署やプロジェクト単位でアクセス範囲を管理しています。
上位フォルダの権限は下位フォルダへ引き継がれるのが基本ですが、下位フォルダ側で個別に「拒否」を設定して上書きすることも可能です。
この「例外的に拒否できる」柔軟さが、ファイルサーバーならではの設計思想といえます。
Boxでは、フォルダやファイルを共有（コラボレーション）した相手に対して「コラボレーター権限（共同作業者ロール）」を割り当てる方式で権限を管理します。
AD/NTFSのような「許可・拒否」の概念ではなく、招待した相手に段階的な役割を割り当てる仕組みであり、後述のとおり「拒否」に相当する設定は用意されていません。
また、権限は上位フォルダから下位フォルダへ一方向に引き継がれる、いわゆる「ウォーターフォール構造」が採用されています。
この構造は、ファイルサーバーからの移行時にもっとも見落とされやすいポイントの一つです。
（出典：Box「項目の権限について」）
Boxのアクセス制御・共有運用では、主に「コラボレーター権限」「共有リンク」「グループ」の3つを利用します。
Boxのコラボレーター権限は、次の7段階に分かれています（2026年8月時点。実際に選択できる役割はプランやコンテンツの種類によって異なるため、詳細は公式ドキュメントでご確認ください）。
|
役割 |
主な権限 |
|
共同所有者 |
編集者の権限に加え、一部の高度なフォルダ設定も変更可能（所有者の変更は不可） |
|
編集者 |
閲覧・ダウンロード・アップロード・編集・削除・共有リンク作成が可能 |
|
ビューアー/アップローダー |
閲覧・ダウンロード・アップロード・ファイル編集（Box Edit等）が可能。タグ付け・招待・削除は不可 |
|
プレビューアー/アップローダー |
プレビュー・アップロード・コメント・タスクの追加が可能（ダウンロード・編集・共有リンク作成は不可） |
|
ビューアー |
閲覧・ダウンロード・コメント・共有リンク作成が可能 |
|
プレビューアー |
プレビュー・コメント・タスクの追加などが可能（ダウンロード・アップロード・編集・共有リンク作成は不可） |
|
アップローダー |
コンテンツのアップロードが可能（ファイル内容の閲覧・ダウンロードは不可） |
上記に加えて、フォルダの所有者は、フォルダに対して最も広い管理権限を持ちます。
ただし、管理者設定や保持ポリシーなどにより、一部の操作が制限される場合があります。
共有リンクでは、管理者設定で許可された範囲内で、アクセスできる範囲を「招待されたユーザーのみ」「会社のユーザー」「リンクを知っている全員（オープン）」の3段階から選択できます。
（出典：Box Developer Documentation「共有リンク」）
さらに、閲覧のみに制限するかダウンロードも許可するかを切り替えられるほか、プランによってはパスコードや有効期限の設定も可能です。
オンプレのファイルサーバーには、この「リンクを知っている人なら社外からでもアクセスできる」という概念自体が基本的に存在しないため、移行時に新たに検討すべき設定項目になります。
Boxのグループ機能は、複数のユーザーをまとめて登録し、フォルダへの招待や権限付与をグループ単位で一括管理できる仕組みです。
管理者コンソールから手動で作成することも、外部のID管理サービス（Microsoft Entra ID〈旧Azure AD〉など）と連携して自動的に同期することもできます。
ファイルサーバーで運用してきたADのセキュリティグループをそのままBoxのグループに置き換えられるかどうかは、契約プランや利用しているID管理・プロビジョニング連携の方式によって異なるため、移行前に確認しておく必要があります。
移行時に権限設計を見直す必要があるのは、ファイルサーバーとBoxとで権限の継承や公開範囲の考え方が根本的に異なるためです。
Boxの権限は、上位フォルダで付与された権限が下位フォルダ・ファイルにそのまま引き継がれる「ウォーターフォール構造」になっています。
ファイルサーバーの感覚で、まず全社共有フォルダの直下に部署フォルダをまとめて作成し、そこに幅広いアクセス権を付与してしまうと、その配下にある個別プロジェクトの機密フォルダにまで、意図せず同じ権限が及んでしまうことがあります。
ファイルサーバーのNTFS ACLでは、上位フォルダで許可されたアクセス権を、下位フォルダ側で「拒否」に設定して個別に取り消すことができました。
一方Boxのコラボレーター権限には、この「拒否」に相当する設定が存在しません。
特定のユーザーだけを下位フォルダで除外したい場合は、下位フォルダでそのユーザーの権限だけを弱めたり削除したりすることはできません。
フォルダ構成自体を分けるか、権限の起点となる上位フォルダ側でコラボレーターやアクセス対象を見直す必要があります。
「まず広く許可してから、必要な範囲だけ拒否で絞る」というファイルサーバー時代の発想から、「最初から必要な範囲だけを許可する」設計へ転換する必要があります。
ファイルサーバーの多くは社内ネットワークやVPN経由でしかアクセスできず、外部への公開手段は限られていました。
Boxでは共有リンクを「リンクを知っている全員」に設定するだけで、Boxアカウントを持たない社外の相手にも即座にファイルを渡せます。
この手軽さは業務効率の面で大きなメリットですが、ファイルサーバー時代の「社内で共有する」感覚のまま共有リンクを多用すると、意図しない社外公開につながるリスクがあります。
Box利用時の社外との共有方法における注意点は、以下の記事でも整理しています。
Box移行時の権限設計は、次の5つのステップで進めるのが現実的です。
ステップ1: 現行のアクセス権限とADグループを棚卸しする
ステップ2: Boxのフォルダ階層と権限方針を設計する
ステップ3: グループとロールの対応表を作る
ステップ4: 外部共有・共有リンクのルールを決める
ステップ5: 管理コンソールでガバナンス設定を行う
最初に、現行のファイルサーバーでどのフォルダに誰が（どのADグループが）どの権限を持っているかを棚卸しします。
長年運用してきたファイルサーバーでは、退職者や異動者に付与されたままの権限、個別に「拒否」設定で例外運用しているフォルダなど、実態が管理資料と食い違っているケースも珍しくありません。
棚卸しの段階で不要な権限を洗い出し、そもそもBoxに引き継ぐべきかどうかを判断することが重要です。
棚卸しの結果をもとに、Boxのフォルダ階層を設計します。
ウォーターフォール構造を踏まえ、全社共有フォルダの配下には本当に全員がアクセスしてよい情報だけを置きます。
部署やプロジェクト固有の機密情報は、全社共有フォルダとは別のトップレベルフォルダや、アクセス対象を限定した親フォルダ配下に分離し、広い権限を継承しない構成にするのが基本方針です。
次に、ファイルサーバーで使っていたADグループと、Boxのグループ・コラボレーター権限をどう対応させるかを整理します。
例えば、一般メンバーには「ビューアー」、プロジェクトメンバーには「編集者」、部署の管理者には「共同所有者」を割り当てるといった形で、役割ごとの標準的な権限レベルをあらかじめ決めておくと、フォルダが増えても運用がぶれにくくなります。
外部の取引先やパートナーと共有する機会が多い場合は、共有リンクのデフォルトのアクセス範囲を「招待されたユーザーのみ」や「会社のユーザー」に設定し、社外向けに限って個別に「リンクを知っている全員」へ変更する運用にすると、意図しない公開を防ぎやすくなります。
加えて、フォルダ設定でコラボレーターを招待できるユーザーを所有者・共同所有者に限定したり、全社設定で外部コラボレーションを許可するドメインを制限したりすることで、共有の起点を絞る運用も検討に値します。
※利用できる外部コラボレーション制御機能は、契約プラン・オプションによって異なります。
最後に、管理コンソールで全社的なガバナンス設定を行います。
契約プラン・オプションに応じて、招待できる外部ドメインの制限、利用を許可するアプリケーション連携の制御、法令遵守のための保持ポリシーやリーガルホールドの設定などが対象です。
Microsoft Entra IDなどのID管理サービス（IdP）とBoxを連携し、ユーザー・グループのプロビジョニングやプロビジョニング解除を自動化しておくと、異動・退職に伴うアカウント管理の負担を軽減できます。
なお、SSOは認証を一元化する仕組みであり、アカウントの無効化やグループの更新そのものを自動化するものではないため、プロビジョニング連携とは区別して導入を検討する必要があります。
移行時の権限設計では、次のような失敗がよく見られます。
ファイルサーバーのフォルダ構成と権限をそのままコピーし、ウォーターフォール構造による権限の連鎖に気づかない
移行作業を進めやすくするため、全社共有フォルダの直下に「編集者」権限を広く付与し、そのまま絞り込みを忘れる
共有リンクの既定値が「リンクを知っている全員」のまま運用され、社外公開が常態化する
BoxのグループをActive Directory（AD）やMicrosoft Entra IDなどのID管理基盤と連携させず、異動後もグループの所属が更新されない
外部ユーザーとの共有ルールを移行前に決めておらず、現場ごとに場当たり的な共有が広がる
これらはいずれも、権限設計を「移行作業の一部」ではなく「移行後も運用し続けるルール」として捉えていないことが原因です。
棚卸しと設計を丁寧に行うだけでなく、運用ルールとして定着させることが欠かせません。
権限設計は、移行時に一度決めて終わりではなく、移行後も継続的に見直す運用が欠かせません。
半年～1年に一度など、定期的にフォルダの権限設定や共有リンクの一覧を棚卸しし、不要になった権限や、本来失効しているはずの共有リンクが残っていないかを確認します。
異動・退職が発生した際は、IdPとのプロビジョニング連携によるアカウントの無効化と合わせて、当該ユーザーが所有していたフォルダ・ファイルの引き継ぎも忘れずに行う必要があります。
Box管理コンソールでは、ユーザーを削除する際に、そのユーザーが所有していたコンテンツを別のユーザーへ引き継ぐ設定も可能です。
（出典：Box Support「Deleting Managed Users」）
ネットワークや端末の状態に応じてアクセス権限を自動的に切り替えたい場合や、PC端末側での情報持ち出し対策まで強化したい場合は、Box標準の権限設定に加えて専用のセキュリティ製品を組み合わせることも選択肢の一つです。
結論として、Boxのコラボレーター権限には、NTFS ACLのような明示的な「拒否（Deny）」に相当する設定はありません。
特定のユーザーだけを下位フォルダから除外したい場合は、下位フォルダで個別に「拒否」したり、継承された権限だけを削除したりすることはできません。
フォルダ構成を分けるか、権限の起点となる上位フォルダでコラボレーターやアクセス対象を見直す方法で対応します。
より柔軟にアクセスを制御したい場合は、端末や利用環境に応じて権限を動的に切り替える専用製品を組み合わせる方法もあります。
可能です。
編集を禁止しつつダウンロードを許可する場合は、社外のユーザーを「ビューアー」として招待できます。
ダウンロードも禁止して閲覧のみに制限したい場合は、「プレビューアー」として招待するか、共有リンクを「閲覧のみ（ダウンロード不可）」に設定します。
ウォーターマーク表示や高度な閲覧制限機能は、契約プランによって利用可否が異なるため、導入前に最新の提供条件を確認することをおすすめします。
異動の場合は、異動後の所属に応じてグループの付け替えとコラボレーター権限の見直しを行い、旧部署の機密フォルダへのアクセスは速やかに外します。
退職の場合は、IdPとのプロビジョニング連携によるアカウント無効化や、Box管理コンソールでのユーザー無効化・削除に合わせて、本人が所有していたフォルダ・ファイルの所有権を後任者や上長に引き継ぐ設定を行うことをおすすめします。
これらの操作を都度手動で行うと抜け漏れが発生しやすいため、退職・異動のフローにあらかじめ組み込んでおくとよいでしょう。
結論として、NTFS ACLをBoxへ完全に同じ権限構造のまま移行できるとは限りません。
Box Shuttleなどの移行ツールでは、コンテンツに加えてユーザー・アクセス権限のマッピングや移行前のシミュレーションにも対応していますが、NTFS ACLとBoxとでは権限モデル自体が異なります。
そのため、移行ツールを利用する場合でも、本記事で紹介した権限設計の見直しを移行前に行うことが重要です。
オンプレファイルサーバーからBoxへ移行する際の権限設計では、NTFS ACLの「許可・拒否」の発想をそのまま持ち込むのではなく、ウォーターフォール構造による権限継承と、共有リンクによる社外公開の仕組みを踏まえて設計し直すことが欠かせません。
現行権限の棚卸しから始め、フォルダ階層の再設計、グループとロールの対応表作成、外部共有ルールの決定、管理コンソールでのガバナンス設定という手順で進め、移行後も定期的な棚卸しと異動・退職時の権限見直しを運用に組み込むことをおすすめします。
「Box導入支援サービス Boxwitch」は、企画書・手順書等のドキュメント作成や、利用者への周知・教育を支援するサービスです。
Box Japan Approved SEの資格を持つ担当者が、フォルダ構成や権限方針の設計から社内への浸透までを伴走支援するため、本記事で紹介したステップを自社の担当者だけで抱え込まずに進めたい場合の選択肢になります。
「CL-UMP」は、働く環境や端末の状態に応じてBoxのアクセス権限を自動的に切り替えられるサービスです。
同一のBoxアカウントでも、社内ネットワークからのアクセスとリモートワーク先からのアクセスとで異なる権限を設定できるため、Box標準の権限設定だけでは難しい、利用環境に応じた柔軟なアクセス制御を実現したい場合の選択肢になります。
「CFKeeper」は、PC上の同期フォルダ内データを自動暗号化し、同期フォルダ外へのコピーや外部へのアップロードを制限できるサービスです。
Boxの権限設定を適切に行っても、同期済みのローカルファイルが端末の紛失や持ち出しによって流出するリスクは別途残るため、端末側の対策まで含めて権限設計を補強したい場合の選択肢になります。
弊社、サイエンスパーク株式会社は1994年の創業より、ソフトウェア・ハードウェアのセキュリティ対策を30年以上に渡り続けてまいりました。
セキュリティリスクの診断から対策導入・運用までのお手伝いが可能ですので、お気軽にお問い合わせくださいませ。ご相談だけでも大歓迎です。
参考情報・出典
・Box Developer Documentation「共有リンク」
・Box Support「Deleting Managed Users」
・Microsoft Learn「Microsoft Entra IDを使用した自動ユーザー プロビジョニング用に Box を構成する」