専門学校生がAIエージェントにKali Linuxを完全自動操作させてセキュリティコンテストで優勝した話

目次

はじめに：なぜ「AIに全部やらせた」のか
チーム紹介：異種混合の「ドルフィン」
1次予選
2次予選（本選）
振り返り：AI時代のセキュリティ

はじめに：なぜ「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♡

チーム「ドルフィン」の挑戦は、まだまだ続きます。
ではまた来年！