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

# アプリケーションログが見つからないときのトラブルシューティング

> 安全な LogBrew の確認手順で、見つからないアプリケーションログ、プロジェクトの設定、フィルター、課題の証拠、トレースのリンクを調べます。

テレメトリが見つからない、不完全、または範囲が広すぎるときに、このページを使います。まずアクセスを確認します。原因を探す間は、プロジェクト、サービス、リリース、環境、期間を固定します。

<Note>
  エージェントのワークフローでは `--json` を追加します。確認が失敗すると、安定した `next` フィールドが返されます。
</Note>

## 簡単な確認から始める

| 症状 | 最初の確認 | 次のステップ |
| - | - | - |
| CLI でサインインしていない | `logbrew status --json` | 人が `logbrew login` を実行します。 |
| プロジェクトが見つからない | `logbrew projects --json` | プロジェクトの一覧にある ID を使います。 |
| 設定の状態がはっきりしない | `logbrew doctor --project "<project_id>" --json` | 返された `next` の値に従います。 |
| ログが空 | 正確なプロジェクトと期間でログを読む | ほかのシグナルの種類は別に確認します。 |
| 結果の範囲が広すぎる | プロジェクト、サービス、リリース、環境のフィルターを追加する | 読み取りのたびに同じスコープを保ちます。 |
| トレースが見つからない | 課題の詳細を読む | レスポンスにトレース ID がある場合だけトレースを読みます。 |
| JavaScript のフレームにビルド後のコードが表示される | ビルドとソースマップの組み合わせを確認する | [JavaScript ソースマップ](/ja/guides/source-maps)の手順に従います。 |
| MCP のエージェントがプロジェクトを読めない | 承認済みプロジェクトを確認する | [MCP の接続の問題](/ja/guides/mcp#fix-connection-problems)の手順に従います。 |

## <span id="recover-missing-first-telemetry">最初のテレメトリが届かないときに回復する</span>

SDK の設定を変える前に、次の読み取り専用のコマンドを実行します。

```bash theme={null}
logbrew version --json
logbrew status --json
logbrew projects --json
logbrew doctor --project "<project_id>" --json
```

`logbrew doctor` は、API へのアクセス、認証、プロジェクト、取り込みキー、設定、テレメトリ、ログの表示を確認します。プロジェクトは変更しません。全体の `status` と各チェックを、[doctor レポート](/ja/reference/cli#read-a-project-doctor-report)で読みます。終了コードが `0` でも、すべての確認に合格したとは限りません。

| doctor のステータス | 次のステップ |
| - | - |
| `needs_ingest_key` | プロジェクト単位の取り込みキーを作成します。[取り込みキーのローテーション](/ja/guides/rotate-ingest-key)を参照してください。 |
| `needs_setup` | SDK の設定を完了します。[SDK 連携](/ja/guides/sdk-ingestion)を参照してください。 |
| `needs_telemetry` | アプリから安全なテストイベントを1件送信し、もう一度 doctor を実行します。 |
| `ready` | 最近のログ、課題、リリース、トレースを読みます。 |

レポートのステータスは、`auth_invalid`、`project_missing`、`api_unreachable`、`check_failed` になることもあります。それぞれの次のステップは [doctor レポート](/ja/reference/cli#read-a-project-doctor-report)にあります。

シグナルの種類はそれぞれ別なので、`ready` のプロジェクトでもログがないことがあります。`logs` の確認は `empty` または `unavailable` になることがあります。ログの読み取りの失敗は、空の結果とは違います。

### 安全なテストイベントを1件送信する

インストールした SDK から、固有のメッセージを持つテストログを1件送信します。トークン、ユーザーのデータ、リクエストボディは含めないでください。プロジェクト ID、サービス、環境、リリース、UTC の開始時刻、SDK のバージョンを記録します。送信が終わるのを待ってから、同じプロジェクトの短い期間を読みます。送信の保留中に、追加のテストイベントを送信しないでください。

## 見つからないログを探す

まず、狭く正確なスコープで読みます。

```bash theme={null}
logbrew read releases --project "<project_id>" --environment production --json
logbrew read logs --project "<project_id>" --environment production \
  --release checkout@1 --since 1h --limit 20 --json
```

次の項目を順に確認します。

1. プロジェクト ID が、イベントを送信したアプリのものであること。
2. サービス、リリース、環境が、大文字と小文字や空白も含めて正確に一致していること。
3. 期間にイベントの時刻が含まれていること。LogBrew はイベントの時刻を UTC で返します。`--until` の時刻自体は期間に含まれません。
4. 検索や重大度のフィルターでイベントが隠れていないこと。
5. 読んでいるシグナルの種類を、アプリが送信していること。ログから課題やトレースは作られません。

それでもイベントが見つからない場合は、フィルターを1つずつ外します。

1. プロジェクトはそのままにして、期間を広げます。
2. リリースのフィルターを外します。
3. 環境のフィルターを外します。
4. サービスのフィルターを外します。
5. 検索と重大度のフィルターを外します。

イベントが表示されたら止めます。最後に外したフィルターが、アプリの設定と一致していません。設定したプロジェクトの代わりに、すべてのプロジェクトを読まないでください。

| 結果 | わかること | 次の確認 |
| - | - | - |
| 1つのプロジェクトで行が0件 | そのスコープに一致するものがない | 時刻とフィルターを確認します。 |
| ログはあるが課題がない | フィルターに一致する、グループ化されたエラーがない | アプリがエラーを送信したか確認します。 |
| 課題はあるがトレースがない | その発生事象に使えるトレースのリンクがない | 課題の調査でトレースのステータスを読みます。 |
| リリースはあるがログがない | そのリリースにはほかのシグナルがあるが、そのスコープにログはない | `logbrew read releases` の件数を比べます。同じプロジェクトで、シグナルの種類ごとに読みます。 |
| フィルターを外すとイベントが表示される | そのフィルターがイベントを除外していた | フィルターかアプリの値を直します。 |

結果の1ページは合計ではありません。`--pagination cursor` を使う場合は、返された `next_cursor` で続きを読み、フィルターは同じものを使います。[カーソルベースのページネーション](/ja/reference/telemetry-api-filters#cursor-pagination)を参照してください。

### ダッシュボードの表示を確認する

ダッシュボードは、各一覧のスナップショットを表示します。ログの画面で **ライブログ** をオンにすると、新しいログが届くたびに追加されます。ほかの画面はライブでは更新されません。新しいスナップショットを取得するには、ページを再読み込みします。古いスナップショットは、空の結果とは違います。

LogBrew が保存するのは、アプリが送信したテレメトリだけです。認証情報、リクエストボディ、クエリの値、個人データは送信前に取り除いてください。フィールドの選び方は [取得するデータを管理する](/ja/guides/safe-capture)で確認します。

## 課題とトレースを確認する

LogBrew が返した課題 ID またはトレース ID を使います。ID を作り出さないでください。

```bash theme={null}
logbrew read issues --project "<project_id>" --environment production \
  --status unresolved --since 24h --json
logbrew read issue "<issue_id>" --json
logbrew read trace "<trace_id>" --project "<project_id>" --json
logbrew read logs --trace "<trace_id>" --project "<project_id>" --json
```

`--status` には `unresolved`、`resolved`、`archived` を指定できます。`ignored` は `archived` と同じ課題を選びます。

課題のステータスとトレースのステータスは別のものです。トレースのステータスの値 `not_linked`、`not_found`、`unavailable` は、それぞれ意味が異なります。各値については [課題を調査する](/ja/guides/investigate-an-issue)を参照してください。課題を解決、アーカイブ、再開する前に、その課題とログを読みます。

## CLI と API のエラーに対処する

JSON モードでは、CLI のエラーに `ok`、`error`、`message`、`next` が含まれます。

```json theme={null}
{
  "ok": false,
  "error": "not_logged_in",
  "message": "not logged in: run logbrew login",
  "next": "run logbrew login"
}
```

API がエラーを返した場合、`error` は `api_error` になります。エラーには、`status`（HTTP ステータス）、`api_code`（API の `code`）、`api_error`、`api_next` も含まれます。`rate_limited` のエラーには `retry_after_seconds` も含まれます。CLI は自動では再試行しません。

| ステータスまたはエラー | 回復方法 |
| - | - |
| `not_logged_in` または HTTP `401` | 人が `logbrew login` を実行します。その後、読み取りを再試行します。 |
| HTTP `403` | プロジェクトに合った認証情報を使います。課題を変更するには、プロジェクトで課題を管理する権限も必要です。認証情報の値は表示しないでください。 |
| HTTP `404` | レスポンスにある最新のプロジェクト、課題、トレースの ID を使います。 |
| HTTP `422` | 示されたフィールドを直します。 |
| `rate_limited` を伴う HTTP `429` | `retry_after_seconds` だけ待ってから、1回だけ再試行します。 |
| ほかのコードを伴う HTTP `429` | 自動の再試行を止めます。`api_next` に従います。 |
| HTTP `5xx` | 少し待って読み取りを1回再試行し、続くようであれば問題を報告します。 |

各エラーコードについては [API エラー](/ja/reference/api-errors)を参照してください。

## <span id="secure-a-compromised-account">不正利用されたアカウントを保護する</span>

アカウントのアクセストークン、リフレッシュトークン、セッション Cookie をほかの人が持っている可能性がある場合は、すべての LogBrew クライアントからログアウトします。[アカウント全体のログアウト](/ja/reference/account-api#every-logbrew-login)の手順に従ってください。この操作には人の承認が必要です。`logbrew logout` やブラウザーでのログアウトは1つのクライアントしか終了しないため、十分ではありません。

アカウント全体のログアウトは、それより前に承認されたすべての MCP 接続も止めます。成功したら、各クライアントでローカルの LogBrew の認証情報を消去し、信頼できるクライアントからもう一度サインインします。MCP クライアントは、信頼できることを確認してから再び承認します。レスポンスが失われた場合は、すべてのクライアントがログアウトしたと報告せず、リクエストを自動で繰り返さないでください。

アカウント全体のログアウトでは、プロジェクトの取り込みキーはローテーションされません。取り込みキーが漏えいした場合は、[取り込みキーをローテーション](/ja/guides/rotate-ingest-key)してください。

## トラブルシューティングを安全に行う

CLI での読み取りには、アカウントのアクセス用の認証情報を使います。プロジェクト単位の取り込み用の認証情報は、SDK での書き込みにだけ使います。トークン、認可ヘッダー、生のログ、顧客のデータ、リクエストボディ、ローカルのパス、ソースコードを、コマンド、チャット、サポートチケットに含めないでください。

問題を報告する前に、失敗が再現する最も狭いスコープで読み取りを1回繰り返します。認証情報の値を除いたコマンド、エラーコード、プロジェクト ID、フィルターの値を記録します。確認しても問題が解決しない場合は、[問題を報告](/ja/guides/report-a-problem)してください。

## 関連ページ

<CardGroup cols={2}>
  <Card title="クイックスタート" icon="rocket" href="/ja/quickstart">
    最初の安全なイベントを送信して読みます。
  </Card>

  <Card title="CLI を使う" icon="square-terminal" href="/ja/guides/cli">
    正確なフィルターと JSON 出力を使います。
  </Card>

  <Card title="課題を調査する" icon="search" href="/ja/guides/investigate-an-issue">
    ステータスを変える前に、課題の証拠を読みます。
  </Card>

  <Card title="API エラー" icon="triangle-alert" href="/ja/reference/api-errors">
    エラーコードごとに回復します。
  </Card>
</CardGroup>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.