361記事のHTML修正をClaude Codeで秒殺。手動の絶望が消えた日。

※この記事は、Claude Codeで1人開発しているSNS運用SaaS「ThreadPost」の開発日記だ。

SNS運用を自動化しませんか？

ThreadPostなら、投稿作成・画像生成・スケジュール管理までAIがサポート。

無料で始める

361件のHTML崩壊と、深夜の絶望

画面を開いた瞬間、血の気が引いた。

ブログの比較表が全て崩れて、画面上に生のテキストがそのまま転がっている。

「| 項目 | 機能 | 価格 |」という記号の羅列が、361記事のすべてで露出していた。

手動で直せば丸数日。開発が止まる。

21件のコミットと、崩壊したブログの再構築

今週はブログのSEOハブ化と、キャンプ動画の自動生成パイプライン構築に追われた。

コミット数は21件。新機能が8件、バグ修正が6件だ。

ブログの表示崩れを一括で直しつつ、タグの正規化とSEOチューニングを完遂させた。

AIに作業を丸投げするのではなく、AIが暴走しないための制約をコードで書く。これが品質を左右する。

しんたろー:
361記事の全修正が数分で終わった。修正漏れゼロ。昔の僕なら手動で全記事開いて3日間は潰してた。時給換算すると数十万円浮いた計算だ。

361記事のテーブル表示が全滅。Claude Codeで一括再生成した夜

ある日の深夜、ブログのハブ記事を見直していて凍りついた。

比較表として綺麗に並んでいるはずのデータが、ただの生のパイプテキストになっていた。

原因はすぐに特定できた。

ブログのMarkdownパーサーである「markdownToHtml」関数に、テーブル記法のHTML変換ロジックがすっぽり抜け落ちていた。

361記事すべてで比較表が全滅している。

1人開発で361ファイルのHTMLを手動修正してビルドし直すのは、拷問だ。

僕はClaude Codeを起動して指示した。

「markdownToHtmlにテーブル対応のHTML変換を追加して、既存の361記事のHTMLを全部再生成してくれ」

Claude Codeは「fix(blog): markdownToHtmlにテーブル対応追加+361記事のHTML再生成」というコミットを残し、数分でスクリプトを実行した。

Markdownパーサーの拡張は、置換ミスで本文全体を破壊するリスクが高い。

特に横幅の溢れによるモバイル表示の崩れは、CSSの「overflow-x: auto」を適切なラッパー要素で囲まなければ確実に発生する。

Claude Codeはヘッダー行の判定ロジックを追加した上で、テーブル全体を自動で横スクロール可能なラッパー「div」で包むコードを吐き出した。

そしてデータベース内の全361記事のMarkdownを再読み込みし、HTMLフィールドを一括更新した。

画面をリロードすると、崩れていた比較表が一瞬で美しいテーブルに化けた。

モバイルで確認しても横スクロールが滑らかに動く。

昔なら絶望して頭を抱えていた作業が、カップラーメンにお湯を注いで待つくらいの時間で終わった。

手動でちまちま修正するという概念自体が、僕の頭から完全に消え去った。

1日1本の動画自動生成。ルールを無視するAIとの泥泥の格闘

ブログの修正で味をしめた僕は、次にInstagram向けのキャンプ動画連載「キャンプヒロイン」の日次自動生成パイプラインに着手した。

今まで手作業で動画の構成を作っていた時は、1本のスクリプトとカット割りを作るのに半日潰れていた。

1人開発の合間に毎日投稿するなど不可能だ。

そこでClaude Codeを使い、プロンプトとバズ分析データを読み込ませて、日次で自動量産するスクリプト「gen-daily-camp-reel.ts」を書き上げた。

コミットメッセージは「feat(camp-heroine): 日次量産パイプライン本体 + 正典最終ルール群」。

これで完全に自動化できる、と高括っていた。

しかし、待っていたのはAIの「ブレ」という底なし沼だった。

AIは生成を重ねるにつれて、過去のストーリーと矛盾する展開を勝手に吐き出し始めた。

前回のカットで壊れたはずのギアが次のカットで新品になっていたり、主人公の服装が崩壊したりする。

大規模言語モデルは、コンテキストが長くなると初期の指示や世界観の設定を軽視する。

アテンション機構の重みが後ろのトークンに偏り、過去の約束事を平気で破るからだ。

「お前、また設定忘れたろ」と画面の前で何度ツッコんだかわからない。

プロンプトの文章をどれだけ丁寧に捏ね繰り回しても、AIは少し目を離すとすぐにルールを破って暴走した。

結局、僕が行き着いたのはプロンプトテクニックではなく、コード側で絶対に破れない制約を定義する「正典（canon）」構造だった。

キャラの服装、カメラのカット割り、登場するギアの型番、5ショット構成のルールを「canon-prompt-blocks.md」という正典ファイルに切り出し、スクリプト実行時に強制参照させるロジックを組んだ。

AIに自由な発想をさせるのをやめ、正典という狭い檻の中に閉じ込めた。

量産において重要なのは、文章の巧みさではなく「AIが逃げられない制約の設計」だと身に染みて理解した。

しんたろー:
プロンプトを100回書き直すより、1個のバリデーションコードを書いた方が100倍早い。AIは自由にさせるとすぐ調子に乗る。正典ファイルで縛り上げてようやく日次投稿が安定した。

ここまで読んだあなたに

今なら無料で全機能をお試しいただけます。設定後はAIが投稿案を毎日生成。確認して選ぶだけ。

無料で始める

落とし穴

Instagramの投稿ロジックで今週一番冷や汗をかいた。

最初はアカウントのアクションブロックを防ぐため、投稿枠を昼の1枠だけに絞り込む修正を行った。

「fix(ig): フィード投稿を昼の1枠のみに(アクションブロック対策+IG定石)」というコードを書いた時のことだ。

スクリプトをテスト実行すると、InstagramのAPIが「エラーコード 2207051」を返してきた。

画面には「投稿失敗」の文字。

通常なら、APIがエラーを返したら即座にリトライ処理を回すのがプログラミングの定石だ。

しかし、何か嫌な予感がして、手元のスマホで自分のアカウントを直接見に行った。

目を疑った。

画面には、APIが「失敗した」と言っていたはずの投稿が、綺麗にフィードに並んでいた。

もしAIの指示通りにリトライ処理を連打していたら、同じ内容が短時間に何十回も投稿され、スパム判定でアカウントが一発で凍結されていた。

Instagram Graph API では、メディアのパブリッシュ処理がタイムアウトしても、バックエンド側で処理が完了しているケースが稀に存在する。

APIの戻り値だけを信用すると、この「幽霊投稿」にハメられる。

僕はすぐに昼枠限定の修正を撤回し、コードを全面的に書き換えた。

「fix(ig): 昼枠限定を撤回+publish誤エラー時の実在確認」のコミットだ。

エラーが返ってきたとしても、すぐにリトライするのではなく、直近の投稿メディアをGET APIで照会し、同じキャプションの投稿がすでに存在するかを裏で実在確認する判定を挟んだ。

AIやプラットフォームの返答を盲信せず、泥臭く事実を確認するコードを入れたことで、僕が自分で自分のアカウントを爆破する危険は去った。

しんたろー:
APIの戻り値を信じてリトライ処理を組んだら、その瞬間に垢BANだった。AIが「失敗」と言っても、画面を見るまで信じるな。これが教訓だ。

今日の数字

今週の主要実績とパフォーマンスをまとめた。

開発・運用パフォーマンス比較

項目	今週の実績	従来（手作業）	変化・インパクト
コミット数	21件	週10件前後	開発スピード2.1倍
361記事のHTML修正	約3分	約40時間	作業時間99.8%削減
タグ表記揺れの修正	393件一括	約8時間	データ整合性100%