AIセキュリティガイドラインは作る側の宿題｜総務省の指針を実務へ

「総務省がAIのセキュリティのガイドラインを出したらしいが、社員にどんな注意をすればいいのか」「うちはAIを開発する会社ではないから、読まなくても困らないのでは」。情報システムや総務の担当者からは、こうした受け止めがよく聞かれます。どちらも、ガイドラインの題名だけを見れば無理のない読み方です。しかしこの文書は、社員向けの使い方の注意集ではありません。本当は、AIを組み込んだ仕組みを作り、社内や顧客に使わせる側が、技術の面で何を備えるかを並べた宿題の一覧です。社内向けのAIアシスタントを自社で作った会社、外注で作らせた会社は、すでにその宿題を受け取る側にいます。この記事では、ガイドラインの対象と骨格、作る側が自分の仕組みに当てはめて確かめる項目、外注先に求める項目、そして対策を入れても残るリスクの扱い方を整理します。

「社員に配る注意集」と読むと、宿題を見落とす

総務省は2026年3月27日、「AIのセキュリティ確保のための技術的対策に係るガイドライン」を確定させて公表しました。前年12月26日から翌年1月29日まで意見を募集し、寄せられた52件の意見を踏まえて確定した、と報道発表で説明しています。背景には、政府の重点計画で、総務省が年度末までに生成AIとセキュリティのガイドラインを策定するとされていたことがあります。

題名に「セキュリティ」とあるため、社内では情報漏えいを防ぐための社員向けの決まりと受け取られがちです。ところが本文を開くと、書かれているのは、外から細工された入力への備え、入口と出口での検査、仕組みに与える権限の絞り込みといった、システムを作る側でしか手を打てない対策です。社員が気を付ければ済む話は、ほとんど出てきません。

この読み違いをしたまま社員に回覧すると、「社外秘を入れないように」といった既存の注意が繰り返されるだけで、肝心の仕組みの側は点検されずに残ります。回覧先は利用者ではなく、仕組みの担当者と発注の担当者です。社員向けの使い方の決まりは、別の文書で整えるものと割り切っておくと、読む目的がぶれません。

社内向けのAIを作った時点で、自社は「提供者」になる

ガイドラインの想定読者は、総務省と経済産業省の「AI事業者ガイドライン」が定める「AI開発者」と「AI提供者」です。開発者は大規模言語モデルそのものを作る立場、提供者はそのモデルを自社のサービスや業務の仕組みに組み込んで、利用者に使わせる立場と整理できます。大手の言語モデルを借りて社内向けのチャットを作った会社は、開発者ではなくても、提供者の側に立っていると考えるのが自然です。

ガイドラインは想定事例の一つ目に「内部向けチャットボット」を置き、組織内の利用者の質問を受け、社内の検索用の資料置き場から必要な情報を取り出して答える仕組みを描いています。二つ目は、組織外の利用者の質問に、インターネットの公開情報を取りに行って答える「外部向けチャットボット」です。どちらも、外部から基盤モデルの提供を受ける運用を前提にしており、言語モデルを自前で作らない会社を読み手として想定していることが分かります。

外注で作らせた場合も、使わせているのは自社です。作った会社が対策を入れてくれるはずだと考えがちですが、仕様に書いていない対策は入らないことがあります。発注する側が自分を提供者として読み、何を求めるかを決める必要があるのはこのためです。なお、AI事業者ガイドラインを社内の規程に落とす工程は「AI事業者ガイドラインを実務に落とす4工程」の記事で扱っており、本稿は技術の面の宿題に絞ります。

文書の骨格｜範囲・脅威・対策と、2つの想定事例

本文は、策定の背景、第1章「スコープ」、第2章「脅威」、第3章「脅威への対策」、用語集で構成されています。第1章では位置づけ、対象とするAI、想定読者を定め、第3章の最後に、先に触れた二つの想定事例の分析を置いています。対策の具体例や詳細を示す別添（付属資料）も併せて公表されています。

位置づけの章では、AI事業者ガイドラインが共通の指針の一つに「セキュリティ確保」を掲げていることを受け、その具体的な手法を示す文書だと説明しています。扱う「セキュリティ確保」は、不正な操作による機密情報の漏えい、システムの意図しない変更や停止が起きない状態を守ることです。公平性や透明性など、より広い安全性の話は対象の外に置かれています。

対象とするAIは、大規模言語モデルと、それを組み込んだAIシステムです。一方で、自律的に動いて作業をこなすAIエージェントは、技術が急速に発展している途中で脅威と対策を安定して確定できないとして、対象外と明記されています。社内でAIエージェントを作っている会社は、この文書だけで足りると考えず、エージェントに固有の危なさは別に洗い出す必要があります。

• 本稿で取り上げる内容は、2026年3月公表の本文に基づきます。総務省は、技術の進展に応じて追補するなど適時に対応するとしています。
• 別添（付属資料）には対策の具体例が載っています。自社の仕様に落とす段階では、本文と併せて別添も確かめてください。

主役の脅威は2つ、脇役が3つ

ガイドラインが主に扱う脅威は、プロンプトインジェクション攻撃と、サービス拒否攻撃の二つです。どちらも、特別な準備をしなくても質問の入力だけで仕掛けられるため、攻撃が現実に起きる可能性が比較的高いと説明しています。前者は、細工した入力で言語モデルに不正な出力をさせる攻撃で、利用者が直接打ち込む形と、読み込ませる資料やメールに細工を仕込む形の二つに分けています。

不正な出力の例として挙げられているのは、検索用の資料置き場の中身を出させる、つながった仕組みを不正に操作する命令文を作らせて実行させる、内部の設定を書いた指示文を出させる、目的を果たせない誤った内容を出させる、の四つです。サービス拒否攻撃は、膨大な処理を要する入力で計算の負荷や費用をふくらませ、応答を遅らせたり止めたりするものです。同じ接続用の鍵に大量の依頼を送り、利用の上限に当てて止める形も注記で触れられています。

脇役として「その他の脅威」に並ぶのは、学習データに細工するデータ汚染、細工したモデルを組み込ませる攻撃、繰り返し問い合わせてモデルを複製するモデル抽出の三つです。さらに注記では、悪意のある攻撃のほかに、人為的な設定ミスによって生じる脅威にも留意が必要だとしています。外部の指示に乗っ取られる仕組みと、利用者の側での備えの本論は「AIが外部の指示に乗っ取られる原因と対策」の記事で扱っています。

脅威	仕掛け方	作る側で効く主な対策（ガイドラインの整理）
直接の指示の注入	利用者が細工した入力を打ち込む	指示文での制約・入力の検証・出力の検証・権限の絞り込み
間接の指示の注入	読み込ませる資料・メール・ウェブに細工を仕込む	上記に加え、外から読む資料の検証
サービス拒否	膨大な処理を要する入力・大量の依頼	指示文での制約・入力と外から読む資料の検証・流量の制限
データ汚染・細工したモデル	学習データや組み込むモデルに細工する	学習データと基盤モデルの信頼性の確認・出力の検証
モデル抽出	繰り返し問い合わせて複製する	単語の出現確率など無用な情報を出さない・流量の制限

優先順位は「影響の大きさ」と「起こりやすさ」で決める

ガイドラインは、どの脅威に手を打つべきかは事例ごとに検討するものだとし、考える要素として二つを挙げています。一つは、事故が起きたときの影響の大きさです。事業の停止による損失なのか、信用の失墜なのか、影響の性質も範囲も深刻さも、仕組みの用途によって変わります。もう一つは、起こりやすさで、外部とつながっているか、どんな利用者が使うかといった置かれた環境で変わるとしています。

社内向けのチャットに当てはめると、利用者は社員に限られるため、外部の攻撃者が直接打ち込む可能性は低めに見積もれます。その一方で、答えの材料になる資料置き場に人事や経営の資料が混ざっていれば、社員の誰かが本来見られない情報を引き出したときの影響は大きくなります。外部向けのチャットでは逆に、誰でも打ち込めるため起こりやすさが高く、指示文の盗み出しやサービス拒否への備えが先に来ます。

ここで押さえておきたいのは、ガイドラインが対策の一覧を示しているだけで、全部を同じ強さで入れよとは言っていない点です。自社の仕組みの用途と置かれた環境から、影響と起こりやすさを書き出し、どこに厚く手を打つかを決めるのは、作る側の仕事です。この書き出しを省くと、費用のかかる対策を一律に入れて予算が尽きるか、何も入れずに済ませるかの両極端になりがちです。

宿題1　仕組みへの指示文に、制約を書き、秘密は書かない

提供者の対策の一つ目は、言語モデルに役割や答え方を事前に伝える指示文（システムプロンプト）で、不正な指示への耐性を上げることです。ガイドラインは、指示文に制約事項やセキュリティ上の注意事項を書き込み、意図しない出力をさせないようにするとしています。社内のチャットなら、答えてよい範囲、資料に根拠がない質問への返し方、内部の設定を尋ねられたときの断り方などが該当します。

同じ項目で、指示文には出力させたくない機密、たとえば接続用の鍵などを直接書かず、必要なときに参照できるよう別に管理することも重要だとしています。直接の指示の注入の図でも、開発段階の呼び名のような機微な情報が、指示文ごと引き出されてしまう例が描かれています。指示文は、いつか外に出るものとして書くのが前提です。

実務でよく見かける落とし穴は、試作の段階で便利だからと指示文に社内の連絡先や接続情報を書き込み、そのまま本番に持ち込むことです。指示文の中身を仕様書に全文で残し、機密が混ざっていないかを公開の前に人が読んで確かめる工程を入れておくと、この失敗は防げます。

宿題2　入口で、利用者の入力を検査する

二つ目は、言語モデルに渡す前の入力を検査することです。ガイドラインは、入力に意図しない出力をさせる不正な指示が含まれていないかを検証し、見つけた場合は一部を削って無害にする、あるいは処理を断るといった措置を取るとしています。この検査を担うのが、用語集で「ガードレール」と呼ばれる保護の仕組みです。本文では、モデルの外側に置く検査の仕組みをこの呼び名で指すと定義しています。

直接の指示の注入の例として、過去の指示を無効にさせる文、役を演じさせて不正な出力を引き出す文、特殊な文字の並びに指示を埋め込む文、別の作業に見せかけて内部の指示文を出させる文が挙げられています。入口の検査は、こうした型を見つけて止めるものですが、言い回しを変えればすり抜けられるため、入口の検査だけで守り切れるとは考えないことが前提です。

入口で処理を断ったときに、利用者へどう伝えるかも仕様に入れておくべき項目です。理由を詳しく返しすぎると、攻撃者に検査の癖を教えることになります。一方で社員が普通の質問で何度も断られれば、使われない仕組みになります。断った入力の記録を残し、誤って止めた例を定期的に人が見直す運用とセットで決めておきます。

宿題3　外から読ませる資料を、命令として扱わせない

三つ目は、言語モデルが答えの材料として読み込む外部の資料の検証です。ウェブサイトや外部のデータベースを参照するときは、そこに不正な指示が含まれていないかを検証し、見つけたら処理を断る。加えて、利用者の入力と外から読んだ資料をはっきり区別させ、読んだ資料には高い注意を払わせる、とガイドラインは書いています。

社内向けのチャットでも、この宿題は他人事ではありません。想定事例の一つ目では、社内の資料置き場のファイルを経由した間接の注入が攻撃の筋として示されています。社員なら誰でも書き込める共有の置き場を答えの材料にしている場合、その中の一つのファイルに仕込まれた文が、別の社員の質問への答えを書き換える入口になりえます。メールを読ませる仕組みなら、社外から届いた一通がそのまま入口です。

手を打つ順番としては、まず答えの材料にする置き場を棚卸しし、誰が書き込めるかを一覧にします。書き込める人が広い置き場ほど、読み込む前の検査を厚くするか、材料から外すかを検討します。材料から外す置き場の選び方は「社内AIに読ませない置き場の一覧」の記事で扱っています。

宿題4　出口で、出してはいけない情報を止める

四つ目は、言語モデルが作った答えを利用者に返す前の検査です。ガイドラインは、出力に出してはいけない情報が含まれていないかを検証し、見つけたら応答を断るとしています。入口と外から読む資料の検査をすり抜けた場合でも、最後に出口で止められれば被害は出ないため、多層で守る考え方の中で重要な位置を占めます。

出口の検査で見る対象は、仕組みごとに書き出しておく必要があります。社内向けのチャットなら、個人の連絡先や給与の数字、社外秘の印の付いた資料の本文、指示文の中身などが候補になります。外部向けなら、社内の情報が混ざっていないか、他社や個人を傷つける表現がないかも見ることになるでしょう。何を止めるかが決まっていない出口の検査は、形だけのものになります。

同じ項目では、単語の出現確率のように攻撃者に悪用されうる情報を、必要に応じて応答から外すことが、モデル抽出への対策になるとも書かれています。開発者向けの画面を社内に開いている場合などは、答えの本文以外に何を返しているかまで一度確かめておくと安心です。

宿題5　つなぐ仕組みの権限を最小にし、資料の参照権限を人に合わせる

五つ目は権限の管理です。ガイドラインは、言語モデルや連携する仕組みを操作する中継の部品（オーケストレータ）の権限を必要最小限にすることで、言語モデルが攻撃を受けた場合の被害の広がりを抑えるとしています。いわゆる最小権限の原則です。答えを作るだけの仕組みに、データを書き換えたり消したりできる権限を持たせない、というのが基本の形です。

もう一つ、検索用の資料と資料置き場への参照権限を、利用者や役割に応じて適切に設定することも挙げられています。社内向けのチャットが全社員に同じ資料を見せる作りになっていると、人事部の資料が営業部の社員の質問への答えに混ざる、といったことが起こりえます。想定事例の一つ目で、この権限管理が主な対策に数えられているのはこのためです。

権限をどう出し分けるかの設計には、探す前に絞る方法や探した後に落とす方法など複数の作り方があり、詳しくは「社内AIは誰にでも同じ答えを返してよい？」の記事で扱っています。ガイドラインの宿題として押さえておくべきなのは、権限を絞る対象が、人だけでなく仕組みの部品にもあるという点です。

宿題6　基本の対策｜記録・流量の制限・開発環境・部品の確認

ガイドラインは、言語モデルに特有の脅威への対応だけでなく、情報システムに一般に必要な基本の対策も欠かせないとしています。例として挙げているのは、監査のための記録を残して後から追えるようにすること、膨大なアクセスによる攻撃を抑える流量の制限、開発環境での開発者の権限の管理、仕組みを構成する部品の信頼性の確認の四つです。

記録については、用途や提供の条件によって、残してよいかどうかや、見られる人の範囲が変わると注記しています。社員の質問をすべて残せば事故の調査には役立ちますが、質問の中に個人の相談や人事の情報が含まれることもあります。何を何日残し、誰が見られるかは、情報システムと人事、法務が一緒に決める項目です。

部品の確認では、提供者は基盤モデルの作り手が開示している情報などを踏まえて信頼性を確かめることが重要だとしています。追加で学習させる場合は、学習データに出したくない機密を使わないこと、データの出どころや加工の履歴で信頼性を確かめることが重要になる場合もあるとしています。

見直しの時期については、基盤モデルが変わったとき、言語モデルが新たに学習したときなどが考えられるとし、一律の頻度は示せないとしています。そのうえで、費用との兼ね合いも考えながら、用途に応じて頻度と中身を決めるべきだとしています。借りているモデルの版が上がる通知を、見直しの合図として扱う決まりにしておくのが現実的です。

読み込みを社内で回す5つの手順

ここまでの宿題を、自社の仕組みに当てはめる手順にまとめます。ガイドラインは、提供しようとする仕組みに即して脅威と対策を具体的に検討できるよう想定事例を示した、と説明しています。つまり、自社の仕組みを事例と同じ形の図に描いてから読むのが、この文書の想定している読み方です。

手順の三で「分からない」が多く出るのは珍しくありません。特に外注で作った仕組みでは、入口と出口の検査がどこまで入っているかを発注側が把握していないことがよくあります。分からない項目を洗い出せたこと自体が、この読み込みの最初の成果です。

外注で作らせるときに、発注の文書に書く項目

社内向けのAIを外注で作らせる場合、ガイドラインの宿題は発注の文書と受け入れの基準に落とし込みます。作った会社に「ガイドラインに沿って作ってください」と一行で頼むだけでは、どこまで入れたかの確かめようがありません。項目ごとに、入れるか入れないかと、その確かめ方を書く形にします。

書く項目の候補は、指示文に機密を書かないことと指示文の全文の納品、入口と出口の検査の有無と止める対象、外から読む資料の検査と入力との区別の方法、中継の部品の権限の一覧、資料置き場の参照権限の出し分けの方法、記録の中身と保存期間、流量の制限の値、使う基盤モデルの名前と版、そして納品後に版が変わったときの連絡の方法です。

受け入れの段階では、想定事例に描かれた攻撃の筋を試す検証を求めることもできます。ガイドラインは、攻撃する側の視点で試す検証（レッドチーミング）によって脅威を特定し、対策の効き目を確かめることも重要だとしています。検証の進め方そのものは「AIをわざと攻撃して弱点を探す」の記事に譲りますが、誰が、いつ、何を試したかの報告を納品物に含めることは発注の文書に書いておけます。

対策を重ねても、残るリスクは消えない

ガイドラインは、対策の例を実装した場合でも、AIの性質上、脅威を生む要因を完全に取り除くことは難しいと明記しています。一つの対策だけで要因を取り除くのは難しいことを前提に、複数の対策を重ねてリスクを下げていく考え方を取っています。入口、外から読む資料、出口、権限の四か所に網を張るのは、どれか一つが破られても他で止めるためです。

残るリスクがあることを前提にすると、決めておくべきことが二つ出てきます。一つは、残ったリスクを誰が受け入れたかの記録です。もう一つは、破られたと気づいたときに仕組みを止める手段と、止める判断をする人です。この二つが決まっていない仕組みは、対策の数が多くても、事故のときに動けません。

法的な面では、ガイドラインは攻撃の法的な整理をする文書ではないと断ったうえで、対策を講じて秘密にしたいデータを適切に管理していれば、仕組みから漏れた場合でも、不正競争防止法の営業秘密の「秘密管理性」の要件を満たし、保護を受けられると考えられるとしています。ただし営業秘密として守られるには、有用性と非公知性の要件も必要だと注記しています。

また、ガイドラインはある脅威の責任を誰が負うかを決める趣旨のものではなく、各組織が自らの状況に応じて合理的な対策を選ぶための指針だとしています。どれを選ぶかは、読み手に委ねられているということです。

社内AIを作るときの確認項目一覧

ここまでの宿題を、仕様書や発注の文書との突き合わせに使える一覧にまとめます。各項目の右の列は、確かめるときに見る物です。

区分	確認項目	確かめるときに見る物
範囲	仕組みが大規模言語モデルを組み込んだものか、自律的に動くエージェントを含むか	仕組みの図・機能の一覧
立場	自社が提供者に当たるか、外注先との役割の分け方	契約書・発注の文書
優先順位	影響の大きさと起こりやすさを書き出したか	脅威の書き出し表
指示文	制約事項を書いたか、鍵や連絡先などの機密を書いていないか	指示文の全文
入口	入力の検査の有無、断ったときの返し方と記録	検査の設定・断った記録
外から読む資料	資料置き場や外部の情報の検査、入力との区別、書き込める人の範囲	置き場の一覧・書き込み権限
出口	止める情報の一覧があるか、止めたときの返し方	止める対象の一覧
権限	中継の部品の権限が最小か、資料の参照権限が人と役割に合っているか	権限の一覧
基本の対策	記録の中身と保存期間と閲覧者、流量の制限、開発環境の権限	記録の設定・運用の決まり
部品	基盤モデルの名前と版、開示情報の確認、学習データの出どころ	部品の一覧
検証と見直し	攻撃を試す検証の報告、版の変更を合図にした見直し	検証の報告書・見直しの記録
残るリスク	受け入れた項目と承認者、止める手段と止める判断者	受け入れの記録

すべての欄を最初から埋める必要はありません。まずは空欄を空欄として見える形にし、次の改修で入れるか、受け入れるかを決めていきます。

やりがちな読み違いと、AIに決めさせない範囲

ガイドラインを社内に取り込む場面で、よく見られる読み違いを挙げておきます。

• 利用者向けの注意集だと考え、社員に回覧して終わりにする
• 開発会社ではないから関係ないと考え、外注で作った社内のチャットを点検しない
• 対策の一覧を全部同じ強さで入れようとして、予算と時間が尽きる
• 入口の検査を入れたことで安心し、出口の検査と権限の絞り込みを省く
• エージェントも対象に含まれると思い込み、固有の危なさを洗い出さない

読み込みの作業では、AIを手伝いに使うと手早く進みます。ガイドラインの本文から項目を抜き出させる、自社の仕様書と突き合わせて空欄の候補を挙げさせる、といった下書きです。ただし、AIには判断をさせず、挙げた候補ごとに本文の章と仕様書の該当箇所を根拠として書かせます。根拠のない候補は捨てるか、人が本文に当たって確かめます。

反対に、AIに任せないのは、どの対策を採るか、どの脅威を後回しにするか、何を残るリスクとして受け入れるかの判断です。人が確認する範囲を、優先順位の書き出し、止める情報の一覧、受け入れの承認の三つと先に決めておくと、下書きの結果に引きずられません。宿題を片付けるのは、仕組みを使わせている会社の人です。

まとめ

総務省が2026年3月27日に公表した「AIのセキュリティ確保のための技術的対策に係るガイドライン」は、大規模言語モデルを組み込んだ仕組みを開発・提供する側に向けた技術的対策の文書で、社員向けの注意集ではありません。社内向けのAIを自社で作る会社、外注で作らせる会社は、自分を提供者として読む必要があります。主な脅威は指示の注入とサービス拒否で、提供者の宿題は、指示文に制約を書いて機密を書かないこと、入口の検査、外から読む資料の検査と区別、出口の検査、中継の部品の最小権限と資料の参照権限の出し分け、そして記録や流量の制限などの基本の対策です。自律的に動くエージェントは対象外とされている点にも注意が要ります。対策を重ねても要因は消えないため、優先順位の書き出し、残るリスクの受け入れ、止める手段を人が決めて記録します。AIには本文の抜き出しと仕様書との突き合わせの下書きを任せ、根拠を書かせ、判断は人が持ちます。まずは自社の社内向けAIの仕組みを一枚の図に描き、想定事例と見比べるところから始めてください。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。