💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

なぜ Workflows が重要なのか

2026年4月12日 時点で LlamaIndex Workflows を見る価値が高いのは、公式ドキュメントが Workflows を イベント駆動の抽象化 と定義しているからです。各 step が特定の event type を受け取り、新しい event を返しながら流れをつないでいくため、複雑な AI アプリの制御をひとつの大きな関数に押し込まずに済みます。

このモデルは agent、RAG flow、extraction flow、そしてそれ以外の複数ステップ処理に向いています。単に見通しが良くなるだけではありません。分岐、状態遷移、人の承認、再試行、デプロイまで同じ考え方で扱えるのが大きな利点です。

LlamaIndex は Workflows が自動で instrument されるとも案内しています。Arize Phoenix のようなツールと組み合わせれば、各 step の動きを観測しやすくなります。本番運用では、最終回答だけでなく途中の動きまで見えることが重要です。

Workflows は何でできているか

基本構成はとてもシンプルです。

Event が流れを開始し、データを次の step に渡します。
Step が event type を処理し、次の event を出します。
Workflow が全体の流れを組み上げます。

step は小さな検証処理でも、複雑な agent でも構いません。これにより、ロジックを補助関数の寄せ集めではなく、実行段階ごとの設計として表現できます。

特に相性がよいのは次のパターンです。

検索前のクエリ改善
複数の RAG 戦略を試して評価する流れ
抽出、検証、修正のループ
人の承認を伴う tool use

どんなときに Workflows を選ぶか

Workflows が強いのは、単にモデルを呼ぶだけではなく、処理の流れを制御したい ときです。

向いているのは次のようなケースです。

前処理、判断、後処理を明確に分けたい
1つ以上の検索や推論経路を試したい
step 間の state を明示的に扱いたい
人の承認や修正が入る可能性がある
自由形式の agent ループより観測しやすい構造にしたい

逆に、単発の呼び出しや短い分類処理なら、Workflows は少し大きすぎるかもしれません。ただし step が 2つ 3つと増えた瞬間に、event ベースの構造が効いてきます。

observability が標準で付いてくる

LlamaIndex は Workflows が自動で instrument されると説明しており、Arize Phoenix のような可観測性ツールに触れています。これは付録ではなく、採用理由のひとつです。

workflow の問題は、最終出力だけでは原因が分かりにくいからです。

入力は正しく整形されているか
分岐は意図した経路を選んだか
retrieval が弱すぎないか
event が途中で失われていないか
retry 後にまだ誤った出力が出ていないか

観測できれば、step ごとに経路を追えます。そうすると、デバッグ、性能測定、改善優先度の判断がしやすくなります。

human-in-the-loop は自然に組み込める

LlamaIndex のドキュメントでは、AgentWorkflow が Workflows の上で動いていると説明されています。human-in-the-loop には InputRequiredEvent と HumanResponseEvent という組み込み event が用意されています。

この設計の良い点は、人的承認を例外処理ではなく event stream の一部として扱えることです。

役立つ場面は次の通りです。

危険な tool call の前に承認が必要
手動レビューのために一時停止したい
長時間処理をあとで再開したい
何を確認し、どう返答されたかを構造化して残したい

たとえば返金、削除、外部書き込みのような操作では、最初からこの形で設計するのが自然です。

LlamaDeploy の役割

LlamaDeploy は local workflow を本番サービスへ橋渡しする層です。公式 docs では、workflow が service として包まれ、control plane と message queue で管理され、production 向けに retry mechanisms と failure handling が備わっていると説明されています。

役割分担を整理すると分かりやすいです。

Workflows はアプリケーションのロジック
LlamaDeploy は実行されるサービス層
control plane は task routing と state 管理の中心
retry と fault tolerance は本番運用の要

ローカル試作から本番へ移すとき、この差はかなり大きいです。

うまく設計するコツ

良い Workflow は、step の数が多いものではありません。境界が明確なものです。

各 step の責務を一文で説明できる
event type を step 間の契約にする
state は明示的に持つ
承認と再試行の挙動を早めに設計する

step が巨大化して条件分岐だらけになると、Workflows の良さが失われます。

導入チェックリスト

本番導入の前に、以下を確認すると安心です。

問題を event と step に分解できるか
中心になるのは agent か、RAG か、extraction か、approval か
どの step から observability を入れるか
human-in-the-loop はどこに置くべきか
まずは standalone の llama-index-workflows で始めるか、bundled 版で始めるか
standalone 2.0 と bundled 1.3 の差を踏まえたか
local と production の設計差を最小にできるか
retry、recovery、fault tolerance の責任分界を決めたか

✍️ 필사 모드: LlamaIndex Workflows 実践ガイド: イベント駆動エージェントと RAG を本番へ運ぶ方法