Agentic Workflowとは何か

用語：Agentic Workflow

一文で：Agentic Workflowは、AIエージェントの計画・tool利用・適応を組み込んだ複数stepの処理flowですが、どこまで経路をAIが決めるかは製品や文脈によって大きく異なります。

分類：AIエージェント・開発・運用（C03）

TERM_ID：G200

Agentic Workflowは、2025〜2026年に急速に広がった言葉で、一般にはAIエージェントのplanning、tool use、decision、adaptationを組み込んだ複数stepのprocess flowを指します。

ただし、この用語は注意が必要です。主要vendorの間でも、どこまでをAgentic Workflowと呼ぶかが完全には揃っていません。

Googleの機械学習用語集は、agentic workflowを「agentがgoal達成のために自律的にplan/executeするdynamic process」と定義しています。Google Cloudの解説も、固定されたtraditional automationと対比し、agentがruntimeの状況へ応じてplanを変える点を強調しています。

一方、IBMの製品文書では、nodeとedge、conditional branch、loopなどを人間が設計し、その中にagent、tool、人間interactionを組み込む仕組みもagentic workflowと呼びます。^[1]^[2]^[3]^[4]

Traditional Workflowとの違い

従来のworkflowでは、process pathは基本的に事前定義されます。

たとえば、form受領→DB確認→条件Aなら承認→条件Bなら担当者へ送る、というように、どの条件でどこへ進むかをcodeやworkflow designerが決めます。

Agentic Workflowでは、途中の一部をagentへ委ねます。

「顧客の問題を解決する」という高レベルgoalだけを渡し、agentが履歴検索、規約確認、専門agentへのdelegation、追加質問などを状況に応じて選ぶことができます。

違いの中心は、execution pathのどこを事前に固定し、どこをAIがruntimeに決めるかです。

Anthropicの「workflow」と矛盾するのか

Anthropicは「Building Effective AI Agents」で、agentic systemsをworkflowとagentに分けています。

workflow：LLMとtoolがpredefined code pathでorchestrateされる
agent：LLMがprocessとtool usageをdynamicにdirectionする

この定義だけを見ると、Agentic Workflowという言葉が矛盾して見えるかもしれません。

しかしここでのworkflowはAnthropicがarchitectureを分析するために置いた区分です。市場全体では「agentを含むworkflow」「agent的判断を行うworkflow」という意味でAgentic Workflowが使われています。

したがって、用語同士を機械的に対応させず、その資料がworkflowという語をどう定義しているかを確認する必要があります。

現実のsystemはhybridが多い

実務では、完全固定workflowと完全自由agentの中間が多くなります。

経費精算なら、申請受領、必須項目check、agentによる領収書と規程の比較、不明点への追加質問、一定額以上のhuman approval、承認後の会計system登録、といった構成ができます。

ここでは全体の重要boundaryはworkflowで固定されていますが、規程調査や追加質問はagentがdynamicに行います。このような構成も、多くの製品ではAgentic Workflowと呼ばれます。

Multi-Agentは必須ではない

Agentic Workflowは複数agentを含む場合もありますが必須ではありません。

single agentが複数toolを使いながらloopするworkflowもあります。逆に、複数の専門agentをorchestratorが調整するworkflowもあります。

したがって「agentic workflow = multi-agent」と推論してはいけません。

Agentic Workflowの利点と代償

固定workflowでは例外処理をすべて事前に列挙する必要があります。Agentic Workflowでは、modelが状況をinterpretして柔軟に次の手段を選べるため、例外や曖昧なinputへ対応しやすくなります。

一方、同じinputでもexecution pathが変わり、cost、latency、reproducibility、安全性の管理が難しくなります。agentic化は柔軟性を増やす代わりに、evaluationとgovernanceの問題を増やします。

「agentic」の割合を読む

0か1かで判断するより、次のどこがdynamicかを見ます。

intent understanding
task decomposition
routing
tool selection
retry/replanning
subagent delegation
termination
human escalation

routingだけLLMが決め、以後はfixed workflowならagentic性は限定的です。agentがtask decompositionからtool selection、replanningまで行うなら、よりagent主導です。

元の製品説明で確認すること

node/edgeは人間が固定するのか
agentがpathを変更できるのか
tool selectionはfixedかdynamicか
single-agentかmulti-agentか
stateとmemoryをどう持つか
human approvalはどこに入るか
failure時にretry/replanできるか
何をもってterminationするか
traceを後から確認できるか

Agentic Workflowという言葉は便利ですが、現時点では広いmarketing語としてもtechnical termとしても使われています。

元文脈に戻ったときは、「agentic」と書いてあるかどうかより、flowのどの部分をAIがその場で決め、どの部分を人間が事前に固定しているかを確認するのが最も確実です。

Agentic Workflowは「固定」と「動的」の連続体

Agentic Workflowを、traditional workflowの反対側にある完全自由なsystemと考えると実務を誤解します。

実際には、control flowは連続体です。

全step fixed
routingだけLLM
一部stepでagent loop
subtask decompositionもLLM
tool selectionとreplanningもLLM
terminationまでLLM中心

どこまでdynamic controlを持たせるかでagentic度が変わります。

この連続体として見ると、vendor間でdefinitionが違っても比較しやすくなります。

Node/EdgeがあってもAgenticになり得る

graph-based workflowでは、nodeとedgeがあると「固定workflow」に見えます。

しかしnodeの内部がagentで、edge selectionをLLMが決めるなら、かなりdynamicです。逆に、agent nodeがあっても必ず一回のprompt callをするだけで、pathが完全固定ならagentic性は弱いです。

そのためdiagramを見るときは、node/edgeの存在ではなく、どのedge selectionやnode behaviorがruntime decisionなのかを確認します。

Business Processとの接続

企業では、agentic workflowだけでbusiness process全体を置き換えるとは限りません。

既存のERP、CRM、approval system、RPA、API workflowの中へagentic stepを差し込むことがあります。

たとえばinsurance claimなら、

claim intakeはfixed form
document interpretationはagentic
fraud signal計算はdeterministic model
high-risk caseはhuman review
paymentはfixed transaction

というhybridが現実的です。

このためAgentic Workflowは、従来automationと競合するだけでなく、組み合わせて使われます。

Determinismが必要な場所

すべてをdynamicにすると、auditやcomplianceが難しくなります。

financial transaction、access control、legal deadlineなどは、deterministic ruleでenforceする価値があります。一方、natural language interpretation、exception handling、information gatheringはagentic decisionが向くことがあります。

良いAgentic Workflowは、自律性を最大化するのではなく、自律性が価値を生む場所へ限定して配置する設計です。

Workflow-level evaluation

Agent単体のanswer accuracyだけでは、Agentic Workflowのqualityを評価できません。

process全体で、

completion rate
correct routing
duplicate action
unauthorized action
average step数
latency
cost
human escalation rate
recovery rate
auditability

を見る必要があります。

たとえば一つ一つのagent responseが正しくても、同じpaymentを二重実行すればworkflowは失敗です。

Idempotencyが重要になる

agentic workflowではretryが多くなるため、同じactionを二重実行しない設計が重要です。

API timeout後に「実行されたか分からない」状態で再度refundを送ると二重返金になるかもしれません。

そのためtransaction ID、idempotency key、check-before-writeなど、traditional software engineeringの仕組みがagentic systemでも必要です。

Agenticだから従来のengineering principleが不要になるわけではありません。むしろ不確実なdecision componentが増えるため、周囲のdeterministic safeguardが重要になります。

Long-running Workflow

Agentic Workflowが数分から数時間、あるいは数日続く場合、checkpointとresumeが必要になります。

service restart、network failure、human approval待ちでprocessが中断しても、最初からやり直すのはcostlyです。

state persistence、event log、checkpoint、timeout policy、versioningが必要になります。

こうした機能は「agentのreasoning」とは別ですが、production workflowの実用性を左右します。

「agentic workflowで自動化率向上」を読む

business caseで「自動化率80%」などと書かれていたら、何をもって自動化とするか確認します。

human approvalが残っていても、他stepが自動なら高いautomation rateと報告することがあります。exception caseだけ人間へ回す場合もあります。

また、agentic workflowが処理した件数だけでなく、error correction、review workload、costも見る必要があります。

Agentic Workflowという用語は、単一のarchitectureを指すより、workflowへmodel-driven decisionをどのように埋め込むかというdesign spaceを指す言葉として読むと、異なるvendor説明を比較しやすくなります。

注・出典

AI協働制作について

本記事は、著者が独自に設計した指示、参照資料、出典確認規則、著作権確認および監査工程を組み込んだChatGPT等の生成AIを、情報収集の補助、資料整理、構成検討、草稿作成、文章校正および監査補助に使用して制作しました。記事の対象範囲、情報源の採否、構成、解釈および最終表現は著者が判断し、最終稿を承認しています。著者は、本記事の正確性、独自性、引用、著作権処理および公開内容について責任を負います。制作工程の詳細は「AI協働制作方針」をご覧ください。