ソフトマッチとハードマッチの比較

By Mirko Peters · 2026-04-24 · Updated 2026-07-18

Azure AD Connect におけるソフトマッチとハードマッチの違いを比較し、ID の照合方法がハイブリッド同期と重複アカウントにどう影響するかを解説します。

Automatically translated with AI from the original post. Read the English original

Microsoft のハイブリッド環境では、オンプレミスの Active Directory と Azure Active Directory（Azure AD）の間でユーザーの ID を同期し続けることが非常に重要です。従来型のサーバーからクラウドまで、ユーザーを確実に対応付ける仕組みがないと、重複アカウントやサインインの混乱など、さまざまな問題が起こりかねません。

そこで登場するのが「ソフトマッチ」と「ハードマッチ」という考え方です。これらは、Azure AD Connect がオンプレミスのユーザーとクラウドのユーザーをどのように対応付けるかを決める、2 つの異なる方法です。ソフトマッチは、メールアドレスのような身近な属性を使って照合します。一方、ハードマッチは GUID と呼ばれる、より深い技術的な識別子を使い、immutableID という属性で確実性を高めます。

この違いを理解することは、単なる技術的な細部の話ではありません。シームレスなサインイン、円滑な移行、そしてユーザーの業務への影響を避けることに直結します。ハイブリッド環境を滞りなく運用し、意図しない重複や失われたサインインを防ぎたいのであれば、それぞれの方法をいつ、どのように使うべきかを知ることが欠かせません。

Azure のマッチングのソフトとハードの違い：GUID と ImmutableID の方法

オンプレミスの Active Directory を Azure AD に接続するとき、ユーザーのマッチングは単なる技術的な細部ではなく、ハイブリッド ID の土台になります。Azure AD Connect には、ソフトマッチとハードマッチという 2 つの主要な方法があります。それぞれが ID の同期をまったく異なる方法で処理するため、どちらを選ぶかによって、今後の管理のしやすさ、フェイルオーバーへの備え、ユーザー体験のすべてが変わってきます。

ソフトマッチは、ユーザーのメールアドレスのような日常的な属性に頼るため、わかりやすい方法です。一方でハードマッチは、より深く掘り下げた方法を取ります。オンプレミス AD の GUID を使い、Azure AD では immutableID としてエンコードして保持します。これにより、ほぼ壊れないリンクを作成でき、障害後や移行後にアカウントを再接続する必要が生じても切れることがありません。

では、なぜこれが重要なのでしょうか。Azure AD Connect によるユーザーの照合方法は、サインインの流れ、シングルサインオンの一貫性、そしてハイブリッド展開や復旧時にエンドユーザーが影響を感じるかどうかに直結するからです。次の詳細では、それぞれの方法の仕組み、長所、そして IT 担当者が初日から照合を正しく行うことに注力する理由を見ていきます。

Azure ソフトマッチの仕組みとユーザー同期

ソフトマッチは、Azure AD Connect が既存のクラウドユーザーとオンプレミスの Active Directory ユーザーを、共通の属性、主に基本 SMTP アドレス（つまり主要なメールアドレス）と proxyAddresses フィールドの値を比較することで対応付けようとするときに行われます。これらの属性が一致すると、Azure AD は同一人物と認識し、アカウントを自動的にリンクします。

この処理は、初期セットアップ時の管理者にはほとんど意識されません。特に、同期を展開する前に Microsoft 365 でユーザーがすでに作成されている場合はなおさらです。Azure AD Connect は「このオンプレミスのアカウントのメールアドレスは、どれかの Azure AD ユーザーと同じか」と確認します。同じであれば、それがソフトマッチです。特別な構成は不要で、同期サイクルの中でこれらの属性を比較するだけで動作します。

ソフトマッチは設計上柔軟なため、ハイブリッド ID を試験導入する場合や、ユーザーの追加・変更が続く動的な環境では便利です。テスト環境、パイロット導入、初めてハイブリッド ID を導入する小規模な組織では、既定で使われることも多い方法です。immutableID を事前に設定する必要はありません。普段から使っているメールアドレスのフィールドを基に、Azure が自動的に対応付けてくれます。

ただし注意点があります。ソフトマッチに頼る場合、両方の環境で一貫性のあるクリーンなメールアドレスが必要です。不一致、入力ミス、重複したメールアドレスがあると、照合が失敗したりアカウントが分割されたりする原因になります。それでも、多くの新規導入やテスト段階では、大きな手間をかけずに従来の ID とクラウドの ID をつなぐ手軽な手段として、ソフトマッチは有効です。

一貫したアカウントリンクのための GUID と ImmutableID のマッチング方法

ハードマッチはより確実な方法を取ります。この方法では、Azure AD Connect がオンプレミスの Active Directory の objectGUID を「ソースアンカー」として使用します。この値を Base64 でエンコードした immutableID に変換し、Azure AD のオブジェクトに設定します。この immutableID は、ユーザー名を変更したり、パスワードをリセットしたり、ほとんどの種類の移行を行ったりしても変わりません。

実際には、ハード マッチングを設定すると、Azure AD Connect は次の点を確認します。「このオンプレミス ユーザーの objectGUID を変換したものは、既存のクラウド アカウントの immutableID と一致するか」。一致すれば、強固なリンクが形成されます。つまり、移行、障害、変更の際にアカウントの接続が切れても、immutableID を照合するだけで、ハード マッチングによって素早く再リンクできます。

この方式は、本番環境、規模の大きい組織、または最大限の安定性と堅牢な災害復旧が求められる環境で推奨されます。ハード マッチングは、一意で変更されない ID に依存するため、重複アカウント、移行時の予期せぬ問題、時間の経過によるずれを防ぎます。アクセス、コンプライアンス、さらには監査証跡にまで影響が及ぶ可能性がある規制業界やミッション クリティカルな環境では、特に重要です。

ハード マッチングの設定には、ある程度の計画が必要です。各 AD オブジェクトの GUID をエクスポートし、Azure AD に immutableID として設定または同期する必要があります。通常は PowerShell または Azure AD Connect のツールを使用します。ただし、フェイルオーバー、復旧、確実なユーザー リンクを円滑に行えるという長期的なメリットを考えると、信頼性が本当に重要な場面では十分に価値があります。

Azure AD Connect ハイブリッド ID におけるディレクトリ属性の役割

Azure AD Connect は、マッチングを行うためにいくつかの重要なディレクトリ属性に依存しています。まず挙げられるのがソース アンカーです。多くの場合、オンプレミスの Active Directory の objectGUID がこれにあたり、クラウドでは immutableID となります。ソース アンカーは、各ユーザーにとっての社会保障番号のような役割を果たします。一意で変更されず、2 つの環境間で確実に一致させるために不可欠です。

次に、ソフト マッチングを可能にする属性があります。具体的には、userPrincipalName (UPN) と proxyAddresses です。UPN は通常、ユーザーの主要なサインイン名です（例: johndoe@yourdomain.com）。proxyAddresses は、ユーザーが持つすべてのメール エイリアスを保持します。共有メールボックスや、引き続き機能させる必要がある古いアドレスなどが含まれます。Azure AD Connect はこれらのフィールドを相互参照し、クラウドとローカルのユーザー オブジェクトを密接にリンクさせ続けます。

一貫性のあるクリーンな属性値は、ユーザーの重複を防ぎ、すべてのユーザーが期待どおりに個人用のサインイン資格情報とメールボックスへのアクセスを維持できるようにします。一方で、不整合や誤った属性値は同期処理を混乱させ、孤立したアカウントや重複ユーザーを生む原因になります。こうした問題は、大規模な環境では急速に拡大しかねません。

ハード マッチングとソフト マッチングのどちらを使う場合でも、どのディレクトリ属性が重要であり、その理由は何かを理解することが、安定したハイブリッド ID の鍵となります。ソース アンカーとメール アドレスを正しく設定しておけば、ハイブリッドな Microsoft 環境でユーザーをオンボーディング、移行、復旧する際に、後々の多くの手間を省けます。

ソフト マッチングと、ハード マッチング（GUID と immutableID）のための適切なハイブリッド ID の選択

ソフト マッチングとハード マッチングのどちらを選ぶかは、単なる技術的な問題ではなく、ID 管理の全体的な計画を左右します。判断は、現在の環境、ユーザー ディレクトリの成熟度、そしてハイブリッド ID によって組織が何を実現したいかに大きく依存します。

ハイブリッド ID を試験的に導入する段階の組織にとって、ソフト マッチングは分かりやすく、柔軟に対応できる方法です。ユーザー データが変化しやすく、環境がまだ発展途上にある、パイロット、一時的な検証環境、導入初期のハイブリッド プロジェクトに適しています。最小限の設定で柔軟性が得られるため、最初から厳格なガバナンスを求めるのではなく、検証と探索に集中できます。

ただし、本番環境に移行する段階、またはビジネスが信頼性、迅速な災害復旧、厳格なコンプライアンスに依存している場合は、ハード マッチングが標準的な選択肢になります。オンプレミスの objectGUID を immutableID に固定することで、ID の分断や重複のリスクを大幅に減らせます。さらに、大きな変更や誤削除の後でも、自信を持ってユーザーを復元または回復できるようになります。

次の記事では、ソフト マッチングの柔軟な性質が役立つ動的な環境と、セキュアでミッション クリティカルな環境において GUID と immutableID のマッチングが欠かせない理由について詳しく解説します。パイロット プロジェクトを進めている場合でも、数千人のユーザーへの展開を控えている場合でも、適切な選択をすることが、円滑な同期とエンド ユーザーの満足度の土台になります。

新規または動的な環境における Azure AD でのソフト マッチングの利用

ソフト マッチは、ハイブリッド環境が流動的なときに真価を発揮します。ユーザーの追加、削除、再編成が頻繁に行われる新規導入、テスト環境、ステージング環境では、追加の設定をせずにオンプレミスの Active Directory アカウントとクラウドのユーザーを即座に関連付けられます。primary SMTP と proxyAddresses の属性が、事前に ImmutableID を割り当てなくても両者をつなぐ役割を果たします。

この方法は、ハイブリッドに本格的に移行する前に Microsoft 365 をパイロット導入する場合や、概念実証を構築する場合に特に便利です。Azure AD Connect は、両方のディレクトリで共通する値をもとにユーザーを照合することを理解したうえで、素早く試行錯誤できます。ImmutableID を事前に設定する必要はありません。メール関連の属性をそろえるだけで、ほぼ準備完了です。

ただし、この柔軟性には責任が伴います。メール アドレスなどのユーザー属性が頻繁に変わると、不一致が生じる可能性があります。属性の管理が優先課題ではない環境では、ソフト マッチは許容範囲が狭くなります。アカウントの分割や同期時の関連付けの失敗を防ぐため、メール アドレス、UPN、エイリアスを標準化する仕組みを整える必要があります。

ベスト プラクティスは、属性の流れを文書化し、オンプレミスとクラウドのユーザー オブジェクトを定期的に監査し、大きな同期変更の前に不整合を解消することです。こうすることで、重複アカウントや孤立アカウントが生じるリスクを抑えられます。本番移行の際に、そうしたアカウントの原因を追跡する作業は誰も望みません。

本番環境と復旧のための GUID と ImmutableID の照合

ハイブリッド環境を本番モードに移行する時期になったら、ハード マッチ（オンプレミスの objectGUID と Azure AD の immutableID を結び付けること）を行うのが適切です。この方法では、2 つのユーザー オブジェクトの間に永続的な結び付きが生まれます。そのため、アカウントが削除、名前変更、移動されても、混乱や重複を起こさずに再構築や復旧が可能です。

この安定した関連付けは、データの整合性と明確な監査証跡が求められる規制の厳しい業界や、災害復旧と事業継続を重視する組織にとって不可欠です。immutableID を固定することで、ユーザーのアクセス権を維持し、認証の信頼性を確実に保てます。

ID 管理の戦略がセキュリティ、リスクの最小化、インシデント発生時の迅速な復旧を中心とするなら、ハード マッチは最良の方式です。

UPN やプロキシ アドレスの不一致など、ソフト マッチに関する Azure の問題の修正

ソフト マッチは強力ですが、細部に敏感です。同期時によく起きる問題の 1 つは、オンプレミスのユーザーの UPN やプロキシ アドレスが、Azure AD の値と完全に一致しないケースです。わずかな誤字や形式の違いでも、厄介な重複アカウントが生じるだけでなく、最悪の場合はユーザーがサインインできなくなります。

ユーザーがサインインするたびに新しいアカウントが表示される場合や、同期後にメールボックスにアクセスできない場合は、まず primary SMTP と proxyAddresses の属性を確認してください。各ローカル AD ユーザーの primary メール アドレスが、大文字と小文字の違いやドメイン サフィックス（.com と .org など）も含めて、クラウド上の値と一致しているか確認してください。

UPN が一致しない場合は、オンプレミスの userPrincipalName 属性を、ユーザーの Azure AD サインイン名に合わせて更新します。場合によっては、Azure で検証済みのドメインに合わせて、ローカル AD の UPN サフィックスを変更する必要があります。属性をそろえたら、同期を実行してアカウントを重複させずに統合します。

先回りして対応することが重要です。特に、ユーザーをまとめて追加する場合や大規模なドメイン変更の後は、ツールや PowerShell スクリプトを使って、ディレクトリの不整合を定期的に監査してください。同期の前に不一致を見つければ、後の大きな手戻りやユーザーの混乱を大幅に減らせます。経験を積めば、こうした修正作業も容易になり、悪夢のような作業も落ち着いて対応できるようになります。

Active Directory の監視と Microsoft 365 コンサルタント向けの参考資料

• Active Directory 監視の設定: 実績のある Active Directory 監視ソリューションを使用して、同期の正常性を追跡し、重複オブジェクトを検出し、ユーザーに影響が出る前に同期エラーを発見してください。プロアクティブな監視により、ハイブリッド ID システムの堅牢性を保ち、トラブルシューティングも容易になります。アクティブ監視の詳細は、こちらの専用リソースをご覧ください。
• Azure AD Connect の診断を活用する: Azure AD Connect に組み込まれている正常性レポートを活用しましょう。これらのツールは、同期エラー、属性の競合、リスクのある変更を明らかにします。定期的に確認することで、ユーザーに影響が出る前に問題を見つけ、サインインを安定して維持できます。
• 専門家のブログとコミュニティガイドを参照する: 最新情報を追い続けることは非常に重要です。itpromentor のような ID 管理の主要ブログや、Microsoft 365 コンサルタント向けの詳細なガイドをフォローしましょう。これらの情報源では、実際の現場で役立つヒント、トラブルシューティングの手順、ID ガバナンスに関する新しい視点が提供されており、複雑な環境から得られた教訓に基づくものが多くあります。
• カテゴリ、タグ、アーカイブを確認する: 継続的に学ぶために、ブログのカテゴリを閲覧したり、タグを使って関心のある内容を絞り込んだり、アーカイブから機能、ベストプラクティス、新しいリリースノートの更新情報を探したりしましょう。
• 学習を継続する: ハイブリッド ID は、一度設定すれば終わりという作業ではありません。最新の記事、ウェビナー、ナレッジベースを活用して、新しい同期機能、属性処理の変更、セキュリティに関する推奨事項を把握しておきましょう。十分な知識を持つ管理者は、問題が発生する前にその多くを防ぐことができます。

アクティブな監視、定期的な知識のアップデート、適切なコミュニティとのつながりを組み合わせることで、ハイブリッド環境を健全に保ち、どのような ID の課題にも備えることができます。

併せて聴きたいエピソード

ソフトマッチとハードマッチについて調べている場合は、以下のエピソードが ID、コラボレーション、ガバナンス、安全な AI 導入について実践的な背景を補足してくれます。

• Conditional Access – Simply Explained — ID、デバイス、場所、リスクのシグナルがアクセスの判断にどのように影響するかを理解できます。
• Microsoft AI Agent Harness – Simply Explained — AI による自動化をより信頼性が高く、可観測性のあるものにする制御の仕組みを解説します。
• Microsoft Teams Governance – Simply Explained — 所有者とライフサイクルのルールが、コラボレーションを持続可能に保つ仕組みを学べます。
• Microsoft Purview – Simply Explained — 分類、保持、コンプライアンスを通じて、コラボレーションと ID を結び付けます。

これらのエピソードは、技術的なトピックを、導入とガバナンスに関する実践的な判断へとつなげる助けになります。