Stripe 社内 Agent 開発の実践：エンジニア1人が1週間で開発した社内AIアシスタント、ほぼ全社員が利用
- 指示を1つ送るだけで、11秒後には「開けて・書き出して・リアルタイムでカウントダウンまで動く」イベント招待状のWebページが完成する。
- 初版はエンジニア1人が1週間で開発。最も難しいレイヤーは既製品（ファイル、サンドボックス、コンテキスト要約の3点）だったからだ。
- スキルは多ければいいわけではない。Stripe の実測では、150個を超えると、最先端モデルはスキル選択を誤り始めた。
- もう一つ。同資料の本文とグラフが一致していない。本文は「会話の多くはマルチターン」と述べる一方で、図の中央値はわずか2ターン。
Kai：エンジニア1人が1週間で開発した企業向けAIアシスタント
LangChain 公式ブログは7月末、非常に詳細な実践検証記事を公開しました。Stripe が同社製のオープンソース「Deep Agents」を使って、全社の非エンジニア向けAIアシスタント「Kai」をどう作ったかという内容です。現在、Stripe 社員の83%が毎週利用していますが、最初の稼働バージョンはエンジニア1人が1週間で作り上げました。この記事の真価は、「どの層が既製品で済むか」「どの層を自前で作るべきか」「規模拡大でどこに壁があるか」をすべて明らかにしている点です。さらに、直感に反する実証結果も示されています。それは、Agent にスキルを追加しすぎると、むしろ賢さが落ちるというものです。
Kai とは何か：3つのポイントで説明
具体的に何ができるのか：
まず、実際の動作を見てみましょう。Stripe が公開した11秒のデモ動画では、エンジニアの Anupam 氏が Kai のホーム画面に次のように入力しています。
サンフランシスコで開催される Stripe Press の公開イベントについて、週次ローンチ計画とインタラクティブなイベント招待状を作成してください。対象はアーリー期の起業家で、テーマは「AI時代に生き残る企業の築き方」です。過去90日間でウェブサイトのトラフィックが最も多かった3冊の本を選び、その著者の最近の公の発言を調査し、テーマ、書籍リスト、候補スピーカー2名を提案してください。各選択には出典を明記してください。
Stripe が公開した Kai のデモ（音声なし）。空白のホーム画面から前述の質問を入力し、ダークテーマのイベント招待状が画面に表示されるまで、わずか11秒。途中、使用しているツール write_file · file_path: event_invite.html と、ask-data というスキルのタグが見えます。出典：stripe.dev『Meet Stripe's Knowledge AI Platform』。
最後の画面に表示されるWebページは、実際に生成されたファイルです。ダークな背景に、タイトルは『Built to Last: Founding Durable Companies in the AI Era』。2026年9月24日（木）午後6:00〜8:30、場所は Stripe サンフランシスコベイエリアオフィス、対象は「アーリー期の起業家（pre-seedからAラウンド）」と記載されています。「招待を申請」「ブックリストを見る」という2つのボタンがあり、下部ではカウントダウンがリアルタイムに動いています。右上には「デモを終了」と「エクスポート」があります。
一瞬だけ映る細かい点も覚えておきましょう。ホーム画面下部の小さな文字には、このプロダクトは Agent Foundations チームが作成したとあり、入門ガイドは社内短縮リンク go/kai-getting-started、フィードバックは #kai-pilot チャンネルへ送るようになっています。右上には「Incognito」（シークレット）スイッチがあり、入力欄のプレースホルダーは「Ask anything, # for skills」で、# を打つとスキルを選択できます。
知識作業用Agentとチャットボットの違いは、成果物を見れば一目瞭然です必要なものは、開けて、編集して、他人に送れる形でなければなりません。読んですぐ忘れてしまうような回答では役に立ちませんこの違いこそが、土台に全く異なる設計が必要となる理由です
なぜプログラミング用Agentは営業や財務に役立たないのか
Stripe のエンジニアは、以前からAIアシスタントを利用していました。同社が自社開発したプログラミング用Agent「Minions」は、1週間で1000以上のプルリクエストをマージでき、コードレビューは人間が行います（この背景は、stripe.dev にある Minions に関する別の2記事からの情報です。LangChain の記事では言及されていません）。
問題は、会社の大多数がコードを書かないことです。営業、財務アナリスト、テクニカルアカウントマネージャーなどが該当します。Claude Code や Codex が台頭してきたとき、こうした人々は取り残されました。彼らも使いたいと思っていましたが、立ちはだかったのはターミナル、データアクセス権限、セキュリティ承認という3つの壁です。
Kai が登場するまで、Stripe は2つの方法を試しましたが、どちらも十分ではありませんでした。
誰でもドラッグ＆ドロップで特定タスク用の小規模Agentを作成でき、ツールも接続可能でした。結果、4000以上が作られました。
問題は数ではありません。多くの人が、意味は似ているが品質にばらつきのあるプロンプトを作成していました。これほど多くの小規模Agentが散在すると、監視とメンテナンスが追いつきません。
実際にそうした人もいました。プログラミングツールに合わせて、自分のワークフローを変更したのです。
セキュリティ上の問題がすぐに浮上しました。同時に、コード品質チームが、これまでサービスを提供したことのない非エンジニアユーザーをサポートしなければならなくなり、突然大きな負担がのしかかりました。
この2つの方法を試した後、彼らはある判断に至ります。その後のすべての設計は、この判断から派生しています。
コードを書く作業は、そのプロセスが統一されています。具体的に何を変更するかは毎回異なりますが、ファイルの編集、テストの実行、コミットといったプロセスとツールはほぼ共通です。言語が Ruby でも Java でも、作業の形は同じです。したがって、1つのAgentアーキテクチャで対応できます
知識作業は、その正反対のスペクトラムの端に位置します。顧客アカウントの調査とコンプライアンス審査の準備では、使用するツール、データ、成果物が異なり、「何をもって完了とするか」という定義すら異なります。1つのアーキテクチャを当てはめることはできません。
この判断を基に、成功のためには3つのことを押さえる必要があると結論づけました。
1つ目、専門知識は中央集権ではなく分散して置く
請求アップグレードの処理方法や収益モデルの構築方法を知っている人は、GTM、財務、マーケティング、法務、データサイエンスなど数十の領域に分散しており、Agent基盤を構築するチームにはいません。さらに、Stripe が扱う全製品、全カバー国を考慮すると、複雑さは計り知れません。Kai がやるべきことは、この複雑さをモデル化しつつ、ユーザーにその存在を感じさせずに、タスクを「いつの間にか完了させる」ことです。