# リクエストログ

Source: https://aiand-docs-staging.pages.dev/ja/analytics/logs/

```http
GET /logs?range=<range>&after=<ts>&after_id=<id>&errors=<bool>&limit=<n>
```

組織のリクエストログを新しい順に取得します。

同じログは [Console](https://console.aiand.com/analytics?tab=logs) の **Analytics → Logs**
からも取得・確認できます。対話的なトラブルシューティングには Console、プログラムによる取得やエクスポートには API
を利用してください。

ターミナルからは [ai& CLI](/ja/cli/) で同じログを確認できます。`aiand logs --range 1h --errors`
で最近失敗したリクエストを、`aiand logs --follow` で新しいリクエストを追跡して表示します。

## クエリパラメータ

| パラメータ       | 型      | 必須 | 説明                                                                                            |
| ---------------- | ------- | ---- | ----------------------------------------------------------------------------------------------- |
| `range`          | string  | 任意 | `15m`、`1h`、`6h`、`24h`、`7days`、`30days`。デフォルト `24h`。                                 |
| `after`          | string  | 任意 | ページングカーソル — 前ページの `next_after`。`after_id` と併せて指定します。                   |
| `after_id`       | string  | 任意 | ページングカーソル — 前ページの `next_after_id`。`after` と併せて指定します。                   |
| `errors`         | boolean | 任意 | `true` で非 2xx のみ。                                                                          |
| `endpoint`       | string  | 任意 | この `/v1` パスへのリクエストのみ（例: `/v1/responses`）。                                      |
| `content_logged` | boolean | 任意 | `true` の場合、取得が試みられたリクエストのみ（下記参照）。ページは `request_at` 順になります。 |
| `limit`          | integer | 任意 | ページサイズ。最大 100。デフォルト 50。                                                         |

## レスポンス

```json
{
  "data": [
    {
      "id": "...",
      "model": "...",
      "api_key": "sk-...abcd",
      "status_code": 200,
      "ttft_ms": 210,
      "latency_ms": 420,
      "input_tokens": 123,
      "output_tokens": 45,
      "cached_tokens": 64,
      "cost": "0.00420000",
      "currency": "usd",
      "created_at": "2026-05-18 12:34:56.123456+00",
      "request_at": "2026-05-18 12:34:55.901234+00",
      "endpoint": "/v1/chat/completions",
      "content_logged": true
    }
  ],
  "has_more": true,
  "next_after": "2026-05-18T12:34:55.654321Z",
  "next_after_id": "..."
}
```

`cost` は `currency`（組織の請求通貨、`usd` または `jpy`）建てで、USD 固定値ではありません。`has_more` が `false` の場合、指定範囲の終端に到達しています。

`ttft_ms` は最初のトークンまでの時間です。ストリーミングのリクエストを受信してから、最初に受信する生成出力（テキスト、推論、ツール呼び出しのいずれか）までのミリ秒数を表します。冒頭のロール通知のようにメタデータだけを含むチャンクは数えません。エンドポイントが送信しない出力も数えません。たとえば `thinking` を指定しない `/v1/messages` の推論です。ストリーミングでないリクエストと、出力の前に終了したストリームでは `null` になります。

`cached_tokens` は `input_tokens` のうち、割引された[キャッシュ入力単価](/ja/models/pricing/#プロンプトキャッシュ)で課金された部分です。キャッシュヒットがない場合は `0`、キャッシュ単価を持たないモデルでは `null` になります。

`request_at` はリクエストを受信した時刻、`created_at` はその少し後に行が確定した時刻です。一覧の並び順とページングは `created_at` 基準ですが、`content_logged=true` の場合は `request_at` 基準になります。`next_after` には常に対応する値が入るため、そのまま渡してください。`endpoint` は `/v1` のパス、`content_logged` は本文の取得が試みられたかどうかを示すもので、保存が必ず成功したことを保証するものではありません。まれに欠落する場合は詳細レスポンスで `unavailable` として現れ、`content_logged: false` にはなりません（[内容ログ](#内容ログ)を参照）。

## ページング

前ページの `next_after` と `next_after_id` を `after` と `after_id` として渡し、`has_more` が `false` になったら終了します。両方送ってください。`after_id` は同じタイムスタンプの行の同点を解消するので、どちらか一方のみの場合は、不足しているパラメータを示す `400 invalid_request_error` が返ります。

`next_after` は不透明なカーソルであり、RFC 3339 のタイムスタンプではありません。値は解析せず、そのまま渡してください。

## 認証

API キー、または JWT + `X-Org-ID`。[認証](/ja/authentication/) を参照。

<Aside type="note">
  リクエストログのメタデータは 365 日間保存されますが、このエンドポイントが一覧できるのは直近 30 日までです。すでに 30 日を過ぎた行は、この一覧から後で取り出せません。30 日より短い間隔で書き出しておけば、一覧に残っている行を残せます。
</Aside>

## 単一リクエストの取得（内容付き）

```http
GET /logs/{id}
```

組織で内容ログが有効な場合、1 件のリクエストのメタデータに加えて、取得された**内容**（リクエスト本文とレスポンス）を返します（[内容ログ](#内容ログ)を参照）。`id` は一覧から、または全 `/v1` レスポンスで返る `X-Request-ID` ヘッダーから取得できます。

```json
{
  "id": "...",
  "state": "ready",
  "metadata": {
    "model": "...",
    "endpoint": "/v1/chat/completions",
    "api_key": "sk-...abcd",
    "status_code": 200,
    "input_tokens": 123,
    "output_tokens": 45,
    "cost": "0.00420000",
    "currency": "usd",
    "request_at": "2026-05-18 12:34:56.123456+00",
    "created_at": "2026-05-18 12:34:58.000000+00"
  },
  "content": {
    "endpoint": "/v1/chat/completions",
    "streamed": false,
    "capturedAt": "2026-05-18T12:34:56.123Z",
    "responseId": "chatcmpl_...",
    "request": "{ ...送信したリクエスト... }",
    "response": "{ ...レスポンス... }",
    "error": null,
    "truncated": false
  }
}
```

`request` と `response` は**テキスト**として保存されます（非ストリームは JSON 文字列、ストリームは取得された SSE イベントストリーム）。クライアント側でパースしてください。保存値はエンドポイント固有の形式（たとえば `/v1/messages` では Anthropic 形式）を維持しますが、安全に保存するための処理が加わるため、元の通信内容とバイト単位で完全に同一であるとは限りません。インラインメディアのプレースホルダ化とサイズ超過時の切り詰めについては、以下で説明します。

ストリーミングレスポンスでは、保存用コピーの `data:` イベントに含まれる JSON ペイロードだけがインラインメディア置換の対象になります。SSE のフレーミングとメディアを含まないイベントは元の形式のまま解析可能であり、クライアントへ配信されるライブストリームがリクエストログ機能によって変更されることはありません。

原則として、保存されるログ 1 件あたり、リクエスト、レスポンス、付随するメタデータを合わせて **10 MiB（約 10 MB）** が上限です。上限を超える内容は拒否されるのではなく切り詰められ、`truncated` が `true` になり、保存されたテキストには切り詰めを示すマーカーが含まれます。インラインの base64 メディアは、サイズ上限を適用する前に `omitted:<media-type>;bytes=<n>` プレースホルダへ置き換えられます。

失敗したリクエストでは、`response` は返却されたエラー本文、`error` にはその `message` と `status`（上流のステータスがあればそれ、なければ返却されたステータス）が入ります。上流の本文そのものは保存されません。

クライアント指定のリクエスト ID は `[A-Za-z0-9._:@=+-]{1,36}` に一致する必要があります。独自の `X-Request-ID` がこの形式に合わない場合、サービスは生成した ID に置き換えます。メタデータと内容の取得には、レスポンスで返された `X-Request-ID` を使用してください。

### `state`

`content` は存在しない場合があります。`state` がその理由を示すため、id が不明な場合を除きエラーにはなりません。

| State         | 意味                                       |
| ------------- | ------------------------------------------ |
| `ready`       | メタデータと内容の両方が存在。             |
| `processing`  | リクエスト完了直後で、メタデータが確定中。 |
| `not_logged`  | このリクエストでは内容ログがオフだった。   |
| `expired`     | 30 日を超過し、内容は削除済み。            |
| `unavailable` | 内容が想定されるが見つからない。           |

メタデータと内容のどちらも存在しない場合のみ `404` を返します。

## 保存された内容のエクスポート

```http
GET /logs/export
```

組織管理者のみ。指定した期間に内容ログが取得されたリクエストの本文を、gzip 圧縮した [JSON Lines](https://jsonlines.org/) ファイル `request-logs.jsonl.gz` 1 つとして新しい順にダウンロードします。1 行が 1 件のリクエストで、各行は[単一リクエストの取得](#単一リクエストの取得内容付き)の `content` と同じ形です。一覧と同じ `range`・`errors`・`endpoint` パラメータを受け付け、既定値も同じ `24h` です。

1 ファイルに含まれるのは、期間内の新しいものから最大 5,000 件です。それより古いリクエストは、`content_logged=true` を付けて一覧を[ページング](#ページング)し、1 件ずつ取得してください。内容がすでに削除されたリクエストはファイルに含まれません。

管理者が組織を[ゼロデータリテンション](/ja/organizations/zero-data-retention/)に切り替えるとき、Console からこのエクスポートを利用できます。

## 保存された内容の削除

```http
DELETE /logs
```

組織管理者のみ。組織のすべてのリクエスト／レスポンス本文の削除を開始し、`202 { "accepted": true }` を返します。削除は数分以内にバックグラウンドで完了します。メタデータ行は残り、対象のリクエストは以後 `unavailable` として開きます。削除はログ取得のスイッチを変更しません。スイッチが ON のままなら、削除後のリクエストは再び保存されます。先にスイッチを OFF にしても、切り替え後最長 1 分ほど取得が続くことがあるため、完全な区切りにはなりません（[内容ログ](#内容ログ)を参照）。

## 内容ログ

リクエスト／レスポンス本文の取得は**オプトイン（既定オフ）**です。メタデータ（上記の一覧）は常に記録されますが、リクエストログに**内容**（実際のプロンプトとレスポンス）が保存されるのは内容ログがオンの間のみです。インライン PDF や動画ジョブなど、内容ログの設定にかかわらず内容を保存する機能もあります。一覧は[ゼロデータリテンション](/ja/organizations/zero-data-retention/)を参照してください。

```http
GET   /logs/settings
PATCH /logs/settings   { "log_content_enabled": true }
```

`GET` は `{ "log_content_enabled": <bool>, "available": <bool>, "data_retention": "standard" | "zero" }` を返し、`PATCH` の結果を即時に反映します。`available` が `false` の場合、内容取得のコントロールを非表示にしてください。削除機能は引き続き利用できます。`PATCH`（組織管理者のみ）は、利用可能な場合にログ取得を切り替えます。[ゼロデータリテンション](/ja/organizations/zero-data-retention/)の組織は `"data_retention": "zero"` を返し、ログ取得が利用可能な環境では、ログ取得をオンにする `PATCH` は `403 zero_data_retention` を返します。

組織管理者は、[Console](https://console.aiand.com/settings/organizations) の **Settings →
Organizations → Request Logging** からも内容ログをオン／オフできます。このスイッチは、現在の環境で内容保存が利用可能な場合にのみ表示されます。利用できない場合でも、Console
から保存済みの内容を削除できます。

<Aside type="caution">
  変更が実際の取得に反映されるまで、最大約 1 分（認証キャッシュ TTL の 2
  倍）かかることがあります。内容ログをオフにしても既存の内容は削除されません。削除するには `DELETE
  /logs` を使うか、30
  日後の失効を待ってください。本文はリージョン内に保存され、内部ログには一切書き込まれません。
</Aside>
