-
Xでシェア
-
Facebookでシェア
-
LINEでシェア
-
LinkedInでシェア
-
記事をクリップ
-
記事を印刷
10年先ではなく、次の2年で何ができるか
過去2年間にわたり、誰もが生成AIに関する話題をたくさん耳にしてきた。しかし、生成AIがビジネスの世界をどう変えうるかについて熱狂的に語られるわりに、いま現在AIが何を実現しているのかを示す具体例を見つけるのは必ずしも容易ではない。企業はAIの実験から価値を生み出すことに苦労し、失敗していると報告するケースのほうが多い。
消費者による導入率も、依然として比較的低いままだ。「革命」などの言葉が使われるにもかかわらず、データによれば大半のユーザーの利用頻度は毎日ではなく週に1回程度であり、SNSやグーグルのようなプラットフォームほど頻繁には利用されていない。これは、生成AIがまだ消費者の本当の習慣として根づいていないことを示している。時折利用され、集中的に使われることもあるが、日常生活の基盤にはなっていない。つまり、過熱したブームに現実がまだ追いついていないのだ。
こうした報告はあるものの、生成AIはインターネットやスマートフォンと同じ規模の根本的変化をもたらすと筆者らは考えている。インターネットはおよそ20年にわたりイノベーションと企業の創出をもたらした。スマートフォン革命は、モバイルアプリに支えられて15年にわたる成長の時代を生んだ。生成AIも同じような変革の時代を牽引し、おそらく10年以上にわたり新たな価値を創出すると思われる。
先述したようなパターンは、新しいテクノロジーにおいてはよく見られる（ガートナーのハイプサイクルでしばしば説明されるように、過度の楽観、次に幻滅、その後に本当の価値創出が生じる）。筆者らの見るところ、「経済のあらゆる領域がまもなくAIに置き換えられる」と大胆に主張する主要なAI推進派の多くは、AIを過大評価している。なぜなら、既存企業において実際に機能するAIを導入するのは容易ではないからだ。比較的クリーンなデータ、プロセスのマッピング、綿密な実験が必要であり、そのうえでなお人間の介在（ヒューマン・イン・ザ・ループ）が求められる場合が多い。
とはいえ、舞台裏では着実な進展も見られる。それらの事例が示すのは、マルチエージェントシステムを用いて反復的なタスクを自動化、代替することで、より持続的かつ根本的な生産性向上につながる可能性である。
リーダーは今後10年のうちに何が起きるのかを当て推量すべきではない。代わりに、次の2年間で現実的に何を達成できるのかを自問する必要がある。筆者らが2024年後半に実施したプロジェクトでは、エージェント型AIが（少なくとも短期的には）真のゲームチェンジャーとなることが証明され、企業に実質的な価値をもたらしている。ただし、プロジェクトごとの金銭的利益はプラスだが、いずれも目を見張るほどではないのも現実だ。このような漸進的な利益はリーン生産方式のそれと似ており、マイクロソフトCEOのサティア・ナデラも同様の例えを用いている。
エージェント型AIシステムをうまく実装しているプロジェクト事例に関する筆者らの研究から、成功には何が求められるのかが判明した。ブームの過熱に惑わされず、このテクノロジーには何が可能なのかを理解し、その能力を明確な価値創出の機会と結びつけることである。また、実験と学びを通じてマルチエージェントシステムを実装するための、実践的なアプローチも必要だ。
エージェント型ワークフローという枠組みの台頭
過去数年の間に、AI技術は少なくとも3つの異なる段階を経て急速に成熟してきた。
・プロンプティング（2022年）：初期には「パワープロンプト」（高度に設計された指示文）に大きな関心が寄せられた。概念実証（POC）ではプロンプトはうまく機能するように見えた。しかし本番環境では信頼性が急速に低下した。業務プロセスは通常、95～99％の精度を必要とする。筆者らは50以上の事例を見てきた経験を踏まえ、プロンプティングのみでは出力の精度が70％を超えることはめったになかったと推測する。
・検索拡張生成（RAG、2023年）：RAGは、生成AIの出力を知識基盤に紐づけることで安定性を高めた。ここでもPOCは有望に見えたが、本番環境の複雑さによって弱点が露呈し、許容できないほど低い精度につながることが多かった。
・エージェント型システム（2024年から現在）：直近の進展は、小規模で専門化されたエージェント群のネットワークに見られる。エージェントの中には質問をルーティング（経路を選択・制御）するものもいれば、狭く定義されたタスクを遂行するもの、出力のチェックと修正を行うものもいる。いまではトークンのコストが下がったことで、マルチエージェントシステムの多段化が商業的に採算に見合うようになっている点が重要だ。この階層化設計が信頼性を大幅に向上させる。
2025年秋にはエージェント主導の商用プロジェクトが急増した。オープンAIはストライプおよびショッピファイとの提携を開始。グーグルは購入と決済のプロセスを自動化するエージェント決済プロトコル（AP2）を発表した。
企業はテック大手の動きに追随したくなるかもしれない。だが持続可能な価値の第一波が生じるのは、ここではない可能性がある。ベイン・アンド・カンパニーが先頃実施した消費者調査では、76％が買い物でエージェント型システムを使うことに抵抗感があると答えた。気が進まない理由として、大半の人がセキュリティとプライバシーへの懸念を挙げている。
顧客対応の場面は、現在のAIエージェントの能力とは相性が悪い。顧客対応は煩雑で予測しにくい。入力は構造化されておらず、トーンと文脈はたえず変化し、規制当局と消費者は幻覚（ハルシネーション）やエラーに対して寛容ではない。マルチエージェントシステムが高い精度に到達できるのは確かだが、そのためには個々のエージェントを幼児のように扱う必要がある。
幼児に「食卓の用意をして」とは頼まないだろう。作業を分解し、「まずはお皿を1枚置いて」「次にフォークを添えて」「次はグラスを置いて」と1工程ずつ指導すれば、幼児は有意義な貢献ができる。環境を制御しなければならない点も重要だ。騒がしい兄弟も、邪魔をするペットもおらず、親一人だけが指示を出すようにする。マルチエージェントシステムを、幼児への指示──タスクを分解し、1度に一つのタスクを与え、精度をチェックする──と同様の構造にすることで、驚くほど正確なシステムが構築される。
注目すべき点として、これらのシステムはバックエンドのプロセスに適している場合が多い。バックエンドには人間が介在するため、完璧さは必須ではない。対照的に、フロントエンドでのマルチエージェントシステムの実験は刺激的かもしれないが、企業に実質的な価値をもたらす最初の領域となる可能性は低い。バックエンドとオペレーションのプロセスは構造化され反復的なゆえに格好の土壌であり、エージェント型ワークフローによる自動化にはるかに適している。範囲が厳密に決められたタスク、明確に定義された環境、構造化された入力があってこそ、有意義な貢献をもたらすプロジェクトを生み出すことができるのだ。
エージェント型システムを全社レベルで構築する
全社規模でのエージェント型システムの設計は、概念的には単純だが運用面では多大な努力を要する。マルチエージェントシステムの構築に向けた一般的な枠組みは以下だ。
（1）タスクはグーグルADKのようなルーターエージェントに送信され、親が幼児に指示するように、複数のサブタスクに分解される。
（2）サブタスクは、タスク全体の一部分を遂行する個々のタスクエージェントによって完了される。親が一人の幼児にグラスを、別の一人にフォークを食卓に並べさせるのと同じだ。
（3）サブタスクの結果は検証エージェントによってチェックされる。
（4）エラーが見つかった場合、改善エージェントが調整案を提示する。
このアプローチはさまざまなツール、手法、サービスから成る急成長中のエコシステムに支えられ、ノンコア業務のプロセスには非常に適している。しかし、データの完全性と幻覚の制御が不可欠であるコア業務では、カスタムコーディングされたエージェント、基幹システムとのより緊密な統合、より綿密な制御とガードレールの導入が必要となる。
事例：現場オペレーションの改革
具体例として、筆者らが欧州の某大手インターネットプロバイダーとともに実施したプロジェクトについて考えてみよう。我々の目標は、修理サービスに寄せられる電話の解決時間とコストの両方を削減することであった。たいていの人は、ネット接続の不具合についてヘルプデスクに電話し、情報を何度も繰り返し伝え、最終的に技術者が来るのを待った経験があるだろう。
裏側で何が起きているのか（または実現できていないのか）を見れば、実態がわかる。技術者はしばしば状況を十分に把握しないまま到着し、問題を一から解決することを余儀なくされる。これが長い停止時間（時には1カ月以上）と、オペレーターの何千時間もの無駄につながるのだ。
我々は小さく始めることに決め、技術者が作業をより迅速かつ的確に行えるよう支援するシステムの構築に注力した。スタンドアローンのエージェントではなく、プロセスにおける「助手」である。取り組みの一環として、15を超える情報システムからデータを統合し、報告された障害の概要と、試行された解決策の履歴を技術者に提供した。これにより彼らは、顧客の接続トラブルの解決といった作業の概要を、現場に向かう途中で読んだり聞いたりできる。こうして到着後すぐに修理作業を始めることで、問題を把握するために再三無駄にしていた時間を節約できるようになった。
その後我々は、解決に向けて次に取るべき最善の行動を提案する機能を開発した。また別の機能には、技術者がインターネット会社の基盤ITシステムに自然言語で問い合わせ、根本原因を探すことができる対話型インターフェースを搭載した。
最後に、単純で反復的な作業の多くを自動化した。たとえば、間違った世帯がリンクされている場合にCRM（顧客関係管理）の記録を修正したり、地域の中央接続ボックスのスイッチが不具合を起こした時にネットワークリセットを実行したりする作業だ。これにより技術者は、修理のための細かい変更を求めて社内のコールセンターに連絡する必要がなくなり、膨大な時間を節約できるようになった。
我々は8カ月にわたり反復的に仕事を進めた。タブレット端末でソリューションを試している現場の技術者から毎週フィードバックをもらいながら、プロセスをマッピングし、悩ましい問題を解決し、機能を段階的に追加していった。
以下がその結果である。
・解決時間の60％短縮
・年間100万ユーロ以上の継続的なコスト削減
・顧客のネット・プロモーター・スコア（NPS）の大幅な向上
これらの結果を踏まえ、クライアントはソリューションをさらに7つの地域へと拡大することを望んだ。これには相当な労力が追加で必要となった。手法といくつかのエージェント要素は再利用できたが、各地域のITシステムは異なっており、各展開ごとに新たな統合とデータマッピングが求められた。それでも追加の各地域への拡大に要した労力は、最初の地域に要した労力の半分で済んだ。
マルチエージェントシステムの実装に伴う課題
上記で示した通り、マルチエージェントシステムの実装によって真の価値創出を実現できるが、実装の実務について語る人は非常に少ない。我々は次のような現実と障壁に直面した。
迅速なテストか、スケールアップか
最初から拡張性に優れたアーキテクチャで構築したのかと問われれば、そうだと主張したいところだが、それは不可能であった。イノベーターが反復を通じてプロダクト・マーケット・フィットを見出していくのと同じように、マルチエージェントシステムのユースケースとソリューションは、我々が迅速な実験のサイクルを回す中で反復的に進化していった。その次にシステム構築の技術、手法、サービスが急速に進化した。
我々はいきなり完全なシステムの構築に取り掛かったのではない。まずは一つのLLM（大規模言語モデル）とRAGを中心的要素とし、基本的に最初のユースケースを解決することから始めた。テストを重ねる中で、信頼性を高めるためにはシステムをより小規模なエージェントに分割し、より専門化されたタスクを追求させる必要があることを学んだ。これが徐々に完全なエージェント型システムへと進化していった。
最終的に、高い信頼性と機能性を備え、価値をもたらすシステムを開発することができた。現在はこの知識と成果をもとに、同社の他の部分への拡大に向けて、より高い堅牢性を備え、より簡単に維持管理できるアーキテクチャへの再構築を進めている。
問題領域と根本原因
我々の経験則として、リーダーとミドルマネジャーはどのプロセスが多くの時間や労力を要するのかを大まかに把握しているが、どの部分に煩雑さと改善機会があるのかについては認識が浅い。それを把握しているのは当該オペレーションの担当者だけだ。ここから示唆されるのは、システムの構築を実際に始める前に、2つのことを行う必要があるということだ。（1）マネジャーの視点から問題を理解することに十分に時間をかけながらも、（2）いかなる問題であれオペレーション担当者と話し合い、根本原因に関する彼らの見解を聞く。
たとえば、マネジャーは時間やリソースが無駄になっているプロセス（共通サービスセンターでの業務など）を我々に示し、オペレーターが問題をより迅速に解決できるよう、適切な「知識項目」を見つける方法を検討すべきだと指摘する。ところが、我々がオペレーターたちと直接協働し始めたところ、彼らの半数は「知識項目」を10秒以内に見つけたが、残りの半数はシステムの検索に長けていないため、同じ情報を見つけるのに数分を要することが判明した。これはエージェント型AIが効果的に解決できることではなく、訓練の問題である。
一方で我々は、リーダーとマネジャーが完全に見逃していた点を発見した。オペレーターは自分の時間の約50％を、顧客との通話の後でCRMに入力する作業に費やしていたのだ。これはエージェントが得意とする問題である。通話内容を文字に起こし、すべての情報を適切な項目欄に入力することで、プロセスを大幅に迅速化してデータ品質を高めることができる。オペレーターは確認してOKボタンを押すだけでよい。
遅延を招くのはITシステムではなく人間
我々の取り組みで最も多く労力を要し複雑だった部分は、然るべきマネジメントの議論にこぎつけること、ステークホルダーを味方に引き入れること、このプロジェクトによって生じた依存関係を突き止めて解消することであった。
ソリューションを機能させるために10を超えるITシステムを統合することは、技術的に見ても複雑だ。しかし本当の課題は、システムそれぞれに独自の開発チームがおり、おのおののスケジュール、優先事項、ロードマップも異なる点であった。APIエンドポイントを利用可能にしてテストする作業は2週間で済むかもしれないが、各ITシステムのロードマップにこの作業を入れてもらうには、はるかに長い時間を要した。我々が連携していたチームの大半はこの作業を何カ月も後回しにし、優先すべきもっと重要な仕事があると主張した（彼らの視点から見れば、正当な主張なのだろう）。
モデルは幻覚を起こす可能性があり、実際に起こす
エージェントはまだかなり不安定で、幻覚を起こす可能性があるため、LLM自身による評価（LLM-as-a-Judge）、つまり検証エージェントを用いた強固なガードレールとチェックが必要だ。エージェントのシステムプロンプトは、タスクを適切に実行できるよう十分な強度と軽さを兼ね備えていなければならない。ビジネスで運用できるようエージェント型システムの信頼性を十分に高めて機能させるには、繊細な調整、時間、そしてデータサイエンスとデータエンジニアリングのスキルが求められる。言い換えれば、優れた開発者とビジネス経験が依然として非常に重要である。
エージェント主導の変革の新たな規律
この事例から、より一般的な教訓として何が引き出せるだろうか。多くの意味で、これはリーンの再発見のように感じられ、業務を一から再構築することを伴う。以前と異なるのは、今日のツール群が格段に強力で、漸進的な最適化だけでなくプロセス全体の再設計を、部門横断的に行うことさえ可能にしている点だ。
データとAIの能力以上に、プロセスに対する深いリテラシーが成功を左右する。現状を把握し、今後の状況を想定し、それを組み立てやすい一連の小さな工程に落とし込む能力だ。その意味では（シックス・シグマの）「リーン・ブラックベルト」の復活を見ているようだが、現在は生成AIが原動力となっている。
これは細かく秩序立った取り組みであり、華やかなものではない。一歩ずつ着実に進める必要がある。魔法ではなく手法によって、このアプローチは拡大する。新たな業務分野ごとに、新たな分析を行い個別に適応することが求められる。
完全に自律的なエージェントが実現するのは、まだ遠い先だ。現時点で最も効果的な枠組みは、人間の介在を維持すること──つまりオペレーション担当者の能力とスピードを高め、態勢を充実させることである。
最初のうちは徐々にしか進展しない。基幹システム同士がつながり、情報がスムーズに流れるようになって初めて、大きな効率向上が生まれる。
また、テクノロジーはプロジェクトより速く進化する。8カ月前に使っていたツールはすでに古くなっている。ゆえに我々は、基盤技術が変わる前に、つまり1年以内に投資を回収できるユースケースに焦点を当てる。
さらに重要な点として、企業は内部能力を構築しなければならない。データエンジニア、データサイエンティスト、生成AIのUXデザイナー、そして一部では「コンテクストエンジニア」や「生成AIブラックベルト」とも呼ばれる、プロセスを熟知し変革を達成可能な工程に分解できる人材が必要だ。これらの能力を会社として備えることで、新たなエージェント型ワークフローをより迅速に（技術の進化に合わせて）構築できるようになり、それが競争上の真の差別化要因となりうる。
最後に、これらの取り組みは最終的に通常の業務運営に統合されるが、技術的観点とビジネスの観点を一体化させる強固なガバナンスの下で開始することが不可欠だ。このバランスこそが実験を変革へと導く。
これからの10年
生成AIの過熱したブームに導入が追いついていないかもしれないが、その潜在能力は本物だ。かつてのインターネット革命やスマートフォン革命と同様に、このプラットフォームシフトは産業のあり方を変えることになる。それは一夜にしてのディスラプションによってではなく、何年にもわたる規律ある改革を通じて進んでいく。
単にツールを導入するだけでなく、ツールによって自社を継続的に改革する能力を築く組織こそが、勝ち残るだろう。
