要約

  • draft-toutain-t2trg-coreconf-m2m-01 は、コンパクトなYANG/SIDモデルをontology、FROST、MCPツールへ接続し、制約機器のデータと操作をagentから利用可能にする案である。
  • ツール定義、正しいSID、DTLS/OSCORE、成功応答はそれぞれ限定された事実を示すだけで、主体の権限や物理的postconditionまでは示さない。
  • 防御可能な記録には、モデル版、識別子投影、principal、policy、承認、要求、CORECONF認可、ローカル処理、interlock、作動、独立readbackが必要である。

一つの操作には二つの時計がある。MCPサーバーが「完了」を返した時刻と、現場の軸が目標回転数へ達した時刻だ。両者が一致する保証はない。後者が存在しないことさえある。

それでも自動化画面は前者だけを表示しやすい。tool callは正しい名前と引数を持ち、SIDは解決され、CoAP応答も成功した。その瞬間、デジタルな受理が物理的な結果へすり替わる。

2026年10月2日時点で、IETF DatatrackerはCORECONF for Machine-to-Machine Communication revision 01をactiveなindividual Internet-Draftとして掲載していた。更新日は9月16日、本文も同日付で、想定statusはInformational、失効日は2027年3月20日である。RFC stream、responsible AD、telechatはない。Datatrackerは個人投稿がIETFのendorsementでもstandards process上の正式な地位でもないと明記する。T2TRG mailing listでの議論は採用の証拠ではない。

同日のYANG Validationは19 errors、8 warningsを示した。revisionにreferenceがない、descriptionがない、canonical orderに反する、config falseのbootstrapがaccessible treeにない、といった内容である。これは提出版の成熟度を示す診断であり、実装障害や脆弱性の件数ではない。

小さなpacketの背後に大きな意味がある

提案はYANGによる型、CBORによる小さいpayload、CoAPによる交換、SIDによる短い識別を組み合わせる。transducerはsensor、actuator、または両方であり、quantity、timestamp source、統計、通知設定を持つ。低電力回線にとって、冗長な名前を毎回送らずに済む価値は大きい。

revision 01はSOSAとSensorThingsへの投影を加え、二つのMCP serverを描く。coreconf-m2mはlive deviceのCoAP操作を包み、frost-sensorthingsはFROST内の履歴と関係を照会・編集する。Rennesの例では、agentがThingを探し、Datastreamをたどり、sensor SIDとprecisionを取得し、現在値を読んでObservationとして保存する。

abstractはdevice-specific translation layerなしでAI agentと相互運用できると述べる。しかし解釈者は消えていない。MCP serverがFROSTからhostname、endpoint、transducer identity、instance SID、target SID、unit、precisionを選び、friendlyな引数をwire requestへ変える。

古いendpointなら別の機器へ届く。identityの再利用なら名前と実体がずれる。precisionが違えば有効な整数が誤った物理量になる。categoryを誤ればsensorがactuatorとして露出する。syntaxはすべて正しいままでもよい。

従ってprojection receiptには、正確なYANG module/revision、feature、deviation、SID file、private translation、device/transducer identity、bootstrap generation、endpoint、unit、precision、category、control type、method、path、target SID、FROST recordのversion・provenance・freshnessが要る。

Capabilityを見つけることと、使う権利は違う

ccm2m:Controlは操作を明示する。read-single、read-stat、統計reset、history設定、subscription、actuatorのinstant-writeが分かれている。setup-historyは設定するだけで開始せず、stopはCoAP Observeの状態に依存する。この区別はよくできている。

ただしcontrol graphはauthorized principalを決めない。許容範囲、目的、時間窓、二者承認、retry上限、safety interlock、emergency stopも書かない。操作が存在するというontology statementは、そのagentが今それを実行してよいというpermission statementではない。

基盤のCORECONF draft revision 21は、serverがunauthorized userによるread/writeを防ぐことを要求する。data node、datastore、RPC、action、event streamに対する権限がなければ4.01 Unauthorizedを返し、適切なauthentication/authorizationを利用するとしている。従って「CORECONFに認可がない」という結論は誤りである。

MCP 2026-07-28 specificationもtool discoveryとpermissionを分ける。tool setはrequestごとのauthorizationで変えてよい。serverはinput validation、access control、rate limitを行い、clientはsensitive operationのconfirmationや引数表示、result validation、timeout、auditを考慮する。信頼されないserverからのtool annotationは信頼してはならない。

必要なのは層間のbindingである。MCP server identity、tool-definition hash、requesting client、authenticated principal、credential audience/scope、policy version、承認、target、parameter boundsとCORECONF authorization decisionを一つのevidence chainへ置く。tool nameだけのlogには、委任者も責任主体もいない。

Channel securityは機械の安全範囲を決めない

選択したdraftはCORECONF over CoAPにDTLSまたはOSCOREを要求する。それらは通信を守る。pumpの回転数上限、valveを開けられる時間、maintenance中の禁止、現場のstop authorityは決めない。暗号は危険なrequestも正確に届けられる。

CORECONFはUnauthorized、Not Found、Method Not Allowed、YANG constraintなどのerrorを区別する。2.xx successはそのlayerでrequestが処理された証拠である。shaft speed、pressure、valve position、temperatureの実測ではない。

draftのinstant-write例は、架空pumpを1,500 rpmへ設定する。実在しないためidentity SIDはPPPPPPというplaceholderで、quantityのstructural SIDだけが実際のmodel定義である。sosa:Actuationはwritten valueとclientがcommandを発行した時間を記録し、draft自身がobservationではないと説明する。

commandとmeasurementを分ける姿勢をMCP UIでも維持すべきだ。tachometerのreadbackには別のsensor identity、calibration、unit、precision、timestamp source、causal windowが必要である。commandを書いたcache rowを読み返しても、物理世界は確認できない。

完全なladderは、tool invocation、intent/consent、principal/authorization、protected request、application validation、durable commit/action start、local interlock、physical actuation、separate observation、state persistence、reconciliation/rollbackを分ける。途中で止まることは問題ではない。どこまで進んだかを偽らないことが重要だ。

一人の設定が全subscriberを変える

notification parametersは具体的なblast radiusを示す。historyのstep、precision、max-samples、time-period、encoding、max-payload、alertのthreshold、hysteresis、dampening、confirmable cadenceはwritableで、同じtransducerの全observationに共通する。active中の変更は、設定したclient以外にも即時反映される。

start_history_notifyはiPATCHで設定した後にFETCH+Observeする。呼出側には個人用subscriptionに見えても、既存observerの頻度やencodingを変え得る。active flagは一人以上が見ていることしか示さず、誰が何の目的で見ているか、変更に同意したかは示さない。

安全なtoolはshared scopeを明示し、旧version/値を読み、preconditionかconflict ruleを使い、before/afterとaffected observerを記録する必要がある。subscribe権限は、他者のsubscriptionを再設定する権限ではない。FROSTのhistoryを読む権限も、live controllerのidentity mappingを編集する権限ではない。

NONは再送判断をapplicationへ渡す

profileではFETCHとiPATCHをNon-Confirmable CoAPで送る。低電力networkでdefault retransmissionを避ける目的は理解できる。その代わりtimeout、retry、idempotencyはapplication policyになる。

responseがないと、request未着、処理済みでresponse喪失、処理継続中を区別できない。set-valueの再送とside effectを持つactionの再送は同じではない。receiptにはrequest identity、token、payload hash、attempt、timeout policy、duplicate handling、後続readbackが必要である。

Confirmable notificationのACKもCoAP peerへのdeliveryを示すだけだ。FROSTへのdurable write、agentの判断、人間の認知、physical conditionの解消は別である。

Timestampとscaleが結果の意味を決める

bootstrapにはoptionalなreference epoch、uptime、minimal-stepがある。quantity timestampはsourceまたはreceiverが付け、historyではarrivalとstepから再構成される場合がある。command issue、firmware accept、physical effect、database storeの時刻を同一視できない。

raw integerはidentity、unit、precisionと組み合わさって初めてquantityになる。minimal-stepより速いpollingはfreshnessを増やさずbatteryだけを使う可能性がある。postconditionにはmodel revision、unit、precision、calibration、time origin、clock quality、ageを残すべきだ。

YANG validationの19/8も同じ原則に従う。現在のrevisionに修正点があることを示すが、security scoreではない。将来zeroになっても、authorization、interoperability、physical motionは証明しない。これはmodel receiptである。