TP-Linkルータは本当に危険?真実を探る

はじめに

Youtubeでは、TP-LINKのルータに関して、極めて出どころの怪しい情報が飛び交っているようです。聞いた感じだと、

  • パケットを中国に転送している
  • VPNが自動切断される

このようなところだと思います。しかし、これは極めて怪しいと言わざるを得ません。私が考えるに、パケットを中国に転送しているというのはダウトだと思います。それは、分析だけで手間すぎるし、そもそも、中国へのルートが酷い輻輳を起こすのが明らかだからです。

VPNは中国国内だとかなり規制されているので、代表的なポートが塞がれている可能性はなくはないです。日本国内での利用だと甚だ迷惑ですが。

いくつかYouTubeの動画などを確認しましたが、危険説は米国政府の発表などが全てで、ソースコードのリバースなど客観的な根拠は見当たりません。せいぜいが、国家情報法ですね。しかし、そういう法律があるというのは行われている根拠にはなりません。

TP-Linkとは

「TP-Link」は、ネットワーク機器の製造や販売などを行っている企業です。1996年に設立され、現在は1万円以下という低価格で購入できるWi-FiルーターやWebカメラなどが人気を博し、世界170か国以上で10億人を超えるユーザーにネットワーク関連製品を提供しています。世界44か国に現地法人を設置しており、日本には2015年に子会社である「ティーピーリンクジャパン株式会社」を設立しています。

実現性の検討

VPNの自動切断は一応、実現可能です。しかし、VPNかどうかの判別は正直、難しいのでこれも眉に唾を100リットルくらい塗るレベルですね。ただ、それ以上に私が怪しんでいるのはルータのファームウェアをばらしたレポートが一つもないことです。というか、ルータに問題があり得るなら、ファームウェアをばらせば一発です。故に、私はそのようなレポートがない以上、本件自体が虚偽と考えざるを得ません。

TP-LINKのコード

実は、TP-LINKのコードの多くは、GPLのコードです。したがって、多くの機種でコードが公開されています。もちろん、リビルドにはそれ相応の手間がかかるとは思います。そして、リバースエンジニアリングした方もいらっしゃいます。以下の記事でリバースエンジニアリングの例を見ることができますが、ロジックボムや隠されたゲートが発見されたという情報は確認できていません。

Reverse engineering my router’s firmware with binwalk

また、GPL上、ルータに書き込まれているバイナリとソースコードに不整合がある場合、GPL違反に問われるリスクがあります。そのようなリスクを冒して、トロイの木馬を埋め込むのはかなりハードルが上がると言わざるを得ません。

GPLは、ソフトウェアの自由な利用、改変、配布を保障するライセンスですが、その条件を遵守しない場合、法的な問題が発生することがあります。具体的には、GPLに基づくソースコードを使用しているにもかかわらず、ファームウェアにその変更点やソースコードを公開しない場合、著作権侵害として訴えられるリスクがあります。

検討

当然、本件が事実であると仮定した動画はすべて、疑いの目で見ることになります。私個人としては、適切なソースを引用していない場合、このような動画はすべて通報対象としています。

家庭用ルータの脆弱性

家庭用のルータの場合、特にUPnP周りが脆弱になることは比較的多いです。ネットワーク経由のゲーミングではポート開放が前提になることがあり、それがどのように設定されているかによっては致命的な脆弱性を実装するリスクがあります。

UPnP (Universal Plug and Play)とは

UPnP(Universal Plug and Play)は、ネットワークに接続されている機器同士が自動的に通信し、必要な設定を自動で行うための技術です。この技術により、ユーザーは手動で設定を行う手間を省くことができます。特に、ネットワーク経由のゲーミングやストリーミングサービスでは、UPnPが重要な役割を果たします。この種のゲートウェイ機器では、UPnPによるポートの自動開閉が定義されており、必要に応じてポートが自動開閉されます。

しかし、その利便性の反面、UPnPはセキュリティ上の脆弱性を抱えることが多く、適切に設定されていない場合や脆弱な実装がされている場合、外部からの不正アクセスのリスクが高まります。家庭用ルーターにおいても、UPnP機能の脆弱性がしばしば指摘されています。

監視とロギング

本来、このような問題の対処には監視とロギングが必要ですが、技術者以外にはその判断が困難です。家庭用ルータでsyslog転送などを持っているものはほとんど見受けられません。

終わりに向かって

個人的には、生成AIなどでこのようなスキルを埋めることができないかと思いますが、現状では生成AIの必要な負荷と家庭用のルータに利用されるプロセサのスペックを勘案すると、難しいと言わざるを得ないですね。

Delta Lakeの楽観的排他制御:ACID特性の詳細と実現方法

仕事で、Microsoft Fabric絡みのところを調べていました。

基本、Fabricの中ではApache Sparkなどが動いていることは判っていたので、Delta LakeでACID特性が実現されているというのもなんとなくわかっていました。では、どのようにしてACID特性が実現されているのかというところには関心がありました。この辺に関して触れられているのは以下のQiita上の記事です。

https://qiita.com/toshimitsuk/items/5dac76dddfe921cb8a47

そして、上記記事の次のところに着目しました。

Delta Lakeのソースコード (https://github.com/delta-io/delta) から、Delta Lakeの楽観的排他制御の仕組みを見ていきます。なお、ここではUpsertを対象に楽観的排他制御の仕組みを見ていきます。(再掲)

なるほど、楽観的排他制御かと。 では、楽観的排他制御とはなにかということです。

悲観的排他制御

これと対照的な概念が悲観的排他制御です。 悲観的排他制御とは所謂ロックによって排他制御を実現します。

こちらの方がよく知られているでしょう。いわゆるUpsertの場合において考えます。Upsertは排他制御がよくわかるところです、Upsertを仮に選択と条件分岐と更新と追加の組み合わせで考えます。

  1. 対象キーでレコードが存在するかどうかを確認する
  2. もし、レコードが存在すれば更新する
  3. レコードが存在しなければ追加する

これをそのまま実装してしまうと、1.と2.の間に割り込まれてしまうと、その間に重複するレコードが作成されてしまうリスクが発生します。結果的に、3.は正しく、Primary Keyなどの処理が実装されていればエラーになります。

Upsertであれば、悲観的排他制御であれば、1.のタイミングで対象となる表などにはロックが作られ、割り込み処理は一般的には待たされます。結果として、Upsertは完遂できます。仮に、待たされた方が自動連番などでキーを発生させていれば、その後により後のキーが発行されて正常に終了するでしょう。

楽観的排他制御

では、これが楽観的排他制御ではどうなるでしょうか? 楽観的排他制御ではロックではなく、更新の検出により処理します。つまり、処理する前に、割り込まれたことを検出して処理をします。 つまり、なぜ楽観的なのかというと、滅多に抵触する処理は行われないはずという仮定があります。 このあたりの詳しい話については以下の記事も参考にできます。

https://qiita.com/NagaokaKenichi/items/73040df85b7bd4e9ecfc

  1. 検証: 最初にレコードの現在の状態を取得し、その状態を記録します
  2. 更新の準備: データを更新する準備をします
  3. 更新の試行: 更新を試みますが、その際に他のトランザクションが同じレコードを変更していないかを確認します
  4. 競合の対処: 他のトランザクションが変更していた場合は、更新を再試行するか、エラーを返します

パフォーマンスと課題

さて、悲観的排他制御と楽観的排他制御の差はどこにあるのか? 一つのポイントはパフォーマンスです。悲観的排他制御はロックを行うため、そこがパフォーマンス上のボトルネックになります。では、楽観的排他制御は銀の弾丸か? そんなことはありません。銀の弾丸はどこにも存在しないのです。

楽観的排他制御の弱点は、更新の検出にあります。これが崩れればすべてがお釈迦です。そして、楽観的排他制御のポイントは、楽観的、競合することはそうそう起きないだろうにあります。競合がかなりの頻度で起きるとすればどうでしょうか? ほとんどの場合で、何らかの回避動作が必要になります。更に、その回避動作は正しいのかの検証も極めて重要です。

結論から言うと、楽観的排他制御は難易度が高いです。その意味ではロックして、競合処理を起こさないようにする悲観的排他制御の方がシステム的な難易度は低いです。パフォーマンスの劣化は大きな課題ですが。

テキストエンコーダーとベクトル演算が引き起こすプロンプト混在の謎

スタジオ真榊のAIイラスト術解説になぜ、複数キャラクターのプロンプトが混じってしまうのかというのがあるので、私なりに解説を試みてみましょう。

まず、画像生成AIのプロセスについて考える必要があります。代表的な、画像生成AIであるStable DiffusionについてはDeep Learning 論文 Advent Calendar 2022に参加された、omiitaさんの表した、「世界に衝撃を与えた画像生成AI「Stable Diffusion」を徹底解説!」があるのでこれを下敷きにします。

Stable DiffusionはText Encoder、拡散モデル、VAEというパーツで成り立っています。基本的にはプロンプトを解析する、Text Encoder、画像生成に重要な役割を担う拡散モデル(U-Net)を考えます。VAEは拡散モデルのはらんでいる問題点の解決には重要ですが、あとで考えても構わないと思います。

まず、「複数キャラクターのプロンプトが混じってしまう」要因には、Text Encoderが大いに関わっています。Stable DiffusionではText EncoderにCLIPという手法を使っていますが、これの役目はテキストをベクトルに変換することです。まず、試みに、”(1 girl, blue hair color), (1 boy, red hair color)”というプロンプトを考えます。

“()”は通常、Stable Diffusionでは、重みづけ以上の意味を持ちえません。故に、見た目ではグループ化のように見えますが、Stable Diffusionでは重みづけ以上の意味はありません。さて、ベクトル表現とはなんでしょうか? これは分散表現と大いに関係があります。

例えば、Kingという言葉を分散表現でとらえるとき、このような考え方ができます。King→男性の統治者、そうすると男性という概念と統治者という概念で表現できます。簡単に表そうとすれば(1,1)というベクトルでしょうか。この場合、最初の次元が例えば男性という概念、統治者というのが2次元目とします。

さて、女王と言うものを考えるためにベクトルの次元を増やしましょう。2次元目として女性という概念を加えます。この場合、先ほどの例は(1,0,1)というベクトルで表現できるかもしれません。昔、Word2vecが大流行りしたときに、王-男性+女性=女王というサンプルが多く見られました。これは以下の計算で、この例に当てはめられます。

(1,0,1)-(1,0,0)+(0,1,0)=(0,1,1)

ここまで、考えると、なぜプロンプトが混じるのかに答えが見えてきます。理由はベクトルの計算において、混じってしまうからです。先ほど、述べたように、()はStable Diffusionにおいて、重み以上の意味はありません。従って、書いたつもりになっていても単にベクトル演算の押し合いへし合いでかき回されているだけになります。

では解決策はどうするのか、何とかして計算を分離すればいいとなります。例えば、Latent Coupleなどでは、領域を分割して、そこに独立してText EncodingやU-Netを構築します。この辺は「複数キャラクターを分けて生成するLatent coupleの改良版!(Attention Couple)」あたりの解説を読むのが適切です。

以上、なぜ、プロンプトが混じるのかを解説してきました。

なぜ、VAEは特に説明しなかったのか? それは、基本的には拡散モデルの計算量を削減するための仕組みであり、実際上、VAEは画像の仕上がり具合には大きな影響がありますが、特に、最近では、VAEはモデルに組み込まれているものをそのまま使うことが多く、SD 1.5時代のように色味とかを考えてVAEを案じることがほぼ見られなくなっているため説明を省略しました。

2025年に廃止されるAzureサービス:移行先と最適な代替案

2025年に廃止になる、Azure関係のサービスは以下のような感じです。

2025/1/6

Microsoft Genomics

2025/3/31

Visual Studio App Center

2025/6/30

SAP HANA Large Instances

2025/9/30

Azure Database for Maria DB
Azure Basic Load Balancer
Azure HPC Cache
Azure Remote Rendering
Azure Service Map
Azure SQL Edge
Azure Unmanaged Disks
Azure vFXT

時間が限られているので難しいものもありますが、わかる範囲で考えていきます。SAP HANA Large Instancesは時間が限られていますが、Azureのサポートされているインスタンスサイズへの移行が考えられるでしょう。その意味では、テストが課題ですが比較的可能な範囲かなと思います。

Azure Database for Maria DBはだいぶ前からアナウンスがかかってましたし、恐らく、Azure Database for MySQLが考えられるでしょう。DDLなどのテストは必須ですが、他のオプションよりは考えられるでしょう。

Azure Remote RenderingはHololens2とWindows 10に向けた、レンダリングソリューションなので、実質、Windows 10のMRがリタイアしてしまえば存在意義を失うのは確かです。

Azure SQL Edgeは地味に面倒かもしれないです。まず、状況によるといったところです。SQL Serverは検討され得ますが、x64のみのサポートなのでエッジデバイスでARMの場合には検討対象から外れます。その場合、SQLiteなどを考慮できますが、クラウドとかにミラーリングが発生するならば厄介です。その場合、エッジデバイス内はmemcachedとかにして、クエリをキャッシュするという戦略の方がいいかもしれないです。

考えられる範囲でまとめてみました。

2025年に終了するMicrosoftの製品群

窓の杜の記事 “2025年にサポート終了となるMicrosoft製品をチェック 〜Windows 10が10月に引退へ” からです。大きいところでは、Windows 10のサポート終了が大きいですね。あと、デッドラインが迫っているのはMicrosoft Genomics、移行先としてはCromwellOnAzureが挙げられていますがパット見た感じはいそうですかと移行はできなさそうです。

Dynamics系列の移行も迫っているので注意が必要です。あとは、忘れてはいけないのが、Azure Database for MariaDBの終了予定ですね。

クラシックポリシー

2025年1月6日

  • Microsoft Genomics

2025年3月31日

  • Visual Studio App Center

2025年6月30日

  • SAP HANA Large Instances (HLIs)

2025年9月19日

  • Azure Database for MariaDB

2025年9月30日

  • Azure Basic Load Balancer
  • Azure HPC Cache
  • Azure Remote Rendering
  • Azure Service Map
  • Azure SQL Edge
  • Azure Unmanaged Disks
  • Azure vFXT

2025年10月14日

  • Windows 10 Enterprise and Education
  • Windows 10 Home and Pro
  • Windows 10 IoT Enterprise

モダンポリシー

2025年4月2日

  • Dynamics 365 Business Central on-premises (Modern Policy), 2023 release wave 2, version 23.x

2025年4月9日

  • Microsoft Configuration Manager, Version 2309

2025年10月7日

  • Dynamics 365 Business Central on-premises (Modern Policy), 2024 release wave 1, version 24.x

2025年10月14日

  • Windows 11 Enterprise and Education, Version 22H2
  • Windows 11 IoT Enterprise, Version 22H2

2025年10月22日

  • Microsoft Configuration Manager, Version 2403

2025年10月24日

  • Windows Server Annual Channel, Version 23H2

2025年11月11日

  • Windows 11 Home and Pro, Version 23H2

固定ポリシー

2025年1月14日

  • Dynamics C5 2015
  • Dynamics CRM 2015
  • Dynamics NAV 2015
  • Dynamics SL 2015
  • Visual Studio 2022 , Version 17.6 (LTSC channel)

2025年4月8日

  • Dynamics GP 2015
  • Dynamics GP 2015 R2

2025年7月8日

  • Microsoft SQL Server 2012, Extended Security Update Year 3
  • SQL Server 2014, Extended Security Updates Year 1
  • Visual Studio 2022 , Version 17.8 (LTSC channel)

2025年10月14日

  • Access 2016
  • Access 2019
  • Dynamics 365 Business Central on-premises (Fixed Policy)
  • Excel 2016
  • Excel 2019
  • Exchange Server 2016
  • Exchange Server 2019
  • Microsoft Office 2016
  • Microsoft Office 2019
  • Microsoft Report Viewer 2015 Runtime
  • OneNote 2016
  • Outlook 2016
  • Outlook 2019
  • PowerPoint 2016
  • PowerPoint 2019
  • Project 2016
  • Project 2019
  • Publisher 2016
  • Publisher 2019
  • Skype for Business 2016
  • Skype for Business 2019
  • Skype for Business Server 2015
  • Skype for Business Server 2019
  • Visio 2016
  • Visio 2019
  • Visual Studio 2015
  • Visual Studio Team Foundation Server 2015
  • Windows 10 2015 LTSB
  • Windows 10 IoT Enterprise LTSB 2015
  • Windows 10 Team (Surface Hub)
  • Windows Defender Exploit Guard
  • Windows Defender for Windows 10
  • Windows Server 2012, Extended Security Update Year 2
  • Windows Server 2012 R2, Extended Security Update Year 2
  • Word 2016
  • Word 2019

Windows メールのサポートが終了しました

Windowsメールのサポートは2024/12/31をもって完全に終了し、送受信共に不可能になったと思われます。こちらの環境では既に、Outlook (new)に置き換えているので追試は不可能ですがそうなったと思います。今までWindowsの標準的なメールは以下のものがありました。

  • Outlook(new)
  • Outlook(old)
  • Windowsメール

Windowsメールの終了で、基本的にはOutlookに集約されたと思います。Outlook(new)はモダンな実装ですが一方で、COMベースのアドインの実装は無くなっています。Outlook(old)のサポートは2029年まではされると聞いていますが対応は速い方がいいでしょうね。

Windows Hot Patchとは?技術的課題とその解決策

1. はじめに

WindowsのHot Patch機能は、システムの稼働時間を最大限に維持し、セキュリティの向上を図るために設計された重要なツールです。本記事では、Windows Hot Patchの導入方法とその利点について詳しく解説します。Windows Hot PatchはIgnite 2024で紹介されました。

2. Windows Hot Patchとは?

Windows Hot Patchは、システムの再起動を必要とせずにソフトウェアのパッチを適用する技術です。これにより、システムの稼働時間を最大化し、業務の中断を最小限に抑えることができます。

2.1. 主な特徴

  • ダウンタイムの削減: システムの再起動が不要なため、業務の中断を避けることができます。
  • セキュリティ強化: セキュリティパッチを即座に適用することで、脅威からの保護を迅速に行えます。
  • パフォーマンスの維持: 再起動によるパフォーマンス低下を防ぎ、安定した運用を継続できます。

3. Windows Hot Patchの技術的課題

Hot Patchを適用する際にはいくつかの技術的課題があります。特に、実行中のファイルへのロックが挙げられます。

3.1. ファイルロックの重要性

Windowsはシステムの安定性を維持するために、実行中のファイルにロックをかけます。このロックにより、ファイルが予期しないタイミングで変更されることを防ぎ、システムの予測不可能な挙動を回避します。しかし、このロック機能があるため、Hot Patchの適用は技術的に難しいものとなります。

3.2. 実際のリスク: 事例紹介

実行中のデータを書き換えることがどれだけ危険であるかを示すために、過去に発生した事故を紹介します。

事例: 京都大学スーパーコンピュータ事故

実際に、京都大学のスーパーコンピュータでは、不注意により実行中のスクリプトが書き換えられた結果、77TBものデータが消失する事故が発生しました。このような事故は、システムの運用における細心の注意が必要であることを示しています。

3.3. プロセスリロードの必要性

単にファイルを書き換えるだけでは不十分であり、実行中のプロセスを適切にリロードする必要があります。これにより、変更が正しく反映され、システムの安定性とセキュリティが保たれます。

3.4. 技術的な克服

Hot Patch技術は、ファイルロックとプロセスリロードを考慮した上で、システムを再起動せずにパッチを適用する方法を提供します。これにより、ダウンタイムを最小限に抑えつつ、セキュリティ更新を迅速に行うことが可能です。

4. Windows Hot Patchの導入方法

Windows Hot Patchを導入する手順は以下の通りです。

4.1. 前提条件の確認

  • 対象のWindowsバージョンがHot Patchをサポートしていることを確認します。
  • 最新のWindows Updateを適用しておきます。

4.2. Hot Patchの適用

  1. Windows Updateの設定: Windows Updateの設定を開き、Hot Patchの適用を有効にします。
  2. 更新の確認: 最新のHot Patch更新を確認し、ダウンロードおよびインストールを行います。
  3. 適用の確認: Hot Patchが正しく適用されているか確認します。

5. 実際の活用事例

Hot Patchを利用することで、企業は以下のような効果を実感しています。

5.1. 事例1: 金融業界

金融業界では、システムの停止が許されないため、Hot Patchを導入することで24時間体制の運用を実現しています。

5.2. 事例2: 医療業界

医療機関では、患者データの保護とシステムの稼働時間が重要です。Hot Patchを活用することで、セキュリティと運用効率の両立が可能になりました。

6. まとめ

Windows Hot Patchは、システムの稼働時間を最大化し、セキュリティを強化するための有力なツールです。導入することで、業務の中断を最小限に抑え、安定した運用を維持することができます。

LLMの未来: スケーリング則の限界と効率化の新アプローチ

今、LLMは一つの岐路にあると思っている、現状の認識としてはスケーリング則に限界が見受けられること。スケーリング即とはモデルの大規模化によって、モデルの精度、アウトプットの品質が高まるという経験則を指す。しかし、スケーリング即に現状、限界が見えていて、モデルの大規模化が必ずしもアウトプットの深化に結び付かない例が観測されている。

AIの天井が見えてきた日:スケール則の限界と新時代の幕開け

最近の事例から、私は今後の有望な方向性として二つのアプローチを見出しています。

MoE (Mixture of Experts):比較的歴史の長い発想で、Gradient Boostingなどもその考え方と考えられます。複数のモデルを組み合わせ、それぞれに重み付けを行うことで高精度なモデルを構築する手法です。

BitNet:比較的新しい考え方で、ニューラルネットワークは発火しているか否かという状態を表すため、ビットレンジを極限まで圧縮できるはずという理論に基づきます。このアプローチでは、計算リソースの使用を大幅に削減することが可能です。

これまでは、モデルの大規模化競争が主流でしたが、これは妥当な方向性でしょうか。ビッグプレイヤーは結果的に原子力発電にまで進んでいますが、これがよい方向性だとは思えません。したがって、モデルの効率化が今後のゲームチェンジャーとなり得ると考えています。

暴言の坩堝と化したX:その背後にあるもの

イーロン・マスクが最近このようなことを言っています:

XユーザーのElon Muskさん: 「Please post a bit more positive, beautiful or informative content on this platform」 / Twitter

しかし、以下の発言も彼のものです:

XユーザーのElon Muskさん: 「𝕏 is the PvP of social media」 / Twitter

イーロン・マスクがTwitterを買収し、私物化してPvP(プレイヤー対プレイヤー)ソーシャルメディアに変えたのは周知の事実です。なぜこのようなことが起きたのでしょうか?

単純な理由があります。H-1Bビザを擁護したからです。アメリカのIT業界は、H-1Bビザで入国してくる海外の優秀な労働者に大きく依存しています。H-1Bビザがなくなると、業界にとっては死活問題となります。しかし、PvPソーシャルメディアとなった「𝕏」上で、イーロン・マスクのような経営者は多数派ではありません。そして、マスクが焚きつけた対立感情により、海外からの安価な労働者の流入を止めたいと考える人が増えています。

結果、「𝕏」は暴言の坩堝と化しました。しかし、その引き金を引いたのはイーロン・マスク本人であることを忘れてはなりません。

さらにウィットに富んだ良い返しを紹介します:

Xユーザーのdownshift.eth (on Warpcast)さん: 「@elonmusk Please write an algorithm that promotes more positive, beautiful or informative content on this platform」 / Twitter

日本では良い言葉がある。「人を呪わば穴二つ」

MoonBit: WebAssembly特化言語のGitHub公開

WebAssemblyに特化した言語「MoonBit」のコンパイラがGitHubで公開 - Publickey WebAssemblyに特化した言語が公開されたそうです。WebAssemblyとはasm.jsなどの流れの延長上に、実行可能コードをWebでホストできるものです。現時点でも、SQLiteをWeb上にホストしたりなどの実装が見受けられます。

現状では、WebAssemblyに特化した言語はかなり珍しいです。今のところ、WebAssembly使用の実例としてはTensorflow.jsやUnityなどの例になります。