ネットワークカメラの業界標準!ONVIF規格とは? (後編)
こんにちは、小野です。
今回は前回に続き、ネットワークカメラ(IPカメラ)や周辺機器に採用される業界標準規格「ONVIF(Open Network Video Interface Forum)」を取り上げます。まだ前回を読んでいない方は、まずこちらからどうぞ。
後編となる本記事では、IPカメラの開発や仕様検討に関わるエンジニアの方向けに、ONVIF対応を進めるうえでの「実装の進め方」と「つまずきやすいポイント」をOKIアイディエスの開発事例を交えて紹介します。
ONVIFコマンドの実装では、Profile Specification、Service Specification、WSDL、Schemaファイルなど参照すべき資料が多く、誤解や見落としがあると、認証取得に支障をきたすことも少なくありません。本記事では、実装の全体像を整理したうえで、認証取得で見落としやすい注意点もご紹介しますので、ぜひご期待ください。
前回は、ONVIF規格についていろいろ教わりました。ネットワークカメラの規格として誕生し、今では世界的に広く普及しています。特にセキュリティ分野では、ONVIFに対応した製品が続々と登場しています。
ONVIFに準拠していると、異なるメーカーの機器同士でも接続でき、システムの拡張や将来的な機器入れ替えにも安心して対応できます。まさにネットワークカメラのデファクトスタンダード(事実上の標準規格)ですね。
ONVIFはプロファイルごとに対応する機能群が決まっていて、年々アップデートされているので、将来性が高い点もポイントでした。
ところで前回、最後に予告していましたよね。OKIアイディエスがどんなONVIF設計を手掛けているのか、深掘りして解説するって。
そうですね、言っていましたね。忘れていません。今回は後編として、ONVIF設計のポイントと、実際にどんなONVIF設計を行っているのかをたっぷり紹介します。
ONVIFコマンドの実装方法
まずは前回、少しだけ触れた「ONVIFの実装方法」について説明します。ONVIFにはコマンドがあって、コマンドを実装することで、クライアント(ユーザー)側からカメラの検出、情報取得からカメラの制御までが行えます。
下記のシーケンス図は、前編で説明したものですが、このシーケンス図で、クライアントからデバイスへ送信されるものが、ONVIFコマンドです。

だから、機器同士の連携が重要なんですね。ONVIFはその連携ができるよう取り決められた規格ってことですよね。
その通りです。ONVIFコマンドを実装するには、仕様書の入手と、実装対象のONVIFコマンドの確認が必要です。
そのONVIFコマンドの実装に必要となる主な仕様書と、その内容はどんなものなんでしょうか?
仕様書についてどんなものか、簡単にまとめました。それから、ONVIFコマンドはXML形式で記述されたメッセージになります。下記に仕様書について簡単にまとめました。なお、ONVIFコマンドはXML(SOAP)メッセージとしてやり取りします。
主な仕様書:
- Profile Specification
「どのプロファイルで、どの機能・コマンドを最低限実装する必要があるか」が書かれた“要件一覧”
- Service Specification
Serviceごとに、「そのコマンドが何をするのか」「どんなリクエスト/レスポンス/エラーになるか」が書かれた“インターフェースの約束事を定義した文書”
- ServiceのWSDLファイル
SOAPメッセージの形や、Input/Outputのパラメータ構造が定義された“通信インターフェースの定義書”
- Schema(XSD)ファイル
型や文字数など、パラメータの細かい制約が定義された“XML文書の構造を定義するファイル”
なるほど……。資料がいろいろあって、細かく定義されているんですね。
ONVIFコマンド実装(XMLメッセージ作成)の流れは、こんなイメージです。
ONVIFコマンドの実装の流れ
- 認証を取りたいProfileのProfile Specificationから実装が必要な機能・コマンドを確認する。
【ポイント!】
ここを誤ると“実装したのに認証が取れない”といった手戻りの原因になります。
- 実装するコマンドが属するServiceのService Specificationでコマンドの機能を確認する。
- WSDLファイル+Schemaファイルで実装するコマンドの詳細を確認する。
【ポイント!】
ここをおろそかにすると、テストツールで思わぬエラーを出してしまい、原因調査に時間がかかるポイントです。
- ONVIFコマンドをXML形式で実装する。
ONVIFコマンドって多分いろんな種類がありますよね。どんなものでも流れは一緒ですか?
はい、コマンド実装の流れは一緒です。前編で映像のストリーム配信のシーケンスについて説明したことを覚えていますか?
覚えていますよ、XMLで記述されたSOAPプロトコル通信になるんですよね。で、映像配信はRTSPプロトコル通信になります。
今回は“GetVideoEncoderConfiguration”コマンドを例にとってみましょう。このコマンドはIPカメラからエンコーダ設定情報を取得するコマンドです。最初のGetProfilesの段階に位置するものですよ。
エンコーダ設定は「圧縮方式(コーデック)」「解像度」「フレームレート」「ビットレート」「画質パラメータ」など、カメラの映像品質やネットワーク負荷を左右する非常に重要なパラメータです。このコマンドの実装手順を追うことで、多くのONVIFコマンドに共通する考え方が理解できます。
なるほど、下記のシーケンスの赤枠で囲った部分ですね。

ONVIFコマンドの実装手順1
1. 認証を取りたいProfileのProfile Specificationから実装が必要な機能・コマンドを確認する。
ONVIF対応機器でコマンド実装を始める際、最初のステップは認証対象となるProfileの仕様確認です。前回も触れましたが、ONVIFではProfileごとに「最低限実装しなければならない機能やコマンド」が厳密に決められています。
プロファイルの種類でいうと、Profile S、Profile C、Profile Gなどがありましたね。Profile Specificationはどこにあるんですか?
Profile SpecificationはONVIFの公式サイトから提供されている仕様書です。Profileごとに仕様書が提供されていて、誰でもダウンロードして閲覧することができます。
たとえば「Profile S Specification」は次のリンク先から閲覧できますよ。
ここでは「7.10 Video Encoder Configuration」の章を見てみましょう。Profile S Specificationには、“Device requirements”や“Function List for Devices”といったセクションがあり、機能ごとに実装に必須かどうかが明示されています。

※ONVIF_Profile_-S_Specificationから抜粋
7.10.3章に機能リストがありますね。
“GetVideoEncoderConfiguration”コマンドについて、Serviceが“Media Service”で、Requirement欄に“M”と書かれています。
“M”は必須(Mandatory)という意味です。つまり、このコマンドは実装しなければならない、ということですね。
なおServiceとは、Profileの中の構成要素(機能のまとまり)です。“Media”もその1つで、クライアント側からリアルタイム配信の設定を行うためのものです。
実装する機能に合わせて、表から必要なコマンドを整理するのが第1歩なんですね。
ONVIFコマンドの実装手順2
2. 実装するコマンドが属するServiceのService Specificationでコマンドの機能を確認する。
次に、実装するコマンドが具体的にどんな機能を持つのかを、Service Specificationで確認します。
たとえば先ほどの“GetVideoEncoderConfiguration”は
Mediaサービスに属するので、「Media Service Specification」を参照します。

“GetVideoEncoderConfiguration”について、5.5.2章に詳しく書かれています。
コマンドの役割(ここでは「ビデオエンコーダ設定を取得」)のほか、パラメータ名(赤枠)、パラメータの型(黄枠)、エラー時の応答(緑枠)、アクセス権(青枠)などが明示されています。
リクエストに含めるべきパラメータや、レスポンスに返る内容が分かりますね。
ONVIFコマンドの実装手順3
3. WSDLファイル+Schemaファイルで実装するコマンドの詳細を確認する。
続いて、コマンドをシステム間でどうやり取りするか、技術的な詳細を確認します。そこで登場するのが「WSDLファイル」と「Schema(XSD)ファイル」です。これらを突き合わせて、SOAP/XML通信が正しくできるよう、必要な情報を把握したうえでXMLメッセージを作成します。
今回のゴールは、ONVIFコマンドを実装するためのXMLメッセージを作ること。これはその準備段階ですね。
その通りです。まずはWSDLファイルで定義された“ GetVideoEncoderConfiguration”コマンドの概要です。

緑枠は、リクエスト/レスポンスのメッセージ構造(SOAP)の操作識別子やURIです。赤枠はInput(入力)パラメータで、ここでは特に“ConfigurationToken”が必須であることを示しています。
「WSDLファイル」は理解できました。もう1つの「Schemaファイル」も教えてください!
分かりました。それでは、「Schemaファイル」も説明しましょう。
例として“common.xsd”を見てみましょう。ここには、トークンの型や最大文字長の制約など、実装時に守るべき細かな仕様が定義されています。

ここまでくれば、XMLファイルの作成に進めそうですね。
ONVIFコマンドの実装手順4
4. ONVIFコマンドをXML形式で実装する。
コマンド仕様に従って、ONVIFコマンドを以下のように整理できます。

- 赤枠:Outputパラメータ
・ Configuration[VideoEncoderConfiguration]:onvif.xsdにて定義
・ ConfigurationTokenに紐づくビデオエンコーダの構成
- 緑枠:パラメータの要件
・ required:必須のパラメータ
・ optional:省略可能なパラメータ
・ unbounded:複数列挙可能なパラメータ
- 黄枠:パラメータの型
・ [VideoEncoderConfiguration]:Output全体
・ [Name]:ユーザーが判別できる名前(最大64文字、onvif.xsdにて定義)
・ [int]:整数型(詳細はw3.org/2001/XMLSchema参照)
上記は、これまで出てきた
“GetVideoEncoderConfiguration”コマンドですね。
そうです。Responseタグの中にConfigurationタグ、その配下に各設定パラメータを入れて構成します。つまり、デバイスに対して「コマンドを受け取ったら、この形式で応答してください」という内容になります。

なるほど。各コマンドのレスポンスは、WSDLやSchemaを参照して作るんですね。では、このコマンドを実行すると、どんなレスポンスが返ってくるんですか?
クライアントから、このコマンドを試してみましょう。そうするとデバイスがこんなレスポンスを返します。

レスポンスの内容を見ると、タグの入れ子構造、token="abc"のような属性の使い方、各パラメータ値の記述方法などが確認できます。こうして正しい形式でXMLメッセージを作れることが、ONVIFコマンド実装のゴールです。
OKIアイディエスの開発事例
OKIアイディエスは、ONVIF対応のカメラシステムの開発実績もあるんですよね。社内のウワサでは、AMD製のKria™ K26 SOMにONVIFを実装したとか。
まさにウワサ通りです。AMD製のSOM(System on Module)であるKriaに実装しました。この開発では、Profile SとProfile Tの2種類のProfileを実装しています。

ということは、Profile S/TのONVIFコマンドを実装したんですね。さらに、ONVIFコマンドに応じた組込みソフトウェア/ハードウェア制御の設計・実装も行った、と。
そうです。ONVIF対応だけでなく、AI推論コアの制御や4K映像への対応まで含めた「トータルなカメラシステム開発」を行った点が特徴です。映像(カメラ)入力部の制御、映像配信・ストリーミング制御、パンチルトズーム制御、エンコーダ制御など、幅広い組込みソフトウェア/ハードウェア制御も実装しました。
紹介してもらったONVIFの要素が詰まっていますね。でも、単にONVIF対応するだけなら、Kriaのようなデバイスを使わなくてもいいのでは?とも思います。
このカメラシステムは物体検知機能も搭載するため、AI推論コアの制御も実装しました。その制御をKria側で行っています。さらに4Kカメラ映像にも対応しています。もちろん、ONVIF対応に必須の適合テストも実施しました。
ONVIFの認証を受けるには、開発したシステムがONVIFテストツールのテストに合格し、ONVIF団体の審査を受けてから認証手続きを行う必要がありますよね?
その通りです。ONVIF認証に向けた適合性テストもPassしています。もちろんそれまでの過程で仕様書通りに設計ができているか都度レビューを行って進めました。設計段階でソフト/ハード設計者が連携し、それぞれの知見やノウハウを持ち寄ることで、複雑なONVIF規格対応のカメラシステム開発を成功させました。
ちなみにKriaはAMD社のデバイスです。OKIアイディエスはAMD社のプレミアパートナーです。AMD製のKria K26 SOM(※)を活用して、限られた資源(CPUクロック、FPGA回路、メモリー)内において、AI処理、ONVIF対応、カメラ制御を実装し、SoC 1チップで実現している点が当社の強みです。パートナーシップによりKriaをはじめ、最新の高性能ハードウェアの情報をいち早く入手し、AMD社との技術連携しながら、システム設計を行っています。
最後に
そういえば、2026年3月3日から2026年3月6日に東京ビッグサイトで開催されていたSecurity Show 2026に行ってきたんですよ。各社がIPカメラやプラットフォームを展示していました。もちろん、ONVIF対応のカメラ製品も数多く展示されていました。やっぱりONVIF規格は業界のデファクトスタンダードになっているというのは本当だったんですね!
ONVIF規格が実際に広まっていることを肌で感じてもらえたようで何よりです。どんな展示がありましたか?
工場や工事現場などのインフラ、介護の現場や家の中など様々な環境に合わせて色んな種類のカメラがありましたが、AIが搭載されたIPカメラシステムが多く展示されていたのが印象的でした。
たとえば、ONVIF対応カメラからの映像をサーバーで受信し、生成AIで人物の特徴を文章入力すると、その映像データ候補を検索できる仕組みが紹介されていました。
IPカメラでのAIの活用方法が今後のカメラシステムのカギとなりそうですね。
他にもサーマルカメラ製品の展示もありましたね。照明のない工場など、異常な発熱の検知をしたいというニーズに対応していました。FAが進む現場ではニーズが多いみたいですよ。こういったところではリアルタイム性が重要視されているようでした。
IPカメラのニーズの多様化を感じますね。確かに危険を検知するのはリアルタイム性が重要視されるのは納得です。
そうなんですよ。でも、リアルタイム性が重視される用途は、監視カメラにおいては思ったよりも少ない印象を受けました。実際には撮りためたデータを後から見返すことが多いようです。
なるほど、後から見返す…。特定の見たいシーンを探して見るのは手間ですよね。そこで先ほどのようなAIの出番、ということですか?
そうなんです。映像記録から、人の背格好の特徴から特定できる仕組みで、人物の特定や誰がいつ現れたなどがわかるようになっていました。
もはや今の時代の監視カメラは、すでに監視するだけではないものに進化しつつあります。「監視+何をするか」という付加価値を考えていく必要があります。
IPカメラの役割は「映像記録」から「検知して報告すること」へシフトしていると感じました。生成AIも登場した今、映像記録とAI処理でどんなことをするのか、どのような付加価値をつけるか。そこが肝心だと思います。
ONVIFは、システムの拡張性や柔軟性という点からも、今後のカメラの付加価値の実現に欠かせない存在になると思います。
ONVIFは随時機能や仕様がアップデートされています。準拠していることで他社メーカー同士の接続も容易になるなど様々なメリットがあります。
開発には、ソフトウェアとハードウェア、両方の知見が求められます。設計の初期の段階から各技術者同士の連携が不可欠です。
前回と今回のブログで、OKIアイディエスでは、IPカメラのソフト・ハード開発だけでなく、ONVIF規格への対応の開発もできることがよくわかりました!展示会では、海外のIPカメラメーカーも多く、日本のONVIF対応のカメラシステムはまだまだこれからと感じました。これからIPカメラを開発したい、という会社さんのお問い合わせをお待ちしています!
OKIアイディエスでは、IPカメラのソフト/ハード開発に加え、ONVIF規格への対応設計・実装・適合試験まで含めたサービスを提供しています。今後もONVIF対応製品の開発・設計サービスを強化してまいりますので、安心してご相談ください!
次回のブログ更新は2026年4月を
予定しています。お楽しみに!
- ※記載されている会社名、製品名は、各社の商標または登録商標です。
- ※ここに記載されている仕様、デザインなどは予告なしに変更する場合があります。