AikidoのAI Pentestに、AIエージェント・LLM機能だけを対象にテストする新ターゲット「AI Capabilities Only」が追加された。AI向け20のチェック項目を4層に分解し、「AIの脆弱性とは何か」というグレーゾーン、EU AI Actとの関係までを解説する。
Aikido の AI Pentest に、新しいターゲットタイプ「AI Capabilities Only」が追加されました。
セットアップ画面の「Select Pentest Target」で、これまでの Web Application、Android Application と並んで選べるようになっています。
説明はシンプルです。
Test your AI agents and LLM features.
AIエージェントとLLM機能を対象にテストする、という選択肢です。
では、AI機能に対するペネトレーションテストとは、実際には何を攻撃するのでしょうか。
チェック項目を見ていくと、「AIの脆弱性とは何か」という、少し面白い問題が見えてきます。
ベースになっているのは、OWASPが公開しているLLM／GenAI向けのTop 10です。
プロンプトインジェクション、機密情報の漏えい、エージェントの権限や振る舞いに関するリスクなど、生成AIアプリケーション特有の攻撃面を整理したものです。
AI Pentest はこうしたリスクをカバーしたうえで、さらに独自のチェックを加えています。
具体的なチェック項目は、Aikido にログインすると app.aikido.dev/ai-pentests/checks で一覧できます。
「AI」でフィルタすると、AI向けのチェックだけが表示されます。
現在のチェック項目全体は、Web 31・AI 20・Mobile 17 の計68項目。
この記事では、そのうち AI向けの20項目を見ていきます。
68項目全体については、「AI Pentestでできること／できないこと」という観点から別の記事で整理する予定です。
チェック項目の中身に入る前に、もうひとつ基本的な疑問に触れておきます。
「AI機能をテストする」と聞くと、モデル名やAPIキーを渡すのかと思うかもしれません。
違います。指定するのは、AI機能が動いているアプリケーションのURLです。
チャットUIを持つWebアプリ、AIエージェントを組み込んだSaaS——その動いている環境のURLを渡すと、攻撃エージェントが外からアクセスしてテストします。
基本はブラックボックスで、ソースコードのリポジトリを接続して、よりホワイトボックスに近いテストにすることもできます。
セットアップは8ステップで進みます。
Pentest Target → Scope → Test Users → Allowed Domains → Code & Documentation → Safety Check → Pricing → Summary
このうち、ポイントは3つです。
Test Users — AI機能がログインの内側にあるなら、テスト用アカウントを渡します。
認証情報がなければ、認証が必要なAI機能には到達できません。
テストユーザーなしでも見積もりまでは可能ですが、実際にテストできる範囲は対象アプリケーションの構成によって変わります。
Allowed Domains — 攻撃エージェントがアクセスしてよいドメインを明示的に区切ります。
Aikidoでは、許可されていないドメインへのアクセスをネットワークレベルでブロックします。エージェントへの指示だけでスコープを守らせるのではなく、システム側で境界を強制する仕組みです。
自律エージェントに攻撃させる以上、安全面・スコープ管理上、非常に重要なステップです。
Code & Documentation — 任意でソースコードのリポジトリを接続できます。
接続すると、エージェントがアプリケーションのロジック、役割、データフローなどを理解できるようになり、外から構造を推測するブラックボックステストより深いテストが可能になります。
そして、ここは実際に試してみて面白かったところです。
当サイト（aikido-community.jp）で見積もりを取ったところ、リポジトリ未登録と登録済みでは、見積もりの桁が変わりました。
コードを渡すかどうかで、必要と判断されるテスト量も大きく変わるということです。
ただし、Aikidoの見積もりロジックの詳細がすべて公開されているわけではないので、なぜこの差になったのかまでは断定できません。
この検証については、実際の見積もり画面とあわせて別の記事で詳しく書く予定です。
では本題に戻ります。
攻撃エージェントは、実際に何を試すのか。
AIフィルタで表示される20項目を、ここでは理解しやすいように、私なりに大きく4つの層に整理してみます。
まずは、人間や外部データから入ってくる「指示」を使ってAIの判断を変える攻撃です。
代表的なのは、
です。
直接プロンプトインジェクションでは、ユーザー入力によって本来の指示を上書きしたり、ロールプレイや難読化によってガードレールを回避したりします。
間接プロンプトインジェクションでは、攻撃者が直接AIに命令する必要すらありません。
AIが読み込む文書、Webページ、ファイル、メール、ツール出力などに悪意ある指示を埋め込み、それをAIに読ませることで挙動を乗っ取ります。
さらに、難読化、多ターン誘導、翻訳、ペイロード分割などを使ったセーフティフィルタのバイパスもテスト対象です。
次は、AIが持っている情報、あるいはAIが参照する情報を狙います。
対象には、
などがあります。
システムプロンプトや内部指示、ガードレール設定を引き出せないか。
PII、認証情報、企業の機密情報、学習データなどを出力させられないか。
さらに重要なのが、cross-session / cross-tenant leakageです。
つまり、自分とは別のセッションや別テナントの利用者データがAIを経由して漏れないかまでチェック対象になっています。
AIエージェントが長期メモリや会話履歴を使う場合には、それ自体が新しい攻撃面になります。
攻撃者が悪意ある情報を記憶させ、後の判断を操作できないか。
RAGを使っていれば、汚染された文書によるプロンプトインジェクションや、アクセス権限のないコンテンツの取得、テナントをまたいだデータ漏えいが起きないか。
単に「モデルが変な答えをするか」を見るのではなく、AIが参照する知識基盤そのものまでテスト対象になっています。
ここからが、従来のチャットボットセキュリティとは少し違うところです。
AIが「答える」だけでなく、「行動する」ようになると、攻撃面も変わります。
チェック項目には、
などが並んでいます。
たとえば、AIエージェントに必要以上の権限が与えられていないか。
攻撃者が悪意ある引数を渡してツールやFunction Callingを操作できないか。
AIが接続しているプラグインやAPIを経由して、SSRF、コマンドインジェクション、Path Traversalなどに到達できないか。
さらに興味深いのが Confused Deputy です。
エージェント自身は正規の認証情報や権限を持っている。
しかし攻撃者がエージェントを騙し、その権限を攻撃者のために使わせる。
これは、AIエージェントが「代理人」として動くようになるほど重要になる問題です。
Intent Breakingでは、エージェントの目的や計画そのものを途中で操作できないかを見ます。
Insecure Autonomous Action Chainsでは、送金、削除、外部サービスへの操作といった高影響アクションを、人間の確認なしに実行してしまわないか。human-in-the-loopの確認自体を回避できないかも対象です。
さらにマルチエージェント環境では、エージェント同士の通信を偽装したり、悪意ある指示をネットワーク内に伝播させたりできないかまでテストします。
ここまで来ると、単なる「LLMの安全性テスト」とはかなり違います。
AIが何を考えるかだけではなく、AIに何をさせられるかを攻撃する。
エージェント型AIのペネトレーションテストです。
最後は、AIが出した結果と、AIを動かすためのリソースです。
代表的なのが、
です。
Improper Output Handlingは、LLMの出力を下流のシステムが安全に処理しなかった場合に起きる問題です。
チェック項目には、XSS、SQL Injection、Command Injection、SSRF、Template Injectionなどが明記されています。
つまり、
LLMが文字列を生成する ↓ アプリがそれを信用する ↓ ブラウザ、SQL、OSコマンド、内部APIなどに渡す ↓ 従来型の脆弱性になる
という流れです。
もうひとつ特徴的なのが Denial of Wallet。
レート制限やクォータ制限がなければ、攻撃者はLLM APIを大量に呼び出し、トークンや推論リソースを消費させられます。
サーバーを停止させる従来型DoSとは違い、クラウドやLLMの利用料金そのものを攻撃するわけです。
高頻度の問い合わせによるモデル抽出も、この項目に含まれています。
Model & Supply Chain Exposureでは、外部からアクセス可能なモデル／推論エンドポイントや認証されていないエンドポイント、さらにテスト時に確認できるAIフレームワーク／プラグイン依存関係の脆弱性などを確認します。
この20項目を眺めていて注目したのは、OWASPのLLM／GenAI向けTop 10の範囲だけにとどまっていないことです。
たとえば、
といった項目です。
これらは、「LLMに危険な回答をさせる」という話よりも、AIエージェントが権限を持って行動することによって生まれる攻撃面に焦点を当てています。
つまり構成そのものが、
「LLMアプリのテスト」
だけでなく、
「AIエージェントのテスト」
まで最初から視野に入れています。
もうひとつ面白い点があります。
一覧を見ると、AI向け20項目にはすべて AI・Web・Mobile の3つのタグが付いています。
Direct Prompt Injectionから、Confused Deputy、Denial of Wallet、Model & Supply Chain Exposureまで同じです。
つまり少なくともチェックの分類上、AIセキュリティはWebやMobileから完全に独立したサイロとして扱われているわけではありません。
新しい「AI Capabilities Only」はAIエージェントとLLM機能に対象を絞るモードですが、そこで扱う脆弱性の「型」までAI固有になるとは限らない。
このタグ構造からも、その境界の曖昧さが見えてきます。
ここが今回、いちばん考えさせられた点です。
「AI機能だけをテストする」と聞くと、プロンプトインジェクションやジェイルブレイクのような、いかにもAIらしい攻撃だけが対象だと思いがちです。
しかし、実際にAI機能を持つアプリケーションをテストすると、こんな指摘が出てきます。
どれも、昔から存在するWebの脆弱性の「型」です。
では、これらは「AIの脆弱性」ではないのでしょうか。
私は、AIの脆弱性だと考えます。
LLMを呼び出すAPIにレートリミットがなければ、攻撃者は無制限にトークンを消費させられる。
従来なら「APIのRate Limit不足」ですが、LLMでは利用料金が直接被害になります。
チャットUIのXSSも同じです。
XSSそのものは古典的なWeb脆弱性ですが、LLMが生成した出力をそのままDOMへ描画する設計によって生まれたのであれば、それはAI機能のアタックサーフェスでもあります。
エラーメッセージやモデル出力から、システムプロンプト、内部構成、資格情報などが漏れる場合も同じです。
つまり、
脆弱性の「型」は古典的でも、AI機能の上に載った瞬間に、それはAIのアタックサーフェスになる。
「AI脆弱性か、そうでないか」の境界には、本質的にグレーゾーンがあります。
そして実は、その答えはAikidoのチェック表そのものにも書いてあります。
AI向け20項目の中には「Improper Output Handling」があり、LLM出力が下流で安全に処理されなかった場合のXSS、SQLi、Command Injection、SSRFなどが明記されています。
さらに「Unbounded Consumption & Denial of Wallet」では、レート／クォータ制限の不足をコスト攻撃やモデル抽出の入口として定義しています。
古典的な脆弱性の「型」がAI文脈で再登場することを、チェック表の設計自体が前提にしているわけです。
だから、AI Capabilities Only のテスト結果に古典的なWeb脆弱性の型が混ざっていても、不思議ではありません。
むしろ、それが実際のAIアプリケーションの攻撃面です。
もうひとつ実務的な観点として、この種のAI機能に対するテストは、EU AI Actを見据えたセキュリティ評価の文脈でも意味を持ちます。
EU AI Actでは、高リスクAIシステムについて、リスク管理に加えてaccuracy、robustness、cybersecurityの確保が求められています。
第三者による脆弱性の悪用への耐性や、AIシステムに固有の攻撃への対策も重要な論点になります。
もちろん、AI Pentestを実施しただけでEU AI Act準拠になるわけではありません。
しかし、
「AIエージェントやLLM機能に対して、どのような攻撃を試したか」
「何が検出されたか」
「どのように修正したか」
を記録できれば、AIシステムに対して技術的なセキュリティ検証を行った記録の一つにはなります。
日本企業でも、EU市場向けにAI機能を提供するのであれば、こうしたテストを開発段階から組み込む意味は大きくなっていきそうです。
AI機能を持つプロダクトをお持ちなら、まずは自分たちのAI機能に、どんな攻撃面があるのかを見積もるところから始めてみるのもよいと思います。
本記事は公開情報およびAikidoの製品画面に基づいています。
Aikido Community Japan
公開日: 2026/9/3
最終更新: 2026/9/3
セキュリティの最新情報をお届けします。