3 サイトを総合監査して、24 項目を 1 日で潰した話
2026-05-07 ／ 第3号 ／ 公開時点では下書き
立ち上げから 3 日後（Day 4）。
3 サイトが同じワークフローで動くところまでは整えた。今日は、その先に「整える」方向の作業が一気に進んだ日になった。
結論：3 サイトを横断的に監査したら 24 項目の課題が出てきて、それを全部その日のうちに潰した。Astro 移行の長期課題以外、すべてクローズ。
朝、Search Console から通知が来ていた
Gmail を開くと Google Search Console から karaha.org について「代替ページ（適切な canonical タグあり）」の通知。意味が分からなかったので、通知のスクショを Claude に投げた。
これは Google が「インデックスに登録しない」と判定したページがある時の通知です。今回は
/home/という古い URL が 404 になっているのが原因。Google Sites 時代の URL が残っていて、検索結果からのアクセスで 404 を返している。
あ、と思った。
karaha.org は元々 Google Sites で運用していて、そこから Cloudflare Pages に移したサイトだ。/home は新サイトには無い。
_redirects に 2 行追加で済んだ。
/home / 301
/home/* /:splat 301
これで /home も /home/whatever も全部トップへ 301。GSC で「修正を検証」を押して終わり。
旧 Google Sites の遺産が、もう 1 サイト分埋まっていた
1 行で直る話だったが、ここで気になった。「esynet.jp と rooo.pro にも同じパターンないか」。Claude に確認を投げた。
esynet.jp、ありました。/ホーム/所在地連絡先、/ホーム/お知らせ、/ホーム/blog、/ホーム/主な取扱商品、/ホーム/運営取引情報、/ホーム/お問い合わせ、そして /ホーム 自体。7 件全部 404。
これも _redirects に 7 行で対処。日本語パスは Cloudflare がマッチさせる時に URL エンコードが必要なので、Python で encode して書き出した。それぞれ /legal/tokutei/（住所掲載ページ）、/#products アンカー、/#contact アンカー、トップ、と v2 サイトの相当ページへ振り分けた。
rooo.pro は元々白紙からのスタートで過去 URL 資産がほぼなく、致命的な問題は無し。GSC に古い sitemap 提出と URL prefix プロパティだけ残っていたので削除して綺麗にした。
「ついでに総合的に監査して」と投げた
3 サイトとも GSC の警告は収まった。でもここで思った。「他に未整備な項目、たぶんいっぱいある」。
立ち上げから 3 日。動いてはいるが、見落としは絶対多い。1 つ警告が来てから慌てるよりも、先に網羅的に洗い出したい。Claude にこう投げた。
3 つのサイトを様々な視点で総合的にチェックして改善提案してほしい
Claude は調査エージェントを走らせて、しばらくしてから 10 観点 × サイト別に整理した提案を返してきた。SEO、a11y、パフォーマンス、セキュリティ、モバイル、UX、コンテンツ、保守性、クロスサイト整合、build-in-public 適性。
合計 24 項目。優先度は 高 6・中 13・低 5。さらに「現状でセーフだが気になる点」として esynet.jp の特商法での運営責任者表記が挙がった。
一番ヒヤリとした項目
監査結果の冒頭で、Claude がこう書いてきた。
esynet.jp と karaha.org のプライバシーポリシーは「Cloudflare Web Analytics を利用」と明記しているが、HTML に beacon スクリプトが入っていない。事業者サイトでこの不整合は最もまずい部類です。
3 サイトとも実環境を curl で確認したら、本当に beacon が一切入っていなかった。
事業者サイトとして「使っている」と書きながら実は使っていない、というのは法的に微妙な状態。
Cloudflare ダッシュボードで Web Analytics の「自動セットアップ」が ON になっていたのに、なぜか HTML に入っていない。理由は、Cloudflare Pages 配信のサイトでは自動注入が機能しない仕様だった。手動セットアップでトークン発行 → 33 ファイル全部の </body> 直前に beacon を挿入 → push。
数分後、curl で 3 サイト全部 beacon が確認できた。プライバシーポリシーと実装が整合した瞬間、今日のヤバさのトップが消えた。
OG 画像だけは AI に任せられない
監査の高優先度項目に「rooo.pro の og:image が 4 ページ全部で未設定」があった。X や Slack に URL を貼った時、白いカードが出る状態。
これは Claude にまるっと任せられない作業だ。Cloudinary に画像を 1 枚アップロードする作業が必要で、しかも画像そのものを生成する判断は私の側。
その間 Claude は他の修正を進めていてくれた。私は別途、「rooo」の文字をベースに、Google カラーの円や三角形を散らした OG 画像を別 AI で生成 → Cloudinary にアップ → URL を Claude に渡す → 4 ページに meta タグ反映、という流れで合流した。
「画像作って」までを自動でやってもらうことはできない。でも「ここの作業はこれが必要」と Claude が指摘してくれる時点で、私が見落とすことは無い。役割分担として、これは健全だ。
Tailwind を 3MB から 29.3KB に圧縮した
監査で大きな指摘の 1 つが、karaha.org が Tailwind CDN（cdn.tailwindcss.com）を本番で使っていたこと。
Tailwind 公式が "not for production" と明記しており、3MB 級の JIT を毎ロード走らせる。
これは前から認識していた長期課題だ。今日それを片付けることにした。
ただし、ローカルに Node.js が入っていない。ビルド環境を整えるのは大ごとに見えた。Claude が代案を出した。「Tailwind の standalone CLI バイナリを使えば Node 不要」。
Tailwind v3.4 の Windows 用 standalone バイナリ（40MB の単体実行ファイル）を /tmp にダウンロード → tailwind.config.js と src/main.css を作成 → standalone CLI でビルド → styles.css 29.3KB が生成。
各 HTML から <script src="https://cdn.tailwindcss.com"></script> を <link rel="stylesheet" href="/styles.css"> に置換（15 ファイル機械処理）。
3MB+ の毎回 JIT ダウンロードが、29.3KB の静的 CSS に置き換わった。 FCP が体感で変わるはず。
残った中堅課題を順に潰す
ここから先は、「ひとつ 5〜30 分」の作業を順番に。Claude に「順番に進めて」と投げて、私はそれを確認・許可するモードに入った。
・canonical タグを 3 サイトに統一（rooo.pro と esynet.jp に欠けていた。karaha.org は最初から完備）
・og:locale / twitter:card / twitter:site をすべて統一
・rooo.pro の sitemap.xml に <lastmod> 追加
・rooo.pro の全ページに skip-link と <main> ランドマーク（凍結している versions/v0/ を除く）
・karaha.org の event カードのテキスト色を 1 段明るくしてコントラスト比を WCAG AAA 達成
・karaha.org の Google Fonts を <style>@import url(...)</style> から <link rel="preconnect"> + <link rel="stylesheet"> 形式に統一
・esynet.jp の Cloudinary 画像 URL に f_auto,q_auto,w_* 変換を付加（hero / 商品 5 枚）
・esynet.jp に Organization JSON-LD 追加
・esynet.jp の hero 画像に width / height / loading / fetchpriority 属性
・esynet.jp の Google Maps iframe の grayscale を軽くしてモバイル touch でも読みやすく
・esynet.jp の v1 時代の /blog ページに noindex メタタグ
・3 サイトの _headers に Content-Security-Policy（script/style/img/font/connect/frame の各ソースをホワイトリスト化）
・karaha.org の :root CSS 変数を src/main.css に集約して各 HTML から重複削除
CSP 設定後はブラウザコンソールで違反が出ていないことを 3 サイトとも確認した。0 件だった。
3 サイト横断のメリットが、初めて実感できた
同じ問題が 3 サイトに同時にあった。だから対処も 3 サイトに同時に書けた。
例えば canonical タグ：rooo.pro と esynet.jp に欠けていた → 一気に追加。Cloudflare Web Analytics：3 サイト全部「実装ゼロ」 → 3 つのトークンを取って 3 サイトに beacon 挿入。CSP：3 サイトの _headers に同じ構造で（必要ドメインの違いだけサイトごとに反映）。
2 日前に「3 サイト横断で運営したい」と書いた時は、漠然とした希望だった。
今日それが、実利益として体感できた。
自分でしか決められないこと
監査の最後の項目は esynet.jp の特商法表記だった。「運営責任者は省略・請求あれば開示」という現状の表記。法的には完全にセーフ（消費者庁 2022 改正で明示的に認められた手法）。Yahoo!ショッピング側で氏名は開示されている。
Claude は「現状でセーフ。ユーザー判断事項です」と返してきて、止まった。判断を私に委ねてくれた。
少し迷ったが、決めた。運営責任者：浅野 英司、電話：080-4865-0476、両方とも公開する。
X（@eijiasano_）でも rooo.pro の運営者として既に出ている名前だ。隠す意味は、もう薄い。電話も、開かれていた方が事業者として誠実だと思う。
esynet.jp の特商法ページとトップの Contact セクション、Organization JSON-LD の founder と telephone も同時に更新した。検索結果のナレッジパネルで「esy net」を引いた時に、運営者と連絡先がきちんと表示される状態。
AI を使う運用の、見えてきた形
立ち上げから 3 日、未整備な項目はあって当然だった。それを「未整備のまま少しずつ気づいて直す」運用ではなく、「監査というフレームで一気に全部洗い出す」運用に切り替えたら、想像以上に速く・深く動けた。
これは AI を相棒にする運用の、結構大きな利益だ。1 人で監査リストを作るのは骨が折れる。Claude に「総合的に監査して」と投げると、観点漏れなく出してくる。後はそれを読んで判断・実行するだけ。
もう一つ印象的だったのは、Claude が 「これはユーザー判断事項です」と勝手に決めずに止めるところ。特商法の氏名公開、og:image の作成、特定の URL の意図確認 ── どれも「判断は人間側」と明確に返してきた。AI に何でも任せるのではなく、判断の境界が見えている。これは一人運営者にとってかなり大事な設計だと思った。
次は
残った将来課題は rooo.pro の Astro 移行だけ。記事数が増えてからで OK。
あと数日中に、Cloudflare Web Analytics の実データが見え始めるはず。「数字を見るのは 2 ヶ月目から」と決めていたので、見ても何かを判断するわけではない。ただ、まず動いていることを確認する。
監査・対処・整合性確認、全部 1 日で。
Day 4 を、そう呼ぶ。