MENU

Microsoft Teamsで社内ユーザーを追加できない時の最速解決ガイド

Teams

先に結論です。Microsoft Teamsで社内ユーザーを追加できないときは、いきなりテナント全体の権限を変更しません。まず実行者がチーム所有者か、対象チームが動的メンバーシップか、Microsoft 365のサービス障害がないか、Information Barriersで追加が禁止されていないかを確認します。その後、特定のエラー条件に一致する場合だけMicrosoft Entra IDのAllowedToReadOtherUsersをMicrosoft Graphで調べます。

旧AzureAD PowerShellモジュールの導入や、旧モジュールによるテナント詳細変更を新しい手順として使わないでください。AzureADとMSOnlineのPowerShellモジュールは廃止・移行対象です。2026年時点ではMicrosoft Graph PowerShellを使い、読み取り確認、変更承認、最小権限、監査記録をそろえてから変更します。

ITtripTOOLS
その「面倒」、無料で解決。 ITtripがつくる、6つの道具。 無料ツール一覧へ すべて無料・追加課金なし
先頭0を守るCSV編集こわさないCSV PDFに直接書き込みかけるPDF 写真＋説明をPDFに写レポ スマホ⇄PCで共有コピペ便 · 文章・写真 みんなの日程を調整日程Fit 匿名質問・投票を集めるKOEQ
目次

症状と確認先の判断表

症状主な原因候補最初の確認
［メンバーを追加］を実行できない所有者ではない、動的チーム役割とメンバーシップ種別を確認する
社内ユーザーが検索に出ないUPN違い、アカウント状態、Information Barriers、ディレクトリ読み取り制限Entra IDのユーザーと正確なUPNを確認する
We couldn’t add memberと表示される一時障害、グループ処理、AllowedToReadOtherUsers=Falseサービス状態と基盤グループへの追加可否を比較する
追加後もしばらく表示されない動的ルール、反映待ち、クライアントキャッシュMicrosoft 365グループ側と反映時刻を確認する
共有チャネルを持つチームだけ失敗するInformation Barriers、共有先との制約Purview管理者へポリシー判定を確認する
外部メールアドレスだけ失敗するゲストアクセス、外部アクセス、B2B設定社内Memberとは別のゲスト手順へ分岐する
多くのユーザーで同時発生Microsoft 365サービス障害、管理変更Service healthと変更履歴を確認する

「社内ユーザー」と「ゲスト」は分けてください。同一テナントのMember、別テナントから招待されたB2B Guest、外部アクセスでチャットする相手、共有チャネルの外部参加者は異なる仕組みです。対象ユーザーの種類を間違えると、ゲスト設定を変えても社内メンバー追加は直りません。

調査前に記録する情報

  • 対象チームの正確な表示名と、可能ならチームID・基盤Microsoft 365グループID
  • 追加を実行したユーザーの役割がOwnerかMemberか
  • 追加対象ユーザーのUPN、表示名、User type、アカウント有効状態
  • エラー全文、発生時刻、Teamsデスクトップ・Webのどちらで発生したか
  • 同じ対象をMicrosoft 365グループへ直接追加できるか
  • チームが静的か動的か、標準・非公開・共有チャネルを持つか
  • 同じ時刻のService health、監査ログ、管理変更履歴

この情報をそろえると、ユーザー1人の属性問題、1チームの構成問題、テナント全体のポリシー、Microsoft側の障害を分けられます。変更前の値を記録しないままPowerShellを実行すると、直ったとしても原因と影響を説明できません。

安全な確認手順

  1. チーム所有者か確認します。Teamsで対象チームの［チームを管理］を開き、実行者の役割を確認します。Microsoftの公式説明では、非公開チームへメンバーを直接追加する基本権限は所有者にあります。
  2. Service healthを確認します。管理者はMicrosoft 365管理センターの［Health］→［Service health］でTeamsと関連サービスのインシデントを確認します。広域障害中はテナント設定を変えず、復旧更新を待ちます。
  3. 対象ユーザーを確認します。Microsoft Entra管理センターで正確なUPN、User type、アカウント有効状態、削除済みでないことを確認します。表示名だけで別ユーザーを選ばないようにします。
  4. 動的メンバーシップを確認します。基盤Microsoft 365グループがDynamicなら手動追加を中止し、動的ルールとユーザー属性を確認します。所有者でもメンバーを直接追加・削除できません。
  5. Information Barriersを確認します。Purview Information Barriersを利用している組織では、追加元と対象ユーザーのセグメント、共有チャネルの共有先との組み合わせをコンプライアンス管理者が確認します。
  6. Teams管理センターで比較します。Teams管理センターの［Teams］→［Manage teams］→対象チーム→［Members］で追加を試し、クライアント固有かサービス側かを切り分けます。既存所有者を削除しません。
  7. 基盤グループで比較します。同じユーザーを対象チームのMicrosoft 365グループへ追加できるか確認します。新しいOutlookグループを作るのではなく、既存チームの基盤グループで比較します。
  8. 特定条件でだけAuthorization Policyを調べます。公式の既知事象と同じエラーが出て、基盤Microsoft 365グループへは追加できる場合に限り、AllowedToReadOtherUsersを読み取ります。
  9. 変更後に反映を検証します。グループ、Teams管理センター、Teamsクライアントの順で状態を確認し、変更者、時刻、旧値、新値、結果を監査記録へ残します。

チーム所有者と基本の追加操作

Microsoftの公式手順では、チーム所有者はチーム名の［その他のオプション］からメンバー追加を開き、名前、配布リスト、セキュリティグループ、Microsoft 365グループなどを検索できます。非所有者は追加を要求し、所有者が承認または拒否する流れになります。画面に追加項目がない場合は、まず役割とチーム種別を確認します。

Teams管理センターでも、管理者は［Manage teams］から対象チームを開き、［Members］でメンバーと所有者を管理できます。クライアントで失敗し管理センターでは成功する場合、クライアントのセッション、キャッシュ、段階配信の影響が考えられます。両方で失敗する場合はグループ、ポリシー、サービス側へ調査を進めます。

ライセンスは対象ユーザーがTeamsを利用できるかに関係しますが、メンバーシップ追加そのものと同じ判定ではありません。アカウント作成、利用場所、ライセンス割り当て、サービスプラン、サインイン許可を別々に確認し、「ライセンスがないから検索に出ない」と一つの原因へ決めつけないでください。

動的メンバーシップなら手動追加しない

動的メンバーシップのチームでは、Microsoft Entra IDのユーザー属性をルールが評価し、メンバーを自動追加・削除します。Microsoftは、所有者でもメンバーを手動追加・削除できず、Teamsクライアントのメンバー管理項目が非表示になると説明しています。これは不具合ではありません。

対象ユーザーを参加させるには、ユーザーのdepartment、country、jobTitleなど、実際の動的ルールが参照する属性を正しく更新するか、業務要件に合わせてルールを変更します。ルールを一人だけ通すために虚偽の属性を設定すると、ライセンス、アクセス制御、他グループにも影響するため行わないでください。

Microsoftの資料では、動的メンバーシップがMicrosoft 365グループへ反映された後、Teamsに見えるまで数分から最大2時間程度かかる場合があります。変更直後に何度も別経路から追加せず、Entra IDの処理状態とグループメンバーを確認して待ちます。

Information Barriersによるブロック

Microsoft Purview Information Barriersは、規制業界や利益相反管理のため、特定のユーザー同士が検索、チャット、ファイル共有、チーム参加を行えないよう制限します。公式資料では、ユーザー検索とチームへのメンバー追加が明示的な制御対象です。検索候補へ出ないことが、設定ミスではなくコンプライアンス要件の場合があります。

対象チームに他チームと共有した共有チャネルがある場合、新しいユーザーと共有先メンバーの組み合わせもInformation Barriersの判定対象になり得ます。エラーにInformation Barriersと表示されたら、回避のためポリシーを無効化せず、コンプライアンス管理者に必要な共同作業が許可されるか確認します。

情報バリアがない組織で、同一テナントの多くのユーザーが検索できない場合は、次のAuthorization Policyの分岐へ進みます。情報バリアを使っているか不明なら、Teams管理者だけで判断せずPurview管理者へ確認します。

AllowedToReadOtherUsersを確認する条件

Microsoftには、Teamsで内部または外部メンバーを追加すると「We couldn’t add member. We ran into an issue. Please try again later.」と表示される一方、Microsoft 365グループへは直接追加できる事象について公式資料があります。この条件でUsersPermissionToReadOtherUsersEnabledがFalse、現在のMicrosoft Graph表現ではauthorizationPolicy.defaultUserRolePermissions.allowedToReadOtherUsersがFalseだと、Teamsが利用者を検索できない場合があります。

これは「Teamsで追加できない原因の大半がこの設定」という意味ではありません。動的チーム、所有者不足、情報バリア、サービス障害、UPN違いなどを除外し、公式の症状と基盤グループでの成功条件が一致した場合だけ確認します。

Microsoft Graph PowerShellで読み取る

読み取りは変更ではありませんが、組織の管理端末と承認された管理アカウントを使います。Microsoft Graph PowerShellが未導入なら、現在のユーザー範囲へインストールします。

Install-Module Microsoft.Graph -Scope CurrentUser

次に読み取り権限で接続し、Authorization Policyの既定ユーザーロール権限を表示します。変更承認記録にあるテナントID、管理アカウント、承認済みスコープを使い、接続直後のGet-MgContextでTenantIdとAccountが承認記録に一致すること、必要なGraphスコープが含まれること、文書化されたOIDC/基本スコープの許可リスト外のスコープが含まれないことを確認し、いずれかを満たさなければ処理を中止します。組織の同意ポリシーにより管理者同意が必要な場合があります。

$approvedTenantId = Read-Host "変更承認記録のテナントID"
$approvedAccount = Read-Host "変更承認記録の管理アカウントUPN"
$approvedScopes = @("Policy.Read.All")
$allowedContextScopes = $approvedScopes + @("openid", "profile", "email", "offline_access", "User.Read")
Connect-MgGraph -TenantId $approvedTenantId -ContextScope Process -Scopes $approvedScopes
$context = Get-MgContext
$context | Format-List Account, TenantId, Scopes
$contextScopes = @($context.Scopes)
$unexpectedScopes = @($contextScopes | Where-Object { $_ -notin $allowedContextScopes })
if ($context.Account -ne $approvedAccount -or
    $context.TenantId -ne $approvedTenantId -or
    $approvedScopes[0] -notin $contextScopes -or
    $unexpectedScopes.Count -gt 0) {
    Disconnect-MgGraph
    throw "承認記録と接続コンテキストが一致しないため中止しました。"
}
$policy = Get-MgPolicyAuthorizationPolicy
$policy.DefaultUserRolePermissions | Format-List AllowedToReadOtherUsers
Disconnect-MgGraph

結果がTrueなら、この設定は原因ではありません。別の項目を調査します。Falseなら、いつ、誰が、何の目的で変更したかを監査ログと変更管理記録で確認します。Falseは既定ユーザーが他のユーザー情報を読めなくするテナント全体の制限で、Microsoftは特殊な状況向けとしており推奨していません。

承認後にTrueへ戻す手順

公式症状と一致し、False設定が意図したセキュリティ要件ではなく、セキュリティ担当の承認がある場合だけ変更します。Microsoft Graphの公式資料では、Policy.ReadWrite.Authorization権限が必要で、委任シナリオの最小Microsoft EntraロールとしてPrivileged Role Administratorが示されています。実行時は承認記録のテナントID、管理アカウント、スコープと接続コンテキストを照合し、更新直前にも再確認します。現在のFalse値と対象テナントの表示を変更記録へ保存し、条件が一致する場合だけ続行します。常用の一般管理者アカウントで安易に実行しません。

$approvedTenantId = Read-Host "変更承認記録のテナントID"
$approvedAccount = Read-Host "変更承認記録の管理アカウントUPN"
$approvedScopes = @("Policy.ReadWrite.Authorization")
$allowedContextScopes = $approvedScopes + @("openid", "profile", "email", "offline_access", "User.Read")
Connect-MgGraph -TenantId $approvedTenantId -ContextScope Process -Scopes $approvedScopes
$context = Get-MgContext
$context | Format-List Account, TenantId, Scopes
$contextScopes = @($context.Scopes)
$unexpectedScopes = @($contextScopes | Where-Object { $_ -notin $allowedContextScopes })
if ($context.Account -ne $approvedAccount -or
    $context.TenantId -ne $approvedTenantId -or
    $approvedScopes[0] -notin $contextScopes -or
    $unexpectedScopes.Count -gt 0) {
    Disconnect-MgGraph
    throw "承認記録と接続コンテキストが一致しないため中止しました。"
}
$policy = Get-MgPolicyAuthorizationPolicy
$currentValue = $policy.DefaultUserRolePermissions.AllowedToReadOtherUsers
[pscustomobject]@{
    TenantId = $context.TenantId
    AllowedToReadOtherUsers = $currentValue
} | Format-List
if ($currentValue -ne $false) {
    Disconnect-MgGraph
    throw "現在値がFalseではないため更新を中止しました。"
}
$params = @{
    defaultUserRolePermissions = @{
        allowedToReadOtherUsers = $true
    }
}
$context = Get-MgContext
$context | Format-List Account, TenantId, Scopes
$contextScopes = @($context.Scopes)
$unexpectedScopes = @($contextScopes | Where-Object { $_ -notin $allowedContextScopes })
if ($context.Account -ne $approvedAccount -or
    $context.TenantId -ne $approvedTenantId -or
    $approvedScopes[0] -notin $contextScopes -or
    $unexpectedScopes.Count -gt 0) {
    Disconnect-MgGraph
    throw "更新直前の接続コンテキストが承認記録と一致しないため中止しました。"
}
Update-MgPolicyAuthorizationPolicy -BodyParameter $params -Confirm

更新後に同じセッションで値を読み直し、Trueになったことを確認してから切断します。

$policy = Get-MgPolicyAuthorizationPolicy
$policy.DefaultUserRolePermissions | Format-List AllowedToReadOtherUsers
Disconnect-MgGraph

監査記録には変更者、実行時刻、対象テナント、旧値、新値、承認者、関連インシデント、再試験結果を残します。チーム1つだけの設定ではないため、Teams以外のMicrosoft 365サービスや社内アプリのユーザー検索も確認します。

旧AzureADコマンドを使わない

以前はAzureADモジュールのテナント詳細取得・変更コマンドでUsersPermissionToReadOtherUsersEnabledを扱う手順が使われました。しかしAzureADとMSOnlineのPowerShellモジュールは廃止・サポート終了の対象となり、MicrosoftはMicrosoft Graph PowerShell SDKまたはMicrosoft Entra PowerShellへの移行を案内しています。

旧モジュールを新たに導入すると、接続できない、認証方式が現行要件に合わない、将来再び動かなくなるという問題が起こります。記事、手順書、自動化スクリプトから旧コマンドを除き、必要権限と戻り値が異なることを確認してGraph版へ移行します。

Outlookで別グループを作る回避策を常用しない

Outlookで新しいMicrosoft 365グループを作り、それを新しいチームへ変換すればメンバーを集められる場合があります。しかし既存チームの問題は解決せず、別のグループメールボックス、SharePointサイト、権限、保存場所が増えます。利用者がどちらを使うか分からなくなり、情報が分散します。

診断では、既存チームの基盤Microsoft 365グループへ同じユーザーを追加できるかを比較します。新しいグループを作る必要はありません。業務上どうしても新チームが必要なら、情報所有者、保持方針、既存データの移行、旧チームの扱いを決めた正式な変更として実施します。

追加後に反映されない場合

  • 動的チーム：Entra IDの動的処理状態と基盤グループを確認し、最大2時間程度の反映待ちを考慮します。
  • 静的チーム：Teams管理センターとMicrosoft 365グループのメンバーを比較し、どの層まで反映したか確認します。
  • クライアントだけ古い：Teams Webで確認し、サインアウト・サインインやクライアント更新を検討します。テナント設定を再変更しません。
  • 対象ユーザーが利用できない：追加成功とTeams利用可否を分け、ライセンス、サインインブロック、サービスプランを確認します。
  • 監査上は成功だが見えない：サービスインシデント、レプリケーション、クライアントキャッシュを記録し、Microsoftサポートへ時刻とIDを伝えます。

よくある質問

グローバル管理者なら必ず追加できますか

必ずではありません。動的メンバーシップはルール管理で、Information Barriersはコンプライアンス制御です。管理者権限で無理に回避せず、チーム種別とポリシーの意図を確認します。

AllowedToReadOtherUsersをTrueにして安全ですか

TrueはMicrosoftが通常推奨する状態ですが、テナント全体の既定ユーザー権限を変えます。Falseが意図した情報分離要件でないこと、公式症状に一致すること、セキュリティ担当の承認があることを確認してから変更します。

ユーザーにTeamsライセンスがないと追加できませんか

メンバーシップ追加と、そのユーザーがTeamsを利用できるかは別に確認します。アカウント状態、ライセンス、サービスプラン、サインイン許可を個別に調べ、ライセンスだけを単一原因にしません。

社内ユーザーをゲストとして追加すれば回避できますか

勧めません。同一人物のMemberとGuestが混在し、権限、ファイル所有、監査、通知が複雑になります。正しいテナント内アカウントの問題を直します。

Information Barriersを一時停止できますか

追加のために無断停止してはいけません。法令、利益相反、機密分離の要件を守るための制御です。必要な共同作業が正当なら、コンプライアンス管理者が正式なポリシー変更を判断します。

公式資料

まとめ

Teamsへ社内ユーザーを追加できないときは、所有者、サービス状態、ユーザー情報、動的メンバーシップ、Information Barriers、Teams管理センター、基盤Microsoft 365グループの順で確認します。公式の特定エラー条件に一致した場合だけMicrosoft GraphでAllowedToReadOtherUsersを読み取り、承認後にTrueへ戻します。旧AzureADコマンドや新規グループ乱立を避け、変更範囲を記録しながら解決してください。

Teams
Teams 権限設定 Microsoft 365

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次