AIエージェントをデモだけでなく、本番環境で確実に機能させることは、企業が想定していたよりも難しいことが分かってきています。データが断片化していること、不明確なワークフロー、そしてエスカレーション率の暴走が、業界全体での導入を遅らせています。
Greyhound ResearchのチーフアナリストであるSanchit Vir Gogia氏は、「技術そのものは、デモではしばしばうまく動きます。問題は、それが実在する組織の複雑さの中で運用するよう求められたときに始まります。」と述べました。
Creatioでエージェント導入を統括するBurley Kawasaki氏とチームは、3つの領域を軸にした手法を開発しました。データレイクの遅延を回避するためのデータバーチャライゼーション、マネジメント層としてのエージェントダッシュボードとKPI、そして高い自律性へ向けて推進するための、厳密に境界づけられたユースケースのループです。
より単純なユースケースでは、Kawasaki氏はこれらの実践によって、エージェントが自力で最大80〜90%のタスクを処理できるようになったと語ります。さらに調整すれば、より複雑な導入環境であっても、少なくとも半数のユースケースで自律的な解決を支えられる可能性があると見積もっています。
「人々はポジ概念実証（POC）をめちゃくちゃたくさん試してきました。非常に多くのテストを実施しています」と、Kawasaki氏はVentureBeatに語りました。「しかし2026年になって、私たちは、運用効率を生むか、追加の収益につながるような、ミッションクリティカルなワークフローに焦点を当て始めています。」
なぜエージェントは本番で失敗し続けるのか
企業は、ある形でエージェント型AIを導入したいと熱望しています。多くの場合、現実の具体的なユースケースを特定する前から「置いていかれたくない」という不安が背景にありますが、データアーキテクチャ、統合、監視、セキュリティ、そしてワークフロー設計をめぐる重大なボトルネックに直面します。
最初の障害はほぼ必ずデータに関係している、とGogia氏は言います。企業の情報は、きれいに整理された形でも統一された形でも存在することがほとんどありません。SaaSプラットフォーム、アプリ、社内のデータベース、その他のデータストアに分散しています。中には構造化されているものもあれば、そうでないものもあります。
しかし、データ取得の問題を企業が乗り越えたとしても、統合は大きな課題です。エージェントは、アプリケーションとやり取りするためにAPIや自動化のフックに依存しますが、この種の自律的なやり取りが現実になるずっと前に、多くの企業システムは設計されていた、とGogia氏は指摘しました。
その結果、不完全または一貫性のないAPIが生じたり、プログラムからアクセスしたときにシステムが予測不能な挙動を返したりすることがあります。またGogia氏は、正式に定義されていないプロセスを自動化しようとすると、組織はつまずくことがあるとも述べました。
「多くのビジネス・ワークフローは、暗黙知に依存しています」と彼は言います。つまり、従業員は明確な指示なしでも、過去に見た例外をどう処理すればよいかを知っている、ということです。しかし、その欠けているルールや指示は、ワークフローを自動化ロジックへと翻訳した瞬間、驚くほどはっきりと見えてきます。
調整（チューニング）のループ
Creatioは「明確なガードレールのある範囲に限定して」エージェントを導入し、その後「明示的な」調整・検証フェーズを行う、とKawasaki氏は説明します。チームは最初の成果を見直し、必要に応じて調整し、その後、許容できる精度に到達するまで再テストします。
そのループは通常、次のパターンに従います：
設計時の調整（本番稼働前）： プロンプトエンジニアリング、コンテキストのラッピング、ロール定義、ワークフロー設計、そしてデータやドキュメントに基づくグラウンディングによって、パフォーマンスを改善します。
人が介在する修正（実行中）： 開発者が承認し、編集し、あるいは例外を解決します。人間が最も介入しなければならない場合（エスカレーションや承認）、ユーザーはより強いルールを設定し、より多くのコンテキストを提供し、ワークフロー手順を更新します。あるいは、ツールへのアクセスを絞ります。
継続的な最適化（本番稼働後）： 開発者は例外率や結果を引き続き監視し、必要に応じて繰り返し調整します。時間の経過とともに、精度と自律性の向上につながります。
Kawasaki氏のチームは、リトリーバル（検索）強化型生成を適用し、エージェントを企業のナレッジベース、CRMデータ、その他の独自ソースにグラウンディングします。
エージェントが実運用に投入された後は、ダッシュボードで監視します。パフォーマンスの分析、コンバージョンに関する洞察、監査可能性（監査証跡）を提供します。つまりエージェントは、デジタルワーカーのように扱われます。ダッシュボードとKPIを備えた独自のマネジメント層が存在します。
たとえばオンボーディング・エージェントは、エージェントの監視とテレメトリを行うための標準的なダッシュボードのインターフェースとして組み込まれます。これは、オーケストレーション、ガバナンス、セキュリティ、ワークフロー実行、監視、そしてUIへの埋め込みといった、プラットフォーム層——「LLMの上に位置する」——の一部だとKawasaki氏は述べました。
ユーザーは、稼働中のエージェントの一覧と、それぞれのプロセス、ワークフロー、実行結果を見ることができます。さらに、個別のレコード（紹介や更新など）に「掘り下げ」（ドリルダウン）すると、ステップごとの実行ログと関連するコミュニケーションが表示され、追跡性、デバッグ、そしてエージェントの微調整を支援します。最もよく行われる調整は、ロジックとインセンティブ、ビジネスルール、プロンプトのコンテキスト、そしてツールへのアクセスだとKawasaki氏は語っています。
導入後に表面化しやすい最大の課題は以下です：
例外処理の量が多くなり得る： ガードレールとワークフローが調整されるまで、エッジケースの初期の急増が起こりがちです。
データ品質と完全性： 欠けている、または一貫性のないフィールドやドキュメントがあるとエスカレーションの原因になります。チームは、グラウンディングのために優先すべきデータと、自動化すべきチェックを特定できます。
監査可能性と信頼： 特に規制対象の顧客は、明確なログ、承認、ロールベースのアクセス制御（RBAC）、そして監査証跡を求めます。
「私たちはいつも、エージェントを訓練するための時間を確保する必要があることを説明しています」と、CreatioのCEOであるKatherine Kostereva氏はVentureBeatに語りました。「エージェントをオンに切り替えたらすぐにそうなるわけではなく、完全に理解するための時間が必要で、その後でミスの数が減っていきます。」
"データの準備状況"は、必ずしも大規模な作り直しを意味しない
エージェントを導入しようとするとき、「私のデータは準備できているか？」はよくある初期の問いです。企業はデータアクセスが重要だと理解していますが、大規模なデータ統合プロジェクトによってそれがストップしてしまうこともあります。
しかしバーチャルな接続を使えば、エージェントが基盤となるシステムにアクセスでき、通常のデータレイク／レイクハウス／ウェアハウスの遅延を回避できます。Kawasaki氏のチームは、データと統合するプラットフォームを構築し、現在は、データを仮想オブジェクトに取り込み、処理し、UIやワークフローにおいて標準的なオブジェクトのように使うためのアプローチに取り組んでいます。これにより、DB内で大量のデータを「永続化したり複製したり」する必要がありません。
この手法は、たとえば銀行のように、取引量が単に大きすぎてCRMへコピーできない一方で、「AI解析やトリガーにとっては依然として価値がある」領域で役立つ可能性があるとKawasaki氏は言いました。
統合と仮想オブジェクトが整ったら、チームはデータの完全性、一貫性、利用可能性を評価し、ドキュメントが多い、あるいは非構造化のワークフローのような、導入しやすい出発点を特定できます。
Kawasaki氏は、「実際に基盤となるシステムの中でデータを本当に使うこと」が重要だと強調しました。それは、結局のところ最もきれいなデータ、あるいは情報源としての真実（ソース・オブ・トゥルース）がそこにあることが多いためです。
エージェントを仕事に合わせる
自律型（またはほぼ自律型）のエージェントにとって最適なのは、「明確な構造」と「コントロール可能なリスク」を伴う、高ボリュームのワークフローだとKawasaki氏は述べています。たとえばオンボーディングやローン準備におけるドキュメントの取り込みと検証、あるいは更新や紹介といった標準化されたアウトリーチです。
「特に、業界の中の非常に具体的なプロセスに結びつけられる場合、それこそが、現実に測定でき、強いROIを提供できる場所です」と彼は言いました。
たとえば金融機関は、多くの場合、自然にサイロ化しています。法人向け融資のチームは自分たちの環境で業務を行い、資産運用は別のところで行われます。しかし、自律型エージェントなら、部門をまたいで複数のデータストアを横断し、たとえば資産運用やアドバイザリーサービスの良い候補になり得る法人顧客を特定するといったことができます。
「それは明白な機会のように思えるかもしれませんが、誰もすべてのサイロをまたいで見ていないのです」とカワサキ氏は述べました。このシナリオそのものにエージェントを適用したいくつかの銀行では、「数百万ドル規模の追加収益」といったメリットが見られたと同氏は主張していますが、特定の機関名は挙げていません。
しかし、別のケース——特に規制のある業界——では、より長い文脈を扱えるエージェントが望ましいだけでなく、必要不可欠です。たとえば、複数ステップからなる業務として、システム横断で証拠を集めること、要約すること、比較すること、コミュニケーションを起草すること、そして監査可能な根拠を作成することがあります。
「エージェントは、すぐに回答を返してくるわけではありません」とカワサキ氏は述べました。「完全なエンドツーエンドのタスクを完了するには、数時間、場合によっては数日かかることがあります。」
これは「単一の巨大なプロンプト」ではなく、オーケストレーションされたエージェント型の実行を必要とすると同氏は語りました。このアプローチでは、作業を決定論的なステップに分解し、そのステップをサブエージェントが実行します。メモリと文脈管理は、さまざまなステップや時間間隔にわたって維持できます。RAGによる根拠づけを行うことで、出力を承認済みの情報源に結び付け続けるのに役立ち、またユーザーは、ファイル共有やその他のドキュメントリポジトリへの拡張を指示することができます。
このモデルは通常、カスタムの再学習や新しい基盤モデルを必要としません。企業が使うモデルが何であれ（GPT、Claude、Gemini）、カワサキ氏は、プロンプト、ロール定義、制御されたツール、ワークフロー、データの根拠づけによって性能が向上すると述べました。
フィードバックループでは、「中間チェックポイント」に「より一層の重点」が置かれると同氏は語りました。人間が、中間成果物（要約、抽出された事実、ドラフトの推奨事項など）を確認し、誤りを修正します。それらは、その後、より良いルールや検索（リトリーバル）の情報源、より狭いツールのスコープ、改善されたテンプレートへと変換できます。
「この種の自律エージェントにとって重要なのは、両方の世界の最良を組み合わせることです。すなわち、AIの動的な推論と、真のオーケストレーションによる制御とパワーです」とカワサキ氏は述べました。
最終的に、エージェントには、エンタープライズ・アーキテクチャ全体、新しいオーケストレーションのフレームワーク、明示的なアクセス制御にまたがる協調的な変更が必要になると、ゴギア氏は述べました。エージェントには、特権を制限し、範囲内にとどめるためのアイデンティティを割り当てなければなりません。可観測性（オブザーバビリティ）が重要です。モニタリングツールによって、タスク完了率、エスカレーションの発生、システムとの相互作用、そしてエラーのパターンが記録できます。この種の評価は恒常的な実践であるべきであり、新しいシナリオや想定外の入力に遭遇したときにエージェントがどう反応するかをテストすべきです。
「AIシステムが行動を取れるようになった瞬間に、企業はコパイロットの導入時にはめったに登場しないいくつかの質問に答えなければならなくなります」とゴギア氏は述べました。たとえば次のような点です。エージェントはどのシステムにアクセスしてよいのか？承認なしに実行できるアクションの種類は何か？どの活動は常に人間の判断を必要とするのか？すべてのアクションはどのように記録され、どのようにレビューされるのか？
「その[企業]がこの難しさを過小評価すると、多くの場合、見栄えはするものの実際の運用上の複雑さに耐えられないデモに行き詰まります」とゴギア氏は述べました。
