--- title: "IPsecとは？仕組み・AH/ESP/IKEとVPNでの使い方、SSL/TLSとの違いと選び方を解説" url: "https://www.issoh.co.jp/column/details/13464/" published: 2026-07-11 updated: 2026-09-27 categories: ["セキュリティ"] publisher: "株式会社一創" --- # IPsecとは？仕組み・AH/ESP/IKEとVPNでの使い方、SSL/TLSとの違いと選び方を解説 IPsec（アイピーセック）とは、IPパケットそのものを暗号化・認証し、インターネットのような信頼できない経路でも通信の中身を守るプロトコル群です。拠点間をつなぐVPNの土台として広く使われ、Web閲覧に限らずあらゆるIP通信をまとめて保護できます。この記事では、IP層で何を守るのかという位置づけ、AH・ESP・IKEとSA（暗号化の取り決め）の関係、トランスポートとトンネルの2モード、暗号スイートやSA有効期限の決め方、拠点間VPNとクラウド接続での使い方を順に整理しました。NAT越えやMTU不整合という現場で必ず踏む段差も、公式ドキュメントの数値付きで示します。最後に、SSL/TLS-VPNとの選び分けと、自前で運用すべきかの判断基準を条件付きで示します。 ## まとめ｜IPsecとはIP層で通信を丸ごと暗号化するVPNの土台 IPsecは、IP層（ネットワーク層）で動作し、その上を流れる通信を中身ごと暗号化・認証するプロトコルの集まりです。仕様の骨格は[RFC 4301（Security Architecture for the Internet Protocol）](https://www.rfc-editor.org/rfc/rfc4301.html)に定義されています。アプリに依存せず、IPで運ばれる通信ならまとめて保護できるため、拠点を常時つなぐサイト間VPNの標準的な方式として定着しました。守る要素は、盗聴を防ぐ暗号化、改ざんを検知する完全性、なりすましを防ぐ認証の3つです。 中核は、パケットを暗号化するESP、認証だけを担うAH、鍵を安全に交換するIKEの3要素です。現行のIKEv2は[RFC 7296（STD 79）](https://www.rfc-editor.org/rfc/rfc7296.html)で規定されています。オンプレの機器同士に限らず、AWSやAzureのクラウドと自社拠点を結ぶサイト間VPNも一般的な構成になりました。設計で迷う場合は[インフラ構築（AWS/GCP/Azure）](https://www.issoh.co.jp/service/system/aws/)で構成段階から相談を受け付けています。 ## IPsecとは何か｜IP層で通信を暗号化・認証する仕組みの位置づけ IPsecを理解する近道は、「どの層で、何を守るのか」を押さえることです。IPsecはIP層で動くため、その上位で動くアプリケーションを問わず、通信を経路ごと包んで保護できます。 ### IPsecの位置づけ｜IPレイヤーで通信をまとめて暗号化・保護する Webの通信を守るTLSがアプリケーションに近い層で個別に働くのに対し、IPsecは下の層でIPパケット単位に暗号化と認証をかけます。Web・メール・業務システムを種類を問わず一括で保護できる点が違いです。RFC 4301はこの保護を、セキュリティポリシーデータベース（SPD）に照らしてパケットごとに破棄・素通し・IPsec適用のいずれかを決める形で定義しています。VPN全体の位置づけは、親テーマの[VPNとは何か・仕組みと企業導入の判断基準](https://www.issoh.co.jp/column/details/13215/)で整理しました。 ### IPsecで守れる3つの要素｜暗号化（機密性）・完全性・認証 IPsecが与える保護は3点です。盗聴されても中身を読ませない暗号化（機密性）、途中で書き換えられていないかを検知する完全性、相手が本物かを確かめる認証。暗号化だけでは改ざんを見抜けず、認証がなければなりすましを許すため、3要素をまとめて満たす設計がIPsecの狙いになります。個々のアルゴリズムが何を保証するかは、[暗号化とは何か・共通鍵と公開鍵の違い](https://www.issoh.co.jp/column/details/13274/)で基礎を扱っています。 ### なぜIP層で守る必要があるのか｜アプリを問わず経路ごと保護できる アプリごとに暗号化を実装すると、対応していないソフトの通信は素通りになります。IP層で守れば、拠点から出ていく通信を経路の入口でまとめて包めるため、個々のアプリの対応状況を問いません。境界制御を担うファイアウォールと組み合わせ、通す通信はIPsecで暗号化し、通さない通信は遮断する設計が定番になります（[ファイアウォールとは何か・種類と選び方](https://www.issoh.co.jp/column/details/13233/)）。 ## IPsecの仕組み｜AH・ESP・IKEとSA（暗号化の取り決め）の関係 IPsecは単一のプロトコルではなく、役割の異なる要素の集まりです。パケットを守るAHとESP、鍵を交換するIKE、両者が使う取り決めのSA。この4語の関係がわかれば、動作はほぼ見通せます。 ### AHとESPの役割の違い｜認証だけを行うか、暗号化まで担うか 実際にパケットを保護するのが、AHとESPの2つです。暗号化を行うかどうかで役割が分かれます。仕様の出典は[RFC 4302（IP Authentication Header）](https://www.rfc-editor.org/rfc/rfc4302.html)と[RFC 4303（IP Encapsulating Security Payload）](https://www.rfc-editor.org/rfc/rfc4303.html)で、どちらも2005年12月の発行でした。[IANAのプロトコル番号レジストリ](https://www.iana.org/assignments/protocol-numbers)ではESPに50、AHに51が割り当てられており、ファイアウォールで許可する対象もこの番号で指定します。 | プロトコル | IPプロトコル番号 | 暗号化 | 認証・完全性 | 主な用途 | | ------------ | --------- | ---- | ------ | ------------ | | AH（認証ヘッダ） | 51 | 行わない | 行う | 改ざん検知・送信元の確認 | | ESP（暗号ペイロード） | 50 | 行う | 行う | 盗聴防止＋改ざん検知 | 実務でESPが主流になる理由は2つです。AHは中身を暗号化しないので盗聴を防げず、外側のIPヘッダまで完全性の計算に含めるため、アドレスを書き換えるNAT配下では成立しません。 ### IKEによる鍵交換とSAの確立｜フェーズ1とフェーズ2の2段階 暗号化には鍵が要りますが、経路の上でそのまま送れば盗まれてしまいます。鍵を安全に交換する役割を担うのがIKE（Internet Key Exchange）です。IKEv1は2段階でSA（Security Association＝暗号方式や鍵の取り決め）を確立します。フェーズ1でIKE自身の経路を作って互いの認証を済ませ、フェーズ2でデータを流すIPsec用のSAを確立する流れです。SAは通信の向きごとに作られ、有効期限が来ると鍵が自動更新されます。管理画面が「フェーズ1／フェーズ2」の欄で設定を求めるのは、この2段構えの名残です。 ### トランスポートモードとトンネルモードの違い｜守る範囲と使い分け IPsecには、パケットのどこまでを保護するかで2つのモードがあります。守る範囲が異なり、用途で選び分けます。 | モード | 暗号化する範囲 | IPヘッダの扱い | 主な使いどころ | | ---------- | ------- | ---------- | -------------- | | トランスポートモード | データ部分のみ | 元のヘッダを使う | 端末間の直接通信 | | トンネルモード | 元パケット全体 | 新しいヘッダを付ける | 拠点間VPN・機器同士の接続 | サイト間VPNでトンネルモードが基本になるのは、元のパケットをまるごと包んで外側に新しいIPヘッダを付けるため、送信元・宛先のアドレスまで隠せるからです。代償として、外側ヘッダのぶん1パケットで運べるデータは減ります。この差が後述するMTU調整として現れます。 ## IPsecの設定項目｜暗号スイート・鍵交換方式とSA有効期限の決め方 IPsecの設定で手が止まるのは、設定画面に並ぶ用語の対応関係がわからないときです。決めるべき項目は4つに絞れます。暗号スイート、IKEのバージョン、SAの有効期限、守る対象のネットワーク範囲。 ### 暗号スイートの決め方｜AES-GCMを軸にDHグループを合わせる 暗号スイートは、暗号アルゴリズム・完全性アルゴリズム・鍵交換（Diffie-Hellman）グループの組み合わせで、IKE用のSAとデータ用のChild SA（IPsec SA）に別々に設定します。AES-GCMのようなAEAD方式なら暗号化と完全性が一体になるため、完全性アルゴリズムを別に並べる必要はありません。[Cloud VPNの公式ドキュメント（2026年9月時点）](https://docs.cloud.google.com/network-connectivity/docs/vpn/concepts/mtu-considerations)ではペイロードMTUがAEAD系（AES-GCMなど）で1,406バイト、非AEAD系（AES-CBCなど）で1,374バイトと公開され、いずれもIPv4ゲートウェイインターフェースの値で、方式の差が32バイト出ます。両端の提案が1つも一致しないとネゴシエーションは止まるため、DHグループ（ecp384など）まで対向機器に合わせるのが手順です。 ### IKEv1とIKEv2の違い｜フェーズ2段階と3種の交換手順 新規に組むならIKEv2を選びます。IKEv1はフェーズ1・フェーズ2の2段構えでした。RFC 7296のIKEv2はIKE\_SA\_INIT、IKE\_AUTH、CREATE\_CHILD\_SAという3種の交換で組み立てられ、仕様書はCREATE\_CHILD\_SAを「IKEv1でPhase 2交換と呼ばれた機能に相当する」と説明しています。発行は2014年10月で、STD 79として標準化されています。strongSwanの[swanctl.conf リファレンス](https://docs.strongswan.org/docs/latest/swanctl/swanctlConf.html)は、接続ごとのversionキーの既定値を2（IKEv2）とし、1で指定するIKEv1をdeprecatedと記載しました。IKEのメッセージはUDP 500番から始まり、経路上にNATがあると判定された時点で4500番へ移ります。[AWS Site-to-Site VPNの公式ドキュメント](https://docs.aws.amazon.com/vpn/latest/s2svpn/VPC%5FVPN.html)も、対応機能としてIKEv2とNATトラバーサルを挙げています。IKEを使わない選択肢は[WireGuardの仕組みとOpenVPNとの違い](https://www.issoh.co.jp/tech/details/7696/)で比較しました。 ### swanctl.confの設定例｜拠点間トンネルを張る最小構成 OSSで組む代表例がstrongSwanです。公式ドキュメント（docs最新は6.1系）の[Configuration Quickstart](https://docs.strongswan.org/docs/latest/config/quickstart.html)のSite-to-Site構成をもとに、拠点A（10.1.0.0/16）と拠点B（10.2.0.0/16）を事前共有鍵でつなぐ最小形を示します。 ``` # /etc/swanctl/swanctl.conf : 拠点A側（strongSwan 6.1系） connections { site-to-site { remote_addrs = 203.0.113.20 version = 2 proposals = aes256gcm16-prfsha384-ecp384 rekey_time = 4h local { auth = psk id = 198.51.100.10 } remote { auth = psk id = 203.0.113.20 } children { netA-netB { local_ts = 10.1.0.0/16 remote_ts = 10.2.0.0/16 esp_proposals = aes256gcm16-ecp384 rekey_time = 1h start_action = trap } } } } secrets { ike-site { id = 203.0.113.20 secret = "事前共有鍵をここに置く" } } ``` 読み込みは `swanctl --load-all`、確立状況は `swanctl --list-sas` で見ます。`version = 2` がIKEv2の指定、`rekey_time` がSAの更新間隔です。 ## IPsec-VPNの使いどころ｜拠点間接続とクラウドとの接続 IPsecがもっとも使われるのが、VPN（仮想的な専用線）の構築です。物理的な専用線を引く代わりに、インターネットの上に暗号化した通り道を作って離れた場所をつなぎます。拠点とクラウドをIPsecでつなぐ具体的な設定は[Site-to-Site VPNのIKE既定値の突き合わせとstrongSwan接続手順](https://www.issoh.co.jp/tech/details/17873/)で解説しています。 ### サイト間VPNとリモートアクセスVPN｜つなぐ対象で分かれる IPsec-VPNの使い方は大きく2つに分かれます。1つはサイト間（拠点間）VPNで、拠点のネットワーク機器どうしをトンネルモードで常時つなぐ形です。拠点内の端末は特別な設定なしに、暗号化された通り道で相手拠点と通信できます。もう1つはリモートアクセスVPNで、在宅勤務者の端末から社内へ個別に暗号化接続を張る使い方です。リモートアクセス用途ではSSL/TLS-VPNも増えましたが、拠点を固定的に結ぶ用途ではいまもIPsecが標準です。 ### クラウドとのIPsec接続｜AWS/Azureのサイト間VPNで自社拠点をつなぐ AWS・Azure・Google Cloudは、拠点とクラウド上の仮想ネットワークをIPsecで結ぶサイト間VPN（Site-to-Site VPN）を備えています。AWSの公式ドキュメントでは1つのVPN接続に2本のトンネルが含まれ、同時利用で可用性を確保する設計だと明記されています。帯域は標準で1トンネルあたり1.25 Gbps、Transit GatewayまたはCloud WANに接続するLarge Bandwidth Tunnelで最大5 Gbpsです。クラウド全体の守り方は[クラウドセキュリティの考え方と責任共有モデル](https://www.issoh.co.jp/column/details/13266/)とあわせて検討すると全体像がつかめます。既存の回線とアドレス設計の棚卸しから入る構成は、[インフラ構築（AWS/GCP/Azure）](https://www.issoh.co.jp/service/system/aws/)で対応しています。 ## IPsec接続でつまずく箇所｜NAT越え・MTU不整合と片側トンネル切れ 設定を投入してもつながらない、あるいはつながるのに一部の通信だけ止まる。IPsecで持ち込まれる相談は、この3パターンにほぼ集約されます。順番に切り分ければ原因は絞れます。 ### NAT越えの設定｜UDP 4500へ切り替わる条件とポート穴あけ ESPはIPプロトコル番号50で運ばれ、TCPやUDPのようなポート番号を持ちません。ポート番号を書き換えて多重化するNAT機器を、素のESPは通り抜けられません。これを解くのが[RFC 3948（UDP Encapsulation of IPsec ESP Packets）](https://www.rfc-editor.org/rfc/rfc3948.html)のNAT-Tです。ESPをUDP 4500番のペイロードに包み直して普通のUDP通信として扱わせる仕組みで、IKEはまずUDP 500番で始まり、経路上のNATを検出した時点で4500番へ移ります。ファイアウォールで通す対象は、UDP 500番・UDP 4500番・素のESPを運ぶIPプロトコル50番の3つです。つながらないときは、プロトコル50番だけ落ちている設定漏れを先に疑ってください。 ### MTU不整合の切り分け｜1460バイトとMSSクランプの実測値 Cloud VPNのゲートウェイMTUは1,460バイト（ClassicとHA VPNで共通）、HA VPN over Cloud Interconnectでは1,440バイトです。IPv4ゲートウェイインターフェースのペイロードMTUはAEAD系で1,406バイト、NAT-T有効なら8バイト減って1,398バイトです。Cloud VPNはカプセル化後の断片化に対応しないため、対向側のゲートウェイで事前フラグメントを有効にします。TCPはMSSクランプで収まりますが、AWS Site-to-Site VPNはPath MTU Discoveryをサポートしないと公式に明記されており、経路の途中でICMPが落ちていると調整が働きません。「pingは通るのに大きなファイル転送やHTTPSの応答だけ固まる」という症状は、ほぼこのMTU不整合です。切り分けは、DFビット付きのサイズ指定pingで通る上限を探すのが早道です。 ### 片側トンネル切れの切り分け｜2本構成とBGP経路の自動切り替え クラウドとのVPNで多いのが、2本あるトンネルの片方だけがダウンする事象です。AWSは1つのVPN接続に2本のトンネルを用意する設計なので、片方が落ちても通信は続きます。裏を返せば、監視していないと片肺運転に気づけません。見る順番は、鍵の更新（rekey）タイミングの差、対向機器のDPD間隔、BGPが片側だけ確立していないかの3点です。[Google CloudのCloud VPN公式ドキュメント](https://docs.cloud.google.com/network-connectivity/docs/vpn/concepts/overview)は、HA VPNのSLAを大半のトポロジで99.99%（構成によっては99.9%）、Classic VPNを99.9%と示し、対応する経路制御をHA VPNは動的（BGP）のみ、Classic VPNは静的（ポリシーベースまたはルートベース）のみと分けています。静的経路だけで組むと、片側の切断時に経路が自動で切り替わりません。要件に足りないと判断した段階では、[AWS Direct Connectと専用線接続](https://www.issoh.co.jp/tech/details/15476/)や[閉域網とVPN・専用線の違い](https://www.issoh.co.jp/column/details/13181/)を並べて比較します。 ## IPsec-VPNとSSL/TLS-VPNの違い｜どちらを選ぶか VPNには、IPsecを使う方式と、WebでもおなじみのSSL/TLSを使う方式があります。層も設定の重さも違うため、用途で選び分けます。 ### IPsec-VPNとSSL/TLS-VPNの比較｜層・対象・導入の手間 2方式の違いを、実務で効く観点に絞って並べます。 | 観点 | IPsec-VPN | SSL/TLS-VPN | | ------ | ------------------ | ----------- | | 動作する層 | IP層（ネットワーク層） | トランスポート層より上 | | 守る通信 | あらゆるIP通信を一括 | 主にWebや対応アプリ | | 使うポート | UDP 500・4500／IP 50 | TCP 443が中心 | | 端末側の準備 | 専用クライアントや機器設定 | ブラウザ中心で軽い | | 向く用途 | 拠点間の常時接続 | 個人のリモートアクセス | SSL/TLS-VPNはTCP 443番という「どこからでも通る」ポートに載るため、出張先のホテルや客先ネットワークからでもつながりやすい方式です。IPsecはUDP 500・4500番とIPプロトコル50番を通す必要があり、経路の制約を受けます。SSL/TLSそのものの仕組みは[TLSとは何か・SSLとの違いとバージョン選定](https://www.issoh.co.jp/tech/details/13318/)で扱っています。 ### 選び分けの判断基準｜ネットワーク拠点をつなぐか、人をつなぐか 判断軸はシンプルです。**拠点のネットワークどうしを固定的に、常時つなぎたいならIPsec-VPN**が向きます。**社外の従業員が自分の端末から必要なときだけ接続する用途ならSSL/TLS-VPN**のほうが、導入も運用も軽い選択です。つなぎたいのは拠点か人かを最初に決めると、方式選びで迷いません。両方の要件があるなら、拠点間はIPsec、在宅アクセスはSSL/TLSと併用するのが現実的です。 ## IPsecを自前で運用すべきか｜採用の条件と、見送るべき場面 IPsecは強力ですが、常に自前で組むのが正解とは限りません。鍵の設計、モードの選択、機器ごとの相互接続性と、運用で見るべき点が多いためです。 ### IPsecを自前で組むべき構成｜拠点間の常時接続と自社運用体制がある場合 自前でIPsec-VPNを組む価値が高いのは、**複数拠点を常時つなぐ必要があり、ネットワーク機器を継続して運用できる体制が社内にある構成**です。専用線ほどのコストはかけられないが暗号化された固定経路が要る、という要件にIPsecはかみ合います。クラウドとのサイト間VPNのように片側をマネージドに任せられるなら、自社側の機器設定だけに集中できます。判断の目安は、監視対象のトンネルが何本になるかです。2拠点とクラウド1つなら実質2〜4本で収まり、担当1名でも回せます。 ### 自前運用を見送るべき場面｜小規模・在宅中心・運用人手が薄い場合 逆に、**つなぎたいのが少数の在宅勤務者だけで、拠点間の常時接続がない場合、IPsecを自前で構える手間は過剰**になりがちです。この規模なら、SSL/TLS-VPNやマネージドのゼロトラストアクセスに寄せたほうが、端末側の設定が軽く運用も続けやすくなります。移行先としては[ZTNA（ゼロトラストネットワークアクセス）とVPNとの違い](https://www.issoh.co.jp/column/details/13099/)が比較対象です。機器を扱える担当が薄い組織で自前のIPsec機器を持つと、切り分けが属人化し障害時の復旧が滞ります。判断軸は「拠点を常時つなぐ要件があるか」「機器を運用し続ける人手があるか」の2点で、どちらも薄いなら暗号化はマネージド側に委ね、自社は接続設計に集中するほうが長期的に軽く運べます。 ## よくある質問 IPsecの検討でよく挙がる質問に回答します。 ### IPsecとは何ですか？わかりやすく教えてください IPsecは、IPパケットを暗号化・認証して、信頼できない経路でも通信の中身を守るプロトコル群です。仕様の骨格はRFC 4301に定義されています。IP層で動くため、その経路を流れる通信を種類を問わずまとめて保護できます。おもに拠点間VPNの土台として使われ、暗号化・完全性・認証の3つを同時に満たす仕組みです。 ### IPsecのAH・ESP・IKEの違いは何ですか？ 役割が異なります。AH（認証ヘッダ／IPプロトコル番号51）はパケットの改ざん検知と送信元の確認だけを行い、暗号化はしません。ESP（暗号ペイロード／同50）は暗号化と認証の両方を担うため、VPNではESPが主に使われます。AHは外側のIPヘッダまで完全性の計算に含めるためNAT配下では成立しません。IKE（鍵交換）は暗号鍵を安全に交換し、SAを確立・更新します。 ### トランスポートモードとトンネルモードはどう違いますか？ 暗号化する範囲が違います。トランスポートモードは元のIPヘッダを残してデータ部分だけを保護するため、端末どうしの直接通信に向く方式です。トンネルモードは元のパケットをまるごと暗号化し、外側に新しいIPヘッダを付けるため、アドレスまで隠せます。VPN機器を出入口にできることから、サイト間VPNではトンネルモードが基本です。 ### IPsecで開けるべきポート番号はどれですか？ 3つです。IKEの鍵交換に使うUDP 500番、NAT-T用のUDP 4500番、素のESPを通すIPプロトコル50番です。AHを使う構成ではIPプロトコル51番も要ります。NAT-TはRFC 3948で規定され、経路上にNATを検出するとIKEはUDP 500番から4500番へ移ります。「ポートは開けたのにつながらない」という相談では、TCP/UDPではないIPプロトコル50番の設定漏れが定番です。 ### クラウドとの接続でもIPsecは使えますか？ 使えます。AWS・Azure・Google Cloudは、拠点とクラウドの仮想ネットワークをIPsecで結ぶサイト間VPN（Site-to-Site VPN）を備えています。AWSは1つのVPN接続に2本のトンネルを用意し、IKEv2とNATトラバーサルに対応する構成です。Google CloudはHA VPNのSLAを大半のトポロジで99.99%と公開しており、可用性の要件で選び分けられます。専用線より低コストで社内からクラウド上のシステムへ直接到達できます。 ## 関連記事 - [VPNとは？仕組み・種類・メリットとデメリット、企業導入の判断基準を解説](https://www.issoh.co.jp/column/details/13215/)：IPsecが土台となるVPN全体の種類と導入判断を整理しています。 - [TLSとは？SSLとの違い・仕組みとバージョン選定を実装者向けに解説](https://www.issoh.co.jp/tech/details/13318/)：もう一方のVPN方式であるSSL/TLSの仕組みを扱っています。 - [閉域網とは？VPN・専用線との違いと業務システム構築での選び方を解説](https://www.issoh.co.jp/column/details/13181/)：IPsec-VPNで足りるか閉域網へ寄せるかを比較しています。 - [ゼロトラストネットワーク（ZTNA）とは？VPNとの違いと製品選定・導入判断を解説](https://www.issoh.co.jp/column/details/13099/)：自前運用を見送る場合の移行先として端末単位の認可を扱います。 - [AWS Direct Connectとは？専用線接続の仕組み・VPNとの違い・料金と導入判断](https://www.issoh.co.jp/tech/details/15476/)：帯域や遅延が足りない場合の専用線接続を扱っています。 --- 出典: [IPsecとは？仕組み・AH/ESP/IKEとVPNでの使い方、SSL/TLSとの違いと選び方を解説]()（株式会社一創）