AI Relay サービスのアカウント BAN を効果的に減らす方法
Wokey Team · 2026-06-27
モデル提供元は最近、大規模なアカウント BAN の波を実施しました。その範囲は広く、正当に使っていた個人ユーザーまで巻き添えになりました。
Relay サービスを運営している人、あるいは選ぼうとしている人にとって、これは真剣に考える価値があります。BAN は運の問題なのか、それともアーキテクチャの問題なのか。
私の答えは後者です。BAN 率はランダムではなく、アーキテクチャで決まります。
少し引いて見てみましょう。アカウントが共有や転売されているかどうかを判断する際、モデル提供元は通常、次のようなシグナルを見ています。
- IP の変化と IP の種類 — リクエストが突然、住宅用 IP からデータセンターの IP に飛んだり、異なる地域をまたいで移動したりする。
- 行動の異常 — 呼び出し頻度、同時実行数、時間の分布が、明らかに 1 人の人間のものに見えない。
- 複数のアカウントが出口を共有 — 数十のアカウントのリクエストが同じ IP 群を通って流れている。
- クライアントのフィンガープリントの異常 — リクエストヘッダー、TLS フィンガープリント、デバイスの特徴が通常のクライアントと一致しない。
これらのシグナルが重なると、提供元のリスク管理システムがアカウントにフラグを立てます。
しかし、どのシグナルが最も重く、最も検出しやすいかと聞かれれば、私は IP だと答えます。
理由は単純です。IP は最も外側にあり、最もコストの低い選別基準だからです。住宅用 IP からのリクエストとデータセンターの IP からのリクエストは、リスク管理システムの目にはまったく異なるリスク階層に見えます。データセンターの ASN、IP の飛び移り、地理的な異常。この 3 つが同時に現れれば、リスク管理システムに「これは普通のユーザーではない」と告げているようなものです。
正直に言えば、従来の Relay サービスのアーキテクチャはまさにこの地雷を踏んでいます。すべてのリクエストが Relay のサーバーから出ていき、数十のアカウントが同じデータセンターの IP 群を共有しています。どれだけ負荷分散しても、プロキシプールをローテーションしても、出口は根本的にサーバールームです。ほかの Relay 運営者のソリューションも見てきましたが、熱心にプロキシをローテーションしていても、ASN を調べればすべてクラウド事業者です。仮面が違うだけで、顔は同じです。
だからこそ、3 つの Relay サービスを渡り歩いても、どこでも 2 週間ごとに BAN される人がいるのです。運が悪いのではなく、どのサービスも同じアーキテクチャだからです。
では、IP を変えずに保つにはどうすればよいのでしょうか？
個人ユーザーなら、すでに確立された方法があります。自宅の NAS に New API や One API のような統合ゲートウェイを立てるか、sam-to-API のようなツールを使い、すべての提供元の API をそこ経由にします。スマートフォン、ノートパソコン、モデルを呼び出すどのクライアントも、提供元に直接アクセスしません。代わりに自宅のデバイスを経由し、そこから提供元の API に転送します。こうすれば、どのモデルを呼び出しても、提供元から見た出口 IP は常に自宅のブロードバンドの IP で、自宅で普通に使っているのと見分けがつきません。
外出中はどうするか？ Tailscale や WireGuard のようなメッシュネットワークツールを使って、スマートフォンやノートパソコンの通信をまず自宅の NAS に戻し、そこから外に出します。カフェでも、オフィスでも、電車の中でも、リクエストは自宅のブロードバンドから出ていきます。Wi-Fi を切り替えたりモバイルデータをオンにしたりしただけで、提供元に IP の飛び移りを見られることはありません。
この方法は fnOS コミュニティや AI のセルフホスティング界隈で十分に実績があり、チュートリアルも実践者も豊富です。個人ユーザーにとっては、現時点で最も信頼できる IP 固定の方法です。
しかし、これで解決するのは 1 人分の問題だけです。
Relay サービスは、数十から数百の Provider のアカウントを管理しています。一人ひとりの家に出向いて NAS を設置し、ゲートウェイを設定することはできません。必要なのは、各 Provider が軽量なノードをインストールしてプラットフォームに接続できる体系的な仕組みです。リクエストは引き続き Provider 自身のネットワークから出ていきますが、注文の振り分けとトラフィックのルーティングはプラットフォームが一元的に処理します。
このアーキテクチャを Provider 側出口と呼びます。リクエストは Relay のサーバーではなく、Provider 自身のネットワークから出ていきます。
たとえるなら、NAS の方法は自分で道端の店を開くようなものです。自宅から発送し、仕入れも品ぞろえも注文対応もすべて自分で行います。Provider Node はプラットフォームのフランチャイズに加盟するようなものです。発送は引き続き自宅からですが、注文はプラットフォームから振り分けられます。発送元の住所は変わらず、変わるのは誰が注文を振り分けるかです。
これが Wokey Provider Node の役割です。
インストールは簡単で、コマンド 1 つで済み、macOS、Linux、Windows、Docker に対応しています。インストール後、ローカルのコンソールを開き、Wokey アカウントを紐づけ、ローカルのサブスクリプションの認証情報をインポートします。ノードが起動すると、Wokey プラットフォームとの WebSocket 接続を維持します。プラットフォームがユーザーのリクエストを送り込み、ノードがローカルからベンダーの API にリクエストを送ります。全工程が Provider 自身の IP から出ていくため、ベンダーから見れば、Provider が自分のサブスクリプションを普通に使っているのとまったく同じです。
現在対応しているベンダーは OpenAI/Codex、Anthropic/Claude、Zhipu、Kimi、DeepSeek、Gemini、xAI などです。
このアーキテクチャを自分で運用してみて、最も実感したのは次のことです。リスク管理と「戦う」のではなく、そもそもリスク検出の前提条件を一切満たさないのです。ベンダーから見れば、これは自宅で自分のサブスクリプションを使っている普通のユーザーにすぎず、説明を要する異常は何もありません。
プロジェクト全体は Apache-2.0 でオープンソース化されており、出口のホワイトリストはソースにハードコードされています。私がそう言うから安全なのではなく、すべてのコードが監査可能だから安全なのです。
もちろん、Provider 側出口で BAN がゼロになると言うつもりはありません。IP は BAN の要因の 1 つにすぎず、呼び出し頻度、同時実行のパターン、時間の分布もリスク管理を発動させる可能性があります。BAN 率ゼロを保証できるソリューションはありません。
しかし論理は明快です。最大のシグナルに対処していなければ、ほかのどんな最適化も砂上の楼閣です。
BAN 率を下げる鍵は、使い方を普通と見分けがつかないようにすることです。IP を変えずに保つことが最も重要な要素です。個人ユーザーには個人向けの方法があり、Relay サービスには体系的な Provider 側出口の仕組みが必要です。
Relay の競争が最終局面を迎えたとき、勝負を分けるのはモデルの多さや価格の安さではなく、Relay だと提供元に見破られないアーキテクチャを持っているかどうかです。あなたがいま使っているサービスは、どこのネットワークからリクエストを出していますか？