---
schema_version: "1"
id: d696aa56cf000fd3e7d317e7e4375a8c526c4f470639b53b81b49a5d6123b3c6
title: アクティビティ ログを使用したビューの読み込み時間の監視
collection: tableau
version: current
locale: ja-jp
portal_url: https://docs.salesforce.com/tableau/current/ja-jp/online/activity_log_monitor_view_load_times.md
canonical_url: https://help.tableau.com/current/online/ja-jp/activity_log_monitor_view_load_times.htm
source_site: help.tableau.com
content_type: documentation
content_hash: dc022eff734727d6410db277e7a3591795756d319464e92b5130ede72251b19a
description: Use Activity Log vizql_http_request events to monitor view load times and troubleshoot slow workbooks.
---
[メイン コンテンツに進む](#main-content)

# アクティビティ ログを使用したビューの読み込み時間の監視

ビューがユーザーにとって最適にレンダリングされるようにすることは、管理者の重要な仕事です。アクティビティ ログを使用すると、パフォーマンス上の懸念事項をリアルタイムで特定して、発生した問題に対処することで、サイトの円滑な運用を維持できます。

このトピックでは、管理者が `vizql_http_request` イベント タイプを使用して、ビューの読み込み時間を把握し、パフォーマンスのボトルネックをトラブルシューティングする方法について説明します。

## 前提条件

ビューの読み込み時間を監視するには、アクティビティ ログ データが構造化されていて、クエリ可能な形式である必要があります。続行する前に、次の前提条件が満たされていることを確認してください。

- **アクティビティ ログの構成:** アクティビティ ログを設定して、ログ ファイルを AWS S3 バケットに書き込みます。
- **データのインポート:** アクティビティ ログによって生成されたログ ファイルを Splunk や Amazon EventBridge などの監視ツールにインポートします。または、ログ ファイルを Snowflake や Google BigQuery などのクラウド データ ウェアハウスにインポートすることもできます。目的は、クエリや分析を簡単に行える形式にすることです。

**注:** このトピックでは、アクティビティ ログ データをデータ ストアにインポートするプロセスは扱いません。詳細な手順については、「[アクティビティ ログの設定](https://help.tableau.com/current/online/ja-jp/activity_log_setup.htm)」と、選択したデータ プラットフォームのドキュメントを参照してください。

## 開始する

どこから始めればよいのでしょうか? ダッシュボードまたはビューの初期読み込み (「bootstrap セッション」イベントと呼ばれる) に焦点を合わせることで、ビューのパフォーマンスを監視できます。このイベントは通常、ビューのレンダリングに必要な時間の大部分をキャプチャし、読み込みにどれくらいかかったかを明確に示します。

bootstrap イベントを監視するには、次の手順に従います。

1. Splunk や Amazon EventBridge など、設定した監視ツールを開きます。
2. 次の値でフィルタリングします。
    
    1. `eventType = vizql_http_request`。
    2. `endpointName = bootstrapSession`。
    3. `eventOutcome = success`。
3. 結果で、`duration` フィールドを見つけます。

vizql\_http\_request イベントの duration フィールドは、操作の完了にかかった時間をミリ秒単位で表します。これにより、Tableau ビューの初期読み込み時間を追跡して分析できるようになります。

> [!TIP]
> 
> **ヒント:** どこから始めればよいかわからない場合は、管理者インサイト スターター ワークブックに含まれる \[ダッシュボードの読み込み時間\] ダッシュボードを使用します。このダッシュボードには、コンテンツの読み込み時間とパフォーマンス評価が表示されるので、問題のあるビューを特定するのに役立ちます。その後、アクティビティ ログを使用して、問題が発生しているユーザーをリアルタイムで確認したり、ワークブックのリビジョンがパフォーマンスにどのような影響を与えているかを把握したりできます。詳細については、[管理者インサイトを使用したカスタム ビューの作成](https://help.tableau.com/current/online/ja-jp/adminview_insights.htm)を参照してください。

## エラーを監視する

パフォーマンスに加えて、bootstrap セッション データを使用して、ユーザーがコンテンツの表示中にエラーに遭遇したかどうかを確認できます。これらのエラーを確認するには、eventOutcome フィールドと eventOutcomeReason フィールド検索します。これらのフィールドは、監視アラートを設定して、調査の開始点を示すのに役立ちます。たとえば、ダッシュボードの表示中にユーザーからエラーが報告された場合、bootstrap セッションを見ると、ユーザー操作の履歴を確認できます。これにより、エラーの原因を特定し、問題がいつから発生し始めたかを把握できるようになります。この情報を知っておくことは、問題の根本原因をトラブルシューティングするために重要です。

- **eventOutcome:** このフィールドには、各操作の成功または失敗のおおまかなカテゴリ (成功、失敗、client\_error、internal\_error) が記録されます。
- **eventOutcomeReason:** このフィールドには、何が問題だったかについての詳細な情報が示され、多くの場合、エラーを説明する HTTP ステータス コードが記録されます。

エラーを監視するには、次の手順に従います。

1. Splunk や Amazon EventBridge など、設定した監視ツールを開きます。
2. 次の値でフィルタリングします。
    
    1. `eventType = vizql_http_request`。
    2. `endpointName = bootstrapSession`。
    3. `eventOutcome != success`。
3. 結果で、`eventOutcomeReason` を確認し、エラーの詳細を把握します。

## パフォーマンスに関する問題のトラブルシューティング

パフォーマンスの問題には多くの要因があるため、問題の調査が困難になる場合があります。ただし、いくつかのアプローチを使用してプロセスを簡略化することができます。このセクションでは、bootstrap セッションを使用してワークブックのパフォーマンスをトラブルシューティングする一般的な方法の概要を説明します。まず、問題が 1 つまたは少数のワークブックに限定されているかどうかを判別します。次に、関連するセクションの手順に従います。

### 1 つのワークブックのトラブルシューティング

単一のワークブックにパフォーマンス上の問題がある場合は、次の手順に従います。

1. **ワークブックのリビジョンを特定します。**
    
    パフォーマンスの問題がワークブックの新しいリビジョンで発生したかどうかを確認します。これを行うには、bootstrap セッションで `workbookRevision` 属性を確認します。このプロセスでは、ワークブックの以前のバージョンへのユーザーのアクセスと比較する必要がある場合があります。
    
    新しいリビジョンがパフォーマンスの問題を引き起こしている場合は、ワークブック所有者に連絡し、協力して設計を改善します。
2. **ユーザー固有の問題を確認します。**
    
    パフォーマンスの問題がワークブックのリビジョンに固有のものではない場合は、特定のユーザーのみに影響するかどうかを判断します。これを行うには、bootstrap セッションの `requestUri` 属性と `actorUserLuid` 属性を確認します。`requestUri` 属性は、アクセスされるワークブックまたはビューの URL を示し、`actorUserLuid` 属性は、ビューにアクセスするユーザーを示します。両方を使用すると、個々のユーザー セッションを区別しやすくなります。
    
    問題がユーザー固有のものである場合は、ユーザー間での類似点を探します。たとえば、問題は、それらのユーザーがアクセスしているカスタマイズされたビューや、ビューの特定の操作方法に起因する場合があります。`requestURI` 属性を解析して、特定のビューを識別する必要があります。
3. **行レベルのセキュリティを確認します。**
    
    一部のユーザーがパフォーマンスの問題を抱えていて、その原因がカスタム ビューではない場合、問題は、ワークブックに実装されている行レベル セキュリティ (RLS) に関連している可能性があります。特にセキュリティ ルールが複雑な場合やデータセットが大きい場合、RLS がパフォーマンスに大きな影響を与える可能性があります。詳細については、「[Tableau の行レベルのセキュリティ オプションの概要](https://help.tableau.com/current/online/ja-jp/rls_options_overview.htm)」を参照してください。

### ワークブックのサブセットのトラブルシューティング

ワークブックのサブセットにパフォーマンスの問題がある場合は、次の手順に従います。

1. **共通のデータ ソースを特定します。**
    
    影響を受けるワークブックが使用しているデータ ソースの共通点を探します。
    
    影響を受けるワークブックがデータベース サーバーまたはクラウド データ ウェアハウスへのライブ接続を使用している場合、パフォーマンスの問題は、ライブ接続にある可能性があります。
    
    影響を受けるワークブックがデータ抽出を使用している場合は、ワークブックが最近更新されたかどうかを確認します。アクティビティ ログの `hist_publish_datasource` イベント タイプまたは管理者インサイトの TS イベント データ ソースを使用して、最近の変更を特定できます。
2. **データ ソースのパフォーマンスを確認します。**
    
    ライブ接続の場合、データベース サーバーまたはクラウド データ ウェアハウスのパフォーマンスを監視します。サーバー側で最近の変更や問題がないか確認します。このステップは Tableau の外部で実行します。
    
    抽出データ ソースの場合、抽出プロセスと最近の更新を確認します。抽出が最適化されていて、データが過度に大きくないことや複雑でないことを確認してください。詳細については、[Web 上での抽出の作成](https://help.tableau.com/current/online/ja-jp/datasource_extract.htm)を参照してください。

## 重要な考慮事項

アクティビティ ログを使用してビューの読み込み時間を監視することは、ダッシュボードのパフォーマンスとユーザー エンゲージメントを最適に維持する優れた方法です。ただし、すべてのダッシュボードまたはビューのレンダリング操作で bootstrap セッション イベントが生成されるわけではありません。bootstrap セッション イベントが不要なシナリオを次に示します。

- **キャッシュされたダッシュボード:** ダッシュボードまたはビューが以前のキャッシュから取得された場合。
- **タブの切り替え:** ユーザーが同じワークブック内でタブを切り替え、新しいタブのコンテンツが読み込まれるかキャッシュされた場合。

`vizql_http_request` イベントタイプを使用して、`bootstrapSession` イベントに注目することで、ビューのパフォーマンスに関する重要なインサイトを獲得し、先を見越して問題に対処することができます。