> ## 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 CLI リファレンス：コマンドとフィルター

> LogBrew のコマンド、フィルター、カーソルベースのページネーション、ライブ監視、JSON 出力、エラーを確認します。

[オープンソースの LogBrew CLI](https://github.com/LogBrewCo/cli) は、ターミナルからテレメトリを読み取り、アカウントのデータを管理します。インストール、ログイン、よくある作業については、まず [CLI を使う](/ja/guides/cli)を読んでください。

## CLI の仕組み

ターミナルでは読みやすいテキストを使います。スクリプトやコーディングエージェントでは `--json` を使います。

アカウントの読み取りには、アカウントでのログインが必要です。ログインを始める前に `logbrew status --json` を実行します。ブラウザーでの認可は人が完了する必要があります。プロジェクトの取り込みキーはテレメトリを送信します。アカウントでのログインの代わりにはなりません。

プロジェクトの作成、キーの作成、課題のステータス・優先度・担当者の変更、デプロイ、サポートの更新は、アカウントのデータを変更します。これらを実行する前に、操作と対象が正しいことを確認してください。

すべてのコマンドを表示するには `logbrew --help` を実行します。`logbrew read logs --help` のようにコマンドに `--help` を付けると、そのフラグを表示できます。JSON のルールを確認するには `logbrew help json` を実行します。

| コマンドの系統 | 用途 |
| - | - |
| `login`、`whoami`、`me`、`logout` | ログインを始める、アカウントの識別情報を読む、ローカルのセッションを閉じる。 |
| `status`、`health`、`doctor`、`version`、`examples` | アクセス、プロジェクトの準備状況、CLI のバージョン、初回実行用の例を読む。 |
| `setup` | ローカルのマニフェストを読み、SDK の設定計画を出力する。ファイルの変更やインストールコマンドの実行は行いません。 |
| `projects` | 有効なプロジェクトの一覧を読む。 |
| `projects repositories` | 接続済みのリポジトリを読む、または1つのリポジトリのコンポーネントを見つける。 |
| `projects create`、`projects keys create` | プロジェクトを作成する、または既存のプロジェクトに取り込みキーを作成する。 |
| `projects setup` | 既存のプロジェクトについて、確認した設定を記録する。 |
| `projects archive`、`projects delete` | プロジェクトをアーカイブする、または確認の後に完全に削除する。 |
| `usage`、`account usage` | 使用量、上限、クォータの状態、リセット日を読む。 |
| `mcp grants`、`mcp revoke` | アカウントに接続した MCP クライアントを名前付きで一覧表示する、または1つの接続を無効化する。 |
| `read` | ログ、課題、アクション、リリース、メトリクス、トレース、または1つの項目を読む。 |
| `explain` | 課題、ログ、アクション、トレース、スパン、メトリクス、リリースについて、範囲を絞った証拠を読む。 |
| `investigate issue` | 課題の調査の証拠を読む、または候補のデプロイを検証する。 |
| `issues archive`、`issues resolve`、`issues reopen` | 1件の課題、または1つのプロジェクトの最大100件の課題のステータスを設定する。 |
| `issues priority` | 1件の課題、または1つのプロジェクトの最大100件の課題の優先度を設定する。 |
| `issues assign`、`issues unassign` | 1件の課題、または1つのプロジェクトの最大100件の課題について、担当者（アカウントまたはチーム）を設定または解除する。 |
| `issues assignees` | 1つのプロジェクトで課題を割り当てられるアカウントとチームを一覧表示する。 |
| `issues owners` | 1件の課題のオーナー候補を一覧表示する。 |
| `issues ownership` | 1つのプロジェクトのオーナーシップルールと CODEOWNERS ファイルを読む、または設定する。 |
| `issues activity` | 1件の課題の変更履歴を読む。 |
| `issues rule`、`logs rule` | 1件の課題、または1つのログシグネチャの重大度のルールを設定する。 |
| `inbox` | ほかの人があなたやあなたのチームに割り当てた課題を読む、または既読にする。 |
| `set issue`、`resolve`、`close`、`ignore`、`reopen` | 1件の課題のステータスを設定する。`close` は `resolved` を意味します。`ignore` と `ignored` は `archived` を意味します。 |
| `deploy` | 完了した1件のデプロイを記録する。 |
| `debug-artifacts` | Apple または Android のネイティブのデバッグファイルをアップロードする、または1つのイメージの識別情報を調べる。 |
| `analytics` | 概要、プロパティ、比較、パス、ファネル、再訪、ライフサイクルを読む。 |
| `support` | サポートチケットを作成、読み取り、返信、クローズ、再開する。 |
| `watch` | ライブのログ、課題、アクションをストリーミングする。 |

## <span id="read-a-project-doctor-report">プロジェクトの doctor レポートを読む</span>

`logbrew projects --json` で得たプロジェクト ID を使います。

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

このコマンドは、プロジェクトの状態と最近のログ1件を読みます。プロジェクトの作成、キーの変更、設定の記録は行いません。

レポートには `status`、`checks`、`next` があります。各チェックには `check`、`status`、`next` があります。チェックは `api`、`auth`、`project`、`ingest_key`、`setup`、`telemetry`、`logs` です。

終了コード `0` は、CLI がレポートを書き出したことを示します。プロジェクトの準備ができているという意味ではありません。レポートの `status` と各チェックを読んでください。`not_checked` のチェックは合格していません。

| レポートの `status` | 意味と次のステップ |
| - | - |
| `auth_invalid` | アカウントのアクセスがないか、無効です。人が `logbrew login` を実行します。 |
| `project_missing` | このアカウントはプロジェクトにアクセスできません。`logbrew projects --json` で得た ID を使います。 |
| `api_unreachable` | API リクエストが完了しませんでした。ネットワーク接続を確認してから、コマンドをもう一度実行します。 |
| `check_failed` | リクエストが失敗したか、レスポンスが無効でした。変更せずにコマンドをもう一度実行します。再び失敗する場合は、[問題を報告](/ja/guides/report-a-problem)してください。 |
| `needs_ingest_key` | プロジェクトに有効な取り込みキーがありません。キーは、プロジェクトを変更する許可がある場合だけ作成します。 |
| `needs_setup` | SDK の設定が必要です。[クイックスタート](/ja/quickstart)の手順に従います。 |
| `needs_telemetry` | 設定は始まっていますが、LogBrew にこのプロジェクトのテレメトリがありません。テストイベントを送信します。 |
| `ready` | プロジェクトに有効なキーとテレメトリがあります。作業に必要なシグナルを読みます。 |

プロジェクトの読み取りが成功すると、`logs` のチェックは `visible`、`empty`、`unavailable`、`error`、`invalid_response` のいずれかになります。このチェックでレポートの `status` は変わりません。ログの結果が空でも、ほかのシグナルについては何もわかりません。読み取りの失敗は、空の結果とは違います。

`next` は回復のための案内として使います。アカウントやプロジェクトの状態を変更する許可を与えるものではありません。

### 例：アカウントのアクセスがない場合

アカウントの認証情報がない場合、このコマンドは API リクエストを送りません。次のレポートを標準出力に書き出し、終了コード `0` で終わります。

```json theme={null}
{
  "checks": [
    { "check": "api", "next": "run the API reachability check first", "status": "not_checked" },
    { "check": "auth", "next": "run logbrew login", "status": "missing" },
    { "check": "project", "next": "resolve the prior check first", "status": "not_checked" },
    { "check": "ingest_key", "next": "resolve the prior check first", "status": "not_checked" },
    { "check": "setup", "next": "resolve the prior check first", "status": "not_checked" },
    { "check": "telemetry", "next": "resolve the prior check first", "status": "not_checked" },
    { "check": "logs", "next": "resolve the prior check first", "status": "not_checked" }
  ],
  "next": "run logbrew login",
  "status": "auth_invalid"
}
```

このレポートは、[プロジェクト API の診断](/ja/concepts/projects#diagnose-project-setup)とは別のものです。API のフィールド `state`、`setup_status`、`next_action` は含まれません。

## <span id="filters">フィルター</span>

| フィルター | コマンド |
| - | - |
| `--project <project_id>` | logs、issues、actions、releases、metrics、traces、trace |
| `--release <release>` | logs、issues、actions、releases、metrics、traces、trace |
| `--environment <environment>` | logs、issues、actions、releases、metrics、traces、trace |
| `--service <service_name>` | logs、issues、actions、releases、metrics、traces |
| `--since 24h` | logs、issues、actions、releases、metrics、traces、analytics |
| `--until <RFC3339>` | logs、issues、actions、releases、metrics、traces、analytics |
| `--limit 100` | logs、issues、actions、releases、metrics、traces |
| `--severity error` | logs、watch |
| `--search checkout` | logs |
| `--trace <trace_id>` | logs |
| `--status unresolved` | issues（`unresolved`、`resolved`、`archived`） |
| `--priority high` | issues（`high`、`medium`、`low`） |
| `--assignee me` | issues（`me`、`none`、`my_teams`、ユーザー ID、または `team:<team_id>`） |
| `--status error` | traces（`error`、`ok`） |
| `--min-duration-ms <milliseconds>` | traces |
| `--name <name>` | actions、metrics |
| `--user <distinct_id>` | actions |

`--since` には、`24h` や `7d` のような期間、または RFC 3339 タイムスタンプを指定できます。`--until` には RFC 3339 タイムスタンプを指定できます。これは終了時刻で、その時刻自体は含まれず、`--since` より後である必要があります。ID で1件の課題を読む場合は、`--until` を指定できません。

ログの重大度は `info`、`warning`、`error`、`critical` のいずれかです。課題のステータスは課題のワークフロー上の状態で、重大度ではありません。`--status ignored` は `--status archived` の古い名前です。`--status open` は `unresolved` を、`--status closed` は `resolved` を意味します。`--assignee none` は担当者のいない課題を、`--assignee my_teams` は自分のチームの課題を選びます。`--assignee` にそれ以外の値を指定すると、`invalid_assignee` で失敗します。

CLI は次の別名も受け付けます：`--project-id`、`--env`、`--service-name`、`--trace-id`、`--distinct-id`、そして `--severity` の別名の `--level`。新しいスクリプトでは、表にある名前を使ってください。

次のコマンドは、1日分のエラーを読みます。

```bash theme={null}
logbrew read logs --severity error \
  --since 2026-10-01T00:00:00Z --until 2026-10-02T00:00:00Z --json
```

プロジェクト ID でプロジェクトを選びます。サービス名で、そのプロジェクト内のコンポーネントを選びます。空白を含む値は引用符で囲みます。

```bash theme={null}
logbrew read logs --project "<project_id>" \
  --service checkout-api --since 24h \
  --severity error --search "checkout failed" --json
```

ハイフンで始まる検索テキストには、テキストの前に `--` を置きます。

```bash theme={null}
logbrew logs --json -- --timeout
```

## 課題の発生事象を選ぶ

課題は、一致する発生事象をグループ化したものです。ステータス、発生事象の件数、初回確認と最終確認の時刻を知るには、課題を読みます。

```bash theme={null}
logbrew read issue "<issue_id>" --json
```

1件の発生事象の証拠を読むには、`explain issue` または `investigate issue` を使います。`--occurrence` を指定しないと、LogBrew は推奨する発生事象を選びます。これは最新のイベントとは限りません。最新のイベントを読むには次のようにします。

```bash theme={null}
logbrew explain issue "<issue_id>" --occurrence latest --json
```

`--occurrence` には、`recommended`、`first`、または LogBrew が返した発生事象の ID も指定できます。これらのコマンドは、プロジェクト、リリース、環境、時刻のフィルターを受け付けません。証拠を比べる前に、選んだ発生事象のタイムスタンプを読みます。証拠のフィールドについては [課題を調査する](/ja/guides/investigate-an-issue)を参照してください。

## <span id="change-issue-status-and-priority">課題のステータスと優先度を変更する</span>

1件の課題を変更するには、課題 ID を1つ使います。

```bash theme={null}
logbrew issues archive "<issue_id>" --json
logbrew issues priority high "<issue_id>" --json
```

`archive` は `archived` を、`resolve` は `resolved` を、`reopen` は `unresolved` を設定します。優先度は `high`、`medium`、`low` のいずれかです。設定した優先度は固定されます。設定しない場合、優先度は課題の重大度に従います。

2件以上の課題を変更するには、`--project` を追加します。すべての課題がそのプロジェクトにある必要があります。1回のコマンドで最大100件の課題を変更できます。

```bash theme={null}
logbrew issues resolve "<issue_id_1>" "<issue_id_2>" \
  --project "<project_id>" --json
```

結果には、課題ごとに1つの項目があります。各項目は `updated`、`unchanged`、`not_found` のいずれかです。`unchanged` の課題は、すでに指定した値になっていました。ネットワークの障害の後は、同じコマンドをもう一度実行できます。

これらのコマンドは確認を求めません。先に課題 ID を確認してください。課題の読み取りと変更では、`ignored` ではなく `archived` が表示され、各課題の `priority`、`priority_source`、`assignee` も表示されます。[課題のレスポンス](/ja/reference/telemetry-response-shapes#issue-response)を参照してください。

## 課題を割り当てる

担当者は課題ごとに最大1つで、1つのアカウントか1つのチームです。プロジェクトで割り当てられるアカウントとチームを一覧表示します。

```bash theme={null}
logbrew issues assignees --project "<project_id>" --json
```

1件の課題を、アカウント、自分（`me`）、またはチームに割り当てます。

```bash theme={null}
logbrew issues assign "<user_id>" "<issue_id>" --json
logbrew issues assign me "<issue_id>" --json
logbrew issues assign "team:<team_id>" "<issue_id>" --json
```

担当者を解除します。

```bash theme={null}
logbrew issues unassign "<issue_id>" --json
```

ステータスや優先度と同じく、`--project` を追加すると、そのプロジェクトの最大100件の課題を変更できます。アカウントはそのプロジェクトを読み取れる必要があり、チームはそのプロジェクトの組織に属している必要があります。自分または自分のチームに割り当てられた課題を探すには次のようにします。

```bash theme={null}
logbrew read issues --project "<project_id>" --assignee my_teams \
  --status unresolved --json
```

テキスト出力には担当者の名前が表示されます。チームの場合は `team #<slug>` と表示されます。アカウントに名前がない場合はメールアドレスが、それもない場合はユーザー ID が表示されます。担当者のいない課題には `unassigned` と表示されます。

## <span id="owners-history-and-the-inbox">オーナー、変更履歴、受信トレイ</span>

```bash theme={null}
logbrew issues owners "<issue_id>" --json
logbrew issues ownership --project "<project_id>" --json
logbrew issues ownership set --project "<project_id>" \
  --rules ownership.txt --codeowners .github/CODEOWNERS --json
logbrew issues activity "<issue_id>" --limit 50 --json
logbrew inbox --json
logbrew inbox read --json
```

`issues owners` は、オーナー候補と、照合に使った証拠を一覧表示します。`issues ownership set` は、それぞれ 128 KiB 以下のローカルファイルを送信します。空のファイルを送ると、そのテキストは消去されます。`issues activity` と `inbox` では、`--limit` に 1〜200 を指定でき、`next_cursor` の値を `--cursor-time` と `--cursor-id` で渡せます。詳しくは [課題のオーナーを確認する](/ja/guides/issue-workflow#find-who-owns-an-issue)を参照してください。

## <span id="set-severity-rules">重大度のルールを設定する</span>

```bash theme={null}
logbrew issues rule "<issue_id>" warning --json
logbrew logs rule "<log_id>" info --ignore --json
```

重大度は `info`、`warning`、`error`、`critical`、`source` のいずれかです。`source` を指定すると、取得した重大度が再び表示されます。`--ignore` を付けると、一致するログがデフォルトのログの一覧に表示されなくなります。`--ignore` を付けない場合、ルールは一致するログを表示します。

## <span id="read-the-next-page">次のページを読む</span>

ログ、課題、アクション、メトリクス、トレースは、カーソルベースのページネーションに対応しています。リリースは対応していません。最初のページでは `--pagination cursor` を使います。

```bash theme={null}
logbrew read logs --project "<project_id>" --since 24h \
  --pagination cursor --limit 100 --json
```

レスポンスには `logs` と `next_cursor` があります。`next_cursor` が null でない場合は、`time` と `id` を持ちます。これらを `--cursor-time` と `--cursor-id` で送信します。

```bash theme={null}
logbrew read logs --project "<project_id>" --since 24h \
  --pagination cursor --limit 100 \
  --cursor-time "<returned_time>" \
  --cursor-id "<returned_id>" --json
```

どのページでも、フィルターと件数の上限は同じものを使います。`next_cursor` が `null` になったら止めます。次のページがあるかどうかは、行数ではなくカーソルで判断します。最後のページは空のことがあります。

```json theme={null}
{
  "logs": [],
  "next_cursor": null
}
```

課題、アクション、メトリクスも同じ形式で、`logs` の代わりに `issues`、`actions`、`metrics` を使います。

## <span id="live-watch">ライブ監視</span>

`logbrew watch --json` は、ライブのログ、課題、アクションをストリーミングします。1つの種類だけをストリーミングするには、`logs`、`issues`、`actions` を追加します。`tail`、`follow`、`stream` は `watch` の別名です。watch はトレースやスパンに対応していません。

watch には `--json` が必要です。付けないと、コマンドは `watch streams JSON for agents` と書き出し、終了コード `1` で終わります。

watch の課題イベントでは、アーカイブ済みの課題が優先度なしの `ignored` として表示されます。現在のステータスと優先度を知るには、課題を読みます。

watch が受け付けるのは `--severity` だけです。たとえば `--severity error,critical` のように指定します。`logbrew watch actions` は `--severity` を受け付けません。CLI はイベントを受け取った後にこのフィルターを適用します。サーバーが送信する量は減りません。watch には、プロジェクト、リリース、環境、時刻のフィルターがありません。これらのフィルターを使うには `read` コマンドを使います。一時的に切断された場合、CLI は待ってから再接続します。

## <span id="read-results-and-errors">結果とエラーを読む</span>

`--json` はコマンドの前後どちらにも置けます。出力を使う前に終了コードを読みます。人が読むための出力は解析しないでください。バージョンによって変わることがあります。

| 終了コード | 意味 |
| - | - |
| `0` | 成功。JSON は標準出力にあります。 |
| `1` | 実行中にコマンドが失敗しました。たとえば API やネットワークのエラーです。 |
| `2` | 実行前に CLI がコマンドを拒否しました。 |

成功時の出力は、API のレスポンスの形式を保ちます。配列の場合もオブジェクトの場合もあります。カーソルベースのページネーションを使わない場合、ログの読み取りは配列を返します。空の配列は、一致するログがないことを意味します。エラーではありません。

エラーは標準エラー出力に書き出されます。例外は `debug-artifacts --json` で、エラーを標準出力に書き出します。JSON のエラーには `ok`、`error`、`message`、`next` があります。安定した失敗コードとして `error` を使います。`next` が示すコマンドを実行する前に、その内容を確認してください。

たとえば、`logbrew watch traces --json` は終了コード `2` で終わり、次のように書き出します。

```json theme={null}
{
  "ok": false,
  "error": "unknown_resource",
  "message": "unknown resource: traces",
  "next": "use logbrew traces for recent traces, or logbrew trace <trace_id> for one trace"
}
```

`logbrew read logs --limit 0 --json` は終了コード `2` で終わり、次のように書き出します。

```json theme={null}
{
  "ok": false,
  "error": "invalid_limit",
  "message": "invalid limit: 0",
  "next": "use --limit with a positive whole number"
}
```

値を直して、コマンドをもう一度実行します。拒否されたコマンドは、空の結果とは違います。HTTP のエラーについては [API エラー](/ja/reference/api-errors)を、API を直接呼び出すリクエストについては [テレメトリ API](/ja/reference/telemetry-api)を参照してください。


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