Workflow 型 vs Agent 型の使い分け

この記事の目的

LLM システムの実現方式を、Workflow 型・Agent 型・その中間(ハイブリッド)から根拠を持って選べるようになります。特に、実務で最も多い失敗である「過剰な Agent 化」を、トレードオフ表と判断フローで防げる状態がゴールです。

AI Agent とは何かで定義したとおり、Workflow 型は手順をコードで固定し、Agent 型は手順の決定をモデルに委ねます。本記事はこの選択を設計判断として詳細化します。

出発点となる原則は 1 つです — 要件を満たせる範囲で、最も自律性の低い構成を選ぶ。自律性は必要になってから足すことはできますが、外すのは(それに依存した設計が積み上がるため)困難です。

Agent 型が優位なのは「柔軟性」だけです。それ以外のすべての観点でコストを払うため、柔軟性が本当に必要かが判断の中心になります。

「手順を列挙できるか」は、机上ではなく実際に列挙を試みて判断します。列挙を試みた結果として「分岐が発散して書き切れない」ことが確認できたときが、Agent 型を正当化できる瞬間です。

実務のシステムの多くは、純粋な Workflow でも純粋な Agent でもなく、その組み合わせに落ち着きます。

Workflow の 1 ステップとして Agent を埋め込む — 全体の流れ(受付 → 処理 → 検証 → 出力)は固定し、「処理」の中の探索的な部分だけ Agent に任せます。Agent の不確実性を 1 ステップに閉じ込められます
Agent のツールとして Workflow を渡す — 定型手順(例: 帳票作成の 5 ステップ)を 1 つのツールに固めて Agent に渡します。Agent は「いつ使うか」だけを判断し、手順の中身では迷いません

どちらの方向でも、予測可能な部分をコードに固定し、判断が必要な部分だけをモデルに委ねるという同じ原則が働いています。

最初から正解の構成を当てる必要はありません。移行しやすい順序があります。

Workflow で始める — まず固定手順で作り、実運用のログから「手順が足りなかったケース」を集めます
足りない部分を特定して Agent 化する — 発散していた分岐が実は 3 パターンだった、と分かればルーティングで済みます。本当に探索的だと確認できた部分だけ Agent にします
境界を関数・ツールとして切っておく — Workflow のステップと Agent の境界をきれいに保つと、双方向の移行(Agent 化・Workflow への後退)が安価になります

「Agent の方が先進的だから」という選定 → 要件ではなく流行で方式が決まり、上のトレードオフ表の代償だけを払う → 柔軟性が必要な根拠(列挙を試みた結果)を要求する
システム全体を 1 つの巨大 Agent にする → 予測可能だった部分まで不安定・高コストになり、デバッグ不能に近づく → 予測可能な部分を Workflow に固定し、Agent の範囲を最小にする
Agent から Workflow に戻せない密結合 → 「Agent 化してみたが不安定」となっても後退できず、不安定なまま運用する羽目になる → ステップ境界を関数・ツールとして分離しておく

Building Effective Agents(Anthropic) — Workflow と Agent の区別と「シンプルさ優先」原則の出典(アクセス日: 2026-07-05)

なし