Windows更新プログラムKB5063878が引き起こすUAC問題 ― MSIインストールや修復に影響

Windowsの更新プログラムは、セキュリティの向上や不具合修正、機能改善のために定期的に配信されています。しかしながら、これらの更新が新たな問題を引き起こすことも少なくありません。2025年8月に配布された「KB5063878」はその典型例であり、ユーザーアカウント制御(UAC)に関連する挙動に変化をもたらし、予期しない副作用を発生させました。

この更新は、本来であればシステムの脆弱性を修正し、利用者の安全性を高めることを目的としていました。特にCVE番号が割り当てられたセキュリティ問題への対応として導入されたものです。しかし結果として、標準ユーザーがMSIインストーラーを利用してアプリケーションをインストールしたり修復したりする際に、これまで想定されていなかった管理者権限の要求やエラーが発生する事態につながっています。

セキュリティと利便性のバランスは常に難しい課題ですが、今回の事例は「安全性を強化するための修正」が「正規利用者の業務や利用シナリオを妨げるリスク」を露呈した形といえるでしょう。本記事では、この問題の背景や技術的な原因、具体的な影響範囲、そしてマイクロソフトの今後の対応について整理していきます。

不具合の概要

KB5063878 を適用したシステムでは、これまで問題なく実行できていた 標準ユーザー権限での MSI インストールや修復操作 に異常が発生しています。具体的には、アプリケーションのセットアップや修復を行う際に、通常では表示されない ユーザーアカウント制御(UAC)の管理者資格情報プロンプト が出現するケースが多発しています。

従来の挙動では、標準ユーザーでも MSI インストーラーを利用して一部のアプリケーションを修復できましたが、今回の更新後はその操作が中断され、管理者権限を求められるようになっています。場合によっては、資格情報を入力しても処理が正しく進行せず、エラーコード「1730」 を伴って修復が失敗する事例が報告されています。

影響は一部の古いソフトウェアに顕著で、例えば Office Professional Plus 2010 では、標準ユーザーで修復を実行しようとすると確実にエラーが発生し、作業が進まないという報告が複数挙がっています。新しいアプリケーションであっても、インストーラーが MSI を利用している場合には同様の事象に直面する可能性があります。

問題の特性上、管理者アカウントを利用すれば回避できるケースもありますが、組織全体で標準ユーザー権限による運用を徹底している環境(セキュリティポリシーが厳格な企業や教育機関など)では、ソフトウェアのメンテナンス作業そのものが困難になるという深刻な影響を及ぼしています。

技術的背景

今回の不具合の根本には、Windows Installer(MSI) に存在していた脆弱性への対応があります。マイクロソフトは 2025年8月のセキュリティ更新プログラムの一環として、CVE-2025-50173 に指定された「Windows Installer における特権昇格の脆弱性」を修正しました。この脆弱性は、攻撃者が通常は許可されていない操作を標準ユーザー権限で実行できる可能性を持っており、悪用されればマルウェアの導入や権限昇格につながる重大なリスクを孕んでいました。

これに対処するため、KB5063878 では Windows Installer の権限チェックの仕組みが変更され、これまで曖昧に処理されていた一部の動作がより厳格に制御されるようになりました。特に、MSI インストーラーを利用した「修復操作」や「再インストール」に関しては、標準ユーザーが直接実行できないよう制限が強化され、管理者権限の確認を必ず要求するようになったのです。

セキュリティ的には正しい方向性ですが、この変更はアプリケーションの設計や利用環境における既存の前提条件を崩すことになりました。長年利用されてきたソフトウェアの中には、標準ユーザーでの MSI 修復を想定して動作しているものが少なくなく、こうしたアプリでは正常に動作できず、結果としてユーザーにとって「不具合」として認識される状態が発生しました。

加えて、この挙動変更はシステム内部でのセキュリティ強化に伴う副作用であるため、単純に設定を切り替えたり回避策を講じたりすることが難しいのも特徴です。レジストリやポリシーで回避できる設定は提供されておらず、現状では 管理者権限を利用してインストールや修復を行うしかない という状況に陥っています。

このように、セキュリティ修正と利便性の衝突が表面化したことで、Microsoft は今後のアップデートで「特定の正規アプリケーションが不要に UAC プロンプトを発生させないよう改善する」方針を示しており、技術的には既存の権限モデルを維持しつつ例外処理を加える形で対応するものと考えられます。

影響範囲と事例

今回のUAC関連不具合は、Windows 11、Windows 10、さらに Windows Server 系列 を含む幅広いバージョンに影響しています。特定のエディションや構成に限定された問題ではなく、KB5063878 を適用したシステム全般で確認されているため、利用環境を問わず発生し得る点が特徴です。

具体的な影響は以下の通りです。

  • 標準ユーザー権限でのインストールや修復の失敗 MSIベースのアプリケーションを標準ユーザーで修復しようとした場合、必ず管理者資格情報を求められ、処理が中断される。 これにより、従来はヘルプデスクやサポート担当者を介さずにユーザー自身で行えていた軽微な修復作業ができなくなる。
  • エラーコードの発生(Error 1730) 特定のアプリでは、資格情報入力後も処理が進まず、「このインストールを完了するには管理者権限が必要です」といった趣旨のエラーを伴う Error 1730 が表示される。特に Office Professional Plus 2010 で顕著に確認されている。
  • 古いソフトウェアにおける互換性問題 長期間サポートが終了しているレガシーアプリケーションほど影響を受けやすい。こうしたアプリは標準ユーザーでの修復を前提に設計されていることが多く、企業内での業務継続に支障をきたす。
  • 組織運用への影響 大規模な組織では、セキュリティポリシーとしてユーザーを原則標準権限に制限している場合が多い。そのため、アプリ修復が都度ヘルプデスクや管理者権限の付与を必要とし、運用コストやサポート工数の増大 につながる。教育機関や公共機関などでも同様の課題が発生し得る。

一方で、管理者アカウントを利用している個人ユーザーや小規模環境では、日常利用における影響は比較的小さいとみられます。しかし、業務システムや多数のユーザー端末を抱える組織環境では、軽微なソフト修復が全社的な業務停止リスクに直結する 可能性があるため、影響は重大です。

マイクロソフトの対応と今後の見通し

マイクロソフトは、KB5063878 適用後に報告された UAC 関連の不具合を正式に認識し、問題の存在をサポートページやセキュリティ関連情報で公表しています。特に「アプリの修復やインストールが予期せず失敗する」「不要な UAC プロンプトが表示される」といった事象は再現性が高く、単なる一部環境の特殊事例ではないことが確認されています。

現時点で Microsoft は、この挙動を「セキュリティ強化による副作用」と位置づけており、セキュリティ修正そのものを撤回するのではなく、正規の利用シナリオを阻害しない形で調整を行う修正プログラムを今後配信する方針 を示しています。具体的には、以下のような対応が検討されていると見られます。

  • 不要な UAC プロンプトの抑制 信頼されたアプリケーションが標準ユーザーで実行する正規の MSI 修復操作については、従来通り完了できるように例外処理を加える。
  • セキュリティと互換性の両立 脆弱性(CVE-2025-50173)の悪用を防止しつつ、既存アプリケーションの互換性を維持するバランスをとる。これにより、セキュリティリスクを再度解放することなくユーザー体験を回復する。
  • 今後のアップデートで段階的に反映 パッチは月例の累積更新プログラム、または追加の緊急修正(Out-of-band Update)として配布される可能性がある。特に企業環境での影響が大きいため、優先度は高いと考えられる。

一方、修正が提供されるまでの間、Microsoft は暫定的な回避策として「影響を受ける操作を管理者権限で実行する」以外に公式な手段を提示していません。これは、セキュリティ修正を緩和するような設定変更が推奨されないためです。そのため、ユーザーや管理者は以下のような運用上の工夫を余儀なくされています。

  • 標準ユーザー環境での修復作業を一時的に制限する
  • 管理者アカウントでの代替作業をサポート窓口が担う
  • 必要であれば更新適用を延期し、修正版のリリースを待つ

マイクロソフトの対応速度や修正版の品質は今後注目される点です。セキュリティ修正が業務システムの利用に直接的な悪影響を及ぼすことは企業にとって大きなリスクであり、今回のケースは「セキュリティ優先の変更」と「ユーザー利便性」のバランスの難しさを象徴する事例といえるでしょう。

おわりに

KB5063878 による UAC 関連不具合は、セキュリティ更新がもたらす副作用の典型例といえます。本来は Windows Installer の脆弱性を塞ぐという正当な目的で導入された変更が、結果として標準ユーザーによるアプリケーションの修復やインストールといった正規の操作を阻害する事態につながりました。セキュリティ強化が必須である一方で、利便性や業務継続性との両立がいかに難しいかを改めて示しています。

特に企業や教育機関のように標準ユーザー権限での運用を前提としている組織では、この問題は単なる「一部の不具合」では済まされません。アプリ修復のたびにヘルプデスクへの依頼や管理者権限の一時付与が必要となれば、運用コストや対応工数は大幅に増加し、システム全体の効率性を下げることになります。現場のユーザーにとっては、日常的な作業が中断される不便さが直接的な負担となるでしょう。

マイクロソフトは今後の更新で修正を行うとしていますが、配布時期や具体的な改善内容はまだ明らかになっていません。そのため、利用者や管理者は暫定的な回避策を講じつつ、修正版の提供を待つほかありません。今回の件は、更新プログラムの導入にあたって「セキュリティリスクを減らすメリット」と「既存環境への影響リスク」を天秤にかけながら慎重に判断する必要性を再認識させる出来事でもあります。

最終的には、こうした問題に直面した際に備えて バックアップの徹底影響調査の迅速化情報共有の体制整備 を行っておくことが、個人ユーザーにも組織にも求められます。セキュリティ更新は不可欠ですが、その適用と運用の両面でリスクを管理することこそが、安定したシステム利用の鍵になるといえるでしょう。

参考文献

マイクロソフト「Windows 2030 Vision」──AIエージェント時代に向けた大胆な構想

マイクロソフトが発表した「Windows 2030 Vision」は、単なる新機能の紹介ではなく、今後10年におけるコンピューティングの方向性を示す「未来宣言」に近い内容です。発表者であるデイビッド・ウェストン氏(Dwizzleとしても知られる)は、Windowsのセキュリティ戦略を長年牽引してきた人物であり、今回のビジョンは同氏の知見を凝縮したものと言えます。

この発表の特徴は、従来の「OSに何が追加されるか」ではなく、「OSそのものの役割がどう変化するか」に焦点を当てている点です。特にAIエージェントが人間の作業を肩代わりする未来像、マウスやキーボードといった従来の入力デバイスからの脱却、そして量子時代を見据えたセキュリティ再設計など、構想は非常に広範で大胆です。

また、このビジョンは単に技術的側面に留まらず、働き方や人間の時間の使い方そのものにまで踏み込んでいます。AIが「苦役作業」を肩代わりすることで人間はより創造的な活動に集中できるようになる、という主張は、単なるOSの進化ではなく「仕事と生活の質の変革」を伴うものです。

一方で、このような長期的構想には必ず実現可能性や現実の制約とのギャップが存在します。本記事では、動画内容の要点を整理するとともに、外部評価や報道の視点、さらに現時点で感じられる現実的な課題や疑問点についても検討していきます。

主要テーマ

1. AIエージェントによる仕事の変革

ウェストン氏が最も強調しているのは、AIエージェントが日常業務の主役に躍り出る未来像です。これまでAIはツールや補助的な存在として位置付けられてきましたが、2030年のWindowsでは、AIは人間と同じ「同僚」として扱われることを想定しています。たとえば、セキュリティ専門家の役割を担うAIを雇用し、Teamsで会話し、会議に出席し、メールのやり取りやタスクの割り当てまで実行するというシナリオが描かれています。

この変化により、現在「苦役作業(toil work)」と呼ばれている反復的・単純なタスクはAIが処理するようになり、人間は創造的活動や意思決定といった、より高次の業務に集中できるようになります。AIが業務の30〜40%を肩代わりすることで、企業や個人が年間を通して膨大な時間を取り戻す可能性があるとされています。これは単なる効率化ではなく、人間の働き方そのものを再構築する試みといえます。

2. マルチモーダルなインターフェース

次に示されたのは、人間とコンピューターのインタラクションが根本的に変わる未来像です。ウェストン氏は「マウスやキーボードの世界は、Gen ZにとってDOSを使うような感覚になる」と述べ、従来の入力デバイスが過去の遺物になる可能性を指摘しました。

代わりに重視されるのが「マルチモーダル」なアプローチです。コンピューターはユーザーの視覚や聴覚を理解し、ユーザーは自然言語で命令を伝える。さらにジェスチャーや視線追跡、音声トーンなど、五感を利用した直感的なやり取りが標準化されると予想されています。こうしたインターフェースは「より自然なコミュニケーション」をコンピューターとの間に成立させ、PCの利用体験を大きく変化させるとされています。

3. セキュリティの根本的再設計

セキュリティ面でも大胆な方向転換が提示されました。ウェストン氏は、ユーザーが求めるのは「アプライアンスレベルのセキュリティ」だと指摘します。これは、食洗機のように「ボタンを押せば常に安全に動作し、余計な拡張性を持たない仕組み」に近いもので、セキュリティをユーザーが意識せず利用できることを目指しています。

さらに、AIによってセキュリティチームを仮想的に構築できるようになるため、中小企業でも高度な防御体制を持てるようになります。量子コンピューティングの脅威に備えて、Windowsには既にポスト量子暗号の実装が進められており、ユーザーに対しても量子耐性技術の有効化を促しています。

また、脆弱性の大半を占めるバッファオーバーランやメモリ破損を根絶するため、メモリ安全性の確保を最優先課題と位置付けています。これにより、セキュリティパッチに費やされる膨大な時間を削減できるとしています。さらにディープフェイクや情報改ざんに対応するため、コンテンツの真正性を保証する「プロベナンス基準」の導入も進められています。

4. Windowsレジリエンスと継続的改善

「Windows Resiliency Initiative」と呼ばれる取り組みも紹介されました。これは、システム障害が発生しても技術者が現場に出向かず、リモートで復旧を完結できる仕組みを構築するものです。これにより、世界中のユーザーが均一に迅速なサポートを受けられるようになります。

また、パートナーとの連携を強化し、ベストプラクティスや最新技術を共有することで、Windowsエコシステム全体の耐障害性を高める方針も示されました。

ただしウェストン氏は「セキュリティの基本は20年間変わっていない」とも指摘し、パッチ適用やパスワード管理といった基本動作が依然として重要であり、これらをAIや最新技術で効率化することが「勝ち続けるための戦略」であると強調しています。

外部評価・報道の視点

今回の「Windows 2030 Vision」は、メディアや専門家の間でも大きな議論を呼んでいます。発表内容は未来志向である一方、実現可能性やユーザー体験とのギャップが多方面から指摘されています。

まず Windows Central は、今回のビジョンを「OSそのものの再定義」と位置付けています。特にAIエージェントをOSの中心に据えるという方向性は、従来のアプリケーション主導型の発想を超え、OSが一種の“AIプラットフォーム”へと進化する可能性を示唆していると解説しています。その一方で、ユーザーインターフェースやセキュリティ基盤の刷新には大規模な技術的課題が残されているとも指摘しました。

TechRadar は、人間とコンピューターの対話がより自然なものになるというアイデアを肯定的に捉えています。特に「コンピューターが人間の視覚や聴覚を理解する」という構想は、現行のCopilotや音声アシスタントの延長線上にある進化として期待できると述べています。ただし、現実にはユーザーが従来の入力デバイスを完全に放棄するには抵抗が大きく、文化的な摩擦や習慣の変化が最大のハードルになるだろうと強調しています。

PC Gamer はさらに懐疑的な視点を示しています。マウスやキーボードを「過去の遺物」と見なす発言については大胆だが現実離れしていると評価。特にキーボードは生産性を維持する上で依然として不可欠なデバイスであり、クリエイティブ作業や開発分野での利用を考えれば、短期的には置き換えは不可能に近いと分析しています。また、セキュリティに関しても「Windows Updateですら安定性に課題を抱える現状を踏まえると、2030年の理想像は相当に高いハードル」と指摘しました。

一方、Times of IndiaEconomic Times といった一般メディアは、この発表を「Windowsの未来像を描く一連のビデオシリーズの第一弾」として紹介しています。報道では特に「agentic AI」というキーワードが強調されており、単なるOSの進化ではなく、AIが主体的に行動するエージェントとして統合される未来を長期戦略の一環として捉えています。

総じて、外部評価は「構想としては魅力的だが、実用性や移行プロセスには疑問が残る」という二極的な見方に分かれています。AI中心の未来像を描いた点は評価されつつも、既存ユーザーが直面するUI変革の負担、セキュリティにおける未解決の課題、そして市場や業界の反応をどう吸収するかが鍵になると報じられています。

個人的な考察

今回の「Windows 2030 Vision」は未来像として魅力的ではありますが、現実とのギャップをどう埋めるかが最大の課題だと感じます。以下に、自分なりの観点を整理します。

1. OSの変革要因とキラーアプリの存在

OSのあり方を決定づけるのは、必ずしも企業のロードマップだけではありません。過去を振り返ると、Windows 95 のGUI普及にはOfficeやインターネット接続環境の広がりが寄与し、スマートフォンの進化もiPhoneとApp Storeという「キラーアプリ的な存在」によって加速しました。したがって、2030年のWindowsがどうなっているかは、Microsoftの戦略に加えて、まだ存在しない新しいキラーアプリやデバイスが現れるかどうかに強く依存すると考えます。

2. 入力デバイスの未来:マウスとキーボード

ウェストン氏はキーボードやマウスが時代遅れになると予測していますが、自分は懐疑的です。特にキーボードは、プログラミングや文章作成といった「最高効率を求められる作業」において依然として無敵の存在です。音声やジェスチャーは便利な一方で、精度やスピード、プライバシーの観点からすべてを置き換えることは難しいでしょう。おそらく未来は「キーボードを中心にしつつ、音声や視線、タッチなどを補助的に併用するハイブリッドモデル」に落ち着くと考えます。

3. メモリ安全性とRustカーネルの実装

セキュリティ脆弱性の70%以上がメモリ安全性の欠如に起因することは事実であり、Rustなどのメモリ安全言語でカーネルを再実装する計画は理にかなっています。しかし、OSカーネルは膨大なコードベースと互換性要件を抱えており、完全移行には10年以上の時間と大規模な投資が必要です。Rustカーネルは方向性として正しいものの、実際には段階的な部分置き換えやハイブリッド運用になる可能性が高いと見ています。その進捗がどの程度のスピードで進むかが、Windowsのセキュリティ強化の実効性を左右するでしょう。

4. セキュリティの現実的課題

理想的なセキュリティ像が提示されていますが、現実はむしろ逆方向に揺れています。特に最近のWindows Updateは、適用後に致命的な不具合を引き起こす事例が後を絶ちません。理想像として「アプライアンスレベルのセキュリティ」を掲げるのは理解できますが、まずはアップデート適用がユーザーに不安を与えないレベルの安定性を確保することが急務だと感じます。構想を前進させる前に、足元の信頼性を固めるべきでしょう。

5. CopilotとAIエージェントの未来像

現在の流れを見る限り、CopilotがOSに深く統合されていくことは間違いないでしょう。しかし、将来的にはユーザーが「AIエージェントを自由に選ぶ時代」が到来する可能性があります。ブラウザ市場のように、Microsoft製、Google製、オープンソース製など複数のエージェントが競争する構図も十分あり得ます。さらに、将来はLLM(大規模言語モデル)とはまったく異なる技術が台頭し、AIエージェントのあり方を根本から変えることも考えられます。

6. 人とAIの関係性

Microsoftのビジョンは「AIに任せられるところは任せ、人間は別の価値創出に集中する」という分業モデルに基づいています。しかし、自分としては、最終的には人間とAIが協働する形に収束すると考えます。完全な分業はリスクが大きく、AIの誤判定や未対応領域を人間が補完する必要があるからです。AIを「新しい同僚」として受け入れる姿勢が、現実的な落としどころになるのではないでしょうか。


このようにまとめると、未来像は壮大ですが、現実に落とし込むには「基盤の安定性」「技術移行の現実性」「人間とAIの共存モデル」といった課題をどう克服するかが鍵になると感じます。

おわりに

「Windows 2030 Vision」で示された未来像は、単なるOSの進化にとどまらず、AIエージェントによる業務の変革、マルチモーダルなユーザー体験、量子耐性を含むセキュリティ再設計といった大きなテーマを包括しています。これらはいずれも今後10年を左右する重要な方向性ですが、同時に実現に向けて多くの課題も残されています。

第一に、AIエージェントの普及は間違いなく進むものの、その実装形態やユーザーがどのように受け入れるかは不透明です。企業が「AIをOSの中心に組み込む」戦略を描いても、歴史的に見ればキラーアプリや予期せぬ技術革新がOSのあり方を根本から変えてきました。したがって、2030年のコンピューティング環境は、Microsoftの構想と市場の偶発的な動きが交差する地点に形成されるでしょう。

第二に、入力デバイスの変革は象徴的ですが、必ずしも現実に即しているとは限りません。音声や視覚入力が高度化する一方で、キーボードの効率性を超える手段は依然として存在しないため、「補完的に新しいインターフェースが追加される」という進化が妥当な予測です。

第三に、セキュリティに関しては「アプライアンスレベル」「量子耐性暗号」「メモリ安全性」といった強力なビジョンが打ち出されました。しかし、現行のWindows Updateの品質問題を見ればわかる通り、現実の課題は足元に山積しています。ユーザーが安心して更新できる基盤を整えなければ、どれほど未来的な構想を掲げても信頼を得ることはできません。

最終的に、今回のビジョンは「OSをAI時代にどう適応させるか」という問いに対するマイクロソフトの回答であり、挑戦的な方向性を提示するものです。しかし、この道筋は直線的ではなく、技術の進化、ユーザー文化の変化、市場の競争環境といった要素によって何度も修正を迫られるはずです。AIが完全に人間を代替する未来ではなく、人間とAIが協働し、役割を調整しながら進化する姿こそが現実的な到達点と考えられます。

言い換えれば「Windows 2030 Vision」は完成図ではなく、進むべき方向を示した地図のようなものです。その地図をどう歩むかはMicrosoftだけでなく、開発者、利用者、そしてこれから登場する新しい技術やサービスによって決まっていくでしょう。

参考文献

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 環境全体の安全を守るうえで不可欠な行動となります。

参考文献

Microsoftが発表したWindowsおよび周辺アプリの変更について利用者が注意すべきポイント

以下では、Microsoftの公式情報にもとづき、Windows 11 24H2の強制アップデートに関する発表と既知の不具合、BitLocker(ストレージ暗号化)の自動有効化によるデータ喪失リスク、そしてMicrosoft Authenticatorのパスワード管理機能廃止について解説します。いずれも利用者に影響し得る重要トピックです。それぞれ明確な見出しのもとに詳細をまとめます。

Windows 11 24H2の強制アップデート

Windows 11 24H2への大型アップデートは順次すべての適格デバイスに提供され、自動適用が進められています。利用者にとっては、不安定な更新が強制されるリスクに注意が必要です。

MicrosoftはWindows 11 バージョン24H2(通称「Windows 11 2024 Update」)の一般提供を開始し、段階的ロールアウトの最終フェーズに入ったと述べています。特に、Windows Update経由での自動更新について「Windows 11 バージョン23H2/22H2/21H2を実行しているHomeおよびProエディションのデバイス(かつIT部門に管理されていないもの)は、バージョン24H2への更新プログラムが自動的に配信される」ことが公式にアナウンスされています。ユーザーは再起動のタイミングを選択したり、短期間(通常1週間程度)であれば延期も可能ですが、基本的には管理されていない一般ユーザーPCには強制的に24H2へのアップデートが適用される流れです。企業の管理下にない端末(例えば自宅利用のPCや小規模事業のPC)が対象となるため、企業ユーザーであってもこうした端末を業務利用している場合は注意が必要です。一方、社内でWindows Update for BusinessやIntune、グループポリシーなどにより更新管理されているデバイスはこの自動適用の対象外ですが、遅かれ早かれ24H2へのアップグレード計画を立てる必要があります。

こうした強制アップデートに対し、利用者からは「十分に検証されていない不安定なアップデートが強制されるのではないか」という懸念が出ています。アップデート中はPCの再起動が繰り返され長時間かかる可能性があり、業務に支障をきたすおそれがあります。また、アップデート適用後にシステム不具合(最悪の場合Blue Screen of Death、いわゆるSTOPエラー)が発生すると業務停止につながりかねません。実際、Windows 11 24H2にはいくつかの既知の不具合が公式に報告されています。企業環境ではWSUSや更新ポリシーでアップデートのタイミングを制御できますが、最新バージョンへの追随そのものは避けられないため、以下のような問題点を把握した上で慎重に展開することが重要です。

未だ不具合が報告されている状況にある24H2ですが、強制アップデートによる影響を軽減させるためにバックアップなどの対策を行いつつ、アップデートに伴う業務停止時間を最小限にするように計画を立てておく必要が

Windows 11 24H2のストレージ暗号化自動化(BitLocker)とデータ喪失リスク

Windows 11 24H2ではデバイスのストレージ暗号化(BitLocker)が初期設定で有効になるケースが増えています。暗号化自体はセキュリティ強化策ですが、万一に備えて回復キーの管理に注意しないと、ユーザーが自分のデータにアクセスできなくなるリスクがあります。

MicrosoftはWindows 11のセキュリティ強化の一環として、「モダンなシステムのほとんどでBitLockerをデフォルト有効化した」と述べています。従来、BitLockerによるドライブ暗号化は主にPro以上のエディションや企業向けに重視されていましたが、Windows 11 24H2では要件緩和によりHomeエディションを含む幅広いシステムで自動的にデバイス暗号化(BitLocker相当)が有効となるよう変更されています。例えばモダンスタンバイ対応のPCだけでなく、TPMを備えた一般的なPCでも条件を満たせばセットアップ時に暗号化がオンになります。これは盗難・紛失時のデータ保護には有効であり、Microsoftも「チップからクラウドまでWindows 11は既定でより安全になった」とアピールしています。

BitLocker自動化の仕組み

初期セットアップや24H2へのアップグレード時に、ユーザーが明示的に操作しなくてもバックグラウンドでドライブ暗号化が開始される場合があります。この際、回復キー(Recovery Key)のバックアップが自動で行われるのが通常です。具体的には、個人のMicrosoftアカウントでWindowsにサインインしている場合、BitLockerの48桁の回復キーはそのアカウントにひも付けられオンラインで取得可能な状態で保存されます。一方、職場や学校の管理下にあるデバイスでは、回復キーはAzure ADやActive Directoryに自動バックアップされ、組織のIT部門が管理します。このように、ユーザー自身が意識しなくとも「回復キーの保管」自体は行われる設計です。ただしMicrosoftも強調しているように、「このバックアップが確実に存在しアクセス可能かを検証すること、必要に応じて自前の追加バックアップを作成すること」が極めて重要です。万一クラウドへのキー保存がされていなかったり、ユーザーが誤ってキー情報を削除してしまっていると、暗号化ドライブにアクセスできなくなった際に復旧手段がなくなるためです。

データ喪失のリスクと注意点

BitLocker暗号化が自動有効になることで懸念されているのが、ユーザーが回復キーを把握していない場合のデータ喪失リスクです。実際、「Windowsのアップデートや設定変更後に突如BitLockerによってロックがかかり、自分のデータにアクセスできなくなった」という報告が増えていると指摘する声もあります。例えばあるユーザーは、「MicrosoftはMicrosoftアカウントでサインインすると自動的にBitLockerを有効化するようになった。もしそのMSアカウントへのアクセス権を失えばデータも永遠に失う。【警告も再チャンスもなく、BitLockerに初めてロックアウトされたときにその存在を知る人が多い】」と述べ、一般ユーザーにとってはデータ機密性よりも可用性(アクセスできること)の方が重要であるケースが多いのに、バックアップの周知不足により「悲劇的な失敗(致命的なデータ損失)」が起きかねないと批判しています。これは決して大げさな懸念ではありません。企業から貸与されたPCや共有端末の場合、利用者自身が回復キーを知らされていなかったり、管理者もキーを紛失してしまうと、そのPC上のローカルデータには誰もアクセスできなくなります。特にリモートワークで従業員が各自セットアップしたPCを使っているような場合、本人が暗号化の存在を認識しておらずキーのバックアップを怠っていると、ちょっとしたハードウェア変更やファームウェア更新が引き金でBitLockerリカバリを求められ、業務データが人質に取られるような事態も起こりえます。

このようなリスクへの対策として、Microsoftは公式ガイドでBitLocker回復キーの確認・バックアップ方法を公開しています。企業環境では、可能であればAzure ADやMBAM(Microsoft BitLocker Administration and Monitoring)等で全端末の回復キーを一元管理する運用が望まれます。また、24H2への更新ポリシー適用時に自動暗号化を無効化するレジストリ設定([DisableDeviceEncryptionキーの利用など】)も技術的には可能です。しかしセキュリティ強化とのトレードオフになるため、基本方針としては暗号化は有効にした上で、キー管理を徹底することが推奨されます。具体的には以下の点に注意してください:

  • キーの所在確認: Microsoftアカウント利用時は「デバイスの一覧」ページから回復キーを確認できます。同僚や部下のPCについても、組織管理下であればAzure ADポータル等からキーを取得可能です。万一に備え、全デバイスのキー情報が揃っているか今一度チェックしましょう。
  • ユーザー周知: IT部門からエンドユーザーへ、「BitLocker暗号化が有効になっている」ことと「回復キーの重要性」について周知徹底してください。鍵を紛失するとデータ復旧不能になる旨を伝え、可能ならユーザー自身にもキーのバックアップ(印刷保管や安全なクラウド保管)を促します。
  • シナリオテスト: ハードディスク交換やBIOSパスワード変更など、BitLockerがリカバリキー入力を要求する典型的なシナリオをテストしてみましょう。キーを正しく入力できるか、手順に不備がないかを事前に確認しておくことで、実際のトラブル時に落ち着いて対応できます。

以上を踏まえ、Windows 11 24H2環境では「暗号化されていることを前提に運用を組み立てる」ことが不可欠です。セキュリティは強化されますが、その裏で鍵管理がおろそかになると本末転倒です。企業としてはデータ漏えいとデータ消失の双方のリスクを考慮し、ポリシーと教育を整備する必要があります。

Microsoft Authenticatorのパスワード管理機能廃止

Microsoft Authenticatorアプリのパスワード保存・自動入力機能が2025年中に段階的終了します。モバイルでAuthenticatorをパスワード管理に使っていたユーザーは、Edgeブラウザーへの移行やエクスポートを求められており、通知を見逃すとパスワードを失う可能性があるため注意が必要です。

Microsoftは「Authenticatorアプリ内のオートフィル(パスワード管理)機能を廃止し、今後はMicrosoft Edgeに統合する」ことを発表しました。これは2025年に入ってから公開されたサポート文書で明らかにされたもので、ユーザーにとって有用だったAuthenticatorのパスワード保存機能を停止する代わりに、より多くのユーザーをEdgeブラウザへ誘導する意図があるとされています。公式には「複数デバイス間でパスワードを容易に使えるようオートフィル体験を整理統合するため」と説明されており、実質的にモバイルにおけるパスワードのオートフィル管理はEdgeに一本化される流れです。

段階的廃止のスケジュール

廃止は一夜にして行われるわけではなく、以下の段階を追って実施されます。

  • 2025年6月 – Authenticatorアプリ上で新しいパスワードを保存する機能が無効化されます。これ以降、Authenticator内には新規のログイン情報を追加登録できなくなります。
  • 2025年7月 – Authenticatorによるパスワード自動入力(オートフィル)機能が停止します。同時に、Authenticatorに保存されていたクレジットカードなどの支払い情報はデバイス上から削除されます(これら支払い情報は他デバイスと同期されない設計のため、このタイミングで消去されると公式に説明されています)。
  • 2025年8月 – Authenticatorアプリに保存されていたパスワードが全て利用不能になります。8月1日をもってサーバー上からも関連データが消去され、以降Authenticatorアプリを開いても既存パスワードは表示されなくなります。

このスケジュールに沿い、最終的にはAuthenticatorアプリからパスワード機能そのものが完全に撤去されます。ただし、アプリ自体は今後も二要素認証コードの生成やパスキーの保存用途で引き続き利用可能です。あくまで削除されるのは「パスワードの保存・入力機能」の部分だけですが、ユーザー体験としては「Authenticatorが大幅に機能縮小される」ことになるため注意が必要です。

利用者への影響と注意点

この変更で最も懸念されるのは、「通知を見逃したユーザーが突然パスワードを失ってしまう」リスクです。MicrosoftはAuthenticatorユーザーに対し、Edgeへの移行またはサードパーティ製パスワードマネージャーへのエクスポートを推奨しています。公式メッセージでは「2025年8月1日より後はAuthenticator内のパスワードおよび情報は自動的に削除されるため、それまでにデータをエクスポートしておくように」と案内しています。しかし、この情報は主にウェブのサポート記事や一部報道を通じて伝えられているもので、アプリ内通知を見落としていたり、そもそも変更自体を知らないユーザーも存在するでしょう。例えば個人でAuthenticatorを使っていた従業員がこの事実を知らない場合、8月になってからアプリを開いて初めて「保存していた多数のサイトのパスワードが消えている」ことに気付き、業務ログインに支障が出るかもしれません。

企業のIT担当者は、従業員がAuthenticatorのパスワード機能を利用しているか把握し、必要に応じてサポートすることが求められます。具体的には:

  • 周知徹底: 会社から「Microsoft Authenticatorでパスワードを保存・自動入力している場合、近日中に使用できなくなる」旨を告知し、各自でEdgeブラウザーの機能に移行するか、データをエクスポートして別のパスワード管理ツールにインポートするよう促しましょう。
  • データエクスポート支援: AuthenticatorアプリにはパスワードデータをCSV形式でエクスポートする機能があります。IT部門として手順を案内したり、必要ならエクスポート作業を支援してください。またエクスポートしたファイルの安全な取扱い(暗号化保管・早期削除)についてもアドバイスすべきです。
  • 代替ソリューションの提示: Microsoftが推奨するようにEdgeブラウザの組み込み機能を使う方法以外にも、企業ポリシーで許可された信頼性の高いパスワード管理ソフト(例: 1PasswordやLastPass、Keeperなど)への移行を検討しても良いでしょう。重要なのは、ユーザーがパスワード管理難民にならないよう事前に受け皿を用意することです。

今回のAuthenticator機能廃止は、Microsoftアカウントを取り巻くパスワードレス戦略の一環とも言われています。実際、同時期にMicrosoftアカウントのパスワードレス認証(パスキーなど)の拡充も発表されています。しかし現実には多くのWebサービスが未だパスワードで保護されており、ユーザー側でパスワードを管理しなければならない状況は当面続きます。企業においても、従業員が誤ってAuthenticator任せにしていたパスワードを失わないよう、そして安全なパスワード管理方法へ円滑に移行できるよう、期限(2025年8月)までに対応を完了させることが望まれます。

まとめ

以上、Windows 11 24H2の強制アップデートと不具合、BitLocker自動暗号化の留意点、Microsoft Authenticatorのパスワード機能廃止について解説しました。いずれのトピックも「セキュリティ強化」や「最新環境への移行」という大きな流れの中で起きている変化ですが、その過程で一時的にユーザーや管理者の負担・リスクが増す側面があります。企業のIT管理者としては公式情報を注視し、適切なタイミングで社内システムやポリシーを調整することが重要です。幸いMicrosoftからは定期的に詳細な発表やドキュメントが提供されていますので、信頼性の高い一次情報をもとに迅速かつ的確な対応を心がけましょう。本記事の情報が、皆様の環境をアップデートしつつ安全に維持する一助になれば幸いです。

まずはこれだけ!GitHub Copilotの使い方

GitHub Copilot を最大限活かせるように基本的な使い方を学びましょう。

本記事では、 Visual Studio Code での操作を中心に説明していますが、ショートカットについてはIntelliJ IDEA や PyCharm などのJetGBrains 系のIDEについても掲載しています。

回答する言語を指定する

英語で回答してほしいときは特に設定変更する必要はありませんが、日本語で回答してほしいときに、毎回「日本語で回答してください」などと書くのは面倒です。GitHub Copilot では、回答する言語を指定することが可能です。

Visual Studio Code の場合は Settings > Extensions > GitHub Copilot で、Github > Copilot > Chat: Locale Overridesの設定を変更することで、指定した言語で回答を求めることができます。

デフォルトはautoになっていると思いますので、日本語で回答してほしければja に変更してください。

IntelliJ IDEA や PyCharm などでは、 Settings > Languages & Frameworks > GitHub Copilot で、Chat欄のNatural Languageを日本語に変更することで、日本語で回答を求めることができます。

3つのツールを状況に応じて使い分ける

ここでは、以下の3つのツールの使い分けについて説明します。

  1. インラインチャット
  2. チャットパネル
  3. ChatGPT などの対話型生成AIサービス

インラインチャット

チャットパネルを起動してもよいのですが、インラインチャットを使うことでより素早くコードを生成したり、改善したりできます。

Visual Studio Code で、インラインチャットを起動するには、Cmd+IWin+I)のショートカットキーを使用します。

IntelliJ IDEA や PyCharm では、Ctrl+Shift+ICtrl+Shift+G)で同様の操作ができます。

チャットパネル

チャットパネルを使用すると、ワークスペースに関する質問ができるため、説明を求めたい場合にはこちらを使用します。後述のChatGPTなどの対話型生成AIサービスでもソースコードを添付すれば似たようなことができますが、手間なくできる点ではこちらを使用するのがよいでしょう。

チャットパネルは、Cmd+Shift+ICtrl+Shift+I)で開閉できます。会話後、コードに復帰したいときはチャットパネルを閉じることですぐにコーディングに戻れます。

IntelliJ IDEA や PyCharm では、Ctrl+Shift+C(Windowsも同様)で、チャットパネルの開閉ができます。

ChatGPTなどの対話型生成AIサービス

一方、ワークスペースに依らない問題の解決方法を質問したいとかであれば GitHub Copilot Chat ではなく、 ChatGPT などを使う方が効率的です。これは GitHub Copilot Chat ではコーディングに関する内容にのみ答えてくれるという点が影響しており、会話の途中で答えてくれなくなることはストレスになるので、使い分けをした方がよいのではないかと思います。

現時点ではアプリ版かWeb版を使うことになるかと思います。ChatGPT 以外にもツールはたくさんありますので、使いやすいものを選択してください。

コードを生成する

インラインチャットを含めたコード生成のパターンを考えます。

適切な名称をつけてコードを生成してもらう

もっとも基本的な生成の仕方になります。関数を生成する場合、適切な関数名をつけることでその関数名に沿ったコードを生成してくれます。

たとえば、JavaScriptで2つの数を加算する関数を作成する場合、addTwoNumbersという名前をつけることで2つの引数と加算をするコードが生成されます。

function addTwoNumbers と入力すると、候補が表示されます。TABキーでこれを確定すると関数が完成します。

コメントをつけて生成してもらう

実現したいことをコメントで書いて、その内容にあったコードを生成させます。

コメントを書いてから改行すると、そのコメントにあったコードが生成されます。

生成された内容が問題なければ、TABキーで確定させます。

候補が表示されているとき、マウスカーソルをカーソルをホバーすると、生成するコードの他の候補に切り替えられます。

これを表示しなくても、Option+[Alt+[)とOption+]Alt+])で前の候補と次の候補を行き来でき、生成したい候補でTABキーで確定できます。最初に生成されたコードが期待したコードでなくても別の候補が期待したコードである可能性があるので、切り替えて確認するとよいでしょう。

コードを書きながらコードを生成してもらう

これがもっともよく使われている方法かもしれません。コードを書きながらその次のコードを生成してもらう方法です。

同じようなコードを生成する場合や常套句のようなコードを生成する場合には高い精度のコードを生成してくれますが、意図が正しく伝わっていないと期待したコードを生成してくれないので、後述のインラインチャットでコード生成を指示するのがよいと思います。

インラインチャットでコード生成を指示する

適切な関数名が思いつかなくてもコメントを書かなくてもインラインチャットを使うことでコードの生成を指示できます。

ENTERRETURN)キーで生成してくれます。

Visual Studio Code では、再生成したければCmd+RWin+R)、受け入れるならCmd+ENTERWin+RETURN)を押下します。IntelliJ IDEA や PyCharm ではショートカットは用意されていないようで、マウス操作で再生成し、

受け入れるなら、同様にマウス操作で

エディタに反映します。

インラインチャットでコードを書き換えてもらう

書き換えてほしいコードを選択し、インラインチャットで書き換えてほしい内容を入力することでコードの改善ができます。とりあえず書いたコードにバグがあったり、非効率なコードだったりするときに改善してもらうことができるので便利です。

修正してほしいコードを範囲選択し、インラインチャットを起動、修正後どうなってほしいかを伝えます。

候補が表示されるので、

問題なければCmd+ENTERWin+RETURN)で確定します。

文章による説明を求める必要がなく、さっさと修正したい場合はチャットパネルではなくインラインチャットを使う方が効率よくコーディングを進められます。

何をするかを指定する

文章で書かなくてもコマンドを使ってやってほしいことを指定することができます。

/generate

実際には文章で書いても手間ではなく、先にコメントを書いておけば生成してくれるので、使う機会はほぼないかもしれませんが、Visual Studio Code ではコード生成をするコマンドがあります。

/generateを使って作成してほしいコードの仕様を伝えると、

以下のようにコードを生成してくれます。

IntelliJ IDEA や PyCharm ではこのコマンドはないようですので、ご注意ください。

/fix

修正についても文章で書いてもそれほど手間ではないので使う機会は多くないですが、/fixコマンドを使うことで修正を指示することができます。

/fixコマンドに続いて修正してほしいことを記述することで、

修正結果を表示してくれます。

このコマンドは IntelliJ IDEA や PyCharm でも使用可能です。

/explain

コードやワークスペースが何を行っているのかを説明・要約してもらうことで、コードを一から読むよりも理解が早くなります。たとえば、業務で自分が関わったことのない古いコードがある場合、そのコードについて説明をしてもらってからコードを読んだ方が理解しやすいと思います。

説明はインラインチャットではなくチャットパネルで聞いた方がわかりやすいです。

チャットパネルを開くと、現在エディタで表示しているファイルが選択済みなので、このまま/explainコマンドを指定します。

説明の中で不明な点や深掘りしたい点があれば、チャットで追加質問してください。

このコマンドは IntelliJ IDEA や PyCharm でも使用可能です。

/doc

これまではクラスやメソッドのコメントを書くこともメンテナンスすることも非常にコストの高い作業だったと思います。生成AIの登場でこのような問題は過去のものとなりつつあります。

関数の先頭で以下のように/docコマンドを使用すると、

以下のようにドキュメントテーションコメントを生成してくれます。

コメントが古くて最新化したい場合でも/docコマンドが使用できます。以下のようにドキュメンテーションコメントが適切にメンテナンスされていない場合でも、コメントと関数を範囲指定して/docコマンドを使うと、

以下のようにコメントを生成し直してくれます。

このコマンドは IntelliJ IDEA や PyCharm でも使用可能です。

/tests

主にGitHub Copilot Chatで使用しますが、テスト対象を選択してテストコードを生成することができます。ただし、注意したいのは、テストの準備にプロジェクト固有の特殊が必要な場合にはうまく生成されないことがあります。

基本的には、最初の1つはコード補完を使いながら自身で作成し、その派生形で記述できる他のバリエーションを指示しながら作成するのがよいでしょう。テストで使用している値についても細かく指示するよりは一旦生成させて自身で修正した方が早い場合があります。

その他のコマンド

上記以外にもいくつかのコマンドがあります。

Visual Studio Code では、コード編集を行うための /edit コマンドが用意されています。

IntelliJ IDEA や PyCharm ではコードをシンプルにするための/simplyfy コマンドが用意されていますが、冗長なコードという点であれば、IDE自体の機能で修正できる場合もありますので、それほど使用頻度は高くないと思います。

何を参照するかを指定する

何を参照するのかを明示的に指定することで、精度の高い回答を得ることができます。これらはVisual Studio Code のみで使用可能ですが、ファイルだけはIntelliJ IDEA や PyCharm でもマウス操作で追加することができます。

@workspace

ワークスペース内のソースコードをすべて参照し、関連性の高いファイルをピックアップしてコードや回答を生成します。説明上、この記事中ではワークスペースという表現に統一していますが、ワークスペースでもプロジェクトでも伝わりますので、特に気にする必要はありません。

@vscode

Visual Studio Code 限定の機能になりますが、Visual Studio Codeの機能に着目した回答をしてくれます。設定やショートカットキーに関する質問をしたい場合は、@vscodeをつけるようにしてください。会話の中で設定に遷移するボタンも出力してくれるので、こちらも活用してみてください。

Show in Settings Editorをクリックすると、

設定が表示されます。

@terminal

コードの話ではなく、コマンドに関する質問をしたい場合は、ターミナルに着目した回答をしてくれる@terminalを使うのがよいでしょう。

#file

参照してほしいファイルを指定します。基本的にはアイコンをクリックしてファイルを選ぶのがよいでしょう。基本的に単独で使用可能ですが、もし効かないようであれば@workspaceと併用してください。

#editor

エディタの表示領域を含めるには#editorを使用します。ただし、現在エディタで表示しているファイルはデフォルトで参照していることがほとんどなので、あまり使う機会はないかもしれません。

#selection

エディタの選択箇所を参照します。IntelliJ IDEA や

#terminalLastCommand

ターミナルで最後に実行したコマンドとその実行結果を参照します。非常に便利な機能ですが、

#terminalSelection

ターミナルの選択箇所を参照します。コマンドを実行していてエラーが出たときに対処方法を聞くときは#terminalLastCommandで構いませんが、もう少しピンポイントで聞きたいときは#terminalSelectionを使うとよいでしょう。

目的別プロンプト集

いくつか、よく使いそうなプロンプト例をまとめてみました。これらはGitHub Copilot Chatで使用します。

ワークスペース全体を説明してもらう

/explainコマンドと@workspaceを組み合わせることで、ワークスペース全体について説明してもらうことができます。

@workspace /explain

新しく参画したメンバーが担当するワークスペースの構造を把握する際にとても有用だと思います。オンボーディング中やオンボーディング後の自習時間に使ってみてはいかがでしょうか。

ワークスペースのディレクトリ構造を明らかにする

ワークスペースのディレクトリ構造に可視化したいときは、以下のように聞くとよいです。

@workspace /explain ワークスペースのディレクトリ構造を教えて

こちらも、どこにどんなファイルがあるのかをディレクトリ構造を把握したい場合に有効な方法です。

コードレビューをしてもらう

作成したコードに対してコードレビューを行ってもらうのも有効な使い方のひとつです。

コードレビューを行う場合は、包括的なレビューをするのか、特定の何かについてレビューをするのかを明確にすることが重要です。

包括的なレビューを行ってほしい場合

たとえば、改善すべて点はありますかと質問するとよりよくするためのアドバイスを回答してもらうことができます。この方法は、最初のレビューや最終的なレビューとして使うとよいでしょう。

特定の観点に基づいてレビューを行ってほしい場合

特定の観点についてレビューをしてもらうことで、改善すべき点をより明確にすることができます。

具体的には、コード品質(命名規則、冗長なコード、可読性)、セキュリティ、パフォーマンスなどの問題を指摘してもらうのがよいと思います。

  • 命名は適切ですか
  • 冗長なコードや簡潔に書けるコードはありますか
  • エラーハンドリングは適切ですか
  • 実装漏れやデバッグコードなどは残っていませんか
  • 脆弱性はありますか
  • パフォーマンスの問題はありますか
  • 不足しているテスト観点はありますか

これ以外にも、プロジェクト固有の観点(特定の機能が実装されているか、など)を確認するのもよいでしょう。

また、レビューア側でも目視によるレビューと併用するのもよいと思います。

まとめ

当然といえば当然ですが、 GitHub Copilotの機能はVisual Studio Codeがもっとも充実しています。ただ、EclipseやIntellJ IDEA など他のIDEでもまったく使えないわけではないため、もし使っているのであれば積極的に活用していくことが重要です。

GitHub Copilotを活用にするには、基本的なショートカットやコマンドなどを理解することももちろんですが、やってほしいことを明確に指示することが大切です。これはインラインチャットで指示するだけでなく、コメントを書いてからコードを書き始めるということも含みます。

Copilot や AI Agent 関連はかなり活発に進化しています。この記事で紹介した機能以外もありますし、今後もっとよいやり方が出てくることも容易に想像できます。コーディングの生産性を高めるため、定期的にキャッチアップが必要だと思います。

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を揃えるようにするなど何かしらの対策をしておいた方がよいかもしれません。

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メモリを使用しているため、このような表示になっています。

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

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

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

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

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

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

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

ISOHybrid イメージの検出

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

ダウンロードが必要です

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

警告

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

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

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

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

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