マイコンによるBLE／Bluetooth開発事例5選｜電子錠から屋外IoTまで

はじめに：BLE機器の設計判断は、実例から学ぶのが早い

サーリューションがこれまで手がけてきたBLE／Bluetoothを搭載した機器の開発は、スマートロックからヘルスケア計測デバイス、非接触温度計測、非接触充電、屋外IoTまで、幅広い領域にわたります。

BLE（Bluetooth Low Energy）は、ボタン電池1個で数か月〜年単位の駆動を可能にし、iPhone・Androidの双方に標準実装されているため、IoT機器・ウェアラブル・産業センサのスマホ連携手段として広く採用される標準的な選択肢となっています。ひと昔前は「BLEモジュール＋ホストマイコン」の2チップ構成が一般的でしたが、近年はBLE内蔵マイコン1チップで小型・省電力・低コストを同時に成立させる設計が主流になっています。

ただし、つなげるだけなら簡単でも、製品化となると「省電力」「他タスクとの共存」「OTA」「セキュリティ」と、踏むべき判断ポイントが一気に増えます。

本記事では、サーリューションのBLE／Bluetooth開発事例から代表的な5件を取り上げ、実際にどんな設計判断をしているのかを共有します。

---

BLE／Bluetoothの基礎

本題に入る前に、BLE開発で最低限押さえておきたいポイントを整理します。

Bluetooth Classic と BLE の違い

• Bluetooth Classic（BR/EDR）：オーディオ転送やファイル転送など、連続した大容量データ向け
• BLE（Low Energy）：センサ値・状態通知など、小さなデータを省電力でやりとりする用途向け

IoT機器・ウェアラブル・産業センサの多くは、後者のBLEを選択します。

ペリフェラルとセントラル

• ペリフェラル（Peripheral）：末端のデバイス側（センサ、ロック、ウェアラブル）
• セントラル（Central）：スマートフォンやPCなどの親機側

マイコン側で実装するのは基本的にペリフェラルです。GATT（Generic Attribute Profile）と呼ばれる仕組みで、サービスとキャラクタリスティックを定義し、スマホアプリが読み書きします。

通信距離と消費電流の目安

• 通信距離：数m〜数十m（見通し）
• 消費電流：アドバタイズ時で数百μA、スリープ時で数μA〜
• ボタン電池（CR2032）で数か月〜数年の駆動が可能（消費電力設計による）

---

BLE対応マイコンの主要選択肢

BLE内蔵マイコンには複数の選択肢がありますが、用途ごとに得意領域が異なります。サーリューションのマイコン開発・ファームウェア設計では、案件特性に応じて以下のラインナップを使い分けています。

BLE単体機器ではNordic nRF52を中心に、Wi-Fi併用が必要な製品ではESP32、産業用途で長期供給が要件となる案件ではSilicon Labsと、案件特性に合わせて最適なチップを選定します。

---

開発事例5選

事例1｜電子錠（スマートロック）

• 使用マイコン：Nordic nRF51822
• 要素技術：BLE、NFC、モータ制御、ボタン、ブザー

スマートフォンのアプリからBLEで解錠・施錠を指示し、マイコンがモータを駆動してロック機構を動かします。BLEが使えない場面に備えてNFCカードによるバックアップ認証も実装し、ひとつのマイコンで「無線通信」「近接通信」「モータ駆動」「ユーザーフィードバック（ブザー・LED）」を同時に処理する構成です。

BLEスタックは内部で割り込みとタイマーを多用するため、モータ制御タスクとの競合が設計ポイントになります。本件ではRTOSを使わず、ステートマシンとタイマー割り込みを中心に組み、BLEイベントを優先させつつモータ駆動のPWMを途切れさせない設計としました。

スマートロック、ロッカー、無人受付ボックスなど、認証＋物理アクチュエータを持つ製品における典型的なアーキテクチャとして応用が利きます。

---

事例2｜小型ヘルスケア計測デバイス｜低消費電力×加速度センシング×BLE送信

• 使用マイコン：Nordic nRF51822
• 要素技術：加速度センサ、AD変換、BLE、LED、ボタン

身につけて使う小型デバイスで加速度データを計測し、スマートフォンへBLEで送信するヘルスケア機器です。

この種のデバイスで最重要となるのがバッテリー駆動時間です。加速度センサは計測タイミング以外はスリープさせ、BLEのアドバタイズ間隔も必要最低限まで絞り、マイコン自体も計測待ちでDeep Sleepに入れる——こうした省電力設計の積み重ねが、ボタン電池1個で数か月もたせるか、数日〜数週間でダウンするかを分けます——実装品質に大きく左右されます。

スマホアプリ側で波形解析や統計処理を行い、機器側は計測と送信に専念させる「軽いエッジ・重いアプリ」の役割分担も、BLE機器の典型的な設計パターンです。

---

事例3｜サーモパイルBLE｜赤外線アレイ温度を無線で飛ばす

• 使用マイコン：Nordic nRF51822
• 要素技術：赤外線アレイセンサ、BLE

非接触で温度分布を取得する赤外線アレイセンサと、そのデータをBLEで送出する構成です。人流計測・環境モニタ・機器温度監視などに展開できる構成として設計しました。

温度アレイは複数画素（例：8×8、16×16）の温度値を一度に持つため、1フレームあたりのデータ量がBLEの1パケット容量（標準でわずか数十バイト）を超えることがあります。本件では、フレームを分割して複数パケットに載せる、サンプリングレートを用途に応じて落とす、前フレームとの差分だけを送る——といった工夫で、BLEの限られた帯域で熱画像を飛ばす設計を実現しています。

---

事例4｜自転車非接触充電｜BLE通信基板とメイン制御基板の分業アーキテクチャ

• 使用マイコン：本体側 Renesas RL78/G13／BLE通信側 Nordic nRF52832
• 要素技術：充放電制御、BLE、基板間シリアル通信、LED、温度センサ、受光センサ

本事例は、1つの製品のなかでマイコンを2つに分けた例です。

• 本体マイコン（RL78/G13）：充放電制御・センサ監視・安全ロジック
• BLE通信マイコン（nRF52832）：スマートフォンとのBLE通信・ユーザー向け情報表示

なぜ分けるのか。ひとつは責務の分離です。充放電の安全系を司るマイコンに、BLEスタックの不具合や通信待機による処理遅延を持ち込みたくありません。もうひとつは開発・認証の独立性です。BLE部分だけを別マイコン化することで、無線認証（技適等）の取り直しリスクを局所化でき、本体側ファームウェアの変更が無線認証に波及しません。

2基板はシリアル通信で連携し、状態通知や操作指令をやりとりします。プロトコルは独自定義で、応答／タイムアウト／再送までを含めて軽量に設計しました。

「制御は制御マイコン、通信はBLEマイコン」という分業パターンは、安全系・認証系が絡む製品で非常に有効です。

---

事例5｜水位計｜BLE／Sigfox／LTEを組み合わせた屋外IoT

• 使用マイコン：Nordic nRF52832
• 要素技術：AD変換、角加速度センサ、BLE、Sigfox、LTE

屋外に設置される水位計で、3種類の無線を使い分けている事例です。

• BLE：保守員が現地に行ったときに、スマートフォンから設定変更・データ吸い上げ
• Sigfox：低頻度・超低消費電力での常時データ通報（水位アラートなど）
• LTE：大容量データの送信が必要な場面（詳細ログや画像など）

屋外設置機器は電源制約が厳しく、電池駆動とソーラー発電の併用も含めて電源設計を行いました。角加速度センサは、設置物の傾き監視と異常検知に使い、水位計算の信頼性を高める補助データとして機能します。

「近接＝BLE／広域低速＝Sigfox／広域高速＝LTE」という無線のハイブリッド設計は、屋外IoT全般で再利用可能なパターンです。

---

BLE開発でつまずきやすい3つのポイント

BLEは「つなげるだけなら簡単、製品化すると沼」と言われる領域です。サーリューションが特に注意して設計しているポイントを3つに絞って共有します。

1. 低消費電力設計

• アドバタイズ間隔：短すぎると電池が減り、長すぎると接続までの待ち時間が伸びる。製品用途ごとに最適点を探る
• 接続間隔：スマホOS側の制約があり、こちらが望むほど短くできないケースがある
• マイコンのSleepモード：Deep Sleep対応、RAM保持、起床要因の設計が肝
• ペアリング方式（パスキー／Just Works／OOB）も電源設計と無関係ではなく、ディスプレイの有無等のUI制約と合わせて初期に決め切る

2. BLEスタックと他タスクの共存

• BLEスタックは内部で割り込み・タイマーを常時使っている
• モータ制御や液晶描画のリアルタイム処理と優先度がぶつかると、接続断や描画ちらつきにつながる
• Nordic SDK（SoftDevice）がシステムの割り込み優先度を一部占有するため、共存設計は実装上の制約として最初に考慮する

3. OTA（Over-The-Air）ファームウェアアップデート

• 出荷後のバグ修正・機能追加に不可欠
• ただし、ブートローダー領域の確保、署名検証、電池切れ・通信断時のロールバック対策など、実装コストは軽くない
• 本当に必要な製品か、出荷前検証で詰め切れるかを最初に判断する

---

マイコン選定の考え方

BLEマイコンの選定は、上から順に絞り込む形で進めると判断がブレません。

① 電源条件
     ├─ 電池駆動／長寿命優先  → Nordic nRF52
     └─ 外部電源あり          → 次の条件へ

② 無線条件
     ├─ BLE単独で十分          → Nordic nRF52
     ├─ BLE＋Wi-Fi が必要      → ESP32
     └─ BLE＋広域無線（LTE等） → Nordic nRF52 ＋ 別IC構成

③ 認証・供給条件
     ├─ 産業用途／長期供給／既認証モジュール優先 → Silicon Labs
     └─ 民生／短中期            → 上記に従う

④ 既存資産
     └─ 既存ファーム流用が大きい場合は資産側を優先

加えて、出荷数量・開発期間・SDKの成熟度もチップ選定の重要な要素です。Nordicはドキュメント・サンプル・OTAの完成度が高く、サーリューションの実装事例数も最多です。「BLE単体・電池駆動・小型ならまずnRF52から検討する」——これがサーリューションの現時点の基本姿勢です。

---

まとめ

BLE／Bluetoothを搭載したマイコン製品の開発は、

1. BLE対応マイコンの選定（Nordic／ESP32／Silicon Labs）
2. 省電力設計（アドバタイズ・接続・スリープの最適化）
3. スマホアプリとの役割分担（機器は軽く、アプリは賢く）

の3点セットで成否が決まります。

サーリューションのマイコン開発サービスでは、Nordic nRF51／nRF52を中心に、ESP32 や Silicon Labs も用途に応じて使い分けながら、スマートロック・ヘルスケア・非接触計測・非接触充電・屋外IoTなど、多様なBLE機器の開発実績を積み重ねてきました。BLE／Bluetooth搭載案件は、サーリューションが実績を積み重ねてきた技術カテゴリのひとつです。

「BLE／Bluetoothを搭載したIoT製品を新規開発したい」「既存製品のBLE化を検討している」「BLEスタックと他タスクの共存で詰まっている」——そういったマイコン開発・ファームウェア設計の課題について、まずは技術相談から、お気軽にご相談ください。

マイコン開発・ファームウェア設計のサービス詳細はこちら