2026年1月、日本の製造業を支える計測機器メーカー「菅原研究所」が、ランサムウェアグループ「Quilin」による標的型攻撃の被害を受けた。この事件は、単なる一企業の被害という枠を超えて、生成AIが武器として使われる時代における開発現場の脆弱性を浮き彫りにした。
被害内容を見ると、約74GBから200GB以上のデータが窃取され、その中にはソースコード、APIトークン、Bitbucketリポジトリといった開発資産が含まれていた。つまり、攻撃者は単にデータを暗号化して身代金を要求するだけでなく、開発者が日々扱っている技術情報そのものを「人質」として利用する戦術へと進化しているのだ。
本記事では、この事件を起点に、生成AI時代におけるサイバー攻撃の実態と、開発エンジニアが今すぐ実践できる対策について解説する。技術的な詳細を噛み砕きながら、なぜ従来のセキュリティ対策では不十分なのか、そして何をすべきなのかを明確にする。
なぜ開発現場が狙われるのか：サプライチェーン攻撃の実態
菅原研究所のような企業が標的とされる理由は、その戦略的価値にある。同社は自動車産業や重工業の研究開発・品質管理において不可欠な計測機器を製造しており、その操業停止はサプライチェーン全体に波及効果をもたらす。攻撃者は、大手企業に直接攻撃を仕掛けるよりも、その基盤を支える専門企業を狙うことで、より効率的に圧力をかけることができる。
しかし、より深刻なのは、開発資産そのものが攻撃の材料として悪用される点だ。窃取されたソースコードは、AIツールに読み込ませることで、人間では気づかないような脆弱性を自動的に発見される。さらに、APIトークンが流出すれば、攻撃者は正規のシステム管理者になりすまし、クラウド上のデータを削除したり、提携企業のシステムへ侵入するための踏み台として悪用したりする可能性がある。
これは「サプライチェーン攻撃」と呼ばれる手法で、一つの企業の脆弱性が、その企業だけでなく、取引先や顧客企業全体のセキュリティを脅かす構造的な問題を生み出す。開発現場で扱う技術情報は、もはや自社の資産であるだけでなく、エコシステム全体のセキュリティを左右する重要な要素となっているのだ。
生成AIがもたらす攻撃の高度化：人間のスピードを超える脅威
Quilinのような攻撃グループが、なぜこれほどまでに脅威となっているのか。その背景には、生成AIの実戦投入がある。従来、ハッカーが人間の目で探していたシステムの穴を、AIエージェントが自動かつ高速に見つけ出すようになっている。盗んだソースコードをAIに読み込ませれば、人間では気づかないような小さなミスも一瞬で発見されてしまう。
具体的には、Quilinはマルウェアの開発プロセス自体にAIを活用しており、検知回避のためのコード難読化や、新たな攻撃用チャットボットの生成を自動化していると報告されている。また、音声クローン技術を用いた「ビッシング（音声フィッシング）」詐欺も増加しており、経営幹部の声を模倣して送金を指示するといった手法との複合攻撃も懸念されている。
技術的な進化も著しい。Quilinは、初期のGo言語からRust言語へと移行することで、検知回避能力を向上させた。Rustは比較的新しいプログラミング言語であり、従来のC++やC#で作成されたマルウェアを対象としたシグネチャベースの検知エンジンでは、解析や検知が困難な場合がある。さらに、Rustの高い移植性を悪用し、Windows環境だけでなく、LinuxサーバーやVMware ESXiといった仮想化基盤を直接攻撃できるバリアントを開発している。
特に注目すべきは「断続的暗号化（Intermittent Encryption）」と呼ばれる技術だ。従来のランサムウェアは、ファイル全体を先頭から末尾まで暗号化するため、処理に時間がかかり、CPU負荷が高いため検知されやすい。しかし、断続的暗号化では、ファイルを一定間隔（例：16バイト暗号化し、次の16バイトをスキップ）で部分的に暗号化するため、処理速度が極めて高速で、ファイルのI/Oパターンが通常操作に近く、EDR（Endpoint Detection and Response）による振る舞い検知を回避しやすい。
つまり、人間が手動で守るスピードを、AIが自動で攻めるスピードが上回ってしまっているのが、生成AI時代の脆弱性の正体なのだ。
開発現場で実践すべき対策：技術的防御と運用の両輪
このような高度化した脅威に対抗するためには、従来の境界防御だけでは不十分だ。開発エンジニアが今すぐ実践できる対策を、技術的防御と運用の両面から解説する。
APIトークンとシークレットの管理：デジタルな合鍵を守る
APIトークンの流出は、セキュリティ上、最も危険な状態の一つだ。APIトークンは、クラウドサービスや連携システムを利用するための「デジタルな合鍵」であり、これが盗まれると、攻撃者は正規のシステム管理者になりすますことができる。
最も基本的な対策は、コードに鍵を書かないことだ。ソースコードの中にAPIトークンやパスワードを直接書き込む（ハードコーディング）のは厳禁である。環境変数や専用の管理ツール（AWS Secrets Manager、HashiCorp Vaultなど）を使用し、本番環境と開発環境で異なる認証情報を管理する。
さらに、コードを保存する前に、トークンが含まれていないか自動でチェックするツール（Secret Scanning）を導入する。GitHubやGitLabには、コミット時にシークレットを検出する機能が組み込まれているが、これらを有効化し、CI/CDパイプラインにも組み込むことで、人的ミスを防ぐことができる。
万が一漏れた場合に備え、APIトークンを定期的に変更（ローテーション）し、古い鍵を使えなくする運用を自動化する。特に、Gitリポジトリの履歴に誤ってコミットしてしまった場合、履歴を書き換えるだけでは不十分なため、トークンを即座に無効化し、新しいトークンを発行するプロセスを確立しておく必要がある。
多要素認証とゼロトラストの原則：侵入を前提とした設計
「社内ネットワークだから安全」という考えを捨て、ゼロトラストの原則を適用する。これは、すべてのアクセスを信頼せず、常に検証するという考え方だ。
多要素認証（MFA）の徹底は、最も効果的な対策の一つである。パスワードやトークンが盗まれても、スマートフォンの承認などがなければログインできないようにすることで、フィッシング攻撃による認証情報の窃取を防ぐことができる。特に、リモートアクセスや特権IDの利用時には、MFAを強制する。
権限の最小化も重要だ。開発者やシステムに対して、業務に必要な最低限の権限だけを与えることで、万が一侵入されても被害範囲を限定できる。例えば、本番環境への直接アクセスを制限し、承認プロセスを経た上で、一時的な権限を付与する運用を検討する。
ネットワークセグメンテーション：被害の拡大を防ぐ
OA系ネットワーク（事務用）とOT系ネットワーク（工場・制御用）を論理的・物理的に分離することで、事務用PCの感染が直ちに生産ラインの停止につながらないような設計が不可欠だ。開発環境と本番環境も同様に分離し、開発環境で発生したインシデントが本番環境に波及しないようにする。
特に、VMware ESXiのような仮想化基盤は、Quilinのような攻撃グループが優先的に標的とするため、これらのシステムへのアクセスを厳格に制限し、定期的なセキュリティパッチの適用を徹底する。
イミュータブルバックアップとインシデントレスポンス：回復力の強化
Quilinはバックアップデータを最優先で破壊する。そのため、ネットワークから論理的に切り離されたオフラインバックアップ、あるいは書き込み一度・読み取り多数（WORM）方式のクラウドストレージにバックアップを保存することで、ランサムウェアによる暗号化の影響を受けずにデータを復元できる。
インシデントレスポンス計画の策定と演習も重要だ。攻撃を受けた際の初動対応（ネットワーク切断、証拠保全、法執行機関への連絡）をマニュアル化し、定期的に演習を行う。特に、「身代金を支払うか否か」の意思決定プロセスを事前に定めておくことが、有事の混乱を防ぐ。
AIを活用した検知の自動化：攻撃の自動化に対抗する
攻撃が自動化されている以上、防御も自動化が必要だ。従来のウイルス対策ソフト（既知の悪いファイルを検知）だけでなく、AIを活用して「普段と違う動き（異常なデータ転送やアクセス権限の変更）」をリアルタイムで検知・遮断するEDR/NDRなどのシステムを導入する。
特に、断続的暗号化を検知するためには、EDRの設定を最適化する必要がある。大量のファイル変更や、ボリュームシャドウコピー（VSS）の削除コマンド（vssadmin delete shadowsなど）の実行を即座にブロックする設定を有効にする。
開発者としての心構え：セキュリティは開発プロセスの一部
菅原研究所の事例は、技術情報そのものが人質になる時代の象徴だ。「データを暗号化して身代金を要求する」だけでなく、「盗んだ技術でさらなる攻撃を仕掛ける」という段階へ脅威がシフトしていることを認識し、対策を強化する必要がある。
しかし、セキュリティ対策は、開発の速度を落とすものではない。むしろ、適切なツールとプロセスを導入することで、開発効率を向上させながら、セキュリティリスクを低減できる。Secret ScanningをCI/CDパイプラインに組み込むことで、人的ミスを防ぎ、コードレビューの負荷を軽減できる。環境変数やSecrets Managerを活用することで、設定の管理が容易になり、環境間の差異によるバグを防ぐことができる。
重要なのは、セキュリティを「後から追加するもの」ではなく、「開発プロセスの一部」として捉えることだ。コードを書く際に、認証情報の扱いを意識し、権限の最小化を考慮し、異常な動作を検知できるような設計を心がける。これにより、高度化する脅威に対抗しながら、開発の速度と品質を両立できる。
生成AI時代のセキュリティは、技術的な対策だけでなく、開発者一人ひとりの意識と行動によって支えられている。菅原研究所の事例を対岸の火事とせず、自社の開発プロセスを見直し、実践的な対策を講じることが、今まさに求められているのだ。