リクエストログ

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

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

同じログは Console の Analytics → Logs からも取得・確認できます。対話的なトラブルシューティングには Console、プログラムによる取得やエクスポートには API を利用してください。

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

クエリパラメータ

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

レスポンス

{
  "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-18 12:34:55.654321+00",
  "next_after_id": "..."
}

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

cached_tokens は input_tokens のうち、割引されたキャッシュ入力単価で課金された部分（繰り返しのプロンプトプレフィックス）です。キャッシュヒットがない場合は 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 として渡します。同一ミリ秒のリクエストが複数あり得るため、after のみのページングは安全ではありません。

認証

API キー、または JWT + X-Org-ID。認証を参照。

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

GET /logs/{id}

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

{
  "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 を返します。

保存された内容の削除

DELETE /logs

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

内容ログ

リクエスト／レスポンス本文の取得は**オプトイン（既定オフ）**です。メタデータ（上記の一覧）は常に記録されますが、内容（実際のプロンプトとレスポンス）は内容ログがオンの間のみ保存されます。

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

GET は { "log_content_enabled": <bool>, "available": <bool> } を返し、PATCH の結果を即時に反映します。available が false の場合、内容取得のコントロールを非表示にしてください。削除機能は引き続き利用できます。PATCH（組織管理者のみ）は、利用可能な場合にログ取得を切り替えます。

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