Run it by と gotoHuman、Slackの承認、ワークフローのヒューマンタスクの違い

ひとことで言うと

ヒューマンインザループのツールの多くは、承認者がチームの一員であることを前提にしています。Slackにいる、レビュー用の受信箱に席がある、ワークフローエンジンのユーザーである、といった具合です。Run it byは逆の前提に立っています。承認者は、メールアドレスか電話を持つ誰でもよく、専用のリンクを受け取り、何にもサインアップしません。

他社製品に関する情報は、2026年10月に各社のページで確認したものです。最新の情報は、リンク先をご覧ください。

gotoHumanのようなレビュー用の受信箱

gotoHumanは、エージェントが提案した内容をチームがレビューする受信箱を中心に作られています。エディターでレビューの種類を定義し、エージェントがレビューを依頼し(そのためのMCPサーバーがあります)、レビュアーは受信箱から、またはメールやSlackの通知から操作し、結果はWebhookで返ります。料金は席数に応じて決まります。

エージェントの出力を毎日レビューする社内チームには、とても合っています。Run it byが向いているのは、その逆のケースです。チームの外にいる人(顧客、家主、他社のマネージャー)からの、1回限りの判断を求める場合で、相手は1つのリンクを開いたら二度と戻ってきません。

SlackやTeamsの承認

チャットツールの承認ボタンは、承認者が全員同じワークスペースにいるなら便利です。でも、1人でも外にいる(顧客、業者、別のチャットツールを使うパートナー)と、使えなくなります。Run it byのリンクはどのブラウザでも開けますし、Slackに自分で貼り付けることもできます。

人の手順を含むワークフローエンジン

フレームワークやエンジンが提供するのは、一時停止であって、ページではありません。LangGraphのinterruptはグラフを止め、コードが渡した値で再開します。Orkes Conductorのヒューマンタスクは、割り当てられたユーザーがフォームを送信するのを待ちます。どうやって相手に届けるか、何を見せるか、本人であることをどう証明するかは、自分で決める必要があります。

この2つは組み合わせられます。グラフを一時停止し、Run it byのリクエストを作成して、Webhookで判定が届いたら再開します。

並べて比較

選び方

• 自社のチームが一日中エージェントの出力をレビューする:レビュー用の受信箱。
• 承認者が全員Slackにいて、リスクが低い:チャットツールのボタン。
• ワークフローエンジンを運用していて、必要なのは一時停止だけ:エンジンのヒューマンステップに、相手に届ける手段を加える。
• 承認者がチームの外にいる、複数の人の同意が必要、または誰が判断したかを証明したい:Run it byの承認。