Unkey、API key管理から「ship APIs, not infrastructure」へ広げた開発者基盤

James PerkinsとAndreas Klingerは、APIを公開するたびに認証、rate limiting、usage trackingを別々に組み立てる不満からUnkeyを始めた。

Perkinsは「開発者はintegratorになりたいのではなく、shipしたい」と説明している。出典

狭い入口から始める

2023年6月の公開時点で、UnkeyはAPI key管理という明確な課題に絞った。

公開後には1,200 GitHub stars、1,600 users、1,300万回超のverificationを記録した。出典

転機・苦労

認証をcritical pathに置くほど、serverlessのcache latencyが壁になった。

チームはCloudflare Workersからstateful Go serversへ移り、end-to-end latencyを6倍改善した。出典

成長・成功

API keyだけでなく、gateway、rate limiting、analyticsへ広げた後、Deployを加えた。

$4.5M seedの発表では、auth、rate limiting、billing、observabilityを別々に持つAPIチームへ、ひとつのcontrol planeを提案している。出典

現在地

Unkeyは「ship APIs, not infrastructure」という立場で、real serversの予測可能性とgit pushの体験を組み合わせる。

狭いAPI primitiveから、公開・保護・計測までのworkflowへ進んだことが、同社の現在のポジションを作っている。出典

APIを製品として提供する小規模チームは、deploy、API key、rate limit、analyticsを別々に運用する余裕がない。

Unkeyはこの分断を一つのcontrol planeにまとめる。出典

Deploy public betaやfree tierは導入障壁を下げる一方、インフラの信頼性が価値の前提になる。

API keyのverification・policy・usage dataを同じcontrol planeで蓄積することが主な障壁。

ただしOSSにより機能自体は模倣可能で、信頼性と運用データが差別化になる。

弱い。

API利用者が増えるほど直接的なnetwork effectが発生するモデルではなく、導入事例とSDK・OSSの採用が間接的に効く。

APIを自社製品として提供するstartup、AI APIを運営するチーム、authやrate limitの内製を避けたいbackend developers。

単純な静的サイトには過剰。

狭いAPI keyから入り、利用データをもとにgatewayとDeployへ隣接拡張したこと。

GitHub・docs・OSSを組み合わせ、開発者が試して理解できる導線を作った。出典

インフラを一つに束ねるほど、障害時のblast radiusと運用責任は大きくなる。

Deployはpublic betaで、Analyticsもprivate betaのため、成熟度と提供範囲は要確認。出典

GitHubとOSSでAPI primitiveを試してもらい、docsとfree tierでself-serve導入を促す。

そこからDeploy、gateway、analyticsへ拡張し、複数ツールの統合コストを削減する。出典

主要チャネル: github, content, community, productLedGrowth

最初から「全部入り」を売るのではなく、API keyという明確な痛みから入り、隣接する運用課題へ広げる戦略が参考になる。

技術選択をserverlessからGoへ戻した点も、流行よりcritical pathの実測を優先した例だ。出典

日本のSaaSでもAPIを顧客へ公開する場面が増えた。

認証、rate limit、usage-based billing、docsを個別実装する負担を、国内リージョンや日本語サポートと組み合わせれば導入余地がある。

ただしデータ保管と障害対応の要件は要確認。