OneDrive サイトのカスタマイズ

OneDrive サイトは、会社の要件に基づいて、Microsoft 365 または一般的なアドイン モデルを使用してカスタマイズできます。 このカスタマイズを行う実際の方法は、アドイン モデルの方法のみを使用できることから、オンプレミス シナリオとは異なります。

重要

これは、SharePoint Online での従来の OneDrive エクスペリエンスのみに適用されます。 新しい既定のエクスペリエンスを使用している場合、これはサポートされません。 OneDrive のモダンまたは新しいエクスペリエンスでは、カスタム ブランディングをサポートしていません。 テナント管理者は、SharePoint Online の管理設定から既定のエクスペリエンスを制御できます。

専用およびオンプレミスの場合のパターンはアドイン モデル手法と同じですが、使用可能なテクノロジには違いがあります。

OneDrive サイトをカスタマイズする理由

OneDrive (OD4B) サイトにカスタマイズを適用することに関しては、さまざまな側面があります。 これらのサイトは SharePoint サイトであるためカスタマイズできますが、カスタマイズの短期的および長期的な影響を常に考慮する必要があります。

以下に、OneDrive サイトのカスタマイズに関する大まかなガイドラインを示します。

  • ブランド化カスタマイズは Microsoft 365 のテーマまたは SharePoint サイトのテーマ エンジンを使用して適用します。
  • テーマ エンジンで十分でない場合は、代替 CSS オプションを使用していくつかの CSS 設定を調整できます。
  • カスタム マスター ページを使用して OneDrive サイトをカスタマイズすることは避けてください。これにより、将来の更新に伴う長期的なコストと課題が増えるためです。
    • ほとんどの場合、テーマや代替 CSS で一般的なブランド化シナリオをすべて達成できます。
    • カスタム マスター ページを使用する場合は、Microsoft 365 に主要な機能更新プログラムが適用される際に、サイトにも変更を適用できるようにしておいてください。
  • JavaScript 埋め込みを使用すると、サイトの機能を変更したり、非表示にしたりできます。
  • CSOM を使用して、OneDrive サイトの言語や地域の設定を制御できます (「新しい API」を参照)。
  • OneDrive サイトでコンテンツ タイプとサイト列を使用することはお勧めしません。 OneDrive サイトは、個人用の非構造化データおよびドキュメントに使用します。 チーム サイトやコラボレーション サイトは、会社のデータやドキュメントに使用します。これらのサイトでは、ユーザーは希望する情報管理ポリシーとメタデータを使用できます。

Microsoft 365 ではカスタマイズが確実にサポートされるので、OneDrive サイトで使い続けることができます。 ただし、運用とメンテナンスの観点から、このようなカスタマイズが及ぼす影響はかならず考慮してください。 これは SharePoint に固有のものではなく、任意のプラットフォームで構築された IT ソリューションに関する経験則です。

以前のガイドラインに沿ってカスタマイズされた OneDrive サイトの例を次に示します。 ここでは Microsoft 365 のテーマ、サイト テーマ、および JavaScript の埋め込みパターンの使用を組み合わせることで、最終的な結果を実現しました。

カスタマイズされた OneDrive サイト

OneDrive サイトのカスタマイズを適用する場合の課題

各 OneDrive サイトでは、SharePoint 2007 と SharePoint 2010 で使われていた、個人用サイトと同じアーキテクチャが使用されています。 つまり、各 OneDrive サイトは独自のサイト コレクションであり、ブランド化やその他のカスタマイズを適用するための一元的な場所はありません。

各 OneDrive サイトは個人用管理パスの下に独自のサイト コレクションであり、URL は割り当てられたユーザー プロファイルに基づいて作成されます。画像では、3 つのサイトが子サイトとして一覧表示されます。最初の子サイトの URL は/bill_contoso_comで終わります。2 つ目は /vesa_contoso_com で終わります。3 つ目は /john_contoso_com で終わります。

必要な構成を OneDrive サイトに適用するために使用された従来のソリューションは、ファーム レベルの機能の関連付けに基づいていました。 つまり、SharePoint ファームにファーム ソリューションを展開し、個人用サイトが作成されるたびにカスタム機能をアクティブ化するよう、機能フレームワークを使用してカスタム機能を関連付け、その後、必要なカスタマイズを適用していました。

この方法は、Microsoft 365 では機能しません。これは、ファーム ソリューションを展開する必要があり、Microsoft 365 サイトでは不可能であるためです。 したがって、必要な変更をサイトに適用するため、代替案を探す必要があります。

Microsoft 365 では、OneDrive サイトの作成時にカスタム コードを添付できる一元化されたイベントは発生しません。 そのため、アドイン モデルのアプローチと一般的な代替ソリューションについて考える必要があります。 古いモデルでスタックしないでください。新しい API とテクノロジを使用して同じ最終結果を達成する方法について考えます。 要件の観点から見ると、カスタマイズをサイトに適用する方法は重要ではありません。適用されている限り、ビジネス要件は機能のステープリングを使用しないため、サポートされている技術的なメカニズムを使用して必要なカスタマイズを適用します。

カスタマイズを適用するためのオプション

Microsoft 365 で一元的なカスタマイズを OneDrive サイトに適用するメカニズムは 4 つあります。 5 番目のオプションとして手動オプションを検討することもできますが、数百または数千の OneDrive サイトがある場合は、手動オプションを使用することは現実的ではありません。 以下のオプションがあります:

  • Microsoft 365 スイート レベルの設定 (Microsoft 365 テーマおよび他の設定)
  • ユーザー コンテキストが含まれる非表示のアプリ パーツ
  • 構成を事前に作成して適用する
  • ユーザー プロファイルの更新に基づくリモート タイマー ジョブ

それぞれのオプションには長所と短所があり、適切なオプションは詳細なビジネス要件によって異なります。 Office 365 スイート レベルから一部の設定を適用することもできますが、恐らくより具体的な設定が必要になります。そのため、実際にカスタマイズを行う必要があります。

Microsoft 365 スイート レベルの設定

Microsoft 365 は SharePoint だけではありません。 Delve や Yammer など、SharePoint アーキテクチャに基づいていないその他のサービスを見つけることができます。 つまり、企業のブランド化と構成は、SharePoint サイトの内容を制御することだけではありません。むしろ、全体的なエンド ユーザー エクスペリエンスと、さまざまなサービス間で一貫した構成を提供する方法について考える必要があります。

これらの企業要件の典型的な例はブランド化です。これに対応するため、ある程度のレベルのブランド化をコントロールできる Microsoft 365 テーマを導入しました。

次の図には、Microsoft 365 テーマの現在の設定が示されています。この設定はすべての Microsoft 365 サービスに適用できます。

Microsoft 365 サイトが表示され、カスタムテーマタブページが表示され、「organizationのカスタムテーマを管理する」、Office 365をカスタマイズしてオガン化のブランドを反映します。設定は、カスタム ロゴ、クリック可能なロゴの URL、背景画像、アクセントカラー、ナビゲーション バーの背景色、テキストとアイコンの色、アプリ メニュー アイコンの色で使用できます。

既定では、テーマ設定Office 365 OneDrive サイト スイート バーを制御するため、これらのオプションを他のオプションと共に使用して、OneDrive サイト全体で少なくとも適切なブランド化要素を確実に提供できます。 Office 365 管理ツールで Office 365 のテーマ設定を変更すると、設定が OneDrive サイトに適用されるまでに長い時間がかかります。しばらくお待ちください。

ユーザー コンテキストが含まれる非表示のアプリ パーツ

このアプローチでは、必要なカスタマイズ プロセスを開始するための場所として一元化されたランディング ページを使用します。 つまり、会社のイントラネット ホーム ページなど、ユーザーがブラウザーを開くと必ず表示される 1 つの一元化された場所が必要になります。 これは、Active Directory のグループ ポリシー設定を使用して企業のランディング ページを制御する中規模および大規模企業の一般的なプロセスです。 これにより、エンド ユーザーは、会社のドメインに参加しているブラウザーの既定のウェルカム ページをオーバーライドできなくなります。

ユーザーがイントラネット サイトに到達すると、ページ上の表示されていないアプリ パーツがカスタマイズ プロセスを開始します。 通常のユーザーはサイト作成プロセスが開始する前に一度 OneDrive サイトを訪問する必要があるため、実際にはこのアプリ パーツは、OneDrive サイトの作成全体を実行します。 非表示のアプリ パーツは、Azure でホストされているプロバイダー ホスト型アドインからページをホストします。 次に、このページはカスタム プロセスを開始します。

このアプローチの論理設計の細部に注目してみましょう。

リレーションシップを表示する図。SharePoint サイトのアプリ パーツでは、インスタンス化を使用してプロバイダー ホスト型アプリに移動します。プロバイダー ホスト型アプリでは、メッセージの追加を使用してストレージ キューに移動します。ストレージ キューでは、インスタンス化を使用して WebJob に移動します。WebJob では、変更の適用を使用して OneDrive サイトに移動します。

  1. 非表示のアプリ パーツを、エンドユーザーが到達する集中管理サイトに配置します。 通常これは、企業のイントラネットのフロント ページです。
  2. アプリ パーツはプロバイダー ホスト型アドインからページをホストしています。プロバイダー ホスト型アドインでは、サーバー側コードで Azure ストレージ キューに必要なメタデータを追加することでカスタマイズ プロセスを開始します。 つまり、このページはカスタマイズ要求のみを受け取りますが、処理時間を正常に保つための変更は実際には適用されません。
  3. これは、処理をキューに追加するために受信される、実際の Azure ストレージ キューです。 これにより、カスタマイズ制御プロセスを非同期的に処理できるため、エンド ユーザーがイントラネットのフロント ページに留まる期間は関係ありません。 カスタマイズ プロセスを同期すると、ページの実行が完了するまでイントラネットのフロント ページでブラウザーを開いたままにするかは、エンドユーザーに依存します。 それでは、最適なエンド ユーザー エクスペリエンスになるはずがありません。
  4. WebJob は、Azure Storage Queue に従ってフックされます。これは、新しい項目がストレージ キューに配置されたときに呼び出されます。 この WebJob は、正しいサイト コレクションにアクセスするため、キューのメッセージから必要なパラメーターとメタデータを受信します。 WebJob は、App Only トークンを使用しており、テナントのレベルでサイト コレクションを操作するために必要なアクセス許可が付与されます。
  5. 実際のカスタマイズは、プロセスを開始するイントラネットのフロント ページにアクセスしたユーザーのサイトに対して、個々に適用されます。

これは、OneDrive サイトに適切な構成があることを確認する最も信頼性の高いプロセスです。 カスタマイズのバージョン管理ロジックをプロセスに簡単に追加できます。これにより、必要な更新プログラムが必要なときにユーザーがイントラネット のフロント ページに次回アクセスするときに、必要な更新プログラムを OneDrive サイトに適用できます。 ただし、このオプションでは、エンド ユーザーが到達する一元化された場所が必要です。

ファーム ソリューションを使用した従来の SharePoint 開発モデルに慣れている場合、このプロセスは 1 回限りのタイマー ジョブの実行に似ています。

構成を事前に作成して適用する

このオプションは、ユーザーがアクセスする前の、OneDrive サイトの事前作成に依存しています。 これは、CSOM または REST を使用して、バッチ プロセスで特定のユーザー用の OneDrive サイトを作成する方法を提供する比較的新しい API を使用することで実現できます。 PowerShell スクリプトを使用するか、リモート API を呼び出す実際のコードを記述することで必要なコードを開始できます。

管理者は、OneDrive サイトを作成するために、事前作成とカスタマイズを使用します。

  1. 管理者は、リモート作成 API を使用してユーザーの OneDrive サイトを作成し、スクリプト プロセスの一部として OneDrive サイトに必要なカスタマイズを適用します。
  2. 実際の OneDrive サイトは特定のユーザーのために Microsoft 365 に作成され、ユーザー プロファイルに関連付けられます。

これも信頼性の高いプロセスですが、新しいユーザーの管理と更新を「手動」で行う必要があります。つまり、非表示のアプリ パーツの方法を使用した場合より多くの作業が必要となります。 ただし、これは有効な方法であり、他のファイル共有ソリューションから OneDrive に移行していて、ユーザーが実際のサイトの作成を開始する前に OneDrive サイトに 1 回アクセスする必要がないようにする場合に特に便利です。

ユーザー プロファイルの更新に基づくリモート タイマー ジョブ

この方法では、ユーザー プロファイルをスキャンし、OneDrive サイトの作成者を確認した後、必要に応じて変更をサイトに適用します。 つまり、SharePoint の外部で実行されるスケジュールされたジョブは、定期的に状態をチェックし、必要なカスタマイズを実行します。 スケジュールされたジョブは、Azure での WebJob として、または独自の Windows スケジューラーの PowerShell スクリプトとしてシンプルに実行することができます。 明らかに、展開の規模は選択したスケジュール設定オプションに大きな影響を与えます。

リモート タイマー ジョブは、サイト コレクション内のループを使用して各サイトをカスタマイズします。

  1. スケジュールされたタスクが開始されます。その際、OneDrive サイトをプロビジョニングするユーザーを確認するためにユーザー プロファイルもアクセスします。
  2. 実際のサイトは、個々のビジネス要件に基づいてカスタマイズされます。

このオプションのキーの欠点の 1 つは、カスタマイズが適用される前に、ユーザーが OneDrive サイトにアクセスできる状況の可能性が明確にあるということです。 同時に、このオプションは、エンド ユーザーがサイトで必要な設定を変更していないことを確認したり、OneDrive サイトのコンテンツが会社のポリシーと一致することをチェックしたりするための、他のオプションの興味深いアドオンです。

関連項目