Blog

GraphQLの強み（現場で効くところ）

• 欲しいデータだけ取得できる（過不足を減らす）
• スキーマが型として残る（破壊的変更を減らす）
• 複数バックエンドの統合がしやすい（BFF/集約）

GraphQLの落とし穴（対策前提）

• 重いクエリでサーバーが死ぬ（深さ/複雑度制限が必要）
• N+1問題が起きやすい（DataLoader等の対策）
• 権限が甘いと“全部見える”が起きる（フィールド単位の認可）

認証基盤（OAuth/OIDCなど）の役割

• 認証（Authentication）：誰かを確認する
• 認可（Authorization）：何をしていいか決める
• トークン管理：期限・更新・失効・スコープ

「ログインできる」より重要なのは、“見せてはいけないデータを絶対に見せない”ことです。

よくある誤解（事故の原因）

• 「GraphQLなら何でも速い」→ ❌（クエリが重ければ即死）
• 「JWTなら安全」→ ❌（失効・漏洩・スコープ設計が本体）
• 「認証＝ログイン画面」→ ❌（本質は認可と監査）
• 「APIは作って終わり」→ ❌（運用・互換性・廃止が本番）

APIは“便利さ”の顔をして、裏側は“セキュリティと運用の塊”です。

① API設計（契約を作る）

• GraphQLスキーマ設計（型/クエリ/ミューテーション）
• エラー設計（クライアントが復旧できる形）
• 互換性（破壊的変更を避ける）と廃止ポリシー

② 認証・認可（境界線を作る）

• OAuth/OIDC設計（クライアント種別・スコープ）
• RBAC/ABAC（ロール・属性）設計
• トークン管理（期限・更新・失効・漏洩時対応）

③ 実装・性能（落ちない仕組みにする）

• Resolver実装、N+1対策、キャッシュ
• クエリ深さ/複雑度制限、レート制限
• 監視（メトリクス/ログ/トレース）

④ 運用・統制（増えても破綻しない）

• APIキー/クライアント管理、発行・停止フロー
• 監査ログ・アラート・インシデント対応
• ドキュメント・SDK・サンプル整備（開発者体験）

例：GraphQL APIの拡張＋認証基盤の整備

• 9:30：監視チェック（レート制限/エラー率/遅延）
• 11:00：スキーマ設計（互換性を崩さず追加）
• 13:30：認可の見直し（フィールド/スコープ）
• 16:00：深さ制限・N+1対策・キャッシュ調整
• 18:00：廃止予定APIの通知・移行ガイド更新

特徴：実装よりも“壊れないための調整”が多い職種です。

• スキーマ/仕様が「契約」として管理されている
• 認可（スコープ/ロール）が明文化されている
• レート制限・深さ制限・監査ログがある
• 監視（遅延/エラー率）とアラートがある
• 廃止/変更の手順（通知・移行）がある

2つ以下なら、まず認可＋監視＋変更管理の整備から始めるのが安全です。

必須になりやすい領域

• API設計（GraphQLスキーマ、エラー設計、互換性）
• 認証/認可（OAuth/OIDC、JWT、スコープ、RBAC/ABAC）
• セキュリティ基礎（最小権限、鍵管理、監査、脅威モデル）
• 性能/信頼性（レート制限、キャッシュ、N+1対策）
• 観測（ログ/メトリクス/トレース）
• 運用（変更管理、廃止、開発者向けドキュメント）

評価されやすいカテゴリ

• クラウド基礎（IAM/ネットワーク/監視）
• セキュリティ基礎（認証・暗号・監査）
• API/設計思想（ドキュメントと運用）

資格より強いのは、「安全に運用されているAPIの実績」です。

おすすめの順番（現実的ルート）

• 「便利さ」と「安全性」の両方を考えられる
• 仕様や契約をきっちり守るのが好き
• 失敗パターン（攻撃/バグ）を潰すのが得意
• 運用・監視・廃止まで含めて設計できる

• APIエンジニア → プラットフォームエンジニア（基盤）
• APIエンジニア → IAM/認証アーキテクト
• APIエンジニア → セキュリティエンジニア（アプリケーション）
• APIエンジニア → テックリード/アーキテクト