CoAPとは？一言でいうと？
CoAPは、メモリや電力の少ない機器どうし、または機器とサーバの間で、Webと同じ考え方（URIで資源を指し、GETで読み、PUTで書く）の通信をするためのプロトコルです。IETFのRFC 7252（2014年6月）は、CoAPを制約のあるノードとネットワーク（低消費電力で損失の多いネットワーク）向けの特化したWeb転送プロトコルと説明し、スマートエネルギーやビル自動化などのM2Mの用途を想定しています（2026年9月27日確認）。
RFC 7252は、対象の例として、ROMとRAMの少ない8ビットのマイコンや、6LoWPANのようにパケットの誤りが多く、数十kbit/s程度の速度しか出ないネットワークを挙げています。こうした環境では、HTTPのヘッダの大きさや、TCPの接続手続きの往復が重荷になります。
CoAPはHTTPと簡単に連携できるように作られており、プロキシを介してHTTPの世界とつなげます。一方で、マルチキャスト対応、非常に小さなオーバーヘッド、単純さといった、制約のある環境向けの要件を満たすことを目指しています。
ACKと処理結果の区別は、後半の分離応答とMID・Tokenの例で、送受信を順に追って確認できます。
REST型（GET・PUTなど）とUDPはどう組み合わさる？
CoAPは、上の層はHTTPに似せ、下の層はUDPで軽くするという組み合わせです。温度センサ（CoAPサーバ）の値を読む例で見ます。
- 要求・応答URI で資源を指し、GET・POST・PUT・DELETE を使う。応答コードは 2.05 Content、4.04 Not Found など
- メッセージの層CON・NON・ACK・RST で、届いたかの確認と再送を受け持つ
- DTLS暗号化する場合に使う（既定ポート5684）coaps のとき
- UDP既定ポート5683。接続の手続きがなく軽い
UDP は届いたかを保証しないので、CoAP は自分でメッセージの層を持つ。暗号化も TLS ではなく DTLS。
- クライアントが coap://sensor1.example/temp に GET の要求を送る（UDPの既定ポート5683）
- センサは、応答コード 2.05 Content と温度の値を返す
- 設定を変えたいときは PUT、資源を作るときは POST、消すときは DELETE を使う
- 資源が見つからなければ 4.04 Not Found のように、HTTPの404に対応するコードを返す
応答コードは「クラス.詳細」の形で、2.xxが成功、4.xxがクライアント側の誤り、5.xxがサーバ側の誤りです。HTTPを知っていれば意味を推測しやすいように作られています。
UDPの上でどう確実に届ける？4種類のメッセージ
UDPは届いたかどうかを保証しないため、CoAPはUDPの上にメッセージの層を持ち、次の4種類を使い分けます。
- 1
CON で送る
確認応答を求めるメッセージとして送る
- 2
ACK が来なければ再送
待ち時間を倍々に延ばして再送する（指数バックオフ）
- 3
受け手が ACK を返す
受け取ったことを知らせる。応答を載せることもある
確認が要らない定期的な測定値は NON で送る。処理できないメッセージには RST を返す。
| 種類 | 意味 | 使う場面 |
|---|---|---|
| CON（Confirmable） | 確認応答を求める。届かなければ間隔を倍々に延ばして再送する | 確実に届けたい要求・通知 |
| NON（Non-confirmable） | 確認応答を求めない | 定期的に送る測定値など、多少欠けてもよいもの。マルチキャストの要求もNON |
| ACK（Acknowledgement） | CONを受け取ったことを知らせる。応答を載せることもある | CONへの返事 |
| RST（Reset） | 受け取ったが処理できないことを知らせる | 心当たりのないメッセージへの返事 |
クライアント
CoAPサーバー
1. クライアント → CoAPサーバー
CON：GET要求
確認応答を求めるメッセージで資源を読む
2. CoAPサーバー → クライアント
ACKに応答を載せて返す
確認応答の中に結果を含める
ACKは必ず応答本文を含むわけではない。処理に時間がかかる場合は別の応答になる。
本文とRFC 7252のpiggybacked responseを基にした省略図。空のACKと後続応答のケースは本文で区別。 矢印の長さと段の間隔は、時間・距離を表しません。
ヘッダ・ポート・暗号・拡張は？
CoAPのメッセージは4バイトの固定ヘッダから始まり、0〜8バイトのトークン（要求と応答を対応づける値）とオプションが続きます。既定ポートはUDPの5683番（coap）で、DTLSで保護するcoapsは5684番です。
再送の既定値は、最初の待ち時間（ACK_TIMEOUT）が2秒、最大再送回数（MAX_RETRANSMIT）が4回で、同じ相手に同時に出してよい未完了の要求（NSTART）は1つです。RFC 7252は、この倍々に延ばす再送（指数バックオフ）を基本の輻輳制御としています。
CoAPは、基本仕様のあとに拡張が加えられています。
- Observe（RFC 7641、2015年9月）：資源の値が変わるたびにサーバから通知を受け取る仕組み。GETで一度登録すれば、繰り返し問い合わせずに済む
- CoRE Link Format（RFC 6690、2012年8月）：/.well-known/core にGETすると、その機器が持つ資源の一覧が返る（資源の発見）
- CoAP over TCP, TLS, and WebSockets（RFC 8323、2018年2月）：UDPが通りにくい環境向けに、TCPやWebSocketの上でもCoAPを使えるようにした
MQTTと何が違う？比較表
IoTのプロトコルとして並べて問われやすい2つを、同じ軸で比べます。
| 比較軸 | CoAP | MQTT |
|---|---|---|
| 規格 | IETF RFC 7252（2014年6月） | OASIS MQTT 5.0（2019年3月7日） |
| 通信モデル | 要求・応答（REST型。GET・PUTなど） | publish/subscribe（ブローカーが配る） |
| 下位の通信 | UDP（TCP・WebSocket版はRFC 8323） | TCP/IPなど順序どおり欠けずに届く通信 |
| 中継役 | 不要（端末どうしで直接話せる。プロキシも使える） | ブローカーが必須 |
| 確実さの調整 | CON（確認あり）とNON（確認なし） | QoS 0・1・2 |
| 既定ポート | 5683（coap）、5684（coaps・DTLS） | 1883（TLSなし）、8883（TLS） |
| 暗号化 | DTLS | TLS |
| 値の変化の通知 | Observe（RFC 7641） | 購読したトピックに配信 |
| マルチキャスト | 対応（要求はNON） | 仕様にはない（ブローカーが複数に配る） |
迷ったら、「誰が相手を知っているか」で考えます。CoAPはクライアントがセンサのURIを知って直接たずねる形、MQTTは送り手も受け手もブローカーだけを知っていればよい形です。MQTTの仕組みは MQTTとは、UDPとTCPの違いそのものは TCPとUDPの違い で確認できます。
IoT中級ではどこで、どう問われる？
CoAPは、IoTシステム技術検定 中級の出題カテゴリ「センサ／アクチュエータ技術と通信方式（デバイス、ネットワーク、LPWA、プロトコル）」の「プロトコル」に当たります。公式ページの図では比率が25〜30%です（MCPC公式ページ、2026年9月27日確認）。公式テキスト『IoT技術テキスト 第4版』では第4章「IoT通信方式」に当たる範囲です（章とカテゴリの対応は当サイトの推定）。
CoAPの出題数は公表されていません。4択では、次のような観点が考えられます（当サイトの予想で、出題の再現ではありません）。
- CoAPが使う下位プロトコル（UDP）と、MQTTが使うもの（TCP）の区別
- REST型のメソッド（GET・POST・PUT・DELETE）を使うこと
- CON・NON・ACK・RSTの意味の組合せ
- 暗号化の手段（CoAPはDTLS、MQTTやHTTPSはTLS）
用途の条件からHTTP・MQTT・CoAPを選ぶ考え方は HTTPとMQTTの使い分け でまとめています。
どこで取り違えやすい？つまずき別の見直し表
| 取り違え | 正しい整理 | 見直す手がかり |
|---|---|---|
| CoAPもTCPで動くと思う | 基本はUDP。TCP・WebSocket版は後からRFC 8323で追加 | RFC 7252＝UDP |
| CoAPはpublish/subscribe型だと思う | 要求・応答のREST型。変化の通知はObserveで補う | ブローカーがいるのはMQTT |
| CoAPの暗号化はTLSだと思う | UDPの上なのでDTLS。coapsの既定ポートは5684 | D＝Datagram（UDP向け） |
| NONは応答が返らない要求だと思う | NONは確認応答（ACK）を求めないだけで、応答自体は返りうる | ACKの有無と応答の有無を分ける |
| ポート番号をMQTTと混同する | CoAPは5683・5684、MQTTは1883・8883 | CoAPは56で始まる |
確認問題1
CoAPの説明として正しいのは？
CoAPの説明として、最も適切なものはどれか。
選択肢を準備しています。「正解と解説を見る」は先に開けます。
正解と解説を見る
正解：1。CoAPはRFC 7252で規定された、UDPの上で動くREST型のプロトコルで、HTTPと同じくGET・POST・PUT・DELETEを使います。
2はMQTTの説明です。3は「UDP」の部分は合っていますが、トピックの購読はMQTTの仕組みで、CoAPは要求・応答型です。4は誤りで、CoAPの基本はUDPで、QUICを使うのはHTTP/3です。
確認問題2
確認応答を求めるメッセージはどれ？
CoAPで、受信側に確認応答（ACK）を求め、応答がなければ再送するメッセージの種類はどれか。
選択肢を準備しています。「正解と解説を見る」は先に開けます。
正解と解説を見る
正解：4。CONは確認応答を求めるメッセージで、ACKが返らなければ待ち時間を倍々に延ばしながら再送します。
1のNONは確認応答を求めないメッセージで、定期的な測定値など多少欠けてもよい送信に使います。2のRSTは、受け取ったメッセージを処理できないことを知らせる返事です。3のACKは、CONを受け取ったことを知らせる側のメッセージです。
確認問題3
coapsの既定ポートと暗号化の組合せは？
RFC 7252で定められた、暗号化されたCoAP（coaps）の既定ポートと暗号化の方式の組合せとして、最も適切なものはどれか。
選択肢を準備しています。「正解と解説を見る」は先に開けます。
正解と解説を見る
正解：2。coapsはUDPの上でDTLSを使い、既定ポートは5684番です。暗号化しないcoapの既定ポートは5683番です。
1の5683番は暗号化しないcoapのポートで、方式もTLSではありません。3の8883番とTLSは、MQTTをTLSで使う場合の組合せです。4の1883番はTLSを使わないMQTTのポートです。
プロトコルの問題にほかの分野を混ぜて本番の形式で試すなら、IoT中級の無料お試し20問 へ。登録なしで全問の解説を確認できます。
空のACKと処理結果は別：MIDとTokenで追う分離応答
温度をGETした後、センサがすぐに結果を返せない場合を考えます。空のACKは要求メッセージの受信確認で、温度の取得結果ではありません。同じ通信相手との間で、MIDはメッセージの確認・再送、Tokenは要求と応答の対応を追う値です。以下の番号は説明用です。
- 1
端末 → センサ：CON GET
MID=1001、Token=0xA1B2C3D4で温度を要求
- 2
センサ → 端末：空のACK
MID=1001、Code=0.00。Tokenなし。処理結果はまだ届いていない
- 3
センサ → 端末：別のCON応答
MID=2001、同じToken、2.05 Contentで温度を返す
- 4
端末 → センサ：空のACK
MID=2001で、この応答メッセージの受信を確認
受信確認のMIDと、要求・結果を対応させるTokenを分けて読む。
RFC 7252の分離応答を説明する独自例。時間間隔は表していません。
| 応答の方式 | 要求直後のACK | 結果の対応付け |
|---|---|---|
| すぐに結果を返す（ピギーバック） | 要求と同じMID。結果のコードとTokenも載せる | 要求と同じToken |
| 後から結果を返す（分離応答） | 要求と同じMIDの空ACK（Code=0.00） | 後の応答に要求と同じToken。CON応答なら、そのMIDへのACKも返す |
ACKを受け取ったことと、処理が成功したことは区別します。またCONにも再送回数の上限があり、通信障害下での到達を無条件に保証する仕組みではありません。RFC 7252の5.2節・5.3節で、応答方式と値の照合を確認できます。