SharePoint のファイル／サイトにゲスト招待して権限も付与したのに、特定ユーザーだけ「Selected user account does not exist in tenant ‘Microsoft Services’…」でアクセスできない――この症状は、権限不足よりも“サインインしているアカウント（テナント）が想定と違う”ことが原因になりがちです。この記事では、エラーの意味、最短で切り分ける確認ポイント、再招待や別アカウント招待までの現実的な解決策をまとめます。
起きている症状とエラーメッセージの意味
まずは状況を整理します。今回の代表的なエラーは次のとおりです。
Selected user account does not exist in tenant ‘Microsoft Services’ and cannot access the application in that tenant. The account needs to be added as an external user in the tenant first. Please use a different account.
| 観測される事実 | 読み取れること | 重要度 |
|---|---|---|
| ゲスト招待済み／権限付与済みのはず | SharePoint 側の共有設定やアクセス権だけが原因とは限らない | 高 |
| 特定ユーザーだけエラーになる | テナント設定の全体不具合より、当該ユーザーのアカウント状態・サインイン状況に偏りやすい | 高 |
| InPrivate/シークレットでも改善しない | 単なるキャッシュではなく、アカウントの種類（個人/組織）や紐づきの問題の可能性が上がる | 中 |
| エラーに “Microsoft Services” が出る | “今アクセスしようとしている先のテナント”が、あなたの SharePoint テナントではなく、別の既定テナントに誘導されている可能性 | 最重要 |
このエラーの核心は、「今サインインしているアカウントは、アクセス先（アプリ/SharePoint）が属するテナントに存在しない」という点です。さらに “Microsoft Services” と出ているケースでは、個人 Microsoft アカウント（いわゆる MSA）側の既定テナントに誘導されている、または招待したテナントとは別テナントで認証が進んでいる状況が疑われます。
結論：招待されたのと「別のアカウント／別テナント」でサインインしているのが原因になりやすい
結論から言うと、SharePoint にゲスト招待したユーザーがアクセスできない最大の原因は、招待されたアカウントとは別のアカウント（または同じメールに見えても別扱いのアカウント種別）でサインインしてしまうことです。
たとえば次のような「あるある」があります。
- 会社のメールアドレス（例：[email protected]）を持っているが、同じメールで個人 Microsoft アカウント（MSA）を作っていた
- 普段は個人アカウントで Microsoft にサインインしており、招待リンクを開いたときにそのセッションが優先された
- 同じメールアドレスに見えても、職場/学校アカウント（組織）と個人 Microsoft アカウントが別物として存在している
- 複数のテナント（組織）に属していて、ログイン時に想定外のテナントを選んでしまった
この状態だと、エラー文のとおり“Microsoft Services” 側には外部ユーザー（ゲスト）として追加されていないため、「存在しない」「別アカウントを使って」と弾かれます。つまり、SharePoint の権限設定が正しくても、認証の入口で別の世界線に行ってしまっているのが原因です。
なぜ「特定ユーザーだけ」発生しやすいのか
同じ手順で他のゲストは閲覧できるのに、ある 1 人だけがエラーになる場合、「その人のアカウントが特殊」というより、“その人の Microsoft のサインイン履歴・アカウント構成が複雑”であることが多いです。
| 起きがちな背景 | 何が起こるか | 結果 |
|---|---|---|
| 同じメールで個人アカウント（MSA）を作成済み | ログイン画面で個人アカウント側が優先される／自動選択される | “Microsoft Services” に誘導されやすい |
| ブラウザに個人用 Microsoft サインインが残っている | 招待リンクを開いた瞬間に既存セッションが使われる | 想定アカウントでの切替が起きない |
| 複数の組織テナントへ参加（B2B/マルチテナント環境） | テナント選択が発生し、誤った側で続行してしまう | 「存在しない」扱いになる |
| ゲスト招待を過去に何度も受けている／古い招待が残っている | 古い招待・古いオブジェクトと衝突することがある | 再招待しても挙動が不安定に見える |
要するに、同じ「メールアドレス」に見えても、Microsoft の認証世界では“どの種類のアカウントとして存在しているか”が結果を分けます。
最初にやるべき切り分け：いま何でサインインしているかを揃える
このエラーは、いきなり「ゲスト削除→再招待」に飛ぶより、まずサインインの前提を揃えるほうが早く解決することがあります。ゲストユーザー向け／管理者向けに、確認ポイントを分けて整理します。
ゲストユーザー側でまず試すこと（案内用）
- Microsoft 系サイトから完全にサインアウトする（個人アカウントを含む）
- 可能なら別ブラウザ、または別プロファイルを作って開く（Edge/Chrome の「プロファイル」を分ける）
- 招待メールのリンクを開く際、アカウント選択が出たら招待されたメールアドレスのアカウントを明示的に選ぶ
- アカウント選択が出ない場合は、一度ブラウザを閉じてやり直す（ウィンドウを残したままだとセッションが残ることがあります）
ポイントは、「シークレットでもダメ」＝「キャッシュが悪い」とは限らないことです。シークレットでも、ログインの流れで個人アカウントを使ってしまうと同じ結果になります。特に、端末やブラウザで個人 Microsoft アカウントに普段からサインインしている人ほど起きやすいです。
管理者側で確認すること（最短チェック）
| チェック項目 | 見るべき観点 | 意図 |
|---|---|---|
| ゲストユーザーがディレクトリに存在するか | Microsoft Entra ID（旧 Azure AD）のユーザー一覧に当該メールがあるか | 招待が“そもそも登録されていない”を除外 |
| SharePoint のサイト権限に入っているか | サイトメンバー/訪問者/所有者、またはファイル権限に当該ゲストがいるか | 純粋な権限不足を除外 |
| 外部共有ポリシー | テナント全体／サイト単位で外部共有が許可されているか | 設定のブロックを除外 |
| “Microsoft Services” という文言 | ユーザーが間違ったアカウントで入っている兆候 | 根本原因（認証ミスマッチ）に寄せる |
この時点で「存在するし権限もあるのにダメ」なら、ほぼ認証ミスマッチ（別アカウント/別テナント）です。ここから先は、再招待か別アカウント招待が現実的な解決ルートになります。
実際に有効だった回避策：別アカウントを新規作成して招待し直す
スレッドの解決内容として有効だったのは、次の手段です。
- 新しいユーザー（別アカウント）を作成して招待し直したら解消した
これは非常に示唆的で、当該ユーザーは「同じメールアドレスでも別扱いになる」ような状態（個人/組織の取り違い、過去の紐づき、複数テナント所属など）により、認証が安定しなかった可能性が高いです。
現場対応としては、次のような判断が合理的です。
| 対処案 | 効果 | コスト | 向いている状況 |
|---|---|---|---|
| ログインし直し（別ブラウザ/別プロファイル） | 正しいアカウントに戻せれば一発で直る | 低 | 今すぐ試せる／ユーザーが協力的 |
| ゲストを削除→再招待 | 古い招待や状態の影響をリセットできる | 中 | 同じメールのまま直したい／履歴が怪しい |
| 別アカウント（新規メール等）で招待 | 認証の衝突要因を丸ごと回避しやすい | 中〜高 | 特定ユーザーだけ何をやっても直らない |
「削除→再招待」でも解決しない、あるいはユーザー側のアカウント事情が複雑で切り分けに時間がかかる場合、運用としては別アカウント招待が最速の着地点になりやすいです。
現実的な対処手順：まずはサインインの取り違いを潰す
ここからは、管理者が案内しやすいように、実務向けの手順としてまとめます。
手順：ゲストユーザーに案内する（取り違い対策）
- ブラウザで Microsoft 関連（Microsoft 365、Outlook.com、OneDrive 個人版など）を開いているタブをすべて閉じる
- ブラウザのプロファイルを分ける（仕事用/個人用が混ざらないようにする）
- 新しいプロファイル（または別ブラウザ）で、招待されたメールアドレスでサインインする
- 招待メールのリンクを開き直す
ここで重要なのは、「同じメールアドレスに見える」ことに安心しないことです。Microsoft のログイン画面では、メールアドレスを入力すると個人アカウントとして続行できてしまう場合があり、結果として “Microsoft Services” に寄っていきます。
手順：それでもダメなら削除→再招待（管理者側）
「同じメールのまま直したい」場合に、次が王道です。
- Microsoft Entra ID（旧 Azure AD）で当該ゲストユーザーを削除（またはブロック解除/状態確認）
- SharePoint サイト側のメンバー/権限から当該ユーザーを除外
- 数分待って反映させた上で、あらためて招待を送り直す
- 招待メールからアクセスしてもらい、初回の招待承諾フローを完了させる
再招待がうまくいかないときは、招待を送っただけで「承諾が完了していない」ケースもあります。ユーザーが招待メールを開いて承諾フローまで進んだか（途中で別アカウントに切り替えていないか）も、実は重要です。
手順：最短で片付けるなら別アカウント招待
何度やっても当該ユーザーだけ直らない場合、運用判断として次が強いです。
- 当該ユーザーに別のメールアドレス（新規作成でも可）を用意してもらう
- そのメールアドレスでゲスト招待し直す
- 以後、SharePoint へのアクセスはそのアカウントを正として運用する
これは「根本原因の究明を後回しにしてでも業務を回す」ための割り切りです。特に期限がある共有（監査資料、契約書レビュー、共同編集など）では、結果として最もトラブルが少ない着地になります。
アカウント種別の違いを押さえる（個人 Microsoft アカウント vs 職場/学校アカウント）
この手のトラブルは、言葉にすると簡単ですが、現場では混乱しやすいので表で整理します。
| 項目 | 個人 Microsoft アカウント（MSA） | 職場/学校アカウント（組織・Entra ID） |
|---|---|---|
| 主な用途 | 個人向け Outlook.com、OneDrive 個人版、Xbox など | Microsoft 365（会社/学校）、Teams、SharePoint、管理対象サービス |
| 所属の概念 | 基本は個人の世界（既定テナントに寄りやすい） | テナント（組織）に属する。ゲストは外部ユーザーとして招待される |
| 同じメールで共存 | できる場合があり、取り違いが起きる | できる場合があり、取り違いが起きる |
| 今回のエラーとの関係 | 誤ってこちらでログインすると “Microsoft Services” 側に行きやすい | 招待された側がこちらなら、こちらでログインしないとアクセスできない |
SharePoint のゲスト共有は、基本的にMicrosoft Entra ID（旧 Azure AD）の B2B ゲストとしてユーザーが紐づきます。したがって、ユーザーが違う種類のアカウントでログインしてしまうと、権限があっても入れません。
“Microsoft Services” と出るときの見分けポイント
エラー文のテナント名が “Microsoft Services” の場合、「あなたの SharePoint テナント名」ではないはずです。ここを起点に、次のように切り分けます。
- エラーに自社テナント名が出ていない → ログイン先がズレている可能性が高い
- ユーザーが普段 Outlook.com 等を使っている → 個人アカウントが優先されている可能性
- ログイン画面で“個人アカウントとして続行”が選べてしまう → 取り違いの温床
この段階で、サイト側設定をいじる前に、まず「正しいアカウントでログインし直す」に舵を切るのが最短です。
管理者がやりがちな落とし穴
外部共有のトラブルは、つい SharePoint 側の権限ばかり見がちですが、今回のようなエラーでは次の落とし穴があります。
「権限を付けた＝入れる」と思い込む
SharePoint の権限は「認証が通った後」に評価されます。認証の入口で別テナント扱いになっていると、どれだけ権限を盛っても入れません。
「シークレットでダメ＝設定が原因」と決めつける
シークレットは確かにキャッシュを減らせますが、ログインフローの中で個人アカウントを選んでしまえば同じです。シークレットは万能薬ではなく、アカウント選択の失敗を防ぐ仕組みではありません。
同じメールアドレスを見て安心する
現場では「メールアドレスが同じだから同一人物＝同一アカウント」と扱いがちです。しかし Microsoft の認証では、同じ見た目のメールアドレスでも、別の資格情報として存在し得ます。これがトラブルの根です。
ユーザーへの案内テンプレ（コピペ用）
サポート窓口・情シスからゲストユーザーに送る文面として、そのまま使える形にまとめます。
| 案内文テンプレ |
|---|
| SharePoint のリンクを開く際、別の Microsoft アカウント（個人アカウント等）でサインインしていると「Selected user account does not exist in tenant ‘Microsoft Services’…」が表示されることがあります。 お手数ですが、次の手順でお試しください。 Microsoft 関連サイト（Outlook.com、Office、OneDrive 等）をすべてサインアウト／タブを閉じる ブラウザの「別プロファイル」または別ブラウザを起動する 招待されたメールアドレスのアカウントでサインインする こちらのリンクを開く（再度お送りします） それでも解決しない場合、別のメールアドレスで招待を作り直すことで解消するケースがあります。必要であれば代替アドレスをご連絡ください。 |
よくある質問
削除→再招待をしても同じエラーが出るのはなぜ？
多くの場合、ユーザー側が再招待後も同じ誤ったアカウントでサインインしているためです。招待を作り直しても、入口で “Microsoft Services” 側へ入ってしまうと、やはり「そのテナントにいない」と判断されます。再招待の効果を出すには、初回の招待承諾フローを“正しいアカウント”で踏む必要があります。
同じメールアドレスのまま直したい。現実的に可能？
可能性はありますが、状況次第です。ユーザーがそのメールアドレスを個人 Microsoft アカウントとしても使っている場合、どちらが優先されるかが環境に左右され、再発しやすいことがあります。業務の優先度が高いなら、別アカウント（別メール）での招待が結果として安定します。
端末を変えると直ることがある？
あります。端末やブラウザによって、既存のサインイン状態（個人アカウントのセッション）が変わるためです。ただし根本は「正しいアカウントで認証できているか」なので、端末変更はあくまで切り分けの一手です。再発防止の観点では、仕事用と個人用のブラウザプロファイル分離が有効です。
補足：独自アプリのログインで同じ系統のエラーが出る場合
同種のエラーは、SharePoint だけでなく、独自アプリ（Azure / Entra ID のアプリ登録でサインインする Web アプリ等）でも起きることがあります。典型は次のパターンです。
- アプリ登録がシングルテナント（特定テナントのユーザーのみ）なのに、他テナントや個人アカウントでログインしようとしている
- 認可エンドポイントや Authority が、想定と違う（
common/organizations/consumersの使い分けがズレている）
アプリ側の考え方を表にすると、切り分けしやすくなります。
| エンドポイント/対象 | ログインできるアカウント | 用途の目安 |
|---|---|---|
common | 組織アカウント＋個人 Microsoft アカウント | 幅広く許容したい（ただし要件整理が必要） |
organizations | 組織アカウント（Entra ID） | 会社・学校アカウントのみ許可したい |
consumers | 個人 Microsoft アカウント（MSA） | 個人向けサービスに寄せたい |
<tenant-id> / <tenant-name> | そのテナントのユーザーのみ（基本） | シングルテナント運用 |
アプリの「サポートされているアカウントの種類」をマルチテナント対応に変更する、またはログイン先テナントを固定するなど、要件に合わせて整合させることで解決に向かいます。SharePoint のゲスト問題と同じく、根っこは“どのテナントの誰として認証しているか”です。
// 例：Authority（概念例）
https://login.microsoftonline.com/organizations
https://login.microsoftonline.com/common
https://login.microsoftonline.com/<tenant-id>
再発防止のための運用ポイント
一度直っても、同じユーザー・同じ環境で再発することがあります。ゲスト共有を安定させるために、次の運用をおすすめします。
- ゲストには「仕事用ブラウザプロファイル」を案内する（個人アカウントと混ぜない）
- 招待メールを転送・使い回ししない（リンクを別チャネルに貼ると、既存ログインの影響を受けやすい）
- 特定ユーザーで詰まったら、深追いせず別メールでの招待を許容するルールを用意する
- 管理者側は、SharePoint の共有設定と Entra ID のゲスト状態をセットで確認する手順書を持つ
「Selected user account does not exist in tenant ‘Microsoft Services’…」は、権限設定の問題に見えて実は“入り口の認証ミス”であることが多いエラーです。まずはサインインアカウントの取り違いを疑い、ダメなら削除→再招待、さらにダメなら別アカウント招待という順で進めると、最短で解決しやすくなります。
コメント