# 第8章　評価軸の設計

> **ナビゲーション**
>
> * 前の章: [第7章　ベンダー地図](/ja/solutions/part4-procurement/ch07-vendor-landscape.md)
> * 次の章: [第9章　比較の実践](/ja/solutions/part4-procurement/ch09-comparison-practice.md)

***

![感情的な選定を排し「品質・性能・コスト・統合適合性」の4軸で自社に最適なAPIベンダーを論理的に導き出す](/files/whdPP37StURyTLsfUbks)

第7章でベンダーの全体像を把握しました。次のステップは「どのベンダーが自分たちのニーズに合っているか」を判断する評価軸を設計することです。評価軸なしに選んでしまうと、後から「品質が足りなかった」「コストが想定の3倍になった」「統合が難しすぎた」という失敗が起きがちです。この章では、品質・性能・コスト・統合適合性の4つの軸から評価の組み立て方を解説します。

![評価軸なきベンダー選定は「品質不足」「想定の3倍のコスト」「統合難」という致命的な失敗を招く](/files/kV5ZrqVVBzY8SOMxeuC0)

***

## 8.1 品質軸——何をもって「良い翻訳」と言うか

翻訳品質は主観的に見えますが、できる限り客観的な指標で評価する方法が存在します。

### BLEU スコア

**BLEU（Bilingual Evaluation Understudy）** は、機械翻訳の品質を自動的に数値化する指標の代表です。人間が作成した「正解訳（参照訳）」と機械翻訳の出力を比較し、単語や連続した語句（n-gram）がどれだけ一致するかで0〜100のスコアを算出します。

* **利点**：計算が自動で速い・大量のテキストを一括評価できる
* **限界**：同じ意味でも表現が違うと低スコアになる・文脈や流暢さを測れない・言語によって値の解釈が異なる

BLEUはあくまで「機械的な参考値」として使い、最終判断は人間の評価と組み合わせることが重要です。

### COMET スコア

**COMET（Crosslingual Optimized Metric for Evaluation of Translation）** は、BLEUの限界を克服するために開発された新世代の評価指標です。大規模言語モデルを使って翻訳の意味的な正確さ・流暢さ・人間評価との相関を計算します。

人間の評価結果との相関係数がBLEUより高く、近年の学術論文や品質評価では標準的な指標となりつつあります。

### 自動評価指標の使い方と限界

![翻訳品質は主観ではなくデータで測る——BLEUの限界を理解し次世代標準の「COMET」を活用する——BLEU/COMET/TER/人間評価（MQM）の比較表](/files/LDYdG0oowL5SZu6jWVRe)

| 指標        | 評価方式      | 人間評価との相関 | 計算速度    | 利用推奨場面      |
| --------- | --------- | -------- | ------- | ----------- |
| BLEU      | n-gram一致率 | 低〜中      | 高速      | 大量テキストの粗い比較 |
| COMET     | ニューラルモデル  | 高        | 中程度     | 精密比較・ベンダー選定 |
| TER       | 編集距離ベース   | 中        | 高速      | 翻訳後編集量の推定   |
| 人間評価（MQM） | 人間が採点     | 最高       | 低速・高コスト | 最終品質確認      |

### ドメイン適合性テスト

汎用的な翻訳エンジンが、自分たちの業務領域でも通用するかを確認するテストです。医療・法律・技術文書では、一般語と異なる意味を持つ専門用語が多く登場します。

![汎用エンジンが自社の専門領域で通用するかは4ステップの適合性テストで実証する——代表的文書の抽出→API並列投入→専門家評価→スコア比較](/files/WOtlZTWDDwhszXUkWqpo)

実施方法の例：

1. 自社の代表的な文書（50〜100文）を用意する
2. 複数ベンダーのAPIに同一テキストを投入する
3. 翻訳結果を社内の専門家（または外部翻訳者）に評価してもらう
4. スコアと修正箇所数でベンダーを比較する

### 言語ペアカバレッジ

主要言語（英・仏・独・中・日・西など）はほぼすべてのベンダーが対応していますが、希少言語（スワヒリ語・タガログ語・ベンガル語など）になると対応ベンダーが限られます。自社で扱う言語ペアが確実にサポートされているかを事前に確認することが必須です。

### 固有名詞・専門用語対応

製品名・人名・ブランド名が誤訳されると信頼性が損なわれます。用語集（Glossary）機能の有無と使いやすさは、選定の重要ポイントです。

***

## 8.2 性能軸——速さと安定性

いくら品質が高くても、遅かったり頻繁に落ちたりするAPIは使い物になりません。

### レイテンシの測定方法

**レイテンシ**とは、APIにリクエストを送ってからレスポンスが返ってくるまでの時間（遅延）です。

![ユーザー体験を左右するのは平均速度（p50）ではなく最悪ケース（p99）の極端な遅延である——p50/p95/p99の分布図](/files/iHxxtcFl6vmyUzyHStna)

* **p50（中央値）**：全リクエストの50%がこの時間以内に完了。「普段の速さ」
* **p95**：95%のリクエストがこの時間以内。「ほぼ最悪ケース」
* **p99**：99%のリクエストがこの時間以内。「極端な遅延の上限」

ユーザー体験に影響するのは主にp95・p99です。平均値だけで判断すると、たまに極端に遅いケースを見落とします。

### スループット上限（RPM）

\*\*RPM（Requests Per Minute）\*\*とは1分間に送れるリクエスト数の上限です。同時に大量のリクエストを処理する場合（ECサイトの一括翻訳など）、RPM上限を超えると `429 Too Many Requests` エラーが返ります。上限の引き上げが可能か・有料プランで緩和されるかを確認しましょう。

### ストリーミング対応の有無と品質

音声認識（STT）や長文翻訳では、結果が出た部分から順次受け取れる「ストリーミング」対応が重要です。ストリーミングに対応していない場合、全文処理が完了するまで待つ必要があり、応答体感が悪くなります。

### SLA（サービスレベルアグリーメント）の読み方

\*\*SLA（Service Level Agreement）\*\*とは、ベンダーが保証するサービス品質の契約です。主に以下を確認します。

![大量処理時の上限（RPM）とSLA（稼働率保証）を確認し本番環境でのシステムダウンを防ぐ——99.9%保証＝月8.7時間ダウン許容 vs 99.99%保証＝月4.3分ダウン許容](/files/W86epHCALDyuYN4aR0lb)

| 項目          | 内容             | 確認ポイント                            |
| ----------- | -------------- | --------------------------------- |
| 可用性（Uptime） | 月間稼働率の保証値      | 99.9%（月8.7時間ダウン可）vs 99.99%（月4.3分） |
| 補償条件        | SLA未達時のクレジット返還 | どの程度補填されるか                        |
| 計画メンテナンス    | 定期メンテの通知方法     | 事前告知があるか                          |
| サポートレベル     | 障害時の応答時間       | Businessプランで何時間以内か                |

### 障害履歴・稼働率の確認方法

各ベンダーは通常「ステータスページ」（例：`status.deepl.com`）を公開しています。過去の障害履歴・原因・復旧時間が記録されているため、本番導入前に確認することを推奨します。

***

## 8.3 コスト軸——課金モデルの比較

### サービスタイプ別の課金単位

| サービス種別       | 課金単位           | 代表的な価格帯         |
| ------------ | -------------- | --------------- |
| テキスト翻訳       | $/100万文字       | $5〜$80          |
| STT（音声認識）    | $/分            | $0.006〜$0.025   |
| TTS（音声合成）    | $/100万文字       | $4〜$30          |
| 通訳（AIリアルタイム） | $/時間 or $/分    | $0.01〜$0.10/分   |
| TMS/LSP API  | 要見積もり or $/ワード | $0.05〜$0.30/ワード |

※価格は目安であり、為替・プラン・量によって変動します。

### ボリュームディスカウント構造

多くのベンダーは利用量が増えるほど単価が下がる「ボリュームディスカウント」を設けています。比較の際は単純な単価だけでなく、**自社の月間使用量を推定したうえで実効単価（Total / 使用量）を計算**することが重要です。

### 無料枠・トライアルの活用

![無料枠（PoC用）とボリュームディスカウントを組み合わせ実効単価を最適化する——Google Cloud 50万字/月・AWS Translate 200万字/月・DeepL API Free 50万字/月・Azure Translator 200万字/月](/files/npDrqv2hDmaVGEod48eN)

| ベンダー例                    | 無料枠      | 条件       |
| ------------------------ | -------- | -------- |
| Google Cloud Translation | 50万文字/月  | 毎月リセット   |
| AWS Translate            | 200万文字/月 | 初年度のみ    |
| DeepL API Free           | 50万文字/月  | 商用利用制限あり |
| Azure Translator         | 200万文字/月 | 毎月リセット   |

PoC（概念実証：本番導入前の小規模テスト）段階では無料枠の範囲で複数ベンダーを試し、その後有料移行するのが合理的なアプローチです。

### 隠れコスト

見落としがちな費用項目：

* **データ転送費用**：大量テキストをAPIに送受信する際のネットワーク転送コスト（特にクラウドをまたぐ場合）
* **ストレージ費用**：非同期バッチ処理の入出力ファイルをS3などに保管するコスト
* **サポート費用**：Businessレベルのサポートは月額固定費が発生する場合がある
* **カスタムモデル学習費用**：カスタム翻訳モデルのトレーニングに別途費用が発生するケース

### TCO（総所有コスト）の考え方

\*\*TCO（Total Cost of Ownership：総所有コスト）\*\*とは、APIの利用料だけでなく、統合に要するエンジニア工数・運用監視コスト・障害対応コストを含めた「真のコスト」です。

![API利用料は氷山の一角——データ転送費・ストレージ費・サポート費・カスタムモデル学習費・統合運用エンジニア工数を含めたTCO（総所有コスト）で真のコストを評価する](/files/3HU3H6K8Iao3EGYXmzgt)

```
TCO = API使用料 + 開発統合工数 + 運用・監視コスト + 障害対応コスト + 移行コスト
```

安価なAPIでも統合が複雑であれば開発工数が膨らみ、結果としてコストが高くなることがあります。

***

## 8.4 統合適合性軸——ゲートウェイ設計視点からの評価

この軸は、本書の主要テーマである「APIゲートウェイとしての設計」に直結する最も重要な視点です。品質やコストが同水準であれば、統合のしやすさが最終的な選択を決めることが多いです。

![ゲートウェイ設計において最も重要なのは「開発体験」——OpenAPI仕様と非同期対応が統合コストを劇的に下げる——必須要件（Critical）・重要要件（Important）・加点要件（Nice to have）の分類](/files/sWziQSuQ3w5tDaUuSBto)

| 評価項目         | 確認内容                                        | 重要度 |
| ------------ | ------------------------------------------- | --- |
| OpenAPI仕様の提供 | Swagger/OpenAPI 3.x の公式仕様があるか               | ★★★ |
| ドキュメント品質     | サンプルコード・エラーコード一覧が充実しているか                    | ★★★ |
| 非同期対応        | Webhook（プッシュ）対応か、ポーリング（引き取り型）のみか            | ★★★ |
| 認証方式         | API Key / OAuth2 / JWT のどれか・切り替え可能か         | ★★★ |
| レート制限の透明性    | `X-RateLimit-Remaining` 等のヘッダーで残量を通知するか     | ★★  |
| Webhookの信頼性  | リトライポリシーと署名検証（HMAC等）を提供するか                  | ★★  |
| SDK提供状況      | 主要言語（Python・Node.js・Java等）のSDKがあり、メンテされているか | ★★  |
| サンドボックス環境    | 本番とは独立したテスト環境（Sandbox）が提供されているか             | ★★  |
| バージョニングポリシー  | APIのバージョン管理方針・廃止予告期間が明示されているか               | ★   |

**OpenAPI仕様**とは、APIの仕様をYAML/JSONで記述した標準フォーマットです（詳細は第11章で解説）。これがあると、APIdogなどのツールへのインポートが容易になり、テスト・ドキュメント生成・クライアントコード自動生成が格段に効率化されます。

**Webhook**とは、処理が完了した際にベンダー側からシステムに通知を送ってくる仕組みです。ポーリング（定期的に「完了した？」と問い合わせる方式）より効率的で、大量の非同期処理がある場合に重要になります。

![大量の非同期処理には無駄な通信を生むポーリングではなく信頼性の高いWebhookが必須——ポーリング（引き取り型）vs Webhook（プッシュ型）の比較](/files/sd5S0sBaHyNdekqq1Ft7)

***

> **まとめ**：4つの評価軸（品質・性能・コスト・統合適合性）を明確にしてから比較を始めることで、「なんとなく有名だから」という感情的な選定を避け、自社ニーズに合ったベンダーを論理的に選定できるようになります。

![4つの軸は独立していない——安いAPIは開発工数を押し上げるなどシステム全体のトレードオフを見極める——結論：品質やコストが同水準なら「統合のしやすさ（DevEx）」が最終的な勝敗を分ける](/files/NVM1Q7LfFi4PhOppXc2o)

![比較の実践へ進むため無料枠を活用して自社データによるPoC（概念実証）を開始する——次のアクション：専門文書50〜100文抽出・Free Tierアカウント開設・OpenAPI仕様のツール読み込み](/files/iVozqivPsxhDkKUIX2nO)

***

→ [第9章 比較の実践](/ja/solutions/part4-procurement/ch09-comparison-practice.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/part4-procurement/ch08-evaluation-criteria.md?ask=<question>
```

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.