第11章 — 可観測性、ロギング、インシデントレスポンス

『LLM Primer VII: AIセキュリティ』を章ごとに紹介していくウォークスルー、第11回。ロギング、アラート、インシデントレスポンスを、アーキテクチャ的な防御を運用者が実際に回せるシステムに変えるレイヤとして扱う章。

なぜこの章があるのか

構造は正しくとも可視性のないシステムは、不可視のうちに失敗する。第11章はLLMシステムの可観測性レイヤを歩く — 何をログすべきか、乱用と異常をどう検知するか、ノイズを生まずにどうアラートするか、何かが起きたときにインシデントレスポンスのプレイブックをどう回すか、そこから何を学ぶか。一般的な規律は他所の運用エンジニアリングから転用でき、そこにLLM固有の拡張が加わる。確率的な出力は、インシデントの再現に決定的なシステム以上の状態捕捉を要求する。2024年以降開発が進むOpenTelemetry GenAIセマンティック規約が、その状態のためのベンダー中立の語彙を与える。

11.1 何をログするかはデフォルトではなくポリシー判断である

ログが少なすぎればチームは調査ができない。多すぎればコンプライアンス、コスト、プライバシーの問題が生じ、いずれ削減を迫られる。守り抜ける立場は、チームが特定した運用ユースケースを支える最小限を、それぞれを支える構造化された形で残す、というものだ。目的には通常、乱用や異常のリアルタイムアラート、インシデントの事後調査、キャパシティ計画とコスト分析、コンプライアンス報告、モデル挙動の継続評価が含まれる。それぞれの目的はスキーマへの要求が異なり、一つの目的に設計されたログは他の目的には不十分だ。OpenTelemetry GenAIセマンティック規約は、LLM呼び出しのためのスパンと属性 — モデル名、プロバイダ、リクエストパラメータ、プロンプト内容、レスポンス内容、トークン数、レイテンシ、コスト — を定義し、特定のSDKに関係なく下流のツールが同じテレメトリを解釈できるようにする。Langfuse、Helicone、Arize Phoenix、Datadog LLM Observability はすべてこの形状を消費する。本番のログエントリには通常、リクエストID、認証済みプリンシパル、テナント、モデルのバージョンとプロバイダ、検索コンテキストとその出所を含む組み立て済みプロンプト全体、ツール呼び出しとその出力、レスポンス内容、入力と出力での安全分類スコア、レイテンシとトークン集計が含まれる。これを責任を持って保存するとは、保持期間、PIIの取り扱い、ログストア自体のアクセス制御について明示的であることを意味する。

11.2 検知はシグネチャ、統計、振る舞いのシグナルを組み合わせる

テレメトリが構造化されたら、次の問いはどのパターンが問題を示すかだ。シグネチャマッチングは最も安価な第一線 — 既知のプロンプトインジェクションフレーズ、DAN系の前置き、base64エンコードされたペイロード、以前観測されたロールプレイの設定など。リストは公開研究、社内レッドチーム作業、過去のインシデントから作られる。シグネチャは既知の変種を捕まえるが、敵対者はどのフレーズがフラグされるかを学ぶと適応する。統計的異常検知はベースラインからの乖離を監視する — 異常なトークン分布、典型と異なるレイテンシ対長さの比率、拒否率や特定のツール呼び出しの率の急上昇。ベースラインは通常状態ではゆっくり漂い、異常状態では急に変わる。振る舞いパターン検知は、個々のリクエストが露骨に悪意的でなくても乱用プロファイルにマッチする — 一人のプリンシパルが同じ制限リクエストを言い換えた変種を数千回発行する、正当な内容と特定の接尾辞を組み合わせたリクエストの急上昇、ユーザごとのレスポンス分布のゆっくりとした漂流など。検知は、運用者が実際に応答するアラートに繋がって初めて有用になる。分類は通常、クリティカル(規模のある能動的乱用、オンコールエンジニアの呼び出し)、ハイ(顕著なパターンだが被害は有界、業務時間内通知)、ミディアム/ロー(ダッシュボードと週次レビュー)と区別する。アラート疲れが失敗モードで、それを防ぐのは厳格な深刻度規律である。

11.3 インシデントレスポンスは即興ではなくプレイブックである

NIST SP 800-61 Revision 2 が枠組み — 準備、検知と分析、封じ込め、根絶、復旧、事後活動 — を与え、LLM固有のプレイブックはそれを拡張する。準備とは、インシデントの前にランブック、オンコールローテーション、関連ツールへのアクセスが存在していることを意味する。検知と分析は、11.1の可観測性が報われる場所だ。LLMインシデントの封じ込めは、特定のツールを無効化するフィーチャーフラグを切ること、より保守的なモデルバージョンへの格下げ、特定のプリンシパルやテナントに対するレート制限の締め付け、あるいはトラフィックの代替スタックへの経路変更を意味しうる。根絶はインシデントの種類に依存する。ジェイルブレイクにはフィルタルールの追加、侵害されたRAG文書はインデックスからの削除、漏出した資格情報はローテーションが必要かもしれない。復旧は、封じ込めが解かれ、根絶が検証されたうえでシステムが通常に戻る局面だ。事後活動は、モデル固有の作業が集中する場所である。挙動を可能なら再現し、失敗の境界を特徴づけ、そのインシデントがモデルの使い方を変えるべき何かを示唆しているかを判断し、結果を評価スイートへ流し込んで将来の退行がデプロイ前に捕捉されるようにする。ゼロでない温度のサンプリングでは再現が常に可能とは限らないが、目標は望ましくない挙動がいつ発生するかを定義することだ。

第11章が敷いたもの

第12章は第IV部を、アイデンティティとアクセスのレイヤ — 誰がシステムとどのような条件で対話でき、コンポーネント間で強制がどう構造化されるか — で締めくくる。伝統的な規律が当てはまる。APIキー、OAuth、mTLSによる認証。RBACとABACによる認可。マルチテナント分離。レート制限とクォータ。エンタープライズガバナンスのオーバーレイ。LLM固有の拡張はモデルをプリンシパルとして扱うこと — ユーザの代理で動くエージェントは自身のアイデンティティと権限を持つ — 、ツール呼び出しにおけるcapabilityトークンの役割、マルチテナントLLMプラットフォームがサポートすべきモデル挙動のテナントごと設定、といった点にある。続く第13章は第V部を規制の状況で開く。この本が展開してきた技術的統制は、AI ActとGDPR、米国州法、それらを取り巻く枠組みへとマッピングされていかなければならない。

次回 — 第12章: アクセス制御とアイデンティティ。認証、RBAC対ABAC、マルチテナント分離、レート制限、そしてLLMシステムを規制環境で使えるものにするエンタープライズガバナンスのオーバーレイ。