盗まれたAPIキーはどこで使われた？転売の中継「中転站」の正体

連載の第 2 回です。前の回は 第 1 回 AIのAPIキーが中国圏から不正利用された朝、まずしたことです。

侵入の跡が無いのに、AI の API キーは使われていました。この回では、キーがいつ、何に、どこで使われたかを、AI の提供元の利用の記録からたどります。結論は、キーは社内ではなく、外にある中継サービスの裏側で使われていた、です。確かめた被害額は約 11 ドルでした。

調査は、前の回と同じく Claude Code が、編集長の指示と承認のもとで行いました。

見る場所を変える

社内のサーバーに入られた跡が無いなら、キーを預けている側、つまり AI の提供元の記録を見るしかありません。提供元の管理画面には、キーごとの利用の記録があります。いつ、どのモデルが、どのくらい呼ばれたかが残っています。

ログイン済みの管理画面を借りて、その日に起きたことを分単位で並べ直しました。

なぜ、提供元の記録を見たのか

自分の側の記録で分かるのは、自分の側で起きたことだけです。キーが外で使われたのなら、その記録は、キーを預かっている提供元にしか残りません。

いつ、どのモデルが、どのくらい使われたか。被害の大きさを知り、止めるべきキーを決めるのにも、この記録が要ります。

時系列: 生存確認から、本番の利用まで

2026年10月15日の記録は、次のとおりです。時刻は日本時間です。

• 01:26 生存確認。 たった 1 分ほどの間に、その日使えたキーのすべてへ、ごく小さな問い合わせが飛びました。入力は 7 トークン、出力は 0 です。
• 02:57 もう一度、生存確認。 同じ顔ぶれへ、もう一度確かめています。
• 03:12 から 03:24 本番の利用。 使えるキーを均等に回して、合わせて約 580 回。画像の生成と大きなモデルが中心でした。
• 03:22 から 23 に失効、03:24 で記録が終わる。 こちらがキーを失効し始めると利用は止まり、記録は 03:24 で終わっています。

「生存確認」は、そのキーがまだ使えるかを確かめる、ごく小さな問い合わせです。中身のある仕事はさせず、つながるかだけを見ます。

調査を担当した AI の記録には、「動いているところから、ちょうど必要な分だけ集めてきた」とあります。叩かれていたのは、その日使えたキーだけでした。調査を担当した AI の記録には、この時系列を見た印象として「ぞっとするほど手際がよかった」とあります。

量は小さかった

使われたキーは 8 本、入力は約 100 万トークン、出力は約 36 万トークンでした。トークンは、AI が文字を数える単位です。API の料金は、この量で決まります。提供元の利用の記録で確かめた被害額は、約 11 ドルでした。

悪用が確かめられたのは、OpenAI のキー 8 本でした。記録には、「ここで一つ、胸をなで下ろすことがあった。叩かれていた鍵は、ほんのひと握りだった」ともあります。外に持ち出されたキーの本数や提供元ごとの内訳、集められた経緯は、第 3 回で説明します。

考察: なぜ、生きたキーだけが叩かれたのか

まず、確かめたことです。

• 01:26 に、その日使えたキーのすべてへ、ごく小さな問い合わせが来ました(入力 7 トークン、出力 0)。
• 03:12 からの本番は、使えるキーを均等に回していました。
• 持ち出された実在のキーは約 290 本でしたが、実際に使われたのは 8 本でした(第 3 回)。

次に、確かめていないことです。相手が手元に何本持っていたか、中継の中でキーをどう選んでいたかは、外からは見えません。8 本がすべて OpenAI のキーだったのも、中継が対応している提供元の都合かもしれませんが、確かめていません。

ここからは、編集部の推測です。小さな問い合わせは、キーがまだ使えるかを確かめるものだったと考えられます。失効したキーは、この段階で「使えない」と返ります。本番の前に選んでおけば、使えないキーで失敗を重ねずに済みます。そう考えると、数百本のうち、使えた数本だけが叩かれた説明がつきます。

拾った鍵を手に、マンションの部屋の鍵穴へ、順に差して回してみる動きに似ています。回らない鍵はその場に捨て、回る鍵だけを持ち帰ります。ここでは、回るキーだけが、次の工程へ進みました。

この見方に立つと、「使い終えたキーを失効する」ことが、そのまま守りになっていた、と読めます。失効して作り直したキーは、確認の段階で弾かれたとみられます。この話は、第 5 回で整理します。

何に使われたか: 3 種類のプロンプト

プロンプトは、AI に渡す指示の文章です。利用の記録から、叩かれていたプロンプトの中身を開きました。大きく 3 種類ありました。

1 つ目は、本番の利用です。 中国語で書かれた「B2B 邮件画板渲染与生成引擎」(B2B メール画板のレンダリング・生成エンジン)という題の、作り込まれたシステムプロンプトでした。システムプロンプトは、AI の役割をあらかじめ決める指示です。

中身は、海外向けの営業メールを自動で作る仕組みです。ある工具のブランドを名乗る売り込みのメールを、スペイン語やポルトガル語にして出力させていました。送り先の会社名と担当者名は、変数で流し込む作りです。

2 つ目は、採点です。 AI の出力を、別の AI に採点させる「評価ジャッジ」の指示が混じっていました。作った文面の質を、機械的に確かめる使い方です。

3 つ目は、接続テストです。 短い指示が大量にありました。たとえば、次のようなものです。

Reply with OK only.
Count from 1 to 5
これは接続確認ではありません。何もせず「了解」とだけ返してください。

どれも、中身のある仕事ではなく、AI につながるかを確かめる文です。キーをつなぎ込んだあとの動作確認に見えます。これは編集部の見立てで、確かめたわけではありません。

社内に無いプロンプトは、外で使われた証拠

次に、この中国語のシステムプロンプトが、社内のどこにあるかを探しました。社内のコードにも、記録にも、どこにもありませんでした。

このプロンプトは、社内のコードにもログにもありません。社内の仕組みが送ったものではないため、キーが社内で使われたのではなく、外のサービスに流し込まれて動いていた、と考えられます。侵入の跡が無いのに、キーが外で使われていた理由の、半分はこれで説明がつきます。残りの半分、キーがどうやって外に出たかは、第 3 回で説明します。

調査を担当した AI の記録は、この状況をこう書いています。「他人のクレジットで、知らない誰かに売り込みメールが飛んでいく」。

中継・転売のしくみ

盗んだキーを集めて、自分のサービスの裏側につなぎ、他人の請求で動かす。この基盤を、今回の調査では「中転站(ちゅうてんたん)」と呼びました。

利用者は、中継に払って AI を使います。中継は、束ねたキーを順に回します。使った分の請求は、キーの持ち主に届きます。利用者からは、裏側のキーが盗まれたものかどうかは見えません。

「中転站」という言葉

「中転站」は、調査で使った呼び方です。中国語の簡体字では「中转站」と書きます。

中国語の報道を確かめたところ、「API 中转站」「AI 中转站」は、利用者と AI の提供元の間に立つ代理の仕組みを指す言葉として使われていました。

• 36氪に掲載された寄稿(2026年5月13日)は、API の中转站を、利用者と AI の提供元の公式のサービスの間に立つ代理業者で、トークンの代理購入のようなものだと説明しています。利用者の依頼は、AI のモデルに直接ではなく、まず中转站のサーバーに届く、とも書いています。
• 每日经济新闻の調査記事(2026年9月29日)は、国家安全部の公式の微信の記事にある定義を引いて、「AI 中转站」を、利用者と AI のモデルの提供元の公式のサービスの間にある代理の層だと説明しています。各社の API を 1 つのプラットフォームにまとめて利用者に提供する、という説明も添えています。

ただし、この 2 つの記事は、中継というサービスの一般的な説明です。盗まれたキーが使われている、と書いた資料は、編集部が確かめた範囲では、ありませんでした。つまり、今回の「中転站」は、中国語圏で使われる言葉を借りた、編集部の呼び方です。

公開の調査で確かめた、盗んだキーの中継・転売

盗まれた資格情報が中継・転売で使われる手口は、今回が初めてではありません。確かめられた公開の調査は、次の 2 つです。

Sysdig の「LLMjacking」(2024年5月6日)。 セキュリティ企業の Sysdig は、盗んだクラウドの資格情報で AI のモデルを使う攻撃を「LLMjacking」と名づけました。最初に調べた事例では、欠陥のあるバージョンのウェブフレームワークが動くシステムから、資格情報が取られていました。攻撃者のスクリプトは、10 の AI サービスについて、資格情報が使えるかを調べていました。しかも、できることと上限が分かる程度の、最小限の問い合わせです。

同社は、LLM 向けの中継(リバースプロキシ)が使われた形跡も見つけています。中継を使うと、複数のアカウントへのアクセスを、元の資格情報を見せずにまとめて管理できます。同社の調査は、攻撃者が LLM のアクセスを売ることを意図している、と述べています。その場合、クラウドのアカウントの持ち主が請求を払います。

Microsoft の民事訴訟(2025年1月10日)。 Microsoft は、あるグループが、公開のウェブサイトから集めた顧客の資格情報を悪用するソフトを作り、そのアクセスを別の悪意ある者へ転売した、と主張しています。これは、同社が裁判所に出した内容に基づく主張です。

今回の記録は、この 2 つと似ています。使えるキーだけにごく小さな問い合わせを送る点は、Sysdig の報告にある確認の形と近いものです。ただし、同じ攻撃者だと言えるものは、何もありません。

昔と、いまの比べ

盗まれた資格情報で AI を使う攻撃は、2024 年に「LLMjacking」と名づけられました。同年 5 月 6 日の Sysdig の報告で狙われていたのは、クラウドの資格情報です。同社は、最大限に使われた場合、被害者の負担が 1 日 4 万 6 千ドルを超えうる、と試算しました。実際の被害額ではなく、最悪の場合の計算です。

2025 年 2 月 7 日の Sysdig の報告は、様子が変わったことを伝えています。DeepSeek-V3 が 2024 年 12 月 26 日に出ると、数日後には、ある中継に組み込まれていました。その中継には、DeepSeek の API キーがすでに 55 本、入っていたといいます。

今回は、クラウド全体の資格情報ではなく、AI の提供元が出す API キーそのものが、束ねられていました。盗まれる単位が、キー 1 本まで小さくなり、新しいモデルが中継に取り込まれる速さも上がっている、と編集部は読んでいます。ただし、これは公開の報告から読み取った印象で、全体の傾向を数えたものではありません。

自分の利用の記録で、まず見ること

読んでいるあなたが、自分のキーの利用の記録を見るときの 5 つです。編集部の考えで、提供元ごとに画面は違います。

1. 使った覚えのない時間に、使われていないか。
2. 使った覚えのないモデルや、画像の生成が混じっていないか。
3. 量が、普段と桁違いに増えていないか。
4. ごく小さな問い合わせが、複数のキーに一斉に来ていないか。
5. 自分のプログラムに無い、知らない指示の文章が入っていないか。

見つけたら、そのキーを先に失効します。OpenAI の公式の案内も、漏れが疑われるときは、すぐにキーを失効して新しいキーに入れ替えるよう書いています。調べるのは、そのあとです。

この回で分かったこと

読んでいるあなたへ

被害額が小さくても、キーが外の中継に取り込まれた事実は変わりません。使われていなくても、見つかったキーは、失効して作り直す対象です。

次にやること(この回の話から)

1. 提供元の管理画面で、キーごとの利用の記録が見られる場所を、今日一度開いて確かめる。いざというときに、探す時間をなくせます。
2. 覚えのない利用を見つけたとき、だれが連絡を受け、だれがキーを失効するかを、先に決めておく。
3. 自分のプログラムが送る指示の文章(プロンプト)を、一覧にしておく。一覧にないものが記録に出たら、外で使われた手がかりになります。

次の回へ

では、そのキーは、どうやって外へ持ち出されたのでしょうか。侵入の跡は無いのに、数百本のキーが一か所に集められていました。入り口は、全台の控えを集める台の管理画面にありました。第 3 回 入口はバックアップの管理画面だった。認証の手前の欠陥と「pakchoi」に続きます。