自動化が壊れた日に何が出るか — 止まるか、間違えたまま進むか
4 分で読む
自動化の道具が壊れた日、あなたの画面には何が出るのでしょうか。
「エラー」「失敗」「警告」「完了（エラーあり）」「バックグラウンド処理は完了したが、一部の項目でエラーが発生」「停止済み」「中止」「無視」「エラーを無視」「アボート」「リトライ」「フロー再起動」「ジャンプ」「要対応（Needs attention）」「アウトプットは false」「エラーメッセージは表示されず、自動的に操作番号7へ移動します」「エラーとして返ってこない」……。
この中で、あなたが気づけないのはどれですか。 上はすべて、業務自動化の製品が実際に使っている「壊れたときの状態名」です。全部が全部、赤い文字で止まって知らせてくれる訳ではありません。中には、成功と同じ顔をして終わるものがあります。
先に結論を 1 行だけ書いておきます。「RPA は止まる、AI は間違えて進む」は、公開資料の上では成立しませんでした。
壊れ方は 2 つではなく、4 つあった
用語を先に置きます。RPA（Robotic Process Automation）は画面を人と同じ手順でなぞる道具、iPaaS（Integration Platform as a Service）はシステム同士を配線でつなぐ土台、AI エージェントは指示を受けて手順まで自分で決めて実行する AI です。
45 件の記述を全部読んでから、文章が実際に答えている形で 4 つに割りました。あらかじめ用意した選択肢に押し込んではいません。
| 記号 | 何がテキストに書いてあるか | 読者にとっての意味 |
|---|---|---|
| S1 | ベンダーが既定は止まると書いている | うるさい壊れ方。気づける |
| S2 | ベンダーが止まらない・そのまま進むと書いている | 静かな壊れ方。自分で見に行かないと気づけない |
| S3 | 設定で決まる（両方できると書いてあるが、初期値がどちらかは書かれていない） | 契約前には分からない |
| S4 | その問いに答える記述が無い（探して見つからないか、本文が別の軸を語っている） | 契約前にも契約後にも、公開情報からは分からない |
S1 と S2 は「怖さの向き」が反対です。 S1 は業務が止まって迷惑がかかりますが、止まった事実は見えます。S2 は業務が流れ続けますが、間違った結果が下流に配られたことに誰も気づきません。
そして実際に読んでみると、一番多いのは S3 と S4でした。多くの製品では、「うちの設定だとどっちに倒れるのか」を買う前に確かめる方法が、公開情報の中に存在しません。
どちらが怖いかは、業務で決まる
45 件を読んで残ったのは、製品の優劣ではなく問いの立て方でした。
| 業務の性質 | 怖いのはどちらか | 探すべき記述 |
|---|---|---|
| 止まると困る（受注・出荷・請求の締め、当日中に終わらせる処理） | 止まる壊れ方が怖い | 途中から再開できるか。やり直しは自動か手動か |
| 間違うと困る（人事・給与・会計・外部への送信、あとから直せない登録） | 静かに進む壊れ方が怖い | 既定が「止まる」か。部分失敗が「完了」に混ざらないか |
| どちらも困る | 記述が無いことが一番怖い | 既定を明記しているか。ログの保持期間を公開しているか |
そのうえで、契約前に投げる質問を 5 つに絞りました。どれも、公開情報だけでは相当数の製品について答えが出せなかった問いです。
| # | 聞くこと | ここで見つけた根拠 |
|---|---|---|
| 1 | 何も設定しなかったとき、エラーで止まりますか、進みますか | 45 件中 18 件はその記述が無く、11 件は「選べる」とだけ書いて初期値を書いていない |
| 2 | 一部だけ失敗したとき、全体は「成功」になりますか | SaaStainer は「完了（エラーあり）」、ActRecipe は「警告」で正常終了扱い |
| 3 | 失敗を、誰がどこで知りますか | Power Automate はポータルから実行すると通知が出ない。MICHIRU RPA はメッセージを出さない設定を選べる |
| 4 | 失敗した分は、送り直せますか。途中から再開できますか | SaaStainer は送り直せず手作業。AUTORO・Jenka・JOINT iPaaS は記述が見つからない |
| 5 | 実行の記録は何日残りますか。誰が見られますか | Jenka は利用者 2 週間・社内 13 か月。batton・BizRobo!・AUTORO などは期間が公開されていない |
| 持ち帰り | 一言 |
|---|---|
| 種類では決まらない | 「RPA だから止まる」「AI だから進む」は公開資料では成立しなかった |
| 静かな失敗は AI の専売ではない | ベンダー自身が静かな壊れ方を書いていた 11 件のうち、8 件は AI ではない |
| 一番怖いのは「書いていない」 | 45 件中 18 件は、その問いに公開情報で答えていない |
各製品の製品のページは IT連携マップの道具一覧で、出典 URL と調査日つきに公開しています。手段そのものの向き不向きは「つなぐ手段の比較」に、66 製品を 6 つの役に分けた全体像は「業務自動化の言葉が多すぎる」にあります。
ここから先は調査の詳細です（約 19 分）。上のカードだけで決められます。調べた 1 件ずつの記録は IT連携マップ に、出典 URL と調査日つきで公開しています。
調査の詳細
このページの答えは、以下の調べで出しました。対象・確認時期・出典を並べます。
ここでは、AI エージェント 13 件・RPA 12 件・iPaaS／ワークフロー 20 件、合わせて 45 件の公開ドキュメント・ヘルプ・利用規約を 1 件ずつ開き、**「失敗したとき、その先の処理はどうなるのか」**だけを抜き出して並べました。金額でも機能一覧でもなく、壊れ方の質だけを見ています。
調査日 — AI エージェント 13 件は 2026-08-26 時点、RPA・iPaaS 32 件は 2026-08-13／2026-08-11 時点の公開情報です。2 つの群で 2 週間ずれており、同時点の比較ではありません。 規約もドキュメントも月単位で変わります。
実装はしていません。公開資料と、編集部の調査記録を読んだだけです。動かした結果は書いていません。 総論では「安定性・壊れ方」を一つの観点としてまとめましたが、ここではそのうち壊れ方だけを取り出して細かく割ります（全体像は「業務自動化の言葉が多すぎる」に）。
ここでの調査範囲について
- 実装していません。 公開資料と、編集部の調査記録を読んだだけです。動かした結果は書いていません。
- 対象は AI エージェント 13 件・RPA 12 件・iPaaS／ワークフロー 20 件の計 45 件です。日本の自動化製品の全体ではありません。「45 件中 9 件」を「業界の○%」と読み替えることはできません。
- 確認時期は AI エージェントが 2026-08-26、RPA・iPaaS が 2026-08-13／2026-08-11 です。2 群で 2 週間ずれています。 MCP の対応状況だけは 45 件すべてを 2026-08-26 に取り直しています。
- 「公開情報を確認した範囲では見つからなかった」と「その機能が無い」は区別しています。 ログインの内側にある資料は読めていません。Yoom の失敗時の扱いのように、公開ページに無いだけで、ログイン後には説明がある可能性があります。
- hubflow は到達不能でした。 hubflow.jp・www.hubflow.jp とも DNS の A レコードが空で名前解決に失敗（2026-08-11・2026-08-26 の両日）。中身は 1 項目も採れていません。 上の 45 件には数に入れていますが、内容の比較には入っていません。
- Anyflow Automation は「調べていない」に近い状態です。 公式サイトが JavaScript で本文を描く作りで、取得した HTML に題名しか入りませんでした。他の「見つからなかった」と同じ列に置かないでください。
- 「RPA に何ができて、何ができないか」は書いていません。 編集部の調査記録では、その項目を RPA と iPaaS の 32 件についてそもそも採っていないためです。AI エージェント側だけ「できないこと」が書けてしまうので、その非対称を隠さずに書きませんでした。
- 誤り率・成功率・精度の比較はしていません。 調査記録にその数字がありません。「AI の方が間違えやすい」「RPA の方が確実」という文は、このデータからは 1 文字も出せません。
- AI エージェント 13 件は開発向けに偏っています（一般業務向けは Agentforce・Claude Cowork・CrewAI・Manus の 4 件）。情シスや管理部門の業務にそのまま当てはまる母集団ではありません。
- モデルの賢さや将来性は評価していません。 ここが見たのは、壊れたときに何が起きると書いてあるか、だけです。
45 件を割ってみた — 止まるか進むかは、種類では決まらない
| 群 | S1 止まる | S2 止まらない | S3 設定次第 | S4 記述なし | 計 |
|---|---|---|---|---|---|
| AI エージェント | 2 | 3 | 5 | 3 | 13 |
| RPA | 4 | 0 | 3 | 5 | 12 |
| iPaaS・ワークフロー | 3 | 4 | 3 | 10 | 20 |
| 合計 | 9 | 7 | 11 | 18 | 45 |
内訳は全部出します。数え方を疑う人が自分で確かめられないと、この表は意味を持たないからです。
| 記号 | 銘柄 |
|---|---|
| S1（9） | AI: Codex・Kiro／RPA: MICHIRU RPA・Power Automate デスクトップ フロー・ロボパット・WinActor／iPaaS: ASTERIA Warp・Magic xpi・Yoom |
| S2（7） | AI: Claude Code・GitHub Copilot・Manus／RPA: 0 件／iPaaS: ActRecipe・AUTORO・IIJ Connectivity Data Platform・SaaStainer |
| S3（11） | AI: Antigravity・Cline・CrewAI・Devin・OpenClaw／RPA: Coopel・マクロマン・UiPath／iPaaS: Anyflow Embed・Jenka・TROCCO |
| S4（18） | AI: Agentforce・Claude Cowork・Cursor／RPA: アシロボ・batton・BizRobo!・EzRobot・SynchRoid／iPaaS: Anyflow Automation・bindit・BizteX Connect・Datable・hubflow・HULFT Square・JOINT iPaaS・Qanat・Reckoner・WAHA! Transformer |
この表から読めることを 3 つ。
第一に、「RPA だから止まる」も「AI だから進む」も成立していません**。** 「既定は止まる」と明記している RPA は 12 件中 4 件しかなく、逆に「止まらない」と明記した iPaaS は 4 件、AI エージェントは 3 件ありました。
第二に、RPA の S2 が 0 件なのは「止まるから」ではありません。「そう書いていないから」です。 実際、RPA の 3 件は「エラーを無視して進む」設定を持っています（次の節で原文を出します）。選べるのに、初期値が書かれていない。
第三に、最大の塊は S4（記述なし）で 45 件中 18 件、4 割です。 読者が一番知りたい問いに、5 社に 2 社は答えていません。
数え方の注意 — 総論では RPA と iPaaS の 24 製品を対象に数えました。ここでは AI エージェント 13 件を足した 45 件を、4 つに割り直しています。同じ数字ではありません。 分母が違う数字を足し引きしないでください。
⟹ ここでの芯は「種類で決まる」ではありません。既定がどちらに倒れているかを、買う前に読めるかどうかで決まります。
RPA の欄を調査記録から横に並べると、こうなります（記号や札をクリックすると原文・出典）。
比較項目:
| システム | 業務安定性 | ||
|---|---|---|---|
| 壊れ方（止まるか・間違えて進むか） | 失敗したときの扱い | 実行ログの保持 | |
| アシロボ（assirobo） | 実行中に画面の解像度を変えると誤動作する可能性がある、と動作環境の注意書きに書かれている。 誤動作の中身（そのあと何が起きるのか）は書かれていない。失敗したときに処理が止まるのか、そのまま先へ進むのかを説明した記述も公開ページに無い。機能の一覧に「エラー処理」という項目名が並び、エラーの時にメールで知らせる仕組みがあることまでは書かれているが、その中身は説明されていない。 | ― 確認したもの: 公式トップ・特徴・料金・よくある質問（両サイト）を確認した。再実行・通知・途中再開に関する記載は無い。お知らせに個別の不具合告知（ブラウザ起動（ユーザ情報引継ぎ）エラーの発生について）はあるが、これは製品の機能ではなく障害告知である。 調査日 | ― 確認したもの: 公式トップ・特徴・料金・よくある質問（両サイト）を確認した。実行ログの有無および保持期間に関する記載は無い。 調査日 |
| batton | ― 編集部まとめ出典()
batton RPA 製品ページ 確認したもの: 製品ページ・紹介ページ・よくある質問・特定商取引法に基づく表記を確認し、2026-08-26 に保存済みの全ページを「エラー」「失敗」「停止」「中断」「リトライ」「再実行」「異常」で走査した。失敗したときに処理が止まるのか、そのまま先へ進むのかを説明した記述は無い。マニュアルに当たるページ（batton.co.jp/help-page/）はサーバー側のエラーで表示されず、中身を読めない。 調査日 | ― 確認したもの: RPA 製品ページ・LP・FAQ を確認した。再実行・エラー通知・途中再開についての記載は無い。 調査日 | 利用者向けの実行ログ画面についての説明は無いが、サポートの説明として、ベンダー側が使用ログを見て活用状況を測り助言する、と書かれている。また「ギフトコード」機能で、利用者が作ったシナリオをベンダーのカスタマーサクセスが PC ごとに遠隔で確認できるとされる。保持期間は公開されていない。 保持期間は公開されていない。 |
| BizRobo! | ― 編集部まとめ出典()
BizRobo! Basic 製品ページ 確認したもの: 公開ページ 183 件の一覧から製品ページ（BizRobo! Basic / Lite / mini）・活用業務例 136 件の本文・操作検証実績・コネクタ紹介・導入事例の標本を確認した。失敗したときに処理が止まるのか続くのかを説明した記述は無い。活用業務例には「不備のあるデータについてのみ本部担当者にアラートを送信」といった文が出てくるが、これはロボットの作り方の例であって製品の挙動の説明ではない。製品ドキュメントに相当するものは公開側に見つからず、出来合いのロボットとコネクターは会員登録と同社の承認が要る場所（BizRobo! PORTAL）の内側にあるため確認していない。規約類の PDF 12 本もダウンロードしていない。 調査日 | RPA活用業務例の本文に「ロボットはデータに不備がないか確認し、不備のあるデータについてのみ 本部担当者にアラートを送信」「csv化した請求書とSAPの伝票データを突合し、不一致部分があれば担当者にアラートを送信」とある。これは製品機能の説明ではなく、ロボットの作り方の例である。再実行・途中再開・通知の仕組みを製品機能として説明したページは、開いた範囲では見つからなかった。 | mini の説明に「稼働したロボットの履歴がみれる」「BizRobo! miniではスケジュール実行の記録がとれるので安全に運用することができます。」とある。保持期間は公開されていない。 |
| Coopel（クーペル） | 「はい」ならエラーが起きても処理を続行し、「いいえ」ならエラーの場合は処理を中断する。 止まるか進むかはアクションごとに決める形になっている。「エラーを無視」はさまざまなアクションで使えるオプションで、設定項目は任意と説明されており、どちらが最初から選ばれているのかは書かれていない。別に「エラーを捕捉して実行」という制御のアクションがあり、その内側でエラーが起きたときだけ通知などを走らせられる（「エラーを無視」が設定されているアクションでは、エラーは無視される）。 | ヘルプセンターに「シナリオの実行結果を確認する」「シナリオの実行結果を通知する」「シナリオの実行状況や予約状況を確認する」の記事がある。再実行・途中再開の仕様は未確認（記事本文が取得できていない）。 | ― 確認したもの: 製品ページ・機能ページ・料金プランを確認し、ヘルプセンターの記事題名一覧（全 638 URL）も走査した。実行結果を確認する機能はあるが、保持期間を示す記載は見つからなかった。 調査日 |
| EzRobot | 性能の足りないパソコンでは、動きが遅くなったり、操作のタイミングがずれて思わぬ動きをすることがある、と注意している。 画面を見て操作するしくみのため、環境が変わると結果が変わりうることを、いくつかの箇所で断っている。ロボットが認識できるのはメイン画面だけで、リモートデスクトップでつなぐと接続元の解像度に合わせて画面の解像度が変わることがあり、画像認識や座標指定を使った手順は影響を受ける、とも書かれている。失敗した手順でシナリオが止まるのか、次へ進むのかは書かれていない（価格・製品紹介・サポート体制・よくある質問を通して読んだ範囲）。 | ― 確認したもの: 価格ページ・EzRobotとは・サポート体制・FAQ の全 5 章を確認した。再実行・エラー通知・途中再開のいずれについても記述が無い。事例（株式会社シルスフィア会計事務所様）に「ロボットが上手く動作する場合と動作しない場合があり、安定しないことがありましたが、サポートに相談し、解決策を提示してもらったことで動作が安定するようになりました。」とあり、失敗時は人とサポートで解決する運用が語られている。製品としてのエラー処理機構は公開ページからは判らない。 調査日 | ― 確認したもの: EzRobotとは・サポート体制・FAQ・価格ページを確認した。実行ログの機能・保持期間ともに記述が無い。 調査日 |
| マクロマン（MACROMAN） | 待っても要素が無ければエラーを返す ベンダー公表 「エラー時の処理」というコマンドを置くと、エラーが出たあと後続を止めるか続けるかを選べる。 選べるのは 処理を停止 と 処理を継続 の 2 つ。ほかに Try / Catch / Finally にあたる 4 つのコマンドがあり、途中から再開する「エラー再開」は無料プランには付かず、上位プランの機能。このコマンドを置かなかったときにどう扱われるかは、読んだ範囲には書かれていない。 画面の要素が出るまで待つコマンドは、待っても見つからなければエラーを返す。 よくある質問の「マクロマンの動きと画面の動きがズレてしまう」で案内されているコマンド。見つかればすぐ次へ進み、指定した秒数のあいだ見つからなければエラーになる。その後スクリプトがどうなるかは、この説明には書かれていない。 | サンプルスクリプトに「トライキャッチ（エラーキャッチ）」があり、「エラーキャッチを開始(Try)」「エラー発生時の処理(Catch)」「最終処理(Finally)」「エラーキャッチを終了」の4コマンドが公開されている。途中再開に当たる「エラー再開」は FREE には付かず、STANDARD 以上の「便利な機能（上位機能）」（2026年6月の ver6.2.0.0 で新設）。よくある質問はエラーの原因を「コマンドの不備によるエラー」「環境によるエラー」に分けて自己診断の手順を公開しており、それでも解決しない場合はユーザーコミュニティへ案内している。 エラー再開は上位プランの機能。 | 保存先は C:\Users\{PCのユーザー名}\Documents\MACROMAN\Logs。ローカルのファイルなので、保持期間は利用者側の運用次第であり、ベンダーが定めるものではない。 保持期間の定めは公開されていない。 |
| MICHIRU RPA | エラー処理が無い範囲では止まる ベンダー公表 次の実行は初期状態ではエラーを無視する ベンダー公表 「エラー処理」を置いていない範囲でエラーが出ると、メッセージが出て処理が止まる。 「エラー処理」という操作を置くと、そこから先はエラーが出ても止まらず、指定した操作番号へ移る、別の操作セットを呼ぶ、といった動きに変えられる。同じ設定で「エラーメッセージを表示しない」を選ぶこともでき、その場合はエラーが起きても画面に何も出ない。設定は次の「エラー処理」を置くまで有効で、「エラー処理クリア」で解除できる。ファイルのコピーのように、行き先に同じ名前がある場合の扱いを 上書き／「処理をスキップ」／「エラー停止」 から選ぶ操作もある。 前の実行がエラーで止まっていても、外から指示された次の実行は初期の状態ではエラーを無視して動く。 タスクスケジューラ・Chatwork・コマンドラインなどから実行を指示したとき、前の操作セットがエラーで止まっていると、初期の状態では確認のメッセージを出したうえでエラーを無視する動きになる。設定は 4 通りあり、確認を出さずにエラーを無視して動かす／エラーの画面を閉じるまで待つ／実行を中止する、のいずれかにも変えられる。確認のメッセージは 30 秒放置すると自動的に実行する側が選ばれる。 | 操作メニューの「実行順の制御」に「エラー処理」が含まれる。ヘルプセンターには「実行中にエラーが出たら」として「キー画像が見つかりません」「対象 Window が見つかりません」の対処ページがある。再実行（リトライ）や途中再開の仕様、失敗時の通知の仕組みについては、編集部が開いた範囲では説明を見つけられなかった。 | ― 確認したもの: 概要ページ・料金プラン・よくあるご質問・外部連携ページ・ヘルプセンターの項目一覧を確認した。実行ログの画面や保持期間についての記載は見つからなかった。 調査日 |
| Power Automate（デスクトップ フロー／Power Automate for desktop） | 止めずに続ける機能が試験公開されている ベンダー公表 操作ごとに、やり直す回数と、その後どう続けるかを決められる。 やり直しの初期値は 2 秒間隔で 1 回。やり直しても駄目だったときは 次のアクションに進む／アクションの繰り返し／ラベルに進む から選び、変数の設定やサブフローの実行も指定できる。複数の操作をまとめて扱う「ブロック エラー発生時」では、エラーの後にブロックの先頭から再開するか末尾から再開するかを選べる。これはパソコンの画面を操作する側（デスクトップ フロー）の話で、クラウド側から動かした場合に実行中の知らせが画面に出ないことは、同じドキュメントの「ランタイム通知」のページに書かれている。 要素が見つからないときに止めず、いちばんそれらしい要素を選んで続ける機能が試験公開されている。 画面の作りが変わって要素が見つからなくなったときに、実行時に最も可能性の高い正しい要素を選んで先へ進む、と書かれている。プレビューと明記された段階の機能で、1 つの要素だけを扱う一部の操作、かつ要素が見つからないというエラーにだけ効く。 ベンダー公表ドキュメント デスクトップ …()
採取元: ドキュメント デスクトップ フローでエラーを処理する（シングル アクションのエラーを処理する）・ドキュメント デスクトップ フローでエラーを処理する（UI とブラウザーの自動化のための自己復旧）
調査日 | 失敗の知らせ方は起動元で変わる ベンダー公表 既定ではエラーが起きた時点で止まる。アクションごとに「エラー時」を開くと、何秒おきに何回やり直すかを決められる（初期値は 2 秒間隔で 1 回）。やり直しても駄目だったときの続け方は 次のアクションに進む／アクションの繰り返し／ラベルに進む から選び、さらに 変数の設定 と サブフローの実行 も指定できる。複数のアクションをまとめて面倒を見る「ブロック エラー発生時」もあり、こちらは エラーの後にブロックの先頭から再開するか末尾から再開するかを選べる。直前に起きたエラーの中身（失敗したアクションの名前・場所・詳細など 6 項目）を取り出して、後続の処理で使うこともできる。 利用者の目の前で動かした場合は、Windows の通知か「フロー監視ウィンドウ」で 実行中・一時停止・停止・正常終了・エラー発生 が知らされ、通知から一時停止や停止もできる。クラウド側から起動した場合は通知が出ないとはっきり書かれている。 | 実行履歴は放っておくと消えない ベンダー公表 実行の記録は利用者のパソコンではなく、クラウド側のデータベース（Dataverse）に貯まる。アクションのログには 2 つの置き方があり、新しい方（フロー ログのテーブル）は保持期間を分単位で指定できる——1 日 = 1,440 分、7 日 = 10,080 分、28 日 = 40,320 分、90 日 = 129,600 分、365 日 = 525,600 分、0 は無期限。設定を変えても、それ以前に作られたログは元の期間のまま残る。ログを取ること自体も 有効（初期値）／実行時エラーのときだけ／無効 から選べる。古い方の置き方（実行 1 件の中に固まりで持つ）には自動で消す仕組みが無く、1 回の実行あたり 5 万〜8 万件が上限とされる。この設定を変えるには Premium の権利と管理者の権限が要る。 実行そのものの記録（開始と終了の時刻・状態・入出力・エラー時の画面の写し）には、自動で消える期限が定められていない。減らしたい場合は、管理者が「6 か月より古い実行を消す」といった条件を作り、定期的に走らせる形になる。消したものは元に戻せないとはっきり書かれている。 |
| ロボパットAI（Robo-Pat AI）／ロボパットDX | 止まったときの動きを手順ごとに決められる ベンダー公表 止まる前の画面が録画で残る。 自動レコーダー機能の説明が「予期せぬエラーでロボットが止まった場合」を前提に書かれており、止まる直前の画面を録画して保存すると説明されている。よくある質問の見出しも「ロボットがエラーで止まった時の対策などはありますか？」という立て方で、止まること自体は前提になっている。止めずに次の手順へ進める設定があるかどうかは、開いた範囲には書かれていない。 止まったときの動きは手順ごとに決めておける（例：担当者へメール）。手順ごとの再試行もある。 よくある質問の回答による。決めておけるのは止まったときに何をするかであって、止まらずに先へ進むという選択肢が用意されているかどうかは書かれていない。 | 例として、エラーが起きた時には担当者へメールを送らせる、という設定が挙げられている。途中再開（止まった工程から再開する）の記載は無い。 | ― 確認したもの: よくある質問一覧（43件）にはエラー箇所の特定に関する項目があるが、実行ログの保持期間を示す記載は、当方が開いた公開ページ（トップ・特徴・理由・サポート・トライアル・自動化できる業務・ツール個別5件・オプション・AIオプション・よくある質問回答11件）には無い。ローカルPC上で動く製品のため、ログの置き場も期間も利用者側の環境次第になる可能性があるが、それを述べた記述は見当たらなかった。マニュアルは robots.txt で拒否されているため未採取。 調査日 |
| SynchRoid（シンクロイド） | ― | ― 確認したもの: 製品ページ・ポータルの公開 5 ページを確認した。再実行・通知・途中再開の説明は無い。開発辞典の追加履歴に「リトライ処理をさせたいを追加しました。」「エラーメッセージを取得したいを追加しました。」（いずれも項目名のみ）があり、リトライを組めることは分かるが、製品が自動で再実行するのか、利用者がそう組むのかは公開情報では区別できない（辞典の項目名が「〜させたい」＝利用者が組む形であることを示唆する）。 調査日 | ソフトウェア構成ページの Management Console の機能に「ロボットの稼働ログ／データ管理」、同ページの詳細説明に「ロボット実行ログ、監査ログ情報管理」とある。保持期間は公開されていない。なお本番向けには「Tomcat 上に Management Console を構築し、MySQLなどのEnterprise 級のデータベースを使用することを推奨しています。」とあり、ログの置き場所は利用者が用意するデータベースと読める。 |
| UiPath | 例外を投げ直す／無視して次へ進む／やり直す／中止する、の 4 つから選んで決めておける。 実行エラーが起きたときのプロジェクトの動きを決める専用のワークフローが用意されていて、そこで返す値によって次の動きが決まる。「無視」を選ぶと、失敗しても次の手順から実行が続くので、止まらない作りにできる。1 つのプロジェクトにつき 1 つだけ置ける（部品をまとめたライブラリには置けない）。どれが初期値になるのかは、開いたページには書かれていない。なお、このページの日本語には機械翻訳が含まれるとページ自身が断っている。 | エンタープライズ プラン限定の機能として「自動化の自己修復」があり、説明は「Healing Agentが自動化の故障箇所の修正方法を提案し、実行時にUIオートメーションの問題箇所を修復します。」。画面変更に追随できないという RPA の弱点に、製品側が名指しで対処している。再実行・通知・途中再開といった一般的なエラー処理については、編集部が開いたページに記述が無い。 | ログ画面は 1 万件・50 KB まで ベンダー公表 クラウド版では実行（ジョブ）の記録に保持の決まりがあり、新しく作った処理から生まれた実行は、既定で 30 日たつと消える。処理ごとに変えられ、終わった実行は 1〜180 日（既定 30 日）、終わっていない実行は 30〜540 日（既定 180 日）。消す代わりに保管場所へ書き出しておく選び方もあり、その場合は後から読み返せる。消えるのは実行の記録そのもの（実行時の画面の記録を含む）で、元に戻せない。処理と結び付いていない実行には既定の 30 日が適用される。 ロボットが出したログは専用の画面で見られ、時刻・重要度（Trace／Debug／Info／Warn／Error／Fatal）・処理名・実行した端末名で絞り込み、CSV に書き出せる。制限もはっきり書かれている——1 度に返るのは 1 万件まで、50 KB を超えるログは無視される、最初に表示されるのは前日ぶんだけ。フォルダーごとの閲覧権限が要る。 |
| WinActor | 目印が見つからないと通常は止まる ベンダー公表 止めずに続ける作り方も配られている ベンダー公表 画面上の目印が見つからないと、通常はエラーになってシナリオが止まる。 見本の解説の中で、画像で目印を探す手順が該当なしになった場合の既定の挙動として説明されている。画面が変わって目印が見つからない、という一番起きやすい失敗がここに当たる。ただし例外処理グループで囲んでおけば、止めずに別の処理へ移せるとも同じ文で説明されている。 止めずに続ける作り方も見本として配られている（Excel のマクロを別立てで動かす例）。 止まらないのは既定の挙動ではなく、そう作った場合の話である点に注意。この見本は Excel のマクロを別立てで動かすことで、マクロ側でエラーが出てもシナリオを止めない形にしている。 | 「例外処理グループを用いてシナリオを停止するサンプルシナリオ」「遷移先画面を検知して例外処理を実行するサンプルシナリオ」「監視ルールを使用してウェブページのエラーダイアログを検知するサンプルシナリオ」が公開されている。再実行（リトライ）・途中再開・失敗通知に関するまとまった説明は、開いた範囲では見つからなかった。 | サンプルシナリオが使う部品の一覧に「01_WinActor制御/08_実行ログ/ログメッセージ出力.ums6」が現れる。保持期間は公開されていない（そもそも実行は利用者の PC 上なので、保持はファイルの置き方次第と読める）。 |
◎ 条件なしで当てはまる ○ 条件つき・一部 △ 限定・要申請・無いと明記 × 当てはまらないと明記 ？ 編集部がまだ確認していません ― 提供元が公開していない（編集部が調べた） — 記号は編集部の札から機械で付けています。物差しは項目ごとに違い、列の見出しがその項目の意味です。札の意味と根拠は各セルの要約を押すと出ます。
材料の調査日（最新）: 2026-08-13
RPA の中ですら、既定が逆を向いている
同じ「RPA」という 3 文字の中で、既定の向きが割れています。ベンダーの原文をそのまま並べます。
| 製品 | 原文 | 出典 |
|---|---|---|
| Power Automate デスクトップ フロー | 「既定では、デスクトップ フローはエラーが発生すると実行を停止します。」 | ドキュメント |
| WinActor | 「画像マッチングの該当無しとなった場合、通常はエラーとなりシナリオが停止しますが、例外処理グループ内で実行しているため、アクション例外へ処理が移動します。」 | 見本の解説 |
| UiPath | 「無視 - 例外を無視して、次のアクティビティから実行を続行します。」／「中止 - 現在のグローバル例外ハンドラーを実行した後に、実行が中止されます。」 | 手引き |
| Coopel | 「* はい：エラーが発生しても、処理を続行します。」／「* いいえ：エラーの場合、処理を中断します。」 | ヘルプセンター |
| MICHIRU RPA | 「そのため、この範囲でエラーが発生してもエラーメッセージは表示されず、自動的に操作番号7へ移動します。」 | 操作一覧 |
上の 5 件は全部 RPA です。上 2 つは止まり、下 3 つは止めない選択肢を持ちます。
そして UiPath と Coopel については、どれが初期値なのかが、開いたページには書かれていませんでした。「無視」と「中止」が並んでいるだけで、何も触らずに導入したときにどちらで動くのかが分かりません。
30 秒放置すると「実行」が選ばれる
MICHIRU RPA には、もう一段あります。外部から実行を指示されたときの動作について、公式ページはこう書いています。
「表示されてから30秒以内に操作が行われなかった場合は、自動的に「実行」が選択されます。」（外部連携）
確認画面は出るのに、席を外していると「実行」側に倒れます。「人が確認する仕組みがあります」という説明と、「人が見ていなくても進みます」という挙動は、両立します。
静かに壊れる 11 件 — うち 8 件は AI ではない
ここで一番、直感に反する結果です。ベンダー自身が「気づかないまま進む形」を書いている 11 件を集めたら、AI エージェントは 3 件しかありませんでした。
| 群 | 製品 | ベンダー自身が書いていること |
|---|---|---|
| iPaaS | Yoom | 「一部アプリ（Slack、GMOサイン等）ではエラーとして返ってこないため、テスト時にアウトプットに値が入っているかどうかで成功/失敗をご判断ください。」（ヘルプ） |
| iPaaS | SaaStainer | 処理状態の区分名が「バックグラウンド処理は完了したが、一部の項目でエラーが発生」（ヘルプ） |
| iPaaS | ActRecipe | 「警告：レシピの全体実行自体は正常終了したものの、注意が必要な状態です。」＝一部処理できなかったレコードが別の名前で記録される（ヘルプ） |
| iPaaS | Magic xpi | 「そのためデータマッパはエラーがあるにも関わらず、レコードの処理を継続することになり、結果的に終了（Exit）設定を無視することになります。」（技術情報 PDF） |
| iPaaS | AUTORO | 要素が見つからないエラーを無視して進む設定について「この設定は、デフォルトではONの状態になっています。」／「エラー発生時の実行結果（アウトプット）は「false」が取得されます。」（サポート） |
| iPaaS | IIJ Connectivity Data Platform | 通信エラー時に同じフローを 3 回までやり直す。「リトライしないよう変更することはできませんが、以下の方法でリトライを回避できます。」（質問集） |
| RPA | MICHIRU RPA | エラー処理で「エラーメッセージを表示しない」を選べる＝エラーが起きても画面に何も出ない |
| RPA | Power Automate デスクトップ フロー | ポータルから実行したときは通知を出さないと明記（ランタイム通知） |
| AI | GitHub Copilot | 点検には作り話の危険があり、実在しない問題や、コードの読み違いに基づく指摘をすることがあると明記（公式） |
| AI | Manus | 注意書きを出すだけで、手伝いを断ったり会話を止めたりはしないと明記＝注意書きは出すが会話は止めない（公式ヘルプ） |
| AI | Claude Code | 作業を失敗させたり囲いを切らせたりする代わりに「逃げ道」を用意すると明記＝隔離で失敗しても止まる側には倒れない（公式） |
静かな失敗は AI の特徴ではなく、自動化一般の特徴です。 11 件のうち 8 件は AI ではありません。
しかも iPaaS 側の静かさには、AI には無い種類があります。Magic xpi の「終了を選んだのに続く」 は、利用者が明示的に「止めろ」と設定した指示が無視される場合がある、という自己申告です。AUTORO の「デフォルトで ON」 は、何も知らずに導入した人が最初から静かな側に置かれる、ということです。
「通知があります」と書いてあるだけの 4 件
機能の名前はあるのに、中身が分からないものもありました。これは「静かではない」の証拠にはなりませんので、別に置きます。
| 製品 | 製品のページが書いている注意 |
|---|---|
| アシロボ | 機能一覧に「エラー処理」の項目名とメール通知はあるが、中身の説明が無い |
| BizRobo! | アラート送信は**製品機能ではなく「ロボットの作り方の例」**として描かれている |
| BizteX Connect | 「アプリケーションのエラーは随時担当者が確認しております」＝提供側の運用体制であってフローの挙動ではない |
| Reckoner | 機能名の羅列のみ |
AI エージェントは「間違える」を規約に書いている
AI エージェント側の特徴は、間違えることを隠していない点です。しかもヘルプではなく、利用規約に書いてあるものがあります。
| 製品 | 原文 | どこに書いてあるか |
|---|---|---|
| Cursor | 「この機能を有効化することにより、あなたは、自動生成されたコードの実行に伴うあらゆるリスク（システム停止、ソフトウェアの欠陥、データ損失、セキュリティ脆弱性などを含みますがこれらに限られません）をすべて引き受けることを認識し、これに同意するものとします。」 | 利用規約 1.7 |
| Antigravity | (a) AI エージェントが行った操作と作業の責任は、利用者が単独で負う | 追加利用規約 |
| GitHub Copilot | 実行されたコマンドの最終的な責任は利用者にある | 責任ある利用 |
| Devin | その出力は網羅的ではない補助にすぎず、利用者自身の点検・試験・監査・独立した検証の代わりにはならない | 利用規約 8.2 |
| CrewAI | 作り話は、言語モデルが、もっともらしいが事実として誤っている・与えた文脈で裏づけられない内容を生むときに起きる／検査役は仕事に検査役を付けたとき＝仕事ごとに付けて初めて働く | 公式ドキュメント |
| OpenClaw | 失敗の大半は珍しい攻撃ではなく「誰かが話しかけて、その通りに実行してしまった」もの | 公式ドキュメント |
規約に書いてある、ということは「起きる前提で設計されている」ということです。 責任の所在が先に決められています。読んだ RPA 12 件の失敗時の記述の中には、ここまで正面から「誤る」と書いているものはありませんでした（**無い、という意味ではありません。**同じ範囲では見つからなかった、という意味です）。
AI エージェントの欄も同じ形で並べます。
比較項目:
| システム | 業務安定性 | |||
|---|---|---|---|---|
| 壊れ方（止まるか・間違えて進むか） | 失敗したときの扱い | 実行ログの保持 | 検証環境 | |
| Agentforce（エージェントフォース） | 有害と判定された生成物は表示前に遮る ベンダー公表 自分の手に負えない用件に当たったときは、人の担当者に引き継ぐと公式に説明されている。 これは会話の相手をする場面についての説明で、処理そのものが失敗したときに止まるのか続けるのかを述べたものではない。後者を説明した記述は、開いた範囲では見つからなかった。 生成された内容は表示前に検査され、有害と判定されたものは利用者に見せる前に自動で遮られる、と公式に説明されている。 検査の対象として挙がっているのは、憎悪表現・偏り・嫌がらせなど方針に反する兆候。答えの内容が業務上正しいかどうかを判定する仕組みではない。 | 外部から呼び出して使う場合、応答は 120 秒で打ち切られ、打ち切られたときはエラーが返る。同時に処理できるのは 1 件だけで、重ねて送ると別のエラーが返る。 返ってくるエラーの種類ごとに、何を確かめればよいかを並べた案内が開発者向けドキュメントにある（該当のエージェントの識別子が違う／認証の設定が違う／宛先が違う／送信データの形式が違う、など）。会話は「開始・やり取り・終了」の 3 段階で扱い、途中の文脈は開始した会話の中で保たれる。 | ― 編集部まとめ出典()
Einstein 基盤のセキュリティ文書 確認したもの: 信頼できる AI のページには、Trust Layer の機能のひとつとして監査証跡が挙がっている。また Einstein 基盤のセキュリティ文書（PDF）には、提供に使う各システムがそれぞれの記録の仕組みか集中管理の仕組みへ情報を記録すること、利用者のアクセス記録に日付・時刻・部分的な URL を残すことが書かれている。しかし、いずれも自社の安全管理のための記録についての説明で、利用者がエージェントの実行内容をどれだけの期間さかのぼって見られるのかを示す記述は無い。料金ページの比較表にも保持期間の行は無い。 調査日 | ― 編集部まとめ出典()
Einstein 基盤のセキュリティ文書 確認したもの: 公式製品ページ（日本語）・仕組みのページ・料金ページ・開発者ドキュメント（Agent API の 4 ページ）・Einstein 基盤のセキュリティ文書（PDF）を開いたが、Agentforce を試すための検証用の環境について書いた記述は無い。PDF には、機能ごとに環境を分けていること（とくに検証用と本番）が書かれているが、これは提供側の構成についての説明で、利用者に検証環境を用意するという記述ではない。関連する案内が置かれている help.salesforce.com は JavaScript で描画されるため機械では本文が取得できない。 調査日 |
| Antigravity（Google） | エージェントの行為の責任は利用者 ベンダー公表 計画を立ててから実行する使い方では、変更を加える前に必ず止まって承認を求めるか、一切止まらずに実行するかを、設定で選ぶ。既定として勧められているのは、止まって承認を求める側。 これは「人が見る前に変更が入るかどうか」の設定であって、実行が失敗したときに処理を止めるのか続けるのかを説明したものではない。後者を述べた記述は、開いた範囲では見つからなかった。なお、隔離を有効にしている場合は、コマンドを実行する直前に「隔離を外して実行する」という逃げ道が選択肢として出る。 規約は、エージェントが行った行為の責任は利用者にあると定め、本番環境で使う場合は、起こしうる被害を避けるために判断と監督を行うことを利用者の責任として挙げている。 | 会話を丸ごと複製して別案を試す枝分かれの仕組みがあり、試した結果がだめなら元の枝に戻れる。 枝分かれで複製されるのは会話だけで、手元のファイルは複製されないと公式に注意されている。ファイルまで分けたい場合は、版管理側で枝を分けるか、変更を退避しておくよう案内されている。会話の履歴は作業フォルダごとに区切られる。 | 会話の履歴は手元の作業フォルダごとに残り、いつでも選び直して再開できる。 どれだけの期間残るのかを示す記述は、開いた範囲では見つからなかった。規約には、利用者のデータ・操作の記録・関連する情報を記録して保存すること、削除を希望する場合は所定のメール宛先に依頼できることが書かれている。 | コマンドライン版に、基本ソフトの機能を使って実行を閉じ込める仕組みがある。既定では無効で、設定ファイルで有効にする。有効にすると、実行前の確認に「隔離を外して 1 回だけ実行する」という選択肢が出る。 閉じ込め方は Linux が nsjail、macOS が sandbox-exec、Windows が AppContainer。無効にしている場合でも、危なそうなコマンドはその場で「隔離して実行する」を選べる。仮想マシンを立てる方式ではないと明記されている。 |
| Claude Code | 照合できない命令は承認を求める側に倒れる ベンダー公表 隔離の壁に阻まれてコマンドが失敗したとき、失敗の中身が出力に足されてそのまま渡り、別のやり方（壁の外で実行し直す）を試すことがある。作業を止める側には倒れない。 止めたい場合は、その逃げ道を設定で閉じられる。閉じると、すべてのコマンドは壁の中で動くか、あらかじめ例外に挙げられているかのどちらかになる。壁の外での実行し直しは通常の承認の流れに戻るため、手動の設定では確認を求められる。 照合できなかったコマンドは、手動の設定では承認を求める側に倒れると明記されている。 原文の見出しは「Fail-closed matching」。ただしこれは権限の照合についての記述で、作業そのものが失敗したときの扱いではない。 | 入力のたびにコードの状態が自動で控えられ、あとから「コードだけ戻す」「会話だけ戻す」「両方戻す」を選べる。中断した作業も再開できる。 控えは 1 セッションにつき直近 100 件まで。セッションごと 30 日で消え、期間は設定で変えられる。戻せない範囲がはっきり書かれており、シェルコマンドが書き換えたファイル、サブエージェントが加えた編集、外部からの変更、リンクで結ばれたファイルは戻らない。 | 作業の記録は手元のパソコンに 30 日間そのまま残り、期間は設定で変えられる。 Anthropic 側に残る期間は契約で分かれ、商用（Team／Enterprise／API）は 30 日、個人契約はモデルの改善にデータを使うことを許可していれば 5 年、許可していなければ 30 日。ブラウザで動かす形態では、その中の操作がすべて記録されると別ページに書かれている。 | シェルコマンドをファイルとネットワークの両面で隔離して動かす仕組みが本体に入っている。macOS・Linux・WSL2 で動き、Windows をそのまま使う形には対応していない。 既定では作業フォルダとその回だけの一時フォルダにしか書き込めず、書き込み先や通信先は設定で広げられる。ブラウザで動かす形態では、作業ごとに切り離された仮想マシンが割り当てられ、一定時間使われなければ回収されると別ページに書かれている。 |
| Claude Cowork | 道具の実行が失敗すると、その結果に失敗した印と失敗の内容が残る。Claude への要求が失敗したときはやり直しが行われ、何回目かが記録される。 失敗したあとに、その先の作業を止めるのか続けるのかを説明した記述は、開いた範囲では見つからなかった。記録の項目としては、成功したかどうか・失敗の内容・試行回数までが公開されている。 | 道具を 1 つ動かすごとに、成功したか失敗したか、失敗したときのメッセージ、かかった時間が記録に残る。Claude への要求が失敗したときは何回目の試行かも残るので、やり直しが行われていることが分かる。 誰の判断で許可・拒否されたか（あらかじめの設定／その場の許可／利用者の中断／利用者の拒否など）も記録される。これらは組織向けの記録の書き出しの説明にある項目で、書き出し先は利用する側が用意する。作業を途中から再開する仕組みについては、開いた範囲では記述が見つからなかった。 | 既定では中身は含まれず、指示文や応答本文、道具のやり取りは設定で明示的に有効にしたときだけ含まれる。 書き出し先は利用する側が用意するため、どれだけ残すかは利用する側が決める。Cowork 自身がこれらの記録をどれだけの期間持つのかを示す記述は、開いた範囲では見つからなかった。 | ― 編集部まとめ出典()
公式ドキュメント（概要） 確認したもの: 公式ドキュメントの概要（claude.com/docs/cowork/overview）と記録の書き出し、公式製品ページ、料金ページ、稼働状況ページを開いたが、試すための隔離された環境について書いた記述は無い。概要には Claude Code と同じ仕組みを使うと書かれているが、Cowork の側でそれをどう扱うかは書かれていない。 調査日 |
| Cline（クライン） | ひとつずつ承認する設定なら操作のたびに止まり、自動承認にすると止まらずに進む。公式ドキュメントは、自動承認では気づく前に多くの変更が加わりうると書き、控えからの巻き戻しを前提にするよう案内している。 すべてを自動で承認する設定については、起こりうることとして「警告なしに大事なファイルを消す」「システム設定を変えるコマンドを実行する」「設定ファイルを上書きする」「パッケージを入れたり消したりする」「版管理に変更を確定して送信する」が公式に列挙されている。安全でない扱いにするコマンドは固定の一覧ではなく、モデルがコマンドごとに判定すると明記され、「これは例であって保証ではない」と書かれている。 | 作業の各段階で控えが取られ、「ファイルだけ元に戻す」「会話だけ元に戻す」「両方戻す」を選んで戻せる。前の指示を書き直して、そこから先の変更をまとめて取り消すこともできる。 承認が必要になったときと、自動で承認したコマンドが 30 秒を超えて動き続けているときは、基本ソフトの通知で知らせる設定がある。 | ― | ― 編集部まとめ出典()
公式ドキュメント（自動承認） 確認したもの: 公式ドキュメント（自動承認・控えと巻き戻し・初めての方向け）と、公式サイトの料金・企業向けページを開いたが、製品の側が用意する試用のための隔離環境についての記述は無い。自動承認の説明には、まず使い捨ての企画や隔離した環境で試すよう利用者側の準備を勧める記述があり、企業向けの機能一覧には自社の閉じたネットワーク内への配置が挙がっている。 調査日 |
| Codex（OpenAI） | 確認役を自動の別の判定に切り替えている場合は、許可されればそのまま進み、拒否されたときは「もっと安全な別の道を探す」か「止めて人に聞く」よう指示が返る。 壁の中で許される範囲の操作は、確認も判定も通らずそのまま進む。隔離した状態では動かせないコマンドは、通常の確認の流れに戻る。 | 開始・継続・再開の呼び出しが用意されている ベンダー公表 中断した対話は後から開き直して続けられ、外部から組み込む形でも同じように再開できる。取りかかる前後に版管理の目印を作って、あとから元に戻せるようにすることが公式に勧められている。 行き先（手元・作業用の複製・クラウド）を選び間違えたときは、実行を取り消して直前の指示を呼び戻せる。変更の見比べでは、直近のひと区切りだけを取り出して見ることもできる。 外部から組み込む形では、対話を開始・継続・再開する呼び出しが用意されている。 | 企業向けの記録の基盤に残る分は 30 日。会話は組織の設定に従い、削除した会話は原則 30 日以内に完全に消される予定に入る。 実行時の状態や作業の控えは会話とは別の扱いで、会話を消しても関連するものがすべて即座に消えるわけではないと明記されている。どの操作が記録に出るかは事象と発生した場所によるとされ、シェルの実行・ブラウザ操作・ファイル操作・承認のすべてが記録に出ると考えてはいけないと書かれている。 | 手元で動かすとき、コマンドは既定で隔離された環境の中で実行される。読み取りだけ・作業場所への書き込みまで・制限なし、の 3 段階があり、既定は作業場所への書き込みまで。 隔離は基本ソフトの仕組みで行われ、macOS は標準の機能、Windows は標準の機能または WSL2、Linux と WSL2 は追加の部品を入れて実現する。クラウドで動かす場合は、仕事ごとに切り離された仮想環境で動く。 |
| CrewAI（クルーAI） | もっともらしいが事実と違う答えが出ることを公式に認めており、企業向けの機能として、出来上がりを参照資料と突き合わせて 0〜10 点で採点する検査役が用意されている。検査に落ちた仕事は、完了扱いにならずに失敗として扱われる。 この検査役は仕事ごとに付けて初めて働く。付けていない仕事の出来上がりが突き合わされることはない。点数の合格ラインは自分で決められ、公式には重要な内容なら 8〜10、一般的な内容なら 6〜7 が目安として示されている。1 回の検査で 1〜3 秒ほど余計にかかるとも書かれている。 | 検査に落ちると、その理由が担当のエージェントに差し戻され、直しては検査という往復が、通るか、決めた回数に達するまで繰り返される。 検査役には、自分で書いた検査の処理を渡す形と、言葉で条件を書いて言語モデルに判定させる形の 2 種類がある。往復の上限は仕事ごとに数値で指定する。人の入力を待たせる指定も、仕事の項目として用意されている。 | 使ったモデル、担当ごとの経過時間、道具の使用と出力、消費量と概算費用、仕事ごとの状態（完了・実行中・失敗）が残る。 どれだけの期間残るかを示す記述は、開いた範囲では見つからなかった。書き出し先として OpenTelemetry と外部の監視サービスへの連携が用意されており、そちらに送れば保持は送り先の決まりに従う。 | ― |
| Cursor | 規約は、生成される提案に誤りや誤解を招く情報が含まれうること、その評価とそれに伴うリスクは利用者が負うことを明記しています。さらに、人の確認を経ずにコードの提案を自動実行する機能があり、それを有効にした場合はシステム停止・不具合・データ損失などのリスクをすべて利用者が引き受ける、と定めています。 自動実行が有効なときは画面にその旨が明示されると規約に書かれています。誤った方向へ進んだ場合に備えて、作業中に自動で作られる復元ポイントから戻す運用が案内されており、失敗したら処理を止めるという説明は見当たりません。 | 作業の途中に自動で復元ポイントが作られ、変更前の状態にファイルだけを戻せます。復元ポイントは利用者の端末に保存され、Git とは別の仕組みだと明記されています。 戻るのはファイルだけで、やり取りの履歴は残ります。恒久的なバージョン管理には Git を使うよう案内されています。 | ― 編集部まとめ出典()
公式ドキュメント コンプライアンスと監視 確認したもの: エンタープライズ向けの監査記録のページ、データ利用の説明ページ、セキュリティページ、料金ページを開いた。監査記録は Enterprise で利用でき、SIEM・Webhook・S3 へ転送して長期保管できると案内されているが、Cursor 側で何日保つのかを示す数字は無い。エージェントの応答や生成コードの中身は記録しないとは明記されている。 調査日 | ― 編集部まとめ出典()
料金ページ（プラン比較） 確認したもの: 料金ページの機能比較、公式ドキュメントのトップとエージェント概要、エンタープライズ向けのプライバシー・コンプライアンスの各ページを開いたが、本番と分けて設定を試すための検証環境の提供に関する記載は無い。Enterprise には自動実行・ブラウザ・ネットワークの制御という項目があるが、これは実行時の制限であって別環境の提供ではない。 調査日 |
| Devin | 規約は、出力が不正確だったり用途に合わなかったりすることがあり、使う前に人の確認が要るかどうかを判断する責任は利用者にあると定めています。コードの点検結果についても、問題をすべて拾えるとは保証せず、利用者自身の確認・テスト・監査の代わりにはならないと明記しています。 レビュー機能の指摘も、確信度の高い「不具合」と、利用者が自分で調べて実際に問題かどうか確かめる「要調査」に分けて示されます。設定を入れれば、指摘や CI の失敗に人手を介さず自動で対応し続けます。 | プルリクエストの指摘や CI の失敗に対して、自動で修正案を出して直しに行く設定（Auto-Fix）が用意されています。既定では入っておらず、組織の管理者だけが有効にできます。 有効にすると、見つけた不具合の横に修正案が並び、差分の画面からそのまま適用できます。指摘が無い要約だけのコメントには反応しません。 | 日数の記載なし。取引が続く間は保持 ベンダー公表 保持期間を日数で示した記載は無く、取引関係が続くあいだ保持する、と説明されています。 やり取りの記録や利用状況のデータは必要な期間だけ保持し、期間は会社側が決めるとも書かれています。作業の経過そのものは、画面上で作業ごとの記録として後から追えます。 | 作業は利用者の端末ではなく、シェル・エディタ・ブラウザを備えたクラウド上の作業環境で行われ、そこで自分の変更を動かして確かめられます。外部ツールの接続設定を保存する前には、隔離された確認用の環境を立ち上げて接続を試す仕組みもあります。 本番と分けた検証用の契約や環境が別途売られているわけではなく、作業そのものが独立した環境で走る形です。 |
| GitHub Copilot | 公式の「限界」の章が、存在しない問題を指摘してしまうこと、一見正しく見えても意味的・文法的に誤ったコードを出しうること、生成したコードに脆弱性が含まれうることを明記し、いずれも人が確認して試すよう求めています。止まるのではなく、誤ったまま先へ進みうる前提で書かれています。 端末側では危険なコマンドの実行前に許可を求める仕組みがあり、実行されたコマンドの最終的な責任は利用者にあると明記されています。 | 端末側の対話では、危ない可能性のあるコマンドを実行する前に許可を求めます。クラウドで動く方は、作った変更をプルリクエストとして出し、そこに付いた指摘を受けて自分で直しに戻ります。 クラウドで動く方が触れるのは、そのプルリクエストの枝だけです。既定の枝に直接反映することはできず、他のリポジトリにも入れません。各コミットの説明に、その作業の記録へのリンクが入ります。 | それより長く残したい場合は、外部の監視基盤へ流して保管するよう案内されています。 入力と提案そのものの扱いは別で、法人向けの既定では保持されず、個人向けでは 28 日間保持されると案内されています。利用状況のデータは 2 年間保存されます。 | ― 編集部まとめ出典()
公式ドキュメント 責任ある利用（エージェント） 確認したもの: プランと価格の比較表、公式ドキュメントの入門・責任ある利用・企業向けアカウント・監査記録の各ページを開いたが、本番と分けて設定を試すための検証環境の提供に関する記載は無い。代わりに書かれているのは、クラウドで動くエージェントが触れる範囲の制限（そのプルリクエストの枝だけ、他のリポジトリには入れない、専用の環境に入れた秘密情報以外は使えない）で、これは実行時の制限であって別環境の提供ではない。 調査日 |
| Hermes Agent（ヘルメス・エージェント） | 編集部がまだ確認していません | 編集部がまだ確認していません | コンテナによる隔離が security の層の 1 つとして挙げられている ベンダー公表 | |
| Kiro（AWS） | まかせきりで動かす設定のときは、途中で判断がつかなくなると勝手に進めず「要対応」の状態に移り、利用者の入力を待ちます。この設定は既定では切ってあり、切っている間は一手ずつ一緒に進める形です。 作業は隔離された環境で行われ、成果はプルリクエストとして出てくるため、確認してから取り込む前提になっています。誤った内容のまま先へ進んだ場合にどう扱うかを述べた記述は、開いた範囲には見当たりません。 | まかせきりで動かす設定のとき、途中で判断がつかなくなると作業は「要対応」の状態に移り、利用者の入力を待って止まります。プルリクエストに書いた指摘には自動で対応して更新を積み、特定のやり取りだけ直させる指示も出せます。 進み具合は作業画面から追え、各段階の報告が出ます。 | 管理者が有効にすると、利用者の入力と応答が記録され、保存先は自社の AWS 環境内の指定した置き場になります。提供側が何日保つという定めではなく、保持期間は自社側の設定で決まります。 無料枠の利用者については、規約違反の検知のために入力を最長 60 日間保存することがあると、サービス個別条項に書かれています。記録機能そのものに追加料金は無く、保存先の費用だけがかかります。 | ブラウザから使う形では、作業ごとに隔離された環境が立ち上がり、必要なリポジトリだけを複製して作業し、終わると片付けられます。中には画面のない Chrome と操作用の道具が入っていて、直した画面をその場で確かめられます。 外に出られる宛先は設定で絞れます。本番と分けた検証用の契約が別に売られているわけではなく、作業そのものが毎回この隔離環境で走る形です。 |
| Manus（マヌス） | 公式ヘルプは、自信ありげに見えても不正確・不完全な内容を出すことがあると認めたうえで、重要な判断に関わる話題では注意書きを出すものの、手伝いを断ったり会話を止めたりはしないと明記しています。つまり誤ったまま先へ進みうる形で、確かめるのは利用者の側とされています。 一方、混雑でシステム側が作業を打ち切ったときは止まり、続けるか、やめてクレジットの払い戻しを受けるかを利用者が選べます。 | 作業用の仮想環境との接続が長く切れたままになると、環境は自動で作り直されます。作業の進み具合と履歴は残りますが、その環境の中に置いてあったファイルは作り直しの際に失われると明記されています。混雑で作業が打ち切られたときは、続けるか、やめてクレジットの払い戻しを受けるかを選ぶ画面が出ます。 進み具合が失われた場合は、ヘルプ内の窓口へすぐ連絡するよう案内されています。 | ― 編集部まとめ出典()
公式ヘルプ 作業環境の不具合 確認したもの: ヘルプセンターの作業環境・不具合・データの退避と復元の各カテゴリと、稼働状況ページを開いたが、実行の記録を何日保つかを示す数字は無い。代わりに書かれているのは作業用の仮想環境の作り直しの方針で、無料の利用者は 7 日、有料の利用者は 21 日使わないと自動で作り直されるとされている（これは環境の寿命であって記録の保持期間ではない）。 調査日 | 作業はクラウド上の隔離された仮想環境で行われ、利用者はその中の画面を見たり、途中で自分で操作を代わったりできます。環境は作り直されることがあり、その際に中のファイルは失われますが、作業の進み具合と履歴は残ると説明されています。 本番と分けた検証用の契約が別に売られているわけではなく、作業そのものが毎回この隔離環境で走る形です。 |
| OpenClaw（オープンクロー） | 公式ドキュメントは、この種の失敗の大半は珍しい攻撃ではなく「誰かが話しかけて、その通りに実行してしまった」ものだと述べ、モデルは操られうる前提で被害範囲を小さく設計するよう求めています。一方で、隔離環境を明示的に指定した実行は、その環境が用意されていなければ動かずに落ちる（安全側で止まる）と明記されています。 実行の許可を毎回求めるかどうかは設定で、個人用の構成では既定で許可を求めない側に倒してあり、それは意図した使い勝手であって欠陥ではないと書かれています。厳しくするかどうかは利用者が決める形です。 | 症状から順にたどる切り分けの手引きと、健全性の点検・設定の移行・修復手順をまとめて実行する点検コマンド（openclaw doctor）が用意されています。動作の記録はコマンドで取り出せ、会話ごとの記録も端末上のファイルとして残ります。 モデルの選択や、つながらないときの切り替えについても別途手引きがあります。自分で設置して動かす形なので、対処は利用者自身が行います。 | 動作の記録は利用者の端末のファイルとして日付ごとに書き出され、会話の記録も端末上に残ります。どちらも提供元が消すのではなく、長く残す必要が無ければ利用者が自分で古いものを消すよう案内されています。 記録の中の秘密情報は伏せられ、伏せる対象は自分で足せます。診断のために共有するときは、記録そのものではなく秘密情報を伏せた状態表示を使うよう勧められています。 | 隔離した環境で実行する仕組みはありますが、既定では入っておらず、利用者が自分で有効にする形です。切ってある状態では、行き先を自動に任せた実行は常駐させている端末そのもので走ります。隔離環境を明示して指定した場合は、環境が用意されていなければ実行されずに落ちます。 危険度の高い道具（コマンド実行・ブラウザ操作・外部取得）は、信頼できる相手や明示した許可一覧に絞るよう勧められています。強い境界が要る場合は、OS の利用者や機器そのものを分けるよう求めています。 |
◎ 条件なしで当てはまる ○ 条件つき・一部 △ 限定・要申請・無いと明記 × 当てはまらないと明記 ？ 編集部がまだ確認していません ― 提供元が公開していない（編集部が調べた） — 記号は編集部の札から機械で付けています。物差しは項目ごとに違い、列の見出しがその項目の意味です。札の意味と根拠は各セルの要約を押すと出ます。
材料の調査日（最新）: 2026-09-05
ただし、止まる側に倒す AI もある
「AI＝止まらない」で終わらせると、これも嘘になります。既定で止まる側に倒している製品が、はっきり存在します。
| 製品 | 原文 |
|---|---|
| Kiro | まかせきりは既定で切／実行中に確認が要るときは「要対応」の状態に移り、利用者の入力を待つ（公式） |
| Codex | 承認されれば実行を続け、拒否されれば明らかに安全な道を探すか、止まって利用者に尋ねる側へ倒す（公式） |
| Antigravity | 提案した変更に進む前に必ず止まり、明示の承認を求める／もう一方の設定は止まって人の点検を求めず、計画をそのまま実行に移す（公式） |
| Cline | 控えが無いまま自動承認にすると、問題に気づく前に多くの変更が積み上がるので不安が残る（公式） |
Antigravity の 2 行は、同じ製品の中に「必ず止まる」と「決して止まらない」が設定として両方あることを示しています。怖さを決めているのは製品名ではなく、その設定を誰がどう決めたかです。
気づいたあと、戻せるのか／途中から再開できるのか
壊れ方を見たら、次は直し方です。ここで AI 側と RPA・iPaaS 側で、思想がはっきり分かれました。
| 直し方 | 群 | 製品と、ベンダーが書いていること |
|---|---|---|
| 戻す（本体に取り消しが入っている） | AI | Claude Code: 自動の控えを取る。ただし控えは bash コマンドが書き換えたファイルを追跡しない（公式）／Cline: ファイルだけ・会話だけ・両方を選んで戻す／Cursor: 控えが保存するのはセッション中のコードの側の断面」（公式） |
| 戻すのは版管理任せ | AI | Codex: 製品機能ではなく、作業前後に控えを取る運用の勧め |
| 途中から再開 | iPaaS・RPA | TROCCO: 「ワークフロージョブが失敗した状態からジョブを再実行すると、停止したタスクから再実行がスタートします。」（ドキュメント）／ASTERIA Warp: チェックポイントで途中から復帰／Power Automate デスクトップ フロー: ブロックの先頭・末尾から再開／Anyflow Embed: 実行履歴から再実行 |
| 送り直せない | iPaaS | SaaStainer: 「※連携エラーが発生した情報は、再度連携を通して登録することはできません。」（ヘルプ）→ 受け取り側を手で直す |
| 記述が見つからない | iPaaS | AUTORO（同じ処理の自動やり直しの記載は無い）／Jenka／JOINT iPaaS／WAHA! Transformer（「切り戻し」は設定の版を戻す機能であって実行の途中再開ではない） |
「戻す」と「途中から再開」は、別のことです。 AI 側は「やった変更を無かったことにする」方向、iPaaS・RPA 側は「止まった場所から続きをやる」方向に道具が作られています。
そして両方に、はっきりした穴があります。Claude Code の控えはコマンドが書き換えたファイルを追いません。SaaStainer は失敗した分を送り直せません。どちらも、ベンダー自身がそう書いています。
あとから追えるのか — 記録が残る期間
「AI は静かに間違えるから、記録で見張ればいい」——その処方箋を書く前に、記録側の実態を見ておく必要があります。
| 残り方 | 製品と期間 |
|---|---|
| 提供側が期間を明示 | Claude Code 30 日（設定変更可）／GitHub Copilot 監査 180 日・プロンプトと提案 28 日／Codex Compliance Logs 30 日／Kiro 無料枠は最長 60 日／UiPath 既定 30 日・最長 180 日／Jenka 利用者には 2 週間・社内には 13 か月（ヘルプ）／TROCCO 365 日（ドキュメント）／Anyflow Embed 30 日／IIJ CDP 約 90 日固定／HULFT Square 過去 1 か月 |
| 利用者側が置き場と期間を決める | Kiro（自社の AWS）／Claude Cowork／OpenClaw（消すのは利用者）／マクロマン（利用者のパソコン内）／WinActor（PC 上）／SynchRoid（利用者が用意する DB）／ASTERIA Warp（日数を指定） |
| 保持期間の記載が見つからない | batton・BizRobo!・WinActor・AUTORO・Antigravity・Claude Cowork・CrewAI／Devin は日数の記載なし |
| 記録に出るとは限らないと明記 | Codex: シェルのコマンド・ブラウザ操作・アプリの呼び出し・ファイル操作・承認のすべてが、利用者に見える監査の書き出しに出てくると思ってはいけない（公式） |
WinActor・Claude Cowork・Kiro が 2 か所に出てくるのは、間違いではありません。「どこに残るか」は書いてあるのに、「何日残るか」が書かれていないという状態が実在するからです。ログの置き場が自社の中でも、いつ消えるかを決めた文書が無ければ、監査のときに出せる保証はありません。
数で見ると、「あとから何が起きたか追えるか」に答えがあったのは AI エージェント 13 件中 10 件、RPA 12 件中 7 件、iPaaS 19 件中 8 件でした（iPaaS は到達不能の 1 件を除いた数）。とくに iPaaS 側は、19 件中 11 件が「探したが公開されていない」です。
⟹ 「AI は記録で見張れ」と書くなら、同じ段で「その記録の期間を公開している会社の方が少数派だ」と書かないと片手落ちになります。
Jenka の 「利用者には 2 週間・社内には 13 か月」 は、この落差を一番きれいに示しています。同じログでも、見られる人によって寿命が違います。
止まっている間も、お金は減るのか
壊れ方は、支払い方にもつながります。何を数えて課金するかを並べると、2 つの群がきれいに分かれました。
| 群 | 何を数えるか | 件数 | 内訳 |
|---|---|---|---|
| RPA | 置いた数（ライセンス・PC 台数・ボット数・同時実行数） | 12 件中 9 | アシロボ・BizRobo!・EzRobot・MICHIRU RPA・Power Automate・ロボパット・SynchRoid・UiPath・WinActor |
| AI エージェント | 使った量（クレジット・トークン・実行回数・ACU） | 13 件中 10（うち 3 件は席との併用） | Antigravity・Cline・Codex・CrewAI・Devin・Kiro・Manus ＋ 席併用の Claude Code・Cursor・GitHub Copilot |
⟹ RPA は動かさなくても払う。AI エージェントは動かすほど払う。
壊れ方と重ねると、同じ「壊れた」でも財布への効き方が逆になります。RPA が止まって週末を越えても請求は変わりませんが、AI エージェントが間違ったまま作業を続ければ、その分だけクレジットは減ります。
例外もあります。UiPath だけは「ユーザー数＋ロボット数＋エージェント呼び出し数」（価格ページ）で、置いた数と使った量の両方をまたいでいます。batton は「アカウント数」で PC 台数では課金せず、マクロマン にいたっては台数でも実行数でもなくサポートの厚さが価格の軸でした。
課金の単位そのものを数え上げた話は姉妹編に譲ります（3 層の見積もりの読み方は「API・iPaaS・RPAの料金を調べてみた」に）。ここで言いたいのは 1 点だけです。「止まる怖さ」と「進む怖さ」は、請求書の形まで違う。
併用は「これから」ではなく、もう製品の中にある
「RPA を AI エージェントの手足にする」という話は、よく聞きます。実際にどこまで来ているのかを、MCP（Model Context Protocol、AI と道具をつなぐ共通の差込口）の対応状況で数えました。この項目だけは 45 件すべてが 2026-08-26 に取り直してあり、群をまたいで厳密に横に並べられます。
| 群 | 両方（サーバーにもクライアントにもなる） | クライアントのみ | サーバーのみ | 探したが公開されていない |
|---|---|---|---|---|
| AI エージェント（13） | 4 | 9 | 0 | 0 |
| RPA（12） | 1 | 0 | 0 | 11 |
| iPaaS・ワークフロー（20） | 0 | 0 | 2 | 18 |
日本市場の RPA 12 件のうち、MCP に触れているのは UiPath 1 件だけでした。
| 製品 | 原文 |
|---|---|
| UiPath | MCP を本体で支え、MCP サーバーをエージェントの流れの一部として作る・置く・つなぐことができる（Orchestrator ドキュメント） |
| Magic xpi | 企業向けの MCP サーバーとして使うと、既存の業務処理を、どの AI エージェントからも呼べる安全な「道具」に変えられる（製品ページ） |
| JOINT iPaaS | 生成 AI や SaaS・オンプレミスなど多様な業務システムを横断的に連携させる、API コネクタ付きの MCP 構築基盤だと説明（お知らせ） |
「AI が RPA の壊れ方を直す」も、すでに製品名になっている
壊れ方そのものに AI を当てる動きも、2 社で見つかりました。ただし、どちらも条件つきです。
| 製品 | 原文 | 条件 |
|---|---|---|
| UiPath | 「レジリエンスの高い、自己修復可能なUIオートメーションを構築」（価格ページ） | エンタープライズ プランの欄に書かれている |
| Power Automate デスクトップ フロー | 「自己復旧では、要素が見つからないときにフローを停止するのではなく、実行時に最も可能性の高い正しい要素を特定し、フローの実行を続行できます。」（ドキュメント） | プレビューと明記された段階 |
ここには、全部が凝縮されています。「画面が変わって止まる」を直す方法が、「止めずに、たぶん正しい要素を推測して続ける」なのです。 うるさい壊れ方を、静かな壊れ方と交換しているとも読めます。どちらが自社にとって良いのかは、業務が「止まると困る」のか「間違うと困る」のかで反対になります。