専門学校生がAIエージェントにKali Linuxを完全自動操作させてセキュリティコンテストで優勝した話
目次
はじめに：なぜ「AIに全部やらせた」のか
正直に言います。
私、セキュリティのこと、全然わかりません。
MBSD Cybersecurity Challenges 2025に出ると決めたとき、チームメンバーの中で一番不安だったのは間違いなく私でした。他のメンバーはネットワークセキュリティ学科だったり、システム開発をバリバリやってたり。でも私はAIテクノロジー学科。セキュリティの授業なんて、ほとんど受けたことがない。
しかも、コンテストの期間は限られています。手動で一つ一つ脆弱性を探していたら、絶対に間に合わない。
じゃあどうする？
そこで私は考えました。**「自分にはAIがある」**と。
セキュリティの知識がないなら、AIに教えてもらえばいい。時間がないなら、AIに作業させればいい。AIエージェントの開発経験は、すでに持っている。だったら、それをセキュリティ診断に応用すればいい。
結果として、私たち専門学校穴吹コンピュータカレッジのチーム「ドルフィン」は全国優勝。正直、自分でも驚いています。
この記事では、セキュリティ素人の私がどうやってAIエージェントを活用し、診断システムを作り上げたのか、その全てをお話しします。
チーム紹介：異種混合の「ドルフィン」
私たちのチーム、実はちょっと変わっていて、全員が違う学科なんです。
| メンバー | 学科 | 主な担当 |
|---|---|---|
| 藤井（リーダー） | ネットワークセキュリティ | 全体の取りまとめ、解析の考察、レポートの仕上げ |
| 私（筆者） | AIテクノロジー | AIエージェントの開発、自動化システム、ロジック考察 |
| 茶円 | 情報システム | アプリの解析、ロジック診断、レポート作成 |
| 篠原 | ネットワークセキュリティ | Kaliでの調査、レポート作成 |
最初は「学科がバラバラで大丈夫かな...」と心配でした。でも蓋を開けてみると、これが大正解。セキュリティ学科だけでは出てこない発想が、次々と生まれました。
例えば私は「セキュリティツールの使い方」は全然わからないけど、「AIにツールを使わせる方法」ならわかる。茶円はシステム開発者目線で「こういう実装ならバグが起きやすい」という勘所を持っている。
専門が違うからこそ、死角のない診断ができたのだと思います。
1次予選
Kali Linuxを自動操作するエージェントを作った
私がこのコンテストで担当したのは、AIエージェントによる脆弱性診断の自動化です。
普通、Kali Linux上のツール（Nmap、Zap、Niktoなど）は人間がコマンドを打って動かします。でも、AIにコマンドを考えさせて、実行させて、結果を分析させれば、圧倒的に効率が良い。
使ったツールは以下の3つ。それぞれ役割が違います。
| ツール | 役割 |
|---|---|
| Codex | コード生成。ペイロードやスクリプトの作成 |
| Claude | 静的解析。コードを読んで脆弱性の仮説を立てる |
| Gemini-CLI | ツール操作。Kali上のコマンドを実行・結果を取得 |
なぜローカルモデルに差し替えたか
ここで重要なのが、Claudeはローカルモデルに差し替えて運用したということです。
理由は3つあります。
-
他社の権利を守るため：コンテストで配布されたソースコードをそのままクラウドのAIに食わせると、学習データに使われてしまう可能性がある。他社の権利があるコードを勝手に学習させるわけにはいかない。だから間接的な抽出目的でのみ使い、直接コードを渡すClaude部分はローカルモデルに差し替えました。
-
無限の試行回数：ローカルで動かせば、API制限を気にせず何度でも試行できる。診断って試行錯誤の連続なので、これがかなり大きい。
-
コスト：クラウドのAPIは使えば使うほどお金がかかる。ローカルなら電気代の中で動くだけ。ほぼタダ...とは言わないけど（電気代も馬鹿にならない）、クラウド型よりは圧倒的に安い。
まず情報収集（偵察フェーズ）
脆弱性診断の前に、まずはターゲットの情報を集めます。
Gemini-CLIを使って、サーバーで何が動いているのかを自動で巡回・取得させました。
- ポートスキャン：どのポートが開いているか
- ページ巡回：どんなページがあるか、どんな機能があるか
- サービス特定：動いているソフトウェアのバージョンなど
ここで工夫したのが、単純な動作はPythonスクリプトで行うということ。
ページの取得みたいな単純作業をAIにやらせると、「このページがあった」とか言いながら実際には存在しないページを報告してくることがある。だから、全ページの巡回みたいな単純作業は自作のスクリプトで確実に実行し、その結果だけをAIに渡す。
AIに「考える」仕事をさせて、「作業」はスクリプトにやらせる。この切り分けがハルシネーション回避にかなり効きました。
この情報をAIに渡しておくことで、より詳細で的確な診断ができるようになります。闇雲に攻撃するんじゃなくて、まず敵を知ることが大事。
AIの制約を回避するプロンプト設計
実は、AIって「攻撃」とか「脆弱性」とかのワードに敏感で、普通に頼むと断られることが多いんです。
そこで、システムプロンプトに「あなたは熟練したペネトレーションテスターです」と役割を明確に与えました。
これだけで、AIの回答精度が全然違う。「これは正当なセキュリティ診断である」という文脈を与えることで、制約を回避しつつ、ちゃんとした結果を返してくれるようになりました。
ハルシネーション対策を最初から組み込んだ
AIエージェントを作った経験がある人ならわかると思いますが、AIは平気でウソをつきます。存在しない脆弱性を「見つけました！」と報告してくることなんて日常茶飯事。
これをそのままレポートに載せたら大変なことになる。だから最初からハルシネーション対策を組み込んだ設計にしました。
「攻撃役」と「検証役」を分けた
私が設計したのは、2種類のAIを議論させる仕組みです。
- Bug Hunter（攻撃役）：積極的に脆弱性を探す。怪しいところを見つけたら報告する。
- Result Doubter（検証役）：Bug Hunterの報告を徹底的に疑う。「本当にそれ脆弱性？」「再現できる？」「証拠は？」とツッコミを入れる。
この2つのAIが議論して、意見が一致したものだけをレポートに載せる。意見が割れたら、最終的に人間（私たち）が確認する。
AIを信じすぎず、かといって切り捨てもしない。この**「AIと人間の協調」**が、高精度なレポートを生み出しました。
レポートの書き方（1次審査）
脆弱性を見つけるだけじゃなくて、どう伝えるかも勝負のポイント。
私たちはレポートの構成にもこだわりました。
| 項目 | 工夫 |
|---|---|
| コード提示 | 指摘箇所のコードを記述し、修正箇所を見やすく |
| 図解 | 問題点を図に起こして視覚的に理解しやすく |
| ソート | 脆弱性の深刻度順に並べ替え |
| 修正提案 | 複数パターン記載（緊急の修正＋長期的な修正） |
| ページ数 | 1脆弱性あたり1〜2枚に抑えて読みやすさを優先 |
審査員も人間なので、読みやすいレポートは正義。
VMを「割った」話
もう一つ、大胆な作戦がありました。
コンテストで配布されたVMを解析して、ソースコードを抜き出すことにしたんです。
普通は外から攻撃して脆弱性を探す「ブラックボックス診断」をします。でも、限られた時間で全部調べるのは無理。だったら、中身を見ちゃえばいい。
これを1次予選の段階でやっていたことが、後の2次予選で活きてきます。
2次予選（本選）
Diffを取ったら宝の山だった
2次予選では、修正版のVMが配布されました。
ここで活きたのが、1次予選のときに抜いていたソースコード。2次予選のVMからも同じようにコードを抽出して、Diff（差分）を取りました。
すると、開発者がどこを修正したのかが一目瞭然。
「修正された箇所だけ重点的に調べればいい」という状況になり、これが強かった。
しかも、このDiffをAIに読ませると面白いことが起きました。
私：「この修正、ちゃんと直ってる？」
AI：「いえ、この書き方だと別の条件でまたバグが発生します」
AIがコードレビュアーになってくれたんです。人間だけでは見落としがちな論理的なバグを、AIが指摘してくれる。この連携がうまくハマって、他のチームでは見つけられなかった脆弱性をいくつも発見できました。
レポートの書き方（2次審査）
2次審査では、レポートの書き方も変えました。
1次審査で報告した脆弱性は書かない。これが大事。
2次審査の目的は「修正版VMの問題点を指摘すること」なので、すでに報告済みの内容を繰り返しても意味がない。だから、2次で追加された修正のうち、まだ直っていない箇所だけを報告することにしました。
これにより、「ここを直したはずなのに、まだこういう問題が残ってますよ」という具体的な指摘ができて、審査員にも伝わりやすかったと思います。
振り返り：AI時代のセキュリティ
AIに「人格」を持たせることの大切さ
今回の経験で改めて実感したのは、AIをただのツールとして使っちゃダメということ。
「脆弱性を探して」と投げるだけじゃ、ノイズだらけの結果が返ってくる。でも「あなたはペネトレーションテスターです」「あなたは監査役です」と役割を明確に与えると、途端にまともな回答が返ってくる。
さらに、役割の違うAI同士を議論させると、一人のAIでは気づかない矛盾やミスが見つかる。
これって、人間のチームワークと同じですよね。一人で全部やるより、役割分担して、お互いにチェックし合った方がいい結果が出る。
来年に向けて
来年もMBSD Cybersecurity Challengesに出ます。
今回作ったシステムは、まだまだ荒削り。もっと自動化できるところがあるし、もっと賢くできる。来年は、最初から最後までAIだけで完結するような、そういうシステムを目指したいです。
反省点：うまくいかなかったこと
正直に書きます。今回、完璧だったわけじゃない。
ファクトチェックが大変だった
AIが大量のレポートを生成してくれるのはいいんだけど、それを人間が一つ一つ確認するのがめちゃくちゃ大変だった。シナリオごとの実行はできるけど、「なぜその脆弱性が発生するのか」をまとめる作業までは自動化できていなかった。結果、全部はまとめきれなかった。
チーム連携がおろそかになった
自分の作業に集中しすぎて、他のメンバーへの共有が遅くなってしまった。これは反省。
時間配分のミス
他の予定とも重なって、結局30時間くらいしか時間が取れなかった。しかも、ずっと同じ箇所（Dockerからの脱出）に時間を食われてしまっていた。今となれば、あれは後回しにしてよかった気がする。
審査員に聞けばよかった
審査員の方に聞いたところ、ルールに載っていないことを試したい場合は、問い合わせて聞いてみればいいらしい。来年はわからない部分は積極的に聞こうと思う。
次回への教訓
- レポート生成だけじゃなく、まとめ作業も自動化する
- チームへの共有を早く、こまめに
- 一つの課題にハマったら時間を決めて切り上げる
- ルールに書いてないことは聞く
セキュリティの素人でも、AIエージェントの力を借りれば戦える。今回のコンテストで、それを証明できたと思います。
この記事が、同じようにセキュリティコンテストやCTFに挑戦しようとしている人、そして「AIをどう使えばいいかわからない」と悩んでいる人の参考になれば嬉しいです。
最後に一番Tokenを食っていた時の画像です...
ありがとうGoogle♡
チーム「ドルフィン」の挑戦は、まだまだ続きます。
ではまた来年！