🔧 上限を設定したSNSツールが1件も制限せず動いていた——コードを読むまで見えなかった1行の穴

道路に「工事中・迂回してください」という看板を立てたとします。

でもその看板は、車を運転するドライバーだけが見るものでした。

カーナビには、何も伝わっていません。「直進です」と案内し続けます。

看板はたしかに、そこにあります。数字も、条件も、きちんと書いてあります。

でも受け取るはずの相手には、届いていない。

これと同じことが、わたしの書いたコードの中で起きていました。

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

• AIに書いてもらったコードを「走らせた＝完了」にしている • 設定値を書いたのに、実際の動きと照合していない • エラーが出ていないから、正しく動いていると思っている • 「動かした記録」と「意図通りに動いた記録」を区別していない

先に結論を言います。「設定した場所」と「実行される場所」は、コードの中では完全に別物です。

この記事では、わたしがInstagramの自動化ツールを作った際に踏んだバグの実話と、コードを読んで初めてわかった原因を書きます。

エンジニアでなくても気づける確認方法も、合わせて書きます。

「上限10件」と書いた日——設定はたしかにそこにあった

何を自動化しようとしていたか

Instagramの特定の投稿に対して、コメントしてくれた人を自動で取得するツールを作っていました。

投稿1本あたりの処理対象を絞るために、ファイルの先頭部分に設定値をまとめて書く構造にしていました。

const maxPosts = 10という変数を書いたのは、ツール全体の設定を1か所にまとめたほうが後で直しやすいと思ったからです。

設定値を1行変えれば動作が変わる——そういう「便利な設計」のつもりでした。

ところが実際は、「便利な設計のつもり」にしかなっていませんでした。

ファイルの構造と「設定がある場所」

ツールのファイルを大まかに説明すると、上部に設定値をまとめる「設定ブロック」と、下部に処理の手順を書く「実行ブロック」の2つに分かれていました。

maxPostsは設定ブロックに書かれていて、実行ブロックの中でそれを呼び出すつもりでした。

ただ「呼び出すつもり」というのがポイントで、実際に呼び出す処理が書かれているかどうかは、書いた時点で確認していませんでした。

変数の名前が書いてあれば、自動的にそこへ届くものだと思っていたからです。

この「思っていた」という部分が、3日間の誤作動の種になりました。

「書いた」という達成感

変数に数字を入れる作業は、とても直感的です。

maxPosts = 10と書くと、10という数字がそこに存在します。

コードを読めば誰にでも「10件に制限している」と伝わります。

わたしはその瞬間、「上限設定が完了した」という達成感がありました。

書いた、数字がある、設定が入った——という感覚です。

この感覚が、3日間つづく誤解の始まりでした。「書いた」と「届いた」は、同じではなかったんです。

「届いているか」という問いを持っていなかった

設定の行を書いた後、その行をテストしていませんでした。

「書いた＝動く」という前提が、無意識に入り込んでいたからです。

「設定を書いた後、件数が設定通りになっているか確認する」という工程が、完全に抜けていました。

テストというと大げさに聞こえますが、必要だったのは「走らせた後に件数を数える」という1ステップだけでした。

その1ステップを確認リストに入れていなかったことが、問題の根本でした。

振り返ると、確認を怠ったというより「確認するべきだ」という発想自体がなかったんです。

それが今回、一番の学びになりました。

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

3日間、ログはずっと「正常終了」を返していた

エラーが1件もないきれいなログ

ツールを完成させてから、毎日走らせました。

最初の3日間、ログの最後は必ず「処理完了」という文字でした。

エラーは0件。警告も0件。

毎回、画面の上から下まで読んでも、赤い文字が一つも出てきませんでした。

「きれいに動いている」という確信が、日ごとに積み上がっていきました。

ログが教えてくれたこと、教えてくれなかったこと

当時のログには、処理の開始と終了、取得件数、APIのレスポンスステータスが記録されていました。

「取得件数：52件、ステータス：200、処理完了」のような出力が並んでいました。

今見れば一目でわかりますが、当時は「件数の表示がある＝上限が効いている」と思い込んでいました。

「件数が表示されている」と「件数が設定値通りに絞られている」は、まったく別の情報です。

ログの中に「maxPostsの値が使われた」という記録は、一切ありませんでした。

設定値がどう使われたかを記録する処理を書いていなかったので、当然でした。

「問題ない」という判断の根拠はログだけだった

当時わたしが「問題ない」と判断した根拠は、ログだけでした。

エラーが出ていない。処理が完了している。

この2点を確認して、「設定通りに動いている」という結論を出していました。

でも本当は「処理が完了した」という事実しか、ログは教えていませんでした。

「意図した件数に絞られているか」という問いへの答えは、ログのどこにも書いていなかったんです。

その問い自体を立てていないことが、問題でした。

件数を数えたのは3日目の夜

3日目の夜、ふとした気まぐれで処理済みの件数を数えてみました。

「50件を超えている」という数字が出てきました。

設定した上限は10件でした。その5倍以上が処理されていました。

最初は自分の数え間違いかと思いました。でも何度数えても、50件を超えていました。

「設定の書き方を間違えたのかも」という混乱

「設定の書き方を間違えた」と思い、コードを確認しました。

const maxPosts = 10の行は、たしかにそこにありました。

数字はある。設定は書いてある。それなのに、なぜ効いていないのか——という混乱が続きました。

おかしいとわかっているのに、何がおかしいのかを言語化できない状態が約1時間続きました。

「書いてある変数が、なぜ無視されるのか」という問いを持てたのは、そこからさらに30分後のことでした。

コードを読んで初めてわかった「2つの場所」の存在

page.evaluateとは何か——工場の例えで

原因を探っていくうちに、page.evaluateという命令にたどり着きました。

聞き慣れない言葉だと思いますので、工場の例えで説明します。

工場には「コントロールルーム」と「作業フロア」の2か所があります。

コントロールルームの人が「ライン3を10回だけ動かして」と書いたメモを机に置きました。

でもフロアの作業員に、そのメモが手渡されませんでした。

フロアは「10回だけ」という指示を知らないまま、動き続けます。

page.evaluateは、この「作業フロア」にあたる部分です。

変数が「届かない」という意味——スコープという壁

page.evaluateの外側で設定した変数は、内側では自動では見えません。

これはJavaScriptという言語の「スコープ」という仕様で、バグでも設計ミスでもありません。

スコープとは「変数が見える範囲」のことで、page.evaluateの中は独立した領域として扱われます。

正しく動かすには、「引数」という形で明示的に渡す必要があります。

引数とは、フロアの作業員にメモを手渡す行為のことです。

わたしのコードには、その手渡しが書いてありませんでした！フロアは「上限は何件ですか？」

という情報を受け取れず、無制限で動き続けました。

渡す処理が1行なかっただけという事実

コードで言えば、page.evaluateの呼び出しに引数を追加するだけが修正内容でした。

変更前は変数名が外にあるだけで、中へ渡す記述がありませんでした。

変更後は引数として渡す形になり、フロアが「10件まで」という指示を受け取れるようになりました。

修正自体は1行の変更でしたが、原因にたどり着くまでに合計2時間近くかかりました。

原因に気づいた後の修正より、原因を特定するまでの時間のほうが圧倒的に長い——これが今回の教訓の一つです。

ログに「変数の値」を出力すれば早く気づけた

後から気づいたのですが、処理の冒頭に「maxPostsの値をログに出力する」1行を書いておけば、初日に発見できていました。

「上限件数：undefined」という出力が出れば、「届いていない」とすぐわかります。

undefined（未定義）という文字は、変数が届いていないサインです。

ログに「処理した件数」だけでなく「使用した設定値」を記録する習慣があれば、見落としが大幅に減ります。

完全なログ設計の手順は有料記事側にまとめていますが、まず「設定値が届いたか」を1行出力するだけでも、発見が格段に早くなります。

「外」と「中」という発想がなかった

コードを書いていて、「外側」と「内側」という概念をあまり意識していませんでした。

全部がつながっている1つのものだと、なんとなく思っていたからです。

でも実際には、page.evaluateの外と中は別世界です。

外で定義した変数は、意識して渡さない限り、中には入れません。

この「別世界」の存在を理解したとき、問題の原因がすっきり見えました。

渡す処理が1行なかっただけ——ただそれだけの話でした（笑）

CMO時代には「設定した＝届く」を疑ったことがなかった

管理画面には「保存ボタン」がある

以前、月3,000万円規模の広告運用に携わっていた時期があります。

その頃は毎日、さまざまなツールの管理画面を触っていました。

広告の上限予算を入力して「保存」を押す。配信条件を設定して「適用」を押す。

「保存されました」という確認が必ず出るので、設定が届いたかどうかを疑いませんでした。

「設定した＝届く」が、完全に当たり前の前提でした。

設定ツールが提供する「信頼の幻想」

広告管理画面、CMSの管理画面、SaaSの設定画面——これらはすべて「設定の反映」を保証してくれています。

「保存ボタンを押したら値をDBに書く」「書いた値を実行時に読み出す」——この2つの処理が、当たり前のように機能しているのは、誰かが設計して実装しているからです。

自分でコードを書く世界では、その安心感は誰も提供してくれません。

設定を書いて、届けて、届いたことを確認する——この3ステップが全部、自分の責任になります。

ユーザーとして管理画面を使っている間は見えなかった「届ける工程」が、作る側に回った瞬間に全部見えてきます。

「届ける仕組み」は誰かがすでに作っている

でも自分でコードを書くと、話が変わります。

管理画面の裏側には、誰かが「保存ボタンを押したら値を書き込む」処理を書いています。

その仕組みを使っている側にいると、その存在は見えません。

自分でコードを書くとき、「届ける工程」は自分で設計する必要があります。

「書いたから届く」ではなく、「届けるコードを別途書く」が必要なんです。

管理画面の向こうにある仕組みの重さが、初めて見えた瞬間でした。

コードを書くまで、その存在に気づいていませんでした。

「設定が届いているか」という問いの発見

CMO時代、「設定が届いているか」を確認する方法を持っていませんでした。

確認する必要性を感じたことも、ありませんでした。

管理画面が「そういうもの」として用意されていたので、その向こう側は気にしなかった。

それで何年も仕事できていたから、疑問にすらなりませんでした。

自分でコードを書いて初めて、「届ける責任が自分にある」と分かりました。

「届いているか」という問いが、初めて自分ごとになった瞬間でした。

AIが書いてくれたコードでも、同じ穴は起きます

エラーが出ないバグは、AIも気づきにくい

ClaudeやChatGPTにコードを書いてもらうことが増えました。

AIが書くコードは、文法的には正しいことが多いです。

でも「文法的には正しい、でも意図通りに動かない」バグは、AIも気づきにくいです。

エラーが出ないため、「問題ない」と判断しやすいからです。

わたし自身も、このコードをAIと一緒に書いていました。

それでも「走らせた結果を設定値と照合する」工程は、人間が担う必要があります。

AIに「変数が届いているか確認して」と頼む

コードを書いてもらった後に「この設定値が実際に使われているか確認するログ出力を追加して」と頼むと、AIは確認用の出力を追加してくれます。

「maxPostsが10件として動いているかどうかを、実行時に出力するコードを追加して」と頼むと、処理の冒頭に確認行を書いてくれます。

実行後に「上限件数：10」という表示が出れば、設定が届いていると確認できます。

「undefinedが出ていないか」「NaNが出ていないか」——この2点を走らせた後に確認するだけで、変数の受け渡し問題はかなり早く発見できます。

undefinedは「変数が届いていない」、NaNは「数値として扱えなかった」というサインです。

「動かした記録」と「意図通りに動いた記録」は別

ログに「処理完了」と書いてある。AIが書いたコードだから品質は高い。

この2つが揃っていても、「設定値が意図通りに使われているか」は別の問いです。

走らせた件数と、設定した上限を照合する。

その作業を1回するだけで、今回のバグは発見できました。

「走らせた後に照合する」という工程が抜けていたことが、3日間気づけなかった直接の原因でした。

AIとのコードレビューで確認すべき2点

AIが書いたコードを走らせる前に、確認するようになったポイントが2つあります。

1つは「設定値がどこで定義され、どこで使われているか」を追うことです。

定義した変数が、使われる場所まで確実に届いているか——このルートを1度なぞります。

もう1つは「この変数がundefinedだったとき、どういう動きになるか」をAIに聞くことです。

undefinedが渡されたとき何が起きるかを事前に知っておくと、ログの読み方が変わります。

この2点は、エンジニア経験がなくても実践できる確認方法です。

「1行の追加」で直り、確認に15分かかった

修正したのは数文字だった

修正の内容は、技術的には単純でした。

page.evaluateを呼び出す行に、maxPostsを引数として追加しました。

変更したのは1行、増えた文字数は10文字にも満たないです。

変更前と変更後を並べると、見た目はほとんど変わりません。

でもその差が、3日間の誤作動を生んでいました。

修正の前に、原因を言語化した

修正を加える前に、「何が起きていたか」を自分の言葉で書き出しました。

「maxPostsという変数は設定ブロックに書いてあるが、page.evaluateの内側には引数として渡されていないため、内側ではundefinedになっていた。

undefinedを件数の上限として渡しても上限なしで動き続けた」というものです。

このように書き出してみると、修正すべき箇所が1か所だけだとわかりました。

原因を言語化してから修正する——この順番が、修正後の確認をしやすくします。

書き出した原因と、修正後の動作が合っているかを照合できるからです。

修正後に「件数の一致」を確認した

修正した直後、すぐにツールを走らせました。

「修正できた」ではなく「修正が効いたか」を確認するためです。

処理された件数を数えると、ちょうど10件でした。設定した上限と一致していました。

この一致を確認して、初めて「直った」と言いました。

「修正した＝直った」ではなく「件数が合った＝直った」という確認の仕方です。

確認に15分かけた意味

修正してから件数を確認するまで、15分かかりました。

ツールを走らせて、結果を数えて、設定値と照合する——この工程が15分です。

最初からこの15分を踏んでいれば、3日分の誤作動は起きませんでした。

「確認に15分かける」価値の大きさが、じわじわと分かりました。

修正前に「設定した＝届く」と思い込んだのと同じ間違いを、修正後に繰り返したくなかった。

だから、自分の目で数字が合うのを見るまで「完了」と言いませんでした。

この経験が変えた、1つの確認習慣

「ログが正常」は「設定が効いた」ではない

エラーなし、警告なし、処理完了——これはすべて「処理が終わった」という意味です。

「あなたの設定通りに動いた」という意味は、どこにもありません。この2つは、答えるべき問いが違います。

ログを見て安心するのは自然なことですし、わたしも今でもします。

でも、ログとは別に「設定値が本当に使われているか」という問いを持つようになりました。

具体的には、新しいツールを初めて走らせるとき、必ず「設定した数字がログに表示されているか」を確認します。

これは1分もかからない確認で、のちのち何時間もの原因調査を防いでくれます。

ログに「設定値の確認行」を入れる

今のわたしのコードには、主要な設定値を処理の冒頭で出力する行が入っています。

「対象件数の上限：○件で開始します」「スリープ時間の設定：○秒」のような出力です。

これを見ることで「設定値がここに届いている」という確認ができます。

undefinedやNaNが出ていれば、その時点で設定の渡し方を疑えます。

エラーが出るまで待つのではなく、設定値を先に見せてもらう——これが今の習慣です。

この確認行を書くときも「AIに設定値の確認出力を追加して」と頼むと、1分で入ります。

コードを「読める」ことの意味

わたしはエンジニアではありません。ゼロからコードを書ける人間でもありません。

それでも「何かがおかしい」と感じたとき、コードを読んで原因を見つけられました。

100%理解しなくても、「ここで何かを渡しているな」という読み方で十分でした。

動いているように見えるものを疑う力。ログではなく、実際の数字を確認する習慣。

これは、エンジニアだけが持てるものではないと、今では思っています。

自動化ツールの仕組みを体系的に知りたい方は、わたしのClaude Code自律環境についてまとめた有料記事で詳しく書いています。よければ参考にしてみてください。

今日からできる、たった1つの照合

走らせた後に問う、1つの質問

ツールを走らせたら、こう問いかけてみてください。

「設定した数字と、実際の件数は合っているか？」

これだけです。コードが読めなくても、数字を見ることはできます。

設定が10件なら10件か。対象が5件なら5件か。

ただそれだけの照合が、今回のようなバグを見つける最短ルートです。

1回の確認が、何日分もの誤作動を防ぎます。

ツールを走らせる前の「1行確認」

初めてコードを動かすとき、わたしが必ずするようになった確認があります。

それは「AIに、この設定値がundefinedになった場合は何が起きるか」を聞くことです。

答えが「無制限に処理されます」であれば、変数の渡し方を確認するきっかけになります。

この問い1つが、走らせる前のリスク確認として機能します。

「最悪の動作」を先に知ることで、確認すべきポイントが見えてきます。

「届いた」を確認することが、確認の本当の意味

「動かした」「ログが正常だった」は、出発点です。

「設定が届いたか」という問いを1回追加するだけで、今回のようなバグは早く見つかります。

わたしがこの確認を習慣にしたのは、3日間気づけなかった経験があるからです。

ログしか見ていなければ、もっと長く気づけなかったかもしれません。

「動いている」と「設定が効いている」は、別の状態です。

その違いを、エラーのないログは教えてくれません。

以上です。フォーマット確認：

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