Microsoft Securityの「Breaking the code: Multi-stage ‘code of conduct’ phishing campaign leads to AiTM token compromise」で最初に押さえるべき結論は、これは単なるパスワード盗難ではなく、認証済みセッションのトークンを狙うAiTMフィッシングへの警戒強化が必要な事案だという点です。
攻撃者は「行動規範違反」「社内コンプライアンス調査」「懲戒関連のケースログ」といった業務上無視しにくい文面を使い、PDF、CAPTCHA、中間ページ、Microsoftサインイン画面へと段階的に誘導します。Microsoftによると、この攻撃は2026年4月14日から16日にかけて、26カ国・13,000以上の組織・35,000人超のユーザーを対象に観測されました。主な標的は米国ですが、Microsoft 365を利用する日本企業にとっても、メール防御・MFA・条件付きアクセス・トークン失効対応を見直すべき実例です。(Microsoft)
Microsoft Securityの今回の発表で何が変わったのか
今回のMicrosoft Securityの発表は、Microsoft製品の脆弱性修正やバージョンアップ通知ではありません。重要なのは、フィッシング対策の前提を更新する必要があるという点です。
従来は「怪しいリンクを踏まない」「MFAを有効にする」「差出人ドメインを確認する」といった対策が中心でした。しかし今回のキャンペーンでは、正規のメール配信サービス、攻撃者管理ドメインからの認証済みメール、CAPTCHA、企業向けに整えられたHTMLメール、PDF添付、正規のMicrosoftサインイン体験を組み合わせています。Microsoftは、最終的にAiTMの流れで認証セッションをプロキシし、認証トークンを取得できる可能性があると説明しています。(Microsoft)
| これまでの見方 | 今回見直すべき点 | 実務での対応 |
|---|---|---|
| MFAを有効にしていれば安全 | フィッシング耐性のないMFAはAiTMで回避される可能性がある | 管理者・経理・役員からフィッシング耐性のあるMFAへ移行 |
| SPF/DKIM/DMARCを通過していれば安全 | 攻撃者管理ドメインから認証済みメールが送られる場合がある | 送信者認証だけでなく本文、URL、添付、クリック後の挙動を見る |
| 添付ファイルにマルウェアがなければ安全 | PDF内リンクから認証情報窃取へ進む | Safe AttachmentsとSafe Linksを併用する |
| 不審メールを削除すれば完了 | クリック済みユーザーのトークン侵害を確認する必要がある | URLクリック、サインインリスク、セッション失効を確認 |
| パスワードリセットで復旧できる | トークンやセッションが残る場合がある | パスワード変更に加え、セッション失効・メールボックス確認を行う |
攻撃の流れ：Code of Conductを装った多段階フィッシング
今回の攻撃は、「社内の行動規範レビュー」や「コンプライアンス違反のケースログ」を装う点が特徴です。受信者に心理的な圧力をかけ、通常なら慎重なユーザーでも「早く確認しなければ」と感じやすいテーマが使われています。
Microsoftの分析では、メールの表示名として「Internal Regulatory COC」「Workforce Communications」「Team Conduct Report」などが使われ、件名にも内部調査や非準拠ケースを連想させる文言が含まれていました。本文には組織固有の名称が埋め込まれ、「承認済みの内部チャネルから発行された」「安全に確認済み」といった信頼感を補強する表現も使われていました。(Microsoft)
| 段階 | ユーザーに見える内容 | 管理者が見るべきポイント |
|---|---|---|
| メール受信 | 行動規範、社内規定、懲戒、コンプライアンス調査を装う通知 | 件名、表示名、差出人、添付PDF、受信者数 |
| PDF添付 | 「ケース資料を確認」などのリンク付きPDF | Safe Attachmentsの判定、添付ファイル名、ハッシュ |
| CAPTCHA | Cloudflare CAPTCHA風の確認画面 | 自動解析回避、ユーザークリック後のURL遷移 |
| 中間ページ | 「暗号化された資料の確認には認証が必要」と説明 | 複数ドメインへのリダイレクト、端末種別ごとの遷移 |
| Microsoftサインイン | 「Sign in with Microsoft」から認証へ誘導 | AiTMによるセッションプロキシ、トークン窃取の可能性 |
特に注意したいのは、攻撃が最初から偽のログイン画面だけで完結していないことです。CAPTCHAや中間ページを挟むことで、ユーザーには「正式な確認手順」に見えやすくなり、自動解析やサンドボックス検知を避ける効果も期待できます。Microsoftも、このCAPTCHAが自動分析を妨げるゲートとして機能していた可能性に触れています。(Microsoft)
AiTMトークン侵害が危険な理由
AiTMは「Adversary-in-the-middle」の略で、攻撃者がユーザーと正規サービスの間に入り、認証の流れを中継する攻撃です。ユーザーが本物のMicrosoft認証に見える画面でサインインしても、その認証セッションが攻撃者側でプロキシされると、パスワードだけでなく認証済みのセッショントークンが狙われます。
この点が通常の資格情報フィッシングより厄介です。単にパスワードを盗む攻撃であれば、MFAが追加の防御になります。しかしAiTMでは、ユーザーがMFAを完了した後のセッション情報が悪用される可能性があるため、SMS、メールOTP、通常の承認型アプリなど、フィッシング耐性のないMFAだけでは十分とは言えません。Microsoft Entra IDの認証ガイダンスでも、Windows Hello for Business、パスキー、FIDO2セキュリティキー、証明書ベース認証などのフィッシング耐性のある方法が推奨されています。(Microsoft Learn)
つまり、今回の発表から得るべき実務上の教訓は「MFAを入れているか」ではなく、どのMFA方式を、どのアカウントに、どの条件で要求しているかを確認することです。
影響を受けやすい組織と担当者
Microsoftの観測では、今回のキャンペーンは特定業界だけに絞られていません。影響が目立った業界として、Healthcare & life sciences、Financial services、Professional services、Technology & softwareが挙げられています。対象国の多くは米国ですが、攻撃手法そのものはMicrosoft 365を利用する組織全般に転用しやすいものです。(Microsoft)
日本企業で特に確認すべきなのは、次のような環境です。
| 対象 | 優先して確認すべき理由 |
|---|---|
| Microsoft 365 / Exchange Onlineを利用している組織 | メール経由で誘導され、Microsoftアカウント認証が狙われる |
| Microsoft Defender for Office 365を利用している組織 | Safe Links、Safe Attachments、ZAP、Threat Explorerの設定確認が必要 |
| Microsoft Entra IDでMFAを運用している組織 | MFA方式がフィッシング耐性を持つか確認する必要がある |
| 管理者、経理、人事、法務、役員アカウント | 社内規程・コンプライアンス系の誘導に反応しやすく、侵害時の影響が大きい |
| SOC / CSIRTを持つ組織 | メール、URLクリック、サインインリスク、トークン失効を横断して確認する必要がある |
今回の攻撃は、Microsoftの認証基盤に脆弱性があるという話ではありません。問題は、ユーザーが正規の認証フローに見える手順へ誘導され、そのセッションを攻撃者が悪用する点にあります。そのため、パッチ適用だけで終わる対応ではなく、ID、メール、エンドポイント、ユーザー教育をまたいだ確認が必要です。
今日中に確認すべき初動対応
まず行うべきは、「自社に該当メールが届いていないか」「クリックしたユーザーがいないか」「その後に不審なサインインがないか」の確認です。
Microsoft Defender XDRを利用している場合は、Advanced Huntingで関連メールを検索できます。Microsoftのブログでは、今回のキャンペーンで使われた送信元メールアドレスをもとにEmailEventsを検索する例が示されています。EmailEventsには、送信者、受信者、件名、配信場所、検出方法、認証詳細など、メール処理に関する情報が含まれます。(Microsoft) (Microsoft Learn)
EmailEvents
| where Timestamp between (datetime(2026-04-14) .. datetime(2026-04-17))
| where SenderMailFromAddress in~ (
"[email protected]",
"[email protected]",
"[email protected]",
"[email protected]",
"[email protected]"
)
| project Timestamp,
RecipientEmailAddress,
Subject,
SenderFromAddress,
SenderMailFromAddress,
DeliveryAction,
DeliveryLocation,
LatestDeliveryAction,
LatestDeliveryLocation,
NetworkMessageIdURLクリックの確認には、Safe Linksのクリック情報を持つUrlClickEventsが役立ちます。このテーブルには、メール、Microsoft Teams、Office 365アプリ内のリンククリックに関する情報が記録されます。ただし、Defender for Office 365をMicrosoft Defender XDRに展開していない場合、該当テーブルを使ったクエリは結果を返さないことがあります。(Microsoft Learn)
let suspiciousDomains = dynamic([
"compliance-protectionoutlook.de",
"acceptable-use-policy-calendly.de"
]);
UrlClickEvents
| where Timestamp between (datetime(2026-04-14) .. datetime(2026-04-17))
| where Url has_any (suspiciousDomains)
| project Timestamp,
AccountUpn,
Url,
ActionType,
Workload,
IPAddress,
IsClickedThrough,
UrlChain検索で一致が出た場合は、メールを削除して終わりにしないでください。クリック済みユーザーについて、Microsoft Entra IDのサインインログ、ID Protectionのリスク、Defender XDRのインシデント、Defender for Cloud Appsの不可能移動などを確認します。Microsoftの検出例でも、Microsoft Defender for Office 365では悪性URLクリックや配信後削除、Microsoft Entra ID ProtectionではAnomalous TokenやUnfamiliar sign-in properties、Defender for Cloud AppsではImpossible travel activityが関連する検出として挙げられています。(Microsoft)
代表的なIOC
Microsoftが公開しているIOCは、初動調査の起点として有用です。ただし、攻撃者はドメインや送信元を変える可能性があるため、IOC一致だけを安全判断の基準にしないでください。件名、文面、PDF添付、CAPTCHA遷移、Microsoftサインイン誘導などの攻撃パターンも合わせて見ます。(Microsoft)
| 種別 | IOC |
|---|---|
| 悪性コンテンツをホストしたドメイン | compliance-protectionoutlook[.]de |
| 悪性コンテンツをホストしたドメイン | acceptable-use-policy-calendly[.]de |
| 送信元ドメイン | cocinternal[.]com |
| 送信元ドメイン | gadellinet[.]com |
| 送信元ドメイン | harteprn[.]com |
| 送信元メールアドレス | cocpostmaster[@]cocinternal[.]com |
| 送信元メールアドレス | nationaladmin[@]gadellinet[.]com |
| 送信元メールアドレス | nationalintegrity[@]harteprn[.]com |
| 送信元メールアドレス | m365premiumcommunications[@]cocinternal[.]com |
| 送信元メールアドレス | documentviewer[@]na[.]businesshellosign[.]de |
| PDFファイル名 | Awareness Case Log File – Monday 13th, April 2026.pdf |
| PDFファイル名 | Awareness Case Log File – Tuesday 14th, April 2026.pdf |
| PDFファイル名 | Awareness Case Log File – Wednesday 15th, April 2026.pdf |
ハッシュ値による確認も可能です。
5DB1ECBBB2C90C51D81BDA138D4300B90EA5EB2885CCE1BD921D692214AECBC6
B5A3346082AC566B4494E6175F1CD9873B64ABE6C902DB49BD4E8088876C9EAD
11420D6D693BF8B19195E6B98FEDD03B9BCBC770B6988BC64CB788BFABE1A49DMicrosoft Defender for Office 365で確認する設定
Microsoftは、Exchange Online ProtectionとMicrosoft Defender for Office 365の推奨設定を確認するよう案内しています。Microsoft Learnの推奨設定では、StandardとStrictの2段階が示され、Preset security policiesを使って適用できると説明されています。また、脅威ポリシーを調整する前に、SPF、DKIM、DMARCなど送信ドメイン認証の設定を確認することも推奨されています。(Microsoft Learn)
Safe Linksを有効化し、対象範囲を確認する
Safe Linksは、フィッシングなどに使われる悪性リンクに対して、メールフロー時のURLスキャンや書き換え、クリック時の検証を行います。メールだけでなく、Microsoft Teamsや対応するOfficeアプリ内のリンクにも保護を適用できます。(Microsoft Learn)
確認すべきポイントは次の通りです。
| 確認項目 | 見るべきポイント |
|---|---|
| Safe Linksポリシー | 全ユーザー、特に管理者・経理・人事・法務・役員に適用されているか |
| Officeアプリ保護 | Word、PowerPoint、Excel内リンクにも保護が及ぶ設定か |
| Teams保護 | Teamsチャットやチャネル内リンクも対象か |
| 内部メール | 内部ユーザー間のメールでもリンク保護が必要な業務か |
| 他社URLラッピングサービス | Defender for Office 365の処理を妨げていないか |
注意点として、別サービスでURLを先にラップしている場合、Safe Linksの処理が妨げられる可能性があります。また、すべてのメール形式や場所が同じように保護されるわけではないため、ポリシーの適用範囲を実際の業務アプリに合わせて確認することが重要です。(Microsoft Learn)
Safe AttachmentsでPDF添付の扱いを確認する
今回の攻撃では、PDF添付からリンクへ誘導する流れが使われました。Safe Attachmentsは、添付ファイルを仮想環境で検査し、マルウェア、ランサムウェア、フィッシングに関連する有害な添付ファイルを配信前に確認する追加防御です。Microsoft Learnでは、Safe Attachmentsのスキャンは通常15分以内に完了するものの、処理に時間がかかる場合があると説明されています。(Microsoft Learn)
実務では、単に「添付ファイルのマルウェア検査が有効か」だけでなく、PDF内リンクからの誘導を前提に、Safe Linksとの組み合わせで確認してください。
ZAPで配信後の悪性メールを回収できるか確認する
Zero-hour auto purge、通称ZAPは、すでにメールボックスへ配信された悪性のフィッシング、スパム、マルウェアメールを後から検出して無力化する機能です。Microsoft Learnでは、ZAPが最後の48時間に配信されたメールを対象に検索し、ユーザーに通知せず自動処理することが説明されています。(Microsoft Learn)
ZAPを確認する際は、次の観点で見てください。
| 確認項目 | 判断基準 |
|---|---|
| ZAP for phishing | 有効になっているか |
| フィッシング判定時のアクション | 迷惑メール移動ではなく検疫が必要なリスクか |
| 高信頼度フィッシング | ユーザーが自分で解除できない運用になっているか |
| 48時間を超えたメール | ZAP任せにせず、Threat Explorerや手動パージを検討する |
| 通報後対応 | ユーザー通報からSOC確認、検索、削除までの手順があるか |
ZAPは強力ですが、万能ではありません。特に、ユーザーがすでにクリックしている場合は、メールの削除だけでは不十分です。クリック履歴、サインイン履歴、トークン失効まで確認する必要があります。
Microsoft Entra IDでMFAを見直す
今回のMicrosoft Securityの発表で最も重要な移行ポイントは、フィッシング耐性のあるMFAへの段階移行です。
Microsoft Entra IDでは、Windows Hello for Business、Platform Credential for macOS、FIDO2パスキー、FIDO2セキュリティキー、Microsoft Authenticatorのパスキー、証明書ベース認証などがフィッシング耐性のある認証方法として挙げられています。(Microsoft Learn)
特に管理者アカウントは優先度が高いです。Microsoft Learnでは、Global Administrator、Security Administrator、Exchange Administrator、Conditional Access Administrator、Privileged Role Administratorなどの管理者ロールに対し、フィッシング耐性のあるMFAを要求することが推奨されています。(Microsoft Learn)
管理者ロールから移行する手順
| 手順 | 作業内容 | 注意点 |
|---|---|---|
| 現状把握 | 管理者が使っているMFA方式を棚卸しする | SMS、音声、メールOTP、承認型アプリのみのユーザーを洗い出す |
| 認証方法登録 | FIDO2キー、パスキー、Windows Hello for Businessなどを登録する | ポリシー適用前に登録を完了させる |
| 緊急アクセス設計 | break-glassアカウントを条件付きアクセスの除外に含める | 除外管理を怠るとテナントから締め出される可能性がある |
| レポート専用で検証 | 条件付きアクセスをReport-onlyで影響確認する | 業務アプリや管理ポータルへの影響を見る |
| 段階適用 | 管理者、経理、人事、役員、一般ユーザーへ広げる | 一括適用よりも業務影響を抑えやすい |
Microsoft Learnでも、フィッシング耐性のあるMFAポリシーを作る前に、管理者が適切な方法を登録していないとテナントからロックアウトされるリスクがあると注意喚起されています。いきなり本番適用せず、Report-onlyで確認してから有効化するのが安全です。(Microsoft Learn)
トークン侵害が疑われる場合の復旧対応
AiTMが疑われる場合、パスワードリセットだけで復旧完了と判断しないでください。Microsoft Entra IDでは、アクセストークンやリフレッシュトークン、アプリケーション側のセッショントークンの仕組みが異なります。Microsoft Learnでは、Microsoft Entra IDが発行するアクセストークンの既定有効期間は1時間であり、アプリケーションが独自に発行したセッショントークンは、そのアプリケーション側のポリシーでアクセスを制御すると説明されています。(Microsoft Learn)
トークン侵害や不正サインインが疑われる場合は、次の順番で対応します。
| 優先度 | 対応 | 目的 |
|---|---|---|
| 高 | 影響ユーザーを一時的にブロックまたは無効化 | 攻撃者の継続アクセスを止める |
| 高 | パスワードをリセットする | 盗まれた資格情報の再利用を防ぐ |
| 高 | セッションを取り消し、リフレッシュトークンを失効させる | 既存セッションの継続利用を抑止する |
| 高 | MFA再登録を要求する | 攻撃者が登録した認証方法を排除する |
| 中 | メールボックスルール、転送設定、署名、送信済みメールを確認する | BECや永続化の痕跡を確認する |
| 中 | OneDrive、SharePoint、Teams、管理操作のログを確認する | データアクセスや横展開を確認する |
| 中 | 影響範囲をインシデントとして記録する | 再発防止と監査に備える |
Microsoft Defender for Office 365の侵害メールアカウント対応ガイドでは、攻撃者がアカウントにアクセスすると、Microsoft 365メールボックス、SharePoint、OneDriveにアクセスできる可能性があるため、影響アカウントと関連サービスを中心に調査する必要があると説明されています。また、疑わしいInboxルール、外部転送、送信済み・削除済みメール、連絡先情報の変更などが侵害の兆候として挙げられています。(Microsoft Learn)
Microsoft Defender for Endpointとブラウザ側の確認
Microsoftは、Microsoft Defender for EndpointのNetwork protectionを有効にすることも推奨しています。Network protectionは、ユーザーが任意のアプリケーションからフィッシング、エクスプロイト、その他の悪性コンテンツをホストする危険なドメインへアクセスすることを防ぐ機能です。監査モードで事前にブロック影響を確認してから有効化できます。(Microsoft Learn)
運用上は、次の順番で進めると失敗しにくくなります。
| フェーズ | 作業 |
|---|---|
| 監査 | 監査モードで、どのアプリや端末がブロック対象になりそうか確認する |
| 除外整理 | 業務上必要な通信と危険な通信を切り分ける |
| 限定適用 | IT部門、管理者端末、パイロット部門から有効化する |
| 全社展開 | IntuneやDefenderポリシーで段階展開する |
| 監視 | ブロックログ、ユーザー問い合わせ、業務影響を確認する |
Microsoft EdgeやSmartScreenをサポートするブラウザの利用も、フィッシングサイトや詐欺サイトのブロックに役立ちます。ただし、ブラウザだけに頼るのではなく、メール、ID、エンドポイントの防御を組み合わせることが前提です。
Microsoft Defender XDRで検出と封じ込めを強化する
今回の攻撃のように、メール、URL、ID、クラウドアプリがつながる事案では、個別製品のアラートだけを見ると全体像を見落としやすくなります。
Microsoft Defender XDRのAutomatic attack disruptionは、メール、ID、エンドポイント、アプリなど複数のシグナルを相関し、攻撃進行中に侵害資産を自動封じ込めする機能です。Microsoft Learnでは、攻撃の横展開を早期に制限し、セキュリティチームが完全な復旧を行う時間を確保することを目的としていると説明されています。(Microsoft Learn)
ただし、自動封じ込めを有効にしていても、SOC側で確認すべき項目は残ります。
| 確認項目 | 理由 |
|---|---|
| Defender XDRのインシデント相関 | メール、クリック、サインイン、端末のつながりを見る |
| Entra ID Protectionのリスク | Anomalous Tokenや不審なサインインを確認する |
| Defender for Cloud Apps | Impossible travelやSaaS操作の異常を確認する |
| Sentinel連携 | 複数ログを長期保管し、横断調査する |
| ユーザー確認 | 本人がクリックやサインインを認識しているか確認する |
Microsoft Entra ID Protectionの調査ガイドでも、リスク調査ではサインインログを確認し、アプリ、デバイス、場所、IPアドレス、ユーザーエージェントなどを見て、通常の行動かどうかを判断することが推奨されています。攻撃者がユーザーになりすませる疑いがある場合は、パスワードリセット、MFA、ブロック、リフレッシュトークンとアクセストークンの失効が必要です。(Microsoft Learn)
社内教育で伝えるべきポイント
今回の攻撃は、技術的な防御だけでは防ぎきれません。特に「Code of Conduct」「内部調査」「懲戒」「コンプライアンス違反」といったテーマは、受信者が焦りや不安を感じやすく、確認を急ぎがちです。
ユーザー教育では、単に「怪しいメールに注意」と伝えるより、具体的な行動基準を用意した方が効果的です。
| ユーザーに伝える内容 | 具体例 |
|---|---|
| 急かす社内規程メールは確認する | 「24時間以内に確認」「非準拠ケース」「懲戒資料」など |
| PDF内リンクからサインインしない | 添付PDFの「Review Case Materials」などから直接ログインしない |
| CAPTCHAがあっても安全とは限らない | CAPTCHAは正規サイトの証明ではない |
| Microsoftサインインに見えても油断しない | サインイン前に業務上の正規導線か確認する |
| 不安な場合は別経路で確認する | Teams、電話、社内ポータルなど、既知の経路で確認する |
| 報告をためらわない | クリック後でも早く報告すれば被害を抑えられる |
人事、法務、コンプライアンス部門にも協力してもらい、社内の正式な通知ルールを明確にしておくことが重要です。たとえば「懲戒・行動規範・コンプライアンス関連の正式通知は、必ず社内ポータルにも掲載する」「メール添付PDFから直接サインインさせない」といったルールがあると、ユーザーが判断しやすくなります。
失敗しやすい対応と回避策
MFAを有効にしているだけで安心する
MFAは重要ですが、方式によって耐性が異なります。SMS、音声、メールOTP、単純な承認型アプリは、パスワードのみより強固でも、AiTM対策としては限界があります。管理者や高リスク部門から、フィッシング耐性のある認証へ移行してください。
IOCブロックだけで終わらせる
公開IOCは調査の入口です。攻撃者はドメイン、差出人、PDF名を変える可能性があります。行動規範、内部調査、CAPTCHA、PDF内リンク、Microsoftサインイン誘導といった攻撃パターンに着目する必要があります。
メール削除後にクリック済みユーザーを見ない
不審メールを削除しても、すでにクリックし、認証が完了していればアカウント侵害が進んでいる可能性があります。UrlClickEvents、サインインログ、ID Protection、Defender XDRインシデントを確認してください。
パスワードリセットだけで復旧完了とする
AiTMではトークンやセッションが問題になります。パスワード変更に加えて、セッション失効、MFA再登録、メールボックスルール、転送設定、OAuthアプリ同意、サインイン履歴まで確認する必要があります。
条件付きアクセスをいきなり本番適用する
フィッシング耐性のあるMFAをいきなり全管理者に強制すると、認証方法未登録のユーザーが管理ポータルへ入れなくなる可能性があります。break-glassアカウントを設計し、Report-onlyで影響を確認してから段階適用してください。
次に取るべき行動
今回のMicrosoft Securityの発表を受けて、最初にやるべきことは明確です。
まず、Microsoft Defender XDRまたはThreat Explorerで、公開IOC、類似件名、PDF添付、URLクリックを確認します。次に、クリック済みユーザーがいれば、Microsoft Entra IDのサインインログ、ID Protection、Defender XDRインシデントを確認し、必要に応じてアカウントブロック、パスワードリセット、セッション失効、MFA再登録を実施します。
並行して、Defender for Office 365のSafe Links、Safe Attachments、ZAP、推奨ポリシーを確認し、管理者ロールからフィッシング耐性のあるMFAへ移行してください。最後に、人事・法務・コンプライアンス通知の正規ルールを社内に明示し、「行動規範」「内部調査」「懲戒」などを装うメールを受け取ったときの確認経路を整備します。
今回の攻撃は、特殊なマルウェアよりも、ユーザー心理、正規サービス、認証の隙間を突く攻撃です。Microsoft Securityの情報を単なる脅威ニュースとして読むのではなく、自社のメール防御、ID保護、MFA移行、インシデント対応手順を更新するきっかけにしてください。
コメント