このトピックでは、Application Load Balancer (ALB) に関するよくある質問への回答を提供します。
ALB インスタンスを IPv4 からデュアルスタック、またはデュアルスタックから IPv4 に切り替えることはできますか？
ALB インスタンスで転送できるリクエストの最大サイズはどれくらいですか？許可される最大サイズを増やすことはできますか？
同じバックエンドサーバー内のすべてのバックエンドサーバーが異常な場合、ALB インスタンスはどのようにリクエストを転送できますか？
Alibaba Cloud は異なる仕様の ALB インスタンスを提供していますか？
いいえ、Alibaba Cloud は異なる仕様の ALB インスタンスを提供していません。アップグレードされた ALB インスタンスは、仮想 IP アドレス (VIP) を自動スケーリングでき、それぞれ最大 100 万 QPS を処理できます。ALB のパフォーマンスの詳細については、「パフォーマンスメトリック」をご参照ください。
アップグレードされていない ALB インスタンスは、静的 IP モードと動的 IP モードを区別します。静的 IP モードでは、ALB インスタンスで使用される VIP は固定です。動的 IP モードでは、負荷が増加するにつれてより多くの VIP を使用でき、各インスタンスは 100 万 QPS に到達できます。
ALB インスタンスのパフォーマンスの詳細については、「ALB とは」トピックの「パフォーマンスメトリック」セクションをご参照ください。
ALB インスタンスの最大インターネット帯域幅を増やすにはどうすればよいですか？
ALB インスタンスが 2 つのゾーンにデプロイされ、インターネット共有帯域幅インスタンスに関連付けられていない場合、ALB インスタンスのデフォルトの最大インターネット帯域幅は 400 Mbit/s です。
より多くの帯域幅が必要な場合は、インターネット共有帯域幅インスタンスを購入し、ALB インスタンスの Elastic IP アドレス (EIP) をインターネット共有帯域幅インスタンスに関連付けることができます。
インターネット共有帯域幅インスタンスの購入方法の詳細については、「インターネット共有帯域幅の作成」をご参照ください。
EIP をインターネット共有帯域幅インスタンスに関連付ける方法の詳細については、「ALB インスタンスの作成と管理」および「最大帯域幅の変更」をご参照ください。
リスナーのヘルスチェック設定を変更するにはどうすればよいですか？
ヘルスチェック中に例外が検出されないのに、502 ステータスコードが返されるのはなぜですか？
これは、ALB インスタンスのバックエンドサーバーが過負荷になっているためです。ALB インスタンスのバックエンドサーバーが過負荷になっている場合、ヘルスチェックの結果が正常であっても、アクセスリクエストが応答に失敗する可能性があります。詳細については、「Linux インスタンスの高負荷の問題のトラブルシューティングと解決」をご参照ください。
データ転送プランを使用して、ALB のインターネットデータ転送料金を相殺できますか？
ALB インスタンスが EIP を使用してインターネット経由でサービスを提供している場合、データ転送プランを使用してパブリック帯域幅料金を相殺できます。
ALB インスタンスが Anycast EIP を使用してインターネット経由でサービスを提供している場合、データ転送プランを使用してインターネットデータ転送料金を相殺することはできません。
ALB は相互認証をサポートしていますか？
ベーシック ALB インスタンスは相互認証をサポートしていません。スタンダードまたは Web Application Firewall (WAF) 対応の HTTPS リスナーALB インスタンスの エディションを変更するALB で相互認証を有効にすることができます。相互認証を構成する前に、ベーシック インスタンスの エディションを変更して、スタンダードまたは WAF 対応にする必要があります。
相互認証に使用される認証局 (CA) 証明書は、Alibaba Cloud またはサードパーティによって署名できます。
Alibaba Cloud によって署名されたプライベート CA 証明書を選択または 購入 します。
サードパーティによって署名された CA 証明書を選択するか、ALB に 追加 します。証明書を構成する際には、[ デフォルトの CA 証明書 ] ドロップダウンリストで [ 自己署名 CA 証明書のアップロード ] をクリックします。[ 証明書アプリケーションリポジトリ ] ページで、[ データソース ] が [ CA 証明書のアップロード ] であるリポジトリを作成します。リポジトリの詳細ページで、自己署名ルート CA 証明書または自己署名中間 CA 証明書をアップロードします。
相互認証を構成するには、Alibaba Cloud Certificate Management Service から証明書を選択するか、CA 証明書を購入します。詳細については、「プライベート CA の購入と有効化」をご参照ください。
ワイルドカードリスナー証明書はどのような要件を満たす必要がありますか？満たす必要がある要件は?
HTTPS リスナーにワイルドカード証明書を構成する場合は、次の制限事項に注意してください。
ワイルドカード証明書を選択すると、ALB は 1 つのワイルドカード (
*) のみを含む証明書を識別できます。ワイルドカードはドメイン名の左端に配置する必要があります。たとえば、ALB は*.example.comと*test.example.comを識別できますが、test*.example.comは識別できません。ワイルドカード証明書の要件:
ワイルドカードドメイン名のレベル: ワイルドカードドメイン名は、ワイルドカードドメイン名と同じレベルの特定のドメイン名と一致させることができます。たとえば、
*.example.comはtest.example.comと一致させることができますが、ワイルドカードドメイン名よりも 1 レベル下のtest.test.example.comとは一致させることができません。国際化ドメイン名 (IDNA):
ワイルドカードが唯一のワイルドカード文字であり、ワイルドカードドメイン名の左端にある場合、IDNA はワイルドカードドメイン名と一致させることができます。たとえば、
xn--fsqu00a.example.comは*.example.comと一致させることができます。ワイルドカードがワイルドカードドメイン名の左端ではない場合、IDNA はワイルドカードドメイン名と一致させることができません。たとえば、
xn--fsqu00atest.example.comは*test.example.comと一致させることができません。
一致範囲: ワイルドカード (
*) は、数字、文字、およびハイフン (-) と一致させることができます。たとえば、*.example.comはtest.example.comと一致させることができますが、test_test.example.comとは一致させることができません。
どのようなタイプの EIP を ALB インスタンスに関連付けることができますか？
ALB は、従量課金制の EIP のみをサポートしています。次の表は、ALB インスタンスに関連付けることができる EIP のタイプを示しています。
課金方法 | インターネット課金方法 | 回線タイプ | セキュリティ保護 |
従量課金 | トラフィック課金 | BGP (マルチ ISP) | デフォルト |
トラフィック課金 | BGP (マルチ ISP) Pro | デフォルト | |
トラフィック課金 | BGP (マルチ ISP) | Anti-DDoS Pro/Premium |
EIP を ALB インスタンスに関連付ける場合は、次の制限事項に注意してください。
同じ ALB インスタンスの異なるゾーンに割り当てられた EIP は、同じタイプである必要があります。
ALB インスタンスに関連付ける EIP は、EIP 帯域幅プランに関連付けることはできません。EIP を ALB インスタンスに関連付けた後、ALB コンソールでインターネット共有帯域幅インスタンスを ALB インスタンスに関連付けることができます。インターネット共有帯域幅インスタンスは、EIP と同じ回線タイプを使用する必要があります。サブスクリプションインターネット共有帯域幅インスタンスと従量課金制インターネット共有帯域幅インスタンスがサポートされています。インターネット共有帯域幅インスタンスを ALB インスタンスに関連付ける方法の詳細については、「最大帯域幅の変更」をご参照ください。
帯域幅課金制の課金方法を使用するサブスクリプション EIP または従量課金制 EIP を ALB インスタンスに関連付けることはできません。
ALB インスタンスに EIP を割り当てる際に、[ EIP の購入 ] または [ EIP の自動割り当て ] を選択すると、トラフィック課金制の課金方法を使用する従量課金制 EIP が作成されます。EIP は BGP (マルチ ISP) 回線を使用し、Anti-DDoS Origin Basic によって保護されます。
内部向け ALB インスタンスに EIP を関連付けることはできますか？
はい、ALB インスタンスのネットワークタイプをインターネット向けに切り替えた後、内部向け ALB インスタンスに EIP を関連付けることができます。
内部向け ALB インスタンスに EIP を関連付けるには、インスタンスのネットワークタイプを変更します。内部向け ALB インスタンスをインターネット向け ALB インスタンスに変更できます。詳細については、「ALB インスタンスのネットワークタイプの変更」をご参照ください。
ネットワークタイプをインターネット向けに切り替えると、ALB インスタンスは EIP を使用してインターネット経由でサービスを提供します。インターネット経由のデータ転送に対して課金されます。詳細については、「従量課金」をご参照ください。
ALB コンソールで証明書をアップロードできますか？
いいえ、ALB コンソールで証明書をアップロードすることはできません。
ALB は Alibaba Cloud Certificate Management Service の証明書を使用します。ALB コンソール ではなく、Certificate Management Service コンソールで証明書をアップロードする必要があります。詳細については、「SSL 証明書のアップロード」をご参照ください。
ALB はトラフィックミラーリングをサポートしていますか？
はい、ALB はトラフィックミラーリングをサポートしています。詳細については、「本番トラフィックをステージング環境にミラーリングする」をご参照ください。
ALB インスタンスを IPv4 からデュアルスタック、またはデュアルスタックから IPv4 に切り替えることはできますか？
いいえ、ALB インスタンスの IP モードを切り替えることはできません。
IPv4 またはデュアルスタック ALB インスタンスを使用する必要がある場合は、作成してください。
DNS レコードを削除する際に注意すべき点はありますか？
アップグレードされた ALB インスタンスは、DNS レコードの削除と復元機能をサポートしています。
アップグレード前は、静的 IP モードの ALB インスタンスはこれらの機能をサポートしていましたが、動的 IP モードの ALB インスタンスはサポートしていませんでした。
ゾーンの DNS レコードを削除すると、ゾーンで使用されている VIP のプローブが停止します。同時に、ゾーンで使用されている EIP または VIP (IPv4 アドレスと IPv6 アドレスの両方を含む) が削除されます。IPv4 アドレスまたは IPv6 アドレスのみを削除することはサポートされていません。
WAF 2.0 の透過プロキシモードと WAF 3.0 のサービス統合モードの違いは何ですか？
次のセクションでは、WAF 2.0 の透過プロキシモードと WAF 3.0 のサービス統合モードの違いについて説明します。
WAF 2.0 の透過プロキシモード: リクエストが ALB または CLB に転送される前に、WAF によってフィルタリングされます。透過プロキシモードでは、リクエストは 2 つのゲートウェイを通過します。WAF と Server Load Balancer (SLB) のタイムアウト期間と証明書を構成する必要があります。
WAF 3.0 のサービス統合モード: WAF はバイパスモードでデプロイされ、リクエストは ALB に直接転送されます。リクエストがバックエンドサーバーに転送される前に、ALB はリクエストコンテンツを抽出して WAF に送信し、フィルタリングします。サービス統合モードでは、リクエストは 1 つのゲートウェイを通過します。これにより、ゲートウェイ間で証明書と設定を同期する必要がなくなり、同期の問題を防ぎます。
詳細については、「WAF 3.0 と WAF 2.0 の比較」をご参照ください。
WAF と ALB を統合するにはどうすればよいですか？
ALB は WAF 3.0 と統合されています。ALB インスタンスを WAF で保護する場合は、WAF 対応 ALB インスタンスを購入してください。WAF 対応 ALB インスタンスを購入する際は、次の情報にご注意ください。
Alibaba Cloud アカウントに WAF 2.0 インスタンスがない場合、または WAF をアクティブ化していない場合: WAF 対応 ALB インスタンスを購入することで、インターネット向けおよび内部向けの ALB インスタンスに対して WAF 3.0 を有効にすることができます。このようにして、ALB はサービスレベルで WAF とインターフェースされます。詳細については、「WAF 対応 ALB インスタンスのアクティブ化と管理」をご参照ください。
WAF 対応 ALB インスタンスをサポートするリージョン (ALB が WAF 3.0 と統合されているリージョン)
エリア
リージョン
中国
中国 (成都)、中国 (青島)、中国 (北京)、中国 (広州)、中国 (杭州)、中国 (烏蘭察布)、中国 (上海)、中国 (深圳)、中国 (張家口)、中国 (香港)
アジア太平洋
フィリピン (マニラ)、インドネシア (ジャカルタ)、日本 (東京)、マレーシア (クアラルンプール)、シンガポール、タイ (バンコク)
ヨーロッパおよびアメリカ
ドイツ (フランクフルト)、米国 (シリコンバレー)、米国 (バージニア)
中東
SAU (リヤド - パートナーリージョン)
Alibaba Cloud アカウントに既に WAF 2.0 インスタンスがある場合: ベーシックインターネット向け ALB インスタンスとスタンダードインターネット向け ALB インスタンスに対して、透過プロキシモードで WAF 2.0 を有効にすることができます。内部向け ALB インスタンスは WAF 2.0 をサポートしていません。
中国 (杭州)、中国 (上海)、中国 (深圳)、中国 (成都)、中国 (北京)、中国 (張家口) のリージョンにある ALB インスタンスのみを、透過プロキシモードで WAF 2.0 とインターフェースできます。
説明ALB インスタンスに対して WAF 3.0 を有効にする場合は、最初に WAF 2.0 インスタンスをリリースするか、WAF 3.0 に移行してください。
WAF 2.0 インスタンスをリリースした後、デフォルトでは ALB の X-Forwarded-Proto ヘッダーが無効になっているため、サービスエラーが発生する可能性があります。エラーを防ぐには、ALB インスタンスのリスナーに対して X-Forwarded-Proto ヘッダーを有効にする必要があります。詳細については、「リスナーの管理」をご参照ください。
WAF 2.0 インスタンスをリリースする方法の詳細については、「WAF サービスの終了」をご参照ください。
WAF 3.0 に移行する方法の詳細については、「WAF 2.0 インスタンスを WAF 3.0 に移行する」をご参照ください。
CLB と ALB は WAF 2.0 と WAF 3.0 をサポートしていますか？
サービス | WAF 2.0 (透過プロキシモード) | WAF 3.0 (サービス統合モード) |
CLB | サポートされています。 WAF 2.0 を透過プロキシモードで CLB に接続する方法の詳細については、次のトピックをご参照ください。 | サポートされていません。 |
ALB |
| サポートされています。 サポートされているリージョンと関連操作の詳細については、「WAF 対応 ALB インスタンスのアクティブ化と管理」をご参照ください。 |
WAF 2.0 を ALB または CLB に統合した後、タイムアウト期間と証明書が同期されないのはなぜですか？
WAF 2.0 を ALB または CLB に統合した後、クライアントリクエストは ALB または CLB に転送される前に WAF によってフィルタリングされます。リクエストは 2 つのゲートウェイを通過するため、WAF と ALB または CLB の間で設定を同期する必要があります。タイムアウト期間または証明書を変更すると、遅延により同期の問題が発生する可能性があります。
証明書が更新されない場合、またはタイムアウト期間の変更が有効にならない場合は、DingTalk グループ 21715946 に参加してご相談ください。
ALB インスタンスが、リスナーの転送ルールで構成されている最大 QPS に到達できないのはなぜですか？
仕組 み: ALB は、バックエンドサーバーのグループ間でネットワークトラフィックを均等に分散することにより、負荷分散サービスを提供します。転送ルールで構成する最大 QPS は、各バックエンドサーバーに均等に割り当てられます。
各バックエンドサーバーの最大 QPS は、次の式を使用して計算されます:
各バックエンドサーバーの最大 QPS = 合計 QPS/(N-1)。N はサーバーグループ内のバックエンドサーバーの数を示します。たとえば、転送ルールで最大 QPS を 1,000 に設定します。バックエンドサーバーの数が 8 の場合、各バックエンドサーバーの最大 QPS は次の式を使用して計算されます:1000/(8-1) = 142。原因: 少数の持続的接続が使用されるシナリオでは、サーバーグループ内のすべてのバックエンドサーバーに持続的接続が割り当てられるわけではありません。その結果、ALB インスタンスは最大 QPS に到達できません。
推奨事項: サービス中断を防ぐために、ビジネス要件に基づいて、転送ルールで最大 QPS を適切な値に設定することをお勧めします。転送ルールで最大 QPS を設定する方法の詳細については、「リスナーの転送ルールの管理」トピックの「転送ルールの作成」セクションをご参照ください。
ALB インスタンスで転送できるリクエストの最大サイズはどれくらいですか？許可される最大サイズを増やすことはできますか？
クライアントリクエストの URI または HTTP ヘッダーの最大サイズは 32 KB です。許可される最大サイズを増やすことはできません。アクセスログに記録できるカスタムヘッダーのデフォルトの最大サイズは 1 KB で、4 KB に増やすことができます。増加をリクエストするには、アカウントマネージャーにお問い合わせください。
クライアントリクエストの URI または HTTP ヘッダーのサイズが最大サイズを超えると、HTTP 400 または 414 ステータスコードが返される場合があります。詳細については、「ALB ステータスコード」をご参照ください。
大量のデータを送信する場合は、POST メソッドを使用してデータを送信することをお勧めします。ALB への POST リクエストの本文のサイズは最大 50 GB です。
同じバックエンドサーバー内のすべてのバックエンドサーバーが異常な場合、ALB インスタンスはどのようにリクエストを転送できますか？
ALB は、スケジューリングアルゴリズムに基づいてリクエストを分散し、サービスの可用性を維持します。この問題に対処するには、ログを確認してバックエンドサーバーでエラーが発生しているかどうかを判断するか、ヘルスチェックの設定を確認します。詳細については、「ALB ヘルスチェックの問題のトラブルシューティング」をご参照ください。
HTTP 500、502、503、および 504 ステータスコードが返されるのはなぜですか？
500 (Internal Server Error)
バックエンドサーバーで内部エラーが発生しました。リクエストはバックエンドサーバーによって処理できません。
考えられる原因:
バックエンドサーバーが HTTP 500 ステータスコードを返し、ALB はバックエンドステータスコードをクライアントに渡します。バックエンドサーバーが HTTP 500 ステータスコードを返す理由を確認してください。
バックエンドサーバーは、レスポンスを送信する前に接続を閉じます。バックエンドサーバーでパケットをキャプチャして原因を特定し、トラブルシューティングすることをお勧めします。
502 (Bad Gateway)
ALB の HTTP または HTTPS リスナーがリクエストをバックエンドサーバーに送信できなかったか、バックエンドサーバーからレスポンスが返されませんでした。その結果、HTTP 502 ステータスコードがクライアントに返されました。
考えられる原因:
バックエンドサーバーが HTTP 502 ステータスコードを返し、ALB はバックエンドステータスコードをクライアントに渡します。バックエンドサーバーが HTTP 502 ステータスコードを返す理由を確認してください。
ALB バックエンドサーバーは別の HTTP ステータスコード (504 や 444 など) を返しますが、ALB は HTTP 502 ステータスコードを返します。アクセスログの upstream_status フィールドと status フィールドを確認するか、パケットをキャプチャして、バックエンドサーバーにエラーがあるかどうかを確認することをお勧めします。
TCP 経由の ALB とバックエンドサーバー間の通信にエラーが含まれています。バックエンドサーバーが正常かどうか、サービスポートがリスナーによってリッスンされているかどうか、または TCP ハンドシェイクが成功するかどうかを確認してください。
バックエンドサーバーのバックログがいっぱいで、パケットがドロップされています。netstat を使用して、バックエンドサーバーのネットワーク統計にドロップされたパケットの数が表示されているかどうかを確認することをお勧めします。たとえば、
netstat -s | grep -i listenコマンドを実行できます。クライアントから送信されたパケットの長さが、バックエンドサーバーの最大転送単位 (MTU) を超えています。この場合、ヘルスチェックは成功するか、短いパケットが予期どおりに送信されます。ただし、長いパケットは予期どおりに送信されません。バックエンドサーバーでパケットをキャプチャして、パケットの長さが要件を満たしているかどうかを分析することをお勧めします。
バックエンドサーバーから返されたパケットの形式が無効であるか、無効な HTTP ヘッダーが含まれています。バックエンドサーバーでパケットをキャプチャして、HTTP レスポンスの形式が無効かどうかを確認することをお勧めします。
ALB のバックエンドサーバーがリクエストの処理を完了していません。バックエンドサーバーのログデータを確認してください。また、CPU とメモリの使用量も確認してください。
503 (Service Temporarily Unavailable)
サービスは利用できません。これは、トラフィックが制限を超えているか、バックエンドサーバーが利用できないためです。
考えられる原因:
バックエンドサーバーが HTTP 503 ステータスコードを返し、ALB はバックエンドステータスコードをクライアントに渡します。バックエンドサーバーが HTTP 503 ステータスコードを返す理由を確認してください。
クライアントからのネットワークトラフィックが ALB のスロットリングをトリガーしています。次のいずれかの方法を使用して、問題のトラブルシューティングを行うことができます。
CloudMonitor コンソールで 1 秒あたりのリクエスト数を確認します。詳細については、「ALB 監視メトリック」および「ALB インスタンスに関する監視情報の表示」をご参照ください。
CloudMonitor は監視データを分単位で表示します。アクセスログを使用して、1 秒あたりのリクエスト数を確認できます。アクセスログの upstream_status フィールドを表示します。コンテンツが「-」の場合、リクエストはバックエンドサーバーに送信されません。
レスポンスヘッダーに ALB-QPS-Limited:Limited フィールドが含まれているかどうかを確認します。含まれている場合、リクエストが ALB スロットリングをトリガーしたことを示します。
クライアントが ALB にアクセスする際に、ドメイン名を使用する代わりに ALB の IP アドレスにアクセスするか、クライアントがドメイン名を使用して ALB にアクセスする際に DNS 解決結果を更新しません。その結果、リクエストを複数の ALB IP アドレスに分散できず、HTTP 503 エラーコードが返されます。クライアントは IP アドレスではなく、ALB のドメイン名にアクセスすることをお勧めします。また、クライアントが DNS によって返された異なる IP アドレスを使用して ALB にアクセスしていることを確認してください。
ALB リスナーにバックエンドサーバーが関連付けられていないか、バックエンドサーバーの重みが 0 に設定されています。
504 (Gateway Time-out)
バックエンドサーバーのレスポンスがタイムアウトしました。
考えられる原因:
バックエンドサーバーによって 504 ステータスコードが返された場合は、バックエンドサーバーが過負荷になっているかどうかを確認してください。
ALB からバックエンドサーバーへの接続がタイムアウトしました。タイムアウト期間はデフォルトで 5 秒に設定されています。アクセスログの upstream_connect_time フィールドが 5 秒または約 5 秒に設定されているかどうかを確認できます。パケットをキャプチャして、レスポンスのタイムアウトの原因を特定することをお勧めします。
バックエンドサーバーのワークロードが重く、レスポンスを返すのに必要な時間が指定されたタイムアウト期間よりも長くなっています。たとえば、リクエストのタイムアウト期間が 60 秒に設定されているとします。応答時間が 60.001 秒の場合、ALB は HTTP 504 ステータスコードを返します。CloudMonitor コンソールまたはアクセスログで、問題が発生した期間のネットワーク遅延を表示できます。ネットワーク遅延を表示するには、CloudMonitor の upstream_rt フィールド、またはアクセスログの upstream_response_time フィールドを確認します。
ALB Ingress を使用する際に注意すべき点はありますか？
ALB Ingress コントローラーは、AlbConfig オブジェクトを使用して ALB インスタンスを構成します。 ALB Ingress コントローラーを使用して作成された ALB インスタンスの構成は、ALB コンソールで手動で変更しないことをお勧めします。 ALB Ingress の詳細については、「ALB Ingress の管理」および「ALB Ingress の機能」をご参照ください。
ALB コンソールで、ALB Ingress コントローラーを使用して作成された ALB インスタンスの構成を手動で変更すると、手動で変更された構成は AlbConfig オブジェクトによって上書きされます。これにより、アクセスログ機能の無効化やルーティングルールの削除などの例外が発生する可能性があります。
ALB の CORS 機能に関する FAQ
オリジン間リソース共有 (CORS) の設定が有効にならないのはなぜですか？また、ブラウザがプリフライトリクエストエラーをスローするのはなぜですか？
[ 許可されたリクエストヘッダー ] パラメーターにアスタリスク (*) ではなく特定のヘッダー名が指定されている場合は、テストのために [ 許可されたリクエストヘッダー ] をアスタリスク (*) に設定できます。問題が解決した場合は、Access-Control-Request-Headers の header_name 属性が構成に含まれているかどうかを確認してください。含まれていない場合、header_name 属性がないことが失敗の原因です。
プリフライトリクエストと実際のリクエストで異なる転送ルールが採用されるのはなぜですか？
ALB は、転送ルールに対して複数のマッチング方法をサポートしています。ただし、CORS のプリフライトリクエストのヘッダーとメソッドは特殊であり、実際のリクエストとは異なります。CORS を使用する場合は、ドメイン名を使用して転送ルールを構成することをお勧めします。これにより、プリフライトリクエストと実際のリクエストが、CORS ルールで構成されていない転送ルールと一致しなくなります。