消 防 情 第 365号
令和５年11月29日
都道府県消防防災主管部長 殿消防庁国民保護・防災部防災課防災情報室長（公印省略）
地上デジタル放送波を活用した災害情報伝達手段の技術ガイドラインの改訂について（通知）
平素から、消防防災行政の推進について格別な御尽力いただき厚く御礼申し上げます。
この度、令和４年３月に公開された「地上デジタル放送波を活用した災害情報伝達手段のガイドライン策定等に係る検討報告書」の第2部 第2章「地上デジタル放送波を活用した災害情報伝達手段の技術ガイドライン」について、別紙２のとおり改訂しましたので公表いたします。
今回の改訂は、令和４年度に実施しました技術実証の成果を踏まえ、複数自治体と複数放送局で運用する場合の放送遅延等を防止するために、関係者間で定めておくべき運用のルールを留意事項として追記するなど所要の改訂を行ったものです。
つきましては、貴都道府県内の市町村に対し、災害情報伝達手段の多重化に取り組むための参考資料として御活用していただきますよう周知をお願いいたします。
記
１．添付資料（１）別紙１：地上デジタル放送波を活用した災害情報伝達手段の技術ガイドライン
改訂のポイント（２）別紙２：地上デジタル放送波を活用した災害情報伝達手段の技術ガイドライン（令和５年11月改訂）
２．資料掲載先「地上デジタル放送波を活用した災害情報伝達手段の技術ガイドライン（令和５年11月改訂）」(https://www.fdma.go.jp/mission/prepare/transmission/item/transmission001_08_r511-1.pdf）

以上
総務省消防庁 国民保護・防災部
防災課

防災情報室

担当：金子、荷見、山口、工藤、横山
電話：03-5253-7526（直通）別紙１

地上デジタル放送波を活用した災害情報伝達手段の技術ガイドライン
改訂のポイント＜概要＞
令和４年３月に公開された「地上デジタル放送波を活用した災害情報伝達手段のガイドライン策定等に係る検討報告書」の第 2 部 第 2 章「地上デジタル放送波を活用した災害情報伝達手段の技術ガイドライン」について、複数自治体と複数放送局で運用するモデル（以下「ｍ：ｎモデル」という。
）に係る令和 4 年度技術実証の成果を踏まえて、関係者間で定めておくべき運用のルールを留意事項として追記するなどの所要の改訂を行ったものです。

＜主な改訂ポイント＞
１ 地上デジタル放送波を活用した災害情報伝達手段の特徴（２）地上デジタル放送波を活用した災害情報伝達手段の利点（メリット）○（追記）ｍ：ｎモデルの利用に当たって、限られた伝送能力を複数の市町村がシェアする必要があることから、放送波の利用について一定の制限及びルール作りが必要であること。
【例】：1 回の情報発信の音声ファイルの大きさ制限
２ 情報伝達システムの詳細（２）統合運用調整機能（バックエンド機能）○（修正）バックエンド機能を放送事業者が担うことで「バックエンド事業者」が存在しないケースが想定されることから、「バックエンド事業者」の記載を削除すると共に、新たに「統合運用調整機能（バックエンド機
能）」の語を用いること
３ 情報伝達システムの標準とするべき技術的要件について○（追記）サービス・機器提供事業者間の競争性を確保するための新たな要件【例】：テレビ受像機製品と同様に、ベンダー（メーカー）を問わず、災害情報伝達の仕組みとしての基本的機能が保証され、全国すべてのテレビ局（放送事業者）の電波を受信し、共通的に動作しなければならない○（追記）ｍ：ｎモデルの利用に当たって輻輳を避けるための新たな要件【例】：市町村が生成する災害情報を記述した音声ファイル等のデータ量の大
きさの上限について、事前に市町村相互で運用ルールを定めなければならない

：回線の圧迫を緩和する目的で、可能な限り情報発信のタイミングをずらすため、市町村相互での情報発信のタイミングの事前共有等の運用ルールを定めなければならない○（追記）災害情報の伝達に必要となる安全かつ継続的運用のための新たな要件【例】：市町村防災行政無線（同報系）と同等以上の音質を確保すること：市町村からの災害情報が送信された際は、市町村との契約に基づき、当該データ放送帯域において、優先的に災害情報を放送すること○（追記）参考として、市町村数の上限等を決定する様々な要素（放送事業者が提供する帯域による）【例】：聞き取りやすい一定の音質：音声データファイルの符号化方式：データファイルの圧縮比率（非圧縮ファイルサイズに対する圧縮後のファイルサイズ）：受信障害対策のための方策（FRUTE/AL-FEC 送出機能の仕様）：連続送信間隔
３（１）基本的な要件○（追記）セキュリティ対策の明確化【例】：システム全体におけるセキュリティ担保（セキュリティの 3 要素含む）
が必要であること
３（３）入力（送信）システム○（追記）J アラートとの連携を行うべきこと、及びその際に留意すべき事項【例】：国民保護情報や大津波警報等の情報を EDXL 化し、統合運用調整機能（バックエンド機能）と連携すること：遅延防止のため、関係者間においてあらかじめ運用に関する取り決めを行うこと
３（６）受信機の標準仕様○（追記）受信機の標準的仕様について、ｍ：ｎモデルの利用に当たって必要となる新たな要件【例】：受信機については高齢者等の操作も想定して、操作性は簡易であることが望ましい：EDXL に含まれる自治体コード、エリア ID、グループコードを識別し、適切に動作をする機能を有しなければならない：放送により蓄積された情報を EDXL の内容により時刻指定再生などが可能になるよう時刻を取得し保持できる機能を有すること

４ 導入に当たっての留意事項○（追記）地上デジタル放送事業者が参入する際に、電波法や放送法等の法令上の手続について留意しておくべき事項【例】：放送事業者においては、運用開始までに管轄の総合通信局等へ電波法、放送法等に係る事業計画の変更届出が必要となること：設備の変更が必要な場合は、電波法に係る変更許可の申請が必要となること（４）地上デジタル放送事業者との利用契約○（追記）地上デジタル放送事業者との利用契約に当たって、確実に情報伝達するために留意しておくべき事項、及びｍ：ｎモデルの利用に際して留意す
べき事項【例】：当該帯域において、平時に災害情報以外の情報を配信するサービスの契約を行う場合は、有事の際に災害情報の配信を優先するため、災害情報
以外の情報の配信を中止する可能性があることの確認○（追記）放送休止時間や放送事業者が放送役務を実施できない状況下における例
示【例】：中継局の保守作業や機材メンテナンスの実施中の場合や、災害・事故等による障害が放送設備に発生した場合等○（追記）ひとつの放送事業者が複数の市町村と契約する場合に必要となる確認事
項【例】：それぞれの市町村からの放送要求が同時刻に集中した場合、放送事業者
は放送要求の先着順に実施し、放送までのタイムラグが発生する可能性があることを確認○（追記）サービス開始後に他の市町村から利用開始の申し出があった場合の対応
方針【例】：地上デジタル放送事業者は、データ放送帯域を災害情報伝達のために利用するサービスを開始した後、当該事業者の放送エリア内における他の市町村からサービス利用の申し出があった際は、新たにサービス提供を行うために十分なデータ放送帯域が確保されている場合、当該市町村と誠実に協議を行い、必要とされるサービスが提供するように取り計らうことが望ましい別紙２

地上デジタル放送波を活用した災害情報伝達手段の技術ガイドライン

令和４年３月
令和５年 11⽉ 改訂

（技術ガイドライン 目次）
はじめに ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・１
１

地上デジタル放送波を活用した災害情報伝達手段の特徴

・・・・・・・・２（１）地上デジタル放送波を活用した災害情報伝達手段の概要

・・・・・・２（２）地上デジタル放送波を活用した災害情報伝達手段の利点（メリット） ・４（３）情報伝達の流れ ・・・・・・・・・・・・・・・・・・・・・・・・・４
２

情報伝達システムの詳細 ・・・・・・・・・・・・・・・・・・・・・・・５（１）入力（送信）システム ・・・・・・・・・・・・・・・・・・・・・・５（２）統合運用調整機能（バックエンド機能） ・・・・・・・・・・・・・・６（３）テレビ局マスター設備 ・・・・・・・・・・・・・・・・・・・・・・７（４）屋外スピーカー・屋内受信機 ・・・・・・・・・・・・・・・・・・・８（５）その他の追加的な機能 ・・・・・・・・・・・・・・・・・・・・・・９３

情報伝達システムの標準とするべき技術的要件 ・・・・・・・・・・・・・17（１）基本的な要件 ・・・・・・・・・・・・・・・・・・・・・・・・・・18（２）EDXL の標準仕様について ・・・・・・・・・・・・・・・・・・・・19（３）入力（送信）システム ・・・・・・・・・・・・・・・・・・・・・・21（４）統合運用調整機能（バックエンド機能） ・・・・・・・・・・・・・・22（５）ＩＰＤＣ連携装置 ・・・・・・・・・・・・・・・・・・・・・・・・22（６）受信機の標準仕様 ・・・・・・・・・・・・・・・・・・・・・・・・23
４

導入に当たっての留意事項 ・・・・・・・・・・・・・・・・・・・・・・26（１）入力（送信）システムの検討・導入 ・・・・・・・・・・・・・・・・26（２）サービス提供事業者との利用契約 ・・・・・・・・・・・・・・・・・26（３）ＩＰＤＣ連携装置の設置及び基幹放送設備との接続 ・・・・・・・・・27（４）地上デジタル放送事業者との利用契約 ・・・・・・・・・・・・・・・28（５）屋外スピーカー・屋内受信機の整備・導入 ・・・・・・・・・・・・・29

はじめに
本ガイドラインは、令和３年度の「地上デジタル放送波を活用した災害情報伝達手段のガイドライン策定等に係る検討会」における議論や実証等を通じて得られた知見を整理し、令和４年３月に公開された「地上デジタル放送波を活用した災害情報伝達手段のガイ
ドライン策定等に係る検討報告書」の第 2 部 第 2 章「地上デジタル放送波を活用した災害情報伝達手段の技術ガイドライン」について、令和 4 年度における複数自治体が単一放送事業者の帯域を共用する際に発生する課題とそれを解決する複数放送局の複数帯域を切り替えて運用するモデル（以下「ｍ：ｎモデル」という。
）での技術実証における成果を踏まえて改訂を行ったものである。
地上デジタル放送波を活用した災害情報伝達手段の導入と運用に当たっては、地上デジタル放送事業者に加え、入力（送信）システム、電子署名の認証局機能及び指定する放送事業者へのルーティング機能（バックエンド機能）、地上デジタル放送関連設備、各種受信装置の機能・サービスを提供する事業者が関連することから、各市町村が別々の調達仕様で独自に本手段の整備・導入を進めた場合、これらのサービス提供事業者毎に仕様が異なること等につながり、当該事業者間での競争が働かず、導入・運用経費が低廉化できない等の弊害が生じるおそれがあることから、本ガイドラインは、地上デジタル放送波を活用した災害情報伝達手段の中核となる技術・機器について標準とするべき技術的要件・仕様を提示し、これに準拠したシステムや機器等を市町村が調達することで事業者間の競争性を確保することを狙いとするものである。
さらに、新しい災害情報伝達手段であることを踏まえ、市町村の防災担当職員が導入を検討する際の参考に資する手引きとするとともに、地上デジタル放送事業者やサービス提供事業者等の関係者に対して、標準とするべき技術的要件への理解を深められる資料とする。
本ガイドラインの構成は、１及び２において令和３、４年度の技術実証を踏まえて得られた技術的知見を総括し、これを踏まえ、３において地上デジタル放送事業者やサービス提供事業者等の関係者に対する標準とするべき技術的要件をとりまとめるとともに、４において導入に当たり市町村の防災担当職員及び地上デジタル放送事業者等の関係者が留意すべき事項をとりまとめた。
なお、本ガイドラインをもとに、本手段の整備・運用に関わる市町村、放送事業者、サービス提供事業者等が主体となり、全国的な課題の解決に向けた検討や、ガイドラインの要件を達成するための標準的な仕様や運用ルールの策定を行うことで、本手段のより一層の整備促進が期待される。

-1-

１ 地上デジタル放送波を活用した災害情報伝達手段の特徴（１） 地上デジタル放送波を活用した災害情報伝達手段の概要
地上デジタル放送波を活用した災害情報伝達手段は、市町村が伝達する災
害情報をインターネットで一般的な IP パケットとして、テレビの地上デジタ
ル放送波に重畳して、屋外スピーカーや屋内受信機に一斉同報する伝達手段である。
地上デジタル放送波に IP パケットを重畳し一斉配信する放送技術・サービス（以下「ＩＰＤＣ」という。）については、文字や音声、映像のほか、PDF
ファイルやオフィス系ソフト（Word、Excel 等）のファイル、センサー信号等
も放送波に重畳することが可能である。また、受信した IP パケットは、そのままイーサネット等のコンピューターネットワークに載せることができるた
め、インターネットインフラでの情報伝送が容易となっている。
このＩＰＤＣ方式について地上デジタル放送を活用して放送するのが「地上デジタル放送波を活用したＩＰＤＣ型データ放送」であり、地上デジタル放送波を活用した災害情報伝達手段は、このＩＰＤＣ型データ放送を用いて災害情報を伝達するものである。
また、本手段は情報交換言語として EDXL を採用する。EDXL とはEmergency Data eXchange Language の略である。以降、当文書の中で「EDXL」と表現する場合、消防庁の標準定義フォーマット（別添参照）に準拠した「EDXL」を指す。
（参考）
EDXL は、通信に関する標準化団体 OASIS により、災害情報管理・処理のた
めに XML で定義された文書形式で、異なるシステム間で情報の伝送を行うための標準記述形式である。これは、L アラートにおいても一部拡張され「コモンズ
EDXL」として採用されている。
消防庁が平成 28 年度に実施した「災害情報伝達手段等の高度化事業」においては、加古川市における V-Low マルチメディア放送を活用した同報系システムの整備・実証に当たり、文字情報を伝送できる「コモンズ EDXL」をマルチメデ
ィア（音声、画像等）の伝達を可能とするよう拡張した EDXL が導入された。
地上デジタル放送波を活用した情報伝達手段において用いられる EDXL についても、V-Low マルチメディア放送を活用した同報系システムに用いられた
EDXL を地上デジタル放送波用に拡張したものを活用する。
（屋外スピーカー、
屋内受信機、デジタルサイネージ、避難所の館内放送設備等に音声・文字・画像
情報を伝送できるだけでなく、避難所の施錠装置や照明の操作等も可能である。）
現状、開発・製造が見込まれる当該伝達手段の受信機等においては、文字や音声、デジタルサイネージへの表示、受信機のソフトウェアアップデート等が可能となっているが、将来的には、市町村等のニーズに応じて、サービス提供-2-

事業者等において、映像や電子ファイル、センサー信号等の伝送が可能となる設備・機器の開発や製造が行われる可能性がある。
ＩＰＤＣ型データ放送については、地上デジタル放送波の特性（一斉同報、高い耐障害性、各世帯でのテレビ受信環境の普及等）を活かし、デジタルサイ
ネージ等の多様なＩＰ端末に情報伝達が可能な技術として、ＩＰＤＣフォー
ラムにおいて、規格化や技術仕様検討等が行われ、アナログテレビ放送（ＶＨ
Ｆ）の跡地利用として、事業化が試みられたマルチメディア放送（Ｖ－ｈｉｇ
ｈ／Ｖ－Ｌｏｗ）に実装された技術である。
本手段のシステム構成については、次のとおりである（図 1）。

②統合運用調整機能（バックエンド機能）

図 1 地上デジタル放送波を活用した災害情報伝達手段の構成（①市町村の操作端末）
後述する要件【３ - (３)】を満たすことができれば、既存の一斉同報のインターネットサービスや防災行政無線操作卓等からの情報発信も可能である。
操作端末から入力する災害情報は、EDXL で記述され、情報を伝送する。

（①市町村～②統合運用調整機能（バックエンド機能））
指定の地上デジタル放送事業者に対して EDXL を伝送するメッセージルー
ティングを行う。情報が適切に送信されたことを市町村庁舎の操作端末に返信する。

（②統合運用調整機能（バックエンド機能）～③放送事業者）
EDXL で記述された災害情報を、放送事業者の基幹放送設備に接続するＩ
ＰＤＣ連携装置において、TS（トランスポートストリーム：放送用のコンテナ形式）に変換し、基幹放送設備に出力し、地上デジタル放送波に重畳され、情報が伝送される。
-3-

（③放送事業者～④屋外スピーカー・屋内受信機等）
屋外スピーカー・屋内受信機において、音声・文字表示等により住民等へ災害情報を伝達する。受信し処理した文書ＩＤに動作結果等を付して、ＬＰＷ
Ａ等の通信網を通じてアンサーバックを行うことも可能となっている（拡張的な機能）。

（２） 地上デジタル放送波を活用した災害情報伝達手段の利点（メリット）
地上デジタル放送波を活用した災害情報伝達手段については、次の利点がある。
ア

本手段に用いているＩＰＤＣ型データ放送は、情報を既存のコンピューター

ネットワークに載せることが容易であるため、様々な機器・デバイスに情報を伝送することができる。
イ

既存の地上デジタル放送網を活用するため、市町村にとって新規の設備整備の負担が少ない。また、運用保守については、バックエンドを運営する事業者
及び地上デジタル放送事業者との利用契約を締結する形式となるため、これらの設備等の保守は不要となり、市町村が自ら整備した屋外スピーカーや屋内受信機の保守管理を行うこととなる。
なお、他営網を用いること、限られた伝送能力を複数の市町村がシェアして利用する場合があることから、同様の特性を持つ他の災害情報伝達手段と同様に、放送波の利用には制限（先着順に放送）や一定のルール（１回の情報発信の音声ファイルの大きさ）が生じうることに注意が必要である。

ウ 地上デジタル放送の対象地域は、県域（又は広域）であるため、広域避難を想定した場合でも、市町村外の住民に情報伝達が可能である。
エテレビコンセントに接続した同軸ケーブルと屋内受信機を接続することで、屋内での情報受信が可能となり、アンテナ工事等が不要のため、比較的安価に
屋内受信機を配備することができる。

（３） 情報伝達の流れ
市町村の防災担当職員は、入力（送信）システムを経由して災害情報を入力し、バックエンドでは、認証アカウンティングを含む情報交換網の中核を担い災害情報のルーティング、キューイングを行う。
災害情報が放送局内に届くと、ＩＰＤＣ連携装置で TS（トランスポートスト
リーム）という形式に変換され、地上デジタル放送の本放送の TS とともに多重化され、送信所から送出される。送出された TS は、屋外スピーカーや屋内受信機で受信され、音声等で伝達される。
（図２）

-4-

屋外スピーカー

入力（送信）
システム

統合運用調整機能（バックエンド機能）

図 2 情報伝達の流れのイメージ

２ 情報伝達システムの詳細
上記１（３）に記載したとおり、地上デジタル放送波を活用した災害情報伝達手段
は、①入力（送信）システム、②統合運用調整機能（バックエンド機能）、③テレビ
局マスター設備（ＩＰＤＣ連携装置、多重化装置）、④屋外スピーカー、屋内受信機で構成される。以下に各構成の詳細を示す。
（１） 入力（送信）システム
入力（送信）システムは、市町村の防災担当職員が容易に使用できるユーザー
インターフェース（UI）を有し、電子署名に対応することが可能で、EDXL を出力する機能があれば、専用のシステム等に限定されるものではない。一斉送信シ
ステムのクラウド型の WEB アプリケーションや既存の災害情報システムの入力システムを活用することを想定している。
なお、本手段のための専用の入力（送信）システムを構築する場合、災害時において防災担当職員は複数の情報伝達手段への入力作業が必要となり、情報伝達業務が増大することにつながるため、近年市町村で導入されている一斉送信シ
ステムなどから、統合運用調整機能（バックエンド機能）（後述（２）を参照。
）
に対して、EDXL を生成し連携することが効果的である。
（ワンソース・マルチ
ユースによる最適化）
実証では、一斉送信システム）と連携し、情報伝達が可能であることが確認されている。また、市町村防災行政無線（同報系）と一斉送信システムとを連携させ、防災行政無線の操作端末から発信された災害情報を、一斉送信システムを経由して FAX や一斉架電システム、登録制メールと連携させている場合があり、実証においても入力システムとして利用するのではなく、連携インターフェイスとして活用し、防災行政無線からのテキストや音声を自動的に取得する検証-5-

を行い、擬似的な検証環境において連携可能であることが確認されている。このことから、既存の防災行政無線を活用し、一斉送信システムを連携させることにより、モデル実証で確認されたような情報伝達方法を導入することも可能である。
一方、EDXL において記述可能な項目は多岐にわたるが、既存のクラウド型の一斉送信システムの多くは、全ての EDXL の記述項目に対応していないことから、本手段の機能を十分に活かすためには、既存の一斉送信システムにおいて入力項目を追加する等により EDXL に対応させること、又は EDXL 対応に最適化された入力システムを利用すること等が必要となる。
（２） 統合運用調整機能（バックエンド機能）
統合運用調整機能（バックエンド機能）は、指定の地上デジタル放送事業者に対して EDXL を伝送するメッセージルーティングを行い、情報が適切に送信されたことを市町村の入力（送信）システムに返却するものであり、情報セキュリ
ティに必要となる、認証（市町村からの送信であるという真正性の確認）、認可（アクセス権限の確認）、アカウンティング（市町村からの送信履歴等の収集）を含む情報交換網の中核を担うものである。入力（送信）システムから災害情報を受信し、受信した EDXL についてバリデーションチェック（入力されたデータが入力規則に対して適切に記述されているかを確認すること。
）を行い、電子署名の真正性を確認した後、放送局内のＩＰＤＣ連携装置に配信する。
複数の市町村からの情報発信を受信し、複数の放送事業者に対してルーティ
ングを動的に最適化するための重要な役割を担う。
また、隣接する自治体において、統合運用調整機能（バックエンド機能）を提供する事業者が異なる場合は、必要に応じ、それぞれの自治体からの要請を踏まえ連携を図る。
統合運用調整機能（バックエンド機能）は、以下の機能を担う。
ア 電子署名の証明書の認証局機能
市町村から発信される災害情報が記載された EDXL には、真正性を担保し、なりすましを防止するために電子署名（XML 署名）を付すことが必須とされ、必ず市町村の電子署名が付されることから、統合運用調整機能（バックエンド
機能）は、その電子署名に必要なクライアント証明書の発行・管理を行う機能を有している。

イ ID 発番・管理
統合運用調整機能（バックエンド機能）は、複数の入力システムから EDXL
を受信することが想定されることから、管理に必要となる ID を一意とするため、ID の発番・管理を行う機能を有している。この機能により、複数の市町-6-

村からの災害情報や添付された音声ファイルをシステム全体で一意に取り扱うことが可能となり、ログ管理が可能となる。
ウ 優先順位制御
受信した情報を優先基準に基づき順序を入れ替えて配信する機能を有している。具体的には、国民保護情報や津波警報等、緊急度の高い情報を他の配信
情報よりも優先して配信する等の機能がある。
エ メッセージルーティング
入力（送信）システムから受け取った災害情報を指定する放送事業者に対して送信する（ルーティングする）機能を有している。
オ メッセージキューイング
入力（送信）システムから受け取った災害情報を放送事業者に「確実に」、「重複することなく」、「順序通りに」届ける非同期の機能を有している。
※

メッセージキューイングとは、機器やプログラムの間でデータの受け渡

しを非同期に行う手法をいう。
カ ログ管理
市町村からの情報発信、放送事業者からの放送、屋外同報系装置・屋内受信機での受信などのログを全て収集管理する。

（３） テレビ局マスター設備
地上デジタル放送局内では、統合運用調整機能（バックエンド機能）から送出された EDXL で記述された災害情報を、放送事業者の基幹放送設備に接続する
ＩＰＤＣ連携装置において、IP パケット（UDP/IP）化し、TS（トランスポー
トストリーム：放送用のコンテナ形式）に変換し、多重化装置に出力し、地上デジタル放送波に重畳する。
ア ＩＰＤＣ連携装置
ＩＰＤＣ連携装置は、主として以下の機能を有する。
① 情報入力部
統合運用調整機能（バックエンド機能）とのインターフェイスを担う機能であり、統合運用調整機能（バックエンド機能）を有する機器との接続は
災害時においても信頼性が高く（回線の完全２重化）、高セキュリティの通信回線（閉域網）を用いることが重要である。入力された災害情報をそのまま②情報処理部に出力する。

-7-

②情報処理部
入力された災害情報を地上デジタル放送波に重畳するために必要なＩＰＤ
Ｃ型データ放送用 TS に変換し、情報送出部に送出する。
③情報送出部指定されたタイミングで基幹放送設備へ情報を送出する（原則は即時送出）。
④運行執行部
上記①から③の運用状況を監視できる機能を有しており、どの市町村からどのような情報が放送されたかを確認できる機能を有している。
イ 多重化装置
多重化装置では、ＩＰＤＣ連携装置から送出されたＩＰＤＣ型データ放送用
TS を本放送（テレビサービス用 TS）に重畳し、放送される。その際、多重化装置のいくつかの設定値の変更が必要となる。
（４） 屋外スピーカー・屋内受信機
防災行政無線と同様に、音声等により住民へ災害情報を伝達する設備・機器であり、ＩＰＤＣ型データ放送を受信して、EDXL に記述を解釈し、音声鳴動、文字表示等を行う。
地上デジタル放送波は広域の電波であることから、市町村の災害情報（EDXL）を載せたＩＰＤＣ型データ放送は、他の市町村の屋外スピーカーや屋内受信機においても受信されることとなるが、受信機に設定された自治体コードとＩＰ
ＤＣ型データ放送により送信された EDXL の自治体コードが一致しない限り動
作しないため、他の市町村が設置した屋外スピーカーや屋内受信機（異なる自治体コードで設定したもの）が音声鳴動すること等は生じない。
また、EDXL の活用により、受信機のファームウェアアップデートが可能である。EDXL には、受信機の設定情報の更新等、ファームウェアアップデートを行
うための仕様が定義されており、地上デジタル放送波に重畳することで遠隔でシステムアップデートが可能となる。後述（５）アのアンサーバック機能と組み合わせることで、製品の不具合改修、機能改善等に活用することが可能で、ソフトウェアを随時アップデートすることで、システム全体の運用寿命を延ばすことが可能となる。
ア 屋外スピーカー
屋外スピーカーは、市町村防災行政無線（同報系）等と同様に、受信部、屋外スピーカー、非常電源、鋼管柱等から構成される。
受信部を地上デジタル放送波に対応した機器に交換することで既存の屋外ス
ピーカーを活用することも可能である。
-8-

イ 屋内受信機
屋内受信機については、防災行政無線の戸別受信機と同等の機能を有する必要がある。具体的には、平成 30 年 3 月に公開された「防災行政無線等の戸別受信機の標準的なモデル等のあり方に関する検討会報告書」にある「標準的なモデルの機能一覧」をベースに、ＩＰＤＣ型データ放送の特性を加味して技術的要件を整理する。


音声受信：音声放送の受信

緊急一括呼出：緊急時に音量を自動で最大に調整（緊急事態を知らせる機能）

選択呼出：一括呼出、グループ呼出、個別呼出

録音再生：放送の録音再生が可能



停電時対応：商用電源から内蔵の電池へ自動切替



内蔵電池の動作時間：24 時間以上（例：放送５分／待受け 55 分の条件）

外部アンテナ接続：外付けのアンテナが接続可能

受信機の状態を表示できる機能（５） その他の追加的な機能
EDXL が情報受信者（Recipient）
・情報消費者（Consumer）の属性に応じて、伝達内容を記述した表現形を多様な体現形に変換することができるため、災害情報の伝達における様々な場面や情報消費者への幅広い応用が可能となる。実証で実施した内容を中心に追加的機能を以下に示す。
ア アンサーバック
LPWA 等の通信網を利用することで、アンサーバックを行うことができる。
アンサーバックは以下の２種類に大別することができる。
①

状態通知・変化／エラー通知
定期的（３時間に１回、１日に１回等）に受信機側から機器の状態や異常の有無、電波の受信感度などの情報を統合運用調整機能（バックエンド機能）に回答する。
なお、状態通知のアンサーバックを活用して、市町村の情報伝達手段の管理
PC や警告灯等で機器の異常を通知することや、受信機の保守事業者に連絡することも可能である。
②

指示応答／アンケート回答受信した EDXL に報告要求が記述されていた場合、受信機側から統合運用調整機能（バックエンド機能）に対して受信状態を応答する。また、受信した-9-

EDXL にアンケート要求があり、情報消費者が受信機の操作によって、回答した内容を応答する。
（参考）
実証では LPWA（Low Power Wide Area network：低消費電力で長距離の通信ができる無線通信技術）の１つである Sigfox を用いてアンサーバックを行ったが、他の事業者が提供するＬＰＷＡ網や、他の通信網を活用してアンサーバックを行うことも可能である。

イ 多言語対応
EDXL は、１つの伝達文に複数の言語表現（テキスト・音声）を含めて記述することが可能となっており、受信機側の言語設定に応じて指定された言語で音声放送・テキストの表示を行うことができる（イメージは図３を参照。）。
多言語の音声やテキストデータは、あらかじめ市町村で用意するか、又は多言語翻訳機能（テキストからの自動音声合成を含む。
）を有するシステム等を利用することが考えられる。

図 3 多言語対応のイメージ（右写真は屋内受信機（試作機）の言語設定画面）- 10 -

ウ 聴覚に障害のある住民への情報伝達
EDXL を活用することにより、聴覚に障害のある住民用の屋内信号装置と屋内受信機を協調して動作させることができる。
（参考）
実証では、屋内信号装置として一般に使用されている Bellman & Symfon®のベルマンビジットシステム（マルチセンサ発信機、フラッシュ受信機、ベッドシェーカー）との連携が可能であることが確認された。屋内受信機と屋内信号装置が連携し、屋内受信機の受信情報を光・振動に変換することが可能である。
具体的な設定方法としては、屋内受信機とマルチセンサ発信機を 3.5 ㎜ステレ
オミニプラグ付きのオーディオケーブルで接続し、マルチセンサ発信機はフラッシュ受信機と無線通信を行い、フラッシュ受信機とベッドシェーカーを配線接続した。
（接続イメージは図４を参照）

図 4 屋内受信機とマルチセンサ発信器等との接続イメージ（右写真は、実証で設定した際の状況）

エ コミュニティ FM との連携
屋内受信機にラジオ機能が備わっている場合は、地上デジタル放送波で特定の日時に特定の周波数（臨時災害放送局の周波数）に同調してラジオを起動することを記述した EDXL を放送し、指定日時に自動的に屋内受信機のラジオ機能から臨時災害放送局等の放送を受信することができる（図５参照。
）。
地上デジタル放送（広域の情報）と臨時災害放送局（狭域の情報）が連携することで、災害時に、住民に対して、より細やかな情報を伝達することができる。
インターネットが利用不能な状態においても、市長のメッセージや医療情報、罹災証明書発行、給水や炊き出しなどを住民に伝達する手段として有効に利用することが考えられる。

- 11 -

図 5 コミュニティ FM との連携のイメージ（右写真は、コミュニティ FM の周波数に自動で設定されている状況）

オ デジタルサイネージ等との連携
民間企業等が設置・運用しているデジタルサイネージやテレビに対して、市町村が伝達する災害情報を表示させることができる（図６）。
デジタルサイネージディスプレイに HDMI の空きポートがある場合、ディスプレイに EDXL を体現すること（表示すること）ができるアプリケーションを搭載した受信機とディスプレイとを直接接続する（図７）。ディスプレイに空きポートがない場合、HDMI 切替機を接続する（図８）。受信機がデジタルサイネージに対して災害情報を表示する際、表示切り替え指示をサイネージ制御装置
側に送り、サイネージ制御装置がパネルの表示切り替え制御を行うことで災害情報を表示する。HDMI 切替機を挟む場合、HDMI 切替機の機種によっては、制御が効かないことがあるので留意が必要である。
また、高機能な HDMI 切替機を用いて、ディスプレイの制御権をやり取りすることにとどまらず、既存のディスプレイ上の表示画面にオーバーレイやワイプの画面表示で場所や場面に応じた表示を行うことができる（図９）。
導入にあたっては、民間施設のデジタルサイネージの表示面の一部又は全部を、どういう状況下において、市町村からの災害情報を表示するのか、どういう状況において、元に戻すのかについて、予め自治体とサイネージを管理する民間事業者との間で調整が必要となる。

- 12 -

【今後の可能性】
民間施設においても、災害が発生した場合、施設管理者において当該施設に滞在する者の避難誘導等、在館者の安全を確保する取組みが行われる（消防法令に基づき、防火管理者や防災管理者が選任されている場合は、防火・防災管理業務の一環として避難誘導等が行われる。
）
そのため、受信機が受信した市町村からの災害情報を自動的にデジタル
サイネージに連携するだけでなく、施設管理者の判断によって伝達のタイ
ミングや内容を適宜コントロールする機能が必要となる場合が考えられ、今後、そのコントロールを含めて高機能な HDMI で制御することが可能となることが見込まれる。

図 6 デジタルサイネージへの災害情報の表示
右写真：軽井沢町での実証の例
左写真：中央区での実証の例

図 7 サイネージパネルに空きポート

図 8 HDMI スイッチャーを接続するがある場合の論理構成

場合の論理構成- 13 -

テロップの表示

図 9 既存のディスプレイ上の表示画面にテロップ（画面下部分）を表示した状況

カ 避難所の解錠
EDXL を用いて、避難所の鍵ボックスの解錠・施錠を行うことができる。
「災害情報伝達手段等の高度化事業」を通じて、兵庫県加古川市においては、
既に導入されている（加古川市に設置されている避難所の鍵ボックスは図 10 を参照。
）。
一般には、避難所の開設は、市町村職員が避難所へ行き、解錠等を行っている
が、EDXL 及びＩＰＤＣ型データ放送を活用することで、遠隔で鍵ボックスを解錠し、避難した住民が解錠・施設内に避難することができる。

図 10 避難所の鍵ボックス
キ 避難者の行動捕捉
屋内受信機に Bluetooth 通信機能が搭載されている場合、屋内受信機とBluetooth 検知器や Bluetooth 通信検知アプリを搭載したスマートフォンを用いて、避難者の行動を捕捉し、市町村庁舎（災害対策本部等）で管理 PC の地図上で確認することができる。現状では、この機能の導入に当たっては、民間事業者のサービスを利用することが考えられる。

- 14 -

（参考）実証では、みまもりタグの仕様に従って、Bluetooth のビーコンを屋内受信機
から発信し、ALSOK の「みまもりタグ感知器」や ALSOK のスマートフォンア
プリで Bluetooth を検知し、「みまもりタグ検知器」の設置場所情報やスマートフォンの GPS 位置情報から避難者の行動を捕捉することができる。
（図 11）

屋内受信機のボタンを押下して、避難所への避難等の意思を市町村へ伝達

屋内受信機を持って避難所へ避難Bluetooth 検知器の例

みまもりアプリの例

Bluetooth 検知器と屋内受信機との通信により、避難者の行動を捕捉

市町村（災害対策本部）の管理 PC の地図上で避難者の行動を把握

図 11 実証で実施した避難者行動の捕捉イメージ- 15 -

ク FM トランスミッター装置との連携
屋内受信機と FM トランスミッター装置を連携させることで、地上デジタル
放送波を用いて屋内受信機で受信した音声ファイルを FM トランスミッター装置で情報伝達することができる。
想定される利活用シーンとしては、避難所の屋外で車両に避難している住民
への FM ラジオを用いた情報伝達、避難所内で掲示板やデジタルサイネージだ
けでなく、音声による情報伝達等が考えられる。
これらは、EDXL を用いてプログラムすることで可能となり、災害時の様々な場面で、ツールを組み合わせて住民への情報伝達が可能となると考えられる。

（参考）EDXL の応用例として「メッセージフェリーデバイス」の利用
インターネットが使用できない状況下であっても、災害対策本部と避難所との間でデジタル情報の交換を行う場合に、DTN（Delay Tolerant Networking:遅延耐性ネットワーク）環境を構築し、「メッセージフェリーデバイス」を用いることで、交換する情報を EDXL で記述した上で「メッセージフェリーデバイス」に載せ、「メッセージフェリーデバイス」同士が近づくだけで何ら操作がいらずに情報を伝搬することができる。

ケ J アラート連携
J アラートとの連携も可能である。J アラート受信機と入力システムを接続すること等により、J アラートで配信される国民保護情報や津波情報等の災害情報を伝達することができる。

（参考）J アラート連携の具体的な事例
兵庫県加古川市において、J アラート受信機のイーサネットで接続したシング
ルボードコンピュータで EDXL を生成し、バックエンドに連携することで、J ア
ラートで配信される国民保護情報や津波警報等の災害情報を地上デジタル放送
波に重畳することとしている。

- 16 -

３ 情報伝達システムの標準とするべき技術的要件について
上記１及び２で示した実証から得られた技術的知見を踏まえ、本項においては、本手段の中核となる技術・機器について標準とするべき技術的要件を提示し、これに準拠したシステムや機器等を市町村が調達することで事業者間の競争性を確保することが期待されるものである。システム全体としての共通的動作を保証しつつ、サービ
ス・機器提供事業者間の競争性を確保する観点から、以下の①から③を満たす必要がある。
① 受信機は市町村で共通に使用できなければならない
テレビ受像機製品と同様に、ベンダー（メーカー）を問わず、災害情報伝達の仕組みとしての基本的機能が保証され、全国すべてのテレビ局（放送事業者）の電波を受信し、共通的に動作しなければならない。受信機は、市町村コードを設定することで、すべての市町村を個別特定して利用できなければならない。
② 空中波直接受信、再送信受信にかかわらず動作する
再送信については同一周波数パススルー方式、周波数変換パススルー方式に対応しなければならない。周波数変換パススルー方式の場合、UHF 帯以外の帯域（CATV 帯域）にも対応しなければならない。
③ 市町村が複数の放送事業者、サービス提供事業者等から調達しても統一した動作が保証できる
分割調達や複数年度にまたがる調達によって、複数の事業者の製品が混在していても、相互運用することができなければならない。
また、ｍ：ｎモデルにおいては、輻輳する恐れがあることから、IPDC 方式が蓄積型放送である特性を踏まえつつ、輻輳による情報発信から受信機動作までの時間が一定以内に収まるよう、以下の④及び⑤を満たす必要がある④ 市町村が生成する災害情報を記述した音声ファイル等のデータ量の上限（下記（参考）を参照）について、事前に市町村相互で運用ルールを定めなければならない。
⑤ 回線の圧迫を緩和する目的で、可能な限り情報発信のタイミングをずらすため、
市町村相互での情報発信のタイミングの事前共有等の運用ルールを定めなければならない。
本システムは、災害情報を伝達するための手段であり、安定的かつ継続的に運用されることが重要であることから、次の⑥から⑧に留意する必要がある。
⑥ 受信機において再生される音声品質は、確実な災害情報伝達のため、市町村防
災行政無線（同報系）と同等以上の音質を確保しなければならない。

- 17 -

⑦ 地上デジタル放送事業者においては、災害情報伝達のために利用を許諾したデータ放送帯域、及び当該帯域に重畳する音声ファイル等のデータ量の上限に基づき、当該帯域を共用する市町村数に上限（下記（参考）を参照）を設け、サービス品質を確保しなければならない。
⑧ 地上デジタル放送事業者においては、災害情報伝達のために供出するデータ放
送帯域は、商業利用も含めた他の用途にも利用されるものであるが、市町村からの災害情報が送信された際は、市町村との契約に基づき、当該データ放送帯
域において、優先的に災害情報を放送すること。
そしてその満たすべき技術的要件を（１）から（７）までまとめる。なお、以下の技術的要件を満たすシステムや機器等が、追加的機能を搭載することを制限しない。
また、１で述べたように、市町村における本手段の整備においては、災害情報交換
言語として EDXL を採用することを標準の要件とし、サービス・機器提供事業者毎に仕様が異なることにつながりやすい屋内受信機等の仕様について、標準仕様に準拠した製品を調達することが重要である。
（参考）市町村数の上限等について
複数の市町村が同一の放送事業者の帯域を利用する場合における市町村数の上限
等は、放送事業者が提供する帯域に応じて主に下記の要素で決定される。
・聞き取りやすい一定の音質・音声データファイルの符号化方式
・データファイルの圧縮比率（非圧縮ファイルサイズに対する圧縮後のファイルサイズ）
・受信障害対策のための方策（FRUTE/AL-FEC 送出機能の仕様）
・連続送信間隔（１） 基本的な要件
情報伝達システムの各構成要素（入力（送信）システムから地上デジタル放送
設備を経由して受信機に至るまでの情報伝達経路）について、異なる放送事業者、
サービス提供事業者等であっても容易に災害情報の伝送、設備・機器の接続・動作が可能となるよう EDXL を利用でき、確実に動作するものとすること。各構
成要素の一部に EDXL を利用できない要素が含まれる場合、本ガイドラインにおける標準とするべき技術的要件に準拠したシステムではない。
本手段の特徴的な技術は、災害情報交換言語 EDXL であり、EDXL が標準定義フォーマットに基づき記述され、情報伝送されることにより、屋外スピーカー、
屋内受信機のみならず、他の IP 端末との連携も可能となる。
（EDXL の標準定義
フォーマットは別添資料に示す。
）- 18 -

また、入力（送信）システムから受信機までを一つのシステムと捉え、セキュリテ
ィの３要素（機密性、可用性、完全性）の確保を含め、システム全体におけるセキュ
リティを担保しなければならない。

（２） EDXL の標準仕様について
地上デジタル放送波を活用した災害情報伝達手段では、情報交換言語として
EDXL を用いて災害情報を伝送する。ＩＰＤＣ型データ放送の特徴の一つとして、情報の伝送が容易であることを示したが、その利点を最大限に活かすため、伝送路や周波数帯、ネットワーク、ハードウェアに依存することなく、オープンで柔軟な情報交換言語を採用する。
（参考）EDXL と４ロールモデル
地上デジタルテレビ放送は原則として、情報発信者と情報伝達者が必ず一致し、放送局は放送内容から送信まですべての責任を負う。地上デジタル放送波を活用した
ＩＰＤＣ型データ放送では、情報発信者は市町村であり、市町村から災害情報配信の放送データ重畳委託の契約を根拠として、放送法等関係法令の規定を踏まえ、市町村の災害情報を放送することとなる。
また、地上デジタルテレビ放送は、「公衆によって直接受信されることを目的とす
る電気通信の送信」であり、テレビ放送は一般社団法人電波産業会（ARIB）で標準化されたテレビ受像機にて受信され、「公衆」がその情報を受け取ることとなる。地
上デジタル放送波を活用したＩＰＤＣ型データ放送の場合、防災行政無線と同等の機能を有するために必要となる基本的な動作を行うためのアプリケーションを標準化しつつ、その他多様な機能やサービスを実装した受信機が出現する可能性がある。
先例としては、「災害情報伝達手段等の高度化事業」における V-Low マルチメディア
放送において、EDXL を用いて避難所の鍵ボックスや避難階段の照明に対する操作が可能となった。
地上デジタル放送波を活用した災害情報伝達手段に用いる EDXL においては、テレビ放送とは異なる属性に対して役割を定義する必要があり、それを 4 ロールモデ
ルとして定義している。
それぞれの期待される役割等は EDXL の中に「originatorRole」「senderRole」「recipientRole」「consumerRole」として記述されている。

- 19 -

図 12 EDXL における４ロールモデルのイメージ① 情報発信者（Originator）
意味を記述する主体。入力（送信）システムを利用し、1 個の表現形として様々な体現形に変換可能な EDXL を生成し、情報伝達者（Sender）にむけて、情報送信を依頼する。
② 情報伝達者（Sender）
情報発信者が制作した表現形のコンテンツを受領し、公衆たる情報消費者に向けて配信する。ルーティング・アカウンティング・優先順位制御・ログ管理・送出等を担う。放送法において放送番組編集の自由を定め、放送事業者は、この枠組みの中で、自主自律の下、自らの責任において放送番組を編集し、市町村との契約に基づいて、適法に情報を送出する。
③ 情報受信者（Recipient）
EDXL を受信・解釈する機器。表現形である EDXL を情報消費者属性に応じて様々な形態で提供（体現形）する。例えば、「音声を再生する」「デジタルサイ
ネージに文字情報を表示する」「鍵ボックスを解錠する」等で表現された EDXLを解釈し、その表現のとおり動作等を行う。
④ 情報消費者（Consumer）
動作を「期待」される人・モノ（公衆）。情報受信者によって体現された情報を受け取り、避難行動を取ったり、避難所の鍵が開いたりする。

- 20 -

（３）入力（送信）システム
入力（送信）システムは以下アからウの要件を満たさなければならない。エについては市町村が必要と判断した場合、対応しなければならない。
ア EDXL を生成すること
入力（送信）システムに入力された災害情報から EDXL を生成し、電子署名の証明書の認証局機能及びメッセージルーティング機能が要求するプロトコル
で連携する機能を有すること。その際、統合運用調整機能（バックエンド機能）
から都度、ID が発番されるので、その発番された ID を利用しなければならない。
イ 電子署名をつけること
情報の改ざん防止と発信者の同一性を担保するため、電子署名（XML 署名）をつける機能を有すること。なお、デジタル証明書を発行する認証局については特に指定しない。
ウ 統合運用調整機能が要求するプロトコルで連携できること
電子署名の証明書の認証局機能及び放送事業者間のメッセージルーティング
機能等を提供する統合運用調整機能（バックエンド機能）が要求するプロトコル
で連携する機能を有すること。

（市町村において必要とする場合の追加的な機能）
上記アからウまでの標準仕様に加え、市町村において、モデル検証で実施した多様な情報伝達方法を導入するため、次の機能を追加することが考えられる。
エ J アラート連携
市町村が必要と判断した場合、J アラート受信機と連携し、国民保護情報や大津波警報等の情報を EDXL 化し、統合運用調整機能（バックエンド機能）へ連携しなければならない。
ただし、J アラートは、その情報の特性上、広範囲（県域または複数の都道府県に跨って）を対象に発令されることが多い。その際、一つの放送事業者に対して複数の市町村が、同じ内容の放送要求をほぼ同時に行った場合、放送事業者はそれらの放送要求に対して一つずつ先着順に、放送を行っていくため、順番の遅い市町村の情報発信に遅れが出る可能性がある。このような遅延を防止するため、地上デジタル放送の県域または広域圏を放送対象地域とする特性を活かし、同一内容の放送を一つずつ先着順に放送するのではなく、一回の放送で、県域または広域圏に情報発信するなど、関係者間においてあらかじめ運用に関する取り決めを行っておくことが重要である。
- 21 -

（４）統合運用調整機能（バックエンド機能）
統合運用調整機能（バックエンド機能）は、ｍ：ｎモデルに必須の機能であり、
以下４項目の要件を満たさなければならない。
ア 電子署名の証明書の認証局機能の提供
統合運用調整機能（バックエンド機能）は、EDXL に付すべき電子署名（XML署名）に必要なクライアント証明書の発行・管理を行う機能及び外部の認証局機
能との連携機能を提供しなければならない。
イ 優先順位制御機能の提供
市町村から受信した災害情報の情報種に応じて、放送事業者への連携優先順位を制御する機能を有すること。情報種ごとの優先順位については市町村と協議の上確定すること。また、複数の市町村の情報を取り扱う際には、関係する市
町村間においてあらかじめ運用に関する取り決めを行わなくてはならない。
ウ メッセージルーティング機能の提供
入力システムから受け取った災害情報を、指定する放送事業者に対してルー
ティングする機能を有すること。
複数の市町村、複数の放送事業者間におけるルーティングは、放送事業者の放送休止期間やＩＰＤＣサービスを提供できない時間帯に対してのルーティング
先の切り替え等の処理だけでなく、ルーティングテーブルを最適化してシステ
ム全体に通知する機能を有すること。
エ メッセージキューイング機能の提供
放送事業者（ＩＰＤＣ連携装置）に対しメッセージキューイング機能を提供し、市町村の災害情報を連携しなければならない。

（５）ＩＰＤＣ連携装置
設備は、放送事業者のマスター設備内に設置する。機能要件としては以下２項目の要件を満たさなければならない。
ア 統合運用調整機能（バックエンド機能）とのインターフェイス機能の提供
EDXL を受信し、電子署名の検証機能を有するとともに、必要に応じて、送出を停止する機能を有すること。

- 22 -

イ FLUTE / AL-FEC 送出機能の提供
ｍ：ｎモデルの運用に対応するため、適切に EDXL を FLUTE / AL-FEC に変
換し TS に重畳して送出する機能を有すること。放送局間で共通する運用規定を定めて受信機能と同期して安定かつ確実な動作が保証できること。

（６）受信機の標準仕様
受信機の標準的な仕様については、市町村防災行政無線（同報系）の戸別受信機の標準モデル機能を踏まえ、以下アからコの要件 10 項目を満たさなければならない。サからソの 5 項目については市町村が必要と判断した場合、対応しなけ
ればならない。なお、受信機については高齢者等の操作も想定して、操作性は簡易であることが望ましい。
ア 音声受信：音声ファイルの受信
地上デジタル放送波を受信し、ＩＰＤＣ型データ放送に重畳された EDXL データを解析し、格納された音声ファイル（市町村からの災害情報）をスピーカー
にて聞くことができる機能を有すること。特に、EDXL に含まれる自治体コード、エリア ID、グループコードを識別し、適切に動作をする機能を有しなければならない。
また、市町村が必要と認めた場合、アンサーバック機能を提供しなければならない。
イ 緊急一括呼出：緊急時に音量を自動で最大に調整（緊急事態を知らせる機能）
緊急一括放送を受信した場合、受信機の音量設定に関係なく、当該受信機の最大音量で放送内容を聞くことができる機能を有すること。
ウ 選択呼出：一括呼出、グループ呼出、個別呼出
地区単位やあらかじめ設定したグループ（消防団や高齢者世帯、土砂災害警戒区域内にある世帯等）に対する放送（グループ呼出）や、特定の屋内受信機だけを鳴動させるような放送（個別呼出）に対応できる機能を有すること。
エ 録音再生：放送の録音再生が可能
内蔵メモリ等により放送内容を録音かつ再生できる機能を有すること。
オ 停電時対応：商用電源から内蔵の電池へ自動切替
通常は商用電源で運用していて、停電時等に内蔵の電池（乾電池やリチウムイ
オン電池、ニッケル水素電池等）に自動で切り替わり、停電時等の放送を聞き漏らさないようにする機能を有すること。
- 23 -

カ 内蔵電池の動作時間：24 時間以上（例：放送５分／待受け 55 分の条件）
停電時等に内蔵電池での運用に切り替わった際に、内蔵電池において 24 時間
以上の運用・動作を可能とする機能を有すること。
キ 外部アンテナ接続：外付けのアンテナが接続可能
屋内受信機を設置する住戸に設置されているテレビコンセント（地上デジタ
ル放送を受信するためのコンセント）に接続するための端子（コネクタ等）を有し、接続すると自動でテレビコンセントからの受信に切り替わる機能を有する。
屋外において、地上デジタル放送波（空中波）を受信するための本体付属のアンテナを有すること。
ク 受信機の状態を表示できる機能
電波の受信状況、待受状態、録音状態等の受信機の状態を表示できる機能を有すること。
ケ 時刻同期及び保持機能
放送により蓄積された情報を EDXL の内容により時刻指定再生などが可能になるよう時刻を取得し保持できる機能を有すること。
コ ｍ：ｎモデルへの対応機能
統合運用機能と連携して m:n モデルの運用に対応できること。放送によりス
ケジュールされた放送局切り替えや自律的に市町村コードにより特定される放送役務へ自動同調する機能を有すること。
（市町村において必要とする場合の追加的な機能）
上記アからケまでの標準仕様に加え、市町村において、モデル検証で実施した多様な情報伝達方法を導入するため、次の機能を追加することが考えられる。
サ FM 放送を受信するための機能
FM 放送（76.0MHz～108.0MHz）を受信し、内蔵するスピーカーにて放送内容を聞くことができる機能を有し、EDXL を解析するソフトウェアと連携して FM
受信機能を制御できること。
シ LPWA 通信を行うための機能
屋内受信機の受信状況や作動状況の確認等を行うアンサーバック機能に用いるため、LPWA（Low Power Wide Area）の通信網と通信ができる機能を有すること。

- 24 -

ス Bluetooth 通信を行うための機能
屋内受信機の位置を追跡し、動態把握等を行うため、Bluetooth により通信ができる機能を有すること。
セ 光により受信したこと等を示すための機能
LED 等が設けられ、屋内受信機が放送を受信したことを光の点灯や点滅で知らせるための機能を有すること。
ソ 外部機器と接続するための機能
聴覚に障害のある住民に屋内受信機を配備する場合に、フラッシュ受信機や振動により気づきを与える機器との接続や、放送内容を表示するデジタルサイ
ネージやテレビ等との接続ができるよう、外部機器と接続するための端子を有すること。

- 25 -

４ 導入に当たっての留意事項
市町村が地上デジタル放送波を活用した災害情報伝達手段の導入について検討する場合、まずは当該市町村管内に地上デジタル放送を提供する放送事業者とＩＰＤ
Ｃ型データ放送の利用が可能かについて協議を行うことが必要となる。放送事業者との協議が進んだ場合、入力システムの検討、サービス提供事業者の選定・調達、屋
外スピーカーや屋内受信機の調達・整備等の情報伝達システムの整備を進めていくこととなる。
このような地上デジタル放送波を活用した災害情報伝達手段の導入検討に際して、実証で得られた知見等から主な留意事項を以下に示す。なお、屋外スピーカー及び屋
内受信機を活用した同報系システムの整備を念頭に置いており、LPWA 網やBluetooth 検知など拡張的な機能の導入は含めていない。
また、放送事業者においては、運用開始までに管轄の総合通信局等へ電波法、放送法等に係る事業計画の変更届出が必要となり、設備の変更が必要な場合は、電波法に係る変更許可の申請が必要となる。
（１）入力（送信）システムの検討・導入
入力（送信）システムは、EDXL を作成・送信できる機能があれば、一斉送信システムや既存の災害情報システムを利用することが可能である。一斉送信シ
ステムを利用する場合、標準定義フォーマットに準拠した EDXL の利用が可能であるか、作成・送信できる EDXL に制限があるかどうかを確認しておく必要がある。
（参考）他の同報系システムを既に整備している場合に屋内受信機の配備やデジタ
ルサイネージとの連携等のために本手段を補完的に利用する場合の応用例
既に市町村防災行政無線（同報系）等の同報系システムを整備している場合であって、本手段の屋内受信機やデジタルサイネージ等との連携等の情報伝達を補完的に利用するニーズがある場合、既存の同報系システムに一斉送信システ
ムを連携させることにより、一斉送信システムを連携インターフェイスとして用いて EDXL を自動作成させ、統合運用調整機能（バックエンド機能）への情報伝送が可能である。
これにより、従来と同じように、使い慣れた同報系システムの操作卓を利用して、ＩＰＤＣ型データ放送の利用が可能となる。
（２）サービス提供事業者との利用契約
現状では、市町村とサービス提供事業者との間で、統合運用調整機能（バックエンド機能）を用いて、ＩＰＤＣ型データ放送に重畳するための災害情報を記述した EDXL 伝達文を指定の放送事業者に伝送するサービスの利用契約を結ぶ必要がある。
統合運用調整機能（バックエンド機能）の利用契約に当たり、仕様書には、次- 26 -

の要件が満たされているか確認すること。
ア サービス要件
24 時間 365 日サービス提供が可能で、稼働率 99％以上を確保すること。ただし、システムメンテナンス等による停止は除く。システムメンテナンスは、
事前に日時を通知し、台風や大雨等、災害の発生が予測される時には実施しない。
イ データセンターの要件
・国内のデータセンター内に構築したシステムによる SaaS（Software as aService）方式とする。
・データセンターは、情報セキュリティマネジメントシステムの規格である
JIS Q 27001

又は ISO/IEC 27001 に基づく認証を取得していること。

・データセンターは、土砂災害特別警戒区域や浸水想定区域などの危険区域に存在しないものとすること。
（危険区域に存在する場合は危険性に応じた必要な対策が講じられていること。）
・データセンターは、建築基準法に規定する耐火建築物で、耐震性に優れ、必要な防火対策・雷対策が講じられているものとすること。
・データセンターへの出入りは常駐警備による入退室管理が 24 時間 365 日実施され、入室セキュリティは３段階以上とすること。
・回線・設備機器が冗長化されており、障害発生時にも通信が可能であること。
ウ システムセキュリティ要件
・データベースのデータはバックアップを行っており、２拠点以上のデータセンターに保管すること。
・システム稼働状況を 24 時間 365 日監視し、異常を検知した場合には、関係者に緊急連絡が行われ、障害復旧に当たる体制を整えていること。
・データの保管や持ち出しに対し、機密保持対策が講じられ、外部からのサイバー攻撃対策やウイルス対策が実施され、常に最新の監視状態に維持されていること。
（３）ＩＰＤＣ連携装置の設置及び基幹放送設備との接続利用しようとする放送事業者の放送局内にＩＰＤＣ連携装置が未設置の場合、
ＩＰＤＣ連携装置の設置及び基幹放送設備との接続が必要となる。
費用負担については、市町村及び放送事業者との間で調整が必要となるが、地上デジタル放送波の特性から、複数の市町村が１の放送事業者の放送波を利用することも可能であることから、都道府県も含めた関係機関で検討することが望ましい。

- 27 -

（４）地上デジタル放送事業者との利用契約
災害情報をＩＰＤＣ型データ放送に重畳して放送することについて、市町村と地上デジタル放送事業者との間で事前協議を行い、利用契約を結ぶ必要がある。
利用契約には、次の事項について相互に確認しておくことが望ましい。
•

市町村が住民へ伝達する災害情報の放送データを制作して、これを放送事業者の放送設備（多重化装置）に入力し、当該放送データを放送事業者の放送帯域に重畳して配信することの確認•

放送データを重畳して配信するための利用料の確認•

市町村において使用する入力（送信）システムや、ＩＰＤＣ型データ放送を受信する機器（屋外スピーカー、屋内受信機、避難所の鍵ボックス等）の確認•

放送事業者は、放送法及び電波法その他関連法令を遵守し、自主自律の下、自らの責任において放送番組の編集ができることの確認•

当該帯域において、平時に災害情報以外の情報を配信するサービスの契約を行う場合は、有事の際に災害情報の配信を優先するため、災害情報以外の情報の配信を中止する可能性があることの確認•

災害情報の内容に誤りがあることが判明した場合、市町村は直ちにその責任において修正を行うこととし、修正を行う場合は、予め放送事業者にその旨を事前に通知することの確認（緊急を要する場合は、事後報告とすることができるかについても確認しておくことが望ましい。）。

•

放送休止時間や放送事業者が放送役務を実施できない状況下（中継局の保守作業や機材メンテナンスの実施中の場合や、災害・事故等による障害が放送設備に発生した場合等）における免責等についての対応についての確認もし、ひとつの放送事業者が複数の市町村と契約をする場合、上記に加え、以下の確認事項も必要となる。
•

それぞれの市町村からの放送要求が同時刻に集中した場合、放送事業者
は放送要求の先着順に実施し、放送までのタイムラグが発生する可能性があることを確認

今後、本手段が普及し、同一放送対象地域内の複数の放送事業者が参入し、また、複数の市町村が利用しようとする際の利用契約においては、市町村と放送事業者がそれぞれ個別に契約を交わす場合のほか、参画する複数の市町村と複数の放送事業者間で協議会を形成し、運用におけるルールを定め合意することも考えられる。
- 28 -

なお、地上デジタル放送事業者は、データ放送帯域を災害情報伝達のために利用するサービスを開始した後、当該事業者の放送エリア内における他の市町村
からサービス利用の申し出があった際は、新たにサービス提供を行うために十分なデータ放送帯域が確保されている場合、当該市町村と誠実に協議を行い、必要とされるサービスが提供するように取り計らうことが望ましい。また、地上デジタル放送事業者は、当該事業者の放送エリア内において、他の放送事業者がサービス利用を開始する場合には、相互に協議を行い、ｍ:ｎモデルの実現に努めること。
（５）屋外スピーカー・屋内受信機の整備・導入
屋外スピーカーについては、既存のものがあれば、アンテナ・受信装置等を交換することで本手段の導入が可能となる。アンテナ・受信装置の切り替えに併せて、非常電源の長時間化や高機能スピーカーの導入等についても検討し、機能強化による耐災害性の向上に努めることが望ましい。
屋内受信機については、上記３（７）に示す標準仕様に準拠した製品を調達すること。これにより、屋内受信機を追加的に配備する場合においても、特定のベンダーに依存することなく、他のベンダー製品も導入でき、競争性を確保し、調達価格の低廉化に寄与するものと考えられる。

- 29 -

別添

災害情報交換言語（EDXL）の標準定義フォーマット
（Ver.1）

更新日

Version版

主な追加・変更内容

1

名称と内容はじめに
表記ルール
コモンズEDXL要素
コモンズEDXLデータモデル

備考

このドキュメントにおける表記上のルール

2

はじめに
１．はじめに
本文書は地上デジタル放送波を活用した災害情報伝達手段に用いる災害情報交換言語（EDXL）の定義を記述するものである。

3表記ルール
接頭辞
URI = 名前空間
関連する基底型 :
項番

親要素

1 A1
2
3
4
5
6
7
8 A2
9
10
11 A3
12
13 (element)
14 (end)

接頭辞
名前空間
関連する基底型
項番
親要素

子要素

子要素
A11

基底型

出現回
数

type.A11**A3
xs:string

1

B21
B11

A1
xs:string

*
1

B12
B31

xs:string
A2

1
1

B11
B12
*

意味

システム利用

とりうる値

解説“c11a”“c11b”?
+

code.D1

名前空間（Namespace）を識別するための接頭辞を記述する。
名前空間（Namespace）名を記述する。
このドキュメント内に仕様が記述されていない型を基底型として参照している場合、関連する基底型として記述する。
要素の位置を一意に表せるように番号を記述する。
親要素として、型の名前を記述する。このドキュメント内では一意な名前とする。列挙型の場合、複数の要素から参照される場合のみ記述する。
親要素に含まれる項目の名前を記述する。同じ親要素内で一意な名前とする。例外的に任意の子要素も許容する場合は、子要素にアスタリスク（”*”）だけを記述した行を子要素の最後に置く（例：項番７）。この場合に許容する名前空間を、「とりうる値」欄に記述することができる。
また、規定型がこの要素のみが使用する列挙型となる場合、とりうる値を続けて記述する。（項番２，３，４）

4

基底型

子要素の基底型を記述する。子要素の基底型としては、XML Schemaで定義されているビルトインデータ型、このドキュメント内で定義される親要素の名前、XML Schema単純型拡張（後述）、または関連する基底型で定義される親要素の名前を記述する（例：項番
5、6、9）。親要素の基底型は通常、記述しないが、子要素の基底型は必ず記述する。
XMLSchema単純型拡張を以下に示す。
- pcx_eb:nullablefloat・・・xs:float型を拡張しており、xs:floatの記述範囲のほかに空文字の記述を許容するもの- pcx_eb:nullableinteger・・・xs:integer型を拡張しており、xs:integerの記述範囲のほかに空文字の記述を許容するもの
親要素の出現回数は記述しない。具体的な出現回数は親要素を参照する子要素中に定義される。

出現回数

子要素の出現回数は以下のように記述する。
必ず1回出現 1
0回か1回出現 ?
1回～無限大に出現 +0回～無限大に出現 *N回～M回出現 N, M

意味

親要素、子要素の意味を簡潔に記述する。

システム利用子要素がシステムのどのような機能で使用されるかを記述する。

とりうる値

子要素がとりうる値を簡潔に記述する。列挙値となる場合は、具体的な文字列をダブルクォートで挟んで記述する。正規表現を利用する場合は”RE:”を最初につけて記述し、任意の文字列を許容する場合は”*”を記述する。また、コード表による参照の場合、”code.” で始まるコード管理表の親要素名を記述する（例：項番3、4、12）。

解説

親要素、子要素を説明する文章を記述する。子要素がアスタリスク（”*”）だけの行は、例外的に任意の子要素も許容する理由を解説に記述し、他の欄は記述しない。

5

注１）親要素、子要素は排他的に用いる。
注２）親要素として型を記述する場合には要素名として”type.”を最初につける。
注３）別の名前空間に属する要素を作成する際は、要素名は呼び出される側の名前空間に属するようにする。そのために、次の２点の記述法を利用する。
・子要素欄に別の名前空間接頭辞が付いていた場合、基底型に記載の要素名に対して参照することとする。この場合の子要素と基底型は同じ接頭辞であるものとする。
・親要素名を”(element)”とした場合、子要素名を基底型に記載の型として、グローバルに宣言する（例：項番13）。
注４）表の最終行であることを明示するために、親要素名として”(end)”を置く。
注５）例に示した親要素、子要素の名称やとりうる値には特に意味がない。

6

要素の背景色について
必須要素（例：項番5）

コモンズノードシステム上、必須の要素。メッセージ収集時点でチェックが行われ、存在していない場合、および形式が正しくない場合
はエラーとなる（エラーチェックの起動の有無は、システムのオプションにより制御可能）。

必須要素（例：項番13）
親要素は省略可能であるが、親要素を指定した場合は必須となる要素。
（親要素は省略可）
条件付必須要素

特定の要素の子要素として出現する場合や、別の要素が特定の値を保持する場合のみ必須となる要素。必須となる条件については
各要素の「意味」「解説」列で記述する。

推奨要素（例：項番10）

コモンズノードシステムとして設定が推奨される要素。メッセージ情報の有用性の観点から、できる限り設定されていることが望ましい（存在しなくてもエラーとはならない）。

未使用要素

EDXLスキーマで定義されているが、コモンズノードシステムとしては使用しない要素。要素そのものを省略する。

システム設定要素

コモンズノードシステムが設定する要素。
情報発信システムは、この要素を設定してはいけない。
情報受信システムは、この要素を解析する必要はないが、この要素が存在することや存在しないことによってエラーが出ないように注意する必要がある。

7

コモンズEDXL要素
commons
URI = http://xml.publiccommons.ne.jp/xml/edxl/
関連する基底型 : edxlde: urn:oasis:names:tc:emergency:EDXL:DE:1.0 （OASIS EDXL）、 comet-edxl: http://xml.publiccommons.ne.jp/xml/edxl/ext/comet-edxl/、
commons_dr:http://xml.publiccommons.ne.jp/xml/edxl/ext/documentRevocation/ acpn_or:http://v-low-xml.futurelink.co.jp/ACPN/operationRequest/v1.0
項番

親要素

子要素

1 (element)
EDXLDistribution
2 edxlde:EDXLDistributionType
3
distributionID4

senderID

基底型

出現回数

意味

システム利用

edxlde:EDXLDistributionType

1 ドキュメントルート

xs:string

メッセージを一意に識別する文字列(ID)。
・重複排除、送達保証
元文書のIDではなく、EDXLエンベロープを付与した時点で一意となるようにUUID（Universally Unique Identifier：
RFC4122）を割り振ることを推奨する。
1 この文字列は、コモンズノードシステムにおいて、メッセージを一意に表す文字として使用される。コモンズノードシステ
ムは、この値がすでにデータベースに登録されているかどうかを元に、重複受信を排除する機能を実現する。

xs:string

とりうる値

本情報の識別情報を示し、本要素が同じものについては、同一の情報であることを示す。
例）7e573043-fc3c-4a6b-bdb8-a9608233b0af
詳細については、解説資料「メッセージと文書」を参照のこと。

発信システムID。情報発信システムを一意に表す文字列。 ・メッセージルーティング
コモンズに直接発信するシステムのFQDN（Fully Qualified
Domain Name）形式の文字列を設定する。ただし、DNS登録されている必要はない。

組織のドメインを末尾に含むFQDN形式の文字列を設定することで他システムとの重複を回避できる。
例：組織のドメインがexample.lg.jpの場合"sender.commons.system.example.lg.jp"

例えばAシステムからBシステムに入って、Bシステムからコモンズに配信する事例では、Bシステムの名称を表わす
FQDNを設定する。
コモンズからSOAP配信される情報のsenderIDは、発信元の1 senderIDが指定される。

TVCMLでSenderIdに該当するのは、SentFrom/Party/@FormalName。
用途：
特定のシステムからコモンズに送出したメッセージをフィルタリングする場合などに使用する。

なお、コモンズエディタから発信する場合のsenderIDは、「editor.ドメイン名」としているため連携システムから発信する際のsenderIDでは、”editor"という表現は非推奨としている。

5

dateTimeSent

xs:dateTime

解説

発信システムサーバが二重化されている場合、各サーバで同じSenderIDを使用する。たとえば、バック
アップ側のサーバから発信する場合のsenderIDは、平時の駆動系側のサーバから発信する場合のsenderIDと同じ値となる。

発信日時。情報発信システムがこの情報を送信した日時を表す。

タイムゾーンには日本標準時(+09:00)を指定しなければならない。
例：2016-05-01T10:00:00+09:00

1 この情報が複数のシステムを経由して送信される場合、コモ
ンズノードシステムに対して最後に送信処理を行ったシステ
ムの処理時刻を設定する。
6

distributionStatus

edxlde:statusValues

運用種別。
1 元文書の運用種別を表す文字列ベースの列挙値。

標準EDXLより列挙値を抜粋。

7

distributionType

edxlde:typeValues

更新種別。
1 情報の更新内容を表す文字列ベースの列挙値。

詳細については、解説資料「文書の新規作成・更新とドキュメントIDの関係」を参照のこと。

8combinedConfidentiality

xs:string

メッセージの機密性(confidentiality)を表す文字列。デフォル
1 ト値で固定とする。

"UNCLASSIFIED AND NOTSENSITIVE"

現バージョンでは"UNCLASSIFIED AND NOTSENSITIVE"で固定。

9

language

xs:string

メッセージの言語を表す文字列。現バージョンではja-JPで? 固定。

"ja-JP"

現バージョンでは"ja-JP"で固定

10

senderRole

edxlde:valueListType-<senderRole><valueListUrn>acpn:returnID<valueListUrn/><value>*********</value></senderRole>

3バイトのリターンIDを格納する。
*

8

commons
URI = http://xml.publiccommons.ne.jp/xml/edxl/
関連する基底型 : edxlde: urn:oasis:names:tc:emergency:EDXL:DE:1.0 （OASIS EDXL）、 comet-edxl: http://xml.publiccommons.ne.jp/xml/edxl/ext/comet-edxl/、
commons_dr:http://xml.publiccommons.ne.jp/xml/edxl/ext/documentRevocation/ acpn_or:http://v-low-xml.futurelink.co.jp/ACPN/operationRequest/v1.0
項番
11

親要素

子要素
recipientRole

基底型

出現回数

edxlde:valueListType

意味

システム利用Recipient(EDXLを受信・解釈する機器)に関する情報を表す。

・メッセージルーティング
・再生、表示、作動

とりうる値-

拡張EDXLでは、本要素を受信装置記述子として使用することで、受信装置の属性とその再生方法に関するヒントを記述可能とする。

解説
valueListUrnにacpn:recipientDescriptorを指定する。
value要素を複数指定することができ、ここにJSON形
式で記述する。記述例を以下に示す。項目詳細については、補足*1を参照のこと。
<recipientRole> <!– 受信装置記述子 --><valueListUrn>acpn:recipientDescriptor<valueListUrn/><value><![CDATA[{
deviceClass: "publicSignage" // この記述を適用す
る受信装置は公衆サイネージ,consumerDescriptorId: "group1" // この記述を適用する情報消費者グループのIDは group1, reproductionClass: ["text", "audio"] //受信装置に期待される体現化はテキストと音声}]]></value><value><![CDATA[{
deviceClass: "publicSignage" // この記述を適用す
る受信装置は公衆サイネージ,consumerDescriptorId: "group2" // この記述を適用する情報消費者グループのIDは group2,reproductionClass: ["text", "stillImage"] //受信装置に期待される体現化はテキストと静止画,reproductionTime: 30 // 受信装置に期待される
再生時間は30秒,reproductionCount: 5 // 受信装置に期待される
再生回数は5回}]]></value></recipientRole>*

12

keywordedxlde:valueListType

このメッセージに関連した話題(topic)を表すリスト形。使用し
* ない。

-

使用しない

13

distributionReference

xs:string

別メッセージへの参照を表す文字列。
* 本来は、更新メッセージ受信時に更新対象メッセージのIDを設定するが、実装上設定しない。

-

使用しない

14
15

explicitAddress
targetArea

edxlde:valueSchemeType
edxlde:targetAreaType* 明確な受信者を表す。現バージョンでは使用しない。
対象地域。
情報発信者が当該の情報を伝えたい住民が居住している地域を表す。
地域の名称は、都道府県、市区町村、政令都市の区など、
全国地方公共団体コード（JISX0401/0402）を保有する団体
等の名称を設定する-使用しない
子要素 jisX0402 について：
jisX0402要素は必須項目であり、情報の対象地域の「市区町村及び一部事務組合等コード」番号を記述する。

EDXLスキーマ上は、省略可能となっているが、子要素* jisX0402がメッセージルーティングで使用されるため省略してはならない。
元文書が自治体によって作成されている場合には、
targetArea/areaName要素のひとつには作成した自治体名を記述し、areaNameKana要素の値には作成した自治体名のかな表記を記述する。

9

この要素を複数指定する場合、当該の情報を作成した
自治体（対象地域）の出現順は最後にする。

commons
URI = http://xml.publiccommons.ne.jp/xml/edxl/
関連する基底型 : edxlde: urn:oasis:names:tc:emergency:EDXL:DE:1.0 （OASIS EDXL）、 comet-edxl: http://xml.publiccommons.ne.jp/xml/edxl/ext/comet-edxl/、
commons_dr:http://xml.publiccommons.ne.jp/xml/edxl/ext/documentRevocation/ acpn_or:http://v-low-xml.futurelink.co.jp/ACPN/operationRequest/v1.0
項番

親要素

16

子要素
contentObject

基底型

出現回数

edxlde:contentObjectType

意味

システム利用

とりうる値

情報本体および付加情報を含む複合型。
commons:contentObjectとedxlde:contentObjectを
EDXLDistribution配下に混在して配置する。
*

運用種別を表す文字列ベースの列挙型。

解説
contentObject要素は下記規則に沿って設定されなけ
ればならない・commons:contentObjectはpcxmlあるいは気象庁
XMLのどちらかを保持し、必ず1個指定しなければならない・edxlde:contentObjectは複数指定でき、
consumerRoleの受信媒体指定かcontentKeyword の添付ファイルパスのいずれかを指定する
・拡張されたEDXLからedxlde:contentObjectとedxlde:recipeintRoleの要素を削除すると、従来のコモンズの仕様に従ったEDXLとならなければならない
この型は、PCXML要素でも使用される。
本番。このメッセージが、実運用の業務内で作成・発表されたことを表す。

17 edxlde:statusValues
18

xs:NMTOKEN
*

19

*

"Exercise"

訓練。このメッセージが、実運用中の訓練業務で作成・発表されたことを表す。

20*"System"システム。情報発信者が送信することはない。このメッセージが、実運用中またはテスト中に送信されたシステム情報であることを表す。

21*"Test"

テスト。このメッセージが、運用開始前のシステム構築
時のベンダ間接続テストで作成・発表されたことを表す。

22 edxlde:typeValues
23

xs:NMTOKEN
*

24

*

"Update"25*"Cancel""Actual"

更新種別を表す文字列ベースの列挙型。
"Report"

この型は、PCXML要素でも使用される。
新規。元文書が新しく作成された情報であることを表す。
更新。元文書が改版されたことを表す。なお、更新時の情報には、差分のみではなく、改版後の文書全体が含まれていなければならない。
取消。
既に作成・発表された元文書が削除されたことを表す。
"Cancel"は発信したこと自体が誤りである誤報などの場合に用いる。
誤報等により元文書の一部が訂正された場合には、訂正後の文書全体を含む情報をdistributionType=Updateで送信することが推奨される。
また、通常の更新ではなく訂正であることを注意喚起
するため標題にその旨を明記することが推奨される。
詳細については、解説資料「発信情報の取消」を参照
のこと。

26

27 edxlde:targetAreaType28*

circlexs:string"Error"

地域情報を含む複合型。
対象となるエリアの地理情報（円）を表す文字列。書式は”
緯度(-90 ~ 90),経度(-180 ~ 180),半径(km)”となる。
* 緯度・経度には世界測地系に基づく値を10進法で設定す
る。

10

エラー。
エラー発生についての情報であることを表す。システ
ムが送信し情報発信者が送信することはない。
例）34.75695,134.841178,0commons
URI = http://xml.publiccommons.ne.jp/xml/edxl/
関連する基底型 : edxlde: urn:oasis:names:tc:emergency:EDXL:DE:1.0 （OASIS EDXL）、 comet-edxl: http://xml.publiccommons.ne.jp/xml/edxl/ext/comet-edxl/、
commons_dr:http://xml.publiccommons.ne.jp/xml/edxl/ext/documentRevocation/ acpn_or:http://v-low-xml.futurelink.co.jp/ACPN/operationRequest/v1.0
項番

親要素

子要素

基底型

29

polygonxs:string30

country

xs:string31

subdivision

xs:string32
33 edxlde:contentObjectType34

locCodeUN

xs:string

contentDescription

xs:string

出現回数

意味

システム利用

とりうる値

ISO 3166-1定義国名コードを表す文字列。現バージョンでは使用しない。
ISO 3166-2地理（行政区画・属領）コードを表す文字列。現* バージョンでは使用しない。

-

使用しない

-

使用しない

* UN/LOCODEを表す文字列。現バージョンでは使用しない。
情報本体および付加情報を含む複合型要素。
見出し文。
この情報の内容を簡潔に表した文章。

-

使用しない

*

例)2009年9月1日大雨被害に伴う避難勧告（試験）
詳細については、解説資料「メッセージを説明する要素」を参照のこと。

? incidentDescriptionが情報の原因となった事象についての記述を指すのに対し、contentDescriptionは情報そのものに対する記述を指す。
35

contentKeyword

edxlde:valueListType

元文書についてのキーワードを表すリスト形。

・マルチメディア情報添付-

拡張EDXLでは、本要素を添付ファイルコンテンツのパスとして使用することで、他のコンテンツから参照される際のパスを指定する。
添付のものメディアを識別するメディアIDを格納する。

<valueListUrn>acpn:attachementPath<valueListUrn/><value>imgs/map.jpg</value></contentKeyword><contentKeyword><valueListUrn>acpn:monoMediaID<valueListUrn/><value>********</value></contentKeyword></contentObject>

36

incidentID

xs:string

災害のIDを表す文字列。
? 一つの災害に対する全市町村/インフラ関係者間で有効なIDを採番する機構が存在しないため、使用しない。

37

incidentDescription

xs:string

この情報の原因となった事象についての記述を表す文字列。

-

edxlde:valueListType* 情報の作成者のロールを表す文字列。使用しない。

11

使用しない

例)2009年9月1日大雨被害（試験）
詳細については、解説資料「メッセージを説明する要素」を参照のこと。

? contentDescriptionは情報そのものに対する記述を指すのに対し、incidentDescriptionが情報の原因となった事象についての記述を指す。
originatorRole

valueListUrnにacpn:attachementPathを指定する。
value要素は1個しか指定できず、またEDXL内で一意で無ければならない。この属性が指定されているコン
テンツは添付ファイルであることを示し、単独では利用できない。以下に記述例を示す。
<contentObject><contentKeyword>

*

38

解説

対象となるエリアの地理情報（多角形）を表す文字列。書式
は”緯度(-90 ~ 90),経度(-180 ~ 180)”を区切り文字スペー* ス’ ‘で連結したものとなる。
緯度・経度には世界測地系に基づく値を10進法で設定す
る。

-

使用しない

commons
URI = http://xml.publiccommons.ne.jp/xml/edxl/
関連する基底型 : edxlde: urn:oasis:names:tc:emergency:EDXL:DE:1.0 （OASIS EDXL）、 comet-edxl: http://xml.publiccommons.ne.jp/xml/edxl/ext/comet-edxl/、
commons_dr:http://xml.publiccommons.ne.jp/xml/edxl/ext/documentRevocation/ acpn_or:http://v-low-xml.futurelink.co.jp/ACPN/operationRequest/v1.0
項番

親要素

39

子要素
consumerRole

基底型

出現回数

edxlde:valueListType

意味

システム利用Consumer（動作を「期待」される 人・モノ（公衆））に関する記述を表す。

・再生、表示、作動

とりうる値-

拡張EDXLでは、本要素を情報消費者記述子として使用することで、情報消費者のグループを記述可能とする。

解説
valueListUrnにacpn:consumerDescriptorを指定する。
value要素を複数指定することができ、ここにJSON形
式で記述する。また、IDを付与することで、受信装置記述子から参照することも可能である。なお、この属性は再生の主体であるコンテンツにのみ付与可能であり、添付ファイルには付与できない。記述例を以下に示す。項目詳細については、補足*2を参照のこと。
<consumerRole > <!-- 情報消費者記述子 --><valueListUrn>acpn:consumerDescriptor<valueListUrn/><value><![CDATA[{
id: "group1" // この情報消費者グループのIDは"group1",groupIds: ["916"] // 対象グループIDは916:尾上
処理工場（拡声子局）,areaCodes: ["282100501"] // 対象エリアは0501:
尾上町 養田}]]></value><value><![CDATA[{
id: "group2" // この情報消費者グループのIDは"group2",areaCode: ["282100501", "282100601","282100602"] // 対象エリアは0501など尾上町 一部のエリア}]]></value></consumerRole >*なお、本要素はコモンズXML仕様でも運用されているが、valueListUrnの値が異なるため、競合することはな
い。

40
41
42

confidentiality
other
nonXMLContent

xs:string
xs:otheredxlde:nonXMLContentType

43

xmlContent

edxlde:xmlContentType? このメッセージの守秘性を表す文字列。使用しない。
* 任意の要素。使用しない。
非XML形式の元文書を含む複合型。この要素とxmlContent ・マルチメディア情報添付のどちらかが必須となる。
?

-

使用しない
使用しない

XML形式の情報を含む複合型。この要素とnonXMLContentのどちらかが必須となる。
?

44 valueListType45
46
47 edxlde:nonXMLContentTypevalueListUrn
value

xs:string
xs:string

1 キー

-

+値

-

非XML形式の元文書を含む複合型。コモンズノードシステム
では使用しない。

12

別紙「緊急速報/エリアメール配信機能開発ガイド」参照。
別紙「緊急速報/エリアメール配信機能開発ガイド」参照。

commons
URI = http://xml.publiccommons.ne.jp/xml/edxl/
関連する基底型 : edxlde: urn:oasis:names:tc:emergency:EDXL:DE:1.0 （OASIS EDXL）、 comet-edxl: http://xml.publiccommons.ne.jp/xml/edxl/ext/comet-edxl/、
commons_dr:http://xml.publiccommons.ne.jp/xml/edxl/ext/documentRevocation/ acpn_or:http://v-low-xml.futurelink.co.jp/ACPN/operationRequest/v1.0
項番

親要素

子要素

基底型

48
49
50
51
52

mimeTypesize
digesturi
contentData

xs:string
xs:integer
xs:string

53 edxlde:xmlContentType54

keyXMLContent

edxlde:anyXMLType55

embeddedXMLContent

edxlde:anyXMLType56 CommonsTargetAreaType
57

areaName

xs:string

xs:anyURI
xs:anyBase64Binary

出現回数

areaNameKana

システム利用XML形式の情報本体を含む複合型。
embeddedXMLContent内のフラグメントを表す。フラグメント
要素を包含する。使用しない。
情報そのものを表す。子要素として、公共情報コモンズXML* （PCXML）フォーマットまたは気象庁防災情報XMLフォーマッ
トまたは操作要求XMLが出現する。

*

edxlde:targetAreaType を継承するコモンズ用拡張。
地域の名称を表す。同じ親を持つjisX0402要素が存在する
場合、コードに該当する名称を設定する。

1

58

意味

1 MIMEタイプを表す文字列。
? ファイルサイズを表す数値。
? ダイジェストを表す文字列。
? URI。
Base64エンコード形式。uriの代わりまたはuriとともに使用さ
? れる。

解説

-

使用しない。

例)加古川市

この要素が、/EDXLDistribution/targetArea下に出現する場
合、情報発信者が当該の情報を伝えたい住民が居住している地域の名称を表す。地域名称は、都道府県、市区町村、政令都市の区など、全国地方公共団体コード（JISX0401/0402）を保有する団体等の名称を設定する。

地域のかな表記を表す。同じ親を持つjisX0402要素が設定されている場合、コードに該当する名称のかな表記の値を設定する。

xs:string

とりうる値-例)かこがわし

この要素が、/EDXLDistribution/targetArea下に出現する場? 合、情報発信者が当該の情報を伝えたい住民が居住している地域の名称を表す。地域名称は、都道府県、市区町村、政令都市の区など、全国地方公共団体コード（JISX0401/0402）を保有する団体等の名称のかな表記を
設定する。
59

jisX0402

xs:string

この情報が対象とする地域の「市区町村及び一部事務組合 ・メッセージルーティング
等コード」を表す。値はチェックディジットつき6桁の値となる。

例)282103?

60

ooAzaTyouTyouMokuCode61 CommonsContentObjectType62
publishingOfficeName

xs:string

xs:string

EDXLDistribution/targetArea/ の子要素としての jisX0402
は、必須要素である。その他の位置に出現する場合はこの限りではない。
このメッセージが対象とする地域の「大字町丁目コード」を表す。このコードは国土交通省国土計画局が提供する、位置? 参照情報ダウンロードサービスにおいて使用されている値とする。
edxl:contentObjectType を継承するコモンズ用拡張要素。
本情報を業務的に発表した部署の名称を示す。
スキーマ上では互換性維持のため省略可能とするが、実質? 上必須要素である。

13例)災害対策局災害対策課

commons
URI = http://xml.publiccommons.ne.jp/xml/edxl/
関連する基底型 : edxlde: urn:oasis:names:tc:emergency:EDXL:DE:1.0 （OASIS EDXL）、 comet-edxl: http://xml.publiccommons.ne.jp/xml/edxl/ext/comet-edxl/、
commons_dr:http://xml.publiccommons.ne.jp/xml/edxl/ext/documentRevocation/ acpn_or:http://v-low-xml.futurelink.co.jp/ACPN/operationRequest/v1.0
項番
63

親要素

子要素
publishingOrganizationName

基底型

出現回数

xs:string

意味

システム利用publishingOfficeID

xs:string

?

解説
例)兵庫県

スキーマ上では互換性維持のため省略可能とするが、実質上必須要素である。

本要素は、Version 1.3より、追加された。Version 1.3
以降の形式の発信システムは、必ず本要素を設定しなければならない。また、受信側システムでは、Version 1.2.1 以前形式の発信システムによる情報に、本要素が設定されない場合がある点に注意する必要がある。なお、XMLスキーマ上は互換性維持のため省略可能としている。

?

64

とりうる値

本情報を業務的に発表した組織の名称を示す。

本情報を業務的に発表した組織のコードを表す。
発表組織が自治体の場合、全国地方公共団体コード（JISX0401/0402）をチェックディジット付きの6桁で指定する。

・メッセージルーティング例）280003

発表組織が自治体以外の場合には省略する。

65

publishingOfficeDomainName xs:string

66

previousDocumentRevision

本情報を業務的に発表した組織を一意に表す文字列であ ・メッセージルーティング
る。自治体の場合は省略する。PCXML内のPublishingOffice
要素以下のOrganizationDomainNameが設定されている場? 合は、同じ値を設定する。PCXML内のOfficeDomainNameではないので注意が必要である。

xs:int

更新前のメッセージの版番号を表す。この情報が新規(distributionType=Report)である場合には、
previousDocumentRevisionは値0を指定するか、要素ごと省略する。
更新前のメッセージの版番号が不明である場合には、要素ごと省略する。
?

値は、連続している必要はない（１→２→４→５となってよい）。
さらに、previousDocumentRevisionの値を持つ情報がコモンズに発信されなくてもよい（元文書システムが１→２→４→５と更新し、１と５のみをコモンズに発信する場合に、５の場合のpreviousDocumentRevisionの値は４となる）。
上記より、本項目を使用して伝達者側システムを設計することは推奨されない。

14

commons
URI = http://xml.publiccommons.ne.jp/xml/edxl/
関連する基底型 : edxlde: urn:oasis:names:tc:emergency:EDXL:DE:1.0 （OASIS EDXL）、 comet-edxl: http://xml.publiccommons.ne.jp/xml/edxl/ext/comet-edxl/、
commons_dr:http://xml.publiccommons.ne.jp/xml/edxl/ext/documentRevocation/ acpn_or:http://v-low-xml.futurelink.co.jp/ACPN/operationRequest/v1.0
項番
67

親要素

子要素
documentRevision

基底型

出現回数

xs:int意味

システム利用

とりうる値

このメッセージの版番号を表す。
この情報が新規(distributionType=Report)である場合には、
documentRevisionの値は１となる。

解説
本要素は、第1.1版より、必須要素に指定された。第1.1版以降の形式の発信システムは、必ず本要素を設定しなければならない。また、受信側システムでは、第1.0版形式の発信システムによる情報に、本要素が設定されない場合がある点に注意する必要がある。なお、XMLスキーマ上は互換性維持のため省略可能としている。

更新された元文書の順序を識別するのに利用されるため、必須要素とする。

詳細については、解説資料「文書の管理・運用」を参
照のこと。

?

documentRevisionの値は、更新を行うごとに、より大きな値となっていなければならない。ただし、更新ごとの値が連続している必要はない（１→２→４→５となってよい）（元文書システムが１→２→４→５と更新し、１と５のみをコモンズに発信する場合に、元文書の５版のdocumentRevisionの値には（２ではなく）５を設定する）。

68

documentID

xs:string

ドキュメントID。文字数の上限は128文字である。
文書を一意に識別する文字列。文書に共通のdocumentIDと 、documentRevision が符番されることで、改版を表現する。

詳細については、解説資料「メッセージと文書」を参照のこと。

例えば、「避難勧告発令 → 避難指示発令 → 避難指示解除」の順で発令・解除が発表されるとき、コモンズノードシ
ステムに対して3件の情報の送信が行われる。ここで、distributionIDは3件の情報すべてに異なる値が符番されるのに対し、documentIDは3つの情報すべてに同じ値が符番される。これによって、3件の情報の元文書が同一であり、?
元文書が更新されていることを認識できる
documentID は、コモンズのシステム内でユニークなIDとなる必要があるため、UUID（Universally Unique Identifier：
RFC4122）の使用を推奨する。また、元文書が発信システム
上一意となる ID を持っており、かつ上記改版の考え方に則している場合には、これに発信システムのFQDNを付けたものを用いてもよい。pcxml の documentID と同じものである。

69

category

categoryType70

urgency

xs:string1

このメッセージの情報種別を表す。

・メッセージルーティング

このメッセージの緊急度を表す文字列ベースの列挙値。以下のいずれかの値となる。

・メッセージルーティング

詳細については、解説資料「アラーティング要素のとりうる値」を参照のこと。
この要素は、ノードシステムによって付与される。
情報発信システム側は、この要素を設定してはいけな
い。
情報受信システム側は、この要素を解析する必要はな
いが、この要素が存在することによってエラーが出ないように注意する必要がある。

?

71
72

*
*

"Immediate""Expected"

15

直ちに
まもなく（1時間以内）

commons
URI = http://xml.publiccommons.ne.jp/xml/edxl/
関連する基底型 : edxlde: urn:oasis:names:tc:emergency:EDXL:DE:1.0 （OASIS EDXL）、 comet-edxl: http://xml.publiccommons.ne.jp/xml/edxl/ext/comet-edxl/、
commons_dr:http://xml.publiccommons.ne.jp/xml/edxl/ext/documentRevocation/ acpn_or:http://v-low-xml.futurelink.co.jp/ACPN/operationRequest/v1.0
項番

親要素

73
74
75
76

子要素

severity

基底型

出現回数

*
*
*
xs:string

意味

システム利用このメッセージの重大性を表す文字列ベースの列挙値。

とりうる値

解説

"Future""Past""Unknown"

近い将来
過去
不明/適用外詳細については、解説資料「アラーティング要素のとりうる値」を参照のこと。

・メッセージルーティング

この要素は、ノードシステムによって付与される。
情報発信システム側は、この要素を設定してはいけな
い。
情報受信システム側は、この要素を解析する必要はな
いが、この要素が存在することによってエラーが出ないように注意する必要がある。

?

77
78
79
80
81
82
83

certainty

*
*
*
*
*
*
xs:string"Extreme""Severe""Moderate""Minor""None""Unknown"
このメッセージの確実性を表す文字列ベースの列挙値。

この要素は、ノードシステムによって付与される。
情報発信システム側は、この要素を設定してはいけな
い。
情報受信システム側は、この要素を解析する必要はな
いが、この要素が存在することによってエラーが出ないように注意する必要がある。

?

84
85
86
87
88
89

deliveryInformation

*
*
*
*
*
deliveryInformationType

著しく高い
高い
中程度
低い
重大性なし
不明/適用外詳細については、解説資料「アラーティング要素のとりうる値」を参照のこと。

"Observed""Likely""Possible""Unlikely""Unknown"

発生中・進行中おそらく起こる(p>50%)
起こるかもしれない(p<=~50%)
起こりそうにない(p=~0%)
不明/適用外

配信情報を表す複合型要素。
? この要素は、コモンズノードシステム側で付与される。
情報発信システム側では設定してはいけない。

90

91 categoryType
92
93
94
95
96
97
98
99
100

received

receivedType

xs:string
*
*
*
*
*
*
*
*
*

配信処理済みノード情報を表す複合型要素。
* この要素は、コモンズノードシステム側で付与される。
情報発信システム側では設定してはいけない。
情報種別を表す列挙型。
"AntidisasterHeadquarter""EvacuationOrder""Shelter""TemporaryStayFacilities""DamageInformation""GeneralInformation""Event""CivilProtection""UrgentMail"

16

この型は、PCXML要素でも使用される。
災害対策本部設置状況
避難勧告・指示情報
避難所情報
一時滞在施設情報
被害情報
お知らせ
イベント情報国民保護情報
緊急速報メール（別紙「緊急速報/エリアメール配信機能開発ガイド」
参照。）

commons
URI = http://xml.publiccommons.ne.jp/xml/edxl/
関連する基底型 : edxlde: urn:oasis:names:tc:emergency:EDXL:DE:1.0 （OASIS EDXL）、 comet-edxl: http://xml.publiccommons.ne.jp/xml/edxl/ext/comet-edxl/、
commons_dr:http://xml.publiccommons.ne.jp/xml/edxl/ext/documentRevocation/ acpn_or:http://v-low-xml.futurelink.co.jp/ACPN/operationRequest/v1.0
項番

親要素

子要素

基底型

出現回数

意味

システム利用

とりうる値

101

*

"SedimentDisastersWarning"

102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127 commons_dr:type.DocumentRevocation

*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*

"WaterLevel""RainFall""TideLevel""FamiliariseRiver""WeatherWarningAndAdvisory"

128
dateTimeRevoked
129
commons:documentID
130
description
131 複合型要素・システム内部情報
132 deliveryInformationType

xs:dateTime
xs:string
xs:string133
134

messageURI
description

xs:string
xs:string

1 このメッセージのURIを表す。
このメッセージの概要を表す文字列。
?

135
136
137

maximumDeliveryTimesdeliveryTimes
doErrorEscalation

xs:intxs:intxs:boolean

1 このメッセージの最大配信試行回数を表す数値。
1 このメッセージの現在までの配信試行回数を表す数値。
このメッセージの配信失敗時に、エラーエスカレーション処
1
理を行なうかどうかを表すフラグ。

解説
土砂災害警戒情報（発信システム側はこの情報種別を発信してはいけな
い。受信システム側は"SedimentDisastersWarningFromJMA"（気象庁XML形式の土砂災害警戒情報）を受信すること。）

河川水位情報
雨量情報
潮位情報
水位周知河川
気象警報・注意報"SedimentDisastersWarningFromJMA" 土砂災害警戒情報"FloodForecastingFromJMA" 指定河川洪水予報"TsunamiForecast"
津波警報・注意報・予報"LocalizedHeavyRainFall"
記録的短時間大雨情報"TornadoWarning"
竜巻注意情報"EscalationMessage"
配信結果情報"DocumentRevocation"
文書無効化情報"SeismicIntensityInformation" 震度速報
"EarthquakeInformation"
震源に関する情報"EarthquakeAndSeismicIntensityInformation" 震源・震度に関する情報"InformationOnSeismicActivity" 地震の活動状況等に関する情報"InformationOnTheNumberOfEarthquakes" 地震回数に関する情報"InformationOnTheRevisionOfSourceParametersForRemarkableEarthquakes"
顕著な地震の震源要素更新のお知らせ"TsunamiInformation"
津波情報"TsunamiObservationsAtOffshoreGauges" 沖合の津波観測に関する情報"WeatherEmergencyWarningsAndWarningsAndAdvisories"
気象特別警報・警報・注意報"VolcanicForecastsAndWarnings" 噴火警報・予報"PowerFailure"
停電発生状況
"VolcanicInformation"
噴火速報"WeatherWarningAndAdvisoryH27" 気象警報・注意報（Ｈ２７）
本要素はXML Version1.4より追加された。
本要素は、誤配信文書の公開終了を情報伝達者へ要求する目的で使用され、EDXLの
embeddedXMLContent要素以下に本要素が出現する。
サービス提供者以外は、本要素を発信することはできない。

文書無効化情報

1 無効日時1 無効ドキュメントID
1 説明・メッセージルーティング

文書を無効化した日時
無効理由などを記述する。

配信プロセスを表す複合型要素。全ての要素値はノードシ
ステム内で設定され、情報発信者側での設定はできない。

17

この要素は、ノードシステムによって付与される。
情報発信システム側は、この要素を設定してはいけな
い。
情報受信システム側は、この要素を解析する必要はな
いが、この要素が存在することによってエラーが出ないように注意する必要がある。

commons
URI = http://xml.publiccommons.ne.jp/xml/edxl/
関連する基底型 : edxlde: urn:oasis:names:tc:emergency:EDXL:DE:1.0 （OASIS EDXL）、 comet-edxl: http://xml.publiccommons.ne.jp/xml/edxl/ext/comet-edxl/、
commons_dr:http://xml.publiccommons.ne.jp/xml/edxl/ext/documentRevocation/ acpn_or:http://v-low-xml.futurelink.co.jp/ACPN/operationRequest/v1.0
項番

親要素

138
139
140
141
142
143
144
145 taskType

子要素

基底型

firstDeliveryDate
lastDeliveryDate
deliveryStatus

xs:dateTime
xs:dateTime
xs:string

task

*
*
*
taskType

146
147
148
149
150
151
152
153
154
155
156
157
158 commons-edxl:task

serviceName
topicID
taskStatus

159

commons-edxl:CometEndpoint.PushTopicName

captiontype
applicantapplicantRole
receivedNodeEndpointID

xs:string
xs:stringcommons:taskStatusType****
xs:string
xs:string
xs:string
xs:string
xs:string

出現回数

意味

システム利用

とりうる値

解説? このメッセージが初めて配信された日時を表す。
? このメッセージが最後に配信された日時を表す。
このメッセージの配信ステータスを表す文字列ベースの列?
挙値。
"SUCCESSFUL""ACTIVE""FAILED"* 配信タスク情報を表す複合型要素。
配信タスクを表す複合型要素。全ての要素値はノードシステ
ム内で設定され、情報発信者側での設定はできない。

全ての配信タスクは正常に完了している。
1つ以上の配信タスクが処理中である。
1つ以上の配信タスクに失敗した。
この要素は、ノードシステムによって付与される。
情報発信システム側は、この要素を設定してはいけな
い。
情報受信システム側は、この要素を解析する必要はな
いが、この要素が存在することによってエラーが出ないように注意する必要がある。

1 サービス名
1 トピックID? この配信タスクのステータスを表す文字列ベースの列挙値。
"EXECUTED""WAITING""DENIED""FAILED"? トピック名? トピック種別? 利用団体ID? 利用団体種別? 収集・配信ポイントID
Comet-EDXL配信タスクを表す複合型要素

xs:string

この配信タスクは正常に終了している。
この配信タスクは実行中である。
この配信タスクは拒否された。
この配信タスクは失敗している。

この要素は、ノードシステムによって付与される。
情報発信システム側は、この要素を設定してはいけな
い。
情報受信システム側は、この要素を解析する必要はな
いが、この要素が存在することによってエラーが出ないように注意する必要がある。

トピック名を表す単純型要素。
1160

commons-edxl:CometEndpoint.PushMessageURI

xs:string

配信するメッセージのURIを表す単純型要素。
1

161

commons-edxl:CometEndpoint.MessageSentTime

xs:dateTime

このメッセージが発信された時刻を表す単純型要素。
1

162 received

163
164
165
166 (end)

メッセージ受信有無を確認するための情報。

nodeIdreceivedTime
endpointID

xs:string
xs:dateTime
xs:string

1 受信済みノードのIDを表す。
1 このノードがメッセージを受信した日時を表す。
1 受信済み収集・配信ポイントID(参考)
167 valueSchemeType18

この要素は、ノードシステムによって付与される。
情報発信システム側は、この要素を設定してはいけな
い。
情報受信システム側は、この要素を解析する必要はな
いが、この要素が存在することによってエラーが出ないように注意する必要がある。

commons
URI = http://xml.publiccommons.ne.jp/xml/edxl/
関連する基底型 : edxlde: urn:oasis:names:tc:emergency:EDXL:DE:1.0 （OASIS EDXL）、 comet-edxl: http://xml.publiccommons.ne.jp/xml/edxl/ext/comet-edxl/、
commons_dr:http://xml.publiccommons.ne.jp/xml/edxl/ext/documentRevocation/ acpn_or:http://v-low-xml.futurelink.co.jp/ACPN/operationRequest/v1.0
項番
168
169
170 (end)

親要素

子要素
explicitAddressScheme
explicitAddressValue

基底型
xs:string
xs:string

出現回数

意味

システム利用1 スキーム名
?値

とりうる値
-

19

解説
使用しない
使用しない

commons

補足*1 受信装置記述子のオブジェクトのプロパティ一覧
項番
A-1

プロパティ名（背景黄色は必須項目、緑色は推奨項目）

型

出現
回数

意味

とりうる値

deviceClass

stringA-12

consumerDescriptorId

*
*
*
*
*
*
*
*
*
*
*
*
*
string? 情報消費者グループのID

A-13

wakeUpboolean? 速達であることを示すフラグ

true の場合は速達であることを意味する。値が指定されていない場
合は false となる。
受信装置は出来る限り早く情報消費者に情報を伝えるために自動起動やプッシュ通知を行う。

A-14

actionstring? 望まれる動作を表すARIBの動作コード

A-15

validDateTime

string? コンテンツの有効期限

値は別紙「ARIB動作内容コード表」に記載されたコード出なければならない
日時フォーマットはxs:dateTime型で指定しなければならない

A-2
A-3
A-4
A-5
A-6
A-7
A-8
A-9
A-10
A-11

1 受信装置の種別

解説
受信装置は自身が指定されているものの中で最初にマッチング可能（情報消費者グループのマッチング：後述）な受信装置記述子を選択する。

"radio""personalTerminal""publicSignage""IoTConcent""adhockNetworkGateway""SNS""mailMagazine""webPublishing""emergencyMail""telephone""loudSpealer""motorSiren"
"OTA"

ラジオ
スマートフォン、タブレット、セットトップボックス
サイネージ"IOT機器接続口"
"DTN"
SNS
安心安全メール
公式HP
3キャリア緊急速報メール
自動配信電話／自動応答電話
屋外拡声器
モーターサイレン
OTA
この値で指定される（=情報消費者記述子のIDが一致する）情報消費者グループが同一メッセージ内の情報消費者記述子で定義されていなければならない。
受信装置は対応する情報消費者グループに対する配信が可能である場合のみ、当該受信装置記述子を選択できる。

例：
2017-10-22T19:45:00+09:00
A-16

reproductionClass

array<string>? 再生内容の種別

テキスト("text")、音声("audio")、静止画("stillImage")、動画("video")、点検放送("alive")、バイナリ("binary")のうちいずれかを、複数個配列で指定できる例：["text", "stillImage"]

A-17

*

"text"

テキスト

A-18
A-19
A-20
A-21
A-22
A-23
A-24
A-25

*
*
*
*
*
numbernumberstring"audio""stillImage""video""alive""binary"

音声
静止画
動画
点検放送
バイナリ

reproductionTime
reproductionCount
storeOperation? コンテンツの再生秒数? コンテンツの再生回数? コンテンツの蓄積処理

20

999は永遠を意味する
storeOnly:再生せず蓄積
playandStore:再生し蓄積
記述がない場合は再生のみ

commons

A-26

reportboolean? レポート要求

A-27

reproductionSpeed

number? コンテンツの再生スピード

true の場合はrecipientととしてアンサーバックを返す。値が指定されていない場合は false となる。
相対値（1を基準値とし0.1から10）A-28

reproductionVolume

number? コンテンツの再生音量

例：1.2
相対値（0から100の整数）? コンテンツの再生時刻

例：
100
日時フォーマットはxs:dateTime型で指定しなければならない

A-29

reproductionDateTime

stringA-30

reproductionMedia

array<string>? 再生コンテンツの指定

A-31

reproductionRepeat

string? 再生コンテンツの繰り返し指定

A-30

reproductionTypestring? OTAでアップデートする機器の型番

A-31

reproductionVersion

string? OTAでアップデートする機器のバー
ジョン

A-32 (end)21例：2017-10-22T19:45:00+09:00
0009F2（メディアID）。
モーターサイレンのプリセット2音色の指定方法は「1」「2」。その他「0」で強制停止。
拡声器のプリセット12種の音源の指定は「1」から「12」OTAの場合、分割して放送されたバイナリファイルを配列で指定。
cronの記述準拠。
例：
0 17 * * 1 （毎週月曜の 17:00に実行）
例：
VRK10F1
例：
1.1.1

commons*2 情報消費者記述子のオブジェクトのプロパティ一覧
プロパティ名項番（背景黄色は必須項目、緑色は推奨項目）
B-1
id
B-2
groupIds型
stringarray<string>

出現
回数

意味

とりうる値

1 情報消費者のグループのID? 情報消費者の種別を表すARIBのグ
ループIDの配列

解説
受信装置記述子からこのIDを指定して参照することができる。
値は別紙「加古川市グループコードエリアID表」に記載されたコードでなければならない
例：["916"]

B-3

areaCodes

array<string>? 情報消費者の居場所を表すARIBのエリアコードの配列

値は別紙「加古川市グループコードエリアID表」に記載されたコードでなければならない
例：["0501", "0601", "0602", "0603"]

B-4

consumerClass

string? 情報消費者の種別

B-5
B-6
B-7

Receptor**
string? 操作対象種別

情報消費者がヒトではなくモノである場合にそのモノの種別を指定する。
"automaticShelterManager""automaticMailSender"

B-8 (end)22

自動避難所管理装置
メール代行送信装置
情報消費者の内部に操作の対象が複数ある場合に対象の種別を指定

操作要求XML 要素
acpn_or
URI = http://v-low-xml.futurelink.co.jp/ACPN/operationRequest/v1.0
関連する基底型 :
項番

親要素

子要素

基底型

1 (element)
2 type.process3

processtype.process

task

type.task

4 type.process5

operation

xs:string

出現回数

意味

システム利用

とりうる値

解説

1 情報消費者への建物の解錠・施錠・状態報告の要求を表す+

個々の要求を表す。複数の task要素を指定することで複数の連続した操作を記述できる。
操作要求を表す。
operation要素とreport要素のどちらか一方を記述しなければならない。

下記の表の組み合わせで操作を要求できる。
■情報消費者記述子のconsumerClass属性がautomaticShelterManager（自動避難所管理装置）の場
合(object) : (operation) => (要求の意味)
buildingLock : lock => 建物の入り口を施錠せよ
buildingLock : unlock => 建物の入り口を解錠せよ
light : on => 照明を点灯せよ
light : off => 照明を消灯せよ■情報消費者記述子のconsumerClass属性がautomaticMailSender （メーラー）の場合(object) : (operation) => (要求の意味)
省略 : postNotification => 避難者の状況をメールで支援者に通知せよ?

6

report?

7

object*状態報告要求を表す。
operation要素とreport要素のどちらか一方を記述しなければならない。
操作の対象となる機器の種別

8 (end)23

コモンズEDXLデータモデル
commons: targetArea
targetArea
EDXLDistribution
0..*

distributionID
senderID
dateTimeSent
distributionStatus
distributionType
combinedConfidentiality
languagesenderRole *recipientRole *keyword *distributionReference * #explicitAddress *jisX0402
ooAzaTyouTyouMokuCode
areaName
areaNameKana

circle *polygon *country *subdivision *locCodeUN *commons:contentObject
publishingOfficeName
publishingOrganizationName
publishingOfficeID
publishingOfficeDomainName
documentRevision
documentID
categoryurgency
severity
certainty

contentObject
0..*contentDescription
contentKeyword *incidentID
incidentDescription
originatorRole *consumerRole *confidentiality
other *

1deliveryInformation
messageURI
description
maximumDeliveryTimesdeliveryTimes
firstDeliveryDate
lastDeliveryDate
deliveryStatus

1

nonXMLContent
mimeTypesize
digesturi
contentData

xmlContent
OR

keyXMLContent
embeddedXMLContent

task
serviceName
topicID
taskStatus
captiontype
applicantapplicantRole

cometEDXL: task
CometEndpoint.PushTopicName

凡例

EDXL-de定義要素
コモンズEDXL定義要素

CometEndpoint.PushMessageURI
CometEndpoint.MessageSentTime

24

0..*

0..*

received
nodeIdreceivedTime

endpointID