Category: Best Practices

内閣官房と総務省より「第二期政府共通プラットフォームにおけるクラウドサービス調達とその契約に係る報告書」（以下、『報告書』）が発行されました（令和２年８月５日付）。   今回の『報告書』は、内閣官房IT総合戦略室・総務省行政管理局の２府省により構成される「政府共通プラットフォームの構築・活用推進及び政府におけるクラウドサービス利用検討」プロジェクトチーム、クラウド利用戦略・企画担当の皆様より、作成・取りまとめをいただいた報告書となります。　後述の引用部分の記載のとおり、今回の『報告書』は、第一号の政府重点プロジェクトに指定された政府共通プラットフォームにおける「クラウドサービス調達」に関して、２府省共同で組成されたプロジェクトチームが調達方法（契約内容を含む）を検討し、実際の調達手続を行った”事例紹介”として執筆されています。 なお、『報告書』中で複数回「AWS」への言及がありますが、その理由に関しましては、 ”＞「第二期政府共通プラットフォームの設計・開発等業務の請負」の調達においては、採用するクラウドサービス事業者を問わず、一般競争入札・総合評価落札方式により審査及び入札を実施し、平成31年3月に設計開発事業者が決定した。その際、Amazon Web Services（以下、「AWS」という。）を前提とした提案が採用されたことから、本プラットフォームについてAWS前提での設計開発を開始することとなった（p.2）” ──旨、『報告書』において説明いただいております。 ２万字近い『報告書』のなかでは、これまで政府調達・公共調達において、クラウドサービスを調達する際に直面しがちだった幾つかの典型的な課題に関し、先進的な整理が試みられており、いくつもの有益な提言が含まれています。 今回のブログでは、AWSジャパン・パブリックセクターより『報告書』の概要と、読み取られるべきインパクトについて解説します。 調達の背景と、事例紹介の『報告書』 今回の『報告書』の冒頭では、報告書作成の「背景」が記載されています（「１．背景等」）。クラウドに期待されるメリット、政府情報システムにとってのクラウドの重要性、そして調達・契約に至る検討の経緯が仔細に記載されており、少々長文となりますが重要な導入部分であるため、以下に引用します（着色強調は、ブログ筆者。他の引用箇所も同様）。 　”近年、急速に進化し発展したクラウドサービスは、正しい選択を行えば、コスト削減に加えて、情報システムの迅速な整備、柔軟なリソースの増減、自動化された運用による高度な信頼性、災害対策、テレワーク環境の実現等に寄与する可能性が大きく、政府情報システムにおいても、クラウドサービスを利用することで様々な課題が解決されることが期待される。 　このことから、現在、多方面にわたり、クラウドサービスの利用が増加してきている状況において、政府情報システムにおけるクラウドサービスの利用に係る基本方針[脚注1]が決定され、クラウド・バイ・デフォルトの原則を具体化し、各府省が、クラウドサービスを採用し、かつ、クラウドサービスを効果的に利用するための基本的な考え方が示されたところである。また、政府情報システムにおける予算要求から執行までの一元的なプロジェクト管理[脚注2]において、政府情報システムの一元的な管理体制の構築により、クラウドサービスの経費の合理化やサービスレベルの向上を実現するため、内閣官房IT総合戦略室が各府省を牽引してクラウド化を強力に推し進めるとともに、政府全体を代表してクラウドサービス事業者（以下「CSP」という。）と交渉し、政府が本来有する巨大な調達主体としてのバイイング・パワーを発揮してスケールメリットを確保することが不可欠とされたところである。 　本報告は、この一元的プロジェクト管理の第一号として政府重点プロジェクトに指定された政府共通プラットフォーム（以下「政府共通PF」という。）における第二期政府共通PFのクラウドサービス調達に関して、「政府共通プラットフォームの構築・活用推進及び政府におけるクラウドサービス利用検討」プロジェクトチームのクラウド利用戦略・企画担当（以下「PFPJ」という。）が調達方法（契約内容を含む）を検討し、総務省において実際の調達手続を行った事例として紹介するものである。 [脚注1] ｢政府情報システムにおけるクラウドサービスの利用に係る基本方針｣（2018年（平成30年）6月7日各府省情報化統括責任者（CIO）連絡会議決定） [脚注2] ｢政府情報システムの予算要求から執行の各段階における一元的なプロジェクト管理の強化について｣（令和元年6月4日デジタル・ガバメント閣僚会議） ❖「クラウド × 政府調達」の各論点に指針を提示 以下、AWSの理解による今回の『報告書』の要点・ハイライトをご紹介させていただきます。 ❖再掲：『報告書』の要点（『報告書』本体へのリンクはこちら）   要点①：クラウドサービスの「分離調達」を実施 『報告書』では、「＞クラウドサービスの調達では、システムの設計開発とクラウドサービスをセットで調達する場合やシステムの設計開発と分離して、クラウドサービスの提供をメインとして調達する場合などが考えられる」との２パターンを理論的に想定しています。　従来の公共調達においては、圧倒的に前者、つまりはシステムの設計開発とクラウドサービスとを”セット”で調達する「一括調達」が圧倒的に多く観察される調達形態でした。 しかしながら、今回の「＞政府共通PFにおいては、後者の分離したクラウドサービスの提供とこれに関連したアカウント管理のための役務提供を含む調達」の方式が選定され、調達が実施されています。（「システムの設計開発」を担う事業者等は、後続の別個の調達単位にて選定される立て付けとなっています。） 要点②：随意契約ではなく「一般競争契約」を選定 政府調達においては「競争性」をどのように担保するか、つまりは、一般競争契約を行うか／随意契約を行うか──の判断分岐が生じます。 今回の調達においては、「＞クラウドサービスの調達方法に関して、国内外様々なCSPが提供しており、現行の会計法令からすれば、原則、一般競争契約による調達を検討することが望まし」いものと整理され、調達が実施されました。 要点③：最低価格ではなく「総合評価」方式で調達 『報告書』において詳述されているとおり、政府調達においては「落札方式については、最低価格落札方式か総合評価落札方式かを検討する必要がある」とされています（＊登場する調達・会計法令関連の用語に関しても『報告書』本体に詳細な脚注が付されているので、ご参照ください）。 今回の調達では、「＞クラウドサービスの安全性やサービス・レベル・アグリーメント（以下「SLA」という。）等に関する要求要件を調達仕様に明記する場合や役務提供などの複合的な要素がある場合は、クラウドサービスの内容、種類等から総合的に判断する必要があるため、総合評価落札方式によることが適当」と整理をし、「最低価格落札方式」ではなく、「総合評価落札方式」を選定した旨、経緯が記載されています。 要点④：直接契約ではなく「間接契約」を締結 一般の商流を考えた場合、大きく分けて「＞クラウドサービスの契約方法については、CSPと直接契約する場合と中間事業者を介して、クラウドサービスの提供を受ける間接契約」の２パターンが想定されます（『報告書』では、これらの中間に位置するような契約形態に関しても言及があります点、ご留意ください）。 今回の『報告書』では、直接契約・間接契約のメリットをそれぞれ比較考慮したうえで、「＞支払業務について国内の中間事業者を活用することで、サービス毎の支払を取りまとめ、従来どおりの請求書をベースにして支払ができるため、直接契約に比べ支払業務を円滑に行えるメリットが発揮されるケースがある」と整理し、間接契約を締結するに至った経緯が説明されています。なお、将来的に「直接契約」を選択する場合の論点に関しても『報告書』では記載されており、CSPとしても直接・間接契約のどちらをもお選びいただける商流スキームを提供しております。 要点⑤：CSPと中間事業者に課す「サービス提供条件」を分離 従来の公共調達では、プライムとして提案する応札企業が、提供する役務に関して主たる責任を専一的に負う慣行、およびそれを求める契約書上の記載が続いてきました。しかし、One to Many、多くの顧客に均一なサービス利用条件を提供するビジネスモデルに基づくCSPにとって、個別の調達案件ごとにカスタムされた利用条件・契約条件を提示することは至難の業であり、政府調達と言えども「責任共有モデル」の境界を踏み越え、役務受託に伴う責任を調達者側はCSPに求めるべきではありませんし、CSP側もそうした責任の受任を確約することができません。では、公共調達において調達者側が求めたい”責任”と、CSP側が負い切れる”責任”とのギャップを、どのように埋めることができるでしょうか？今回の『報告書』では、要点④で述べた「中間事業者」に対して求める”責任”とのコンビネーションにおいて、このギャップを乗り越える工夫が行われ、応札者にとっての参入機会の拡大も図られた旨、記載されています。 ”当該クラウドサービスの利用に関する約款等に基づき、契約の相手方である中間事業者の負うべき責任の範囲等についてあらかじめ承諾を受けることを求める旨の追加的な条項を設定した。この条項は、本来クラウドサービスの利用者がCSPの約款等に基づき、利用に関する条件等を容認した上で利用するものであるが、国の契約においては、中間事業者が契約の相手方となる場合、委託先となる中間事業者が、すべての責任を負うことで、量的にも質的にも負いきれない筋違いの責任を求められる可能性があると判断し、結果として入札不調を招く恐れがあることからこのような条項を設定した。 　 　 例えば、国の契約の場合、一般的には損害賠償請求の上限など示されていないことが多いが、CSPが提供するサービスの約款等において一定の上限が決められている場合、中間事業者が、契約の相手先である国に対して、すべての責任を負うことになるため、中間事業者が負うクラウドサービス提供における責任範囲等に関して、契約段階で発注者側に承諾を得ることで調達に参加する中間事業者の不安を解消し、参入機会の拡大にも繋がるものと考えられる ”。 上記の発想を踏まえ、今回の『報告書』では、”＞CSPと中間事業者それぞれの役割分担に照らして責務や安全性の水準を「クラウドサービスの条件」及び「請負者のサービス提供条件」とに分割し調達仕様書上で求め”る工夫を行った旨、調達の経緯が説明されています。 要点⑥：従量課金を「単価契約」で実現 クラウドの特徴でありメリットの一つとして挙げられることの多い「従量課金」。従来の公共調達においては、固定額で契約を取り結ぶ「総価契約（固定価額での契約）」が支配的な契約類型であり、「従量課金」、ひいてはクラウドとの相性が悪いのでは？────との疑問が提起されてきました。 今回の『報告書』では、「＞国の契約においては、総額をもって契約する総価契約が原則であるが、特例として、契約上の数量が確定できないものについて、単価を契約の主目的とし、期間を定めてその供給を受けた実績数量を乗じて得た金額の代価を支払うことができる契約形態として、単価契約が認められている」との解釈をベースとし、クラウド採用に伴う“従量課金”への対応を、総価契約でも概算契約でもなく、「単価契約」で実現しています。具体的な入札時の応札価格の試算の手法等に関しては、『報告書』本体をぜひご覧ください。 要点⑦：利用サービスの種類を限定せず、随時の追加が可能と整理 政府予算からの支出が行われる以上、予算要求時点での精確な利用サービスの「種類」、その「ボリューム」が積算根拠として明記されることが、日本の公共調達では長らく求められてきました。『報告書』においても、上記の原則に関し、「＞単価契約も総価契約と同様に、歳出予算の制限を前提とすることから、単価のほか契約期間に対応したクラウドサービスの利用量を予定しておくことが必要であり、調達時には歳出予算の範囲内でクラウドサービスの契約ができるようにする必要がある」と、上記の原則を踏襲する整理を行っています。 他方で、今回の『報告書』ではもう一歩踏み込み、以下のような記載をもって、利用するクラウドサービスの追加が調達実施の時点以降も可能となる整理を行うことで、各利用機関にとって提供される柔軟性・迅速性が大幅に高まっています。（強調は、ブログ筆者） ”ただし、クラウドサービスの調達を単価契約とする場合は、クラウドサービスの種類を調達仕様書に明記できることやサービス毎に単価が、契約書の内訳として明記できることが重要となるため、契約期間中に単価が変動した場合や新たなサービスが追加される場合は、原則として、変更契約が必要となる。しかし、利用開始前に迅速に変更契約することは現実的には困難であり、サービスの継続的な提供に大きな影響が発生する。そのため、単価が公表されていることや利用量が確認できること等の条件を満たし、請求金額を検証できることを前提とするが、契約変更に係る事務負担軽減のため、例えば、契約書において、変更契約の条件に「単価変動やサービス追加の際は、契約時と同等の割引率や割増率を適用するものとする。」などと明記し、毎回変更契約せずに効率的に契約事務を行う工夫も考えられる。今般、政府共通PFでは、このような方法により、クラウドサービスの価格変動や追加サービスに柔軟に対応した契約方法として単価契約を採用した。” 要点⑧：複数年契約のメリットを認識しつつも「単年度契約」を実施 […]

はじめに AWS CloudFormationを介してAmazon Elastic Cloud Compute (EC2) インスタンスをデプロイした後には、ソフトウェアのインストール、またはオペレーティングシステムの設定が必要になることがほとんどです。多くのAWSのお客様はCloudFormationのヘルパースクリプトの一つである cfn-init （2012年2月から利用可能）を使用していると思います。しかし、それ以後もAWSは、お客様のフィードバックに応じて多くの新機能とサービスをリリースしてきました。そのうちの一つはAWS Systems Managerです。このブログ記事では、AWS CloudFormationを介してデプロイされたAmazon EC2インスタンスに対して、AWS Systems Manager State Managerを使用してインスタンスを設定する、よりシンプルで堅牢な方法を紹介します。

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

スポットインスタンススペシャリスト ソリューションアーキテクトの滝口です。2020年6月10日にオンラインで開催された「コンテナ × スポットインスタンス」 活用セミナーでは、200名を超えるご参加人数という大盛況のもと、AWSのソリューションアーキテクトによる技術解説と、各種コンテナ技術を最大限に活用してスポットインスタンスをご利用いただいている3社のお客様から、実際の事例についてお話いただきました。 本記事では、お客様のご登壇資料を含む当日資料のご紹介、また参加者の皆様からいただいた当日のQ&Aの一部をご紹介します。 当日アジェンダと資料 12:00～13:00　Amazon EC2 Auto Scaling によるスポットインスタンス活用講座 講師：滝口　開資（アマゾン ウェブ サービス ジャパン株式会社　ソリューション アーキテクト） 13:00～14:00　具体的実装に学ぶ、Amazon ECS × EC2 スポットインスタンス、Amazon EKS × EC2 スポットインスタンスによる低コスト & 高可用アーキテクチャ 講師：Hara Tori（アマゾン ウェブ サービス ジャパン株式会社　シニアデベロッパー アドボケイト） 14:00～14:30　AWS Batchによる大規模バッチ処理でのスポットインスタンス活用 講師：宮本 大輔（アマゾン ウェブ サービス ジャパン株式会社　ソリューション アーキテクト） Containers + EC2 Spot: AWS Batch による大規模バッチ処理でのスポットインスタンス活用 from Daisuke Miyamoto   14:30～15:00　ECS×スポットインスタンス活用の秘訣 講師：田中 […]

このブログは、認知科学の原則を使って AWS クラウドの学習効果を高める方法に関するシリーズ記事の第 3 回（最終回）です。 このシリーズの前回と前々回では、プレゼンテーションや講義からの情報を受動的にインプットすることばかりに依存しないということが、いかに重要であるかについてを取り上げました。長期的な学習効果を強化していくためにはインプットばかりでなく、その情報を能動的に 記憶から引き出す（または思い出す） よう、セルフテストに挑戦することが大切です。またこの考え方をふまえ、 時間間隔を空けた反復学習 を実践することで、学習をより効率的かつ効果的にする方法についてもご紹介しました。 どちらの戦略でも強調されているのは、学習プロセスにおいては記憶が重要な役割を果たすということです。ある分野についてのプロフェッショナルになるためには、その分野に関する主要な概念や事実といった強固な基礎を身につけることから始める必要があります。たとえば機械学習 (Machine Learnning: ML) について言えば、そもそも特徴量エンジニアリングとは何かを知らなければ、ML モデルで特徴量エンジニアリングを実践することは不可能です。 しかしこれまでに説明してきたことを鑑みると、キーとなる情報を記憶するためにいたずらに反復学習を行うことが正しいとは限りません。情報に対する理解を深めるのに役立つテクニックがいくつかあります。そのうちの 1 つはエラボレーションと呼ばれるものです。 エラボレーションとは エラボレーションとは、学習中の新しい情報を既存の知識と関連付けていくことで、新たにインプットしている情報に詳細を付け加えていくプロセスのことです。エラボレーションのプロセスでは What (何を) 学習しているかよりも、学習中のトピックの背後にある How (どのように) や Why (なぜ) により重きを置きます。ここでは簡単な例を使って、この概念をより具体的につかんでいきましょう。 エラボレーションの実践 機械学習を例にとった場合、おそらく最初に直面するハードルの 1 つは、この分野特有の用語や概念についての語彙を理解することでしょう。そのためまず Demystifying AI/ML/DL や What is Machine Learning? といったトレーニングを受講し、そこに出てくる用語や概念について時間差学習によって小刻みにセルフテストを行います。 機械学習のタイプの違いを理解しているかを確認するセルフテストの問題の 1 つとして、たとえば以下のような問題があったとします（正解は1）。 次のうち、教師あり学習が最も適しているのはどれか答えなさい 画像内の鳥を特定する 購買傾向に基づいてある集団をより小さな集団にグループ化する データセット内の特徴量の数を減らす クレジットカード取引データ内の異常を特定し、不正としてラベル付けする この問題やその他の同様の問題に正解することはさほど難しくありません。つつまり、回答にあたって教師あり学習ついて深い理解が必要な問題とは言えません。フォローアップの問題に挑戦することでエラボレーション、つまりこのトピックに関する詳細を付け加えていきます。こうすることで、より深い理解が得られます。 以下に示すのは、この状況またはその他の同様の状況でフォローアップエラボレーションとして活用できる問題の例です。 「画像内の鳥の特定」が、どのように教師あり学習の良い例であるか説明しなさい 他の選択肢が、教師あり学習に適していないのはなぜですか 正解の選択肢に加えて、教師あり学習の適切なユースケースを他に挙げなさい 正解の選択肢が、教師なし学習の例でないのはなぜですか   エラボレーションが脳に与えるインパクト エラボレーションの問題が学習に大きな効果をもたらすメカニズムは、脳が情報を最も効果的に保存および取り出す仕組みと関連しています。長期的な観点では、脳内にある他の情報と密接に接続された情報（大きく強固に張りめぐらされたクモの巣状のニューロンをイメージしてください）は、そうでない情報、つまり他の情報との関連付けが乏しく接続の弱い状態で保存された場合と比べて、はるかに簡単に記憶から取り出せるようになります。エラボレーションの問題に取り組み、学習中のトピックに詳細を付け加える訓練を実践すると、先に述べたニューロン同士の密接な結合の形成につながります。 では、この エラボレーション の原則を AWS クラウドの学習に活用するにはどうしたらよいでしょうか。以下にいくつかのアイデアを示します。 フォローアップ問題に挑戦する。反復学習 (小テストの問題に解答する、メモカードでセルフテストをする、難しい ハンズオンラボ […]

本記事は、EC2スポットインスタンススペシャリスト シニアソリューションアーキテクトのIsaac Vallhonratによる寄稿です。 Amazon EC2 スポットインスタンスを使うと、AWS クラウド内の使用されていない EC2 キャパシティーを用いて、オンデマンド料金に比べ最大 90% の割引価格でご利用いただけます。スポットインスタンスは、バッチジョブ、ビルド等のCI/CDパイプライン、負荷テスト、コンテナ化されたワークロード、ウェブアプリケーション、ビッグデータの分析クラスター、ハイパフォーマンスコンピューティング(HPC)用計算クラスターなど、複数のインスタンスタイプで柔軟に実行できる、耐障害性を備えたワークロードに最適です。このブログ投稿では、スポットインスタンスでウェブアプリケーションを実行するための方法とベストプラクティスについて説明し、これによりもたらされるスケールと費用節減の両方のメリットを得られるようにします。 スポットインスタンスには中断という特徴があります。この特徴を踏まえて、これから構築するウェブアプリケーションはステートレスかつ耐障害性があり、また疎結合されていることが望ましいです。また永続データの保持には Amazon ElastiCache, AmazonRDS, Amazon DynamoDB などの外部データストアを使用する必要があります。 スポットインスタンスのおさらい 2009 年に提供開始されたスポットインスタンスは、ここ最近のアップデートや関連サービスとの統合によって、お使いのワークロードで格段に活用しやすくなっています。ウェブアプリケーションを構築する方法の詳細に入る前に、スポットインスタンスの動作の概要のおさらいにお付き合いください。 まず、スポットインスタンスは EC2 の購入オプション、買い方のひとつです。 他の購入オプションである、オンデマンドインスタンス、リザーブドインスタンスやSavings Plansで起動した場合と比べて、EC2インスタンスとして提供するハードウェアに違いはありません。スポットインスタンスと他の購入オプションの違いはただ一つ、EC2 サービスが容量を必要とする場合には、2 分前に通知したのち、EC2サービスがスポットインスタンスを中断する、という動作です。つまり、大幅な割引価格で提供する代わりに、オンデマンドインスタンスやリザーブドインスタンスからの起動需要が高まってきたとき、スポットインスタンスの使用していたキャパシティをEC2サービスに戻し、需要に応える、というのがスポットインスタンスサービスの動作原理です。 スポットインスタンスは、スポットキャパシティプールと呼ばれる、いわば空きキャパシティがある限り起動できます。スポットキャパシティプール(スポットプール)とは、とは、インスタンスタイプ (m5.large など), オペレーティングシステム種別(Linuxなど), アベイラビリティーゾーン (us-east-1a など) が同一である、Amazon EC2 サービスが使用していない（空の） EC2 インスタンスの集合を指します。属性の異なるプール同士はそれぞれ独立したプールとして区別されます。例えば、us-east-1aゾーンのLinux向けm5.largeのスポットプールと、us-east-1bゾーンのLinux向けm5.largeのスポットプールは、独立した別のプールです。このそれぞれに空きがあるとき、スポットインスタンスを起動し、使用できます。 スポットインスタンスの料金は Amazon EC2 サービスによって設定され、各プールの EC2 インスタンスの需要と供給の長期的な傾向に基づき、徐々に調整されます。スポット料金は急激に変化することはなく、突然のスパイクや変動がないことが期待できます。 EC2 マネジメントコンソールと API の両方から、最大過去 3 か月間の価格履歴データを表示できます。次の図は、バージニア北部 (us-east-1) リージョンにおける m5.xlarge […]

このブログは、認知科学の原則を使って AWS クラウドの学習効果を高める方法に関するシリーズ記事の第 2 回です。 シリーズの第 1 回では、長期学習における反復学習の重要性について取り上げました。学習にあたっては数百のアマゾン ウェブ サービス (AWS) のサービスや機能に充分に留意しておく必要があります。すべてをより効果的に学習するには、ビデオを観たりドキュメントを読んだりして情報を受動的にインプットするだけでは不充分です。クイズやメモカードを使った学習、 ラボなどのハンズオンアクティビティを通したセルフテストを実行することで、学習中の情報を能動的に活用して、記憶から引き出す必要があります。 しかし多くの場合、多忙なスケジュールの中で継続的に反復学習を行っていくのは簡単ではありません。そこで有用なのが、時間差学習 (Spaced Practice) という概念です。 時間差学習とは、ある一定の期間中に徐々に時間間隔を広げて学習時間を分散させるというやり方です。     たとえば今週初めに視聴した Amazon S3 に関するビデオの内容に合わせて自身で作成したメモカードを確認するとします。メモカードでの学習にかかる総時間は約 60 分です。時間差学習ではこの時間を複数回に分散させることで、60 分間かけてすべてを 1 回で学習するよりもはるかに高い長期的学習効果を得ようとします。 この場合にカギとなるのは、覚えようとしている情報が記憶から消えてしまうギリギリのタイミングで復習を行うことです。このスイートスポットは人それぞれで異なります。 いずれにしても、学習中の情報が脳内の長期記憶に関連する部分に統合されるまでには時間が必要です。脳内からその情報を取り出すタイミングを遅らせる（または間隔を空ける）と、その情報は長期記憶を司るニューラルネットワークへより強く取り込まれます。間隔を空けずに行う反復学習は、この記憶の取り込みに要する時間を考慮しておらず、結果的に学習内容が短期記憶の範疇にとどまりやすくなります。   間隔を空けた反復学習は、長期記憶を格納する脳の領域に統合した後、記憶痕跡を活性化します。内側側頭葉は短期的な記憶を保存します。大脳新皮質は長期的な記憶を保存します。   Amazon S3 ビデオの例に戻りましょう。ビデオを見た直後に聞いたことをセルフテストすると、質問に回答する際には短期記憶の中から情報を引き出していることになります。情報を長期記憶に取り込むのに十分な時間がなかったためです。   ラーニングセッションまたはプレゼンテーションの直後に復習を行うと短期記憶が使用される。   時間差学習では、セルフテストを数時間あるいは数日の間隔を空けて行います。この時点で、情報を長期記憶に統合する時間があったことになります。テストへの回答は難しくなりますが、長期的には学習効果に大きな効果をもたらします。   ラーニングセッションまたはプレゼンテーションから間隔をおいて復習を行うと長期記憶が使用される。   では、AWS クラウドの学習に時間差学習を活用するにはどうしたらよいでしょうか。 以下にいくつかのアイデアを示します。 集中詰め込み式をやめ、学習を小さなチャンクに切り分ける。 1 週間休むことなく勉強すると短期的には有効に感じられるかもしれませんが、長期的には学習効果が低くなってしまいます。そのかわりに数百におよぶ AWS トレーニングを活用してください。トレーニングの多くはオンラインで受講できるショートトレーニングコースで、これを活用するとインプットからある程度の間隔 (数日間というよりは数週間程度の期間にわたって) をおいて簡単に学習内容を復習できます。 ラーニングパスを選択し、独自の間隔で学習スケジュールを立てる。 AWS のラーニングパスは一連のコースと試験で構成されており、このパスに従って学習を進めることで AWS […]

アマゾン ウェブ サービス (AWS) の 175 を超えるサービス群、数百にもおよぶ機能、クラウドコンピューティングの用語や概念という新しい語彙。これらは AWS の構築を学ぼうとする際に最初の壁となり立ちはだかります。この壁は多少険しいものに感じられるかもしれません。また、情報を受動的にインプットする学習法にばかり頼っていると、壁を乗り越えるのは難しくなってしまいます。 一方でこの障壁の高さを引き下げて、 AWS ビルダーとしての学習目標の達成を支援してくれるものもあります。人間にとって最も効果的な学習方法に関する、数十年にわたる研究から得られた認知科学的な知見、そして 数百に及ぶ AWS トレーニングポートフォリオ を活用できることです。 これからシリーズブログとして、数回にわたってこのテーマを扱っていきます。シリーズ内の各記事では、AWS のサービス、機能、および関連する概念をより効果的に学習し、結果としてより優れたビルダーになるために活用できる認知科学の原則に焦点を当てていきます。このシリーズでは次のテーマに基づいて概説していきます。 反復学習 時間差学習 エラボレーション   シリーズ第 1 弾となる今回は、反復学習についてご紹介しましょう。 反復学習の原則とは、学習者が以前に見たり聞いたりした情報を定期的に記憶から取り出して、その情報を使用して問題を解決したり質問に回答したりすることで、長期学習が強化されることと規定されています。 つまり反復学習とは、自分の記憶から情報を引き出す機会を学習者が自分自身に与えることです。 これは情報のインプットのみに重点を置いた、前述のアプローチとはまったく対照的です。学習した情報を保存するニューラルネットワークはその情報を繰り返し受動的に取り込むのではなく、自分の力で情報を思い出す（または記憶から取り出す）ことで強化されます。   通俗的な学習方法においては情報のインプットに重点を置く傾向がありますが、脳の学習方法に関する研究では、(反復: Retrieval により) 情報の取り出しを行うことが長期学習に不可欠であることがわかっています。   簡単な例を見てみましょう。2 つのグループがあります。どちらのグループも、Amazon S3 に関するプレゼンテーションに参加しました。それ以降 2 週間にわたり、1 つ目のグループ (反復学習グループ (Retrieval Group)：RG) のメンバーは、参加したプレゼンテーションで紹介された主な概念やトピックを思い出せるかどうかを試す一連のクイズに参加します。 一方で 2 つ目のグループ (非反復学習グループ (Non-Retrieval Group)：NRG) のメンバーは、プレゼンテーションで紹介され主な概念とトピックを繰り返す、一連のフォローアッププレゼンテーションに参加します。RG とは異なり学んだ情報に関するクイズやテストは受けません。 最初のプレゼンテーションから数週間さらには数か月後、RG は Amazon S3 に関連する記憶の保持に関して […]

ビジネスリーダーやテクノロジーリーダーと話すと、彼らは新しい製品やサービスを迅速に市場に投入することが必要だと話します。その一方で、彼らはセキュリティを継続的に確保する必要もあります。また同時に、時間とともに変化するビジネスニーズにワークロードを適応させながら、回復力のある環境を維持する必要があります。このブログシリーズでは、AWSのベストプラクティスを共有して、お客様がこれらのセキュリティ、スケーラビリティ、および適応性の要件を満たすようにAWS環境を計画するのを支援します。 私の目標は、クラウド環境の配備を管理するための設計上の考慮事項についてお客様をガイドすることです。このブログシリーズでは、今後、このガイダンスに沿った一般的なユースケースとパターンの実装を解説するブログを投稿していきます。