stripe/ai を採用する前に読む、課金メーターとエージェント接続の設計

stripe/ai が埋めようとしている溝はどこにあるか

LLM を使った製品を作るとき、最初に面倒になるのは課金の設計だ。トークン数はリクエストごとに変動し、モデルごとに単価も違う。Stripe のサブスクリプションや従量課金の仕組みにこれを載せようとすると、利用量の集計と Stripe 側への送信を自前で書くことになる。stripe/ai はこの部分を SDK として切り出している。README は「one-stop shop for building AI-powered products and businesses on top of Stripe」と述べており、対象読者は Stripe を課金基盤としてすでに使っている、あるいは使う予定の開発者だ。もう一つの軸がエージェントからの Stripe 操作で、MCP サーバーとエージェントスキルの配布がそれにあたる。課金とエージェント接続という別々の問題を一つのリポジトリに同居させている点が、この構成の特徴であり、後述するように採用判断を分けて考える必要がある。

2 つの SDK はフレームワーク依存の有無で選ぶ

README が挙げる SDK は 2 つある。@stripe/ai-sdk は Vercel の ai および @ai-sdk ライブラリと Stripe の課金基盤を統合するためのもので、@stripe/token-meter は OpenAI、Anthropic、Google Gemini のネイティブ SDK と連携し、フレームワーク依存を持たないと説明されている。つまり選択軸はモデルプロバイダーではなく、すでに ai パッケージの抽象化を使っているかどうかだ。ai パッケージ経由でモデルを呼んでいるなら ai-sdk 側が素直に収まり、各社のネイティブ SDK を直接叩いて細かいパラメータを制御しているなら token-meter を選ぶことになる。README にはどちらを使うべきかの判断フローチャートまでは示されておらず、両者の API 差分も本稿の材料からは確認できない。ここは導入前に各サブディレクトリの README を直接読んで確かめるしかない部分だ。

MCP はホスト型サーバー、スキルは配布物という違い

Stripe は https://mcp.stripe.com でリモートの MCP サーバーを運用しており、OAuth によるセキュアな MCP クライアントアクセスを提供すると README は説明している。自前でサーバーを立てるのではなく、クライアント側からこのエンドポイントに接続する形だ。認証が OAuth である点は、API キーをエージェントの環境変数に置く運用と比べて権限の扱いが変わる。一方、エージェントスキルはコードではなく指示文の集合で、agentskills.io が定義する仕組みに沿って配布される。Claude Code、Codex、Cursor、Grok Build 向けに公式プラグインのインストールコマンドが用意されており、これらは追加のエージェントツールを含み、自動的に更新されると README は述べている。MCP が実行時の接続、スキルが開発時の指示、という役割分担で読める。

導入手順はハーネスごとにコマンドが分かれる

プラグイン経由の導入はハーネスごとにコマンドが異なる。Claude Code では claude plugin install stripe@claude-plugins-official、Codex では codex plugin add stripe@openai-curated、Cursor では /add-plugin stripe、Grok Build では grok plugin install stripe --trust をプロジェクト内で実行する。Cursor はマーケットプレイスからの導入も選べる。新しい Agent Plugins 標準については、クライアントごとにインストール方法がまだ揃っていないと明記されており、Git URL の https://github.com/stripe/ai とサブディレクトリ providers/agent-plugins/plugin/ をクライアントに指定する方式が案内されている。手動インストールの場合は npx skills add https://docs.stripe.com を実行する。この手動経路には注意書きがあり、手動で入れたスキルは自動更新されないため npx skills update -y で最新版を取得する必要がある。

自動更新されないスキルという運用上の落とし穴

このリポジトリで最も見落としやすい制約は、スキルの更新経路が 2 つに分かれていることだ。公式プラグインとして入れた場合は自動更新されるが、npx skills add で手動インストールした場合は自動更新されず、npx skills update -y を自分で実行しなければ古い指示のままになる。Stripe の API は変更されることがあり、スキルは「latest best practices」をエージェントに渡すためのものだと README は位置づけている。つまり古いスキルを放置すると、古い作法でコードを書かされる可能性がある。CI や開発コンテナのセットアップ手順に npx skills update -y を入れるか、プラグイン経由に統一するかの判断が要る。もう一点、Agent Plugins 標準はインストール方法がクライアントごとに異なると明記されている段階で、標準化が進行中の領域に手を出すことになる。

Stripe を使っていないなら中心部分は空振りする

このリポジトリの価値は Stripe の課金基盤に接続する前提で成立している。決済や請求を別の事業者で完結させている場合、@stripe/ai-sdk と @stripe/token-meter はどちらも選択肢にならない。MCP サーバーも Stripe アカウントの操作をエージェントに許可するためのものだから、同様だ。代替としては、LLM の利用量を自前で集計して任意の請求システムに渡す実装が考えられる。違いは抽象化の層にある。token-meter は OpenAI、Anthropic、Google Gemini のネイティブ SDK に寄り添う形でトークン計測を組み込むのに対し、自前実装ではモデルごとの usage フィールドの差異を自分で吸収することになる。逆に、請求先が Stripe でないなら自前実装のほうが構成は単純になる。エージェントスキルだけは課金と独立して使えるため、Stripe を請求に使っていないチームでもスキル配布の部分だけを利用する余地はある。

ライセンスと保守コストの見取り図

ライセンスは MIT で、リポジトリの LICENSE ファイルに置かれている。MIT は商用利用や改変、再配布を許容する寛容なライセンスだが、本稿は法的助言を行うものではない。実際の適用条件は必ず原文を確認してほしい。保守の観点では、SDK 本体とスキル配布で更新の性質が違う。SDK はパッケージマネージャー経由でバージョンを固定できるが、スキルはエージェントの振る舞いに効く指示文であり、更新すると生成されるコードの傾向が変わる。バージョンを固定して再現性を取るか、常に最新を追って Stripe の変更に追随するかのトレードオフになる。リポジトリは TypeScript を主言語としつつ Python もトピックに含まれており、SDK の言語別の提供状況は本稿の材料からは判断できない。導入時は llm/ai-sdk と llm/token-meter の各ディレクトリを直接確認し、自分の言語向けのパッケージが存在するかを最初に確かめるのが順序として妥当だ。

編集部の結論

採用を検討すべきなのは、LLM の利用量を Stripe の請求に直結させたい開発チームと、Stripe の API を扱うエージェントに最新の作法を読ませたいチームだ。逆に、課金を Stripe 以外で完結させている場合や、特定のエージェントハーネスに依存したくない場合は、このリポジトリの中心部分は不要になる。導入前に確認すべきは、@stripe/ai-sdk と @stripe/token-meter のどちらが自分のフレームワーク構成に合うか、そして手動インストールしたスキルが自動更新されない点を運用でどう埋めるかである。

公式情報源

1. Issues
2. License: MIT
3. Project website
4. README
5. stripe/ai on GitHub