Hello there, ('ω')ノ
LLM01：Prompt Injection
対応するプロンプト対策
- ② ユーザー入力とシステム指示を混ぜない
- ③ 外部データはすべて敵として扱う
- ⑥ 「できないこと」を明示的に書く
- ⑧ 会話履歴を信用しすぎない
なぜ対応するのか
Prompt Injection は 「指示の優先順位を誤認させる攻撃」。 プロンプト構造が曖昧だと、攻撃は“仕様どおり”成功します。
経営・設計判断
- プロンプトは 入力UIではなく実行ロジック
- WebのSQL Injectionと同じレベルで設計レビュー対象にする
LLM02：Insecure Output Handling
対応するプロンプト対策
- ⑤ 出力も信用しない
- ⑦ 自己検証（Self-Check）をさせる
なぜ対応するのか
LLMの出力がそのまま
- HTML
- JSON
- コマンド
- APIリクエスト
として使われると、出力＝コード実行になります。
経営・設計判断
- 「AIが出したから安全」は通用しない
- 出力検証は WAFやサニタイズと同列の必須要件
LLM03：Training Data Poisoning
対応するプロンプト対策
- ③ 外部データはすべて敵
- ⑧ 会話履歴のリセット・分離
- ⑩ 侵入前提設計
なぜ対応するのか
RAGや継続学習があると、 攻撃者は「未来の回答」を汚染できる。
経営・設計判断
- 学習データは資産であり攻撃面
- データの出どころ・更新フローをガバナンス対象にする
LLM04：Model Denial of Service
対応するプロンプト対策
- ④ プロンプトを固定文字列だと思わない
- ⑩ 完璧防御を前提にしない
なぜ対応するのか
- トークン浪費
- 無限思考誘導
- 再帰的自己評価
などで 計算資源を枯渇させられます。
経営・設計判断
- LLMは「CPUを直接燃やせるAPI」
- 利用制限・検知・遮断が必須
LLM05：Supply Chain Vulnerabilities
対応するプロンプト対策
- ③ 外部データはすべて敵
- ① システムプロンプトを秘密情報として扱う
なぜ対応するのか
- プラグイン
- MCP / Tool
- 外部API
- OSS Prompt
が 間接プロンプトインジェクション経路になる。
経営・設計判断
- 「LLMが読むもの」＝サプライチェーン
- ベンダー評価に AI連携を含める
LLM06：Sensitive Information Disclosure
対応するプロンプト対策
- ① システムプロンプトを秘匿
- ⑤ 出力検証
- ⑥ 明示的な禁止ルール
なぜ対応するのか
LLMは「知っていること」を 聞かれたら答える設計。
経営・設計判断
- データ分類（機密／非機密）をプロンプトに反映
- 人に教えてはいけないことはAIにも教えない
LLM07：Insecure Plugin Design
対応するプロンプト対策
- ② 構造分離
- ⑨ 権限概念を持ち込む
- ⑤ 出力検証
なぜ対応するのか
LLMが「APIを呼べる」ということは 自然言語で権限操作ができるという意味。
経営・設計判断
- プラグインは「管理者API」扱い
- 最小権限・明示的許可が必須
LLM08：Excessive Agency
対応するプロンプト対策
- ⑨ 権限分離
- ⑦ 自己検証
- ⑩ 侵入前提
なぜ対応するのか
LLMに「考えて行動させすぎる」と、 意図しない判断・実行が起きる。
経営・設計判断
- AIに裁量を与える＝責任を与える
- 人間の承認ポイントを設ける
LLM09：Overreliance on LLMs
対応するプロンプト対策
- ⑤ 出力を信用しない
- ⑦ 検証フロー
- ⑩ Assume Breach
なぜ対応するのか
AIはそれっぽく間違える。
経営・設計判断
- AIは「判断支援」であって「最終責任者」ではない
- 意思決定の分離が重要
LLM10：Improper Error Handling & Logging
対応するプロンプト対策
- ① プロンプト秘匿
- ⑩ ログ・検知・対応
なぜ対応するのか
エラーやログから
- システムプロンプト
- 内部ルール
- セーフティ条件
が漏れると 攻撃設計図を与える。
経営・設計判断
- エラーメッセージは「攻撃者向け資料」
- AIログは通常ログより厳格に管理
Best regards, (^^ゞ
