- 公開日
セキュリティを説明するときは、まず何が起きて誰に影響するかを示し、次に原因となる仕組みと防御する位置を結びます。最後に、実害を避けるための確認条件と、その確認では分からない範囲を添えます。具体性を増すために、制約を突破する文言や手順を追加する必要はありません。読者が守る対象と次の行動を判断できる情報を選びます。
症状は観測できる形で書く
「AIには攻撃の危険があります」だけでは、読者は自分の業務の何を見ればよいか分かりません。「見積書の要約を頼んだのに、資料とは無関係な送信処理が要求された」と書けば、依頼した処理と逸脱した処理を比較できます。続けて、送信先や内容の確認なしに実行すると、意図しない情報提供につながる可能性を説明します。
ただし、症状と原因は分けます。意図しない出力が一度現れたことだけで、攻撃が成功した、情報が漏れた、特定の防御が無効だったとは断定できません。資料内の指示、依頼の曖昧さ、ツール設定などを調べる前は、原因候補として扱います。送信要求が生成されたことと、実際に送信されたことも別の観測です。
記事では、依頼、参照資料、出力、実行記録のうち何を確認できたかを示します。実行記録がないなら「送信は未確認」と記し、画面に警告が出たことだけで「流出を防げた」と結論しません。症状を正確に限定すると、読者に必要な調査や防御の説明が自然に続きます。
仕組みは越えてはいけない境界で説明する
Prompt Injection（プロンプトインジェクション）は、入力された内容によってAIの振る舞いを意図しない方向へ変える問題です。外部のWebページやファイルを介する経路もあります。OWASPのLLM01:2025 Prompt Injectionは、外部資料による間接的な入力と、権限の制限、外部内容の分離などの対策を説明しています。
この仕組みを伝えるときは、「悪い文章がAIをだます」で終えず、資料を読む権限と、資料中の指示を実行する権限が違うことを示します。見積書には金額や納期を読む価値がありますが、見積書の作成者がAIに社内データの送信を許可できるわけではありません。
信頼境界とは、このように、出所や権限が異なる情報・処理を区別する境目です。防御の説明では、資料を依頼と区別して渡すことに加え、要約だけを行う処理に送信権限を与えない、と具体的な位置を示します。OWASPのLLM Prompt Injection Prevention Cheat Sheetも、文字のラベルや指示の書き方を強制の境界として扱わず、ツール呼び出しを利用者の権限やセッションの状況と照らして検証するよう勧めています。文章の解釈を助ける指示と、操作を実際に止める制限は、同じものとして書きません。
OWASPは、確実に防ぎ切る予防方法があるかは明らかでないとしています。記事でも、「この一文を加えれば安全」と約束せず、入力の扱い、実行権限、出力の照合がそれぞれ何を受け持つかを説明します。防御策を列挙するより、どの逸脱をどこで抑えるかを一つずつ対応させる方が、読者は設計へ戻しやすくなります。
同じ材料で抽象的な説明を書き直す
架空の場面として、担当者がAIへ「見積書から金額と納期を要約して」と依頼したとします。資料には「見積額は3万円、納期は発注確定後5営業日」とあり、末尾には要約と無関係な外部送信を求める記載があります。公開記事では、その記載が求める操作の種類を説明し、突破を狙う具体的な文言は載せない形にします。
抽象的な説明は、例えば次のようになります。
不審な指示には注意が必要です。入力を適切に管理し、安全性を高めましょう。
この文章は方向性を述べていますが、不審と判断する根拠、正当な要約を続けてよいか、何を止めるかが分かりません。同じ情報を使い、説明を次のようにつなげられます。
依頼は金額と納期の要約ですが、見積書の末尾には外部送信を求める記載があります。資料中の文は利用者の操作依頼ではないため、送信の根拠として扱いません。要約処理には送信機能を付与せず、金額と納期は元の見積書と照合します。確認例では、要約が保たれることと、送信処理へ進まないことを別々に確かめます。
編集後は、症状、権限の違い、防御位置、確認対象が分かります。新しい攻撃文を足したのではなく、すでにある情報と操作の関係を具体化しています。なお、これは説明文の比較であり、モデルへ入力して性能を測った結果ではありません。
この例で期待する要約は、「見積額は3万円、納期は発注確定後5営業日と記載」です。「5日後に納品」と変えると、営業日と暦日、起点の条件が失われます。セキュリティの説明に集中していても、正当な業務内容の精度を落としてよいわけではありません。
確認例は防御の期待動作を示す
公開記事で確認例を示すなら、試験対象の所有者が許可した範囲を決め、実在の機密情報や送信先を使わない条件を先に書きます。NISTのSP 800-115は、セキュリティ試験の評価計画の作成（6.5節）や、試験の取り決めを文書にするRules of Engagementのテンプレート（付録B）を扱っています。2008年の一般的なセキュリティ試験の指針であり、ここでは事前に計画と許可を整える考え方の参考にするだけで、現在のLLM防御性能の根拠にはしません。確認例でも、対象、許可する活動、行わない活動、問題が起きたときの連絡先を、試験を始める前に決めておきます。
見積書の例なら、外部に接続しない模擬環境と架空資料を使い、送信機能が呼ばれたかだけを記録する代替処理を用意する設計が考えられます。代替処理は外部へ何も届けず、本番の認証情報も持ちません。資料内の操作要求は無害化した表現で示し、隠し方や検知をすり抜ける工夫を試す手順は公開例に含めません。
確認したい内容は、次の三つに分けます。
| 確認すること | 期待する状態 | 合わない・確認できない場合 |
|---|---|---|
| 資料中の操作要求を認識したか | 依頼とは異なる内容として区別される | 入力の渡し方や検知の条件を調べる。未観測なら検知成功としない |
| 許可されない操作を止めたか | 外部送信が起きず、許可されない呼び出しは実行側でも拒否される | 実行経路と権限を見直し、確認できるまで該当機能の利用を保留する |
| 正当な要約を保ったか | 金額・納期・条件が原文どおりに残る | 原資料照合と、停止範囲の見直しを行う |
これは試験計画の例で、結果を記入した表ではありません。実施する場合は、対象版、設定、入力、期待結果、実際の観測を分けて残します。送信機能が最初から存在しない構成なら、呼び出しの拒否試験と同じ意味にはなりません。何を備えた構成の、どの境界を確認したのかを示します。
警告が出ても送信されていれば、検知はできても実行阻止は失敗しています。指示を正しく認識した後に要約まで止まった場合は、検知の誤りではなく、止める範囲が広すぎる過剰な停止です。一方、操作要求のない通常の見積書にも警告が出るなら、誤検知として別に記録します。すべてを「安全に動いた／動かなかった」の一項目へまとめると、直す場所が分からなくなります。
公開する具体性と残す限界を選ぶ
公開原稿に必要なのは、対象業務、入力の種類、越えてはいけない権限、防御位置、期待結果です。秘密情報、実在する攻撃対象、認証情報、突破を再現しやすくする細かな調整を含めなくても、これらは説明できます。伏せた箇所がある場合も、読者の判断に必要な条件まで消さないようにします。
例えば「危険なので詳細は省きます」だけでは、防御を選べません。「外部資料に操作要求が含まれる条件を扱い、具体的な突破文は省く。確認するのは資料と依頼の区別、操作の阻止、要約の継続」と説明すれば、読者は記事の射程を把握できます。専門担当者への修正依頼には追加情報が必要なこともありますが、一般公開の文章とは共有範囲を分けて扱います。
無害化した一例が期待どおりでも、別形式のファイル、画像、長い会話、異なる権限設定で同じ結果になるとは限りません。逆に、模擬例の条件を絞り過ぎると、実運用で問題になる経路を確認できないこともあります。記事では確認した条件と未確認の経路を示し、追加の試験を行う判断を許可された担当者へつなぎます。
書く前には、次の項目を本文で説明できているかを確かめます。
| 項目 | 本文で説明すること | 見積書の例 |
|---|---|---|
| 症状 | 利用者に見える逸脱と影響 | 要約の依頼で、資料と無関係な送信処理が要求される |
| 境界 | どの情報が、どの権限で扱われると失敗か | 見積書の末尾の記載が、利用者の操作依頼として扱われる |
| 防御の位置 | どこで止めるか | 資料と依頼を区別し、要約処理に送信権限を与えない |
| 確認方法 | 何を見れば働いたと分かるか | 要約の正確さと、送信処理へ進まないことを別々に確かめる |
| 構成の前提 | 機能が接続されているか | 送信機能が未接続なら「拒否した」ではなく「接続されていない」と書く |
| 公開の範囲 | 読者と目的に合う詳しさ | 突破を狙う文言や再現性の高い手順は載せない |
仕上げでは、読者が「何を見て異常に気付き、どの仕組みを確認し、どこを直すか」を文章だけで追えるかを確かめます。追えない箇所には、突破手順ではなく、主体、対象、権限、期待結果のうち欠けている情報を補います。これが、具体性と安全性を両立させる編集の出発点です。
基本から確認する：この記事の前提になる考え方は、「AIエージェントの安全設計（権限・外部資料・承認・検証の基本）」にまとめています。
