※本記事の内容は、2025年7月時点の情報に基づいて記載しています。
こんにちは。
インフォシェア株式会社 DX部です。
日頃Nintex でシステム開発を行っている皆様へ、Nintex製品の今後について、ブログにて記載させていただきます。
公式サポート終了とSharePoint 2013 ワークフローエンジン・Add-Inモデルフォームの廃止
今後のNintex 製品について、Nintex社から、以下3点の発表がされています。
① 2025年12月31日をもって Nintex Workflow for Office 365 の公式サポート終了
② 2026年4月2日をもって、SharePoint 2013 ワークフローエンジンの廃止による Nintex Workflow for Office 365 の停止
③ 2026年4月2日をもって、Add-Inモデルフォームの完全に廃止に伴う、フォーム停止
Nintex Workflow for Office 365 や Nintex Forms for Office 365 をお使いのお客様は、すでにご存知の方も多いかもしれませんが、「実際これって具体的に何が起きるのか」「廃止されるってどうすればいいのか」と感じる方も多くいるかと思います。
なので、本ブログでは、このNintex社からの発表について、詳細を記載いたします。
※本情報は、Nintex Communityと、Nintex社への問い合わせからまとめております。
ブログ公開時点で、最新情報が更新されている可能性もございます。
あらかじめご了承くださいませ。
Nintex Workflow / Forms のサポート終了、その意味を正しく理解していますか？
まず、①の「2025年12月31日をもってNintex Workflow for Office 365 の公式サポート終了」についてです。これは、Nintex Workflow for Office 365 についての発表になります。
Nintex Workflow for Office 365 は、2023年12月6日にすでに「製品ライフサイクルの終了」をしており、開発・アップデートはすでに終了しています。
しかし、現在はサポートポリシーの「限定サポートフェーズ」であるため、まだNintex社へ製品に関する問い合わせはできていた状況でした。
それが、今回の2025年12月31日に終了するという事になります。
そのため、2026年1月1日からは、Nintex Workflow for Office 365 についての問い合わせは受け付けられなくなってしまいます。
ただし、上記で説明した通り、こちらはNintex Workflow for Office 365 のみですので、Forms については、引き続き問い合わせが可能です。
Forms については、③の「2026年4月2日をもって、Add-Inモデルフォームの完全に廃止に伴う、フォーム停止」部分でも改めて詳しく説明します。
Nintex Workflow for Office 365 と Nintex Forms for Office 365 が使えなくなる？
続いて、②の「2026年4月2日をもって、SharePoint 2013 ワークフローエンジンの廃止によるNintex Workflow for Office 365 の停止」です。
こちらは、Microsoft社から発表されている通り、2026年4月2日からSharePointワークフローエンジンが廃止されます。
それに伴い、Nintex Workflow for Office 365が実行できなくなります。
そのため、上記の製品でシステムを構築しているソリューションは、すべて停止してしまうことになってしまいます。
そして、③の「2026年4月2日をもって、Add-Inモデルフォームの完全に廃止に伴う、フォーム停止」です。
こちらは、Nintex Forms for Office 365 の”ClassicおよびResponsiveフォーム“で作成する、Add-Inモデルのフォームが廃止され、フォームが利用不可になります。
現在、そのフォームを使用しているリストは、2026年4月2日を迎えると、自動的にSharePointリストの標準フォームに戻ってしまいます。
SharePoint2013ワークフローエンジンの廃止とAdd-Inモデルの廃止の2点は、Nintex Workflow for Office 365 / Nintex Forms for Office 365 で開発をしているシステムにおいて、「2026年4月2日に突然使えなくなる」ということになってしまいます。
そのため、2026年4月2日までに、システムを新しく移行する必要があります。
サポート終了後、企業が取るべき4つの選択肢
上記の通り、Nintex Workflow / Forms for Office 365 のサポート終了とともに、これまで業務の裏側で静かに動いていた“仕組み”が止まります。では、企業は何を選び、どう進めるべきなのでしょうか。
ここからは、私たちが実際に移行支援を行ってきた経験などから、現実的かつ有効な「4つの選択肢」を整理してご紹介します。それぞれの選択肢には異なる特長があり、最適解は企業によって異なります。すでに保有しているライセンス、社内の技術リソース、今後の運用方針に合わせて、最もフィットする方法を検討してみてください。
選択肢①：Nintex Workflow へ移行
(旧名称：Nintex Workflow Cloud/Nintex Automation Cloud)
いま使っている Nintex の感覚のまま、クラウドで続けられないかな…
そんな方にとって最も自然な選択肢が、”Nintex Workflow“（旧名称：Nintex Workflow Cloud/Nintex Automation Cloud）です。
旧Nintexユーザーであれば比較的操作感が近く、ゼロから学び直す必要がないため、スムーズな移行と現場の混乱回避が両立できます。
そもそも Nintex Workflow とは、従来の SharePoint 上で動作していた”Nintex Workflow for Office 365” や ”Nintex Forms for Office 365”の後継にあたる、完全クラウドベースの自動化プラットフォームです。ドラッグ＆ドロップで簡単にフォームやワークフローを構築でき、複数SaaS（Ex. Microsoft 365 や、SharePoint Online、Salesforce など）との接続ができます。
Nintex Workflow の最大の魅力は「集中管理による運用統制」ができる点にあります。
- ワークフローやフォームなどの構成要素を一元管理でき、属人化しにくい
- ユーザーやグループ単位で「作成／実行／管理」の権限を分けて設定でき、運用ガバナンスを維持しながら現場の自律性も確保可能
- フォームやフローの過去バージョンを自動で保存できるため、誤操作や仕様変更時も簡単に巻き戻しが可能
- いつ・誰が・何を操作したかを記録できるような監査ログも標準機能として搭載されているため、トラブル対応や内部監査にも備えられるセキュリティ性の高い設計
- 利用条件（ライセンス・環境要件）
これらを踏まえ、以下のような企業様には、特に Nintex Workflow の導入をご検討いただく価値があるかと思います。
- SharePoint や Office 365 で既にNintexを活用しつつ、クラウド基盤に完全移行したい
- 複数部署や多様なクラウドサービス間でワークフローやフォームを統合・一元管理したい
- 拠点や部門ごとにワークフロー利用者が多く、属人化せずに運用したい
選択肢②：Power Apps ＋ Power Automate で再構築
Microsoft 365 の環境内で完結させたいな…
このように考える企業様におすすめなのが、”Power Apps” と ”Power Automate”の組み合わせです。Microsoft 365 に含まれている機能を活用することで、追加のライセンスコストを抑えつつ、業務に必要なフォームとワークフローの再構築をすることができます。
そもそも Power Apps とは、Microsoft が提供するローコードアプリ作成ツールです。業務用の入力フォームや小規模アプリを簡単に作成することができます。
また、Power Automate は、ドラッグ＆ドロップでワークフロー（フロー）を設計・自動化できるサービスであり、Outlook、SharePoint、Teams などと連携可能です。
この Power Apps + Power Automate の組み合わせにより、「フォームでデータを入力し、その後の承認・通知・処理を自動化する」という一連の業務フローが Microsoft 365 内で完結します。
Power Apps ＋ Power Automateの最大の魅力は、すでに Microsoft 365 を導入済みの企業であれば「手軽に始められる柔軟性と内製化のしやすさ」にあります。
- Microsoft 365 ライセンスをすでに保有している企業であれば、追加コストなしで利用できる範囲が広い
- SharePointリストと連携したフォームの作成が容易（従来の資産を活かせる）
- Outlook、Teams、Excel、Planner などMicrosoft製品との親和性が高く、通知やデータ連携もシームレス
- 個人または部門単位で構築・運用が可能なため、小さな業務改善から始めやすい
- 利用条件（ライセンス・環境要件）
（※これまでNintexで実現していた構成を置き換えると想定した場合）
利用可能な機能範囲は Microsoft 365 のプラン（E1/E3/E5等）によって若干異なるため、導入前に確認が必要です。また、「プレミアムコネクタ」や「Dataverse」「環境制御」などの一部機能を使用したい際は、別途ライセンスが必要になる場合があります。
これらを踏まえ、以下のような企業様には、特に Power Apps ＋ Power Automate の導入をご検討いただく価値があるかと思います。
- すでに Microsoft 365 を導入しており、追加コストを抑えてフォームやワークフローの再構築を行いたい
- 全社展開よりも、まずは特定部門・業務から小さく始めて段階的に移行を進めたい
- 業務ごとに異なるフローや申請様式が多く、柔軟にカスタマイズしたい
選択肢③：Power Apps ＋ Azure Logic Apps で再構築
Microsoft 365 の業務資産を活かしながらも、より複雑な処理や社内全体の統制にも
対応したいな……
このようにお考えの企業様には、”Power Apps” と ”Azure Logic Apps” の組み合わせによる再構築をおすすめします。
Azure のサービスを活用することで、Microsoft 365 の業務基盤を活かしながら、より高い統制性と拡張性を備えたフォームとワークフローの再構築が可能です。
そもそも Azure Logic Apps とは、Microsoft が提供するクラウドベースのワークフローサービスです。UIを使ったフロー設計も、コードによるフロー実装も可能で、複雑な条件分岐やデータ処理、スケジューリングなどを組み込める点が特長です。
Power Automate は Logic Apps のエンジンを使用している点では同じ「ワークフロー自動化ツール」ですが、Azure Logic Apps の方が、「大規模・複雑な業務ロジックを組織横断で制御できる」ツールであり、IT管理者やシステム部門による統制やガバナンスを意識した用途に向いています。Power Automate は、個々の市民開発者が作成する前提ですが、Logic Apps は、権限が付与されている開発者だけが作成できる時点で、統制力が違います。（Power Appsについては上記の通り）
この Power Apps + Azure Logic Apps の組み合わせにより、Power Platformの中でも、特に拡張性・柔軟性に優れた構成を実現できます。
繰り返しになりますが、Power Apps ＋ Azure Logic Apps の最大の魅力は、「拡張性とガバナンスを両立しつつ、Microsoft製品との親和性も高い」点にあります。
- Microsoft 製品群と密接に連携しながらも、より複雑で大規模な処理を実現可能
- Azure ポータル上での集中管理が可能なため、組織横断でのガバナンス・監査にも対応
- Azure 上で実行される Logic Apps によって、外部システムやSaaSとの高度な統合も可能
- 実行ログや障害通知、APIベースの連携管理など、IT部門にとって扱いやすい運用設計が可能
- 利用条件（ライセンス・環境要件）
（※これまでNintexで実現していた構成を置き換えると想定した場合）
Azure Logic Apps の利用に際しては、従量課金モデルとなるため、トリガーやアクション数、ネットワークコスト、ストレージコストなど、動作ボリュームに応じたコストが発生します。
これらを踏まえ、以下のような企業様には、特に Power Apps ＋ Azure Logic Apps の導入をご検討いただく価値があるかと思います。
- 自社内の業務システムと連携しながら、柔軟な承認フローやデータ統合を設計したい
- 全社的なガバナンス・統制を意識しながら、部門横断での仕組み整備を行いたい
- Microsoft 製品との親和性は維持しつつ、より高度な業務要件に対応したい
選択肢④：SharePoint標準機能で使用（＋ Power Automate or Azure Logic Apps）
今すぐ大きな投資は難しく、とにかく業務が止まらないように早く切り替えられる
かな…
このように考える企業様にとって、最も手軽で現実的な手段のひとつが、”SharePoint標準機能” + ”Power Automate” または “Azure Logic Apps” による代替です。
Microsoft 365 に含まれる SharePoint の基本機能を活用することで、最小限のコスト・工数で代替手段を用意することができます。
SharePoint標準機能とは、Microsoft 365 に標準搭載されている ”SharePoint Online” の中で、リストやライブラリ、列、ビューといった機能を活用することで、業務用の申請フォームや入力画面をノーコードで構築できます。（Power Automate や Azure Logic Apps については上記の通り）
ただし、SharePoint 単体では承認・通知などの自動化は行えないため、Power Automate または Azure Logic Apps との組み合わせが必須となります。
SharePoint標準機能活用の最大の魅力は、「手軽さと迅速な業務継続」が可能な点にあります。
- Microsoft 365 ライセンスをすでに保有している企業であれば、Microsoft 365 の標準機能で構成できるため、追加ライセンスなしで導入可能（範囲には注意）
- Nintex の既存データ（SharePointリスト上のアイテム）をそのまま活用できる
- SharePoint リストをフォーム代わりに使用し、Power Automate のテンプレートも活用すれば、承認フローの初期構築が短時間で完了する
- UIの柔軟性や複雑処理には制限があるが、最小構成で業務継続を実現可能
- 利用条件（ライセンス・環境要件）
Power Automate のプレミアムコネクタや外部連携が必要な場合は、別途 Power Platform の追加ライセンスが必要です。
これらを踏まえ、以下のような企業様には、特に SharePoint標準機能活用をご検討いただく価値があるかと思います。
- Nintex の代替として、最低限の申請・承認フローを急ぎ立ち上げたい
- 複雑な画面レイアウトや多段階の分岐を必要としないシンプルな業務が多い
- 将来的に他手段へ本格移行するまでの「暫定対応」として、スピード重視で構築したい
事例公開―弊社はこうしてNintexからの移行を成功させました
さて、ここまでで、移行先の選択肢をいくつか見てきましたが、「実際にどうやって進めるの？」という点が気になる方も多いかと思います。
そこで今回は、弊社が支援した実例をご紹介します。
1. 実施した移行案件の概要
今回ご紹介するのは、”Nintex Workflow for Office 365” および ”Nintex Forms for Office 365（Add-In モデル）” を利用していたシステムに対し、上記の方法から、選択肢①：”Nintex Workflow”（旧名称：Nintex Workflow Cloud/Nintex Automation Cloud）への移行を支援した事例です。
2. 移行時にネックとなったポイント
今回の移行にあたっては、「技術的に実現可能かどうか」という点や「ユーザーから見た操作感・使い勝手の変化」という点など、いくつかの懸念点がありました。特に以下のような点が、プロジェクトを進める上での検討ポイントとなりました。
① フォーム関連の課題（Nintex Forms for Office 365 からの移行）
- レイアウトの自由度
- 旧Nintex Forms（Add-Inモデル）では自由なレイアウト設計が可能でしたが、新しいSPFxモデルではレスポンシブ仕様が基本となり、細かなレイアウト調整が難しくなります。
- JavaScript を使った表示制御
- 以前は JavaScript による細かなUI制御が可能でしたが、新しいSPFxモデルでは、基本的にカスタムスクリプトは制限され、自由に使える設計にはなっていません。
- その代替として、”Nintex Rules（ルール）機能” による制御がどこまでカバーできるか、PoCで事前に検証が必要となりました。
② 業務フローのパターン分け（Nintex Workflow for Office 365 からの移行）
- 複雑な承認パターンの再現
- 今回移行したシステムは、承認パターンや権限パターンなどが申請ごとに異なっており、分岐処理が多岐にわたる構成でした。
- Nintex Workflow でこれらのパターンを再現可能かどうか、特に「段階的な承認（ユーザー単体やグループ含む）」、「差戻し先の選択（承認者間の差戻し、申請者への差戻しなど）」「権限パターンの切り替え」などの実現性について、全パターンを両者で確認する必要がありました。
③ 移行後の運用設計における注意点
- 既存システムの扱い
- 今回は、移行前のシステムを完全に停止し、全ユーザーに移行先への切り替えを徹底する方針としました。
- 事前に切り替えタイミングや、対象範囲などを定めておかないと、移行後に「旧データが見られない」といった混乱が発生するリスクがあります。
- フォームレイアウト崩れへの備え
- 前述の通り、2026年4月2日を過ぎると、Nintex Forms（Add-Inモデル）は利用できなくなり、フォームは自動的に、SharePoint標準のフォームに切り替わります。
- これにより、従来フォームのXMLデータをそのまま表示することは難しく、例えば「繰り返しセクション」などのNintex独自の制御構造が正しく反映されず、保存されていたXML形式のデータが正しくレイアウトされなくなる可能性があるため、周知と再設計の検討が必要でした。
これらのポイントからも分かる通り、PoC（事前検証）と要件定義フェーズは、移行プロジェクトを成功させるうえで非常に重要です。特に、現行システムで「できていたこと」が移行後にも維持できるのか、またその際のユーザーから見た操作感などが大きく損なわれないか、というような点をあらかじめ検証・整理しておくことが、トラブルのない移行とスムーズな運用開始につながります。
3. プロジェクトの流れ（スケジュール概要）
実際にプロジェクトは、以下のような流れで進行していきます。
以上、弊社が実際にご支援した移行事例をもとに、プロジェクトの進め方をご紹介しました。
Nintex Workflow/Forms のサポート終了は、業務継続の観点でも重要な転換点となりますが、適切な準備と選択により、スムーズな移行と業務改善の両立も可能です。
移行先の選定にお悩みの方や、何から始めるべきかご不安な方は、ぜひお気軽にご相談ください。
下記より、弊社の移行支援サービスの詳細をご覧いただけます。