エージェンティック・オペレーティングモデルとは
ある財務チームが、月次決算のプロセスを支援するためにエージェントの導入を始めたと想像してみてほしい。エージェントはERPからデータを取得し、請求書の照合を行い、仕訳案を作成し、例外事項をフォローアップする。一方、カスタマーオペレーションチームもエージェントを導入し、顧客からの問い合わせ対応、住所変更、注文状況の確認などを担っている。さらにITチームは、インシデントの初期診断を行うエージェントを開発している。
それぞれが順調に機能しているように見える。しかし、ここで厄介な疑問が浮上する。もしエージェントが請求書を誤って分類した場合、実際に責任を負うのは誰なのか？エージェントがどこまで自律的に行動してよいのか、誰が判断するのか？エージェントはいつ人間に確認を取るべきなのか？そして、エージェントが本当に業務に貢献しているのか、それともリスクを増大させているのか、企業はどうやって判断すればよいのか？
これらの問いに、技術アーキテクチャは答えを出せない。アーキテクチャは確かに重要だ。システムがどのように構築され、エージェントがどのようにコンテキストを取得し、ツールを呼び出すのかという問いには答えてくれる。しかし、エージェントが実際に稼働し始めると、企業にはそれ以上のもの、すなわち、ソフトウェアが単なる支援ツールではなく、業務そのものを実行する主体となった場合の企業運営の方法が必要となる。
ここで、エージェンティック・オペレーティングモデルという概念が重要性を帯びてくる。
揺らぎ始めた従来の前提
長年にわたり、企業のオペレーティングモデルは単純な前提の上に構築されてきた。すなわち、人間が業務の主要な実行者であるという前提だ。ソフトウェアは、ERPへの取引記録、CRMでの顧客インタラクション管理、ワークフローによる承認プロセス誘導、ダッシュボードでのデータ表示といった形で、人間を支援するために存在してきた。しかし、最終的に業務を開始し、評価し、決定し、完了させるのは人間だった。
エージェンティックAIは、この前提を変え始めている。
今やソフトウェアは、単に人間の作業を効率化するだけではない。複数のステップからなるタスクを実行し、システム間の作業を調整し、初期段階の例外処理を行い、リスクの低いアクションを自律的に判断し、確信度が低い場合やポリシーで要求される場合にのみ人間にエスカレーションするようになった。この変化は、個々のユースケースで見れば小さく映るかもしれない。しかし、エージェントが複数の機能で同時に使われ始めると、従来のオペレーティングモデルの脆さが露呈する。
第一の問題は、場当たり的に自動化が進むことだ。ある部門がカスタマーサービス用のエージェンティックツールを購入する。別の部門は財務用のエージェントを構築する。ITチームはインシデントトリアージ用のエージェントを作る。それぞれは生産的に見えるが、エージェントの所有権、承認プロセス、成果の評価方法に関する共通のモデルは存在しない。その結果生まれるのは、新しいオペレーティングモデルではなく、制御不能に拡大する自動化の寄せ集めである。
第二の問題は、説明責任の所在が不明確になることだ。エージェントが請求書を誤って分類した場合、誰が責任を負うのか？データサイエンスチームか？買掛金プロセスのオーナーか？プラットフォームベンダーか？明確な定義がなければ、インシデントが発生するたびに部門間の議論に発展する。
第三の問題は、規模の拡大がリスクを増幅させることだ。小規模なパイロットは、プロジェクトチームが厳重に監視するため、安全に見えることが多い。しかし、エージェントが複数の部門や国をまたいで使用されるようになると、オペレーティングモデルの弱点がすぐに顕在化する。承認プロセスが統一されておらず、リスクのしきい値が異なり、成功指標もバラバラだからだ。
したがって、エージェンティックAIは単なる技術プロジェクトとして管理できるものではない。それは新たな実行レイヤーであり、新たな運用規律を必要とする。
初期段階で定義すべき6つの要素
健全なエージェンティック・オペレーティングモデルは、必ずしも複雑である必要はないが、明確に定義されていなければならない。少なくとも、初期段階で定義すべき6つの要素がある。
1. 明確な権限の境界
各エージェントは、承認なしに実行してよいアクション、人間の承認が必要なアクション、そして推奨のみに留めるべきアクションを正確に把握していなければならない。これは単に「エージェントは調達プロセスを支援する」と言うことではない。必要なのは、運用可能な定義である。
例えば調達において、エージェントは依頼内容を分類し、購買ルートを提案することはできる。ベンダーオンボーディングの完了確認も可能だ。ポリシーの許容範囲内であれば、単純な請求書不一致の処理も行える。しかし、リスクの高い新規サプライヤーの承認や、承認なしでのベンダーマスターの変更は許可されない。
IT運用において、エージェントは初期診断や、Runbookに従ったリスクの低い是正措置を実行できる。しかし、広範囲に影響を及ぼす本番環境の設定変更は、インシデントマネージャーの承認なしには行えない。
明確な権限の境界がなければ、エージェントは過度に制限されて価値を生み出せないか、自由すぎて安全ではなくなるかのどちらかである。
2. エージェントごとの3つのオーナー
エージェンティック・オペレーティングモデルにおける最も重要な原則の一つは、すべてのエージェントに3つのオーナーが存在しなければならないということである。
第一に、ビジネスオーナーである。通常はプロセスの成果に対して責任を持つ者だ。エージェントのビジネス目標、SLA、ユースケースの優先順位、そしてスピード、品質、ユーザーエクスペリエンスの間のトレードオフを決定する。例えば、請求書例外処理エージェントであれば買掛金責任者、決算オーケストレーションエージェントであればコントローラーが該当する。
第二に、テクニカルオーナーである。統合、信頼性、可観測性、そしてエージェントの技術的なライフサイクル管理に責任を持つ。これはプラットフォームチームかAIエンジニアリングチームに属することが多い。
第三に、リスクオーナーである。ガードレール、承認のしきい値、コンプライアンス管理、そして停止条件を決定する。領域によっては、コンプライアンス、内部統制、または法務部門からリスクオーナーが選ばれる。
これら3つのオーナーシップがなければ、エージェントは共同所有のように見えて、実際には誰のものでもない状態になる。
3. 明確なエスカレーション経路
成熟したオペレーティングモデルは、最大限の自律性を追求するものではない。適切な自律性を追求するものである。そのため、各エージェントは明確なエスカレーションパス、すなわち、いつ人間に判断を委ねるべきかを定義しておく必要がある。
これは、確信度が低い場合、データが不完全な場合、ポリシーに矛盾がある場合、通常のパターンから外れた例外が発生した場合、取引額がしきい値を超えた場合、または評判への影響が大きすぎる場合などに発生する。
カスタマーオペレーションでは、エージェントは住所変更リクエストを自律的に処理できるが、高額な返金や紛争に発展する可能性のあるケースはエスカレーションしなければならない。Record-to-Reportプロセスでは、エージェントは仕訳案を作成できるが、重要な仕訳や機密性の高い勘定科目についてはエスカレーションが必要となる。
適切なエスカレーションパスとは、単に「人間に投げる」ことではない。誰が、どのSLAで、どのようなコンテキストとともに受け取るのかを定義し、人間がゼロから作業をやり直す必要がないようにしなければならない。
4. 3つの運用モード
企業は、シンプルかつ明確な3つの運用モードを設定する必要がある。
第一のモードは推奨のみである。エージェントは分析、要約、アクションの提案を行うが、実行は人間が行う。新しい領域、リスクの高い領域、あるいはデータや管理体制が十分に整っていない領域に適している。
第二のモードは**人間参加型（Human-in-the-loop）**である。エージェントはアクションの準備や一部のステップの実行を行うが、最終的な決定には人間の承認が必要となる。これは、財務、調達、人事、カスタマーオペレーションの初期導入において、最も現実的なモードであることが多い。
第三のモードは制限付き自律性である。エージェントは、明確に定義された範囲内で、ガードレール、ログ記録、フォールバック手順を備えた上で、自律的に行動することが許可される。チケットのトリアージやリスクの低いIT是正措置など、ルールが比較的明確で大量に発生する業務に適している。
重要なのは、これらのモードを技術チームだけで決定してはならないということだ。ビジネス、リスク、オペレーション部門の合意を得る必要がある。
5. アクティビティではなくアウトカムを測定する
従来のオペレーティングモデルは、処理チケット数、FTE数、スーパーバイザーあたりのバックログなど、人間のアクティビティとキャパシティに焦点を当てすぎる傾向があった。エージェンティックモデルでは、焦点はワークシステムのアウトカムに移行しなければならない。
より適切な指標としては、サイクルタイム、例外発生率、自動化率、トランザクションあたりのコスト、意思決定の質、手戻り率、SLA達成率などが挙げられる。財務決算において、重要な問いは、何人のアナリストが残業しているかではなく、決算がより迅速に行われているか、例外がより早く解決されているか、内部監査人が統制の証跡をより信頼しているかである。
6. 人間の役割の再設計
これは最も軽視されがちな要素である。エージェンティック・オペレーティングモデルは、単に既存のチームにエージェントを追加するだけではない。それは仕事の設計そのものを変える。
多くのプロセスにおいて、人間の役割は、取引の実行、データの転記、フォローアップの追跡から、例外処理、意思決定の品質監視、ワークフローの改善、ポリシーの管理、運用フィードバックによるシステムのトレーニングへとシフトする。
買掛金業務では、チームはもはや標準的な請求書を一つ一つチェックすることにほとんどの時間を費やさなくなる。焦点は、複雑な例外、ベンダーとの紛争、ポリシーの調整に移る。シェアードサービスセンターでは、最前線のケースプロセッサーの役割は減少する一方で、プロセスコントローラー、ナレッジキュレーター、エージェントスーパーバイザーといった役割の需要が高まる。
企業は、より高いキャパシティとスピードを得ることができるが、それは人間の役割、スキル、チーム構造を積極的に再設計する場合に限られる。そうしなければ、エージェントは単に古い組織の上に積み上げられるだけになる。
ロールベースからアウトカムベースへ
エージェンティック・オペレーティングモデルがもたらす最大の影響の一つは、ロール（役割）ベースの管理からアウトカム（成果）ベースの管理への移行である。
従来のモデルでは、組織は業務を組織図の枠組みで管理する傾向があった。すなわち、誰が何を行い、各チームに何人所属し、役割間の引き継ぎがどのように行われるか、といった具合だ。このアプローチは、人間が主要な実行者である場合には理にかなっている。しかし、エージェントも実行に加わるようになると、より重要な分析単位は役割ではなく、エンドツーエンドのアウトカムとなる。
エージェントは、人間の組織における職務の境界を気にしない。CRMからデータを取得し、ナレッジベースでポリシーを確認し、ITSMにチケットを作成し、ERPを更新するという一連の流れを、一貫して実行できる。したがって、企業は次のような問いを立て始める必要がある。達成したいアウトカムは何か、どのステップに本当に人間が必要か、どの判断ポイントを保護すべきか、そしてどの部分をデジタルレイバーに任せるべきか。
例えば、Lead-to-Cashプロセスでは、セールスオペレーション、オーダーマネジメント、請求、債権管理をそれぞれ個別に最適化するのではなく、「注文が有効で、迅速に回収可能である」というアウトカムを目指して、注文の妥当性確認、契約内容のチェック、初期の債権フォローアップをエージェントがオーケストレーションするように設計し直すことができる。
すべての領域が、すぐにアウトカムベースで管理できるわけではない。プロセスが依然として混沌としており、データが標準化されておらず、エンドツーエンドのオーナーシップが確立されていない場合、このモデルを無理に適用すると、かえって混乱を招く可能性がある。より現実的な初期ステップは、プロセスを安定化させ、オーナーシップを明確にし、基本指標を設定した上で、エージェントを段階的に導入することである。
誰が主導すべきか
企業がエージェントを業務実行の一部として真剣に位置づけるようになれば、その管理体制も変わらなければならない。
企業は通常、ビジネス、テクノロジー、リスク、セキュリティ、法務、人事が関与する部門横断的なガバナンスフォーラムを必要とする。その目的は官僚主義を増やすことではなく、重要な決定が個別に行われるのを防ぐことである。このフォーラムでは、ユースケースの優先順位、領域ごとの自律性のレベル、最低限の管理基準、パフォーマンス指標、インシデント、そして労働力への影響について議論する。
トランスフォーメーションオフィスやAIオフィスは、エージェンティックユースケースを、パイロットの寄せ集めとしてではなく、運用プロダクトのポートフォリオとして管理する必要がある。つまり、ロードマップが存在し、長期的なオーナーが存在し、目標とするアウトカムが存在し、ユースケースをいつ停止または拡大するかについて明確な判断基準が存在する。
最も重要なことは、エージェンティック・オペレーティングモデルは技術部門だけの課題ではないということだ。COOは、変化の中心がプロセス設計と運用経済にあるため、関与する必要がある。CHROは、職務設計、スキル、パフォーマンス管理に直接的な影響があるため、関与する必要がある。CFOやリスク責任者も、エージェントが統制、監査可能性、説明責任に影響を与えるため、積極的に関与する必要がある。
企業の準備ができていない兆候
すべての組織がエージェンティック・オペレーティングモデルを拡大できるわけではない。よく見られる危険信号としては、各部門が独自の基準でエージェントを構築している、本番稼働中のエージェントの正式なリストが存在しない、ビジネスオーナーが不明確である、承認のしきい値がリスクポリシーに基づかずにバラバラである、オペレーションチームがエージェントの行動を把握していない、成功指標が単なるツール導入率である、人事部門が役割の変化について見解を持っていない、エージェントに関連するインシデントが正式なガバナンスメカニズムに報告されない、などがある。
これらの症状のいくつかがすでに見られる場合、優先すべきは新しいユースケースを追加することではなく、まず運用規律を強化することである。
エージェンティック・オペレーティングモデルは、最終的にはAIをよりアクティブにすることではない。それは、ソフトウェアが業務に参加し始めたときに、誰が決定し、誰が責任を負い、リスクがどのように管理され、人間とエージェントがどのように協力してアウトカムを生み出すのかを、企業が確実に把握できるようにすることである。これこそが、印象的なデモと、真にスケーラブルな変革とを区別するものである。