「コピーが効かない」の一報から、壊れていた13箇所が見つかった — 中小企業 × AI 経営（2026年8月）

何かが故障していることに、誰も気づかないまま何日も過ぎていた——そんな経験はありませんか。警告ランプも鳴りません、大きな音もしません。壊れる前と、見た目はまったく同じまま動き続けます。気づくきっかけは、たいてい「あれ、これ動いてます?」という誰かのひと言だけです。

私たちのWebサービスにも、これとよく似た壊れ方が13箇所も見つかりました。しかも、機械的な検査は一通り整えていたはずでした。

「コピーが効かない」から始まった

私たちは無料のWebツール集を運営しています。170種類を超えるツールがあり、毎日どこかを更新しています。当然、機械的な検査も整えてきました。ビルドは通る。検査は緑。エラーの通知も来ない。

それでも、壊れていました。13箇所も。

きっかけは、社内の利用者からの何気ない一報でした。「変換した数字が、コピーすると変換前のままなんだけど」。

さっそく調べると、変換そのものは正常でした。画面にも正しい結果が出ている。真犯人は別の場所にいました。コピーボタンです。押しても何もコピーされていなかった。利用者の手元には、直前に別の場所でコピーした「変換前の文字」がクリップボードに残っていて、それを貼り付けたので「変換されていない」ように見えたのです。

報告の文言(「変換がおかしい」)と、実際の故障箇所(コピー機構)は別でした。利用者は正確な故障報告をしてくれません。それが普通です。 症状から原因へ遡るのは、こちらの仕事でした。

しかもこのコピーボタン、押してもエラーが一切出ません。画面上は普通のボタンで、押した感触もある。ただ、静かに何もしていないだけ。私はこの類型を「静かに壊れる」と呼ぶことにしました。エラーは出ない、組み立ては成功する、見た目は一見正常、でも利用者には壊れている。火災報知器が鳴らない火事です。煙が見えるまで、誰も気づきません。

「壊れているのに、何も鳴らない」は他人事ではない

これはコピーボタンに限った話ではありません。中小企業の日々の業務にも、同じ壊れ方をするものがあります。

よくある「壊れているのに何も鳴らない」もの	気づくきっかけ
送信していたはずの請求書	「まだ届いていません」と言われて初めて分かる
自動返信していたはずのメール	「返事がない」と言われて初めて分かる
更新していたはずの在庫表	数字が合わないと誰かに指摘されて初めて分かる

どれも、「エラーが出ていない」ことを「動いている」の根拠にしてしまった結果です。エラー通知・組み立ての結果・見た目——この3つが揃って「正常」と言っていても、利用者の体験は壊れうる。根拠にできるのは、「実際に使う操作をして、期待の結果が返った」ことだけです。今回の13件は、すべてこの監視の網の外にいました。

1件の報告を、「型」として追いかけた

コピーボタンを直して終わり、にはしませんでした。1件見つかった壊れ方は、同じ型で他にも潜んでいると考えるべきです。

全ページのコピーボタン——数えたら40ページに186個ありました——を、実際のブラウザで機械的に全部クリックし、本当にコピーされたかを検査しました。すると、部品の付け忘れで完全に無反応のボタンが、さらに6個見つかりました。

同じ発想でサイト全体を洗うと、出てくるわ出てくるわ。

• ローンの計算ツール30ページ全部で、説明文が「月返済額 約NaN万円」になっていた(NaN=「数字ではない」という記号がそのまま表示されていた)
• SNSでシェアされたときに表示される画像が、4ページで存在しない画像を指していた
• 3ページで、開いた瞬間に裏側でエラーが起きていた(画面には出ないが、一部機能が死ぬ)

合計13件。どれも、エラー通知ゼロ・ビルド成功・見た目ほぼ正常の裏に隠れていました。最初の1件見つけて終わりにしていたら、残り12件は今日もそのまま静かに壊れ続けていたはずです。

修正だけなら一日で終わります。大事なのは、この類型を今後は機械が見つけるようにすることでした。検査を三層に分けて整備しました。

一層目は、組み立てた成果物そのものを機械で走査する層です。「NaN」「undefined」のような壊れの痕跡になる文字列や、リンク切れ・画像切れがないかを調べます。人間の目視では170ツール分を毎回見きれません。二層目は、本番に公開した直後に、実際のページを取得して正しく配信されているかを確認する層です。手元では正常でも、公開先の設定で壊れることがあるからです。三層目は、全ページを本物のブラウザで開き、開いた瞬間にエラーが起きないか見る層です。今回の「開いた瞬間に裏でエラー」型は、この層でしか捕まりません。

三層とも、初回実行でそれぞれ実物の不具合を検出しました。作った検査が初日から在庫の不具合を掘り当てたわけで、投資はその日のうちに回収された計算です。

検査そのものも、検査した

ひとつ、地味ですが大事な工夫があります。検査の側にわざと偽物の不具合を混ぜて、検査がちゃんと検出するかを確かめる仕組みを入れました。

以前、当社では「検査式が間違っていて、正常なものを異常と報告する」事故を経験しています。誤報を出す検査は、すぐに信用を失って誰も見なくなる。そうなると、本当に壊れた日の通知も読み飛ばされます。検査は、疑われたら終わりです。 だから新しい検査は、全サイトの実データで「誤検知ゼロ」を確認してから運用に入れる、という規律にしました。

報告は「点」ではなく「型」で受け取る

利用者からの不具合報告に対して「その箇所を直して返信する」だけだと、同じ型の仲間を見逃します。報告は「点」ではなく「型」で受け取る。 1件の報告から「同じ作りの場所は全部怪しい」と広げて調べる。今回はそれで1件が13件になりました。

正直なところ、「コピーが効かない」というその一報をもらった瞬間は、ひやりとしました。でも冷静に考えれば、黙って去られるのが一番の損失です。 無料ツールの利用者は、壊れていたら何も言わずに二度と来ません。

報告をくれる人がいて、報告の窓口があり、報告を型に広げて調べる手順がある。この3つが揃って、はじめて「利用者がテスターになってくれる」状態が生まれます。中小企業に専任の品質保証チームはいません。だからこそ、一報をもらえたことに感謝し、その価値を最大限に引き出す仕組みが要るのだと、今回あらためて思いました。

テストが緑であることと、利用者が困っていないことは、別の話です。その差分を埋めるのは、派手な技術ではなく、壊れ方の型を集めて、検査に変えていく地道な作業でした。今日もどこかで静かに壊れていないか、今は三層の検査が毎日サイトを巡回しています。