共有サービスをエージェンティックサービスへと変革する
皆さんの会社の経理業務チームが、毎日何十件もの請求書例外処理に追われている様子を想像してみてください。一件ごとに内容を開き、読み込み、発注書や入庫伝票と照合し、処理可能か、あるいは却下すべきかを判断しなければなりません。意思決定そのものよりも、3つの異なるシステムを横断してデータを探すことに、ほとんどの時間が費やされています。あるいは、人事サービスチームが、休暇申請やオンボーディング状況に関する同じような質問に繰り返し回答しているケース。答えは既にナレッジベースにあるにもかかわらずです。あるいは、ITサポートがパスワードリセットに追われ、より複雑なインシデントが長時間待たされている状況。
共有サービス（シェアードサービス）は、プロセスの標準化、ボリュームの集約、規模の経済による効率化という、理にかなった論理から生まれました。経理、人事、調達、IT、カスタマーオペレーションを一元化することで、トランザクションをより一貫して処理できるようにしたのです。このモデルは今も機能していますが、限界も見え始めています。ボリュームは増加し、例外処理のバリエーションは拡大し、ビジネスからの期待は単なる効率性から、スピードと成果の質へと移行しています。チケットは滞留し、引き継ぎ（ハンドオフ）は増加します。SLAは形式的には達成されていても、エクスペリエンスは依然として低いままです。多くのチームが、仕事を完了させることよりも、仕事を移動させることに忙殺されているのが実情です。
ここで、エージェンティックサービスが一つの回答として登場します。これは、サービスデスクの上にチャットボットを載せるようなものではなく、サービスを提供する方法そのものを変えるものです。もはや、主に人間の労働力に依存したデリバリーではありません。人間とエージェントからなるチームに基づくサービス提供なのです。このモデルでは、エージェントがリクエストを読み、コンテキストを理解し、システムを呼び出し、アクションを準備し、単純なケースは直接解決します。人間がいなくなるわけではありません。その役割は、例外処理、ポリシーの解釈、ステークホルダー管理、継続的改善へとシフトします。目標は単なるFTE（フルタイム換算人員）の削減ではありません。もしそれが主目的であれば、企業は往々にして脆い自動化を構築し、信頼を失うことになります。より適切な目標は、サービスモデルそのものを変革することです。
なぜ共有サービスが変革の出発点として適しているのか
すべての機能が、エージェンティックな変革の出発点として適しているわけではありません。共有サービスは、非常に戦略的な機能や、非常に非構造化された機能よりも、しばしば優れた候補となります。その理由は主に3つあります。
第一に、処理量が多く、作業パターンが反復的であること。共有サービスは、請求書例外処理、従業員からの問い合わせ、購買依頼、パスワードリセット、注文状況確認、紛争処理、オンボーディング業務など、大量の作業を扱います。処理量が多いことは、二つの利点を同時にもたらします。ケースのパターン、例外、その結果を理解するための十分な過去データが存在すること。そして、エージェンティックワークフローへの投資を経済的に成立させるのに十分な反復作業が存在することです。
第二に、プロセスが単純ではないものの、比較的標準化されていること。多くの共有サービスのプロセスは簡単な作業ではありませんが、リクエストを読み、意図を分類し、システムからデータを取得し、ポリシーを確認し、パスを決定し、アクションを準備し、解決またはエスカレーションするという、オーケストレーション可能なステップに分解できるほどには構造化されています。これは、社会的なコンテキストや人間の判断がはるかに支配的な、非常に戦略的または交渉色の強い仕事とは異なります。
第三に、運用データが豊富であること。共有サービスは通常、すでにERP、CRM、HRIS、ITSM、ナレッジベース、SOP、ワークフローエンジン上で稼働しています。エージェンティックサービスの基盤は実は既に存在しているのです。ただし、多くの場合、それらは分散しており、統合的に利用できる状態にはありません。経理共有サービスには、請求書、発注書、入庫伝票、ベンダーマスター、支払いポリシーのデータがあります。人事サービスには、HRIS、ナレッジ記事、ケース履歴、福利厚生ポリシーがあります。購買オペレーションには、申請フォーム、契約、ベンダーステータス、承認マトリクスがあります。ITサポートには、チケット、CMDB、ランブック、テレメトリがあります。カスタマーオペレーションには、CRM、注文履歴、権利ルール、インタラクションのトランスクリプトがあります。
しかし、重要なのは、共有サービスが変革の初期候補となるのは、自動化が容易だからではなく、再設計するのに十分な豊かさを持っているからだということです。もし企業が単に人員削減だけを追求するなら、最も狭く、最も安全なユースケースを選び、部分的な自動化で止まってしまう傾向があります。それは局所的な効率性をもたらすかもしれませんが、サービスモデルを変えるものではありません。
チケット管理から解決のオーケストレーションへ
エージェンティックな共有サービスにおける最も根本的な変化は、作業キューの管理から解決のオーケストレーションへの移行です。従来のモデルでは、サービスデスクはチケットを受け取り、リクエストの内容を読み、複数のシステムでデータを検索し、ポリシーを確認し、ケースを解決できるか、あるいは転送すべきかを判断します。多くの時間は、付加価値の高い意思決定ではなく、管理業務やコンテキストの検索に費やされています。
エージェンティックモデルでは、これらの初期ステップの大部分をエージェントに移行できます。十分に明確で、リスクが低～中程度のケースであれば、エージェントはメール、フォーム、チャット、チケットを読み取り、リクエストの種類を分類し、ナレッジベースやトランザクションシステムからコンテキストを取得し、ステータス、権利、ポリシーを確認し、下書きの応答やステータス更新などのアクションを準備し、特定の条件下では解決を実行することもできます。
ITサポートを例に挙げましょう。パスワードリセット、標準的なアプリケーションアクセス、一般的なインシデントの状況確認といったリクエストに対して、エージェントはリクエストを読み取り、本人確認とコンテキスト確認を行い、適切なツールを呼び出し、人間のアナリストを待たずにケースを解決できます。人事サービスでは、休暇、オンボーディング状況、ポリシードキュメントに関する質問に対して、エージェントはHRISとナレッジベースからデータを取得し、パーソナライズされた回答を提供できます。簡単な管理業務であれば、エージェントは許可された範囲内で準備または実行できます。購買オペレーションでは、標準的な購買依頼に対して、エージェントはニーズを分類し、アイテムがカタログにあるかどうか、承認済みベンダーかを確認し、購買依頼のドラフトを作成するか、依頼者を正しいルートに誘導できます。経理オペレーションでは、単純な請求書例外処理に対して、エージェントは請求書と発注書、入庫伝票を照合し、基本的な不一致を特定し、適切なルートに振り分けるか、解決策の推奨案を準備できます。
エージェントがルーティンワークを引き受ければ引き受けるほど、人間がより重要になる領域が明確になります。パターンに当てはまらない例外、ポリシー間の競合、センシティブなステークホルダーに関わるケース、ベンダーや顧客との交渉、重要な影響を及ぼす意思決定、そして継続的なプロセス改善は、引き続き人間の領域です。共有サービスチームの役割は変わります。彼らはもはや主にチケットを処理する存在ではなく、例外解決者、ポリシー解釈者、サービス品質管理者、そして運用上のフィードバックを通じたシステムのトレーナーとなります。
成熟した設計では、サービスデスクはもはや受信箱や人間の待ち行列と同義ではありません。それは、どのリクエストを自動解決し、どのリクエストに承認が必要か、どのリクエストを直接人間に回すべきか、そしてエージェントが失敗した場合のフォールバックをどのように行うかを調整する、オーケストレーション層となります。もし企業が、フローの設計を変えずに、古いサービスデスクの前にエージェントを追加するだけなら、結果は通常、チャットボットと古い滞留タスクの山だけです。変革の価値は小さなものになります。自律的な解決（Autonomous Resolution）は、パターンが十分に安定しており、データが利用可能で、ポリシーが比較的明確で、影響を限定できるケースに適しています。非常に曖昧だったり、感情的な要素が強かったり、追加の管理なしでは影響が大きすぎるケースには適していません。
運用管理のための新しいサービスカタログ
共有サービスが人間とエージェントのチームモデルに移行すると、運用管理はもはや従来のサービス定義に頼ることはできません。企業は、少なくとも3つのタイプのサービスを区別する新しいサービスカタログを必要とします。
第一に、人間によるサービス（Human-delivered Service）です。これは、判断、機密性、またはリスクの高さから、主に人間が実行し続けるサービスです。例としては、高額な顧客紛争、従業員の地位に影響を与える人事判断、重要な会計処理、リスクの高い本番環境の変更などが挙げられます。
第二に、エージェント支援サービス（Agent-assisted Service）です。エージェントはコンテキストの読み取り、ドラフトの準備、推奨事項の提示を支援しますが、主要な意思決定者は依然として人間です。例としては、決算期のコメンタリードラフト、調達ルートの推奨、顧客クレーム対応のドラフト、エンジニア向けのインシデントトリアージなどが挙げられます。
第三に、エージェント実行サービス（Agent-executed Service）です。エージェントは、明確に定義されたポリシーの範囲内でサービスを直接完了でき、必要に応じて人間へのフォールバックが行われます。例としては、パスワードリセット、注文状況照会、特定の管理データ更新、標準的な購買依頼のルーティング、曖昧さのないポリシーに関する問い合わせの解決などが挙げられます。
この区別は重要です。なぜなら、各カテゴリには異なる管理が必要だからです。各エージェンティックサービスには、応答時間だけでなく解決時間も含む、関連性の高いSLAが必要です。SLAは、単なる受付ではなく、成果を反映する必要があります。エスカレーションルールは明示的でなければなりません。エージェントがいつ停止すべきか、いつケースをスーパーバイザーに回すべきか、いつ承認が必須か。監査証跡により、企業はリクエストがどこから来たのか、どのようなコンテキストが使用されたのか、どのツールが呼び出されたのか、どのようなアクションが実行されたのか、そしていつ人間が引き継いだのかを確認できる必要があります。監査証跡がなければ、エージェンティックな共有サービスは、内部監査、コンプライアンス、プロセスオーナーに対して説明責任を果たすことが難しくなります。各サービスは、そのサービスモードに適したメトリクスを持つ必要もあります。エージェント実行サービスは、人間によるサービスと同じ方法で測定することはできません。
最も一般的な設計上の誤りの一つは、人間へのフォールバックを可能な限り避けるべきものと見なすことです。共有サービスにおいては、これはむしろ重要な管理手段です。フォールバックは、データが不十分な場合、ポリシーが競合する場合、信頼度が低い場合、リスクが高すぎる場合、またはユーザーがエージェントの結果を拒否した場合に必要となります。健全な設計とは、エージェントにすべてのケースを解決させることを強制するものではなく、いつ安全に停止すべきかを認識している設計です。フォールバックが適切に設計されていないと、二つのことが起こり得ます。エージェントが積極的になりすぎて高額なミスを犯すか、あるいはエージェントが保守的になりすぎてすべてのケースが結局人間に回され、ビジネス価値が失われるかです。運用管理は、エージェントが何を許可されているかだけでなく、どの程度の信頼を置くのが適切かという限界も規定する必要があります。
効率性から成果の質へ：価値の測定
エージェンティックな共有サービスは、しばしば生産性向上というストーリーで売り込まれます。それは間違いではありませんが、視野が狭すぎます。より重要な価値は、サービス品質の変化です。最も有用なメトリクスとしては、初回問い合わせ解決率（First-Contact Resolution）、つまり最初のインタラクションで解決されたケースの割合。タッチレス処理率（Touchless Processing Rate）、つまり人間の手を経ずに完了したケースの割合。サイクルタイム（Cycle Time）、つまりリクエスト受付から完了までの時間。例外滞留件数（Exception Backlog）、つまり困難なケースが滞留しているか減少しているか。そして、ケースあたりのコスト（Cost per Case）、つまり1件のケースを解決するための実際のコストです。これらのメトリクスは、エージェントが使われているかどうかだけでなく、サービスモデルが本当に変わったかどうかを理解するのに役立ちます。
品質を伴わない効率性は、信頼を損なうことになります。そのため、エージェンティックな共有サービスは、エラー率、コンプライアンス上の指摘事項、ユーザー満足度、そしてトラストスコア（エージェントの結果に対するユーザーの信頼を示す指標）でも測定されるべきです。トラストスコアは複雑である必要はありません。受入率、オーバーライド率、またはエージェントの推奨に対するユーザーフィードバックから始めることができます。重要なのは、企業が単に何が自動化されたかだけでなく、人々がそれを信頼しているか、そして結果が正しいかどうかを測定することです。
設計例：エージェンティックな経理共有サービス
経理共有サービスは、プロセスが十分に構造化され、処理量が多く、かつ明確な判断領域を持つという点で良い例です。ある組織が、買掛金管理と決算支援から始めることを想像してみてください。
エージェント支援サービスとなり得るものには、請求書例外の分類、ERPからの証憑収集、差異説明のドラフト作成、レビューア向けの滞留案件サマリー作成などがあります。ここでは、人間が最終的なアクションを決定しますが、データ検索や説明文作成に費やす時間は大幅に削減されます。
エージェント実行サービスとなり得るものには、請求書や支払いのステータス照会への回答、ベンダーからの問い合わせを適切なルートに振り分ける処理、非常に明確なルールに基づく低リスクケースの処理、ケースの自動作成や更新などがあります。
人間によるサービスとして残るものには、重要な会計処理の判断、不正の疑いがある例外処理、交渉を要するベンダーとの紛争、高額な支払いの承認などがあります。
必要となる管理手段には、3つのサービスモードを区別するサービスカタログ、サービス種類ごとのSLA、金額とリスク階層のしきい値、すべてのツール呼び出しと推奨に対する監査証跡、買掛金アナリストやコントローラーへのフォールバック、そしてオーバーライドと修正パターンに関する週次レビューが含まれます。
関連するメトリクスには、ベンダー問い合わせのタッチレス率、請求書例外のサイクルタイム、ステータス問い合わせの初回問い合わせ解決率、ドラフトコメンタリーの修正率、人間の対応を待つ例外の滞留件数、そして実装後に発生したコンプライアンス問題などが含まれます。
このような設計例は、エージェンティックな経理共有サービスが、人間不在の経理を意味するわけではないことを示しています。変わるのは、誰が何を担当するのか、いつ人間が介入するのか、そしてサービスがどのように測定されるのか、ということです。
変革に適さない共有サービスの兆候
すべての共有サービスが、すぐに規模を拡大できる準備ができているわけではありません。いくつかの危険信号に注意する必要があります。基本的なプロセス自体がまだ安定していない、または文書化されていない。ナレッジベースが古いドキュメントや矛盾したポリシーで溢れている。ERP、CRM、HRIS、ITSMへの統合がまだ脆弱である。オペレーション、IT、リスクの間に明確なサービスオーナーがいない。サービスのメトリクスが、成果ではなくチケットボリュームにのみ基づいている。例外率が非常に高く、その原因が理解されていない。組織が依然としてエージェントを単なる省力化ツールと見なしている。
このような状況では、エージェンティックな変革は、古い混乱の上に新しい層を追加するだけのリスクを負います。結果は通常、一見高度に見えるが、信頼性が低く、スケールが難しい自動化となります。
今すぐ下すべき決断
このテーマを理解した上で、いくつかの決断を下すことが推奨されます。第一に、最も実行可能な初期の共有サービス領域を選択すること。処理量が多く、パターンが比較的標準的で、運用データが利用可能であり、明確なプロセスオーナーがいる領域を優先します。第二に、ユースケースごとにサービスモード（人間による、エージェント支援、エージェント実行）を明示的に決定すること。第三に、フォールバックとエスカレーションを初期段階から設計すること。エージェントが本番環境で失敗してから、いつ人間が引き継ぐべきかを考え始めるのでは遅すぎます。第四に、サービスカタログとサービスのメトリクスを変更すること。エージェンティックな共有サービスは、チケットと人員数にのみ焦点を当てた従来のサービス定義では管理できません。第五に、部門横断的なガバナンスを確立すること。COO、CIO、プロセスオーナー、リスク管理部門、人事部門が、これは単なるツールプロジェクトではなく、オペレーティングモデルの再設計であるという点で合意する必要があります。
経営層への問いかけは、次の通りです。自社の共有サービスは、依然として人間ベースのチケット処理マシンとして設計されていますか？それとも、新しい管理、メトリクス、説明責任のもとで人間とエージェントのチームによって実行される、成果ベースのサービスポートフォリオとして考え始めていますか？この問いへの答えが、エージェンティックAIが単なる効率化のレイヤーに留まるのか、それとも企業が内部サービスとオペレーションを提供する方法を真に変革するのかを決定づけるでしょう。