F-4: ワークフロー（決定論）vs エージェント（自律）¶

この相反は何か¶

エージェントの制御フローをコードで事前に定義された手順（ワークフロー/決定論）として固定するか、LLMが次の行動を自律的に選択するループ（エージェント/自律）に委ねるかという二者択一です。これはAIエージェントアーキテクチャにおいて最も根本的な設計判断の一つであり、テスト容易性・コスト予測性・柔軟性のバランスを決定します。

この選択が排他的である理由は、制御の主体が質的に異なるためです。ワークフローでは「次に何をするか」をコードが決めます。状態遷移図は事前に確定しており、ユニットテストで全経路を検証できます。エージェントでは「次に何をするか」をLLMが決めます。経路は実行時に動的に生成され、事前の網羅的テストは不可能です。この違いは「程度」ではなく「質」の差であり、システムのテスト戦略・コスト見積り・障害対応のすべてに影響します。

AIエージェントにおいてこの相反が特に重要なのは、LLMが確率的（F3）であり、自己ループする（F13）ためです。制御フローを委ねる範囲が広いほど、確率的な逸脱と無限ループのリスクが増大します。一方で、タスクの変動性が高い（[task_variability]）場合には、事前に手順を列挙すること自体が不可能であり、LLMの自律性に頼らざるをえません。

選択肢A：ワークフロー（決定論）¶

処理の全体をDAG（有向非巡回グラフ）またはステートマシンとしてコードで定義し、各ステップの順序・分岐条件・エラー処理を事前に確定させます。各ステップ（ノード）の内部でLLMを呼ぶことは許されますが、フロー自体はLLMが決めません。Temporal、Airflow、LangGraphの固定グラフなどが実装基盤です。

ワークフローの最大の利点は予測可能性です。処理がどの経路を辿るかは入力の条件で決定論的に定まり、全経路をユニットテストでカバーできます。コスト見積りも各ステップのLLM呼び出し回数が固定であるため正確に行えます。監査においても「なぜこの順序で実行されたか」をコードで示せます。

もう一つの利点は安全性です。B1 決定論的な殻の原則に従い、権限チェック・予算管理・検証をコードで強制できます。LLMは各ノード内の曖昧な判断（分類、要約、解釈）だけを担い、フロー制御には関与しません。これにより、LLMの確率的な逸脱がシステム全体に波及することを防ぎます。

弱点は柔軟性の欠如です。手順を事前に列挙できないタスク（デバッグ、調査、オープンエンドな生成）には対応できません。新しい業務パターンが出現するたびにコードの変更とデプロイが必要になり、変化の速い領域では開発速度がボトルネックになります。

選択肢B：エージェント（自律）¶

LLMが「観察→思考→行動」のループ（ReAct型）を自律的に繰り返し、次の行動を毎ステップ動的に選択します。ツールセットは事前に定義しますが、どのツールをどの順序で呼ぶかはLLMが決めます。制御フローの事前定義は不要です。

エージェントの最大の利点は柔軟性です。手順が毎回変わるタスク、環境の状態に応じて行動を変える必要があるタスク、そもそも手順が不明なタスクに対応できます。開発者は「何ができるか（ツール）」を定義するだけで、「どうやるか（手順）」はLLMに委ねられます。新しいツールを追加するだけで新しいタスクに対応でき、コードの変更量が少なく済みます。

しかし代償は制御の困難さです。LLMが無限ループに陥る（F13）、不必要に高コストなツールを連発する（F2）、禁止された操作を実行する（F14）といったリスクがあります。コスト見積りは不正確になり、テストは「典型的な入力に対して概ね正しい行動をする」という統計的な評価にならざるをえません。デバッグでも「なぜこの行動を選んだか」の再現が確率的にしかできません。

これらのリスクに対処するため、エージェント型を採用する場合でも予算による律速（B3 予算付き自律ループ）が不可欠です。ステップ数・トークンコスト・経過時間の上限を設け、暴走を確定的に防止します。

選定基準¶

選定は [task_variability] と [accountability] の2つの駆動変数で判定します。

[task_variability]（タスクの変動性）が第一の判定軸です。

変動性	判定
低：手順が定型、ステップの順序が固定	ワークフロー
中：基本手順は固定だが、一部のノードで動的判断が必要	ワークフロー骨格＋エージェントノード
高：手順自体を毎回LLMが生成する必要がある	エージェント

[accountability]（説明責任）が第二の判定軸です。

説明責任	判定
高：規制下、監査対象、判断根拠の提示が必要	ワークフロー（＋不可避な部分のみエージェント）
低：探索的、プロトタイプ、内部ツール	エージェントを許容

加えて、[failure_cost] が高い場合はワークフローに倒す強い動機があります。不可逆な操作（決済、データ削除、契約締結）を含む処理では、LLMに制御フローを委ねること自体がリスクです。

デフォルトとハイブリッド¶

デフォルト：できる限りワークフロー（決定論）を選んでください。 ワークフローで実現できる範囲をまず固定し、本当にLLMの自律性が必要な部分だけを切り出します。「エージェントにしておけば柔軟だから」という理由でエージェントを選ぶと、テスト容易性・コスト予測性・安全性を不必要に犠牲にします。

ハイブリッド：決定論的な骨格（ワークフロー）＋確率的なノード（エージェント）が最も実用的な構成です。B2 ワークフロー骨格が体現するこのアプローチでは、全体の制御フローをDAG/ステートマシンで固定し、各ノードの内部を「決定論コード」「単発LLM呼び出し」「ミニエージェント（予算付き自律ループ）」のいずれかに差し替え可能にします。フロー自体のテストと、各ノード内のLLM品質の評価を分離できるのが利点です。

判断を誤ったときの症状¶

ワークフローを選ぶべきだったのにエージェントを選んだ場合：

LLMが毎回ほぼ同じ手順を踏むのに、その手順がコードに固定されていないため、たまに順序を飛ばしたり不要なステップを追加したりします。
コスト見積りが不正確で、同じ入力でも処理コストが2〜10倍ばらつきます。
テストが「概ね正しい」という統計的な評価にしかならず、品質保証に確信が持てません。
規制機関や監査人から「なぜこの操作が行われたか」を問われたとき、「LLMがそう判断したから」としか答えられません。

エージェントを選ぶべきだったのにワークフローを選んだ場合：

新しい種類のタスクが来るたびにワークフロー定義の追加・変更とデプロイが必要になり、対応速度が致命的に遅くなります。
ワークフローの分岐条件が爆発的に増え、コードが管理不能な条件分岐の塊になります。
想定外の入力に対して「該当するフローがない」としてエラーを返すため、ユーザー体験が硬直的です。
本来LLMが自律的に解決できるタスクを、開発者が手動で手順化する作業に時間が費やされます。