Stainless — 週1.1億DLのSDK生成層をAnthropicが買った理由

2026-06-07

OpenAPI 仕様から SDK、ドキュメント、CLI、MCP を生成し、開発者とエージェントに接続する図
出典: 自作図(数値は Stainless Customers ページ(2026/5参照)

AI エージェントの話題は、この一年で「賢く会話する」から「実際に作業を片づける」へと移ってきた。資料を調べてまとめたり、社内のツールを動かしたり、外部のサービスに注文を出したり。そうした仕事をエージェントに任せようとすると、多くの会社が同じ壁にぶつかる。エージェントが相手のサービスにうまくつながれない、という壁だ。

2026 年 5 月 18 日、Anthropic がこの「つなぐ」部分を専門にしてきた Stainless という会社を買収した。Stainless は開発者向けの裏方ツールを作る会社で、一般にはほとんど名前を知られていない。それでも、Claude を作る Anthropic がわざわざ買ったという事実には、いまのエージェント競争がどこで決まりつつあるのかが表れている。勝負はモデルの賢さだけでなく、エージェントを外の世界につなぐ配管の質に移りはじめている。

Stainless がやっていたのは、ある会社のサービスを別のソフトやエージェントから呼び出せるようにする部品、すなわち SDK と、その使い方を説明したドキュメントを、自動でまとめて用意する仕事だ。地味に見えるが、この SDK やドキュメントが実際の API と噛み合わなくなると、エージェントはとたんに失敗する。注文を二重に出したり、必要な情報を取りこぼしたり、エラーに気づかないまま先へ進んだりする。つなぐ部分の出来が、そのままエージェントの仕事の成否になってしまう。

しかもこの SDK は、ふだん利用者の目に触れない場所で大量に使われている。Stainless が用意した SDK は各社の公式パッケージとして配られ、その合計ダウンロードは週に 1 億回を超える。顧客には OpenAI や Cloudflare のような、AI や API を売りにする企業が並ぶ。2024 年末には著名ベンチャーキャピタルの a16z が主導して 25 億円規模を出資していて、表に出ないインフラとして静かに広がっていた会社だった。

以下では、この買収を「エージェントが外の世界で動くための土台を、Anthropic が押さえた話」として読み解いていく。

1. Anthropic が買ったのは「モデルの賢さ」ではない

今回の発表で Anthropic がまず語ったのは、モデルの性能ではなく「つなぐこと」だった。エージェントは、外のサービスに届いて初めて仕事になる。どれだけ賢く考えても、相手につながらなければ何も片づけられない。

その「つながる質」を決めているのが、さきほどの SDK とドキュメントだ。ここが弱いと、失敗はモデルの賢さではなく接続の側で起きる。Stainless はこの接続を引き受けてきた会社だった。だから Anthropic が手に入れたのは、外のサービスをエージェントが使える形に整える力そのものになる。「SDK 生成ツールを買った」という説明では、この動きは小さすぎる。

参考: Anthropic の買収発表 / Stainless の参加発表

2. Stainless は SDK とドキュメントを丸ごと作る工場だった

Stainless の入口は、API の仕様書だ。どんな機能をどう呼べるかを書いた設計図、いわゆる OpenAPI 仕様を渡すと、そこから外部利用のための成果物がまとめて生成される。

生成されるのは、SDK だけではない。

  • 主要な言語ごとの SDK(TypeScript、Python、Go、Java など)
  • API の使い方を説明するドキュメント
  • コマンドで操作するための道具(CLI)
  • インフラ設定用の部品(Terraform)
  • AI エージェント向けの接続口(MCP サーバー)
  • 配布と更新の自動化(公開リポジトリへのリリース作業まで)

大事なのは、これらをばらばらにではなく、まとめて同時に用意していたことだ。API は頻繁に変わる。SDK だけ直してもドキュメントが古ければ結局つまずくし、ドキュメントだけ直しても配布物に反映されなければ誰も新しい方を使えない。Stainless は、仕様が変わるたびに人間用と AI 用の接続物を丸ごと作り直していた。だからこれは単なる「コードの自動生成」ではなく、SDK からドキュメント、配布までを一括で生産する工場だった。

OpenAPI 仕様が更新されると SDK を自動で再生成する Stainless の画面
出典: Stainless — SDKs product page(2026/5参照)

参考: Stainless SDKs / Stainless Series A 発表

3. 週1億ダウンロードは、表に出ないインフラの証拠

Stainless の規模は、利用者数では測りにくい。公式サイトには、稼働中の SDK が 1,000 以上、関連リポジトリに付いた開発者の評価の印(GitHub のスター)が 5.3 万以上、そして SDK の合計ダウンロードが週に 1.1 億回以上、と並んでいる。

この数字が示すのは、自社サービスの利用者数ではなく「配られた量」だ。Stainless が作った SDK が各社の公式パッケージとして組み込まれ、それが npm や PyPI といった配布の場で毎週ダウンロードされていく。利用者は Stainless の名前を意識していない。気づかないうちに、その生成物に支えられている。

顧客の顔ぶれも示唆的だ。OpenAI、Cloudflare、Replicate、Weights & Biases といった、AI や開発者向けサービスを売る会社が並ぶ。Anthropic の競合も含めて、各社の開発者向けの使い勝手を、一社で横断して支えていたことになる。

ここで、その一社である Anthropic の傘下に入る意味が見えてくる。すでに作られた SDK の所有権は顧客に残るが、これから先の作り直しを誰が担うかは別問題だ。AI を売る会社にとって、SDK とドキュメントは飾りではない。API がどれだけ早く使われるか、エージェントがどれだけ失敗せず動くか、開発者がどれだけ信頼するか、に直結する場所だからだ。

Stainless Customers 公式ページのOG画像
出典: Stainless — Customers page(2026/5参照)

参考: Stainless Customers / Stainless Series A 発表

4. AI に道具を渡すとき、数で攻めると失敗する

MCP は、AI エージェントに外部ツールの使い方を渡すための仕組みで、もともと Anthropic が提唱した。Stainless の作り方で面白いのは、この「ツールの渡し方」の設計だ。

ありがちなやり方は、API の機能ひとつひとつ(エンドポイント)を、そのまま別々のツールにする方式だ。「一覧を取る」「注文を出す」「契約内容を変える」といった操作を、片っ端からツールとして並べる。機能が少ないうちはこれで動く。ところが API が大きくなるとツールが数百個に膨らみ、エージェントは「どれを使えばいいか」で迷う。さらに、AI が一度に読み込める情報量(コンテキストウィンドウ)を、ツールの説明を読むだけで使い果たしてしまう。

Stainless はここを逆から解いた。エージェントに渡す中心のツールを、たった 2 つに絞っている。ひとつはドキュメントを検索するツール(search_docs)、もうひとつは自分で書いたコードを安全に隔離された場所で実行するツール(execute)だ。エージェントはまず説明を調べ、必要なコードを自分で書き、エラーが出たら直す。膨大な機能一覧を丸ごと覚えさせるより、その場で調べて書かせる方に寄せている。

この発想は、コードを書くのが得意になった最近のエージェントと相性がいい。そして MCP を作った当の Anthropic にとって、この知見は自社プラットフォームの設計にそのまま生きる。

ツールを2つに絞る方式が平均ツール呼び出し回数を最小に抑えることを示す Stainless のベンチマーク棒グラフ
出典: Stainless — MCP product page(2026/5参照)

参考: Stainless MCP / Stainless Docs Platform for agents

5. サービス終了で、顧客の関心は「乗り換え」に移った

Stainless 自身の発表によれば、これまでのホスト型サービスは終了する。買収と同じ日を境に、新規の登録も、新しいプロジェクトも、SDK の生成も止まる。

すでに使っている顧客は、生成済みの SDK を持ち続け、自由に手を入れられる。ただし「今あるコードを持っていること」と「これから先も作り直し続けられること」は、まったく別の話だ。

API は止まらず変わり続ける。新しい機能、仕様の変更、認証やデータの受け渡し方が、月単位で増えていく。そのたびに SDK もドキュメントも作り直して、足並みをそろえる必要がある。その作業を Stainless に任せていた会社は、いま乗り換え先を決めることになる。候補は Speakeasy や Fern といった競合サービス、あるいは自社で仕組みを抱える道だ。

短期的には、仕事の中心はこの乗り換え作業になる。もう少し長い目で見ると、「AI に使われても壊れない接続のしかたを、どう作るか」という設計の仕事に変わっていく。

参考: Stainless の参加発表 / Stainless SDKs

6. 自分なら、API を「エージェント対応」にする仕事を狙う

では、ここから自分なら何をするか。Stainless と同じものを正面から作るのは、正直かなり重い。言語ごとの仕組み、SDK の生成、配布、ドキュメント、AI 連携、セキュリティを、ずっと面倒見続けることになる。

一方で、その周りには現実的な機会がある。たとえば、API を持つ企業に向けて「うちの API は AI エージェントにちゃんと使えるか」を点検する仕事だ。OpenAPI 仕様、SDK、ドキュメント、MCP を、まとめて健康診断する。具体的にはこんな項目になる。

  • API の設計図(OpenAPI 仕様)に、抜けや分かりにくい点はないか
  • SDK を作る前提となる設定は整っているか
  • ドキュメントは、AI も読みやすい形になっているか
  • Claude Code や Cursor のような AI ツールで、連携作業が実際に成功するか
  • AI に操作させたとき、権限や記録が安全に保たれるか
  • API を更新したとき、SDK・配布・ドキュメントが自動でそろうか

以前 Quartr を、決算情報を整えて供給する層として見た。Stainless はそれと同じ構図で、API 利用を支える供給層として読むと分かりやすい。Whop のようなマーケットプレイスでも、根っこは同じだ。エージェントが企業のサービスを直接操作する世界になれば、API とドキュメントの質が、そのまま入口の良し悪しになる。

この買収は、エージェントが画面の上で何かをクリックする話にとどまらない。企業の API が、AI に読まれ、書かれ、実行される時代に向けた一手として見ると、意味がはっきりする。

まとめ:Stainless 買収を 6 点で整理する

  1. Anthropic が買ったのは SDK 会社ではなく「つなぐ力」。エージェントが外で働くには、SDK・ドキュメント・AI 連携がそろっている必要がある
  2. Stainless は SDK とドキュメントを丸ごと作る工場だった。OpenAPI 仕様から、SDK・ドキュメント・配布までを一度に作り直す
  3. 週1.1億ダウンロードは「表に出ないインフラ」の証拠。生成された SDK が各社の公式パッケージとして広く使われていた
  4. AI へのツールの渡し方が巧み。機能を全部並べず、「調べる」「実行する」の 2 つに絞ってエージェントに使わせる
  5. 買収後の顧客の関心は乗り換え。既存の SDK は残るが、これから先の作り直しは代わりが要る
  6. 事業機会は API のエージェント対応。仕様の点検、ドキュメント、AI 連携の評価をまとめて引き受ける余地がある

参考リンク

この記事は、調査・記事制作に特化したAIエージェントと、人の編集で作っています

調査、構成、執筆、更新管理の一部にAIエージェントを取り入れています。 事業や組織へのAI導入を、実務に合わせて検討したい場合はご相談ください。

AI導入について相談する