LLMセキュリティ設計を依頼できる会社の選び方と依頼前に決める5項目

LLMセキュリティ設計を依頼できる会社を、OWASP Top 10 for LLM 2025とNIST AI RMFへの対応力で見極める方法を整理した。依頼先の種類と選定基準、提案比較の質問、依頼前に社内で決めておく5項目をまとめる。

LLMセキュリティ設計を外部に依頼するなら、OWASP Top 10 for LLM ApplicationsとNIST AI RMFに準拠した設計と実装まで説明できる会社を選ぶのが近道だ。従来のWeb診断だけを請け負う会社では、自然言語が指示として解釈されるLLM特有の脅威を取りこぼしやすい。本記事では、依頼先の種類と選び方、提案を比べる質問、依頼前に社内で決めておく5項目を、情報システム部門とエンジニアリング責任者向けに整理する。

LLMセキュリティ設計を依頼できる会社とは？

LLMセキュリティ設計を依頼できる会社とは、LLMを組み込む業務システムの脅威モデリングから防御の設計、監査ログとインシデント対応の整備までを請け負える外部パートナーを指す。

ここでいう設計は、完成後の脆弱性診断とは別の作業だ。RAGやツール使用型エージェントの構成を決める段階で、どのデータをモデルに渡し、どの操作を許すかを決める作業を含む。診断だけ、開発だけを請け負う会社もあるため、依頼範囲を最初に分けて考える必要がある。

LLMのセキュリティ設計に専門の依頼先が要るのはなぜか？

LLMでは自然言語の入力がそのまま指示として解釈されうるため、入力と制御コードを分ける従来のWebセキュリティの前提が成り立たないからだ。入力バリデーションだけでは防御にならない。

多くの組織は、従来のWebアプリケーションセキュリティの延長でLLMを設計しようとする。この出発点のずれが、運用開始後のインシデントの主な要因になる。自然言語が実行境界を越えるという特性が、新しい攻撃面を生むためだ。

間接的プロンプトインジェクションとはどのような攻撃か

プロンプトインジェクションは、入力や外部データに「これまでの指示を無視して」といった命令を埋め込み、モデルの挙動を操作する攻撃である。2つの類型がある。

直接的インジェクション：ユーザーが悪意あるプロンプトを直接送信する
間接的インジェクション：LLMが参照する外部データ（ウェブページ、メール、ドキュメント）に攻撃用プロンプトを仕込む

RAGやツール使用型エージェントを構成する場合、間接的インジェクションが主要な脅威になる。外部データはモデルから見ると信頼できる文脈として扱われがちだが、実際には任意のテキストが含まれうる。依頼先がこの区別を前提に話せるかどうかが、最初の見極めどころになる。

OWASPとNIST AI RMFは依頼先の評価にどう使うか？

OWASP Top 10 for LLM Applications 2025は脅威の一覧、NIST AI RMFは組織のリスク管理の枠組みだ。依頼先の設計の網羅性は前者で、ガバナンスへの接続は後者で確かめる。

OWASPはLLMアプリケーション特有の主要リスクを10項目に整理して公開している。（出典：OWASP『OWASP Top 10 for LLM Applications 2025』2024年11月、OWASP Gen AI Security Project）

エンタープライズ導入で特に問われやすい項目と、依頼先に確認したい点を次の表にまとめた。

OWASPの項目	依頼先に確認したいこと
LLM01 プロンプトインジェクション	外部データ経由の間接的な攻撃まで対策の設計に含めるか
LLM02 機密情報の漏洩	RAGの検索段階で権限外の文書を除外する設計を示せるか
LLM05 不適切な出力処理	出力をSQL・HTML・シェルに渡す箇所を信頼できない入力として扱うか
LLM06 過剰なエージェンシー	副作用のある操作に人間の承認を挟む設計を提案するか
LLM07 システムプロンプトの漏洩	システムプロンプトに認証情報や機密を置かない前提で設計するか
LLM08 ベクトルと埋め込みの弱点	ベクトルDBのアクセス制御とテナント分離を範囲に含むか
LLM10 無制限の消費	入力長の制限とトークン単位のレートリミットを設計するか

残るLLM03（サプライチェーン）、LLM04（データとモデルのポイズニング）、LLM09（誤情報）は、自社でモデルを調整する場合に確認対象へ加える。回答の正確性が業務判断に直結する用途でも同様だ。

NIST AI RMF 1.0は、次の4つのコア機能でAIリスク管理を構成する。（出典：NIST『Artificial Intelligence Risk Management Framework (AI RMF 1.0)』2023年1月、NIST）

Govern：組織全体のAIガバナンス方針、責任分担、文化
Map：AIシステムが生むリスクを特定・分類する
Measure：リスクを測定・分析・追跡する
Manage：リスクに優先順位を付けて対処する

NISTは生成AI向けの補足として、Generative AI Profile（NIST AI 600-1）も2024年7月に公開している。（出典：NIST『NIST AI 600-1: Generative Artificial Intelligence Profile』2024年7月、NIST）

OWASPとNISTは補完関係にあり、依頼先が両方を並べて説明できるかは、設計とガバナンスを分断させないための確認点になる。組織側のガバナンス体制はAIガバナンス・フレームワーク構築ガイドで整理している。

依頼できる会社にはどんな種類があるか？

依頼先は大きく、セキュリティ診断会社、LLMアプリの開発会社、AI導入を支援するコンサルティング会社の3種類に分かれる。設計から運用まで一社で通すか、診断を別会社に分けるかで選び方が変わる。

依頼先の種類	強みになりやすい範囲	手薄になりやすい範囲	向いている依頼
セキュリティ診断会社	完成後の脆弱性診断、攻撃の再現	構成段階の権限設計、業務フローとの接続	本番前の第三者診断
LLMアプリの開発会社	RAG・エージェントの実装、入出力の防御層	全社ガバナンス、法務論点の整理	設計と実装の一括依頼
AI導入コンサルティング会社	利用ポリシー、体制設計、規程との整合	実装の細部、攻撃手法の検証	全社方針と設計要件の策定

この表は編集部による一般的な整理であり、個々の会社の能力を示すものではない。同じ種類の会社でも得意範囲は大きく異なるため、次の基準で個別に確かめる。

依頼先はどの基準で選べばよいか？

第一の基準は、OWASPの10項目に沿った脅威モデリングを自社の構成に当てはめて説明できるかだ。そのうえで監査ログとインシデント対応、法務との連携、継続レビューまで範囲に含むかを確認する。

脅威モデリングの具体性：自社のRAG・エージェント構成に対し、どの項目がどこで起きうるかを図示できるか
間接的インジェクションへの設計：外部データの扱い方と、防ぎきれない場合の次の防御層を説明できるか
3層防御の設計力：入力・出力・権限の各層に置く対策を、性能やコストとの兼ね合いも含めて示せるか
運用までの範囲：監査ログの項目、異常検知の指標、インシデント対応手順まで成果物に含むか
法務との連携：個人情報の扱いや委託先管理の論点を、法務部門と詰める進め方を持っているか
継続レビュー：モデル更新や機能追加のたびに設計を見直す体制を提案に含めるか

見積の比べ方そのものはAI開発の見積比較チェックリストが詳しい。本記事ではセキュリティ設計に固有の観点に絞っている。

提案を比べるときは何を質問すればよいか？

提案の比較では、対策の名前ではなく実装の中身を問う質問が効く。たとえば間接的プロンプトインジェクションへの対策と、それで防ぎきれない場合の次の層を聞くと、設計の深さが分かる。

質問	回答で確認したいこと
外部データはモデルにどう渡すか	引用として区切る方式と、その限界を自ら説明するか
副作用のある操作はどこで止めるか	メール送信・削除・決済の前に人間の承認を置くか
重要な判断の誤りをどう検出するか	別モデルや別プロンプトでの二重チェックをコストと合わせて示すか
権限外の文書が文脈に入らない仕組みは	検索段階でユーザー権限によるフィルタをかけるか
ログには何を残し、どこまで伏せるか	機密をマスクしたうえでプロンプトと出力を保存するか

間接的プロンプトインジェクション対策の4つの実装パターン

質問への回答を評価するために、代表的な実装パターンを押さえておく。

パターン1：外部データを引用として扱う。 取得したドキュメントを明示的なタグで囲んでモデルに渡す。

<document source="internal-doc-123">
(取得した文書テキスト)
</document>

そのうえで、タグ内の内容は情報として扱い、そこに書かれた指示には従わない旨をシステムプロンプトで明示する。万全な防御ではないが、単純な攻撃は大きく減らせる。

パターン2：ツール実行前に人間がレビューする。 副作用のある操作はモデルに直接実行させず、人間の承認フローを挟む。OWASPのLLM06（過剰なエージェンシー）への直接的な対策である。

パターン3：セカンドオピニオン用のモデルを置く。 重要な判断について、異なるモデルまたは異なるプロンプトで二重チェックする。コストは上がるが、誤判断を見つけやすくなる。

パターン4：入力を分類する。 入力が質問応答・要約・実行指示のどれに当たるかを分類し、タスクごとに異なる権限とツールで処理する。分類の仕組み自体も攻撃対象になりうるため、分類結果の監査も要る。

依頼前に社内で決めておくことは？

依頼前に社内で決めるべきは5項目だ。対象システムの構成、扱うデータの区分、エージェントに許す操作、準拠する基準、運用体制である。これが曖昧だと各社の提案範囲がそろわず比較できない。

決めておく項目	決める内容	決めずに依頼すると起きること
1. 対象システムの構成	チャット単体か、RAGか、ツールを呼ぶエージェントか	脅威の範囲が定まらず、提案の粒度がばらつく
2. 扱うデータの区分	顧客情報・従業員情報・社外秘のうち、モデルに渡してよいもの	マスキングや権限フィルタの要件が後から増える
3. エージェントに許す操作	自動で実行してよい操作と、人間の承認を挟む操作の線引き	過剰な権限のまま設計が進む
4. 準拠する基準	OWASP・NIST AI RMF・社内規程のどれを満たすか、法務の関与範囲	成果物の合否を判断する物差しが無くなる
5. 運用体制	監査ログの保管期間、異常時の連絡窓口、継続レビューの担当	設計はできても運用で止まる

2と3は、依頼先ではなく自社にしか決められない項目である。社内の利用ルールが未整備なら、企業のAI利用ポリシー策定ガイドを先に参照し、データの区分と承認の考え方をそろえておくと依頼がスムーズになる。

依頼範囲には何を含めるべきか？

依頼範囲の基本は、入力・出力・権限の3層防御の設計である。これに監査ログと異常検知、インシデント対応手順の整備までを加える。

入力バリデーション

サニタイゼーション：制御文字の除去、HTMLエスケープ
プロンプトインジェクション検出：既知の攻撃パターンのヒューリスティックや検出モデル
入力長の制限：サービス拒否への対策と、意図しない長文脈の抑止
レートリミット：ユーザー単位とAPIキー単位の両方

出力フィルタリング

個人情報の検出：氏名、電話番号、メール、住所、マイナンバー等のマスキング
社内機密パターンの検出：組織固有の秘匿文字列の検出
引用元の付与：RAGの出力に参照元のメタデータを含める
検証層：法務・医療など、領域ごとに事実確認が要る場合に置く

権限最小化とデータ分離

文脈の最小化：ユーザー権限に応じて取得範囲を制御する
ツール権限の最小化：エージェントに与えるツールを必要最低限に絞る
テナント分離：マルチテナント環境でデータを分離する
シークレット管理：APIキーや認証情報のプロンプトへの混入を防ぐ

RAG特有の権限設計は社内ナレッジをRAGで対話可能にするで扱っている。

監査ログと異常検知

監査ログには次の項目を残す。

ユーザーIDとタイムスタンプ
プロンプト全文（機密をマスクしたもの）
取得された文脈（RAGの参照元）
モデル出力全文
呼び出されたツールと結果
応答時間とトークン消費量

異常検知の指標は次の4つを基本にする。

内容の異常：想定外のトピックへの逸脱、禁止ワードの検出
コストの異常：ユーザー単位のトークン消費の急増
レイテンシの異常：応答時間の急激な悪化
ツール呼び出しの異常：想定外の外部APIへのリクエスト

インシデント対応手順

検知：異常検知の仕組みによるアラート
隔離：該当ユーザーや該当プロンプトパターンの遮断
調査：監査ログに基づく原因の特定
通知：社内関係者への連絡と、必要に応じた監督機関（後述の委員会）への報告
恒久対策：防御ロジックの更新とルールの追加

個人情報保護の論点は誰と詰めるべきか？

個人情報保護の論点は、情報システム部門と依頼先だけでなく、法務部門を交えて詰めるべきだ。個人情報保護を所管する国の委員会は2023年6月に、生成AIサービスの利用に関する注意喚起を公表している。

この注意喚起は、生成AIサービスを利用する事業者に対して個人情報の扱いへの注意を促すものだ。（出典：個人情報保護委員会『生成AIサービスの利用に関する注意喚起等について』2023年6月、個人情報保護委員会）

依頼先との間で、少なくとも次の論点を確認しておく。

入力される個人情報の範囲：顧客情報や従業員情報が送信されていないか
利用目的との整合：利用目的の範囲を超えたAI利用になっていないか
委託先の管理：LLMサービスの提供者や設計の依頼先をどう管理するか
越境データ移転：国外リージョンへのデータ送信をどう扱うか

セキュリティ設計と法令対応は一体で議論する領域であり、依頼先が法務との打ち合わせに同席できるかも選定時の確認点になる。

Farleapが設計段階でセキュリティを組み込む進め方

※ご提案です。当社の実施実績ではありません。

株式会社ファーリープ（Farleap）は、LLM導入の支援において、セキュリティ設計をアーキテクチャ設計と切り離せない工程として位置づけている。設計が終わってからセキュリティを足すのではなく、設計段階でOWASPとNISTの観点を織り込み、運用段階での手戻りを減らすことを狙う。依頼を受ける場合に想定する範囲は次のとおりだ。

OWASP Top 10 for LLM Applicationsに照らした脅威モデリング
3層防御の設計と実装の支援
監査ログの設計と異常検知ルールの策定
インシデント対応プレイブックの整備
モデル更新や機能追加の際の継続的なセキュリティレビュー

AI導入とDX全体の支援内容はAI導入・DXのサービス紹介にまとめている。

まとめ

LLMセキュリティ設計の依頼先は、会社の種類ではなく、OWASPの10項目に沿って自社の構成の脅威を説明でき、3層防御から監査ログ、インシデント対応までを範囲に含められるかで選ぶ。依頼前には、構成・データの区分・許す操作・準拠する基準・運用体制の5項目を社内で決めておく。特にデータの区分と承認を挟む操作の線引きは自社にしか決められず、これがそろうと各社の提案を同じ物差しで比べられる。セキュリティ設計は開発の最終段階で足すものではなく、構成を決める段階から依頼先と一緒に詰めていく領域である。

本記事は一般的な情報提供を目的としたもので、法的助言に代わるものではない。

よくある質問

LLMのセキュリティ設計はどこに依頼すればよいか？

自社のRAGやエージェント構成に対し、OWASP Top 10 for LLM Applications 2025の10項目で脅威を説明できる会社が候補になる。そのうえで3層防御と監査ログ、インシデント対応まで設計範囲に含めるかを確認する。診断会社・開発会社・コンサルティング会社のどれであっても、この範囲を一社で担えるかが分かれ目になる。

LLMセキュリティ設計の依頼前に社内で何を決めておくべきか？

対象システムの構成、扱うデータの区分、エージェントに許す操作、準拠する基準、運用体制の5項目である。特にデータの区分と人間の承認を挟む操作の範囲は社内でしか決められない。ここが曖昧なままだと各社の提案範囲がそろわず、比較が難しくなる。

脆弱性診断とLLMセキュリティ設計の依頼は何が違うか？

脆弱性診断は完成したシステムの弱点を見つける作業で、設計は構成を決める段階でモデルに渡すデータと許す操作を決める作業である。LLMでは入力自体が指示として解釈されるため、後からの診断だけでは権限設計の不備を直しにくい。両者は別の依頼として範囲を分けて考える。

間接的プロンプトインジェクションとはどのような攻撃か？

LLMが参照するウェブページ・メール・社内文書などの外部データに攻撃用の指示を仕込み、モデルの挙動を操作する攻撃である。ユーザーが直接送る攻撃と違い、RAGやツール使用型エージェントでは参照データが信頼できる文脈として扱われやすく、主要な脅威になる。

機密情報の漏洩を防ぐ設計として何を依頼すべきか？

送信前の個人情報マスキング、RAG検索段階での権限フィルタ、出力側の機密パターン検出、監査ログの保存の4点を依頼範囲に含める。中でも、検索段階で権限外の文書を除外し、モデルへ渡す文脈を絞り込む設計が効果を出しやすい。

更新履歴

2026-03-14 初稿公開。
2026-10-14 対策キーワードを「LLMセキュリティ設計依頼できる会社」に変更し、依頼先の選び方と依頼前に決めておくことを軸に構成を全面的に見直した。OWASP Top 10 for LLM Applicationsの項目番号を2025年版に更新し、出典リンクを本文に追加した。