Claude Codeで実サイトを運用して見つけた欠陥の記録

いま困っていることから探す

症状から直接飛べるようにしてあります。どれかに当てはまるなら、そのページから読むのが早いです。

どの記事も、先に結論と手順、後ろに証拠としての実測記録という並びにしてあります。急いでいるなら各ページの最初の節だけで足ります。

まずひとつだけ確かめるなら、これ

このサイトで見つけた中でいちばん割に合う点検を、先に置いておきます。所要10秒で、あなたのサイトでも今すぐ試せます。

curl -I http://あなたのドメイン/
curl -I https://www.あなたのドメイン/
curl -I http://www.あなたのドメイン/

3本とも 301 が返り、Location が正規のURLを指していれば正常です。どれかが 200 を返したら、同じページが複数のURLで配信されていて、クロールの予算を最大4分割しています。

運用中の17サイトを実測したところ、15サイト（初日に10サイト、翌日の洗い直しでさらに5サイト）がこの状態でした。ページのソースを見ても分からない欠陥なので、誰も気づかないまま運用していました。判定の仕方と直し方は記録にまとめてあります。

ここに書いてあること

運用しているのは90サイト前後で、いずれも実際に検索から人が来ています。テスト用の題材ではないので、間違えると本当に順位が落ちますし、申し込みが止まります。そういう環境でClaude Codeを毎日使って出た失敗を、再現手順つきで残しています。数えるだけの検査、1件だけ見る標本検査、HTMLだけを見る検査はどれも通ってしまう——そういう類の話です。

直近の記録（2026年8月〜9月1日）

このサイトの記事は実際の作業日と対応しています。新しい順に並べています。

• 【9月1日】被リンクの測定を誤り、存在しない問題を181ページぶん直しかけた。相対パスだけを数えて絶対URLのリンクを見落としていました。「リンクゼロ31ページ」は測定エラーで、改修計画ごと破棄しました（記録）
• 【8月13日】sitemapの検査を4種類書いても、1ページが素通りした。どの検査も本番のsitemapを読んでいなかったためです。本番との差分を毎回取る検査Eを足しました（記録）
• 【8月8日】HTTP取得の1行が原因で、日本語ページを56本壊した。ストリームの文字列連結はマルチバイト文字をチャンク境界で壊します。原本との突き合わせで36本と20本に切り分けました（記録）
• 17サイトで、同じ内容が4つのURLから200で返っていた。canonicalは全サイト正しく、HTMLからは見えない欠陥でした。.htaccessの301で1本に寄せ、全サイトで301が3/3になったことを確認しました（記録）
• 初日に「全部直した」と判断したのは誤りだった。対象サイトの一覧そのものが古く、翌日に5サイトの漏れが見つかりました。うち1サイトは143URL中14本しか検索結果に出ていない状態でした
• 検査スクリプトが、検査対象を取りこぼしていた。ある欠陥を横展開検査するために作ったスクリプトの対象一覧に、その欠陥が最初に見つかったサイト自身が入っていませんでした。7本・139表示ぶんの取りこぼしが、検査されないまま残っていました（対策）
• 公開直後の全数検査で、canonicalの二重スラッシュを18件検出した。sitemap側のURLは正しかったので、両者を突き合わせなければ気づけませんでした
• Search Consoleの「取得できませんでした」が一過性だった。こちら側の実測は4点とも正常で、再送信したら翌日「成功しました」に変わりました（切り分け方）

5件に共通するのは、作業そのものではなく、対象の一覧と確かめ方の側に欠陥があったことです。手を動かす部分はAIが失敗しません。失敗が入り込むのは、その外側です。

同じ型は繰り返し出る｜型で引く索引

個別の事例は毎回違って見えますが、欠陥の型は数が限られています。いま自分の環境で起きている症状から引けるように、型で並べておきます。

「新しい失敗をした」と思ったときも、あとから見るとこのどれかの変奏でした。型として持っておくと、原因調査の初手が速くなります。

なぜ「確かめ方」の話ばかりなのか

Claude Codeに100ファイルの書き換えを頼むと、ほぼ確実に100ファイルとも書き換わります。そこは失敗しません。失敗するのは、書き換えた結果が意図どおりかどうかを人間が判断できなくなるところです。1ファイルなら目で見れば分かりますが、100ファイルは見られません。

そこで検査コードを書くわけですが、この検査コード自体がよく間違っています。実際に出た例を挙げます。

• 絶対数で見て偽陽性：変更後の <div> と </div> の数が合わないので壊れたと判定した。実際には変更前から合っていなかった。差分で見るべきだった
• 探す範囲が狭くて偽陽性：<main> の中だけを見て「h1が空のページがある」と報告した。h1は <main> の外にあった。全体を見たら1,018ページで欠落ゼロだった
• 空を「合格」と読んで偽陰性：応答が空のときに「未登録の文言が含まれていない」が真になり、未登録のドメインを「登録済み」と表示した

3つとも、コードは意図どおりに動いています。壊れていたのは判定の条件です。だからこのサイトでは、直した手順と同じ分量でどう確かめたかを書いています。

読む前に知っておくとよいこと

ここに書いてあることは、次のような条件で起きた話です。あなたの環境と違う部分は読み替えてください。

Linux上のGitリポジトリで完結する開発とは前提がかなり違います。とくに「本番サーバーのファイルを直接書き換える」という部分は、普通の開発ならまずやりません。バージョン管理が効かないぶん、退避と検査で担保する必要があり、そこがこのサイトの主題になっています。

一方で、規模の大きさに関係なく効く話もあります。差分で見る、全数で見る、否定形で判定しない。このあたりは環境を問いません。

書き方の方針と更新のしかた

読んで損をしないように、次のルールで書いています。

• 実測した数字だけを書く。「速くなります」ではなく「10サイトで301が3/3になった」と書きます。測っていないことは書きません
• 失敗した経路も書く。うまくいった手順だけ並べると、読んだ人が同じ穴に落ちます
• 日付を書く。ツールもサービスも仕様が変わります。いつ時点の話かが分からない記事は害になります
• 環境を書く。上の表のとおりです。ここが違うと再現しない話が混ざります

更新は、実際に作業をした日にその作業から記事を起こす形です。公式の発表を追いかけて解説する形は取っていません。手を動かした側にしか書けないことのほうが、読む価値があると考えているためです。そのため更新は不定期で、作業がなければ記事も増えません。逆に、ひとつの作業から複数の記事になることもあります。

すでに公開した記事も、後から事実が変わったことが分かれば書き換えます。その際は、いつ何を変えたかを該当箇所に残します。読み返したときに「この記述はいつ時点のものか」が分かるようにするためです。Claude Code そのものの機能や設定（何ができるか、どう設定するか）は姉妹サイトの claudeguide.jp 側にまとめてあります。このサイトは、その機能を使って実際に運用した結果のほうを扱います。

よくある質問