3
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

その「激安AI API」、正体はトークン転売リレーかもしれない ― Denial of Walletと自社LLM基盤を守るための実務ガイド

3
Last updated at Posted at 2026-07-27

なぜ今これが重要か

社内でLLMを使う場面が増えると、必ず一度は目にするのがAI APIを公式より桁違いに安く売るという中継サービスの広告だ。公式のAnthropicやOpenAIの料金からすると信じられない割引で、しかもOpenAI互換のエンドポイントをそのまま渡してくれる。コスト削減を求められる現場ほど、この誘惑は強い。

2026年7月末にHackerNewsで話題になった調査記事が、この激安API市場の裏側を丁寧に解き明かした。ある中継業者は3,333ドル相当のAnthropicクレジットを425人民元、日本円にしておよそ9千円弱で売っていた。公式価格からの割引率はおよそ97.8%に達する。ここまで来るとビジネスモデルとして成立するはずがなく、成立させているのは不正な資金源と巧妙なアカウント運用だ。

この記事は二つの意味で日本のエンジニアに関係する。ひとつは買う側の視点で、こうした中継サービスに社内のプロンプトや顧客データを流すことが何を意味するのか。もうひとつは作る側の視点で、自社がLLM機能を外部提供したとき、この市場が育てた攻撃手法、とりわけDenial of Walletにどう備えるかだ。単なる海外の不正事例として片付けず、自社の調達判断と設計判断に落とし込みたい。

何が起きているか

調査記事が描くのは、単独の詐欺師ではなく分業化されたひとつの産業だ。市場は四つの層で構成されている。

最上流にいるのはカードとアカウントの供給業者で、米欧の課金審査を通過するよう作られたバーチャルカードと、大量登録済みのアカウントを卸す。その下の層がアカウントプールで、数百のアカウントを束ねて認証トークンとレート制限を管理し、フラグが立ったアカウントを自動で切り離してフェイルオーバーし、外からは単一のAPIに見せる。さらにその下に中継業者がいて、プールのAPIを中国語の消費者向け製品として包み、WeChat決済とサポートを付けて価格競争する。最下流が実際の利用者で、安い推論を求める開発者やスタートアップに加えて、モデル蒸留のために大量アクセスする買い手もいる。

規模も無視できない。トラフィック上位10の中継業者だけで月間の合計アクセスが360万に達し、蒸留で国産モデルを鍛える業者は一日に数十万人民元を稼ぐと語られ、業界全体では数十億人民元規模の連鎖だと表現されている。原典は中国の技術フォーラムV2EXに投稿された分析で、そこから英語圏に伝わって議論が広がった。

不正の資金源は複数ある。無料トライアルの自動大量取得によるクレジット搾取、利用してから支払いを取り消すチャージバック、限度額を絞ったプリペイドカードでの入金、そして企業が無防備に公開しているサポート用チャットボットを踏み台にする手口だ。中でも設計者が警戒すべきなのが、予算を焼き切ることだけを目的に同時大量リクエストを浴びせるDenial of Wallet、いわゆる財布への攻撃である。

技術的な核心

中継はどう組み立てられているか

ほぼすべての中継業者が、one-apiまたはnew-apiというオープンソースのAPIゲートウェイの上で動いている。どちらも本来は正当な用途を持つ、OpenAI互換のマルチプロバイダゲートウェイだ。

one-api 公式リポジトリ(GitHub)を見ると、その機能がそのまま転売インフラに転用できることが分かる。OpenAI、Azure、Claude、Gemini、DeepSeekなど20以上のプロバイダを単一のOpenAI互換エンドポイントに統合し、チャンネルという単位で複数の上流APIキーのプールを登録する。リクエストは複数チャンネルへ自動で分散され、失敗すれば別チャンネルへリトライされる。利用者ごとにアクセストークンを発行し、有効期限と利用上限、IP制限やモデル制限を設定でき、グループごとに課金倍率を変えることもできる。派生プロジェクトのnew-api(GitHub)も同系統だ。

正規のマルチプロバイダ運用と、転売プールの運用は、技術的にはほぼ同じ形をしている。違いは上流のキーが正当に契約されたものか、盗まれたカードや使い捨てアカウントで量産されたものか、その一点にある。つまりゲートウェイ自体は中立的な道具であり、悪いのは供給されるキーの出所だ。ここを混同すると、one-apiを使うこと自体が危険という誤った理解につながる。

利用者側から見た中継の透明性の低さも重要だ。中継は事実上のロードバランサとして振る舞うため、リクエストがどの上流に流れたかは見えない。議論では、劣ったモデルを黙ってすり替える差し替えの懸念や、エージェントの実行ログが保存され学習データとして再販売されるのではという懸念が指摘された。プロンプトに含まれる社内情報や顧客データが、どこの誰の手を経由し、どこに保存されるのか、買う側には原理的に確認できない。

Denial of Walletという攻撃クラス

この市場が正当な提供者側にもたらす最大の脅威が、Denial of Wallet、DoWだ。OWASPは2026年版のLLMアプリ脆弱性トップ10で、これをLLM10:2025 Unbounded Consumption(OWASP GenAI)として整理している。従量課金のクラウドAIでは、攻撃者が大量の推論を発生させるだけで、可用性ではなく請求額を破壊できる。サービスを落とすのではなく、財布を落とす攻撃だ。

自社がLLM機能を外部公開する場合、想定すべきリクエストは善意の利用者だけではない。無料枠を狙うボット、無防備なエンドポイントを転売プールの上流として使う中継業者、そして純粋に予算消尽を狙う攻撃者が混じる。ここで効いてくるのが上限設計である。

# 危険な構成(多くのPoCがこうなっている)
[利用者] --> [自社APIゲートウェイ] --> [LLMプロバイダ]
   認証なし / 上限なし / 同時実行制御なし / 予算アラートなし

# 求められる構成
[利用者] --> [認証・レート制限・同時実行制御] --> [予算ガード] --> [LLMプロバイダ]
              |                                    |
          テナント単位のクォータ              ハード上限で自動遮断

調査記事の著者は、検出手段としてカナリア値の埋め込みを最も現実的だと評価する一方、デバイスフィンガープリントは容易に回避されるとして懐疑的だった。攻撃者と守る側のいたちごっこにAIが拍車をかけており、綺麗な解決策は存在しないというのが結論に近い。だからこそ、検出に頼り切るのではなく、上限で被害額そのものを有限に閉じ込める設計が要になる。

日本の実務への示唆

日本の現場では、買う側と作る側の二方向で備えたい。

まず買う側だ。激安の中継APIは、コスト削減ではなくリスクの外部化であることが多い。プロンプトに社外秘や個人情報を載せて素性の知れない中継に流せば、委託先管理も越境データ移転の統制も効かず、個人情報保護法上の第三者提供や委託の観点で説明責任を果たせない。加えて、上流が盗難カードや不正アカウントで成り立っている以上、ある日突然すべてのキーが失効してサービスが止まるリスクを常に抱える。事業の基盤を、他人の不正の継続性に賭けることになる。調達の原則はシンプルで、LLM APIは公式か、正規の再販契約を明示するベンダーからのみ購入し、価格が公式から大きく乖離する中継は採用しない。

次に作る側だ。自社サービスにLLM機能を組み込むなら、DoWを前提に上限を多層で設計する。最低限、テナント単位とAPIキー単位のクォータ、同時実行数の制限、入力トークン長の上限、そしてプロバイダ側の予算上限とアラートを併用したい。多くのプロバイダは組織やキーの利用上限を設定でき、たとえばClaude APIのレート制限(platform.claude.com)のように、上限とヘッダによる残量の可視化が用意されている。これをアプリ側のクォータと二重にかける。

擬似コードで表すと、守りの骨格はこうなる。

def guarded_llm_call(tenant, req):
    # 1. 認証とテナント識別(匿名の従量アクセスを作らない)
    assert tenant.authenticated

    # 2. 入力サイズの上限(Uncontrolled Input Size 対策)
    if count_tokens(req.prompt) > MAX_INPUT_TOKENS:
        raise TooLarge

    # 3. テナント単位のレート制限と同時実行制御
    if not rate_limiter.allow(tenant.id):
        raise RateLimited
    with concurrency_guard(tenant.id, limit=MAX_CONCURRENCY):

        # 4. 予算ガード。当月消費が上限を超えたら即遮断
        if billing.month_spend(tenant.id) >= tenant.hard_cap:
            alert_ops(tenant.id)          # 運用へ通知
            raise BudgetExceeded

        # 5. 異常消費の記録。監視とカナリアで転用を検知
        with usage_logger(tenant.id):
            return provider.call(req)      # 上流のキーもキー単位で上限設定

ポイントは、匿名で無制限に叩けるエンドポイントを絶対に作らないこと、そして予算はソフトな警告ではなくハードな遮断として実装することだ。アラートだけでは、攻撃者が夜間に予算を焼き切る速度に人間が追いつけない。

セキュリティ運用の観点では、社内から素性不明のAI中継ドメインへの通信が出ていないか、egress監視で把握しておきたい。従業員が善意で激安APIを使い始めると、そこが機密の流出経路になる。国内の脅威動向としてはIPA 情報セキュリティ10大脅威 2026がサプライチェーンやクラウド不正利用を継続して挙げており、インシデント発生時はJPCERT/CCが相談窓口になる。

まとめ

激安AI APIの正体は、盗難カードと使い捨てアカウントを束ねた転売リレーであり、その市場が同時に、正規提供者を狙うDenial of Walletという攻撃を育てている。エンジニアが取るべきアクションは次の三つに集約できる。

第一に、買う側として、公式価格から大きく外れる中継APIを調達の選択肢から外し、プロンプトに載せるデータの越境と第三者提供を管理下に置く。第二に、作る側として、自社のLLMエンドポイントを認証、レート制限、同時実行制御、入力長制限、そしてハードな予算遮断で多層に守り、匿名の従量アクセスを作らない。第三に、運用として、素性不明のAI中継への通信をegress監視で捉え、カナリアと異常消費検知を仕込む。one-apiのようなゲートウェイ自体は中立の道具であり、問われているのは上流キーの出所と、上限設計の有無である。


参考ソース

3
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
3
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?