AIセキュリティガイドラインとは｜総務省の技術的対策の指針
AIセキュリティガイドラインとは、AIそのものへのサイバー攻撃に備える技術的対策の例を、総務省がまとめた文書です。
公表の経緯と位置づけ
総務省は2025年9月から、サイバーセキュリティタスクフォースの下にAIセキュリティ分科会を設けて検討を進めてきました。ガイドライン案への意見募集は2025年12月26日から2026年1月29日まで行われ、52件の意見を踏まえて2026年3月27日に策定・公表されています（出典: soumu.go.jp）。
背景には、2025年6月に閣議決定された「デジタル社会の実現に向けた重点計画」で、総務省が2025年度末までに生成AIとセキュリティのガイドラインを策定すると定められたことがあります。本編のほか、対策の具体例を示す別添（付属資料）も総務省の報道資料ページで公開されています。
対象はLLMを組み込んだAIシステム
ガイドラインが主な対象にしているのは、LLM（大規模言語モデル、大量の文章を学習して文章を生成するAI）と、LLMを構成要素に含むAIシステムです。社内文書を検索して回答するチャットボットや、外部のWebサイトを参照して答えるチャットボットが典型例です。
一方で、AIエージェント（目標に向けて自律的に判断し、外部のツールを操作するAI）は対象外とされています。技術が急速に発展している途中で、特有の脅威や対策を現時点で安定的に確定するのが難しいことが理由です。
想定読者はAI開発者とAI提供者
想定読者は、AI事業者ガイドラインが定義する「AI開発者」と「AI提供者」です。AI開発者はAIモデルを作る事業者、AI提供者はAIモデルを組み込んだサービスを提供する事業者を指します。
業務でAIを使うだけの「AI利用者」は直接の読者ではありません。ただし、社内向けにRAG（Retrieval-Augmented Generation、社内文書などを検索して回答に取り込む仕組み）のチャットボットを構築して従業員に提供する場合、その企業は社内に対するAI提供者の立場になります。自社でAIを組み込んだ仕組みを作る企業にとっては、自分ごとの文書です。
企業がいま目を通しておきたい理由
現場では、AIのセキュリティ面の判断がつかないことが活用の足かせになっています。GiftXがビジネス職のAI利用者に聞いた調査では、次の回答が上位に並びました（複数回答）。
| 回答 | 割合 | 区分 |
|---|---|---|
| どこまでAI活用していいか判断できない | 27.7% | 個人の課題1位 |
| セキュリティ制限でツールが使えない | 19.6% | 組織の課題3位 |
| 利用ルール・ガイドラインがない | 19.1% | 組織の課題4位 |
制限をかけるだけでは活用が止まり、ルールがないままでは事故が怖くて使えません。公的な指針を基準にして「どの対策があれば使ってよいか」を決めておくと、現場が判断しやすくなります。
詳細な調査データは「ビジネス職生成AI活用実態調査（2026年版）」にてご覧ください。
AIセキュリティガイドラインと関連する公的ガイドラインの比較｜AI事業者ガイドライン・AISI・IPA
AIのセキュリティに関わる公的な文書は複数あり、役割が異なります。総務省のガイドラインは、自らの位置づけを関連文書との関係で次のように整理しています。
| 文書 | 策定主体 | 想定読者 | 役割 |
|---|---|---|---|
| AIのセキュリティ確保のための技術的対策に係るガイドライン | 総務省 | AI開発者・AI提供者 | LLMを狙う攻撃への技術的対策例を示す |
| AI事業者ガイドライン（第1.2版） | 総務省・経済産業省 | AIを開発・提供・利用する全ての事業者 | AIガバナンスの統一的な指針。セキュリティ確保は指針の1つ |
| AIセーフティに関する評価観点ガイド | AISI | AI開発者・AI提供者 | AIセーフティを評価する観点を示す |
| AIセーフティに関するレッドチーミング手法ガイド | AISI | AI開発者・AI提供者 | 攻撃者の視点で対策を検証する手順を示す |
全体の方針を決めるのがAI事業者ガイドラインで、その中の「セキュリティ確保」をLLMの具体的な手法まで掘り下げたのが総務省のガイドラインという関係です。AI事業者ガイドラインは2026年3月31日に第1.2版へ改訂されています。AISIは、関係省庁・機関でつくるAIセーフティ・インスティテュートです。
なお、IPAのサイトで公開されている「テキスト生成AIの導入・運用ガイドライン」は、IPAの人材育成プログラム修了生がまとめた成果物です。ページ上でIPAの意見を代表するものではないと注記されているため、公的な基準ではなく実務の参考資料として読むのが適切です。
AIエージェントを「どう作り、どう育てるか」を、GiftX記事制作エージェントの実物で解説。
AIセキュリティガイドラインが対象とするAIへの脅威の種類
ガイドラインは、プロンプトの入力だけで実行できるため攻撃の可能性が比較的高い2つの脅威を主な対象にしています。そのうえで、前提条件が必要なその他の脅威も整理しています。
関連記事：プロンプトインジェクションとは？直接型と間接型の違い、事例と企業の対策
プロンプトインジェクション攻撃
プロンプトインジェクション攻撃は、LLMに細工をした入力を与えて、本来は出してはいけない内容を出力させる攻撃です。ガイドラインは入力の経路で2種類に分けています。
- 直接プロンプトインジェクション：攻撃者が細工したプロンプトを入力する。「過去の指示を無視せよ」と既存の指示を上書きする、研究者を装うロールプレイで有害な出力を引き出す、といった手口がある
- 間接プロンプトインジェクション：LLMが参照するWebページや電子メールに、不正な指示を隠しておく。利用者に悪意がなくても、参照したデータ経由で攻撃が成立する
狙われるのは、RAG用データストアの中身、システムプロンプト（AIの役割や制約を事前に設定する指示文）、連携先システムのデータです。LLMに不正なSQLやシステムコマンドを生成させ、連携先で実行させて改ざんや削除につなげる手口も挙げられています。
DoS攻撃（サービス拒否攻撃）
DoS攻撃は、AIシステムに膨大な処理を必要とするプロンプトを入力し、応答の遅延や停止を起こす攻撃です。LLMに出力を無駄に続けさせたり、ツールを呼び出させ続けたりして、AI提供者に経済的な損失を与える手口も含まれます。従量課金のAPIで動くサービスでは、停止だけでなく利用料の急増というかたちで被害が表れます。同じAPIキーに大量のリクエストを送り、利用上限に到達させてサービスを止める攻撃も想定されています。
データポイズニングなどその他の脅威
攻撃に一定の前提条件が必要なものとして、次の3つが挙げられています。
- データポイズニング攻撃：学習データに細工をして、特定の入力に対して不正な回答を返すようにする
- 細工をしたモデルの導入を通じた攻撃：細工したLLMを外部に提供し、AIシステムに組み込ませる
- モデル抽出攻撃：LLMに繰り返しアクセスして出力を分析し、類似のモデルを複製する
悪意のある攻撃に限らず、設定ミスなどのヒューマンエラーにも注意が必要だと書かれています。
AIセキュリティガイドラインが示す対策の実践方法｜開発者と提供者の役割
ガイドラインは、1つの対策で脅威を完全に排除するのは難しいという前提に立っています。そのうえで、複数の対策を重ねてリスクを下げる考え方を示しています。
関連記事：生成AIで気をつけるセキュリティとは？主要リスクと企業がとるべき対策を解説
AI開発者の対策
AI開発者の主な対策は、安全基準をLLMに事後学習させて、不正な指示への耐性を上げることです。システムプロンプトのような優先度の高い指示を常に優先するよう学習させることも含まれます。
ただし、悪意のある攻撃者は一般の利用者より巧妙な入力を使います。耐性の確認には、AISIの「AIセーフティ評価ツール」や国立情報学研究所（NII）のデータセットなどを活用するよう勧めています。基盤モデルの脆弱性は利用企業側では直せないため、モデルを選ぶ段階で、提供元がどのような安全対策や評価を公開しているかを確認しておくと判断材料になります。
AI提供者の対策
AIを組み込んだサービスを提供する側の対策は、次の3つに分かれます。
- システムプロンプトによる耐性の向上：制約やセキュリティ上の注意事項を書き込む。APIキーなどの機密情報はシステムプロンプトに直接書かず、別に管理する
- ガードレールによる検証：入力プロンプト、外部から参照するデータ、出力の3か所で不正な指示や出してはいけない情報を検知し、処理を拒否する
- オーケストレータやRAGの権限管理：LLMや連携システムを操作する仕組みの権限を必要最小限にする。RAGのデータへの参照権限を、利用者や役割に応じて設定する
ガードレールは、入出力を検証して不正を止める保護の仕組みを指します。オーケストレータは、LLMと外部のツールやシステムをつなぐ処理の流れを管理する仕組みです。
情報システムとしての基本的な対策
LLM特有の対策に加えて、情報システム全般の基本的な対策も必要だとしています。具体的には、監査ログの保存による追跡、膨大なアクセスを抑えるレートリミット、開発環境の権限管理、基盤モデルなど構成要素の信頼性の確認です。
対策の見直しは、基盤モデルが変わったときやLLMが新たに学習したときが目安とされています。また、これらの対策を講じて秘密のデータを適切に管理していれば、漏えいしても不正競争防止法の営業秘密として保護される可能性があるという見解も示されています。
想定事例と自社事例で見るAIセキュリティガイドラインの当てはめ方
ガイドラインには、AIサービスの想定事例が2つ載っています。GiftXが手がけた事例と並べると、自社の仕組みがどちらに近いかを判断しやすくなります。
社内向けチャットボット（RAG利用）
1つ目は、組織内の利用者が社内文書を検索して回答を得るチャットボットです。主な脅威は、利用者が不正なプロンプトでRAGのデータを盗み出す攻撃と、データストアのファイルに仕込まれた指示による攻撃です。対策として、ガードレールに加えてRAGの参照権限の管理が挙がっています。
GiftXが支援した社内ナレッジ検索のAI化では、規程や議事録、過去の提案書を横断検索できるようにし、資料探しが1回約15分から約1分になりました。この種の仕組みでは、役職や部署で閲覧範囲が違う文書をそのまま検索対象に入れると、本来見られない人に回答として届いてしまいます。
オフィス系7職種のAI利用者669人の調査では、生産性向上を明確に実感した割合が、チャット中心の利用層14.3%に対しAIエージェント利用層54.3%。約3.8倍の差が見られました。
外部向けチャットボット（外部連携利用）
2つ目は、組織外の利用者が使うチャットボットで、インターネット上の情報を参照して回答します。システムプロンプトの窃取やDoS攻撃に加え、Webページに隠された指示による間接プロンプトインジェクションが想定されています。
GiftXでは、FAQや注文状況を参照して問い合わせに答えるAIチャットボットを運用し、月2,000件の問い合わせのうち約60%をAIが一次対応しています。社外の誰でも入力できる窓口では、入力と出力の両方を検証するガードレールと、利用回数の上限設定が欠かせません。
利用企業がAIセキュリティガイドラインを読むときの確認ポイント
ガイドラインを自社の対策に落とし込むときは、まず自社の立場と対象のサービスを切り分けます。
- 立場の確認：外部のAIサービスを使うだけか、社内外に向けてAIを組み込んだ仕組みを提供するか
- 公開範囲の確認：利用者が社内に限られるか、社外の誰でも入力できるか
- 連携の確認：社内文書、外部のWebサイト、業務システムのどれとつながるか
提供する立場で、社外に公開し、業務システムと連携するほど、確認すべき対策が増えます。従業員がAIを使うときのルールづくりは、このガイドラインの範囲外です。入力してよい情報や利用できるツールの決め方は、AI事業者ガイドラインや社内の利用ガイドラインで補います。
AIエージェントを業務に組み込む場合も、ガイドラインの対象外である点に注意が必要です。IPAのサイトでは2026年7月に、人材育成プログラム修了生による「生成AIおよびAIエージェントを安全に活用するための手引書」も公開されており、参考資料の1つになります。
関連記事：生成AI利用ガイドラインの作り方｜必須項目と5ステップの策定手順
AIセキュリティ対策を進めるときに陥りがちな3つの落とし穴
落とし穴1｜全社の全用途を一度にガイドラインへ合わせようとする
用途ごとに必要な対策が違うのに全部を同時に揃えようとすると、検討が終わらず、どのAI活用も始まりません。社内向けのRAGと社外向けのチャットボットでは、優先すべき対策がそもそも異なります。
落とし穴2｜文書の読み込みから入り、対策が実装まで届かない
ガイドラインの解説資料を作ることが目的になり、実際のシステムプロンプトや権限設定が変わらないまま時間が過ぎます。APIキーをシステムプロンプトから外す、RAGの参照権限を役割ごとに分けるといった作業は、動く仕組みがあって初めて進みます。
落とし穴3｜既製のチャット型AIに社内データをつなぐだけで済ませる
既製ツールでは、参照権限の細かい設定やガードレールを自社の業務に合わせて組み込めず、守りたいデータを守れません。部署ごとに閲覧範囲が違う文書が同じ回答に混ざると、気づいたときには情報が広がっています。
スモールスタートで1業務をAIエージェントに任せる
まず1つの業務を選び、その業務で必要なガードレールと権限設計を組み込んだうえで動かすと、対策と活用を同時に前へ進められます。1業務で型ができれば、次の業務へ広げるときの基準になります。GiftXでは、セキュリティ要件を含めたAIエージェントの構築を1業務単位から伴走支援しています。詳細はAIエージェント構築支援サービスをご覧ください。
AIセキュリティガイドラインに関するよくある質問
AIセキュリティガイドラインに法的な拘束力はありますか？
法律ではなく、各組織が自らの状況に応じて合理的な対策を選ぶための指針として提供されています。責任の所在を決める趣旨のものでもありません。ただし、取引先や監査で対策状況を問われたときの説明の基準として参照されやすい文書です。
AIを業務で使うだけの企業も対象ですか？
想定読者はAI開発者とAI提供者で、外部のAIサービスを使うだけの企業は直接の対象ではありません。社内向けにAIチャットボットを構築して従業員に提供する場合は、提供者の立場で読む必要があります。
AIエージェントはガイドラインの対象ですか？
対象外です。技術が発展途上で、特有の脅威や対策を安定的に確定するのが難しいためとされています。総務省は、新たな脅威や技術の動向を見ながら追補などで対応するとしています。
社内の情報セキュリティ規程とは何が違いますか？
既存の規程は、アクセス管理やログ管理など情報システム全般を対象にしています。このガイドラインは、プロンプトインジェクションのようにAIの入出力を悪用する攻撃への対策を補うものです。両方を組み合わせて使う位置づけです。
まとめ
AIセキュリティガイドラインは、LLMを組み込んだAIシステムを攻撃から守るために、総務省が2026年3月に示した技術的対策の指針です。主な対象はプロンプトインジェクション攻撃とDoS攻撃で、AI開発者とAI提供者それぞれの対策が整理されています。
社内向けのRAGチャットボットのように、自社で仕組みを作って従業員に提供する企業は、提供者として読む必要があります。全体方針はAI事業者ガイドライン、技術的な手法はこのガイドラインと役割を分けて参照すると、社内の基準を組み立てやすくなります。
対策を一度に揃えるより、1つの業務で対策込みの仕組みを動かし、その型を広げるほうが活用と安全を両立しやすくなります。
AIの安全な業務活用を進めたい方へ
本記事で紹介したAIセキュリティの考え方を踏まえて、自社の業務でもAIエージェントを安全に導入したい・相談したいとお考えの方は、ぜひGiftX AIエージェント構築支援までお問い合わせください。
GiftX AIエージェント構築支援では、貴社の業務に合わせて1業務単位のスモールスタートから本番運用まで、AIエージェント構築をワンストップで支援します。ユースケースの洗い出しから、権限設計を含むPoC、本番運用、社内ナレッジ化まで伴走します。
AI活用にご関心のある方は、ぜひ一度ご相談ください。
▶ GiftX AIエージェント構築支援の詳細・お問い合わせはこちら
