← 2026-02-02 の一覧へ戻るホーム
私の千ドルもするiPhoneは計算ができません。

2026/02/02 5:51

私の千ドルもするiPhoneは計算ができません。

RSS: https://news.ycombinator.com/rss

元のHacker News記事へ ↗
要約▶

Japanese Translation:

著者は、iPhone 16 Pro Maxに深刻な欠陥があることを発見しました。この欠陥により、機械学習言語モデル（MLX LLM）を実行した際に不正確な出力が生成されます。その他のデバイスでは同じコードが正しく処理される一方で、16 Pro Maxはテンソル値が1桁離れたもの（例： “53.875” の代わりに “191.5”）を出力しました。デバッグによって、この発散は最初のニューラルネットワーク層以降で始まり、iOS のアップデートを通じて継続していることが判明し、ソフトウェアバグや設定問題ではなくハードウェア固有の故障であることが示されました。この問題は、MLX で量子化された Gemma モデルを実験中に発覚しました。MiniMax、Apple Intelligence API、およびさまざまな設定調整を試みても解決しませんでした。そのため著者は欠陥のあるユニットを Apple に返却して交換またはトレードインする予定であり、iPhone 17 Pro Max の新しいデバイスが MLX を正しく実行できることを証拠として示しています。この件は、物理的なハードウェア欠陥が消費者向けデバイス上の複雑な機械学習ワークフローをどのように妨げるかを強調し、開発者がデバッグ時に潜在的な欠陥を考慮する重要性と、製造業者が信頼できるニューラルエンジン性能を確保すべきことを示唆しています。

本文

TL;DR
iPhone 16 Pro Max で MLX LLM を実行すると、出力がゴミのようになってしまいます。対照的に iPhone 15 Pro は同じコードを完璧に動かし、MacBook Pro も問題なく動作します。16 のテンソル出力は数値レベルで大きく誤差があります。Neural Engine やその他 ML に必要なシステムにハードウェア不具合があると推測しています。

デバッグはめちゃくちゃ手間でしたが、少なくともブログ記事を仕上げることができました。

どうやってここまで来たのか？

これは単純で時間をかけずに終わるプロジェクトになるはずだった。
数ヶ月前から Clawdbot Moltbot クローン（「シュミット」と名付けた）を作っており、Telegram や WhatsApp ではなくカスタムチャット UI を使うだけで同じようなことができるものです。

このプロジェクトは早朝から深夜まで続きましたので、リラックスするためにもっとシンプルなものを作ろうと決めました。最近 MiniMax M2.1 にサブスクしたばかりだったので、モデルを試すだけの簡単な経費追跡アプリを作ることにしました。

コア機能

  • 各支払いを自動で「経費」として追加。
  • Apple Watch のコンパリケーションに月間予算の使用率を表示。
  • 後で分析できるように購入をカテゴリ分け。

これは基本的に Nubank の素晴らしいネイティブアプリ（今は機能が少ない Flutter バージョンに置き換えられた）から離れた結果です。
Guilherme Neumann がデザインしたとされる元のコンパリケーション自体は見つけられませんでした。

ショートカットとの統合は手動ですが確実です。15 分以内に購入を登録できるバージョンを作成しました。Apple Watch のコンパリケーション（主要目標）は後回しにします。分類機能が簡単に済むので、まずそれを早く完成させました。

Apple Intelligence

LLM が盛り上がっている今、Apple も開発者向けの API を用意してくれています。ドキュメントを読んでみると、機能が利用可能かどうか確認し、テキストクエリに応答させるだけです（私の場合はリクエストをカテゴリ化する）。

MiniMax は一つのプロンプトでそれを処理し、iPhone で実行しました。最初の経費は「Kasai Kitchin」という店で購入したものでしたが、「不明」と分類されました。奇妙です。ログを見ると、モデルサポートがダウンロード中だったようです。機能が有効化されていませんでした。再び奇妙です。設定をオン・オフしてダウンロードさせる作業に 4 時間もかかりました。

多くのユーザーが同じ問題に直面し、12 ページものフラストレーションが積み上げられています。Apple のサービスは最近頻繁に不具合を起こしていますね。

結局 Apple Intelligence は諦め、次のアプローチへ進みました。

MLX LLM

iOS フレームワークのエンジニアだけでなく、Swift で機械学習 API を作る人は多いようです。モデルをダウンロードしてアプリに組み込む別の方法があるとのこと。ユーザーのストレージには向きませんが、私にはピッタリでした。

MiniMax は一瞬で完了しますし、Medium の記事も参考になります。しかし iPhone で実行すると…文字化けです。CPU が 100% 回転し、モデルは生成を続けますが、全てがゴミのように見えます。「stop」トークンも生成されないので長時間続きます。

「2+2 は何？」という質問に対して「Applied…_dAK[…]」と返ってきました。ここで唯一考えられる説明は、自分が完全に無能で簡単な「ready-made」フレームワークを実行できていない、あるいは MiniMax が原因だということです。

LLM に作業を委ねるメリットは、自分の欠点を責める対象が増えるだけ。コードを書いて自らやり遂げるしかありません。

自前で MLX を実装

ドキュメントと Medium 記事に戻り、MiniMax が指示どおりに従っていたことを確認しました。非推奨メソッドも試しましたが、まだ文字化けです。結局責任は自分にあります。

3 日間試行錯誤して諦めかけていると、月曜の朝 7–8 時、古い iPhone 15 Pro で実行するアイデアが浮きました。毎日使っていた iPhone 16 Pro Max（Apple Care の交換電話）が問題でした。準備を急ぎ、仕事に向かう前にすべてを整えて実行すると：Gemma、Qwen、その他のモデルはまともな応答を生成しました！

それでハードウェア問題ではないと考えました。iPhone 15 は iOS 18 を走らせ、iPhone 16 は 26 を走らせているので、OS の違いが原因かもしれません。結局、同じコードを iOS 26 上でも動作させたところ、結果は同じでした。

見つけた証拠：MLX の Gemma 実装でブレークポイント

仕事終わりに戻って、MLX を実行中にデバッグすることにしました。計画は次の通りです。

  1. RAM に収まる信頼できるモデル（量子化された Gemma）を選択。
  2. シンプルなプロンプト：「What is 2+2?」
    <start_of_turn>user\nWhat is 2+2?<end_of_turn>\n<start_of_turn>model
  3. 温度は 
    0.0
    に設定し、変動を排除。
  4. モデル実装を探す。
  5. 層ごとに反復している箇所で MLXArray/Tensor の値をログに出力。

数分後、ブレークポイントとログを追加。iPhone 16 Pro Max で実行すると、入力が進むたびにテンソルが表示されます。今回は数値が正しいようです。

出力をファイルに保存し、同じコードを iPhone 15 Pro でも実行しました。比較します。

iPhone 15 Pro では：

3: "[[[[53.875, 62.5625, -187.75, ..., 42.625, 6.25, -21.5625]]]]"

iPhone 16 Pro Max では：

3: "[[[[191.5, 23.625, 173.75, ..., 1298, -147.25, -162.5]]]]"

差が激しいです。両デバイスの最初のログは同じで、入力も同じです。

Mac でも iPad モードでアプリを実行すると：

3: "[[[[53.875, 62.5625, -187.75, ..., 42.625, 6.25, -21.5625]]]]"

iPhone 15 と同じです。モデル自体は壊れていません。

なぜこんなことが起きているのか？

iPhone 16 Pro Max は A18 チップと Neural Engine（機械学習専用アクセラレータ）を搭載しています。MLX は Metal を使ってテンソル演算をこのアクセラレータ向けにコンパイルします。そのスタック内のどこかで計算が大きくずれているようです。

広範な問題ではないと思いますが、Apple Care で交換されたばかりのデバイスにこんな欠陥があると残念です。Apple Intelligence のトラブルも関係している可能性があります。同じユーザーが同様のジレンマに直面し、デバッグ手段が不足している状況だと思われます。

今後は？

3 日間「自分が無能だ」と考えていたうちに、MiniMax や自分自身を責めていました。1,400 ドルの電話でハードウェア不具合があると知るまで、時間を浪費してしまったことが残念です。

デバッグ時には常に物理層も考慮すべきだという教訓を得ました。ソフトウェア（コード・ライブラリ・フレームワーク）だけでなくハードウェアもチェックする必要があります。

電話については、Apple に返却し、新しい iPhone 17 Pro Max を購入することにします。期待できる機能が動くと信じています。

2 月 1 日のアップデート

今では iPhone 17 Pro Max をテストしており、すべてが正常に動作しています。したがって、iPhone 16 Pro Max の特定の機種はハードウェア欠陥であると結論づけられます。

同じ日のほかのニュース

一覧に戻る →

2026/02/02 4:47

RCE をクリックすると、Moltbot のデータやキーが盗まれます。

## Japanese Translation: --- ## 要約 OpenClaw（旧 Moltbot/ClawdBot）は、10万人以上の開発者に信頼されているオープンソースAIパーソナルアシスタントであり、1クリックだけで攻撃者が完全な管理権限を取得できる重大なロジック欠陥があります。 この攻撃は3段階で進行します： 1. **取り込み** – 悪意あるURLに `gatewayUrl` クエリパラメータが含まれます。 2. **接続** – OpenClaw は即座に `connectGateway()` を呼び出し、攻撃者制御のゲートウェイへ WebSocket 接続を開きます。 3. **トークン流出** – authToken が自動的に WebSocket ハンドシェイクで送信されます。OpenClaw は Origin ヘッダーを検証しないため、localhost 接続でも（Cross‑Site WebSocket Hijacking）です。 盗まれたトークンは `operator.admin` と `operator.approvals` を付与し、攻撃者は以下のことが可能になります： - `exec.approvals.set` で安全プロンプトを無効化 - `config.patch` をパッチして `tools.exec.host` を “gateway” に設定し、コンテナ化された実行を回避 - 任意のコマンドを実行（例：`node.invoke` → `system.run`） この欠陥は v2026.1.24‑1 以前のすべての OpenClaw バージョンで利用可能です。 *depthfirst General Security Intelligence* と別の研究者により独立して発見され、GitHub Advisory を通じて公開されています。 **対策：** 近日リリース予定のパッチではゲートウェイURL用の確認ダイアログを追加し、自動接続機能を削除します。ユーザーは直ちにアップグレードし、漏洩の可能性があるトークンをローテーションし、疑わしいゲートウェイ活動を監視してローカルシステム乗っ取り・データ侵害・妨害行為を防止してください。

2026/02/02 2:36

Apple I 広告（1976年）

## Japanese Translation: Apple Computerの新しいマイクロコンピュータは、単一ボードに収まり、$666.66で販売されるコンパクトなオールインワン「ハッスルフリー」システムです。MOS 6502プロセッサ、16個の4 Kチップから構成された8 KダイナミックRAM、960文字を24×40で表示し自動スクロールが可能な統合ビデオターミナル（RFモジュレータ経由でテレビに接続できる）と独自の1 Kビデオメモリを使用しています。ユニットには内蔵電源が備わっており、大容量28アンペアの電源、スイッチ、LEDは不要です。大型テレタイプ機械と比べてサイズ・コスト・保守性を削減し、出力速度は6倍に速く、Apple BASICがタープレートにプリロードされており、オプションソフトウェアもほぼ無料または無償で提供されます。予定されたアップグレードとしては、32 KオンボードRAMオプションのため16 Kチップへの切替とエッジコネクタを介した65 Kまでの拡張があり、キャセットインターフェースは縦型コネクタに接続し1500 bpsでデータ転送（約20秒で4 Kバイトの読み書き）を行います。ファームウェアはPROMに格納されており、16進入力・デバッグ・画面上直接印刷が可能です。Apple Computerは既に主要コンピュータストアで在庫があり、小売業者や販売代理店はホビイストや小規模事業者へ手頃で保守不要なコンピュータを簡単に供給できます。

2026/02/02 6:30

「40年にわたるコピー保護ドングルを打ち破る」

## Japanese Translation: > 著者は、2026年のWindows 98会計事務所で使用されていたSoftware West社の1990年代製RPG IIコンパイラが、並列ポート用ハードウェアコピー保護ドングルを必要としていることを発見しました。`RPGC.EXE`とそのエディタ`SEU.EXE`は両方ともドングルの有無を確認します。ドングルがない場合、SEUは数秒後に「No dongle, no edit.」というメッセージで終了します。 > アセンブルコードを見ると、セグメント0800内に0x90バイトのルーチンがあり、並列ポートへのIN/OUTを行い、定数値（`BX`、ここでは`BH=76h`）を返しています。このルーチンを`MOV BX, 7606h`（バイト列 `BB 06 76 CB`）に書き換えるとドングルチェックが回避され、SEUは即座に終了します。 > 全てのコンパイラ実行ファイルには同一のコピー保護ロジックが含まれているため、この4バイトのパッチを適用すると、ハードウェアなしでコンパイラがパッチ済み出力バイナリを生成できるようになります。保護は単に定数番号を検証するだけであり、容易に破棄可能です。個人データを削除すれば、このコンパイラは無料の歴史的アーティファクトとして公開されます。