【IoTの通信を軽くする】CoAPとは？仕組み・HTTPとの違いをわかりやすく解説

IoT関連の資料を読んでいて「CoAP」という見慣れない単語に出会い、HTTPと何が違うのか分からず戸惑った経験はありませんか。CoAPは、センサーや小型デバイスのようにリソースが限られた機器のために設計された通信プロトコルです。この記事では、CoAPの基本的な意味から、UDPベースで動作する仕組み、HTTPやMQTTとの違い、セキュリティ対策までを分かりやすく解説します。

CoAPとは？基本的な意味

読み方と正式名称

CoAPは「コープ」または「シーオーエーピー」と読みます。正式名称はConstrained Application Protocol（制約のあるアプリケーション向けプロトコル）で、RFC 7252として標準化されています。ここでいう「制約」とは、CPU性能・メモリ容量・電池残量・通信帯域といったリソースが乏しい状態を指します。つまりCoAPは、名前そのものが「非力な機器のための通信規格」であることを表していると考えると分かりやすいでしょう。

なぜIoT専用のプロトコルが必要なのか

Webサイトの閲覧で使われるHTTPは、豊富なメモリと安定した回線があることを前提に設計されています。一方、屋外に設置された温度センサーや電池駆動の見守り機器は、メモリが数十KBしかなかったり、電池を数年もたせる必要があったりします。こうした機器にHTTPをそのまま載せると、ヘッダーの大きさや通信の往復回数が負担になり、電池の消耗や通信コストの増加につながります。CoAPは、この課題を解決するために生まれたプロトコルです。

HTTPの考え方を引き継いでいる

CoAPは軽量化を追求していますが、まったく新しい概念を持ち込んだわけではありません。リソースをURIで指定し、メソッドで操作するというREST的な考え方はHTTPと共通しています。そのため、Web開発の経験がある人であれば、基本的な考え方はスムーズに理解できるはずです。HTTPを軽自動車サイズに設計し直したもの、とイメージすると全体像をつかみやすくなります。

---

CoAPの仕組み

UDP上で動作する

CoAPの最大の特徴は、TCPではなくUDPの上で動作する点です。TCPは通信を始める前に接続を確立する手続き（ハンドシェイク）が必要ですが、UDPにはその手続きがありません。そのぶん通信の往復が減り、応答が速く、消費電力も抑えられます。デフォルトで使用するポート番号は5683、暗号化を伴うCoAPs（CoAP over DTLS）では5684が割り当てられています。

4つのメッセージタイプ

UDPは「送りっぱなし」で届いたかどうかを保証しないため、CoAPは自前で信頼性を確保する仕組みを持っています。それが以下の4つのメッセージタイプです。

「確実に届けたいデータはCON、多少欠けても困らないデータはNON」と使い分けることで、必要な場面だけ信頼性のコストを払う設計になっています。

HTTPと同じ4つのメソッド

• GET — リソースの現在値を取得する（例：センサーの温度を読む）
• POST — リソースを新規に作成、または処理を実行する
• PUT — リソースの値を更新する（例：設定値を書き換える）
• DELETE — リソースを削除する

加えてCoAPには、HTTPにはないObserve（オブザーブ）という拡張機能があります。クライアントが一度「監視したい」と登録しておくと、値が変化したタイミングでサーバー側から自動的に通知が届く仕組みです。定期的に問い合わせを繰り返す必要がなくなるため、電池駆動の機器では特に効果を発揮します。

---

CoAPとHTTP・MQTTの違い

3つのプロトコルを比較する

使い分けの考え方

CoAPとMQTTはどちらもIoT向けですが、得意分野が異なります。CoAPは「特定の機器の値を、必要なときに読み書きしたい」場面に適しています。一方MQTTは、ブローカーと呼ばれる仲介サーバーを経由して多数の機器にデータを配信する構成に強く、多対多の通信で力を発揮します。どちらが優れているという話ではなく、システムの通信パターンに合わせて選ぶのが実務上の判断基準になります。

---

CoAPのセキュリティ

DTLSによる暗号化

CoAP自体は通信内容を暗号化しません。そのため、機密性が求められる場面ではDTLS（Datagram Transport Layer Security）と組み合わせて使います。DTLSは、TCP向けの暗号化技術であるTLSをUDP向けに作り直したもので、パケットの順番が入れ替わったり欠落したりする前提で設計されている点が特徴です。DTLSを用いる構成は「CoAPs」と呼ばれ、URIも coaps:// で始まります。

注意すべきリスク

UDPは送信元を偽装しやすいという性質があり、CoAPも例外ではありません。特に、小さなリクエストに対して大きな応答を返す仕組みを悪用され、通信量を増幅させる攻撃の踏み台にされるリスクが指摘されています。対策としては、インターネットに直接公開せず閉じたネットワーク内で運用する、DTLSを有効にする、応答サイズに上限を設けるといった設計上の配慮が必要です。

リソース制約とセキュリティの両立

暗号化処理はCPUと電力を消費するため、非力なデバイスでは負担になります。実務では、扱うデータの機密性を評価したうえで、必要な範囲にDTLSを適用するという判断がなされることが少なくありません。ただし、認証情報や個人に紐づくデータを扱う場合は、性能を理由に暗号化を省略すべきではないという点は押さえておきたいところです。

---

CoAPが使われる場面

• スマートメーター — 電気・ガス・水道の使用量を定期的に送信する
• 環境センサー — 温度・湿度・CO2濃度などを収集する農業・ビル管理システム
• スマート照明・空調 — 個別の機器に対して設定値を書き込む
• 産業機器の遠隔監視 — 工場設備の稼働状態を取得する

いずれも「電池で長期間動かす」「通信量を抑えたい」「機器の数が多い」という条件が共通しています。逆に、大きなファイルの転送や、画面表示を伴うアプリケーションにはCoAPは向いていません。

---

CoAPを扱う際に押さえておきたい3つのポイント

• UDPベースであることを前提に設計する — 到達保証が必要なデータにはCONメッセージを使い、再送の設定を検討する
• Observeを活用して通信回数を減らす — 定期的なポーリングより、変化時の通知のほうが省電力になるケースが多い
• 暗号化はDTLSで行う — TLSではなくDTLSである点を混同しないよう注意する

導入前に確認したいチェックリスト

• 通信するデバイスの数と、通信の頻度は明確になっているか
• データの欠落が許容できるか（CON／NONの使い分けの判断材料になる）
• ネットワークがインターネットに直接公開されていないか
• デバイス側にDTLSを処理できる性能の余裕があるか
• 既存システムとの連携でHTTPへの変換（プロキシ）が必要になるか

---

よくある質問(FAQ)

---

まとめ