# 第4章 品質ティア——APIの第一級概念として
> **ナビゲーション**
>
> * 前の章: [第3章 言語サービスAPIの分類軸](/ja/solutions/part2-taxonomy/ch03-taxonomy.md)
> * 次の章: [第5章 アーキテクチャ設計](/ja/solutions/part3-architecture.md)
***
***
## 4.1 なぜ品質をAPIの設計に組み込む必要があるか
### 「翻訳APIを叩いた」だけでは何が返ってくるか分からない
翻訳APIを初めて導入したチームがよく陥るのが、次のような状況です。
> 「DeepL APIを呼び出したら翻訳文が返ってきた。これでグローバル展開できる！」
しかし少し立ち止まって考えてみましょう。その翻訳文は、**どんな用途に使えるクオリティ**なのでしょうか？
機械翻訳（MT）は、テキストの意味を大まかに伝えるには十分でも、顧客向けのマーケティング文書や法的拘束力を持つ契約書には使えないことがほとんどです。APIを「叩いた」だけでは、その品質が自分のユースケースに適しているかどうかは分かりません。
### 品質を後付けで考えると何が起きるか
実際にあり得るシナリオを見てみましょう。
**シナリオ A**: あるSaaS企業がサービスを20言語展開しようと、テキスト翻訳APIだけを組み込んだ。ローンチ後、海外ユーザーから「UIの翻訳がおかしい」「製品名が誤訳されている」というクレームが続出。後から人間翻訳者を呼んで修正したが、APIの呼び出しコードは品質を考慮した設計になっておらず、どのテキストをどのレベルで翻訳すべきかの情報が欠落していた。結果、コードの大幅な書き直しが必要になった。
**シナリオ B**: 医療機器メーカーが取扱説明書の翻訳にMT APIを使用した。一部の重要な安全警告が誤訳されたまま出荷され、規制機関から指摘を受けた。認証翻訳の要件を設計時に考慮していなかったためだ。
これらはいずれも、**品質の要件をAPIの設計に先立って定義していなかった**ことが根本原因です。
### 品質ティアをAPIの最上流に置く設計思想
私たちが提唱するのは、翻訳APIを呼び出すときに必ず **品質ティア（Quality Tier）** をパラメータとして明示的に指定するという設計思想です。
```json
POST /v1/translate
{
"text": "This product may cause serious injury if misused.",
"source_lang": "EN",
"target_lang": "JA",
"quality_tier": "expert_in_the_loop" ← 品質ティアを明示的に指定
}
```
品質ティアをAPIの入力仕様に組み込むことで、以下のことが実現します：
* 呼び出し側（アプリ）が品質への意図を明示できる
* 受け取り側（翻訳プラットフォーム）が適切なワークフロー（MT専用・MTPE・AIT・エキスパート検証）を自動的に選択できる
* 調達・コスト・納期が品質ティアに連動して透明化される
***
## 4.2 4つのティアの定義と使い分け
### ティア一覧
第1章で整理した品質グラデーションを、APIの設計パラメータとして定義します。
| ティアID | 名称 | 概要 |
| -------------------- | ---------------- | ---------------------------------------------------- |
| `mt` | 機械翻訳のみ（MT Only） | 即時・最安・品質保証なし |
| `mtpe` | MTポストエディット（MTPE） | MTの出力を人間が確認・修正する（軽微〜完全の幅あり） |
| `ait` | AI翻訳（AIT） | 著者が文書要件をAIに指示し、ターゲット言語の文書を直接生成 |
| `expert_in_the_loop` | エキスパート検証付きAIT | AITで生成した文書を言語専門家がcertification/verificationする最高品質レベル |
***
### `mt`——機械翻訳のみ
**定義**: 機械翻訳エンジンが生成したテキストをそのまま出力する。人間によるチェックや修正は行わない。
**処理の仕組み**:
```
[原文テキスト]
↓
[ニューラル機械翻訳エンジン（NMT）]
↓
[翻訳テキスト（即時出力）]
```
**想定ユースケース**:
* 内容の大意把握（意味が分かればよい）
* 社内の非公式コミュニケーション
* 大量の情報を高速にスキャンする情報収集
**コスト感**: 最安（APIの従量課金のみ。数円〜数十円/1,000文字）
**納期感**: 即時（ミリ秒〜数秒）
**注意点**: 誤訳・不自然な表現・文化的に不適切な表現が含まれる可能性がある。公開用コンテンツや重要な意思決定に使うことは推奨されない。
***
### `mtpe`——MTポストエディット
**定義**: MTの出力を人間が確認・修正するワークフロー。修正の深さに応じて「軽微後編集（Light PE）」と「完全後編集（Full PE）」の2段階があるが、APIのティアとしては同一の `mtpe` として扱い、詳細スコープはオプションパラメータで指定する。
**処理の仕組み**:
```
[原文テキスト]
↓
[ニューラル機械翻訳エンジン]
↓
[MT翻訳テキスト]
↓
[ポストエディター（人間）による確認・修正]
↓
[後編集済みテキスト]
```
**軽微後編集（Light PE）**:
* 明らかな誤り・不自然な表現を最小限の労力で修正
* すべての文を書き直すのではなく、問題箇所のみを修正
* 業界標準（ISO 18587）の「最低限の修正（minimal edits）」に相当
**完全後編集（Full PE）**:
* 原文と訳文の整合性・流暢さ・文化的適切さ・専門用語の正確さを完全に担保
* 結果的に人間翻訳と同等の品質を目指す
* 品質チェック（QA）プロセスを含む
**想定ユースケース**:
* 顧客向けWebサイト・FAQ（Light PE）
* 製品マニュアル・マーケティング資料（Full PE）
* 医療機器の患者向け資料（Full PE）
**コスト感**: 中〜高（MT費用 + 後編集費用。スコープにより MT単体の2〜10倍）
**納期感**: 数時間〜5営業日（後編集スコープと量に依存）
**注意点**: 軽微後編集のスコープは事前に明確に定義すること。「どこまで直すか」があいまいだと後編集者によってバラつきが生じる。
***
### `ait`——AI翻訳
**定義**: 著者が文書要件（対象読者・目的・トーン・長さなど）をAIに指示し、ターゲット言語の文書を直接生成する。原文をそのまま翻訳するのではなく、**多言語コンテンツ生成**として位置づける。
**処理の仕組み**:
```
[著者による文書要件の指示]
（対象読者・目的・長さ・トーン・専門用語制約 etc.）
↓
[LLM（大規模言語モデル）]
↓
[ターゲット言語での文書（直接生成）]
```
**MTPEとの根本的な違い**:
| 観点 | MTPE | AIT |
| ----- | --------- | ----------- |
| 起点 | 原文テキストの翻訳 | 文書要件の指示 |
| プロセス | 翻訳 → 後編集 | 要件定義 → 直接生成 |
| 実施者 | 翻訳者 | 著者自身 |
| 原文の扱い | 必須の入力 | 参照または不要 |
**著者がAITを実施する2つの構造的優位性**:
1. **原文修正の権限がある**: 翻訳者は訳文の範囲でしか作業できないが、著者は原文そのものを変更できる。「この表現は別の言語では伝わりにくい」と気づいたとき、著者はソースを改稿することができる。
2. **文書の背景知識を最も豊かに持っている**: 著者はその文書が生まれた文脈・意図・制約を知っており、AIへの要件指示の精度も生成された文書の評価も、より妥当かつ細やかに行える。
**想定ユースケース**:
* 顧客向けWebコンテンツ・マーケティング文書の多言語展開
* ブログ・SNS・ニュースレターの多言語版生成
* ソフトウェアUIの多言語コピー生成
**コスト感**: 低〜中（LLM API費用のみ。著者の時間コストが主）
**納期感**: 即時〜数時間（著者の要件定義と確認サイクルに依存）
**注意点**: AIT出力の品質は、著者が与える要件指示の質に大きく依存する。プロンプト設計のスキルが成果を左右する。
***
### `expert_in_the_loop`——エキスパート検証付きAIT
**定義**: 著者がAITで生成した文書を、言語専門家（翻訳者・校正者・専門領域の専門家）がcertification/verificationする最高品質レベル。AITの速度と専門家の権威を組み合わせる。
**処理の仕組み**:
```
[著者による文書要件の指示]
↓
[LLM → ターゲット言語文書の生成（AIT）]
↓
[言語専門家によるレビュー・certification/verification]
↓
[必要に応じた著者へのフィードバック・修正サイクル]
↓
[専門家が承認した最終文書]
```
**`mtpe` との違い**:
| 観点 | MTPE | Expert-in-the-Loop |
| ------ | ------------ | ------------------------------- |
| 生成の起点 | NMTエンジンによる翻訳 | LLMによる要件ベース生成（AIT） |
| 専門家の役割 | 訳文の修正・書き直し | 生成文書のcertification/verification |
| 著者の関与 | 低（翻訳者に委任） | 高（著者が要件指示・最終確認） |
**想定ユースケース**:
* 規制対応文書・公的提出物（医療・法律・金融）
* 認証が必要な製品ラベル・安全警告
* 国際展開における法的契約書・規約
* 高リスク領域での顧客向け公式文書
**コスト感**: 高〜最高（LLM費用 + 専門家報酬。用途と専門領域に依存）
**納期感**: 1〜10営業日（専門家のスケジュールと文書量に依存）
**注意点**: 「エキスパート」の要件は用途によって異なる。言語的な正確さだけでなく、法的・医療的・規制的な専門知識が必要な場合もある。証明行為（certification）そのものは専門家が担う。
***
## 4.3 品質・コスト・納期の三角形
### トレードオフの構造
翻訳プロジェクトには常に「品質・コスト・納期」の三角形があります。いずれか一辺を優先すると、他の辺に影響が出ます。
```mermaid
graph LR
Q["🏆 品質
（Quality）"]
C["💰 コスト
（Cost）"]
S["⚡ 納期
（Speed）"]
Q <-->|"高品質・低コスト → 納期が長くなる"| C
Q <-->|"高品質・短納期 → コストが高くなる"| S
C <-->|"低コスト・短納期 → 品質を犠牲にする"| S
```
### ユースケース別の最適ティア選択フロー
以下の意思決定フローで、自分のユースケースに最適なティアを選べます。
```mermaid
flowchart TD
START["🚦 このコンテンツは何に使うか？"]
A["公的機関への提出
規制対応・法的効力が必要"]
B["社外公開コンテンツ
（顧客・市場向け）"]
C["社内用途
情報把握目的"]
D["`**expert_in_the_loop**
エキスパート検証付きAIT一択`"]
E["著者自身が要件を
定義・生成できる"]
F["既存の原文をベースに
修正が必要"]
G["`**ait**
AI翻訳（著者が要件指示）`"]
H["`**mtpe**
MTポストエディット`"]
I["`**mt**
機械翻訳のみ`"]
START --> A & B & C
A --> D
B --> E & F
E --> G
F --> H
C --> I
```
### ビジネス判断としての品質ティア選択
品質ティアの選択は、技術的な決定であると同時に **ビジネスリスクの管理** でもあります。
| リスク種別 | 低品質翻訳が招く可能性 | 推奨ティア |
| ----------- | ------------- | -------------------- |
| **ブランドリスク** | 誤訳による顧客の信頼失墜 | `ait` 以上 |
| **法的リスク** | 不正確な契約・規制書類 | `expert_in_the_loop` |
| **安全リスク** | 誤った使用方法・警告の伝達 | `expert_in_the_loop` |
| **情報リスク** | 社内意思決定への影響は軽微 | `mt` で許容可 |
品質ティアをAPIリクエストの最上流に組み込むことで、これらのビジネスリスクが可視化され、翻訳ワークフロー全体の設計がブレなくなります。
> **設計の原則**: 「後から品質を上げる」より「最初から品質要件を決める」方が、コストも時間も節約できる。
***
> **まとめ**
>
> * 品質ティアはAPIの後付けパラメータではなく、設計の最上流に位置づけるべき第一級概念
> * `mt`・`mtpe`・`ait`・`expert_in_the_loop` の4ティアは、品質・コスト・納期のトレードオフを体系化したもの
> * AITの登場により、著者自身が翻訳主体になる `ait` ティアが新たな主役となった
> * ユースケースのリスク（ブランド・法的・安全・情報）に応じて最適ティアを選ぶことが、ビジネス判断の核心
***
> 次の章: [第5章 アーキテクチャ設計](/ja/solutions/part3-architecture.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/part2-taxonomy/ch04-quality-tiers.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.