AIでアプリを内製するなら、最初に「門番」を。狙われるのはシステムではなく開発者のPC

2026年10月7日 08:17

AIでアプリを作るのは、本当に速くなりました。そのぶん、見落としやすくなったものがあります。開発しているパソコンそのものが狙われる、という危険です。

2026年5月、国内のある大手企業が「GitHubの認証情報が漏れ、第三者にリポジトリをコピーされた」と公表しました。侵入の経路は公式発表では確定していません。

ただ近年、「開発者の環境を起点に認証情報が抜かれ、本丸のリポジトリへ侵入される」という攻撃(npmやPyPIなどを使ったサプライチェーン攻撃)が世界中で多発しています。僕自身、このニュースをきっかけに自分の開発の流れを見直したので、その整理を残しておきます。

※ここで紹介する攻撃のシナリオは、この事案の原因として確定したものではありません。「今の開発環境で現実に起きている、代表的な脅威」として整理しています。

AIでどんどんコードを生成する今の開発では、決して他人事ではありません。自社でアプリを内製する会社も同じです。

ざっくり用語解説

GitHub: ソースコードを預けて共有するサービス。今の開発の「本丸」のような存在
npm: JavaScript/TypeScript系の、世界最大級の部品(パッケージ)配布サービス。Node.js系の開発ではほぼ必須
NuGet: .NET/C#系で使われる、Microsoft公式の部品管理サービス
PyPI: Python系の部品配布サービス
パッケージ: 他人が作った便利な部品(ライブラリ)。今の開発では大量に組み合わせて使う
サプライチェーン攻撃: 信頼されている部品や配布経路にマルウェアを混ぜ、使った人をまとめて感染させる攻撃

「開発者のパソコン経由で本丸が落ちる」という攻撃

システム本体をガチガチに守っていても、開発者のパソコンが狙われる。これが今の怖いところです。流れはこうです。

罠を置く: 攻撃者がnpmに、有名なパッケージに似せた偽物や、乗っ取った正規パッケージにマルウェアを混ぜたものを公開する
感染: 開発者がうっかり npm install すると、インストール時に自動で動くスクリプト(postinstallなど)を通じて、裏でマルウェアが起動する
鍵を盗む: 開発者のパソコンや自動ビルドの環境に保存されていた認証情報(GitHubのアクセストークン、クラウドの認証情報など)が抜き取られる
本丸へ侵入: 攻撃者は盗んだ鍵を使い、正規のルートからGitHubの非公開リポジトリなどに入り、ソースコードや内部情報を持ち出す

2025年には、感染したパッケージが別の作者の認証情報を次々に盗み、連鎖的に広がる「ワーム型」の攻撃も見つかっています(いわゆるShai-Hulud系)。「自分は怪しいパッケージは入れない」と思っていても、信頼していたパッケージの作者が感染すれば、自分も巻き込まれる構造です。

なぜnpmで起きやすいのか

「.NETのNuGetでは、同じような事件をあまり聞かない。何が違うの？」と思うかもしれません。

差は仕組みというより、規模・更新の頻度・依存関係の深さにあります。npmはパッケージの数も、ダウンロード数も、部品が部品に頼る依存の深さも、ほかの言語の配布サービスを大きく引き離しています。攻撃者から見ると、狙える範囲の広さと効果の大きさが桁違いなのです。

「数行の処理でも外部パッケージを使う」という文化が根づいていることも、依存関係を膨らませ、攻撃される面を広げています。

NuGetにも理論上は同じリスクがありますし、実際に偽物のパッケージの事案も過去にありました。ただ、規模と頻度の差で、今はnpmが攻撃者の主戦場になっています。

ちなみに僕は、業務の中核になるロジックや重要なシステムは、今も .NET 中心でAI駆動開発をしています。業務システムでは「速く作れること」以上に「長く安定して動くこと」が大事なので、コアの部分は .NET + Azure + SQL Server 側に寄せる構成をとることが多いです。

AI駆動開発の、思わぬ落とし穴

Claude CodeやCursorなどを使ったAI駆動開発では、AIが提案するパッケージを反射的に npm install してしまう機会が、人が書く開発よりずっと増えます。

AIは「とりあえず動くこと」を優先します。そのパッケージが今まさに乗っ取られていないか、名前の打ち間違いを狙った偽物ではないか、までをその場で判断できるとは限りません。

これは、AIツールそのものが危ないという話ではありません。問題は、GitHubやクラウドへの広い権限を持つ開発者の環境自体が、攻撃する価値の高いものになっていることです。AI駆動開発のスピードが生む「依存関係の確認不足」を、攻撃者は確実に狙ってきます。

今日からできる対策

完全に防げる方法はありません。でも、何重にも守ればリスクは大きく下げられます。

自動実行を止める: npm install --ignore-scripts を癖にする。ただし効くのはインストール時に動くタイプだけ。アプリの中で読み込まれて動くタイプには効かないので、万能ではありません
鍵の寿命を短くする: GitHubのアクセストークンは無期限にせず、期限つき・権限は最小限に(できればFine-grained PAT)
秘密の情報をコードに書かない: .env などの環境変数で管理し、.gitignore で確実にGitHubへ上げないようにする。GitHubのPush ProtectionやSecret Scanningも併用する
依存関係の健康診断を続ける: Snyk、Socket.dev、Dependabot、npm audit などを習慣にする。Socket.devはインストール前に怪しい動きを見つけるタイプで、AI駆動開発と相性がいい
lockfileを信じる: package-lock.json をコミットし、自動ビルドでは npm ci を使う。AIに勧められるまま、安易に依存を更新しない
バージョンを固定する: @latest 任せにしない。特にメジャーバージョンの自動更新は慎重に

Claude Codeに「門番」を立たせる

Claude Codeで開発しているなら、プロジェクト直下の CLAUDE.md に次のようなルールを置いておくと、AI自身にセキュリティの決まりを守らせることができます。

# Role & Context
あなたはセキュリティと堅牢性を最重視する、シニアレベルのAIコーディングアシスタントです。
昨今のnpmサプライチェーン攻撃の脅威を踏まえ、開発のスピードを維持しつつ、
マルウェア感染リスクを極限まで排除してコード生成を行ってください。

# Rules for Dependency Management
1. 【脱・過度な依存】安易に外部パッケージを追加せず、まずは標準ライブラリでの実装を検討すること。
2. 【厳格な選定】パッケージを提案する際は、広く認知されメンテナンスが継続しているものに厳選し、
   タイポスクワッティングがないか自ら二重チェックすること。
3. 【安全なインストール】npm install 提案時は原則 --ignore-scripts を付与すること。
4. 【バージョン固定】新規依存追加時は version pinning を推奨し、
   メジャーバージョン自動更新を避けること。

# Rules for Security & Secrets
1. 【ハードコード禁止】APIキーやGitHubのPAT等をコード内に直接記述しないこと。
2. 【環境変数の徹底】認証情報は必ず .env 等を利用し、.gitignore への追加を必ず確認すること。

# Continuous Security
既存の依存関係を操作する際は、npm audit や Snyk・Socket.dev・Dependabot 等の
スキャンツールの利用をユーザーにリマインドすること。

僕の会社のサイトも、同じ方針で作っています(パッケージの導入は --ignore-scripts が前提です)。

おわりに

画面や手軽な連携の部分はAIで一気に組み上げる。絶対に守りたい中核のロジックは、堅牢な仕組みで作る。そんな組み合わせと、AIによる依存関係の見張りを続けることが、これからの開発の現実的な答えになりそうです。

スピードをとるか、堅牢さをとるか、ではありません。スピードを保ったまま、堅牢さをAIに守らせる。

アプリを内製するなら、1本目を作る前にこの「門番」を置いておく。それだけで、防げる事故がかなりあります。

作るところから、安全に動かし続けるところまで、御社の実務で一緒にやるのがブートキャンプです。

現場アプリ内製化ブートキャンプについて