機密文書の権限管理をどう設計する？社内公開範囲・閲覧・編集権限の分け方

契約書、見積書、人事資料、経営資料、顧客情報などを社内システムで管理するとき、重要になるのが機密文書の権限管理です。

「ログインしている社員なら誰でも見られる」

という設計では、情報の重要度によっては適切ではありません。

一方で、

「文書ごとに閲覧できる社員を1人ずつ指定する」

という設計にすると、運用が複雑になりすぎることがあります。

機密文書の権限管理で重要なのは、文書の機密度と利用者の役割を整理し、「誰が・どの文書に・どの操作までできるか」を明確にすることです。

例えば、

• 全社員が閲覧可能
• 所属部署だけ閲覧可能
• 管理職だけ閲覧可能
• 指定されたユーザーだけ閲覧可能
• 閲覧はできるが編集できない
• 閲覧はできるがダウンロードできない

といった形で権限を分けます。

この記事では、機密文書を扱う社内システムを想定し、公開範囲の決め方、閲覧・編集権限、RBAC、ダウンロード制御、URLアクセス対策、監査ログなどを実務目線で解説します。

機密文書の権限管理とは

機密文書の権限管理とは、文書ごとに利用できるユーザーや操作を制御する仕組みです。

例えば社内文書管理システムに、次のファイルが登録されているとします。

• 就業規則
• 営業マニュアル
• 顧客との契約書
• 人事評価資料
• 役員会議資料
• 新規事業計画
• 給与関連資料

これらをすべて同じ権限で管理するのは適切とは限りません。

就業規則は全社員が閲覧できても、人事評価資料は人事担当者や対象となる管理職だけに制限したい場合があります。

そのため、文書管理では、

「誰がログインしているか」

だけでなく、

「そのユーザーが、この文書にアクセスしてよいか」

まで判定する必要があります。

機密文書では「閲覧できるか」だけでは不十分

権限管理というと、閲覧可能・閲覧不可だけを考えがちです。

実際の業務システムでは、操作ごとに権限を分けた方がよいケースがあります。

例えば、

• 閲覧
• 新規登録
• 編集
• 削除
• ダウンロード
• 印刷
• 共有
• 権限変更

などです。

営業部の一般社員は契約書を閲覧できるものの、

• 原本ファイルの削除
• 公開範囲の変更

はできないようにする、といった設計が考えられます。

つまり、

「誰が見られるか」と「見たあと何ができるか」を分けて設計する

ことが重要です。

最初に文書の公開範囲を整理する

権限機能を作る前に、社内でどのような公開範囲が必要なのかを整理します。

一般的には、次のような分類が考えられます。

1. 全社公開

ログインしているすべての社員が閲覧できる文書です。

例えば、

• 社内規程
• 社内マニュアル
• 全社通知
• 共通テンプレート

などです。

機密性が比較的低く、多くの社員が利用する情報に向いています。

2. 部署限定

特定の部署に所属する社員だけが閲覧できる文書です。

例えば、

営業部：
営業マニュアル、営業会議資料

経理部：
経理マニュアル、月次処理資料

人事部：
採用資料、人事関連資料

といった分け方です。

部署異動がある会社では、ユーザーの所属部署変更と文書権限が連動する設計も重要になります。

3. 役職・ロール限定

管理職や特定の役割を持つユーザーだけが閲覧できる方法です。

例えば、

• 部長以上
• 人事担当者
• 経理担当者
• システム管理者
• 役員

などです。

RBAC（Role-Based Access Control：役割ベースのアクセス制御）を利用すると管理しやすくなります。

4. プロジェクト・案件限定

特定のプロジェクトや案件に参加しているメンバーだけが閲覧できる方法です。

例えば顧客Aとのシステム開発案件について、

• 契約書
• 要件定義書
• 見積書
• 議事録

を案件参加者だけに公開します。

プロジェクト終了時に権限をどうするかも決めておく必要があります。

5. 個別ユーザー限定

特定のユーザーだけを直接指定する方式です。

例えば、

• 社長
• 人事部長
• 対象社員

だけが閲覧できる人事資料などです。

柔軟性は高いものの、文書ごとに大量のユーザーを指定すると運用が複雑になります。

そのため基本は部署やロールで管理し、例外的な文書だけ個別ユーザーを設定する方法が扱いやすいでしょう。

6. 作成者・所有者限定

文書を登録した本人や担当者だけが利用できる状態です。

下書き段階の文書などに利用できます。

例えば、

下書き
↓
上司確認
↓
承認
↓
部署公開

というワークフローにもつなげられます。

文書の機密レベルを設定する方法もある

公開範囲だけでなく、文書自体に機密レベルを持たせる方法もあります。

例えば、

レベル1：社内公開

全社員が閲覧可能。

レベル2：部署限定

所属部署の社員のみ閲覧可能。

レベル3：機密

指定ロール・指定ユーザーだけ閲覧可能。

レベル4：極秘

役員など特定ユーザーのみ閲覧可能。

といった分類です。

ただし、

「機密だから部長以上」

のように機密レベルと権限ルールを完全に固定すると、実際の業務に合わない場合があります。

機密区分は文書分類として利用し、実際のアクセス権限は別途設定できる設計も考えられます。

RBACで機密文書の権限を管理する

権限管理でよく利用される方式がRBACです。

ユーザーごとに権限を1つずつ設定するのではなく、ロールに権限を設定します。

例えば、

一般社員

• 社内公開文書を閲覧
• 自部署文書を閲覧

部署管理者

• 自部署文書を閲覧
• 自部署文書を登録
• 自部署文書を編集

文書管理者

• 文書登録
• 文書編集
• 公開範囲変更
• 文書削除

システム管理者

• ユーザー管理
• ロール管理
• システム設定

といった形です。

ロールを使うことで、社員が100人いても個別に大量の権限を設定する必要がなくなります。

RBACだけでは足りないケース

RBACだけでは、次のような条件を表現しにくい場合があります。

「営業担当者は自分が担当する顧客の契約書だけ閲覧できる」

「部長は自部署の文書だけ閲覧できる」

「案件メンバーだけ設計資料を閲覧できる」

このような場合は、

• 所属部署
• 担当顧客
• プロジェクト
• 文書所有者

などの情報も使ってアクセス可否を判断します。

例えば、

ユーザーの部署 = 文書の公開部署

であれば閲覧を許可する、といった判定です。

ロールとデータ属性を組み合わせることで、現実の業務に合わせた権限管理ができます。

権限管理のDB設計例

小規模な文書管理システムであれば、例えば次の情報を管理します。

ユーザー

• user_id
• name
• department_id
• role_id
• status

部署

• department_id
• department_name

文書

• document_id
• title
• owner_user_id
• department_id
• confidentiality_level
• file_path
• created_at

ロール

• role_id
• role_name

権限

• permission_id
• permission_name

例えば権限として、

• DOCUMENT_VIEW
• DOCUMENT_CREATE
• DOCUMENT_EDIT
• DOCUMENT_DELETE
• DOCUMENT_DOWNLOAD
• DOCUMENT_PERMISSION_CHANGE

などを定義できます。

ただし、実際のDB構造は権限要件によって変わります。

最初から大量のテーブルや権限を作るより、実際に必要な公開範囲を整理してから設計することが重要です。

フォルダ単位と文書単位のどちらで権限を設定するか

文書管理システムでは、

「フォルダ単位で権限を設定するか」

「ファイル単位で設定するか」

も重要なポイントです。

フォルダ単位

例えば、

人事部フォルダ
→ 人事部のみ閲覧

営業部フォルダ
→ 営業部のみ閲覧

という管理方法です。

設定がシンプルで運用しやすいメリットがあります。

文書単位

同じフォルダでも、

文書A：全社員
文書B：営業部のみ
文書C：部長以上

のように設定できます。

柔軟ですが、管理が複雑になります。

実務では、

基本はフォルダ・カテゴリ単位で権限を設定し、必要な文書だけ個別権限を上書きする

という方法が扱いやすいことがあります。

権限の継承ルールを明確にする

フォルダ単位で権限を設定する場合、継承ルールも決めます。

例えば、

営業部フォルダ
↓
2026年度
↓
契約書

という階層があるとします。

上位フォルダで「営業部のみ」と設定した場合、下位フォルダや文書にも自動適用するのかを決めます。

さらに、

「特定の文書だけ役員限定に変更できるか」

なども整理します。

権限継承が複雑になりすぎると、

「なぜこのユーザーが閲覧できるのか分からない」

という状態になりやすいため注意が必要です。

アクセス拒否を基本にする

機密文書では、

「特に設定がなければ閲覧可能」

より、

「権限が明示的に認められている場合だけ閲覧可能」

という考え方が安全です。

これをデフォルト拒否と考えることができます。

例えば新しく機密フォルダを作成したとき、設定漏れによって全社員へ公開されるより、最初は誰も閲覧できず、管理者が必要な権限を設定する方が情報漏えいを防ぎやすくなります。

画面で非表示にするだけでは権限管理にならない

非常に重要なポイントです。

例えば一般社員には「人事資料」というメニューを表示しないようにしたとします。

しかし、

/documents/123

というURLへ直接アクセスすると表示できるのであれば、権限管理として不十分です。

サーバー側で必ず、

1. ユーザーがログインしているか
2. 対象文書が存在するか
3. ユーザーにその文書の閲覧権限があるか

を確認してからデータを返します。

画面上の非表示は操作性のための制御であり、セキュリティ上の認可処理はサーバー側で行う必要があります。

ファイルURLを知っているだけで取得できないようにする

文書情報の画面は保護されていても、実ファイルへのアクセスが保護されていないケースがあります。

例えばPDFが、

https://example.com/files/contracts/contract-123.pdf

というURLにあり、このURLを知っていれば誰でもダウンロードできる状態です。

これでは文書画面に権限管理を実装しても意味がありません。

ファイル取得時にも、

ログイン確認
↓
文書ID確認
↓
アクセス権限確認
↓
ファイル提供

という処理を行います。

クラウドストレージを利用する場合は、一定時間だけ有効な署名付きURLを発行する方法もあります。

ファイル名をランダムにするだけでは不十分

例えば、

8f2d9a7c.pdf

のように推測しにくいファイル名へ変更したとしても、それだけでアクセス制御にはなりません。

URLがメールやログなどから漏れれば、権限のないユーザーでも利用できる可能性があります。

ファイル名の推測困難性に依存せず、取得時に認可処理を行うことが重要です。

閲覧とダウンロードを分ける

機密文書では、

「ブラウザで閲覧は許可するが、ダウンロードは制限したい」

という要件もあります。

例えば、

一般社員：
閲覧のみ

管理職：
閲覧・ダウンロード可能

という設計です。

ただし、ブラウザ上に文書内容を表示している以上、技術的に情報の持ち出しを完全に防げるとは限りません。

スクリーンショットや撮影などもあります。

そのため、ダウンロード禁止機能を「絶対に持ち出せない仕組み」と考えるのではなく、情報管理上の制御の一つとして利用します。

印刷制限が必要かも検討する

PDFビューアなどでは印刷操作を制限したいという要件もあります。

例えば、

• 機密文書は印刷不可
• 管理職のみ印刷可能
• 印刷した場合は監査ログに記録

などです。

一方、完全な印刷防止が難しいケースもあります。

システムによる制御と、社内ルール・端末管理などを組み合わせて考えることが重要です。

外部共有をどう扱うか決める

社内文書管理でも、

「この契約書だけ取引先へ共有したい」

といった要件が出ることがあります。

この場合、社内権限とは別に外部共有機能を設計します。

例えば、

• 共有リンクを発行
• 有効期限を設定
• パスワードを設定
• ダウンロード可否を設定
• 共有リンクを無効化
• アクセス履歴を記録

などです。

永久に有効な公開URLを発行するより、必要な期間だけアクセスできる設計の方が管理しやすくなります。

退職・異動時の権限変更を考える

機密文書の権限管理では、ユーザーのライフサイクルも重要です。

例えば営業部から人事部へ異動した社員が、以前の営業部限定文書を引き続き閲覧できる状態になっていないか確認する必要があります。

部署情報と権限が連動していれば、

営業部
↓
人事部へ異動
↓
営業部限定文書へのアクセスを失う

といった制御ができます。

退職時には、

• アカウント無効化
• セッション失効
• 文書アクセス禁止
• 所有している文書の引き継ぎ

なども必要になります。

文書の所有者が退職した場合を考える

個人が文書の所有者になっている場合、退職によって管理できる人がいなくなる可能性があります。

そのため、

• 所有者
• 管理部署
• 文書管理責任者

を分ける設計も考えられます。

例えば契約書であれば、

作成者：営業担当者
管理部署：営業部
文書管理責任者：営業部長

という形です。

重要文書を特定ユーザーだけに依存させないことがポイントです。

権限変更は監査ログに残す

機密文書では、文書そのものの閲覧履歴だけでなく権限変更も重要な監査対象です。

例えば、

「役員限定だった文書が全社公開へ変更されている」

という問題が発生したとします。

監査ログがあれば、

• 誰が
• いつ
• どの文書について
• どの権限から
• どの権限へ変更したか

を確認できます。

特に、

• 公開範囲変更
• 閲覧ユーザー追加
• 管理者追加
• ダウンロード許可
• 外部共有

などは記録を検討します。

文書の閲覧履歴も残すべきか

文書によっては、

「誰が閲覧したか」

まで確認したい場合があります。

例えば、

• 人事資料
• 経営資料
• M&A関連資料
• 個人情報を含むファイル

などです。

監査ログとして、

• ユーザー
• 文書
• 閲覧日時
• 操作内容
• IPアドレス

などを保存できます。

ただし、すべての一般文書について毎回閲覧ログを保存するとログ量が増えるため、機密区分に応じて対象を決める方法もあります。

ダウンロード履歴は特に記録を検討する

機密文書では閲覧だけでなく、ダウンロードが重要です。

例えば大量の顧客情報が含まれるファイルを社員がダウンロードした場合、

「誰がいつ取得したか」

を後から確認できると調査しやすくなります。

例えば、

• document_id
• user_id
• action = DOWNLOAD
• downloaded_at
• ip_address

などを記録します。

外部共有URLを利用する場合も、アクセス履歴を記録する方法があります。

文書そのものの変更履歴も管理する

Word、Excel、PDFなどを差し替える運用では、

「現在表示しているファイルが最新版なのか」

という問題もあります。

例えば、

契約書_v1
↓
修正版_v2
↓
最終版_v3

という変更があった場合です。

古いファイルを上書きして消してしまうのではなく、バージョンを管理する方法があります。

例えば、

• バージョン番号
• 更新者
• 更新日時
• 更新理由
• 過去ファイル

を保持します。

権限管理とバージョン管理を組み合わせることで、重要文書を追跡しやすくなります。

機密文書を検索結果に出すときも権限確認が必要

文書管理システムに全文検索機能を付ける場合も注意が必要です。

例えば人事部だけが見られる文書が、

検索結果のタイトル
検索スニペット
AI検索結果

などに表示されてしまうと、本文を開けなくても情報が漏れる可能性があります。

そのため検索時にも、

「このユーザーが閲覧できる文書だけを検索対象にする」

という制御が必要です。

AI・RAGで機密文書を検索するときの権限管理

最近では、社内文書をAIやRAGで検索する仕組みも増えています。

例えばユーザーが、

「今年の人事制度について教えて」

と質問すると、社内文書から関連情報を検索し、生成AIが回答する仕組みです。

この場合も通常の文書管理と同じく権限確認が必要です。

例えば一般社員が検索した際に、人事担当者限定の資料がRAGの検索結果へ混ざってしまうと、AIの回答を通じて機密情報が漏れる可能性があります。

そのため、

ユーザー認証
↓
ユーザーの部署・ロール確認
↓
アクセス可能な文書だけ検索
↓
AIへ渡す
↓
回答生成

という設計が重要です。

AIを導入しても、既存の文書アクセス権限を迂回しないことが基本です。

機密文書の権限管理でよくある失敗

全員に管理者権限を付ける

少人数の会社では、

「設定が面倒だから全員管理者」

となることがあります。

しかし、文書削除や公開範囲変更まで全員ができる状態は、誤操作のリスクが高くなります。

必要最小限の権限を付与する考え方が重要です。

フォルダの権限と個別文書の権限が複雑すぎる

権限の上書きを大量に許可すると、管理者自身も状態を把握できなくなります。

「なぜこの人が見られるのか」

を説明できる程度のルールに整理することが重要です。

画面だけ隠している

メニューを非表示にしても、URLやAPIへ直接アクセスできれば意味がありません。

サーバー側で認可します。

ファイルストレージが公開状態になっている

文書管理画面はログイン必須でも、保存先のファイルURLが一般公開されているケースです。

ファイル取得そのものにもアクセス制御が必要です。

共有リンクに有効期限がない

一度発行した共有URLが永久に利用できると、後から誰がURLを持っているのか把握できなくなります。

共有期限や無効化機能を検討します。

権限変更の履歴がない

機密文書が誤って公開されても、誰が設定を変更したのか確認できません。

重要な権限変更は監査ログに残します。

機密文書の権限管理を設計する手順

実際のシステム開発では、次の順番で整理すると進めやすくなります。

1. 管理する文書を洗い出す

例えば、

• 契約書
• 見積書
• 顧客資料
• 人事資料
• 経営資料
• 社内規程
• マニュアル

などです。

2. 文書の機密度を分類する

全社公開でよいものと、閲覧者を制限するものを整理します。

3. ユーザーの種類を整理する

例えば、

• 一般社員
• 部署管理者
• 人事担当
• 経理担当
• 役員
• システム管理者

などです。

4. 公開範囲を決める

• 全社
• 部署
• プロジェクト
• ロール
• 個人

のどれが必要かを確認します。

5. 操作権限を決める

• 閲覧
• 登録
• 編集
• 削除
• ダウンロード
• 共有
• 権限変更

などです。

6. 例外ルールを整理する

例えば、

「営業部限定だが役員も閲覧可能」

といった例外があるか確認します。

7. 監査ログを決める

• 閲覧
• ダウンロード
• 編集
• 削除
• 権限変更
• 外部共有

のどこまで記録するかを決めます。

【コピペ用】機密文書の権限管理チェックリスト

社内文書管理システムを検討するときは、次の項目を整理すると要件定義が進めやすくなります。

文書分類

• どのような文書を管理するか
• 機密レベルを設けるか
• 全社公開文書は何か
• 部署限定文書は何か
• 個人限定文書はあるか

ユーザー

• どの部署があるか
• どのロールがあるか
• 管理者は誰か
• 複数部署に所属するユーザーはいるか
• 退職・異動時の処理はどうするか

権限

• 閲覧権限
• 登録権限
• 編集権限
• 削除権限
• ダウンロード権限
• 印刷権限
• 共有権限
• 権限変更権限

ファイル

• ファイルURLを直接開けないようになっているか
• 一時的なダウンロードURLを利用するか
• バージョン管理が必要か
• 外部共有が必要か

監査

• 閲覧履歴を残すか
• ダウンロード履歴を残すか
• 削除履歴を残すか
• 権限変更履歴を残すか
• 外部共有履歴を残すか

セキュリティ

• 権限判定をサーバー側で行っているか
• デフォルト拒否になっているか
• 退職者のアクセスを即時停止できるか
• 機密ファイルの保存先が公開されていないか
• AI検索でも文書権限を維持できるか

機密文書の権限管理に関するよくある質問

部署ごとに文書を分けるだけでも大丈夫ですか？

業務要件によります。

シンプルな社内文書管理であれば、部署ごとの権限だけでも十分な場合があります。

一方、人事資料や経営資料のように部署内でも閲覧者を限定したい場合は、ロールや個別ユーザーによる制御も必要です。

文書ごとにユーザーを指定した方が安全ですか？

必ずしもそうではありません。

細かく制御できますが、文書数や社員数が増えると管理が非常に複雑になります。

基本は部署やロールで管理し、例外的な文書だけ個別指定する方法が運用しやすいでしょう。

管理者はすべての機密文書を閲覧できるようにすべきですか？

必ずしも必要ではありません。

システム設定を管理する権限と、機密文書を閲覧する権限は分離できます。

例えばシステム管理者でも、人事評価資料の内容までは閲覧できない設計が可能です。

ダウンロードを禁止すれば情報漏えいを防げますか？

情報持ち出しのリスクを下げる手段にはなりますが、完全に防げるわけではありません。

画面に表示できればスクリーンショットや撮影なども可能です。

権限管理、監査ログ、端末管理、社内ルールなどを組み合わせて対策します。

Google DriveやMicrosoft 365だけでは足りませんか？

一般的な文書共有であれば、既存サービスで十分な場合があります。

一方、

• 独自の承認フロー
• 業務システムとの連携
• 顧客や案件単位の権限
• 独自の監査要件
• AI・RAGとの権限制御連携

などが必要な場合は、既存サービスとの連携や独自システムを検討する余地があります。

AIで社内文書を検索する場合も権限管理できますか？

可能です。

ただし、AIへ渡す前の検索段階でユーザーの閲覧権限を確認する必要があります。

通常の文書画面では見られない資料が、AI経由では回答されてしまう設計にならないよう注意が必要です。

まだ公開範囲が決まっていなくてもシステム開発の相談はできますか？

可能です。

まず、

• どの文書を扱っているか
• 誰が利用しているか
• 現在どのように共有しているか
• どの情報を見せたくないか

を整理することで、必要な権限構造を決めていけます。

hiro-dev-labでは機密文書の権限設計から相談できます

機密文書の管理システムを作る場合、単純なファイルアップロード機能だけでは十分ではありません。

実際には、

• ユーザー管理
• 部署管理
• ロール管理
• 文書分類
• 公開範囲
• 閲覧・編集権限
• ダウンロード制御
• 外部共有
• 監査ログ
• バージョン管理
• AI・RAGとの連携

などを組み合わせて設計する必要があります。

hiro-dev-labでは、

• 現在の文書管理業務のヒアリング
• 要求整理
• 要件定義
• 権限設計
• 認証・認可設計
• データベース設計
• ファイル管理設計
• 監査ログ設計
• Webシステム開発
• AI・RAGを活用した社内文書検索

など、業務整理からシステム設計・開発まで相談できます。

例えば、

「共有フォルダでは誰が見られるか分からなくなっている」

「部署ごとに文書の公開範囲を分けたい」

「人事資料だけ閲覧者を限定したい」

「契約書のダウンロード履歴を残したい」

「社内文書をAI検索したいが権限も維持したい」

といった段階からでも整理できます。

機密文書の権限管理で重要なのは、権限機能を複雑にすることではありません。

「誰が、どの文書に、どの操作までできるのか」を業務に合わせて明確にし、すべてのアクセス経路で一貫して制御することが、安全で運用しやすい文書管理システムを作るための基本です。