レンタルサーバーうんちく「KAGOYAライトプラン専有」サーバーの使用感・不具合とその顛末

trivia レンタルサーバーうんちく「KAGOYAライトプラン専有」サーバーの使用感・不具合とその顛末 最終更新日: 2026年6月30日

サーバーはサイト運営においてはかなり重要です。
重要なのはコストですが、使用・サイト運営要件に対するパフォーマンスを考慮したコスパが最重要となるのは言うまでもありません。

ここでは当studioが利用しているKAGOYのライトプラン/1コア4GB専有の使用感・不具合を、経験に基づいた感想と合わせて書いています。

カゴヤ側は「アプリケーション内部処理は正常だが、同時アクセス時の待機（キューイング）が発生している」と返答していますが内部処理が33ミリ秒で終わり、メモリも4MBしか食わない軽量ページに対して
秒間数千規模の処理すら捌けずに詰まる（p95が20秒超に跳ね上がる）というのは
「専有サーバー」のスペックとしては明らかに異常（あるいは、Webサーバー層やPHP-FPMのプロセス上限が極端に絞られている証拠）

選んだ要件

過去にcoreサーバーやxサーバーも使用していました。
xサーバーは利用者も多く好意的な意見も多かったようですが、当方2000～3000ページからなるMovableType（以下MT）によるサイトも運営しており、共有では時間帯によりリソースひっ迫しMT更新（投稿）がタイムアウトすることも少なくなく、滅多にやらないが全体または全投稿の再構築ではタイムアウトが頻発したことから以降の運営上サーバー移転は必須となりました。
費用では月額が2000円内を考えたが、一部VPSを除くとKAGOYAのライトプラン以外該当するものがありませんでした。
VPSも検討したが、サーバー知識が拙いとどうなのかという不安から検討外、ほぼ一択でこのサーバーに乗り換えました。

移転後

数千ページのMT再構築、その前のXサーバーでは40分かかるのもザラでしたが、このサーバーでは20～30分。複数サイトで同時に再構築をするとタイムアウトするが、全体または全投稿再構築など滅多にやらないことなので特に問題はありませんでした。
サポートは人によりけりで、良い担当にあたると納得できるがそうでない方にあたると良い気がしないことも有りました。
サービス全体としては、とにかく案内不足が酷く移転後の各種設定で、KAGOYAサイトのマニュアルを見ても情報が古いなどはザラで、ライトプランがまだ新しい頃だったのでとても不便でした。
また、ファイルマネージャーは無く、phpmyadminもユーザーがインストール（ほぼ置くだけですが）しないと無いのでVPSには知識が拙いからこの専有プランとして利用しても、一般的なレンタルサーバーよりハードルは高くなります。

パフォーマンス

流石専有といった感じで、MTサイト複数（といってもマルチ式でサイトは2）、Wordpress（以下WP）サイト複数運用し、アクセスは多くても100/日あればいいかなといった程度であれば何も問題はないですね。
数千ページのサイトが静的なのでアクセスによるサーバー負荷が低いことも、比較的良好な状態で使えた要因かもしれません。

今回、当報告を書くに至った事件・障害

2025年秋ごろよりWPを使ったシステム開発を始めた。
時にコードミスで無限ループを起こし、サーバー停止となることもあった。
専有なので良かったといったところだが、昨秋10月に無限ループした際は通常140程度が上限のプロセスを25程度に下げられた。
当時サポートからは高負荷だから上限下げたと言われ、それも仕方ないと思っていた＝サーバー知識が拙い故だが、1か月以上その状態が続いた。
25から140になったのは、開発を行う中でサーバー負荷を意識するようになったが、プロセス制限がかかった中では開発に差しさわりがでるようになったことから戻すようにサポートに冀ったからだった。
140に戻す際、サポート担当曰く「再発の可能性を了承しろ」といったことも言ってきたが、無限ループは無いがそれに近しいことなどは開発中に起きていたので、制限あると逆に開発が進まないことからも了承した。

単なるwebでなくシステム故の問題

システム自体は一か月半程度で完成に至ったが、同時アクセス数が20程度でサーバーが高負荷状態になり、システムがその役割を果たさなくなった。
WPを使ったことが主因、無駄にコアが働くことでajaxが走ってDB忙しい、phpが働くのもとにかく負荷いなる。
システムをプラットフォーム無しで作るのは、その管理画面からなにから設計・制作しないといけない。WPテーマ程度に考えたシステムだが、実用を考慮するとWP機能を一部使ったシステムといった体にしないと間に合わない。
もちろん、原因がサーバー負荷であるので全てajaxDB参照に耐えるサーバーなら何ら問題ないが、明らかにコスパ悪い。
そこで各ページの基礎情報=postmetaのみ参照し、他はjson直ポーリングによるリアルタイム動的情報提供とするように作り直しを始めた。

WPが未だに抱える不始末

もともとブログエンジンであるが、特にMT有償化以降企業サイトなどでも急速に使われるようになった。
ブログエンジンとしての要件・仕様は、簡単にインストール出来て覚えればコーディングも比較的楽ではあるが、その汎用性が無駄にサーバー負荷をかける諸悪の根源でもある。
最新の7xですら、アクセスすると走るajaxや発生するクエリに無駄が多い。
当該システムの負荷低減にはこれらを無くすことも必要だった。

KAGOYAライトプランの障害

長期間にわたるやり取りと、Muninグラフ・アクセスログ・クエリログ・K6テスト結果・複数AIによる検証を経て、当方が下した結論を先に書く。

① 5/27の障害復旧は「仮復旧」だった可能性が高い。

障害の復旧に7時間以上を要したこと自体、一般的なレンタルサーバー障害と比べて異常に長い。ChatGPT・Gemini・Grokのいずれもこの点を指摘した。さらにKAGOYAが「復旧」を告知した後も、当方環境ではMySQL接続拒否・OOM・504エラーが継続した。I/O負荷グラフの正常化のみを根拠に「復旧済み」とし、実際のサービス提供品質が戻っていない状態のまま告知したとしか読めない。

② 無告知のプロセス制限が、「復旧後」遅延の正体だった。

Muninのプロセスグラフでは5/27夕方からBusy serversの天井が140前後から25前後へ低下している。KAGOYAが無告知でApacheプロセス上限を絞ったことを示す。「復旧した」との告知を出しながら実際はプロセス数を1/5以下に制限していた。昨秋の制限時には事前告知があったが、今回は一切なかった。ユーザーが自ら気づき抗議して初めて認め、解除した。

③ 「当方IPからのPOSTが原因」という説明は根拠にならない。

KAGOYAが問題視したアクセス数（秒間1.7〜2.0回）を当方のクエリログと照合すると、1リクエストあたりDBクエリ14件・合計処理時間0.003〜0.02秒・SLOWクエリ0件という極めて軽量なものだ。同程度の操作は5/26にも毎日行っており、その日は何も起きていない。具体的にどのファイルのどの処理が何件のプロセスを滞留させたかを示す数値・ログは、結局一度も提示されなかった。

④ 6/9以降の再悪化も、コード変更なしで発生している。

PHPバージョン変更と連動してパフォーマンスが劇的に変化する現象は、当方コードでは説明がつかない。サーバー側で何らかの制限・調整が動いていると考えるのが自然だが、KAGOYAは「意図的な変更はない」の一点張りで、具体的なログ・根拠を一切提示していない。

5/27 障害発生とその顛末

障害発生（5/27 5:08〜）
2026年5月27日朝、開発作業を始めようとしたところWP管理画面にもアクセスできない状態だった。同サーバー上の別サイトも全て重く、500番台エラーが頻発した。緊急サポートに連絡しつつKAGOYAの障害情報を確認すると以下の告知が出ていた。

復旧に7時間9分を要した。一般的なレンタルサーバーの障害復旧にしてはかなり長い部類で、商用サイトならダメージも大きい。当方も半日以上まともに作業できない状態が続いた。
参考資料として、その時の管理画面内のグラフを添付する。

「復旧」後の異常継続

12時を過ぎたころ管理画面へのアクセスが軽くなったことから復旧と判断し、開発作業を再開した。しかし間もなく再び遅延が始まった。リソースモニター（Munin）を確認すると、CPU systemが80%前後に張り付き、irqも通常より高い値が続いていた。
この状態をサポートに連絡した。

5/27 16:48のKAGOYA最初の返信の引用

本日午前5時頃より発生した障害については、12時10分に復旧いたしました。
今回お問い合わせいただいた状況は、本日発生した障害とは別に、これまでも幾度かお問い合わせをいただき、ご案内しております通り、ご利用ウェブサーバーでは、ご利用ウェブサイトが必要とするリソースが不足していることで発生しています。過去にもご案内いたしました通り、上位プランへの移行をご検討ください。

午前中ずっとサーバーが応答不能で、リロードやタブ切り替えを繰り返して生存確認をしていた状態で、復旧したと思って作業を再開したら遅延が続いている、という状況にもかかわらず、返ってきたのは「リソース不足・上位プランへ移行を」という内容だった。意味が解らなかった。
サポートフォームからも強く抗議したところ、5/27 18:28に上席名義で返信が来た。

このたびは、当社対応および現在のサーバー状況により多大なご不便とご不信をおかけしておりますこと深くお詫び申し上げます。
現在ご指摘いただいております内容につきましては、社内関係部門に事実関係の確認と整理を改めて行っております。上記につきまして整理のうえ明日（5月28日）に改めて正式な見解、および対応方針をご案内申し上げます。

プロセス制限の発覚（5/28）

翌5/28朝のMuninグラフを確認すると、5/27夕方以降のプロセスグラフの天井が明確に下がっていた。Busy serversが140前後から25前後に固定されたままになっている。
この「人工的な渋滞」がCPU userを85%以上に張り付かせ、通常操作すら遅延していた原因だったと考えらえる。

5/28 10:27のKAGOYA返信の引用

現在のプロセス上限につきましては、引き続き制限を設けている状況でございます。
当該制限につきましては、仮に上限を引き上げた場合、現在のサーバースペックではアクセス集中時に負荷に耐えられず、サーバーダウンが発生する可能性があるため、やむを得ず実施しております。

ここで初めてプロセス制限を認めた。しかし「やむを得ず」の根拠として指摘されたのが当方IPからのPOSTアクセス集中というものだった。

当方からの反論

IPアドレス 58.91.89.130 からのアクセスのほとんどは、そのページのリロードやタブ復帰による通信に拠ります。
昨日は午前中の貴社インフラ障害によりサーバーが応答不能・極めて不安定だったため、ブラウザでタブのアクティブ/非アクティブ切り替えやリロードを1時間あたり数回〜10回以上行い、開発中のクエリ再送が発生しました。
貴社がこれを「大量POSTアクセスによる負荷」と報告したのは、原因と結果を完全に逆転させたものです。

5/28 12:40のKAGOYA返信では、ようやく5/27の経緯が2つの事象に整理された。

■① 全体障害（共通事象）　発生時間：5時08分 ～ 12時17分

サーバー側の定期処理に伴うI/O負荷の増大により、サーバーに接続しづらい状況が発生しておりました。当社にて再起動を実施し、負荷軽減を確認したうえで復旧としております。

■② 個別環境での高負荷事象　発生時間：14時頃～

以前より継続的に発生しておりました大量のPOSTアクセスにより、高負荷状態となっておりました。サーバーダウンのリスクを回避するため、一時的にプロセス上限の制御を行っておりましたが、5月28日15時55分頃に当該制御を解除しております。
しかしながら、5月27日16時48分の当社からのご案内において、プロセス制御の実施内容について十分にご説明できておらず、結果として混乱を招いてしまいました点につきまして、深くお詫び申し上げます。

「プロセス制御の実施内容について十分にご説明できなかった」ことへの謝罪はあったが、無告知で実施したこと自体の責任については言及がない。また補償については以下の通り。

プロセス制限を実施していた期間に関する補償につきましては、当社としてはサーバーダウン回避および安定稼働を目的とした措置として実施したものであることから、現時点では返金等の対応はいたしかねる認識でございます。

当方の強い要請を経て、5/28 16:28にプロセス上限がMunin上で140前後に戻ったことを確認できた。
とはいえ他人事と感じられる管理体制・サポート、何より性能を見て契約したが容易に移転を奨めるサポート要員など、不信感を抱くだけの結果だった。

復旧後の確認と再障害（5/30）

プロセス上限が戻ったことで、開発作業を進め併せてK6 100VUSの負荷試験を実施したところ、WPページにもかかわらず応答速度が静的ページ並みという良好な結果が出た。
しかし5/29 18時頃・5/30朝9時頃と、立て続けに障害が再発した。
当方はこの間サイトへのアクセスすらしていなかった。5/30朝の障害は午前中のうちに収束したが、5/30夜にはCPU systemが83.35%で張り付き、memoryにも大きなスパイクが発生する状態が再び起きた。5/31以降は急に安定し、K6 100VUS試験でも正常な数値に戻った。
当方はこの間サイトへのアクセスすらしていなかった。

5/30の当方からの報告

ログオン状態でsingleページを普通に開いただけでサーバーがほぼ停止状態（504 Gateway Timeout、データベース接続エラー多発）となりました。
PAGEロード時のクエリ数：39件（ほとんどがCACHE_HITS）

総クエリ時間：0.0206秒

SLOWクエリ（10ms以上）：0件
wp-cronが起動した程度のWordPress標準動作でこの状況になるのは異常です。プロセス制限を解除していただいたにもかかわらず改善が見られないということは、サーバー全体が低負荷時でしかまともに耐えられない状態であることを示しています。

また5/30のMuninグラフではCPU systemが83.35%で張り付き、memoryにも大きなスパイクが確認された。
これに対するKAGOYAの6/1回答が、「5/27障害との直接的な関連はない」「当方IPからのアクセス集中が一因」という内容だった。

6/2にKAGOYAはサーバーログを添付した上で以下を示した

2026年5月27日 14:07以降、当社サーバーにおいてOut of memory（メモリ不足）が継続的に発生していることを確認しております。MySQLプロセスの終了および再起動が繰り返され、サーバーのリソースが逼迫していた状態となります。また、同様の事象は2026年5月30日 09:19以降にも発生しております。
Out of memoryが発生している時間帯において、開発環境IP（58.91.89.130）から以下のアクセスを確認しております。

14時〜15時：6,133回

15時〜16時：7,076回

16時〜17時：7,261回

凡そ1秒に1.7〜2.0のアクセス数

KAGOYAはOOM発生とIPからのアクセスが同時刻であることを根拠に因果関係を主張したが、当方が提出したその時間帯のクエリログは1リクエストあたりDBクエリ14件・合計0.005〜0.02秒・SLOWクエリ0件というものだった。5/30のログも同水準だった。

当方からの反論（6/2当方メール引用）

この内容のものをさばききれないサーバーが、「仮想専用サーバー（1コア4GB）」としての契約仕様を満たしているとは到底考えられません。
当方責務と言われるなら、具体的にどのファイルのどの関数などがどのように甚大なプロセス/クエリ/負荷を発生させたか、正確なログなどをいただけますか。
障害当日である5/27以降、開発作業が著しく滞り、極微差な開発作業しかしていない。当方テーマは5/27と微細な違いしかないが5/30にまた度重なる障害が起きたが、5/31には問題が起きていない。また障害前日の5/26にも問題はなかった。

「5/27と5/30は障害が起き、5/26と5/31には何も起きていない。コードはほとんど変わっていない。」という時系列の異常をKAGOYAは「時系列上の変化のみから原因を特定することはできない」として退けた。
6/4・6/8の返信は一字一句同じ文面のコピペで届き、「当社の見解は本回答をもって最終とさせていただく」という一文が添えられていた。当方が「同じ文面のコピペは顧客対応として失礼だ」と指摘したが、それに対する謝罪や説明も特になかった。

同条件テストによるBusy servers大幅下落（6/9〜）

5/31以降は安定していたが、6/9朝にMuninのBusy serversグラフを確認すると、前日まで Max 104〜110前後だったものが63前後で頭打ちになっていた。総スロット143のうち実効処理が半分以下という状態だ。コードに一切変更はしていない。

当方からの指摘（6/10 13:00）

MuninのApache processesグラフより、

・6月7日（良好時）：Busy servers Max 104.96

・6月9日（問題時）：Busy servers 63前後で頭打ち

この差について、技術的な説明をいただけますか。

KAGOYAの回答（6/11 17:01）

Muninに表示されるBusy serversの値は、Apacheにおいて実際に処理中のプロセス数を示すものであり、設定上の固定された上限値を直接示すものではございません。当該値はアクセス状況や処理時間、プロセスの滞留状況、およびシステムリソースの使用状況によって動的に変動するものです。

「動的変動」という説明では、同一コード・同一テスト条件で前日比が半減した事実の説明にならない。

さらに当方が指摘した逆相関（6/14 9:43）

Busy serversが63前後で頭打ちとなっている時間帯においては、CPU使用率およびメモリ消費が逆に大幅に増加していることを確認しております。プロセス数が少ない（63程度）にもかかわらずリソース消費が爆増。6月7日の良好時（Busy Max 104前後）と比較して明確な差。

プロセス数が少ないほうがCPU・メモリを食うという逆相関は、並列処理が制限された状態でリクエストが滞留し、各プロセスが長時間CPUを占有し続けることで起きる典型的なパターンで、5/27〜5/28のプロセス制限時に体験した現象とまったく同じ挙動だった。

PHPバージョン変更による劇的改善と再悪化

単発アクセスでは極軽量のWPぺージがK6負荷試験などで異常遅延を起こす、その原因を当方なりにさぐったが、PHPのバージョンが8.2ｘだった。
6/7にPHPを8.4系から8.5.6に変更したところパフォーマンスが大幅に改善、K6 100VUS試験のp95が1秒前後まで回復しBusy serversも110前後に戻った。しかし6/9にコードを一切変更していないにもかかわらず再び悪化した。
そこで試しに6/14にPHPを8.5.6から8.4.21に戻したところ即座に改善。

PHP8.5時（悪化時）：p95 = 数十秒超・エラー多発
PHP8.4変更後（改善時）：p95 = 1秒前後・エラーほぼなし

PHP設定変更により並列処理遅延発生がテスト環境・設定上20倍も改善することに気が付き、6/16以降管理画面と合わせてキャプチャし証拠保全に努めるようにした。上はその前々日に変更し良化したが経時悪化した際のもの。
こちらはPHP8.5.6だったが8.4.21に変更後。P95の数値＝ページロード時間が20秒から1秒以内に劇的改善。
こうした証拠を送っているにもかかわらず、KAGIYA側は当該試験中行ってもいないPOST過多を原因とし、サーバーに異常はないとの回答を継続したことから、サポートではなく企業として事実に基づいた篤実な解答を求めるべく、サポートではなく上位決済のできる方への担当変更なども要望した。

当方からのエスカレーション依頼他（6/16 9:25）

PHPバージョンを変更するだけでここまで明確に挙動が変わる事実は、サーバー側に何らかの調整・制限・監視が働いていることを強く示唆していると考えます。この点について、技術部門による調査と具体的なご説明をいただきたく、技術・運用責任者へのエスカレーションを正式に依頼いたします。

KAGOYAはこれに対し

「サーバー側で同時プロセス数の制限を意図的に変更した事実はない」と繰り返すのみで、具体的な監視ログ・調査結果の提示は現時点でなされていない。
この主張を繰り返すばかりで、毎日Loaderによる1分テストでのavg resp timeを確認し1秒超えていればK6による負荷10分テスト行い不具合状態にあることを確認し、設定変更から改善確認のK6テストでの確認を強いられている状況が継続した。

PHP設定変更はなんでもよかった

ここまでPHPのバージョン変更で対応してきたが、試しにメモリーリミットや他の項目での数値変更でも改善するか試してみた。
ページロードはこのテスト上では20秒かかる。
メモリーは128M設定にしてあったが、64に下げてのもの。

128Mを64Mと半分にしても軽量ページなので100VUSでも問題はない。
並列処理が極めて狭められていることが解るが、100VUSといっても常時100ではなく、毎秒だが10～20程度、キャッシュされない新規アクセスとはいえこの極軽量ページに対する同時アクセスが二桁程度でボトルネックに引っ掛かるなど現代のレンタルサーバーでは考えられないことであり、専有サーバーであれば尚更酷い状態である。
勘違いしてほしくないのは、改善後は100VUSでも余裕であり、当方が契約した1コア4GBの性能には満足できるものであると言うこと。
リソースモニターをみても、設定変更を挟んだ時系列の同試験でのグラフは大きく異なるが、初期性能を普通に発揮できれば現状において異論もサポート以外に不満は無い。
しかしユーザーがPHP設定を変えないと初期性能が発揮できないという故障には不満であり、それに対し返金も保障もなく移転推奨のみとする企業運営には倫理や道徳はもちろん、法順守さえも行わないと見える現状合わせた全てが不満・不信である。

再現性

PHPのバージョン変更、メモリーリミット数値変更、session.gc_maxlifetime、項目すべてまたは変更なしで更新でもいいのかもしれないが、PHP設定変更で劇的改善する。
朝作業開始前に一度Loaderで1分試験、ここで1秒・概ね600ms未満なら良いが、1300ms以上の場合はK6で100VUSテストを行うと平均で20秒もページロードにかかる最悪な状態。
繰り返すが、ページはWP動的生成とはいえ

• リクエスト手法（METHOD）
  GET（通常ページ遷移）
• 総クエリ数（TOTAL_QUERIES）
  14 回
• データベース純処理時間（TOTAL_Q_TIME）
  0.0033 秒（3.3ミリ秒）
• プログラム全体実行時間（TOTAL_EXEC_TIME）
  0.0339 秒 〜 0.0343 秒（約34ミリ秒）
• 使用メモリ量（MEM_USED）
  32.00 MB（計測コア純増分：4.00MB）
• 総読込ファイル数（TotalFiles）
  514 個
• テーマ内読込ファイル数（Theme）
  16 個
• プラグイン干渉（TopPlugins）
  string-locator (23) / disable-emojis (2) / wordpress-importer (1)

このように極軽量である。

参考にデバグログに出力した内容は以下の通り。

========================================================================================
[SAVEQUERIES_TOTAL] TYPE:PAGE | TRIGGER:PAGE_LOAD | ACTION:none | URI:/2nd-3scup/s-class/9001001.php | REFERER:direct
[STATS] TOTAL_QUERIES: 14 | TOTAL_Q_TIME: 0.0033s | TOTAL_EXEC_TIME: 0.0339s | MEM_USED: 4.00MB
[DETAILED QUERIES]
[1] TIME: 0.0005s | SQL: SELECT option_name, option_value FROM wp_3soptions WHERE autoload IN ( ‘yes’, ‘on’, ‘auto-on’, ‘auto’ )
[2] TIME: 0.0003s | SQL: SELECT option_name, option_value FROM wp_3soptions WHERE option_name IN (‘_site_transient_wp_theme_files_patterns-9e51b52134ece57cfc25bbad50924a34’,’_… [LONG SQL TRUNCATED]
[3] TIME: 0.0003s | SQL: SELECT ID, post_name, post_parent, post_type FROM wp_3sposts WHERE post_name IN (‘2nd-3scup’,’s-class’,’9001001-php’) AND post_type IN (‘page’,’attach… [LONG SQL TRUNCATED]
[4] TIME: 0.0002s | SQL: SELECT wp_3sposts.* FROM wp_3sposts WHERE 1=1 AND wp_3sposts.ID = 9001001 AND wp_3sposts.post_type = ‘post’ ORDER BY wp_3sposts.post_date DESC
[5] TIME: 0.0003s | SQL: SELECT DISTINCT t.term_id, tr.object_id FROM wp_3sterms AS t INNER JOIN wp_3sterm_taxonomy AS tt ON t.term_id = tt.term_id INNER JOIN wp_3sterm_relati… [LONG SQL TRUNCATED]
[6] TIME: 0.0002s | SQL: SELECT t.*, tt.* FROM wp_3sterms AS t INNER JOIN wp_3sterm_taxonomy AS tt ON t.term_id = tt.term_id WHERE t.term_id IN (95)
[7] TIME: 0.0002s | SQL: SELECT post_id, meta_key, meta_value FROM wp_3spostmeta WHERE post_id IN (9001001) ORDER BY meta_id ASC
[8] TIME: 0.0002s | SQL: SELECT t.term_id FROM wp_3sterms AS t INNER JOIN wp_3sterm_taxonomy AS tt ON t.term_id = tt.term_id WHERE tt.taxonomy IN (‘category’) AND t.slug IN (‘… [LONG SQL TRUNCATED]
[9] TIME: 0.0001s | SQL: SELECT t.*, tt.* FROM wp_3sterms AS t INNER JOIN wp_3sterm_taxonomy AS tt ON t.term_id = tt.term_id WHERE t.term_id IN (60)
[10] TIME: 0.0002s | SQL: SELECT t.*, tt.* FROM wp_3sterms AS t INNER JOIN wp_3sterm_taxonomy AS tt ON t.term_id = tt.term_id WHERE t.term_id = 94
[11] TIME: 0.0003s | SQL: SELECT term_id, meta_key, meta_value FROM wp_3stermmeta WHERE term_id IN (95,94) ORDER BY meta_id ASC
[12] TIME: 0.0002s | SQL: SELECT user_id, meta_key, meta_value FROM wp_3susermeta WHERE user_id IN (26) ORDER BY umeta_id ASC | CALLER: require(‘wp-blog-header.php’), require_once(‘wp-includes/template-loader.php’), include(‘/themes/initialize/single.php’), the_post, WP_Query->the_post, update_post_author_caches, cache_users, update_meta_cache
[13] TIME: 0.0002s | SQL: SELECT * FROM wp_3susers WHERE ID IN (26)
[14] TIME: 0.0002s | SQL: SELECT option_name, option_value FROM wp_3soptions WHERE option_name IN (‘auth_key’,’auth_salt’,’secure_auth_key’,’secure_auth_salt’,’logged_in_key’,’… [LONG SQL TRUNCATED]
========================================================================================
========================================================================================================================
[USER:GUEST ] REQ: /2nd-3scup/s-class/9001001.php | METHOD:GET | AJAX:NO | ACTION:N/A
[USER:GUEST ] STATS: Time:0.0343s (DB:0.0033s) | Mem:32.00MB | TotalFiles:514 | Queries:14
[USER:GUEST ] FILES: Theme:16 | TopPlugins: string-locator(23), disable-emojis(2), wordpress-importer(1)
[USER:GUEST ] [DBQ] 0.0005s | TBL:? | FUNC:? | SQL:SELECT option_name, option_value FROM wp_3soptions WHERE autoload IN ( ‘yes’, ‘on’, ‘auto-on’, ‘a…
[USER:GUEST ] [DBQ] 0.0003s | TBL:? | FUNC:? | SQL:SELECT option_name, option_value FROM wp_3soptions WHERE option_name IN (‘_site_transient_wp_them…
[USER:GUEST ] [DBQ] 0.0003s | TBL:? | FUNC:? | SQL:SELECT ID, post_name, post_parent, post_type FROM wp_3sposts WHERE post_name IN (‘2nd-3scup’,’s-c…
[USER:GUEST ] [DBQ] 0.0002s | TBL:? | FUNC:? | SQL:SELECT wp_3sposts.* FROM wp_3sposts WHERE 1=1 AND wp_3sposts.ID = 9001001 AND wp_3sposts.post_typ…
[USER:GUEST ] [DBQ] 0.0003s | TBL:? | FUNC:? | SQL:SELECT DISTINCT t.term_id, tr.object_id FROM wp_3sterms AS t INNER JOIN wp_3sterm_taxonomy AS tt …
[USER:GUEST ] [DBQ] 0.0002s | TBL:? | FUNC:? | SQL:SELECT t.*, tt.* FROM wp_3sterms AS t INNER JOIN wp_3sterm_taxonomy AS tt ON t.term_id = tt.term_…
[USER:GUEST ] [DBQ] 0.0002s | TBL:? | FUNC:? | SQL:SELECT post_id, meta_key, meta_value FROM wp_3spostmeta WHERE post_id IN (9001001) ORDER BY meta_…
[USER:GUEST ] [DBQ] 0.0002s | TBL:? | FUNC:? | SQL:SELECT t.term_id FROM wp_3sterms AS t INNER JOIN wp_3sterm_taxonomy AS tt ON t.term_id = tt.term_…
[USER:GUEST ] [DBQ] 0.0001s | TBL:? | FUNC:? | SQL:SELECT t.*, tt.* FROM wp_3sterms AS t INNER JOIN wp_3sterm_taxonomy AS tt ON t.term_id = tt.term_…
[USER:GUEST ] [DBQ] 0.0002s | TBL:? | FUNC:? | SQL:SELECT t.*, tt.* FROM wp_3sterms AS t INNER JOIN wp_3sterm_taxonomy AS tt ON t.term_id = tt.term_…
[USER:GUEST ] [DBQ] 0.0003s | TBL:? | FUNC:? | SQL:SELECT term_id, meta_key, meta_value FROM wp_3stermmeta WHERE term_id IN (95,94) ORDER BY meta_id…
[USER:GUEST ] [DBQ] 0.0002s | TBL:? | FUNC:? | SQL:SELECT user_id, meta_key, meta_value FROM wp_3susermeta WHERE user_id IN (26) ORDER BY umeta_id ASC
[USER:GUEST ] [DBQ] 0.0002s | TBL:? | FUNC:? | SQL:SELECT * FROM wp_3susers WHERE ID IN (26)
[USER:GUEST ] [DBQ] 0.0002s | TBL:? | FUNC:? | SQL:SELECT option_name, option_value FROM wp_3soptions WHERE option_name IN (‘auth_key’,’auth_salt’,’…
————————————————————————————————————————

過去に数社のレンタルサーバー、それも共有サーバーを使ってきたし、今も管理業務でさくらなども扱っているが、この程度の軽量ページへの同時アクセス数100程度で20秒の遅延が発生するなど、一般論ではあり得ない。
ましておや対象サーバーは「1コア4GB専有」であることからすれば「優良誤認」か「故障」かと考えてしまうのは当然、優良誤認と言うと詐欺だのなんだのとなるから言い控えるが、現在までのやり取りを総合すると

• 返金など補償はしない
• ユーザーである当方ページによるajax発生過多などが原因
• 後に当方ページ・サイトが一因とするが、他の要因には触れず
• 当方は生ログ・スクリーンキャプチャによる証拠、再現証拠も複数渡しているが、それに対する具体的な反証や検証はない
• 単に「意図的な制限はかけていない」の繰り返しで、意図したか否かは関係なく、翌日には再発している物理的な事象に対する対応を要望しても「意図的な制限はない」の繰り返し
• サーバーに異常はないし説明もしたので今後は対応しないとも言ってきた

6/22日のKAGOYAからの返信だが、

＞・お客様アカウントに対して、サーバー側で意図的な設定変更や制限の変更を行った事実はないこと
上記につきましては、当社として確認した結果に基づくご案内でありご案内可能な内容は上記の通りです。
また、5月27日発生の障害以降、同じサービスの全ホストに対して
一律の制限付与を行った事実もございません。

＞・本事象は特定の単一要因で説明可能なものではなく、複合的な要因により発生するものであること
＞・そのうえで、お客様環境における負荷状況が一因となっているとの認識であること
本事象は複合的要因によるものであり、特定の単一要因に帰属できるものではございません。
当社にて確認した限り、サーバー側に不具合は確認されておらず、以前にもご案内しております通り、
実際のサーバー負荷は、アクセス回数だけではなく、アクセス先、同時実行数、処理時間、POST処理の内容、
プロセス滞留状況、およびメモリ消費状況等を総合的に確認のうえ判断する必要がございます。

本件では、お客様の開発環境IP（58.91.89.130）からのアクセスが集中していたこと、
短時間に連続したGET/POSTアクセスが発生していたこと、ならびに admin-ajax.php 宛の
POSTアクセスが大半を占めていたことを確認しております。
これらの状況を踏まえ、当社としてはお客様環境内の処理負荷増大が
一因となっていた可能性が高いものと判断しております。

なお、一般論として、PHPのバージョンや設定の差異により、
実行エンジンの挙動、メモリ使用量、キャッシュ動作等が変化することに伴い、
同一のアプリケーション構成であっても処理性能に差異が生じる場合がございます。

そのため、特定のバージョンや設定変更のみをもって、サーバー全体の性能や挙動を
一義的に評価できるものではなく、複数の要素が相互に影響するものと認識しております。

上記が当社としての最終見解であり、これまでにご案内済みの内容以上の
新たな技術的説明・個別調査・対応の予定はございません。

また、当社サービスは当社所定の運用方針およびリソース管理のもとでご提供している
マネージドサービスとなりますため、個別の構成や挙動に関するご要望には対応いたしかねます。

なお、当社として本件に関し不具合は確認しておらず、補償・返金等の対応につきましてもいたしかねます。

恐れ入りますが、本件に関する対応は本回答をもって完了とさせていただきます。
本件に関する一連のご照会につきましては、これ以上の回答はいたしかねます。

何卒よろしくお願い申し上げます。

欺瞞に溢れた酷いもの。
やり取り内で送った証拠（ログやグラフなど）に基づく当方操作＝ajaxなどは微細、単なるアクセス処理の問題なのにいまだにajax過多と言っている。
一般論というが、30分以内に同じテストを設定変更を挟んだ結果に20倍程度の処理能力差がでるものは、一般論でいえば故障というはずだ。
相変わらず反証などのない、的外れなajax過多などと未だに言ってくる返信からすれば技術的根拠以前に対応する気がない逃げ口上にしか聞こえない返答ばかり。
これだけアクセス負荷テストを行い設定変更などもし、証拠も送っている。KAGOYAサイドにログは残っている筈だが、不具合確認していないという返答は技術商売であることから考えれば虚偽報告ではとの疑念も持つ。

障害から数えてだいぶ時間が経ったが、説明もここにきて二転三転してきており、技術商売であるサーバー屋であるにもかかわらずこれでは企業として信用ができない。
そう考える様にもなった。

障害からのものとの切り分け

前項に書いた通り未だにajax過多だの言ってくるので、障害以来のやり取りではなく、別レスを起こしこの不具合対処をするようにと考えた。


6/24のもの。
開発作業は最終段階で表示微調整などであり、この案件を試験運用してもサーバーが性能発揮されていれば、グラフ上昇は微細。
しかしながら実用にはサーバーが常時正しく働かないと、同時アクセスが重なると表示遅延でページの価値がなくなる。

別途スレッドを立てたつもりだが、対応が悪く返信に2～3日など当たり前。
改めて試験対象ページについて下記の通り送った。

• 項目別の前回・今回数値比較
  クエリ数（TOTAL_QUERIES）
  前回（6/20・21）： 14 回 （非ログオン通常アクセス時）
• 今回（最新ログ）： 14 回 （非ログオン通常アクセス時）
• 数値変化： 0 （完全に同一のクエリ構成を維持）
• データベース純処理時間（TOTAL_Q_TIME）
  前回（6/20・21）： 0.0031 秒 ? 0.0035 秒
• 今回（最新ログ）： 0.0033 秒
• 数値変化： ほぼ横ばい（ミリ秒単位の微小なブレのみで、DBの応答速度は変わらず極めて高速）
• PHP・AJAX起動・実行時間（TOTAL_EXEC_TIME）
  前回（6/20・21）： 0.0321 秒 ? 0.0355 秒
• 今回（最新ログ）： * 通常ページ表示：0.0339 秒
• バックグラウンドAJAX（heartbeat / keep_alive）：0.0528 秒 ? 0.0529 秒
• 数値変化： PHPスクリプト単体の起動から処理完了までの内部時間は、ミリ秒単位で完全に同一の超爆速の正常値を維持。
• メモリ負荷（MEM_USED）
  前回（6/20・21）： 32.00 MB （純増分 4.00 MB）
• 今回（最新ログ）： * 通常ページ表示：32.00 MB （純増分 4.00 MB）
• AJAX通信：36.00 MB （純増分 8.00 MB）
• 数値変化： 0 （64Mの制限枠に対して完全に安全圏内であり、一切のメモリ肥大化なし）
• 読込ファイル数（TotalFiles）
  前回（6/20・21）： 514 個 （通常アクセス時）
• 今回（最新ログ）： * 通常ページ表示：514 個
• AJAX通信時：540 個

現況判断にはAIを用いている、GPT　Gemini　Grok　Cloude　GoogleAI全てが、サイト側をこれ以上弄ってもK6での100VUS試験での改善は極小、サーバーのボトルネック解消が最善であり必須との解答。

そりゃそうだ、CPU・メモリー他爆速だが単に道が狭いだけだもの。
上記は生ログをAIに渡して要点だけ抜きだしたものだが、生ログも提供済みであるし、症状再現100％であることから対応＝あくまでも正常使用可能な状態への復旧を望んでいるが、6/25に下記のような返答が来た。

ご提示の内容まで含めて精査しましたが、
現状の事象はサーバー障害または制限付与によるものとは判断しておりません。
まず、ご提示いただいているデバッグログのとおり、

・クエリ数
・DB処理時間
・PHP実行時間
・メモリ消費量
・読込ファイル数

はいずれも前回と今回で差異がなく、アプリケーション内部の処理性能は
一貫して同一かつ安定している状態です。
この点は、お客様ご自身の測定結果においても明確に一致しております。

一方で、負荷試験時のみ大きな遅延が発生している点については、
「同時アクセス時の処理待機（キューイング）が発生している」ことによる挙動と整理されます。

個々の処理が高速であっても、同時に処理可能な数を超えたリクエストは順次待機状態となるため、
結果として応答時間が大きく増加します。

これは一般的なサーバー挙動であり、再現性があること自体は障害の根拠にはなりません。
また、session.gc_maxlifetime の変更により改善する点については、

・セッション管理処理の発生タイミング
・リクエストごとの処理占有時間
・I/O発生挙動

が変化することで、同時アクセス時のリソース使用状況が変わり、
結果としてスループットが変動しているものです。

すなわち、制限が解除された、あるいはサーバー側で何らかの操作が行われたことを示す挙動ではありません。

なお、

「勝手に制限が付与・解除されている」
「故障が再発している」

とのご認識についてですが、
当社側で同時接続数制限や処理制御を変更した事実は確認されておらず、
また本事象がそれに起因することを示す技術的根拠も確認できません。

以上より、本件は

・アプリケーション内部処理：正常
・性能変動要因：同時アクセス時の待機発生
・PHP設定変更による改善：処理特性の変化によるもの

と判断しており、サーバーの故障または異常状態には該当いたしません。

本件につきましてはサーバー側起因の障害ではないため、本回答をもって調査完了といたします。

本件の挙動は、アプリケーションおよび実行環境の特性に起因するものであり、
サーバー側の障害や制限によるものではないため、個別の対応や調整は実施しておりません。

今後の改善につきましては、お客様環境にて

・同時アクセスを前提としたアプリケーション設計の見直し
・セッション処理（ロック・保持期間）の最適化
・負荷時のリクエスト分散やキュー制御の導入
・同時処理数を考慮したアクセス設計

等をご検討いただく必要がございます。

これらの調整により、同時アクセス時の待機発生を抑制し、
より安定した応答性能が得られる可能性がございます。

とんでもない応答

無料のサービスではない。
「1コア4GB専有　月額利用料約1700円」、WP専用とかいうその辺のサーバーよりよっぽど高性能であり専有なので他ホストの干渉も減るはず。
このような軽量ページに対する100VUSアクセス負荷試験で、20秒からの遅延というwebページとしては致命的な不具合が出るはずがない。

この返答の主な問題点

データを見ながら無視している

あなたが渡した34ms / 14クエリ / 極軽量構成という明確な数字を認めつつ、「個々の処理は高速」と認めているのに、最終的に「同時アクセスのせい」に全部持っていく。
これは**「データは見たけど、都合が悪いので無視」**という態度。

構成の特性を完全無視

wp_head/wp_footer未使用、WPは基礎情報のみ、小さいJSON＋クライアントサイド演算というほぼ静的・ヘッドレス寄りの超軽量設計であることを理解していない（または理解した上でスルー）。
こんなページに「同時アクセス前提のアプリケーション設計を見直せ」は、明らかにミスマッチ。普通のブログ記事やLPレベルに「大規模分散設計」を求めているようなもの。

責任転嫁が露骨

サーバー側に一切非を認めない。
「session.gc_maxlifetime で改善した」事実すら「処理特性が変わっただけ」「制限解除の証拠ではない」と強引に切り捨て。
最終的に「全部お客様のアプリ設計が悪い」と結論づけ、調査完了で終わらせる。

技術的に無理のある主張

34msの超軽量ページで「同時アクセス時のキューイングが発生」と主張するのは、現実的にかなり無理がある。
そんな軽いページがキューで詰まるなら、サーバーの同時処理能力が極端に低い（＝リソース不足 or 意図的制限）可能性の方が遥かに高い。

サポートの長とのやり取りで、ajaxPOST過多という的外れな応答が続き、移転推奨しておきながら返金も保障もしないということから、企業としての上位決済可能な方からの返答・応答を求めたが何も言わずにそのまま放置。
先の障害からのものと分けるべきとして新スレッド立ててもこのような的外れな解答というか、こちらへの言いがかりかとも感じる一切の根拠のない物言い。
これが有償、それも比較的高額で広告している性能とそれの下支えとなる一般論、全てに反するサービス提供する企業なのでしょうか。

その後

要旨は以下のようですね

遅延の原因は**同時アクセス時の待機（キューイング）**によるもの
PHP設定変更で改善するのは「処理特性が変わっただけ」で、サーバー側の制限解除ではない
サーバー側で意図的な制限や変更は一切していない
したがってサーバー障害ではない → アプリ側で同時アクセス対策を検討せよ

試験対象ページは先に示した通り極軽量ページ有り、たかが100同時アクセス程度で待機発生するサーバーではないですよね？
PHP設定変更で改善し深夜帯に制限かかるが、設定内容に関わらず変更すれば同程度改善することの繰り返しは、不具合以外のなにものでもありません。
意図的な変更はしていないのかもしれませんが、故障は意図して管理者が起こすものではありません。意図したかしていないかは本件関係ありません。
サイト/アプリで対策の必要のないレベルの軽量ページです、早急篤実な修理を願います。

先週となんら変わらない内容の返信で、なんの根拠も示されてません。
しかしながらユーザーが設定変更せずに正常に動けば根拠も不要です、今朝もloaderによる簡易試験から設定変更正常化作業代行を行いましたが、それで解るのでK6による試験は行っていません。
修理依頼い書きましたが、昨日の結果はありますので添付します、よろしくお願いいたします。

送信内容そのままだが、これを6/25の夕刻に、同日Loaderのみ行って設定変更対処したので前日6/24の試験結果とPHP設定変更後の結果を添付し返信した。
毎日K6で100VUS10分テストを設定変更挟んで2回やるのは辛い、時間の無駄で作業の障り。
だがここまで有償契約に対する裏切り・背信をするなら、サーバーやこうしたシステムやWPに詳しい方でないとKAGOYAの対応・企業としての立脚意図が解り辛いとは思うが、色々と考えないといけないようですね。

6/27・6/28と、応答・返答などを求めて送信しているが、一切の応答なし、両日ともに不具合有り～PHP設定変更により当方で復旧させている。

6/29になり、ようやく返答が来た

全文は長いので要旨抜粋したものが以下。

• サーバー側で同時接続数や処理能力に関する制限を任意に付与・解除した事実はなく、サーバー障害や異常も確認されていない。

• PHP設定変更で改善する挙動は、設定変更に伴う実行環境の再読み込み、プロセス状態やキャッシュ状態の変化、セッション処理挙動の変化などによる一時的な処理特性の変動。

• したがって「設定変更により改善する」挙動をもって、サーバー側で制限が解除された、または故障が修理されたとする判断には至らない。

• ログ上、アプリ内部処理（クエリ数、DB処理時間、PHP実行時間、メモリ使用量、ファイル読み込み数）は正常で変化なし。

• 高同時アクセス時の遅延は同時処理数を超過した際の待機発生による一般的なサーバー挙動。

• 本件はサーバー側の障害や制限によるものではないため、調査完了とし、個別の対応や調整は実施しない。

• 改善はアプリ側で同時アクセス対策（設計の見直し、セッション最適化など）を行う必要がある。

まず具体的な理論や数値提示による反証や説明がないが、言っていることにも破綻があってもうどうしようもない。

カゴヤ返信の異常・矛盾点（羅列）以下が、技術的・論理的異常な部分

• 極軽量ページなのに100VUSで20秒遅延を「一般的なサーバー挙動」と主張
  → 専有1コア4GBで、極軽量ページに100同時アクセス程度で20秒待機が発生するのは明らかに異常。一般的なサーバー性能として到底ありえない。
• アプリ内部処理が正常だからサーバー側は問題ない
  → クエリ数・DB時間・PHP実行時間・メモリが正常でも、同時アクセスで遅延が発生するのはサーバー側の同時処理能力（Busy servers / キュー管理）に問題がある証拠なのに、それを無視してアプリ側に責任転嫁。
• PHP設定変更で改善するのは「処理特性の変化」
  → バージョン変更でもmemory_limit変更でもsession.gc_maxlifetime変更でも改善する極めて高い再現性を、「処理特性が変わっただけ」で片付けている。論理的に破綻している。
• 「設定変更で改善する挙動をもって制限解除や故障修理とは判断しない」
  → 設定変更のたびに改善し、時間が経つと再悪化するという明確なパターンを無視。意図的に目を逸らしているというか、ユーザーの設定変更で不具合改善することを故障修理というが、再現性からもこれはしゅうりではなく故障に対するユーザーが仕方なく行っている対処であり、これら一連が故障現実
• 「意図的な制限変更はない」
  → 「意図的でない」と言っているが、自動で制限がかかる仕組みがあることを認めていない。結果として放置を正当化している。
• 「アプリ側で対策せよ」
  → 専有サーバーなのに「同時アクセス対策をアプリ側でやれ」というのは、契約内容と矛盾。専有の意味を完全に否定している。
• 「調査完了」
  → 1ヶ月以上不具合が続き、ユーザーが毎日設定変更を強いられている状況を**「調査完了」**で終わらせるのは、企業として異常。

こちらからの返信内容

• 貴社の「サーバー側で制限や障害はない」「PHP設定変更による改善は処理特性の変化」という回答は、当方の確認した再現性の高い事実と大きく矛盾する。
• 確定事実：PHP設定変更（バージョン、memory_limit、session.gc_maxlifetimeなど）で性能が劇的に改善するが、設定変更のたびに再現され、翌日には再び悪化する。解除後の状態は正常で、専有サーバーの性能を十分発揮できている。
• これは同時アクセス制限（処理待機）が常態化している証拠であり、単なる処理特性の変化では説明できない。
• 極軽量ページで100VUSでp95 20秒超という性能を「一般的なサーバー挙動」と主張するのは、専有1コア4GBサーバーとして到底許容できる性能ではない。
• ユーザー側で設定変更しないと正常性能が得られない状態が1ヶ月以上継続しており、明確なサービス不履行。
• 要請：技術部門または運用責任者より、改善仕組みの具体的な技術的説明、ユーザー操作に依存しない正常性能の恒久的な回復、障害期間の利用料金返金または補償の可否について、責任者からの直接回答を求める。

支払い済みの費用は返金しないと明言されているから補償可否等は正直優先度は低い。
あくまでも正常な性能によるサービスの提供をさせるのが第一義。正常ならサポート以外は充分だからだ。

だが返答内容はここ数回同じ内容である。
これは、技術屋が反証等の無いまた理論破綻した反論に終始し、ユーザー操作によりその当日は一般論における可能同時アクセス数過少となる制限解除となり正常化する状態を放置、これがKAGOYAのレンタルサーバー屋としての方針と断定せざるを得ない。

KAGOYAは1コア4GBのサーバで同時アクセス処理数やその保障を謳ってはいないが、KAGOYAも他社ももっと安価なプランを提供しておりその一般論、専有で性能上位といった事実を考慮すれば、優良誤認を狙ったとの嫌疑また、支払い後に返金保証すら行わないとするなどの事実は詐取の嫌疑すら生じるもので、ユーザーとしては到底看過できないし、当方のような誤認をする方が今後発生することも懸念するものだ。

K6による負荷試験はキャッシュを持たないユーザーが繰り返しアクセスしてくるもので、100VUSといってもユーザー数ベースで考えれば述べユーザーは数千を超えることにもなる。
しかしながら、webサイトの目的が情報提供であり一般論的にその提供＝アクセスの多いことが是とされる以上、同時アクセス処理能力に不具合がある状態は故障・サービス提供不履行。
本日はK6での100VUS50VUS20VUSでの試験と設定変更後の試験を行った。


これら画像にした測定では、100VUSから50VUSで大幅に改善はしているが、P95が5～6秒ではページ・サイト運営としてはアウト。
20VUSでようやくギリギリの2秒、同時アクセス20はグラフにある試験開始時のみで平均は2.5～3でしかない。これらを併せた平均値がP95で2秒程度であり、webサイトを置くサーバーとしては不足であり喧伝仕様とその対価から考えれば大きく不足である。

PHP設定変更後は大幅改善している。
変更前の20VUSよりも滞りの無い100VUS試験結果。
試験ではあるが、全てのログはKAGOYAに残っている筈であり、これほど明らかな差・改善が起きていることを理論的・技術的説明や反証もなく返答としている欺瞞に対しどうすべきかを考えるフェーズに入ったと考えるべきなのだろう。

1. 消費者庁 景品表示法担当（最も直接的）相談方法：メールまたは電話

問い合わせ先：電話：03-3507-9100（消費者庁代表）
景品表示法に関する相談は「表示対策課」へ
メール：消費者庁ウェブサイトの問い合わせフォームから「景品表示法違反の疑い」として送信可能https://www.caa.go.jp/policies/policy/representation/fair_labeling/
おすすめの伝え方
「専有サーバーとして高性能をうたっているにもかかわらず、実際の性能が著しく劣り、ユーザー側で設定変更しないと正常に使えない」ことを具体的に書いて相談。

2. 公正取引委員会（景品表示法の執行機関）

相談窓口：公正取引委員会 相談室
電話：03-3581-5471
ウェブサイトから相談フォームあり

3.管轄警察署（詐取・業務妨害嫌疑）