納期案内をAIに任せるなら、どこまで？RPA・自動処理・エージェントの使い分け

読む内容の解釈にAIが必要なら、流れを固定したAIワークフローが候補になります。調べた結果を受けて次の調査や操作を選ぶ必要がある部分だけ、範囲を限定したエージェントを検討します。

「注文の納期を案内する」なら、どこが変わるか

「注文Aの納期を教えてください」という問い合わせへの返信案を考えます（想定例）。作るのは、担当者が読んでから送る初稿です。使える資料の状態によって、次の手順が変わります。

資料の状態	初稿までの手順	選ぶ理由
注文台帳の納期欄と確定状態がそろう	注文を取得し、確定なら定型文へ。未確定なら確認待ち	値と条件で決まり、文章の解釈をAIに任せる必要がない
注文に対応する商談メモは決まっているが、納期が文章で書かれる	指定メモを読み、「候補」「確定」などをAIが抽出。根拠を添えて初稿へ	読み取りにはAIを使うが、取得先と順序は固定できる
メモに「後日の変更連絡を参照」とあり、参照先を追加で探す必要がある	許可済み資料から変更連絡を探し、必要なら対象・日付を照合して初稿へ	読んだ内容によって次に探す資料が変わる。探索を限定したエージェントの候補

三つ目でも、変更連絡の保存先が注文にひも付いていれば、取得順を固定できるかもしれません。エージェントが向くのは、資料を読んだ後に次の手順を選ぶ必要がある仕事です。納期を確約する根拠がなければ、どの方式でも確認待ちにします。

手順を決める役割と、操作する手段を分ける

ワークフローは「処理の順序や分岐を組み立てた流れ」、エージェントは「許された範囲で、AIが状況に応じて進め方や使う機能を選ぶ構成」です。一方、RPAは主に人の画面操作を代行する手段、APIはシステムの機能やデータをプログラムから利用する接続口です。

「誰が次の手順を決めるか」と「どうシステムを操作するか」は別の問いです。固定したワークフローからRPAを動かすことも、エージェントが許可されたAPIを使うことも考えられます。新旧のランキングに並べず、流れと操作手段を別々に比べます。

Anthropicは、事前に定めた経路でモデルやツールを動かすワークフローと、モデルが進め方を動的に制御するエージェントを区別しています。分類して既定の処理へ振り分ける例もワークフローに含めています。「AIが判断した」「繰り返した」という理由だけで、エージェントと決めつけません。

以下の3図は、注文Aの納期を調べて返信案を作る流れです。3方式とも、返信は担当者が読んでから送ります。図中の「確認依頼」は注文Aの納期問い合わせ、「下書き」はその返信案です。納期欄だけで分かるか、商談メモを読む必要があるか、変更連絡まで探すかを比べてください。

決まった画面操作を続けて使う場合は、RPAの開発・保守で、途中で止まった作業を点検して再開する例を見られます。

入力と分岐が決まるなら、通常処理かAIワークフローで足りる

項目と判定条件がそろうなら、ルール処理を選ぶ

注文番号から台帳を開き、納期欄と確定状態が読めるなら、通常のプログラムで処理できます。「必須欄が空なら確認待ち」「照合できれば定型文へ値を入れる」という流れです。AIに判断を任せる箇所はありません。画面操作が必要な箇所だけRPAを使うこともできます。

この構成を選ぶ理由は、正解をルールとして表せるからです。例外は推測せず人に戻せるなら、固定した流れで扱えます。文章の意味を読み取る必要が生じた場合は、同じルールで対応できる前提を見直します。

図1｜ルール処理。指定データの取得・照合・下書き保存を行います。入力不足・規則外・結果不明で停止し、人へ戻します。

読む工程にAIを使っても、流れは固定できる

参照すべき文書は決まっているものの、記述の表現がそろっていない場合はどうでしょうか。「注文Aの商談メモを開く→AIが納期と確定・未定を読み取る→該当箇所を確かめる→返信案にまとめる」というAIワークフローが候補です。AIが分類を担う場合も、行き先と処理内容はあらかじめ限定します。

AIに任せるのは内容の解釈です。資料の取得順や、足りない情報があった際の戻し先は固定できます。必須項目の形式検査を通っても、読み取りに誤りが残ることがあります。初稿は根拠資料と照らして読み直します。

図2｜AIワークフロー。取得先、処理順、確認待ちへの分岐は固定します。根拠不足・規則外・結果不明で停止し、人へ戻します。

次に調べることが変わる部分だけ、エージェントに任せる

最初の資料だけでは分からず、得られた内容を見て検索語や次に読む資料を変える必要があるなら、探索部分にエージェントを使う余地があります。検索条件の追加などで固定した流れでも足りるかを先に試します。文章の難しさと、進め方をAIに委ねる必要性は分けて考えます。

エージェントを使う場合も、目的、アクセスできる資料、呼び出せる機能、完了条件は先に決めます。調べる作業の記入例で、許す範囲を具体化してみます。

依頼は「注文Aの納期変更メールを探し、現在の納期と未確認点を添えた返信案を作る」。参照先は許可済みの資料群だけ、使える機能は検索・取得・下書き保存だけです。AIは追加検索、資料の読み直し、初稿化を選べます。完了時には調べた結果、根拠の該当箇所、分からなかった点をそろえます。ツール呼び出しの合計10回、または開始から60秒のうち先に達した時点で停止し、途中結果を担当者へ渡します。10回・60秒は、この例で決めた停止条件です。

この例でエージェントに渡す機能は、資料の検索・取得と下書き保存だけです。OWASPのExcessive Agencyは、必要な機能と権限だけを与え、読む用途に不要な送信・削除機能を含めない対策を挙げています。

また、資料中の文章は調べる情報として扱い、操作を命じる権限を与えない設計にします。OWASPのPrompt Injectionは、外部文書などに含まれる内容がモデルを意図しない振る舞いへ誘導する間接的な攻撃を説明しています。外部内容の区別とシステム側の権限制限を組み合わせても、完全防止の保証はできません。

図3｜限定したエージェント。調査結果を受けて次の検索・再確認・初稿化を選びます。根拠不足・規則外・結果不明に加え、この例では計10回の呼び出しか開始後60秒で停止します。

調べる先や作業の順序をAIが選ぶ場合は、業務用AIエージェントの開発で、人が確認する箇所と実行する範囲の分け方を紹介しています。

方式ごとに変わる失敗と、全方式に共通する実行前の確認

接続担当者向け：画面変更・API制限・応答消失時の扱い

画面操作を選ぶと、操作対象を見つける仕組みを調べる必要があります。MicrosoftのPower Automateは、画面要素を特定するセレクターを使います。画面構造や識別に使う属性が変わる場合、同じ対象を選べるかを確かめます。これは画面を使うルール処理にも、画面を使うエージェントにも関係します。

APIは画面をクリックせずに機能を呼べますが、提供元の利用制限を受けます。Microsoft Graphでは、制限時にHTTP 429が返り、Retry-Afterなどに従った待機・再試行が案内されています。採用するAPIの上限、認証条件、エラー時の扱いは、その提供元の資料で確かめます。

試用で確かめる失敗は、ルール処理なら未定義の条件や誤ったルール、AIワークフローなら読み違いや不適切な分類です。エージェントでは、さらに不要な追加調査や目的からの逸脱を点検します。画面変更やAPI制限への対処も、進め方の選定とは分けて設計します。

繰り返し実行も別に見ます。AWSの設計資料は、応答がないときの単純な再試行が、処理の重複を生む問題を説明しています。送信ボタンを押した後に応答が途切れたなら、「失敗した」と決めて再送しません。処理結果を照会し、同じ依頼を二重に実行しない仕組みを用意します。要求IDによる重複防止には、受け側が同じ要求として扱える条件も必要です。

承認前に、対象と実際に行う操作をそろえる

人の承認を置く場合も、承認者が何を見られるかで採用判断が変わります。対象ID、根拠の該当箇所と資料の版・確認時点、未確認事項、実行する操作を示します。送信なら宛先・添付・実際に送る全文、更新なら変更前後の値と対象範囲を並べます。AIによる「問題ありません」という要約だけを承認対象にしません。

承認後に宛先や本文、変更内容を作り直せば、承認した対象と実行対象がずれます。変更時は承認を取り直し、実行直前にも対象と権限を検査します。更新は戻す方法を、送信は取り消せると仮定せず、止める地点と誤送信後の対応先を先に決めます。

例えば、最新の資料を取得できず、送信先も自由文から推測するしかない状態では、承認ボタンがあっても自動送信の範囲を広げません。資料の管理者から正本と適用版を、業務担当者から正式な宛先を、システム管理者から送信結果の調べ方を得るまでは、未確認事項を付けた下書きにとどめます。

まず参照・下書きで試し、停止と再開を確かめる

試用の前に、閲覧する資料、AIへ渡す情報、下書きの保存先を決めます。読み取った情報をどのサービスへ送るかも調べます。

同じ依頼で、通常ケース、資料不足、資料間の矛盾、権限外の要求、接続失敗を試します。必要な箇所の見落とし、根拠の正しさ、人が直した内容と見直しにかかった時間を記録し、単純な方式と比べます。見つからない情報を見つかったように扱わず、確認待ちへ戻せることも評価対象です。

停止した例は、資料・接続・判断基準のどこを直すと再び進めるかを記録し、同じ依頼で試し直します。下書きの試用から更新・送信へ範囲を広げる際の承認、結果の照会、停止・再開の手順は、AIエージェントの監督｜問い合わせ返信で考えるで続けて扱っています。

注文台帳だけで完結するのか、文章を読むのか、次の資料を探すのか。実際の一件を追って、固定できない箇所を探してください。生成AIの導入支援では、その範囲と、人が見る仕事を整理できます。

外部のメールや資料を読む自動処理では、文章に混ざった指示で操作が変わる場合も試しておきます（外部の文章でAIが誤作動する原因と連携時の対策）。

参考出典

• Anthropic「Building effective agents」
• OWASP「LLM01:2025 Prompt Injection」
• OWASP「LLM06:2025 Excessive Agency」
• Microsoft Learn「Automate using UI elements」
• Microsoft Learn「Microsoft Graph throttling guidance」
• AWS「Making retries safe with idempotent APIs」

資料の確認日：2026年9月15日。3構成図と承認・停止・再開の具体例は、資料を踏まえた設計上の提案です。画面操作とAPI制限の説明は、それぞれPower AutomateとMicrosoft Graphの仕様に基づきます。