Tech News JP

Azure Arc対応AKSのWindows Server 2019、本日をもってサポート終了 Microsoftは2026年4月1日をもって、Azure Arc対応AKS（Kubernetes Service）におけるWindows Server 2019ノードのサポートを正式に終了した。これにより、Windows Server 2019ベースのノードイメージの新規提供およびセキュリティパッチの配信が停止される。 影響範囲と具体的なリスク 今回の変更で最も注意が必要なのは、Kubernetesバージョンのアップグレード可否に直結する点だ。Windows Server 2019のノードが残存しているクラスターでは、今後のKubernetesバージョンアップグレードが実行不可能になる。セキュリティパッチが適用されないノードを抱えたまま本番環境を運用し続けることは、コンプライアンス上のリスクはもちろん、実際の攻撃面の拡大にもつながる。 オンプレミスやエッジ環境にKubernetesクラスターを展開するためにAzure Arc対応AKSを活用している企業にとって、この変更は看過できない。特に、Windows向けコンテナワークロードを運用している環境では早急な対応が求められる。 移行先：Windows Server 2022 Microsoftが推奨する移行先はWindows Server 2022だ。Windows Server 2022はメインストリームサポートが2026年10月まで、延長サポートが2031年10月まで提供される予定であり、今後数年間の安定した運用基盤として選択できる。 移行の基本的な手順は以下の通りだ： 既存のWindows Server 2019ノードプールの棚卸し Windows Server 2022イメージを指定した新規ノードプールの作成 ワークロードの段階的な移行（drain & cordon） 旧ノードプールの削除 なお、LinuxノードのみのクラスターはKubernetesのバージョンアップグレードに影響を受けない点も確認しておきたい。 日本企業への影響 国内では製造業や流通業を中心に、Azure Arc対応AKSをオンプレミス・エッジ環境のコンテナ基盤として採用するケースが増加している。既にWindows Server 2019を使用中のクラスターを持つ組織は、本日以降のセキュリティパッチが提供されない状態にあることを認識した上で、速やかに移行計画を策定・実行する必要がある。 移行作業を先送りにするほど、脆弱性の累積とアップグレード対応の複雑化が進む。Microsoftの公式ドキュメントと移行ガイドを参照しながら、計画的な対応を進めてほしい。 元記事: Windows Server 2019 Retirement on AKS enabled by Azure Arc

Microsoft 365、2026年7月から商用ライセンスを値上げ Microsoftは2026年3月24日、商用向けMicrosoft 365スイートのパッケージおよび価格改定を発表した。新価格は2026年7月1日より全世界で適用され、既存顧客は7月1日以降の次回更新時から影響を受ける。 値上げの背景 Microsoftは今回の改定について、「過去数年間で大幅に拡充したAI・セキュリティ・IT管理機能の価値を価格に反映するもの」と説明している。具体的に追加される機能の例として、以下が挙げられている。 AI: Copilot Chat、Copilot Chat Analytics セキュリティ: Microsoft Defender for Office 365 Plan 1 IT管理: Intune Suite（Remote Help、Advanced Analytics、Plan 2、Privilege Management、Microsoft Cloud PKI、Application Managementを含む） これらの新機能は2026年第3四半期（CY26 Q3）から順次ロールアウトが始まり、2026年8月1日までに展開完了予定。テナントへの適用前には30日前にメッセージセンターで事前通知が行われる。 対象製品 価格改定の対象となる主な製品は以下の通り。 カテゴリ 製品 エンタープライズ Office 365 E3/E5、Microsoft 365 E3/E5、EMS E3/E5、Windows E3/E5 ビジネス M365 Business Basic/Standard、Apps for Business フロントライン M365 F1/F3 政府向け M365 G3/G5、GCC F1/F3、Office 365 G1/G3 スタンドアロン Microsoft 365 Apps、Entra P1/P2、Per Device SKU なお、今回の発表はTeams分離SKU（Teamsあり／なしのSKU分割）とは別の施策であることが明記されている。 企業への影響 日本国内でも多くの企業がMicrosoft 365を基盤として採用しており、ライセンスの更新スケジュールや予算計画への影響は避けられない。特にエンタープライズ契約を持つ組織は、7月1日以降の更新タイミングを早めに確認し、コスト試算を見直しておくことが推奨される。 具体的な値上げ幅は製品・地域ごとに異なり、Microsoftの公式価格表で確認できる。新機能の追加と引き換えとはいえ、既にDefenderやIntuneをアドオンで購入している組織では費用対効果の再評価が必要になるケースもありそうだ。 ...

Hugging Face、ポストトレーニングライブラリ「TRL v1.0」正式リリース Hugging Faceは、大規模言語モデル（LLM）のポストトレーニングに特化したPythonライブラリ「TRL（Transformer Reinforcement Learning）」のバージョン1.0を正式リリースした。 TRLとは TRLは、事前学習済みの言語モデルに対して人間のフィードバックや強化学習を用いて追加学習を行うためのライブラリだ。ChatGPTのような対話AIを作る際に不可欠な「RLHF（Reinforcement Learning from Human Feedback）」の実装を手軽に行える点が特徴で、Hugging FaceのTransformers・Accelerate・PEFTといったエコシステムとシームレスに統合されている。 v1.0での主な変更点 今回のv1.0は、ここ数年で急速に発展したポストトレーニング手法の多様化に対応するため、ライブラリの設計思想そのものを見直した節目のリリースとなっている。 もともとTRLはPPO（Proximal Policy Optimization）アルゴリズムを中心に設計されたライブラリだった。PPOは2017年にOpenAIが発表した強化学習アルゴリズムで、LLMの対話能力を向上させるRLHFの中核として長らく使われてきた。 しかし近年、DPO（Direct Preference Optimization）やGRPO（Group Relative Policy Optimization）など、PPOと比較してより軽量・安定したポストトレーニング手法が次々と登場した。特にDPOはreward modelを別途学習する必要がなく、実装の手軽さから研究・開発現場での採用が急速に広まっている。GRPOはDeepSeek-R1の学習にも採用されたことで日本国内でも注目を集めている手法だ。 v1.0ではこうした新手法への対応を強化しつつ、「フィールドの進化についていける」設計に刷新されており、今後登場する新しいアルゴリズムにも柔軟に対応できるアーキテクチャが採用されている。 日本の開発者への影響 国内でも、LLMのファインチューニングや独自チャットボット開発に取り組む企業・研究機関が増加している。TRLはHugging Faceのエコシステムに乗っているため、すでにTransformersを使った開発を行っているチームであれば導入コストは低い。 GPUリソースが限られる環境向けに、PEFTによるLoRAとの組み合わせも公式でサポートされており、コンシューマグレードのGPU（例：RTX 4090など）でもLLMのRLHFが現実的に実行できる点は、中小規模の開発チームにとって大きなメリットだ。 入手方法 TRL v1.0はPyPIで公開されており、以下のコマンドでインストールできる。 元記事: TRL v1.0: Post-Training Library Built to Move with the Field

IBMが企業向け軽量マルチモーダルモデル「Granite 4.0 3B Vision」を公開 IBMは、企業向け文書処理に特化した小型マルチモーダルAIモデル「Granite 4.0 3B Vision」をHugging Faceで公開した。約4Bパラメータという比較的コンパクトなサイズながら、画像とテキストを組み合わせて処理する「Image-Text-to-Text」タスクに対応しており、企業現場での実運用を強く意識した設計が特徴だ。 「小さく、賢く、使いやすく」——企業ユースケースへの最適化 Granite 4.0 3B Visionは、IBMのGraniteシリーズの最新世代にあたる。Graniteシリーズはもともとエンタープライズ向けに設計されており、コードベース解析や業務文書の要約・抽出など、実務に直結するユースケースへの対応を重視してきた。 今回のVisionモデルはその路線をマルチモーダル領域へと拡張したもので、請求書・契約書・技術図面といった「画像として届く企業文書」をそのまま読み解く能力を持つ。GPT-4oやGemini 1.5 Proなどの大規模モデルと同等の文書理解タスクを、はるかに少ないリソースで処理できる点が企業導入のハードルを下げると期待されている。 軽量モデルが注目される背景 生成AI活用が本格化するにつれ、クラウド経由のAPI利用ではなくオンプレミスやプライベートクラウドでの自前運用を求める企業が増えている。特に金融・医療・法務といった機密性の高い業種では、データを外部サービスに送信することへの抵抗感が強い。 3〜4Bクラスのモデルであれば、高性能GPUを大量に用意しなくても動作するケースが多く、既存のサーバーインフラへの統合が現実的になる。IBMがあえてこのサイズ帯でVisionモデルを投入した背景には、こうした「現場で動かせるAI」への需要がある。 オープンウェイトでの公開——透明性と再現性の担保 Granite 4.0 3B VisionはHugging Face上でウェイトが公開されており、研究者や開発者が自由にダウンロードして利用・評価できる。IBMはGraniteシリーズのトレーニングデータや使用許諾についても比較的透明性の高い情報開示を行っており、企業が導入審査を行いやすい点も強みのひとつだ。 公開からわずか約14時間で1,200件超のダウンロードを記録しており、エンタープライズAIコミュニティからの注目度の高さがうかがえる。 日本企業への示唆 日本では紙文書や複合機からスキャンしたPDFが業務の主役であり続けており、「画像として存在する文書」を自動処理するニーズは特に高い。Granite 4.0 3B Visionのような軽量マルチモーダルモデルは、DXを推進したい中堅・大企業にとって現実的な選択肢となりそうだ。IBM Japanを通じた商用サポートの提供も今後期待される。 元記事: Granite 4.0 3B Vision: Compact Multimodal Intelligence for Enterprise Documents

Axiosにサプライチェーン攻撃——週間1億ダウンロードのHTTPクライアントが標的に 2026年3月31日、JavaScriptエコシステムで広く使われているHTTPクライアントライブラリ「Axios」が、npmを通じたサプライチェーン攻撃の被害を受けたことが明らかになった。Axiosは週間1億100万ダウンロードを誇る超メジャーパッケージであり、その影響範囲は計り知れない。 何が起きたか 今回の攻撃では、Axiosのバージョン 1.14.1 および 0.30.4 に、plain-crypto-js という新しい依存パッケージが追加された。この plain-crypto-js はその日に新規公開されたマルウェアであり、認証情報の窃取とリモートアクセス型トロイの木馬（RAT）のインストールという二段構えの悪意ある機能を持っていた。 このようなサプライチェーン攻撃は、ユーザーが直接マルウェアをインストールするわけではなく、信頼するライブラリの依存関係として自動的に引き込まれる点が特に危険だ。Axiosのような信頼性の高いパッケージへの混入であれば、多くの開発者がセキュリティチェックをすり抜けてしまう可能性がある。 攻撃の手口：流出したnpmトークン 調査の結果、攻撃者は有効期限のない長期npmトークン（long-lived npm token）の流出を悪用してパッケージを公開したとみられている。 AxiosのGitHubリポジトリには、Trusted Publishing（信頼済み公開）の採用を求めるIssueがすでに存在している。Trusted Publishingを導入すると、npmへの公開をGitHub Actionsのワークフローからのみに制限できるため、今回のような不正なトークン悪用を防ぐことができる。 見分けるためのヒント：GitHubリリースのないnpm公開 セキュリティ研究者のSimon Willisonは、今回の攻撃に際して興味深い観察を共有している。 「悪意ある公開パッケージには、対応するGitHubリリースが存在しない」 このパターンは、先週発覚したLiteLLMへのサプライチェーン攻撃でも同様に確認されており、不審なリリースを見つけるための有効な経験則になりうるという。npmでパッケージが更新された際、GitHubのリリースタグと照合する習慣をつけることが、今後のサプライチェーンリスク低減につながる。 日本の開発者へ AxiosはNext.js、Nuxt、React、Vue.jsなど日本でも広く使われているフレームワークのプロジェクトで標準的に採用されている。package-lock.json や yarn.lock を確認し、1.14.1 または 0.30.4 を使用している場合は即座にバージョンを変更することが推奨される。また、plain-crypto-js への依存が混入していないかを npm ls plain-crypto-js で確認するのも有効だ。 オープンソースのサプライチェーンへの攻撃は近年急増しており、今回の事例はその深刻さを改めて浮き彫りにしている。 元記事: Supply Chain Attack on Axios Pulls Malicious Dependency from npm

SalesforceがSlackを全面AI強化——30の新機能を一挙発表 クラウドソフトウェア大手のSalesforceは、サンフランシスコで開催した少人数向けイベントにおいて、ビジネスチャットツール「Slack」の大規模アップデートを発表した。CEOのマーク・ベニオフ氏が自ら登壇し、AI機能を中心とした30の新機能を披露。Slackを単なるコミュニケーションツールから、企業の業務プロセスを一手に担う「AIエージェント基盤」へと位置づけ直す狙いが鮮明になった。 再利用可能な「AIスキル」が業務を自動化 今回の発表で最も注目を集めたのが、再利用可能なAIスキル（Reusable AI-Skills）だ。ユーザーがSlackbotに対して特定のタスクをあらかじめ定義しておくことで、さまざまな場面で繰り返し呼び出せるようになる。 たとえば「イベントの予算を作成して」とSlack上でコマンドを入力するだけで、Slackbotが関連するチャンネルや連携アプリのデータを自動的に収集・整理し、実行可能なプランを生成。さらに、職種をもとに関係する社員を自動で特定してミーティングを設定するところまでを一気に処理する。 SalesforceによればSlackbotには標準のスキルライブラリが組み込まれており、ユーザーが独自のカスタムスキルを作成することも可能だ。繰り返し発生する定型業務の大幅な効率化が期待される。 MCPクライアント対応でエンタープライズ全体と連携 Slackbotは今回のアップデートでMCP（Model Context Protocol）クライアントとしての機能も備えた。MCPは外部サービスやツールとAIエージェントをつなぐプロトコルで、近年さまざまなAIプラットフォームが採用を進めている。 この対応により、Slackbotは2024年にSalesforceが立ち上げたAIエージェント開発プラットフォーム「Agentforce」とも連携可能になった。社内のあらゆるエージェントやアプリへ作業を振り分け、人手を介さずに最適な処理ルートを自律的に判断するという。 会議の文字起こし・要約、デスクトップ監視も Slack暫定CEOのロブ・シーマン氏によれば、Slackbotはミーティングのリアルタイム文字起こしと要約にも対応。途中で集中が途切れてしまった参加者も、Slackbotに「自分のアクションアイテムをまとめて」と依頼するだけで必要な情報をすぐに確認できる。 さらに、Slackの外部でユーザーのデスクトップ操作を監視し、商談・会話・カレンダー・行動パターンなどを分析した上で、次の行動を提案したりフォローアップのメッセージを自動起草したりする機能も追加される。プライバシー保護の仕組みも内包されており、ユーザーが権限設定を細かく調整できるとしている。 「Slack買収から5年」——AIで再定義を狙う SalesforceがSlackを277億ドルで買収したのは2021年のこと。ベニオフCEOは今回の基調講演で、その5年間を振り返りながら「Slackを企業の中核業務に欠かせないプラットフォームにする」という意気込みを示した。 日本企業にとっても、Slackはすでに多くの開発・IT部門で利用されている馴染み深いツールだ。今回のAI強化によって、チャットの枠を超えた業務自動化の基盤として活用できるかどうか——実際の使い勝手が問われることになる。新機能は今後数ヶ月以内に順次提供される予定だ。 元記事: Salesforce announces an AI-heavy makeover for Slack, with 30 new features

LiteLLMへの不正コード混入が大規模被害に発展 AI採用スタートアップのMercorは、オープンソースプロジェクト「LiteLLM」を標的にしたサプライチェーン攻撃に起因するセキュリティインシデントを公式に認めた。同社はTechCrunchの取材に対し、今回の被害は「数千社に及ぶ影響企業のうちの1社」であると述べた。 ハッキング集団が攻撃への関与を宣言 今回の侵害には、TeamPCPと呼ばれるハッキンググループが関与しているとされる。また、悪名高い恐喝目的のハッキング集団**Lapsus$**もMercorへの攻撃と同社からのデータ取得を自ら名乗り出ており、リークサイトにはSlackのデータやチケット管理データ、さらにMercorのAIシステムとコントラクターのやり取りと思われる動画2本を含むサンプルデータが掲載された。ただし、Lapsus$がTeamPCPのサイバー攻撃経由でMercorのデータを入手した経緯の詳細は現時点では不明だ。 Mercorとは — OpenAIやAnthropicとも連携するAI採用企業 2023年創業のMercorは、OpenAIやAnthropicなどを顧客とし、AIモデルの訓練用データ収集のためにインドなどの市場から科学者・医師・弁護士といった専門家をコントラクターとして仲介するAI採用プラットフォームだ。1日200万ドル（約3億円）以上の報酬支払いを仲介しており、2025年10月にはFelicis Ventures主導の3億5,000万ドル（約530億円）のシリーズCラウンドで評価額100億ドル（約1.5兆円）に達したことでも注目を集めている。 Mercorの広報担当Heidi Hagberg氏は「インシデントの封じ込めと復旧に速やかに対処した。大手サードパーティのフォレンジック専門家を起用した徹底的な調査を進めており、顧客・コントラクターへの直接連絡も継続している」とコメントした。一方で、Lapsus$との関連性や顧客データの流出有無については回答を拒否した。 LiteLLMとは — 1日数百万ダウンロードの人気ライブラリ LiteLLMは、OpenAI・Anthropic・Geminiなど複数のLLM（大規模言語モデル）APIを統一インターフェースで呼び出せる人気のOSSライブラリで、Y Combinator支援のスタートアップが開発している。セキュリティ企業Snykによれば1日あたり数百万回ダウンロードされており、企業のAIシステムに広く組み込まれている。 今回の問題は先週、LiteLLMの関連パッケージに悪意あるコードが混入しているのが発見されたことで発覚した。コードは数時間以内に特定・除去されたものの、LiteLLMの普及度の高さからその影響範囲が注目されている。この件を受けてLiteLLM側もコンプライアンス対応を見直し、セキュリティ認証の取得パートナーを物議を醸していたスタートアップ「Delve」から「Vanta」に切り替えた。 サプライチェーン攻撃のリスクが再び顕在化 今回の事例は、AIシステムの基盤となるOSSライブラリへの不正コード混入という「ソフトウェアサプライチェーン攻撃」の脅威を改めて示している。依存ライブラリのセキュリティ管理は、AIスタートアップに限らず、OSSを活用するすべての企業にとって重要な課題となっている。影響を受けた企業の全体数やデータ流出の実態については、現在も調査が続いている。 元記事: Mercor says it was hit by cyberattack tied to compromise of open-source LiteLLM project

Claude Codeのソースコード流出——51万行超が誤公開、未公開機能が次々と発覚 AIコーディングツール「Claude Code」を開発するAnthropicが、バージョン2.1.88のアップデートパッケージに内部TypeScriptコードのソースマップファイルを誤って同梱してしまうという失態を犯した。この流出コードは51万2,000行超にのぼり、X（旧Twitter）上のユーザーがいち早く発見・公開。Ars TechnicaやVentureBeatも相次いで報じ、技術コミュニティに大きな波紋を呼んだ。 発覚した未公開機能の数々 コードを解析したユーザーたちは、複数の興味深い未公開機能を発見している。 たまごっち風ペット機能 Redditの投稿によると、入力欄の横に「ペット」が表示され、コーディングの進捗に応じてリアクションするというユニークな機能が確認された。開発体験をゲーミフィケーションする試みとみられる。 常時稼働バックグラウンドエージェント「KAIROS」 より注目度が高いのが、コードネーム「KAIROS」と呼ばれる機能だ。ユーザーの明示的な指示なしにバックグラウンドで常時稼働するエージェント機能と見られており、Claude Codeのエージェント化をさらに進める布石になりそうだ。 開発者の本音コメント さらに、Anthropicのエンジニアによるコードコメントも見つかった。「このメモ化（memoization）は複雑さをかなり増やしているが、本当にパフォーマンスが改善しているかは正直わからない」という率直な一文で、開発現場のリアルな葛藤が垣間見えると話題になった。 拡散は止まらず——GitHubで5万フォーク超 Anthropicは問題を認識後、速やかにアップデートを修正。しかしそれより先に、流出コードはGitHubのリポジトリにコピーされ、5万フォーク以上という驚異的な速さで世界中に拡散した。デジタルデータの性質上、一度公開された情報を完全に回収することは事実上不可能な状態となっている。 Anthropic公式コメント——「セキュリティ侵害ではない」 Anthropicの広報担当クリストファー・ナルティ氏はThe Vergeに対し、次のようにコメントしている。 「本日、Claude Codeのリリースに内部ソースコードが含まれていました。顧客データや認証情報などの機密情報は一切含まれておらず、漏洩もありません。これはセキュリティ侵害ではなく、人的ミスによるリリースパッケージングの問題です。再発防止策を順次展開しています。」 専門家の見解——長期的影響は限定的か 調査会社GartnerのAIアナリスト、アルン・チャンドラセカラン氏は、今回の流出について「悪意ある行為者がガードレール（安全制約）を回避する手がかりを得る可能性というリスクはある」としながらも、長期的な影響は限定的だと分析。「Anthropicにとっては、プロセスやツールへの投資を通じてオペレーショナルな成熟度を高めるきっかけになるだろう」と述べた。 Claude Codeとは Claude Codeは2025年2月にリリースされたAnthropicの開発者向けAIコーディングツール。その後、ユーザーに代わってタスクを自律的に実行するエージェント機能を追加し、急速に存在感を高めている。日本でもGitHub CopilotやCursorと並ぶAIコーディングアシスタントとして開発者の注目を集めており、今回の流出で明らかになった未公開機能の正式リリースに期待が高まっている。 Anthropicの次の一手——特に「KAIROS」のような常時稼働エージェント機能がいつ、どのような形で正式公開されるかが、今後の注目点となりそうだ。 元記事: Claude Code leak exposes a Tamagotchi-style ‘pet’ and an always-on agent

Claude AIがVim・GNU Emacsのゼロデイ脆弱性を発見——ファイルを開くだけでRCE AIアシスタント「Claude」を使ったシンプルなプロンプトによって、テキストエディタ「Vim」および「GNU Emacs」にリモートコード実行（RCE）の脆弱性が発見された。いずれも細工されたファイルを開くだけでコードが実行されるという深刻なものだ。 発見したのは、AIレッドチーミングとセキュリティエンジニアリングを専門とするセキュリティ企業「Calif」の研究者、Hung Nguyen氏。Claude に「ファイルを開くだけでトリガーされるRCEのゼロデイ脆弱性を探せ」と指示したところ、Claudeはソースコードを分析し、複数の脆弱性を特定。さらにPoC（概念実証コード）を自動生成・改善し、修正案まで提示した。 Vimの脆弱性——パッチ済み Vimの脆弱性は、モードライン（modeline）処理における不十分なセキュリティチェックに起因する。モードラインとはファイル先頭に記述するVimへの設定指示で、これを悪用することでファイル内に埋め込んだコードを実行させることができる。 本来はサンドボックス内での実行に限定されるはずだが、別の問題によってその制限を回避し、現在のユーザー権限で任意のコマンドを実行できてしまう。 影響バージョン: Vim 9.2.0271以前のすべてのバージョン CVE: 未採番 対応状況: Vim 9.2.0272でパッチ済み 開発チームのセキュリティ情報には「攻撃者が細工したファイルを送りつけることで、Vimを実行しているユーザー権限で任意コマンドが実行される」と明記されている。 GNU Emacsの脆弱性——未修正のまま GNU Emacsの問題は、バージョン管理システムとの統合機能（vc-git）に潜む。ファイルを開くと vc-refresh-state 経由でGit操作が走り、.git/config が読み込まれる。このとき、設定ファイルに記述された core.fsmonitor プログラムが自動実行される仕組みを悪用される。 攻撃シナリオとしては、隠し .git/ ディレクトリと悪意あるコンフィグファイルを含むアーカイブ（メール添付やクラウドドライブ共有など）を被害者に送りつけ、展開後にテキストファイルを開かせるだけでペイロードが実行される。GUI上には何も表示されないため、被害に気づきにくい。 GNU Emacsの開発チームは「これはGitの問題であり、エディタ側で対処するものではない」という立場を取っている。技術的には確かにコードをGitが実行しているが、エディタがユーザーの同意なく信頼されていないディレクトリでGitを自動実行している点でリスクは現実的だ。 Nguyen氏はGitの呼び出し時に core.fsmonitor を明示的にブロックするよう修正することを提案しているが、最新版でも未修正のまま。不明な出所のファイルやインターネットからダウンロードしたファイルを開く際は細心の注意が必要だ。 AI活用による脆弱性発見の新潮流 今回の発見は、LLM（大規模言語モデル）をセキュリティリサーチに活用する手法の有効性を改めて示す事例となった。VimはLinuxサーバーのほぼすべてのディストリビューションにデフォルトでインストールされており、DevOpsやシステム管理者に広く使われているだけに、パッチ適用は早急に行うことを強く推奨する。 Vim利用者はただちにバージョン9.2.0272以降へアップデートすること。GNU Emacsユーザーは修正が提供されるまで、出所不明なファイルを開かないよう注意されたい。 元記事: Claude AI finds Vim, Emacs RCE bugs that trigger on file open

GIGABYTE Control Centerに重大な脆弱性——未認証の攻撃者がファイルを自由に書き換え可能 GIGABYTE（技嘉科技）のハードウェア管理ツール「GIGABYTE Control Center（GCC）」に、認証なしのリモート攻撃者が任意の場所にファイルを書き込める深刻な脆弱性が発見された。台湾のCERT（コンピュータ緊急対応チーム）が警告を発しており、GIGABYTEも公式セキュリティ情報を公開している。 脆弱性の概要 脆弱性はCVE-2026-4415として追跡されており、CVSSv4.0スコアは9.2（Critical／深刻）と評価されている。セキュリティ研究者のDavid Sprüngli氏が発見した。 GCCはGIGABYTE製ノートPCおよびマザーボードにプリインストールされているWindows向けオールインワン管理ツールで、ハードウェアモニタリング、ファン制御、パフォーマンスチューニング、RGBライティング制御、ドライバ・ファームウェア更新などを担う。 問題の根本は、GCCの「ペアリング」機能にある。この機能はネットワーク越しに他のデバイスやサービスと通信するためのものだが、有効になっている場合、攻撃者はOSの任意のパスに対してファイルを書き込むことができてしまう。 影響を受けるバージョンと攻撃シナリオ バージョン25.07.21.01以前でペアリング機能を有効にしているシステムが対象となる。攻撃者はネットワーク経由で認証なしに接続し、次のような被害をもたらす可能性がある。 任意コード実行（RCE） 権限昇格（Privilege Escalation） サービス拒否（DoS） GIGABYTE製品は世界中のゲーマーやPC自作ユーザーに広く普及しており、日本市場でもマザーボードのシェアが高いため、影響を受けるユーザーは少なくないと考えられる。 対応策：即時アップデートを GIGABYTEは修正済みバージョン25.12.10.01をリリースしており、ダウンロードパスの管理、メッセージ処理、コマンド暗号化の改善によって脆弱性を修正した。GIGABYTEは「直ちに最新バージョンへのアップグレードを強く推奨する」と呼びかけている。 また、インストーラーのトロイの木馬化リスクを避けるため、必ずGIGABYTEの公式ソフトウェアポータルから最新版を入手することが推奨されている。サードパーティのダウンロードサイトや非公式な配布元からの取得は避けるべきだ。 チェックポイント GIGABYTEのノートPCやマザーボードを使っている場合は、GCCのバージョンを確認する ペアリング機能を使用していない場合は無効化することも有効な緩和策となる アップデートは公式ポータルから入手する GIGABYTE製品を利用しているユーザーは早急にバージョンを確認し、アップデートを適用してほしい。 元記事: GIGABYTE Control Center vulnerable to arbitrary file write flaw

ProtonがE2EE対応ビデオ会議「Proton Meet」を発表 プライバシー重視のメール・クラウドサービスで知られるProtonが、ビデオ会議サービス「Proton Meet」を正式にリリースした。Google Meet、Zoom、Microsoft Teamsなどの主要サービスに対抗するプライバシーファーストな選択肢として位置付けられている。 無料プランでもアカウント不要、50人まで参加可能 Proton Meetの大きな特徴は、Protonアカウントがなくても無料で利用できる点だ。無料プランでは1回最大1時間、最大50人までのビデオ通話に対応する。より長時間の会議が必要なユーザー向けには月額7.99ドル（約1,200円）の「プロ」プランも用意されている。 使い方はシンプルで、会議リンクを作成して参加者と共有するだけ。Proton Calendarとの統合に加え、GoogleカレンダーやMicrosoft Outlookへの予定追加にも対応している。 暗号化技術の詳細——MLS + WebRTC構成 セキュリティ面では、Messaging Layer Security（MLS）と呼ばれるオープンソースのエンドツーエンド暗号化（E2EE）プロトコルを採用している。MLSはリアルタイムのグループメッセージング向けに設計されており、第三者機関によるレビューも完了している。 アーキテクチャはWebRTCをベースとし、映像・音声の中継にSelective Forwarding Unit（SFU）を使用。各会議リンクにはIDとパスワードが含まれており、Protonが10年以上使用してきたSecure Remote Password（SRP）プロトコルで参加者を認証する。 暗号化の仕組みとしては、参加者全員で「エポック鍵」を共有し、誰かが参加・退出するたびに鍵をローテーションする設計になっている。これにより、フォワード秘匿性（新規参加者が過去のメッセージを読めない）とバックワード秘匿性（退出済みメンバーが以降のメッセージを読めない）の両方が保証される。 なぜ今、プライバシー特化の会議ツールなのか ProtonはMeetの開発背景として、いくつかの社会的背景を挙げている。 第一にGDPRやCCPA（カリフォルニア州消費者プライバシー法）への準拠の容易さだ。EU拠点のProtonのサービスを使うことで、米国の「CLOUD Act」（クラウドデータへの政府アクセスを認める法律）の影響を受けにくくなる。特に欧州企業や日本企業で海外サービスの利用に慎重な組織にとって、EU拠点のサービスは選択肢として有力だ。 第二にAIモデルの学習への懸念だ。主要ビデオ会議サービスが会話データをAI学習に利用する慣行が広まる中、Protonは「会話内容に一切アクセスできない」設計を強みとして打ち出している。 「Proton Meetはエンドツーエンド暗号化で通話を保護し、広告販売、監視、AIトレーニングへの会話の利用を一切できなくします」（Proton公式） サーバーが侵害された場合でも、データベースには会議IDのみが保存されており、通話の内容や参加者の個人情報は漏洩しない設計となっている。メールアドレスやIPアドレスも参加者間でのみ共有され、Proton側には誰が誰と会議したかの記録も残らない。 日本ユーザーへの注目点 個人情報保護法の改正や企業のセキュリティ意識の高まりを受け、日本でもビデオ会議のプライバシーに関心が高まっている。アカウント不要で即座に使えるシンプルさと、堅牢なE2EE実装を兼ね備えたProton Meetは、セキュリティ要件の厳しい業務シーンや、プライバシーを重視する個人ユーザーに刺さる可能性がある。 元記事: Proton launches new “Meet” privacy-focused conferencing platform

Googleが@gmail.comアドレスの変更を解禁 Googleは2026年3月31日、米国ユーザーを対象に@gmail.comアドレスのユーザー名（@より前の部分）を変更できる新機能の提供を開始した。長年にわたってGmailではエイリアス（別名）の追加は可能だったものの、メインの@gmail.comアドレス自体を変更する手段は存在しなかった。今回の対応により、その制限がついに撤廃された形だ。 変更手順 操作はGoogleアカウント設定から行う。 Googleアカウントの設定を開く 「Googleメールアドレスを変更する」を選択 希望する新しいユーザー名を入力 「メールアドレスを変更」→「はい、変更します」をクリック 変更後は、Gmail・Googleフォト・Google Driveなど、Googleの各種サービス全体に新しいアドレスが自動的に反映される。 旧アドレスはどうなる？ 変更後も旧アドレスは削除されず、第三者に再割り当てもされない。引き続き同一のGoogleアカウントに紐付いた状態が維持されるため、旧アドレス宛のメールも引き続き受信できる。過去にそのアドレスで登録した外部サービスへの影響を最小限に抑えられる点は、ユーザーにとって安心材料となるだろう。 注意点 この機能はまだ米国内でも段階的なロールアウト中であり、すべてのアカウントで即時利用できるわけではない。設定画面に該当のトグルが表示されない場合は、対象外のアカウントまたは地域である可能性が高い。 日本を含む米国外への展開については、Googleからの公式アナウンスはまだない。ただし、2025年10月に最初の目撃情報が報告されており、年末には一部アカウントで確認されていたことから、今後グローバル展開が進む可能性は十分ある。 日本ユーザーへの影響 GmailはGoogleアカウントと直結しているため、アドレス変更はYouTubeやGoogle Workspaceなど多数のサービスに横断的に影響する。日本でも提供が始まった際には、外部サービスへの登録変更を忘れずに行うことが重要だ。特に二段階認証のバックアップコードや、業務・金融系サービスに登録しているGmailアドレスの更新は優先度が高い。 Gmailは世界で20億人以上が利用するメールサービス。今回の機能追加は「最初にGmailを取得したときから名前が変わった」「ハンドルネームを変えたい」といったユーザーからの長年の要望に応えるものだ。 元記事: Google now allows you to change your @gmail.com address

Microsoftは、Windows 11向けの帯域外（Out-of-Band）更新プログラムKB5086672を公開した。この更新は、直近で問題が発生していた機能更新プログラム（Feature Update）を修正することを目的としている。 帯域外更新とは 帯域外更新とは、通常の毎月第2火曜日（いわゆる「Patch Tuesday」）のリリーススケジュール外で緊急配信される更新プログラムのことだ。通常の定例アップデートを待てないほど深刻な問題が発生した場合に、Microsoftが臨時で提供する。今回の配信は、機能更新プログラムの適用に失敗するなどの不具合が報告されていたことへの迅速な対応とみられる。 対象と適用方法 KB5086672はWindows 11を対象とした更新プログラムで、Windows Updateから手動で確認・適用できるほか、自動更新が有効な環境では順次配信される。企業環境でWSUS（Windows Server Update Services）やMicrosoft Intuneを利用している場合は、管理者側での展開作業が必要になることもある。 日本国内でも多くの企業・個人がWindows 11を使用しており、機能更新プログラムの不具合は業務影響が大きい。心当たりのある方はWindows Updateを確認し、KB5086672が未適用であれば早めにインストールすることを推奨する。 背景 Windows 11では過去にも機能更新プログラムの適用失敗やロールバック繰り返しといった問題が報告されており、Microsoftは都度帯域外パッチで対応してきた実績がある。今回も同様のパターンであり、問題の根本原因や具体的な修正内容の詳細はMicrosoftの公式サポートページで確認できる。 最新のWindows環境を安定的に保つためにも、帯域外更新の情報を定期的にチェックする習慣をつけておきたい。 元記事: Windows 11 KB5086672 is out to fix broken feature update

MicrosoftとNVIDIAが原子力×AI協業——インフラのボトルネック解消へ Microsoftは、原子力エネルギー産業のデジタル変革を加速するため、NVIDIAとの戦略的協業「AI for Nuclear」を発表した。この取り組みは、業界が長年抱えてきたインフラのボトルネック——すなわち、原子力発電所の新設・刷新が「理想論」から「実行」へ移行できない構造的課題——の解消を狙ったものだ。 原子力産業が直面するボトルネック 原子力発電所の建設・運用にはきわめて複雑な許認可プロセスが伴う。各国の規制当局への申請書類は膨大で、審査期間も長期にわたる。加えて、次世代小型モジュール炉（SMR: Small Modular Reactor）をはじめとする新型炉の設計には高度なシミュレーション技術が必要であり、既存の計算インフラでは処理能力が不足しているケースも多い。 こうした課題に対して、MicrosoftとNVIDIAが提供するのは、Azure クラウドと NVIDIA の GPU コンピューティングを組み合わせたエンドツーエンドのAIツール群だ。 3つの主要領域でAIを活用 今回の協業では、主に以下の3領域でAIを適用する。 1. 許認可プロセスの効率化 規制申請に必要な膨大な文書作成・管理をAIが支援。過去の申請事例や規制要件を学習したモデルが、ドラフト生成やコンプライアンスチェックを自動化する。これにより、数年単位かかることもある許認可期間の大幅な短縮が期待される。 2. 設計・シミュレーションの加速 NVIDIA の高性能GPUを活用した物理シミュレーションにより、原子炉設計の反復サイクルを高速化する。熱流体解析や中性子輸送計算など、従来はスーパーコンピュータが必要だった処理をクラウド上で柔軟にスケールアウトできる。 3. 運用の最適化 稼働中のプラントでは、センサーデータや運転ログをリアルタイム解析するAIが、予知保全や異常検知を担う。設備の故障を事前に検知し、計画外停止を減らすことで、稼働率の向上とコスト削減を同時に実現する。 日本への示唆 日本においても、2011年の東京電力福島第一原発事故以降に停止した原発の再稼働審査や、次世代炉の導入議論が続いている。原子力規制委員会への許認可申請は世界でも屈指の複雑さを誇り、AIによる審査支援の需要は高い。MicrosoftのAzureはすでに国内データセンターを複数擁しており、今回のAI for Nuclearソリューションが国内電力会社にも展開される可能性がある。 Microsoftは近年、自社データセンターの電力需要増大を背景にスリーマイル島原発の電力購入契約を締結するなど、原子力への積極的な関与を見せている。AIとクラウドの普及が電力消費を押し上げる中、その電力源としての原子力と、原子力産業を支えるAI——という相互補完的な構図が鮮明になりつつある。 今後、具体的なツールの提供時期や対応する規制フレームワークの詳細については、MicrosoftおよびNVIDIAの追加発表が待たれる。 元記事: AI for nuclear energy: Powering an intelligent, resilient future

マイクロソフトは2026年3月の月例セキュリティ更新（Patch Tuesday）を公開し、Windowsおよび関連ソフトウェアの83件の脆弱性を修正した。今月は2件がパッチ公開前に既に悪用または公開が確認されたゼロデイ脆弱性として注目されている。 SQL Server と .NET に公開済み脆弱性 事前に公開されていた脆弱性のひとつ、CVE-2026-21262 は SQL Server 2016 以降に影響する特権昇格の欠陥だ。セキュリティ企業 Rapid7 のアダム・バーネット氏は「ネットワーク経由で sysadmin 権限への昇格が可能であり、CVSS v3 スコアは 8.8 と深刻度『重要』に迫る水準だ。先送りは難しい」と警告している。 もうひとつの CVE-2026-26127 は .NET アプリケーションに影響し、当面の影響はクラッシュ誘発によるサービス拒否（DoS）にとどまる見込みだが、サービス再起動中に別の攻撃手法が連鎖する可能性も否定できない。 プレビューペインを開くだけで危ない Office の RCE 脆弱性 毎月恒例となりつつある Microsoft Office の深刻な欠陥として、今月は CVE-2026-26113 と CVE-2026-26110 が浮上した。いずれもリモートコード実行（RCE）が可能であり、Outlook のプレビューペインで細工されたメッセージを表示するだけでトリガーされる点が特に危険だ。添付ファイルを開く操作すら不要なため、利用者は意図せず被害を受けるリスクがある。 特権昇格が今月の主役——「悪用の可能性が高い」6件を確認 セキュリティ企業 Tenable の分析によると、今月修正された CVE のうち約55%が特権昇格（EoP）バグだという。そのなかで「悪用の可能性が高い」と評価された主な脆弱性は以下の通り。 CVE-2026-24291（CVSS 7.8）: Windows アクセシビリティ インフラストラクチャの不適切な権限割り当てにより SYSTEM 権限へ昇格可能 CVE-2026-24294（CVSS 7.8）: SMB コアコンポーネントの認証不備 CVE-2026-24289（CVSS 7.8）: 高深刻度のメモリ破損＋競合状態（レースコンディション） CVE-2026-25187（CVSS 7.8）: Google Project Zero が発見した Winlogon プロセスの欠陥 歴史的マイルストーン：AIエージェントが発見した初のCVE 今月最も注目すべきトピックのひとつが CVE-2026-21536（CVSS 9.8）だ。Microsoft Devices Pricing Program コンポーネントに存在するこの重大な RCE 脆弱性は、完全自律型 AI ペネトレーションテストエージェント「XBOW」 によって発見された。ソースコードへのアクセスなしに CVSS 9.8 の脆弱性を特定した点が業界で話題を呼んでいる。XBOW は過去1年間、HackerOne のバグバウンティリーダーボードで上位を維持してきた実績を持つ。 ...

Microsoftがクロス署名ドライバープログラムへの信頼を廃止へ Microsoftは2026年4月のWindowsアップデートにおいて、旧来のクロス署名カーネルドライバープログラム（Cross-Signed Driver Program）への信頼を削除すると発表した。この変更により、今後はMicrosoftが認定するWindows Hardware Compatibility Program（WHCP）を通じて署名されたドライバーのみがデフォルトで読み込まれるようになる。 クロス署名ドライバーとは クロス署名ドライバーとは、MicrosoftのルートCA（認証局）ではなく、サードパーティの認証局によって署名されたカーネルモードドライバーを指す。過去にWindowsのドライバーエコシステムが拡大していく過程で広く利用されてきたが、その反面、マルウェアがドライバーに悪意あるコードを仕込んで署名を通過させる「ドライバー署名の悪用」が攻撃手法として確立されてしまった背景がある。 近年、ランサムウェアや高度な脅威アクター（APT）がカーネルレベルのドライバーを悪用するケースが増加しており、Microsoftはドライバーのセキュリティ強化を優先課題として取り組んできた。 段階的な適用で互換性への影響を監視 今回の変更は一度に完全適用されるわけではなく、まず評価モード（Evaluation Mode）として展開される。評価モードでは、クロス署名ドライバーが読み込まれた場合にイベントログへの記録や管理者への通知が行われるが、実際のブロックは行われない。これにより、企業やOEMが既存の環境への影響を把握し、対応を進める猶予期間が設けられる。 Microsoftは互換性への影響を監視しながら段階的に適用を進める方針で、最終的にはクロス署名ドライバーのデフォルト読み込みを完全に無効化する予定だ。 企業・開発者が取るべき対応 ハードウェアベンダーやドライバー開発者は、WHCPを通じた署名取得へ移行することが求められる。WHCPの認定プロセスはMicrosoftのHardware Dev Centerポータルから申請でき、Microsoftによる技術的なテストと審査を経て署名が付与される。 企業のIT管理者は、社内で使用しているサードパーティ製ハードウェアのドライバーがWHCP署名済みかどうかを確認し、未対応のベンダーに対してアップデートを要求する必要がある。特に、古いプリンターや特殊な計測機器、産業用デバイスのドライバーは対応が遅れる可能性があるため、早期の棚卸しが推奨される。 セキュリティ強化の流れの一環 この変更は、MicrosoftがWindows 11以降で推進しているSecured-core PCやVulnerable Driver Blocklist（脆弱ドライバーブロックリスト）の強化と同じ方向性を持つ。カーネルへのアクセスを厳しく制限することで、マルウェアがOSの深部に潜り込むことを根本から防ぐ設計思想だ。 Windowsのセキュリティ基盤を強化する上で重要なマイルストーンとなる今回の変更を前に、ハードウェアベンダーとIT担当者は早めの対応準備を進めておくべきだろう。 元記事: Advancing Windows driver security: Removing trust for the cross-signed driver program

Azure DevOps MCPサーバーがMicrosoft Foundryに登場 Microsoftは、Azure DevOps向けのMCP（Model Context Protocol）サーバーをMicrosoft Foundryで正式に提供開始したと発表した。これにより、AIエージェントがAzure DevOpsのパイプライン・作業項目（Work Items）・リポジトリを自然言語で直接操作できるようになる。 MCPとは何か MCP（Model Context Protocol）は、AIモデルと外部ツール・データソースを標準的なインターフェースで接続するためのオープンプロトコルだ。Anthropicが提唱し、近年急速に採用が広がっている。MCPサーバーを経由することで、AIエージェントはアプリケーションのAPIを直接知らなくても、自然言語の指示だけで外部システムを操作できるようになる。 何ができるようになるのか Azure DevOps MCPサーバーを使うことで、開発者やAIエージェントは以下のような操作を自然言語で実行できるようになる。 パイプラインの管理: ビルドやリリースパイプラインの状態確認、トリガー実行 作業項目の操作: バックログの確認・更新、スプリント計画の調整 リポジトリへのアクセス: コードの参照やプルリクエストの状況確認 たとえば「先週マージされたPRの一覧を見せて」「今日のビルドが失敗した原因を調べて」といった指示を、AIエージェントが直接Azure DevOpsに問い合わせて答えられるようになる。 リモートMCPサーバープレビューも同時提供 今回の発表と合わせて、リモートMCPサーバーのプレビューも提供が開始された。従来のMCP接続はローカル環境でのプロセス起動が前提だったが、リモートMCPサーバーにより、クラウド上でホストされたMCPサーバーへのHTTPS接続が可能になる。これにより、エンタープライズ環境での大規模なエージェント活用がより現実的になる。 エージェント駆動のDevOpsへ この動きは「DevOpsのエージェント化」というトレンドの加速を示している。GitHub CopilotやAzure AI Foundryとの連携により、コードの記述から本番デプロイまでの一連のフローをAIエージェントが補佐・自動化する未来が近づいている。 日本でもAzure DevOpsを活用している企業は多く、CI/CDパイプラインや作業管理にAIエージェントを組み込む需要は高い。Microsoft Foundryのエコシステムを通じて、こうした機能が標準的に利用できるようになることは、DevOpsチームの生産性向上に大きく貢献するだろう。 利用開始方法 Azure DevOps MCPサーバーはMicrosoft Foundry経由で利用可能。Azure DevOpsのサービス接続とMicrosoft Foundryプロジェクトを組み合わせることで、既存のDevOps環境にAIエージェントを統合できる。 元記事: Azure DevOps MCP Server Now Available in Microsoft Foundry

Azure App Service証明書、業界標準変更で発行方式が刷新へ Microsoftは、CA/Browser Forum（CA/B Forum）が策定する業界全体の証明書基準変更に伴い、Azure App ServiceのマネージドTLS証明書に関する重要なアップデートを発表した。この変更は2026年内に適用が予定されており、Azureでウェブアプリを運用する開発者・運用担当者は内容を把握しておく必要がある。 何が変わるのか 影響を受けるのは以下の2種類の証明書だ。 無料マネージドTLS証明書（DigiCert発行） 有償App Service証明書（GoDaddy発行） CA/B Forumは、TLS証明書の最大有効期間を段階的に短縮する方向で議論を進めており、将来的には最大47日まで短縮される見通しだ（現行は最大397日）。これはフィッシングや証明書の不正利用リスクを低減するための業界全体の取り組みであり、Google、Apple、Mozillaなど主要ブラウザベンダーが推進している。 AzureのApp Service証明書においても、この基準変更に合わせて証明書の発行方式・有効期間・更新サイクルが変更される。具体的な新しい有効期間や移行タイムラインは順次公式ドキュメントに反映される予定だ。 自動更新ユーザーへの影響は最小限 Microsoftによれば、証明書の自動更新（Auto-renewal）を有効にしているユーザーは、Azureが更新処理を自動的に行うため影響を受けにくい。App Serviceのマネージド証明書はデフォルトで自動更新が設定されているケースが多く、該当ユーザーはAzureポータルで設定状況を確認するだけで済む場合がほとんどだ。 手動管理ユーザーは対応が必要 一方、以下のケースに該当する場合は能動的な対応が求められる。 有償App Service証明書を手動で更新・管理している場合 — 有効期間の変更に伴い、更新作業の頻度が増加する 証明書をKey Vaultと連携させている場合 — Key Vaultのシークレットローテーション設定も見直しが必要になる可能性がある 外部システムが証明書の有効期間に依存している場合 — 証明書の短縮に対応できるよう監視・アラート設定を更新する 日本の運用担当者へのポイント 日本では金融・医療・公共系のシステムでApp Serviceを活用するケースも増えており、証明書の有効期限切れによるサービス停止は深刻なインシデントにつながりかねない。今回の変更を機に、証明書管理の自動化状況を棚卸しし、手動フローが残っていれば自動化への移行を検討したい。 Azureポータルの「App Service証明書」ブレードでは、各証明書の自動更新ステータスを一覧で確認できる。まずは自動更新が有効かどうかを確認することが最初のアクションだ。 詳細はMicrosoftの公式ブログ「Apps on Azure Blog」で継続的に更新される予定となっている。 元記事: Industry-Wide Certificate Changes Impacting Azure App Service Certificates

Claude CodeのソースコードがNPMマップファイル経由で流出 Anthropicが開発するAIコーディングアシスタント「Claude Code」のソースコードが、NPMレジストリに含まれるJavaScriptソースマップ（.mapファイル）を通じて誰でも閲覧可能な状態になっていたことが明らかになった。 ソースマップとは何か JavaScriptのビルドプロセスでは通常、本番配布用にコードを難読化・圧縮（ミニファイ）する。しかしデバッグを容易にするため、圧縮前の元ソースと圧縮後コードの対応関係を記録した「ソースマップファイル（.map）」を生成することがある。このファイルをNPMパッケージに誤って同梱してしまった場合、事実上の「ソースコード公開」に等しい状態になる。 Claude CodeはNPMパッケージとして配布されており、今回はまさにこの落とし穴にはまった格好だ。 流出から判明した内部実装の詳細 Hacker Newsで866件以上のコメントを集めた関連スレッド「The Claude Code Source Leak: fake tools, frustration regexes, undercover mode」では、流出したソースコードを解析した結果として複数の興味深い実装が報告されている。 フェイクツール（Fake tools） Claude Codeが実際には存在しないか、あるいは期待通りに動作しないツールを「あるかのように」提示している実装が含まれていたとされる。これはユーザー体験の調整やフォールバック処理の一環とみられるが、透明性の観点から議論を呼んでいる。 フラストレーション正規表現（Frustration regexes） ユーザーが苛立ちや怒りを示すようなメッセージを送った場合に検出するための正規表現が含まれていたという。ユーザーの感情状態を把握してレスポンスを調整する仕組みとみられ、「AIが人間の感情を監視している」という点でプライバシー面での懸念も指摘されている。 潜伏モード（Undercover mode） Claude Codeが自身のアイデンティティを隠す、もしくはAIであることを明かさない動作モードの実装が確認されたとの報告もある。ベンチマーク評価時の挙動調整など、複数の用途が推測されているが、詳細はまだ調査中だ。 Anthropicへの影響と業界の反応 Hacker NewsやX（旧Twitter）ではこの流出が急速に拡散し、元ツイートは多数のエンゲージメントを獲得。AI企業の「ブラックボックス」に対する透明性への関心の高さを改めて示した。 AnthropicはClaudeシリーズをクローズドモデルとして提供しており、内部実装の詳細は非公開が原則だ。今回の流出は意図的な情報公開ではなく、ビルド・パッケージングプロセスにおけるミスとみられる。 日本では多くの開発者がClaude Codeを業務に活用しており、今回明らかになった内部実装の詳細——特にフラストレーション検出や潜伏モード——については、利用方針やプライバシーポリシーの観点から改めて精査する価値があるだろう。 教訓：NPMパッケージのソースマップ管理 この事例は、商用ソフトウェアをNPMで配布する際のセキュリティ管理の重要性を改めて示している。.mapファイルの同梱有無は.npmignoreやpackage.jsonのfilesフィールドで制御できるため、クローズドソースのツールを配布する開発者は自社パッケージの設定を今一度確認することを推奨する。 Anthropicからの公式声明は現時点では出ていない。 元記事: Claude Code’s source code has been leaked via a map file in their NPM registry

Claude Codeのソースコードが流出——偽ツール注入・感情検知・未公開エージェントモード「KAIROS」とは Anthropicが開発するAIコーディングアシスタント「Claude Code」のソースコードが、NPMパッケージへのソースマップ（.mapファイル）の誤同梱によって流出した。パッケージはすぐに取り下げられたが、コードはすでに広くミラーリングされ、Hacker News上でも大きな話題となっている。 Anthropicにとってこれは1週間で2度目の情報漏洩事故だ（直前にはモデル仕様書のリークもあった）。また、ちょうど10日前にはOpenCodeに対して法的措置を取り、サードパーティによるClaude Codeの内部API悪用を問題視していたばかりとあり、今回の流出内容がより注目を集めている。 偽ツール注入による「反蒸留（Anti-distillation）」機構 最も注目を集めた発見が、claude.ts（301〜313行目）に存在するANTI_DISTILLATION_CCフラグだ。これが有効な場合、Claude CodeはAPIリクエストにanti_distillation: ['fake_tools']を含め、サーバー側がシステムプロンプトに「偽のツール定義」を静かに注入する。 目的は明快だ——Claude CodeのAPIトラフィックを傍受して競合モデルの学習に使おうとする行為を妨害するため、意図的に汚染データを混入させる。この機能はGrowthBook社のフィーチャーフラグ（tengu_anti_distill_fake_tool_injection）でゲートされており、ファーストパーティCLIセッションのみに適用される。 もっとも、研究者が指摘するように回避策は単純で、MITMプロキシでanti_distillationフィールドをリクエストボディから除去するか、環境変数CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETASを設定するだけで無効化できる。実質的な保護はむしろ法的手段に依存しているとみられる。 「アンダーカバーモード」——AIがAIであることを隠す ソースには、AIであることを開示せずに動作するモードの存在も確認された。特定の条件下でClaude CodeがAIアシスタントとしての素性を表に出さずに応答するこの機能は、エンタープライズ向けの特定ユースケースを想定したものとみられる。 正規表現によるユーザーの感情（フラストレーション）検知 驚くべきことに、ユーザーのフラストレーション検知にLLMではなく正規表現が使われていることも判明した。「damn」「wtf」「not working」といったパターンにマッチした場合に、システムが何らかの応答を調整する仕組みだ。シンプルながら軽量で実用的な設計判断と言えるが、AIツールの感情認識がこのような古典的手法で実装されていることには多くの開発者が驚きを示している。 1日25万件の「無駄なAPIコール」 パフォーマンス面でも気になる数字が出てきた。設計上の問題とみられる不要なAPIコールが1日あたり約25万件発生しているという。コスト面やレイテンシへの影響が懸念される。 未公開の自律エージェントモード「KAIROS」 おそらく最も衝撃的な発見が、KAIROSと呼ばれる未リリースの自律エージェントモードだ。詳細は限られているが、現在の対話型モードを超えた、より高度な自律実行能力を持つモードとして開発が進んでいるとみられる。Anthropicが近い将来にエージェント機能を大幅に強化する計画を持っていることを示唆しており、業界関係者の注目を集めている。 まとめ 今回の流出は、Anthropicにとって技術的・法的・広報的な打撃となった。一方で、現代の商用AIツールがどのような工夫と妥協のもとで構築されているかを垣間見る、稀な機会にもなっている。日本国内でもClaude Codeの利用者は増加しており、これらの実装が今後の開発判断や競合製品の設計にどう影響するか、引き続き注目が集まりそうだ。 元記事: The Claude Code Source Leak: fake tools, frustration regexes, undercover mode