# 第11章 ルーティング設計
> **ナビゲーション**
>
> * 前の章: [第10章 なぜゲートウェイが必要か](/ja/solutions/part5-integration/ch10-why-gateway.md)
> * 次の章: [第12章 ゲートウェイAPIの設計](/ja/solutions/part5-integration/ch12-gateway-api.md)
***
前章でゲートウェイの概念と価値を学びました。ゲートウェイの最も重要な仕事は「どのリクエストをどのベンダーに送るか」を決める**ルーティング**です。この章では、ルーティングの判断軸・障害時の対処・コスト最適化の3つのテーマを掘り下げます。
***
## 11.1 ルーティングの4つの軸
ルーティングとは「道案内」です。翻訳リクエストという荷物を、最適なベンダーという目的地へ届けるための仕組みです。その判断に使う軸は主に4つあります。
***
### 軸1：言語ペア
すべてのベンダーがすべての言語ペアを同じ品質でサポートしているわけではありません。
| 言語カテゴリ | 特徴 | 推奨ベンダー傾向 |
| ------------------- | --------------------- | --------------- |
| 日欧語（日→英、英→独など） | DeepLが自然な訳文を生成しやすい | DeepL優先 |
| アジア言語（中→日、韓→英など） | GoogleやAWSが広い学習データを持つ | Google / AWS |
| 希少言語（スワヒリ語・アムハラ語など） | 対応ベンダーが限られる | Google（カバレッジ広め） |
| アラビア語 | 方言差が大きく専門知識が必要な場合も | ドメインによりLSP併用 |
ルーティング設定では「言語ペアごとにデフォルトベンダーを設定し、非対応なら代替ベンダーへ」という設計が基本です。
***
### 軸2：ドメイン
**ドメイン**とは、翻訳対象の専門分野のことです。同じ英語から日本語への翻訳でも、医療文書と一般ニュースでは要求される専門性がまったく異なります。
| ドメイン | 特徴 | 推奨アプローチ |
| --------- | ------------------ | ---------------------------------- |
| 医療・臨床 | 専門用語の正確さが最優先 | AWS Transcribe Medical / 専門LSP API |
| 法律・契約 | 意味の誤りが法的リスクになる | 専門LSP（翻訳会社）のAPI |
| 特許 | 国際特許規則に沿った表現が必要 | 特許専門LSP |
| 一般コンテンツ | 品質よりコスト・スピード優先の場合も | DeepL / Google |
| Eコマース商品説明 | 量が多く品質は中程度でよい | コスト重視でGoogle / AWS |
***
### 軸3：品質ティア
同じ翻訳でも、求められる品質水準は用途によって異なります。\*\*品質ティア（Quality Tier）\*\*として段階を設けると管理しやすくなります。
| ティア | 意味 | 対応するサービス |
| -------------------- | ---------------------------- | ----------------------- |
| `mt` | 機械翻訳のみ（MT Only）。速さ・安さ優先 | DeepL / Google / AWS |
| `mtpe` | MTポストエディット。機械翻訳後に人間が修正 | TMS経由でLSP |
| `ait` | AI翻訳（AIT）。著者が文書要件をAIに指示し直接生成 | LLM系APIまたはAIT対応TMS |
| `expert_in_the_loop` | エキスパート検証付きAIT。言語専門家が認証・検証 | LSP API / TMS + 専門家レビュー |
リクエストに `"quality_tier": "mt"` と指定すれば最安・最速ベンダーへ、`"quality_tier": "expert_in_the_loop"` であれば専門家レビューを含むTMS/LSPへ——という分岐が自動で行われます。
***
### 軸4：コスト
コストも重要な判断軸です。同等品質のベンダーが複数ある場合、コストの低いほうへルーティングします。また、月次予算に上限を設ける「予算キャップ」機能と組み合わせることで、想定外の課金を防げます。
* **コスト優先モード**：品質要件を満たす中で最もコストの低いベンダーへ
* **クオリティ優先モード**：コストより品質スコアを優先して選択
***
### ルーティング設定ファイルの例
ルーティングロジックは、設定ファイル（JSON形式）として外部化しておくと、コードを変更せずにルールを更新できます。
```json
{
"routing_rules": [
{
"name": "医療ドメイン優先ルール",
"conditions": {
"domain": "medical"
},
"primary_vendor": "aws_transcribe_medical",
"fallback_vendors": ["deepl", "google_translate"]
},
{
"name": "希少言語ルール",
"conditions": {
"target_lang": ["sw", "am", "yo"]
},
"primary_vendor": "google_translate",
"fallback_vendors": ["aws_translate"]
},
{
"name": "エキスパート検証ルール",
"conditions": {
"quality_tier": "expert_in_the_loop"
},
"primary_vendor": "lsp_api_primary",
"fallback_vendors": ["lsp_api_secondary"]
},
{
"name": "デフォルトルール（日欧語・一般）",
"conditions": {},
"primary_vendor": "deepl",
"fallback_vendors": ["google_translate", "aws_translate"],
"cost_mode": "quality_first"
}
]
}
```
条件に一致するルールを上から順に評価し、最初にマッチしたルールを適用します（**ファーストマッチ方式**）。
***
## 11.2 フォールバック戦略——障害時の自動切替
### プライマリ・セカンダリ・ターシャリの3段構え
フォールバック（Fallback）は、障害時に自動的に代替ベンダーへ切り替える仕組みです。本番システムでは最低3段階の構成を設けるのが基本です。
```mermaid
flowchart LR
A[リクエスト受信]
B[プライマリ: DeepL]
C[セカンダリ: Google]
D[ターシャリ: AWS]
E[レスポンス返却]
F[レスポンス返却]
G["レスポンス返却
※失敗時はエラー返却"]
A --> B
B -->|成功| E
B -->|失敗| C
C -->|成功| F
C -->|失敗| D
D --> G
```
### フォールバックのトリガー条件
フォールバックはどのような状況で発動するのでしょうか。主なトリガーは以下の3種類です。
| トリガー | 説明 | 例 |
| ------------ | ------------------ | ----------------- |
| **タイムアウト** | 指定時間内に応答がない | 3秒以内に返答がなければ次へ |
| **エラーレート超過** | 直近N件中のエラー率が閾値を超えた | 直近10件中3件以上失敗で切替 |
| **レート制限超過** | ベンダーのAPI呼び出し上限に達した | HTTP 429が返ってきたら次へ |
### サーキットブレーカーパターン
\*\*サーキットブレーカー（Circuit Breaker）\*\*は、電気回路のブレーカーになぞらえた設計パターンです。電気のブレーカーは「過電流が流れたら回路を切断して機器を守る」ものですが、ソフトウェアのサーキットブレーカーは「障害が頻発するベンダーへの接続を一時的に遮断して、無駄なリクエストを送り続けないようにする」仕組みです。
3つの状態があります。
```mermaid
flowchart TD
A["🟢 Closed（通常）
エラーが少ない。普通にリクエストを転送する。"]
B["🔴 Open（遮断）
ベンダーへの接続を即時遮断。リクエストは次のベンダーへ。"]
C["🟡 Half-Open（試験）
少量のリクエストだけ試しに送ってみる。"]
A -->|エラー率が閾値超過| B
B -->|一定時間経過後| C
C -->|成功| A
C -->|失敗| B
```
このパターンにより、障害中のベンダーへの無駄な呼び出しを排除し、システム全体の応答速度を保てます。
### フォールバック時のログとアラート
フォールバックが発動した事実は必ず記録・通知すべきです。「気づかないうちにセカンダリベンダーで動き続け、コストが2倍になっていた」という事態を防ぐためです。
```json
{
"event": "fallback_triggered",
"timestamp": "2026-04-11T09:23:45Z",
"from_vendor": "deepl",
"to_vendor": "google_translate",
"trigger_reason": "timeout",
"request_id": "req_abc123",
"alert_sent": true
}
```
***
## 11.3 コスト最適化ルーティング
### リクエスト特性に応じたコスト計算
コスト最適化ルーティングでは、リクエスト送信前に各ベンダーの見積もりコストを計算し、品質要件を満たす中で最安を選びます。
主な特性とコストの関係：
| リクエスト特性 | コストへの影響 |
| ------- | --------------------------------------------- |
| 文字数 | 多いほど高い（文字単価課金のため） |
| 緊急度 | 緊急モードは高品質（高コスト）ベンダー固定 |
| 品質ティア | expert\_in\_the\_loop > ait > mtpe > mt の順に高い |
| 言語ペア | 希少言語ほどコストが高い傾向 |
### 月次コスト上限の管理
ゲートウェイには月次コスト上限（バジェットキャップ）を設定できます。設定例：
```json
{
"budget": {
"monthly_limit_usd": 5000,
"alert_threshold_percent": 80,
"hard_cap": true
},
"per_vendor_limits": {
"deepl": 2000,
"google_translate": 2000,
"aws_translate": 1000
}
}
```
`hard_cap: true` の場合、上限に達すると新規リクエストを受け付けなくなります（エラーを返す）。`hard_cap: false` なら警告だけ出して処理は続行します。ビジネス要件に応じて選択します。
### キャッシュによるコスト削減
同じテキストを何度も翻訳するのは無駄です。**翻訳キャッシュ**を導入することで、一度翻訳した結果を再利用できます。
```mermaid
flowchart TD
A[リクエスト受信]
B{キャッシュ確認}
C["キャッシュから返却
（コスト 0）"]
D[ベンダーAPIへ転送]
E[結果をキャッシュに保存]
F[レスポンス返却]
A --> B
B -->|ヒット| C
B -->|ミス| D
D --> E
E --> F
```
キャッシュのキーは「ソーステキストのハッシュ値 + 言語ペア + ドメイン + 品質ティア」の組み合わせです。テキストが少し変わっただけでキャッシュミスになるため、完全一致キャッシュが基本です。実際の運用ではキャッシュのTTL（有効期間）を設定し、古い翻訳を使い続けないよう管理します。
***
次の第12章では、ゲートウェイが外部に公開する「統一API」の設計仕様を具体的に定義していきます。
***
→ [第12章 ゲートウェイAPIの設計](/ja/solutions/part5-integration/ch12-gateway-api.md)
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://translationlab.gitbook.io/ja/solutions/part5-integration/ch11-routing.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.