Microsoft 365 の SharePoint で「サイト全体ではなく、特定のサブフォルダーだけをゲストに共有したい」のに、招待リンクを開くと「アクセス要求」になり続けてフォルダーへ入れない――この“無限ループ”は権限設計とサインイン状態が噛み合わないときに起きがちです。この記事では、権限の整理手順から外部共有設定、ゲスト側の確認ポイントまで、再発しにくい形で解決する方法を具体的に解説します。
今回の事象を整理:サブフォルダー A1 だけ共有したいのにアクセス要求ループになる
まず、状況を「どこで詰まっているか」に分解します。SharePoint の外部共有トラブルは、原因が一つではなく複数の要素が同時に絡むことが多いため、最初に全体像を固定しておくのが近道です。
| 項目 | 内容 | ポイント |
|---|---|---|
| 環境 | Microsoft 365 Business | テナント/サイトの外部共有ポリシーが影響 |
| サイト | SharePoint サイト「group_A」 テンプレート:ドキュメント センター | ライブラリ側で独自権限になっているケースがある |
| フォルダー構成 | folder group A 配下にサブフォルダー A1 / A2 | 「A1 だけ」に権限付与したい |
| 共有対象 | Azure AD(現在の名称:Microsoft Entra ID)で作成したゲスト | ゲストのサインイン状態がズレるとループしやすい |
| 実施した操作 | サイト所有者 user1 が A1 を共有し「編集」権限付与 | 共有リンクとフォルダー権限が一致しているかが重要 |
| 発生症状 | ゲストが招待リンクを開くと「アクセス要求」画面 承認しても再度アクセス要求に戻される | 権限が付いた“つもり”でも実際のアクセス主体が別だと起きる |
この症状は、ざっくり言うと「SharePoint 側の権限が正しく付いていない」か「ゲストが“招待されたのとは別のアカウント/状態”でアクセスしている」ときに発生しやすいです。さらに、サイト/ライブラリ/フォルダーで権限が二重三重になっていると、見た目の設定と実際の判定がズレて混乱が増えます。
まず理解しておきたい:SharePoint の「共有」と「権限」は別物として動く
SharePoint での「共有」は、直感的には“リンクを送れば入れる”ように見えますが、内部的には次の要素が噛み合って初めて成立します。
- 外部共有が許可されていること(テナント全体 + サイト単位)
- 共有リンクの種類(特定のユーザー / 組織内 / 既存アクセスなど)
- 対象アイテムの権限(A1 の固有権限や、継承の状態)
- アクセスしているユーザーの“本人性”(招待されたゲストとしてサインインできているか)
今回の「アクセス要求ループ」は、SharePoint が“あなたは権限を持っていません。要求してください”と判定している状態です。承認後も同じ画面に戻る場合は、次のどれかが疑われます。
- 承認した権限が、実はフォルダー A1 に反映されていない(別スコープの権限を付与している、または A1 側の権限が崩れている)
- ゲストが、招待されたゲストアカウントではなく別の Microsoft アカウント/別セッションで開いている
- 共有リンクが古い/別の形式で、“共有したつもりの設定”とリンクの状態が一致していない
結論から:最初にやるべきは「A1 の権限を整理し直す」
この手のトラブルは、まずフォルダー A1 の権限を一度“きれいに”揃えるのが最も効果的です。なぜなら、サイト/ライブラリ/フォルダーで権限が重複していると、管理者側の画面で見える情報と、ゲスト側の実アクセスが一致しないことがあるからです。
対処法:A1 の権限を整理し直す(継承停止 + 付け直し)
以下は、質問の内容に沿った最優先の手順です。ポイントは「既に付いているゲスト権限を一度すべて外し、A1 にだけ必要な権限を付け直す」ことです。
- サブフォルダー A1 に移動します。
- 右上の「…」などから 「アクセスの管理」 を開き、さらに 「詳細設定(Advanced)」 を開きます。 (表示が変わる場合は「アクセス許可」「詳細」など、権限の詳細画面に進める導線を探します。最終的に“ユーザー/グループの一覧が出るクラシック権限画面”に到達できればOKです。)
- 画面上部の表示を確認します。
- 「このフォルダーは親からの権限の継承を停止しています」等が出ていれば、A1 はすでに固有権限です。
- 継承中であれば、必要に応じて権限の継承を停止します(“A1 だけ”を実現するには基本的に継承停止が必要です)。
- クラシックな権限一覧(ユーザー/グループが並ぶ画面)で、対象のゲストユーザーに付いている権限を一度すべて削除します。
- 同じゲストが複数の表示名で存在していないか(例:名前表記と「#EXT#」表記など)も確認し、紛らわしい重複は避けます。
- この段階で、誤って既存の Owners/Members/Visitors など主要グループを消さないように注意します。
- もう一度 A1 の権限画面から 「権限の付与(Grant Permissions)」 を実行し、ゲストユーザーのメールアドレスを入力して追加します。
- 権限レベルは 「編集(Edit)」か「共同作成(Contribute)」のどちらかに統一して付与します。
- サイト側で Contribute、フォルダー側で Edit など、スコープ別に権限レベルがズレると切り分けが難しくなります。
- 「編集」と「共同作成」は似ていますが、運用上はどちらを使うか決めて統一したほうがトラブルが減ります(一般的な共同編集なら Contribute で足りることが多いです)。
- 通知メールを送る場合は、同じ画面から送信します。可能であれば一度リンクを作り直す(後述)とより確実です。
重要:「サイト全体は触らせず、A1 だけアクセスさせたい」場合は、原則としてゲストにサイトメンバー権限を付けない運用も可能です。ただしその場合、A1 の固有権限が少しでも崩れると今回のような事象が出やすくなるため、A1 の権限画面を“誰が見ても説明できる状態”に整えておく必要があります。
権限が混乱しやすい理由:サイト権限とフォルダー権限の「二重付与」
SharePoint は最終的に「一番強い権限」が勝つように見えますが、実務ではどこで権限を渡したかが曖昧になると、トラブル時の切り分けが非常に難しくなります。特にゲスト共有では、次のパターンが混在すると“付いているのに入れない”が起きやすいです。
| 混乱パターン | 起きやすい症状 | 避けるコツ |
|---|---|---|
| サイトで Contribute、A1 で Edit | 管理者側は付与したつもり、ゲスト側はアクセス要求 | 権限レベルを統一し、まずは A1 に直接付与で検証 |
| フォルダー共有とアクセス要求承認を両方使う | 承認メールのリンクを踏むと再要求になる | “アクセス要求”に頼らず、A1 の権限付け直しと共有リンク再発行に寄せる |
| 同じゲストが複数の表記で存在 | 片方に権限を付けても、ログインしている主体が別で弾かれる | ゲストの識別子を揃え、重複エントリを作らない |
| ライブラリが独自権限、フォルダーも独自権限 | “どこで止まっているか”が見えにくい | まずライブラリ配下の権限構造を図式化してから整理 |
おすすめは、最初は「A1 にだけゲストを直接追加」という最小構成で成功させ、その後に必要があればサイトグループ運用に寄せることです。初期の段階で広く権限を与えるほど、問題の切り分けが遠回りになります。
目的別:A1 だけゲストに見せるための権限設計パターン
同じ「ゲスト共有」でも、運用目的によって最適解が変わります。A1 だけに限定したい場合、以下の設計が分かりやすく、後からの説明もしやすいです。
| 目的 | サイト権限 | A1 の権限 | メリット | 注意点 |
|---|---|---|---|---|
| A1 のみアクセスさせたい | 付与しない(または最小) | ゲストを直接追加し Contribute/Edit | 公開範囲が最小で安全 | A1 の権限が崩れると影響が直撃。管理ルールを決める |
| サイト内の他コンテンツも閲覧OK | ゲストを Members へ追加 | 原則継承(特別扱いしない) | 運用が単純で共有ミスが減る | サイト全体の公開範囲が広がる |
| A1/A2など特定フォルダー群を共有 | 付与しない(または最小) | 共有対象フォルダーごとに固有権限 | 公開範囲を制御しやすい | フォルダーが増えるほど権限管理が複雑。担当者とルールが必須 |
今回の要件は「A1 にだけアクセスさせたい」に該当するため、サイトメンバーに追加せず、A1 にだけゲストを直接追加する設計が合っています。実現自体は可能ですが、その代わり“A1 の権限が正しく整っていること”が絶対条件になります。
次に必須:テナントとサイトの「外部共有」設定を確認する
A1 の権限を付け直しても改善しない場合、外部共有ポリシーが原因で「リンクは届くが入れない」状態になっている可能性があります。外部共有はテナント全体の上限とサイト単位の上限の“より厳しい方”が適用されます。
確認手順:SharePoint 管理センター側
- SharePoint 管理センターを開き、「ポリシー」→「共有」へ進みます。
- SharePoint の外部共有が許可されていることを確認します。
- 組織の方針で外部共有が制限されている場合、フォルダー共有は成立しません。
- 「アクティブなサイト」から対象サイト「group_A」を選択します。
- 「共有」や「その他の共有設定(More sharing settings)」相当の項目を開き、外部共有が「新規および既存のゲスト(New and existing guests)」になっていることを確認します。
- 外部共有が「既存のゲストのみ」や「組織内のみ」に寄っていると、招待フローやリンクが期待通りに動かないことがあります。
- 変更した場合は保存し、反映後に共有リンクを作り直すのが安全です。
外部共有設定の“見落としポイント”早見表
| レベル | 見る場所 | 期待する状態 | ズレたときの典型症状 |
|---|---|---|---|
| テナント | SharePoint 管理センター ポリシー → 共有 | 外部共有が許可 | 共有リンク自体が作れない/ゲストが弾かれる |
| サイト | アクティブなサイト → group_A | 新規および既存のゲスト | リンクは届くが入れずアクセス要求へ |
| リンク設定 | 共有時のリンク設定 | 特定のユーザー(Specific people) | 別アカウントで開くと失敗、意図しないユーザーに公開 |
質問のケースでは「Azure AD でゲストを作成している」ため、サイト側の外部共有が新規および既存のゲストになっていることは特に重要です。ここが一段でも厳しいと、A1 側でどれだけ権限を整えてもゲストは正規の手順で入れません。
よくある落とし穴:ゲストが“別のアカウント”でリンクを開いている
権限も外部共有も正しく見えるのにアクセス要求ループが消えない場合、次に疑うべきはゲスト側のサインイン状態です。
ゲストは、同じブラウザーで以下のような状態になっていることがあります。
- すでに別の Microsoft アカウント(個人用/業務用)でサインインしている
- 以前に別テナントのゲストとしてログインしたセッションが残っている
- 招待メールのアドレスとは別のアドレスで認証している
この場合、SharePoint から見ると「権限を付与したゲスト」と「今アクセスしている主体」が一致せず、結果として承認されても承認されても入れないように見えます。
ゲストに案内したい“定番の切り分け手順”
- 招待メールのリンクは、シークレット/プライベートウィンドウで開く
- Microsoft 関連のページ(Outlook/Teams/Office.com など)から一度すべてサインアウトする
- リンクを開いたとき、招待されたメールアドレスでサインインする
- うまくいかない場合は、別ブラウザー(Edge/Chrome など)で試す
運用上は、ゲストへ次のように一文で依頼するとトラブルが減ります。
「リンクは一度サインアウトしてから、シークレットウィンドウで開いてください。サインイン時は招待されたメールアドレスを必ず選択してください。」
ゲスト側原因の可能性を見分ける表
| 見え方 | 可能性 | まず試すこと |
|---|---|---|
| アクセス要求画面がずっと出る | 別アカウントで開いている | シークレットで開き直し、招待アドレスでサインイン |
| 承認メールが来ても入れない | 承認した相手とアクセス主体が違う | ゲストが表示しているアカウント情報を確認 |
| 別のフォルダーなら入れる | A1 側の権限が崩れている | A1 の権限を削除→付け直し |
| どこにも入れない | 外部共有ポリシー/サインイン制御 | SharePoint 管理センターの外部共有、テナント制御を確認 |
共有リンクも再発行する:古いリンクのままだと再現することがある
権限を整えたあとに、念のため共有リンクを作り直すのは有効です。なぜなら、共有の過程で生成されたリンクや“共有状態”が、途中の操作(アクセス要求承認、権限の追加削除、リンク形式変更など)で複雑化している場合があるからです。
おすすめのリンク設定
- リンクの種類:特定のユーザー(Specific people)
- 権限:編集を許可(必要な場合のみ)
- 必要に応じて:リンク期限を設定(運用ルールとして推奨)
ポイントは、「共有リンクの種類」と「A1 に付けた権限」を一致させることです。たとえば、リンク側は特定ユーザーなのに、A1 側では別の表示名のゲストに権限が付いていると、アクセス判定が噛み合いません。
アクセス要求機能に頼りすぎない:ゲスト共有では混乱の元になりやすい
SharePoint の「アクセス要求」は便利ですが、ゲスト共有の場面では次の理由で“ループの入口”になりやすいです。
- 要求がフォルダーではなくサイト/ライブラリに飛ぶことがある
- 承認時に付く権限が意図したスコープと違うことがある
- メールのリンクが「要求状態」へ誘導し、ゲストが同じ導線を踏み続ける
今回の目的が「A1 だけ入れればよい」なら、アクセス要求の運用で回すよりも、A1 の権限を明確にして共有リンクを発行し直す方が安定します。
それでも解決しないときの切り分け:再現条件を“潰し込み”する
ここまで(A1 の権限整理・外部共有確認・ゲスト側サインイン確認・リンク再発行)をやってもループが続く場合、原因を特定するために再現条件を絞り込みます。ポイントは「ゲスト固有の問題か」「A1 固有の問題か」「サイト固有の問題か」を分けることです。
| テスト | やること | 結果の読み取り |
|---|---|---|
| 別ゲストで A1 を開く | 別のゲストを用意し、同じ手順で A1 を共有 | 入れないなら A1 の権限/サイト設定側が濃厚 |
| 同じゲストで A2 を開く | A2 を共有してアクセス可能か確認 | A2 はOKなら A1 の権限構造が濃厚 |
| 同じゲストで別サイトの共有 | 別サイトの単純なフォルダー共有で入れるか確認 | 入れないならゲストのサインイン/テナント制御が濃厚 |
| user1 以外の所有者で共有 | 別のサイト所有者で A1 を共有し直す | 共有操作アカウント固有の問題(権限/制御)を疑う |
この切り分け結果は、後述の Microsoft サポートへの依頼時にも強力な材料になります。「何をやって、どういう条件だと再現するか」を整理しておくと、調査が一気に進みます。
最終手段:Microsoft サポートへエスカレーションするべき状況
スレッドの最終結論としても触れられている通り、UI 上の設定が正しく見えるのにアクセス要求ループが解消しない場合、SharePoint のバックエンド側(共有状態の内部データ、同期状態、不可視な制御など)の問題が疑われます。こうなると現場でできることが限られるため、Microsoft 365 管理センターからサポートチケットを起票するのが現実的です。
起票前に準備しておくと良い情報
| 項目 | 例 | なぜ必要か |
|---|---|---|
| 対象サイト | group_A のサイトURL | サポートが対象を特定するため |
| 対象フォルダー | folder group A / A1 | アイテムスコープの権限確認のため |
| ゲストの識別 | 招待したメールアドレス、ゲスト表示名 | “権限を付けた主体”と“アクセス主体”の一致確認 |
| 共有リンクの種類 | 特定のユーザー(Specific people) | リンク判定のログ確認に必要 |
| 外部共有設定 | 新規および既存のゲスト | ポリシーの上限/下限の確認 |
| 発生日時 | いつから/いつ再現するか | ログ追跡の時間軸が必要 |
| 試した対処 | A1 権限の削除→付け直し等 | 同じ提案の繰り返しを避け、調査を前進させる |
起票手順(管理者向け)
- Microsoft 365 管理センターへアクセスします。
- 左メニューから 「サポート」→「新しいサービス リクエスト」 を選択します。
- 説明欄に、次の内容を箇条書きで記載します。
- どのサイト(group_A)のどのフォルダー(A1)をどのゲストに共有しているか
- A1 が継承停止済み(固有権限)であること
- Microsoft Entra ID(旧 Azure AD)にゲストユーザーが存在すること
- 招待リンクを開くとアクセス要求画面に戻る無限ループが発生すること
- 共有リンクが「特定のユーザー」であること
- SharePoint の外部共有ポリシーが「新規および既存のゲスト」であること
- ゲスト側でシークレットモード等の切り分けも実施済みであること
サポート側では、管理画面から見えないバックエンドのログや共有状態の整合性などを確認できます。特に“設定は合っているのにループが止まらない”ケースでは、ここが突破口になることが多いです。
再発防止の運用ヒント:フォルダー限定共有は「ルール化」が重要
「A1 だけ共有」を継続運用するなら、トラブルを減らすために次のルールを決めておくのがおすすめです。
- 共有は必ず A1 の権限画面で確認してから完了とする(共有しただけで終わらせない)
- 権限の付与スコープを一つに寄せる(サイト権限とフォルダー権限を混在させない)
- 共有リンクは「特定のユーザー」を原則にする(誤共有防止)
- ゲストへ案内するテンプレ文を用意し、シークレットで開くことを標準手順にする
- フォルダーが増える場合は、共有対象フォルダー一覧と権限付与者を管理台帳化する
SharePoint の権限は強力ですが、自由度が高い分だけ“誰が見ても追える設計”にしておくことが安定運用の鍵になります。
まとめ:まずは A1 の固有権限を整理し直し(重複・競合を排除)、外部共有ポリシーを確認し、ゲスト側のサインイン状態を正した上で共有リンクを再発行する――この順番が最短ルートです。それでも解消しない場合は、バックエンド要因の可能性があるため Microsoft サポートへエスカレーションし、ログ調査を依頼するのが確実です。

コメント