#macos

この症状は、Claude Code の worktree を使って新しいローカルセッションを起動した直後に、ブランチ切り替えの段階で止まるものです。手元の issue 報告では、ダイアログに > ブランチを切り替えられませんでした (Could not switch branch) > `Background full checkout failed: other` と出て、そのままセッションが始まりません。#86276 では、worktree 自体は片付く一方で、セッション用に作られたブランチ `claude/<name>-<hash>` が base repo 側に残ると報告されています。[#86276](https://github.com/anthropics/claude-code/issues/86276) 似た見え方をする別件もあります。#74526 では、git submodule の中で worktree セッションや background-task chip を起動すると同じ `Background full checkout failed: other` に落ち、

Chromeでログイン画面は出るのに、「パスワードを保存しますか？」が出ない、あるいは以前入れたID・パスワードが自動入力されない状態です。 まずは、よくある順に見ていきます。Chrome では、たいてい次のどれかです。 Chrome 側で「パスワードの保存」がオフになっている 自動入力の候補はあるのに、Google パスワード マネージャーに保存されていない すでにそのサイトが「保存しない」に入っている シークレット モードやゲスト ブラウジングを使っている 他のパスワード管理アプリや、仕事用のポリシー設定が邪魔している 上から順に試してみてください。ほとんどの場合、1〜3番の確認で止まります。 Chrome for Windows 11 24H2、macOS Sequoia、ChromeOS でも見方はほぼ同じです。 Chrome 右上の ︙ を開き、[設定] を選びます。 左側の [Google パスワード マネージャー] を開きます。 表示が少し違う場合は、[自動入力とパスワード] → **[Google パスワード マネージャー

Word のコメントが消せないとき、原因はだいたい次の4つに分かれます。どれに当たるかは、［校閲］タブの［削除］ボタンが押せるかどうかでおおよそ見分けられます。 | 状況 | 考えられる原因 | 見る場所 | |---|---|---| | ［削除］ボタンが灰色で押せない | 文書が保護されている／読み取り専用・閲覧のみの権限で開いている | 確認1・確認2 | | 画面上部に「保護されたビュー」「編集を有効にする」の黄色いバーが出ている | 保護ビューで開いている | 確認1 | | 削除したはずのコメントがまだ残っている、または別の場所に出てくる | 「解決済み」にしただけ／表示の切り替えで隠れていただけ | 確認3 | | 削除できるが、1件ずつで終わらない | 一括削除を使っていない | 確認4 | メールの添付ファイルやインターネットから保存した文書は、「保護されたビュー」で開きます。この状態では編集ができないので、コメントも削除できません。 画面上部の黄色いバーに ［編集を有効にする］ があればクリックする タイトル バーに「読み取り専用」と出ている場合は、

読んでいてまず思ったのは、これは「直したつもり」がいちばん危ないタイプの話だ、ということだった。 ログもコメントも残っているのに、それを見て安心してしまうと、実際には何週間も同じ失敗を繰り返していても気づけない。自動化って便利なぶん、こういう“見えているのに見えていない”状態を作りやすいんだなと思った。 面白かったのは、作者がちゃんと failure を見える化したつもりで、それでもなお根っこの原因は残っていた点だ。`gtimeout` でハングを止める、成功時だけ STAMP を更新する、失敗は stderr に残す。どれも筋が通っている。けれど、それらは「失敗を検出しやすくする」だけで、「失敗をなくす」わけではない。ここを混同すると、コメントが増えるほど安心してしまう。記事を読んでいて、まさにそこに引っかかった。 もう一つ気になったのは、`gh auth token` のところだ。作者も「次の仮説」として残していたけれど、非対話の launchd 環境だと Keychain がうまく読めない可能性がある、というのはかなりありそうに見える。しかも失敗しても静かに未認証ルートへ落ちるな

手元にある issue には、少なくとも 2 つの別パターンがありました。ひとつは macOS 13.x で `claude` の起動そのものが落ちるケース、もうひとつは zsh の起動時に余計なエラーが毎回出るケースです。見た目は似ていますが、症状の場所が違います。 `[#69928](https://github.com/anthropics/claude-code/issues/69928)` では、インストール直後に次のような出力が出ています。 ```text Setting up Claude Code... dyld: Symbol not found: __ZTVNSt3__115basic_stringbufIcNS_11char_traitsIcEENS_9allocatorIcEEEE Referenced from: /Users/emmaborowski/.claude/downloads/claude-2.1.185-darwin-x64 (which was built for Mac OS X 13.0) Expected in: /usr/lib/lib

Macのベータ版を触っている人のあいだで、Apple Intelligence に絡む「余計なものを落としたくない」という話が出ています。今回の元記事は、Reddit に投稿された短いスレッドで、AIモデルや関連パッケージのダウンロードを避けるための回避策が共有された、という内容です。元記事自体は本文情報がほとんど残っていないのですが、少なくとも「MacOSBeta の文脈で、Apple の AI 機能に関するダウンロードを止めたい人がいる」という空気は読み取れます。ベータ版では仕様が変わりやすく、思わぬ通信や容量消費が起きやすいので、こうした小さな工夫が妙に現実的に響きます。 元記事は Reddit の r/MacOSBeta に投稿されたもので、タイトルは「Workaround to avoid downloading AI models and ...」となっています。本文の抽出結果には「Reddit」とだけあり、投稿本文の具体的な説明は残っていませんが、少なくとも投稿者は、MacOS Beta で何かを有効にしたときに AI モデルや関連コンポーネントのダウンロードが始まってし

What jumps out to me isn’t the AppleScript, or even the somewhat Rube Goldberg plan of watching Terminal tabs for a Claude Code dialog and then poking Enter for them. It’s that the author is describing a problem space where the obvious “just automate it” answer keeps colliding with macOS security in different ways, and one of those collisions is silent. Silent failures are the worst kind, especially when you’re debugging background automation that is supposed to babysit an unattended machine. I

読んでまず思ったのは、ここまでやるのか、という驚きでした。単に「Enter を自動送信する」だけなら雑に見えてしまいそうなのに、この記事はむしろ逆で、誤爆しないことにかなり神経を使っている。その慎重さが面白かったです。 特に引っかかったのは、AppleScript で画面を見に行く方法が、思った以上に壊れやすいことです。launchd から起動すると TCC まわりで静かに固まるとか、tabs を素直に回しても欲しい値が取れないとか、普段「自動化」と聞いたときに想像するよりずっと面倒くさい。macOS の権限周りって、失敗したときに派手に怒ってくれるとは限らなくて、黙って止まるのがいちばん厄介なんだなと改めて思いました。 もう一つ印象に残ったのは、この記事が「押せばいい」で済ませず、カーソルが本当に Allow 側にあるかまで確認しているところです。人間なら目で見て判断している部分を、雑に置き換えると危ない。自動化って便利そうに見えて、実際には「何を信用していいか」をかなり細かく設計しないと事故るんだな、と感じました。地味ですが、その地味さこそが実装の本体なのだと思います。 --- >

Homebrewが7.0.0を公開した。今回の更新は、単なる定例のバージョン上げではなく、インストールやアップグレードの高速化、sandboxingの強化、macOS向けの新しいネイティブアプリ、脆弱性チェックの内蔵など、使い方そのものに触る内容がまとまっている。しかも、macOS 10.15のサポート終了やIntel Macの扱い変更まで含まれていて、Homebrewがどの環境を今後重視するのかもはっきりした。日常的にbrewを叩いている人ほど、影響の大きい節目だと思う。 Homebrew 7.0.0は、6.0.0以降で最も大きい変化として、まず速度と安全性を前面に出している。公開時点のアップグレードは、`brew update` を通じて自動で進められるか、`HOMEBREW_NO_AUTO_UPDATE` を使っている場合は手動で `brew update` を走らせればよい。ここでいう 7.0.0 では、古いインターフェースは段階的に扱いが変わり、deprecated は警告、disabled は拒否、removed はそもそも使えない、という整理が入った。 サポート環境の見直

この症状は、Claude Code の Agent Teams と tmux の組み合わせで、teammate の spawn が失敗したときに報告されています。代表例は [#77559](https://github.com/anthropics/claude-code/issues/77559) です。報告文では、`Failed to send command to pane %2: respawn pane failed: fork failed: Device not configured` という形で失敗しており、別の pane `%3` でも同じエラーが出ています。Issue 本文では、`ENXIO / "Device not configured"` は「harness が tty を失った pane を指している」ことを示唆すると書かれています。 まず自分のケースかどうかを見分けるなら、次の2点が合っているかを確認するとよさそうです。ひとつは、Agent Teams の tmux セッションで teammate の spawn 時にだけ落ちること。もうひとつは、エラーメ

Google Ads で広告を出したら、突然アカウントを止められた。理由は「Malicious software」と「Compromised Site」。ただ、本人は「そんなものはない」と反論し、公開した検証結果を並べて再審査を求めた。この記事は、そのやり取りの経過と、なぜ本人がここまで強く false positive を疑っているのかを記録したものだ。しかも最後には、Hacker News で話題になった結果、アカウントが復活したと追記されている。広告審査のブラックボックスさと、開発者が巻き込まれる理不尽さが、かなり生々しく見える話だった。 記事の主題は、RACE という macOS 向け terminal multiplexer の広告が Google Ads で止められた、という出来事だ。RACE は Rust で書かれたネイティブアプリで、複数の端末を自由な大きさで並べ、開発作業に合わせて配置できる。普通の terminal multiplexer のように、アプリを閉じても shell session を生かしたままにできるのが売りで、作者自身が開発し、日常的に使い、保守も

いちばん最初に思ったのは、ようやくAIが“人の前に割り込む存在”から少し離れたな、ということだった。PCを勝手に触るAIって、便利そうに見えて、実際にはこちらの操作とぶつかりやすい。記事にあるように、これまではユーザーが別の作業をすると干渉して失敗することもあったという。あれは想像以上にストレスが大きいはずで、AIの性能以前に、机の上での居場所の問題だったんだと思う。 バックグラウンドで動くようになると、体感はかなり変わるはずだ。AIに画面操作を任せているあいだ、自分はメールを書くなり、別の資料を直すなりできる。つまり「AIの作業を見守る時間」が減る。こういう改善は地味だけれど、実際の使い心地を一段上げる。生成AIは派手な新機能より、こういう摩擦を削るほうが効くのではないかと思う。 ただ、Macだけというのは少し引っかかった。しかも macOS Sequoia 15 以降に限る。ベータで、しかも Pro / Max 向け。触れる人がかなり絞られているので、「今すぐ誰でも使える未来」ではない。とはいえ、こういう制約つきの実験でも、先に使い勝手の型を作るのは意味があるはずだ。Windows

このエラーが出るケースは、少なくとも issue 報告上では二つに分かれています。ひとつは、もともと動いていた作業フォルダがアップデート後に急に弾かれるケース。もうひとつは、フォルダ内に `Skills`、`Scheduled`、`Artifacts`、`.claude/` などが絡んでいて、同じ文言で止まるケースです。該当する報告は [#78368](https://github.com/anthropics/claude-code/issues/78368) と [#89916](https://github.com/anthropics/claude-code/issues/89916) です。 見分けるときは、まず「そのフォルダは以前は問題なく使えていたか」と「中に `.claude/` があるか、あるいは `Skills` などの名前のサブフォルダがあるか」を確認するのが早いです。少なくとも issue の記述では、見た目上は Claude のアプリデータが入っていないのに、この文言で拒否される例がありました。[#78368](https://github.com/anthr

What jumps out to me is not the feature itself, but the fact that this is the version of computer use people will actually tolerate. Letting an agent commandeer your cursor is still a bit of a party trick. Letting it run in the background while you keep working feels much closer to something I’d leave on. That said, I’m not sure this is as huge a leap as the framing suggests. Anthropic is catching up to a pattern OpenAI already pushed onto the Mac earlier this year, so the interesting part is le

新しいターミナルを開くたびに `claude` が見つからない。けれど、インストールの途中では成功メッセージが出ている。そんなときは、まずこの2つの issue が自分の症状に近いかを見たほうがいいです。 1つは、`install.sh` か `claude install` が「launcher と shell integration を設定した」と表示するのに、`~/.local/bin` を `PATH` に追加していないケースです。報告は macOS / zsh ですが、症状そのものは「入ったはずなのにシェルから見えない」です。該当 issue は [#76060](https://github.com/anthropics/claude-code/issues/76060) です。 もう1つは、自動更新の途中で optional dependency のダウンロードが詰まり、更新は成功扱いで終わるのに、次の起動で `claude: command not found` になるケースです。こちらは [#72690](https://github.com/anthropics/c

自分のケースかどうかを先に切り分けるなら、まず「Claude Desktop に付属している Claude Code だけが落ちるのか」を確認したほうが早いです。issue には、同じ macOS 12 系の機械で、Desktop app の bundled build だけが起動直後に死に、standalone CLI は動いた例がありました。つまり、少なくとも報告上は「macOS が古いから全部だめ」という話ではありません。 issue に出ているエラーは、どれも「起動直後に dyld がシンボルを見つけられず abort する」という形です。たとえば #91381 は `_DNSServiceGetAddrInfoEx`、#75206 は libc++ の symbol not found、#91550 も `_DNSServiceGetAddrInfoEx` でした。見た目は違っても、どれも `exit code 134` に落ち着いています。 #75206](https://github.com/anthropics/claude-code/issues/75206) では、

macOS の見た目や操作感は好きだけれど、ハードウェアやエコシステムの閉じ方には距離を置きたい。そんな発想から、ravynOS というオープンソースOSのプロジェクトが前面に出てきた。今回のページは、その考え方をかなり率直に説明している。まだ完成品ではなく、あくまで開発者向けの初期段階だと明言している点も含めて、野心と未完成さが同時に見える内容だ。似た話は昔からあるが、今回は「macOS の使い心地を、オープンソースと自由なハードウェアの上で再現したい」という筋がはっきりしているので取り上げる価値がある。 ravynOS のトップページは、まずこのOSが何者かをかなり直接的に示している。説明によると、ravynOS は Darwin、FreeBSD、そして Apple のオープンソースコードを土台にした、早期段階のオープンソースOSだ。狙いは macOS のアプリケーションと互換性を持たせること、そして「hardware restrictions」がないこと。つまり、Apple 製ハードウェアに縛られない macOS 風の環境を作ろうとしているわけだ。 ページの文面では、「macOS

Apple SiliconのMac上で、仮想のiPhoneを起動するためのCLIツールがGitHubに公開されています。名前は `vphone-cli`。見た目は地味ですが、中身はかなり攻めています。iOS向けのファームウェアを準備し、パッチを当て、DFU復元を経て、カスタムファームウェアを入れ、最初の起動まで一気通貫で進められるようにしているからです。単なるデモではなく、研究用途や自動化テストまで視野に入った道具に見えます。 この手の話は、単に「面白い」で終わりません。AppleのVirtualization.framework、iOSの復元、AMFIやSIPの制約、さらにはSileoやTrollStoreまで出てくるので、macOSとiPhoneの境界がどこまで揺らされているのかを知る材料になります。元記事はREADME中心ですが、そこに書かれている内容だけでも十分に濃いです。 `vphone-cli` は、Lakr233 が公開している公開リポジトリで、README には「Apple の Virtualization.framework を使って、PCC research VM

`ERR_ABORTED` は同じ文字列でも、報告されている中身がかなり違います。今回の issue 群では、少なくとも 2 パターンありました。ひとつは Claude Cowork 連携で artifact を作った直後に表示と共有が失敗する件、もうひとつは Claude in Chrome の `read_network_requests` が中断された通信に対して HTTP 503 を作って見せてしまう件です。 自分のケースかどうかを先に見分けるなら、最初にこの 2 点を切り分けるのが早いです。artifact 作成直後に失敗しているなら [#61571](https://github.com/anthropics/claude-code/issues/61571) に近いです。ネットワークの読み取り結果として 503 が返ってくるなら [#77841](https://github.com/anthropics/claude-code/issues/77841) に近いです。 この issue は closed ですが、本文にある通り「artifact 生成直後に表示できない」

最初に思ったのは、「プリンタの世界、まだこんなに面倒なのか」ということだった。しかも相手が“古い業務機”ではなく、2023年に出たHP Laser 1008aだというのが妙に効いている。WindowsとLinuxでは使えるのにmacOSだけ置き去り、しかもAirPrintもない。こういう中途半端な孤立は、実際に困る人が少ないぶん、公式対応がつきにくいんだろうなと思う。 それでも、Claude Codeを使ってmacOS向けのdriverを作ってしまった、というのは素直に面白い。AIがすごいというより、人間が「どうせ既存のdriverがないなら、作ってしまおう」と踏み込めるようになったことが大きい気がする。特に、SPL3みたいなかなり癖のある独自print languageを扱っている点は、ただの小技ではない。エラー画面を読ませたり、Linux containerの中でHPのrastertospl codecを動かして本物のSPL3を出したりと、かなり泥臭い手順をAIと一緒に詰めている。ここは「AIが勝手に解決した」という話ではなく、むしろ人間がかなり細かく面倒を見たから成立したのだろう

まず、この症状に当てはまるかどうかを先に切り分けます。今回の issue では、Remote Control が失敗を重ねたあとに無効化され、再起動しないと試し直せないように見える、という報告が 2 件あります。`[#78364](https://github.com/anthropics/claude-code/issues/78364)` では「3 回の一時的な失敗」で Remote Control が静かに恒久無効化される、と書かれています。`[#87269](https://github.com/anthropics/claude-code/issues/87269)` では、起動時に Remote Control の開始に失敗すると、そのセッション中は回復せず、再接続経路もないと報告されています。 今回の手元の確認では、Claude Code は Remote Control 機能自体を案内していますが、同時に複数インストールの存在も出ています。実際の出力は次のとおりです。 ```text $ claude --version 2.1.207 (Claude Code) ``

自分のケースかどうかを先に切り分けるなら、Claude Desktop の通常チャットは動くのに、Code タブだけが起動直後に失敗するかどうかです。Issue [#83656](https://github.com/anthropics/claude-code/issues/83656) と [#82587](https://github.com/anthropics/claude-code/issues/82587) では、どちらも Code タブの起動失敗が報告されていて、エラー文に `Malformed Mach-o file` と `exit code 127` が出ています。前者では、Desktop が別途ダウンロードした `claude` バイナリの署名状態まで確認されています。 今回の issue 群で見えているのは、少なくとも「Claude Code 自体の機能不全」というより、Claude Desktop 側が起動する `claude` バイナリの読み込みに失敗している、という形です。`#83656` の報告では、main の Claude.app 本体と help

`exit code 143` は、この材料だけを見ると「Claude Code のプロセスが SIGTERM で終わった」系の症状として扱うのが自然です。そう見てよさそうな根拠は、issue 側で実際に `SIGTERM (exit 143)` と書かれていることです。たとえば [#87658](https://github.com/anthropics/claude-code/issues/87658) では、Claude desktop アプリ内で 2 つ目の local Code セッションを始めると、先に動いていた CLI プロセスが SIGTERM で終了すると報告されています。 ただし、同じ `exit code 143` でも原因はひとつではありません。#76293 では、対話中の Claude Code が Bash tool の成功後に何のエラー表示もなく shell に戻り、あとでセッションを再開できたと書かれています。こちらの報告では、約 3 日動作していたこと、永続化された transcript が約 4.6 MB だったこと、request metadata

まず、この件は Claude Code 側から返ってくる `HTTP 500` です。Issue では、`Anthropic API Error: 500 Internal Server Error` という表現でまとまっていて、内容も `Internal server error` とだけ出ています。たとえば代表 issue の [#59832](https://github.com/anthropics/claude-code/issues/59832) には、API の 500 が出たことと、`status.claude.com` を確認するよう案内する文面が載っています。ほかの [#59778](https://github.com/anthropics/claude-code/issues/59778)、[#59748](https://github.com/anthropics/claude-code/issues/59748)、[#59753](https://github.com/anthropics/claude-code/issues/59753) も同じ症状です。

`ENOTFOUND` は、少なくとも今回の issue 群では「DNS が引けていない」系の失敗として現れています。ただし、同じ見え方でも原因は 1 つではありません。今回確認できた範囲では、`claude update` で失敗するケースと、macOS のスリープ復帰後に OAuth の更新がこけるケースが並んでいます。 症状の入口としては、`claude update` や Web 系の操作で `ENOTFOUND` / `ETIMEDOUT` が出て、その後にログイン状態が崩れるか、アップデートだけ失敗するかを見ます。参照できる issue は [#71699](https://github.com/anthropics/claude-code/issues/71699) と [#85149](https://github.com/anthropics/claude-code/issues/85149) です。 まず、自分の環境で Claude Code がどう入っているかは確認しておいたほうがよさそうです。手元の出力では、`claude doctor` が複数インストールを検

まず自分のケースかどうかを見るなら、今回集めた 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) です。

この症状は、Claude Code が `ENOSPC` とともに「temp filesystem is full (0MB free)」「Command output was lost...」のような文言を出すのに、実際には空き容量があるケースとして報告されています。少なくとも issue 上では、ディスク不足そのものではない例が 2 件ありました。ひとつは [#65086](https://github.com/anthropics/claude-code/issues/65086) で、`stdout` も `stderr` も出さずに非 0 終了した subprocess に対して、偽の `ENOSPC` が出たという報告です。もうひとつは [#65251](https://github.com/anthropics/claude-code/issues/65251) で、macOS 上で Bash tool の出力取得が失敗し、`/private/tmp/claude-501/.../tasks` の temp filesystem が満杯だと誤判定されたという報告でした。

まず切り分けたいのは、あなたの症状が「長く動かしているバックグラウンド処理が、本人の操作なしに止まる」タイプかどうかです。今回の issue 群では、どちらも Claude Code のバックグラウンド実行に絡んで exit code 144 が出ています。 手元で確認できた Claude Code CLI の情報はこれです。 ```text $ claude --version 2.1.207 (Claude Code) ``` 背景エージェント関連のコマンドは存在しています。 ```text $ claude agents --help Usage: claude agents [options] Manage background agents Options: --add-dir <directory> Additional directory to allow tool access in dispatched sessions (repeatable) --agent <agent> Default

正直、最初に思ったのは「そこまでやるのか」という驚きだった。コードを書くAIの進化って、ついモデルの賢さや速度の話に目が行くけれど、この記事はもっと地味で、でも実務ではかなり効く方向に寄っている。別々のTerminalで動いているClaude同士が、手でコピペしなくても文脈を渡し合える。派手さはないけれど、こういう小さな摩擦の削減が一番ありがたい場面は多い。 面白いのは、Anthropicがここで「会話の全部」を共有させていないことだと思う。やり取りできるのはtextだけで、historyやfilesやpermissionsまでは渡らない。これは少し中途半端にも見えるけれど、むしろ現実的だとも感じた。AIエージェント同士をつなぐと、便利さと危うさがすぐ同居する。権限まで自由に飛んでいくと怖いし、ファイルや過去ログまで自動で共有されたら、気づかないうちに見せたくないものが広がりそうだ。その意味で、メッセージは通すが勝手な許可変更はさせない、という線引きはかなり妥当ではないかと思う。 一方で、これが本当に効くのは「複数セッションを同時に回す人」だけだろうとも思った。普通の人にとっては、まだ

会議に入った直後、マイクが勝手にオフになっていて毎回オンにし直す状態です。 Teamsで「参加したのに、なぜか自分だけミュート」のときは、アプリの設定より先に、会議の権限とデバイス側を見たほうが早いです。上から順に試してください。ほとんどの場合これで直ります。 会議の主催者側で、参加時に参加者を自動ミュートする設定になっている Teams 側で使うマイクが別デバイスに切り替わっている Windows 11 24H2 や macOS Sequoia のマイク権限が外れている Bluetooth ヘッドセットの省電力機能で、通話開始時に入力が不安定になっている Teams の一時的な不具合や、古いキャッシュが残っている Microsoft Teams for Microsoft 365 で、主催者が「参加者は入室時にミュート」を有効にしていると、参加後に自分でマイクを戻す必要があります。自分が主催者でないなら、ここが原因のことは多いです。 Step 1 会議画面右上の [参加者] を開き、主催者に「入室時のミュート設定が入っていないか」を確認します。 Step 2 自分が主

Teams で自分だけ映らない、または会議前のカメラプレビューが真っ黒になるときは、だいたい「権限」「別アプリの占有」「Teams 側の設定」「端末の一時不調」のどれかです。上から順に試してみてください。ほとんどの場合、最初の2〜3手で戻ります。 Windows 11 24H2 / macOS Sequoia / iOS 18 でカメラ権限が切れている ほかのアプリがカメラをつかんだままになっている Teams の「ビデオ」がオフ、またはプレビュー表示が崩れている 外付けWebカメラやドッキングステーションの接続が不安定 Teams アプリ自体のキャッシュや更新状態が古い Step 1 Step 2 「カメラへのアクセス」がオンか確認し、さらに「アプリにカメラへのアクセスを許可する」もオンにします。 Step 3 一覧の中にある「Microsoft Teams」をオンにします。 古いデスクトップ版では「デスクトップアプリにカメラへのアクセスを許可する」も必要です。 Step 1 Step 2 「Microsoft Teams」にチェックが入ってい

PowerPoint for Microsoft 365 / PowerPoint 2024 で、スライド番号を入れたはずなのに表示されない、または数ページだけ番号が飛ぶときは、だいたい設定の食い違いです。 そもそも「スライド番号」を入れる設定がオフになっている そのスライドだけ「ヘッダーとフッター」が外れている タイトルスライドに番号を表示しない設定になっている ほかのレイアウトを使っていて、番号プレースホルダー（=差し込み用の枠）が入っていない テンプレート側で番号の位置や色が背景と重なって見えなくなっている 上から順に試してみてください。ほとんどの場合、ここで直ります。 PowerPoint for Microsoft 365 / PowerPoint 2024（Windows 11 24H2）の場合、まずはここです。 1. [挿入] → [ヘッダーとフッター] を開きます。 2. [スライド] タブで [スライド番号] にチェックを入れます。 3. 必要なら [タイトル スライドに表示しない] のチェックを外します。 4. [すべてに適用] を押します。 これで全体に反映される

正直、これはかなり“地味だけど効く”アップデートだと思った。派手な新機能というより、複数の作業が同時に走っているときの、あの面倒な説明の繰り返しを減らしてくれる話だからだ。 特に引っかかったのは、Claude が単にメッセージを中継するだけでなく、「要約された内容」を次の session に渡すところ。履歴や files を丸ごと引き継ぐわけではない、という線引きは妙に現実的だと思う。便利さはあるけれど、何でも自動で共有されるほど怖い仕組みにはしていない。AI に仕事を投げるとき、結局いちばん事故るのは“勝手に全部つながっている感”なので、この控えめさは好ましい。 一方で、これが本当に活きるのは、1 人が複数の作業を並走させる場面よりも、複数の worktree や長い処理が絡むときではないかと思う。人間がタブを行ったり来たりしながら「さっき何を見つけたんだっけ」と探す代わりに、Claude 同士が軽く受け渡してくれるなら、かなりストレスが減るはずだ。逆に言うと、単独の session しか使わない人にはあまり刺さらない。そこは機能として少し玄人向けだなとも感じた。 あと、permis

最初に思ったのは、これは地味だけどかなり気持ちいい解決だな、ということだった。手で直すINDEX.mdって、たしかに最初は親切そうに見えるのに、少し増えた瞬間にもう信用できなくなる。27個もエージェントがあるならなおさらで、「一覧のほうが現実に追いつかない」状態はほぼ避けられない。そこを最初から壊れ物として扱って、自動生成に寄せているのが潔い。 面白かったのは、やっていること自体よりも、壊れ方への目配りだと思う。frontmatterのパースをPyYAMLに頼らず、Bashの中にPythonを埋め込んで、さらに壊れたファイルはエラーで止めず警告として残す。こういう設計は「完璧に検証してから出す」より、「まず一覧を生かして、壊れている場所も見えるようにする」発想に近い。現場ではそのほうが役に立つことが多い。全部を厳密に守らせると、どこか1つのミスで仕組み全体が止まるから。 あと、launchdで週1回、しかも低優先度で回しているのも、いかにも実用主義だと思った。毎回手で叩くのは面倒だし、毎回リアルタイムに更新するほどのものでもない。こういう「十分に新しい」を自動で維持する仕組みは、日々の

AnthropicのAIエージェント「Claude Cowork」に、なかなか嫌な穴が見つかりました。 ざっくり言うと、本来は隔離されているはずの仮想環境から抜け出し、Mac上のファイルにまで手を伸ばせる可能性があった、という話です。AppleInsiderが伝えたこの記事は、AIの便利さの裏側にある「権限管理」の甘さをかなり生々しく示しています。 Claude Coworkのローカル実行モードに、仮想マシンの外へ影響が及ぶ弱点があった 攻撃の起点は、Linux kernelの不具合 CVE-2026-46331 仮想環境内でroot権限を取られると、Macのファイルシステムにある共有領域へ触れた そこからSSH private key、クラウド認証情報、ブラウザデータなどに届く可能性があった Anthropicはすでにクラウド実行をデフォルトにしており、ローカル処理よりは安全とされる ただし、AIに広い権限を与える危険そのものは消えていない 今回の話でややこしいのは、Claude Coworkが「Macの上でそのまま動いていた」のではなく、**

Anthropicの「Claude Cowork」に、Mac上のローカル実行時にサンドボックスを抜けられる脆弱性が見つかった 影響を受けたのは、修正前のローカル Cowork セッションを使っていた約50万台のmacOS端末とされる 攻撃が成功すると、AIエージェントがVMの外に出て、ユーザーのMac上のファイルを読み書きできる SSH鍵やクラウド認証情報など、盗まれると困るデータに手が届く可能性がある いまの最新版はクラウド実行が既定なので回避されるが、ローカル実行を選ぶとまだ危ない 根っこにあるのは「仮想マシンの中だけに閉じ込めたつもりが、ホスト側のファイルシステムまでつながっていた」という設計上の怖さ この記事、かなり面白いです。AIエージェントの話というと、つい「便利な自動化」や「賢いアシスタント」を想像しがちですが、実際には“どこまで触っていいのか”の境界線が本当に難しい。今回の件は、その境界線があっさり破られた例だと思います。 The Hacker News が伝えたのは、Anthropic の Claude Cowork にある sandbox escape 脆弱性です。

Califが、Apple M5搭載のmacOSで動くカーネルのメモリ破壊系エクスプロイトを公開した 対象は、Appleの新しい防御機構 MIE（Memory Integrity Enforcement） が有効な環境 ローカルの一般ユーザー権限から root シェルまで到達する、権限昇格の攻撃チェーンだという 研究チームは、脆弱性発見から約5日で動作する exploit を作ったと主張している 詳細な技術情報は、Appleが修正を出したあとに公開する予定 個人的には、「新しい防御は無敵ではない」という現実をかなり強く突きつける話だと思う セキュリティ研究者グループの Calif が、Appleの最新チップ M5 上で動くmacOSに対して、カーネルのメモリ破壊系脆弱性を使った公開エクスプロイトを作った、と発表しました。 ざっくり言うと、これは 「Macのかなり深いところ、OSの中核である kernel を攻撃して、管理者権限より強い root 権限まで上がれる攻撃を実際に動かした」 という話です。 しかも相

For Claude and Claude Code users, this kind of Apple security release matters more than it first appears. A lot of AI workflows now live inside the browser, the terminal, Mail, and local dev tooling, so OS-level fixes for sandbox escapes, kernel bugs, and privacy bypasses can directly affect the safety of the environments we build and test in. Apple says this document describes the security content of macOS Tahoe 26.5, released May 11, 2026. The update covers a broad set of vulnerabilities acros

Excel で、入力の続きを予測してくれない／曜日や連番がオートフィルで入らないときの対処法です。 「下へドラッグしても同じ値しか入らない」「候補の一覧が出ない」「連続データにならない」――そんな症状は、設定・操作・セルの書式のどれかが原因のことが多いです。上から順に試してみてください。ほとんどの場合これで直ります。 オートフィルの機能自体がオフ - Excel 2024 / Microsoft 365 では、予測入力やオートフィルに関する設定が無効だと、動きが変わります。 ドラッグではなく「コピー」になっている - 連続データではなく、同じ値の複製として扱われている可能性があります。 セルの書式が「文字列」になっている - 数値や日付に見えても、文字列扱いだと連番や曜日の判定がうまくいきません。 フィルハンドルが使えない設定 - 右下の小さい四角（=フィルハンドル）が無効だと、オートフィルしづらくなります。 Excel の不具合やアドインの影響 - Excel for Microsoft 365 / Windows 11 24H2 で、アドイン

「Zoomのマイクテストでは聞こえるのに、実際の会議に入ると自分の声だけ相手に届かない」——この症状、かなり焦りますよね。 でも、上から順に試してみてください。ほとんどの場合、設定の切り替えで直ります。 よくある原因は次の5つです。 Zoom会議でミュートの解除ができていない Zoom側のマイク選択が本番で別デバイスになっている Windows 11 24H2 / macOS Sequoia / iOS 18 の権限設定でマイクが制限されている 他のアプリがマイクを占有している Bluetoothヘッドセットの接続不安定で、テスト時と本番時に入力先がずれる --- テストでは通るのに本番だけ無音、で一番多いのがこれです。 1. Zoom会議画面の左下にある [ミュート解除] を確認します。 2. 斜線付きのマイクアイコンなら、そこをクリックして解除します。 3. 画面上部や左下に 「ホストによってミュートにされています」 と出ていないか見ます。 4. 出ている場合は、ホストに「ミュート解除の許可」を依頼します。 >

症状：MacのAirDropが相手側に出てこない、または受信できず送れない。 AirDropは便利ですが、Wi‑FiやBluetoothの設定、受信範囲、接続条件のどこか1つでもズレると急に見えなくなります。 上から順に試してください。ほとんどの場合、ここまでで直ります。 --- AirDropの受信設定が「連絡先のみ」になっている Wi‑Fi / Bluetooth がオフ、または不安定 Mac側のファイアウォール設定で受信が妨げられている Personal Hotspot（インターネット共有）が有効になっている 送受信側の距離が遠い、または相手の機種が発見条件を満たしていない --- まずここです。相手に表示されない原因の定番です。 Macで [Finder] → [移動] → [AirDrop] を開きます。 画面下部の 「このMacを発見可能な相手」 を確認します。 以下のどちらかに切り替えてください。 「すべての人（10分間）」 「連絡先のみ」 相手が連絡先に入っていないなら、まず

Chromeでログインしたはずなのに、次に開くとまたサインインを求められる状態ですね。 この症状は、Cookieの保存が止まっている、同期が切れている、Chromeのプロフィールが壊れているあたりが原因のことが多いです。 上から順に試してみてください。ほとんどの場合、これで直ります。 サードパーティ Cookie がブロックされている Chromeの同期（Sync=データ同期）がオフ、または一時停止している 「終了時に閲覧履歴を消去」「Cookieを自動削除」が有効になっている Chromeのプロフィール（ユーザーデータ）が壊れている 拡張機能（=Chromeに追加した機能）がログイン維持を邪魔している --- ログイン状態はCookieで保持されるため、ここが止まると毎回サインインになります。 Chromeで [設定] を開きます。 次に [プライバシーとセキュリティ] → [サードパーティ Cookie] を選びます。 [サードパーティ Cookie をブロックする] になっている場合は、いったん **[サード

症状：PowerPointで貼り付けた画像が、保存したあとにぼやける・荒くなる・印刷すると画質が落ちる。 PowerPoint for Microsoft 365 / Windows 11 24H2、または PowerPoint for Microsoft 365 / macOS Sequoia 15 でよくある悩みです。 画像そのものが壊れているというより、PowerPoint側の圧縮設定や保存形式が原因のことが多いです。上から順に試してください。ほとんどの場合これで直ります。 --- 画像の自動圧縮が有効になっている 既定の解像度が低く設定されている 「図の圧縮」で一括圧縮されている JPG などの劣化しやすい形式で保存・再保存している コピー＆ペースト時に低解像度の画像として貼り付いている --- PowerPoint for Microsoft 365 / Windows 11 24H2 では、これが一番多い原因です。 1. PowerPoint を開き、[ファイル] → [オプション] を選びます。 2. 左側の [詳細設定] をクリックします。 3.

「Microsoft Teamsで会議中に画面共有できない」「共有ボタンがグレーアウトして押せない」状態のときに、まず疑うべき原因と解決手順をまとめます。 会議の画面共有ができないときは、アプリの不具合よりも会議設定・権限・OS側の許可が原因であることが多いです。上から順に試してください。ほとんどの場合これで直ります。 会議の主催者が共有を制限している Teamsアプリが古い、または一時的に不調 Windows 11 24H2 / macOS Sequoia / iOS 18 側で画面収録・アクセシビリティ権限が未許可 会社の管理ポリシーで外部共有や画面共有が禁止されている ネットワーク不安定、VPN、セキュリティソフトの干渉 --- まずここを確認してください。共有ボタンが押せない場合、会議の主催者設定で止められていることがあります。 1. 会議画面で [参加者] を開く 2. 参加者一覧の上部や会議オプションで、共有に関する制限がないか確認する 3. 主催者または共同開催者の場合は、**会議オプション*

Safariで「Cookieの許可が必要です」と表示され、ログイン画面から先へ進めない症状の対処法をまとめます。 SafariでWebサービスにログインしようとすると、「Cookieを有効にしてください」、「このページではCookieが必要です」、「ログインできない／次へ進めない」と出て止まることがあります。 Office系サービスや金融サイト、予約サイトでもよくある症状です。 --- まずは、よくある原因を上から順に確認してください。ほとんどの場合、設定の見直しで直ります。 1. SafariでCookieがブロックされている 2. Webサイトデータやキャッシュが壊れている 3. コンテンツブロッカーや拡張機能が邪魔している 4. プライベートブラウズで開いている 5. iPhone / Mac 側の日時設定やOSが古い --- 1. [設定] を開きます。 2. [アプリ] → [Safari] をタップします。 3. [詳細] → [すべてのCookieをブロック] がオンならオフにします。 4.

Chromeのタブを開きすぎて、Windows 11 24H2 や macOS Sequoia 15 で動作が重くなり、メモリ使用量が増えている状態を、できるだけ手早く軽くする方法をまとめます。 「タブを閉じても重い」「Chromeだけ妙にメモリを食う」というときは、上から順に試してみてください。ほとんどの場合、設定の見直しだけでかなり改善します。 --- 開きっぱなしのタブ数が多く、メモリ（RAM）を使いすぎている 画像・動画・広告が多いページを複数開いている Chrome のバックグラウンド動作や拡張機能が負荷を増やしている キャッシュ（=一時保存データ）がたまっている Chrome が古く、最適化が足りない --- タブが多いだけで、かなりメモリを消費します。タブを「閉じる」だけでなく、自動で休ませる設定が効きます。 Chrome 右上の [︙] → [設定] を開く 左メニューの [パフォーマンス] を選ぶ [メモリセーバー] をオンにする さらに、よく使うサイトがあるなら [常にアクティブにするサイトを追加] に

「自分のマイクだけDiscordで勝手にミュートされる」「通話には入れるのに相手に声が届かない」——そんなときの確認手順を、上から順にまとめます。 まず安心してください。ほとんどの場合は、入力デバイスの選択ミスか、Discord/OS側のマイク権限設定で直ります。 Discord内でマイクがミュート、または音声入力デバイスが違う Windows 11 24H2 / macOS Sequoia / iOS 18 側でマイク権限がオフ 通話の入力感度、ノイズ抑制、プッシュトゥトーク設定が合っていない BluetoothヘッドセットやUSBマイクの接続不良 Discordアプリやドライバーの不具合 --- Discordは、アプリ内で別のマイクを掴んでいるだけでも「声が聞こえない」状態になります。 通話画面の左下、または自分のアイコン付近にあるマイクアイコンが赤くなっていないか確認します。 赤い斜線が入っていたら、クリックしてミュートを解除します。 Discordで [ユーザー設定] → [音声・ビデオ] を開きます。 [入力デバイス] が、実際に使っているマ

Zoomで画面共有ができない、または「共有」ボタンが押せない状態は、だいたい「権限」「ホスト設定」「アプリ不具合」のどれかです。 上から順に試してみてください。ほとんどの場合、設定の見直しだけで直ります。 まずは、よくある原因を整理します。 参加者側の共有権限がオフになっている ホストが画面共有を制限している Zoomアプリのバージョンが古い Windows 11 24H2 / macOS Sequoia / iOS 18 の権限設定が足りない 一時的なアプリ不具合やキャッシュでボタンが反応しない --- 会議に参加しているだけの立場だと、ホスト設定で共有が止められていることがあります。 「共有」ボタンが灰色で押せないときは、まずここを疑いましょう。 1. Zoomミーティング中に、画面下部の[共有]ボタンを確認します。 2. 押せない場合は、ホストに「画面共有を許可してほしい」と依頼します。 3. ホスト側で、会議画面下部の[セキュリティ]を開きます。 4. [参加者に次を許可] の中にある **[画面共

外付けSSDをつないでもMacに出てこない、または開けても「読み取り専用」で保存できない状態を、順番に切り分ける手順です。 外付けSSDのトラブルは、ケーブル・給電・フォーマット・ディスクエラーのどれかで起きていることが多いです。 上から順に試してください。ほとんどの場合、基本の確認だけで改善します。 --- 1. ケーブルやUSBハブの接続不良 2. macOS Sequoia 15 / Sonoma 14 でディスクが正しくマウントされていない 3. SSDのフォーマットがMacと合っていない 4. ディスクの権限設定や「読み取り専用」状態になっている 5. SSD側のエラー、または物理的不調 --- 外付けSSDが認識しないとき、いちばん多いのがここです。 Step 1: SSDをいったん外し、Mac本体のUSB-Cポートに直接接続します。USBハブやドッキングステーションは一度外してください。 Step 2: 別のケーブルがあれば差し替えます。特に充電専用ケーブルだと認識しません。

PowerPoint for Microsoft 365 で動画が再生されない、またはスライド上の埋め込みメディアが黒画面になるときは、メディア形式・保存場所・アプリ側の再生設定を順に確認すると切り分けしやすいです。 上から順に試してください。ほとんどの場合、ファイル形式の不一致か、リンク切れ、PowerPoint 側の再生設定で直ります。 動画ファイルの形式やコーデック（= 圧縮方式）が PowerPoint と合っていない 埋め込みではなくリンク参照になっていて、元ファイルの場所が変わった PowerPoint for Microsoft 365 / PowerPoint 2024 の再生設定やアクセラレーション設定が影響している Windows 11 24H2 のグラフィック関連で黒画面が出ている macOS Sequoia の PowerPoint でメディア権限や埋め込み処理が不安定になっている --- PowerPoint は見た目が同じ動画でも、内部の形式が合わないと再生できません。 1. 動画ファイルをエクスプローラーで開き、拡張子を確認します。 例:

Zoomで相手の声は来るのに、スピーカーだけ無音になる症状が出たときは、まず「出力先」「ミュート」「OS側の音量」「Zoomのオーディオ設定」を順に確認しましょう。 Zoom内のスピーカー設定が別デバイスになっている Windows 11 24H2 / macOS Sequoia / iOS 18 側で音量や出力先が切り替わっている 会議中にスピーカーがミュート、または音量が0になっている Bluetoothイヤホンや外部ディスプレイに音声が逃げている Zoomアプリの設定ファイルやキャッシュが不調になっている 上から順に試してみてください。ほとんどの場合、最初の2〜3項目で直ります。 1. Zoom会議画面の下部で、[オーディオ] の右側にある ^ をクリックします。 2. [スピーカーを選択] で、今使っている出力先を選びます。 - 例: 「スピーカー（Realtek(R) Audio）」 - 例: 「MacBook Airのスピーカー」 3. そのまま [スピーカーのテスト] を押し、テスト音が鳴るか確認します。 4. 鳴らない場合

「Chromeでキャッシュを削除したはずなのに、前の表示のまま変わらない…」というときの対処法です。 Google Chrome（Windows 11 24H2 / macOS Sequoia 15 / iOS 18）でキャッシュを消しても反映されない場合、原因はだいたい決まっています。上から順に試してみてください。ほとんどの場合これで直ります。 削除したのが「キャッシュ」ではなく、履歴やCookieだけだった 削除範囲の時間指定が合っていない ページ側が強くキャッシュしている 拡張機能や別プロファイルが表示を引きずっている Chrome自体に一時的な不具合がある --- いちばん多いのがここです。削除画面でチェックを入れ忘れると、見た目は消したつもりでも反映されません。 1. Chromeを開きます 2. 右上の ︙ を押します 3. [閲覧履歴] → [閲覧履歴を消去] を開きます 4. 期間を [全期間] にします 5. [キャッシュされた画像とファイル] にチェックを入れます 6. 必要なら **[Cookie と他のサイトデータ

iPhoneをUSBでつないでも、Windows 11 24H2 や macOS Sequoia のパソコンで写真が表示されず、取り込みできない状態です。 まずは、よくある原因を先に整理します。上から順に試してください。ほとんどの場合これで直ります。 USBケーブルが充電専用、または断線しかけている iPhone側で「このコンピュータを信頼」が許可されていない iPhoneがロック中、または写真アクセスが制限されている Windows 11 24H2 / macOS Sequoia 側の写真取り込みアプリやドライバの不具合 iCloud写真や最適化設定の影響で、端末に原本がない --- USB認識しないとき、いちばん多いのがここです。 1. iPhoneをいったん外し、純正またはMFi認証のLightning/USB-Cケーブルでつなぎ直します。 充電だけできるケーブルでは、写真転送ができないことがあります。 2. USBハブを使っている場合は外して、PC本体のUSBポートへ直結します。 3. iPhoneをロック解除した状態で接続します。 4.

Discordで通話に入れず、「接続中」のまま止まる・終わるときは、たいてい「ネットワーク」「音声設定」「アプリの不具合」のどれかです。 上から順に試してみてください。ほとんどの場合これで直ります。 回線が不安定、またはVPN/プロキシが邪魔している Discord側の音声設定（入力・出力デバイス）が合っていない Windows 11 24H2 / macOS Sequoia / iOS 18 の権限設定でマイクが使えない Discordアプリのキャッシュや一時的な不具合 Discordサーバー側の障害や通話チャンネルの問題 --- 接続中のまま終わる症状は、ネットワークが原因のことがかなり多いです。 1. いったん Discord を完全に閉じます。 2. VPN、プロキシ、セキュリティソフトの通信制限を一時的にオフにします。 3. Wi‑Fi を切り替えるか、可能ならスマホのテザリングで試します。 4. ルーターを再起動します。 5. Discord を開き直して通話に入り直します。 ブラウザ版 Discord（Chrome / Edge）でも試すと切り分けしやすい

症状：PowerPointで発表者ツールが出ない、またはスライドショーが別画面に出ず崩れてしまう。 PowerPointの本番前にこれが起きるとかなり焦りますが、原因はだいたい限られています。上から順に試してみてください。ほとんどの場合、ここで直ります。 発表者ツールの設定がオフになっている 画面の表示先が「拡張」ではなく「複製」になっている 使っているプロジェクターや外部モニターの解像度・拡大率が合っていない PowerPoint側のスライドショー設定が崩れている アドインやOfficeの一時的な不具合が起きている --- PowerPoint for Microsoft 365 / PowerPoint 2024 / PowerPoint 2021 / PowerPoint for Mac 2024 で、まずここを見ます。 1. PowerPointを開き、[スライドショー] タブを選びます。 2. [発表者ツールを使用する] にチェックが入っているか確認します。 3. もし外れていたら、チェックを入れ直してスライドショーを開始します。 4. 画面が複数ある

Zoomに入ったのに自分だけカメラが黒画面で映らない、または相手に映像が届かないときは、たいてい「設定」「権限」「他アプリの占有」のどれかです。 上から順に試してみてください。ほとんどの場合これで直ります。 Zoom側でカメラが正しく選ばれていない Windows 11 24H2 / macOS Sequoia / iOS 18 のカメラ権限がオフ ほかのアプリがカメラを使っていてZoomに渡せない バーチャル背景やエフェクトが負荷になっている 端末側の一時不具合、またはZoomアプリが古い --- まずはZoomアプリ側の設定です。外付けカメラや仮想カメラがあると、意図せずそちらを掴んで黒画面になることがあります。 1. Zoom Workplace を開く 2. 右上の歯車アイコンから [設定] を開く 3. [ビデオ] を選ぶ 4. [カメラ] のプルダウンで、使いたいカメラを選ぶ 5. プレビューに自分の映像が出るか確認する 会議中なら、画面下の [ビデオの開始] の横にある ^ を押して、カメラ名を選び直してください。

セキュリティ研究チーム Calif が、Anthropic の「Mythos Preview」を使って macOS の脆弱性を見つけた Appleの新しい防御機能「Memory Integrity Enforcement (MIE)」を、M5搭載Mac上で回避する形の exploit が作られた チームいわく、AIの助けで「5日」で working exploit に到達した exploit は local user から root shell まで到達する、かなり強い権限昇格の攻撃チェーン ただし詳細な55ページのレポートは、Appleが修正を出すまで公開しない方針 これは「AIが防御を破る速度」と「Appleの防御の強さ」を同時に示す、なかなか象徴的な出来事だと思う 9to5Mac が伝えたのは、セキュリティ研究チーム Calif が、Anthropic の Mythos Preview を使って、macOS の実働する exploit（脆弱性を悪用するコード） を短期間で作れた、という話です。 しかもただの脆弱性発見ではなく、対象は **Apple の新し

Phosphene は、macOS Tahoe向けの動画壁紙エンジンです。 自分の MP4 / MOV などの動画を、デスクトップ壁紙やロック画面にできるのが売りです。 macOSの標準の壁紙ピッカーに統合されるので、見た目や使い方がかなり自然です。 ただし中身はかなり攻めていて、Appleのprivate framework に依存しているため、将来のOS更新で壊れる可能性があります。 電源状態や熱、バッテリー、ロック中かどうかに応じて再生を賢く切り替えるなど、かなり気の利いた設計になっています。 Phospheneは、ひとことで言うと「Macの壁紙を動画にするアプリ」です。 しかも単なる再生アプリではなく、macOSの壁紙機能そのものに食い込むタイプのソフトです。 普通、壁紙といえば静止画ですよね。でもPhospheneを使うと、手持ちの動画を壁紙として扱えます。しかもアプリ内だけで完結するのではなく、System Settings → Wallpaper の中に自分の動画がちゃんと並ぶ、というのが面白

Anthropicの新しい取り組み「Project Glasswing」で、Appleのような企業がAIを使って脆弱性を探せるようになった サイバーセキュリティ企業Califが、Claude Mythos Previewを使ってmacOSの新たな脆弱性を発見した 見つかったのは、2つのmacOSのバグを組み合わせて権限を上げる「privilege escalation exploit」 ただし、AIだけで自動的に完成したわけではなく、人間の専門知識が必要だった Appleは報告を確認中で、すでに修正済みかは記事時点でははっきりしていない MacRumorsが伝えたのは、AIがmacOSの脆弱性発見に実際に役立ったという話です。 しかも「AIがすごいらしい」というふわっとした話ではなく、サイバーセキュリティ企業が実際に脆弱性を見つけ、Appleがその報告を受けたという、かなり現実的なニュースです。 今回のきっかけになったのは、Anthropicが発表した Project Glasswing。 これは、Appleのような企業がAnthropicの新しいAIモデル *

Califが、Apple M5搭載Mac上で動くpublicなmacOS kernel memory corruption exploitを公開 対象は macOS 26.4.1 (25E253)、unprivileged local user から root shell まで到達する local privilege escalation Appleの新しい防御機構 MIE (Memory Integrity Enforcement) を有効にした bare-metal M5 hardware 上で動作したとされる バグ発見から、わずか数日でworking exploitに到達したというのがかなり衝撃的 ただし、技術詳細はAppleの修正後に公開予定で、現時点では攻撃の全容は明かされていない 今回の話をひとことで言うと、「Appleが何年もかけて強化してきた防御を、実機M5上で突破するmacOS kernel exploitが公開された」というニュースです。 元記事の著者Califによれば、Apple ParkでA