50万回の実際の呼び出しで、1日のネットワーク待機時間を3時間から3分に短縮しました

2026-09-08

データソース：2026-07-16～2026-09-08、実運用環境での513,336回の呼び出し

一、結論から

最後まで読む時間がない方のために、最も重要なポイントを一文でまとめます。

50万回の実際のAPI呼び出しデータに基づき、1日のネットワーク転送待機時間を約3時間から3分に短縮しました。

どうやって実現したのでしょうか。――推論とツール実行を分離し、大量のトラフィックを内部ネットワークに流し、少量のトラフィックだけを国際回線経由にしました。

以下で、具体的な経緯と実際のデータを説明します。

二、背景：旧アーキテクチャが遅かった理由

当初、メインマシンは中国本土に設置し、そこに CodeX を動かしていました。CodeX は、OpenAI API の呼び出し、会話コンテキストの管理、ツール呼び出しの実行など、AIアプリケーション開発に必要な機能をすべて備えたフレームワークです。すべての処理を1台のマシン上で実行していました。

ネットワーク構成は次のとおりです。

flowchart LR
    A[CN 主力机<br>CodeX] -->|公网请求<br>VPN + Cloudflare| B[OpenAI API]
    B -->|推理响应<br>~794 KB / 次| A

推論リクエストのたびに、中国からVPNとCloudflareを経由し、太平洋を越えてOpenAIに到達した後、結果を再び戻す必要があります。この経路には、次のような不利な特徴がありました。

• 帯域幅：10 Mbps（実効スループットは約0.75 MB/s）
• 遅延：RTT約300ms。しかも頻繁に変動
• 安定性：断続的なパケットロスや再送が発生

このアーキテクチャでは、1日10,000回の呼び出しを行うと、ネットワーク転送データを待つだけで約3時間かかっていました。

この3時間の間、CodeXは何もしていません。ただネットワークを待っているだけです。

三、データが物語ること

「3時間」が実際にどこで費やされているのかを明らかにするため、旧アーキテクチャにおける2026年7月16日から9月8日までのすべてのアクセスログを取得しました。合計 513,336回の有効な呼び出し であり、問題を説明するには十分なサンプル数です。

1回の呼び出し におけるトラフィックの構成を集計しました。

両者には 58倍 の差があります。推論トラフィックが全体の98.3%を占め、ツール制御信号はわずか1.7%です。

次に、所要時間を計算しました。

推論トラフィックを国際回線経由で転送した場合：

7.94 GB = 7,940 MB ÷ 0.75 MB/s ≈ 10,587秒 ≈ 2.94時間

ツール制御トラフィックだけを国際回線経由で転送した場合：

0.14 GB = 140 MB ÷ 0.75 MB/s ≈ 187秒 ≈ 3分

問題の所在が明らかになりました。毎日約3時間が推論トラフィックの転送に費やされています。しかし、これらのデータは本来、国際回線を通す必要がありません。

四、解決策：「一体型」から「分離デプロイ」へ

問題が「すべての処理を中国のメインマシン上で実行し、すべてのトラフィックが国際回線を通っていること」にあるなら、解決策は処理を分離することです。

新アーキテクチャ：推論をAWSに、ツールを中国に配置

CodeXから推論機能を分離し、AWS USにデプロイしました。

flowchart LR
    subgraph CN["🇨🇳 CN 主力机"]
        T[工具执行环境]
        C[HTTP/2 客户端]
    end

    subgraph AWS["☁️ AWS US"]
        R[推理设备<br>Rust + SQLite]
        O[OpenAI API]
    end

    C -->|工具参数下行<br>591.59 Bytes| R
    C -->|工具结果上行<br>13,387.34 Bytes| R
    R <-->|推理流量<br>7.94 GB/天 内网闭环| O

この新アーキテクチャにおける主な変更点は、次のとおりです。

1. 推論デバイス（軽量なRustサーバー + SQLite）をAWS USにデプロイし、OpenAIと同じリージョンに配置
2. 推論デバイスとOpenAIの間はAWSの内部バックボーンネットワークを使用：遅延は10ms未満、帯域幅はGbps級
3. 中国のメインマシンからOpenAIを直接呼び出さない。担当するのは次の2つだけです。
   • 推論デバイスから送信されたツール呼び出しパラメーター（591.59 Bytes）を受信
   • ツール実行後、その結果（13,387.34 Bytes）を推論デバイスに返送
4. SQLiteで推論デバイス側の会話コンテキストを管理し、中国のメインマシンはステートレス化

旧アーキテクチャと新アーキテクチャで、国際回線を通るトラフィックを比較します。

五、最終結果

六、データの信頼性に関する説明

• 集計期間：2026-07-16 16:50～2026-09-08 09:51（中国標準時）
• サンプル総数：513,336回の呼び出し。実運用環境の全量ログであり、抽出サンプルではありません
• トラフィック集計：実際のHTTPリクエスト／レスポンスボディのサイズに基づいています
• ツール呼び出しパラメーター：1回あたり591.59 Bytes
• ツール呼び出しレスポンス：1回あたり13,387.34 Bytes
• 帯域幅の推定：実測した実効スループット0.75 MB/sに基づいています（理論値1.25 MB/sではありません）
• RTTの推定：VPN + Cloudflareによる上乗せ分を含む、実測値300msに基づいています

すべての元ログはエクスポートして検証できます。

七、まとめ

帯域幅を増強したわけでも、より高性能なマシンに交換したわけでも、OpenAIの処理を高速化したわけでもありません。

行ったことは、ただ一つです。推論とツール実行を分離しました。

• 推論（大量のトラフィック）はAWS USに配置し、OpenAIの近くで実行
• ツール実行（軽量な制御信号）は中国のメインマシンに配置

その結果、1日3時間のネットワーク待機時間が、3分になりました。

データに基づくアーキテクチャ最適化に、特別な秘策はありません。あるのは、実際の数字だけです。

データソース：実運用環境の推論デバイスアクセスログ。サンプル数513,336回。
集計期間：2026-07-16 16:50～2026-09-08 09:51（CST）。