Microsoft Defenderの2026年4月更新で押さえるべき結論は、Microsoft SentinelをDefenderポータルへ移す作業は「画面の引っ越し」ではなく、SOC運用・権限・自動化・API連携・コンプライアンス確認を見直すプロジェクトだという点です。
2026年4月22日に更新されたMicrosoft公式ドキュメント「Transition your Microsoft Sentinel environment to the Defender portal」では、既存のMicrosoft Sentinel環境をAzure portalからMicrosoft Defenderポータルへ移行する際の前提条件、運用上の差分、制限事項が整理されています。Microsoft SentinelはDefenderポータルでMicrosoft Defender XDRと組み合わせても、単独でも利用でき、SIEMとXDRを統合した運用体験を提供します。なお、Azure portalでのMicrosoft Sentinelサポートは2027年3月31日以降終了し、Defenderポータルでの利用に移行する方針が示されています。(Microsoft Learn)
この記事では、security admins、identity teams、compliance teamsが移行前に確認すべきポイントを、実務で使える判断基準に落とし込んで解説します。
Microsoft Defenderの最新動向: Transition Your Microsoft Sentinel Environment to the Defender Portalで何が変わったか
今回の更新で重要なのは、Microsoft SentinelをDefenderポータルで扱う際の「できること」だけでなく、既存運用のどこを修正しないと失敗しやすいかが明確になっていることです。
Microsoft公式ドキュメントでは、既存のMicrosoft SentinelワークスペースをDefenderポータルへ移行する利用者向けに、計画、権限、データ保管、自動化、分析ルール、API、ハンティング、インシデント運用の差分が説明されています。移行自体に追加コストは発生せず、顧客は従来どおりSentinelの利用量に応じて課金されるとされています。(Microsoft Learn)
特に注意すべき点は、次の3つです。
- インシデントとアラートの相関はDefender XDRエンジンが中心になる
- 自動化ルールやプレイブックは、条件・遅延・未対応操作の見直しが必要になる
- IdentityInfo、APIレスポンス、データ保持、CMKなどはセキュリティ運用だけでなく監査・コンプライアンスにも影響する
つまり、移行担当者は「Defenderポータルに接続できるか」だけで判断してはいけません。接続後にSOCの一次対応、チケット連携、KQLクエリ、アクセス制御、証跡管理が期待どおり動くかまで検証する必要があります。
2026年4月更新で確認すべき主なポイント
2026年4月22日更新版で実務上重要な内容を整理すると、次のようになります。
| 確認領域 | 更新内容の要点 | 実務での影響 |
|---|---|---|
| 移行対象 | 既存のMicrosoft Sentinel有効化済みワークスペースをDefenderポータルへ移行する利用者向け | 既存SOC運用を前提に移行計画を作る必要がある |
| コスト | Defenderポータルへの移行自体に追加コストはない | ライセンス追加ではなく、運用変更として計画できる |
| データ収集 | 既存コネクタやLog Analytics基盤のデータ取り込みは基本的に維持される | ただしDefender XDRコネクタやスキーマ差分は確認が必要 |
| データ保管・プライバシー | Azure portal利用時とDefenderポータル利用時で適用されるポリシーが異なる | compliance teamsはデータ所在地、保持、共有の再確認が必要 |
| CMK | 既存ログやSentinelコンテンツはCMK暗号化が継続するが、オンボード後のアラート・インシデントはCMK暗号化されない | 規制業種では監査資料の更新が必要 |
| 分析ルール | Sentinelの分析ルールはDefenderポータルでも利用できるが、相関・マージはDefender XDR側が制御する | インシデント件数や名称が変わる可能性がある |
| Fusion | Defenderポータル移行後、Fusion分析ルールは無効化される | 相関機能はDefender XDRの機能に置き換わる |
| 自動化 | Descriptionフィールド、incident title条件、手動プレイブック実行などに注意が必要 | 既存プレイブックが動かない、または意図しない対象に動く可能性がある |
| API | 統合インシデント・アラート連携ではMicrosoft Graph REST APIの利用が推奨される | 外部チケット、SOAR、独自ダッシュボードの改修が必要になる場合がある |
| IdentityInfo | Advanced Hunting側のIdentityInfoはSentinel Log Analytics側と一部スキーマが異なる | identity teamsはKQL、カスタム検出、RBAC要件を再確認する必要がある |
この表で分かるように、移行の中心はポータル操作ではなく、検知から対応までの一連の運用フローの再設計です。
移行前にまず確認すべき前提条件
Microsoft DefenderポータルへMicrosoft Sentinelを移行する前に、最初に確認すべきなのは「どのワークスペースを、どの権限で、どの順番で移行するか」です。
Microsoft公式ドキュメントでは、既存のMicrosoft Sentinelワークスペースを持つ顧客がDefenderポータルへ移行するケースを対象にしています。新規顧客で、サブスクリプションのOwnerまたはUser access administrator権限でオンボードした場合、ワークスペースは自動的にDefenderポータルへオンボードされると説明されています。(Microsoft Learn)
security adminsが確認すべきこと
security adminsは、移行前に次の棚卸しを行うべきです。
| 確認項目 | 見るべきポイント |
|---|---|
| ワークスペース一覧 | 本番、検証、地域別、部門別、MSSP管理対象を分けて整理する |
| データコネクタ | Defender製品、クラウド、ID、メール、サードパーティ製品の接続状態を確認する |
| 分析ルール | インシデント作成の有無、アラートのみのルール、Fusion依存を確認する |
| 自動化ルール | Description、incident title、provider、analytics rule nameを条件にしていないか確認する |
| プレイブック | 手動実行、チケット連携、承認フロー、外部通知の動作を確認する |
| API連携 | Microsoft Sentinel APIとMicrosoft Graph APIのどちらを使っているか確認する |
| SOC手順書 | Azure portal前提の画面名、対応順、エスカレーション条件を更新する |
特に重要なのは、アラートだけを生成し、インシデント作成をオフにしている分析ルールです。Microsoft公式ドキュメントでは、インシデント作成をオフにしてアラートのみをトリガーするMicrosoft Sentinel分析ルールのアラートは、Defenderポータルでは表示されないと説明されています。(Microsoft Learn)
identity teamsが確認すべきこと
identity teamsは、Microsoft Entra ID、Defender for Identity、ユーザーエンティティ、IdentityInfoテーブルに関わる影響を確認します。
Defenderポータルへオンボードすると、IdentityInfoテーブルはMicrosoft Defender Advanced HuntingとSentinel Log Analyticsワークスペースの両方で利用できます。ただし、Advanced Hunting側のIdentityInfoにはDefender XDRとMicrosoft Sentinelの統合フィールドが含まれ、一部フィールドは名前変更または非対応になるとされています。(Microsoft Learn)
実務では、次のクエリを重点的に見直します。
- ユーザーリスクやサインイン履歴を使ったカスタム検出
IdentityInfoをjoinしているKQL- VIPユーザー、管理者アカウント、退職者アカウントを抽出するクエリ
- ID情報をチケットやレポートに出力する自動化
- テーブルレベルRBACを前提にした閲覧制御
特に注意が必要なのはRBACです。Microsoft公式ドキュメントでは、Defenderポータルへの移行後、IdentityInfoテーブルはネイティブDefenderテーブルとなり、テーブルレベルRBACをサポートしないとされています。Azure portal側でIdentityInfoへのアクセスをテーブルレベルRBACで制限している組織は、移行後に同じ制御が維持されると考えない方が安全です。(Microsoft Learn)
compliance teamsが確認すべきこと
compliance teamsは、移行によって「データがどこに保存され、誰が見られ、どのように保持されるか」を再確認する必要があります。
Microsoft公式ドキュメントでは、Azure portal利用時はMicrosoft Sentinelのデータ保管・処理・保持・共有ポリシーが適用され、Defenderポータル利用時はMicrosoft Defender XDRのポリシーが適用されると説明されています。(Microsoft Learn)
また、Customer-managed keys、いわゆるCMKを使っている環境では注意が必要です。オンボード前にCMKを有効にしていた場合、ワークスペース内のログデータや分析ルール、オートメーションルールなどのSentinelコンテンツはCMK暗号化が継続します。一方で、オンボード後のアラートとインシデントはCMK暗号化されません。さらに、Sentinel data lakeに保存されるデータではCMKが完全にはサポートされず、Microsoft-managed keysで暗号化されるとされています。(Microsoft Learn)
規制業種やグローバル企業では、次の資料を更新しておくと監査対応がスムーズです。
| 更新すべき資料 | 理由 |
|---|---|
| データフロー図 | Azure portal中心からDefenderポータル中心の運用に変わるため |
| データ保持方針 | 適用ポリシーや保存先の説明が変わる可能性があるため |
| 暗号化方式の説明 | CMK対象外になるアラート・インシデントを明記するため |
| アクセス制御設計書 | IdentityInfoや統合インシデントの閲覧範囲を確認するため |
| 監査ログ確認手順 | SOC作業と管理操作の証跡確認場所が変わるため |
データコネクタは基本継続。ただし「見え方」と「重複」に注意
Microsoft SentinelをMicrosoft Defenderに統合しても、既存のデータ収集アーキテクチャやテレメトリの流れは基本的に維持されます。既存のコネクタは中断なく動作し、Log Analyticsの観点でも取り込みパイプラインやデータスキーマに変更はないと説明されています。(Microsoft Learn)
ただし、実務上は「接続が継続する」だけでは不十分です。Defender製品に関するアラートはMicrosoft Defender XDR connectorから直接ストリームされるため、該当ワークスペースでインシデントとアラートが有効になっているか確認する必要があります。また、コネクタの変更により一部アラートでスキーマ差分が生じる可能性があります。(Microsoft Learn)
Defender for Cloud連携では重複イベントに注意
Defender for Cloudを利用している場合は、コネクタの種類によって対応が変わります。
| 利用中のコネクタ | 必要な確認 |
|---|---|
| Tenant-based Defender for Cloud connector | 重複イベントや重複アラートを防ぐ設定を確認する |
| Legacy subscription-based connector | Microsoft Defenderへのインシデント・アラート同期をオプトアウトする必要があるか確認する |
移行テストでは、単にアラートが来るかを見るのではなく、同じ検知が二重にインシデント化されていないかを確認しましょう。重複があると、SOCの一次対応件数が増え、SLAやMTTRの指標が実態より悪化します。
Defenderポータルでは一部コネクタが表示されない
Defenderポータルへオンボード後、統合セキュリティ運用で使われる一部のデータコネクタは、DefenderポータルのData connectorsページに表示されません。Microsoft Defender for Endpoint、Microsoft Defender for Identity、Microsoft Defender for Cloud Apps、Microsoft Defender XDRなどが該当します。一方で、これらはAzure portal側のMicrosoft Sentinelでは引き続き一覧に表示されます。(Microsoft Learn)
運用担当者が「Defenderポータルに表示されないから切断された」と誤解しないよう、移行後の確認手順書に明記しておくことが重要です。
分析ルールとインシデント相関はDefender XDR中心に変わる
Microsoft Sentinelの分析ルールは、Defenderポータルでも作成、更新、管理できます。ウィザード、リポジトリ、Microsoft Sentinel APIを通じた管理も継続されます。(Microsoft Learn)
一方で、インシデントの相関やマージはDefender XDRエンジンが大きな役割を持つようになります。Microsoft公式ドキュメントでは、DefenderポータルではMicrosoft DefenderデータとSentinelに取り込まれたサードパーティデータの両方に対して相関が自動適用され、相関基準はDefenderポータルの内部ロジックに含まれると説明されています。(Microsoft Learn)
これは、SOC運用に大きな影響を与えます。
たとえば、Azure portal時代に「1つの分析ルールにつき1インシデント」として運用していた場合でも、Defenderポータルでは複数の関連アラートが同一インシデントにマージされる可能性があります。これにより攻撃ストーリーは把握しやすくなりますが、従来の集計指標やチケット運用とはズレが出る場合があります。
Fusion分析ルールは無効化されるが、相関機能が失われるわけではない
Azure portalのMicrosoft Sentinelでは、Fusion分析ルールがアラート相関に基づいてインシデントを作成していました。DefenderポータルへMicrosoft Sentinelをオンボードすると、このFusion分析ルールは無効化されます。ただし、相関機能そのものが失われるわけではなく、Defender XDRのインシデント作成・相関機能がその役割を置き換えます。(Microsoft Learn)
移行時には、Fusionルールを「有効に戻す」ことを目的にするのではなく、Defenderポータル側で生成されるインシデントがSOCの期待どおりにまとまっているかを確認しましょう。
自動化ルールとプレイブックは移行失敗が起きやすい
Microsoft Defenderポータル移行で最もトラブルが起きやすいのが、自動化ルールとプレイブックです。
Microsoft SentinelのプレイブックはAzure Logic Appsベースのワークフローですが、Defenderポータルで作業する場合、自動化ルールとプレイブックには複数の制限や変更点があります。(Microsoft Learn)
Descriptionフィールドを条件にしている自動化ルールは要注意
オンボード後、SecurityIncidentテーブルにはDescriptionフィールドが含まれなくなります。そのため、インシデント作成トリガーの条件にDescriptionを使っている自動化ルールは、移行後に動作しなくなります。また、ServiceNowのような外部チケットシステムと連携している場合、インシデント説明が欠落する可能性があります。(Microsoft Learn)
修正する場合は、Descriptionではなく次のような条件に置き換えるのが現実的です。
| 旧条件 | 置き換え候補 |
|---|---|
| Descriptionに特定文字列が含まれる | Analytics rule name |
| Incident titleが特定形式 | タグ、重大度、関連エンティティ |
| ProviderNameがAzure Sentinel | Defenderポータル移行後のProviderNameを前提に再設計 |
| 特定製品名をタイトルから判定 | serviceSource、productNameなどAPI側のフィールドを確認 |
incident titleを条件にする運用は避ける
Defenderポータルは独自の相関エンジンを使うため、既存インシデント名が変更される可能性があります。Microsoft公式ドキュメントでも、自動化ルールを正しく実行するために、インシデントタイトルを条件に使うのではなく、アラートを作成した分析ルール名やタグを使うことが推奨されています。(Microsoft Learn)
これは実務的にも妥当です。タイトルは人間にとって読みやすい表示名であり、安定した機械判定キーではありません。自動化の条件には、変更されにくいルール名、タグ、重大度、エンティティ種別を使いましょう。
実行遅延も手順書に入れておく
Defenderポータルでインシデントが作成または更新されてから自動化ルールが実行されるまで、最大10分程度かかる場合があります。また、Microsoft DefenderインシデントがMicrosoft Sentinelに表示されるまで最大5分程度かかる場合があり、その場合はプレイブックのトリガーも遅延します。(Microsoft Learn)
SOCの一次対応で「5分以内に自動チケット化」「即時Teams通知」などのSLAを置いている場合は、移行後の遅延を前提に運用基準を見直す必要があります。
API連携はMicrosoft Graph REST APIを前提に見直す
外部チケット、SOAR、独自ダッシュボード、監査レポートをAPIで連携している組織は、移行前に必ずAPIレスポンスを確認してください。
Microsoft公式ドキュメントでは、統合インシデントとアラートの操作にはMicrosoft Graph REST APIの利用が推奨されています。一方で、Microsoft Sentinel APIは分析ルールや自動化ルールなどのSentinelリソースに対する操作を引き続きサポートします。(Microsoft Learn)
つまり、移行後は次のように使い分けるのが基本です。
| 用途 | 推奨されるAPI |
|---|---|
| 統合インシデントの取得・更新 | Microsoft Graph REST API |
| 統合アラートの取得 | Microsoft Graph REST API |
| 高度なハンティング連携 | Microsoft Graph REST API |
| Sentinel分析ルールの管理 | Microsoft Sentinel API |
| Sentinel自動化ルールの管理 | Microsoft Sentinel API |
APIレスポンスで確認すべきフィールド
移行後は、レスポンス内のフィールドにも差分があります。
| 項目 | Azure portal中心の運用 | Defenderポータル中心の運用 |
|---|---|---|
| インシデントURL | incidentUrl | providerIncidentUrlが追加され、Defender側のリンクとして利用できる |
| アラート発行元 | alertProductNames | 取得時に?$expand=alertsが必要な場合がある |
| プロバイダー名 | providerName = Azure Sentinel | providerName = Microsoft XDR |
| サービスソース | なし | serviceSource |
| 検出ソース | なし | detectionSource |
| 製品名 | なし | productName |
外部チケットに「Azure Sentinel」と固定表示している場合や、providerNameで分岐処理している場合は、移行後に条件が一致しなくなる可能性があります。単体テストだけでなく、実際のインシデントを使ったエンドツーエンドテストを行いましょう。
Advanced HuntingとKQLは使えるが、同じ前提では扱わない
DefenderポータルへMicrosoft Sentinelをオンボードすると、既存のログテーブル、KQLクエリ、関数をAdvanced Huntingページで利用できます。また、インシデントに紐づくMicrosoft SentinelアラートはAlertInfoテーブルへ取り込まれ、Advanced Huntingから参照できます。(Microsoft Learn)
ただし、Azure portalのMicrosoft Sentinelとまったく同じ体験ではありません。たとえば、Advanced Huntingではブックマークがサポートされず、ブックマークはDefenderポータル内のMicrosoft Sentinel > Threat management > Huntingで扱う形になります。(Microsoft Learn)
カスタム検出で見直すべきKQLの例
次のようなクエリは、移行前後で実行結果を比較してください。
IdentityInfoを参照するクエリSecurityIncidentのDescriptionを参照するクエリ- インシデント名やProviderNameを条件にしているクエリ
- Defender XDRデータとSentinelデータをjoinするクエリ
- チケット起票や通知に使う要約フィールドを生成するクエリ
クエリの見直しでは、単にエラーが出ないかを見るだけでは不十分です。件数、重複、重大度、対象ユーザー、対象デバイスが期待どおりかを比較することが重要です。
インシデント運用は統合キューを前提に再設計する
Defenderポータルでは、製品横断の統合インシデントキューでセキュリティインシデントを管理します。Microsoft公式ドキュメントでは、統合インシデントキューにより、複数のセキュリティ領域にまたがるアラートを1つのビューで扱えるようになり、横展開を含む攻撃ストーリーを把握しやすくなると説明されています。(Microsoft Learn)
一方で、運用設計は変わります。従来は「ID担当」「エンドポイント担当」「クラウド担当」が別々のインシデントを処理していた組織でも、Defenderポータルでは1つの統合インシデントに複数領域のアラートがまとまる場合があります。
SOCで見直すべき担当分担
| 従来の運用 | 移行後に検討すべき運用 |
|---|---|
| 製品別に担当者を分ける | インシデント全体を見て一次判定し、専門担当へ切り分ける |
| ユーザー単位・端末単位で個別処理 | 攻撃ストーリー単位で関連エンティティを確認する |
| SentinelのインシデントだけをSOC対象にする | Defender XDR、Sentinel、サードパーティ由来の統合インシデントを対象にする |
| ルール名から対応手順を選ぶ | 重大度、攻撃段階、エンティティ、相関情報から対応手順を選ぶ |
統合キューは便利ですが、アナリストに求められる知識範囲は広がります。移行時には、ポータル操作の研修だけでなく、インシデントの読み方、エンティティページの使い方、関連アラートの見方まで含めた訓練が必要です。
複数ワークスペース・複数テナント環境の確認ポイント
グローバル企業やMSSPでは、単一ワークスペースだけでなく、複数ワークスペース・複数テナントの運用が一般的です。
Microsoft公式ドキュメントでは、Defenderポータルは複数テナントポータルを通じて、複数テナントにまたがる1つ以上のワークスペースをサポートすると説明されています。複数ワークスペース構成では、テナントごとに1つのプライマリワークスペースと複数のセカンダリワークスペースを接続し、各ワークスペースを個別にDefenderポータルへオンボードします。(Microsoft Learn)
注意すべきなのは、相関やデータ取り込みの中心がプライマリワークスペースになる点です。Microsoft公式ドキュメントでは、複数ワークスペースシナリオにおいて、プライマリワークスペースのアラートのみがMicrosoft Defender XDRデータと相関されると説明されています。(Microsoft Learn)
プライマリワークスペース選定の判断基準
| 判断基準 | 推奨される考え方 |
|---|---|
| SOCの主運用対象 | 24時間監視や一次対応の中心となるワークスペースを優先する |
| Defender XDRデータとの関連性 | エンドポイント、ID、メール、クラウドの主要データと相関させたい環境を選ぶ |
| 地域・法規制 | データ所在地や監査要件を満たせる構成にする |
| MSSP運用 | 顧客単位、地域単位、契約単位で責任範囲を明確にする |
| 自動化ルール | プライマリ変更で実行対象が変わらないか確認する |
複数ワークスペース環境では、まず検証用テナントまたは低リスクのワークスペースで相関、チケット連携、APIレスポンス、権限を確認し、その結果を本番展開に反映するのが安全です。
Defenderポータル移行でよくある失敗と対策
移行時の失敗は、技術的な接続ミスよりも「既存運用の前提が変わることを見落とす」ケースが多くなります。
| よくある失敗 | 原因 | 対策 |
|---|---|---|
| アラートが見えない | アラートのみ生成し、インシデント作成をオフにしている | 分析ルールのインシデント作成設定を確認する |
| 自動化ルールが動かない | Descriptionやincident titleを条件にしている | 分析ルール名、タグ、重大度など安定した条件へ変更する |
| チケット情報が欠落する | APIレスポンスやインシデント説明の差分を見落としている | providerIncidentUrlやproductNameなど新フィールドを確認する |
| インシデント件数が変わる | Defender XDRの相関・マージが働く | KPIやSLAの集計定義を見直す |
| 権限設計が崩れる | IdentityInfoのテーブルレベルRBACが維持されない | ID情報の閲覧範囲をDefender側で再設計する |
| コネクタが消えたと誤解する | DefenderポータルのData connectorsページに一部表示されない | Azure portal側の表示との差分を手順書に記載する |
| 手動プレイブックが使えない | アラートやエンティティへの手動実行がDefenderポータルで未対応 | 代替の実行手順やAzure portal側の運用を整理する |
特にグローバル環境では、地域ごとにSOC手順が微妙に異なることがあります。日本、北米、欧州で同じ移行チェックリストを使うだけでなく、データ所在地、監査要件、営業時間、エスカレーション先の違いを反映しましょう。
移行プロジェクトの進め方
Microsoft DefenderポータルへのMicrosoft Sentinel移行は、次の順序で進めると失敗を減らせます。
| フェーズ | 実施内容 | 成果物 |
|---|---|---|
| 現状把握 | ワークスペース、コネクタ、分析ルール、自動化、API、権限を棚卸しする | 移行対象一覧、影響範囲一覧 |
| 設計 | プライマリワークスペース、権限、データ保持、SOCフローを決める | 移行設計書、権限設計、データフロー図 |
| 検証 | 検証環境または低リスク環境でオンボードし、インシデント生成からチケット連携まで確認する | テスト結果、修正リスト |
| 改修 | 自動化ルール、プレイブック、API、KQL、手順書を修正する | 改修済みルール、更新済みRunbook |
| 展開 | 本番ワークスペースを段階的にDefenderポータルへ移行する | 移行記録、承認記録 |
| 定着 | SOCアナリスト、ID担当、監査担当へ教育し、KPIを再評価する | 教育資料、運用レポート |
移行前後で比較すべき指標は、単なるアラート件数ではありません。次のような運用品質の指標を見ると、移行後の問題を早く見つけられます。
- 重大度別インシデント件数
- 自動化ルールの実行成功率
- チケット作成までの時間
- 誤検知クローズ率
- インシデントマージ後の平均アラート数
- 担当者アサインまでの時間
- KQLクエリの実行結果件数
- ID関連インシデントの可視性
読者が次に取るべきアクション
Microsoft Defenderの2026年4月更新で最も重要なのは、Microsoft SentinelのDefenderポータル移行を「いつか対応する画面変更」として扱わないことです。2027年3月31日以降、Microsoft SentinelはAzure portalでサポートされず、Defenderポータルでの利用に移行する方針が公式に示されています。(Microsoft Learn)
まず着手すべきことは、次の5つです。
- すべてのMicrosoft Sentinelワークスペースを一覧化する
- 分析ルール、自動化ルール、プレイブック、API連携を棚卸しする
Description、incident title、providerName、IdentityInfoに依存する処理を洗い出す- compliance teamsとデータ保持、CMK、RBAC、監査証跡を確認する
- 検証環境でDefenderポータル移行後のインシデント生成からチケット連携までをテストする
Microsoft Defenderポータルへの移行は、正しく進めればSIEMとXDRを統合し、アラート相関、調査、対応を効率化できる大きな機会です。一方で、既存のSentinel運用をそのまま移すだけでは、自動化の停止、権限設計のズレ、チケット連携の欠落が起こりやすくなります。
まずは「接続できるか」ではなく、SOCが同じ品質で検知・判断・対応・報告できるかを基準に、移行チェックリストを作成するところから始めましょう。
コメント