本文へスキップ
>_ITDITDセキュリティ対策プラットフォーム

事故図鑑

高#アカウント凍結#APIキー悪用#AIサービス

OpenAIアカウントBANの理由と対処——盗まれたAPIキーが『蒸留』違反に問われるとき

OpenAIのアカウントが突然BAN（凍結）される——その一因に『盗まれたAPIキーが他者に悪用され、蒸留（distillation）ポリシー違反と自動判定される』パターンがあります。なぜ被害者まで凍結されるのか、未然に防ぐ鍵管理、そして万一のときの異議申し立ての考え方を、防御目線で一般化してまとめます。

公開日 2026-06-09 更新日 2026-06-13 10分で読める

セキュリティに詳しくない個人開発者にも起こりうる事故を、固有名詞や特定可能な情報を伏せて一般化した記事です。攻撃の再現手順は載せません。狙いは「同じ目に遭わないための備え」と「遭ってしまったときの落ち着いた対処」です。

事故サマリー — INCIDENT FILE
種別
アカウント凍結（BAN）／APIキーの盗用・悪用
きっかけ
盗まれたAPIキーが第三者に悪用される
判定理由
悪用の中身が『蒸留（distillation）』ポリシー違反と自動判定
特徴
操作したのは第三者でも、名義人のアカウントが凍結対象になる
予防
キーの分離・最小権限・利用量アラート・依存CVEの機械監視
対処
証拠保全 → 公式フォームで異議申し立て（ログで「人間業ではない」を示す）
自動
検知・凍結の主体
名義人
凍結される側
分離
予防の本命（鍵）
ログ
異議申し立ての武器

「課金を止めた」≠「対応完了」

不正課金を止めるのは止血にすぎません。漏洩経路を塞ぎ、名義に残った“違反記録”に対処するまでが本当の対応です。

なぜ被害者まで凍結されるのか

ポイントは、プラットフォーム側の判断が**「誰が操作したか」ではなく「その名義で何が起きたか」**に基づく点です。鍵の持ち主＝責任者という前提で、違反パターンが検知されればアカウントが止まります。

① APIキーが何らかの経路で第三者に渡る
↓
② 第三者が大量の出力を生成（ラベリング等）
↓ 自動検知が「蒸留」とみなす
③ 名義人のアカウントが自動で凍結
盗用キーの悪用が、名義人のアカウント凍結につながる流れ（概念図）。

『蒸留（distillation）』とは

強力なモデルの出力を大量に集め、その「入力→出力」ペアを教師データにして別のAIモデルを学習させる行為です。多くの主要AIプロバイダは、規約で自社の出力を使って競合モデルを作ることを禁止しています。大量のアノテーション生成やデータラベリングはこのパターンに一致しやすく、自動エンフォースメントが反応しやすい領域です。

つまり何が起きるか

盗んだ側にとって、他人のキーは「使い放題の計算資源」です。その使い道が規約違反級（蒸留・大量データ生成）だと、巻き添えで名義人のアカウントが止まります。盗用そのものより、盗用された後の使われ方が凍結の引き金になるのが、この事故の厄介なところです。

典型的な兆候（一般化）

実際のケースでは、凍結の前段に「身に覚えのない利用」が観測されることが多いです。固有の数値は伏せますが、共通する特徴は次のとおりです。

  1. 兆候① 利用量の異常

    ふだんの想定を大きく超える利用量・請求が、短時間に発生する。

  2. 兆候② 内容の不一致

    本人が使わないモデル・本人の用途と無関係な内容・本人の言語と異なる処理が走っている。

  3. 兆候③ 自動化の痕跡

    ごく短時間に大量のリクエストが集中し、出力の多くが空など、人手では起こり得ない分布になっている。

  4. 結果 アカウント凍結

    数日後、規約（蒸留等）違反を理由にアカウントが停止される。

兆候を見たら、決めつける前に生のログを見る。モデル・内容・言語・時間分布を見れば、それが自分の使い方かどうかは一目で分かります。

予防：事故が「広がらない」鍵設計

凍結の根を断つには、そもそも鍵を盗られない・盗られても被害を局所化することが効きます。

1

キーをサービスごとに分離する

1本のキーを複数プロジェクトで使い回さない。1か所の侵害が「アカウント全体の問題」に膨らむのを防ぐ。漏れても被害が1プロジェクトで止まる。
2

最小権限・上限を設定する

用途に必要な権限だけに絞り、利用上限（ハード/ソフトリミット）を設ける。盗用時の被害額と「規約違反級の使い込み」を物理的に抑える。
3

利用量アラートを張る

普段比で跳ねたら即通知。早期に気づければ、悪用が「蒸留級の規模」に育つ前に鍵を止められる。
4

漏洩経路＝依存CVEを機械監視する

鍵漏洩の多くは、放置した既知脆弱性（RCE等）でランタイムから抜かれる。依存CVEを機械に見張らせれば、人手の見落としを構造的に防げる。詳しくは CVEとは / CVE追従の運用。

鍵はファイル以外からも漏れる

コードやgitをgrepして平文の鍵が無くても安心はできません。実行中のプロセスの環境変数が、脆弱性（RCE）やHTTPヘッダ経由で抜かれることがあります。漏洩はファイルだけでなくランタイムでも起きます。RCEとは / .envとは。

万一BANされたら：異議申し立ての筋道

不正利用の客観証拠が手元にあれば、冷静に事実を提出することで道は開けます。鍵となるのは**「これは人間の操作ではあり得ない」をログで示す**ことです。

1

証拠を保全する

利用ログ（時間分布・モデル・内容・言語）と、鍵を無効化した記録、漏洩経路を塞いだ記録を保存する。後から再取得できない情報が多いので、まず保全。
2

公式フォームから事実を提出する

推測や感情ではなく、検証可能な事実を並べる。①ごく短時間への異常な集中＝自動化された悪用、②本人の用途・言語との不一致、③発覚後ただちにキーを削除し漏洩元も是正した誠実な対応。
3

フェーズで主張を切り替える

同じ事実でも、効く論点は局面で違う。返金交渉では「この使用は明らかに自分のものではない」を主役にし、凍結解除では「盗まれたキーで第三者がやった＝自分はやっていない」を積極的に主張する。

なぜ「人間業ではない」が効くのか

ごく短時間に大量のリクエストが集中し、出力の多くが空——といった分布は、正常な業務利用では説明がつきません。使用パターンの不自然さそのものが、「自分の操作ではない」を示す最も強い客観証拠になります。

やりがちな失敗と、正しい備え

やりがちな失敗

  • 1本のキーを複数プロジェクトで使い回す
  • 利用上限・異常アラートを設定していない
  • grepがcleanで「漏れていない」と安心する
  • 課金を止めただけで対応完了にする
  • 感情的に抗議し、客観証拠を整理しない

正しい備え

  • キーをサービスごとに分離し最小権限にする
  • ハード/ソフトの利用上限と異常アラートを張る
  • ランタイム漏洩（RCE・ヘッダ）も疑う
  • 止血と「漏洩経路を塞ぐ」を別作業として両方やる
  • ログで「人間業ではない」を淡々と示す

本件の決着（このケースのその後）

このパターンの事故では、ログという客観証拠を添えて異議申し立てを行った結果、アカウント自体は最終的に復旧した。一方で、不正利用された分の追加返金は受けられず、すでに適用済みのクレジット分でやり取りは終わっている。

ここにいちばんの教訓がある——アカウントが戻っても、流出した鍵で使われた費用は戻ってこない。 復旧まで時間も手間もかかる。だから本当の防御は「凍結されてから争う」ことではなく、鍵を漏らさない／漏れても利用量の上限で被害を止めるという事前設計にこそある。異議申し立ては最後の手段であって、最初の守りではない。

ひとことで言うと——盗用そのものより「盗用された後の使われ方」が凍結を招く。だから守りは鍵の設計に、対処はログの保全に宿る。

次に読む

よくある質問

Q自分は規約違反していないのに、なぜアカウントがBANされるの？
A

APIキーが盗まれ、第三者がそのキーで規約違反級の使い方（大量データ生成など）をすると、その活動はあなたの組織名義で記録されます。多くのプラットフォームは自動エンフォースメントで違反パターンを検知して凍結するため、操作したのが第三者でも、名義人であるあなたのアカウントが対象になり得ます。

Q『蒸留（distillation）』とは何ですか？
A

強力なモデルの出力を大量に集め、それを教師データにして別のAIモデルを学習させる行為です。多くの主要AIプロバイダの利用規約は、自社モデルの出力で競合モデルを作ることを禁止しています。大量のラベリングやアノテーション生成はこのパターンに合致しやすく、自動検知の対象になりがちです。

QBANされたら、まず何をすべき？
A

①不正利用の証拠（短時間への異常な集中、本人の用途と一致しない内容など）を保全し、②公式の異議申し立てフォームから事実を提出します。鍵が盗用されたこと、活動が自動化された悪用であることを、ログという客観証拠で示すのが要点です。