Clerk Authは、Clerkを基盤とした専用認証システムをアプリに提供します。Replitのログインシステムを使用してReplitアカウントを作成するReplit Authとは異なり、Clerk Authはアプリ専用の別のClerkテナントをプロビジョニングします。アプリのユーザーはReplitアカウントではなく、アプリ内で直接アカウントを作成します。ブランディング、ログイン方法、サインイン体験を完全にコントロールできます。Documentation Index
Fetch the complete documentation index at: https://docs.replit.com/llms.txt
Use this file to discover all available pages before exploring further.
Clerk Auth vs. Replit Auth — Clerk Auth（このページ）では、アプリが完全にカスタマイズ可能なブランディングとReplitから独立したユーザーアカウントを持つ独自の認証テナントを取得します。**Replit Auth**では、ユーザーはReplitアカウントでサインインし、Replitブランドのログインページが表示されます。ログイン体験に独自のブランドを使いたい場合や、Replitから独立したユーザーアカウントが必要な場合はClerk Authを選択してください。
Clerk Auth vs. Replit Auth 比較
| Clerk Auth | Replit Auth | |
|---|---|---|
| ユーザーアカウント | ユーザーはアプリ内でアカウントを作成（Replitアカウント不要） | ユーザーはReplitアカウントでサインイン |
| ブランディング | 完全カスタマイズ可能 — アプリ名、アイコン、カラー | Replitブランドのログインページ |
| SSO認証情報 | プロバイダーごとに独自のOAuth認証情報を使用 | ReplitのShared OAuthアプリを使用 |
| 環境 | 開発環境と本番環境が分離 | シングル環境 |
| 紹介プログラム | Replit紹介との統合なし | サインアップがReplit Referralsにカウント |
| 最適な用途 | カスタムブランドアプリ、プロフェッショナル/商業製品 | クイックセットアップ、Replitブランディングが許容できるアプリ |
はじめに
Clerk AuthをアプリにAgentプロンプトに含めて追加します：Clerk AuthがReplitで動作する仕組み
AgentがアプリにClerk Authをセットアップすると、以下が行われます：- 専用のClerkテナントを作成 — アプリは開発環境と本番環境が分離された独自のClerkアプリケーションを取得します
- 認証情報のプロビジョニング — APIキーとシークレットが環境変数として保存されます
- プロキシの設定 — 認証が発行済みドメインでシームレスに動作します
- サインインとサインアップルートのセットアップ — 事前構築済みのClerk Reactコンポーネントがアプリに追加されます
- サーバーサイドミドルウェアの追加 — APIルートがClerkのExpressミドルウェアで保護されます
Clerkアカウントを作成したりインフラを管理したりする必要はありません。すべてがReplitによって自動的に管理されます。
機能
サポートされている機能
Clerk Authはアプリに以下を提供します：- 独立したユーザーアカウント — アプリのユーザーはReplitユーザーではなく、アプリのClerkテナント内にのみ存在します
- 完全ブランドのサインインページ — アプリ名、ロゴ、カラー、フォント、コピーをアプリのコードで設定します
- カスタムブランドSSO — プロバイダーごとに独自のOAuthクライアントを提供することで、プロバイダーのOAuth同意画面にデフォルトではなくアプリの名前とブランディングが表示されます
- メールとパスワード認証 — メール認証を含む組み込みのサインアップとサインイン
- ソーシャルサインイン（SSO） — Google、GitHub、Apple、X（Twitter）でのサインインを許可
- ユーザー管理 — Authペインからユーザーの表示、検索、モデレート
- セッション管理 — 自動管理される安全なセッショントークン
- 開発環境と本番環境 — 公開前に開発で認証をテスト
Clerk Authの設定のほとんどは、Project EditorのAuthツールから管理できます。Clerkアカウントは不要で、Clerkダッシュボードに触れる必要もありません。
サポートされていない機能
今日のClerk Authでは、以下の機能は利用できません（自分でセットアップする外部Clerkアプリと比較して）。詳細な内訳についてはこのFAQを参照してください。- 電話番号でのサインイン — SMSベースのサインインと認証
- MFAサポート — エンドユーザー向けの多要素認証
- SSOプロバイダーの完全対応 — 現在はGoogle、GitHub、Apple、Xのみサポート
- 組織テナント — Clerkの組織とチームメンバーシップ機能
開発環境と本番環境
Clerk Authを使用するすべてのアプリは、2つの完全に分離されたClerk環境を取得します。ビルド中の開発/プレビューアプリを動作させる開発環境と、発行済みアプリを動作させる本番環境です。これらの環境は設計上分離されており、APIキーとユーザーストアが別々になっています。別々のAPIキー
各環境にはそれぞれの公開可能キーとシークレットAPIキーがあります。アプリに公開されるキーは、アプリが開発中か本番中かに応じて自動的に切り替わります：- ワークスペースでは、
CLERK_PUBLISHABLE_KEYとCLERK_SECRET_KEYのSecretsには、開発環境を指すテストキー（pk_test...とsk_test...）が含まれています。
- アプリを発行すると、発行済みデプロイメントは本番環境を指すライブキー（
pk_live...とsk_live...）で動作します。プレフィックスを確認するには、Publishing → Overview → Adjust settingsを開いてCLERK_PUBLISHABLE_KEYとCLERK_SECRET_KEYを確認します。
環境を切り替えるために何かする必要はありません。Replitが開発と本番の両方のキーを自動的に管理します。開発、テスト、発行するだけです。
別々のユーザーストア
各環境にはそれぞれのユーザーストアがあります。開発環境でサインアップしたアカウントは本番環境には存在せず、その逆も同様です：- 開発/プレビューアプリでテスト中にサインアップしたユーザーは、開発ストアのみに作成されます。
- 発行済みアプリでサインアップしたユーザーは、本番ストアのみに作成されます。
- セッション、ユーザーメタデータ、Clerkの
userIdに関連付けたデータは同様に、アカウントが作成された環境にスコープされます。
開発は実験とビルドの場所です。本番はライブアプリの実際のユーザーを提供します。この2つは意図的に分離されており、開発で作成されたアカウントとデータは本番には表示されません。
ユーザーの管理
Project EditorのAuthペインは、認証済みユーザーの完全なビューを提供します。Clerk Authはアプリ専用のユーザーストアを作成するため、ここにリストされているユーザーはアプリのアカウントであり、Replitアカウントではありません。
- メール、名前、最終ログイン、アカウント作成日などの詳細ですべてのユーザーを表示
- 特定のユーザーを見つけるための検索とフィルタリング
- アプリへのアクセスを制御するためのユーザーのBanとUnBan
- 異なる基準によるユーザーの並べ替え
- 環境の切り替え — 開発と本番を切り替えて各環境のユーザーを管理
サインインページのカスタマイズ
サインインとサインアップページのビジュアルブランディング（アプリ名、ロゴ、カラー、フォント、コピー）はAuthペインではなく、アプリのコードで設定されます。変更するにはAgentに依頼してください：<ClerkProvider>に渡されるappearanceとlocalizationプロパティ、およびアプリのpublic/ディレクトリのロゴファイルによって管理されています。Agentはこれらをアプリのテーマと同期させます。
GoogleのOAuth同意画面、AppleのOAuth同意画面、GitHub、XのOAuth同意画面（ユーザーが「Googleでサインイン」などをクリックした後に表示される画面）に表示されるアプリ名は別のものです。これはプロバイダーに登録されたOAuthアプリから来ており、サインインページのコードを編集しても変更されません。変更するには、そのプロバイダーのカスタムOAuth認証情報の設定が必要です。
ログインプロバイダーの設定
Clerk AuthはGoogle、GitHub、Apple、XをSSOプロバイダーとしてサポートしています。AuthペインのConfigureタブから、サインインページに表示するプロバイダーを制御できます。また本番環境では、各プロバイダーがReplit管理のOAuth認証情報を使用するか、ブランドサインイン用の独自の認証情報を使用するかを設定できます。
- プロバイダーの有効化/無効化 — トグルを使用してサインインページにプロバイダーが表示されるかどうかを制御します。無効なプロバイダーはユーザーから非表示になります。
- カスタムOAuth認証情報の設定（本番のみ） — 下記のSSOプロバイダーのOAuth認証情報の設定を参照してください。
SSOプロバイダーのOAuth認証情報の設定
デフォルトでは、プロバイダーはReplit管理の認証情報を使用します。サインインはすぐに機能しますが、OAuthの同意画面にはReplitのブランディングが表示されます。Custom credentialsに切り替えると、プロバイダーのデベロッパーコンソールから独自のOAuthクライアントを使用でき、同意画面にデフォルトではなくアプリの名前とブランディングが表示されます。- Project EditorでAuthペインを開きます。Configureタブに移動し、サイドバーのSSO providersでProductionを選択します。
- 設定するプロバイダーの横にあるEditアイコンを選択します。デフォルトではReplit-managed credentialsが選択されています。
- Custom credentialsを選択します。パネルが展開され、認証情報フィールドと、プロバイダー側で登録する必要がある値を含むProvider setupチェックリストが表示されます。
- 設定を完了するための手順に従います。手順にはコンソールへの直接リンクと関連するヘルパードキュメントが含まれています。また、Additional resourcesでプロバイダー向けのヘルパードキュメントも確認できます。
- 必要な認証情報の値をすべて入力します。
- プロバイダーのデベロッパーコンソールで、Provider setupチェックリストに記載されているすべてのエントリをプロバイダーのデベロッパーポータルに登録します。コピーアイコンを使用して各値を正確にコピーし、完了したらアイテムにチェックを入れるか、すべて完了したらMark all as doneを選択します。
- Save changesを選択します。
ドメイン変更後のセットアップの再確認
新しい外部ドメインのリンクやReplitを通じたドメイン購入などのドメイン関連の操作により、アプリのリダイレクトコールバックURLとJavaScriptオリジンが変更される場合があります。その場合、カスタム認証情報で設定されたプロバイダーは、デベロッパーコンソールで新しい値を登録する必要があります。 ドメイン変更後、Configureタブに戻ります。セットアップのリマインダーがタブ、サイドバー、SSO providersリストのプロバイダーの横に警告アイコンとして表示されます。プロバイダーの横に警告アイコンとsetup steps remainingが表示されている場合、そのProvider setupチェックリストに完了すべき新しい項目があることを意味します。
メール認証のドメインセットアップ
アプリがメールとパスワードによるサインアップを提供している場合、Clerkは各新規ユーザーの受信箱に認証コードを送信します。メール配信のためにドメインを設定することで、コードがスパムフィルターによって遅延またはブロックされることなく、アプリのURLから届くようになります。このセットアップが必要な場合
このDNSレコードの設定が必要なのは、アプリが別のプロバイダーで管理されている外部ドメインをリンクしている場合のみです（例：Cloudflare、GoDaddy、Namecheap、または類似サービスで登録したドメイン）。 以下の場合はセットアップ不要です：.replit.appサブドメインから提供される場合- Replitを通じて購入したドメインの場合
メール送信のためのDNSレコードの追加
外部ドメインからのメール認証の送信をアプリに許可するには、ドメインプロバイダーにDNSレコードのセットを追加します。- Project EditorでPublishingを開きます。
- Domainsを選択します。
- リンクされた外部ドメインを見つけてManageを選択します。
- Authentication DNS setup requiredの下で、Replitが表示するCNAMEレコードをコピーします。これらはClerkがドメインからの認証メールを送信するために必要なレコードです。
- DNSプロバイダー（Cloudflare、GoDaddy、Namecheapなど）にサインインし、表示されたとおりに各レコードを追加します。
トラブルシューティング
- 認証メールが届かない — Manageパネルに表示されたとおりに各レコードが追加されていることを確認してください。DNSプロバイダーが要求する末尾のドットを含むようにしてください。受信者のスパムフォルダを確認してください。
- レコードがまだ検出されない — DNS反映の時間を待ち（最大48時間）、Manageパネルで欠落しているとフラグが立てられているレコードを再確認してください。
セキュリティベストプラクティス
- 常にサーバーサイドで検証する — UIだけでなく、APIルートで認証を確認してください
- 環境変数を使用する — コードにキーやシークレットをハードコードしないでください
- プロキシミドルウェアを最初に置く — ExpressアプリでClerkプロキシはボディパーサーの前にマウントする必要があります
- ホームページをサインインにリダイレクトしない — 未認証の訪問者がランディングページにアクセスできるようにしてください
FAQ
Clerk Authを使用するためにClerkアカウントが必要ですか？
不要です。Clerk Authの背後にあるClerkテナントは、AgentがアプリをセットアップするときにReplitによって自動的に作成・管理されます。Clerkにサインアップしたり、Clerkインフラを自分で管理したりする必要はありません。Replit管理のClerkインスタンスのClerkダッシュボードにアクセスできますか？
できません。Replit管理のClerkインスタンスはClerkダッシュボードを通じて公開されていません。代わりにProject EditorのAuthツールから管理してください。プロバイダーの設定、ユーザーの表示、開発環境と本番環境の切り替えはそこで行います。Clerkの公開可能キーがpk_testで始まっています。ライブキーに切り替えるにはどうすればよいですか？
切り替える必要はありません。ワークスペースのSecretsペインに表示されるpk_test...とsk_test...キーは、ビルド中に使用するアプリの開発Clerk環境に属しています。アプリを発行すると、デプロイメントは本番環境のためにpk_live...とsk_live...キーで自動的に動作します。確認するには、ワークスペースでPublishing → Overview → Adjust settingsを開き、発行済みアプリのCLERK_PUBLISHABLE_KEYの値を確認してください。pk_liveで始まっているはずです。これらのキーを手動で編集しないでください。詳細は開発環境と本番環境を参照してください。
開発中に作成したアカウントで発行済みアプリにサインインできないのはなぜですか？
Clerk Authの開発と本番環境は別々のユーザーストアを持っています。開発/プレビューアプリで作成したアカウントは開発環境にのみ存在し、発行時に本番にコピーされません。発行済みアプリで再度サインアップする必要があります。ClerkのuserIdに関連付けたデータも同様です。ワークスペースでAuthペインを開き、Usersタブの環境トグルを使って各環境のユーザーを確認してください。詳細は別々のユーザーストアを参照してください。
Clerk Authは無料で使用できますか？
現在、Clerk Authは無料です。Replit上の他の使用量ベースのサービスと同様に、後で使用量ベースの料金が導入される可能性があります。将来の料金は既存のReplit請求を通じて適用されます。別途Clerkの請求書や支払い方法は必要ありません。Clerk AuthはマンスリーアクティブユーザーのMAU制限がありますか？
ありません。外部Clerkプランとは異なり（ティアによってMAUが上限）、Clerk AuthはMAUの制限を課しません。Clerk AuthはExternal Clerkとどう違いますか？
Clerk Authの背後にあるReplit管理のClerkテナントは、Clerkアカウントで作成したClerkアプリ（External Clerk）と比べていくつかの違いがあります。以下の表は現在の両者の違いを示しています。これはClerk Authの現在の状態を反映しており、サポートされる機能セットは継続的に拡大していきます。| Clerk Auth | External Clerk | |
|---|---|---|
| セットアップ | Replitによって自動プロビジョニング | 自分でセットアップ |
| Clerkテナントの所有権 | Replit管理、アプリが所有 | Clerkアカウントが所有 |
| 料金体系 | 現在無料（将来的に従量課金予定） | サブスクリプション＋従量課金 |
| 請求 | Replit請求（現在無料） | Clerkアカウントでの請求 |
| MAU制限 | 無制限 | ティアによる制限 |
| プロキシとドメイン設定 | replit.appと購入済みドメインは自動、リンクドドメインは手動 | 手動 |
| SSOプロバイダー | 特定のプロバイダーのみ対応：Google、Apple、GitHub、X | より多くのプロバイダーに対応 |
| ユーザー管理画面 | Project EditorのAuthツール | Clerkアプリダッシュボード |
| SMS | 非対応 | 対応 |
| MFA | 非対応 | 対応 |
| 組織テナント | 非対応 | 対応 |
手動で対応が必要なClerk Authの設定は何ですか？
Clerk Authのほとんどのセットアップは自動化されていますが、一部の設定はAuthツール以外での操作が必要です：- SSOプロバイダーのカスタムOAuth認証情報 — プロバイダーの同意画面にReplitのデフォルトではなくアプリの名前とブランディングを表示したい場合は、プロバイダーのデベロッパーコンソールでOAuthアプリを登録し、認証情報をAuthペインに貼り付けます。SSOプロバイダーのOAuth認証情報の設定を参照してください。
- 外部ドメインのメール認証用DNSレコード — アプリが別のプロバイダーで管理されている外部ドメインをリンクしている場合、認証メールがドメインから配信されるようにDNSレコードを追加する必要があります。メール認証のドメインセットアップを参照してください。
Replit管理のClerkアプリの代わりに独自のClerkアプリを使用できますか？
可能です。アプリにすでにReplit管理のClerkアプリがプロビジョニングされている場合は、独自の外部Clerkアプリを接続する前にまず削除してください：- Project EditorのAuthペインを開きます。
- Configureタブに移動します。
- ページの下部までスクロールしてDelete Clerk appをクリックします。
追加リソース
- 既存アプリをClerk Authに移行する — 既存のユーザーデータを持つビジネスアプリをアカウントの継続性を損なわずにClerk Authに移行するためのベストプラクティス
- Google SSOの設定 — カスタムGoogle OAuth認証情報のセットアップ
- GitHub SSOの設定 — カスタムGitHub OAuth認証情報のセットアップ
- Apple SSOの設定 — カスタムApple Sign In認証情報のセットアップ
- X（Twitter）SSOの設定 — カスタムX OAuth認証情報のセットアップ
- Clerkドキュメント — 外部Clerkアプリを統合するビルダー向けのリファレンス