すべてのプロダクト
Search
ドキュメントセンター

Platform For AI:LLM インテリジェントルーティングワークベンチ

最終更新日:Jun 26, 2026

WebUI ワークベンチは、LLM インテリジェントルーティングのための視覚的な管理インターフェイスです。ロールベースのユーザー管理、独立した API キーの割り当て、リアルタイムモニタリング、設定のホットアップデートなどの機能を提供します。これにより、ユーザーID の分離とアクセス監査が可能になり、運用の複雑さが軽減されます。

機能概要

必要に応じて、ワークベンチでユーザー管理機能を有効にできます。この機能が無効の場合、ワークベンチは次のモジュールを提供します:

  • リアルタイムモニタリングスループット、レイテンシー、TTFT などのパフォーマンスメトリクスをほぼリアルタイムで表示します。また、ステータスコードの分布や、ゲートウェイ、スケジューラ、推論インスタンスの稼働状況も表示し、異常の迅速な検出とパフォーマンスボトルネックの特定に役立ちます。

  • 設定センター:トラフィックスプリッティングプロキシ、スケジューリングポリシー、リクエストスロットリング、トラフィックミラーリングなど、コアパラメーターをホットアップデートできます。変更はサービスの再起動なしで即座に反映されるため、本番環境での動的なチューニングに最適です。詳細については、「設定センター」をご参照ください。

  • スマートチャット:チャットテスト用の視覚的なインターフェイスを提供します。テキストまたは画像のリクエストを LLM インテリジェントルーティングサービスに直接送信し、HTTP ログを使用してデバッグすることで、トラフィックスプリッティングプロキシの動作を迅速に検証できます。

ユーザー管理を有効にすると、包括的なユーザーシステムが構築され、複数のチームが LLM サービスを共有する企業に最適です。これにより、次のモジュールが追加されます:

  • データ概要:ユーザーおよび部門ごとのトークン消費とリクエスト量の分布を表示します。時間範囲やユーザーディメンションでデータをフィルタリングでき、管理者が高使用率のユーザーを特定するのに役立ちます。

  • ユーザー管理:ユーザーの作成、取得、更新、削除、有効化/無効化、API キーの管理を行うことができます。これらの操作は API を通じても実行できます。詳細については、「ユーザー管理 API リファレンス」をご参照ください。

  • 監査ログ:ログイン/ログアウト、ユーザー変更、API キーのリセット、設定変更などの管理操作を記録します。各アクションの時間、操作者、リソースオブジェクトがログに記録されます。コンプライアンス監査や問題追跡のために、時間、操作タイプ、操作者でログをフィルタリングできます。

  • ユーザーセンター:ユーザーは自身のプロファイルを管理し、API キーを表示およびリセットし、個人のリクエスト統計とトークン消費記録を確認できます。

各ロールで利用可能なモジュールは次のとおりです:

ロール

権限

一般ユーザー

スマートチャット、ユーザーセンター (個人の統計情報を表示)

管理者

一般ユーザーのすべての権限に加えて、データ概要 (全ユーザーの統計情報を表示)、リアルタイムモニタリング、設定センター (読み取り専用)

システム管理者

管理者のすべての権限に加えて、ユーザー管理、監査ログ、設定センター (読み取り/書き込み)

ワークベンチへのアクセス

前提条件:LLM インテリジェントルーティングサービス、または LLM インテリジェントルーティングサービスを含む集約サービスをデプロイ済みであること。

手順

  1. PAI コンソールにログインし、EAS の推論サービスタブに移動します。

  2. 対象の LLM インテリジェントルーティングサービスを見つけます。

  3. サービスの [Invocation / Logs / Monitoring] 列で、[web app] アイコンをクリックします。

  4. ポップアップウィンドウで WebUI ワークベンチを見つけ、管理者ワークベンチを開きます。

    管理者がユーザー管理ページでユーザーを作成した後、ユーザーは [User Login portal] から自身の API キーを使用して WebUI ワークベンチにログインできます。

設定センター

設定センターでは、LLM インテリジェントルーティングのコア設定をホットアップデートでき、変更はサービスの再起動なしで即座に反映されます。次の図は、各設定が適用されるステージを示しています。

image

設定タイプ

説明

スケジューリングポリシー

リクエストを推論インスタンスにスケジューリングするためのポリシーを設定します。PD 分離モードでは、Prefill フェーズと Decode フェーズにそれぞれ個別のポリシーを設定できます。

モデルルーティング

リクエストの model フィールドに基づいて、対応するインスタンスにリクエストをルーティングします。モデルに一致するものが見つからない場合、リクエストは設定されたデフォルトモデルによって処理されます。

トラフィックスプリッティングプロキシ

モデルのプレフィックスまたは重みに基づいて、設定された外部の上流 API サービスにリクエストを転送します。

リクエストスロットリング

バックエンドリクエストの同時実行数を制限します。制限を超えた場合、リクエストを即座に拒否するか、キューに入れるかを選択できます。ライフサイクル全体、Prefill フェーズ、Decode フェーズに対して、それぞれ個別の同時実行数制限を設定できます。

トラフィックスプリッティングプロキシで指定された DashScope などの外部サービスは、独自のスロットリングルールに従うため、この設定の影響を受けません。

トラフィックミラーリング

本番トラフィックの一部をコピーして、ターゲットアドレスに送信します。これは、通常の応答に影響を与えることなく、カナリア検証、パフォーマンス比較、またはデータ収集に使用されます。

グローバルスケジューリング

現在のリージョンの推論リソースが不足している場合、スケジューラはトラフィックを他のアイドル状態のリージョンにある推論サービスインスタンスにルーティングします。これにより、グローバルな計算プーリングと効率的なリソースの再利用が可能になります。

ユーザー管理 API リファレンス

認証:すべての API コールには、リクエストヘッダーにシステム管理者の API キーを含める必要があります:Authorization: Bearer <admin_api_key>

コールを行う際は、例の中の https://gateway.example.com を、http://xxx.cn-shanghai.pai-eas.aliyuncs.com/api/predict/ai_assistant.ai_gw のようなご自身の LLM インテリジェントルーティングのエンドポイントに置き換えてください。

1. ユーザーの確認

従業員IDに基づいてユーザーを検索し、存在する場合はそのユーザー情報を返します。

リクエストGET /api/users/check?employee_id={employee_id}

パラメーター

パラメーター

タイプ

必須

説明

employee_id

string

はい

従業員 ID。

curl -X GET "https://gateway.example.com/api/users/check?employee_id=12345" \
-H "Authorization: Bearer <admin_api_key>"

2. ユーザーの作成

新しいユーザーを作成し、その API キーを返します。

リクエストPOST /api/users

パラメーター

パラメーター

タイプ

必須

説明

name

string

はい

ユーザー名。

email

string

いいえ

メールアドレス。

employee_id

string

いいえ

従業員 ID。

department

string

いいえ

部署。

role

string

いいえ

ユーザーのロール。デフォルト:user。選択可能な値:admin

metadata

object

いいえ

拡張情報。

curl -X POST "https://gateway.example.com/api/users" \
-H "Authorization: Bearer <admin_api_key>" \
-H "Content-Type: application/json" \
-d '{"name":"田中 太郎","email":"taro.tanaka@company.com","employee_id":"12345","department":"技術部"}'

3. ユーザーの取得

すべてのユーザーまたは単一のユーザーに関する情報を取得します。

リクエスト

  • GET /api/users (すべてのユーザーを取得)

  • GET /api/users/{user_id} (単一のユーザーを取得)

# すべてのユーザーを取得
curl -X GET "https://gateway.example.com/api/users" \
-H "Authorization: Bearer <admin_api_key>"

# 単一のユーザーを取得
curl -X GET "https://gateway.example.com/api/users/user_xxx" \
-H "Authorization: Bearer <admin_api_key>"

4. APIキーのリセット

ユーザーの API キーをリセットし、新しいキーを返します。

リクエストPOST /api/users/{user_id}/regenerate-key

curl -X POST "https://gateway.example.com/api/users/user_xxx/regenerate-key" \
-H "Authorization: Bearer <admin_api_key>"

5. ユーザーの更新

ユーザーの情報を更新します。

リクエストPUT /api/users/{user_id}

パラメーター

パラメーター

タイプ

必須

説明

name

string

はい

ユーザー名。

email

string

いいえ

メールアドレス。

employee_id

string

いいえ

従業員 ID。

department

string

いいえ

部署。

role

string

いいえ

ユーザーのロール。デフォルト:user。選択可能な値:admin

enabled

boolean

いいえ

ユーザーが有効かどうかを指定します。

metadata

object

いいえ

拡張情報。

curl -X PUT "https://gateway.example.com/api/users/user_xxx" \
-H "Authorization: Bearer <admin_api_key>" \
-H "Content-Type: application/json" \
-d '{"department":"新製品部","email":"taro.tanaka@newcompany.com"}'

6. ユーザーの削除

指定されたユーザーを削除します。

リクエストDELETE /api/users/{user_id}

curl -X DELETE "https://gateway.example.com/api/users/user_xxx" \
-H "Authorization: Bearer <admin_api_key>"

7. ユーザープロビジョニング

Provision API は、新しいユーザーを作成するか、API キーをリセットして、ワンタイムプロビジョニングリンクを生成します。ユーザーはこのリンクを使用して自身の API キーを取得できます。直接的なユーザー作成 (POST /api/users) と比較して、プロビジョニング方式はより安全です:

  • ユーザーは専用のリンクを通じて API キーを取得するため、キーがプレーンテキストで送信されるのを防ぎます。

  • リンクは 24 時間後に自動的に失効します。

  • リンクは一度しか使用できず、使用後は無効になります。

7.1 新規ユーザーのプロビジョニング

リクエストPOST /api/provision

curl -X POST "https://gateway.example.com/api/provision" \
  -H "Authorization: Bearer <admin_api_key>" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "田中 太郎",
    "email": "taro.tanaka@company.com",
    "employee_id": "12345",
    "department": "技術部"
  }'

7.2 プロビジョニングによるキーのリセット

このメソッドは、ユーザーがすでに存在しているものの、新しい API キーが必要な場合に使用します。

リクエストPOST /api/provision/reset

curl -X POST "https://gateway.example.com/api/provision/reset" \
-H "Authorization: Bearer <admin_api_key>" \
-H "Content-Type: application/json" \
-d '{"employee_id":"12345"}'

7.3 プロビジョニングリンクの検証

ユーザーが provision_url を開くと、Web ページがこのエンドポイントを呼び出してトークンを検証し、ユーザー情報と API キーを取得します。

リクエストGET /api/provision/verify?token={token}

8. 典型的なワークフロー

新規ユーザー登録 (プロビジョニング)

プロビジョニング方式では、ワンタイムリンクを通じて API キーを配信するため、より安全です。

# 1. ユーザーを作成し、プロビジョニングリンクを取得します。
curl -X POST "https://gateway.example.com/api/provision" \
-H "Authorization: Bearer <admin_api_key>" \
 -H "Content-Type: application/json" \
 -d '{"name":"田中 太郎","email":"taro.tanaka@company.com","employee_id":"12345","department":"技術部"}'
# 2. 返された provision_url をユーザーに送信します (例:メールやインスタントメッセージ経由)。

# 3. ユーザーがリンクを開くと、ページが自動的に /api/provision/verify を呼び出して API キーを取得します。

新規ユーザー登録 (直接作成)

# 1. ユーザーがすでに存在するかどうかを確認します。
curl -X GET "https://gateway.example.com/api/users/check?employee_id=12345" \
-H "Authorization: Bearer <admin_api_key>"

# 2. ユーザーが存在しない場合は、ユーザーを作成します。
curl -X POST "https://gateway.example.com/api/users" \
-H "Authorization: Bearer <admin_api_key>" \
-H "Content-Type: application/json" \
-d '{"name":"田中 太郎","employee_id":"12345","department":"技術部"}'

# 3. 返された api_key をユーザーに送信します。

ユーザーオフボーディング (無効化または削除)

# ユーザーを無効化します (推奨)。
curl -X PUT "https://gateway.example.com/api/users/user_xxx" \
-H "Authorization: Bearer <admin_api_key>" \
-H "Content-Type: application/json" \
-d '{"enabled": false}'

# または、ユーザーを削除します。
curl -X DELETE "https://gateway.example.com/api/users/user_xxx" \
-H "Authorization: Bearer <admin_api_key>"

APIキーの回復 (プロビジョニング)

# 従業員 ID でキーをリセットし、新しいプロビジョニングリンクを送信します。
curl -X POST "https://gateway.example.com/api/provision/reset" \
-H "Authorization: Bearer <admin_api_key>" \
-H "Content-Type: application/json" \
-d '{"employee_id":"12345"}'

# 返された provision_url をユーザーに送信します。

APIキーの回復 (直接リセット)

# 従業員 ID でユーザー情報を取得します。
curl -X GET "https://gateway.example.com/api/users/check?employee_id=12345" \
-H "Authorization: Bearer <admin_api_key>"

# 返された user_id を使用して API キーをリセットします。
curl -X POST "https://gateway.example.com/api/users/user_xxx/regenerate-key" \
-H "Authorization: Bearer <admin_api_key>"

よくある質問

Q:ワークベンチでキャッシュヒット率が0%になるのはなぜですか?

A: このメトリクスでは、推論サービスが実行時にキャッシュヒットデータを報告する必要があります。対象の EAS サービスの起動コマンドに --enable-cache-report パラメーターが含まれているか確認してください。このパラメーターがないと、ワークベンチはデータを収集できず、キャッシュヒットが発生していてもキャッシュヒット率は 0% と表示されます。