9月4日、AWSが「Best practices for building agentic automations with Amazon Quick Automate」と題した記事を公開した。この記事では、Amazon Quick Automateを使って本番グレードのエージェントベース業務自動化を構築するためのベストプラクティスについて詳しく紹介されている。

Amazon Quick Automateとは

本題に入る前に、サービスの位置づけを整理しておく。Amazon Quick Automateは、Amazon Quickに組み込まれたマルチエージェント自動化機能だ。部門をまたいだシステム連携、UI/API操作、サードパーティアプリとの統合を複数エージェントで協調させて実現する。

AWS Step Functionsのようなワークフローオーケストレーターや、Amazon Bedrock上に構築するカスタムエージェントとの違いは、ノーコード／ローコードの操作性と、エンタープライズSaaSとの標準コネクタ群を最初から備えている点にある。エンジニアリングチームが一から構築するのではなく、業務部門が主体となって自動化を設計・運用できることを想定したサービスと理解するとよい。

「まず自動化ありき」が失敗の元

記事の冒頭でAWSが強調しているのは、技術よりもプロセス設計の重要性だ。「最もよく見る失敗は、自動化する対象のプロセスを本当に理解する前に、いきなり自動化の設計に飛びつくことだ」と明言している。

自動化に向いているプロセスの特徴として、記事では以下を挙げている：

• 複数の基幹システムをまたいで処理が走る
• メールやPDFなど非構造・半構造のデータを入力として受け取る
• 単純なif-then分岐ではなく、文脈に基づく判断が必要
• 例外処理が多く、従来のスクリプト型自動化では対応しきれない

具体例として挙げられているのがベンダー請求書処理と従業員オンボーディングだ。請求書はPDFで届き、発注書との照合、承認ルーティング、ERPへの転記が必要になる。オンボーディングはHR・IT・施設管理の各システムにまたがる。どちらも「ルールを全部書き下せない」類の処理だ。

さらに重要なのが「あるべき姿（to-be）のプロセス設計」を先に行うことだ。既存の手動フローをそのままエージェントに置き換えるのではなく、「エージェントが処理する世界ではどうあるべきか」をゼロから考え直す。システム間でデータを転記していたステップや、可視性のためだけに存在していた中間承認などは丸ごと削除できる。記事にあるルールが秀逸で、「削れるステップは全部削れ。たまにいくつか戻さざるを得なくなるくらいでなければ、削り方が甘い」とある。

エージェント設計の核心：責任範囲を絞る

「何でもやる一つのエージェント」は、作りにくく、デバッグしにくく、信頼しにくい。コストも高い。AWSの推奨はエージェント1つにつき、1つの明確な責任を持たせることだ。

請求書処理を例にとると：

• エージェントA：受信した請求書を読んで構造化データに変換
• エージェントB：抽出データと発注書・契約書を照合して差異を検出
• エージェントC：金額・カテゴリに基づいて承認ルートを決定

こうすることで問題が起きた際に原因エージェントがすぐ特定できる。

Quick Automateには責任の絞り込みを助ける2つの機能がある。

ツールのスコープ制限：各エージェントに必要なツールだけを与える。ドキュメント抽出エージェントにはAmazon TextractやAmazon Bedrock Data Automationへのアクセスを許可し、それ以外は渡さない。なおAutomation Assistantが提供するプロセス説明に基づいて、ツールのスコープを自動で絞ってくれる。

Structured Output：エージェントが返すデータの形式をスキーマで定義する。「ベンダー名・請求書番号・明細・合計額を返す」と指定することで、次ステップへの引き渡しが安定し、パースエラーの一クラスがまるごと消える。

エージェントと決定論的ステップの使い分け

記事が特に実践的な知見として強調しているのが、「エージェントを使う場面」と「コードや条件分岐など決定論的なステップを使う場面」の使い分けだ。

判断の目安はシンプルだ：

• ルールを完全に書き下せるなら→決定論的ステップ（コード実行、条件分岐）
• 非構造データの解釈や文脈判断が必要なら→エージェント

Quick Automateの課金はトークン数ではなくエージェント稼働時間（agent hour）で計算される。決定論的ステップはモデルを呼ばずに高速実行されるため、全体の実行時間を短縮しコストを下げる直接的な効果がある。トークン課金に慣れた読者には直感に反するかもしれないが、これはバッチ処理や長時間稼働フローにおけるコスト予測をしやすくする設計上の選択でもある。

ヒューマンインザループの設計

完全自動化は高リスクプロセスには向かない。Quick Automateは2パターンのHITL（Human-in-the-Loop）をサポートする：

• ブロッキング型：人間の承認が来るまでワークフローが停止。大口支払い、契約書の顧客送付、基幹システムへの修正ポスティングなどに適用する
• ノンブロッキング型：担当者に通知しつつ次のトランザクション処理は継続。非同期で例外対応が可能

どの程度人間レビューを挟むかはデータを見ながらチューニングする問題だ。レビュアーが実際にエージェントの判断を覆す頻度を測定し、信頼できると分かった範囲から徐々に自動処理の閾値を上げていく、という運用が推奨されている。

評価と観測性

エージェントは実行のたびに同じパスをたどるとは限らない。そのため評価はローンチ前の一回限りのテストではなく、継続的な運用規律として位置付けられている。

Quick Automateにはカスタムエージェントユニットテスト機能があり、個々のエージェントに対して期待する入出力を定義して単体で実行できる。フルワークフローを組む前に各エージェントを単体で検証することで、障害の切り分けが格段に楽になる。

実行ログはステップ単位、ツール呼び出し単位で記録される。メトリクスはAmazon CloudWatchに流れるため、既存の運用ダッシュボードにそのまま統合できる。

認証設計：サービス認証とユーザー委任の使い分け

エージェントが企業システムにアクセスするための認証設計は、「誰の権限でアクションを実行するか」という問いに直結するため、ガバナンス上も重要なポイントだ。Quick Automateは2モデルを提供する：

• サービス認証：スケジュール・トリガー実行など人が関与しない常時稼働プロセス向け。自動化自体がIDを持ち、アクションはそのIDに紐づく。監査ログにおいても「誰が実行したか」が明確になるため、コンプライアンス要件の厳しい業務フローに適している
• ユーザーベースの3-legged OAuth：チャットやパーソナルフローなど、特定ユーザーの代理として動作するケース向け。エージェントは呼び出し元ユーザーの権限スコープ内でのみ操作できるため、過剰権限によるリスクを構造的に抑えられる

どちらのモデルを選ぶかは処理の性質と監査要件に応じて判断することになる。記事ではこの使い分けを「権限の最小化」原則と結びつけて説明しており、認証設計を後回しにしないよう注意を促している。

詳細はBest practices for building agentic automations with Amazon Quick Automateを参照していただきたい。