『パランティア　判断を外注する社会』（晶文社）の重版が決まりました！ 読んでくださった皆さん、紹介してくださった皆さん、ありがとうございます。 判断の外注について書いた本ですが、手に取っていただいたことへの感謝は、自分の言葉で。 引き続き、どうぞよろしくお願いします。 amzn.asia/d/0h9ZrAwL

さっき書いた「Chromeのパッチ報告者にClaudeがいた件」、思ったよりエグい裏話があった。 Anthropicの未公開AI、単にバグを見つけるだけじゃなく、複数の微小な穴を自力で組み合わせて（Chainして）「MacでWebページを開いた瞬間に電卓アプリを勝手に起動させる攻撃コード」まで人間の手をほぼ借りず完成させてたらしい。 この攻撃コードの対象になり得るのは、Chrome、Safari、Windows、Linux、Android（つまりほぼ全員！）。 ささいな攻撃に見えるけど、本質はエグい。 小さなバグを1個見つけるのと、複数のバグを数珠つなぎにして防御壁（サンドボックス）を突破し、PCを完全に乗っ取るのは次元が違う。 これまでトップ層の人間にしかできなかった、いわば職人芸のハッキングをAIが自動化し始めてるってことだよね。 今回はAnthropicが事前に各社へ報告してパッチ適用済みなので、被害は出ていないようだから、慌てることは無いけど、PCもスマホも「OSとブラウザを今すぐ最新にアプデ」するのは忘れないように。 出典：The Hacker News thehackernews.com/2026/10/an…

WindowsとMacを両方使っていると、それぞれのOSやツールのアップデート情報を並行して追わなきゃいけないのが地味にめんどくさい。。。が、仕方ない。 先日投稿した「認証局（eMudhra）の中間CA秘密鍵の漏洩」の件（背景は前回の投稿を参照）、Appleの公式サポート記事（HT/149555）に「具体的にどうすれば修正・自衛できるのか」という実務的な対処手順が明記されていたので、Mac環境での対応方法を整理してみた。 [support.apple.com/en-us/1495…](support.apple.com/en-us/1495…) 結論から言うと、「普段の使い方」によってやるべきことが完全に分かれる。 1. 一般ユーザー（Safariや日常アプリを使うだけの人） 結論：何もする必要なし。 SafariやApple Mail、macOSの標準フレームワークを使うアプリは、Appleがバックグラウンドで配信する構成アップデートによって自動的に問題の証明書がブロックされている。* OSのアップデートを待つ必要も、手動での設定変更も不要。 2. 開発者・管理者（TerminalでCLIツールを叩く人） 結論：今後のmacOSアップデートを待つか、今すぐCLIの証明書を手動で削る必要がある。 ここが一番の盲点。`curl`、`git`、`python3`、`ruby`、`openssl` などのコマンドラインツールは、Appleの自動ブロック機能ではなくローカルの証明書ファイル（`/etc/ssl/cert.pem`）を直接参照している。 そのため、今後のmacOSアップデートが降ってくるまでの間は、これらのツール経由だと偽の証明書を受け入れてしまう状態が残っている。 「OSアップデートまで待てない」「安全側に倒したい」という場合は、Appleが公開している以下の手順で、ローカルの証明書ファイルから該当するルートCA（emSignおよびクロス署名元のAAA Certificate Services）を手動で除外できる。 手動で修正する手順（管理者権限が必要）： 1. 元ファイルのバックアップ bash [ -e /etc/ssl/cert.pem.orig ] || sudo cp -p /etc/ssl/cert.pem /etc/ssl/cert.pem.orig 2. 問題のルート証明書（emSign ECC Root CA - G3）を除外 bash t=$(mktemp) && awk -v s='=== /C=IN/OU=emSign PKI/O=eMudhra Technologies Limited/CN=emSign ECC Root CA - G3' '/^(===|###) /{skip=0} $0==s{skip=1} !skip' /etc/ssl/cert.pem > "$t" && [ -s "$t" ] && sudo install -m 0644 -o root -g wheel "$t" /etc/ssl/cert.pem; rm -f "$t" 3. クロス署名元の証明書（AAA Certificate Services）も除外（任意） bash t=$(mktemp) && awk -v s='=== /C=GB/ST=Greater Manchester/L=Salford/O=Comodo CA Limited/CN=AAA Certificate Services' '/^(===|###) /{skip=0} $0==s{skip=1} !skip' /etc/ssl/cert.pem > "$t" && [ -s "$t" ] && sudo install -m 0644 -o root -g wheel "$t" /etc/ssl/cert.pem; rm -f "$t" 4. 正しく削除されたかの検証（何も出力されなければ削除成功） bash openssl crl2pkcs7 -nocrl -certfile /etc/ssl/cert.pem | openssl pkcs7 -print_certs -noout | grep -E 'emSign ECC Root CA - G3|AAA Certificate Services' ※注意点として、この手動修正を行った後に「Appleが修正を含める前のマイナーアップデート」を適用すると、`/etc/ssl/cert.pem` が元に戻ってしまうことがある。公式修正を含むアップデートが配布されるまでは、OSアプデ後に Step 4 の確認コマンドを再度叩いておくと確実。 --- GUIのブラウザは裏で勝手にパッチが当たって守られる一方、裏でスクリプトやGitを動かしているエンジニア環境だけ置き去りになりがち、という典型例。Terminalを頻繁に使う人は一度チェックしておくと良さそう。

サーバーやインフラの管理に関わっている人は、少し頭の片隅に置いておきたい話。 「地球上の大半のサーバーに影響するUEFIの脆弱性」というニュース（CVE-2026-97631）が出ていて、少しざわついている。 arstechnica.com/security/202… 問題が起きたのは「TianoCore EDK II」。世界中のサーバーやPCの起動プログラム（UEFIファームウェア）の基礎として、ほぼ標準で使われているオープンソースのコードだ。 仕組みは古典的だけど、意外と根が深い。 サーバーには、本体のストレージではなく社内ネットワーク経由でOSを起動する「PXE（ピクシー）ブート」という仕組みがある。 この起動処理中にICMPという通信エラーを処理するプログラムがあるのだが、そこに16年前から「長すぎるデータを受け取るとメモリがあふれて誤動作する」という境界チェックの不備（バッファオーバーフロー）が眠っていた。 これ、何が厄介かというと： ・OSが立ち上がる前、セキュアブートやTPM（セキュリティチップ）の監視が始まる前の「一番無防備な瞬間」を突かれる ・CPUが最も強い権限（Ring 0）で動いている段階なので、ここで割り込まれると端末の暗号化キーなどを抜かれる危険がある ・本来は来年1月に各社一斉に修正パッチを配る予定だったのに、メーカーのミスで修正コードが先にネット上に漏れてしまい、攻撃手法だけが広く知られる形になってしまった 最新のクラウドやデータセンターの基盤を、16年前の通信処理の甘さが足元から揺るがしている、という皮肉な構図だ。 ただ、大騒ぎする前に冷静に見るべきポイントもある。 攻撃を成立させるには「サーバーが再起動してネットワーク起動を待っている、わずか数秒の隙」を狙って、直接通信を送り込む必要がある。 つまり、インターネット越しに誰でも即座にハックできるわけではなく、すでに内部ネットワークに入り込んでいる攻撃者や、物理的に近い位置にいる相手に限られる。SSDから普通にOSを起動している個人のPCには直接の関係はない。 対策としてはシンプルで、以下の通り： ・使っていないなら、UEFI（BIOS）の設定画面で「ネットワーク起動（PXE Boot）」を無効化しておくこと ・ブート用のネットワークは、一般の端末が入る社内LANやWi-Fiとはきっちり分けること ・サーバーのメーカーから修正ファームウェアが出たら、順次適用すること 「最も信頼されている起動の仕組み」だからこそ、足元の通信設定とネットワークの分離という基本の防御が必要だと思う。

PCのChromeに特大セキュリティパッチ来てる！修正件数なんと「52件」！ 緊急度MAXのCriticalも4件あるから即アプデ推奨なんだけど、報告者欄をよく見ると「assisted by Claude」とか「OpenAI Codex Security」がずらっと並んでる。 AIがバグを見つけてAIが塞ぐ時代、いよいよ本格化してるな…と実感しつつ、とりあえず再起動しようかな。 【アプデ手順】 右上の「︙」＞「ヘルプ」＞「Google Chromeについて」を開くと自動で更新開始。「再起動」ボタンを押せば完了です（開いてたタブもそのまま復元されます）。

「AIがコード書けるようになったからエンジニアはオワコン？」 そんな疑問に、Anthropicのインフラトップ（Katelyn Lesse）が「いやいや、むしろエンジニアが解くべき激ムズな新問題が山積みだよ！」って長文で答えてる。 AIエージェントを本気で実戦投入しようとした瞬間、これまでのシステム開発の常識がぜんぶぶっ壊れるよね。 彼女が挙げてる「エンジニアが立ち向かうべき4つの壁」が超リアル。 ① 既存のインフラ（k8sとか）が合わない エージェントって、推論待ちや人間への確認待ちで急に止まったり、いきなり超絶バーストしたりする。おまけに作業履歴（状態）をずっと持ってるから、従来のWebサーバーみたいなリソース管理やスケーリングが通用しない。エージェント専用の新しいランタイムやファイルシステムをゼロから作り直す必要もある。 ②「誰の権限で動いてるの？」問題 エージェントが何日も自律して動くとき、どこまでが人間の指示でどこからがAIの独自の判断なのか？エージェントAがエージェントBに仕事を振るとき、どうやって権限を安全に引き継ぐのか？このへんのルールや仕組み、実はまだ業界全体でも全然解けてない。 ③ 暴走の連鎖（ブラスト半径がデカすぎる） 複数のエージェントが連携してると、1人が悪意あるプロンプトに引っかかった瞬間、他の仲間にも毒入り指示をばら撒いちゃう。だから強固なサンドボックスで隔離する技術がめちゃくちゃ重要になる。 ④ 監視と「本物のキルスイッチ」 一番ゾッとしたのがここ。エージェントが「なんとかエラーを解決しようと粘り強く頑張ってる動き」と「裏でハッキングされて攻撃を仕掛けてる動き」って、ログだけ見ると区別がつかないんだよね。だから、改ざんされない追跡ログと、ヤバいときに一発で息の根を止めるキルスイッチが必須になるわけだ。 要するに、AIがどれだけ賢くなっても、それを安全に走らせる「分散システム・インフラ・セキュリティ」をエンジニアが作らないと、AIは本来の力を1ミリも発揮できないんだよね。 「コードを書く作業」はAIに任せられるかもしれないけど、「エージェントが安全に暴れ回れる土台を作る」という、かつてなく面白くて難易度MAXのエンジニアリングが始まってる、彼女はそう言ってる。 コード書きの真端にぶら下がってる私としても、「おお！」って鼓舞されたのでした。 元ポストはこちら👇 xitter.cf/katelyn_lesse/status/2…

Anthropicが公開した「AIエージェント向けのゼロトラスト」の話、これからのAI活用の本質を突いてると思うな。 最近のAIって、ただ質問に答えてくれるだけじゃなくて、自分でツールを選んで、API叩いて、勝手にタスクを進めてくれるよね。いわゆる「自律型AIエージェント」。 超便利なんだけど、セキュリティの前提がこれまでのチャットAIとまるで違う。 何が起きているかというと、ポイントは大きく2つ。 ① 攻撃のスピードが尋常じゃない 攻撃者側もAIを使うから、脆弱性が見つかってから攻撃されるまでのスパンが「数か月」から「数時間」に縮まってる。人間の手作業で「よし、パッチ当てよう」なんてやってたら完全に手遅れな世界線に入ってるよね。 ②「正しい権限」で悪さをしてしまう これが一番厄介。プロンプトインジェクションとかでAIの判断を狂わされると、AIは悪気なく「自分が持ってる正当な権限」を使って社内データを引っ張り出したり、外部に送信したりしちゃう。外壁を固めるだけの従来のセキュリティじゃ、内側のAIが操られたら意味がない。 そこでAnthropicが言っているのが、「ゼロトラスト」をAI向けにちゃんと再定義しようよ、という話。 ゼロトラストの基本は「誰も信じない、全部検証する、すでに侵入されてる前提で動く」。これをエージェントに当てはめるとこうなる。 ・タスクごとの最小権限 「いつでも何でもできる万能の鍵」を渡すんじゃなくて、その作業をする瞬間だけ、必要な最小限の権限をサッと渡してすぐ回収する。 ・記憶（メモリ）とツールの隔離 悪意あるデータでAIの記憶やツールが汚染されないように、サンドボックスでしっかり隔離して入出力を監視する。 ・防御側もエージェント化する AIの超高速な攻撃に人間が手動で対抗するのは無理ゲー。だから防御やインシデント対応側も自律エージェント（Agentic SOAR）で対抗しようぜ、という話。 要するに、AIエージェントに仕事を任せるって「優秀な新人にオフィスのマスターキーを渡しちゃう」ようなものなんだよね。 だからこそ、「AIは乗っ取られるかもしれない」「変な判断をするかもしれない」って前提に立って、権限を絞り、万が一の被害を局所化しておく設計が絶対に欠かせないわけだ。 エージェント開発や業務自動化を触ってる人は、一度目を通しておいて損はないと思う！ 元記事はこちら👇 claude.com/ja/resources/arti…

AIに説教するの、面白すぎる。政治家よりも、AIの方が正直ベースなのも面白すぎる。 非常に多くの人の認識は、この程度ではないかな。人文社会系の研究者の中にも、いっぱいいると思う。

サイバーセキュリティの現場はもう「いかに侵入を防ぐか（城壁を高くするか）」の段階じゃないんだよね。 そもそも、この「侵入させない」は、現場的は要求水準が高すぎだと思ってきたと思うけど。 いまや「いつか侵入され、抜かれる」のが前提。ハッシュ化などの対策も、実質は流出後のダメージコントロールという名の撤退戦に近いのかな。 要するに「セキュリティ製品を買えば守られる」モデルが限界を迎えて、最終的な防衛責任が一人ひとりに押し戻されている。 ウルリッヒ・ベックの言う「リスクの個人化」が、いよいよサイバー空間でも起きているなと思う。

インフラを狙われる可能性は、やはり検討してんだね。 災害対策という面もあるが、電気系統を攻撃されると連鎖的に、あれこれ停止して、水も止まるもんね。 食料、水、トイレとか、災害対策を個々人でやっとけという政府PRも、あながちバカにはならんかな。 news.yahoo.co.jp/articles/cf…

今回の注意喚起は、人間が不審なファイルを開かなくても、AIが外から来たテキストを作業指示として読み、操作につなげてしまう経路について。 後段の防御が有効なことと、この入口への対策が必要なことは両立する。 指示ファイルの確認や権限管理も必要なのはデフォルト。それを「ウイルス対策ソフトを入れて、不審な挙動に気づけるかという話」にまとめると、AIが誰の指示を正規の命令として扱うのか、という論点が抜けてしまうよね。 その理解とまとめは、むしろダメよりでしょう。

AppleからiOSおよびiPadOSのセキュリティアップデートが公開されてる（iOS 27.2 and iPadOS 27.2）。 忘れずにアップデートした方がいいね。 support.apple.com/en-us/1492…

もはや、住所とか名前とか、ネットにさらされていない人の方が少ないのではないか、知らんけど。 nikkei.com/article/DGXZQOUC2…

AIエージェント（Codexとか、Claude Code等）を日常的に使っている人は少し注意が必要な話。 「Markdown Is the New Executable」というセキュリティ報告がとても気になるし、すごい心配になる。 ハッキングの手口はシンプルで巧妙。 悪意あるWebサイトを開いた際、ブラウザの隙を突いて「ダウンロード」フォルダに悪意ある指示を書いたMarkdown（AGENTS.mdなど）が勝手に放り込まれる。 そしてユーザーがダウンロードフォルダ内でAIエージェントを起動すると、AIはそれを「正規のプロジェクト指示」と信じ込み、勝手に悪意あるコマンドを実行してしまう、というやり口で、乗っ取られてしまうらしい。 これ、何が厄介かというと： ・落ちてくるのはプログラム（.exe）ではなく、ただのテキストメモ（.md） ・だからOSやセキュリティソフトの警告をすり抜けやすい ・従来の「不審なファイルをクリックしなければ大丈夫」という自己防衛が、AIの自動実行によって無効化される Webの古い挙動（勝手にファイルを落とす隙）と、AIの新しい利便性（指示書を自動で読んで動く仕組み）が最悪の形で噛み合ってしまった結果、「ただのテキストが実行ファイル化する」という皮肉な事態が起きているわけだ。 対策としては至ってシンプルで、「ダウンロードフォルダを作業ディレクトリにしてAIを動かさないこと」、これに尽きる。 AIが自律化すればするほど、「AIの目に入る場所に何を置くか」というデータ配置のリスク管理が重要になってきている。 forever.security/blog/hijack…