Windows 10 ESUをめぐる混乱 ― EUでは「無条件無料」、他地域は条件付き・有料のまま

2025年9月、Microsoftは世界中のWindows 10ユーザーに大きな影響を与える方針転換を発表しました。

Windows 10は2025年10月14日でサポート終了を迎える予定であり、これは依然として世界で数億台が稼働しているOSです。サポートが終了すれば、セキュリティ更新が提供されなくなり、利用者はマルウェアや脆弱性に対して無防備な状態に置かれることになります。そのため、多くのユーザーにとって「サポート終了後も安全にWindows 10を使えるかどうか」は死活的な問題です。

この状況に対応するため、Microsoftは Extended Security Updates(ESU)プログラム を用意しました。しかし、当初は「Microsoftアカウント必須」「Microsoft Rewardsなど自社サービスとの連携が条件」とされ、利用者にとって大きな制約が課されることが明らかになりました。この条件は、EUのデジタル市場法(DMA)やデジタルコンテンツ指令(DCD)に抵触するのではないかと批判され、消費者団体から強い異議申し立てが起こりました。

結果として、EU域内ではMicrosoftが大きく譲歩し、Windows 10ユーザーに対して「無条件・無料」での1年間のセキュリティ更新提供を認めるという異例の対応に至りました。一方で、米国や日本を含むEU域外では従来の条件が維持され、地域によって利用者が受けられる保護に大きな格差が生じています。

本記事では、今回の経緯を整理し、EUとそれ以外の地域でなぜ対応が異なるのか、そしてその背景にある規制や消費者運動の影響を明らかにしていきます。

背景

Windows 10 は 2015 年に登場して以来、Microsoft の「最後の Windows」と位置付けられ、長期的に改良と更新が続けられてきました。世界中の PC の大半で採用され、教育機関や行政、企業システムから個人ユーザーまで幅広く利用されている事実上の標準的な OS です。2025 年 9 月現在でも数億台規模のアクティブデバイスが存在しており、これは歴代 OS の中でも非常に大きな利用規模にあたります。

しかし、この Windows 10 もライフサイクルの終了が近づいています。公式には 2025 年 10 月 14 日 をもってセキュリティ更新が終了し、以降は既知の脆弱性や新たな攻撃に対して無防備になります。特に個人ユーザーや中小企業にとっては「まだ十分に動作している PC が突然リスクにさらされる」という現実に直面することになります。

これに対して Microsoft は従来から Extended Security Updates(ESU) と呼ばれる仕組みを用意してきました。これは Windows 7 や Windows Server 向けにも提供されていた延長サポートで、通常サポートが終了した OS に対して一定期間セキュリティ更新を提供するものです。ただし、原則として有償で、主に企業や組織を対象としていました。Windows 10 に対しても同様に ESU プログラムが設定され、個人ユーザーでも年額課金によって更新を継続できると発表されました。

ところが、今回の Windows 10 ESU プログラムには従来と異なる条件が課されていました。利用者は Microsoft アカウントへのログインを必須とされ、さらに Microsoft Rewards やクラウド同期(OneDrive 連携や Windows Backup 機能)を通じて初めて無償の選択肢が提供されるという仕組みでした。これは単なるセキュリティ更新を超えて、Microsoft のサービス利用を実質的に強制するものだとして批判を呼びました。

特に EU では、この条件が デジタル市場法(DMA) に違反する可能性が強調されました。DMA 第 6 条(6) では、ゲートキーパー企業が自社サービスを不当に優遇することを禁止しています。セキュリティ更新のような必須の機能を自社サービス利用と結びつけることは、まさにこの規定に抵触するのではないかという疑問が投げかけられました。加えて、デジタルコンテンツ指令(DCD) においても、消費者が合理的に期待できる製品寿命や更新提供義務との整合性が問われました。

こうした法的・社会的な背景の中で、消費者団体や規制当局からの圧力が強まり、Microsoft が方針を修正せざるを得なくなったのが今回の経緯です。

EUにおける展開

EU 域内では、消費者団体や規制当局からの強い圧力を受け、Microsoft は方針を大きく修正しました。当初の「Microsoft アカウント必須」「Microsoft Rewards 参加」などの条件は撤廃され、EEA(欧州経済領域)の一般消費者に対して、無条件で 1 年間の Extended Security Updates(ESU)を無料提供することを約束しました。これにより、利用者は 2026 年 10 月 13 日まで追加費用やアカウント登録なしにセキュリティ更新を受けられることになります。

Euroconsumers に宛てた Microsoft の回答を受けて、同団体は次のように評価しています。

“We are pleased to learn that Microsoft will provide a no-cost Extended Security Updates (ESU) option for Windows 10 consumer users in the European Economic Area (EEA). We are also glad this option will not require users to back up settings, apps, or credentials, or use Microsoft Rewards.”

つまり、今回の修正によって、EU 域内ユーザーはセキュリティを確保するために余計なサービス利用を強いられることなく、従来どおりの環境を維持できるようになったのです。これは DMA(デジタル市場法)の趣旨に合致するものであり、EU の規制が実際にグローバル企業の戦略を修正させた具体例と言えるでしょう。

一方で、Euroconsumers は Microsoft の対応を部分的な譲歩にすぎないと批判しています。

“The ESU program is limited to one year, leaving devices that remain fully functional exposed to risk after October 13, 2026. Such a short-term measure falls short of what consumers can reasonably expect…”

この指摘の背景には、Windows 10 を搭載する数億台規模のデバイスが依然として市場に残っている現実があります。その中には、2017 年以前に発売された古い PC で Windows 11 にアップグレードできないものが多数含まれています。これらのデバイスは十分に稼働可能であるにもかかわらず、1 年後にはセキュリティ更新が途絶える可能性が高いのです。

さらに、Euroconsumers は 持続可能性と電子廃棄物削減 の観点からも懸念を表明しています。

“Security updates are critical for the viability of refurbished and second-hand devices, which rely on continued support to remain usable and safe. Ending updates for functional Windows 10 systems accelerates electronic waste and undermines EU objectives on durable, sustainable digital products.”

つまり、セキュリティ更新を短期で打ち切ることは、まだ使える端末を廃棄に追いやり、EU が掲げる「循環型消費」や「持続可能なデジタル製品」政策に逆行するものだという主張です。

今回の合意により、少なくとも 2026 年 10 月までは EU の消費者が保護されることになりましたが、その後の対応は依然として不透明です。Euroconsumers は Microsoft に対し、さらなる延長や恒久的な解決策を求める姿勢を示しており、今後 1 年間の交渉が次の焦点となります。

EU域外の対応と反応

EU 域外のユーザーが ESU を利用するには、依然として以下の条件が課されています。

  • Microsoft アカウント必須
  • クラウド同期(OneDrive や Windows Backup)を通じた利用登録
  • 年額約 30 ドル(または各国通貨換算)での課金

Tom’s Hardware は次のように報じています。

“Windows 10 Extended Support is now free, but only in Europe — Microsoft capitulates on controversial $30 ESU price tag, which remains firmly in place for the U.S.”

つまり、米国を中心とする EU 域外のユーザーは、EU のように「無条件・無償」の恩恵を受けられず、依然として追加費用を支払う必要があるという状況です。

不満と批判の声

こうした地域差に対して、各国メディアやユーザーからは批判が相次いでいます。TechRadar は次のように伝えています。

“Windows 10’s year of free updates now comes with no strings attached — but only some people will qualify.”

SNS やフォーラムでも「地理的差別」「不公平な二層構造」といった批判が見られます。特に米国や英国のユーザーからは「なぜ EU だけが特別扱いされるのか」という不満の声が強く上がっています。

また、Windows Latest は次のように指摘しています。

“No, you’ll still need a Microsoft account for Windows 10 ESU in Europe [outside the EU].”

つまり、EU を除く市場では引き続きアカウント連携が必須であり、プライバシーやユーザーの自由を損なうのではないかという懸念が残されています。

代替 OS への関心

一部のユーザーは、こうした対応に反発して Windows 以外の選択肢、特に Linux への移行を検討していると報じられています。Reddit や海外 IT コミュニティでは「Windows に縛られるよりも、Linux を使った方が自由度が高い」という議論が活発化しており、今回の措置が OS 移行のきっかけになる可能性も指摘されています。

報道の強調点

多くのメディアは一貫して「EU 限定」という点を強調しています。

  • PC Gamer: “Turns out Microsoft will offer Windows 10 security updates for free until 2026 — but not in the US or UK.”
  • Windows Central: “Microsoft makes Windows 10 Extended Security Updates free for an extra year — but only in certain markets.”

これらの記事はいずれも、「無条件無料は EU だけ」という事実を強調し、世界的なユーザーの間に不公平感を生んでいる現状を浮き彫りにしています。

考察

今回の一連の動きは、Microsoft の戦略と EU 規制の力関係を象徴的に示す事例となりました。従来、Microsoft のような巨大プラットフォーム企業は自社のエコシステムにユーザーを囲い込む形でサービスを展開してきました。しかし、EU ではデジタル市場法(DMA)やデジタルコンテンツ指令(DCD)といった法的枠組みを背景に、こうした企業慣行に実効的な制約がかけられています。今回「Microsoft アカウント不要・無条件での無料 ESU 提供」という譲歩が実現したのは、まさに規制当局と消費者団体の圧力が効果を発揮した例といえるでしょう。

一方で、この対応が EU 限定 にとどまったことは新たな問題を引き起こしました。米国や日本などのユーザーは依然として課金や条件付きでの利用を強いられており、「なぜ EU だけが特別扱いなのか」という不公平感が広がっています。国際的なサービスを提供する企業にとって、地域ごとの規制差がそのままサービス格差となることは、ブランドイメージや顧客信頼を損なうリスクにつながります。特にセキュリティ更新のような本質的に不可欠な機能に地域差を持ち込むことは、単なる「機能の差別化」を超えて、ユーザーの安全性に直接影響を与えるため、社会的反発を招きやすいのです。

さらに、今回の措置が 持続可能性 の観点から十分でないことも問題です。EU 域内でさえ、ESU 無償提供は 1 年間に限定されています。Euroconsumers が指摘するように、2026 年以降は再び数億台規模の Windows 10 デバイスが「セキュリティ更新なし」という状況に直面する可能性があります。これはリファービッシュ市場や中古 PC の活用を阻害し、電子廃棄物の増加を招くことから、EU が推進する「循環型消費」と真っ向から矛盾します。Microsoft にとっては、サポート延長を打ち切ることで Windows 11 への移行を促進したい意図があると考えられますが、その裏で「使える端末が強制的に廃棄に追い込まれる」構造が生まれてしまいます。

また、今回の事例は「ソフトウェアの寿命がハードウェアの寿命を強制的に決める」ことの危うさを改めて浮き彫りにしました。ユーザーが日常的に利用する PC がまだ十分に稼働するにもかかわらず、セキュリティ更新の停止によって利用継続が事実上困難になる。これは単なる技術的問題ではなく、消費者の信頼、環境政策、さらには社会全体のデジタル基盤に関わる大きな課題です。

今後のシナリオとしては、次のような可能性が考えられます。

  • Microsoft が EU との協議を重ね、ESU の延長をさらに拡大する → EU 法制との整合性を図りつつ、消費者保護とサステナビリティを両立させる方向。
  • 他地域でも政治的・消費者的圧力が強まり、EU と同等の措置が拡大する → 米国や日本で消費者団体が動けば、同様の譲歩を引き出せる可能性。
  • Microsoft が方針を変えず、地域間格差が固定化する → その場合、Linux など代替 OS への移行が加速し、長期的に Microsoft の支配力が揺らぐリスクも。

いずれにしても、今回の一件は「セキュリティ更新はユーザーにとって交渉余地のあるオプションではなく、製品寿命を左右する公共性の高い要素」であることを示しました。Microsoft がこの問題をどのように処理するのかは、単なる一製品の延命措置を超えて、グローバルなデジタル社会における責任のあり方を問う試金石になるでしょう。

おわりに

今回の Windows 10 Extended Security Updates(ESU)をめぐる一連の動きは、単なるサポート延長措置にとどまらず、グローバル企業と地域規制の力関係、そして消費者保護と持続可能性をめぐる大きなテーマを浮き彫りにしました。

まず、EU 域内では、消費者団体と規制当局の働きかけにより、Microsoft が「無条件・無償」という形で譲歩を余儀なくされました。セキュリティ更新のような不可欠な機能を自社サービス利用と結びつけることは DMA に抵触する可能性があるという論点が、企業戦略を修正させる決定的な要因となりました。これは、規制が実際に消費者に利益をもたらすことを証明する事例と言えます。

一方で、EU 域外の状況は依然として厳しいままです。米国や日本を含む地域では、Microsoft アカウントの利用が必須であり、年額課金モデルも継続しています。EU とその他地域との間に生じた「セキュリティ更新の地域格差」は、ユーザーにとって大きな不公平感を生み出しており、国際的な批判の火種となっています。セキュリティという本質的に公共性の高い要素が地域によって異なる扱いを受けることは、今後も議論を呼ぶでしょう。

さらに、持続可能性の課題も解決されていません。今回の EU 向け措置は 1 年間に限定されており、2026 年 10 月以降の数億台規模の Windows 10 デバイスの行方は依然として不透明です。セキュリティ更新の打ち切りはリファービッシュ市場や中古 PC の寿命を縮め、結果として電子廃棄物の増加につながります。これは EU の「循環型消費」や「持続可能なデジタル製品」という政策目標とも矛盾するため、さらなる延長や新たな仕組みを求める声が今後高まる可能性があります。

今回の件は、Microsoft の戦略、規制当局の影響力、消費者団体の役割が交差する非常に興味深い事例です。そして何より重要なのは、セキュリティ更新は単なるオプションではなく、ユーザーの権利に直結する問題だという認識を社会全体で共有する必要があるという点です。

読者として注視すべきポイントは三つあります。

  • Microsoft が 2026 年以降にどのような対応を打ち出すか。
  • EU 以外の地域で、同様の規制圧力や消費者運動が展開されるか。
  • 企業のサポートポリシーが、環境・社会・規制とどのように折り合いをつけるか。

Windows 10 ESU の行方は、単なる OS サポート延長の問題を超え、グローバルなデジタル社会における企業責任と消費者権利のバランスを象徴する事例として、今後も注視していく必要があるでしょう。

参考文献

Docker DesktopにCritical脆弱性、CVE-2025-9074 ─ macOS・Linuxも含め更新推奨

コンテナ技術は、開発から運用まで幅広い現場で欠かせない存在となっています。その中でも Docker Desktop は、Windows・macOS・Linux などの環境で簡単に Docker を利用できるツールとして、多くの開発者やエンジニアに利用されています。日常的にローカル開発環境を立ち上げたり、テスト用に複数のコンテナを起動したりする用途で広く普及しており、影響範囲は非常に大きいと言えます。

今回報告された脆弱性 CVE-2025-9074 は、そうした日常的に利用される開発環境に潜む重大なリスクです。影響は特定の設定や条件に限定されず、Enhanced Container Isolation(ECI)や「Expose daemon」設定の有無にかかわらず影響を受けることが判明しています。これにより、普段はセキュアだと考えていた環境でも、不正アクセスやコンテナ制御の乗っ取りといった深刻な被害に発展する可能性があります。

特に Windows 環境では、WSL を介したホストドライブへのアクセスが可能になるなど追加的なリスクが確認されていますが、macOS や Linux でも同様にコンテナ間の不正制御が可能になるため、「Windows ユーザーだけが対象」ではなく、すべての Docker Desktop ユーザーが直ちにアップデートすべき事案です。

Docker 側は迅速に修正版をリリースしており、2025年8月20日に公開された Docker Desktop 4.44.3 で本脆弱性が修正されています。本記事では、脆弱性の詳細とリスク、そしてユーザーが取るべき対策について整理します。

脆弱性の概要

今回報告された CVE-2025-9074 は、Docker Desktop 上で稼働する Linux コンテナが、本来アクセスできないはずの Docker Engine API に直接アクセスできてしまうという脆弱性です。Docker Engine API はコンテナのライフサイクル管理やイメージ操作などを行うための強力なインターフェースであり、ここに不正アクセスされると、ユーザーの意図しない操作が可能になってしまいます。

この問題の本質は、Docker Desktop が内部で利用している サブネット経由の通信経路にあります。通常であれば、セキュリティ設定やネットワークの分離によってコンテナからホスト側の管理 API へ直接到達できないように設計されています。しかし、今回の脆弱性では、その設計をすり抜ける形でアクセスが可能となり、結果として以下のようなリスクが生じます。

  • 不正なコンテナ制御: 攻撃者が任意に新しいコンテナを生成したり、既存コンテナを停止・削除したりできる。
  • イメージの操作: ローカルに保存された Docker イメージを削除、改ざん、あるいは外部に流出させる可能性。
  • 設定の改変: 環境構築や開発に利用する設定を不正に変更される危険性。

さらに問題を深刻化させているのは、この挙動が ECI(Enhanced Container Isolation)や「Expose daemon」の設定有無に依存しない という点です。つまり、セキュリティオプションを強化していたとしても、今回の脆弱性を防ぐことはできません。

また、Windows 環境においては、WSL バックエンドを利用している場合、通常は制御できない ホストドライブがユーザー権限でマウントされる リスクが確認されています。これはシステム内のファイルが意図せず外部から参照・改変されることにつながり、開発用 PC の安全性を直接脅かす可能性があります。

一方で macOS や Linux 環境においても、Docker Engine API の権限を奪取されれば同様にコンテナ制御やイメージ操作が行われるため、プラットフォームに依存しない深刻な脅威となっています。

今回の脆弱性は CVSS v4.0 ベーススコア 9.3(Critical) として評価されており、最も高い深刻度レベルに分類されています。この評価は、単なる理論的リスクではなく、現実に悪用された場合の影響が極めて広範囲かつ深刻であることを意味しています。

影響範囲

今回の脆弱性 CVE-2025-9074 は、Docker Desktop を利用しているすべてのユーザーに影響を与える可能性があります。特定の環境や利用方法に限定された問題ではなく、Windows・macOS・Linux のいずれにおいても共通してリスクが存在する点が重要です。

まず Windows 環境については、特に WSL(Windows Subsystem for Linux)をバックエンドとして利用している場合に深刻な追加リスクが指摘されています。WSL 上の Linux コンテナからホストマシンのドライブをユーザー権限でマウントされる可能性があり、これによって開発者が扱うソースコードや機密データが不正に参照・改変される危険性が生じます。これは通常のコンテナ分離モデルでは想定されない挙動であり、ローカル開発環境全体が攻撃者に乗っ取られる可能性を意味します。

一方で macOS や Linux 環境でも安心はできません。Docker Engine API へのアクセスが可能になる点は共通しており、攻撃者がこの API を操作することで、以下のようなリスクが発生します。

  • 不正なコンテナの生成・削除・停止などによる環境の破壊
  • ローカルに保存された Docker イメージの不正利用や流出
  • 開発環境に必要な設定やデータの改変によるサービス停止や混乱

つまり、「Windows 以外の環境では被害が軽い」とは言えず、開発環境に依存するすべてのユーザーが影響を受ける可能性があるのです。Docker Desktop は開発者にとって日常的に利用するツールであり、ローカル環境のコンテナ基盤そのものが脆弱化するという点で、被害の範囲は単一コンテナにとどまらず、開発プロジェクト全体、さらには組織内のリポジトリや CI/CD パイプラインに波及するリスクを孕んでいます。

加えて、今回の脆弱性は ECI(Enhanced Container Isolation)や「Expose daemon」設定の有無に依存せず影響するため、「セキュリティ機能を有効化しているから安全」と考えていたユーザーも例外ではありません。むしろ、多くの利用環境で普段通りにコンテナを実行しているだけで影響を受けるため、利用者全体を巻き込む普遍的な問題と言えます。

結論として、この脆弱性は 「Docker Desktop を利用するすべてのユーザーが対象」であり、特定のプラットフォームや構成に限定されたリスクではありません。そのため、Windows だけでなく macOS や Linux を利用している開発者やエンジニアも例外なく、迅速なアップデート対応が求められます。

対策

今回の脆弱性 CVE-2025-9074 に対しては、Docker 社がすでに修正版を公開しており、Docker Desktop 4.44.3 以降にアップデートすることで解消されます。現地時間 2025 年 8 月 20 日にリリースされたこのバージョンには、脆弱性を突いた不正アクセス経路を封じる修正が含まれており、ユーザー側で追加の設定変更を行う必要はありません。

重要な点は、設定や回避策では問題を防げないということです。ECI(Enhanced Container Isolation)の有効化や「Expose daemon」の無効化など、従来のセキュリティオプションを組み合わせてもこの脆弱性を防ぐことはできません。根本的な対策は Docker Desktop 自体を更新することに尽きます。

アップデート手順

1.現在のバージョンを確認

ターミナルで以下を実行し、Docker Desktop 4.44.3 以上であるかを確認します。

docker version

または、Docker Desktop Dashboardの右下に表示されているバージョンが4.44.3以上になっていることを確認します。

2.最新版の入手

Docker の公式サイト(https://www.docker.com/products/docker-desktop)から最新版をダウンロードします。Docker Desktop Dashboardの通知からでもダウンロード可能です。

3.Docker Desktopのアップデート

  • Windows / macOS: インストーラを実行し、既存の Docker Desktop に上書きインストール。
  • Linux: パッケージマネージャ(例: apt や dnf)を利用して更新、もしくは公式のインストーラを再適用。

4.アップデートの実行

右下がUpdateという表示になっている場合、これをクリックしてアップデートを行ってください。Software Updateページが表示されるので、更新を実施してください。

5.アップデート後の確認

  • 再度 docker version を実行し、クライアント・サーバともに 4.44.3 以上であることを確認。
  • 念のため、既存のコンテナが正常に動作するかテスト。

運用上の留意点

  • 全環境での更新を徹底: 個人開発環境だけでなく、チームメンバーや CI/CD 用のビルド環境など、Docker Desktop を利用しているすべての端末で更新が必要です。
  • 旧バージョンの利用を避ける: 脆弱性が公開されているため、旧バージョンを使い続けると攻撃者に狙われやすくなります。
  • 定期的なバージョンチェック: Docker Desktop は短いリリースサイクルで更新されるため、今回の件を機に定期的にバージョン確認を行い、常に最新を維持する運用を推奨します。
  • CI/CD パイプラインの確認: ビルド環境やテスト環境で Docker Desktop を利用している場合、更新漏れがあるとチーム全体のリスクにつながるため、パイプラインの実行ホストも忘れずに更新してください。

結論として、唯一の有効な対策は速やかなアップデートです。Windows 環境だけでなく macOS・Linux を含むすべての開発環境で Docker Desktop を利用しているユーザーは、今すぐバージョン確認を行い、必要に応じて更新を実施することが強く推奨されます。

おわりに

今回明らかになった CVE-2025-9074 は、Docker Desktop の根幹である Docker Engine API へのアクセス制御に関わる重大な脆弱性であり、影響範囲は Windows・macOS・Linux を含むすべての利用者に及びます。特定の環境に限定された問題ではなく、普段の開発作業やテスト環境、さらには CI/CD パイプラインにまで影響する可能性がある点が非常に危険です。

特に Windows 環境では WSL を介したホストドライブへのアクセスが可能になるなど追加的なリスクがありますが、これはあくまで一部の強調事例であり、macOS や Linux 環境でも Docker Engine API を乗っ取られることで同等の深刻な被害が生じ得ます。したがって、「Windows 以外は安全」と考えるのは誤りです。開発者がどの OS を利用していようと、この脆弱性を軽視すべきではありません。

Docker 社は迅速に修正版を提供しており、2025 年 8 月 20 日公開の Docker Desktop 4.44.3 で問題は解消されています。今回の事例から学べる重要な教訓は、脆弱性対策は「設定や部分的な防御策では不十分」であり、ソフトウェアを常に最新の状態に保つことこそが最も確実な防御策であるという点です。

また、個人開発者だけでなく、組織として Docker Desktop を利用している場合は、全メンバーの環境を一斉に更新する体制が不可欠です。ひとりでも古いバージョンを使い続ければ、その環境が攻撃者に狙われ、結果的にプロジェクト全体のセキュリティを損なう恐れがあります。特にクラウド連携やソースコード管理リポジトリと接続している開発環境では、被害が企業全体に波及する可能性すらあります。

さらに、今回の脆弱性に限らず、日常的なセキュリティ対策として 安全性が確認されていない不明なコンテナイメージを軽率に起動しない ことも重要です。公式リポジトリや信頼できる配布元以外から入手したコンテナには、脆弱性を悪用するコードやマルウェアが含まれる可能性があります。OS やツールを最新化することと同様に、利用するコンテナの信頼性を確認することも忘れてはなりません。

結論として、今すぐ Docker Desktop のバージョンを確認し、4.44.3 以上に更新することが最優先の対応です。加えて、怪しいコンテナを不用意に起動せず、信頼できるソースのみを利用することが、Docker 環境全体の安全を守るうえで不可欠な行動となります。

参考文献

IntelliJ IDEAで次の出現箇所を選択する

Visual Studio Codeでの❖+D/⌘+Dのような現在選択しているテキストと同じテキストが出現する次の箇所を選択するショートカットは、IntelliJ IDEAにも存在します。

ただ、WindowsとmacOSでショートカットが異なるので両方を使用している方は注意が必要です。

Windowsの場合

WindowsのIntelliJ IDEAでは、Alt+Jで現在選択しているテキストと同じテキストが次に出現する箇所を選択することができます。

macOSの場合

macOSのIntelliJ IDEAでは、^+Gで現在選択しているテキストと同じテキストが次に出現する箇所を選択することができます。

Linuxの場合

最近では開発用マシンとして使用している人もいるので、ちょっと調べてみました。Ubuntu 24.04 ARM64で動作確認を行っていますが、他のディストロやCPUでも変わらないかと思います。

結論からいうと、Windowsと同じAlt+Jで同様の操作ができました。macOSだけが異なるショートカットになっているため、こちらについても意識しておいた方がよいでしょう。

まとめ

Visual Studio Codeとは異なり、IntelliJ IDEAをはじめとするJetBrainsの製品はWindowおよびLinuxとmacOSでショートカットが異なります。これはCtrlキーとcommandキーの違いというような差異ではなく、使用するアルファベット自体が異なっている(まったくの別ショートカットとなっている)点に注意が必要です。

特に、私のようにプライベートと仕事で使用OSが異なる人は混乱しやすいと思いますので、OSを揃えるようにするなど何かしらの対策をしておいた方がよいかもしれません。

Linuxコマンドの代替・上位互換コマンドを使ってみよう – z, eza, fd, rg, bat, tldr

Linuxコマンドの代替コマンド、上位互換コマンドを紹介する動画を見ていて、知らないコマンドばかりだったので、実際に使ってみました。

コマンド自体はすべてmacOSでインストールして試しています。公式サイトのURLを付けていますので、その他のプラットフォームの場合は公式サイトご確認ください。

z – cdの代替コマンド

zcdの代替コマンドです。cdコマンドと比べて移動に関する操作が強化されています。

インストール方法

macOSへインストールするにはHomebrewを使用します。

brew install zoxide

インストール後、~/.zshrcに以下を追記し、シェルを再起動します。

eval "$(zoxide init zsh)"

使用方法

コマンドが違うだけで基本的にはcdコマンドと同じように使用できます。ただ、前にいたディレクトリへの復帰の方法がとても強力です。

$ z foo
$ mkdir -p bar/baz
$ mkdir -p abc/def
# foo/bar/bazディレクトリに移動する
$ z bar/baz
# 直前にいたfooディレクトリに戻る
$ z -
# 移動したことのあるbazディレクトリに直接移動する
$ z baz
$ z -
$ z abc/def
# 移動したことがあるなら直前にいたディレクトリでなくても移動可能
$ z baz
$ z def

2つ以上のディレクトリを行き来するときとかは重宝しそうです。

eza – lsの代替コマンド

ezaはexaからフォークしたコマンドで、現在はこちらがメンテナンスされているようです。

ezalsの代替コマンドです。lsコマンドよりも高い可読性の表示が簡単にできるのが特徴です。

インストール方法

macOSへインストールするにはHomebrewを使用します。

brew install eza

使用方法

eza

eza -l

色つきや下線がついた見やすい表示になります。

fd – findの代替コマンド

fdfindの代替コマンドです。特定の文字列を含むファイル名やディレクトリ名を簡単に探すことができます。

インストール方法

macOSへインストールするにはHomebrewを使用します。

brew install fd

使用方法

複雑なオプションを使わずにファイルやディレクトリを検索できます。

# fooを含むファイル名、ディレクトリ名を現在のディレクトリから再帰的に検索する
$ fd foo
# ファイルのみを検索したいとき
$ fd --type f foo
# ディレクトリのみ検索したい場合
$ fd --type d foo
# fooを含むファイル名、ディレクトリ名をディレクトリbarを基点に再帰的に検索する
$ fd foo bar

findコマンドはオプションを色々覚えないといけないですし、環境やバージョンによってオプションが異なることがあるため、毎回調べる手間を大幅に削減できるのがうれしいですね。

rg – grepの代替コマンド

rggrepの代替コマンドです。ファイルの中に文字列をGrepすることに特化したコマンドで、サクラエディタのGrep機能をコマンド化したような使い心地です。

インストール方法

macOSへインストールするにはHomebrewを使用します。

brew install ripgrep

使用方法

オプションおよびコマンドの組み合わせなしでファイルの中身のGrepができます。

# 現在ディレクトリを基点に再帰的に'foo'が含まれる行を検索する
$ rg foo
# オプションなしで正規表現が使用可能
$ rg 'ba[rz]'
# 検索する基点となるディレクトリを指定可能(barディレクトリを基点に検索)
$ rg foo bar
# 拡張子を絞って検索することも可能
$ rg foo -g '*.css'

bat – catの代替コマンド

batcatの代替コマンドです。catコマンドよりも高機能かつ見やすい表示にしてくれます。

インストール方法

macOSへインストールするにはHomebrewを使用します。

brew install bat

使用方法

catと同じでファイル名を指定してファイルの中身を表示できるのは同じですが、moreコマンドなどと組み合わせる必要がなく、色も付けてくれるのでかなり見やすくなります。

tldr – manの補完コマンド

こちらは代替コマンドというよりは補完するコマンドだと言えます。tldrコマンドで調べて、それでも不足している場合はmanコマンドで調べるという使い方がよさそうです。

インストール方法

macOSへインストールするにはHomebrewを使用します。かつてはtldrという名前でインストールできていたようですが、現在はtlrcという名前でインストールします。

brew install tlrc

使用方法

manコマンドと同じようにコマンド名を引数にします。

すっきりとした見た目なので非常にわかりやすいですね。さっと調べたい場合はtldrコマンドで調べて、もっと詳しくいろいろなオプションを調べたい場合はmanコマンドを使うようにするとよいと思います。

コマンドの使い方を調べるコマンドは他にもあるので簡単に紹介します。

cheat

tldrと似ていますが、チートシートをローカルにダウンロードして、それを編集して自分で育てることができます。

$ brew install cheat
# コマンドを始めて調べるときはコミュニティ提供のチートシートをダウンロードできる
$ cheat sort
A config file was not found. Would you like to create one now? [Y/n]: y
Would you like to download the community cheatsheets? [Y/n]: y
Cloning community cheatsheets to /Users/t0k0sh1/.config/cheat/cheatsheets/community.
Enumerating objects: 335, done.
Counting objects: 100% (335/335), done.
Compressing objects: 100% (310/310), done.
Total 335 (delta 43), reused 213 (delta 23), pack-reused 0
Cloning personal cheatsheets to /Users/t0k0sh1/.config/cheat/cheatsheets/personal.
Created config file: /Users/t0k0sh1/.config/cheat/conf.yml
Please read this file for advanced configuration information.
# 以降はチートシートを表示する
# To sort a file:
sort <file>

# To sort a file by keeping only unique:
sort -u <file>

# To sort a file and reverse the result:
sort -r <file>

# To sort a file randomly:
sort -R <file>

# To sort a file and store the output in another file:
sort <inputFile> -o <outputFile>

# Sort by default uses /var/tmp to store temp files but size of /var/tmp directory is limited. In order to sort huge use a directory with adequate size:
sort -T <tempDirectory> <file>
# 一度ローカルに保存したチートシートは編集できる
$ cheat -e sort

howdoi

プログラマ向けのQ&Aサイトから回答を調べて表示するコマンドです。

$ brew install howdoi
# JavaのStream APIでsortをするときの書き方を調べるにはキーワードを並べる
$ howdoi java stream sort
List result = list.stream().sorted((o1, o2)->o1.getItem().getValue().
                                   compareTo(o2.getItem().getValue())).
                                   collect(Collectors.toList());

まとめ

個人的にはfd、rgコマンドはこれからも使っていきたいと思いました。もちろん、シェルスクリプトではfindコマンドやgrepコマンドはこれからも使うと思います。

伝統的なコマンドを使いこなすことも重要ですが、使いにくいと思うコマンドを別のコマンドに置き換えてより効率的に作業をこなすのも重要なことだと思いますので、積極的に試していきたいと思います。

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