> ## Documentation Index
> Fetch the complete documentation index at: https://translations.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

> Auth0テナント環境を実運用に乗せる方法。

# 運用 (B2C)

運用を実現するには、事業継続に必要な、スケーラブルで測定・定量化可能な運用を支えるインフラを構成・整備する必要があります。Auth0 では、これには補助サービス (メールプロバイダーなど) の設定、デプロイメント向けサービスの監視、異常な状況の検知、本番環境で問題が発生した際に迅速かつ円滑に復旧するための準備が含まれます。

効果的な運用体制を確立することは、成功している顧客がその価値を実感している取り組みです。ワークフローを検討する際には、次のような点を考慮する必要があります。

* 障害を事前に検知するには、何をすべきでしょうか？
* Auth0 の運用状況に関するデータをどのように取得できますか？
* Auth0 は、Auth0 サービスにおける今後の変更に関する情報を提供していますか？
* Auth0 からの重要なお知らせをどのように確認できますか？
* Auth0 の限られたデータ保持期間を超えて分析・保管できるようにするには、Auth0 のログデータをどのように扱うべきでしょうか？
* アプリケーションのピーク負荷によってレート制限やその他のエラーが発生していないかを判断するために、Auth0 のログをどのように調べればよいですか？
* ユーザー向けに本番環境で必要な規模のメール配信を支えるには、どのメールサービスを使うべきでしょうか？本番環境で Auth0 の標準メールプロバイダーを使用できますか？
* ファイアウォールを構成する必要はありますか？また、Auth0 からの通信を受信する必要がある内部サービス (カスタムデータベース、Web サービス、メールサーバーなど) のために、どのファイアウォールポートを開放する必要がありますか？

Auth0 は、Auth0 サービスの運用を[監視](/docs/ja-jp/get-started/architecture-scenarios/business-to-consumer/operations#monitoring)する機能をサポートしているほか、Auth0 の[サービスステータス](/docs/ja-jp/get-started/architecture-scenarios/business-to-consumer/operations#service-status)に関する情報も提供しています。さらに、Auth0 は、Auth0 サービスに対する今後の変更に関する情報を、さまざまな[通知](/docs/ja-jp/get-started/architecture-scenarios/business-to-consumer/operations#notifications)を通じて提供しています。Auth0 の[ログ](/docs/ja-jp/get-started/architecture-scenarios/business-to-consumer/operations#logging)サービスも、レート制限や過剰な負荷によって生じる制約を含め、運用上の異常を追跡・特定するための幅広い機能を提供しています。

Auth0 には、標準で統合を迅速化するためのメール配信サービスが用意されています。ただし、これらのサービスは本番環境での大規模利用を想定したものではなく、メール配信に関して特定のサービスレベルや保証も提供していません。ベストプラクティスとして、通常は独自の[メールプロバイダー](/docs/ja-jp/get-started/architecture-scenarios/business-to-consumer/operations#email-provider-setup)を設定することを推奨しています。

また、Auth0 との統合や Auth0 の拡張機能の利用を支えるために、[インフラストラクチャ](/docs/ja-jp/get-started/architecture-scenarios/business-to-consumer/operations#infrastructure)構成を変更する必要がある場合もあります。たとえば、内部または外部のインフラにコールバックを提供する必要がある場合 (例: Actions、Rules、Hooks で外部 API 呼び出しを行う必要がある場合、または既存のレガシー ID ストアを活用するためにカスタムデータベーススクリプトを使用する必要がある場合) は、ファイアウォール設定を構成する必要があるかもしれません。

<div id="service-status">
  ## サービスのステータス
</div>

Auth0の[ステータスダッシュボード](https://status.auth0.com/)とAuth0の[稼働状況ダッシュボード](http://uptime.auth0.com/)では、Auth0サービスの現在および過去の状態を、人が見てわかりやすい形式で確認できます。監視アラートが発報された場合は、トラブルシューティングの第一段階として、運用担当者はまずステータスダッシュボードを確認し、現在障害が発生していないかを確認する必要があります。パブリッククラウドのステータスページでは障害通知の購読も可能です。また、Social Providers など、依存しているサードパーティの[外部サービス](/docs/ja-jp/deploy-monitor/monitor/check-external-services-status)のステータスも確認することをお勧めします。こうした情報をすぐ確認できるようにしておくと、問題のトラブルシューティング時に原因候補をすばやく切り分けるのに役立ちます。そのため、これらの確認事項は、開発者だけでなくヘルプデスク担当者にとっても、トラブルシューティングチェックリストの最上位に置くべきです。

<Info>
  ### ベストプラクティス

  Auth0および依存サービス (Social Providers など) のステータス確認方法に関する情報は、開発者とヘルプデスク担当者の双方にとって、トラブルシューティングチェックリストの最上位に置くべきです。また、ステータス更新の通知を受け取れるよう、Auth0のステータスページで購読を設定することをお勧めします。
</Info>

パブリッククラウドサービスで障害が発生した場合、Auth0は根本原因分析 (RCA) を実施し、その結果をAuth0のステータスページに公開します。Auth0では、障害発生後に根本原因の特定、寄与要因の分析、再発防止策の検討を含む徹底的な調査を行うため、RCAドキュメントの公開までに数週間かかる場合があります。

<div id="email-provider-setup">
  ## メールプロバイダーの設定
</div>

Auth0 は、サインアップ時のウェルカムメール、メールアドレスの確認、パスワード漏えい、パスワードリセットなどのイベントに応じて、ユーザーに[メール](/docs/ja-jp/customize/email)を送信します。イベントの種類ごとにメールテンプレートをカスタマイズできるほか、メール処理を高度にカスタマイズすることも可能です。Auth0 には、基本的なテスト向けに送信容量が限られたテスト用メールプロバイダーが用意されていますが、本番環境で使用するには独自のメールプロバイダーを設定する必要があります。また、独自のプロバイダーを設定するまでは、メールテンプレートのカスタマイズは機能しません。

<Info>
  ### ベストプラクティス

  デフォルトの Auth0 メールプロバイダーでは、本番運用に必要な量のメール送信やメールテンプレートのカスタマイズはサポートされていません。そのため、本番環境にデプロイする前に独自のメールプロバイダーを設定してください。
</Info>

<div id="infrastructure">
  ## インフラストラクチャ
</div>

<div id="firewalls">
  ### ファイアウォール
</div>

Auth0 で実行されるカスタムコード (Action、Rule、Hook、またはカスタムデータベーススクリプトなど) からネットワーク内のサービスを呼び出す場合、または Auth0 でオンプレミスの SMTP プロバイダーを設定する場合は、[Auth0 からのインバウンドトラフィック](/docs/ja-jp/secure/security-guidance/data-security/allowlist) を許可するようにファイアウォールを設定する必要がある場合があります。ファイアウォールで許可する IP アドレスはリージョンごとに異なり、<Tooltip tip="Auth0 Dashboard: サービスを設定するための Auth0 の主要な製品です。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=Auth0+dashboard">Auth0 Dashboard</Tooltip> の Rules、Hooks、カスタムデータベーススクリプト、メールプロバイダーの設定画面に一覧表示されています。

<div id="logging">
  ## ログ
</div>

Auth0 には、イベントをログに記録するための豊富な機能があり、さらにログをスキャンしてイベントの異常を特定することもできます (詳細は[ログのドキュメント](/docs/ja-jp/deploy-monitor/logs)を参照してください) 。Auth0 のログの標準保持期間はサブスクリプションレベルによって異なり、最短で 2 日、最長でも 30 日です。Auth0 がサポートする外部ロギングサービスとの連携を活用すれば、この期間を超えてログを保持できるほか、組織全体のログを集約することも可能です。

<Info>
  ### ベストプラクティス

  ログストリーミングソリューションのいずれかを利用して、ログデータを外部のログ分析サービスに送信することをおすすめします。これにより、データをより長期間保持できるようになり、ログデータに対する高度な分析も可能になります。
</Info>

ご利用のサブスクリプションレベルにおけるログデータの[保持期間](/docs/ja-jp/deploy-monitor/logs/log-data-retention)を確認し、ログデータを外部のログ分析サービスに送信するためのログデータエクスポート拡張機能を実装してください。Auth0 Marketplace では、[ログストリーミングソリューション](https://marketplace.auth0.com/features/log-streaming)のいずれかを利用できます。

開発チームは、トラブルシューティングや、QA テストでは見つけにくい断続的なエラーの検出にログファイルを活用できます。セキュリティチームも、フォレンジックデータが必要になった場合に備えて、ログデータを必要とするでしょう。包括的な分析機能を提供するサービスにログファイルをエクスポートすることで、利用傾向や <Tooltip tip="Attack Protection: Auth0 が提供する、ブルートフォース対策、不審な IP のスロットリング、漏えいしたパスワードの検出、ボット検出、適応型多要素認証など、攻撃を検出して軽減するための機能。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=attack+protection">attack protection</Tooltip> のトリガーといったパターンの把握に役立ちます。

<div id="rate-limits-and-other-errors">
  ### レート制限やその他のエラー
</div>

Auth0 では、[レート制限を超過した](/docs/ja-jp/troubleshoot/customer-support/operational-policies/rate-limit-policy)ときに報告されるエラーに対して、固有のエラーコードを提供しています。ログを自動的にスキャンしてレート制限エラーを検出できるように設定しておくと、レート制限に達するアクティビティがユーザーに大きな影響を及ぼす前に、先手を打って対処できます。Auth0 は他の種類のエラーについてもエラーコードを公開しており、[認証エラー](/docs/ja-jp/libraries/common-auth0-library-authentication-errors)に加えて、Auth0 <Tooltip tip="Management API: お客様が管理タスクを実行できるようにする製品。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=Management+API">Management API</Tooltip> 呼び出しによるエラーについてもログをスキャンすると役立ちます (Management API のエラーコードは、[Management API Explorer](https://auth0.com/docs/api/management/v2) で各呼び出しの下に表示されます) 。

<Info>
  ### ベストプラクティス

  Rule 内からユーザープロファイル情報を取得するために Management API を呼び出すと、レート制限エラーの一般的な原因になります。これは、このような API 呼び出しがログインのたびに実行される可能性があるうえ、定期的なセッションチェックでも実行されるためです。
</Info>

<div id="monitoring">
  ## 監視
</div>

サービス停止に先回りして対処するために必要な情報をサポートチームまたは運用チームが適時受け取れるよう、[Auth0 実装の監視](/docs/ja-jp/deploy-monitor/monitor)の仕組みを整備する必要があります。Auth0 では、監視基盤に組み込める監視用エンドポイントを提供しています。これらのエンドポイントは、監視サービスで利用しやすいレスポンスを返すよう設計されています。なお、これらのエンドポイントで取得できるのは Auth0 に関するデータのみです。ユーザーがログインできるかどうかを確認するうえで不可欠な、完全なエンドツーエンド監視を行うには、合成トランザクション監視を設定することをおすすめします。これにより監視をより細かい粒度で行えるようになり、Auth0 に起因しない障害やパフォーマンス低下も検知できるため、より先回りした対応が可能になります。

<Info>
  ### ベストプラクティス

  認証のエンドツーエンド監視を行いやすくするため、合成ログイントランザクションを送信できるように設定しておく必要があります。これは、権限を持たないテストユーザーと [Resource Owner Password Grant](/docs/ja-jp/get-started/authentication-and-authorization-flow/resource-owner-password-flow/call-your-api-using-resource-owner-password-flow) を組み合わせて使用するシンプルなアプリケーションで実現できます。また、[Auth0 のレート制限ポリシー](/docs/ja-jp/troubleshoot/customer-support/operational-policies/rate-limit-policy)も忘れずに考慮してください。
</Info>

<div id="notifications">
  ## 通知
</div>

Auth0 からの通知にはいくつかの種類があり、テナントやプロジェクトに影響する重要な情報が含まれることがあるため、注意して確認してください。

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  セキュリティに関する事前通知やその他の運用上のお知らせは、Auth0 から Dashboard 管理者に送信されます。こうしたメッセージを受け取る必要がある担当者が Dashboard 管理者になっていることを確認してください。
</Callout>

<div id="dashboard-notifications">
  ### Dashboard の通知
</div>

Auth0 は、テナントに関連する重要なお知らせを随時送信することがあります。こうしたサービスに関するお知らせは Auth0 Dashboard に送信され、内容の重大度に応じて、登録済みの Auth0 Dashboard 管理者にメールでも送信されます。定期的に Dashboard にログインし、画面上部のベルアイコンを確認して、重要なお知らせが届いていないかを確認する習慣をつけてください。また、Auth0 からのメールには、必要な変更や対応に関する重要な情報が含まれている場合があるため、速やかに確認してください。

<div id="change-log">
  ### 変更ログ
</div>

Auth0 は、Auth0 の[変更ログ](https://auth0.com/changelog)でサービスの変更に関する情報を提供しています。変更内容を把握できるよう、Auth0 の変更ログを定期的に確認する習慣をつけてください。問題を調査するサポートチームにとっては、特にそれが[破壊的変更](/docs/ja-jp/troubleshoot/product-lifecycle/deprecations-and-migrations)である場合、最近の変更が関係している可能性を判断するうえで、変更ログの確認が役立つことがあります。開発チームもまた、活用できる新機能を見つけるために変更ログを確認するとよいでしょう。

<div id="project-planning-guide">
  ## プロジェクト計画ガイド
</div>

推奨戦略の詳細を確認できるよう、ダウンロードして参照できるPDF形式の計画ガイドをご用意しています。

[B2C IAM プロジェクト計画ガイド](https://assets.ctfassets.net/cdy7uua7fh8z/3er1aEQ7Ul0q3c9leJWczR/b1f18b4c16abb7e78b01e4eb2b52bb8e/B2C_Project_Planning.pdf)