AES-256

暗号化における位置づけ

AES（Advanced Encryption Standard）は 2001 年に NIST が連邦情報処理標準（FIPS 197）として採択したブロック暗号で、128 ビット固定のブロック長に対して 128 / 192 / 256 ビットの 3 つの鍵長を選択できる。このうち AES-256 は鍵長が最も長く、理論上の総当たり探索に 2^{256} 回の試行が必要になるため、量子コンピュータの脅威を含めても当面は安全とされる。

金融機関の口座データ、医療記録、政府の機密情報など「漏洩した場合のインパクトが極めて大きい」データの保護に採用されるケースが多い。AWS S3 のサーバーサイド暗号化（SSE-S3）や Apple の iMessage もデフォルトで AES-256 を使用している。

仕組みを直感的に理解する

AES-256 は平文を 128 ビット（16 バイト）のブロックに分割し、各ブロックに対して 14 ラウンド の変換を適用する。各ラウンドではバイト置換（SubBytes）、行シフト（ShiftRows）、列混合（MixColumns）、ラウンド鍵加算（AddRoundKey）という 4 つの操作を組み合わせる。鍵長が 128 ビットなら 10 ラウンド、256 ビットなら 14 ラウンドとラウンド数が増える分、暗号の拡散効果が高まる。

筆者が暗号を学び始めた頃、「ラウンド数が多い＝遅い」と思い込んでいたが、現代の CPU は AES-NI 命令セットでハードウェアアクセラレーションを備えており、ソフトウェア実装と比較して数倍〜十数倍の速度が出る。実務でパフォーマンスが問題になることはほとんどない。

AES-128 との使い分け

セキュリティ上、AES-128 でも現時点では十分な強度がある。両者の選択は「規制要件」と「将来の脅威モデル」で決まることが多い。

• AES-256 を選ぶ場面: PCI DSS・HIPAA など規制が明示的に 256 ビットを求める場合、または量子コンピュータ時代を見据えた長期保存データ
• AES-128 で十分な場面: 通信の一時的な暗号化（TLS セッション鍵など）、レイテンシが極めて重要なリアルタイム処理

なお、鍵長を 256 ビットにしても、鍵管理が杜撰であれば意味がない。暗号アルゴリズムの強度より鍵の保管・ローテーション運用の方が実務上のリスクになりやすい点は押さえておきたい。

AI・クラウド分野での活用

LLM の推論 API では、ユーザーのプロンプトやレスポンスが通信経路上で暗号化される。TLS 1.3 のハンドシェイクで合意される共通鍵に AES-256-GCM が使われるケースが一般的で、保存時暗号化（encryption at rest）にも同じアルゴリズムが採用される。プライバシー・バイ・アイソレーションの設計思想でテナントごとにデータを分離する場合も、ストレージ層の暗号化に AES-256 が標準的に用いられる。

エッジAI デバイスでは計算リソースが限られるが、前述の AES-NI 相当のハードウェアサポートを持つ SoC が増えており、組み込み環境でも AES-256 のオーバーヘッドは許容範囲に収まりつつある。