BSides Bangaloreから考える、AI時代のセキュリティ人材はツール運用より攻撃ライフサイクル理解が必要

先に結論

AI時代のセキュリティで差がつくのは、どのツールを入れたかではなく、そのツールが上げたアラートを誰が最初に見て、それが攻撃のどの段階なのかを判断できるかどうかです。

EDRもSIEMもクラウドの監査ログも、それ自体は「気づく」ための仕組みにすぎません。気づいた通知を読み、これは偵察の足音なのか、すでに権限を奪われた後なのかを切り分け、止める判断を下せる人がいて初めて防御になります。中小企業でセキュリティ事故が深刻化するのは、製品がなかったからではなく、通知が届いても読む人・止める権限を持つ人が決まっていなかったからであることが少なくありません。

この記事は、攻撃者がどんな順序で内部に入り込むのかという「攻撃ライフサイクル」を軸に、限られた人員の会社が最初に何を理解し、どこに人を配置し、外部に何を任せるべきかを整理します。ツール名を覚える研修ではなく、体制の設計として読んでください。セキュリティ全般の考え方はGXOのセキュリティ事業のページにもまとめています。

この記事を読むべき人

• EDRやSIEM、あるいはSaaSの高いプランを入れたのに、本当に守れているのか自信が持てない経営者・情シス担当者
• セキュリティ担当が兼任1名、あるいは実質不在で、「詳しい人を採ればいい」と思っているが採用も進んでいない中小企業
• MSSPやシステム会社に監視を委託しているが、夜間や休日に何が起きるのか、止める権限は誰にあるのかを確認したことがない会社
• 標的型メール訓練を毎年やっているのに、なぜか手応えがなく、続ける意味を見失いかけている担当者
• AIによって攻撃が速く・巧妙になっていると聞き、何から手をつければいいのか判断軸が欲しい方

一つでも当てはまるなら、この先の「攻撃ライフサイクル」の見方が、投資と人の優先順位を決める物差しになります。

何が起きているのか（フックとしてのBSides）

2026年7月9日、インドのバンガロールでコミュニティ主導のセキュリティカンファレンス「BSides Bangalore」が開催されました。BSidesは世界各地で有志が運営する非営利のセキュリティイベントの総称で、経営層向けの円卓から、研究発表、実機を触るワークショップ、CTF（旗取り競技）まで、実務者と経営者が同じ場で議論するのが特徴です。

ただし、ここで注意したいことがあります。あるカンファレンスが開催され、そこでAIとセキュリティが語られること自体は、「だから中小企業の人材育成はこうすべきだ」という結論を直接支える根拠にはなりません。海外のイベントの登壇内容や参加者数を確認しないまま引用して一般論に飛躍するのは、この種の記事が最も陥りやすい誤りです。本記事はBSidesを「AI時代のセキュリティ人材が話題になっている」という時流のきっかけ（フック）としてのみ扱い、主張の論拠はカンファレンスの中身ではなく、後述する「攻撃ライフサイクルという枠組みそのもの」に置きます。

その枠組みが今なぜ重要かというと、AIは攻撃の各工程を速く・安く・大量にする方向に働くからです。もっともらしい日本語のフィッシング文面、標的企業の公開情報を突き合わせた偵察、侵入後の環境調査。かつては人手と時間がかかっていた作業が短縮されると、「気づいてから動く」までの猶予も短くなります。守る側が製品の数で対抗しようとしても、読む人がいなければ猶予は縮む一方です。だからこそ、道具の数ではなく、攻撃の流れを理解した人の配置が問われます。攻撃側のAI活用がなぜ経営が向き合うべき課題になるのかは、Five Eyes警告から考えるAI時代のサイバーリスクの記事でも掘り下げています。

「ツールを入れたのに守れない」という構造

多くの中小企業のセキュリティ投資は、「良い製品を入れる」で止まっています。EDR（端末の不審な挙動を検知する仕組み）を導入した、SIEM（各種ログを集めて相関分析する仕組み）のライセンスを買った、クラウドの上位プランで監査ログを有効にした。ここまでは予算さえあれば実行できます。問題はその次です。

これらの製品は、異常があると必ず「アラート」を出します。しかしアラートは「これは攻撃です、今すぐ止めてください」という親切な文章では届きません。多くは「このプロセスがこの権限でこのファイルにアクセスした」「見慣れないIPからログインが成功した」といった、事実の断片です。それが業務上正常なのか、攻撃の兆候なのかを切り分けるには、読む側に知識と文脈が要ります。ここが埋まっていないと、次の三つのうちどれかが起きます。

一つ目は、アラートが溜まって誰も読まなくなるパターンです。通知は毎日何十件も届き、そのほとんどは誤検知か無害な業務です。切り分けられる人がいないと、「また出ている」で流すのが習慣になり、本物が混ざっていても埋もれます。二つ目は、全部を真に受けて疲弊するパターンです。とりあえず全件を情シス兼任者が抱え込み、本業が回らなくなって、結局は運用が形骸化します。三つ目は、最も危ういもので、アラートは出ていたのに事故後に初めて「そういえばあの通知は本物だった」と気づくパターンです。

中小企業でこれが起きやすいのには理由があります。専任のセキュリティ担当がいない、いても総務や情シスとの兼任で、日々の問い合わせ対応やPC調達に時間を取られる。アラートを読む時間が業務時間の中に確保されていない。夜間・休日は誰も画面を見ていない。そして何より、「見て、これは危ないと思ったときに、サーバーを止めたりアカウントを凍結したりする権限」を誰が持つのかが決まっていない。製品は買えても、この「人と権限の設計」はお金では買えません。ここを設計する視点はセキュリティ運用の伴走パッケージのような、判断できる人を外から補う考え方にもつながります。

つまり、守れないのはツールが悪いからではなく、ツールと「読んで止める人」の間が断線しているからです。次章の攻撃ライフサイクルは、この断線がどの段階で致命傷になるかを見えるようにするための地図です。

攻撃ライフサイクルという見方

攻撃は、ある日突然データが暗号化される単一の事件ではありません。多くの場合、攻撃者は複数の段階を順に踏んで内部に居座り、時間をかけて目的に近づきます。一般的に、その流れはおおまかに次のように説明されます。これは特定の製品や特定のフレームワークの定義そのものではなく、攻撃の順序を理解するための共通言語として捉えてください。

1. 偵察：公開情報、SNS、求人票、取引先情報などから、狙う相手と入り口を調べる段階。
2. 初期侵入：フィッシング、認証情報の使い回し、公開サーバーの脆弱性などを突いて、最初の一歩を得る段階。
3. 足場の確保：入った先で、再侵入できる仕組みや常駐する仕掛けを用意する段階。
4. 権限昇格：一般利用者の権限から、管理者権限やより強い権限を奪う段階。
5. 内部探索：どこに重要データがあるか、どのサーバーが動いているかを内部から調べる段階。
6. 横展開：一台から別の端末・サーバー・クラウド・SaaSへと侵入範囲を広げる段階。
7. 目的の実行：データの暗号化（ランサムウェア）、持ち出し、破壊など、最終目的を果たす段階。

この見方の価値は、「何が痕跡として残るか」と「どこで止められるか」を段階ごとに結びつけられる点にあります。守る側は全段階に均等に構えることはできませんが、段階ごとに「本来ここで気づけるはずの兆候」を知っていれば、限られた注意力をどこに向けるかを決められます。

ここで重要なのは、右端の「止められる可能性」は、後ろの段階に行くほど狭く・難しくなるという事実です。目的の実行段階、たとえばファイルが暗号化され始めてからでは、できることは被害を広げないことと復旧に切り替えることに限られます。逆に、初期侵入や権限昇格の段階で気づければ、被害はまだ点にとどまっています。防御の投資対効果は、後段で慌てるより前段で気づく体制に置いたほうが高い。この「早い段階ほど安く止まる」という力学が、次章の優先順位につながります。

なお、実際に事故が起きた後の初動と封じ込め、原因調査についてはインシデント対応支援のページで扱っている考え方も参考になります。攻撃を「点」で理解するのではなく、段階の連なりとして理解しておくことが、事故対応の速さにも効いてきます。

中小企業が最初に押さえるべき段階

七つの段階すべてに専任者を置いて監視するのは、大企業でも簡単ではありません。人員が限られる中小企業にとっては非現実的です。ではどこに絞るか。結論から言えば、「初期侵入」と「権限昇格」の二点です。理由は三つあります。

第一に、この二段階は攻撃の「入口」と「増幅点」だからです。初期侵入を防げれば、そもそも中に入られません。仮に入られても、権限昇格を止められれば、攻撃者は一般利用者の狭い権限のまま動くしかなく、被害の広がりが大きく抑えられます。逆にこの二点を抜かれると、後段の内部探索・横展開・目的の実行は一気に進みます。少ない手数で効くのがこの二点です。

第二に、この二段階は中小企業でも「打てる手が具体的にある」からです。初期侵入に対しては、多要素認証の徹底、公開しているサーバーやVPN機器のパッチ（AIが脆弱性発見を速める中でのパッチ運用の考え方はこちらの記事で扱っています）、そして人へのメール訓練。権限昇格に対しては、管理者権限を普段使いしない、管理者アカウントの棚卸し、退職者や外注先アカウントの停止、特権付与を承認制にする。いずれも、高価な製品を新規購入しなくても、運用ルールと既存機能の設定で相当程度進められます。緊急の脆弱性が公表されたときに自社への影響と対応順を見極める動きは、緊急脆弱性・CVE影響診断のような枠組みで整理できます。

第三に、この二段階は「気づきやすい」からです。前章の表のとおり、見慣れない場所からのログイン成功や、管理者グループへの不審な追加は、比較的はっきりした痕跡を残します。読む人さえいれば、専門家でなくても「これはおかしい」と気づける粒度です。逆に内部探索や横展開の兆候を切り分けるには高い専門性が要ります。まず自社で押さえるのは、気づきやすく効果の大きい入口と増幅点。専門性の要る後段は外部と組む。この役割分担が、限られた人員での現実解です。

どの対策から着手するかを迷う場合は、自社の状況に合わせて優先順位を並べ替えるセキュリティ対策の優先順位整理のような入口から始めると、いきなり製品選定に走らずに済みます。

人を育てるか、外に出すか、の判断

守るべき段階が見えたら、次は「誰がやるのか」です。選択肢は大きく、社内で人を育てる・外部に委託する・両者を組み合わせる、の三つです。判断の分かれ目は、兼任担当者に何を期待でき、何を期待できないかを正直に見積もることにあります。

現実的に、兼任のひとり情シスに期待できるのは、次のような「決まった手順で回せる守り」です。多要素認証が全員に効いているかの確認、退職者アカウントの停止漏れがないかの棚卸し、管理者権限を持つ人のリスト管理、パッチ適用の進捗確認、そして日々のアラートの一次確認（明らかに正常/明らかに異常/判断がつかない、の三分類まで）。ここまでは、育成と手順化で任せられます。

一方で、兼任担当者に期待すべきでないのは、「専門的な切り分けと24時間の監視」です。判断がつかないアラートが本物かどうかの精密な分析、深夜に始まった攻撃への即応、フォレンジック（痕跡の科学的な調査）は、片手間でできる仕事ではありません。ここを兼任者に丸投げすると、本業も守りも共倒れになります。この線引きを曖昧にしたまま「うちの情シスに任せている」と言っている状態が、最も危険です。

外部に委託する場合も、「丸投げ」にしてよいわけではありません。委託して安心なのは、自社が最低限「何を任せて、何は自分たちの責任として残したか」を理解しているときだけです。たとえば、監視は委託しても、止める判断と実行の権限は自社に残る、というケースは多い。そのとき自社側に「攻撃ライフサイクルのどの段階の話をされているのか」が分かる人がいないと、委託先から連絡が来ても即断できません。つまり、外に出すほど、自社側にも「通訳できる最低限の理解」を持った人が要る。これは矛盾ではなく、委託を機能させる前提条件です。判断できる人を月額で外から補うセキュリティ運用の伴走型パッケージは、この「社内に判断者がいない」問題への一つの現実的な答えになります。

社内教育で実際に効くもの

社内教育というと、多くの会社がまず標的型メール訓練（偽のフィッシングメールを送って開封率を測る訓練）を思い浮かべます。これは初期侵入の入口を守る施策として意味がありますが、限界もはっきりしています。

限界の一つは、開封率という数字が独り歩きしやすいことです。開封率が下がったからといって、巧妙化した本物のメールを見抜けるとは限りません。訓練メールは往々にして本物より分かりやすく、AIで自然になった最新のフィッシングとは質が違います。もう一つの限界は、「引っかかった人を責める」空気を作ると、本当に怪しいメールを開いてしまったときに報告が遅れることです。攻撃対応で最も価値があるのは「早い報告」なのに、訓練が報告をためらわせる方向に働けば本末転倒です。

それでも訓練を続ける意味はあります。第一に、全員に「クリックする前に一呼吸置く」習慣を残すこと。第二に、「怪しいと思ったらすぐ報告してよい、報告した人は評価されこそすれ責められない」という文化を根づかせること。訓練の目的を「開封率を下げる」から「怪しいと思ったら報告する行動を増やす」に置き換えると、続ける価値が明確になります。開封率よりも報告率を指標にする、という発想の転換です。

そして、メール訓練よりも先に決めるべき、地味で最も効く一手があります。それは「アラートを誰が最初に見るか」を人の名前で決めることです。EDRやSIEM、クラウドの通知が、共有メールボックスに届いて誰の担当でもない、という状態が事故を大きくします。平日の日中は誰、その人が不在のときは誰、そして夜間・休日はどうするのか。一次確認する人、判断がつかないときにエスカレーションする先、止める権限を持つ人。この三役を実名で決め、紙一枚に書いておく。高価でも難しくもありませんが、これがないと他のすべての投資が「通知が届く先のない仕組み」になります。教育とは、知識を配ることである以前に、この役割と連絡の道筋を全員が知っている状態を作ることです。

委託先・MSSPに聞く質問

監視やセキュリティ運用を外部（MSSP＝マネージド・セキュリティ・サービス・プロバイダーなど）に委託している、あるいはこれから委託する会社は、契約の前後で次の質問をぶつけてみてください。答えが曖昧なまま契約すると、「監視しているつもり」の空白地帯が生まれます。

• 何を監視していますか。端末（EDR）だけか、サーバーやクラウド、SaaSのログイン、ネットワークまで含むのか。攻撃ライフサイクルのどの段階を見ているのかを具体的に。
• 何は監視していませんか。契約範囲の外を明確に。多くの事故は「見ていると思っていたが範囲外だった」場所で起きます。
• アラートは誰に、どの手段で届きますか。自社の誰の携帯・メールに、何分以内に届くのか。共有アドレス止まりになっていないか。
• 夜間・休日はどうなりますか。24時間365日の人による監視か、日中だけか、自動検知だけで人は翌営業日に見るのか。攻撃は営業時間を選びません。
• 止める権限は誰にありますか。委託先が独自にサーバーを隔離・アカウント停止できるのか、それとも自社の承認が要るのか。承認が要るなら、その承認者は夜間に捕まるのか。
• 誤検知が多いとき、どう調整しますか。アラート疲れを防ぐチューニングの責任は誰にあるのか。
• 事故が起きたとき、どこまでやってくれますか。検知の通知までか、封じ込めまでか、原因調査（フォレンジック）や復旧まで含むのか。含まないなら、その部分は誰が担うのか。

これらは専門知識がなくても聞けます。むしろ、答えを聞いて自社側で判断するために必要なのが、前章までの「攻撃ライフサイクルの共通言語」です。相手の説明がどの段階の話なのかが分かれば、抜けている段階を自分で見つけられます。委託は、任せることではなく、任せた範囲と残した責任を自分で説明できる状態を作ることだと考えてください。

よくある誤解

最後に、投資判断を鈍らせる典型的な思い込みを四つ挙げます。いずれも「もっともらしいがゆえに危ない」ものです。

「ツールを入れたから安全」 ── 本記事の中心的な論点です。ツールは気づくための仕組みであって、気づいた通知を読んで止める人と権限がなければ、防御にはなりません。導入は出発点であって、到達点ではありません。

「セキュリティ人材を採用すれば解決する」 ── 一人の専門家を採れば安心、という発想は、二つの点で危うい。まず、そもそも人材は市場全体で不足しており、中小企業が専任を採り切るのは容易ではありません。次に、仮に採れても、一人に依存すればその人が休んだ日・辞めた日に穴が空きます。必要なのはヒーロー一人ではなく、役割分担と、抜けたときに埋まる仕組みです。

「うちは小さいから狙われない」 ── 攻撃の多くは、標的を厳選した狙い撃ちではなく、脆弱な入口を機械的に探す網です。AIで偵察と攻撃が自動化・大量化するほど、規模の小ささは守りにはなりません。むしろ守りが手薄な中小企業が、大手取引先へ入り込む踏み台として狙われることもあります。

「資格を持っている人がいれば守れる」 ── 資格は基礎知識の証明として有用ですが、資格の有無と「自社のアラートを読んで止められるか」は別問題です。守れるかどうかを決めるのは、自社の環境・権限・連絡網に即した運用が回っているかであって、免状の数ではありません。

これらの誤解は、いずれも「一度の意思決定（買う・採る）で守りが完成する」という前提を共有しています。実際の守りは、日々アラートを読み、役割を回し、抜けを埋め続ける運用です。その運用を誰がどう担うのかを設計するところから始めてください。

FAQ

Q. EDRを入れれば、まず一安心と考えてよいですか。 A. EDRは端末の不審な挙動に「気づく」ための強力な仕組みですが、上げたアラートを読んで判断する人がいて初めて機能します。導入と同時に、平日日中・不在時・夜間休日それぞれで誰が一次確認するかを決めてください。決めていなければ、EDRは「誰も見ない通知を出す装置」になりかねません。

Q. 全段階を守るのは無理そうです。どこから手をつけるべきですか。 A. まず「初期侵入」と「権限昇格」の二段階です。多要素認証の徹底と公開資産のパッチ（初期侵入対策）、管理者権限の棚卸しと承認制（権限昇格対策）は、高価な製品を買わずに運用ルールで相当進められ、かつ痕跡が比較的はっきり残るため気づきやすい領域です。

Q. 標的型メール訓練を毎年やっていますが、効果を感じません。続けるべきですか。 A. 開封率を下げる目的だと手応えが薄いのは自然です。指標を「怪しいと思ったら報告する行動を増やす」に置き換え、報告した人を責めない文化とセットで続けると意味が出ます。攻撃対応で最も価値があるのは早い報告です。

Q. 兼任のひとり情シスに、どこまで任せてよいですか。 A. 多要素認証の確認、退職者アカウントの停止、管理者リストの管理、パッチ進捗、アラートの一次三分類までは、手順化すれば任せられます。判断がつかないアラートの精密分析や夜間の即応、フォレンジックは片手間では無理なので、外部と組む前提で考えてください。

Q. 監視を外部に委託すれば、社内には詳しい人はいらなくなりますか。 A. いいえ。委託先からの連絡が攻撃のどの段階の話なのかを理解し、止める判断を下す人は社内に必要です。外に出すほど、社内には「通訳できる最低限の理解」を持つ人が要ります。それがないと、連絡が来ても即断できません。

Q. AIで攻撃が進化していると聞きます。中小企業は何を変えるべきですか。 A. 新しい製品を増やすより先に、「アラートを最初に見る人・エスカレーション先・止める権限者」を実名で決めてください。AIは攻撃を速く・大量にするので、気づいてから動くまでの猶予が縮みます。猶予を縮ませないのは製品の数ではなく、通知が確実に人に届く体制です。

Q. セキュリティ人材はどれくらい不足しているのですか。 A. 経済産業省が2025年5月に公表した「サイバーセキュリティ人材の育成促進に向けた検討会 最終取りまとめ」では、国内で約11万人のサイバーセキュリティ人材が不足しているという民間調査結果が示されています。同省は情報処理安全確保支援士（登録セキスペ）を2030年までに5万人へ増やす目標を掲げています（2025年4月時点で約2.4万人）。採用だけで穴を埋めるのが難しい市場環境だと分かります。

参考・出典

• 経済産業省「『サイバーセキュリティ人材の育成促進に向けた検討会最終取りまとめ』を公表しました」（2025年5月14日公表、一次情報）: https://www.meti.go.jp/press/2025/05/20250514002/20250514002.html （2026-07-10 確認。国内約11万人不足・登録セキスペ2030年5万人目標・2025年4月時点約2.4万人の出典）
• OWASP GenAI Security Project（一次情報・生成AIのセキュリティ観点の参考）: https://genai.owasp.org/ （2026-07-10 確認）
• NIST AI Risk Management Framework（一次情報・AIリスク管理の枠組みの参考）: https://www.nist.gov/itl/ai-risk-management-framework （2026-07-10 確認）
• Security BSides Bangalore 2026（開催概要・二次情報。本文ではフックとしてのみ言及し、登壇内容の詳細は主張の根拠にしていません）: https://bsidesbangalore.in/ （2026-07-10 確認。開催日2026年7月9日を確認）

※攻撃ライフサイクルの段階分けは、攻撃の順序を理解するための一般的な説明として記述しており、特定のフレームワークの定義を断定的に引用したものではありません。