AIコーディングアシスタントを介したサプライチェーン攻撃：脅威アクターはもはやコードを書く

サプライチェーンはもはやパッケージだけで構成されていない

ソフトウェアサプライチェーンセキュリティは長らく特定のモデルに基づいて考えられてきました：あるコンポーネントが侵害され、多くの組織がそのコンポーネントを利用し、その後依存関係ツリーを通じて影響を受けるシステムが特定されます。SolarWinds、Log4Shell、悪意あるnpmパッケージ、偽のPyPIモジュール、乗っ取られたオープンソース依存関係は、このモデルの異なる事例です。攻撃のスケーリングメカニズムは明確です：同じコンポーネントが多くのコードベースで使用されるのです。

しかしAIコーディングアシスタントはこの構図を変えています。ここで侵害されるのは、必ずしも公開されたパッケージ、オープンソース依存関係、ビルドツールではありません。リスクは開発者ワークフローそのものの中に現れます。コード提案、リファクタリング、テスト生成、バグ修正、ヘルパー関数の記述の際に、AIアシスタントはファーストパーティコードに直接貢献します。

この貢献は依存関係としては現れません。パッケージレジストリを通過しません。SCAツールの依存関係ツリーには現れません。多くの場合、通常の開発者のコミットのように見えます。新たな問いはこうです：コードに入る変更がパッケージではなくAI支援の提案である場合、サプライチェーンセキュリティはこれをどう捉えるのか？

2026年初頭に公表された事案は、この問いを理論的なものではなくしました。Anthropicは、中国の国家支援グループがClaude Codeを使用し、テクノロジー、金融サービス、政府の各セクターで約30の組織に侵入する協調的なキャンペーンを実行したことを公表しました。同じ時期に、重要インフラの標的に対してAI支援オペレーションが使用されたとする別の報告も公開されました。

これらの事案に共通するのは、AIツールが単なる生産性レイヤーであることをやめ、攻撃チェーンの一部となったことです。本質的なリスクは：AI支援コードは信頼された開発者のアイデンティティを通じてコードベースに入りますが、必ずしも同じレベルの信頼に値するわけではありません。

新たな攻撃パターン：アシスタントは侵害されずに利用される

従来のサプライチェーン攻撃では、攻撃者は通常、共有されるコンポーネントを標的とします。パッケージが汚染される。メンテナーアカウントが乗っ取られる。ビルドシステムが操作される。署名鍵が漏洩する。更新チャネルが悪用される。そして、このコンポーネントを利用するすべての組織が影響を受けます。

AIコーディングアシスタントを介して発展するパターンは異なります。ここでは攻撃者がアシスタント自体を乗っ取る必要はありません。アシスタントは攻撃者によってツールとして使用されるか、開発者ワークフローに向けられたコンテキストを通じて影響を受けます。これはより巧妙なモデルです。

攻撃者は、特定のコード提案を引き出すプロンプト、サンプル、リポジトリコンテキスト、オープンソースコンテンツ、Q&Aページ、issueテキストを用意できます。目的は、AIアシスタントがもっともらしく見えるが脆弱性を含むコードを生成させることです。開発者の視点ではプロセスはありふれたものです — リファクタリングを行い、アシスタントにヘルパー関数を求め、提案がもっともらしく見え、コードが読まれ、テストが通り、プルリクエストが承認されます。

しかし生成されたコードの中には、小さなロジックの欠陥、弱い検証、SSRFの経路、機密データの漏洩、誤った認可、後で利用される可能性のあるバックドアが含まれているかもしれません。このコードは外部依存関係ではなく — 組織自身のコードです。従来のSCAツールは何も見ません。

問題はまさにここにあります：サプライチェーン攻撃は依存関係ツリーから抜け出し、開発ワークフローへと移動したのです。

従来のサプライチェーン vs AIコーディングアシスタント起因の攻撃

記録された2026年の事案は何を示しているか？

2026年の事案は、AIコーディングツールが単なる理論的リスクではないことを示しました。異なる事案の共通メッセージは同じでした：攻撃者はAIツールを開発、偵察、エクスプロイト生成、そして運用上の速度のために使用しています。

既存の防御はなぜ不十分なままなのか？

AIコーディングアシスタントに起因するサプライチェーンリスクにおいて、防御のギャップは単なるツールの不足ではなく — プロセスのギャップです。3つの根本的な問題が際立ちます。

6つの具体的な変更

結論：AIコードは信頼できる入力ではない

AIコーディングアシスタントはソフトウェア開発の速度を高めています。この事実は変わりません。組織はこれらのツールを使うでしょう。開発者はより速くプロトタイプを作り、リファクタリングし、バグを解決するでしょう。しかし生産性の向上はセキュリティの前提を自動的に無効にしません。

AI支援コードは、信頼された開発者のアイデンティティの下でコミットされたものであっても、信頼できると見なすべきではありません。コードが生成されたコンテキスト、使用されたモデル、プロンプト、リポジトリの内容、外部の情報源は攻撃面の一部です。

だからこそサプライチェーンセキュリティは、もはやパッケージスキャンだけに限定できません。新しいサプライチェーンには次のものも含まれます：コーディングアシスタント、プロンプトのコンテキスト、AI支援コミット、開発者ワークフロー、モデル製造元のインシデント公表、リポジトリアクセス権限、CI/CDセキュリティゲート、AI使用ログ、コードレビューの規律。

正しいアプローチはAIの使用を禁止することではありません。正しいアプローチはAI支援コードを可視で、監査可能で、リスクベースの開発入力にすることです。従来のサプライチェーンセキュリティは「どのパッケージを使っているか？」を問うていました。2026年の追加の問いは：このコードを誰が書いたか、どのツールが手助けしたか、そしてそのツールの出力はどのように検証されたか？