AI GatewayでLLMのリクエストとレスポンスをどこまで記録できるか試す

はじめに

LLMアプリを作っていて、最初に怖くなるのは「動かないこと」よりも「動いたあとに何が起きているか分からないこと」です。

OpenAIやAnthropicのSDKを使えば、LLMを呼び出すこと自体は簡単です。数行のコードでプロンプトを送り、レスポンスを受け取れます。個人開発やPoCなら、それだけでも十分に見えます。

しかし、運用を考え始めると急に不安になります。

どのプロンプトで失敗したのか。どのモデルが遅いのか。トークン数はどれくらい増えているのか。エラーはアプリ側なのか、プロバイダ側なのか。ユーザーから「変な回答が出た」と言われたときに、実際の入力と出力を追えるのか。

このあたりが見えないと、LLMアプリは改善しにくくなります。

今回は、Cloudflare AI Gatewayを使って、LLMのリクエストとレスポンスをどこまで記録できるかを試します。

単なる機能紹介ではなく、実際に小さなリクエストを流し、Cloudflareのダッシュボード上で何が見えるのかを確認します。あわせて、ログに本文が残ることの便利さと怖さ、LangfuseのようなLLMOpsツールとの棲み分けも考えます。

AI Gatewayをまだ触ったことがない場合は、先に Cloudflare AI Gatewayの導入で最初に押さえることを読むと流れをつかみやすいです。Workers AI bindingを使った最小構成で、AI Gatewayにリクエストを通すところまで整理しています。

結論から言うと、AI Gatewayは「LLM呼び出しの出口ログ」を作る入口としてかなり使いやすそうです。公式仕様上、ダッシュボードやログにはprovider、model、status、duration、tokens、cost、prompt、responseが出るため、最初のデバッグとコスト感の把握に必要な材料は揃っています。

ただし、この記事を書き直していて反省した点があります。初稿では「確認します」「次に試したいです」という表現が多く、検証済みのこと、公式仕様として分かっていること、これから試すことが混ざっていました。このブログの方針では、そこを混ぜるのはよくありません。

そのため本稿では、基本ログとして確認する範囲、公式仕様から分かる観測機能、まだ自分の環境では未検証の高度化ポイントを分けて整理します。

今回試すこと

今回は、アプリケーションを大きく作りません。

まずはNode.jsの小さなスクリプトから、AI Gateway経由でOpenAI互換APIを呼び出します。次に、Cloudflareのダッシュボードでログを確認します。

構成は次のとおりです。

Node.js script
  ↓
Cloudflare AI Gateway
  ↓
OpenAI API

最初からWebアプリに組み込まない理由は、観測対象を絞るためです。

Webアプリにすると、フロントエンド、APIサーバー、認証、CORS、デプロイなど、LLMロギング以外の論点が混ざります。今回見たいのは、AI Gatewayを挟むことで、LLMリクエストの何が見えるようになるかです。

この記事で確認するのは、次の項目です。

promptが記録されるか
responseが記録されるか
providerとmodelが分かるか
statusが分かるか
latencyまたはdurationが分かるか
input tokensとoutput tokensが分かるか
costが分かるか
エラー時にどの情報が残るか
ログ保存や閲覧にどのような制約があるか

加えて、運用に寄せるなら次の論点も見ます。

リクエストごとにpayload保存を制御できるか
user、team、environmentなどのメタデータを付けられるか
costは請求額そのものなのか、推定値なのか
ダッシュボードの外へログやtraceを出せるか
Langfuseなどの観測基盤とどう接続できるか

期待していること

AI Gatewayに期待しているのは、LLM呼び出しの入口を差し替えるだけで、最低限の観測性を得られることです。

本格的なLLMOpsをやるなら、Langfuseのようにtrace、span、generation、scoreを設計した方がよいです。RAG、Agent、評価ループ、ユーザーフィードバックまで扱うなら、アプリケーション内部の処理構造を明示的に記録する必要があります。

ただ、すべてのAIアプリで最初からそこまで作るのは重いです。

まずは「どのLLM呼び出しが、いつ、どのモデルに送られ、何トークン使い、いくらかかり、どのくらい遅かったか」を見たい。その入口としてAI Gatewayが使えるなら、かなり実用的です。

個人的には、AI Gatewayを「LLMトラフィックの入口に置く観測レイヤー」として見ています。アプリ内部の詳細なtraceを取るというより、プロバイダへ出ていくLLMリクエストをまとめて可視化する道具です。

今回の記事では、その理解がどこまで妥当かを、基本ログ、payload制御、metadata、cost、外部連携の観点で整理します。

セットアップ

まずCloudflare側でAI Gatewayを作成します。

CloudflareのダッシュボードからAI Gatewayを作成し、Gateway名を決めます。あわせて、Cloudflare Account IDを確認します。

環境変数は次のように用意します。

CLOUDFLARE_ACCOUNT_ID=xxxx
CLOUDFLARE_AI_GATEWAY_ID=xxxx
OPENAI_API_KEY=sk-xxxx

ローカルでは .env を使います。

touch .env

.env には次のように書きます。

CLOUDFLARE_ACCOUNT_ID=your-account-id
CLOUDFLARE_AI_GATEWAY_ID=your-gateway-id
OPENAI_API_KEY=your-openai-api-key

公開リポジトリには .env を含めず、.env.example だけを置きます。

CLOUDFLARE_ACCOUNT_ID=
CLOUDFLARE_AI_GATEWAY_ID=
OPENAI_API_KEY=

最小コード

まずはfetchで直接呼びます。

SDKを使ってもよいのですが、最初はAI GatewayのURL構造を見えるようにしたいので、あえて素のfetchで書きます。

import "dotenv/config";

const accountId = process.env.CLOUDFLARE_ACCOUNT_ID;
const gatewayId = process.env.CLOUDFLARE_AI_GATEWAY_ID;
const openaiApiKey = process.env.OPENAI_API_KEY;

if (!accountId || !gatewayId || !openaiApiKey) {
  throw new Error("Missing required environment variables");
}

const gatewayUrl =
  `https://gateway.ai.cloudflare.com/v1/${accountId}/${gatewayId}/openai/chat/completions`;

const response = await fetch(gatewayUrl, {
  method: "POST",
  headers: {
    Authorization: `Bearer ${openaiApiKey}`,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    model: "gpt-4o-mini",
    messages: [
      {
        role: "system",
        content: "あなたはLLMOpsに詳しい技術ブログ編集者です。",
      },
      {
        role: "user",
        content:
          "AI GatewayでLLMのリクエストとレスポンスを記録する記事のタイトル案を3つ出してください。",
      },
    ],
    temperature: 0.3,
  }),
});

if (!response.ok) {
  const errorText = await response.text();
  throw new Error(`Request failed: ${response.status} ${errorText}`);
}

const data = await response.json();

console.dir(data, { depth: null });

このコードを実行します。

node src/index.ts

成功すれば、通常のOpenAI APIレスポンスと同じような形式で結果が返ります。

ここで重要なのは、レスポンスを受け取ることではありません。Cloudflare AI Gateway側に、この呼び出しがどう記録されるかです。

ダッシュボードで確認したいこと

リクエストを何回か流したあと、CloudflareのAI Gatewayダッシュボードを確認します。

確認したいのは、次の項目です。

timestamp
provider
model
status
duration
input tokens
output tokens
cost
prompt
response

特に見たいのは、promptとresponseの本文がどのように表示されるかです。

LLMのデバッグでは、本文が見えることが非常に重要です。ユーザーが「変な回答が返った」と言ったとき、実際の入力と出力を確認できなければ、プロンプトが悪いのか、モデル選定が悪いのか、前処理が悪いのかを切り分けられません。

一方で、本文が見えることはリスクでもあります。

業務データ、個人情報、顧客情報、社内ドキュメントをプロンプトに含める場合、その内容がログに残るということです。便利だから有効にする、ではなく、何をログに残してよいかを決めたうえで使う必要があります。

この記事では、検証用の無害なプロンプトだけを使います。

基本ログで確認できること

AI Gatewayのログでまず見るべきものは、個別リクエストの事実です。

公式ドキュメント上、AI Gatewayのログには、user prompt、model response、provider、timestamp、request status、token usage、cost、duration、user agentが含まれます。DLP policyを設定している場合は、DLP action、matched policy、matched profile、検出されたentryもログに出ます。

これをLLMアプリの運用目線に置き換えると、基本ログで分かることは次のようになります。

観測したいこと	AI Gatewayで見る項目	使いどころ
どのモデルへ投げたか	provider / model	モデル切り替え後の影響確認
成功したか失敗したか	status / error	失敗リクエストの切り分け
どれくらい遅いか	duration	レイテンシ悪化の把握
どれくらい使ったか	input tokens / output tokens	プロンプト肥大化の検知
どれくらい高いか	cost	コスト傾向の把握
何を投げたか	prompt	出力不良時の原因調査
何が返ったか	response	ユーザー申告との照合

ここで重要なのは、AI Gatewayのログは「アプリケーション内部の状態」ではなく「LLMプロバイダへ出ていくリクエスト」を見るものだという点です。

たとえばRAGで回答が悪かった場合、AI Gatewayを見ると、最終的にLLMへ渡したpromptとresponseは確認できます。しかし、そのpromptに入った検索文書がなぜ選ばれたのか、query rewriteが失敗したのか、retrieverのスコアが低かったのかまでは分かりません。

つまり、AI Gatewayは「LLMへの出口で何が起きたか」を見る道具です。RAGやAgentの内部工程を見る道具ではありません。

まず見るべき結果

この検証で最初に確認する結果は、次の3つです。

1つ目は、正常系のログです。OpenAI互換エンドポイントをAI Gateway経由に差し替えたあと、ダッシュボードのログにprovider、model、status、duration、tokens、costが出るかを確認します。ここが出なければ、Gateway URL、Account ID、Gateway ID、API key、provider pathのどこかが間違っています。

2つ目は、payloadの保存です。promptとresponse本文が見える場合、デバッグには有効です。一方で、本文が保存されること自体がリスクになります。検証環境なら便利で済みますが、業務利用では「本文を保存してよいリクエスト」と「metadataだけ残したいリクエスト」を分ける必要があります。

3つ目は、エラー系のログです。存在しないmodel、無効なAPI key、不正なbodyを投げたとき、AI Gateway側に失敗リクエストが残るかを確認します。運用時に大事なのは、成功ログよりも失敗ログです。失敗がアプリ側の入力不備なのか、provider側の認証やmodel指定の問題なのかを切り分けられる必要があります。

初稿では、ここを「次に確認します」と書いていました。公開記事としては弱いので、実際に記事として出す段階では、少なくとも次の表を埋めるべきです。

ケース	期待する結果	記事に残す観点
正常なchat completions	status success、model、tokens、duration、costが残る	Gateway経由の疎通確認
存在しないmodel	error statusが残る	provider由来のエラーが見えるか
無効なAPI key	認証エラーが残る	Gatewayとproviderのどちらで失敗したか
不正なbody	400系エラーが残る	アプリ側バリデーション不足の検知
payload保存なし	prompt / responseを保存しない	metadataだけで運用できるか

この表を埋めるところまでやって、はじめて「基本のロギングを確認した」と言えます。

エラーも記録してみる

正常系だけを見ると、実運用での使い勝手は分かりません。

LLMアプリで本当に困るのは、失敗したときです。そこで、意図的にいくつかのエラーを起こします。

まず、存在しないモデル名を指定します。

model: "not-existing-model"

次に、APIキーを間違えます。

OPENAI_API_KEY=invalid-key

さらに、リクエストボディを壊します。

body: JSON.stringify({
  model: "gpt-4o-mini",
  messages: "invalid"
})

それぞれのケースで、次を確認します。

AI Gatewayのログに失敗リクエストが残るか
status codeは見えるか
provider側のエラー本文は見えるか
アプリ側のエラーとAI Gateway側のエラーを切り分けられるか

個人的には、ここが一番記事価値になりそうです。

正常に動いた手順だけなら、公式ドキュメントとの差分が薄くなります。しかし、エラー時に何が見えるかは、運用設計に直結します。

payloadを保存しない選択肢

AI Gatewayで一番便利で、一番怖いのはpromptとresponse本文が見えることです。

本文があると、デバッグはかなり楽になります。ユーザーから「変な回答が出た」と言われたときに、実際の入力、system prompt、model、出力を見れば、少なくともLLMに渡った最終状態は確認できます。

一方で、本文ログはそのまま情報管理の論点になります。業務データ、個人情報、顧客情報、社内ドキュメントを含むpromptを保存してしまうと、ログ基盤自体が機密データの保管場所になります。

AI Gatewayでは、リクエストごとにログ収集やpayload保存を制御できます。

cf-aig-collect-log: false

このヘッダーを使うと、そのリクエストのログ自体を保存しない動きになります。

cf-aig-collect-log-payload: false

こちらは、requestとresponseのpayload保存を抑止しつつ、token、model、provider、status、cost、durationのようなmetadataは残すための設定です。

運用上は、後者の方が使いやすい場面が多そうです。本文は残したくないが、コスト、レイテンシ、エラー率は追いたい、という要件は普通にあります。

fetchで書くなら、次のようにヘッダーを足します。

const response = await fetch(gatewayUrl, {
  method: "POST",
  headers: {
    Authorization: `Bearer ${openaiApiKey}`,
    "Content-Type": "application/json",
    "cf-aig-collect-log-payload": "false",
  },
  body: JSON.stringify({
    model: "gpt-4o-mini",
    messages,
  }),
});

この設定は、個人的には本番導入時の初期値候補です。開発環境ではpayloadを保存して調査し、本番環境ではpayloadを保存せずmetadataだけ残す。障害調査で必要な一部の検証リクエストだけpayload保存を許可する。こういう運用の方が、あとで説明しやすいです。

メタデータを付ける

ログは残るだけでは足りません。後から探せなければ、運用では使いにくいです。

AI Gatewayでは、cf-aig-metadata ヘッダーでリクエストに任意のメタデータを付けられます。値はstring、number、booleanに限られ、保存されるメタデータは最大5件です。

たとえば、次のような情報を付けます。

headers: {
  Authorization: `Bearer ${openaiApiKey}`,
  "Content-Type": "application/json",
  "cf-aig-metadata": JSON.stringify({
    app: "blog-editor",
    env: "staging",
    feature: "title-suggestion",
    user_type: "admin",
    experiment: true,
  }),
}

このメタデータがあると、ログの見方が変わります。

単に「gpt-4o-miniのエラーが増えた」ではなく、「stagingのtitle-suggestionだけでエラーが増えた」「特定featureのtokensが増えている」「実験リクエストだけcostが高い」といった切り分けができます。

ここで注意したいのは、metadataに個人情報そのものを入れないことです。user_id のような識別子を入れる場合でも、公開記事やログ例では抽象化し、実運用ではハッシュ化や内部ID化を検討した方がよいです。

また、OpenTelemetry連携でもこのmetadataはspan attributesとして使えるため、後からLangfuse、Honeycomb、Braintrustのような基盤へつなぐ場合にも効いてきます。

costは推定値として扱う

AI Gatewayのcostは便利ですが、請求額そのものとして扱うべきではありません。

公式ドキュメント上も、cost metricは送受信token数をもとにした推定値です。provider側の正確な請求額は、最終的にはproviderのダッシュボードを確認する必要があります。

この前提を置くと、AI Gatewayのcostは次の用途に向いています。

モデル別のコスト傾向を見る
prompt変更後にtokenが増えていないか見る
provider間のざっくり比較をする
異常に高いリクエストを見つける
予算超過の予兆を早めに拾う

逆に、月次請求の突合や会計上の正確な利用額として使うには弱いです。

LLMOpsで大事なのは、costを「正確な請求額」としてではなく、「運用上のシグナル」として使うことです。高いリクエスト、急に増えたtoken、特定featureの肥大化を見つけるには十分価値があります。

ログを見て考えること

ログを確認したら、単に「見えました」で終わらせません。

次の観点で整理します。

1つ目は、デバッグに十分かどうかです。プロンプトとレスポンス、モデル、トークン数、ステータスが見えれば、最低限の原因調査には使えそうです。

2つ目は、コスト管理に使えるかどうかです。トークン数とコストが見えるなら、モデル変更やプロンプト肥大化の影響を追いやすくなります。

3つ目は、レイテンシ調査に使えるかどうかです。durationが見えるなら、遅延の傾向をモデル別、プロバイダ別に確認できます。

4つ目は、評価データとして使えるかどうかです。ログに本文が残るなら、後から失敗例を集めて評価データセット化できる可能性があります。ただし、そのためにはログID、フィードバック、メタデータ付与の仕組みが必要になります。

5つ目は、セキュリティとコンプライアンスです。本文ログは便利ですが、何でも残してよいわけではありません。業務利用するなら、保存期間、アクセス権限、マスキング、DLP、暗号化、外部エクスポートの方針が必要です。

ここまでを見ると、AI Gatewayのログは「個別リクエストを読む」には十分です。ただし、運用が進むと、ダッシュボードを目視するだけでは足りなくなります。

たとえば、次のような問いにはダッシュボードだけでは限界があります。

昨日と比べてtokensが急増したfeatureはどれか
latencyが悪化したのは特定modelだけか
payload保存を無効にした本番リクエストだけを集計できるか
AI Gatewayのspanをアプリ側traceと同じtrace IDで見られるか
DLPでflagされたリクエストを別の保管先で監査できるか

ここから先は、AI Gatewayを単体のログビューアではなく、観測パイプラインの入口として扱う必要があります。

OTelでtraceに接続する

AI GatewayはOpenTelemetry-compatible backendへtrace spanをexportできます。

spanには、model、provider、input tokens、output tokens、prompt、completion、cost estimate、custom metadataなどが含まれます。つまり、AI Gatewayで見えていたLLMリクエスト情報を、既存の分散トレーシング基盤へ流せるということです。

ここで大事なのは、trace context propagationです。

AI Gatewayには、次のヘッダーでtrace IDとparent span IDを渡せます。

cf-aig-otel-trace-id: <32-character-hex-trace-id>
cf-aig-otel-parent-span-id: <16-character-hex-span-id>

これを使うと、アプリケーション側のtraceとAI Gateway側のspanを同じ流れに接続できます。

RAGの例で考えると、理想は次のようなtraceです。

HTTP request
  ↓
auth
  ↓
query rewrite
  ↓
vector search
  ↓
prompt build
  ↓
AI Gateway span
  ↓
post process

AI Gateway単体では、query rewriteやvector searchは見えません。しかし、OTelでアプリ側traceと接続すれば、「どのアプリ処理の中で、どのLLM呼び出しが、どれくらい遅く、高く、失敗したのか」を同じ画面で追える可能性があります。

ここはまだ自分の環境では未検証です。したがって、この記事では「次の高度化ポイント」として扱います。ただ、AI GatewayをLangfuseやHoneycombのような基盤と接続するなら、最初に見るべき論点です。

Logpushで長期分析に回す

ダッシュボードのログは、個別調査には向いています。一方で、長期保存、横断集計、監査、再学習用データ抽出まで考えると、外部ストレージへ出したくなります。

AI GatewayにはWorkers Logpushでログを外部ストレージへexportする仕組みがあります。ログは暗号化され、受け取り側で復号して処理する前提です。

ここで設計上の論点になるのは、保存先そのものではありません。何をどの粒度で保存し、どの用途に使うかです。

用途	保存したいもの	注意点
コスト分析	model、tokens、cost、metadata	costは推定値
障害調査	status、error、duration、provider	payloadなしでも切り分けできる設計が必要
品質改善	prompt、response、feedback	個人情報と機密情報の扱いが重い
監査	DLP action、policy、metadata	アクセス権限と保存期間が必要
評価データ化	prompt、response、評価ラベル	同意、匿名化、利用目的の整理が必要

個人的には、最初からすべてのpayloadを長期保存するのは避けたいです。まずmetadata中心で集計できる形にし、品質改善に使うリクエストだけを明示的にサンプリングする方が安全です。

ここも現時点では設計論です。Logpushまで実際に組むなら、別記事でR2やClickHouseに流し、GraphQLやSQLで集計できるかを検証した方がよさそうです。

Langfuseとの棲み分け

AI Gatewayを試すと、Langfuseと何が違うのかが気になります。

現時点の仮説では、AI GatewayはLLMプロバイダへの出口を観測するものです。どのリクエストが、どのプロバイダに、どのモデルで送られ、どれくらいのトークンとコストを使ったかを見るのに向いています。

一方で、Langfuseはアプリケーション内部の処理をtraceとして見るものです。

たとえばRAGでは、ユーザー入力を受け取り、クエリを書き換え、ベクトル検索し、取得文書をプロンプトに詰め、LLMに投げ、回答を後処理し、ユーザー評価を受け取る、という流れがあります。

このときAI Gatewayだけでは、「最後にLLMへ送ったリクエスト」は見えても、その前にどの文書を検索したのか、なぜそのプロンプトになったのか、どのステップで品質が落ちたのかまでは見えにくいはずです。

つまり、棲み分けは次のようになりそうです。

AI Gateway:
  LLMプロバイダへのリクエストを横断的に観測する

Langfuse:
  アプリ内部のLLM処理フローをtraceとして観測する

小さなAI機能なら、まずAI Gatewayだけでも十分かもしれません。

しかし、RAG、Agent、評価ループ、ユーザーフィードバックまで扱うなら、Langfuseのようなtrace設計が必要になります。

整理すると、役割分担は次のようになります。

観点	AI Gateway	Langfuse
見る場所	LLM providerへの出口	アプリ内部のLLM処理
得意なもの	model、tokens、cost、duration、status	trace、generation、score、feedback
導入の軽さ	URL差し替えで始めやすい	アプリコードへ計測を入れる必要がある
失敗調査	provider呼び出しの失敗に強い	処理フローのどこで品質が落ちたか見やすい
評価ループ	単体では弱い	scoreやdatasetへつなぎやすい

したがって、どちらか一方を選ぶというより、入口が違います。

小さなAI機能を作った直後なら、まずAI GatewayでLLMトラフィックを見えるようにする。その後、RAG、Agent、評価、ユーザーフィードバックを扱い始めたらLangfuseで内部traceを設計する。さらに、AI GatewayのOTel exportやmetadataで両者をつなぐ。

この順番が、個人開発や小さなPoCでは現実的だと感じています。

この記事の着地点

この記事で確認したいのは、AI Gatewayを使えばLLMアプリの運用がすべて解決する、という話ではありません。

むしろ、LLM呼び出しの最初の観測点として、どこまで使えるのかを見たいです。

LLMアプリは、作るだけなら簡単になりました。数行のコードでモデルを呼び出し、もっともらしい回答を返せます。

しかし、本番に近づくほど、見るべきものが増えます。

プロンプト、レスポンス、トークン数、コスト、レイテンシ、エラー率。これらが見えないまま改善するのは難しいです。

AI Gatewayは、その最初の可視化レイヤーとして使えるのか。

ここに対する現時点の答えは、「LLMプロバイダへの出口を見る用途なら使える」です。

特に、URLを差し替えるだけでprovider、model、status、duration、tokens、cost、prompt、responseを見られる設計は、最初の観測レイヤーとしてかなり強いです。

一方で、AI GatewayだけでLLMOpsが完成するわけではありません。アプリ内部のtrace、RAGの検索結果、Agentのtool call、ユーザーフィードバック、評価scoreは別途設計する必要があります。

今回の限界と次にやること

この記事では、AI Gatewayの基本ログと、観測を高度化するための設計論を整理しました。ただし、まだ実装検証として残っているものがあります。

項目	状態	次にやること
正常系ログ	最小コードで確認対象	実ログのスクリーンショットまたは項目表を残す
エラー系ログ	ケース設計済み	model不正、API key不正、body不正を実行して比較する
payload保存制御	公式仕様を整理	`cf-aig-collect-log-payload: false` の見え方を確認する
metadata	公式仕様を整理	feature、env、experimentでフィルタできるか確認する
cost	推定値として整理	provider請求額との差分をどう扱うか決める
OTel	未検証	LangfuseまたはHoneycombへspan exportする
Logpush	未検証	R2またはClickHouseへ流して日次集計する

次にやるべきなのは、OTelやLogpushへ飛ぶ前に、まず基本ログの検証表を埋めることです。

正直、ここを飛ばして「高度な観測」に進むと、また記事が不親切になります。まずは正常系、エラー系、payload保存なし、metadata付きの4パターンを流し、AI Gatewayのログ画面で何が見え、何が見えないかを確定させる。そのうえで、OTelやLogpushへ広げるのが筋がよさそうです。

ぼやきとしては、LLMアプリは「とりあえず動いた」からが本番です。動いたものをどう見て、どう直して、どう安全に運用するか。AI Gatewayは、その入口としてちょうどよい位置にいる気がしています。

AI GatewayでLLMのリクエストとレスポンスをどこまで記録できるか試す

AI GatewayでLLMのリクエストとレスポンスをどこまで記録できるか試す

はじめに

今回試すこと

期待していること

セットアップ

最小コード

ダッシュボードで確認したいこと

基本ログで確認できること

まず見るべき結果

エラーも記録してみる

payloadを保存しない選択肢

メタデータを付ける

costは推定値として扱う

ログを見て考えること

OTelでtraceに接続する

Logpushで長期分析に回す

Langfuseとの棲み分け

この記事の着地点

今回の限界と次にやること

DUOps

Cloudflare AI Gatewayの導入で最初に押さえること

Langfuse朝ブリーフィングを実装して試す - 異常traceだけをSlackに流せるか

Langfuseの異常だけをSlackに流す朝ブリーフィングを作りたい

AI GatewayでLLMのリクエストとレスポンスをどこまで記録できるか試す

AI GatewayでLLMのリクエストとレスポンスをどこまで記録できるか試す

はじめに

今回試すこと

期待していること

セットアップ

最小コード

ダッシュボードで確認したいこと

基本ログで確認できること

まず見るべき結果

エラーも記録してみる

payloadを保存しない選択肢

メタデータを付ける

costは推定値として扱う

ログを見て考えること

OTelでtraceに接続する

Logpushで長期分析に回す

Langfuseとの棲み分け

この記事の着地点

今回の限界と次にやること

DUOps

関連記事

Cloudflare AI Gatewayの導入で最初に押さえること

Langfuse朝ブリーフィングを実装して試す - 異常traceだけをSlackに流せるか

Langfuseの異常だけをSlackに流す朝ブリーフィングを作りたい