Amazon Quick Automate のネイティブケース管理機能によるエージェントワークフローの拡張

人工知能（AI）エージェントは、概念実証段階では請求書の処理や保険金請求の審査支援、サポートチケットの分類などを担うことができます。しかし、こうしたエージェントを実環境で数千件あるいは数百万件の業務項目にわたって運用しようとすると、全く異なる課題が浮き彫りになります。

企業規模での成功には、エージェントそのものだけでなく、さらに多くの要素が求められます。各業務項目が複数のエージェントやシステムを通過する際のステータスを追跡し、失敗が発生した場所と原因を明確に把握すること、必要に応じて人間が介入できる仕組みを用意すること、そして需要に応じてインフラを動的に拡張できることが不可欠です。

Amazon Quick Automate は、こうした運用上の課題に対し、ケース管理 を通じて対応します。すべての業務項目はライフサイクルを通じて永続する「ケース」として表現され、ワークフローのステータスを段階的に可視化できます。また、判断を要する場面では人間の介入（ヒューマン・イン・ザ・ループ）をサポートし、並列実行も可能にするため、チームはエージェントをオーケストレーションして業務プロセスの大規模自動化を実現できます。

本稿では、Quick Automate のケース管理機能とエージェント型自動化機能を組み合わせて活用する方法をご紹介します。ケース管理の概要を解説し、ケース作成から処理、解決に至るまでのエージェントワークフローにおけるライフサイクルを追跡します。

単一または複数のケースを作成・管理する方法や、ステータスの自動追跡・更新、例外への対応、さらにワークフロー内に Human-in-the-loop (HITL) ステップを組み込む手法についても解説します。また、動的なスケーリングを可能にする「ケース作成者 - 処理者」のパターンも紹介します。

最後に、HITL やケース追跡を含むエンタープライズプロセス向けのケース管理構造について、実際のユースケースを通じて詳しく説明します。

Amazon Quick 内に AI エージェントとワークフローオーケストレーションを統合した Quick Automate は、アプリケーション、UI、API をまたぐ複雑なエンドツーエンドのビジネスプロセスを自動化します。エージェント型と決定論的な自動化機能をエンタープライズ向けワークフローオーケストレーションにネイティブで組み合わせることで、Quick Automate はエージェント主導のビジネスプロセスに構造化・可視化・制御をもたらします。

追跡可能な作業項目を備えたケース管理機能や、細粒度アクセス管理、アクティビティログ、バージョン管理、例外処理、HITL 対応などの制御機能をネイティブで提供します。その結果、エンタープライズ規模でもプロセスが開始から解決まで確実に進行します。

Quick Automate のケース管理機能には、いくつかの重要な利点があります。ワークフローが明確に定義されたステージを進行する際にリアルタイムで追跡できるため、可視性が向上します。プロセスオーナーは各作業項目の現状を正確に把握でき、マネージャーはスループットを監視し、ボトルネックを早期に発見して遅延がビジネス成果に影響を与える前に介入できます。

並列処理により複数のケースを同時に実行できるため、スループットが増加し、組織がビジネスサービスレベル契約（SLA）の達成を支援します。すべてのアクション、意思決定、状態遷移がケース履歴の一部として記録されるため、コンプライアンス、監査可能性、ガバナンスも強化されます。

リアルタイムのステータス更新によりオペレーター、マネージャー、ビジネス関係者が常に情報を共有できるため、ステークホルダーとのエンゲージメントも高まります。各ケースの文脈内でコミュニケーションが行われるため、断片化されたメールスレッドに代わり、中央集権的なコラボレーション、明確な所有権、そして引き継ぎのミスを減らすことができます。

前提条件

Quick Automate でケース管理ワークフローを実装する前に、Amazon Quick へのアクセス権限があること、および組織の要件に合わせた正しい AWS リージョンで作業を行っていることを確認してください。Quick Automate のワークフローはリージョン固有のものだからです。また、Quick Automate でワークフローを作成するには、ユーザーアカウントが Enterprise ライセンスを持っている必要があります。

ケースライフサイクルとステータス

ケース管理機能は、Quick Automate において、複雑で長時間実行されるワークフローを並列処理可能な個別の作業単位へと変換します。各ケースは、定義されたライフサイクル段階を経て進行する独立した作業アイテムとして機能します。

ケースには「ケースタイプ」が含まれており、これは請求書やクレームなど関連する業務をグループ化するためのユーザー定義コンテナです。また、追跡用の一意の ID として機能する参照名と、処理に必要なビジネス情報を保持するキー・バリュー形式のカスタムデータフィールドも含まれます。

システムは自動的に追加メタデータを管理します。これにはワークフロー内のケースステータス、エラー発生時の例外詳細、およびケースに関連する実行ログが含まれます。以下の表では、ケースが取りうるライフサイクルステータスを説明しています。

ケース管理自動化のベストプラクティス

Quick Automate における ケース管理 は、標準的な自動化ライフサイクルに統合されています。以下のセクションでは、設計から本番環境での監視に至るまでの各フェーズを順を追って解説します。

自動化の設計

ワークフローを設計する際は、まず「自社の自動化において何がケース（案件）となるか」を明確にするところから始めましょう。ケースとは、請求書、クレーム、チケット、注文など、開始から解決までを通じてワークフロー上を移動する作業の単一単位を指します。

次に、ケースを作成する方法を決めます。ケースはイベント発生時に個別に作成することもできますし、ファイル、データベース、外部システムなどのソースからバッチ処理で生成することも可能です。さらに、ケースをどのように処理するかについても検討が必要です。ケースは順次処理も並列処理も可能です。単一の自動化でワークフロー全体を実行することも可能ですが、チームでは並列処理の実現と責任の所在を明確にするため、2 つの自動化に役割を分けることが一般的です。

Case Creator は Excel ファイル、データベース、Web アプリケーションなどのソースからデータを取得し、個々のレコードを個別の作業項目を表すケースに変換します。一方、Case Processor はケースを受け取り、例外処理や人間による確認（HITL）タスクを含む実際のワークフローステップを実行します。複数のプロセッサを並列で実行することで、スループットの向上を図ることができます。

最後に、人間による介入が必要な箇所とタイミングを特定し、それをワークフローに組み込みます。チームは、ケースの処理を一時的に停止する「人間のチェックポイント」を作成できます。これにより、レビュー担当者に関連データや判断に必要な項目が表示され、タスク完了後に自動的に処理が再開されます。

自動化の作成

Quick Automate では、作業を取り込むためのアクションとして 2 つの機能が提供されています。

1 つ目は Create New Case です。これは、ユーザーがフォームを送信した、API リクエストが届いた、サポートチケットが発生したといった、個別のイベントをデータソースとする場合に使用します。一意のリファレンス名（例：Order-12345）を設定し、同様のケースをグループ化するケースタイプ（例：SalesOrders）を選択して、ケース固有のデータを格納するキーと値のペアを紐付けます。このアクションは 1 つのケースのみを作成し、即座に「準備完了」状態に設定します。

2 つ目は Create Multiple Cases です。これは、スプレッドシートや CSV ファイル、レコードのテーブルといったデータソースから、一括インポートやスケジュールされたデータ読み込みを行う場合に使用します。ケースタイプとソースとなるテーブルを指定し、一意の ID として機能する列を選択します。このアクションは各行ごとに個別のケースを作成し、各列を自動的にカスタムデータフィールドにマッピングします。

ワークフローが異なるステージを進むにつれて、ケースデータの変更が必要になることがよくあります。[update cases action] を使用すると、ケース ID とキー・バリューペアを指定することで、既存のケースデータに追加したり修正したりできます。このアクションは、処理結果の記録、監査用タイムスタンプの取得、計算値の保存、カスタムステータスの維持などに活用できます。ただし、このアクションが利用可能なのは「進行中（In Progress）」のケースのみです。

自動化内で更新された情報にアクセスするには、updated_case["custom_data"]["key_name"] を使用してください。既存のケースを動的に取得または検索する必要がある場合は、「Search Cases action」をご利用ください。このアクションを使えば、ケースタイプ、参照 ID、ステータス、その他の属性などをフィルター条件としてケースを検索できます。取得した結果は、ケースの詳細を確認したり、追加処理をトリガーしたり、ワークフローの一部としてケースを更新したりするために利用できます。

Human in the loop (HITL) タスクでは、ビルダーは「Create User Task」アクションを使用してケースを一時停止し、人間によるレビュー担当者に文脈や判断に必要なフィールドを表示できます。ケースが「Pending Resolution（解決待ち）」ステータスで待機している間も、他のケースの処理は継続されます。レビュー担当者が Task Center でタスクを完了すると、ケースは自動的に「Ready」ステータスに遷移し、関連する人間の入力結果が反映された上で処理が再開されます。自動化プロセスは最初から再実行されるため、次にどの分岐を実行すべきかを判断するために latest_task_resolution 属性を確認する必要があります。

自動化のデプロイ

自動化を構築したら、本番環境で実行できるよう公開して設定を行います。ワークフローを公開し、定義された間隔で定期的に実行するスケジュールを設定することも可能です。デプロイ時には、主に以下の 2 つの側面を設定します。まず、トリガーの設定において想定される負荷に基づき、同時に並列実行するインスタンス数を決定します。ケース処理用の自動化では、複数のインスタスを並列で実行することで、ケースのボリュームを分散させることができます。次に、HITL タスクについては、Task Center でタスクを解決できるユーザーまたはグループを指定します。デプロイ時には、Quick のユーザーがタスクを完了できるよう、個人やグループを追加して権限付与を行います。

自動化のモニタリング

Amazon Quick Automate（Quick Automate）を使えば、ワークフローを進行中の各ケースのリアルタイム可視化が可能になり、単一のダッシュボードからすべてのプロセッサインスタンスの状態を追跡できます。監視ビューでは、完了率やビジネス例外（必須フィールドの欠落など論理的・データ関連の問題が原因）、システム例外（技術的な障害が原因）、未完了ケースといった主要な指標が表示されます。これらの指標により、チームはボトルネックを素早く特定し、自動化のパフォーマンスを測定できます。各ケースレコードにはステータス、メタデータ、処理詳細が含まれており、ユーザーはケースの詳細にドリルダウンして、利用可能な場合は完全なログ、カスタムデータフィールド、例外メッセージ、タイムスタンプ、スクリーンショットを確認できます。

使用例：ケース管理を活用した複数銀行の明細書処理の自動化

この使用例では、並列処理のためのケース管理機能により、2 つのシステム間での手動データ入力がどのように削減されるかを示します。ソリューションアーキテクチャから実装の詳細まで、実際の財務統合シナリオをたどり、前節で導入された各概念が本番環境の自動化にどう適用されるかを解説します。

複数の金融機関と取引を行う企業は、毎月繰り返される運用上の課題に直面しています。各月の末になると、財務アナリストは各銀行のポータルから明細書をダウンロードし、数百件の取引を手動で自社の中央財務管理システムに入力します。金額の入力ミスが一つでもあれば、照合作業に数時間を要する問題が連鎖的に発生し、SOX（サーベンス・オクスリー法）のコンプライアンス要件を満たすためには、すべての入力データが正確で監査可能な状態である必要があります。この手動プロセスは時間がかかり、ミスも起こりやすく、月次照合を遅らせる要因となっています。

解決策のアーキテクチャ

以下の図は、複数銀行の取引明細処理を自動化するためのエンドツーエンドのソリューションアーキテクチャを示しています。ケース作成と処理を担当する2つの自動化ワークフローが連携することで、並列処理が可能になり、大規模な環境でもサイクルタイムを短縮できます。

最初の自動化（ケース作成）は、最新の銀行明細を取得し、カスタムAIエージェントを用いて各取引を抽出して個別のケースとして読み込みます。2番目の自動化（ケース処理）では、各ケースに対して銀行ポータルへアクセスし、適切な口座を選択した上で取引情報を入力します。複数のプロセッサインスタンスが同時に実行され、それぞれが独立して取引を取得・入力できます。

200ドル以上の支払いは人的レビュー対象としてフラグが立ちます。財務アナリストが受取人、金額、承認の有無を確認し、承認または却下を判断します。却下された取引は、アナリストの理由コードとコメントを記録したビジネス例外として保存され、監査証跡に残ります。

実装：作成者－プロセッサ設計

「ケース作成者」ワークフロー（例：財務諸表の集約）は、主に 3 つの重要な処理を行います。まず、銀行の口座明細書ポータルにアクセスして最新の明細書をダウンロードします。次に、カスタム AI エージェントがダウンロードした PDF を解析し、各取引を構造化されたデータフィールドとして抽出します。最後に、抽出された取引ごとにケースを作成するバッチ処理を実行し、下流の処理のためにすべてのケースを「準備完了」状態に設定します。

下の画像は、Quick Automate で作成された「ケース作成者」ワークフローを示しています。このワークフローには 2 つのプロセスステップが含まれています。1 つ目はブラウザによるポータルへの移動と PDF のダウンロードを担当し、2 つ目はカスタム AI エージェントによるデータ抽出と、その後のバッチケース作成を呼び出します。

図 2: Quick Automate の「ケース作成者」ワークフロー

ワークフロー内でネイティブに使用されるのは、アクションと指示を設定した専用タスクエージェントである「カスタムエージェント」です。このエージェントはダウンロードされた PDF を受け取り、Python コードツールを用いて取引明細行を構造化されたテーブル形式で抽出します。各ケースに必要なフィールドは、エージェントの出力スキーマによって定義されています。以下の画像には、指示と出力スキーマを含むエージェントの設定が表示されています。

エージェントがすべての取引を抽出した後、自動化システムは「複数ケース作成」アクションを使用してバッチ処理でケースを作成します。ここではケースタイプとして"Bank Transaction"を指定し、エージェントの出力テーブルをカスタムデータソースとしてマッピングします。また、Reference 列を各ケースの一意な ID として設定しています。以下の画像には、ワークフロー内でのバッチケース作成の設定が表示されています。

作成された各ケースには、カスタム属性として完全な取引データが保存されます。ケースレコードには、ステータス（Ready）、参照名、タイプ（銀行取引）が含まれ、さらに銀行名、口座番号、取引日、説明、取引種別、金額といったカスタムデータフィールドも格納されています。以下の画像は、ケーステーブルとその主要コンポーネントを示すモニターダッシュボードです。