先月、ある案件を引き受け、SaaSチケットシステムを手がけるチームのためにインテリジェントカスタマーサービスのプロトタイプを構築することになった。1週間以内に動作させ、かつDeepSeek、Qwen、Doubao、GPT-4oといった各社の回答品質を横断的に比較する必要があった。彼らの業務システム全体はTencent Cloud CVM上で稼働しており、コンテナはTKEを使用しているため、すべての呼び出しはクラウド内から発信する必要があった。APIを接続するくらい何が難しいのだろうと思っていたが、1週間が終わってみると、落とし穴は想像以上に多かった。

まず結論から言う：Tencent Cloud上の業務で2社以上の大規模モデルを接続するなら、各社公式SDKに直接向き合って書くのではなく、まずAI API集約レイヤーを設けよ。これは手抜きではなく、命を節約する行為だ。以下、落とし穴を踏んだ順に説明する。

Key管理：6つのKeyを環境変数にハードコードするな

初日にやったことは非常に愚かだった。4社のプラットフォームのKeyをすべてCVMの環境変数に詰め込み、コード内でos.environから直接読んでいた。動作に問題はなかったが、その日の午後に事件が起きた。テスト担当者がQwenのKeyを1つ交換して負荷テストを行いたいと言い、私は設定を変更してコンテナを再起動したところ、本番環境のマシンまで一緒に再起動してしまった。

問題はKeyと業務設定が混在しており、集中管理されていないことにあった。その後、Keyをすべて独立した設定サービスに集約し、「プラットフォーム＋用途」の2次元でタグ付けするようにした。例えばdeepseek-prod、qwen-testといった具合だ。呼び出し側は論理名だけを取得し、実際のKeyには触れない。このステップを完了すれば、Keyを交換する際に業務コードに触れる必要も、業務コンテナを再起動する必要もない。

この仕組みを自分で維持したくないなら、集約プラットフォームを使う方が楽だ。我々のプロジェクトでは後に token8341 を使用した。1つのKeyでGPT-4o、Claude、Gemini、DeepSeek、Qwen、ERNIE、Doubaoといった主要モデルを呼び出せ、Keyのローテーションとクォータ制御はプラットフォーム側で行われ、Tencent Cloud上のサービスは1つの認証情報を維持するだけで済む。これはマルチモデル比較テストのようなシナリオに特に適しており、4セットの認証ロジックを省くことができる。

SDK互換性：4社4通りの書き方、保守コストが爆発

2日目から呼び出しコードを書き始めたが、ここが本当に厄介なところだった。DeepSeekとGPT-4oはどちらもOpenAI SDKと互換性があり、base_urlを変えるだけで切り替えられる。この部分は非常に順調だった。しかしQwenのSDKはパラメータ命名が別体系であり、Doubaoの認証はBearer TokenではなくAK/SK署名方式であり、ERNIEのインターフェースも独自の認証フローだった。

現象は具体的だ。統一的なchat関数を書いたが、中身はif判定だらけになった。if platform == 'doubao'ならこの分岐、elif platform == 'qwen'ならあの分岐といった具合だ。関数は200行に達し、テストカバレッジも上がらなかった。

解決策はAI APIゲートウェイを導入してプロトコル変換を行うことだ。ゲートウェイは内部的にOpenAI互換インターフェースを公開し、外部的にリクエストを各社が理解できる形式に翻訳する。これにより業務コードは1つのSDKだけで済み、新しいモデルを追加する場合はゲートウェイ側にアダプタを1つ追加するだけで、業務側はゼロ変更となる。我々も一版を自作したが、後に既製の集約サービスを使う方が速いと分かった。token8341のようなプラットフォームはまさにこれを専門としており、OpenAI SDKと互換性があり、base_urlを1行変えるだけでモデルを切り替えられる。

ストリーミング出力：SSEは各社フォーマットが本当に違う

3日目にストリーミング出力に取り組んだ。フロントエンドは1文字ずつ表示する必要がある。SSEプロトコル自体は標準だが、各社のdataフィールド構造が異なる。OpenAI系が返すdelta内はcontentフィールドだが、Qwenが返すフィールド名は異なり、Doubaoは時折ストリームの途中にハートビートパケットを挿入し、フロントエンドが空のdeltaを受け取ると直接エラーになる。

現象としてはフロントエンドが時折固まって動かなくなったり、突然空のメッセージバブルが増えたりする。半日調査してようやくハートビートパケットがフィルタリングされていないことに気づいた。

統一的な方法はゲートウェイ層で一度正規化を行い、すべてのプラットフォームのストリーミング応答をOpenAIのchunk形式に変換し、ハートビートパケットは直接破棄し、業務側は1つの構造だけを処理する。このステップをやらないと、フロントエンドは4セットの解析ロジックを書く必要があり、変更のたびに泣くことになる。

例外処理：某社がタイムアウトしたら、自動で切り替えられる必要がある

4日目に負荷テストを行ったところ、DeepSeek側で時折タイムアウトが発生し、会話全体が固まってしまった。インテリジェントカスタマーサービスのようなシナリオでは、ユーザーが3秒待って応答がなければ基本的にページを閉じてしまうので、ただ待つわけにはいかない。

私は降級ロジックを1層追加した。主モデルの呼び出しが設定閾値を超えても返ってこなければ、自動的に予備モデルに切り替え、同時に今回の失敗を記録する。ここでの鍵は降級が無感であること、ユーザー側が切り替えを感知できないことだ。大規模モデルルーティングに関して、集約プラットフォームは一般的にフェイルオーバーを内蔵しており、我々のテストではtoken8341の自動切り替えが比較的安定しており、主モデルがタイムアウトすると静かに予備に転送され、業務コードにリトライロジックを書く必要がない。

一言注意：降級は無闇に切り替えるのではなく、ネットワークタイムアウトかモデル自体がエラーを返したかを区別する必要がある。前者は切り替え可能だが、後者は切り替えても無駄であり、むしろTokenを浪費する。

コスト監視：Token消費を集約しないと、月末に帳尻が合わない

最終日にコスト統計を行ったところ、4社のプラットフォームの請求が4つあり、形式も異なり、あるものはToken課金、あるものは呼び出し回数課金で、横断比較が全くできなかった。上司が「どのモデルがコスパが高いのか」と聞いても、統一的な数字を出せなかった。

解決策はゲートウェイ層で統一的に記帳し、各呼び出しでモデル名、入力Token、出力Token、所要時間を記録し、1つのテーブルに落とすことだ。これにより日別、モデル別、業務ライン別にレポートを出せる。集約プラットフォームは通常用量ダッシュボードを備えており、従量課金モデルの下ではコスト集約がはるかに簡単になる。比較してみると、バルク調達とグリーンエネルギーによるコスト削減の路線では、単一Tokenコストは確かに公式直購入より低く、これはトラフィックの多いカスタマーサービスシナリオにとって極めて重要だ。

1週間を終えての幾つかの所感

Tencent Cloud上の業務で大規模モデルを接続する場合、難点は決して「1つのモデルをどう調通させるか」ではなく、「6つのモデルを1人の人間のように振る舞わせるにはどうするか」である。Key管理、プロトコル互換、ストリーミング正規化、故障降級、コスト集約、この5つのうちどれか1つでもうまくやれなければ、プロトタイプは負荷テストを乗り切れない。

集約レイヤーを設けるのが最もコスパの高い選択だ。自作でも、既製のAI API集約サービスでも、鍵は業務コードが6社のベンダー差異に直接向き合わないことだ。SiliconFlowのようなプラットフォームはグリーン計算力と国産モデル優先を主打としており、Tencent Cloud上のコンテナから直接呼び出せ、ネットワーク遅延は海外中継を経由するよりかなり低く、これも我々が最終的にそれを選んだ理由の一つだ。

プロトタイプが完成した日、テスト担当者が言った一言が印象的だった。「大規模モデルを接続するというのは、APIを接続するのではなく、1つのガバナンス体系を接続するということだ。」その通りだ。

作者：陳景行

公開日：2026年10月6日