ServiceNow の Flow Designer: オーストラリアのリリースで実際に変わるもの

[JunshuO]

ServiceNow の Flow Designer: オーストラリアのリリースで実際に変わるもの

私は、Flow Designer が古いワークフローエディターに取って代わって以来、Flow Designer に取り組んできました。正直なところ、プラットフォームコミュニティがこれを完全に受け入れるまでには時間がかかりました。経験豊富な開発者は、複雑なシナリオでは Flow Designer が少し制限されていると感じたため、静かに Workflow に戻ったり、代わりにビジネスルールを作成したりしていた時期がありました。これは過去数回のリリースで大きく変更され、オーストラリアリリースは、私が予想していたよりも物事を推し進めました。

この記事は、Flow Designer の概要と、アーキテクトや上級開発者にとって重要なオーストラリアのリリースの実際の新機能について、実用的で正直に説明する試みです。私がこれを書いているのは、私自身の認定メンテナンスのためであり、部分的には、実際には、その本質的な意味を説明していない表面的な「新機能」に関する投稿をたくさん見てきたからです。

基本事項: Flow Designer とは何ですか？

ServiceNow を初めて使用される場合、Flow Designer はプラットフォームのビジュアル自動化ツールです。フロー (自動化プロセス) を構築するには、キャンバス上で次の 4 つの構成要素を組み合わせます。

• トリガーは、 フローを開始します。これらは、作成または更新中のレコード、スケジュールされた時刻、または受信 API 呼び出しです。
• アクションは、 レコードの作成、通知の送信、外部システムの呼び出し、スクリプトの実行など、あらゆる作業を行います。
• フローロジックは、 パスを制御します。if/else 分岐、for-each ループ、待機条件などです。
• サブフローは、 コードで関数を呼び出すのと同様に、複数のフローから呼び出すことができるプロセスの再利用可能なチャンクです。

キャンバスはドラッグアンドドロップ式なので、スクリプティングの深いバックグラウンドがなくてもアクセスできます。ただし、「ローコード」を「低電力」と間違えないでください。私は、Flow Designer がマルチシステム統合、並列承認チェーン、SLA 対応ルーティングなど、非常に複雑なエンタープライズプロセスを処理するのを見てきました。

私が一緒に仕事をしているチームにいつも強調していることの 1 つは、再利用性は Flow Designer が与えてくれる最大の贈り物であり、ほとんどのチームはそれを十分に活用していないということです。API コールまたはビジネスロジックをラップしてカスタムアクションを一度ビルドすると、インスタンス全体にわたってすべての開発者のアクションピッカーに表示されます。ロジックが変更されたら、1 か所を更新します。それが約束であり、チームが実際にそれに従えば、メンテナンスの節約は本物になります。ServiceNow 独自の設計考慮事項に関するドキュメントでは、オーストラリアのリリースについて、フローは短く、モジュール式で、再利用可能な作業のコレクションである必要があるという点が強調されています。

IntegrationHub: 他のすべてに接続する場所とは、何ですか？

Flow Designer は ServiceNow 内のものを単独で自動化します。IntegrationHub は、外部の他のエンタープライズシステムに到達できるようにするものです。

スポークライブラリは、ほとんどの組織がすでに使用しているプラットフォーム (Microsoft Teams、Slack、Jira、Salesforce、DocuSign、ServiceNow から ServiceNow など) をカバーしています。各スポークには、事前にビルドされ認証されたアクションステップが用意されているため、毎回 REST 呼び出しを最初から記述する必要はありません。

実際、複雑な環境において Flow Designer が真価を発揮するのはこの点です。最近、ある金融サービスのクライアントと仕事をしたところ、オンボーディングフローが ServiceNow、Jira、Azure AD、Teams に関係し、すべて単一の Flow Designer キャンバスからオーケストレーションされました。ビジネスステークホルダーは実際にフローを読み、フローが何をしているのかを理解できるため、サインオフと変更管理がスクリプトベースのものよりも大幅に簡単になりました。

オーストラリアのリリースで Flow Designer に実際に追加されるものとは、何ですか？

このオーストラリアリリースは 2026 年 5 月に一般提供され、見出しは AI ですが、Flow Designer への具体的な追加機能は、通常の「AI を活用した」マーケティングが示唆するよりも具体的でアーキテクチャ的です。私が実際に重要だと考える点は以下のとおりです。

AI エージェントアクション: これはまさに新しい領域です。

現在、Flow Designer にはネイティブの「AI エージェントの使用」アクションが搭載されています。これは Now Assist がバックグラウンドで提案を生成するものではありません。これは、構成された AI エージェントにデータを渡すファーストクラスのフローステップであり、エージェントの構造化された出力がフローの次のステップにフィードされます。

これでフローは、トリガー、コンテキストデータの検索、AI エージェントの呼び出し、条件付きロジックでの AI 出力の使用、そして結果に基づいたアクションの実行といった流れになります。

私が何度も繰り返し考えている実際的な例は、インシデントのトリアージです。短縮説明、カテゴリ、および最近の類似インシデントをトリアージエージェントに渡します。提案されたアサイン先グループ、信頼スコア、および推奨される解決パスを取得します。信頼性が十分に高い場合は、自動アサインして通知します。十分な信頼性がない場合は、人間によるレビューのためにサービスデスクにルーティングします。

これがアーキテクチャ的に重要なのは、フローロジックが純粋に決定論的である必要がなくなったことです。プロセス全体を構造化され監査可能な状態を維持しながら、AI の推論を活用する意思決定ポイントを設計できます。出力は名前付きフロー変数にマッピングされるため、下流のすべてのステップは、何を取り扱っているかを正確に把握できます。

正直に言うと、これはアーキテクトが検討すべき新しい設計上の課題も提起します。AI ステップが予期しない出力を返すフローをどのように処理しますか？フォールバックはどうしますか？途中に確率的ステップがあるプロセスをどのように監査しますか？これらはこの機能を避ける理由ではありませんが、プロダクション設計における実際の考慮事項です。

自然言語フロー生成: 魔法ではなく、便利な機能です。

オーストラリアリリースのNow Assist for Creator には、わかりやすい英語の説明からドラフトフローを生成する機能が含まれています。「マネージャーの承認を得て、Jira チケットを作成し、Teams を介して要求者に通知するフローを作成する」などのプロセスを説明すると、ステップが計画されたキャンバスのドラフトが表示されます。

私はこれを試しましたが、特に要件について話し合ってから数分以内に利害関係者に具体的なものを示したいワークショップの設定で、すぐに始めるのに本当に便利です。生成されたドラフトは本番環境に対応していません。ほとんどの場合、条件を調整し、エラー処理を追加し、適切な変数を接続する必要があります。しかし、空白のキャンバスからレビュー可能なものになるまでの時間が短縮されます。

チームが注意したいのは、生成された出力を実際よりも完成に近づいているものとして扱うことです。ドラフトには、名前付け規則、スコープ対象のアプリ構造、既存のアクションライブラリ、またはガバナンス要件がわかりません。アーキテクトは、テスト環境に近づく前に、それを適切にレビューする必要があります。

フロー実行分析: これは私が最も楽しみにしているものです。

失敗したフローのトラブルシューティングは、常に必要以上に苦痛でした。実行履歴を取得し、ログを段階的に実行できますが、12のアクションと複数の統合呼び出しを含む複雑なフローで何が原因で失敗したのかを突き止めるには、伝統的に多くの手動トレースが必要でした。

オーストラリアリリースでは、実行履歴の上に AI 支援診断レイヤーであるFlow Execution Analysis が追加されました。フローに障害が発生すると、最も可能性の高い障害ポイントが特定され、考えられる根本原因が説明され、具体的な修復手順が提案されます。

私がこれに心から興奮している理由は、実際の運用コストに対処しているからです。ServiceNow を実行するほとんどの組織には、本番環境でフローをサポートする人員が混在していますが、全員が最初にフローの構築に関与していたわけではありません。「このフローが失敗した」から「修正すべき点とその理由」までの時間を短縮するものはすべて、直接的なビジネス価値を持ち、私の経験では、その時間は歴史的に必要以上に長くなってきました。

また、引き継ぎドキュメントに対する私の考え方も変わります。プラットフォーム自体がフローが失敗した理由とそれに対する対処法を説明できれば、フローを知る人がいない本番環境での障害という最悪のシナリオは、壊滅的になる可能性が大幅に低くなります。

ネストされたプレイブック: 静かなアーキテクチャの勝利です。

これは Flow Designer に隣接していますが、言及する価値があります。オーストラリアのリリースでは、ネストされたプレイブックが導入されています。つまり、プレイブックを別のプレイブック内で使用できるようになりました。詳細については、ServiceNow コミュニティプレイブックのリソースページをご覧ください。これを使用するには、子をスタンドアロンプレイブックとして作成し、ネスト可能としてマークして、親から参照する前にアクティブ化します。

このパターンは、Flow Designer のサブフローが提供する再利用性や、複雑なガイド付きプロセスの分解と同様のメリットをもたらします。それ以前は、大規模なプレイブックは扱いにくくなり、複数のプロセスバリアントにわたるメンテナンスが困難でした。これで、共通セグメントをファクタリングして適切に再利用できるようになりました。

Flow Designer を利用するアーキテクトへ: いくつかのアドバイス

• 構築前に監査しましょう。新しいものを作成する前に、アクションライブラリとサブフローカタログを検索してください。数年間実行されているインスタンスでは、開発者が認識しているよりも多くの再利用可能な素材が存在することがよくあります。重複すると、メンテナンス負債が生まれ、急速に蓄積されます。
• スコープ対象のアプリケーションは必須です。すべてのフローは、スコープ対象のアプリ内に存在する必要があります。開発者がグローバルスコープでビルドしているのを今でも見かけますが、デプロイ時に苦痛が生じます。オーストラリアのリリースでは AI 支援開発に重点が置かれているため、これは重要性を低下させるのではなく、より重要になっています。生成されたフローには適切なホームが必要です。
• 組み込みのテストツールでテストしましょう。Flow Designer には、トリガー条件をシミュレートし、実行をステップスルーできるテストフレームワークがあります。アクティブ化する前に使用してください。当たり前のことのように聞こえますが、実際には、時間のプレッシャーは近道につながります。
• 本番環境のフローを積極的に監視しましょう。何かが故障したときだけでなく、実行履歴、そして今度はフロー実行分析を通常の運用レビューの一環として使用します。統合ステップの失敗率が高い場合は、多くの場合、早期に検出する必要がある認証情報または構成のずれを示しています。
• 設計時に AI ステップの障害モードについて検討しましょう。AI エージェントアクションが利用可能になったことで、障害処理では AI 固有のシナリオ (予期しない出力形式、低い信頼スコア、エージェントが対応不可) を考慮する必要があります。これらのパスは、本番環境でヒットした後ではなく、ビルド前に設計します。

まとめ

Flow Designer は、経験豊富なワークフローエディターユーザーを懐疑的にしたツールから、長い道のりを歩んできました。オーストラリアリリースの追加、特に AI エージェントアクションとフロー実行分析は、ツールでできることと本番運用をサポートする方法に対する実質的な変更です。

アーキテクトレベルで働いている人にとって、今の課題は、Flow Designer に十分な能力があるかどうかではなく、AI 主導のステップを含むバージョンのツールをどのように管理および設計するかです。これは真に新しいデザイン空間であり、それをうまく行うためのパターンはまだコミュニティ全体で確立されています。

私のように認定アーキテクトの資格取得に向けて取り組んでいる場合、または認定アーキテクトの資格を維持している場合は、組織のアップグレード前に PDI でこれらの機能を実際に体験することは、有益な時間の投資となります。実際にそれらを利用して構築し、エッジケースに直面する経験こそが、本当の学習が起こる場所です。

オーストラリアの最新情報の全体像については、ServiceNow オーストラリアリリース コミュニティガイドは確実な出発点であり、Flow Designer の製品ページには、プラットフォームを初めて使用するステークホルダーと共有する場合に役立つ公式の概要が掲載されています。

---

この記事は機械翻訳されております。最新は元となる記事をご覧ください: https://www.servicenow.com/community/developer-blog/flow-designer-in-servicenow-what-the-australia-r...。

免責事項: 一部の日本語は、翻訳ソフトウェアを使用してお客様の便宜のために翻訳されています。正確な翻訳をご提供できるよう相当な努力を払っておりますが、いかなる自動翻訳も人間の翻訳者に代わすることはなく、そのようなことは意図されておりません。翻訳は「現状のまま」提供されています。他言語への翻訳の的確性、信頼性または正確性については、明示または黙示を問わず、いかなる保証も行われません。翻訳ソフトには限界があるため、一部のコンテンツが正確に翻訳されていない場合があります。これらの資料の公用言語は英語です。翻訳の際に生じる相違または不一致は、コンプライアンスまたは履行の目的に関しては拘束力を有さず、法的効力はないものとします。

This article was machine translated and replicated from the original source: https://www.servicenow.com/community/developer-blog/flow-designer-in-servicenow-what-the-australia-r...。

[JunshuO]

私は、Flow Designer が古いワークフローエディターに取って代わって以来、Flow Designer に取り組んできました。正直なところ、プラットフォームコミュニティがこれを完全に受け入れるまでには時間がかかりました。経験豊富な開発者は、複雑なシナリオでは Flow Designer が少し制限されていると感じたため、静かに Workflow に戻ったり、代わりにビジネスルールを作成したりしていた時期がありました。これは過去数回のリリースで大きく変更され、オーストラリアリリースは、私が予想していたよりも物事を推し進めました。

この記事は、Flow Designer の概要と、アーキテクトや上級開発者にとって重要なオーストラリアのリリースの実際の新機能について、実用的で正直に説明する試みです。私がこれを書いているのは、私自身の認定メンテナンスのためであり、部分的には、実際には、その本質的な意味を説明していない表面的な「新機能」に関する投稿をたくさん見てきたからです。

基本事項: Flow Designer とは何ですか？

ServiceNow を初めて使用される場合、Flow Designer はプラットフォームのビジュアル自動化ツールです。フロー (自動化プロセス) を構築するには、キャンバス上で次の 4 つの構成要素を組み合わせます。

• トリガーは、 フローを開始します。これらは、作成または更新中のレコード、スケジュールされた時刻、または受信 API 呼び出しです。
• アクションは、 レコードの作成、通知の送信、外部システムの呼び出し、スクリプトの実行など、あらゆる作業を行います。
• フローロジックは、 パスを制御します。if/else 分岐、for-each ループ、待機条件などです。
• サブフローは、 コードで関数を呼び出すのと同様に、複数のフローから呼び出すことができるプロセスの再利用可能なチャンクです。

キャンバスはドラッグアンドドロップ式なので、スクリプティングの深いバックグラウンドがなくてもアクセスできます。ただし、「ローコード」を「低電力」と間違えないでください。私は、Flow Designer がマルチシステム統合、並列承認チェーン、SLA 対応ルーティングなど、非常に複雑なエンタープライズプロセスを処理するのを見てきました。

私が一緒に仕事をしているチームにいつも強調していることの 1 つは、再利用性は Flow Designer が与えてくれる最大の贈り物であり、ほとんどのチームはそれを十分に活用していないということです。API コールまたはビジネスロジックをラップしてカスタムアクションを一度ビルドすると、インスタンス全体にわたってすべての開発者のアクションピッカーに表示されます。ロジックが変更されたら、1 か所を更新します。それが約束であり、チームが実際にそれに従えば、メンテナンスの節約は本物になります。ServiceNow 独自の設計考慮事項に関するドキュメントでは、オーストラリアのリリースについて、フローは短く、モジュール式で、再利用可能な作業のコレクションである必要があるという点が強調されています。

IntegrationHub: 他のすべてに接続する場所とは、何ですか？

Flow Designer は ServiceNow 内のものを単独で自動化します。IntegrationHub は、外部の他のエンタープライズシステムに到達できるようにするものです。

スポークライブラリは、ほとんどの組織がすでに使用しているプラットフォーム (Microsoft Teams、Slack、Jira、Salesforce、DocuSign、ServiceNow から ServiceNow など) をカバーしています。各スポークには、事前にビルドされ認証されたアクションステップが用意されているため、毎回 REST 呼び出しを最初から記述する必要はありません。

実際、複雑な環境において Flow Designer が真価を発揮するのはこの点です。最近、ある金融サービスのクライアントと仕事をしたところ、オンボーディングフローが ServiceNow、Jira、Azure AD、Teams に関係し、すべて単一の Flow Designer キャンバスからオーケストレーションされました。ビジネスステークホルダーは実際にフローを読み、フローが何をしているのかを理解できるため、サインオフと変更管理がスクリプトベースのものよりも大幅に簡単になりました。

オーストラリアのリリースで Flow Designer に実際に追加されるものとは、何ですか？

このオーストラリアリリースは 2026 年 5 月に一般提供され、見出しは AI ですが、Flow Designer への具体的な追加機能は、通常の「AI を活用した」マーケティングが示唆するよりも具体的でアーキテクチャ的です。私が実際に重要だと考える点は以下のとおりです。

AI エージェントアクション: これはまさに新しい領域です。

現在、Flow Designer にはネイティブの「AI エージェントの使用」アクションが搭載されています。これは Now Assist がバックグラウンドで提案を生成するものではありません。これは、構成された AI エージェントにデータを渡すファーストクラスのフローステップであり、エージェントの構造化された出力がフローの次のステップにフィードされます。

これでフローは、トリガー、コンテキストデータの検索、AI エージェントの呼び出し、条件付きロジックでの AI 出力の使用、そして結果に基づいたアクションの実行といった流れになります。

私が何度も繰り返し考えている実際的な例は、インシデントのトリアージです。短縮説明、カテゴリ、および最近の類似インシデントをトリアージエージェントに渡します。提案されたアサイン先グループ、信頼スコア、および推奨される解決パスを取得します。信頼性が十分に高い場合は、自動アサインして通知します。十分な信頼性がない場合は、人間によるレビューのためにサービスデスクにルーティングします。

これがアーキテクチャ的に重要なのは、フローロジックが純粋に決定論的である必要がなくなったことです。プロセス全体を構造化され監査可能な状態を維持しながら、AI の推論を活用する意思決定ポイントを設計できます。出力は名前付きフロー変数にマッピングされるため、下流のすべてのステップは、何を取り扱っているかを正確に把握できます。

正直に言うと、これはアーキテクトが検討すべき新しい設計上の課題も提起します。AI ステップが予期しない出力を返すフローをどのように処理しますか？フォールバックはどうしますか？途中に確率的ステップがあるプロセスをどのように監査しますか？これらはこの機能を避ける理由ではありませんが、プロダクション設計における実際の考慮事項です。

自然言語フロー生成: 魔法ではなく、便利な機能です。

オーストラリアリリースのNow Assist for Creator には、わかりやすい英語の説明からドラフトフローを生成する機能が含まれています。「マネージャーの承認を得て、Jira チケットを作成し、Teams を介して要求者に通知するフローを作成する」などのプロセスを説明すると、ステップが計画されたキャンバスのドラフトが表示されます。

私はこれを試しましたが、特に要件について話し合ってから数分以内に利害関係者に具体的なものを示したいワークショップの設定で、すぐに始めるのに本当に便利です。生成されたドラフトは本番環境に対応していません。ほとんどの場合、条件を調整し、エラー処理を追加し、適切な変数を接続する必要があります。しかし、空白のキャンバスからレビュー可能なものになるまでの時間が短縮されます。

チームが注意したいのは、生成された出力を実際よりも完成に近づいているものとして扱うことです。ドラフトには、名前付け規則、スコープ対象のアプリ構造、既存のアクションライブラリ、またはガバナンス要件がわかりません。アーキテクトは、テスト環境に近づく前に、それを適切にレビューする必要があります。

フロー実行分析: これは私が最も楽しみにしているものです。

失敗したフローのトラブルシューティングは、常に必要以上に苦痛でした。実行履歴を取得し、ログを段階的に実行できますが、12のアクションと複数の統合呼び出しを含む複雑なフローで何が原因で失敗したのかを突き止めるには、伝統的に多くの手動トレースが必要でした。

オーストラリアリリースでは、実行履歴の上に AI 支援診断レイヤーであるFlow Execution Analysis が追加されました。フローに障害が発生すると、最も可能性の高い障害ポイントが特定され、考えられる根本原因が説明され、具体的な修復手順が提案されます。

私がこれに心から興奮している理由は、実際の運用コストに対処しているからです。ServiceNow を実行するほとんどの組織には、本番環境でフローをサポートする人員が混在していますが、全員が最初にフローの構築に関与していたわけではありません。「このフローが失敗した」から「修正すべき点とその理由」までの時間を短縮するものはすべて、直接的なビジネス価値を持ち、私の経験では、その時間は歴史的に必要以上に長くなってきました。

また、引き継ぎドキュメントに対する私の考え方も変わります。プラットフォーム自体がフローが失敗した理由とそれに対する対処法を説明できれば、フローを知る人がいない本番環境での障害という最悪のシナリオは、壊滅的になる可能性が大幅に低くなります。

ネストされたプレイブック: 静かなアーキテクチャの勝利です。

これは Flow Designer に隣接していますが、言及する価値があります。オーストラリアのリリースでは、ネストされたプレイブックが導入されています。つまり、プレイブックを別のプレイブック内で使用できるようになりました。詳細については、ServiceNow コミュニティプレイブックのリソースページをご覧ください。これを使用するには、子をスタンドアロンプレイブックとして作成し、ネスト可能としてマークして、親から参照する前にアクティブ化します。

このパターンは、Flow Designer のサブフローが提供する再利用性や、複雑なガイド付きプロセスの分解と同様のメリットをもたらします。それ以前は、大規模なプレイブックは扱いにくくなり、複数のプロセスバリアントにわたるメンテナンスが困難でした。これで、共通セグメントをファクタリングして適切に再利用できるようになりました。

Flow Designer を利用するアーキテクトへ: いくつかのアドバイス

• 構築前に監査しましょう。新しいものを作成する前に、アクションライブラリとサブフローカタログを検索してください。数年間実行されているインスタンスでは、開発者が認識しているよりも多くの再利用可能な素材が存在することがよくあります。重複すると、メンテナンス負債が生まれ、急速に蓄積されます。
• スコープ対象のアプリケーションは必須です。すべてのフローは、スコープ対象のアプリ内に存在する必要があります。開発者がグローバルスコープでビルドしているのを今でも見かけますが、デプロイ時に苦痛が生じます。オーストラリアのリリースでは AI 支援開発に重点が置かれているため、これは重要性を低下させるのではなく、より重要になっています。生成されたフローには適切なホームが必要です。
• 組み込みのテストツールでテストしましょう。Flow Designer には、トリガー条件をシミュレートし、実行をステップスルーできるテストフレームワークがあります。アクティブ化する前に使用してください。当たり前のことのように聞こえますが、実際には、時間のプレッシャーは近道につながります。
• 本番環境のフローを積極的に監視しましょう。何かが故障したときだけでなく、実行履歴、そして今度はフロー実行分析を通常の運用レビューの一環として使用します。統合ステップの失敗率が高い場合は、多くの場合、早期に検出する必要がある認証情報または構成のずれを示しています。
• 設計時に AI ステップの障害モードについて検討しましょう。AI エージェントアクションが利用可能になったことで、障害処理では AI 固有のシナリオ (予期しない出力形式、低い信頼スコア、エージェントが対応不可) を考慮する必要があります。これらのパスは、本番環境でヒットした後ではなく、ビルド前に設計します。

まとめ

Flow Designer は、経験豊富なワークフローエディターユーザーを懐疑的にしたツールから、長い道のりを歩んできました。オーストラリアリリースの追加、特に AI エージェントアクションとフロー実行分析は、ツールでできることと本番運用をサポートする方法に対する実質的な変更です。

アーキテクトレベルで働いている人にとって、今の課題は、Flow Designer に十分な能力があるかどうかではなく、AI 主導のステップを含むバージョンのツールをどのように管理および設計するかです。これは真に新しいデザイン空間であり、それをうまく行うためのパターンはまだコミュニティ全体で確立されています。

私のように認定アーキテクトの資格取得に向けて取り組んでいる場合、または認定アーキテクトの資格を維持している場合は、組織のアップグレード前に PDI でこれらの機能を実際に体験することは、有益な時間の投資となります。実際にそれらを利用して構築し、エッジケースに直面する経験こそが、本当の学習が起こる場所です。

オーストラリアの最新情報の全体像については、ServiceNow オーストラリアリリース コミュニティガイドは確実な出発点であり、Flow Designer の製品ページには、プラットフォームを初めて使用するステークホルダーと共有する場合に役立つ公式の概要が掲載されています。