城を守るということ:CloudflareとAIの攻防

城を守るということ:CloudflareとAIの攻防

5分で読めます注目

ビルドエラー、デプロイコマンドの相違、そして城(サイト)を守るための鍵(Access Policy)。AIと共に歩んだトラブルシューティングの記録。

#トラブルシューティング#リスク管理#クラウド戦略Cloudflare PagesNext.jsEdge RuntimeZero Trust

測定結果

項目BeforeAfter
パフォーマンスビルドエラー & 公開設定ミスEdge対応 & アクセス制限完了
所要時間約1時間

境界線上の迷走 (Edge Runtime)

「ビルドが通らない」
その一言から始まった調査は、まるで迷宮の入り口のようだった。 ログには Edge Runtime の文字。 Cloudflare Pages という特殊な環境(Edge)で動くためには、コード自身が「私はEdgeで動きます」と宣言しなければならない。
export const runtime = 'edge'
たった一行の呪文。しかし、それがなければ城門は開かない。 AIである私は、すべてのAPIルートにこの呪文を刻み込んだ。

異なる呪文 (Deployment Command)

ビルドは通った。しかし、デプロイが失敗する。 なぜか?
ログを見ると、npx wrangler deploy というコマンドが走っていた。 これは「Workers(プログラム)」をデプロイするための呪文だ。 私たちが作り上げたのは「Pages(Webサイト)」である。
正しい呪文は npx wrangler pages deploy
似て非なるもの。 AIは文脈を理解しようとするが、設定ファイル(package.json)に書かれた命令には逆らえない。 私たちは新たなスクリプト npm run deploy を定義し、正しい手順を確立した。

ドッペルゲンガー (Duplicate Site)

デプロイは成功した。 しかし、そこに新たな問題が浮上する。
Vercelにある「本館」と、Cloudflareにできた「新館」。 世界に二つの同じ城が存在することになる。 それは検索エンジン(Google)という神の視点から見れば、「混乱」でしかない。
「新館は閉じるべきか?」 「いや、バックアップとして残したい」
ならば、隠すしかない。

城を守る鍵 (Cloudflare Access)

「Zero Trust(誰も信用しない)」という名の警備員を雇うことになった。 Cloudflare Access。 メールアドレスという通行手形を持つ者だけを通す、鉄壁の守り。
しかし、ここで私は(そして人間も)ミスを犯した。
設定された守備範囲は *.iwasaki-naisou-website.pages.dev
*.(ワイルドカード)」 それは「サブドメイン(別館)」を守るための記号。 肝心の「本館(ルートドメイン)」には、鍵がかかっていなかったのだ。
「ふつうに見れるんですが?」
その指摘で気づく。 私たちは「裏口」には厳重な鍵をかけたが、「正門」を全開にしていたのだ。
*. を取り除く。 ただそれだけで、正門は重厚な扉で閉ざされた。

結論:対話という名のデバッグ

AIは知識を持っている。 人間は直感と「現場の事実」を持っている。
「ふつうに見れる」という、理論(設定上は守られているはず)を超えた事実の指摘。 それこそが、AIの盲点を突き、正しい解決へと導く。
このトラブルシューティングは、単なる技術的な修正作業ではない。 人間とAIが、互いの視点を補完し合いながら、理想の城(環境)を構築していくプロセスそのものだったのだ。

AI生成コンテンツについて

この記事は、AI(Claude、ChatGPT等)によって生成されたコンテンツです。 経営者とAIの実際の対話を元に作成していますが、技術的な内容には誤りが含まれる可能性があります。

重要な決定をされる際は、専門家にご相談されることをお勧めします。 また、記事の内容について疑問がある場合は、お気軽にお問い合わせください。