プロンプト1行でPC乗っ取り｜Microsoft緊急警告

監修者伊東雄歩

株式会社ウォーカー CEO。東北大学卒。MENSA会員、JDLA認定講師、健全AI教育協会理事。生成AI×教育・学習科学を専門とし、2億円超のシステム開発プロジェクトを統括。

2026年5月7日公開：MicrosoftがSemantic Kernel（AIエージェントSDK）に深刻なRCE脆弱性2件を公表
CVE-2026-26030（CVSS 9.8）：Python版のフィルター機能でeval()が悪用され、プロンプト1行でcalc.exeが起動
CVE-2026-25592：.NET版のSessionsPythonPluginでサンドボックス外に任意ファイルが書き込み可能
業界全体への警告：LangChainにも類似脆弱性（CVE-2025-68664）。OWASP 2026はプロンプトインジェクションを最大脅威に指定
日本企業の対策：即パッチ適用に加え、権限最小化・サンドボックス分離・ヒューマンインザループの3原則が必須

「AIに自然言語で話しかけただけで、PCの中身を乗っ取られる」——SF映画みたいな話に聞こえますが、現実です。2026年5月7日、Microsoftが自社のAIエージェントSDKに深刻な穴があったと自ら公表しました。AIエージェントが急速に企業に広がるなか、見過ごせない警鐘です。

Microsoftが公表した2件のRCE脆弱性とは

2026年5月7日、Microsoft Security Blogの警告

Microsoftが2026年5月7日に公開したブログのタイトルは衝撃的でした。

「When prompts become shells（プロンプトがシェルになるとき）」。

シェルとは、コンピュータに直接命令を打ち込むための窓口のこと。つまり、AIに普通の言葉で話しかけているはずが、PC内部を操る命令を実行できてしまう——そんな状況をMicrosoftが自社製品で見つけて公表したのです。

対象になったのはMicrosoft Semantic Kernel。AIエージェントを作るためのSDK（開発キット）で、GitHubで27,865スターを獲得する人気のオープンソース製品です。

Semantic Kernelとは｜Microsoft純正のAIエージェント基盤

Semantic Kernelに馴染みがない方のため、簡単に説明します。

これはAIエージェント（自分で考えて作業するAI）を作るための「土台」です。OpenAIのGPT-4、Azure OpenAI、Hugging Faceなど色々なAIモデルとつなぎ、C#・Python・Javaで業務システムに組み込めます。

金融・医療・製造業など、高いセキュリティが求められる企業でも採用例が増えていました。日本でもAzure OpenAIと組み合わせる形で広く使われています。

つまり、「企業の本番システムに堂々と入っている」AIエージェント基盤に重大な穴があったわけです。インパクトの大きさが想像できると思います。

公表された2件のCVE

Microsoftが公表した脆弱性は2件です。

CVE-2026-26030：Python版Semantic Kernelのフィルター機能の問題。CVSS 9.8（最高レベルに近い深刻度）
CVE-2026-25592：.NET版Semantic KernelのSessionsPythonPluginの問題。任意ファイル書き込みが可能

どちらもRCE（リモートコード実行）、つまり攻撃者が遠隔から好きなプログラムを動かせる種類の脆弱性です。

プロンプト1行でcalc.exeが起動した攻撃手法

CVE-2026-26030｜eval()がそのまま悪用された

もっとも深刻なのはPython版の脆弱性（CVE-2026-26030）です。

Semantic Kernelには「In-Memory Vector Store」という、AIの記憶を保持する仕組みがあります。そこに付属するフィルター機能で問題が起きました。

ユーザーが入力した文字列（たとえば検索したい都市の名前など）が、Pythonの`eval()`関数にそのまま渡されていたのです。

`eval()`は「文字列をプログラムとして実行する」関数。普段使う分には便利ですが、ユーザー入力をそのまま渡すと「入力された文字列が命令として動いてしまう」という、教科書に載るレベルの危険な使い方です。

Microsoft自身もブログで「単一のプロンプトでAIエージェントが動くデバイス上の`calc.exe`を起動できた」と書いています。calc.exeはWindowsの電卓アプリ。「電卓くらい」と思うかもしれませんが、これは「同じ手口でランサムウェアでもデータ盗難でも何でも動かせる」ことを示すデモンストレーションです。

ブロックリストを回避するクラス階層トラバース

Microsoftは「危険な命令はブロックする仕組み」を一応用意していました。しかしそれが回避されました。

使われたのは「クラス階層トラバース」と呼ばれるテクニックです。Pythonの`tuple().__class__.__bases__[0].__subclasses__()`という長ったらしい呪文を使うと、Importを直接呼ばずに`os.system`（OS命令実行）にたどり着けます。

ブロックリストは「`import`」「`os.system`」といった単語そのものは止めますが、こうした遠回りな呼び出しは見逃してしまったのです。

つまり、「ブラックリスト方式は突破される」という古典的なセキュリティの教訓が、AIエージェントの世界でもそのまま当てはまったわけです。

CVE-2026-25592｜サンドボックスからの脱出

もう一つの.NET版の脆弱性（CVE-2026-25592）は、別のメカニズムで成り立っています。

Semantic KernelにはSessionsPythonPluginという、Azure Container Apps上の隔離環境（サンドボックス）でPythonコードを動かす機能があります。

その中の`DownloadFileAsync`というファイル転送用ヘルパーが、誤ってAIモデルから呼び出せる関数として公開されていました。

パス検証も不十分だったので、攻撃者は悪意あるプロンプトを通じてAIエージェントを操り、Windowsのスタートアップフォルダに任意のファイルを書き込むことができたのです。スタートアップフォルダに置かれたファイルはPC起動時に自動実行されます。つまり、再起動のたびに攻撃が動き続ける状態が作れてしまいます。

パッチ適用が最優先｜対応バージョン

Microsoftはすでに修正版を公開しています。

Python版：semantic-kernel 1.39.4以上にアップグレード
.NET版：Semantic Kernel 1.71.0以上にアップグレード

Semantic Kernelを使っている企業・開発者は、今すぐバージョン確認してください。「Search Plugin」と「In-Memory Vector Store」を組み合わせて使っているケースは特に危険です。

なぜ今これが大問題なのか｜業界全体への警告

AIエージェントは「ツールにつながった瞬間」に攻撃対象になる

Microsoftのブログには、業界全体に向けた重要な一文があります。

「AIモデルがツールにつながった瞬間、プロンプトインジェクションは『コンテンツの安全性問題』から『コード実行の入り口』に変わる」というメッセージです。

これまでプロンプトインジェクションといえば、「AIに変な発言をさせる」「不適切な回答を引き出す」程度の問題と考える企業も多くいました。

しかし、AIエージェントは違います。データベースを操作したり、ファイルを書き込んだり、外部APIを叩いたり——実際の業務を「実行」する力を持ちます。だからこそ、プロンプトインジェクションが即RCEに直結する世界に変わったのです。

LangChainでも同じことが起きていた

これはSemantic Kernelだけの問題ではありません。

2025年12月、競合のAIエージェントフレームワーク「LangChain」でも、ほぼ同じ性質の重大脆弱性が見つかっています。コード名は「LangGrinch」（CVE-2025-68664、CVSS 9.3）。

こちらはシリアライズ／デシリアライズの仕組みを悪用するもので、プロンプトインジェクションを通じてAIエージェントに細工された構造化データを出力させ、秘密情報の窃取やRCEにつなげるという内容です。

つまり、主要なAIエージェントフレームワークの設計に共通する弱点が、立て続けに暴露されている状況といえます。

OWASP 2026｜プロンプトインジェクションが最大脅威に

セキュリティ業界の権威OWASPも、2026年版のAIエージェントセキュリティガイドラインでプロンプトインジェクションを最大脅威に指定しました。

調査によれば、本番運用中のAIエージェントの73%がプロンプトインジェクション攻撃を受けているとされます。さらに、攻撃者が初期侵入してから他システムへ横展開するまでわずか22秒という研究結果まで出ています。

従来のセキュリティ対策（ファイアウォール・ウイルス対策ソフトなど）では、この速度に追いつけません。AIエージェント時代には「設計段階からの防御」が必須になっています。

主要AIエージェントフレームワーク｜セキュリティ視点での比較

主要4フレームワークの特徴

企業がAIエージェントを導入する際、フレームワーク選択は重要です。セキュリティ視点での主要4製品を整理します。

Semantic Kernel（Microsoft）：Azure OpenAIとの統合に強み。今回のRCE脆弱性は修正済み。エンタープライズ向けサポートが充実
LangChain：もっとも普及。柔軟性が高い反面、2025年末にLangGrinch脆弱性。サードパーティ統合の多さがリスク
LlamaIndex：RAG（検索拡張生成）に特化。例外処理不足によるサービス停止系の脆弱性が指摘されたことあり
AutoGen / CrewAI：マルチエージェント連携が強み。AutoGenはSemantic Kernelに統合され、Microsoft Agent Framework 1.0として2026年4月3日にGA

どのフレームワークも「セキュリティはフレームワークだけでは解決しない」という点で共通しています。導入企業側のガードレール構築が前提です。

Microsoft Agent Framework 1.0との関係

Microsoftは2026年4月3日、Semantic KernelとAutoGenを統合した新製品「Microsoft Agent Framework 1.0」を一般提供開始しました。

今回のRCE脆弱性は旧Semantic Kernel側で発見されたもので、新フレームワークでも基盤コードを引き継いでいる部分があります。

新フレームワークへ移行する企業も、「移行先で同じ脆弱な依存関係を使っていないか」を確認することが大切です。

日本企業の対策｜今すぐ確認すべき5つのこと

日本企業のAIエージェント採用は加速中

日本のAIエージェント活用は、まさに本番フェーズに入りつつあります。

多くの日本企業は2024〜2025年に「生成AIの実験」を行い、2026年から「本番運用・ガバナンス・スケール」のフェーズに踏み込む段階。Semantic KernelやAzure OpenAIをベースにAIエージェントを社内システムに組み込んでいる企業も少なくありません。

今回のような脆弱性公表は、こうした「導入から運用への移行期」にこそ深刻なリスクになります。

対策1｜パッチ適用の優先順位を上げる

まずやるべきは、明らかな対応です。

Semantic Kernelを使っている開発チームはバージョン確認を行い、Python版なら1.39.4以上、.NET版なら1.71.0以上にすぐ更新してください。

とくに「Search Plugin」+「In-Memory Vector Store」の組み合わせを本番運用している場合は、脆弱性公表前から悪用されていた可能性も否定できません。アクセスログを遡って調査することをおすすめします。

対策2｜AIエージェントの権限を最小化する

次に重要なのが「権限最小化」です。

AIエージェントには、業務に必要な最低限の権限だけを与える。これが原則です。

たとえば請求書処理を担うAIエージェントに「全社員の人事データへの読み取り権限」が付与されていたら、プロンプトインジェクション一発で情報漏えいに発展します。「読み取り専用にできるところは書き込み権限を外す」「他システムへの接続は最小限に絞る」といった当たり前の対策が、ますます重要になっています。

対策3｜サンドボックス分離を徹底する

AIエージェントが扱う処理は、本番システムから隔離された環境（サンドボックス）で実行しましょう。

今回のCVE-2026-25592もサンドボックス機能の不備が突かれたものですが、サンドボックス自体は防御の柱として有効です。最新パッチが当たったコンテナ環境を使い、AIエージェントから本番DBや認証情報に直接触れさせない設計が基本になります。

対策4｜ヒューマンインザループ（HITL）を組み込む

意外と見落とされがちなのが「人間のチェックを挟む」仕組みです。

AIエージェントが重要な操作（ファイル削除、メール送信、決済処理など）を行う前に、必ず人間が承認するワークフローを組み込む。これだけで、プロンプトインジェクションに乗っ取られた攻撃の被害を大幅に抑えられます。

完全自動化が魅力的に見えても、「人間が止められる地点」を残す設計が現時点の正解です。

対策5｜継続的な脆弱性監視と社内教育

最後は地味ですが大切な「継続性」の話。

AIエージェントの脆弱性は今後も次々に出てきます。社内に「AIセキュリティ担当」を明確に置き、CVE情報を日常的にウォッチする体制を作りましょう。

同時に、AIエージェントを業務で使う一般従業員にも「プロンプトインジェクションとは何か」を簡単に教育することが必要です。怪しい外部データをAIに渡さない、というシンプルな注意が、企業全体の防御力を底上げします。

よくある質問（FAQ）

Q. Semantic Kernelを使っていない場合は安心ですか？

A. いいえ、他のAIエージェントフレームワークでも同種の脆弱性が見つかっています。

2025年12月にはLangChainで「LangGrinch」（CVE-2025-68664）が公表されました。LlamaIndexやAutoGenでも個別の問題が報告されています。プロンプトインジェクションがRCEに直結する構造は「AIエージェント全般の設計課題」であり、Semantic Kernel固有の問題ではありません。利用フレームワークを問わずセキュリティ点検が必要です。

Q. AIエージェントを使うのは危険なのでやめるべきですか？

A. 適切な設計と運用があれば、リスクを管理しながら活用できます。

AIエージェントには大きな生産性向上効果があります。問題は「無防備に本番システムに繋ぐこと」であって、AIエージェント自体ではありません。権限最小化・サンドボックス分離・ヒューマンインザループの3原則を守れば、リスクをコントロールしながら導入できます。「使わない」ではなく「正しく使う」が現実的な答えです。

Q. 自社の脆弱性をどう確認すればいいですか？

A. まずパッケージのバージョンを確認し、Microsoft公式アドバイザリを参照してください。

Python版なら`pip list`や`requirements.txt`で`semantic-kernel`のバージョンを確認。.NET版ならNuGetパッケージマネージャで`Microsoft.SemanticKernel`を確認します。脆弱なバージョンを検出するためのGitHub Advisoryも公開されているので、Dependabotなどの依存性スキャナを活用すると自動化できます。

Q. プロンプトインジェクションを完全に防ぐ方法はありますか？

A. 残念ながら「完全に防ぐ手法」はまだ確立されていません。

OpenAIもMicrosoftも公式に「プロンプトインジェクションを完全に防ぐ汎用手法はない」と表明しています。だからこそ、被害を限定する「多層防御」が現実的な対策です。入力検証・出力フィルタ・権限分離・サンドボックス・人間のチェックなど、複数の防御層を組み合わせて、どこか1層が破られても全体が陥落しないように設計します。

Q. Microsoft Agent Framework 1.0に移行すれば安全ですか？

A. 新製品でも基盤コードを引き継ぐ部分があるため、油断は禁物です。

Microsoft Agent Framework 1.0（2026年4月3日GA）はSemantic KernelとAutoGenを統合したものです。新製品でも依存する内部ライブラリで同じ問題が残っている可能性があります。移行先で「最新の修正版を確実に取り込んでいるか」「自社のプラグイン設計に類似のリスクがないか」を確認することが大切です。

Q. 中小企業でもこれらの対策は現実的ですか？

A. 「全部やる」より「優先度の高い対策から段階導入」がおすすめです。

中小企業がいきなり全部の対策を入れるのは負担が大きいでしょう。まず「パッチ適用」と「権限最小化」の2つから始めるのが現実的です。AIエージェントが触れる範囲を業務上必要な最小限に絞り、定期的にバージョンアップを行うだけで、リスクの大半は抑えられます。

まとめ

2026年5月7日公開：MicrosoftがSemantic Kernelの深刻なRCE脆弱性2件を自ら公表
CVE-2026-26030（CVSS 9.8）：Python版でeval()が悪用され、プロンプト1行で任意コード実行が可能だった
CVE-2026-25592：.NET版でサンドボックス外への任意ファイル書き込みが可能
パッチ適用：Python版1.39.4以上、.NET版1.71.0以上が修正バージョン
業界全体の課題：LangChain・LlamaIndexなど他フレームワークでも同種の脆弱性が次々に公表
OWASP 2026：プロンプトインジェクションが最大脅威。本番AIエージェントの73%が攻撃を受けている
日本企業の対応：パッチ・権限最小化・サンドボックス・人間のチェック・継続監視の5本柱が必須
使わないではなく正しく使う：3原則を守ればAIエージェントの生産性メリットは享受できる

まず確認したいのは、自社で使っているAIエージェント基盤のバージョンです。Semantic Kernelを採用している場合は、開発チームに「Python版1.39.4以上／.NET版1.71.0以上に上げてください」とすぐに伝えましょう。並行して、AIエージェントの権限範囲を見直すことから始めるのがおすすめです。