開発端末が、会社の境界線になっている
AIコーディングエージェントや開発支援ツールを使う会社が増えるほど、守るべき場所はサーバーだけではなくなります。実際にコードを書き、APIキーを置き、GitHubやクラウドに接続する「開発端末」そのものが、会社の重要な境界線になります。
2026年5月20日、GitHubは同社所有の内部リポジトリへの不正アクセスについて公表しました。GitHubの説明では、5月18日に第三者が公開した毒入りのVS Code拡張機能により従業員端末が侵害され、GitHub内部リポジトリの流出が関係したとされています。GitHubは、顧客自身のenterprise、organization、repositoryなど、内部リポジトリ外に保存された顧客情報への影響を示す証拠はないとも説明しています。
ここで重要なのは、「GitHubの特殊な事件」として片づけないことです。構造としては、どの会社にも起こり得ます。開発端末には、ソースコード、.env、GitHub token、npm token、SSH鍵、クラウド認証情報、パスワード管理ツールへの接続など、業務の入口が集まります。そこに入る拡張機能は、ただの装飾ではありません。
拡張機能は、エディタの外まで届く
Visual Studio Codeの公式ドキュメントでは、拡張機能はVS Code自身と同じ権限で動き、ファイルの読み書き、ネットワーク要求、外部プロセス実行、ワークスペース設定の変更などが可能だと説明されています。これは、便利さの源泉である一方で、侵害時の影響が大きいという意味でもあります。
今回関連が示されたNx Consoleのアドバイザリでは、悪性版 18.95.0 が2026年5月18日にVisual Studio Marketplaceで約18分、OpenVSXで約36分入手可能だったと記録されています。修正版は 18.100.0 です。アドバイザリは、影響を受けた可能性がある場合、悪性プロセスや永続化ファイルの確認、端末から到達可能なトークン・シークレット・SSH鍵のローテーション、アクセスログの監査を求めています。
公開時間が短かったから安全、とは言えません。拡張機能は自動更新されることがあります。VS Codeの公式ドキュメントでも、拡張機能は更新を確認して自動的にインストールされると説明されており、必要に応じて extensions.autoUpdate や個別拡張の自動更新設定を変更できます。便利な自動更新は、信頼できる更新を早く届ける仕組みであると同時に、侵害された更新も早く届き得る仕組みです。
中小企業が最初に見るべき4つのチェック
この種のリスクに対して、最初から大企業並みの監視基盤を作る必要はありません。まずは、開発端末とAI開発支援ツールの使い方を、次の4点で棚卸しするだけでも効果があります。
1つ目は、入っている拡張機能の棚卸しです。昔入れたまま使っていない拡張、用途が重複している拡張、発行元やリポジトリが不明瞭な拡張は、削除候補にします。AI支援ツールも同じです。便利そうだから入れる、ではなく、業務に必要なものだけを残します。
2つ目は、自動更新の運用です。個人開発なら自動更新のままでもよい場合があります。一方で、会社の業務端末、顧客データを扱う端末、APIキーを置く端末では、主要な拡張機能だけでも更新タイミングを確認する運用に変える価値があります。すべてを止めるのではなく、重要端末だけ慎重に扱うのが現実的です。
3つ目は、許可リストです。VS Codeは企業向けに extensions.allowed を提供しており、発行元、特定拡張、バージョン、プラットフォーム単位でインストール可能な拡張を制御できます。小さな会社でも、「業務端末で使ってよい拡張機能リスト」を作るだけで、判断が属人化しにくくなります。
4つ目は、端末内シークレットの整理です。.env、APIキー、クラウドCLIの認証情報、GitHub CLI、npm token、SSH鍵、パスワード管理ツールのCLIセッションなどを、どの端末で、どの範囲まで読める状態にしているか確認します。AIエージェントや拡張機能を導入する前に、読ませてよい情報と読ませてはいけない情報を分ける必要があります。
AI開発支援ツールの前に、作業環境を設計する
AIコーディングエージェントは、コードを読み、ファイルを編集し、コマンドを実行できるほど価値が出ます。つまり、価値が出るほど権限も大きくなります。ここを曖昧にしたまま「AIで開発を速くする」だけを進めると、成果物の品質以前に、作業環境そのものが危うくなります。
実務では、次のようなルールを先に決めておくと安定します。
- AIや拡張機能が読んでよいフォルダを分ける
- 顧客情報、契約情報、認証情報を作業フォルダに置かない
.envや鍵ファイルをリポジトリに含めない- 新しい拡張機能を入れる前に、発行元、更新頻度、リポジトリ、権限を確認する
- 主要な開発端末で、拡張機能一覧を定期的に確認する
- 侵害が疑われる場合は、拡張削除だけで済ませず、到達可能な認証情報のローテーションを検討する
これは、エンジニアだけの話ではありません。AI支援ツールを使って業務アプリ、社内FAQ、データ分析、Webサイト、営業資料を作る会社では、開発端末が業務情報の通り道になります。中小企業ほど、担当者の1台に多くの権限が集まりがちです。だからこそ、最初の設計が効きます。
Optiensとしての見方
Optiensでは、AI導入を「ツールを入れること」ではなく、「業務に合わせて、使ってよい情報・権限・確認手順を決めること」として扱います。AIエージェントや開発支援ツールは強力ですが、会社の中に入れる以上、便利さと同じくらい、どこまで読めるか、どこまで実行できるか、失敗時にどう戻すかを決めておく必要があります。
AI活用をどこから始めるべきか迷っている場合は、まず AI活用診断簡易版（無料） で、既存業務のどこがAIパッケージ化しやすいかをご確認ください。より具体的に整理したい場合は、詳細版AI活用診断（¥5,500税込・MTGなし） で、AIパッケージ適合性、構成案、優先順位、費用前提を整理してお届けします。
なお、ソースコードや実環境を対象にした検査、修正作業、テスト実施は、導入支援またはスポット相談として個別にお見積もりします。