isms クラウドセキュリティ認証の取得手順と費用感

2026年5月4日

丸山桃子

この記事のポイント

✓isms クラウドセキュリティ認証の意味
✓ISO/IEC 27017との関係
✓外注時の注意点を実務目線で解説します

isms クラウドセキュリティ認証は、クラウドサービスを提供する企業だけでなく、クラウドを利用して顧客データを扱う企業にも関係する認証です。SaaS、EC、受託開発、SNS運用、バックオフィス代行のように、業務のどこかでクラウドを使う事業者は、取引先から「セキュリティ体制を説明してください」と聞かれる場面が増えています。この記事では、ISMSとの違い、ISO/IEC 27017の位置づけ、取得のメリット、費用、進め方、外部人材に依頼する時の見極め方まで、実務で判断できる粒度で整理します。単に「取れば安心」という話ではなく、自社の取引条件、顧客の要求、運用負荷に照らして、いつ取得を検討すべきかが分かる内容にします。

isms クラウドセキュリティ認証の全体像

isms クラウドセキュリティ認証は、ISMS認証を土台に、クラウドサービス固有のリスク管理を追加で評価する仕組みです。一般的なISMSは、情報資産をどう守るかを組織全体のマネジメントシステムとして確認します。一方、クラウドセキュリティ認証では、クラウドサービスの提供者または利用者として、責任分界、設定管理、データ削除、仮想環境、監視、インシデント対応などをより具体的に見ます。

ISMSクラウドセキュリティ認証の認証基準は、JIPDECによる「JIP-ISMS517」となります。「JIP-ISMS517」は、ISO/IEC 27017:2015（JIS Q 27017：2016）に基づくISMSクラウドセキュリティ認証に関する要求事項です。

この引用の通り、認証基準はISO/IEC 27017に基づいています。ただし、ここで誤解しやすいのは、ISO/IEC 27017単体の認証を受けるというより、ISMS認証を前提にクラウドセキュリティの要求事項を追加で満たすという点です。つまり、まだISMSを取得していない会社が、いきなりクラウドセキュリティ認証だけを取得する流れではありません。まずISMSの適用範囲、情報資産管理、リスクアセスメント、内部監査、マネジメントレビューといった土台を整える必要があります。

ISMSとISO/IEC 27017の関係

ISMSは「会社として情報セキュリティを継続的に管理する仕組み」を問う認証です。ISO/IEC 27017は、そこにクラウドサービスの管理策を足すための実践的な規格です。たとえば、クラウド環境ではオンプレミスのように物理サーバーを直接触るわけではありません。AWS、Microsoft Azure、Google Cloud、各種SaaSなどを使う場合、どこまでがクラウド事業者の責任で、どこからが利用企業の責任なのかを明確にしないと、設定ミスやログ未確認が放置されます。

公的な制度情報を確認するなら、認証制度の概要はISMS適合性評価制度の公式サイトで確認できます。規格そのものの位置づけや認証機関を調べる際は、最初に公式情報を見てから審査機関やコンサル会社の資料を読むと、営業資料の表現に引っ張られにくくなります。また、個人情報や行政手続きに関わる制度と合わせて確認したい場合は、法令検索の入口としてe-Gov法令検索も押さえておくと便利です。

取得を検討すべき企業と検討が早すぎる企業

isms クラウドセキュリティ認証は、すべての事業者が今すぐ取得すべき認証ではありません。取得には文書整備、運用記録、審査対応、改善活動が必要で、社内の時間も外部費用もかかります。だからこそ、取得の目的が「なんとなく安心だから」だと途中で止まりやすいです。検討すべきタイミングは、取引先からセキュリティチェックシートの提出を求められる、官公庁や大企業案件の入札条件に認証が入る、クラウドサービスの提供者として顧客データを預かる、海外取引やBtoB SaaSの販売で第三者認証が信用材料になる、といった局面です。

アパレルECの支援現場でも、最初は「Instagramの投稿設計」や「商品説明文の改善」だけを見ればよかったのに、売上管理、顧客リスト、広告アカウント、配送データまで扱うようになると、急にセキュリティの話が現実になります。私の体験では、ブランド側がGoogleドライブで全データを共有し、退職者のアカウントが残ったままになっていたことがありました。見た目の世界は華やかでも、在庫表や顧客データの扱いはかなり泥くさい。そこを曖昧にしたまま外部委託を広げると、認証以前に日常運用で事故が起きます。

取得が向いているケース

取得が向いているのは、クラウドサービスを事業の中核にしている会社です。具体的には、SaaSを提供している、顧客の業務データをクラウド上で保管している、API連携で外部サービスとデータをやり取りしている、クラウド基盤上で受託システムを運用している、BtoB顧客から継続的にセキュリティ監査を受ける、といった会社です。特に大企業向けの営業では、機能や価格だけでなく、認証取得状況が初回の信用審査で見られます。

一方で、個人事業主や小規模チームが、まだ顧客データの取り扱いも少なく、取引先から具体的な要求も受けていない段階なら、いきなり認証取得に進むより先に、アクセス権限、NDA、バックアップ、端末管理、クラウド設定の棚卸しを優先した方が効果的です。認証はゴールではなく、日々の運用を外部から説明できる形にする手段です。土台がない状態で審査対応だけを外注すると、文書はできても現場が回りません。

検討が早すぎるケース

検討が早すぎるケースもあります。たとえば、まだサービス仕様が固まっていない、クラウド基盤が頻繁に変わる、担当者が兼務で情報セキュリティの責任者が不在、委託先管理が契約書ベースで整理されていない、といった状態です。この段階で認証取得プロジェクトを始めると、審査のための文書が現実の運用に追いつかず、形だけのルールになります。

ファッションECでたとえると、在庫管理のルールがないまま広告費だけ増やすのに近いです。表面上の流入は増えても、欠品、過剰在庫、返品対応で利益が崩れます。セキュリティ認証も同じで、認証マークを先に取りに行くより、どの情報を誰が持ち、どのクラウドに置き、どの権限で触れるのかを決める方が先です。結果として、その整理が認証取得時のリスクアセスメントや管理策選定にもつながります。

取得メリットは営業資料ではなく取引条件で考える

isms クラウドセキュリティ認証のメリットは、抽象的に言えば信用力向上、セキュリティ水準の可視化、社内統制の強化です。ただ、実務ではもっとシビアに考えるべきです。取得によって、どの商談の通過率が上がるのか、どの監査回答が短縮されるのか、どの契約条件を満たせるのか、どの事故リスクを下げられるのか。ここまで落とし込まないと、費用対効果が見えません。

特にBtoBのクラウドサービスでは、顧客の情報システム部門や法務部門が契約前に確認します。チェック項目は、認証の有無、データ保存場所、暗号化、ログ管理、アクセス制御、脆弱性対応、委託先管理、バックアップ、障害時の連絡体制などです。認証を取得していると、すべての説明が不要になるわけではありませんが、「第三者審査を受けている」という前提があるため、会話の出発点が変わります。

メリット1: セキュリティチェックの回答が整理される

大企業との取引でよくあるのが、Excel形式のセキュリティチェックシートです。項目数が100項目を超えることも珍しくありません。認証取得プロセスで情報資産台帳、リスクアセスメント表、適用宣言書、運用手順、インシデント対応フローを整えておくと、チェックシートへの回答が属人的になりにくくなります。

未整備の会社では、営業が「たぶん暗号化しています」、開発が「ログは見られます」、経営者が「委託先は信頼しています」と別々に答えがちです。これはブランド運営で、デザイナー、EC担当、倉庫担当が別々の在庫数を持っている状態に似ています。数字もルールも一元化されていないと、判断が遅くなります。認証取得の価値は、外向きの信用だけでなく、社内の答えを揃えることにもあります。

メリット2: 責任分界が明確になる

クラウド利用で事故が起きる時、原因の多くは「誰が何を管理するのか」が曖昧なことです。クラウド事業者は基盤を守っていても、利用者側のID管理、公開設定、APIキー、データ投入、権限付与までは代わりに運用してくれません。isms クラウドセキュリティ認証では、クラウドサービスカスタマとクラウドサービスプロバイダの視点で管理策を整理するため、この責任分界を文書と運用に落とし込めます。

たとえば、EC運営を外部委託する場合、広告アカウント、ECカート、倉庫システム、CRM、メール配信ツールを複数人が触ります。誰が退職者のアカウントを止めるのか、二要素認証を必須にするのか、CSVをローカルに保存してよいのか、顧客から削除依頼が来た時にどこまで消すのか。こうした細部を契約と運用に入れると、事故の芽を減らせます。

メリット3: 外部委託の管理品質が上がる

クラウドサービスの運用は、自社だけで完結しません。開発会社、保守会社、マーケティング支援会社、ライター、デザイナー、広告運用者、カスタマーサポート代行など、複数の外部人材が関わります。認証取得の過程では、委託先にどの情報を渡し、契約で何を求め、作業終了後にどの権限を回収するかを決める必要があります。

@SOHOの関連ガイドでは、AI活用やセキュリティ周辺の業務委託を検討する時に、依頼内容をどう切り分けるかを把握できます。AI・マーケティング・セキュリティのお仕事は、AI、マーケティング、セキュリティの境界が重なる案件を整理したガイドです。クラウド認証の準備でも、技術調査、運用文書、教育資料、チェックリスト化を分けて依頼すると進めやすくなります。

取得方法はギャップ分析から始める

取得方法を最短ルートで言うと、現状把握、適用範囲の決定、ギャップ分析、リスクアセスメント、管理策の整備、運用記録、内部監査、マネジメントレビュー、審査申請、第一段階審査、第二段階審査、是正対応、登録という流れです。ここで重要なのは、いきなり文書テンプレートを作ることではありません。最初に「どのサービス、どの拠点、どの部署、どのクラウド利用を認証範囲に入れるか」を決める必要があります。

範囲を広げすぎると、関係者が増え、管理すべき情報資産も増えます。逆に狭すぎると、顧客に説明したいサービスが認証範囲外になり、営業上の効果が薄れます。たとえばSaaS企業なら、開発部門だけでなく、カスタマーサポート、運用監視、営業の顧客情報管理まで含めるかが論点になります。EC支援会社なら、顧客ブランドの管理画面に入る業務、商品データの保管、広告アカウント運用、分析レポート作成が対象になりやすいです。

1. 適用範囲を決める

適用範囲は、審査を受ける「舞台」です。全社なのか、特定サービスなのか、特定部署なのかで準備量が変わります。BtoB SaaSを販売するために取得するなら、顧客に説明するサービスの開発、運用、サポート、インフラ管理が範囲に含まれている必要があります。単にバックオフィスだけが対象では、顧客が知りたいリスクに答えられません。

適用範囲を決める時は、サービス図、データフロー図、利用クラウド一覧、委託先一覧を作ります。データがどこから入り、どこに保存され、誰が見て、どのタイミングで削除されるのかを線で描くと、抜け漏れが見えます。私が現場で見た失敗は、ECの画像素材フォルダだけを見ていて、実は顧客情報を含む出荷CSVが別の共有フォルダに残っていたケースです。おしゃれな商品画像より、住所や電話番号のCSVの方が事故時の影響は重いです。

2. リスクアセスメントを行う

リスクアセスメントでは、情報資産ごとに脅威、脆弱性、影響、発生可能性を評価します。クラウド特有のリスクとしては、公開設定ミス、認証情報の漏えい、APIキーの管理不備、ログ未取得、バックアップの復元未確認、リージョンやデータ保存場所の説明不足、委託先の再委託管理などがあります。

ここで大切なのは、完璧なリスク一覧を作ることではなく、事業に効く粒度で管理策を決めることです。たとえば「クラウドストレージの誤共有」というリスクに対して、共有リンクの期限設定、外部共有の承認制、定期棚卸し、退職時のアカウント停止、ダウンロード制限を組み合わせます。単に「注意する」と書いても運用にはなりません。誰が、いつ、どの画面で確認し、記録をどこに残すかまで決めます。

3. 運用記録を積み上げる

審査では、ルールがあるだけでは不十分です。実際に運用されている証拠が必要です。アクセス権限の棚卸し記録、教育実施記録、脆弱性情報の確認記録、インシデント訓練、委託先評価、内部監査、マネジメントレビュー議事録などが確認されます。準備期間は会社の規模や既存の整備状況によりますが、ゼロから始める場合は6か月から12か月程度を見ておくと現実的です。

外部人材に一部を依頼するなら、ドキュメント作成だけでなく、現場ヒアリングや業務フロー整理ができる人を選ぶと進みやすいです。AIコンサル・業務活用支援のお仕事では、業務整理やAI活用支援の依頼範囲を把握できます。認証準備でも、AIで規程案を作るだけではなく、実際の業務に合わせてチェックリストへ落とす力が必要です。

費用の目安と内訳

isms クラウドセキュリティ認証の費用は、会社規模、拠点数、対象サービス、既存ISMSの有無、コンサル利用の有無で大きく変わります。すでにISMS認証を持っていて、クラウドセキュリティ認証を追加する場合と、ISMSから新規に整備する場合では、負担がまったく違います。小規模組織でも、審査費用、コンサル費用、社内工数、ツール費用、教育費用を合わせると、初年度で100万円から300万円程度を見込むケースがあります。中規模以上や複数拠点では、それ以上になることもあります。

費用を見る時は、請求書に出る金額だけで判断しないことです。社内担当者が週に5時間から10時間を数か月使うなら、その人件費も実質コストです。開発者、情シス、営業、法務、カスタマーサポートがヒアリングや運用変更に関わるため、プロジェクト管理を軽く見ると本業の進行に影響します。

審査費用

審査費用は、認証機関に支払う費用です。第一段階審査、第二段階審査、登録料、維持審査、更新審査などがあります。審査工数は対象人数や適用範囲によって変わります。クラウドセキュリティ認証では、ISMSの審査に加えてクラウド固有の要求事項を確認するため、既存ISMSの状態が整っているほど追加負担を抑えやすくなります。

公式サイトでは、認定された認証機関や認証取得組織を検索できます。審査機関を比較する時は、費用だけでなく、クラウドサービスやSaaSの審査経験、審査員の専門性、日程調整のしやすさを確認します。ISMSクラウドセキュリティ認証の公式情報で制度の基本を確認したうえで、複数の認証機関から見積もりを取るのが堅実です。

コンサル費用

コンサル費用は、外部支援の範囲で変わります。規程類のテンプレート提供だけなら比較的安く、現状調査、リスクアセスメント、内部監査支援、審査同席、是正対応まで含めると高くなります。目安として、小規模組織の伴走支援で50万円から200万円程度の幅を見ておくとよいです。ただし、安い支援が悪いわけではなく、自社に必要な支援範囲と合っているかが重要です。

外部支援を探す場合、システム開発やクラウド運用に理解がある人材を選ぶと、現場の言葉が通じます。アプリケーション開発のお仕事は、開発案件の依頼範囲や必要スキルを整理したガイドです。認証準備では、規程文書だけを書ける人より、API、ログ、権限、運用監視の現実を理解している人の方が、実装可能な管理策に落とし込めます。

社内工数とツール費用

見落とされやすいのが社内工数とツール費用です。パスワード管理ツール、MDM、ログ管理、脆弱性診断、バックアップ、チケット管理、教育コンテンツ、電子契約など、既存の運用で不足している部分を補う必要があります。すでに使っているSaaSの設定変更だけで済む場合もありますが、監査ログの保存期間やアクセス制御のために上位プランへ変更するケースもあります。

実務で失敗しやすいポイント

isms クラウドセキュリティ認証で失敗しやすいのは、文書を作ること自体が目的になることです。規程、手順書、台帳を整えるのは必要ですが、現場が使えないルールは審査前後で形骸化します。特にクラウド環境は変化が速く、新しいSaaS、外部委託、API連携、生成AIツールが増えます。最初に作った台帳を半年放置すれば、実態との差がすぐに広がります。

もう1つの失敗は、セキュリティ担当者だけに背負わせることです。情報セキュリティは情シスの仕事と思われがちですが、クラウド利用では営業、マーケティング、CS、経理、人事、外部パートナーがそれぞれSaaSを使います。Instagram運用ひとつでも、広告アカウント、素材管理、インサイト分析、キャンペーン応募者情報が絡みます。担当者だけが頑張っても、現場のSaaS利用を把握できなければリスクは残ります。

クラウドサービスカスタマとプロバイダを混同する

ISO/IEC 27017では、クラウドサービスを利用する側と提供する側で見るべき管理策が変わります。SaaSを自社で提供している会社はプロバイダの視点が必要です。一方、AWSやSaaSを利用して業務を行う会社はカスタマとしての管理が必要です。両方に該当する会社も多く、たとえば自社SaaSをAWS上で運用している場合、AWSに対してはカスタマ、自社顧客に対してはプロバイダです。

この二重の立場を整理しないと、審査準備で混乱します。AWSの物理セキュリティを自社が証明する必要はありませんが、自社が設定したIAM、ネットワーク、ログ、バックアップ、顧客への説明責任は自社の範囲です。責任分界表を作り、契約、SLA、利用規約、運用手順に反映することが重要です。SLAはサービス停止時の対応にも関わるため、営業資料だけでなく運用部門が守れる内容にします。

セキュリティ教育が一度きりで終わる

教育は、入社時や認証取得前の一度きりでは不十分です。クラウドサービスの設定画面は変わり、フィッシングの手口も変化します。SNSアカウントを扱う現場では、DM経由のなりすまし、広告アカウントの乗っ取り、権限付与のミスもあります。教育は年1回の形式的な動画視聴で終わらせず、実際に起きそうな業務シーンに合わせた短いチェックを繰り返す方が定着します。

私が支援した現場でも、パスワードルールの説明より「撮影委託先に商品画像と顧客情報を同じフォルダで渡さない」という具体例の方が伝わりました。セキュリティは抽象語だと距離が出ますが、日々の作業に置き換えると急に自分ごとになります。認証のための教育ではなく、業務を止めないための教育として設計することが大切です。

委託先管理が契約書だけで止まる

委託先管理では、NDAや業務委託契約を結ぶだけで安心しがちです。しかし、実際には委託先がどの端末で作業するのか、再委託はあるのか、共有されたデータをいつ削除するのか、作業終了後にアカウントを返却するのかまで確認する必要があります。契約書の条文と実際の業務フローが合っていないと、事故時に説明できません。

外部人材に依頼する時のおすすめの切り分け方

認証取得をすべて社内だけで進めるのは、現実的に重い場合があります。外部コンサル、クラウドエンジニア、ライター、業務改善担当、法務支援者などに分けて依頼すると、プロジェクトの進行が安定します。ただし、丸投げは危険です。認証は自社の運用そのものなので、外部人材は整理と実装の支援役、自社は意思決定と運用責任を持つ役、と分ける必要があります。

おすすめは、最初にプロジェクト責任者を社内で決め、その人が外部人材の成果物を受け取れる状態にすることです。外部人材には、現状ヒアリング、クラウド利用一覧の作成、情報資産台帳のたたき台、リスクアセスメントのファシリテーション、規程文書の編集、教育資料の作成、内部監査チェックリストの作成などを依頼できます。各作業は専門性が違うため、ひとりに全部を求めるより、必要な部分だけを切り出す方が品質を保ちやすいです。

技術支援と文書支援を分ける

技術支援では、クラウド設定、ログ取得、権限管理、バックアップ、脆弱性診断、監視設計を見ます。文書支援では、規程、手順書、教育資料、議事録、チェックリスト、審査向け説明資料を整えます。この2つを混同すると、文書はきれいでも設定が甘い、設定は強いけれど審査で説明できない、というズレが起きます。

単価相場を見て依頼範囲を調整する

外部人材を探す時は、依頼範囲と単価感を合わせることが重要です。システム設計やクラウド設定まで含むなら、ソフトウェア開発者やクラウドエンジニアの相場に近づきます。規程文書や教育資料、社内向けマニュアルを整えるなら、編集者やテクニカルライターの力が役立ちます。@SOHOのソフトウェア作成者の年収・単価相場は技術職の相場感を確認する入口になります。著述家，記者，編集者の年収・単価相場は、文書化や編集を依頼する時の目線合わせに使えます。

安く済ませることだけを優先すると、後で社内運用に合わない文書を直す手間が増えます。逆に高額なコンサルに全部任せても、社内の判断が追いつかなければ運用は定着しません。依頼前に「認証範囲を決めたい」「台帳を作りたい」「クラウド設定を確認したい」「教育資料を作りたい」のように成果物を分け、見積もりを比較するのが現実的です。

資格は実務理解の補助線として見る

外部人材を選ぶ時、資格は一定の判断材料になります。ただし、資格があるだけで認証プロジェクトを任せられるわけではありません。ネットワークやクラウド基盤の理解が必要な場面では、CCNAのような技術資格が基礎力の目安になります。@SOHOのCCNA（シスコ技術者認定）は、ネットワーク知識を持つ人材の理解度を見たい時に参考になります。

一方で、認証取得では文書の正確さも大切です。規程や手順書は、あいまいな表現を避け、誰が読んでも同じ運用になるように書く必要があります。ビジネス文書検定は、業務文書の基本スキルを確認する資格ガイドです。セキュリティ認証の文書は、専門用語を並べるより、現場で迷わない文章にする方が価値があります。

取得前チェックリスト

取得前には、最低限のチェックをしておくとプロジェクトが迷走しにくくなります。まず、認証取得の目的を明文化します。大企業取引の条件なのか、SaaS販売の信用補強なのか、社内統制の強化なのかで、適用範囲も優先順位も変わります。次に、既存のISMS取得状況を確認します。未取得であれば、クラウドセキュリティ認証だけでなくISMS構築から計画する必要があります。

さらに、クラウド利用一覧を作ります。AWS、Azure、Google Cloud、Microsoft 365、Google Workspace、Slack、Notion、GitHub、ECカート、広告管理画面、CRM、会計SaaSなど、部門ごとに使っているツールを洗い出します。無料プランや個人アカウントで使っているツールも対象です。セキュリティ事故は、公式に導入した大きなシステムより、現場が便利だから使い始めた小さなSaaSから起きることがあります。

最低限確認したい項目

確認したい項目は、情報資産、クラウドサービス、アカウント、権限、ログ、バックアップ、委託先、契約、教育、インシデント対応です。たとえば、誰が管理者権限を持つのか、退職や契約終了時に何日以内に権限を削除するのか、管理者ログを何か月保存するのか、バックアップから復元できることをいつ確認したのか、といった質問に答えられるかを見ます。

ここで答えに詰まる項目が多いなら、認証審査の前に運用整備を優先すべきです。反対に、すでに社内でルールがあり、記録も残っているなら、審査対応は比較的進めやすくなります。重要なのは、満点の状態を待つことではなく、現状の穴を見える化し、事業リスクが高い順に潰すことです。

取引先に説明できる資料を作る

認証取得を検討する段階から、取引先に説明できる資料を作ると実務で役立ちます。認証範囲、クラウド利用、データ保存、アクセス制御、暗号化、バックアップ、委託先管理、インシデント連絡体制を1枚から3枚程度に整理します。これは営業資料ではなく、セキュリティ説明資料です。

この資料があると、認証取得前でも取引先との会話が具体的になります。「取得予定です」だけでは弱いですが、「現在はこの範囲を対象に、リスクアセスメントとログ管理を整備しています」と言えれば、相手も判断しやすくなります。認証後も、登録証だけを送るより、認証範囲と運用概要を一緒に説明する方が誤解を防げます。

たとえば、EC運営支援の現場では、商品説明文やSNS投稿だけでなく、画像素材、顧客データ、広告アカウント、売上データを扱います。これらを整理する作業は、認証の直接審査項目ではなくても、情報資産管理や委託先管理の土台になります。クラウドセキュリティ認証を取得する会社が増えるほど、周辺業務を支える外部人材の需要も広がります。

手数料と継続支援の見方

ただし、手数料だけで選ぶのは危険です。認証関連の依頼では、守秘義務、成果物の権利、作業範囲、責任範囲、納期、レビュー方法を明確にする必要があります。NDAを結び、アクセス権限を最小限にし、不要になった権限を削除する。これは依頼者側の責任でもあります。外部人材を入れるほど、委託先管理そのものが認証準備の一部になります。

受発注側が共有すべき期待値

発注側は「認証を取れる資料を作ってほしい」と抽象的に頼むのではなく、「クラウド利用一覧を作る」「リスクアセスメントのたたき台を作る」「教育資料を作る」「セキュリティチェックシート回答を整理する」のように分けて依頼すると、成果物の品質を判断しやすくなります。受注側も、自分が審査判断をする立場ではないこと、最終責任は認証取得企業にあることを明確にする必要があります。

クラウドセキュリティ認証は、専門家だけが閉じた部屋で作るものではありません。現場の運用、顧客への説明、外部委託の管理、継続的な改善がつながって初めて機能します。華やかなECやSNS運用でも、裏側には権限、ログ、契約、データ削除の地味な作業があります。その地味な作業を見える化できる会社ほど、取引先から信頼されやすくなります。