セキュリティがソフトウェアファクトリーの導入を加速する

「AIには休息が必要なく、睡眠もとらず、祝日も休暇もない。」 – パク・ムンボム、78ResearchLab CPO（韓国語原文からの翻訳）¹

2026年9月30日、新韓銀行（Shinhan Bank）が顧客情報の流出を韓国の金融当局に報告しました。2週間後の10月14日、金融当局が集計した被害範囲は、銀行・貯蓄銀行・キャピタル会社・暗号資産事業者を含む16社、約10万件に広がっていました。² 同じ月の6日には、汝矣島純福音教会とサラン教会が、ハッキングによって信徒の情報が流出した形跡があると明らかにしました。³ それに先立つ9月3日には、政府の調査団が動画配信サービスのTVING（ティービング）で約3,954万件のアカウントが流出したと発表しています。⁴

今回の金融業界の事故には、AIが使われたという話がついて回っています。しかし2026年10月15日時点で、これは 確定した事実ではありません。 金融当局はAIの使用有無をまだ調査しています。² 確認されているのは、複数のセキュリティ企業が攻撃インフラからLLMベースの自動侵入ツールの痕跡を報告した、というところまでです。⁵ それでも私は、この状況を軽く見過ごすことはできないと考えています。攻撃側がすでにエージェントで仕事を始めているのなら、防御側が人間の速度で動く体制は長くはもたないからです。

この記事の主張は一つです。私は、セキュリティの圧力がソフトウェアファクトリーの導入を早めると考えています。 攻撃は速くなっています。AIで脆弱性を見つける企業は、今や修正能力をボトルネックとして指摘しています。規制は修正期限を短くしています。これらの圧力は、発見から修正・デプロイまで人がボトルネックにならない開発体制、つまりソフトウェアファクトリーの方向を指していると私は考えます。ただし、これは「人なしで動く工場」を意味しません。人がルールを決め、機械はそのルールの中で休まず実行します。

TL;DR

• 最近の韓国国内の事故で、調査によって確認された原因や複数のメディアが報じた原因は、新しい攻撃手法ではありませんでした。ソースコードに残ったアクセスキー、迂回された認証手続き、適用されていないセキュリティパッチのように、基本的な統制が欠けていた箇所でした。
• AIが変えるのは、攻撃の種類よりも速度と規模です。攻撃者が基本統制の隙間を見つける速度が上がれば、隙間を発見して塞ぐまでにかかる時間が防御の中核指標になります。
• 圧力はすでに動いています。AIが脆弱性を見つける速度に修正が追いつかず、米国・EU・韓国の規制は修正期限を短くしたり、迅速なパッチ適用の障壁を下げたりしており、修正まで行うAIツールも登場しています。ただし導入はまだ初期段階で、自動修正への信頼も障壁の一つに挙げられています。
• 私は、ソフトウェアファクトリーがその時間を短縮する有力な体制だと考えています。発見された問題をタスクにし、エージェントが修正し、証拠で検証し、失敗をルールに変えます。
• ただし、ファクトリー自体が新たな攻撃面になります。リスク等級、書き込み権限の分離、人による停止コマンドといった仕組みなしに作られたファクトリーは、セキュリティを高めるどころか脅威を増やします。

1. 韓国で何が起きているのか

下の表は、2026年10月15日までに公表された主な事故をまとめたものです。政府の調査や被害機関が明らかにした原因と、報道機関やセキュリティ企業が報道・主張した原因を区別して記載しました。

統計も同じ方向を指しています。科学技術情報通信部とKISA（韓国インターネット振興院）によると、2026年上半期の侵害事故の届け出は1,236件で前年より19.5%増え、そのうちランサムウェアの届け出は76.8%増えました。⁸

AIが関与したという主張はどこまで確認されたのか

ここでは事実と推測を分けて見る必要があります。

• セキュリティ企業の分析（複数）： Genians、Oasis Security、S2Wは、攻撃に使われたと推定されるサーバーから、中国語ベースの自律型ペネトレーションテストツールARTEXの痕跡を報告しました。S2WはARTEXとAIモデルをつなぐ中継プログラムも発見したと明らかにしました。ただしS2Wは、データ窃取のどの部分をAIが実行したのかは当局が調査すべきだとしています。⁵
• CrowdStrike（中程度の確信度）： Reutersの報道によると、CrowdStrikeは攻撃者がARTEXとAnthropicのClaude Codeを使ったと主張しました。この評価は「中程度の確信度（moderate confidence）」によるもので、特定の攻撃グループへの帰属は行っていないと自ら明らかにしています。⁹
• 政府： 金融委員会の10月2日の報道資料は、事故を「サイバー攻撃」と「侵害の試み」としか記述していません。10月14日の時点でも、当局はAIによるハッキングかどうかを調査中でした。²

まとめると、「LLMベースの攻撃自動化ツールの痕跡が攻撃インフラで見つかった」というのは複数の企業が報告した内容です。「AIがこの攻撃を実行した」というのは、まだ確認されていません。

海外にはより明確な記録があります。Anthropicは2025年11月、中国の国家が背後にいると判断したグループがClaude Codeを自律型の侵入エージェントとして構成して約30の組織を狙い、戦術的な作業の80〜90%をAIが実行したと報告しました。この数値はAnthropic自身の分析です。¹⁰

2. 変わったのは攻撃の種類ではなく速度だ

78ResearchLabのCPOでセキュリティ専門家のパク・ムンボム氏は、今回の事故についてこう書いています（以下の引用は韓国語原文からの翻訳）。この攻撃は「既存の攻撃手法にAIという『ターボエンジン』を付けて効率と規模を最大化したもの」であり、現場の専門家が感じている危機感の正体は、防御のパラダイムが時間をかけて崩れたのではなく「一瞬で崩れた」ことにある、と。¹

彼が挙げた例は印象的です。かつては中国の春節や中秋節になると、中国発のサイバー攻撃が目に見えて減りました。人間の攻撃者には休みの日があり、その間に防御側は分析し対応する時間を稼げました。AIにはそのような日がありません。

第1節の表とこの観察を重ねると、一つの構図が見えてきます。政府の調査で確認された原因や複数のメディアが報じた原因は、どれも古い問題でした。ソースコードに入れられた秘密鍵（TVING、Coupang）、従業員の退職後も変更されなかったキー（Coupang）、認証の迂回が報じられた付属の照会サービス（新韓銀行）、適用されていないパッチ（金融当局の点検）です。金融当局が10月に555の金融会社を点検した結果でも、130社でセキュリティパッチの未適用、24時間監視の不在、多要素認証の未導入といった基本統制の不備が見つかりました。¹¹ 実際、一部の分析は、今回の事故の核心的な原因はAIではなく、外部に公開されたAPIの権限検証の欠陥だとみています。¹²

私は、この二つの解釈は矛盾しないと考えています。AIは新しい穴を作るというより、もともとあった穴を人間よりはるかに速く見つけられるのです。 Anthropicが報告した事例のように、AIエージェントが偵察と侵入作業の大部分を担えば、攻撃者一人が同時に試せる対象と回数が増えます。¹⁰

攻撃が速くなっていることは、AIとは別に脆弱性の統計にも表れています。Google MandiantはM-Trends 2026で、平均time-to-exploit（脆弱性の公開から実際に悪用されるまでの時間）を約-7日と推定しました。平均がマイナスであるということは、公開前に悪用された事例が集計に含まれていることを意味します。¹³ VulnCheckは、2025年に悪用された脆弱性の28.96%が公開当日またはそれ以前に悪用されたと集計しました。2024年は23.6%でした。¹⁴ この二つの統計はAIがその原因であることを示しておらず、私はMandiantの算出方法も確認できていません。ただ、脆弱性の公開後に防御側が対応を始められる余裕が減っているという方向は、両方の資料で一致しています。

攻撃者が隙間を見つけるのにかかる時間が数日から数時間に縮まれば、防御側にとって重要な指標も変わります。隙間を発見してから塞ぐまでにかかる時間 です。TVINGは2024年のペネトレーションテストで脆弱性を発見しましたが修正せず、その脆弱性が2026年の事故につながりました。⁴ 発見はしたものの、修正が追いつかなかったのです。

3. 人の順序に縛られた対応は、この速度についていけない

従来のセキュリティ対応は、おおむね人の順序に従います。脆弱性の報告が入ると担当者が確認し、開発チームに作業を依頼し、開発者が日程を組んで修正し、レビューを経て定期リリースのスケジュールに載せます。各段階は合理的です。問題は各段階の間の待ち時間です。担当者が休暇中だったり、開発チームが別の予定に縛られていたり、リリースが来月に予定されていたりすれば、その間ずっと隙間は開いたままです。

これは個人の勤勉さでは解決しません。パク・ムンボム氏が言うように、攻撃は祝日にも休まないのに、防御体制の各段階は人の勤務時間に縛られています。彼は、より多くの人員と機材の投入を結論として挙げました。¹ 私もその必要性には同意します。ただ、人を増やすだけでは、待ち時間という構造的な問題は消えません。人が増えても、各段階は依然として人の勤務時間と承認の順序に縛られるからです。

既存のCI/CDや緊急変更手続きで十分ではないか、という反論もあるでしょう。CI/CDは、人が書いたコードをビルドしてデプロイする段階を自動化します。緊急変更手続きは承認段階を減らします。しかし修正作業の大半が手作業の組織では、問題を分類し、原因を見つけ、修正コードを書き、その修正が正しいという証拠を作る仕事を、依然として人が行っています。私は、そうした組織ではこの前段の待ち時間が最大の空白だと考えています。逆に、パッチの自動化と緊急対応の体制がすでに十分に整っている組織であれば、ファクトリーが加えられる分はそれだけ小さいでしょう。

4. 圧力はすでに動いている

攻撃の速度だけではありません。2026年には、ファクトリーの方向へ押す圧力が三つの方向から同時に観察されます。以下では、事実、企業の主張、見通しを区別して整理します。

4.1 発見を自動化した側が、修正をボトルネックとして指摘している

Anthropicは2026年5月のProject Glasswingの中間報告で、AIでオープンソースプロジェクトの脆弱性を見つけてメンテナーに約530件を報告したものの、そのうちパッチが当てられたのは75件だけだったと明らかにしました。そして、こう診断しています。「このようなバグを修正する際のボトルネックは、それらをトリアージし、報告し、パッチを設計してデプロイする人間の能力である（the bottleneck in fixing bugs like these is the human capacity to triage, report, and design and deploy patches for them.）」¹⁵ 10月には、トリアージとパッチ適用が「いまだにほとんど手作業（still mostly manual）」であるとして、これを自動化することを次の目標に掲げました。¹⁶ これは企業自身の発表です。しかしForresterも同じ方向を予測しています。「発見は今や安価だ。価値があるのは修正の側だ（Discovery is now cheap. Remediation is where the value lives.）」¹⁷

これは一企業の観察であり、530件中75件という数値だけで、業界全体のボトルネックが移ったとは言えません。しかし、AIが脆弱性を見つける速度が攻撃側と防御側の双方で同じように上がるのなら、防御側が先んじられるのは、見つけたものをより速く直す側だと私は考えます。そして、ここがソフトウェアファクトリーの入る場所だと考えています。

4.2 規制が修正期限を短くし、迅速なパッチ適用の障壁を下げている

• 米国（事実）： CISAは2026年6月にBOD 26-04を発令し、連邦の民間機関に対して、最も危険な脆弱性を最短3日以内に対処するよう求めました。優先順位の基準には「大規模な自動化攻撃が可能かどうか」が含まれています。¹⁸
• EU（事実）： 2026年9月11日から、サイバーレジリエンス法（CRA）により、製造業者は実際に悪用されている脆弱性を24時間以内に早期報告しなければなりません。これはパッチの期限ではなく報告の期限です。¹⁹ 欧州中央銀行（ECB）は、直接監督する約110の銀行に対し、AIを用いたサイバー脅威への対応実行計画を10月31日までに提出するよう求めており、重点領域にパッチ管理が含まれています。²⁰
• 韓国（事実）： 金融委員会は2026年5月、セキュリティ目的のAIに限って、大手金融会社49社のネットワーク分離規制を1年間時限的に緩和する案を打ち出しました。²¹ 6月には、AIによるセキュリティテストや、当局が周知した脆弱性に対する緊急セキュリティパッチの過程で生じた軽微なシステム障害を、制裁から免責することを議決しました。²² 迅速にパッチを当てる際に生じる障害の制裁リスクを減らしたわけです。ただし免責の範囲は狭いものです。
• 韓国（事実）： 今回の金融業界の事故の後、10月14日に金融委員会のシン・ジンチャン事務処長は、「『AIによる攻撃はAIで防御する』セキュリティ体制を確立するため、ネットワーク分離規制の緩和など制度改善も、より綿密かつスピード感をもって推進していく」と述べました（韓国語原文からの翻訳）。²³ 同じ記事には、今回の事故をネットワーク分離の改編と直接結びつけるのは適切ではないという専門家の反論も掲載されています。
• 韓国（計画）： 科学技術情報通信部は5月の民間情報保護推進計画（案）で、高性能AIモデルを脆弱性の自動分析とパッチ生成に試験適用すると明らかにしました。実施時期と予算は確認できていません。²⁴

これらの措置のどれも、「エージェントがコードを直してデプロイせよ」とは求めていません。しかし修正期限は短くなり、迅速なパッチ適用やセキュリティ目的のAIを阻んでいた制度的な障壁は下がりつつあります。私は、これは人の勤務時間に縛られた修正手続きでは合わせにくい方向だと考えています。

4.3 ツールはすでに修正まで行う

• DARPA AI Cyber Challenge（事実）： 2025年8月の決勝で、参加チームの自律システムは合成脆弱性54件を見つけ、43件にパッチを当てました。タスクあたりの平均パッチ時間は約45分、コストは約152ドルでした。²⁵
• GitHub Copilot Autofix（企業の主張）： パブリックベータのデータで、PR時点のセキュリティアラートの修正時間の中央値が、手作業の1.5時間から28分に短縮されました。²⁶
• Google DeepMind CodeMender（企業の主張）： 6か月間でオープンソースプロジェクトにセキュリティ修正72件を反映しました。すべてのパッチは提出前に人がレビューしました。²⁷

4.4 導入はまだ初期段階だ

導入はまだ初期段階です。Ivantiが2026年2月にセキュリティ実務者約1,200人を調査した結果、87%がエージェンティックAIの統合を優先事項に挙げましたが、脆弱性対処にAIを使っている割合は42%でした。²⁸ 韓国で確認された事例も、KB金融グループのAIペネトレーションテストエージェントのように点検と検知が中心であり、²⁹ 「セキュリティのためにコーディングエージェントベースの開発体制を導入した」と明らかにした韓国企業は、今回の調査では見つかりませんでした。Forresterは、規制当局と保険会社が、AIによる発見と実際の対処の間に人による検証と承認の段階を求めるようになると予測しています。¹⁷

これらの調査は、導入が遅い原因を明らかにしてはいません。ただ、KaiのCISO調査（二次報道）では、回答者の52%が自動化された意思決定への信頼不足を最大の障壁に挙げました。³⁰ 私は、この信頼の問題こそが、ソフトウェアファクトリーの設計課題を正確に指していると考えます。自動で修正しつつ、その修正が正しいという証拠を残し、危険な変更は人が承認する構造です。次の節からその構造を扱います。

5. ソフトウェアファクトリーは何を減らすのか

ソフトウェアファクトリーとは、AIエージェントがタスクの受け付けから実装、検証、報告、改善までを繰り返し回す開発体制です。このブログでは9月の記事でこの概念を紹介し、³¹ 最近の4回の連載で公開リポジトリ12か所をリバースエンジニアリングし、実際にファクトリーが動いている8か所を確認しました。³²

連載で観察した仕組みをセキュリティの言葉に置き換えると、次のようになります。

• 受け付け： Issue、失敗したCI、ユーザーからの報告が自動的にタスクになります。セキュリティに適用すれば、脆弱性スキャナーの結果、ペネトレーションテストの報告書、セキュリティアドバイザリーが、担当者の予定を待たずにタスクになります。ただしスキャナーの結果には誤検知が混ざっているため、影響範囲と深刻度をまず分類して優先順位を決める段階が前に必要です。
• ゲートと証拠： 第3回で見たように、成熟したファクトリーは「修正前のコードでは失敗し、修正後には通るテスト」を証拠として求めます。³³ セキュリティ修正に適用すれば、認証の迂回が修正前には成功し、修正後には阻止されることをテストとして残すことになります。そのテストは、以後のすべての変更で同じ穴が再び開いていないかを確認し続けます。
• 自己改善： 第4回の「失敗をルールに」のループは、一度起きた失敗を指示文や検査の仕組みに変えます。³⁴ セキュリティに適用するなら、ソースコードにキーが入った事故が一度起きた後は、キーが含まれるコミットをゲートで阻止する検査を追加する、といった形です。しかし第4回で見たように、新しいルールが実際に効果を上げたかを確認した公開記録はまれでした。セキュリティのルールであれば、その検査が実際に阻止できるかを定期的に試す段階まであって初めて、ループが完成します。

自動修正にもリスクがあります。第3回には、メンテナーが動作を確認してマージした修正が、意図された動作を変えていたことが判明し、リリース前に差し戻された事例がありました（Astro）。³³ セキュリティ修正は業務機能を壊すおそれがあるため、修正を作ったエージェントとは別の検証段階と、問題が起きたときに差し戻す条件を、あらかじめ決めておく必要があります。

ここで重要なのは範囲です。ファクトリーが減らすのは、ソフトウェアの欠陥を発見して修正し、デプロイするまでの時間 です。フィッシングで乗っ取られたアカウント、監視要員の不足、ネットワーク設計の問題までをファクトリーが解決するわけではありません。露出したキーを破棄して新たに発行する運用作業もコード修正とは別物であり、コードを直したからといって、すでに露出したキーのリスクが消えるわけではありません。しかし第1節の原因の多く、つまりコードに秘密鍵を入れる習慣、認証検証の欠陥、修正されていない脆弱性は、コードを直さなければ再発を防げない問題であり、この範囲の中にあります。

効果も測定しなければなりません。第4回で見たOpenClawの自動実装ワーカーは、1週間で52回成功し256回失敗しており、プロジェクトは失敗率が高いと自動実装を止める仕組みを追加しました。³⁴ 自動化によって増えた検証やレビューの負担も含めて、修正にかかった時間が実際に減ったのかを測る必要があります。

6. 人がルールを決め、機械が実行する

「人の介入なしに対応する」という表現は誤解を招きやすいものです。連載で確認した事実は、むしろその逆に近いものでした。ファクトリー8か所のうち、ボットがmainブランチへのマージを大量に行っていたのはOpenClawだけで、残りでは人による最終マージが主に観察されました。³² ボットにマージを任せたOpenClawでさえ、変更の種類ごとにリスク等級を定義し、セキュリティポリシーとリリースは人が承認するようにしていました。³⁵

そこで私は、必要なものをこう定義します。人がボトルネックにならない体制 です。人は、何を自動で処理してよいかをルールとして定めます。機械はそのルールの中で、夜間も祝日も実行します。ルールの外の仕事、たとえばセキュリティポリシーの変更や元に戻しにくいデプロイは、人に引き渡します。

このとき人の承認が残るからといって、待ち時間がそのまま残るわけではありません。人が承認ボタンを押す時点で、問題の分類、修正コード、修正前の失敗と修正後の成功を示す証拠がすでに用意されていれば、人の仕事は修正作業全体から、用意された証拠を検討する判断へと縮小できます。どれだけ縮小するかは、組織ごとに測定してみる必要があります。緊急のセキュリティ修正であれば、この判断を担う当番と連絡経路をあらかじめ決めておくことも、ファクトリー設計の一部です。

この構造は、パク・ムンボム氏が強調した「現場の専門家の経験をシステムに反映しなければならない」という結論ともつながります。¹ 現場の専門家は、AIが生み出す迂回パターンや侵害の兆候に最初に気づく人たちです。その判断が報告書や議事録にしか残らなければ、次の攻撃のときにも再び人の速度で処理されます。逆にその判断がファクトリーのルールや検査の仕組みになれば、専門家が眠っている間もその判断が実行されます。ファクトリーは現場の専門家を置き換えるものではありません。専門家の判断を、休まず実行される形に変えるものです。

7. ファクトリー自体を守らなければ脅威は増える

セキュリティを理由にファクトリーを主張するなら、反対側のリスクについても語らなければなりません。書き込み権限を持つエージェントは、それ自体が攻撃対象です。攻撃者がIssueやPRの本文に指示文を隠してエージェントを操るプロンプトインジェクションや、エージェントが使うトークンの窃取が代表的です。CrowdStrikeの評価が正しければ、今回の金融業界の攻撃者も、開発者が使うのと同じコーディングエージェントを使っていました。⁹ ツールは中立であり、そのツールを取り巻く仕組みが結果を決めます。

連載で観察したプロジェクトは、このリスクに対して具体的な仕組みを設けていました。³⁵

• リスク等級をファイルで定義する。 ドキュメントの変更、一般的なコード、機密性の高いパス、セキュリティポリシー、リリースを分け、リスクの高い等級はCODEOWNERSとセキュリティガードで人の承認を強制します。（OpenClaw）
• エージェントに書き込みトークンを与えない。 分析とレビューを行うエージェントは読み取り専用で実行し、書き込みは範囲を絞った専用ステップのワークフローコードでのみ行います。レビューのルールはPRのブランチではなく対象ブランチから読み込み、PRが自分のレビュールールを変えられないようにします。（Astro）
• 人がいつでも止められるようにする。 自動マージはオプトインで始め、書き込み権限を持つ人が使える停止コマンドを用意します。（OpenClaw）

金融業界のように変更承認手続きと職務分離を厳格に求められる組織であれば、これらの仕組みはむしろ出発点になります。リスク等級を分ければ、人の承認が本当に必要な変更とそうでない変更を明示的に区別できます。人の承認は本当に必要なところに残し、それ以外の段階の待ち時間を減らすことが目標です。具体的な規定との適合性は、各組織が監督規定を基準に別途検討する必要があります。

結論

パク・ムンボム氏の観察のとおり、かつては攻撃者にも休みの日があり、防御側はその隙に分析し修正する時間を稼いでいました。私は、人の対応速度に依存する体制の限界がますます大きくなっていると考えています。韓国国内の事故でAIが使われたかどうかはまだ調査中ですが、海外ではAIエージェントが攻撃作業の大部分を実行したという報告がすでに出ており、VulnCheckの集計では、公開当日またはそれ以前に悪用される脆弱性の割合が2024年より2025年に増えています。

こうした環境では、「うちは事故がなかった」ということは安全の根拠になりません。既存のやり方がこれからも安全を保証するという根拠がないからです。私たちは適応しなければならない時代を生きています。

私は、適応の方向はこちらだと考えています。隙間を発見した瞬間から塞ぐまでの時間を、人の勤務時間から切り離さなければなりません。人がルールを決め、機械はそのルールの中で休まず実行し、失敗は再びルールになります。そして、その機械を取り巻く仕組みを人が設計し、監督します。これがソフトウェアファクトリーです。修正期限は短くなり、攻撃は休みません。私は、セキュリティがソフトウェアファクトリーの導入を加速する主要な理由になると考えています。