# 第5章　5層アーキテクチャ

> **ナビゲーション**
>
> * 前の章: [第4章　品質ティア](/ja/solutions/part2-taxonomy/ch04-quality-tiers.md)
> * 次の章: [第6章　共通スキーマ設計](/ja/solutions/part3-architecture/ch06-common-schema.md)

***

![第5章：言語APIの5層アーキテクチャ——関心の分離によるスケーラブルな言語処理システムの構築](/files/kK3azHROH2O9KEq05pXF)

***

言語APIを単体で使うだけなら、シンプルなHTTPリクエスト1本で済みます。しかし現実のビジネスでは、「機械翻訳の後に人間がレビューする」「音声を文字に起こしてから翻訳する」「翻訳結果をCMSに自動登録する」といった複雑な処理の連鎖が必要になります。この複雑さを整理するために、本章では言語APIを **5層（レイヤー）** に分けて捉えるアーキテクチャモデルを紹介します。

![単体APIの無秩序な連携（Chaotic Integration）vs 関心の分離（Separation of Concerns）——5層構造が拡張性とトラブルシューティングの容易さを実現する](/files/r80bFALidjTEtlt3QsMo)

***

## 5.1 全体レイヤー図の読み方

まず全体像を俯瞰しましょう。表を「下から上へ」順番に読んでください。L1が土台で、L5が最も利用者に近い層です。

|     層    | 名称             | 主要コンポーネント                        |
| :------: | -------------- | -------------------------------- |
| **L5** ▲ | アプリケーション層      | 翻訳メモリ管理、CAT連携、CMS統合、人間レビュー       |
|  **L4**  | ワークフロー・プロジェクト層 | ジョブ管理、担当者アサイン、品質ゲート              |
|  **L3**  | 品質・知識層         | 翻訳メモリ/TM、用語集/Glossary、スタイルガイド、QA |
|  **L2**  | コンポジション層       | STT→翻訳→TTS のパイプライン、非同期ジョブ        |
| **L1** ▼ | プリミティブAPI層     | 翻訳、STT、TTS、OCR、言語検出、NER          |

> ▲ 利用者に近い側 ／ ▼ 基盤となる側（上位層は下位層に依存）

各層の責務を一言でまとめると次のとおりです。

| 層  | 名称             | 一言サマリー               |
| -- | -------------- | -------------------- |
| L1 | プリミティブAPI層     | 最小単位の言語処理を担う「部品」     |
| L2 | コンポジション層       | 部品を繋いで複合パイプラインを作る    |
| L3 | 品質・知識層         | 翻訳の「知識」と「品質ルール」を注入する |
| L4 | ワークフロー・プロジェクト層 | 人間を含む作業フローを管理する      |
| L5 | アプリケーション層      | 実際のビジネスシステムと接続する     |

上位の層は下位の層に依存します。たとえばL4のワークフローはL3の品質チェックを呼び出し、L3はL1の翻訳APIを利用します。この積み重ねが「関心の分離」を実現し、システムを保守しやすく拡張しやすくします。

![L1（土台）からL5（利用者）への積み重ねが、単体のAPIをビジネスシステムへと昇華させる——各層の責務と依存関係](/files/MYqn0O9pPiQwzyNzdvfH)

***

## 5.2 L1 プリミティブAPI層——基本の部品

L1は、化学で言う「原子」に相当します。それ以上分解できない最小単位の言語処理APIの集まりです。

### 主要なプリミティブAPI

| API種別  | 英語名                            | 役割                     |
| ------ | ------------------------------ | ---------------------- |
| 翻訳     | Translation                    | テキストをある言語から別の言語へ変換する   |
| 音声認識   | STT (Speech-to-Text)           | 音声データをテキストに書き起こす       |
| 音声合成   | TTS (Text-to-Speech)           | テキストを音声データに変換する        |
| 光学文字認識 | OCR                            | 画像やPDF中の文字を読み取りテキスト化する |
| 言語検出   | Language Detection             | テキストがどの言語で書かれているかを判定する |
| 固有表現認識 | NER (Named Entity Recognition) | テキスト中の人名・地名・組織名などを抽出する |

![L1は最小単位の言語処理を担う「部品」であり、リソース指向のREST設計に従う——6種のプリミティブAPIとJSONによるシンプルな入出力](/files/Iu59nhcMwoO96y0UYf7g)

### RESTful API設計の基本パターン

L1のAPIは通常、**リソース指向のREST設計**に従います。HTTPメソッド（POST/GET）でリソースへの操作を表現し、JSONでデータをやり取りします。

以下は最もシンプルな翻訳リクエストの例です。

```http
POST /v1/translations
Content-Type: application/json
Authorization: Bearer <YOUR_API_KEY>

{
  "text": "おはようございます",
  "source_language": "ja",
  "target_language": "en"
}
```

レスポンスはシンプルで、翻訳結果と付加情報が返ります。

```json
{
  "translated_text": "Good morning.",
  "source_language": "ja",
  "target_language": "en",
  "detected_language": null
}
```

L1はシンプルである分、単体では「品質の制御」や「複数処理の連携」ができません。そこで上位層が必要になります。

***

## 5.3 L2 コンポジション層——部品を繋ぐパイプライン

\*\*コンポジション（Composition）\*\*とは「組み合わせ」を意味します。L2では、L1の部品を連結して1つの複合サービスを構築します。

### 音声翻訳パイプラインの例

最も代表的な例が「音声翻訳」です。日本語の音声を英語の音声に変換するには、3つのL1 APIを直列に繋ぎます。

```
[音声ファイル (ja)]
      ↓
  STT (音声認識)
      ↓
[テキスト (ja): "本日はお越しいただきありがとうございます"]
      ↓
  翻訳 API
      ↓
[テキスト (en): "Thank you very much for coming today."]
      ↓
  TTS (音声合成)
      ↓
[音声ファイル (en)]
```

このパイプラインをAPIの利用者が毎回自分で組む必要はありません。L2はこのパイプライン全体を1つのエンドポイントとして公開します。

![L2はL1の部品を直列に繋ぎ、複合的な言語サービスを単一のエンドポイントとして提供する——音声翻訳パイプライン（STT→Translation→TTS）の例](/files/Wkf7GGfm8omeLO070p3s)

### 非同期ジョブの仕組み

音声ファイルが長い場合など、処理に数十秒かかることがあります。このような場合、**同期的な応答（リクエストを送って即座に結果を得る）** はタイムアウトリスクがあります。

代わりに**非同期ジョブ**を使います。

1. リクエストを送ると、即座に「ジョブID」が返される
2. 利用者はジョブIDを使って処理状況を\*\*ポーリング（定期的に問い合わせ）\*\*する
3. または処理完了時に指定URLへ**Webhook**通知を受け取る

```json
// ジョブ登録直後のレスポンス
{
  "job_id": "job_abc123",
  "status": "pending",
  "estimated_seconds": 45
}
```

### パイプライン設計の注意点

* **部分失敗への備え**：STTは成功したが翻訳でエラーが出た場合、どこから再試行するかを設計する
* **エラーの伝播**：上流の品質が悪いと下流の結果も悪化する（例：STT精度が低いと翻訳精度も落ちる）
* **タイムアウト設定**：各ステップに個別のタイムアウトを設ける

![長時間処理には非同期ジョブ（ポーリング/Webhook）を用い、部分失敗・エラー伝播・タイムアウトへの備えを設計する](/files/IUuD5fLfEOZGj6OeMiih)

***

## 5.4 L3 品質・知識層——翻訳メモリ・用語集・スタイルガイド

L1とL2だけでは「均質で高品質な翻訳」は実現できません。業界固有の用語や企業独自の文体が反映されないからです。L3はそのための「知識」をAPIに注入する層です。

### 翻訳メモリ（TM: Translation Memory）

過去に翻訳したテキストとその結果をデータベースに蓄積したものです。同じ文や類似した文が再登場したとき、過去の翻訳を再利用できます。

> **メリット**：翻訳コストの削減・一貫性の向上 **例**：製品マニュアルの改訂版で、変更のない文章は前版の翻訳をそのまま再利用

### 用語集（Glossary）

固有名詞・製品名・専門用語の「正解訳」を事前に登録したリストです。翻訳エンジンはこのリストを参照して訳語を統一します。

> **例**：「ダッシュボード」は必ず "Dashboard" と訳し "Panel" と訳さない

### スタイルガイド

翻訳の文体・トーン・表記ルールを定義したドキュメントです。

> **例**：敬体（〜です・ます）か常体（〜だ・である）か、句読点の使い方、英数字の全角・半角統一

![L3は翻訳メモリ（TM）・用語集（Glossary）・スタイルガイドの3つの「知識資産」をTranslation Engineに注入し、均質で高品質な出力を実現する](/files/enavUKLcpRbS9Mlns08z)

### QA（品質保証）ルールの自動チェック

翻訳結果を納品前に自動検査するルールセットです。

* 対訳で数値が一致しているか（原文に "5%" とあれば翻訳にも "5%" があるか）
* タグや変数が維持されているか（`{{user_name}}` が消えていないか）
* 禁止語リストに違反していないか

これらの「知識資産」はAPIリクエスト時にIDで参照します（詳細は第6章のスキーマ設計を参照）。

![納品前にタグ維持・数値一致・禁止語違反を自動検査する「QAルール」が品質を担保する——QA Checklistの自動チェック例](/files/QyYTKOt4P17p6Rax1Ip4)

***

## 5.5 L4 ワークフロー・プロジェクト層——人間を巻き込む設計

機械翻訳だけで完結しない場合、プロの翻訳者や編集者が作業工程に入ります。L4はそのような「**人間ループ（Human-in-the-Loop）**」を管理する層です。

### ジョブ管理フロー

```
依頼受付 → MT生成 → 担当者アサイン → ポストエディット作業 → レビュー → 品質ゲート → 納品
```

各ステップはAPIで操作可能なジョブオブジェクトとして管理されます。

![機械で完結しない工程には、人間の作業をAPIで管理する「Human-in-the-Loop」を組み込む——L1〜L3の自動翻訳処理とプロ翻訳者・編集者によるレビュー工程の統合](/files/OA10UAbhmL7vxo1PH8G8)

### 品質ゲート

**品質ゲート**とは、「一定の品質スコアを満たさない限り次工程へ進まない」という制御機構です。

> **例**：QAスコアが90点未満の場合、自動的にレビュアーへエスカレーション

品質ゲートにより、低品質な成果物が最終ユーザーに届くリスクを下げられます。

### ステータス管理とWebhook通知

各ジョブは `pending → processing → completed` のようなステータスを持ちます（詳細は第6章参照）。ステータスが変化するたびにWebhookで外部システムへ通知することで、担当者への自動メール送信やCMSへの自動登録が実現できます。

![品質ゲート（QAスコア基準）を設け、基準未満の場合は自動で人間にエスカレーションする——ステータス管理とWebhook通知による自動発火](/files/PkTAS6twL4bY1ZH3F1if)

***

## 5.6 L5 アプリケーション層——CMS・CAT・外部システム連携

L5は「実際のビジネスの世界」と言語APIを繋ぐ最上位の層です。エンジニアより、プロダクトマネージャーや翻訳コーディネーターが直接触れる層でもあります。

### CAT（Computer-Aided Translation）ツール連携

CATツールとは、翻訳者の作業を支援するソフトウェアです（例：memoQ、SDL Trados、Wordfast）。翻訳メモリや用語集を活用しながら、人間が効率よく翻訳を行う環境を提供します。

L5のAPIはCATツールと双方向に連携します：CATからジョブを受け取り、完成した翻訳をCATへ返送します。

### CMS（コンテンツ管理システム）連携

WebサイトやECサイトのコンテンツを管理するCMS（例：WordPress、Contentful、Drupal）と連携することで、記事の多言語化を自動化できます。

> **例**：日本語で記事を公開すると、自動的にMT翻訳→軽量ポストエディット→英語版として公開、という一連のフローが走る

### 翻訳発注・請求・プロジェクト管理システムとの統合

翻訳プロジェクトには、翻訳作業だけでなく発注管理・請求処理・進捗報告も伴います。L5のAPIはこれらのビジネスシステム（ERP、会計ソフト、プロジェクト管理ツール）とのデータ連携も担います。

![L5は言語APIと「現実のビジネス（CAT/CMS/ERP）」を双方向に繋ぐ最上位層——PMや翻訳コーディネーターが直接恩恵を受ける](/files/lO2QIGd4UqUGMqMPHbZp)

***

## まとめ

![各層の責務（関心の分離）を理解することが、迅速なトラブルシューティングと堅牢なシステム設計の鍵となる——全層比較表（コアコンポーネント・処理の性質・メインターゲット）](/files/102ZX9KHKcGbCyvq5vEe)

5層アーキテクチャは、シンプルなAPIコールから複雑なビジネスワークフローまでを整理する強力なフレームワークです。どの層に問題があるかを特定することで、トラブルシューティングも容易になります。次章では、これらすべての層を横断して使われる「共通スキーマ」の設計を学びます。

![次のステップ：全層を横断する「共通スキーマ」の設計へ進み、データ構造を標準化する](/files/IuWt2QXbYxf2KeeQHrx4)

***

→ [第6章 共通スキーマ設計](/ja/solutions/part3-architecture/ch06-common-schema.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/part3-architecture/ch05-layered-architecture.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.