エンコード・ハッシュ化・暗号化の違い——「変換する」という言葉に隠れた3つの別物

「このデータはエンコードしてあります」「パスワードはハッシュ化して保存しています」「通信は暗号化されています」——どれも「データを何らかの形に変換した」という意味で使われます。

でもこの3つは、目的も仕組みも、元に戻せるかどうかも、まったく違います。

混同すると「暗号化しているから安全」「エンコードしているから読めないはず」という誤った前提を持ってしまいます。実際のシステム設計やセキュリティの会話でも頻繁に出てくる概念なので、しっかり整理しておきましょう。

まず3つの結論

エンコード：誰でも元に戻せる変換。目的は「形式を揃えること」。 ハッシュ化：元に戻せない一方向の変換。目的は「一致確認と改ざん検出」。 暗号化：鍵を持つ人だけが元に戻せる変換。目的は「第三者に読まれないようにすること」。

エンコードをたとえるなら、外国語への翻訳です。

文字コード（UTF-8やShift_JIS）も同じです。コンピューターは文字をそのまま扱えないため、「あ」を「E3 81 82」のような数値の列に変換する約束事（エンコーディング）があります。この変換は誰でも逆引きできるので、秘匿性はゼロです。

URLに日本語を含めるときの %E3%81%82 という表記（パーセントエンコーディング）も同じ仕組みで、URLとして扱える文字に変換しているだけです。

ハッシュ化をたとえるなら、肉をミンチにする調理です。

ハッシュ関数も同じです。「password123」という文字列を入力すると「ef92b778bafe771207f0…」のような固定長の値（ハッシュ値）が出力されます。元の文字列には戻せませんが、同じ入力からは必ず同じハッシュ値が出るという性質があります。

この「同じ入力→同じ出力」「逆算不可能」という性質がとても便利です。

パスワードの保存では、パスワードそのものではなくハッシュ値を保存します。ログイン時に入力されたパスワードをハッシュ化して、保存済みのハッシュ値と比べるだけで「合っているか」がわかります。データベースが流出しても、ハッシュ値から元のパスワードは取り出せません。

暗号化をたとえるなら、鍵のかかった金庫です。

暗号化の目的は「権限のない第三者に内容を読まれないようにすること」です。メッセージのやりとりや通信の保護（HTTPS）はこれにあたります。

エンコードと違うのは「鍵を持つ人にしか戻せない」点。ハッシュ化と違うのは「元のデータに戻せる」点です。

観点	エンコード	ハッシュ化	暗号化
元に戻せるか	誰でも戻せる	戻せない	鍵があれば戻せる
たとえ	外国語への翻訳	肉をミンチにする	鍵のかかった金庫
主な目的	形式の変換・互換性	一致確認・改ざん検出	内容の秘匿
セキュリティ効果	なし	改ざん検出に有効	盗聴・読み取り防止
典型的な用途	文字コード・URL変換	パスワード保管・チェックサム	HTTPS通信・ファイル保護

「パスワードを暗号化して保存しています」

一見良さそうですが、暗号化では鍵さえ手に入れれば元のパスワードに戻せます。パスワードは「一致確認できれば十分」なので、元に戻せる必要はありません。正しくは**ハッシュ化（ソルト付き）**で保存するのが標準です。

「Base64エンコードすれば読まれない」

Base64はエンコードなので、誰でも瞬時にデコードできます。難読化にはなりますが、セキュリティの意味はほぼありません。読まれたくないなら暗号化が必要です。

「ハッシュ値を解読された」

ハッシュは元に戻せないので「解読」とは言いません。似ているのは「総当たり攻撃」や「レインボーテーブル（よくあるパスワードのハッシュ値をまとめた表）を使って一致するものを探す」という方法です。ソルト（ランダムな値を加えてからハッシュする）で対策できます。

「パスワードをどう保存するか」「通信をどう守るか」「ファイルの整合性をどう確認するか」——それぞれ使うべき技術が違います。「変換している＝安全」ではなく、「何のためにどの変換を使っているか」を意識することが、セキュリティを正しく扱う第一歩です。