2025年はAIエージェントの年になるかもしれない、もし彼らが企業の地獄を生き延びることができれば

企業は数十年にわたって、バックオフィス業務、データ入力、請求処理、その他の反復的なワークフローの自動化を模索してきました。しかし、ソフトウェアが進化しても、真のエンドツーエンドの自動化はほとんどの企業にとって実現が困難です。現在、大規模言語モデル (LLM) が急速に普及し、自律的に推論して行動できる「AI エージェント」が登場したことで、2025 年はついに企業の自動化が大きく前進する年になるだろうという見方が高まっています。 サム・アルトマンは「2025年には、最初のAIエージェントが労働力に加わり、企業のアウトプットを大幅に変えるかもしれない」と おり、一方マーク・ベニオフは、多くの組織プロセスが専門のエージェントに委任される未来を見据えて、Salesforceを「AgentForce」へと方向転換させています。これらの予測は、AIエージェントは現実世界のエンタープライズシステムの複雑なハードルを乗り越えることができるのか、という中心的な疑問を提起します。この記事では、エンタープライズ自動化の特有の難しさについて検討し、今日の有望な（しかしまだ成熟段階の）ソリューションのいくつかを探ります。また、Salesforce（SFDC）の一見単純なワークフロー（新規アカウントの再販業者注文の作成）の実践的なテストを共有し、舞台裏に潜む複雑さを明らかにします。 公言して エンタープライズ自動化がなぜ難しいのか? 理論上は、企業のタスクの自動化は、ログイン、フォームへの入力、そして「送信」をクリックするスクリプトを実行するだけという簡単な作業のように思えます。しかし、実際には、その複雑さは驚くほどです。企業は、Salesforce、SAP、Oracle、そして自社開発のソリューションなど、無数の記録システムに依存しています。各システムには、独自の権限、認証フロー、カスタムビジネスロジックのネットワークがあります。さらに、これらのシステムは大幅にカスタマイズされていることがよくあります。企業ごとに異なる特殊な UI、追加のデータフィールド、特注のワークフローが見られるのはよくあることです。 MuleSoft と Deloitte の共同調査によると、大企業は日常業務をサポートするために平均 976 の異なるシステムを使用している可能性があります ( )。この断片化により、自動化ツールは複数のシステムと通信する必要があり、各システムはそれぞれ微妙な違いがあり、堅牢な API を備えているものもあれば、まったく備えていないものもあります。多くの場合、最も単純なタスクは、古いレガシー アプリケーションと新しいクラウドベースのサービス間でデータをブリッジすることです。Salesforce のような標準プラットフォームでさえ、カスタム ワークフローとサードパーティの統合が導入されると、迷路のように複雑になる可能性があります。 ソース このような背景から、LLM を利用したエージェントはより柔軟なアプローチを約束します。少なくとも理論上は、データを解析し、次のステップを推論し、複雑な GUI を操作することさえできます。しかし、次の例でわかるように、AI エージェントに人間の助けを借りずに基本的な Salesforce ワークフローを実行させることは、多くの人が認識しているよりも複雑です。 実践例: Salesforce でカスタム再販業者注文を作成する タスク Salesforce を使用している自転車製造会社の営業担当者だと想像してください。あなたは「Northern Trail Cycling」という新しい再販業者に、大型の Dynamo X1 自転車 1 台を 5,000 ドルで販売したところです。あなたの仕事は次のとおりです。 1 - Salesforce に対して認証します (提供された資格情報を使用)。 2 - 再販業者用の新しいアカウントを作成します。 3 - 再販業者の注文を作成し、明細項目 (自転車) を追加します。 4 - その注文を製造部門に提出して承認を得ます。 実行が成功すると、最終結果は次のようになると予想されます。 一見シンプルに見えますが、細部にこそ問題があります。同社の Salesforce インスタンスはカスタマイズされており、カスタムの「再販業者注文」オブジェクトとフロー、製品追加用の特別なドラッグ アンド ドロップ機能、明確なラベルのない非表示の「製造に送信」ステップを使用しています。私は、いくつかの新しい AI 駆動型自動化アプローチを使用してこのシナリオをテストし、その効果を確認しました。 クロード コンピュータの使用 それは何ですか？ Claude Computer Use は、 Anthropic の新機能です。これは、Claude に「表示」および「制御」するためのコンテナ化されたデスクトップ環境全体を提供することで、標準の LLM 関数呼び出しパラダイムをさらに一歩進めています。スクリーンショットをキャプチャし、視覚的/空間的推論によって解釈し、マウスのクリック、スクロール、キーストロークなどの OS レベルのアクションを実行できます。 Claude 3.5 Sonnet v2 で導入された ユーザーの視点から見ると、Claude に高レベルのタスク (「Salesforce にログインしてこの再販業者の注文を作成する」) を与え、Claude はまさにそれを実行しようとします。次のシーケンスをループします。 スクリーンショットをキャプチャして解釈します。 UI アクション (マウス クリック、キーストローク、bash コマンド) を発行します。 タスクが完了する（または諦める）まで繰り返します。 テストしてみる まず、 を変更せずに Anthropic のリファレンス実装を実行する最も簡単な方法から始めましょう。ここでは、最初のプロンプト、Claude の提案したプラン、および対話を開始するデスクトップを示す対話の開始を示します。 システム プロンプト クロードのコンテナ化されたデスクトップを観察して、最初は感銘を受けました。ブラウザを開き、Salesforce URL にアクセスし、提供された資格情報でログインし、「アカウント」に移動しました。フォームに正しい詳細を入力して、 の新しいアカウントを完璧に作成し、新しい再販業者の注文を作成しようとしました。バイクを追加するためのカスタム ドラッグ アンド ドロップ インターフェイスに遭遇するまでは、すべてが順調に進んでいました。ピクセルベースのドラッグ アンド ドロップを実行しようとして、システムが停止しました。 Bike Production Company 何度か失敗した後、別の方法（非表示の「アイテムの追加」ボタンなど）を探そうとしました。「編集」ボタンを使った最初の試みは成功しませんでした。 「編集ダイアログには、製品を追加する明確な方法がないことに気がつきました。再販業者の注文ドロップダウンをクリックして、他のオプションがあるかどうか確認し、別の方法を試してみます。」 最終的には、「関連」タブから新しいアイテムを追加する方法を発見することで解決に至りましたが、アプリの動的トリガーが注文合計を自動的に更新しなかったため失敗しました。SFDC アプリの開発者は、人間のユーザーがドラッグ アンド ドロップ方式に従うだけと想定して、このコード パスの開発を完了しませんでした。つまり、このフローは AI エージェントではなく、人間向けに設計されていたのです。 次に、クロードはカスタム タブの下に埋もれていた「製造に送信」ボタンを見つけようとしました。その手順についての事前知識がなかったため、数分間もたつきました。最終的には、私が介入して、自転車を手動で注文に追加し、クロードに関連ボタンを指示する必要がありました。約 10 分と約 0.80 ドルの使用コストが経過しましたが、プロセスはまだ完全に自動化されていませんでした。Anthropic がこの機能を実験的と呼ぶ理由は簡単にわかりました。Computer Use が実際に製品化できるようになるまでには、多くの現実世界のガードレールと改善が必要です。 もっと良くなる可能性はあるでしょうか? 荒削りではあるものの、このコンセプトは刺激的です。GUI インタラクション用のビジョンベースの AI は急速に改善しており、推論のコスト曲線は急速に下がっています。 によると、同じパフォーマンスの場合、LLM のコストは年間約 10 分の 1 に減少しています。原理的には、Claude の将来のバージョンでは、ドラッグ アンド ドロップなどの視覚/空間タスクがより高速かつ安価で正確になる可能性があります。 最近の a16z の調査 しかし、根本的な問題は、エンタープライズ UI、特に古いものや大幅にカスタマイズされたものは、自動化を考慮して構築されることがほとんどないということです。ピクセルレベルのインタラクションは脆弱です。レイアウトの小さな変更や動的なポップアップにより、フロー全体が中断される可能性があります。視覚的に基礎を置いた GUI フレームワークに関する も増えていますが、何百もの異なるワークフローでこれらを実稼働レベルにすることは、大きな仕事です。 研究 ヘッドレスブラウザ: GUIを完全に省略 代替アプローチの 1 つは、「視覚的な境界ボックス」を完全に無視することです。ターゲット アプリケーションが Web ブラウザーで実行される場合は、スクリーンショットやピクセルベースのインタラクションをスキップして、DOM レベルで自動化できます。Playwright や Selenium などの従来のヘッドレス ブラウザーはテスト フレームワークに関連付けられることがよくありますが、AI ユースケースに重点を置いた新世代のヘッドレス ブラウザーが登場しています。これらの新しいプラットフォームは、Playwright と Selenium を基盤として構築され、より動的な LLM 駆動のインタラクションを可能にします。 ブラウザベース はその一例です。これは、開発者がコンテナを管理する必要なく、ブラウザ セッションをホストおよびスケーリングするインフラストラクチャ プラットフォームとして機能します。インタラクション パターンは、ページの HTML コンテンツを xPath にマップされたコンポーネント (フォーム、ボタンなど) に解析し、この構造を選択した LLM に渡すことを中心に展開されます。次に、LLM は実行する次の Playwright コード セットを生成し、従来の GUI クリックではなくコードを介して DOM とインタラクションできるようにします。完全にヘッドレスであるため、スクリーンショットの使用が少なくなるかまったく使用されないようになり、完全な「デスクトップ環境」アプローチよりもコンテキストの長さが短くなり、レイテンシが低くなります。 BrowserBase 最近では、開発者の作業を容易にするために、BrowserBase が オープンソース ライブラリをリリースしました。元のモデルでは、インタラクションはまだ非常に手動で、開発者は Playwright コードを直接記述したり、HTML を手動で解析したりするなど、ヘッドレス ブラウザーの低レベルの詳細を扱う必要がありました。StageHand では、BrowserBase はより高度な抽象化を提供し、開発者は「ナビゲート」や「抽出」などの意図に基づく自然言語コマンドを使用できます。このアプローチには、生の HTML をコンポーネントに変換する処理も組み込まれているため、LLM がタスクを処理しやすくなります。ただし、StageHand 自体には組み込みのオーケストレーションが提供されていないため、ユーザーはワークフローを接続および管理するために独自のオーケストレーション レイヤーを作成する必要があります。 StageHand BrowserBase をテストするために、Playwright コードを書くためのコンソールと、それらのスクリプトを自動的に生成する LLM プロンプト ライターを提供する同社の開発者プレイグラウンドを使用しました。その目的は、ログイン、アカウントの作成、再販業者の注文の作成という、複数のステップから成るナビゲーションを実行することです。ただし、このプラットフォームでは、各ステップを自分で調整する必要があります。Claude に与えられたのと同じプロンプトから開始すると、BrowserBase は複数のステップで推論することができず、つまずいてしまいました。そこで、各ステップに自然言語プロンプトを提供し、生成された Playwright コードが意図したとおりに動作するかどうかを観察しました。下のスクリーンショットでは、一連のプロンプトと、生成された Playwright コードを確認できます。 実際には、Playground のブラウザ環境と、入力する必要のある HTML フォームの間に不整合が時々発生しました。ボタンが奇妙にレンダリングされ、待ち時間が長くなり、フォーム フィールドが期待どおりに読み込まれませんでした。これらの不具合にもかかわらず、LLM で生成された Playwright コードは、ログインしてアカウントを作成し、再販業者の注文フォームに部分的に入力することができました。ただし、ドラッグ アンド ドロップでアイテムを追加するのが、またもや障害でした。約 7 分間、いじくり回した後、諦めました。このプラットフォームがまだこのようなタイプの自動化に適していないことは明らかでした。これは、Web スクレイピングのユース ケースに最適であると考えられます。 スカイバーン デフォルトでオーケストレーションを追加する、よりオールインワンのヘッドレス アプローチです。ユーザーが手動で手順を定義して管理する必要がある BrowserBase とは異なり、Skyvern はすぐに使用できるオーケストレーションの処理を試みます。内部的には、 に見られるように BrowserBase と同様に動作しますが、手順をオーケストレーションして推論できる Web エージェントも追加されています。これには、意思決定を支援するために、抽出されたコンポーネントとその xPath とともにスクリーンショットを LLM に送信するオプションのビジョン モードが含まれます。 Skyvern は、 オープンソース コード BrowserBase での手動ステップ作成の制限に対処するために、私は Skyvern のマネージド サービスを使用して、特にワークフロー モードに焦点を当ててテストすることにしました。このモードは複数ステップのプロセス用に設計されており、Salesforce ワークフローでのパフォーマンスを評価したいと考えました。残念ながら、実行には 15 以上の推論ステップと 1 ドルのクレジットが 2 要素認証 (2FA) プロセスで停止しました。Skyvern のホスト IP にフラグが立てられ、2FA がトリガーされ、手動でコードを入力したり、Cookie を共有して状況を回避する方法はありませんでした。これは、エンタープライズ環境での認証の継続的な課題を浮き彫りにし、 のようなスタートアップが AI エージェントの認証ソリューションのみに焦点を当てて登場している理由を強調しています。 Anon Skyvern のチームは、このプラットフォームをよりシンプルで小規模なタスクに適したものと位置付けており、サポートされる主なユースケースは連絡フォームの自動化です。その他の潜在的なユースケース (ジョブ、請求書など) はまだ「トレーニング中」と記載されており、このプラットフォームはエンタープライズ ワークフローのより複雑なニーズではなく、シンプルなユースケースに重点を置いた自動化から始めていることを示しています。有望ではありますが、開発のこの段階では、Skyvern はそれほど複雑ではないシナリオに適していることは明らかです。 トレードオフ ヘッドレス ブラウザはピクセルレベルの推測を省略するため、エラーが少なくなり、実行が速くなります。ただし、ドラッグ アンド ドロップや複雑なシングル ページ アプリなどの高度な機能を使用するとすぐに、部分的なスクリーンショット分析や特殊なコードに戻る必要がある場合があります。ブラウザは 2FA や IP ブラックリストに遭遇する可能性もあります。マルチテナントのエンタープライズ アプリケーションの場合、認証だけでは難しい場合があり、カスタム オーケストレーション レイヤーが必要になることもあります。 もう 1 つの制限は、これらのプラットフォームがワークフローが実行されるたびに LLM を介して動的にコードを生成することに依存していることです。LLM は本質的に非決定論的であるため、出力されるコードは実行ごとに異なる可能性があり、一貫性を監査または検証することが困難になります。この予測不可能性は、特に機密性の高いワークフローで問題を引き起こす可能性があります。生成されたコードのキャッシュは一部のプラットフォームではロードマップにあるようですが、LLM にとっては大きな課題となります。推論中のプロンプトまたはバッチ処理のわずかな変更でも、まったく異なる結果が生成され、キャッシュ プロセスが複雑になることがあります。 全体的に、ヘッドレス ブラウジングは完全な GUI 操作よりも安価で安定していますが、魔法のような解決策にはほど遠いものです。BrowserBase や Skyvern などの多くのソリューションは、「すべてを自動化する 1 つのプラットフォーム」ではなく、より狭いユース ケース (フォーム、データ抽出など) に重点を置いています。 内部 API のリバース エンジニアリング 3 つ目のアプローチは、クリックしたときに発生するネットワーク呼び出しを傍受して、Web ページを完全にバイパスすることです。ブラウザが送信するリクエストをキャプチャできれば、それらの呼び出しをコードで再構築できます。原理的には、これにより面倒な UI ベースの手順が回避され、アプリケーションが使用するのと同じバックエンド ロジックが確実に実行されます。この傾向は完全に新しいものではなく、API のリバース エンジニアリングは以前から行われてきました。ただし、新しい追加機能として、ネットワーク リクエストを推論する AI エージェントが組み込まれ、プロセスがよりインテリジェントで適応性の高いものになっています。 数か月前、Integuru という製品が 、そのオープンソース アプローチと斬新な方法論で注目を集めました。その可能性に魅了され、興味深いグラフベースのアプローチと、ネットワーク要求を推論する AI エージェントの統合に惹かれて、試してみることにしました。自動化の時間とコストを大幅に削減できるという期待から、検討する価値のある魅力的な選択肢となりました。 Hackernews で発表され Integuru の 比較的新しいものですが、将来性があります。その核となるのは、タスクの実行中にすべてのネットワーク トラフィックと Cookie を Chromium に記録することです。次に、リクエストのグラフ表現を作成し、どのページがどのエンドポイントを呼び出すかをマッピングします。このグラフを使用してトラバーサルを実行し、それを LLM に渡して、同じリクエストを再生する各ノードのコードを生成し、必要に応じて動的パラメータ (「Bike Production Company」など) を挿入し、依存関係に基づいてそれらを組み合わせます。このアプローチにより、理論的には自動化プロセスが大幅に合理化される可能性があります。 リポジトリは しかし、実際には、主にコンテキスト ウィンドウの制限により、このユース ケースではうまく機能しませんでした。フローが長すぎて、LLM が効果的に処理できなかった可能性があります。ログイン クッキーを直接埋め込み、ホームページから開始することでプロセスを短縮する試みも成功しませんでした。低レベルの OpenAI API キーがこれらの問題の一因になっていると思われますが、Integuru がまだ初期段階であることは明らかです。可能性はありますが、製品にはさらなる改良が必要です。デモ (Robinhood から税務書類をダウンロードするなど) は、よりシンプルなフローを備えた最新の Web フレームワークで最もうまく機能しました。Salesforce は、複雑なフロントエンドと迷路のようなカスタム オブジェクトにより、エラーが発生しました。 とはいえ、この方法はまだ万能なソリューションではありません。すべてのステップを記録する必要があるため柔軟性が制限され、特定のフローのコードを事前に生成するという、10 年前に人気があったルールベースの RPA ツールを彷彿とさせる、より静的なアプローチに傾いています。これは根本的な制限を浮き彫りにしています。ネットワーク リクエストに AI 推論を追加することはエキサイティングで、API を持たないシステムとの統合への扉を開く可能性がありますが、エンタープライズ環境の動的で多様なワークフローよりも、より制御されたタスクや繰り返しのタスクに適しています。 AgentForce: Salesforce のネイティブ ソリューション Salesforce における AI 駆動型自動化について語るなら、Salesforce エコシステム内に「エージェント」を構築するという Marc Benioff 氏の大きな賭けである について触れずにはいられません。開発者中心でさまざまなシステムにわたるワークフローの自動化を目的とする、上記でテストした他のソリューションとは異なり、AgentForce は Salesforce 専用のローコードの組み込みソリューションとして位置付けられています。多くのコンポーネントをパッケージ化し、Salesforce プラットフォーム内のフロー全体に焦点を当てています。 AgentForce アイデアは、Salesforce に完全に常駐し、カスタマイズに基づいて構築されるエージェントを作成することです。ユーザーは、エージェントの一般的な説明を定義し、トピックを割り当て、コードまたは Salesforce UI で定義された事前構築されたフローである関連アクションをリンクします。次に、エージェントが機能できるように、権限、ユーザー ロール、および指示が設定されます。この概念により、理論的には、企業は既存の Salesforce データとワークフローを活用して、大規模なコーディングなしで自動化を推進できます。 AgentForce を eBikes の再販業者の注文例で直接テストしたかったのですが、残念ながら無料の開発者アカウントでは利用できない Einstein (AI 機能) へのアクセスが必要です。代わりに、架空の「Coral Beach Resort」アプリで 30 分間のプレイグラウンドを探索しました。テスト タスクは、エージェントを設定して予約の作成を自動化することでした。これは、eBikes シナリオの再販業者の注文に多少類似したプロセスです。 セットアップは非常に複雑で、権限の定義、トピックの有効化、事前構築されたアクションへの接続、データ フィールドのマッピング、指示の明確化など、複数の手順が必要でした。ローコード ソリューションとして販売されていましたが、Salesforce の複雑さに関する十分な知識が必要であることが明らかになりました。会社の Salesforce インスタンスに、十分に文書化されたカスタム フィールドと事前構成されたアクション フローがない場合、初期の負担は相当なものになる可能性があります。現実的には、ほとんどの企業は、これらのエージェントを完全に実装して最適化するために、システム インテグレーターまたはコンサルタントを導入する必要があるでしょう。 AgentForce のルールベースの性質も際立っていました。自動化が正確に機能するためには、ユーザーはどのフィールドが入力されるか、または渡されるかを注意深くマッピングする必要があり、一部の AI 駆動型プラットフォームよりも実践的な作業が必要になります。このアプローチは精度を保証しますが、Salesforce の強力な専門知識と既存のインフラストラクチャへの依存を強化します。 AgentForce は Salesforce のエコシステムに限定されていますが、これには利点と欠点の両方があります。一方では、認証、ユーザー権限、ツール定義、オーケストレーション ロジックを単一のプラットフォームに統合するパッケージ ソリューションです。他方では、多くのエンタープライズ ワークフローは複数のシステムにまたがっており、AgentForce のサイロ化された性質により、より広範な自動化ニーズへの適用が制限されます。Marc Benioff は、何百もの顧客がすでに AgentForce を使用する契約を結んでいると述べているため、その進化は注目に値します。 それで…もう着きましたか? これらの実験から、現在の AI エージェント ソリューションは、複数のステップから成るタスクについて適切に推論し、計画を立てることができることは明らかです。本当の課題は、これらのシステムが実際にどのように動作するかについての部族の知識を持つ、乱雑な現実世界の環境での実行です。グラフィカル UI は人間の対話のために構築されており、各企業のカスタム ロジックは複雑性の小さなブラック ホールのようなものです。ヘッドレス アプローチのために GUI を省略したり、バックエンド API をリバース エンジニアリングしたりした場合でも、エッジ ケース、認証のハードル、レート制限、または LLM の最高の機能を妨げる動的ワークフローに直面します。 残る課題は主にエンジニアリングの問題です。堅牢なツールの構築、エンタープライズ システムとの緊密な統合、ガードレールの確立、信頼性の高い監視およびオーケストレーション フレームワークの作成などです。これらは、専念した努力と専門化によって解決できます。今日の LLM は、1 年前に利用可能だったものよりもはるかに優れた推論機能をすでに発揮しており、コストは急速に低下しています。今後は、これらの機能を効果的に展開するために必要なインフラストラクチャとプロセスの構築に重点を移す必要があります。 しかし、こうした困難が、着実に進んでいる進歩を覆い隠すようなことはあってはなりません。すでに、制御されたドメインで高い精度を実現できる、専門的で垂直に焦点を絞った AI 自動化 (SDR やカスタマー サポート エージェントなど) が生まれています。こうした単回使用の自動化が成熟するにつれて、それらが連鎖してより広範なワークフローに組み入れられるようになるかもしれません。最終的には、単一の汎用エージェントですべてを行うのではなく、複数の専門エージェントを組み合わせることで、大企業におけるエンドツーエンドの自動化を実現することになるかもしれません。現時点では、ゼロからエージェントを構築することの ROI は、最もボリュームの多いタスク以外では採算が取れないかもしれません。 専門化と今後の道 これらのテストから得られた教訓の 1 つは、特化の重要性です。単一のドメイン (NetSuite での請求書作成など) でほぼ完璧な信頼性を実現するには、大幅な微調整が必要です。1 つの専門ワークフローに重点を置くスタートアップや社内チームは、幅広い汎用ソリューションよりも優れたエクスペリエンスを提供できます。私たちはすでに、財務、物流、人事、サプライ チェーンのターゲット タスクに取り組む「垂直エージェント」の波を目にしています。各エージェントは、必要に応じて UI 自動化と可能な場合は直接 API 呼び出しを組み合わせ、ドメイン固有のフォールバック ロジックとガードレールを組み込むなど、深く統合されます。 大きな疑問が残ります。2025 年は本当にこれらのエージェントが主流になる年になるのでしょうか、それとももっと長い道のりになるのでしょうか。テクノロジーは急速に進歩しており、楽観的な見方が広がっています。しかし、コード生成が改善されてもソフトウェア エンジニアがいなくなったわけではないのと同じように、すべてのプロセスで「ハンズフリー」のエンタープライズ自動化が実現することはおそらくないでしょう。代わりに、専門分野で反復的な改善が行われ、最終的には部分的な自動化のモザイクとしてそれらが組み合わされるでしょう。 結論 自律型 AI エージェントの概念は、特に反復的なタスクが大量にある企業環境では、間違いなく魅力的です。時間の節約、エラーの削減、従業員がより創造的で戦略的な仕事に集中できるようにするなど、潜在的なメリットは莫大です。ただし、AI エージェントの基礎的な機能は強力ですが、広く採用されるかどうかは、基礎研究の推進に加えて、エンジニアリングの課題を克服できるかどうかにかかっています。 鍵となるのは、適切なインフラストラクチャを構築することです。堅牢なツール、信頼性の高い統合、明確に定義されたガードレールとオーケストレーション レイヤーを備えたドメイン固有のソリューションが必要です。現実のエンタープライズ システムの複雑さには、専門的なソリューションが必要です。ここで垂直エージェントが優れたパフォーマンスを発揮します。明確に定義された狭いワークフローに集中することで、チームはソリューションを高い精度と信頼性にまで改良し、各ドメイン固有の課題に対処できます。時間の経過とともに、これらの専門エージェントが相互接続され、より広範な自動化ネットワークが構築される可能性があります。 2025 年には、目覚ましい進歩とパイロット プログラムの増加がもたらされるでしょう。自動操縦で動く世界ではなく、特定の問題に取り組む、ターゲットを絞った非常に効果的な自動化が見られるようになるでしょう。完全なエンタープライズ自動化への道のりは、専門化とコラボレーションによって反復的なものになります。勢いは高まっており、これらのエンジニアリングの課題を解決することで、エンタープライズ イノベーションの次の波への道が開かれます。 (特集画像提供：DALL-E)