先日の投稿で、Office365がWindows Azure Active Directoryサービスをバックボーンとして利用しているという話をいたしました。
プレビュー版ですが、管理画面に入れるようになっているので早速確認してみました。アクセス先は以下のアドレスです。Office365にアクセスしてから開くか、直接Office365で利用しているID、PASSを入力してログオンするかです。
https://activedirectory.windowsazure.com/
各サービス毎の見た目は以下の通りになります。Windows Azure Active Directoryが根幹にあって、そこから契約している各サービス・機能へのリンクが張られている感じですね。
プランP1のテナント
プランE3のテナント
(新)Office365 Enterpruseテクニカルプレビュー
9月に入って、ディレクトリ同期ツールからのメールが少し変わりました。とはいえ、内容自体に変わりは無く、送り元の署名が「Microsoft Online Servicesチーム」から「Windows Azure Active Directoryチーム」に変わりました。
特にサービスとしても差は無いように見えますので、Office365で利用していた基盤を共通化してWindows Azure Active Directoryというサービス名称で切り出したということでしょうか。
（前）
（後）
ちなみに、このチームからのメールは、
などに送信されてきます。オブジェクトの重複チェックで引っかかって更新できなかった場合など、障害内容の特定に非常に役に立つ内容になってますので、会社の設定の欄の技術担当者の電子メールアドレスは、随時受け取りが可能なアドレスをちゃんと記載しておくと良いかと思います。
Office365では、オンプレミスのActive Directory同様、デフォルトで「有効期限：90日」のパスワード有効期限のポリシーが定められており、当初はこちらを変更することはできませんでした。（このポリシーに合わない場合は、「無期限にする」という選択肢しかありませんでした。）
また、Outlookを利用している場合、パスワードの期限切れが近づいた場合にユーザーにそれを通知する機能がありましたが、こちらの通知期間もデフォルトで14日前からとカスタマイズはできない固定値でした。 【参照】Outlook パスワードの有効期限切れ通知
この夏（8月頃）のサービス更新でこちらの両方のパラメータをドメインごとに変更できるように改善されましたので、今回はこちらを紹介します。同じサービスでも、提供期間内にこういった改善事項がどんどん実装されていくというのはクラウドサービスならではですね。
こちらの変更ですが、PowerShellから実行をします。（一時期は管理者ポータルの画面から設定できたように記憶をしているのですが、現時点では確認できませんでした）
Windows PowerShell 用 Microsoft Online Services モジュールをインストールしている環境から、以下のコマンドを実行します。
$LiveCred=Get-Credential Connect-MsolService -Credential $LiveCred Set-MsolPasswordPolicy -NotificationDays xxx -ValidityPeriod yyy -DomainName contoso.onmicrosoft.com Set-MsolPasswordPolicy -NotificationDays xxx -ValidityPeriod yyy -DomainName contoso.com
推察はできるかと思いますが、xxxにパスワード期限切れの事前通知期間を、yyyにパスワードの有効期限を設定します。設定可能な値は、xxx：7（1週間前）～60（2か月前）かつyyy以下 yyy：7（1週間）～1000（約3年間）です。
また、設定はドメインごとに実施をする必要があります。ドメインによってポリシーを変える（例えば関連会社を同一テナントに入れている場合など）ことも可能です。
なお、ここで以前の値より有効期限を短くした場合、このカウントは「そのユーザーが前回パスワードを変更した日」からの日数になりますので、ポリシーを変えた瞬間に期限切れになる可能性がございます。Webからのアクセスであればパスワード変更画面に飛ばされるのでさほど問題はないですが、POP/IMAPやActiveSyncなどは突然接続できなくなるように見えるので、短縮する場合はご注意ください。
昨年の11月頃、こちらの記事で紹介させて頂いた通り、Office365の管理者ポータルのドメインメニューから表示されるDNSレコードの構成要件が変更になりました。
おそらく先月くらいからだと思うのですが、こちらの表示が少し変わったように思えます。
_sip._tlsのSRVレコードの行が復活し、しかも微妙に表示がずれています。これは、プランPの方でも同じ表示になっています。
最近は特に_sip._tlsのレコードは明示的に追加はしていないのですが、もし問題が発生したら追加してみようと思います。
(9/5追加)
コミュニティで回答がありました。Lync AttendeeクライアントがSIPのAレコードは認識せずにSRVレコードのみ対応しているため、それ用に必要なレコードだそうです。
なるほど、そういえば微妙にLyncとLync Attendeeの挙動が違う環境があると思ってましたが、AttendeeはSRVレコードのみ（＝Proxy非対応でIEの設定の影響を受けない）なのですね。
9/22に実施される.NETラボさんの勉強会に、MVP for Directory Servicesである国井さんと一緒に「ADFS/Office365連携の紹介」のタイトルで登壇させて頂くことになりました。
内容の詳細はこれから詰めるのですが、私のパートの方はOffice365のADFSの運用やトラブルシュート関係（おそらく、今であれば証明書周りになると思いますが）にしようかなと思ってます。
FIMのハンズオン（GoogleAppsとのシングルサインオン環境構築）も有りますし、凄い豪華な内容になっています。まだ申込みは始まってないようですが、興味のある方は是非参加頂けると幸いです。
ディレクトリ同期ツールは、デフォルトでいくつかのフィルタルール（例えば、isSystemCriticalObject属性の物は同期しない）などが設定されており、それらを除いて同期オブジェクトのフィルタリングはMicrosoftの正式なサポートとしては提供されておりません。
ただ、用途によっては特定のOUのみ同期させたい、特定のドメインのオブジェクトのみ同期させたいということがあるかと思います。（テストで実施をする場合や、オンプレミスのシステムで利用しているサービスアカウント群を同期したくない、など）
英語版のコミュニティのWikiに Configure Filtering for Directory Synchronization というカスタムのフィルタを設定する方法が公開されておりますので、ここではその内容を一部抜粋して紹介したいと思います。
【前提】以下で紹介する手順は、いずれもディレクトリ同期ツールに含まれるdentity ManagerもしくはSyncronization Service Managerという管理コンソールからMIISAdminsグループに所属するユーザーアカウントで実行します。（ディレクトリ同期ツールは32bit版はILM2007、64bit版はFIM2010をベースにしていますので、インストールされている場所が異なりますが、見た目含め中身はほぼ一緒です）
（参考：64bit版のツールを起動した画面）
①OUベースのフィルタリング
②ドメインベースのフィルタリング
③ユーザー属性ベースのフィルタリング
例として、extensionAttribute15属性にNoSyncが設定されているユーザーを同期対象外とするように構成したいと思います。
※ここで紹介するフィルタリングはユーザーオブジェクトのみに適用可能です。（グループならびに連絡先は、より複雑なフィルタリングが施されております。）
この辺りの概要については、ILM 2007 を使用して Active Directory ユーザーを管理する などのTechnet記事などに紹介がありますので、それぞれの項目についてもう少し理解をしたい場合には参考になさってください。
※2013.1追記 Office365のUpgradeプロセス見直しにより、各テナントのパラメータが保持されるようになったようです。よって、以下の問題は発生しないものと思われます。
Office365は、Exchange2010をベースとして開発されておりますが、クラウドサービス向けにデフォルトの設定値とは少しパラメータを変更して提供されております。
ところが、クラウドサービスの性質上、定期的にバージョンアップや仕様変更（例えば、メールボックス容量の増加）などを実装する場合があり、この際にExchangeデフォルト値→Office365デフォルト値に変更をするというスクリプトが実行されています（サーバの設定値がソフトウェアデフォルトに戻ってしまわないようにだと思われますが、）。
通常であればあまり問題は無いのですが、ユーザー側でも設定変更が可能なパラメーターが少数ながら存在し、その値をユーザーサイドでカスタマイズして利用している場合は、定期的に変更していないか確認をして設定変更する必要があります。
私の確認した範囲で、上書きされる可能性の有るパラメータは以下2コマンドの3パラメータです。
| Set-RemoteDomain | AutoForwardEnabled | True |
| AutoReplyEnabled | True | |
| Set-OrganizationConfig | MailTipsLargeAudienceThreshold | 25 |
特に、前者はセキュリティ上の理由で外部転送を拒否していると思われますので、定期的に確認をして設定が戻っていないかを調査するのが望ましいと思われます。
なお、この変更は私のテナントだと2011/8、2011/11、2012/6の3回実施されております。実施されたかどうか、どういったコマンドが実行されたかは管理者監査ログを取得することにより、確認をすることができます。通常は利用することができない Administrator や w3wp などの特権アカウントでメンテナンスは実行されますので、それと合わせることにより確認がしやすいかと思います。 
実行されている詳細なコマンドは以下の通りです。
| Set-OrganizationFlags | 影響なし | ||
| Set-TenantObjectVersion | 影響なし | ||
| Set-PerimeterConfig | DomainController | “” | 影響なし |
| Identity | apcprd03.prod.outlook.com /Microsoft Exchange Hosted Organizations/contoso.onmicrosoft.com |
||
| EhfConfigSyncEnabled | True | ||
| RouteOutboundViaEhfEnabled | True | ||
| SyncToHotmailEnabled | False | ||
| EhfAdminAccountSyncEnabled | False | ||
| HygieneSuite | Standard | ||
| Set-TransportConfig | DomainController | “” | 影響なし |
| Identity | contoso.onmicrosoft.com | ||
| UseServicePlanAsCounterInstanceName | True | ||
| OrganizationFederatedMailbox | FederatedEmail.xxxxxx @contoso.onmicrosoft.com |
||
| SupervisionTags | Reject;Allow | ||
| Set-MailboxPlan | DomainController | “” | 影響なし |
| Identity | apcprd03.prod.outlook.com/ Microsoft Exchange Hosted Organizations/contoso.onmicrosoft.com /Default-xxxxx |
||
| QueryBaseDNRestrictionEnabled | False | ||
| RecipientLimits | 500 | ||
| MaxSendSize | 35 MB (36,700,160 bytes) | ||
| MaxReceiveSize | 36 MB (37,748,736 bytes) | ||
| ResetPasswordOnNextLogon | False | ||
| SingleItemRecoveryEnabled | True | ||
| EwsEnabled | True | ||
| ActiveSyncEnabled | True | ||
| MAPIEnabled | True | ||
| MAPIBlockOutlookNonCachedMode | True | ||
| HiddenFromAddressListsEnabled | False | ||
| UseDatabaseRetentionDefaults | False | ||
| RecoverableItemsQuota | 30 GB (32,212,254,720 bytes) | ||
| RecoverableItemsWarningQuota | 20 GB (21,474,836,480 bytes) | ||
| Set-CASMailboxPlan | 影響なし | ||
| Set-RemoteDomain | Identity | contoso.onmicrosoft.com | 影響あり |
| AutoForwardEnabled | True | ||
| AutoReplyEnabled | True | ||
| Set-OrganizationConfig | DomainController | “” | 影響あり |
| Identity | contoso.onmicrosoft.com | ||
| MailTipsGroupMetricsEnabled | True | ||
| MailTipsMailboxSourcedTipsEnabled | True | ||
| MailTipsAllTipsEnabled | True | ||
| MailTipsLargeAudienceThreshold | 25 | ||
| Set-Mailbox | Identity | apcprd03.prod.outlook.com /Microsoft Exchange Hosted Organizations/contoso. onmicrosoft.com/FederatedEmail.xxxxx |
影響なし |
| SCLQuarantineEnabled | False | ||
| Force | True | ||
| Arbitration | True | ||
| ProhibitSendQuota | 10 GB (10,737,418,240 bytes) | ||
| RecoverableItemsQuota | 30 GB (32,212,254,720 bytes) | ||
| SCLDeleteEnabled | False | ||
| UseDatabaseQuotaDefaults | False | ||
| SCLRejectEnabled | False | ||
| DisplayName | Microsoft Exchange | ||
| RecoverableItemsWarningQuota | 20 GB (21,474,836,480 bytes) | ||
| IssueWarningQuota | 9 GB (9,663,676,416 bytes) | ||
| ProhibitSendReceiveQuota | 10 GB (10,737,418,240 bytes) | ||
| HiddenFromAddressListsEnabled | True | ||
| SCLJunkEnabled | False | ||
| New-ApprovalApplication | 影響なし | ||
| New-ApprovalApplicationContainer | 影響なし | ||
| install-Container | 影響なし | ||
| Install-ActiveSyncDeviceClassContainer | 影響なし | ||
| Set-MServSyncConfigFlags | 影響なし | ||
| Set-Organization | 影響なし | ||
| Install-FederationContainer | 影響なし | ||
| New-MicrosoftExchangeRecipient | 影響なし | ||
| Install-InternetMessageFormat | 影響なし | ||
| Install-GlobalSettingsContainer | 影響なし | ||
| Install-EmailAddressPolicy | 影響なし | ||
| install-PerimeterConfigContainer | 影響なし | ||
| install-TransportConfigContainer | 影響なし | ||
| Install-GlobalAddressLists | 影響なし | ||
| Set-ManagementSiteLink | 影響なし | ||
Office365でシングルサインオンを運用してしばらく経つと、以下の様なメールを受け取ることがあります（テナントの設定で技術担当者のメールアドレスをきちんと登録しておく必要があります。）
普段、ディレクトリ同期したオブジェクトに禁則文字があったり他のオブジェクトと重複があった場合のエラーや、24時間のうちに1度もディレクトリ同期が行われなかった場合などにメールは飛びますが、こちらは証明書の有効期限切れの1~2ヶ月前あたりに来るようです（まだ来ないテナントとかも有って、詳細な条件は分からないのですが）。
ADFS証明書の更新について の記事で書いたとおり、証明書の更新のタイミングは「自己署名証明書の切れるタイミング」「通信用の公的SSL証明書の切れるタイミング」の2回有り、それぞれで実施をする必要があります。
これを放っておいて、どちらかの証明書の期限が切れた場合、もしくはトークン署名証明書が更新された後にUpdate-MsolDeferatedDomainコマンドを実施せずにプライマリ証明書に昇格してしまった場合はシングルサインオンができない状態になり、全てのユーザーがアクセスできないという事態になってしまいます。
というわけで、証明書は毎年忘れずに更新し、きちんと運用しましょうというお話でした。（どうしても忘れっぽい場合は、最初から3年なり5年なりの長めの外部＆自己署名証明書を実装しましょう）
Office365の次期バージョン（開発コードOffice15）のプレビューが開始されました。ヘルプを見てみたところ、概ねADFSがらみの部分は同じコンテンツのようでしたので、実際に試してみました。
ちなみに、環境はこんな感じです。
まずは、ADFS用のドメインを追加します。新しい管理者ポータルから、「ドメイン」を開き「ドメインの追加」を選択します。ドメイン名を入力し、次へを選択します。
ドメインの認証画面が表示されますので、プルダウンから「一般的な手順」を表示させます。すると、認証用のTXTレコード（MS=ms12345678）が表示されますので、こちらと同じ値を追加しようとしている独自ドメインのDNSに登録します。
変更が出来たのを自身の端末などから確認ができたら、「確認」ボタンをクリックするとドメインの登録が完了します（ここはキャッシュなどの問題で数時間～24時間ほどかかる場合もございます。） ドメインの用途は必要なサービスを選択（SharePoint Onlineは他のサービスとは排他）して「次へ」をクリックすると、ドメインの追加は完了します。
続けて、独自ドメインのDNSレコードの構成に入ることもできます。追加する必要のあるレコードは、概ねOffice365の時と変わらないようですが、MXの向け先であるFOPEのFQDNのみcontoso-com.mail.eo.outlook.com のような変換ルールだったのが contoso-com.mail.protection.outlook.com のような変換ルールになってます。（プレビュー版だからの可能性も有ります。）
ドメインが追加されたことを確認したところで、オンプレミス（AD、ADFSサーバ）側の処理に入りたいと思いますが、先行して「ディレクトリ同期のアクティブ化」を実施されておくことをお勧めします。
「ユーザーとグループ」からシングルサインオンの右側にあるセットアップを選択し、「ActiveDirectory同期をアクティブ化する」をクリックします。（画面には「最大24時間かかる場合があります」と表示されますが、本当に数時間以上掛かるケースが多いです。）
さて、この間にADFS、ディレクトリ同期サーバなどのセットアップを行います。
まずは、既存のActive Directory環境のアセスメントから実施します。今回、オンプレミスのActive Directoryが「exchange2013.local」というインターネット上で解決ができず、かつ自身で所有していない（＝Office365 Enterpriseの追加ドメインとして利用できない）ドメインなので、独自ドメインの「exchange2013.info」を利用します。
今まで、username@exchange2013.localだったユーザ名をusername@exchange2013.infoに変更します。勿論、この作業以降はユーザは元のIDではログオンできなくなるので注意が必要です。（今まで利用していたのがexchange2013usernameの形式であれば問題なく継続してログオンできます。）
ドメインコントローラ上から、「Active Directoryドメインと信頼関係」を開き、ドメイン名の上のルートを右クリックしてプロパティを開き「代わりのUPNサフィックス」にexchange2013.infoを追加します。
これで、ユーザーを作成する際やプロパティを開いた際に、UPN名で「exchange2013.local」の他に「exchange2013.info」をプルダウンから選択して設定することが可能になります。ちなみに、これを行っただけでは既存のユーザのUPNは変更されませんので、GUIからユーザーを選択してプロパティを開いて変更するか、PowerShellなどで変更してしまいましょう。
ここでは、Office 365 環境用 ID フェデレーション実装ガイド で紹介されているPowerShellを利用してドメイン内のUPNを問答無用でexchange2013.infoに変更しました。
$UPNSuffix = "exchange2013.info"
Get-ADUser -Filter:* | foreach {
[string]$newUPN = $_.SamAccountName + "@" + $UPNSuffix
Set-ADUser $_ -UserPrincipalName:$newUPN
}
続いて、DNSを作成します。exchange2013.infoというゾーンは、現在内部DNSには無いのでそれを新規で作成し、sts.exchange2013.infoというホストをADFSサーバのIP（adfs.exchange2013.local）に向けるようにAレコードを作成します。
つぎに、ADFS実行用のサービスアカウントを作成します。Active Directoryユーザーとコンピューターから、任意のユーザーを作成します。ここでは、adfsserviceというユーザーを作成しています。厳密には管理者権限が無くても構成は可能ですが、警告が出たり手順が複雑になるので、ここでは管理者として構成しておきます。
これで、ようやくADFSをセットアップする準備が整いました。ADFSサーバにadfsserviceのアカウントでログインします。また、セットアップに必要なファイルを準備しておくと良いと思います。
まず、AdfsSetup.exeを起動してADFSをインストールします。使用許諾に同意した後に、「フェデレーションサーバ」の役割を選択して進めると、プログラムのインストールは完了します。
最後の所で「ADFS2.0の管理スナップインを開始する」のチェックボックスを外して完了します。（もしくはチェックを外さないで、次の起動画面の状態で準備の次の工程を進めます）
ADFSのセットアップには、SSL証明書が必要になります。今回はイントラ内での利用のみかつ検証環境なのでエンタープライズCAから発行された証明書を利用しようと思います。（既に発行済みの物を.pfxで保存して持ってきておきます）
MMCを起動し、「スナップインの追加と削除」から「証明書」を選び「ローカルコンピュータ」を選択します。
「個人」からインポートを選択し、用意したpfxファイルをエクスポート可能な形で「個人」にインポートします。この際に最初にエクスポートした際に設定したパスワードが要求されます。
インポートした証明書の秘密キーに対して、ADFSサービスアカウントが読み取り以上のアクセス権限を有している必要がありますので、証明書の「秘密キーの管理」から適切な権限を割り当てます。
続いて、ADFSのセットアップに戻ります。「ADFS2.0の管理」を起動し、中央ペインの構成ウィザードを起動します。
「新しいフェデレーションサービスを作成」「新しいフェデレーションサーバーファーム」を選択します。利用する証明書では、先ほどインポートした証明書が選択され、フェデレーションサービス名に sts.exchange2013.info が入っていることを確認します。また、ADFSのサービスアカウントはadfsserviceを選択し、パスワードを入力します。
しばらく待つとADFSのセットアップの完了です。
この後、Office365の情報を追加するとADFSのセットアップは完了しますが、その前に、ディレクトリ同期ツールのセットアップを先に完了させる必要があります。
dirsync-ja.exe を管理者として実行します。ライセンス許諾に同意して次へを選択すると、しばらく待つとインストールの終了です。終了後はそのまま設定ウィザードに移行しますので、Office365 Previewポータルでディレクトリ同期の準備が完了したことを確認した後、構成ウィザードを起動します。
ちなみに、手順等の問題で先に「サインインアシスタント」をインストールした場合、このインストールの途中で異常終了します。かならず一度アンインストールしてからディレクトリ同期ツールをインストールして下さい。
さて…、ここで完了をクリックする前に、元のOffice365 Previewポータルに戻ってディレクトリ同期が有効化されていることを確認します。場合によっては1日以上待つことになるかもしれませんが、そこは余裕を持ってスケジューリングをしておいて、気長に待ちます。
ディレクトリ同期が有効化された後に、構成ウィザードを開始します。ウィザードでは、同期用のOffice365の管理者アカウントとActive Directoryの管理者アカウントを設定します。設定が完了したら早速同期しておきます。
最後に、ADFSを有効化します。用意しておいたWindows PowerShell用Microsoft Online Servicesモジュールを実行してインストールを行います。
その後、ADFSサーバ上でPowerShellを起動してConnect-MsolServiceでOffice365に接続し、Convert-MsolFederatedDomainコマンドを実行してシングルサインオンを有効化します。
$LiveCred = Get-Credential Connect-MsolService -Credential $LiveCred Convert-MsolDomainToFederated -DomainName contoso.com
これで、サーバ側の準備は完了です。
Active化したuser01というアカウントでシングルサインオンの試験をしてみようと思います。https://sts.exchange2013.info/ を「イントラネットサイト」に設定した後に、ポータルに接続しまてIDを入力後、「exchange2013.infoにサインインする」をクリックすると、数回のリダイレクトの後にシングルサインオンできました。
というわけで、特にOffice365の時の手順と相違なくシングルサインオン環境が構築できました。共通的に利用している部分も多く、特にディレクトリ周りは同じ基盤を使って実装していると思われます。
あまり日本語のドキュメントが無かったので、自分のリマインダ代わりに手順を記載します。
ADFSは、その動作の為にSSL証明書を利用しますが、その用途によって「①サービス通信証明書」「②トークン暗号化解除証明書」「③トークン署名証明書」の3つが利用されます。
Office365を利用する場合、ウィザードで通常通り作成すると、①はIIS等でCSR作成した外部CA（もしくは自己署名やエンタープライズCA）の証明書で、②③がADFSが自動的に生成した証明書となります。
SSL証明書には有効期限がありますので、①②③ともに有効期限が来る前に更新をする必要があります。
CSRの発行から登録についてもいくつか処理を実施しなくてはいけません。Microsoftのサポートページに機械翻訳のKBも載ってますので参考になさって下さい。流れとしては以下の通りです。
それを過ぎると、ADFS 2. 0 サービスの通信の証明書を変更する方法
以前の投稿「ADFSインストールから350日でSSO不可」「ADFSの自己証明書の期間延長」でも記載しましたが、自己証明書でADFSサービスが自動的に更新を行ってくれるので手順的にはそれほど問題は無いと思います。
Office365の場合は自動的に期限の切れる20日前に、その時点から1年間有効なセカンダリの証明書が発行されるので、それがプライマリに昇格する5日間の間にUpdate-MsolFederatedDomainコマンドを実行するか、Microsoft Office 365 Federation Metadata Update Automation Installation Toolをインストールしておきます。
手動で任意のタイミングで実行したい場合は、以下を参考に実行されて下さい。
Add-PSSnapin Microsoft.Adfs.PowerShell Import-Module MSOnline $LiveCred = Get-Credential Connect-MsolService -Credential $LiveCred Update-ADFSCertificate Update-MsolFederatedDomain -DomainName contoso.com Get-MsolFederationProperty Restart-Servivce adfssrv
毎回実施するのが面倒な場合は、Set-AdfsProperties -CertificateDuration 3650 などを加えても良いでしょう。更新後は念のためADFSサービスを再起動します。
ちなみに、ADFSファーム構成の場合、この証明書情報はActiveDirectory上に格納されますのでこの工程と①の最後の工程はADFSのプライマリ（最初にインストールした物：Get-AdfsSyncPropertiesでRoleがPrimaryComputerと出る物）で実施すればファーム内の別サーバに同期されます。
※その他の①の工程（IISへの設定）は各マシンで個別に実施する必要があります。
ADFS Proxyサーバは、基本的にはADFSサーバでいうサービス通信証明書に相当する証明書のみ利用しています。
通常の場合はADFS Proxy構成ウィザードを走らせる必要は無く、
でいけるかと思います。
ただ、ADFS側でトークン署名証明書を更新した場合は、ADFS Proxy構成ウィザードを再実行した方が良いという情報もございますので、念のため実行しておいた方が良いでしょう。