AIと一緒にWi-Fiサーベイ支援ツールを作ってみた話

1. きっかけ：手書き記録の限界

Wi-Fi調査の仕事では、現場で複数のアクセスポイントの情報を記録する必要があります。SSID、BSSID、RSSI（電波強度）、チャンネル番号、暗号化方式。これを一つひとつ手で書き留めるのが、長年の流儀でした。

でも現場に立ってスマートフォンのアプリをメモ代わりにしながら、ノートに転記して、帰社後に入力し直す——この手順がどうにも無駄に見えてきました。電波状況は変わりやすいし、記録ミスも起きる。何より、複数台のAPが並んでいる環境では、一覧で俯瞰できる方が絶対に判断しやすい。

「Windowsのコマンドで電波情報を取れるはずだ」というところから調べ始めて、lswifiというPythonのライブラリにたどり着きました。GUIもNotionへの保存も、最初は考えていなかったのですが、作っていくうちに必要な機能がどんどん見えてきました。

2. 具体的にやったこと（ツール構成とGUI）

技術構成はこうです。Python 3.9以上、tkinterでGUI、lswifi 0.1.66でWi-Fi情報取得、requestsとpython-dotenvでNotion API連携、speedtest-cliで速度測定。動作環境はWindows 10/11です。

GUIはtkinterで作りました。ボタンを押すとlswifiでスキャンが走り、検出されたアクセスポイントの一覧がテーブル形式で表示されます。SSID、BSSID、RSSI（dBm）、チャンネル、暗号化方式が並ぶ構成です。

実際に使ってみて気づいたのは、現在接続中のAPが一覧の中でどれなのかすぐわかるようにしたい、ということでした。そこで「現在のSSIDとBSSIDを取得して、一致する行をハイライトする」機能を追加しました。BSSID完全一致なら濃い緑、SSID一致（別のAPに繋がっている状態など）なら薄い緑にしています。

3. 具体的にやったこと（Notion連携と速度測定）

調査結果をその場でNotionに保存できたら、報告書作成の手間がかなり減る——そう考えてNotion APIを組み込みました。スキャン結果を、指定した親ページの配下に子ページとして自動作成するようにしています。APIキーと保存先ページIDは.envファイルで管理し、コード内にはハードコードしない設計です。

速度測定はspeedtest-cliを使いました。ボタン一つで計測が走り、下り・上り速度がGUI上に表示されます。そのままNotionの保存データにも含めることができます。

CSVへのエクスポート機能も入れました。Notionを使っていない現場でも持ち出せるように、スキャン結果を任意のタイミングでCSVに書き出せます。

4. つまずいたこと（lswifiのJSONキー問題）

最初につまずいたのは、lswifiが返すJSONの構造でした。チャンネル番号を取得しようとしたところ、想定していたキー名で値が取れず、チャンネルが全部0になる問題が起きました。

lswifiのドキュメントを読んで実際のJSONを出力してみると、キー名が想定と違っていたのが原因でした。実際のJSONに合わせて、channel_number、channel_width、channel_frequency、modes、securityを正規化することで解決しました。「ドキュメントを読むより、実際に出力して中身を見た方が早い」という教訓です。

もう一つ手間取ったのが、Notion APIの401エラーです。最初はAPIキーの設定ミスかと思い、.envの書き方を何度も確認しました。それでも直らないので、APIキーが正しく読み込まれているか、Notionのページにインテグレーションが共有されているか、を切り分ける簡単な診断スクリプトを作りました。原因はページへのインテグレーション共有が漏れていたことでした。エラーメッセージだけ見ていたら気づけなかった。

5. 速度測定の落とし穴と使える形になるまで

速度測定機能を試していたとき、Wi-Fi環境で測っているはずなのに、なぜか有線LANと同じような値が出ることがありました。調べてみると、テストPCが有線LANにも接続していて、speedtest-cliがそちらのインターフェースを使っていたのが原因でした。

「Wi-Fiの速度を測る」つもりで動かしていても、有線が繋がっていればそちらで計測されてしまう。これはツールの問題というより、測定環境の問題です。今は「速度測定前に有線を抜くか、測定インターフェースを意識する」という注意書きをGUIに入れています。自動では判断できないことは、使う人間が意識するしかない。

一通りの機能が揃った時点でMVPと判断しました。Wi-Fi電波状況のスキャン、現在接続APのハイライト、速度測定、Notionへの自動保存、CSV出力——これだけあれば現場で実際に使えます。完璧ではないですが、「使えるもの」として動く状態になったことの方が重要でした。

6. 今感じていること・学び

このツールを作ってみて改めて思ったのは、「現場で感じていた不便さ」が開発の一番の動力になる、ということです。Wi-Fi調査で手書きをしていた自分にとって、何が不要で何が欲しいかは最初からわかっていた。だから迷いなく機能を絞れました。

AIはコードの書き方を教えてくれますが、「何を作るか」は自分で決めるしかない。今回も、lswifiをどう使うか、Notionをどう組み込むか、どの機能をMVPに含めるか——判断はすべて自分でしています。AIは「どう書くか」の相談相手で、「何を作るか」の答えは現場経験の中にある。

lswifiのJSONキーの問題、Notion APIの401エラー、speedtest-cliの落とし穴。どれも「やってみて初めて気づいた」問題です。ドキュメントを読んでいても、実際に動かしてみないとわからないことがある。それはAIを使う作業でも、現場の工事でも、変わりません。

7. 次に向けて

現時点では、スキャン→記録→保存という基本的な流れができています。次はフロア図や地図との連携を考えています。「この位置でこの電波強度だった」という情報を空間的に記録できれば、Wi-Fi設計の提案資料として使えるようになる。

また、今回はWindows専用ですが、現場によってはMacやLinuxを使う人もいる。そこへの対応も視野に入れています。ツールとしての完成度よりも、実際に現場で使えるかどうかを優先しながら、少しずつ育てていく予定です。次回は、このツールを実際の調査現場で使ってみた結果を報告できればと思います。