自社のAIアプリのセキュリティの確かめ方

自社の「基盤とセキュリティ」の準備度は？10問・約3分で確かめる（無料・登録不要）

社内向けのチャットボットや、社内の資料を検索して答えるRAG（検索拡張生成）のアプリを自社で作る会社が増えています。この記事では、総務省の「AIのセキュリティ確保のための技術的対策に係るガイドライン」と、AIセーフティ・インスティテュート（AISI）の「AIセーフティに関するレッドチーミング手法ガイド」にそって、自社のAIアプリの確かめ方を整理します。

自社のAIアプリには、どんな脅威がありますか？

総務省のガイドラインは2026年3月に策定され、大規模言語モデル（LLM）と、LLMを組み込んだAIシステムを主な対象にしています。読み手は、AIを開発する事業者と、AIを使ったサービスを提供する事業者です。社内向けのアプリを自社で作る会社も、提供する側の対策が参考になります。

ガイドラインが主な脅威として挙げるのは次のとおりです。

• プロンプトインジェクション攻撃：細工した入力で、不正な出力をさせる攻撃です。利用者が直接細工する「直接型」と、AIが参照するWebページやメールに細工をしておく「間接型」があります。被害の例として、RAGのデータの漏えい、AIに設定した内部の指示（システムプロンプト）の露出、連携するシステムでの不正な命令の実行が挙げられています。
• DoS攻撃（サービス拒否攻撃）：大量の計算を求める入力で、応答を遅らせたり止めたりする攻撃です。外部のAPIの利用上限に達することも含みます。
• そのほかの脅威：学習データに細工をする攻撃（データポイズニング）、細工したモデルを組み込ませる攻撃、問い合わせを繰り返してモデルを複製する攻撃（モデル抽出）です。

なお、ガイドラインは、自律的に動くAIエージェントについては、脅威や対策がまだ安定していないとして対象外にしています。AIエージェントの権限と確認は「AIエージェントを安全に使うための権限と確認」で扱います。

海外では、OWASP（Webアプリのセキュリティに取り組む国際的なコミュニティ）が、LLMを使うアプリの主なリスクを「Top 10」としてまとめています。2025年版の10項目は、プロンプトインジェクション、機密情報の開示、サプライチェーン、データとモデルのポイズニング、不適切な出力の処理、過剰な権限（Excessive Agency）、システムプロンプトの漏えい、ベクトルと埋め込みの弱点、誤情報、際限のない消費（Unbounded Consumption）です。版ごとに項目が見直されています。確認の観点を広げるときの参考になります。

何を、どの観点で確かめればよいですか？

総務省のガイドラインが提供者向けに挙げる対策を、確かめる5つの観点に整理します。

システムプロンプトには、制約や注意事項を書きます。APIキーなどの秘密の情報はシステムプロンプトに直接書かず、別に管理します。 システムプロンプトは、攻撃によって外に出てしまう場合があるためです。

④の権限は、事故の被害の大きさを左右します。RAGのアプリで、利用者が本来見られない資料まで検索の対象になっていると、AIの回答を通じてその内容が伝わってしまうことがあります。元の資料の閲覧の権限と、AIが参照する範囲がそろっているかを確かめます。

レッドチーミングは、どう進めますか？

総務省のガイドラインは、新しい脅威が続けて出てくることから、レッドチーミングで脅威を見つけ、対策の有効性を確かめることを重要としています。AISIの手法ガイドは、レッドチーミングを、攻撃者がどのようにAIシステムを攻撃するかの観点で、対応の体制と対策の有効性を確かめる評価の手法と説明しています。

2025年3月31日に公表された第1.10版は、3つの工程と15の手順で進め方を示しています。

① 実施の計画と準備：実施を決めてレッドチームを作り、予算と人を確保します。計画を立て、実施の環境を用意し、問題が見つかったときの連絡の流れ（エスカレーション）を確かめます。

② 攻撃の計画と実施：起こりうるリスクの筋書き（リスクシナリオ）と攻撃の筋書き（攻撃シナリオ）を作り、攻撃を行います。実施中の記録を取り、終わったら一時的なアカウントの削除や設定の復帰を行います。

③ 結果のとりまとめと改善：結果を分析して報告書を作り、関係者で確かめます。改善の計画を立てて実施し、改善の後も確かめます。

実施の時期について、手法ガイドは、初回は対象のシステムのリリースや運用の開始の前に行うことを基本とし、運用を始めた後も必要に応じて行うことが望ましいとしています。規模の大きなシステムでは、部品や層ごとに分けて行う方法も示されています。

体制は、開発・提供のチームと連携する形でレッドチームを置き、責任者を決めます。社内で十分な体制が取れない場合は、外部の事業者に攻撃の計画と実施を頼む方法もあります。第1.10版では、成果物の例（シナリオと攻撃結果の記録、報告書）も別添として示されており、進め方の参考になります。

運用の中で、何を続ければよいですか？

総務省のガイドラインは、対策を講じても脅威の要因を完全に取り除くことは難しく、複数の対策を組み合わせてリスクを下げる考え方を示しています。そのため、作った後の運用が大切になります。

• 記録を見る：不正な指示が検知された記録や、利用量の急な増え方を定期的に確かめます。
• モデルや部品を変えたら確かめ直す：使うモデルや組み込む部品を変えると、対策の効き方が変わることがあります。ガイドラインも、技術の進展や基盤モデルの変更に合わせて対策を見直すよう求めています。
• 事故のときの流れを決める：機密情報が出力された、想定外の操作が行われた、といった場合の止め方と連絡先を決めておきます（「AIの不具合・事故への備えと対応」参照）。

チェックリスト

• AIアプリが参照するデータと、ほかの仕組みに対してできる操作を一覧にしている
• 入力に不正な指示が含まれていないかを確かめる仕組みがある
• 参照する外部のデータと、利用者の入力を区別して扱わせている
• 出力に機密情報が含まれていないかを確かめている
• システムプロンプトに、APIキーなどの秘密の情報を書いていない
• RAGで参照する範囲が、元の資料の閲覧の権限とそろっている
• ほかの仕組みを操作する部分の権限を、必要最小限にしている
• 監査の記録を保存し、問い合わせの回数に上限を設けている
• リリースの前にレッドチーミングを行い、改善の計画を立てている
• モデルや部品を変えたときに、対策を確かめ直す手順がある