AIコーディングのAPIキー流出|内製で先に守る鍵と棚卸し5項目

AIコーディングのAPIキー流出

回答: AIコーディングツールを使った内製では、守る対象が「作ったコード」から「鍵」に移っています。2026年10月に公開された2件の事例では、狙われたのはソースコードではなく、APIキーとログイン済みの状態(セッション)が入ったファイルでした。鍵が外に出ると、作った仕組みが無事でも、請求とアクセス権だけが動きます。当てはまるのは、AIコーディングツールや生成AIを業務で使っている会社です。APIキーを発行していなくても対象から外れるわけではありません。 今回のマルウェアが集めるのはAPIキーだけでなく、ログイン済みの状態(cookie)やツールのトークンも含むため、業務PCでAIツールにログインしている人がいれば、その端末が感染した場合は対象に入ります。社内の誰もAIツールを使っていない場合、AIツールの認証情報を抜かれることはありませんが、Aoki はブラウザの保存情報やパスワード管理ツールも収集対象にしているため、感染の対象から外れるわけではありません。外部サービスとの連携アカウントにも同じ考え方が当てはまります。内製をやめる必要はありません。着手の順番として、鍵の置き場所と無効化の手順を先に決めます。

目次

この記事でわかること

  • 2026年10月に公開された2件(インフォスティーラー Aoki / OpenCode Console)で、実際に何が持ち出されたのか
  • なぜ「コードが盗まれていないから被害はない」と言えないのか
  • 不動産会社が反響対応の仕組みを内製している場合、鍵に何がぶら下がっているか
  • 今日できる棚卸し5項目と、よくある勘違い(ツール側から鍵を消しても無効化にはならない)

いま何が起きているか

答え: 2026年10月、AIコーディングツールの認証情報を対象にした事例が2件、別の経路で公開されました。いずれも他社の公開報告で、7plusの環境の話ではありません。

ここでは各社の公開情報に書かれている範囲だけを並べます。

1. 情報を抜き取るマルウェアが、AIツールの認証ファイルを対象に加えた

セキュリティ企業 Symantec の Threat Hunter Team が2026年10月15日に報告した内容です。インフォスティーラー(端末から情報を抜き取るマルウェア)「Aoki(Aokigahara)」の新しい検体が、AIコーディングツールの認証情報を収集対象に加えていました。

報道各社が共通して挙げている収集対象は次のとおりです。

分類 対象
設定ファイル `.claude.json`、Codex の `config.toml` と `.env`
ログイン済みの状態 Claude デスクトップの cookie、ChatGPT の cookie
トークン GitHub Copilot、Cursor、Gemini、JetBrains AI Assistant、Kiro
ローカルDB Cursor の local state database
クラウド AWS の認証情報

Codeium は Symantec の報告の概要部分では対象として挙げられていますが、後段の詳細なトークン一覧には含まれていません。報道各社の記載も揺れているため、ここでは参考として触れるだけにします。

押さえておきたい点が3つあります。

  • AIの提供元が侵害されたわけではありません。 持ち出されたのは、マルウェアに感染した端末(開発や作業に使っているPC)の中にあったファイルです
  • Aoki は2026年初頭に初めて確認されたもので、古い検体はAI関連ファイルを対象にしていませんでした。AI関連は後から追加された対象です。なお最新の検体は、ブラウザ・暗号資産ウォレット・パスワードマネージャー・メッセージングアプリ・VPN/FTPクライアント等からの窃取も引き続き行います
  • 動機は金銭目的とみられ、特定の攻撃グループとの結びつけは公表されていません

2. ホスティング側に保存されていたAPIキーが、取り出された可能性

もう1件は、オープンソースのAIコーディングエージェント「OpenCode」の運営が2026年10月17日に公表した件です。

  • 2026年10月16日の夜間に旧システムへの不正アクセスがあり、クラウド側の管理画面(OpenCode Console)に利用者が保存していた外部AIサービスのAPIキーが流出した可能性があると、翌17日に公表されました
  • 影響範囲はConsole利用者の約1.4%にあたると運営は説明しています
  • オープンソースのアプリとコマンドライン版は影響を受けていないと共同創業者が述べています
  • 公表後、身に覚えのない利用料が発生したという利用者の報告が出ています(いずれも個別の報告で、総額が独立に検証されたものではありません)
  • 提供元側も動いています。報道によると、Anthropic と Google は流出した可能性があると判断したAPIキーをブロックし、OpenAI は OpenCode と連携してアクセスを復旧し、攻撃で使われた分のクレジットをAPI利用者に返金したと説明しています
  • OpenCode は今回を大規模な「蒸留攻撃(distillation attack)」に関連づけて説明しています。侵入経路やキーの保存方法は公表されていません

1件目の出典は Symantec Threat Hunter Team の報告です。OpenCode の件は、現時点で同社の告知ページが公開されておらず、利用者へのメールと共同創業者の発言をもとにした報道が情報源です(TechCrunch(2026年10月19日))。日本語でのまとめは@ITの記事で読めます。

なお、Aoki の件については、盗まれたキーが実際に悪用されたかどうかは公表されていません。「必ず使われる」という前提で書くことはできません。

盗まれるのは「コード」ではなく「鍵」と「ログイン済みの状態」

答え: 作ったものは手元に残り、動き続けます。外に出るのは、そのツールが外部サービスを呼ぶための鍵と、ログイン済みの状態です。だから「コードは盗まれていない」は安心の根拠になりません。

この2件が示しているのは、守る対象の変化です。内製の話は長く「自社で作れるか・保守できるか」が論点でしたが、今回持ち出されたのは成果物ではありません。

鍵とログイン済みの状態が外に出ると、起きることは次の2つです。

  1. 請求が動く。 他人が自社の契約枠で生成AIを使えます。最初の兆候が「身に覚えのない利用料」になるのは、この順番だからです
  2. アクセス権が動く。 キーやトークンに紐づいた権限の範囲で、外部の人が自社の利用者と同じ立場で動けます。権限次第では、つながっているコード管理サービスやクラウド、自動実行の仕組みまで範囲が広がりうる、とSymantecは説明しています

ただし「コードは一切出ない」と言い切ることもできません。Symantec は、Cursor のローカルDBがチャットの文脈やコードの断片をキャッシュしうると指摘しています。主たる対象が鍵とログイン済みの状態である、という整理です。

逆に言えば、作った仕組みが止まらないため、処理を見ているだけでは気づけないのが厄介な点です。処理が落ちれば異常として見えますが、鍵が持ち出されただけなら、画面上は平常どおりです。手がかりになるのは、請求や外部からの連絡のほかに、提供元の利用履歴・監査ログ・利用量の通知、端末側のウイルス対策の検知です。どれを見る体制があるかで、気づくまでの時間が変わります。この「エラーにならないまま状態が変わる」構図は、自作の仕組みが黙って止まるときの気づきにくさと似ています(参考: GASのエラーに気づかず反響を取りこぼす理由と対策)。

不動産会社の反響対応に置き換えると、どこが動くか

答え: 反響メールを読む権限、顧客情報の保存先への書き込み権限、チャットへの通知権限です。内製した仕組みでは、これらがキーや連携アカウントにまとめてぶら下がっていることがあります。

以下は、不動産会社が反響対応の仕組みを内製している場合に、何が鍵に紐づいているかの整理です。公開された2件が不動産業について述べたものではない点はご注意ください。

鍵・認証の種類 紐づいている権限の例 外に出た場合に動くもの
生成AIサービスのAPIキー 返信文の下書き生成、文面の要約 自社の契約枠での不正利用。保存済みのデータに手が届くかは、サービスの仕様とキーの権限によります(提供元の仕様を要確認)
メール受信アカウントの認証 反響メールの読み取り 反響メール本文(氏名・連絡先・希望条件を含む)
顧客情報の保存先(スプレッドシート・CRM)の認証 台帳への書き込み・読み取り 過去分を含む顧客台帳
チャット連携(LINE WORKS 等)のトークン 通知の送信 社内チャットへの投稿
コード管理・自動実行サービスのトークン 仕組みの変更・実行 仕組みそのものの書き換え

ここで問題になりやすいのは、誰の名義で動いているかが分からない状態です。作った担当者の個人アカウントで鍵を発行し、そのまま運用しているケースでは、鍵の一覧も、利用状況の確認先も、本人の手元にしかありません。これは内製の属人化と地続きの話です(参考: GAS自作の属人化リスク)。業務システム側のログイン認証そのものについては不動産業務システムのログインはパスワードのままでよいかで整理しています。反響メールの個人情報を自作の仕組みで扱うときの注意点は反響メールの個人情報をGASで扱うときの落とし穴にまとめています。

今日できる棚卸し5項目

答え: 「どこに鍵があるか」「誰の名義か」「どこで無効化するか」の3点を書き出すところから始めます。設定変更より先に、一覧を作る作業です。

公開情報を踏まえて、社内で確認するための棚卸し項目を並べました。報道で案内されている対応(鍵の無効化と差し替え、直近の利用状況の確認)に、社内で決めておく項目を足しています。

  1. 鍵がどのファイルに入っているか把握する

`.env` と、各AIツールの設定ファイル(上の表に挙げたもの)に何が書かれているかを確認します。ツールを入れた本人以外は中身を知らないのが通常なので、まず「どのPCの、どのファイルに鍵があるか」を書き出します。

  1. 用途別に鍵を分ける

1本の鍵で複数の用途を兼ねていると、1か所の疑いで全部を止めることになります。検証用と本番用、仕組みごとに分けて発行しておくと、入れ替えの影響範囲が限定できます。

  1. 使っていない鍵を無効化する。ただし「提供元の画面で」

ここが今回いちばん実務的な学びです。OpenCode は影響を受けた可能性がある利用者に、各提供元(OpenAI・Anthropic・Google)のダッシュボードで鍵を無効化して差し替え、その鍵を使っているアプリ側も更新し、直近の利用状況を確認するよう案内しました。ツール側から鍵を消す操作と、提供元で無効化する操作は別だと考えてください。退職者が発行した鍵、検証で作ったまま残っている鍵は、提供元の画面で無効化します。

  1. 支出上限を設定し、利用状況を定期的に見る

請求が最初の兆候になりうるので、上限設定と、利用状況の確認先を決めておきます。確認の頻度は、利用額と業務の重要度に応じて決めます(利用量の通知を受け取れるサービスなら通知を使います)。確認先が担当者の個人アカウントだけになっていないかも合わせて見ます。

  1. 配布元を確認する

AI関連のツールや拡張機能を、どこから入れたかを確認します。インフォスティーラーは正規の配布物に見せかけて入ってくるため、入手経路の記録が確認の起点になります。

5項目とも「担当者名と確認日が入るか」で判断してください。名前が入らない項目は、誰も見ていない項目です。

これをやっても防げないこと

答え: 棚卸しは、鍵が外に出たときの範囲を狭める打ち手です。感染そのものを防ぐものではありません。

正直に書いておきます。

  • 鍵を分けても、端末が感染すればその端末にある鍵は対象になります。端末側の対策(OSと各ツールの更新、マルウェア対策、配布元の確認)は別に必要です
  • 無効化と再発行は、手順を誤ると動いている仕組みを止めます。使用中の鍵を先に無効化すれば、反響の通知が落ちます。新しい鍵へ差し替えてから旧鍵を無効化できるかは提供元の仕様によるため、先に手順を確認してから実施してください。流出が疑われる鍵は、一時的に止まることを承知のうえで無効化を優先します
  • 専用サービスを使えば鍵の管理が不要になるわけでもありません。外部サービスを使う場合も、連携アカウントの名義・権限・退職時の扱いは自社で決める必要があります

内製を否定する話ではありません。社内にAIコーディングツールを使える人がいること自体は強みです。論点は、その人が離れたときに鍵の一覧と無効化の手順が残るか、です。AIで作った仕組みを誰がどう確認するかという論点はAIで作るのは速い、では誰が確認するのかで扱っています。

よくある質問

社内でAIコーディングツールを使っていなければ、関係ありませんか

APIキーを発行していないことは、対象から外れる根拠にはなりません。Aoki が集めるのはAPIキーだけでなく、ログイン済みの状態(cookie)やツールのトークンです。業務PCで ChatGPT や Claude にログインしている人がいれば、その端末が感染した場合は対象に入ります。社内の誰もAIツールを使っていない場合、AIツールの認証情報を抜かれることはありません。ただし Aoki はブラウザの保存情報やパスワード管理ツールも収集対象にしているため、感染そのものの対象から外れるわけではありません。顧客情報を扱う仕組みを外部サービスと連携させているなら、連携アカウントのトークンも同じ考え方の対象になります。鍵の一覧を作る作業は、どの場合でも無駄になりません。

鍵を再発行すれば、流出した鍵はもう使えなくなりますか

再発行だけでは不十分な場合があります。新しい鍵を発行しても、古い鍵が自動で無効になるとは限りません。 提供元の仕様を確認し、古い鍵が失効したことを提供元の画面で確認してください。新しい鍵に差し替える作業と、古い鍵を無効化する作業は別だと考えておくと取りこぼしません。

自社が影響を受けたかどうかは、どう確認できますか

一般論として確認できるのは、提供元の利用状況と請求の履歴です。身に覚えのない利用があるか、いつもと違う時間帯や量の利用がないかを見ます。OpenCode の件では、影響を受けた可能性がある利用者には運営からメールで通知されたと公表されています。利用しているサービスからの通知を受け取るアドレスが、現在も読まれているかどうかも確認しておくとよいでしょう。

対策はどこから手を付けるべきですか

鍵の一覧作りからです。設定変更やツール導入より先に、「どの鍵が、どのPCの、どのファイルにあり、誰の名義で、どこで無効化できるか」を1枚にします。これがないと、何かあったときに止める対象が分かりません。

まとめ

公開された2件が示しているのは、内製の論点が「作れるか」だけでは済まなくなったことです。コードは残るのに、鍵だけが動く。作った仕組みが平常どおり動いているぶん、気づく契機が請求や外部からの連絡になりがちです。

今週できることは、鍵の一覧を1枚作ることだけでも十分です。そのうえで、使っていない鍵を提供元の画面で無効化する。この2つが、いちばん手数が少なく範囲を狭められる打ち手です。

反響の通知だけは、鍵の整理中も止めたくないという場合

Mail2Link は、ポータルサイトの反響メールを LINE WORKS・LINE・Chatwork へ転送・通知するサービスです。転送したメールの本文やファイルをサーバー・データベースに保存しない設計で、重複配信の判定にはハッシュ化したテキストのみを保持しています。自作の仕組みを整理している間の受け皿としても使えますが、連携アカウントの名義・権限・退職時の扱いは、どの手段を選んでも自社で決める必要があります。

Mail2Link の詳細を見る

—

この記事を書いた会社

7plus株式会社 不動産会社向けの営業DX支援を行うITソリューションプロバイダーです。反響対応を即時化する「Mail2Link」「Mail2Link×AI」、ノーコード業務アプリ「BizBlock」の開発・提供に加え、Salesforce認定パートナーとして不動産特化型Salesforceパッケージの導入・定着コンサルティングも行っています。

詳しくはこちら → https://7plus.jp/

この記事を書いた人

目次