AIエージェントを使ってビジネスオペレーションを自動化する方法

誤解: より多くの自動化はより多くのワークフローを意味する

ワークフロー自動化に5年間取り組んできたオペレーションチームは、エージェントにも同じアプローチを取る傾向があります：プロセスをマッピングし、各ステップを特定し、エージェントにそのステップを実行させるように設定します。それは厳密に感じられます。しかし、それはワークフローと同じように脆弱なエージェントを生み出します。なぜなら、マップは依然として実行されるものだからであり、顧客が予期しないことをした瞬間にマップは間違ってしまうからです。

ワークフローはパスをエンコードします。エージェントは成果を追求し、持っているツールと見つけた状態からパスを選択します。サプライヤーが部分的な納品日で発注書に返信すると、ワークフローには誰かが構築したと思われる分岐が必要です。エージェントは返信を読み、期待される日付を更新し、関心のある人に伝え、続行します。違いは知性ではありません。エージェントにはパスではなく、成果と一連のツールが与えられたのです。

したがって、最初の方法の変更はプロセスマップから始めるのをやめることです。週の終わりに真実であってほしいことから始めてください。

タスクではなく、成果から始める

成果とは、確認可能なビジネスの状態についての文です。それは一連の記録、条件、時間を示します。タスクは活動を説明し、成果は結果を説明します。表は4つの一般的なオペレーションの違いを示しており、3列目はエージェントが各成果を追求するために許可される必要があることです。

結果文を書くのは見た目より難しく、1時間の価値があります。どのように確認するか言えない場合、それはまだ結果ではありません。「判断を使う」というフレーズが必要な場合、それは人が保持する部分を見つけたことになります。

エージェントにログインではなく、管理されたシステムを提供する

第二の方法の変更は、エージェントに渡すものに関するものです。誘惑は、既存のシステム内のユーザーアカウントと長いプロンプトです。それにより、すべてを見て、アカウントができることは何でも行い、個人とは異なる痕跡を残さないエージェントが得られます。代替案は、エージェントを特定の人物のために行動するクライアントとして扱うシステムであり、4つの特性があります。

• アクションはツールとして。 結果に必要な操作は、エージェントが発見し呼び出すことができる定義された型のアクションとして存在し、入力と結果を持ち、操作する画面ではありません。Model Context Protocolはこれに対するオープンスタンダードであり、互換性のあるエージェントはそれを通じて公開されたツールを使用できます。
• すべての呼び出しに対する権限。 エージェントに提供されるツールは、そのエージェントが行動する人物の役割によってフィルタリングされ、各呼び出しは実行時に再度確認されます。購入注文を承認できない人のエージェントは、承認することもできません。
• 予算。 システム自身のAIが推論を行う場合、支出は統合ごとに制限されるため、誤った結果が請求書を増やすことはありません。
• ログ。 すべての呼び出しは、その入力と結果がエージェントが行動した人物に帰属し、エージェントの週をレビューすることが同僚のレビューと同じ作業になります。

MCP仕様自体は、サーバーが入力を検証し、アクセス制御を実装する必要があり、クライアントはツール呼び出しを確認し拒否できる人物を保持すべきであると述べています。AnthropicとOpenAIの両方からの現在のガイダンスは同じ方向を指しています：接続されたサーバーが要求する権限を確認し、データを変更するツールの承認を維持し、信頼できるサーバーにのみ接続してください。管理されたシステムがそのアドバイスを実用的にし、無視すべき警告ではなくします。

6つのステップからなる方法

1. 結果を明示する確認可能な一文で、期限を設ける。予想される例外とその責任者を記載する。
2. 1週間手動で実行する今日その仕事をしている人が、何をしたか、なぜそれをしたかを書き留める。そのページがエージェントが従うポリシーとなり、通常は誰もが予想したよりも短い。
3. ツールの範囲を定める結果に必要なアクションのみをリストする。それをエージェントに与え、行動する人の権限の下で、他には何も与えない。
4. レビューを伴って引き渡すエージェントが結果を実行し、1週間すべてのアクションを人がレビューし、その後は例外のみを確認する。エージェントではなくポリシーを修正する。
5. 例外を測定する人が介入しなければならなかった回数と、その際の記録が結果からどれだけ離れていたかを数える。送信されたリマインダーは指標ではない。
6. 範囲を広げる最初の結果が1ヶ月間退屈であった場合、次の結果を追加する。同じガバナンスを再利用し、結果とツールリストのみを変更する。

順序が重要です。第二ステップをスキップしたチームは、プロンプトのポリシーを記憶から書くことになり、エージェントはその記憶のギャップを引き継ぎます。第三ステップをスキップしたチームは、エージェントに全システムを与え、その後レビュー期間中に心配することになります。

タスクではなく例外を測定する

ワークフローの自動化は、完了した実行、送信されたメール、更新された記録というタスクで測定されます。自動化が機能しているときも、間違っているときも、その数字は上がります。だからこそ、それらは安心感を与えますが、同時に無意味でもあります。結果を追求するエージェントは、人々に残す残余で測定されるべきです。

三つの数字がほとんどの業務をカバーします。人が関与しない結果の割合は上昇すべきです。週ごとの例外の数は減少し、ビジネスが実際に生み出すレベルで平坦に保たれるべきです。そして各例外の遅延：人がそれを見たとき、記録が結果からどれだけ離れていたかです。請求書が14日ではなく40日遅れて人に届く場合、遅れているのは人ではなくポリシーです。

ワークフローがまだ必要な場所

これらのいずれもワークフローの自動化を廃止するものではありません。判断がない高ボリュームの固定パスは、依然としてワークフローとして最も適切にエンコードされます：注文をファイルするウェブフック、夜間エクスポート、フォーム送信をルーティングするルールです。意思決定テーブルは、どのタイミングでどれを選ぶかを示し、第三行は一般的なケースです。

実例

上記の表からの在庫結果は、在庫、サプライヤー、購入注文、タスクがツールとして公開された1つのレコードであるSoisワークスペースに接続されたエージェントへの継続的なリクエストとして示されています。オペレーションリードは支出制限を設定し、各アイテムにサプライヤーを指定しました。

例外は出力です。オペレーションリードが見るのは2つの承認と1つの調達決定です。4つの定期的な注文は、あたかも人がそれを提起したかのように記録に存在し、月曜日のレビューがログとなります。Soisでは、接続されたエージェントはリードがすでに使用しているもので、OAuthで一度サインインし、その役割内で行動します。そして、そのエージェントが推論を行うとき、Soisはその代理でAIを実行せず、何も料金を請求しません。この方法はSoisに依存せず、エージェントが行動するシステムの4つの特性が真であることに依存します。

人々が尋ねる質問

この文書は、記載されている製品が変更される際にレビューされます。次回の予定レビュー： 2026年12月4日.