Tech News JP

マスク氏、自社チップ製造施設「Terafab」を構想——テスラ・SpaceXのAI需要に対応 イーロン・マスク氏は先週末、テキサス州オースティン市内で開催されたイベントにおいて、テスラとSpaceXが共同で半導体製造施設を建設する野心的な計画を発表した。マスク氏がこの施設を「Terafab」と命名していることが、公開された写真から確認されている。建設予定地はテスラのオースティン本社および「ギガファクトリー」の近隣とされている。 なぜ自前の半導体製造が必要なのか マスク氏が自社製造に踏み切る背景には、急増するAIおよびロボティクス向けの計算需要がある。氏は「半導体メーカーは我々が必要とするスピードでチップを製造してくれない。Terafabを建設するか、チップを持てないかの2択だ。チップが必要だから、建設する」と述べた。 日本でも生成AIの普及に伴いGPUの調達難が続いており、NVIDIAのH100/H200系チップを中心に需給ひっ迫が問題視されている。テスラやSpaceXが社内で半導体製造を内製化しようとする動きは、こうした業界全体のチップ不足を象徴する出来事といえる。 計画の規模と課題 マスク氏が掲げる目標は壮大だ。地球上では年間100〜200ギガワットの計算能力をサポートするチップを製造し、さらに宇宙空間では1テラワット規模の計算インフラを構築するという。 ただし、具体的なタイムラインは示されていない。また、Bloombergも指摘しているように、マスク氏には半導体製造の専門的なバックグラウンドがない。加えて、同氏はこれまでもテスラの自動運転完全実現やFSDの普及時期、SpaceXの有人火星飛行計画などで繰り返し「過大公約（overpromising）」を行ってきた歴史がある。 半導体製造は高度な専門知識と莫大な設備投資が求められる産業であり、TSMCやSamsungといった既存プレーヤーが長年かけて築いた製造技術の壁は非常に高い。Terafabが現実のものとなるかどうか、業界の注目が集まっている。 元記事: Elon Musk unveils chip manufacturing plans for SpaceX and Tesla

CursorのComposer 2、実は中国製モデルが基盤だった AIコーディングツールとして急成長を遂げているCursorが、今週リリースした新モデル「Composer 2」をめぐって物議を醸している。同社は当初、Composer 2を「フロンティアレベルのコーディング知性」と謳って発表したが、実際には中国企業Moonshot AIのオープンソースモデル「Kimi 2.5」を基盤として構築されていたことが明らかになった。 X（旧Twitter）のユーザーが暴露 きっかけはX上のユーザー「Fynn」による指摘だった。Fynnは、Composer 2が「追加の強化学習を施しただけのKimi 2.5にすぎない」と主張し、モデルIDにKimiを示すコードが含まれている証拠を提示した。「せめてモデルIDを変名しろよ」と皮肉も込めてポストしたこの指摘は、瞬く間にテック界隈で拡散した。 Moonshot AIはアリババとHongShan（旧Sequoia China）が出資する中国企業であり、そのモデルを米国スタートアップが流用していたという事実は少なからぬ注目を集めた。 Cursorは認めつつも「大部分は独自トレーニング」と主張 これに対し、CursorのVP（開発者教育担当）であるLee Robinsonは「そうです、Composer 2はオープンソースのベースモデルからスタートしました」と認めた。ただし、「最終モデルの計算リソースのうち、ベースモデルに使ったのは約4分の1にすぎず、残りは独自トレーニングに費やした」と説明し、各種ベンチマークでのComposer 2の性能はKimi 2.5と「大きく異なる」と強調した。 また、Kimi公式アカウントもX上でCursorを祝福する投稿を行い、今回の利用がFireworks AI経由の「認定商業パートナーシップ」に基づくものだと説明した。「Kimi-k2.5が基盤を提供できたことを誇りに思う」とも述べ、ライセンス上の問題はないとしている。 なぜ最初から開示しなかったのか 問題となるのは、Cursorが発表時にKimiとの関係を一切開示しなかった点だ。Cursorは昨秋に23億ドルの資金調達ラウンドを完了し、企業評価額は293億ドル（約4.4兆円）に達する。また年間収益換算で20億ドル超を達成したとも報じられており、そのような資金力を持つ企業がモデルをゼロから作らなかったことへの批判だけでなく、中国製モデルを基盤としたことへの政治的センシティビティも背景にある。 米中間でAI開発の「主導権争い」が激化する中、DeepSeekの躍進が昨年シリコンバレーに衝撃を与えたことは記憶に新しい。中国製モデルの採用を公表することへのためらいが、今回の情報開示の遅れにつながったとの見方もある。 共同創業者のAman Sangerも「最初のブログ記事でKimiのベースモデルに言及しなかったのは失敗だった。次のモデルでは修正する」と率直に認めた。 オープンソースエコシステムの現実 今回の件は、AIモデル開発においてオープンソースの活用が一般的になってきていることを改めて示している。商用製品がオープンソースのベースモデルを活用すること自体は珍しくないが、その出所を適切に開示することが信頼構築の観点から不可欠であることも浮き彫りとなった。日本でも多くのAIサービスが同様の構造を持つ可能性があり、モデルの出自に対する透明性への関心が今後さらに高まりそうだ。 元記事: Cursor admits its new coding model was built on top of Moonshot AI’s Kimi

AIだらけの会場、でもゲームにAIなし——GDC 2026の奇妙な矛盾 毎年ゲーム開発者が集まる業界最大のカンファレンス「GDC（Game Developers Conference）Festival of Gaming」2026年版が開催された。今年の会場を一言で表すなら「AI祭り」だった。しかし、ふたを開けてみると、実際にゲームを作っている開発者たちの声は真逆だった。 会場を埋め尽くすAIベンダー 展示フロアでは、生成AIを活用したツールが並んだ。AIで動作するNPC（ノンプレイヤーキャラクター）の生成、チャット入力だけでゲームまるごとを作るツール、テンセント（Tencent）のAIが生み出したピクセルアートのファンタジー世界のデモなど、10分プレイするだけでも体験できた。レイザー（Razer）のブリーフィングでは、シューティングゲームのQA（品質保証）作業を自動化するAIアシスタントが披露され、Googleディープマインド（DeepMind）の研究者によるAI生成のプレイアブル空間についての講演は立ち見が出るほどの盛況ぶりだった。 しかし、開発者たちは「絶対に使わない」 ところが、記者が実際に話したゲーム開発者のほぼ全員が、自分のプロジェクトへのAI活用を否定した。インディーゲーム『The Melty Way』の開発者ガブリエル・パケット氏はこう語る。「人間の思考ってものすごく美しいと思う。なんでそれを使わないんですか？」 この感覚は多くの開発者に共通していた。特にインディー開発者の間では、AIを使うことで「人間が作った」という本質的な価値が損なわれるという意識が根強い。 GDCが実施した最新調査でも、回答者の52%が「生成AIはゲーム業界に悪影響を与えている」と回答。この割合は2025年の30%、2024年の18%から急上昇しており、反感は年々強まっている。すでに「AIフリー」を明示してゲームを販売するインディー開発者も増えてきた。 「人の手の感触」へのこだわり インディーの名作『Tunic』や『Chicory: A Colorful Tale』を送り出したパブリッシャー兼スタジオ「Finji」の共同創業者アダム・サルツマン氏とレベッカ・サルツマン氏は、自社作品の核心を「特定の人物の指紋が感じられること」と表現する。「見せた瞬間に何か分かるんだけど、実際にプレイするとすべての期待を裏切ってくる」（レベッカ氏）。この哲学は生成AI活用と真っ向から対立する。Finjiのゲームに生成AIを使う可能性を問われたアダム氏の答えは明快だった。「絶対にない」 AI推進派との温度差 一方、業界の別の側面ではAI推進論も根強い。Google Stadiaの立ち上げに携わり、ソニーでPlayStation NowやPlayStation Homeの開発経験を持つGoogle Cloud幹部ジャック・ブーザー氏は「生成AIは私の30年近いゲーム業界キャリアで目撃してきた中で最大の変革だ」と断言する。開発サイドではデバッグやQA、アイデア出しへの活用、プレイヤーサイドではゲームの個別カスタマイズへの応用など、楽観的な展望も語られた。 Nvidia（エヌビディア）のDLSS 5が公開デモで既存ゲームキャラクターの顔を「AIっぽいノイズ感のある描写」に変えてしまったことで広がった否定的反応も、小規模開発者のAI離れに拍車をかけているとみられる。 GDC 2026は、ゲーム業界が抱えるAIをめぐる深い矛盾を可視化した場となった。ベンダーや大企業が推し進めるAIの波と、実際にゲームを作るクリエイターたちの「人の手」へのこだわり——この溝は2026年現在、むしろ広がりつつある。 元記事: AI was everywhere at gaming’s big developer conference — except the games

AIがコードを書く時代に「コードを理解すること」の価値はどこにあるのか 「AIに話しかければアプリが作れる」——そんな言説が広まる中、ソフトウェアエンジニアのSteve Krouseが興味深い論考を公開した。タイトルは「コードの死亡報告は大げさすぎる」。Hacker Newsで400以上のポイントを集め、300件超のコメントが寄せられた注目の記事だ。 バイブコーディングの本質と落とし穴 「バイブコーディング（vibe coding）」とは、自然言語（英語）で指示を出し、AIが生成したコードに対して「ボタンをそこに移動して」「もっと青くして」と反応しながらイテレーションを重ねるスタイルだ。英語レベルの感覚（バイブ）のまま操作できるため、非エンジニアでもアプリ開発が可能になる。 しかし、Krouseはここに根本的な問題を指摘する。**「バイブは精度の高い抽象化であるという錯覚を生む」**のだ。 実際、AIエッセイストのDan Shipperがバイブコーディングで作ったテキストエディタアプリがバイラルヒットした後、リアルタイム共同編集機能の実装で致命的な壁にぶつかった事例が紹介されている。「ライブコラボレーション」は誰もがGoogle DocsやNotionで使ったことがあるため、仕様として完全に理解できている気がする。しかし実際には、競合状態の管理、操作変換（Operational Transformation）やCRDTといった複雑なアルゴリズム、ネットワーク障害への対処など、膨大なエッジケースが潜んでいる。 英国の哲学者バートランド・ラッセルの言葉が重く響く。 「物事はすべて、精密にしようとして初めてわかるほど、曖昧なのだ」 抽象化こそがプログラミングの本質 Krouseが強調するのは、抽象化（abstraction）の力だ。人間の脳は同時に7±2個の物事しか扱えない。それ以上の複雑さを扱うには、複数の概念を一つにまとめる「圧縮」が必要であり、この圧縮こそが抽象化だ。 コンピュータサイエンスの先駆者Edsger Dijkstraはこう述べた。 「抽象化の目的は曖昧にすることではなく、その中で絶対的に精確に語れる新たな意味レベルを作ることにある」 具体例として、SlackがいつユーザーにPush通知を送るかを示した複雑なフローチャートが紹介される。エンジニアのSophie Alpertはこれを巧みな抽象化でシンプルなダイアグラムに整理した。ReactJSがUI開発の複雑さを、TailwindCSSがスタイリングの複雑さを抽象化したように、良い抽象化は困難な問題を扱いやすくする。 AGI時代でもコードは必要か 記事は最後にAGI（汎用人工知能）到来後の世界を展望する。月額1000ドルでAndrej Karpathy級の天才エンジニアを100人雇えるとしたら、細かい実装の詳細にこだわる必要はあるのか？ Krouseの答えは「それでも抽象化の理解は不可欠」というものだ。どれだけ高性能なAIがあっても、何が精確な仕様であるかを人間が理解・判断できなければ、AIが生成したシステムの品質を評価することすらできない。コードを書くスキルではなく、複雑さをどう構造化・抽象化するかという思考の枠組みこそが、AIと協働する時代に求められる能力だという主張だ。 日本でも「ノーコード/ローコード」や「AIペアプログラミング」への注目が高まる中、この論考はエンジニアとして何を学ぶべきかを問い直す良い機会を提供してくれる。プログラミングの本質は「コードを書く行為」ではなく「複雑さをコントロールする知的営み」にあるのかもしれない。 元記事: Reports of code’s death are greatly exaggerated

ひとり開発者が直面した「テストの無人地帯」 Christopher Meiklejohnは、コミュニティ向けアプリ「Zabriskie」をひとりで開発している。チームも投資家もなく、ベッドルームで黙々とシップし続けるスタイルだ。Webアプリとして好評だったものの、「App Storeにないアプリは存在しないも同然」という現実に直面し、iOS・Android・Webの3プラットフォーム同時対応を余儀なくされた。 1人で3つのコードベースを維持するのは現実的でない。そこで採用したのが Capacitor だ。既存のReact Webアプリをネイティブシェルで包み込み、AndroidではWebView、iOSではWKWebViewとして動作させることで、単一コードベースから3プラットフォームに展開できる。さらにサーバー側からJSON形式で画面レイアウトを送る「サーバードリブンUI」アーキテクチャを組み合わせることで、App Storeのレビュー待ちなしに変更を全プラットフォームへ即反映できる。 しかしここに落とし穴がある。Capacitorアプリはテストツールの「無人地帯」に落ちるのだ。PlaywrightはネイティブシェルのWebViewにアクセスできず、XCTestやEspressoといったネイティブテストフレームワークはWebViewの中のHTML要素を操作できない。Webツールには「ネイティブすぎ」、ネイティブツールには「Web的すぎ」という宙ぶらりんな状態になる。 ClaudeをQAエージェントとして訓練する WebアプリにはPlaywrightで150本以上のE2Eテストが走っているが、モバイルアプリ側には何もなかった。そこでMeiklejohnは、ClaudeにAndroid・iOSの両プラットフォームを操作させ、スクリーンショットを撮って問題を検出し、バグレポートまで自動で起票させる仕組みを構築することにした。 Androidは90分で解決 Androidエミュレーター内ではlocalhostがホストMacではなくエミュレーター自身を指すため、まずadb reverseでポートフォワーディングが必要だ。これは再起動のたびに再実行が必要なものの、ワンライナーで済む。 本命の突破口は、CapacitorアプリがChrome DevTools Protocol（CDP）ソケットを公開しているという事実だ。adb shellでWebViewのDevToolsソケットを特定してローカルポートに転送すれば、PlaywrightやPuppeteerと同じプロトコルでAndroid WebViewを完全制御できる。JWTをlocalStorageに注入して認証、window.location.hrefでナビゲーション——座標指定やUI操作は一切不要。adb shell screencapでスクリーンショットを取得するPythonスクリプトと合わせて、Android環境はわずか90分で完成した。 iOSは6時間以上の格闘 対照的に、iOSは6時間以上を要した。この差は2026年時点のモバイル自動化ツールの成熟度を如実に物語っている。iOSのWebViewはAndroidほどオープンなデバッグインターフェースを持たず、Apple独自のセキュリティモデルがあらゆる迂回路を塞ぐ。 AI活用QAの可能性と現実 この事例は、ClaudeをはじめとするLLMをQAエンジニア的に活用する流れを示している。単にコードを書かせるだけでなく、スクリーンショットを見て視覚的なバグを検出させたり、バグレポートを自動作成させたりといった使い方だ。1人開発者がリソース制約の中でQA品質を維持するための現実的な戦略として注目される。 AndroidとiOSの難易度差は、モバイル自動化エコシステムの分断を象徴している。Capacitorのような「Write Once, Run Anywhere」アプローチはコード共有を実現する一方、テスト環境の整備は依然として各プラットフォーム固有の課題が残ることを、この実践レポートは教えてくれる。 元記事: Teaching Claude to QA a mobile app

AIが「スパム製造」のハードルを下げている コーディングを民主化するAIツールの普及が、思わぬ副作用をもたらしている。スパムメールが、かつてないほど「それらしく」見えるようになってきたのだ。 テクノロジーメディア「Tedium」のErnie Smith氏は最近、自身のスパムフォルダに届いたメールに異変を感じた。従来のスパムといえば、崩れたレイアウト・不自然なフォント・ちぐはぐな配色が当たり前だった。ところが最近は、クラウドストレージの容量超過を装った偽通知メールが、一見すると本物のサービスメールと区別がつかないほど洗練されたデザインで届くようになっている。 さらに注目すべき変化がある。従来のスパムは画像をオフにすると途端に崩れ、フィッシング詐欺だと一目でわかった。しかし最近のスパムは、画像なしの状態でも適切なレイアウトとテキスト構造を維持している。多くのメールクライアントはスパムフォルダで画像を自動的にブロックするため、これは意味のある変化だ。 「バイブスキャミング」という新たな脅威 この現象の背景にあるのが、ChatGPTやClaudeなどのLLM（大規模言語モデル）を使って直感的にコードを生成する「バイブコーディング（Vibe-Coding）」の普及だ。 セキュリティプラットフォームのGuard.ioはこれを**「VibeScamming（バイブスキャミング）」**と名付けて警告している。フィッシングサイトの構築、クレジットカード情報の詐取、企業のOffice 365認証情報を狙った攻撃——これらすべてが、技術的な知識をほとんど持たない「ジュニアスキャマー」でも、AIエージェントへの数回のプロンプト入力だけで実現できるようになっているという。 Anthropicも昨夏発表したレポートの中で、LLMの助けを借りることで、本来ランサムウェアを開発できないような人物でも「ノーコード型マルウェア」を製造できるようになると警告している。こうしたマルウェアは1本あたり最大1,200ドル（約18万円）で販売されるケースもあるという。 「怪しいメールの見分け方」が崩壊しつつある 長年にわたり、スパムやフィッシングメールを見分けるための経験則として「デザインがチープ」「HTMLが崩れている」「画像が壊れている」といった視覚的な手がかりが有効だった。しかしバイブコーディングによってデザインの最低水準が底上げされた今、こうした判断基準は機能しなくなりつつある。 ユーザーはより巧妙な罠にかかりやすくなり、一方で無意識にセキュリティへの不信感を高め、正規のメールまで疑うようになるという悪循環も懸念される。 LovableやBoltといったAIコーディングプラットフォームは、スタートアップや個人開発者にとって画期的なツールだ。しかしその恩恵が、サイバー犯罪者にも等しく届いている現実は、技術の民主化が常に光と影を伴うことを改めて示している。 スパムフォルダは今や、インターネットの「地下」で何が流行しているかを映す鏡でもある。そしてその鏡が映し出す景色は、AIの時代において急速に変わりつつある。 元記事: They’re vibe-coding spam now

Rustコミュニティ内でAIを巡る議論が本格化 2026年2月、RustプロジェクトのコアメンバーであるNiko Matsakis氏（@nikomatsakis）が、RustのコントリビューターやメンテナーたちのAIに関する見解を収集・まとめたドキュメントを公開した。2月6日から収集された意見を2月27日時点でまとめたもので、プロジェクト全体としての公式見解ではなく、個々のメンバーの生の声を幅広く紹介している。 Matsakis氏はドキュメントの冒頭で「これはRustプロジェクトとしての統一見解ではない。現時点でRustプロジェクトはAIツールの利用についてまとまったポジションを持っていない。このドキュメントは、それを形成するための第一歩だ」と明記している。 「AIを使いこなすにはエンジニアリングが必要」 議論の中で繰り返し強調されたのが、AIツールは使いこなしに実力が要るという点だ。コントリビューターのTC氏はこう述べている。 「良い結果を出すには、丁寧かつ慎重なエンジニアリングが必要だ。問題を適切に構造化し、正しいコンテキストとガイダンスを与え、適切なツールと環境を整える。コンテキストウィンドウの最適化を考え、限界を把握する必要がある」 また、モデルの急速な進化についても言及があった。「2〜3ヶ月でどれほど変わったかは見えにくいかもしれないが、最先端のモデルは今や無視できないほど優れている」（TC氏）。 これは、AIに対して「煙だけで実体がない」と感じる人と「深く価値を見出す人」との間に生まれる認識差の説明にもなっている。ユーザー@yaahc氏は「工学的なバックグラウンドがあるかどうかで、ツールから得られる成果が大きく変わる可能性がある」と分析している。 コーディング以外での活用が見えてくる AI活用の議論はコーディング支援に集中しがちだが、実際にはそれ以外の用途でも多くのメンバーが価値を見出している。 ドキュメント検索・調査補助の観点では、Arm社のdavidtwco氏が「1万ページ以上のアーキテクチャドキュメントを検索するのに社内AIツールが非常に役立っている。上流のIssueに迅速に対応できるようになった」と述べている。scottmcm氏も「Spanを取得するにはどこを見ればいい？というような調査系の質問には非常に有効だ」と評価する。 コードレビューのアシストについても期待の声が上がっている。BennoLossin氏は「AIに確認させ、質問を生成させることで、正しいアイデアを探る助けになった」と語る。Linuxカーネルコミュニティでは、プロジェクト固有のプロンプトを丁寧に設計したLLMエージェントによるコードレビュー支援で成果が出たケースも報告されており、Rust側でも同様の試みへの関心が示された。 日本のエンジニアへの示唆 Rustは近年、WebAssembly・組み込み・システムプログラミングの文脈で日本国内でも注目度が高まっている言語だ。今回の議論は「AIを使えばいいのか、使わないほうがいいのか」という二項対立ではなく、どう使いこなすかというより実践的な問いへと議論が移行していることを示している。 プロジェクトとしての公式ポジションはまだ形成途上だが、AIの活用方針について組織やチームで議論を深めていく上での参考事例として、日本のエンジニアコミュニティにとっても示唆に富む内容だ。元のコメント全文は公開されており、原文で確認することもできる。 元記事: Diverse perspectives on AI from Rust contributors and maintainers

AIが「賢い大学生レベル」になっても、なぜ人は解雇されないのか AnthropicのCEO、ダリオ・アモデイ氏は「2年前のAIは賢い高校生レベル、今は賢い大学生レベル」と発言した。この言葉通りなら、カスタマーサポート（CS）市場はすでに壊滅していてもおかしくないはずだ。 ところが現実は正反対だ。米求人サイト「Indeed」のデータによれば、カスタマーサービス関連の求人数は2025年中盤から回復基調にあり、コロナ禍前の水準に近づきつつある。企業は大規模言語モデル（LLM）を大幅割引で利用できる環境があったにもかかわらず、人員削減ではなく再雇用を選んだのだ。 「90%自動化」プロジェクトが葬られた理由 ある元大手テック企業エンジニアの事例が示唆に富む。彼のチームはLLMとナレッジベースを組み合わせ、CSケースの90%を自動化するシステムを構築した。技術的には成功だった。しかしプロジェクトは却下された。 理由はシンプルだ。残り10%のケースこそが、CS担当者の時間の大半を消費していた。自動化できたのは「話せるFAQ」を作ることであり、本当に困難な問題の解決ではなかった。 「半決定可能問題」という見落とされた視点 この現象を理論的に説明する概念が「半決定可能（semi-decidable）」な仕事だ。ホワイトカラーの職種の多くはこの性質を持つ。 決定可能なケース（約80%）：過去の経験で解決できる、再現性のある問題。これはAIが得意とする領域で、自動化の恩恵を受けやすい。 決定不可能なケース（約20%）：解決策が存在するかどうか自体が不明な問題。対処に数日〜数週間かかることもあり、コストが青天井になる。 この「80/20の法則」こそ、AIが仕事を奪うという議論が見落としているポイントだと筆者は指摘する。簡単な仕事を効率化しても、困難なケースへの対処コストは変わらないか、むしろ浮き彫りになる。 ソフトウェアエンジニアリングも同じ構造 これはCS職に限った話ではない。ソフトウェアエンジニアリングでも、日常的なコーディング作業の大半はルーティンだ。しかし、例えば新しいフレームワークのバージョンアップ時に潜む「たった1つのboolean設定」が本番環境全体を落とすことがある。このような「決定不可能な問題」の発見と解決こそが、熟練エンジニアの真価であり、AIが代替しにくい領域だ。 まとめ 「AIがホワイトカラーの仕事をすべて奪う」という終焉論は、仕事の構造的な複雑さを無視した過度な単純化かもしれない。AIは確かに生産性を向上させるが、解決困難な問題が消えるわけではない。むしろ、AIが易しい問題を処理することで、人間は難しい問題に集中することを求められる時代になっているとも言える。 カスタマーサポートの求人回復は、その現実を雄弁に物語っている。 元記事: White-collar AI apocalypse narrative is just another bullshit

Microsoft、Windows 11の性能を本気で立て直す——2026年の大規模改善計画を正式発表 Microsoftは2026年3月20日、Windows 11の品質向上に向けた詳細なロードマップを公式ブログ「Our commitment to Windows quality」で公開した。RAM使用量の削減、UIレイテンシの低減、File Explorerの高速化、検索機能の安定性向上など、長年ユーザーから不満の声が上がっていた問題群に正面から取り組む内容となっている。 なぜ今、Microsoftは動いたのか 背景にあるのは、Appleとの競争激化と、Windows 11に対する根強いネガティブイメージだ。特に「MacBook Neo」の発表以降、SNSではWindowsのRAM管理や動作の滑らかさ、信頼性に関する批判が急増。2025年を通じたWindowsの品質低下が積み重なり、Microsoftにとって無視できない市場リスクとなっていた。 2026年1月にはWindows担当プレジデントのPavan Davuluri氏が「人々にとって意味のある形でWindowsを改善する必要がある」と公の場で認め、具体的な改善を約束していた。今回の発表はその約束を実行に移す段階となる。 主な改善内容 1. RAM使用量の削減 Windowsのベースラインメモリフットプリントを引き下げる。現状、8GBのPCではアイドル時にすでに約6GBをOSが消費しており、16GBのPCでも10GB超に達することがある。WhatsAppやDiscordといった人気アプリがElectronなどのWebラッパー（メモリ消費大）を採用している状況を踏まえると、OS側での最適化は急務だ。Microsoftは「高負荷時でも一貫したパフォーマンス」を実現すると約束しており、アプリの応答性向上が期待される。 2. WinUI 3への移行でUIレイテンシを削減 コアUIをWinUI 3（Windowsのモダンネイティブフレームワーク）へ移行し、クリックへの反応速度を改善する。WinUI 3はDirect Compositionを活用したハードウェアアクセラレーション描画に対応しており、アニメーションや操作のもたつきが改善される見込みだ。日本のPCユーザーにとっても、ウィンドウ操作やタスク切り替えの体感速度が向上するはずだ。 3. File Explorerの高速化 File Explorerは長らく「重い」「もっさりしている」という批判を受けてきた。今回の改善対象に含まれており、フォルダ遷移やファイル表示のレスポンスが向上する予定だ。 4. 検索機能の信頼性向上 検索が応答しない、結果がおかしいといった問題も改善対象となっている。 業界への影響 今回の発表に対し、MicrosoftのエンジニアやエグゼクティブがSNSで積極的に補足情報を発信しており、珍しくユーザーからの反応も好意的なものが目立つという。Windows 11のシェアを維持・拡大するためにも、2026年の改善が実際にどこまで体感できる形で届くかが今後の焦点になる。 日本でも法人・個人問わずWindowsユーザーは多く、特にRAM不足に悩む低スペックPCユーザーにとって、この改善は切実な朗報となりうる。今後のWindows Updateで段階的に展開される見込みで、続報が注目される。 元記事: Microsoft confirms Windows 11 will run faster under heavy load, reduce RAM usage, and feel more responsive

SamsungがAirDrop対応を発表——AndroidとiOSの壁がついに崩れるか Appleのファイル共有技術「AirDrop」は長年、iPhoneやMacユーザーが他のエコシステムへ移行しない理由のひとつとして挙げられてきた。近距離でのワイヤレスファイル転送をほぼシームレスに実現するAirDropは、Apple製品同士でしか使えない「囲い込み」の象徴的な機能だった。 ところが今回、SamsungがGalaxy端末の一部においてAirDropプロトコルのサポートを導入することが明らかになった。これが実現すれば、Androidスマートフォンを持つユーザーも、iPhoneやMacとの間で直接ファイルをやり取りできるようになる。 Quick ShareとAirDropの融合 Samsungはすでに「Quick Share（クイックシェア）」という独自のニアバイ共有機能を持っており、Galaxy端末間や対応するWindows PCとのファイル共有に使われてきた。今回のAirDropサポートはこのQuick Shareに統合される形で提供されると見られており、ユーザーは専用アプリを別途インストールする必要はないとみられる。 なぜ今このタイミングか 背景のひとつとして、EUのデジタル市場法（DMA: Digital Markets Act）の影響が考えられる。DMAはAppleをはじめとする大手プラットフォーム事業者に対し、相互運用性（インターオペラビリティ）の確保を求めており、Appleはすでに他社デバイスへのAirDrop的な連携を段階的に開放する方向で動いている。 日本でも、iPhoneのシェアは非常に高く（2024年時点で国内スマートフォン市場の約60〜70%）、家族や職場でiPhoneとAndroidが混在するシーンは珍しくない。AirDropの相互運用対応が進めば、こうした混在環境でのファイル共有の煩わしさが大幅に解消される可能性がある。 対応端末と提供時期 現時点では、対応するGalaxyデバイスの具体的なモデル名や提供時期の詳細は明らかになっていない。ただし「一部のGalaxy端末」から段階的に展開される見通しで、フラッグシップモデルのGalaxy S25シリーズなどが優先される可能性が高い。 Androidユーザーにとっての意味 これまでAndroidユーザーがiPhoneユーザーとファイルを共有するには、LINEやGoogle Drive、Bluetoothなどを経由する必要があり、AirDropのような直感的な体験にはほど遠かった。Samsung端末でAirDropが使えるようになれば、プラットフォームをまたいだファイル共有のハードルが大きく下がり、「iPhoneしか使えない」理由がひとつ減ることになる。 Appleの「壁」がどこまで崩れるのか——今後の動向に注目が集まる。 元記事: Good news for Samsung users: AirDrop support is finally here

Microsoftは本日、Microsoft Defenderにおける「エンドポイント機密データアラート（Endpoint Sensitive Data Alerting）」機能を正式に廃止した。この変更により、企業の情報セキュリティ担当者や管理者は、既存のアラートポリシーを新しい管理先へ移行する対応が求められている。 廃止される機能とは エンドポイント機密データアラートは、Microsoft Defender for Endpoint（MDE）において、エンドポイントデバイス上の機密情報に関わる操作を検知・通知する機能だ。たとえば、個人情報や財務データなどの機密ファイルが不審なプロセスによってアクセスされた際に管理者へ警告を発するといった用途で活用されてきた。 日本企業においても、個人情報保護法やマイナンバー法への対応として、エンドポイントセキュリティを強化するためにMicrosoft Defenderを導入している組織は多く、この廃止は無視できない変更点となる。 管理者が取るべき対応 Microsoftは既存のアラートポリシーを新しい管理先へ手動で移行するよう管理者に求めている。移行先については、Microsoft Purview コンプライアンスポータルが案内されており、データ損失防止（DLP: Data Loss Prevention）ポリシーや、Purview のインサイダーリスク管理機能との統合が推奨されている。 移行を怠った場合、既存のアラートポリシーが機能しなくなり、機密データの漏洩リスクを見逃す可能性がある。特に金融・医療・公共機関など、厳格なコンプライアンス要件を持つ組織では早急な対応が必要だ。 Microsoft Purview への統合という大きな流れ この廃止は、Microsoftがセキュリティ・コンプライアンス機能をMicrosoft Purviewに集約するという戦略の一環だ。近年、MicrosoftはDefenderとPurviewの連携を強化しており、機密データの保護・検出・対応を一元管理できる体制への移行を進めている。 管理者はMicrosoft 365管理センターまたはMicrosoft Purviewポータルから移行手順を確認し、できるだけ早くポリシーの移行作業を完了させることが推奨される。 元記事: Microsoft retires endpoint sensitive data alerting in Defender today

Linux 7.0開発が最終段階へ、RC5でドライバ・コア更新が一段落 Linuxカーネルの次期メジャーバージョン「Linux 7.0」の開発が安定期に入った。開発者のLinus Torvalds氏は、第5リリース候補版（RC5）の公開にあわせてメーリングリストへのメッセージを投稿し、「今週は比較的穏やかだった」と開発状況を評価した。 ドライバとコアの大規模更新を経て落ち着き 直前のRC4までは、各種デバイスドライバやカーネルコアへの変更が集中的に取り込まれる慌ただしい時期が続いていた。RC5では新たな問題報告も減少し、主にバグ修正と細かな最適化が中心となっている。これはリリース候補サイクルとして正常な推移であり、最終リリースへのカウントダウンが始まったと見てよい。 Linux 7.0が持つ意味 Linuxカーネルのバージョン番号は、6.x系が2022年の6.0リリースから続いており、7.0への移行はメジャーバンプとして注目を集めている。ただし、Linuxのバージョン番号は純粋に「キリが良くなったから」という慣例的な理由で上がることも多く、7.0だからといって技術的な断絶があるわけではない。それでも、サーバー・組み込み・デスクトップ問わずLinuxを利用する日本企業や開発者にとって、新しいドライバサポートやパフォーマンス改善は実用上の恩恵をもたらす。 今後のスケジュール Linuxカーネルの開発サイクルは通常、RC1からRC7〜8程度を経て正式版がリリースされる。RC5が「穏やか」な状態であれば、残り数週間のうちに正式版がリリースされる見通しだ。Torvalds氏は引き続きRC6以降の進捗をメーリングリストで報告する予定。 UbuntuやFedora、Arch Linuxなど主要ディストリビューションへの搭載は、それぞれのリリーススケジュールに依存するが、Linux 7.0の動向は今後のディストリビューション選定にも影響を与えそうだ。 元記事: Linux 7.0 development stabilizes as Linus Torvalds reports calmer fifth release candidate

ChromeのABE保護を新手法で突破する「VoidStealer」が登場 セキュリティ研究機関のGen Digital（Norton・Avast・AVG・Aviraの親会社）は、情報窃取型マルウェア「VoidStealer」がGoogle Chromeの**Application-Bound Encryption（ABE）**をこれまでにない手法で回避していることを報告した。 ABEとは何か Googleは2024年6月リリースのChrome 127でABEを導入した。これはCookieや認証トークンなどの機密データを保護する仕組みで、マスターキーをディスク上で暗号化したまま保持し、通常のユーザーレベルのアクセスからは復号できないようにしている。復号にはSYSTEM権限で動作する「Google Chrome Elevation Service」による検証が必要だ。 しかしABEはこれまでも複数のインフォスティーラーやオープンソースツールによって回避されてきた歴史がある。Googleは都度修正を施してきたものの、新たな手法による回避が繰り返されている。 ハードウェアブレークポイントによる新たな攻撃手法 VoidStealerのアプローチが特異なのは、特権昇格もコードインジェクションも必要としない点だ。Gen Digitalの脅威研究者ヴォイチェフ・クレイサ氏によれば、本マルウェアは「野外で観測された中で初めて、ハードウェアブレークポイントを利用してブラウザのメモリから直接v20_master_keyを抽出するデバッガーベースのABE回避技術を採用したインフォスティーラー」だという。 具体的な手順は次のとおりだ。 サスペンド状態の隠しブラウザプロセスを起動し、デバッガーとしてアタッチ 対象のDLL（chrome.dllまたはmsedge.dll）のロードを待機 DLL内の特定文字列とLEA命令を走査し、ハードウェアブレークポイントを設置 ブラウザ起動時にABE保護データが復号されるタイミングでブレークポイントが発火 ReadProcessMemoryでレジスタから平文のv20_master_keyを読み取り抽出 ブラウザ起動時は保護されたCookieを早期に読み込むためマスターキーの復号が強制的に発生する。VoidStealerはこの「一瞬だけ平文でメモリに存在する状態」を狙い撃ちにする。 オープンソースツール「ElevationKatz」との関係 Gen Digitalの分析では、この手法はChromeのCookieダンプツールセット「ChromeKatz」に含まれるオープンソースプロジェクト「ElevationKatz」をベースにしている可能性が高いとしている。ElevationKatzは1年以上前から公開されており、VoidStealerはそれを攻撃者向けに実装し直したとみられる。 MaaSとして拡散中 VoidStealerは**Malware-as-a-Service（MaaS）**として2025年12月中旬からダークウェブフォーラムで販売されており、バージョン2.0でこの新しいABE回避機能が追加された。 対策と今後の展望 BleepingComputerはGoogleにコメントを求めたが、本稿執筆時点では回答は得られていない。特権昇格不要・コードインジェクション不要という特性から、従来のエンドポイント検出との相性が悪く、検知が難しい攻撃手法といえる。ブラウザに保存された認証情報やCookieへの依存を減らし、ハードウェアセキュリティキーやパスキーの活用を検討することが望ましい。 元記事: VoidStealer malware steals Chrome master key via debugger trick

Microsoftは2026年3月21日、Microsoftアカウントのサインインが失敗する深刻な不具合を修正する緊急更新プログラム「KB5085516」を公開した。 不具合の概要 今月のパッチチューズデー（定例セキュリティ更新）として配信された累積更新プログラム「KB5079473」を適用後、Teams、OneDrive、Microsoft Edge、Microsoft 365 Copilot、ExcelやWordなどのOfficeアプリでサインインができなくなる事象が報告されていた。 エラーメッセージには「インターネット接続が必要です。インターネットに接続されていないようです（You’ll need the Internet for this. It doesn’t look like you’re connected to the Internet.）」と表示されるが、実際にはデバイスはインターネットに正常に接続されており、誤検知であることが判明している。 影響を受けるユーザー この問題はMicrosoftアカウント（個人・Teams無料版など）を使用している場合のみ発生する。企業環境でEntra ID（旧Azure Active Directory）を使って認証している場合は影響を受けない。 日本でも個人利用や中小企業でMicrosoftアカウントを利用しているケースは多く、特に「Teams無料版」を業務で活用しているユーザーは注意が必要だ。 修正方法 Microsoftは暫定的な回避策として「PCを再起動する」ことを案内していたが、今回のKB5085516の適用により根本的な修正が提供された。 更新プログラムはWindows 11バージョン25H2および24H2を対象としており、以下の方法で適用できる。 Windows Update：設定 → Windows Update から「更新プログラムのチェック」 Microsoft Update カタログ：手動でKB5085516を検索してダウンロード なお、今回の更新にはパッチチューズデーで配信されたすべてのセキュリティ修正も含まれている。 相次ぐ緊急パッチ 今月のパッチチューズデー以降、Microsoftは複数の緊急対応を余儀なくされている。Bluetoothデバイスの認識問題やRRAS（ルーティングとリモートアクセスサービス）のセキュリティ脆弱性に対するホットパッチ、さらに一部のSamsung製Windows 11ノートPCでCドライブにアクセスできなくなる問題への対処など、異例の頻度で修正が続いている。 Windows Updateを自動更新に設定していないユーザーは、手動での適用を強く推奨する。 元記事: New KB5085516 emergency update fixes Microsoft account sign-in

CISA、DarkSword関連のiOS脆弱性3件を「積極的に悪用されている脆弱性カタログ」に追加 米国サイバーセキュリティ・インフラセキュリティ庁（CISA）は、iOSの脆弱性3件を「積極的に悪用されている既知の脆弱性（KEV）カタログ」に追加し、連邦文民行政府（FCEB）機関に対して2週間以内——具体的には2026年4月3日まで——のパッチ適用を義務付けた。 DarkSwordとは何か DarkSwordは、iPhoneを標的とした高度なエクスプロイト配信フレームワークだ。先週、Googleの脅威インテリジェンスグループ（GTIG）とセキュリティ企業iVerifyの研究者が詳細を公開した。このフレームワークは合計6件の脆弱性チェーン（CVE-2025-31277、CVE-2025-43529、CVE-2026-20700、CVE-2025-14174、CVE-2025-43510、CVE-2025-43520）を組み合わせて利用し、サンドボックス回避・権限昇格・リモートコード実行を可能にする。 Appleはすでに最新のiOSリリースで全脆弱性を修正済みだが、iOS 18.4〜18.7を実行しているiPhoneはいまだ影響を受けるため、迅速なアップデートが求められる。 3つのマルウェアファミリーと攻撃グループ GTIGの調査によると、DarkSwordを通じて感染端末に投下されるマルウェアは以下の3種類だ。 GhostBlade — 非常に攻撃的なJavaScriptベースの情報窃取型マルウェア GhostKnife — 大量のデータを外部に持ち出すバックドア GhostSaber — コード実行とデータ窃取を兼ねるJavaScript型マルウェア 攻撃グループとしては、トルコの商用スパイウェアベンダー「PARS Defense」の顧客とされるUNC6748と、ロシアのスパイ活動グループと疑われるUNC6353が関与していることが判明している。UNC6353はウォータリングホール攻撃を展開しており、ウクライナのECサイト・産業機器・地域サービス系のウェブサイトを侵害してiPhoneユーザーを狙っていた。 また、DarkSwordは感染後に一時ファイルを消去して終了する設計になっており、短期間の監視オペレーションと検知回避を意図した作りになっていると研究者らは指摘する。 CISAの対応と民間企業への呼びかけ CISAは今回、6件の脆弱性のうちCVE-2025-31277、CVE-2025-43510、CVE-2025-43520の3件をKEVカタログに登録。拘束的運用指令（BOD 22-01）に基づき、FCEB機関に対して「ベンダー指示に従ったパッチ適用、またはクラウドサービス向けBOD 22-01ガイダンスの遵守。緩和策が利用できない場合は製品の使用を中止すること」と警告した。 BOD 22-01の適用対象は連邦機関に限られるが、CISAは民間企業を含むすべての組織に対しても、できる限り早急にデバイスを保護するよう強く求めている。 日本のユーザーへの影響 iPhoneは日本国内でも高いシェアを持つ。iOS 18.4以降を使用しているユーザーは、設定アプリから**「一般」→「ソフトウェアアップデート」**を確認し、最新バージョンへのアップデートを今すぐ行うことが推奨される。特に企業のモバイルデバイス管理（MDM）担当者は、管理下にある端末のOSバージョンを速やかに確認してほしい。 元記事: CISA orders feds to patch DarkSword iOS flaws exploited attacks

FBIが緊急警告：TelegramがC2インフラに悪用されるイラン系サイバー攻撃 米連邦捜査局（FBI）は3月23日、イランの情報省（MOIS）と連携するハッカーグループが、マルウェア攻撃のコマンド＆コントロール（C2）インフラとしてメッセージングアプリ「Telegram」を悪用していると警告を発した。 攻撃の概要 FBIのフラッシュアラートによると、このTelegramを利用したC2インフラは、イラン政府を批判するジャーナリスト、イラン反体制派、および世界各地の反政府組織を標的としたWindowsマルウェアに組み込まれているという。 攻撃者はソーシャルエンジニアリングの手口で標的のデバイスにマルウェアを感染させ、スクリーンショットやファイルの窃取（exfiltration）を実行する。感染後の被害はスパイ活動による情報収集、データ漏洩、そして標的組織の評判失墜に及んでいる。 関与が疑われる脅威アクター FBIは以下の2グループを今回の攻撃に関与するとして特定した： Handalaハクティビストグループ（別名：Handala Hack Team、Hatef、Hamsa）：イランと連携する親パレスチナのハクティビスト集団 Homeland Justice：イラン・イスラム革命防衛隊（IRGC）と紐付けられた国家支援型の脅威アクター 押収されたドメインとStryker攻撃との関連 今回の警告は、FBIが4つのドメイン（handala-redwanted[.]to、handala-hack[.]to、justicehomeland[.]org、karmabelow80[.]org）を押収した翌日に公表された。これらのサイトはHandala、Homeland Justice、および「Karma Below」という第三の脅威アクターが米国内外の被害者から盗んだ機密文書やデータの漏洩に利用していた。 一連の動きの背景には、Handalaによる米国医療大手Stryker社への大規模サイバー攻撃がある。攻撃者はWindowsドメイン管理者アカウントを侵害して新たなグローバル管理者アカウントを作成、Microsoft Intuneのワイプコマンドを悪用して社員の個人PCやモバイルデバイスを含む約8万台のデバイスを工場出荷状態にリセットするという壊滅的な被害をもたらした。 ロシア系攻撃との並行性 同週、FBIはロシア情報機関と連携した脅威アクターによるSignalおよびWhatsAppユーザーを標的にしたフィッシングキャンペーンについても警告を発しており、すでに数千件のアカウント侵害が確認されている。標的は現・元米政府高官、軍関係者、政治家、ジャーナリストなど「高い諜報価値を持つ個人」とされている。 防御のポイント FBIは中東の地政学的緊張の高まりを背景に、この種の攻撃が今後も継続・拡大する可能性を示唆。ネットワーク防御担当者に対し、不審なTelegramとの通信のモニタリングや多要素認証（MFA）の徹底など、具体的な緩和策の実施を促している。 日本国内でも反政府的・政治的な活動を行う組織や研究者、ジャーナリストがターゲットになり得るため、同様の脅威インテリジェンスに注視することが求められる。 元記事: FBI warns of Handala hackers using Telegram in malware attacks

「なぜ誰もWindowsネイティブアプリを書かないのか」——現役開発者が語る混沌の実態 Chromiumの開発に携わったこともあるベテラン開発者のDomenic氏が、自作のWindowsユーティリティ「Display Blackout」を開発した経験をもとに、Windowsネイティブアプリ開発の現状を赤裸々に語ったブログ記事が、Hacker Newsで400以上のポイントを獲得し大きな反響を呼んでいる。 マルチモニター環境向けユーティリティを作ってみたら…… Display Blackoutは、3画面環境でゲームプレイ中に左右のモニターを「ブラックアウト」するシンプルなツールだ。OLEDディスプレイでは真っ黒な画面を表示することで実質的にピクセルをオフにできる。機能要件は、ディスプレイの列挙、ボーダーレスウィンドウの配置、グローバルホットキー、スタートアップ起動、設定の永続化、システムトレイアイコンの表示——いずれもシンプルに見える。 しかし開発を始めると、技術選択の段階から地獄が口を開けていた。 Windowsプログラミングの「地層」 WindowsのUI開発スタックは、歴史的な地層のように積み重なっている。 Win32 API（1990年代〜）: C言語ベースの原始的なAPI。今も現役で使われている MFC（Microsoft Foundation Classes）: C++でWin32をラップしたライブラリ Windows Forms（.NET 1.0 / 2002年）: Win32コントロールのC#ラッパー WPF（.NET 3.0 / 2006年）: XAMLによるマークアップとGPUレンダリングを導入した刷新版 UWP（Universal Windows Platform / 2015年）: Windows 10向けの「次世代」プラットフォーム WinUI 3（2021年〜）: UWPのUIレイヤーを切り出したもの 問題は、これらが互いに競合し、それぞれ異なる制限を抱えており、Microsoftが何度も「これが未来だ」と宣言しながら方針転換を繰り返してきた点だ。 UWPという「失われた10年」 特に批判が集中するのがUWP（ユニバーサルWindowsプラットフォーム）だ。Windows 10と同時に登場し、Microsoftが全力で推進したにもかかわらず、サンドボックス制限の厳しさや既存APIとの非互換性から開発者に敬遠され、事実上の失敗に終わった。Win32 APIの多くの機能がUWPサンドボックスから使えず、グローバルホットキーのような基本的な機能の実装にすら回り道が必要だった。 なぜElectronが選ばれるのか この混沌が、Electron（Webテクノロジーを使ったデスクトップアプリフレームワーク）が広く普及した理由を雄弁に物語っている。VS Code、Slack、Discord——著名なデスクトップアプリの多くがElectronを採用しているのは偶然ではない。メモリ消費が大きいという批判はあれど、単一のコードベースでクロスプラットフォーム対応でき、Web標準という安定した基盤の上に乗れるというメリットは絶大だ。 日本の開発者への示唆 Windowsデスクトップアプリを業務システムとして開発・保守している日本企業にとっても、この問題は他人事ではない。WPFで書かれた社内ツールがWinUI 3へ移行できずにいる、UWPで開発した資産が宙ぶらりんになっているといった状況は珍しくない。Microsoftが「次世代」を何度宣言しても、10年後に同じ問題に直面する可能性は十分にある。 Microsoftには、開発者が安心して長期投資できる一貫したビジョンが求められている。 元記事: Windows native app development is a mess

Microsoft Entra ID バックアップ＆リカバリー、静かにプレビュー開始 Microsoftは2026年3月19日、Entra IDオブジェクトのバックアップと復元を行う新機能「Microsoft Entra Backup and Recovery」のプレビューをテナントに展開した。Entra管理センターから利用できるが、大々的なアナウンスはなく、技術コミュニティで話題になってから翌20日にRSAカンファレンス向け発表の中でさりげなく言及されるという異例のデビューとなった。 何がバックアップされるのか 対象となるのは「コアテナントオブジェクト」と呼ばれるディレクトリの根幹部分だ。具体的には以下が含まれる： ユーザー・グループ アプリケーション・サービスプリンシパル 条件付きアクセスポリシー 認証メソッド・承認ポリシー 名前付き場所・組織設定 Exchange OnlineやSharePoint Onlineのようにメールやファイルデータを抱えるワークロードとは異なり、Entra IDはオブジェクトの構成情報が主体のため、同等の機能をより少ないストレージで実現できる。 バックアップの仕様 頻度: 1日1回自動実行（時刻はテナントごとに異なり、現時点では変更不可） 保持数: 直近5世代（最大5日分）のローリング保持 無効化: プレビュー段階では不可、すべて自動 必要ライセンス: Entra P1 または P2（一部テナントではライセンス不問でも利用可能との報告あり） 必要ロール: 新設の「Entra Backup Reader」管理ロール 差分レポートで復元判断を支援 特徴的なのが差分レポート機能だ。現在のオブジェクト状態と選択したバックアップ時点との差分をレポートとして生成し、「どのバックアップから復元すべきか」の判断材料を提供する。 例えば、エンタープライズアプリ（サービスプリンシパル）が不正に追加された場合、差分レポートにはそのオブジェクトが表示され、復元操作では「ソフトデリート（論理削除）」が実行される。誤操作を防ぐため、復元処理がハードデリートを行うことはない。 現時点での課題として、レポート生成に時間がかかる点が挙げられている。小規模テナントでも75分以上を要するケースが確認されており、GA（一般提供）に向けた改善が期待される。 日本のテナント管理者への影響 Microsoft 365を利用する日本企業にとって、Entra IDのオブジェクト保護は長年の課題だった。ランサムウェア攻撃や誤操作によるアカウント・ポリシーの破損は深刻なインシデントにつながりうるが、従来は条件付きアクセスポリシーなどの設定を手動でバックアップするか、サードパーティ製品に頼るしかなかった。 Microsoft純正の自動バックアップ機能が追加されることで、基本的な保護はプラットフォーム側が担う形になる。一方、5日間という保持期間はコンプライアンス要件によっては不十分な場合もあり、より長期の保持ニーズへの対応は今後の課題だ。 GA（一般提供）の時期や追加機能については、今後のアナウンスに注目したい。 元記事: Low-Key Debut for Entra ID Backup and Recovery

AIコード生成の評価問題を「実行」で解決 AIが生成したコードの品質を正確に評価するのは、実は非常に難しい問題だ。コードが文法的に正しく見えても、実際に動かしてみると想定外のバグが潜んでいたり、エッジケースで失敗したりすることは珍しくない。 この課題に取り組むため、Hugging FaceのBigCodeチームはBigCodeArenaを発表した。「人間参加型（Human-in-the-Loop）」のコード生成モデル評価プラットフォームとして、これが初めての試みとなる。 従来のベンチマークの限界 これまでのコード生成評価には主に2つのアプローチがあった。 HumanEval等のベンチマーク: あらかじめ用意されたテストケースでコードを採点するが、現実の多様なプログラミングタスクのごく一部しかカバーできない 人手評価: ソースコードを読んで頭の中で実行をシミュレートするのは認知負荷が高く、複雑なUIアプリや長いプログラムになるほど精度が落ちる たとえば「レスポンシブなフォトギャラリーサイトを作って」と2つのAIに頼んだとき、両方のコードが一見正しく見えても、実際にブラウザで表示して初めて違いが分かることがある。片方は美しいグリッドレイアウトを実現し、もう片方はスタイリングのバグで崩れているかもしれない。実行なしには判断できないのだ。 BigCodeArenaの仕組み BigCodeArenaはLMArena（Chatbot Arena）のフレームワークを拡張し、コード評価特有の機能を追加している。 リアルタイム実行とサンドボックス環境 生成されたコードはすべて、分離されたサンドボックス環境で自動実行される。Pythonスクリプト、ReactのWebアプリ、PyGameのゲーム、C++のアルゴリズムなど、ソースコードではなく実際の出力結果をユーザーが確認できる。 幅広い言語・フレームワーク対応 現在サポートされている言語・環境は以下の通り。 対応言語（10種）: Python、JavaScript、TypeScript、HTML、C、C++、Java、Go、Rust、Markdown Webフレームワーク: React、Vue、バニラHTML/CSS/JS Pythonフレームワーク: Streamlit、Gradio、PyGame 図表: Mermaid 汎用インタープリタ: PythonおよびJavaScriptのコードインタープリタ、コンパイル言語ランナー インタラクティブなテスト Webアプリのボタンをクリックしたり、生成されたゲームをプレイしたり、コードを直接編集して再実行したりと、静的なコード比較では不可能なインタラクティブな検証が可能だ。 マルチターン対話 現実のプログラミング作業と同様に、要件の追加や機能変更、バグ修正の依頼といったマルチターンの対話にも対応している。 5カ月で見えてきた傾向 2025年2月の公開から約5カ月間で、500人以上のユニークユーザーから14,000件以上の会話データと4,700件以上の高品質な優劣投票が集まった。最先端LLM（大規模言語モデル）10種類が評価対象となっている。 ユーザーが持ち込むタスクの内訳は多岐にわたる。 Webデザイン（36%）: レスポンシブなWebサイト、インタラクティブなダッシュボード 問題解決（23%）: アルゴリズム、データ構造、計算チャレンジ ゲーム開発（16%）: ゲームロジックやUIの実装 日本の開発者コミュニティへの示唆 BigCodeArenaは誰でも無料で利用でき、コミュニティの投票結果がリーダーボードとして公開される。GitHub CopilotやCursorといったAIコーディング支援ツールを日常的に使う開発者にとって、「どのモデルが実務で最も役立つか」を判断する際の参考資料として活用できるだろう。 日本語でのコード生成評価については今後の展開が注目されるが、まずはコード評価の新たなスタンダードとなりうる取り組みとして、その動向を追っていきたい。 元記事: BigCodeArena: Judging code generations end to end with code executions

Hugging FaceとVirusTotal、AIモデルのセキュリティ強化で連携 オープンソースAIプラットフォームのHugging Faceは、世界最大規模の脅威インテリジェンス・マルウェア分析プラットフォーム「VirusTotal」との連携を発表した。この取り組みにより、Hugging Face Hub上で共有される全ファイルのセキュリティが強化される。 220万超のモデルが継続的にスキャン対象に 現在、Hugging Face Hubには220万を超える公開モデル・データセットリポジトリが存在する。今回の連携により、これら全リポジトリのファイルがVirusTotalのデータベースと照合され、継続的にセキュリティチェックが行われる。 ユーザーがリポジトリやファイルのページを訪問すると、Hubは自動的にVirusTotalから対応ファイルの情報を取得し、結果を表示する仕組みだ。 AIモデルが持つセキュリティリスク AIモデルは強力なツールである一方、大規模なバイナリファイルやシリアライズされたデータ、依存ライブラリなどを含む複雑なデジタル成果物でもある。具体的な脅威として以下が挙げられている。 モデルファイルやアーカイブに偽装した悪意あるペイロード アップロード前にすでに改ざんされたファイル 既知のマルウェアキャンペーンに関連するバイナリ ロード時に危険なコードを実行するシリアライズオブジェクト Pickle形式など機械学習でよく使われるシリアライゼーション形式は、任意コード実行の脆弱性が以前から指摘されており、セキュリティ上の懸念は日本のAI開発現場でも共有されている課題だ。 プライバシーを守りながら脅威を検出 ファイルの検出方法はハッシュ照合方式を採用している。ファイルの内容そのものをVirusTotalに送信するのではなく、ファイルハッシュ値をデータベースと比較することで、ユーザーのプライバシーとデータ保護原則を維持しながら脅威情報を取得する。 過去にVirusTotalで解析済みのファイルであれば、そのステータス（クリーンか悪意あるか）、検出数、関連する脅威キャンペーン情報などが確認できる。 組織のCI/CDパイプラインへの統合も視野に この連携はエンドユーザーの安全確保にとどまらず、企業・組織のワークフローへの統合も想定している。CI/CDパイプラインやデプロイプロセスにVirusTotalのチェックを組み込むことで、悪意あるアセットの拡散を防ぐ仕組みが構築できる。 モデルのダウンロードや統合の前に脅威情報を確認できる透明性の向上、重複スキャンを減らす効率化、そしてオープンソースAIコミュニティ全体への信頼醸成が、この協業の主な目的となっている。 詳細や貢献については security@huggingface.co に問い合わせできる。 元記事: Hugging Face and VirusTotal collaborate to strengthen AI security