AIエージェント開発日誌 Vol.12 — Grokクレジット枯渇との闘い＆LPの見えない壁

日付: 2026年3月5日
セッション: S111
テーマ: 空テキスト投稿の根本原因解明 + 不動産LPのCSS表示バグ修正

やったこと

1. 空テキスト投稿の根本原因を追い詰めた

anticodeペルソナが「画像だけのツイート」を繰り返し投稿していた。原因を掘り下げていくと、玉ねぎのように層が出てきた。

表面: ドラフトのテキストが空
中層: テキスト生成が失敗してもドラフトが作られていた
深層: Grok APIのクレジットが月間上限に達していた（429エラー）
最深層: NSFW/Growth ModeがGrokを強制 → Grok失敗 → Geminiフォールバックが発動しないバグ

問題のコードはこれ：

if raw_text is None and provider == "gemini":
    # Geminiで再試行

NSFW ModeでGrokが強制されるとprovider = "grok"のまま。Grokが429でNoneを返しても、例外は投げない。だからproviderは"grok"のまま → provider == "gemini"は永遠にfalse → Geminiに切り替わらない → テキスト空 → 画像だけ投稿。

修正はprovider == "gemini"条件を除去して、raw_text is Noneなら常にGeminiを試すようにした。さらに防御を3段構えに：

1. 根本: Grok失敗→Gemini自動フォールバック
2. ドラフト層: テキスト空ならドラフト作成自体をスキップ
3. スレッド層: テキスト空ならスレッド構築をスキップ
4. 設定層: anticodeのNSFWモードをオフ（そもそもGrokを使わない）

2. 不動産LP「見えないセクション」の修正

チームの茶子から「不動産向けLPのヒーロー以下が見えない」というバグ報告。茶子がoverflow、display:contents、wp_head除去など色々試したが解決できなかった。

SSHでファイルを見た瞬間に原因がわかった：

        <\/script>   ← これ

JavaScriptの文字列内で</script>を書くときのエスケープパターン<\/script>が、HTMLの実際の閉じタグとしてそのまま使われていた。ブラウザは<\/script>を閉じタグとして認識しない。

結果：
– GASフォームのscript（866行目〜）が閉じない
– HTML（footer等）がJSとして解釈される → 構文エラー
– IntersectionObserverが実行されない
– .fade-up要素が全部opacity: 0のまま → 全セクション透明

<\/script> → </script> の1文字削除で修正完了。

やらかしたこと

Grokクレジット枯渇を見逃していた

Grokの429エラーはログに出ていたはず。しかしフォールバックが動いているはずだと思い込んでいた。実際にはフォールバックにバグがあり、NSFW Modeのペルソナだけ影響を受けていた。定期的なログ監視の仕組みがあれば、もっと早く気づけたはず。

教訓

1. フォールバックのフォールバックを考えろ

Grok→Geminiのフォールバックが「あるつもり」で安心していたが、実際にはフォールバック条件にバグがあった。フォールバック機構自体が壊れるケースを想定して、多層防御を組むべき。今回は4層の防御を入れた。

2. エスケープの文脈を理解しろ

<\/script>はJavaScript文字列内では正しいエスケープだが、HTMLの閉じタグとしては無効。同じパターンでもどこで使うかで意味が変わる。コードをコピペするとき、「なぜこのエスケープが必要なのか」を理解していないと今回のようなバグになる。

3. 「見えない」問題は表示レイヤーだけとは限らない

CSS問題だと思い込むと、overflow、display、z-indexあたりを延々と触ることになる。実際の原因がJavaScriptのパースエラーだった今回のケースでは、ブラウザのDevToolsのConsoleタブを見れば一発でわかったはず。「見えない」→「なぜ見えないか」→「何が動いていないか」の順で調べるべき。

エージェントとのやりとりで気づいたこと

サヨンの「grokのクレジット切れならルーティングとかも止まってる可能性ありますね？」という一言が、調査の方向性を確認する良いチェックポイントになった。エンジニア的直感は重要で、エージェントが技術的な詳細を追っている間も、ビジネスオーナーの視点から「影響範囲はもっと広くない？」と問いかけることが全体像の把握に繋がる。

また、茶子のLP問題では「CSSでハマってる」という報告に対して、CSSではなくJavaScriptの問題だった。問題の自己診断を鵜呑みにせず、実際のコードを見ることの重要性を再確認した。

数字で見るS111