AI Suite 内のすべての管理操作は JSONL 形式の監査ログ行を生成します。この行にはタイムスタンプ、実行者のメールアドレス、操作動詞、影響を受けたリソース、 X-App-Id 発信元クライアントの識別子、およびレビュアーが後続のイベントと行を関連付けるための安定したハッシュが記録されます。この行には モデルの入力や出力は一切含まれません. プロンプトテキストも、完了テキストも、ドキュメントの内容も、抽出されたエンティティもありません。この設計上のコンテンツ非保持の選択が、調達やコンプライアンスのレビュアーにとって監査ログ行を有用にしている理由であり、その説明に値します。

監査ログ行に含まれるものと含まれないもの

代表的なログ行（軽く編集済み）：

{"ts":"2026-06-05T09:14:22Z","actor":"jane@bank.example","action":"license.assign",
 "subject":"user@bank.example","tier":"commercial","x_app_id":"ai-admin-console",
 "ip":"10.4.1.22","ua_hash":"a17c…","seq":48211}

含まれるもの：監査人が尋ねるデプロイヤーの義務に答えるのに十分なメタデータ — 誰が、いつ、どのリソースに対して、どのクライアントから操作を行ったか. 含まれないもの：AI ワークフローからのペイロードは一切ありません。この例では操作がモデルを呼び出していませんが（呼び出していた場合でも）、呼び出しイベントを記録する行はありますが、プロンプトや応答の記録は当社のインフラには存在しません。

この分離は意図的です。監査ログ行は 操作が実際に行われた証拠です。アクションの内容—モデルに送信されたプロンプトや返された回答—は、展開者自身のハードウェア上に存在し、展開者自身の保持ポリシーに従って管理されます。私たちがそれを見ることは決してありません。

なぜ内容が行から除外されるのか

理由は2つあります。1つは規制上の理由、もう1つは運用上の理由です。

規制上の理由：EU AI法は、高リスクAIの展開者に対し、「適切な期間」ログを保持し、システムの運用を監視し、要求に応じてコンプライアンスを証明することを求めています。 [1]。義務は展開者にあり、何が起こったかを証明する責任があります。クラウドLLM APIは、プロンプトと応答をベンダーのインフラ上に保存することでこれに対応しており、データ処理の問題をベンダーに移転し、展開者が管理しない第二のコンプライアンス境界を作り出しています。コンテンツフリーのローカル監査は、その移転なしに同じ規制上の問題に答えます： 展開者は 展開者自身のストレージに内容を保持し、展開者自身の保持ルールに従います。

運用上の理由：モデルの内容として保存されるすべてのバイトは、暗号化、アクセス制御、保持、スケジュールに基づく削除、電子証拠開示の対象となる必要があります。コンテンツフリーの行は小さく（数百バイト）、固定形状で、追記専用であり、展開者の既存のSIEMに簡単にシリアライズ可能です。これは義務を満たす最小の証拠単位です。

主要なフレームワークでこれが何に対応するか

NIST AI RMF 1.0は、監査可能性を信頼できるAIの核心的な次元として位置づけ、展開者に「意思決定を再構築するのに十分なシステムアクションの記録」を維持するよう求めています。 [2]。「再構築に十分な」が重要なフレーズです：行はレビュアーが何が起こったかを再構築できるようにしなければなりません。コンテンツフリーの行は、 管理上の アクション（ライセンスの発行、ポリシーの変更、サーバーの登録）については、推論の 内容 を保持せずにそれを実現します。推論内容に関する義務については、展開者自身のローカルストアがその質問に答えます。

ENISAのAIサイバーセキュリティガイダンスは、脅威モデリングの観点からこれを位置づけています。 [3]：ベンダーのインフラに保存されるすべてのプロンプトと応答は、展開者の攻撃対象領域をベンダーのものも含むように拡大します。モデル内容をベンダー側から除外することで、その対象領域は展開者が既に管理している範囲に狭まります。

当社が提供する形態 — AI Admin Console UI、 aisuite-server デーモンのJSONL監査、および組織ごとのSIEM転送フック — はこれを直接実装しています。すべての管理イベントはデプロイヤーが読み取れる行に記録されます。ローカルまたは顧客ホストの推論経路では、プロンプトおよび応答内容はSoftware Tailorのコントロールプレーンに送られません。

調達審査での実際の様子

クラウドAIベンダーが調達で立ち止まる質問は、「推論内容はどこに保存されており、当社のコンプライアンスチームが要求に応じてそれを提出できるか？」というものです。コンテンツフリー監査が答える調達の質問も同じで、2つの明確な回答があります： コンテンツはお客様のハードウェア上にあり、お客様のチームが既に所有しているため提出可能です。当社側の監査行はその操作が行われたことを証明し、お客様側のコンテンツはその操作が何をしたかを証明します。

より広い調達の枠組みについて — これらの特性を用いてベンダー側の認証ではなくベンダー質問票を主導する方法を含め — は、 オンプレミスAI導入が調達で停滞する理由 および EU AI法令準拠に関する記事をご参照ください。

デプロイヤーの責任として残るもの

コンテンツフリー監査は導入の構造的特性であり、エンドツーエンドのコンプライアンスソリューションではありません。デプロイヤーは引き続き以下を所有します：

  • 「再構築に十分」とは何かを定義すること 自社のワークフローに応じて — 保持期間、マスキングルール、電子証拠開示の姿勢。
  • ローカルコンテンツストアの運用 （デプロイヤーが選択するもの — ファイルシステム、ドキュメントDB、暗号化されたブロブストアなど）および当社側からの監査行をSIEMに転送し、自社ログと相関させること。
  • デプロイヤー義務メモの作成 調達時にこのアーキテクチャを指し示すもの。

当社はアーキテクチャと監査行フォーマットを提供します。その下流、つまりコンテンツの保持ポリシーを含むすべては、デプロイヤーのコンプライアンスチームが独自のルールを適用する領域です。

参考文献

  1. 欧州委員会。『AI法 — AIに関する規制枠組み』。 https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai。2026年6月3日アクセス。
  2. NIST。『AIリスク管理フレームワーク（AI RMF 1.0）』。 https://www.nist.gov/itl/ai-risk-management-framework。2026年6月3日アクセス。
  3. ENISA。『人工知能のサイバーセキュリティ』。 https://www.enisa.europa.eu/topics/iot-and-smart-infrastructures/artificial-intelligence。2026年6月3日アクセス。