AIとブログを量産していたら、たった1文字のせいで表示が崩れた話

記事を効率よく量産するために、生成AIとスクリプトを組み合わせた仕組みを作っていました。ある日公開した記事を見た読者から「商品カードがバグってます」の一言。原因を辿ると、驚くほど小さな1文字の違いでした。

同じフォーマットの記事を何本も作るとき、1本ずつ手で書いていては時間がいくらあっても足りません。そこで、記事のテンプレートと商品データを分けておき、スクリプトに組み立てさせる仕組みを使っていました。今回はその仕組みの中で実際に起きた不具合と、見つかるまでの経緯、そしてそこから得た教訓を、できるだけ噛み砕いてまとめてみます。

1. そもそも、なぜ「量産する仕組み」を作ったのか

きっかけは単純で、似たような構成の記事を何十本も作る必要が出てきたことでした。見出しの位置、価格やスペックを並べる表、商品ごとのメリット・デメリット、よくある質問コーナー──こうした「型」が決まっている記事は、1本ずつ手作業で組み立てるより、共通の骨組みを1つ作り、中身のデータだけを差し替えていく方が圧倒的に速く、しかも体裁もそろいます。

この方法自体は、ブログに限らずカタログサイトやニュースサイトでも広く使われている、ごく一般的なやり方です。問題は「型」そのものではなく、型に中身を流し込む「組み立て方」の部分に潜んでいました。

2. 「動いているように見える」が一番危ない

不具合が起きたのは、4つの商品カードを1つの記事にまとめて組み込む処理でした。カードのHTML部品を1つずつ作る関数を呼び出し、それを4回分つなげて記事本文に差し込む、という単純な処理です。

ところが、4つの部品を「連結」するつもりが、実際には「並べただけ」になっていました。プログラムの世界では、文字列同士をつなげる書き方と、複数の値をひとまとめの塊として扱う書き方が、見た目にはほんの数文字しか変わりません。今回は、その数文字の違いに気づかないまま処理が最後まで動いてしまいました。

厄介なのは、この間違いをしていても、プログラムがエラーで止まってくれるわけではないという点です。「文字列をつなげる」書き方も「複数の値をまとめて扱う」書き方も、どちらもプログラムとしては正しい文法です。コンピューターから見れば「どちらのやり方で処理しますか？」という指示の違いでしかなく、「これは間違いです」とは教えてくれません。人間が期待していた結果と、実際に指示した内容がズレていただけなのです。

3. 出力されたのは「中身」ではなく「入れ物の説明書き」だった

本来であれば、4つの商品カードのHTMLがそのままつながって記事に埋め込まれるはずでした。しかし実際にファイルに書き出されたのは、4つの部品を「ひとまとめの塊」として扱った際の、内部的な表記そのものでした。

たとえるなら、4枚の写真をアルバムに1枚ずつ順番に貼っていくつもりが、誤って「写真4枚をまとめて入れた箱」を、箱ごとアルバムのページにそのまま置いてしまったようなイメージです。箱の中の写真自体はちゃんと存在しているのに、見た目には「箱」という余計な入れ物と、その中身を説明するラベルまでもがページの上に出てきてしまう。今回のバグは、まさにこの「箱」と「ラベル」が記事のテキストとして紛れ込んでしまった状態でした。

結果として、ブラウザで記事を開くと、本来は見えないはずの記号や区切り文字がテキストとして画面に表示され、商品名の途中に妙な改行やカンマが挟まる、という奇妙な見た目になっていました。プログラムはエラーで止まることなく、最後まで正常に処理を終えていたため、生成の段階では異常に気づけませんでした。

4. 見つけてくれたのは自動テストではなく「人の目」

実は、記事を公開する前に自動化されたチェックも一通り走らせていました。カードの数が正しいか、リンクが正しく設定されているか、ページが表示されるか──そうした項目はすべて「問題なし」と判定されていました。

ですが、そのチェックは「決められた場所に、決められた数の要素があるか」までしか見ておらず、「中の文章が正しい日本語になっているか」までは検証していませんでした。皮肉なことに、崩れた表記の中にもカードらしき枠組みの記号は含まれていたため、機械的なチェックはすり抜けてしまったのです。最終的に不具合を見つけてくれたのは、実際に画面を見た読者からの一言でした。

5. 原因を特定するまでの3ステップ

「バグってます」という報告だけでは、どこに原因があるのかはまだ分かりません。実際に原因にたどり着くまでは、次のような順番で切り分けを行いました。

• Step1：実際の画面を見る — まずは思い込みを捨てて、報告のあったページを開き、どこがどうおかしいのかをそのまま観察する
• Step2：見えている記号から逆算する — 画面に表示されていた記号やカンマの並び方から、「これはプログラム内部の表記がそのまま漏れているのでは」と当たりをつける
• Step3：生成元のファイルを直接確認する — 実際に書き出されたファイルの中身を開き、想定していた見た目と実際の中身にズレがないかを1行ずつ照合する

この3ステップの中でも、特に効いたのは最初の「思い込みを捨てて画面をそのまま見る」ことでした。「きっとリンクの設定ミスだろう」「画像が読み込めていないのかも」と原因を先に決めつけてしまうと、目の前に答えが出ていても見逃しやすくなります。今回も、変わった記号の並び方をよく観察したことが、遠回りせずに原因へたどり着く近道になりました。

6. 直してから、もう一度やったこと

原因が分かってからの修正自体は、それほど時間がかかるものではありませんでした。むしろ時間をかけたのは、直したあとの確認作業です。今回は次の3点を必ず行うようにしました。

• 修正した仕組みで、影響を受けていた記事すべてを作り直す
• 作り直した記事のファイルを直接開き、おかしな記号が残っていないかを目視で確認する
• 実際にブラウザで表示し、スマホ画面のサイズでも見た目が崩れていないかを確認する

「直したはずなのに、実は一部だけ直っていなかった」という事態を避けるため、修正前と同じ条件で、もう一度最初から確認をやり直すことを徹底しました。急いでいるときほど「たぶん直っているはず」で済ませたくなりますが、そこを一手間かけるかどうかが、次の思わぬトラブルを防げるかどうかの分かれ目になる気がしています。

7. 「量産」と「確認」はセットでしか意味がない

効率化のためにAIやスクリプトへ作業を任せることは、うまくいけば大きな時短になります。ただ今回の件で改めて感じたのは、量産のスピードを上げるほど、最後に人の目で確認する工程の価値も比例して上がるということでした。

1本の記事を作るだけなら、多少の見落としは書いている途中で自然と気づけます。ですが「同じ仕組みで10本、20本と一気に作る」場合、その仕組みに紛れ込んだ小さな間違いは、1本分ではなく作った本数分だけ、一気に同じ形で複製されてしまいます。量産は効率を生む一方で、ミスもまとめて量産してしまうという、当たり前だけれど見落としがちな一面があります。

自動化は「作る速さ」を上げてくれるが、「正しさ」までは保証してくれない。最後の答え合わせは、結局のところ人の役割です。

幸い今回は表示が崩れるだけの不具合で、実害はテキストの見た目のみでした。それでも、こうした小さなズレは積み重なると気づかれにくくなります。修正後は同じ確認作業をもう一度やり直し、想定通りの見た目になっていることを確かめてから公開し直しました。

8. AIやスクリプトに任せる部分、任せない部分

今回のことがあってから、作業を任せる範囲について少し考え方を整理しました。文章のたたき台づくりや、同じ形式のパーツを大量に組み立てる作業は、AIやスクリプトに任せるとかなりの時短になります。一方で「本当に想定通りの見た目・結果になっているか」の最終確認だけは、どれだけ量が多くても人の目を通すようにしています。

• 任せて良い：文章のたたき台、定型フォーマットへの当てはめ、繰り返し作業
• 任せきりにしない：最終的な見た目の確認、公開前のチェック、想定外の入力への対応

「任せる／任せない」の線引きは、作業の種類だけでなく、間違えたときの影響範囲でも決めるとよさそうです。今回のように「同じ仕組みで何本も作る」作業ほど、1箇所の間違いが広範囲に広がりやすいため、最後の確認だけは省略しない、というのが今回得た一番の実感です。

まとめ

「動いた」と「正しく動いた」の間には、思っているより大きな差があります。効率化の仕組みを作るときほど、最後に人の目で確認する一手間を惜しまないこと。今回のちょっとしたトラブルは、そのことを再確認する良い機会になりました。次に同じような仕組みを作るときは、量産する数が増えるほど、確認の手間も一緒に増やしていこうと思います。