「生成AIを入れたら、業務が速くなった」。ここまでは多くの現場が到達しています。ですが本当に差がつくのは、その次です。総務省が2026年3月27日に公表した「AIのセキュリティ確保のための技術的対策に係るガイドライン」は、まさにこの次の一歩、つまりAI特有の攻撃面を前提に設計と運用をやり直すための実務文書として読むと、急に腹落ちします。公表資料は総務省の報道ページと本編PDFから確認できます。
https://www.soumu.go.jp/menu_news/s-news/01cyber01_02000001_00282.html
https://www.soumu.go.jp/main_content/001064122.pdf
このガイドラインの主な対象は、LLMおよびLLMを構成要素に含むAIシステムです。想定読者は、モデルやシステムを開発するAI開発者と、それをサービスに組み込んで提供するAI提供者です。一方で、AIエージェントは対象外とされています。技術進化が速く、特有の脅威や対策を安定的に整理しにくい段階だからです。ここを先に押さえておくと、文書の射程を誤読しにくくなります。
いつものWebセキュリティだけでは守り切れない理由
この文書の核心を一文で言えば、AIシステムは普通のWebアプリの延長線だけでは守れない、ということです。認証・認可・WAF・監査ログはもちろん重要ですが、それだけでは足りません。そこに、プロンプト、外部参照データ、モデル出力、ツール実行、推論コストというAI固有の攻撃面が増えるからです。
総務省ガイドラインで中心的に扱われる脅威は、プロンプトインジェクション攻撃とDoS攻撃です。特にLLMでは、重い入力を投げ続けて計算資源を消耗させる形の攻撃が、可用性だけでなくコスト面でも実害になります。つまり「動くこと」自体がセキュリティ要件になります。
ただし、ここで視野を狭めるのは危険です。関連する公的資料や評価観点では、データポイズニング、細工されたモデル導入、モデル抽出、メンバーシップ推論、モデル反転なども整理されています。AISIの評価観点ガイドを併読すると、総務省ガイドラインをより立体的に読めます。
https://aisi.go.jp/output/output_framework/guide_to_evaluation_perspective_on_ai_safety/
まずは4層に分けると、脅威分析が迷子にならない
現場で最初に効くのは、AI機能を4層に分けて見ることです。これだけで「どこに何の事故が起きるか」が整理しやすくなります。
入力層で起きること
ユーザー入力、添付ファイル、Web取得文書、RAGで参照する社内文書がここに入ります。この層の主なリスクは、不正命令の混入と毒入りデータの流入です。自然言語の中に命令文が埋め込まれていても、単なる情報として扱うべきか、制御命令として扱うべきかを明確に切り分ける必要があります。
オーケストレーション層で起きること
システムプロンプト、ワークフロー、ツール呼び出し制御、RAG検索制御を担う層です。ここで起きる事故は、意図しない権限昇格や誤作動です。モデル単体の問題というより、周辺制御の設計不備で事故が増幅します。
モデル・推論層で起きること
推論コストの急増、過剰な情報露出、モデル抽出の試行などが主な論点です。性能評価だけでなく、悪用される前提の制限設計が必要になります。
外部接続層で起きること
社内DB、SaaS、メール、ファイル、業務APIへの接続が集中する層です。最も実害が出やすく、AIの誤作動がそのまま機密アクセスや不正操作につながります。ここを「便利機能」として安易につなぐと、事故は一気に深刻化します。
実装で効く7つの再設計ポイント
ここからは、現場でそのまま使える形に落とします。順番は、導入しやすさよりも事故抑止効果を優先しています。
プロンプトを信用しない前提にする
ユーザー入力だけでなく、RAGで取得した文書や外部サイトのテキストも、半信頼または非信頼データとして扱います。自然言語をそのまま制御命令として実行しない境界を、オーケストレータ側で明示的に設けることが出発点です。
RAGを検索機能ではなく権限付きアクセスとして扱う
RAGは「検索できるか」より先に、「誰がどのデータを参照できるか」を設計すべき仕組みです。アプリ画面の認可だけでなく、検索インデックス、ベクトルDB、原本ストアまで一貫して権限を通します。デジタル庁の調達・利活用ガイドラインでも、RAG検索先のアクセス権限設定不備を具体的なリスクとして扱っています。
https://www.digital.go.jp/news/3579c42d-b11c-4756-b66e-3d3e35175623
出力を検査してから返す
従来は入力検証が中心でしたが、生成AIでは出力検証が同じ重さを持ちます。個人情報、秘密情報、不許可コマンド、危険URL、異常に長い応答などを返答前に検査し、条件に応じてマスクや拒否に切り替える構成が必要です。
ツール実行は最小権限に固定する
読み取り系と更新系の権限を分離し、対象リソースを限定し、危険操作は人間承認を必須にします。AIに広すぎるトークンを渡す設計は、誤誘導が起きた瞬間に実害へ直結します。
推論コストを守るレート制御を入れる
DoS対策をネットワーク層だけで終わらせず、トークン量、コンテキスト長、ツール連鎖回数、処理時間、ユーザー単位のコスト上限まで制御対象に含めます。LLMでは、可用性とコストは同時に守る設計が必要です。
モデルとデータの供給網を点検する
OSSモデル、追加学習データ、埋め込みモデル、外部プラグイン、評価データセットは、すべてサプライチェーン上のリスク対象です。由来、ハッシュ、署名、取得元、評価結果、更新履歴を管理し、持ち込み部品の透明性を確保します。
ログを会話履歴だけで終わらせない
入力、システムプロンプト版、RAG参照文書ID、ツール呼び出し履歴、利用モデル版、フィルタ判定、拒否理由、出力後処理結果まで観測可能にします。AIの挙動は非決定的なので、再現できなくても再構成できるログ設計が重要です。
明日から回せる、実務への落とし込み手順
ガイドラインを読んで終わりにしないために、実務では三段階で進めるのが現実的です。
まずは棚卸しです。チャットUIの有無ではなく、外部文書参照の有無、社内文書参照の有無、業務API呼び出しの有無、メールやファイル更新の有無、追加学習の有無を洗い出します。ここで危険度の輪郭が見えます。
次に、機能ごとの脅威対策表を作ります。内部向けRAGチャットであれば、プロンプトインジェクション対策、機密権限制御、出力フィルタ、監査ログ、トークン制限、危険操作禁止を1枚で管理します。優先順位は「モデルの賢さ」ではなく、「失敗したときに何が漏れ、何が壊れるか」で決めます。
最後に、統制コンポーネントをアプリ外側に分離します。入力検査、RAG前認可、出力検査、ツール実行前ポリシー判定を別レイヤーに置き、モデルを万能な意思決定主体ではなく推論エンジンの一部として扱います。この構成に変えると、モデルを入れ替えても統制を維持できます。
いちばん大事な読み方
このガイドラインを読んだIT技術者が持つべき感覚は、AIの安全性はモデル選定よりシステム設計で決まる、という一点です。高性能モデルでもRAG権限が甘ければ漏えいします。プロンプトを工夫しても出力検査がなければ危険応答は出ます。認証が堅くても、AIに広いAPI権限を渡せば事故は起きます。
総務省の文書は、その当たり前をAI時代の実装論として言語化したものです。だからこそ、読むだけでなく、設計レビュー項目と運用手順に変換して初めて価値が出ます。AIを「便利な機能」として追加する段階から、AIを「攻撃面を持つシステム」として運用する段階へ、ここで確実に進めていきたいです。
作成日：2026年4月1日