CDNの意図しないキャッシュ問題を生成AIを用いて解決してみた

こんにちは。株式会社divxでエンジニアをしている本田です。

みなさんは日々の業務で生成AIを活用しているでしょうか。既にバリバリ使っている方も多いとは思いますが、今回は「CDNの意図しないキャッシュ問題を生成AIを用いて解決してみた」というテーマで執筆していきたいと思います。

株式会社divxでは全社的にAI・生成AIの活用を徹底しており、エンジニアである私も生成AIを日々の業務に欠かせないツールとして使っています。この記事は、以下のような課題を持つ方に特にお読みいただきたい内容です。

• 生成AIに対して、どのように質問すればいいか悩んでいる

• 生成AIを活用して業務効率を向上させたい

• Web検索ではヒットしない具体的に踏み込んだ調査をしたい

現在、私の担当している大まかな作業として、オリジンサーバーの負荷分散やエンドユーザーの通信速度向上のためのCDN (Content Delivery Network) 設定やセキュリティ設定などを担当させていただいています。

これらのインフラ系の設定は、顧客ごとにサーバー環境やセキュリティポリシーが異なるため、非常に踏み込んだ専門的な質問をいただくことが多々あります。特に複雑な事象が発生した際、従来の課題解決の方法には大きな壁がありました。

以前までは問題解決の対応策として、Web検索を試みていたのですが、ニッチで専門的な事柄はなかなかヒットしません。そのため、最終的には公式ドキュメントを確認するか、過去に実装経験がある先輩や同僚にアドバイスをいただくというのが主な対応策でした。

しかし、生成AIの発展はこの状況を一変させました。専門知識が必要な課題に対し、これまでの「検索」「経験者に聞く」に加えて、「生成AIに仮説生成を依頼する」という新たな第三の選択肢が生まれたのです。この新しい手法こそが、私たちの業務効率と生産性を劇的に向上させる鍵となっています。

生成AIは、私たち人間が持つ知識の枠を超えた広大な情報を学習しています。この特性を最大限に活かすため、私は生成AIを単なる情報検索ツールとしてではなく、「人間の思考の幅を強制的に広げてくれる外部パートナー」として活用しています。

私たちの思考は、過去の経験や慣れた手順に縛られがちです。サーバー負荷の問題なら「キャッシュを疑う」、セキュリティなら「WAFの設定を確認する」など、定石通りの解決策しか浮かばないことが少なくありません。しかし、生成AIに多角的な視点から仮説を立ててもらうことで、私たちが思いつかないようなニッチな設定ミスや心理的な要因など、盲点となりがちな領域まで視野を広げることができます。また、どのような実装方針を立てればよいか方針に迷っている際、実装までの筋道を立ててくれるので作業の第一歩を補助してくれる存在でもあります。

私が実践している「生成AIによる仮説の構築と検証」の具体的な手順は、以下の通りです。

本記事のタイトルにもなっていますが、「キャッシュ設定していないにも関わらず、キャッシュされてしまう」という課題に対して生成AIを用いて解決していきたいと思います。
この課題について生成AIに仮説をいくつか立ててもらいました。

仮説1：オリジンサーバーが強制的にキャッシュを指示している。 オリジンサーバーのレスポンスヘッダーに Cache-Control: public, max-age=XXX が含まれており、これがCDN側の設定を上書きしている。

仮説2：キャッシュ無効化のルールよりも、より広範囲をカバーするキャッシュ有効化ルールが先にマッチしている。 例：*.htmlを無効にしたが、上位の「すべてのコンテンツをキャッシュする」ルールが優先された。

仮説3：オリジンサーバーの手前に、別のリバースプロキシやロードバランサーが設置されており、それが一時的にキャッシュしている。

生成AIから複数の仮説が提示された後、次に重要なのは「どの仮説から検証するか」という優先順位の決定です。

仮説1と仮説3は、CDNの設定という私たちの直接的なコントロール範囲外（オリジンやその手前のインフラ）の可能性を示唆しています。もちろん重要ですが、まず確認すべきは「CDNの設定に関する仮説」です。

そのため、最も内部的な設定に起因する仮説2を優先して検討することにしました。これは、CDNのルールツリーにおけるルールの競合や階層構造の欠如といった、設定の根本に関わる問題だからです。

先に結論を申し上げると、この仮説2がほぼ正解でした。

今回のお客様のヒアリング方式が特殊で、通常のテンプレートルールに当てはめるのではなく、全てのパラメータを個別に書き出していただいた上で設定を進めていたという経緯があります。その結果、「全てのコンテンツをキャッシュしない」という大枠の親ルールの設定が漏れていたということが原因でした。

CDNの設定では、通常、特定の条件で個別にキャッシュの有効/無効を上書きする子ルールを、より広い範囲を定義する親ルールの下に配置します。(※添付画像参照)しかし、今回はその前提となる「全てのコンテンツをキャッシュしない」という親ルールが欠如していたため、CDNがデフォルトの動作（多くの場合はキャッシュを試みる）に戻ってしまい、結果として設定していないコンテンツまでキャッシュされるという事態につながっていたのです。

このように、デフォルトの設定が漏れてしまうことは稀に発生します。今回も生成AIが「ルール競合」という視点、つまり「前提となる大枠のルールが機能していない可能性」という仮説を提示してくれたことで、私たちは広大な設定項目の中から、前提となる親ルールの欠如をピンポイントで発見することができました。
また、複数ある仮説のうちから優先順位を設定したこともスムーズな問題解決につながりました。仮に、「オリジンサーバーに問題がある」という仮説1から取り掛かっているとお客様にオリジンサーバーの設定をヒアリングし、お客様に確認いただくという工程が発生してしまいます。このような無駄な報連相を減らすことも生成AIをうまく使いこなすための一つの工夫です。

生成AIを活用して複数の仮説を立案することにより、問題解決における思考のパターンが形成され、原因特定の精度が向上したと実感しています。
さらに、この過程により自身の検討内容が整理されるため、第三者に質問する際にも『仮説AとBについて検証しましたが、原因特定には至りませんでした』といった形で、論理的かつ明確に状況を説明できるようになりました。

勿論、一つの仮説について深掘りしてさらに詳しく生成AIに壁打ちさせて考察することもできますが、今回の事例のように、生成AIの仮説によって短時間で根本原因にたどり着けることは、日々の業務効率を飛躍的に高めてくれます。

生成AIの活用により、第三の視点によるアプローチや時短などをもたらし、私たちの生産性を高めます。しかし、このプロセスを実践して気づかされることは、生成AIからの回答が本当に正しいのかということを最終的に人間が判断し、責任を持つことの重要性です。

生成AIはあくまで過去のデータの統計から仮説を生成するだけで、その仮説が「本当に顧客の要求と一致しているのか」「サービスの信頼性を損なわないか」を判断するのは私たちエンジニアです。設定一つとっても、「最新の情報に保つ」という速度と、「オリジンサーバーの負荷を軽減する」という安定性のバランスをどう取るかは、生成AIには決めることができません。

生成AIによる効率化を求めつつも、その成果をどうサービスに反映させるか、どうすればユーザーが気持ちよく使えるかを考えるところに、私たちエンジニアの価値、そして「人間味のある仕事」が残されているのではないでしょうか。

これからも、日々の業務で得た知見や、生成AIとの新しい付き合い方を、読者の皆さんと目線を合わせて発信していきたいと思います。