インタビュー
Randall Newman、CPTO兼Satisfi Labs共同創業者 – インタビューシリーズ

Randall Newman、CPTO兼Satisfi Labs共同創業者は、AIプラットフォーム、フィンテック、ハイパフォーマンスシステムの構築に豊富な経験を持つテクノロジーおよびプロダクトリーダーです。Satisfi Labsを共同設立して以来、Newmanは同社の会話型AI技術の構想、設計、スケーリングの中心的役割を果たし、プロダクト開発、アーキテクチャ、エンジニアリングチーム、戦略的統合を統括しています。Satisfi Labsに入る前は、Satisfi Inc.でプロダクト部門の責任者を務め、モバイルマーケティング会社Right On Mobileを共同設立しました。キャリアの初期には、CIBC World Marketsで17年以上勤務し、戦略的リスク、高頻度取引、株式裁定といったシニアリーダーシップ役割を担い、定量取引の専門知識とハンズオンの技術開発を組み合わせました。
Satisfi Labsは、スポーツ、エンターテイメント、観光、アトラクション、その他のライブ体験ビジネス向けに特化したAIエージェントの展開に注力するAI企業です。2016年に設立され、会話型AIとそのAnswer Engineから、顧客サポートの自動化、チケット・コマースコンバージョンの向上、顧客会話からのインサイト抽出を支援するエージェントプラットフォームへと進化しました。そのAIエージェントは50以上の言語で動作し、チケット販売、CRM、コンテンツ管理、その他の業務システムと連携して、チケット販売、会話のヒューマンスタッフへのエスカレーション、顧客情報の収集、パーソナライズされた応答の提供などのアクションを実行します。Satisfi Labsによれば、同社の技術は現在、Ticketmaster、Simpleview、MappedIn、Ventrata、Vozziなどの企業と提携・統合され、775以上のブランドに信頼されています。
あなたはCIBCで低遅延取引システムの構築や高頻度取引戦略のリーダーを務めるなど、金融市場でほぼ20年を過ごした後、テクノロジー起業へ転向し、最終的にSatisfi Labsを共同設立しました。スピード、信頼性、リスク管理が重要だったオペレーティングシステムから得た教訓のうち、現在のプロダクショングレードAIエージェントの構築に最も影響を与えているものは何ですか?
取引から学んだことは、良いアイデアと良いビジネスは別物だということです。機会を正しく見極めても、実行が遅い、コストが高すぎる、リスク前提が誤っているなどの理由で損失を出すことがあります。AIも同様です。モデルの能力は一つの入力に過ぎません。ビジネスは、その能力を許容できるコストとリスクで再現可能な成果に転換できるかどうかに左右されます。
インデックス裁定ブックを運用すると、個々の判断だけでなく全体を見ることを学びます。小さなエラーがポートフォリオ全体に繰り返されると、非常に大きなエクスポージャーになります。AIでは、数千のエージェントが個別には妥当な判断を下していても、集合的に問題を引き起こすことがあります。すべてが同じ不良データに依存するか、同じ失敗したサービスを再試行しているのです。個々の応答だけでなく、システム全体を管理しなければなりません。
そして、スピードは結果を改善するときにのみ意味があります。取引ではマイクロ秒が重要になる瞬間がありました。AIにおいては、誤った結果を即座に出すよりも、取引を確認するためにあと1秒かける方が良いと考えています。重要なのは、スピードが価値を生む場面と、単にミスを加速させるだけの場面を見極めることです。
最後の教訓は、事業全体を始めた根本的なものです。優位性は、他の誰よりも早く価格の誤りを見つけることから生まれます。現在の誤価格は、多くの企業がAIエージェントをサポートコスト削減の手段と見なしている点だと考えています。Satisfi Labsでは、これらを収益チャネルと捉えています。当社のスポーツ会場では、エージェントとの会話の約40%がチケットに関するものです。これらのファンは不満を言いに来るのではなく、手に現金を持って座席を尋ねに来ます。市場が価格を誤っているものを見つけ、それを獲得するのです。これは裁定取引と同じ本能です。
Satisfi Labsは2017年に設立され、現在の生成AIブーム以前から存在し、コンテキスト自然言語処理と会話型AIからエージェントプラットフォームへと進化してきました。質問に答えることを主目的としたシステムから、ユーザーに代わって行動できるエージェントへ移行するために必要だった最大のアーキテクチャ変更は何でしたか?
私たちは10年間で、MLB/NFLチーム、エンターテイメント会場、観光組織など800以上の企業クライアント向けに数千のAIエージェントを構築してきました。最大の変化は、システムに情報だけでなく権限を与えるようになったことです。
アシスタントが利用可能なチケットを教えてくれる場合、それは単に回答を提供しているだけです。チケットを交換すると、在庫や顧客記録、場合によっては金銭が変更されます。したがって、誰がその操作を承認したのか、実際に何が起きたのか、プロセスが途中で停止した場合にどう回復するかを把握する必要があります。
そこで、モデルの判断と実行権限を分離します。モデルはリクエストを解釈し、次のステップを提案できますが、その下にあるシステムが権限、ビジネスルール、取引限度額を強制します。モデルからの説得的な説明であっても、これらの制御を上書きすることはできません。
また、”エージェントがタスクを完了したと言った”ことと”ビジネスシステムが完了を確認した”ことを厳密に区別する必要があります。これらは同じではありません。購入リクエストがタイムアウトした場合、再試行する前に購入が実際に完了したかどうかを確認した方がよいでしょう。
戦略的に見ても、より優れたモデルがビジネスコントロールを再構築させるべきではありません。新しいモデルがリリースされるたびにシステムが許可される範囲を再交渉することなく、推論のあらゆる改善を活用したいと考えています。
「エージェント的AI」という用語は現在、幅広い製品に適用されています。エンジニアリングの観点から、先進的なチャットボット、AIコパイロット、そして真に自律的なAIエージェントの境界線はどこに引くべきでしょうか?
私が一つだけ質問するとすれば、本人が実際に委譲した責任は何か、ということです。
チャットボットは情報を提供します。コパイロットは作業の実行を支援しますが、重要なステップは依然としてユーザーが指示し承認します。自律エージェントは、目的を追求しながらそのうちのいくつかの決定を自ら行う権限を持ちます。
インターフェースだけではどれを見ているのかは分かりません。会話型製品の背後には実際の自律性があることもあります。エージェントとして販売されていても、すべての有用なアクションに対して人間の承認が必要な場合があります。
エンタープライズにおいて、自律性は具体的な合意であるべきです。すなわち、システムが特定のユーザーに対し、特定の範囲内でこれらの操作を実行でき、これらの条件下で停止しなければならない、という合意です。これは実際にテストし、管理できるものです。
また、最大限の自律性を目標にすべきではありません。時には、最良の製品はタイミングの良い一つの質問を投げかけ、残りを処理します。その質問を省くとデモはより印象的になりますが、ビジネスの安全性は低下します。目的は不要な人間の作業を排除することであり、必要な人間の判断を排除することではありません。
Satisfi Labsは最近、前線に配置されたエンジニアリング実践であるSatisfi Forwardを立ち上げました。能力のあるAIプラットフォームを構築することと、顧客の実環境でエージェントが確実に動作させることの間にどのようなギャップを感じ、それがこのモデルを作るきっかけとなったのでしょうか?
最後の工程がボトルネックになりつつありました。プラットフォームは多くを標準化できますが、すべての顧客の業務が同じように機能するとは限りません。顧客のチケッティングシステムには特定の制限があり、承認プロセスは3つの部門を通ります。適格リードの定義も次の顧客とは異なります。これらの細部が、導入が実際に有用かどうかを左右します。
既製のプラットフォームを購入し、印象的なデモを組み立てることは可能です。しかし、実際のユーザー向けに堅牢な体験として商用化するのは別問題です。そこで前線に配置されたエンジニアが活躍します。Satisfi Forwardのチームの仕事は、成果を理解し、何が障壁となっているかを特定し、プラットフォーム上にそれを実現するワークフローと統合を構築することです。
しかし、私たちはすべての案件に明確な境界線を設けています。構築に入る前に、成功の定義、ビジネスプロセスの所有者、顧客に依存する部分、そしてローンチ後の保守担当者を合意します。そうしなければ、最後の工程のプロジェクトは無制限の義務となります。また、コードが納品された時点で案件は完了ではありません。顧客の運用でワークフローが機能し、誰かがそれを維持する責任を持つ時点で完了となります。
コードの製作コストも大幅に下がっており、このモデルは以前に比べてはるかに実用的になっています。ただし、私はSatisfi ForwardをSaaS製品に付随するサービス部門と見なしていません。各案件から次に開発すべき製品が何かを学びます。3社の顧客が同じワークフローを求めるとき、それはサポート負担ではなく、支払顧客が付随したロードマップそのものです。従来のSaaSモデルは機能を推測し、証拠を待っていましたが、私たちはまず証拠を得て、その過程で収益も得ます。これがAI時代におけるプロダクト企業の構築方法だと考えています。
エージェントはチケッティングシステム、顧客関係管理プラットフォーム、コンテンツ管理システム、その他のリアルタイム情報源と接続できます。エージェントが取引やアクションのトリガー機能を獲得するにつれ、リアルタイムデータへのアクセスと低レイテンシーを、根拠付け・セキュリティ・誤ったアクションへの防御策とどのようにバランスさせますか?
まず、速度でセキュリティ上の失敗を補ってはなりません。いくつかの要件は制約です。その中で最適化します。
次に、作業の種類を区別します。駐車に関する質問への回答とチケット購入の完了では、データの鮮度や制御が同じである必要はありません。安定した情報はキャッシュできます。金銭のやり取りが発生する場合は、価格・在庫・完了を確認する権威ある取引システムが必要です。
危険なのは、システムが何が起きたか分からないケースです。バックエンドが購入を受け付けても、応答が届かないことがあります。エージェントが失敗と判断して再試行すると、購入が二重に行われます。これは言語の問題ではなく、取引回復の問題です。
そして、実際に重要な条件下で体験を測定します。静かな火曜日の平均レイテンシーではほとんど何も分かりません。イベントが雨天中止になると、突然何千人もの人が一斉にチケットの扱いを尋ねます。1分あたりの平均トラフィックだけで計画すると、その突発的な需要に対応できる容量を見逃します。私はこのことを取引システムから直接学びました。
ここにもコストに関する判断があります。すべてのリクエストが最も高価なモデルやエージェントの連鎖を必要とするわけではありません。要件を満たす最もシンプルな経路を使用し、意思決定に実質的に効果をもたらす部分にだけ余分な時間や計算リソースを費やしてください。ユーザーは正直な結果を得るべきであり、確認できなかったことについても正直に伝える必要があります。
Satisfi Labs は、専門エージェントが AI ワークフォースとして協働できるモデルを説明しています。特にルーティング、共有コンテキスト、意思決定の衝突、どのエージェントが行動すべきかを決定する際に、複数の専門エージェントをオーケストレーションする上で最も難しい技術的課題は何ですか?
最も難しい点は、作業を分散させる際に責任の所在を保つことです。
まず、別のエージェントが本当に必要かどうかを問いかけてください。時には専門家が必要です。時には単なるツール呼び出しやシンプルなワークフローで十分です。追加するエージェントはすべて、リクエストの別解釈、別の依存関係、別のエラー発生箇所となります。そして、裏で動くエージェントの数はユーザーに見えないようにすべきです。
複数のエージェントが正当化される場合、インタラクションを所有するエージェントは一つにしたいです。専門家は情報提供や限定的な作業を行えます。チケットエージェントは在庫と交換を管理し、カスタマーサービスエージェントはポリシーを扱います。しかし、結果を統合し、ユーザーが本当に求めていたものを得たかどうかを判断するのは誰かが行う必要があります。
ルーティングが難しいのは、人々が質問をきれいなカテゴリに分けて尋ねないからです。ひとつのリクエストが三つのエージェントに関わることもあります。システムは次のことを判断しなければなりません:一つのエージェントで処理できるか、複数を順番に実行する必要があるか、あるいは何かを実行する前にユーザーにもう一つ質問すべきか。
コンテキストも同様です。すべてをすべてのエージェントに送るわけにはいきません。そうすると遅延が増え、ノイズが生じ、エージェントが不要な情報にアクセスしてしまう恐れがあります。また、エージェントの仮定が次のエージェントに渡されただけで事実になるべきではありません。
二つのエージェントが意見が合わない場合、どちらかがより説得力を持つまで議論させたくありません。明確な権限モデルが必要です。チケットシステムが可用性を確立し、ビジネスが交換ポリシーを定めます。リアルタイムデータはキャッシュデータに勝ち、ビジネスルールはモデルの判断に勝ち、なお解決できない場合はユーザーに尋ねるか人間を介入させます。難しいのはエージェント同士を会話させることではなく、どのエージェントが何を行い、責任がどこにあったかを正確に再構築できることです。
Satisfi Labs は、会話量といった指標ではなく、エージェントを目標やビジネス成果に対して測定することにますます注力しています。企業は AI エージェントのパフォーマンスを適切に評価するために実際に何を測定すべきでしょうか?また、エージェントにより大きな自律性を与える前に信頼性をどのように評価すべきでしょうか?
まずビジネス成果から始め、次にその成果のうちエージェントが実際にどれだけ貢献したかを問います。
エージェントと会話した後に誰かがチケットを購入したからといって、必ずしもエージェントが販売を生み出したとは限りません。購入は別の理由で行われた可能性もあります。可能な限り、単なる最後のインタラクションへのクレジットではなく、統制された比較や信頼できるベースラインを用意したいものです。チケット販売クライアントの場合、測定すべきはファンが実際に座席を確保できたかどうかであり、エージェントが礼儀正しく応答したかどうかではありません。会場がチケット窓口での列を短縮しようとする場合は、誰も列に並ぶ前にエージェントがどれだけ問題を解決したかを測定することになります。
次に、成功した結果の経済性を検討します:モデルコスト、インフラストラクチャ、人間によるレビュー、エスカレーション、そしてミス修正のコストです。作業を修正する人員を考慮しないと安価に見えるエージェントは実際には安くありません。
信頼性には独自のスコアカードが必要です。完了率、正確性、無許可の操作、障害からの回復、エスカレーションの質などです。重大なプライバシーインシデントを良好なコンバージョン率に平均化してはいけません。
より大きな自律性を与える場合、委任される特定の行動クラスに関する証拠が必要です。テストし、監督下で観察し、制限内で拡大し、停止手段を確保してください。全体的な高精度スコアだけでは、システムがすべての取引に対応できることを証明しません。また、インセンティブに注意が必要です。時には人間を介入させることが正しい結果です。エージェントにハンドオフ回避だけを報酬として与えると、エスカレーションすべき問題を保持し続けることに驚かないでください。
最近、音声 AI は測定可能な成果に基づいて設計すべきであり、既存のチャットボットの別インターフェースとして扱うべきではないと主張しました。スタジアム、アトラクション、ライブイベントなどの環境で、音声エージェントが複雑でリアルタイムなインタラクションの主要インターフェースになるために、まだ必要とされる技術的ブレークスルーは何ですか?
多くのクライアントが「チャットアプリに音声をプラグインすればいいのでは?」と尋ねます。実際に可能です。しかし、それが良い体験になるとは限りません。次の本当の改善点は、より人間らしい声ではなく、人々が実際に使用する条件下でも機能し続けるインタラクションです。
スタジアムでは、観客の騒音の中で誰かが話し、なじみのない選手名を使い、途中で考えを変え、ゲートが開く前に購入を完了しようとします。システムは中断や不確実性、バックエンドの遅延に対応しながら、タスクを失わずに処理しなければなりません。
重要な詳細に特に注意してください。カジュアルなフレーズを聞き間違えるのは一つの問題ですが、チケットの枚数やイベントの日付を聞き間違えるのは別の問題です。エージェントは、会話全体を退屈にしないように、行動の結果に影響を与える詳細を確認する必要があります。
音声にすべてを任せさせるべきではありません。20種類の座席オプションを比較する場合は、画面上で行う方が適しています。ある人は最初に入力し、車に乗り、会話を音声で続けたいと思うかもしれません。システムはその文脈を保持し、音声、テキスト、ビジュアルを状況に最適な形で活用すべきです。
このうちのいくつかは、より優れたモデルが必要です。多くは、より良い統合とインタラクションデザインが求められます。テキスト中心に設計され、音声で読み上げるというワークフローは、ブレークスルーを待つだけでは解決しません。進捗を評価する一つの基準は、実際の条件下で、ユーザーがより少ない労力で正確にタスクを完了できるかどうかです。
エージェントが情報提供からチケット販売、顧客データの収集、体験のパーソナライズ、そして業務システムとの連携へと役割を拡大する中で、企業はどの意思決定をエージェントが自律的に行えるべきか、どの意思決定は常に人間の監督が必要かをどのように判断すべきでしょうか?
これはリスク管理です。もし事態がうまくいかなくなった場合、どれほどの被害が生じ得るでしょうか?エージェントが閉められない扉を開けてしまうのでしょうか?
可逆性は有用な第一のテストですが、総露出も考慮すべきです。1件の返金は小額で可逆的かもしれませんが、誰も気付かないうちに1万件の誤った返金が行われるのは別問題です。個々のアクションとシステム全体の累積活動に対して制限を設ける必要があります。
もしアクションが低リスクで可逆的であれば、より多くの自律性を付与します。たとえば、設定の更新、注文の確認、アイテムの確保などです。結果の重大性が増すにつれて、確認や承認を追加します。購入では顧客に価格の確認を求める必要があるかもしれません。大規模な返金では従業員の承認が必要です。安全上の脅威は直ちにエスカレーションされます。そして、ある決定は人間が最終的に行うべきです。
なお、顧客の同意と会社の承認は別物です。顧客が購入を確認したからといって、エージェントが会社のポリシーを回避する権限が与えられるわけではありません。従業員が例外を承認したからといって、顧客が料金に同意したことになるわけでもありません。
制限は、アクションを実行するシステムによって強制されるべきであり、単にプロンプトで記述するだけでは不十分です。エージェントに広範なアクセス権を与えておき、注意を促すプロンプトに頼るべきではありません。また、人が必要な場合は、十分な文脈を提供して実際の判断ができるようにすべきです。情報なしに何百もの承認を誰かに任せれば、監視ではなくゴムスタンプを作ったことになります。意味のあるリスクを減らす箇所に人間の注意を集中させましょう。すべてのやり取りに薄く広げてはいけません。
今後、Model Context Protocol やエージェント間コミュニケーションといった技術が、エンタープライズ AI システムの構築方法を根本的に変え、孤立したエージェントから、エージェントがツールを発見し、コンテキストを交換し、企業やプラットフォームを跨いで行動を調整できるエコシステムへと移行させると予想しますか?
プロトコルは目的達成の手段だと考えています。MCP は AI アプリケーションにツールとコンテキストへの共通アクセス手段を提供します。エージェント間プロトコルはエージェント同士の協調を実現します。これは価値があります。エージェントがツールを必要とするたびにカスタム統合を構築する必要はありません。これは API がソフトウェア統合に果たした役割に似ています。
しかし、共通フォーマットがあるからといって、2 社がアクションの意味や誰が承認できるか、失敗時の処理について合意しているわけではありません。エージェントがツールを発見できても、使用を許可すべきとは限りません。身元、権限、信頼、責任を依然として検討する必要があります。あるエージェントが別のエージェントに何かを依頼し、問題が生じた場合、その決定の所有者は誰になるのでしょうか?
実際に変わるのは次の点だと考えます。現在、会場はウェブサイトとアプリを持っていますが、数年後には他のエージェントと交渉できるエージェントが登場します。ファンのパーソナルアシスタントが、会場のエージェントに特定の価格帯で2席と駐車パスを求め、取引全体が両エージェント間で完了します。適切な機能を見つけることは比較的容易ですが、顧客の支出権限を把握し、合計価格を確認し、チケットは成功したが駐車が失敗した場合の処理などが実際の課題です。
エージェントを運用しただけで顧客との関係が自動的に得られるとは考えていません。その関係は獲得しなければなりません。また、会場がこれらの取引を検索会社やチケットマーケットプレイスに委ねるとは思いません。Satisfi Labs の目標は、そのエコノミーで会場を代表するエージェントになることであり、企業が自社名を付けられるほど信頼できる存在です。信頼性、権限管理、責任追及に関して構築したすべてが、その座を獲得する要因です。
素晴らしいインタビューをありがとうございました。さらに詳しく知りたい読者は Satisfi Labs をご訪問ください。












