[AI] このブログの改善を Claude Code に手伝ってもらったら、LLMは最高の相棒だった

WordPress から Astro へ移行したこのブログ、移行後にいくつか課題が残っていました。それを Claude Code(Anthropic の CLI 型コーディングエージェント。チャット版の Claude と同じモデルがターミナルで動くイメージ)に手伝ってもらって片付けたのですが、想像以上に「相棒」として優秀だったのでまとめておきます。

最初に立場をはっきりさせておくと、AI に丸投げして全部やってもらった、という話ではありません。むしろ逆で、判断と検証は人間が握りつつ、調査・実装・反復のスピードを LLM に任せる。この役割分担が一番ハマる、という体感の記録です。

何を直したのか

この日やったのは大きく3つ。

1. サイトマップが Search Console で「不明な形式・検出0件」になる問題
2. モバイルの PageSpeed Insights スコアが低い問題
3. npm audit で出ていた依存パッケージの脆弱性

それぞれ、独立した Pull Request に分けて対応しました。

1. サイトマップ問題：原因は「生成」ではなく「配信」だった

最初「sitemap-index.xml が正しく生成されていないようだ」と相談しました。ここが面白かったのですが、Claude はまずローカルでビルドして 「生成物自体は正しい」 ことを確認したうえで、こう切り分けました。

• ビルド成果物の sitemap-index.xml は有効な XML
• astro preview でも 200 / Content-Type 正常 / リダイレクトなし
• → だから原因はビルドではなく Cloudflare Pages の配信レイヤーにある

真因は、セキュリティのために _headers で全レスポンスに付けていた X-Content-Type-Options: nosniff でした。配信時の Content-Type が XML でないと、Google は中身を推測できずサイトマップを「不明な形式」として弾く。だから XML の Content-Type を明示固定する、という修正です。

/sitemap-index.xml
  Content-Type: application/xml; charset=utf-8

「生成が壊れている」という最初の見立てを鵜呑みにせず、症状から原因の場所を切り分けたのがよかった。ここは人間が雑に振った問いを、ちゃんと疑ってくれました。

2. モバイルのPageSpeed：犯人は画像だった

「モバイルの PageSpeed が低い」というざっくりした相談に対して、Claude はコードベースを調べて画像ペイロードを主因と特定しました。実際ひどくて、

• 記事内のスクリーンショットが 1枚で 11MB
• ファビコンに 4000×4000・1MB の画像をそのまま指定していた

このあたりを、最適化スクリプト(sharp で本文画像を最大幅へ縮小・再圧縮)を書いて一括処理。結果、ページ内の画像合計が 21.9MB → 3.6MB(約-83%) になりました。ファビコンも専用の小さいものを生成して 1MB → 1.7KB。

加えて Core Web Vitals 周りも、

• 記事のヒーロー画像が loading="lazy" で LCP 画像を遅延読み込みしていたのを eager + fetchpriority="high" に
• ビルド時に画像の実寸を読んで width/height を付与し CLS(レイアウトシフト)を防止
• 一覧サムネを background-image から、先読み可能な <img> に変更

と直していきました。

3. 依存の脆弱性：壊さない範囲で

npm audit の9件について、Claude は 「破壊的変更を伴うもの」と「伴わないもの」を分けて提案してきました。npm audit fix(semver 互換)で vite の high 2件などを解消し、残りは開発時の型チェッカー配下の依存で、修正に破壊的ダウングレードが必要・本番バンドルに含まれず実リスクも低い、という理由であえて見送る判断。

「全部直す」ではなく「壊さずに直せるところまで」という線引きを、理由つきで出してくれるのが実務的でした。

なぜ「丸投げ」ではうまくいかないのか

ここが本題です。今回スムーズに進んだのは、LLM に向かない仕事を人間が引き受けたからだと思っています。

症状を持ち込むのは人間

Search Console の「検出0件」も、PageSpeed のスコアも、私の手元にしか見えない情報です。さらに今回 Claude は実行環境のネットワーク制限で本番サイトに直接アクセスできなかった。だから「本番が実際どうなっているか」を確かめて伝えるのは人間の役目でした。

といっても、難しいことをする必要はありません。私は開発者なので最終確認に curl を叩いたりもしますが、たいていはエラーが出ている画面をもう一度開く——Search Console や PageSpeed Insights を再確認する、ブラウザでそのページを表示してみる——それで十分です。「自分の目で見た事実」さえ渡せば、LLM は的確に動いてくれます。観測そのものは、まだ人間の仕事です。

仮説と実装、反復は LLM が速い

逆に、「ローカルでビルドして検証 → 原因の場所を切り分け → 最適化スクリプトを書く → 何度も試す」みたいな手数のかかる部分は圧倒的に速い。画像最適化スクリプトをサッと書いて 28 枚を一括処理、なんてのは相棒に任せるのが気持ちいい領域です。

意思決定と検証は手放さない

• 脆弱性をどこまで直すか
• サイトマップの真因はどこか
• マージしていいか

こういう判断は人間が握る。Claude は選択肢と推奨理由を出してくれるので、こちらは「採用/却下」を決めるだけ。PR を機能ごとに分けてくれたので、レビューもマージも独立して回せました。

コツは「小さく区切って、根拠を聞く」

うまく付き合うコツを今回の体験から挙げるなら、

• タスクを PR 単位で小さく切る(レビュー可能な粒度に)
• 「なぜそう判断したか」を必ず言わせる(鵜呑みにしない材料になる)
• 確かめ方までセットで出してもらう(「この画面をもう一度開く」「ブラウザで表示してみる」など、自分の手で再現できる形で)
• 本番情報・最終承認は人間が持つ

まとめ

「AI に仕事を奪われる」みたいな話をよく聞きますが、今回の実感はかなり違いました。判断する人間がいて初めて、LLM は最高の相棒になる。症状を持ち込み、方針を決め、最後に検証する——その枠さえ握っていれば、調査と実装の速度は何倍にもなります。

このブログの中身(サイトマップの Content-Type、画像最適化、Core Web Vitals)も、それぞれ単体で記事になる小ネタです。気が向いたら個別に深掘りします。まずは、相棒として悪くないどころかかなり良い、という話でした。

気になった方は、まずブラウザから試せる Claude を触ってみるのがおすすめです。コードを書く人なら、今回使った Claude Code まで踏み込むと一気に世界が変わります。