先に自動化する単位を決める

「受注を自動化する」には、メールを読んで品目と数量を把握し、商品コードに対応づけ、契約単価を調べて注文を登録する仕事が含まれます。抽出の誤りなら担当者が直せます。登録後に発覚すると、物流や取引先への訂正が必要になります。同じ誤りでも、発見した工程によって影響が変わります。

一件の仕事について、入力、承認済みの判断基準、結果が残るシステムを図にします。フォームやAPIで入力を受けられるかを確認し、構造化された値がすでにある場合は、そのまま利用する費用と検証方法を比較します。メールを使い続ける場合は本文の記載と顧客管理システムの確定値を分けます。メールの送信者と注文権限を持つ人の同一性は、CRMの顧客識別子とイベントデータで扱うデータの整合性にも関わります。

Google PAIRのユーザーニーズと成功条件[1]は、利用者への価値をもとに自動化と人の支援を比較しています。デモの印象より先に、一件の仕事がどの状態で終わるかを決めます。受注の場合は、注文番号が発行され、取引先、品目、数量、単価が基準と一致することが条件になり得ます。下書きが入力時間を減らしても、完了件数は基幹システムで別に確認します。

入力と処理経路に合う方式を選ぶ

表は工程ごとに一行ずつ当てはめます。最終列を埋められない場合は、結果を判定する基準を先に業務担当者が決めます。

業務の条件最初に比較する方式適用例運用で確認する証拠
承認済みの条件と計算式があり、入力が定型ルールによる自動化契約単価、数量、適用日時で受注額を計算基準の版、境界値の期待結果、金額の照合
システム間に正式な連携手段があるAPI連携商品・在庫を照会し、承認済み注文を登録認証・対象への権限、応答消失後の照会、注文の一意性
APIがなく画面操作が安定しているRPAなどの画面自動化レガシー画面で業務コードや許可済みファイルを取得画面変更の検知、作業用アカウント、台帳との照合
書式の異なる文から抽出・分類するAIによる抽出・分類と固定の処理経路メールの品目・数量・配送依頼を分ける候補値と原文、欠落時の保留、修正履歴
中間結果によって次の調査やツールが異なる動作範囲を限定したエージェント廃番部品の代替品を許可済みの資料から探すツールと業務範囲、手順・時間の上限、根拠、停止と引き継ぎ
方針が競合する、または業務責任者の裁量が必要人による判断と確認支援例外割引や納期確約の判断適用根拠、承認者、顧客への案内、実行結果

APIはシステムが定められた方法で情報をやり取りする接点です。参照用と変更用を分け、業務に必要な権限を割り当てます。調査で全取引先の単価を参照できると、関係のない契約情報が入り込むことがあります。調査結果を外部へ送る場合も、別の書き込み処理として扱います。

RPAは画面上の決まった手順を実行します。APIのない長期運用システムで手順が安定している場合に候補となります。予期しないダイアログ、認証切れ、ボタンや入力規則の変更では停止して担当者に渡せるようにします。可能なら注文番号や台帳の状態を照合し、確認手段が限られる場合は実行範囲と許容する損失を絞ります。

Anthropicの資料は、コードで定めた経路を通るワークフローと、次の処理を選ぶエージェントを区別し、十分に機能する簡単な方式から始めるとしています。メールの書式がさまざまでも、受領、検証、承認、登録の順で固定できる場合は、抽出と固定フローを試せます。調査順が途中の結果に依存し、有効な経路の列挙が難しい場合はエージェントの実験を検討できます。 Anthropic — Building effective agents[2]

サービスの仕組み

キャンペーンに必要なデータから接続 — 施策から逆算してイベントと属性を定義し、識別子、送信時点、測定ツールの役割を整えます。

架空の注文をメールから登録までたどる

架空の部品商社に「いつもの小型ブラケットを3箱、前回と同じ条件で」というメールが届きます。取引先ごとに品目の呼称、箱の入り数、契約単価の適用日が異なります。転送文に過去の注文が含まれたり、別のメールが訂正依頼だったりします。モデルは「小型ブラケット」「3箱」を抽出し、「いつもの」「前回」を要確認と表示します。現在の注文と引用部分の出典が分かれていると、担当者は候補値を確認できます。

商品コードと取引先の対応は管理されたマスターデータから取得します。候補が複数なら違いを表示します。名前の似た規格違いや、推定で換算した包装単位は、文章だけでは発見しにくい誤りです。担当者が選ぶ項目と、システムが確定できる項目を決めます。

工程この例で扱う情報不一致時の処置
解釈メールの品目、数量、納期の記載値がない、または引用部分と混在すれば保留
対応づけ契約で指定された商品コードと包装単位を照会複数候補は担当者が選択
計算契約単価、承認数量、値引きで金額を計算適用日、単位、値引きが不明なら承認キューへ
実行承認済み項目と作業IDを権限確認済みの登録APIに渡す同じ依頼は結果を照会し、内容の変更は訂正として扱う
完了注文番号と保存済みの品目、数量、金額を比較応答が途切れた場合は再登録前に結果を照会

メールのメッセージIDだけでは、別のメールで送られた同じ発注を見落とします。取引先の発注番号、受付ID、訂正の回数など、業務上の識別子を選びます。同じ作業IDで内容が変わった場合の扱いを決め、冪等キーを使う場合は適用範囲と有効期間を確認します。キーがない場合や応答を受け取れない場合には、照会や担当者による突合の経路が必要です。 AWS Builders’ Library — Making retries safe with idempotent APIs[3]

承認は担当者が見た品目、数量、単価、配送情報の版に結びつけます。承認後に数量が変われば、新たな承認に回します。登録直前に契約単価が変わる場合や、注文者の権限が失効する場合もテストします。実行時にAPIが条件を再確認できるようにします。

同じ業務を別の方式で試す

取引先の入力項目を統一できる場合は、必須項目のある注文フォームとAPIが候補です。入力時に欠落を見つけられます。メールを維持する取引先にはAIで下書きを作れます。外部APIのないシステムでRPAを試すなら、先に画面参照から始めます。登録を広げる場合は保存の前後を確認できるようにします。

代替品の調査では、廃番の確認後に仕様書の検索、互換条件の照合、候補の提示が順不同になることがあります。参照資料とツールを絞り、根拠の資料・段落を残します。実際の注文に変更する際は既定の承認に従い、業務システムが実行権限を発行します。 OWASP — AI Agent Security Cheat Sheet[4]

導入会議で使う七つの質問

  1. 一件の完了はどの状態ですか。 下書き、承認、基幹システムでの確定のうち、必要な最終証拠を決めます。
  2. 入力を簡素化できますか。 フォーム、マスターデータ、公式インターフェースと、相手側が変更できる条件を比較します。
  3. 順序が変わるのか、入力だけが異なるのか。 順序が固定なら抽出や分類だけにAIを使えます。担当者が説明できる分岐はルールで表現します。
  4. 単価、権限、顧客状態の情報源は誰が管理していますか。 メールと台帳の値が違う場合の優先順位と確認先を決めます。
  5. 参照ですか、状態変更ですか。 実行者、範囲、承認値と実行値、失敗時の照合方法を記載します。
  6. エラーや結果不明はどこへ送りますか。 キュー、引き受ける人、期限、復旧・補正、顧客案内を決めます。
  7. 何を測って現在の方式と比較しますか。 処理時間に加え、承認待ち、手戻り、手動切り替え、保守、教育を確認します。

回答のない箇所は、拡大前にそろえるべき業務上の証拠です。取引先の別名をいつも担当者が直すなら、その対応表の管理から試します。基準があって照合しづらいときは環境と検証データを用意します。テスト自動化のポートフォリオの頻度、影響、期待結果、環境の再現性が検証の準備度を見極める助けになります。

小さな実験で確認の負担も測る

注文を書き込まない範囲で、本番に近い画面と承認済みのデータを使います。通常、単位不明、契約対象外、欠落、訂正について、業務責任者が期待結果を先に記載します。モデルと作業アカウントに渡る項目を確認し、現行方式と同じ業務で人の作業時間や失敗時の手戻りを測ります。NIST AI 600-1[5]では導入前の検証とリスクの追跡を扱っています。

仮に100件の受付に対して70件の下書きができ、60件が修正なしで移行した場合、下書き生成率は70%です。修正なしは全受付の60%で、下書きに限れば約85.7%です。確認時間と、修正10件・未生成30件の計40件の負担を含めます。呼び出しの成功件数だけでは二重の確認作業を把握できません。

短縮時間が支出の減少に結びつくかは配置や契約によります。繁忙時の滞留が減ったなら期限や残業を確認します。RPAでは画面変更とアカウント管理、AIでは分類ルールや評価の更新も含めます。新しい承認待ちと交代時の引き継ぎも運用コストです。

検出し対処できる失敗を確認してから範囲を広げます。数量と品目の候補から始め、次に権限を持つ担当者の承認で定型注文を保存します。対象取引先と品目を絞り、障害通知と手動への切り替えを試します。範囲外での登録や原因の分からない失敗があれば、先に処理経路を確認します。