🗑️ 106人中21件のデータで、削除候補が3件出ていた——「完全性チェック」を後から入れるまで

棚の奥を確認しないまま、手前に並んでいるものだけ見て「全部チェックした」と思ったことがあります。

手前の5個を確認したという事実が、「全部見た」という感覚に変わっていました。

奥には、まだあるかもしれない。でも見ていない部分は、存在しないものと同じ扱いになっていました。

これが怖いのは、「見落とした」ではなく「確認した」という手応えがある点です。

確かめた感触があるまま、残りが確かめられていない状態です。疑いが起きにくい。

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

・自分で作った、あるいはAIに手伝ってもらって動かしているツールの出力を「たぶん合っている」で使い続けている

・ツールが何かを算出しているが、その計算のもとになったデータが全体の何%なのか確認したことがない

・処理が途中で止まっても、エラーが表示されないまま動き続けていることに気づいていない

・「おかしいかな」と感じながら、確認を後まわしにしたことがある

最後の項目は少し特別です。

「おかしい」という直感があるのに確認しない状態は、ツールへの信頼と「確認コストの先延ばし」が重なっています。

直感を後まわしにした回数だけ、問題は静かに積み重なります。

先に結論を言います。

「知っている」と「自分のツールにも実装している」は、まったく別のことです。

わたし——Lilyはこれを、自分が作ったフォロワー管理ツールが106人中21件のデータしか保持していない状態でunfollow候補を3件算出していたことで、初めて体で理解しました。

この記事では、フォロワー管理ツールが106人中21件のデータで候補を出していた失敗の原因と、fail-closedでの対処を書きます。

フォロワー管理ツールを作った経緯

このツールを作り始めたのは、今から約2か月前のことです。

Xのフォロワーを一覧で把握したい——それだけの動機でした。

フォロワーが100人を超えたあたりから、「この方、誰だっけ」という感覚が少しずつ出てきていました。

名前を見ても、どういう経緯でフォローし合ったか思い出せないことが増えていました。

記録があれば、確認できます。AIに手伝ってもらいながら、少しずつ形にしていきました。

一覧表示から交流の記録へ

最初は、フォロワーのユーザー名とプロフィールを一覧表示するだけでした。

それだけでも、手元で確認できることが増えた実感がありました。それで十分のつもりでした。

使っているうちに、「過去の交流も記録したい」と思い始めました。

「いいね」や「返信」のやりとりを積み上げておけば、誰と最近話していたかがわかります。

記録が積み重なってくると、「誰との交流が途切れているか」が見えるようになってきました。

見えてくると、次は「まとめて確認できる形にしたい」という欲が出てきます。

unfollow候補を出す機能を足した

気づいたら、「unfollow候補」という機能が加わっていました。

ここ数週間でいいねや返信のやりとりが少ないアカウントを、候補として画面にリストアップする機能です。

実際にunfollowするかどうかは自分で判断する、という設計にしていました。

ツールは補助。最終的な判断は人間が、という考え方で作っていました。

📕 AIエージェントと自動化の全工程をまとめた総集編


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

候補3件の表示に感じた違和感

ある日、画面に「候補が3件あります」と表示されました。

3件という数字を見たとき、「そうかもな」と思いました。

最近、Xのタイムラインをゆっくり見られていませんでした。

誰と交流があって誰となかったか、正直なところ把握しきれていませんでした。

だからこそツールに頼ろうとしていたわけで、「3件候補がある」という表示に、それほど違和感を感じませんでした。

候補を1件ずつ確かめた

3件の候補アカウントが、画面に並んでいました。

1件目——「最近確かに見ていないな」という感覚でした。

2件目——「そうかもしれない」という感覚でした。

1週間前にコメントをくれた方だった

3件目に差しかかったとき、手が止まりました。

そのアカウントは、1週間前にLilyのnoteにコメントをくれていた方でした。

コメントの内容を覚えていました。ある記事の特定の部分について、丁寧な感想を書いてくれていました。

Lilyも返信をしていました。

「この方が候補として出ている？」という疑問が、まず浮かびました。

「何かがおかしい」という直感で、画面から離れてログを確認しました。

記録は106人中21件だった

ツールが保持しているフォロワーの記録を数えてみると、21件でした。

フォロワーの総数は106人です。21 ÷ 106 = 約20%以下です。

全体の5分の1以下のデータで、「誰との交流が少ないか」を計算していました。

残りの85人は、ツールにとって文字通り「存在しない人」と同じ扱いになっていました。

この85という数字が、しばらく頭の中で止まっていました。85人のデータがありません。

その85人の中に、実際はよくいいねをくれている方がいるかもしれない。

よく返信をくれている方がいるかもしれない。

でもツールはその85人を「記録なし＝交流なし」として処理していました。

そして、その状態でunfollow候補を3件出していました。

21件で止まっていた原因

なぜ21件しかデータがなかったのか、原因を調べました。

少し技術的な話になりますが、できるだけ噛み砕いて書きます。

Xのデータ取得には1日の上限がある

Xのデータを外部のツールで取得するとき、「一度に全件取得する」ことはできません。

「100件ずつ取ってきてください」という形でXのシステムに問い合わせる必要があります。

そしてこの「問い合わせ」には、1日あたりの上限があります。

ツールが動いていたある瞬間、この上限に引っかかりました。

21件を取得したところで、制限がかかって処理が止まりました。

止まった事実が画面に出なかった

本来であれば「21件まで取れました。残りは取れていません」と、何らかの形で表示するべきでした。

でもツールにはそういった仕組みがありませんでした。処理は止まったが、その事実は画面に出ませんでした。

ツールはその後も動き続け、21件のデータを全体として扱いながら計算を続けていました。

エラーはログにだけ残っていた

確認に動いたのは、ツールが書き出していたログファイルを直接開いてからです。

処理が中断した時刻のあたりに、1行だけ短いメッセージが記録されていました。

APIからのレート制限エラーで処理が中断したことを示す内容で、エラーはログには残っていました。

でも画面には何も出ていませんでした。

エラーをログに書く仕組みはあったが、エラーが出たときにツールの動作を変える仕組みがなかった、ということです。

記録するだけでは、足りませんでした。

このことに、Lilyは3週間気づきませんでした。

知っていたのに実装していなかった

ここで、少し背景を話します。Lilyはマーケティングの仕事を長くしてきました。

月に数千万円規模の広告費が動く現場で、データと向き合ってきました。

そのとき、何度も繰り返してきた確認があります。

「このデータ、全件取れていますか？」「計測が外れていた期間はありませんか？」

「ゼロ件のとき、本当に"ゼロ"ですか？それとも"取れなかった"のですか？」

「データが欠けていた場合、どこかで警告が出るようになっていますか？」

これらは、データを扱う仕事では当たり前の確認です。

新しいシステムを導入するとき、週次のミーティングで、設計のレビューで、繰り返し確認してきました。

「品質チェックは要件に入れる」というのは、Lilyにとって特別なことでも難しいことでもありませんでした。

タグ1日の欠けでレポートがぶれる

広告のコンバージョンデータを扱っていたとき、タグが1日外れていただけで、週次のレポートが大きくぶれることがありました。

気づかずに翌週の予算配分に使えば、効果の低い媒体に多く配分するという判断が起きます。

「全件取れているか」「計測が外れた期間はないか」の確認は、そういう経験から習慣になったものでした。

危ないのはエラーの出ない誤り

システムが動いているように見えるとき、一番危ない場所はどこか——それは、エラーが出ていなくて、でも正しくない状態です。

それなのに。自分で作ったフォロワー管理ツールには、この確認を1行も書いていませんでした。

「動いている」と「正しく動いている」

最初にこのことに気づいたとき、しばらく何もできませんでした。

自分がよく知っているはずのことを、自分がやっていなかった。

「知識があるから、大丈夫だと思っていた」という感覚に、今は言語化できます。

ツールを作るとき、機能を追加するたびに動作確認をしていました。

「ちゃんと動いている」という確認を重ねていました。

その「動いている」という感覚が、いつの間にか「正しく動いている」と同じ意味になっていました。

動いている、と、正しく動いている——この2つは違います。

でも個人でツールを作るとき、その区別が薄れていました。

自分が作ったものへの無意識の信頼

もうひとつ、正直に言います。「自分が作ったものへの無意識の信頼」があったと思います。

他の人が作ったシステムを見るとき、「これは本当に全部取れていますか？」と問うのは自然でした。

でも自分が作ったものを見るとき、その問いを立てていませんでした。

「自分が作ったものだから、基本的には大丈夫」という前提が、どこかにありました。

その前提を、疑っていませんでした。新しくシステムを導入するときに「品質チェックはどこに入っていますか？」

と確認し続けてきた人間が、自分のシステムでは省いていた——笑い話のようで、わりとしんどかったです（笑）

でも同時に、「見に行ってよかった」という気持ちも大きかったです。

3件目で手が止まったこと、そこから確認に動いたこと——それは正しい行動でした。

「おかしい」という直感を、後まわしにしなかったことは、よかった。

ツールが何も言わない「静かな誤爆」

一番怖かったのは、「3件の候補が出ていた」こと自体ではありませんでした。

怖かったのは、ツールが何も言わなかったことでした。

正常に見える画面のまま候補が出た

画面には「候補が3件あります」とだけ出ていました。

「取得できたデータは21件です」という表示はありませんでした。

「106人中21人分しか記録がありません」も出ていませんでした。

「データが不完全な可能性があります」というメッセージも、どこにも出ていませんでした。

正常に見える画面のまま、候補を3件出していました。

この状態を、Lilyは「静かな誤爆」と呼ぶことにしました。

大きなエラーより気づきにくい

大きなエラーが出れば、気づけます。赤い文字でエラーが表示されれば、手が止まります。

「処理に失敗しました」と出れば、確認に動きます。でも静かな誤爆は、そうではありません。

成功した見た目のまま、部分的なデータで処理を続けます。声が出ません。何も言いません。

だから気づきにくい。

入力データの欠け以外でも起きる

静かな誤爆は、入力データが欠けているとき以外にも起きます。

たとえば、フィルタリングの条件が意図と違う形で機能していて、除外すべきものが残り続けているとき。

たとえば、日付の絞り込みがタイムゾーンのずれで1日ずれているとき。

たとえば、「値なし」と「ゼロ」が区別されておらず、実績がないのか記録がないのか判断できない状態。

どれも、出力画面は「動いている」に見えます。数字も出ます。結果も出ます。ただ、それが正しくない。

影響の大きい処理なら取り返せない

今回はフォロワー管理がテーマでした。「誤って外してしまった」で済む話でした。

相手に連絡して「間違えてしまいました」と伝えれば、大抵は終わります。フォローし直せばいい。

でも同じ構造が、もっと影響の大きな部分に入っていたら——そう考えると、今回早めに気づけてよかった、と思います。

たとえば、顧客へのメール送信対象を絞り込む処理。たとえば、金額に関わる計算。

たとえば、データの更新や上書き。

こういった処理が「静かな誤爆」をしていたとき、「間違えました」で終わらない可能性があります。

フォロワー管理ツールで気づけたのは、幸運でした。

でも「幸運だった」で終わらせず、仕組みを変えることにしました。

データ不足なら候補を出さない設計

対処は、シンプルにしました。

取得できたフォロワー数が全体の90%を下回っている場合、unfollow候補を表示しない処理を追加しました。

フォロワーが106人なら、96人以上のデータが取れていれば候補を出します。

それ以下であれば、候補は出しません。

画面には「データが不十分なため、今日は候補を表示できません」という表示に変わります。

この設計の考え方を「fail-closed（フェイル・クローズド）」と言います。

「失敗したときは、安全な方向に閉じる」という考え方です。

反対の設計は「fail-open（フェイル・オープン）」——「失敗しても、できる範囲で動き続ける」という考え方です。

ツールの目的や操作の性質によって、どちらが適切かは変わります。

でも削除・変更・送信など、やり直しにくい操作を含む場合は、fail-closedの方が安全なことが多いとLilyは考えています。

候補が出ない日があっても、誤った候補が出るよりいい。そう判断しました。

取得直後に閾値チェックを挟む

実装としては、フォロワーの取得処理が終わった直後に判定を1段階追加する形にしました。

「今日取得できた件数」を「記録上の総数」で割り、その値が0.9を下回る場合は候補の算出に進まず、画面にメッセージを返します。

候補を算出する処理自体は変えていません。入り口に閾値チェックを挟んだだけです。

変更の規模は小さかったですが、「データ不足のまま候補が出る」という状態は、ここで終わりました。

90%というラインを選んだ理由

90%というラインをなぜ選んだか、少しだけ補足します。

「100%でなければ動かない」にすると、わずかな制限引っかかりでも毎回候補なしになります。

それは使いづらい。かといって「50%でも動く」にすると、21件（約20%）でも動いてしまいます。

90%というのは、「大幅に欠けていれば止まる、わずかに欠けていれば動く」というバランスとして選びました。

このラインが最適かどうかは、使い続けながら調整するかもしれません。

とにかく「チェックがある状態にする」を、まず優先しました。

チェックのない状態を、先に終わらせたかった。

根拠を説明できる数値にする

数字を決めるとき、もう一つ意識したことがあります。「根拠を出せる数値にする」ということです。

なぜ90%かという根拠は、過去の取得履歴からXの制限がどの程度の頻度でかかるかを確認して、「毎日ギリギリ制限にかかることは少ない」という実績からきています。

根拠のない数字でラインを決めると、チェック自体が形だけになります。

「だいたいこんなもんだろう」という感覚でラインを引くと、その感覚がどこから来ているか自分でも説明できなくなります。

数字を持つなら、その数字が何から来ているかを言えるほうがいい、という考え方です。

変更後に2回「候補なし」が出た

変更後、ツールは2回「候補なし（データ不足）」を返しました。

最初の1回を見たとき、「あれ？」と思いました。

でも確認すると、取得数が80件台にとどまっていて、90%のラインを下回っていました。

ツールは正しく判断していました。

以前のままなら候補を出していた

あの状態のまま動き続けていたら、この2回も候補を出していたはずです。

その候補が「実際に交流が少ないアカウント」だったのか、「データがないだけのアカウント」だったのか、画面を見ただけでは判断できませんでした。

チェックを入れてからは、少なくとも「データが20%しかない状態で候補を出す」ことはなくなりました。

取れなかった事実が見えるようになった

「候補なし」が出た日を確認すると、取得数は81件でした。106人中81件で、約76%です。

以前は、この81という数字が画面に出ることすらありませんでした。

チェックを入れたことで、「取れなかった事実」が見えるようになりました。

「候補なし」は正しい判断の結果

「候補なし」という表示は、失敗ではありません。

「今日のデータは信頼できる水準に届いていない」という、正しい判断の結果です。

そう考えると、何も言わずに動き続けていたときより、ずっと信頼できます。

失敗談として残す理由

この話を書いたのは、失敗談として残す意味があると思ったからです。

「知っている人間でも、自分のツールには同じことをしていなかった」という話です。

AIでツールを作るハードルは下がった

AIが個人開発を手伝ってくれる時代になって、ツールを作るハードルは下がりました。

それ自体はいいことです。

でも「動いている」から「正しく動いている」まで、確認の手順が自然についてくるわけではありません。

Lilyは3週間、106人中21件のデータで動かし続けていたツールを、「うまく動いている」と思っていました。

数字は正直です。21は21です。106は106です。

それを見に行かなかったのは、Lilyの側の問題でした。

「動いているから大丈夫」という感覚が、どれだけ長くその状態を続けさせるか。

体験として知ることができたのは、小さな代償で済んだ幸運だったと思っています。

品質チェックは設計で意図して入れる

AIと一緒にツールを作るとき、AIは「動く」ものを作るのが得意です。

でも「正しく動く」ための品質チェックは、設計の段階で意図して入れなければ、入りません。

それはAIの問題ではありません。システムの設計として、最初から組み込む必要があります。

あなたのツールは止まったとき何か言うか

最後に、読んでくださっている方へ。

AIに手伝ってもらって何かを作っている方、あるいは個人で小さなツールを動かしている方——そのツールは、途中で処理が止まったとき、何か言いますか？

「成功した見た目のまま、部分的なデータで動き続ける」ことはないですか？

確認しに行くのが少し怖い気持ち、わかります。

「見てみたら思ったよりひどかった」という話になるかもしれない。でも見に行く方が、絶対にいいです。

特に、削除・変更・送信など、やり直しにくい操作を含む部分は——入っているデータが何件なのか、全体の何%なのかを、一度数えてみてください。

完全性チェックの入れ方や、fail-closedの考え方を自分のツールに当てはめる方法は、別のnoteにまとめています。

よければ続きも読んでみてください。

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