Portkey（現PRISMA AIRS AI Gateway）でLLM APIを監視する方法

公式siteは「Portkey is now PRISMA AIRS AI Gateway」と案内しており、既存のPortkey製品・開発者向け資料も確認対象です。導入時は契約・画面に表示される製品名と利用可能な機能を照合します。現在は、LLM requestのrouting、observability、guardrails、governanceを扱います。監視ではrequestの成功率だけでなく、trace、latency、cost、qualityを同じ運用単位で追います。

監視対象のMatrix

表は横にスクロールできます

Signal	見る値	使いどころ
Reliability	error、timeout、retry	providerやrouteの障害切り分け
Performance	latency	遅延の発生段階を特定
Cost	model・user・workspace別usage	想定外spendを発見
Trace	LLM call、tool call、retrieval	multi-step agentを追跡
Quality	user feedback等	数値指標だけでは見えない劣化
Governance	access、redaction、retention	data handlingを確認

GatewayからTraceまで

application requestをgateway経由にし、request IDやtraceでmulti-step workflowをつなぎます。単一callとagent workflowを分け、どのmodel / providerでerrorや遅延が起きたかを調べます。

Portkeyはrequest / response、model、provider、token、latency、costを扱うobservabilityとOpenTelemetry-compatible telemetryを案内しています。監視stackへexportする範囲や現行機能は導入時に公式資料で確認します。

Securityと運用条件

• prompt / responseをlogへ残す範囲を決める

• PII redaction、access control、retentionを確認

• secretをapplication logやtraceへ含めない

• cost alertやlatency閾値のownerを決める

• feedbackとrequest traceの紐づけを確認する

切り分けの順番

1. request IDまたはtraceで該当実行を特定する。

2. gateway、provider、tool、retrievalのどの段階か見る。

3. error / latency / retryとmodelを確認する。

4. token・credit・costを確認し、異常なusageと区別する。

5. output qualityのfeedbackを確認して修正箇所を決める。

AIものさしの判断

複数providerやagent callを運用するなら、request単位のlogだけでなくtraceでworkflow全体を追えるようにします。cost・latencyの最適化と、prompt / responseの保護を同時に設計してください。

監視を実装へ落とすイベント設計

監視の最初の作業は、dashboardを眺めることではなく、一つの実行を追える識別子を決めることです。アプリrequest、gateway request、LLM call、tool call、最終回答が別々のIDになると、遅延や費用の原因を追えません。親request IDとstep / span IDを使い、ログ上で一つの実行として関連づけます。

表は横にスクロールできます

記録するsignal	推奨する粒度	調査で答えること
request ID / trace	一つのユーザー実行	どの呼び出し列で失敗したか
provider / model / route	各LLM call	どのrouteでtimeoutやfallbackが起きたか
status / error class	各step	入力、gateway、providerのどこで失敗したか
latency	call単位とend-to-end	待ち時間がどの段階で増えたか
token / cost	callと実行の両方	予算超過がどの用途から起きたか
feedback / eval	answer単位	成功率だけでは見えない品質変化

全てのprompt本文を永続保存する必要はありません。障害調査に必要なmetadataと、本文を保存する必要性を分け、redaction、アクセス権、retentionを設計します。ユーザー入力に個人情報や社内機密が入る用途では、収集前に保存範囲を決めます。

Alertは利用者影響へ結び付ける

error件数だけの閾値は、trafficが増えると平常時の一時失敗にも反応します。成功率、p95 latency、timeout率、fallback率、cost per requestなどから、利用者影響に結び付くsignalを選びます。小さな試験期間のbaselineを取ってから閾値を設定し、warningと停止条件を分けます。

表は横にスクロールできます

状況	まず見るもの	運用Action
失敗率が急増	provider別status、route、time window	影響範囲を切り分け、必要ならrouteを止める
latencyが悪化	gateway、provider、toolごとのspan	遅いstepを特定し、fallbackは品質検証後に使う
costが予算超過	model、user、route別usage	新規処理を制限し、budget ownerへ通知
quality feedbackが悪化	prompt/model変更、評価set	直近の変更を切り分けてrollback候補を作る
redaction違反	具体例、policy、対象trace	閲覧範囲を制限し、incident手順を適用

fallbackが常に正常な答えを保証するわけではありません。別modelへrouteした結果は、latency・costだけでなく出力schema、品質、safetyを評価してから採用します。

Traceを使った障害切り分け例

利用者から「回答が遅く、根拠リンクが少ない」と報告されたとき、平均値だけで結論を出さず、代表requestをtraceで開きます。最初にend-to-end時間を検索・retrieval・LLM生成へ分け、次にproviderやmodelごとのcallを見ます。

1. 親request IDから該当traceを開く。

2. retry、fallback、timeoutしたspanを特定する。

3. 検索結果数とsource選別状態を確認する。

4. contextサイズ、model、generation時間を比較する。

5. 同一条件の成功traceと並べる。

6. 原因候補を一つずつ変更し、評価setで再確認する。

この調査では、ログに全文が保存されていないからといって直ちに内容を追加保存せず、metadataだけで原因が絞れるかを先に確認します。データ保持の変更はprivacy reviewの対象です。

Securityと運用の境界

Portkey / PRISMA AIRSの現行案内では、AI Gatewayに加えてobservability、governance、guardrails等が説明されています。ただし機能名が存在することだけで、自社の設定や契約範囲で有効だとは言い切れません。実環境で有効化したpolicy、workspace、deployment modeを確認し、監視とブロックの違いをテストします。

• provider keyはvault / secret managerで管理し、traceに出さない

• request / response本文のredactionを試験payloadで確認する

• access controlとtrace閲覧権限を最小化する

• retentionとexport先の責任者を決める

• guardrailを監視のみからblockへ移す前にfalse positiveを測る

• 障害時に製品管理画面へ入れなくてもapplication側ログで追えるか確認する

導入時のAcceptance Check

production trafficへ接続する前に、検証用requestでtrace、error、cost、latencyが期待した粒度で残るかを確認します。API keyやユーザー本文を含まない合成データを使い、通常系、provider timeout、429、fallback、guardrail検出を試します。合格条件は「da（新しいタブで開く）shboardに表示された」ではなく、運用担当者がrequestを特定し（新しいタブで開く）、原因を切り分け、必要なら停止・復旧できることです。（新しいタブで開く）

導入後のownerと連絡経路も決（新しいタブで開く）めておきます。alertが発火した際に誰がtraceを確認し、誰がroute停止や利用者告知を判断するかが曖昧なら、閾値の設計より運用分担を先に整えます。