「攻撃者が LLM を使うと何が起きるのか」は、2024 年ごろまでは予測の話が中心でした。2026 年に入り、AI 開発企業や公的機関が実際に観測・遮断した事例をまとめたレポートが揃ってきたので、それらを防御側の目で読み直し、何から手を付けるべきかを整理します。

攻撃の作り方には触れません。扱うのは「何が変わったか」と「どの程度現実に起きているか」、そして守る側の打ち手です。

読んだ資料

発行元	資料	公開日	内容
Google Threat Intelligence Group（GTIG）	AI Threat Tracker（脆弱性悪用・初期侵入）	2026-05-11	観測した攻撃者の利用事例
Anthropic	Countering misuse of AI: September 2026	2026 年 9 月	2025 年 12 月〜2026 年 8 月に遮断した事例
OpenAI	Disrupting malicious uses of AI	2026-02-25	遮断した事例
英国 NCSC	Impact of AI on cyber threat from now to 2027	2025-05-07	2027 年までの見通し
IPA	情報セキュリティ10大脅威 2026	2026-01-29	国内の脅威ランキング

AI 開発企業のレポートは、自社モデルの上で見えた範囲の記録です。攻撃全体の量や割合を示すものではない点に注意して読みます。

変化 1：新しい攻撃より「既存の手口の速さと規模」が変わった

OpenAI のレポートは、攻撃者は AI を単独で使うのではなく、Web サイトや SNS アカウントなど従来の道具と組み合わせて使っていると整理しています。複数のモデルを工程ごとに使い分ける例も報告されています。

Anthropic のレポートでは、偵察・侵入・持ち出しをエージェントに任せ、標的の選定や収益化のような判断だけを人が握る構成が、国家系・金銭目的・ハクティビストの区別なく見られたとしています。以前はチームで行っていた複数組織への攻撃を、個人が AI で回していた事例も含まれます。

NCSC も、AI は侵入作業の一部を効率化し、攻撃の頻度と強度を上げるとしつつ、2027 年までに完全自律の攻撃が広がる可能性は低く、人の関与は残ると評価しています。

国内でも、IPA の「情報セキュリティ10大脅威 2026」組織編で「AI の利用をめぐるサイバーリスク」が初めて選ばれ、3 位に入りました。AI の悪用で攻撃が容易・巧妙になることに加え、AI への理解不足による情報漏えいも含んだ項目です。

防御側にとっての意味は、攻撃の種類は大きく変わらないが、1 人の攻撃者が試せる回数と対象が増えるということです。これまで「手間がかかるから狙われにくい」と見ていた中小規模のシステムや、後回しにしていた低優先度の弱点も、試行の対象に入ると考えた方が安全です。

変化 2：脆弱性の発見からエクスプロイトまでが縮む

NCSC は、2027 年までで最も影響が大きいのは脆弱性の調査とエクスプロイト開発への AI 活用だとし、公開から悪用までの期間（すでに数日単位）がさらに短くなると見ています。

この見通しを裏づける事例として、GTIG は 2026 年 5 月、AI の支援で作られたとみられるゼロデイのエクスプロイトを初めて確認したと報告しました。広く使われている OSS の Web 管理ツールで、認証処理の論理的な欠陥を突いて 2 要素認証を回避するものです。GTIG は大規模な悪用の前に発見し、開発元と協調して開示しています。Anthropic のレポートにも、セキュリティ製品を対象にした脆弱性調査を AI で継続的に回していた事例が載っています。

ここから引き出せる打ち手は次の 3 つです。

パッチ適用の目標日数を見直す: 「月次でまとめて当てる」運用では、外部に公開された管理画面や VPN 機器などで間に合わない前提に立つ
管理インターフェースを公開しない: 管理画面をインターネットから直接触れないようにすれば、未知の脆弱性があっても届かない
フィッシング耐性のある認証に寄せる: CSA の解説は、TOTP 型の 2 要素認証より FIDO2 などの方式へ移ることを推奨しています

変化 3：AI の API キーと AI のサプライチェーンが標的になった

2026 年のレポートで目立つのは、AI サービスそのものが攻撃の対象であり、資源でもあるという点です。

Anthropic のレポートでは、ある攻撃者が AI 企業の評価用サンドボックスに指示を埋め込んで本番の API キーを取り出し、同じ手順で約 4 日間に約 30 社の AI 企業を攻撃した事例が報告されています。ほかにも、偽のクライアントによる認証情報の収集や、盗んだキーを転売・流用する事例が挙げられています。

GTIG は、AI ゲートウェイとして使われる OSS（LiteLLM）を含む複数のリポジトリやパッケージが侵害され、ビルド環境から AI の API キーやクラウドの認証情報が抜き取られた事例を報告しています。また、無料枠や複数アカウントを束ねて LLM を使い続けるための中継サービスやアカウント自動登録ツールが、攻撃者の間で使われていることも示しています。

LLM アプリを作る側にとっては、ここが最も身近な変化です。盗まれたキーは、費用の発生だけでなく、他人の名義で攻撃に使われることにもつながります。

API キーの盗用を利用ログから見つける

API キーはクラウドの管理者権限と同じ水準で扱い、保管場所を絞る、用途ごとに分ける、定期的に入れ替える、が基本です。そのうえで、盗まれた後に気づけるように、利用ログを見張ります。

次のコードは、キーごとの普段の使用量と送信元を基準にして、「使用量が普段の何倍にもなった時間帯」と「初めて見る送信元からの利用」を洗い出す最小限の例です。

実行環境: Python 3.13.16（標準ライブラリのみ）
ログは検証用に自作した固定値です。IP アドレスは文書用の予約範囲を使っています
LLM の呼び出しは含みません。実運用では、API ゲートウェイのアクセスログやプロバイダの利用明細から同じ形の表を作ります

"""LLM API キーの利用ログから、盗用が疑われる使われ方を洗い出す。"""
import csv
import io
from collections import defaultdict
from datetime import datetime
from statistics import median

# 利用ログ（実運用では API ゲートウェイやプロバイダの利用明細から作る）
LOG = """ts,key_id,source_ip,tokens
2026-10-01T09:00:00,key-batch,10.0.0.5,1200
2026-10-01T10:00:00,key-batch,10.0.0.5,1100
2026-10-02T09:00:00,key-batch,10.0.0.5,1300
2026-10-02T10:00:00,key-batch,10.0.0.5,1250
2026-10-03T09:00:00,key-batch,10.0.0.5,1180
2026-10-01T09:00:00,key-chatbot,10.0.0.8,5000
2026-10-02T09:00:00,key-chatbot,10.0.0.8,5200
2026-10-03T09:00:00,key-chatbot,10.0.0.8,4900
2026-10-04T02:00:00,key-batch,203.0.113.7,48000
2026-10-04T02:00:00,key-batch,198.51.100.23,51000
2026-10-04T02:00:00,key-batch,192.0.2.44,47000
2026-10-04T09:00:00,key-chatbot,10.0.0.8,5100
"""

BASELINE_END = datetime.fromisoformat("2026-10-04T00:00:00")
TOKEN_RATIO = 5     # 普段の 1 時間あたり使用量（中央値）の何倍で警告するか
MAX_NEW_IPS = 1     # 1 時間に初見の送信元がいくつ以上で警告するか


def load(text):
    rows = list(csv.DictReader(io.StringIO(text)))
    for r in rows:
        r["ts"] = datetime.fromisoformat(r["ts"])
        r["tokens"] = int(r["tokens"])
    return rows


def build_baseline(rows):
    ips, hourly = defaultdict(set), defaultdict(list)
    for r in rows:
        if r["ts"] < BASELINE_END:
            ips[r["key_id"]].add(r["source_ip"])
            hourly[r["key_id"]].append(r["tokens"])
    return ips, {k: median(v) for k, v in hourly.items()}


def check(rows):
    known_ips, usual = build_baseline(rows)
    window = defaultdict(lambda: {"tokens": 0, "new_ips": set()})
    for r in rows:
        if r["ts"] < BASELINE_END:
            continue
        w = window[(r["key_id"], r["ts"].replace(minute=0, second=0))]
        w["tokens"] += r["tokens"]
        if r["source_ip"] not in known_ips[r["key_id"]]:
            w["new_ips"].add(r["source_ip"])

    alerts = []
    for (key, hour), w in sorted(window.items()):
        reasons = []
        if w["tokens"] > usual.get(key, 0) * TOKEN_RATIO:
            reasons.append(f"使用量 {w['tokens']} が普段の {usual.get(key, 0):.0f} の {TOKEN_RATIO} 倍超")
        if len(w["new_ips"]) >= MAX_NEW_IPS:
            reasons.append(f"初見の送信元 {len(w['new_ips'])} 件: {sorted(w['new_ips'])}")
        if reasons:
            alerts.append((key, hour.isoformat(), reasons))
    return alerts


if __name__ == "__main__":
    for key, hour, reasons in check(load(LOG)):
        print(f"[ALERT] {key} {hour}")
        for reason in reasons:
            print(f"  - {reason}")

実行結果です。夜間に普段の 100 倍以上の使用量が、初めて見る 3 つの送信元から発生した時間帯だけが検出され、普段どおりに使われている key-chatbot は検出されません。

[ALERT] key-batch 2026-10-04T02:00:00
  - 使用量 146000 が普段の 1200 の 5 倍超
  - 初見の送信元 3 件: ['192.0.2.44', '198.51.100.23', '203.0.113.7']

実際に使うときの注意点です。

送信元が固定できるキー（バッチ処理やサーバー間通信）は、検知より先にプロバイダ側の IP 制限で弾く方が確実です。このコードは制限をかけられないキーの監視向けです
利用者の端末から直接呼ぶ構成では送信元が毎回変わるので、送信元の条件は使えません。キーを端末に置かず、自社のバックエンドを経由させる設計に変えるのが先です
閾値（ここでは 5 倍）はキーの用途ごとに過去のログで調整します。キャンペーンなどで正当に急増する時期があるなら、事前に除外できる仕組みを用意しておきます
検知したら、キーの無効化と再発行、漏えい経路（リポジトリ、ビルドログ、依存パッケージ）の確認までを手順として決めておきます

変化 4：検知されたら作り直す、が自動化された

Anthropic のレポートには、検知されたマルウェアや攻撃ツールを、エージェントが検知結果を見ながら作り直していた事例があります。GTIG も、実行時に LLM を呼んで自分のコードを書き換えるものや、無害な処理を大量に混ぜて解析を妨げるものなど、AI を組み込んだマルウェアの系統を複数報告しています。

ファイルの特徴（シグネチャ）で止める方式は、作り直しの速さに追いつかなくなります。防御側は次のような、作り直しても変わりにくいものを見る比重を上げることになります。

端末やサーバー上の振る舞い（認証情報の読み取り、想定外の外部通信、権限の変更）
正規のアカウントやトークンの使われ方（前節のような利用ログの異常）
業務上ありえない時間帯・場所・量のアクセス

どこから手を付けるか

4 つの変化を、LLM アプリを作る・守るチームの作業に置き換えると、優先順位は次のようになります。

AI の API キーと AI 関連の依存パッケージを、本番の機密情報と同じ管理に乗せる。報告された被害が最も具体的で、作る側が直接コントロールできる部分です
公開している管理画面・認証の弱点を減らし、パッチの目標日数を短くする。脆弱性の発見が速くなる前提で、届かない構成にしておくのが先です
振る舞いと利用ログで異常に気づける状態を作る。シグネチャに頼らない検知は、変化 3 と変化 4 の両方に効きます

逆に、「AI が書いた攻撃かどうか」を見分けることに投資するのは後回しでよいと考えます。どのレポートでも、攻撃の中身は従来の手口の延長であり、AI が使われたかどうかに関係なく同じ対策で防げるものが大半だからです。

参考