以下に 問題1 を指定の形式で整理・解説します。
■ 問題文
ある企業では、Amazon EC2 上でアプリケーションをホストしています。このアプリケーションは、規制遵守のための特定のルールの対象となります。特定のルールの 1 つに、ワークロードへのトラフィックとワークロードからのトラフィックを、ネットワークレベルの攻撃に対して検査する必要があります。これには、パケット全体の検査が含まれます。この規制ルールに準拠するには、セキュリティエンジニアは侵入検知ソフトウェアを c5n.4xlarge EC2 インスタンス にインストールする必要があります。次に、アプリケーションのインスタンスとの間のトラフィックをモニタリングするようにソフトウェアを設定しなければなりません。
セキュリティエンジニアは次に何をすべきですか？
■ 選択肢
A.
Amazon Inspector を使用してネットワークレベルの攻撃を検出し、疑わしいパケットを EC2 インスタンスに送信するために AWS Lambda 関数をトリガします。
B.
Network Load Balancer を使用してモニタリング用の EC2 インスタンスにトラフィックを送信するように VPC フローログを設定します。
C.
ネットワークインターフェイスをプロミスキャスモードにして、トラフィックをキャプチャします。
D.
Network Load Balancer を使用してモニタリング用の EC2 インスタンスにトラフィックを送信するように VPC トラフィックミラーリング を設定します。
■ 問題文の要件の概要
- パケット全体の検査が必要（＝パケットのペイロードも含めたリアルタイムモニタリングが必要）
- ネットワークレベルの攻撃の検出
- EC2 間トラフィックの監視
- c5n.4xlarge インスタンスを用いた侵入検知の設定
■ 正解の選択肢と解説
✅ D. VPC トラフィックミラーリングを使ってトラフィックをモニタリング用EC2に送信
- VPCトラフィックミラーリングは、指定したENI（Elastic Network Interface）を通過するトラフィックをキャプチャして、別のモニタリング用EC2にリアルタイムで送信する機能。
- パケットの内容（ペイロード）まで検査可能で、IDS（侵入検知システム）やネットワークフォレンジックに有効。
- NLBはトラフィック経路として使えるが、ここでの要点はミラーリング設定。
■ 不正解の選択肢の理由
| 選択肢 | 理由 |
|---|---|
| A | Amazon Inspector は EC2 や Lambda、ECR イメージに対する 脆弱性スキャンやセキュリティベストプラクティスの評価を行うサービスであり、ネットワークパケットのリアルタイム監視や検査には対応していない。 |
| B | VPC フローログはトラフィックのメタデータ（IP、ポート、許可/拒否）を記録するログ機能であり、パケットの中身は取得できない。パケット全体の検査には不十分。 |
| C | EC2 では プロミスキャスモードは非サポートであり、VPC 内の他のインスタンスのトラフィックをキャプチャできない設計。ネットワーク仮想化により隔離されている。 |
■ SCS試験で押さえておくべきポイント
- VPC トラフィックミラーリングは、EC2上のIDSやパケットキャプチャを実現するための公式手段。
- VPC フローログはメタデータのみ、ネットワーク可視化やトラブルシューティングには有効だが侵入検知には不十分。
- Amazon Inspectorは 脆弱性スキャン用途で、ネットワーク監視では使わない。
- EC2インスタンスでのプロミスキャスモード使用不可は覚えておくべき試験頻出知識。
他のネットワーク可視化系機能との使い分け（VPC Flow Logs vs Traffic Mirroring）も重要なポイントです。必要に応じて補足します。
以下に 問題2 を指定の形式で整理・解説します。
■ 問題文
ある企業がマイクロサービスアプリケーションを Amazon Elastic Kubernetes Service (Amazon EKS) でホストしています。企業は、オンデマンドでアプリケーションを更新するために継続的なデプロイを設定しています。
セキュリティエンジニアは、アプリケーションログの異常をほぼリアルタイムで自動検出するソリューションを実装する必要があります。また、このソリューションでは、これらの異常に関する通知をセキュリティチームに送信する必要があります。
■ 選択肢
A.
Amazon CloudWatch Container Insights を設定して、EKS アプリケーションログを収集および集約します。異常を監視するための CloudWatch アラームを作成します。異常が検出されたときにセキュリティチームに警告する AWS Lambda 関数を起動するようにアラームを設定します。
B.
AWS App Mesh を設定して、Amazon EKS のマイクロサービスへのトラフィックを監視します。App Mesh を AWS CloudTrail と統合してログを記録します。Amazon Detective を使用してログを分析し、異常が検出された場合にセキュリティチームに警告します。
C.
Amazon EKS を設定して、アプリケーションログを Amazon CloudWatch に送信します。ロググループのメトリクスフィルターに基づいて CloudWatch アラームを作成します。しきい値タイプとして異常検出を指定します。Amazon SNS を使用してセキュリティチームに警告するようにアラームを設定します。
D.
Amazon EKS を設定して、ログを Amazon S3 にエクスポートします。Amazon Athena クエリを使用してログを分析し、異常がないか確認します。Amazon QuickSight を使用して、ユーザーアクセスリクエストの異常を視覚化および監視します。Amazon SNS 通知を設定して、セキュリティチームに警告します。
■ 正解の選択肢と解説
✅ C.
CloudWatch Logs → メトリクスフィルター + 異常検出 → SNS で通知
- Amazon EKS のアプリケーションログを CloudWatch Logs に送信
- メトリクスフィルターで異常パターンに基づくカスタムメトリクスを生成
- CloudWatch 異常検出を使用して通常とは異なる挙動を自動検出
- アラームを SNS 経由でセキュリティチームに通知
✅ リアルタイム性・自動検出・通知の要件すべてを満たすベストな構成です。
■ 不正解の選択肢の理由
| 選択肢 | 理由 |
|---|---|
| A | Container Insights はリソースメトリクス（CPU、メモリ、I/O等）監視に特化しており、アプリケーションログの異常検出には適していない。 |
| B | App Mesh はマイクロサービスの通信制御、CloudTrail は API 呼び出しログ、アプリケーションログの異常検出機能を直接提供しない。Detective は主にセキュリティイベントの相関分析に使用。 |
| D | S3＋Athena＋QuickSight の構成はバッチ処理的であり、リアルタイム検出には不向き。ログ分析はできるが即時通知性が欠如。 |
■ SCS試験で押さえておくべきポイント
- CloudWatch メトリクスフィルター + 異常検出 + SNS は、リアルタイム異常検出・通知の組み合わせとして頻出。
- Container Insights ≠ アプリケーションログ分析。主にパフォーマンスモニタリング用途。
- Athena / S3 / QuickSight ＝ バッチ集計や分析系のアーキテクチャで、即応性には欠ける。
- 異常検出（Anomaly Detection）機能は、ML に基づいた CloudWatch アラームの強化機能として強く意識しておくとよい。
必要に応じて、CloudWatch のメトリクスフィルター構文や異常検出設定画面の使い方も補足できます。
以下に 問題3 の内容を指定形式で整理・解説します。
■ 問題文（編集せずにそのまま）
ある企業が AWS でワークロードを実行しています。ワークロードは開発、テスト、本番用にそれぞれ別の AWS アカウントで運用されています。すべての開発者が開発アカウントにアクセスできますが、テストアカウントと本番アカウントにアクセスできるのは一部の開発者のみです。
企業は、各環境の各開発者用に個別の認証情報を管理するのに多くの時間を費やしています。セキュリティエンジニアは、開発者が異なるアクセスを必要とする場合に利用できる、よりスケーラブルなソリューションを実装する必要があります。ソリューションは、開発者が複数のアカウントにわたるリソースへアクセスできるようにし、認証情報の共有を最小限に抑えなければなりません。
これらの要件を満たすソリューションを選択してください。
■ 選択肢（編集せずにそのまま）
A.
テスト環境と本番環境にサービスアカウントを作成します。テストアカウントと本番アカウントへのアクセスを必要とする開発者に、サービスアカウントのアクセスキーを付与します。サービスアカウントのアクセスキーを定期的にローテーションします。
B.
Amazon Simple Workflow Service (Amazon SWF) のワークフローを作成します。追加のアクセスが必要な場合は、ワークフローを使用して他のアカウントへのアクセスをリクエストするように開発者に指示します。
C.
AWS Identity and Access Management Access Analyzer を使用して、開発者が各アカウントで必要とするアクセス許可を特定します。IAM Access Analyzer を設定して、開発者ごとに適切なアクセスを自動的にプロビジョニングします。
D.
テストアカウントと本番環境アカウントで IAM ロールを作成します。ロールに sts:AssumeRole アクションを許可するポリシーを追加します。テストアカウントと本番アカウントにアクセスできる開発者向けに、開発アカウントに IAM ロールを作成します。これらのロールを、テストアカウントと本番アカウントの新しいロールの信頼ポリシーに追加します。
■ 問題文の要件の概要
- 3つのアカウント（開発・テスト・本番）間でのアクセス制御
- 一部の開発者がテスト・本番にアクセス可能
- 認証情報の個別管理を削減し、スケーラブルにしたい
- 認証情報の共有を最小限に抑えることが要件
■ 正解の選択肢と解説
✅ D. テスト・本番アカウントに IAM ロールを作成し、開発アカウントから AssumeRole によるアクセスを許可する
- 各アクセス先アカウントに IAM ロールを作成
- 信頼ポリシーに開発アカウントの IAM ロールまたはユーザーを追加（AssumeRole）
- 開発者は開発アカウントから STS（Security Token Service）経由で一時的にロールを引き受けてアクセス
- 結果として、認証情報を共有せずにクロスアカウントアクセスを実現できる
- セキュリティのベストプラクティスに基づいたスケーラブルな方法
■ 不正解の選択肢の理由
| 選択肢 | 理由 |
|---|---|
| A | サービスアカウントのアクセスキー配布は認証情報の共有を前提としており、セキュリティリスクが高い。定期ローテーションしても解決にならない。 |
| B | Amazon SWF はワークフローオーケストレーションサービスであり、アクセス権管理には不適切。使い方が不自然。 |
| C | IAM Access Analyzer はアクセスの可視化・分析ツールであり、自動で権限をプロビジョニングする機能はない。意図しない外部アクセスを検出する目的のツール。 |
■ SCS試験で押さえておくべきポイント
- クロスアカウントアクセスの基本 = AssumeRole
- アクセス先アカウントで IAM ロールを作成
- 信頼ポリシーで引受け元（ユーザー・ロール）を明示
sts:AssumeRoleにより一時的な認証情報を取得
- アクセスキーの共有は非推奨、なるべく STS を使用
- IAM Access Analyzer = アクセスの分析、自動設定ではない
- セキュリティとスケーラビリティの観点で AssumeRoleベースの構成が模範解答
必要に応じて、AssumeRole のトラストポリシーや、開発アカウント→テスト・本番アカウントのロール切り替え方法の例も補足可能です。
以下に 問題4 の内容を指定形式で整理・解説します。
■ 問題文（編集せずにそのまま）
ある企業は、AWS Lambda 関数を使用してアプリケーションロジックを実装しています。同社は、AWS Organizations 内の組織を使用して数百の AWS アカウントを管理しています。
同社は、すべてのアカウントにおいて Lambda 関数の脆弱性を継続的に監視するソリューションを実装する必要があります。このソリューションは、検出された問題をダッシュボードに公開する必要があります。テスト中または開発中の Lambda 関数は、ダッシュボードに表示されないようにする必要があります。
これらの要件を満たす手順の組み合わせを選択してください。(2 つ選択)
■ 選択肢（編集せずにそのまま）
A.
組織の管理アカウントで AWS Shield Advanced を有効にします。Amazon CloudWatch を使用して、脆弱性のある Lambda 関数のダッシュボードを構築します。
B.
組織の管理アカウントで、委任された Amazon GuardDuty の管理者アカウントを指定します。GuardDuty 概要ダッシュボードを使用して、脆弱性のある Lambda 関数の概要を取得します。
C.
すべてのアカウントで GuardDuty の Lambda Protection を有効にします。新しいアカウントに対して Lambda Protection を自動的に有効にします。テスト中または開発中の Lambda 関数にタグを適用します。タグのキーとして GuardDutyExclusion を使用し、タグの値として LambdaStandardScanning を使用します。
D.
組織の管理アカウントで、委任された Amazon Inspector の管理者アカウントを指定します。Amazon Inspector ダッシュボードを使用して、脆弱性のある Lambda 関数の概要を取得します。
E.
テスト中または開発中のすべての Lambda 関数に「test」または「development」のタグを適用します。これらのタグを含む検出結果を抑制する抑制フィルターを使用します。
■ 正解の選択肢と解説
✅ D. Amazon Inspector 管理者アカウント + ダッシュボード活用
✅ E. タグ + 抑制フィルターでテスト/開発環境を除外
D の解説：
- Amazon Inspector は Lambda 関数の「標準スキャン」や「コードスキャン」により、依存パッケージやコードの脆弱性を検出可能。
- AWS Organizations 経由で管理アカウントから委任管理者を指定して、複数アカウント横断的に Lambda をスキャン・可視化できる。
- Inspector のダッシュボードを使うことで、本番環境での問題を一元的に可視化可能。
E の解説：
- 「test」「development」タグを Lambda 関数に付与し、それをInspector の抑制フィルターで指定。
- これにより、開発・テスト用関数の検出結果を無視できる。
- ダッシュボード表示からも除外され、要件（本番関数のみ監視対象）に合致。
■ 不正解の選択肢の理由
| 選択肢 | 理由 |
|---|---|
| A | AWS Shield Advanced は DDoS 対策サービスであり、Lambda 関数のコード脆弱性スキャンには関与しない。CloudWatch による可視化も誤った用途。 |
| B | Amazon GuardDuty は **脅威検出（不正アクセス等）**が目的。コードの脆弱性検出は不可。Lambda の「保護」はあるが目的が異なる。 |
| C | タグによる除外指定に GuardDutyExclusion などのキーは存在しない。また、GuardDuty の Lambda Protection は「脆弱性スキャン」ではなく「脅威検出」目的なので誤り。 |
■ SCS試験で押さえておくべきポイント
- Amazon Inspector = 脆弱性スキャンツール
- EC2 / Lambda / コンテナに対応
- Lambda は標準スキャン（依存パッケージ）とコードスキャン（静的解析）
- 組織レベルでの監視 = Inspector の管理者アカウント設定（委任）
- 環境タグ＋抑制フィルター = 本番以外を除外
- GuardDuty / Shield は脅威検出やネットワーク攻撃対策。コード脆弱性には不適
必要であれば、Inspector のスキャン設定・フィルター設定例も提示可能です。
以下に 問題5 を指定フォーマットでまとめて解説します。
■ 問題文（編集せずにそのまま）
ある企業は、開発者の AWS アカウントからの AWS アクセスキーがコードリポジトリサイトで検出された場合に、自動メール通知を受信したいと考えています。
この要件を満たすメール通知を提供するソリューションを選択してください。
■ 選択肢（編集せずにそのまま）
A.
オペレーションタイプの AWS アカウントの連絡先情報を別のメールアドレスに変更します。このメールアドレスを定期的にポーリングして通知を取得します。
B.
Amazon EventBridge ルールを作成し、サービスカテゴリの値が「Risk」の AWS Health イベントに反応するように設定します。Amazon Simple Notification Service (Amazon SNS) を使用してメール通知を構成します。
C.
Amazon EventBridge ルールを作成し、Amazon GuardDuty の UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS の検出結果に対して Amazon Simple Notification Service (Amazon SNS) のメール通知を送信するように設定します。
D.
新しい異常検出ソフトウェアを実装します。AWS CloudTrail ログを取り込み、AWS マネジメントコンソールで ConsoleLogin イベントのモニタリングを設定します。異常検出ソフトウェアからのメール通知を設定します。
■ 問題文の要件の概要
- アクセスキーがコードリポジトリなどで検出された際に
- 自動でメール通知を受け取りたい
- 対象は開発者アカウントの AWSアクセスキーの漏洩イベント
■ 正解の選択肢と解説
✅ C.
Amazon GuardDuty の UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS 検出結果に対して EventBridge 経由で SNS 通知する
解説：
UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWSは、アクセスキーがAWS外部で使用されたときに GuardDuty が検出するタイプ。- EventBridge を使って検出イベントをトリガーに SNS メール通知が可能。
- この構成により、アクセスキーが漏洩して不正使用された瞬間に即座に通知できるため、要件を完全に満たす。
■ 不正解の選択肢の理由
| 選択肢 | 理由 |
|---|---|
| A | アカウント連絡先のメールアドレス変更は、AWSからのサービス通知（請求やメンテ）用途で、キー漏洩のリアルタイム通知は不可能。 |
| B | AWS Health の「Risk」カテゴリは主にサービス状態通知で、アクセスキー漏洩には関連しない。 |
| D | CloudTrail の ConsoleLogin イベントはマネジメントコンソールログインを記録するのみ。アクセスキーの外部使用検知は不可。また、外部製ソフトの導入は過剰でコスト・信頼性の面で劣る。 |
■ SCS試験で押さえておくべきポイント
- GuardDuty の検出タイプには意味がある：
UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWSはアクセスキーの漏洩・外部使用を示す。 - EventBridge は GuardDuty と連携できる：
GuardDuty 検出をトリガーにして、自動処理（通知、Lambda起動など）を構成可能。 - 通知には Amazon SNS を使用：
EventBridge → SNS → メール/Slack/Webhook等の配信がベストプラクティス。 - AWS Health や ConsoleLogin では漏洩検知はできない：
それらはサービス可用性やUIログイン監視であり、資格情報流出の検知には GuardDuty の方が適している。
追加で、EventBridge の設定例や通知テンプレートが必要であればお申し付けください。
以下に 問題6 を指定フォーマットで整理・解説します。
■ 問題文（編集せずにそのまま）
あるセキュリティエンジニアは、Amazon S3 バケットに保存されている機密データを識別するソリューションを実装する必要があります。このソリューションは、既存の Amazon Simple Notification Service (Amazon SNS) トピックを使用して、S3 バケット内の機密データについてレポートする必要があります。
最小限の実装作業でこの要件を満たすソリューションを選択してください。
■ 選択肢（編集せずにそのまま）
A.
S3 バケットをスキャンしてパターンに一致する機密データを探す AWS Lambda 関数を作成します。SNS トピックに通知を送信するように Lambda 関数をプログラムします。
B.
マネージドデータ識別子を使用して機密データを識別および分類するように Amazon Macie を設定します。SNS トピックに通知を送信する Amazon EventBridge ルールを作成します。
C.
Amazon GuardDuty を有効にします。AWS CloudTrail S3 データイベントを設定します。GuardDuty の検出結果に反応して SNS トピックに通知を送信する Amazon CloudWatch アラームを作成します。
D.
AWS Config を有効にします。S3 バケット内の機密データを監視し、SNS トピックに通知を送信するように AWS Config を設定します。
■ 問題文の要件の概要
- S3内の機密データを識別・レポート
- 既存のSNSトピックで通知
- 最小限の実装作業
■ 正解の選択肢と解説
✅ B.
Amazon Macie を使用して機密データを識別し、EventBridge で SNS 通知を送信
解説：
- Amazon Macie は S3 バケットの中の PIIや認証情報などの機密データを自動検出できるマネージドサービス。
- マネージドデータ識別子を用いることで、名前、クレジットカード番号、AWSアクセスキーなどを検出可能。
- Macie は EventBridge と統合されており、検出イベントをトリガーにして SNS トピックへ通知できる。
- サーバレスで自動化可能かつ、カスタムコード不要なので「最小限の実装作業」という条件を満たす。
■ 不正解の選択肢の理由
| 選択肢 | 誤っている理由 |
|---|---|
| A | Lambda でのスキャンは手動でのパターン実装や S3 操作、SNS 送信ロジックが必要。保守負荷が高く「最小限の実装作業」ではない。 |
| C | GuardDuty は脅威検出用であり、バケットの中身の機密性識別は不可。CloudTrail データイベントはアクセスログであり内容は対象外。 |
| D | AWS Config は構成の監査・コンプライアンスチェック用であり、S3オブジェクトの中身の解析は不可。データの機密性検知はできない。 |
■ SCS試験で押さえておくべきポイント
- ✅ Amazon Macie は S3 内の機密データ識別・分類に特化したマネージドサービス
- PII、認証情報、財務情報、PHI など
- ✅ マネージドデータ識別子を使えば、構築不要で高精度な検出が可能
- ✅ Amazon EventBridge は Macie の検出結果をトリガーにして SNS や Lambda と連携できる
- ❌ Lambda や Config、GuardDuty は「S3オブジェクトの中身の解析」には不適
追加で Macie の検出イベントに対する EventBridge ルール構文や SNS トピック構成の例が必要であれば、お知らせください。
以下に 問題7 を指定フォーマットで整理・解説します。
■ 問題文（そのまま出力）
AWS Organizations を使用している企業が、ワークロードを AWS に移行しています。同社のアプリケーションチームは、ワークロードが Amazon EC2 インスタンス、Amazon S3 バケット、Amazon DynamoDB のテーブル、および Application Load Balancer を使用することを決定しました。各リソースタイプについて、同社はデプロイが次の要件に準拠する必要があることを義務付けています。
- すべての EC2 インスタンスは、承認された AWS アカウントから起動される必要があります。
- すべての DynamoDB テーブルは、標準化された命名規則を使用してプロビジョニングされる必要があります。
- 組織内のアカウントにプロビジョニングされるすべてのインフラストラクチャは、AWS CloudFormation テンプレートによってデプロイされる必要があります。
これらの要件を満たす最適な手順の組み合わせを選択してください。(2 つ選択)
■ 選択肢（そのまま出力）
A. アプリケーション AWS アカウントの各サービスに対して AWS Config マネージドルールを有効にします。
B. アクセス許可の境界を使用して、内部コンプライアンス要件の条件が満たされない限り、アプリケーション AWS アカウントが特定のリソースをプロビジョニングできないようにします。
C. 管理者 AWS アカウントで CloudFormation テンプレートを作成します。StackSets をアプリケーション AWS アカウントと共有します。テンプレートがアプリケーション AWS アカウント専用に使用されるように制限します。
D. アプリケーション AWS アカウントで CloudFormation テンプレートを作成します。出力を管理者 AWS アカウントと共有して、準拠しているリソースを確認します。出力を管理者の AWS アカウントのみに制限します。
E. SCP を使用して、内部コンプライアンス要件の条件が満たされない限り、アプリケーション AWS アカウントが特定のリソースをプロビジョニングできないようにします。
■ 問題文の要件の概要
- EC2 インスタンス → 承認されたアカウントから起動
- DynamoDB テーブル → 命名規則の徹底
- 全リソース → CloudFormation によるデプロイ必須
- 全体として → ガバナンス強制と自動化された配布方法が求められている
■ 正解の選択肢と解説
✅ C.
管理アカウントで CloudFormation テンプレートを StackSets により配布し、制限付き使用
- StackSets を使えば、統一テンプレートを複数アカウントへ安全に配布可能。
- テンプレートの利用先アカウントを制限することで、承認されたアカウントからの起動制限にも合致。
- 全インフラを CloudFormation で管理できる。
✅ E.
SCP（サービスコントロールポリシー）でアカウントの操作制限を実装
- SCP により、命名規則違反やテンプレート外の操作を事前にブロック可能。
- 例：
dynamodb:CreateTableを"Resource": "arn:aws:dynamodb:::table/approved-*"のみに許可など。 - Organizationsレベルの強制力を活かせる。
■ 不正解の選択肢の理由
| 選択肢 | 理由 |
|---|---|
| A. | AWS Config は違反検出（後追い）ツール。事前ブロックやCloudFormation強制は不可能。 |
| B. | アクセス許可の境界は IAM エンティティ単位。組織レベルの強制ポリシーには不向き。また、CloudFormation経由での強制や命名規則制御が困難。 |
| D. | テンプレートがアプリケーションアカウント発では、要件である「管理された CloudFormation 利用」に反する。また準拠性確認だけでは制限を強制できない。 |
■ SCS試験で押さえておくべきポイント
- ✅ SCP（Service Control Policy） は、Organizations配下アカウントのアクセス制御に用いる。IAM より上位の制御。
- ✅ CloudFormation StackSets は、マルチアカウント環境で統一されたインフラデプロイを実現。
- ❌ Config は「構成監視と違反検知」の用途。強制制御には不向き。
- ❌ アクセス許可の境界は IAM の補助ツールで、組織全体の強制ポリシーには不十分。
この問題は SCPとStackSetsの使い分けを問う良問です。理解を深めるには、実際に StackSets を使って複数アカウントへテンプレート配布する流れを試してみるのがおすすめです。
