はじめに

服部慎二と申します。MBSDに新卒入社して2年目で、普段はWebアプリケーション脆弱性診断を行っております。

2026/8/1～2026/8/6にかけてアメリカ・ラスベガスで開催された「Black Hat USA 2026」に参加してきました！

業務内でAIを活用する動きが広がる中で、診断業務にAIをどのように取り入れ、どの部分を補助できるのかを考える機会が増えてきました。そうしたAI活用やセキュリティ技術の最新動向に加え、世界中のセキュリティ技術者の考え方や取り組みに直接触れたいという思いから、Black Hatへの参加を希望しました。その思いを会社にも後押しいただき、今回、参加する機会をいただけたことに感謝しています！

4日間のトレーニングを受講したほか、ArsenalやBusiness Hallを回り、最新のセキュリティ技術や製品に触れてきました。Black Hatの概要については他のメンバーにお任せし、本記事では、受講したトレーニングやArsenal・Business Hallなどについて共有いたします。

Trainings

今回受講したのは、Absolute AppSec社が提供する「AI-Enhanced Secure Code Review: Black Hat Edition」という4日間のトレーニングです。

本トレーニングでは、LLMの基礎からAIを活用したセキュアコードレビューまでを、講義とハンズオンを交えながら学びました。AIを単なる解析ツールとして利用するのではなく、従来のセキュアコードレビューの考え方と組み合わせ、より効率的にレビューを行うためのアプローチを学ぶ内容でした。

受講したTraining roomの入口

「AI×セキュリティ」という最近では切り離すことのできないテーマを取り扱った内容となっています。今回は20人程度の比較的コンパクトなクラスだったこともあり、講師との距離も近く、気になったことをその場で確認しやすいトレーニングでした。

スケジュール

トレーニングは以下のスケジュールで進行していきました。

日程	テーマ	概要
Day 1	Building Blocks of LLMs	LLMの基礎、Prompt Engineering、Context、Embeddings、Vector Store、Agentic AIなど
Day 2	Secure Code Review	セキュアコードレビューの方法論、リスク評価、情報収集、認証・認可、入力検証など
Day 3	Secure Code Review（Continued）	出力エンコーディング、暗号、設定など
Day 4	Group Breakout	グループ演習、ハンズオン分析、成果発表など

前半でAI/LLMやセキュアコードレビューについて学び、後半ではそれまでの内容を踏まえた演習へ進む構成です。最終日の4日目には参加者同士でグループを組み、それぞれのアプローチで課題に取り組み、最後に成果発表する流れでした。

Building Blocks of LLMs

1日目は、LLMの基本的な仕組みから、Prompt Engineering、Context、Embeddings、Vector Storeまで、AIをセキュリティ分野で活用するための基礎を扱った内容です。ハンズオンでは、PromptやContextの与え方による出力の違いを確認しながら、AIを用いたコード分析やAgentic AI、生成結果の評価・検証などを行い、求める結果を得るためのAI活用の基礎を学習しました。

本トレーニングを通じて改めて重要性を認識したのが、Contextとトークン消費の関係です。知識としては理解していたものの、トレーニングの中でもContextを増やしすぎることで、かえって期待した結果が得られないケースを実際に確認しています。実際の運用ではトークン消費がそのままコストにもなるため、実践の中で何をAIに渡し、何を渡さないかを具体的に整理しながらAIを活用することが求められます。

これまでは「関連しそうな情報はなるべく多くAIに渡す」という使い方をすることもありましたが、トレーニングを通して、タスクを適切に分割し、それぞれに必要なContextだけを与えることで、不要なトークン消費を抑えつつ、分析対象を明確にして精度の向上につなげる手法について理解を深めることができました。

高性能なモデルを使うことだけではなく、PromptやContext、Toolなどをどのように組み合わせて設計するかが、AIを効果的に活用するうえで重要なポイントになると改めて実感させられる内容でした。

Secure Code Review

2日目から3日目は、まずAIを使う前に、人がSecure Code Reviewをするときにどうコードを見ていくのかを学びました。最初に対象アプリケーションの機能や構成、使われている技術などを確認し、そこからリスクがありそうな箇所を整理して、認証・認可やInjectionなどの観点でコードを見ていきます。

最初から決まったチェックリストを上から順番に確認するのではなく、まずはアプリケーションを理解し、その内容に合わせて確認項目を増やしたり減らしたりしながら進めます。このあたりは、普段行っているブラックボックス診断の進め方ともかなり近い感覚です。

自分が行った検証では、Injectionを中心に、ユーザーから受け取った値がどこから入り、どの処理を通って、最終的にどこで使われるのかをコード上で追っていきました。SQL InjectionやXSSなどについてSourceからSinkまでデータの流れを追い、途中で入力値の検証が行われているか、出力時に適切なエスケープが入っているかなどを確認する内容です。

実際にコードを追ってみると、同じInjectionでもフレームワークによって見方がかなり変わります。例えばXSSでは、テンプレートエンジンが自動的にエスケープする場合でも、特定の記法や設定によって、その処理を無効にする書き方もあります。また、SQL Injectionについても、ORMを使っているから安全というわけではなく、raw SQLを実行する処理など、ORMが持つ安全な仕組みを迂回していないか確認する必要があります。そのため、単純に危険そうな関数を探すだけではなく、対象のフレームワークがどのような安全機能を持ち、それがコード上で適切に使われているかまで理解して確認することが重要です。

もう一つ試したのが、LLMに与えるContextによって分析結果がどのように変わるかという点です。今回はOllamaを利用してローカル環境でGemma 3を動かし、同じコードと質問に対して、セキュアコードレビュー時の判断材料となる情報をContextとして与えた場合と、与えない場合で結果を比較しました。

Contextなしの場合 (一部抜粋)

　

Contextありの場合 (一部抜粋)

　

Contextを与えない場合は、Web3やユーザーのロール管理など、コードの一部から推測した内容を中心に分析されています。一方、Contextを与えた場合は、コードスニペットの処理や入力値の検証など、よりコードに近い部分へ分析の着眼点が変わりました。

ただし、Contextを与えた場合でも、コードから確認できない機能や影響を推測している箇所は残っていました。Contextを追加することで分析の方向性を調整することはできても、それだけで正しい結果になるわけではなく、最終的な確認は人が行う必要があります。

Group Breakout

4日目は、それまでの3日間で学んだ内容を使ったグループ演習です。私たちのグループでは、予約・スケジュール管理を行うOSSを対象に、まず各自でAIを使ったSecure Code Reviewを行いました。AIを使いながらコードやSkills（分析手順や観点をまとめた指示）を作り、それぞれのアプローチで分析を進めた後、見つけた内容や件数、どのような方法で分析したのかを持ち寄って結果を比較します。

面白かったのは、検出した件数にはそれぞれ差があるものの、最終的には同じような脆弱性を検出していたことです。また、比較的多くの脆弱性を検出していたメンバーのコードやSkillsを見てみると、分析する観点ごとに処理を分けたり、Skillsを細かく作り込んだりと、AIに一度にすべてを任せない工夫が見られました。

ちなみに、個人的に一番苦労したのは、やはり英語でのコミュニケーションです。拙い英語と翻訳アプリを使いながら何とか進めましたが、技術的な内容や自分の考えをその場で英語にして伝えるのは想像以上に大変でした。それでも、コードや画面を見せながら話すと思った以上に伝わるもので、言葉の壁はあっても技術者同士で通じ合えることを肌で感じ、グローバルな環境に飛び込む面白さを感じたことも、大きな刺激になりました。

成果発表では、各グループで対象としたOSSが異なることもあり、同じ要件で取り組んでいても、Agentの役割分担やSkills、Toolの作り方など、分析の組み立て方にはかなり違いがありました。SASTを組み込んだり、複数のAgentに役割を持たせたりと、それぞれ工夫しながら実装していました。

中には、同じモデルを使いながら、異なるアーキテクチャやSkills、Contextで複数のアプローチを試し、それぞれの結果をAIで比較・要約しているグループも見られました。発表では、同じモデルを使用していても、アプローチによって共通して検出するものもあれば、結果が大きく異なるものもあることが紹介されており、モデルだけでなく、アーキテクチャやSkills、Contextの違いも分析結果に影響するという点が、個人的に強く印象に残っています。

また、各チームの発表で共通していたのが、AIが出した結果をそのまま採用せず、途中に検証（Validation）を入れていたことです。クロスチェックしたり、実際のコードと照らし合わせたりと方法はそれぞれでしたが、講師の方も、AIによる分析結果の信頼性を高めるためには、人による確認や別の手法とのクロスチェックなど、どこかにValidationのプロセスを設ける必要があると述べられていました。

同じ課題でも実装の仕方やAIの使い方はかなり違っていて、発表の見せ方にも個性があり、他のチームの発表を見るだけでも参考になる部分が多くありました。思わず笑いが起きる場面もあるなど、最後まで和やかな雰囲気の中で、4日間のトレーニングを締めくくりました。

Trainings まとめ

4日間のトレーニングを通して、LLMの基礎からSecure Code Review、そしてそれらを組み合わせた実践演習まで、段階的に経験することができました。特に印象に残ったのは、単に高性能なAIを利用するだけではなく、タスクの分け方やContext、Prompt、Toolをどのように設計するかによって結果が大きく変わるという点です。

初日には、こうしたモデルの周囲にContextやToolなどを組み合わせるハーネスについても議論がありました。一方で、トレーニングでは単純にモデルをラップするだけではなく、複数のAgentや処理を組み合わせて全体を設計するAgentic Orchestration（AIエージェントのオーケストレーション）という考え方が重視されており、AIそのものの性能だけでなく、「どのようにAIを使うか」を考えることの重要性を実感しました。

技術的な知識だけでなく、海外のエンジニアと一緒に学び、議論し、試行錯誤できたことも含めて、非常に濃密な4日間となりました。今回得た知見や経験を、今後のセキュリティ診断やAI活用にもつなげていきたいと思います。

Arsenal・Business Hall

Arsenal

Arsenalでは、研究者や開発者が開発したセキュリティツールについて、実際のデモを交えながら紹介が行われていました。今回、主に以下の2つの内容を見ました。

• ThreatXtension: AI-Powered Browser Extension Security Analysis Framework
• OWASP Faction 2.0

ThreatXtension

ThreatXtensionは、Chrome拡張機能を解析するためのツールです。

特徴的だったのは、Chrome拡張機能のソースコードをそのままLLMにすべて読ませるのではなく、ManifestやJavaScriptに対する静的解析、権限、エントロピー、VirusTotalやChrome Web Store上の情報などを先に集め、その結果をLLMに渡して最終的な分析を行う構成になっていた点です。

例えば、単純にCSSを書き換えるだけの拡張機能なのに、Cookieや閲覧履歴へのアクセス権限を要求している場合、その権限が拡張機能の用途として妥当なのかをLLMに判断させる、といった使い方が紹介されていました。

これはTrainingで扱った内容ともかなり重なります。何でもLLMに渡すのではなく、必要な情報を先に絞り込み、Contextとして渡す情報を整理するという考え方が、実際のツールにも取り入れられていたのが印象的でした。

OWASP Faction 2.0

OWASP Faction 2.0は、脆弱性を自動で見つけるスキャナーというより、診断業務そのものを管理するためのプラットフォームです

診断案件の作成、担当者の割り当て、検出事項の登録、レビュー、レポート作成、修正期限の管理、再診断までを一つの画面で扱えるようになっていました。検出事項についても多数のテンプレートが用意されており、普段使っている説明文や推奨対策を登録して再利用できます。

AIも組み込まれており、再現手順などをもとに、脆弱性の説明文や推奨対策、レポートの概要を生成するデモが行われていました。

AIを「脆弱性を全て見つけるもの」としてではなく、普段の作業の流れを崩さずに効率化のツールとして活用している点が非常に興味深かったです。 専門外の方にも伝わる言葉を選んだり、誰でも再現できる手順を整理したりするのは、私自身も普段からよく悩んでいる部分でした。そうした文章作成でAIに下書きや表現の候補出しを任せられれば、自分は最終的な内容の確認や調整に集中できるため大きなメリットがあります。 いきなり診断全体をAI化するのではなく、まずは時間のかかる作業から段階的にAIを取り入れていくアプローチは、今後の実業務での利用を検討するうえで非常に参考になります。

また、MCP ServerやSkillsを使い、CLIツールで取得した結果をFactionに検出事項として登録するようなデモも行われていました。

今回取り上げた2つのツールでは、LLM単体にすべてを任せる構成ではなく、従来の解析手法や既存のワークフローと組み合わせることが前提になっていたのが印象的でした。

ThreatXtensionでは決定論的な解析結果をLLMに渡し、Factionでは診断者のワークフローを維持したままAIを取り入れています。AIの性能そのものよりも、「どこでAIを使うか」を設計することが実用上は重要であるとArsenalからも感じました。

Business Hall

Business Hallではさまざまな企業を回りましたが、特に以下のブースを中心に訪問して話を伺ってきましたので、いくつか抜粋して紹介します。

• XBOW
• HackerOne
• Horizon3.ai
• Oligo Security
• Pi Security
• Prescient Security
• Snyk
• Semgrep
• PortSwigger
• Trend Micro

4日間のトレーニングを終えた直後だったこともあり、単純に「AIを使っている」という部分よりも、AIに何をさせているのか、どのような情報を与えているのか、検出した結果をどのように検証しているのかという部分に自然と目が行きました。

XBOW

XBOWでは、AIエージェントを使ってWebアプリケーションに対するペネトレーションテストを自動化するサービスを紹介していました。

XBOWは、AIを活用した自律型のオフェンシブセキュリティのプラットフォームを展開している企業です。バグバウンティプログラムにおいて、AIエージェントを用いて自律的に脆弱性を発見した実績を公表したことでも話題になりました。

同社サービスは基本的にはブラックボックスでテストできますが、ソースコードやSAST・DASTの結果、過去のペネトレーションテストのレポートなどを追加情報として与えることもでき、より多くの情報を使ったテストも可能とのことです。

認証情報だけでなく、管理者と一般ユーザーのように権限の異なる複数のアカウントを設定したり、特定のエンドポイントや攻撃手法を指定したりすることもできます。

中でも興味深かったのが、修正後の再診断機能です。

一度見つかった脆弱性について、修正後に同じ通信をそのまま再実行するだけではなく、その脆弱性に特化したエージェントがもう一度テストを行う仕組みになっていました。また、WAFを有効にした状態で、WAFを回避しながら脆弱性を検出できるか確認するといった使い方もできるとのことでした。より広い範囲をもう一度調べたい場合には、ほかの攻撃エージェントも含めて改めてテストを行うこともできます。私たちが再診断を実施する際にも、修正が不十分であったり、別の脆弱性が作り込まれているケースが少なからずあるため、利用者にとって重要な観点であると感じました。

なお、SQL InjectionやIDOR、RCEなど、すでに検証用のエージェントが用意されている脆弱性については、検出後の確認まで自動化されています。一方で、実験的な領域や、まだ検証用エージェントが対応していない問題（網羅性も含む）については、人が確認する場合もあるとのことでした。

Oligo Security

Oligo Securityでは、実行中のアプリケーションを監視し、脆弱性の優先順位付けや攻撃の検知を行う仕組みについて紹介されていました。

特徴的なのは、ソースコードを直接参照するのではなく、OS上で動作するセンサーから、実際にどのライブラリや関数が動いているのかを確認している点です。

例えば、アプリケーションに脆弱性を持つライブラリが含まれていたとしても、そのライブラリや問題のある処理が実際には使われていない場合があります。Oligo Securityでは、単に「脆弱なライブラリが存在する」という情報だけではなく、実際にそのライブラリや関数が動いているかまで確認することで、対応すべき脆弱性を絞り込めるという説明でした。

また、脆弱性の管理だけではなく、実行中のコードの振る舞いを監視することで、攻撃の検出にも利用できます。

デモでは、本来はデータを解析するためのPythonライブラリが通常とは異なる処理を実行しようとした際に、関数の呼び出し履歴などを確認し、異常な動作として検出する例が紹介されていました。

このツールでもAIは利用されていますが、検出の中心をAIだけに頼っているわけではありません。

特定の関数がOS上で本来行うべきではない処理など、あらかじめ判断できるものについては決められたルールで検出し、その上にAIや異常検知の仕組みを組み合わせています。

今回はAIを前面に出した製品が多い中、実行中のライブラリや関数を観測するなどリアルタイム性が求められる領域では、確実に判断できる部分を従来の方法で検出するという手法の重要性は変わらないことを改めて認識しました。

Snyk

Snykでは、開発段階で利用しているOSSパッケージを調べ、既知の脆弱性の検出や修正を支援する仕組みについて紹介されていました。

今回紹介されていたのは、SCA（Software Composition Analysis）のデモです。GitHubやGitLabなどのリポジトリを接続し、プロジェクト内の依存関係を定義するファイルなどから利用しているOSSパッケージを解析します。脆弱性が見つかった場合は、既知のCVEや危険度、修正方法などを確認することができます。

担当者からも、実行中のアプリケーションを監視したり、ペネトレーションテストを行ったりするものではなく、開発段階で利用するセキュリティツールという説明があり、シフトレフトの施策の一つとして活用されるものとなります。

私が普段行っているブラックボックス診断では、実際に動いているアプリケーションに対して外部から脆弱性を探すため、さまざまな環境の診断対象サイトに対して比較的柔軟に対応が可能というメリットがあります。一方、Snykのようなツールは開発環境上に組み込む必要はあるものの、外部からは判断しづらいシステム内部で利用しているOSSパッケージに問題がないかまで確認できるというメリットがあります。それぞれのメリットやセキュリティ要件なども踏まえながら適切なセキュリティ施策の設計が重要であると強く感じました。

Trend Micro

もう一つ印象的だったのが、AIをセキュリティ業務に活用する製品だけでなく、AIそのものを守るための製品も増えていたことです。

Trend Microのブースでは、ChatGPT、Claude、Geminiなどへ送信する入力内容を監視し、機密情報の送信や危険な指示を検知・制御する仕組みのデモが行われていました。

さらに、自社で開発したAIアプリケーションに対してPrompt Injectionなどを試し、本番公開前に攻撃者の視点から安全性を確認する機能も紹介されていました。

デモでは、銀行を想定したAIチャットボットに対して、本来は許可されていない送金処理を実行させようとする例が使われており、テスト後には、成功した攻撃の種類や実際のやり取りまで確認できるようになっていました。

弊社でもAIレッドチーミングとして、対象システムに応じたシナリオベースで検証するサービスを提供しており、「AIを導入したシステムをどのように守るか」という観点でお客様からの引き合いも増えてきている状況です。私もAIを使ったシステムを構築する中で、AIの問題解決力や柔軟性に高い可能性を感じる一方で、脆弱性診断員としては攻撃経路を注意深く検討して対策を講じる必要性を要所要所で強く感じています。

Business Hall内に設けられた交流スペース

さいごに

Black Hatのトレーニングは2日間でもハードだと聞いていました。今回は4日間のコースだったので、正直かなり大変でしたが、その分、得られたものも多くありました。

特に、AIを活用するうえでは、単純に高性能なモデルを使うだけではなく、タスクの分け方やContextの与え方、既存のツールとの組み合わせ、そして出力結果をどのように検証するかが重要だという点は、今回のTrainingを通して強く印象に残りました。

また、Business HallやArsenalでは、Trainingで扱った考え方が実際の製品やツールにも取り入れられている場面を見ることができました。AIにすべてを任せるのではなく、従来の解析手法と組み合わせたり、検証用のエージェントを用意したりと、各社それぞれの方法でAIを活用していたのも興味深かったです。まだ社会人経験が浅く、どうしても技術寄りの視点になってしまうことが多いのですが、その技術がビジネス上の課題にどのように活用されているのかを体感できたことは非常に有意義であり、社会人として技術だけでなくその先にあるビジネスまで意識するきっかけになりました。

英語での講義やグループワークにはかなり苦戦しましたが、翻訳ツールや周りの参加者にも助けられ、最終日まで何とかやり切ることができました。参加前は4日間のTrainingを無事に終えられるか不安もありましたが、実際に飛び込んでみると、思っていた以上に何とかなることを経験できたことは、これからの自分にとって大きな糧になると感じています。

また、入社2年目の若手という立場で、海外のエンジニアと一緒にSecure Code ReviewやAIの活用方法について考え、議論し、実際に手を動かせたことは、とても貴重な経験でした。 技術的な知識だけでなく、自分とは異なる考え方やアプローチに触れられたことも含め、思い切って参加してみて良かったと思います。