2. XML と警報配信 XML とは何か, 先ずは簡単に説明しておきたい 2(1) マークアップ言語の XML XML はマークアップ言語の 1つであるマークアップ言語はデジタル情報を文書として共有したり交換したりするためのものであるコンピューターネットワーク上でデジタル情報が共有交換される

Size: px

Start display at page:

Download "2. XML と警報配信 XML とは何か, 先ずは簡単に説明しておきたい 2(1) マークアップ言語の XML XML はマークアップ言語の 1つであるマークアップ言語はデジタル情報を文書として共有したり交換したりするためのものであるコンピューターネットワーク上でデジタル情報が共有交換される"

あおいますはら
5 years ago
Views:

1 公衆警報の様式統一と放送 ~ 米国の CAP 導入と気象庁 XML ~ メディア研究部福長秀彦 1. はじめにインターネットや地上デジタル放送, 携帯ネットワーク, ワンセグなどマルチメディア化が進む中にあって, 世界各国ではデジタルの特性を生かして警報や緊急情報を如何に手際よく公衆に伝えるか, 公衆警報システムの見直しが進められているこの背景としては, 警報を配信するメディアが多様化してきたことの他に警報の高度化がある警報は観測 ( 警戒 ) 網の整備とデータ処理技術の進展によって, より詳細化し, 地理的あるいは時系列的に細分化が進む傾向があるこの傾向は, 過去の知見が豊富でデータベース化が比較的容易な自然災害の分野で顕著である例えば日本の大雨警報は, 本稿執筆時点の年 1 2 月現在では, 都道府県を 3 74 のブロックに細分化した二次細分予報地域まで発表されているしかし 2010 年の5 月下旬からは, 更に細かく1,777の市町村区分ごとに ( 東京 23 区では区ごと ) 警報が出される予定であるまた予想される被害別に大雨警報 ( 土砂災害 ) と大雨警報 ( 浸水害 ) に分けられることになっている警報が高度化すれば, 情報量が増え, その体系も複雑なものとなるが, 放送事業者や自治体からすれば, 送られてくる警報が利用しやすく, 公衆や住民に分かりやすい形で配信できることが重要であるまた, システムの異なる各メディアに効率良く迅速に伝送できるものでなければならないそこで計画されているのが, マークアップ言語の XML(Extensible Markup Language) を利用した警報伝送様式であるアメリカでは, 政府機関や州政府, 自治体が発信する警報を,XMLをベースにした CAP (Common Alerting Protocol) という様式に統一し, 放送やインターネット, 携帯などの商用移動体通信, 自治体のサイレンシステムなどに伝送するナショナルプロジェクトが進行中である一方, 日本でも気象庁がこれまで警報ごとに異なっていた様式を XML によるものに統一し,2010 年から順次実施する見通しである本稿では, 多メディア化や警報の高度化と様式統一との関係を明らかにすると共に, 検討されている様式の構造をCAPと気象庁 XMLで比較し, 警報伝達に対するアプローチの相違を論じる 36 APRIL 2010

2 2. XML と警報配信 XML とは何か, 先ずは簡単に説明しておきたい 2(1) マークアップ言語の XML XML はマークアップ言語の 1つであるマークアップ言語はデジタル情報を文書として共有したり交換したりするためのものであるコンピューターネットワーク上でデジタル情報が共有交換されるためには, 文書の構造が統一されていなければならないこの文書の構造を取り決めるのがマークアップ言語であるウェブのホームページ作成で馴染み深いHTML (HyperText Markup Language) もその 1つである 2(2)XMLの仕組み XMLでは, 情報の要素を開始タグ <> と終了タグ </> で括る情報要素の名前は開始タグと終了タグの中に < >,</ > のように書き込む開始タグと終了タグの間に内容 (content) を記述する内容は文字や数字であるまた情報要素に付属する性質は属性として開始タグの中に < 属性名 =" 属性値 "> と書く例えば図 1のXML 文書のうち,< 名前 > 警報 </ 名前 > は情報要素の一つであり, 名前は情報要素名, 警報は内容であるまた情報要素の < 警報発表機関 =" 庁 "> ~</ 警報 > のうち, 発表機関 =" 庁 " の部分は属性である図 1をよく見ると < 災害 Hazard> という要素の下に < 警報 > 要素が, 更にその下に < 名前 > < 情報 > < 地域群 > の各要素,< 地域群 > の下に < 地域 > 要素がとツリー構造 ( 階層構造 ) になっているこの文書のツリー構造を図 2 に示す頂点に位置する < 災害 Hazard> はルート要素と呼ばれ, 言わば大本のフォルダのようなものであるツリーを構成する情報要素や内容, 属性は node ( 葉がでる節の意味 ) と呼ばれる HTML と違って XML はタグに情報要素名を自由につけることができる情報体系をオーダーメイドで柔軟に決められるしかし, ユーザーによって情報要素名のつけ方などが異なっていては, 情報共有が困難になるそこで, 実際に使われる場合は, 文書構造の厳密な取り決めが XML Schema などのスキーマ言語によってなされる図 1 <?xml version="1.0" echoding="shift-jis"?> < 災害 Hazard> < 警報発表機関 = " 庁 "> < 名前 > 警報 </ 名前 > < 情報 > 災害によって大きな被害が予想され厳重な警戒が必要です </ 情報 > < 地域群 > < 地域 > < 名前 > 市 </ 名前 > < 情報 > 災害によって大きな被害が予想され厳重な警戒が必要です </ 情報 > </ 地域 > < 地域 > < 名前 > 市 </ 名前 > < 情報 > 災害によって大きな被害が予想され厳重な警戒が必要です </ 情報 > </ 地域 > </ 地域群 > </ 警報 > < 警報発表機関 = " 庁 "> < 名前 > 警報 </ 名前 > </ 警報 > </ 災害 Hazard> XML 文書の例 APRIL

3 図 2 XML のツリー構造になるただ,XML はデータを自在に分類できる自由の代償として, 開始タグ < > で始まる情報要素は必ず終了タグ </ > で閉じなければならないなどの掟があるタグを使って文書の構造を厳密に定義しなければならない分だけ素材のデータ量に比べて情報量が嵩んでしまう 3. 米国の公衆警報システムと放送 2(3) 何故 XMLなのか X M L が警報伝送の様式として採用された理由は,HTML に代わる言語として利用が増えていることにもよるが, 情報量が増えて複雑化する警報を, 分かりやすく自在に仕分けして提供できることによるツリー構造が厳密で整然としたものとなれば, 放送通信事業者や自治体など情報の受け手は, 警報のカテゴリーや緊急度, エリア別の検索が容易になるであろう XML による文書を別の形式の文書に変換するスタイルシート言語の XSL(Extensible Stylesheet L a n g u a g e ) やインターフェースの D O M( D o c u - ment Object Model) を使えば, 送られてきた警報の中から必要なデータを取り出して, 公衆や住民に分かりやすい形に加工できるようアメリカでは, 第二次大戦後の冷戦時代から今日に至るまで, 放送が公衆警報システムの主役を務めてきた放送やインターネット, 携帯など各メディアを統合した次世代型システムの要となる CAP(XML ベース ) を理解するためには, アメリカにおける公衆警報システムの成り立ちと発展を踏まえておく必要がある 3(1) 旧世代の公衆警報システムアメリカでは,1951 年にトルーマン大統領の指示によって, 放送を利用した最初の公衆警報システムが作られたこのシステムは, 核爆弾を搭載したソビエトの爆撃機の侵入を市民に知らせるためのもので,CONELRAD(Control of Electromagnetic Radiation) と呼ばれた 1) 空軍が警報信号を専用の電話回線で特定のラジオ局に伝えると, 特定局は事前に決められた警報文を放送する警報文は電話などで他のラジオ局に次々とリレーされるというシンプルな 38 APRIL 2010

4 システムであったまた, 特定の周波数による電波のON-OFFによって, 敵機の電波探知航法をかく乱することになっていたその後,ICBM( 大陸間弾道ミサイル : InterContinental Ballistic Missile) が開発されて爆撃機による核攻撃の可能性が少なくなったことなどから,1963 年に第二世代の警報システムの EBS(Emergency Broadcast System) にとって代わられた 2) EBSは, 戦争の脅威など国家の一大事に大統領が公衆に呼びかけるためのものだが, 後年には地方レベルの緊急事態や気象警報などに活用されるようになった CONELRADと違ってテレビ局のネットワークも参加していた大統領が国家レベルのEBS 起動を決めると, 連邦機関が専用回線でラジオテレビのネットワーク主要局に連絡する主要局は可聴域の2 つの周波数から成るアナログの注意信号を, それより周波数が高い電波にのせて各局に送信するこれを各局がキャッチすると, 受信した電波から元の信号を取り出す復調器がアンロックされる各局はリスナーの注意を惹きつけるため, 復調した注意信号のトーン ( 音 ) を手動で放送し, 直ちに番組を中断するこのあと, 連邦機関から主要局経由で伝えられる大統領のメッセージを伝える仕組みになっていた EBSは1997 年に第 3 世代のEAS(Emergency Alert System) に更新された 3(2) 第 3 世代の EAS 本稿執筆時点の2009 年 12 月現在,EAS は現役世代の公衆警報システムである 3) 警報配信メディアはラジオ ( A M F M デジタル衛星デジタル ), テレビ ( 地上波衛星 ),C A T V( 有線系無線系 ), ケーブルプロバイダーなどである EAS が起動すると, 上記のメディアは番組を中断し警報を視聴者に伝える起動のケースは 1 国家の非常時の際に大統領ないしは大統領に指名された者が全国民に向けて警報を発信する場合,2 州や地方 ( 通常は郡単位 ) の機関が住民に向けて気象災害や人災, 子供の誘拐や失踪に関する警報を発信する場合, であるこのうち 1は旧世代のシステムによる時代を含め,2009 年 12 月末日に至るまで起動の実績はない 2は正確な統計はないが, 多数の起動実績がある EAS によって伝送される警報メッセージは, (a) デジタル化で符号化されたヘッダー,(b) トーン ( 音 ) による注意信号,(c) 音声による警報アナウンスメント,(d) デジタルで符号化されたエンドマーク, から成るこれらは, いずれも各メディアによって変調されて送信されるこのうち重要なのは ( a ) で, ヘッダーには警報の発信者や警報の対象となるハザード ( 戦争の脅威や自然災害, 大事故といった危険をもたらすもの ) の説明, 被害が予想される地域,EASの起動日時などの情報が 1と0 の組み合わせで記述されているデジタルの符号化によって番組の中断や警報メッセージの送信が自動化されたまたテレビ局や CATVが警報の内容を字幕でスムーズに伝えられるようになった EASによる警報メッセージの基本的な流れを図 3で説明する 4) ❶ 大統領が全国民に向けて警報を発することを決めると,FEMA( 連邦緊急事態管理庁 : Federal Emergency Agency) が EASを起動し,PEP(Primary Entry Point) に通知する ❷このPEPというのは, 特別に指定された商業ラジオ局 (AM,FM) などで 37 局ある 5) APRIL

5 他の局と同様に番組を中断してリスナーに警報を伝えるが,PEP としての役割は, 階層構造の下位局に前述 (a) のヘッダーから (d) のエンドマークまでを特定の周波数で順次送信することである ❸ SR(State Relay) は, 商業ラジオ局あるいは州政府が運営する VHF や UHF 局, マイクロ回線の親局である州内の下位局に警報メッセージをリレーする州政府レベルで警報メッセージが出される時の起点と成る場合は SP (State Primary) と呼ばれる図 3 EAS の概略 ❹ LR(Local Relay) も商業ラジオ局などで, 1 つもしくは複数の郡から成る地方エリアの下位局をカバーする地方機関レベルの警報の起点となる場合は LP(Local Primary) となる注州レベル地方レベルを分かりやすくするため系統図をシンプルにしてあるが, 実際には SR- 各局間,PEP-LR 間等のリンクもあり複雑である 3(3)EAS の脆弱性 ❺ その他の局は,LR(LP) の送信した周波数をキャッチして, 自動的に番組を中止し, 視聴者に警報メッセージを伝える ❻ NWR(NOAA Weather R a d i o ) というのは,N O A A ( 米国海洋大気圏局 :Nat ion a l Oceanic and Atmospheric Administration) の NWS( 気象業務部 :NOAA Weather Service) が運営しているラジオである各地方にある NWS は地方レベルの気象警報を N W R で出している各放送局や CATV は NWR による気象警報の周波数をキャッチする機器を備え, これによって気象警報を放送している警報メッセージのデジタル符号は EAS と NWR で互換性がある E A S については G AO( アメリカ会計検査院 :Government Accountability Office) がその脆弱性を指摘している 6) GAO の報告によると, 国家的非常時の場合に FEMA は地上回線によって前述の PEP37 局に警報を通知するが, このリンクに失敗すると, 警報メッセージのリレーは成立しなくなるとしているまた PEP によってカバーし切れない遠隔地の放送局は, 衛星回線ネットワークの公共ラジオ局経由で警報を入手しているが, 公共ラジオ局は PEP のように非常用の燃料や発電機などを必ずしも完備している訳ではないので, 信頼性が十分とは言えないと指摘している 40 APRIL 2010

6 また EAS に携帯などの通信メディアが加わっていないことや放送の特性から被害が予想される地域を選別して警報を配信できないことを問題点として挙げている FEMA 自身も新しい公衆警報システム構築に関する文書の中で, 次のように記述している 7) 最近の調査によると,TVやラジオでは平日は住民の 4 0 % にしか届かず, 夜中は 12 % しかテレビを見ていないラジオでは 5% になるテレビラジオは公的な情報の重要な source であり続けるだろうが, その影響力は減ってきている放送によるエリアの絞込みは州や一定の地域単位に限られている 4. 米国の次世代型システムと CAP 4(1)IPAWS 8) 同時多発テロや年のハリケーンカトリーナなどを契機として, 放送に依存した公衆警報システムを見直す機運が高まった FEMAは2004 年から次世代型の警報ネットワークインフラである I PAW S( 統合公衆警報システム :Integrated Public Alert and Warning System) の構築に着手した年には, ブッシュ大統領が新たな警報システムを求める特別命令 (Executive Order) を出した IPAWS の目標は以下の通りであるイ多様なメディアを結集して警報配信ルートを多様化するロ大統領が全国民に向けて警報を発信するのを確実にするハメディア間の相互運用性を確保するニ EAS など既存のシステムを強化高度化するホ障害を持つ人達や英語を理解しない国民にも警報が届くようにする図 4にIPAWS の概念図を示す図 4の警報配信システムのうち,EASは IPAWS によって前述の PEPを現在の 37 局から 74 局にまで増やし, 人口の 9 0% までカバーできるようにする計画であるまた伝送ルートを多様化するため民間ラジオ局の衛星回線ネットワークと接続することになっているデジタル EASというのは, 可聴域の周波数によって音声ベースの警報メッセージを伝える EAS のデジタル化を促進しようというものである公共テレビ (PBS : Public Broadcasting S er v ice) の地上デジタル網を使って, 音声だけでなく静止画やビデオ, テキストデータなどで警報メッセージを配信する FEMA と公共テレビ局の団体である APTS(Association of Public Television Stations) は既に協力協定を結び, 州や地域レベルのパイロット事業が進行中である将来はこのデジタル EAS で配信される警報メッセージを商業放送網や携帯ネットワークなどにも転送することを視野に入れている CMAS(Commercial Mobile Alert System) は携帯や無線呼出し (beeper) などの商用移動体通信を結集した新たな警報システムである FEMAや FCC, 関係する通信事業者による委員会がシステムに必要な技術要件や手順を盛り込んだ勧告をまとめ, これに基づいて FCCは運用のための規則 (REPORT AND ORDER) を策定している図 4 には明示していないが,IPAWS では, 自然災害や人為的な事故によって被害の及ぶエリアを迅速的確に特定し, 関係機関に連絡するソフトも開発することになっている GTAS (Geo-Targeted Alerting System) と呼ばれるこのソフトでは, 化学プラントや原子力施設な APRIL

7 図 4 IPAWS の概念図注 Integrated Pubic Alert and Warning System(IPAWS)Overview and Commercial Mobile Alert System(CMAS)introduction(2009 年 8 月より作成 ) どの事故で, 有毒物質や放射性微粒子が環境中に漏れ出した場合に, それらの移動範囲を予測し, 影響のあるエリアに限って警報を出すこれはシステムというより警報の情報内容が高度化する例である図 4に戻る連邦機関や州政府, 地方機関は警報メッセージを一旦 I PAWS の Agg regator に送る Aggregator では送られてきた警報が法令に基づく然るべき機関から適正な手続きによって発信されたものであることを認証する警報メッセージが複数である場合には, 優先順位 (Priority) をつけて各メディアの配信システムに転送する何故 Aggregator を一旦経由するのか Aggregator がなければ, 警報の発信機関はそれぞれが配信メディアへの伝送路を確保しなければならなくなる更に, 警報発信機関やAggregatorにとって, 同じ内容の警報を各配信メディアのシステムごとに, いちいち別々の様式で送っていたのでは, 効率よく迅速な伝送はできない一度に各システム同時に送れるようにしたいそこで警報を伝送する際の様式が統一されることになるこれが CAP である 4(2)CAP のバックグラウンドアメリカ大統領府にあって, 国家安全保障会議などと並ぶ重要な機関であるNSTC( 国家科学技術会議 :National Science and Technology Council) は2000 年 11 月, effective Disaster Wa r n i n g s に関する報告書を公表した 9) この報告書の中でNSTCは, あらゆる種類の警報を即座に, 自動的に収集して広範な種類の警報配信システムにリレーできる標準的な様式が開発されるべきであると勧告した NSTCの勧告を受けて, 翌年から防災機関の関係者や情報通信技術の専門家から成るグループが CAP のデータ構造の原型を作る作業 42 APRIL 2010

8 を開始したその後, 実地試験や長期のデモンストレーションが重ねられた 2004 年 4 月には,XML などの標準仕様を策定する国際組織のOASIS(Organization for the Advancement of Structured Information S t a nd a rd) が,CAP Ver s ion1.0 を国際標準仕様として採択した更に 2007 年には,ITU ( 国際電気通信連合 : International Telecommunication Union) が CAPをITU 勧告として採択した 2008 年に FEMA は IPAWS の運用に CAP を使うことを公表した CAP は国際標準であるので, アメリカだけでなくカナダやスリランカでも公衆警報システムに使われている年 12 月現在,CA P の最新版はVer- sion1.2 である Version1.0 ~ 1.2は標準仕様 (Standard) であり, 実際に使う場合には, 各国の警報配信システムにうまく適合するように Standard のサブ仕様が作られている IPAWS の場合でも,EAS や CMASといった各システムに CAPを実装するためのサブ仕様が作られているが, 本稿では, 根幹である Standardを先ずは俎上に乗せて, 構造と特徴を明らかにしたい 4(3)CAP(Standard) の構造 CAPはXMLで記述されている従って 2 (2) で述べたようにツリー構造 ( 階層構造 ) を持つ図 5にCAPのツリー構造を示す図 5 を見るとCAP は <alert>,<info>,<area>, <resource> の 4 つの情報要素のブロックから構成されていることが分かるそれぞれのブロックは情報要素のファイルを格納するフォルダのようなものと考えれば良いだろうこのうち頂点に位置する <alert> は, ツリーを構成するすべての情報要素 node を格納するルート要素である大本のフォルダであるので, 1つのCAPメッセージにつき <alert> は常に1 つである <alert> に含まれる情報要素のうち, <identifier> はメッセージの IDを,<sender> は警報を発信した機関名を内容とするまた <alert> には,<info> ブロックが 1 つないしは複数含まれる <info> ブロックはCAPメッセージの本文であるこのうち <category> は気象災害や火災, 健康被害, テロ, インフラ被害といったようにハザードをコード名で類別したものであるまた <event> は災害の具体的な名前を示す <effective> は警報が有効と思われる時間帯,<description> は人間が判読可能な災害についての記述, <response Type> は避難など推奨される対応策のコードを示す <info> ブロックでユニークなのは <urgency>, <severity>,<certainty> の3つの情報要素を備えていることであるこのうち <urgency> はハザードの緊急性を示すもので, 対応の緊急度順にImmediate,Expected,Future などのコードを持つ <severity> はハザードの強度を示しExtreme,Severe,Moderateなどで,<certainty> はハザードが起きる確実性で Observed,Likely,Possible などのコードによって表される警報の重要度や優先順位 ( プライオリティ ) は, 伝統的にはハザードの強度といった単一の指標から決められることが多いが,CAP の Standardでは <urgency>,<severity>, <certainty> の3つの情報要素を使って言わば 3 次元でプライオリティが決められるこれは, それぞれの頭文字をとって U/S/C モデルとも呼ばれる図 6にモデルの概念を示す APRIL

9 図 5 CAP のツリー構造注 1 OASIS Common Alerting Protocol Version 1.1 及び 1,2 より作成 2 / の各記号は図 2 参照 3 は中略の意図 5 のツリー構造に戻る <info> ブロックには警報の対象地域を示す <area> ブロックが 1つないしは複数含まれるこのうち <areadesc> は地域名をテキスト形式で記述する <circle> は中心点と半径を持つ被災予想圏を描くための数値コード,<geocode> は地域を特定するためのコード番号である <area> ブロックは被災するおそれがある地域を絞り込み, 細分化するためのコードを持つ各種の情報要素が用意されている <resource> ブロックは, 警報に付随する地図や静止画, 音声ファイル, より詳細なデータなどがネットワークのどのサーバーにあるか参照させるためにある <resourcedesc> はファ図 6 U/S/C モデルの概念注 Workshop on ICT Standards for Public Warning-Geneva,2006 Effective Public Warnings and the Common Alerting Protocol(CAP) による 44 APRIL 2010

10 イルの内容と種類をテキスト形式で記述し, <size> はファイルの大きさを表す <uri> は uniform Resource identifier の略で, インターネットの URL(Uniform Resource Locator) が書き込まれる図 7 に CAP Standard による警報メッセージの例を示す図 7 CAP の例文 <?xml version = "1.0" encoding = "UTF-8"?> <alert xmlns = "urn:oasis:names:tc:emergency:cap:1.2"> <identifier>ksto </identifier> <sender>ksto@nws.noaa.gov</sender> <sent> t14: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> t16: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, ==( 中略 )== </polygon> <geocode> <valuename>same</valuename> <value>006109</value> </geocode> <geocode> <valuename>same</valuename> <value>006009</value> </geocode> </area> </info> </alert> 5. 気象庁 XML とその構造 5(1) 警報の様式統一と XML 気象庁が出す防災情報は, 現状では, その特性に応じて, それぞれ独自のデータ様式 ( フォーマット ) を持つ注 1 OASIS Common Alerting Protocol Version1,2 Public Review Draft02 AppendixA より抜粋作成 2 <resource> ブロックはオプションのため不使用データ様式は, コードやかな漢字, 半角カナ,1 と 0 から成るバイナリー, などの単独あるいはそれぞれの組み合わせから成るまた気象警報注意報や府県週間天気予報などは, かな漢字半角カナによるコードに加えて, XML でも送信されているが, それらの XML は, 種類が異なる防災情報の間で必ずしも様式の統一が図られている訳ではない一般的には, 様式が異なるデータの間に互換性はない従って, それぞれの様式ごとにデータを判読するソフトが必要となるしかし, 防災情報の種類が多くなってくると, 気象庁から情報を受け取って住民や視聴者に配信する自治体や放送事業者などにとっては, 多岐にわたる防災情報を 1 つの汎用ソフトで処理できるようになった方が便利であるそこで, 気象庁では, 各種防災情報のデータ様式を XML による新たなフォーマッ APRIL

11 トに統一することを決めたその対象となる防災情報は, 気象警報注意報, 台風情報, 津波警報注意報, 緊急地震速報, 地震速報, 噴火警報予報, 天気予報, 週間天気予報などで, 気象庁が出す警報がすべて網羅されている気象警報注意報などに使われている現行の XML も, 情報要素の名前などを統一した新 XML フォーマットに改められる XML を使う理由は,2(3) で述べた通り, 高度化し複雑なデータ構造を持つ防災情報であっても住民や視聴者に分かりやすい形に加工したり, 抽出したりすることが容易なためである気象庁は 2008 年 2 月から,XML の普及推進団体である XML コンソーシアムと協力して, フォーマットの策定に着手した気象庁と XML コンソーシアムでは, これまでに 2 度, フォーマットのドラフトを公開して一般から意見を募集し,2009 年 5 月に完成版である気象庁防災情報 XML フォーマット Ver1.0 を公表したこの後, 様々な OS のサーバーを使ってテストを行い,Ver1. 0 に基づくサンプル警報図 8-A 文が確実に送受信されるかどうか検証した気象庁では,2010 年の 5 月下旬から市町村区分ごとに出されることになっている大雨警報などから新たな XML フォーマットによる送信を開始し,2011 年 3 月からは, 対象となる防災情報をすべて X M L の統一様式で伝送できるようにする方針である 5(2) 気象庁 XML の構造図 8-A に気象庁 XML フォーマットのツリー気象庁 XML のツリー構造注 1 気象庁防災情報 XML フォーマット Ver1.0 より作成 2 / の各記号は図 2 参照 3 は中略の意 46 APRIL 2010

12 構造を示す図 8-Aを見ると, 気象庁 XMLは <Report>,<Control>,<Head>,<Body> の 4つの情報要素のブロックから構成されているのが分かる頂点に位置する <Report> は, すべての情報要素 nodeを格納するルート要素, 言わば大本のフォルダであるその下に <Control>,<Head>, <Body> の3ブロックが順番に同格の子要素として配置されているこの 3 つは,<Report> 中にそれぞれ 1 つしか書くことができない <Control> 部は, 情報処理と送受信を行うサーバーに基本的な制御情報を提供するもので,5 つの情報要素から成るこのうち <Title> には, 気象警報注意報, 津波警報注意報予報, 緊急地震速報, 噴火警報予報といった具合に情報の種類が記述される <DateTime> は情報を作成発信した時刻, <Status> は送信される情報の運用種別を示し, 通常, 訓練, 試験などを内容とする <Head> 部は, 情報の概要を簡潔に示すためにある自治体や放送事図 8-B 気象庁 XML のツリー構造 (Body 部 : 市町村への大雨警報の例 ) 業者は <Head> 部を処理することによって, どのような警報が, どの地域を対象に出され, いつからいつまで警戒が必要か, 情報の核心を把握することができる <Head> 部は10 の子要素を持ち, このうち <Title> は表題で, 例えば県気象警報注意報, 津波警報, 緊急地震速報( 警報 ) などのように記述される <TargetDateTime> は災害がいつから予想されるか基点となる時刻, <InfoType> は, 発表, 注 1 気象庁防災情報 XML フォーマット Ver1.0 気象警報注意報サンプル電文より抜粋作成 2 情報内容内は具体例更新, 訂正, 取消など情報の形態を表す <Headline> は見出しに相当し, 下部構造として <Text> と <Information> の子要素を持っている <Text> は放送の字幕スーパーに使われるような見出 APRIL

13 し文である <Information> は, 孫要素の <Areas> 以下で対象となる地域を, 同じく孫要素の <Kind> 以下で当該地域に出されている警報などの名前予想される災害 ( 例 : 浸水土砂災害 ) などを仕分けし, 記述する図 8-A では分かりやすく説明するために,<Kind> は 1 つしか書かれていないが, 複数書くことができるこれは気象警報注意報の場合に,1 つの地域に大雨警報や洪水警報, 強風注意報など複数の警報注意報が出される実情に即応するものである防災情報の緊急性が高く, シビアな迅速性が求められる場合には, ルート要素 <Report> を <Control> 部と <Head> 部だけで構成し, 図 8-A 右端の <Body> 部を省略することができるまた <Control> 部と <Head> 部の構造はすべての XML 文書で共通である <Body> 部は, 防災情報を更に詳しく伝えるためにある雨量, 津波の高さ, 河川の水位と言った量的予想や特記事項などを提供する量的予想の内容や特記事項の伝え方は, 防災情報の種類によって異なるゆえに <Body> 部の構造もそれぞれ情報の種類に応じて最適のスタイルを持ち, 共通ではない図 8-B は大雨警報が市町村に出された場合の <Body> 部である図 8 -B の例文では, 市に大雨警報が出され, 浸水に対する警戒を呼びかける内容である <Kind> 中の <Name> で大雨警報が出されたことが示され,<Attention> の <Note> で図 9 気象庁 XML の例文 <?xml version="1.0" encoding="utf-8"?> <Report xmlns=" xmlns:jmx=" xmlns:jmx _ add=" <Control> <Title> 気象警報注意報 </Title> <DateTime> T08:09:43Z</DateTime> <Status> 通常 </Status> <EditorialOffice> 管区気象台 </EditorialOffice> <PublishingOffice> 管区気象台 </PublishingOffice> </Control> <Head xmlns=" <Title> 県気象警報注意報 </Title> <ReportDateTime> T17:09:00+09:00</ReportDateTime> <TargetDateTime> T17: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=" xmlns:jmx _ eb=" =============( 以下略 )======================= 注気象庁防災情報 XML フォーマット Ver1.0 気象警報注意報サンプル電文より抜粋, 作成 48 APRIL 2010

14 予想される災害が浸水害であり警戒が必要なことが表現されているまた <Area> 中の <Name> によって市という地域名が記述されている実は, ここまでは <Head> 部の <Information> と重複する既報部分である新たな情報が付加されているのは <Property> 以下である <Property> は量的予想などの詳細な事柄を表す情報要素である子要素の <Type> はどのような災害の量的予想であるかを示し, この例では浸水である <WarningPeriod> は警戒を要する期間を示し,<EndTime> と <Term> で24 日の夜遅くまで浸水に対する警戒が必要であることを表しているまた, <AdvisoryPeriod> は警戒よりも緊迫度は低いが注意を要する期間を示し,<EndTime> と <Term> で翌 25 日の朝まで注意が必要であることを表している <PrecipitationPart> というのは, 降水量についての諸要素を示し, その下の <Base> は最大値など,<jmx_eb:Precipitation> は降水量のデータを表すつまり, この例文では1 時間当りの最大雨量が 8 0 ミリに達すると警告している前述の <Head> 部と同様に,<Property> を含む <K i nd> は複数書くことができる図 9に気象庁 XML の例文を示す 5(3) 放送事業者などの利用について放送事業者が XMLによる防災情報を放送する場合には,XMLを解読するソフトが必要となる解読されたデータを更に文字や図に変換する従ってソフトの改修が必要となるまたデータ放送で使う場合には, データ放送用のマークアップ言語であるBML(Broadcast Markup Language) に変換しなければならないインターネットのホームページに掲載する場合には, スタイルシート言語の XSL を使えば HTML の形式に変換できる BML や HTML はいずれも XML ないしは同系統のマークアップ言語であり, 変換は比較的容易であるこの点もデジタルの多メディア時代にあって強みと言えるであろう 2(3) で述べた通り,XML はかな漢字や半角カナによる従来型のデータ様式よりも情報量が嵩む従来型のデータ量は数 kbyte ~ 数 10kByte であるが,XML では数 10kByte ~ 数 100kByte に増えるその分, 情報の処理や伝送には時間がかかる受信するデータ量が多い放送事業者や都道府県は, 情報処理や伝送の速度を考慮に入れておく必要があるだろう気象庁では, 対象となる防災情報をすべて XML 化する 2011 年 3 月以降も, 自治体や放送事業者などの準備が整うまでの移行措置として, かな漢字などによる形式をしばらくは併用することにしている 6. おわりに CAP と気象庁 XML の比較最初に断っておくが, ここでの狙いは, 優劣や実効性を比較するものではないそもそも警報は国によって異なるし, 標準仕様の CAP と即実践型の気象庁 X M L を単純に比べることはできないここでは,CAP Standard と気象庁 XML の設計思想やバックグラウンドの違いが構造上の相違点として, どのように反映されているのかを見る警報伝達に対するアプローチの相違を明らかにすることによって, 逆 APRIL

15 に, 如何なる警報システムの場合に, 如何なるアプローチが必要かあぶり出すことができると考えるからである C A P は, あらゆる種類の警報を即座に, 自動的に収集して広範な種類の警報配信システムにリレーできる標準的な様式という NSTCの勧告を実現するために策定された当然, この勧告を反映し, 気象庁 XMLにはない構造上の特徴を持つそれらを以下に示すイ <info> ブロックに <category> が設定され, 自然災害だけでなく事故やテロを含むすべてのハザードに対応するよう設計されているロ <info> ブロックに <urgency>, <severity>,<certainty> が設定され, 警報のプライオリティを明確化しているこれは, 政府機関や州政府, 地方機関などが発信する多様な警報が,Aggregator や各メディアによって整然と順序立てて配信されるようにしたものと考えられるまた政府や自治体が避難などハザードへの対応を指示できるように <responsetype> や <instruction> といった情報要素を持つハ地図や静止画, 音声ファイルなどを様々なデジタルメディアが参照できるよう <resource> ブロックが用意されている一方,CAPと比較した場合の気象庁 XML の構造上の特徴を以下に示すイ現行の防災情報の体系を, そっくり使えるように作られ,IPAWS などのようにCAP Standard に基づいたサブ仕様を作る必要はないその意味で最初から精緻な実用型であるロ <Head> 部から <Body> 部にかけて情報内容が一部重複しながら, 詳細になってゆく構造を持つ気象庁 XMLの全体構造は情報量が垂直に深く拡がってゆくニュース記事のような三角形であるこの構造は, 細分化し複雑化した情報を見出しから要領よく伝えるのに適しているこのため緊急時でシビアな迅速性が求められる場合には,<Body> 部の省略が可能である CAP の場合も三角形ではあるが, <info > ブロックに同格の子要素が多数並び, 比較的なだらかな三角形をしているハ <Body> 部は防災情報の種類によってそれぞれ最適の構造を持つ CAP の場合には, タグの名前や情報要素ブロックの使い方は共通で, 基本的にはoptional なタグやブロックを加えたり外したりして最適な構造を組み立てるこれに対して気象庁 XMLでは,<Body> 部で, 特定の防災情報に対応した固有のタグが作られ, 量的予想によるキメ細かな情報伝達を可能にしている CAP にしても気象庁 XML にしても, 多メディア化や警報の高度化に対応したものであるが, それぞれの構造の比較から,CAP は多様な警報を様々なメディアに幅広く手際よく送信する特徴を, 気象庁 XMLは細分化し高度化した警報を明瞭迅速に伝える特徴を持っていることが分かる各国の公衆警報システムの形態がその国の歴史や直面するハザード, メディア事情, 技術レベルなどと, どの程度の相関関係を持つかは, 今後の定性的定量的研究に委ねなければならないであろうただ, アメリカの公衆警報システムの歴史的経緯を見ると, 戦争やテロなどの国家的危機に対する強い警戒感が, CAP がアメリカで作られ,IPAWS に採用された背景の 1 つとして考えられようまた気象庁 XMLが細分化し高度化した警報をクリアに迅速に伝えようとするのも, 秒単 50 APRIL 2010

16 位の速報性が求められる津波や大地震などを日本人が過去に幾度も経験してきたことが背景にある最近は日本でも, 愛知県や三重県などで, 県や市町村が出す避難情報や被害状況, 災害対策本部の設置状況のほか, 交通やライフラインなどの情報を一括して収集し,XMLを使った共通様式で放送局や新聞社,CATV, 携帯事業者などに伝送しようという実証実験が既に始められている 10) 将来的には, 気象庁 XML も含め, 多数の防災機関からの情報を収集する日本版 Aggregator が出現する可能性もあるその時には,CAP に見られるようなアプローチが考慮されるかも知れない ( ふくながひでひこ ) 注 : 1) 米国の NPO である Partnership for Public Warning の報告書 The Emergency Alert System(EAS):An assessment などによる 2) 前掲 1 の他に State of California Emergency Alert System(EAS) など 3) 前掲 1 及び FCC Consumer Facts/The Emergency Alert System(EAS),FCC's EAS Web page などによる 4) 前掲 1.3 及び CA L I F OR N I A Homepage の EMERGENCY ALERT SYSTEM FREQUENTLY ASKED QUESTIONS などによる 5)FEMA Integrated Public Alert and Warning System(IPAWS) IPAWS Project による EAS は公共ラジオ局の衛星ネットワークともリンクしているが, これは PEP の第 3 層として 37 局には含まれない 6)GAO T 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)IPAWS については FEMA Integrated Public Alert and Warning System(IPAWS) systemenhancements.shtmn などを参考にした 9)NSTC Report on Effective Disaster Warnings (November, 2000) 10) 総務省所管の安心安全公共コモンズ実証実験 XML を使った共通様式とは TVCML(TV Common Markup Language) APRIL

PowerPoint Presentation

PowerPoint Presentation 気象庁 XML とは ~ 気象庁 XML 利活用セミナー ~ 2013/3/12 気象庁予報部業務課杉山善昭目標資料はどこにある XMLの構造を読めるようになろうここをみれば基本的に使えるタイトル時間見出しの表示発展編に行く前に資料はここにある 2 3 気象庁 XML の基本構造導入編とにかく仕様書を見れば分かります ( たぶん ) http://xml.kishou.go.jp/specifications.html