Nango、900以上のAPI連携をAI agent向けのcode-first基盤へ変えた設計

Nangoの共同創業者Robin Guldenerらは、まず完成されたCloudを持っていたわけではない。

2023年のHacker News launchでは、open-source repoしかない状態でTypeform登録を受け、Render上に利用者ごとのserverとdatabaseを手動で立ててAPI keyを返した。

24時間で約200台のVMが動いたという。出典

この荒い始まりは、integrationの痛みが実在することを示した一方、手作業では伸びないことも明らかにした。

NangoはAPI authenticationのOSSから、OAuth、credential refresh、sync、webhook、tool callingを扱うplatformへ段階的に広げた。出典

次の壁は、顧客が書くuntrusted codeだった。

初期はvm2のin-process sandboxを使ったが、脆弱性を受けて別runnerへ分離し、後にtenant-isolated AWS Lambdaへ進化させた。

月1.5億回超のfunctionを動かすには、便利さだけでなく隔離とコストの両立が必要だった。出典

さらにNangoは、Temporalを使っていたschedulerをPostgresベースへ置き換えた。

汎用workflowの機能を持ち込むより、実際の負荷とenterpriseの導入障壁に合わせて単純化する選択だった。出典

そして2026年、NangoはGradient主導の$7.5M seedを発表し、900以上のAPI、数千のengineering team、AI agent向けMCPへ焦点を移した。

Robin Guldenerらの道のりは、connectorを増やす物語ではなく、顧客のコードを安全に実行できるintegration runtimeへ、制約のたびに設計を変えた物語と言える。出典

B2B SaaSが顧客ごとに異なるCRM・support・calendar APIを接続する痛みを、NangoはAuth、Functions、Syncs、Webhooks、MCPへ分解して吸収する。

900以上のAPIとcode-firstの拡張性が、事前構築connectorの硬さと自前実装の遅さの間を埋める。出典

顧客の要求をintegration codeとしてレビュー・version controlできるため、AI coding agentで作るプロダクトとの相性も良い。

API接続を単なるconnector catalogではなく、実行・監視・tenant isolationまで含むruntimeとして提供する点がPMFの核だ。出典

最大のmoatは、APIごとの認証・pagination・sync・webhookの実装知識と、顧客コードを安全に実行する運用データの蓄積だ。

900以上のAPI catalogとtemplate、logs、retry、tenant isolationが一体化すると、単なるSDKより移行コストが高くなる。出典

network effectは中程度。

接続数が増えるほどcatalogの価値と要望データは増えるが、API providerや顧客が相互に参加しないと機能しない強い二面市場ではない。

OSS利用者とcontributorが新APIを補う間接的な効果が中心だ。出典

顧客向けintegrationを持つSaaS、AI agentを外部システムへ接続するteam、複数tenantのOAuthを運用するdeveloperが中心。

単一APIの一度きりの内部scriptや、integration自体がcore moatになる大企業には自前実装が適する場合もある。

第一に、Auth・credential refresh・rate limit・retryなど散らばる運用負荷を一つのplatformへ束ねたこと。出典

第二に、pre-built integrationだけでなくTypeScript Functionsとして顧客固有の処理を書けること。

第三に、OSSとGitHub、Hacker News、技術ブログを組み合わせ、developer-firstで信頼を積み上げたこと。出典

integrationはproviderごとの仕様変更とOAuthの例外に依存し、900以上のAPIを保守するコストは高い。

顧客コードを実行する以上、sandbox escapeやtenant間の情報漏えいは重大リスクであり、実際にvm2の脆弱性を契機にin-process sandboxを捨てている。出典

また、TemporalからPostgresへ移行した事実は、汎用workflow基盤が全てのstageに最適とは限らないことを示す。出典

OSS repoとHacker Newsでdeveloperを獲得し、無料CloudでAuthやFunctionsを試してもらい、接続数・proxy requests・実行時間などのusageへ拡張する。

AI agentとMCPを前面に出すことで、従来のSaaS integrationだけでなくAI productのtool accessへ市場を広げた。出典

ただしusage課金は予測可能性を損ねるため、Enterpriseのsecurity・SLA・self-hostingを明確にする必要がある。

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

platformはconnector数だけで勝てない。

認証、実行、監視、失敗時の再実行、tenant isolationまでを一つの運用面として提供して初めて、顧客の「作る」だけでなく「壊さず運ぶ」痛みに届く。

AIでcode生成が速くなっても、credentialとruntimeの責任は残る。

日本ではSaaS間連携の要件が顧客企業ごとに細かく、SIerや業務ソフトとの接続が導入障壁になりやすい。

Nango型を展開するなら、国内会計・CRM・人事APIのtemplateと、個人情報を国内環境で扱えるself-hosting・監査機能が重要になる。

これは市場構造からの示唆であり、Nangoの国内実績を示すものではない。