Apollo Studioは、GraphQL APIのスキーマ管理・クエリ実行・性能分析をブラウザで行うApollo社のWebツールです。2026年10月時点では「GraphOS Studio」という名称で、Apollo GraphOSプラットフォームの管理画面として提供されています。URLは今も studio.apollographql.com のままです。なお、検索結果に並ぶLaunchpad用のソフトウェア「Apollo Studio」や同名の撮影スタジオとは無関係です。この記事では、アカウント不要のApollo Sandboxでの動作確認、Rover CLIによるスキーマチェック、4つの料金プランの違いを、公式ドキュメントと手元での実行結果をもとに整理します。
まとめ:Apollo Studioの現在地と使い始める順番
- Apollo Studioは2020年6月にGraph Managerから改称され、現在はGraphOS Studioとして提供されています。
- 試すだけならアカウント登録は不要です。Apollo Sandboxが
http://localhost:4000に自動接続し、イントロスペクションでスキーマを読み込みます。 - 本番モード(
NODE_ENV=production)のApollo Serverではイントロスペクションが無効になるため、Sandboxにスキーマが表示されません。 - スキーマレジストリとスキーマチェックが、IDE単体のGraphiQLやPostmanとの決定的な違いです。CIではRover CLI(2026-10-06に1.0.0)を使います。
- 料金はFree・Developer(100万リクエストあたり5ドルから)・Standard・Enterpriseの4プランです。Freeは操作履歴が1日しか残らず、セルフホストRouterも毎分60リクエストに制限されます。
以下、構成要素、Sandboxの手順、Explorer、スキーマチェック、料金、他ツールとの使い分けの順に説明します。
Apollo StudioからGraphOS Studioへの改称と現在の構成要素
名称は2度変わっています。Apolloの公式ブログによると、2020年6月29日に「Apollo Graph Manager」が「Apollo Studio」へ改称されました。2022年10月5日にはプラットフォーム全体がApollo GraphOSとして発表され、Studioはその管理画面(GraphOS Studio)という位置付けになりました。日本語の解説記事で「Apollo Studio」と書かれていても、指している画面は同じです。
GraphOSはStudio単体の製品ではなく、次の部品の組み合わせです。版は2026年10月9日にGitHubのリリース一覧とnpmで確認しました。
| 部品 | 役割 | 現行版・状態 |
|---|---|---|
| GraphOS Studio | Web管理画面 | SaaS(版番号なし) |
| Apollo Sandbox | アカウント不要のStudio | SaaS・オフライン可 |
| Rover CLI | スキーマの公開とチェック | 1.0.0(2026-10-06) |
| GraphOS Router | Federationのゲートウェイ | 2.18.0/3.0はPreview |
| Apollo Server | Node.jsのGraphQLサーバー | 5.5.1(v4は2026-01-26にEOL) |
GraphOS Routerは2026年10月7日に3.0がPreviewとして発表されたばかりで、安定版は2.18.0です。RouterのソースコードはElastic License 2.0で公開されています。Federationの仕組みそのものはGraphQLフェデレーションの解説記事で扱っているので、この記事ではStudio側の機能に絞ります。
アカウント不要のApollo Sandboxでローカルサーバーに接続する手順
Apollo Sandboxは、GraphOS Studioをアカウントなしで使うモードです。Sandboxの公式ドキュメントでは、稼働中のGraphQLサーバーからイントロスペクションでスキーマを取得し、Explorer・スキーマリファレンスを提供すると説明されています。一度オンラインで開いたブラウザなら、localhost 相手に限りオフラインでも動きます。
Apollo Server 5を4000番ポートで起動するコード例
Sandboxは開いた時点で http://localhost:4000 への接続を試みます。Apollo Server 5(@apollo/server 5.5.1)の startStandaloneServer を4000番で起動すれば、追加設定なしでつながります。
npm install @apollo/[email protected] [email protected]
次のコードを server.mjs に保存します。
// server.mjs
import { ApolloServer } from '@apollo/server';
import { startStandaloneServer } from '@apollo/server/standalone';
const typeDefs = `#graphql
type Book {
id: ID!
title: String!
author: String
}
type Query {
books: [Book!]!
}
`;
const resolvers = {
Query: { books: () => [{ id: '1', title: 'GraphQL入門', author: 'Ada' }] },
};
const server = new ApolloServer({ typeDefs, resolvers });
const { url } = await startStandaloneServer(server, { listen: { port: 4000 } });
console.log(`ready at ${url}`);
Node.js 26.5.0で node server.mjs を実行すると「ready at http://localhost:4000/」と表示されました。ブラウザで同じURLを開くと、Apollo Serverのランディングページに埋め込みSandboxが表示されます。エディタに query { books { id title author } } を入力して実行すると、IDが1、タイトルが「GraphQL入門」、著者が「Ada」のデータを取得できます。このページのHTMLは embeddable-sandbox.cdn.apollographql.com からスクリプトを読み込み、接続先を window.location.href(自分自身のURL)に設定していました。外部CDNへの通信を遮断した社内ネットワークでは、この埋め込みSandboxは表示されません。
URLパラメータで接続先とクエリを指定する方法
4000番以外のポートやリモートのエンドポイントを使うときは、Sandboxの上部の入力欄でURLを変えるか、URLパラメータで初期状態を渡します。公式に対応しているのは次の4つです。
| パラメータ | 指定する内容 |
|---|---|
endpoint |
接続先URL(既定は localhost:4000) |
document |
エディタに入れる操作 |
variables |
変数(JSON) |
headers |
HTTPヘッダー(JSON) |
たとえば https://studio.apollographql.com/sandbox/explorer?endpoint=http://localhost:4200 を開くと、4200番のサーバーに接続した状態で始まります。値はURLエンコードしてから共有するよう公式ドキュメントは勧めています。チームのREADMEにこの形式のリンクを置いておくと、新しいメンバーが接続先を間違えません。
本番モードでSandboxにスキーマが出ない原因
同じサーバーを NODE_ENV=production で起動すると、ランディングページとイントロスペクションの既定の挙動が変わります。ランディングページから埋め込みSandboxが消え、イントロスペクションのクエリは次のエラーで拒否されます。
GraphQL introspection is not allowed by Apollo Server, but the query contained __schema or __type.
To enable introspection, pass introspection: true to ApolloServer in production
この状態でSandboxやRoverの rover graph introspect を向けてもスキーマは取れません。Roverは「No data field provided」で終了しました。本番のスキーマを確認したいなら、イントロスペクションを開けるより、CIでスキーマファイルをGraphOSのレジストリに公開し、Studio側で参照する方が安全です。
本番モードとは別の注意点として、開発・本番のどちらでも、必要なヘッダーを付けずにGraphQLのGETリクエストを送ると、既定のCSRF防止機能により400で拒否されます。content-type: application/json を付けたPOSTか、apollo-require-preflight ヘッダーを付ければ通ります。Sandboxでは実行できるのに curl では400になる場合は、このヘッダー条件を疑ってください。
Explorerの操作で知っておきたい機能とCORS・認証の設定
Explorerは、Sandboxとログイン後のStudioの両方にあるクエリ実行用のIDEです。公式ドキュメントでは全GraphOS組織で無料とされ、Query・Mutation・Subscriptionの3種類の操作に対応しています。エディタはVS Codeと同じMonacoで作られており、補完・構文チェック・定義へのジャンプが使えます。
クエリの組み立て、スキーマ検索、操作の共有、ヘッダー設定に使う機能を順に紹介します。
- Documentationタブ:フィールド横の「⊕」を押すと、カーソル位置のパスにフィールドが追加され、引数用の変数も自動生成されます。
⌘+Kの検索:User.emailのように「型.フィールド」で絞り込め、エントリーポイントからの経路まで示されます。- 操作ごとのメニュー(•••):整形、共有リンクのコピー、
curlコマンドの生成ができます。 - Headers・Variables・環境変数のパネル:内容はセッションをまたいで保持されます。
公開エンドポイントに接続するときのCORS設定
Explorerはブラウザから直接エンドポイントへリクエストを送ります。CORSを設定している本番APIに接続する場合は、許可するオリジンに https://studio.apollographql.com を加える必要があります。CORS設定を変えられないなら、プロキシを立ててExplorerをそちらに向ける方法が公式に案内されています。Cookie認証を使う場合は、Cookieに SameSite=None; Secure を設定し、サーバーの応答に Access-Control-Allow-Credentials: true を付けます。Explorer側でもCookie送信を有効にし、ブラウザの第三者Cookie制限を確認してください。
プリフライトスクリプトで認証トークンを自動更新する設定
OAuthのアクセストークンのように期限があるヘッダーは、環境変数とプリフライトスクリプトで扱います。ヘッダーの値に Bearer {{token}} と書くと、環境変数 token の値が差し込まれます。スクリプトは操作の実行前に動き、explorer.fetch や explorer.environment.set を使えます。
// プリフライトスクリプトの例(トークン発行APIは自社のものに置き換える)
const res = await explorer.fetch('https://auth.example.com/token', {
method: 'POST',
headers: { 'content-type': 'application/json' },
body: JSON.stringify({ clientId: explorer.environment.get('clientId') }),
});
explorer.environment.set('token', res.json().access_token);
スクリプトからのリクエストは https://preflight-request.apollographql.com というオリジンから送られます。トークン発行API側でこのオリジンを許可していないと、CORSエラーで失敗します。プリフライトスクリプトはグラフのバリアントごとに1つ設定でき、そのバリアントに対するExplorerの全操作で実行されます。
スキーマレジストリとスキーマチェックで破壊的変更を止める仕組み
Studioを単なるIDEと分けるのはこの機能です。スキーマをGraphOSのレジストリへ公開し、サーバーやRouterから操作の利用データをGraphOSへ送信すると、変更案を収集済みの操作と照合できます。掲載例のApollo Serverでは、CIとは別にサーバー側にも APOLLO_KEY と APOLLO_GRAPH_REF を設定し、利用データの送信(usage reporting)を有効にする必要があります。未収集の操作への影響は判定できません。Sandboxからもログインすれば、ローカルのスキーマとレジストリ上のグラフとの差分表示とチェック実行ができます。
既定で実行される3種類のチェックと判定に使う期間
スキーマチェックを1回実行すると、既定でbuild、operations、linterの3種類のチェックが走ります。buildチェックはスキーマが正しく組み立てられるかの確認で、失敗すると後続のチェックは実行されません。operationsチェックは過去の操作と照合し、結果をBroken・Potentially affected・Unaffected・Safe・Ignoredの5状態に分けます。
照合に使う期間の既定値は7日で、その期間に1回以上実行された操作が対象です。ただし遡れる期間はプランの保持期間が上限になります。Freeプランの保持期間は1日なので、週1回しか呼ばれない管理画面の操作は、チェックの対象にほぼ入りません。本番APIの変更をチェックで守りたいなら、少なくともDeveloperプラン(7日)が前提です。
Rover 1.0でGitHub Actionsにチェックを組み込む手順
CIでは APOLLO_KEY にグラフのAPIキーを入れ、Roverでチェックと公開を行います。Rover 0.39.1(2026-05-20)からは --check を付けた publish で、チェックに通ったときだけ公開できるようになりました。チェックと公開を別コマンドで実行すると、その間に他のメンバーが別の変更を公開する競合が起こりうるため、公式ドキュメントは一体化した実行を勧めています。
# .github/workflows/schema.yml
name: schema
on: pull_request
jobs:
check:
runs-on: ubuntu-latest
env:
APOLLO_KEY: ${{ secrets.APOLLO_KEY }}
APOLLO_VCS_COMMIT: ${{ github.event.pull_request.head.sha }}
steps:
- uses: actions/checkout@v4
- uses: apollographql-gh-actions/[email protected]
- run: rover graph check my-graph@current --schema ./schema.graphql
# main へのマージ後に実行する公開ステップの例
# rover graph publish my-graph@current --schema ./schema.graphql --check
チェックに失敗すると、Roverはエラーコード E043 で終了し、ジョブが失敗します。手元でAPIキーを設定せずに rover graph check を実行すると、E020(設定プロファイルがない)で止まりました。ローカルでは rover auth login(1.0.0で追加されたOAuthログイン)か rover config auth で認証してから実行します。
Rover 1.0.0のリリースノートによると、互換性のない変更が3点あります。Federation 1のサポート削除、rover cloud コマンドの削除、そして --format json の出力形式の変更(json_version が3に上がった)です。チェック結果のJSONをスクリプトで解析しているCIは、0.x系から上げる前に出力形式を確認してください。スキーマ自体の設計方針はGraphQLスキーマ設計のベストプラクティスにまとめています。
料金プラン4種の違いと無料プランで足りる範囲
2026年10月9日時点の公式料金ページでは、プランはFree・Developer・Standard・Enterpriseの4つです。差が出るのは利用人数、データの保持期間、一部の機能です。
| 項目 | Free | Developer | Standard | Enterprise |
|---|---|---|---|---|
| 料金 | 無料 | 100万件あたり5ドルから | 個別見積もり | 個別見積もり |
| 利用人数 | 3人まで | 10人まで | 30人まで | 無制限 |
| 操作履歴(チェック・分析) | 1日 | 7日 | 90日 | 18か月 |
| トレース | 1日 | 7日 | 90日 | 90日 |
| セルフホストRouter | 毎分60リクエスト | 制限なし | 制限なし | 制限なし |
| Contracts・Studioのlint | なし | あり | あり | あり |
| SSO・Schema Proposals | なし | なし | あり | あり |
| サポート | コミュニティ | 平日8時間・SLAなし | 平日8時間・SLAあり | 24時間365日 |
Developerは従量課金です。QueryとMutationの月間件数に対し、最初の2億5,000万件が100万件あたり5.00ドル、次の7億5,000万件が4.25ドル、次の40億件が3.50ドル、50億件超が3.00ドルです。Response Cachingなどを有効にすると、性能アドオンとして100万件あたり2.00ドル(最初の帯)が加わります。新規登録時には50ドル分のクレジットが付きます。月1,000万件ならアドオンなしで約50ドルなので、最初のクレジット分は1か月ほどで使い切る計算です。
注意点が1つあります。カスタムチェックは、料金ページの機能表ではDeveloper以上で使えると書かれていますが、スキーマチェックの解説ページには「Enterpriseプランが必要」とあり、記述が食い違っています。カスタムチェックを前提に設計するなら、契約前に営業窓口で確認してください。
Freeで足りるのは、個人の学習や、Sandboxでローカルのサーバーを触るだけの使い方です。公式ドキュメントによると、FreeプランでオンラインのSandboxを使うと、Sandbox自身が送る付随リクエストも毎分60件の上限に数えられ、ピーク時には1分で約40件に達します。複数人で同じRouterを叩くと、すぐ上限に当たります。
GraphiQL・Postmanとの使い分けとApollo Studioが過剰になる条件
クエリを実行するIDEとしてだけ見るなら、Apollo Studioを選ぶ理由はあまりありません。判断の軸は「スキーマの変更をレジストリで管理したいか」です。
| 観点 | Apollo Studio | GraphiQL | Postman |
|---|---|---|---|
| 提供形態 | SaaS(Sandboxは登録不要) | OSS(npm graphiql 5.4.0) | デスクトップ・Web |
| スキーマレジストリ | あり | なし | なし |
| 破壊的変更のチェック | 実操作と照合 | なし | なし |
| REST APIのテスト | 対象外 | 対象外 | 主用途 |
| 外部通信なしの運用 | Sandboxのみ条件付き可 | 自前ホストで可 | 軽量APIクライアントで可 |
次の条件に当てはまるなら、Apollo Studioの導入は過剰です。
- クライアントが自社の1アプリだけで、スキーマ変更とクライアント改修を同時に配備でき、旧版クライアントも残らず、結合テストで互換性を確認できる。この条件なら、operationsチェックを追加する優先度は低くなります。
- 外部SaaSへの通信が禁止された閉域網で開発している。Sandboxの埋め込みはCDNから読み込まれ、チェックはGraphOSのクラウドで実行されます。
- APIの大半がRESTで、GraphQLは一部だけ。REST・GraphQLの両方を1つのコレクションで管理でき、NewmanでCIにも組み込めるPostmanの方がまとまります。
反対に、複数のクライアント(Web・iOS・Android・外部パートナー)が同じスキーマを使い、どの変更がどのクライアントを壊すかを人手で追えなくなった段階が導入の目安です。この段階ではFreeの1日保持では足りないので、Developer以上で検討します。クライアント側の実装はApollo Clientの解説記事、型の自動生成はGraphQL Code Generatorの解説記事が参考になります。
よくある質問
Apollo Studioは無料で使えますか?
使えます。Apollo Sandboxはアカウント登録なしで使え、ローカルのGraphQLサーバーに接続してクエリを実行できます。アカウントを作った場合もFreeプランは無期限・クレジットカード不要です。ただしFreeは利用者3人まで、操作履歴とトレースの保持が1日、セルフホストのGraphOS Routerが毎分60リクエストまでという制限があります。チームで本番APIのスキーマチェックに使うなら、7日分の履歴が残るDeveloperプラン(100万リクエストあたり5ドルから)以上が現実的です。
Apollo StudioとApollo Sandboxの違いは何ですか?
Apollo Sandboxは、GraphOS Studioをアカウントなしで使う特別なモードです。Sandboxは稼働中のサーバーからイントロスペクションでスキーマを読み込みます。ログイン後のStudioは、GraphOSのレジストリに公開されたスキーマを参照します。Explorerとスキーマリファレンスは両方で使えますが、メトリクスやチェック履歴などレジストリに紐づく機能はログインが必要です。Sandboxでもログインすれば、ローカルのスキーマとレジストリ上のグラフの差分表示やチェックができます。
Apollo GraphOSとは何ですか?
Apollo GraphOSは、2022年10月5日に発表されたApollo社のGraphQLプラットフォームの総称です。管理画面のGraphOS Studio(旧Apollo Studio)、スキーマレジストリ、Federationのゲートウェイを担うGraphOS Router、CLIのRoverなどで構成されます。2026年10月時点ではRouterの安定版が2.18.0、Roverが1.0.0です。Apollo Server・Apollo ClientはGraphOSなしでも単独で使えるOSSライブラリです。
本番環境のサーバーにSandboxから接続できないのはなぜですか?
Apollo Serverは NODE_ENV=production のとき、既定でイントロスペクションを無効にします。Sandboxはイントロスペクションでスキーマを読み込むため、本番サーバーではスキーマが表示されません。introspection: true を渡せば有効にできますが、イントロスペクション要求が認証やネットワーク制限を通過できる利用者は、スキーマ情報を取得できるようになります。本番のスキーマはRoverでGraphOSのレジストリへ公開し、ログインしたStudioで参照する運用を勧めます。CORSで https://studio.apollographql.com を許可していない場合も接続に失敗します。
Apollo Studioのスキーマチェックをローカルで試すには何が必要ですか?
GraphOSのアカウントと、スキーマを公開済みのグラフが必要です。Rover CLIを入れ、rover auth login か rover config auth で認証してから、rover graph check グラフ名@バリアント --schema ./schema.graphql を実行します。認証せずに実行するとエラーコード E020 で止まります。ブラウザで試すなら、Sandboxにログインして左メニューのChecksから実行することもできます。なお、Consumerロールのメンバーはチェックを実行できません。