重要なポイント
- SOC 2とISO 27001は組織の統制を認証するものであり、ツールを認証するものではない。「OllamaはSOC 2準拠」「vLLMはISO 27001認証済み」とは絶対に言わないこと。すべて監査人が確認する統制への「対応状況」として説明する。
- SOC 2は5つのTrust Services Criteria(セキュリティ、可用性、機密性、処理の完全性、プライバシー)で評価し、ISO 27001は文書化されたISMS内のAnnex A統制で評価する。
- 推論エンドポイントにはアクセス制御と構造化リクエストログが必要。Ollama、vLLM、TGIなど大半のセルフホストエンジンはデフォルトでこれを提供せず、前段にゲートウェイが必要。
- モデル重みとプロンプト/レスポンスログは保存時(ディスク暗号化)と転送時(TLS)の両方で暗号化する。他の本番データストアに既に適用している統制と同じもの。
- オープンウェイトモデルでも公開元の身元、チェックサム検証、ライセンス条件、配信スタックの既知CVEを含む文書化されたベンダーリスク評価が必要。
- コンプライアンス自動化プラットフォーム(Vanta、Drata、Secureframe)はクラウドインフラから証跡を自動収集できるが、セルフホスト推論サーバーは通常カスタム連携か手動アップロードが必要。
- 本記事は法的・コンプライアンス助言ではない。最終的な範囲・統制の判断は監査人が行う。
本記事は法的・コンプライアンス助言ですか?
いいえ — 本ガイドは法的・コンプライアンス助言ではありません。 SOC 2やISO 27001の監査人が一般的に確認する統制のカテゴリを技術的な観点で説明し、セルフホストLLMデプロイへの当てはめ方を示すものです。特定の統制が実際の監査を満たすかどうかは、監査人の判断、組織のリスク評価、提出する範囲声明の内容によって決まります。監査を計画する前、またはコンプライアンス状況について何らかの主張をする前に、資格を持つ監査人やコンプライアンス部門にご相談ください。
SOC 2 Trust Services Criteriaとは何を求めるものか
SOC 2は5つのTrust Services Criteria(TSC)で組織を評価し、いずれもセルフホストLLMシステムが本番データに触れた瞬間から適用される。 監査人がテストするのはモデルではなく、レビュー期間を通じて統制が存在し機能していたことを組織が証明できるかどうかである。
| 基準 | 監査人が確認する点 | セルフホストLLMでの統制 |
|---|---|---|
| セキュリティ | アクセス制御、ログ、脆弱性管理 | 推論ゲートウェイでのRBAC+MFA |
| 可用性 | 稼働率、冗長性、DR計画 | マルチノード配信+検証済みバックアップ |
| 機密性 | データ分類、知る必要性 | 重み・ログの保存時暗号化 |
| 処理の完全性 | 正確性、完全性、適時性 | バージョン固定モデル+出力ログ |
| プライバシー | 通知、同意、データ最小化 | 文書化されたプロンプトログ保持ポリシー |
ISO 27001 Annex Aとは何を求めるものか
ISO 27001は組織の情報セキュリティマネジメントシステム(ISMS)を認証するものであり、Annex Aはそこから引用される統制の参照リストであって、単一システムに直接適用するチェックリストではない。 セルフホストLLMデプロイは他の資産と同様にISMSの範囲内に位置し、リスクアセスメント、適用宣言書(Statement of Applicability)への記載、関連統制が機能している証跡が必要となる。
| Annex A領域 | LLMスタックへの対応 |
|---|---|
| A.5 組織的管理策 | モデル公開元のベンダーリスクレビュー |
| A.5.19–22 供給者関係 | モデル出所・ライセンス確認 |
| A.8 技術的管理策 | エンドポイント堅牢化、暗号化、ログ |
| A.8.16 監視活動 | 推論リクエスト/レスポンス監査ログ |
| A.8.24 暗号 | 転送時TLS、保存時ディスク暗号化 |
| A.5.29 事業継続 | モデル配信向けインシデント対応手順書 |
推論エンドポイントに必要なアクセス制御とログとは
監査人は誰がどの資格情報でいつモデルを呼び出したかを確認したいと考えるが、一般的なセルフホストエンジンはいずれもゲートウェイなしではこれを満たさない。 Ollamaはデフォルトで`127.0.0.1:11434`にバインドしユーザーアカウントを持たず、vLLMとHugging Face TGIは組み込み認証なしでOpenAI互換HTTP APIを公開する。
推論エンジンの前段にAPIゲートウェイ(Kong、Envoy、クラウドプロバイダーのAPI管理層など)を配置して呼び出し元ごとのAPIキーやOAuth2を追加し、呼び出し元ID・タイムスタンプ・モデルバージョン・トークン数をSIEMが取り込める形式でログ記録する。
- 認証:ゲートウェイでのAPIキーまたはOAuth2。全呼び出し元が共有するベアラートークンは不可
- 認可:ロールベースアクセス — どのモデルを誰が呼び出せるか、管理/メトリクスエンドポイントを誰が見られるか
- 監査ログ項目:呼び出し元ID、タイムスタンプ、モデル+バージョン、呼び出しエンドポイント、レスポンスステータス
- 管理アクセス:推論ホストへのシェル/設定アクセスにはMFAを必須とする
モデル重みとプロンプトログをどう暗号化するか
モデル重み、プロンプトログ、レスポンスログには、他の本番データストアに監査人が既に期待しているのと同じ保存時・転送時暗号化が必要。 重み自体は機密でないことが多いが、推論サーバーのディスクにはキャッシュされたプロンプト、ファインチューン済みアダプター、機密性の高いログも通常保存されている。
推論ホストではディスク全体暗号化(LinuxならLUKS、WindowsならBitLocker、macOSならFileVault)を基本とする。ゲートウェイでのすべての受信APIコールにTLS終端を追加し、VPC内であっても生の推論ポートを平文HTTPで公開しない。
- 保存時:ホストのディスク全体暗号化、プロンプトログDB用の暗号化ボリューム
- 転送時:呼び出し元→ゲートウェイ→推論エンジン間のTLS。平文の内部ホップなし
- 鍵管理:鍵はKMS/vaultに保管し、文書化されたスケジュールでローテーション
モデル更新の変更管理はどう行うか
モデルバージョンの切替、量子化変更、システムプロンプトの編集はすべて本番変更であり、コードデプロイと同じ承認履歴が必要。 監査人は変更ログが事後に存在することではなく、変更が本番反映前にレビュー・承認された証跡があるかを具体的に確認する。
- 可変な「latest」ポインタではなく、正確なモデルアーティファクト(チェックサム)を固定する
- 本番でのモデル・システムプロンプト変更前に文書化された承認ステップを必須とする
- すべての変更を承認者・日時・理由とともに記録する
- 直前のバージョン固定アーティファクトへのロールバック経路を維持する
オープンウェイトモデルのベンダーリスクをどう評価するか
「オープンウェイト」は「ベンダーなし」を意味しない — モデル公開元はSaaSベンダーと同様のサプライチェーン当事者であり、監査人はこれに対する文書化されたリスクアセスメントを期待する。 これは最も見落とされがちな統制の一つで、チームはダウンロードしたGGUFやsafetensorsファイルを内部のものとして扱いがちだが、実際には組織外から取り込まれたものである。
- 公開元の身元:Meta、Mistral AI、Alibaba/Qwen、Microsoftなど既知の組織か、匿名ソースか
- チェックサム検証:デプロイ前に公開元発行のハッシュとSHA-256を照合
- ライセンスレビュー:商用利用条件、再配布制限
- 配信スタックのCVE:モデルファイル自体だけでなく、llama.cpp、vLLM、TGIの既知脆弱性を追跡
モデル配信システムのインシデント対応とはどのようなものか
モデル配信システムには標準的なWebアプリの手順書ではカバーされないインシデント区分 — モデル流出、モデル出力を通じてデータが漏えいするプロンプトインジェクション、推論エンドポイント侵害 — があり、それぞれに名前の付いた対応経路が必要。
- トリガー例:不正な重みファイル変更、単一資格情報でのリクエスト急増、ログ内のプロンプトインジェクションの兆候
- 封じ込め:システム全体を停止させずに推論エンドポイントを分離・オフライン化できること
- 証跡保全:インシデント発生期間の生ログを保持し、調査中はローテーションしない
- テスト頻度:最低年1回の机上演習、日時と参加者を記録
プロンプトログの保持ポリシーには何を含めるべきか
プロンプトログは、ユーザーが他の業務システムに入力するのと同じ機密情報を含むことが多く、LLMスタックが生成する中で最もリスクの高いデータである。 書面での保持ポリシー(保持期間、アクセス可能者、削除方法)は監査人が具体的に確認する統制であり、一般的なデータ保持ポリシーからの推測では不十分。
- 保持期間:「無期限」ではなく具体的な日数/月数を定義する
- アクセス制御:プロンプトログ保管には一般ログとは別の限定アクセスリストを設ける
- 最小化:通常はメタデータのみログ記録し、全文ログは正当な理由があり期間限定の場合のみ
- 削除プロセス:文書化し、可能であれば自動化する
推論サーバーをネットワーク上でどうセグメント化すべきか
推論サーバーは、一般的なアプリケーションサーバーと同一サブネットに置くのではなく、認証済みゲートウェイ経由でのみ到達可能な専用ネットワークゾーンに配置すべき。 これにより他サービスが侵害された場合の影響範囲を限定し、監査人に明確なネットワーク図を提示できる。
どのセルフホストツールが監査関連統制を提供するか
一般的な推論エンジンはいずれも完成した監査証跡を提供しない。違いは自ら構築すべき範囲とプラットフォームが既に提供する範囲の割合にある。 これは対応度の比較であり、いずれかのツールに関するコンプライアンス上の主張ではない。
| ツール | 組み込み認証/ログ | 必要な計装 |
|---|---|---|
| Ollama | なし(localhostにバインド) | リバースプロキシ+認証+SIEM連携 |
| vLLM | Prometheusメトリクスのみ | APIゲートウェイ(OAuth2/キー)+監査ログ |
| Hugging Face TGI | Prometheusメトリクスのみ | vLLMと同様、ゲートウェイ+監査ログ |
| エンタープライズプラットフォーム | RBAC+監査ログを標準搭載 | それでもISMS文書化は必要 |
コンプライアンス自動化プラットフォームはセルフホストLLMに役立つか
コンプライアンス自動化プラットフォーム — Vanta、Drata、Secureframeが最も利用されている3つ — はクラウドインフラ、人事システム、IDプロバイダーから証跡を自動収集するが、セルフホストのオンプレミス推論サーバーは通常デフォルトの連携リストの対象外。
会社全体でより広いSOC 2/ISO 27001プログラムを運用しており、セルフホストLLM層以外を継続的に監視したい場合はコンプライアンス自動化プラットフォームの利用を検討する。
| プラットフォーム | 特徴 |
|---|---|
| Vanta | 幅広いフレームワーク対応、スタートアップで一般的 |
| Drata | 継続的な統制監視、深い連携 |
| Secureframe | SOC 2とISO 27001を統合したワークフロー |
これらのプラットフォームはより広い統制環境の証跡収集を自動化するものであり、セルフホストLLMインフラそのものを認証するものではない。PromptQuorumはこれらいずれとも現時点でアフィリエイト関係はない(開示済みの製品リンクのみ)。
監査対応でよくある間違いは何か
セルフホストLLMの監査指摘の多くは、根本的に統制が欠けているのではなく、推論サーバーを通常のITコントロール環境の外として扱うことから生じる。
- 間違い: オープンソースツールが「監査可能(ソース公開)」であることを、既に監査済みだと誤解する。修正: 公開元と配信スタックの独自リスクアセスメントを文書化する。
- 間違い: 「社内からしかアクセスできないから」とゲートウェイなしで推論APIを公開したままにする。修正: ネットワーク到達可能性とアクセス制御は別の論点。認証を追加する。
- 間違い: 稼働監視用アクセスログにプロンプト全文を混在させる。修正: 保管を分離し、内容を含むログには厳格なアクセス制御と短い保持期間を適用する。
- 間違い: モデルバージョンの切替を承認履歴なしの定型デプロイとして扱う。修正: コードデプロイと同じ変更管理承認を適用する。
- 間違い: モデル配信固有の障害モード(重み改ざん、プロンプトインジェクション)向けインシデント対応計画がない。修正: 既存のIR計画にこれらのトリガーを追加し、少なくとも一度テストする。
セルフホストLLMの監査準備チェックリストとは
監査人の現地調査が始まる前にこのチェックリストを実施すること — 各項目は上記で扱った統制カテゴリに対応する。
- 1セルフホストLLMシステムをISMS/SOC 2の範囲声明に追加する
Why it matters: 技術統制がすべて整っていても、範囲内で未文書化のシステムは指摘事項となる。 - 2関連するTrust Services CriteriaまたはAnnex A統制を実際のスタックにマッピングする
Why it matters: 監査人は提供されたマッピングに基づいてテストするため、不完全なマッピングは未検証の欠落を生む。 - 3すべての推論エンドポイントの前段に認証済みゲートウェイを設置する
Why it matters: 最も多い単一の指摘事項である認証なしモデルAPIを解消する。 - 4呼び出し元IDとタイムスタンプ付きの構造化リクエストログを有効化する
Why it matters: セキュリティ基準で監査人が要求する主要な証跡。 - 5ホストディスクとプロンプトログ保管を暗号化し、ゲートウェイでTLSを強制する
Why it matters: 機密性基準とAnnex A.8.24暗号統制を満たす。 - 6モデルバージョン更新の変更管理手順を作成し遵守する
Why it matters: 処理の完全性を証明し、文書化されたロールバック経路を提供する。 - 7本番稼働中の各オープンウェイトモデルについてベンダーリスク評価を文書化する
Why it matters: 最も見落とされがちな統制、モデル自体のサプライチェーンリスクを閉じる。 - 8プロンプト/レスポンスログの保持・削除ポリシーを公開する
Why it matters: プロンプトに個人データが含まれる場合、プライバシー基準で直接必要となる。 - 9推論サーバーを専用ネットワークゾーンにセグメント化する
Why it matters: 影響範囲を限定し、監査人に明確なネットワーク図を提供する。 - 10モデル固有のトリガーを含むインシデント対応手順書を作成し一度テストする
Why it matters: 監査人は計画が存在し実施されたことを確認する。単なる作成では不十分。
よくある質問
本記事は法的・コンプライアンス助言ですか?
いいえ。本ガイドはSOC 2やISO 27001の監査人が一般的に確認する統制のカテゴリを技術的な観点で説明するものです。資格を持つ監査人やコンプライアンス部門の代わりにはなりません。監査を計画する前、またはコンプライアンス状況について主張する前に、必ず専門家にご相談ください。
Ollama、vLLM、Hugging Face TGIを使えばAIインフラはSOC 2準拠になりますか?
単一のツールが組織を準拠にすることはありません。コンプライアンスは組織全体の統制セットに対する監査結果です。Ollama、vLLM、TGIは認証・ログ・暗号化を追加すれば技術要件を支えられますが、ソフトウェア製品として「SOC 2準拠」「ISO 27001認証済み」ではありません。
AIインフラにおけるSOC 2 Type IとType IIの違いは何ですか?
Type Iはある一時点で統制が適切に設計されていたかを評価します。Type IIは通常6〜12か月のレビュー期間にわたって統制が効果的に機能していたかを評価します。推論エンドポイントでは、Type IIはアクセスログや変更管理記録が監査当日だけでなく期間を通じて継続的に存在する必要があることを意味します。
ソフトウェアベンダーが存在しないオープンウェイトモデルでもベンダーリスク評価は必要ですか?
はい。モデル公開元(Meta、Mistral AI、Alibaba/Qwenなど)はSaaSベンダーと同様のサプライチェーン当事者です。文書化されたリスクアセスメントには公開元の身元、ダウンロードした重みのチェックサム検証、ライセンス条件、モデルを読み込む配信スタックの既知CVEを含めるべきです。
LLMをセルフホストすることでクラウドLLM APIと比べて監査範囲は縮小しますか?
単純に縮小するのではなく、範囲が変化します。セルフホストはクラウドAPIが生む第三者データ処理者関係をなくしベンダーリスク項目を簡素化できますが、同時にクラウドベンダーが担っていたアクセス制御、暗号化、パッチ適用、ログ記録などすべての統制を組織自身が担うことになります。
推論エンドポイントで監査人はどのようなログを期待しますか?
最低限、呼び出し元ID(APIキーまたは認証済みユーザー)、タイムスタンプ、呼び出したモデルとバージョン、エンドポイント、レスポンスステータスを書き込み制限のあるログストアに出力することです。プロンプト・レスポンスの全文は、通常は独自の保持ポリシーを持つより厳格なアクセス制御下の別ストアに保管します。
監査証跡としてプロンプトログはどのくらい保持すべきですか?
普遍的な数字はありません。組織のリスクアセスメント、監査人の期待、適用されるプライバシー法のデータ最小化原則とのバランスによって決まります。「無期限」ではなく具体的な保持期間を書面で定義し、全文プロンプトを含むログにはより厳格なアクセス制御を適用し、その期間を監査人に説明できるようにしてください。
Vanta、Drata、SecureframeのようなプラットフォームはセルフホストLLMサーバーを監視できますか?
クラウドインフラ、IDプロバイダー、チケットシステムに対する証跡収集の自動化には優れていますが、セルフホストのオンプレミス推論サーバーは通常デフォルトの連携対象外です。多くのチームはそのシステムについてカスタムAPI連携を構築するか、証跡を手動でアップロードし、それ以外の統制環境はプラットフォームに自動化させています。
セルフホストAIインフラで最も多い単一の監査指摘は何ですか?
「社内ネットワークからしか到達できないため」という理由で認証なしのまま公開された推論APIです。ネットワーク到達可能性とアクセス制御は別の論点であり、監査人はネットワーク上の配置にかかわらずエンドポイントでの認証を期待します。
監査対応を容易にするにはvLLM/TGIとエンタープライズ推論プラットフォームのどちらを選ぶべきですか?
vLLMとHugging Face TGIは完全な制御を提供しますが、認証・ログ・暗号化層を自ら構築する必要があります。エンタープライズ推論プラットフォームはRBACと監査ログを標準搭載していることが多く、カスタム計装の作業を減らせますが、いずれの場合も周辺のISMS文書化とベンダーリスク評価は必要です。どちらか一方がコンプライアンスの近道になるわけではなく、計装層を自社で構築するか購入するかで選んでください。
追加情報源はどこで確認できますか
- AICPA SOC 2 Trust Services Criteria(aicpa-cima.com) — SOC 2監査が評価される公式Trust Services Criteriaフレームワーク
- ISO/IEC 27001:2022(iso.org) — 公式規格本文とAnnex A統制リファレンス
- OWASP Top 10 for LLM Applications(owasp.org/www-project-top-10-for-large-language-model-applications) — サプライチェーン・プロンプトインジェクションリスクを含むLLMデプロイ固有のセキュリティリスク