> ## Documentation Index
> Fetch the complete documentation index at: https://docs.apiyi.com/llms.txt
> Use this file to discover all available pages before exploring further.

# 公式リレーとリバースエンジニアリング API の違いとは？

> APIYIはデフォルトで公式リレーです。安定性、プロトコル互換性、キャッシュ、同時実行数、長期的な持続可能性の観点から公式リレーとリバースエンジニアリング APIを比較し、Claude_Reverse、Codex_Reverse、Gemini_Reverse、公式リレーグループの中から選択する方法を解説します。

## 簡単な回答

**公式リレー**とは、ベンダーの公式 API または公式クラウドマーケットプレイスを通じて転送されるリソースを意味します。\*\*リバースエンジニアリング（リバース）\*\*とは、非公式インターフェースを通じて取得されるアクセスを意味します。どちらの経路でも同じモデルを呼び出す場合、単一ターンの回答は非常に近いものになる可能性があります。実際の違いは、**安定性、プロトコル互換性、機能の完全性、キャッシュ効率、同時実行数、長期的な持続可能性**にあります。

* **APIYIはデフォルトで公式リレーです。** リバースグループは、個人学習、コスト重視のワークロード、重要度の低いタスク向けの補完的な選択肢です。
* 本番ワークロード、コーディングエージェント、エンタープライズ顧客には、公式リレーを推奨します。
* 個人学習、シンプルなチャット／翻訳／要約、コスト重視のワークロードには、リバースグループを利用できます。
* APIYIには現在、テキスト／コーディング向けのリバースグループが正確に3つあります：`Claude_Reverse`、`Codex_Reverse`、`Gemini_Reverse`。その他のベンダーのテキストモデルでは、デフォルトで公式リレーの`Default`／`SVIP`グループが使用されます。
* 画像`-all`／`-vip`モデルは独立したリバース系統で、主に`Default`によって提供されます。URL出力が必要な一部のモデルでは`image2_OSS`が使用されます。正確なマッピングについてはコンソールを確認してください。これらは上記3つのグループには含まれません。
* APIYIは、グループ名とドキュメントでソースを表示します。リバースグループが公式の直接接続として提示されることはありません。

> [!NOTE]
>
> これらは典型的なパターンであり、すべての公式リレーチャネルがすべてのリバースチャネルより優れていると主張するものではありません。公式リレーでもベンダーのキャパシティ制限に直面することがあり、高品質なリソースプールを持つリバースチャネルのほうが、一部のワークロードでは一時的に速度、同時実行数、または安定性において優れる場合があります。具体的なチャネル、時間帯、そしてご自身のテスト結果に基づいて判断してください。

この記事では、特定の1つのモデルではなく、APIYIのグループ全般について説明します。モデルレベルの違いについては、モデルのドキュメントを確認し、ご自身でテストを実行してください。

## APIYIの公式リレーと逆引きグループ

**グループ**と**モデル**を分けて考えてください。グループは token 上のチャネルであり、モデルはリクエスト内の `model` フィールドです。APIYIでは、グループをソースとユースケースの整理に使用していますが、一般的なグループには公式リレーと逆引き画像モデルの両方が含まれる場合があります。

**APIYIはデフォルトで公式リレーです。** 主に公式リレーで構成されるグループには、`Default`、`SVIP`、`ClaudeCode`、`Claude_Enterprise`、`CodexResponses`、`image2Enterprise`、`NB-Enterprise`に加えて、動画グループの`SeeDance2`と`Wan&HappyHorse`があります。全リスト、割引、モデルの対応状況については、[グループ](https://docs.apiyi.com/ja/groups.md)を参照してください。

### 逆引きグループ（補足）

| 逆引きグループ | 対応範囲 | 倍率 | 最適な用途 |
| - | - | - | - |
| `Claude_Reverse` | 24個のClaudeモデル。`claude-fable-5-2`や`claude-haiku-5-5`などの新しいリリースを除く | 0.5 | 個人学習、非本番環境 |
| `Codex_Reverse` | `gpt-5.6-*`、`gpt-6-*`、`gpt-6.1-*`を含む9個のモデル | 0.5 | コスト重視のCodex、非本番環境 |
| `Gemini_Reverse` | Gemini 2.5から3.8までの11個のモデル。Gemini 4を除く | 0.5 | Gemini CLI、学習、非本番環境 |

逆引きグループは補足的なものであり、公式リレーと同じSLA、同時実行数、機能の完全性を保証するものではありません。

> [!NOTE]
>
> `Default` / `SVIP` は主に公式リレーですが、`gpt-image-2-all`、`gpt-image-2.6-all`、および`-vip`シリーズなどの逆引き画像モデルも含まれています。グループ名だけでなく、グループとモデルの両方を確認してください。

## 中核的な違い：モデルの知能だけではない

### 安定性とパフォーマンス

| 項目 | 公式リレー | リバース | 事業への影響 |
| - | - | - | - |
| モデルの動作 | ネイティブで一貫性がある | 概ね近いが、時折差異がある | 単一ターンの回答では通常、大きな違いはない |
| モデルの真正性 | 検証可能な提供元 | サプライヤーの透明性に依存 | 固定テストセットで検証する |
| 初回トークン | 低く予測可能 | プロキシやキューが追加される場合がある | リアルタイムおよびストリーミングのUXに影響する |
| 全体的な速度 | 公式側の負荷の影響を受ける | リソースプールによって変動する | バッチ処理用にリトライとタイムアウトの余裕を確保する |
| 同時実行数とピーク | RPM / TPM またはクォータが明示されている | アカウントプールとスケジューリングに依存 | ピーク時に429やキュー待ちが発生しやすい |
| キャッシュ | 公式のキャッシュ機構を完全に利用できる | キャッシュ制御パラメータが通過しない場合がある | 長い会話や固定プレフィックスのコストが高くなる |

### プロトコルと機能

| 項目 | 公式リレー | リバース | 事業への影響 |
| - | - | - | - |
| パラメータ互換性 | 公式のパラメータと構造に完全対応 | 一部のパラメータが互換性を持たない、または無視される場合がある | 複雑な呼び出しでは回帰テストを実施する |
| ストリーミング | ネイティブで標準化されている | 通常は対応しているが、バッファリングや形式の違いが生じる可能性がある | 初回トークンのUXとクライアントのタイムアウトを調整する |
| ツール呼び出し / MCP | ネイティブで信頼性が高い | 構造や順序に問題が生じる可能性が高い | エージェントタスクの成功率が低下する |
| 構造化JSON | 公式機能によってスキーマが保証される | スキーマが厳密に適用されない場合がある | 下流のパース処理で許容性が必要になる |
| マルチモーダル | 公式の完全なサポート | 画像、音声、動画が利用できない場合がある | 少量のトラフィックでマルチモーダルワークロードを検証する |
| コンテキスト長 | 制約が明確な公式の上限 | リバースチェーンによって制限される場合がある | 長いドキュメントと会話で負荷テストを実施する |
| 思考 / 推論の制御 | 公式の推論パラメータとレスポンス形式 | 完全には再現できない場合がある | 推論バジェットとチェーン処理に影響する |
| 使用量とエラーコード | 公式の計測と明確なエラー種別 | 推定値になったり、誤ってマッピングされたりする場合がある | 課金の照合とリトライに許容性が必要になる |

### バージョン、コンプライアンス、持続可能性

| 項目 | 公式リレー | リバース | 事業への影響 |
| - | - | - | - |
| モデルバージョンの更新 | 公式のライフサイクルに従う | 遅延したり、通知なしに変更されたりする場合がある | 固定したバージョン用のロールバック計画を維持する |
| SLAとトラブルシューティング | 公式のサポートチャネル | リバース提供元のサポートに依存 | エンタープライズでは保証を重視すべきである |
| リソースとリスク管理 | コンプライアンスに沿って利用する場合は比較的管理されている | 上流のアカウントプール、リスク管理、インターフェース変更に依存 | 重要なワークロード用にバックアップチャネルを確保する |
| 商用コンプライアンス | ベンダーの商用API規約の対象となる | ベンダーの公式API規約の対象外となる | エンタープライズで本番利用する前にコンプライアンスを評価する |
| 価格と長期的なコスト | 透明性があり、調達割引が可能な場合がある | より安価な場合があるが、隠れた運用コストが高い | 単価だけでなく総コストを計算する |
| 長期的な持続可能性 | 比較的高い | 非公式リンクの利用可能性に依存 | 長期運用するプロジェクトでは公式リレーを優先する |

> [!NOTE]
>
> リバースリソースは、ベンダーの公式な商用API規約の対象外です。この記事は技術的な説明であり、法的助言ではありません。各自のエンタープライズ調達および本番利用について、コンプライアンスを評価してください。

## 単一ターンの品質が近い場合でも、エージェントが公式リレーを優先すべき理由

コーディングエージェントの成功率は、単一ターンの回答だけで決まるものではありません。不正なツール呼び出し引数が1つあるだけでも、JSONフィールドが1つ欠落しているだけでも、またはストリームが1回中断するだけでも、タスク全体が失敗して再起動される可能性があります。単一ターンの品質が同じように見えても、複数ターンの成功率には差が生じることがあります。

エージェントのワークロードでは、次の3つの問題が増幅されます。

* **ツール呼び出しの構造**: 逆引きチェーンによってパラメータが書き換えられたり無視されたりすることで、誤った関数名、引数の順序、またはネストが発生する可能性が高まります。
* **キャッシュプレフィックス**: システムプロンプト、ツール定義、履歴は、複数ターンにわたる長いプレフィックスを形成します。逆引きチェーンが`cache_control`を通過させられない場合、キャッシュヒットが減少し、コストとレイテンシーの両方が上昇します。
* **エラーコードとリトライ**: 不正確なエラーマッピングにより、リトライロジックが回復可能なエラーを致命的なエラーとして扱ったり、その逆になったりする可能性があります。

> [!TIP]
>
> Claude Code、Codex、Gemini CLI、OpenClawのワークフローでは、デフォルトで公式リレーを優先してください。逆引きグループは、コスト補完または重要度の低いタスクにのみ使用してください。

## 公式リレーを優先する場合と、リバースが許容される場合

| シナリオ | 推奨 | 理由 |
| - | - | - |
| コーディングエージェント（Claude Code / Codex / Gemini CLI） | 公式リレーを優先 | ツール呼び出しとマルチターンタスクでは、プロトコルの一貫性が求められます |
| 長いコンテキストと複雑なマルチターンチャット | 公式リレーを優先 | キャッシュプレフィックスとコンテキストの受け渡しがより完全です |
| シンプルなチャット、翻訳、要約 | リバースも許容 | 単一ターンの品質は近く、コストも低くなります |
| ツール呼び出し / MCP ワークフロー | 公式リレーを優先 | パラメータ構造、順序、エラーコードの信頼性がより高くなります |
| 高同時実行数のバッチ生成 | 公式リレーを優先し、リバースをストレステスト | 同時実行数は、公式のクォータまたはリバース側のリソースプールに依存します |
| 画像生成 | 公式リレー / エンタープライズグループ。成熟したリバースの選択肢もテスト | 出力形式、成功率、4K の安定性には大きな差があります |
| エンタープライズの本番環境 | 公式リレー | コンプライアンス、SLA、トラブルシューティングがより充実しています |
| 価格を極めて重視する場合 | まず総コストを比較 | リトライ、失敗した作業、運用コストを含める必要があります |

## キャッシュはヒット率だけではありません

公式の Claude キャッシュには、明示的なプレフィックスマッチング、`cache_control` マーカー、5分間 / 1時間の TTL があります。`cache_creation_input_tokens` フィールドと `cache_read_input_tokens` フィールドには、書き込みと読み取りが直接示されます。OpenAI は自動プレフィックスキャッシュを使用し、Gemini は中程度のヒット率で暗黙的なキャッシュを使用します。

リバースチェーンがリクエストを転送するだけで、キャッシュ制御パラメータを完全に引き渡せない場合、ヒット率は低下します。長い会話、固定されたシステムプロンプト、大規模なツール定義によって、コスト差は拡大します。チャネルを選択するときは、キャッシュが存在するかどうかだけでなく、同じプレフィックスに対する実際のキャッシュ読み取り比率を測定してください。

キャッシュの仕組みと課金については、[APIYI はキャッシュ課金に対応していますか？](https://docs.apiyi.com/ja/faq/cache-billing.md) を、Claude のパラメータについては、[Claude のプロンプトキャッシュ](https://docs.apiyi.com/ja/api-capabilities/claude-prompt-caching.md) を参照してください。

## チャネルの評価方法：5つの指標

公式リレーとリバースのどちらかを選ぶ必要がある場合は、固定のテストセットを実行し、次の5つの数値を記録してください。

| 指標 | 計算方法 | 注意点 |
| - | - | - |
| リクエスト成功率 | 成功したリクエスト ÷（総リクエスト数 − クライアント側の4xx） | 自分自身のパラメータエラーは除外します |
| 実効キャッシュヒット率 | キャッシュ読み取り token ÷ 入力 token | 同じモデル、同じプレフィックス、同じグループを使用します |
| P95レイテンシー | 初回 token までの時間と合計所要時間を分けて測定します | 平均値だけに依存しないでください |
| エージェントタスク完了率 | 最終的に完了した固定タスクの割合 | 単一ターンの品質よりも実際の利用状況に近い指標です |
| 成功したタスクあたりのコスト | （リクエストコスト + リトライコスト + 失敗した作業）÷ 成功したタスク数 | 失敗分も含めます |

キャッシュフィールドはベンダーによって異なります。Claude は `cache_read_input_tokens` を公開し、OpenAI は `prompt_tokens_details.cached_tokens` などのフィールドを使用します。実際のレスポンスからフィールドを読み取ってください。

> [!TIP]
>
> 単一ターンのベンチマークで分かるのは、モデルが回答できるかどうかだけです。これら5つの指標によって、そのチャネルでビジネスを運用できるかどうかが分かります。

## APIYIのチャネル原則

* **デフォルトは公式リレー**: APIYIは、デフォルトでベンダーの公式APIと公式クラウドマーケットプレイスを使用します。リバースはコストを補完するためのものであり、デフォルトのチャネルではありません。
* **ソースを明示**: `Claude_Reverse`、`Codex_Reverse`、`Gemini_Reverse`は、グループ名とドキュメント内でリバースとして明示されています。公式の直接接続として説明されることはありません。
* **本番環境では公式リレーを優先**: `Default`、`SVIP`、`Claude_Enterprise`、`CodexResponses`、`image2Enterprise`、`NB-Enterprise`は本番トラフィックを処理します。画像モデルでは、各モデルのソースに応じて選択してください。
* **複雑なAgentには公式リレー**: ツール呼び出し、マルチターンタスク、長いコンテキストでは、プロトコルの一貫性が求められます。
* **学習とコスト最適化にはリバース**: リバースグループは、公式リレーと同じSLA、同時実行数、または機能の完全性を保証するものではありません。
* **エンタープライズ顧客**: 保証が重要な場合は、`Claude_Enterprise`、`image2Enterprise`、または`NB-Enterprise`を使用してください。SLAと調達オプションについては、サポートにお問い合わせください。
* **チャネルは変更されます**: 上流リソース、モデルバージョン、グループの倍率は変更される場合があります。コンソールと[ライブアップデート](https://docs.apiyi.com/en/live.md)を確認してください。

単一ターンの回答だけを見ると、公式リレーと優れたリバースチャネルは非常によく似て見えることがあります。公式リレーが本当に価値を持つのは、**動作の一貫性、予測可能な安定性、完全な機能、長期的な持続可能性**です。本番環境のビジネスでは、この4つが単価だけでなく、サポートコストと顧客維持率を左右します。

## 関連ドキュメント

> [card] [グループ](https://docs.apiyi.com/ja/groups.md)
>
> ベンダーとモデル別のすべてのグループ、倍率、割引、選択ガイダンス

> [card] [tokenとグループ](https://docs.apiyi.com/ja/faq/token-and-groups.md)
>
> tokenを作成し、プライマリグループとフォールバックグループを設定

> [card] [グループとは？](https://docs.apiyi.com/ja/faq/groups-explained.md)
>
> ユーザーグループとtokenグループ

> [card] [キャッシュ課金](https://docs.apiyi.com/ja/faq/cache-billing.md)
>
> Claude、OpenAI、Geminiのキャッシュ動作と課金

> [card] [GPT Image：公式とリバース](https://docs.apiyi.com/ja/api-capabilities/gpt-image-2/vs-gpt-image-2-all.md)
>
> 画像モデルのパラメータ、価格、品質の違い

> [card] [モデルの料金](https://docs.apiyi.com/ja/models/index.md)
>
> すべてのモデルの価格と仕様


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.