AIに作らせたWebアプリを、公開する前に見る5つの場所

AIに作らせたWebアプリは、手元では動き、ビルドも単体テストも通ります。それでも、公開すると本番でだけ壊れることがあります。BenriWorksは2026年9月、16のサイトに計測タグを入れ、ブログの広告と方針の文書を整えました。その過程で見つかった問題は、どれもソースコードとビルドの外側にありました。見つかった場所ごとに、公開前に確かめる5つの場所としてまとめます。

ビルドと本番のあいだにあるもの

AIがコードを書くとき、確かめているのは主にソースコードとビルドと単体テストです。ところが、利用者が触れるのは、配信されてブラウザに届いたページです。その間には、配信の設定、応答ヘッダー、外部のサービスとのやりとりが挟まります。計測タグの導入では、16サイト中3サイトで計測が届かず、原因はどれもこの間にありました。

1. 本番のページとコンソール

最初に、公開したURLでページを開き、ブラウザの開発者ツールのコンソールにエラーが出ていないかを見ます。

修正月齢アプリでは、AIが書いた計測タグが、本番のブラウザでだけ構文エラーになっていました。ソースでは /\/+$/ と書いた正規表現が、テンプレート文字列を通る段階で逆スラッシュを失い、ブラウザには //+$/ として届いていました。// はコメントの始まりと解釈され、そこから先が壊れます。ソースを読んでも、ビルドを通しても分かりません。修正のあとは、生成したタグをビルドの前に構文解析する検査を足しました。経緯は「Claude Fable 5.1 で13リポジトリにGA4を入れた記録」にあります。

このブログでも、記事のアイキャッチ画像がサイト全体で表示されていなかった時期があります。ブログは /blog の下で配信していて、画像を最適化する仕組みがその配信パスを元の画像のパスに付けず、画像の取得に失敗していました。配信のパスが絡む問題なので、本番と同じ形で配信したページを開いて確かめる必要があります。

2. 本番の応答ヘッダー

次に、本番のページが返すHTTPの応答ヘッダーを見ます。開発者ツールのネットワークのタブで、ページ本体の応答を選べば一覧で確認できます。

計測が届かなかった残りの2サイトでは、応答ヘッダーのContent-Security-Policy（CSP。ブラウザが読み込んだり送信したりしてよい相手を制限する設定）が、計測タグの配信元と送信先を許可していませんでした。タグはページに入っているのに、ブラウザが読み込みと送信を拒んでいたのです。作業の仕様書には、AIが「CSPはどのリポジトリにも設定なし」と書いていました。ソースコードを文字列で検索して見つからなかったためで、実際には関数やミドルウェアの中で組み立てられていました。見つけたのは、本番の応答ヘッダーを転記した、別のAIの確認報告です（「GPT-6 Astra の Codex に、16サイトの疎通確認を任せた記録」）。

3. 外へ送っているURL

3つめは、ページが外部のサービスへ何を送っているかです。計測や広告のタグは、ページのURLを送ります。そのURLに、利用者が入力した内容が含まれていないかを確かめます。

子どもの生年月日から入学と卒業の年度を一覧にする学歴早見表では、1回開いただけなのにページビューが2件記録されていました。数の食い違いを追うと、アプリが入力内容をURLへ書き戻す処理を持っていて、その履歴の変更を計測が2件目のページビューとして送っていました。そして2件目のURLには、子どものニックネームと生年月日が乗っていました。

この書き戻しの処理は、計測を入れる前からアプリにあったものです。計測を足したことで、書き戻しと計測が組み合わさり、入力内容を外へ送る経路になりました。対処として書き戻しをやめる変更を提案しましたが、アドレスバーが入力に追従しなくなる挙動の変更を含むため、マージの判断は人に残しています。確かめ方は、開発者ツールのネットワークのタブで計測への送信を選び、送っているURLに入力の内容が含まれていないかを見ることです。

4. 置いたファイルと、その中身

4つめは、公開のために置いたファイルが、実際に効く形になっているかです。

このブログでは、広告の配信に必要な ads.txt はあるのに、広告のコードがサイトのどこにも入っていない状態が続いていました。この状態では、審査を通っても広告は配信されません。9月20日に見つかり、広告のコードを全ページに入れています。

同じように、ブログのリポジトリには検索エンジン向けの robots.txt を生成する仕組みがありますが、ブログは /blog の下で配信しているため、/blog/robots.txt として出ていました。検索エンジンが読むのはサイトの一番上の /robots.txt だけなので、こちらは読まれません。実際に効いているのは、トップサイトの側に置いたファイルです。ファイルがあることと、それが読まれる場所にあることは、別に確かめる必要があります。

5. 説明の文書と、実際の読み込み

最後は、プライバシーポリシーのような説明の文書が、実際の動きと合っているかです。

このブログのプライバシーポリシーには、「アクセス解析はVercel Analyticsのみで、Cookieは使わない」という趣旨の記述が残っていました。実際には、9月にGoogleアナリティクスとGoogle AdSenseを読み込むようにしていて、どちらもCookieを使います。計測と広告のコードを入れた変更では、方針の文書を見直していませんでした。9月24日に、読み込んでいるサービスに合わせて書き直し、計測や読み込むサービスを増やすときは文面も同じ変更で見直すことを、ページのコードのコメントに残しました。

5つを確かめる順番

上から順に見ると、動くかどうか、止められていないか、送りすぎていないか、効いているか、説明と合っているか、の順になります。どれも、コードを書いたAIが自分の作業の中では見ない場所です。書いたAIとは別の目で確かめる考え方は「AIの答えが正しいか確かめるには。聞き直すより、答えの外側を見る」にまとめました。検査を自動で走らせる仕組み自体が止まっていたことに気づかなかった件は、「AIが書いたプルリクエストの検査が、3秒で終わっていた」に書いています。

公開した後に一度

5つの確認は、公開の直前だけでなく、計測や広告のタグを足したとき、配信の設定を変えたときにも同じように必要です。学歴早見表の件は、アプリそのものではなく、あとから足した計測との組み合わせで起きました。何かを足したら、本番のURLを開いて、コンソールとネットワークのタブを一度見る。その数分で、ここに挙げた問題の多くは見つかっていたはずです。