Stripeは社内AIプラットフォームを構築した

Meet Stripe's Knowledge AI Platform

コーディングエージェントはStripeのエンジニアリングを変革しましたが、Claude CodeやCodexといったAIの波から、営業担当者、財務アナリスト、テクニカルアカウントマネージャーなどの非エンジニアは取り残されていると感じていました。既存のツールでは、Stripeが必要とするデータセキュリティ要件や特定のワークフロー（データウェアハウスのクエリ、営業電話前の顧客調査、インシデントのトリアージ、収益シナリオのモデリング、コンプライアンスレビューの準備など）に対応できませんでした。しかし、Stripeの知識AIプラットフォームが出荷されたことで、すべてが変わりました。

［画像: Stripeの知識AIプラットフォームのインターフェースのスクリーンショット］

4月のローンチからわずか2週間で、Stripeのほとんどの部署がKai（KAI）としても知られるStripeの知識AIプラットフォームを利用するようになりました。現在、GTM（マーケティング、営業、カスタマーサクセスマネージャー、テクニカルアカウントマネージャー）のほぼ全員を含む、83%が週次アクティブユーザーです。ほとんどのKaiセッションは複数回のやり取りを必要とし、ユーザーは内部または外部に共有する前に、深い調査を行ったり、特定の成果物を作成したり、アセットを洗練させたりしています。Kaiにより、Stripeの誰もが日々の業務を支援するために特別に構築されたエージェントを持つことができるようになりました。

なぜ知識AIプラットフォームを構築したのか

コーディングタスクの場合、具体的な変更は様々ですが、タスクを実行するために必要なワークフローとツールはほぼ同じです。ファイルを編集し、テストを実行し、コミットします。プログラミング言語は異なりますが、作業の形状は比較的均一であるため、単一のエージェントアーキテクチャがうまく機能します。知識労働は、そのスペクトルの反対側に位置します。アカウントの調査やコンプライアンスレビューの準備といったタスクには、異なるツール、異なるデータ、異なる出力、そして「完了」の異なる定義が必要です。

Kaiが登場する前、知識労働のためのAIオプションは2つありました。

• NoCode Agent Builder: 誰でもワークフロー固有のエージェントを構築・デプロイでき、ツールを使用できました。このシステムを使用して4,000以上のエージェントが構築されました。しかし、チームが概念的に類似したプロンプトを異なる品質レベルで記述していることにすぐに気づき、これらのマイクロエージェントの拡散を監視・維持することがますます困難になりました。
• コーディングエージェント: コーディングエージェントは強力でしたが、異なるリスクセットをもたらしました。私たちの目標はStripe全体の生産性向上を可能にすることであるため、一部のユーザーはワークフローを変更し、コーディングエージェントを選択しました。しかし、セキュリティ上の懸念が急速に浮上し、これまで非エンジニアをサポートしたことのないコード品質チームに新たなサポート負荷が生じました。

これらの経験から、知識AIプラットフォームを構築するには、3つのことを正しく行う必要があると認識しました。それは、専門知識を集中させることなくスケーリングすること、ユーザーが作業している場所で出会うこと、そしてコードには存在しないガードレールを強制することです。

専門知識を集中させることなくスケーリングする

Stripeのユーザーにサービスを提供するために必要な専門知識の範囲は驚くほど広いです。請求のエスカレーションをトリアージする方法や収益シナリオをモデリングする方法を知っている人々は、中央集権化されておらず、エージェントインフラストラクチャを構築しているチームにはいません。彼らは、それぞれ独自のツール、データソース、ワークフロー、そして「良い」とは何かについての判断を持つ、GTM、財務、マーケティング、法務、データサイエンスなど、数十の専門分野に分散しています。Stripeが事業を展開するすべての製品と国にこれを掛け合わせると、結果は驚くほど複雑になります。Kaiは、その複雑さをタスクがうまくいくように見えなくする形でモデリングする必要があります。

エージェントは roaming する必要がある

エージェントがどこに表示されるかは、それが何を知っているかと同じくらい重要です。誰もがブラウザタブで作業しているわけではなく、ターミナルで作業している人はさらに少ないです。したがって、知識エージェントは単一の製品であってはならず、作業が行われるあらゆる場所に自身を埋め込むことができる柔軟なプラットフォームでなければなりません。

例えば、財務チームがStripeの運営予算の複雑な変更をモデリングするために使用する内部アプリケーションを考えてみてください。エージェントは、アプリケーションから離れることなく、コンテキストを読み取り、関連ドキュメントを調査し、有効な変更を提案し、違いを要約する必要があります。

スタンドアロンのエージェント製品を構築しても機能しません。代わりに、ユーザーを自然なワークフローから新しいアプリに強制することになります。サーフェスごとに個別のエージェント製品を構築しても機能しません。保守が困難になり、複数のツールを使用するユーザーは断片的な体験をすることになります。プラットフォームはユーザーが作業している場所で出会う必要があります。

ガードレールを一から構築する

コーディングエージェントは、数十年にわたる高速で検証可能なガードレールを備えた環境で動作します。コンパイラは無効な構文を拒否し、テストはリグレッションを捕捉し、gitはすべての間違いを元に戻せます。知識労働にはこれらの構造に対するサポートはほとんどありません。

Stripeのコア不変条件を考えてみてください。「単一の分析で、関連性のない2つの顧客コンテキストからのデータを組み合わせるべきではない」。ユーザーはそれぞれ独立して両方のコンテキストに正当なアクセス権を持つかもしれませんが、それらが同じセッションに表示されることは決してありません。分離境界は「この人物が認証トークンに基づいて何にアクセスできるか？」ではなく、「このコンテキストを与えられたこのタスクは何を表示できるか？」です。プラットフォームは、ユーザーが依存するこれらの暗黙的なガードレールを強制する必要があります。

Kaiをどのように構築したか

単一のモノリシックエージェントでは、これらの制約すべてを効果的にエンコードすることはできません。また、すべてのドメインチームに安全でホストされたパフォーマンスの高いエージェントインフラストラクチャを個別に構築するように依頼しても、スケーリングしません。この課題に対処するために、Kaiを3つのレイヤーで構築しました。

• 同じエージェントへの複数のインターフェースを提供するサーフェスに依存しないAPI
• ドメインオーナーが独自のKaiエージェントを構築・管理するAgent Studio
• インフラストラクチャについて誰も考えることなく数秒でセキュリティを提供する実行環境

サーフェスに依存しないAPI

Kaiは意見のあるWebアプリケーションとSlack統合を提供しますが、主なプリミティブはそれら両方を支える基盤となるAPIです。エージェントはアプリケーションではなくサービスであり、サーフェスは単にそれへのカスタマイズされたビューです。

ほとんどのStripe社員は、社内でホストされているWebアプリケーションを通じてKaiを利用しています。セットアップするインフラストラクチャはありません。すべての従業員が初日から利用できます。

任意の内部ツールもKaiを埋め込むことができ、多くのツールがそうしています。例えば、ビジネスインテリジェンスプラットフォームで作業している従業員は、Chrome拡張機能がサードパーティのWebベースツール内でKaiの機能を表示するため、既存のアプリケーション内からKaiに質問できます。

［画像: カスタムアプリケーションがAPI経由でKaiを埋め込み、エージェント体験をすべてのワークフローにもたらす様子］

Agent Studio

Agent Studioはドメインオーナー向けのコントロールプレーンです。チームはこれを使用して、スキル、カスタムKaiエージェント、およびツールの選択を構築、テスト、監視します。例えば、GTMチームは、ワークフローに合わせて調整されたKaiエージェントを所有しています。これはデフォルトでスキルをロードし、データソースに接続し、ユーザーが期待する形式で出力を提示します。Agent Studioは、使用状況データと品質シグナルを各アセットの横に表示するため、ドメインオーナーはプラットフォームチームに問い合わせることなく、何が機能しているかを確認できます。

［画像: アセットはStripe全体で領域に整理され、ドメインエキスパートによって管理されている］

実行環境

［画像: 実行環境のアーキテクチャ図］

これは、プラットフォームの約束を現実にするレイヤーです。エージェントハーネス、サンドボックス、ワークフローオーケストレーション、アクセス制御フレームワークなどのコアプリミティブは、Stripeの製品向けエージェントと意図的に共有されています。内部知識労働は、外部製品と同じ機密データを扱い、同じユーザーにサービスを提供するため、同じセキュリティとコンプライアンス基準が必要です。基盤を共有することで規律が生まれ、フライホイールが作成されます。実行環境の改善は、内部エージェントと製品エージェントの両方に同時に利益をもたらします。

LangChainのdeepagentsを使用して構築されたエージェントハーネスは、Kubernetes上で、セキュアなセッションごとのサンドボックスとマルチテナント仮想ファイルシステムで実行されます。セッション内では、エージェントは成果物を作成・反復処理する仮想ファイルシステムで作業し、分析およびデータ処理にはセキュアなコード実行サンドボックスが使用されます。

これは、長くて複雑なセッション全体で状態を保持するように構築されています。最近のセッションは932ターンに達しました。Kaiの深いタスク管理機能により、単一の会話は、タイムアウトしたりコンテキストウィンドウをオーバーロードしたりすることなく、数百ターン、数百のツールおよびLLM呼び出しで構成できます。これは、知識労働が単一の質問で終わることはめったにないため重要です。それは、それ自体の上に構築される反復的な推論であり、セッションはその状態を低下させることなく保持する必要があります。

［画像: ユーザー行動が変化しており、セッションはますます深いマルチターンコラボレーションに使用されている］

ハーネスの最も興味深い部分の1つは、正しいスキルを選択する方法です。Kaiは、主要な指標を追跡するビジネスインテリジェンスダッシュボードから、内部実行を整理するプロジェクト管理ツール、ZoomやGoogle Workspaceなどのサードパーティサービスまで、さまざまな内部システムにまたがる1,000以上のスキルとツールに接続されています。誰でも質問でき、それが適切なコンテキストをロードし、ジョブを完了するために適切なツールを使用することを信頼できます。コーディングエージェントは、ここで自然な利点を持っています。作業するフォルダは、スキルとコンテキストの自然な編成を提供します。フォローアップ投稿で、既存の構造なしでこれをどのように解決したかについて、ハイブリッドRAG/LLMアプローチなどを利用して説明します。

インパクト

結果は顕著でした。GTMの新入社員はKaiネイティブであり、利用率は2.7倍高く、パワーユーザーは同じコホート内でローユーザーよりも80%多くの価値を達成しています。アカウントエグゼクティブがKaiを使用すると、販売活動が2倍になり、機会が17%増加し、収益機会が26%増加し、それを使用しない週の同じセールス担当者と比較して、成約率が39%向上します。全体として、Kaiは年間25,000時間を管理業務から収益創出業務にシフトさせるのに役立ちました。

財務およびオペレーション部門では、KaiはStripe社員が煩雑なデータを分析し、定期的なダイジェストを生成し、断片化されたコンテキストを使用可能な成果物に変換するのを支援しています。

エンジニアリング部門では、Kaiはシステムに関する質問をしたり、実行リクエストの調査を行ったり、ログを分析したり、計画をドラフトしたり、より専門的なエージェントやスキルを呼び出したりする自然な場所になっています。

そしてStripe全体で、毎日5,000以上のセッションがデータ分析を中心に展開されています。これにより、Kaiはユニークなてこ入れポイントとなっています。データ品質と分析レイヤーに関する適切なコンテキストを接続することで、ほとんどの質問に対してデフォルトで正しい応答を保証できます。

Stripe社員からの直接的なフィードバックは、これらの集計値を裏付けています。彼らは「AIを受け入れる力を与えられた」と感じ、「Kaiが正確に正しいことをするのに驚いた」と報告しています。しかし、私たちのお気に入りの逸話は、Kaiの紹介セッションを終えてすぐに、Asana、Slack、Jiraを単一の自動化プロセスにまとめるダイジェストで共同作業を行った非エンジニアの話です。

まだ勝っていない

Stripeでは、お気に入りのキャッチフレーズの1つに「まだ勝っていない」というものがあり、これはKaiにも当てはまります。私たちはこの旅の最も初期段階にあり、まだやりたいことがたくさんあります。

• より良い状態管理: Kaiのような汎用エージェントは、ツール呼び出しを反復的に行ったり、大規模なドキュメントをプルダウンしたりする際に多くの状態を生成します。LLMに送信される「アクティブ」コンテキストと、S3や仮想ファイルシステムのような状態ストアにある「拡張」コンテキストの両方を継続的に調整しています。
• 反省と自己改善: Kaiがスキルトレースを反省し、改善を提案し、テストし、スキルオーナーのレビューのために変更を提出できる品質改善ループに取り組んでいます。
• より良いコラボレーションプリミティブ: ユーザーはKaiセッションで多くのコンテキストを生成しますが、それは現在「ロックイン」されています。しかし、それが仕事の進め方ではありません。Kaiが提示するものをセッション間で共有できるようにし、複数のユーザー（およびエージェント！）が同じ成果物で共同作業できるようにしたいと考えています。

コーディングエージェントは、最初にソフトウェアエンジニアにとってAIを具体的なものにしました。Kaiは、Stripe全体の知識労働者に同様のてこ入れ感をもたらすのに役立ちました。生産性を大幅に向上させましたが、天井がまだわからないのが興味深いところです。そして、ここで限界を押し広げ続けることに興奮しています。内部生産性と外部エージェントを強化するエージェントシステムを構築することが、あなたの興味を引く挑戦のように聞こえるなら、私たちは採用しています。