Microsoft 365（Exchange Online）で別テナントと双方向の予定表共有（Free/Busy 参照）を構成したのに、PowerShell の Test-OrganizationRelationship で「Object reference not set to an instance of an object」が出て検証できない――この症状は、設定そのものが壊れているというより「必須の接続先 URL が空のまま保存されている」ことが原因になりがちです。本記事では、原因の切り分けから、最短で復旧できる作り直し手順までを具体的にまとめます。
現象：Test-OrganizationRelationship で .NET の NullReference エラーが出る
2 つの Microsoft 365 テナント間で Organization Relationship（組織間の予定表共有など）を双方向で構成しようとすると、次のような状態に遭遇することがあります。
- 両テナントで関係（Organization Relationship）と共有対象ドメインを設定した
- Exchange 管理センター（EAC）の画面から関係を作成しようとすると「error executing cmdlet」と表示される
- PowerShell の
New-OrganizationRelationship自体はエラーにならない - しかし
Test-OrganizationRelationshipを実行すると、どちらのテナントでも以下の .NET エラーで失敗する
Object reference not set to an instance of an object
（オブジェクト参照がオブジェクト インスタンスに設定されていません）- 実際に Outlook / Outlook on the web で相手テナントの空き時間（Free/Busy）が取得できない
見た目は「設定ミス」っぽいのですが、コマンドが成功しているのにテストだけ落ちる、しかも .NET 例外（NullReferenceException 相当）で落ちる、というのがポイントです。ここまでそろう場合、まず疑うべきは Organization Relationship の内部に保存される接続先情報の欠落です。
前提：Organization Relationship と予定表共有の関係
Exchange Online でテナント間の予定表情報をやり取りする際、混同されやすい概念がいくつかあります。今回のトラブルを理解するために、まず全体像を整理しておきます。
| 用語 | 何を決めるものか | 今回のトピックとの関係 |
|---|---|---|
| Organization Relationship | 相手組織（ドメイン）に対して Free/Busy などの共有を許可する設定 | 主役。URL 情報が空だとテスト/通信が成立しない |
| Sharing Policy（共有ポリシー） | 個別の予定表共有（ユーザーが外部へ公開する範囲）などに関わる設定 | 要件によっては関連するが、まずは Organization Relationship の正常化が先 |
| EAC（Exchange 管理センター） | GUI で組織間共有を設定できる | 失敗すると「error executing cmdlet」だけになり、原因が見えづらい |
| PowerShell（Exchange Online） | 設定値を確実に投入・確認できる | 今回の回避策（Get-FederationInformation → 作成）が有効 |
Organization Relationship で Free/Busy が動く仕組み
Organization Relationship は、別組織（別テナント）と Exchange レベルで「どのドメインに対して、どの範囲の予定表情報を共有するか」を定義する仕組みです。空き時間（Free/Busy）参照の場合、ざっくり言うと次の流れで通信が成立します。
| 要素 | 役割 | 関係する代表的な設定/値 |
|---|---|---|
| Autodiscover | 相手側の Exchange へ到達するためのエンドポイントを見つける | TargetAutodiscoverEpr |
| EWS（Exchange Web Services） | Free/Busy など予定表の可用性情報を取得する | TargetApplicationUri |
| フェデレーション情報 | 相手組織の “どこに接続すべきか” を取得する | Get-FederationInformation の戻り値 |
| Organization Relationship | 共有の有効化、共有レベル、対象ドメインを定義する | FreeBusyAccessEnabled / FreeBusyAccessLevel / DomainNames など |
ここで重要なのが、TargetAutodiscoverEpr と TargetApplicationUri は「相手組織に接続するための URL 情報」であり、ここが空だと 通信の起点となるオブジェクトが生成できず、テスト時に参照して落ちる、という挙動になり得る点です。
まず確認したい前提条件（最短で切り分ける）
今回のケースでは “URL 情報が空” が原因でしたが、同じように「テストが失敗する」症状を作る要因は他にもあります。作り直す前に、最低限の前提を押さえておくと切り分けが早くなります。
| 確認項目 | ありがちな落とし穴 | 確認の目安 |
|---|---|---|
| 相手側も関係を作成済みか（双方向） | 片側だけ設定して「双方向のはず」と思い込む | 双方向共有なら、両テナントで Organization Relationship を作成 |
Test-OrganizationRelationship の -UserIdentity | ユーザー未指定/存在しないユーザー/メールボックス無し | 自テナント内の実在するメールボックス ユーザーを指定 |
| 対象ドメイン（DomainNames） | 相手のカスタム ドメインではなく onmicrosoft.com を指定して混乱 | 相手のメール アドレス ドメインに合わせる（運用実態に合わせる） |
| 共有レベルの要件 | AvailabilityOnly で「件名も見える」と誤解する | 必要な可視化レベル（最小/一部詳細）を事前に決める |
原因：TargetApplicationUri と TargetAutodiscoverEpr が空
結論から言うと、Organization Relationship の接続先 URL 情報が空のまま保存されていると、Test-OrganizationRelationship が内部参照できず “Object reference not set to an instance of an object” で落ちることがあります。
Get-OrganizationRelationship で現状を見える化する
次のように、対象の Organization Relationship を取得して URL 関連のプロパティを確認します。
Get-OrganizationRelationship |
Format-List Name,DomainNames,FreeBusyAccessEnabled,FreeBusyAccessLevel,TargetApplicationUri,TargetAutodiscoverEprここで TargetApplicationUri と TargetAutodiscoverEpr が空（何も表示されない、または Null）になっていたら、今回のエラーと直結している可能性が高いです。
2 つのプロパティが “空だとダメ” な理由
この 2 つは、名前の通り「相手組織へ到達するための URL（エンドポイント）」を保持します。値が空だと、テスト処理の内部で URL を参照した時点で対象オブジェクトが存在せず、.NET の参照例外として表面化しやすくなります。
| プロパティ | 意味 | 空のときに起きやすいこと | 正常時の値の例（イメージ） |
|---|---|---|---|
TargetAutodiscoverEpr | 相手組織の Autodiscover エンドポイント | 相手側の情報解決に失敗し、テストで参照例外が出る | https://…/autodiscover/autodiscover.svc/WSSecurity など |
TargetApplicationUri | 相手組織のアプリケーション URI（EWS などへの到達に必要） | Free/Busy 取得の呼び出し先が確定できず、テスト/実通信が失敗 | https://outlook.com/… 等（環境により異なる） |
どちらも「値そのもの」を人が手入力で覚える類のものではなく、相手組織のフェデレーション情報から取得して自動で埋めるのが安全です。そこで活躍するのが Get-FederationInformation です。
事前準備：Exchange Online PowerShell で各テナントに接続する
作業は両テナントで実施します。管理者の端末から Exchange Online PowerShell に接続して実行してください（モジュールは事前に導入済みである前提です）。
Connect-ExchangeOnline -UserPrincipalName <管理者UPN>作業が終わったら、セッションを切断しておくと安全です。
Disconnect-ExchangeOnline解決策：Get-FederationInformation を使って関係を作り直す
URL 情報が空になっている場合、最も確実なのは「相手組織のフェデレーション情報を取得し、その結果を使って Organization Relationship を作り直す」方法です。EAC のウィザードが失敗しても、この方法なら必要な値が自動で入り、後から確認もしやすくなります。
Get-FederationInformation で何が取れるのか
Get-FederationInformation は、相手ドメインに対してフェデレーション関連の情報（アプリケーション URI や Autodiscover のエンドポイントなど）を取得します。人が値を推測して埋めるよりも、結果をそのままパイプで渡す方がミスが減ります。
Get-FederationInformation -DomainName <相手テナントのドメイン>作り直しの全体像
| 手順 | 作業 | ポイント |
|---|---|---|
| 現状確認 | Get-OrganizationRelationship で URL が空か確認 | 空ならこの手順で復旧できる可能性が高い |
| 置き換え方針 | 既存を削除するか、別名で作るか決める | 運用中なら “別名で作成→検証→切替” が安全 |
| 作成 | Get-FederationInformation | New-OrganizationRelationship | URL 情報が自動で埋まる |
| 双方向 | 両テナントで同様に作成 | 片側だけでは片方向 |
| テスト | Test-OrganizationRelationship と Outlook で確認 | -UserIdentity は必須と考える |
推奨コマンド例（両テナントで実行）
次のコマンドを、それぞれ「相手テナントのドメイン」を指定して実行します。ポイントは Get-FederationInformation の結果をパイプで New-OrganizationRelationship に渡すことです。
Get-FederationInformation -DomainName <相手テナントのドメイン> |
New-OrganizationRelationship `
-Name "<任意の名前>" `
-FreeBusyAccessEnabled $true `
-FreeBusyAccessLevel <FreeBusy の詳細レベル>これにより、作成された Organization Relationship には次が期待できます。
TargetAutodiscoverEprとTargetApplicationUriに正しい値が自動設定される- Free/Busy 共有が成立するための “最低限の骨格” が整う
- EAC のウィザードよりも再現性が高く、後から設定値を追いやすい
既存の関係を残すか、削除して作り直すか
既存の Organization Relationship を “同名で上書き” はできません。置き換えパターンは主に次の 2 つです。
| パターン | やり方 | 向いている状況 | 注意点 |
|---|---|---|---|
| 別名で新規作成して切替 | 新しい名前で作成 → テスト → 運用側を切替 | 運用中で影響を最小化したい | 古い関係が残るので、最終的に整理が必要 |
| 削除して作り直し | 既存を削除 → 同名で新規作成 | まだ運用開始前、または影響範囲が小さい | 削除中は一時的に共有が途切れる可能性がある |
FreeBusyAccessLevel の選び方
Free/Busy の見え方（どこまで情報を出すか）は、セキュリティ・運用ポリシーに直結します。代表的な値と意味を整理しておきます。
| 値 | 相手に見える内容 | 向いているケース | 注意点 |
|---|---|---|---|
AvailabilityOnly | 空き/予定あり（ビジー）だけ | 外部共有は最小限にしたい | 会議名や場所などは見えない |
LimitedDetails | 件名など一部の詳細を含む | 部署間・グループ会社など、一定の信頼がある | 情報漏えい観点で承認が必要なことが多い |
スレッドやサンプルで $true と書かれている例を見かけることがありますが、-FreeBusyAccessLevel は通常、上記のような列挙値（文字列）を指定します。要件に合わせて選び、必要なら後から Set-OrganizationRelationship で変更します。
作り直したあとに URL が入ったか確認する
作成直後に次で確認し、URL が空でなくなったことを必ずチェックします。
Get-OrganizationRelationship "<OrganizationRelationship名>" |
Format-List Name,DomainNames,FreeBusyAccessEnabled,FreeBusyAccessLevel,TargetApplicationUri,TargetAutodiscoverEprここで 2 つの URL が埋まっていれば、少なくとも「NullReference 的に落ちる状態」は解消している可能性が高いです。
テストの実行方法：Test-OrganizationRelationship の正しい使い方
Organization Relationship を作り直したら、すぐにテストして「PowerShell 上で OK」「クライアントでも OK」の両方を確認します。
推奨実行例
Get-OrganizationRelationship "<OrganizationRelationship名>" |
Test-OrganizationRelationship -UserIdentity <自テナント側のテスト用ユーザー>-UserIdentityには 自テナント内の実在ユーザー（メールボックスを持つユーザー）を指定します。- 相手テナント側のユーザーを指定するのではなく、まずは “自分が問い合わせ元になっている” ことを明確にします。
- エラーが出ないことに加え、結果の詳細（どのフェーズで失敗したか）も控えておくと、追加調査が楽になります。
Outlook / Outlook on the web での実運用テスト
PowerShell で成功しても、実際の利用シーン（Outlook や OWA）で見えないと意味がありません。確認は次の観点で行います。
| 確認ポイント | 具体的な操作 | 期待結果 |
|---|---|---|
| アドレス帳の解決 | 相手テナントユーザーを検索してスケジュール アシスタントへ追加 | 名前解決でき、出席者として追加できる |
| Free/Busy 表示 | 日付を変えながら空き時間を確認 | 「空き」「予定あり」などが表示される |
| 共有レベルの反映 | AvailabilityOnly / LimitedDetails の違いを見る | 設定したレベルに応じた情報量になる |
それでも直らないときの追加チェック
URL 情報が埋まり、Test-OrganizationRelationship も通ったのに、クライアント側で Free/Busy が出ない場合は、次の “周辺設定” を疑います。今回の NullReference とは別レイヤーの問題なので、段階的に潰すのがコツです。
共有対象ドメイン（DomainNames）が運用ドメインと一致しているか
相手側のメール アドレスが [email protected] なのに、Organization Relationship の DomainNames が partner.onmicrosoft.com だけ、という状態だと、意図したユーザーに対して共有が適用されない可能性があります。まずは関係の対象ドメインを確認します。
Get-OrganizationRelationship "<OrganizationRelationship名>" |
Format-List Name,DomainNames必要に応じて Set-OrganizationRelationship でドメインを追加・修正します（運用で使うドメインを優先）。
テストユーザーが “メールボックスを持つ” か
Test-OrganizationRelationship は “問い合わせの主体” となるユーザーのコンテキストを使います。ライセンス未付与、メールボックス未作成、共有メールボックスを誤指定、といったケースでは期待通りに動かないことがあります。まずは Exchange Online 上でメールボックスがあるユーザーを指定してください。
共有レベルと公開範囲の齟齬
Organization Relationship 側で LimitedDetails を指定していても、組織の運用ポリシーやユーザー側の公開範囲が “最小” に固定されていると、見え方が変わることがあります。組織としてどこまで公開するのか（AvailabilityOnly でよいのか、件名まで必要か）を合意し、共有レベルの設計から見直すと手戻りが減ります。
EAC（GUI）で失敗する環境では PowerShell 運用に寄せる
EAC の「組織間共有」ウィザードは便利ですが、環境やタイミングによっては裏側のコマンド実行に失敗して “error executing cmdlet” だけが表示され、原因が追いにくいことがあります。今回のように URL 情報が空のまま残るケースでは、PowerShell で “取得→作成” を明示した方が再現性が高く、監査や引き継ぎにも強い構成になります。
運用のコツ：双方向構成を確実にするチェックリスト
双方向の予定表共有は、片側の作業だけで終わったつもりになりやすい領域です。最後に、運用で使えるチェックリスト形式で要点を整理します。
| チェック | テナント A | テナント B | 備考 |
|---|---|---|---|
| Organization Relationship が存在 | ◯/× | ◯/× | 双方向なら両方が◯ |
| DomainNames に相手の運用ドメイン | ◯/× | ◯/× | 実際のメール アドレス ドメインと合わせる |
| TargetAutodiscoverEpr が空でない | ◯/× | ◯/× | 空なら作り直し候補 |
| TargetApplicationUri が空でない | ◯/× | ◯/× | 空なら作り直し候補 |
| Test-OrganizationRelationship が成功 | ◯/× | ◯/× | -UserIdentity はメールボックス ユーザー |
| Outlook/OWA で Free/Busy が表示 | ◯/× | ◯/× | 実利用の確認が最終ゴール |
よくある質問
New-OrganizationRelationship が成功しているのに、なぜ URL が空になるのですか？
New-OrganizationRelationship を “手入力ベース” で実行すると、共有の論理設定（FreeBusyAccessEnabled や DomainNames）は入っても、相手組織へ到達するための URL 情報が自動補完されない場合があります。その状態で Test-OrganizationRelationship が内部参照すると、オブジェクトが生成できず NullReference 的に落ちることがあります。Get-FederationInformation を使うのは、この “自動補完” を確実に行うためです。
TargetAutodiscoverEpr / TargetApplicationUri を手で埋めてもよいですか？
可能ではありますが、推奨しません。値の形式や、相手側の構成変更（URL 変更）への追従を考えると、Get-FederationInformation で相手の情報を取得して作成する方が安全で、作業の再現性も高くなります。
片方向だけでいい場合もありますか？
あります。例えば「グループ会社の予定表を本社だけが参照する」など、要件として片方向で足りるケースです。その場合でも、運用で混乱しないように “どちらが参照する側か” を明確にし、Organization Relationship の命名にも方向性（例：To-Partner / From-Partner）を含めるとトラブルが減ります。
まとめ：NullReference の正体は “空の URL プロパティ” を疑う
Test-OrganizationRelationshipの「Object reference not set to an instance of an object」は、Organization Relationship 内の必須値が欠落しているときに起き得る- 特に
TargetApplicationUri/TargetAutodiscoverEprが空だと、テスト時に内部参照ができず失敗しやすい Get-FederationInformation -DomainName … | New-OrganizationRelationship …で作り直すと、URL 情報が自動で入り、テスト成功・Free/Busy 復旧につながる- 設定後は PowerShell のテストだけでなく、Outlook / Outlook on the web で相手の空き時間が見えることまで確認する
コメント