API 概要
Log Query API は、アカウントで行われた すべての API 呼び出し の詳細な記録を返します。 使用したモデル、実際の請求額、レイテンシー、呼び出しがストリーミングされたかどうか、 および呼び出しが失敗したときのエラーコードを含みます。 これは Balance Query API を補完するものです。残高照会では 残っているクレジット量がわかり、ログ照会ではそれがどこに使われたかがわかります。 代表的な 3 つのユースケースは次のとおりです。自動照合
時間範囲別またはモデル別に実際の支出を集計し、自社の課金と突き合わせます
セルフサービスのトラブルシューティング
失敗したリクエストのエラーコードを確認し、パラメータの問題と上流側の問題を切り分けます
サポートチケット
サポートに
request_id を共有すると、正確な呼び出しを特定してもらえますログは、コンソールの Logs ページでも確認できます。この API は同じデータへのプログラムによるエントリーポイントであり、自動照合、定期エクスポート、または独自のモニタリングへの取り込みを目的としています。手動で確認する場合は、コンソールを使用してください — 呼び出し記録の確認方法 をご覧ください。
System Token の取得方法
Log Query API は System Token で認証します。これは API key とは別物です(このページ末尾の重要な注意事項を参照してください)。1
コンソールにアクセス
api.apiyi.com/account/profile にアクセスしてプロフィールページを開いてください2
System Token を見つける
ページ下部の「Account Options - System Token」セクションを見つけてください
3
AccessToken を生成
アカウントのパスワードを入力すると、後続の API クエリに使用できる AccessToken を取得できます

API情報
リクエスト詳細
リクエストヘッダー
クエリパラメータ
ログタイプ
レスポンス詳細
成功レスポンスの例
主なレスポンスフィールド
other フィールドには入れ子のオブジェクトではなく JSON の文字列が入るため、2 回目のパースが必要です
(json.loads() は Python、JSON.parse() は JavaScript で使用します)。そこには billing_type、
request_path(実際に呼び出されたエンドポイント)、group_ratio、model_ratio、および usage が含まれます。クォータ変換
変換ルール
500,000 クォータ = $1.00 USD
quota ÷ 500,000
例:
quota: 7500→ $0.015 USDquota: 22500→ $0.045 USDquota: 18→ $0.000036 USD
エラーレスポンス
HTTP 401 - 認証に失敗しました
sk-で始まる APIキーが誤ってシステム token として使用されました。
解決策: コンソールでシステム token を再生成し、Authorization には Bearer プレフィックスなしの 生の値が入っていることを確認してください。
コード例
cURL 例(単一ページ、簡易確認)
このコマンドは最大 10 件のレコードを返します。実際の照合には、下のページネーション版を使用してください。
Python 例(ページネーション対応、すぐ実行可能)
Node.js 例(ページネーション対応)
Python の requests ライブラリと Node.js の fetch API は、どちらも gzip を自動で展開するため、
追加の設定は不要です。curl だけは明示的な
--compressed フラグが必要です。一般的なシナリオ
期間内の支出を計算する
上の Python の例を使ってください。重要なのは、type=2 を渡すことと、合計した quota を 500,000 で割ることです。単一のモデルに絞るには、model_name パラメータを追加します。
失敗した呼び出しを見つける
ゲートウェイによって拒否されたリクエスト(不正なパラメータなど)は
quota が 0 で、
課金されません。ログ内の error_code を使うと、「呼び出しが失敗した」のか
「呼び出しは成功したが、結果が気に入らなかった」のかを切り分けられます。サポートに渡すリクエスト ID を提供する
ログで問題のある呼び出しを見つけて、サポートにrequest_id を伝えてください。これにより、
正確なリクエストをエンドツーエンドで特定できるため、「あるモデルへの呼び出しが
ある時刻の近くで失敗した」と説明するよりはるかに効率的です。
よくある質問
なぜ 10 件しか取得できないのですか?
なぜ 10 件しか取得できないのですか?
page_size のサーバー側上限は 10 です。それより大きい値でもエラーにはなりませんが、反映もされません。
それ以上取得するには、ページネーション(p=0、p=1、p=2 など)を使い、レスポンスが空の配列を返すまで続ける必要があります。上の Python と Node.js の例には、すでにこの処理が含まれています。レスポンスの一部のフィールドが空です。何か問題がありますか?
レスポンスの一部のフィールドが空です。何か問題がありますか?
いいえ。一部のフィールドにはプラットフォーム内部の情報が含まれており、通常のアカウントから見ると空または 0 です。これは想定どおりで、照合やトラブルシューティングに必要なフィールドには影響しません —
quota、model_name、error_code、request_id
はいずれも完全に埋まっています。token_group がコンソールに表示されるグループ名と異なるのはなぜですか?
token_group がコンソールに表示されるグループ名と異なるのはなぜですか?
API はグループの識別子を返しますが、コンソールはグループのラベルを表示します。
これらは異なる場合があります — たとえば、API では
default が返り、コンソールでは Default と表示されます。完全な対応表は、公開エンドポイント https://api.apiyi.com/api/pricing の usable_group フィールドで確認できます。このフィールドは識別子をラベルに対応付けます。レポートをコンソールと一致させたい場合は、この対応付けを自分で適用してください。token のカウントとクォータが一致していないようです。どちらが正しいのですか?
token のカウントとクォータが一致していないようです。どちらが正しいのですか?
quota を使用してください。これは、その呼び出しで実際に差し引かれた量であり、照合に適した唯一のフィールドです。画像生成や動画生成のような呼び出しごとの課金モデルでは、レスポンス内の token カウントが価格計算に関与しないプレースホルダー値になる場合があります — そうしたモデルは other.billing_type に by_count を報告します。どこまで遡ってクエリできますか?
どこまで遡ってクエリできますか?
start_timestamp と end_timestamp を使って任意の範囲を指定できます。履歴データの正確な保持期間については、サポートにお問い合わせください。長期的な遡及参照を API に頼るよりも、照合データを定期的にエクスポートすることをおすすめします。curl で文字化けする、または jq がエラーを出す
curl で文字化けする、または jq がエラーを出す
理由: API が gzip 圧縮されたコンテンツ(Python の requests ライブラリと Node.js の fetch API は自動的に展開します。
Content-Encoding: gzip)を返しており、curl がそれを展開していないためです。対処法: --compressed フラグを追加します:ログをクエリするとクォータを消費しますか?
ログをクエリするとクォータを消費しますか?
いいえ。ログクエリエンドポイントはクォータを消費しません。
重要な注意事項
リクエスト制限
- レート制限を避けるため、クエリの間隔は少なくとも 1 秒空けてください
- 適切なリクエストタイムアウトを設定してください(30 秒を推奨します)
- 広い期間範囲では、ページネーションと再試行処理を実装してください
関連ドキュメント
- 残高照会 API — アカウントの残り残高を確認します
- token 管理 API — API key をプログラムから作成・管理します
- 呼び出し履歴の確認方法 — コンソールで手動確認します
- ログと課金の理解 — 課金フィールドの読み方