現場で初めて「Teamsトランシーバー（Walkie Talkie）」を使ってみた話
昨夜の建物内LAN調査では、基幹ケーブルの行先を確認するため、作業者同士が離れて作業する場面がありました。
こういう時に毎回困るのが“連携のタイミング”。
そこで、以前から気になっていた Microsoft Teams の「Walkie Talkie（トランシーバー）」機能を、現場で初めて本格的に使ってみました。
一般的なトランシーバーの弱点をクラウドで補える期待感
通常のトランシーバーは
電波の届く範囲に制限がある
建物の構造に影響される
といった弱点があります。
一方、Teamsのトランシーバーは インターネット経由。
つまり、理屈の上では どこにいても交信できる のが魅力です。
イベント現場や店舗の作業時にも使えないかと、ずっと模索していました。
専用のBluetoothイヤホンマイクも導入
スマホを片手に作業しながらPTT（Push to Talk）ボタンを押すのは現実的ではないので、
トランシーバー対応のPTTスイッチ付きBluetoothイヤホンマイクも用意しました。
これで、“ほぼインカム”として運用できます。
事前テストで気づいた「約1秒の遅延」
使ってみると、どうしても 1秒弱の遅延 が発生します。
この時点で、
「せーの」のタイミング合わせ
ステージ現場での瞬間的なキュー出し
といった用途には不向きだと感じました。
ただ、今回の建物内LAN調査のように“遠隔で声が届けばいい場面”なら問題ないだろうと判断し、本番導入してみました。
実際に使ってみると…iPhoneでは不安定な場面が多かった
今回の作業者2名の環境は 両方ともiPhone。
ここで想定外の挙動が連発しました。
① アプリがバックグラウンドだと送信が届かない
Teamsのドキュメントでは「バックグラウンドでも動作する」とありますが、
実際には
・届く時と届かない時が混在
という状態。
② PTTが押せても、相手側には音声が届かない現象
こちらでは「送信中」と表示されているのに、
相手には全く届いていないケースが何度も発生しました。
なぜiPhoneだとこういう不安定さが起こりやすいのか？
これは“現象として”非常に理にかなっています。
理由を簡潔にまとめると──
iOSは「バックグラウンド動作に極端に厳しい」OS
iPhoneは
バッテリー保護
セキュリティ
アプリの強制スリープ
音声入出力の奪い合い制御
が強めに働くOSです。
PTTのような
「常時待受＋瞬間送信」
という仕組みは、iOSと相性が悪い場面がどうしても出てきます。
Bluetoothマイクの“音声権限”が積極的に奪われるiOS仕様
iPhoneは外部マイク・PTTスイッチを、
アプリやOS側の割込みで頻繁に一時解放することがあります。
アプリは“押されている認識”でも、
音声の入力権限が戻っていないことが起こり得ます。
Teams トランシーバー自体がAndroid向け最適化が主軸
Microsoftの資料でも、
Zebra端末
Samsung Knox
業務用Android端末
が主用途で、iOSは「対応はしているがメインではない」という立場です。
次回はAndroid端末でも同じ検証をしてみる予定
今回の不安定さは環境依存が強く、
特に iOS（iPhone）のバックグラウンド処理が原因として十分あり得る と感じました。
次回の現場では Android でも試し、
動作の比較をしてみる予定です。
他にも選択肢があるので今後検証する
トランシーバー機能を持つアプリは他にもあります。
LINEWORKS ラジャー
BuddyComm
Zello（海外で人気）
イベントや現場仕事では選択肢を広く持っておくことが大事なので、
これらも検証していきます。
結論：クラウドPTTは“現場の新しい選択肢”になり得る
実運用ではまだ癖があるものの、
従来のトランシーバーの距離制限を超えられるのは大きなメリットです。
現場ITの視点で見ると、
「クラウドトランシーバーは今後もっと普及する」
そんな予感がした現場でした。