#トラブルシューティング#リスク管理#クラウド戦略Cloudflare PagesNext.jsEdge RuntimeZero Trust
測定結果
| 項目 | Before | After |
|---|---|---|
| パフォーマンス | ビルドエラー & 公開設定ミス | 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の実際の対話を元に作成していますが、技術的な内容には誤りが含まれる可能性があります。
重要な決定をされる際は、専門家にご相談されることをお勧めします。 また、記事の内容について疑問がある場合は、お気軽にお問い合わせください。
