【ビジネス・セキュリティニュース 2026/8/13】「正規ユーザー」を隠れみのに侵入 信頼された基盤を狙う最新サイバー脅威【調査】／AIを選ぶのは、もうIT部門ではない？ Gartner、日本のデジタルワークプレースのハイプ・サイクル発表／ブラウザの再起動は不要になる？ Chromeが模索する「週2回のセキュリティ更新」と動的パッチ ほか
今週は「攻撃の高速化」「AIガバナンスの主導権移行」「ブラウザのアップデート革新」「SIプロジェクトの構造的失敗」と、テーマはバラバラに見えますが、いずれも「今の体制や認識でいいのか」を問い直す内容です。特にセキュリティとAIガバナンスは、自社の現状と照らして確認してほしいトピックです。
今週のトピック
「正規ユーザー」を隠れみのに侵入 信頼された基盤を狙う最新サイバー脅威
AIを選ぶのは、もうIT部門ではない？ Gartner、日本のデジタルワークプレースのハイプ・サイクル発表
ブラウザの再起動は不要になる？ Chromeが模索する「週2回のセキュリティ更新」と動的パッチ
NHKの基幹システム刷新はなぜ頓挫したのか？ メインフレーム移行から考える大型SIのリスク
① 「正規ユーザー」を隠れみのに侵入 信頼された基盤を狙う最新サイバー脅威
CrowdStrikeは2026年8月3日、年次調査「2026 Threat Hunting Report」を公表しました。一言で表すなら、「正規のアカウントやツールを使って侵入するから、従来の検知をすり抜ける」という傾向が鮮明になった報告書です。
攻撃の"速さ"が想定を超えている
まず数字を見てください。
PoC（概念実証コード）とは、脆弱性が実際に攻撃可能であることを示すサンプルコードのことです。このPoCが公開されると、攻撃者がそれをもとに実際の攻撃ツールを作り始めます。その速度が「公開から48時間以内に88%」という水準にまで達している、というのが今回の報告の核心です。
一例として、Linuxの権限昇格脆弱性（CVE-2026-31431）では、ベラルーシ系の脅威アクターUMBRAL BISONが公表から約20時間後に活動を特定されています。2026年4月29日の情報公表翌日には、CrowdStrikeが広範な展開を検知しました。最初の24時間に確認された事象のうち約94%は公開PoCをもとにした試験的な動作だったとのことで、「PoCが出たら即スキャンされている」と考えるべき状況です。
AIとソフトウェアサプライチェーンへの侵食
もう一つ注目すべきなのが、AI環境そのものへの攻撃です。
北朝鮮系の脅威アクターSTARDUST CHOLLIMAは2026年3月、盗み出したメンテナーの認証情報を使ってJavaScriptのパッケージ配布基盤「npm」のAxiosパッケージを侵害し、悪意あるコードを仕込みました。さらに6月には、少なくとも131個のMastra AIフレームワーク部品に悪質なnpmパッケージを依存関係として混入させています。2026年上半期に特定されたソフトウェアリポジトリの脅威のうち87%がnpm関連だったという数字は、AI開発の現場でも「信頼できるはずのライブラリ」が攻撃経路になりつつあることを示しています。
また、AIの普及そのものが防御側の新しい課題になっています。CrowdStrike OverWatchによると、AIエージェント起点の活動から生じる検知候補は、人間の手作業による活動の2.5倍に達しています。これは「攻撃者のAI利用が2.5倍」という意味ではなく、正常なAIエージェントの活動も大量のシグナルを生むため、悪意ある挙動との切り分けが難しくなっているという指摘です。
筆者の見方では、この報告書が示しているのは「悪いものを弾く」という境界防御の発想だけでは追いつかないという現実です。正規のアカウントが使われているなら、ログオンを通過した後の「おかしな動き」を検知する仕組みが不可欠になります。パッチ適用のスピードと、ゼロトラスト（「一度認証が通ったから安全」という前提を持たないセキュリティ設計）的な発想への移行が、具体的なアクションとして浮かび上がります。
② AIを選ぶのは、もうIT部門ではない？ Gartner、日本のデジタルワークプレースのハイプ・サイクル発表
ガートナージャパンは2026年8月5日、「日本における未来のデジタル・ワークプレースのハイプ・サイクル：2026年」を発表しました。ハイプ・サイクルとは、技術の期待値が「過熱→幻滅→実用化」の波をたどる様子を示すGartner独自の分析モデルです。
IT部門から「ビジネス部門」へ、主導権が移っている
今回のハイプ・サイクルでGartnerが挙げた注目テクノロジーは6つで、中でも特に前景化しているのがエージェント型AI（自律的にタスクを実行するAI）とAIワークスペース（従業員向けAIツールのポートフォリオ）です。
ここで情シス担当者が気になるのは、AIの選定権がどこにあるかという問題でしょう。Gartnerが指摘しているのは、AIエージェントの適用範囲がオフィス業務だけでなく工場や店舗にまで広がることで、ツールを選ぶ主体がIT部門からビジネス部門へと移りつつあるという変化です。
この変化が生み出すリスクとして名指しされているのがシャドーAIです。IT部門が把握しないまま導入・利用されるAIツールのことで、情報漏えいや統制の欠如につながるガバナンス上の課題として位置付けられています。
組織と個人の関係も変わる
今回のレポートではテクノロジー面だけでなく、組織設計の観点からも注目点があります。Gartnerは、組織開発・社内人材マーケットプレース・AI支援型スキル管理の3つを「企業と個人がより対等で柔軟な関係を結ぶ未来の組織を実現する上での中核」と位置付けています。また、デジタル従業員エクスペリエンス（従業員が業務でデジタルツールをどう体験するか、という視点）を個別ツールの価値ではなくユーザー側から評価する概念として重要視しています。
ガートナージャパンの林宏典氏（ディレクターアナリスト）は、急速に進化するAIが生産性向上や人材不足の緩和だけでなく、イノベーション促進にも寄与し得ると説明しています。そしてデジタルワークプレースは「AIと人」「AIとAI」という多様なコラボレーションを支える「企業の成長と変革を実現するプラットフォーム」へ進化する必要があるとしました。
情シスの立場から見ると、シャドーAIへの対処を「禁止・監視」だけで乗り切ろうとすると、ビジネス部門との摩擦が増すばかりです。どのAIツールは承認済みで、どの用途はNGなのかを整理したガイドラインを早めに整備しておく必要があります。
③ ブラウザの再起動は不要になる？ Chromeが模索する「週2回のセキュリティ更新」と動的パッチ
Googleは2026年7月30日、Chrome（Googleが開発するWebブラウザ）のセキュリティ対策プロセス全般でAIを使う取り組みを発表しました。脆弱性の発見から修正・配信・適用まで、全工程でAIを組み込むという内容です。
脆弱性発見の歴史を一気に振り返る
Chromeのセキュリティチームは2023年、ファジング（プログラムにランダムなデータを投入してバグを見つける自動テスト手法）にLLM（大規模言語モデル）を使い始めました。2024年にはProject Zeroが、人間のようにコードを解析して脆弱性を検証するエージェント「Naptime」を開発。2025年にはGoogle DeepMindとProject Zeroが共同で脆弱性発見エージェント「Big Sleep」を展開し、13年以上コードに潜んでいた欠陥を発見しています。
2026年初めにはGeminiを使った検出基盤を構築し、Chrome全体のコードから欠陥を探索。2026年3月時点の報告件数はすでに2025年通年の実績を上回っています。
トリアージの自動化と動的パッチへの取り組み
脆弱性の報告を受けてから優先度を判断する「トリアージ」という作業は、従来1件あたり5分〜30分以上かかっていました。これを自動化した結果、2026年5月だけで最優先対処が必要な「重大度S1+」を含む20件以上の欠陥が製品版へ混入するのを未然に防いでいます。
リリースサイクルについては、メジャーバージョンを2週間ごとのサイクルへ移行しつつあり、セキュリティ更新は毎週実施しています。さらにGoogleは、セキュリティ修正の配信を週2回に増やすパイロットも進めています。つまり、Chromeそのものを週2回メジャーアップデートするという意味ではなく、脆弱性修正をより早く届けるための取り組みです。「Big Sleep」と自動修正エージェント「CodeMender」はCI（継続的インテグレーション：コードの変更を頻繁に統合・検証する開発プロセス）環境に組み込まれ、24時間体制でコード変更を検査しています。
アップデートの適用面でも変化があります。Googleは「動的パッチ（dynamic patching）」と呼ぶ、バックグラウンドのプロセスを順次入れ替えて多くの場合にブラウザ全体の再起動を不要にする仕組みを研究開発しています。一方で、Chrome 150のmacOS版では、すべてのウィンドウを閉じてもバックグラウンドでアプリが動作し続ける状態を利用し、未適用の更新がある場合に自動で再起動して最新化する仕様変更がすでに導入されています。
企業の運用担当者にとって、パッチ適用のタイミングをコントロールする余地が変わってくる可能性があります。「ブラウザを再起動してください」という案内が不要になる未来は近いかもしれませんが、一方で「いつ自動的に更新されたか」のログ管理や、更新による動作確認の方法も合わせて整理しておくとよいでしょう。
④ NHKの基幹システム刷新はなぜ頓挫したのか？ メインフレーム移行から考える大型SIのリスク
ITmedia エンタープライズが、NHKが日本IBMを相手に、既払い金の返還と損害賠償を合わせて約54億7000万円を求めて起こした訴訟を軸にした解説ブックレット（全15ページ）を公開しています。収録記事は2025年5〜6月に公開されたものです。この訴訟は双方の主張が分かれており、ここでは公開情報をもとに大規模SIの論点を整理します。
「誰が責任を持つか」が曖昧になる構造
大規模SIでは、発注側とベンダー側の役割や責任範囲は契約やプロジェクト体制によって異なります。要件、現行資産の解析、移行方式、進捗管理について「誰がどこまで責任を持つのか」が曖昧になると、問題が起きたときに認識のずれが表面化します。長くプロジェクト管理に携わってきた立場から見ると、これは大規模SIの現場でよく起きることです。NHKと日本IBMの訴訟でも、開発方式や移行方針、プロジェクトの進め方を巡って双方の主張が分かれています。この訴訟と同じ時期に、富士通に続いて日立製作所もメインフレーム事業からの撤退を表明しました。メインフレームとは、銀行や放送局など大規模な業務処理を担ってきた高信頼性の汎用大型コンピュータのことです。国内の主要ベンダーが相次いで撤退を表明したことで、メインフレームを現役で使い続けている組織は移行を迫られる局面が近づいています。
正直に言うと、メインフレーム移行は「終わりの見えないプロジェクト」になりやすいです。既存の業務ロジックがドキュメント化されていないまま何十年も動き続けているケースが多く、要件定義の段階で「自分たちも把握していなかった仕様」が次々と出てくる。その積み重ねが、スコープと費用と責任のズレを生みます。
移行プロジェクトを始める前に整理すること
大規模な基幹システム移行を控えている組織にとって重要なのは、技術選定だけではありません。現行資産をどこまで把握できているか、移行方式の前提は妥当か、発注側とベンダー側の責任範囲や受け入れ基準は明確か。NHKと日本IBMの事例は、こうした条件をプロジェクト開始前から明文化しておく重要性を考える材料になります。契約書の責任範囲と受け入れ基準の確認を、今週の行動として挙げておきます。
おわりに
今週の4トピックに共通しているのは、「既存の前提が崩れ始めている」という感覚です。信頼済みのアカウントが侵入経路になり、AIの選定権がIT部門から離れ、ブラウザのアップデート運用も変わり、大型SIの構造的問題が法廷で問われる。どれも「今まで通り」では対処できない問いを突きつけています。
気になるトピックがあれば、スキやコメントで教えていただけると参考になります。
あわせて読みたい
この記事に関連する実践的な内容を、さらに詳しく整理しています。
このテーマの記事は「ビジネス基盤」マガジンにまとめています。 → マガジンを見る
いいなと思ったら応援しよう！
記事が役に立ったと感じたら、応援いただけると励みになります。
