メインコンテンツまでスキップ

Agentic Enterprise: デジタルトランスフォーメーションからエージェンティック・トランスフォーメーションへ

図解:Agentic Enterprise:デジタルトランスフォーメーションからエージェンティック・トランスフォーメーションへ

現在、多くの企業はデジタルトランスフォーメーションにおいて既に十分に進んでいるという自負を持っています。主要なプロセスはERP上で稼働し、承認はデジタルワークフローで行われ、ダッシュボードはリアルタイムデータを表示し、大多数の従業員は既にコパイロットやチャットボットを活用して、文書作成、要約、インサイトの探索を行っています。しかし、大規模組織の内部をより深く見てみると、本当の意味で変わっていないものがあることに気づきます。仕事は依然として、ある受信箱から別の受信箱へ、あるチームから別のチームへ、あるアプリケーションから別のアプリケーションへと移動しています。ボトルネックは依然として存在しており、その見た目がより現代的になったに過ぎません。

ここで浮かび上がる疑問は、これまで進められてきたデジタルトランスフォーメーションは、本当に企業の働き方を変えたのか、それとも単に手作業をデジタル画面上に移し替えただけなのか、ということです。そして、もし答えが後者であるならば、実際に変えるべきものは何なのでしょうか。

デジタル化が表面で止まっているとき

過去20年にわたり、大企業はデジタル化に巨額の投資を行ってきました。彼らはプロセスをERPで標準化し、顧客とのやり取りをCRMに移行し、シェアードサービスを構築し、クラウドを採用し、ワークフローエンジンやRPAによって業務の一部を自動化してきました。その成果は明らかです。可視性が向上し、コンプライアンスが改善され、多くの領域で取引コストが削減されました。

しかし、そこには明確になりつつある限界があります。多くのトランスフォーメーションプログラムは、基本的に手作業をデジタル画面上に移し替えただけのものです。紙のフォームはオンラインフォームに変わりました。物理的な承認は電子承認に変わりました。かつてスプレッドシートで行われていた照合作業は、現在ではダッシュボードと例外キューによって行われています。これらは確かに進歩ですが、多くの場合、ハンドオフを排除するわけでも、意思決定権限を簡素化するわけでも、誰が何をすべきかを変えるわけでもありません。

例として、調達から支払いまでのプロセス(source-to-pay)を考えてみましょう。ある企業は、すでに電子調達システム、ベンダーポータル、自動スリーマッチを導入しているかもしれません。しかし、価格不一致、発注書の不完全さ、ベンダーマスタの問題、または購買カテゴリの曖昧さといった例外が発生すると、業務は依然として依頼者、購買担当者、買掛金担当者、ベンダーサポートの間を行き来します。デジタルシステムは記録と追跡を支援しますが、部門横断的な問題解決をインテリジェントにオーケストレーションするには至っていません。

同様のことは、記録から報告までのプロセス(record-to-report)でも発生しています。多くの組織は、すでにグローバルなERPと規律ある決算カレンダーを有しています。しかし、決算が進行する中で、財務チームは依然として証拠を追跡し、仕訳の異常をフォローアップし、事業部門に確認を求め、監査人向けの説明をまとめる必要があります。プロセスはデジタル化されていますが、その実行は依然として人間の調整に大きく依存しています。

問題は、使用されているテクノロジーにあるわけではありません。ERP、CRM、HRIS、その他のエンタープライズプラットフォームは、現代の業務運営の根幹です。しかし、歴史的にこれらのプラットフォームは、標準化、管理、取引効率のために設計されてきました。これらは、安定したプロセスと明確なルールに対して非常に強力です。一方で、曖昧なコンテキスト、動的な例外、またはシステムや機能を横断するマルチステップの調整を扱う必要がある場合には、必ずしも優れているとは限りません。

このような制約のため、多くの企業はBPM、RPA、統合ミドルウェア、データレイク、ワークフローツール、ナレッジベース、そして最近ではGenAIアシスタントといった、さらなるレイヤーを追加しています。その結果、しばしばますます複雑化するランドスケープが生まれます。各ツールは問題の一部を解決しますが、バリューストリーム全体は断片化されたままです。

初期のGenAI:個人を支援するが、企業を変えるには至らない

ジェネレーティブAIの登場は、個人レベルでの生産性の飛躍的な向上をもたらしました。従業員は、より迅速にメールを作成し、契約書を要約し、プレゼンテーションのドラフトを作成し、ドキュメントから回答を検索し、初期分析を生成できるようになりました。これは、特にナレッジワークにおいて有用です。

しかし、多くの企業では、GenAIの導入は個人支援のレベルで止まっています。AIは個人がより速く作業するのを助けますが、エンドツーエンドのワークフローを自動的に変えるわけではありません。調達アナリストはベンダーサマリーをより速く作成できるかもしれません。カスタマーサービス担当者はより速く応答文を作成できるかもしれません。開発者はより速くコードを書けるかもしれません。しかし、ビジネスプロセス全体としては、人間が開始し、調整し、決定し、ループを閉じることに依然として依存しています。

言い換えれば、従来のデジタルトランスフォーメーションと初期のGenAIは、しばしば効率の向上(efficiency uplift)をもたらしますが、必ずしもオペレーティングモデルの変革(operating model shift)をもたらすわけではありません。企業は表面上はより効率的になりますが、基本的な仕事のロジックは変わりません。

エージェンティックAIによって実際に変わること

エージェンティックAIによる大きな変化は、質問に答える能力にあるのではありません。その大きな変化は、システムが目標を追求し、ステップを計画し、ツールを使用し、コンテキストを管理し、ある程度の自律性を持ってマルチステップのワークフローを実行する能力にあります。これにより、AIは補助ツールから実行レイヤーへとシフトします。

この違いを理解するために、アシスタント(assistant)と実行役(executor)という役割を想像してみてください。アシスタントは人間がタスクを遂行するのを支援します。エージェントは成果(outcome)に向けて仕事を実行します。アシスタントモデルでは、人間が実行の中心であり続けます。人間がタスクを分解し、アプリケーションを選択し、コンテキストを移動させ、次のステップを決定します。エージェンティックモデルでは、その作業の一部が、目標を理解し、計画を立案し、ツールやAPIを呼び出し、複数のシステムからデータを取得し、単純な例外を処理し、必要に応じて人間の承認を求め、成果が達成されるまでプロセスを継続できるシステムに移行します。

カスタマーオペレーションにおける簡単な例を挙げます。従来のチャットボットは顧客の質問に答えます。エージェンティックシステムは、答えるだけでなく、本人確認、注文ステータスの確認、ポリシーに基づく返金処理、例外発生時のチケット作成、フォローアップのスケジュール設定、CRMの更新を、すべて監視下の単一フローで実行できます。

ITオペレーションの例では、コパイロットはエンジニアがログを読むのを支援します。エージェンティックシステムは、インシデントを検出し、関連するテレメトリを収集し、診断用のランブックを実行し、インシデントレコードを起票し、リスクの低い是正措置を提案または実行し、信頼度が低い場合や影響が大きい場合にはエンジニアにエスカレーションできます。

これが最も重要な変化です。生産性はもはや個人単位でのみ測定されるのではなく、人間とエージェントの混成チームの設計によって測定されます。運用業務の一部はデジタル労働力によって実行され、人間は監視、例外処理、ポリシー設計、継続的改善といった役割にシフトします。

これは、すべてのプロセスが高度な自律性に適しているという意味ではありません。多くの領域では、依然として強力な人間による管理が必要です。例えば、与信判断、機密性の高いマスタデータの変更、高額な支払い承認、法的影響を伴うアクションなどです。しかし、そのような領域であっても、エージェントは準備作業、検証、オーケストレーション、文書化を引き受けることができます。これをより早く理解した企業は、エージェントをアプリケーションの付加機能としてではなく、労働力モデルの一部として見るようになるでしょう。

対症療法ではなく、同時並行的な再設計

よくある誤りは、エージェンティックAIを既存のプロセスに単に追加すれば十分だと考えることです。実際には、最大の価値は、企業が以下の4つの要素を同時に再設計する用意があるときに生まれます。

第一に、プロセスです。単に古いステップを自動化するのではなく、フローを簡素化し、ハンドオフを減らし、例外パスを再定義することです。第二に、システムとアーキテクチャです。エージェントは、ツール、API、データ、イベント、ナレッジへの安全なアクセスを必要とします。適切な統合とコンテキストの基盤がなければ、エージェントはより高価なチャットボットに過ぎなくなります。第三に、ガバナンスと管理です。エージェントが行動できるのであれば、権限の範囲、承認の閾値、監査証跡、可観測性、説明責任が明確でなければなりません。第四に、人間の役割です。スーパーバイザー、プロセスオーナー、リスクオーナー、現場のマネージャーは、エージェントがいつ単独で行動してよいか、いつ承認を求めるべきか、そしてその結果に対して誰が責任を負うのかを知る必要があります。

したがって、エージェンティック・トランスフォーメーションはAIプロジェクトだけの問題ではありません。これは、ビジネス、テクノロジー、リスク、人事にまたがるアジェンダなのです。

なぜこれがエンタープライズのアジェンダとなるのか

多くの組織は、社内チャットボット、要約、ナレッジアシスタント、単一タスクの自動化といった小さなユースケースからAIを始めます。それは自然なことです。しかし、エージェンティックAIがエンタープライズのアジェンダとなるのは、焦点がタスクレベルの生産性からエンドツーエンドのバリューストリームへと移行したときです。

企業は、従業員がより速くメールを作成できるようにするだけでは、ビジネスの経済性を変えることはできません。戦略的価値は、エージェンティックAIが収益、マージン、キャッシュフロー、サービスレベル、リスク態勢に直接影響を与えるワークフローに適用されたときに現れます。関連するバリューストリームとしては、リードからキャッシュ(lead-to-cash)、調達から支払い(source-to-pay)、記録から報告(record-to-report)、カスタマーオペレーション、サプライチェーン、シェアードサービスなどが挙げられます。

これらの領域では、エージェントは待ち時間を短縮し、意思決定を加速し、調整の負荷を軽減し、実行の一貫性を高めることができます。しかし、それは企業がこれをAI機能の追加ではなく、オペレーティングモデルの再設計として捉えた場合に限ります。

エージェントが行動を実行し始めると、企業はそれを、仕事の権限、システムアクセス、権限範囲、目標とする成果、監督、監査証跡を持つデジタル労働力として扱う必要があります。これは現実的なマネジメント上の影響を伴います。請求書例外を処理するエージェントのマネージャーは誰か?ポリシーを設定するプロセスオーナーは誰か?自律性のレベルを承認するリスクオーナーは誰か?エージェントのパフォーマンスは、速度、精度、回復率、コンプライアンスのいずれで測定されるのか?エージェントの動作が逸脱した場合、どのように停止させるのか?これらの問いに対する答えがなければ、企業は制御不能な自動化を生み出すリスクを負います。

断片的なパイロットの罠を避ける

多くの組織は、参入障壁が低いために、数十の小さなパイロットを実行したくなるでしょう。問題はパイロット自体にあるのではなく、野心の断片化にあります。もし各部門が独自のエージェンティックツールを購入し、独自のユースケースを構築し、独自の成功を測定するならば、結果はエージェントの乱立(agent sprawl)です。多くのデモはあるが、エンタープライズへのインパクトはほとんどない、という状態です。

経営幹部は早期に問いかける必要があります。このユースケースはどの価値プールに接続されているのか?それは優先バリューストリームにおける真のボトルネックを解決するのか?適切な管理のもとで本番化できるのか?データと統合の基盤は存在するのか?成功した場合、部門横断的にスケールできるのか?優れたパイロットとは、技術的に最も魅力的なものではなく、ビジネス成果と新しいオペレーティングモデルへの道筋が最も明確なものです。

ビジネス上の選択からロードマップを始める

もしエージェンティック・トランスフォーメーションが構造的な変化であるならば、そのロードマップはツールのカタログから始めるべきではありません。それはビジネス上の選択から始めなければなりません。最初の質問は、どのエージェントプラットフォームを購入すべきかではなく、どのバリューストリームにおいて、企業が最も準備ができており、かつ実行の主体(locus of execution)を移す必要があるか、です。

CFOは、プロセスが構造化されており、データが比較的明確で、そのメリットが決算サイクルタイムと管理品質に直接結びつくため、record-to-reportを選択するかもしれません。COOは、ボリュームが多く、ハンドオフが多く、サービスレベルに直接的な影響があるため、カスタマーオペレーションを選択するかもしれません。CPOは、例外管理に多くの労力が費やされ、購買コンプライアンスに影響を与えるため、source-to-payを選択するかもしれません。CIOは、ランブック、可観測性、インシデントワークフローが段階的な自律化に十分成熟しているため、ITオペレーションを選択するかもしれません。ドメインの選択は、アーキテクチャ、データ、ガバナンス、組織変革モデルを決定づけます。

規律あるロードマップは、少なくとも各エージェンティックイニシアチブにおいて、以下の5つの次元を結びつける必要があります。すなわち、ビジネス目標、データとナレッジの準備状況、システム統合、自律性のレベル、ガバナンスモデルです。これら5つの要素がなければ、企業は一見高度に見えても、本番稼働時に脆いソリューションを生み出しがちです。

すべてのプロセスがエージェンティック・トランスフォーメーションの初期対象として適しているわけではありません。エージェンティックAIは、ボリュームが十分に高く、成果が明確で、ハンドオフや例外が多く、ルールをマッピングでき、データとシステムにアクセス可能で、ガードレールによってリスクを制限できるプロセスに最も適しています。逆に、このアプローチは、発生頻度が非常に低い、非常に政治的な、非常に曖昧な、または成熟した管理基盤なしでは規制上非常にセンシティブなプロセスを第一波として扱うのには適していません。例えば、高額な戦略的交渉、複雑な法的判断、管轄をまたぐ企業ポリシーの変更などです。このような領域では、AIはアドバイザーとして依然として有用かもしれませんが、主要な実行役となるにはまだ適していません。

今、何を決断すべきか

デジタルトランスフォーメーションとエージェンティック・トランスフォーメーションの違いを理解した上で、いくつかの初期の決断を下す必要があります。

第一に、自社がエージェンティックAIを個人の生産性向上のためのアジェンダと見るのか、それともオペレーティングモデルの再設計と見るのかを決定することです。もし後者の位置づけでなければ、その影響は限定的なものにとどまります。第二に、第一波として優先する1~2のバリューストリームを選択することです。相互に接続されていない多数の小さなユースケースから始めることは避けてください。第三に、ドメインごとに許可される自律性のレベルを設定することです。推奨のみ(recommendation-only)、人間関与型(human-in-the-loop)、制限付き自律性(bounded autonomy)を区別してください。第四に、部門横断的なオーナーを任命することです。少なくとも、ビジネスオーナー、テクノロジーオーナー、リスク/管理オーナーを明確にする必要があります。第五に、デジタルコアの基盤が本番稼働に十分な準備ができているかどうかを判断することです。データ、API、アイデンティティ、ログが未成熟であれば、初期の焦点はスケールではなく、準備態勢(readiness)に置くべきかもしれません。

準備態勢を評価するために、指標となるいくつかの質問があります。自社は、最も実行可能なエンドツーエンドのバリューストリームを特定しているか?そのバリューストリームにおける主要なボトルネック、ハンドオフ、例外パスは理解されているか?必要な取引データ、ドキュメント、ナレッジは比較的アクセス可能で信頼できるか?コアシステムは現実的な統合経路を持っているか?エージェントが実行を許可されるアクションと、人間の承認が必要なアクションについて明確になっているか?リスク、セキュリティ、法務、監査の各機能は、設計の初期段階から関与しているか?テクノロジーのデモではなく、運用上の成果を追求するビジネススポンサーが存在するか?

また、注意すべき危険信号もあります。各部門が共通のアーキテクチャやガバナンスなしに、独自にエージェントを購入または構築している場合、それは危険信号です。ユースケースがビジネスバリューストリームにとって重要だからではなく、デモが容易だから選ばれている場合、それは危険信号です。エージェントが誤った決定や行動をした場合の責任の所在が明確でない場合、それは危険信号です。データとナレッジが散在し、キュレーションされておらず、合意された真実の源泉がない場合、それは危険信号です。コアシステムの統合が困難で、エージェントがチャットとレコメンデーションに留まっている場合、それは危険信号です。変革チームがプロセスの再設計や労働力への影響についてではなく、モデルやツールについて話している場合、それは危険信号です。成功がビジネス成果の実際の変化ではなく、パイロットの数で測定されている場合、それは危険信号です。


エージェンティック・トランスフォーメーションは、最終的には、人間をより賢いソフトウェアに置き換えるという話ではありません。これは、デジタル労働力が日常業務の現実的な一部となり始めたときに、企業を再設計するという話です。勝つ組織は、最も速くエージェントのデモを作成した組織ではなく、この変化を中心にビジネス戦略、プラットフォーム、ガバナンス、労働力を最も規律正しく整合させた組織です。

次の記事では、より技術的でありながら極めて重要な問い、すなわち、エージェンティックエンタープライズアーキテクチャとは具体的に何を意味し、それを従来のエンタープライズアプリケーションアーキテクチャとどのように区別するのかについて掘り下げます。