機能のロールアウト

新製品や機能は、これらのクラウド プラットフォームに段階的に導入されます。一般に、新機能は最初に Test Cloud で利用可能になり、その後 Test Cloud (公共部門向け) と Test Cloud (専有型) で利用可能になりますが、コンプライアンス、インフラストラクチャ、リリースの準備状況の要件が適用されます。そのため、使用するクラウド プラットフォームによって可用性が異なる場合があります。

機能のロールアウト Test Cloud

更新が利用可能になるタイミング

Test Cloud のリリース ノートで発表する更新内容は次の項目に応じて段階的に利用可能になります。

• ライセンス プラン
• 組織とテナントの リージョン

そのため、更新内容が利用できるタイミングはユーザーによって異なります。

リリース ノートで変更が最初に告知される日付は、その機能が最初に利用可能になる日付です。ご自身の環境で変更がまだ確認できなくても、すぐに確認できるようになります。

Community リリース: 変更はまず、Community ユーザーに対して利用可能になります。リリース ノートはこのタイミングで公開されます。

Enterprise リリース: Enterprise ユーザーは、Community のデプロイ後 1 時間から 14 日以内にデプロイを利用できるようになります。機能によっては、Enterprise で利用可能になるまでに長時間を要することがあります。 テストに利用するカナリア テナントには、通常、発表の 3 日後に更新が提供されます。選択したホスティング リージョンでこれらの変更にアクセス可能になる正確な時間は、変更がすべてのリージョンにいつ正常にデプロイされたかによって異なります。

Enterprise リリースの公開や、他のリージョンでの公開のタイミングであらためて告知を行うことはありません。

次の表は、Enterprise ユーザーだけでなく Community ユーザーも機能を利用できるようになるタイミングの例です。

リリース ノートの日付	Community プランでの公開日	Enterprise プランでの公開日
2025 年 7 月 14 日	2025 年 7 月 14 日	2025 年 7 月 14 日以降

Enterprise のみに適用される変更

変更が Enterprise プランにのみ適用される場合は、リリース ノートではその変更内容を Enterprise ラベル () を使用して区別します。このような変更は、最初の公開のタイミングで Enterprise プランおよび Enterprise 無料トライアルのユーザーに直接提供されます。変更はリリース ノートの日付と同じタイミングで反映されますが、お使いのリージョンで利用可能になるまでに数日かかる場合があります。

次の表は、Enterprise ユーザーのみが機能を使用できる場合の例です。

リリース ノートの日付	Community プランでの公開日	Enterprise プランでの公開日
2025 年 7 月 14 日	N/A	2025 年 7 月 14 日以降

遅延更新組織

この機能は、Advanced Tier ライセンスを持つ企業ユーザーが利用できます。

詳細については、UiPath のセールス チームにお問い合わせください。

ユーザーの組織が遅延更新リージョンでホストされている場合、Test Cloud とそのサービスが、前述のルールの対象となる他のエンタープライズ組織にデプロイされた少なくとも 2 週間後に、ユーザーのリージョンでも利用可能になります。

各ユーザーのホスティング リージョン内の更新遅延組織で変更が利用可能になるまでの正確な日数は、全リージョンへの変更のデプロイが完了するタイミングに応じて、14 日をわずかに超える場合があります。

通常のエンタープライズ組織を実稼働前環境として更新のテストに使用し、更新遅延組織を運用環境として使用できます。 エンタープライズ組織で更新内容が利用可能になってから約 2 週間後に更新遅延組織にも変更が反映されます。

リージョン

遅延更新機能は 、米国 および 欧州連合 (EU ) のホスティング リージョンでのみ利用可能です。

更新遅延の恩恵を受けるサービス

UiPath サービスは、米国または欧州連合 (EU) では遅延更新をサポートする場合があります。これらのリージョンで遅延更新をサポートしているサービスを確認するには、「 グローバルなクラウド リージョン 」のページをご覧ください。

ステータス ページ

すべての UiPath® サービスの稼働時間、定期メンテナンス期間、またはインシデントの最新情報については、ステータス ページをご覧ください。

機能のロールアウト Test Cloud (公共部門向け)

Test Cloud (公共部門向け) の新機能や更新内容の導入に対する UiPath のアプローチは、シームレスかつ効果的に移行できるように設計されています。

みどころ

1. リリース ノート: 新機能や更新内容の開発とテストが完了したら、リリース ノートで告知します。これらのリリース ノートには https://docs.uipath.com/ja/ からアクセスできます。
2. 透明性: UiPath のリリース ノートは、透明性と情報を提供するように設計されています。新機能の内容と、既存の機能にもたらされる変更について詳しく説明します。
3. タイミング: リリース ノートの公開後まもなく、新機能や機能更新がユーザーに表示されます。具体的なタイミングは、機能や更新の複雑さによって異なる場合がありますが、公開後にできるだけ早くアクセス可能な状態にすることを目指しています。

すべての UiPath® サービスの稼働時間、定期メンテナンス期間、またはインシデントの最新情報については、ステータス ページをご覧ください。

機能のロールアウト Test Cloud (専有型)

Test Cloud (専有型) の主なメリットの 1 つは、アップグレードを制御できることです。重要な UiPath アプリケーションを更新するための特定の要件を満たしており、次のような重要な側面について活用できます。

• プラットフォームと UiPath サービスが更新され、ビジネスの中断を防ぐスケジュール設定を行います。たとえば、年末年始などの繁忙期に更新を回避できます。
• プラットフォームに新機能をデプロイするスケジュールを決定する。これにより、テスト環境と運用環境の両方でオートメーションと新機能の検証を計画できます。

リリース プロセス

このページでは、リングに基づくデプロイ モデルを使用して、Test Cloud (専有型) の環境間で更新がどのように配信、制御、伝達されるかについて説明します。

リリースの概要

Test Cloud (専有型) のリリースは 2 週間ごとに行われます。各スプリントは、新機能と拡張機能、セキュリティ パッチ、インフラストラクチャ、構成の更新、バグ修正を含むペイロードを提供します。

すべての更新は、サービスのデプロイ計画によって管理されるリングベースのロールアウト戦略に従います。

ロールアウトのスケジュールと環境

Test Cloud (専有型) のデプロイ ライフサイクルには、次のコンポーネントが含まれます。

• リリース周期 – リリースは 2 週間に 1 回のスケジュールに従います。各スプリントには、新機能、改良点、セキュリティ パッチ、バグ修正などの累積的な更新プログラムが含まれています。
• リングベースのロールアウト – リリースは複数の環境で順番に進められます。Sandbox が最初の環境になります。それ以降の環境は、希望するスケジュールとデプロイ アーキテクチャによって異なります。Sandbox 環境は、更新の事前検証に使用できる共有インスタンスです。リリース ノートはこのタイミングで公開されます。
  注:

  ロールアウト フローには、ブラックアウト ウィンドウとフリーズ期間は含まれません。

リリースの種類

Test Cloud (専有型) には、次の 2 種類の更新が用意されています。

• 標準リリース: 製品、インフラストラクチャ、構成を 2 週間ごとに定期的にデプロイし、更新します。
• 修正プログラムのリリース: セキュリティの脆弱性または影響の大きいバグの緊急修正。

修正プログラムと緊急リリース

優先度の高い修正の場合、デプロイのライフサイクルは以下の例外に従います。

• リリースは、すべてのリングで迅速に追跡されます。
• 呼び出し音の遅延、メンテナンスウィンドウ、およびブラックアウトウィンドウは、緊急性に基づいてバイパスされる場合があります。
  注:

  修正プログラムの対象となるのは、Test Cloud (専有型) での以前の動作からの回帰のみです。

アップグレード コントロール

Test Cloud (専有型) では、更新をデプロイするタイミングを柔軟に設定できます。以下のアップグレード コントロールの種類を使用して運用環境を構成できます。

• 遅延リリース: 更新を最大 30 日間延期します。
• ブラックアウト ウィンドウ: デプロイを一定期間禁止します。ブラックアウト期間のルールは次のとおりです。
  • 最大 30 日間連続して使用できます。
  • その後、別のブラックアウトが適用される前に、10日間のオープン期間が続く必要があります。
  • 5営業日前までに提出する必要があります。
  • 今後 48 時間以内のデプロイ スケジュールはブロックできません。たとえば、2 日未満で終了するブラックアウト ウィンドウは延長できませんが、終了に 5 日より長くかかるブラックアウト ウィンドウは調整可能です。
• メンテナンス ウィンドウ: アップグレードが営業時間外に実行されるようにします。メンテナンス ウィンドウは通常、東部標準時の午後 3 時から午後 9 時の間にスケジュールされます。すべての運用環境のアップグレードには、6 時間の連続するウィンドウが推奨されます。
  注:

  Sandbox 環境は、ブラックアウト期間とメンテナンス期間から除外されます。

コミュニケーションとユーザーの責任

お使いの Test Cloud (専有型) 組織へのリリースのロールアウト状況を確実に把握するには、以下のリソースを確認する必要があります。

• リリースノート: Sandbox 環境がアップグレードされるのと同じ日に公開されます。
• ステータス ページの通知: 少なくとも 7 日前に通知するダウンタイムに使用されます。

Test Cloud (専有型) ユーザーは、次のことを行う必要があります。

1. リリース ノートとステータス ページの更新を定期的に確認してください。
2. 公開後にリリース ノートを確認します。
3. サンドボックスおよびその他の承認された環境で変更を検証します。
4. 回帰やパフォーマンスの問題が見つかった場合に、サポート チケットをオープンして運用リリースを一時停止します。

ロールアウトの例

たとえば、スプリント リリースが 7 月 7 日にサンドボックスにデプロイされ、運用環境の遅延が 30 日の場合、タイムラインは次のようになります。

1. Sandbox のアップグレードは 7 月 7 日に実行されました。
2. リリース ノートは 7 月 7 日に公開されました。
3. 生産アップグレードは8月9日に実施されました。

アップグレード制御について

次の 2 種類のコントロールがあります。

1. リリースの遅延: これにより、更新を最大 30 日間延期できます。
2. ブラックアウト期間: 最大 30 日間のブラックアウト期間で、特定の期間は更新が行われないようにします。

Test Cloud の組織を常に最新の状態に保つため、以下の制限を設けました。

• ブラックアウト期間は30日間しか継続しません。これは、年末のニーズに合わせて 30 日間の凍結期間に対応するためです。
• 各ブラックアウト ウィンドウの後には少なくとも 10 日間の休憩を挟む必要があります。これにより、ブラックアウト ウィンドウが長引いた後に UiPath が更新プログラムをロールアウトするための十分な時間を確保できます。
• ブラックアウト期間の変更は、変更予定の5営業日前までにチケットで提出する必要があります。
• 以前はブロックが解除されていた時間が 48 時間以内にブロックされるような変更を実装することはできません。

次のセクションでは、これらのガイドラインの理解を深めるのに役立ついくつかの例について説明します。

• 5 日後に終了するブラックアウト ウィンドウにいる場合は、新しい期間をブロックしないため、このウィンドウを延長または短縮できます。
• ブラックアウト期間が 1 日で終了すると、翌日がブロックされるため、延長することはできません。
• 現在のブラックアウト ウィンドウがなく、1 日後に開始されるブラックアウト ウィンドウを設定したい場合、そのようなウィンドウは作成できません。

アップグレード制御の管理

Test Cloud で利用可能な両方のアップグレード コントロールを設定するには、 サポート チーム に連絡してサポート チケットを提出する必要があります。