公開記事に社内の符丁が紛れていた話

符丁が漏れていた。

公開済みの記事に、読者には意味の分からない英数字が紛れていました。社内でしか通じない符丁です。慌てて修正しましたが、安心したのも束の間、別の記事でも同じ種類のノイズが見つかりました。

最初の修正は、ある技術解説記事に紛れ込んでいた社内コード名を1ファイルだけ書き換えるという、ごく小さな対応でした。ところがその後、公開済みの別の2つの記事からも、開発の変更履歴を示す識別子がまとめて見つかり、除去する事態になりました。一度直したはずの問題が、形を変えて別の場所から出てくる。これは単なる見落としではなく、仕組みそのものに穴があるサインでした。

なぜ人の目では止められないのか

なぜ同じ種類のミスが繰り返されたのか。答えは単純で、内部識別子は書き手にとって「異物」に見えないからです。

開発の現場では、コミットの履歴や社内的な呼び名は日常的に目にする情報です。文章を書く側にとっては見慣れた記号であり、あえて説明を加えたくなるほど自然に手が動いてしまいます。レビューする側も同様で、意味のある技術用語と、読者にとって無意味なノイズの境界は、慣れた人ほど気づきにくいものです。むしろ「知っている人には分かる情報」だからこそ、チェックの網をすり抜けてしまう。

これは特定の担当者の注意力不足ではなく、構造的な問題です。人が「気をつける」ことに依存している限り、同じ種類の見落としは形を変えて必ず再発します。実際に、1件修正した直後にもう1件、さらに複数件と、断続的に同種の事故が続いたことがそれを裏付けていました。

4つの関門で通さない仕組みに変えた

そこで発想を転換しました。「気をつける」という運用ではなく、「通せない」という仕組みに置き換えることです。

具体的には、文章が世に出るまでの流れを、生成・批評・機械的な文法チェック・最終承認という4つの段階に分解し、それぞれの段階に内部識別子を検出して拒否するルールを組み込みました。10ファイル規模の改修を行い、どこか1つの関門を通り抜けても、次の関門で必ず引っかかる構成にしています。

ポイントは、対策を「最後のチェック」だけに集約しなかったことです。人の目に頼る最終確認だけを強化しても、文章が生成される最初の段階で紛れ込んだ識別子は、その後の工程でも「もともとそこにあったもの」として自然に見過ごされがちです。生成の時点、批評の時点、機械的な検査の時点、そして承認の時点と、性質の異なる4つのフィルターを重ねることで、どこか一つに死角があっても他の三つが機能する構造にしました。

個別対応から、内部名称全般を止めるルールへ

この4段階の仕組みを作った際、対象をコミット履歴の識別子だけに絞りませんでした。もう一段広げて、読者が検索しても辿り着けない社内的なコード名やスラッグ全般を対象にする判断をしています。

この拡張には理由があります。最初の事故はコミット履歴の識別子でしたが、根本原因は「読者にとって意味を持たない内部情報が、書き手にとっては自然な言葉として出力される」という構造そのものにありました。だとすれば、対象をコミット履歴だけに限定しても、次は別種の内部名称で同じ事故が起きるだけです。実際、同程度の規模の改修を通じて、禁止するルールの範囲をコミット履歴の識別子から、読者に無意味な内部名称全般へと一般化しました。

個別の事象に個別のパッチを当てるのではなく、事象の背後にある共通の性質を見極めて、ルールを一段抽象化する。これは技術的な対策の話であると同時に、再発防止の考え方そのものの話でもあります。

属人的な注意力に頼る運用への問い

ここまでの話は、私たちの記事制作に限った話ではありません。多くの中小企業でも、社内資料や顧客向けの文書、ウェブサイトの更新作業などで、似た構造のリスクを抱えているのではないでしょうか。

担当者が「気をつけて」チェックする運用は、性善説にも属人的な注意力にも依存しています。担当者が変われば注意の質も変わりますし、忙しい時期には見落としも増えます。重要なのは、個人の注意力を責めることではなく、情報が生まれてから世に出るまでの流れのどこに、機械的に検出して止める仕組みを置けるかを考えることです。

公開前の確認を1回強化するだけでは足りません。情報が作られる最初の地点から、世に出る最後の地点まで、性質の異なる複数の関門を重ねて初めて、同じ事故の再発を封じることができます。自社の情報発信の流れの中に、そうした多重の関門があるかどうか、一度点検してみる価値はあるはずです。