🔢 n=3で出した「勝ちパターン」が4件目でひっくり返った——AIのPDCAに最低サンプル数を設けるまで

バスケットボールで3本連続シュートが決まったとき、「今日は当たっている」と感じます。

でも4本目が外れ、5本目・6本目も外れたら、最初の3本は「たまたまの連続」だったことになります。

人間の感覚では、3回の連続は十分な根拠に見えます。

でもデータとしては、まだほとんど何も証明されていないのです。

それは頭では分かっていました。でも自分が設計したAIツールで、まったく同じ間違いをやっていました。

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

• AIに投稿や文章を判断させるとき、3〜5件のデータで「方向性が見えた」と結論を出している • 最初の数回がうまくいったから「このやり方が正解だ」と思い込んでいる • AIのPDCAを回しているけれど、何件から判断するかを事前に決めていない • 「勝ちパターンを見つけた」つもりでいるが、試した件数を聞かれると答えが曖昧になる

先に結論を言います。

AIのPDCAは、最低サンプル数を決めないと、少ない件数で間違った学習をします。

わたしのツールは3件で判断していたせいで、4件目に結論が逆転しました。

この記事では、AIツールが3件で判断して4件目に結論が逆転した事故と、最低サンプル数を8に変えた理由を書きます。

AIが投稿を自動で改善する仕組み

少し、背景から話させてください。

わたしはLilyという名義で、SNS運用やnoteの発信をしています。

数年前から、XとThreadsで投稿の文章を自動生成するAIツールを動かし続けています。

このツールの仕組みをざっくり説明すると、「AIが投稿を出して、反応を見て、次の投稿をよくしていく」というものです。

専門的な言葉では「PDCAを自動で回す」と言います。

PDCAというのは「計画→実行→評価→改善」の繰り返しのことです。

人間が手動でやっていた見直しの作業を、AIが自動でやってくれるイメージです。

このツールには「スタイル評価器」という部品があります。

「感情的な訴え」「具体的な数字を含む」「問いかけで終わる」といった投稿の型を、それぞれ評価してスコアをつける仕組みです。

スコアが高い型は「勝ちパターン」として記憶され、次の投稿生成に使われます。

スコアが低い型は「負けパターン」として記録され、使用頻度が下がっていきます。

この学習サイクルが自動で動き続ける。それが基本的な構造です。

勝ち負けは3件のデータで決めていた

評価のポイントはシンプルです。「この種類の投稿は伸びやすいか、そうでないか」を数値で判定します。

そしてその判断を下すとき、ツールは3件のデータを参照する設計でした。

「3回試して、だいたい結果が揃ったら勝ち負けを決める」という設定です。

当時のわたしには、この数字に疑問がありませんでした。

3件くらいあれば傾向が見えるだろう、という感覚で決めたのです。

でも、ここに落とし穴がありました。「感覚で決めた数字」が、後で大きな問題を引き起こすことになります。

設定ファイルに書いた3という数字

ツールの設定ファイルには、こんな形で書いてありました。

MIN_SAMPLES = 3

たった一行です。でもこの一行が、ツールの全判断に影響していました。

「MIN_SAMPLESに満たない件数のときは、判断を保留する」という条件が、コードの評価ロジックに組み込まれています。

この設定値が3だと、4件目のデータが来る前に「判断済み」のフラグが立つのです。

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


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

3件の連勝が4件目で逆転した

Xで投稿の自動最適化を動かしていたとき、事故が起きました。

あるパターンの投稿が、3件連続で平均より高いエンゲージメントを記録しました。

エンゲージメントというのは、いいね・リプライ・引用などの反応の総数のことです。

ツールはこれを「勝ちパターン」と判定して、このパターンの投稿を増やす方向に学習しました。

ここまでは、設計通りの動きでした。

4件目からスコアが急落した

問題は4件目でした。4件目の数字が急落して、平均を大きく下回りました。

「たまたま調子が悪かっただけかも」と思って様子を見ていると、5件目・6件目も同じ傾向でした。

3件の連勝は偶然だったのです。

ログに残っていた逆転の記録

この事故を発見したのは、週に一度手動でログを確認する習慣があったからです。

ツール側が出力する pattern_score という数値が、連続して下がっているのを見て異変に気づきました。

evaluation_log.json の中に、こんな記録が残っていました。

pattern: "emotional_appeal", score: 0.82, n=3, status: "promoted"
pattern: "emotional_appeal", score: 0.31, n=4, status: "should_demote"

スコアが0.82から0.31に、たった一件で逆転していました。

「勝ちパターン」として学習した内容が、間違いだったことになります。

間違った方向に最適化が進んでいたことを、4件目になって初めて知りました。

これが正直、かなりしんどい発見でした。

「仕組みで動かしているから正確なはず」という安心感が、一瞬で崩れた感覚です。

ツールが「動いていること」と、ツールが「正しく動いていること」は、別の話なんだと思い知りました。

動いているように見えていても、間違った学習を積み重ねていることがある。

前職で言い続けた「n数が足りない」

その発見のとき、前職の記憶がフラッシュバックしました。

CMOとして働いていた頃、チームに繰り返し言い続けていた言葉です。

「n数が足りないまま判断するな」というものでした。

n数というのは「データの件数」のことで、広告の世界でよく使う言い方です。

施策を1週間だけ走らせて「効果がない」と判断しようとしたチームメンバーに、「まだサンプルが少なすぎる」と何度も待ったをかけていました。

月3,000万円規模の広告を動かしていても、そういう判断ミスは普通に起きるのです。

「分かった気になる」のが、人間の自然な反応なのかもしれません。

そのわたしが、自分で作ったツールで同じことをしていた。

笑えない話なんですけど、笑うしかなかったです（笑）

「知っていること」と「実際にやっていること」は、まったく別なんだと改めて思いました。

頭の中にある知識は、仕組みの中に落とし込まなければ、ルールとして機能しないのです。

知識はあった。でもコードに書いていなかった。

それだけのことでした。そしてそれだけで、半年以上間違い続けていました。

MIN_SAMPLESを3から8に変えた

事故を確認してすぐ、Threads側のツールへ予防的な横展開をしました。

Threadsのツールも同じ構造で動いていて、同じように3件で判断する設定でした。

「Threadsではまだ事故は起きていないが、時間の問題だ」と判断しました。

Xで起きたことを、Threadsで繰り返す前に手を打ちたかったのです。

これは「壊れる前に直す」という選択です。

そこでMIN_SAMPLESを3から8に引き上げました。

MIN_SAMPLESというのは、「最低でも何件集まってから判断するか」という設定値のことです。

プログラムの中に「この数字未満のときは判断しない」と書くだけの変更です。

変更は設定ファイルの1行だけ

変更箇所は config/evaluator_settings.py の1行でした。

XとThreadsで同じ評価ロジックを共有しているため、ここを書き換えるだけで両方に反映されます。

git diff で確認したのは、たった1行の変更です。

- MIN_SAMPLES = 3
+ MIN_SAMPLES = 8

たった1文字分の差です。でもこれで、ツールが判断を出すまでの条件が根本から変わりました。

ただし、この一行が、ツールの行動を根本から変えます。

8にした根拠とまだ分からないこと

なぜ8かという根拠は、シンプルです。

3件で逆転が起きたので、「3の2倍より少し多い数字にしよう」と決めました。

数学的に厳密な根拠ではありません。でも「3は少なすぎる」という事実は、Xで実測して確認していました。

「8が最適かどうか」は、まだはっきりわかりません。

まず「少なすぎない数字」に直すことを優先して、動かしながら調整することにしました。

なぜ3件では少なすぎるのか

非エンジニアの方に向けて、「なぜ3が少なすぎるのか」を平たく説明させてください。

コインの3連続表は12.5%で起きる

コインを3回投げて、3回とも表が出たとします。

このとき「このコインは表が出やすい」と言えるでしょうか。

直感的には「ちょっと怪しい」と感じますよね。でも「確証がある」とは言えない。

なぜかというと、普通のコインでも3回連続で表が出る確率は12.5%あるからです。

8回に1回くらい、「3連続表」という偶然が起きてしまうのです。

投稿の反応も偶然が続く

投稿のエンゲージメントも似ています。

「たまたま反応がよかった投稿が3件続く」という偶然は、普通に起きます。

3件では「たまたまの連続」と「本当のパターン」を区別できないのです。

8件で偶然とノイズを減らす

8件まで集めれば、偶然が8件連続する確率はぐっと下がります。

8回全部表が出る確率は約0.4%です。

3回全部表が出る確率（12.5%）と比べると、32分の1になります。

完全に証明できるわけではありません。でも、判断の信頼度が大きく変わります。

もう少し言うと、投稿の反応には曜日・時間帯・その日の話題・フォロワーの増減など、コントロールできない要因がたくさん絡みます。

3件だと、それらのノイズを平均化できないのです。

8件あれば、ノイズが一定程度相殺されて、本当の傾向が見えやすくなります。

「まあこの方向が正しそうだ」と言える水準に、ようやく近づく件数が8件でした。

8件にして3週間で変わったこと

MIN_SAMPLESを8にして約3週間が経ちましたが、今のところ大きな逆転学習は起きていません。

判断が出るまでの時間は、7日から10日ほど長くなりました。

以前は3件集まると動き出していたので、その分だけ待ちが増えたことになります。

早く間違えるより正しく判断する

最初は「機会を逃しているんじゃないか」という不安がありました。

早く判断できた方が、早く最適化が進むと思っていたからです。

でも冷静に考えると、「早く間違えること」と「早く正しく判断すること」は全然違います。

早い判断が、正しい判断と同じではありませんでした。

今は「ゆっくりでも、正しい方向に進む」を選んでいます。

週1回ログを目視で確認する

確認方法も変えました。

以前は「なんとなく動いているから大丈夫」という感覚で、ログを見ていませんでした。

今は週1回、evaluation_log.json を開いて status フィールドを目視確認しています。

promoted と demoted の件数バランスが極端に偏っていないか、短期間で promoted から demoted への逆転が起きていないかを見ます。

この確認は10分もあれば終わります。

自動化できている部分は自動化しながら、判断の品質だけは人間が定期的にチェックする。

そのバランスが大事だと、今は感じています。

少なくとも、逆転学習が起きていないことは確認できています。

「後で直す」は半年来なかった

ここで正直に言いたいことがあります。

設計したとき、「3件でとりあえず動かして、後で調整しよう」と思っていました。

その「後で」が6か月以上来なかったのです。

「後で直す」というのは、ほとんどの場合、直さないことと同じです（笑）事故が起きて初めて手を動かした、それが正直なところです。

個人開発で起きがちな後回し

これ、AIツールに限った話ではないと思います。

個人開発や自動化に取り組む人なら、似たような経験があるんじゃないかと思います。

「とりあえず動く状態にした」という達成感の後、細部の見直しが後回しになっていく。

そして「後で」は、なかなか来ない。

来るのは、たいてい事故が起きてからです。わたしもそうでした。

事故が起きなければ、Threadsでも同じことが起きていたと思います。

Xの失敗が、Threadsの予防につながった——これはラッキーでした。

でもラッキーに頼りたくはないです。

設定値を月1回見直す仕組み

最近は「設定値の定期見直しタスク」をカレンダーに入れるようにしました。

「MIN_SAMPLES、まだ合ってるか？」

という問いを月に一度、強制的に目に入るようにしているのです。

定期的に「この数字、まだ合っているか？」を確認する習慣が大事だと、今は思っています。

「動く」と「正しく動く」は違う

少し視点を変えさせてください。

個人でAIツールを動かしていると、最初の達成感は「動いた！」という体験です。

何時間も試行錯誤した後にやっと動いたときの感覚は、格別です。

でも「動く」と「正しく動く」は、違う話です。

そして「正しく動く」と「正しく動き続ける」は、さらに別の話です。

MIN_SAMPLESの問題は「正しく動く」のレイヤーの話でした。

ツールは動いていたけれど、間違った学習を積み重ねていたのです。

エラーが出ない静かな失敗

この「静かに間違い続けている」状態が、一番発見が遅れます。

エラーメッセージが出ないので、動いているように見えてしまうからです。

ログにエラーはありません。処理は完了しています。数字も出ています。

でもその数字が、間違った前提の上に乗っているのです。

こういう「静かな失敗」は、積み重なってから気づきます。

わたしの場合は6か月でした。半年間、間違った方向に最適化が進んでいた可能性があります。

AIが自動で動いているとき、人間はどうしても「AIが管理している」という感覚になります。

でも実際には「わたしが設定した数字が動かしている」だけです。

3という数字を決めたのは自分

AIに判断を任せているとき、「AIが自動で決めている」と感じることがあります。

でも実際には、「誰かが設定した数字を使って判断している」のです。

MIN_SAMPLES=3と設定したのはわたしです。それを8に変えたのも、わたしです。

AIが勝手に「3件で判断しよう」と決めたわけではありません。

設計したわたしが、3という数字を入れていただけです。

AIの精度は、設定した人間の判断に引っ張られます。

これは当たり前のことに聞こえますが、「AIが回している」という感覚になると忘れがちです。

ツールが動いている間、人間は設定値から注意が離れていきます。

でもその設定値が、ツールのすべての判断を決めています。

判断基準の設計は人でもAIでも同じ

CMO時代に「n数が足りないまま判断するな」と言っていたとき、わたしは人間のチームに向けて言っていました。

今は、AIのパラメータとして書き込んでいます。

形は変わっても、本質は同じでした。

「判断基準の設計」は、相手が人間でもAIでも、同じくらい大事なことです。

自動化しても設計の責任は残る

「設定した人間が責任を持つ」という考え方は、自動化が進むほど重要になります。

自動化によって人間の手作業は減ります。でも判断基準を設計する責任は消えません。

むしろ「一度設定したら誰も見直さない」というリスクが、自動化によって生まれます。

わたしのMIN_SAMPLESがまさにそうでした。

設定した瞬間は「3でいいだろう」と思っていた。

でもその後6か月間、誰も（わたし自身も含めて）その数字を見直さなかったのです。

何件で判断するかを先に決める

AIに何かを自動判断させるとき、「何件からOKとするか」を先に決めておくことは、地味ですが重要な設計の話です。

「AIが自動でPDCAを回してくれる」という部分にみんな目が行きがちです。

でも「その判断基準がどこに設定されているか」まで考えない。

わたしも設計当初はそうでした。動いていることに安心して、中の設定値を見直すことがなかったのです。

今日、設定値の根拠を確認する

もし数字を決めずに動かしているとしたら、今日確認してみてください。

「何件集まったら判断するか」という設定が、どこかにあるはずです。

設定ファイルの中に MIN_SAMPLES、MIN_TRIALS、min_count、threshold といった名前の変数があれば、まずその数字を確認することをすすめます。

その数字がどんな根拠で決まったか、言えますか？

「なんとなく3」だったとすれば、それが見直しポイントです。

「動いている」と「正しく動いている」を混同しないこと。

これが今回の話から一番持ち帰ってほしいことです。

この話の具体的な続き——「MIN_SAMPLESの適切な数の考え方」「判断基準をどこに設定するか」の詳しい仕組みは、Claude Code自律環境をまとめた有料記事に書いています。 このページのフッターからご覧いただけます。

最後に一つだけ聞かせてください。

今あなたが使っているAIツールや自動化の仕組みに、「何件からOKとする」という設定はありますか。

その数字が「なんとなく3」だったとしたら、今日確認してみてください。

3件目と4件目の間に、事故は静かに起きます。

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