公衆警報の様式統一と放送～米国の 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 はマークアップ言語の１つである。マークアップ言語はデジタル情報を文書として共有したり交換したりするためのものである。コン要素，< 地域群 > の下に< 地域 > 要素が…とツこの文書のツリー構造を図 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 identiﬁer sender sent scope メッセージ ID 発信機関名日付対象・・・・・・ category event eﬀective 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>[email protected]</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>×× 地方では、２４日夜遅くにかけて所により雷を伴った猛烈な雨のおそれがあります。土砂災害や河川のはん濫、低地の浸水などに警戒して下さい。</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