Amazon Web Services ブログ

Category: *Post Types

SAMLセッションタグを使用してフェデレーションユーザーのSession Managerアクセスを構成する

このブログ投稿では、フェデレーションユーザーに対して、AWS Systems Manager Session Managerへのアクセス権限を属性ベースのアクセスコントロール(ABAC=Attribute Based Access Control)にて設定する方法を示します。SAMLセッションタグを使用することで、外部IDシステムで定義された属性をAWS内のABACの判定の一部として使用できます。たとえば、AWS Identity and Access Management(IAM)ユーザーが所属する部門に基づいて、特定のマネージドインスタンスへのアクセスを許可することができます。フェデレーションユーザーが使用できる属性の詳細については、「新しい ID フェデレーション – AWS でアクセスコントロールに従業員属性を使用する」を参照してください。

Read More

AWS Systems Manager を使用したソフトウェアのパッチ適用

世界中の企業でクラウドコンピューティングの導入が急速に増加しており、クラウドジャーニー(クラウド活用を進める過程)の中で、さまざまな移行パターンが選ばれています。モノリシックなレガシーアプリケーションをそのまま使用してクラウドに移行することは「リフト・アンド・シフト」とも呼ばれるアプローチであり、クラウド移行の有力な手法の1つです。一方で、お客様が移行パターンについての知識を深めるにつれ、クラウドネイティブツールを最大限に活用できるようにリフト・アンド・シフト方式を最適化する必要があります。

Read More

AWS Summit Online ~ 金融系セッションの見どころのご紹介

皆さんこんにちは、アマゾン ウェブ サービス ジャパンで金融事業開発を担当する飯田です。今回は、9月8日からスタートする AWS Summit Online の金融セッションの見どころについてご紹介します。   AWS Summit Online について AWS Summit Onlineは、今年5月に開催を予定していたAWS Summit Tokyo/Osakaのコンテンツをオンライン化してフルスケールでお届けするものです。9月8日(火)~9月30日(水)の開催期間中、基調講演、お客様事例、AWSセッション、パートナーセッションなど150を超えるコンテンツをオンデマンドで視聴頂けます。また、8日と9日には基調講演など一部ライブ配信を行うものもあります。金融関連のセッションも全てオンデマンドで開催期間中いつでも視聴頂ける予定です。   金融領域におけるAWSの活用動向 金融関連のセッションのご紹介に入る前に、日本の金融領域におけるクラウド活用の状況を振り返っておきたいと思います。AWSは2011年に東京リージョンを開設しました。金融領域では、当初フィンテック企業から活用が始まります。金融機関では、2013年より、ソニー銀行などを皮切りに徐々に利用が広がります。そして、2017年には、三菱UFJフィナンシャル・グループがAWS活用を公表し、AWS Summitにもご登壇頂きました。以降、金融の様々なマーケットセグメントにおいてクラウド活用の検討が本格化し、AWSは、銀行、証券、保険、決済などの領域で活用が広がっています。ユースケースも、顧客口座情報を蓄積するデータレイク、大規模なリスク計算、オンラインバンキングやコールセンターなどの顧客チャネル、モバイル決済サービスの基盤、機械学習を活用した融資審査や不正検知など、ミッション・クリティカルな業務領域へと広がりました。これらのユースケースは既に構築され、活用され、ビジネスへのインパクトを出しています。そして、先行する金融機関では、勘定系などの基幹システムにおけるAWS利用の検討を進めています。AWS Summit の登壇金融機関数も、2017年はわずか4社に過ぎませんでしたが、2020年はフィンテック企業も含めると21社と大幅に拡大しました。   金融セッションの見どころ 今年の金融関連のセッションはメガバンクからフィンテックまで全21社が18のセッションに登壇します。さて、これだけ多くの金融機関がセッションを持つ中でどういった点に着目すれば良いでしょうか。各セッションの詳細については、AWS Summit Onlineのサイトでご覧になって頂ければと思いますが、私からは全体の傾向としての見どころをお伝えできればと思います。 まず第一に、21社の金融関連のセッションのうち、11社については、役員を始めとする経営層の方にご登壇頂きます。SOMPOホールディングス、三井住友信託銀行、日本取引所グループを始め、多くのセッションで経営層の方が自らクラウドの活用戦略を語ります。これは、クラウドの活用が個別プロジェクトのインフラ選定の話ではなく、全社のDX戦略に関わる経営課題として認識されるようになってきたことの表われと言えるでしょう。第二に、金融のクリティカルなユースケースに関するセッションが多いことです。例えば日本カードネットワーク、PayPay、楽天のセッションでは、決済サービス、QUICKはマーケットデータの配信、ソニー銀行は勘定系におけるAWS活用をテーマとしています。これらが構想としてではなく、実装されたものとして、あるいは具体的なアーキテクチャーと共に語られる点において、クラウドの活用のミッション・クリティカル領域への広がりを実感頂けると思います。第三に新規ビジネスモデルの構築や業務改革におけるクラウドの活用です。住信SBIネット銀行のNEOBANK構想、東海東京証券のプラットフォーム戦略では、クラウドを活用することで今までの金融サービスのあり様を変えていく試みが議論されます。また、三菱UFJフィナンシャル・グループは、AI/MLの活用による業務改革の実例をご紹介します。第四にクラウド人材の育成です。多くの金融機関がクラウドをDX戦略の中核に位置付ける中、デジタル人材、クラウド人材の育成は喫緊の課題です。クレディセゾン、東京海上日動火災保険、みずほフィナンシャルグループによるリレーセッションでは、各社各様のデジタル人材育成の取組みが紹介されます。また、ふくおかフィナンシャルグループのセッションは、データレイクをメインのテーマとしていますが、人材育成の観点でも示唆に富むお話となっています。上記以外にも、フィンテック企業からFinatext、マネーフォワード、ネットプロテクションズ、ZEROBILL BANK、ビットバンクに登壇を頂く予定です。   最後に AWS Summit Online において、AWSの活用事例を共有頂いた金融機関、及びご登壇者の皆様に改めて御礼申し上げます。これらのセッションが視聴された皆様のデジタルトランスフォーメーションに貢献できることを願っております。セッションは9月8日~30日までの開催期間中、いつでもオンデマンドで視聴頂けますので、是非ご登録頂き、金融におけるクラウド活用の最新動向を実感頂けたらと思います。セッションについては、サイト内で検索頂くか、セッションIDや金融機関名に基づいて見つけて頂くことが可能です。   下記は金融関連のトピックにてご登壇頂きました企業一覧とセッションIDです(五十音順)。   QUICK(CUS-24, CUS79) クレディセゾン(CUS-26) 住信SBIネット銀行(CUS-81) ZEROBILL BANK(CUS-92) ソニー銀行(CUS-51) SOMPOホールディングス(CUS-21) 東海東京フィナンシャル・ホールディングス(CUS-23) 東京海上日動火災保険(CUS-26) 日本カードネットワーク(CUS-24) 日本取引所グループ(CUS-25) ネットプロテクションズ(CUS-86) Finatextホールディングス(CUS-05) ビットバンク(CUS-93) […]

Read More

『行政&情報システム』”行政におけるパブリック・クラウド” 特集号にAWSからの寄稿が掲載されました

AWSジャパン・パブリックセクターより、寄稿記事の掲載のお知らせです。隔月で刊行されている雑誌『行政&情報システム』の“「行政におけるパブリック・クラウド」特集号”にAWSパブリック・セクターメンバーが執筆した記事が掲載されています。 記事の全文をお読みいただくには、発行者である「行政情報システム研究所」宛にバックナンバーの購入をお申し込みをいただくか、もしくは、こちらのリンクより、150円で記事単位でのダウンロードが可能です。 今回のAWSメンバーからの寄稿記事は 「公共機関で実践されるクラウドセキュリティのベストプラクティス」と題されています。 本文中でも引用されている数字として、富士キメラ総研によると、2019年度の公共クラウド市場は前年比22.0%増の925億円となり、2023年度には2,368億円に 達すると予測されています。 今回の寄稿の問題意識は、次のようなものです。「>行政情報システムのクラウド化を検討する上でもっとも大きな検討事項となるもの、それはセキュリティです。行政機関の立場から見れば、クラウドは外部のサービスとして位置付けられ、利用そのものに心理的なハードルが存在しました。また、これまでの技術文書やガイドラインがオンプレミスを前提として記述されているため、クラウドを利用する時に考慮すべき事項が明確化されていませんでした」──こうした問題意識のもと、今回の寄稿では、「クラウドを活かしたセキュリティ向上のためのペストプラクティスを紹介」しています。 以下に、掲載記事の概要・要点を幾つかご紹介します。 寄稿の4つの要点:クラウドで「システム」と「データ」を守り、「第三者評価」を活用し「サービス」を継続 今回の寄稿は、「①クラウドでシステムを守る」「②クラウドでデータを守る」「③クラウドでサービスを継続する」「④クラウドで第三者評価を活用する」──の4つの章立てで構成されています。 ①クラウドでシステムを守る ──行政情報システム全体のセキュリティを確保するためには、クラウド環境のセキュリティに留まらず、オンプレスミスからクラウドまでの流通経路を考慮し、システム全体でセキュリティを高める必要があります。そのための手法として、クラウドへの接続には、インターネットを利用した通信に加え、1)VPN(Virtual Private Network)や専用線を利用して閉域ネットワーク環境を構築する、2)他のユーザからのアクセスを許容しないプライベートなネットワーク空間を構築する──等の手法を紹介しています。 ②クラウドでデータを守る ──システム全体のセキュリティ確保をユーザとクラウド事業者とで責任分担し、各々の役割を相互に共有する実装モデルである、『責任共有モデル』 という考え方を紹介しています。併せて、1)クラウド事業者が提供するストレージサービスでは、ファイルを配置するだけで自動的に複数の拠点で冗長化され、耐久性が向上すること、2)また、そのファイルに対して誰にどのようなアクセス権限を付与するかなどのきめ細かな権限設定を行うことができること、3)機密性の高いデータに関しては暗号化機能を提供できること──などが、説明されています。 ③クラウドでサービスを継続する ──システム全体の可用性を高め、万が一の障害時においても事業を継続するためには、できる限り単一障害点を作らないことがベストプラクティスです。1)AWSはユーザからの課題や要望に対して不断のサービス改善を実施しており、それらに基づいて『Well-Architectedフレームワーク』 と呼ばれるシステム設計上のベストプラクティスを提供していること、2)AWSでは、データセンター、仮想インスタンスのレベルにおいて冗長構成をとることが可能であること、3)AWSが提供するサービスの多くはインフラストラクチャー管理、セキュリティコントロール、コンプライアンスコントロール、コストの最適化などをサービスとして提供する『マネージドサービス』の形態をとっていること──などが、説明されています。 ④クラウドで第三者評価を活用する ──クラウドを利用するにあたり、最後の課題となるのが“漠然とした心理的なハードル”です。「クラウドはユーザの物理的な管理下にないため説明責任が果たせない」との論調が存在します。こうした心理的なハードルを払拭し、ユーザがクラウドを利用する際の説明責任を果たす方法として、第三者評価の活用があります。「政府情報システムにおけるクラウドサービスの利用に係る基本方針」では、「クラウドサービスの情報セキュリティ機能の実態を利用者が個別に詳細に調査することは困難」としており、「パブリック・クラウドに関しては、第三者による認証や各クラウドサービスの提供している監査報告書を利用することが重要である」と示しています。併せて、日本では「政府情報システムのためのセキュリティ評価制度(ISMAP)」が2020年に制定され、施行されました。 ISMAPの2つのメリットに関し、1)現場の担当官によるクラウド事業者に対する評価を本制度に委ねることができる、2)クラウドを前提としたシステム調達の仕様策定において、「ISMAPクラウドサービスリストに掲載されているクラウドサービスの中から選択することを原則とする」と表記することで、安全で信頼できるクラウド事業者の選定が実現できる──旨、説明しています。 ❖4つのコラムにより、「閉域接続」「データ廃棄」「マイナンバー等の特定個人情報の扱い」「データセンターの冗長化」を例示 また、今回の寄稿では、具体的な例示を伴った解説を心がけるために、以下、4つの「トピック」をコラム形式で盛り込んでいます。 【トピック#1】 総合行政ネットワーク(LGWAN)を介したクラウドへの閉域接続: 北九州市と日立製作所による、行政事務のデジタル化やデータ利活用、クラウド利活用を目的とし、日立製作所が提供している「地域IoT連携クラウドサービス」を活用して、LGWANから専用線で閉域接続されたバーチャルプライベートクラウド上に構築した行政文書目録検索や通知文書閲覧システムの実証実験に関し、紹介しています。 【トピック#2】 クラウド上での安全なデータの廃棄:昨今の情報漏洩に端を発したデータ廃棄についても、オンプレミスとクラウドではアプローチが異なることを説明しています。統制の一例として、「ユーザはストレージ領域をデフォルトで暗号化」「データを削除する際は、併せて当該領域の暗号鍵を削除」等の手法を紹介し、「クラウドではデータへのガバナンスがユーザに取り戻され、第三者が適切に廃棄したかという証明問題からそもそも解放される」旨、例解しています。 【トピック#3】 クラウド上での個人情報や特定個人情報の保護: 社会保険診療報酬支払基金が、社会保障・税番号制度の導入に伴い、「医療保険者等向け中間サーバー等における資格履歴管理、情報提供ネットワークシステムを通じた情報照会・提供及び本人確認に関する事務」においてマイナンバー等の特定個人情報を扱うことから、実際のシステム構築に際し、「アプリケーションやデータを統制するユーザの責任と、インフラストラクチャーを統制するクラウド事業者の責任を区別して整理」した事例に関し、紹介しています。 【トピック#4】 クラウドを活用したデータセンターの冗長化: 政府CIO補佐官等ディスカッションペーパーによる「パブリック・クラウドを利用した情報システムにおける計画・構築時の基本的な考え方」では、大規模災害対策について、オンプレミスでの「データセンターの2重化、データバックアップの遠隔地保管等を予算の制約内で検討」との考え方に対し、クラウド利用時の考え方として「広域の大規模災害発生時においてもサービスを継続できるよう、マルチアベイラビリティゾーン、マルチリージョンを活用した設計とする(多大な追加コストは不要)」との対比を示しています。   以上の章立てとコラムの構成に基づき、寄稿の最終段落は “クラウドを活かしたセキュリティ向上は制度面、実装面、技術面においても、十分な検討を経て成熟期を迎えています。「クラウドこそがセキュリティを高めるための解決策である」と言われる日も遠くはないと私たちは考えています”──と、結ばれています。 ぜひご一読をいただければ嬉しいです。   ❖Read More : AWS Blog: AWSも参加した調査研究として(社)行政情報システム研から「パブリッククラウド活用」の報告書が発表されました ── 同月号の『行政&情報システム』で特集されている「調査報告書」に関して、AWSからも概要を紹介しています。 日本の公共部門の皆様へのご案内 今後ともAWS 公共部門ブログ(英語版)で AWS の最新ニュース・公共事例をフォローいただき、併せまして、「農水省DX室」「気象庁の衛星ひまわり8号のデータセット」や「情報処理推進機構(IPA)」など日本の公共機関との取り組みを紹介したAWSジャパン・パブリックセクターチームの過去の投稿に関しても、ぜひご覧いただければ幸いです。 * * * * このブログは、アマゾンウェブサービスジャパン株式会社 パブリックセクター 統括本部長補佐(公共調達渉外担当)の小木郁夫が執筆しました。 Tags: Government /政府、Public-Sector / 公共部門

Read More
Webinar Title

【開催報告】AWS 環境上での医療情報ガイドライン対応の最新動向 ウェビナー

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

Read More

AWS セキュリティドキュメントに150 以上の AWS サービスが追加されました

2019 年 6 月の AWS セキュリティブログで説明した、 AWSドキュメント の取り組みについての最新情報をお伝えします。 AWS セキュリティドキュメントに 150 以上のAWS サービスが追加されたことをお知らせできることを嬉しく思います。 AWS セキュリティドキュメントに馴染みがない方のためにお伝えすると、これは既存のサービスドキュメントの中にあるセキュリティコンテンツを簡単に見つけることができるように開発されたもので、AWS サービスのセキュリティ機能を確認する際に複数のソースを参照する手間を省くものです。これは、AWS 責任共有モデルで説明されている、クラウド “の” セキュリティ、クラウド “における”セキュリティに関する情報を含む、AWS クラウド導入フレームワーク( Cloud Adoption Framework – CAF)のセキュリティに沿った内容となっています。各章では、各 AWS サービスに適用される CAF の中から、以下のセキュリティトピックを取り上げています。

Read More
Amplify Meetup #01 開催!

【全資料まとめ&開催報告】Amplify Meetup #01

みなさんこんにちは!アマゾンウェブサービスジャパン株式会社 ソリューションアーキテクトの木村公哉(@kimyan_udon2)です。梅雨が明けて、気づけばお盆も明けた今日この頃ですが、皆様いかがお過ごしでしょうか? 7月31日に「Amplify Meetup #01」を開催しました。「Amplify Meetup」はAWS AmplifyのユーザーとAWS Amplifyに興味のあるエンジニアのみなさんでLTなどを通して盛り上がるコミュニティーイベントです。今回初めて開催しましたので、開催報告と合わせて「Amplify Meetupとは?」という点についてもご紹介いたします。

Read More

内閣官房・総務省より「第二期政府共通プラットフォームにおけるクラウドサービス調達とその契約に係る報告書」が発表されました

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

Read More

AWS AppConfigとAWS CodePipelineの統合による機能リリースの自動化

昨年、AWS AppConfigをリリースしました。これはアプリケーション設定の作成、管理及び迅速なデプロイを行う、AWS Systems Managerの新機能です。AppConfigを使用すると、デプロイメントを行う前にアプリケーション設定を検証でき、制御及び監視可能な方法で設定をデプロイできます。 AWS AppConfigを使用すると、アプリケーションコードのデプロイメントとは独立して、設定の変更をデプロイ可能です。つまり、アプリケーション設定を更新しても、アプリケーションの再起動やサービスの停止を行う必要がありません。AWS AppConfigを使用すれば、アプリケーションは更新した設定をすぐに使用できます。具体的には、AWS AppConfig API、AWS CLIやAWS SDKを使用することで、更新した設定を取得することができます。 ローンチ以来、お客様はさまざまなユースケースにAWS AppConfigを採用しており、なかでもコードのデプロイメントとは独立して新機能をリリースする機能がトップユースケースの1つでした。アプリケーション設定のデプロイメントはコードのデプロイメントより高速です。なぜならコンフィグレーションファイルは、ビルドステージを必要とせず、アプリケーションを停止すること無く実行中にデプロイすることができるためです。 機能リリースにあたって、バックエンドサービスの設定とフロントエンドの設定を正しい順序で行う必要があります。そのためには、しばしば複数のチームや手作業を調停する必要があります。こういった手作業によるデプロイメントは、カスタマーエクスペリエンスに影響を与える作業遅延を引き起こす可能性があります。 複数の環境、アプリケーションやリージョンに、アプリケーション設定をデプロイするという手動タスクをシンプルにするために、我々はAWS AppConfigとAWS CodePipelineの統合を発表しました。このローンチは、お客様が AWSの数千のチームが使用するベストプラクティスを選択することを可能にします。それは、コード変更を機能リリースから容易に分離し、安全且つ効率的な方法でこれらの機能リリースを自動化するというものです。

Read More