9月24日、Kanwal Mehreenが「Agent or Workflow? A Practical Test for Knowing When You Actually Need an AI Agent」と題した記事を公開した。「エージェント」という言葉が氾濫している。3つのツールを持つチャットボットも、固定のドキュメント処理パイプラインも、スケジュール実行の自動化も、すべて「エージェント」と呼ばれる。本来の意味で自律的に計画・行動・観察・戦略修正を行うシステムも同じ名前だ。この混乱のせいで、不要な場面でエージェントが採用されるケースが増えている。本記事ではその判断軸を整理し、コードを書く前に「どちらを選ぶべきか」を見極めるための実践的なテストとチェックリストを提示している。

ワークフローとエージェントの違い

ワークフロー（パイプラインやチェーンとも呼ばれる）は、制御フローが設計時に固定されているシステムだ。ステップの順序、分岐、終了条件はすべて開発者が事前に決める。LLMをステップの一部に使っていても、全体の流れが決まっていればワークフローに分類される。

たとえば顧客の返金処理なら、「申請受付 → 資格確認 → LLMで判定 → 承認/却下」という経路を事前に図示できる。LLMや条件分岐が含まれていても、取り得るパスがすべて設計済みなら、それはワークフローだ。

エージェントは、LLM自体が実行時に「次に何をするか」を決めるシステムだ。ゴールとツール群を与えられ、どのツールをどの順番で呼ぶか、いつ止めるかをモデルが判断する。バックトラックやループも発生しうる。

記事ではその好例として、本番環境の障害調査を挙げている。「過去30分でチェックアウトの失敗が増えた原因を特定せよ」というタスクに対し、ある障害ではデプロイ履歴→スタックトレース→DBレイテンシという順で調査し、別の障害ではリージョン別の失敗分布→CDNステータス→DNS→プロバイダ障害という経路をたどる。事前に正しい調査手順を固定できない——これがエージェントが必要なケースだ。

※編集部の考察：LangChainやAutoGenといったエージェントフレームワークの普及により、エージェントの実装コストは大きく下がった。しかしそれは「エージェントを使うべき理由」にはならない。実装が容易になったからこそ、設計判断の重要性は増している。

判断のための「1つのテスト」

記事が提示する最もシンプルな判断基準がこれだ：

コードを書く前に、タスクの完全なフローチャートを描けるか？

• 描ける → ワークフローを使え
• 次のステップが実行中の発見（予想外のツール結果、中間データ）によって決まる → エージェントが必要

ここで記事が強調するのは、「ワークフロー＝シンプル、エージェント＝高度」という誤解だ。ワークフローでも複数のLLM呼び出し、検索、ツール呼び出し、リトライ、人間による承認、複雑なビジネスロジックを組み込める。逆に、モデルが次の行動を決定するだけのシンプルなシステムでもエージェントになりうる。複雑さの度合いではなく、実行時に制御フローが動的に決まるかどうかが唯一の判断軸だ。

構築前の5点チェックリスト

1〜4は「Yesならワークフローで十分」という判断につながる問いだ。5番は性質が異なる——これはエージェントの採用を急ぐ前に、より単純な代替手段を先に検証したかを確認するための問いだ。元記事の意図は「ワークフロー＋LLM判断という組み合わせを試していないなら、まずそこから始めよ。それで解決するならエージェントは不要」という順序の強調にある。

カスタマーサポートを例に取ると、「問題分類(LLM) → ポリシー確認 → 資格判定(LLM) → 返金処理」という固定ワークフローにLLMを組み込むだけで十分な場合は多い。これがうまく機能するなら、完全自律型エージェントは不要だ。

エージェントはトークン消費・API呼び出し・レイテンシのすべてがワークフローより増える。大量のFAQ対応や定型タスクにエージェントを使うのはコスト面でも合理的でない。

結論：まず制約から始めよ

記事の最終的な主張はシンプルだ。

フローチャートを先に描け。ワークフローを先に作れ。どこで失敗するかを計測してから、エージェントが本当に必要かを判断せよ。

エージェントが必要になるとしても、タスク全体ではなく一部分だけに適用すれば済むケースが多い。問題が真に「オープンエンド」——実行中に流れを発見していく必要がある——場合にのみ、エージェントを選ぶ根拠が生まれる。

詳細はAgent or Workflow? A Practical Test for Knowing When You Actually Need an AI Agentを参照していただきたい。