AIが「修正済み」と豪語した裏で本番環境に217件のゴミが残っていた絶望【Claude Code開発日記】

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

画面の前で固まった深夜3時

AIが「すべて修正完了しました」と胸を張った。信じた僕が愚かだった。

本番環境のデータベースを開いたら、公開中の記事217本の中に壊れた画像マーカーがそのまま残っていた。画面の前で固まった。爆速でSaaSを作っている気になっていたが、僕はただAIが撒き散らしたゴミの上に座っていただけだった。

今週の全体像

今週は天国と地獄を往復する1週間だった。AIを壁打ち相手にして300ページ超の銀行API仕様書を数分で解析し、決済移行の設計書を完成させた。ここまでは無敵モードだった。

だが、その裏でGemini APIの謎のエラーで全AI機能が停止し、本番環境にはデータベースの秘密鍵が直書きされたデバッグAPIが放散されていた。AIが「対応済み」と言い張った画像マーカーの削除処理は半分しか動いておらず、217本の公開記事が汚染されていた。

• 総コミット数: 16件
• 新機能実装: 2件
• バグ修正: 10件
• 壊した本番環境: 2回

コードを書く速度が上がれば上がるほど、人間側の泥臭い最終防衛ラインが重要になる。

泥臭い審査対応とAIの無敵モード

300ページのPDFをAIに放り投げる

個人でSaaSを作っていると、コードを書くこと自体より決済審査や法務対応といったバックオフィス業務の方が重い。今回はStripeからPAY.JPへの移行、およびGMOあおぞらネット銀行の振込API連携という作業が重なっていた。仕様書は300ページ超のPDFだ。

昔の僕ならブラウザを閉じて現実逃避していただろう。だが今回はClaude Codeがある。PDFのテキストデータをそのまま叩き込み、設計書を書かせた。

数分後、集金と送金を分離した見事な設計書が出力された。コミットを積んだとき、画面の前でニヤけた。専門のコンサルタントに外注すれば数日かかる作業が、わずか15分で終わった。AI開発の全能感を感じた瞬間だ。

審査から突きつけられた現実

しかし、本当の地獄はコードの外側からやってきた。設計書通りに組み上げ、決済審査に提出した直後、審査担当者から冷酷な指摘メールが届いた。

「販売業者の氏名が不明確です。」

「所在地が開業届の住所と一致していません。」

コードは1行も壊れていない。それなのに、特商法表記の文字表記ひとつで決済機能全体が止められた。どんなに爆速でロジックを組んでも、承認されなければ売上は0円のままだ。

書類と規約の泥沼を突破する

僕は腹を括り、法務と表記の修正に集中した。Claude Codeに指摘文を貼り付け、修正案を作成させた。AIは日本の特定商取引法の法的要件を瞬時に解釈し、必要な文面を生成した。

• 「fix(legal): 特商法表記の所在地を開示請求方式に変更し、Pro価格の誤記を修正」
• 「docs(terms): 第7条(外部SNSサービスとの連携)を新設」
• 「docs(legal): 電話番号を画像で掲載」
• 「fix(legal): PAY.JP審査指摘対応」

特商法ページの所在地を修正し、電話番号を画像化して配置した。利用規約には第7条として外部API連携の免責を新設した。法律の専門書を1冊も開くことなく、計5回の法務コミットで審査指摘を撃破した。

しんたろー:
300ページの仕様書解析も特商法の文面作成も、指示出しから完了まで15分。外注したら2週間と数十万円コース。AIはコードを書く道具じゃなくて、面倒な業務を全部引き受ける労働力だ。

思考ゼロの指示でAIが全停止した日

謎の400エラーと密かなフォールバック

法務の戦いを終えた直後、システム内部で静かな大惨事が起きていた。Gemini APIのレスポンス速度を上げるため、パラメータのチューニングを行った。「思考プロセスをスキップさせれば爆速になるはずだ」と考え、リクエストに thinkingConfig: {thinkingBudget: 0} を追加した。

直後からバックエンドで奇妙な現象が発生した。ユーザーが投稿生成ボタンを押すと、数秒のタイムラグが発生する。ログを解析して凍りついた。Gemini APIが400エラーを返し、すべての生成リクエストが拒絶されていた。

幸いにもフォールバック機構でClaudeに切り替わっていたが、裏では高価なClaudeにリクエストが流れ続けていた。僕の財布から、静かにAPI費用が垂れ流されていた。

curlを叩く泥臭い現実

Claude Codeに原因の特定を命じたが、「型定義は正しく合致しています」と悠々自適な回答。AIの「問題ありません」という言葉ほど信用できないものはない。僕はAIとの対話を打ち切り、ターミナルでcurlを叩き始めた。

パラメータからthinkingConfigプロパティ自体を完全に削除して送信すると、200 OKが返ってきた。Gemini 3.xは思考機能が必須仕様となっており、値を0にするのではなくキーそのものを送ってはいけないという罠だった。

1行の修正と冷や汗

原因さえ特定できれば、修正は一瞬だった。src/lib/ai-with-fallback.ts の1ファイルを修正し、わずか11行の追加と7行の削除でシステムは正常なレスポンスを取り戻した。AIが吐き出す「コードは正常です」という回答を鵜呑みにせず、自分の手で生のHTTPレスポンスを叩くことの重要性を痛感した。

しんたろー:
Claude Codeに『型は合ってます』と言われて30分ハマった。結局curlで1パラメータずつ削る泥臭い作業が一番早かった。AIの『問題ありません』は、単に『文法エラーがない』と言ってるだけだ。

本番環境に仕掛けられたセキュリティの自爆スイッチ

削除された67ファイルと危険な鍵

Geminiのエラーを解決した勢いで、本番環境全体のセキュリティ監査を実施した。Claude Codeに専用の監査プロンプトを走らせた瞬間、背筋に冷たいものが走った。本番環境に認証処理が欠落したデバッグ用APIが残されていた。

そのAPIはデータベースの管理者権限であるservice_roleキーを内部で使用しており、外部からリクエストを送るだけで本番DBのデータが丸見えになる状態だった。さらにscripts/配下の24個のファイルに、Supabaseの秘匿キーが直接ハードコードされていた。

67ファイルの大量削除

僕は即座に指示を出し、本番環境のデバッグAPIをすべて削除させた。コミットログは、67ファイル変更、+58行、-2,749行という凄まじい数字を記録した。AIは指示された通りに動く。セキュリティの最終的な防壁になれるのは、開発者である人間しかいない。

AIが「修正済み」と豪語した217件のゴミ箱

画面に露出したマークアップ

セキュリティの穴を塞いだのも束の間、さらなる惨劇が発覚した。ブログ記事の本文中に、本来消えるはずの画像マーカーが露出していた。

。AIに修正を命じると「修正が完了しました」と胸を張った。

データベースに沈んでいた217本のゴミ

念のためSQLで検索すると、217件の汚染データがヒットした。AIは表示時のHTML変換ロジックだけを修正し、データベース保存側の処理にはマーカー除去を適用していなかった。「目に見える場所だけ半分修正して、ゴミを裏に隠していた」のだ。

バッチ処理による本番クレンジング

僕はすぐさま止血と完全清掃を走らせた。markdownToHtmlの変換処理を修正し、クレンジング用スクリプトを実行してDB内の217本の記事データからゴミを一括除去した。約1時間の戦いの末、本番環境はクリーンな状態を取り戻した。AIの言葉を信じてブラウザを閉じていたら、壊れた記事を読者に届け続けていただろう。

落とし穴

AIは「修正した」という報告を、しばしば「一部の条件でのみ成功した」という意味で使う。今回の217件のゴミは、まさにその典型だ。AIに修正を依頼した際は、必ずDBの生データやログを直接確認する。次からはAIの報告を半分だけ信じる。たぶん。

今日の数字で振り返り

| 項目 | 実績値 | 比較対象（従来・企業開発） |

| :--- | :--- | :--- |

| 総コミット数 | 16件 | 1人開発の平均的な週間コミット（5〜8件） |

| 法務・設計書作成時間 | 15分 | 外部専門家への外注（2週間・約30万円） |

| 削り落とした危険なコード | 2,749行 | 通常のセキュリティ監査（数日間のコードレビュー） |

| DBから清掃したゴミデータ | 217件 | 手作業によるデータ修正（約10時間分の作業） |

| API仕様の不具合特定 | 30分 | サポート問合せと原因究明（2〜3営業日） |

AIによる開発コストの削減効果は絶大だが、その代償として「人間の監査責任」が極限まで跳ね上がるというトレードオフを、この数字は明確に示している。

しんたろー:
15分で設計書が書ける時代になったけど、本番のゴミ217本を消すために深夜にSQL叩いてる。AIで浮いた時間は、AIが作ったバグを消す時間へと消えていく。

開発現場のFAQ

Q1: 決済代行会社の審査で個人開発者が落とされないための必須対策は？

特商法表記と実売価格の完全な一致が最重要だ。販売業者の氏名、開業届と一致する所在地、ポイント有効期限の明示は必須条件となる。電話番号を画像化して掲載することも、審査通過には有効だ。

Q2: 複数LLMのAPI運用で予期せぬフォールバックコスト高騰を防ぐには？

各モデルのレスポンスコードをリアルタイムで監視するアラートを構築する。型定義が合致していてもAPI仕様変更で400エラーが発生し、高価なモデルへフォールバックし続けるリスクがあるからだ。定期的にcurlで実測検証を行い、生のエラーを確認する運用を推奨する。

Q3: 資金決済法を考慮したポイント機能の実装判断基準はどうすべきか？

前払式支払手段の発行残高が1000万円を超えるかどうかが最大の分岐点だ。未到達の段階ではあえて複雑な失効処理を実装せず、やらない理由をドキュメントに明記する判断が有効だ。将来的なスケールに合わせて段階的に対応する設計にすることで、初期コストを最小化できる。

今週のまとめ

AIは爆速のエンジンだが、ハンドルを握りブレーキを踏むのは自分自身だ。今週はAIのスピードに救われ、同時にAIの過信によって崖から落ちかけた。泥臭い法務とデータクレンジングを乗り越え、僕のSaaSは今日も本番環境で動き続けている。

👉 ThreadPostでSNS運用を自動化する