文書単位の共有を期限付きにするには｜所有者・招待相手・継承の整理

1. 基本権限と例外共有はどう重ねるか

本稿では、組織に所属しているという基本条件を満たしたうえで、部署ロールまたは文書への有効な個別付与によって操作を許可する構成を提案する。個人情報を含む文書では、さらに文書の分類や共有先の条件を満たすことを必要とする。例えば別部署のレビュー担当者には、部署全体の権限を増やすのではなく、対象文書の閲覧だけを期限付きで付与する。認証済みであることと、個々の文書への操作を許されることは別であり、必要最小限の権限を選ぶ。[1]

優先規則は、文書分類による共有禁止などの必須制約を先に確認し、その後に基本権限と例外共有を評価する形にする。例外共有が失効しても、部署の権限で読める人は引き続き閲覧できる。一方、部署の権限がない人は閲覧できなくなる。この違いを共有画面に表示しないと、管理者は共有解除によって完全にアクセスを止めたと誤認しやすい。本稿では「部署から許可」「個別共有から許可」のように、許可理由を管理画面で追える設計を提案する。

• 閲覧・編集・ダウンロード・再共有を別の操作として定義する。
• 例外共有でも越えられない組織境界や文書分類を決める。
• 共有解除後も残る基本権限を管理者に表示する。

2. 所有者と招待相手に何を記録するか

所有者は、文書を利用できる人と同義にせず、共有の承認や見直しに責任を持つ役割として定義する。例えば、文書を作成した担当者が異動しても、作成者という履歴は残し、現在の所有者は別に変更できる構成にする。招待を承認する権限と本文を編集する権限も分け、編集できる人が無条件で外部共有できる状態を避ける。本稿では、文書ごとに現在の所有者、承認可能な範囲、代理承認者を持たせ、所有者が不明なまま共有を延長しない運用を提案する。

招待の記録には、対象文書、招待相手を識別するID、操作範囲、開始日時、終了日時、付与者、承認理由、取消状態を含める。メールアドレス宛ての招待では、入力した宛先と実際に受諾したアカウントの対応も確認対象にする。招待リンクを受け取っただけで許可するのか、指定した本人のログインを必要とするのかは別の設計判断である。個人情報を扱う本稿の想定では、受諾する相手を固定し、招待から再共有権限は自動付与しない案を採る。

• 作成者・所有者・共有承認者・招待相手を区別する。
• 招待の受諾前にも終了日時が進むかを決める。
• 共有理由に個人情報の本文を不用意に転記しない。

3. 有効期限はどの時点で判定するか

本稿では、開始日時以上かつ終了日時未満を有効とし、サーバーが認可を判断する時刻を基準にする案を提案する。「金曜日まで」という入力は、利用者が確認できるタイムゾーンと日時へ変換して保存する。期限切れレコードを整理する定期処理は管理用とし、その処理の完了を待たずにアクセスを拒否できるようにする。例えば夜間の整理処理が遅れても、終了日時を過ぎた文書取得を許可しない。判定に必要な情報を取得できない場合の扱いも、実装前に決めておく。

ログイン状態が続くことと、文書共有が有効であることは切り離す。セッションに過去の許可結果を保存する場合は、共有取消や期限到来をどう反映するかが必要になる。本稿では、文書取得時に現在の共有状態を評価し、権限キャッシュを使う場合も終了日時を越えて許可しない案を提案する。セッション自体を終了させる場合はサーバー側での無効化が必要だが、文書一件の共有終了を理由に全業務からログアウトさせるかは別途判断する。ブラウザーに表示済みの内容まで消去できるとは扱わない。[2]

• 期限直前・期限と同時刻・期限直後の境界条件を試験する。
• 端末時刻を変更してもサーバー側の判定が変わらないことを確認する。
• 取得済みファイルや表示済み情報は共有解除の対象外として説明する。

4. 移動・複製・所有者変更で何を引き継ぐか

フォルダーからの権限継承がある場合、文書の移動は保存場所の変更だけでなく、閲覧者の変更を伴う。本稿では、移動前に新旧の継承権限と個別共有を比較し、閲覧可能になる範囲を確認してから確定する案を提案する。例えば限定部署のフォルダーから全社用フォルダーへ移すなら、期限付き招待が残るかだけでなく、新たに全社の基本権限で読めることを示す。文書分類に反する移動は、共有設定を黙って調整するのではなく、拒否または承認待ちにする。

複製では本文を引き継いでも、招待相手や共有期限は自動的にコピーしない案を採る。新しい文書IDと所有者を決め、配置先の継承権限を評価してから必要な共有を設定する。一方、所有者変更は同じ文書の管理責任を移す操作とし、既存の招待一覧を新所有者が確認する工程を設ける。引継ぎでは、継続する共有、取り消す共有、期限まで残す共有を区別し、変更の前後を記録する。所有者変更だけで招待期限を延長したり、共有先を追加したりしない。

• 移動後に増える閲覧者を確定前に示す。
• 複製元の共有設定を引き継ぐ範囲を明文化する。
• 新所有者による共有一覧の確認を引継ぎ項目に含める。

5. RAGで期限切れ文書を使わせないためには

本稿では、RAGの検索対象を選ぶ際にも、質問者が現在閲覧できる文書を基準にする案を提案する。検索画面から文書を隠すだけではなく、回答生成へ渡す本文や断片にも同じ境界を設ける。例えばレビュー期間が終わった文書は、直接開けないだけでなく、要約依頼の根拠としても使わない設計にする。認可をサーバー側で行うという指針を、検索と本文取得の各入口に適用し、画面表示の制御だけに依存しない。[1]

検索インデックスに権限情報を持たせる場合は、共有取消から更新までの間をどう扱うかを決める。本稿では、候補となった文書について最新の許可状態を確かめ、許可された断片だけを生成処理へ渡す案を提案する。回答キャッシュや会話履歴には、元文書とは別に生成済み情報が残るため、共有終了で自動消去されると説明しない。保存する回答の閲覧範囲と保存期間も決め、過去回答を別の利用者へ再利用するときに、元の共有相手だけを前提にした内容を混ぜない。

• 権限のない文書名や抜粋が検索結果に出ないか確認する。
• 期限後の質問で対象文書が生成処理へ渡らないか確認する。
• 会話履歴・回答キャッシュ・引用リンクの扱いを分ける。

6. API・Webhook・再実行の権限をどう扱うか

APIでは、認証情報が有効というだけで対象文書への操作を許可せず、呼出主体、文書、操作の組合せを評価する。本稿では、人が開始した処理はその人の権限、組織共通の連携処理は明示的に付与した連携主体の権限として区別する案を提案する。例えば個人の一時共有を使って開始した出力処理を、強い権限の共通アカウントへ無条件に置き換えない。文書IDを知っていることを許可の根拠とせず、API側の認可を実装する。[1]

非同期処理では、受付時に許可されていたかに加え、実行時と結果取得時の扱いを定める。本稿では、期限前に登録した処理でも、期限後の再実行には改めて許可を求める案を提案する。Webhookも、失敗時の再送によって終了済みの共有内容を外部へ送らないよう、送信前の判定点を置く。通知だけを送る場合も文書名などの情報量を決める。長時間処理の途中で期限を迎える場合は、継続条件、出力の保留、取消時の状態を定義し、成功したように見せない。

• APIの権限と画面の権限が同じ規則を参照するか確認する。
• キュー待機中・再送待機中・結果取得時を個別に試験する。
• 外部へ送信済みの内容を取り戻せる前提を置かない。

7. 公開前の確認表では何を判定するか

確認表は、設定項目の有無ではなく、誰がどの状態で何を実行したときにどうなるかを記録するために使う。下表は本稿の試験案であり、合格済みの結果ではない。基本権限がある利用者と、例外共有だけを持つ利用者を分け、期限前に取得したURLや同じログイン状態で操作する。文書一件だけでなく別文書を誤って開けないことも含め、認可ロジックの単体試験と実際の経路を通す結合試験を組み合わせる。[1]

期待結果は、閲覧可否だけでなく、許可理由と情報の出方まで書く。例えば例外共有が切れた人に、エラー画面から本文の一部や不要な文書情報が見えないことも確認対象にする。失敗時に安全に終了し、エラーへ機密情報を出さないことは認可の指針にも含まれる。実施後は環境、時刻、対象設定、観測結果を記録し、未実施や期待と不一致の項目を残す。画面の試験だけでAPIやRAGも確認済みとはしない。[1]

• 期待結果と実測結果を別欄で管理する。
• 未実施の項目には未確認と記載し、公開判断者へ伝える。

8. 本番保守で共有の残り続けをどう見つけるか

本稿では、期限付き共有を保守可能にするため、付与・延長・取消・所有者変更の履歴と、認可結果を追える記録を分けて設ける案を提案する。共有変更の記録には実行者、対象、変更前後の期限、理由を残し、本文や資格情報をそのまま書かない。問い合わせ時には「共有は切れたが部署権限が残っている」のか、「期限の反映に問題がある」のかを切り分けられる状態を目指す。認可のログは有用だが、過剰な記録による機密情報の蓄積にも注意する。[1]

保守の見直し対象は、期限なしへの変更、延長の繰り返し、所有者不明、更新されていない検索索引などに絞る。例えば継続レビューで毎回延長しているなら、一時共有のままでよいか、正式な業務権限へ整理するかを業務責任者が判断する。障害時には、期限判定に必要な情報を取得できない経路を検知し、代替操作を無条件に許可しない。修正後は関連する試験を再実行し、公開時の設定だけでなく、その後の変更でも規則が維持されるか確認する。

• 期限延長の頻度と所有者不明の共有を定期的に確認する。
• 権限判定の障害を運用担当が把握できる通知先を決める。
• 設定・コード変更時に期限境界と共有経路の回帰試験を行う。

よくある質問

所有者が不在で、共有期限の延長を判断できない場合はどうしますか。

本稿では、事前に定めた代理承認者が業務目的と対象範囲を確認する案を提案します。代理権限がない場合は、運用担当の判断だけで延長せず、承認先へ引き上げます。期限を迎える前に判断できなければ共有終了を基本とし、作業への影響と代替手段を連絡します。

本番と同じ確認環境がない場合でも公開できますか。

確認できない経路を明示し、公開範囲を縮小できるか判断します。例えばWebhookの再送を検証できないなら、その連携を無効にした状態で公開する案があります。合成データによる試験が通っても本番設定との差は残るため、未確認事項、担当者、確認予定を公開判断の材料にします。

一時休職する所有者の文書は、すべて所有者変更すべきですか。

一律ではなく、休職期間中に共有承認や文書更新が必要かで分けます。変更が不要なら共有の終了予定を確認し、必要なら期限付きの代理管理を設ける案があります。代理に必要なのが共有管理だけなら、本文編集や再共有までまとめて付与しないようにします。

期限付きの例外共有を、緊急対応のため延長するときの条件は何ですか。

対象文書、操作、延長理由、承認者、新しい終了日時を確定させます。理由が継続業務へ変わっている場合は、その場で無期限化せず、基本権限の見直しとして別に判断します。延長後も承認した範囲だけが有効かを確認し、緊急対応終了時の見直し担当を決めます。

参考・関連資料

• [1] Authorization - OWASP Cheat Sheet Series ↗
• [2] Session Management - OWASP Cheat Sheet Series ↗

公式資料の確認日：2026-10-28。業務例は説明用で、顧客の実績ではありません。編集：株式会社N2i。執筆にAI支援を使用し、別のAIによる出典・品質確認に合格した記事を公開する方針です。