公衆警報の様式統一と放送

公衆警報の様式統一と放送
~米国の CAP 導入と気象庁 XML ~
メディア研究部
1. はじめに
福長秀彦 警報が高度化すれば,情報量が増え,その
体系も複 雑なものとなるが,放送事業者や自
インターネットや地上デジタル放送,携帯ネッ
治体からすれば,送られてくる警報が利用しや
トワーク,ワンセグなどマルチメディア化が進む
すく,公衆や住民に分かりやすい形で配信で
中にあって,世界各国ではデジタルの特性を生
きることが重要である。また,システムの異な
かして警報や緊急情報を如何に手際よく公衆に
る各メディアに効率良く・迅速に伝送できるも
伝えるか,公衆警報システムの見直しが進めら
のでなければならない。そこで計画されている
れている。
のが,マークアップ 言 語のXML(Extensible
この背景としては,警報を配信するメディア
が多様化してきたことの他に「警報の高度化」
Markup Language)を利用した警報伝送様式
である。
がある。警報は観測(警戒)網の整備とデータ
アメリカでは,政府機関や州政府,自治体
処理技術の進展によって,より詳細化し,地理
が発信する警報を,XMLをベースにした CAP
的あるいは時系列的に細分化が進む傾向があ
(Common Alerting Protocol)という様式に統
る。この傾向は,過去の知見が豊富でデータ
一し,放送やインターネット,携帯などの商用
ベース化が比較的容易な自然災害の分野で顕
移動体通信,自治体のサイレンシステムなどに
著である。
伝送するナショナルプロジェクトが進行中であ
例えば日本の大雨警報は,本稿執筆時点の
る。一方,日本でも気象庁がこれまで警報ごと
2009 年12月現在では,都道府県を374 のブロッ
に異なっていた様式をXML によるものに統一
クに細分化した「二次細分予報地域」まで発表
し,2010 年から順次実施する見通しである。
されている。しかし2010 年の5月下旬からは,
本稿では,
「多メディア化」や「警報の高度化」
更に細かく1,777の市町村区分ごとに(東京 23
と「様式統一」との関係を明らかにすると共に,
区では区ごと)警報が出される予定である。また
検 討されている様 式の構造をCAPと気 象 庁
予想される被害別に大雨警報(土砂災害)と大
XMLで比較し,警報伝達に対するアプローチ
雨警報
(浸水害)に分けられることになっている。
の相違を論じる。
36
APRIL 2010
2. XML と警報配信
その下に< 名前 >・<情報 >・< 地域 群 > の各
XMLとは何か,先ずは簡単に説明しておき
リー構造(階層構造)になっている。
たい。
2(1)マークアップ言語の XML
XML はマークアップ言語の1つである。マー
クアップ言語はデジタル情報を文書として共有
したり交換したりするためのものである。コン
要素,< 地域群 > の下に< 地域 > 要素が…とツ
この文書のツリー構造を図 2 に示す。頂点に
位置する<災害 Hazard>はルート要素と呼ば
れ,言わば大本のフォルダのようなものである。
ツリーを構成する情報要素や内容,属性は node
(葉がでる節の意味)と呼ばれる。
ピューターネットワーク上でデジタル情報が共
HTMLと違って XML はタグに情報要素名を
有・交換されるためには,文書の構造が統一
自由につけることができる。情報体系をオーダー
されていなければならない。この文書の構造を
メイドで柔軟に決められる。しかし,ユーザー
取り決めるのがマークアップ言語である。ウェ
によって情報要素名のつけ方などが異なってい
ブのホームページ作成で馴 染み深いHTML
ては,情報共有が困難になる。そこで,実際
(HyperText Markup Language)もその1つで
に使われる場合は,文書構造の厳密な取り決
ある。
めが XML Schemaなどのスキーマ言語によっ
てなされる。
2(2)XMLの仕組み
XMLでは,情報の要素を開始タグ
<>と終了タグ</>で括る。情報要素
の名前○○は開始タグと終了タグの中
に< ○ ○ >,</○ ○ > のように書き
込む。開始タグと終了タグの間に内容
(content)を記 述する。内容は文字
や数字である。また情報要素に付属
する性質は属性として開始タグの中に
< ○○ 属性名 =" 属性値 ">と書く。
例えば図 1 のXML文書のうち,<
名前 > ○ ○ 警 報 </名前 >は情 報要
素の一つであり,名前は情報要素名,
○○警報は内容である。また情報要
素の < 警 報 発 表機 関=" ☆ ☆ 庁 ">
~ </ 警報 > のうち,発表機関=" ☆
☆庁 "の部分は属性である。
図1をよく見ると<災害 Hazard>と
いう要素の下に<警報 > 要素が,更に
図 1 XML 文書の例
<?xml version="1.0" echoding="shift-JIS" ?>
< 災害 Hazard>
< 警報 発表機関= " ☆☆庁 ">
< 名前 > ○○警報 </ 名前 >
< 情報 > ○○災害によって
大きな被害が予想され、
厳重な警戒が必要です。</ 情報 >
< 地域群 >
< 地域 >
< 名前 > ××市 </ 名前 >
< 情報 > ○○災害によって大きな被害が
予想され厳重な警戒が
必要です </ 情報 >
</ 地域 >
< 地域 >
< 名前 > △△市 </ 名前 >
< 情報 > ○○災害によって大きな
被害が予想され厳重な
警戒が必要です </ 情報 >
</ 地域 >
</ 地域群 >
</ 警報 >
< 警報 発表機関= " ☆☆庁 ">
< 名前 > ◎◎警報 </ 名前 >
・
・
・
</ 警報 >
</ 災害 Hazard>
APRIL 2010
37
になる。
図 2 XML のツリー構造
ただ,XML はデータを自在に分
災害 Hazard "/"
類できる“自由の代償”として,開
始タグ< ○○ >で始まる情報要素は
必ず終了タグ</○○ >で閉じなけ
警報
名前
情報
○○警報
TEXT
警報
発表機関
ればならないなどの掟がある。タグ
発表機関
を使って文書の構造を厳密に定義
しなければならない分だけ素材の
以下略
地域群
データ量に比べて情報量が嵩んで
しまう。
"/" ルート要素
地域
情報要素
(各)
地域
内容
属性等
名前
情報
名前
情報
△△市
TEXT
××市
TEXT
3. 米国の公衆警報
システムと放送
アメリカでは,第二次大戦後の
冷戦時代から今日に至るまで,放
送が公衆警報システムの主役を務
めてきた。
放送やインターネット,携帯など
2(3)何故XMLなのか
XML が警報伝送の様式として採用された理
各メディアを統合した次世代型システムの要と
なるCAP(XMLベース)を理解するためには,
由は,HTML に代わる言語として利用が増え
アメリカにおける公衆警報システムの成り立ち
ていることにもよるが,情報量が増えて複雑化
と発展を踏まえておく必要がある。
する警報を,分かりやすく自在に仕分けして提
供できることによる。
3(1)旧世代の公衆警報システム
ツリー構造が厳密で整然としたものとなれ
アメリカでは,1951年にトルーマン大統領の
ば,放 送・通信事 業者や自治体など情報の
指示によって,放送を利用した最初の公衆警
受け手は,警報のカテゴリーや緊急度,エリ
報システムが作られた。このシステムは,核爆
ア別の検 索 が 容易になるであろう。XML に
弾を搭載したソビエトの爆撃機の侵入を市民に
よる文書を別の形式の文書に変換するスタイ
知らせるためのもので,CONELRAD(Control
ルシート言 語 のXSL(Extensible Stylesheet
of Electromagnetic Radiation)と呼ばれた1)。
Language)やインターフェースのDOM(Docu-
空軍が警報信号を専用の電話回線で特定のラ
ment Object Model)を使えば,送られてき
ジオ局に伝えると,特定局は事前に決められた
た警報の中から必要なデータを取り出して,公
警報文を放送する。警報文は電話などで他の
衆や住民に分かりやすい形に加工できるよう
ラジオ局に次々とリレーされるというシンプルな
38
APRIL 2010
システムであった。また,特定の周波数による
る。EAS が起動すると,上記のメディアは番組
電波の ON-OFFによって,敵機の電波探知航
を中断し警報を視聴者に伝える。
法をかく乱することになっていた。
起動のケースは①国家の非常時の際に大統
そ の 後,I C B M( 大 陸 間 弾 道ミサイル:
領ないしは大統領に指名された者が全国民に
InterContinental Ballistic Missile)が 開 発さ
向けて警報を発信する場合,②州や地方(通
れて爆撃機による核攻撃の可能性が少なくなっ
常は郡単位)の機関が住民に向けて気象災害
たことなどから,1963 年に第二世代の警報シス
や人災,子供の誘拐や失踪に関する警報を発
テム のEBS(Emergency Broadcast System)
信する場合,である。このうち①は旧世代のシ
にとって代わられた 。
ステムによる時代を含め,2009 年12月末日に
2)
EBS は,戦争の脅威など国家の一大事に大
統領が公衆に呼びかけるためのものだが,後
至るまで起動の実績はない。②は正確な統計
はないが,多数の起動実績がある。
年には地方レベルの緊急事態や気象警報など
EAS によって伝送される警報メッセージは,
に活用されるようになった。CONELRADと
(a)デジタル化で符号化されたヘッダー,
(b)
違ってテレビ局のネットワークも参加していた。
トーン(音)による注意信号,
(c)音声による警
大 統領が国家レベルのEBS 起 動を決める
報アナウンスメント,
(d)デジタルで符号化され
と,連邦機関が専用回線でラジオ・テレビの
たエンドマーク,から成る。これらは,いずれ
ネットワーク主要局に連絡する。主要局は可聴
も各メディアによって変調されて送信される。
域の2 つの周波数から成るアナログの注意信号
このうち重要なのは(a)で,ヘッダーには警
を,それより周波数が高い電波にのせて各局に
報の発信者や警報の対象となるハザード(戦
送信する。これを各局がキャッチすると,受信
争の脅威や自然災害,大事故といった危険を
した電波から元の信号を取り出す復調器がアン
もたらすもの)の説明,被害が予想される地
ロックされる。各局はリスナーの注意を惹きつ
域,EAS の起動日時などの情報が 1と0 の組
けるため,復調した注意信号のトーン(音)を
み合わせで記述されている。デジタルの符号
手動で放送し,直ちに番組を中断する。このあ
化によって番組の中断や警報メッセージの送信
と,連邦機関から主要局経由で伝えられる大
が自動化された。またテレビ局や CATVが警
統領のメッセージを伝える仕組みになっていた。
報の内容を字幕でスムーズに伝えられるように
EBS は1997年に第 3 世代のEAS(Emergency
なった。
Alert System)に更新された。
EAS による警報メッセージの基本的な流れ
を図 3 で説明する4)。
3(2)第 3 世代の EAS
❶大統領が全国民に向けて警報を発するこ
本稿執筆時点の2009 年12月現在,EAS は
とを決めると,FEMA(連邦緊急事態管理庁:
現役世代の公衆警報システムである 。警報配
Federal Emergency Agency)が EASを起動
信メディアはラジオ(AM・FM・デジタル・衛
し,PEP(Primary Entry Point)に通知する。
星デジタル)
,テレビ(地上波・衛星)
,CATV(有
❷このPEPというのは,特別に指定された
線系・無線系)
,ケーブルプロバイダーなどであ
商業ラジオ局(AM,FM)などで 37局ある5)。
3)
APRIL 2010
39
❺ そ の 他 の 局 は,LR(LP)
図 3 EAS の概略
の送信した周波数をキャッチし
PEP
FEMA
❷
て,自動的に番組を中止し,視
❶
聴者に警報メッセージを伝える。
❻ N WR(NOAA Weather
SR
(SP)
州政府
❸
R a d i o )というのは,N OA A
(米国海洋大気圏局:Nationa l
Ocea nic a nd At mospheric
LR
(LP)
LR
(LP)
地方機関
❹
NWS
Administration)のNWS(気
象 業 務 部:NOA A Weather
Service)が 運営しているラジ
オである。各地方にあるNWS
NWR
・・・・・・
視聴者
・・・・・・・
・・・・・・
・・・・・・
・・・・・
・・・・・・
・・・・・・・
❻
❺
各局
は 地 方 レ ベ ル の 気 象 警 報を
NWR で出している。各放送局
や CATV は NWR による気 象
警 報の周波 数をキャッチする
機器を備え,これによって気象
注 州レベル地方レベルを分かりやすくするため系統図をシンプルにしてあるが,
実際には SR- 各局間,PEP-LR 間等のリンクもあり複雑である。
警報を放送している。警報メッ
セージのデジタル 符 号は EAS
と NWR で互換性がある。
他の局と同様に番組を中断してリスナーに警報
を伝えるが,PEPとしての役割は,階層構造の
3(3)EAS の脆弱性
下位局に前述(a)のヘッダーから(d)のエンド
EAS については GAO( アメリカ会 計 検 査
マークまでを特定の周波数で順次送信すること
院 :Government Accountability Office)が そ
である。
の脆弱性を指摘している6)。GAO の報告による
❸ SR(State Relay)は,商業ラジオ局ある
と,国家的非常時の場合にFEMAは地上回
いは州政 府が運営するVHFやUHF局,マイ
線によって前述のPEP37局に警報を通知する
クロ回線の親局である。州内の下位局に警報
が,このリンクに失敗すると,警報メッセージ
メッセージをリレーする。州政府レベルで警報
のリレーは成 立しなくなるとしている。 また
メッセージが出される時の起点と成る場合は SP
PEPによってカバーし切れない遠隔地の放送局
(State Primary)と呼ばれる。
❹ LR(Local Relay)も商業ラジオ局などで,
は,衛星回線ネットワークの公共ラジオ局経由
で警報を入手しているが,公共ラジオ局は PEP
1つもしくは複数の郡から成る地方エリアの下位
のように非常用の燃料や発電機などを必ずしも
局をカバーする。地方機関レベルの警報の起点
完備している訳ではないので,信頼性が十分と
となる場合は LP(Local Primary)となる。
は言えないと指摘している。
40
APRIL 2010
また EAS に携 帯などの 通 信メディアが 加
も警報が届くようにする。
わっていないことや放送の特性から被害が予想
図 4 に IPAWS の概念図を示す。図 4 の警報
される地域を選別して警報を配信できないこと
配信システムのうち,EAS は IPAWS によって
を問題点として挙げている。
前述のPEPを現在の37局から74 局にまで増や
FEMA 自身も新しい公衆警報システム構築
し,人口の 90%までカバーできるようにする計
に関する文 書の中で,次のように記述してい
画である。また伝送ルートを多様化するため民
る 。
間ラジオ局の衛星回線ネットワークと接続するこ
7)
「最近の調査によると,TVやラジオでは平
日は住民の 40%にしか届かず,夜中は12%し
とになっている。
デジタルEASというのは,可聴域の周波数
かテレビを見ていない。ラジオでは 5%になる。
によって音声ベースの警報メッセージを伝える
テレビ・ラジオは公的な情報の重要なsourceで
EAS のデジタル化を促進しようというものであ
あり続けるだろうが,その影響力は減ってきて
る。 公 共 テレビ(PBS : Public Broadcasting
いる。放送によるエリアの絞込みは州や一定の
Service)の地上デジタル網を使って,音声だけ
地域単位に限られている…」
。
でなく静止画やビデオ,テキストデータなどで警
報メッセージを配信する。FEMAと公共テレビ
4. 米国の次世代型システムとCAP
4(1)IPAWS
8)
局の団体であるAPTS(Association of Public
Television Stations)は既に協力協定を結び,
州や地域レベルのパイロット事業が進行中であ
9.11同時 多 発テロや 2005 年のハリケーン・
る。将来はこのデジタルEAS で配信される警
カトリーナなどを契機として,放送に依存した
報メッセージを商業放送網や携帯ネットワーク
公衆 警 報システムを見直す機運が 高まった。
などにも転送することを視野に入れている。
FEMAは 2004 年から次世代 型の警 報ネット
CMAS(Commercial Mobile Alert System)
ワークインフラであるIPAWS(統合公衆警報シ
は携帯や無線呼出し(beeper)などの商用移動
ステム:Integrated Public Alert and Warning
体通信を結集した新たな警報システムである。
System)の構築に着手した。2006 年には,ブッ
FEMAやFCC,関係する通信事業者による委
シュ大統領が新たな警報システムを求める特別
員会がシステムに必要な技術要件や手順を盛り
命令(Executive Order)を出した。
込んだ勧告をまとめ,これに基づいて FCC は
IPAWS の目標は以下の通りである。
㋑ 多様なメディアを結集して警報配信ルートを
多様化する。
㋺ 大 統領が全国民に向けて警報を発信するの
を確実にする。
㋩ メディア間の相互運用性を確保する。
運用のための規則(REPORT AND ORDER)
を策定している。
図 4 には明 示していないが,IPAWS では,
自然災害や人為的な事故によって被害の及ぶエ
リアを迅速・的確に特定し,関係機関に連絡
するソフトも開発することになっている。GTAS
㋥E
AS など既存のシステムを強化・高度化する。
(Geo-Targeted Alerting System)と呼ばれる
㋭ 障害を持つ人達や英語を理解しない国民に
このソフトでは,化学プラントや原子力施設な
APRIL 2010
41
図 4 IPAWS の概念図
警報発信者
警報配信システム
EAS
連邦機関
デジタルEAS
IPAWS
インターネット
州政府
NWR(NOAA)
Aggregator
地方機関
CAP
(IP 経由)
公
衆
CMAS
CAP
(IP 経由)
サイレン・
電子掲示板 etc
注 Integrated Pubic Alert and Warning System(IPAWS)Overview and
Commercial Mobile Alert System(CMAS)introduction(2009 年 8 月より作成)
どの事故で,有毒物質や放射性微粒子が環境
ムごとに,いちいち別々の様式で送っていたの
中に漏れ出した場合に,それらの移動範囲を
では,効率よく迅速な伝送はできない。一度
予測し,影響のあるエリアに限って警報を出す。
に各システム同時に送れるようにしたい。そこ
これはシステムというより警報の情報内容が高
で警報を伝送する際の様式が統一されること
度化する例である。
になる。これが CAP である。
図 4 に戻る。連邦機関や州政府,地方機関
は警報メッセージを一旦 IPAWS のAggregator
4(2)CAP のバックグラウンド
に送る。Aggregatorでは送られてきた警報が
アメリカ大統領府にあって,国家安全保障会
法令に基づく然るべき機関から適正な手続き
議などと並ぶ重要な機関であるNSTC(国家科
によって発信されたものであることを認証する。
学技術会議 :National Science and Technology
警報メッセージが複数である場合には,優先
Council)は 2000 年11月,
“effective Disaster
順位(Priority)をつけて各メディアの配信シス
Warnings”に関する報告書を公表した9)。
テムに転送する。
何 故 Aggregatorを 一 旦 経 由 す る の か。
この報 告 書の中で NSTC は,
「あらゆる種
類の警報を即座に,自動的に収集して広範な
Aggregator がなければ,警報の発信機関はそ
種類の警報配信システムにリレーできる標準的
れぞれが配信メディアへの伝送路を確保しなけ
な様式が開発されるべきである」と勧告した。
ればならなくなる。
NSTC の勧告を受けて,翌年から防災機関の
更に, 警 報発 信 機 関やAggregatorにとっ
関係者や情報 通信技術の専門家から成るグ
て,同じ内容の警報を各配信メディアのシステ
ループが CAPのデータ構造の原型を作る作業
42
APRIL 2010
を開始した。その後,実地試験や長期のデモ
を構成するすべての情報要素・nodeを格納する
ンストレーションが重ねられた。
ルート要素である。大本のフォルダであるので,
2004 年 4月には,XMLなどの標準仕様を策
1つの CAPメッセージにつき<alert>は常に1
定 する国 際 組 織 のOASIS(Organization for
つである。<alert>に含まれる情報要素のうち,
the Advancement of Structured Information
<identifier>はメッセージのIDを,<sender>
Standard)が,CAP Version1.0を国 際 標 準
は警報を発信した機関名を内容とする。
仕様として採択した。更に2007年には,ITU
ま た<alert> に は,<info>ブ ロック が 1
( 国 際 電 気 通 信 連 合 : I nternationa l Tele -
つないしは 複 数 含まれ る。<info>ブ ロック
communication Union)が CAPをITU 勧告と
は CAPメッセージの本 文 である。 このうち
して採択した。
<category>は気 象 災害 や火 災, 健 康 被 害,
2008 年 にFEMAは IPAWS の 運 用 にCAP
テロ,インフラ被害といったようにハザードを
を使うことを公表した。CAPは国際標準であ
コード名で類別したものである。また<event>
るので,アメリカだけでなくカナダやスリランカ
は災害の具体的な名前を示す。<effective>は
でも公衆警報システムに使われている。
警報が有効と思われる時間帯,<description>
2 0 0 9 年 12月現 在,CA P の 最 新 版はVersion1.2 である。Version1.0 ~ 1.2 は標準 仕様
(Standard)であり,実際に使う場合には,各
国の警報配信システムにうまく適合するように
は人 間が 判 読 可 能な災害 についての 記 述,
<response Type>は避難など推奨される対応
策のコードを示す。
<info>ブロックでユニークなのは<urgency>,
Standardのサブ仕様が作られている。IPAWS
<severity>,<certainty>の3 つの情報要素を
の場合でも,EAS や CMASといった各システ
備えていることである。このうち<urgency>は
ムにCAPを実装するためのサブ仕様が作られ
ハザードの緊急性を示すもので,対応の緊急
ているが,本稿では,根幹である Standardを
度 順 にImmediate,Expected,Futureな ど
先ずは俎上に乗せて,構造と特徴を明らかに
のコードを持 つ。<severity>はハザードの強
したい。
度 を 示 しExtreme,Severe,Moderateな ど
で,<certainty>はハザードが起きる確実性で
4(3)CAP(Standard)の構造
CAPは XMLで 記 述されて いる。 従って2
(2)で述べたようにツリー構造(階層構造)を
Observed,Likely,Possibleなどのコードによっ
て表される。
警報の重要度や優先順位(プライオリティ)
持 つ。図 5 にCAP のツリー構造を示 す。 図 5
は,伝統的にはハザードの強度といった単一
を 見 る とCAPは<alert>,<info>,<area>,
の指標から決められることが多いが,CAPの
<resource> の 4つの情報要素のブロックから
St a nd a rd で は<urgency>,< s ever it y>,
構成されていることが分かる。それぞれのブ
<certainty> の3 つの情報要素を使って言わば
ロックは情報要素のファイルを格納するフォルダ
3 次元でプライオリティが決められる。
のようなものと考えれば良いだろう。
このうち頂点に位置する<alert>は,ツリー
これは,それぞれの頭文字をとって U/S/Cモ
デルとも呼ばれる。図 6 にモデルの概念を示す。
APRIL 2010
43
図 5 CAP のツリー構造
alert "/"
CAP
Version
identifier
sender
sent
scope
メッセージ ID
発信機関名
日付
対象
・・・・・・
category
event
effective
description
response Type
ハザード類別
ハザード名
時間
TEXT
対応行動
urgency
severity
certainty
緊急性
強度
確実性
注① OASIS Common Alerting Protocol Version
1.1 及び 1,2 より作成
②“/”○□△の各記号は図 2 参照
③・・・は中略の意
・・・・・
info
・・・・・
area
resource
area Desc
circle
TEXT
圏域
geocode
・・・
地理コード
resorce Desc
size
ファイル種別
大きさ
uri
・・・
URL
図 6 U/S/C モデルの概念
図 5 のツリー構造に戻る。<info>ブロック
には 警 報 の 対 象 地 域 を 示 す<area>ブ ロッ
クが 1つないし は 複 数 含 まれ る。 このうち
ハザード
(event)
<areaDesc>は地域名をテキスト形式で記述す
る。<circle>は中心点と半径を持つ被災予想
要素が用意されている。
<resource>ブロックは,警報に付随する地
ty
in
み,細分化するためのコードを持つ各種の情報
rta
ブロックは被災するおそれがある地域を絞り込
ce
を特定するためのコード番号である。<area>
severity
圏を描くための数値コード,<geocode>は地域
図や静止画,音声ファイル,より詳細なデータ
などがネットワークのどのサーバーにあるか参
照させるためにある。<resourceDesc>はファ
44
APRIL 2010
urgency
注 Workshop on ICT Standards for Public Warning-Geneva,2006
Effective Public Warnings and the Common Alerting Protocol(CAP)による
イルの内 容と種 類をテキスト形式で記 述し,
<size>はファイルの 大きさを表す。<uri>は
uniform Resource identifier の略で,インター
5. 気象庁 XML とその構造
5(1)警報の様式統一とXML
ネットのURL(Uniform Resource Locator)が
気 象庁が出す防災情報は,現状では,そ
書き込まれる。図 7 にCAP Standardによる警
の特性に応じて,それぞれ独自のデータ様式
報メッセージの例を示す。
(フォーマット)を持つ。
データ様式は,コードやか
図 7 CAP の例文
な漢字,半角カナ,1と0 から
成るバイナリー,などの単独
<?xml version = "1.0" encoding = "UTF-8"?>
<alert xmlns = "urn:oasis:names:tc:emergency:cap:1.2">
<identifier>KSTO1055887203</identifier>
<sender>KSTO@NWS.NOAA.GOV</sender>
<sent>2003-06-17T14:57:00-07:00</sent>
<status>Actual</status>
<msgType>Alert</msgType>
<scope>Public</scope>
<info>
<category>Met</category>
<event>SEVERE THUNDERSTORM</event>
<responseType>Shelter</responseType>
<urgency>Immediate</urgency>
<severity>Severe</severity>
<certainty>Observed</certainty>
<eventCode>
<valueName>SAME</valueName>
<value>SVR</value>
</eventCode>
<expires>2003-06-17T16:00:00-07:00</expires>
<senderName>NATIONAL WEATHER SERVICE SACRAMENTO
CA</senderName>
<headline>SEVERE THUNDERSTORM WARNING</headline>
<description> AT 254 PM PDT...NATIONAL WEATHER SERVICE DOPPLER RADAR INDICATED ==(中略)== </description>
<instruction>TAKE COVER IN A SUBSTANTIAL SHELTER UNTIL
THE STORM PASSES.</instruction>
<contact>BARUFFALDI/JUSKIE</contact>
<area>
<areaDesc>EXTREME NORTH CENTRAL TUOLUMNE COUNTY IN
CALIFORNIA ==(中略)== </areaDesc>
<polygon>38.47,-120.14 ==(中略)== </polygon>
<geocode>
<valueName>SAME</valueName>
<value>006109</value>
</geocode>
<geocode>
<valueName>SAME</valueName>
<value>006009</value>
</geocode>
</area>
</info>
</alert>
あるいはそれぞれの組み合わ
せから成る。また「気象警報・
注 意 報 」や「 府 県週 間 天 気
予報」などは,かな漢字・半
角カナによるコードに加えて,
XMLでも送信されているが,
それらのXMLは,種類が異
なる防災情報の間で必ずしも
様式の統一が図られている訳
ではない。
一般的には,様式が異なる
データの間に互換性はない。
従って,それぞれの様式ごと
にデータを判読するソフトが
必要となる。
しかし, 防災情 報の種 類
が多くなってくると,気象庁
から情報を受け取って住民や
視聴者に配信する自治体や放
送事業者などにとっては,多
岐にわたる防災情報を1つの
汎用ソフトで処理できるよう
になった方が便利である。
そこで, 気 象 庁では, 各
種防災情報のデータ様 式を
注① OASIS Common Alerting Protocol Version1,2 Public Review Draft02 AppendixA より抜粋作成
② <resource> ブロックはオプションのため不使用
XML による新たなフォーマッ
APRIL 2010
45
トに統一することを決めた。その対象となる防
文が確実に送受信されるかどうか検証した。
災情報は,
「気象警報・注意報」
,
「台風情報」
,
気象庁では,2010 年の 5月下旬から市町村
「津波警報・注意報」
,
「緊急地震速報」
,
「地
区分ごとに出されることになっている大雨警報
震速報」
,
「噴火警報・予報」
,
「天気予報」
,
「週
などから新たなXMLフォーマットによる送信を
間天気予報 」などで,気象庁が出す警報がす
開始し,2011年 3月からは,対象となる防災情
べて網羅されている。
「気象警報・注意報」な
報をすべて XML の統一様式で伝送できるよう
どに使われている現行のXMLも,情報要素の
にする方針である。
名前などを統一した新XMLフォーマットに改め
5(2)気象庁 XML の構造
られる。
図 8-A に気 象庁 XMLフォーマットのツリー
XMLを使う理 由は,2(3)で 述べた 通り,
高度化し複雑なデータ
構造を持つ防災情報で
図 8-A 気象庁 XML のツリー構造
あっても住民や視聴者
に分かりやすい形に加
Report "/"
工したり,抽出したり
名前空間
Version
することが容易なため
である。
Control
気 象 庁 は 2008 年2
Head
Body
月か ら,XML の 普 及
推 進団体であるXML
Title
コンソーシアムと協力し
情報名
て,フォーマットの策
・・
DateTime
日付
・・
定に着手した。気象庁
Title
運用種別
標題
対象区域等
とXMLコンソーシアム
では,これまでに 2 度,
Status
・・
Item
Item
以下略
以下略
・・
Target
Headline ・・ DateTime ・・
Information
Item
基点時刻
Info
Type
情報形態
Text
見出し文
フォーマットのドラフト
を公開して一般から意
見を募集し,2009 年 5
Kind
Areas
月に完成版である「気
象 庁 防 災 情 報 XML
フォーマットVer1.0」を
Name
Code
警報名等 コード番号
Condition
コードタイプ
Area
予想災害
公表した。この後,様々
Name
なOSのサーバーを使っ
地域名 コード番号
てテストを行い,Ver1.0
に基づくサンプル警報
46
APRIL 2010
Code
注①気象庁防災情報 XML フォーマット Ver1.0 より作成
② “/”○□△の各記号は図 2 参照
③・・・は中略の意
構造を示す。図 8-Aを見ると,気象庁 XML は
<Control> 部は,情報処理と送受信を行う
<Report>,<Control>,<Head>,<Body> の
サーバーに基本的な制御情報を提供するもの
4つの情報要素のブロックから構成されている
で,5つの情報要素から成る。このうち<Title>
のが分かる。
には,
「気象警報・注意報」
,
「津波警報・注意
頂点に位置する<Report>は,すべての情報
報・予報」
,
「緊急地震速報」
,
「噴火警報・予
要素・nodeを格納するルート要素,言わば大本の
報」といった具合に情報の種類が記述される。
フォルダである。その下に<Control>,<Head>,
<DateTime>は情 報を作 成・発 信した時 刻,
<Body>の3ブロックが順番に同格の子要素とし
<Status>は送信される情報の運用種別を示し,
て配置されている。この3 つは,<Report>中に
「通常」
,
「訓練」
,
「試験」などを内容とする。
それぞれ1つしか書くことができない。
<Head> 部は,情報の概要を簡潔に示すた
めにある。自治体や放送事
図 8-B 気象庁 XML のツリー構造(Body 部:市町村への大雨警報の例)
業者は<Head> 部を処理す
ることによって,どのような
警報が,どの地域を対象に
Report "/"
出され,いつからいつまで
警戒が必要か,情報の核心
Body
Warning
Item
<Head> 部は10 の子要素
を 持 ち, このうち<Title>
警報・地域種別
Item
Item
Kind
Name
を把握することができる。
名前空間
報)」などのように記述され
Attention
Name
Code
Note
XX 市
コード番号
大雨警報
浸水害警戒
Type
浸水
Advisory
Period
Precipitation
Part
EndTime
EndTime
Base
Term
24日 夜遅く
Data
25日
Term
朝
る。<TargetDateTime>
は災害が い つ から予 想さ
れ る か 基 点 とな る 時 刻,
<InfoType>は,
「 発 表 」,
Warning
Period
Data
気象警報・注意報」,
「津波
警報」,
「緊急地震速報(警
Area
Property
は表 題で,例えば「××県
「更新」,
「訂正」,「 取消」な
ど情報の形態を表す。
<Headline>は 見 出し に
相 当し, 下 部 構 造 として
Jmx_eb:Precipitation
80
1 時間雨量
単位(ミリ)
注①気象庁防災情報 XML フォーマット Ver1.0 気象警報・注意報サンプル電文より抜粋作成
②情報内容□内は具体例
<Text>と<Information>
の 子 要 素 を 持 って い る。
<Text>は放 送の字幕スー
パーに使われるような見出
APRIL 2010
47
し文 で あ る。<Information>は, 孫 要 素 の
ぞれ情報の種類に応じて最適のスタイルを持ち,
<Areas>以下で対象となる地域を,同じく孫
共通ではない。図 8-B は大雨警報が市町村に出
要素の <Kind>以下で当該地域に出されている
された場合の<Body> 部である。
警報などの名前・予想される災害(例:浸水・
図 8-B の例文では,××市に大雨警報が出さ
土砂災害)などを仕分けし,記述する。図 8-A
れ,浸水に対する警戒を呼びかける内容であ
では分かりやすく説明するために,<Kind>は
る。<Kind>中の <Name>で大雨警 報が出さ
1つしか書かれていないが,複数書くことがで
れたことが示され,<Attention> の <Note>で
きる。これは気象警報・
注意報の場合に,1つの
図 9 気象庁 XML の例文
地域に大雨警 報や洪 水
警 報, 強 風 注 意 報など
複 数の 警 報・注 意 報 が
出される実情に即応する
ものである。
防災情 報の緊 急性 が
高く,シビ ア な 迅 速 性
が 求められる場 合には,
ル ート 要 素<Report>を
<Control>部 と<Head>
部だけで構成し,図 8-A
右 端 の<Body>部 を 省
略することができる。また
<Control> 部 と<Head>
部の構造はすべてのXML
文書で共通である。
<Body> 部は,防災情
報を更に詳しく伝えるた
めにある。雨量,津波の
高さ,河川の水位と言っ
た量的予想や特記事項
などを提供する。量的予
想の内 容や特 記事 項の
伝え方は,防災情報の種
類によって異なる。ゆえに
<Body> 部の構造もそれ
48
APRIL 2010
<?xml version="1.0" encoding="utf-8" ?>
<Report xmlns="http://xml.kishou.go.jp/jmaxml1/"
xmlns:jmx="http://xml.kishou.go.jp/jmaxml1/"
xmlns:jmx _ add="http://xml.kishou.go.jp/jmaxml1/addition1/">
<Control>
<Title> 気象警報・注意報 </Title>
<DateTime>2009-07-24T08:09:43Z</DateTime>
<Status> 通常 </Status>
<EditorialOffice>×× 管区気象台 </EditorialOffice>
<PublishingOffice>×× 管区気象台 </PublishingOffice>
</Control>
<Head xmlns="http://xml.kishou.go.jp/jmaxml1/informationBasis1/">
<Title>×× 県気象警報・注意報 </Title>
<ReportDateTime>2009-07-24T17:09:00+09:00</ReportDateTime>
<TargetDateTime>2009-07-24T17:09:00+09:00</TargetDateTime>
<EventID />
<InfoType> 発表 </InfoType>
<Serial />
<InfoKind> 気象警報・注意報 </InfoKind>
<InfoKindVersion>1.0 _ 0</InfoKindVersion>
<Headline>
<Text>×× 地方では、24日夜遅くにかけて所により雷を伴った猛烈な雨のおそれがあります。
土砂災害や河川のはん濫、低地の浸水などに警戒して下さい。</Text>
<Information type=" 気象警報・注意報(府県予報区等)">
<Item>
<Kind>
<Name> 大雨警報 </Name>
<Code>03</Code>
<Condition> 土砂災害、浸水害 </Condition>
</Kind>
<Kind>
<Name> 洪水警報 </Name>
<Code>04</Code>
</Kind>
=============(中略)==================
<Areas codeType=" 気象情報/府県予報区・細分区域等 ">
<Area>
<Name>×× 県 </Name>
<Code>400000</Code>
</Area>
</Areas>
</Item>
</Information>
==============(中略)=====================
</Headline>
</Head>
<Body xmlns="http://xml.kishou.go.jp/jmaxml1/body/meteorology1/"
xmlns:jmx _ eb="http://xml.kishou.go.jp/jmaxml1/elementBasis1/">
=============(以下略)=======================
注 気象庁防災情報 XML フォーマット Ver1.0 気象警報・注意報サンプル電文より抜粋,作成
予想される災害が浸水害であり警戒が必要なこ
Markup Language)に変換しなければならな
とが表現されている。
い。インターネットのホームページに掲載する
また<Area>中の <Name>によって××市と
場合には,スタイルシート言語のXSLを使えば
いう地域名が記述されている。実は,ここまで
HTML の形式に変換できる。BMLやHTML
は<Head> 部 の <Information>と重 複 する既
はいずれもXML ないしは同系統のマークアッ
報部分である。新たな情報が付加されている
プ言語であり,変換は比較的容易である。こ
のは<Property>以下である。
の点もデジタルの多メディア時代にあって強みと
<Property>は量的予想などの詳細な事 柄
言えるであろう。
を表す情報要素である。子要素の <Type>は
2(3)で述べた通り,XML はかな漢字や半
どのような災害の量的予想であるかを示し,こ
角カナによる従来型のデータ様 式よりも情報
の 例 で は 浸 水 である。<WarningPeriod>は
量が嵩む。従来型のデータ量は数 kByte ~数
警 戒 を 要 する 期 間 を 示 し,<EndTime>と
10kByteであるが,XMLでは数 10kByte ~数
<Term>で 24日の 夜 遅くまで 浸 水 に 対 する
100kByteに増える。
警 戒が 必 要であることを表している。 また,
その分,情報の処理や伝送には時間がかか
<AdvisoryPeriod>は 警 戒よりも緊 迫 度は低
る。受信するデータ量が多い放送事業者や都
いが注意を要する期間を示し,<EndTime>と
道府県は,情報処理や伝送の速度を考慮に入
<Term>で翌 25日の朝まで注意が必要である
れておく必要があるだろう。
ことを表している。
気象庁では,対象となる防災情報をすべて
<PrecipitationPart>というのは,降水量に
XML 化する2011年 3月以降も,自治体や放送
ついての諸要素を示し,その下の <Base> は
事業者などの準備が整うまでの移行措置とし
最大値など,<jmx_eb:Precipitation> は降水
て,かな漢字などによる形式をしばらくは併用
量のデータを表す。つまり,この例文では 1 時
することにしている。
間当りの最大雨量が 80ミリに達すると警告し
ている。
前述の <Head> 部と同様に,<Property>を
含む <Kind>は複数書くことができる。
図 9 に気象庁 XML の例文を示す。
6. おわりに
CAPと気象庁XMLの比較
最初に断っておくが,ここでの狙いは,優劣
や実効性を比較するものではない。そもそも
5(3)放送事業者などの利用について
警報は国によって異なるし,標準仕様の CAP
放送事業者が XML による防災情報を放送
と“即実践型”の気象庁 XMLを単純に比べる
する場合には,XMLを解読するソフトが必要
ことはできない。ここでは,CAP Standardと
となる。解読されたデータを更に文字や図に変
気象庁 XML の設計思想やバックグラウンドの
換する。従ってソフトの改修が必要となる。ま
違いが構造上の相違点として,どのように反映
たデータ放送で使う場合には,データ放送用
されているのかを見る。警報伝達に対するアプ
のマークアップ 言 語であるBML(Broadcast
ローチの相違を明らかにすることによって,逆
APRIL 2010
49
に,如何なる警報システムの場合に,如何なる
が垂直に深く拡がってゆくニュース記事のよう
アプローチが必要かあぶり出すことができると
な三角形である。この構造は,細分化し複雑
考えるからである。
化した情報を見出しから要領よく伝えるのに適
CAP は,
「 あらゆる種 類の警 報を即座に,
している。このため緊急時でシビアな迅速性
自動的に収集して広範な種 類の警 報 配信シ
が求められる場合には,<Body> 部の省略が
ステムにリレーできる標準的な様 式」という
可能である。CAPの場合も三角形ではあるが,
NSTC の勧告を実現するために策定された。
<info >ブロックに同格の子要素が多数並び,
当然,この勧告を反映し,気象庁 XML には
比較的なだらかな三角形をしている。
ない構造上の特徴を持つ。それらを以下に示
す。
㋩ <Body> 部は防災情報の種類によってそれ
ぞれ最適の構造を持つ。CAPの場合には,タ
㋑ <info>ブ ロックに<category>が 設 定さ
グの名前や情報要素ブロックの使い方は共通
れ,自然災害だけでなく事故やテロを含むす
で,基本的にはoptionalなタグやブロックを加
べてのハザードに対応するよう設計されている。
えたり外したりして最適な構造を組み立てる。
㋺ < i n f o > ブ ロ ッ ク に< u r g e n c y > ,
これに対して気象庁 XMLでは,<Body> 部で,
<severity>,<certainty> が 設 定され, 警
特定の防災情報に対応した固有のタグが作ら
報のプライオリティを明 確 化している。これ
れ,量的予想によるキメ細かな情報伝達を可能
は,政 府機関や州政 府,地方機関などが発
にしている。
信する多様な警報が,Aggregator や各メディ
CAPにしても気 象庁 XML にしても,
「多メ
アによって整 然と順序立てて配信されるよう
ディア化」や「警報の高度化」に対応したもの
にしたものと考えられる。また政 府や自治体
であるが,それぞれの構造の比較から,CAP
が避難などハザードへの対応を指示できるよ
は多様な警報を様々なメディアに幅広く・手際
うに<responseTy pe> や <i nst r uct ion>と
よく送信する特徴を,気象庁 XML は細分化し
いった情報要素を持つ。
高度化した警報を明瞭・迅速に伝える特徴を
㋩地図や静止画,音声ファイルなどを様々な
デジタルメディアが参照できるよう<resource>
ブロックが用意されている。
一方,CAPと比較した場合の気象庁 XML
の構造上の特徴を以下に示す。
持っていることが分かる。
各国の公衆警報システムの形態がその国の
歴史や直面するハザード,メディア事情,技術
レベルなどと,どの程度の相関関係を持つか
は,今後の定性的・定量的研究に委ねなけれ
㋑現行の防災情報の体系を,そっくり使え
ばならないであろう。ただ,アメリカの公衆警
るように作られ,IPAWS など のようにCAP
報システムの歴史的経緯を見ると,戦争やテ
Standardに基づいたサブ仕様を作る必要はな
ロなどの国家的危機に対する強い警戒感が,
い。その意味で最初から精緻な実用型である。
CAP がアメリカで作られ,IPAWS に採用され
㋺ <Head> 部から<Body> 部にかけて情報
た背景の1つとして考えられよう。
内容が一部重複しながら,詳細になってゆく構
また気象庁 XMLが細分化し高度化した警
造を持つ。気象庁 XML の全体構造は情報量
報をクリアに迅速に伝えようとするのも,秒単
50
APRIL 2010
位の速報性が求められる津波や大地震などを
日本人が過去に幾度も経験してきたことが背景
にある。
最近は日本でも,愛知県や三重県などで,
県や市町村が出す避難情報や被害状況,災害
対策本部の設置状況のほか,交通やライフライ
ンなどの情報を一括して収集し,XMLを使っ
た共通様式で放送局や新聞社,CATV,携帯
事業者などに伝送しようという実証実験が既に
始められている10)。将来的には,気象庁 XML
も含め,多数の防災機関からの情報を収集する
日本版 Aggregator が出現する可能性もある。
その時には,CAPに見られるようなアプローチ
が考慮されるかも知れない。
(ふくなが ひでひこ)
注:
1)米 国の NPO である Pa rt nersh ip for P ublic
Wa r n i ng の 報 告 書 The Emergency Alert
System(EAS):An assessment などによる。
2)前掲 1 の他に State of California Emergency
Alert System(EAS)
〈http://eas.oes.ca.gov/〉
など。
3)前掲 1 及び FCC Consumer Facts/The Emergency Alert System(EAS)
,FCC's EAS Web
page〈http://www.fcc.gov/pshs/services/eas/〉
などによる。
4) 前 掲 1.3 及び CA L I F O R N I A H o m ep a g e
の EMERGENCY ALERT SYSTEM
F R EQU ENTLY A SK ED QU E S TION S
〈http://eas.oes.ca.gov/Pages/easfaq.htm〉など
による。
5)FEMA「Integrated Public Alert and Warning
System(IPAWS)」IPAWS Project による。
EAS は公共ラジオ局の衛星ネットワークとも
リンクしているが,これは PEP の第 3 層とし
て 37 局には含まれない。
6)GAO-09-1044T EMERGENCY PREPADNESS
「Improved Planning and Coordination
Necessary for Development of Integrated
Public Alert and Warning System。
7)FEMA「Integrated Public Alert and Warning
System(IPAWS)
」
“IPAWS Background”
。
8)I PAW S に つ い て は F E M A「 I n t e g r a t e d
Public Alert and Warning System(IPAWS)」
〈http://www.fema.gov/emergency/ipaws/
systemenhancements.shtmn〉
などを参考にした。
9)NSTC Report on“Effective Disaster Warnings”
(November, 2000)
。
10)総務省所管の安心・安全公共コモンズ実証実
験。XML を使った共通様式とは TVCML(TV
Common Markup Language)
。
APRIL 2010
51