Immersive TranslateカスタムAPIセットアップ

OpenAIサービス設定を開く

Immersive Translateの公式OpenAIサービスページには、More Settingsの下にカスタムAPIアドレスが文書化されています。OpenAI互換エンドポイントを評価するときは、そこから始めます。後のセットアップチェックを再現可能な環境に結び付けられるよう、拡張機能のバージョンとブラウザを記録します。

最初のテストでは一つの設定を選び、復旧用にデフォルト設定を利用できる状態に保ちます。認証情報は非公開の拡張機能設定にだけ入力します。特にブラウザがマーチャント管理画面にもアクセスできる場合は、ページコンテンツを送信する前にエンドポイントが意図した宛先であることを確認します。

アドレスがベースか完全なルートかを確認する

すべてのカスタムアドレスフィールドがSDKのbaseURLのように動作すると仮定しないでください。公式ページのAzure例には完全なchat-completions URLが含まれています。インストール済み拡張機能のヘルプテキストと、サニタイズした送信リクエストのパスを調べ、アドレスの使われ方を判断します。

APIsRouterのchat-completions候補では、完全なルートはhttps://api.apisrouter.com/v1/chat/completionsです。インストール済みバージョンがベースURLを明示的に要求してルートを追加するなら、https://api.apisrouter.com/v1を使います。chat/completionsのサフィックスが重複しないようにします。以下のワークシートは候補設定を説明するもので、テスト済み拡張機能の設定ではありません。

Service: OpenAI
Settings area: More Settings > custom API address
Full request URL candidate: https://api.apisrouter.com/v1/chat/completions
Base-only candidate, if required by installed version: https://api.apisrouter.com/v1
Credential: gateway key entered privately
Model: exact current catalog ID with verified chat behavior

翻訳リクエストの経路を見える状態に保つ

拡張機能は選択したサービスアドレスへ翻訳リクエストを送ります。そのアドレスを単なる接続フィールドではなく、データ共有の判断として扱います。選択したエンドポイントを通じて処理してよいコンテンツを使い、選択した翻訳操作がページのどの程度を含むかを確認します。

以下のフローは、文書化されたカスタムアドレス機構を使うゲートウェイ経路を示します。選択モデルのラベルは設定上の選択であり、検証済みモデルの一覧ではありません。ストア認証、商品編集、インポート承認はこのリクエスト経路の外にあります。

まず管理されたページを一つ検証する

合成商品説明、保護されたブランド用語、単位付き数量、リンクを含む短いページを使います。そのページだけを翻訳します。表示された結果をソースと比較し、サニタイズしたネットワーク送信先、選択モデル、レスポンスステータスを検査します。

コンテンツが欠落、重複、ソース言語との混在を起こしていないか確認します。次に長い段落や見出しとリストを含むレイアウトを試します。後の設定変更を同じ素材と比較できるよう、ソースと観測出力を保存します。大きな文書を処理する前の有用な診断ベースラインになります。

編集上の問いにはバイリンガル読解を使う

ブラウザ翻訳は、レビュアーが不慣れなソース資料を検査したり、注意が必要な表現を特定したりする助けになります。原文を表示したまま、主張、数量、用語を直接比較します。対象言語を評価できない場合は、流暢に見えることを証拠として受け入れず、評価できる人へ候補を回してください。

用語集の判断はカタログワークフローに保持します。カスタムエンドポイントが拡張機能内で用語集の強制やフィールド単位の検証まで提供すると仮定しないでください。インポート用の商品説明には、独自のソース参照付き候補、レビュー結果、送信先マッピングが必要です。

さらに翻訳する前にエラーを診断する

リクエスト経路、認証情報、正確なモデルIDから始めます。利用できる場合は構造化エラーを記録し、証拠を共有する前にヘッダーを秘匿化します。リクエストが制限されているなら、全ページ翻訳をすぐに繰り返すのではなく、作業量を減らしてサービスのリトライガイダンスに従います。

小さく選んだ文章で、接続失敗とコンテンツまたはレスポンス処理の問題を切り分けます。一度に一つの設定を変えます。公式ページには過去の価格とリクエストレートの例がありますが、その数値を新しい設定にコピーせず、現在のエンドポイントのドキュメントとアカウント上限を使ってください。

ブラウザ出力とカタログ配信を分ける

翻訳されたブラウザ表示は検査面です。商品テキストを公開するには、カタログレビュー用パッケージで候補を作り、識別子とソースリビジョンを保持し、承認済みフィールドをストアの実際のインポートまたは翻訳APIに通します。

保存されたフィールドを読み、意図したストアフロントのロケールを開いて配信を検証します。通常の訪問者に何が表示されるかを証明するため、編集者のブラウザ拡張機能だけに頼らないでください。翻訳リクエストの使用量をストア操作から分け、作業量を評価するときはリトライも計上します。ページまたは文字ごとの固定コストと仮定せず、現在の料金を参照します。

証拠と統合の限界

公式ドキュメントは、カスタムアドレス設定を確立しています。この記事ではAPIsRouter経由のインストール済み拡張機能リクエストをテストしていないため、正確なアドレス動作、モデル互換性、描画結果はセットアップチェックとして残っています。図は例示的な設定フローです。

互換性記録を完成させるには、拡張機能とブラウザのバージョン、サニタイズした設定、リクエスト送信先、正確なモデル、管理されたソースページ、観測した翻訳を含めます。保護フィールドのレビューは、そのトランスポートチェックから分けます。短い文章が成功しても、すべての文書形式やストア公開ワークフローが検証されるわけではありません。

よくある質問