AIエージェントビジネスの現状と今後の考察

こんにちは！年末記事の第二弾、AIエージェントに関するビジネス記事になります。現状のエージェントはどうなっているのか、今後エージェントを始める方が参考になるように説明します。

第一弾の記事は既に公開されています。

Weekly AI Agent News!から見えたAIエージェントの現在地 - 襖からキリン

私が公開しているWeekly AI Agent News!や論文のリポジトリはこちらです。

speakerdeck.com

github.com

AIエージェントに取り組む人材とは？
企業のAIエージェントの状況
現状の主力エージェント製品を解説
これからのエージェントを考える
AIエージェントの誤解
最後に

AIエージェントに取り組む人材とは？

記事のターゲット層を絞るためにAIエージェントに関わる人材の関係図を示します。

図の説明をすると、最左列が新たなエージェントの提案や包括的な分析を取り組んだり、エージェント開発の土台を作る層です。中央が最左列から発信された知見、開発ツールをもとにサービス提供、プロジェクト提案、PoC検証をする層です。右列がエージェントを受け入れ、使う層になります。

今回の記事のターゲットは真ん中の層になります。

企業のAIエージェントの状況

まず最初に国内外のエージェントのサービス状況を振り返ってみます。以下は大企業を中心にエージェントのサービスを出している、または来年1月からサービスを出す会社です。

国外企業

国内企業

クラウドベンダー、ITベンダー、業務支援クラウドサービス、データ分析基盤サービスからエージェントの提供が始まっています。クラウドベンダーはどこもAgent Builderのようにエージェントを簡単に作れる開発フレームワークの提供をしています。

それ以外は各社のサービスの強みを活かしたエージェントを提供しています。データ基盤ならデータ分析支援、ドキュメント管理なら質問応答、業務支援ならタスク代行という形です。

既存サービスがない場合は、Web検索に基づくリサーチ支援サービス、エージェント開発伴奏、営業等の資料作成支援サービスを提供しています。

現状の主力エージェント製品を解説

エージェントビルダー

エージェント開発が難しいユーザー層にプロバイダが開発済みのエージェントを提供する、またはその一部カスタマイズできるサービスです。 AWS, Google, Microsoft等主要なクラウドベンダーはこぞって出しています。

具体的にどの業務で使うのが有効かなどの明確なユースケースは、私が知る限りではありません。ただ様々な顧客の業務課題ごとに調節できるように様々なアプリやデータと連携できます。

この手のエージェント開発は連携先アプリの機能が重要で、連携先アプリを人を介さずコントロールするのがエージェントの役割になります。ただ、作ったエージェントがどれだけ日常的に使ってもらえるか、業務改善のインパクトを出せるかはこれからです。

エージェントにメールの文面を考えさせて一時保存させたり、採用面接の担当者を割り当てたりと細かいタスクをやらせるか、大勢が共通の課題を持つタスクを担わせるかは考えものです。

アトラシアンから提供されるエージェントの例 (https://www.atlassian.com/ja/blog/atlassian-rovo-ga)

このビジネスの火付け役はやはりOpenAIのGPTsになります。

リサーチ、問い合わせ対応

RAGの延長線上のビジネスです。情報検索は社内文書やWeb情報を含みます。このエージェントはドキュメント管理サービス会社やRAGソリューション提供会社から提供されています。

Web検索はリサーチ業務で使われ、社内文書の検索は問い合わせ業務で使われます。リサーチは価格比較、特許検索、競合分析などに使用します。

エージェントの情報検索では必要な情報が揃うまで繰り返し検索をおこないます。そして、エージェントが必要な情報が揃ったか、もう揃わないか判断します。（その基準の定義が難しいことはやっている人は分かります。）

Genspark Autopilot Agent のデータ検索機能の実行プロセス

データに基づく意思決定支援

売り上げデータやCRMのデータを必要に応じて読み取り、分析してグラフなどに可視化して意思決定材料を報告します。このエージェントはデータ分析基盤や基幹システムを提供する会社から提供されています。

分析プロセスは目的やデータに応じて変化するため、固定されたワークフローではなく、エージェントが考える必要があります。

様々なソースから資料作成

資料作成は提案書、調査報告書、事例資料、ブログ、プレスリリースなど様々です。エージェントがWeb調査したり、社内資料を探し、データを読み取りしながら最後のレポートにまとめます。このエージェントはシンクタンク、コンサル、ITベンダーから提供されています。

どんな資料を作るかによって体裁や調査方法、読み解くデータが異なるため、定まったワークフローにならず、エージェントが考える必要があります。もっと特化型にするならば、作成する資料単位でエージェントを作ります。

Agentic Process Automation

RPA（Robotic Process Automation）の拡張になります。RPAは定型業務を自動化するフローをノーコードで作っていました。ただし、作った自動化フローのメンテナンスが度々必要でゾンビロボットが増えることもあり、ノーコードを使いこなす人材の育成も必要でした。 Agentic Process Automationはエージェントが定型業務と非定型業務のワークフローを作ってくれます。

エージェントによって生成されたワークフロー（引用：https://arxiv.org/abs/2411.05451）

これからのエージェントを考える

生成AIエージェントと業務ソフトウェアの結びつきが強くなる

多くのソフトウェアに「xx Intelligence」や「xx Agent」と名付けた機能がこれから徐々に増えていきます。現状はAIの強い会社が様々なプラットフォームに繋ぐ口を作り、データ連携を強化しています。データ連携先が増えればそれだけユーザーの利用用途を模索でき、ビジネスチャンスが生まれるからです。

一方で、私はSalesforceのように自社サービスの強みを活かした機能が増えていくと考えています。現にテキスト指示だけでソフトウェアを制御し、シミュレーションをおこなうなどの研究は増えつつあります。以下にも研究の実例を紹介しています。

Weekly AI Agent News!から見えたAIエージェントの現在地 - 襖からキリン

結局、エージェントの精度を高めるためには領域を絞り込み、タスクを限定させ、作り込む必要があります。なんでもデータ連携できても、結局一つ一つの精度が出ないとユーザーは使わなくなります。

あなたがエージェントビルダーを使うユーザーになる前に、自社のサービスを見直す方が賢明かもしれません。

「ユーザーが指示するだけで〇〇の業務が完了/効率化する」がキャッチコピーになる

マーケティングでこのフレーズを見ることが増えてきていますが、さらに増えると考えています。 UIで詳細設定まで細かく設定したり、パソコンの前で何度も手順書を見てやっていたことが、テキストや音声で指示をするだけで実行できると謳うソリューションです。

理由は、カスタムエージェントを提供する会社は売り文句がカスタマイズ性と自動化とデータ連携性に集まり、作ったエージェントのデプロイ先がTeamsやslackなどのコミニケーションツールかChatGPTのWeb版のようになるためです。

その結果、対話形式で様々なタスクが自動化されると表現されます。

業務特化のエージェントも同様で、どの業務が完了するかを変えるだけで同じ謳い文句になります。

GUIからコンピュータを制御するのはまだ難しい

研究テーマとして非常に難易度が高く人気がありますが、ビジネスで利用するにはまだ厳しい見方をしています。コンピュータ制御でWebナビゲーションをするにしても、様々なサイトへの適応力やアプリの使い方の理解、画面に存在する数多くのボタンの意味を的確に理解し実行する必要があります。しかもそれらを的確に10回以上正しく続けて初めてECサイトの購入などのタスクは完了します。

LLMプロバイダは稼ぐ必要があり、APIの利用料は痩せ細ったため、アプリケーションで稼ぐ必要があります。そのためのアプリケーションとして先行者利益でAnthropicは、Computer Useの機能を出していますが、まだ成就するのに時間がかかります。

Computer use (beta) - Anthropic

Appleのようなスマホを提供する会社もエージェントによる音声アプリ操作は力を入れています。しかし、まだ人間が望むような高い汎用性は研究では得られていません。

汎用的なエージェント設計は難しく、業務特化のエージェントに勝機あり

エージェントを汎用的に複数の業務で役立つようにすると図に示すようなアーキテクチャになりますが、各業務の精度は単体特化より下がってしまうことが経験的に知られています（左下）。全てを高い精度で維持するには、エージェントのアーキテクチャの工夫よりも、ベースとなるLLMの能力の向上が今以上に必須です。

精度が低いとユーザーは使いませんし、納品すらできません。結局、業務特化で動くように作ることになります（上段）。

そして、業務特化のエージェントをいくつも作り、オーケストレーターがルーティングして、あたかも汎用的なエージェントに見せかける（右下）のが今の技術の現状です。

既に海外のベンチャーは去年の時点で汎用型で失敗し、特化型でビジネスを進めています。以下の記事は今年の6月の記事ですが、その背景が良くわかるのでおすすめです。

Agents aren’t all you need - by Miguel Rios Berrios

AIエージェントの誤解

自動化したければAIエージェントではない

最近のリリースや発表を見ると、研究者が目指すエージェントとビジネスで使うエージェントに乖離が出ています。

ビジネスの方が定義が緩く、とにかくバズワードを使いたいと言わんばかりに内部ロジックや振る舞いに限らず、AIを使って自動化したものは全てエージェントとしている印象です。超大手の某社は通訳するだけでエージェントという始末。

研究のツール利用、メモリ、計画などを軸にしたLLMエージェントを知っている人からすると、最近の某社リリース内容はエージェントではないと言いたくなるものです。ですが、それ以前にもエージェントの概念はもちろんあり、人工知能が環境で動作するならその主体はエージェントと考えることもできます(Russell and Norvig, 2022)。今までもエージェントの概念はあって、少しずつ時代に合わせて変化していきます。

あなたは広義のエージェントか最近の狭意のエージェントのどちらで語っていますか。マーケティング観点では広義の方が使いやすく、技術者の場合、狭意の方が技術的に議論がしやすく分かりやすいでしょう。

なぜこんなにも命名に慎重なのかというと、研究者が現在目指す”エージェント”が適切に刺さる課題は、世の人が自動化したいことの一部です。（ほんの一部は言い過ぎな気もしたので期待を込めて一部です。）むしろ自動化したいことの多くは別の方法で解決する方が性能が良いです。広義でエージェントで考えているとその違いを区別できず、見えなくなってしまいます。

私の体感では以下の図のイメージです。以下は全て狭義のLLMエージェントのことを指しています。

わざわざLLMがツールを使わずとも既に世の中には便利なツールがあります。それだけで解決できるかもしれません。社内から「エージェントでもできるけど、別のツールでもできるよね？」と声が上がると良いですね。

更に自動化したいことのうち、LLMを使うことが有効そうな課題はその一部で、検索含めたLLMによるワークフローで解決を目指せます。わざわざ思考して計画立てたり、自己修正もいらないです。淡々と上から下に処理を流して、プロンプトエンジニアリングすれば良いです。ただ最近はこのフローの処理一つ一つをエージェントと呼び、マルチエージェント呼ぶ人たちもいます。何を持ってエージェントのつもりなんでしょうか。

エージェントは、タスクの処理プロセスが動的であったり、人間のような思考でケースバイケースを対処する必要がある課題に対して出番になります。

なんでもかんでもエージェントに持っていくことはできますが、果たしてそれが最適な解法なのかは注意深く検討する必要があります。過去のDeepでぽん！だった時代を思い出すとわかってくれる人はいると思います。

エージェントのプロセスが理にかなっているから結果も正しいわけではない

エージェントの動作の仕組みが、人間の業務フローと似て納得感があれば、結果が正しくて業務に役にたつように思ってしまいますが、そんな保証は全くないです。いくらエージェントのフローが人間の解釈的に妥当でも、プロンプトが妥当でも、LLMが正しく出力できなければ、それで処理は終わりです。

エージェントに複雑なことをさせているため、結果で良さが測りにくくなり、いつの間にか結果重視からプロセス重視になっていませんか。エージェントの動作原理の説明は、あくまで顧客にサービスの透明性と信頼性の補助材料であって本質は結果です。

できる限り、そのエージェントがどんな課題にどう答えることができるのか、プロセス評価と合わせて結果も評価し、アピールすべきです。単純なLLMの生成やRAGより良い回答をするとか、回答に深みが出るでは足りません。

来年には似たようなエージェントが市場に乱立します。そのとき他社と比較されたとき説明できますか。そのためには結果にこだわり、アピールポイントを端的に説明できるようににこだわる必要があります。

似たような話で、OpenAIのo1から推論スケーリング則でプロセス評価が注目されていますが、結果の教師でなくプロセスを監督する必要性という記事が過去にあります。こちらもおすすめの記事です。

Supervise Process, not Outcomes — AI Alignment Forum

都合のいい言葉「マルチエージェント」

そもそもマルチエージェントのエージェントをどう解釈していますか。ここが大事です。 人の職業や性格などの役割を指すのか、タスク処理の機能を指すのか、自律型エージェントを指すのかです。

強化学習では、意思決定モデルをエージェントと呼びます。もちろんマルチエージェント強化学習のエージェントでも同じです。

ただLLM以降の生成AIエージェントでは同時期に様々な分野から多くの論文が発表され、エージェントの言葉がそれぞれの分野の意図でそのまま使われました。例えば、分野としては社会シミュレーション、ゲーム理論、心理学、対話システム、MAS、強化学習、ツール利用があります。

その結果、新たな流派のLLMエージェントとそのマルチ化のマルチエージェントという構図にはなりませんでした。

どれが間違いということでもないので、せめて自社の目指すエージェント像のマルチ化をマルチエージェントとして統一してほしいですね。

でないとあなたの会社が言うところのエージェントってなんですか？でサービスの内容と矛盾を生み、混乱になります。下手したらどれもこれもエージェントでは？と指摘されかねます。営業が顧客に説明するときに苦労するのが目に見えます。

そしてエージェントの命名が適当になってくると、「なんだエージェントって大した事ないのね。」ということになり、一瞬で幻滅期に突入すると考えます。

最後に

この記事では、エージェントの現状のビジネスを振り返り、これからエージェントのビジネスがどうなるか、更にエージェントに関して良くある誤解をまとめました。

エージェントビジネスはまだ黎明期であり、多くの課題を抱えます。
自社のサービスと市場ニーズに合った特化型エージェント開発が鍵です。
技術者とビジネス層が連携して戦略を練る必要があります。

この記事を読んで、ぜひ自社のエージェント開発を振り返ったり、来年の戦略を考えてみてください。