社内の勉強会（WG）で話し合った内容をもとに、AIを業務に取り入れるうえで押さえておきたいセキュリティの考え方をご紹介します。今回のWGでは、AIの進化が業務を効率化する一方で、攻撃する側もAIを使うようになり、リスクの質と速さが大きく変わっていることが主なテーマになりました。
この記事では、次の3つの話題を取り上げます。
- 先回りして動く「常駐型AI」と、その管理のしかた
- AIによって加速するサイバー攻撃と、古いシステムを放置する危険
- AI特有の弱点「プロンプトインジェクション」の仕組みと緩和策
1. AIは「聞かれて答える」から「先回りして動く」へ
WGでは、AIエージェント（目的に向けて自分で手順を考え、ツールを操作するAI）の発展を、次の4段階に整理しました。
- チャット型：問いかけ（プロンプト）に対して回答を返す基本の段階
- ワークフロー型：決められた手順に沿って、一連の業務を順番に実行する段階
- エージェント型：目的を与えると、必要な手順や手段をAI自身が判断し、ツールを操作して進める段階
- 常駐型：利用者のそばに常に控え、指示を待たずに状況の把握・段取り・確認を先回りして行う段階
WGでは、ブラウザを自分で操作して情報検索から商品の購入代行まで行う常駐型AIが各社から登場していることが話題になりました。便利な一方で、次のような課題も挙がっています。
見えないところで使われる計算量
常駐型AIは裏側で継続的に情報収集やタスク探索を行うため、トークン（AIが処理する文字の単位で、利用料金の基準になるもの）を大量に消費します。いまは提供側が負担していても、将来その負担が利用者や事業者に回ってくる可能性があります。そのため、利用量に上限を設けるなど、仕組みとしての制限を用意しておくことが大切です。
誤った判断による「望まない購入」
決済まで代行できるAIは、判断を誤ると意図しない商品の購入や、不適切な契約につながるおそれがあります。お金や契約が関わる操作には、必ず人間が最終承認するというガードレール（安全のための制限）を組み込むことが欠かせません。
2. AIで攻撃が速くなる時代の守り方
WGで特に危機感をもって議論されたのが、攻撃する側によるAIの活用です。これまでの防御は「人間が手作業で弱点を探す」ことを前提にしていましたが、その前提が崩れつつあります。
脆弱性の公表から攻撃までが「分単位」に
以前は、脆弱性（システムの弱点）が公表されてから実際に攻撃されるまで、数日から数週間の猶予がありました。WGでは、AIによる自動探索によって、公表からわずか分単位で自動攻撃が始まる状況になっていることが話題になりました。
また、単体では攻撃に結びつかないような小さな不具合でも、AIがコード全体を網羅的に調べて組み合わせることで、実際に使える攻撃手順に仕立てられてしまうという点も共有されました。WGでは、PHP（Webサイトでよく使われるプログラミング言語）に長く潜んでいたメモリの不具合が、AIによるコード探索と関係して見つかった事例も取り上げられています。
古いOSや放置されたWordPressが「裏口」になる
WGで共有された教訓のひとつは、メインのサービスが安全でも、同じサーバーに同居している保守されていないWordPressが侵入口になり得るということです。また、サポート終了（EOL）を迎えたOSを使い続けていると、OSのセキュリティ修正はもう提供されません。いざ問題が起きたときには設定変更では対処できず、サーバーの移行や作り直しが必要になり、長期間サイトを止めることにもつながります。
さらに、WAF（Webアプリケーションへの攻撃を防ぐ仕組み）やIP制限だけでは、正常な通信に見せかけた攻撃を防ぎきれない場合があることも話題になりました。
守る側もAIで先回りする
「今まで大丈夫だったから」という考え方はもう通用しません。攻撃側がAIで弱点を探す以上、守る側も日常的にAIを使って自社の弱点を先回りして見つけ、修正し続ける姿勢が求められます。
3. AI特有の弱点「プロンプトインジェクション」
プロンプトインジェクションとは、AIが読み込むデータの中に悪意ある指示を紛れ込ませ、AIを本来の目的とは違う動きに誘導する攻撃です。
なぜ防ぎにくいのか
原因は、大規模言語モデル（LLM）が、構造上「人間からの命令」と「処理対象のデータ」を区別できないことにあります。システム側のルール、利用者の指示、外部から読み込んだメールやファイルは、すべてひと続きの文章として同じように扱われます。そのため、データの中に「隠し命令」があると、AIがそれを新しい指示と受け取って実行してしまうことがあります。
WGでは、次のような攻撃の流れが紹介されました。
- HTMLメールの隠し文字：白い背景に白い文字や極小の文字で、人には見えない指示を埋め込む。「受信メールを要約して」と頼んだだけで、隠された指示が実行されるおそれがある
- 外部のMarkdownファイル：「この仕様書に従って修正して」と渡したファイルに悪意ある指示が潜み、読み込んだ時点でエージェントの動作が乗っ取られる
- MCPを通じた連携の悪用：MCP（Model Context Protocol、AIと外部ツールをつなぐ仕組み）で、メール読み込みなどの入力系と、GitHubへの書き込みやデータベース更新などの出力系が同じAIにつながっていると、入力から入り込んだ命令が出力側で実行されてしまう
現時点での緩和策
- 入力系と出力系のMCPを分ける：読み込み用と書き込み用のツールを、同じAIの処理に無制限につながない
- 確認していない外部データを自動で読ませない：不要な営業メール、信頼性の低いサイトのHTML、送り主の分からないファイルをAIに直接処理させない
- 参照先をホワイトリストで限定する：AIが参照できる情報源や連携ツールを、許可したものだけに絞る
ただし、データベースへの攻撃を防ぐ「プレースホルダー」のように、命令とデータを機械的に切り分ける仕組みはLLMにはありません。これらはあくまで被害を小さくするための対策です。重要な外部への出力の前には、必ず人間の確認を挟む運用にしておくことが不可欠です。
まとめ：WGで共有した3つの心得
最後に、WGで全員の指針として確認した3つの心得をご紹介します。
- 作る速さと同じだけ、確かめる速さを身につける：AIで開発が速くなった分、生成されたコードや設定の安全性を検証する速さも同じかそれ以上に高める
- 最小権限の原則を徹底し、不用意にデータを渡さない：AIエージェントや外部ツールに、不要なアクセス権限や未確認のメール・機密情報を渡さない
- シャドウAIをなくし、動いている環境を定期的に棚卸しする：シャドウAI（会社が把握していないAIの利用）を含め、動いているOS・言語・プラグイン・AIツールを一覧にし、サポート切れの環境や把握していない利用を早めに見つける
AIは強力な道具ですが、攻撃する側にとっても同じです。便利さを取り入れながら、権限を絞り、人間の確認を挟み、環境を把握し続けること。こうした地道な取り組みが、AI時代の安全な活用につながります。
技術ブログのほかの記事