0908 | 今週のテックニュース: Jellyfin 12.0、LGテレビ、そして旧暗号の終焉

葵: こんにちは、テクノロジーニュースポッドキャストへようこそ。私は葵です。

悠真: 悠真です。今朝のニュースから、気になる話題を深掘りしていきます。今日はバージョン12になったJellyfin、スマートテレビが聞いていたという話、VMwareからの脱出劇、25年前の暗号が破られた話、テスラの事故報告、開発ツール周り、そして修理権とデジタル主権まで。一見バラバラに見えますが、「誰がコントロールしていて、ユーザーはどこまで信頼できるのか」という一点でつながっていると思います。それではさっそくJellyfinから。

葵: そうですね。Jellyfin 12.0がリリースされました。まず何が起きたかというと、「10.」というバージョン接頭辞を廃止したんです。今まで10.8とか10.9とか、ずっと「10.x」で続いてきたプロジェクトだったんですが、今回は「12.0」として登場しました。

悠真: ずっと10.xのままだと、いつまで経っても古いメジャーバージョンに見えるから、というのは一つの動機として自然ですね。実際は機能面でかなりの変更が入っているのに、番号的には10.11とかのままでしたから。

葵: そこで番号を一気に飛ばして12.0、接頭辞も捨てて新体制を示したというわけです。ただ、このリリースで一番実用的に効いてくるのがデータベース移行です。移行が入るので、アップデート前にバックアップが必須、ということが明示されています。

悠真: ここは議論でも一番緊張感のあるポイントでしたね。メディアサーバーって、視聴履歴、再生位置、ユーザー設定、メタデータの関連付けまで全部データベースに入っている。バックアップなしで移行して失敗したら、家のサーバーが丸ごと初期状態に戻る。家族全員の「続きから再生」が消えるわけです。

葵: しかもJellyfinユーザーはセルフホスト勢が多くて、各自の環境がバラバラなんですよね。Dockerで動かしている人、ベアメタルで長年動かしている人、プラグインを大量に入れている人。移行パスが全部の環境で同じように踏めるかどうか、そこが不確実だからこそ「バックアップ必須」が強調されているんでしょう。

悠真: もう一つ、地味だけれど影響が大きい変更が、ユーザー名が大文字小文字を区別しない仕様になったこと。

葵: これは賛否が分かれるポイントでした。便利になったと言う人がいる一方で、既存のユーザー名と衝突の可能性があるんですよ。「Kenji」と「kenji」が別ユーザーだった環境だと、大文字小文字を無視した瞬間に同じ名前として扱われかねない。

悠真: ログイン周りで混乱する人も出ますよね。パスワードは区別するのにユーザー名は区別しない、という仕様に慣れていない人もいる。まあ大半のメジャーなサービスはユーザー名をケースインセンシティブにしているので、Jellyfinがそれに追いついたという見方もできます。

葵: 全体としては、番号の新しさより中身の移行の重さで語られていたリリースでした。次の追随バージョンが出てきた段階で、移行の安定性がどう評価されるかを見るのが良さそうです。では、話をリビングルームに移しましょう。さっきの「家のサーバー」の話から、その家にあるテレビの話。

悠真: Gamers Nexusの調査が話題になっています。LGのスマートテレビが、会話を録音して文字起こしし、そのデータをLG Ad Solutionsに送っていたという内容です。追跡対象となっていたテレビは2億1600万台。この規模感がまず驚きでした。

葵: しかも単に番組視聴履歴を取っているだけではない。画面がオフの状態でもマイクで音声を取得していたという指摘があります。テレビを見ていないから安全、ではないんです。

悠真: さらに、ローカルネットワークをスキャンしていたという報告もあって、ここが技術者層に強く刺さったポイントでした。自分のテレビが家の内部のネットワーク構成を調べている。これはプライバシーの問題というより、ほぼ侵入調査に近い動きですよね。

葵: 調査したGamers Nexusのアドバイスはシンプルで、「インターネットから切断すること」。これに対して議論が二つに割れました。一方は「全面同意」派。テレビはHDMI入力としてだけ使えばいい、ネットワークには繋がない。スマート機能は要らない。

悠真: もう一方は「現実的には難しい」派です。動画アプリや配信サービスをテレビで見るために買っている人にとって、ネット切断はテレビの価値を半分以上殺す。だからせめて初期設定時にトラッキングの同意を丁寧に切れ、というのが妥協案として挙がっていました。ただ、その同意の切る画面自体が分かりにくく設計されているのではないか、という不信の声もありましたね。

葵: 規模の話も重要です。2億1600万台という数字は、メーカーがテレビを「家電」ではなく「視聴データの収集端末」として運用していることを示している。一台あたりのリスクは小さく見えても、台数がこれだけあると広告ビジネスとして成立してしまう。

悠真: そこから派生して、「次に買うテレビはスマート機能のないモデルにする」とか「テレビよりプロジェクターの方がこうした仕組みが少ないのでは」といった現実的な回避策の共有が盛り上がっていました。あとは、自宅のルーターのDNSレベルでテレビの通信をブロックする、という技術的な対応も定番として話されていました。

葵: つまり最終的な結論は、「信頼できるかを個別に検証するコストを払うなら、繋がないのが最も確実」という、やや悲観的なところに落ち着いている感じですね。では次。これも「囲い込みと脱出」の話。BroadcomとVMwareです。

悠真: まず状況整理。Broadcomが、VDDKの公開ダウンロードを説明なしに引き上げました。VDDKはVMwareの仮想ディスクを扱うための開発キットで、サードパーティのツールがVMware環境を移行したり読み取ったりするのに使われています。これが公開されなくなった。

葵: 移行ツールを作っている側、あるいはVMwareからの脱出を試みている側にとっては死活問題です。しかもサポートに問い合わせても「利用不可」との回答だけ。理由の説明もない。

悠真: ここから議論が出てきたのは、BroadcomのVMware買収後の振る舞いとセットで見る見方です。ライセンス体系の変更で既存顧客のコストが上がり、そこへ移行を助けるはずの技術的入口まで絞る。脱VMwareを促したいのか、逆に足止めしたいのか、どちらにせよユーザーの選択肢が狭まっているという。

葵: 中には「これを機に、仮想化基盤への依存そのものを見直すべき」という声もありました。KVMやProxmoxといったオープンな代替への移行コストは確かに高いけれど、VDDKが無断で消える世界では、その移行コストを払ってでもロックインから抜ける価値がある、という考え方です。

悠真: そして面白いのが、その「脱VMware」が現実に起きている実例として、Tottenham Hotspurの事例が出てきたことです。プレミアリーグのサッカークラブですが、VMwareからHPE Morpheus VM Essentialsへ移行して、ライセンス費用を85パーセント以上削減しました。

葵: 85パーセントは大きいですね。サッカークラブというのはIT部門が大規模とは言えない組織で、それでも移行できた、というのが示唆的です。VM Essentialsというのは既存のVMwareツールやワークフローと親和性を持たせた形の製品なので、運用の引き継ぎが比較的スムーズだったのではないかと見られています。

悠真: 議論の中では、この事例を「価格交渉の新しい武器」として捉える見方が強かったですね。Broadcomの囲い込みが続く中で、大手顧客が実際に85パーセント削減に成功したという数字が一つ出るだけで、他の組織の移行判断が変わる。ベンダーにとっては契約更新の交渉が一段と難しくなる。

葵: 一方で慎重な意見もありました。移行自体のプロジェクトコスト、運用スタッフの再教育、障害時の切り戻しまで含めると、ライセンスの85パーセント削減が総コストの85パーセント削減ではない、と。それでも、方向性としては「出口が実在する」ことを示した例として意義が大きい、というまとまり方でした。

悠真: さて、ここから少し古典に目を向けましょう。旧い暗号がどう破られたか、という話と、旧いマルウェアのソースコードが公開された話です。どちらも「過去の資産がどうなるか」というテーマでつながっています。

葵: まず暗号の方。研究者が、1999年に出たNetscape 4.51に同梱されていたE-Certifyの512ビットRSA CAルート証明書を、デスクトップのGPU時代のRyzen CPUで約30時間で素因数分解したという話です。

悠真: 512ビットのRSAが、家庭のデスクトップマシンで半日強で破られる。これが意味するのは、25年前に正当に信頼されていたルート証明書が、今や個人の趣味の時間で突破できる強度しかないということです。

葵: 議論では「これは過去の話では済まない」という見方が強かったですね。長期アーカイブされた文書や古いバックアップ、今もどこかで動いているレガシーシステムには、同時代の暗号で保護されたデータがまだ残っている。当時は十分だった強度も、保存先に残る限り、追い越された時点で意味を失う。

悠真: だから「暗号化しておけば永遠に安全」という考え方は成立しない、という当たり前のようで、実務では忘れられがちな結論が再確認された形です。ローテーションや鍵長の引き上げは、退職した古い鍵を実際に捨てることまで含めてやらないと意味がない、という指摘もありました。

葵: そしてもう一つ。Stuxnetの再構成されたソースコードがGitHubに公開されました。約1万5千行。逆コンパイルされたバイナリから復元されたもので、研究・教育目的に限るとされています。

悠真: Stuxnetは2010年頃に発見された、イランの濃縮施設を狙った極めて精巧なマルウェアです。それが逆コンパイルから復元されてGitHubに置かれた、というのは意識的な選択で、実際にソースコードレベルでどう書かれているかを読める形にしたこと自体に価値がある、というのが公開者の立場です。

葵: 議論はきれいに二つに分かれました。一つは「歴史的文書として公開する価値が十分にある」という立場。実務的なウイルス作成の教科書というより、国家規模のサイバー攻撃がどう構成されていたかの一次資料であり、防御側の研究にこそ必要な資料だという。

悠真: もう一つは「復元コードが正確かどうか検証できないのに公開してよいのか」という疑念です。逆コンパイル由来のコードは元のソースと意味がずれることがあり、間違った形で「Stuxnetの実装」が広まってしまうリスク。それから、研究目的と謳っても、悪用の閾値を下げる可能性はゼロではない、という。

葵: ただ、ここでさっきの512ビットRSAの話とつながるんですね。25年前の防御が崩れた今、当時の攻撃コードを防御側が研究できるようにしておくことの価値が上がっている、と捉えることもできる。

悠真: どちらにしても、二者択一には解決しない問題として残りました。公開が適切だったかは未解決のまま。では、話題を変えて、少し重い話を。テスラの事故報告です。

葵: ニュージャージー州で、FSD、つまりフルセルフドライビングあるいはオートパイロットの作動が確認されたテスラのモデル3が、一時停止を無視して衝突し、82歳のドライバーが亡くなった事故です。

悠真: ここで一番議論を呼んだのは、運転支援システムが作動していたと「確認された」という点です。つまり、単に「FSDが入っている車だった」という話ではなく、当時実際にFSDあるいはオートパイロットが関与していた状態だったと裏付けが取れている。それでも一時停止を見過ごした。

葵: そしてもう一つの、透明性の問題です。テスラがNHTSA、アメリカ道路交通安全局に提出した資料の中の重要なフィールドを黒塗りしていたことが判明しました。

悠真: この黒塗りに対する反応は厳しかったですね。規制当局への提出資料で重要な部分が隠されていると、事故の根本原因がどこにあったのか、ソフトウェアの判断だったのか、ドライバーの監視不足だったのか、そもそも車両の設計だったのか、外部から検証する手段が失われる。

葵: 議論では、責任の所在というのが核心でした。FSDが作動中であれば、運転の主体はどこにあるのか。法律上は今もドライバーに注意義務があるとされているけれど、システムの名前に「フルセルフドライビング」と入っていることで、ユーザーの過信を誘うのではないかという批判は昔からありました。今回の事故はそれが現実になった形、と。

悠真: 一方で、だからといってFSDを全面的に禁じれば安全かというと、そうでもない、という現実的な意見もありました。人間のドライバーも一時停止を無視して死亡事故を起こしている。支援システムが一律に悪いと結論付けるのではなく、事故データと設計の両方を検証可能にすることが先決、と。

葵: そこで、やはり黒塗りが足かせになる。透明性がないまま議論しても、擁護も批判も検証できない。法規制がどう進むか、NHTSA側がこの黒塗りをどう扱うかが、今後の焦点だということですね。では少し空気を変えて、開発ツールの話題を二つ。

悠真: まずTerrastructのTALAです。アーキテクチャ図のレイアウトエンジンなんですが、これがオープンソース化されました。ライセンスはMPL-2.0。そしてD2のバージョン0.9.0に同梱されています。

葵: TALAは、コードから図を生成するときの、要素をどこに置くかというレイアウト計算を担当する部分です。従来の汎用グラフレイアウトエンジンは、グラフ理論的には正しくても、アーキテクチャ図としては読みにくい出力になることがありました。TALAはアーキテクチャ図専用に設計されている。

悠真: オープンソース化に対する反応は概ねポジティブでした。「ツールが閉じていると、レイアウトの癖に対処しようがなかった」という声が多くて、これでレイアウトが気に入らないときにコードを読めるようになった、と。

葵: 開発者からすれば、レイアウトエンジンというのは黒魔術の領域なので、自分でいじれる選択肢が増えること自体が価値なんですよね。D2と合わせて、コードで図を書く流れがさらに実用的になったという見方でした。

悠真: もう一つはvLLMのブログです。AMDのMI300XとMI355XのGPU上で、speculative decodingのベンチマークがROCm環境で公開されました。対象はMTP、EAGLE-3、DFlash、DSparkという手法。

葵: speculative decodingというのは、小さいモデルが高速に推論候補を出し、大きなモデルがそれを一括で検証することで、推論を速くする手法です。この分野、これまではNVIDIAのCUDA環境での結果が中心で、AMDのROCmでここまで体系的なベンチマークが出たのは珍しい。

悠真: 議論では「ようやくAMDが本格的に追い上げてきた」という雰囲気があったですね。推論基盤を選ぶとき、CUDAにしかない最適化が不足しているとAMDを選びづらかった。speculative decodingがROCmで動き、しかも数字が出ているというのは、選択肢の幅が実質的に広がったことを意味する。

葵: もっとも、手法によって得意不得利があって、MTPとEAGLE-3は成熟している反面、DFlashやDSparkはまだ新しい、という区別も必要と指摘されていました。どの手法がどのワークロードで速いかは、結局、自分のモデルとトラフィックパターンで測るしかない、と。

悠真: 図を書く選択肢と推論を走らせる選択肢、両方に選択肢が増えた、という話で締めましょう。では最後の大きなテーマへ。ユーザーの利益より事業者の都合が勝つ、という共通の構造を持つ三つの話題です。

葵: 一つ目、EUの修理可能性ルールです。施行から1年経った段階で、Right to Repair Europeの調査によると、新品スマートフォン2,334台のうち、修理情報へのリンクを掲載していたのは約18パーセントでした。

悠真: 約18パーセント。ルールが存在しているのに、8割以上が従っていないか、あるいはグレーな形で回避している。この数字の受け止め方は分かれました。規制の設計が甘い、という見方と、罰則の執行が追いついていない、という見方。

葵: どちらにしても、紙の上のルールと現場の運用の間に大きな溝があるのは確かです。修理情報が見つからなければ、消費者は修理を選べない。結果的にメーカーの意向どおり新品への買い替えが進む。ルールがあっても実効性がなければ、ユーザーの選択肢は実質的に増えない、という。

悠真: 二つ目はTiVoです。無料で広告を自動スキップしてくれていたSkipModeという機能が、2026年11月2日から廃止されます。そして月額課金の有料アドオンを試しているという報道です。

葵: これは議論が白熱しました。録画をした自分のコンテンツから広告をスキップする機能を、後から有料化する。買ったときの製品の価値が事後に減るわけで、製品を所有しているという感覚そのものが壊れている、という批判が根強かったですね。

悠真: 一方で、広告スキップの仕組みが広告主との契約構造を壊していて、無料のまま維持するのは商用として無理だったのでは、という現実的な見方もありました。ただ、その場合も、既存ユーザーの期待を裏切る形ではなく、最初から明示すべきだったという点は変わらない、と。

葵: そして三つ目が、スイスです。連邦の3,000席をMicrosoft 365からオープンソースのopenDeskへ移すパイロットを開始しました。目標は2027年、そしてデジタル主権法という法律も制定されています。

悠真: ここまでのTiVoや修理情報の話と対比すると、スイスの事例は「対抗策が政府レベルで実行できている」例として参照されていました。民間の個人ユーザーがソースコードを選べない場面は多いけれど、政府や大規模組織は選べる。選べるなら選んでおくべきだ、という立場の裏付けです。

葵: もっとも、3,000席はスイス連邦全体からすればパイロット規模で、2027年の目標が達成できるかどうかはまだ分からない。公共部門のIT移行は技術より調達と運用の惯性が壁になる、という慎重な声もありました。でも、デジタル主権を法律のレベルで定義したこと自体は、他国が参照できる前例として大きい、という評価が多いですね。

悠真: まとめると、こうなります。企業はデータを集める、機能を後から有料化する、移行の入口を閉める。それに対して、政府は法律で主権を確保し、クラブは代替基盤に逃げ、ユーザーはテレビからLANケーブルを抜く。どの話題も、コントロールの取り合いの最前線に立っている。

葵: そして、その取り合いで技術者が果たす役割も今日の話題にたくさん出てきました。バックアップを取り、DNSでテレビをブロックし、代替ツールを検証し、古い鍵を捨てる。個々の対応は小さいけれど、選択肢を手元に残しておくこと、それが今日の教訓かなと。

悠真: というわけで、今日はここまで。聞いていただきありがとうございました。それではまた次回、お会いしましょう。

葵: ありがとうございました。また来週。