ワークフロー（自動化）とは何か — 仕事の順番を作る道具と、失敗したときの挙動
「受付 → 確認 → 記帳 → 通知」のように、仕事が流れる順番を作るのがワークフローです。工場に例えると生産ラインで、ラインを流れるのは部品ではなくデータです。各工程に道具（ChatAI・AI エージェント・RPA・iPaaS・AI-OCR のどれでも）を配置できます。
ワークフローの 8 つの観点
| 観点 | 実態（2026-08-26 時点の公式資料） |
|---|---|
| 用途 | 定型の流れ（受付→確認→記帳→通知）を毎回同じ順で回す |
| 価格の数え方 | 実行数・タスク数・処理時間・データ量など製品ごとに単位が違う。単位が違うと比べられない |
| 導入しやすさ | 画面上でブロックを並べる製品が主流。プログラムは不要 |
| 安定性・壊れ方 | 失敗が目に見える。多くは既定で止まり、記録が残る |
| 前提条件 | 各工程の相手（機械）に接続口があること |
| 情報セキュリティ | 通り道として業務データが流れる。データの保管場所と学習利用の定めは契約前に確認（「学習に使わない」を明記する製品がある） |
| 継続性と出口 | 組んだフローは製品固有。乗り換え時に持ち出せるかは要確認（作り直しが基本） |
| 注意事項 | 「エラーのとき止まるか進むか」は製品と設定で違う。契約前に確認 |
ラインの良さは失敗が目に見えることです。たとえば Yoom は「エラーが発生するとフローボットが途中で停止し、「エラー」履歴に表示されます。」（ヘルプ）と明記しています。止まって、記録が残る。工場らしい、行儀のよい壊れ方です。ただし「エラーを無視して進む」既定の動作を持つ製品もあるので、既定がどちらかは製品ごとに確かめます。この役の製品は iPaaS（配線盤）と共通で、1 つの製品が「ライン」と「配線盤」の 2 役を兼ねます。当てはまる製品と、エラー時の流れ・課金単位・出口の欄は RenkeiMap の連携ツール一覧 に出典つきで置いてあります。
調査記録で確かめる
生産ラインを動かす引き金と、途中の変換・向きを、iPaaS の欄で見ます。
比較項目:
| システム | 業務安定性 | 業務ワークフロー円滑度 |
|---|---|---|
| 失敗したときの扱い | 起動のきっかけ | |
| ActRecipe | 通知設定でレシピ実行の通知対象を 4 段階から選べる ベンダー公表 通知設定でレシピ実行の通知対象を 4 段階（すべて／失敗時のみ／警告時のみ／失敗と警告時のみ）から選べる 連携先 SaaS の API 仕様変更は原則サポートの一部として対応 「連携するSaaSのAPIのバージョンアップ等の仕様変更には、原則としてサポートの一部として対応しております」。再実行・途中再開についての記述は見つけられなかった。 2026-08-11 追記 通知対象の原文は「すべて（デフォルト）：レシピが実行された際に常に送信します。」以下 4 段階。実行ステータスも 3 値あり、再実行・途中再開の記述は 630 件超の記事一覧を見ても見つけられなかった。 | 定期（cron 形式で分・時・曜日まで指定可）／手動／一部レシピは Webhook （例に */10 0-9 * * 1,2,3,4,5 を掲載）／Webhook は「一部のレシピではWebhookに対応しております」 |
| Anyflow Automation | ？ 調査中 — この項目はまだ調査しきれていないため、調査完了までお待ちください。（詳しくは【詳細・出典】） 編集部確認Anyflow Automa…()
Anyflow Automation 製品ページ 確認したもの: 公式サイト anyflow.jp は本文を JS で描画する殻で、取得した HTML には題名と meta しか入らない（製品ページ・会社ページ・利用規約を 2026-08-11 に取得して確認）。この項目を機械で確かめられる公開ページが無い。なお同社の SaaS 事業者向け製品 Anyflow Embed は技術ドキュメントを公開しており、そちらの情報は Embed のページにある。 調査日 | ？ 調査中 — この項目はまだ調査しきれていないため、調査完了までお待ちください。（詳しくは【詳細・出典】） 編集部確認Anyflow Automa…()
Anyflow Automation 製品ページ 確認したもの: 公式サイト anyflow.jp は本文を JS で描画する殻で、取得した HTML には題名と meta しか入らない（製品ページ・会社ページ・利用規約を 2026-08-11 に取得して確認）。この項目を機械で確かめられる公開ページが無い。なお同社の SaaS 事業者向け製品 Anyflow Embed は技術ドキュメントを公開しており、そちらの情報は Embed のページにある。 調査日 |
| Anyflow Embed | 自動リトライ／実行履歴からの再実行／Slack・Teams などへの通知 アクションの自動リトライ／エンドユーザーが実行履歴から押す再実行ボタン／イベント通知 アクションの自動リトライ（既定: 429/500/502/503/504/507 かつ GET・OPTIONS のとき 2 回。専用アクションは条件・回数 0〜5 回に変更可）／エンドユーザーが実行履歴から押す再実行ボタン（回数制限なし・失敗履歴が 30 日でアーカイブされるまで）／イベント通知（Slack・Teams・メール・Datadog・New Relic・Sentry） 「実行に失敗しており、アーカイブ（30日経過）されていない実行履歴にのみ、再実行ボタンが表示されます。」／「再実行の回数に制限はありますか？ いいえ、再実行の回数に制限はなく、何度でも再実行することが可能です。」 | 自社プロダクト起点（クリック／Request／My Event／Webhook）／外部プロダクト起点（ポーリング・リアルタイム＝Webhook）／スケジューラー（cron 式） 「リアルタイムトリガーは通常、Webhook経由で発火するトリガーです。」／スケジューラーは「cron式でカスタムスケジュールを設定することが可能です」。 |
| ASTERIA Warp | 「チェックポイント」＝「大規模、大容量の処理を行うことを想定し、エラーの際に処理途中から復帰させるなどの機能」 「チェックポイント」（Enterprise のみ）＝「大規模、大容量の処理を行うことを想定し、エラーの際に処理途中から復帰させるなどの機能」。ほかに「フローメトリクス」（Standard 以上）、「優先実行」（Enterprise） 途中再開が明示的に機能として存在し、かつ最上位エディション限定であることが分かるのはこの 5 社でここだけ。再実行・通知については取得したページに記載が無い。 ベンダー公表製品ラインナップ・価格（機能…()
製品ラインナップ・価格（機能比較・詳細説明） ベンダー公表 ℹ️【2026-08-11 追記】再実行と通知も公開されている（第1回の「取得したページに記載が無い」を補う）。①チェックポイントの自動リトライ — 原文「チェックポイントフローのStartコンポーネントのプロパティに リトライ回数 と リトライ間隔 プロパティが追加されました。このフローでエラーが発生すると、Startコンポーネントで指定したリトライ回数分だけ、エラーが発生した場所の直前のチェックポイントからリトライが実行されます。」（raw/hc_checkpoint_retry_20260811.json）②エラー通知は 2 システムで、原文は「ASTERIA Warpでは2つのケースでエラー通知することが可能です。」に続けて「1. 実行したフローのエラー通知」「2. ASTERIA Warpサーバー異常の通知」を挙げ、前者は「コンポーネントにエラー処理フローを設定して、エラー処理フローでエラーの通知をするフローを作成する方法が考えられます。」と説明する（raw/hc_errornotify_20260811.json）③フローの異常終了はサーバー異常の通知では拾えない — 管理コンソール ヘルプの原文「サーバーで異常が発生した場合に管理者にメールで通知するための設定を行うことができます。開発したフローが異常終了した場合はこの通知は行われませんので、エラー処理フローなどを使って個別に対応してください。」（raw/doc_mc_index_20260811.html）④フロー側の分岐に BranchByException「エラーの種別により分岐します」・Exception・ExceptionReturn がある。
採取元: 製品ラインナップ・価格（機能比較・詳細説明）
調査日 | スケジュール起動／メールトリガー／URL トリガー＝Webhook・ブラウザからの実行／外部トリガー スケジュール起動（全エディション）／メールトリガー（Core + 以上）／URL トリガー＝Webhook・ブラウザからの実行（Core ++ 以上）／外部トリガー（FTP, MQ）（Standard 以上） エディションで使えるトリガーが変わるのがこの製品の特徴。 ベンダー公表製品ラインナップ・価格（機能…()
製品ラインナップ・価格（機能比較） ベンダー公表 ℹ️【2026-08-11 追記】管理コンソールの「設定＞トリガー」メニューの区分は URL／スケジュール／FTP／メール監視／メッセージキュー監視 の 5 つ（メール監視は原文「POPのメールボックスを監視してフローを実行するメール監視トリガー」）。開始コンポーネントは Start／HttpStart／PlatioStart。出典 https://help.asteria.com/documentation/warp/ja/current/flow/mc/index.html
採取元: 製品ラインナップ・価格（機能比較）
調査日 |
| AUTORO | ① エラー通知（プロジェクトのコラボレーター宛、複数指定可。現在は E メールのみ）／② 「エラー時に実行するワークフロー」を 1 つ指定でき、そのワークフローは ${error}（workflow.name / message / task_name / session_time / session_queue_id / session_url）を受け取れる。最大実行回数を 0 以上の整数で設定でき、未入力なら回数制限なし／③ Try タスクでワークフロー内でエラーを握り、セッションをエラーにせず分岐処理できる。 同じ失敗したノードを自動で再試行（リトライ）する機能の記載は無い。「エラー時に実行するワークフロー」は再実行ではなくリカバリ用の別ワークフローの起動である。 | 定期実行（スケジュール）に加え、メール受信や他システムのステータス変更に連動した起動が可能。 FAQ にも「土日 / 夜間でもロボットを起動できる定期実行機能がある」との記載。 ベンダー公表AUTORO の機能と特徴()
AUTORO の機能と特徴 ベンダー公表 ℹ️ドキュメントで補足（2026-08-11）：起動契機は「スケジュール」と「外部アプリトリガー」の 2 種類。原文「トリガーにはスケジュールと外部アプリトリガーの 2 種類が存在します。」。スケジュールは CRON 形式（[分][時][日][月][曜日]）で、CRON を書かずに何月/何日/何時/何分/何曜日のフォームでも設定できる。外部アプリトリガーはドキュメント上 Gmail・Outlook・Slack イベント・Webhook の 4 種。Webhook は「特定のURLへのPOSTリクエストを起点として指定したワークフローを実行します。」で、トリガーごとに 1 分間 60 リクエストが上限。外部アプリトリガーには 2 つの制限が明記されている：「外部アプリトリガーは定期的に動き、ワークフローを実行します。そのためトリガー元のアプリの状態をリアルタイムに反映しているわけではありません。」／「外部アプリトリガーにより一度に起動できるワークフローは 50 件までです。」。設定できるトリガー数の上限はプラン別で Lite 3・Standard 10・Pro 20。ほかに Zapier および Google スプレッドシートのアドオンからの起動のページもある。
採取元: AUTORO の機能と特徴
調査日 |
| bindit | 再実行・途中再開の記載は無い。フロー実行数のカウントは「正常終了および警告終了したフロー」。 | イベント（各連携先の「こんなイベントを条件に、」＝メール受信・行追加・レコード作成/更新/削除・打刻 など） 定期実行（スケジュール）・手動実行の記載は見つからなかった（binditとは・よくある質問・料金・連携アプリ全 21 ページを確認）。レシピの中に「特定の時刻にSlackに通知する」ものはあるが、機能としてのスケジュール実行の説明は無い。 |
| BizteX Connect | これは提供側の運用体制の説明であって、リトライ・途中再開といった製品機能の説明ではない。製品としての再実行機能の有無は公開ページから確認できなかった。 | 例: kintone では「プロセスのステータス変更の検知」「レコード追加/編集の検知」「レコード削除の検知」「コメントの書き込みの検知」。 イベントを持つのは 50 件中の一部で、採取した 238 操作のうちイベントは 41 件。定期（スケジュール）実行・手動実行の有無は公開ページに明示が無い。 編集部確認BizteX Connect…()
BizteX Connect 連携サービス個別ページ（kintone） 編集部確認 ℹ️2026-08-11 追記（すでに保存済みの個別ページの読み直し）：起動契機は「イベント」だけではない。「HTTP リクエスト」コネクタの個別ページがイベントとして Webhook と RSS を掲げており、外部からの通知でも起動できる。定期（スケジュール）実行・手動実行の有無は依然として公開ページに明示が無く、BizteX Connect には公開の製品ドキュメント／ヘルプセンターが存在しない（2026-08-11 確認）：docs.biztex.co.jp は 404、support/help/manual.biztex.co.jp と connect-support.biztex.co.jp はいずれも名前解決せず、アプリ本体 connect.biztex.co.jp は /help・/docs・/manual とも 404 でログインページのみ。service.biztex.co.jp の sitemap.xml 全 86 URL と www.biztex.co.jp の sitemap.xml 全 255 URL にもマニュアル区画は無い。 調査日 |
| Datable | ― 確認したもの: 公開ページの全部（/ /terms /newterms /security /hr /aboutus /corp /datable-ai）を描画して読んだが、再実行・通知・途中再開に触れた記述は無い。規約は逆に第15条3項で原文「ユーザーは、本サービスを介して送受信されるファイルの内容に関して、データ漏洩、データの消失、データ転送が行われないことにより不利益を被った場合、自己の責任においてリスクを負担することに同意の上、本サービスを利用するものとし…」と免責側だけを定めている。 調査日 | ― 確認したもの: 規約・トップ・/hr を描画して読んだが、実行の契機（定期・イベント・手動）に触れた記述は無い。 2026-08-11 更新 ブラウザで描画してから読み直した結果、「JS で読めない」ではなく「公開ページのどこにも書かれていない」ことが確かめられたので、「機械検証できない」から「公開されていない」へ判定を変えた。見たのは公開ページの全部にあたる: / /terms /newterms /security /hr /aboutus /corp /datable-ai（静的 sitemap 24 ページのうち、blog・news・seminar・reports を除く実体ページ）。 調査日 |
| Dify（ディファイ） | 失敗ブランチや既定値を使うときには、どんな種類のエラーだったかを表す error_type と、詳しい内容を表す error_message という二つの変数が使えます。これを使って、利用者向けの案内を出す、担当者へ知らせる、別の手立てに切り替える、記録に残す、といった処理を組めると説明されています。処理を自動でやり直す仕組みや、途中から再開する仕組みについての記載は、開いた範囲のドキュメントには見当たりませんでした。 | 編集部がまだ確認していません |
| HULFT Square | 専用コネクターでは「エラーが発生した際の自動リトライ機能など、便利な機能が用意されている場合もあります」 専用コネクターでは「エラーが発生した際の自動リトライ機能など、便利な機能が用意されている場合もあります」（コネクターでつなぐ節）。障害時目標復旧時間は 24 時間以内。 「用意されている場合もあります」という条件つきの記述であり、全コネクターで自動リトライがあるとは書かれていない。 ベンダー公表HULFT Square 連…()
HULFT Square 連携方法（コネクターでつなぐ） ベンダー公表 ℹ️マニュアル「コネクタートップページ」の「基本」節に、例外系のオペレーションが並ぶ: 例外通知／例外監視／データチェック／データチェックエラー詳細取得／アサーション例外／イベント通知(Amazon EventBridge)。表には「例外 メッセージ」「制限事項」の列があり、オペレーション単位で例外メッセージのページが張られている。出所 https://www.hulft.com/help/ja-jp/HULFTSquare/Content/Designer/Connector/connector.htm（保存: raw/help_connector_top_20260811.html）。
採取元: HULFT Square 連携方法（コネクターでつなぐ）
調査日 | ファイルイベント／REST API／スケジュール／HULFT Transfer の 4 種類 ファイル イベント ジョブ／REST APIジョブ／スケジュール ジョブ／HULFT Transferジョブ の 4 種類（マニュアル「ジョブ」）。 に続けて「ファイル イベント ジョブ」「REST APIジョブ」「スケジュール ジョブ」「HULFT Transferジョブ」の 4 つが並ぶ。あわせて外部 SaaS からの Webhook 受信という名前の起動契機はこのページには無く、HTTP 要求は「REST APIジョブ」として表現されている。 |
| IIJクラウドデータプラットフォームサービス | チェックポイント機能・優先実行モード（いずれもエンタープライズエディションのみ） 原文の説明は「大規模な利用ケースにおける障害対策機能」 再実行・通知の仕組みについては、公開されているページに個別の説明が無い。 ベンダー公表サービストップ プラン・料金…()
サービストップ プラン・料金 エディション一覧 ベンダー公表 ℹ️公開 FAQ に再実行の仕様がある。原文「本サービスの仕様では、フローの実行リクエストを送信してレスポンスを待っている間に通信エラーが発生した場合に、同じフローの実行を3回までリトライします。リトライしないよう変更することはできません」（raw/faq_longflow_20260811.html）。また監視タイムアウト値は「オンプレミス版Asteria Warpでは監視タイムアウト値の変更で上記のログが出力される頻度を抑制できますが、本サービスではお客様は設定を変更できません」（raw/faq_timeout_20260811.html）。
採取元: サービストップ プラン・料金 エディション一覧
調査日 | スケジュール起動（全エディション）／メール起動（エントリー以上）／URLトリガー（ベーシック以上）／FTPトリガー（スタンダード以上） 料金表の「実行機能」行から。エディションが上がるほど契機が増える形になっている。 ベンダー公表サービストップ プラン・料金…()
サービストップ プラン・料金 実行機能 ベンダー公表 ℹ️公開マニュアルのエディション別機能表では、トリガーの区分は スケジュール（全エディション）／URL（ベーシック以上）／SOAP（スタンダード以上、※ASTERIA Warp 2412 以降のバージョンでは利用できません）／メール（エントリー以上）／FTP（スタンダード以上）。加えて ASTERIA Warp との機能差の表に「以下のトリガーは使用できません メッセージキュートリガー」とある。URL トリガーは「本サービスで行うURLトリガーの有効設定や、フロー実行用のURLの形式は、オンプレミスのAsteria Warpのものとは異なります」（公開FAQ）。
採取元: サービストップ プラン・料金 実行機能
調査日 |
| JENKA | コネクタ単位のスイッチが 2 つある ベンダー公表 ① 「エラー発生時にワークフローを停止する」をオフにすると、そのコネクタでエラーが出ても後続コネクタが動く／② 「エラー発生時のメールを通知する」をオフにすると、そのコネクタに起因するエラーのメール通知が止まる。エラー通知メールはワークフローを「公開」状態にして起きたエラーのときだけ送られ、手動実行では送られない。失敗したコネクタを自動で再試行（リトライ）する機能や、途中から再開する機能の記載は無い。 エラー通知メールの宛先は追加・変更できる（別記事）。前回 「公開されていない」 としたのは、コーポレートサイト側にこの説明が無いためだった。 | イベント（「メールを受信したら…情報が追加・更新・削除されたら…」）／定期（「特定の日や曜日、時間を指定して起動」「年月日・曜日・時間など特定の時期にワークフローを実行」）／手動 ベンダー公表JENKAの機能（トリガー・…()
JENKAの機能（トリガー・実行設定） ベンダー公表 ℹ️ヘルプセンターで補足（2026-08-11）：起動は 3 システム。① 定期実行（トリガー）コネクタ＝JENKA 内部スケジュール。実行間隔は 分／時間／日／週間／か月 から選び、既定は 15 分（原文「※デフォルト間隔は15分です。」）／② Webhook(受信) コネクタ＝コネクタごとに用意される URL に外部から GET または POST（原文「主にWebアプリケーション内で、特定のイベントが発生したらJENKAに対して通知する機能です。」）。後続コネクタにパラメータを渡すには一度テスト受信を実行しておく必要がある／③ 各サービスのトリガーコネクタ（18 件）＝Email メール受信検知、Gmail・Outlook のメール受信検知、Slack・Teams の投稿検知、Google Calendar/Drive/Sheets・Excel・OneDrive・Dropbox の更新検知、Zoom のレコーディング／要約完了検知、DX Suite の読取ユニット更新検知。加えて手動実行がある（トリガーコネクタは手動実行時にはスタートコネクタとして動く）。トリガーコネクタはコネクタ実行数にカウントされない（原文「・コネクタの実行数にカウントされないです。」）。
採取元: JENKAの機能（トリガー・実行設定）
調査日 |
| JOINT iPaaS for SaaS | コネクタごとの「エラー設定」で、エラー時に別のワークフローを実行できる（エラー時のワークフロー） ログ画面で失敗したワークフローのエラーメッセージを確認する運用。 「また、各コネクタの 「エラー設定」 では、エラー発生時の動作を設定できます。」／「「エラー時のワークフローを実行する」を選択することで、エラーが発生した際に指定したワークフローを実行できます。」／「エラー時のワークフローは、通常の処理でエラーが発生した場合にのみ実行されるワークフローです。」。自動リトライ・途中再開についての記述は、確認したページには無い。（ヘルプページの本文は HTML の __NUXT_DATA__ に入っており、静的取得のままで読める） | 7 種類（スケジュール／手動／Webhook／状態変更／MCPツール ほか） 7 種類: スケジュールトリガー／手動トリガー／手動（フォーム付き）トリガー／コネクタトリガー（Webhook）／インスタンスステータス変更／汎用httpトリガー（Webhook）／MCPツール。 原文（ヘルプ「トリガーの設定」の表。左列の見出しが「トリガーの種類」、右列が「実行シーン」）。左列と右列を「」で分けて写す: 「スケジュールトリガー」→「定期処理を行いたい」／「手動トリガー」→「ユーザー操作で開始したい」／「手動（フォーム付き）トリガー」→「ユーザー操作で開始したい」／「コネクタトリガー（Webhook）」→「外部SaaSからワークフローを起動したい」／「インスタンスステータス変更」→「インスタンスのステータス変更時にワークフローを起動させたい」／「汎用httpトリガー（Webhook）」（原文に注記「※コネクタトリガーが準備していない場合、汎用httpトリガーを利用します」）→「外部SaaSからワークフローを起動したい」／「MCPツール」→「MCPサーバーを構築したい」。スケジュールの種類は原文で「隔日」「隔時」「隔分」「曜日指定」「月初から」「月末」の 6 つ。（ヘルプページの本文は HTML の __NUXT_DATA__ に入っており、静的取得のままで読める） |
| Magic xpi | Web ベースのダッシュボードで実行状況・処理履歴・エラーを確認 アラート通知とドリルダウン分析、高速ロギングシステム（LogBack）とログ収集ツール 再実行・途中再開についての明示は無い。 | スケジューラー／Webサービス・HTTP／キュー・メール・ファイル・DB 監視／SAP・Salesforce 監視 ほか スケジューラー（カレンダー、インターバル）／WEBサービス（WebServiceプロバイダー）／HTTP（Webアプリケーション）／キュー監視（MSMQ・JMS・WebSphereMQ・iSeries Data Queue）／E-Mail受信／フォルダー内のファイル監視／データベース監視（MS-SQL・Oracle・DB2・DB2/400・MySQL・PostgreSQL）／SAP Business One監視／SAP A1監視(iDOC)／SAP ERP監視(iDOC)／Salesforce監視／SugarCRM監視／Exchange2007監視／ServiceMax監視／MQTT／リモート起動（TcpTriggerTool） 追加・更新・削除の差分だけを取る「差分抽出機能」が併記されている。 ベンダー公表Magic xpi 製品詳細…()
Magic xpi 製品詳細 トリガー機能 ベンダー公表 ℹ️【2026-08-11 追記】技術情報サイトの「各製品の機能比較」にトリガー区分の全 28 件がある: Directory Scanner／Email／Exchange／HL7／HTTP／IBM i／JMS／MSMQ／Salesforce／SAP ERP／SAPB1 2004／SAPB1 2005／SAPB1 2007／SAPB1 8.8／ServiceMax／Sugar／TCP Listener／Web Service／WebSphere MQ／スケジューラ ユーティリティ／Azure Service Bus【xpi 4.14.1】／DBTrigger／EDI／FileWatcher／Kafka【xpi 4.14.1】／MQTT／OData／RESTful API。FAQ の原文「トリガーには「アダプタ/コネクタ」の他にスケジューラ、フォルダ監視、HTTP、WebService、Email等を設定します。トリガーの条件が満たされた時に、そのフローは起動します。」
採取元: Magic xpi 製品詳細 トリガー機能
調査日 |
| Make（メイク） | 警告の印から種類と原因データを辿れる ベンダー公表 未完了実行（Incomplete executions）を有効にすると、エラーが起きた時点の状態が保存され、原因を調べて直したうえで続きから終わらせることができます。この設定を入れるとエラーはすべて警告として扱われます。Retry の受け皿を使う場合はこの設定が必須で、失敗した分は未完了実行として貯め、設定に応じて自動で再試行するか、利用者が自分で解消するまで置いておくかを選べます。エラーがどの受け皿でも処理されなかった場合はメールで知らされ、繰り返しのエラーで自動化が止められたときにも知らせが届きます。 未完了実行の保管がいっぱいになったときの挙動も定められており、データ損失を許さない設定なら自動化そのものを止め、許す設定なら実行を続けて保管できない分を捨てます。 エラーが起きると編集画面の該当する処理に警告の印が付き、印をクリックするとエラーの種類とメッセージ、原因になったデータの束を確かめられると案内されています。 | 編集部がまだ確認していません |
| n8n | 自動化ごとに「失敗したときに走らせる別の自動化」を指定できます。指定した側は Error Trigger から始める決まりで、そこからメールや Slack で知らせる、といった処理を組めます。失敗時に受け取れる情報には、実行の識別子と画面へのリンク、エラーの内容、最後に動いた処理の名前、そして再試行だった場合は元の実行の識別子が含まれます。途中からの再開もあり、Save execution progress を Save にしておくと、エラーのときに止まったところから続きを実行できます（そのぶん遅くなるとの注記つき）。失敗した実行の調べ方としては、実行履歴の確認とログの外部への流し込みが案内されています。 料金プランの比較表には Automatic retries が挙げられています。意図的に失敗させて上の仕組みを走らせるための Stop And Error という処理も用意されています。 ベンダー公表n8n ドキュメント「Han…()ほか 2 件
採取元: n8n ドキュメント「Handle errors gracefully」・n8n ドキュメント「Configure workflow settings」（Save execution progress）・n8n 料金ページ 比較表（Workflow execution）
調査日 | 編集部がまだ確認していません |
| Qanat Universe | ― 確認したもの: 製品ページに本文が無い。 調査日 | ― 確認したもの: 製品ページに本文が無い。 調査日 |
| Reckoner | 実行履歴・ログ管理／エラーブロックの特定／実行結果通知（メール・Slack）／ワークフロー単位でのテスト 再実行・途中再開の可否についての記載は機能ページ・料金ページ・FAQ には無い。 | 定期実行（5分 / 時間 / 日 / 週 / 月など）／Webhook トリガー実行／即時実行（手動） |
| SaaStainer by JOINT | SaaS 事業者向けの説明として、保守・運用を GMO AIコネクト側が行うと明記 SaaS 事業者向けの説明として、保守・運用（システム監視／障害対応＝影響範囲の確認・原因究明と切り分け／バージョンアップ対応）を GMO AIコネクト側が行うと明記 利用者側の画面で再実行できるか等の機能の話ではなく、運営側の運用体制の話である点に注意。 | Webhook（出来事を契機）と、時刻指定の定期実行の両方が実例として公開されている（例:「毎日00:00に連携」） （freee人事労務 to カオナビ の紹介）「freee人事労務で新規作成/更新した従業員情報を毎日00:00に連携し、カオナビに自動登録/更新します。」利用者が契機を選べるという説明は無い — 既製アプリごとに決まっている形。 |
| TROCCO | 「GUIで通知や再実行も、コード管理でCI/CDも」。途中再開（失敗ノードからの再開）の可否は公開ページで確認できなかった。 ベンダー公表TROCCO ワークフロー（…()
TROCCO ワークフロー（ジョブ管理） ベンダー公表 ℹ️Docs「通知設定について」（https://documents.trocco.io/docs/notification.md、保存: raw/docs_notification_20260811.md）の原文「通知を設定することで、転送ジョブの実行状況や結果に応じた通知を受け取ることができます。 設定するには、通知先（通知に使用するサービスの設定）を作成し、その後に通知設定を作成する必要があります。」。通知先は Slack（Webhook URL を発行して登録）とメールがある。
採取元: TROCCO ワークフロー（ジョブ管理）
調査日 | スケジュール実行（毎時／毎日／毎週／毎月）と、TROCCO API によるジョブ実行 ワークフロー機能では条件分岐・リトライ・並列実行数制御・通知も設定できる。 「すべての機能で以下の4種類のスケジュール頻度を設定できます。」＝毎時（hourly）／毎日（daily）／毎週（weekly）／毎月（monthly）。タイムゾーン設定と複数スケジュールの登録が可能。API 側はでエンドポイント一覧に「転送ジョブ実行 POST /api/jobs」がある（利用は 30日トライアルまたは Advanced プラン以上）。製品サイトのワークフローページ https://primenumber.com/services/trocco/features/workflow/ の原文は「条件分岐、リトライ、並列実行数制御、通知、スケジュール実行など、ワークフロー運用に必要な設定が可能です。」（保存: raw/feature_workflow_20260811.html）。外部 SaaS からの Webhook でワークフローを起動する契機は、確認したページには見つからなかった。 ベンダー公表TROCCO Docs「スケ…()ほか 1 件
採取元: TROCCO Docs「スケジュール機能について」（Markdown 版）（Docs「スケジュール機能について」）・TROCCO API リファレンス 概要
調査日 |
| Waha! Transformer | 切り戻しは「設定の版を戻す」機能であって、実行の途中再開ではない。ジョブの再実行・失敗通知の記載は無い。 | 手動実行のほか、トリガー機能・コマンドライン・メール・REST 連携から実行できる スケジュール（定期実行）の明示は無く、「トリガー機能」の中身もページでは説明されていない。コマンドライン起動があるため外部ジョブスケジューラからの起動が前提と読めるが、それは推測なので値には書かない。 |
| Yoom | ― 編集部まとめ出典()
料金プラン（プラン比較表を全項目確認） 確認したもの: 再実行・自動リトライ・失敗通知・途中再開に当たる説明を、製品トップ・機能ページ（アプリ連携／データ変換／ブラウザ操作）・料金プランのプラン比較表・利用規約で探したが見当たらない。この社は機能ページを「できること」の紹介で構成しており、失敗したときの扱いを説明した公開ページが無い（ログインの内側にあるかどうかは、編集部からは分からない）。 調査日 | ポーリング頻度はプラン依存で 15 分／10 分／10 分／5 分／5 分に一度。Webhook の受け取りは 1 分あたり 60／120／120／300／600 件が上限。データコネクトの同期は 1 日 1 回〜1 時間に 1 回。 |
◎ 条件なしで当てはまる ○ 条件つき・一部 △ 限定・要申請・無いと明記 × 当てはまらないと明記 ？ 編集部がまだ確認していません ― 提供元が公開していない（編集部が調べた） — 記号は編集部の札から機械で付けています。物差しは項目ごとに違い、列の見出しがその項目の意味です。札の意味と根拠は各セルの要約を押すと出ます。
材料の調査日（最新）: 2026-09-07