コーディングエージェントは Stripe のエンジニアリングを変革しましたが、営業担当者、財務アナリスト、テクニカルアカウントマネージャーなどの非エンジニアは、Claude Code や Codex の AI の波に取り残されたように感じていました。Stripe が必要としていたデータセキュリティ要件と特定のワークフロー（データウェアハウスのクエリ、営業コール前のアカウント調査、インシデントのトリアージ、収益シナリオのモデリング、コンプライアンスレビューの準備など）を処理できる既存のツールはありませんでした。Stripe のナレッジ AI エージェントをリリースしたことで、状況は一変しました。
GIF
4 月のローンチから 2 週間以内に、Stripe のほとんどの社員が Stripe のナレッジ AI プラットフォーム、通称 Kai を利用するようになりました。現在、83% が週次アクティブユーザーであり、GTM（マーケティング、営業、カスタマーサクセスマネージャー、テクニカルアカウントマネージャー）のほぼ全員が含まれています。ほとんどの Kai セッションは多くのターンを必要とし、ユーザーは深い調査を行い、具体的な成果物を作成し、社内外で共有する前にアセットを磨き上げています。Kai により、Stripe のすべての社員が、日々の業務を支援するために特別に構築されたエージェントを利用できます。
ナレッジ AI プラットフォームを構築した理由
コーディングタスクでは、具体的な変更内容は異なりますが、タスクを実行するためのワークフローとツールはほぼ同じです。ファイルを編集し、テストを実行し、コミットします。プログラミング言語は異なりますが、作業の形態はかなり均一であり、だからこそ単一のエージェントアーキテクチャがうまく機能します。ナレッジワークはその正反対です。アカウントの調査やコンプライアンスレビューの準備などのタスクには、異なるツール、異なるデータ、異なる出力、そして異なる「完了」の定義が必要です。
Kai 以前、ナレッジワークには 2 つの AI オプションがありました：
- NoCode Agent Builder： 誰でもツールを使用できるワークフロー特化型エージェントを構築してデプロイできました。このシステムを使って 4,000 以上のエージェントが構築されました。しかし、すぐにチームが概念的には類似したプロンプトをさまざまな品質レベルで書いていることに気づき、これらのマイクロエージェントの増殖を監視・維持することがますます困難になっていきました。
- コーディングエージェント： コーディングエージェントは強力でしたが、別の種類のリスクをもたらしました。Stripe 全体の生産性向上を可能にするという目標から、一部のユーザーはワークフローを変更してコーディングエージェントを選択しました。しかし、すぐにセキュリティ上の懸念が浮上し、これまで非エンジニアをサポートしたことがなかったコード品質チームに新たなサポート負担が生じました。
これらの経験から、ナレッジ AI プラットフォームの構築には 3 つのことを正しく行う必要があると気づきました：専門知識を集中化せずにスケールさせること、ユーザーが働く場所に合わせて対応すること、そしてコードには存在しないガードレールを適用することです。
専門知識を集中化せずにスケールさせる
Stripe のユーザーに対応するために必要な専門知識の範囲は驚異的です。請求エスカレーションのトリアージや収益シナリオのモデリング方法を知っている人々は集中管理されておらず、エージェントインフラを構築するチームにも確かにいません。彼らは GTM、ファイナンス、マーケティング、法務、データサイエンスなど、数十の専門 ドメイン に分散しており、それぞれが独自のツール、データソース、ワークフロー、そして何が「良い」かという判断基準を持っています。これを Stripe が事業を展開するすべての製品と国に掛け合わせると、その複雑さは驚くべきものになります。Kai はその複雑さを不可視化する形でモデル化し、タスクが そのまま機能する ようにしなければなりません。
エージェントはどこにでも現れる
エージェントがどこに現れるかは、何を知っているかと同じくらい重要です。誰もがブラウザのタブで作業しているわけではなく、ターミナルで作業している人はさらに少ないのです。したがって、ナレッジエージェントは単一の製品であってはならず、作業が行われる場所に埋め込めるほど柔軟なプラットフォームである必要があります。
例えば、財務チームが Stripe の運営予算の複雑な変更をモデル化するために使用する内部アプリケーションを考えてみてください。エージェントは、アプリからユーザーを引き離すことなく、コンテキストを読み取り、関連ドキュメントを調査し、有効な変更を提案し、差分を要約する必要があります。
スタンドアロンのエージェント製品を構築しても機能しません。ユーザーを自然なワークフローから引き離し、新しいアプリへと強制することになるからです。各サーフェスに個別のエージェント製品を構築するのも機能しません。維持が難しく、複数のツールを使いこなすユーザーは断片化された体験をすることになるでしょう。プラットフォームはユーザーがいる場所 に合わせて 対応しなければなりません。
ゼロからガードレールを構築する
コーディングエージェントは、数十年にわたって培われた高速で検証可能なガードレールが存在する環境で動作します。コンパイラは不正な構文を拒否し、テストはリグレッションを検出し、git はあらゆるミスを元に戻せるようにします。ナレッジワークには、こうした構成を支える仕組みがほとんどありません。
Stripe の核となる不変条件を考えてみてください：「2 つの無関係な顧客コンテキストのデータを単一の分析で組み合わせてはならない」。ユーザーは両方のコンテキストに個別に正当なアクセス権を持っているかもしれませんが、同じセッションに両方が現れることは決してありません。分離の境界は「この人は認証トークンに基づいて何にアクセスできるか」ではなく、「このタスクにはこのコンテキストを踏まえて何を表示することが許可されるべきか」なのです。プラットフォームは、ユーザーが依存しているこうした暗黙のガードレールを適用しなければなりません。
Kai の構築方法
単一のモノリシックなエージェントでは、これらの制約をすべて効果的にエンコードすることはできません。また、各ドメインチームにセキュアでホストされた高性能なエージェントインフラを独立して構築するよう求めるのもスケールしません。この課題に対処するため、Kai を 3 つのレイヤーで構築しました：
- サーフェス非依存の API：同じエージェントへの複数のインターフェースを提供
- AgentStudio：ドメインオーナーが独自の Kai エージェントを構築・管理
- 実行環境：誰もインフラを意識することなく数秒でセキュリティを提供
サーフェス非依存の API
Kai には、明確な設計思想を持つ Web アプリケーションと Slack インテグレーションが同梱されていますが、主要なプリミティブは両方を支える基盤 API です。エージェントはアプリケーションではなくサービスであり、サーフェスはそのカスタマイズされたビューにすぎません。
ほとんどの Stripe 社員は、社内ホストの Web アプリケーションを通じて Kai を利用しています。セットアップが必要なインフラはなく、入社初日からすべての従業員が利用できます。
内部ツールはどれでも Kai を埋め込むことができ、多くのツールが実際にそうしています。例えば、ビジネスインテリジェンスプラットフォームで作業する従業員は、既存のアプリケーション内から Kai に質問できます。これは、Chrome 拡張機能が Kai の機能を Web ベースのサードパーティツール内に表示するためです。
カスタムアプリケーションは API を通じて Kai を埋め込み、エージェンティックな体験をすべてのワークフローに提供します
AgentStudio
AgentStudio はドメインオーナーのためのコントロールプレーンです。チームはこれを使用して、スキル、カスタム Kai エージェント、ツール選択を構築、テスト、モニタリングします。例えば GTM チームは、自社のワークフローに合わせて調整された Kai エージェントを所有しています。デフォルトで自社のスキルを読み込み、データソースに接続し、ユーザーが期待する形式で出力を提示します。AgentStudio は各アセットとともに使用状況データと品質シグナルを表示するため、ドメインオーナーはプラットフォームチームに問い合わせることなく、何が機能しているかを確認できます。
スキルは Stripe 全体の領域ごとに整理され、各領域はドメインエキスパートによって管理されています
実行環境
これはプラットフォームの約束を現実にするレイヤーです。エージェントハーネス、サンドボックス、ワークフローオーケストレーション、アクセス制御フレームワークを含むコアプリミティブは、Stripe の製品向けエージェントと意図的に共有されています。内部ナレッジワークは、外部製品と同じ機密データを扱い、同じユーザーにサービスを提供するため、同じセキュリティとコンプライアンスの基準が必要です。基盤を共有することで規律が生まれ、フライホイールが生み出されます。実行環境の改善は、内部エージェントと製品エージェントの両方に同時に利益をもたらします。
LangChain の deepagents を使用して構築されたエージェントハーネスは、Kubernetes 上で動作し、セッションごとのセキュアなサンドボックスとマルチテナント仮想ファイルシステムを備えています。セッション内では、エージェントは仮想ファイルシステム上で成果物を作成・反復処理し、分析とデータ処理にはセキュアなコード実行サンドボックスが使用されます。
長く複雑なセッション全体で状態を保持するように設計されており、最近では 932 ターンに達したセッションもあります。Kai の高度なタスク管理機能により、単一の会話がタイムアウトやコンテキストウィンドウの過負荷なしに、数百ターン、数百回のツール呼び出しと LLM 呼び出しで構成されることができます。これは、ナレッジワークが単一の質問であることはほとんどなく、それ自体に積み重なっていく反復的な推論であり、セッションが品質を劣化させずにその状態を保持する必要があるため、重要です。
ユーザーの行動は変化しており、深いマルチターンコラボレーションのためにセッションがますます利用されています
ハーネスで最も興味深い点の 1 つは、正しいスキルを選択する仕組みです。Kai は、主要指標を追跡するビジネスインテリジェンスダッシュボードから、内部実行を整理するプロジェクト管理ツール、Zoom や Google Workspace などのサードパーティサービスまで、さまざまな内部システムにわたる 1,000 以上のスキルとツールに接続されています。誰でも質問でき、適切なコンテキストを読み込み、仕事を完了するために適切なツールを使用してくれると信頼できます。コーディングエージェントにはここで自然な利点があります。作業するフォルダがスキルとコンテキストの自然な組織化を提供するからです。次の記事では、ハイブリッド RAG/LLM アプローチをはじめとする技術を活用して、既存の構造なしでこの問題をどのように解決したかについて詳しく説明します。
インパクト
結果は顕著です。GTM の新入社員は Kai ネイティブであり、使用頻度は 2.7 倍で、パワーユーザーは同じコホート内の低使用ユーザーと比較して 80% 以上多くの価値を生み出しています。Account Executive が Kai を使用すると、使用しない週と比較して、営業活動が 2 倍、創出されるオポチュニティが 17% 増加、収益機会が 26% 増加、成約件数が 39% 増加します。全体として、Kai は年間 25,000 時間を管理業務から収益創出業務にシフトするのに貢献しました。
ファイナンスとオペレーションでは、Kai は Stripe 社員が複雑なデータを分析し、定期的なダイジェストを生成し、断片化されたコンテキストを使いやすい成果物に変換するのを支援しています。
エンジニアリングでは、Kai はシステムに関する質問をしたり、実行リクエストの調査をしたり、ログを分析したり、計画をドラフトしたり、より専門的なエージェントやスキルを呼び出したりするための自然な場所になっています。
そして Stripe 全体では、毎日 5,000 以上のセッションがデータ分析を中心としています。これにより、Kai は独自のレバレッジポイントとなっています。データ品質と分析レイヤーに関する適切なコンテキストをプラグインすることで、ほとんどの質問に対してデフォルトで正しい回答を保証できます。
Stripe 社員からの直接のフィードバックもこれらの数値を裏付けています。彼らは 「AI を活用する力を与えられた」 と感じ、「Kai が正確に正しいことをやってのけることに驚かされている」 と報告しています。しかし、私たちのお気に入りのエピソードは、Kai の入門セッションを終えた非エンジニアが、すぐに Asana、Slack、Jira を 1 つの自動化プロセスにまとめるダイジェストでコラボレーションし始めたというものです。
私たちはまだ勝っていない
Stripe では、「私たちはまだ勝っていない」 というフレーズがお気に入りの 1 つですが、これは Kai にもぴったり当てはまります。私たちはこの旅のごく初期段階にあり、やりたいことはまだたくさんあります：
- より良い状態管理： Kai のような汎用エージェントは、ツール呼び出しを反復的に行い、大きなドキュメントを取得するなどして、多くの状態を生成します。私たちは、LLM に送信される「アクティブな」コンテキストと、S3 や仮想ファイルシステムなどの状態ストアにある「拡張された」コンテキストの両方を継続的に調整しています。
- リフレクションと自己改善： Kai がスキルに関するトレースを振り返り、改善を提案し、テストし、スキルオーナーがレビューするための変更を提出できるようにする品質改善ループに取り組んでいます。
- より良いコラボレーションプリミティブ： ユーザーは Kai セッションで多くのコンテキストを生成しますが、それは現在「ロックイン」されています。しかし、それが仕事の進め方ではありません。Kai がセッション全体で表示するものを共有できるようにし、複数の人（そしてエージェント！）が同じ成果物でコラボレーションできるようにしたいと考えています。
コーディングエージェントは、まずソフトウェアエンジニアにとって AI を具体的なものにしました。Kai は、Stripe 全体のナレッジワーカーに同じレバレッジ感をもたらしました。興味深いのは、生産性を大幅に向上させた一方で、まだ天井が見えていないことです。そして、私たちはこの限界を押し広げ続けることに興奮しています。内部生産性と外部エージェントを強化するエージェンティックシステムの構築があなたにとっての挑戦に思えるなら、採用情報はこちら。
