社内AIのプロンプトインジェクションを確かめるには？頼み方と確認点

社内AIのプロンプトインジェクションは、導入前に範囲と判定基準を決め、専門の会社に確認を頼むのが現実的な確かめ方です。プロンプトインジェクション攻撃とは、総務省のガイドライン⁠によれば、細工をした入力でLLMに不正な出力をさせる攻撃です。細工をしたデータを参照させる間接型もあります。

今日は、社内AIについて3つ⁠を紙に書いてください。AIが読めるデータ、AIが動かせるシステム、誰が使うか、です。これが無いと、依頼先は範囲も費用も出せません。

この記事は発注者向けです。攻撃の具体的な方法は扱いません。

一度確かめれば済むものではない

先に、期待値をそろえておきます。

プロンプトインジェクションには、完全に防げる方法が確立していません。OWASPのLLM01:2025は、確実に防ぐ方法があるかは不明だとした上で、影響を抑える対策を並べています。

確認の結果にも限界があります。AISIのレッドチーミング手法ガイド 第1.10⁠版は、自然言語を受け付けるシステムは入力の種類が多く、網羅的な確認は難しいとしています。AIは同じ入力に同じ出力を返すとは限らず、確認時に成功しなかった攻撃が後で成功する可能性もあります。

ですから、発注の目的は「安全の証明」ではありません。起きては困ることに絞って対策の効き目を確かめ、直す場所を見つけることです。

実際の製品でも問題は見つかっています。IPAの10大脅威 2026 解説書は、2025年6月⁠に報道された Microsoft 365 Copilot の脆弱性「EchoLeak」⁠を取り上げています。外部から不正なプロンプトが注入されると、社内の秘密データ等が流出する可能性があったという内容で、解説書が挙げる報道の見出しには修正済みとあります。

頼む前に、自社で何を決めておく？

依頼先に渡す情報は、次の表の形にまとめると伝わります。

大事なのは最後の行です。AISIのガイドは、重視する点は実際のリスクに応じて決める必要があるとし、事業領域に詳しい人の知見も使うよう求めています。これは社内の人にしか書けません。

たとえば、部品メーカーが取扱説明書、設計標準、不具合報告を検索する社内AIを作る場合です。「製造の担当者に、原価が入った文書の内容が見える⁠」⁠は困ることの1つです。仕入先からのメールも検索対象なら、「メールの中身によってAIの動きが変わる⁠」⁠も候補になります。

後者は、IPAのAI利用者のためのセキュリティ豆知識⁠が「混ぜるな危険」⁠と呼ぶ場面に近いものです。検索の範囲を適切に制限することも、選択肢に挙がっています。

依頼の範囲は、どう決める？

見積もりの前に、次の5点⁠を依頼先とすり合わせます。AISIの手法ガイドにある考え方を、発注者の言葉に直したものです。

どの環境で実施するか

ガイドは実運用環境、ステージング環境、開発環境の3つ⁠を挙げています。内容によっては実運用のサービスが予期せず止まる場合もあるとしています。業務で使っているAIを対象にするなら、影響を関係者と協議してから範囲を決めます。

どこまで情報を渡すか

内部の情報を渡さないブラックボックス、渡すホワイトボックス、一部だけ渡すグレーボックスがあります。ブラックボックスは攻撃者の目線に近く、ホワイトボックスはより多くの対策の効き目を確かめられます。部品ごとに組み合わせることも多いとされています。

商用のLLMを使う場合、LLMの部分は基本的にブラックボックスでしか確かめられません。

外部のAIサービスの部分をどう扱うか

LLMを外部のAPIで使っている場合、提供元からテスト結果等をできる限り入手するよう、ガイドは勧めています。その上で、外部のLLMが安全でも、システム全体の安全は保証されないとしています。自社でつないだ部分を確認の中心に置きます。

市販のサービスを対象にするときは、利用規約でテストが認められているかを提供元に確かめてから始めます。

外から入るデータも対象に含めるか

利用者が打ち込む文章だけでなく、AIが読みにいくWebページやファイル、メールも入口です。総務省のガイドラインは、前者を直接型、後者を間接型と分けています。RAG（文書を検索してAIに渡す仕組み⁠）⁠やメール連携があるなら、間接型を範囲に含めるか明示します。

何を成功とみなし、何回試すか

AIの出力は揺れるため、判定の基準と実行回数を先に決めるようガイドは求めています。実施の条件と結果の記録も残します。「問題なし」⁠の報告を受けたときに、何回、どの条件で試した結果なのかが分からないと、判断ができません。

確認点は、どの項目を入れる？

依頼書には、攻撃方法ではなく「確かめたい結果」⁠を書きます。総務省のガイドラインとOWASPの内容から、発注者が見るべき項目を整理しました。

依頼先には、結果だけでなく原因がどの層にあるかも分けて報告してもらいます。AIの答え方の問題なのか、権限の設定の問題なのかで、直す人が変わるからです。

権限の設定は、確認を頼む前に自分たちで見直せます。総務省のガイドラインは、AIや連携システムを動かす権限を必要最小限にすれば、攻撃を受けた場合の被害拡大を抑えられるとしています。AIの中身に触らなくても手を打てる部分です。

契約で押さえることは？

確認の過程で、依頼先は社内の機密情報に触れる可能性があります。AISIの手法ガイドが、契約に盛り込むことが望ましいとしている項目は次のとおりです。

• 機密情報の取り扱いと、求めるセキュリティ対策
• 再委託の禁止
• 必要に応じた監査の実施
• 確認によって生じうる法的責任についての免責または補償

あわせて、国や地域で情報管理の法令や対策が異なる可能性にも留意するよう書かれています。作業する場所や担当者の所在も聞いておきます。

見積もりを比べるとき、何を聞く？

ここでは金額の相場は書きません。範囲によって大きく変わるうえ、確かめられる公的な統計が見当たらないためです。代わりに、各社に同じ質問をして中身を比べます。

• LLMを組み込んだシステムの確認の実績を、公開できる範囲で説明できるか
• Webアプリの診断メニューに、AIへの確認が含まれるのか、別メニューなのか
• 間接型まで範囲に入るか
• 自動ツールと人の手作業の割合はどうか
• 判定基準と実行回数を報告書に書くか
• 直したあとの再確認が料金に含まれるか

依頼先を探すときは、ペネトレーションテストの比較と脆弱性診断サービスの比較から候補を出し、AIを対象にできるかを個別に確かめます。確認ではなく、見張りや入出力の制御を常時入れたい場合はAIセキュリティ製品の比較が入口です。

報告書を受け取ったら、何を見る？

AISIの手法ガイドは、工程を計画、攻撃の計画と実施、結果のとりまとめと改善の3つ⁠に分け、全部で15のステップにしています。終わりの部分は発注者の仕事でもあります。

ガイドの別添には成果物の例があり、次の3点⁠が示されています。

• リスクシナリオと攻撃シナリオ、その実施結果
• レッドチーミング実施結果報告書
• 最終報告書

納品物をこの3点⁠と照らすと、抜けに気づきやすくなります。受け取ったら、見つかった問題ごとに「誰が、いつまでに直すか」⁠を決めます。ガイドでも、改善計画と、改善後のフォローアップまでが工程に入っています。

いつ、やり直す？

初回はリリースや運用開始の前が基本です。AISIのガイドは、できれば企画の段階から攻撃者の目線でリスクを分析しておくと、手戻りが少なくなるとしています。

運用を始めたあとは、次のようなときにやり直しを検討します。

• システムプロンプトを変えたとき
• AIのモデルを更新したとき
• セキュリティ対策を追加、修正したとき
• 新たな脅威が懸念されるとき、想定外の問題が起きたとき

社内AIは、読ませる文書や連携先が少しずつ増えていきます。「メール連携を足した」「協力会社にも開放した」といった変更も、起きては困ることが変わるので見直しの対象に入れておきます。

全社の確認を毎回やり直す必要はありません。ガイドは、気になる脅威に絞って行う方式も挙げています。

自社の立場がまだ整理できていないときは

そもそも社内AIが「使うだけ」⁠な⁠の⁠か「組み込み」なのかで、読む資料も頼む範囲も変わります。生成AIのセキュリティガイドラインの読み分け⁠で先に確かめてください。社員への周知がまだなら、生成AIの社内ルールの項目と例文から始めるほうが早い場合もあります。AIのセキュリティの全体はAIのセキュリティ記事の一覧⁠にあります。