機密情報を保護する「コンフィデンシャル・コンピューティング」上でのLLM実行基盤の構築

『使用中』データも暗号化せよ：AWS Nitro Enclavesで構築するセキュアなLLM推論基盤の実装詳解

2026年1月5日更新 2026年2月22日約12分で読めます

文字サイズ:

『使用中』データも暗号化せよ：AWS Nitro Enclavesで構築するセキュアなLLM推論基盤の実装詳解

この記事の要点

LLMにおける「使用中」データの機密性確保
コンフィデンシャル・コンピューティングの基本概念
TEE（Trusted Execution Environment）の活用

生成AIの導入において、特に金融や医療、製造業などの分野で頻繁に課題となるのが「セキュリティ審査」です。

「RAG（検索拡張生成）で社内規定を検索させたいが、データが外部に漏れるのは困る」「プロンプトに含まれる個人情報が、クラウド事業者の管理者に見られる可能性はゼロなのか？」

これらの懸念に対し、データを保存する際の「ディスク暗号化」や、送受信時の「通信暗号化」だけでは、十分な対策とは言えなくなっています。なぜなら、大規模言語モデル（LLM）が回答を生成（推論）するまさにその瞬間、データはコンピュータのメモリ上で暗号化されていない状態（平文）で展開されているからです。

そこで今、実装レベルで求められているのが「コンフィデンシャル・コンピューティング」による「使用中のデータ（Data in Use）」の保護です。

本記事では、理論だけでなく実践的なアプローチとして、AWS Nitro Enclavesを例に挙げ、機密情報を安全に扱うためのLLM推論基盤の構築手順をコードを交えて分かりやすく解説します。セキュリティとAIを両立させる技術の核心を見ていきましょう。

なぜ「暗号化」だけでは不十分なのか：Data in Use保護の必要性

一般的に利用されている「暗号化」は、データを保管している時や通信している時の保護を目的としています。しかし、コンピュータの頭脳であるCPUがデータを処理するためには、一度メモリ上で暗号を解く（復号する）必要があります。実は、この「暗号が解かれた瞬間」こそが、現在のセキュリティにおいて最も狙われやすい弱点となっています。

メモリ内データの脆弱性とTEEの役割

もし悪意のある第三者がシステムの管理者権限を奪ったり、クラウド事業者の内部に不正を働く者がいたりした場合、メモリの内容を丸ごと読み取る手法（メモリダンプ）を使えば、入力されたプロンプトや生成された回答、さらにはAIモデルの重要なデータまで抜き出されてしまうリスクが理論上存在します。

このリスクを防ぐための技術が、TEE（Trusted Execution Environment：信頼された実行環境）です。TEEは、コンピュータの物理的な仕組み（ハードウェア）を利用して、通常のシステムから完全に切り離された安全な小部屋（エンクレーブ）を作ります。この小部屋の中のメモリは専用の鍵で強力に暗号化されているため、たとえシステムの最高権限（root権限）を持っていたとしても、外から中身を覗き見ることはできません。

コンフィデンシャル・コンピューティングがLLM活用をどう変えるか

LLMにおいてTEEを採用するメリットは、単なる漏洩防止だけではありません。

データの主権性確保: クラウド事業者でさえアクセスできない環境を構築することで、自社専用のサーバー（オンプレミス）と同等の高い機密性を保ちながら、クラウドならではの柔軟な拡張性を活用できます。
マルチパーティ計算: 例えば、データ提供元の機密データと、AI開発元の独自LLMを、互いに中身を見せることなく掛け合わせて推論するといったビジネスモデルが可能になります。

事前準備：TEE対応クラウドインスタンスの選定と環境要件

具体的な実装に入る前に、利用するプラットフォームの選定と環境構築を行います。今回は、公式の技術文書が充実しており試しやすいAWS Nitro Enclavesを例に解説しますが、他のクラウドサービス（Azure Confidential Computingなど）でも基本的な考え方は同じです。

主要プロバイダーの対応状況とLLMへの適合性

LLMを動かす上で最大の課題は「GPUのサポート」です。

AWS Nitro Enclaves: 現時点では、主にCPUを利用した環境が主流です。GPUをこの安全な小部屋に割り当てることは技術的な難易度が高いため、処理速度よりも機密性を最優先したい場合や、計算量を減らした小規模なモデル（量子化モデルなど）をCPUで動かす用途に適しています。
Azure Confidential Computing: 高性能なGPUを搭載した機密性の高い仮想マシン（Confidential VM）を提供しており、GPUの計算力を活かした高速な処理が可能です。処理速度を重視する場合は、こちらが有力な選択肢となります。最新の対応状況は公式の技術文書をご参照ください。

今回は、仕組みの理解と実装の汎用性を重視し、AWS Nitro Enclavesでの構築手順を進めます。

必要なツールセットと権限設定

まず、土台となるサーバー（親インスタンス）を立ち上げます。AWSでNitro Enclavesを有効にするには、以下の条件を満たす必要があります。

インスタンスタイプ: c5、m5、r5などのNitro世代のインスタンス（最低でも4つの仮想CPUを推奨します。LLMを動かす場合は、メモリ容量の大きいr5.2xlarge以上が適しています）。
OS: Amazon Linux 2023 または Amazon Linux 2 (AL2)。
Enclave有効化: インスタンス起動時に詳細設定で「Nitro Enclave: 有効」にチェックを入れます。

インスタンスにSSH接続し、必要なCLIツールをインストールします。

# Nitro Enclaves CLIのインストール
sudo dnf install aws-nitro-enclaves-cli aws-nitro-enclaves-cli-devel -y

# ユーザーをグループに追加
sudo usermod -aG ne ec2-user
sudo usermod -aG docker ec2-user

# 設定反映のため再ログインが必要
exit

次に、安全な小部屋（エンクレーブ）に割り当てるCPUとメモリの量を、設定ファイル（/etc/nitro_enclaves/allocator.yaml）に記述します。LLMの処理には多くのメモリが必要となるため、親インスタンスのメモリの大部分をエンクレーブに割り当てます。

# /etc/nitro_enclaves/allocator.yaml
# 例: r5.2xlarge (8 vCPU, 64GB RAM) の場合
# 親に2vCPU/4GBを残し、残りをエンクレーブへ
cpu_count: 6
memory_mib: 55000

設定後、アロケーターサービスを起動します。

sudo systemctl start nitro-enclaves-allocator.service
sudo systemctl enable nitro-enclaves-allocator.service

Step 1：LLM推論コンテナのエンクレーブ化（EIFビルド）

事前準備：TEE対応クラウドインスタンスの選定と環境要件 - Section Image

ここから具体的な実装に入ります。まずは、一般的に使われるDockerコンテナを、Nitro Enclavesの隔離された環境で動かせる専用の形式（EIF：Enclave Image File）に変換する手順を見ていきましょう。

AWS環境における機密計算の実装方法は日々洗練されていますが、「コンテナの作成」→「EIFへの変換」→「識別値（PCR値）の取得」という基本的な流れは一貫しています。

推論サーバーのコンテナ構成

今回は、限られたリソースでも効率よくLLMを動かすために、llama.cppという軽量なライブラリをPythonから利用する（llama-cpp-python）シンプルなサーバーを構築します。この構成は、GPUが使いにくいエンクレーブ環境でも実用的な速度が出やすいため、実証実験などでもよく採用される手法です。

まず、エンクレーブの中で動き、VSock（仮想ソケット：隔離環境と通信するための専用経路）を通じてリクエストを受け取るPythonプログラム（server.py）を作成します。

# server.py (VSock対応推論サーバー)
import socket
import json
import os
from llama_cpp import Llama

# モデルパスの設定（コンテナ内のパス）
MODEL_PATH = os.getenv("MODEL_PATH", "/app/model.gguf")

# Llamaモデルのロード
# n_ctx: コンテキストウィンドウサイズ（用途に応じて調整）
llm = Llama(model_path=MODEL_PATH, n_ctx=2048, verbose=False)

def handle_request(conn):
    try:
        data = conn.recv(4096).decode()
        if not data:
            return
        
        request = json.loads(data)
        prompt = request.get("prompt", "")
        max_tokens = request.get("max_tokens", 100)
        
        # 推論実行
        output = llm(prompt, max_tokens=max_tokens)
        
        # 結果をJSONとして返送
        response = json.dumps(output)
        conn.sendall(response.encode())
    except Exception as e:
        error_msg = json.dumps({"error": str(e)})
        conn.sendall(error_msg.encode())

def main():
    # VSockのアドレスファミリを使用
    # CID: Any (受信), Port: 5000 (任意のポート)
    sock = socket.socket(socket.AF_VSOCK, socket.SOCK_STREAM)
    sock.bind((socket.VMADDR_CID_ANY, 5000))
    sock.listen()
    
    print("Enclave server listening on VSock port 5000...")
    
    while True:
        try:
            conn, _ = sock.accept()
            handle_request(conn)
            conn.close()
        except Exception as e:
            print(f"Connection error: {e}")

if __name__ == "__main__":
    main()

Dockerfileの作成

次に、コンテナの設計図となるDockerfileを作成します。ここで最も重要なポイントは、機密データであるAIモデルのファイル（重みデータ）をどのように扱うかを決定することです。

イメージに含める（今回採用する方法）: コンテナを作成する段階でモデルファイルを組み込みます。プログラムとデータが一体化するため、後述する識別値（PCR値）によって「正しいモデルが使われているか」まで確実に証明できます。ただし、コンテナのデータサイズは大きくなります。
実行時に読み込む: 暗号化されたモデルを外部のストレージ（S3など）から取得し、エンクレーブの中で暗号を解きます。コンテナのサイズは小さくなりますが、暗号を解くための鍵を安全に管理する仕組みが別途必要になります。

今回は、セキュリティの確実性を最優先し、モデルのデータごとコンテナに組み込む「1」のアプローチで進めます。

# 軽量なPythonベースイメージを使用（バージョンはプロジェクトに合わせて調整）
FROM python:3.11-slim

WORKDIR /app

# 必要なシステムライブラリのインストール（ビルドツール等が必要な場合）
RUN apt-get update && apt-get install -y --no-install-recommends \
    build-essential \
    && rm -rf /var/lib/apt/lists/*

# Pythonライブラリのインストール
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

# モデルファイルとスクリプトのコピー
# GGUF形式の量子化済みモデルをローカルに用意しておくこと
COPY model.gguf .
COPY server.py .

# 環境変数の設定（バッファリング無効化など）
ENV PYTHONUNBUFFERED=1

# 起動コマンド
CMD ["python", "server.py"]

Enclave Image File (EIF) への変換

Dockerイメージを作成した後、AWSが提供する専用ツール（nitro-cli）を使ってEIF形式に変換します。この作業によって、通常のコンテナが、改ざんされていないことを証明できる安全なイメージへと変換されます。

# 1. Dockerイメージのビルド
docker build -t llm-enclave:latest .

# 2. EIFへの変換ビルド
nitro-cli build-enclave \
  --docker-uri llm-enclave:latest \
  --output-file llm-enclave.eif

変換が完了すると、画面にPCR（Platform Configuration Register）と呼ばれる値が表示されます。

PCR0: イメージのSHA384ハッシュ（コンテンツ全体の指紋）
PCR1: カーネルとブートストラップのハッシュ
PCR2: アプリケーションのハッシュ

重要：これらのPCR値（特にPCR0）は必ずメモしておいてください。
これは、作成したイメージの「デジタルな指紋」として機能します。後ほど行う「構成証明（アテステーション）」という手順で、暗号鍵の管理サービス（KMS）に対し「この指紋を持つ安全な環境からの要求だけを許可する」というルールを設定するために不可欠な情報です。もしイメージ内のデータがほんの少しでも書き換えられれば、このPCR値は全く違うものに変化するため、改ざんを確実に検知できます。

Step 2：リモートアテステーション（構成証明）の実装

ここが機密計算の核心部分です。「現在動いているプログラムは、本当に意図して作成した安全なイメージ（EIF）なのか？」ということを、暗号技術を用いて数学的に証明します。

「誰が実行しているか」を証明する仕組み

AWSの暗号鍵管理サービス（KMS）と連携させることで、「事前に登録した正しい指紋（PCR値）を持つエンクレーブからの要求に対してのみ、暗号を解くための鍵を渡す」という厳密な制御が可能になります。

KMSキーポリシーの設定

AWSの管理画面でKMSキーを作成し、その利用ルール（キーポリシー）に特定の「条件」を追加します。これにより、正しいイメージを実行しているエンクレーブだけが、この鍵を使ってデータを復号（kms:Decrypt）できるようになります。

{
    "Sid": "Allow enclave to decrypt",
    "Effect": "Allow",
    "Principal": {
        "AWS": "arn:aws:iam::YOUR_ACCOUNT_ID:role/YOUR_INSTANCE_ROLE"
    },
    "Action": "kms:Decrypt",
    "Resource": "*",
    "Condition": {
        "StringEqualsIgnoreCase": {
            "kms:RecipientAttestation:ImageSha384": "[ここにビルド時にメモしたPCR0の値をペースト]"
        }
    }
}

この設定を行えば、仮に悪意のある操作者がイメージを改ざんしてシステムを起動しようとしても、指紋であるPCR0の値が変化してしまうため、KMSは鍵の引き渡しを拒否します。このように、システムの設定やコード自体によって安全性を強制する仕組みが実現できます。

Step 3：セキュアな推論APIの立ち上げと動作検証

Step 2：リモートアテステーション（構成証明）の実装 - Section Image

最後に、安全な小部屋（エンクレーブ）を起動し、親インスタンスと通信させてみましょう。エンクレーブにはIPアドレスが割り当てられず、インターネットなどの外部ネットワークからは完全に遮断されています。外の世界とやり取りする唯一の手段が、VSock（仮想ソケット）と呼ばれる内部専用の通信経路です。

VSockを使用したホスト-エンクレーブ間通信

エンクレーブを起動します。

nitro-cli run-enclave \
  --cpu-count 6 \
  --memory 55000 \
  --eif-path llm-enclave.eif \
  --enclave-cid 16 \
  --debug-mode # 本番では外す

ここで指定している--enclave-cid 16は、エンクレーブの識別番号（CID）です。親インスタンス（標準でCID=3）から、このCID=16のエンクレーブに向けて、VSock経由でデータを送信することになります。

親インスタンス側で動作するクライアントスクリプト client.py を作成します。

# client.py
import socket
import json

# エンクレーブのCIDとポート
CID = 16
PORT = 5000

def query_enclave(prompt):
    # VSockソケット作成
    s = socket.socket(socket.AF_VSOCK, socket.SOCK_STREAM)
    s.connect((CID, PORT))
    
    # リクエスト送信
    payload = json.dumps({"prompt": prompt})
    s.sendall(payload.encode())
    
    # レスポンス受信
    response = s.recv(4096).decode()
    s.close()
    return response

print(query_enclave("機密プロジェクトXの進捗について要約して。"))

機密データを送信しての推論テスト

これで、以下のフローが完成しました。

親インスタンスからclient.pyを使って質問（プロンプト）を送信します。
データはVSockを経由して、隔離されたエンクレーブに届きます。
エンクレーブ内の安全なメモリ上でのみデータが展開され、LLMが回答を生成します。
生成された回答の結果だけが、親インスタンスに返却されます。

この仕組みを構築すれば、親インスタンス側で通信内容を盗み見よう（パケットキャプチャ）としても、VSockを通るデータやエンクレーブ内のメモリの状態を読み取ることはできません。実証データとしても、この隔離環境の堅牢性は高く評価されています。

運用とトラブルシューティング：実環境での注意点

実際にこの仕組みを運用していくと、いくつかの課題に直面することがあります。中でも、不具合の原因を特定する「デバッグ作業の難しさ」は、多くの現場で共通する課題です。

エンクレーブ特有のデバッグの難しさへの対処

エンクレーブの中にはSSHなどで直接ログインすることができず、プログラムの動作記録（ログ）も標準状態では確認できません。もし「うまく動かない」と感じた場合は、まずは検証用の--debug-modeで起動し、nitro-cli consoleコマンドを使って内部の出力状況を確認するアプローチが有効です。

# エンクレーブのコンソールIDを取得して接続
ENCLAVE_ID=$(nitro-cli describe-enclaves | jq -r .[0].EnclaveID)
nitro-cli console --enclave-id $ENCLAVE_ID

ただし、実際の運用環境（本番環境）では、セキュリティの観点から--debug-modeは必ず無効化する必要があります。そのため、本番運用に向けては、プログラム内で発生したログをVSock経由で親インスタンス側に転送し、そこで収集・監視する仕組みをあらかじめ実装しておくことが重要です。

モデル更新時の運用フロー

LLMモデルを更新する場合、以下の手順が必要です。

新しいモデルを組み込んだDockerイメージを再作成します。
EIF形式への変換を行い、新しいPCR値（指紋）を取得します。
KMSの利用ルール（キーポリシー）を更新し、新しいPCR値を許可リストに追加します。
エンクレーブを再起動して変更を反映させます。

この一連のPCR値の更新作業を、システムの自動展開の仕組み（CI/CDパイプライン）に組み込んで自動化することが、日々の運用負担を軽減し、人為的なミスを防ぐための鍵となります。

まとめ

Dockerビルド - Section Image 3

コンフィデンシャル・コンピューティング技術は、これまで「情報漏洩のリスク」を懸念して生成AIの導入を見送っていた組織にとって、状況を打破する強力な解決策となります。AWS Nitro Enclavesのような仕組みを活用すれば、物理的に隔離された「安全な聖域」にLLMを配置し、処理中のデータまでも確実に保護することが可能です。

もちろん、CPUを利用することによる処理速度の制約や、システム構築の複雑さといった課題は存在します。しかし、機密データを安全に扱えるという事実に基づいた信頼性の向上や、厳格なセキュリティ基準（コンプライアンス）を満たせるという価値は、導入にかかる労力を大きく上回るメリットをもたらします。

まずは、今回解説したような最小限の構成（CPUで動く小規模なLLM）で検証環境（PoC）を構築し、実際のデータを用いて「技術的に裏付けられた安全性」を確認することから始めてみることをおすすめします。実証に基づいた確実なステップを踏むことが、組織全体での安全なAI活用の第一歩となるはずです。

『使用中』データも暗号化せよ：AWS Nitro Enclavesで構築するセキュアなLLM推論基盤の実装詳解 - Conclusion Image

コメントは1週間で消えます

コメントを読み込み中...