Cloudflare Agents と Workflows：それぞれの役割

Cloudflare Agents と Workflows の比較は、対話型アシスタントの仕事が会話より長く続くようになったときに役立ちます。エージェントは進捗を説明し、バックグラウンド処理は中断に耐えて承認を待つ必要があります。両者は関係する責任ですが、ライフサイクルは異なります。

イベントを受け取りユーザーと通信する、継続した対話の主体には Agents を使います。待機や再試行を含む永続的なバックグラウンド段階には、その実行モデルが適合する場合に Workflows を使います。会話と長時間の仕事を独立して進める必要がある場合に組み合わせ、外部の業務上の影響は明示的に照合できるようにします。

従業員が仕入先評価を依頼する場面を考えます。アシスタントは不足情報を尋ね、状態を表示します。評価処理は記録を集め、報告を作り、同僚の判断を待ちます。ブラウザーを閉じても仕事を失わず、再接続で評価を最初から始めない設計が必要です。

この記事では、この仮想設計で境界を説明します。すべてのアシスタントに両方の製品が必要とも、永続的な実行がすべての外部操作を安全に繰り返せるようにするとも考えていません。

Cloudflare Agents と Workflows：ライフサイクルを比べる

Cloudflare の Agents と Workflows の文書 は、補完する役割を説明しています。Agents は継続的な対話と識別情報を、Workflows は永続的なバックグラウンド実行を支えます。テンプレートを選ぶ前に、その役割から判断してください。

仕入先評価では、会話には従業員向けのライフサイクルがあり、仕事には業務のライフサイクルがあります。従業員が切断し、別の権限ある同僚が結果を確認し、最初のチャットが終わっても評価が待ち続けることがあります。

表は分担の設計案です。SDK の採用だけでアプリの権限モデルや業務状態の台帳が自動的にそろうという意味ではありません。

会話記録ではなく作業記録から始める

評価に安定した作業番号を与えます。責任者、資料版、要求された結果、現在状態を、会話の読み直しに依存しない形で保存します。会話は意図の説明には使えても、受け付けた仕事の唯一の記録にしてはいけません。

画面では、相談中の依頼と受け付け済みの仕事を分けます。従業員が送信して応答を失った場合、再接続で仕事の存在を確認できる必要があります。最後のチャットからモデルに推測させる方法は信頼できません。

入力待ち、証拠収集、確認待ち、承認、拒否、失敗など、業務責任者に意味のある状態を定義します。誰が状態を変えられ、どの証拠が必要かも含めます。

作業番号は対話画面が変わっても維持します。後のメールやダッシュボードは同じ受理済み評価を表示できますが、仕事の動きを決める第二の正本にはしません。

永続的な段階を説明できる大きさに保つ

Workflows の概要 は、永続的な複数段階の実行を説明しています。入出力と復旧動作が明確な段階に使います。資料収集、文章生成、複数システムの変更を一つの巨大な段階にすると、失敗時の調査が難しくなります。

評価では、資料取得、報告生成、承認済み判断の反映を分けます。報告を支えた資料版を記録します。資料変更後の再試行は、黙って異なる評価を作るのでなく、明示した方針に従わせます。

保存された段階の結果と、外部への影響の証明を混同しないでください。宛先が受理した直後に呼び出し側が応答を失うことがあります。何が起きたか確定する操作番号や照合方法がアプリに必要です。

段階境界は、次の行動を明確にできる場合に役立ちます。運用担当が、再試行、証拠更新、確認担当への連絡を選べないなら、境界に業務情報が足りない可能性があります。

承認を版付きの業務イベントにする

承認は正確な評価版と、その結果として起きることに結び付けます。確認ページを開いた後に資料や報告が変わったら、進む前に不一致を解決させます。

イベント到着時に確認担当を認証し、作業権限を調べます。評価を特定する URL だけでは承認権限になりません。ツールの結果や生成文を、同僚の承認に置き換えてはいけません。

取り消しも同様です。以後の段階を止めても、外部システムが受理済みの要求まで取り消せるとは限りません。止まった仕事と、なお照合が必要な結果をユーザーに示します。

正本の状態から再接続する

従業員が戻ったら、現在の権限で作業状態を読みます。最後に記録した段階と確認時刻を表示します。会話の要約は役立っても、推測した状態で作業記録を上書きしてはいけません。

進捗通知と正本の状態を分けます。通知を見逃しても、状態変更を失ってはいけません。逆に、通知を受け取っただけで、元の仕入先記録を閲覧できるようにもしてはいけません。

待機中、失敗後、他の同僚が操作した後の再接続をテストします。古い判断を送ろうとする開きっぱなしのタブも含めます。部署や交代勤務をまたぐ業務では、これらは通常の条件です。

当社のエージェント評価ガイド は、より広い結果のテストで、ツール呼び出しの成功だけでは足りない理由を説明しています。ここで重要なのは、正しい仕事が続き、ユーザーが本当の状態を見ることです。

必要を満たす最小の構成を選ぶ

短い照会をするアシスタントは、独立したバックグラウンド処理が不要かもしれません。定時のデータ変換には対話エージェントが不要かもしれません。両方を追加すると、設定、状態の関連、障害経路の保守が増えます。

構成は責任を明確にすべきです。現在状態を Agent と Workflow のどちらが管理するか説明できないなら、ツールを増やす前に契約を書きます。

調整と障害テストの予算を組む

システム数、状態変更、承認役割、結果不明の外部操作が増えるほど実装費用は増えます。チャットの文章量は、作業量のよい尺度ではありません。

作業設計、対話、処理実行、宛先連携、受入を分けた GBP の見積もりを求めます。依存関係の版の保守と、配置時に実行途中の仕事を扱う手順も含めます。

選ぶサービスと負荷について現行料金を確認し、待機、再試行、推論、保存、観測を分けて見積もります。めったに動かない仕事でも、業務上の影響が大きければ慎重な運用支援が必要です。

パイロットでは、ブラウザー終了、処理中断、承認重複、宛先タイムアウトを実演します。運用担当がチャットを再構成せず、評価を見つけて次の安全な操作を決められる状態を残します。

当社の範囲を限定した AI 連携パイロット で契約を定義できます。作業段階、接続システム、承認役割を添えてエージェントの業務処理案をご依頼 ください。実行基盤の選択を、チームが本当に完了すべき仕事に従わせられます。

よくある質問

Agents と Workflows は競合製品ですか？ 強みが異なり、組み合わせられます。Agents は継続した対話と識別情報に、Workflows は永続的なバックグラウンド段階に適します。毎回両方を使うのではなく、アプリのライフサイクルから選びます。

すべての AI アシスタントに Workflow が必要ですか？ いいえ。短い対話作業なら不要な場合があります。受け付けた仕事が独立して続き、イベントを待ち、定めた段階で復旧する必要があれば検討します。

永続実行は業務操作の重複を防ぎますか？ 外部システムについて考える必要は残ります。宛先は応答を失っても処理を完了できます。影響の大きな操作には安定した番号と記録された照合方針を使います。

承認状態はどこに保存しますか？ 正確な提案版と確認担当に結び付けた、正本の作業記録に保ちます。会話は判断を表示して説明できますが、唯一の承認記録にしてはいけません。

ユーザーがブラウザーを閉じるとどうなりますか？ 接続とは独立して受理済み作業を保ちます。戻ったらユーザーを認証して現在状態を読み、ジョブを最初から始めたり、モデルに進捗を推測させたりしません。

パイロットでは何を試しますか？ 通常の流れに加え、切断、処理中断、古い承認、重複イベント、宛先結果不明を試します。各状態の担当コンポーネントと復旧方法を報告に示します。

組み合わせた実装の費用はいくらですか？ 状態変更、システム連携、権限役割、復旧要件によります。チャット機能だけの単価ではなく、対話、処理、受入、サポートを分けた範囲付き GBP 見積もりを求めます。