この記事は、2026 年 9 月 1 日に Ania Braszkiewicz、Yi Zhang によって執筆された「 Introducing AWS Certified AI Business Strategist: Built for the people who scale AI 」を翻訳したものです。 すべての AI の取り組みには、2 種類の仕事が同時に発生します。1 つは「構築」です。モデル、インフラストラクチャ、コードがこれにあたります。もう 1 つは「意思決定」です。どの投資に資金を充てるか、成功をどう測定するか、どのようなガバナンスを整備するか、いつスケールし、いつ止めるかを決めることです。AWS は長年にわたり技術的なビルダーを認定してきました。そして 9 月 1 日より、ビルダーと共に AI 導入を推進する方向けに特化した認定を開始します。 AWS Certified AI Business Strategist は、組織内で AI の取り組みを評価し、推進し、スケールさせるプロフェッショナルのための新しい認定です。対象となるのは、チーム全体で導入を進める事業部門のリーダー、顧客に AI の価値を伝える営業プロフェッショナル、実験段階から本番稼働まで顧客の戦略を導くコンサルタント、AI 投資をビジネス成果に結びつけるプログラムマネージャーです。この試験は、企業を舞台にしたシナリオを通じて、汎用的なビジネス判断力を検証します。AWS のサービスは実践的な文脈として登場しますが、それ自体が試験の対象ではありません。この認定が検証するフレームワークは、組織や業界を越えて適用可能です。 その点が、単一プロバイダーの製品、プラットフォーム、技術スタックに特化した知識を問う認定資格とは異なります。また、履修に数か月、数千ドルを要するアカデミックなプログラムや、より低コストでも数週間を要するオンラインプログラムとも異なります。これは厳格な試験監督付きの試験であり、業界で認知された資格として戦略的スキルを検証し、すぐに履歴書に記載できます。 あなたはすでに AI 導入を推進しています。そして今、それを認めてくれる資格があります。 この認定を作った理由 いまだに多くの組織が、AI を単なる技術的な取り組みとして捉えています。しかし AI は戦略的なビジネスの取り組みでもあり、AI をスケールさせるには、構築とは異なるスキルセットが必要です。 私たちは業界を問わず、お客様から同じ声を聞いてきました。中堅のプロフェッショナルやシニアの現場担当者が AI の成果に責任を負っているにもかかわらず、それをリードするスキルを持っていることを証明できずにいました。チームは、本質的にはビジネス価値に関する意思決定を技術スタッフに頼っていました。どのユースケースを優先するか、説得力のあるビジネスケースをどう構築するか、どのようなガバナンスを整備するか、パイロット段階の先へどうスケールさせるか、といった判断です。これらは判断を要する事柄ですが、組織にはその判断をうまく下せる人材を見極めたり育成したりする手段がありませんでした。 私たちはまた、営業、コンサルティング、オペレーション、ビジネスリーダーの各職種のプロフェッショナルからも声を聞きました。彼らは、技術的な実装ではなく戦略的な意思決定に即した認定資格を求めていました。中には、すでに AWS Certified AI Practitioner (AIF) を取得し、そこで得られた技術的な基礎を高く評価している方もいました。しかし、彼らが行っている日々の業務には異なる種類の裏付けが必要でした。AWS Certified AI Practitioner (AIF) は技術的な理解を検証します。AWS Certified AI Business Strategist (AIB) はビジネス判断力を検証します。トランスフォーメーションには、その両方が必要です。 そこで私たちはこの認定を作りました。この試験は、AI の取り組みに携わる、あるいはその周辺で働く経験を 6 か月以上持つプロフェッショナル向けに設計されています。コーディング、AWS の実装経験、他の AWS 認定は必要ありません。 この認定があなたにとって重要な理由 あなたも自分の組織で目にしたことがあるかもしれません。AI ツールは利用でき、技術者もそろっているのに、「取り組みがパイロットから抜け出せない停滞状態にはまり込んでいる」という状況です。最近の Harvard Business Review の調査によると、AI 導入による運用上の負担は中間管理職が負っているということが分かりました。彼らは、正式な支援や全社的なガイダンスなしに、AI の使用基準、品質、ガバナンスに関する重要な決定を単独で行っています ( HBR, 2026 )。このパターンは至るところで起きています。現在、88% の組織が少なくとも 1 つの業務機能で AI を利用しています ( McKinsey, 2025 )。それにもかかわらず、その取り組みが有意義なビジネス成果を生んでいると答えたのはわずか 19% でした ( ServiceNow/Oxford Economics, 2025 )。 その理由は構造的なものです。ほとんどの組織は、業務そのものを再設計することなく、既存のワークフローに AI を組み込んでいます。パイロットの停滞から抜け出すには、どのツールを使うべきかだけでなく、仕事の進め方そのものを再考できる専門家が必要です。 そのギャップを埋められるプロフェッショナルこそ、組織が最も必要とする人材です。どのユースケースが投資に値するかを評価し、現実的な期待値を設定するビジネスケースを構築し、規模拡大に必要な変革を管理できる人々です。雇用主も、それに応じた報酬を支払っています。 AI によって人間の専門知識の必要性が高まる職種では、AI によって非専門家にとって作業が容易になる職種と比べて、賃金の伸びが 42% 高くなっています ( PwC, 2026 Global AI Jobs Barometer )。AI 資格を持っている労働者は、そうでない同業者よりも 3.5 倍速く昇進しています ( Randstad, 2026 年 5 月 )。また、学位以外の資格は、キャリア中盤での停滞リスクを平均 29% 低減します ( NYU/Burning Glass Institute, 2026 )。 これらのスキルを検証する手段がなければ、プロフェッショナルは、すでに十分な実力があるにも関わらず AI リーダーシップの役割から見落とされてしまうリスクがあります。すでに AWS の技術認定を取得している場合、この資格はそれを補完します。何を、なぜ構築するのかを形づくる戦略的なレイヤーを検証するからです。技術的な実装と AI ビジネス戦略の両方で認定されたプロフェッショナルが組織にいれば、チームは機会を評価するための共通のフレームワークを共有でき、意思決定をより迅速に進めることができます。 試験で問われる内容 この試験は、現実のビジネス状況に即したシナリオベースの設問を通じて、4 つの領域を対象とします。 AI の基礎とリテラシー は、ビジネスの文脈における AI の概念、能力、制限についての実践的な理解度を問います。提案された AI ソリューションが課題に適しているかどうかを評価し、技術チームに適切な質問を投げかけるために必要な知識です。 AI 戦略とビジネス価値の創造 は出題比率が最も高い領域です。ユースケースを評価し、ビジネスケースを構築し、ROI を定量化し、AI が適切なソリューションではないケースを見極める能力を評価します。あるベンダーが 200 万ドルの AI 導入を提案してきたとします。その投資が妥当なのか、時期尚早なのか、あるいは重要な成功要因を欠いているのかを、あなたは評価できるでしょうか? AI ガバナンスと責任ある AI リーダーシップ は、ガバナンス構造を確立し、企業の AI リスクを管理し、規制要件に対応する能力を評価します。ガバナンスを省いた組織が速く進めるわけではありません。コンプライアンス、法務、レピュテーションに関する懸念が後から追いついたときに停滞します。 ビジネス準備状況、リーダーシップ、AI トランスフォーメーション は、組織の準備状況を評価し、変革を管理し、取り組みをパイロットから企業規模の展開へと進める能力を評価します。 準備の方法 AWS Skill Builder には、必要なものがすべてそろっています。この分野が初めての場合は、 AI Business Strategist ロール向けのデジタルコース から始めてください。このコースは 13 のモジュールにわたり、4 つの試験領域に直接対応しています。デジタルコースを修了したら、 認定試験の準備プラン に従って残りのギャップを特定し、 Practice Question Set で練習しましょう。すでに経験がある場合は、試験準備プランから始めてください。 ※ 訳者注: 2026 年 9 月 4 日現在、デジタルコースは英語版のみでの提供となります。 上記のコースを選択される前に、Skill Builder の上部メニュー内「アカウント」→「プロフィール」内の「AWS Training and Certification の設定」より「言語」を英語に変更してからご確認ください。 はじめましょう ベータ試験の登録は 2026 年 9 月 1 日に開始し、試験の提供は 9 月 29 日から始まります。ベータ試験は英語と日本語で受験でき、一般提供の開始時にはさらに多くの言語が利用可能になります。2027 年 2 月 15 日までにこの認定を取得した受験者には、通常の認定資格バッジに加えてアーリーアドプターバッジが付与されます。 次にあなたの組織が「これに投資すべきか ?」あるいは「うまくいっているものをどうスケールさせるか ?」と問うとき、AI の段階的な成果を大きな変革へと転換できる人材になりましょう。それを裏付ける認定資格とともに。 ベータ試験への登録はこちら → 翻訳は Technical Instructor の 室橋 弘和 が担当しました。

こんにちは。タイミーでプロダクトエンジニアをしている津守です。 普段は、エンジニアとして機能の開発をメインの仕事としていますが、最近は営業チームの商談に同行する機会が増えてきました。そこで突きつけられたのが、タイトルの問いです。 自分が作った機能を、自分で売れるか。 機能は作れる。仕様も説明できる。でも、顧客を前にして「これはあなたの課題をこう解決します」と語り、納得してもらえるか。やってみると想像以上に難しく、同時に開発者として得るものが大きい体験でした。 この記事では、商談同行を重ねる中で見えてきたことと、そこから営業メンバーとの間に育っていったコミュニケーションパスについてまとめます。9月5日開催の Product Engineering Conference 2026 （以下、PdEConf 2026）が掲げる「職能の壁を越え、プロダクト価値を最大化させる」というテーマの、ひとつの実践記録として読んでもらえると嬉しいです。 なぜ「自分で売ってみよう」と思ったのか きっかけは、チームで開発した機能がなかなか顧客に活用されない、という課題感でした。 タイミーでは、営業が顧客にしっかり伴走しながらプロダクト導入後もサポートするコンサルティングに近い構造です。機能案内なども都度丁寧に行う体制ではありますが、新しく作った機能の導入は思うように広がりませんでした。チームとしては必要とされる機能を開発している認識でしたが、それがなかなか使われない。なぜ使われないのかという疑問に加え、使われなければ当初予定していた検証も進みません。 どうすれば営業メンバーの理解を得て、機能を届けられるのか。スプリントレビューの運用を見直して情報伝達を改善し、営業行動ログから提案状況も追いました。しかし、解消には至りませんでした。 チーム内に閉じた取り組みでは答えが出ないので、まずは「自分が作った機能は本当に顧客に売れるのか」を現場で感じ取りたい。そう考えて営業メンバーに相談し、商談への同行を始めました。 売ろうとすると、機能の強みと弱みがわかる 実際に商談の場で機能を説明して真っ先に気づいたのは、価値を感じてもらえる点と解決できていない点が同時に見えることでした。概要の説明だけで納得してもらえる部分がある一方で、答えに詰まる指摘や、対応しきれていない側面が容赦なく浮き彫りになります。 素朴な質問に十分答えきれず「将来的には対応していきます」としか言えない——。 答えに詰まる箇所は、そのまま営業メンバーが提案しづらい箇所です。 逆に、その場で納得してもらえた説明の切り口は、そのまま営業が使える強みになります。 ユーザーインタビューと違い、商談では自分が価値を証明する側に立ち、顧客も「使うか、使わないか」を判断します。そのため、「使うけれど、ここは不満」という改善要望と、「ここが解決されなければ使わない」という利用の障壁を切り分けられます。既存の運用や他の選択肢との比較も含め、機能がまだ使われていない理由を直接受け取れるのが、商談ならではです。 ユーザーインタビューと商談同行の違い ただし、注意しなければいけない点もあります。商談で聞いた一社・一人の意見は実在する課題ですが、優先すべき課題かは別問題です。 セールス主導開発の滑りやすい坂道 が指摘するように、商談同行は使い方を誤れば、一社の要望を過度に優先した開発の入り口にもなります。複数のユーザーに聞いて「重なる課題感」に手をつけながら、個別事例には深く踏み込む。この具体と抽象の行き来と、 定常的に顧客接点を持ち続ける ことが必要です。 「自分が売れた」で終わらせない ― プロダクトを売れる形で提供する 自分が同行した商談での提案がきっかけで売上に貢献できると、素直に嬉しいです。「自分で作った機能を自分で売れるんだ」という手応えは、ものづくりをする人間にとって強烈な体験ではないでしょうか。ただ、この体験は感動が大きい分、意識しないと「自分で売ること」自体を目指してしまい本来の役割を見失ってしまいます。 エンジニアが商談に同行する意義は、自分が売れるようになることではないと考えています。自分の中で売り方の検証を回し、そこでの学びをプロダクト開発に反映することが本筋です。そのうえで、刺さった提案の仕方や文脈を型化し、営業資料のひな形として渡していく。つまり、 プロダクトを「売れる形」にして提供すること です。改善した機能と、それを説明するための型をセットで渡せば、組織全体で価値を届ける力になります。 営業とともに開発する体制を築く 商談同行は、一度きりで終わらせず継続することで真価を発揮します。同行を重ね、商談後にはその場で営業メンバーと振り返り、機能の強みと弱みを一緒に整理して目線を揃えていく。これを繰り返すことで、営業メンバーとの間に「機能を届ける」ためのコミュニケーションパスができていきました。 一番大きな変化は、商談に関する相談をされるようになったことです。機能説明の商談を控えたメンバーから「この機能はどう勧めるのがいいか」と事前に相談が入る。商談を終えたメンバーから「この質問に上手く答えられなかった」と持ち込まれる。以前はプロダクトへのフィードバックの機会がほぼスプリントレビューだけでしたが、Slack で非同期にこうしたやり取りが行われるようになりました。これらは営業の困りごとであると同時に、機能に対するフィードバックそのものです。相談で出た論点は開発に反映されたり、営業資料のひな形に反映し共有知として残したりしています。 変化は開発チーム側にも起きました。チーム内で商談の内容を共有していくうちに、機能をどう売るかを主題として会話する機会が増え、メンバーの関心が自然と営業の動きへ向いていきました。営業メンバーの日報に開発メンバーがリアクションする光景は、今では当たり前です。 この双方向の関心が重なった結果としてスプリントレビューにも変化がありました。開発チームからの共有会に近かった場が、お互いが「この機能をどう提供するか」の視点で意見を交換し合い、どんなプロダクトにしていくべきかを議論する場になりました。 商談同行で生まれたコミュニケーションパスの変化 この関係性が当たり前になると、 作る前から「これは本当に届けられるのか」という問いに対して、解像度の高い状態で開発を進める環境 が生まれます。一度の商談で得られるのは顧客の課題ですが、続けることで得られるのは、課題が自然に集まってくる関係そのものです。 おわりに 「そのプロダクト、自分で売れるか？」 自分で売ろうとすれば機能の強みと弱みが同時に見え、その学びをプロダクトの価値に還元する。売れるかという問いへの答えを探す過程で、営業メンバーと「作る前から『届けられるか』を検証できる土壌」が育っていきました。 この取り組みは、自分の役職に囚われない動きも必要でしたが、それ以上に営業メンバーが日頃から築いてきた顧客との関係性があったから起こせた行動でもあります。良いことも悪いこともはっきりフィードバックしてもらえる顧客が多いのは、営業メンバーの日々の取り組みのおかげなので本当に感謝しています。 PdEConf 2026 に参加される方で、同じような取り組みをされている方、これから始めようとしている方がいれば、ぜひ会場でお話しできると嬉しいです。

本ブログは 2024 年 11 月 24 日に公開された AWS Public Sector ブログ Deploying AWS Modular Data Center: From ordering to delivery and installation を翻訳したものです。 Amazon Web Services (AWS) Modular Data Center (MDC) とは、AWS のマネージドデータセンターを迅速にデプロイするサービスで、インフラが限られた場所でも、ロケーション依存型アプリケーションやレイテンシー依存型アプリケーションの実行が可能になります。遠隔地でのデプロイ時間を短縮し、最大 5 ラック の AWS Outposts や AWS Snow Family デバイスを収容します。MDC は 20 フィートの輸送用コンテナ 2つで構成され、ICD-705 （米国の情報機関が機密情報を扱う施設の物理的・技術的セキュリティ基準を定めた指令）準拠のシールド筐体に配電機能、冗長冷却 (N+1)、セキュリティ、監視、消火設備など、重要なインフラ要素を備えたデータセンターとして機能する自己完結型ソリューションです。AWS MDC サービスは、現場で低遅延のアプリケーションを実行する必要があるものの、データセンターを置く十分なスペースがないお客様向けに設計されたものです。例えば、防衛、国家安全保障、人道支援機関では、MDC を導入することで計算負荷の高いワークロードやストレージ負荷の高いワークロードをタクティカルエッジで実行でき、AI や機械学習によって大量のデータ処理を行い、わずかな遅れも許されない状況でもリアルタイムの意思決定が可能になります。 本投稿では、MDC を導入するためのエンドツーエンドのプロセスについてご説明します。合わせて、 Amazon Web Services (AWS) とお客様の役割や責任の分担についても解説し、デプロイメントの成功、運用可用性の向上、セキュリティ体制の強化に向けて明確な指針を提供します。サイトへの MDC の導入方法を 6 つのステージで示しておりますので、ぜひ最後までお読みください。  6 つのデプロイステージ 導入方法はお客様ごとに異なるものです。そのため、AWS はお客様とプロセス全体で常に緊密に連携し、MDC の納入を確実かつ円滑に行います。MDC のデプロイプロセスは次の 6 つのステージで構成されます。 リクエストの送信 現地調査結果の確認および現地準備 発注承認 納品 設置および試運転 政府セキュリティ認定 図 1.MDC 導入の工程: エンドツーエンドの全 6 ステージ。 以下では、各ステージの詳細を説明します。導入プロセスを理解いただくことで、効率的な準備にお役立てください。 （注：以下のプロセスはアメリカ国内のお客様を対象とした説明となっており、また、日本のお客様にはアクセスができないURL等がございます。ご不明な点がありましたらAWSアカウントチームまでお問い合わせ下さい） ステージ 1: リクエストの送信 このプロセスでは、お客様固有のニーズに対応するためのコンサルティングを行います。まず、 AWS マネジメントコンソール の AWS MDC ページからお問い合わせフォームに入力いただき、AWS に送信します (図 2)。フォームを送信後、2 営業日以内に AWS からプライマリアカウントオーナーにご連絡いたします。組織内でプライマリアカウントオーナーが不明の場合は、AWS アカウントチームまでお問い合わせください。 このステージでは、AWS はお客様と連携して、MDC のユースケースを明確にし、サイト準備アンケートなどで設置サイトの情報を収集します。これには、インフラの依存関係を特定するために、導入場所、気象条件、電力、ネットワーク接続、セキュリティ要件などのサイト特性に関する情報も含まれます。また、お客様のニーズに最適な MDC 構成と AWS Outposts または AWS Snowball Edge のデバイス容量を決定するためのお手伝いもします。事前定義された構成がお客様のニーズに合わない場合は、お客様の要件に合わせたカスタム構成を作成するために協力させていただきます。 図 2.AWS マネジメントコンソールのお問い合わせフォーム。 ステージ 2: 現地調査結果の確認および現地準備 お客様からのリクエストとサイト情報の確認後、AWS の技術者または AWS の資格を持つ技術者を派遣し、サイト準備アンケートの内容を基に現地調査を実施します。この現地訪問は、そのサイトが MDC の各要件 (以下の一覧参照) に対応しているかを確認することが目的となります。そのため、現地訪問にあたり、お客様には AWS チームに現地の連絡先と立ち入り権限をご提供いただく必要があります。現地では、設置を進めるための情報を収集し、MDC 設置前に解決すべき問題を特定します。現地調査を完了したのち、その結果を確認し、サイトの準備に向け追加対応が必要な場合はお客様にお知らせします。サイトの MDC 設置要件への対応は、お客様の責任において行っていただくものですが、AWS は対応を完了していただくための必要な情報を提供し、設置前には現地の状況を確認させていただきます。サイトでの MDC の設置と試運転を行うにあたり、お客様には AWS のチームと協力の上、当該サイトがすべての要件を満たしているかどうかを確認し、現地調査結果の検証をすべてクリアしていただく必要があります。 カテゴリ 要件 設置場所 (据付面) 設置には、20 フィート × 30 フィートのコンクリート基礎面または砕石地盤が必要。 離隔スペース MDC 設置面積は 16 フィート × 20 フィート (4.9 m x 6.1 m)。全周囲に少なくとも 8 フィート (2.4 m) の保守スペースを確保。ラック搬入を容易にするため、エリア全体においてフォークリフトなどの荷役機器の移動が可能であること。 耐荷重 MDC の設置および撤去を行う場所と搬入動線は、MDC、荷役機器、配送車両の合計重量に耐えられること。設置場所の据付面そのものは、沈下することなく最低 50,000ポンドの耐荷重があること。 耐震補強 施設への MDC 設置期間中は、規制または建築基準法で定める範囲において、適切な耐震ブレースまたはアンカーの設置、維持が必要。 施設へのアクセス MDC 設備に対し、AWS による MDC への物理的アクセス、保守、MDC の撤去を阻害するような変更を行わないこと。フェンスやセキュリティカメラなどの追加のセキュリティ対策が必要な場合は、AWS の担当者までご相談ください。 温度および湿度 周囲の外気温は -20°F (-30°C)～127°F (53°C) の範囲とし、相対湿度は 5%～95% であること。MDC を屋内に設置する場合、十分な空気循環を行い、動作中は一定の温度と湿度の範囲を維持すること。 標高 MDC の設置場所は、海抜 10,000フィート (3,050メートル) 未満の標高にあること。 電源 二重化構成の場合、MDC には三相 400/480 VAC、50/60Hz、175A の電源が 2 系統必要。冗長性を下げた構成の場合は、単一の電源系統で動作可能。 ネットワーク MDC のネットワーク要件は、お客様のニーズによって異なる場合があります。AWS の担当者までご相談ください。MDC のネットワークラックには、お客様支給のネットワーク機器および暗号化ハードウェアを最大 10U まで収容可能。ラックはUPSで保護された冗長A+B電源の供給も可能。 サイトの要件について、より詳しくは AWS Modular Data Center User Guide をご参照ください。 ステージ 3: 発注承認 現場調査結果の確認後、サービス利用規約に同意いただき、発注書の発行をもって発注手続きを完了します。そこから、MDC の構築、事前設定、出荷準備をサービスチームが行います。MDC は製造プロセス完了後、お客様の現地ご担当者と納品日および設置日を調整したうえで出荷されます。 ステージ 4: 納品 MDC の準備が整い次第、ユニットを現地に配送し、組み立てと設置作業を行うための調整をお客様と進めます。MDC は、不正開封防止シールや不透明梱包など、標準的な商業用セキュリティ対策を講じて非機密扱いとして出荷されます。機密扱いでの配送が必要な場合は、お客様と連携のうえ、MDC を米国本土 (CONUS) の空港または出発港まで護送する運送業者の手配もお手伝いいたします。MDC の輸送は、車両、鉄道、船舶、軍用機 (C-17 または C-5 のみ) から選択できます。 AWS は、運送業者との調整、積み込みおよび荷降ろし作業、お客様のサイトへの MDC の配送を含む、CONUS 内での輸送と物流の統括責任を負います。また、現場要件を満たした水平な据付面上に MDC を設置するためのクレーンやフォークリフトなどの重機も手配します。サイトが米国本土外 (OCONOUS) である場合、運送業者との調整、積み込みおよび荷降ろし、配送、登録輸入者としての手続きなど、輸送と物流に関する対応はお客様にて行っていただきます。また、MDC を水平な据付面上に設置するための機器類もお客様手配となります。  ステージ 5: 設置および試運転 MDC の設置は、AWS チームがサイトに到着し、お客様の指定担当者と到着確認を行った後すぐに開始されます。荷解き作業を開始する前に、AWS チームが最終的なサイト確認を実施し、現地の状況が MDC の要件に合致しているかをあらためて確認します。 サイトが必要な要件を満たしていない場合、作業は延期となります。作業を延期することがないよう、お客様には MDC の納品前にサイト準備作業をすべて完了いただくことが極めて重要です。 また、AWS チームがサイトにアクセスするための許可手続きは、お客様側で行っていただく必要があります。MDC をデプロイする場所に AWS がアクセスできない場合、AWS のサポートが限定される場合があります。 AWS チームが MDC を指定のコンクリートまたは砕石基礎に配置し、組み立てと設置を進めます。所要期間はサイトの状況にもよりますが、通常 1〜2 週間です。機器類および電気システムを含むすべての MDC コンポーネントの組み立て、設置、テストは、AWS にて管理します。また、AWS が提供する機器に使用するすべての光ファイバーは、AWS が準備し、MDC 内に敷設します (電気設備の検査やテストも含みます)。お客様には、MDC を正常に動作させるための、電源、ネットワーク、緊急管理システム用など、すべての外部ファイバーケーブルと電源ケーブルを用意いただき、接続作業を対応いただきます。設置作業時において MDC への接続および通電は、お客様側の有資格電気技術者が実施することが義務付けられています。お客様は、AWS 起動手順のほか、関連法令、電気規程、建築消防法規に従って MDC への通電と接続を実施する責任を担います。 試運転が完了すると、メンテナンスサービスが開始されます。MDC は物理的にお客様のサイトに設置されているため、本体のメンテナンスは AWS とお客様との責任共有となります。AWS は、AWS の技術者または AWS 認定の技術者による定期検査や修理など、予防および是正保守を提供します。重要なスペアパーツの準備、保管も行い、納品に時間がかかる部品類でもすぐに使えるよう常備します。さらに AWS は MDC 内に消火システムを設置し、この保守も行います。お客様は MDC の定期的な検査、監視を行い、エラー状態が発生した際は AWS に速やかに報告する責任を負います。また、問題発生時にはサイト常駐担当者にアラート発報するよう、消火・警報システムとオペレーションセンターを接続しておき、即時対応を徹底する必要があります。MDC の物理的なセキュリティ維持もお客様側の責任となります。なお、MDC にはモニタリングシステムが組み込まれています。MDC を AWS リージョン に接続すると、 Amazon CloudWatch と連携でき、MDC の状態をリモート監視できます。 MDC は、ICD-705 に基づく機密情報隔離施設 (SCIF) の要件を満たすように設計されており、TS/SCI (Top Secret/Sensitive Compartmented Information ) レベルまでのデータをホストする認定を取得することができます。MDC は、電磁波盗聴対策 (TEMPEST)、無線周波数 (RF) シールドに加え、音響や熱に関する各種要件に完全準拠した構築、試験が行われています。MDC を SCIF として認定する必要がある場合、AWS は試運転の完了後に、お客様の承認担当者 (AO) が実施する認定審査に対応できる状態に準備します。適切な AO の選定と必要な認定取得は、お客様の責任にて進めていただきます。 ステージ 6: 政府セキュリティ認定 特定の政府機関で MDC を使用する場合、お客様は適切な AO から必要な運用権限 (ATO) や接続権限 (ATC) を取得する必要があります。認定の手続きにおいて、AWS は必要な書類を提供し、お客様をサポートします。認定が必要な場合、MDC に収容する機密ワークロード用の AWS ラックの設置およびテストは、必ず認定取得後に実施することになります。認定が下り次第、ラックの設置が可能になり、AWS が MDC 内の AWS ラックの組み立て、設置、テストを行います。  まとめ 本投稿では、リクエストの送信から納品、設置まで、AWS Modular Data Center をデプロイするための 6 つのステージについて説明しました。MDC の導入をスムーズに達成するためには、各ステージで以下のポイントを押さえることが重要です。  リクエストの送信 — AWS マネジメントコンソールのお問い合わせフォームにご記入ください。お客様の要件をもとに、AWS と連携して MDC の構成を確定させます。また、サイト準備アンケートにもご回答いただきます。 現地調査結果の確認および現地準備 — AWS とともに現地調査を実施します。現地調査の結果から、サイトに必要な作業を行い、MDCの設置と試運転の前に完了させます。 発注承認 — サービス利用規約への同意と発注書の発行をもって発注を確定します。AWS は MDC の構築、事前設定、出荷準備に進みます。 納品 — 輸送、物流は AWS との調整が必要です。サイトが米国本土外の場合は、物流と重機類はお客様にて手配いただきます。また、サイトが MDC の到着を受け入れ、設置を開始できる状態にしておきます。 設置および試運転 — AWS がサイトに立ち入るためのアクセス権を確保いただきます。設置チームが作業できるよう、電源接続をご準備ください。MDC の組み立て、設置、テストは AWS が実施します。 政府セキュリティ認定 — 認定が必要な場合は、お客様の AO から ATO および/または ATC を取得してください。AWS はドキュメンテーションを支援し、認定取得後にラックの設置を完了します。 注意: AWS Modular Data Center は現在、米国 Joint Warfighting Cloud Capability (JWCC) 契約に基づく政府機関のお客様のみがご利用いただけます。AWS Modular Data Center は現在、AWS GovCloud (米国西部) リージョンと AWS GovCloud (米国東部) リージョンでサポートされています。 AWS Modular Data Center の詳しい情報は、お客様の AWS アカウント担当者までお問い合わせください。 タグ:  Amazon CloudWatch ,  AWS GovCloud (US) ,  AWS Management Console ,  AWS Outposts ,  AWS Public Sector ,  AWS Snow Family ,  AWS Snowball Edge ,  defense ,  government ,  security ,  storage ,  technical how-to