第10章 — 安全なLLMアーキテクチャの設計

『LLM Primer VII: AIセキュリティ』を章ごとに紹介していくウォークスルー、第10回。アーキテクチャを主たるセキュリティ規律として扱う章 — 確率的なコンポーネントに与えうる最も安全な構成とは、そのコンポーネント自身の自制ではなく構造によって被害範囲が有界化された状態だからだ。

なぜこの章があるのか

第I部から第III部の各章では、脅威とモデル側の防御を挙げてきた。第10章はモデルの周囲にあるアーキテクチャ — 分離境界、検証層、ポリシーエンジン、API契約、ゼロトラストの原則 — を歩き、これらがシステムに構造的な性質を与える様子を描く。前提はこれまでのセキュリティエンジニアリングと同じで、侵害を仮定し、被害を封じ込め、侵害を可視化する。新しいのは、封じ込める対象が自然言語で駆動されるオーケストレータであり、その指示は任意の入力経路から届きうるという点だ。アーキテクチャのパターンは過去の時代から転用が効く。この章の仕事は、それらがLLMに具体的にどう当てはまるかを描くことにある。

10.1 分離が被害範囲を有界化する

分離境界とは、一方のコンポーネントがもう一方に、統制されたインターフェイスを経由せずには直接影響を与えられない、意図的な継ぎ目のことだ。分離のセキュリティ上の理由は、侵害されたコンポーネントが正規のインターフェイスを通じて到達できる範囲によって被害が有界化される点にある。LLMシステムにおいて最も重要な分離の問いは、モデルとそれ以外の全てのシステムアクセスとの間にある。ファイルシステムに無制限にアクセスでき、ネットワークにも無制限にアクセスでき、許可リストのないシェル実行ツールを持つプロセスの中で動くモデルは、被害範囲が大きい。定義済みsyscallセットのサンドボックスの中でプロセスが動き、ネットワークアクセスがドメイン単位の許可リストを備えたegressプロキシを経由し、ツールが周囲のコードによってリクエストごとに発行されるcapabilityトークン経由で呼び出されるモデルは、被害範囲がはるかに小さい。このパターンはコード実行にも広がる — OpenAIやAnthropicがコードインタプリタ環境で用いているようなサンドボックスツールは、生成されたコードを短命のgVisorやFirecracker VMの中で実行する — またブラウジングにも及ぶ。ヘッドレスブラウザは、内部エンドポイントへのアクセスを持たない分離されたネットワーク名前空間の中で動く。分離は具体的な攻撃が発生する前に行う設計上の判断であり、被害範囲の削減あたり最も安価なセキュリティ投資として、この分野が提供する最良のものだ。

10.2 検証は階層化され、ポリシーは宣言的である

単一の検証点は単一の障害点だ。本番のLLMエンドポイントは通常、クライアントリクエストとレスポンスの間に5つのレイヤを構成する。認証はプリンシパルの資格情報を検証する。リクエスト検証はAPIのスキーマ — 型、範囲、長さ、文字集合 — に照らしてリクエストを確認する。ポリシー評価は、認証されたプリンシパル、検証されたリクエスト、現在のシステム状態がこのアクションを許すかを問う。モデル呼び出しはシステムプロンプト、検証済みのユーザ入力、ポリシーが許すものにスコープを絞ったツールリスト、出力制約を伴って走る。出力フィルタリングは、返してはならない内容 — 漏出した秘密情報、禁止された内容、安全でないツール呼び出し — がないかレスポンスを確認してから送信する。ポリシーロジックは時間とともに肥大化し、アプリケーションコードのあちこちに散らばれば、多数の条件分岐の和集合となって、監査もテストも進化も難しくなる。この分野はポリシーとコードを分離することで収束してきた。CNCFプロジェクトのOpen Policy Agent (OPA) はRegoで書かれたポリシーを評価する。2023年にリリースされたAWS Cedarは、形式検証の性質を備えた、より焦点を絞った認可言語だ。どちらも本番運用に耐える。選択は通常、組織的な整合性で決まる。ポリシーはバージョン管理され、レビュー可能な成果物となり、システムの実効セキュリティポリシーは常に一箇所で読める状態になる。

10.3 モデル呼び出しへのゼロトラストの適用

APIはLLMシステムと呼び出し元との間の契約である。安全なAPI設計とは、敵対的な呼び出し元と接触してもその不変条件が生き残るように契約を形作る規律だ。明示的な入力スキーマ — 厳密な型、範囲、許可リスト化された列挙型 — はコストが低く、APIが呼び出し元に置いている暗黙の信頼を有界化する。内部状態を漏らさない構造化されたエラーレスポンスは、曖昧な表現のエラーが可能にしてしまう情報収集を回避する。冪等キー、リクエストID、バージョニングは、追加の状態を必要とせず、呼び出し元の振る舞いに対する可観測性をシステムに与える。ゼロトラストモデルは、Googleの2014年のBeyondCorp論文で提示され、2020年のNIST SP 800-207で形式化され、この原則を拡張する — ネットワーク上の位置によって信頼される呼び出し元は存在しない。全てのリクエストは認証され、明示的なポリシーに対して認可され、デバイスとコンテキストに照らして評価され、記録される。LLMシステムに適用すれば、モデル呼び出し自体がプリンシパルになる — モデルから下流ツールへのリクエストはモデルとして認証され、そのモデルが代理で動作している人間のアイデンティティを運び、両方のアイデンティティを知るポリシーに対して認可される。狭いスコープと短いTTLを持つcapabilityトークンが、これを合成可能にする鍵だ。結果として、侵害されたプロンプトが完全なシステム侵害へと権限を昇格することができなくなる。モデルのcapabilityそのものが、特定のリクエストのために周囲のコードが発行したトークンによって有界化されているからだ。

第10章が敷いたもの

可視性のない構造は不可視のうちに失敗する。第11章は、アーキテクチャ的な防御を運用可能なシステムに変える可観測性のレイヤを検討する — LLMが処理の中にいるときに何をログすべきか、テレメトリをどう構造化すればリアルタイムのアラート、事後の調査、キャパシティ計画、コンプライアンス、継続評価を同じ記録から提供できるか。2024年にLLM固有のスパンと属性の標準化を始めたOpenTelemetry GenAIセマンティック規約が、ベンダー中立の基盤を与える。具体的な実装 — Langfuse、Helicone、Arize Phoenix、Datadog LLM Observability — はその上に、それぞれ異なるトレードオフで乗っている。続く第12章は、アイデンティティとアクセスの側面 — OAuth、mTLS、RBACとABAC、マルチテナント分離、レート制限、規制環境でシステムを使えるようにするエンタープライズガバナンス統制 — を扱う。

次回 — 第11章: 可観測性、ロギング、インシデントレスポンス。OpenTelemetry GenAI規約で何をログするか、乱用パターンをどう検知するか、失敗が確率的なシステムに対してNIST型のインシデントレスポンスをどう回すか。