Apollo GraphQLはGraphをAPI開発の共有基盤へどう変えたか

冒頭：Graphを共有基盤にする

Apollo GraphQLは、GraphQLのclient/server libraryから、schema・federation・router・metricsを束ねるAPI orchestration platformへ広がった。

2021年の公式発表では、ApolloのOSSが月間1,700万downloads、Apollo graphが1日60億queriesを処理していた。出典

創業：アプリとデータの間をつなぐ

創業者Geoff Schmidtは、Apollo GraphQLをGraphQLとMeteorの経験から育てた。

ApolloのleadershipページはGeoff SchmidtをFounderとして掲載している。出典

GraphQLを単なるquery languageではなく、アプリが複数のbackendからデータを取得するための共有契約として位置づけたことが出発点だった。

転機：OSSの採用を企業の運用へ

OSS libraryだけでは、teamが増えたときschemaの変更や複数serviceの統合が難しくなる。

ApolloはFederation、schema management、Routerを整え、graphを段階的に統合する道具へ広げた。出典

2019年には$22M、2021年には$130Mの調達を発表し、OSSとGraph platformへの投資を拡大した。出典

成長・成功：GraphOSへ

Geoff Schmidtは公式の調達発表で「The graph is a new layer of the stack」と説明し、graphをclientとmicroservicesをつなぐ共有層として描いた。出典

ここでApolloは、開発者が使うOSSと、企業が安全に変更を管理する有料platformを接続した。

GraphOSはFreeからDeveloper、Standard、Enterpriseへ広がり、Developerは100万requestsあたり$5から始まる。出典

結び：APIを組織の契約にする

Apolloの道のりは、流行するquery languageを売った話ではない。

複数teamが同じschemaを読み、変更を検証し、clientへ届ける運用面まで製品化した話だ。

日本のPdMが持ち帰れるのは、開発者向けOSSの採用後に発生する「壊さずに広げる」問題を、別のplatformとして設計する視点である。

ApolloのPMFは、複数のbackend serviceをまたぐアプリ開発チームの「必要なデータを毎回個別APIでつなぐ」痛みにある。

GraphQLはclientが必要なデータを一つのqueryで要求し、Apollo FederationとGraphOSは複数teamのschemaを共有可能なgraphへ束ねる。出典

その結果、APIを単なるendpoint集合ではなく、組織横断の開発契約として扱える。

moatは、OSSの普及で蓄積されたschema・operation・federation運用の知識と、それをGraphOSへ接続する開発者workflowの組み合わせにある。出典

単独のGraphQL libraryは代替できても、組織のgraph運用データと習慣まで一度に移すのは難しい。

ネットワーク効果は中程度。

GraphQL schemaを共有するteamやsubgraphが増えるほど統合graphの便益は大きくなる一方、外部ユーザーが増えるほど自動的に価値が増すmarketplace型ではない。

社内team・client・serviceの接続密度が価値を押し上げる。出典

主対象は、複数のbackend serviceとweb/mobile clientを持つ中堅〜大企業のplatform・frontend・backend team。

小規模な単一service APIやGraphQLを試すだけの個人にはFreeで足りるが、schema governanceやfederationを組織で運用したいチームほどGraphOSの価値が高い。出典

成功要因は三つある。

第一にApollo Client、Server、RouterなどOSSの入口を広くしたこと。出典

第二にFederationで既存serviceを段階的に統合できるようにしたこと。出典

第三にschema checksやmetricsをGraphOSへ集約し、導入後の運用品質を有料化したこと。出典

リスクはGraphQLそのものの学習・運用コストと、統合graphの設計負債である。

Apollo自身も複数のunconnected graphを増やすことが弱点になり得ると説明している。出典

GraphOSの価値はschema governanceに依存するため、組織内の所有者や契約が曖昧なチームでは導入効果が出にくい。

これは公開情報からの分析であり、顧客ごとの成果は要確認だ。

成長はOSSとdeveloper educationを入口にし、production運用のgovernanceへ拡張するland-and-expand型だ。

Apolloは2021年の資金調達記事で、Apollo ClientやFederationのOSS、複数言語対応、team拡大を明示した。出典

現在はGraphOSのusage-based pricingとenterprise supportで、利用量・team数・運用要件に合わせて課金を広げる。

主要チャネル: open_source, documentation, developer_relations, content_marketing, community, enterprise_sales, ecosystem

プロダクトの境界をlibraryから運用platformへ移すと、OSSの採用を失わずに企業課題へ近づけられる。

Apolloの示唆は、技術標準を押さえるだけでなく、schema checks・metrics・routerのような「使い続けるための面」を商品化することだ。出典

ただし、platform化は導入の意思決定者を増やすため、開発者価値と組織ガバナンスを同時に説明する必要がある。

日本で展開するなら、既存の業務serviceが多く、web・mobile・partner APIを別々に運用する企業のAPI統合を入口にしやすい。

GraphQL導入そのものではなく、schema ownership、変更影響の可視化、複数teamの合意形成を日本語の導入支援とセットで売るべきだ。

金融・小売・メディアなど複数チャネルを持つ企業で、GraphOSの監査・権限・SLAを具体的な業務課題に結びつける必要がある。