LLMワークフロー設計の考え方 | AIに考えさせなくていい業務のほうが実は多い

企画職の担当者に向けて、AIを使った多段処理を「ワークフロー」として組む考え方を、開発現場の視点から整理します。
AI活用の企画を立てるとき、自律的に動くエージェントの構成が最初に候補になりがちです。

自分で状況を判断して、必要な作業を選んで進めてくれる。魅力的です。

ところが対象の業務を具体化していくと、こういう話になります。

「まず添付ファイルから項目を抽出して、顧客マスタと照合して、内容を要約して、システムに登録する」

順番、決まっています。

順番が決まっているなら、それをAIに考えさせる理由はありません。

分かれ目は「順番を誰が決めるか」だけ

AIを使った多段処理には2つの形があります。違いはひとつだけです。

• ワークフロー — 処理の順番を人間がコードに書く
• エージェント — 処理の順番をAIがその場で決める

ここで混同されやすいのですが、ワークフローだからAIを使わないという話ではありません。

さきほどの例でも「項目を抽出する」「内容を要約する」はAIが担います。
固定されているのは工程の並びであって、各工程の中身ではありません。

そして順番が固定されていると、次の2つが変わります。

1件あたりにAIを何回呼ぶかが確定するので、1件あたりの費用と所要時間が計算できます。月あたりの件数を掛ければ運用費の見積もりになります。

各工程の入力と出力が決まるので、工程ごとにテストが書けます。

エージェントの場合、呼ぶ回数も順番も要求によって変わるため、この2つが幅を持った推定になります。
自由度の代償はここに出ます。

ここに注意
「AIに任せる範囲」と「順番を決める主体」を分けて議論すると、話が早くなります。
AIを使う工程がいくつあっても、順番が決まっているならワークフローです。
この整理をしないまま「エージェントで」と決めると、決まっていたはずの順番が毎回揺れる構成になります。

工程に刻むことが、失敗への備えになる

多段処理では、どこかの工程が必ず失敗します。
外部APIが応答しない、混雑して時間切れになる、サーバーが再起動する。

ワークフローとして組む仕組みでは、終わった工程の結果が保存されます。

抽出（済） → 照合（済） → 要約（済） → 登録（失敗）
                                        ↑ ここだけやり直す

5工程めで落ちても、1から4はやり直しになりません。

逆に言えば、処理をひとつの大きな塊にしてしまうと、この利点が消えます。
最後で落ちたら全部やり直しです。AIの呼び出しも、その分の費用ごとやり直しになります。

だから工程の区切り方が設計項目になります。目安は、外部とのやり取りが1つ入るたびに区切ることです。
AIの呼び出しとDBへの書き込みを同じ工程に入れると、書き込みだけが失敗したときにAIの呼び出しからやり直すことになります。

ただし細かく刻みすぎると、工程間で受け渡す結果の保存量が増えます。
工程ごとの結果には保存できる大きさの上限があるので、画像やPDFのような大きなデータはファイル保管サービスに置いて参照だけを渡す作りにします。この受け渡し方は先に決めておく必要があります。

「待つ」ことを処理の一部として書ける

業務の流れには、待ちが含まれます。

翌営業日の朝まで待つ。上長の承認を待つ。先方からの返信を待つ。

ワークフローとして組むと、この待ちを処理の途中として保持できます。待ち方は2種類です。

時間で待つ — 「3営業日後に督促を送る」のように時刻が決まっている待ち。指定できる待ち時間は最長1年とされています。待機中の処理は同時実行の枠を消費しないため、大量の案件を並行して待たせられます。

出来事を待つ — 「承認ボタンが押されるまで」のように、いつ来るか分からない待ち。通知や承認が届いた時点で、その工程から再開します。

これが効くのは承認業務です。

申請から承認までの間には、人間の都合による長い空白が入ります。
この空白を処理の途中として保持できるので、「申請を受け付ける処理」と「承認後に実行する処理」を別々のプログラムに分けて、その間の状態を自前のテーブルで管理する必要がなくなります。

1本の流れとして書けるため、どの案件がどこまで進んでいるかも追いやすくなります。

一方で、待つ仕組みがあるからこそ期限を決めておかないと処理が残り続けます。
承認が来ないまま1か月経った案件をどう扱うのか。自動で却下するのか、催促するのか、担当者の一覧に出すのか。

これは技術的な選択ではなく業務ルールなので、企画側で決めておく項目になります。

ここに注意
待っている処理は、外から見ると「何も起きていない」状態です。
何を待っているのかを担当者に見せる画面を用意しておかないと、止まっているのか進んでいるのかが分からないという問い合わせが発生します。
待ちを設計に入れるなら、待ち一覧の画面も要件に入ります。

2回実行されても壊れない工程にする

失敗した工程は自動で再試行されます。

ということは、1回で終わるつもりだった処理が2回走る場合があります。
公開されている設計指針でも、工程は理想としては何度実行しても同じ結果になるように作るべきだとされています。

工程の種類によって、影響がまったく違います。

下の3行が問題です。そして、ここは実装だけの話になりません。

「すでに実行済みかを確認する」と書くと簡単に見えますが、何をもって同一の処理と見なすかは業務の定義です。

同じ顧客の同じ月の請求はひとつなのか。同じ金額でも別の請求になり得るのか。
この判定に使える識別子が業務データの中に存在するかどうかを、設計の前に確かめる必要があります。
存在しない場合は、識別子を発行する仕組みそのものを作ることになります。

なお、決済サービスをはじめとする外部APIには、同じ識別子を付けた要求を1回だけ受け付ける仕組みが用意されていることがあります。
使えるなら自前で判定を作るより確実なので、サービス選定時の確認項目に入れておくとよいでしょう。

結論：混ぜるのが現実的

ワークフローとエージェントは、どちらか一方を選ぶ問題として立てると判断が難しくなります。

実務的なのは、全体の流れをワークフローで固定し、手順が読めない工程だけをエージェントにする構成です。

受付（固定） → 調査（エージェント） → 承認待ち（固定） → 登録・通知（固定）

自由度が必要なのは1工程だけ、という業務は珍しくありません。
その工程には往復の上限を置き、外側の流れは固定したままにします。

この形をとると、エージェント部分が期待どおりに動かなかった場合でも、その工程を条件式や定型処理に置き換えるだけで済みます。
最初から全体をエージェントにすると、この差し替えができません。

比較の観点を整理すると、こうなります。

エージェント側の利点は「想定外の入力」の行だけです。
そこが要件として本当に必要なのか、必要なのはどの工程なのか。ここを詰めるのが企画側の仕事になります。

本記事は当社の開発経験と公開情報に基づく整理です。各サービスの仕様や上限値は継続的に更新されており、最適な設計の考え方も変化する可能性があります。AIワークフローの設計に関するご相談も承ります。