English
これまで本サイトでは、AIエージェントが「対話するツール」から、実際の業務を進める存在へ変わりつつあることを、OpenClawの検証などを通じて紹介してきた。
今回は、実際に発生したECサイトの障害対応にAIエージェントを活用した事例を取り上げる。
対象となったのは、筆者が運営する雑貨のECサイト「Magnote Gifts」である。ボットによる大量のアクセスでサーバーに大きな負荷がかかり、サイトが停止する事態が発生した。
緊急対応にかかった時間は約半日。対策後、問題となっていたアクセスは、対策前と比べて約7割減少した。
ただし、今回重要だったのは削減率だけではない。AIにどこまで調査を任せ、どの時点で人間が判断するのか。その範囲をどのように決めるかが、結果を左右した。
突然、ECサイトが停止した
最初に分かったのは、サーバーに大きな負荷がかかり、サイトが応答しなくなっていることだけだった。
アクセス数が増えていることはすぐに確認できたが、誰が、どこから、どのようなリクエストを送っているのかは分からない。
この段階で推測だけをもとに設定を変更すると、原因を取り違えたり、別の問題を引き起こしたりする可能性がある。そこで、闇雲に対策を始めるのではなく、まず何が起きているのかを正確に調べることにした。
Claude Codeでサーバーログを解析する
調査のためにローカル環境へ専用のフォルダを用意し、Claude Codeを立ち上げてサーバーログを解析した。
サーバーログは膨大であり、人間が一行ずつ確認すれば、かなりの時間がかかる。そこで、特定の時間帯にアクセスが集中していないか、同じパターンのリクエストが繰り返されていないか、通常時と異なる動きがないかをClaude Codeに調べてもらった。
その結果、カートやウィッシュリストへの追加リクエストが、異常な件数に達していることが分かった。さらにアクセス元を調べると、それらの多くがシンガポールからのリクエストに集中していた。
商品ページを閲覧するだけのアクセスとは異なり、カートやウィッシュリストへの追加では、セッション管理やデータベースへの書き込みなど、サーバー側で複数の処理が発生する。
こうしたリクエストが大量に繰り返されれば、アクセス数以上にサーバーへ大きな負荷がかかる。
複数のデータを照らし合わせる
ただし、サーバーログだけで原因を判断することは避けた。
Google Analytics、Search Console、Cloudflareの情報も確認し、アクセス元、リクエストの内容、発生していた時間帯を複数のデータから照らし合わせた。
従来であれば、担当者がサーバーログを開き、Google Analyticsを確認し、Search ConsoleとCloudflareの管理画面を見ながら、それぞれの数字を手作業で比較する必要がある。
今回は、Claude Codeによるログ解析と、ブラウザ上で確認した各サービスの情報を組み合わせ、AIと対話しながら調査を進めた。
一つの情報だけに依存せず、複数のデータを横断して確認したことで、原因をより短時間で絞り込むことができた。
問題のあるアクセスをサーバーの手前で止める
原因が見えてきたところで、次に考えたのは、問題のあるアクセスをどこで止めるかという点である。
このサイトでは、DNSとCDNにCloudflareを使用している。そこで、問題のあるリクエストがサーバーへ到達する前に、Cloudflare側でスクリーニングする設定を追加した。
サーバーがリクエストを受け取ってから拒否する場合、拒否する処理そのものにサーバーのリソースを使用する。
一方、サーバーの手前にあるCDNで止めることができれば、サーバーまで届くトラフィック自体を減らせる。玄関まで来てから対応するのではなく、敷地の入口で止めるようなものである。
ボットアクセス以外の問題も見つかった
調査を進める中で、ボットアクセスとは別の問題も見つかった。
サイト内で使われていたキャッシュ機能が重複しており、プラグイン側の設定にも不整合があった。
キャッシュは本来、サイトの表示を速くし、サーバーへの負荷を減らすための仕組みである。しかし、複数のキャッシュ機能が重複し、想定と異なる動きをすると、かえってサイトの挙動が複雑になり、障害発生時の原因特定も難しくなる。
そこで、重複していたキャッシュの構成を整理し、Cloudflareからサーバーへ届くリクエストの流れも見直した。
最終的に実施した主な対策は、次の三つである。
・問題のあるアクセスをCloudflare側でスクリーニングする
・サイト内部で重複していたキャッシュ構成を整理する
・Cloudflareからサーバーへ届くリクエストを最適化する
これらを組み合わせることで、サーバーへ到達する不要なトラフィックを大きく減らすことができた。
半日の対応で問題アクセスが約7割減少
ここまでの緊急対応にかかった時間は、約半日だった。
設定変更後、ボットによって増加していたアクセスは、対策前と比べて約7割減少した。
サイトが安定しただけでなく、Google Analyticsのデータも確認しやすくなった。それまでは、ボットによるアクセスがノイズとして混ざっていたため、実際の顧客がサイト上でどのように行動しているのかを読み取りにくい状態だった。
不要なアクセスが減ったことで、実際の利用者の動きを以前より確認しやすくなった。
当初の目的はサーバー負荷を減らすことだったが、結果としてアクセス解析の環境も改善された。分析に利用しているデータへボット由来のノイズが混ざっていても、その事実自体に気づいていないEC事業者は少なくないかもしれない。
復旧だけで終わらせず、周辺の問題も確認する
今回、AIがサーバーログ、Cloudflare、Google Analytics、Search Consoleなどの情報を確認できる環境を整えた。
そこで、当初の目的だったサイトの復旧だけで終わらせず、周辺の設定も一通り確認することにした。
その結果、Google Merchant Centerとの連携にも問題があり、一部の商品データが正しく登録されていないことが分かった。
さらに、社内のスプレッドシートで管理していた商品情報と、ECサイト上の商品情報の間にも、整理が必要な箇所が見つかった。
確認すべき項目は、次のようなものである。
- 各商品にどの情報が登録されているか
- 不足している商品情報は何か
- ECサイトとGoogle Merchant Centerの間で、情報が正しく連携されているか
これらの情報をまとめて確認し、商品データの抜け漏れを減らすためには、複数のシステムを横断して管理する仕組みが必要である。
現在は、スプレッドシート、ECサイト、Google Merchant Centerのデータを突き合わせ、商品情報を一元的に管理するシステムの構築を進めている。
これはPIM（Product Information Management）と呼ばれる仕組みである。完成後、改めて別の記事で紹介したい。
AIには、目先の作業だけでなく周辺まで見てもらう
今回の対応を通じて感じたのは、AIに一つの作業だけを依頼するより、問題の周辺まで含めて調査してもらったほうが、得られる価値が大きくなるということである。
もし「この設定だけを修正してほしい」と依頼していたら、その設定は直っても、キャッシュ構成の重複や、Google Merchant Centerの商品データの問題までは見つからなかった可能性が高い。
障害対応で重要なのは、目の前に現れた症状を取り除くだけではない。同じような問題を生み出す可能性のある構造まで確認することである。
一方で、サーバーや外部サービスへの権限を、AIに無制限に与えればよいわけではない。
調査に必要な範囲だけアクセスを許可し、重要な変更は人間が確認する。作業が終わったら、不要になった権限を削除することも必要である。
どこまでAIに調査を任せ、どこから先を人間が判断するのか。この境界線を決めることが、実務でAIを使ううえでは重要になる。
AIに使われるのではなく、AIを使う
PlayStation 2の半導体設計に携わっていた頃から、筆者がチームメンバーに伝えてきた言葉がある。
ツールは使うものであって、ツールに使われてはいけない。
どれほど便利なツールでも、提示された答えをそのまま受け入れるようになれば、思考は止まってしまう。
その答えは本当に正しいのか。もっと良い方法はないのか。使う側が考え続けなければ、より良い商品やサービスを生み出すことにはつながらない。
AIは、これまでのツールよりも実行できる範囲が広い。だからこそ、使う側の判断はさらに重要になる。
AIには広く調査してもらう。しかし、最後の判断まで任せきりにしない。
今回の障害対応は、AIの実行能力だけでなく、人間が任せる範囲を設計し、結果を検証することの重要性を改めて確認する機会となった。
次稿では、4〜5年前にWordPressで構築したB2B発注サイトを、Next.jsとSupabaseを使った新しいシステムへ全面的に移行した事例を紹介する。
そこで特に重要だったのは、Claude Codeにいきなり実装を任せるのではなく、実装前にAIと対話し、要件を明確にしたことである。
藤本真也｜Silicon Valley Japan Lab Founder / Chief Strategist
米国在住25年以上。エンジニアと経営者の経験をもとに、シリコンバレーの技術動向を日本企業の経営や事業開発にどう生かすかという視点から発信している。