clerk-auth

Clerk 認証 - 破壊的変更とエラー防止ガイド

パッケージのバージョン: @clerk/[email protected]、@clerk/[email protected]、@clerk/[email protected]、@clerk/[email protected] 破壊的変更: 2025年11月 - API バージョン 2025-11-10、2024年10月 - Next.js v6 の非同期 auth() 最終更新日: 2026-01-09

---

新機能（2025年12月〜2026年1月）

1. API キーのベータ版（2025年12月11日）- 新機能 ✨

アプリケーション用のユーザースコープおよび組織スコープの API キーです。コード不要の UI コンポーネントを利用できます。

// 1. Add the component for self-service API key management
import { APIKeys } from '@clerk/nextjs'

export default function SettingsPage() {
  return (
    <div>
      <h2>API Keys</h2>
      <APIKeys />  {/* Full CRUD UI for user's API keys */}
    </div>
  )
}

バックエンドでの検証:

import { verifyToken } from '@clerk/backend'

// API keys are verified like session tokens
const { data, error } = await verifyToken(apiKey, {
  secretKey: process.env.CLERK_SECRET_KEY,
  authorizedParties: ['https://yourdomain.com'],
})

// Check token type
if (data?.tokenType === 'api_key') {
  // Handle API key auth
}

clerkMiddleware のトークンタイプ:

// v6.36.0+: Middleware can distinguish token types
clerkMiddleware((auth, req) => {
  const { userId, tokenType } = auth()

  if (tokenType === 'api_key') {
    // API key auth - programmatic access
  } else if (tokenType === 'session_token') {
    // Regular session - web UI access
  }
})

料金（ベータ版 = 無料）:

• 作成: $0.001/キー
• 検証: $0.0001/検証

2. Next.js 16: ミドルウェアのファイル名が proxy.ts に変更（2025年12月）

⚠️ 破壊的変更: Next.js 16 では、重大なセキュリティ脆弱性（2025年3月に公表）を受けて、ミドルウェアのファイル名が変更されました。

背景: 2025年3月の脆弱性（Next.js 11.1.4〜15.2.2 が対象）では、単一の HTTP ヘッダー x-middleware-subrequest: true を追加するだけで、ミドルウェアベースの認可を完全に回避できました。これはすべての認証ライブラリ（NextAuth、Clerk、カスタムソリューション）に影響しました。

名称変更の理由: middleware.ts → proxy.ts への変更は、単なる見た目上のものではありません。Next.js は、ミドルウェアを中心としたセキュリティパターンが危険であることを示しています。今後の認証実装では、認可をミドルウェアだけに依存させないでください。

Next.js 15 and earlier: middleware.ts
Next.js 16+:            proxy.ts

Next.js 16 の正しい設定:

// src/proxy.ts (NOT middleware.ts!)
import { clerkMiddleware } from '@clerk/nextjs/server'

export default clerkMiddleware()

export const config = {
  matcher: [
    '/((?!_next|[^?]*\\.(?:html?|css|js(?!on)|jpe?g|webp|png|gif|svg|ttf|woff2?|ico|csv|docx?|xlsx?|zip|webmanifest)).*)',
    '/(api|trpc)(.*)',
  ],
}

最低バージョン: Next.js 16 には @clerk/[email protected]+ が必要です（Turbopack のビルドエラーと、サインアウト時のキャッシュ無効化の問題を修正します）。

3. パスワードの強制リセット（2025年12月19日）

管理者はパスワードが侵害されたことを示し、リセットを強制できます。

import { clerkClient } from '@clerk/backend'

// Force password reset for a user
await clerkClient.users.updateUser(userId, {
  passwordDigest: 'compromised',  // Triggers reset on next sign-in
})

4. 組織レポートとフィルター（2025年12月15〜17日）

ダッシュボードに、組織の作成指標と、名前／スラッグ／日付による絞り込み機能が追加されました。

---

API バージョン 2025-11-10 の破壊的変更

1. API バージョン 2025-11-10（2025年11月10日）- 破壊的変更 ⚠️

対象: Clerk Billing／Commerce API を使用するアプリケーション

重大な変更:

• エンドポイント URL: /commerce/ → /billing/（30 以上のエンドポイント）

  GET /v1/commerce/plans → GET /v1/billing/plans
  GET /v1/commerce/statements → GET /v1/billing/statements
  POST /v1/me/commerce/checkouts → POST /v1/me/billing/checkouts
  

• フィールドの用語: payment_source → payment_method

  // OLD (deprecated)
  { payment_source_id: "...", payment_source: {...} }
  
  // NEW (required)
  { payment_method_id: "...", payment_method: {...} }
  

• 削除されたフィールド: Plans のレスポンスに以下のフィールドが含まれなくなりました:

  • amount、amount_formatted（代わりに fee.amount を使用）
  • currency、currency_symbol（fee オブジェクトを使用）
  • payer_type（代わりに for_payer_type を使用）
  • annual_monthly_amount、annual_amount

• 削除されたエンドポイント:

  • Invoices エンドポイント（statements を使用）
  • Products エンドポイント

• null の扱い: 明確なルールが導入されました。null は「存在しない」を意味し、省略は「存在するかどうかを表明していない」ことを意味します。

移行: API バージョン 2025-11-10 に対応する v6.35.0+ の SDK に更新してください。

公式ガイド: https://clerk.com/docs/guides/development/upgrading/upgrade-guides/2025-11-10

2. Next.js v6 の非同期 auth()（2024年10月）- 破壊的変更 ⚠️

対象: auth() を使用するすべての Next.js Server Components

// ❌ OLD (v5 - synchronous)
const { userId } = auth()

// ✅ NEW (v6 - asynchronous)
const { userId } = await auth()

こちらにも影響: ミドルウェア内の auth.protect() も非同期になりました

// ❌ OLD (v5)
auth.protect()

// ✅ NEW (v6)
await auth.protect()

互換性: Next.js 15、16 に対応しています。デフォルトでは静的レンダリングが使用されます。

3. カスタム OAuth の PKCE サポート（2025年11月12日）

カスタム OIDC プロバイダーとソーシャル接続が PKCE（Proof Key for Code Exchange）に対応し、クライアントシークレットを安全に保存できないネイティブ／モバイルアプリケーションのセキュリティが強化されました。

ユースケース: モバイルアプリ、ネイティブアプリ、シークレットを安全に保存できないパブリッククライアント。

4. クライアントの信頼性: クレデンシャルスタッフィング対策（2025年11月14日）

認識されていないデバイスからユーザーがサインインすると、自動的に追加認証が行われます。

• 有効なパスワードを持ち、2FA を設定していないユーザーに適用されます
• 設定は不要です
• すべての Clerk プランに含まれます

仕組み: 新しいデバイスからのサインインを検知すると、Clerk はメールコードやバックアップコードなどによる追加認証を自動的に求めます。

5. Next.js 16 のサポート（2025年11月）

@clerk/nextjs v6.35.2+ では、Next.js 16 のサインアウト時のキャッシュ無効化が改善されています。

---

重要なパターンとエラー防止

Next.js v6：Async auth() ヘルパー

パターン：

import { auth } from '@clerk/nextjs/server'

export default async function Page() {
  const { userId } = await auth()  // ← Must await

  if (!userId) {
    return <div>Unauthorized</div>
  }

  return <div>User ID: {userId}</div>
}

Cloudflare Workers：authorizedParties（CSRF 防止）

重要： CSRF 攻撃を防ぐため、必ず authorizedParties を設定してください。

import { verifyToken } from '@clerk/backend'

const { data, error } = await verifyToken(token, {
  secretKey: c.env.CLERK_SECRET_KEY,
  // REQUIRED: Prevent CSRF attacks
  authorizedParties: ['https://yourdomain.com'],
})

理由： authorizedParties がないと、攻撃者が他のドメインの有効なトークンを使用できてしまいます。

出典： https://clerk.com/docs/reference/backend/verify-token

---

clerkMiddleware() の設定

ルート保護のパターン

import { clerkMiddleware, createRouteMatcher } from '@clerk/nextjs/server'

// Define protected routes
const isProtectedRoute = createRouteMatcher([
  '/dashboard(.*)',
  '/api/private(.*)',
])

const isAdminRoute = createRouteMatcher(['/admin(.*)'])

export default clerkMiddleware(async (auth, req) => {
  // Protect routes
  if (isProtectedRoute(req)) {
    await auth.protect()  // Redirects unauthenticated users
  }

  // Require specific permissions
  if (isAdminRoute(req)) {
    await auth.protect({
      role: 'org:admin',  // Requires organization admin role
    })
  }
})

すべてのミドルウェアオプション

オプション	型	説明
debug	boolean	デバッグログを有効にします
jwtKey	string	ネットワークなしでの検証に使用する JWKS 公開鍵
clockSkewInMs	number	トークンの時刻の許容差（デフォルト：5000ms）
organizationSyncOptions	object	URL ベースの組織の有効化
signInUrl	string	カスタムサインイン URL
signUpUrl	string	カスタムサインアップ URL

組織の同期（URL ベースの組織の有効化）

⚠️ Next.js のみ： この機能は現在、Next.js の clerkMiddleware() でのみ動作します。Sec-Fetch-Dest ヘッダーチェックのため、他のランタイム（Cloudflare Workers、Express など）の authenticateRequest() では動作しません。

出典： GitHub Issue #7178

clerkMiddleware({
  organizationSyncOptions: {
    organizationPatterns: ['/orgs/:slug', '/orgs/:slug/(.*)'],
    personalAccountPatterns: ['/personal', '/personal/(.*)'],
  },
})

---

Webhook

Webhook の検証

import { Webhook } from 'svix'

export async function POST(req: Request) {
  const payload = await req.text()
  const headers = {
    'svix-id': req.headers.get('svix-id')!,
    'svix-timestamp': req.headers.get('svix-timestamp')!,
    'svix-signature': req.headers.get('svix-signature')!,
  }

  const wh = new Webhook(process.env.CLERK_WEBHOOK_SIGNING_SECRET!)

  try {
    const event = wh.verify(payload, headers)
    // Process event
    return Response.json({ success: true })
  } catch (err) {
    return Response.json({ error: 'Invalid signature' }, { status: 400 })
  }
}

一般的なイベントタイプ

イベント	トリガー
user.created	新しいユーザーがサインアップ
user.updated	ユーザープロフィールの変更
user.deleted	ユーザーアカウントの削除
session.created	新しいサインイン
session.ended	サインアウト
organization.created	新しい組織の作成
organization.membership.created	ユーザーが組織に参加

⚠️ 重要： Webhook のルートはパブリック（認証なし）にする必要があります。ミドルウェアの除外リストに追加してください：

const isPublicRoute = createRouteMatcher([
  '/api/webhooks/clerk(.*)',  // Clerk webhooks are public
])

clerkMiddleware((auth, req) => {
  if (!isPublicRoute(req)) {
    auth.protect()
  }
})

---

UI コンポーネント早見表

コンポーネント	用途
<SignIn />	サインインフロー全体
<SignUp />	サインアップフロー全体
<SignInButton />	サインインモーダルを開く
<SignUpButton />	サインアップモーダルを開く
<SignedIn>	認証済みの場合のみレンダリング
<SignedOut>	未認証の場合のみレンダリング
<UserButton />	サインアウト機能付きユーザーメニュー
<UserProfile />	プロフィール管理全体
<OrganizationSwitcher />	組織を切り替え
<OrganizationProfile />	組織の設定
<CreateOrganization />	新しい組織を作成
<APIKeys />	API キーの管理（新機能）

React フック

フック	戻り値
useAuth()	{ userId, sessionId, isLoaded, isSignedIn, getToken }
useUser()	{ user, isLoaded, isSignedIn }
useClerk()	メソッドを備えた Clerk インスタンス
useSession()	現在のセッションオブジェクト
useOrganization()	現在の組織コンテキスト
useOrganizationList()	ユーザーのすべての組織

---

JWT テンプレート - サイズ制限とショートコード

JWT のサイズ制限：カスタムクレームは 1.2KB ⚠️

問題： ブラウザーの Cookie は 4KB に制限されています。Clerk のデフォルトクレームが約 2.8KB を使用するため、カスタムクレームに使えるのは 1.2KB です。

⚠️ 開発時の注意： Vite の開発モードでカスタム JWT クレームをテストすると、「431 Request Header Fields Too Large」 エラーが発生することがあります。これは、Clerk のハンドシェイクトークンが URL 内で Vite の 8KB 制限を超えるためです。解決方法については、Issue #11 を参照してください。

解決策：

// ✅ GOOD: Minimal claims
{
  "user_id": "{{user.id}}",
  "email": "{{user.primary_email_address}}",
  "role": "{{user.public_metadata.role}}"
}

// ❌ BAD: Exceeds limit
{
  "bio": "{{user.public_metadata.bio}}",  // 6KB field
  "all_metadata": "{{user.public_metadata}}"  // Entire object
}

ベストプラクティス： 大きなデータはデータベースに保存し、JWT には識別子やロールのみを含めてください。

利用可能なショートコードのリファレンス

カテゴリ	ショートコード	例
ユーザー ID と名前	{{user.id}}、{{user.first_name}}、{{user.last_name}}、{{user.full_name}}	"John Doe"
連絡先	{{user.primary_email_address}}、{{user.primary_phone_address}}	"[email protected]"
プロフィール	{{user.image_url}}、{{user.username}}、{{user.created_at}}	"https://..."
確認	{{user.email_verified}}、{{user.phone_number_verified}}	true
メタデータ	{{user.public_metadata}}、{{user.public_metadata.FIELD}}	{"role": "admin"}
組織	org_id、org_slug、org_role（sessionClaims 内）	"org:admin"

高度な機能：

• 文字列の補間：「"{{user.last_name}} {{user.first_name}}"」
• 条件付きフォールバック：「"{{user.public_metadata.role || 'user'}}"」
• ネストされたメタデータ：「"{{user.public_metadata.profile.interests}}"」

公式ドキュメント：https://clerk.com/docs/guides/sessions/jwt-templates

---

Clerk を使ったテスト

テスト用認証情報（固定 OTP：424242）

テスト用メールアドレス（メールは送信されず、固定 OTP を使用）：

[email protected]
[email protected]

テスト用電話番号（SMS は送信されず、固定 OTP を使用）：

+12015550100
+19735550133

固定 OTP コード：424242（すべてのテスト用認証情報で使用できます）

セッショントークンの生成（有効期間 60 秒）

スクリプト（scripts/generate-session-token.js）：

# Generate token
CLERK_SECRET_KEY=sk_test_... node scripts/generate-session-token.js

# Create new test user
CLERK_SECRET_KEY=sk_test_... node scripts/generate-session-token.js --create-user

# Auto-refresh token every 50 seconds
CLERK_SECRET_KEY=sk_test_... node scripts/generate-session-token.js --refresh

手動フロー：

1. ユーザーを作成します：POST /v1/users
2. セッションを作成します：POST /v1/sessions
3. トークンを生成します：POST /v1/sessions/{session_id}/tokens
4. ヘッダーで使用します：Authorization: Bearer <token>

Playwright による E2E テスト

テストトークンを自動管理するため、@clerk/testing をインストールします：

npm install -D @clerk/testing

グローバルセットアップ（global.setup.ts）：

import { clerkSetup } from '@clerk/testing/playwright'
import { test as setup } from '@playwright/test'

setup('global setup', async ({}) => {
  await clerkSetup()
})

テストファイル（auth.spec.ts）：

import { setupClerkTestingToken } from '@clerk/testing/playwright'
import { test } from '@playwright/test'

test('sign up', async ({ page }) => {
  await setupClerkTestingToken({ page })

  await page.goto('/sign-up')
  await page.fill('input[name="emailAddress"]', '[email protected]')
  await page.fill('input[name="password"]', 'TestPassword123!')
  await page.click('button[type="submit"]')

  // Verify with fixed OTP
  await page.fill('input[name="code"]', '424242')
  await page.click('button[type="submit"]')

  await expect(page).toHaveURL('/dashboard')
})

公式ドキュメント：https://clerk.com/docs/guides/development/testing/overview

---

既知の問題の予防

このスキルでは、記録されている 15 件の問題を予防できます：

問題 #1：Clerk シークレットキーがない

エラー：「Clerk Secret Key または API Key がありません」 出典：https://stackoverflow.com/questions/77620604 予防策：.env.local または wrangler secret put を使用して、必ず設定してください

問題 #2：API キーからシークレットキーへの移行

エラー：「apiKey は非推奨です。secretKey を使用してください」 出典：https://clerk.com/docs/upgrade-guides/core-2/backend 予防策：すべての呼び出しで apiKey を secretKey に置き換えてください

問題 #3：JWKS キャッシュの競合状態

エラー：「利用可能な JWK がありません」 出典：https://github.com/clerk/javascript/blob/main/packages/backend/CHANGELOG.md 予防策：@clerk/[email protected] 以降を使用してください（修正済み）

問題 #4：authorizedParties がない（CSRF）

エラー：エラーは発生しませんが、CSRF の脆弱性があります 出典：https://clerk.com/docs/reference/backend/verify-token 予防策：必ず authorizedParties: ['https://yourdomain.com'] を設定してください

問題 #5：インポートパスの変更（Core 2）

エラー：「モジュールが見つかりません」 出典：https://clerk.com/docs/upgrade-guides/core-2/backend 予防策：Core 2 用にインポートパスを更新してください

問題 #6：JWT のサイズ制限超過

エラー：トークンがサイズ制限を超えています 出典：https://clerk.com/docs/backend-requests/making/custom-session-token 予防策：カスタムクレームを 1.2KB 未満にしてください

問題 #7：非推奨の API バージョン v1

エラー：「API バージョン v1 は非推奨です」 出典：https://clerk.com/docs/upgrade-guides/core-2/backend 予防策：最新の SDK バージョン（API v2025-11-10）を使用してください

問題 #8：ClerkProvider JSX コンポーネントのエラー

エラー：「JSX コンポーネントとして使用できません」 出典：https://stackoverflow.com/questions/79265537 予防策：@clerk/[email protected] 以降で React 19 との互換性を確保してください

問題 #9：非同期 auth() ヘルパーの混乱

エラー：「auth() は関数ではありません」 出典：https://clerk.com/changelog/2024-10-22-clerk-nextjs-v6 予防策：必ず await を使用してください：const { userId } = await auth()

Issue #10: 環境変数の設定ミス

エラー: 「Publishable Key がありません」またはシークレットの漏えい 予防策: 正しいプレフィックス（NEXT_PUBLIC_、VITE_）を使用し、シークレットを決してコミットしないでください

Issue #11: 431 Request Header Fields Too Large（Vite 開発モード）

エラー: サインイン時に「431 Request Header Fields Too Large」 発生源: カスタム JWT クレームのテスト時に、Vite 開発モードでよく発生します 原因: URL 内の Clerk の __clerk_handshake トークンが、Vite の 8KB ヘッダー制限を超えています 予防策:

package.json に追加します：

{
  "scripts": {
    "dev": "NODE_OPTIONS='--max-http-header-size=32768' vite"
  }
}

一時的な回避策: ブラウザーのキャッシュを消去し、サインアウトしてから再度サインインします

理由: Clerk の開発用トークンは本番環境より大きく、カスタム JWT クレームによってハンドシェイクトークンのサイズが増加します

注: これは Issue #6（セッショントークンのサイズ）とは異なります。Issue #6 は Cookie（1.2KB）に関するものですが、こちらは開発モードの URL パラメーター（8KB → 32KB）に関するものです。

Issue #12: ユーザー型の不一致（useUser と currentUser）

エラー: クライアントとサーバーでユーザーユーティリティを共有すると、TypeScript エラーが発生します 発生源: GitHub Issue #2176 発生する理由: useUser() はクライアント側の UserResource を返し、サーバー側の currentUser() が返す User とはプロパティが異なります。クライアントには fullName と primaryEmailAddress オブジェクトがありますが、サーバーには代わりに primaryEmailAddressId と privateMetadata があります。 予防策: 共通のプロパティのみを使用するか、クライアントとサーバーのコンテキストごとに別々のユーティリティ関数を作成してください。

// ✅ CORRECT: Use properties that exist in both
const primaryEmailAddress = user.emailAddresses.find(
  ({ id }) => id === user.primaryEmailAddressId
)

// ✅ CORRECT: Separate types
type ClientUser = ReturnType<typeof useUser>['user']
type ServerUser = Awaited<ReturnType<typeof currentUser>>

Issue #13: 複数の acceptsToken 型による token-type-mismatch

エラー: 複数のトークン型で authenticateRequest() を使用すると、「token-type-mismatch」が発生します 発生源: GitHub Issue #7520 発生する理由: 複数の acceptsToken 値（例：['session_token', 'api_key']）を指定して authenticateRequest() を使用すると、Clerk が誤って token-type-mismatch エラーをスローします。 予防策: @clerk/[email protected]+ にアップグレードしてください（修正はスナップショットで利用可能で、まもなくリリース予定です）。

// This now works in @clerk/[email protected]+
const result = await authenticateRequest(request, {
  acceptsToken: ['session_token', 'api_key'],  // Fixed!
})

Issue #14: 不正な URL による deriveUrlFromHeaders のサーバークラッシュ

エラー: URL 解析エラーでサーバーがクラッシュします 発生源: GitHub Issue #7275 発生する理由: 内部関数 deriveUrlFromHeaders() が安全でない URL 解析を行うため、ヘッダー内の不正な URL（例：x-forwarded-host: 'example.com[invalid]'）を受信すると、サーバー全体がクラッシュします。これはサービス拒否の脆弱性です。 予防策: @clerk/[email protected]+ にアップグレードしてください（修正済み）。

Issue #15: 保留中のセッションに対する treatPendingAsSignedOut オプション

エラー: なし。エッジケースへの対応に使う任意のパラメーターです 発生源: Changelog @clerk/[email protected] 存在する理由: 特定のフロー（例：クレデンシャルスタッフィング対策の二次認証）では、セッションのステータスが pending になることがあります。デフォルトでは、保留中のセッションはサインアウト状態（ユーザーは null）として扱われます。 使用方法: treatPendingAsSignedOut: false を設定すると、保留中の状態をサインイン済みとして扱います（@clerk/[email protected]+ で利用可能）。

// Default: pending = signed out
const user = await currentUser()  // null if status is 'pending'

// Treat pending as signed in
const user = await currentUser({ treatPendingAsSignedOut: false })  // defined if pending

---

本番環境での考慮事項

サービスの可用性と信頼性

背景: Clerk は 2025 年 5 月から 6 月にかけて、Google Cloud Platform (GCP) の障害に起因する 3 件の大規模なサービス停止を経験しました。2025 年 6 月 26 日の障害は 45 分間（UTC 6:16～7:01）にわたり、すべての Clerk 顧客に影響を与えました。

出典: Clerk ポストモーテム: 2025 年 6 月 26 日

緩和策:

• リアルタイムの更新情報を得るために Clerk Status を監視する
• Clerk API が利用できない場合に備えて、グレースフルデグラデーションを実装する
• 可能な限り認証トークンをローカルにキャッシュする
• 既存のセッションについては、ネットワークを必要としない検証のために jwtKey オプションを使用する:

clerkMiddleware({
  jwtKey: process.env.CLERK_JWT_KEY,  // Allows offline token verification
})

注記: 完全な障害の間は、新しいセッションを作成できません（認証には Clerk API が必要です）。ただし、jwtKey を使用して JWT をローカルで検証すれば、既存のセッションは引き続き動作します。Clerk は、単一ベンダーへの依存リスクを軽減するために、マルチクラウドの冗長性の検討を約束しました。

---

公式ドキュメント

• Clerk ドキュメント: https://clerk.com/docs
• Next.js ガイド: https://clerk.com/docs/references/nextjs/overview
• React ガイド: https://clerk.com/docs/references/react/overview
• バックエンド SDK: https://clerk.com/docs/reference/backend/overview
• JWT テンプレート: https://clerk.com/docs/guides/sessions/jwt-templates
• API バージョン 2025-11-10 へのアップグレード: https://clerk.com/docs/guides/development/upgrading/upgrade-guides/2025-11-10
• テストガイド: https://clerk.com/docs/guides/development/testing/overview
• Context7 ライブラリ ID: /clerk/clerk-docs

---

パッケージバージョン

最新（2025 年 11 月 22 日）:

{
  "dependencies": {
    "@clerk/nextjs": "^6.36.7",
    "@clerk/clerk-react": "^5.59.2",
    "@clerk/backend": "^2.29.2",
    "@clerk/testing": "^1.13.26"
  }
}

---

トークン効率:

• スキルなし: 約 6,500 トークン（セットアップチュートリアル、JWT テンプレート、テストセットアップ、Webhook、本番環境の考慮事項）
• スキルあり: 約 3,200 トークン（破壊的変更 + 重要なパターン + エラー防止 + 本番環境のガイダンス）
• 削減量: 約 51%（約 3,300 トークン）

防止されるエラー: 正確な解決策とともに文書化された 15 件の問題 主な価値: API Keys ベータ、Next.js 16 proxy.ts（2025 年 3 月の CVE の経緯を含む）、clerkMiddleware() のオプション、Webhook、コンポーネントリファレンス、API 2025-11-10 の破壊的変更、JWT サイズ制限、ユーザー型の不一致、本番環境の考慮事項（GCP 障害、jwtKey によるオフライン検証）

---

最終検証日: 2026-01-20 | スキルバージョン: 3.1.0 | 変更点: 4 件の新しい既知の問題（#12～15: ユーザー型の不一致、acceptsToken 型の不一致、deriveUrlFromHeaders のクラッシュ、treatPendingAsSignedOut オプション）を追加、proxy.ts セクションを 2025 年 3 月の CVE セキュリティ経緯とともに拡充、本番環境の考慮事項セクション（GCP 障害 + 緩和策）を追加、organizationSyncOptions の Next.js 限定の制限事項に関する注記を追加、Next.js 16 の最小バージョン要件（6.35.0 以上）を更新。