AI自動化ツールはどう選ぶ？ワークフロー型・エージェント型を用途別に整理

AI自動化ツールを選ぶときは、「AIが使えるか」だけでなく、処理順を人が固定するワークフロー型と、状況に応じてAIがツールや経路を選ぶAgent型を分けて考えると判断しやすくなります。

Make公式Helpでも、standard scenarioはfixed rules、AI scenarioは固定ワークフローの一部へAI判断を入れる構成、AI agent scenarioはagentがpathを決める構成として整理されています。

先に結論：手順が変わるかどうかで型を選ぶ

表は横にスクロールできます

型	手順	AIの自由度	向く仕事
Workflow型	ほぼ固定	低い	定型連携・通知・転記
AI Step型	全体は固定	一部だけAI判断	要約・分類・抽出
Agent型	状況で変わる	高い	必要Toolや経路が都度変わる

「Agentの方が高度だから選ぶ」のではなく、固定フローでは表現できない部分があるかで判断します。

方式ごとの違い

Workflow型は処理順が決まっている仕事に向く

フォーム→Sheet→Slack、Gmail→分類→CRMなど、triggerとアクションがあらかじめ決まっている処理はワークフロー型で設計しやすくなります。

結果の再現性、audit、debugを優先する業務では固定flowが扱いやすいです。

AI Step型は一部だけ判断が必要な仕事に向く

全体flowは固定しつつ、途中で要約、分類、抽出、文章生成だけAIへ任せる形です。

AIの自由度を狭められるため、定型業務へ生成AIを入れる最初の形として使いやすくなります。

Agent型は経路自体が変わる仕事に向く

問い合わせ内容を見てknowledge検索、CRM確認、返信draft作成など、必要なツールが毎回変わる場合はAgent型が候補になります。

Make AI Agentは接続するツールを設定し、AIに判断・実行させる機能です。Zapier AgentsにもActionを使うエージェント機能がありますが、ZapierはAgentsをAI by Zapierへ移行中です。既存Agentsの説明を新規導入手順として使う前に、現在の提供画面と移行案内を確認してください。

自由度が高いほど監視項目も増える

Agent型では、どのツールを選んだか、何回callしたか、どこで止めるか、誤ったアクションをどう防ぐかを設計する必要があります。

「自律的だから手放しでよい」とは限りません。

比較するときの判断軸

外部ActionのRiskで選ぶ

要約や分類だけならAIの自由度を上げやすい一方、メール送信、削除、決済、公開、CRM更新など不可逆性の高いアクションではapprovalや制限を入れます。

Costは実行経路の変動も見る

固定ワークフローはstep数を見積もりやすい一方、Agentはツール call回数がcontextによって変わる場合があります。

subscriptionだけでなく、タスク / クレジット / 実行 / model tokenなど利用量も確認します。

最初からAgent化しない

手順が明確なら、まず固定ワークフローで自動化し、AI判断が必要なpointだけ切り出します。自由度が本当に必要な部分が見えてからAgent化します。

Human-in-the-loopを残す

Agent型でも重要アクション前に人のapprovalを挟めます。自動化率100%を目標にせず、riskが高い部分だけ人へ戻す設計を考えます。

AIものさしの判断

選び方は「Agentが新しいからAgent」ではなく、仕事の不確実性で分けるのが基本です。

固定手順→ワークフロー型、固定手順＋一部判断→AI Step型、経路そのものが変わる→Agent型という整理をすると、過剰な自動化を避けやすくなります。

AIものさしでは、ツール名ではなく、再現性・自由度・risk・監視可能性から自動化方式を決められた状態をこのワークフローの完了条件にします。

選定フロー：まず固定できる境界を見つける

方式を選ぶ前に、業務を「入力」「許可される操作」「完了条件」「人が確認する点」へ分解します。Agentを使うかどうかは、モデルの新しさではなく、実際に経路を変える必要があるかで決めます。

3問で型を絞る

Q1. 同じ入力条件なら、毎回ほぼ同じ順で処理できるか。

• はい → 通知、転記、定型計算などはWorkflow型から始める。

• いいえ → Q2へ。

Q2. 全体の順序は固定で、途中の一工程だけ文章解釈や分類が必要か。

• はい → 固定WorkflowにAI Stepを一つ置き、その出力をschema / 選択肢で制約する。

• いいえ → Q3へ。

Q3. 入力内容に応じて、検索先・次の処理・必要なTool自体が変わるか。

• はい → Agent型を候補にする。ただし、使えるToolをallowlistにし、操作範囲・実行回数・停止条件を制限する。

• いいえ / 判断できない → まず固定WorkflowまたはAI Stepの小さな試作を行う。

Makeの公式scenario分類も、fixed rulesのstandard scenario、決まった手順にAI moduleを加えるAI scenario、Agentが経路を決めるAI agent scenarioを区別しています。これは製品用語の分類であり、他社の同名featureが同じ仕様とは限りません。

具体例：問い合わせを担当部署へ振り分ける

表は横にスクロールできます

段階	固定Workflow	AI Stepを含むWorkflow	Agent型
Input	formのカテゴリ欄	自由記述本文	文面・添付・過去履歴など複数source
判断	billingなら経理	AIが候補カテゴリを分類	必要に応じてFAQ検索、CRM参照などを選ぶ
Action	決めたSlack channelへ通知	許可カテゴリなら通知、曖昧なら人へ	許可Toolの範囲で複数手順を選択
Stop条件	必須欄欠落	信頼できない / 空の分類	Tool未許可、予算超過、期限超過、人承認待ち
QA	各分岐を固定sampleで検査	誤分類・空出力をfallbackへ	tool call履歴と副作用を人が確認

顧客への自動送信、返金、アカウント停止など、誤作動の損害が大きい処理は、最初のPoCで実行させず、下書きまたは人承認で止めます。Agentが「実行できる」ことと、その実行を無人で許可できることは別です。

PoC前に埋める運用カード

• 対象業務：どの入力から、何を完了させるのか。

• 固定可能な工程：手順・分岐条件・出力先のうち、仕様として決められる部分。

• AIへ渡す範囲：自由記述の分類など、人がルール化しにくい一工程。

• 許可する副作用：read / draft / update / sendのどこまで許すか。

• Fallback：情報不足、矛盾、timeout、Tool失敗時に誰へ戻すか。

• 観測方法：成功率だけでなく、誤処理、人の修正、再試行、利用量を記録する。

一つのAgent試験では、最初に「読取＋draft作成」までに制限し、既知の入力例で期待する経路を表にします。経路が一定なのにAgentがtoolを選び直してコストやerrorが増えるなら、固定flowへ戻す判断も妥当です。

公開前の境界・権限チェック

1. Toolは必要最小限にし、書込み・送信系は初期状態で無効にする。

2. 個人情報・機密文書を含む場合、各製品の契約、アクセス権、データ利用条件を確認する。

3. Agentが参照できるデータとユーザー権限を一致させる。

4. 外部アクション前に承認や二重確認を挟む。

5. 実行履歴、失敗通知、停止スイッチ、所有者を決めてから本番データを接続する。

AIものさしの判断は、固定できる工程を先にWorkflowへ閉じ込め、必要な不確実部分だけAIへ渡すことです。Agent化は「手順が変わる必要性」「許容できる副作用」「監視と停止ができる担当」の三つがそろう場合に限定すると、過剰な自律化を避けられます。

Make公式のScenario型の比較と、Zapier Agentsの登録済みAction設定を根拠に、製品上の機能と一般的な設計判断を分けました。個々のplan、利用上限、管理者設定は契約・workspaceで変わるため、導入時に再確認してください。

Agentを選ぶ前の失敗パターン

表は横にスクロールできます

失敗	なぜ起きるか	設計で防ぐこと
Agentを入れたが経路が毎回同じ	必要だったのは一部の分類だけ	固定Workflowへ戻し、AI Stepだけ残す
出力をそのまま顧客へ送る	誤りの影響と承認条件を決めていない	Draftまでに制限し、人が確認して送る
Toolを増やしすぎる	Agentが選ぶ候補と権限範囲が広い	業務に必須のToolだけallowlistにする
失敗を再実行して二重登録	idempotencyや既存ID照合がない	書込前に処理済みIDを確認する
成功率だけで評価する	誤った副作用や監視負荷を見落とす	誤処理数、手動修正、停止率、usageも記録

AgentのPoCでは「期待した答えが出たか」だけでなく、「許可外のactionを選ばなかったか」「不足情報で止まれたか」「人に戻す必要があるケースを見つけたか」を確認します。失敗時に安全に止まることも完了条件です。

方式を変える判断基準

固定WorkflowからAI Stepへ進むのは、規則だけでは分類・抽出が難しい入力があるときです。AI StepからAgentへ進むのは、必要な処理経路が入力ごとに本当に変わり、その変化をログで説明できるときです。単にpromptが長い、またはbranchが多いという理由だけではAgent化の根拠になりません。

最初の試験は、正解が分かる過去例を少数選び、固定の期待結果と比較します。件数は業務上意味のある範囲を担当者が決め、本文で特定の成功率を一般化しません。誤った外部操作が一件でも重大な損害になるなら、成功率に関係なく承認を必須にします。