AIが生成した図解の文字がすべて豆腐化。Claude Codeの盲点に絶望した3日間

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

生成された画像を開いた瞬間、思考が停止した。そこにあったのは、美しいグラフではなく、画面いっぱいに並んだ白い四角「□」の群れだった。AIは文字化けした画像を前に「図解の生成が正常に完了しました」と自信満々に報告してくる。AIには出力した画像の『視覚的な結果』が見えていない。その恐ろしい盲点に気づいた瞬間、背筋に冷や汗が走った。

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

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

無料で始める

AI開発で直面した光と影の全貌

今週は天国と地獄を往復する3日間だった。AIを使った爆速開発で、わずか数日で162本分のSEO記事基盤と、自動図解システムを立ち上げた。しかしその裏で、AIの「サイレント失敗」や「いい加減な数値計算」に何度も足をすくわれた。

1人開発でAIを相棒にするとき、人間が担うべき役割はコードを書く作業ではない。AIが差し出してきた成果物を徹底的に疑い、安全と品質の境界線を引くことだ。

今週の動きをまとめた数値サマリーだ。

総コミット数: 30件
新機能実装: 4件（マルチ投稿ラッパー、図解ベクターパス化、SEOテンプレート基盤など）
バグ修正: 6件（文字化け、リダイレクトホール、分析コレクター停止など）
作成・変更ファイル数: 92ファイル
追加・削除行数: +9,280行 / -263行

AIは圧倒的なスピードでコードを吐き出すが、その成果物が本番環境でどう振る舞うかまでは責任を持ってくれない。僕が体験したリアルな格闘の記録を共有する。

162本のSEO設計をAIと完遂した裏にあった「カニバリ」の罠

1人SEOマーケティングの限界をAIで突破する試み

僕は運営するサービス周辺で162本に及ぶ大型SEO記事群を一気に構築しようと計画した。通常、100本を超えるトピッククラスター設計は専門チームが何週間もかける作業だ。1人開発者がこれを行うのは物理的に不可能に思える。

そこで僕は、Claude Codeに競合の上位表示データを食わせ、キーワード分類から記事構成案作成までをすべて任せた。AIに指示を投げると、数秒で膨大な見出し案が画面を埋め尽くした。「全162本のカニバリ検査が完了しました。重複はゼロです」。AIはそう言った。従来のマーケティングチームが1ヶ月かける作業を、たったの数分で終わらせたように見えた。

ドヤ顔のAIが吐き出した構成案を手動で突合した恐怖

しかし、あまりの速さに違和感を覚えた僕は、生成された構成案から用語集30本とQ&A記事50本を抜き出し、手動でマトリクス表を組んで突き合わせてみた。ぞっとした。キーワードの完全重複がいくつも見つかったのだ。例えば「NAP情報とは」という記事と「NAP情報を整える手順」という記事で、狙うべき検索クエリが完全に被っていた。

AIは「共通テンプレート」を適用して記事を量産する際、文脈の重複を「効率化」として処理していたのだ。SEOにおいて、自社サイト内で同じ検索意図を持つページが複数存在することは致命的なリスクとなる。これがキーワードカニバリゼーションだ。検索エンジンはどちらのページを評価すべきか判断できず、サイト全体の評価が共倒れになる。AIは表面的な差分だけで「重複なし」と判定していた。

テンプレートと境界線設計によるカニバリの根絶

AIの言動を信じるのを即座にやめ、機械的な突合スクリプトを組んで重複するタイトルとIDを炙り出した。コミット「docs(yobikomi): 残り52本のタイトルを確定し、全162本のカニバリ検査を完了」では、Google Ads APIから取得した実測データを直接流し込み、検索ボリュームに基づく機械判定を実施した。その結果、タイトルが完全一致していた3組を検出し、即座に削除・再割り振りを実行した。

さらに、AIが書き分けに失敗しないよう、厳格な役割分担のルールを定めた共通テンプレートを構築した。用語集は「定義」に特化し、解説記事は「手順」に特化する。Q&Aは「悩み解消」に特化し、マネーページへ誘引する。コミット「docs(yobikomi): 用語集30本の共通テンプレート」や「docs(yobikomi): Q&A50本の共通テンプレート」を投入したことで、AIの思考の脱線を防ぐ枠組みが完成した。

しんたろー:
「カニバリゼロです！」ってAIが言ってきたとき、一瞬信じかけた自分が怖すぎる。手動で突合したら被りまくり。AIに大量のコンテンツを作らせるときは、文章を書かせる前に「ここから先はみ出すな」という領域の境界線を人間がコードで縛らないと確実に事故る。

サーバー上で文字がすべて豆腐化。画像レンダリングの盲点

「完成しました」の裏に隠された白紙と□の群れ

SEO基盤の設計と並行して、記事内に挿入するインフォグラフィックを自動生成するパイプラインの開発を進めていた。記事の文脈に合わせてSVGを動的生成し、それを画像処理ライブラリである「Sharp」でPNGに変換して保存する仕組みだ。Claude Codeに実装を命じ、ローカル環境（macOS）でテストを回した。

「図解画像の生成と保存処理が正常に終了しました」。吐き出されたログにはエラーが1つも出ていない。成功したと思って生成されたPNGファイルを開いた僕は、思わず言葉を失った。画像の中央に配置された枠線の中に、日本語の文字が一言も入っていなかった。代わりに、小さな四角い記号「□」が整然と並んでいた。AIは「コードが例外を投げずに最後まで実行されたこと」を確認して「成功」と報告していたのだ。しかし、生成された画像の中身が読める状態になっているかどうかまでは、AIには見えていなかった。

なぜVercel上のLinuxコンテナで日本語が化けるのか

問題の原因は、クラウドインフラと画像変換ライブラリの仕様にあった。サーバーサイドでSVGをPNGにラスタライズする際、「Sharp」はSVG内に指定されたフォントを、実行環境のOSにインストールされているシステムフォントから探して描画する。僕のローカル環境には日本語フォントが入っていたため、テスト時には綺麗に表示されていた。

しかし、本番環境であるVercelのLinuxコンテナには、日本語フォントが1つもインストールされていない。コミット「fix(infographic): 図解PNGの日本語文字化けを修正(フォント埋め込み)」を打ち、日本語フォントファイルを直接プロジェクト内に配置した。しかし、Vercelのサーバーレス環境ではライブラリがSVG内の指定を正しく解釈できず、@font-faceで指定したdata: URIのフォントを無視してしまう現象が発生した。生成されたPNGのファイルサイズはわずか1,364バイト。ほぼ真っ白な透明画像が出力され続けていた。

テキストのベクターパス化による完全防衛

OSのフォント環境やライブラリのパース挙動に頼っている限り、この問題は再発する。そこで僕は、SVG内のテキスト要素を、画像描画前に文字の輪郭データ（ベクターパス）へ直接変換するアプローチへ切り替えた。コミット「fix(infographic): 文字をベクターパス化してPNGの豆腐を根絶」の変更内容がこれだ。

「opentype.js」を用いてサーバー上でフォントファイルのグリフを直接読み込み、文字列をSVGのパスデータに変換してからSharpへ渡す仕組みを構築した。文字を「テキストデータ」ではなく「図形データ」として埋め込むことで、サーバー側にフォントが存在するかどうかに関わらず、絶対に文字化けしない完璧な画像生成パイプラインが完成した。さらに、コミット「test(infographic): 図解PNGの日本語描画テストを追加」を追加し、自動テストを組み込んだ。

しんたろー:
AIはコードが動いたかどうかは教えてくれるけど、画面に何が映っているかは教えてくれない。「できました」というAIの言葉を真に受けて本番にデプロイしてたら、読者全員に豆腐の画像を配り続けるところだった。視覚的なアウトプットを出す機能は、人間が泥臭く自分の目で確認するしかない。

AIが自ら作った「フィッシング詐欺」の踏み台

AI開発において最も恐ろしいのは、機能が動いているように見えて、裏で致命的なセキュリティホールが放置されているケースだ。今週、僕はあやうく自社サービスを攻撃者の踏み台にされるところだった。メルマガやSNS配信の機能を拡張するため、ユーザーがリンクをクリックした際に計測を行うエンドポイントのリダイレクト処理をClaude Codeに実装させた。

「外部サイトへのリダイレクト処理とクリックログの記録機能を実装しました」。AIは綺麗なTypeScriptコードを書いて提出してきた。テスト環境でリンクを踏むと、正しく目的のページに遷移する。しかし、コードの中身を一行ずつ追っていた僕は、血の気が引くのを感じた。パラメータで渡されたURL文字列を、何の検証もせずにそのままレスポンスの「302 Redirect」に流し込む構造になっていたのだ。いわゆるオープンリダイレクト脆弱性である。

僕が「これだと外部の悪質サイトに自由に飛ばされるぞ。ドメインの制限をかけろ」とAIにツッコミを入れた。するとAIは「修正しました」と返してきたが、追加されたコードはただの文字列部分一致チェック（url.includes(「threadpost.jp」)）だった。これでは、攻撃者が「evil-threadpost.jp.com」のようなドメインを用意すれば簡単に突破できてしまう。AIはセキュリティの概念を「仕様を満たすための記号合わせ」としか捉えていなかった。

コミット「fix(security): track/click と track/external のオープンリダイレクトを封鎖」を緊急打電した。厳格なURLパーサーを自作し、プロトコルをhttpsに限定した上で、あらかじめ許可されたドメインのホワイトリストと完全一致しない限り、強制的にトップページへフォールバックさせるロジックを組み込んだ。1人SaaSにおいて、ドメインの信用失墜は即死を意味する。AIにセキュリティの「配慮」を期待してはいけないと心に刻んだ。

ここまで読んだあなたに

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

無料で始める

落とし穴

AIが提示する「都合の良いシミュレーション」をそのまま事業計画に組み込んでいたら、来年のはじめに資金ショートを起こして死んでいたはずだ。当初、AIを使って弾き出した損益分岐の到達期間は「8.3ヶ月」だった。しかし、実際のオーガニック検索の立ち上がりラグや、定期課金の解約率を数式に組み込み直したところ、実際の到達時期は17〜18ヶ月まで伸びることが判明した。コミット「fix(yobikomi): 到達時期8.3ヶ月は誤り。立ち上がりを織り込むと17-18ヶ月」にて、この数式を厳密に修正した。AIが出してきた数値データは、自分で数式を分解して裏を取るまで絶対に信用してはいけない。

開発を数字で振り返る

項目	今週の実績	比較対象・従来の基準	差分・インパクト
SEO設計完了数	162本	従来の手動設計：約3〜4週間	わずか2日で全設計書を完工
自動生成された試作数	21パターン	手動プロトタイピング：半日で2〜3個	v1〜v21まで一気に比較検証
SEO事業の黒字化予測	17〜18ヶ月	AIの初期シミュレーション：8.3ヶ月	1.08倍の現実的な数値へ修正
画像描画エラー率	0%（対策後）	対策前：Vercel上で100%豆腐化	ベクターパス化でOS依存を完全脱却
セキュリティホール	0件（即時塞ぎ）	放置した場合：即座にドメインブラックリスト入り	安全なリダイレクト検証ロジックを共通化

しんたろー:
162本の設計を2日で終わらせたのはAIの凄さだけど、その裏で「8.3ヶ月で黒字化できますよ」というAIの甘言を真に受けてたら来年死んでた。AIが出してきた数値データは、自分で数式を分解して裏を取るまで絶対に信用しちゃダメだ。

AI開発の現場で直面する疑問へのリアル回答

Q1: AIが「正常に完了した」と報告してきたコードでサイレント失敗を防ぐには？

コードの戻り値だけでなく、生成されたデータそのものを検証するアサーションをパイプラインに組み込む。例えば画像生成なら、ファイルサイズが極端に小さいケースや透明度の割合が異常なケースを検知して例外を投げる。AIの言葉ではなく、データベースのレコードや出力ファイルのバイト数を機械的に監視する。

Q2: サーバー環境の違いによる「文字化け（豆腐化）」をコードで根本解決する方法は？

OSのシステムフォントに依存する処理を排出し、フォントファイルをプロジェクト内に同梱した上で、描画処理時にベクターパス化を行う。Node.js環境なら「opentype.js」を使用してSVG内のテキストをパスデータへ変換する。これにより、フォントが存在しないLinuxコンテナ環境でも100%環境に依存しない描画が可能になる。

Q3: AIに損益計算や事業シミュレーションを行わせる際の注意点は？

AIはもっともらしい計算結果を出すのが得意だが、立ち上がり期間のラグや解約率の減衰といった現実的な制約条件を漏らす傾向がある。AIの出力はそのまま使わず、計算式のロジックを分解させて出力させる。その上で、人間が最悪のシナリオを反映させた再計算を行うことが必須だ。

泥臭い手作業の先にしか、動くSaaSは存在しない

AI開発を始めてから、開発のスピードは間違いなく数倍に跳ね上がった。しかし、AIがどれだけ賢くなっても、画面の向こうで文字が化けていることに気づくのも、セキュリティホールの恐ろしさに身震いするのも、最後は僕たち人間の仕事だ。AIを道具として使い倒しながら、最後の責任は自分の手で取る。この泥臭いバランス感こそが、1人開発を成功させるための唯一の道だ。

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