AES暗号とは？歴史・仕組み・GCMまで

WebをHTTPSで開き、Wi‑Fiに接続し、ノートPCのディスク暗号化を有効にする。
ふだん何気なく触れているこの3つの動作の奥には、同じ名前の暗号がいます。
AESは、128ビットのブロックを扱い、鍵長に128・192・256ビットを持つ共通鍵ブロック暗号で、2001年にFIPS 197として標準化された方式です（FIPS 197: の AES プロジェクト概要も参照できます（NIST AES:

筆者の経験に基づく観察です。実装検証の現場では、AESそのものよりも「どのモードで、どう鍵やnonceを扱ったか」が安全性を左右する場面を何度も見てきました。

ここが暗号の美しいところなのですが、AESの核心は「強いアルゴリズム名を知ること」では終わりません。
TLS 1.3、無線LAN、ストレージ暗号化といった実例に結びつけながら、AES本体と運用の境界を分けて捉えると、なぜ現代でも標準であり続けるのかが腑に落ちます。

AES暗号とは何か：共通鍵暗号の標準をひとことで整理する

共通鍵暗号とは

ブラウザの接続情報を開くとTLS_AES_128_GCM_SHA256のような文字列が出てきたり、家庭用ルーターの設定画面でAESという表記を見かけたりします。
このとき筆者が最初に腑に落ちたのは、「AESは製品名でも通信サービス名でもなく、暗号アルゴリズムの名前だ」という整理でした。
Google ChromeやWindowsがそのまま暗号なのではないのと同じで、Wi‑FiやTLSも仕組み全体の名前であり、その内部でAESが部品として使われます。

共通鍵暗号は、暗号化と復号に同じ鍵を使う方式です。
英語では symmetric-key encryption、対称鍵暗号とも呼ばれます。
送る側と受け取る側があらかじめ同じ秘密の鍵を共有しておき、その鍵でデータを読めない形に変え、同じ鍵で元に戻します。
大量のデータを高速に処理できるので、実運用では通信の本文や保存データの保護に広く使われます。

ただし、ここには古典的な難しさもあります。
相手とどうやって安全に同じ鍵を持つのか、という鍵配送の問題です。
参加者が増えるほど管理すべき鍵の数も増え、全員が個別に共有する完全メッシュ構成では必要鍵数は n×(n−1)/2 になります。
この事情があるため、現代の通信では公開鍵暗号で共通鍵を安全に共有し、その後の大量データは共通鍵暗号で処理する、という役割分担が定着しています。

AESは、その共通鍵暗号の中でも現在の標準的な方式です。
ひとことで言えば、AESは共通鍵暗号に属するブロック暗号です。
この「共通鍵」と「ブロック暗号」は別の切り口なので、次で分けて押さえると混乱しません。

ブロック暗号とは

ブロック暗号は、データを一定サイズの塊に区切って変換する暗号です。
AESではその塊、つまりブロックの大きさが128ビットに固定されています。
鍵長は128・192・256ビットの3種類で、対応してラウンド数は 10・12・14 です。

ここで見落としやすいのは、AES本体が定義しているのは1ブロックごとの変換規則だという点です。
平文128ビットを受け取り、鍵を使って暗号文128ビットへ写す。
この変換を安全に行うために、内部ではSubBytesShiftRowsMixColumnsAddRoundKeyといった操作を組み合わせます。
数学的にはこれがAESの核心ですが、実務ではそれだけでは足りません。
ファイルや通信データは128ビットでは収まらないからです。

そこで必要になるのが動作モードです。
CBCCTRGCMのようなモードは、AESという1ブロック変換をどう並べて長いデータ全体を扱うか、初期値として何を使うか、改ざん検出まで含めるか、といった設計を受け持ちます。
つまり、AESはエンジンであり、モードは走らせ方です。

この層を分けて考えると、ブラウザで見えるAES-GCMという文字列の意味も明確になります。
そこに書かれているのは「AESというブロック暗号をGCMモードで使っている」という意味であって、AES単体が長文の通信や認証まで全部を面倒見ているわけではありません。
TLS 1.3で使われる暗号スイートでも、暗号スイート名はレコード保護のAEADを表し、鍵交換や署名方式とは切り離されています。
Wi‑Fiでも事情は同じで、AES対応と書かれていても、実際に使われているのはCCMPやGCMPのようなプロトコル側の構成です。

なお、モードごとに性質は異なります。
GCMは機密性に加えて完全性と認証を持つAEADです。
CBCやCTRは暗号化自体はできますが、改ざん検出は別の仕組みが必要です。
とくにCTRやGCMでは同じ鍵でnonceやIVを再利用すると安全性が崩れるので、AESの名前だけ見て安心するのは危うい、というのが実装検証の現場でも繰り返し現れる論点でした。

AESとRijndaelの関係

AESとRijndaelはしばしば同じもののように扱われますが、厳密には一致しません。
Rijndaelは設計者が提出した元の暗号アルゴリズム・ファミリーで、ブロック長や鍵長に柔軟性がありました。
その中から、128ビットブロック仕様を米国標準として採用したものがAESです。

歴史の流れを短くつなぐと、DESの後継を選ぶために公募が始まり、2000年にRijndaelが選定され、2001年に FIPS 197 として標準化されました。
この「2000年選定」と「2001年標準化」が混同されやすいのですが、整理すると話は素直です。
選ばれた年と、規格として確定した年が違うだけです。

この差は単なる名称の細部ではありません。
暗号を学び始めた頃は、筆者も「AES = Rijndaelでいいのでは」と思っていました。
ところが実装や仕様書を追うと、標準文書が指しているのはあくまでAES、つまりRijndaelのうち標準化された範囲です。
ここを曖昧にすると、「Rijndaelは可変ブロック長なのに、なぜAESは128ビット固定なのか」という初歩的な疑問で引っかかります。

実務で出会うのも、ほぼ常にAES仕様です。
AES-128AES-256という呼び方は鍵長の違いを指していて、ブロック長はどちらも128ビットのままです。
ここでの数字は「ブロック長」ではなく「鍵長」だと理解しておくと、用語のズレが一気に減ります。

ひと言サマリーと用語の層の違い

ひと言で固定するなら、AES=128ビットブロックの共通鍵ブロック暗号、鍵長128/192/256、2001年標準化です。
まずはこの定型句を頭に置くと、会話や仕様書の記述を追いやすくなります。

そのうえで、用語の層を分けると混乱が消えます。
AESはアルゴリズム名です。
TLSは通信プロトコル、Wi‑Fiは無線LANの規格群、CCMPGCMはAESの使い方を定めるモードやプロトコルです。
TLS_AES_128_GCM_SHA256のような表記は、さらにその上の暗号スイート名です。
つまり、アルゴリズム、モード、プロトコル、製品表示が同じ平面に並んでいるわけではありません。

この整理ができると、「ブラウザにAESと出ていた」「Wi‑Fi設定にAESがあった」という日常の表示も、過不足なく読めます。
そこに書かれたAESは、暗号の中心部品を指しているにすぎません。
長いデータをどう分割し、IVやnonceをどう管理し、改ざん検出をどこまで含めるかは別の層の設計です。
ここが暗号の美しいところで、名前は短いのに、実際の安全性はその周囲の構成まで含めて決まります。

なぜAESが必要になったのか——DESから標準交代まで

DESの56ビット鍵問題

AESが必要になった出発点は、旧標準DESの寿命が見えてきたことです。
DESは1977年に制定された共通鍵ブロック暗号で、当時としては実用的でしたが、中心的な弱点は56ビット鍵にありました。
鍵空間は 2^56 通りです。
制定当時は巨大に見えたこの数も、計算機の性能向上と並列計算の現実化によって、総当たり攻撃の対象として無視できない大きさになりました。

筆者はこの感覚を説明するとき、56ビット鍵を「10桁強のダイヤル錠」にたとえることがあります。
1桁増えるだけで試す組み合わせは10倍に膨らみます。
3桁の錠なら順番に回していけば現実的でも、10桁を超えた途端に話が変わる。
その一方で、計算機の側は人間の指とは違って、桁が増えても休まず並列に試し続けられます。
暗号の安全性はこの「組み合わせ爆発」と「計算能力の伸び」の綱引きで決まりますが、DESの56ビットは、その綱引きで押し込まれる側に回ってしまったわけです。

問題は鍵長だけではありません。
DESはブロック長や設計の時代背景も古く、現代のデータ量と実装環境に合わせた標準としては窮屈になっていました。
ここでいう「古い」は、単に昔の方式という意味ではなく、コンピュータの性能、ソフトウェア実装、ハードウェア実装、国際的な相互運用といった前提条件が、制定時と今とで別物になったということです。
旧世代の条件で作られた標準を、そのままインターネット時代の基盤に据え続けるのは無理がありました。

この流れの中で、DESの延命策としてTriple DESのような発想も使われましたが、根本的には新しい標準が必要でした。
そこで求められたのが、より長い鍵、より現代的な設計、そして広い環境で実装できる次世代の共通鍵暗号です。

AES公募の設計目標と評価軸

新標準は、密室で決める形ではなく公開の競争で選ばれました。
1997年、米国標準を所管するNISTがAES公募を開始します。
ここで狙われたのは、単に「DESより強い暗号」を1本選ぶことではありませんでした。
安全性、性能、実装容易性のバランスが取れた方式を、公募と公開評価の過程で選び出すことに意味がありました。

応募は21方式あり、そのうち要件に適合したものが15方式、さらに評価を経て最終候補は5方式に絞り込まれました。
この選抜過程が象徴的です。
暗号は理論上強ければ終わりではなく、ソフトウェアでもハードウェアでも実装でき、メモリや処理資源に無理がなく、国際的に使えることまで含めて標準たりえます。
研究室の紙の上で美しいだけでは足りず、現場の制約を飲み込めることが求められました。

ここが暗号の面白いところで、評価軸が一つではありません。
安全性が第一にあるのは当然として、処理速度が遅すぎれば通信や保存に広く使えませんし、実装が複雑すぎれば誤実装の温床になります。
暗号方式そのものが強くても、実装に乗せたときに扱いにくければ標準化の価値は落ちます。
AES公募は、その現実を正面から織り込んだプロセスでした。

この時点で、後のAESに通じる輪郭も見えています。
現代標準の共通鍵暗号には、強い数学的設計だけでなく、長期運用に耐える実装性と公開検証の蓄積が必要です。
AESはその条件を満たす形で生まれたのであって、偶然広まったわけではありません。

Rijndael採用の背景

最終的に2000年に選ばれたのがRijndaelです。
設計者の正式表記は Joan Daemen / Vincent Rijmen、日本語ではヨアン・ダーメン／ヴィンセント・レイメンと書かれることが多いです。
この2人が設計したRijndaelは、公開評価の中で安全性と実装効率の両面から高い評価を得て、AESの元になる方式として採用されました。

ここで一度、名称を丁寧に分けておくと混乱が減ります。
Rijndaelは元の暗号方式の名前で、柔軟なブロック長と鍵長を持つファミリーです。
一方のAESは、その中から128ビットブロック仕様を標準化したものです。
つまり、Rijndaelがそのまま丸ごとAESになったのではなく、標準として使う範囲が定められた、という関係です。

Rijndaelが採用された背景には、設計の見通しの良さもあります。
内部構造が比較的整理されており、ソフトウェア実装でもハードウェア実装でも扱いやすい。
暗号の標準では、この「強い」だけでなく「広く正しく実装できる」ことが効きます。
筆者も実装検証の文脈でAESを見るたびに、標準暗号は数式だけで勝負していないと感じます。
実装者にとっての明快さや性能上の納得感があるからこそ、OS、ブラウザ、通信機器、ストレージ装置まで同じ基盤を共有できます。

採用後、AESとして定まった仕様では、ブロック長は128ビットに固定され、鍵長は128・192・256ビットの3種類になりました。
この整理によって相互運用性が高まり、標準としての扱いやすさも増しています。
ここでの選定は、暗号研究の勝者を決めたというより、世界中の実装が乗れる共通基盤を決めた出来事でした。

年表: 1997/2000/2001

AESの成立は、年を分けて押さえると混同しません。とくに2000年は選定、2001年は標準化です。この2つは別の出来事です。

1. 1997年

NISTがAES公募を開始しました。DESの後継となる新しい共通鍵暗号標準を、公開の評価プロセスで選ぶ段階に入った年です。

1. 2000年

最終候補5方式の中からRijndaelが採用方式として選定されました。
ここで「AESに使う暗号方式」が決まりますが、この時点ではまだFIPSとしての正式発行前です。

1. 2001年

AESは FIPS 197 として標準化されました。ここで初めて、AESが公式な標準文書として確定します。

この並びを押さえると、「AESは2000年に決まったのか、2001年にできたのか」という引っかかりが消えます。
2000年にRijndaelが選ばれ、2001年にAESとして文書化された、という二段階です。
歴史を正確に追うと、AESは単なる新アルゴリズムではなく、DESの限界を受けて、公開公募、比較評価、方式選定、標準文書化という手順をきっちり踏んで登場した標準だと見えてきます。

AESの仕組みを直感でつかむ——4つの操作でデータをかき混ぜる

StateとS-boxのイメージ

AESの内部を直感でつかむなら、まず平文ブロックを4×4の表として見るのが近道です。
AESが一度に扱うブロックは128ビット、つまり16バイトです。
これを1バイトずつ16個のマスに入れたものがStateで、各セルには8ビットの値が入っている、と考えます。
暗号化は、この16個の小さな値を表の上で何度も並べ替え、置き換え、混ぜ、鍵と重ねる処理だと思うと見通しが立ちます。

たとえば紙に4×4のマスを書いて、00 11 22 33 44 55 66 77 88 99 aa bb cc dd ee ff のような16バイトを埋めてみると、AESの「崩し」の感覚がつかめます。
筆者は初学者に説明するとき、まずこの手遊びを勧めます。
いきなり全部を追うのではなく、まずSubBytesで各マスの値を別の値に置き換え、そのあとShiftRowsで行を横にずらすだけでも、元の規則的な並びが崩れ始めます。
まだ列単位の混合を入れていないのに、見た目の秩序が失われる。
この段階で、AESが「1か所をいじるだけで全体を散らしていく」暗号だと腹落ちしやすくなります。

S-boxは、この最初の崩しを担う変換表です。
1バイトを受け取って、別の1バイトに置き換える辞書のようなものだと捉えるとよいでしょう。
同じ入力なら同じ出力になりますが、並び方に素直な規則が見えないよう設計されています。
ここが暗号の美しいところなのですが、AESは最初から全体をぐちゃぐちゃにするのではなく、まず各セルの局所的な規則性を壊し、そのあと行と列の操作で全体へ広げる構造になっています。
小さな崩しを全体の拡散へつなげる、この二段構えがAESの骨格です。

視覚的には、4×4の表を描き、各セルに1バイトを書き込み、SubBytesで各セルの値が入れ替わる様子、ShiftRowsで2行目・3行目・4行目が左へずれる様子を矢印で添えると理解が早まります。
数式を見る前に、この「表の上でデータが動く」絵を頭に置いておくと、後の処理も追いやすくなります。

4つの基本操作の役割と直感

AESは1ラウンドの中で、基本的に4つの操作を組み合わせてStateを変形していきます。
役割はそれぞれはっきり分かれていて、別々の意味を持つ処理を重ねることで暗号としての強さを作っています。

まずSubBytesは、Stateの16個のセルを1バイトずつ別の値に置き換える処理です。
表全体を動かすのではなく、各マスの中身だけを書き換えます。
これによって、「入力に対して出力が素直に読める」関係を断ち切ります。
平文にあった単純な規則や、1ビット変えたときの追いやすさをここで崩します。

次のShiftRowsは、名前どおり行をずらす処理です。
1行目はそのまま、2行目は少し、3行目はさらに、4行目はもっと、という形で横方向に回転させます。
ここで面白いのは、SubBytesが各セルを単独で変えた結果を、今度は位置のずれとして全体へ持ち出す点です。
同じ列にいた値どうしの関係が崩れ、列の顔ぶれが変わります。
カードを列ごとに積んでいたものを、各段だけずらして積み直すイメージに近いです。

MixColumnsは、列の中にある4バイトを混ぜ合わせる処理です。
ShiftRowsで列の構成メンバーが入れ替わったあと、その列内部で値を絡ませるので、1つのセルの変化が列全体へ波及します。
これが「局所の秩序から全体の拡散へ」の中心部分です。
最初は各セル単位で壊したものが、行ずらしを経由して列混合に渡され、数ラウンド後には最初の1バイトの影響がState全体へ広がっていきます。

AddRoundKeyは、ラウンド鍵とのXORです。
XORはビットごとの重ね合わせと捉えると直感的です。
同じデータでも鍵が違えば結果が変わり、逆に正しい鍵がなければ元に戻せません。
AESではこの処理が「ただ混ぜる」だけでなく、「秘密の鍵情報を各段階に注入する」役目を持っています。
表の配置替えや置換だけなら仕組みを知る人が追えてしまいますが、各ラウンドで鍵が差し込まれることで、変形の道筋そのものが秘密に支配されます。

構造上の見どころとして、AESは最初にいきなり通常ラウンドへ入るのではなく、初回にAddRoundKeyを行ってからラウンド処理を始めます。
さらに、最終ラウンドではMixColumnsを行いません。
つまり毎回まったく同じ4操作を機械的に繰り返すわけではなく、冒頭と終端に少し異なる形を持っています。
直感的には、最初に鍵で基準位置をずらしてから攪拌を始め、終盤は列の混合を省いて着地する構造です。
この形まで含めてAESの定義です。

図で示すなら、4×4の表に対して「各セルの中身が置換される」「各行が左へ回転する」「各列の中で値が混ざる」「鍵表と重ねてXORする」という4枚のコマ送りを並べると理解しやすくなります。
1回だけ見ると地味な処理でも、これを何ラウンドも重ねることで、元の規則が追えない状態まで拡散していきます。

ラウンド構造と鍵スケジュール

AESの暗号化は、Stateに同じ種類の操作を何度も適用するラウンド構造です。
ただし、毎回まったく同一ではありません。
流れとしては、まず初回のAddRoundKeyがあり、そのあと中間ラウンドでSubBytes、ShiftRows、MixColumns、AddRoundKeyを繰り返し、終端のラウンドではMixColumnsを省きます。
この「最初に鍵」「途中は4操作」「最後は列混合なし」という形を押さえると、全体像が整理されます。

ラウンド数は鍵長によって増えます。
AES-128は10ラウンド、AES-192は12ラウンド、AES-256は14ラウンドです。
鍵が長いほど探索空間が広くなるだけでなく、内部処理の段数も増えるわけです。
直感に反するかもしれませんが、AES-256は単に「鍵が長いAES-128」ではなく、同じ骨格を保ちながら、より多くの段を踏む版だと見たほうが実態に近いです。

ここで必要になるのが鍵スケジュールです。
元の秘密鍵を、そのまま毎ラウンド使い回すのではなく、各ラウンドで使うラウンド鍵へ展開していきます。
料理でいえば、1つの材料をそのまま何度も入れるのではなく、下ごしらえして工程ごとに必要な形へ切り分ける感覚です。
これにより、各ラウンドのAddRoundKeyで異なる鍵成分がStateに注入されます。
暗号化の本体がStateを「かき混ぜる」担当だとすれば、鍵スケジュールは「どのタイミングでどの鍵成分を混ぜるか」を支える裏方です。

筆者が実装検証でAESの処理順を確認するときも、まず見るのはこの骨格です。
SubBytesやMixColumnsの中身を細かく追う前に、初回AddRoundKeyが先にあること、終端ラウンドにはMixColumnsがないこと、鍵長ごとにラウンド数が違うことを押さえると、テストベクトルの見え方が一気に変わります。
処理の正しさは個々の式だけではなく、順番でも決まるからです。

AES-128/192/256の比較表

AESには3つの鍵長があり、違いは鍵の長さだけでなくラウンド数と処理負荷にも現れます。
ブロック長はどれも128ビットで共通です。
比較するときは、同じ4×4のStateを使いながら、何段かき混ぜるかが変わると捉えると混乱しません。

この表の読み方は単純で、鍵長が伸びるにつれてラウンド数が増え、そのぶん処理段数も増えます。
だから速度の目安としてはAES-128が最も軽く、AES-256が最も重くなります。
もちろん3者とも同じAESファミリーなので、使っている基本操作は共通です。
違うのは、どれだけ長い鍵を持ち、何回その攪拌を重ねるかです。

視覚化するなら、同じ4×4のState図を3つ並べて、中に書くデータ量は変えず、横に並ぶラウンドの箱の数だけを10、12、14と増やしていく図が向いています。
そうすると、AES-128/192/256の差が「別物の暗号」ではなく、「同じ仕組みを異なる段数で回す仲間」だと自然に見えてきます。

AESで暗号化と復号はどう進むのか——16バイト単位の流れを追う

1ブロック=16バイトの概念図

AESの処理を手順として追うとき、最初に腹落ちさせたいのが1回に扱う単位です。
AES本体が受け取るのは、前述の通り固定長のブロックで、サイズは128ビット、つまり16バイトです。
鍵長が128ビット、192ビット、256ビットと変わっても、この「1回に処理するデータの箱」の大きさは変わりません。

図にすると、1ブロックは16個のマスとして眺めるとつかみやすくなります。

実際のAES内部では、これが4×4のStateとして並び、各マスに1バイトずつ入ります。
前のセクションで見たSubBytesやShiftRowsやMixColumnsは、この16マス全体を相手にして動きます。
1文字ずつ独立に暗号化するのではなく、16バイトをひとかたまりとして変形するわけです。

筆者がこの単位感覚を説明するときによく使うのが、短い文字列をそのままUTF-8のバイト列に並べる見方です。
たとえばHELLO AES!のような短い文字列は、英字と記号なので1文字がほぼ1バイトで並びます。
16マスの箱に左から順に入れていくと、途中で文字が尽き、空きマスが残ります。
逆に、16バイトを少しでも超える文字列を入れようとすると、1つの箱に収まりきらず、次のブロックへあふれます。
この「ぴったり16で切る」「余りが出る」という感覚を一度視覚で持つと、AESがストリームのように無限長データをそのまま流しているわけではないことが見えてきます。

暗号化→復号のステップ

1ブロックが16バイトだとわかったら、次はそのブロックがどう変形されるかを順番に追います。
AESの暗号化は、1ブロックに対して決まった順序で操作を重ねる構造です。

1. まず16バイトの平文ブロックをStateに並べ、最初にAddRoundKeyを行います。ここでは平文に対して、鍵スケジュールで用意された最初のラウンド鍵をXORで重ねます。AESはここからスタートする点が特徴です。

1. 次に中間ラウンドへ進みます。ここではSubBytes、ShiftRows、MixColumns、AddRoundKeyの4操作を1セットとして繰り返します。中間ラウンドの回数は鍵長に応じて変わりますが、流れそのものは同じです。State全体が少しずつではなく、各段階で別の規則に従って組み替えられていきます。

1. 終端のラウンドでは、SubBytes、ShiftRows、AddRoundKeyを行います。この段ではMixColumnsを入れません。暗号化の骨格を追うときは、この終端だけ形が少し違うことを押さえておくと、処理順の理解が崩れません。

1. こうして得られた16バイトが、そのブロックの暗号文です。平文1ブロックが暗号文1ブロックへ写像される、というのがAES本体の役目です。

復号は、この流れをただ「逆順に読む」だけではなく、各操作に対応する逆変換を使って元へ戻していきます。
暗号化でSubBytesを使ったなら復号ではInvSubBytes、ShiftRowsにはInvShiftRows、MixColumnsにはInvMixColumnsが対応します。
AddRoundKeyはXORなので、復号側でも鍵加算として働きます。
順番としては、暗号化の終端側からたどる形でラウンド鍵を使い、Stateを少しずつ平文へ戻します。

ここが暗号の美しいところなのですが、暗号化と復号は「同じことを2回やる」のではありません。
暗号化で加えた変形を、復号ではきちんと打ち消す専用の手順が必要です。
実装検証でも、暗号化だけ合っていて復号が崩れるケースはこの逆変換の順番違いで起こります。
InvShiftRowsとInvSubBytesの並び、InvMixColumnsを挟む位置、どのラウンド鍵をどこで当てるかが少しでもずれると、16バイトは元の文字列に戻りません。

長文データとモードの必然性

AES本体が扱えるのは16バイト単位の1ブロックだけです。
では、メール本文や画像ファイルやHTTPS通信のレコードのような長いデータはどうするのかというと、複数の16バイトブロックに分けて処理します。
20バイトなら2ブロック、32バイトなら2ブロック、33バイトなら3ブロックという具合です。
ここで必要になるのがモードです。

理由は単純で、AES本体は「1ブロックを1ブロックへ変換する部品」にすぎないからです。
長文を安全に扱うには、先頭ブロックと次のブロックをどう関係づけるか、同じ平文ブロックが並んだときに同じ暗号文にならないようどう工夫するか、途中までの処理結果をどう次へつなぐか、といった設計が要ります。
その役割を担うのがCBC、CTR、GCMなどの動作モードです。

たとえばCBCは前の暗号文ブロックを次の処理に絡めることで、各ブロックを連鎖させます。
一方でCTRはカウンタ値から疑似的な鍵流を作り、平文とXORしていく考え方を取ります。
GCMはCTR系の暗号化に加えて、改ざん検知のための認証タグも扱います。
TLS 1.3でAES-GCMのようなAEADが主役になるのは、機密性だけでなく完全性までまとめて扱えるからです。

GCMでは一般に96ビットのnonceが推奨され、認証タグは仕様上最大128ビットまで選べます（NIST SP 800‑38D: 短いHELLO AES!を16マスに入れてみると、この必然性が実感できます。
1ブロックに収まるうちはAES本体だけを眺めても話が閉じますが、文字を少し足した瞬間に次の箱が必要になります。
そこから先は、箱をどうつなぐかという問題に変わります。
AESの理解が一段深まるのは、まさにこの境目で、「暗号アルゴリズム本体」と「運用モード」が別物だと見えたときです。
次のセクションでは、そのモードごとの差をもう少し具体的に整理していきます。

AESはなぜ安全とされるのか——総当たり・既知の攻撃・量子計算の見方

鍵空間と総当たり困難性

AESが安全とみなされる第一の理由は、鍵空間の大きさです。
AESには 2^128、2^192、2^256 通りの鍵候補があり、攻撃者が正しい鍵を知らないなら、もっとも素朴な方法は片端から試す総当たりになります。
ここで直感に反するかもしれませんが、128ビットというだけで、すでに人間の感覚から外れた規模です。

筆者はこの説明をするとき、紙に小さな演習を書いてもらうことがあります。
1秒に 10^12回 鍵を試せる装置を想定して、それを宇宙年齢のあいだ動かし続けたとしても、2^128 の全探索には届かない、と桁だけ追ってみるのです。
厳密な年数を暗記する必要はありません。
ポイントは、毎秒1兆回という時点で十分に途方もないのに、それでも128ビット鍵の全候補は遠すぎる、という感覚をつかむことにあります。
暗号の安全性は抽象的な「強そう」ではなく、こうした桁感で見ると腹落ちします。

この差は、旧世代の56ビット鍵だったDESと比べるとさらに鮮明です。
56ビットは現代の計算能力の前では現実的な攻撃対象になりましたが、AESの128ビット以上は同じ見方では到達できません。
192ビットや256ビットになると、その隔たりはさらに広がります。
少なくとも総当たりという正面攻撃に関しては、AESは現実の計算資源から十分に距離を取っている、というのが基本認識です。

もちろん、安全性は鍵長だけで決まるわけではありません。
短い鍵を選んだり、推測しやすい方法で鍵を作ったり、鍵そのものを漏えいさせたりすれば、巨大な鍵空間は役に立ちません。
それでも「アルゴリズム本体に対して総当たりが成立するか」という観点では、AESの鍵空間は今なお強力な防壁です。

既知の攻撃の射程

AESの安全性を語るときは、「理論研究がある」ことと「実用的に破られている」ことを分けて考える必要があります。
現時点では、正しく実装されたフルラウンドのAESに対して、現実の運用で成立する実用的な攻撃は知られていない、というのが妥当な水準です。
ここは断定的に神話化するのではなく、現在の公開知見の範囲でそう評価されている、と押さえるのが正確です。

既知の研究の多くは、AESそのものをまるごと破る話ではありません。
典型的なのは、ラウンド数を減らした縮退版に対する解析です。
暗号研究では、まず簡略化した版に攻撃を当てて、設計のどこまで余裕があるかを見るのが自然な流れです。
これは「本番のAESがそのまま危ない」という意味ではなく、設計の安全余裕を測るための学術的なステップと理解すると混乱が減ります。

もうひとつ区別したいのが、サイドチャネルです。
たとえば計算時間、消費電力、電磁波、キャッシュの挙動のように、アルゴリズムの数学ではなく実装の振る舞いから鍵情報が漏れる経路があります。
実務で事故につながりやすいのは、むしろこちらです。
AESの数式が破られたのではなく、ソフトウェアやハードウェアの実装、鍵の置き方、乱数の扱い、周辺設計の甘さから崩れるわけです。

ここが暗号の現場でいちばん誤解されやすいところです。
AES本体が強くても、使い方が雑ならシステム全体は安全になりません。
前述の通り、AESはブロック暗号の部品であって、実際の安全性はモード選択、nonceやIVの管理、乱数、鍵管理、認証の有無まで含めて決まります。
AES-GCMのようなAEADであってもnonce再利用が起きれば前提が崩れますし、XTS-AESはストレージ向けの機密性を与えますが改ざん検知までは担いません。
安全性は「AESを使っている」という一語ではなく、周辺の設計まで含めた総合点で決まります。

量子計算時代の安全性評価

量子計算の話題が出ると、AESもすぐ無力化されるように受け取られがちですが、見方はもう少し整理できます。
対称鍵暗号に対してよく挙げられるのは Groverのアルゴリズム で、これは総当たり探索を平方根の計算量に縮める、という形で理解されます。
したがって、AESのような対称鍵では、実効鍵長が概ね半減する と説明されます。

この見方に沿うと、AES-128は理論上 約64ビット相当、AES-256は 約128ビット相当 の探索困難性として語られます。
AES-192も同様に中間の位置づけです。
量子計算が出てきても「即座に終わる暗号」ではなく、必要な安全水準に応じて鍵長をどう見るか、という読み替えになります。
ここでも大切なのは、量子時代の議論がゼロか一かではないことです。

もっとも、これは理想化した量子計算モデルでの評価です。
Groverを現実の大規模攻撃に乗せるには、膨大な量子資源、誤り訂正、長時間安定して動く量子回路が要ります。
量子計算の存在を理由に今のAESが無意味になる、という理解は飛躍があります。
一方で、長期保護が必要なデータでは、将来の計算能力も見込んで鍵長を選ぶ発想が自然です。
その文脈でAES-256が選ばれる場面があるのは、量子計算を見据えた余裕を持たせやすいからです。

このテーマでも、アルゴリズム本体だけを切り出して安心するのは早計です。
量子計算は総当たりの見積もりを変えますが、現実の破綻は今もなお鍵管理や実装不備から起こります。
AESの安全性を正しく捉えるなら、総当たりに対しては巨大な鍵空間があり、既知の実用攻撃は確認されておらず、量子計算下でも対称鍵としての評価軸が残る、という三層で見るのが適切です。
そこに運用の健全性まで含めて、はじめて「AESはなぜ安全とされるのか」が立体的に見えてきます。

本当に大事なのはAESの使い方——GCM・CBC・CTRの違い

AESはあくまで128ビットのブロックを変換する暗号の本体です。
現場で安全性を左右するのは、その本体をどんなモードで回すかにあります。
同じAESという名前でも、ECBCBCCTRGCMでは性質がまるで違います。
ここを混同すると、「AESだから安全」という雑な理解になってしまいます。

ECBが非推奨な理由

ECBは、平文をブロックごとに独立して暗号化する最も素朴な形です。
仕組みは単純ですが、その単純さがそのまま弱点になります。
同じ平文ブロックは、同じ鍵のもとで必ず同じ暗号文ブロックになります。
内容そのものは読めなくても、繰り返しの模様が暗号文に残ります。

この性質は、文章より画像で考えると直感がつかみやすくなります。
白黒のロゴや単純な図形を思い浮かべてみてください。
そこに同じ色や同じ模様の領域が広く続いていると、同じ16バイト単位の並びも繰り返されます。
ECBで暗号化すると、その繰り返しが暗号文側でも対応して現れ、輪郭や大まかな構造が透けて見える、あの有名な例が起きます。
筆者も初めてその画像を見たとき、「読めないのに見えてしまう」という感覚が強く残りました。
暗号は中身を隠せば終わりではなく、構造の手がかりまで消せるかが問われるのだと腹落ちした瞬間でした。

ここがECBの本質的な問題です。
ブロック暗号を、ただ独立に並べただけでは、データ全体としての意味のあるパターンを隠しきれません。
そのため、ECBは現代の一般的なデータ保護では非推奨と考えるのが基本です。
教材としてはわかりやすい一方、実運用の選択肢として前面に出てくることはまずありません。

CBC/CTRの設計意図と注意点

CBCとCTRは、ECBの欠点を避けるために設計された代表的なモードです。ただし、どちらも「AES本体にどんな追加の性質を持たせるか」が違います。

CBCは、各ブロックを暗号化する前に前の暗号文ブロックと混ぜる方式です。
先頭ではIVを使い、その後は前段の結果が次段に影響します。
これにより、同じ平文ブロックが現れても、そのまま同じ暗号文にはなりません。
ECBで問題になった模様の残留を避けるという意味では、素直でよくできた設計です。

ただし、CBCが与えるのは秘匿性であって、完全性ではありません。
暗号文が途中で書き換えられていないか、送り手が正しい相手か、といった確認はCBC単体ではできません。
ここを落とすと、「復号できたから正しいデータだろう」と思い込んでしまいますが、その前提は成り立ちません。
CBCを使うなら、改ざん検出はMACなど別の仕組みで補う必要があります。
暗号化と認証を別々に組み合わせる設計が必要になる、ということです。

CTRは発想が少し異なります。
AESで平文そのものを直接混ぜるのではなく、nonceやカウンタから作った入力をAESに通し、その出力を鍵流のように使って平文とXORします。
見た目はブロック暗号でも、中身の感覚としてはストリーム暗号に近づきます。
この構成の利点は、各ブロックが前段に縛られないことです。
処理の流れが一直線に依存しないので、実装上の扱いが軽く、並列化とも相性がよくなります。

一方で、CTRには絶対に踏んではいけない地雷があります。
同じ鍵でnonceやIVを再利用すると、同じ鍵流が再び生成されます。
そうなると、異なる平文どうしが同じマスクで覆われることになり、暗号文同士の関係から平文の関係が露出します。
CTRの破綻は「少し弱くなる」ではなく、設計の前提そのものが崩れる種類の事故です。
ここが直感に反するかもしれませんが、CTRではAES本体が強くても、nonce管理を誤った瞬間に安全性の土台が抜けます。

GCM（AEAD）が推奨される背景とnonce一意性

GCMは、CTR系の高速な暗号化に加えて、認証タグによる改ざん検出を組み合わせたモードです。
分類としてはAEAD、つまり「機密性と完全性を同時に与える方式」に入ります。
さらに、暗号化しない追加データまで認証対象にできます。
通信プロトコルのヘッダのように、読める状態のまま正しさだけ保証したい情報とも相性がよく、現代のプロトコルで選ばれやすい理由がここにあります。
TLS 1.3ではAEADが前提になっているのも、この流れに沿っています。

筆者がGCMの価値をいちばん実感するのは、復号に失敗したときの挙動です。
たとえば保存していた暗号文を1ビットだけ書き換えたとします。
CBCやCTRに認証を付けていない構成だと、どこか壊れたデータとして通ってしまう可能性があります。
GCMではタグ検証の段階で弾かれ、平文として受け取りません。
「読めない」だけでなく「触られていたら拒否する」という振る舞いが、運用上はとても効きます。
現場ではこの差が大きく、暗号化できることより、改ざんされたデータを受け入れないことのほうが安心につながる場面が少なくありません。

GCMでよく使われる構成としては、nonceに96ビット、認証タグに128ビットを用いることが多いです。
ただしこれは実務上の典型例であり、仕様上はタグ長やnonce長が可変であること、96ビット以外のnonceを使用する場合に追加処理が必要になることを忘れてはなりません。
最も重要なのは、同一鍵でnonceを一意に保つ運用が守られていることです。

モード比較表

文章だけだと差がぼやけるので、主要な性質を並べると次のようになります。

見ての通り、差は「暗号化できるかどうか」ではありません。
ECB、CBC、CTR、GCMはどれも平文を隠すという意味ではAESを使っています。
しかし、模様を漏らすのか、改ざんを見抜けるのか、nonce再利用で壊れるのかという運用上の性質が違います。
AES本体を理解したあとに本当に分水嶺になるのは、ここでどのモードを選び、どの前提を守るかです。

AESはどこで使われているのか——TLS 1.3、Wi‑Fi、ストレージ暗号化

TLS 1.3のAEAD運用

HTTPSでWebページを開いたとき、裏側でよく動いているのがTLS 1.3です。
ここでのAESの出番は、単に「昔からある共通鍵暗号が使われている」という話ではありません。
TLS 1.3では、暗号スイート名の役割そのものが整理され、鍵交換や署名方式は暗号スイート名から分離されました。
TLS 1.2以前で見かけた「鍵交換方式・認証方式・暗号方式がひとつの長い名前に詰め込まれている」構図ではなく、TLS 1.3の暗号スイート名はレコード保護に使うAEADとハッシュを表す形になっています。

その代表例がTLS_AES_128_GCM_SHA256です。
この名前の中心にあるのはAES-GCMで、暗号化と改ざん検出を一体で行うAEADとして動きます。
前節で見た通り、ここが暗号の美しいところなのですが、TLS 1.3は「暗号化できるだけでは足りない」という現代的な前提を仕様レベルで取り込んでいます。
古い非AEAD系を抱え込まず、通信の保護をAEAD前提にそろえたことで、実装側も設計の見通しを持ちやすくなりました。

その代表例がTLS_AES_128_GCM_SHA256です（RFC 8446:

Wi‑FiのCCMP/GCMPとAES

無線LANでも、AESは中心にいます。
WPA2で標準的に使われてきたのがCCMPで、これはAES-CCMを土台にした保護方式です。
無線区間では、単に内容を隠すだけでなく、フレームが途中で書き換えられていないことも押さえなければいけません。
そのため、Wi‑FiでもAESは「データを読めなくする箱」としてではなく、認証つきの運用の中核として使われています。

WPA3系統や新しい世代では、GCMPのようにAES-GCM系を使う構成も目立ちます。
名前が少し違っても、発想は共通です。
AESをブロック暗号本体として使い、その上にCCMやGCMのようなAEAD系の仕組みを載せて、無線通信に必要な秘匿性と改ざん検出をまとめて実現するわけです。
Wi‑Fiのセキュリティを「パスワードの強さ」だけで見ていると見落としがちですが、実際にはその下でどの保護方式が動いているかが土台を作っています。

この話は設定画面でも意外なほど身近です。
ルーターや端末のWi‑Fi設定でWPA2‑PSK（AES）という表示に出会うことがあります。
この表示はAES系アルゴリズムが用いられていることを示す簡略表記で、実際には CCMP（AES‑CCM）や GCMP（AES‑GCM 系）のようなプロトコル層の構成が用いられている場合が多い点に注意が必要です。
詳しい実装やパラメータは機器ベンダーや Wi‑Fi Alliance の仕様を確認してください（Wi‑Fi Alliance: この話は設定画面でもわかりやすく見えます。
ルーターや端末のWi‑Fi設定でWPA2‑PSK（AES）という表示を見かけることがありますが、これはあくまで簡略表示であり、内部では CCMP（AES‑CCM）や GCMP（AES‑GCM 系）といったプロトコル層の構成が動作しています。
機器によって採用するプロトコルやパラメータ（タグ長・nonceの扱いなど）が異なるため、正確な実装詳細は機器ベンダーや Wi‑Fi Alliance／IEEE の仕様書を参照してください（Wi‑Fi Alliance: IEEE 802.11i/RSN など）。

XTS-AESは機密性のための方式であって、改ざん検出までを単体で与える設計ではありません。
この違いは、GCMのようなAEADと並べてみると見えやすくなります。
AESはいつも同じ顔で使われるのではなく、通信ではGCM、保存ではXTSのように、場面ごとに適したモードへ載せ替えられているわけです。

この分野も、設定画面でふと出会えます。
BitLockerや各種ディスク暗号化機能の設定を触っていると、AESが選択肢として現れることがあります。
筆者もディスク暗号化の画面でAES表記を見たとき、「WebとWi‑Fiだけでなく、持ち歩くPCの中身まで同じ暗号が守っているのか」と腹落ちしました。
通信路のAESと保存先のAESは仕事の内容が違いますが、日常ではその両方に触れています。

日常3シーンでのAES発見術

AESを「理論上の標準」ではなく「今まさに使っている技術」として捉えるには、日常の画面の中で見つけるのが早道です。
筆者が説明のときによく使うのは、次の3つの場面です。

HTTPS閲覧の場面

ニュースサイトでもネットバンキングでも、ブラウザでHTTPSのページを開くとTLSが動いています。
接続情報の詳細を開いたときにTLS_AES_128_GCM_SHA256のような表記が出ていれば、そこでAES-GCMが通信保護に使われています。
読者が今見ているページの背後でも、平文のやり取りではなく、AEADとしてのAESが働いていると実感できる場面です。

社内Wi‑Fiにつなぐ場面

会社や自宅の無線LAN設定で、WPA2-PSK（AES）やWPA3の表示を見ることがあります。
ここで見えているAESは、Wi‑Fiの無線区間を守る中核です。
社内Wi‑Fiに接続するという何気ない操作の裏で、WPA2ならCCMP、WPA3系統ならGCMP系を含む新しい保護方式が候補に入り、AESがその土台になっています。
パスワード入力だけがセキュリティではなく、方式そのものにAESが組み込まれているわけです。

ノートPCのストレージを守る場面

持ち歩くノートPCでは、盗難や紛失時に保存データが読まれないことが要点になります。
ディスク暗号化の設定画面でAES表記に出会うと、通信ではなく保存データの保護でも同じ名前が使われているとわかります。
ここではXTS-AESのようなストレージ向けの運用が選ばれ、電源を落としたあとのデータ保護を担います。
ブラウザ、Wi‑Fi、ストレージという3つの場面を並べると、AESは「どこかの専門システムの中だけにいる暗号」ではなく、日常のデジタル生活を横断している基盤だと見えてきます。

まとめ——AESを方式として理解し、鍵管理まで視野に入れる

AESは、標準として定義された共通鍵ブロック暗号の名前です。
ただ、現場で問われるのは「AESを使ったか」ではなく、「どう使い、どう守ったか」です。
暗号本体の強さと、モード選択、nonceやIVの扱い、乱数、実装、鍵管理は分けて考えると頭の中が整理できます。
仕様や一次資料に当たりたい場合は、TLS 1.3 の RFC（RFC 8446）や GCM の NIST 文書（SP 800‑38D）などを参照してください（RFC 8446: NIST SP 800‑38D: