「PC だと普通に開けるのに、iPhone の Safari だけ SharePoint が開けない」「No Item exists at URL… という英語のエラーが出る」――この組み合わせは、SharePoint Online と iOS Safari 特有の“あるある”トラブルです。実はファイルが消えているわけではなく、Safari のプライバシー機能や条件付きアクセス（Conditional Access）の影響で「認証に失敗しているだけ」ということが多くあります。本記事では、エンドユーザー視点と管理者視点の両方から、原因と具体的な解決手順を丁寧に解説します。
iOS の Safari だけで「No Item exists at URL」が出る現象とは？
SharePoint Online のドキュメントライブラリや特定ファイルを開こうとしたとき、iPhone / iPad の Safari だけ次のようなエラーメッセージが表示されるケースがあります。
No Item exists at URL. It may have been deleted or renamed by another user.
典型的な状況は次の通りです。
- 同じ URL を Windows / Mac のブラウザー（Edge / Chrome）で開くと問題なく表示できる
- iOS の Safari でだけエラーになり、ファイルやフォルダーが存在しないように見える
- SharePoint アプリや OneDrive アプリから開くと表示できることもある
この場合、多くはアイテムが本当に削除されたわけではなく、認証や条件付きアクセスの制御に引っかかっているだけです。特に、
- Safari のプライバシー設定（サイト越えトラッキング防止 / Cookie 制限）
- Microsoft Entra ID（旧 Azure AD）の条件付きアクセス（Conditional Access）ポリシー
- URL の文字列（空白や特殊文字）の扱い
これらが原因で、SharePoint 側が「ユーザーは認証されていない」「アクセス権がない」と誤判定し、結果として「No Item exists at URL…」という 404 風のメッセージを出してしまう構図です。
よくある原因を整理
まずは、よくある原因をざっくり整理しておきます。
| 原因カテゴリ | 具体的な内容 | 症状の特徴 |
|---|---|---|
| Safari のプライバシー設定 | 「サイト越えトラッキングを防ぐ」「すべての Cookie をブロック」などにより、Microsoft サインイン用の Cookie が正しく保存されず、MSAL によるトークン取得が失敗する。 | Safari だけサインイン画面が繰り返し出る / サインインできたように見えるが、SharePoint 画面でエラーになる。 |
| 条件付きアクセス（CA） | 「承認済みクライアントアプリのみ」「準拠デバイス必須」「ブラウザーは Edge のみ許可」といったポリシーにより、Safari からのブラウザーアクセスがブロックされる。 | SharePoint / OneDrive アプリからは開けるが、Safari ではエラー。サインインログに CA による拒否が記録される。 |
| URL の文字列問題 | コピーした URL に余計な改行や空白が含まれている、もしくは空白や &、' などが未エンコードのままになっており、Safari が URL を正しく解釈できない。 | 特定のリンクだけエラーになる。別経路（ライブラリをたどる / アプリから開く）だと問題なく開ける。 |
| アカウント衝突 | 同じ Safari 上で複数テナントのアカウントにサインインしており、SharePoint が期待しているテナントと異なるアカウントで認証されてしまう。 | ゲストユーザーや複数アカウントユーザーだけが再現する。「別のアカウントで試す」と改善することがある。 |
次の章からは、エンドユーザー自身でできる対処と、管理者が条件付きアクセスを確認・調整する手順を順番に解説します。
エンドユーザー向け：自分でできる対処手順
Safari のプライバシー設定を一時的に緩める
まず試してほしいのが、Safari のプライバシー設定を少し緩くすることです。根本原因が条件付きアクセスの場合はこれだけでは解決しませんが、Safari 側の Cookie / トラッキング制御が原因の場合は、これで一気に解消することもあります。
設定アプリを開き、次の順に確認します。
- 設定 > Safari を開く
- 「サイト越えトラッキングを防ぐ」を一時的にオフ
- 「すべての Cookie をブロック」がオンになっている場合はオフ
| 設定項目 | 推奨状態 | 補足 |
|---|---|---|
| サイト越えトラッキングを防ぐ | 一時的にオフ | SharePoint / Microsoft 365 のシングルサインオンに必要な Cookie がブロックされることがあります。動作確認後、組織ポリシーに応じて戻すか検討します。 |
| すべての Cookie をブロック | オフ | オンのままだと、Microsoft アカウントのサインイン自体が安定して行えません。 |
設定変更後、一度 SharePoint のタブを閉じてから再度開き直し、再サインインを試してみてください。
Safari の Web サイトデータを削除して再サインインする
設定を変えても直らない場合は、Safari 側に古いキャッシュや Cookie が残っていて、それが悪さをしている可能性があります。次の手順で、該当ドメインの Web サイトデータを削除し、サインイン情報をリセットします。
- 設定 > Safari を開く
- 画面下部の「詳細」 > 「Webサイトデータ」を開く
- 検索欄に
sharepoint.com、microsoftonline.com、onedrive.comなどを入力し、表示された項目を削除 - Safari のアプリ自体をいったん終了し、再度起動
- 再度 SharePoint の URL にアクセスし、Microsoft アカウントでサインインし直す
これにより、Safari が保持していた古い認証情報や壊れたセッション情報がリセットされ、正常にトークンを取得し直せるようになることが多いです。
共有 URL を確認し、余計な空白や特殊文字を取り除く
チャットツールやメールからコピーした SharePoint のリンクは、意外と余計な改行や空白、未エンコードの特殊文字が紛れ込んでいます。PC ブラウザーは多少の崩れを補正してくれますが、Safari ではそれがうまくいかず、結果として「No Item exists at URL」になるパターンもあります。
簡単なチェック方法は次の通りです。
- 共有されたリンクを長押しして「リンクをコピー」する
- メモアプリなどテキストエディタを開き、リンクを貼り付け
- URL の前後に空白や改行が入っていないか確認し、あれば削除
- リンクの途中で改行されていないか（2 行以上に分かれていないか）確認
特に長い URL の場合、次のように途中で折り返されてしまい、コピー時に URL が分断されることがあります。
| 状態 | 例 | 結果 |
|---|---|---|
| NG 例（途中改行あり） | https://contoso.sharepoint.com/sites/Dept/Shared Documents/ファイル名（「Shared Documents/」の後ろで改行されるなど） | Safari が URL を途中までしか認識できず、「No Item exists at URL」に。 |
| NG 例（空白未エンコード） | .../Shared Documents/社内 資料.xlsx | 空白が %20 に変換されておらず、ブラウザーによっては誤解釈される。 |
| OK 例 | .../Shared%20Documents/%E7%A4%BE%E5%86%85%20%E8%B3%87%E6%96%99.xlsx | 空白や日本語が URL エンコードされており、どのブラウザーでも安定して扱える。 |
メモアプリ上で整えた URL をもう一度コピーし、Safari のアドレスバーに直接貼り付けて開いてみてください。
別の経路で開く：Microsoft Edge や SharePoint / OneDrive アプリ
組織によっては、条件付きアクセスのポリシーで「Safari のような汎用ブラウザーからのアクセスを制限し、Edge や公式アプリのみ許可」としているケースがあります。この場合、いくら Safari 側の設定を調整しても、ポリシーによってブロックされているため開くことはできません。
そのときは、次の経路を試します。
- iOS 版 Microsoft Edge をインストールし、そこから SharePoint の URL を開く
- SharePoint モバイルアプリをインストールして、アプリ内から該当サイトへアクセスする
- OneDrive アプリで組織アカウントにサインインし、「共有」や「サイト」から目的のファイルへたどる
「アプリ経由で開くことが前提のポリシー」になっている組織では、ユーザー側の正解は「アプリを使う」ことです。無理に Safari で開けるようにするのではなく、運用としてモバイルアプリの利用を案内するとトラブルが減ります。
アカウント衝突を解消する：一度すべてサインアウトしてサインインし直す
次によくあるのが、複数テナントのアカウントを同じ Safari で使っているパターンです。たとえば「自分の会社のアカウント」「取引先テナントのゲストアカウント」「個人用 Microsoft アカウント」の 3 種類を行き来していると、どのアカウントでサインインしているのかが分かりにくくなります。
この場合、次のようにして一度きれいにし直します。
- Safari で
https://portal.office.comなど Microsoft 365 のポータルサイトを開く - 右上のプロフィールアイコンからすべてのアカウントをサインアウト
- Safari を終了し、再度起動
- 再度 SharePoint の URL にアクセスし、「職場または学校アカウント」で正しいテナントのアカウントでサインインする
これで本来アクセス権を持っているテナントのアカウントで認証されるようになり、エラーが解消されるケースがあります。
管理者向け：条件付きアクセス（Conditional Access）を確認する
ユーザー側の対処を行っても改善しない場合、あるいは組織内の多くのユーザーに同じ症状が出ている場合は、条件付きアクセスのポリシー設計が原因である可能性が高いです。この章では、Microsoft Entra ID（旧 Azure AD）の管理者が確認すべきポイントをまとめます。
前提：必要な権限
条件付きアクセスの有効 / 無効や内容変更には、一般的に次のような権限が必要です。
- グローバル管理者
- セキュリティ管理者
- 条件付きアクセス管理者
閲覧のみであれば「セキュリティ閲覧者」ロールでも確認できますが、ポリシーの変更はできません。自身のロールが不明な場合は、まずテナントの管理者に確認しましょう。
ポリシーの割り当て：対象ユーザー / アプリ / クライアントアプリを確認
Microsoft Entra 管理センターにサインインし、次の順で条件付きアクセスの画面を開きます。
- Entra 管理センターにアクセス
- セキュリティ > 条件付きアクセス > ポリシーを選択
- Safari からのアクセスに影響していそうなポリシーを選択
各ポリシーについて、少なくとも次の 3 点を確認します。
| 項目 | 確認ポイント |
|---|---|
| ユーザー / グループ | 問題が発生しているユーザー / グループが「含まれている」か。「除外」に設定されていないか。 |
| 対象クラウドアプリ | SharePoint Online や OneDrive for Business が含まれているか。 「すべてのクラウドアプリ」が対象の場合も注意。 |
| クライアントアプリ | 「ブラウザー」が対象になっているか。 「モバイルアプリとデスクトップクライアント」のみを対象にしたポリシーとの兼ね合いも確認。 |
特に「クライアントアプリ」の設定で、「特定のブラウザーのみ許可」「モバイルブラウザーはブロック」といった条件が組まれていると、iOS Safari だけが弾かれる事象が起きやすくなります。
アクセス制御（Grant / Session）を確認する
次に、各ポリシーの「アクセス制御」を確認します。ここで Safari に影響しやすいのは以下のような条件です。
- 準拠デバイスを要求する（Intune 準拠デバイスのみ許可）
- 承認済みクライアントアプリを要求する
- アプリ保護ポリシーを要求する
- セッション制御（条件付きアクセスアプリ制御など）
| 制御内容 | Safari への影響 | 対処の方向性 |
|---|---|---|
| 準拠デバイス必須 | iOS 端末が Intune に登録されていない、または準拠状態でない場合、ブラウザーアクセスがブロックされる。 | BYOD 端末でブラウザーアクセスを許可したいかどうか、ポリシー設計を見直す。必要に応じて例外グループを用意。 |
| 承認済みクライアントアプリ必須 | Safari など汎用ブラウザーからのアクセスは原則 NG。SharePoint / OneDrive / Teams / Edge アプリなど「承認済みアプリ」のみ許可される。 | 方針が「アプリ経由を強制」なのであれば、ユーザーにはアプリ利用を案内。ブラウザー利用を許可したい場合は設定の緩和を検討。 |
| アプリ保護ポリシー必須 | アプリ保護ポリシーに対応していないクライアントからのアクセスがブロックされる。Safari は通常対象外。 | モバイル端末からはアプリ経由アクセスを標準とし、ブラウザーは PC のみ許可するなどの運用ルールを明確にする。 |
| セッション制御 | リバースプロキシ型の制御（CA アプリ制御など）が Safari の Cookie ポリシーと競合し、意図しないブロックになることがある。 | 特定のサイト / ユーザーのみ制御対象にする、もしくはモバイルブラウザーを制御対象外にするなどチューニングを検討。 |
「No Item exists at URL」というメッセージ自体は SharePoint 側の表示ですが、その裏では「条件付きアクセスで拒否された」「トークンが取得できず未認証扱いになった」といった要因が隠れていることが多い点に注意しましょう。
ブラウザー制限の設計方針を確認する
昨今のセキュリティ要件の高まりから、「ブラウザーは Edge のみ許可」「モバイルブラウザーは禁止し、アプリのみ許可」といったポリシー設計も一般的になってきました。
このようなポリシーを採用している場合は、次のような方針を整理しておくと運用がスムーズです。
- 個人端末（BYOD）からのアクセス方針
→ 会社支給端末以外は「アプリのみ許可」「特定サイトのみ許可」などを明文化する。 - サポート対象ブラウザーの明示
→ 「PC は Edge / Chrome をサポート」「iOS は SharePoint / OneDrive / Teams アプリを推奨」など、ユーザー向けガイドに明記。 - 例外申請フロー
→ 特定業務で Safari など別ブラウザー利用が必須な場合の例外申請方法を用意しておく。
こうした方針が整理されていれば、「Safari で開けないのは仕様」「この場合はアプリを使ってください」と明確に案内でき、無駄なトラブルシュートを減らせます。
テストとログで原因を切り分ける
原因が条件付きアクセスかどうかを切り分けるには、次のような手順をおすすめします。
- 問題が発生しているユーザーを、一時的に該当の CA ポリシーの「除外」に追加する
- その状態で iOS Safari から SharePoint にアクセスしてもらい、再現性を確認する
- エラーが解消した場合、そのポリシーが原因である可能性が極めて高い
併せて、サインインログ / 監査ログも確認しましょう。
- Entra 管理センター > サインイン から該当ユーザーのログを検索
- アプリケーションが「SharePoint Online」「Microsoft Office」等になっているイベントを確認
- 結果が「失敗」で、詳細に「条件付きアクセスによってブロックされた」旨が記録されていないか確認
ここで CA によるブロックが確認できれば、Safari の設定ではなくポリシー側を調整するべきと判断できます。
実務でよくある落とし穴と回避策
「デスクトップでは成功・Safari だけ失敗」は認証周りを疑う
エラーメッセージに「No Item exists…」と書かれているため、「ファイルが削除されたのでは？」と考えがちですが、デスクトップブラウザーでは開けるのに Safari だけ失敗する場合、ほぼ認証や条件付きアクセスの問題です。
このようなときは、次の優先順位で確認すると効率的です。
- Safari のプライバシー設定（ITP / Cookie 制限）
- Safari の Web サイトデータ削除と再サインイン
- URL の整形（空白 / 改行 / 未エンコード文字の除去）
- SharePoint / OneDrive アプリから開けるか確認
- 条件付きアクセスのポリシー有無を管理者に確認
チャットやメールによるリンク共有で URL が途中で切れている
特にモバイル環境では、長い URL が自動で折り返され、その折り返し位置までしかコピーされていないというトラブルが頻発します。これを避けるための実務的な対策としては、次のようなものがあります。
- 共有リンクの生成時に「短縮リンク」を使用する
- 「メールで送信」や「アプリで共有」機能を利用し、ユーザーに直接コピーさせない
- 業務マニュアルや社内ポータルでは、可能な限り「ライブラリのパス」だけを案内し、実際のアイテムはユーザーに画面操作でたどってもらう
特にモバイルチャットアプリでは、リンクの前後に全角スペースや余計な文字が混入することもあるため、問題が起きたときはメモアプリなどに貼り付けて確認する癖をつけるとよいでしょう。
共有設定とサインイン要求の齟齬
SharePoint 側の共有設定が次のようになっていると、モバイルでのアクセス時に余計な混乱を生むことがあります。
- リンクの種類が「特定のユーザー」だが、受け取った側が別アカウントでサインインしている
- 社内限定リンクにもかかわらず、私用端末から別テナントのアカウントでアクセスしている
この場合、SharePoint は「対象ユーザーが違うためアクセス権がない」と判断しますが、その結果として「No Item exists…」というメッセージを返すことがあります。特定ユーザーリンクを多用している組織では、ユーザーに対して「どのアカウントでサインインすべきか」を明確に案内するとトラブルを減らせます。
よくある質問（FAQ）
Q. iOS の Chrome や他ブラウザーなら開けるのに、Safari だけ失敗します。なぜですか？
A. iOS の Chrome や Edge は内部的に Safari と同じレンダリングエンジン（WebKit）を使っていますが、アプリとしての挙動や Cookie の扱いが微妙に異なるため、ある環境では Chrome だけ動く / Safari だけ動くといった差が出ることがあります。とはいえ、根本的な原因はやはり「Cookie・トラッキング制御」「条件付きアクセス」「URL の不整合」であることが多いため、本記事のチェックリストに沿って原因を切り分けることをおすすめします。
Q. Safari の「サイト越えトラッキングを防ぐ」は常にオフにしておいて良いですか？
A. セキュリティ / プライバシーの観点では、むやみにオフにし続けるのはおすすめできません。あくまでトラブルシューティングのために一時的にオフにするという位置付けで考え、問題の原因が条件付きアクセスや URL であった場合は、必要に応じてオンに戻すことを検討してください。組織が MDM などで Safari 設定を管理している場合は、必ず管理者の方針に従いましょう。
Q. BYOD（個人所有端末）で Safari から SharePoint を使わせたいのですが、何に気をつければよいですか？
A. BYOD でのアクセスはセキュリティリスクが高くなるため、次のような観点でポリシーを決めておくとよいです。
- 「ブラウザー利用を認めるか」「アプリのみ許可するか」を明確にする
- ブラウザーを認める場合でも、「機密度の高いサイトはアプリのみ」といった段階的な制御を検討する
- ユーザー向けには、「Safari でエラーになったらアプリを使う」「業務用アカウントと個人アカウントを分けて使う」といった具体的な行動指針を提示する
セキュリティを優先するなら、「BYOD は原則アプリのみ」「ブラウザーは会社支給端末のみ」といった割り切ったルールも有効です。
Q. 利用者への案内文テンプレートが欲しいです。
以下のような短い案内を、社内ポータルやヘルプページに掲載しておくと、同じ質問への対応コストを減らせます（必要に応じてカスタマイズしてください）。
iPhone / iPad の Safari で SharePoint を開いたときに「No Item exists at URL…」と表示される場合は、以下をお試しください。
- 設定 > Safari で「サイト越えトラッキングを防ぐ」を一時的にオフにする
- 設定 > Safari > 詳細 > Webサイトデータ で sharepoint.com / microsoftonline.com / onedrive.com のデータを削除する
- メモアプリにリンクを貼り付け、余計な空白や改行が入っていないか確認してから開く
- それでも開けない場合は、Microsoft Edge（iOS）または SharePoint / OneDrive アプリからアクセスしてください
改善しない場合は、スクリーンショットを添えて情報システム部門までお問い合わせください。
まとめ：Safari 固有の「未認証化 → 404 風メッセージ」を正しく捉える
iOS の Safari で SharePoint が「No Item exists at URL…」と表示される問題は、一見すると「ファイルやサイトが削除されたように見える」ため、ユーザーに強い不安を与えます。しかし実態としては、
- Safari のプライバシー設定による認証エラー
- 条件付きアクセスによるブラウザー制限
- URL のコピペ時に発生した文字列の破損
- 複数アカウントによる認証の衝突
など、「存在しない」のではなく「正しく認証・ルーティングできていない」ことが原因である場合がほとんどです。
エンドユーザー側では、
- Safari の「サイト越えトラッキングを防ぐ」を一時的にオフにし、Web サイトデータを削除して再サインイン
- URL の余計な空白や未エンコード文字を取り除く
- Microsoft Edge（iOS）や SharePoint / OneDrive アプリで開く
といったステップを踏むことで、多くのケースを自己解決できます。
一方、管理者は、
- 条件付きアクセスのポリシー割り当て（ユーザー / アプリ / クライアントアプリ）
- アクセス制御（準拠デバイス、承認済みクライアントアプリ、アプリ保護ポリシー、セッション制御）
- サインインログでの CA によるブロックの有無
を確認し、組織のセキュリティポリシーと利便性のバランスを取りながら、「アプリを前提とするのか」「ブラウザーも許可するのか」を設計していく必要があります。
このように、Safari 固有の挙動と条件付きアクセスの設計を正しく理解しておけば、「No Item exists at URL」という紛らわしいメッセージに振り回されることなく、本来の原因に素早くたどり着けるようになります。モバイルでの SharePoint 利用が増えている今こそ、あらかじめ方針と手順を整備しておくと安心です。
コメント