Grayrecord Technow

清水亮氏の『AI研究者が見た「不都合な」真実』を拝読しましたが、正直なところ、論理の飛躍があまりにも多く、全く読むに堪えないものでした。まるでWELQの健康に関する記事を読んだ後のような読後感です。 特に、最初に引っかかったのは以下のところです。 そのほかさまざまな技術的イノベーションもあり、もはやオープンウェイトの大規模言語モデルを一般企業や個人が手元で動かすことは、十分実用的なものになりつつある。 しかし、DeepSeek-R1のようなモデルを動かそうとすると、数百GB以上のVRAMが必要であり、コンシュマーレベルのGPUでは到底対応できません。ARM Macの環境だと、SharedなRAMのおかげで少し軽減しますが、それでも数百GBは無理があります。 まず、段階を追って清水氏の言説を検証します。 論理的に分解すると、以下の段階です。 GPT-4.5の問題 GPT-4.5をDeepSeek-R1で実現できる DeepSeek-R1を動的1bit量子化で実現できる 動的1bit量子化で適切なアウトプットが出る 動的1bit量子化モデルをMac Studioで動かせる Mac Studioが最適 まず、1.の問題は明確に存在し、計算コストの問題があります。問題は、2.以降です。DeepSeek-R1は大規模推論が可能ですが、GPT 4.5と同等な能力があるかどうかは実証されていないと考えます。3.はまあ、Unislothの発表を見る限り、実現はしてるとは思うのですが、4.はUnislothの発表を見る限りまだ、ベンチマークは十分ではありません。5.については容量的には動きそうレベルです。6.に関しては全く論外です。これは後述します。 ただし、米国型大型AIモデルを言うならば、コロッサスの問題を避けては通れないでしょう。南部環境法センター（Southern Environmental Law Center）が2025年4月9日に公開した調査によると、コロッサスでは 認可申請された15基を遥かに超える、35基のガスタービンエンジンを備えています。当然、この現実こそ、まさに不都合な真実です。 ちなみに、清水氏が記事で「不都合な真実」として引き合いに出している、OpenAIの競合であるAnthropic社のダリオ・アモデイCEOによる「今後5年間でAIが一部の仕事を奪う可能性、特に認知労働、つまりホワイトカラーの初級職に大きな影響が出て、5年で半分の初級職がなくなる」という警鐘は、本来の「不都合な真実」（環境問題）とは異なる文脈で用いられています。この点も、清水氏の言説がアテンションを引くための装置として機能している一例と言えるでしょう。 まず、Unislothの検証は以下の環境です。 The 1.58bit quantization should fit in 160GB of VRAM for fast inference (2x H100 80GB), with it attaining around 140 tokens per second for throughput and 14 tokens/s for single user inference. You don’t need VRAM (GPU) to run 1.58bit R1, just 20GB of RAM (CPU) will work however it will be very slow. For optimal performance, we recommend the sum of VRAM + RAM to be at least 80GB+. ...

あまりに、どけちすぎる、伝説級の詐欺メールが登場です。 楽天ポイント大還元祭！ 今だけ！楽天カード会員様限定で、エントリーしてくじを引くだけで最大3,000ポイントが当たるチャンス！抽選は毎日可能。今すぐチャレンジしよう！ ■ キャンペーン概要 期間：2025年5月25日〜6月20日 対象：楽天カード会員様（要ログイン） ■ 参加方法 以下のボタンをクリックしてエントリー ログイン後、くじを引くだけで抽選に参加！ その場でポイント当選結果が表示されます ■ 賞品内容 特賞：楽天ポイント 3,000pt（5名様） 1等：1,000pt（30名様） 2等：300pt（100名様） 3等：50pt（1,000名様） 参加賞：楽天ポイント 1pt（全員） 保証されてるのが1ポイントだけって、詐欺としてもケチすぎるでしょう。 こんなんで誰が応募するとでも？ ■ ご注意事項 楽天IDでのログインが必要です 当選ポイントは期間限定ポイントとして付与されます キャンペーン内容は予告なく変更・終了する場合があります ▶ 今すぐエントリーしてくじに挑戦 番外編として、次の愚劣詐欺もピックアップ。 “[spam]【重要なお知らせ】amazonアマゾンプライムの自動更新設定を解除いたしました3574366919” サブジェクトしかねー本文もねー添付もねーリンクもねー 俺ら東京さ行ぐだの替え歌にしちゃうぞ。

またしても、伝説級の詐欺師あらわるです。 FROM: European Commissioninfo@eu.org EUを名乗っているのに、ドメインが「eu.org」？ あり得ない…。 Representation in United Kingdom Europe House 32 Smith Square London SW1P 3EU. For your attention. RE: $25,000,000.00 PAYMENT APPROVAL NOTICE. This message is to bring to your notice that your scammed victim’s compensation funds payment has been approved for payment by the Order of the President of the European Commission after the Executive Meeting on Monday 29th October 2024. Upon the process of your payment, we received an application from one of your attorneys in the United Kingdom (ADENITIS & PARTNERS) who introduced himself as your legal representative in the United Kingdom. Stating that you have authorized them to change the ownership of your payment to INVERNESS MAINTENANCE COMPANY INC. as the sole beneficiary with the account number: 3010007328 with the Citi Bank of America. ...

このニュースは背筋が凍りました。 MetaがロシアのYandexと同じ手口でユーザーの行動を追跡していたことが判明、何百万ものウェブサイトに「スマホのアプリと通信するコード」を埋め込んで追跡しておりブラウザの履歴を削除しても無駄 通常、ウェブブラウザには「同一オリジンポリシー (Same-Origin Policy)」というセキュリティ機能があり、異なるオリジン（プロトコル、ホスト、ポートの組み合わせ）間でリソースを共有することを厳しく制限しています。Cross-Origin Resource Sharing (CORS) はこの制限を緩和するためのメカニズムですが、明示的な許可が必要です。 Meta Pixel がこの規制をどのようにバイパスしたのか、最新の調査結果に基づいて説明します。 localhostソケットとWebRTCの悪用 Meta PixelがCross-Originの規制をバイパスした主な手口は、以下の組み合わせにありました。 localhostポートの利用: Metaが提供するAndroidアプリ（Facebook、Instagramなど）が、デバイス内の特定のローカルポート（例えば12580-12585）をサイレントにリッスンしていました。つまり、アプリがウェブサイトからの通信を受け入れる準備ができていたということです。 ウェブサイトに埋め込まれたMeta PixelのJavaScriptコードは、モバイルブラウザ上で実行される際に、localhost (127.0.0.1) のこれらのポートに対して通信を試みました。 localhostへの通信は、ブラウザの同一オリジンポリシーのスコープ外、またはその穴を突く形で行われました。ブラウザは、自身のデバイス内のローカルホストへの通信に対しては、比較的制限が緩い場合があります。 WebRTC (Web Real-Time Communication) の利用: Meta Pixelは、WebRTCというリアルタイム通信プロトコルを利用して、_fbp Cookie（ブラウザを識別するファーストパーティCookie）などの追跡データをlocalhostのアプリに送信していました。 WebRTCは、ブラウザ間の直接通信や、ブラウザとローカルネットワーク内のデバイスとの通信を可能にするための技術であり、その機能がこの追跡に悪用された形です。特に、WebRTCのSDP (Session Description Protocol) というセッション情報をやり取りする部分が利用されたと報告されています（SDP munging）。 アプリ側でのデータリンケージ: Androidアプリは、localhost経由で受け取った_fbp Cookieを、アプリにログインしているユーザーの永続的な識別子（Facebook IDなど）と紐付けました。 これにより、ユーザーがブラウザでCookieを削除したり、シークレットモードを使ったり、Facebook/Instagramにログインしていなくても、そのウェブ閲覧履歴がMetaのユーザーアカウントに紐付けられて追跡されるという、従来のプライバシー保護メカニズムを回避する仕組みが実現されました。 Metaとサイト運営者の責任 実際に、"Disclosure: Covert Web-to-App Tracking via Localhost on Android“という調査報告書をチェックすると、日本のドメインだけでも以下のリストに見られるようなウェブサイトがMeta Pixelを使用している惨状が明らかになります。これはほんの一部に過ぎません。 https://auctions.yahoo.co.jp/ https://beauty.hotpepper.jp/ https://dmarket.docomo.ne.jp/ https://grapee.jp/ https://mechacomic.jp/ https://nlab.itmedia.co.jp/ https://page.auctions.yahoo.co.jp/ https://trilltrill.jp/ https://www.boatrace.jp/ https://www.cmoa.jp/ この状況は、Metaだけでなく、サイト運営者にも重い責任 があることを示しています。 この惨状から、私は次のことを強く要求します。 まず、Metaは今まで不法に採取したデータをすべて廃棄すること。 次に、サイト運営者はMetaから受け取った全ての違法データを廃棄すること。 これらが、ユーザーのプライバシーを守るために最低限必要な措置です。 楽天ad4U 今回のMeta Pixelの手口は、かつての「楽天ad4U」を想起させます。楽天ad4Uも一種の行動ターゲティング広告で、Adobe Flashオブジェクトの中に数千個のURLへのリンクを埋め込み、それぞれのURLを訪れた形跡があるか否かをCSSの色判定で調べる手口でした。 ...

不安しかない au IDや、「dアカウント」にログインしようとしたら、なぜか回線認証で詰んで先に進めない。機種変更したら、これまで使えていたサービスに紐付けられたdアカウントの再設定で地獄を見た──。そんな経験、ありませんか？ なぜなら、その背後には 「回線を持っているがゆえに、不便を強いられる」という、キャリア認証システムの根本的な問題 がちらついていたからです。 「dアカウント」にせよ、「au ID」にせよ、その 「King of ゴミ」 とも言うべき、回線認証の強要は、我々のデジタルライフを大きく阻害しています。ITmediaでも報じられたように、なぜdアカウントのUI/UXはこれほどまでに悪い評価で衆目の一致する所となっているのか。今回は、その根深い問題点、特に回線認証という 時代錯誤な仕組みが引き起こす弊害 に焦点を当て、なぜ我々がこれほどまでに不満を抱えているのかを徹底的に掘り下げていきます。 先ごろ、発表されたSBI住信の買収で不安を漏らす声が噴出しています。実際、ITmediaでも以下のような記事が書かれています。 なぜ、「dアカウント」は嫌われているのか　住信SBIネット銀行買収で、不安の声が上がるワケ 終わってるUser eXaust：キャリア認証の「糞」っぷり 私は家計簿アプリMoney Forwardでau PAYを含む複数の金融サービスを集約して管理していますが、その連携方法がユーザーに多大な「苦痛」をもたらしています。 Money Forward連携と「糞」なキャリア認証 まず、Money Forwardはau ID側からの適切なAPI提供がないため、不安定な「スクレイピング」でデータを収集せざるを得ません。これにより、au IDの認証が頻繁に切れてしまい、再認証の度に地獄を見ます。 この再認証プロセスが、まさに「User eXhaust」の極致です。 痛みしかないフロー Money Forwardでau Payからの認証切れを発見する おもむろに再認証を始める 認証しようとしたら、最初の壁、パスワード認証できないにぶつかる スマートフォンからパスワード認証を有効化しようとする スマートフォンアプリからは該当操作が見つからない wifiからは設定できない、回線認証の強制 糞そのもののキャリア認証 パスワード認証の無意味化と強制的なSMS認証: au IDのパスワード認証は、わずか15分で自動的に無効化されます。さらに、パスワードを有効にしようとすると「悪用に関する警告」が表示された上に、時代遅れのSMS認証が強制されます。安全で便利な時間ベースの二段階認証（TOTP）は選択肢にすらありません。 回線認証の強制とWi-Fi切断の強要: パスワード認証が無効化されると、次に強制されるのは「Wi-Fiを切って、VPNをオフにしろ」という「愚劣な回線認証」です。安定したWi-Fiを切り、特定のモバイル回線で接続し直すという不必要な手間は、ユーザーに計り知れないストレスを与えます。 設定変更の困難さ: これらのパスワード認証に関する設定は、My auアプリには存在せず、Webブラウザからしかアクセスできません。しかも、そのWeb設定もスマートフォンからしか行えないという多重の制約があり、スマートフォンが手元にない状況では完全に「詰み」ます。 PayPay連携も「アホすぎる」 PayPayの連携方法も同様にユーザーを疲弊させます。Money ForwardとPayPayを連携させる際、API連携ではなく、スマートフォンアプリ間で「インテント」を飛ばすという、極めて非効率で不安定な方法を強いてきます。この理解しづらい手間は、金銭管理という重要なタスクにおいて、ユーザーに「アホすぎる」苦痛を与えています。 信頼性と安定性の問題: アプリ間の連携は、アプリのバージョン、OSのバージョン、端末の設定など、様々な要因で不安定になる可能性があります。 バッテリー切れやアプリの不具合など、何らかの理由でPayPayアプリが使えない場合、連携自体ができなくなるリスクもあります。 テックジャイアントとキャリア認証の雲泥の差 GoogleやMicrosoftといった世界のテックジャイアントは、現在、パスキー、TOTP（時間ベースワンタイムパスワード）、フォールバックとしてのSMS、そして最終手段としての事前配布解除コードを組み合わせた認証基盤を標準としています。 これらの企業は、ユーザーがどのデバイス、どのネットワークからでも安全かつシームレスにサービスを利用できるよう、以下の点を重視しています。 フィッシング耐性の高いパスキーを基幹とする。 オフラインでも利用可能なTOTPを次点とする。 利便性とセキュリティを両立させる。 「回線認証」などという愚劣な認証を主要な手段として導入することはありません。 信用性が無い理由 古い技術への固執: 時代遅れで脆弱性が指摘されているSMS認証を主軸にしたり、利便性を著しく損なう回線認証に固執したりする時点で、最新のセキュリティ脅威に対する認識が甘いか、対応能力が低いと見なされます。 利便性の犠牲とユーザーへの負担: ユーザーに多大な手間やストレスを強いる認証システムは、結果的にユーザーがセキュリティ対策を回避しようとする行動を誘発しかねません。例えば、不便な設定を避けたり、パスワードを使い回したりするリスクを高めます。 「技術的腐敗」: 認証基盤が「技術的腐敗」の状態にあるということは、システム全体の整合性や信頼性が低いことを意味します。このような基盤の上で金銭取引が行われているとなると、潜在的な脆弱性や予期せぬトラブルのリスクが懸念されます。 ...