9 ポイント 投稿者 xguru 2024-10-07 | まだコメントはありません。 | WhatsAppで共有
  • すべての仕事は、人間と機械が共有する作業の束として捉えられる
  • ソフトウェアがますます多くの作業を処理している一方で、依然として大半のビジネスプロセスは人間が担っている
  • AI agentは、この業務バランスを決定的に変えると期待されている
  • これまでの世代のソフトウェアとは異なり、新しい認知アーキテクチャによってend-to-endプロセスを動的に自動化できる
  • これは単に読み書きができるAIではなく、アプリケーションロジックの流れを決定し、ユーザーの代わりに行動できるAIであり、企業におけるLLMの最大の機会を示している

これって単なるRPAでは? : RPAの限界と問題点

  • すでに聞いたことのある話に思えるかもしれないが、それはUiPathやZapierが過去10年間にわたり「bot automation」という名前で似たビジョンを売り込んできたから
  • UiPathはRPAの巨人で、画面スクレイピングとGUI自動化を通じてユーザーの行動を記録し、順次的なステップを模倣して、文書からの情報抽出、フォルダ移動、フォーム入力、データベース更新などのプロセスを自動化する
  • その後、ZapierのようなiPaaSプロバイダーは、より軽量な「API自動化」アプローチを導入したが、UiPathとは異なり、その範囲はWebアプリ自動化に限定される
  • UiPathとZapierは、部門別または業界固有のソフトウェアシステムの内部および間に存在する、企業プロセスのlong tailを解決するための、組み合わせ可能なルールベースの水平型自動化プラットフォーム市場を実証した
  • しかし企業がbotベースの自動化を拡張するにつれ、既存アーキテクチャの能力と約束された自律性の間のギャップが明らかになり始めた
    • 依然として多くの人手と手作業が必要。自動化の構築および保守プロセスは、今なお痛いほど手動的である
    • UI自動化は脆弱で、API統合には限界がある。UI自動化はソフトウェアUIが変わると頻繁に壊れ、APIはより安定しているものの、レガシーまたはオンプレミスのソフトウェアとの統合ははるかに少ない
    • 非構造化データを扱えない。企業データの80%は非構造化および半構造化データだが、シーケンスベースの自動化ではこのデータをインテリジェントに扱えない
  • 既存のRPAやiPaaSソリューションは、LLMを統合しようとする場合でさえ、決定論的アーキテクチャに縛られ続けている
    • UiPathのAutopilotやZapierのAI Actionsは、テキストから行動への変換や、セマンティック検索、合成、ワンショット生成のためのノードといった下位agent設計パターンに対してのみLLMを提供している
  • こうしたAI機能は強力になり得るが、プロセス自動化におけるLLMのより革新的なユースケースは、なお見落とされている

AI agentは意思決定エンジンとして根本的に異なる

  • Agentは、今日のRPAボットやRAGアプリとは異なり、アプリケーションの制御フローの中心に意思決定エンジンとして位置している
  • これにより初めて、適応性、多段階の行動、複雑な推論、強力な例外処理が可能になる
  • 請求書照合(Invoice Reconciliation)の例で説明すると、新しい請求書PDFを会社の総勘定元帳と一致させる簡略化されたプロセス図においても、ワークフローの複雑さはすぐに扱いにくくなる
    • 最初の3つの意思決定セットの中だけでも、関連するあらゆる例外状況を考慮することはほぼ不可能になる
    • このワークフローをロボットのように実行するRPAボットは、エラーを起こし、部分一致や欠落項目を人間へエスカレーションすることが多い
  • しかし、同じワークフローにagentを適用すると、はるかに優れた性能を発揮する
    • 新しい状況への適応: 基本的な推論と関連するビジネス文脈に基づいて、新しいデータソース、請求書フォーマット、命名規則、口座番号、ポリシー変更などをインテリジェントに認識し適応できる
    • 多段階作業が可能: 請求書金額が一致しない場合、仕入先の最近のメールを調べて価格変更の可能性を確認するなど、多段階の調査を実行できる
    • 複雑な推論を実演: 国際的な仕入先の請求書を元帳と照合する必要がある場合、請求書通貨、元帳通貨、取引日、為替レート変動、越境手数料、銀行手数料など、複数の考慮事項をまとめて検索し計算しなければならない。Agentはこの種の知能を発揮できるが、RPAボットは人間にエスカレーションすることになる
    • 不確実性への対処: 個々の項目の丸め誤差や判読不能な数字といった例外に対して、総注文金額の一致、過去の請求書の時期や頻度などの文脈をもとに、堅牢に処理できる

AI agent市場の地図

  • AI agentはもはやSFではない。新興企業からFortune 500企業まで、すでにこうしたシステムを大規模に購入し活用している
  • 現在のagent市場は、ドメイン特化性とLLM自律性という2つの主要な軸で可視化できる
    • ドメイン特化性: 医療やカスタマーサポートのような垂直業界や部門向けの専門agentから、幅広く汎用的な機能を持つ水平型agentプラットフォームまでさまざま
    • LLM自律性: 言語モデルがアプリケーションロジックを独立して計画・指示できる度合いを表す
  • 市場マップの右上には、最も水平的で汎用化可能なagentが含まれる
    • Enterprise agent: 自然言語のSOPや新入社員に渡すものに近いルールを通じて、複数の機能やワークフローにまたがるagentを構築・管理できるスケーラブルなプラットフォーム。大半は「agent on rails」アーキテクチャを使っており、各新規プロセスについて、あらかじめ定義された作業、ビジネス文脈、ガードレールのセットにagentを基づかせる必要がある
    • Browser agent: Webブラウジング、視覚的なUI操作、テキスト入力などを自動化するために、多様なソフトウェアインターフェースと基盤コードベースで訓練されたビジョントランスフォーマーを活用する「general AI agent」設計に従う。汎用性は得られるが、一貫性を犠牲にしがちな傾向がある
    • AIベースのサービス: 「agent on rails」設計を実際に機能させるには広範なデータインフラとガードレールが必要なため、DistylやAgneticのような企業が、「Palantir for AI」モデルとして、顧客とのギャップを埋めるためのforward-deployedエンジニアリングサービスを提供している
  • しかし、すべてのagentが水平的で汎用化可能なものを目指しているわけではない。問題タイプを制限して信頼性を高められる、ドメインおよびワークフロー特化型agentが増えている
    • Vertical agent: SOPやルールに従って人が処理する、手動かつ手順中心のプロセスに最も有望な機会がある。カスタマーサポート、採用、コードレビュー/テスト/保守などのソフトウェア開発作業、コールドセールス、セキュリティ運用などが代表的なカテゴリ
    • AI assistant: ドメイン特化性ではなくタスク特化性によってagentの焦点を絞るもう1つの方法。エンタープライズagentや垂直agentが扱う複雑なend-to-endプロセスとは異なり、より単純で生産性中心の作業を担う
  • Agentそのものではないが、RAGアーキテクチャを中心に構築された生成AIソリューションが、agentベースのソリューションと同じ予算やワークフローをめぐって競合することもある
    • Vertical AI: 医療自動化プラットフォームTennrは、FAX、PDF、電話など多様なソースから非構造化データを抽出し、診療所のEHRへ入力することで紹介処理を進め、スタッフの手作業入力を不要にする
    • RAG-as-a-Service: DanswerやGradientのような企業は、顧客がPDFなどの非構造化データソースをクエリし、データを抽出して、より構造化されたデータベースやシステムに入力できるようにする
    • Enterprise search: Glean、Perplexity、Sanaなどは、概念的に関連する文書を索引化・検索し、組織全体の知識をよりよく管理し、データサイロを解体するためのセマンティッククエリを提供する

未来の企業自動化

  • 生成AIの第2の波は、単に読み書きするだけではなく、ユーザーの代わりに考え行動できるagentによって定義されるだろう
  • こうしたアーキテクチャが成熟するにつれ、AIによるサービス経済の席巻を強力に後押しする触媒となるだろう

まだコメントはありません。

まだコメントはありません。