システムプロンプトがコンプライアンス管理策にならない理由

組織が規制対象データのワークフローにAIエージェントを導入する際、最も一般的なガバナンス手法は、よく設計されたシステムプロンプトです。モデルに特定のデータカテゴリへアクセスしないよう指示したり、定められた範囲内にとどまるよう命じたり、特定のリクエストを拒否するよう設定します。多くのセキュリティやコンプライアンスチームにとって、これはガバナンスのように感じられます――文書化され、レビュー可能で、テスト時にエージェントの挙動を目に見えて制限します。

しかし、これはコンプライアンスコントロールではありません。単なる指示です。この違いは非常に重要です。なぜなら、HIPAA監査人、CMMC評価者、SEC検査官がAIエージェントの導入を審査する際、彼らが評価するのは「モデルに何を指示したか」ではなく、「データ層で技術的に何が許可されなかったか」だからです。これは本質的に異なるものであり、そのギャップこそが、規制対象企業に大規模なコンプライアンスリスクを蓄積させています。

本記事では、システムプロンプトがコンプライアンスコントロールとして機能しない技術的理由、規制環境で生じる失敗パターン、規制当局がアクセス制御の証拠として実際に求めているもの、そしてAIエージェントによる規制対象データアクセスにおいて、データ層ガバナンスだけが防御可能なコンプライアンスを実現する唯一のアーキテクチャである理由を解説します。

要約

主なポイント：システムプロンプト、AIガードレール、モデルのファインチューニング、安全フィルターはすべてモデル層で動作します。これらは通常時のモデル挙動を制限しますが、データアクセスを防止できず、監査で証明可能な証拠も生み出せず、規制当局や評価者、攻撃者が想定する攻撃経路にも耐えられません。モデル、プロンプト、エージェントフレームワークとは独立してデータ層で強制されるガバナンスだけが、HIPAA、CMMC、SEC、PCI DSS、SOXの要件を満たすアクセス制御となります。

なぜ重要なのか：システムプロンプトやガードレールを設定しているからAI導入はガバナンスされていると考えている組織は、気付かぬうちにコンプライアンスリスクを抱えています。モデル層だけでガバナンスされているAIエージェントによる規制対象データへのアクセスは、認証記録、アクセス方針の文書、改ざん検知可能な監査証跡を生み出せません。監査時に「モデルに指示した」はコントロールの証拠ではなく、仮定の証拠に過ぎません。

主なポイント

1. システムプロンプトは指示であり、コントロールではない。指示はモデルに何をすべきか伝えるものです。コントロールは、モデルへの指示や判断に関わらず、不正な行為を防止します。「この診療以外の患者記録にはアクセスしない」というシステムプロンプトは、サービスアカウントが到達できる患者記録へのクエリを技術的に防ぐものではありません。モデルが従う行動指針を示すだけであり、何かに上書きされれば無効化されます。
2. システムプロンプトはプロンプトインジェクションで回避可能――これは構造的な脆弱性であり、設定の問題ではありません。プロンプトインジェクションは、AIエージェントが読むコンテンツ内に攻撃者が指示を埋め込み、元のシステムプロンプトを上書き・補完する手法です。2026年2月、ハーバード、MIT、スタンフォード、カーネギーメロンなどの研究者によるレッドチーム調査では、本番環境でエージェントがモデル層ガードレールを回避し、OWASP Top 10 for LLM Applicationsの5つの失敗事例が特定されました。これは理論上のリスクではなく、実際に展開されたAIエージェントの記録された挙動です。
3. 規制当局が求めるのは「技術的に防止された証拠」であり、「指示した証拠」ではない。HIPAA §164.312(a)(1)は、許可された人物やソフトウェアのみがePHIにアクセスできる技術的方針・手順を要求しています。CMMC AC.1.001は認可されたアクセス制御を、SEC Rule 204-2は帰属可能な記録を求めています。いずれも文書化された指示だけでは満たされません。AIモデルが従うかどうかに関わらず、制約を強制する仕組みが必要です。
4. モデルのアップデートでシステムプロンプトの解釈が密かに変わる可能性がある。AIベンダーが基盤モデルを更新すると、同じシステムプロンプトでも挙動が変わることがあります。あるバージョンでアクセスを確実に制限できていたプロンプトが、次のバージョンでは異なる挙動を示す場合もあります。コンプライアンスコントロールはバージョン依存であってはなりません。ベンダーがモデルを更新するたびに、組織が知らぬ間にガバナンスコントロールが変化するようでは、コントロールの定義を満たしません。
5. システムプロンプトは自身の失敗の監査証跡を残さない。システムプロンプトが回避・上書き・誤解釈された場合、意図した制約が破られたことを示すログは通常残りません。エージェントは意図外の範囲で行動し、本来アクセスすべきでないデータに触れても、そのアクセスが正規のものと区別できる記録が残りません。静かに失敗したシステムプロンプトからは、改ざん検知可能な監査証跡は再構築できません。

システムプロンプトがコンプライアンスコントロールとして失敗する3つの理由

モデル層ガバナンスの失敗パターンは仮説ではありません。これは大規模言語モデルベースのエージェントが指示を処理する構造的特性であり、学術研究や実際のインシデントで記録されています。

プロンプトインジェクション：構造的脆弱性

プロンプトインジェクションは、AIエージェントが読むコンテンツ――ドキュメント、メール、ウェブページ、データベースレコード――に悪意ある指示を埋め込む攻撃です。エージェントは埋め込まれた指示をコンテキストの一部として扱い、元のシステムプロンプトを上書きして実行する場合があります。2026年2月のAgents of Chaos調査では、研究者たちが、機密データの直接リクエストは拒否したものの、そのデータを含むコンテナの転送依頼には応じたエージェントを記録し、本番環境での間接的な指示によるガードレール回避を実証しました。また、複数チャネルで偽装IDを受け入れたり、外部から仕込まれた行動指示を別のエージェントに自発的に共有し、追加の攻撃指示なしで攻撃者の制御を拡大した事例もありました。

コンプライアンスの観点からは、プロンプトインジェクションは設定ミスで修正できるものではなく、LLMベースのエージェントが指示を処理する構造的な特徴であることが重要です。通常時に行動を制限するシステムプロンプトは、操作されたコンテンツに遭遇した際に同じ挙動を保証できません――まさに攻撃者が狙う状況です。

モデルアップデート：静かな挙動のドリフト

AIベンダーは、機能向上や安全性強化、インフラ変更のために基盤モデルを定期的にアップデートします。モデルが更新されると、同じシステムプロンプトへの挙動が変化する場合があります。あるバージョンでエージェントを確実に制限できていたプロンプトが、次のバージョンでは異なる挙動を示すことも、システムプロンプトのテキスト自体に変更がなくても起こり得ます。

これにより、検知が極めて困難なコンプライアンス違反が発生します。ガバナンスコントロールはモデルの変更によってドリフトしますが、外部からは何も変わっていないように見えます。2026年2月のMicrosoft Copilotインシデントは、その下流リスクを示しています。コードエラーにより、Microsoftのアプリケーション層コントロール――感度ラベルやDLPポリシー――が同時に機能不全となり、CopilotがPHIや法的コミュニケーションを含む機密コンテンツを数週間にわたり処理できてしまいました。アプリケーション層とモデル層のコントロールが同一プラットフォーム内にある場合、プラットフォームレベルの単一障害で全コントロールが同時に破られる可能性があります。独立したデータ層の防御がなければ防げません。

間接的操作：システムプロンプトでは守れない境界

能動的な攻撃がなくても、システムプロンプトはコンプライアンスが要求する厳密な境界を強制できません。プロンプトは「この診療に関連するデータのみアクセスせよ」といった意図は表現できますが、データアクセス層でその意図を技術的に強制することはできません。サービスアカウントの認証情報がより広範なデータセットへのアクセス権を持っていれば、システムプロンプトが何を言おうと、エージェントはそのデータに技術的にアクセス可能です。コンプライアンスコントロールは、意図ではなく、技術的に何を防止したかで評価されます。1万件の患者記録に技術的アクセス権があるエージェントが、3件だけ読むよう指示されていても、他の9,997件へのアクセスを防止する仕組みがなければ、HIPAAの「最小限必要」基準は満たせません。

規制当局が実際に求めているもの

規制対象データアクセスを管理するコンプライアンス基準は、「アクセスが技術的に制御されていた証拠」を要求します。「制御しようとした意図の証拠」ではありません。この違いが、監査に耐えうるコンプライアンス体制と、指摘を受ける体制の分かれ目です。

規制当局にとっての「アクセス制御」とは

HIPAAのセキュリティ規則は、「アクセス権を付与された者またはソフトウェアプログラムのみがアクセスできるようにする技術的方針と手順」を求めています。重要なのは「許可する（allow）」という語です――システムは技術的に認可されたアクセスだけを許可しなければならず、アクセス者に自制を促すだけでは不十分です。CMMC評価者がAIエージェントのワークフローにおける認可アクセス制御の証拠を求める場合、期待される証拠はポリシー強制の記録です：どのアクセスが要求され、どのポリシー評価が適用され、何が許可/拒否され、いつだったか。システムプロンプトの設定文書ではこの証拠は生まれません。すべてのエージェントリクエストをABACポリシーで評価するデータポリシーエンジンが証拠を生みます。

規制当局にとっての「監査証跡」とは

HIPAA §164.312(b)、CMMC AU.2.042、SEC Rule 17a-4はいずれも、「実際に何が起きたか」の記録を要求しています――「意図したこと」の記録ではありません。設定・文書化されたシステムプロンプトは意図の記録です。改ざん検知可能な運用レベルの監査ログ（エージェントID、アクセスデータ、操作種別、ポリシー評価、タイムスタンプなど）は、実際に起きたことの記録です。後者だけがこれらの規制要件を満たします。監査人が「先週火曜にAIエージェントがアクセスしたデータは？」と尋ねた場合、答えは監査ログから得られる必要があり、システムプロンプトが防いだはずだという推測からではいけません。

「AIベンダーがコンプライアンス認証を持っている」は答えにならない理由

AIベンダーのコンプライアンス認証――SOC2、ISO27001、FedRAMP――は、ベンダー自身のセキュリティ体制を対象としています。カバードエンティティ（自社）のアクセス制御、監査証跡、最小限必要アクセスの強制、委任チェーンが自社の規制義務を満たしているかどうかは対象外です。HIPAAコンプライアンス、CMMC認証、SEC監査対応は組織の義務であり、ベンダーの証明書にアウトソースできません。監査人が「先週火曜にAIエージェントがアクセスした特定の患者記録のアクセスログを見せて」と言ったとき、ベンダーのSOC2レポートは答えになりません。

データ層ガバナンスの本質

データ層ガバナンスとは、データへのアクセス時点でガバナンスコントロールを強制することです――モデル、プロンプト、エージェントフレームワークとは独立しています。これは「指示した証拠」ではなく、「技術的に制御した証拠」を生み出す唯一のアーキテクチャです。

データ層コントロールがシステムプロンプトにできないこと

データ層ガバナンスコントロールは、規制対象データに到達する前にすべてのデータアクセスリクエストをインターセプトします。エージェントのIDを検証し、ワークフローを委任した人間の認可者と紐付け、リクエストをABACアクセス方針で評価します：このエージェントはこのデータ、この操作、このコンテキストでアクセスを許可されているか？ポリシーが許可すればアクセスを許可し、記録します。許可されなければアクセスを拒否し、その拒否も記録します――モデルへの指示やシステムプロンプトが回避されたかどうかに関わらず。

プロンプトインジェクション攻撃でシステムプロンプトが上書きされ、エージェントが範囲外データへのアクセスを指示された場合でも、データ層ガバナンスコントロールがそのアクセスを拒否します――アクセス方針が満たされていないからです。モデルは侵害されても、データガバナンスは侵害されません。これが「コンプライアンスごっこ」と「本物のコンプライアンス」の違いです。

データ層ガバナンスが生み出す証拠

データ層ガバナンスは、規制当局が求める証拠――改ざん検知可能な運用レベルの監査記録（エージェントID、認可者、アクセスデータ、操作種別、アクセス方針評価、タイムスタンプ）――を正確に生み出します。この記録はモデル挙動とは独立してガバナンス層で作成され、モデルが指示に従うかどうかに依存しません。監査人が「先週火曜にAIエージェントがアクセスしたデータは？」と尋ねた場合、数日かけて推測ログを再構築するのではなく、数時間でガバナンス層からレポートを提出できます。

KiteworksによるAIエージェント向けデータ層ガバナンスの提供

Kiteworksのプライベートデータネットワークは、AIエージェントと彼らがアクセスする必要のある規制対象データの間に配置されます。すべてのエージェントデータリクエストは、データが移動する前に4つのガバナンスチェックポイント――認証済みID、ABAC方針評価、FIPS 140-3認証済み暗号化、改ざん検知可能な監査記録――を通過します。これはモデル、プロンプト、エージェントフレームワークとは独立しています。モデルが侵害、更新、操作されても、Kiteworksはポリシーを強制し続けます。

モデルとは独立したID認証

Kiteworks経由でデータにアクセスするすべてのAIエージェントは、アクセス前に認証されます。これは、ワークフローごとに一意な認証情報が、タスクを委任した人間の認可者と紐付けられる仕組みです。この認証はモデルではなくデータガバナンス層で強制されます。プロンプトインジェクション攻撃でもこれを上書きできません――なぜなら、チェックはデータ層で行われ、エージェントのリクエストがデータに到達する前に実施され、モデルのコンテキストウィンドウ内では攻撃者が操作できないからです。

モデルアップデートにも耐えるポリシー強制

Kiteworksのデータポリシーエンジンは、すべてのエージェントデータリクエストを多次元ABAC方針――認証済みエージェントプロファイル、リソースのデータ分類、ワークフローコンテキスト、操作種別――で評価します。この評価はモデルではなくガバナンス層で実施されます。基盤モデルがアップデートされ、システムプロンプトの解釈が変わっても、データポリシー強制は変わりません――モデル挙動に依存しないからです。データガバナンスポリシーは組織が設定し、モデルバージョンに関係なく一貫して適用されます。

規制当局が利用できる監査証跡

Kiteworks経由のすべてのエージェントデータ操作は、改ざん検知可能な運用レベルの監査ログ（エージェントID、認可者、アクセスデータ、操作種別、ポリシー評価結果、タイムスタンプ）として記録されます。このログは組織のSIEMに連携され、規制証拠要求に対応できる形式で保持されます。HIPAA監査人、CMMC評価者、SEC検査官がAIエージェントワークフローのアクセス制御証拠を求めた際、提出されるのはエクスポート可能な証拠パッケージです――システムプロンプトの設定文書や、規制監査基準を満たす設計ではない推測ログではありません。

大規模にAIエージェントを導入しつつコンプライアンスリスクを蓄積したくない組織にとって、KiteworksはAIガバナンスを「仮定」ではなく「現実」にするアーキテクチャを提供します。KiteworksのコンプライアントAIについて詳しく知る、またはデモをリクエストしてください。

追加リソース

• ブログ記事
  手頃なAIプライバシー保護のためのゼロトラスト戦略
• ブログ記事
  77%の組織がAIデータセキュリティで失敗している理由
• eBook
  AIガバナンスギャップ：2025年に91%の中小企業がデータセキュリティでロシアンルーレットをしている理由
• ブログ記事
  あなたのデータには「–dangerously-skip-permissions」は存在しない
• ブログ記事
  規制当局は「AIポリシーがあるか」ではなく「本当に機能しているか」の証拠を求めている