あと1か月で3月11日。世の中の災害意識が高まる日が近づいています。
災害が起きてからのサバイバル生活を乗り切る術を身に付けることは大事ですが、平時からの備えは、より重要であると考えられます。
備えの重要性が実感されるものの1つに『情報』があります。テレビが視聴できずラジオが役立ったということもよくありますが、もっとローカルなところで言うと家族や同僚との連絡をどのようにして確立するのか、といったことも重要になります。
令和のいまでも、やはり『貼り紙』が伝言ツールになるのでしょうか。
非常時情報管理
非常時に重要となる情報は内部から集まる情報でしょうか、外部から入る情報でしょうか。
その目的によって重要性は変動しますが、いずれにも重要な情報があると考えられます。
『情報は二次活用されてはじめて価値が出る』と言われますが、非常時は特に実感される場面が多くなります。
地震発生時、被害が小さいほど社会の様子が気になります。震度6以上が直撃した場合は目の前で何が起きてしまったのか、何をしなければいけないのかにフォーカスされます。
見聞きした情報に基づいて行動が生まれ、その行動を続けるべきかを判断するために新しい情報を取得します。
ここでは、非常時の情報源や活用法などについて示しています。
MENU
├ TV・ラジオ
├ 新聞
├ インターネット・SNS
├ 防災アプリ
├ 必要な情報であるかの判断
├ 百聞は一見に如かず
├ ウェブ発信
├ 内外を結ぶクロノロ
├ 電話(殺到・輻輳)
├ LINE
├ 安否確認・参集確認
├ 安否確認システム(メール系)
├ 安否確認システム(クラウド)
├ 長所と短所(クラウドv.s.メール系)
├ なぜ、メール系システム?
├ 各システムの調達先
├ 価格設定(廉価性の実現)
├ 10万円未満
├ システム概要・特徴
├ FAQ
├ リンク
TV・ラジオ
情報収集の手段としては、テレビ放送が手っ取り早いですが、だんだんと欲しい情報との乖離が生まれます。確認が取れない情報は報道できないので仕方ありませんが、頼り過ぎには注意が必要です。
この動画は実際の地震発生時の報道の様子です。研修資料なので拡散されていない動画ですが、参考として掲載しておきます。
新聞
リアルタイムではありませんが、テレビ放送には乗らないような細かな情報も掲載されています。
災害対策本部などで活用するためには、情報の取捨選択が必要になります。
例えば断水について、水道設備の被害の大きさは新聞からでも読み取れますが、断水エリアや給水車の状況などは情報の新鮮さに欠くため新聞が適しているとは言い難いです。
信憑性の高い情報が多い新聞ですが、非常時の時間軸で考えると新鮮さに欠けることを念頭に置く必要があります。
インターネット・SNS
悪意の存在は抜きで考えても、正しい情報が掲載されているとは思わないで参照するのが良いと言えます。
電力会社や水道局の公式サイトであっても、情報が錯綜している中でどれだけの精緻な情報が掲載されているかわかりません。最終更新日時を掲載している場合は信ぴょう性が高いのですが、日時不明の場合はいつの情報であるかもわからず、利用するには覚悟が必要になります。
自治体のホームページは『災害モード』に切り替わり、アクセスしやすいようになることが多くなりました。
しかしながら、未対応の自治体もありアクセス殺到でダウンしてしまうケースも散見されます。
SNSは役立つことも多いですが、判断が難しいです。
火災など10分以内の新鮮な情報がSNSで流れている場合もありますが、その情報や画像が本物であるかがわかりません。
防災アプリ
Yahoo!やNHKなど様々なところから防災アプリが出されています。緊急地震速報などを伝えてくれるだけではなく、避難所情報なども提供してくれます。
細かな被害を伝えるものではなく、どちらかと言えば減災のための情報が提供されています。
必要な情報であるかの判断
外部から入って来る情報は、そもそも今必要であるのか検討することが重要です。
非常時には行動が伴わない検討は後回しで良いのです。
蛇口から水が出ていないのに、断水であるかどうかを調べる必要はないですし、復旧時期は曖昧にしか公表されないので、ネットなどを見ても断水を改善する情報は手に入りません。
災害であれば、その被害が甚大なものか、ある狭いエリアに限られるものかを知る事ができれば良いと思います。
それよりも、自分たちで手に入れられる信頼性の高い情報、行動と直結する情報に価値が在ります。
百聞は一見に如かず
道路沿いの小さな用水路の氾濫情報は河川管理事務所でも把握できていない可能性がありますが、自分の眼で見てみれば危険であるかどうかの判断はできると思います。
不用意に危険に近づく必要はありませんが、建物内から見渡せる範囲内の情報くらいは、自分たちで集めても良いと思います。
ウェブ発信
自分たちで手に入れた情報、自分たちの状況などは公式ウェブサイトなどを使って発信することで、救援を受けやすくなったり、人の殺到を緩和できたりします。
ウェブサイトにアクセスが集中するとダウンしてしまいますので、最大限に軽量化を図ります。
ロゴマークなども含め一切の画像使用をやめ、テキストデータのみにすることで簡単に1千倍や1万倍も軽くできます。
この『災害モード』のウェブサイトはAmpiTaを使うと簡単に制作できます。
内外を結ぶクロノロ
非常時は予実管理が重要になります。誰から連絡があったのか、次に何をしなければならないのか、といったことをまとめる掲示板のようなものです。
クロノロジー(chronology)という管理表をホワイトボードなどで共有し、状況の先読みをしながら対策を講じて行きます。
電話(殺到・輻輳)
外部と直接連絡を取る手段として電話やFAXがありますが、非常事態が発生すると使いづらくなります。
1つの電話番号に集中することでもつながりにくい状態になりますが、電話回線をつなぐ交換機や中継器などにも容量があり、既定数以上の回線はつながりません。
通信が多くなると輻輳(ふくそう)状態となり、通信事業者側でも制限をかけることがあります。
重要な回線を優先的に接続する代わりに、多くの回線は使えない状態にしてしまうというものです。
情報のやりとりに電話回線を使用することは、なるべく少なくした方が良いです。
LINE
職員が無事であるか、参集する事ができるかといった確認に電話を使うことは無理がありそうですが、LINEなどのツールであれば冗長性が期待できます。
安否確認・参集確認
自前で確実に情報収集する方法として安否確認システムの導入があります。
参集ルールを『震度6以上』『大雨警報』などの基準にしておき、基準に達する事象が発生したら職員や関係者から情報を募ります。
病院公式SNSを平時から運用し、発災時に特定の情報提供を呼び掛けるツールとして使う方法もあります。
例えば『淀川大橋は通行できるかご存知の方、写真付きでお知らせください』と投げかけると、ご近所の方がお知らせしてくれる可能背があります。
こうした情報に基づき、救急車はどこから来るだろうか、搬送が必要になったときの受け入れ先はどこが候補できるか、などを検討する材料になります。
安否確認システム(メール系)
多用途安否確認システム AmpiTa(アンピタ)
自動送信なし。メールサーバ活用型でサーバ費用は別途必要であるが、既有サーバでも対応可能。
救援や受援など医療機関独特の機能も備わり、平時の研修会の出欠やアンケートへの応用もできるように作られています。
アンチウイルスソフトのように有効期間付きソフトを購入のため月額費用は0円(導入時に期間分一括前払い)。
安否確認システム(クラウド)
Biz安否確認/一斉通報(NTTコミュニケーションズ)
自動配信対応、初期費用10万円~、月額1万円~
Yahoo!安否確認サービス(Yahoo! JAPAN)
自動配信対応、初期費用0円。月額4,400円~
ALSOK安否確認サービス(ALSOK)
自動配信対応、初期費用5万円(税別)、月額18,000円(税別)、家族機能は1口10円。
セコム安否確認サービス(セコム)
自動配信対応、費用は要問合せ
安否確認サービス ANPIS(東洋テック)
自動配信対応、費用は要問合せ
緊急連絡・安否確認システム(NEC)
自動配信対応、費用は要問合せ
エマージェンシーコール(インフォコム)
初期費用20万円、月額4万円。
安否確認サービス(アルカディア)
初期費用5万円、月額1万円。
SPIRAL安否確認サービス(PIPED BITS)
自動配信対応、費用は要問合せ
安否LifeMail(コム・アンド・コム)
自動配信対応、費用は要問合せ
安否確認サービス2(トヨクモ)
自動配信対応、初期費用0円、月額6,800円~(自動送信対応は8,800円~)
安否確認サービス(大塚商会)
トヨクモの代理店販売。
※.付記情報は弊社調査時のものであり現在のものとは異なります。
長所と短所(クラウドv.s.メール系)
集計処理がローカル/ネット
データ集計処理がネット上にあるサーバで行われるか、ダウンロード後に手元のパソコンで行われるかの違いがあります。
クラウド型は処理後のデータのビューアさえあれば良いので、端末はスマホ・タブレット・パソコンなど何でも大丈夫です。
ローカルで処理するメール系(AmpiTa)は、処理用にWindowsパソコンが不可欠となります。
そして、メールサーバにあるメールデータを直接編集することはできません。
生データの見読性
クラウド型の場合、サーバにあるデータの見読性は処理システムに依存します。見やすいかどうかの前に、人間が読める形になっているかもシステムに依存します。
メール系(AmpiTa)の場合、生データは汎用のメール本文です。そのまま人間が読める形式です。受信後に本文を解体して一覧表にするのがWindowsアプリ(AmpiTa)の仕事であって、メールサーバに預けられているデータ自体はWindowsアプリの及ぶところではありません。
サーバの冗長性
クラウドの場合、データ用とソフト用の2つの領域をサーバ上に持つことになります。そのサーバ管理は、サービス提供事業者の範疇となります。
非常事態が起きた時に、そのサーバが正常に動くかどうかはサービス提供事業者に委ねられることになります。
Yahoo!など大量のデータ処理の実績がある企業に強みがあります。
メール系(AmpiTa)の場合は、汎用のメールサーバを使用します。メールサーバ提供事業者は安否確認に使われているとは意識していませんが、東日本大震災でも使い続けられたように、メールサーバは安定性があります。
平時でも毎分何億通ものメールが飛び交っても停止しないほど安定し、利用者が多いため進化も多い技術分野です。
サーバアクセス負荷
クラウドでは、ユーザーが閲覧するためにサーバへアクセスする場合、処理後の仕上がったデータを閲覧することになります。すなわち、ある程度の件数をまとめて閲覧することになります。
安否等を登録する場合、サーバから提供される画面を開き、そこで登録されたデータはサーバへ送られて記録されます。このときサーバとはIDやPasswordのやり取りが生じる場合があります。
メール系(AmpiTa)は、ユーザーが閲覧する場合はWindowsアプリ(AmpiTa)がメールサーバへアクセスし、テキストデータのメールを受信して、ローカルのパソコン上で処理して表示します。
このメールのやり取りは、汎用のメール技術なので陳腐化した技術でありますが、送受信に係るデータ通信量は非常に軽量です。テキストデータのみ、一覧表などのように整列されていないので、メールサーバに蓄積された時間順のメールが、そのまま受信されるだけです。
安否等を登録する場合、ウェブブラウザに表示された画面に入力し、送信ボタンを押すとウェブサーバ上でメールに変換されて送信されます。このときメールサーバとはIDやPasswordのやり取りがサーバ上で実行されていますが、ユーザーが入力する必要はありません。
アクセス性
クラウドの場合、データ送信も受信も同じサーバを、違う方法で閲覧します。アクセス先は1つのデータベースです。
閲覧IDを持っている人が、異なる場所から同時に最新データを閲覧することができます。マルチデバイス対応であり、クラウドのため場所を問わず閲覧可能です。
メール系(AmpiTa)の場合、送信者はブラウザにアクセスしますが、メールサーバにはアクセスしません。ブラウザから送信されたメールは、メールのルールに従ってメールサーバへ届けられます。
閲覧者は、Windowsアプリ(AmpiTa)からメールサーバへアクセスし、メールをダウンロードした後に処理して見やすいリスト形式で表示します。
専用アプリ経由であるが世界中どこからでもアクセス可能です。
アクセス殺到
クラウドの場合、送信も閲覧も1つのサーバへアクセスするため交通整理の処理が上手くいかないとアクセス殺到で通信状態が悪くなる可能性があります。
メール系(AmpiTa)の場合、閲覧は1回だけメールサーバにアクセスしてダウンロード、その後はローカルパソコンで閲覧するのでアクセス殺到のリスクは軽減されています。
安否登録時は、一方的に送られて来たメールをサーバが受け入れることができればそこで完結します。メール送信時点でIDやPasswordのチェックは終わっているので、そのような処理は発生しません。
サーバ維持費
クラウドの場合、サービス提供事業者の管理下にサーバがあるため、管理費用は事業者依存となります。
安否確認システムの利用者数に応じてサーバの容量や接続数も増えるため、それに応じた管理費用がかかります。
ほとんどの事業者がID数に応じた従量制をとっています。月額で数千~数万円がサーバ代であると考えられます。
メール系(AmpiTa)の場合、一般的なレンタルサーバを使う場合の管理者はユーザーですので、管理費はレンサバ代金のみとも言えます。
安否確認対象者が100人でも1万人でも、利用するメールサーバは同じですし、管理者の人数でも特に変化はないので特別に費用はかからず、先述のレンサバ代金のみになります。
月額500円未満のサーバでも動作確認済です。
AmpiTaを例にとると、1回に送信されるデータ(メール1通)が約10KBです。1万通でも100MB程度です。
画像が添付されたメールを10通受け取る程度なのでさほど負荷が大きいとは言えません。1通あたりの容量が小さいので送受チェックが入ってもタイムアウトになることなくすぐに処理されます。
クラウド | メール系 | |
集計処理 | ネット上 端末不問 | ローカル 要Windowsパソコン |
生データ見読性 | 処理システムに依存 | 汎用メールの本文 |
サーバ冗長性 | サービス提供者に依存 Yahoo!などの強み | メール事業者に依存 平時に多用される技術 災害時も使用できた実績 |
サーバアクセス負荷 [受信] | 処理済一覧表を表示 | テキストデータのメールを受信 |
サーバアクセス負荷 [送信] | 専用画面を開いて登録 | ウェブブラウザから登録 |
アクセス性 | ID/Password処理 マルチデバイス対応 | Windwsパソコンと専用アプリ |
アクセス殺到 | 登録と閲覧の接続数上限ありの可能性 | サーバ接続は端的 |
サーバ維持費 | サービス提供者に依存 月額数千~数万円 | ユーザーの自己管理可 月額500円未満 |
なぜ、メール系システム?
メール系システムをなぜ開発したのかと問われれば、維持費の廉価性と、見読性や保存性の高さであると言えます。
選ぶ側がなぜメール系にするのかと言われれば、廉価性は評価項目に入るでしょう。
見読性や保存性に着目する人は少ないかもしれません。
特別な技術を身に付けなくても管理・運営できることが重要視されると思いますが、クラウドでもメール系(AmpiTa)でも特別な知識や技術は求められていません。
個人情報保護についてクラウドシステムの詳細はわかりませんが、メール系(AmpiTa)の場合は事前の個人情報登録は必要ありませんので、平時にシステムを盗まれても漏洩にはつながりません。
メール系(AmpiTa)の大きな特徴は、非常時対応のコンサルタントが自ら企画・設計・検証している点が挙げられます。
このAmpiTaというシステムが開発された背景には、10年程前のシステム開発が関係しています。そして、その目の前には守るべき対象となる患者が居り、医療の確実な提供のためには人数や時間を把握する必要があった『現実的な課題』に直面していました。
ストーリーが簡単にまとめられていますので、ぜひご覧ください。
各システムの調達先
クラウド系のシステムは、当社は販売店や代理店ではありませんので販売元へお問い合わせください。
メール系(AmpiTa)については当社にて取扱いがございます。お気軽にお問い合わせください。
価格設定(廉価性の実現)
廉価性が開発上の重要目標であったAmpiTaは、サーバ維持費を月額500円未満に抑える事に成功しています。税込年額6千円未満のレンタルサーバで動作します。
残るはAmpiTa本体の価格です。これが月額4千円に達するならばYahoo!様の安否確認サービスより高くなってしまいます。
したがって、AmpiTaは高くても3千円台(月額換算)で提供しなければなりません。
10万円未満
AmpiTaは売価10万円未満です。使用期間を定めているため、期限後は使用できませんので、長期的に保有する資産にはなり得ません。課税方法について当社は一切の責任を負えませんが、使用期限付きの10万円未満のソフトウェアであることは事実です。
システム概要・特徴
FAQ [AmpiTa]
多用途安否確認システム『AmpiTa』の機能についてご質問にお答えします。
費用・コスト
Q.AmpiTaの月額利用料は?
A.ありません。
AmpiTaはいわゆる買い切り品なので、最初に支払った費用以外の追加請求がありません。
Q.AmpiTa本体以外にかかる費用は?
A.ネット利用料
AmpiTaには1つのメールアドレス、1つのウェブページが必要です。
月額500円未満のレンタルサーバでもこの2つは付いてきます。
既にホームページやメールアドレスがあれば、恐らく新たにレンタルサーバを契約しなくてもAmpiTaを始められるので、その場合にはレンサバ代はかかりません。
通信料は別途かかりますが、これも一般的なネット通信なので新たにご契約いただく必要はありません。
発災後
Q.AmpiTaの入ったパソコンが無いと安否情報は見れない?
A.メールで見れます。
AmpiTaのデータはメール形式で、普通にメールサーバに保存されているので、Outlookなどもメーラーソフトでも良いですし、ウェブメールでも良いので閲覧することは可能です。
ただし、項目別に整列されている訳ではないので、AmpiTaで見るような一覧表にはなっていません。
Q.通信速度の遅さが心配です。
A.0.1Mbpsで試験しています。
職場や住宅に引き込まれているインターネット通信回線では100Mbps前後は当たり前の速度です。その1千分の1の速度でAmpiTaは実験し、3,000通のメッセージを受信・処理できることを確認しています。
AmpiTaの利用技術はメールです。1通ずつ処理、その1通は10KBほどの軽量、途中で通信状態が悪くなっても最後まで到達できる底力があります。
Q.メールサーバが機能するのか心配です。
A.東日本大震災でも機能していました。
2011年のあの災害で、電子メールは強靭性を発揮しました。メール自体は被災地とは違う所にあるサーバに保存されるため届きやすかったようです。