WEB問題集
解説
【正解: C】の理由
SaaS では Microsoft がアプリ本体 / OS / ランタイム / ミドルウェア / 物理層をすべて管理するため、顧客責任は ID とアクセス権の管理、データ分類と保護設定、デバイス エンドポイント保護のみに限定されます。Microsoft 365 や Dynamics 365 では具体的に Microsoft Entra ID でユーザー / グループを管理し、Conditional Access / MFA で認証を強化、Sensitivity Labels でデータを分類するのが顧客の主要な責務となります。
【他選択肢が違う理由】
- A. アプリ コードの保守: Microsoft 365 のアプリ本体は完成品で、顧客がコードを保守することはありません
- B. OS パッチ / ランタイム: SaaS では Microsoft 側で完全管理されます。これは IaaS の責任範囲です
- D. ハイパーバイザー / 物理ネットワーク: 全モデルで Microsoft の責任であり、顧客は触れません
解説
【正解: A】の理由
IaaS はゲスト OS / ミドルウェア / アプリ / データをすべて顧客が管理できる形態で、Azure Virtual Machines が代表例です。OS カーネル パラメータ調整、特定バージョンのランタイム、ハードウェア互換性が必要な独自エージェント、古い OS を必要とするレガシー アプリのリフト&シフト移行に最適です。柔軟性が最大の反面、運用負荷も最大となるため PaaS / SaaS との比較検討が必要となります。
【他選択肢が違う理由】
- B. コードだけ書いてサーバ管理は不要: PaaS (App Service / Container Apps) の典型シナリオです
- C. 完成した CRM をブラウザ利用: Dynamics 365 / Salesforce などの SaaS の用途です
- D. 物理データセンターの所有: クラウドではハードウェアは Microsoft 所有で、オンプレ / プライベート クラウドの領域です
解説
【正解: A, C】の理由
クラウドが競争力を高める核心は「速度」と「リーチ」の 2 軸です。Time to Market 短縮は、従来の調達 / 設置 / 構成に数ヶ月かかった工程を数分で完結させ、新製品やキャンペーンを競合より早く投入できます。グローバル アクセスは Azure の世界 60 以上のリージョンへ即時にデプロイでき、海外進出やマルチリージョン DR を個社が一からデータセンターを建てずに実現できる戦略的価値があります。
【他選択肢が違う理由】
- B. ハードウェア所有が必須: クラウドではハードウェアは Microsoft 所有で、顧客は利用権のみを取得します
- D. 全顧客に同一機能を強制: 差別化は各社の SaaS / アプリ層で実現するもので、競争力強化とは逆方向です
- E. 調達決裁が不要: 開発スピード向上の一面ですが、企業の競争力という観点では中核的な A / C を優先します
解説
【判定: いいえ】の理由
パブリック クラウド単独移行は、Web フロントの「ピーク時 10 倍トラフィック」のスケーラビリティ要件は Azure のオートスケール (VMSS / App Service / Functions) と Load Balancer で確実に満たせます。しかし基幹業務システムの「機密データの物理ロケーションと管理権限を完全に自社管理下に置く」要件と根本的に整合しません。パブリックではハードウェアと物理ロケーションは Microsoft が管理するためです。
【「はい」が違う理由】
本要件を無視して全てパブリックに移行すると、金融 / 防衛 / 医療系の規制監査で指摘を受けるリスクがあります。Web フロントだけを Azure へ、基幹業務はオンプレに残すハイブリッド構成が要件適合の唯一解です。Azure Arc を使えばオンプレ サーバを Azure 管理面に取り込み Policy / Defender for Cloud を一元適用でき、運用負荷も抑えられます。
解説
【判定: いいえ】の理由
オンプレミス / プライベート クラウド単独運用は、基幹業務システムの「機密データの管理権限を完全に自社管理下に置く」要件は完全に満たせます。しかし Web ストアフロントの「ピーク時に 10 倍超のトラフィックを捌く」スケーラビリティ要件と整合しません。プライベート クラウドの物理キャパシティは事前調達時点で上限が決まり、ピーク時のスケール アウトが物理的に不可能だからです。
【「はい」が違う理由】
10 倍ピークを見越して常時 10 倍の容量を保有する設計は CapEx が過剰投資となり、ピーク以外では設備稼働率が極端に低下します。データセンターの電力 / 冷却 / 保守費用も継続して発生し、TCO はクラウド利用時の数倍になることもあります。Web フロントだけをパブリック クラウドに切り出せばオートスケールがピークに追従し、これがハイブリッド構成の合理性です。
解説
【判定: はい】の理由
ハイブリッド クラウド構成は本問の相反する 2 要件を同時に満たす唯一の解です。Web ストアフロントを Azure に配置すれば VMSS / App Service / Functions のオートスケールでピーク時 10 倍トラフィックに即時追従でき、機会損失を防げます。Front Door / CDN を併用すればグローバル レイテンシも最小化できます。基幹業務システムはオンプレに残るため、機密データの物理ロケーションと管理権限は完全に自社管理下に維持されます。
【「いいえ」が違う理由】
ExpressRoute または S2S VPN で両者を安全かつ低レイテンシで接続すれば、Web フロントから基幹業務 API への呼出も実用的な応答時間で実現できます。Azure Arc でオンプレと Azure リソースを統合管理面に取り込めば、Azure Policy / Defender for Cloud / Monitor を横断的に適用でき、運用ガバナンスも担保できます。
以下の各ステートメントが、クラウド サービス モデル (IaaS / PaaS / SaaS) の責任共有モデルに照らして正しい場合は「はい」、誤っている場合は「いいえ」を選択してください。
注: 正解 1 つにつき 1 点が与えられます。
| ステートメント | はい | いいえ |
|---|---|---|
SaaS において、エンドユーザーの ID とパスワードの管理は Microsoft の責任である。 誤った記述です。エンドユーザーの ID とアクセス権の管理は責任共有モデルで全モデル共通の顧客責任です。Microsoft 365 などの SaaS でも、Microsoft Entra ID でユーザー / グループを作成し、パスワード ポリシー設定や MFA 有効化を行うのは顧客側の責務となります。 | ||
PaaS では OS のセキュリティ パッチ適用は顧客の責任である。 誤った記述です。PaaS では OS / ランタイム / ミドルウェアまで Microsoft が完全管理します。App Service / Functions / Azure SQL Database を使う場合、顧客は OS パッチを意識する必要がなく、アプリ コードとデータ保護のみが責務となります。OS パッチが顧客責任なのは IaaS です。 | ||
IaaS では仮想化基盤 (ハイパーバイザー) のセキュリティ更新は Microsoft の責任である。 正しい記述です。ハイパーバイザー / 物理ホスト OS / 物理ネットワーク機器の管理は IaaS でも Microsoft の責任です。IaaS で顧客が責任を持つのはゲスト OS 以上 (アプリ / データ / ネットワーク構成 / ID) であり、ホスト OS とハイパーバイザーには顧客は触れません。 |
次の各ステートメントを完成させるために、ドロップダウンから最も適切な選択肢を選んでください。同じ選択肢は 2 回使用できません。
| ステートメント | 選択 |
|---|---|
Microsoft 365 (Outlook / Teams / SharePoint) は [ ] に分類される。 Microsoft 365 は完成したアプリケーション一式を提供する SaaS の代表例です。Microsoft がアプリ本体 / OS / ランタイム / ミドルウェア / 物理層のすべてを管理し、顧客はブラウザやクライアントから利用するだけで、責任は ID 管理 / データ分類 / デバイス保護のみに限定されます。 | |
Azure App Service と Azure SQL Database は [ ] に分類される。 App Service と Azure SQL Database は PaaS の代表例です。OS / ランタイム / ミドルウェア (IIS / .NET / Java / Node.js / DB エンジン本体) はすべて Microsoft が管理し、顧客はアプリ コードとデータ設計に集中できます。スケーリングやパッチ適用も自動化されています。 | |
Azure Virtual Machines (ゲスト OS の完全制御が可能) は [ ] に分類される。 Azure Virtual Machines は IaaS の代表例で、ゲスト OS (Windows / Linux) のフル制御権が顧客にあります。カーネル パラメータ調整や独自エージェント導入が可能なため、レガシー アプリのリフト&シフト移行に最適で、OS パッチ以上が顧客責任となります。 |
左のクラウドの利点を、右の最も関連するビジネス インパクトにドラッグ&ドロップしてください。
- Scalability (スケーラビリティ)
- Cost Optimization (コスト最適化)
- Agility (俊敏性)
- Reliability (信頼性)
解説
【正解マッピング】
クラウドの 4 つの代表的な利点は、それぞれ異なるビジネス課題を解決するため明確に切り分けて整理できます。Scalability はリソースを需要に応じて拡張できる能力で、VMSS / App Service / Functions のオートスケールにより Black Friday や TV 露出などの突発的なトラフィック急増にも遅延なく追従できます。Cost Optimization は従来オンプレで数千万円規模だった初期投資 (CapEx) を従量課金 (OpEx) に転換でき、Reservations / Savings Plan / Hybrid Benefit と組み合わせれば財務柔軟性が大きく向上します。Agility はリソース調達 / 廃棄のリードタイム短縮により、新機能を数日から数週間でリリースでき、A/B テストや段階的リリースなど先進開発手法を実践できます。Reliability は Site Recovery によるリージョン跨ぎ DR と Region Pair の組み合わせで、リージョン障害時も別リージョンへフェイルオーバーして業務継続性を担保できます。
クラウド移行の標準的な 4 段階アプローチを正しい順序に並べ替えてください。
- Assess (評価): 現行環境を Azure Migrate で可視化し、依存関係と移行先 SKU を試算
- Plan (計画): リフト&シフト / リプラットフォーム / リファクタリングなど移行戦略を決定
- Migrate (移行): Azure Migrate / Database Migration Service で段階的に移行を実行
- Optimize (最適化): Cost Management / Advisor でコスト・性能を継続的にチューニング
解説
【正しい順序: Assess → Plan → Migrate → Optimize】の理由
Microsoft Cloud Adoption Framework (CAF) が定める標準移行ライフサイクルです。Assess で Azure Migrate を用い、サーバ / DB / 依存関係を棚卸しし、移行先 SKU と TCO を試算します。Plan ではワークロードごとにリフト&シフト / リプラットフォーム / リファクタリングの戦略と優先度を決定します。Migrate で Azure Migrate / Database Migration Service / Site Recovery を使い段階的にカットオーバーを実施します。最後の Optimize で Cost Management の実コストと Advisor の推奨を活用し、SKU 適正化 / Reservations / 自動停止による継続改善を回します。