#windows

MicrosoftがRustを「Tier-1 language」として扱っている、とRust Foundationの寄稿記事が改めて説明しました。単に「Rustを使っています」という話ではなく、社内開発の中でC++やC#、TypeScriptと並ぶ重要言語として位置づけ、Windows向けの開発基盤に深く組み込んでいるという宣言です。Rustは安全性の高い言語として語られがちですが、この記事が面白いのは、その評価が理想論ではなく、Microsoftの実務やビルド基盤の話にまで降りている点にあります。しかも焦点は言語そのものより、RustをWindowsの既存エコシステムにどう接続するかにあります。 記事はまず、RustがMicrosoftにとって戦略上重要な技術であると位置づけます。Azure CTOのMark Russinovichが以前に示したネイティブコードの将来戦略や、MicrosoftがRust Projectを支えるために長年にわたって資金を投じてきた流れを踏まえたうえで、Rustは今や社内開発で最もよく支援される言語群の一つになったと述べています。ここでいう「Tier-1

このエラーは、少なくとも今回読んだ issue 群では Windows 側の仮想化まわりと強く結びついています。 ただし、根っこは 1 つではなさそうです。報告を追うと、同じ文言でも原因が違うケースが混ざっています。 最初に切り分けたいのは、自分の症状がどちら寄りかです。 つまり、この系統では「Windows の仮想マシン機能が無効」「必要な機能が入っていない」側をまず疑うのが自然です。 一方で [#82688](https://github.com/anthropics/claude-code/issues/82688) では、原因がもっと単純で、`CoworkVMService` が `Stopped` になっていただけだったケースが報告されています。 この報告では、`Start-Service CoworkVMService` を通常権限で実行するとすぐ直った、とされています。アプリ側が再起動や再インストールを勧めるより先に、サービス自体を起動すべきだ、という指摘です。 この 2 件だけでも、エラー表示が同じでも対処は同じではないと分かります。 「Windows の機能が

この文字列が出たからといって、ただちに「通信が遅い」の一言では片づきません。今回の 2 件の issue では、どちらも MCP サーバーが期待どおり起動しない、あるいは起動のしかたが想定とずれる ところまで話が進んでいました。 つまり、この症状は「接続先が遠い」よりも、「起動時にサーバーが落ちる」「同じサーバーが二重に起動する」といった、MCP 側の立ち上がり方に目を向けたほうがよさそうです。 まず見たいのは、エラーの出方です。`Starting connection with timeout of 30000ms` のあとに、`CONNECTION_CLOSED` や `Invalid Version:` が続くなら、[#93134](https://github.com/anthropics/claude-code/issues/93134) の流れにかなり近いです。少なくともその issue では、プラグインの manifest 経由で起動した `desktop-commander` の MCP サーバーが、`npm` の時点で止まっていました。 一方で、ツールがまった

このエラーは、少なくとも報告上は 2 つのまったく違う場面で出ています。ひとつは SSH でリモートフォルダに入るとき、もうひとつは Claude Desktop の Code タブで Cowork VM を作るところです。どちらも最終的には同じ文言ですが、引き金は同一とは限りません。 まず自分のケースに近いかを切り分けると、[#64425](https://github.com/anthropics/claude-code/issues/64425) は「同じホストでもホスト名の書き方で成否が変わる」例でした。`root@frigate.ahfp` や `root@pve.ahfp` では失敗し、`frigate.ahfp.local` や `orangepi@wait-room-kiosk.ahfp` では成功しています。つまり、少なくともこの報告では “接続先そのもの” より “ホスト名の表記” に症状が結びついています。 一方で [#64867](https://github.com/anthropics/claude-code/issues/64867) は Windows

`ERR_NAME_NOT_RESOLVED` は、今回の issue 報告では Claude Desktop 起動直後の通信が DNS 解決で落ちている形で出ています。読者の環境でも、起動時にネットワーク系の初期化が失敗しているなら、この症状に近い可能性があります。 ```text Health check fetch failed: Error: net::ERR_NAME_NOT_RESOLVED ``` この報告で分かるのは、少なくともアプリ内部の Chromium ネットワークスタックが、起動時の API 呼び出しを名前解決エラーで通せていない、という点です。少なくとも issue の記述上は、アプリ本体の表示崩れではなく、起動直後の通信失敗が中心に見えます。 切り分けの起点は単純です。もし同じ `ERR_NAME_NOT_RESOLVED` が出ているなら、「アプリだけが落ちる」のか、「名前解決そのものが不安定なのか」を分けて見たほうがよさそうです。#73042 の報告は Windows 10 Enterprise、App Version 1.17377.2、Electro

このエラーは、少なくとも今回確認できた issue では、Cowork の VM サービス側で起動に失敗しているときに出ています。ユーザー向けの文言は同じでも、原因は 1 つではありません。 自分のケースかどうかを見分ける材料としては、まず「どの製品で出ているか」が重要です。[#39010](https://github.com/anthropics/claude-code/issues/39010) は Windows 10 Pro 上の Cowork で、起動時に `VM service not running. The service failed to start.` が出ています。報告者は、実体としては MSIX パッケージ配下の `AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\` に作られた VM 用の `rootfs.vhdx` や `smol-bin.vhdx` が NTFS 圧縮を引き継ぎ、Hyper-V が圧縮された VHDX をマウントできずに失敗していたと書いています。そこで見えていた HCS エラ

この症状は、Windows 版 Claude Desktop で Cowork を起動しようとしたときに「Failed to start Claude's workspace / RPC pipe closed」と出るものです。今回参照した issue はどちらも未解決で、しかも再インストールが途中で止まる、あるいは署名検証で落ちる、という流れまで共通しています。該当する報告は [#86825](https://github.com/anthropics/claude-code/issues/86825) と [#90283](https://github.com/anthropics/claude-code/issues/90283) です。 まず、自分のケースかどうかはここで見分けやすいです。起動時に RPC pipe closed が出る一方で、VM 側のサービスは Running のまま、というパターンです。[#90283](https://github.com/anthropics/claude-code/issues/90283) では `CoworkVMService,

この症状は、少なくとも今回参照した 2 件の issue では、Claude Desktop の起動直後に落ちる系の話として報告されています。1 件は Windows/MSIX 版で、起動後 1.5〜10 秒ほどで main process が自分で終了し、`exit code -1 (0xFFFFFFFF)` になったというものです [#86535](https://github.com/anthropics/claude-code/issues/86535)。もう 1 件は Windows 版で、renderer の bootstrap 周りや sessions-bridge、`claude.exe` の子プロセスに関する不調が並んでいます [#79846](https://github.com/anthropics/claude-code/issues/79846)。 ただし、手元で確認できている一次情報は Windows ではありません。実際に取得できたのは Linux 上の Node.js バージョンだけです。 ```text $ node --version v16.15.

この症状は、少なくとも GitHub 上では 2 件まとまっていました。ひとつは Snapdragon X 環境での報告、もうひとつは Windows 11 Home の低スペック環境で、アップデート後に Cowork guest が毎回失敗するという報告です。どちらも同じエラー文言です。検索するなら `VM connection timeout after 60 seconds` で十分です。 筆者の環境で確認できた一次情報は、以下だけです。この記事で書けるのは、これ以上でもこれ以下でもありません。 ```text OS : Linux 3.10.0-1160.76.1.el7.x86_64 (x86_64) Python : 3.8.13 検証日時 : 2026-08-22T08:50:32+09:00 ``` このため、現時点では「特定 OS 固有の不具合」「特定の更新後に増えた不具合」「低スペックや Snapdragon 系の環境で VM まわりが失敗している可能性」は疑えますが、断定はできません。少なくとも、報告済みの 2 件はどちらも「VM

自分のケースかどうかを先に切り分けるなら、今回集められている issue はどれも「Claude Code のプロセスが途中で死んで、結果として `exited with code 3` と見える」点は共通です。ただし、落ちるタイミングと見えているクラッシュ住所が違います。 たとえば、[#78436](https://github.com/anthropics/claude-code/issues/78436) は、Windows 11 上の Claude Code desktop session が約 30 分後に死んだ報告です。本文では `Elapsed: 1817103ms` とあり、Bundled された `claude.exe` が次のように panic しています。 ```text panic(main thread): Segmentation fault at address 0xFFFFFFFFFFFFFFFF ``` この issue の報告では、「起動直後ではなく、セッションがしばらく動いたあとに落ちた」点がはっきりしています。しかも、同じ `0xFFFFFFFF

まず、この症状は「Claude Code の hook が関係しているらしいが、処理自体は止まらない」タイプではなく、少なくとも issue 上ではもっと厄介に見えます。Windows 環境で `hook_non_blocking_error` が繰り返し出て、設定した hook コマンドが実行されていないように見える、という報告が上がっています。 報告は 2 件あり、どちらも Windows 上の Claude Code に関するものです。[#72636](https://github.com/anthropics/claude-code/issues/72636) では「configured hook commands を実行しない。hook runner が `git` を呼んで失敗を黙って飲み込む」と書かれています。[#79847](https://github.com/anthropics/claude-code/issues/79847) では、Windows で `fg: no job control` が `hook_non_blocking_error` として再発し

`Claude Code process exited with code 3` が出ても、すべてが同じ原因とは限りません。少なくとも今回集めた issue では、Windows 側で常駐している Windhawk が関わるケースと、Hyper-V の仮想マシン内で Claude Code のバイナリが落ちるケースが別々に報告されています。 自分の症状がどちらに近いか、先に分けるのがよさそうです。 ターミナルでは動くのにデスクトップアプリ側だけで落ちるなら、[#52386](https://github.com/anthropics/claude-code/issues/52386) の報告とかなり似ています。報告者は「昨日までは動いていたが、今日は毎回 `Claude Code process exited with code 3` になる」「terminal では引き続き動く」と書いています。さらに Windhawk を終了すると直るとも述べています。 一方で、Windows の Cowork 経由で、VM の起動自体は成功するのに Claude Code の binary が始ま

まず、自分のケースかどうかを切り分けます。今回の報告で共通していたのは、Windows 上で Claude Code を使っていること、そして `EEXIST` が出ていることでした。ひとつは worktree の扱いで「git リポジトリではない」と誤判定される話、もうひとつは `~/.claude/session-env/<session-id>` を作るところで `mkdir` が `EEXIST` になる話です。前者は [#40164](https://github.com/anthropics/claude-code/issues/40164)、後者は [#65309](https://github.com/anthropics/claude-code/issues/65309) です。 ただし、筆者の手元で確認できたのは macOS 上の Claude Code 2.1.207 までです。Windows で同じ再現確認はしていません。なので、ここで書けるのは「こういう症状の issue が実際にある」「手元の環境ではこのバージョンとこの導入状態だった」という範囲に限られます

まず自分のケースかどうかを見るなら、今回集めた issue では「ネットワーク越しのボリューム」や「Windows のパス解決」で `EPERM` が出ています。ローカルディスクの単純な読み書きではなく、保存先や対象が少し特殊なときに崩れていました。 たとえば macOS では、SMB マウントされた volume 上のファイルに対して Read/Bash を走らせると `Operation not permitted` が返る報告があります。報告者は mount の所有者で、`smbutil statshares` でも SMB 3.1.1 と暗号化有効を確認していました。それでも `dangerouslyDisableSandbox: true` では止められず、`--add-dir /Volumes/storage` か `permissions.additionalDirectories` を追加する回避策しか見つかっていませんでした。これが [#57540](https://github.com/anthropics/claude-code/issues/57540) です。

「Teamsで通知が届かない・音が鳴らない」というガイドは2025年3月ごろから定番のネタとして各所で書かれてきた。1年以上経った今もう一度読み直してみると、当時のチェックリストは今でも土台としては有効だが、2026年に入ってから起きている不具合は、当時想定されていなかった種類のものだとわかる。 代表格が2つある。ひとつは4月中旬から報告が相次いだ「通知がデスクトップに張り付いたまま消えない」不具合。もうひとつは、Plannerのタスクチャット刷新に伴って意図的に仕様変更された「コメント通知が来なくなった」現象だ。前者はバグ、後者は仕様変更——原因が真逆なのに、ユーザー側からはどちらも「通知がおかしい」としか見えない。本稿ではこの2つを軸に、旧来のチェックリストをどう位置づけ直せばいいかを整理する。 --- 症状が「来ない」のか「消えない」のか「減った」のかで、疑うべき場所が変わる。 | 症状 | まず疑うもの | 対処 | |---|---|---| | バナーも音も一切来ない | 3層構造（後述）のどこかでオフになっている | 下記「3層」を上から順に確認

「昨日まで普通に使えていたClassic Outlookが、右クリックした瞬間に落ちる」「起動してもすぐ強制終了し、次はセーフモードで開く」——2026年6月末から、この手の悲鳴がまた一気に増えた。半年前・1年前に書かれた「Outlookが起動しない完全解決ガイド」的な記事が今また読まれているのは、まさに今、Classic Outlookのクラッシュが立て続けに起きているからだ。 本稿は、2026年前半に発生した複数のクラッシュ事案を発生時期・影響ビルド・原因・修正状況で整理し直し、「自分のケースはどれで、何をすれば直るか」を最短で切り分けられるようにしたものだ。結論から言うと、直近の主犯は更新プログラムの回帰（リグレッション）で、多くは“Officeを最新へ更新するだけ”で直る。設定を9個いじる前に、まずここを見たほうが早い。 > ⚠️ 先に結論: 2026年6月29日ごろから急にClassic Outlookが落ち始めたなら、疑うべきは自分の設定ではなく **Microsoft 365 Apps バージョン2605（Build 20026.20182

For Claude and Claude Code users, this bug report is interesting because it exposes a very real gap between chat-first usage and agent infrastructure on Windows. Even if you never intend to use Cowork or agent mode, the desktop app may still spin up a heavyweight virtualized stack in the background, and that’s the kind of thing developers notice immediately on a constrained machine. A GitHub issue reports that Claude Desktop on Windows spawns a Hyper-V VM on every launch, even for chat-only use.

Microsoftと、Nightmare Eclipse（別名 Chaotic Eclipse）と名乗る研究者の対立が激化している 研究者はこれまでに 6件のWindows 0-day を公開し、うち 3件は実際に攻撃で悪用 されている Microsoftは「正式な手順で報告されていない」と主張し、法的対応を示唆した 研究者側は、Microsoftに連絡を無視され、アカウント削除や報酬なしの扱いを受けたと反発している 次の“公開予告”として 7月14日 が示されており、事態はさらに悪化する可能性がある この騒動は、脆弱性報告のルール作りがいかに難しいかを改めて見せつけている 今回の話は、かなり人間くさいです。 単なる「脆弱性が見つかった」「パッチが出た」という技術ニュースではなく、研究者とMicrosoftの関係が完全にこじれた結果、0-day公開合戦みたいな状態になっている、というのが本質です。 記事によると、Nightmare Eclipse（Chaotic Eclipseとも呼ばれる）は、Windowsの深い知識を持つ一方で、Microsoftに強

Microsoftが、Windowsのゼロデイ脆弱性を投稿したセキュリティ研究者のGitHubアカウントを停止した 研究者側は「Microsoftに人生を台無しにされた」と主張し、今回の対応を「報復的だ」と非難している 研究者はGitLabへ移動し、さらに反撃を続ける構えを見せている ただし、脅迫めいた発言も含まれており、今回の件は単なる“意見の対立”では済まない重い問題になっている Tom's Hardwareが報じたのは、Microsoftとセキュリティ研究者のあいだで起きた、かなり後味の悪い一件です。 対象になったのは、Nightmare-Eclipse、別名 Chaotic Eclipse と呼ばれる研究者です。 この人物は、Windowsのゼロデイ exploit を投稿したことで、MicrosoftのGitHubアカウントを停止されたとされています。 ここでいう ゼロデイ とは、まだ修正されていない脆弱性 のこと。つまり、悪用されると危険なのに、メーカー側の対策がまだ間に合っていない状態です。 そして exploit は、その

この記事は、Excelの共有しているブックを解除する方法を扱っている 解除は［アクセス許可の管理］から行う メールアドレスで共有した相手との共有は、相手を外すことで解除できる URLを送って共有した場合は、そのリンクを無効化する必要がある 共有の仕組みを知っておくと、「もう見せたくない」「共同編集をやめたい」ときに慌てず済む Excelでいう「ブック」は、ざっくり言えば1つのExcelファイルのことです。 それをOneDrive経由で共有すると、他の人と同じファイルを見たり、編集したりできます。 これは便利なんですが、実際に使っていると「共有をやめたい」「この人だけ外したい」「リンクをもう使えなくしたい」という場面、けっこうあります。 個人的には、共有は始めるより終わらせ方のほうが大事だと思います。止め方を知らない共有は、ちょっと怖いですからね。 元記事の結論はかなり明快で、［アクセス許可の管理］で解除する、というものです。 ここでいう「アクセス許可」とは、そのファイルに誰が入れるか、誰が見られるか、編集できるかを管理する

Excelのブック共有は、Excelを開かなくても設定できる 方法は、エクスプローラー上で操作すること 共有したいブックは、OneDriveと同期しているフォルダーに移動して使う 「Excelを起動して、ファイルを開いて……」と考えがちだが、実はもっと手早い 個人的には、こういう地味だけど効く小ワザがいちばんありがたいと思う 今回の元記事は、「Excelで開かないとブックを共有できないの？」という、かなり実用的な疑問に答えたQ&Aです。 結論からいうと、ブックの共有はExcelを開かなくても設定できます。 しかもやり方は意外とシンプルで、エクスプローラー（Windowsでファイルやフォルダーを見たり移動したりする画面）から操作できる、というのがポイントです。 これ、ぱっと見は「え、そんなのでいいの？」と思うかもしれません。 でも実際、ファイル共有や共同編集って、毎回Excelを起動して中から設定するより、ファイルの置き場所と同期状態を整えるほうが本質なんですよね。ここがわかると、Microsoft 365時代のファイル管理がかなり

Microsoftの月例修正「Patch Tuesday」の直後に、Windowsの新しいゼロデイ脆弱性が3件公開された 脆弱性の名前は YellowKey、GreenPlasma、MiniPlasma YellowKeyはBitLockerを物理アクセスだけで突破しうる GreenPlasmaはWindowsの権限をSYSTEMまで引き上げられる可能性がある MiniPlasmaは2020年に修正されたはずの古いCVEが、いまも悪用できるとされている ここ6週間で、研究者 Nightmare Eclipse が公開した脆弱性は合計6件に達した 一部はすでに悪用中、少なくとも1件はCISAのKEVにも入っている Dark Readingが伝えているのは、Windowsの脆弱性公開がまだ終わっていない、というかなり重たい話です。 Microsoftが毎月まとめて行う修正日は「Patch Tuesday」と呼ばれます。簡単に言うと、Windowsの不具合やセキュリティ問題を定期的に直す“月例メンテ日”です。ところが、その直後にまた新しい穴が見つかる。しかも今回は1件ではなく3件。なかなか嫌

Windowsに昔から入っている `MSHTA` が、攻撃者に悪用されている 入口はフィッシングや「無料ソフト」「クラック版」を装った誘導が多い `LOLBIN`（正規ツールの悪用）なので、見た目では不審さが出にくい `Lumma`、`Amatera`、`ClipBanker`、`PurpleFox` などの配布に使われている 対策は「ユーザー教育」だけでなく、「古い機能を止める」技術的対策も重要 最近のサイバー攻撃で、ちょっと皮肉なのがこの話です。 Windowsの“昔ながらの正規機能”が、マルウェア配布の便利な道具になっているんですね。SecurityWeekの記事は、Microsoftの `MSHTA` という古いユーティリティが、静かにマルウェアをばらまく攻撃で急増していると伝えています。 率直に言うと、これはかなり厄介です。 なぜなら `MSHTA` は「怪しい外部ツール」ではなく、Microsoftが署名した正規の機能だからです。セキュリティ製品から見ると、完全に即ブロックしづらい。攻撃者からすると、これほど都合のいい入口はありません。 `MSHTA` は

MicrosoftがPatch Tuesdayで138件の脆弱性を修正 そのうち30件がCriticalで、かなり重めの内容 Windows DNSとNetlogonに、ネットワーク経由でコード実行されうる深刻な欠陥 Secure Boot証明書の更新も重要で、放置すると来月以降に問題が出る可能性 Microsoft自身も、AIを使った脆弱性発見の加速で今後パッチ件数が増えると見ている --- Microsoftがまた大仕事をやっています。今回のPatch Tuesdayでは、なんと138件もの脆弱性に対して修正パッチが公開されました。しかも、そのうち30件がCritical。セキュリティ修正の世界では、これはかなりのボリュームです。 個人的には、ここが一番面白いところだと思います。単に「件数が多い」だけではなく、AIを使った脆弱性発見が加速していて、パッチの規模そのものが膨らみつつある、という流れがはっきり見えてきています。便利さの裏で、守る側の仕事もどんどん増えているわけです。 The Hacker Newsに

匿名の研究者が、Microsoft製品の未修正ゼロデイ脆弱性を2件追加で公開した 1つはBitLocker回避、もう1つは権限昇格につながる問題 BitLocker回避が本当なら、盗難PCが“ただの紛失”では済まなくなる可能性がある 権限昇格のほうは、現時点では完全なPoCではないが、悪用される土台は示されている 研究者は今年だけで複数のゼロデイを公開しており、Microsoftへの報復的な流れが続いているように見える The Registerによると、Microsoftの脆弱性を立て続けに公開している匿名の研究者が、また2件のゼロデイ情報を出しました。 今回の名前は YellowKey と GreenPlasma。前者は BitLocker bypass、後者は privilege escalation（権限昇格）です。 ざっくり言うと、BitLocker bypassは「暗号化されたはずのPCの守りをすり抜ける」話、権限昇格は「一般ユーザーとして入ったあと、管理者権限やSYSTEM権限まで上がる」話です

Microsoftが、AIエージェントを束ねて脆弱性を探す新基盤「MDASH」を公開した MDASHは Multi-Model Agentic Scanning Harness の略で、100個以上のAIエージェントを連携させて動かす すでにWindows関連で 16件の新たな脆弱性 を発見し、そのうち 4件は重大（critical） 2件は リモートコード実行（RCE） につながる深刻な問題で、May updateで修正された テストでは false positive（誤検知）ゼロ をうたっており、かなり印象がいい ただし、これは「AIが全部解決する」話ではなく、AIをどう運用するか が本質だと感じる --- Microsoftが、AIを使ったセキュリティ基盤「MDASH」を発表しました。 名前だけ聞くと「またAIっぽい新製品かな？」と思うかもしれませんが、今回はわりと本気です。というのも、MDASHはすでに Windowsの新しい脆弱性を16件発見 していて、その中には 4件の重大なもの が含まれているからです。 しか