こんにちは、Lena です。みんなが agentic workflow をどう語っているか、しばらく観察してきました。誰もがこの言葉を少しずつ違う意味で使っていて——正直に言うと、agentic workflow が普通の AI agent や基本的な自動化チェーンと何がどう違うのかを腑に落とすのに、白状したい以上の時間がかかりました。
この記事は、今の状況を私なりに整理して並べ直そうという試みです——どんな下位タイプがあるのか、どう選び分けるのか、本番ではどこが動いて、どこで壊れるのか。あなたが agent で何かを組んでいて、自分の問題に合う workflow アーキテクチャを選びかねているなら、回り道を少し減らせるはずです。
一文で言うなら
Agentic workflow を一文で
Agentic workflow とは——AI モデルが、次に何をするか、どんなツールを呼ぶか、結果をどう評価するかを自分で決め、続けて進むような系のことです。複数のステップにまたがり、プロセス自体にある程度の自律性を持ちます。
それだけです。鍵となる語はプロセスに対する自律性。モデルはただ質問に答えているわけではありません。問題への取り組み方を決め、使うツールを選び、返ってきたものに応じて調整しているのです。
なぜ 2026 になっても言葉が混乱しているのか
事情はこうです——「agentic workflow」という言葉が今カバーしている範囲は、条件分岐つきの 2 ステップのチェーンから、共有メモリと自己修正ループを備えた本格的な多 agent システムまで、すべて含んでいます。Anthropic の building effective agents は、有用な区別を提示しています——workflow は LLM が予め定義されたコードパスを通してオーケストレーションされる系、agent は自分のプロセスを動的に方向づける系。ただし実際の本番システムは、たいていその両者のあいだに住んでいます。
私はこの区別を最初に読んだとき、しばらくそこで止まりました。紙の上ではきれいに見えるのに、現実に出会う系は、どちらの箱にもきれいに収まらないのです。
Agentic workflow の見取り図
すべての agentic workflow が同じ作り方をされているわけではありません。これらの違いは、何を作るかを決めるときに重要で——もっと言えば、それが本番で生き残れるかを左右します。
線形 workflow
最もシンプルな形。タスク A → タスク B → タスク C。各ステップはツールアクセスつきの LLM 呼び出しで処理されますが、順序は事前に決まっています。イメージとしては——抽出 → 分析 → 要約。自律性は低く、予測可能性は高い。 文書処理、データ抽出のパイプライン、ステップが変わらないあらゆる作業に向きます。
分岐 workflow
系が一か所、または複数箇所でルーティング判断を行います。「入力がサポートチケットなら左、営業問い合わせなら右」。ルーティングは LLM によるものでも、ルールベースでも構いません。基本的なチェーンを越えていくとき、多くのチームがまず到達するのがここです。LangGraph のようなフレームワークは、グラフベースのステート管理と条件付きエッジでこのパターンを明示的に表現します。
自己修正 workflow
ここから本当に面白くなります。系がタスクを実行し、自分の出力を評価し、結果が検証を通らなければループバックして再試行・修正する。 実質、evaluator-optimizer ループです。コード生成では特によく見るパターン——あるモデルが書き、別のモデルがレビューし、レビュアーが納得するまで反復します。落とし穴：適切な終了条件がないと、このループはトークンを無限に燃やします。
多 agent workflow
複数の専門化された agent が問題の異なる部分に取り組み、オーケストレータが調整します。Anthropic は彼らの多 agent 研究システムでまさにこのパターンを採ったと書いています——lead researcher がサブタスクを専門化されたサブ agent に委譲して並列実行させる、というものです。Orchestrator-worker パターンは強力ですが、本物の調整コストを持ち込みます——委譲が精密でないと、agent は作業を二重化したり、穴を開けたり、互いに衝突したりします。
Human-in-the-loop な workflow
上記いずれのパターンでも、明示的なチェックポイントで人間がレビュー・承認・再指示することで先に進む構成です。これは独立したアーキテクチャというより、他のアーキテクチャの上に重ねる制約のレイヤーに近い。リスクの高い領域では譲れません——金融上の判断、法務レビュー、誤った行動が現実の結果を生むあらゆる場面で。
Agentic workflow は agent や自動化とどう違うのか
Workflow vs agent
Workflow には構造があります。適応的だとしても、定義されたステップと遷移を持つ「設計された流れ」が存在します。Agent はもっと開かれていて——何を、いつ、どうやるかを自分で決め、事前定義の構造は最小限に抑えます。本番システムの大多数は workflow であって、純粋な agent ではありません。純粋な agent はデバッグ、予測、コントロールがいずれも難しいからです。
Agentic workflow vs RPA
伝統的な RPA は厳格でルールベースなスクリプトを追います。決まった順序でボタンをクリックします。Agentic workflow は非構造データを解釈し、判断を下し、データが期待と合わない時に適応します。 RPA は UI が変わると壊れる。Agentic workflow も壊れますが、別の——時にはより微妙な——理由で壊れます。一方で可変性への耐性ははるかに高い。
Agentic workflow vs ノーコード自動化
Zapier や Make のようなノーコードツールは、トリガー-アクションのパターンをよく扱います。ただし、ステートレスで推論を持たない。Agentic workflow はステップを越えて文脈を保持し、中間結果に応じた条件判断ができ、ルーティングだけではない——理解を必要とするタスクをこなせます。Model Context Protocol (MCP) はここで触れておく価値があります——AI アプリケーションが外部ツールやデータソースとどう接続するかを標準化していて、agentic workflow の下を支える結合組織になりつつあります。
ユースケース別の実例
コーディング：Agent がコードを書く → テストを走らせる → エラーを読む → 修正する → 再実行。自己修正ループ。本番でもっとも成熟した agentic workflow パターンと言って良いでしょう。
リサーチ：オーケストレータがリサーチクエスチョンをサブタスクに分解 → 並列のサブ agent が異なるソースを検索 → 結果が統合される。鍵となる課題は重複の排除、そして「いつ掘るのを止めるか」。
文書処理：PDF からフィールドを抽出 → スキーマに照らして検証 → 異常をフラグ → 人手レビューへルーティング。検証ステップに分岐が入る線形パターン。
サポート：受信チケットを分類 → 関連ドキュメントを取得 → 返信のドラフトを書く → トーンと正確性を確認 → 送信またはエスカレーション。ドラフトに自己修正レイヤーを重ねた分岐 workflow。
運用：システムメトリクスを監視 → 異常を検知 → 推定原因を診断 → 修復案を提示 → 承認待ち → 実行。ここでは human-in-the-loop が決定的に重要です。
決定マップ——どの workflow を選ぶべきか
……ここは少し意外な答えです——「いちばん複雑なものを選ぶ」ではない。むしろ逆です。手早いフレームワークを置きます：
| 要因 | 線形 | 分岐 | 自己修正 | 多 agent |
|---|---|---|---|---|
| タスクの安定性 | ステップがほぼ変わらない | 入力は変わる、ステップは固定 | 出力品質が揺れる | サブタスクが互いに独立 |
| ツールリスク | 低——読み取り専用ツール | 中——書き込みあり | 中——リトライ可能 | 高——隔離が必要 |
| レビュー必要度 | 低 | 中 | 中〜高 | 高 |
| メモリ要件 | ごく小 | 中程度 | 中程度（ループ状態） | 高（agent 横断のコンテキスト） |
安全にあなたのタスクをこなせる最もシンプルなアーキテクチャから始めること。 動く線形 workflow は、たまにオーケストレーションを幻覚する多 agent システムに勝ります。Google の Agent2Agent (A2A) プロトコルは多 agent 連携の標準化を進めていますが、今の多くのチームにとっての現実は——サブタスクが本当に独立で並列化できるときにだけ、多 agent システムのオーバーヘッドは見合います。
なぜ agentic workflow は本番で壊れるのか
ここが私の戻ってきてしまう箇所です。デモではうつくしく回るのに、本番に出して一週間で崩れる workflow を、いくつも見てきました。失敗モードは十分に一貫していて、列挙できます。
コンテキストドリフト。 長時間走るタスクで、モデルは早期の文脈を見失っていき、三歩前に自分が決めたことと矛盾する判断を始めます。トークン上限は実在し、ほとんどの workflow は文脈の刈り込みを十分にこなせていません。CIO の agentic AI とエンジニアリングに関する分析は、これを中核課題に挙げています——多ステップ越しの持続実行に必要なのは、より長いコンテキストウィンドウではなく、意図された文脈アーキテクチャです。
ツール失敗。 API は落ちる。レートリミットに当たる。レスポンス形式は変わる。ツール失敗をうまく扱えない workflow は、一度の API タイムアウトを一回まるごとの破綻に膨らませます。多くのチームは、リトライ戦略とフォールバック経路への投資が足りていません。
検証の弱さ。 Workflow は走り、出力を出す、けれども誰もそれが実際に良いものかをチェックしない。自己修正 workflow は助けになりますが、それは evaluator が generator のミスを実際に捕まえられる場合に限ります。プロンプトが詰めきれていないせいで evaluator が何でもゴム印で通してしまうセットアップを、私は何度か見ました。
修正が再利用されない。 これはやや微妙ですが、長期で見るとおそらく一番高くつくものです。Agent がある問題に当たり、人間が直し、その直しが蒸発する。翌週、同じ問題、同じ手作業の介入。成功した修復は、再利用可能なものとして決して結晶しないまま。 一回限りの訂正を恒久的な改善に転化する仕組みがありません。Workflow は自分の歴史から学ばない——ただリセットするだけです。
インフラレベルで正しい解がどんな形をしているか、私はまだ完全には見えていません。ただ、こういうパターンは大事だと思います——同じ失敗に当たっては手作業で直すことを繰り返しているなら、あなたが抱えているのは workflow の問題ではなく、ケイパビリティ継承の問題です。成功した修正がシステムの一部にならなければならない——誰かの頭の中にとどまっていてはいけない。
これがまさに、私たちが evomap.ai を作り始めた理由です。私たちは agent が現実の問題を解くのを見続けてきました——デバッグ、テスト、ドキュメント——そして次の実行までに、彼らが摑んでいたすべてが消えていきました。だから問い始めたのです——成功した修正がパッケージ化され、共有され、他の agent に自動で継承されるなら、どうなるのか？それが私たちの Genome Evolution Protocol の核となるアイデアです——もっと賢いモデルを作るのではなく、ある agent が必死で得た解を蒸発させないようにすること。同じ「直す-忘れる-繰り返す」のループに足を取られているなら、あなたの問いを直接投げて返ってくるものを見てみる価値があるかもしれません。
FAQ
Agentic workflow は結局なんですか？普通の AI agent や単純な自動化とどう違いますか？
Agentic workflow は、硬直した自動化と完全自律 agent のあいだに座ります。事前定義された構造（ステップ、遷移、チェックポイント）を持ちつつ、その構造の中で意思決定の権限を AI モデルに渡しているのが特徴です。普通の自動化は固定ルールに従います。純粋な agent はすべてを自分で決めます。Agentic workflow は、定義されたステージをどのように完了させるかの自律性をモデルに渡し、全体の流れは人間が設計します。
2026 年で実用的な agentic workflow のリアル例は？
自己修正つきのコード生成、多ソースのリサーチ統合、検証つきの文書抽出、品質チェックつきのカスタマーサポートのドラフト作成、human-in-the-loop な修復を含む運用監視。共通する筋は——複数のステップ、ツール利用、そして出力に対する何らかの評価を経て結果を届けるタスクであることです。
Agentic workflow はメモリ、コンテキスト、多段タスクをどう扱いますか？
短期コンテキストは典型的にはモデルのコンテキストウィンドウで管理します——会話履歴やツール結果がメッセージとして流れていきます。より長い workflow では、チームは外部ステートストアを使います——データベース、ファイル、または専用のメモリシステムが、情報をステップを越えて永続化します。多 agent システムでは、すべての agent が読み書きできる共有ステートオブジェクトをよく使います。コンテキスト管理は、この領域でいまも最難関のエンジニアリング問題の一つです。
Previous Posts:
- 本文で扱った workflow パターンの下層で、現代の agent システムがどう積層しているかをはっきり見たいなら——OpenHarness、GEP、agent stack layers を解きほぐすこちらの記事がアーキテクチャ側へ直結します：OpenHarness and GEP Agent Stack Layers
- 上で触れた「workflow vs ケイパビリティ継承」の問題は、再利用可能な skill と再利用可能な手続き的アセットを並べて比べると、もっとはっきり見えてきます：Agent Skills vs GEP Assets Real Difference
- 本文の自己修正やオーケストレーションのパターンに引っかかったなら、agent execution chains と hooks を扱ったこの記事が自然な次の読み物になります：Agent Hooks AI Execution Chains
- 本番での agentic workflow の最大の失敗モードのひとつは、修正が実行をまたいで保持されないこと。その学習ギャップをより深く掘り下げているのがこちら：ARC AGI 3 Agent Learning Gap GEP
- メモリ、オーケストレーション、workflow の永続化を扱う実用フレームワークを比較検討しているなら、Mem0、LangGraph、CrewAI、ハーネスエンジニアリングのパターンを並べたこの記事が、本文の自然な続編になります：Harness Engineering Mem0 LangGraph CrewAI
