JavaScript | Web API：位置情報・センサー － センサー利用の注意点

JavaScript JavaScript
スポンサーリンク

センサー利用の「注意点」は“技術”と“人間”の両方を見ること

位置情報・DeviceOrientation・DeviceMotion・カメラ・マイク…。
どれも「現実世界のあなた」を Web に持ち込むための強い機能です。

だからこそ、
「どうやって使うか」より先に「どう気をつけるか」 を考える必要があります。

ここでは、プログラミング初心者のうちに絶対押さえておいてほしい
センサー利用の注意点を、具体例と一緒に整理していきます。

プライバシーと権限の扱い方

いきなり使わない。「なぜ必要か」を先に伝える

センサーはどれも、ユーザーからすると「ちょっと怖い」領域です。

位置情報を勝手に取られていないか
カメラが勝手に起動していないか
動きが勝手に監視されていないか

なので、コード的には呼べても、
「いきなり呼ばない」 のが大前提です。

悪い例（いきなり位置情報を取りに行く）:

// ページ読み込み直後にいきなり呼ぶのは NG 寄り
navigator.geolocation.getCurrentPosition(success, error);
JavaScript

良い例（説明してから、ボタンを押したら呼ぶ）:

<p>現在地を使って近くのお店を表示します。</p>
<button id="useLocationBtn">現在地を使う</button>
<p id="message"></p>

const btn = document.querySelector("#useLocationBtn");
const message = document.querySelector("#message");

btn.addEventListener("click", () => {
  message.textContent = "ブラウザのダイアログで「許可」を選ぶと、現在地を使えます。";

  navigator.geolocation.getCurrentPosition(
    (pos) => {
      message.textContent = "現在地を取得しました。";
    },
    (err) => {
      message.textContent = "位置情報を利用できませんでした。";
    }
  );
});
JavaScript

「なぜ必要か」を先に言う
「あなたの操作で始まる」ようにする

この 2 つだけで、ユーザーの安心感はかなり変わります。

拒否されるのは“普通”として扱う

センサー系は、拒否されるのが当たり前です。

位置情報を拒否
カメラを拒否
モーションアクセスを拒否

これを「エラー」ではなく
「ユーザーの正当な選択」 として扱うのが大事です。

位置情報の例:

navigator.geolocation.getCurrentPosition(
  (pos) => {
    // 通常処理
  },
  (error) => {
    if (error.code === error.PERMISSION_DENIED) {
      message.textContent =
        "位置情報の利用が拒否されました。手入力で場所を選択できます。";
      // ここで「駅名を入力」「地名を選ぶ」などの代替 UI を出す
    } else {
      message.textContent = "位置情報を取得できませんでした。";
    }
  }
);
JavaScript

「拒否されたら何もできない」ではなく、
「拒否されたときのルートもちゃんと用意する」 のがプロの設計です。

バッテリー・パフォーマンスへの配慮

取りっぱなしにしない。開始と停止をセットで考える

位置情報の watchPosition、
DeviceMotion / DeviceOrientation のイベント監視などは、
「ずっと動き続ける処理」 です。

開始したら、どこかで必ず止める必要があります。

悪い例（開始だけして止めない）:

window.addEventListener("devicemotion", handleMotion);
// ページを閉じるまでずっと動き続ける
JavaScript

良い例（開始と停止をセットで用意）:

<button id="startBtn">センサー開始</button>
<button id="stopBtn" disabled>センサー停止</button>
<p id="info"></p>

const startBtn = document.querySelector("#startBtn");
const stopBtn = document.querySelector("#stopBtn");
const info = document.querySelector("#info");

function handleMotion(event) {
  info.textContent = "センサーから値を受信中…";
}

startBtn.addEventListener("click", () => {
  window.addEventListener("devicemotion", handleMotion);
  startBtn.disabled = true;
  stopBtn.disabled = false;
});

stopBtn.addEventListener("click", () => {
  window.removeEventListener("devicemotion", handleMotion);
  startBtn.disabled = false;
  stopBtn.disabled = true;
});
JavaScript

「いつ始めて、いつ止めるか」を
UI とセットで設計する のがポイントです。

更新頻度を意識する（全部に反応しない）

センサーイベントは、かなり高頻度で飛んできます。

毎秒 30 回〜60 回以上
端末によってはもっと

そのたびに重い処理や DOM 更新をすると、
すぐにカクカクしたり、バッテリーを食いまくります。

簡単な対策として「間引き」があります。

let lastTime = 0;

function handleMotion(event) {
  const now = Date.now();
  if (now - lastTime < 100) {
    // 100ms 以内なら無視（10fps くらいに間引く）
    return;
  }
  lastTime = now;

  // ここに実際の処理を書く
}
JavaScript

「全部に反応する」のではなく、
「どれくらいの頻度なら十分か」を決めて間引く。
これだけで体感がかなり変わります。

精度・ノイズ・端末差を前提にする

センサー値は“揺れるし、外れる”のが普通

位置情報の accuracy
DeviceMotion の加速度
DeviceOrientation の角度

どれも「ピタッと正確」ではなく、
常に少し揺れたり、たまに大きく外れたりします。

だからこそ、
「生の値をそのまま信じない」 のが大事です。

例: 「振った」判定をするときの工夫

const threshold = 20;      // これ以上なら「振った」
const cooldown = 1000;     // 1 秒に 1 回まで
let lastShakeTime = 0;

function handleMotion(event) {
  const acc = event.accelerationIncludingGravity;
  if (!acc) return;

  const x = acc.x || 0;
  const y = acc.y || 0;
  const z = acc.z || 0;
  const magnitude = Math.sqrt(x * x + y * y + z * z);

  const now = Date.now();
  if (magnitude > threshold && now - lastShakeTime > cooldown) {
    lastShakeTime = now;
    // ここで「振った」として何かする
  }
}
JavaScript

小さな揺れは無視する
連続で反応しないようにクールタイムを入れる

こういう「フィルタ」を挟むのが、センサー利用の基本です。

端末やブラウザによって挙動が違う前提で

PC ではセンサーがそもそもない
Android と iOS で値の範囲や向きが微妙に違う
古いブラウザでは API 自体が存在しない

こういうことは普通に起こります。

なので、必ず存在チェックを入れます。

if (!("geolocation" in navigator)) {
  message.textContent = "このブラウザは位置情報に対応していません。";
} else {
  // 位置情報を使う処理
}
JavaScript
if (typeof DeviceMotionEvent === "undefined") {
  info.textContent = "この端末では加速度センサーは利用できません。";
}
JavaScript

「あれば使う、なければ別ルート」
この考え方が、センサー系では特に重要です。

HTTPS と「安全なコンテキスト」

センサー系は基本的に HTTPS 前提

位置情報
カメラ・マイク
一部のセンサー

これらは、
「安全なコンテキスト（secure context）」 でしか動きません。

つまり、基本的に

https:// で配信されているページ
http://localhost（開発用の特例）

のどちらかでないと、
API が使えなかったり、権限ダイアログが出なかったりします。

「コードは合っているのに動かない」とき、
まず HTTPS を疑う癖 をつけておくと、原因特定が早くなります。

UX としての「センサー利用」を設計する

センサーがなくても“詰まない”ようにする

理想はこうです。

センサーが使える
→ 便利でリッチな体験を提供

センサーが使えない・拒否された
→ それでも最低限は使える

例えば、位置情報なら:

使えるとき
→ 現在地から近くの店舗を自動表示

使えないとき
→ 駅名や住所を手入力してもらう UI を出す

というふうに、
「センサーはあくまでプラスアルファ」 として扱うと、
アプリが強くなります。

「怖くない説明」を一言添える

最後に、すごくシンプルだけど効くやつ。

「現在地を使って近くのお店を表示します」
「端末の傾きでキャラクターを動かします」
「端末を振るとサイコロを振ります」

こういう一言があるだけで、
ユーザーは「何をされるのか」を理解できます。

逆に、何も説明がないまま
「位置情報を許可しますか？」
「モーションと方向へのアクセスを許可しますか？」

とだけ出ると、
かなり不安になります。

センサー利用は、
技術 50％・説明 50％ くらいの気持ちでちょうどいいです。

初心者として「センサー利用の注意点」で掴んでほしいこと

ざっくりまとめると、こうです。

センサーは強力だからこそ、「勝手に使わない」「ちゃんと説明する」。
拒否・非対応・ノイズ・端末差は“普通に起こるもの”として設計する。
開始と停止、頻度制御、フィルタリングで「バッテリーと体感」を守る。
HTTPS と権限ダイアログは、センサー利用の前提条件として意識する。

センサーを触るときは、
「コードが動くか」だけじゃなくて「人からどう見えるか」 を一緒に考えてみてください。

その視点を持てるエンジニアは、
位置情報・カメラ・マイク・モーション…どの世界に行っても、ちゃんと強いです。

スポンサーリンク
タイトルとURLをコピーしました