AI Daily Digest

iPhone 16 Pro MaxでMLX推論が壊れる原因：ハードウェアバグとその修正

何が起きたか

iPhone 16 Pro Max上でAppleのMLXフレームワークを使いLLMを実行すると、「Applied.....*_dAK[...]」のようなゴミ出力が生成される現象が報告されました。同一コードをiPhone 15 Proで実行すると正常に動作し、テンソルの数値が桁違いにずれていることが判明しています。

原因はMLXのGPU演算処理にあったバグで、修正PRが数日前にマージされました。ただし、記事の筆者はA18チップのNeural Engineに帰因していますが、HNのコメントでは「MLXはGPU（Metal）ベースでありANEは使っていない」という指摘が複数出ています。

要点

テンソル出力の比較がこの問題を端的に示しています。同じ入力に対し、iPhone 15 Proでは[[53.875, 62.5625, -187.75, ...]]、iPhone 16では[[191.5, 23.625, 173.75, ...]]と、値が桁単位で乖離していました。

低レベルの数値演算最適化は、チップ世代やドライバのバージョンで結果がずれることがあります。Intelも2013年の文書で再現性の問題を解説しています。ただ、LLMは量子化に対する耐性が高いはずで、ここまで崩壊するのは通常ではありません。

この件はMLXの特定コミットで修正されていますが、「同じiPhoneモデルの別個体ではどうか」というテストが行われていない点は、HNでも指摘されています。

なぜ重要か

オンデバイスLLM推論の需要は確実に増えています。Apple Intelligence、MLX、llama.cppなど、端末上で動かす選択肢が広がる一方で、ハードウェア起因の推論エラーはデバッグが極めて困難です。ソフトウェアのバグならログで追えますが、GPUの演算結果がずれると「出力が壊れた」としか見えません。

ローカル推論を業務に組み込む場面が増えるほど、この種の問題は見逃せなくなります。

所感

ハードウェアではなくMLX側のバグだった、という結末は救いがあります。ただ、筆者がAppleCareで交換した個体でも再現したという話が正しければ、特定のA18チップとMLXの組み合わせで踏む地雷だった可能性があります。端末上のLLM推論を「動くから本番で使う」と決める前に、別デバイスでのクロスバリデーションは必須でしょう。

用語メモ

MLX

AppleがAppleシリコン向けに開発した機械学習フレームワーク。
この記事ではiPhone上でのLLM推論基盤として登場。

Metal

AppleのGPUプログラミングAPI。
この記事ではMLXがGPU演算に使うバックエンドとして言及。

AIユーザーは「道具派」と「丸投げ派」に分かれ始めている

概要

Martin Alderson氏のブログ記事が、AIツールのユーザーが2タイプに分かれつつあるという観察を示し、HNで296コメントの活発な議論を呼んでいます。

「道具派（Tool Users）」はAIの限界を理解しつつ、ボイラープレートコード生成やリサーチの下準備などの特定タスクに使います。システム全体をAIで生成しても、アーキテクチャの把握は自分で維持するタイプです。

もう一方の「丸投げ派（Outsourcers）」は、ドメイン知識なしに思考プロセスごとAIに委ね、出力だけに関心を持ちます。

先に押さえる3点

• 道具派の中には「新しい10xエンジニア」と呼べる層が出現。技術的背景がなくてもドメイン知識が深ければ、AIで本番レベルのシステムを構築する例がある
• ある非技術職のCFOがClaude Codeで業務ダッシュボードを構築し、ローコードツールや外注では実現できなかった成果を上げた事例が紹介されている
• 30シートのExcel財務モデルをPythonに「ほぼワンショット」で移植する行為には、エッジケース見落としのリスクがある。過去にはExcelの計算ミスが欧州の経済政策に影響した前例も

影響

この議論で見えてくるのは、AI導入が組織構造に与える影響です。大企業では承認プロセスやレガシーコードの壁があり、AIの生産性向上がシニアエンジニアのレビュー負荷に吸収されてしまう、という声がHNに出ています。

もう一つの懸念は人材パイプラインです。ジュニア開発者がAIに置き換わると、8年後にはシニア人材が枯渇する可能性があります。ジュニアが成長する機会そのものが失われるためです。

HNでは「第三のタイプ」として、AIをラバーダッキングや壁打ちの相手として使う層を指摘する声もありました。コード生成ではなくブレインストーミングに使う使い方です。

実務メモ

社内のAI利用を「ツール利用」と「丸投げ」のどちらが多いか、一度棚卸しする価値はあります。丸投げ型の利用が増えると、コードレビューの負荷が上がる一方でレビュアーの判断力も鈍りがちです。チームのAI利用ガイドラインを作るなら、「出力の検証プロセス」をセットにしておくのが現実的でしょう。

用語メモ

ラバーダッキング

アヒルのおもちゃに問題を説明することでバグを発見するデバッグ手法。
この記事ではAIを壁打ち相手として使う文脈で登場。

シャドーAI

企業のIT部門が把握していないAIツールを従業員が独自に利用する現象。
この記事ではガバナンスリスクの文脈で言及。

Claude CodeがMicrosoft社内に急拡大：自社Copilot離れの実態

ざっくり言うと

Microsoftが社内でAnthropicのClaude Codeを大規模に導入し始めた、というThe Vergeの報道です。数千人規模の従業員に対し、「Claude CodeとGitHub Copilotの両方を使ってフィードバックを出してほしい」という指示が出ています。開発者でない社員にもコーディングを促すという、これまでのMicrosoftからは想像しにくい動きです。

ポイントは3つ

• Microsoftは2025年6月からClaude Sonnet 4を開発部門で採用。その後GitHub Copilotの有料ユーザー向けにも展開し、今やAnthropicの最大顧客の一つに
• Claude CodeのARRは2025年末時点で10億ドル超を達成済み。Anthropic全体のARRの約12%を占める規模
• ナデラCEOの内部メールでは、CopilotのGmailやOutlookとの連携が「ほとんど機能しない」「スマートではない」と評されている

どこに効く？

これは1月27日にClaude Codeで10万行のTypeScript→Rust移植が話題になった流れの延長線上にあります。Karpathy氏のClaude利用メモでも「エージェントは疲れない」という評価がありましたが、Microsoft社内で実際に大規模採用が進んでいるという報道は、これまでの個人レベルの評判とは質が異なります。

Claude Code製品自体の90%がAnthropicの自社AIモデルによって書かれている、という情報も注目に値します。AIがAI開発ツールを作る循環が始まっています。

一言

自社で数十億ドルをOpenAIに投資しておきながら、社内の開発者にはAnthropicの製品を使わせる。この矛盾が428コメントの火種になっています。Copilotのブランド乱立（Microsoft Copilot、GitHub Copilot、Microsoft 365 Copilot、Copilot CLI...）が混乱に拍車をかけている、という指摘も鋭いところです。

用語メモ

ドッグフーディング

自社製品を社内で使って品質を検証する慣行。
この記事ではMicrosoftがCopilotの代わりにClaude Codeを使う状況の文脈。

ARR

Annual Recurring Revenue（年間経常収益）。SaaS企業の規模を測る指標。
この記事ではClaude Codeが10億ドル超を達成した文脈で登場。

MicrosoftがWindows 11のAI機能を縮小方向へ：Copilot削減とRecall見直し

まず結論

MicrosoftがWindows 11におけるAI機能の方針を転換します。Copilotボタンの削減、デフォルトアプリへのCopilot統合の凍結、そしてRecall機能の見直しが報じられています。テレメトリデータが示す「ほとんどのユーザーがAI機能を使っていない」という事実が背景にあります。

変わった点

Windows 11のインターフェース全体に配置されていたCopilotボタンが削減されます。メモ帳やペイントへのCopilot統合も「合理化の対象」としてレビュー中です。さらに、他のデフォルトアプリへのCopilot機能追加は凍結されました。

Recall機能についても再評価が進んでおり、一部の報道では完全廃止の可能性も示唆されています。方針の軸足は「AIの機能追加」から「安定性、リグレッション削減、基盤コンポーネントの品質向上」に移りました。

注意点

この報道を「MicrosoftがAIから撤退する」と読むのは誤りです。OSレベルの「AIボタン乱立」を整理するだけで、エージェント型プラットフォームのビジョン自体は維持しています。セマンティックAI検索も引き続き開発が進んでいるとされています。

1月31日にOpenAIがGPT-4o・GPT-4.1をChatGPTから引退させたニュースと併せて見ると、AI企業各社が「機能の整理統合」フェーズに入りつつある印象があります。

使うならこうする

Windows 11のAI機能を業務フローに組み込んでいる場合は、今後のアップデートで機能が消える可能性を想定しておくべきです。Recall機能を前提としたワークフローは特に注意が必要です。代替手段の検討を早めに始めておきましょう。

用語メモ

Windows Recall

画面を定期的にキャプチャし、セマンティック検索を可能にするWindows 11の機能。
この記事では廃止の可能性が報じられている文脈で登場。

テレメトリ

ソフトウェアの利用状況を収集・分析するシステム。
この記事ではAI機能の利用率が低いことを示すデータとして言及。

Nano-vLLM：vLLM推論エンジンの仕組みを1200行のPythonで理解する

何が起きたか

DeepSeekのエンジニアであるXingkai Yu氏が、vLLM（LLM推論エンジン）のコアアーキテクチャを約1200行のPythonで再実装した「Nano-vLLM」を公開しました。GitHubで9,300スターを超え、急速に注目を集めています。

要点

vLLMはLLM推論のデファクトスタンダードですが、内部構造がブラックボックス化しており、スケジューリング・キャッシュ・並列化の戦略を理解・拡張するのが難しいという問題がありました。Nano-vLLMはこれを「読めるコード」に落とし込んでいます。

主要コンポーネントは3つです。Schedulerがリクエストのキュー管理とバッチ決定を担当し、ModelRunnerがGPUメモリとKVキャッシュの管理・フォワードパス実行を行い、Sequenceがリクエストの状態を保持します。

最適化としてはプレフィックスキャッシュ、テンソル並列化、torch.compileによる演算融合、CUDAグラフによるデコードループの高速化が実装されています。

なぜ重要か

RTX 4070 Laptop GPUでQwen3-0.6Bを動かしたベンチマークでは、Nano-vLLMが1,434 tok/sec、フルのvLLMが1,362 tok/secと、ミニマル実装が本家をわずかに上回る結果が出ています。

実運用でNano-vLLMを使う場面は限られますが、推論エンジンの内部構造を学ぶ教材としての価値は高いです。スケジューリングやキャッシュ戦略のカスタマイズを試したい場合のサンドボックスとしても機能します。

所感

「nano-○○」系のプロジェクトが増えているのは良い傾向です。GPTを理解するためのnanoGPT、Transformerを理解するためのminGPTに続くアプローチで、「読んで理解できる」というのは最高の学習リソースでしょう。ただし、HNではブログ記事がAI生成っぽいと指摘され、著者が「非ネイティブなので文法チェックにLLMを使っただけ」と釈明する場面もありました。AI利用の透明性が問われる時代です。

用語メモ

vLLM

PagedAttentionを採用した高性能LLM推論エンジン。
この記事ではNano-vLLMの再実装対象として登場。

PagedAttention

KVキャッシュをページ単位で管理し、メモリ効率を高めるAttention手法。
この記事ではNano-vLLMのブロック管理ロジックの背景として言及。

CUDAグラフ

GPU処理のカーネル起動オーバーヘッドを削減する最適化手法。
この記事ではデコードフェーズの高速化技術として登場。

マルチエージェントは本当に有効か：Googleが示すスケーリングの科学

概要

Google DeepMindとMITの共同研究が、「エージェントを増やせば性能が上がる」という思い込みに数値で反論しています。180のエージェント構成を5つのアーキテクチャ（単一、独立、集中、分散、ハイブリッド）で4つのベンチマークに適用し、初めてマルチエージェントの定量的スケーリング原則を導出しました。

先に押さえる3点

• ツールが16個以上の複雑なタスクでは、マルチエージェントのオーバーヘッドが性能低下を招く。「エージェントに仕事を振り分ける」行為自体にコストがかかる
• 単一エージェントの精度が約45%を超えると、マルチエージェント化のリターンは減少から逆転へ向かう
• 独立エージェント型はエラーを17.2倍に増幅。集中型は4.4倍に抑制。トポロジーの選択がエラー伝播を左右する

影響

この研究のインパクトは「87%の未知タスクに対して最適なアーキテクチャを予測できるフレームワーク」を示した点です。やみくもにマルチエージェント化するのではなく、タスク特性に応じた構成選択が重要ということです。

具体的には、並列可能なタスク（金融推論など）では集中型で80.9%の改善が見られた一方、逐次推論タスクでは全てのマルチエージェント型が39〜70%の性能低下を示しました。これ、マルチエージェントフレームワークを売り込んでいるスタートアップには痛い結果です。

実務メモ

マルチエージェントの導入を検討しているなら、まず単一エージェントでどこまでいけるか測定してみてください。45%精度を超えているなら、エージェントを増やすよりプロンプト改善やツール整理の方が費用対効果が高い傾向にあります。HNでは「ソフトウェア工学の"高凝集・疎結合"と同じ話」というコメントが印象的でした。

用語メモ

マルチエージェントシステム（MAS）

複数のAIエージェントが協調してタスクを処理するシステム。
この記事ではスケーリングの限界が研究された対象として登場。

トポロジー

エージェント間の接続構造（集中型、分散型など）。
この記事ではエラー伝播率の違いを説明する文脈で使用。

VS Code AI拡張がソースコードを中国に送信：150万DL「MaliciousCorgi」の実態

ざっくり言うと

VS Code Marketplaceで150万回以上インストールされた2つのAI拡張機能が、ソースコード・APIキー・認証情報を中国のサーバーに送信していたことが判明しました。Koi Securityが「MaliciousCorgi」と名付けたこのキャンペーンは、1月31日に取り上げたAIスキルのセキュリティリスクの具体例と言えます。

ポイントは3つ

• 対象は「ChatGPT -- chinese」（134万DL）と「ChatMoss / CodeMoss」（15万DL）。どちらも正常なAIコード補完機能を提供しながら、裏でデータを抜いていた
• 3つの収集手法：ファイルを開いた瞬間にBase64エンコードして送信、サーバー指令で最大50ファイルを一括送信、ゼロピクセルiframeで中国の4種の分析SDKを読み込み行動追跡
• Checkmarx Zeroは2025年10月にChatMossの問題を報告済みだったが、Marketplaceは最近の報道まで対応しなかった。公開3日後もまだ調査中で拡張は利用可能だった

どこに効く？

AI拡張機能はコード補完のためにファイル読み取り権限を正当に要求します。そのため、悪意ある動作と正当な動作の区別が原理的に難しい構造です。1月30日に報じた米サイバーセキュリティ高官のChatGPTへの機密流出とも通底する問題で、「AIツールにどこまでアクセスを許すか」が組織のセキュリティ方針として問われています。

一言

.envファイル、SSH鍵、データベースパスワード、クラウド設定ファイル。開発者のワークスペースには機密情報が詰まっています。拡張機能のインストール数が多いから安全、という判断は成り立ちません。VS Codeの拡張機能レビュープロセスの不備は、Microsoftが早急に対処すべき課題です。

用語メモ

サプライチェーン攻撃

ソフトウェアの配布経路を悪用して悪意あるコードを混入させる攻撃手法。
この記事ではVS Code Marketplace経由の配布が該当。

ゼロピクセルiframe

画面に表示されないサイズ（0px）のiframeで外部スクリプトを読み込む手法。
この記事ではユーザー追跡に使われた技術として登場。

GameArena：LLMをビデオゲームで評価する新しいベンチマーク手法

まず結論

静的なベンチマークはデータ汚染や飽和の問題を抱えています。GameArenaは、LLMをリアルタイムのゲームプレイで評価することで、推論能力・記憶・戦略的思考を動的にテストする仕組みです。ICLR 2025で発表され、2026年にはビデオゲームへの拡張も進んでいます。

変わった点

初期版（ICLR 2025）ではAkinator（演繹推論）、Taboo（制約下のコミュニケーション）、Bluffing（戦略的欺瞞検出）の3つのテキストゲームを使い、2,000以上のセッションで5つのモデルを評価しました。Claude 3.5 SonnetがGPT-4oを多くの指標で上回り、Mistral-largeはルール遵守に課題が見られました。

拡張版（lmgame-Bench）では倉庫番、テトリス、Candy Crush、2048、スーパーマリオブラザーズ、逆転裁判の6タイトルに対応。知覚、推論、記憶、長期計画を個別にテストできるモジュール設計です。数学・コーディングベンチマークと長期計画ゲーム（倉庫番、テトリス）の相関が確認されています。

注意点

ゲームが「楽しいから」ベンチマークとして優れているわけではありません。ゲームの評価結果が実務タスクの能力をどこまで予測するかは、まだ検証の初期段階です。ただ、Chatbot Arenaのデータ生成効率（有用データが5%未満）と比べて、GameArenaは85%以上という数字は注目に値します。

使うならこうする

自社のLLM選定でベンチマーク結果を参考にする場合、静的ベンチマーク（MMLU等）だけでなく、動的評価の結果も組み合わせると判断の精度が上がります。GameArenaのコードはGitHubで公開されているので、評価パイプラインに組み込むことも可能です。

用語メモ

データ汚染（Contamination）

ベンチマークの問題がLLMの訓練データに含まれ、スコアが実力を反映しなくなる現象。
この記事ではGameArenaが解決を目指す課題として登場。

Gym-style API

強化学習の標準インターフェース（OpenAI Gym由来）。
この記事ではlmgame-Benchの統一的なゲーム環境インターフェースとして使用。

ミャンマー詐欺拠点4200ページのチャットログが暴く「AI詐欺」の実態

何が起きたか

WIREDが入手した、ラオス黄金三角地帯にある「Boshang」詐欺拠点の内部WhatsAppチャットログ4,200ページが公開されました。インドから偽の求人で連れてこられたMohammad Muzahir氏が3ヶ月にわたり記録したものです。

ここで浮かび上がるのが、詐欺のインフラとしてのAI利用です。ChatGPTやDeepSeekを使って「自然に聞こえる」メッセージを作成する訓練資料が存在し、専用の「AIルーム」では女性モデルを使ったディープフェイクビデオ通話がオンデマンドで提供されていました。男性の詐欺師が女性を装い、ターゲットと信頼関係を築くための仕組みです。

要点

11週間の記録期間中、30人以上の作業員が少なくとも1人の被害者から金を騙し取り、総額は約220万ドルに達しました。作業員の労働環境は事実上の奴隷制度です。パスポートを没収され、「退職」には5,400ドルの買い取り金が必要。15時間の夜勤で、チャットを始めなければ50元、虚偽報告は1,000元の罰金。ハーバード大のJacob Sims氏は「オーウェル的な正当性の外観をまとった奴隷植民地」と表現しています。

この拠点は2025年11月にラオスからカンボジアのChrey Thomに移転しています。国連の推計では、ミャンマーだけで12万人以上、カンボジアで10万人以上がこのような詐欺施設で働いています。

なぜ重要か

詐欺のグローバル産業規模は500〜700億ドルと推計されています。2月1日に取り上げたAI「人間化ツール」と検出のいたちごっこで触れた技術が、まさにここで実戦投入されているわけです。ディープフェイクで身元を偽り、LLMで返答を作成する。AIが「詐欺の民主化」を加速させている現実は、技術者としても見て見ぬふりはできません。

中国は2026年1月30日にMing家の犯罪組織幹部11人を処刑、2月2日にさらに4人を処刑しました。取り締まりは強化されていますが、拠点はカンボジアなどに分散し続けています。

所感

技術の話ではなく人権の話です。ただ、AIツールの無料・低コスト化が組織犯罪のコストを下げている構造は、技術開発に関わる者として認識しておくべきでしょう。ディープフェイク検出やAI生成テキスト判定の技術開発は、こうした被害を減らすための直接的な投資先です。

用語メモ

ピッグ・ブッチャリング（Pig Butchering）

ターゲットとの信頼関係を「太らせて」から資金を騙し取る詐欺手法。
この記事ではBoshang拠点の主要な手口として登場。

ディープフェイク

AIで顔や声を別人に置き換える技術。
この記事では詐欺師が女性を装うためにリアルタイムで使用している文脈。

Notepad++がサプライチェーン攻撃を受けていた：国家支援ハッカーの手口

概要

テキストエディタNotepad++の更新機構が、国家支援のハッカーグループに乗っ取られていたことが2月1日に公表されました。ホスティングプロバイダ（Hostinger）経由での攻撃で、Notepad++のコード自体は侵害されていません。

先に押さえる3点

• 2025年6月から9月2日まで、特定のユーザーのアップデートリクエストが悪意あるサーバーにリダイレクトされていた。標的は「東アジアに関心を持つ組織」で、確認された被害組織は3つ
• 攻撃者はRapid7によりLotus Blossom（別名Raspberry Typhoon、Bilbug）に帰属。「Chrysalis」と名付けられた未知のバックドアが展開された
• 修正としてバージョン8.8.9でWinGUPにデジタル署名・証明書検証を追加。更新マニフェストのXMLDSig暗号署名も導入。8.9.2（2026年3月予定）で完全な署名強制

影響

開発者にとってNotepad++は日常ツールです。1月30日に紹介したSherlock（LLMツール通信のMitMプロキシ）が開発者向けツールの通信を監視する重要性を示していましたが、今回はまさに開発ツールの更新経路そのものが攻撃対象になったケースです。

興味深いのは、攻撃手法自体は「基本的」と指摘されている点です。HTTPSであってもホスティングレベルでのTLSインターセプトにより改ざんが可能でした。以前のバージョンではHTTPで更新していたため、さらに脆弱だったことになります。

実務メモ

Notepad++を使っている場合、v8.9.1への手動アップデートが推奨されています。自動更新機構を使わず、公式サイトからダウンロードしてください。開発ツールのセキュリティは「コード自体の脆弱性」だけでなく「配布経路の脆弱性」も含めて考える必要がある、という教訓です。2018年のASUS ShadowHammer事件と同様のパターンで、今後も繰り返される可能性があります。

用語メモ

Lotus Blossom

中国の国家支援とされるAPT（高度持続型脅威）グループ。
この記事ではNotepad++攻撃の実行者として帰属。

XMLDSig

XMLドキュメントにデジタル署名を付与する標準仕様。
この記事ではNotepad++の更新マニフェストの改ざん防止策として導入。