---
sidebar_position: 1
_i18n_hash: be40481b428c406d4fdaf208c202a926
---
# AIルーター

AIルーターは、AIゲートウェイのグループに対して安定したAIエンドポイントを提供します。リクエストを構成されたゲートウェイルートを通してルーティングし、同じ層内でトラフィックを重みで分散させ、再試行可能な失敗が発生したときに次の層にフォールバックします。

次のような場合に使用します：

- アプリケーション用に1つのエンドポイントを持ちたいとき（特定のAIプロバイダーをハードコーディングせずに）。
- 複数のゲートウェイ間での重みによるトラフィック分割。
- 障害が発生したりレート制限がかかったときに、プライマリプロバイダーからバックアッププロバイダーへのフォールバック。
- ウェイトを変更して徐々にトラフィックを移動できる移行パス。

## AIゲートウェイとの関係

AIゲートウェイは、プロバイダーの認証情報、カスタムベースURL、モデル価格、クオータアラート、ゲートウェイログを保存する単位として機能します。AIルーターはそれを置き換えません。

AIルーターは、どのゲートウェイルートにリクエストを送信するかを決定するだけです。

実行フローは次のとおりです：

1. アプリケーションがAIルーターのエンドポイントを呼び出します。
2. AIルーターがワークスペースIDとルーターIDでルーターを見つけます。
3. AIルーターが第1層からリクエストを受け取るための資格のあるゲートウェイルートを選択します。
4. 選択されたAIゲートウェイがリクエストを上流AIプロバイダーに送信します。
5. 試行が成功した場合は、AIルーターがその応答を返します。
6. 再試行可能なエラーで試行が失敗した場合、AIルーターは同じ層の別のルートを試み、その後次の層を試みます。

## 前提条件

ルートを追加する前に、最低1つのAIゲートウェイを作成し、モデルAPIキーを保存します。キーが保存されていないゲートウェイは、AIルーターのルートピッカーに表示されません。

実行時リクエストには天津APIキーがまだ必要です：

- OpenAI互換エンドポイントの場合、`Authorization: Bearer <YOUR_TIANJI_API_KEY>`を送信してください。
- Anthropic Messagesエンドポイントの場合、`x-api-key: <YOUR_TIANJI_API_KEY>`を送信してください。

天津が呼び出し元APIキーを確認し、上流のリクエストにストアされたAIゲートウェイプロバイダーキーを使用します。

## ルーターの作成

1. 天津のサイドバーで**AIルーター**を開きます。
2. **AIルーターを追加**をクリックします。
3. ルーター名を入力します。
4. ルーターが実行時のトラフィックを受け入れる場合は、**有効**の設定をオンにします。
5. ルーターを保存します。

ルーターが作成されたら、**ルート**タブを開いて層とゲートウェイルートを設定します。

## 層

層はフォールバックレベルです。

リクエストは常に第1層から開始します。再試行可能な失敗が発生した場合、AIルーターはその層の資格のあるルートを試し続けます。層内のすべての資格のあるルートが失敗した場合、AIルーターは次の層に移動します。

複数の層を使用して、厳格なフォールバック順序を設定する場合に使用します。

例：

| 層 | ルート | 意味 |
| --- | --- | --- |
| 層 1 | OpenAIプライマリ、OpenRouterプライマリ | 通常の製品トラフィック |
| 層 2 | DeepSeekバックアップ | プライマリプロバイダーが失敗した後のバックアップ |
| 層 3 | カスタム内部モデル | 最終手段のフォールバック |

層をドラッグして順序を変更します。上位の層が最初に試行されます。

## 層内の重み

同じ層のルートは固定された順序を持ちません。彼らは重みによってトラフィックを共有します。

例：

| ルート | 重み | 約暇な初回試行シェア |
| --- | ---: | ---: |
| ゲートウェイA | 80 | 80% |
| ゲートウェイB | 20 | 20% |

これは以下の場合に役立ちます：

- プロバイダー間のランダムなトラフィック分割。
- 一つのプロバイダーから別のプロバイダーへの漸進的な移行。
- 新しいゲートウェイの少量のトラフィックでの試行（カナリ）。

厳密な順序が必要な場合は、同じ層ではなく異なる層にルートを置いてください。

## ゲートウェイルートの追加

**ルート**タブで：

1. 層内で**ゲートウェイを追加**をクリックします。
2. 既存のAIゲートウェイを選択します。
3. このルートのプロバイダーモードを選択します。
4. ルートオプションを設定します。
5. 保存します。

あとでルートカードからルートを編集または削除できます。

### プロバイダー

プロバイダーは、選択したAIゲートウェイがどのようにルートのために呼び出されるかを制御します。セットアップに一致する場合、同じAIゲートウェイを異なるプロバイダーモードで異なるルートで使用することができます。

サポートされているプロバイダー値：

- `openai`
- `deepseek`
- `anthropic`
- `openrouter`
- `custom`

`custom`の場合、AIルーターは選択されたAIゲートウェイに保存されたカスタムモデル設定（カスタムベースURLやカスタムモデル名など）を使用します。

### 重み

重みは、同じ層内でのルート間でのトラフィックの分散を制御します。重みが高いほど、そのルートが最初に試行される傾向があります。

デフォルト：`100`.

### モデルオーバーライド

モデルオーバーライドは任意です。

設定すると、AIルーターは選択したゲートウェイルートにリクエストを送信する前に、リクエストの`model`をこの値に置き換えます。アプリケーションリクエストがモデルを決定する場合は空白にしてください。

### タイムアウト

タイムアウトは、1回のゲートウェイ試行の最大時間です。

デフォルト：`30000ms`.

試行がタイムアウトした場合、AIルーターはそれを再試行可能として扱い、次の資格のあるルートを試みることができます。

### 再試行可能なステータスコード

AIルーターは、ネットワークエラー、タイムアウト、およびこれらのステータスコードを常に再試行可能として扱います：

- `429`
- `500`
- `502`
- `503`
- `504`

**再試行可能なステータスコード**を使用して、ルートに対してさらにステータスコードを追加できます。たとえば、プロバイダーがしばしばHTTPレスポンスとしてリクエストタイムアウトを報告する場合は、`408`を追加できます。

`400`や`401`などのバリデーションエラーには注意してください。これらは通常、リクエストまたはキーに問題があることを意味し、別のプロバイダーでの再試行は実際の問題を隠す可能性があります。

## ログ

**ログ**タブは、ルーターの実行時試行を表示します：

- ステータス：`成功`、`失敗`、または`部分`。
- プロトコル：一致するリクエストプロトコル。
- 試行回数：試行されたゲートウェイルートの数。
- 最終ゲートウェイ：最終結果を生成したゲートウェイ。
- 最終ゲートウェイログ：リンクされたAIゲートウェイログID。
- 時間。

ルーターログを使用してフェイルオーバー動作を理解します。リンクされたAIゲートウェイログを使用して、トークン使用、上流モデルの詳細、コスト、およびプロバイダーの応答データを調査します。