カテゴリー: 未分類

フォーティネットがSSL-VPNを廃止へ ― 2026年5月サポート終了と企業が取るべき対応

米Fortinet（フォーティネット）が提供してきたSSL-VPN機能の技術サポートを2026年5月に終了することを正式に発表しました。この決定は、日本法人フォーティネットジャパンが2025年10月に開催した顧客・販売パートナー向けウェビナーにおいて明らかにされたものであり、長年にわたりテレワークやリモートメンテナンス用途で広く利用されてきた企業にとって大きな転換点となります。

SSL-VPNは、インターネット経由で社内ネットワークへ安全に接続するための代表的な技術として普及してきましたが、近年はランサムウェア攻撃の初期侵入経路として悪用される事例が急増しています。特にFortinet製装置を含む複数ベンダーのSSL-VPN実装において、深刻な脆弱性（CVE-2024-21762など）が報告されており、運用面でもリスクの顕在化が続いていました。

このような背景から、FortinetはSSL-VPN機能の廃止を決断し、後継としてIPsec VPNやゼロトラストネットワークアクセス（ZTNA）などの方式への移行を推奨しています。本稿では、このSSL-VPN廃止の経緯と影響を整理し、現在Fortinet製SSL-VPNを利用している企業が検討すべき現実的な移行選択肢について解説します。

フォーティネットによるSSL-VPN廃止の背景

フォーティネットがSSL-VPNの提供を終了する決定を下した背景には、近年のサイバー攻撃動向と、同社が掲げるゼロトラスト化への技術的転換があります。SSL-VPNは長年にわたり、テレワークやリモート管理のための主要なリモートアクセス手段として利用されてきました。しかし、2020年代以降、この仕組みがランサムウェアや標的型攻撃の侵入経路として悪用される事例が相次いでおり、攻撃者にとって「境界防御の最も弱い部分」とみなされるようになりました。

実際、Fortinet製品を含むSSL-VPN機能では、認証回避やリモートコード実行（RCE）につながる深刻な脆弱性が複数報告されています。これらの脆弱性は、修正版の提供後も攻撃者に継続的に利用される傾向があり、パッチ適用の遅れや設定不備が攻撃リスクを高める要因となっていました。

こうした状況を受け、フォーティネットは「FortiOS」最新版においてSSL-VPN機能を削除し、より安全性と制御性の高いIPsec VPNおよびZTNA（Zero Trust Network Access）への移行を推奨する方針を明確にしています。これは単なる機能の廃止ではなく、同社のリモートアクセス戦略を「境界防御からゼロトラストへ」転換することを意味しています。

なぜSSL-VPNが廃止されるのか

フォーティネットがSSL-VPNを廃止する最大の理由は、セキュリティ上の恒常的なリスクと技術的限界にあります。SSL-VPNは、TLS暗号化を利用して社外から社内ネットワークに安全に接続できる方式として普及しましたが、その構造上、認証突破後に広範なネットワーク権限を付与する点が攻撃者に悪用されやすい弱点となっていました。

近年では、CVE-2024-21762をはじめとする複数の重大脆弱性がFortinet製SSL-VPNで確認されており、これらはゼロデイ攻撃として現実に悪用されています。脆弱性の多くは、ユーザー認証やセッション管理、Webインターフェースの入力処理に起因するものであり、リモートからのコード実行やシステム侵害を許す可能性があります。加えて、企業側でのパッチ適用遅延や設定不備が重なることで、侵入防御が形骸化するケースも少なくありません。

また、フォーティネットは自社のセキュリティアーキテクチャを「ゼロトラスト」モデルへと移行させており、ネットワーク単位で接続を許可するSSL-VPNはこの方針と整合しなくなっています。ゼロトラストでは、利用者・端末・アプリケーションを個別に検証し、必要最小限のアクセスのみを許可することが求められます。従来のSSL-VPNは「一度接続すれば広範なリソースに到達できる」設計であり、この概念とは根本的に相容れません。

これらの理由から、フォーティネットはSSL-VPNを段階的に廃止し、後継としてより安全な通信制御が可能なIPsec VPNおよびZTNA（Zero Trust Network Access）への移行を正式に推奨しています。

発表内容とサポート終了時期

Fortinet（フォーティネット）は、同社のファイアウォール製品およびリモートアクセス機能で広く利用されてきた「SSL-VPNトンネルモード」について、バージョン FortiOS 7.6.3 以降ではGUI／CLI上から利用できなくなると明記しています。具体的には「Starting in FortiOS 7.6.3, the SSL VPN tunnel mode feature is replaced with IPsec VPN … SSL VPN tunnel mode is no longer available in the GUI and CLI. Settings will not be upgraded from previous versions.」という公式リリースノート上の記述があります。

さらに、同社および関連解説記事では、技術サポート（End of Engineering Support：EoES）として「2026年5月」が国内企業の利用環境における事実上の区切りになると報じられています。たとえば、海外パートナー向けの公表資料では“FortiOS 7.4 のEoES：May 2026”という記述が確認されています。

このため、フォーティネット製のSSL-VPNを現在運用している企業に対しては、2026年5月までに代替構成へ移行を完了させることが強く推奨されています。サポート終了後には、脆弱性修正・機能改善の対象外となるため、同機能を継続して運用することはセキュリティリスクを伴います。

なお、上記はあくまで公表された仕様変更およびサポートポリシーに基づくものであり、貴社の個別契約や機器モデル・ファームウェアのバージョンによって影響範囲は異なります。移行計画を検討する際には、使用中機材のモデル・バージョン・構成を早期に確認することが肝要です。

SSL-VPNの構造的な問題点

SSL-VPNは、TLS（Transport Layer Security）を用いて通信を暗号化し、インターネット経由で社内ネットワークへ安全にアクセスすることを目的として設計された技術です。しかし、その構造上の設計と運用の特性から、現代の脅威環境においては複数の根本的な課題を抱えています。

第一に、接続後の権限範囲が過大であることが挙げられます。SSL-VPNは、一度認証が成功すると社内ネットワーク全体または広範囲のサブネットにアクセスできる構成が一般的です。この「トンネル内全許可」モデルは、攻撃者が一度資格情報を窃取すれば、内部の多数のシステムへ横展開できるという致命的なリスクを伴います。実際、近年発生した複数のランサムウェア攻撃では、侵入経路としてSSL-VPNが悪用され、侵入後にActive Directoryやファイルサーバーなどへ被害が拡大した事例が報告されています。

第二に、ゼロデイ脆弱性の影響範囲が大きいことです。SSL-VPNは外部公開が前提であるため、脆弱性が発覚した際には攻撃者が即座にインターネット上から探索・攻撃を仕掛けることが可能です。特にFortinet製SSL-VPNでは、CVE-2022-42475やCVE-2024-21762などの重大なリモートコード実行脆弱性が確認されており、修正版リリース前から実際に攻撃に利用されていました。パッチ適用の遅延や検証不足によって、企業が攻撃対象となるリスクが常に存在します。

第三に、VPNという技術モデル自体が「境界防御」依存であることです。従来のVPNは「外部と内部を分け、内部は信頼できる」という前提に基づいて設計されています。しかし、クラウド利用の普及やモバイル端末の増加により、社内外の境界が曖昧化した現在では、このモデルでは十分な防御が成立しません。ゼロトラストの考え方では、すべての通信・ユーザー・端末を都度検証する必要があり、SSL-VPNのように一度認証すれば広範囲にアクセスできる仕組みは不適合とされています。

このように、SSL-VPNは暗号化通信という点では有効な技術であるものの、アクセス制御や権限分離、脆弱性対応の観点からは限界に達しており、現行の脅威モデルに対応するには構造的な再設計が不可欠です。フォーティネットがSSL-VPNを廃止する決定は、これらの構造的欠陥を踏まえた合理的な判断といえます。

現在SSL-VPNを利用している企業が取るべき移行方針

フォーティネットがSSL-VPNの技術サポートを2026年5月に終了することを発表したことにより、現在この機能を利用している企業は、今後の接続方式を早急に再検討する必要があります。SSL-VPNは長年にわたりリモートアクセスの標準的手段として用いられてきましたが、近年では深刻な脆弱性の報告やランサムウェア攻撃の侵入経路としての悪用が続発しており、フォーティネット以外の製品を含め、構造的にリスクが高い技術と見なされています。

フォーティネットは、従来のVPN型リモートアクセスからゼロトラストモデルへの転換を明確に打ち出しており、今後はIPsec VPNやZTNA（Zero Trust Network Access）、さらにはSASE（Secure Access Service Edge）などの方式への移行が現実的な選択肢となります。企業としては、機能の代替だけでなく、セキュリティアーキテクチャそのものを見直す機会と捉えることが重要です。

本節では、SSL-VPNの廃止を踏まえ、現行利用企業が取るべき移行方針を段階的に整理し、安全かつ継続的にリモートアクセスを運用するための実践的な方向性を示します。

1. VPNを継続する場合の選択肢

SSL-VPN廃止後も、既存の運用環境やネットワーク構成を大きく変えずにリモートアクセスを維持したい企業にとっては、VPN技術を継続利用する選択肢が現実的です。ただし、従来と同じ構成を維持することは安全上の課題を残すため、暗号方式やアクセス制御の再設計が不可欠です。主な選択肢としては以下の三つが挙げられます。

（1）IPsec VPNへの移行

IPsec（Internet Protocol Security）VPNは、インターネット層で暗号化・認証を行う標準化されたVPNプロトコルであり、SSL-VPNの後継技術として最も一般的な選択肢です。Fortinet自身もSSL-VPN機能の廃止に伴い、FortiGateシリーズでのリモートアクセスはIPsec VPNへの移行を正式に推奨しています。IPsecは高い暗号強度と相互認証（IKEv2、証明書認証など）を備え、機密性の高い通信に適しています。一方で、初期設定が複雑であり、クライアント構成やファイアウォールルールの見直しが必要になる場合があります。

（2）他社製SSL-VPNへの移行（非推奨）

一時的な延命策として、他社製のSSL-VPN製品に切り替える方法も存在します。しかし、SSL-VPNという技術自体が抱える構造的リスク（認証回避、脆弱性の多発、侵入後の横展開の容易さ）は、ベンダーが異なっても本質的には解消されません。実際、2020年代以降、各社のSSL-VPN製品に対して重大なゼロデイ脆弱性が相次いで報告されており、攻撃者による侵入経路として頻繁に悪用されています。このため、他社製SSL-VPNへの移行は恒久的な解決策とは言えず、短期的な暫定対応に留めるのが望ましいとされています。

（3）SASE／クラウドVPNサービスの利用

近年は、クラウドを経由してセキュアなアクセスを実現するSASE（Secure Access Service Edge）やクラウドVPNサービスが注目されています。これらのサービスは、トラフィックをクラウド上で検査・暗号化し、ユーザー認証や脅威検知を一元的に行う仕組みです。従来のVPNのように企業ネットワークに直接接続する必要がなく、通信経路を細かく制御できる点でセキュリティ面の優位性があります。代表的なサービスには、Zscaler Private Access（ZPA）、Palo Alto Prisma Access、Cloudflare Oneなどがあります。

ただし、SASEも内部的にはVPNトンネルを使用する場合があり、構成によってはゼロトラスト型ZTNAほどの粒度で制御できないことがあります。したがって、長期的にはゼロトラストアーキテクチャへの移行を見据え、SASEをその過渡期のソリューションとして位置づけるのが合理的です。

VPNを継続する場合でも「境界防御」モデルを前提とした設計をそのまま踏襲するのは危険であり、強固な認証、多層防御、マイクロセグメンテーションの導入など、ゼロトラストの考え方を段階的に取り入れることが求められます。

2. VPNを使わない場合の選択肢

フォーティネットのSSL-VPN廃止は、企業にとって従来の「VPN依存型リモートアクセス」から脱却する契機となります。近年では、ネットワーク単位で接続を許可するVPNモデルが抱えるリスクを回避するため、VPNを前提としないリモートアクセス方式が急速に普及しています。これらの方式は、ゼロトラストの考え方を基盤としており、「接続させないことによる防御」「アプリケーション単位での認可」を実現するものです。代表的な選択肢は以下の三つです。

（1）ZTNA（Zero Trust Network Access）

ZTNAは、VPNの後継技術として最も注目されている方式です。ユーザーや端末がネットワークに接続するのではなく、アクセス対象のアプリケーションごとに認証・検証を行います。これにより、攻撃者が一度侵入しても内部ネットワーク全体に横展開することを防止できます。ZTNAは、ユーザー属性・端末状態・場所・時間などの要素を組み合わせて動的にアクセス可否を判定するため、認証強度と柔軟性の両立が可能です。
Fortinetをはじめ、Zscaler、Palo Alto Networks、Cloudflareなど主要ベンダーがZTNAソリューションを提供しています。特にフォーティネットは自社のZTNAをFortiGateおよびFortiClient製品に統合しており、既存インフラを活かした移行が可能です。

（2）IdP連携型リバースプロキシ／クラウドゲートウェイ

VPNを介さずに社内システムへ安全にアクセスするもう一つの方法が、IdP（アイデンティティプロバイダー）と連携したリバースプロキシ方式です。Azure AD Application ProxyやCloudflare Access、Google BeyondCorp Enterpriseなどが代表的な実装です。これらはWebアプリケーションを社外から直接公開する代わりに、クラウド上のプロキシが通信を中継し、IdPによる認証（多要素認証や条件付きアクセス）を必須とします。
この方式は、VPNトンネルを張らずにHTTPS通信のみで完結するため、外部からの侵入経路を最小化できます。また、Active Directoryへの直接依存を避ける構成も可能であり、ADの障害や不正利用リスクを軽減できる点も利点です。

（3）VDI／DaaS（仮想デスクトップ）

VPNを廃止しても、社内システムへの業務アクセスを維持する手段としてVDI（Virtual Desktop Infrastructure）やDaaS（Desktop as a Service）の採用も有効です。ユーザーは社外端末から仮想デスクトップにリモート接続し、その内部でのみ業務アプリケーションを利用します。データは常に社内またはクラウド上の仮想環境に留まり、端末側には保存されません。
この方式はデータ漏えいリスクを最小化できる一方で、Active Directoryやネットワーク基盤への依存度が高いため、障害時の影響範囲が広くなる点には留意が必要です。認証基盤をクラウドIdPへオフロードし、冗長化を図ることが安全運用の鍵となります。

これらの方式はいずれも「ユーザーがネットワークに接続する」のではなく、「認可されたリソースに限定的にアクセスする」点に特徴があります。特にZTNAやIdP連携型プロキシは、近年のランサムウェア攻撃の主要侵入経路となっているVPNやRDPを排除できる手段として、国内外で急速に採用が拡大しています。企業は、単なるVPNの代替ではなく、リモートアクセス全体を再設計する視点でこれらの方式を検討することが重要です。

セキュリティ強度で見た選択肢の優先順位

各リモートアクセス方式には、設計思想・通信経路・認証モデルの違いがあり、それぞれが持つセキュリティ強度には明確な差があります。ここでは、近年の脅威動向――特にVPNやRDPを狙った侵入、Active Directoryの認証連携を悪用した攻撃の増加――を踏まえたうえで、現実的な安全性の高い順に整理します。

1. ZTNA（Zero Trust Network Access）

ZTNAは、現在最も安全性が高い方式と評価されています。VPNのようにネットワーク全体を信頼せず、ユーザー・端末・アプリケーションを個別に検証した上で、必要最小限の通信のみを許可します。アクセスは都度認証され、通信経路もアプリケーション単位で分離されるため、侵入後の横展開（ラテラルムーブメント）が極めて困難です。さらに、クラウドIDプロバイダーと統合することで、Active Directoryの障害や不正利用の影響を局所化できます。

2. VDI／DaaS（仮想デスクトップ）

VDIやDaaSは、ユーザーが直接社内ネットワークに接続せず、仮想環境内で業務を完結させる方式です。業務データが端末に残らないため、情報漏えい耐性に優れています。特に金融・公共分野など、データ持ち出しが禁止されている環境では有効な手段です。ただし、認証基盤としてActive Directoryを利用する構成が多いため、ADの脆弱性や障害に対する冗長化対策が重要となります。

3. IdP連携型リバースプロキシ／クラウドゲートウェイ

Webアプリケーションに特化した安全なリモートアクセスを提供する方式です。IdP（Azure AD、Okta、Google Workspaceなど）による多要素認証（MFA）と条件付きアクセスを活用し、通信はHTTPSのみに限定されます。AD連携を排除できる構成も多く、VPNを介さずに安全なWebアクセスを実現できます。ただし、非Webアプリケーション（RDP、SMBなど）には適用範囲が限られます。

4. SASE／クラウドVPNサービス

クラウド上で通信を暗号化・検査し、ユーザーごとのポリシーを適用するSASE（Secure Access Service Edge）は、従来型VPNよりも安全性が高い方式です。ZTNA機能を統合するベンダーも増えており、運用面での利便性とセキュリティの両立が期待できます。ただし、構成によってはRDPなどの従来トンネルを維持するケースがあり、その場合はゼロトラスト実装よりもリスクが残ります。

5. IPsec VPN

IPsec VPNは、暗号強度の高い通信方式として信頼性がありますが、「一度接続すれば内部ネットワークへ広範囲にアクセス可能」という構造上のリスクを抱えています。攻撃者が認証情報を入手すれば、内部システムへ容易に侵入できる点はSSL-VPNと同様です。多要素認証の導入やネットワーク分割を徹底しない限り、ゼロトラスト要件を満たすことはできません。

6. 他社製SSL-VPN（非推奨）

他社製品であっても、SSL-VPNという技術モデル自体が構造的に脆弱である点は変わりません。複数ベンダーのSSL-VPNでゼロデイ脆弱性が繰り返し報告されており、特にランサムウェア攻撃では最も多く悪用されている経路の一つです。サポート期間やパッチ提供に依存するため、持続的な防御は困難です。

ZTNAが最も安全であり、他社製SSL-VPNは最も脆弱という序列は変わりません。
今後は、VPNやRDPを「必要悪」として維持するのではなく、認証・可視化・通信制御を統合したゼロトラスト基盤への移行を前提に、段階的な置き換えを進めることが求められます。

おわりに

フォーティネットによるSSL-VPNの廃止は、単なる機能削除ではなく、リモートアクセスのあり方そのものを見直す転換点となります。長年、多くの企業がSSL-VPNを「安全な社内接続手段」として運用してきましたが、近年ではその仕組みが攻撃者にとって格好の侵入口となり、実際に複数のランサムウェア攻撃や情報漏えい事件で悪用されてきました。フォーティネットがこの技術を終息させるのは、こうした現実的な脅威と、ゼロトラストモデルへの潮流を踏まえた必然的な判断と言えます。

今後、企業が取り得る選択肢は、従来型VPNを継続しながら防御層を強化するか、もしくはゼロトラスト型アクセスモデルへ移行するかのいずれかです。特にZTNA（Zero Trust Network Access）は、アクセス制御をアプリケーション単位で行い、ユーザー・端末・通信を常に検証する仕組みを備えており、現在の攻撃環境に最も適した方式と評価されています。

リモートアクセスは、テレワークやクラウド利用の拡大に伴い、企業の基盤インフラとして不可欠な存在となりました。その一方で、従来の境界防御型モデルに依存し続けることは、組織全体のリスクを高める結果につながります。SSL-VPN廃止という現実を、単なる製品ライフサイクルの問題としてではなく、セキュリティアーキテクチャを刷新する契機として捉え、計画的に次世代の安全なアクセスモデルへの移行を進めることが求められます。

参考文献

Meta AIアプリは“プライバシー災害”なのか？──その実態とユーザーが取るべき対策

2025年6月、テック業界を揺るがす衝撃的な報道がTechCrunchにより明らかになりました。

Meta社がリリースしたAIチャットアプリ「Meta AI」は、その高機能さとは裏腹に、“ユーザーのプライバシーが著しく危険にさらされている”として批判を浴びています。

この記事では、問題の本質と、私たちユーザーが今できることについて整理します。

🔍 何が問題なのか？

Meta AIには「Share（共有）」というボタンがあり、これを押すとチャットの内容が「Discoverフィード」と呼ばれる公開タイムラインに投稿される仕組みになっています。

しかし問題はその設計にありました。

  • ユーザーの多くが「共有＝保存」だと思っていた
  • シェアボタンを押すと「一部公開されます」といった軽い文言が表示されるが、全世界に公開されるとは明記されていなかった
  • 実際にDiscoverフィードには、「病気の相談」「法的トラブル」「性的な話題」など、非常にプライベートな内容が次々に表示されていた

まるで、「検索可能なブラウザ履歴をインターネット上にさらした」かのような事態が起きていたのです。

🧠 ユーザーの認識と実態のギャップ

ユーザーの多くは、Meta AIを「自分専用のAIアシスタント」として使っていました。たとえば：

  • 「私の健康状態を説明すると…」
  • 「これは誰にも言えないことなんだけど」
  • 「税金対策について教えて」

といった発言が、実名やSNSハンドルとともにDiscoverフィードに掲載される例もありました。

Meta側はこれに対して、「シェア機能の使い方について改善中」と説明していますが、既に公開されてしまった内容が完全に消える保証はありません。

📦 なぜこんなことが起きるのか？

これは一種のダークパターン（誤認させるUI設計）と批判されています。

  • ユーザーは「共有」＝「保存」と解釈しがち
  • ポップアップで“誰でも見られる”とはっきり言わない
  • Instagram・Facebookとの連携で「実名アカウント」とチャット内容が紐づく

結果として、「共有するつもりがなかった情報まで、全世界に公開されてしまった」という事例が後を絶ちません。

✅ ユーザーが取るべき対策

この問題を受けて、私たちが今できる具体的な対策をまとめました。

対策内容
Meta AIにプライベートな内容は絶対に入力しない氏名・住所・病歴・法的情報などは入力NG
「Share（共有）」ボタンは絶対に押さない押すとチャットがDiscoverに公開される
チャット履歴の削除を定期的に行うMeta AIアプリまたは設定から削除可能
公開設定・SNS連携を見直すInstagramやFacebookの公開範囲も確認
学習への使用をオプトアウトする（可能なら）国・地域によって制限があります

🔚 終わりに──“無料AI”の裏にある代償

Meta AIは確かに強力なAIですが、その裏では「ユーザーの会話をMetaが使うこと」を前提とした設計になっています。

無料で便利なAIを使えるという代償として、私たちのプライバシーが“商品”として使われている可能性があることを忘れてはいけません。

プライベートな話題は、信頼できる環境かローカルで処理できるツールで行うべきです。Meta AIのようなクラウド型AIに入力する前に、「この内容は他人に見られても問題ないか？という問いを、ひとつひとつ自分に投げかけることが求められています。

🔗 出典記事

ISOファイルをUSBフラッシュドライブ（USBメモリ）に書き込む（macOS編）

以前、WindowsでRufusを使って、ISOファイルをUSBフラッシュドライブ（以下、USBメモリ）に書き込む方法をご紹介しました。

今回はmacOSでISOファイルをUSBメモリに書き込む方法を解説します。

USBメモリのディスクデバイスを確認

diskutil listコマンドを使って、マウントしているUSBメモリが割り当てられているディスクデバイスを確認します。

$ diskutil list
/dev/disk0 (internal):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                         1.0 TB     disk0
   1:             Apple_APFS_ISC                         524.3 MB   disk0s1
   2:                 Apple_APFS Container disk3         994.7 GB   disk0s2
   3:        Apple_APFS_Recovery                         5.4 GB     disk0s3

/dev/disk3 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +994.7 GB   disk3
                                 Physical Store disk0s2
   1:                APFS Volume Macintosh HD            15.2 GB    disk3s1
   2:              APFS Snapshot com.apple.os.update-... 15.2 GB    disk3s1s1
   3:                APFS Volume Preboot                 350.0 MB   disk3s2
   4:                APFS Volume Recovery                804.6 MB   disk3s3
   5:                APFS Volume Data                    107.5 GB   disk3s5
   6:                APFS Volume VM                      20.5 KB    disk3s6

/dev/disk4 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:     FDisk_partition_scheme                        *7.9 GB     disk4
   1:             Windows_FAT_32 UBUNTU-SERV             7.9 GB     disk4s1

上記の場合、/dev/disk4が今回ISOファイルを書き込むUSBフラッシュドライブ（USBメモリ）です。すでに過去に書き込み済みのUSBメモリであれば名前（NAME）、そうでない場合は容量（SIZE）等で判断してください。

USBメモリを初期化する

ディスクデバイスが誤っていないかを十分に確認のうえ、diskutil eraseDiskコマンドでUSBメモリを初期化します。

$ diskutil eraseDisk FAT32 UBUNTU2204 /dev/disk4
Started erase on disk4
Unmounting disk
Creating the partition map
Waiting for partitions to activate
Formatting disk4s2 as MS-DOS (FAT32) with name UBUNTU2204
512 bytes per physical sector
/dev/rdisk4s2: 15023424 sectors in 1877928 FAT32 clusters (4096 bytes/cluster)
bps=512 spc=8 res=32 nft=2 mid=0xf8 spt=32 hds=255 hid=411648 drv=0x80 bsec=15052800 bspf=14672 rdcl=2 infs=1 bkbs=6
Mounting disk
Finished erase on disk4

今回使用しているUSBメモリは8GBなので、FAT32でフォーマットしています。
名前（NAME）を指定したので、その名前に変わっているか確認してみましょう。

$ diskutil list
/dev/disk0 (internal):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                         1.0 TB     disk0
   1:             Apple_APFS_ISC                         524.3 MB   disk0s1
   2:                 Apple_APFS Container disk3         994.7 GB   disk0s2
   3:        Apple_APFS_Recovery                         5.4 GB     disk0s3

/dev/disk3 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +994.7 GB   disk3
                                 Physical Store disk0s2
   1:                APFS Volume Macintosh HD            15.2 GB    disk3s1
   2:              APFS Snapshot com.apple.os.update-... 15.2 GB    disk3s1s1
   3:                APFS Volume Preboot                 350.0 MB   disk3s2
   4:                APFS Volume Recovery                804.6 MB   disk3s3
   5:                APFS Volume Data                    107.5 GB   disk3s5
   6:                APFS Volume VM                      20.5 KB    disk3s6

/dev/disk4 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *7.9 GB     disk4
   1:                        EFI EFI                     209.7 MB   disk4s1
   2:       Microsoft Basic Data UBUNTU2204              7.7 GB     disk4s2

タイプ（TYPE）および名前（NAME）が変わっていることからUSBメモリが初期化されたことが確認できます。

マウントを解除する

書き込みを行う前にマウントを解除しておきます。これをしておかないと、ISOファイルを書き込む時にエラーになります。

$ diskutil umountDisk /dev/disk4
Unmount of all volumes on disk4 was successful

デスクトップからUSBメモリのアイコンが消えたかを確認してください。消えていればマウントが解除されています。

ISOファイルをUSBメモリにコピーする

では、ISOファイルをUSBメモリにコピーしていきましょう。USBメモリへの書き込みにはddコマンドを使用します。

書き込みの際にはディスクデバイスが正しいことを十分確認のうえ行ってください。
また、ddコマンド実行時にsudoコマンドを併用する場合、カレントディレクトリを表す”~“を使用すると正しいパスにならない場合がありますので、フルパスで指定したり、ISOファイルのあるディレクトリに移動してから実行してください。
ddコマンドのデフォルトブロックサイズが512なので、本例では、1M（1MB）に増やして実行しています。

$ sudo dd if=/Users/t0k0sh1/Downloads/ubuntu-22.04-live-server-amd64.iso of=/dev/disk4 bs=1M
1398+1 records in
1398+1 records out
1466714112 bytes transferred in 148.687247 secs (9864424 bytes/sec)

最後に

以上で、USBメモリへの書き込みが完了しました。実際に使用して正しく書き込めていることを確認してください。

本手順ではディスクデバイスの指定を間違わないようにすることが最も重要になります。この点には十分注意して操作を実施してください。

ISOファイルをUSBフラッシュドライブ（USBメモリ）に書き込む（Rufus）

最近では、CD/DVDドライブが搭載されていないPCが多いため、LinuxのインストールなどではUSBフラッシュドライブ（以降はUSBメモリと表記）を使うことが一般的です。

本記事では、WindowsでISOファイルをUSBメモリに書き込むRufusというツールの使い方について解説します。

Rufusのダウンロード

まずは、公式サイトへアクセスします。

下のほうへスクロールしていくと、ダウンロードというセクションが見つかります。ここにある「Rufus x.xx」（執筆時点では「Rufus 3.18」）というリンクをクリックしてダウンロードしてください。

使用方法

ダウンロードしたrufus-x.xx.exeを起動すると、初回は以下のようなダイアログが表示される場合があります。

お好きなほうを選択してください。

ダイアログが閉じると、Rufusが起動します。

デバイスやボリュームラベルの表示内容はご使用のUSBメモリによって異なりますが、特に気にする必要はありません。
私は前回Linux Mint 20.3をインストールしたUSBメモリを使用しているため、このような表示になっています。

使用方法について行うことは多くなく、以下の３点を押さえておけば問題ありません。

  1. USBメモリを挿す
  2. ISOファイルを選択する
  3. 「スタート」ボタンをクリック（そして待つ）

まずは、USBメモリを挿しておいてください。デバイス欄にそのUSBの情報が表示されます。USBメモリを挿していない場合やうまく認識していない場合はデバイス欄は空欄になります。

USBメモリが認識されたら、次にISOファイルを選択します。ブートの種類欄の右の「選択」ボタンをクリックしてファイル選択ダイアログを表示します。

事前にダウンロードしておいたISOファイルを選択して、「開く」ボタンをクリックしてください。

USBメモリに書き込む準備ができました。「スタート」ボタンをクリックしてください。

いくつかダイアログが表示される場合があります。

ISOHybrid イメージの検出

「ISO イメージモードで書き込む（推奨）」を選択したままで、「OK」ボタンをクリックしてください。

ダウンロードが必要です

「はい」ボタンをクリックしてください。

警告

すでにUSBメモリにデータがある場合に表示されます。使用しているUSBメモリが間違っていないことが確認できているのであれば「OK」ボタンをクリックしてください。

USBメモリへの書き込みが始まると、プログレスバーが増えていきます。

プログレスバーが100%になると、「スタート」ボタンがクリックできるようになります。

完了を通知するダイアログは示されないため、デバイス欄のUSBメモリの名前が変更されていること、やプログレスバーが100%で「準備完了」になっていることを確認してください。

モバイルバージョンを終了