# 第10章　なぜゲートウェイが必要か

> **ナビゲーション**
>
> * 前の章: [第9章　比較の実践](/ja/solutions/part4-procurement/ch09-comparison-practice.md)
> * 次の章: [第11章　ルーティング設計](/ja/solutions/part5-integration/ch11-routing.md)

***

![【結論】複数ベンダーのAPI活用には密結合の連鎖を断ち切る「ゲートウェイ（抽象化レイヤー）」の導入が不可欠である——密結合の混乱状態 vs ゲートウェイによる整理された接続の対比](/files/Y4q8tAOoelifXS98hTJk)

Part4では「どのベンダーを選ぶか」という調達・比較の話をしました。しかし実際にシステムを構築するとなると、次の問いが待っています。「複数のベンダーを、どうやってひとつのアプリケーションから使うのか？」

この章では、その答えとなる\*\*ゲートウェイ（抽象化レイヤー）\*\*という考え方を解説します。

***

## 10.1 複数ベンダーを直接叩くことの問題

「DeepLとGoogle翻訳とAWSを使い分けたい」——これは合理的な判断です。しかし、アプリケーションが各ベンダーのAPIに直接接続しようとすると、たちまちいくつかの深刻な問題が浮かび上がります。

![複数ベンダーへの直接接続は開発・運用・ビジネスの各側面に4つの致命的な欠陥をもたらす——API差異の吸収コスト・障害の連鎖・コストの不透明化・改修リスク](/files/USuJoqhzDQzV1g6gR7Vr)

### 問題1：APIの形式・認証・エラーコードがベンダーごとに異なる

各ベンダーはそれぞれ独自のAPI仕様を持っています。DeepLは `source_lang` / `target_lang` というパラメータ名を使いますが、Google翻訳では `source` / `target` です。認証方式もベンダーによってAPIキーをヘッダーに入れる方法、クエリパラメータに入れる方法、OAuthトークンを使う方法とばらばらです。エラーが起きたときのレスポンス形式も統一されていません。

アプリケーション側は、ベンダーの数だけ「翻訳」という同じ仕事のための異なるコードを書く必要があります。

### 問題2：ベンダー障害でアプリが止まる

DeepLのサービスが一時停止したとき、DeepLに直結したアプリはそのままエラーを返すしかありません。「DeepLがダウンしていたらGoogle翻訳に切り替える」という処理をアプリ側に書くことはできますが、ベンダーが増えるほどその条件分岐は複雑になります。

### 問題3：コスト管理が分散・不透明になる

ベンダーAの請求書はベンダーAのダッシュボードで、ベンダーBの請求書はベンダーBのダッシュボードで——というように、コストの全体像を把握するには複数のサービスを横断して確認しなければなりません。「今月どれだけ使ったか」「どのサービスが一番高いか」という問いに即座に答えられない状態は、調達判断を難しくします。

### 問題4：ベンダー乗り換え時にアプリを全面改修しなければならない

より良いベンダーが登場したとき、あるいは契約上の理由でベンダーを変更するとき、各ベンダーに直結したアプリはその接続コードをすべて書き直す必要があります。ベンダーのAPIの変更（仕様変更・廃止）にも同様に対応を迫られます。

### これらを「密結合」と呼ぶ

上記の問題をまとめると、アプリケーションが特定のベンダーに\*\*密結合（tightly coupled）\*\*している状態です。密結合とは「部品Aが部品Bの内部仕様に強く依存している状態」のことです。ベンダーが変わればアプリも変わる、ベンダーが壊れればアプリも壊れる——このような脆弱な設計を避けるための答えが、次節のゲートウェイです。

![アプリケーションが各ベンダーに直接接続する「密結合（Tightly Coupled）」はシステム全体の脆弱性を生む——内部仕様への強依存・ベンダーが変わればアプリも変わる](/files/OLvMcOXqe3qXrOwjUcgY)

***

## 10.2 抽象化レイヤーがもたらす価値

### ゲートウェイの概念

\*\*ゲートウェイ（Gateway）\*\*とは、クライアント（アプリケーション）とバックエンド（各ベンダーAPI）の間に置く中継役のシステムです。\*\*抽象化レイヤー（Abstraction Layer）\*\*とも呼ばれ、「複雑な内部構造を外側からは見えないように包み隠す」役割を果たします。

![クライアントとベンダーの間に「抽象化レイヤー」を配置し複雑な内部構造を完全に隠蔽する——単一の統一インターフェース → ゲートウェイ（Routing/Normalization）→ 各ベンダー専用の通信](/files/ZybdlhjfRt3y3iiGD0lp)

構造を図で示すと次のようになります。

```mermaid
flowchart TD
    A["🖥️ クライアントアプリ<br/>（翻訳APIを呼び出したいだけ）"]
    B["⚙️ ゲートウェイ<br/>ルーティング／正規化（形式変換）<br/>認証管理／障害時フォールバック／コスト集計"]
    C["DeepL API"]
    D["Google API"]
    E["AWS API"]

    A -->|統一された1つのAPI| B
    B --> C
    B --> D
    B --> E
```

クライアントアプリはゲートウェイだけを知っていれば十分です。どのベンダーが裏で動いているかを気にする必要はありません。

### ゲートウェイがもたらす4つの価値

**1. ベンダーロックイン回避**

「ベンダーロックイン」とは、特定ベンダーへの依存度が高くなりすぎて乗り換えが困難になる状態です。ゲートウェイを挟むことで、ベンダーを変更・追加・削除してもアプリ側のコードは一切変更不要になります。

**2. 障害時の自動フォールバック**

フォールバック（Fallback）とは「主要な手段が失敗したときに代替手段に切り替えること」です。ゲートウェイはDeepLのエラーを検知した瞬間にGoogle翻訳へ自動的に切り替えることができます。アプリはエラーを意識せずにすみます。

![ゲートウェイは特定のベンダーへの依存（ロックイン）を排除しシステムの耐障害性を飛躍させる——ベンダーロックイン回避（Code Change: 0）と障害時の自動切り替え（フォールバック）](/files/artS9j4dhDOnNdoCuHGx)

**3. コスト一元管理**

すべての翻訳リクエストがゲートウェイを通るため、「何文字翻訳したか」「どのベンダーをいくら使ったか」を一箇所で集計できます。月次レポートも、予算超過アラートも、ゲートウェイが一手に担います。

**4. 開発者体験（DX）の向上**

DX（Developer Experience）とは開発者にとっての使いやすさのことです。ゲートウェイが統一されたAPIを提供することで、アプリ開発者は「DeepLの認証方式は何か」「AWSのエラーコード400は何を意味するか」を調べる必要がなくなります。開発スピードが上がり、ミスも減ります。

![すべての通信を中央集約することでコストの完全な可視化と開発者体験（DX）の劇的な向上を実現する——コスト一元管理ダッシュボードと Before/After DX向上の対比](/files/MkcsrtJC2LrfFp8HGgTm)

***

## 10.3 ゲートウェイの責務と境界

ゲートウェイが万能に見えてきたかもしれません。しかし、何でもゲートウェイに詰め込むと今度はゲートウェイ自体が複雑化します。「何をやらせて、何をやらせないか」を明確にすることが設計の要です。

![ゲートウェイの肥大化を防ぐためマイクロサービス原則に基づき「担う責務」と「担わない責務」の境界を厳格に定義する——やること（ルーティング・正規化・認証管理・ログ収集）とやらないこと（翻訳・ビジネスロジック・ユーザー管理）](/files/u2mLT0MmMoOx75z0E5l2)

### ゲートウェイがやること

| 責務         | 説明                                       |
| ---------- | ---------------------------------------- |
| **ルーティング** | リクエストの内容（言語ペア・ドメイン・品質要件）に応じて最適なベンダーへ転送する |
| **正規化**    | 各ベンダーの異なるリクエスト形式・レスポンス形式を統一形式に変換する       |
| **認証管理**   | 各ベンダーのAPIキーを安全に保管し、リクエストに付与する            |
| **レート制限**  | ベンダーのAPI呼び出し上限を超えないよう流量を制御する             |
| **ログ収集**   | リクエスト・レスポンスの内容と結果を記録する                   |
| **コスト集計**  | 使用量と費用をベンダー別・サービス別に集計する                  |

### ゲートウェイがやらないこと

| 担わない責務       | 理由                                    |
| ------------ | ------------------------------------- |
| **翻訳そのもの**   | 翻訳はベンダーの仕事。ゲートウェイは橋渡しに徹する             |
| **ビジネスロジック** | 「この案件の翻訳は必ず人間がレビューする」などの業務ルールはアプリ側に置く |
| **ユーザー管理**   | ログイン・権限管理はアプリケーション側の責任領域              |

### マイクロサービスアーキテクチャとの関係

ゲートウェイの考え方は、現代のシステム設計の主流である**マイクロサービスアーキテクチャ**と自然に馴染みます。マイクロサービスとは「システムを小さな独立したサービスの集まりとして構築する設計方針」です。ゲートウェイはその中の「APIゲートウェイ」というロールとして広く採用されています。

次の第11章では、ゲートウェイの中核機能である「ルーティング」の設計を詳しく見ていきます。どのリクエストをどのベンダーに送るか——その判断ロジックを組み立てる方法を学びます。

![【次のアクション】「どのリクエストをどのベンダーに送るか」を決定するルーティングロジックの設計に着手する——ToDo1: リクエスト内容（言語ペア・ドメイン・品質要件）の明確な定義、ToDo2: 要件に基づく最適なベンダーの動的選択ルールの策定](/files/sOAtF0KZHI0U05TCPu1G)

***

→ [第11章 ルーティング設計](/ja/solutions/part5-integration/ch11-routing.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/ch10-why-gateway.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.