Vonage Protection Suite for Oktaのセットアップ方法

v2.0の新機能

v1.x からアップグレードされる場合、変更点は以下の通りです：

• 名前付きトークン — これで、ハッシュの切り詰め値に頼る代わりに、各トークンに人間が読みやすい名前を付けることができるようになりました。これにより、デプロイメント全体にわたる複数のトークンの管理が容易になります。
• インスタンスレベルの設定 — セキュリティ設定（Identity Insights、Fraud Defender、レート制限）は、個々のトークンに紐付けられなくなりました。これらは専用の「設定」タブにまとめられ、インスタンス上のすべてのトークンに適用されます。トークンの追加やローテーションを行う際、セキュリティポリシーの再設定は不要になりました。
• カスタムOTPメッセージテンプレート — 管理者は、言語ごとおよび通信手段（SMS／音声）ごとに、カスタムOTPメッセージテンプレートを定義できるようになりました。この機能を利用するには、Accountレベルでの有効化が必要です。有効化をご希望の場合は、VonageのAccountマネージャーまでお問い合わせください。

v1.6からのアップグレード

v1.6 と v2.0 は互換性がなく、インプレースアップグレードの方法は存在しません。v2.0 は新しい VCR インスタンスとしてデプロイする必要があります。トークンモデル、インスタンスレベルのクレーム、および状態保存キーが変更されています。 v1.6 インスタンスのトークン、使用統計、および OTP アクティビティは移行できず、引き継がれません。v1.6 インスタンスを廃止する前に、新しい v2.0 インスタンスから生成された認証情報を使用して、Okta Telephony のインラインフックおよびイベントフックを再設定してください。

はじめに

ユーザーがOktaで本人確認を行う必要がある場合、Oktaはワンタイムパスワード（OTP）を生成します。ただし、OktaはOTPを直接送信しません。代わりに、OTPをユーザーに配信する外部プロバイダーに依存しています。そのため Okta用Vonage Protection Suite SMS および音声 OTP 配信用の管理されたプラグアンドプレイコネクタを提供することで、この目的に対応します。このコネクタは、Telephony Inline Hooksを介してOkta Identity Engineに直接統合され、Vonage Verifyを介してSMSまたは音声通話でOTPを配信します。このコネクタは、Vonage Cloud Runtime (VCR) 上に構築されています。

サポートされるOktaプラットフォーム

Vonage Protection Suite for Oktaは、Okta Workforce Identity Cloudで利用可能なOktaのTelephony Inline Hook（Oktaアイデンティティエンジン（OIE）と従来のClassic Engineの両方を含む）を介して統合されます。このリリースでは、Auth0（Okta Customer Identity Cloud）はサポートされていません。Auth0は、Telephony Inline Hookとは異なる拡張性モデル（Actions/カスタムクレデンシャルプロバイダ）を使用しており、別途統合が必要です。

2層の不正インテリジェンス・モデル

について Okta用Vonage Protection Suite は2層の不正インテリジェンス・モデルを使用している：

• アイデンティティ・インサイトのOTP番号事前検証（オプション）:キャリアデータベース（有効性、キャリア）に照らし合わせて番号をスクリーニングし、OTP配信が開始される前に不正をブロックする。エンドユーザーからのアクションを必要としないため、これは受動的なインテリジェンスレイヤーです。
• OTP中のレイヤー2不正防御装置:SMSポンピング保護、地理的許可、速度制御、速度制限。

このガイドでは、OktaテナントをVonage Verifyに接続するために Okta用Vonage Protection SuiteOTPはSMSまたは音声で確実に配信される。

コネクターの流れ

次の図は、OktaとVonage Verifyの間のコネクタの配置を示しています：

前提条件

始める前に、以下を確認してください：

• Okta Identity Engine (OIE)を備えたアクティブなOktaテナント。
• Oktaで電話認証を有効にするOkta Admin Console > Security > Authenticators > Setup > Phone).
• Okta Admin Consoleにアクセスし、インラインフックとイベントフックを設定できます。
• Vonage API アカウント (無料でご登録いただけます。)とAPIキー(これらの認証情報はあなたの API設定 Vonage Dashboard内)。
• へのアクセス Vonageダッシュボード.
• Vonage Cloud Runtime Advancedサブスクリプション。お持ちでない場合は、Vonage Customer Success Associate (CSA)に連絡してアクティベートしてください。

Vonage Cloud Runtimeにコネクタをデプロイする

1. ログイン Vonage Cloud Runtime をクリックしてください。 Okta用Vonage Protection Suite タイルを使用している。
2. 右側のメニューから APIキー に対してコネクタをデプロイします。アカウントに API キーが 1 つしかない場合、この手順は自動的にスキップされます。
3. クリック 新しいインスタンスをデプロイする.

4. コネクタ構成タイプで スタンダード をクリックしてください。 続ける.

5. パラメータを入力してください：
   • 地域:地域 : エンティティがホストされる地域。
   • インスタンス名： インスタンスの固有名。
   • Vonage番号（オプション）:この番号はSMS送信者IDとなり、E.164形式で数字のみで構成されている必要があります(「+」記号のない国際番号)。この番号が設定されていない場合、以下に指定するブランド名が代わりに使用されます。発信者番号はVerifyによってランダムに選択されるため、この値は音声通話には適用されません。
   • ブランド名（必須）:OTP メッセージ本文は、SMS でこのブランド名を使用する。この値は音声通話では無視されます。代わりに、発信者番号は宛先地域に適したものとしてVerifyによってランダムに選択されます。
   • 音声通話のフォールバック（必須）: 有効にすると、SMS配信に失敗した場合、コネクタは自動的に音声通話を試みます。

6. クリック 続ける インスタンスをデプロイする。

コネクタの設定

管理者アプリケーションの起動

インスタンスのデプロイ後、コネクタの Admin Applications を起動します。これにより、セキュリティ・ポリシーの設定と認証トークンの生成が可能になります。そのためには、以下の手順に従ってください：

1. 以前に作成したインスタンスを選択し 打ち上げ ボタンをクリックする。

2. をクリックして、Vonage 認証情報を使って認証します。 Vonageで本人確認を行う ボタンをクリックする。

ダッシュボードタブ

コネクタのAdmin Applicationを起動すると、次のようにリダイレクトされます。 ダッシュボード タブを使用します。これは、OTP の配信と認証アクティビティをリアルタイムで可視化します。

について ダッシュボード タブには以下のデータが表示される：

• カウンターセクション は次のような指標を示している：
  • SMS合計:SMS 配信の全体的な試行回数（成功した回数と失敗した回数の両方）。
  • SMSの成功:正常に完了したSMSの配信数。
  • SMSブロック:Identity InsightsまたはFraud DefenderによってブロックされたSMS配信の数。
  • トータル・ボイス:音声配信の試行回数の合計（成功および失敗の両方）。
  • 声の成功:正常に完了した音声配信の総数。
  • 音声ブロック:ブロックされた音声配信の数。
• 最近のOTP活動 には、すべてのトークンについて最近 10 回の OTP 配信試行が表示される：
  • タイムスタンプ:いつ配達を試みたか。
  • 目的地:マスクされた電話番号。
  • チャンネル:SMS/VOICE.
  • ステータス:SUCCESS（成功）、FAILED（失敗）、FLAGGED（フラグ・アンド・デリバリーの場合はアンバー）。
  • 説明:目のアイコンをクリックすると、失敗またはフラグが立った完全な理由が表示されます。
  • レイテンシー:配信完了までの時間（ミリ秒）。
  • トークン名: 作成時に割り当てられたトークン名。
• 最近の認証イベント は、Oktaから取得した直近10件の認証イベントを表示します：
  • タイムスタンプ:イベントがいつ公開されたかを示す
  • トークン名: 作成時に割り当てられたトークン名。
  • イベント:Oktaイベントの種類（例． user.authentication.auth_via_mfa).
  • ファクター:使用される認証要素（例：SMS_FACTOR、CONVERSION）。
  • 成果:SUCCESS、FAILURE、または UNKNOWN。
  • ユーザー:OktaアクターID。
  • リクエスト:認証要求に関連付けられたID。

[トークン] タブ

[トークン] タブでは、生成されたすべてのトークンの概要を確認できます。各エントリには、トークン名、現在のステータス、作成日、有効期限が表示されます。

トークンのステータスは、以下のいずれかになります：

• アクティブ — トークンは有効であり、現在使用中です。
• 猶予期間 — このトークンは更新されました。新しいトークンが有効になりましたが、ダウンタイムを発生させずにOktaの設定を更新できるよう、このトークンはあと24時間有効です。
• 期限切れ — トークンの有効期限が切れたため、これ以上の使用はできません。
• 取り消された — トークンは手動で無効化されたため、これ以降は使用できなくなりました。

トークンの追加

新しいトークンを追加する際は、次の2つの値を指定する必要があります：

• トークン名 — ダッシュボード、OTPアクティビティ、認証イベントの各ビューでトークンを識別するのに役立つ、人間が読みやすいラベルです。これは、同じインスタンス上で複数のトークンを管理する際に特に役立ちます。
• トークンの有効期限 — トークンの有効期間：24時間、7日間、30日間、90日間、または「無期限」。有効期間を短く設定すると、セキュリティ侵害が発生した場合のリスクは軽減されますが、トークンの更新頻度が高くなります。

トークンの回転

トークンをローテーションすると、新しいトークンが発行される一方で、既存のトークンは24時間の猶予期間中は引き続き有効となります。この期間中は両方のトークンが受け入れられるため、OTPの配信を中断することなくOktaの設定を更新できます。新しいトークンは、元のトークンと同じ名前と有効期限の設定を引き継ぎます。ローテーション機能を活用して、ダウンタイムなしで定期的に認証情報を更新してください。 詳細については、 認証トークンの管理とローテーション 章。

トークンの無効化

トークンを失効させると、そのトークンは直ちに無効になります。この操作は、トークンが不正利用された場合や、もはや必要なくなった場合にのみ行ってください。失効は即座に行われ、取り消すことはできません。

[設定] タブ

について 構成 [tab] タブでは、すべてのトークンに適用されるセキュリティポリシーを定義します。

レイヤー 1: Identity Insights による OTP ナンバーの事前検証 (オプション）

コネクタの2層セキュリティモデルは、オプションのIdentity InsightsによるOTP番号事前検証から始まります。

アイデンティティ・インサイト は、携帯電話事業者のデータベースにリアルタイムでアクセスできるVonage APIです。電話番号のリスクレベルを評価するのに役立ちます。コネクタでは、OTP送信前のスクリーニング・ツールとして機能します。コネクタはこれらのチェック結果を使用します。

1. を有効にする。 アイデンティティ・インサイト 機能を使用するには、トグルを オン.
2. 実施したいチェックを選択する：
   • Numbersのフォーマットと有効性（無料）:有効な携帯電話番号かどうかを確認し、VoIPやバーチャル番号に自動的にフラグを付けます。
   • オリジナルキャリア検索（リクエストごとに課金）:この番号が最初に発行されたときに割り当てられたネットワークと回線タイプを識別する。最初からVoIPとして登録された番号をスクリーニングするのに便利。後にVoIPにポートされた携帯電話番号は捕捉されない。
     • ネットワーク・タイプ・フィルター:選択されていないネットワーク・タイプのNumbersはフラグが立てられます。
   • 現在のキャリア検索（リクエストごとに有料）:ポーティングによる変更も含め、現在この番号にサービスを提供しているネットワークとライブ回線タイプを識別します。
3. 地理的およびチャネルフィルタ：これらのフィルタは、電話番号の地理的またはネットワーク特性に基づいて、OTP配信を制限します。
   • 国別許可リスト:ISO 3166-1 alpha-2の国コードを入力してください（例：US、GB、DE）。これらの国に関連する番号のみが許可されます。すべての国を許可するには空欄にしてください。
4. 検証チェック中に宛先番号にフラグが立った場合に取るアクションを選択します：
   • ブロックOTP:OTP が配信されません。失敗の理由は ダッシュボードタブ > 最近の OTP アクティビティ > 説明.
   • フラッグ＆デリバリー:OTPは配信されるが、ダッシュボードではアンバーのフラグが立ち、さらに確認する必要がある。潜在的に正当なユーザーをブロックせずに可視化したい場合に使用します。ステータスは ダッシュボードタブ > 最近のOTPアクティビティ > ステータス.
   • ログのみ:チェック結果は記録されるが、それ以上の処置は取られない。フラグは付けられない。ブロックまたはフラグポリシーにコミットする前に、フラグレートを理解するために初期展開時に便利です。OTPは通常通り送信されます。には何も表示されません。 ダッシュボード タブ

レイヤー2：OTP時の不正防御

番号がレイヤー1のチェックを正常に通過すると（またはIdentity Insightsが無効の場合）、OTPがVonage Verifyに送信され、配信されます。この段階で、追加の保護レイヤーとして Fraud Defender が引き継がれます。

詐欺ディフェンダー SMSポンピング、人為的なトラフィック増加（AIT）、およびトラフィックバースト攻撃に対する防御。この機能を有効にするための操作は必要ありません。Vonage Verifyを通じて処理されるすべてのOTPトラフィックに自動的に適用されます。

ティアの選択

コネクタの設定パネルで、Fraud Defender Advancedは次のように表示されます。 含まれている、 Verifyトラフィックすべてに追加料金なしでご利用いただけます。Fraud Defender Premiumが必要な場合は、Vonage Account Managerに連絡して有効にしてください。

レートリミット

10分間のウィンドウ内で、電話番号ごとにOTPリクエストの最大数を設定します。デフォルトは5回です。これにより、同じ電話番号をターゲットに OTP 要求が繰り返されるのを防ぐことができます。この機能は不要な場合は無効にできます。

配送

• ブランド名:OTP メッセージで受信者に表示されるブランド名。サーバーで設定されたグローバルブランド名を上書きします。
• 推奨テンプレート: この機能を使用すると、言語ごと、および通信チャネル（SMS/音声）ごとに、独自のOTPメッセージテンプレートを設定できます。コードやブランド名用のプレースホルダーを使用して、独自のOTPメッセージを作成してください。インスタンス上のすべてのトークンに適用される優先テンプレートを設定してください。設定がない場合は、Vonageの標準テンプレートが使用されます。この機能を有効にするには、VonageのAccountマネージャーにお問い合わせください。
• SMSから音声へのフォールバック:SMS配信に失敗した場合、音声通話で自動的に再試行します。この機能は必要なければ無効にできます。

生成されたトークンの詳細を記録する

セキュリティポリシーが設定され、トークンが生成されたら、生成されたトークンの詳細を記録してください。トークンの詳細は二度と表示されません。この情報は、Oktaの設定ステップでOktaを設定するために不可欠です：

• テレフォニーウェブフックURL
• イベント・ウェブフックURL
• 認証ヘッダー名
• トークンの秘密

Oktaを設定する

コネクタをデプロイしてトークンを生成したら、Okta Admin ConsoleでTelephony Inline HookとEvent HookをWebhook URLとトークンで設定します。

テレフォニー・インラインフックの設定

次に、以下の手順に従って、テレフォニー・インライン・フックを設定します：

1. Okta Admin Consoleにログインします。
2. に移動する。 ワークフロー > インラインフック.をクリックしてください。 インライン・フックの追加を選択する。 テレフォニー.

3. フックの詳細を記入してください：

• 名称:名前（例："Vonage OTP"）を入力します。
• URL:生成されたトークンの詳細からTelephony Webhook URLを貼り付けます。
• 認証フィールド:生成されたトークンの詳細から Auth Header Name を貼り付けます。
• 認証秘密:生成されたトークンの詳細からトークンシークレットを貼り付けます。

4. クリック セーブ.

イベント・フックの設定

次に、以下の手順でイベントフックを設定します：

1. に移動する。 ワークフロー > イベントフック.

2. をクリックする。 イベントフックの作成.
3. フックの詳細を記入してください：

• 名称:名前（例："Vonage Events"）を入力します。
• URL:生成されたトークンの詳細からEvent Webhook URLを貼り付けます。
• 認証フィールド:生成されたトークンの詳細から Auth Header Name を貼り付けます。
• 認証秘密:生成されたトークンの詳細からトークンシークレットを貼り付けます。

4. について リクエスト セクションでは、Okta がエンドポイントに送信するリクエストを定義します。リクエストを MFAによるユーザー認証 イベントを開催する。
5. クリック 保存して続行.

接続性の検証

次に、Oktaとコネクタ間の接続がアクティブであることを確認します。そのためには、Okta Admin Consoleで両方のフックにActive & Verifyのステータスが表示されていることを確認する必要があります：

1. のVerifyボタンをクリックします。 エンドポイントの所有権の検証 イベントフックを作成した直後に表示されるポップアップ。

統合のテスト

Oktaのビルトインプレビューツールを使用して、手順に従って統合をテストすることができます：

1. Okta Admin Consoleで、次の場所に移動します。 セキュリティ > 認証機能 > セットアップ > 電話 をクリックして、Oktaで電話認証が有効になっていることを確認してください。
2. プレビューテストを実行する：
   • に移動する。 ワークフロー > インラインフック.
   • 作成したテレフォニー・インライン・フックを見つけ アクション > プレビュー.
   • で インラインフックリクエストの設定:
     • テストユーザーの情報を入力します： data.userProfile (有効な認証手段として電話を持っているユーザー）。
     • 選択 requestType (MFA登録、MFA認証、Accountロック解除、またはパスワードリセット）。
   • クリック リクエストの作成 でJSONペイロードを構築する。
   • クリック 編集 をクリックし、必要であればリクエストを修正する。
   • デフォルトの電話番号（9876543210）をE.164形式の実際の携帯電話番号（例：+447700900000）に置き換えてください。
   • クリック 回答を見る を使ってフックを起動します。成功するとステータスが表示される： 成功 を配達期間と一緒に送る。

認証トークンの管理とローテーション

認証トークンは、Okta 組織と Vonage コネクタ間のすべての通信を保護します。 セキュリティ上のベストプラクティスとして、Vonage管理パネルまたはToken Management APIを介してプログラム的に、いつでもトークンを更新することができます。トークンを更新すると、新しいトークンが即座に発行されますが、以前のトークンは24時間有効なままとなるため、OTPの配信を中断することなく、Oktaの設定を更新する時間的余裕が確保されます。

Vonage 管理パネル経由で

1. にログインする。 Vonage 管理パネル Vonageの管理Accountを使用して。
2. に移動する。 トークン タブを開き、ローテーションしたいトークンを探します。
3. をクリックする。 回転 ボタンをタップしてトークンを回転させます。

4. 選択 確認 トークンを回転させるには。
5. 新しいトークンが表示されます。一度しか表示されないため、すぐにコピーして保存してください。
6. 新しいトークンは、現在次のように表示されます。 アクティブ リスト内で。古いトークンは 回転済み そして、24時間の猶予期間中は有効であり、その期間が過ぎると自動的に失効します。

API経由で

OpenAPI仕様書およびPostmanコレクションは、以下の場所で参照可能です。 Vonage Protection Suite for Okta ユーザーガイド > ステップ 6: 認証トークンの管理と更新 > API を使用したトークンの更新.

認証

すべてのAPIエンドポイントでは、HTTP Basic認証が使用されます。すべてのリクエストに認証情報を含めてください。Vonage APIキーとAPIシークレットをBase64文字列としてエンコードしてください：

Authorization: Basic base64(apiKey:apiSecret)

トークン一覧を取得する

トークンをローテーションする前に、そのトークンのUUIDが必要です。「List Tokens」エンドポイントを使用して、すべてのアクティブなトークンとそのIDを取得してください。

GET /admin/tokens

そのインスタンスに関連付けられているすべてのトークンのマップを返します。各エントリには、トークンの ID、ステータス、クレーム、および使用回数が含まれます。

リクエスト

GET /admin/tokens
Authorization: Basic <credentials>

応答 — 200 OK:

{
  "tokens": {
    "94c624db-d933-446c-be4d-bf35c0dbd13a": {
      "id": "94c624db-d933-446c-be4d-bf35c0dbd13a",
      "name": "Production Okta",
      "truncatedToken": "***",
      "expiresIn": "90d",
      "revoked": false,
      "revokedAt": null,
      "rotatedAt": null,
      "gracePeriodEnds": null,
      "createdAt": "2026-06-17T11:09:30.456Z",
      "expirationDate": "2026-09-15T11:09:30.000Z",
      "lastUsed": "2026-06-20T08:15:00.000Z",
      "smsSuccessCount": 0,
      "voiceSuccessCount": 0,
      "smsErrorCount": 0,
      "voiceErrorCount": 0,
      "smsBlockedCount": 0,
      "voiceBlockedCount": 0
    }
  }
}

応答フィールド:

トークンを回転させる

トークンのローテーションでは、同じクレームと新しいタイムスタンプを持つ新しいトークンが発行され、以前のトークンに対して24時間の猶予期間が開始されます。この期間が終了すると、以前のトークンは無効となります。

POST /admin/rotate-token

リクエスト：

POST /admin/rotate-token
Authorization: Basic <credentials>
Content-Type: application/json

{
  "id": "3152b2c3-00b7-4900-b79c-77cfb2663b21"
}

リクエスト本文:

応答 — 200 OK:

{
  "newToken": "<token>",
  "newId": "<uuid>",
  "webhookUrl": "https://<instance-url>/...",
  "authHeaderName": "x-okta-auth"
}

応答フィールド:

Okta の更新（パスワード変更後）

トークンを更新したら、両方のOktaフックを新しい認証情報で更新してください：

1. Okta 管理コンソールで、次の場所に移動します。 ワークフロー > インラインフック, を開いて 電話機能フッククリック [操作] > [編集]、および更新：

• 認証フィールド - authHeaderName 値（デフォルト： x-okta-auth)
• 認証シークレット - 新規 newToken 値

2. こちらへ ワークフロー > イベントフック, を開いて イベントフック、および更新：

• 認証フィールド - authHeaderName 値（デフォルト： x-okta-auth)
• 認証シークレット - 新規 newToken 値

トラブルシューティング

クイックチェック

フルフローをトレースする前に、以下をVerifyする：

資格証明書:OktaのTelephony Webhook URL、Event Webhook URL、Auth Header Name、Token Secretが、トークン生成詳細の値と完全に一致していることを確認します。

フックの状態:Okta Admin Consoleで、次の場所に移動します。 ワークフロー > インラインフック をクリックし、フックのステータスが「Active」および「Verify」であることを確認します。

ダッシュボード:コネクタの「ダッシュボード」タブで最近の OTP アクティビティを確認します。FAILED または FLAGGED イベントを探し、説明アイコンをクリックしてエラーの詳細を確認します。

アイデンティティ・インサイト:OTP がブロックされる場合、Identity Insights が宛先番号にフラグを立てているかどうかを確認する。を調整することを検討してください。 Numbersの場合 フラグが立つ アクションをブロック > フラグと配信またはテストのためのログのみ。

電話認証:Oktaで電話認証が有効になっていることを確認します： Okta Admin Console > Security > Authenticators > Setup > Phone.

問題を段階的に追跡する

何かが期待通りに動作しない場合、以下の段階を経て問題を追跡する：

1. Oktaはリクエストを送信します。:をチェックする。 Okta Admin Console > レポート > システムログ フックコール、ターゲットURL、リクエストステータスを指定する。
2. コネクタがリクエストを処理する:チェック Vonage Cloud Runtime > インスタンス > あなたのインスタンス > ログ 受信リクエスト、Identity Insights の結果、および Verify API 呼び出しについて。
3. OTP配信:チェック Vonage Dashboard > メッセージログ メッセージのステータス、チャンネル、送信者ID、エラーコード、Fraud Defenderのブロック。
4. 認証イベントを受信:チェック コネクタ管理者ダッシュボード > 最近の認証イベント 受信したイベント、イベントの種類、要因、結果、トークンの一致。
5. コンバージョンを記録:チェック Vonage Dashboard > ベリファイログ コンバージョン・ステータス、コンバージョン・フィー、コンバージョン・ミッシングについて。

コネクタエラーコードとIdentity Insightsサブコード

コネクタのエラーコードとIdentity Insightsのサブコードの完全なリストについては、以下を参照してください。 Vonage Protection Suite for Okta ユーザーガイド.

お困りですか？

上記の「トラブルシューティング」を使用しても問題が解決しない場合は、以下までご連絡ください。 Vonageヘルプセンター. リクエストを送信する際は、「」というタイトルのフォームを選択してください。 Vonageコネクタの使用方法 次に、コネクタを選択してください > Okta向けVonage Protection Suiteの利用 これにより、チケットはOkta Connectorのサポートチームに直接転送されます。迅速な解決に役立てるため、APIキー（Account IDのみ。シークレットは含めないでください）、Oktaシステムログに記載されているインラインフックのイベントID、および関連するスクリーンショットやログを添付してください。

さらに読む

• アイデンティティ・インサイト
• 詐欺ディフェンダー
• Vonage Protection Suite for Oktaの記事（ユーザーガイド）
• Verifyアナリティクスとログの概要