TP-Link Tapoデバイスのファームウェア更新とサードパーティ連携の課題
TP-LinkのスマートホームデバイスTapoシリーズは、これまで数回にわたり、サードパーティのローカルクライアントからのアクセスを制限するファームウェアアップデートを実施してきました。特に注目されるのは、2025年10月にTapoプラグで導入されたTPAPプロトコルへの移行です。この変更により、ファームウェアバージョン1.4.0以降のデバイスは、アプリ内の「Third-Party Compatibility」スイッチをオンにしない限り、旧来の方法でのサードパーティ連携を拒否するようになりました（Hacker News (API)）。
2025年10月、ファームウェア1.4.0によりTPAPプロトコルが導入され、Tapoプラグのサードパーティ連携がデフォルトで制限されました。
TP-Linkは、このスイッチをオフにすることで「セキュリティを確保できる」と主張していますが、実質的には古いプロトコルを有効にすることでセキュリティが低下する可能性も指摘されています。多くのユーザーがこの変更に戸惑い、非公式フォーラムでは、TP-Linkからの明確な説明がないまま、数多くの連携問題が報告されていました。
繰り返されるプロトコル変更とセキュリティ強化の背景
過去3年間で、Tapoデバイスのプロトコル変更は今回が3度目です。2023年2月には、L530E電球の脆弱性報告を受け、既存のAESプロトコルからKLAPプロトコルへ移行しました。そして2024年4月には、カメラデバイス向けにローカルログインを無効化するアップデートが行われ、後に「Third-Party Compatibility」スイッチが導入されました（Hacker News (API)）。
これらの変更の背景には、デバイスのセキュリティ強化があると考えられます。しかし、公式からの十分なアナウンスがないままプロトコルが変更され、サードパーティ連携が突如として機能しなくなる状況は、開発者やユーザーにとって大きなフラストレーションとなっていました。TP-LinkのFAQでは、同社の製品がHome Assistantのようなプラットフォームを公式にサポートしていないことが明記されており、これが開発者コミュニティとの間の溝を深める一因となっているのではないでしょうか。
非公式ライブラリ「tapo」のTPAP対応：セキュリティと利便性の両立へ
このような状況の中、非公式のRustおよびPythonクライアントライブラリ「tapo」のv0.11.1が、新たにTPAPプロトコルに対応したと発表されました。この対応により、Tapoアプリの「Third-Party Compatibility」スイッチをオフにしたままでも、Tapoデバイス（プラグ、ライト、電源タップ、H100ハブ）をローカルで制御できるようになります（Hacker News (API)）。
| プロトコル名 | 対象デバイス | Third-Party Compatibilityスイッチ | 備考 |
|---|---|---|---|
| AES | 一部の旧デバイス | N/A | 最古のプロトコル |
| KLAP | ライト、プラグ、電源タップ、H100ハブ | オン | 旧来のプロトコル、一部のカメラにも存在 |
| TPAP | ライト、プラグ、電源タップ、H100ハブ | オフ | 最新のプロトコル、セキュリティ強化 |
このライブラリは、RustクレートをPythonパッケージがラップする形で提供されており、両言語で同じ機能が同時に利用可能です。TPAPプロトコルへの対応は、約4ヶ月にわたる開発の成果であり、2025年9月28日のv0.10.0リリースから始まり、10月4日のv0.11.1で完成しました（Hacker News (API)）。これにより、ユーザーはTP-Linkが推奨するセキュリティレベルを維持しつつ、ローカルでのカスタマイズされた制御が可能になります。
エンジニア目線で見ると：中国系デバイスにおける標準化と選択の重要性
今回のTPAPプロトコルへの非公式対応は、TP-Linkのような中国系スマートデバイスメーカーが採用するクローズドなエコシステムに対する、開発者コミュニティからの重要なカウンターアクションだと感じます。多くのメーカーが、セキュリティや機能追加を名目に、サードパーティ連携を制限する方向に進みがちです。しかし、これによりユーザーの選択肢が狭まり、オープンな開発エコシステムが阻害されることは避けるべきです。
私自身の開発経験からしても、特定ベンダーにロックインされるリスクは常に意識しています。特に個人プロダクトやスタートアップでインフラを選ぶ際、GCPのBigQueryやCloud Runを利用するのも、オープンスタンダードに近い形でデータやサービスを扱える点が魅力だからです。
今回のケースでは、非公式ライブラリがプロトコルをリバースエンジニアリングすることで、ユーザーに「セキュリティを損なわずにローカル制御を維持する」という選択肢を提供した点は非常に評価できます。これは、開発者にとって、ベンダーの都合に左右されずに自分たちのシステムを構築できる可能性を示すものではないでしょうか。
ただし、非公式の対応である以上、将来的にTP-Linkがプロトコルをさらに変更したり、この種の利用を技術的にさらに困難にしたりする可能性も否定できません。その意味で、このようなライブラリに完全に依存するのではなく、柔軟なアーキテクチャ設計と、代替手段への迅速な切り替え準備が、常に重要だと考えます。クラウドサービスを利用する場合でも、マルチクラウド戦略やTerraformのようなIaCツールを活用して、特定のプロバイダへのロックインを避ける努力が求められます。
また、中国系メーカーに対するセキュリティ面での懸念は、米国の一部州がTP-Linkを提訴している事例（The Register）からも伺えます。オープンソースやコミュニティ主導のプロジェクトが、この種の課題に対する有効な解決策を提供し続けることを期待しています。
