AIエージェントのワークフロー設計ガイド｜工程の分解から評価・停止条件まで
約1分で読めます
AIエージェントのワークフローは、業務を小さな工程に分け、各工程の入力・判断・出力と、次に進む条件を決めることで設計できます。まず完了の定義を置き、柔軟な解釈が必要な部分だけをAIに任せ、固定できる処理や停止条件はプログラムで管理しましょう。
この記事の要点
- 完了条件から始める：目的、必要な成果物、確認方法を先に定義し、作業を工程に分けます。
- AIと固定処理を分担する：文章の解釈や調査の方針はAIに、計算や必須項目の確認は決定的な処理に任せます。
- 分岐と停止を設計する：情報不足、検証失敗、時間や回数の上限に達した場合の次の行き先を決めます。
- 成果と過程を評価する：最終回答の品質だけでなく、実際の結果、途中の判断、所要時間や費用も確認します。
AIエージェントのワークフローとは
AIエージェントのワークフローとは、目的を達成するために、情報の取得、判断、処理、結果の確認をどうつなぐかを定めた仕事の流れです。すべての手順を固定する必要はありません。順序が決まった部分の中に、AIが状況に応じて次の調査や判断を選ぶ部分を組み込めます。
例えば、問い合わせ対応では「内容を分類する」「必要な情報を調べる」「返信案を作る」「根拠を確認する」という流れを設けます。このうち、文章の解釈にはAIを使い、必要な項目の有無や処理の終了条件はプログラムで確認する設計が考えられます。
Anthropicの設計ガイドは、あらかじめ決めた経路をたどるワークフローと、モデルが手順を動的に選ぶエージェントを区別しています。実際の設計では、どちらか一方を選ぶよりも、工程ごとに自由度を決めることが重要です。
AIエージェントのワークフローを設計する6つの手順
1. 目的と完了条件を決める
「問い合わせを処理する」だけでは、どこまでできれば完了なのか判断できません。誰が使う成果物を、どの状態で渡すかまで書きます。
例えば「対象となる問い合わせについて、参照した資料を添えた返信案を作り、不明点があれば担当者に伝える」と定義します。資料に答えがない場合は、推測で埋めず「情報不足」として終了することも、適切な結果です。
2. 入力と作業を分解する
開始のきっかけ、利用できる入力、必要な成果物を列挙し、その間を具体的な動詞でつなぎます。問い合わせ対応なら、受付、分類、資料の取得、返信案の作成、確認、担当者への引き渡しです。
各工程には、少なくとも次を記録します。
- 入力：どの情報を受け取り、何が欠けていると進めないか。
- 処理：AIによる解釈か、決められた処理か。
- 出力：次の工程に渡す内容と形式。
- 確認：何を満たせば次に進めるか。
- 例外：確認できない場合や処理に失敗した場合の行き先。
3. 判断点と分岐を置く
各工程の後に「次に進むために何が必要か」を決めます。例えば、対象資料が見つかった場合は返信案を作り、見つからなければ情報不足として担当者に引き渡します。分類が曖昧な場合も、無理に一つの経路へ押し込まず、確認が必要な状態にできます。
分岐に使う条件は、可能な限り具体的にします。「適切なら続行」よりも「参照資料があり、回答の必須項目が埋まっている場合に続行」のほうが、後から検証しやすくなります。
4. 各工程の担当を決める
文章の解釈、資料の関連性の判断、返信案の作成などは、入力に応じた柔軟さが必要です。一方、必須項目の有無、文字数、日付の形式、集計結果などは、定められた規則で確認できます。
同じ工程でも、AIが提案した分類を固定ルールで検証するように、役割を組み合わせられます。最初からすべてを自律化せず、シンプルな構成を基準に必要な自由度を足していきましょう。
5. 結果の確認と停止条件を設ける
成果物の形式だけでなく、目的を満たしたかを確認します。例えば、返信案に参照資料が付いていても、その資料が質問への回答を支持しているとは限りません。内容の確認方法と、判断できなかったときの扱いも決めます。
処理の上限に達した場合、必要な情報を取得できない場合、確認に繰り返し失敗する場合は、処理を止めて理由と途中結果を残します。停止を「完了」「情報不足」「上限到達」「処理失敗」のように区別すると、次の対応を選びやすくなります。
6. 代表例と例外で試す
通常の入力に加え、曖昧な問い合わせ、資料が見つからないケース、矛盾する情報があるケースを用意します。期待する出力と停止状態を事前に決め、変更の前後で同じケースを実行して比較します。
AIに任せる工程と決定的な処理の使い分け
判断の基準は「AIにできるか」ではなく、その工程に柔軟な解釈が必要か、同じ条件なら同じ結果が必要かです。両者を混ぜる場合も、どの出力を次の判断に使うかを明確にします。
AIが担うとよい工程
問い合わせの意図を読み取る、複数の資料から関連する箇所を探す、情報を比較して文章にまとめるなど、入力の表現や進め方が変わる工程です。必要に応じて次の調査を選ぶ余地を設けられます。
ただし、AIによる分類や要約は正しいとは限りません。出力には根拠や不明点を含め、別の工程で確認できる形にします。AI自身の「自信がある」という申告だけを、正確性の証明にはしない設計が有用です。
固定ルールで処理するとよい工程
数値の合計、決められた形式への変換、必須項目の検査、実行回数の上限判定は、条件と結果を明示しやすい処理です。固定処理で結果を確認できる部分までAIの判断に任せる必要はありません。
例えば、AIが「対象期間」を文章から読み取っても、開始日が終了日より後ではないかの判定はプログラムで行えます。形式の確認に通っても期間の解釈が正しいとは限らないため、内容面の確認は別に残します。
人が引き受ける判断
資料が矛盾している、質問の意図を絞れない、組織の方針を解釈する必要がある場合は、担当者が判断できる経路を用意します。引き渡す際は、未解決の論点、参照した資料、実施済みの作業を添えると、最初から調べ直す負担を減らせます。
ワークフローの構成パターンと選び方
工程のつなぎ方は、業務に必要な判断の幅から選びます。Anthropicが紹介する設計パターンを参考に、まずは次のように整理できます。
順番に進む：工程が明確な仕事
決まった順序で処理し、途中に確認を挟む形です。例えば、資料から要点を抽出し、内容を確認してから報告文を作ります。工程ごとの入出力を追いやすく、どこで不備が生じたかを調べやすい構成です。
条件で分岐する：入力の種類で処理が変わる仕事
入力を分類し、種類に応じた処理へ進めます。問い合わせの内容に応じて、製品案内と技術的な調査を別の流れにする例です。分類できない入力の行き先も用意しておきます。
繰り返し調べる：次に必要な情報が途中で決まる仕事
調査結果を確認し、不足があれば次の調査を行う形です。例えば、企業の公開情報を調べる際、最初の資料では事業内容が分からなければ別の資料を探します。
この場合は、調査の自由度だけでなく、打ち切る条件も必要です。検索回数や時間の上限、必要な根拠がそろったとき、追加調査でも進展がないときなどの扱いを事前に決めます。
並行して進める：独立した調査がある仕事
互いに依存しない項目を別々に調べ、結果をまとめる形です。例えば、複数の製品について同じ項目を調査し、最後に比較できます。結果を統合する際は、各調査の対象期間や根拠がそろっているかを確認します。
設計例：問い合わせの返信案を作成する
ここでは、サポート担当者が確認できる返信案を作る架空のワークフローを考えます。目標は自動送信ではなく、問い合わせに対応する資料と、不明点を明示した返信案を渡すことです。
- 受け付ける：問い合わせ本文と対象製品を受け取ります。対象製品が不明なら、担当者に確認が必要な状態で止めます。
- 内容を分類する：AIが質問の要点と想定される分類を出力します。分類できない場合は、不明点を添えて担当者に渡します。
- 資料を調べる：関連資料を取得し、AIが質問に関係する箇所を選びます。見つからなければ「情報不足」で終了します。
- 返信案を作る：AIが選んだ資料を基に案を作り、使った資料と回答できない点を併記します。
- 確認する：プログラムで必須項目を検査し、担当者は資料が回答を支持しているか確認します。
- 結果を引き渡す：確認可能な案、参照先、未解決事項をまとめ、担当者に渡して終了します。
例えば「製品Aの設定を変更したい」という問い合わせで、該当する手順が資料に見つからなかった場合、もっともらしい設定方法を補うのではなく、調べた資料と不足情報を添えて終了します。
外部ツールやAPIを使う工程では、ワークフローの判断と、それを実行する層を分けて考えられます。Relvoは、エージェント向けのツールやAPIをつなぐスマートルーターとして構想されています。ワークフロー自体の設計や完了判定は、別途アプリケーション側で行います。
結果をどう評価し、改善につなげるか
ワークフローの評価では、回答の文章だけでなく、期待した仕事が実際に完了したかを確認します。Anthropicのエージェント評価ガイドも、実行の記録と、実行後に環境がどうなったかを区別しています。例えば「記録しました」という返答と、実際に記録が作成されたことは別の確認対象です。
成果・過程・負担を分けて測る
- 成果：必要な項目を満たしたか、根拠が内容を支持しているか、正しい停止状態になったか。
- 過程：どの分岐を通り、どの資料を参照し、どこで確認や引き渡しが発生したか。
- 負担：処理にかかった時間、実行回数、費用、担当者が修正に要した手間。
たとえば返信案が作成されても、参照資料が質問と無関係なら成果は不十分です。反対に、情報不足を正しく検出して担当者に渡した場合は、返信案がなくても設計どおりの結果になり得ます。
テストケースと合格基準を先に作る
通常ケースだけでなく、入力が欠けた場合、複数の解釈が可能な場合、資料が矛盾する場合、上限に達した場合を含めます。各ケースに「期待する成果」「停止状態」「担当者に渡す情報」を書いておきます。
AIの出力にはばらつきがあるため、同じケースを複数回試し、結果を比較します。採点は、形式や数値のように自動判定しやすいものと、根拠の妥当性のように人の確認が必要なものを分けます。変更後は、改善したいケースだけでなく、以前できていたケースも再実行して後退を確認します。
失敗した工程を特定してから変更する
分類の誤り、取得した資料の不足、返信案への反映漏れでは、修正すべき場所が異なります。実行記録をたどり、失敗した工程とその入力を特定してから、指示、分岐条件、確認方法のいずれかを変更します。
変更後は同じテストケースで再評価し、品質と時間・費用の両方を比較します。複雑な仕組みを追加する前に、単一の処理や固定ルールで目的を満たせないかも確認しましょう。
いつ止めるか：完了・保留・失敗を分ける
停止条件は、処理を打ち切るためだけのものではありません。次に誰が何をすべきかを明確にするため、終了理由と引き渡す情報をセットで設計します。
- 完了：必要な成果物がそろい、定義した確認条件を満たした状態です。成果物と参照した情報を渡します。
- 情報不足：必要な資料や入力が見つからず、判断を続けられない状態です。足りない情報と、確認済みの範囲を示します。
- 上限到達：あらかじめ設定した時間、工程数、調査回数などの上限に達した状態です。途中結果と未完了の作業を残します。
- 処理失敗：必要な工程が実行できず、結果を確認できない状態です。失敗した工程と分かっている範囲の理由を残します。
上限値は業務ごとに決める設計値であり、一律の正解ではありません。最初に仮の値を置き、実際のテストで、途中で打ち切りすぎていないか、逆に進展のない処理が続いていないかを確認して調整します。
確認に失敗した際に作り直す場合も、無制限には繰り返さず、回数上限と引き渡し先を決めます。途中結果が使える状態でも、完了条件を満たしていなければ「完了」とは区別しましょう。
まとめ
AIエージェントのワークフローは、自由に動ける範囲を広げることよりも、仕事の目的と各工程の責任を明確にするところから始まります。AIには柔軟な解釈や調査を任せ、固定できる確認や停止条件は仕組みとして定めます。
まずは一つの業務について、完了条件、工程、分岐、停止時の引き渡しを紙に書き出してみてください。通常時と例外時の両方を試し、実際の成果と負担を比較することで、必要な部分にだけ自律性を広げられます。
よくある質問
AIエージェントのワークフローは、すべての工程をAIに任せる必要がありますか？
いいえ。文章の解釈などにAIを使い、計算、形式の確認、停止条件の判定は固定ルールで処理できます。工程ごとに、柔軟性が必要か、同じ条件で同じ結果が必要かを考えます。
ワークフロー型と自律型はどのように使い分けますか？
手順があらかじめ決まっている業務では、固定した流れが出発点になります。次に必要な情報が途中で変わる調査では、一部をAIの判断に任せつつ、作業範囲と停止条件を決める方法があります。
完了条件と停止条件の違いは何ですか？
完了条件は、仕事が目的を満たしたと判断するための条件です。停止条件には完了のほか、情報不足、処理の上限到達、失敗など、目的を満たさずに終了する場合も含めます。
ワークフローの品質は何で評価すればよいですか？
成果物が要件を満たすかに加え、実際の結果、判断の過程、所要時間、費用、担当者による修正の手間を確認します。通常ケースと例外ケースを用意し、変更前後で同じ基準を使って比較します。