エンジニアリングシナリオ
参考例エージェント型ワークフロー自動化
複数ステップの業務プロセスをAIエージェントで自動化するエンジニアリングシナリオです。エージェントは計画を立て、ツールを呼び出し、ポリシーチェック、人による承認、完全な監査証跡のもとで行動します。
課題
絶え間なく届く依頼を処理する業務チームを想定します。それぞれの依頼では、非構造化のメッセージやドキュメントを読み、複数の社内システムでレコードを参照し、ポリシーに照らして判断したうえで、1つ以上のシステムを更新する必要があります。手順そのものはよく理解されていますが、入力のばらつきが大きく、ルールベースのワークフローでは対応しきれません。
言語モデルは入力を読み、次に何をすべきかを判断できます。そのため、エージェントにシステムへのアクセスを与えて任せてしまいたくなります。しかし制約がなければ、そのようなエージェントは確信を持って誤ったアクションを取り、障害の後に同じアクションを繰り返し、読み込んだコンテンツに隠された指示に誘導されるおそれがあります。エンジニアリング上の課題は、統制されたプロセスの予測可能性を保ちながら、エージェントの柔軟性を得ることです。
設計が満たすべき要件
- エージェントは、明示的に定められたツール群を通じてのみ行動でき、各ツールは定義済みのスキーマと固有の権限スコープを持たなければなりません。
- データの変更、資金の移動、顧客への連絡を伴うアクションはすべてポリシーチェックを通過し、影響の大きいアクションは人による承認を待たなければなりません。
- ワークフローはプロセスの再起動やモデルのエラーを乗り越え、完了済みのアクションを繰り返すことなく再開できなければなりません。
- エージェントが読み込むコンテンツは信頼できないデータとして扱い、エージェントへの指示や権限を変更できるものであってはなりません。
- すべての計画、ツール呼び出し、承認、結果を記録し、実行をレビューおよび再生できるようにしなければなりません。
- 費用と実行時間はワークフローごとに上限を設け、エージェントが先へ進めない場合には人への引き継ぎが明確でなければなりません。
設計
コンポーネント
推論
- 01
トリガー
イベント、スケジュール、ユーザー要求
- 02
計画
目標を範囲の限られたステップに分解
- 03
ツール呼び出し
型付きツールによる読み取り専用の参照
- 04
アクション案
根拠を添えた変更の提案
統制下の実行
- 01
ポリシーチェック
上限、権限、リスク評価
- 02
人による承認
影響の大きいアクションで必須
- 03
実行
対象システムへの冪等な書き込み
- 04
検証
結果を確認し、再試行またはロールバック
- 05
監査
全ステップを記録し、再生可能に
トリガーと受付
ワークフローは、イベント、スケジュール、またはユーザーの依頼から開始され、開始のたびに一意の実行識別子とともに記録されます。受付では入力を正規化し、添付ファイルを抽出し、依頼の種別を分類します。サポート対象外の種別の依頼は、処理を試みることなく、そのまま人に回します。
永続的なワークフローエンジン
ワークフローエンジンは各実行の状態を保持し、ステップが完了するたびに記録します。ワーカーがクラッシュしたり、モデル呼び出しがタイムアウトしたりした場合、実行は最後に完了したステップから再開されます。タイマー、バックオフ付きのリトライ、人による対応の待機は、いずれも通常のワークフローステップとして表現されます。
プランナーとエージェントランタイム
エージェントは、目標、利用可能なツール、関連するポリシーを受け取り、範囲の限られた一連のステップとして計画を作成します。ランタイムは反復回数、トークン数、経過時間を制限し、上限に達した時点で実行を停止します。エージェントはアクションを提案するだけであり、書き込みを直接実行することはありません。
ツールゲートウェイ
すべてのツールは、検証済みの入力スキーマを持つ型付き関数であり、単一のゲートウェイを通じて公開されます。読み取りツールと書き込みツールは分離され、各呼び出しは、機能するうえで最も範囲の狭いクレデンシャルで実行されます。書き込みツールには、実行とステップから導出した冪等性キーが必須であるため、リトライされたステップが二重に適用されることはありません。
ポリシーとガードレールの層
提案されたアクションは、モデルの外側にある決定論的なルールによって評価されます。金額の上限、許可された対象、必須フィールド、リスク評価です。入力とツールの結果は、モデルに届く前に、注入された指示と機微なデータの有無を確認します。結果は、許可、承認が必要、拒否の3つのいずれかです。
人による承認
承認が必要な場合、レビュー担当者には、提案されたアクション、エージェントが集めた根拠、その背後にある推論が提示されます。担当者は承認、編集、または却下を選択でき、その判断は本人のIDに紐づけて記録されます。定められた時間内にレビューされなかった依頼は、自動承認されるのではなく、エスカレーションされます。
監査と評価
各実行は、入力、計画、ツール呼び出し、モデルの応答、ポリシー判定、承認をトレースとして保存します。同じトレースがリグレッションセットにもなります。記録されたケースは、新しいプロンプトやモデルをリリースする前に、それらに対して再生されます。レビュー担当者による編集と却下は、エージェントのどこに改善が必要かを示すシグナルとして追跡します。
トレードオフ
設計判断
| 判断 | 理由 |
|---|---|
| 自律型エージェントではなく、ワークフロー内に制約されたエージェント | 完全な自律性は未知のケースに対応できますが、テストすることも範囲を限定することも困難です。エージェントを定義済みのワークフローの中に置くと、試みられることが制限され、柔軟性の一部を手放すことになります。その見返りとして、筋道立てて理解でき、評価でき、事後に説明できる振る舞いが得られます。 |
| ポリシーはモデルの外側で、コードによって強制 | プロンプト内の指示は、モデルが通常は従うものの、説得されて逸脱しうるガイダンスにすぎません。そのため、上限と権限は、モデルが影響を及ぼせない決定論的なコードによってチェックします。結果として、一部のルールは、ガイダンスとして一度、強制として一度、合わせて二度記述することになります。 |
| 人による承認はすべてに適用せず、リスクに応じて範囲を限定 | すべてのアクションを承認対象にすると、自動化の利点の大半が失われ、レビュー担当者は内容を確認せずに承認する習慣を身につけてしまいます。一方、何も承認しないのは安全ではありません。アクションを影響度で評価することで、誤りの代償が大きい場面には人を関与させ、リスクが低く元に戻せるアクションは先へ進められます。 |
| 冪等なツールを伴う永続的な実行 | エージェントの実行は長時間に及び、モデル呼び出しやネットワーク呼び出しは日常的に失敗します。ワークフローエンジンは、インフラストラクチャと、習得すべきプログラミングモデルを増やします。しかし、リトライによって同じ支払いやメールが二度送られることを防ぐのは、この仕組みです。 |
| 読み取りツールと書き込みツールをクレデンシャルで分離 | 広い権限を持つ単一のクレデンシャルのほうが、設定は簡単です。スコープを分離しておけば、根拠を収集する段階で悪意のあるコンテンツに誘導されたエージェントは、その時点では書き込み権限を持ちません。これにより、プロンプトインジェクションの影響を封じ込められます。 |
意図する成果
- 定型的なケースは手作業なしで完了し、例外は人に回される運用
- モデルが何を提案しても、定められた上限の範囲内に収まるアクション
- ステップごとにレビューでき、テストのために再生できる実行
- 承認依頼のたびに、根拠と推論を併せて確認できるレビュー担当者
この設計が達成を目指すものです。参考例であり、クライアント案件の実測結果ではありません。
代表的な技術
- Python
- FastAPI
- TypeScript
- LLM APIs
- Durable workflow engine
- PostgreSQL
- Redis
- Kafka
- Kubernetes
- OpenTelemetry