業務の自動化で何を使うかは、たった一つの問いで決まります。処理の流れを人があらかじめ決めておけるか。 流れと分岐をすべて先に描いておけるなら、ルールベースや固定ワークフローで十分です。実行の過程をLLMがその都度決める必要があって、はじめてエージェントの出番になります。
よく「LLMを使う」と「AIエージェントを使う」を同じ意味に受け取りがちですが、この二つは違います。LLM(大規模言語モデル)は膨大な量の文章を学習し、人の言葉を理解して新しい文を生み出すAIです。問い合わせを要約したり下書きを作ったりする仕事は、このLLMを一度、あるいは決まった順番で呼ぶだけの「固定ワークフロー」で片づきます。一方「エージェント」は自分で計画を立て、ツールを選び、複数のステップを踏んでいきます。だからこそ、経路をあらかじめ描いておけない業務にだけ必要になるのです。非定型の業務だからといって、必ずエージェントでなければならないわけではありません(ワークフローとエージェントの違い, Anthropic)。
まずは全体像から描いてみましょう。
ベルトコンベアを思い浮かべると、ルールベース自動化の本質が見えてきます。ベルトの上の部品は、決まった位置で決まった作業だけを受けます。ネジを締める位置では必ずネジを締め、昨日も今日も同じ順番で同じ結果が出ます。部品の形が急に変われば、ベルトは処理できずにラインが止まります。
仕事のできる秘書を思い浮かべると、エージェントが見えてきます。「来週のワークショップの場所をちょっと調べておいて」と言うだけで、秘書は人数・予算・前回の評判まで自分で考慮して候補を絞ってきます。細かく指示しなくても、自分で判断してくれます。その代わり、同じ指示を別の日に出すと少し違う候補が上がってくることもあるので、秘書が持ってきた結果には「このまま予約していいか」を一度確認する手順が自然とつきます。
その間に、固定LLMワークフローがあります。順番表はベルトコンベアのように固定されていますが、各位置でやること(要約・分類)は秘書の判断を少しだけ借ります。では、三つを一つずつ見ていきましょう。
Zapier、Make、n8nのようなノーコードツール(コードを直接書かず、画面上でブロックをつないで作るツール)が答える問いは、「この出来事が起きたら、あの作業をどう自動で処理するか」です。
仕組みは、トリガー(trigger、何かが起きる合図)とアクション(action、その合図に応じて実行する動作)の組み合わせです。たとえば「Googleフォームに新しい回答が入ったら → スプレッドシートに行を追加して → Slackに通知を送る」というように流れます。条件と結果が人のあらかじめ決めたとおりに決定的に、つまり同じ入力なら必ず同じ結果につながります。
長所は明快です。予測可能で、どのステップで何が実行されたかがログで一目でわかります。問題が起きればそのステップだけをピンポイントで直せますし(こうして問題箇所を見つけて直す作業をデバッグと呼びます)、実行コストもおおむね安く済みます。
限界も同じ理由から出てきます。あらかじめ定義した経路の外の状況は処理できません。新しいケースが生まれるたびに分岐(branch、条件で道を分ける枝)を一つ足さなければならず、それを見落とすと、そのケースは静かに処理されないままになります。分岐が増えるほど流れは絡み合い、やがて作った本人さえ全体を追えなくなる「分岐爆発」の状態に陥ります。
最近はノーコードプラットフォームがエージェント機能を載せることもあります — Zapier Agents、Make AI Agents。ですから本当の基準は「ノーコードかコードか」ではなく、「経路をルールであらかじめ固定するか、システムがその都度決めるか」なのです。
中間の段階があります。文章を理解する必要はあるものの、処理の流れはいつも同じ、という業務です。
文書を三行で要約する、問い合わせを決まったカテゴリーに分類する、メールの下書きを作る、といった仕事がここに入ります。さらにつなげることもできます。たとえば「問い合わせ内容を分析して感情スコアをつける → スコアが低ければ謝罪のトーン、高ければ感謝のトーンで下書きを書く → 担当者に渡す」というように、LLMを何度も呼びつつ、その順番はいつも同じです。文章を理解する仕事なのでルールだけでは足りませんが、たどるステップと分かれ道はあらかじめすべて決まっています。こういうときは、決まった位置でLLMを呼べば済みます。自分で計画を立てるエージェントまでは必要ありません。
ただし注意したいのは、流れを固定しても結果まで固定されるわけではない、という点です。LLMを呼ぶ各ステップの出力は、実行するたびに変わりえます — 言い回しだけでなく、分類や分岐の判断がぶれることもあります。temperature(出力のばらつきを抑える設定)を0にしても、完全な決定性は保証されません(Anthropic API, Anthropic)。固定されるのは実行の構造であって、結果の一貫性ではないのです。ですからこの段階でも、分類の取り違えが致命的になる分岐には、人が確認する余地を残しておくと安全です。
エージェントは自然言語の目標を受け取って自分で計画を立て、必要なら検索や文書照会といったツールを呼び出し、途中の結果を見ながら次の行動を決めます。決まったフローチャートがない、という点が肝心です。
この柔軟さのおかげで、人がすべてのケースをあらかじめ定義しきれない曖昧な依頼も扱えます。「今四半期の売上報告に異常の兆しがあれば指摘して」のような依頼はルールで書き下すのが難しいですが、エージェントはデータを一通り見て、自分で判断基準を立てて結果を出します。
代償もあります。最も大きな特徴は非決定性です。同じ入力を与えても、実行するたびに結果が少しずつ変わりうる、という意味です。これはエージェントだけの性質ではなく、LLMを呼ぶ以上はつきまといますが、エージェントは流れそのものも自分で決めるぶん、そのぶれが結果全体に大きく及びます。そのため成果物には人の検証が必要で、事実でない内容をもっともらしく作り上げるハルシネーション(hallucination、例:存在しない機能や方針を事実であるかのように述べてしまうこと)のリスクがあり、実行のたびに演算コストがかかります。
| 区分 | ルールベース(ノーコード) | 固定LLMワークフロー | LLMエージェント |
|---|---|---|---|
| 入力 | トリガー + 事前定義した条件 | 自然言語、ただし処理の流れは固定 | 自然言語の目標・文脈 |
| 実行経路 | 人があらかじめ描いた固定経路 | 人が決めた流れどおりにLLMを呼ぶ(分岐を含む) | エージェントがその都度計画 |
| 再現性 | 決定的 — 同じ入力なら同じ結果 | 構造は固定でも結果は非決定的 — 表現も分類・判断も変わりうる | 非決定的 — 毎回変わりうる |
| 強み | 予測可能・透明・低コスト | 流れが固定された、文章理解を伴う作業 | 曖昧な依頼、経路を組めない業務 |
| 限界 | 定義外の状況は不可、分岐爆発 | 固定の流れゆえ例外状況で抜け出せない | 検証が必要、ハルシネーション、実行コスト |
| 人の介入 | 設計の時点(作るとき) | 実行後の検証 | 実行後の検証 |
業務を次の三つの問いに順番に通します。前の段階で引っかかればそこで止まり、通れば次の問いへ進みます。一つの業務を例に追ってみましょう。届いた顧客の問い合わせを処理する仕事です。
第1段階 — ルールだけで処理できるか? 「件名に『返金』があれば返金チームのチャンネルへ回す。」条件と結果がきっちり定まるこうした部分は、ルールで固定します。ノーコードの出番です。ここで終わる仕事なら、より複雑なツールを持ち出す理由はありません。
第2段階 — 決まった流れのLLM呼び出しで十分か? 「問い合わせごとに要点を三行で要約し、決まったカテゴリーに分類して担当者に渡す。」要約と分類は文章を理解する必要があるので、ルールだけでは足りません。けれど「受け取る → 要約・分類する → 渡す」という流れは毎回同じです。分類結果によって送り先が分かれても — 返金の問い合わせなら決済記録を照会、使い方の問い合わせなら案内文書を照会 — その分かれ道を人があらかじめすべて決めておけるなら、これも固定ワークフロー(ルーティング)です。こういうときは、LLMを決まった位置で呼べば十分です。まだエージェントは必要ありません。
第3段階 — 流れとツールの使い方を、LLMが実行の途中で自分で決めなければならないか? 分かれ目は「道が分かれるかどうか」ではありません。道が分かれても、その分かれ道を人があらかじめすべて書き出せるなら、第2段階の固定ワークフローで足ります。本当の第3段階は、流れそのものをあらかじめ書き出せないときです。「『商品が思っていたのと違う』のような漠然とした問い合わせ」は、何から確認するか、何ステップ踏むか、どのツールを使うかが、あらかじめ決まりません。過去の問い合わせを掘り返して出てきた内容に応じて、次に決済記録を見るか、配送履歴を見るか、案内文書を見るかをその都度判断する必要があり、その組み合わせを人が事前にすべて列挙するのは困難です。実行の過程とツールの選択をLLMが自分で組み立てなければならないこの地点が、エージェントの出番です。
三つの問いを順番に投げかければ、「非定型だから無条件でエージェント」という過剰な選択を避けられます。実際、多くの業務は第1段階か第2段階で終わります。
実務の答えは、三つのうち一つだけを選ぶことではなく、組み合わせることです。先ほどの顧客の問い合わせに戻りましょう。漠然とした問い合わせを読んで何を確認するかを決め、返答の下書きを作る経路の探索の部分はエージェントが担い、そうして出てきた返答を顧客管理システム(CRM、顧客情報をまとめて管理するシステム)に記録して担当者に知らせる定型の部分はルールに渡します。一つのツールで無理に統一せず、それぞれが得意な領域を任せるのです。
この構造で欠かせないのが、人の確認ゲートです。エージェントが作った下書きをそのまま送り出すと、非決定性のせいでたまに出る曖昧な結果が、検証なしに外へ出てしまいます。だから「エージェントが下書きを作る → 人が確認する → 確認されたものだけ次のステップへ進む」を既定値に置きます。
この「組み合わせ」と「人の確認ゲート」の原則を、そのままサービスに落とし込んだのがONTLEです。
ONTLEにこう書いて送ります。「今週たまった顧客の問い合わせ、要点だけ絞って返答の下書きまで作って。」
派遣されたAIエージェントは、あらかじめ用意されたボタンを選ぶやり方ではありません。問い合わせを一つひとつ読み、「商品が思っていたのと違う」のような漠然とした案件は、過去の似た問い合わせから探し始めます。そこで返金につながった事例が多ければ注文・決済記録まで確認し、単なる使い方の問題だったなら案内文書を引っ張ってきてトーンを合わせます。何を何ステップにわたってさらに見るかをあらかじめ組んでおけないので、エージェントが実行の過程をその都度組み立てます — この部分がエージェントの出番です。
そうして作られた下書きを、あなたが開いて見ます。トーンのきつい一件をやわらかく直し、事実の間違った一行を正します。人が確認した返答だけが次のステップへ進みます — 先に述べた「確認ゲート」が構造に組み込まれているわけです。固定のルールだけでは収めにくい柔軟さを手に入れながら、エージェント単独使用の最大のリスクである「検証なしの実行」を避けられます。
もちろん、ONTLEがすべての自動化を置き換えるわけではありません。完全に定型化された高頻度の繰り返し業務なら、ノーコード自動化がコストと予測可能性の面で依然として有利です。ONTLEが強みを発揮するのは、確認すべきことが毎回変わってルールで定義しづらく、これまで人が毎回つきっきりにならざるをえなかった非定型の業務です。
いいえ。今のワークフローが予測可能な結果をきちんと出しているなら、切り替える理由はありません。エージェントは、ノーコードでは扱いにくかった「流れをあらかじめ組んでおけない業務」を加えてくれる道具であって、既存の自動化を取り払うための道具ではありません。
あります。人のやる仕事が「最初から最後まで自分で作る」から「作られた下書きを確認する」へ変わるからです。確認にかかる時間は、最初から作るよりずっと短く済みます。完全無人ではありませんが、人の作業量そのものが大きく減ります。
決定的な結果が必ず必要な業務です。会計処理や在庫の移動のように、同じ入力なら必ず同じ結果が出なければならない仕事は、わずかなぶれも危険です。こうした業務は第1段階、つまりルールベース自動化に任せるのが正解です。
繰り返し業務はルールで、流れをあらかじめ組んでおけない業務は対話で任せたいなら、ONTLEで始めてみてください。対話型のAIエージェントが依頼を解釈して成果物を作り、人が確認する構造で設計されています。
https://ontle.kr
著者: パク・ドヒョン