GraphQL接続の落とし穴：Amplify Hosting（amplifyapp.com） vs S3＋Next.js（静的書き出し）比較

前提：どちらもフロントから GraphQL エンドポイント（例：AppSync）へ接続しますが、Amplify Hosting（*.amplifyapp.com） は SSR/Edge を使える一方、S3＋Next.js（静的書き出し） は完全クライアント実行です。この差が CORS・認証方式・秘密情報の扱い・WebSocket・パフォーマンスに直結します。

認証方式（JWT vs IAM/SigV4）の難易度
CORS/Preflight の壁
秘密情報（キー・内向きAPI）の扱い
Subscriptions（WebSocket）と企業ネットワーク
ネットワーク到達性（Private/VPC）
失敗しやすい具体例
パフォーマンスとキャッシュ
マルチ環境/プレビュー時の注意
どちらを選ぶ？判断基準
接続チェックリスト（まずここを通す）

1. 認証方式（JWT vs IAM/SigV4）の難易度

Amplify Hosting（SSR/Route Handlers 可）は、サーバ側でトークンの隠蔽や SigV4 署名を肩代わりでき、クライアントはシンプルな Cookie/ヘッダー操作で済みます。

S3＋Next.js（完全クライアント）は、Cognito User Pools（JWT）なら比較的簡単ですが、AWS_IAM 認証だとブラウザでの SigV4 署名が必要。Cognito Identity Pool 経由の一時クレデンシャル配布、clock skew、権限リーク等のリスクが増します。

推奨：S3 構成なら GraphQL の認証は User Pools（JWT）に寄せるのが現実的。

2. CORS/Preflight の壁

Amplify Hostingは SSR プロキシを挟めば同一オリジン化でき、CORS の影響を最小化できます。

S3 直叩きは GraphQL 側で下記を必ず許可：

Access-Control-Allow-Origin: https://あなたのドメイン
Access-Control-Allow-Methods: POST, OPTIONS
Access-Control-Allow-Headers: content-type, authorization

Preflight（OPTIONS）応答不備は最頻出の原因。まずはここを疑う。

3. 秘密情報（キー・内向きAPI）の扱い

Amplify Hostingではサーバ専用の環境変数で秘密を保持可能。

S3はすべてクライアント配布になるため NEXT_PUBLIC_* 以外は使えません。秘密は置けないと考えて設計しましょう。

4. Subscriptions（WebSocket）と企業ネットワーク

どちらでも利用可能ですが、S3 のクライアント直 wss は企業ネットワークでブロックされるケースがあります。代替の SSE/ポーリングは自前実装が必要。

5. ネットワーク到達性（Private/VPC）

S3 はブラウザからインターネット公開の GraphQL にしか到達できません。Private エンドポイント直結は不可です。Amplify（SSR）なら公開の中継を用意しやすい設計が可能。

6. 失敗しやすい具体例

S3 直叩き：CORS error（Preflight 応答欠落／Origin 不一致）、401/403（Authorization ヘッダー未設定・期限切れ）、SigV4 の時計ずれや権限漏れ。
Amplify Hosting：SSR 側の環境変数をクライアントで参照して undefined、ブランチ URL 追加時に Cognito Callback/CORS 登録漏れ。

7. パフォーマンスとキャッシュ

Amplify Hostingは SSR/ISR でサーバキャッシュや Edge キャッシュを活用可能。GraphQL コールをサーバで集約できます。

S3はクライアントから毎回 POSTになるため CDN キャッシュが効きづらい。SW/IndexedDB 等のクライアントキャッシュ戦略を検討。

8. マルチ環境/プレビュー時の注意

Amplify：ブランチ毎に *.amplifyapp.com が発行。各ブランチURLを Cognito と GraphQL 側の CORS/Callback に登録（漏れがち）。
S3：環境別にバケット/CloudFront を分け、Origin 許可も環境ごとに追加。

9. どちらを選ぶ？判断基準

S3＋Next.js（静的）で十分なケース：

認証をUser Pools（JWT）固定できる
GraphQL をインターネット公開＋適切な CORSで運用可能
WebSocket が利用環境で許容されている

Amplify Hosting を推奨するケース：

AWS_IAM 認証（SigV4）や秘密保護、SSR プロキシで CORS を吸収したい
企業ネットワーク対策、パフォーマンス最適化（SSR/ISR）を行いたい
プレビュー/ブランチ運用を多用する

10. 接続チェックリスト（まずここを通す）

認証方式：S3 なら User Pools（JWT）を選択
CORS：Origin／POST, OPTIONS／content-type, authorization 許可
HTTPS：必須（Mixed Content 回避）
トークン更新：期限切れ時の再ログイン or リフレッシュ導線
Subscriptions：wss 到達性の事前テスト
環境変数：クライアント参照は NEXT_PUBLIC_* のみ
公開性：Private エンドポイントは S3 単体不可 → SSR/プロキシを検討

まとめ：同じ「フロントから GraphQL を呼ぶ」でも、Amplify Hosting は SSR/Edge を活かして CORS・認証・秘密管理のハードルを下げられます。S3＋Next.js（静的）は最小コストで高速ですが、User Pools（JWT）× 公開GraphQL × 正しいCORSに設計を寄せるのが鍵。要件次第で最適解は変わるため、上のチェックリストで早期に詰まりどころを潰しましょう。