項目別バックナンバー[1]:インターネット情報:55
災害警報
天気予報は気象庁のホームページや各種のメディアを通して定期的に伝えられる、だが最近は天気予報と同時にあるいは必要に応じてそれ以外の災害情報を臨時に情報を発信・提供している。
気象庁とその他の気象機関は、一般市民らに対して天気予報だけでなく天気や気象に関する情報や、広義の気候変動や自然災害の情報と災害警報を提供しそれに関係する説明と解説を行い啓蒙活動を行う事も、望まれている。
天気予報は毎日・毎週と定期的に情報が出されているが、「警報」はそれとは異なり、広義の気象による災害発生の危険性が高いという予測がされる時に警戒の情報の提供して発表・提供される。
「警報」は時代や国やその中の地域によって異なるしそれぞれで特色があり、種類や危険度の表現や区分は異なる。
気象情報や自然災害情報は、気象災害の増加や変化で要望が増える傾向にあり、そのニーズと観測設備と観測方法の向上や技術向上とから、対象項目は増加傾向にあり、その結果としての警報発信精度も対象でバラツキがあるが次第に改善が行われている。
ほとんどの国では、国民・一般市民に対する警報は、無制限に出すと情報が混乱して、それへの対応も混乱する危険性があり、それを防ぐために国家気象機関のみが発表できるよう制限している事が多い。
天気予報の歴史は古いが、内容的には人間の目視等から得た情報と経験から予報していた事がほとんどだった、この主観的な情報の取得を客観的な手段に変えて行き、個人的な経験をデータ・データベースとして客観的で継続的なものに変えて行った。天気予報では使用する技術が自然科学の知識と最新技術を使用した内容に大きく変わった。
天気予報は直接には気象学を通しての知識となるが、現在では天気予報は未来の大気の状態を予測する事であり、具体的には過去の気象として温度や湿度や風や気圧などの大気の状態を観測してデータを集めて、短期予報としてその時点からは未来に当たる現在を予報した、そして長期予報としての未来予測も行った。
現代の天気予報は、大気の状態の理論を元にそれを数値モデル化して計算機で演算を行っている、その方法を数値予報と呼ぶ。
同じ様な歴史と手法を行う分野があり、対象にする分野毎に地球学・海洋学・地震学・津波学・火山学等多数が有る。
気象庁のホームページは「地球環境・気候情報の総合ページ」とされており、気候情報以外に地球環境に関するサイトページがある、それから生まれて来る情報の例が災害警報となる。
地球環境情報と災害警報は気象情報・天気予報と同じ様に自然科学と最新技術を使用して理論とその数値モデル化手法を使う事も同じだが、予報・警報技術とそれからの実社会への発信というアウトプットの面ではまだ少ないと言われている。
気象庁のホームページの「資料とデータ欄」では膨大な情報量を扱っており、「気象」では気象観測データは最新情報は３０分から１時間毎に更新されており気象予報等の気象に関する作業の基本データとなっている、過去の観測データがグラフ等で集められ、予報に関する技術や予報誤差に関する検証や実験データが、次に農業・航空気象が集められている。
それに続き「地球環境・気候」があり「地球環境・気候情報の総合ページ」と
異常気象
最近の天候の特徴や見通し
地球環境・気候の観測・解析データ
地球環境・気候の長期変化傾向
気候リスク管理 がある。
以下は資料とデータ欄に「海洋」と「地震・津波・火山」が続く。
「気象と気象予報」に関する情報と、「海洋」と「地震・津波・火山」という地球環境に関する情報があり、その中間の部分に「地球環境・気候情報」の情報が並べられている形だ。
「地震・津波・火山」の項目に災害警報や災害情報に関する項目が含まれている、そこに災害警報や注意報の発表一覧があり検証項目がある。
気象庁の災害警報への対応と元になる情報が並び、それは具体的な内容となっている、情報収集や観測や、災害警報発表には、インターネットや情報技術は現在では深く関わっているが、それと同様に上記情報が気象庁がホームページに公開されている事は重要だ。
気象庁が発表する情報には、地震と火山と津波に関する予報・速報等がある、地球環境と災害面から見ると、火山＞地震＞津波と連なる事も多いが、それ以外の原因で起きる事も多くある。
緊急地震速報・予報の発表状況が気象庁のホームページに掲載される、そこでは予測震度を含む情報だが全国を約200に分割した予報区を対象として扱っていて予報区と異なる地域設定ならば異なる場合があるとしている、たとえば地震動予報業務許可事業者の予測震度では異なる事もあると言う。
「地震の活動状況」「地震・津波の観測・解析データ」「火山の活動状況」「火山の観測データ」「警報・情報等に関する検証資料」「地震・津波、火山の過去の災害」と情報がホームページに並ぶが、地震速報・予報が出された時にマスメディアが報じる、より詳しい情報はほぼこれらの項目に含まれている。
天気・台風とは異なり、地震と火山と津波の予報は現状では難しいが、中期予報や、発生時の緊急速報や、地震発生時の余震や地震津波予報や、火山噴火後の予測やその影響での地震と津波の予測は、次第に詳しい情報が出される様になった。
これらの緊急地震速報は、鉄道総合技術研究所と気象庁の共同技術開発と、防災科学技術研究所による技術開発で行える様になったと記述されている。
そして、インターネットのホームページには、発表から10分から30分程度の遅れで掲載するとされている。
海洋の観測・解析データも気象庁のホームページに掲載される、短期・中期的には台風情報には日本近海の海面水温情報が利用されているし、台風情報と地震発生時の津波警報・注意報等の情報には日本沿岸の潮位の情報が密接に利用されている。
中期・長期的には、日本近海の海面水温・表層水温と日本近海の海流の観測と解析と将来予測を行い情報を発信している、気温や天候予測とそれによる水産物の漁獲量予測にも使用される、オホーツク海の海氷＝通称・流氷の状態と到達予測も行っている。
潮汐観測と予測である潮位表は、中期・長期的には年表的に出されるが台風来襲時の潮位の警報・注意報は地震時の津波警報・注意報と同様な情報となっている、ネット社会では即日性が向上している。
海水中の二酸化炭素量や海水の酸性化問題や海の汚染問題や浮遊するゴミの問題と情報も海洋観測の対象となっている。
情報収集と解析と情報発信は、日本近海の情報が中心だが、それ以外に世界に拡がっている、世界の海水温度や北極域・南極域の海氷域面積等の情報やエルニーニョとラニーニャ現象の実状と見通しには海洋情報が繋がる。
日本近海及び北西太平洋の海域では気象庁の２隻の海洋気象観測船（凌風丸・啓風丸）が海洋・海上気象観測及び温室効果ガスや海洋汚染物質の観測を実施し、赤道上の静止気象衛星ひまわりで観測を宇宙から行っていて、その情報もホームページに継続的に掲載されている。
海外との情報交換での広い情報収集も行われている。
天気・台風予報以外の災害情報として、地震・火山・津波の情報がある、災害の被害が大きい事もあり、発生する度に予報と情報が求められるが精度上の問題や情報発信方法や、情報以外の対応方法に成果を求めるにはまだまだ課題が多い。
自然科学的な観測とデータ収集と解析技術は進歩して来たが、あくまでも予測確率が向上するだけであり１００％の絶対的な精度は得られる見込みはなく、科学的にも不可能だと思われている。
社会科学的あるいは政治的・行政的な災害に対する対応も同時に向上して来たが、社会全体の理解と合意を得ての対応と対策実施は不可能であり、平均的な合意レベルでの対応に制限される、その中で啓蒙・訓練・継続的な情報発信での準備を行っている。
情報発信手段は情報化時代になり、テレビ・ラジオ放送と有線放送に加えて、インターネットと携帯電話回線を使用した電子メールと無線通話網を使用した手段が使用されている。
地震・火山については長期予報・予測が出されて災害発生可能性・確率として提供されるがその受取方法は周知・統一され難い、地震・火山活動が観測された時のそれ以降の短期予報・予測は生活に密接な情報として受け止められて来ている。
津波情報・予測は、原因が地震・火山活動・台風に基づく事が殆どであり、この事象が発生してから津波が到着する前に情報を如何に発信して対策・避難に結びつける事が出来るかが課題となっている、この予報・予測は実効性と必要性が周知されて来ており現在の大きな災害情報とその課題となっている、そして情報伝達方法としてのネット通信は重要になっている。
プッシュ通知
パソコンやスマートホーン（スマホ）をインターネットに接続して情報を入手する場合は、自らウエブサイト閲覧ソフトのブラウザを起動してネットにアクセスする方法で行う、スマホではブラウザを起動する以外にアプリを起動する事でネットワークに接続して利用する事も出来る。
ソフトウェアやネットワーク通信分野では、データなどを受信側・需要側が自らで能動的に読み出しに行く事が主流でありそれをフェッチ方式と呼ぶ、そして利用者の方が操作を行い情報を受けとるその方式を「フェッチ通知」と呼ぶ。
これに対して送信側・供給側から利用者側に通信する方法が「プッシュ」方式(push)であり「プッシュ通知」と呼ぶ。
受信側・需要側が一定時間ごとに受信したいデータの有無を確認する方法・動作がある、フェッチ方式とも言えるが繰り返して確認する受信側の動作を「ポーリング」方式(polling)と呼ぶ。
「プッシュ」方式と「ポーリング」方式では、送信側・供給側が情報を送るタイミングと利用者側が受け取るタイミングが一致しない事も多くあり、区別が全て明確ではないが送信側の能動的な動きの手段として注目されている。
インターネット情報は、通信とパソコン等を使用するアクセス方式故に、使用方法には制限がある、パソコン等の起動と通信回線への接続は最低限の前提条件となる、それを越えてのプッシュ通知は無い。
現在ではパソコン等の機器の起動時には一部のシステムはネットに通信する設定の機能がある、このタイミングはほぼ完全なプッシュ通知方式と言える。
バックグランドで稼働出来るソフトウエア更新システムも導入されている、それらは設定により自動更新方式と、プッシュ通知内容から可否を選択する方式がある、これは機器利用中に適時行われプッシュ通知も入ってくる、現実は機器を使用していない時間を含めると起動時か直後に通知が来る事が多い。
マイクロソフトのウインドウズの更新は、データ量が大きい事やシステム故に機器の終了時にダウンロードして次の起動時に追加される設定になっている。
プッシュ通知の内容は利用者にとり「緊急性」「役に立つメッセージ」の意味が必要でありそれ以外は設定をオフにすると思われる、これは「プッシュ」方式ではそのソフトやアプリ開発者がユーザーに方式を継続的に使ってもらうための工夫が必要な事を意味する。
「緊急性」「役に立つメッセージ」が弱い場合は、電子メールでの通知や、ソフトの起動タイミングでの通知（含むブラウザ起動時またはウエブサイトへのアクセス時）や、利用者が更新チェックした時に通知する方式等がある。
それぞれはプッシュ方式とフェッチ方式とポーリング方式が混在する。
パソコンではインターネットに接続して使用する場合でも、ローカルで使用する時はプッシュ通知を受ける事例は少なく前回に上げたシステムに強く関わるソフトウエアに限られている、ネットワークに接続して使用する事が前提の場合は事情が異なってくる。
ネットワークに接続して使用する事が前提の携帯電話やスマートホンやタブレットに関しては事情と前提が異なり、機器とシステム全体がプッシュ通知に密接に対応している。
MBaaS（エムバース）は「Mobile Backend as a Service」の略語で2012年にアメリカで使われ始めた言葉とされ、これはスマートホンアプリで利用頻度が高い汎用的な機能をクラウドから提供するサービスだ。
スマートホンアプリ開発者は、MBaaSを利用する事で、あらかじめ準備して提供されている高度な機能をサーバーとそのプログラムの開発なしで使用出来てかつ特別な管理・運用なしでアクセス出来る、これにより開発の工数削減とコストダウンを実現出来る。
mBaaSが提供する代表的な機能に「プッシュ通知サービス」があり、スマートホンやタブレットでは標準のサポート機能となっている、送信者は外部から送りたいタイミングで配信出来て、位置情報で指定のエリアにだけ送信する事も可能とされる、そしてユーザーはプッシュ通知サービスのオン・オフの設定をして受信の可否を決める。
スマホでのプッシュ通知は米アップルの「APNS（Apple Push Notification service）」や米グーグルの「GCM（Google Cloud Messaging）」と呼ばれる通知サービスが登場して一気に普及して同時に知名度が上がった。
APNSはアップルが作成したサービスであり、2009/6のiOS 3.0のリリースと同時に始まったネイティブのアプリで使用されるプッシュ通知だった、そこではプッシュ技術を使ってスマホに於いてが常時にオープン状態のIP接続を通してサードパーティーのアプリのサーバーからの通知を含めて、アップル製のスマホやタブレット端末に情報を転送している。
アップルはAPNSをMac OS X Lion向けにも使用した、そこではサーバーのメールやカレンダーやサービスの利用者へのアップデート通知をプッシュするために使用した。
その作業では通知受信時にアプリケーションが開いていなかった場合には、アプリケーションはユーザーに通知するためにバッジするかドックに追加する、プッシュ通知に於けるバッジとは、アプリアイコンの右上に表示される数字であり、これは未完了タスクと新着メールの表示に使われる、数字はプッシュ配信時に設定が可能だ、バッジはプッシュ通知を見逃した利用者への注意を行う方法として有効で、プッシュ通知の開封率に影響するとされる。
mBaaSの利点は、通常はアプリの開発ではアプリと同時にサーバ側の開発とサーバとの連携などの多数の内容が必要になるが、mBaaSはサーバ側とその連携との機能を一括して提供するので、アプリ開発者には多大なメリットがある。
一方ではMBaaSを使用する事で、開発したアプリの重要な情報やデータをサーバ側に知らせる事になる、同時にブラックボックス的な使用方法になるので、アプリ運営上の何かのトラブルが発生した時に、サーバ側か連携部分に問題が存在した場合にはアプリ製作者が解決出来ない可能性がある。
そのために、サービス利用者はどのサービスと提供業者を選ぶかの判断が重要となる、実使用での実績を積めばそれからの変更が難しくなる、初期ではコスト面も多きい要素だが、他のアプリと利用者の実績を見て信頼のあるサービスを選定する事が必要だろう。
mBaaSのプッシュ通知機能ではプッシュ通知の開封率も把握でき、プッシュ通知を許諾オン設定したアプリは、許諾オフのアプリよりも起動回数が高いとされ、アプリの継続率も同様に許諾オフより高い傾向とされる、それ故にmBaaSとプッシュ通知は検討した事項になっている。
mBaaSとして幾つかある
・Firebase（ファイアーベース）はGoogleが買収したサービス。
アプリ開発に於いてサーバで設定するだけで、データベースと、ログ管理・バグ報告・プッシュ通知などのサーバ側の開発が進められるとしている。
・ニフティクラウド（mobile backend）はニフティ社が提供するサービス。
これも、サーバ側の開発をサポートするサービスだ。
全てが日本語で記載されていて、日本の初心者には判り易く利用しやすいと言われている。
・IGAWorksは、アイジーエーワークス社が提供するサービス。
特徴は、広告との連携だとされる。
・AWS Mobile Hubは、既存のサービスを組み合わせているので拡張性が高く、組み合わせが選べるメリットがある、だが反面では操作が統一されないので利用者に知識が必要となる。
Android向けのプッシュ通知では、FirebaseのCloud Messaging（FCM）を必ず使わねばならなく、AWSやmobile backendを使っても、FCMを経由する。
少なくともプロジェクト登録は必要だ。
Googleは2018年4月にサービス「Googleクラウドメッセージング（GCM）」を2019年4月11日で廃止すると発表した、そして後継サービスである「Firebase Cloud Messaging（FCM）」にアップグレードを勧めている。
