次の方法で共有

SharePoint Framework エンタープライズ ガイダンス

  • [アーティクル]

SharePoint Framework (SPFx) は、SharePoint ユーザー インターフェイスの機能拡張のための新しい開発モデルです。 これは、ファースト パーティとサード パーティによって使用され、既存のカスタマイズと、SharePoint アドイン モデルなどの拡張オプションを補完します。 SharePoint Frameworkを使用すると、クライアント側フレームワークを使用して SharePoint のユーザー インターフェイスを強化および拡張するための構造化されたサポートされているアプローチが可能になります。 最新の Web 標準に基づいて、SharePoint のカスタマイズを開発者や企業が幅広く利用できるようにする一連の独自の機能を提供しますが、同時に SharePoint の以前のモデルやパターンと一致します。 このページでは、管理者が SharePoint 環境内のSharePoint Framework ベースのコンポーネントを正常に管理するために必要な背景、利点、知識を提供します。

背景

SharePoint は長い間、アプリケーションおよび開発プラットフォームとして使用されてきました。また、開発やカスタマイズに関する多くのオプションのセットを提供してきました。これには、SharePoint サーバーで実行される完全信頼コード、セキュリティで保護されたソリューション、アドイン、標準機能または JavaScript/CSS の埋め込みを使用して実現されるインターフェイスのカスタマイズなどが含まれます。

マルチテナントの SharePoint Online 内では、完全信頼コードはサポートされたことがなく、セキュリティで保護されたコード サービスは使用されなくなりました。 SharePoint Online のカスタマイズの最も一般的なパターンは、アドイン、標準 API によるリモート コード実行 (Azure など別の場所でのコード実行)、JavaScript の埋め込みのいずれかの方法です。 JavaScript の埋め込みは SharePoint を拡張するための強力な方法でしたが、SharePoint Online の永続モデルに付いていくのは困難であることがわかってきました。 SharePoint Framework は、カスタム ユーザー インターフェイスの拡張機能の作成方法に関する標準化されたフレームワークを提供したり、サポートされている方法および今後用意される方法で SharePoint Online 上にアプリケーションをビルドしたりすることによって、この問題を解決することを目指しています。

SharePoint Framework は、クライアント側の Web パーツおよび拡張によって SharePoint ユーザー インターフェイスを拡張します。

クライアント側の Web パーツ

クライアント側の Web パーツは Web パーツの既知のパラダイムを実装します。これは、長年 SharePoint が成功を収めてきた要因の 1 つです。 エンド ユーザーはこれをページに追加して個別にカスタマイズできます。 このクライアント側の Web パーツは、新しいモダン ページや従来のページ、SharePoint モバイル アプリでも動作します。

注:

詳細については、「SharePoint のクライアント側 Web パーツの概要」を参照してください。

拡張機能

SPFx 機能拡張を使用すると、開発者は SharePoint の "従来" の環境で使用することのできた特定のユーザー インターフェイスのカスタマイズを "新しい" 環境で実装できます。 開発者は、JavaScript を任意のページに追加したり、ページ ヘッダーおよびフッター、メニュー アイテムをリストやライブラリに追加したり、リスト内のフィールドのビューをカスタマイズできます。

開発モデルとツール

SharePoint Framework は、モダン Web スタックベースの TypeScript、JavaScript、HTML、および CSS を使用して一からビルドされます。 生成される成果物のパーツはすべてエンドユーザーのブラウザーで実行されます。 SharePoint Framework には新しい一連のツールも付属しています。 この新しいツールは、プラットフォームに依存せず、Windows、macOS、Linux で動作します。これは、Node.js、Gulp、Webpack、Yeoman などのオープンソース テクノロジに基づいています。 これらのフレームワークとツールは、ビルド、パッケージ化、展開に関する開発者のエクスペリエンスを効率化するために、ビルド時に使用されます。SharePoint Framework コードの実際の実行時には必要ありません。

SharePoint Framework の現在の状態

SharePoint Framework は、2017 年 2 月に SharePoint Online にリリースされました。 SharePoint Framework の最新バージョンと以前のすべてのバージョンはホストされ、SharePoint Online で利用できます。

SharePoint Framework は、SharePoint Server 2016 (Feature Pack 2 を含む) のバージョン v1.1 および SharePoint Server 2019 のバージョン v1.4.1 でも使用できます。

開発者の視点

経験の有無を問わず、すべての SharePoint 開発者が SharePoint Framework から何かしら得るものがあります。 SharePoint Framework により、開発者は安全かつ構造化された方法で、SharePoint のユーザー インターフェイス機能を、まずクライアント側の Web パーツを使用して拡張することができます。 これらのコンポーネントはクライアント側で実行され、Microsoft Graph を介して SharePoint または Microsoft 365 でデータを処理できます。あるいは、標準の OAuth と REST メソッドを使用する独自のカスタム Web API を使用して処理することもできます。

経験豊富な SharePoint 開発者は、Web パーツや SharePoint データ モデルなどの概念に精通しています。 しかし、クライアント側の Web パーツのビルド、パッケージ化、展開のためのツールについては詳しくありません。 開発者は特に TypeScript に関するスキルを習得する必要があります。これは SharePoint Framework 成果物を開発するための第一言語です。 TypeScript は、エンタープライズ開発にとって重要ないくつかの利点を JavaScript に加えます。たとえば、厳密に型指定されたオブジェクト、オブジェクトの継承、クラスとインターフェイスがあり、現在の .NET、Java、C/C++ 開発者がすべて知っておくべき概念も含まれます。 ビルドやパッケージ化の観点からすると、Visual Studio は開発者が SharePoint ソリューションを作成するための唯一のオプションではなくなりました。node.js、npm、Gulp などのオープンソースのテクノロジやプロジェクトを使用することで、開発者は好みのコード エディターや IDE (Visual Studio Code、Sublime、さらにはメモ帳など) を使用してあらゆるプラットフォームで SharePoint Framework 開発を行えるようになりました。

SharePoint ソリューションを今までビルドしたことがないものの、最近の Web テクノロジには詳しい開発者の場合、重大な学習曲線とはなりません。 多くの開発者は既にクライアント側の開発またはその組み合わせに移行しています。 クライアント側の開発は、質が高く、より動的で応答性の高いエクスペリエンスをユーザーに提供します。開発者にとっても、より簡単なエクスペリエンスです。 コード エディターの指定がなく、よく知られている一般的なオープンソースのフレームワークとテクノロジを使用できるので、Microsoft エコシステム内で作業をしたことがない開発者でも、SharePoint の拡張機能のビルドのスピードに簡単に付いていくことができます。

SharePoint Online 拡張機能の最も一般的なパターンの 1 つは、JavaScript の埋め込みの使用です (JavaScript インジェクションとしても知られています)。 これは、たとえば Script Editor Web パーツを使用して任意の JavaScript をページに挿入した後、Web ブラウザー DOM (Document Object Model) の操作を使用して HTML、CSS、JavaScript を挿入してソリューションまたはアプリケーションをビルドする場合の方法です。 この方法には多くの欠点があり、SharePoint が HTML と CSS の構造をビルドした方法に大いに依存するため、多くの場合、お客様が SharePoint Online の新機能を利用する妨げにもなってきました。 まだ完全な代わりにはならないものの、SharePoint Framework は、これらの JavaScript の埋め込みカスタマイズよりも優れた方法です。 既に述べたとおり、SharePoint Framework が使用する TypeScript によって、JavaScript の埋め込みから、標準化されたものおよび将来のプルーフへと、非常に簡単に移行できるようになります。 OfficeDev PnP イニシアチブにも、この移行を行う方法に関するサンプル プロジェクトとガイドラインがあります。

パースペクティブ: より広い範囲の SharePoint プラットフォームでの SharePoint Framework

SharePoint Framework は、既存の方法に加えられた新しいモデルですが、クライアント側の Web パーツなどのユーザー インターフェイスのカスタマイズにより価値をもたらすことに重点を置いています。 このフレームワークは既存の作業モデルと一緒に使えるように設計されており、新しいユーザー インターフェイスのカスタマイズを、よりサポートされた持続的な方法で、より簡単に作成できるようにも設計されています。

重要

SharePoint ページの HTML DOM は API ではありません。 変更の可能性があり、ソリューションを破損する可能性のある、ページ DOM 構造または CSS スタイルへの依存は避けてください。 SharePoint Framework は、信頼できる方法で SharePoint エクスペリエンスをカスタマイズする豊富な API を提供し、SharePoint ページの HTML DOM を操作するためにサポートされている唯一の手段です。

アドインとの比較

SharePoint 2013 で SharePoint アプリとして導入され、後に改名された SharePoint アドイン はこれまで、サポートされ制御された方法で SharePoint Online にカスタマイズを追加するための唯一使用可能なオプションでした。 しかし、SharePoint アドインは、単純なユーザー インターフェイスのカスタマイズが必要とされる多くのケースで、より多くのインフラストラクチャを必要とします。

SharePoint アドインには 2 種類あります。SharePoint ホスト型とプロバイダー ホスト型です。 SharePoint ホスト型のアドインはサポートされている方法で SharePoint でクライアント側のコードを実行するための 1 つの方法ですが、前述のとおり、単純なクライアント側 (JavaScript) の Web パーツを組み込む場合よりもずっと多くの労力が必要になります。 多くの場合、SharePoint ホスト型のアドインは、リストや Web パーツの SharePoint サイトへの展開など、ただ成果物を展開するためだけにビルドされていました。 これらのアドインは、アプリ Web と呼ばれる「特別な」サイトにあります。これは、限定された機能を持つサイトです。

プロバイダー ホスト型アドインは、SharePoint (Online) のリモートで実行されるアドインであり、クライアント側およびサーバー側のコードを利用できます。 これは、知的所有権/コード/ロジックを保護する ISV にとって有利です。また、JavaScript を使用してクライアント側で実行できないシナリオにおいても有利です。たとえば、長時間実行、大量の計算が発生する操作、クライアント側のスクリプトの使用では到達できないリモート データへのアクセスが関係する場合です。

アドインの主な利点は分離です。実際のコードは SharePoint サイト ブラウザーでは実行されないため、クロスサイト スクリプティング保護により、アドインは、ユーザーと同じアクセスを取得することはできません。 アドインには、インストール時にアドインに付与されたアクセス許可だけが与えられます。 これにより、管理者がサード パーティからアドインを取得するシナリオにおいて、アドインがより安全なオプションになります。アドインをダウンロードするストアを Microsoft が持てるようにもします。

SharePoint Framework は SharePoint ホスト型アドインとプロバイダー ホスト型アドインの両方と横並びで動作できるだけでなく、クライアント側のスクリプトだけが必要になるシナリオでも代替として使用できます。 たとえば、アドインはアプリ パーツを、それがホストされるサイトに追加できます。 これらのアプリ パーツは Web パーツと似ていますが、ページのコンテキストで実行する代わりに、ページ上の Iframe 内の独自のドメイン (アプリ Web またはプロバイダー ホスト型 Web) で実行されます。 これにより、アドインが残りのページからユーザー コンテキストを取得しないようにすることができます。

SharePoint Framework は Iframe では実行されません。 そのため、パーツを表示するユーザーのフルパワーで、ページのコンテキストでのよりシームレスな実行が可能になります。 これは、豊富な機能を使って実行できるようにするための鍵です。しかし同時に、アドインと同じレベルのセキュリティ コントロールはないことを意味します。そのため SharePoint Framework のソリューションは、完全信頼クライアント側ソリューションとも呼ばれます。 Iframe では、対応できない問題も発生します。これにより、Web ページが携帯電話や別の画面サイズではきれいに表示されないという結果になります。

執筆の時点では、前述のセキュリティの問題のため、ソリューションをダウンロードしてインストールするストアが SharePoint Framework ソリューションにありません。 多くのシナリオは、ユーザー コンテキストの使用が望ましいシナリオです。その場合には、SharePoint Framework を代わりに使用することもできます。

HTML への JavaScript の埋め込み

開発者によって使用される最も一般的なアプローチの 1 つは、JavaScript の埋め込みと呼ばれる方法の使用です (JavaScript インジェクションとしても知られています)。 それは、カスタム アクション、マスター ページ、ページ レイアウトや、スクリプト エディター Web パーツなどを使って、サイトとページに任意の JavaScript が挿入されていることを意味します。 この方式は、SharePoint ホスト型アドインの作成より単純であることがわかっており、これによってスクリプト コードをユーザーのフルコンテキストで実行することができます。そのため、高い人気を得ています。 このアプローチの欠点として、これらの埋め込みの多くが DOM の操作に依存していること、およびこの実行と保守に開発者スキルを必要することがあります。

SharePoint Online の永続性という性質上、JavaScript を埋め込んでビルドされるこれらのソリューションは、SharePoint Online が更新されると中断する可能性があります。SharePoint ページの構造化とスタイルの適用方法に開発者が依存していた可能性がある (偶然の可能性もある) からです。 SharePoint での更新は、それがマイナーで微小なものであったとしても、これらのソリューションに大きな影響を与え、埋め込み JavaScript が完全に中断する原因となり得ます。

今後は、SharePoint Framework を使用することで、以前 JavaScript の埋め込みを使用してビルドされたこれらのソリューションの多くを実現できます。これは、Microsoft によって標準化されサポートされている方法です。

スクリプト エディター Web パーツ

SharePoint で任意の HTML、JavaScript、または CSS カスタマイズを挿入するための最も一般的な方法は、スクリプト エディター Web パーツまたはコンテンツ エディター Web パーツを使用する方法です。 スクリプト エディター Web パーツは、カスタム スクリプトをどのページにも簡単に追加できるため、人気があります。 サイトのエディターはどれも、スクリプト エディター Web パーツをページに追加したり、JavaScript をコピー/貼り付けしたり、JavaScript が必要なカスタマイズを実行するようにしたりできます。 JavaScript の埋め込みと同様、スクリプト エディター Web パーツの管理は管理者にとって課題となる可能性があります。

多くの場合、SharePoint Framework をこれらのスクリプト エディター Web パーツ構成に直接代わるものとして使用できます。

SharePoint Online でのスクリプト機能の制御

SharePoint Online を使用することで、管理者はカスタム スクリプトをサイトやページに追加する機能を制御して、テナントのセキュリティや整合性を向上させることができます。 これは、SharePoint Online 管理者サイトで「カスタム スクリプト」機能を使って行うことも、PowerShell を使ってサイト単位で個別に行うこともできます。

カスタム スクリプトは、すべてのサイトで無効にすることも、個人用サイトのみで無効にすることもできます。 既定では、個人用サイト、セルフサービスによって作成されたすべてのサイト、テナントのルート サイト コレクションで、新しいテナントのスクリプトが無効になります。

カスタム スクリプトが無効になると、サイトの編集者は、スクリプト エディター Web パーツなどの Web パーツを追加できなくなります。 しかし SharePoint Framework ソリューションは許可されます。アプリ カタログで管理者によって承認された後は、安全なソリューションと見なされるからです。

SharePoint Framework ソリューションの作成方法の違いとそれが重要な理由

SharePoint Framework では、先進的な web スタックのアプローチを活用することと、クライアント側とブラウザー ベースのカスタマイズに重点を置くことによって、SharePoint のカスタマイズを設計、ビルド、展開する方法において SharePoint 開発者にとって新しいパラダイムを使用します。

これによって、SharePoint 開発の扱い方に重要な違いが生じます。

TypeScript、Node.js、Yeoman、Gulp などのテクノロジとフレームワークの使用により、SharePoint Framework は従来 SharePoint (あるいは Microsoft の) エコシステムを使用していなかった開発者ユーザーを引きつけるものとなります。同時に、既存の SharePoint 開発者に対しては、より先進的で標準化されたアプローチによる SharePoint カスタマイズの作成の扉を開きます。

ソリューションを作成する

非常に特定性が高く対象を絞ったツールを Visual Studio 経由で提供する必要があったため、SharePoint の開発は通常、SharePoint のインスタンスがインストールされ構成されている Windows ベースの開発環境内の Visual Studio で行われていました。 これにより、ハードウェアやユーザー設定が厳しく制限され、開発コストが増大していました。 一方、SharePoint Framework は macOS や Linux などのさまざまなプラットフォームで使用できる各種の共通のオープン ソース Web ツールを使用しているため、より柔軟に開発を行うことができます。

SharePoint Framework ソリューションは、Yeoman と呼ばれるツール、および特定の SharePoint Framework ジェネレーター (Node.js に基づく) を使用して作成されます。 Yeoman はプロジェクト スキャフォールディング ツールであり、プロジェクトを作成したり、必要な成果物を生成したり、必要な Node.js パッケージをインストールしたり、ビルド システムを構成したりします。

プロジェクトを生成した後、Visual Studio、Visual Studio Code、Sublime、Atom など、オペレーティング システムの任意のエディターで編集できます。 これにより、チーム内とチーム間で選択できる使用の設定やスタイルの幅が広がります。 Yeoman ジェネレーターは、クライアント側の Web パーツなどの成果物を追加するために同じプロジェクトで何度でも実行できます。

ソリューションを開発およびビルドする

ビルド システムは、Gulp に基づいています。 Gulp は、SharePoint Framework 成果物をビルド、パッケージ化、および必要に応じて展開するタスク ランナーです。 Yeoman と同様、Gulp も Node.js に基づいており、開発者はあらゆるオペレーティング システムでビルドおよび展開することができます。

SharePoint Framework のビルド ツールセットの一部に、ワークベンチがあります。 ワークベンチは、開発者が SharePoint Framework ソリューションをホストしてテストするためのツールです。 ワークベンチには反応性があり、開発者がソリューションをすばやく確認およびテストできるよう、ファイルを保存するときに成果物を自動的に再読み込みします。

ワークベンチには 2 つのバージョンがあります。 1 つは SharePoint 外部に存在し、SharePoint アクセスと SharePoint データがなくても 'オフライン' で実行する開発マシンでローカルにホストされます。 これにより、チームとデザイナーは、架空のデータを使用してソリューションをビルドおよび設計し、ユーザー インターフェイスに重点的に取り組むことができます。

ワークベンチの別のバージョンは SharePoint 内でホストされるもので、実際の SharePoint データおよびコンテキストを使用して SharePoint Framework ソリューションをテストおよび検証する必要があるときに使用されます。

重要

ローカル ワークベンチには最新のブラウザーが必要です。 Internet Explorer 11 はローカル ワークベンチではサポートされていません。

SharePoint Framework ソリューションを展開する

SharePoint Framework ソリューションの展開は、ソリューション パッケージをアプリ カタログに展開し、テナントまたはサイト コレクションでの使用のためにそれを承認することで行われます。

SharePoint Online に展開されたソリューションの場合、Microsoft 365 によってホストされた CDN を使用して、クライアント側コンポーネントの実装に使用するソリューション内の成果物を保存および提供できます。 詳細については、「Microsoft 365 Public CDN」のセクションを参照してください。

SharePoint Server に展開されたソリューションの場合、成果物の保存先を決定する必要があります。 これは、SharePoint Online では必要ない追加の展開手順です。 ソリューション内のユーザーが成果物にアクセス可能であることが唯一の要件となります。

SharePoint Online CDN の代替手段

SharePoint Framework ソリューションの開発者は、任意の CDN サービスを使用できます。たとえば、Azure Storage、Azure CDN などですが、SharePoint そのものを使用することもできます。推奨されているのは、SharePoint CDN 機能を使用することです (後述を参照)。 パブリック CDN を使用する場合、CDN に展開されるアセットを誰でもインターネットで入手できます。これを使用すると、SharePoint Framework ソリューションを多くのテナントで使用できるようになります。 SharePoint CDN に展開される SharePoint Framework ソリューションでは、展開されるスクリプトとリソースは、展開先のテナントでのみ使用可能になります。

既定では、パッケージ化されたソリューションを Azure Blob ソリューションに展開するためのタスクがビルド ツールに組み込まれています。 これは通常、カスタム CDN の場所または構成をサポートするために SI または ISV によって拡張されるものです。

コードを変更してソリューションをビルドした後、SharePoint Framework ツールチェーンは新しいソリューション パッケージ (*.sppkg) とスクリプト ファイルのセットを生成します。 これらのスクリプト ファイルは、ファイル名に固有のハッシュが含まれています。これは、ファイルの内容が以前に展開されたバージョンと異なることを示しています。 新しいバージョンのソリューションを使用するには、一連の新しいスクリプトを CDN に展開し、アプリ カタログのソリューション パッケージを更新する必要があります。 理論的には、既存のスクリプト ファイルの内容を置き換えてソリューション パッケージのアップグレードを避けることができますが、信頼性が低く、推奨されません。 CDN の構成によっては、以前にダウンロードされたスクリプト ファイルがクライアント コンピューターで長時間キャッシュされ、ソリューションのエンド ユーザーへのロールアウトが複雑になる可能性があります。

CDN の場所は重要です。 SharePoint Framework のアセットがホストされる場所には高可用性が必要であるため、信頼されている CDN プロバイダー (Azure や Akamai に類するものや、SharePoint そのもの) をお勧めします。 セキュリティの観点から、展開されている SharePoint Framework ソリューションで使用されている CDN の種類を把握しておくことが重要です。 CDN が破損すると SharePoint Framework ソリューションも破損する可能性があり、最悪のシナリオでは、CDN の問題によって SharePoint (Online) テナントのデータにも問題が波及する可能性があります。

サード パーティの SharePoint Framework ソリューションを承認する際の一般的なチェックリスト項目として、CDN の場所およびそれをホストする可能性があるサード パーティの権限と信頼のチェックがあります。 アプリケーションを SharePoint サイト コレクション内にインストールして使用した後には、これらのサイト コレクションに CDN の場所との依存関係が生成されるためです。 この記事の執筆時点では、簡単にそのエンド ポイントを制御する方法はありません。 SharePoint Framework がユーザー コンテキストの下で実行されていて、ユーザーにできることなら何でも行えるとしたら、ユーザーが気付かないうちに CDN のサード パーティ プロバイダーが、必要な変更と不要な変更の両方によって更新を行う可能性があります。

どんな CDN が使用され、どんな CDN が組織によって承認されるかを IT 管理者が追跡することが勧められています。また、それらをエンタープライズの開発者に伝える必要もあります。

Microsoft 365 Public CDN

Microsoft 365 Public CDN は、Microsoft 365 と SharePoint Online の新機能です。管理者はこの機能を使用して、CDN の JavaScript ファイル、イメージ、CSS スタイルなどの静的アセットを自動的にホストして、パフォーマンスを向上させることができます。 Microsoft 365 Public CDN は、静的アセットを要求するエンド ユーザーのブラウザーの近くにアセットを維持する地理的分散キャッシュ機能です。

管理者は 1 つ以上のドキュメント ライブラリで Microsoft 365 Public CDN 機能を有効にすることができます。これは静的アセットの起点として機能します。 ライブラリと CDN の管理は、SharePoint Online PowerShell コマンドレットを使用して行われます。 ドキュメント ライブラリ内のアセットは、Microsoft 365 CDN にレプリケートされ、生成されてドキュメント ライブラリと関連付けられる Microsoft 365 Public CDN URL からアクセスできます。 アセットに対する更新は 15 分以内に CDN のエンドポイントに反映されます。 ドキュメント ライブラリ内のアセットはいずれも、匿名ユーザーが CDN のエンドポイント経由で使用できます。

エンタープライズ内の SharePoint Framework

SharePoint は、最も成功を収めているエンタープライズ コラボレーション プラットフォームの 1 つであり、これまでもそうでした。その成功の理由の 1 つとして、SharePoint の拡張オプションや、アプリケーションと統合のプラットフォームとして使用できることが挙げられます。 SharePoint Framework は、さらに成功を拡大していきます。これは、サポートされ標準化された方法でクライアント側のカスタマイズをビルドするために、SharePoint をさらにモダンなプラットフォームにすることで実現します。

エンタープライズ開発者

SharePoint Framework を使用すると、エンタープライズ開発者 (通常は組織内で使用するアプリケーションを作成する開発者) が、構造化されサポートされている方法で SharePoint (Online) に新機能を付与して拡張できるようにします。 SharePoint Framework は、開発フレームワークやビルド パイプラインから実際の展開までのすべてのものを提供し、開発者が短時間で新しいソリューションや機能を含むすべてのサイト コレクションに到達できるようにします。そのすべてはアプリ カタログによって管理されます。 エンタープライズのシナリオでは、SharePoint の内外を問わず CDN の場所を完全に制御することもできるため、組織全体に修正プログラムや更新を簡単に展開できます。

エンタープライズ内の管理者と開発者が合同で、SharePoint Framework ソリューションを展開する方法に関する青写真を作成する必要があります。 青写真には、優先されるクライアント側のフレームワークや CDN の場所などの詳細を含める必要があります。

詳細については、「SharePoint Framework カスタマイズに関する計画のビルド」のセクションを参照してください。

市民開発者

長い間、市民開発者は、SharePoint を使用し、多くの方法やテクニックを利用してアプリケーションをビルドしてきました。

シナリオによっては (特に JavaScript の埋め込みやスクリプト エディター Web パーツのソリューションの場合)、SharePoint Framework が 1 つの良い方法として勧められています。 時間の経過とともに、これらのソリューションが標準化され、保守容易性が改善されてきました。 市民開発者は、構造化されたこの新しいソリューション ビルド方法に合わせて調整することを少し難しく感じるかもしれませんが、長期的に見ると、より安定性があり、安全で、保守が簡単であることに気付くことでしょう。

前述のカスタム スクリプト制御方式を実施する場合、市民開発者には、任意の JavaScript コードまたはスクリプト エディター Web パーツを追加することが許可されません。 これにより SharePoint 環境の安定性と保守容易性が向上する可能性はありますが、同時に会社の革新を妨げることにもなり得ます。それで、SharePoint Framework の使用に関して市民開発者がエンタープライズ開発者とこれからも協調するようにする必要があります。

ユーザー エクスペリエンス デザイナーとフロント エンド開発者

Web 開発者やユーザー エクスペリエンス/インターフェイス デザイナーにとって、SharePoint Frameworkは重要です。 架空データを使用し、ユーザー エクスペリエンスに重点を置く場合、フロントエンド開発者はワークベンチを使用することで、任意のオペレーティング システムで好みの編集ツールを使用して、SharePoint を使わずに SharePoint Framework ソリューションで作業することができます。

SharePoint Framework は、Office UI Fabric と並行してリリースされています。これは Office および Microsoft 365 の公式フロントエンド開発フレームワークであり、これを使用することでユーザー エクスペリエンス デザイナーは、Office、Microsoft 365、およびカスタム組み込みソリューションでのシームレスなエクスペリエンスの作成が可能になります。

システム インテグレーター (SI)

システム インテグレーター (SI) またはコンサルタント企業を利用して SharePoint および Microsoft 365 ソリューションをビルドする場合、SharePoint Framework のエンタープライズの計画と合うよう、SharePoint Framework ソリューションのビルド方法について推奨事項や要件を定める必要があります。

通常、システム インテグレーターはソリューションの好みのビルド方法を持っていますが、それは必ずしもガバナンスと一致するとは限りません。そのため、システム インテグレーターとのこの話し合いは重要であり、最終的にはすべての関係者にとって益となります。

システム インテグレーターに関する一般的なシナリオは、システム インテグレーターが企業のソリューションをビルドし、プロジェクトが完成した後は、管理者がソリューションを保守、アップグレード、更新するというものです。これは、SharePoint Framework ソリューションのビルドおよびホスト方法に関して SI と調整する必要があることを強調しています。

独立系ソフトウェア ベンダー (ISV)

独立系ソフトウェア ベンダー (ISV) は、大量市場向けにサード パーティ ソリューションをビルドする組織であり、常に SharePoint Framework ソリューションに関する貴社の計画を実現するとは限りません。 また、ISV は通常、その独自のコードと知的財産を所有しているため、ISV がソリューションを実装してホストする方法を貴社が変更することは困難です。

サード パーティ プロバイダーからの SharePoint Framework ソリューションを使用する場合、ISV による更新の管理方法およびソリューションをホストする方法を特に検討する必要があります。 たとえば、知らないうちにソリューションが更新されてもよいでしょうか。 貴社の制御なしで ISV の CDN で静的アセットがホストされるようにしますか。 この ISV との信頼関係はどのようなものですか。

SharePoint Framework のクライアント側のコードはいずれも現在のユーザー コンテキストの下で実行されること、およびそれに対して制約を設けることはできないこと (これは SharePoint アドインによって行える) を覚えておいてください。

SharePoint Framework カスタマイズに関する計画を作成する

SharePoint Framework を SharePoint (Online) インスタンスを拡張するツールの 1 つとして導入する場合、その計画を作成する必要があります。 計画は、SharePoint Framework ソリューションをビルドするときに使用する新しいテクノロジ スタックを導入することから始めます。 開発者は、SharePoint Framework コードを記述する主言語として TypeScript を使用するトレーニングを受ける必要があるかもしれません。

SharePoint Framework 開発者が学ぶ必要がある別の側面は、SharePoint Framework の実際のツールチェーン (Node.js、NPM、Gulp など) と、さまざまな Gulp タスクを使用してソリューションをビルド、パッケージ化、展開する方法です。 これを始めるための良いリソースが SharePoint Framework の公式マニュアルまたは SharePoint GitHub リポジトリです。

開発者は、組織用に 1 つの特定のクライアント側のフレームワークで、またはさまざまなフレームワークで標準化することができます。 クライアント側フレームワークには、React、Knockout、Angular、Handlebars、jQuery などがありますが、これらに限定されません。1 つのフレームワークでの標準化には利点があります。これにより、開発者はより再利用可能なコードを構築でき、ソリューションの構築と保守方法の整合性が向上します。

複数のフレームワークを許可することにも利点があります。各クライアント側のフレームワークには良い点と悪い点、および用途があるからです。 しかし、クライアント側のフレームワークを許可すると、エンタープライズ ソリューションに断片化が生じる可能性があります。複数の異なるフレームワークがあると、ページの読み込みに時間がかかることは言うまでもありません。多くのフレームワークで必要になる外部ライブラリの読み込み量が増えるからです。

すぐに使用できる SharePoint Framework Yeoman ジェネレーターには、クライアント側の 2 つのフレームワーク (React、Knockout) のテンプレートが用意されています。 いずれは、他のクライアント側のフレームワークを使用するためにコミュニティがジェネレーターまたはサブジェネレーターを追加することが期待されるようになるかもしれません。 React をクライアント側のフレームワークとして優先的に選択することには利点があります。Microsoft によって Office UI Fabric の React バージョンが作成されているからです。それが貴社が希望するものであれば、Office と Microsoft 365 のカスタマイズの外観がわかります。

4 番目の点は、ソリューションの成果物を展開する方法と展開する場所です。つまり、生成したスクリプトのバンドルとアセットをどの CDN に保管するかです。 ツールチェーンに含まれている、すぐに使用できる Gulp タスクでは、Azure Blob ストレージと Azure CDN だけがサポートされています。 Azure サブスクリプションを管理でき、アセットを複数のテナント間で共有する場合、これは良いオプションかもしれません。 一般的な別のシナリオは、SharePoint Online とその CDN 機能を成果物のホストとして使用することです。 SharePoint Framework v1.4 以降、静的アセットは既定で SharePoint Framework パッケージにパッケージ化されています。 このパッケージがアプリ カタログ内に展開されると、Microsoft 365 CDN (有効な場合) またはアプリ カタログ URL から自動的にホストされます。

最後に、開発者はアプリケーション ライフサイクル管理 (ALM) について考える必要があります。ソース コードとバージョン管理、自動ビルド、テスト、デプロイなどを管理する方法について考える必要があります。 Git、GitHub、Visual Studio Team Systems など、最も一般的なソース コードバージョン管理システムを使用できます。

継続的な統合のための既定のツールはなく、node.js をサポートしているツールであれば、好みのものを使用できます。たとえば、Visual Studio Team Systems、Travis CI、Jenkins などがあります。 これらのツールを使用することで、ビルド プロセスとテスト プロセスを自動化することができ、ビルドが成功して承認された場合は、成果物を CDN の場所に展開することさえできます。そのようにして、開発者によるコードのチェックから運用への展開に至るすべてを自動化することができます。

SharePoint Framework ソリューションの管理機能

テナントに展開する SharePoint Framework ソリューションは、テナント管理者によって承認される必要があります。 これを行うには、SharePoint Framework パッケージ *.sppkg ファイルを Apps for SharePoint ライブラリにアップロードします。 新しいソリューションがライブラリに追加されると、ソリューションをテナントで使用することについての承認の同意を求めるダイアログが管理者に対して表示されます。 ダイアログは、これがリソース制限のないクライアント側の完全信頼コード ソリューションであること、およびユーザー コンテキストの下で実行されることを説明します。 また、どのドメインから主にコンテンツを取得するか、つまり、SharePoint Framework スクリプトの CDN の場所も示します。 最初に CDN から読み込んだ後、SharePoint Framework アプリケーションは他の場所からもデータを読み込めるようになります。 承認された後、SharePoint Framework ソリューションを任意のサイト コレクションで有効にできます。

SharePoint Framework アプリ カタログの信頼ダイアログ

アプリ カタログの管理者は、SharePoint のアプリ ライブラリからソリューション パッケージを削除することで、アプリ カタログからいつでもパッケージを削除できます。 これにより、ソリューションが特定のサイト コレクションで使用されないようにすることができます。 アップロードするパッケージの [有効] プロパティを変更することで、ソリューションを無効にすることもできます。 これにより、すべてのサイト コレクションのソリューションがすぐに無効になります。クライアント側の Web パーツを使用する既存のページは Web パーツを表示せず、サイト コレクションを使用できず、既存のサイト コレクションでの追加も行えません。 SharePoint Framework ソリューションを削除するときには、実際のクライアント側のソリューションによって作成されるデータや情報は、SharePoint にあるものも、ソリューションによって使用されるいずれかの外部データ ソースにあるものも、削除されません。

管理者は、サイト コレクションのソリューションの可視性を強化するために、アプリ カタログ内のパッケージの他のプロパティを変更することもできます。たとえば、アイコン、カテゴリ、説明、および主な状態を変更できます。

ソリューション パッケージの更新が必要な場合 (新しい SharePoint Framework 成果物またはその他のパッケージ レベルの変更が行われた場合に必要)、管理者が行う必要があるのは、パッケージの新しいバージョンをライブラリにアップロードすることだけです。

テナント管理者は、SharePoint アドインで行うのと同様に SharePoint Framework ソリューションをモニターすることもできます。SharePoint 管理センターのアプリの下で、SharePoint 管理者は SharePoint Framework ソリューションを追加した後、SharePoint アドインと SharePoint Framework ソリューションの両方について、特定のソリューションがインストールされている場所がいくつあるか確認できます。

サイト コレクションで SharePoint Framework ソリューションを有効にするには、サイト コレクション管理者がそれをサイト コレクションに追加する必要があります。 これは、サイト コレクションで [新しいアプリの追加] を選択した後、アプリの一覧からソリューションを選択することで、SharePoint アドインの場合と同じように行います。 アプリが追加されると、サイト コレクションで使用できるようになります。 サイト コレクションの管理者は、サイト コレクションから SharePoint Framework を削除することもできます。 これは、[サイト コンテンツ] に移動して、アプリで [削除] を選択することによって行います。

SharePoint Framework の展開範囲

SharePoint Framework ソリューションを構築する場合、開発者はソリューションがテナント全体の展開をサポートするか、またはソリューションを各サイトに個別に展開する必要があるかを選択できます。 後者は、ソリューションがサイトに展開された後にリストなどの追加リソースを用意しなければならない場合に必要です。

ソリューションを構築する開発者は、ソリューションがテナント全体の展開をサポートするかどうかを決定しますが、ソリューションの展開方法について最終決定するのは管理者です。 テナント内のすべてのサイトにソリューションを展開できるとしても、管理者はソリューションを特定のサイトにだけ展開することを選択できます。 ソリューションがテナント全体の展開をサポートしていない場合、管理者は特定のサイトにだけ展開できます。

重要

テナント全体の展開は SharePoint Online でのみ可能です。 SharePoint ホスト型オンプレミスでは、SharePoint Framework ソリューションは特定のサイトにだけ展開できます。

SharePoint Frameworkには、SharePoint アドインが持つストアがありません。 このため、ソリューション パッケージをアプリ カタログに追加して承認することで、テナント管理者が常にデプロイを開始する必要があります。

SharePoint Framework コンポーネントをバックアップおよび復元する

SharePoint Framework ソリューションには、固有のバックアップ機能と復元機能がありません。 管理上の観点から推奨される唯一の点は、ソリューション パッケージが誤ってアプリ カタログから削除された場合は、インストールされているすべてのソリューション パッケージ ファイル (*.sppkg) のコピーを作成することをお勧めします。 ただし、アプリ カタログは SharePoint ライブラリであり、ドキュメント ライブラリと同じ機能があります。さらに、メジャー バージョン管理機能がオンになっていて、ごみ箱があります。

バックアップできないのは、スクリプト バンドルやアセットなど、CDN でホストされている実際のソリューション成果物です。 CDN を制御することができ、CDN が SharePoint サイトである場合には、バックアップできます。 サード パーティによって提供されている SharePoint Framework ソリューションを使用している場合、組織にはバックアップする方法がないかもしれません。

SharePoint Framework のロードマップ

SharePoint Framework は、2017 年 2 月に一般提供 (GA) されました。 一般提供とは、IT と開発者が、サポートされた状態で SharePoint Framework を運用環境で使用できるようになることです。 一般提供に到達した後、SharePoint Framework ベースのコンポーネントがビルドされて使用されるシナリオのセットが、Web パーツのシナリオを超え、リストやサイトのカスタマイズの領域にまで広がることを期待しています。

SharePoint Framework の詳細については、「SharePoint Framework のロードマップ」を参照してください。

主な変更または主な新機能の導入については、Microsoft 365 管理者は既に毎日チェックしているとは思いますが、テナント管理の Microsoft 365 メッセージ センターから通知されます。 別の重要なリソースは Office Developer ブログです。このブログには、さらに詳しい詳細や更新が投稿されます。

サポートと SLA

Microsoft は、通常の SharePoint Online サポート チャネルを通じて SharePoint 用に作成されたカスタム ソリューションに対して、サポートを提供していません。 SharePoint ソリューションの構築に関連するすべての問題は、https://github.com/SharePoint/sp-dev-docs/issues の GitHub に記録する必要があります。 SharePoint エンジニアリング グループはこのレポジトリに記録された問題に対して定期的にトリアージを行い、送られてくる要求に対して可能な限り早く対応するよう努力しています。

組織にプレミア サポート契約がある場合、これが SharePoint ソリューションの構築に関連する問題のサポートを要求するときの既定のチャネルとなります。 Microsoft のエスカレーション エンジニアは、緊急度に応じて、要求を処理します。

SharePoint Framework は、下位互換性を持つように設計されています。 Microsoft は、一般的に使用できる SharePoint Framework のバージョンのいずれかを使って構築されたソリューションが稼働し続けることを、そのバージョンの明示的な非推奨に関する通知がなされるまで保証します。

概要

SharePoint Framework は、SharePoint カスタマイズ ツールボックスに対して新たに大きな改良を加え、進化させたものです。開発者はこれを使用して、サポートされる制御可能な方法で SharePoint を拡張できます。 オープン ソースと最新のテクノロジに基づく SharePoint Framework によって、開発者は SharePoint エンタープライズ開発ストーリーを SharePoint チームだけでなく、より多くのさまざまな開発者にも広げることができます。 管理者は、適切なガバナンスやサポートをテナンシー内の SharePoint Framework に提供することで、開発者がより魅力的なソリューションを短時間でビルドできるようにすることができます。結果として、全体的な効率の向上につながります。

SharePoint Framework はファースト パーティとサード パーティの開発者用に作成されており、SharePoint の将来の機能拡張を見こして Microsoft はその使用頻度を増やしているので、貴社にとっての安全策でもあります。 従来の SharePoint と新しい SharePoint のエクスペリエンスの間の将来のギャップを埋めるために、今後 SharePoint Framework に対してますます更新や改良を加えていきたいと考えています。