ひとことで言うと
WeChat 中継は、微信公式アカウント API の呼び出しに固定送信元 IP を与える転送サービスで、errcode 40164（invalid ip, not in whitelist）を根本的に解消します。コード内の api.weixin.qq.com を中継ドメインに置き換え、Authorization: Bearer ヘッダーを 1 つ追加するだけで、リクエストは固定 IP を経由して微信に到達します。公式プラットフォームのホワイトリストにはこの 1 つの IP を登録するだけでよく、サーバー移設・DC 変更・家庭用回線の再接続があっても管理画面に戻る必要はありません。パス・パラメータ・レスポンスは公式 API と完全に同一で、SDK も業務ロジックも変更不要です。価格は年額 ¥19.9、公式アカウント数・呼び出し回数の上限はありません。
エージェントが担う主要な作業
中核機能
固定送信元 IP、ホワイトリストは一度だけ
開通後、成功ページに中継の送信元 IP がそのまま表示され、長期にわたり固定されます。公式プラットフォームの「設定と開発 → 基本設定 → IP ホワイトリスト」に一度貼り付けて保存するだけ。以降はサーバー増設、DC 移設、クラウド事業者の変更があっても管理画面に触れる必要はありません。
IP 1 つ・登録 1 回
変更は 2 か所だけ
リクエストの https://api.weixin.qq.com を https://wechat-publish.ygg.com.cn に置き換え、Authorization: Bearer <キー> ヘッダーを 1 つ追加するだけ。パス・クエリパラメータ・レスポンスは公式 API と完全に一致し、SDK の入れ替えも業務ロジックの書き換えも、既存の access_token キャッシュ方式の変更も不要です。
2 か所・約 2 分
家庭回線・ローカル開発でも利用可能
自分の PC で配信スクリプトを動かす場合、再接続のたびに IP が変わるため、ホワイトリストのためだけに固定 IP のクラウドサーバーを用意するしかありませんでした。中継を挟めば送信元 IP は中継側が提供するため、ローカル開発機・社内ネットワーク・動的グローバル IP からでも公式アカウント API を直接呼べます。
そのまま転送、保存なし・ログはマスキング
リクエストボディは全 HTTPS でそのまま転送し、内容の解析も保存も行いません。ログに残るのは時刻・API パス・ステータスコードのみで、AppSecret や access_token などの機密パラメータは自動的にマスキングされます。この種の中継サービスで最も問われるべき点なので、明示しています。
1 契約で公式アカウント数は無制限
同じ送信元 IP を各公式アカウントのホワイトリストに登録するだけで、1 契約が複数アカウントを同時にカバーし、呼び出し回数の上限もありません。運用代行、マルチブランド運用、1 人の開発者が複数アカウントを管理するケースも 1 契約で済みます。
アカウント数・呼び出し回数とも無制限
QR 決済で即開通、審査待ちなし
電話番号と SMS 認証でログインし、WeChat Pay または支付宝の決済完了と同時に中継キーと送信元 IP が表示されます。すべてセルフサービスで、人手による審査はありません。期限切れになると中継は即座に停止し、更新しても IP とキーは変わらないため、ホワイトリストの再設定は不要です。
横並び比較
中継利用 vs 固定 IP のクラウドサーバー購入 vs 毎回ホワイトリストを修正
| 観点 | WeChat 中継（年額 ¥19.9） | 固定 IP のクラウドサーバーで自前転送 | 変更のたびに管理画面で修正 |
|---|---|---|---|
| 導入コスト | ドメイン変更とヘッダー 1 つ追加、約 2 分 | 転送サービスの構築、HTTPS と証明書更新の設定が必要 | 導入コストはゼロだが、変更のたびにコストが発生 |
| サーバー IP が変わったとき | 影響なし。送信元 IP は業務サーバーに依存しない | 影響はないが、その転送機自体が移設しないことが前提 | 誰かが管理画面で修正し反映されるまで全 API が 40164 |
| 家庭回線・ローカル開発 | そのまま利用可能。動的グローバル IP でも問題なし | リクエストをそのサーバー経由にする必要があり、ローカル検証の経路が長くなる | ほぼ不可能。再接続のたびに IP が変わる |
| 複数の公式アカウント | 1 契約でアカウント数無制限、同じ IP を各アカウントに登録 | 1 台で複数アカウントに対応できるが、サーバー費用は固定支出 | アカウントごとに個別修正が必要で、数が増えるほど負担増 |
| 継続コスト | 年額 ¥19.9、呼び出し回数の制限なし | クラウド年額費用＋運用工数＋証明書の維持 | 金銭的負担はないが、変更のたびに障害対応の時間が発生 |
| 認証情報の経由先 | 中継を経由（そのまま転送・保存なし・キーはマスキング） | 自社のマシンのみを経由 | 微信に直結、第三者を経由しない |
導入前後の比較
定量的改善
エージェントと人の監督の役割分担
システム構成（概念図）
source
自社サーバー / ローカルスクリプト（IP は変動）
agent
中継サービス（Bearer 認証・固定送信元 IP）
human
公式プラットフォームの IP ホワイトリスト（この 1 つのみ）
output
微信公式アカウント API api.weixin.qq.com
Flow
- 自社サーバー / ローカルスクリプト（IP は変動）→中継サービス（Bearer 認証・固定送信元 IP）ドメイン変更 + Bearer キー
- 公式プラットフォームの IP ホワイトリスト（この 1 つのみ）→中継サービス（Bearer 認証・固定送信元 IP）送信元 IP を一度だけ登録
- 中継サービス（Bearer 認証・固定送信元 IP）→微信公式アカウント API api.weixin.qq.comそのまま転送、パスは不変
- 微信公式アカウント API api.weixin.qq.com→自社サーバー / ローカルスクリプト（IP は変動）レスポンスは公式 API と同一
検証可能な事実
数値と出典
本サービスが対象とするのは微信公式プラットフォームの返却コード 40164（invalid ip, not in whitelist）——呼び出し元サーバーのグローバル IP が公式アカウントの IP ホワイトリストに無い場合に発生します。
導入に必要な変更は 2 か所のみ：リクエストのドメインを api.weixin.qq.com から wechat-publish.ygg.com.cn に変更し、Authorization: Bearer <キー> ヘッダーを追加。パス・パラメータ・レスポンスは公式 API と一致します。
価格は年額 ¥19.9。呼び出し回数の上限はなく、1 契約でカバーできる公式アカウント数にも制限はありません。WeChat Pay と支付宝に対応。
ログに残るのは時刻・API パス・ステータスコードのみ。AppSecret や access_token などの機密パラメータは自動的にマスキングされ、リクエストボディは全 HTTPS でそのまま転送、ディスクへの保存は行いません。
開通後、成功ページに中継の送信元 IP とキーがそのまま表示され、長期にわたり固定されます。契約が切れると中継は即座に転送を停止し、更新しても IP とキーは変わりません。
導入と費用
価格
含まれるもの
- · 固定送信元 IP による中継転送。公式プラットフォームのホワイトリストにはこの 1 つの IP のみ
- · 呼び出し回数無制限、1 契約で公式アカウント数の制限なし
- · 全区間 HTTPS。パス・パラメータ・レスポンスは公式 API と完全に同一
- · 決済後ただちにキーと送信元 IP を発行、人手の審査なし
お客様ご用意
- · 公式アカウント自体の認証、API 権限、呼び出し頻度枠（アカウント種別に応じて微信が決定）
- · access_token の取得・キャッシュ・更新（引き続き利用側の責任）
- · 自社のサーバー、ドメイン、業務コード
詳細方案はQRコードから
WeChatでQRコードを読み取り、担当者に完全な方案資料と導入チェックリストをご請求ください。
適用範囲
本方式が適さないケース
- リクエストは YGG の中継サーバーを経由します。そのまま転送し保存せず、機密パラメータをログでマスキングしているとはいえ、「認証情報を第三者に経由させない」ことが厳格に求められる組織（金融・行政など）は、自前の転送構築または直結を選ぶべきです。
- 中継は経路上の追加要素であり単一障害点でもあります。中継が利用できないとき公式アカウント API の呼び出しは失敗します。可用性が重要な業務では、コード側に直結フォールバックを残すか、中継のヘルスチェック後に切り替える設計を推奨します。
- 解決するのは IP ホワイトリストの一点のみです。微信側の API 権限レベル、呼び出し頻度制限、access_token の取得・有効期限のルールは変わらず、トークンの代理管理も行いません。アカウント種別や未認証が理由で使えない API は、中継経由でも同様に使えません。
- 契約が切れると中継は即座に転送を停止し、業務が中断します。期限管理は利用側の責任です。更新リマインドに加えて、自社の監視でも中継経路にアラートを設定することを推奨します。