誰かが「一人で29日間、26のリポジトリにわたって335個のライブページをデプロイした」と言えば、誰もが「どうやってそんなに速く進めたのか」と聞きたくなるだろう。しかし、より適切な問いは「その過程で何が壊れたのか」である。
数字は事実だ。1,549件のコミット、26のリポジトリ、29日間、そしてClaude Codeを使用する一人の開発者。しかし、速度そのものからはほとんど何も学べない。重要なのは失敗の「質感」だ。なぜなら、それらはスタックトレースで捉えられるような種類のものではなく、構造的な亀裂だったからだ。エディタから離れ、本番環境で稼働しているシステム全体を俯瞰したときに初めて、それらは姿を現す。
うまくいったこと
そのスピードは錯覚ではなかった。眠らないAIに任せることで、特定のタスクの所要時間は劇的に短縮される。
教科書通りのアルゴリズムが、数週間ではなく数日で実装可能な機能へと変わった。「2048」のソルバーやminimaxベースのゲームが迅速に完成したのは、その実装パターンが十分に文書化されていたからだ。モデルは学術論文の中で迷走することはない。探索ツリー、ヒューリスティック評価、手のスコアリングを書き上げ、次のタスクへと進む。これらは解決済みの問題であり、AIペアプログラマーはそれらを圧倒的な効率で処理する。
退屈な監査作業も耐えられるものになった。リンクグラフのクロール、リダイレクトチェーンの検証、数百ページにわたるcanonicalタグのチェック。こうした作業は人間の集中力を削ぐが、言語モデルは不平を言うことなく繰り返してくれる。同じパターンを300回チェックし、結果を報告してくれるのだ。
本当の驚きは一貫性だった。AIに数十ものランディングページを生成させると、アンカー（固定要素）がない限り、内容のブレは避けられない。私は小さなメモリファイルを使用して、ブランドシステムを一つに固定した。トーン＆マナーのルール、カラー・トークンの名称、コンポーネントの制限、そしてページのアーキタイプだ。モデルは各タスクの開始時にそれらの制約を読み込み、29通りの異なる気分で書かれたものではなく、まるで一人の手によって作られたかのような成果物を出力した。
実際に壊れたもの
失敗の本質はアーキテクチャにあった。セミコロンの欠落でビルドが失敗することなどなかった。むしろ、システムが「すべて順調である」と私をゆっくりと欺いていったのだ。
最初に起きたのはSEOのカニバリゼーション（共食い）だ。 古いツールハブが元のパスに残っている間に、AIが新しいURLの下に新しいツールハブを構築してしまった。個々のページは最適化されていた。タイトルは的確で、メタディスクリプションはユニーク、コンテンツも有用だった。しかし、それらはすべて同じ検索意図を狙っていた。検索エンジンは、同一のキーワードに対して2つの権威性を検知し、どちらもランク付けしなかった。サイトを単なるファイルの集合体としてではなく、一つのポートフォリオとして管理していなかったため、完璧なページ同士が互いを打ち消し合ってしまったのだ。
次にURLの不一致が続いた。 同じ論理的コンテンツに対して、リポジトリごとに微妙に異なるフォルダ構造が採用されてしまった。あるリポジトリではツールを /tools/utility-name の下にネストし、別のリポジトリでは /utility-name とフラットに配置した。CDNは両方を検知し、それらを解決するためにリダイレクトチェーンを生成し、エッジでエラーを出し始めた。ページは最終的に読み込まれたが、リダイレクトのたびにクロールバジェットとユーザーの忍耐が削られていった。コードは正しかった。トポロジー（構造）がめちゃくちゃだったのだ。
そして、同期の罠がやってきた。 ステージングやバックアップ用のミラーサイトを更新したが、その変更をソースリポジトリに反映させるのを忘れてしまった。その後、AIに環境の同期を依頼したところ、AIはミラーサイトを「正解（ground truth）」として扱った。単純な同期コマンドを実行すれば、本番環境のデータベースやファイルセットが、古いミラーデータの状態で上書きされてしまうところだった。AIは私が「意図したこと」ではなく、私が「指示したこと」を実行したのだ。意図にはdiffはない。差分があるのはファイルだけだ。
監査ツール自体が嘘をついた。 監査を自動化したため、出力はクリーンなものだと思い込んでいた。しかし、実際は違った。AIが書いた監査スクリプトには、オフバイワン（境界値）のミス、リダイレクトのステータスコードに関する誤った想定、実際の構成ミスではなくタイミングやヘッダーによって引き起こされる幽霊エラー（phantom errors）といった、微妙なバグが含まれていた。存在しない問題を報告されたことで、私は幻影を追いかけることになった。ライブサイトを実際に調査し、ブラウザや直接の curl で症状を確認するまでは、静的解析を信用しないことを学んだ。
隠れたコスト
誰も語らない数字がある。私のトークン消費の93パーセントは、キャッシュされたコンテキストの再読み込みに費やされていた。
Claude Codeの長いセッションでは、新しいリクエストのたびに、モデルはこれまでの会話履歴、ファイルバッファ、およびワーキングメモリを再確認する必要があります。セッションの最初のタスクは安価かもしれませんが、10番目のタスクになると、モデルは次の文章を理解するためだけに、それまでのすべてを消化しなければなりません。コスト曲線は急激に上昇します。長いセッションは高価な「読み直し」作業へと変わり、コンテキストウィンドウは現在の作業とは無関係な、以前のジョブの残骸で埋め尽くされてしまいます。
これは単なる癖ではありません。不適切なセッション管理に対する直接的な税金なのです。
解決策
問題を明確に定義すれば、解決策は単純でした。
1つのセッションを1つのタスクとして扱ってください。作業内容が変わったら、新しく始めてください。コンテキストを維持しておきたいという誘惑は強いものです。セットアップ時間を節約しているように感じるかもしれませんが、実際には複利でメモリを借りているようなものです。
知識は、小さく専用のメモリファイルに保持してください。ブランドガイドライン、コンポーネントライブラリ、SEOルールなどを会話のコンテキストの中に持ち込ませてはいけません。それらを簡潔なファイルとしてディスクに書き込み、明示的に参照させてください。これにより、情報の所在を、高価で揮発性の高いコンテキストから、安価で永続的なストレージへと移動させることができます。
異なるジョブの間では、一旦リセットしてください。セッションを閉じ、新しいセッションを開きます。30秒のセットアップが、後の数ドルものコストとハルシネーション（幻覚）を防いでくれます。
スケーリングのための教訓
このような規模で作業を行うのであれば、ファイル単位ではなく、システム単位をレビューの単位とするガードレールが必要です。
公開前にベンチマークを取る。 ページがレンダリングされるからといって、正常に動作すると決めつけてはいけません。デプロイされたURLで、ロード時間、モバイルレイアウト、およびコアメトリクスを確認してください。ローカル開発環境で美しいコンポーネントも、実際のネットワーク条件下では崩壊することがあります。
コピーする前に差分（diff）を確認する。 一括同期やコピー操作を盲目的に実行してはいけません。デルタ（差分）を確認してください。データがどちらの方向に流れているかを理解してください。AIは、あなたがライブの顧客データを上書きしようとしていることを警告してはくれません。
監査結果を鵜呑みにする前に、ライブサイトを調査する。 静的解析はあくまで仮説です。ライブリクエストこそが証拠です。監査ツールがリンク切れやリダイレクトループを報告したときは、直接リクエストを送って検証してください。ツールにもバグはあります。特に、推論されたパターンに基づいて動作するAIによって書かれたツールには注意が必要です。
スケールする前に規約を書き留める。 URL構造、フォルダ階層、カノニカルパターン、コンテンツのタクソノミー（分類）などは、AIが新しいページを1つ生成する前に、AIが読み取れる場所に文書化しておく必要があります。メモリファイルは、...においてオプションではありません。