所要時間
20〜40 分(組織全体で SSO を強制する前に、パイロット確認で設定を検証する時間を含む)。
前提条件
このガイドは、Microsoft Entra ID で Enterprise Application の作成と SAML の構成に必要な Application Administrator または Global Administrator 権限を持つ担当者と連携する、AutoRFP.ai 組織の Administrator 向けです。
開始前に、次を用意してください。
AutoRFP の Administrator 権限。
Microsoft Entra ID の Application Administrator または Global Administrator 権限(または同等)— Enterprise Application の作成と SAML シングルサインオンの構成に十分であること。
組織が使う AutoRFP リージョン(
app.autorfp.ai、us.autorfp.ai、またはeu.autorfp.ai)の把握 — これにより Entra に入力する Reply URL、Entity ID、Relay State が決まります。すべての AutoRFP ユーザーのアカウントメールが、Entra がその人に対してアサートするメールまたは User Principal Name と一致している(または一致させられる)ことの確認。
AutoRFP の管理パネルと Microsoft Entra 管理センターの両方へのアクセス(できれば別々のブラウザタブ)。
‼️ 重要: SSO は組織全体の変更です。強制すると、組織内のすべての AutoRFP ユーザーが Microsoft Entra ID 経由でサインインする必要があり、AutoRFP のパスワードログインは使えなくなります。メール/UPN の不一致は、強制後のログイン失敗で最も多い原因です — 強制する前に突き合わせてください。
📝 用語について: Microsoft Entra ID は以前 Azure Active Directory (Azure AD) と呼ばれていました。一部の Microsoft 画面、エラーメッセージ、古いドキュメントでは旧名称が残っています — Entra ID と Azure AD は同じ製品を指します。
AutoRFP リージョンの値を選ぶ
AutoRFP は 3 つのリージョンで稼働し、それぞれ独自の SAML 接続値セットを持ちます。
誤ったリージョンの値を使うことは、最も多い設定ミスのひとつです。Entra で変更を加える前に、組織がサインインするホスト名(app.autorfp.ai、us.autorfp.ai、または eu.autorfp.ai)を確認してください。
以下のカードに、各リージョンの値を示します。
Reply URL(Assertion Consumer Service、または ACS URL とも呼ばれます)— Entra が SAML レスポンスを送る先のアドレスです。
app.autorfp.ai → https://auth.app.autorfp.ai/__/auth/handler
us.autorfp.ai → https://auth.us.autorfp.ai/__/auth/handler
eu.autorfp.ai → https://auth.eu.autorfp.ai/__/auth/handlerEntity ID(Identifier とも呼ばれます)— AutoRFP が自身を Entra に識別させるための一意の名前です。
app.autorfp.ai → sp:autorfp.ai
us.autorfp.ai → sp:us.autorfp.ai
eu.autorfp.ai → sp:eu.autorfp.aiRelay State — サインイン後にユーザーを戻すページを AutoRFP に伝える任意の値です。
app.autorfp.ai → https://app.autorfp.ai/
us.autorfp.ai → https://us.autorfp.ai/
eu.autorfp.ai → https://eu.autorfp.ai/
📝 このガイドのスクリーンショットについて。 以下の手順は United States リージョン(us.autorfp.ai)で撮影しているため、スクリーンショットには sp:us.autorfp.ai、https://auth.us.autorfp.ai/__/auth/handler、https://us.autorfp.ai/ が表示されます。画面はどのリージョンでも同一です。組織が app.autorfp.ai または eu.autorfp.ai でサインインする場合は、上のカードから自分の行に置き換えてください。
💡 ヒント: AutoRFP の Custom SSO ウィザード(下記パート 1)を開くと、そのワークスペース固有のこれらの値も表示されます。ここにある内容とウィザードの表示が異なる場合は、ウィザードの値を使ってください。
以下のスクリーンショットは user.mail を使用しています。テナントの mail 属性が空、または AutoRFP アカウント上のアドレスと異なる場合は、代わりに user.userprincipalname を使い、email クレームと Name ID の両方を一貫してそれにマップしてください。
ステップバイステップ手順
カスタム SAML SSO の設定は、次の 3 か所にまたがります。AutoRFP の Custom SSO ウィザード、Microsoft Entra 管理センター、および(ユーザー割り当てについては)その両方です。パートの順に進めてください。
パート 1: AutoRFP Custom SSO ウィザードを開始する
組織の Administrator として AutoRFP にサインインします。
Organizational Settings → Integrations に移動します。
SSO セクションで Custom を見つけ、Setup を選択します。
このウィザードは別タブで開いたままにしてください — ウィザードの Step 1 の値を Entra にコピーし、その後 Entra の値をウィザードの Step 2 に貼り付けます。
Organization Settings > Integrations。Microsoft カードではなく Custom カードを使います。
パート 2: Entra で Enterprise Application を作成する
📝 注意: ウィザードのフィールド名は Entra と一致しません。 AutoRFP の Custom SSO ウィザードは「Reply URL」や「Entity ID」とは言いません — 同じ 3 つの値を Single Sign On URL、Audience URI (SP Entity ID)、Default Relay State とラベル付けします。ウィザードから Entra の Basic SAML Configuration へコピーするときは、次のように対応づけます。
- ウィザード Single Sign On URL → Entra Reply URL (Assertion Consumer Service URL)
- ウィザード Audience URI (SP Entity ID) → Entra Identifier (Entity ID)
- ウィザード Default Relay State → Entra Relay State (Optional)
後で Entra 側の Login URL をウィザードに戻す別ステップ(パート 2、ステップ 5)と混同しないでください — 似たラベルを持つ別の値です。
ステップ 1: 非ギャラリー(Non-gallery)アプリケーションを作成する
Microsoft Entra 管理センターを開きます。
Identity → Applications → Enterprise applications に移動します。
New application → Create your own application を選択します。
名前を入力します: 「AutoRFP.ai」。
Integrate any other application you don't find in the gallery (Non-gallery) を選択します。
Create を選択し、アプリケーションが作成されるまで待ちます。
Enterprise apps > New application > Create your own application。Non-gallery オプションを選びます。
ステップ 2: SAML シングルサインオンを有効にする
新しいアプリケーションで Single sign-on を開きます。
SAML を選択します。
新しいアプリケーションで Single sign-on を開き、SAML を選択します。
ステップ 3: Basic SAML Configuration を構成する
Basic SAML Configuration の Edit を選択し、上記の表から自分のリージョンの値を入力します。
Entra フィールド | 値 |
Identifier (Entity ID) | リージョン表の Identifier。例: |
Reply URL (Assertion Consumer Service URL) | リージョン表の Reply URL |
Relay State | リージョン表の Relay State(末尾のスラッシュを含む) |
Sign on URL (optional) | AutoRFP のログイン URL。例: |
US リージョン向けの Identifier、Reply URL、Relay State。自分のリージョンの値に置き換えてから Save します。
Save を選択します。
期待される結果: Basic SAML Configuration パネルを再度開くと、保存した Identifier、Reply URL、Relay State が表示されます。
ステップ 4: Attributes & Claims を構成する
AutoRFP は、各ユーザーについてメール形式のクレームが 1 つアサートされる必要があります。Attributes & Claims で、次のいずれかのクレーム名が送信され、ユーザーのメールまたは UPN にマップされていることを確認してください。
Claim name | 推奨する Entra ソース属性 | メモ |
|
| ユーザーの |
|
| ユーザーが UPN でサインインし、その値が AutoRFP アカウントのメールと一致する場合に使用。 |
📝 確認: email クレームと Name ID の両方は、実際の Entra ↔ AutoRFP 接続でエンドツーエンド検証済みです。以下のスクリーンショットは user.mail を使用しています。テナントの mail 属性が空、または AutoRFP アカウント上のアドレスと異なる場合は、代わりに user.userprincipalname を使い、email クレームと Name ID の両方を一貫してそれにマップしてください。
‼️ 重要: メールの一致。 Entra がアサートする値は、ユーザーの既存 AutoRFP アカウントのメールアドレスと正確に一致する必要があります(大文字小文字は正規化されますが、ローカル部とドメインは一致必須)。組織の mail アドレスと UPN が一部ユーザーで異なる場合は、AutoRFP と一致するソース属性を選び、全員に一貫してマップしてください — 不一致は強制後のサインイン失敗で最も多い原因です。
email という名前のクレームを追加し、ソースは user.mail にします。Namespace は空白のままにします。
Name ID(ユーザーを一意に識別する SAML 値)を次のように設定します。
Name identifier format: Email address
Source attribute: 上でマップしたのと同じ属性(
user.mailまたはuser.userprincipalname)
Name ID format を Email address にし、ソース属性を user.mail に向けます。
IdP の値を収集する前に、Attributes & Claims はこのようになっているはずです。
ステップ 5: Entra の IdP 値を収集する
SAML 設定ページのまま、次の 3 つの値をコピーします — パート 4 で AutoRFP のウィザードに貼り付けます。
AutoRFP フィールド | Entra での確認場所 |
Single Sign-On URL | 「Set up <App Name>」の下に表示される Login URL(Identity Provider SSO URL とも呼ばれます) |
Entity ID / Identity Provider Issuer | Microsoft Entra Identifier |
Certificate | SAML Certificates で、Certificate (Base64) の横の Download を選択します。 |
セクション 3 から Certificate (Base64) をダウンロードし、セクション 4 から Login URL と Microsoft Entra Identifier をコピーします。
パート 3: Entra でユーザーを割り当てる
接続を検証する前に、少なくとも自分自身を Enterprise Application に割り当ててください。Entra は割り当てられたユーザーだけが SAML サインインを完了できます。
Enterprise Application で Users and groups を開きます。
Add user/group を選択し、パイロットユーザーを選んで Assign を選択します。
Users and groups > Add user/group。検証前に自分を割り当ててください。割り当てないとテストサインインは失敗します。
期待される結果: パイロットユーザーがアプリケーションの Users and groups 一覧に表示されます。
📝 注意: Enterprise Application に割り当てられていないユーザーは、メールが完全に一致していても、SSO を強制すると SAML サインインを完了できません。強制後にサインインできないと報告された場合は、まず割り当てを確認し、次にメールの一致を確認してください。
パート 4: AutoRFP ウィザードを完了する — IdP 詳細の入力と Verify
AutoRFP Custom SSO ウィザードの Step 2 に戻ります。
Entra から収集した 3 つの値を貼り付けます。
Single Sign-On URL — Entra の Login URL から
Entity ID — Entra の Microsoft Entra Identifier から
Certificate — PEM 形式の署名証明書
Verify を選択します。AutoRFP が接続テスト用に Microsoft のサインインポップアップを開きます。
自分の AutoRFP 管理者アカウントのメールと一致し、かつアプリケーションに割り当てられている Entra アカウントでサインインします。
Entra から 3 つの値を貼り付け、Verify を選択します。証明書は BEGIN / END 行を残したままにしてください。
‼️ 重要: ポップアップブロッカー。 Verify ステップは Microsoft のサインインポップアップウィンドウに依存します。ブラウザや拡張機能が AutoRFP のポップアップをブロックしていると、エラーが出るか、Verify を選択しても何も起きないように見えることがあります。AutoRFP リージョンのドメインでポップアップを許可して再試行してください。
期待される結果: ポップアップでサインインすると、ウィザードが成功状態を表示し、Enforce ステップに進みます。
Verify が失敗する場合、最も多い原因は次のとおりです。
Entra に入力した Reply URL / Entity ID が誤った AutoRFP リージョンのもの。
証明書に PEM の
-----BEGIN CERTIFICATE-----/-----END CERTIFICATE-----ラッパーがない。サインインした Entra アカウントが Enterprise Application に割り当てられていない。
Entra がアサートするメールまたは UPN が、サインイン中ユーザーの AutoRFP アカウントメールと一致しない。
強制する前にこれらを修正してください。
パート 5: ユーザーを確認して SSO を強制する
Enforce SSO に進みます。ウィザードが表示する AutoRFP ユーザーの表を確認します。
一覧の各ユーザーが Entra の Enterprise Application に割り当てられていることを確認します — 照合しやすい場合はウィザードから CSV としてエクスポートできます。
サインインが Microsoft に移行し、強制後は AutoRFP パスワードが使えなくなることを、事前に組織へ通知します。
Enforce SSO を選択して確認します。
サインアウトされます。Entra 経由で再度サインインし、SSO がエンドツーエンドで動作することを確認します。
強制する前に、一覧の全ユーザーが Entra に割り当てられているか確認します。CSV としてエクスポートして IT チームと照合できます。
期待される結果: サインアウトされ、再度サインインすると AutoRFP のパスワード欄ではなく Microsoft へリダイレクトされます。これで強制が成功したことが確認できます。
‼️ 事前にユーザーへ通知してください。 SSO 強制後のサポート依頼で最も多いのは、ワンタイムのパスワード入力(下記参照)や Microsoft へのリダイレクトに驚いたユーザーからです。強制前の短い事前案内で、ほとんどを防げます。
強制後にユーザー側で変わること
次の表は、Microsoft Entra ID によるカスタム SAML SSO を強制したあとに、AutoRFP ユーザー側で何が変わるかを説明します。
観点 | 強制後 |
サインイン | ユーザーは AutoRFP のサインイン画面で仕事用メールを入力し、認証のため Microsoft にリダイレクトされます。 |
パスワード | サインインに AutoRFP パスワードは使われません。アクセスは Entra ディレクトリと、そこで設定した Conditional Access / MFA ポリシーによって管理されます。 |
強制後の初回サインイン | 以前 AutoRFP パスワードでサインインしていたユーザーは、アカウントを SSO に移行するために、その AutoRFP パスワードを最後にもう一度だけ入力するよう求められることがあります。これは想定どおりで、一度だけ発生します。 |
入退社(Joiners / leavers) | Entra の Enterprise Application へのユーザーの割り当て/削除でアクセスを制御します。SCIM でさらに自動化できます — Microsoft Entra ID で SCIM 2.0 プロビジョニングを有効にする方法 を参照してください。 |
SSO の無効化 | 管理者は AutoRFP の Integrations 設定から SSO をオフに戻せます。パスワードによるサインインは復帰しますが、有効期間中に SSO でサインインしたユーザーは、パスワードで再度サインインするためにパスワードのリセットが必要です。 |
推奨ロールアウト
上記パート 2〜4 の Entra と AutoRFP の構成を完了し Verify に合格したうえで、静かなパイロットを先にしたい場合は Enforce を保留します。
Entra がアサートするメールまたは UPN と一致するよう、AutoRFP ユーザーアカウントのメールを突き合わせます。
Entra で小さな割り当てグループでパイロットします — 少なくとも管理者 1 名と一般ユーザー 1 名を含めます。
切り替え日と想定される変化を全ユーザーに通知します(上記「強制後にユーザー側で変わること」を参照)。
残りのユーザーまたはグループを Entra に割り当て、AutoRFP で Enforce SSO を選択します。
Microsoft Entra ID 固有の機能: IdP 開始アクセスと My Apps
Microsoft Entra ID では、ユーザーが My Apps ポータル(myapps.microsoft.com)や Microsoft 365 アプリランチャーからアプリケーションを起動できます。大半の SAML アプリケーションでは、My Apps のタイルをクリックすると、Entra が IdP 開始(IdP-initiated) の SAML レスポンスを生成してアプリケーションへ直接送ります — 通常のフロー(アプリケーション=「サービスプロバイダー」、または SP が先に要求する)とは異なり、アプリケーション側から求められていないレスポンスです。
AutoRFP のカスタム SAML 接続は サービスプロバイダー開始のみです。毎回のサインインを自分側から開始することを想定しており、未承諾の IdP 開始 SAML レスポンスは受け付けません。そのため、SAML モードの Enterprise Application のデフォルト My Apps タイル動作は AutoRFP では機能しません — クリックするとサインインではなくエラーになるのが想定どおりです。
My Apps から使えるショートカットを用意するには、SAML アプリ本体のタイルに頼らず、Entra の Linked シングルサインオンモードを使います。
強制後、AutoRFP の Custom SSO 設定を開き、ブックマーク形式のサインイン URL(形式:
https://<your-region-host>/login?idp=<your-saml-provider-id>)をコピーします。Microsoft Entra 管理センターで Enterprise applications → New application → Create your own application(または既存のエントリを再利用)に進み、Single sign-on で SAML ではなく Linked を選択します。
コピーしたブックマーク URL をサインオンページとして入力します。
Save を選択し、SAML アプリケーションに割り当てたのと同じユーザーまたはグループを割り当てます。
期待される結果: ユーザーは My Apps に動作する AutoRFP タイルを見ます。クリックするとブックマーク URL が開き、AutoRFP 自身の(サービスプロバイダー開始)サインインフローが始まり、通常どおり Entra へリダイレクトされます — 機能的にはブックマークやお気に入りと同じ体験で、Entra 経由の真のフェデレーション SSO ではありませんが、正しい開始点にユーザーを導けます。
Linked モード自体は認証を行いません — Microsoft のドキュメントでは署名オン機能ではなく「リンクの追加」と説明されています — 実際の認証は、パート 2 で構成した SAML Enterprise Application 経由で行われます。
🛠️ トラブルシューティング
Microsoft Entra ID と AutoRFP で管理者がよく遭遇する SAML の問題と、それぞれの対処です。SCIM 固有の問題は Entra SCIM ガイド のトラブルシューティングを参照してください。
Verify のポップアップが失敗する/何も起きない
ポップアップブロッカーが Microsoft のサインインウィンドウを妨げています。AutoRFP リージョンのドメインでポップアップを許可して再試行してください。
Verify のポップアップは開くがすぐに失敗する
サインインした Entra アカウントが Enterprise Application に割り当てられていないか、Entra に入力した Reply URL / Entity ID が誤った AutoRFP リージョンのものです。
AutoRFP が証明書を拒否する
証明書テキストに -----BEGIN CERTIFICATE----- / -----END CERTIFICATE----- ラッパーがないか、誤った証明書ダウンロードオプションを使っています。
Entra では認証成功だが AutoRFP がユーザーを拒否する
Entra がアサートしたメールまたは UPN が、ユーザーの AutoRFP アカウントメールと一致していません。クレームマッピング(パート 2、ステップ 4)を揃えて再試行してください。
一部のユーザーだけサインインできる
ほぼ常に、対象ユーザーのメール/UPN 不一致か、そのユーザーが Enterprise Application に割り当てられていません。
強制後、ユーザーが一度だけ AutoRFP パスワードを求められる
想定どおりです。以前パスワードでサインインしていたユーザー向けのワンタイム移行プロンプトで、再発しません。
Microsoft My Apps のタイルがサインインせずエラーになる
SAML アプリケーションのデフォルト(IdP 開始)タイル動作としては想定どおり — AutoRFP はサービスプロバイダー開始のサインインが必要です。AutoRFP のブックマーク URL、または Linked モードの My Apps エントリを使ってください(上記「Microsoft Entra ID 固有の機能」を参照)。
誤った Microsoft テナント/個人アカウントのエラー
ユーザーが個人用 Microsoft アカウント(MSA)または誤った職場テナントでサインインしています。Enterprise Application が構成されているテナントのワークフォースアカウントでサインインしてもらってください。
強制後に Entra でメールが変わり、サインインできなくなった
AutoRFP のユーザー管理画面では、管理者がアカウントメールを直接編集することは現在できません。確認済みの旧/新メール対応リストを添えて AutoRFP サポート(ライブチャットまたは [email protected])に連絡してください — サポートは、アカウントを作り直したり既存プロジェクトやコンテンツを失ったりせずに、保存されているアカウントメールを更新できます。
💡 ヒントとベストプラクティス
Entra の構成を始める前に、組織が使う AutoRFP リージョン(
app、us、またはeu)を確認し、そのリージョンの Custom SSO ウィザードから Reply URL、Entity ID、Relay State を直接コピーする。SSO を強制する前に(後ではなく)、全ユーザーの AutoRFP アカウントメールを Entra のメール/UPN と突き合わせる。
まず小さなパイロットグループ(少なくとも管理者 1 名・一般ユーザー 1 名を含む)を割り当て、全員への強制前に Verify を完了する。
AutoRFP ウィザードと Entra 管理センターを別タブで開いたままにする(行き来が多い)。
後で SCIM を追加する予定なら、SAML クレームと SCIM の
userNameマッピングの両方で一貫して使う属性(user.mailまたはuser.userprincipalname)を最初に決めておく。
✋🏼 避けるべきよくある間違い
誤った AutoRFP リージョンから Reply URL / Entity ID / Relay State をコピーする。
メール/UPN の不一致を解消する前に SSO を強制する — 強制後サポート依頼の最大原因。
Verify 実行前に、管理者(またはパイロットユーザー)を Enterprise Application に割り当て忘れる。
PEM の
-----BEGIN CERTIFICATE-----/-----END CERTIFICATE-----ヘッダー/フッターなしで証明書を貼り付ける。SAML サインイン用と同じ Enterprise Application で SCIM プロビジョニングを有効にしようとする(代わりに 2 つ目の専用アプリケーションを作成する)。
ユーザー起動に SAML アプリのデフォルト My Apps タイルを頼り、AutoRFP ブックマーク URL 付きの Linked モードエントリを設定しない。
ワンタイムパスワード入力と Microsoft へのリダイレクトについてユーザーへ通知せず、組織全体で SSO を強制する。
関連ガイド
ガイド | リンク |
Microsoft / Google の OAuth ボタンで SSO を有効にする | learn.autorfp.ai/ja/articles/10110112 |
Okta で SAML SSO を構成する(SAML パターン参考) | learn.autorfp.ai/ja/articles/10224813 |
Okta で IdP 開始 SSO を構成する | learn.autorfp.ai/ja/articles/10307781 |
AutoRFP で SCIM を有効にする | learn.autorfp.ai/ja/articles/13262307 |
Microsoft Entra ID で SCIM 2.0 プロビジョニングを有効にする(完全ウォークスルー) | learn.autorfp.ai/ja/articles/13271391 |
SCIM 2.0 テクニカルリファレンス | learn.autorfp.ai/ja/articles/14014019 |
安全性とセキュリティ FAQ | learn.autorfp.ai/ja/articles/8492368 |
お困りのときは
💬 ライブチャット: アプリ内で利用できます — 「human」と入力するとチームに直接つながります。
📚 ラーニングセンター: learn.autorfp.ai/ja











