【WordPressを使用している地方のWeb制作会社さんへ】セキュリティー対策を中心にした保守サービスのススメ

Responsibility：ちほうタイガー CHIHOU TIGER
佐渡島に本社を有するWeb制作会社「taneCREATIVE」に所属する忘れっぽいトラ。
同社は、ほぼ全員が離島に住んでいるという特殊な環境から、創業時よりリモートワークでのWeb制作・保守サービスを提供。
必然的に企画・デザイン力よりも技術力をベースに力をつけることとなり、現在は多くの大手企業から直接ベンダーとしてWeb制作・保守を任されている。
ここ数年、他社様が制作・構築したWordPressサイト・クラウドサーバーの保守引き継ぎに関するご相談が急増していることから、「日本全国のWeb制作会社がセキュリティー対策に目覚めれば、当社への大変な引き継ぎのご相談が減るのではないか」というtaneCREATIVE代表の妄想によりこの特集を書かされている。

Supervision：西野勝也 KATSUYA NISHINO
クラウド型WAF「Scutum」、クラウド型Web脆弱性診断ツール「VAddy」の開発・提供元である株式会社ビットフォレスト取締役。
同社は、アプリケーションの開発と運用の現場で培った実践的なセキュリティ・防御システムを開発、SaaS型で提供している他、セキュリティー専業会社への技術提供をしているWebアプリケーションセキュリティに関するトップ企業である。
「企業の最も身近なIT相談係であるWeb制作会社がセキュリティー対策を勉強し、適切なアドバイス・対策を出来ることこそが、日本企業躍進へのサポートになると信じている」というtaneCREATIVE代表の表向きの理念に共感し、本特集の技術面での監修を引き受けたことになっている（実際にはちほうタイガーに佐渡島視察時にご馳走するので協力してくれと泣きつかれた）。

皆さんこんにちは。taneCREATIVE株式会社の「ちほうタイガー」です。
当社は、佐渡島の本社を置く42名（2022年4月現在）の小さなWeb制作・保守会社です。
まだまだ小さな会社ではありますが、2012年の起業以来、地道にまじめにコツコツと、『デザイン力の向上』『技術水準の底上げ』『セキュリティーの知識獲得』『サポート体制の強化』『コストの最適化』に取り組んで参りました。
こういった点が少しずつ評価され、現在では数多くの大手企業様より直接Webサイト・Webシステムの制作・開発案件やこれらの保守をご依頼いただいております。
また、佐渡島に本社があり、そこに大多数のエンジニア・デザイナーが在籍していることから、起業以来お仕事はほぼリモートで実施してきました。
この流れから、群馬伊勢崎にもオフィスを構えましたが、これは群馬伊勢崎のエンジニアが当社のスタッフになってくれるというご縁があり、働く場としてオフィスを設置しただけで、別段群馬のお仕事を期待してとかではありません（同じパターンで次は富山にもオフィスを設置します）。
要するに、首都圏の企業様からWeb制作・保守のお仕事をお請けして、それを田舎からリモートで提供している地方によくあるWeb制作会社です。

先ほど「ウィズコロナ・アフターコロナの時代だからこそ」と述べさせていただきましたが、この新型コロナウイルス感染症（COVID-19）の世界的な流行は、当然ながら当社の方でも予想できておらず、完全に想定外のことでした。
当社においても、2020年2月頃より、企業様の方で4月以降の契約を縮小するご相談などがあったほか、店舗経営等をされている小規模なクライアントからWebサイト保守契約の解除などが数件ありましたし、東京に本社を置かれる企業様の活動が停止したことで、新年度のプロジェクトに関して呼んで頂いていたプレゼン・コンペなどが軒並み延期となったことから、マイナスの影響は確かにありました。4月末までは当社代表も眠れぬ日々を送っていた模様です。

しかしながら、約3か月先までのスケジュールがお仕事で埋まっていたためこれを調整したことや、売上に占める保守業務の割合がかなり多かったこと、幸運にも佐渡島ではコロナウィルスの流行がなかった上に、最初からリモートワークの企業であるため稼働力・生産能力が低下することはなかったこと等が幸いして、当社においては、マイナスの影響は限定的なものに抑えることができました。

そのようななか、2020年5月頃から当社へのお問合せが大幅に増加し始めました。もちろん、コロナ対策での積極的なご相談もありましたが、ほとんどは他社様が制作・開発されたWebアプリケーション（Webサイト・Webシステム）・クラウドサーバーの保守を引き継いでほしいというご相談だったのです。
特に一定の規模を有する企業様からWordPress＋AWSという組み合わせでのご相談が急増しており、本記事を書いている今現在も日々のお問合せに対応している状態です。

ご相談いただいた企業様が置かれている状況、当社にご相談いただいた理由を整理してみると次の通りです。

ご相談いただいた企業様が置かれている状況
❶ WebサイトのCMSにWordPressを採用している。
❷ サーバーにAWSやさくらのクラウド等のクラウドサーバーを採用している。
❸ セキュリティーの重要性は理解しているが、新型コロナウイルス感染症の世界的な流行（コロナ禍）をきっかけとしてWebアプリケーション・クラウドサーバーの保守について費用の見直しが必要になった。
❹ コロナ禍によってクライアント側もリモートでの業務を余儀なくされたことで、Webアプリケーションとサーバーの保守はリモートでも問題ないという意識が一気に高まった。

当社にご相談いただいた理由
❶ WordPressのメンテナンス、特にセキュリティー対策に関する一定の知見がある保守会社を探していた。
❷ AWSやさくらのクラウド等のクラウドサーバーの運用と、ミドルウエア・OSに関するセキュリティー対策に関する一定の知見がある保守会社を探していた。
❸ 保守費用は現在と同等か削減できるところを探していた。
❹ 方法はWeb会議やチャット・メールで構わない。佐渡島の会社で迅速でまじめに対応してもらえそう。

この記事をお読みいただいている地方のWeb制作会社さん、個人事業主さんは、既にリモートで業務を行われていることでしょうし、まじめに迅速に作業をされることでクライアントから評価をされているでしょう。田舎で会社を立ち上げれば地域のお仕事も対応せざるを得ませんが、そこで適当なお仕事をしていれば上手くいかないことは佐渡島で生活している当社も理解しているつもりです。
きっとWordPressも十分に使いこなしておられるのではないでしょうか。

一方で、AWSのようなクラウドサーバーについては、もしかしたらリスクの方を心配されているかもしれません。
なぜそう推測するのかと言えば、当社も2018年頃までは、サーバー・OSは出来る限りサーバー会社さんが面倒を見てくれるホスティングサービスをお薦めしてきましたし、PHPとそのフレームワーク、Apache、nginx、MySQL、mariadbといったミドルウエアの保守体制に対しても、「一応できるけれども、自信のなさからできるだけそういった案件を避けてきた」からに他なりません。
どうしてもAWS等のクラウドサーバーを利用せざるを得ない時には、外部の開発会社さんを頼ってきました。

しかしながら、2018年後半頃より、AWSを利用されているクライアントが実感を伴うレベルで増えてきたこと、当社が保守を任されているWordPressサイトへの外部からの攻撃数が明確に増加してきたことから、クラウドサーバーの構築、OS、ミドルウエアのセキュリティー対策に正面から取り組むようになりました。
そして2020年春（よりにもよってコロナ禍真っ只中の4月末か5月頃）から、現場の主観ではありますが、WordPressサイトへの攻撃が更に激化していると感じています。

この記事をお読みいただいている地方のWeb制作会社さん、個人事業主さんも、地元の企業・団体のWebサイト保守を依頼されているかと思います。
そして身近な地元の人たちから、ITの事なら何でも相談できる相手として、まさに守護神のように頼られているのではないでしょうか。
東京で華々しい案件をこなし続けるのも魅力的かもしれませんが、地元の大切なクライアントの資産であるWebサイト・Webシステムを守りきる仕事も誇りが持てる仕事であると私たちは考えています。

また、前述のようにWordPress+AWSの保守が出来れば、しばらくの間は首都圏の企業様のお仕事に困らなくなると当社では推測しています（少なくとも当社に現在殺到しているご相談は、当社単独で捌ききれる量ではなく、早晩当社のリソースが満杯になると考えられます）。コロナ禍は苦しんでいる方々の事を考えれば、決して肯定的にとらえてよい事象ではありませんが、前述のように、クライアント側が「Webの保守・運用などの業務は完全にリモートで良いのではないか」と本気で考えるようになったきっかけにはなったと思います。

他社様が制作・開発されたWebアプリケーションを保守する業務には、広く深い知見が必要な上に、属人的でシステム化が難しい作業が多く、かつ頂戴できる月額費用は少ない為、どうしても目先の利益を優先すれば優秀なエンジニアを稼げる開発業務に充てたいのもよくわかります。
しかしながら、年商を大幅に引き上げることが出来ない保守業務は、大きなIT企業様にとってそれほど魅力的には映らないサービスであり、競合が少ないというメリットがあります。そして地道に積み上げた保守の売上は、地方のWeb制作会社が安定的で持続的な成長をしていく分には十分な売上になることを、佐渡島の当社は証明できたと思っています。

この記事をお読みいただいている地方のWeb制作会社さん、個人事業主さん、今こそ少しだけ勇気を出して、セキュリティー対策を中心にした保守サービスに取り組んでみましょう。

この記事をお読みいただいている地方のWeb制作会社さん、個人事業主さんも、WordPressサイトを保守されている場合、脆弱なパスワード対策、WordPressのコアファイル、テーマ、プラグインのバージョンアップには気を使われているかと思います。
一方で、OSやミドルウエアに関しては、サーバー会社さんにお任せしているケースが多いとも推測しています。

Xserverやさくらのレンタルサーバーなどの共用レンタルサーバーを利用されている場合、OSやミドルウエアはサーバー会社の責任の下、パッケージで提供されているため、（ユーザーの委任で保守を行う）Web制作会社が責任を負う必要はありませんし、逆に言えばWeb制作会社側で干渉できることもほとんどありません。
つまり、通常の共用レンタルサーバーの場合、Web制作会社が保守を担当するのはあくまでWebアプリケーション（本記事ではWordPress等のCMSもWebアプリケーションに含めます）だけであることになります。

しかしながら、AWSの場合、ネットワークや仮想インフラ等の公開サーバーが動くための基本的なインフラ（「仮想インフラ」「セキュリティグループ」「ネットワークインフラ」）に関してはAWSが責任を持ちますが、そのインフラ上で稼働するゲストOS、ミドルウェア、Webアプリケーションについてはユーザーである利用者が責任を持つことになります。
また、AWSの責任範囲である「セキュリティグループ」「ネットワークインフラ」についても（Amazon VPC等の）設定についてはユーザー側にて行わねばなりません。
この為、ユーザーから保守を委任されて行うWeb制作会社には、AWSの設定の他、ゲストOSのパッチ適用、ミドルウエアのパッチ適用、アクセス管理、WAF等のセキュリティー対策の実施が求められることになります。
※最近はVPSサーバーもよく利用されますが、責任範囲については基本的にはAWSと近い為（共有レンタルサーバーと近いVPSもあります）、本特集記事では割愛させていただきます。

このように、採用しているサーバーの種類によって、各レイヤー毎にWeb制作会社に求められる保守業務の内容が異なってきますので、以下「脆弱性を潰す対策」について、各レイヤー毎に保守のポイントを説明させていただきます。

上記のように、ハードウエア/ネットワークの管理責任は、共用レンタルサーバーであれAWSであれサーバー会社にあります。
このレイヤーは保守業務の対象外となりますし、Web制作会社に出来ることは通常ありません。

共用レンタルサーバーであれば、OSはホスティングサービスの内容としてサーバー会社が責任をもって保守をしてくれますので、Web制作会社がOSの脆弱性について対応する必要はありません。
一方で、AWSの場合には、ゲストOSの保守はユーザー側の責任となります。
この為、通常はクライアントと相談の上、パッチ適用ルールとパッチ適用フローを定めて、保守作業としてパッチを適用していくことになります。

共用レンタルサーバーであれば、ミドルウエア（PHPとそのフレームワーク、Apache、nginx、MySQL、mariadb等）はホスティングサービスの内容としてサーバー会社が責任をもって保守をしてくれますので、Web制作会社がミドルウエアの脆弱性について対応する必要は基本的にはありません。
一方で、AWSの場合には、ミドルウエアの管理はユーザー側の責任となります。
この為、通常はクライアントと相談の上、パッチ適用ルールとパッチ適用フローを定めて、保守作業としてパッチを適用していくことになります。

WordPressは世界で最も狙われやすいCMSですので、WordPress本体・テーマ・プラグインに脆弱性が見つかった場合には、速やかにバージョンアップを実施して行く必要があります。
しかしながら、これを更新がある毎に実行すると、それだけで保守コストが多額になってしまう他、特にWordPress本体のメジャーバージョンアップなども即座に対応をしますと、今度は挙動が安定しないこともありえます。
そこで、WPsecのようなスキャンサービスを利用して、一定以上のアラートが出た際にアップデートを実施するアップデートルールとエスカレーションフローを定めて、保守作業としてアップデート対応をしていくことになります。
また、プラグインの脆弱性は、プラグインを「停止中」であっても存在し続けていることに留意する必要があります。
対策として、停止中のプラグインはWordPressの管理画面からできるだけ「削除」しておくようにしましょう。

また、WordPressではMySQLというデータベースを採用していますが、デフォルトでは、データのテーブルに「wp_」というプレフィックス（接頭辞）が設定されるようになっています。
これは「脆弱性」と呼べるほどのものではないと考えますが、「テーブル名」の特定に利用され、データベースに対する攻撃に利用される恐れがあります（SQLインジェクション等）ので、プレフィックスを変更しておくことが推奨されます。

更に、WordPressは元々がブログソフトウエアであったことから、コメント投稿機能・ピンバック機能（リクエストを受け付ける機能）・トラックバック機能（参照元のサイト管理者にリンクを貼ったことを通知する機能）が実装されており、これらの機能はデフォルトではONになっています（これらは「ディスカッション設定」で管理できます）。
これらの機能も「脆弱性」とは言えないかもしれませんが、Dos攻撃・DDos攻撃（大量のデータを送りつける攻撃）の端緒となる可能性がありますので適切に管理しておく必要があります。
具体的には、不要なコメントフォームを非表示にした上で、サーバー側でwp-comments-post.phpへアクセス拒否等の設定を実施する他、使用していないのであればピンバック機能・トラックバック機能についてはOFFにしておくとよいでしょう。

WordPressに限らず動的CMSを採用したケースや、スクラッチ開発したケースなどでWebアプリケーションがデータベースを利用している場合、検索ボックスやお問合せフォームなどDBにアクセスする入り口があると狙われやすくなります。
サイト内検索などは、こだわりがないのであればGoogleのサイト内検索を利用するなどしてブラウザからDBへアクセスできる部分を出来るだけ減らしておくことも有効ですが、動的なページではなかなかそうもいかないのが現状です。
このような場合は、１年に１回程度でも脆弱性診断を実施しておくことをお薦めしています。
当社では、株式会社ビットフォレストさんが提供するクラウド型Web脆弱性診断ツールVAddyを採用しており、納品時にProfessional版でチェックをかけておりますが、一定水準以上のセキュリティーが求められるサイトでは、クライアントにEnterprise版をご契約いただいて、継続的にチェックされることをお薦めしております。
また、他社様が制作したWebサイトを引き継ぐときに脆弱性が存在していると引き受け後に諸々のトラブルに巻き込まれてしまう可能性があります。
Webサイトを引き継ぐ際にも脆弱性診断を実施しておくことをお薦めします。

次に、脆弱性があるかどうかとは別の観点のセキュリティー対策として、そもそも攻撃の対象になりにくくする対策と、攻撃を検知・防御する対策があります。 保守担当者としては、クライアントに対してこれらの対策を多層的にご提案し、運用することが求められます。

WordPressへの攻撃を試みるロボットはソースコード上のWordPressの痕跡を探して、攻撃対象サイトを探してきますので、ソースコード上からWordPressの痕跡を消し去ることで、一定程度狙われにくくすることは可能です。
しかしながら、これを実施してしまうと、WordPress本体、テーマ、プラグインの脆弱性を定期的にチェックするツール（WPsec等）が誤作動を起こすなどのデメリットもある点に注意が必要です。
その結果、当社のように、保守にて脆弱性を潰すことを優先し、この対策は敢えて実施しない制作会社も多いと思います。

接続元のグローバルIPアドレスによってアクセスを制限することで、事前に許可したグローバルIPアドレス以外から各レイヤーへの接続を拒絶する対策（IP制限）はセキュリティー対策として非常に有効です。
このIP制限を重要な範囲に適切な方法で掛けておくことで、セキュリティーを大幅に高めることができます。
AWSの場合には、セキュリティグループ(ホスト、LBに設定する場合)、ネットワークACL(VPC全体に設定する場合)、ロードバランサー(ALBの場合)などで用途に合わせて設定できます。
上記のような厳格なIP制限の他に、国外IPアドレスからのアクセスを制限するという限定的な制限もよく利用されます。
また、IPと併せてポートの制限も適切に設定することも重要です。
例えば、Webサイトなどは公開するため全てのIPからのアクセスを受け付ける必要がありますが、保守に使用するFTPは管理者からのIPのみ受け付けるようにするといったようにIPとポートを組み合わせた制限をかけることが必要になります。
加えて使用しなくなったポートは都度閉じるようにしましょう。
なお、IP制限、ポートの制限は有力な防御方法ですが、Webサイトは公開され全てのIPからのアクセスを受け付けている以上、Webサイト経由での攻撃の全てをアクセス制限で防御することはできませんので、その他の防御手段を併用することが推奨されます。

共用レンタルサーバーであれば、ハードウエアの管理責任はサーバー会社にありますが、どこまでセキュリティー対策を実施しているかは各社のプランによります。
当社の知る限りでは、ファイアーウォールについては標準装備しているサーバーがほとんどですが、IPS（侵入防御システム）についてはオプションとなっているケースが多いので、ご利用になられているプランではどこまでを標準で対応しているのか、オプションを選択できるのかを確認しておくとよいでしょう。
ファイアーウォールとIPSの組み合わせは「ポートスキャン」「DDos攻撃」「Synフラッド攻撃」に有効です。
一方で、AWSの場合には、基本的なネットワーク部分はAWSが責任をもって管理してくれますが、ファイアウォール機能である「セキュリティグループ」と仮想ネットワークを構築できる「Amazon VPC」の設定はユーザー側が行わねばならないことに注意が必要です。
AWSの場合には、セキュリティーグループの設定とAmazon VPCのアクセス制御の設定をしっかりと行いましょう。
なお、AWSの場合には、AWS ShieldというDDos攻撃対策のサービスがデフォルトで適用されています。課金することでWebアプリケーションレベルのDDosも防御できますので必要なセキュリティーレベルに合わせて選択しましょう。

WAF（Web Application Firewall）は、その名の通りファイアウォールの一種で、外部とWebアプリケーションのやり取りを検知・制御することで不正侵入を防御するセキュリティー製品です。
前述のWordPressを例にすると、WordPress本体やプラグインのバージョンアップを実施することは脆弱性自体を潰していく対策ですが、WAFはWebアプリケーションへの攻撃そのものを検知・制御するものですので、例えば使用しているプラグインに致命的な脆弱性が見つかり、セキュリティパッチが提供される前に攻撃を受けた場合（ゼロディ攻撃）でも、WAFであれば防御できることもあります。
また、防御範囲も、XSS対策やSQLインジェクション対策、ファイル不正アクセス対策、PHPの関数の脆弱性対策などの検知しやすい攻撃への対策だけに留まらず、パスワードリスト攻撃、DDos等年々広くなっています（WAF製品・設定によって異なります）。
近年では、WAFを設定することは、Web制作業界でも「やっておいた方がいい」程度には一般的になっていると思いますし、実際に多くのレンタルサーバーではWAFが標準装備となっています。
しかしながら、レンタルサーバー標準装備のWAFをONにすると他の機能に影響が出るケースがあったり、誤検知が多く出ることもあったりします。
また、最近当社にご相談が増えているAWSの場合、事前設定済みのルールセットであるAWS WAF のマネージドルールを利用するケースがほとんどですが、正しくWAFを動作させる場合には高度な知識とノウハウが必要なため、かなりの勉強が必要になります。
利用者側でのカスタマイズの自由度は一見魅力的に見えますが、裏を返すと使いこなすための経験と知識が必要ということですね。
なかなか対応が難しいという場合にはビットフォレストさんのクラウド型WAFサービス「Scutum」（月額29,800円～）をクライアントにご紹介するのも一つの選択肢でしょう（「Scutum」は10年以上の運用データをもとに防御エンジンが自動的にアップデートされるため、利用者側での個別設定は不要です）。

WordPressに限りませんが、特にWordPressでは、管理画面へのログイン画面のURLがデフォルトで“wp-login.php”となっています。
WordPressへの攻撃を試みるロボットは“wp-admin”または“wp-login.php”を探して来ますので、この「ログイン画面のURLを変更」したり、「IP制限」や「Basic認証」を掛けることでURLへのアクセス自体をガードしましょう。
なお、攻撃を試みるロボットが管理画面へのログイン画面にたどり着いてしまうと、ブルートフォースアタックという総当たり攻撃を受けてしまう可能性があります。そうしますと、仮に侵入されなかったとしても、閾値の低い共有サーバーなどではそれだけでサービスを停止してしまうことがあります。
その為、攻撃者をログイン画面にたどり着かせないという対策（bot対策）が重要になります。
なお、前述のWAFを設定しているので大丈夫なのではないかという質問を時々受けますし、実際に最近のWAFはある程度botアクセスを防御することが可能なので、WAFを設定してくれればかなり安心できるのは事実ですが、通常はWAFもbotによるアクセスであると検知するまで一定量のリクエストを受け付けますので、狙われやすいWordPressの場合には、特段の理由が無い限りは「そもそもbotを管理画面にたどり着かせない対策」を実施しておくことをお薦めしています。

上記のように、管理画面へのログイン画面へたどり着かれると、ブルートフォースアタックを受けてしまう可能性がありますが、その際に、「パスワードを複雑で長くする」「ログインの試行回数を制限する」「ログインに（ひらがな等の）画像認証を追加する」「複数の認証要素を用いる２段階認証を入れる」等のログインの難易度を高める対策を実施することで、万が一攻撃者にログイン画面までたどり着かれても、アタック段階でのセキュリティーをある程度高めることができます。
前述のように、WordPressがハッキングされる経路の8％が「脆弱なパスワード」であることをクライアントに伝えて、上記対策を実施しましょう。
WordPressの場合、「ログインの試行回数を制限する」並びに「ログインに（ひらがな等の）画像認証を追加する」ことは「SiteGurad WP Plugin」という有名プラグインで簡単に実現できますし、Xserverのようにサーバー側でログイン試行回数を制限できるサーバーもありますので、実施しておきましょう。

このように、Webサイトの保守業務において、私たちができる「脆弱性を潰す対策」と「攻撃を避ける・防御する対策」について大まかに解説してみましたが、残念ながら万全のセキュリティーというのは非常に困難であると考えております。
少なくとも当社単独では実現できません。
その為、何かトラブルが起こりそうな際、起こった際に迅速に対応できる体制を整えておくことが重要になります。
通常はクライアントの情報システム部門と当社のような保守担当会社が役割分担表を作成し、ケースにより適用するエスカレーションフローを作成して、対応できる体制を整備することになります。
クライアントから「万全のセキュリティー」を求められるケースも非常に稀にあります…… その場合は素直にビットフォレストさんを頼りましょう。

さて、ここまで地方のWeb制作会社さん、個人事業主さん（あるいはこれから独立しようとしている方）に対して、Webサイトの保守業務のうち技術的ハードルが高いと思われるセキュリティー対策について解説してみました。
しかしながら、やはりセキュリティーが絡む保守については、万が一の際のリスクに対する心配も強いでしょう。
そこで、保守契約は明確に「準委任契約」とした上で、「損害賠償責任を保守費用の２年分に限定する責任限定条項」を付けるようクライアントにお願いしましょう（経験上、「その代わりに安くまじめに地方で頑張っております」と伝えればほとんどのクライアントはOKしてくれます）。
当社では、他社様が制作されたWebサイト・Webシステムをお引き受けする際には必ず責任限定条項をお願いして付けて頂いています。

以上、当社は佐渡島の小さなWeb制作会社ではありますが、幸運にも多くの大手企業様よりお仕事を頂けるようになり、そして今、Webサイト（特にWordPress＋AWS）の保守で突如注目をされ始めていると感じています。
本記事では、WordPress＋AWSでの保守業務におけるセキュリティー対策について概要を説明させていただきましたが、紙面の都合もあり詳細を全て解説することはできていません。
もし、各地で頑張っておられるWeb制作会社・個人事業主さんで、もう少し詳細を知りたいという方がおられましたら、こちらのフォームより「ちほうタイガー」宛にご相談ください。その時手が空いている誰かが対応させていただきます。