セキュリティを確保し、最新の機能を利用するには、オペレーティング システムを頻繁に更新することが重要です。デフォルトでは、ChromeOS は約 4 週間ごとに Stable チャンネル（Stable）に OS のフル アップデートをリリースします。セキュリティ修正やソフトウェア アップデートなどのマイナー アップデートは 2 ～ 3 週間ごとにリリースされます。デベロッパーは、新しい安定版がリリースされる前に、デベロッパー（Dev）チャンネルまたはベータ（Beta）チャンネルでアプリケーションをテストして、アプリが正常に動作することを確認できます。Dev チャンネルのアップデートは週 1 ～ 2 回行われ、Chrome チームが現在取り組んでいる内容を確認できます。このビルドにはバグが含まれている可能性がありますが、Stable 版に追加予定の機能を 9 ～ 12 週間前からプレビューできます。Beta チャンネルでは、Stable 版で提供予定の新機能を 4 ～ 6 週間前にプレビューできます。
ただし、これらの既存のチャンネルで毎月テストを行うと、システム管理者やデベロッパーが対応しきれない可能性があります。サポートを強化し、テスト期間を延長するため、ChromeOS 向けに長期サポート チャネルを含む新しい長期サポート プランを作成しました。
長期サポート リリース
ChromeOS の長期サポート リリースは、組織内のデバイスの管理にかかる労力を軽減し、すべての OS アップデートでアプリが正常に動作することを保証する強力なツールです。管理者とデベロッパーは、これらの機能に精通し、導入する組織に優れたエクスペリエンスを提供する必要があります。
ChromeOS では、長期サポート候補（LTC）リリースと長期安定版（LTS）リリースの 2 つの長期サポート リリースが提供されています。
- 長期サポート候補（LTC）- 次の LTS バージョンのベースとして使用され、LTS の 3 か月前に Stable から切り離されます。これにより、管理者はプレビューで準備を進めることができます。
- 長期サポート チャンネル（LTS） - 6 か月ごとに更新されます。リリース サイクルが最も長く、通常の安定版チャンネルの代替として使用されます。テスト目的で LTC を使用する必要がある一部のユーザーを除き、組織全体で長期サポート リリースを採用する場合は、ほとんどのユーザーが LTS を使用する必要があります。
Stable、LTC、LTS のリリース タイムライン
LTC / LTS のライフサイクルは次のようになります。
- LTC リリース（図の 108 LTC）は安定版リリース（108 Stable）から切り離されるため、最初の 1 か月間は両者が同一です。
- LTC には、次の LTS リリース（図の 108 LTS）までの 3 か月間、2 週間ごとにセキュリティ修正が適用されます。つまり、最初の LTC リリースから 3 か月後に、LTC は LTS を反映します。
- LTS がリリースされると、2 週間ごとにセキュリティ修正が適用されます。
- LTS のリリース後も LTC を使用しているデバイスには、引き続き 2 週間ごとにセキュリティ修正が適用され、次の LTC リリースがカットされると自動的にアップデートされます。
オペレーティング システムの機能とバグの修正に加えて、ファームウェア アップデートもデバイスの自動更新の有効期限（AUE）まで LTS リリースにバンドルされます。
どちらのチャンネルも有効にするには、Google ドメインと管理対象デバイスが必要です。Chrome Enterprise Upgrade の試用版に登録すると、Google 管理コンソールにアクセスして、管理対象 Chromebook を設定、デプロイできます。最後に、管理コンソールから管理対象デバイスを LTS チャンネルまたは LTC チャンネルに切り替えます。ほとんどのデバイスで LTS チャンネルを使用し、LTC を使用して今後の LTS リリースをテストすることをおすすめします。
LTC / LTS のテスト ワークフロー
LTC と LTS は、安全なオペレーティング システム エクスペリエンスを確保しながら、管理者のテスト作業を大幅に削減するように設計されています。システム管理者とデベロッパーを長期サポートのライフサイクルに沿って調整するには、次のことを行う必要があります。
- 次期 LTC チャンネルのリリースに対応する安定版リリースに先立ち、Dev と Beta でテストします。
- LTC がリリースされたら、適用されたセキュリティ修正が LTS がカットされるまで作業に影響しないことを確認するために、LTC でテストします。
- LTC が LTS に昇格すると、LTS には引き続き 2 週間ごとにセキュリティ修正が適用されます。これらもテストする必要があります。
ライフサイクル図を参照すると、次のようになります。
- 108 LTC のカットオフ元となる 108 Stable のリリースに先立ち、108 Dev と 108 Beta でテストを開始して、すべてが正常に動作することを確認します。
- 最初のカット日から 3 か月後に 108 LTS がリリースされるまで、2 週間ごとに 108 LTC でテストします。
- セキュリティ修正によって問題が発生しないように、LTS で定期的にテストを続行します。
LTC/LTS バージョン間の変更を管理する
ChromeOS の長期サポート バージョンを採用する場合でも、採用している組織と連携する場合でも、バージョン間の変更を適切に管理することが重要です。新しいプラットフォーム機能に基づいて機能を追加することも、後のバージョンで非推奨になった機能に依存することもできます。また、特定のバージョンのアプリの特定の機能に依存している場合や、ユーザーが実行するバージョンを選択できるようにしたい場合もあります。アプリケーションへのシームレスなアクセスを確保するには、アプリの下位互換性を確保するか、バージョンごとに個別のインスタンスを提供するか、またはその両方を行う必要があります。
下位互換性を確保する
下位互換性により、アプリケーションの新しいバージョンをプラットフォームの古いバージョンで実行できます。これを行うには、新機能を使用する前にその機能が利用可能かどうかを確認する機能検出という手法を使用します。存在する場合はそれを使用し、存在しない場合はフォールバックを任意で指定します。この手法の一般化されたバージョンはフィーチャー フラグと呼ばれます。この手法では、機能が有効になっているかどうかに応じてコードパスが読み込まれます。機能が有効になっているかどうかは、機能の可用性、アプリまたはユーザーレベルの構成によって決まります。この手法は、Android アプリ、Chrome 拡張機能、ウェブアプリのすべてにメリットがあります。アプリの新しいバージョンに下位互換性があることを確認することで、すべてのユーザーに対して 1 つのアプリケーションを管理できます。
コンピューティング負荷の高いアニメーションを提供しようとしているウェブアプリでは、WebGPU をサポートするブラウザ向けに WebGPU を実装し、利用できない場合はよりシンプルな JavaScript を使用したアニメーションにフォールバックすることが考えられます。そのため、次のような操作を行うことがあります。
if ('gpu' in navigator) { // WebGPU is supported! Accelerate computation. } else { // No WebGPU, fallback to JavaScript implementation. }
別のインスタンスを提供する
バージョン間の違いが大きすぎて、下位互換性の手法では対応できない場合があります。機能の違いが大きすぎる場合や、メイン アプリケーションとは別の長期サポート バージョンが必要になるビジネス上のニーズがある場合があります。この場合は、バージョンごとに個別のインスタンスを提供することを検討してください。この方法では、ユーザーが特定のバージョンのアプリを使用することが保証されますが、運用コストが増加する可能性があります。このソリューションを選択する際は、この点に留意してください。
ウェブアプリの場合、別のインスタンスを提供することは、通常、アプリケーションの異なるバージョンを異なる URL でホストすることを意味します。場合によっては、別のサーバー、データベース、その他のウェブサイト インフラストラクチャが必要になることがあります。Android アプリの場合、これは各バージョンに個別の Play ストアの掲載情報があることを意味します。複数の類似アプリが利用可能になり、ユーザーがどれを選べばよいかわからなくなる可能性があるため、ユーザーの混乱を招く可能性があります。Chrome 拡張機能も複数のリスティングを持つことができます。または、こちらのドキュメントを参照して、Chrome 管理コンソールで必要な Chrome 拡張機能のバージョンを固定するようお客様に推奨することもできます。このドキュメントでは、拡張機能を固定する方法と、固定に関連する注意事項について詳しく説明しています。
ChromeOS ユーザーに長期サポート バージョンのみを提供したい Android アプリは、AndroidManifest.xml ファイルに次の内容を記述して、ChromeOS デバイスにのみ配信されるように指定することで、別のリスティングを作成できます。
<uses-feature android:name="org.chromium.arc" android:required="true" />