AIツールをチームで使い始めると、APIキーの管理やコスト管理が思った以上に難しくなってきます。そこに新しい脅威が加わりました。2026年、AIコーディングツールのOpenCodeで「蒸留攻撃（distillation attack）」と呼ばれる手口によって、一部ユーザーのOpenAI・Anthropic・Google向けAPI残高が無断で消費されるインシデントが発生しました。影響を受けたのは全ユーザーの約1.4%とされていますが、この事例が示しているのは「大手AIプロバイダーはセキュリティを強化した、その分だけ小規模な中間業者のほうが狙われやすくなった」という構造的な変化です。この記事では、蒸留攻撃の仕組みと、自社のAI利用環境で確認すべきポイントを整理します。
「蒸留攻撃」とは何か
蒸留攻撃とは、もともとAI研究の文脈では「大きなモデルの知識を小さなモデルに転写する」手法を指す言葉でした。しかしセキュリティの文脈では意味が広がっており、今回のOpenCodeのケースでは「中間サービスに保存・設定されているAPIキーや認証情報を悪用して、外部のAIサービスへのアクセスを無断で消費する」攻撃として使われています。平たく言えば、誰かが自分のAPI残高を使って大量のAIリクエストを投げ続けた、ということです。
なぜこういう攻撃が成り立つかというと、構造上の問題があります。たとえばOpenCodeのようなサービスは、ユーザーが入力したAPIキー（OpenAIやAnthropicと契約した際に発行される認証コード）を経由して、ユーザーの代わりにAIを呼び出します。このAPIキーが外部に漏れたり、サービス側のシステムに脆弱性があったりすると、攻撃者はそのキーを使って残高が尽きるまでリクエストを送り続けられます。ユーザー本人は請求通知が届くか残高ゼロの通知が来るまで気づけない、というのが怖いところです。
今回のOpenCodeの声明で注目されたのは、「大手AIラボ（OpenAI・Anthropic・Google）側はすでにこのベクターへの対策を強化していた」という点です。つまり、正面から大手に攻撃するのが難しくなった分、その手前にある中小規模のプロバイダーやツールが新たな攻撃対象になっているという見方ができます。
影響を受けるのはどんな会社か
OpenCode自体は主にエンジニアやコードを書く担当者向けのAIツールですが、この問題が示す構造は、APIキーを経由してAIを利用しているすべての会社に当てはまります。たとえば次のようなケースです。
- ChatGPTやClaudeのAPIを契約し、社内のチャットボットや自動化ツールに組み込んでいる
- 複数のAIサービスをまとめて管理できる「AIハブ」系ツールや、個人開発者が作ったAPIラッパーを経由して使っている
- 担当者が個人名義でAPIキーを取得し、チームで使うツールに設定している
特に3番目のパターンは中小企業でよく見られます。「とりあえず詳しい担当者が自分のカードで契約して、チームで使えるようにした」という状況は、その担当者が退職した後もキーが生き続けていたり、誰も残高を監視していなかったりするリスクにつながります。
小規模プロバイダー経由で何が変わったか
OpenAIやAnthropicといった大手は、不正利用の検知・ブロック・通知の仕組みに継続的に投資しています。異常なリクエスト量の検出や、地域をまたいだ同一キーの使用検知など、いわば「銀行のカード不正利用検知」に近い仕組みが整いつつあります。
一方、小規模なサードパーティツールやAPIを中継するサービスは、そこまでの体制を持てていないことが多いです。OpenCodeのケースでも、ユーザーへの通知が「インシデント後のメール」という形でした。リアルタイムで止める仕組みよりも、被害が出てから知らせる形になっています。これは小規模サービスとしては「ある意味しかたない」面もあるのですが、使う側はそのリスクを理解した上で判断する必要があります。
ここで参考になるのが、AI利用の実態です。国内の中小企業（従業員10〜100人規模）では、複数のAIツールを部門や担当者ごとにバラバラに契約・利用しているケースが増えています。APIキーを「誰が管理しているか」を聞くと、「担当者個人が持っている」と答える会社が過半数を超えるという傾向があります。セキュリティインシデントが起きたとき、どのキーがどこで使われているかをすぐに把握できる体制がある会社は、まだごく少数です。こうした状況が続く限り、今回のOpenCodeのような事例は他のツールでも起きる可能性があります。
自社のAI利用環境で今確認すべきこと
技術的な実装の話ではなく、管理者や経営者が「今日確認できること」を整理します。
まず、自社でAIサービスのAPIキーを何本発行しているかを把握することから始まります。OpenAIなら管理画面の「API keys」ページ、Anthropicなら「Console」のキー一覧で確認できます。発行したまま使っていないキーがあれば、即座に無効化します。「使っているか分からない」キーは、いったん無効にして動作確認するほうが安全です。
次に、利用量（Usage）とコストのアラートを設定します。OpenAIもAnthropicも、一定の金額を超えたらメールで通知する設定が管理画面から設定できます。月の予算が5,000円なら10,000円で通知、というように上限の2倍程度に設定しておくと、不正利用に早く気づけます。Google Cloudのgemini APIも同様にBudget Alertが使えます。
サードパーティのAIツールを経由している場合は、そのツールの利用規約とセキュリティ体制をあらためて確認することを勧めます。「SOC2取得済み」「ISO 27001認証」といった第三者認証の有無、インシデント発生時の通知手順が明記されているかどうかが判断の目安になります。認証も開示もない小規模ツールを業務の基幹に使うのは、リスクが高いと言えます。
APIキーの管理を「担当者個人」に任せているなら、チームで共有できる管理方法に切り替えることも検討に値します。たとえばAWSのSecrets ManagerやGoogle Secret Managerを使ってキーを一元管理する方法がありますが、これは少しITの知識が必要です。もっと手軽なところでは、1Passwordのようなパスワードマネージャーのチーム版でAPIキーを共有管理する方法もあります。プロンプトの書き方ガイドで触れているAI活用の前提として、「誰が何を管理しているか」を明確にしておくことが基礎になります。
「大手直接契約」vs「中間ツール経由」のリスク比較
以下は、OpenAI・Anthropicなどの大手と直接契約する場合と、サードパーティのAPIハブやツールを経由する場合の違いを整理したものです。
| 観点 | 大手と直接契約 | サードパーティ経由 |
|---|---|---|
| セキュリティ体制 | 充実している（不正検知・通知あり） | ツールによって大きく異なる |
| コスト管理 | 管理画面で詳細に確認可 | ツール側の集計に依存することが多い |
| 不正利用時の被害範囲 | 1サービスのみ | 複数サービスのキーを預けている場合は広がりやすい |
| 利便性 | ツールごとに契約・設定が必要 | 1つの契約で複数モデルを使えることが多い |
| 推奨ケース | 継続的に使う会社 | 複数モデルを比較したい・試したい段階 |
利便性のためにサードパーティを使うことを否定するわけではありません。ただ、本番業務で毎日使うレベルになっているなら、大手と直接契約した上でAPIキーを自社で管理する形に移行するほうが、リスクの観点では合理的です。ChatGPTの使い方ガイドでも整理しているように、業務で継続的に使うツールは「ちゃんとした正規ルート」で契約・管理することが長期的には安定します。
まとめ
今回のOpenCodeのインシデントが示したのは、AIセキュリティの戦線が「大手ラボへの直接攻撃」から「周辺ツールを経由した間接攻撃」へ移りつつあるという変化です。大手が守りを固めた分、その周囲が狙われやすくなるというのは、自然な流れとも言えます。
自社のAI利用が「誰がキーを持っているか分からない」「残高を誰も監視していない」という状態であれば、今日すぐに確認できることがあります。AI導入を進めている最中の会社にとって、こうしたリスク管理の整備が「後回し」になりがちなのは分かりますが、被害が出てから対処するほうがはるかにコストがかかります。
自社の状況を整理したいが何から手をつければよいか分からない、という場合は、AI導入・社内研修の専門家に相談することも一つの選択肢です。
