{"componentChunkName":"component---src-templates-blog-template-js","path":"/2026-07-26-weekly-knowledge","result":{"data":{"site":{"siteMetadata":{"title":"KenRp Blog"}},"markdownRemark":{"html":"

shared-shopping-app は、共有買い物リストを家族や同居人どうしで管理するためのアプリである。今回の週次テーマでは、このアプリを「機能が動くだけの状態」から、「検索流入を受け止め、広告設定を安全に配信し、公開前チェックを継続できる状態」へ寄せた実装を扱う。

\n

単に公開ページを増やすだけでは、運用は安定しない。検索流入向けページ、ログイン後の操作画面、広告配信設定、Cloudflare 上でのビルドとデプロイ前監査、PC とモバイルで異なる UI 要件を、それぞれ混ぜずに分ける必要がある。この記事では、shared-shopping-app リポジトリで行った変更をもとに、公開運用に耐える構成へどう整理したかをまとめる。

\n

この記事で解決すること

\n\n

実装の要点

\n

この週に進めた変更は、大きく 4 つに分かれる。1 つ目は、公開ページとアプリ本体の責務分離である。app/page.tsx、app/about/page.tsx、app/contact/page.tsx、app/privacy/page.tsx、app/terms/page.tsx を公開向けの導線として整理し、app/layout.tsx に metadata と広告初期化を集約した。加えて app/robots.ts と app/sitemap.ts を用意し、検索対象を公開ページに限定した。

\n

2 つ目は、広告収益化の契約層を追加したことだ。lib/monetization.ts と lib/monetization-runtime.ts に、AdSense の publisher / client / slot 設定の検証を集め、app/api/ads/config/route.ts から placement ごとの広告設定だけを返す構成へ変えた。app/ads.txt/route.ts を追加して、ads.txt もアプリの配信経路に載せている。

\n

3 つ目は、公開前監査と Cloudflare 運用の自動化である。scripts/release-audit.mjs、tests/release-audit.test.ts、.github/workflows/ci.yml、.github/workflows/deploy.yml を更新し、必須ファイル、wrangler 設定、環境変数、型生成の前提が崩れていないかを build 前に確認できるようにした。さらに lib/cron-worker.ts と関連テストで、Cron 実行結果を構造化ログとして残すようにした。

\n

4 つ目は、PC 版買い物リスト画面の 3 カラム化である。components/list-detail-client.tsx と app/globals.css を中心に、左サイドバー、中央リスト、右サマリーのレイアウトへ変更し、モバイルでは既存のカルーセル UI を維持した。見た目の話に見えるが、実際には PC とモバイルで責務を分けてテストするための構造変更でもある。

\n

得られた知見

\n

成果は、公開向けの導線、広告配信、運用監査、利用画面の改修が別々の実装ではなく、同じアプリの公開運用を支える構成として接続されたことにある。検索流入は公開ページで受け、ログイン後画面や共有 URL はインデックス対象から外し、広告設定は契約層と API 層で検証してから UI に渡す。これにより、集客や収益化の追加がアプリ本体の責務を汚しにくくなった。

\n

検証の面でも前進がある。ワークログでは npm test と npm run build の成功、PC 版 E2E とモバイル E2E の成功、広告設定や監査スクリプトのテスト追加が確認できる。つまり、UI、設定、ビルド、運用前提のどこが壊れたかを、以前より狭い単位で検出しやすくなった。

\n

一方で、本番デプロイ完了や広告審査結果、実流入の改善効果までがこの週の一次証跡で揃っているわけではない。そのため、ここでの成果は「Cloudflare 上で公開運用しやすい構成へ寄せたこと」であり、「本番成果まで実証済み」とは切り分けて読む必要がある。

\n

実装プロセス

\n

最初に進めたのは、公開ページの整理だった。公開トップや法務ページに metadata、JSON-LD、広告導線を持たせる一方、/app や共有リンクのような利用者向け画面は検索対象から外す必要があった。そこで App Router のルート単位で public / private の境界を引き、robots.ts と sitemap.ts でインデックス対象を制御した。

\n

次に、広告設定を静的ファイルやコンポーネント直書きから切り離した。広告は外部スクリプト依存が強く、環境変数の typo もそのまま配信ミスにつながる。そこで ID 検証、placement 解決、ads.txt 生成を lib/monetization.ts に集約し、UI は API から返る設定を表示するだけに寄せた。失敗時は広告だけが無効になり、買い物リスト本体は壊さない構成である。

\n

そのうえで、公開前監査を CI と deploy workflow に組み込んだ。Cloudflare Workers / OpenNext 構成では、アプリコードの unit test が通っても、wrangler 設定や型生成、必須 env がずれていると本番で詰まりやすい。そこで release-audit と cf:typegen を build 前に挟み、アプリのテストとは別に「公開運用契約」を検査する層を作った。

\n

最後に、PC 版 UI を 3 カラムへ改修した。これは見栄えの改善だけではなく、同じデータ操作を PC とモバイルでどう見せ分けるかの設計判断だった。モバイル導線を壊さないため、状態管理は維持しつつ表示レイヤーだけを分岐させ、E2E も PC 用とモバイル用を分けて確認する流れになった。

\n

利用した技術

\n\n

アーキテクチャ

\n

この変更群は、公開層、体験層、収益化層、運用層の 4 段で整理すると分かりやすい。公開層は検索流入を受けるトップページやユースケースページで、metadata、JSON-LD、robots、sitemap を持つ。体験層はログイン後の買い物リスト画面で、PC は 3 カラム、モバイルはカルーセル UI として同じ操作ロジックを見せ分ける。収益化層は広告設定 API と ads.txt 配信、広告表示コンポーネントからなり、設定の契約と表示責務を分離する。運用層は release audit、cf:typegen、Cron ログ、CI / deploy workflow で、公開前に構成の破綻を検知する。

\n
flowchart LR\n  A["公開ページ<br/>page.tsx / use-cases"] --> B["アプリ本体<br/>ListDetailClient"]\n  C["広告設定契約<br/>lib/monetization.ts"] --> D["広告設定 API<br/>/api/ads/config"]\n  D --> A\n  C --> E["ads.txt route"]\n  F["release-audit / cf:typegen"] --> G["CI / Deploy Workflow"]\n  G --> A\n  G --> B
\n

重要なのは、公開ページ、広告設定、買い物リスト UI、運用監査を 1 つの巨大な層にしていないことだ。広告は UI に直接 env を持ち込まず、公開前監査はアプリ本体のコンポーネントから独立させている。これにより、変更箇所が増えても「どの責務で壊れたか」を追いやすい。

\n

選定理由

\n

Cloudflare 前提の既存構成を大きく崩さなかった理由は、公開運用の複雑さを増やしすぎないためである。別サービスで広告設定や監査を持つより、Next.js アプリと Cloudflare の配信経路の中で閉じたほうが、ビルド、デプロイ、運用手順を一本化しやすい。

\n

公開ページとログイン後画面を App Router のルート単位で分けたのは、SEO 強化と利用中画面の保護を同時に満たすためである。検索流入向けページには説明と広告を持たせたいが、共有リンクや個人操作画面まで検索対象にすると責務が崩れる。public / private をルーティングで切る判断は合理的だった。

\n

広告設定を lib/monetization.ts の契約層に集約したのは、AdSense ID や slot の形式ミスを UI で発見するのが遅すぎるからである。無効値を API 返却前に落とし、UI は「有効設定が来たら表示、無ければ表示しない」だけにした方が安全で保守しやすい。

\n

release-audit を build 前に入れたのは、Cloudflare 系アプリではコードの unit test だけで公開品質を担保しきれないからである。必須ファイル、wrangler 設定、型生成、env の契約を先に検査すれば、デプロイ段階で初めて気づく種類のミスを減らせる。

\n

PC 版 UI を完全別画面へ分離せず、表示層だけを分岐させたのは、モバイルの既存操作を残したかったためである。同じロジックに対して PC とモバイルの見せ方を変える設計なら、データ操作とテストの共通部分を維持しやすい。

\n

導入手順

\n
    \n
  1. まず App Router 上で、公開ページとログイン後画面の境界を決める。トップ、法務、ユースケースページのように検索流入を受けるルートと、利用者専用のルートを分ける。
    2. \n
  2. app/layout.tsx に metadata と広告初期化の共通設定を集め、app/robots.ts と app/sitemap.ts で公開ページだけを検索対象にする。
    3. \n
  3. 広告設定はコンポーネントへ直書きせず、lib/monetization.ts のような契約層へ切り出す。publisher / client / slot の形式をここで検証し、無効値は返さない。
    4. \n
  4. app/api/ads/config/route.ts のような route handler から placement ごとの最小設定だけを返し、app/ads.txt/route.ts で ads.txt も同じ配信経路に載せる。
    5. \n
  5. UI 側は components/ad-unit.tsx のような部品で広告初期化失敗を隔離し、広告ブロッカーや preview 環境でも本体利用を壊さないようにする。
    6. \n
  6. 買い物リストのような利用画面は、状態管理を共通にしたまま、PC とモバイルで表示レイヤーを分ける。今回の構成では ListDetailClient と CSS のメディアクエリで 3 カラム化した。
    7. \n
  7. テストは設定系と画面系を分ける。Vitest で広告設定、Cloudflare 設定、監査スクリプト、バックアップ、privacy ルールを確認し、Playwright で PC / モバイル UI と公開ページ導線を確認する。
    8. \n
  8. build と release 前には npm run build、cf:typegen、release-audit を通し、必要に応じて Cloudflare 向け build / deploy workflow へ接続する。本番 deploy や広告審査の成否は、別途運用ログで確認する。
    9. \n
\n

導入時の課題

\n

最初の課題は、集客導線を増やすほど public / private の境界が曖昧になりやすいことだった。公開トップやユースケースページに広告や metadata を足したい一方で、ログイン後画面や共有リンクまで同じ責務で扱うと、検索対象の制御が崩れやすい。

\n

次の課題は、広告設定の失敗が UI 側で発覚しやすいことだった。AdSense の ID は形式が厳密で、環境変数 typo や preview 環境の違いがそのまま無効表示につながる。設定検証を API より前に置かないと、表示部品に責務が寄りすぎる。

\n

また、Cloudflare 構成では、アプリ本体のテストが通っても wrangler 設定、型生成、必須ファイル不足で deploy が止まることがある。これは unit test だけでは拾いづらく、公開前監査を別レイヤーで持つ必要があった。

\n

UI 改修でも課題があった。PC 版とモバイル版の DOM が同居する構成では、E2E のセレクタが曖昧だと非表示要素を誤操作しやすい。そこで PC とモバイルのテストケース自体を分け、可視要素ベースで確認する必要があった。

\n

最後に、ワークログから確認できるのは build 成功や E2E 成功、コミット、監査スクリプト追加までであり、本番 deploy 完了や広告配信実績は別証跡が必要だった。実装済みと運用確認済みを混同しない整理も重要である。

\n

検証結果

\n

ワークログから確認できる範囲の検証結果は次のとおりである。ここでは「実装したはず」ではなく、記録上確認できた項目だけを列挙する。

\n
2026-07-20:\n- npm test: 成功\n- npm run build: 成功\n\n2026-07-24:\n- PC向け E2E: 成功\n- モバイル向け E2E: 成功\n\n2026-07-25:\n- tests/monetization.test.ts を追加\n- tests/release-audit.test.ts を追加\n- tests/cron-worker.test.ts を追加
\n

確認できた事実から言えるのは、公開ページ変更、広告設定変更、PC UI 改修、公開前監査の追加が、それぞれテストや build に接続されていることまでである。逆に、Cloudflare への本番 deploy 成功、AdSense 審査通過、実際の広告表示率まではこの週の source material だけでは断定できない。

\n

採用理由と代替案

\n

今回の判断で比較対象になったのは、公開運用の責務をどこで分けるかだった。たとえば広告設定は、コンポーネントへ env を直接渡す実装も可能だったが、不採用にした。設定ミスの検出が遅れ、preview と production の差異も UI に持ち込みやすいからである。

\n

ads.txt についても、静的ファイルを都度更新する運用は代替案としてあり得た。しかし、Cloudflare へ配備するアプリ本体と別経路で管理すると、ビルド済みコードと公開設定のズレが発生しやすい。そこで route handler で配信し、同じ deploy 単位に含める構成を採用した。

\n

PC 版 UI も完全な別画面化は代替案としてあり得たが、不採用にした。PC とモバイルでロジックまで分離すると、アイテム編集やリスト作成の修正が二重管理になりやすい。今回は状態管理を共通に保ち、表示だけを分岐させるトレードオフを取っている。

\n

次に検討した方が良いこと

\n","excerpt":"…","frontmatter":{"date":"2026年07月26日","path":"/2026-07-26-weekly-knowledge","title":"shared-shopping-app を Cloudflare 前提で公開運用しやすい構成へ寄せた実装","thumbnail":"/kenRp-blog/assets/kenrp-blog-replace-wireframe.jpg","metaDescription":"shared-shopping-app で、公開ページ、広告設定、公開前監査、PC UI 改修を分離しながら、Cloudflare 前提で運用しやすい構成へ寄せた実装と判断を整理する。","category":"Knowledge","tags":["cloudflare","nextjs","adsense","testing","weekly-knowledge"]}}},"pageContext":{"slug":"/2026-07-26-weekly-knowledge"}}}