株式会社Koinobori
HANDS-ON / 執筆：杉﨑（代表取締役）

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

エラーも出ない・ビルドも通る・見た目も正常。それでも利用者には壊れている——そんな「静かに壊れる」バグが、1件の報告をきっかけに13件見つかりました。テストが緑でも安心できない理由と、検査を三層に重ねた話です。

タグ: #品質管理 #テスト #障害対応 #Webサイト運営 #中小企業 #2026

はじめに：この記事の前提

Koinobori 代表取締役の杉﨑です。 社員数名の会社を経営しながら、自社の Web サービスを自分の手で作り、AI を相棒に毎日更新しています。

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

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

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

1. 課題：エラーが出ないのに、壊れている

最初の一報は「変換がおかしい」だった

報告を受けて、まず変換機能を調べました。変換そのものは正常でした。 画面にも正しい結果が出ている。

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

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

なぜ気づけなかったのか

このコピーボタン、押してもエラーが一切出ません。画面上は普通のボタンで、押した感触もある。ただ、静かに何もしていないだけ。

私たちのサイトを支える仕組みには、こういう性質があります。部品の名前がひとつ食い違っていても、警告なしで「空っぽ」を表示してしまう。ビルド（サイトの組み立て工程）は成功し、既存の検査も通ります。

私はこの類型を「静かに壊れる」と呼ぶことにしました。

火災報知器が鳴らない火事です。煙が見えるまで、誰も気づきません。

2. 取り組み：1件の報告を「類型」として追う

2-1. 同じ壊れ方を全部探す

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

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

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

合計 13 件。どれも、エラー通知ゼロ・ビルド成功・見た目ほぼ正常の裏に隠れていました。

2-2. 検査を「三層」に重ねる

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

第一層：組み立て後の成果物を調べる サイトの完成品（HTML）を機械で走査し、「NaN」「undefined」のような壊れの痕跡になる文字列が紛れていないか、リンク切れや画像切れがないかを調べます。人間の目視では 170 ツール分を毎回見きれません。

第二層：本番配信を調べる サイトを公開した直後に、本番の URL を実際に取得して、正しく配信されているかを自動確認します。手元では正常でも、公開先の設定で壊れることがあるからです（実際、以前この型の事故がありました）。

第三層：実際に開いて調べる 全 237 ページを本物のブラウザで開き、開いた瞬間にエラーが起きないかを検査します。今回の「開いた瞬間に裏でエラー」型は、この層でしか捕まりません。

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

2-3. 検査そのものも検査する

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

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

3. 結果：報告1件が、13件と検査体制に化けた

一日の終わりに数えると、こうなりました。

発見のきっかけ見つかった数
利用者の一報（コピー）1 件 ＋ 同型 6 件
第一層の検査（成果物走査）34 ページ分（NaN 30 ＋ 画像 4）
第三層の検査（実ブラウザ）3 ページ

「コピーが効かない」というたった一言が、13 件の修正と、三層の検査体制に化けました。 あの一報がなければ、これらは全部、今も静かに壊れたままです。

4. 学び

「エラーが出ていない」は「動いている」の根拠にならない

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

報告された1件は、氷山の一角として扱う

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

不具合報告は、もらえること自体が資産

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

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

おわりに

サイトやツールを運営している方は、一度「エラーは出ていないが、実際に押したら動かないボタン」が自社サイトに何個あるか、想像してみてください。私は「ゼロのはず」と思っていて、13 件ありました。

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

執筆：Koinobori 代表取締役 杉﨑

RELATED — 関連コラム

こちらもどうぞ