Bluetoothモジュールを設計に統合する際、最初に直面する根本的な決断の一つが、ホストコントローラインターフェース（HCI）、ATコマンド、またはSoC統合という三つのアーキテクチャパターンの選択です。この決断は単なる技術的な好みの問題ではなく、開発速度、機能柔軟性、認証コスト、量産スケーラビリティに直接影響します。本稿では、三つのアーキテクチャを実際のパラメータで比較し、各アプローチが有利になるシナリオを明確にします。
三つのアーキテクチャパターンの概要
HCIアーキテクチャ：ホストプロセッサがHCIコマンドをコントローラに送信し、コントローラはイベントとACLデータを返す。ホストはBLE Host Stack（GAP/GATT/SMP/L2CAP）を実行し、コントローラはLink Layer以下を担当する。代表例：Nordic nRF52840のUSB HCIファームウェア、Cypress CYW43012。
ATコマンドアーキテクチャ：モジュール内部でフルスタックを実行し、ホストはUART経由でASCIIコマンド文字列を送信するだけ。ホスト側はBLE知識不要。代表例：HC-42、HM-10、Microchip RN4870。接続帯域幅：115200 baud = 最大11.5 KB/s実効スループット。
SoC統合：アプリケーションコードとBLEスタックが同一チップで動作。外部ホストMCU不要。代表例：nRF52833（512KB Flash/128KB RAM）、ESP32-C3、Silicon Labs EFR32BG22。
主要プロトコルスタックの比較
| スタック | ライセンス | 対応チップ | 最小Flash/RAM | 特徴 |
|---|---|---|---|---|
| Zephyr BLE | Apache 2.0（無料） | Nordic、ST、NXP他 | ~256KB/~64KB | マルチプロトコル、活発なコミュニティ |
| NimBLE | Apache 2.0（無料） | ESP32、Nordic、他 | ~100KB/~32KB | 軽量、ESP-IDFネイティブ |
| SoftDevice | Nordic独自（無料使用可） | nRF52シリーズのみ | ~148KB/~8KB | 認定済み、Nordic公式サポート |
| BGAPI | Silicon Labs独自 | EFR32BGシリーズ | ~200KB/~32KB | ATコマンド互換、NCP/SoCモード両対応 |
HCIアーキテクチャの詳細分析
HCIは最大の柔軟性を提供しますが、ホスト側の実装コストも最も高い。UART HCIの場合、H4フレーミング（1バイトパケットタイプインジケータ）を使用し、最大ボーレートは通常1Mbps。USB HCIはisochronousエンドポイントを使用してBluetooth 5.2 LE Audioをサポート。
ホストスタック選択の実例：Linuxシステムでは標準BlueZを使用可能。組み込みRTOS環境ではZephyr HCI driverまたはNimBLE HCIホストを選択。Zephyrのhci_uartサンプルは約180KBのコントローラファームウェアを生成し、ホスト側にさらに~256KBが必要。
ATコマンドの実装詳細
ATコマンドモジュールは開発速度を最大化しますが、スループットと遅延に制約があります。代表的なコマンドシーケンス：
AT+RESET // モジュールリセット
AT+ROLE=1 // ペリフェラルモード設定
AT+NAME=MyDevice // デバイス名設定
AT+UUID=FFE0 // サービスUUID設定
AT+CHAR=FFE1 // キャラクタリスティックUUID設定
AT+NOTI=1 // 通知有効化
AT+ADVEN=1 // アドバタイズ開始遅延特性：ATコマンド処理時間 = コマンド解析（~1ms）+ スタック処理（~5-50ms）+ UARTエコー時間。接続イベントの遅延は通常50-200ms、HCIの直接操作（~10-30ms）と比べて高い。大量データ転送が必要な用途には不向き。
SoC統合アーキテクチャの実装戦略
SoC統合はBOM部品点数を最小化し、消費電力を最適化できる最もエレガントなアプローチです。ただし開発チームにBLEスタックの深い知識が必要。
nRF52833を例に取ると、SoftDevice S140（v7.3.0）のリソース消費：Flash 148KB（0x00000-0x26000）、RAM 8KB（SDがシンボルで提供するRAM_START/RAM_SIZE）、アプリケーション利用可能Flash ~364KB。SoftDevice S113（省電力向け）ならFlash 112KB、RAM 6KB（ペリフェラルのみ）。
Zephyr SoCモードの最小構成：
CONFIG_BT=y
CONFIG_BT_PERIPHERAL=y
CONFIG_BT_GATT_DYNAMIC_DB=y
CONFIG_BT_DEVICE_NAME="TecksayDev"
CONFIG_BT_MAX_CONN=1
CONFIG_BT_MAX_PAIRED=1
# Flash占有: ~148KB / RAM: ~32KBインターフェース設計：UARTとSPIの選択
HCIとATコマンドモジュールはどちらもUARTまたはSPIで接続できます。以下の基準で選択：
| パラメータ | UART | SPI |
|---|---|---|
| 最大速度 | 最大4Mbps（フローコントロール必要） | 最大8Mbps（モジュール依存） |
| ピン数 | 2（TX/RX）+ 2（CTS/RTS） | 4（MOSI/MISO/CLK/CS）+ 割り込み |
| CPU負荷 | DMAで低負荷 | DMAで低負荷 |
| 同期 | 非同期 | 同期（マスタークロック） |
| 適用場面 | コスト重視、中速 | 高スループット、ノイズ環境 |
UART実装時の重要注意事項：RTS/CTSハードウェアフローコントロールは必須。ソフトウェアフローコントロール（XON/XOFF）はBLEバイナリデータと競合するため使用不可。ボーレート自動検出機能を持つモジュール（RN4870等）でも、本番環境では固定ボーレートを推奨。
RF認証コストの分析
アーキテクチャ選択は認証戦略と密接に関連します。
| 認証シナリオ | 概算コスト | 期間 |
|---|---|---|
| 認定済みモジュール採用（ATコマンド） | $2,000-8,000（最終製品のみ） | 4-8週間 |
| HCI + 認定済みコントローラモジュール | $5,000-15,000 | 6-12週間 |
| SoC独自設計（フル認証） | $15,000-60,000 | 16-32週間 |
認定済みモジュール（FCC ID取得済み）を使用する場合、ホストシステムへの組み込みに際してモジュラーグラント手続きが必要。FCC CFR 47 Part 15.212に基づくモジュラー承認の場合、追加テスト費用は$2,000-5,000程度。Bluetooth SIGのQDL（Qualified Design Listing）はスタックレベルの認定で、製品認定（QDID）と区別が必要。
量産規模別のアーキテクチャ適合性
量産台数は最終的なアーキテクチャ選択を左右します。
| 量産規模 | 推奨アーキテクチャ | 根拠 |
|---|---|---|
| <1,000台/年 | ATコマンドモジュール | 開発速度優先、BOM高くてもOK |
| 1,000-50,000台/年 | HCI + 認定済みモジュール | 柔軟性とコストのバランス |
| 50,000-200,000台/年 | SoC + 商用スタック（SoftDevice） | BOMコスト削減で投資回収 |
| >200,000台/年 | SoC + オープンソーススタック（Zephyr） | ロイヤルティゼロ、フル制御 |
損益分岐点の計算例：ATコマンドモジュール（HM-10、$3.50/個）vsカスタムSoC設計（nRF52810、$1.80/個、開発費$80,000）の場合、損益分岐点 = $80,000 ÷ ($3.50 – $1.80) = 約47,000台。50,000台以上の量産でSoC設計が優位。
プロトコルスタック選定の意思決定フロー
実際のプロジェクトでの選定基準：
- 既存MCUにBLEを追加したい：ATコマンドモジュール（HM-10、RN4870）が最速。UART接続のみで動作開始可能
- Linux/Android/Windowsホストにコントローラが必要：HCI + BlueZまたはWinRT Bluetooth APIを採用
- バッテリー動作、消費電力最優先：SoC + SoftDevice S113（ペリフェラルのみ）またはZephyrのLPM設定
- Bluetooth Mesh / LE Audio対応が必要：Zephyr BLE（最も広範な機能セット）またはSilicon Labs BGAPI
- 既存のFreeRTOSコードベースがある：NimBLE（FreeRTOSネイティブ統合）またはSoftDevice（FreeRTOSポート利用可能）
まとめ
Bluetoothモジュールのプロトコルスタック選定は、単一の「ベスト」解答が存在しない設計上のトレードオフです。ATコマンドは最速の市場投入を実現し、HCIは既存ホストシステムとの最大の柔軟性を提供し、SoC統合は量産コストと消費電力の最適解を与えます。重要なのは、プロジェクト初期の量産目標台数、利用可能な開発リソース、認証予算を正直に評価し、それらの制約に最も適したアーキテクチャを選択することです。アーキテクチャを途中で変更すると、ファームウェアの大幅な書き直しと再認証が発生するため、初期の選定が特に重要です。さらに詳細なBluetoothモジュールの技術情報については、弊社エンジニアリングチームにお問い合わせください。