📊 自作ツールが売上111円を捨てていた——自分のコードを信じすぎた話

郵便受けの中に「ダイレクトメールだけ捨てる仕掛け」を置いたとします。

でもその仕掛けの判定が少しだけ甘くて、大切な請求書まで一緒に捨てていた。

そのことに気づいたのは、督促状が届いてからでした。

「ずっとゴミを捨てていたと思っていたのに、大事なものも一緒に消えていた」——そういう状況です。

あなたは今こうなっていませんか？

• 自分で作ったツールの動作を、最後に確認したのが2週間以上前になっている
• 「エラーが出ていないから大丈夫」と、中身の確認をスキップしている
• 集計や記録を自動化しているけれど、出力の詳細は細かく見ていない
• ツールが「完了しました」と返してくれると、それ以上は疑わない

先に結論を言います。自分で書いたコード・自分で設定したルールほど、疑う目が必要です。

この記事では、私の売上管理ツールが111円をサイレントに捨てていた話と、その発覚の経緯を書きます。

「外のものは疑うのに、自分のものは疑わない」という盲点がなぜ起きるのかについても整理します。

エラーがないのに、売上が消えていた

毎日「正常終了」と出ていたのに

ツールが毎日動いていました。エラーのログも、警告も、何も出ていませんでした。

「ちゃんと動いている」——そう思っていました。確認するたびに、処理は完了しているように見えました。

でも実際には、大事なデータが毎回静かに捨てられていたのです。

エラーログがきれいなのは、ツールが「壊れていない」ということです。

「正しく動いている」かどうかは、また別の話なのです。これは当たり前に聞こえるかもしれません。

でも自分が作ったツールで実際に体験すると、かなりこたえます。

「動いている」という事実が、確認を怠らせるのだと気づきました、、、

正常終了という言葉が、これほど裏切ることがあるとは思っていませんでした。

ここに、一つ目の落とし穴があります。

ログを見返して、小さなズレに気づいた

あるとき、何気なく動作ログを見返していました。特に何か疑っていたわけではありません。

日課の確認作業をしていたら、気になる数字が1つありました。

note1という仕組みの「成功率」が1/2になっていたのです。

「あれ、これっていつから？」と思って過去をさかのぼりました。

数日前から1/2が続いていたことがわかりました。

そして、ある時点から2/2に戻っていました。

2/2に戻ったタイミングで、初めて「何かがおかしかった」と気づいたのです。

「おかしい」と気づいたのは、「戻った」からです。

ずっと1/2が続いていたら、もしかして気づかなかったかもしれません。

発覚のきっかけが「正常に戻ったこと」だったのが、少し皮肉な話でした。

でもそれが、今回の一連の調査の始まりでした。

📕 AIエージェントと自動化の全工程をまとめた総集編 手順・コード・テンプレをそのまま渡しています 🤖【完全版】月商160万円の「寝てても回る仕組み」をゼロから30日で組む全工程｜2026年10月版・Claude Code×AIエージェント・特典40ファイル・毎月更新

「正規表現」という道具の話を、噛み砕いて説明します

正規表現とは「こういう形を探せ」という命令

少しだけ技術的な話をします。できるだけ難しくしないので、もう少しお付き合いください。

私のツールの中に「正規表現」というものが使われています。

これは「テキストの中からこういう形のものを探してね」という命令のことです。

たとえば「数字が3ケタ以上続いているもの」を探したいとします。

正規表現を使うと、文章の中からそのパターンだけを自動で拾えます。

料理のレシピで言えば、「材料の一覧の中から、グラム数だけを自動で読み取る」ようなイメージです。

私のツールでも、売上の金額を本文から自動で抽出するために使っていました。

人間が目で見ればすぐわかることを、機械が自動でやる——そのための道具です。

ただし、機械は「見た目」ではなく「ルール」で判定します。

そのルールが少しでもズレていると、人間には当然わかることが、機械には全然わからないのです。

「見れば一発でわかるのに」ということが、ルールのズレで誤動作するのが正規表現の難しさです。

日本語の数字には「助数詞」が後ろについてくる

ここが今回の事故の核心です。英語と日本語では、数字の使い方が少し違います。

英語では「3 items」のように、数字と単位の間にスペースが入ります。

日本語では「3冊」「3つ」「3件」のように、数字にくっついて助数詞が来ます。

「助数詞」とは、ものを数えるときに数字の後ろにつける言葉のことです。

「冊」「個」「本」「つ」「件」「回」などが代表的な助数詞です。

金額の場合は「円」「万円」が後ろにつきます。

でも「3つ」「5件」のような表現の「3」「5」も、数字には変わりません。

私のツールの設定は、数字の後ろに何が来ても「金額」として拾ってしまう状態でした。

「売上ガード」のはずが、金額以外のものまで「金額だ！」と誤って判定していたのです。

日本語コンテンツを扱うとき、この助数詞の問題は思った以上によく起きます。

英語前提で設計されたロジックをそのまま日本語に使うと、こういった事故が起きやすいのです。

111円が消えた、その仕組み

「この3つ」が金額として誤検知された

今回の事故を具体的に説明します。本文の中に「この3つ」という日本語が含まれていました。

ツールの設定は「数字で始まるもの」を金額として拾おうとしていました。

そして「3つ」の「3」を、「3円」「3万円」などの金額の一部だと誤判定したのです。

「この3つ」の「3」が金額に見えてしまい、売上の数字として認識されてしまいました。

本来拾うべきだった111という実際の金額より先に「3」を検知して、処理が止まったのです。

少しイメージしにくいかもしれないので、別の比喩で説明します。

金庫の暗証番号を読み取るシステムが、扉の模様にある「3」を「番号だ！」

と誤認して、処理を止めてしまうようなイメージです。

本物の番号（111）はもっと後ろにあるのに、偽物の番号（3）が先に引っかかる。

そういう状態でした。

「3」は正しい数字の形なので、ツールから見るとエラーでも何でもありません。

「正しいルールに従って処理した。完了です」と返してくるのです。

サイレントに捨てられていた、実際の売上

ツールの側から見ると、処理は「完了」していました。エラーにはなっていませんでした。

ただ、出力されたデータは「3」だけで、本当の売上金額111円は捨てられていました。

しかも、それが音も立てずに捨てられていたのです。

「サイレントに捨てる」というのは、「エラーも警告も出さずに、条件に合わないデータを無視する」という意味です。

ツールは何も文句を言わずにデータを捨てて、「はい、完了です」と答えていたのです。

これが一番きつかったです。間違ったまま「うまくいった顔」をしているので、疑いようがないのです、、、

「エラーが出たら疑う」という発想では、こういうバグには気づけません。

エラーが出ない状態で、正しくない動作をするのが一番怖いのです。

CMOとして外のレポートは疑っていたのに

外部のデータには「前提から確認する」を徹底していた

少し私の経歴の話をします。私はかつて、月3,000万円規模の広告運用に関わる仕事をしていました。

そのときに身についた習慣があります。

外部の代理店やベンダーが持ってくるデータは、「計測の前提」から確認することです。

「この数字、どういう条件で集計しましたか？」「トラッキングタグは正しく全ページに入っていますか？」

こういう質問を、毎回当たり前のようにしていました。

数字を疑うことは、相手への不信ではなく「正確に動くための礼儀」だと思っていたからです。

レポートの数字が良くても悪くても、計測の前提がズレていれば意味がありません。

だから数字の中身よりも先に、「どうやって集めたか」を確認するのが習慣になっていました。

外部のレポートに対しては、この姿勢を自然に取れていました。

でも今回、自分で書いたツールには、その目を一切向けていなかったのです。

自分のコードには、その目を向けていなかった

「自分で作ったから、仕組みを分かっている」という安心感がありました。

「エラーが出ていないから、大丈夫」という思い込みもありました。

そこに、確認をサボらせる罠がありました。

「分かっているから大丈夫」という気持ちは、いつの間にか「確認しなくていい」に変わっていたのです。

外のレポートは疑えるのに、自分の手で作ったものは疑えない——。

これは正直に書くと、少し恥ずかしい話です。

でも同じことをしている人は、きっと多いと思います。

「自分で作ったもの」への甘さは、エンジニアでも非エンジニアでも同じように起きるのではないかと思います。

「気づきにくいバグ」の代表格が、「自分を信じすぎたバグ」なのだと今回改めて感じました。

だからこそ、ここに書いておきたかったのです。

発覚した日のこと

成功率が2/2に戻ったのをログで確認した

あの日、ログを眺めていて気づきました。note1の処理結果が2/2になっていたのです。

「あ、戻った」と思った瞬間、疑問が生まれました。「なぜ戻ったんだろう？」ということです。

逆に言うと、「なぜ一時期1/2になっていたんだろう？」という疑問でもあります。

その疑問を持てたのは、ログを記録し続けていたからでした。

ログがなければ、気づかないまま使い続けていたと思います。

「成功率が記録されている」という地味な仕組みが、今回は命綱になりました。

記録することの大切さを、改めて実感した出来事でした。

何かがおかしいと気づくためには、比較できる過去のデータが必要だからです。

ログを追って、正規表現の問題にたどり着いた

処理ログを時系列で追っていきました。

「1/2になったタイミング」と「2/2に戻ったタイミング」の前後に何が変わったかを確認しました。

変わっていたのは、本文の中の文言でした。

「この3つ」という表現が含まれている記事を処理したときに、誤検知が起きていました。

ツールの正規表現のコードを見直すと、末尾の条件が甘いことがわかりました。

「数字の後ろが何であっても金額として拾う」設定になっていたのです。

これは私が最初にツールを作ったときに設定したものでした。

日本語の助数詞のことを、作るときに考えていなかったのです。

「あ、これ私が作ったとき雑だったな、、、」と思いました（笑）。

でも発見できたことで、次は同じミスをしないで済みます。

不具合の原因がわかったときのあの感覚は、独特です。

「やってしまった」と「やっと分かった」が同時に来る感じです。

修正して、分かったこと

末尾を「金額の形」に限定する

修正方法は、実はシンプルでした。正規表現の末尾の条件を「金額の形に合うものだけ」に限定したのです。

具体的には、「円」「万円」などが後ろに続く場合だけを金額として認識するように変えました。

「3つ」や「3件」のような助数詞が後ろにある場合は、金額としてスキップするようにしました。

これで「この3つ」が誤って111円を押し出すことはなくなりました。

修正後、処理の成功率は安定して2/2を維持するようになりました。

修正そのものにかかった時間は、30分ほどです。

ただ「何が起きているか」を理解するまでに、数時間かかりました。

その数時間は、決して無駄ではなかったと思っています。

「なぜこうなったのか」を理解することで、次に同じ種類のミスを防ぐための引き出しが増えるからです。

「動いているツール」こそ、定期的に確認する

今回の教訓を2つ整理します。1つ目は「エラーがない＝正しく動いている」ではないということです。

2つ目は「動いているツールほど、見落とされやすい」ということです。

壊れていれば気づきますが、「間違ったまま動いている」状態は気づきにくいのです。

これは自分でツールを作る人だけの話ではありません。

AIに作ってもらったスクリプトも、設定した自動化のルールも、同じことです。

「使い始めてから確認していない」ものが1つでもあれば、今日確認してみることをおすすめします。

特に、毎日動いていて当たり前になっているものほど、確認する機会が失われがちです。

「信頼」と「検証」は別のもの

自動化は便利だからこそ、見えにくくなる

自動化の最大のメリットは「自分が動かなくていいこと」です。

でもそれは同時に「何が起きているかを見えにくくする」デメリットでもあります。

手作業なら毎回確認する流れになりますが、自動化されると確認の機会がなくなります。

「毎日処理してくれている」という安心感が、確認の頻度を下げるのです。

私の場合、ツールが111円を捨てていた期間も、処理自体は毎日動いていました。

売上データの一部が毎回欠損した状態で記録されていたのに、気づかなかったのです。

自動化は「仕組みを作ったら終わり」ではありません。

「仕組みが正しく動いているかを確認する習慣」もセットで持っておく必要があります。

「信頼」は確認した上でするもの

外部のレポートを疑うのと、自分のツールを疑うのは、構造的に同じことです。

どちらも「アウトプットの前提を確認する」という行為です。

「信頼しているから確認しない」ではなく、「確認したから信頼できる」が正しい順番です。

このことを、今回のバグが改めて教えてくれました。

自分のコードへの「根拠のある信頼」を持つためには、定期的な動作確認が必要です。

ログを見る、出力の中身を抜き打ちチェックする——そういう地味な習慣が、サイレントなバグを防ぎます。

Claude Code自律環境の仕組みを全部まとめた有料記事があります。

「確認の仕方も含めた全体像を知りたい」という方は、フッターのリンクからどうぞ。

最後に——今日からできる1つのこと

ツールの「出力」を、今日1回だけ中身まで見てほしい

もし今、何かのツールや自動化を使っている方がいれば、1つだけお願いがあります。

直近の出力を、今日1回だけ「中身」まで見てみてください。

「ちゃんと動いた」という完了通知ではなく、「何のデータが処理されて、何が出力されたか」を確認するのです。

それだけで、サイレントなバグに早く気づける可能性が高まります。

私は今回、ログのおかげで111円のロスを発見できました。

でもログがなければ、もっと長い期間気づかないままでいたと思います。

「特に何もないだろう」と思っているときほど、一度だけ細かく見てみてください。

意外と「あれ、これおかしいな」という発見があるかもしれません。

自分を疑うのは、自分を否定することではない

今回の話は、技術的には小さなバグです。

でも「自分を疑う目」を持てるかどうかは、技術の話ではなく姿勢の話だと思います。

自分で作ったものほど、可愛くて信じたくなります。でもそれが、一番の盲点になるのです。

外のレポートを疑えるあなたなら、自分のツールも同じ目で見られるはずです。「正しく動いているか？」

を確認することは、自分への不信ではなく「正確に運用するための礼儀」なのだと思います。

自分のコードを信じすぎた話——これは過去の私への反省でもあります。

でもこの反省が、誰かの「気づき」のきっかけになれば、書いた甲斐がありました。

📕 この記事の内容を、実装まで全部まとめた有料記事があります 手順・コード・テンプレをそのまま渡しています AIで「寝てても回る仕組み」をゼロから30日で組む全手順