フェリカとクラウドを融合させたソニーの電子お薬手帳サービスへの期待と課題

フェリカとクラウドを融合させたソニーの電子お薬手帳サービスへの期待と課題

（構想～概要）

• フェリカ(FeliCa)ICカードとクラウドサービスを連携させたソニーのビジネスモデルの一つ。

• フェリカカードを薬局の端末にかざせば、クラウド上に保管された投薬データからその人のものが表示される。

• 薬暦データはクラウド上、個人情報はフェリカ上に保存される。

• 今秋から川崎市で試験運用。

（課題）

詳細は今後だろうが少なくとも以下の点はクリアまたは一定の検討が行なわれていなければ駄目だろう。

1. フェリカカードと同様にモバイル端末のフェリカアプリもサポート。
2. 複数の薬局に対して共通のカード/アプリ。それぞれ作るのではお薬手帳の意味も無い。現在のお薬手帳やり方は薬局ごとにばらばらで問題が多い。電子化サービスでクリアしたいポイントだ。
3. 内容確認は個人のパソコン、スマホ、タブレットなどでも出来ること。
4. Ａ薬局に出かけた時に、Ａ薬局の薬剤師は、Ｂ薬局の投薬状況、Ｃ薬局の投薬状況も簡単に確認できるかどうか。どのようなときに其れは認められ、どのようなときに其れは拒否されなければいけないか、のケーススタディ。承認または拒否の手順と証跡。
5. データのオーナーは誰か。
6. 修正または削除の権限者、実施手順が妥当か。
7. 実態を見れば、クスリは貰っても、飲む飲まないは別の話というのは常識。実際の服薬量を記録として管理できること。
8. ジェネリック品かどうかが見やすく表示されること。
9. 余った薬を後で飲むことも現実には存在することを考慮して、消費期限管理機能も欲しい。
10. データの構造が公開され、薬局間で共通化あるいは容易な変換が可能にすること。
11. 病院でも簡単に確認できること。
12. 院内情報システムとの連携の検討。人間ドック時のカード、一般診察カードなどとの連携も。
13. 人の一生分のＤＢ化を視野に入れること。短期間のローテーション利用では信頼を得られない。
14. 他人の電子お薬手帳を拾っても簡単にデータが閲覧できては困る。
15. 毎週病院へ行く人もいれば、数年に1回の人もいる。暫く使っていなくても容易にセキュアな本人確認が出来る仕組みとの連携が必要。バイオ認証？

.*.

AWS-API互換クラウドの問題

AWS-API互換クラウドの問題

アマゾンウエブサービス（ＡＷＳ）

アマゾンウエブサービス（ＡＷＳ）はアマゾン社内で利用してきたネットインフラをクラウドサービスとして一般に公開したものです。少ない初期投資でネットビジネスを実現できるため、ＳＯＨＯ系ビジネス、ベンチャービジネスの間で急速に利用が増えています。

ある意味では、アマゾンが培ったネットビジネスのノウハウがＡＰＩの形で公開されたことになりますから、尚のこと重宝な存在となっています。

アマゾン社自体はＩＴベンダーではありませんから、ネットサービス・ウエブサービス・クラウドサービスを実現する巨大なサーバー環境は普通のＩＴベンダーが構築しています。何処のベンダー？

アマゾンは最高のクラウドユーザーとしてシステム要件を明確にし改善を進めてきた立場になります。

.*.

クラウドベンダーは雨後の筍。それも巨大ベンダーとオープンソース(OpenStack?)系とに集約されつつありますが、ここへきて目立った動きとして、特にオープンソース系ベンダーでは、アマゾンＡＷＳ用ＡＰＩをそっくり利用しようというものがあります。

ＩＢＭがオープンスタックを担いだことで明確な流れが出来ました。ＩＢＭ－ＰＣ互換ビジネスの推移が思い出されます。アマゾンは何れ他のベンダーの利用者に甘んじる時代が来るかもしれません。

アマゾンＡＷＳ互換クラウドと特殊ニーズのクラウドの並列。特殊ニーズの部分は一定の汎用性が確認されれば、拡張ＡＰＩとしてＡＷＳに取り込まれていくでしょう。一部はニッチ用途に残る。

互換クラウドベンダーは単にＱＣＤ（コストパフォーマンス）を競うだけになりますから、ＡＷＳ－ＡＰＩに最適化されたサーバーを作ることになります。

.*.

ISMS的考察

1. 27001規格見直しではクラウド対応要件が検討されているが、これさえ要件の一部と心得るべきである。
2. 技術革新への実務的な対応は事業における競争優位を実現する上では欠かせない。
3. データの分離管理は解決すべき課題だ。
4. マルチベンダー、マルチサイトも標準化が進めば容易になるだろう。
5. 平時・災害時とも通信路の確保は従来より一層深刻な課題になるだろう。
6. AWS-API互換ベンダー利用時は互換性を担保する方法論の確立が必要。システム要素の更新時、切り替え時は戻しの手順なども含めることだ。
7. 標準ＡＰＩを使っていてもベンダー固有の脆弱性を歌が必要はあるので、それを把握する方法論も求められる。マルチベンダーの場合は深刻なリスクになる可能性もある。

.*.

ＡＷＳとＡＷＳ互換の比較考察

アマゾンのクラウド（ＡＷＳ）と他社のＡＷＳ互換ＡＰＩクラウドとの違い？を理解してみよう。単純に、
両者QCDを比較して見てみよう。

• Ｑ（機能性）：
  ＡＰＩ互換を達成していれば基本的に違いは無い。
• Ｃ（コスト面）：
  開発コスト、維持コスト、サービス料金のバランスで考えると、既に投資を済ませて一定のカスタマーベースを確保しているところと、これから新たに投資して回収を図ろうとするところ、カスタマーベースも新規9開拓のところとでは優劣が明確だ。もっとも、後発は最新の技術を利用できるメリットもある。
• Ｄ（サービス実現性）：
  既に各国でサービス提供の実績があり、システム運用に対する高い信頼性を確保しているところと、互換機の信頼性実績はこれから作るところとでは隔たりが大きい。

アップルiOSとグーグルAndroidの比較考察、ＩＢＭ-ＰＣとデルＰＣの比較考察、などとよく似ている。先行馬が最初は独走状態になるが、やがて競争を分ける条件が変わってくる。オープンであるところから生まれる競争が求める価値観の変質を生むのだ。利用者が求める価値化に変化が生まれる。

.*.

クラウドと電力供給の対比は妥当か？

クラウドと電力供給の対比は妥当か？

何処かの記事にクラウドを電力供給システムに対比させた説明がありましたが、どちらも中途半端な知識しかありませんから理解が届きません。

電気というパワーを供給する電力供給システムの発展の歴史。コンピューティングというパワーを供給するITパワー供給システムの発展の歴史。

当初、電力は個別に供給されていた。公共サービスではなかった。工場は自分で発電設備を持って必要な品質の電力を作っていた。電力は自己解決すべきものだったのだ。今の電力は公共サービスになっている。とは言え、災害対策レベルでは自己解決するしかない。今でも工場には自家発電が設備されている。次代の電力供給は電力会社から一方的に供給を受ける関係でなく、相互運用する関係になるだろう。其の中には自然エネルギー利用の電力も、非常時運用の電力も組み込まれるに違いない。

利用者は自分が使っているエネルギーがそもそも何処からもたらされているかは全く気にしない。知ることも出来ない。東電か関電か、何処かの工場の余り電気か、太陽エネルギー化など。あるのはコンセントとメーターだけだ。

ITパワーは企業内のデスクトップレベル、サーバーレベルは自己解決型。データセンターサービスはやや公共サービスに近づいた。クラウド化により相互運用性・公共サービス性を高めた。広域サービス対応のリソースもローカルなリソースも統合的に利用できるようになる。

利用者は自分が利用するコンピューティングパワーはどのリソースを使っているか全く気にしなくなる。

と言いたい所だが、色のない電力と色のある情報は区別しない訳には行かない。純粋なコンピューティングは対比させてOKだが、情報そのものはユニークな発展を遂げていかざるを得まい。

.*.

コンピューティングパワーそのものは対比できるが、情報の色が付いた部分に対する公共サービス化、ユニバーサルサービス化は更なる技術革新が求められるだろう。

.*.

結論

• 対比できるのは色の着いていない部分。

• 電気エネルギーに色が付いていない（と考える）からユニバーサルサービスは成立する。 コンピューティングパワーも色の着いて部分はユニバーサルサービスが成立する。

• 色の付いた部分（情報、コンテンツ、コンテキスト、？）を無色にする技術が確立すれば見掛け上のユニバーサルサービスは成立する。手元には鍵だけ。

.*.

＜ISMSでは何を考えるか？＞

1. IT資源構造の見直し。電力を買うという当たり前のことが、ITパワーにも来る前提でインフラ整備に関する長期プランを見直す。

.*.

クラウド導入時の失敗事例？（ＣＩＯニュースから）

 

クラウド導入時の失敗事例？（ＣＩＯニュースから）

デビッド・ギーア氏のレポートではクラウドコンピューティング7つの大罪のタイトルだが内容的には最近フィーバーから見て取った失敗事例のようだ。

http://www.ciojp.com/technology/t/27/13848

1. 入り口で身元確認をしない：
   クラウドサービスだけで本人認証を完結するシステム事例が多いが企業内システムと連携させる場合は本人認証の仕組みを社内システムのそれと連携させなければいけないが、カスタマイズの手間を押えるためか、簡易型の認証システムを利用する例が多いらしい。簡易型の認証で社内システムに入り込むリスクを抱え込むことになる。もともと社内の認証システムも中途半端なものだったからベンダーが用意するものを採用したのだろうが本末転倒になっている。
2. APIキーの保護を考えない：
   クラウドサービスのメリットを最大限発揮させるためにＡＰＩを公開することがあるが、脆弱性のポイントになりかねない。キーは時間による変更、公開先による変更などの手当てのほか、アクセスエラーのトレースによる不正アクセス管理なども行う。
3. クラウド・プロバイダーに強く依存する：
   クラウド・プロバイダーが提供するサービスは多様化し使い勝手が良く重宝なものとなっているが、企業の命運を全く依存するリスクからの回避を常に考えるべきであると。クラウドの技術だけを社内システムに取り込む工夫も始まっている。
4. リスクや説明責任もアウトソーシングできると考える：
   アウトソース出来ないのは分かっているが、みんなで渡れば怖くないで済ますことは出来ない。昔のＩＢＭ神話と同じか。止まらないクラウドも止まる事があるという現実が示された以上どんな言い訳も通用しない。なぜクラウドかも改めて確認しておくべきだろう。
5. IT担当者やセキュリティ担当者と相談せずにクラウド・プロバイダーと契約する：
   こんな馬鹿なことはありえないと思うが、現実には情報システム部門との面倒なやり取りを回避できるし巨額の設備投資も顔を出さないので事業所・部門・グループ会社などで契約する例が後を絶たない。ＩＴガバナンスの方法論が問われる。
6. クラウドのセキュリティを過大評価する：
   クラウドサービスプロバイダが一流のセキュリティ監理者かどうかは分からない。「特定のセキュリティ機能の提供、セキュリティ・タスクの文書化、すべてのセキュリティ・ポリシーおよびセキュリティ対策をまとめた一覧の提供、そしてセキュリティ報告書の提出を要求するべき」との記載もあるが、その前に企業のセキュリティ要件を明確に出来なければ交渉にもならないだろう。
7. コストを正しく理解しない：
   標準サービスは安いが極めて限定的かもしれない。サービスの多くがオプション化されていることもあるようだ。自社システム側の回収も発生するかもしれない。結局、何年でいくら掛かるのか。見掛けの数字で稟議を通してプロジェクトを始めたら思わぬ費用に驚いて立ち往生する例もあるんだろう。

.*.

まだまだ調べることがありそうだ。

オフィスからサーバーが消える日？クラウドリスクの本質？

オフィスからサーバーが消える日？クラウドリスクの本質？

クラウドの領域がミッションクリティカル領域にまで広がるという話がある。いずれは社内サーバーがなくなる日が来るという話も。こういう極端な論争は新たな技術が紹介されるといつも起きることです。

会社に各事業領域をカバーする基幹サーバーが本格的に導入されると部門サーバーはなくなる。でも無くならないから二重投資防止を盾に禁止するしかなかった。決して自然淘汰されない。

パソコンからモバイルまでの個人端末はどうか。通信機能だけでインテリジェンス無しの馬鹿端末に置き換わることは気配すらない。

知的労働者がその生み出す情報の一切を組織に預けることを良しとする訳がない。業務上の成果だからとして組織がむしりとっていこうとするが、個人と組織の間は決して支配・被支配の関係ではない。

とは言え、実質的には既に始まっている個人クラウドは今後ますます日常的なものになる。

部門サーバーは部門に割り当てられたクラウドサービスの利用になる。

.*.

なぜクラウドだけが残るといえるのか？

個人のスモールオフィスは勿論、企業の部門でも、企業の情報統括部門でも、セキュリティの維持が出来なくなるからだ。セキュリティリスクが高まれば対策も中途半端ではすまなくなる。セキュリティの維持に掛かる費用も膨大なものになる。

セキュリティ対策の十分な専門の企業を立ち上げる。大手企業なら資本的にも人材的にも影響を及ぼすことができる専門会社が既にあるだろう。

オフィスの中は中継装置、通信装置だけが残ることになるだろう。

.*.

大規模ネット障害への対策は最後まで残る。二重三重の回線を確保するのは当然だろう。

.*.

ガソリンＯＩＬなどエネルギーも社会の基盤で資源は有限であり産油国も限られるからコストは常に不安定です。クラウドの大前提はブロードバンドの普及で実現した安い通信料金があります。しかし、ビジネスが個人の利用を圧迫し始めると法律が動き始めるでしょう。ビッグデータを無尽蔵にネットに流し始めれば歪（いびつ）な状況を生みかねない。先を争うだけでなく健全な発展を意識した業界の取り組みが必要だろう。

.*.

クラウドの定義

クラウドの定義

The NIST Definition of Cloud Computing

http://www.nist.gov/itl/cloud.cfm

http://csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pdf

対訳

http://agilecatcloud.com/2010/02/22/

.*.

クラウドの定義は変遷を続けている。定義が引用されることが多いＮＩＳＴ自体がその変遷を認めている。ＮＩＳＴは全容を包括できる定義を試みているようだが本質を見極めないとその内、ネットワークとネットワークサービスは全てクラウドで表現されるかもしれない。

乱暴だけどネットの先の直接見えない世界は全部クラウドでも良いんじゃないか。糸電話みたいに物理的に直通の世界はさておいてインターネットがそもそも不確定のネットワークで得体が知れない。 だからクラウド。クラウド＝不確定＝仮想？。柔構造のネットワークとサーバーとサービス。

ネットワークリソースとして存在するものは全てクラウド。？

.*.

クラウド・コンピューティング:

クラウド空間が提供するコンピューティング能力、コンピューティングサービス、 コンピューティング技術、ということになる。

不確定時空のコンピューティングデマンドへの対応だから革新も求められる。

仮想領域をコントロールする 管理技術も求められる。

想像を超えるセキュリティ課題が出てくるだろう。

.*.

クラウド・コンピューティング・サービス

クラウドはネット接続された世界。最悪？のケースでは、不特定アクセスを前提とするサービスだから、コンピューティングサービス要求の変動に応えるための動的なシステム再構成能力が求められそのことを特徴としている。

インターネット回線であっても、専用回線であっても、ネットワークサービスの利用者は不特定のパターンでサービスを利用するので、動的再構成の技術はコストパフォーマンスがクリアできれば導入できる。

ピークタイムが異なる複数のサービスを統合すればトータルとして少ないリソースで対応できるメリットは大きい。オンプレミス、オフプレミス統合も出来ないわけではないだろう。

何が想定外なのｋ。想定できていないことは何もないか。その辺の経験と学習を今進めているわけだ。

さて、動的再構成技術の内容はサービス提供者の話で、利用者からすれば、単に安価なネットサービスの享受に過ぎない。極端な離し、サービスを利用する手順がインターネット接続に準じたものになるに過ぎない。端末利用者はそのことすら意識しないで良いだろう。

.*.

クラウドをビジネスに利用し始めた企業

クラウドをビジネスに利用し始めた企業

クラウドは負荷対応の弾力的運用という側面が評価されている。ミニマムのリソースで最大の効用を得ようというものだが、ぎりぎりで設計するとNTTの通信ダウン事故みたいに何度も失敗する。やはり余裕を持っていないと安心できない訳です。

クラウドのもう１つの側面はインターネット（イントラネットでも）の利用です。企業グループ内や、ビジネスパートナー、あるいはユーザー～顧客との情報連携がしやすいということです。

これって必ずしもクラウドであることを要求するものでは有りません。ただ、不確定のニーズに対する備えとしてクラウドは取り敢えず有効であろうとの理解は得られます。

.*.

一方で、クラウドは幻滅期に入ったとする観測もある。

実際に、そんな余裕で幾つもサーバーを動かしていなければクラウドに変えるメリットは出ない。頻繁に設備増強に追い込まれるような急激な変化は、クラウドにしても容易ではあるまい。

クラウドにすることで、一部のトラブルが全体に波及するリスクもある。途上技術。

.*.

クラウドの信頼性に盲点？アマゾンの事例検証

クラウドの信頼性に盲点？アマゾンの事例検証

クラウドはハードウエアとサービスの対応関係をフレキシブルにしたものだから、ハードウエアの制約による性能低下、信頼性低下からフリーなのが有利なポイント。

ところが、クラウドサービスをもう一つのビジネスに仕立てているアマゾンでトラブルが立て続けに発生している。原因はアマゾン以外から来ているが、別サイトへの切り替えなどがスムーズに行かず結局サービス停止を招いている。

アマゾンのクラウドサービスのクライアントは小規模事業者が多いが、それだけ専門性の高いエンドユーザーサービスを行なっていてアマゾンクラウドのダウンによる影響は決して小さくない。

アマゾン･クラウドに限らないが、複数のベンダーによる協調型システムにならざるを得ない。しかも個別部分がそれぞれ成長していくので、ますます全容把握は困難。

福島原発も想定外が生じて簡単に弱点を露呈した。想定しなければいけないことまで想定外として扱われていた。会社間の軋轢、監督官庁や発注元との軋轢、技術者の面子、費用負担問題などが表に出てきて、本旨が置いていかれる自体が生じている。

アマゾンのクラウドの障害は、クラウドにもきっと何か特徴的な脆弱性が潜むであろうことを予感させてくれただけでも十分な価値のある現実だ。

.*.

クラウド事業者のインド進出加速が示唆すること

クラウド事業者のインド進出加速が示唆すること

普通のデータセンターを利用しているつもりだったが、知らない間に会社のデータはインドに出ていたなんてことに。

平時は国内にあるが、クラウド事業者のトラブル時にはインドへ出ていたとか。

.*.

• クラウド上のデータの安全性はどのように保障されるのか？

• 海外に出た情報の安全性はどのように確保されるのか？

法律も国の成り立ちも違う。インドは中国･ロシアほどのギャップは無いにしても、何処が守るべき線か明確にしておかないといけない。

.*.

クラウド利用時のコンプライアンス

クラウド利用時のコンプライアンス

クラウド環境利用に関連して生じる法的問題・課題について日経に記事が出ている。（詳しい生地は日経電子版にあるのかな？）

要点は３つ。

1. コンテンツをクラウドに保存して利用する場合。そのサービスを提供する業者はコンテンツ（著作物）の複製権、公衆送信権を侵害していると見做される恐れがあるというもの。
2. クラウド環境のグローバル利用の場合は、国家機密など国際的な平和や安全に関わるもの･技術の国際間取引では担当大臣の許可が必要とする外為法への抵触の懸念がある。大臣の許認可基準が明確でない。
3. 個人情報をクラウド上で扱う場合（クラウド上でなくても同じですが）、EUのデータ保護指令のように個人情報保護水準をEU同等することを求められるなど、個人情報を海外に保管することへの制約がある。（個人情報保護については日本はEUより低水準とされている）

.*.

「ISMS」ではどうなるんでしょう？

①　直ぐに思い浮かぶのが、準拠法令の洗い出し。コンテンツサービス事業、クラウドの国際利用（海外クラウドの利用、海外からの国内クラウド利用）、個人情報管理でのクラウド利用などが事業・業務に収まる場合は適切に洗い出されていることですね。

②　コンプライアンス違反とならないようにする規定・手順が明確にされていること。これは難しい。特にコンテンツサービスに絡むところは、著作権を持っているコンテンツかどうかはサービス業者からは分からないから。利用規約で健全な利用義務を入れてその内容として著作権法あるいは公衆送信法？に抵触しないことを求めておく必要がある。しかし、やりすぎると利用者が現れなくなるだろうから容易ではない。

.*.

クラウド利用時のISMS問題？

クラウド利用時のISMS問題？

初期の頃は日本の法律で裁けないのが問題でした。クラウドは海外ばかりでしたから。今は国内にクラウドセンターが出来て解消しました。

次はサーバーが特定できないことを問題にしていました。共同利用であることも問題とされています。

クラウドセンター施設の維持も問題にされています。移設、建て替え。同じベンダーでも心配ですが、違うベンダーへ移る場合に何が課題になるのか。

何がベンダーの資産で何が自分たちの資産か、切り分けは上手くできるのか。なかなか現実にならないと課題が見えてこないものです。

.*.

ベンダーにISMSの取得を条件付けるのは当然でしょうね。自分たちが中に入れない分、第三者に中に入ってもらってチェックして欲しい。それも出来れば3年ごとに審査機関を変えてもらう。迎合的審査・癒着型審査の懸念を払拭させたい。

.*.