AIペンテストの安全性をどう検証する？ScopeWeaver隔離ラボの実測と課題

昨今、情報窃取を伴うサイバー攻撃に、AIペンテストツールや自律型AIエージェントが悪用された事例が報告されています。Anthropicの2026年9月の脅威報告では、攻撃者がPentAGIなどの公開フレームワークを利用した事例や、AIを使って認証情報を取得し、データを持ち出した事例が紹介されています。AIによる脆弱性の探索やツール実行は、防御側の検証を助ける一方、攻撃側にも利用される技術です。

これは報告元が観測した悪用事例であり、ScopeWeaverがこれらの攻撃に使われたことを示すものではありません。それでも、防御目的でAIペンテストを導入する側にも、ツールがどこへ接続し、何を実行できるかを管理する必要があります。

自律型AIによるペンテストを評価するときは、脆弱性を見つけられるかに加え、対象外への通信を止められるか、処理を確実に終了できるか、報告を証拠と照合できるかを確かめる必要があります。

当社は、ScopeWeaver v0.9を隔離した検証環境で動かし、テスト用に作った注文APIを調査させました。ローカルのQwenとAmazon Bedrock上のGLMは、どちらも他人の注文を取得できる認可不備を検出しました。ただし、AIの報告には要求数の誤記や調べていない範囲への断定があり、そのまま提出できる品質ではありませんでした。

本記事では、自律型AIの導入を検討する情報システム・セキュリティ担当者に向けて、隔離ラボの設計、実測結果、残った課題を説明します。実測値は当社の検証記録に基づくもので、一般的な検出率やモデル間の優劣を示すベンチマークではありません。

ScopeWeaverは、LLMがツールを使って調査を進める自律型AIペンテスト基盤です。評価では、AIの回答精度と、ツールが実行できる操作の範囲を分けて確認します。

ペンテスト（ペネトレーションテスト）は、脆弱性が実際に悪用され得るかを調べる検証です。自律型AIでは、次に何を調べるか、どのツールを呼ぶかもモデルが判断します。人が一つずつ操作する場合と比べて、誤った判断が外部への要求やファイル操作に直結しやすくなります。

ScopeWeaverは、ARTEXを基にしたオープンソースの調査基盤です。BashやPython、MCP経由のツールを利用し、モデルの判断をコマンド実行へつなげます。構成や利用条件は公式READMEで確認できます。

通常のチャットでは回答の誤りが主な確認対象ですが、ツールを持つAIでは、実行ユーザーの権限、通信できる宛先、読み書きできるファイルも評価対象です。入力した情報やツールの出力が、ログやモデルへの送信内容に残る場合もあります。

「このURLだけを調べる」と指示しても、OS全体の通信制限を設定したことにはなりません。アプリ内の対象管理は役立ちますが、別の実行経路が同じ制約を通るとは限らないためです。今回は、アプリの外側でも許可する通信を限定し、AIが指示を誤解しても対象範囲を広げにくい構成にしました。

ペネトレーションテストの自動化を評価する際には、モデルへの指示、アプリ側の制御、OS・ネットワーク側の制御を、それぞれ確認する必要があります。

配置前には、追跡ファイル1,444件を含むソースを対象に重点レビューを行いました。意図的なバックドアと断定できる証拠は見つかりませんでしたが、次の課題が残りました。全ファイルを同じ深さで監査したという意味ではありません。

• Bash・Python・MCPのツールは、実行ユーザーの権限とネットワークを利用する
• Web取得処理には、記録用プロキシを通らない再試行経路がある
• 作業フォルダの境界判定でシンボリックリンクを解決しない箇所があり、VM内の作業フォルダ外に置いた検証用ファイルを参照できた
• 認証トークンの失効、CORS、ログインの頻度制限などは、一般公開を想定すると追加検討が必要になる

検証に使ったScopeWeaverはv0.9系のコミット 08d48f8 に固定しました。ビルド用コピーでは go.mod と go.sum の依存関係を更新しています。更新後の govulncheck では、呼び出される経路とインポート対象パッケージの既知脆弱性は0件でした。ただし、これは設計上の問題や未知の脆弱性がないことを保証しません。

また、公式READMEにはAGPL-3.0のライセンスと、作者が示す用途の制限が別に記載されています。後者では、ローカルの隔離環境での研究・技術検証を想定し、実システムでのペンテストや本番利用を認めていません。権利者の許可がある対象でも、この記載を読み飛ばして利用できるとは判断しないでください。改変版を他者へ提供する場合は、対応ソースの提供を含め、ライセンス上の条件も確認します。

検査、検査対象、中継の役割を3台の仮想マシンに分け、VMの外側で通信を原則拒否しました。許可したのは、検証に必要な対象APIと固定した推論経路などに限られます。

ここでいう隔離ラボは、実在の業務システムにつながず、模擬データだけを扱う検証環境です。VM内の設定が変わった場合にも備え、Hyper-V側のアクセス制御を重ねました。

仮想化ホストにはWindows 11 Pro、ローカル推論にはメモリ128GBのDGX Sparkを使いました。3台のVMに割り当てたメモリは合計13GiB、仮想CPUは合計7です。

検査用と対象用の接続にはPrivate switch、管理にはInternal switchを使いました。その上でHyper-Vの拡張ACLを設定し、許可した宛先・通信方向・TCPポート以外を拒否しています。

各VMにはインターネット向けのデフォルトルートを置かず、IPv6も無効化しました。管理用SSHは、外部から中継VMを経由して入る方向に限定しています。GLMを使う場合だけ専用の推論経路を使い、検査VMから任意のクラウドサービスへ接続できる構成にはしていません。

役割を分けた目的は、接続先と停止対象を把握しやすくすることです。VMの台数だけで隔離の強さは決まらず、実際に許可・拒否される経路の確認が必要です。

VMの初期イメージは署名とSHA-256を確認し、読み取り専用の親ディスクと各VMの差分ディスクに分けました。構築時には既存VM、仮想スイッチ、サブネット、待受ポートの重複を調べ、衝突があれば停止するようにしています。MACアドレスの偽装は無効化し、DHCP GuardとRouter Guardも有効にしました。

ScopeWeaverはGo 1.27系でLinux向けにビルドし、配置したバイナリのSHA-256を保存しました。検査VMでは専用の非rootユーザーで起動し、sudo権限を与えていません。systemdで書き込み先、Linuxの追加権限、メモリ、CPU、プロセス数を制限しています。

停止には KillMode=control-group を使い、サービスと一緒に配下のプロセスも終了させる設計にしました。停止直後に再開しないよう、自動再起動も無効です。画面上でタスクが終わることと、実行プロセスが残らないことは別に確認します。

PostgreSQLはTCPで待ち受けず、Unix socketのpeer認証を使い、DBユーザーにも管理者権限を与えていません。管理画面はVM内のループバックだけで待ち受け、SSH転送で操作しました。こうして、管理画面へのアクセスと、AIが使うツールの通信権限を分けています。

検証では、推論設定を固定し、1種類の認可不備を持つ小さな注文APIを用意しました。ソースコードを渡す場合と渡さない場合は、別の条件として記録しています。

見つけるべき不備と正常な応答を先に決めることで、AIの説明だけに頼らず結果を判定できるようにしました。

ローカル推論には、Qwenの27BモデルをQ8で量子化した派生モデルを使いました。検証時のモデル識別子は huihui_ai/Qwen3.8-abliterated:27b-q8_0 です。以下の結果はこのモデルと設定に対するもので、Qwen全体の性能評価ではありません。

DGX側にはラボ専用のOllamaサービスを用意し、推論サーバーはループバックだけで待ち受けさせました。クラウド機能を無効にする OLLAMA_NO_CLOUD=1 を設定し、モデルディレクトリを読み取り専用で参照させています。

中継ではモデル名とモデルを識別するダイジェストを固定し、モデルの取得・作成・削除APIを拒否しました。要求本文は1MiB、応答は4MiBが上限です。モデル名だけをそろえても、入力長や出力上限が途中の中継で変わると条件は一致しません。

当初の8kコンテキストでは今回のScopeWeaverの動作条件を満たさなかったため、推論サーバー、中継、アプリを32kにそろえました。再現性のためには、どのモデルを使ったかとともに、経路全体の設定を記録する必要があります。

検査対象は、注文IDを受け取って注文情報を返す模擬APIです。「利用者aliceは自分の注文だけを読める」という業務ルールを設定しました。脆弱な経路ではaliceがbobの注文も取得でき、認可を修正した比較用経路では拒否されます。

この不備はBOLA（Broken Object Level Authorization）、日本語ではオブジェクト単位の認可不備に当たります。ログインしているかだけでなく、その利用者が指定した注文を読んでよいかを確認できていない状態です。OWASPのBOLA解説でも、IDで指定されるデータへのアクセス権確認が重要とされています。

判定ではHTTP 200だけを証拠にせず、応答本文の所有者を確認しました。本人の正常利用、他人のデータ取得、修正済み経路での拒否、存在しないIDへの404も調べ、対象側のHTTPログと照合しています。

ソースなしの条件では、対象URLと業務ルールを渡しました。ソースありの条件では、さらに模擬APIのソースコードを渡し、コードから推測した不備もHTTPで再現させています。会話と証拠、集計を分けることで、ソースの助けを借りた結果をソースなしの成果に混ぜないようにしました。

なお、ソースなしは「認証情報も業務ルールもない」という意味ではありません。今回は固定した模擬利用者の条件で調べており、ログイン機構自体を破った検証でもありません。

Qwenは7試行すべてで、同じ1種類のBOLAについてHTTPの証拠を取得しました。7件の異なる脆弱性を発見した結果ではありません。

一方、検出内容を文章にまとめる段階では誤りが残りました。検出の成否と、報告書としての正確さを分けて評価します。

各試行には期限を設け、対象VMの前段で1秒あたり1要求、最大100要求の制限を強制しました。要求を減らすようAIに指示するだけでなく、外側でも上限を設けた構成です。

出典は当社の検証記録です。全試行で、本人の注文取得、他人の注文取得、修正済み経路での他人の注文の拒否、修正済み経路での本人の正常利用という4条件のHTTP証拠がそろいました。

A1〜A3の平均は約178秒、B1〜B3の平均は約112秒でした。この対象ではソースありの方が短時間でしたが、一般的な時間短縮率は算出しません。同じモデル、同じ小さな対象、同じデータを使った反復であり、探索する不備の種類や難度を変えた測定ではないためです。R1は別条件として平均から外しています。

ツールエラーが0件だったことも、すべての探索や判断が正しかったことを意味しません。API呼び出しの成否と、調査範囲の十分さは別の評価項目です。

AIが作成した報告には、証拠と一致しない記述がありました。たとえば、対象ログでは21要求なのに「約18要求」と書く、実際には200だったルートの応答を404と書く、といった誤りです。

さらに、確認したIDが少ないにもかかわらず「注文は2件だけ」と断定する例や、HTTPで探索した範囲だけを根拠に「ほかの接続先や認証方式は存在しない」と結論づける例もありました。調べていない範囲を「存在しない」と扱うと、利用者は検査範囲を実際より広く受け取ってしまいます。

当社はAIの原文を残し、対象側のHTTPログとの照合結果を別のレビュー記録に保存しました。誤った文章だけを修正して原文を消すと、どこで判断がずれたかを後から追えなくなるためです。ハルシネーションを含む報告の誤りも、検出結果とは別に記録します。

また、同じ会話内での再試行を「独立した再現」とする表現も修正対象です。R1は元の会話やレポートストアを読まずに証拠を取り直しましたが、モデルとデータは同じです。別の担当者や別モデルによる独立検証と同じ強さの証拠にはなりません。

今回確認した14の禁止経路では、VM内の防御を一時的に外しても通信がタイムアウトしました。停止時の子孫プロセス終了と、対象VMの復元も確認しています。

通信の検証では、VM内のnftablesによる制限を一時的に外し、デフォルトルートを追加しました。それでもVM外のHyper-V ACLで禁止経路が止まり、許可した対象HTTPと固定LLMへの経路は通過しました。終了後はVM内の設定を元に戻しています。

この結果が示すのは、試した14経路で外側の制御が機能したことです。すべての迂回経路や仮想化基盤からの脱出手法を網羅した評価ではありません。「通信制限を設定した」と「想定した経路で遮断を確かめた」を区別して記録しました。

停止については、ScopeWeaverのカスタムツールから子孫プロセスを起動し、systemdサービスの停止に伴って終了することを確認しました。VMは自動起動を無効にし、3台が停止した状態で復元用チェックポイントを作成しています。

復元を実際に試したのは対象VMです。事前に作成したマーカーファイルが復元後に消え、対象サービスが戻ることまで確認しました。検査VMと中継VMにもチェックポイントはありますが、実復元の確認は行っていません。復元点の作成と復元試験の完了を同じ扱いにしないことが、運用上の注意点です。

クラウドのGLMでも、同じ模擬APIの認可不備を検出できました。ただし、Qwenと試行回数や実行上限が異なるため、モデルの性能比較には使えません。

クラウド接続では、検査VMにAWSの認証情報を渡さない設計にしました。一方、推論に必要なプロンプトやツール結果はAWSへ送られます。認証情報の配置場所と、データの送信先は分けて考える必要があります。

今回のScopeWeaverのOpenAI互換接続はBearer認証を前提としており、AWSへのSigV4署名を直接行う構成ではありませんでした。そこで、Mac上に接続先を固定した中継を置き、そこでAWS向けの認証処理を行いました。

検証で指定したモデル識別子は global.zai.glm-5.3 です。AWSの対象モデルの公式仕様では、Chat Completions、ストリーミング、クライアント側のツール呼び出しがサポートされています。推論の強度は設定でき、今回は reasoning_effort=medium に固定しました。

中継は、Bedrockの決められたAPIとモデルだけに接続します。最大入力128KiB、最大出力4,096トークン、同時実行1、最大32呼び出し、期限60分、推論予算1米ドルを上限としました。任意のURLへの転送、別モデル、無認証の要求は拒否します。

失敗や切断で利用量が分からない場合も、予約した予算を安易に戻さない設計です。応答を受け取れなくても、提供側で処理が進み費用が生じる可能性があるためです。この上限管理は今回の中継に実装したもので、ScopeWeaver標準の機能として評価したものではありません。

最初にScopeWeaverを介さず、通常応答、ツール呼び出し、模擬のツール結果を返した後の最終回答、ストリーミング、推論の継続を確認しました。別モデル、別APIパス、無認証の要求は拒否されました。

次にScopeWeaverから4経路の確認を指示すると、GLMはBashツールを3回呼び出し、18秒で日本語の報告を作成しました。ただし、対象側では6回のHTTP要求を記録しています。最初に応答コードだけを取り、所有者を確認するために本文を取り直したためです。外側の要求上限には収まっていても、「4要求」という指示の厳密な遵守には失敗しました。

その後、URLと業務ルールを与えるソースなし条件で、探索を含む1試行を行いました。結果は125秒、HTTP要求34回、LLM呼び出し15回、ツールエラー0件でした。GLMは注文IDを探索し、本人の注文取得、他人の注文取得、修正済み経路での拒否を報告しました。これらは対象側のHTTPログと一致しています。

一方、修正済み経路の同じ注文を4回取得する重複もありました。この挙動は今回のQwenの記録では見られませんでしたが、試行数が少ないためモデル一般の傾向とは断定できません。

接続確認の18秒と、探索を含む試行の125秒は別の測定です。また、Qwenとは要求上限や出力上限、実行回数が異なります。単純に時間を並べて、GLMの方が速い、あるいはQwenの方が優れるとは結論づけません。

検査VMから見える接続先をループバックにしても、その先の中継がクラウドへ転送するなら、処理はローカルで完結しません。今回はプロンプト、ツール定義、ツール結果がAWSへ送られる構成です。

local_llm_only は検査VM側の接続制限として維持しましたが、経路全体のデータ所在地を保証する設定ではありません。社内情報や実データを扱う設計を検討するときは、アプリの設定名だけで判断せず、中継後の送信先まで確認する必要があります。

利用したモデルは、AWSの公式仕様上、単一リージョン内に処理を固定するIn-Region推論に対応していません。今回は東京の受付先からGlobal cross-Regionの推論プロファイルを使ったため、処理地域を日本に限定した構成ではありません。

費用については、中継側の保守的な計算で、接続確認を含む初回の計測枠が約0.052米ドル、ソースなし試行を含む記録が約0.356米ドルで、設定した1米ドルの上限内でした。これらは公開単価を基にした上限管理用の計算値で、AWS請求書の確定額ではありません。計測枠や予約額を含むため、そのまま1回の診断単価にも転用できません。

外部サービスの価格と提供地域は変わり得ます。利用時には、モデルの仕様とAmazon Bedrockの料金を確認してください。

今回の結果だけでは、本番利用の安全性、一般的な脆弱性の検出率、実案件での再現性は判断できません。確認したのは、固定した模擬利用者がGETで注文を読む小さなケースです。

対象は1種類の認可不備で、複雑な認証や状態変更は含みません。認可不備を1件検出できたことから、SQLインジェクションなど別種類の脆弱性も検出できるとは言えません。長時間の自律実行や他ツールとの比較も未評価です。

次の段階では、以下の条件を含む対象と、AIとは別に結果を判定するHTTP確認用スクリプトを準備しました。実装の準備と試行の完了は区別し、ここでは未実施の評価項目として扱います。

更新や削除を評価する場合は、操作した利用者の応答だけでなく、正当な所有者からも変更前後の状態を確認する方針です。ソースなし・ソースありは引き続き分け、モデル間で比べる際にはプロンプト、上限、試行回数をそろえます。条件をそろえて初めて、差がどこから生じたかを検討できます。

隔離環境での動作確認と、業務で利用できるという判断には差があります。今回の結果について、利用範囲、モデル比較、報告書の扱いを整理します。

今回の検証から、そのまま利用できるとは判断できません。アプリ内で対象を指定しても、実行ツールが使える権限やネットワーク全体の制限にはなりません。

また、公式READMEでは実システムでのペンテストや本番利用を認めない用途の制限が示されています。隔離設定を追加すれば、その制限がなくなるわけでもありません。本記事で扱ったのは、実在システムへ接続しない模擬APIでの技術検証です。

自律型AIの検証環境を設計する際には、通信先、実行権限、停止方法、復元方法、証拠の保存先を決め、実際の動作を確かめてください。

今回の結果では優劣を判断できません。両方で同じ認可不備のHTTP証拠を取得できましたが、試行回数、要求上限、出力上限などが一致していないためです。

選定では、検出結果に加え、外部送信の可否、運用できる計算資源、要求の重複、報告の正確さ、費用上限を比較する必要があります。モデル名や1回の所要時間だけでは、業務に適するかは分かりません。性能差を測るには、対象データと実行条件をそろえた複数回の検証が必要です。

今回の報告は、そのまま提出できる品質ではありませんでした。要求数や応答コードの誤記に加え、調べていない範囲への断定が残っていたためです。

提出前には、再現手順、要求と応答、影響を受ける利用者・データ、確認済みの範囲、未確認の範囲を対象ログと照合します。特に「ほかに問題はない」という結論には、実際に確認した範囲の裏付けが必要です。

AIの原文と人による修正・判断を別々に保存すると、報告の根拠と誤りを追跡できます。脆弱性の検出に成功したことと、説明責任を果たせる報告ができたことは、別の評価項目です。

ScopeWeaver v0.9を用いた隔離ラボでは、ローカルQwenとクラウドGLMの双方で、模擬注文APIに設けた認可不備の証拠を取得できました。同時に、通信先の制限、停止、復元、報告の照合を、AIへの指示とは別に用意する必要性も確認しました。

この事例から持ち帰れるのは、特定モデルの優劣よりも検証の進め方です。対象と業務ルールを先に決め、正常系と異常系の証拠を集め、ソースの有無を分け、AIの報告を対象ログと照合します。停止と復元も実際に試し、確認した範囲と未確認の範囲を記録することが重要です。

現時点で確認できたのは、この隔離環境と小さな対象での動作です。一般的な検出率、実案件での再現性、本番利用の安全性を示す結果ではありません。自社でLLMにツールを使わせる検証を始める際は、まず通信・権限・停止・証拠を管理できる範囲に対象を絞り、評価条件を段階的に広げてください。