このガイドでは、Looker ウェブページまたは Looker API リクエストで 404 エラーのトラブルシューティングを行う方法について説明します。通常、404 エラーは、リクエストされたリソースが存在しないか、ユーザーにそのリソースにアクセスする権限がないことを意味します。
デバッグツリー
次の判断基準に沿って、404 エラーのトラブルシューティングを開始します。
以降のセクションでは、ツリー内のシナリオについて詳しく説明します。
ブラウザで 404 エラーが発生した場合のトラブルシューティング
ブラウザのウェブページに 404 エラーが表示される場合は、このセクションの手順に沿って操作します。それ以外の場合は、API エラーのセクションを確認してください。
JavaScript コンソールを確認する
まず、ブラウザの JavaScript コンソールでエラーの詳細を確認します。Google Chrome で JavaScript コンソールを開く手順は次のとおりです。
- その他メニュー をクリックします。
- [その他のツール] を選択します。
- [デベロッパー ツール] をクリックします。
- [コンソール] タブをクリックします。
エラーのリストで 404 エラーを探し、対応する URL を見つけます。
404 を返す URL が Looker URL でない場合、エラーは外部リソースから発生しています。リクエスト URL が Looker に接続するカスタム アプリケーションに属している場合は、アプリケーションのコードとログを調べてエラーのトラブルシューティングを行います。外部リソースの問題に対する Looker のサポートは限定的です。
URL が Looker URL の場合は、次のセクションに進みます。
URL に入力ミスがないか確認する
URL によくある入力ミスがないか確認します。次に例を示します。
- Look ページの一般的なタイプミスは
/look/123です。正しい構文は/looks/123です。 - ダッシュボード ページの一般的なタイプミスは
/dashboard/123です。正しい構文は/dashboards/123です。
LookML に Explore、Look、ダッシュボードへのリンクを含める場合は、必ず最初にリンクをテストして、構文が正しいことを確認してください。
LookML から生成されたリンクに誤字脱字がある場合は、LookML で誤字脱字を修正します。Looker によって生成された URL（UI ナビゲーション要素など）に誤字脱字がある場合は、サポートに連絡して、プロダクトで URL を修正するようリクエストしてください。
API での 404 エラーのトラブルシューティング
エラーが Looker API 呼び出しのレスポンスとして表示される場合は、このセクションの手順に沿って操作します。
API エンドポイントのドキュメントを確認する
404 エラーを返す API エンドポイントのドキュメントを調べます。たとえば、create_sso_embed_url エンドポイントのドキュメント ページは、署名付き埋め込み URL を作成するです。パラメータを確認し、API 呼び出しに正しいパラメータを指定していることを確認します。
リクエストの動詞とパスが正しいことを確認します。たとえば、/api/4.0/embed/sso_url エンドポイントは POST 動詞とともに使用する必要があります。
API Explorer を使用して、インスタンスで API エンドポイントを直接テストすることもできます。
必要なエンドポイント条件を確認する
一部のエンドポイントは、特定の条件でのみ使用できます。
- 一部の LookML プロジェクト エンドポイント（
create_project、deploy_to_production、reset_project_to_productionなど）は、開発モードでのみ使用できます。- 必要に応じて、リクエスト本文
{"workspace_id": "dev"}でupdate_sessionエンドポイントを使用して、API セッションを開発モードに切り替えます。
- 必要に応じて、リクエスト本文
reset_project_to_productionエンドポイントは共有ブランチでは使用できません。deploy_ref_to_productionエンドポイントは、高度なデプロイモードが有効になっている場合にのみ使用できます。
Webhook の設定を確認する
リクエスト URL がデプロイ ウェブフックの場合は、ウェブフックの設定を確認します。
Webhook を使用して特定のブランチまたはリファレンスをデプロイする場合は、プロジェクトで高度なデプロイモードを有効にします。
プロジェクトで Webhook デプロイ シークレットが有効になっている場合は、リクエストにシークレットが含まれていることを確認してください。
リクエストされたリソースが存在するかどうかを確認する
リクエストで参照されているすべてのリソースが Looker インスタンスに実際に存在することを確認します。
リクエストの URL と本文のすべての値（フォルダ ID やダッシュボード ID など）が、有効な既存のリソースを参照していることを確認します。たとえば、ダッシュボードが存在するかどうかを確認するには、管理者ユーザーとして /dashboards/[id] に移動します。リソースがないか無効な場合は、不足しているリソースを作成するか、既存のリソースを指定します。
リソースが存在するのに 404 エラーが返される場合は、リソースが開発モードで存在するかどうかを確認します。Looker ユーザーに develop 権限がある場合は、ユーザーが開発モードに入ったときにリソースにアクセスできるかどうかを確認します。API 呼び出しの場合は、リクエスト本文 {"workspace_id": "dev"} を使用して update_session エンドポイントを使用し、API セッションを開発モードに切り替えます。
ユーザーに develop 権限がない場合は、LookML プロジェクトを本番環境にデプロイしてから、アクセスできるかどうかを確認してください。
ユーザー権限とコンテンツ アクセス設定を確認する
リソースが存在するにもかかわらず、ユーザーに 404 エラーが表示される場合は、ユーザーの権限とコンテンツ アクセスを確認します。
ユーザーを偽装してエラーを確認する
管理者の場合は、[管理] > [ユーザー] パネルに移動し、404 エラーが発生しているユーザーを偽装（sudo）します。
- ユーザーが埋め込みユーザーの場合は、[管理] > [ユーザー] ページの埋め込み認証情報が、埋め込みログイン URL の
external_user_idと一致していることを確認します。 - ユーザーが API 呼び出しを行っている場合は、
login_userエンドポイントを使用してユーザーを偽装します。
ユーザーを偽装しているときに 404 エラーが表示され、管理者がリソースを表示しているときには表示されない場合は、ユーザーの権限またはコンテンツ アクセス設定が不十分である可能性があります。
必要な権限を確認する
[管理] > [ユーザー] パネルでユーザーのロールを確認し、Looker の権限のリストで、ユーザーのロールの少なくとも 1 つに必要な権限が付与されていることを確認します。たとえば、ダッシュボードを表示するには、少なくとも access data、see_looks、see_user_dashboards の権限が必要です。ユーザーに必要な権限がない場合は、そのユーザーに割り当てられているロールの権限セットに権限を追加します。
必要な権限がモデル固有の場合は、必要な権限を持つユーザーのロールの少なくとも 1 つのモデルセットに LookML モデルが含まれていることを確認します。そうでない場合は、ユーザーに割り当てられているロールのいずれかのモデルセットにモデルを追加します。
有効な埋め込み権限を確認する
ユーザーが署名付き埋め込みユーザーの場合は、必要な権限が有効な埋め込み権限かどうかを確認します。そうでない場合、埋め込みユーザーはリクエストを正常に実行できません。たとえば、埋め込みユーザーに see_lookml 権限を割り当てることはできません。
アクセス権限を確認する
コンテンツが required_access_grants が定義された Explore に基づいている場合は、LookML プロジェクトで access_grant の定義を確認します。指定されたユーザー属性のユーザーのユーザー属性値を、アクセス許可で必要な値のいずれかに編集します。
コンテンツ アクセスを確認する
リクエストされたリソースがフォルダに保存されている場合は、そのフォルダのコンテンツ アクセス設定を確認します。Look、ダッシュボード、Looker Studio レポートはすべてフォルダに保存されます。
最終レビューとサポート
404 エラーが引き続き発生する場合は、このページのトラブルシューティングの手順を確認してください。それでも 404 エラーが解決しない場合は、サポートにお問い合わせください。