Category: Industries

ヘルスケア・ライフサイエンス ソリューション部では、お客様の課題に対してAWSの技術支援やアーキテクティングを実施しておりますが、支援の一つとしてプロトタイピングを提供しています。今回は、塩野義製薬株式会社(データサイエンス室、デジタルインテリジェンス部)、シオノギデジタルサイエンス株式会社と行った、モバイルアプリ開発のプロトタイピングを報告致します。プロトタイピングでのクイックな開発を実現するにあたり、共同でリアルタイムにコーディング可能な統合開発環境(IDE)であるAWS Cloud9と、フロントエンドの実装から、認証、AI、データ登録・参照、Amazon S3に蓄積したログの分析といったバックエンド実装までをAWS Amplifyを利用することで2日間でアプリ開発を行いました。

Amazon Web Services (AWS) と 米・国立衛生研究所 (National Institutes of Health :NIH) の米・国立生物工学情報センター (National Center for Biotechnology Information: NCBI) は、新型コロナウイルス感染症  (COVID-19) の研究を支援するためのコロナウイルスゲノム配列データセットの作成を発表しました。このデータセットは AWS Open Data Sponsorship Program によってホストされ、AWS 上の Registry of Open Data でアクセス可能であり、研究者がCOVID-19の研究で使うためにコロナウイルスの配列データに無料で素早く簡単にアクセスできます。 コロナウイルスのデータをクラウドに一元化 コロナウイルスゲノム配列データセット は、研究者が提出した次世代シーケンスのデータ(元のファイル形式)と、米・国立医学図書館 (National Library of Medicine : NLM) で NCBI によってホストされる SRA プロセスのシーケンスデータ(ETLファイルフォーマット)の集合体です。このデータセットは、NIH Science and Technology Research Infrastructure for Discovery,Experiments,and Sustainability […]

はじめに みなさんこんにちは、ソリューションアーキテクトの福嶋、渡邊です。AWS では 2018 年・2019 年と実施してきた自動車業界向けクラウドテクノロジーカンファレンス「AWS Autotech Forum」を夏と冬の2日間に拡大し、「AWS Autotech Forum 2020 Online #1」を8/7にオンラインにて開催させていただきました。オンライン開催第一回目となる今回は、MaaS、自動運転開発、コネクテッドカー、エッジコンピューティング、マップ／ロケーションサービス等の分野において、先進的な取り組みを志向する企業のビジネスリーダー、エンジニアの方々に向けて、お客様の新たなビジネスをご支援させていただく中で学んできた、汎用的に利用可能なプラクティスやテクノロジーの活用シーンを AWSのソリューションアーキテクトからご紹介させていただきました。 オープニング 自動車業界における AWS の取り組みとお客様事例 ソリューションアーキテクト安藤から皆様の新しいビジネスの企画立案に役立てていただくために、 AWS の活用事例や取り組みについてご紹介しました。 テクノロジートレンドの CASE (Connected/Autonomous/Shared/Electric) はすでに多くのお客様が取り組まれており、ビジネストレンドである MaaS への注目度も日増しに高まっています。 MaaS にはエマージングビジネスの側面と企業間アライアンスによる新プラットフォームビジネスの側面があり、AWS を活用いただくことで「価値創出への集中」「最新技術の活用」「試行錯誤の繰り返し」といったメリットをご享受いただけます。 セッションの中では実際に、 AWS をご活用いただいている企業の事例や CES 2020 において Amazon と AWS が共同で発表した自動運転で走行する電気自動車におけるカーシェアリングサービスのコンセプトデモを例に AWS をご利用いただくことによるメリットがどのようなビジネス効果を生み出しているかをご説明しました。 登壇資料: 自動車業界における AWS の取り組みとお客様事例 MaaS関連セッション AWS Connected Mobility Solution (CMS) のご紹介 ソリューションアーキテクト高野からは、コネクテッドモビリティのシステム開発に関する AWS […]

アマゾン ウェブ サービス ジャパン株式会社 インダストリー事業開発部 の佐近です。 ヘルスケア領域のシステム企画・開発・運用にご興味をお持ちのエンドユーザーおよびパートナーを主な対象として2020年7月16日に開催したウェビナー「AWS 環境上での医療情報ガイドライン対応の最新動向」は、400名以上の方々にご視聴いただけました。 本記事では医療情報システム向けAWS利用「リファレンス」作成パートナー5社の登壇内容を含む当日の資料・動画と、ウェビナー視聴者にAWSの活用を今後1年以内で新規にご検討中の分野を伺ったアンケートの回答結果を皆様にご紹介します。

創薬研究において、クラウドリソースの活用は有用です。例えば、大規模計算に必要なHPC環境を必要な時に瞬時に立ち上げて処理したり、目視による画像分類・判別を機械学習により自動化する事で、従来多くの時間がかかっていた業務を短縮することができ、創薬プロセスを飛躍的に効率化することが可能です。しかしながら、クラウドのサービスやソリューションが業務にフィットするか検証するために、計算環境や機械学習環境を構築するには手間と時間がかかります。そのため、ヘルスケア・ライフサイエンスチームでは、創薬ワークフローに対するハンズオンといった業界特化のソリューションを提供することで、機能やソリューションが業務にフィットするかユーザの方々に体感頂いております(例えば、「化合物の溶解度予測」の内容はこちらに記載しています)。今回、当該ハンズオンに対してご要望の多かった、「AWS CloudFormation (以下、CFn)によるテンプレート化」を2つのハンズオンコンテンツで実装し、数回のクリックだけでご自身の環境にDeployできるようにしました。これにより、幅広いユーザーの方に利用頂き、ソリューションを体感頂ければと思います。

“undifferentiated heavy lifting”という言葉をしばしば聞くことがあると思います。これは、競合他社との差別化にはなりえない作業にリソースを大量に消費することを言います。たとえば、サーバを構築し、OS にセキュリティパッチを適用するようなことです。このような作業は、より付加価値が高い製品やサービスを生み出すための活動から、ヒト・モノ・カネを奪い去ります。AWS では、お客様起点の重要な役割として、作業を簡素化し、自動化できるクラウドによるソリューションによって、開発者を”undifferentiated heavy lifting”から解放できるように支援しています。 金融業界では、過去20年間で大きな進歩を遂げています。たとえば、キャピタルマーケットの領域では、クラウドによるマーケットデータの活用により、トレーディングチームはリアルタイムでより良い洞察を導き出し、増え続けるデータからリスクをより効率的に計算できるようになりました。 しかしながら、いくつかの企業にとって、”undifferentiated heavy lifting”はまだ存在しています。それらの1つは、金融機関が規制機関や取引所によって設定された規制や業界ルールを遵守しなければならないことに関連しています。市場参加者は、これらの市場ルールを遵守する必要があり、遵守しない場合はペナルティを受ける場合もあります。 金融業界は、進化し続ける要件の複雑さと細分性が高まっている世界で最も規制の厳しい業界の1つです。しかし、金融機関がコンプライアンスに投資するすべてのリソースについて、多くは義務から機会への移行を行えていません。言い換えれば、ほとんどの金融機関では、同業他社との差別化を図るのではなく、ビジネスを行うためのコストとして、依然として規制やコンプライアンスを捉えています。 野球で例えるならば、プレイヤーはゲームのルールに従わなければなりませんが、優れたプレイヤーは、常に個人とチームの両方のレベルでパフォーマンスを改善するために戦略と戦術を使用しています。同様に、企業は規制要件に対応する必要がありますが、合理化、自動化、コスト効率の高い方法でそれに対応する必要があります。 このブログでは、日本取引所グループ (JPX) が AWS でどのように市場参加者にとってより良い顧客体験を生み出しているかをお話します。JPXは、これまでネットワークへのアクセスに関連していた”undifferentiated heavy lifting”を排除することで、市場参加者が新しいサービスのテスト、構築、立ち上げに向けてリソースを再利用できるようにしています。 JPXは、メンバー企業のクラウドでの市場アクセスを強化 2020年5月、JPX は市場参加者が AWS Direct Connect を介して、売買システムや清算決済システムなどにつながる高信頼ネットワークである arrownet にアクセスできるようにしました。 以前は、会員企業がarrownetに接続したい場合、JPXと自社のオフィスやデータセンター間に専用線を注文し、そのうえでネットワーク構築やセキュリティ対策を実施する必要がありました。このネットワーク構成は、変動する市場に迅速に対応するための信頼性と安定性が必要で、さらに十分な通信容量を提供する必要がありました。回線が接続されると、市場参加者は24時間365日体制で監視し、ハードウェア障害に対応するために人的リソースも投下する必要がありました。また専用線ベンダー側の監視にも、これらの重要なタスクのための人件費とサポート費も付属しています。つまり、arrownetへの接続は、利用者が長年にわたって対応してきた”undifferentiated heavy lifting”とも言えます。 JPXは、市場参加者からフィードバックを取り入れ、arrownetをクラウドに拡大し、市場参加者のアクセスを簡素化しました。市場投入までの時間が短縮され、マーケットからのデータを AWS 環境で扱うことで、マーケットの変動に対してオンデマンドで拡張できるようになります。 JPX は AWS Direct Connect の仮想インターフェイスを提供します。これにより、会員企業は短い期間でarrownetに接続して、テストすることができます。その結果、AWS の利用者は、以前は専用回線接続で直面していた”undifferentiated heavy lifting”な作業をすることなく、クラウド環境でマーケットからのデータを受け取ることができます。 現在の会員企業がこの合理化されたマーケットアクセスの恩恵を受けるだけでなく、FinTech スタートアップも恩恵を受けることができます。多くの Fintech スタートアップは AWS のサービスを使用しているため、彼らの既存の環境をより効果的に活用するには、クラウドネイティブ接続が必要でした。マーケットへの迅速なアクセスができるようになったFintech スタートアップは、新製品やサービスの市場投入までの時間をさらに短縮することができるでしょう。 現在、AWS Direct Connect により、JPX […]

AWS は、デジタル変革を進める小売業のお客様からの 「最先端のリテールソリューションを内製したい」というご要望にお応えするために、お客様自らがレジなし無人販売冷蔵庫を迅速に構築し学習や体験ができる This is my Smart Cooler プログラムを発表します。

本投稿はワールドワイドで金融業界を担当しているプリンシパル・テクニカルプログラムマネージャーの Jennifer Code による寄稿を翻訳したものです。 私の同僚の Ilya Epshteyn が、 金融機関が機密性の高いデータのためにAWSサービスを承認する方法 というタイトルのブログでご紹介したように、金融業界では一般的にクラウドサービスの正式な評価プロセスが存在します。これらの評価プロセスは深さや幅に関しては様々ですが、いずれのプロセスも、業界の期待とテクノロジーリスク管理の健全性を確保しつつ、ビジネス要件を満たすのにはどのクラウドサービスが最適かを決定しようとするものです。このブログでは、クラウドサービスに対する新たな評価プロセスを構築する、または既存の評価プロセスを最適化する際に役立つシンプルなガイダンスを提供します。 私は、お客様と頻繁に会ってお客様のガバナンスとクラウドの評価プロセスについてディスカッションをしますが、その中でよく耳にするテーマがいくつかあります。１つ目は、評価プロセスが正式に存在する場合であっても、オーナー不在の場合が多く、結果としてそのプロセスが達成すべきビジネス上の成果を必ずしも理解しないまま、チームがプロセスに従っているという問題です。強いオーナーシップがなければ、参加者と評価範囲に一貫性が保てません。また、時には、構造化されたフレームワークではなく、個々の専門知識とベストエフォートに依存しているため機能性に差異が生じている場合もあります。最後に、お客様は、ほとんど例外なく、知識の共有を進めつつ、繰り返し学ぶことによって、評価プロセスの質を一気に向上させる方法があるのではと感じています。 正式なクラウドサービス評価プロセスがとても重要なのはなぜでしょうか? 金融サービス会社は、テクノロジーリスクの監視を証明するという、共通の規制上の義務を負っています。従来、企業のリスクフレームワークは、サイロ化された「3 つのラインによる防御」または (3LoD) で構成されていました。第一のラインはリスクの所有者としてコントロールを実行するビジネス / 運用担当者、第二のラインはリスクのモニタリングとコントロールの評価を行うリスク管理担当者、第三のラインは独立または内部監査人、またはリスクアシュランス担当者で構成されています。これらの 3LoD はそれぞれ、テクノロジーリスク、一般的な社内のポリシーの収集、ならびに他の防御ラインによって行われた一連の評価・監査に合わせて自チーム内で文書化された手順についての責任を負ってきました。 この既存の企業リスクフレームワークにクラウドの評価プロセスを組み込むことで、組織は重要な技術上の意思決定がどのように行われたかを適切に証明できるようになります。また、リスクがどのように評価され、軽減されるか、コントロール環境の強さがリスクアペタイトにどのように適合しているかといった点を、クラウドベースのサービスの微妙な差異に焦点を当てつつ説明できるようになります。 クラウド評価を最適化するためのヒント 金融サービスのお客様の期待を念頭に置き、お客様がクラウド評価プロセスを構築または改善するために実行できる3つのアクションを提案します。 ガバナンス体制の正式化。ガバナンス体制が正式に確立されていない場合、金融サービス機関がとるべき最初のステップは、クラウドのガバナンスとコントロールに関してエンドツーエンドの責任を担うC-レベルの経営幹部を任命することです。 プラットフォーム コントロールの優先順位付け。クラウド評価を策定する際に、優先順位と要件について、クラウド・プラットフォームとビジネス・アプリケーション機能の区分を取り入れます。セキュリティとレジリエンスのためのプラットフォームレベルのコントロールを最初の優先事項として重要視します。ビジネス・アプリケーションの機能に視点が移った時に、クラウドプラットフォームから継承されたコントロールに基づいて評価を調整できるようになります。 継続的な改善の組み込み。 知識共有と継続的な改善は、Day 1から明確に優先されるべきです。積極的な透明性があることにより、コントロールが構築され評価が行われる際に、3つの防御ラインすべてにわたっての信頼が築かれることが期待されます。意識的かつ積極的な共有によって、コントロールが設計されており、最初の本番ユースケースに対しても効率的に実行することができるという自信につながります。 AWSの使用量と専門知識が増えるにつれて、コントロールの強化と適用範囲の継続的な改善も容易になります。 ガバナンス体制の正式化 重要な最初のステップはクラウドのガバナンスに対する完全な説明責任を持つ適切な Cレベルの経営幹部を特定することです。この個人は、はじめにクラウドのガバナンスとコントロールのトーン設定を行い − クラウドの評価、使用状況、および継続的なモニタリングのための構造とプロセスを構築する責任をもちます。重要なのは、組織全体の専門知識を活用して、十分に制御されながらアジリティのある環境を確立するよう促す意欲のある、強力でポジションの高いリーダーを任命することです。 そのガバナンスのリーダーは任命され次第、評価プロセスを形成する機能横断的な構造、成文化されたポリシーと必要となるガバナンスプロセスを正式化し、現在進行中の評価のサポートをしなくてはなりません。私の経験では、正式なガバナンスの枠組みに支えられた多様な専門知識を活用できるバーチャルなチームが最も効果的です。 効果的なクラウドガバナンスの考慮事項 効果的なクラウドガバナンスの目標を定め、専門知識を正当に評価する企業全体のクラウド戦略 は、導入と使用状況を測定しながら時間をかけて構築します。 クラウドガバナンスに責任のある経営幹部を任命、従事、およびコミットすることで全体的なガバナンス構造に統合し、継続的なモニタリングを行います。 知識が豊富で 参加を約束できる（3 つの防御ラインにまたがった）リスクとコントロールのステークホルダーをクラウドのガバナンス活動における正式な参加者 にします。 企業のガバナンス フレームワークとプロセスに準拠することで、クラウドイネーブルメントチームの存在を明確にします。 定義されたプロセスを組織に伝達するとともに、承認されたクラウドサービスのみを利用していることを確実にする自動強制機能を使用します。 プラットフォーム コントロールの優先順位付け 私と顧客とのやり取りでよく見られたパターンは、クラウドサービスを評価するにあたり、たった１つのアプローチを作成し、それを全てのパターンに当てはめようとするやり方です。これは典型的に、各サービスを個別に評価する形式をとり、多くの場合、体系的に完成された詳細なチェックリストを伴います。 なぜこれが理想的ではないのでしょうか? 第一に、これは各サービスへの脅威は同等であることを前提としています（したがって、同じ評価が必要なコントロールを決定する適切な方法とされます）。第二に、このタイプのアプローチでは、評価者が能力または機能により区別することは認めていません（たとえば、データを中心としたサービスとコンピューティング サービスの違いを考慮しません）。最も重要な点は、既存の統制基盤を考慮していないことです（したがって、追加のコントロールの必要性を過大評価してしまう可能性があります）。 私が見てきた中で最も効果的だったのは、交渉不可能な基盤を確立した上で、環境、データの機密性、ビジネスの重要性など、他の要因に基づいて必要なコントロールを追加する、段階的なコントロール フレームワークです。この区分けによって、不適切なレベルのリスクを発生させることなく、実験を行うことができます。具体的には、すべてのデータタイプ、すべての環境において最初から予防的統制でなければならないコントロールもありますが、その他のコントロールではモニタリングをサポートすることによって、発見的統制から始めることが許容できるかもしれません。適切にコントロールされたイノベーションが目標です。 […]

電気ガス水道などの公共事業において、設備をIoT化しクラウドと連携する動きは、日々加速しています。 ユーティリティ設備においてクラウドに繋がることによるメリットとしては、主に以下のようなものが挙げられます。 省人化によるコスト削減 点検、保守など、人が行っている作業の自動化・半自動化することによって、コスト削減が図られるケースがあります。例としては、保守が必要なタイミングをシステムが判断することで、施設への訪問回数の削減を行ったり、設備のリモート操作を可能にすることにより、訪問自体を無くすことが挙げられます。 新たな付加価値を利用者に提供 ガスの使用量などの情報を紙ではなく、電子化し、スマートフォンやPC上でいつでも確認できるようにしたり、ユーザーの利用傾向をインテリジェントに分析し、最適なプランや利用料を下げる方法があります。 この投稿では、一つの事例として、北海道ガス株式会社（以下、北ガス（読み方：キタガス））様の例を取り上げます。北ガス様は、AWS IoTのサービスを活用することで、大規模なインフラ構築の投資不要で、高速にPoCを実施しています。北ガス様の抱える課題と、その課題解決のためにどのようにAWS IoT のサービスを活用しているかについて、技術的な視点でご紹介したいとおもいます。 エネルギーサービス事業における課題 北ガス様は、北海道エリア内にて都市ガス事業・電力事業を主なビジネスとして手がける総合エネルギーサービス事業者です。持続可能な社会を支え、北海道に最適なエネルギー社会を創造するべく、ガス、電気、熱、再生可能エネルギーの最適利用と、デジタル技術の高度活用を通じて「持続性」「環境性」「経済性」に優れた新たなエネルギーシステムの構築を目指しています。近年では、デマンドサイドのエネルギーマネジメントによる省CO2・省エネルギーの推進を図るとともに、電気・冷温水を供給するエネルギーセンターを構築し、特定エリア内におけるエネルギーマネジメントを行うCommunity Energy Management System (CEMS)を導入・運用するなど、エネルギーに関わる広範なサービス事業を展開しています。 総合エネルギーサービス事業の展開にあたり、業務用分野においては、お客さまのガスや電気の使用量実績を把握するだけではなく、ボイラーや空調機器、暖房機器等、お客さまが実際に機器をどのように使い、室内環境がどのように変化したのかを把握するデマンドサイド（需要家側）のデータ収集が求められていました。 業務用機器を含むエネルギーシステムは、機器単体の性能・効率向上だけではなく、エネルギーシステム全体として、需要家側の最適利用や省エネを図る必要があり、こうした運用は需要家側に任されております。しかし、積雪寒冷地の北海道では、季節によってエネルギー負荷が大きく変化するため、需要家側で最適な運用ができていないケースが散見されていました。 お客さまの最適運用・省エネを支援するため、機器データや室内環境データを把握することは重要な取り組みと位置付けておりましたが、測定した様々なデータをクラウドにどのように集め、蓄積し、可視化するかに関しては、知見に乏しく、多くの課題がありました。 アーキテクチャの検討 この件に限らず、データ分析や機械学習のワークロードを進めるうえでは、過去の大量のデータが必要となる場合が多くあります。一方で、これからIoT化を進めるケースでは、過去のデータが存在しないケースがほとんどです。さらに、エネルギーサービスなどで分析に使える実データを集めるためには、季節変化等も考慮する必要があるため、データ収集には長い期間が必要となります。 今回のケースにおいても、最初に着手するべき事項として、データを集めて蓄積する部分に焦点を絞り、データ収集・分析基盤のアーキテクチャ設計と構築をすすめました。設計議論における観点は以下のようなところです。 保守・運用にかかる作業を最小化したい。コストを抑え、短期間でPoCを完了させ、次のステップへ進みたい。 蓄積したデータに対して、今後様々な活用が可能な状態にしたい。例えば機械学習やBIツール等を使う可能性を視野に入れる。（具体的な活用方法はこれから考えたい。） デバイスの設置場所は、Wi-Fiなどのインターネット環境が無い場合を想定している。 これらのポイントを考慮したうえで、以下のようなアーキテクチャを設計しました。 ハードウェア・通信環境 このPoCでは、上述のとおり、データの蓄積を主眼としているため、新たなハードウェアの開発は行わず、市販のデバイスを組み合わせてハードウェア環境を構築しています。クラウドへの通信、およびエンドポイントにはSORACOMを用い、そこからAWS IoT Coreへすべてのデータを送信しています。1つのゲートウェイに接続されている複数のセンサー情報が、1つのJSONドキュメント形式でまとめられており、それが一定時間間隔で送られます。 SORACOMからIoT Coreへのデータ送信では、クラウドリソースアダプタであるSORACOM Funnelを利用しています。ゲートウェイからのデータは、SORACOM Funnelを介して、アクセスキー認証によるHTTPS通信によりIoT Coreへ送信しています。本構成では、SORACOM Platform 上で認証情報を管理することで、物理的なハッキング対策を講じるとともに、ゲートウェイからSORACOM Platformまでは閉域網で通信することで、セキュアなIoTシステムを構築しています。 IoT Coreに送られたデータは、IoT Coreのルールエンジンによって、AWS IoT Analyticsへと送信されます。ルールの設定は数クリックで可能であり、SORACOMからIoT Coreへ送られるすべてのメッセージをIoT Analyticsに送る設定を行いました。今回のPoCで作成したルールは１つのみですが、ルールを増やすことによって、例えば、IoTデバイスから届いたデータの値が一定値を越えた場合にE-mailなどでアラートを通知したり、アプリケーション用のデータベースを更新するなど、柔軟に拡張することが可能です。 さて、IoT Analyticsにデータが届くと、IoT Analyticsは内部で、送られてきたJSONをパースし後段の分析で利用可能な形式への変換を行います。ここでは、IoT Analyticsのパイプラインに Lambda Activity を追加し、データが一定量もしくは一定期間蓄積されたら自動的にLambdaを呼び出す設定を行いました。Lambda関数の中で、JSONオブジェクトから必要なデータのみを抽出し、1つのオブジェクトに含まれる複数のセンサーデータの情報を配列に変換し、データストアに保存するようにしました。 分析 IoT Analyticsでは、データソースおよびデータセットの保存先としてS3を選択しています。S3を選択することにより、将来的にAthenaやGlueなどの分析系のサービスや外部ツールを利用し、より高度な分析も行うことが可能になります。 […]

IoT@Loft の第10回目は「スマート工場（IIoT）に向けた課題と取り組み 〜見える化、予知保全、品質管理〜 vol.2」をテーマに、2回目となるオンライン開催を行いました。 工場のIoT 化は、予知保全、生産性向上、デバイス管理、設備の安全管理など多岐にわたり、収益向上やコスト削減を実現しています。今回、様々な分野で工場のスマート化にご尽力されているエンジニアの方々にご登壇頂き、現場の課題とそれに応えるソリューション事例などをご紹介頂きました。また、IoT@Loftでスマート工場をテーマにするのは今回が2回目となります。前回スマート工場をテーマに実施したIoT@Loftの情報や登壇者の方の資料はこちらにあります。さらにこれまでのイベントまとめ記事はこちらにありますので、合わせて確認してみてください。 この回では、目視検査を AI で自動化する取り組みについてシーシーエス様に、工場オペレーションを管理するアプリケーションについて丸紅情報システムズ様に、そして製缶ラインの高速機械をIoT化した取り組みについて東洋製罐様にお話いただきました。また、AWSからはスマートファクトリーを実現する AWS の IoT ソリューションについて紹介しました。