📊 3行サマリー

  • Adobe Creative CloudがWindows・macOSのhostsファイルに、IP「166.117.29.222」「detect-ccd.creativecloud.adobe.com」のマッピングを3行無断挿入していたことが2026年3月中旬にRedditで発覚。
  • 目的はChromeの「Local Network Access」規制で使えなくなった「localhost検出」の代替——Webサイト側からCC導入有無を判定するための分析用トラッキング
  • 発覚から約3週間が経過した4月22日時点でもAdobeは公式声明を出さず、John Gruberら開発者・セキュリティ研究者の批判が激化。日本のIT管理者からも「EDR誤検知・マルウェア級の手口」との警戒が広がる。

📰 Adobe Creative Cloud、hostsファイルに「WAM」タグ付きで3行を無断挿入

Adobe Creative Cloud(CC)デスクトップアプリが、ユーザーに無断でWindows・macOSのhostsファイルを書き換えていたことが、2026年3月中旬にRedditを通じて明るみに出た。追加されていたのは# Adobe Creative Cloud WAM – Startおよび# Adobe Creative Cloud WAM – Endというコメントマーカーで挟まれた3行で、IPアドレス166.117.29.222detect-ccd.creativecloud.adobe.comというAdobeのサブドメインにマップする内容だった。hostsファイルはDNSより優先される通信経路の要であり、改変には管理者権限が必要なシステム領域である。そこを第三者アプリが一方的に書き換え、削除してもCCの再起動で復元されるという事実が、技術者コミュニティを震撼させた。

📖 OSnews・PC Watch報道:発端は2026年3月中旬のReddit投稿

元ネタAdobe CCがhostsファイルを無断で変更か。批判の声相次ぐ(PC Watch / 2026年4月2日)

Adobe Creative Cloudユーザーを中心に、自身のPCのhostsファイルがAdobeによって勝手に改変されたとの報告が相次ぎ、ユーザーの間で物議を醸している。

PC WatchはReddit発の投稿を受けて4月2日に国内メディアとして最初に報道。同日Yahoo!リアルタイム検索でも「hosts書き換え」が話題語として浮上した。英語圏ではOSnewsが4月5日に詳報し、Michael Tsaiのブログ(4月8日)でDaring FireballのJohn Gruberら著名ブロガーが批判コメントを寄せた。報告自体は正規ライセンス利用者から上がっており、海賊版対策という従来の文脈では説明がつかない挙動だった。

🔍 Chromeの「Local Network Access」規制を迂回するためのhosts書き換え

Adobeはなぜこの手段を選んだのか——技術的背景は単純だ。従来、Webページ側でCC導入状況を検出するためにhttp://localhost:{各種ポート}/cc.pngという小さな画像を呼び出していたが、Chromeが実装した「Local Network Access」制限で2026年以降この手法が遮断された。そこでAdobeは、adobe.com/home訪問時にJavaScriptがhttps://detect-ccd.creativecloud.adobe.com/cc.pngを読みに行き、hostsファイルに仕込んだ特定IPで応答が返るかどうかで導入状況を判定する仕組みに切り替えた。つまりhostsファイル改変はWebアプリと既存CC導入の連携、より正確には分析・トラッキング用のシグナル確保が目的である。ブラウザ側セキュリティ強化に対し、システムファイル直接改変で迂回するという判断が、批判の核心だ。

🔇 Adobeは1カ月経っても公式声明なし——沈黙が批判を増幅

発覚から約3週間、本記事執筆時点の2026年4月22日現在もAdobeは公式な説明文・謝罪・仕様変更告知のいずれも出していない。Adobeコミュニティフォーラムには「Why are you guys doing this?」と題されたスレッドが立ち、数百件のコメントが集まっているが、Adobe Employeeバッジを持つ担当者からの実質的な回答は投稿されていない。皮肉なのは、Adobe自身のヘルプドキュメント「Reset hosts file to resolve connectivity issues」が、ライセンス不具合時にはユーザー側でhosts記述を削除しろと案内している点だ。つまり「勝手に追加した行を、不具合時にはユーザーが手動で削除すべき」という構造矛盾が発覚し、PR上の沈黙が「隠蔽を意図したのでは」との疑念を生む悪循環に陥っている。

🌍 John Gruber「他の全ソフトも同じことをしたらどうなる」——海外の論調

Daring FireballのJohn Gruberはブログで次のように指摘した。「Adobeは数ある第三者開発者の一つに過ぎない——他のどの開発者より優れているわけでも、信頼されているわけでも、重要なわけでもない。想像してほしい、もしコンピュータ上のあらゆるソフトが同じように/etc/hostsにエントリを追加し始めたら。狂気だ。」OSnewsのThom Holwerdaはさらに踏み込み、2005年のSony BMG ルートキット事件と並置した。当時Sonyは音楽CD再生時にユーザー同意なくPCへルートキットを仕掛け、最終的に集団訴訟とFTCによる和解金に発展した。Sonyと同じく「正規ビジネスがマルウェア的手法を採った」という構図が、今回のAdobe批判の強度を決めている。あるセキュリティ研究者はhostsファイル内にAdobe関連ドメインが約900件存在するケースを報告しており、これが単発の実験ではなく組織的な追跡網の一部である可能性も指摘されている。

🇯🇵 日本のIT管理者からも「EDR誤検知・マルウェア級」と警戒の声

日本でもPC Watch・ソフトアンテナ・すまほん!!等の技術系メディアが相次いで報道し、X(旧Twitter)では「ここに勝手に書くのはEVILすぎるだろ」「管理者権限が必要なシステムファイルをユーザー同意なく変更するのはマルウェアと同じ手口」といった強い批判が拡散した。日本企業にとって影響は軽くない。hostsファイル改変は、多くの企業が導入するEDR(Endpoint Detection and Response)・SIEMで「マルウェア挙動」として自動アラート発報の対象だからだ。デザイン・広告・出版業界はAdobe CC大量導入先の代表格であり、正規ライセンスであっても社内セキュリティ運用上のホワイトリスト追加や誤検知対応が新たに必要になる。Adobeが商業ユースで払うべき信頼コストは、単なるユーザー感情の問題ではなく、企業IT部門の実務負担として既に顕在化している。

🏁 第三者アプリが改変していいシステム領域はどこまでか

今回の騒動は単なる「Adobeの不手際」では終わらない。ブラウザ側セキュリティ(Local Network Access規制)が閉じた窓を、アプリ側がシステムファイル改変で開け直すという「規制と迂回のいたちごっこ」が、正規ソフトウェアの世界にも持ち込まれたことを意味する。もしAdobeのこの手法が批判を浴びずに定着すれば、MicrosoftもGoogleもAppleも、そしてあらゆるSaaSベンダーが同じ手段を取り得る。Adobeの沈黙が長引くほど、この「業界標準化」の既成事実が積み上がる。ユーザーが取れる当面の対抗策は、hostsファイルを読み取り専用属性に変更する、CCデスクトップアプリをアンインストールする、あるいは企業環境ではEDRポリシーで当該IPを監視対象に加える、という自衛措置に限られる。問われているのは「第三者アプリが改変していいシステム領域の境界線」であり、Adobeの公式説明が出ない限り、この論争は鎮静化しない。