なぜプログラミング用Agentは営業や財務に役立たないのか

Stripe のエンジニアは、以前からAIアシスタントを利用していました。同社が自社開発したプログラミング用Agent「Minions」は、1週間で1000以上のプルリクエストをマージでき、コードレビューは人間が行います（この背景は、stripe.dev にある Minions に関する別の2記事からの情報です。LangChain の記事では言及されていません）。

問題は、会社の大多数がコードを書かないことです。営業、財務アナリスト、テクニカルアカウントマネージャーなどが該当します。Claude Code や Codex が台頭してきたとき、こうした人々は取り残されました。彼らも使いたいと思っていましたが、立ちはだかったのはターミナル、データアクセス権限、セキュリティ承認という3つの壁です。

Kai が登場するまで、Stripe は2つの方法を試しましたが、どちらも十分ではありませんでした。

この2つの方法を試した後、彼らはある判断に至ります。その後のすべての設計は、この判断から派生しています。

この判断を基に、成功のためには3つのことを押さえる必要があると結論づけました。

1つ目、専門知識は中央集権ではなく分散して置く

請求アップグレードの処理方法や収益モデルの構築方法を知っている人は、GTM、財務、マーケティング、法務、データサイエンスなど数十の領域に分散しており、Agent基盤を構築するチームにはいません。さらに、Stripe が扱う全製品、全カバー国を考慮すると、複雑さは計り知れません。Kai がやるべきことは、この複雑さをモデル化しつつ、ユーザーにその存在を感じさせずに、タスクを「いつの間にか完了させる」ことです。

2つ目、Agentはユーザーのいる場所に赴く必要がある

全員がブラウザで仕事をしているわけではなく、ターミナルで仕事をしている人はさらに少数です。したがって、スタンドアロンの製品ではなく、あらゆる社内ツールに組み込めるプラットフォームである必要があります。

財務チームには、会社の運営予算の複雑な変動をシミュレーションするための社内アプリがあります。Agent は、現在のコンテキストを理解し、関連ドキュメントを参照し、妥当な変更を提案し、差異をまとめる必要があります。その間、ユーザーをそのアプリから追い出すことはできません。スタンドアロンの製品にしてしまうと、ユーザーは慣れ親しんだワークフローを離れて、新しいアプリに移動することを強いられます。一方、エントリポイントごとに個別のAgentを作るのはメンテナンスが大変で、複数のツールを横断して使う人にとっては、体験が断片化してしまいます。

3つ目、ガードレールはゼロから作る必要がある

プログラミング用Agentは、数十年かけて蓄積されたガードレール環境に浸かっています。コンパイラは構文エラーを拒否し、テストはリグレッションを検出し、git はどんなエラーからもロールバックを可能にします。これらの高速で検証可能な仕組みは、知識作業にはほとんど存在しません。

Stripe が挙げた自社の厳格なルールの例：無関係な2つの顧客のデータを、同じ分析に入れてはならない。ここでの境界は非常に微妙です。ある人がそれぞれのデータを個別に見る権限を持っている場合でも、それらが同じセッションに存在することは許されません。

Deep Agents が代行してくれた3つのこと：ファイル、サンドボックス、コンテキスト

Kai の基盤は、LangChain がオープンソース化したAgentハーネス、Deep Agents です。

Deep Agents のレイヤーが、Stripe とは無関係な問題をすべて解決してくれたので、私たちは Stripe 固有の問題に集中できました。既製のミドルウェアを棚からいくつか直接取り出せます。組み合わせ可能なスキルパターン、複合バックエンド。正しい構造を与えつつ、十分な柔軟性も残してくれています。

Sharadh Krishnamurthy ・ Stripe Agent Foundation チーム エンジニアリングマネージャー

1週間で動くものが作れたのは、すぐ使える3つのミドルウェアのおかげです（ミドルウェアとは、モデルとビジネスロジックの間に挟むプラグイン可能な部品で、それぞれが1つの汎用タスクを担当します）。以下で詳しく見ていきます。

一、仮想ファイルシステム：Agent に繰り返し編集できるデスクトップを提供

Kai はクラウド上で動作する本番サービスであり、あなたのローカルで動くプロセスではありません。したがって、ハードディスクがそもそもありません。Stripe は S3 を背後に置いた仮想ファイルシステムを構築し、Agent がターンをまたいでファイルを読み取り、書き込み、参照できるようにしました。

なぜファイルシステムという形式が、Agent のコンテキストに特に適しているのでしょうか？ それは、コンテキストが、モデルが参照・編集・自分で整理できるものになるからです。後ろに積み上げるだけで、どんどん長くなるチャット履歴ではありません。

Deep Agents がモデルに提供するファイルツールは全部で8つです（この表はLangChain公式ドキュメントを基に筆者が整理。元記事に一覧はない）。

Stripe はこの仕組みに、独自のラッパーを追加しました。「同期イン／同期アウト」と呼ばれるものです。サンドボックス内で何かを実行する前に、関連ファイルをすべてサンドボックスに具体化します。実行後は、新規作成と変更されたファイルを仮想ファイルシステムに同期して戻します。

その効果は、Agent とそれを駆動するモデルが、セッションのライフサイクル全体を通じて、一貫性のある持続的なファイル環境を認識することです。背後でサンドボックスが何度も起動・破棄されていても、です。

二、サンドボックス：重要なのは Agent がサンドボックスの外側にいること

Kai には、コードを実行する必要がある2種類のタスクがあります。1つは分析（Python を使ったデータ調査やグラフ作成）、もう1つは様々な形式のファイル処理（PDF、プレゼンテーション、構造化ドキュメント）です。

ここで見落としがちですが、非常に重要な設計があります。サンドボックスは「ツール」として Agent に公開されており、Agent 自身がサンドボックス内で実行されているわけではありません。Agent はサンドボックスの外側で動作し、コードを実行する必要があるときだけ、サンドボックスを呼び出します。

なぜこのような構成なのでしょうか？ 答えは「致命的な三つ組」（lethal trifecta）と呼ばれるセキュリティモデルにあります。Simon Willison が2025年6月に提唱し、Stripe はここで直接引用しています。

AIシステムがこの3つの能力を同時に持つと、攻撃者はあなたのデータをパッケージ化して送信するよう仕向けることができます。根本的な原因は、モデルが「主人からの指示」と「今読んでいるドキュメントからの指示」を区別できず、すべてが文字列として連結されてモデルに入力される点にあります。さらに深刻なのは、この問題には現在100%確実な防御策がないということです。プロンプトに「指示に従うな」と書いておいても、毎回機能するとは限りません。

そこで Stripe は、「モデルが生成したコード」に明確な実行境界を設けています。Agent は外側、コードは内側で実行され、内部で問題が発生しても、外部の認証情報やデータチャネルには影響が及びません。

三、自動要約：コンテキストが上限に近づいたら自動で整理

マルチターンの長いセッションには物理的な上限があります。会話が長くなるほど、モデルに送信される履歴が長くなり、コストがかさみ、コンテキストウィンドウの上限に達してしまいます。

Deep Agents の要約ミドルウェアは、デフォルトで次のように動作します（これらのデフォルト値は私が deepagents リポジトリのソースコードから読んだもので、Stripe が実際に使用している数値は公開されていません）。コンテキスト使用量が 85% に達すると圧縮がトリガーされ、最近の 10% はそのまま保持し、その中間はモデルに要約させます。圧縮された元のメッセージは保存され、仮想ファイルシステムの /conversation_history/ というファイルに移動されます。必要になればいつでも参照できます。

Stripe がここで調整するノブには、要約をトリガーするタイミング、要約に使用するモデル、要約の出力長などがあります。また、コストに関する考慮事項にも言及しています。ほとんどのユーザーは Kai をぶっ続けで使うのではなく、断続的に使います。したがって、大きなコンテキストのキャッシュが無効になる状況は可能な限り避けたいと考えています。キャッシュがヒットしないと、その分の文字数はフルコストで再計算されることになります。

エンジニア1人が1週間で初版を開発：Kai の3層アーキテクチャ

Stripe は10年以上かけて、Ruby と Java を中心とした社内ツール、セキュリティレイヤー、デプロイ支援を構築してきました。Python ネイティブの技術スタックを使用するということは、新しい言語に合わせて社内サービスの足場を再構築することを意味します。これは大きな投資であり、実行する前には誰も確信を持てませんでした。

Kai は、その成果でこの投資の正しさを証明しました。Anupam 氏はたった1人で、1週間で Kai の初版を作り上げました。Agent インフラストラクチャの中で最も難しい部分を、Deep Agents がすでに解決していたからです。

Kai は、Deep Agents が正しい道であるという皆の確信を完全に裏付けるものとなった。

Chrissie ・ Stripe AI プラットフォーム責任者

Kai のアーキテクチャは3層で構成されています。

最上位層：インターフェースに依存しない API

Kai には当初から Web アプリと Slack インテグレーションが付属していますが、本当の核となるのはその下にある API です。Agent はここではサービスであり、上記のインターフェースはそのカスタムビューに過ぎません。Web版は初日から全社員が利用可能で、誰も何かを設定する必要はありません。

あらゆる社内ツールが Kai を埋め込むことができ、多くのチームが実際にそうしています。例えば、BI（ビジネスインテリジェンス）プラットフォームで作業している人が、そのインターフェース内で直接 Kai に質問できます。Stripe は Chrome 拡張機能も作成し、Webベースのサードパーティツールに Kai の機能を組み込んでいます。

社内BIツール（Insights and Forecasting Studio）の右側に埋め込まれた Kai。ユーザーが「地域別の収益トレンドを見せて」と入力すると、Kai は左側にグラフを直接作成し、何をしたかを表示します：月次純収益、地域別の折れ線、非現行バージョンの除外、金額のフォーマット。さらに下には折りたたまれた「36 tools」呼び出し記録と、自作のトレンド分析コメントが表示されます。図の地域名が Atlantis、Mordor、Westeros などとなっているのは、ダミーのデモデータであるためです。出典：stripe.dev。

中間層：AgentStudio、各領域向けのコンソール

各領域の責任者はここで、自部門のスキルを構築・テスト・監視し、Kai やツールの選択をカスタマイズします。例えば、GTMチームには、彼らのワークフローに特化した Kai があります。デフォルトで彼らのスキルを読み込み、彼らのデータソースに接続し、彼らの慣れた形式で結果を出力します。コンソールには、各アセットの横に利用データと品質シグナルが表示されるため、領域責任者はプラットフォームチームに問い合わせることなく、どのスキルが効果的かを把握できます。

Agent Studio のスキルページ。右上には34のエリア（area）と表示されています。ABP（管理ビジネスパートナー）エリアには2つのスキル、Bridge エリアには6つのスキルと5つのサブエリア、Data & AI エリアには2つのスキルと32のサブエリア、Finance & Workplace エリア自体には0スキルですが、35のサブエリアがぶら下がっています。この1000を超えるスキルは部門ごとに階層化されており、親エリア自体がスキルを持たないこともあります。各カードの右下の「Editor」は、現在のユーザーの権限を示します。スキル作成には、「Create with AI」と「Create in Editor」の2つの入口があります。（本文では Stripe は「AgentStudio」と続けて表記していますが、製品のインターフェースでは「Agent Studio」と分かれています。ここではスクリーンショットに合わせました。）出典：stripe.dev。

最下層：共有実行環境

Agent ハーネス、サンドボックス、ワークフローオーケストレーション、アクセス制御フレームワークという中核部品は、意図的に Stripe の対外プロダクト内の Agent と共有されています。その理由は、社内の知識作業も、同様に機密性の高いデータを扱い、同じユーザーにサービスを提供しているため、セキュリティとコンプライアンスの基準を下げるべきではないからです。共通の基盤を共有することで、規律が強制されると同時に、実行環境が改善されれば社内 Agent と製品 Agent の両方が恩恵を受けるという好循環が生まれます。

この層は Kubernetes 上で動作し、セッションごとに独立したサンドボックスと、マルチテナントの仮想ファイルシステムを備えています。

Stripe 公式アーキテクチャ図。上部の2つのブロックはコンシューマーで、社内知識 Agent（Kai）と対外プロダクト Agent が、同じ「セキュア共有実行環境」に合流します。中央の濃い紫は Agent ハーネス（Kubernetes 上で稼働）で、その責務は「長いセッションをまたいでコンテキストと状態を維持すること」。下部の4つの部品：ワークフローオーケストレーション（計画と調整）、セッション毎サンドボックス（分離されたコード実行）、セッションワークスペース（仮想ファイルと成果物、拡張状態）、コンテキストルーティング（適切なスキルとツールの選択）。最下部には1000以上のスキルとツールが接続され、Stripe データ、各チームが保有するドメインワークフロー、Google Workspace、Zoom などの外部サービスへと通じています。出典：stripe.dev。

1000ものスキル、モデルはどれを使うべきかどう判断するのか

まず、スキルとは何かを説明します。Deep Agents において、スキルは構造化され、Agent が直接実行できるモジュールです。「特定の種類のタスクを完了する方法」が含まれており、どのツールを読み込むか、どのようなアプローチを取るかが定義されています。これは Agent Skills 標準に準拠しており、ディスク上では1つのディレクトリとして存在し、その中に SKILL.md が必須です。ファイルの先頭は YAML メタ情報（名前、一言説明、使用可能なツール）、その後に Agent 向けの説明書が続きます。スクリプト、テンプレート、リファレンスドキュメントを含めることもできます。

Stripe のアプローチは連邦制です。スキルは各チームが所有・保守しています。ベースの Kai には、Stripe 社内の基本的なナビゲーションをカバーする基礎スキルがバンドルされています。追加のスキルは、ユーザープロファイルと、現在使用しているカスタマイズ版 Kai に基づいて階層的に読み込まれます。営業オペレーション担当者と財務担当者では、受け取るスキルパッケージが異なります。さらに上位にはユーザーレベルのプロファイル層があり、個人が部門のデフォルト設定にスキルを追加できます。

ここでジレンマが生じます。すべてをコンテキストに入れるのは不可能です。毎回、電話帳を読ませるようなものですから。

解決策：最初にスキルを選択させ、スキルがツールを引き出す

Agent Skills 仕様では、各スキルが allowedTools を宣言できます。つまり、そのスキルが使用を許可するツールのリストです。Deep Agents は起動時に、各スキルの名前、一言説明、許可されたツールのリスト、ファイルパスのみをシステムプロンプトに注入します。スキルの本文は一切読み込みません（この方法は「プログレッシブ・ディスクロージャー（段階的開示）」と呼ばれます。本は最初に目次だけが示され、該当する章が開かれたときだけ内容が展開されるイメージです）。モデルはタスクに適したスキルを自分で判断し、選択後、そのスキルの allowedTools によって、どのツールの完全な定義を読み込むかが決まります。

モデルはそもそも、どのスキルを読み込むべきかを判断するために労力を使っています。それならば、その判断に合わせて、関連するツールも一緒に読み込んでしまおう、ということです。

Anupam Upadhyay ・ Stripe AI プラットフォームチーム エンジニア

一部の基礎スキルは固定されており、モデルが何を読み込むか解除するかに関係なく、常に存在します。これにより、Stripe の基本的なコンテキストとポリシー動作が、常に一貫性を保つことができます。

そして、その壁：150

スキルの説明フィールドには、1024文字の上限があります。これは Agent Skills 標準で定められており、Deep Agents のソースコード内で定数としてハードコードされています（MAX_SKILL_DESCRIPTION_LENGTH = 1024、middleware/skills.py 内）。

Stripe チームの実測により、スキル数が150を超え、さらに彼ら独自のシステムプロンプトが加わると、最先端モデルの品質が低下し始めることが分かりました。

スキル数は今も未解決の課題であり、Stripe チームはより良い解決策を模索中です。方向性はハイブリッドな選択システムです。その中で、直感に反する観察結果があります。現在の規模では、純粋にモデルに選択させる方が、RAG よりも効果的だということです。RAG とは、検索で最も関連性の高い数件を先に抽出してからモデルに渡す方法です。理由は、コンテキストが完全な場合、モデルの判断がより正確になるからです。しかし、規模がさらに大きくなれば、RAG または分類器で一次スクリーニングを行い、その後でモデルに最終決定させるという層を追加する必要があります。このハイブリッド方式の詳細は、後続の記事で公開する予定だと Stripe は述べています。

利用データ：83% が毎週利用、会話の半数は2ターンで終了

まず成長について。Kai はプレビュー公開後、1週間でチームの四半期採用目標を達成しました。約4週間でユーザーは296人から5000人以上へと16倍に増えました。

それは、まるで自然に広がっていった。人々が使ってみて、そして定着した。

Sharadh Krishnamurthy ・ Stripe Agent Foundation チーム エンジニアリングマネージャー

主に増えたのは、もともとターゲットにしていた人々です。営業、財務アナリスト、ビジネスオペレーション担当者です。これらの人々は「AI を使え」と言われ続けてきましたが、自分の仕事の仕方に合うツールを見つけられずにいました。Sharadh 氏はユーザーの言葉を次のように伝えています。「以前のものは、たくさんの設定を調整しないと使えなくて。でも会社から AI を使うよう言われていたから、本当に努力したんです。」そして、「これはいい。何も調整する必要がない。」

現在の数字：Stripe 社員の83%が毎週 Kai を利用しています。パーセンテージで見ると、マーケティング（95%）と GTM チーム（87%）の採用率は、エンジニアリングチームよりも高くなっています。

本文は「会話の多くはマルチターン」と述べるが、グラフの中央値はわずか2ターン

「1回のセッションの長さ」について、同じ資料の中で、文章とグラフが2つの異なる答えを示しています。

文章が与える印象は長い：「ほとんどの Kai セッションは多くのターンを必要とする」、例として932ターンに達したセッションが挙げられています。

グラフが示すのは、35.9万セッションの実際の分布です。

Stripe 公式統計図。35.9万セッション、134万ターンに基づく。左：セッション毎のターン数、中央値2、平均3.7、p99は34。中央：セッション毎のモデル呼び出し、中央値8、平均15.8、p99は131。右：セッション毎のツール呼び出し、中央値9、平均19.1、p99は154。陰影帯は p25–p75、点線は平均値。出典：stripe.dev。

セッションの半数は、わずか2ターンで終わっています。上位1%に入ってようやく34ターンです。図のキャプションには「ユーザー行動は変化しており、セッションはより深いマルチターンのコラボレーションにますます使用されている」とありますが、これは傾向について述べているのであって、現在の大多数を示しているわけではありません。932ターンのセッションは、極端な例外的ケースです。

セッションの総数にも、2つの一致しない数字があります。文章部分では「データ分析を中心に毎日5000以上のセッション」と、全社で「6万以上のセッション」とある一方、グラフには35.9万セッションと記載されています。統計範囲の違いは説明されていないため、ここでは別々に記載し、混算しません。

中央値2ターンのセッション、その背後で8回のモデル呼び出し

3つのグラフをまとめて見ると、中央値がわずか2ターンのセッションが、その背後で8回のモデル呼び出しと9回のツール呼び出しを行っていることが分かります。

ターン数が少ないことは、タスクが単純であることを意味しません。ユーザーが一言言うと、その背後で Agent は数ステップを実行し、データを調べ、ファイルを解析し、ドラフトを書き、そして修正しています。これは、前述の3つのミドルウェアがなぜ欠かせないかを説明しています。わずか2ターンの短いセッションでも、その背後ではすでに17〜18回の呼び出しが行われており、ファイルを置く場所、コードを実行する場所、コンテキストの整理が必要だからです。

未解決の4つの課題と、フレームワーク自身が認める限界

Stripe がよく口にする言葉に「まだ勝っていない」（we haven't won yet）というものがあります。現在、取り組んでいる課題は主に4つです。

この製品のすべての約束は、ユーザーが設定を調整する必要がない、ということです。だからこそ、今この責任は私たちにあります。私たちがそのインテリジェンスを作り上げ、全員に代わってこれらの判断をすべて下せるようにしなければならないのです。

Sharadh Krishnamurthy ・ なぜパラメータをユーザーに渡さないのか、について

この取り組みがまだ進行中であることを示す詳細がもう1つあります。Kai の基盤である Deep Agents の現在のバージョンは 0.7.4（2026年8月4日リリース）で、まだ 1.0 に達していません。しかも、その反復は非常に速く、0.7.1 が7月30日、0.7.2 と 0.7.3 が8月3日、0.7.4 が8月4日と、5日間で4つのバージョンがリリースされています。

なぜガバナンスが todo に入るのか：フレームワークのリポジトリに記載された2つの事実

上記4つの課題の中で、「ガバナンスとガードレール」の重みは、Deep Agents のリポジトリを読まなければ分かりません。以下の2点は、2つの記事（LangChain と Stripe の記事）には記載がなく、出典は LangChain 自身がリポジトリに書いた脅威モデルドキュメント（libs/deepagents/THREAT_MODEL.md、文書の冒頭に自動生成・実験的性質と明記）です。

Stripe のエンジニアは以前から独自のプログラミング用Agentを持っており、1週間で1000以上のコード変更をマージできます。営業、財務アナリスト、オペレーション担当者は、ターミナル、データアクセス権限、セキュリティ承認という3つの壁を越えられませんでした。Stripe の判断はこうです。コードを書く作業は形が統一されており、ファイル編集、テスト実行、コミットの流れは同じなので、1つのアーキテクチャで対応できる。一方、知識作業はタスクごとにツール、データ、成果物、そして「完了」の定義まで異なります。

Kai の基盤は LangChain がオープンソース化した Deep Agents です。これは Agent の骨格と駆動システムのようなもので、モデル呼び出しループや状態管理など、Agent を作るなら誰もが実装する必要がある汎用部品がパッケージ化されています。エンジニア1人が1週間で初版を作れたのは、この層のおかげです。ただし、この「1週間」は最初の稼働バージョンを指しており、現在の全員利用のシステムに至るまでの期間や人数は、2つの公式資料には明記されていません。

スキルとは、1つのディレクトリの中に SKILL.md という説明書が入ったものです。先頭の数行がメタ情報（名前、一言説明、使用可能なツール）、その後に Agent 向けの作業手順が続きます。Stripe には1000以上のスキルと500以上の社内ツールがあり、すべてをコンテキストに入れると、毎回電話帳を読ませることになります。

スキルの一言説明は最大1024文字です。150スキルあれば、目次だけで10数万文字になります。モデルはこの程度の文字数は記憶できますが、この巨大なリストから1つを選ぶという行為の精度が低下します。Stripe はこの課題は未解決だと述べており、方向性としては、まず検索や分類器で粗く絞り込んでからモデルに選ばせることを検討しています。ただし、現在の規模では、検索で数件を抽出してからモデルに渡すよりも、完全な目次を見せてモデルに選ばせる方が正確です。

Kai はプレビュー公開から1週間で四半期採用目標を達成し、4週間でユーザーは296人から5000人以上へと増加しました。増えた主なユーザーは、もともとターゲットにしていた人々です。営業、財務アナリスト、ビジネスオペレーション担当者です。