中級向け

AI Agentと手順型の比較

客の問い合わせメールに返信の下書きを作る仕事を、決まった手順で組んだ版と、AI Agentに道具を持たせて任せた版で比べました。同じモデル・同じデータで、Agent版は費用が約3倍、空き枠がある客を4回中3回断り、来店できない日を「予約できます」と書いた回もありました。

動作確認: — n8n 2.36.8 / AI Agent v3.1 / Claude Haiku 4.5

客から届いた問い合わせメールに、在庫や来店枠を調べて返信の下書きを作る。 この仕事を、2通りに組んで比べました。

  • 手順を組む版:AIで用件を仕分け、決まった順に「取り出す → 調べる → 返信を書く」を流す
  • Agentに任せる版:AI Agent 1つに道具を4つ持たせ、何をどの順でやるかを任せる

同じ架空の客のメール7通、同じ在庫と来店枠のデータ、同じモデル(Claude Haiku 4.5)、同じ返信のルールです。

結果はこうでした。

手順を組む版 Agentに任せる版
1通あたりの費用 約0.4円 約1.2円(約3倍)
7通の処理時間 約37〜42秒 約55〜73秒
「今週土曜の午後」で空き枠を案内できた 6回中6回 4回中1回
来店できない日を「予約できます」と書いた 0回 4回中1回

この7通については、Agentに任せる利点はほとんど見つかりませんでした。 用件が2つあるメールで、4回中1回だけ両方を調べたのが唯一の差です。 加えて、Agent版を組む途中で、下書きが宛先なしで作られる、1通も下書きができないまま全部「処理済み」になる、という壊れ方を2回踏んでいます。どちらも実行は「成功」と表示されました。

比べた2つのワークフロー

手順を組む版は、配布しているテンプレートと同じものです。 作る途中で踏んだ落とし穴は別の記事に書きました。

Agentに任せる版はこうです。

AI Agentに任せる版のn8nワークフロー。5分ごとに実行、未処理のメールを取得、1通ずつ処理のあとに、問い合わせに対応するというAI Agentノードが1つあり、処理済みにするノードを経てループに戻る。AI Agentの下にClaude Haiku 4.5と、search_stock、search_visit_slots、create_reply_draft、send_to_humanの4つの道具がぶら下がっている
AI Agent 1つに、在庫検索・来店枠検索・下書き作成・人に回すの4つの道具を持たせた
道具 中身
search_stock 商品の種類で在庫表を引く
search_visit_slots 日付で来店枠表を引く
create_reply_draft 返信の下書きを作る。本文だけをAgentが書き、宛先とスレッドはワークフロー側で固定
send_to_human needs-human ラベルを付ける

宛先までAgentに書かせると、別の客に下書きを作る危険があるので固定にしました。 それでも、仕分け・何を調べるか・下書きを作るか人に回すかはすべてAgentの判断です。

返信のルール(データに無い約束をしない、記号を使わない、社内の言葉を書かないなど)と、 今日の日付と曜日は、システムメッセージで渡しています。

正確さ:Agentは日付を取り違えた

手順を組む版は6回、Agent版は4回流しました。7通それぞれの結果です。

客のメール 手順を組む版(6回) Agentに任せる版(4回)
#1 グレーのソファの在庫 在庫切れ・11月中旬入荷 同じ
#2 幅150cmのテーブル 正しい 正しい
#3 シングルベッド 「取り扱いがない」 「担当者から改めてご連絡」と曖昧
#4 今週土曜の午後 6回とも10/3を調べ、16時の空きを案内 3回は10/4を「土曜」として調べ、「満席」と断った
#5 10月7日(水)11時 来店できないと回答 1回、枠が0件なのに「ご予約いただけます」
#6 チェアの不具合 needs-human 道具が動いた回は needs-human
#7 ソファを見に日曜に 満席と回答。ソファには触れない 満席と回答。1回だけ、ソファの在庫も調べた

#3 は、下書きの本文が残っている3回すべてで曖昧でした。

#4 は、空いている枠がある客を断っています。 今日は 2026-10-02(金曜日)とシステムメッセージに書いてあり、 「今週の土曜」は 10/3 です。Agentは 10/4 を検索し、下書きに「10月4日(土曜日)」と書きました。 10/4 は日曜で、満席です。

手順を組む版では、日付を取り出すだけのノードに同じ「今日の日付と曜日」を渡していて、6回とも正しく 10/3 を出しました。 同じモデル・同じ情報でも、Agentでは崩れた、ということです。 Agentは日付を決めながら、どの道具を使うか、何を書くかも同時に判断しているので、そのぶん崩れやすいのだと考えています(ここは推測です)。

費用と時間:入力が3.5倍

Agentの呼び出し回数は、手順を組む版とほとんど変わりません。違うのは1回あたりに送る量です。

7通あたり 手順を組む版(2回の実測) Agentに任せる版(2回の実測)
モデルの呼び出し 19回 20〜21回
入力トークン 11,410 38,476〜40,999
出力トークン 1,706〜1,718 3,364〜3,512
費用(Claude Haiku 4.5) 約$0.020 約$0.056〜0.059
1通あたり(1ドル150円) 約0.4円 約1.2円

入力が約3.5倍になっています。Agentは呼び出すたびに、4つの道具の説明と、それまでのやりとり全部を送り直します。 手順を組む版は、それぞれの呼び出しに必要な情報だけを渡しています。 この増え方は AI Agentノードの記事 で測ったものと同じ構造です。

Agent版を組むときに踏んだ落とし穴

ここからは、Agent版だけで起きたことです。

道具の名前を日本語にすると、全部「_」になる

最初は道具のノード名を「在庫を検索」のように日本語にしていました。実行するとこう出て止まります。

You have multiple tools with the same name: '_', please rename them to avoid conflicts

道具の名前はノード名から作られます。日本語の部分が落ちて、4つとも _ になり、衝突しています(n8n の実装は確認していません。エラーの内容から読み取ったものです)。 エラーの文面からは「日本語がだめ」とは分かりません。 道具のノード名は英数字にしてください。Agentへの指示でも、その名前で呼びます。

ループの中から値を取る書き方で、下書きが壊れた

create_reply_draft の宛先とスレッドは、ループで今処理しているメールから取っています。 手順を組む版で使っていたのと同じ書き方をそのまま入れたところ、こうなりました。

道具の中の書き方 結果 実行の表示
$("1通ずつ処理").first().json.threadId 下書きは6通できたが、確かめた下書きは宛先が空で、元のメールのスレッドにも入っていなかった。send_to_human は Invalid id value で8回失敗 成功
$("1通ずつ処理").item.json.threadId Paired item data … is unavailable で下書きが1通もできなかった 成功
$("1通ずつ処理").first(1).json.threadId 正常。宛先が入り、元のメールのスレッドに入った 成功

2行目のときは、下書きが0通のまま、ループの最後の「処理済みにする」は動いたので、 7通すべてに処理済みのラベルが付きました。 次の実行ではもう読まれません。客から見れば、返事が来ないまま放置です。

このとき、Agent自身は失敗に気づいていました。最後の出力にこう書いています。

申し訳ございません。システムエラーが発生しているため、下書きの作成ができない状況です。(中略)お手数ですが、こちらの内容をご確認いただき、手動で送信いただくか、システムの確認をお願いいたします。

ところが、この出力の行き先がありません。 Agentの出力は次の「処理済みにする」に渡るだけで、誰も読まない場所に消えました。 Agentが「助けてほしい」と書いても、それを受け取る道を作っておかなければ届きません。

Loop Over Items には出口が2つあり、0番が done(全件完了)、1番が loop(1件ずつ)です。 .first(1) は「1番の出口から最初の1件」という意味で、これで今処理している1通が取れました。 .first() が空になったのは、道具の中では0番の出口(まだ空の done)を見ていたからだと考えています。 通常のノードでは同じ書き方で正しく取れていたので、道具の中だけで違う結果になります(実装は確認していません)。

Agentに任せた方がいい仕事はあるか

Agentの方がうまくいったのは、1か所だけでした。

#7(ソファを見たい + 日曜に行きたい)です。手順を組む版は用件を1つにしか仕分けられないので、 ソファの在庫には一度も触れません。Agentは4回中1回、来店枠に加えてソファの在庫も調べていました。 道具を自分で選べることの利点が出たのは、この1回です。残りの3回は来店枠しか調べていません。

それ以外では、Agentが手順を組む版を上回ったものはありませんでした。

今回わかったのは、手順を書き下せる仕事は、手順として組んだ方が安くて正確だということです。 「在庫の質問なら在庫を調べて答える」「来店の相談なら枠を調べて答える」のように分かれ道が決まっているなら、 その分かれ道をAIに毎回判断させる理由がありません。 Agentに任せるのは、どの順に何を調べればいいかを前もって書き出せない仕事に限った方がよい、と考えています。

確認していないこと

  • モデルは Claude Haiku 4.5 だけです。 より上位のモデルなら、日付の取り違えは減るかもしれません
  • Agent版は4回、手順を組む版は6回の結果です。回数を増やせば割合は変わります
  • .first(1) が効く理由は、出口の番号から推測したものです。n8n の実装は読んでいません
  • Agentへの指示の書き方を工夫すれば、#4 や #5 の誤りが減る可能性はあります。今回は手順を組む版と同じルールにそろえ、それ以上は調整していません

次に読む

手順を組む版をそのまま取り込める形にしたものは メール対応自動化ワークフロー で配布しています。

AI Agent の費用が反復のたびにどう積み上がるかは n8n AI Agentノードの使い方 にまとめました。

ほかの実例や、止まった場所のまとめは n8n 業務自動化の実例 にあります。

次に読む