こせいです。

みなさんは、自分のブログにコードブロックを表示していますか？私は長年「表示しているつもり」でした。

しかし、最近になって恐ろしい事実に気づきました。

💡 ブログ開設からずっと、記事中のコードブロックが『透明人間』だったのです。

💡 ブログ開設からずっと、コードブロックが『透明人間』だった件

私はこの「こせいブログ」を開設して以来、ずっと記事中にコードブロックを埋め込んできました。なぜなら、実際に私が試したコードや設定を、読者のみなさんにもそのまま共有したかったからです。

しかし先日、ふと過去の記事を見返した時に、ある異変に気づきました。

記事中のコードブロックが、なぜか一切表示されていなかったのです。

シンタックスハイライトはおろか、ただのテキストすらありませんでした。表示されているのは、コードブロックの記述の直前と直後にあったはずの、通常の文章だけです。

初めは特定の記事の記述ミスかと思いました。

しかし、私のブログの全151ページを走査すると、恐ろしい事実が判明しました。<pre>タグを含むページが、1本も存在しなかったのです。

ブログ開設以来、コードブロックは一度も正しく描画されていなかった・・・ コードフェンスを含む公開記事6本すべてが、中身のない『透明人間』状態でした。この発見は、私に大きな衝撃を与えました。

🚨 開発ログ：まさか『戻り』が原因？泥沼にハマった4日間の記録

ブログ開設以来のバグは、4日間にわたる泥沼の修理戦記となりました。なぜなら、実際に私がコードや記事の変換ロジックを一つずつ追っていったからです。

この4日間で、私はいくつもの想定外の罠に直面しました。

最初の推測と誤算

最初の私の推測は「犯人は変換層」というものでした。これは半分正しかったのですが、具体的な箇所を特定するのに苦労しました。

私は過去の作業記録を参照し、文章整形スクリプトに起因する類似のバグを疑いました。しかし、そのスクリプトは同人ランキング記事専用で、私のブログからは呼ばれていなかったのです。

真因は往復変換の『3重の壊れ』

調査を進める中で、コードブロックが『透明人間』になっていた真犯人が判明しました。

それはMarkdown変換の「往復変換」、特に**「戻り」のプロセスに潜む3重の壊れ**でした。

Zukai: title=コードブロック崩壊の真因 | steps=格納ミス,言語破棄,戻りで破壊 | layout=flow

用途：コードブロックが壊れる3つの原因を示したフロー図

Prompt: Three abstract blue rounded rectangle modules connected by arrows in a left-to-right flow, representing a data processing pipeline. The first module is labeled "Storage Error", the second "Language Discard", and the third "Conversion Reversal Damage". The final output is an empty block, symbolizing data loss. Wide 16:9, clean modern flat illustration, minimal navy and soft blue palette on white background, generous whitespace. No people of any kind. Absolutely no text, no letters, no numbers, no Japanese characters, no logos.

具体的には、以下の3つの問題が重なって発生していました。

戻り（決定打）：Markdown解析の盲点

最も決定打となったのは、記事を表示する際の変換処理の問題です。コンテンツをマークダウンから中間表現、そして再びマークダウンに戻す際、ある変換ロジックが改行を含むコードをシングルバッククォート1組で囲んでしまっていました。

Markdownでは、コードスパン（インラインコード）よりもブロック構造（見出しなど）が優先的に解析されます。そのため、2行目以降のコード内の # コメント が、意図せずATX見出しとして解釈されてしまいました。

これにより段落が途中で切断され、コードブロックの囲みが対にならず、結果として生のバッククォートがそのまま表示されたり、何も表示されなくなったりしていたのです。

行き：アップローダーの格納ミスと情報破棄

次に、記事を投稿する際のアップローダーの問題です。アップローダーはコードフェンスの本文だけを「コード」とマークして格納していました。

しかし、この際に言語指定を破棄してしまっていたのです。これにより、複数行のコードを含むフェンス済みブロックと、短いインラインコードとがシステム内部で区別できなくなっていました。

行き：空行処理の優先順位

さらに、空行を処理するロジックも原因の一つでした。この空行処理が、コードフェンスを処理するロジックよりも先に実行されていたのです。

結果として、``` で囲まれたコードブロック内部の空行が、問答無用で捨てられていました。これは以前、ブログ内のテーブルが崩壊した時のバグと全く同じ型の問題でした。

知らぬ間に失われた情報が、後々の表示崩壊に繋がっていたのです。

⚠️ 自動ゲートの誤算：正しさを追い求めた結果、自分を止めた日

泥沼の調査と修正作業を経て、私はコードブロックの表示を検証するための新しい検査ゲートを設けました。なぜなら、実際にこのゲートがなければ、完璧に修正できたと確信することはできなかったからです。

しかし、このゲートが思わぬ落とし穴を教えてくれました。

私が1回目のデプロイを実行したとき、新設した検査ゲートはFAILを吐き出して、自分自身を止めたのです。

うわ、終わった。本番環境は無傷で済んだものの、私は自分の作ったゲートに阻まれました。

「せっかく作ったゲートが壊れているのか？」と絶望しました。

計測器の校正ミス

止まった2本の記事を詳しく調べてみると、ゲート側の誤判定が原因でした。

ゲートは```tableという、マークダウンの表の記法と、1行だけの短いコマンド（インラインコードとして描画されるべきもの）を、どちらも複数行のコードブロック、つまり<pre>タグ必須と誤認していたのです。

れ、0.001%・・・いや、これは正しい挙動を止める偽陽性です。

私はゲートツールを精密に修正し、再デプロイしました。すると今度は、無事にゲートを通過。

自分の作ったゲートが、正しく機能することを確認できました。

Zukai: title=検査ゲートの誤判定 | steps=デプロイ,ゲート停止,誤判定,ゲート修正,デプロイ成功 | layout=cycle

用途：検査ゲートが誤判定を起こし、自分自身を止めてしまう循環図

Prompt: A cycle diagram with five segments, illustrating a feedback loop. Each segment is a rounded rectangle connected by an arrow to the next. The segments are colored in a gradient from light blue to navy, representing the stages of a process. The first segment symbolizes "Deployment", the second "Gate Blockage", the third "False Positive", the fourth "Gate Correction", and the fifth "Successful Deployment". Centered composition, wide 16:9, clean modern flat illustration, minimal navy and soft blue palette on white background, generous whitespace. No people of any kind. Absolutely no text, no letters, no numbers, no Japanese characters, no logos.

✅ 真犯人逮捕：Markdown往復変換『戻り』の恐ろしい罠

この泥沼の4日間を通じて、私はMarkdownの往復変換における「戻り」の罠の恐ろしさを痛感しました。結論を言うと、表面的な実装だけでは見抜けない、システムの深部に潜む問題でした。

なぜなら、実際に私が「アップローダーのフェンス処理は実装済み」という既存の記述を信じ込んでいたからです。これは事実でしたが、問題は「戻り」の変換処理にあったのです。

行きだけ見て判断する危険性

共通ルールファイルには「アップローダーのフェンス処理は実装済み」という記録がありました。私はこの記録を見て、データの「行き」（アップロード時）の処理は問題ないと判断しました。

しかし、実際にはデータの「戻り」（表示時）の変換で、コードブロックが破壊されていたのです。これは非常に恐ろしいことです。

既存の品質ゲート（セキュリティスキャン、文章整形スクリプト、日常品質ゲートなど）が存在していても、新しい種類の壊れ方に対応できるとは限りません。何を見ているか、実際のコードで確認する重要性を改めて学びました。

中間表現に構造の種別を残すこと。見た目が似ていても意味が違うものを、同じ表現へ潰してしまわないことが重要でした。

Zukai: title=往復変換の危険 | steps=入力,中間表現,出力 | layout=compare

用途：Markdown往復変換における入力と出力のズレを比較する図

Prompt: A left-to-right comparison layout with two main blocks. The left block is titled "Input (Markdown)" and shows clean, structured code. The right block is titled "Output (Display)" and shows garbled or missing code. A central arrow indicates a transformation process. Wide 16:9, clean modern flat illustration, minimal navy and soft blue palette on white background, generous whitespace. No people of any kind. Absolutely no text, no letters, no numbers, no Japanese characters, no logos.

私は、この多重の壊れを修正しました。表示側では、旧データが複数行のコードを含む場合でも、正しくコードフェンスを付け直すロジックを実装しました。

また、新しい形式のデータはそのまま出力できるようにしました。アップローダー側では、フェンス記号ごとコードを格納するように変更。

これにより、言語指定と内部の空行が正しく保持されるようになりました。

🎉 解決の歓喜：ついにコードブロックがブログに現れた日

修正後のデプロイは、ついに成功しました。本番環境でコードブロックが正しく表示されているのをこの目で確認した時、私は心の中で叫びました。

ありがとうコードブロック！ありがとう検査ゲート！

これで、私のブログの記事は、やっと本来あるべき姿になったのです。

本番確認では、preタグが2件/4件（コードブロックが少ない記事で残りの2件はインラインコードだったため）で確認でき、裸のバッククォートも0、コメントが意図せず見出し化されている箇所も0でした。これは大きい。

📌 4日間の激闘が残した教訓：『測る側』と『ゲート』、そして『往復変換』の真実

この4日間の泥沼修理戦記は、私に多くの教訓を残しました。

特に重要なのは、「計測器の校正」に関する3つの掟です。

1. ゲートを作ったら、まず「壊れていないもの」に当てる

自動検査ゲートは、問題を発見するだけでなく、「問題がないもの」を正しく通過させるかどうかも重要です。作った直後に「壊れているものをFAILにするか」だけでなく、「壊れていないものをOKにするか」を必ず確認しなければなりません。

私の場合、コードブロック検査の初回デプロイが自分のゲートで止まり、調べたらゲート側の誤判定だったという実害がありました。

2. 検査は「壊れ方」ごとに要る

既存の品質ゲート（セキュリティスキャン、文章整形スクリプトなど）が存在していても、新しい種類の壊れ方に対応できるとは限りません。私の場合、リンク切れチェックスクリプトではレビュー消失を素通りしました。

また、複数の既存品質ゲートが、今回のコードブロック崩壊を全て素通りしていたのです。「ゲートがあるから大丈夫」と書かれた台帳を信用せず、何を見ているか、実際のコードで確認する必要があります。

知らないと、2,160円の損失・・・いや、それ以上の信頼損失に繋がります。

3. 往復変換は「戻り」でも壊れる

最も決定的な教訓は、データの「行き」（インプット側）の変換だけでなく、「戻り」（アウトプット側）の変換処理にも注意を払うべきだということです。台帳に「アップローダーのフェンス処理は実装済み」とあっても、それは行き側の話かもしれません。

行きだけ見て判断したことが、私が4日間も原因を特定できなかった理由でした。中間表現に構造の種別を残し、見た目が似ていても意味が違うものを、同じ表現へ潰してしまわない。

この原則を徹底しないと、意図しないバグが静かに潜伏し続けます。

👉 あなたのブログは大丈夫？『見えないバグ』を炙り出すための3つの行動

みなさんのブログは、本当に大丈夫でしょうか？私のように、知らぬ間に「透明人間」になってしまったコードブロックが潜んでいるかもしれません。

私の4日間の苦闘が、みなさんのブログ運営の参考になれば幸いです。

あなたの記事にコードブロックは正しく表示されていますか？シンタックスハイライトは効いていますか？

念のため、一度確認してみることをお勧めします。

そして、データ変換を行っているシステムがあれば、「行き」と「戻り」の両方の挙動を意識的に検証してみてください。今後、システムの問題解決に行き詰まった際、この記事で紹介した「計測器の校正」「ゲートの検証」といったアプローチを試してみましょう。

見えないバグを炙り出し、より堅牢なシステムを構築するためのヒントになれば嬉しいです。

こういう見えないバグとの格闘や、AI運用の実験ログは、ニュースレターでも配信しています。

記事にする前の生の試行錯誤が読みたい方は、こちらからどうぞ。

https://koseiblogai.substack.com