ロマン・セスティエ (CEO) とギヨーム・ルベデル (CTO)、StackOne の共同創設者 – インタビュー シリーズ

ロマン・セスティエ は、StackOne の共同創設者兼 CEO で、Google (GOOGL ) で $1 億の評価を持つプロダクトを立ち上げ、Yieldify でプロダクトおよびサービスを率い、70 人以上のチームを管理しました。また、ContentSquare の UK オフィスを立ち上げ、A/B テストツールとの統合を指揮しました。彼は、ギヨームと共に、Upper.ai というスタートアップも共同創設しました。

ギヨーム・ルベデル は、StackOne の共同創設者兼 CTO で、Yieldify のエンジニアリング担当 VP でした。ギヨームは、1000 を超える SaaS プロダクトで使用されている数百の統合を率いてきました。また、月に 20 億回以上のヒットがある API を構築・維持してきました。

StackOne は、プライバシーを優先した AI 統合プラットフォームで、B2B SaaS コンパニーや AI エージェントが、数百のエンタープライズ システムを単一の統一 API でリアルタイムに双方向に統合できるように支援します。速度とセキュリティを重視して設計されており、開発者は数週間ではなく数日で統合を提供できます。また、顧客データを保存せずに実現します。

あなたが Google を離れて StackOne を共同創設することを決めたのは何ですか？また、AI または SaaS 統合の空白を感じたのは何ですか？

ロマン: 「統合の痛みは、私のキャリアのすべての段階で感じたものです。初期のスタートアップや Google 内の大規模システムで働いていても、システム間のクリーンな統合に大きな障害に直面しました。そこで、広範囲にわたるシステム的な問題であることを実感しました。LLM の台頭により、統合レイヤーを完全に再構想する新しい機会が生まれました。ギヨームと私は、時期が適切で、市場が解決策を求めていることを明確に認識しました。」

Yieldify でプロダクトおよびサービスを率いたあなたの経験と、Area 120 で行った仕事は、StackOne のプロダクト戦略にどのように影響しましたか？

ロマン: 「Yieldify では、プロダクトとサービスを率いていましたが、ロードマップを実際の収益結果に結び付けることの重要性を学びました。Google では、10 億ドルの収益増加をもたらしたデータ分析プロダクトを立ち上げました。Area 120 では、10 倍のアイデアとスピードを学びました。すべてが StackOne の構築に影響しています。2 週間ごとのスプリント、ボールドなプロダクトベット、大胆な実験、統合の使いやすさとユーザーエクスペリエンスに焦点を当てています。」

StackOne は新しいモデルを構築していません。モデルの間と SaaS システムの間のつなぎを構築しています。このインフラストラクチャ レイヤーは、AI エージェントの成功にとってどれほど重要ですか？

ギヨーム: 「AI エージェントは、頭脳だけでなく手も必要です。モデルが優秀に推論できるとしても、現実世界で正確で安全で高速に行動できないと、制限されます。認証、レート制限、アクセス許可を管理する構造化されたインフラストラクチャ レイヤーがなければ、エージェントは誤った行動をとったり、システムを壊したりします。ほとんどの会社は 100 を超える SaaS ツールを使用しているため、StackOne のようなプラットフォームがなければ、各ツールを個別に接続する必要があります。私たちの役割は、エージェントが必要なツールに安全でスケーラブルなアクセスを提供し、チームがロジックに集中できるようにすることです。」

StackOne の統一 API と AI エージェント アクション プラットフォームの内部動作について説明してください。技術的に難しい点は何ですか？

ギヨーム: 「ドメインごとに 1 つの OpenAPI スペックを定義し、数百の下位エンドポイントにマッピングします。そのスペックは中央で最新の状態を保ち、顧客がバージョン変更を管理する必要がありません。ツール スキーマには、適切な認証スコープが事前に定義されており、エージェントが推測または過剰なアクセスを試みることはありません。最も難しいのは、SaaS データ モデルの正規化です。ツールによっては、カスタム オブジェクトや関係を定義できるため、複雑性が大幅に増加します。私たちのエンジンは、LLM アシスト マッピングによってこれをリアルタイムで処理し、開発者に信頼性の高い実行レイヤーを提供します。」

StackOne のツール呼び出しエンジンは、先進的な LLM の機能よりも高速で正確です。なぜですか？

ギヨーム: 「鍵は構造です。私たちのエンジンは、型付けされた関数シグネチャを提供し、モデルがどの引数を使用するかを正確に知ることができます。内部では、StackOne はツール呼び出しをバッチ処理および並列化し、レート制限を尊重して、可能な限り迅速にリクエストを実行します。さらに、資格情報を中央で管理しているため、ループ内で再認証する必要はありません。これらの最適化は、リアルタイムでエージェントを実行しようとする場合に大きな違いをもたらします。」

StackOne は、特に RAG、ツール使用、またはリアルタイム エージェント実行などの AI 使用例に最適化されていますか？

ギヨーム: 「RAG パイプライン用にデルタのみのエンドポイントを提供し、コンテキスト ウィンドウを短く効率的に保ちます。リアルタイム エージェントの場合、ネイティブ イベントまたはシンセティック イベントのストリーミング統一 Webhook をサポートし、基盤となるツールがイベントを提供しない場合はシンセティック イベントを作成します。さらに、テナントおよびプロジェクト レベルで細粒度のアクセス制御を施行し、複数のエージェントをさまざまなユーザー間で安全にオーケストレーションするために不可欠です。」

内部で統合を構築するチームの最も一般的な誤解は何ですか？StackOne のようなプラットフォームを使用する場合とどう異なりますか？

ロマン: 「大きな誤解の 1 つは、統合が単に API 呼び出しであるということです。初期構築は簡単に見えるかもしれませんが、継続的なメンテナンスはエンジニアリング時間の 20% を消費することがよくあります。チームは、ニッチなコネクターの価値を過小評価することがあります。セキュリティは後回しにされることが多いです。SOC-2 コンプライアンスやテナント分離のようなものは、エンタープライズ顧客にとって交渉の余地がないものです。また、テナントのカスタマイズも、最初は見落とされがちです。新しい顧客ごとに独自のエッジ ケース、構成の癖、またはマッピング ロジックがもたらされ、継続的な複雑性が生じます。」

AI エージェントについては誰でも話していますが、現実世界での展開はまだ初期段階です。大量のエンタープライズ採用を妨げているのは何だと思いますか？また、StackOne はどう対応していますか？

ロマン: 「セキュリティとコンプライアンスが最大のブロッカです。CIO は、エージェントが範囲外で動作したり、監査のギャップを作ったりすることを心配しています。StackOne は、最小特権の OAuth スコープを施行し、テナント レベルのキル スイッチを有効にし、完全な監査証跡を提供することでこれを解決します。リスク チームがそのレベルのコントロールを見ると、ゲートキーパーから積極的なサポーターに変わります。」

SaaS プラットフォームを横断してユーザーの代理で AI エージェントを動作させることの最大の技術的またはセキュリティ上の課題は何ですか？それらをどのように軽減しますか？

ギヨーム: 「トークン スプロールやリフレッシュ サイクルを管理する必要があります。中央の暗号化されたボールトでこれを解決します。データ漏洩を防ぐために、行レベルで決定的なアカウント識別子をツール呼び出しに施行し、LLM によってこれが適切に処理されるようにします。エージェントのドリフトや誤用を防ぐために、ポリシー チェックとレッド チーム テストを継続的に実行します。プラットフォームでは、リンクされたシステムごとに利用可能なアクションをパラメーター化できます。セキュリティは、根本から設計されている必要があります。」

LangChain や CrewAI のようなオープンソース ツールと StackOne のようなプロプライエタリ プラットフォームの将来はどう見えますか？

ギヨーム: 「オープンソースをオーケストレーション レイヤー、StackOne を基盤インフラストラクチャと見ています。LangChain と CrewAI ワークフローに直接プラグインする Python と TypeScript 用の SDK を構築しました。オープンソース ツールをプロトタイピングに、管理されたプラットフォームを本稼働レベルの信頼性に使用するハイブリッド モデルが現れるでしょう。Terraform と AWS を使用するチームのように、両方が必要です。」

素晴らしいインタビュー、詳しく知りたい読者は StackOne を訪問してください。