Azure Marketplace から SaaS を購入したのに、サブスクリプション状態がいつまで経っても「Pending configuration（構成待ち）」のまま…。構成リンクを押すと Microsoft のサインイン画面に飛ばされ、個人用 Microsoft アカウント（MSA）がブロックされて進めない――この記事では、このよくあるハマりポイントの原因と、最短での解決手順を丁寧に解説します。
Azure Marketplace の SaaS が「Pending configuration（構成待ち）」から進まない問題とは
Azure Marketplace の SaaS オファーを購入すると、多くの場合、Azure ポータルの 「サブスクリプション」や「SaaS の一覧」に対象のオファーが表示され、状態が 「Pending configuration（構成待ち）」になります。
この状態は、購入（課金の準備）は完了したが、SaaS ベンダー側の構成がまだ終わっていないことを意味します。構成を完了させるためには、Azure ポータルから表示される 「構成」リンクをクリックし、SaaS 発行元（ベンダー）が用意した ランディングページでサインインと同意（コンセント）を行う必要があります。
典型的なハマりパターン
今回のケースは、次のような流れで発生することが多いです。
- 従量課金（Pay-As-You-Go）の Azure サブスクリプションを 個人用 Microsoft アカウント（MSA）で開始している。
- Azure Marketplace から SaaS オファーを購入したところ、ステータスが 「Pending configuration」のまま。
- Azure ポータルから「構成」リンクをクリックすると Microsoft のサインイン画面へ遷移。
- 個人アカウント（@outlook.com や Gmail で作成した MSA）でサインインしようとすると、サインインがブロックされ、構成が先に進まない。
これにより、「購入しているのに、サービスが使えない」という、非常にもったいない状態が続いてしまいます。
「Pending configuration」が意味する本当のところ
まず押さえておきたいポイントは、「Pending configuration」は次のような意味を持つ状態だということです。
| 状態表示 | Azure 側の意味 | 実際に起きていること |
|---|---|---|
| Pending configuration （構成待ち） | Marketplace での購入は完了しているが、 発行元の構成が未完了 | SaaS 側にテナント・ユーザー情報がまだ渡っていない ベンダー側ポータルでの初回サインイン・同意が終わっていない 課金開始条件（プロビジョニング完了）が未達のケースもある |
| Subscribed / 有効 | 構成が完了し、利用可能な状態 | ベンダー側でテナント・ユーザーが紐づけられている SaaS アプリケーションにサインインして利用できる |
つまり、「Pending configuration」のままということは、Azure Marketplace での購入処理は通っているが、SaaS ベンダーとあなたのテナント（組織）がまだ接続されていない状態と理解できます。
なぜ個人アカウント（MSA）だと構成できないのか
多くのユーザーが混乱しがちなポイントは、「Azure にサインインできている個人アカウント（MSA）なのに、なぜ SaaS の構成では弾かれるのか」という点です。この背景には、MSA と Microsoft Entra ID（旧 Azure AD）のアカウントモデルの違いがあります。
MSA と Microsoft Entra ID の違い
まずは、よく混同される 2 種類のアカウントの違いを整理しておきましょう。
| 種類 | 代表的なドメイン | 主な用途 | Azure Marketplace SaaS 構成との相性 |
|---|---|---|---|
| MSA（個人用 Microsoft アカウント） | @outlook.com / @hotmail.com / Gmail 連携 など | 個人向けサービス（Outlook.com, Xbox, 個人用 OneDrive など） | 多くの SaaS オファーで 非推奨 or ブロック |
| Microsoft Entra ID の職場/学校アカウント （旧 Azure AD アカウント） | @contoso.com / @<tenant>.onmicrosoft.com など | 組織向けサービス（Azure, Microsoft 365, 企業向け SaaS など） | Azure Marketplace SaaS の 前提アカウントになることが多い |
Azure Marketplace の SaaS オファーは、ほとんどが 組織（テナント）単位での利用を前提としており、ユーザーやアプリケーションは Microsoft Entra ID テナントに属する職場/学校アカウントとして扱われます。そのため、MSA はそもそも対象外としているオファーが非常に多いのです。
Marketplace のランディングページで何が行われているか
「構成」リンクから遷移するランディングページでは、次のような処理が行われます。
- どの Entra ID テナントからアクセスされているかの判定
- そのテナントに対する アプリケーションの登録・同意（ユーザー同意／管理者同意）
- テナント ID とサブスクリプション ID の紐づけ
- 初回ユーザーのロール（管理者、通常ユーザーなど）の付与
これらはすべて Entra ID テナント上の操作であり、個人用 MSA ではテナント情報を持たないため処理を続行できません。その結果、MSA でサインインしようとすると、サインイン拒否や「組織アカウントを使用してください」といったメッセージが表示され、構成が進まなくなります。
最短で解決するための具体的な手順
ここからは、実際に「Pending configuration」状態を解消し、SaaS を利用可能にするまでの 最短ルートとなる手順を順番に解説します。
手順 1：正しいテナントの職場/学校アカウントでサインインする
まず最初に確認すべきなのは、どの Entra ID テナントで Marketplace 購入を行ったかです。Azure ポータル右上のアカウントアイコンから、現在選択されているディレクトリを確認し、必要であれば 「ディレクトリの切り替え」を行います。
- Azure ポータル右上のユーザーアイコンをクリック
- 「ディレクトリ＋サブスクリプション」（または「ディレクトリの切り替え」）を選択
- Marketplace 購入を行ったディレクトリ（テナント）を選択
そのうえで、同じテナントに属する職場/学校アカウント（例：[email protected] や [email protected]）でサインインし直し、「構成」リンクを開きます。
ポイントは、「Azure にサインインできるアカウント」ではなく、「そのサブスクリプションの属するテナントに存在するアカウント」であることです。同じブラウザに複数アカウントをサインインさせている場合、無意識に別アカウントで開いているケースも多いので注意してください。
手順 2：必要な同意（コンセント）を実施する
ランディングページに到達すると、SaaS によっては Microsoft Entra ID のアプリケーション同意画面が表示されます。ここで必要なのは、オファーによって次のどちらかになります。
| 同意の種類 | 誰が実施できるか | よくある表示 |
|---|---|---|
| ユーザー同意のみでよい場合 | そのテナントの通常ユーザー | アプリが要求するアクセス許可を確認して「承諾」 |
| 管理者同意が必要な場合 | 全体管理者 / クラウド アプリケーション管理者 など | 「このアプリは管理者の承認が必要です」などのメッセージ |
もし「管理者による承認が必要」と表示された場合は、全体管理者（Global Administrator）、あるいは クラウド アプリケーション管理者などの管理ロールを持つアカウントで再度ランディングページにアクセスし、「組織を代表して同意する」オプションを選択して承認を完了させます。
手順 3：テナントとサブスクリプションを正しく合わせる
Azure では、「今どのディレクトリ（テナント）を見ているか」と、「どのサブスクリプションが選択されているか」が非常に重要です。Marketplace の SaaS 構成も例外ではありません。
構成を行う前に、次の点をチェックしましょう。
- Azure ポータル上部の「ディレクトリ＋サブスクリプション」で、対象サブスクリプションが選択されているか
- 構成対象の SaaS オファーが、そのサブスクリプションに紐づいて表示されているか
- ブラウザにサインインしているアカウントが、そのディレクトリに存在するユーザーになっているか
別テナントが選ばれていると、「構成」リンクから遷移したときに 想定とは異なるテナントでサインインされてしまい、最終的に 構成が完了しない or エラーになる原因になります。
手順 4：ブラウザ環境をクリーンにする（シークレット/プライベートウィンドウの活用）
ブラウザには、過去のサインイン情報やクッキー、セッション情報が残っており、意図せず個人アカウント（MSA）で認証されてしまうことがあります。特に、同一ブラウザで個人用・組織用を切り替えて利用している方は要注意です。
対策として、構成時には次のような方法を推奨します。
- プライベート / シークレットウィンドウを開き、そこから Azure ポータルにアクセスする
- 個人アカウントではなく、目的のテナントの職場/学校アカウントで新規サインインする
- その状態で Marketplace の SaaS 一覧から「構成」リンクをクリックする
これにより、MSA での自動サインインを回避し、常に正しいアカウントで構成ページに到達できるようになります。
手順 5：再度「構成」リンクからプロビジョニング完了まで実行する
ここまでの準備が整ったら、改めて Azure ポータルから対象の SaaS サブスクリプションを開き、「構成」リンクをクリックします。正しいテナントとアカウントでアクセスしていれば、
- ベンダーのサインアップ／初期設定フォーム
- アプリの利用開始に必要な情報（組織名、連絡先、初期管理者など）の入力
- Entra ID へのアプリ登録・同意の完了
といったステップが正常に進み、完了後しばらくするとステータスが 「Subscribed（有効）」、あるいは同等の状態に変わるはずです。
この時点で、SaaS 側の管理ポータルやアプリケーションにサインインできるようになっていれば、構成は成功です。
発行元（SaaS ベンダー）側で確認すべきポイント
上記の手順を踏んでも構成が進まない場合、発行元（SaaS ベンダー）の仕様や制限が影響している可能性があります。問い合わせる際には、次の観点を確認するとスムーズです。
MSA が許可されているオファーかどうか
SaaS ベンダーによっては、ランディングページ側で MSA を明示的にブロックしていることがあります。その場合、仕様上 MSA での構成は不可能であり、必ず職場/学校アカウント（Entra ID アカウント）を使用する必要があります。
ベンダーに確認すべき代表的なポイントは次の通りです。
- Marketplace 経由の構成に MSA をサポートしているか
- もしサポートしていない場合、Entra ID テナントのユーザーで構成することが前提か
必要な同意の種類と要求されるロール
もう一つの重要なポイントは、どのレベルの同意が必要かです。特に、テナント全体へのアクセス権を要求するタイプの SaaS アプリでは、ほぼ確実に 管理者同意（admin consent）が必要になります。
| 必要な同意レベル | 典型的な要求 | 必要なロール |
|---|---|---|
| ユーザー同意でOK | ユーザー自身の情報へのアクセスのみ | 特になし（通常ユーザーで可） |
| 管理者同意が必須 | ディレクトリ全体のユーザー情報の読み取りなど | 全体管理者 (Global Administrator) 特定のアプリ管理ロール（クラウド アプリケーション管理者 など） |
問い合わせ時には、「この SaaS を構成するには、Entra ID 側でどのロールを持つユーザーが同意すべきか」を確認しておくと、社内の管理者への依頼もスムーズになります。
MSA で従量課金を開始してしまった場合の具体的な対処
ここからは、多くの方がつまずくケース、すなわち 「従量課金の Azure サブスクリプションを MSA で開始してしまった」場合の現実的な対処方法を詳しく見ていきます。
重要なポイントは、MSA で Pay-As-You-Go を作成したとしても、その裏には必ず Entra ID テナントが存在しているという点です。このテナント内に、構成に利用できる職場/学校アカウントを作成することで、SaaS の構成を完了できます。
ステップ 1：関連付いている Entra ID テナントを特定する
まず、MSA のサブスクリプションがどの Entra ID テナントに紐づいているかを確認します。
- Azure ポータルに MSA でサインイン
- 左メニューから「Microsoft Entra ID」または「Azure Active Directory」を開く
- 「概要」画面で表示されるテナント名やテナント ID を確認
通常、<任意の名前>.onmicrosoft.com 形式の初期ドメインが用意されています。このテナントが、あなたのサブスクリプションのひも付き先です。
ステップ 2：テナント内に職場/学校アカウントを作成する
次に、そのテナント内に構成用のユーザーを作成します。例として、次のようなユーザーを作ると分かりやすいでしょう。
- ユーザー名：
marketplace-admin@<tenant>.onmicrosoft.com - 用途：Marketplace SaaS の構成専用アカウント
ユーザー作成後、このアカウントで Azure ポータルにサインインできることを確認します。初回サインイン時にはパスワード変更が求められることが多いため、その場で新しいパスワードを設定しておきます。
ステップ 3：必要な管理ロールを一時的に付与する
構成対象の SaaS によっては、管理者同意が必須となる場合があります。その場合、上記で作成したアカウントに、次のいずれかのロールを一時的に付与します。
- 全体管理者 (Global Administrator)
- クラウド アプリケーション管理者 (Cloud Application Administrator)
- アプリケーション管理者 (Application Administrator)
ロールの付与は、「Microsoft Entra ID」→「ロールと管理者」から対象ロールを開き、「メンバーを追加」でユーザーを追加することで行えます。
セキュリティの観点から、構成作業が完了したら不要な管理ロールは必ず外すことを推奨します。構成専用アカウントは「特権を一時的に付与して作業後に戻す」という運用が安全です。
ステップ 4：構成用ユーザーで「構成」リンクを踏み、プロビジョニングを完了させる
ここまで準備できたら、構成用ユーザーで Azure ポータルにサインインし直し、対象の SaaS サブスクリプションの「構成」リンクをクリックします。
- 「ディレクトリ＋サブスクリプション」フィルターで対象サブスクリプションを選択
- SaaS の状態が「Pending configuration」になっていることを確認
- 「構成」リンクをクリックし、ランディングページで必要情報を入力
- 要求されるアクセス許可・同意内容を確認して承諾
正常に完了すると、しばらくしてサブスクリプション状態が 「有効」 へと変わり、SaaS 側ポータルへのアクセスも可能になります。
ステップ 5：不要になった権限を戻す
構成が完了したら、忘れずに 構成用ユーザーから不要な管理ロールを削除します。これにより、最小権限の原則を守りつつ、必要な作業だけを安全に実施できます。
よくあるつまずきポイントとチェックリスト
ここまでの内容を踏まえつつ、実際の現場で多い「つまずきポイント」をチェックリスト形式で整理します。構成がうまく進まない場合は、以下を一つずつ確認してみてください。
| チェック項目 | 確認内容 |
|---|---|
| アカウントの種類 | MSA（個人アカウント）でなく、Entra ID の職場/学校アカウントで構成しているか |
| ディレクトリ | Azure ポータル右上の「ディレクトリ＋サブスクリプション」で、購入したテナントが選択されているか |
| サブスクリプション | 対象の SaaS が表示されている サブスクリプションが選択されているか |
| ブラウザセッション | MSA で自動サインインされていないか。シークレットウィンドウで試したか |
| 同意レベル | ユーザー同意で足りるのか、それとも 管理者同意が必須なオファーなのかを確認したか |
| 管理ロール | 管理者同意が必要な場合、適切な管理ロール（全体管理者など）が付与されたユーザーでアクセスしているか |
| ベンダー仕様 | 発行元の仕様として MSA を許可していないオファーではないかを確認したか |
これらを順番に潰していくだけでも、多くの「Pending configuration」トラブルは解消できます。
どうしても進めない場合の最終手段
上記のすべてを試しても構成が進まない場合、次のような最終手段を検討します。
最終手段 1：未構成のうちにキャンセルして再購入する
一部の SaaS オファーでは、「Pending configuration」の状態のままキャンセルが可能なものがあります。この場合、問題のある購入は一度キャンセルし、最初から正しいテナント・正しいアカウントで再購入するのが最もシンプルです。
再購入時のポイントは次の通りです。
- 最初に Azure ポータルで 正しいディレクトリ＋サブスクリプションを選択しておく
- 個人アカウントではなく、組織の職場/学校アカウントでサインインした状態で Marketplace を開く
- 購入後すぐに「構成」を実行し、構成待ち状態を長期間放置しない
最終手段 2：発行元サポートにサブスクリプション情報を伝えて相談する
キャンセルができない、あるいはすでに課金が発生している場合は、SaaS ベンダーのサポート窓口に問い合わせることになります。その際には、次の情報を伝えると話がスムーズです。
- Azure サブスクリプション ID
- テナント ID（Directory ID）
- 購入した SaaS オファー名・プラン名
- 現在の状態（Pending configuration のまま、構成画面でエラーが出る など）
ベンダーによっては、これらの情報をもとに 手動でテナントとサブスクリプションを紐づけてくれたり、構成に利用するアカウントを別のテナントへ切り替えるための手順を案内してくれる場合もあります。
運用で同じトラブルを繰り返さないためのベストプラクティス
最後に、今後同じような「構成待ち」トラブルを避けるための 運用上のベストプラクティスをまとめます。特に、複数のテナントや複数のアカウントを使い分ける環境では、あらかじめルールを決めておくことが重要です。
ブラウザごとに「個人用」と「組織用」を分ける
もっとも簡単にできる対策は、ブラウザごと・プロファイルごとに利用目的を分けることです。
- ブラウザ A：個人用（MSA, 個人の Gmail など）専用
- ブラウザ B：仕事用（Entra ID アカウント、Azure、Microsoft 365）専用
- 構成作業時は必ず「仕事用ブラウザ」で行う
これだけでも、「つい MSA でサインインしてしまった」というヒューマンエラーをかなり減らせます。
Marketplace 購入用・構成用のアカウントをあらかじめ決めておく
組織で Marketplace を多用する場合は、あらかじめ次のようなルールを決めておくと安心です。
- Marketplace で SaaS を購入できるアカウントを 特定の職場/学校アカウントに限定する
- そのアカウントは、必要に応じて管理者同意が行えるロールを持たせておく
- 構成に必要な情報（テナント ID、サブスクリプション ID、初期管理者アカウントなど）を社内 Wiki などに記録
これにより、「誰がどのアカウントでどの SaaS を購入したのか」が明確になり、トラブル時の切り分けも容易になります。
「構成待ち」の状態を放置しない
Azure Marketplace では、購入後すぐに構成を行わず放置すると、どのアカウントで購入したのか忘れてしまい、今回のような混乱を招きやすくなります。ベストプラクティスとしては、
- Marketplace での購入後、その日のうちに構成を完了させる
- どうしても時間が取れない場合は、購入時のアカウント・テナント・サブスクリプションをメモしておく
といった運用を心がけましょう。
まとめ：Azure Marketplace の「Pending configuration」はテナントとアカウントの整理でほぼ解決できる
Azure Marketplace の SaaS がいつまでも 「Pending configuration（構成待ち）」のまま進まない場合、その多くは MSA と Entra ID の違い、および どのテナント・どのアカウントで購入・構成しているかが原因です。
本記事で紹介したポイントを押さえておけば、
- MSA ではなく、Entra ID の職場/学校アカウントで構成を行う
- Azure ポータルの 「ディレクトリ＋サブスクリプション」フィルターを正しく合わせる
- 必要であれば 管理者同意が行えるロールを一時的に付与して構成する
- どうしてもだめな場合は キャンセル再購入または 発行元サポートへの相談を行う
といった形で、確実に「構成待ち」状態から脱出できるはずです。Azure Marketplace を活用して SaaS を導入する際には、アカウント種別とテナントの関係をしっかり意識し、スムーズなプロビジョニングにつなげていきましょう。
コメント