エージェントは、いつ人の承認を求めるべきか

受注業務の説明用の例です。実際の顧客システムの導入事例ではありません。

通常の補充発注が100〜200個だとします。エージェントが500個を提案したら、発注する前に、その判断を人に確認してほしいと考えています。

数量を増やすことには、十分な理由があるかもしれません。需要が変わったのかもしれませんし、今後のイベントに備えて在庫が必要なのかもしれません。そこでエージェントには、入荷予定を確認し、仕入先のリードタイムを調べ、発注数量ごとの影響を比較してほしい。実際の発注には承認が必要でも、判断を準備する仕事は相当な範囲まで任せられます。

エージェントを自分たちの注文管理システムにつなぐことを考えると、この区別が、どこまでアクセスを与えるかを決める手がかりになります。まず責任の範囲を絞り、それを果たすために必要なツールと情報を渡したい。補充を任せるなら、対象となる事業部と在庫を明確にします。その範囲で調査する権限に、仕入先の登録情報を変更したり、別の事業部に割り当てられた在庫を使ったりする権限まで含めるつもりはありません。

通常の数量範囲は承認ルールを考える参考になりますが、150個の発注でも不要な場合があります。エージェントが提案をまとめている間に、仕入先からEDIで更新が届き、予定より早く入荷すると分かったとします。その在庫で必要量を満たせるようになるなら、提案も変わるはずです。調査を始めた時点の情報だけでは、もう発注を正当化できません。

だからこそ、注文を受け付けるシステムには、実行前に現在の在庫、発注済みで未入荷の注文、すでに確約した総量、そして依頼元の権限を確認させたいと考えています。こうした業務上の確認は、人からの依頼でも、EDI経由でも、エージェントからでも必要です。一つの大きな発注を小口に分けても、承認を回避できてはいけません。同じ業務に関わるアプリケーションが増えるほど、注文管理システムがそれらの判断の整合性を保つ必要があります。

こうした確認は通常のソフトウェアで行い、ツールの背後でも権限を制限するべきです。計算方法が決まっている補充数量の算出も、既存のワークフローで対応できるかもしれません。エージェントを使いたいのは、変わりつつある状況を読み解いたり、例外を調べたりすることが、人のより良い判断につながる場面です。

最初の段階では、人が仕事を近くで確認したいと考えています。テストと監督下での運用を通じて、エージェントが期待どおりに行動するか、例外に直面しても制御が機能するかを確かめます。情報が欠けている場合、在庫状況が変わる場合、権限を超える提案をする場合も対象にします。単純な注文を繰り返し正しく処理できたというだけでは、監督を減らす根拠として十分ではありません。

人に戻してくる判断も確認したい。不要な150個の発注に気づけるか。妥当な500個の提案を説明できるか。確認できなかったことを明らかにできるか。通常の注文にまで毎回承認を求めるエージェントでは、確認待ちの仕事がチームの一日を占めるという、別の問題が残ります。

頻繁に発生する業務が、合意した範囲内で安定して処理できると分かったら、通常の仕事は一件ずつ承認せずに進めたい。日に100回行うような業務なら、注文自体の適切さと併せて、不要な確認依頼の数や、人が例外の調査に費やす時間も見ます。仕事を委ねることで、人の判断が必要な決定を確保しながら、チームに時間を返したいのです。

記録、自動チェック、アラート、そして通常の処理から一部を抽出して確認することを含め、定期的なレビューは続けます。モデルやツール、業務の状況が変われば、再び監督を強める理由になります。影響が大きい行動、特に元に戻しにくい行動には、毎回の承認を残すでしょう。頻度の低い判断でも、人を関与させ続けることが、手間と管理のバランスとして妥当な場合があります。

一つひとつの承認依頼の質も重要です。私が在庫状況を組み立て直し、需要が変わったという情報の出所まで探す必要があるなら、調査の多くはまだ私の仕事です。エージェントには、関連する記録をそろえ、選択肢を説明し、不確かな点を見えるようにしてほしい。そうすれば、何をするかの判断に注意を向けられます。

エージェントが500個の発注を持ってきたら、何が変わったのか、すでに何を確約しているのか、200個にとどめるとどうなるのかを知りたい。最後は人が決めるとしても、その判断を準備することには価値があります。長い目で見れば、エージェントを評価する基準は、日常の仕事をどれだけ確実に処理できるか、そして私たちが担い続ける難しい判断をどれだけしやすくしてくれるかだと思います。

← 考察一覧に戻る