0819 | ClaudeがHP 1008aのMacドライバを作成、デスクトップ3Dショウジョウバエ、Apple EU変更、Meta特許

葵: Bri Radioの「HackerNews Daily」へようこそ。僕、葵です。今日もテック界隈で話題のニュースをいくつかお届けします。

悠真: そして私、悠真です。まずは、あるHPプリンタが実はSamsung製のリブランド機だったという話。独自の印刷言語を話すタイプで、Macユーザーにはちょっと厄介な存在なんですよね。

葵: そうそう。ずっとハエをデスクトップで飼えるツールの話もあって、しかも実際の神経回路のデータを動かしてるっていう凝りよう。

悠真: あとは「ノルウェーはOpenAIを買収すべきだ」という大胆な論考も話題ですね。壮大なアイデアですが、今日は深く掘り下げる時間はないかも。

葵: データベース開発の再考をめぐる議論や、ある期間限定で利用制限が緩くなる話まで、盛りだくさんです。さっそく本編へ。

葵: ある開発者が、Samsung製リブランドでWindows専用ドライバしか用意されておらず、macOSから印刷すらできなかったHP Laser 1008a用のドライバを、Claude Codeでほぼそのまま書かせてしまった事例がHacker Newsで話題になっています。投稿者のKuberこと@kuberwastaken氏によると、汎用ドライバが接続処理でハングし、プリンタ自身のエラーページから印刷言語SPL3を特定したうえで、macOSのUSBサンドボックスを迂回し、Linuxコンテナ内でHP純正のrastertosplコーデックを動かして本物のSPL3を生成し、再起動に耐えるバックグラウンドデーモンまで作成したとのことです。約4時間のClaude Codeセッション記録が軽く編集されたトランスクリプトとして公開され、リポジトリはgithub.com/Kuberwastaken/hp-laser-1008a-macosで、MITライセンスのワンコマンドインストーラ付き。一方コメント欄では、これはドライバを書いたのではなくLinuxドライバを使っただけだという反論や、Amazonで売っているプリンタを「obscure」と呼ぶのはおかしいという指摘も。同種の経験として、Claudeに月光のアダプタ対応フォークを約5時間で完成させた例や、業務用3DプリンタをMacから印刷できるようにした例なども報告されています。

悠真: それが、X のユーザーが Claude Code というツールの、およそ 4 時間のセッションを公開したことで一気に話が広がったんです。手順としては、まずプリンタがどんな印刷言語を話すかを特定して、macOS の USB のセキュリティ制限を迂回し、Linux の中で HP 純正のコード変換を使い、実際の印刷データを生成。さらに再起動しても動き続けるバックグラウンドの常駐プロセスまで作り上げて、CUPS がこの機種を正しく認識するところまで持っていったそうです。

葵: ただ、Hacker News の議論では、これは本当に「ドライバを書いた」と言えるのか、という反論も出ています。ある指摘では、これは Linux の既存ドライバを転用しただけで、AI は必要なかったという意見も。それに対して、Amazon で売っている普通のプリンタを「地味」と表現するのは変だというツッコミもありましたね。

悠真: 同じような経験談も数多く寄せられました。Xbox のワイヤレスアダプタを Android TV で使えるようにするフォークを 5 時間ほどで完成させた例や、業務用の 3D プリンタを Mac から制御できるようにした例など。いずれも Claude が仕様書や既存実装を読み込んで、短期間で動くところまで仕上げたと報告されています。

葵: 中でも興味深いのは、特定のメーカーに限らない反応で、Mac 用ドライバがない Brother のプリンタを使っている人たちから「同じことを試したい」という声が上がっていたことですね。つまり今回の話は、一つの機種の救済というより、専用ソフトが用意されないハードウェア全般に向けた「新しい解決方法」の実例として受け止められている、ということなんだと思います。

悠真: AnthropicのコーディングツールClaude Codeで、週間利用制限を50%引き上げる期間限定プロモーションが実施されていたことが、公式ヘルプセンターの2026年7月18日付の記述から明らかになりました。適用期間は2026年5月13日から8月19日までで、対象はPro・Max・TeamプランとEnterpriseプランのレガシーシートベースユーザーで、Freeプランと従量課金ベースのEnterpriseシートは対象外。適用されるのはClaude Codeのみで、CLIやIDE拡張、デスクトップ、Webが含まれる一方、Claude Webやモバイル、Claude Coworkなど他製品の利用制限は変わらず、5時間の利用制限も影響を受けないとのこと。参加のための操作は不要で自動適用され、CLIで/usageを実行すると更新後の制限が確認できます。8月19日以降は週間制限が標準水準に戻るとされています。Hacker Newsでは、最近Claude Codeが驚くほど寛大に感じた理由がこれで説明できるという声や、今日の障害が期限前に駆け込んだ利用者によるものかもしれないという指摘のほか、モデル品質の比較まで含めて議論が広がっています。

葵: つまり、もう少しでこの拡大枠が終わって、標準の週間制限に戻るんですね。参加のための操作は不要で自動的に適用されるんですが、CLI で /usage と打つと、更新後の制限を確認できるそうです。このニュースを受けて、Hacker News では「ここ数ヶ月、Claude Code が驚くほど寛大に感じていた理由がこれで説明できる」という声も出ていました。

悠真: 一方で、この話とは別に、モデルの性能比較でも意見が割れています。あるユーザーは OpenAI のモデルの方が明らかに優れていると主張する一方で、別のユーザーは Claude の最新モデルは問題なく使えて、むしろコード品質はこちらの方が高いと反論する展開に。

葵: こうしたモデルどうしの比較に対しては、「どちらか片方を落とすと、もう一方が見落とす問題に気づけなくなるから、両方のサブスクを持つほうがいい」という実務的な意見もありました。OpenAI にはオープンソースのツールが充実していて、Anthropic にはマーケティングがある、という皮肉を込めた比較も見られましたけど。

悠真: まとめると、期間限定のプロモーションがあることが明らかになった一方で、開発者の間では「どちらのツールで組むか」という議論が、実際の作業現場での使い勝手やサブスクの金額も含めて、いよいよ現実的な選択肢として深まっている、ということなんでしょうね。

葵: macOSのデスクトップ上で生きる3Dのショウジョウバエというプロジェクトが話題です。DenisSergeevitch氏のGitHubリポジトリ「desktop-fly」は、ただのアニメーションではなく、実際のハエの神経回路データ、いわゆるコネクトームによるライブ・スパイキング・シミュレーションで動いていて、ウィンドウの上を歩き、体を手入れし、眠り、カーソルから逃げる判断を本物のハエと同じニューロンで行うと読める内容です。回路は668ニューロンと約19,000の実シナプス結合を持ち、神経伝達物質予測で符号付けされ、1kHzのleaky-integrate-and-fireシミュレーションとして動作。READMEには「逃避はスクリプト化されていない」とあり、カーソルの接近が接近検出視覚ニューロンへの入力になり、巨大繊維ニューロンが実際のシナプスを通じてスパイクした時だけ飛び立つと説明されています。Hacker Newsでは本物のAIだという称賛の一方、ソースを読む限りスクリプト化された行動がコネクトームでトリガーされるだけだという批判も。また、コネクトームは全脳スキャンのようなものだと絶賛し、Claudeでブラウザへ移植しようと計画するコメントも見られました。

悠真: ポイントは、逃げるという行動が事前にスクリプト化されていないことですね。カーソルが近づくと、ハエの脳の視覚ニューロンにあたる部分へ入力が送られて、実際のシナプスを通じて「逃避」の神経が発火した時だけ、ハエは飛び立ちます。データの元は、丸ごと1匹のハエの脳を詳細にマッピングした FlyWire という公開データセットで、その中から脳全体の6分の1ほどにあたる、2万3200個余りの実ニューロンが使われています。

葵: ただ、Hacker News では、この案件をどう評価するかでもめています。「これこそ本物の AI だ」と絶賛する声がある一方で、公開された挙動を分析した人からは、提示されているよりはもう少し限定的だという指摘もありました。つまりハエが完全に神経回路に支配されているというよりも、実際の行動スクリプトが、その回路によって発火・トリガーされている、という方が正確ではないか、と。

悠真: デモ動画がないという指摘を受けて、作者が YouTube のリンクを共有したものの、別のユーザーが「それはこのプロジェクトのものではない」と訂正する一幕もありました。また、NeuroMechFly という既存のハエの身体シミュレーション環境を使えば、もっと本物に近づけられるという提案も出ています。

葵: それでも、668個のニューロンで可能なサイズのため、高速で動くという利点は大きい。実際にユーザーの中には、これを Claude に頼んでブラウザに移植して、スマホでハエをタップしたり、カメラでこちらの動きを読んだりできるようにしたい、という計画を語っている人もいました。正直さを明記した README への評価もあって、複雑な実装を公開してくれたこと自体は、多くの人が認めている印象ですね。

悠真: 「ノルウェーはOpenAIを買収すべきだ」という大胆な論考が、進歩的社会主義のジャーナル『One Thousand Means』でザカリー・ジョーンズ氏により公開され、Hacker Newsで激論を呼んでいます。記事は、AIの能力は制度による対応より速く進展しており、変革的な技術が資本主義の政治経済に衝突すれば人類の生存や民主的秩序へのリスクがあると主張。AIシステムを所有する階級への権力と富の集中を憂慮し、大規模言語モデルは集団的人間の努力の派生的著作物であり「囲い込まれるコモンズ」だと表現したうえで、2兆ドル超のノルウェー政府年金基金が、評価額約8000億ドルとされるOpenAIを購入し、国際社会の利益のために管理することを提案しています。実現には基金のマンデート違反が必要で、米国政府による阻止は明らかだと認めつつ、将来の政権に選択肢を残すべきだと論じます。議論では、単一企業が本当にそれほどの影響力を持つのかという前提への疑問や、猫は袋から出てしまったという表現をめぐる議論、東インド会社やコダック、グーグルの例を挙げた一企業が世界を変えた例への言及などが交わされました。

葵: 具体的な提案は、ノルウェーの政府系基金、いわゆる GPF-G が OpenAI を買収して、国際社会のために管理するというもの。基金は2兆ドル超、OpenAI の評価額はおよそ8000億ドルとされています。著者の理屈では、大規模言語モデルはインターネットから集めた、文字通り私たち全員の情報で訓練されたものだから、これは「囲い込まれた共有資源」だ、というわけです。

悠真: ただ、現実には実現までのハードルは相当高い。基金運用会社はポートフォリオの4割を売却しなければならず、しかもこれは基金のそもそもの運用目的に反します。さらに、米国政府がこの買収を止めることは明らかだ、と著者自身も認めている。それでも「将来の政権のために選択肢を残しておくべきだ」と論じています。

葵: コメント欄ではまず、「そもそも一つの企業が本当にそこまでの影響力を持っているのか」という根本的な疑問が出ました。AI はすでに存在して進歩し続けているから、誰が支配しても大きな流れは変わらない、という意見です。それに対して別のユーザーは、「もう猫は袋から出た」という言い方こそが、支配の不可避性を自分たちで作り上げている自己成就的予言だ、と反論しています。

悠真: また、「猫は袋から出た」という決まり文句自体に異議を唱える人もいて、「船は既に出航した」の方が適切だという指摘も。一方で、歴史的には一つの企業が世界を変えた例はあると指摘する声もあって、OpenAI がそういう企業になるかどうかは、未来の歴史書が決める問題だという示唆もありました。

葵: データベースのクエリ言語SQLを関数型で書き直す新しい言語を、Elmの作者であるEvan Czaplicki氏が作ったという記事がHacker Newsで持ち上がり、SQL好きと嫌いの間でおなじみの大論争になっています。Acadia Engineeringのブログ記事「Rethinking Database Programming」が紹介するのは、PostgreSQLとSQLite向けの新しい関数型クエリ言語です。コメント欄では、この言語はSQLのワンライナーを6行の読みにくいコードにするだけではないかという皮肉に対し、600行の悪夢のようなSQLクエリを60行の読みにくいコードに変える力のための代償だという応酬が展開されました。構文は末尾カンマ問題すら解決していないという指摘や、動的に構築されない限り600行のSQLのほうを選ぶという声も。一方、SQLはひどい言語でありElmのように合成可能な言語で書きたいという主張には、リレーショナルデータの扱い方としては全分野で一番好きだという反論が。また、プログラマーが嫌う性質が非プログラマーにとってのアクセシビリティになっている点でExcelと同じだという指摘や、Datalogがより良い代替案になり得るという声もあがっています。

悠真: あるコメンターは「この言語は SQL のワンライナーを、6行の読みにくいコードに変えるだけでは」と皮肉りましたが、別のユーザーは「600行の悪夢のような SQL を60行の読みにくいコードに変える力を得るための代償だ」と応じました。ただ、構文を見る限り、末尾カンマ問題すら解決していないという指摘も出ています。

葵: ここで再燃しているのが、SQL そのものの評価ですね。一方では「SQL はひどい言語だ」と断言する声もあれば、それに対して「プログラミング言語としてはともかく、リレーショナルデータの扱い方としては、全分野で一番好きな言語だ」と反論する声も。中には、プログラミングを知らない営業職の義父でさえ SQL を知っている、という話も出ていて、プログラマーが嫌う複雑さこそが、非プログラマーにとっての取っつきやすさになっていて、これは Excel と同じだという指摘がありました。

悠真: 実際に600行の SQL をどう扱うかという話になると、「動的に組み立てるのでなければ、600行の SQL のほうを選ぶ」という現実論もありました。SQL は十分に高水準な言語だからこそ、シンプルさと引き換えに何かを失っている、ということですね。それでも、Datalog という別の論理型言語の方がいい代替案になり得るという選択肢も提示されています。

葵: ちなみに Elm の作者は、過去のバージョンで GROUP BY という機能を削除してしまったことがあるそうで、そのネタを引っ提げて「今回こそちゃんと作って戻ってきたのか」という冗談コメントもありました。SQL の良し悪しをめぐる議論は尽きないですが、それだけ使い続けられている言語だという裏返しでもあるんでしょうね。

葵: Hacker Newsで注目を集めているのが、GitHub上の「RyanCodrai/turbovec」というオープンソースのベクトルインデックスです。Rust製でPythonバインディングを持ち、Google ResearchのTurboQuantアルゴリズムがベースになっています。READMEによると、TurboQuantはデータに依存せず、ほぼ最適な歪みを持つ量子化器で、ラベル付きの学習データが必要ない、訓練フェーズなしで動くという特徴があります。プロジェクト側の主張では、1,000万ドキュメントのコーパスはfloat32形式だと約31ギガバイトのRAMが必要になりますが、turbovecなら4ギガバイトに収まり、しかもFAISSより速く検索できるとされています。ベンチマークではFAISSのIndexPQFastScanをすべての測定構成で上回り、4ビットで平均3.4倍、2ビットで23%高速だとされます。ほかにも、訓練ステップなしのオンライン取り込み、手書きSIMDカーネルによる高速検索、変更分だけを永続化する増分保存、検索時フィルタリング、完全ローカル動作といった特徴が挙げられています。

悠真: そういう圧縮効率の話は大きなインパクトがありますよね。追加で挙げられている特徴としては、別途の学習ステップなしでドキュメントを段階的に取り込めるオンライン取り込み、そして最後の同期以降に変わった部分だけを保存する増分保存があります。それから、検索時にID許可リストやスロットのビットマスクで絞り込める、という柔軟性も。そして何より、マネージドサービスを必要とせず、データがマシンやVPCの外に出ない完全ローカル動作なのが、プライバシー重視のユーザーにとっては魅力的に映るでしょうね。

葵: 性能面のベンチマークも公表されています。FAISSのIndexPQFastScanという既存手法を、測定したすべての構成で上回ったとされていて、量子化ビット幅4ビットで平均3.4倍、2ビットに落とすと23%高速だったそうです。コメント欄では、1,000万ドキュメントで4ギガバイトという数字に驚く声や、逆インデックスの構築が以前よりはるかに速くなり、開発者体験がスムーズになるという指摘もありました。SQLiteバインディングのリリースを待ち望む声も出ていますね。

悠真: エージェント的なワークフローでの使い道を尋ねる質問には、ノートやドキュメント、Wikiが良いユースケースだと答える人もいました。Rust製ということで、WASMにコンパイルしてブラウザ拡張のなかで動かせないかという問いもあり、興味を示す返信があったようです。ただ、コメント欄には業界事情をからかう書き込みもあって、プロジェクトがAI生成コードだというジョークや、共著者として名前が出ている謎の人物の正体を問う声も上がっていました。皮肉と反論が交錯する、いつものHacker Newsらしい盛り上がりですね。

葵: ゲーム向けGPUのVRAM管理の話です。Natalie Vock氏がpixelclusterのGPUブログに書いた記事によると、氏が今年の初めに書いたゲーム向けVRAM管理の改善パッチ群が、メーリングリストで数か月審議された後、上流にマージされ、Linux 7.3に組み込まれる予定です。この記事が扱うのは、ゲームが物理VRAMの容量を超えてメモリを使うとき、何が起きるのかという問題です。理論上、VRAM枯渇は安定性ではなくパフォーマンスの問題であるべきで、物理VRAMを超えると一部のメモリはCPU RAMへ退避され、PCIバス経由のアクセスになるためレイテンシと帯域の両方で不利になります。記事によると、PCIe 4.0 x16接続なら帯域は32GiB/s弱で、30FPSを維持するには退避メモリから1フレームあたり約1GiB強を超えて読み出すと不可能になるといいます。RDNA3での測定では、6MBのL2キャッシュサイズでCPUメモリのアクセスレイテンシは約2400サイクルまで上昇し、PCIeフェッチはInfinity Cacheヒットの約7.3倍、VRAMフェッチの約4.6倍のレイテンシを持つとされます。

悠真: 理論上、VRAMの枯渇はシステムの不安定性ではなく、パフォーマンスの問題に留まるべきだと記事は説明しています。ドライバがVRAMをオーバーコミットする場合、要求自体は自由に受け付けられ、物理メモリに収まる範囲でカーネルドライバが割り当てを決める。物理VRAMを超えると、一部のメモリはCPUのRAM側に退避され、GPUからはPCIバスを経由してアクセスすることになるため、レイテンシと帯域の両面で不利になるんですね。

葵: そのコストを具体的に見積もると、PCIe 4.0 x16接続なら帯域は32ギガバイト毎秒弱、つまり毎ミリ秒約32メガバイトです。30フレーム毎秒、1フレーム33.3ミリ秒を維持するには、退避されたメモリから1フレームあたり1ギガバイト強を超えて読み出すと、もう不可能になるという計算になります。ただ、すべてのメモリが同等というわけではなくて、コマンドバッファのようなものはVRAMに余裕があってもCPU側に置かれることがあり、キャッシュヒットによってPCIeの初期コストを償却できる場合もあるそうです。

悠真: コメント欄では、一つのスキャンアウトイメージ、つまり画面への描画出力のバッファに対して4ギガバイトもの退避を観測したという記述に注目する声もありました。各フレームにこうしたイメージが存在することで、退避が連鎖してしまうという指摘ですね。単一の連続した物理メモリを常時予約すべきではないかという疑問もあれば、データを物理メモリ内で移動させてページテーブルを更新し、十分な連続ブロックを確保する方法を提案する人もいました。ゲームかどうかということにも議論が及んでいて、LLM推論には影響があるのかという質問には、ゲームのVRAMオブジェクトは種類が多く予測が難しい反面、LLM推論はデータ移動がそもそもボトルネックだから、影響は限定的だろうという見方が交わされていました。

葵: PythonのデータフレームライブラリPolarsの公式チートシートの話です。Hacker Newsで、オライリーの本「Python Polars: The Definitive Guide」の著者が投稿しています。ほぼ500ページになる本を2ページのチートシートに圧縮したといい、本人の言葉を借りれば「かなり非可逆圧縮」だけれど、役に立つものになったはずだとしています。PDFのほかに、アクセシブルなHTML版も用意されているそうです。

悠真: 約500ページを2ページに収めるというのは、まさに取捨選択の極みという感じがしますね。自分の本の要旨をその形に落とし込むのは、著者自身だからこそできたことでしょう。チートシートという形は、ちょっと特定の構文を思い出したい時や、使い慣れない操作を確認したい時に、本を引くより手軽ですから、実際に使う人が多いんじゃないでしょうか。

葵: 投稿者自身も、感想を聞きたいとコメント欄で呼びかけています。Polarsは高速なデータ処理で人気のライブラリなので、このチートシートがどれだけ使いやすいかは、日常的に使っているユーザーからすれば大きな気になるところでしょう。紙に刷って机の脇に貼っておく、という定番の使い方にもちょうど良さそうです。

葵: Appleが2026年8月18日、欧州連合、EU向けアプリの事業条件の変更を発表しました。Appleの説明によると、この変更は欧州委員会との緊密な連携を経て行われ、事業条件と代替配信をめぐるAppleと委員会の間の不一致を解消するものだといいます。EUでアプリを配信するすべての開発者を単一の事業条件にまとめて複雑さを軽減するのが狙いで、開発者は本日から新条件に署名でき、変更は10月1日に発効します。新モデルでは、Appleはデジタル商品・サービスの販売に手数料を課します。並外れた規模に達した開発者向けのインストール単位の料金であるCore Technology Feeは、App Store外で配信されるアプリ内のデジタル取引に対する5%の手数料、Core Technology Commissionに置き換えられます。

悠真: 新しいモデルでは、Appleはデジタル商品やサービスの販売に対して手数料を課します。そして、これまでインストール単位で課されていたCore Technology Feeは、App Storeの外で配信されるアプリ内のデジタル取引に対する、単純な5パーセントの手数料、Core Technology Commissionに置き換えられます。つまり、大規模なアプリ開発者へのインストール課金が廃止され、売上比例の手数料に一本化されるというのがポイントです。

葵: Hacker Newsの反応は真っ二つに分かれました。Appleがようやく折れ始めたと歓迎する声もあれば、当初から勝ち目はなかったのに時間とお金を無駄にしたと批判する声も。中には、この混乱でAppleが「次のNokia」になると極端な予測を飛ばす人もいましたが、それは現実とかけ離れているという反論もすぐに寄せられていました。AIがどう関係するのかと首をかしげる人もいて、議論が本筋からずれるのもHacker Newsらしいところです。

悠真: 誰が譲歩したのかという点も、見解が対立しています。欧州委員会が折れて開発者が負けたという主張がある一方、むしろAppleが引き下がったのだから、これはEUの消費者にとって前向きな一歩だという見方も。また、アプリは依然としてAppleの審査手続きを通らなければならない上、Appleは手数料の取り分も維持し、特定の理由なくアプリを禁止できるという現実を指摘する声もありました。そもそも欧州委員会が「不一致を解消する」と公式に確認したのか、それともこれはAppleの希望的観測に過ぎないのか、という核心的な疑問を投げかけるコメントも目立ちましたね。

葵: Metaが顔認識と人物の自動記録に関する特許を出願したという話題です。Privacy Guidesのニュースで取り上げられ、Hacker Newsでも広く議論されています。特に注目なのがコメント欄での受け止め方で、「将来、みんなのメガネが人々を自動記録するようになる。将来、みんなの自動記録はすべての人が完全にアクセスできるようになる」という書き込みがありました。さらに、将来のメガネはARグラスにもなり、誰でも他人の視点を閲覧できるようになる、という近未来を描くコメントです。

悠真: このコメントが示唆しているのは、メガネ型デバイスによる常時記録が普及し、撮影した映像が共有や相互閲覧の対象になる世界観です。顔認識と自動記録の特許という文脈では、プライバシーの懸念は避けて通れません。Metaが特許を出願したからといって、すぐに製品化されるわけではありませんが、現実の技術開発の方向性として頭の片隅に置いておく必要はあるでしょう。個人の常時撮影がどれほど社会的に受け入れられるのか、議論はこれからも続きそうです。

葵: 破綻した米格安航空会社スピリット航空の顧客データを、グーグルが競売で落札したという話がハッカーニュースで話題です。題名だけ見ると突飛に思えますが、実際のところ何が起きたのか、データの扱いをめぐって多くのコメントが寄せられています。あるコメント投稿者は、こうしたことが法的に許されるのか疑問を呈し、「匿名化されたデータ」という説明にも疑いの目を向けています。議論では、破綻企業の顧客データが競売にかけられ、AI企業に買われるという流れの妥当性や、個人情報の保護が実際にどこまで機能しているのかが問われています。データの匿名化が実効性を持つのか、そしてこうした取引が消費者にどのような影響を与えうるのかが、投稿の注目ポイントです。

悠真: 中でも議論を集めているのは、いわゆるデータの匿名化、つまり「deidentified」と称して個人を特定できないようにしたという説明に対してです。あるコメントは、それに「私のかわいそうな亡霊だ」と痛烈な皮肉を返していて、匿名化の実効性に疑いを持っている様子がうかがえます。

葵: 別のコメントでは「そんなことがどうして法的に許されるんだ」という声も出ていますね。同じ話題が別のスレッドでも重複投稿されたりしていて、このニュースへの関心の高さを物語っています。破綻企業の資産として競売にかけられた顧客データを、大手技術企業が入手するというケースが、法的にも倫理的にも大きな問いを投げかけているようです。

悠真: そもそも破綻処理の中では、こうしたデータ資産の扱いがしばしばグレーゾーンになります。消費者にとっては、自分の個人データが別の企業に渡されることを事前に知りようがないわけで、「匿名化された」という一言で済ませられてしまう点が、多くの人の不安を呼んでいるのでしょう。

葵: この落札が実際にどんな影響を及ぼすのかはまだはっきりしませんが、少なくとも、個人データが破産処理という文脈でどう移動していくのか、改めて考えさせられる話題であることは間違いありません。消費者側からの懸念は今後も続きそうです。

葵: ファームウェア更新の失敗で文鎮化したノートパソコンを、本人が自前で修理した事例がハッカーニュースで話題です。クアンタム氏の記事によれば、AMD製チップを載せたフレームワークの13インチ機がBIOS更新中の不具合で使えなくなり、約20ドル分の工具で自分で復旧させました。記事では、Frameworkのサポートが1年保証の期限切れを理由に、最低500カナダドル以上かかるマザーボード交換を提案したとされます。FrameworkフォーラムではこのBIOS更新で多くのユーザーが同様の問題を報告しており、2025年3月以降このモデルでBIOS書き込み全般のトラブルが報告されています。Frameworkは問題を認めていません。議論では、公式アップデートで文鎮化したなら保証を延長すべきだという主張と、そうすればメーカーが更新を出さなくなるという反論が交わされました。他のメーカーのファームウェア更新でも同様の被害が報告されています。

悠真: このパソコンは2023年に購入し、それまで3年間は問題なく動いていたそうです。ところが、セキュリティ修正を多く含むというバージョン3.20へのBIOS更新が推奨され、インストール中にシステムがハングして書き込みに失敗。フレームワークのサポートからはバッテリーを放電させて再起動するよう指示されたものの復旧せず、結局、保証期限切れを理由に、500カナダドル以上かかるマザーボード交換を提案されたといいます。

葵: フォーラムでは同じBIOS更新で多くのユーザーが同様のトラブルを報告していて、保証期間内の例もあったとのこと。フレームワーク自身は問題を認めていないそうですが、議論ではもっと根本的な主張も出ています。とあるコメントは、カスタムファームウェアを入れたら保証が切れるのなら、公式の更新を入れた場合はむしろ保証が延びるべきだという意見を展開しました。

悠真: それに対しては、公式更新で保証が延びるなら、メーカーが更新を出さない強い動機になるという反論も出ています。さらに、グーグルの過去の更新で似たような被害を受けたという報告も並び、スマートテレビのソフトウェアを「人類に対する犯罪だ」と表現するコメントまで飛び出しました。約20ドルの工具で自分で直したというこの記事は、ユーザーがメーカーの更新でマシンを失う心配をすべきではない、という声と結びつきながら、修理可能性の限界についても考えさせられる話題になっています。

葵: 話題はスマートフォンへ移ります。フェアフォンが米国で正式に展開を始め、新モデル「フェアフォン・ジェン・シックスプラス」を発表したことがハッカーニュースで注目されています。米国ではハワイとアラスカを除く全州に直販し、現地価格とサポートを提供するといいます。この機種はスナップドラゴン7sジェン4プロセッサを搭載し、RAMは最大12ギガバイトDDR5に増加。アプリの読み込み・切り替えが最大24パーセント高速化し、Android 16をプリインストール、ライフタイム中に6回のOSアップグレードを約束しています。ただし議論の中心はベライゾン非対応で、キャリアカバレッジの対応公示をめぐってスペックページとの矛盾も指摘されています。欧州ではどのキャリアでも使えるのにと疑問の声も上がる一方、米国では歴史的にキャリア固定が一般的だったと説明するコメントもあります。

悠真: 新モデルはスナップドラゴンのプロセッサを搭載し、メモリは従来より増えた8ギガから12ギガのDDR5に。アプリの読み込みや切り替えが最大24%速くなり、OSアップグレードはライフタイム中に6回、ソフトウェアサポートは2033年まで、保証は最長5年です。ユーザーが交換できる部品は12個で、バッテリーは最大53時間持つ設計です。

葵: ところが議論の中心は、むしろ米国最大手の通信キャリアであるベライゾンに対応していないことでした。あるコメントは、フェアフォンの米国注文ページに、主力の周波数帯に対応しておらず、ベライゾンのネットワークでの使用認定がないと書かれていると指摘。さらに、製品スペックのページでは対応しているように書いてあるのに、キャリア別の対応ページでは非対応とあり、矛盾しているという指摘まで出ています。

悠真: 欧州の人からは、どのキャリアのSIMでも使えるのになぜ米国だけ、という疑問も出ました。それに対して米国は歴史的にキャリア固定が一般的だったと説明する声や、別のキャリアへの乗り換えを検討しているという意見、逆に数十の機種が売られていると反論する声もありました。イギリスや欧州を中心に定着してきたフェアフォンが、米国市場でどこまで受け入れられるのか、キャリア対応という壁をどう乗り越えるかが当面の焦点になりそうです。

葵: 戦後のイギリスの砂糖配給を「自然実験」として使った研究が話題です。UKバイオバンクのデータをもとに1951年から56年生まれの6万人以上を分析したもので、配給は1953年9月に終了し、その後砂糖の摂取量はほぼ倍増したため、最初の1000日間の配給曝露量が人によって大きく異なります。配給を長く経験した人々は乳がんや肝臓がんなど複数のがんの発生率が低く、肝臓がんは約69パーセント低かったとされます。ただ議論では方法論への疑問が中心で、砂糖配給だけで歴史状況を単純化しすぎだと指摘する声や、コホート効果に弱いとの批判があります。配給ではマーガリンも魚油に変わっていたなど制度自体の複雑さを挙げる声や、戦後の食事・ストレス・環境変化をどう調整したのかを問うコメントも寄せられています。

悠真: 配給を長く経験した人々は、乳がんや前立腺がん、肝臓がん、直腸がん、肺がんの発生率が低かったそうです。肝臓がんはおよそ69%、乳がんはおよそ36%低く、この差は配給終了から数十年後に現れ始めました。さらにテロメアが長く、推定で約2.2年分の生物学的加齢の遅れに相当し、免疫の酷使を示す指標も低値だったと報告されています。

葵: 仮説としては、早期の甘さへの曝露が味覚を長期的に形成し、食事の好みや代謝、臓器、免疫の発達に影響を与えた可能性が示唆されています。ただ、ハッカーニュースの議論では、この方法論に厳しい目が向けられました。砂糖配給だけで戦後の状況を単純化しすぎだという指摘や、配給ではマーガリンも魚油などに変わっていたという制度的な複雑さ、さらに戦後の食事やストレス、環境変化をどう調整したのかという疑問です。

悠真: コホート効果に弱いとし、配給終了時期が異なる国や配給のない国で同様の傾向が出るかを見たいという意見もありました。一方で、砂糖のない家庭で育って渇望がなかったという体験談や、遺伝的な傾向ではないかという議論も出ています。結論は明確ではないものの、乳幼児期の栄養環境が何十年も後の健康に影響を及ぼしうるという、示唆に富んだ研究であることは確かです。

葵: 最後は、データセンターが近隣の気温に与える影響を、実際のフィールド計測で調べた研究がハッカーニュースで取り上げられています。「近隣スケールでのデータセンターの気温影響の現地測定」という題のこの記事は、都市部の熱環境という身近なテーマだけに、多くのコメントが集まりました。議論では、データセンターの排熱が居住地域の気温にどう影響しうるかをめぐって実体験や見解が交わされています。コメント欄では取り上げられた地域にまつわる冗談めいた投稿も見られ、この話題が幅広い関心を集めていることがうかがえます。データセンターの立地と近隣住民への影響は、AI需要の拡大でデータセンターが増える中、今後さらに大きな関心事となりそうです。

悠真: 議論の中では、笑い話のように語られるジョークもありました。テキサス州のマッキニーという都市を挙げて「マッキニーの全員が死んでいる」という動画ネタが貼られ、それに「初めての仕事はマッキニーだったのに、全員死んだとは悲しい」と返すようなレスが付いています。この辺りのコメントは少々冗談めいていますが、データセンターを含む大規模施設による周辺の温度上昇が、実感としてどれほど影響しているかを考えるきっかけになっています。

葵: 本来この研究は、データセンターの廃熱が都市部の暑さにどう影響を与えるかを、実測データで明らかにしようとしたものです。地域全体の気温上昇という目に見えにくい影響を、数値で示そうとするこうした取り組みは、データセンターの立地計画や都市設計を考える上で重要な材料になりそうです。

葵: Hacker Newsで注目された「指：死ななかったソーシャルネットワーク」という記事は、1971年、つまりインターネットが今の形になるずっと前に作られた指プロトコルという仕組みが今も生き続けていることを伝えています。つまり、投稿者が指摘するように、最も古いソーシャルネットワークは半世紀以上を経ても存続しているわけです。実に最小限の仕組みで、一つのセルから成り立っているとHacker Newsのコメントでも称賛されています。コメント投稿者smalltorchは、HNでも同じことができそうだと指摘しています。

悠真: 「指」と言われると少し意外ですね。ソーシャルネットワークの概念自体が当時あったんですね。

葵: ええ。当時は今のようにタイムラインや写真があるものではなく、超ミニマルなものでした。コメント欄でも「たった一つのセルだ」「これで十分だ」という声が上がっていて、基本情報欄として機能するだけのシンプルさがむしろ魅力だと受け止められています。

悠真: 今の巨大なSNSと比べると、その対比が面白いですね。つまり、機能を削ぎ落として「これだけあれば」という最低限の形が、時代を超えて生き残ったという見方ですね。

葵: まさにそうです。「最低限がいい」というのが、この記事とコメントの共通する感覚なんです。1971年という、今のソーシャルプラットフォームから見ればほとんど前史の時代の仕組みが、一度も途切れずに続いているという事実自体が興味深いところですね。

葵: Hacker Newsに投稿された「鉄道網をフラットベッドスキャナとして使う」という記事は、産業用ラインスキャンカメラBasler ruL2048-19gmを電車やフェリーの窓から向け、移動に合わせて1本の垂直ラインを連続撮影してつなぎ合わせることで超ワイド画像を作るプロジェクトを紹介しています。2026年2月にサンフランシスコ〜オークランド間のフェリーで撮影した56,894×2,048ピクセルのグレースケール画像が公開されており、EMFcamp 2026での講演も行われました。記事にはソファを「スキャン」した最初の実験や、同じくEMFcampでスリットスキャンカメラの講演を予定していたTim Jacobsとお互いネタが重複したのではと心配したエピソードなども含まれています。

悠真: つまり、動く風景そのものをスキャンするわけですね。実際にどんな画像が撮れたんですか。

葵: 2026年2月にサンフランシスコとオークランドの間のフェリーで撮影した、横幅5万6千ピクセルを超えるグレースケール画像が公開されました。あまりに長いので何が写っているのか見渡すのが大変なほどの画像です。このプロジェクトはEMFcamp 2026というイベントでも講演されました。

悠真: 面白いのは、同じイベントでスリットスキャンカメラの講演を予定していた別の開発者と、お互いネタが重複してしまうのではと心配したエピソードですね。結局その相手は、動画の中のあらゆる位置を試すトリッピーなアニメーションを作って区別したそうです。

葵: コメント欄には様々な思い出話が寄せられています。デジタルカメラ登場前にフラットベッドスキャナを電動モーターに載せて庭を撮影したブログを思い出す人や、2008年にウィキの生みの親と言われるウォード・カニンガムと、ポートランドの線路沿いのオフィスで窓から線路に向けて初期のカメラを試したという人もいました。

悠真: 列車の速度が画像の水平方向の圧縮に影響して、単位時間あたりのスキャン数を変えて調整できたけど、露出とカメラの自動調整が問題で結局何も保存しなかった、という細かい回想までありましたね。

葵: 時速150マイルという、日本の新幹線並みの速さの窓からの写真効果を「ブラックホールに吸い込まれる感覚に一番近い」と表現したコメントも印象的です。投稿者自身は、こうした「xをyとして使う」という発想の投稿が好きだと語り、AI関連以外の投稿だけを表示するサイトも作ったそうです。動きながらスキャンするという行為自体が、時間と空間の面白い伸縮になっているという評もありましたね。

葵: それでは、きょうの話題はここまでです。お付き合いいただき、ありがとうございました。 番組の中でのお話が、みなさんの何かのヒントになればうれしいです。

悠真: また次回も、どうぞお楽しみに。みなさんにとって、よい一日になりますように。

葵: それでは、またお会いしましょう。