先に結論
SupabaseでGraphQLを使っているなら、6月15日以降に作る新規projectでGraphQL explorerやcodegenがそのままでは動かなくなる可能性があります。
今回変わるのは、pg_graphql 1.6.0からintrospectionが既定で無効になることです。__schema や __type に依存する開発ツールは影響を受けますが、accountCollection のような通常のdata queryは止まりません。
最初に確認したいのは次の3点です。
- 6月15日以降に新規projectを作る予定があるか
- GraphiQLやgraphql-codegenに依存しているか
- schema commentでintrospectionを戻す運用にできるか
何が変わったのか
Supabaseは2026-05-25のchangelogで、2026-06-15以降に作る新規projectではpg_graphql 1.6.0以上が入り、GraphQL introspectionを既定で無効にすると案内しました。
これまで __schema と __type は追加設定なしで使えました。今後は、明示的にopt-inしない限りエラーになります。
一方で、既存projectはすぐには変わりません。Supabaseの説明では、既存projectはpg_graphql 1.6.0以上へ上げるまで現在の挙動を維持します。
先に影響を受けるツール
真っ先に見るべきなのは、schema introspectionを前提にした開発ツールです。
Supabaseが具体例として挙げているのは次の用途です。
- Supabase StudioのGraphQL explorer
- 外部のGraphiQLやGraphQL Playground
- Apollo DevTools
- Relay compiler
- graphql-codegen
__schemaや__typeを直接たたく独自tool
ここで大事なのは、本番API全体が止まるわけではないことです。GraphQL schemaを読むための補助機能が止まりやすくなる、という理解のほうが正確です。
通常のqueryは止まらない
この変更は重いですが、影響範囲は限定されています。
Supabaseは、accountCollection や insertIntoAccountCollection のような通常のdata queryは設定に関係なくそのまま動くと案内しています。
つまり、利用者向けの機能がすぐ落ちるというより、開発・検証・schema把握のフローが先に詰まりやすい変更です。GraphQL explorerやautocompleteに頼っているチームほど先回りしておく価値があります。
戻し方はschema commentで足りる
対応自体は複雑ではありません。対象schemaごとに、introspectionを明示的に有効化します。
comment on schema public is e'@graphql({"introspection": true})';すでに inflect_names のようなschema commentを使っているなら、設定を上書きせず同じJSONにまとめます。
comment on schema public is e'@graphql({"inflect_names": true, "introspection": true})';新規projectを作った直後にGraphiQLやcodegenが動かないと調査が長引きがちです。GraphQLを使う前提なら、project bootstrap手順にこの設定確認を入れておくほうが安全です。
なぜ既定でOFFになるのか
Supabaseが挙げている理由は明快です。introspectionはAPI surface全体を見せるため、到達できる相手にはtype、field、relationshipの情報まで渡してしまいます。
既定でOFFにすれば、private schemaの露出を抑えやすくなります。便利さより、まず公開面を絞る方向へ寄せた変更だと考えると分かりやすいです。
いますぐやるチェックリスト
短く言うと、やることは次の順です。
- 6月15日以降に新規Supabase projectを作る予定があるか確認する
- GraphiQL、Apollo DevTools、Relay、graphql-codegenの依存有無を洗う
- 独自scriptが
__schemaや__typeをたたいていないか見る - 必要ならschema commentでintrospectionを有効化する
- project作成手順や社内runbookにこの設定を追記する
この変更は、後から気づくよりproject作成前に見つけたほうがずっと軽く済みます。
Supabaseを比較検討している人へ
今回の変更だけでSupabaseを避ける理由にはなりません。むしろ、運用上の前提を公式が早めに明示しているという見方もできます。
ただし、backendを比較する読者にとっては、機能一覧よりこうした運用差分のほうが後で効きます。候補全体を見直したいなら、AIエージェント時代のbackend比較記事も合わせて見ると判断しやすいです。
また、Supabase運用で直近もう1つ重い変更として、Postgres 14サポート終了の記事も出ています。GraphQLまわりとあわせて、runbook更新をまとめて済ませるほうが効率的です。
まとめ
Supabaseのpg_graphql 1.6.0で変わるのは、GraphQLそのものよりschema introspectionを前提にした開発体験です。
6月15日以降の新規projectでは、explorerやcodegenがそのままでは詰まる可能性があります。既存projectは即時影響なしですが、将来upgradeした時点で同じ論点が出ます。
GraphQLを使うなら、今のうちに依存toolを洗い、必要なschemaでだけintrospectionを戻す運用へ寄せておくのが安全です。