AIは「お金と脆弱性を交換できる」世界をもたらす。米内氏に聞く“「つくる」を守るためのセキュリティ”

AIによって開発が加速し、コーディングの民主化も進みました。企業の現場ではAIを前提とした開発が広がり、これまでエンジニアではなかった人たちもコードを書けるようになっています。

それと同時に、AIは脆弱性の発見と高度なサイバー攻撃の自動化も押し上げており、「お金と脆弱性を交換できるエコノミクス」が現実味を帯びつつある――GMO Flatt Security株式会社 取締役CTOの米内貴志氏はこう指摘します。

AIによって「つくる」力と「攻撃する」力が高められていくなか、「守る」はどのように変わるのか。そして、セキュリティに携わる人間に残される役割とは何か。セキュリティの最前線に立つ米内氏にお話を伺いました。

• keyboard_arrow_down AIによる“攻撃者のスキルの底上げ”
• keyboard_arrow_down 「正しい人間が攻撃技術をつくりきる」というミッション
• keyboard_arrow_down コーディング高速化が開発現場にもたらすセキュリティリスク
• keyboard_arrow_down 誰でも「つくれる」時代に、「守る」ために必要なもの
• keyboard_arrow_down セキュリティ分野における“人間のやるべきこと”とは

――まず、ITセキュリティの領域では、どのようにAIを取り入れる動きが起こっているのでしょうか？

米内： さまざまな方向性がありますが、攻撃者側の視点、防御者側の視点に分けて考えてみましょう。

まずは攻撃者側の視点から。脆弱性の発見はかなり自動化が進んでいて、いわゆるスクリプトキディ、ツールを使って雑なスキャンをする程度のスキルの人でも、AIによって一気に高度なことができるようになり、脆弱性発見までたどり着くようになりました。この“攻撃者のスキルの底上げ”が、いまもっともAIの影響が強く現れているところだと思います。

一方、防御側でも、Googleの「CodeMender」、OpenAIの「Aardvark」など、各プレイヤーがセキュリティ用途のAIツール開発に取り組んでいて、脆弱性を発見し自動修正するところまで進んでいます。

しかし、AIをフル活用できているかどうかについては、攻撃側と防御側で差があります。

攻撃側については、AIがフィッシングキャンペーンを支援することはもはや当たり前。ENISA（欧州ネットワーク情報セキュリティ庁）などのレポートでは、テクニカルな攻撃まで自動化が進んでいると報告されています。

しかし、防御側はさらに予兆に気づくための検知や、インシデント後の対応も必要です。例えば「何時何分に／どの国・どのIPから／誰がサインインしたか」というログデータが数万件規模になると、そのままLLMで扱えるデータではなくなります。

セキュリティは「守る側は全部を見なければならないが、攻める側は1つでも粗（あら）を見つければいい」とよく言われますが、防御側は常に大量のデータを扱わなければならず、攻撃側ほど愚直にLLMを活用しにくいのが実情です。そのため、タスク特化の軽量モデルを開発して対抗せざるを得ない場合もあります。攻撃者は高性能なLLMをAPI経由で利用するだけで済むため参入障壁が下がっていますが、防御側の技術的ハードルは依然として高いままです。

――AIが急速に進化していくなかで、防御側はその恩恵を受けにくいという状態は、危険なのではないでしょうか？

米内： はい。そういった危機感もあり、弊社ではClaude 3.7 Sonnet（2025年2月末）がリリースされた直後に、自社のセキュリティ診断AIエージェント「Takumi byGMO」（以下、Takumi）をリリースすることに決めました。

Takumiは現在、ホワイトボックス診断では、96%ほどの脆弱性を発見できるようになっています。ブラックボックス診断の精度は、現時点では4〜5割程度ですが、今後さらに向上していきます。

――セキュリティ専用のAIエージェントは、Claude Codeのような汎用的に使えるAIエージェントとはどう違うのでしょうか？

米内： Claude Codeなどもモデルが賢くなっていて、「バグを探して」と指示するとわりと見つけてくれます。人間にとって難しいのは、そこから“セキュリティ的にリスクにならないもの”をはじく作業です。

脆弱性というのはレアな事象であって、ないことがほとんどなのですが、報酬モデル系のAIは、しっかり情報量のあるアウトプットを出すことに重きを置いていて、偽陽性を出してしまう傾向があります。

「ゼロ・フォールスポジティブ」（偽陽性なし）がセキュリティツールの訴求軸になるほど、いかにノイズを減らすかが大事になっていて、弊社のTakumiも力を入れているところです。

――「偽陽性を出さないこと」はなぜ重要なのでしょうか？

米内：AIを使って未知の脆弱性をいくら発見できても、「本当にリスクなのか」という吟味には、人間に相応のスキルや負担が求められる、という問題があります。「AIよりも人間のほうがスケールしにくい」という難しさは、強く感じていますね。

また、もしも偽陽性がない製品が完成したら、どうなるでしょうか？　お金さえかければいくらでも脆弱性を収穫できるようになります。

少し話が逸れるのですが、米国のDARPA（国防高等研究計画局）が主催する「AI Cyber Challenge (AIxCC)」という脆弱性を探すAI・修正するAIを競わせる大会があります。

OpenAIやAnthropicなども資金を入れていて、優勝チームには400万ドル（約5〜6億円）ほど出るのですが、今年勝利したジョージア工科大学の「Team Atlanta」も偽陽性を出さないことを重視していて、彼らはすでに「脆弱性を何割見つけられたか」ではなく「脆弱性を探すのに、1つあたり何ドルかかったか」という考え方をしています。

――「AIが発達すると、知性をお金に換算できるようになる」という話がありますが、その方向で進んでいる、と。

米内： お金と脆弱性を交換できるエコノミクスが近づいてきていると感じています。

前述の通り、防御側のAIツールが育ちにくい背景には、LLMの技術的な制約があります。いまできることは、正しい人間が攻撃技術をつくりきること。人間をスケールさせることは難しいので、AIが偽陽性を検出する確率をできるだけ下げて、次の時代に備えなければならない。それがいま、私たちが感じているミッション意識です。

――次は、開発現場についてのお話を伺います。AIエージェントによってコーディングが高速化した一方で、セキュリティ面ではどのような課題やリスクがありますか？

米内： コーディングに関してのセキュリティリスクには2つのパターンがあると考えています。1つは「つくる人」のリスク、もう1つは「つくられるもの」のリスクです。

「つくる人」に関するインシデントは、直近では、CursorやClaude CodeといったAIエージェントのユーザーを狙った攻撃が観測されています。例えば、MCPサーバー経由でのポイズニングや、NPMなどのパッケージ侵害。悪意のあるマルウェアを含んだパッケージが、AIエージェント経由で読み込まれることで、端末を操作されてしまいます。決まった行動しかできない従来のマルウェアよりも自由に、それもユーザーのリソースを使って攻撃できるわけですね。

「つくられるもの」のリスクについては、弊社は脆弱性診断・ペネトレーションテストなどのサービスを提供しているのですが、セキュリティレビューをしていて、いわゆるバイブコーディングの流行もあり、「これは人の目が入っていないかも」と感じるコードを目にする機会も増えました。AIの進化によって、アプリケーション自体が脆弱につくられてしまうリスクは高まっていると捉えています。

――「AIはセキュリティ的に問題のあるコードを出力する」という指摘は以前からありましたが、セキュリティのプロから見て、コード品質はどうなのでしょうか？

米内： AIのコードはクリティカルなミスだらけなのかというと、そうではありません。もちろんモデルやエージェントによる差はありますが、チェックしたりツールを通したりすれば防げるようなミスがほとんどです。

しかし、「AIが生成する膨大なコードを、人間がレビューしきれない」ことに起因するリスクが現れていて、「管理者にしか見えてはいけない情報が見えてしまう」「このアプリケーションではできてはいけない操作ができてしまう」といった仕様上の不備を見逃す回数が、生産量の増加に伴って増えています。

CTO同士のつながりで「AIを活用してどれくらい開発が早くなったか」という話をすることがあるのですが、やはり「人間によるレビューが重く、開発速度は2倍、3倍には上がらない」という結論になります。1.x倍にスケールするだけでも十分すごいことではあるのですが、その裏側で見落としも増えている、という状況のようです。

――AIは開発の加速だけでなく、民主化ももたらしています。「エンジニアでなくともコードが書けること」のセキュリティ面での課題は何でしょうか？

米内：オンプレ型のシステムからSaaSに移行したときも「境界外のものが増えて大変だ」「シャドウITだ」と管理に苦労し、その結果、「ゼロトラスト」などのコンセプトが注目を集め、技術的に成長してきました。

現在はあのころの比ではないほど、自由にシステムをつくれるようになっています。誰もが自動化のためのGASはもちろん、自分の手元で動くツールまで作れるようになりました。

しかし、そのようにして生まれたツールやシステムのセキュリティリスクをどう評価するのか。誰が、どのように線引きすると、“つくる人たち”の背中を押せるのか。弊社のお客さまとお話していると「みんなにバイブコーディングをしてほしい。だけど、どう統制をとるのかが問題だ」という声を聞きます。

つくる人たちの背中を押せば押すほど、管理のための認知負荷が高まる。そういった意味で、人間に高い負荷がかかる時期が続くのではないでしょうか。

――コーディングの民主化には良い側面もありますが、推奨するには難しさもある。この課題についてどう考えていますか？

米内：AIによって「このボタンを押したら動く」「通知が飛ぶ」といった機能は、誰でもつくれるようになりました。その一方で、パフォーマンスやセキュリティなどの非機能要件については、教育抜きではレベルを引き上げにくいところがあります。
「これからつくる人たちをエンジニアとしてオンボーディングしていく必要がある」という考えから、弊社ではエンジニア応援プログラムという取り組みを行っています。OSS、スタートアップ、バイブコーダーを対象に、Takumiの無料提供や、メンタリング、オンラインセミナー動画の提供などを行うものですね。

私たちも営利組織なので、弊社のことをより多くの人に知ってほしいというマーケティング的な側面もなくはないのですが、「つくる人が増えているいま、必要な取り組みだからやろう」という気持ちが7割です。

――応援プログラムのユーザーはどんな悩みを抱えていますか？

米内： スタートアップ企業の課題意識は共通しているように思います。「どれくらいセキュリティに投資すればいいのか」ですね。経営的には、セキュリティは「販管費の何％を占めるのか」という問題であり、手放しで投資できるトピックではないというのが実情です。

一方で、バイブコーダーの皆さんは、熱量がすごく高かったですね。モノをつくることは楽しい。エンジニアリングってめっちゃ楽しい。私もいちエンジニアとして共感するところです。

しかし、共通して「なんとなく不安」。具体的な困りごとがあるというより、「なんとなく」なんですよね。その「なんとなく」にお答えするものが、いまの世の中にはないんだなと感じました。

――今後、セキュリティ領域において“人間のやるべきこと”とは何でしょうか？

米内： 「何を見なくていいか」「どこを考えなくていいか」と引き算する能力は、今後もしばらく人間に求められる機能なのではないか、と思っています。

例えば、開発でも「運用を考慮すると、この機能はない方がいい」「技術負債になるからスリムにしよう」というのは大事な美学です。

セキュリティも同様で、例えば「ランディングページは切り離して、最悪の場合でも顧客資産には影響がないようにしておこう」というような設計ができていれば、コーポレート的なリスクは低減できます。システムをどう引き算・分割し、認知負荷が下がるように設計するかは、今のところ人間技でしょう。

また、セキュリティ投資は青天井です。仮に売上が1億円あれば、セキュリティ投資に1億円費やすこともできるかもしれませんが、そんなことをしたら普通は会社が潰れてしまいます。現実的には「“リスクの受容ライン”をどこに持っていくか」で決めていくものです。

ユーザーファーストに考えるのであれば「社内文書は漏れてもいいが、ユーザー環境のバックアップがなくてデータが飛んだり、ランサムウェアにやられたりするのは避けよう」といった風に線引きして、投資していくわけです。

ここもプロダクト開発に似ていますね。AIでいくらでも開発できるなかで「どういうテイストの製品にしようか」「どういう機能をつくろうか」と考え、ラインをどこで揃えるかは人間が決めること。セキュリティにおける「どこを絶対に守るか」という線引きもまた、人間が意思を持たねばならないところだと思います。